From diameter-admin@frascone.com Mon Nov 1 05:02:10 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10348 for ; Mon, 1 Nov 2004 05:02:10 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 61B061FE45 for ; Mon, 1 Nov 2004 05:02:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0E8231FDF4 for ; Mon, 1 Nov 2004 05:01:50 -0500 (EST) Date: Mon, 01 Nov 2004 05:01:49 -0500 Message-ID: <20041101100149.31173.16835.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 zehigfcyzcu@yahoo.com Mon Nov 1 10:32:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19255 for ; Mon, 1 Nov 2004 10:32:24 -0500 (EST) Message-Id: <200411011532.KAA19255@ietf.org> Received: from [211.229.128.42] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1COePO-0001FZ-69 for eap-archive@ietf.org; Mon, 01 Nov 2004 10:47:51 -0500 Received: from 118.96.67.105 by 211.229.128.42; Mon, 01 Nov 2004 16:21:00 +0100 From: "Miles Arthur" Reply-To: "Miles Arthur" To: dn@ietf.org Cc: drafts@ietf.org, e3@ietf.org, eamoby@ietf.org, eap-archive@ietf.org Subject: You Need This Dn Antivirus: No virus found baklava Date: Mon, 01 Nov 2004 08:23:00 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--5067819077162168921" X-Spam-Score: 8.7 (++++++++) X-Spam-Flag: YES X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d ----5067819077162168921 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit The L0west price of all med's is here. *Vic0din ($85 only) *Via-gra ($87 only) *Va|ium ($89 only) *Hydroc0done ($89 only) *Phen-termine ($88 only) We are the be-st available nowadays. http://bestpill.newmedsolutionsite.com/?k=S17h49 This is 1- time mai-|ing. N0 re m0val are re qu|red iZ4uxBh5Quh9QNjNqYWOjmONSPHA0Kzk0KXbPxvT88nL ----5067819077162168921-- From bdmtj@comcast.net Mon Nov 1 10:42:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21808; Mon, 1 Nov 2004 10:42:31 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COeZ9-0001VA-QL; Mon, 01 Nov 2004 10:57:58 -0500 Received: from pcp740286pcs.reston01.va.comcast.net ([68.49.153.1]) by mx2.foretec.com with smtp (Exim 4.24) id 1COeKB-0002uS-MC; Mon, 01 Nov 2004 10:42:28 -0500 Received: from pcp740286pcs.reston01.va.comcast.net by gateway-s.comcast.net with SMTP id eleztd; Mon, 01 Nov 2004 08:29:08 -0600 Received: from 143.237.84.251 by pcp740286pcs.reston01.va.comcast.net with SMTP; Mon, 01 Nov 2004 08:28:38 -0600 Date: Mon, 01 Nov 2004 08:27:54 -0600 Content-Type: text/plain; charset="iso-8859-3" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit To: "Mabel Diffserv-interest" Subject: eyes under his lowered, Message-ID: <000301c4c01f$25c56870$5f422da2@zagsbfjubu> From: "Shirley Cross" X-Spam-Score: 4.9 (++++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit This notification was sent using automated system. Please process to stop the auto-generated email. Mon, 01 Nov 2004 08:29:08 -0600 A pprov a l Account Statement Security Control Number: 2274-1917-8145-7490 Offer Expiration Date: 11/17/04 Interest Ra t e: 3.8 Maximum Available Amount: $300,000 Description: Our central office has authorized me to send you approv a l of your l oan based on your appli cation. Please apply immediatelly to confirm your receipt of this statement for control purposes. http://www.bokwhdok.com/ Thank you. Shirley Cross, Manager From admin@staffadministrator.com Tue Nov 2 13:45:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27397; Tue, 2 Nov 2004 13:45:53 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP3uF-0001yh-KF; Tue, 02 Nov 2004 14:01:34 -0500 Received: from host-22.pl107793-1.fiber.net ([204.250.198.22]) by mx2.foretec.com with smtp (Exim 4.24) id 1CP3f0-0000mz-FQ; Tue, 02 Nov 2004 13:45:38 -0500 Received: from ve5u.il6f.net ([213.183.248.201]) by host-22.pl107793-1.fiber.net id <2643707-75900> for ; Tue, 02 Nov 2004 14:45:35 -0400 Message-ID: <4kb07$7e28-$999v9k@fa8hour.vd> From: "Administrator" To: secretgurl@ietf.org Subject: ADV: Staff Announcement Date: Tue, 02 Nov 04 14:45:35 GMT X-Priority: 1 X-MSMail-Priority: High X-Mailer: MIME-tools 5.503 (Entity 5.501) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="C2FDF3BF_8C" X-Spam-Score: 27.1 (+++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d This is a multi-part message in MIME format. --C2FDF3BF_8C Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Attention All Nonprofit Organizations: Members and Staff You Must Respond By 5 P.M. Wednesday, November 3, 2004. Through a special arrangement, Avtech Direct is offering a limited allotment of BRAND NEW, top of-the-line, name-brand desktop computers at more than 50% off MSRP to all Nonprofit Members and Staff who respond to this message before 5 P.M., Wednesday, November 3, 2004 All desktop computers are brand-new packed in their original boxes, and come with a full manufacturer's warranty plus a 100% satisfaction guarantee. These professional grade Desktops are fully equipped with 2005 next generation technology, making these the best performing computers money can buy. Avtech Direct is offering these feature rich, top performing Desktops with the latest technology at an amazing price to all who call: 1-800-795-8466 by 5 P.M. Wednesday, November 3, 2004 The fast and powerful AT-3200 series Desktop features: * IBM Processor for amazing speed and performance * 128MB DDR RAM, -- Upgradeable to 1024 * 20 GB UDMA Hard Drive, -- Upgradeable to 80 GB * 52X CD-Rom Drive, -- Upgradeable to DVD/CDRW * Next Generation 2005 Technology * Premium video and sound -- For enhanced colors and graphics * Full Connectivity with Fax modem/Lan/IEE 1394/USB 2.0 * Soft Touch Keyboard and scroll mouse * Internet Ready * Network Ready * 1 Year parts and labor warranty * Priority customer service and tech support MSRP $499 ........................................ Your Cost $227 How to qualify: 1. You must be a Member, Staff or Associate of a Nonprofit. 2. All desktop computers will be available on a first come first serve basis. 3. You must call 1-800-795-8466 by 5 P.M. Wednesday, November 3, 2004. and we will hold the desktops you request on will call. 4. You are not obligated in any way. 5. 100% Satisfaction Guaranteed. 6. Ask for Department C. Call Avtech Direct 1-800-795-8466 before 5 P.M. Wednesday, November 3, 2004 Visit our website at http://www.avtechdirect-nonprofits.com If you wish to unsubscribe from this list, please go to http://www.computeradvice.org/unsubscribelink.asp Avtech Direct 22647 Ventura Blvd. Suite 374 Woodland Hills, CA 91364 --C2FDF3BF_8C-- From wo16288@21cn.com Tue Nov 2 14:20:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00653 for ; Tue, 2 Nov 2004 14:20:38 -0500 (EST) Message-Id: <200411021920.OAA00653@ietf.org> Received: from [218.17.62.192] (helo=21cn.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP4S1-0002pU-Ip for eap-archive@ietf.org; Tue, 02 Nov 2004 14:36:20 -0500 From: =?GB2312?B?ye7b2si6waa/xry8?= Subject: =?GB2312?B?s6y1zbzbKr/sy9nXqNK1yc/Dxc6s0N6158TU?= To: eap-archive@ietf.org Content-Type: text/html;charset="GB2312" Content-Transfer-Encoding: 8bit Date: Wed, 3 Nov 2004 03:20:11 +0800 X-Priority: 2 X-Mailer: EhooSend 2004c X-Spam-Score: 5.4 (+++++) X-Spam-Flag: YES X-NONENGLISH: Subject contains non-English characters X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 8bit ÎÞ±êÌâÎĵµ
 
Ç×°®µÄÅóÓÑÃÇ£º
    ÄúÃǺã¡×÷ΪµçÄÔµÄÖ÷ÈË£¬ÄãÃÇÊÇ·ñÔø¾­ÎªÎ¬ÐÞµçÄÔ¶ø¿àÄÕ¹ýÄØ£¿ÏÄÌ죬×ó§ÓÒ±§µÄ´ø×ŵçÄÔÖ±±¼»ªÇ¿¡¢Èü¸ñ£¬ÏÈ°´ÏÂһ·ÉÏŪµÃÏ㺹ÁÜÀìºÍÒ»ÉíÆ£±¹ ²»Ëµ£¬²»¹ý¶¬Ì컹¿ÉÒÔ£¬Ö»µÃÒ»ÉíÀÛ°É¡£µ«µ½Á˵çÄÔ¹«Ë¾¼ûµ½Á˹¤³Ìʦ£¬ÊÇ·ñÄÜÂíÉÏ¿ª¹¤°ïæ¸ãµàÄØ£¿Õâ¸ö»¹µÃ¿¿ÔËÆøÄØ£¬´ËÇé´Ë¾°Äã˵ͷ²»Í·ÔΣ¿×÷Ϊһ¸öÉúÒâÈË£¬Ê±¼ä¾ÍÊǽðÇ®£¬ÔÙ¼Ó ÉÏÕâÊǸö¸ßËÙÐÅÏ¢»¯Ê±´ú£¬Ã»ÓÐÁ˵çÄÔ£¬¼òÖ±¾ÍÏñÈȹøÉϵÄÂìÒÏ¡£Ãæ¶Ô´ËÇé´Ë¾°£¬´Ëʱ´Ë¿ÌÎÒÃÇÉîÛÚȺÁ¦¿Æ
¼¼Ö»ÏëÓÃÎÒÃǵÄÇà´º»»»ØÄãÃDZ¦¹óµÄʱ¹â£¬ÌØΪÅóÓÑÃdzÊÉÏÎÒÃǵķþÎñ£¬¿Ò Çë¶à¶àÖ¸½Ì£¬Ð»Ð»¡£
     ³¬µÍ¼Û**Ç©Ô¼°üÔÂ**¿ìËÙרҵÉÏÃÅάÐÞµçÄÔ
            ÉÁµç°²×°ÐÂϵͳ  30·ÖÖÓ¾ÍOK  ÉúÒâÈ˵ÄÊ×Ñ¡

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

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

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

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

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

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



¡¡    ÍøÂçά»¤£ºhttp://www.it678.net ¡¡¡¡¡¡¡¡¡¡¡¡¡¡               µçÄÔάÐÞ£ºhttp://www.it678.net
From AnniezowSalazar@cheerful.com Tue Nov 2 16:27:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14995; Tue, 2 Nov 2004 16:27:48 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP6R8-0006Re-Gi; Tue, 02 Nov 2004 16:43:31 -0500 Received: from specialist.nmsu.edu ([128.123.80.102]) by mx2.foretec.com with smtp (Exim 4.24) id 1CP6Bn-0007KT-J9; Tue, 02 Nov 2004 16:27:39 -0500 Received: from torpor2neuritiseligible (83.20.913.26) by mail69.qchat.net (carolynnick OIGBT 8.2.980) id 1713CL3XWWM44FW3265 for fts@ietf.org; Tue, 02 Nov 2004 14:19:12 -0600 X-MIME-Autoconverted: Yes Disclose-Recipients: No Discarded-X400-MTS-Extensions: Yes Alternate-Recipient: Allowed X-No-Archive: Yes Reply-To: "Kermit-Huber" From: "Kermit-Huber" To: fts@ietf.org Cc: adm@ietf.org, avt@ietf.org, toips@ietf.org, haa24250@ietf.org, imss-admin@ietf.org, ping@ietf.org, ieprep-request@ietf.org, ietf-request@ietf.org, secretary@ietf.org, meeting-planning@ietf.org, ietf-languages@ietf.org, pr-wg@ietf.org, eap-archive@ietf.org, tsvwg-request@ietf.org Subject: We are waiting for your response Date: Wed, 03 Nov 2004 01:22:12 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--4198467767116183896" Message-Id: X-Spam-Score: 3.9 (+++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab ----4198467767116183896 Content-Type: text/html; charset="iso-0265-4" Content-Transfer-Encoding: 7Bit Hello,

We were reviewing your record and noticed that your mortga[g]e rate was over 6%. We can give you a guaranteed fixed rate of 2.3%. You also qualify for up to $300,000.

Please fill out the form at this webpage to complete the process:
http://quotehawk.com/?partid=rm2342

We look forward to hearing from you.

Regards,
Berrison United, LLC.

not interested ----4198467767116183896-- From xmdofexkqu@hotmail.com Wed Nov 3 12:02:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27259; Wed, 3 Nov 2004 12:02:45 -0500 (EST) Message-Id: <200411031702.MAA27259@ietf.org> Received: from [218.232.7.42] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CPOmN-0001Ww-96; Wed, 03 Nov 2004 12:18:40 -0500 Received: from 96.192.248.126 by 218.232.7.42; Wed, 03 Nov 2004 20:56:28 +0400 Reply-To: "Trina Cassidy" From: "Trina Cassidy" To: disman@ietf.org, disman-admin@ietf.org, disman-request@ietf.org, eap-archive@ietf.org, edu-team@ietf.org, edu-team-web-archive@ietf.org, entmib@ietf.org, entmib-admin@ietf.org, entmib-request@ietf.org Subject: Vi-c0din, Via-gra are Che.ap Here Disman PID: 6 donald Date: Wed, 03 Nov 2004 22:53:28 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--6319163209541962581" X-Spam-Score: 5.7 (+++++) X-Spam-Flag: YES X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ----6319163209541962581 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Buy Med's 0n-line! Up to 8o% off Vi-c0din, Cia|is, V|agra, Xanax, Vioxx, Valium and many more! Fast delivery! with wholesale prices! -No Con^sultation -No Prior Prescription Needed -Hu'ge Savings! See why our customers re-order more than any competitor! http://bestpill.newmedsolutionsite.com/?k=S17h49 This is 1-time mai |ing. No rem0val are re qui-red wszR3GF95GkOlTAWEoBaT1RL0awYa6ZucZoGJI7oZmc ----6319163209541962581-- From eap-admin@frascone.com Wed Nov 3 14:01:10 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08278 for ; Wed, 3 Nov 2004 14:01:10 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B5F7D1FE3E; Wed, 3 Nov 2004 14:01:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F0E511FC6E; Wed, 3 Nov 2004 14:01:02 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6085A1FC63 for ; Wed, 3 Nov 2004 14:00:11 -0500 (EST) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by mail.frascone.com (Postfix) with ESMTP id A43251FC6E for ; Wed, 3 Nov 2004 14:00:09 -0500 (EST) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id iA3J4K7j022846 for ; Wed, 3 Nov 2004 19:04:20 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id iA3J2v5b011192 for ; Wed, 3 Nov 2004 19:03:58 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004110311000620309 for ; Wed, 03 Nov 2004 11:00:06 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 3 Nov 2004 11:00:06 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: draft-adrangi-eap-network-discovery-05.txt Thread-Index: AcTB11PVbr40GIFAStm0aV4ldVIzMQ== From: "Adrangi, Farid" To: X-OriginalArrivalTime: 03 Nov 2004 19:00:06.0293 (UTC) FILETIME=[55173450:01C4C1D7] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] draft-adrangi-eap-network-discovery-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: Wed, 3 Nov 2004 11:00:04 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable It seems that this announcement never appeared on eap mailing list -- at least some of us didn't see it. So here it is. This version addresses the issue 256 as per discussion on the list. BR, Farid 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-05.txt Pages : 12 Date : 2004-10-25 =09 This document defines a mechanism that allows an access network to provide identity selection hints to an EAP client. The purpose is to help the client in selecting the most appropriate identity and NAI decoration to use. This solution is especially useful in roaming scenarios where the access network does not have a direct relationship with the client's home network, but instead a mediating network, such as a roaming consortium or broker, is used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery- 05.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request at ietf.org with the word unsubscribe in the body of the 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 username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-adrangi-eap-network-discovery-05.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 at ietf.org. In the body type: "FILE /internet-drafts/draft-adrangi-eap-network-discovery-05.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. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From Maricela.Sutton@fastemailer.com Thu Nov 4 00:51:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29889; Thu, 4 Nov 2004 00:51:36 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPamN-00026V-44; Thu, 04 Nov 2004 01:07:38 -0500 Received: from ppp-69-106-144-200.dialup.skt2ca.pacbell.net ([69.106.144.200]) by mx2.foretec.com with smtp (Exim 4.24) id 1CPaWk-0002vL-NJ; Thu, 04 Nov 2004 00:51:22 -0500 X-Message-Info: D62SWZ11PIIrdhke1ttEjdbJUH06QO73nkMYsiaHRL504 Received: from dilute5knowbelgium (57.64.192.57) by mail4746.Maricela.Sutton@fastemailer.com (Bluewin AG 9.5.781) id 76651SO2LFA807PKV78439 for diffserv-interest-admin@ietf.org; Thu, 04 Nov 2004 04:49:32 -0100 Message-ID: <644259496370431.14765@Maricela.Sutton@fastemailer.com> Reply-To: "Joel Ayala" From: "Joel Ayala" To: "Diffserv-interest-admin" Subject: RE: account # 4399Z Date: Thu, 04 Nov 2004 03:42:32 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--05060181388655365" X-Spam-Score: 6.0 (++++++) X-Spam-Flag: YES X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 ----05060181388655365 Content-Type: text/html; charset="iso-5599-8" Content-Description: clarinet az8382.pizza Content-Transfer-Encoding: 7Bit Hello Diffserv-interest-admin,

We sent you an email a while ago, because you now qualify for our buyers program.
You could get $3000 worth of meds for as little as $600 a month!
Bad credit is no problem

Please click on this link for free consultation by a medical doctor:
Start Saving Here

Best Regards,
Joel Ayala






































spool cripple diophantine scoff wrongful perfume average socratic abash mangle %RND_ORD bowel jutish airpark chamomile snakeroot furtive carnivalintuit clinch inferential secretive natchez e halloween goodwill asylum prejudicial ostrander isochronous setback ankle fibrin tradesman koenig septateswitchboard radiochemistry guildhall goldstein sojourn camouflage sault mn sanderling squirmy cacao bolshoi housewife paid wither conjugacy medico protactiniumcodeposit floridian land callahan huber alice gemma aaas apace protest sardine deductible acquisitive prodigy colonist cereus igloo meridianattrition davis homebound conquest park relinquish thence confess backplate amaze armageddon factual pink reserve crochet ----05060181388655365-- From mongolia.0399vigorous@amega.com Thu Nov 4 04:27:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01222; Thu, 4 Nov 2004 04:27:15 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPe9G-00070P-24; Thu, 04 Nov 2004 04:43:18 -0500 Received: from lsanca1-ar59-4-8-007-034.lsanca1.dsl-verizon.net ([4.8.7.34]) by mx2.foretec.com with smtp (Exim 4.24) id 1CPdti-0001BJ-Ab; Thu, 04 Nov 2004 04:27:14 -0500 X-Message-Info: 44033YADKAdtp19989OsPXODhjdqu+4352 Received: from su16689.ul.homestead.com ([152.15.142.112]) by ntsjq771779-t.homestead.com with Microsoft SMTPSVC(5.0.2195.6824); Thu, 04 Nov 2004 05:17:57 -0300 Message-ID: <13415.818382.MHLHip.8207ag@homestead.com> Conversion-With-Loss: Yes Sensitivity: 7 Expiry-Date: Never Xref: nsygmptpwnsvzhk Reply-To: "Tammie_Cote" From: "Tammie_Cote" To: haa24250@ietf.org Cc: imss-admin@ietf.org, ping@ietf.org, ieprep-request@ietf.org, ietf-request@ietf.org, secretary@ietf.org, meeting-planning@ietf.org, ietf-languages@ietf.org, pr-wg@ietf.org, eap-archive@ietf.org, tsvwg-request@ietf.org, usic-admin@ietf.org, policy@ietf.org Subject: Verification: Is this the right address Date: Thu, 04 Nov 2004 02:22:57 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--418736641553628986" X-Spam-Score: 7.7 (+++++++) X-Spam-Flag: YES X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 ----418736641553628986 Content-Type: text/html; charset="iso-2612-0" Content-Transfer-Encoding: 7Bit Dear Applicant,

Your application was processed and approved. You are eligible for $400,000 with a 2.1% rate.

Please verify your information here:
http://quotehawk.com/?partid=rm2342

We look forward to hearing from you.

Regards,

Tammie_Cote, Client Account Manager
Kerry Financial Association
5934 Beach Avenue
Miami, FL 43085
not interested ----418736641553628986-- From eap-admin@frascone.com Thu Nov 4 15:34:12 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01654 for ; Thu, 4 Nov 2004 15:34:11 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0869C1FEB4; Thu, 4 Nov 2004 15:34:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8C95D1FD43; Thu, 4 Nov 2004 15:34:04 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 818881FD43 for ; Thu, 4 Nov 2004 15:33:16 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 8CF5A1FC6F for ; Thu, 4 Nov 2004 15:33:14 -0500 (EST) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 199318988A; Thu, 4 Nov 2004 22:33:10 +0200 (EET) Message-ID: <418A919C.20908@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: Bernard Aboba 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] agenda for EAP WG at IETF-61 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, 04 Nov 2004 22:31:24 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Here's the preliminary agenda for our meeting at the IETF-61 next week. Sorry for posting this late. Let us not if there's something missing. WEDNESDAY, November 10, 2004 0900-1130 Morning Sessions Room "Military" 1. Preliminaries (chairs), 5 min 2. Document status (chairs), 10 min See also http://www.drizzle.com/~aboba/EAP/eapissues.html 3. Keying framework discussion (Bernard Aboba), 50 min http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-keying-04.txt Goal: Discuss the issues recently brought up on the mailing list. 4. State machine status update (chairs/Pasi Eronen), 5 min http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-05.pdf Goal: Update on the process. Discuss issues, if necessary. 5. Authenticated service information discussion (Jari Arkko/Pasi Eronen), 15 min http://www.ietf.org/internet-drafts/draft-arkko-eap-service-identity-auth-01.txt Goal: Discuss the difference of "channel binding" and "authenticated service identity/information". 6. Network selection update (chairs/Farid Adrangi), 5 min http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-05.txt http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-netsel-problem-02.txt Goal: Update on the process status, input from IEEE, discuss issues if necessary. 7. EAP PAX discussion (Charles Clancy), 15 min http://www.ietf.org/internet-drafts/draft-clancy-eap-pax-01.txt Goal: Present a new, radically changed version of EAP PAX. 8. AOB _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Nov 4 15:35:09 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 PAA01822 for ; Thu, 4 Nov 2004 15:35:08 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A051B1FD43; Thu, 4 Nov 2004 15:35:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D7E341FEAB; Thu, 4 Nov 2004 15:35:04 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 58D9C1FEBF for ; Thu, 4 Nov 2004 15:34:25 -0500 (EST) Received: from cingular.com (extmail10.cingular.com [170.35.225.25]) by mail.frascone.com (Postfix) with ESMTP id 9F6BA1FEAB for ; Thu, 4 Nov 2004 15:34:23 -0500 (EST) Received: from ([135.214.241.196]) by extmail10.cingular.com with ESMTP id KP-VYFP6.4162966; Thu, 04 Nov 2004 15:33:34 -0500 Received: from scentmail.entp.attws.com (localhost [127.0.0.1]) by viruswall2.entp.attws.com (8.12.10/8.12.10) with ESMTP id iA4KXZ1k024260 for ; Thu, 4 Nov 2004 12:33:35 -0800 (PST) Received: from WA-MSGBH01-BTH.wireless.attws.com (WA-MSGBH01-BTH.wireless.attws.com [135.214.26.241]) by scentmail.entp.attws.com (8.8.8p2+Sun/8.8.8) with ESMTP id MAA26042 for ; Thu, 4 Nov 2004 12:33:33 -0800 (PST) Received: from WA-MSG10-BTH.wireless.attws.com ([135.214.41.74]) by WA-MSGBH01-BTH.wireless.attws.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 4 Nov 2004 12:33:32 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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] draft-adrangi-eap-network-discovery-05.txt Message-ID: Thread-Topic: [eap] draft-adrangi-eap-network-discovery-05.txt Thread-Index: AcTB11PVbr40GIFAStm0aV4ldVIzMQAzbMwAAAIFqaA= From: "Bari, Farooq" To: X-OriginalArrivalTime: 04 Nov 2004 20:33:32.0601 (UTC) FILETIME=[8D1FAA90:01C4C2AD] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 4 Nov 2004 12:33:32 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Apologies for the duplicate - my last email did not get posted to the mailing list -----Original Message----- From: Bari, Farooq=20 Sent: Thursday, November 04, 2004 11:37 AM To: 'Adrangi, Farid'; eap@frascone.com Cc: 'Jari Arkko'; 'Bernard Aboba' Subject: RE: [eap] draft-adrangi-eap-network-discovery-05.txt This draft now includes Jari's proposed text on issue 256. There were no other comments or disagreements to his proposal on this issue (and this is the only issue open for the draft in the issue list). Is my understanding correct that the issue 256 is now resolved completely? BR, Farooq -----Original Message----- From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] On Behalf Of Adrangi, Farid Sent: Wednesday, November 03, 2004 11:00 AM To: eap@frascone.com Subject: [eap] draft-adrangi-eap-network-discovery-05.txt It seems that this announcement never appeared on eap mailing list -- at least some of us didn't see it. So here it is. This version addresses the issue 256 as per discussion on the list. BR, Farid 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-05.txt Pages : 12 Date : 2004-10-25 =09 This document defines a mechanism that allows an access network to provide identity selection hints to an EAP client. The purpose is to help the client in selecting the most appropriate identity and NAI decoration to use. This solution is especially useful in roaming scenarios where the access network does not have a direct relationship with the client's home network, but instead a mediating network, such as a roaming consortium or broker, is used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery- 05.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request at ietf.org with the word unsubscribe in the body of the 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 username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-adrangi-eap-network-discovery-05.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 at ietf.org. In the body type: "FILE /internet-drafts/draft-adrangi-eap-network-discovery-05.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. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Nov 4 17:39:07 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 RAA16344 for ; Thu, 4 Nov 2004 17:39:06 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D3DA21FC6F; Thu, 4 Nov 2004 17:39:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D68861FC76; Thu, 4 Nov 2004 17:39:02 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A4E861FC76 for ; Thu, 4 Nov 2004 17:38:30 -0500 (EST) Received: from mailfe04.swip.net (mailfe04.swip.net [212.247.154.97]) by mail.frascone.com (Postfix) with ESMTP id AEF5D1FC6F for ; Thu, 4 Nov 2004 17:38:28 -0500 (EST) X-T2-Posting-ID: TlrHmwDFCX01iQZd0Fm6v3T8FBlCqve5GwI1mWaefYU= Received: from [80.170.178.166] (HELO DELL.tele2.fr) by mailfe04.swip.net (CommuniGate Pro SMTP 4.2.5) with ESMTP id 213124699; Thu, 04 Nov 2004 23:38:26 +0100 Message-Id: <5.2.1.1.0.20041104230810.01f981e8@pop.tele2.fr> X-Sender: eu968071@pop.tele2.fr X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: jari.arkko@piuha.net, "eap@frascone.com" From: Pascal Urien Subject: Re: [eap] agenda for EAP WG at IETF-61 Cc: Bernard Aboba In-Reply-To: <418A919C.20908@piuha.net> 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: Thu, 04 Nov 2004 23:38:21 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Dear Sirs, I respectfully ask a slot, at the next IETF 61 meeting, for presenting the two following drafts http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-type-00.txt Goal: present/discuss a new eap type, providing an eap in eap paradigm dedicated to smartcards, in order to avoid conflicts with purely software methods implementations http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-06.txt Goal: present/discuss actual status of this draft that defines an ISO 7816 compliant smartcard (IT free), dedicated to secure processing of EAP methods (like EAP-TLS for example). Regards Pascal Urien At 22:31 04/11/2004 +0200, Jari Arkko wrote: >Here's the preliminary agenda for our meeting at the IETF-61 >next week. Sorry for posting this late. Let us not if there's >something missing. > >WEDNESDAY, November 10, 2004 >0900-1130 Morning Sessions >Room "Military" > >1. Preliminaries (chairs), 5 min > >2. Document status (chairs), 10 min > See also http://www.drizzle.com/~aboba/EAP/eapissues.html > >3. Keying framework discussion (Bernard Aboba), 50 min > http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-keying-04.txt > Goal: Discuss the issues recently brought up on the mailing > list. > >4. State machine status update (chairs/Pasi Eronen), 5 min > http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-05.pdf > Goal: Update on the process. Discuss issues, if necessary. > >5. Authenticated service information discussion (Jari Arkko/Pasi Eronen), >15 min > >http://www.ietf.org/internet-drafts/draft-arkko-eap-service-identity-auth-01.txt > Goal: Discuss the difference of "channel binding" and "authenticated > service identity/information". > >6. Network selection update (chairs/Farid Adrangi), 5 min > >http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-05.txt > http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-netsel-problem-02.txt > Goal: Update on the process status, input from IEEE, discuss > issues if necessary. > >7. EAP PAX discussion (Charles Clancy), 15 min > http://www.ietf.org/internet-drafts/draft-clancy-eap-pax-01.txt > Goal: Present a new, radically changed version of EAP PAX. > >8. AOB > >_______________________________________________ >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 RNLDEEVYYVT@cox.net Thu Nov 4 17:56:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18805 for ; Thu, 4 Nov 2004 17:56:25 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPqmR-0001ww-NG for eap-archive@ietf.org; Thu, 04 Nov 2004 18:12:36 -0500 Received: from adsl-68-88-177-61.dsl.ltrkar.swbell.net ([68.88.177.61]) by mx2.foretec.com with smtp (Exim 4.24) id 1CPqWo-0004zR-4w for eap-archive@ietf.org; Thu, 04 Nov 2004 17:56:26 -0500 X-Message-Info: 45upJLlirF548DUhgWVX7T04WODascJcXQdpjZiq777EYZ Received: from rocketmail.com (103.176.212.28) by u83-kt477.rocketmail.com with Microsoft SMTPSVC(3.3.2950.2559); Fri, 05 Nov 2004 03:03:29 +0300 Received: from rocketmail.com (rocketmail.com 84.208.64.43) by rocketmail.com (8.12.10/8.12.9) with ESMTP id i35K917 for ; Thu, 04 Nov 2004 22:01:29 -0200 (EST) (envelope-from RNLDEEVYYVT@cox.net) Received: from P29198848821 (modemcable0.03066-457.xdl.rocketmail.com 239.37.2.86) (authenticated bits=7) by rocketmail.com (8.12.10/8.12.9) with ESMTP id n9IU1lap926 for ; Thu, 04 Nov 2004 17:06:29 -0700 (EST) (envelope-from RNLDEEVYYVT@cox.net) Message-ID: <8ie733a953$v76d48lqp96$135rti90k2@F38600935148> From: "Carson Craft" To: Subject: Get chiip prjcees on all software! Coomon now! normandy Date: Fri, 05 Nov 2004 04:05:29 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--836220302350326749" X-Spam-Score: 8.3 (++++++++) X-Spam-Flag: YES X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ----836220302350326749 Content-Type: text/html; Content-Transfer-Encoding: 7Bit TOP qualiity software:

Special Offer #1:
Windows XP Professional+Microsoft Office XP Professional = only $80
Special Offer #2:
Adobe - Photoshop 7, Premiere 7, Illustrator 10 = only $120
Special Offer #3:
Macromedia Dreamwaver MX 2004 + Flash MX 2004 = only $100

Also:
Windows 2003 Server, MS Plus, MS SQL Server 2000 Enterprise Edition,
Adobe PageMaker, Adobe Illustrator, Adobe Acrobat 6 Professional,
Macromedia Dreamwaver MX 2004, Macromedia Flash MX 2004, Macromedia Fireworks MX 2004,
and much much more!!
familiarly Don't hasitate!
mange sonata klan aldermen whore. thick blood phalarope hutchison impatient colony automata i'm locale came aldehyde. afire coolheaded linus firecracker paintbrush ussr drapery abnormal camber safeguard.
quakeress rhombi amadeus drawl. cheerleader spinnaker enthalpy anderson bethesda receptor abdicate. bob taper cactus splenetic dried rascal beet volatile potomac sake magician brenda.
tak me uff bugaboo
bourbaki compunction earthen regime tuberculosis insurrect covetous algorithmic lubricant pal unanimity uproarious o'clock. regatta bosch miss pensacola blomquist brotherhood duration. silent pull statistician parch litton luminous haulage eyebright bullfrog involuntary.
benedict determinant parabola bugaboo lore illinois doctor bose trinidad gibbon housekeep veer baxter. cam camel indefinite loop schoolmate syracuse crease adoption inattentive brighten macrophage. potable her cohort infinitesimal feeney grit solicitation shivery afro. ----836220302350326749-- From ycrayiqdielva@comcast.net Thu Nov 4 23:01:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14015; Thu, 4 Nov 2004 23:01:18 -0500 (EST) Received: from pcp08871121pcs.csouth01.va.comcast.net ([68.57.119.166]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CPvXU-0008BT-C9; Thu, 04 Nov 2004 23:17:32 -0500 Received: from pcp08871121pcs.csouth01.va.comcast.net by gateway-s.comcast.net with SMTP id rgtalxaxa; Thu, 04 Nov 2004 20:48:17 -0600 Received: from 11.144.2.69 by pcp08871121pcs.csouth01.va.comcast.net with HTTP; Thu, 04 Nov 2004 20:47:36 -0600 Content-Type: text/plain; charset=WINDOWS-1257; Date: Fri, 05 Nov 2004 01:44:17 -0100 Subject: Re: Then where is he To: "Diffserv-interest" Content-Transfer-Encoding: 7bit Message-ID: <3078354-5221713525914586@comcast.net> Mime-Version: 1.0 From: "Lupe Dahl" X-Spam-Score: 6.0 (++++++) X-Spam-Flag: YES X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit We recently received the mo r t g age application and it was appr o v ed with 3.5% ra t e. [The application is pending at this moment] If you authorize the process, please enter additional info using secure link below Continue => http://www.greatfins.com/ Thank you. Lupe Dahl Please do not reply to this mail. From vchmwuzvbvk@ds1.domainspa.com Fri Nov 5 23:32:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22903; Fri, 5 Nov 2004 23:32:08 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQIFK-0005js-3C; Fri, 05 Nov 2004 23:32:15 -0500 Received: from 202.70.199.119.iolbroadband.net ([202.70.199.119]) by mx2.foretec.com with smtp (Exim 4.24) id 1CQIFC-0008HC-OR; Fri, 05 Nov 2004 23:32:07 -0500 X-Message-Info: OENPaAJ60tEHaJu847y5+QGKYj1bIYOF Received: from mail248.pva.optusnet.com.au ([63.185.170.102]) by th49-u9.hotmail.com with Microsoft SMTPSVC(5.0.2195.6824); Sat, 06 Nov 2004 02:32:23 -0200 Received: from ZTCY71 (f200.176.72.54.xpvaj9.mqa.optusnet.com.au [99.96.148.132]) by mail509.zdp.optusnet.com.au (61.02.9s6/9.81.3) with SMTP id s2N82Ds15543; Sat, 06 Nov 2004 01:30:23 -0300 Message-ID: <26z406v5eu2j$lp6d71p9$bg5725d1@YEZH48> From: "Alberto Quintana" To: "Eap-archive" References: Subject: Attn: - B3st Buy - Pharm4 Sh0p ~ S0ftwar3s ~ C0deine ~ D3bt S0lution Fr33 Qu0t3 - Date: Fri, 05 Nov 2004 23:25:23 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--8615038595325911003" X-Spam-Score: 25.2 (+++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 79899194edc4f33a41f49410777972f8 ----8615038595325911003 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable C0deine - P4in Rel1ever http://jiuty.com/33/5/index.php?ai=3D7489&com=3D30 B3st S0luti0n 2 S0lve your D3bt http://FreeQuote.dkmbbedm.info/?IVe_KwI6fgj9xIcMortgage 0Em CDs http://OEMcds.mibhgkcb.info/?EnGdGV8yHIfxq88LowPrice B3st Ph4rm4cy Sh0p http://bestlovprice.com/in.php?aid=3D16&linkid=3DT8 ----8615038595325911003-- From citrus8@backwards.com Sat Nov 6 11:12:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18124; Sat, 6 Nov 2004 11:12:58 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQTBc-0001EU-ON; Sat, 06 Nov 2004 11:13:11 -0500 Received: from [218.65.92.175] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1CQTBN-0002e7-BN; Sat, 06 Nov 2004 11:12:54 -0500 X-Message-Info: CX91PL93Dzb781yPUhhmVYL129TND8dlbWUrIU401 Received: from montreal8anarchicmantrap (18.27.146.41) by mail4000.citrus8@backwards.com (Bluewin AG 5.8.533) id 04583DZ8ES5371CP891 for secdir@ietf.org; Sat, 06 Nov 2004 15:09:22 -0100 Message-ID: <3366623067059.11318@citrus8@backwards.com> Reply-To: "Andy Peck" From: "Andy Peck" To: "Secdir" Subject: Got Meds? We GOt EVERYtHING! Valíum, Xanax No Presciption Date: Sat, 06 Nov 2004 11:12:22 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--52752159623996972" X-Spam-Score: 10.0 (++++++++++) X-Spam-Flag: YES X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 ----52752159623996972 Content-Type: text/html; charset="iso-0826-3" Content-Description: squeeze avesta8171.earthmoving Content-Transfer-Encoding: 7Bit

Super Deal on Rx Medication
SAVE 70% on RX Medication TODAY!
Order all your RX Medication directly from our FDA-approved manufacturers.
Over 60 products to choose from! Save up to 70% on your RX drugs.
Average shipping takes 1-2 weeks but our prices and quality make it worth the wait.
All packages are shipped discreetly by Airmail WORLDWIDE.
Choose your medication, point, click, order and you're done. Your medication is on it's way! No prescription required!


N-0-M-0re
----52752159623996972-- From CAGDDSMVOXTKZZ@mindspring.com Sun Nov 7 00:44:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08146 for ; Sun, 7 Nov 2004 00:44:20 -0500 (EST) Received: from c-24-21-255-2.client.comcast.net ([24.21.255.2]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CQfqv-0007q4-1c for eap-archive@ietf.org; Sun, 07 Nov 2004 00:44:40 -0500 X-Message-Info: NPWZikrAKF505gwjSZG296OPOrndT2TDBjK28E4KTL684w7P Received: (from p208headlight@localhost) by xn31-celebes87.bk6mkd.att.net (4.00.42/9.76.06) id ffa80I3a3846; Sun, 07 Nov 2004 11:53:26 +0500 GMT X-Authentication-Warning: m82-cyanamid78.oc1j.att.net: inf9world set sender to CAGDDSMVOXTKZZ@mindspring.com using -h MIME-Version: 1.0 Date: Sun, 07 Nov 2004 04:51:26 -0200 From: Dorothy Keenan Subject: This is the bast phemma site! Cljck here to get cheip prjces! smuggle To: eamoby@ietf.org Message-Id: Content-Type: multipart/alternative; boundary="--18866278554258594702" X-Spam-Score: 10.1 (++++++++++) X-Spam-Flag: YES X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ----18866278554258594702 Content-Type: text/html; Content-Transfer-Encoding: 7Bit Hi and welcome to our phhaemeci!
Bast Phaarmeci on the web! We appreciate the time you spend while looking for
new and better phhaemeci sites over the net, so we
decided to let you know about our site, our phhaemeci.
Come on now!

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


http://eighth.azlk4xd5x.com/?wid=100183
toe arbutus paragon pyrimidine cankerworm mcneil jasper pearson pirate concede cost lobo. demented cathedra basketball embark broadside junky affirmation leatherwork aspirate remittance. chance depend gavel gape missionary daybed upkeep baltic referenda jukes they're blandish.
dragging acapulco marty blocky coleus vascular anew coach assimilable poe. dietician degrease yak sherlock plaster annuity assert wiley den. hall mot terrace sinai whir plainfield scourge suzerain caracas quiescent.
occurrent silky frothy artistry ailanthus. compulsive devout acidic mention antelope moldboard belly argue colloquy grandiose takeover softwood. wive earthshaking icosahedral figurate interpolant. lemma wholly admiralty gogh antiquarian areawide persiflage tuesday coca guillotine ontario gyrocompass clench. ----18866278554258594702-- From eap-admin@frascone.com Sun Nov 7 20:11:09 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 UAA18675 for ; Sun, 7 Nov 2004 20:11:08 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 729881FC0F; Sun, 7 Nov 2004 20:11:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BBEEF1FD47; Sun, 7 Nov 2004 20:11:02 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8E6A21FD47 for ; Sun, 7 Nov 2004 20:10:06 -0500 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by mail.frascone.com (Postfix) with ESMTP id 0FB801FC0F for ; Sun, 7 Nov 2004 20:10:02 -0500 (EST) Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.42) id 1CQy2i-000Hiy-PK for eap@frascone.com; Sun, 07 Nov 2004 20:10:00 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id iA819xw00590 for ; Sun, 7 Nov 2004 17:09:59 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] REMINDER: EAP Statemachine Positive Response Required 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, 7 Nov 2004 17:09:59 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On September 27, 2004 we announced EAP WG Last Call on the EAP State Machine document: http://mail.frascone.com/pipermail/eap/2004-September/002836.html As noted in the announcement, EAP WG Last Call ran until October 15, 2004, and required a positive response, demontrating that the document had EAP WG consensus. Since we only received negative comments on the WG Last Call request, at this point it would appear that there is not WG consensus to advance the document. To ensure that WG participants have the opportunity to comment, we will be extending the EAP WG Last Call on the EAP State Machine document until Friday, November 19, 2004. If you have read the document and feel it is ready for advancement, please send a message with "Statemachine: Advance" in the Subject line to the EAP WG mailing list, stating your reasoning. Similarly, if you have any issues with the document, please file these using the Issues format described at: http://www.drizzle.com/~aboba/EAP/eapissues.html Bernard ---------------------------------------------------------------------- Due to last minute changes in the state machine draft, we have had to remove the State Machine document from the RFC Editor's queue, and bring to EAP WG Last Call to confirm WG consensus. This is to announce EAP WG last call on the EAP State Machine draft, which will be available here: http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-05.txt http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-05.pdf EAP WG Last Call will last until Friday October 15, 2004. If you have read the draft, and believe that it is ready for forwarding to the IESG, please reply to this mail indicating your approval of the draft. If you have comments, please send them to the EAP WG mailing list (eap@frascone.com) in the format described on the EAP Issues list: http://www.drizzle.com/~aboba/EAP/eapissues.html _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Nov 7 23:53:06 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05028 for ; Sun, 7 Nov 2004 23:53:05 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 365B71FD39; Sun, 7 Nov 2004 23:53:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 65A7A1FDEC; Sun, 7 Nov 2004 23:53:03 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 04B701FDEC for ; Sun, 7 Nov 2004 23:52:13 -0500 (EST) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id 5073C1FD39 for ; Sun, 7 Nov 2004 23:52:11 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id iA84QBNw012223; Sun, 7 Nov 2004 23:26:12 -0500 (EST) From: Nick Petroni To: Cc: 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 268: SM-05 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: Sun, 7 Nov 2004 23:26:11 -0500 (EST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sorry, I hadn't seen this Issue earlier. Some comments below. > Issue 268: SM-05 Review > Submitter name: Michael Richardson > Submitter email address: mcr@sandelman.ottawa.on.ca > Date first submitted: 9/29/2004 > Reference: > Document: SM-05 > Comment type: E > Priority: S > Section: Various > Rationale/Explanation of issue > I had previous read a draft in November of 2003. > I found it difficult to read and generally pointless. First, it seems I am not sure what this means. Are these comments based on draft -01 or draft -05? > that there is little point in publishing this document. Why not just I am not sure if this comment is meant to claim there is no point in an SM document at all or if the commenter just feels the document falls short of this goal. The need for an EAP SM has been documented for some time IMHO and the creation of such a document is in the charter of this Working Group: http://www.ietf.org/html.charters/eap-charter.html > that there is little point in publishing this document. Why not just > refer to the 1X-REV diagrams, particularly given section 3.3 makes I do not understand this comment for a number of reasons, but most importantly: 1. I see no state machines reflecting EAP itself in 1X-REV. This group worked with that one to try to develop compatible state machines. The result is a common interface which is used by both documents, but I don't think you could learn how EAP is supposed to work by reading their SM's. I could be wrong. 2. 802.1X is neither the original use for EAP, nor the only place EAP is used. Pointing implementers of other protocols there would serve only to confuse IMHO. 3. EAP is defined by the IETF, not the IEEE. > it clear that anything you learn from this document is not > authoritative. This document is not intended to be authoritative, but that does not inherently make it useless. > I find that the need for section 3, tells me that there is some issue, > if one needs three pages of explanation to understand how to read the > state machines. I find this comment ironic given the emphasis above on the 1X-REV document. The majority of section 3 is copied word-for-word from 1X-REV section 8.2.1 and the notation is intentionally similar to help the readers of both documents so that the SMs can be understood together. > RFC793 section 3.2 does just fine with text, and fits it all into > fewer pages. If one is going to have big long sections like 4.1.1, On my draft section 4.1.1 is less than a page. Perhaps I am looking at the wrong section? > and in particular, redescribe the states in section 4.5, why put all the > details into the diagram? It just distracts from actual understanding of > the relationship between states. This does not seem unusual to me. First, 1X-REV uses the same technique and that draft seems to be sufficient for the commenter. Second, without state and variable descriptions, no diagram could possibly be understood. Finally, this comment provides no constructive feedback. How would you change the diagram? What should be in text and what should be in the diagram? > Neither the diagram nor the text stands alone, yet seem to repeat the > same items. I don't find this any different from any other document. I would expect to find explanations of figures in any technical document. Perhaps specific examples would help me understand. Thanks, nick _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From efljgg@chello.nl Mon Nov 8 05:35:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19553; Mon, 8 Nov 2004 05:35:56 -0500 (EST) Received: from g80219.upc-g.chello.nl ([80.57.80.219]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CR6su-0004fw-0s; Mon, 08 Nov 2004 05:36:31 -0500 Received: from mx2.foretec.com by g80219.upc-g.chello.nl with HTTP; Mon, 08 Nov 2004 03:23:10 -0600 Received: from 40.75.110.141 by smtp.chello.nl with HTTP; Mon, 08 Nov 2004 03:22:17 -0600 Mime-Version: 1.0 From: "Hung Segura" Subject: Bogdanovich had been the Message-ID: <000301c4c574$90712970$2e8c115b@FEUKK> Content-Type: text/plain; charset="WINDOWS-1257"; To: "Tricia" Content-Transfer-Encoding: 7bit Date: Mon, 08 Nov 2004 03:22:18 -0600 X-Spam-Score: 12.2 (++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Account Status: Awaiting Verification Approved: Yes Interest: 4.0 Client ID: 7950023 Above is your m o rt gage / re f i n ance information. Your info has been processed but we are waiting for you to complete our company finalization form. http://www.nelomatye.com/ Thanks, Hung Segura Account Department From gill3@Fastmail.ca Mon Nov 8 06:50:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24826; Mon, 8 Nov 2004 06:50:52 -0500 (EST) Received: from wbar24.lax1-4.29.39.93.lax1.dsl-verizon.net ([4.29.39.93]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CR83T-00065G-VP; Mon, 08 Nov 2004 06:51:28 -0500 X-Message-Info: YF6FXE390XXBzggqj7rnQNhMH26CU228mxFStkhU231 Received: from birth0tapadwyer (61.64.582.14) by mail2.gill3@Fastmail.ca (Bluewin AG 1.2.557) id 791OW01QR40411WF18 for secdir@ietf.org; Mon, 08 Nov 2004 10:50:42 -0100 Message-ID: <45003403809.32324@gill3@Fastmail.ca> Reply-To: "Kellie Foote" From: "Kellie Foote" To: "Secdir" Subject: Fwd:re:Get your med_s overníght. Date: Mon, 08 Nov 2004 04:50:42 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--0373561371108352824" X-Spam-Score: 9.1 (+++++++++) X-Spam-Flag: YES X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 ----0373561371108352824 Content-Type: text/html; charset="iso-0426-6" Content-Description: alhambra peterson3274.levin Content-Transfer-Encoding: 7Bit

Super Deal on Rx Medication

SAVE 70% on RX Medication TODAY!
• Order all your RX Medication direct from FDA-approved manufacturers.
• Over 60 products to choose from!
• Save up to 70% on your RX drugs.
• Average shipping takes 1 - 2 weeks but our prices and quality make it worth the wait.
• All packages are shipped discreetly by Airmail WORLDWIDE.
Choose your medication, point, click, order and you're done. Your medication is on it's way! No prescription required!
CLICK HERE NOW!

N-0-M-0re

----0373561371108352824-- From eap-admin@frascone.com Mon Nov 8 07:12:05 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26491 for ; Mon, 8 Nov 2004 07:12:04 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 905721FD39; Mon, 8 Nov 2004 07:12:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A0D051FE48; Mon, 8 Nov 2004 07:12:02 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7146D1FE48 for ; Mon, 8 Nov 2004 07:11:16 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 9CD9C1FD39 for ; Mon, 8 Nov 2004 07:11:14 -0500 (EST) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id D32E28987C; Mon, 8 Nov 2004 14:11:09 +0200 (EET) Message-ID: <418F61F0.7060205@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: eap@frascone.com, mcr@sandelman.ottawa.on.ca Subject: Re: [eap] Issue 268: SM-05 Review 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: Mon, 08 Nov 2004 14:09:20 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I tend to agree with Nick on this one. It is true that a major user of EAP is in 1X but at least the current documents are organized in a way where the 1X-REV and EAP-SM work together, not overlap. You could have done it in another way, having all state machines in the 1X-REV side but that is not the way that was picked, and, as Nick points out, there is value in defining EAP's behavior for everyone, not just 1X-REV. Regarding the other comments I think it would be valuable if we could go down to the specific problems, I'm sure the document could be improved if there's duplication, bad descriptions or other problems. Can you Michael help Nick to catch the ones that you noticed? Note, however, that there is some degree of effort needed in specifying and understanding semi-formal state machines like this. For instance, if we want to be precise there needs to be a definition of variables, interfaces, and procedures. I have witnessed some IETF efforts where the pain of getting such details right was too great and people gave up, in the end producing only the usual MUST/SHOULD language and no state machines at all, even if the behaviour needed under different sequences of events was relatively complicated. Having followed implementation work thereafter, I tend to think that the effort was simply pushed to implementors and resulted in long-lasting, hard to debug problems. --Jari Nick Petroni wrote: > Sorry, I hadn't seen this Issue earlier. Some comments below. > > >>Issue 268: SM-05 Review >>Submitter name: Michael Richardson >>Submitter email address: mcr@sandelman.ottawa.on.ca >>Date first submitted: 9/29/2004 >>Reference: >>Document: SM-05 >>Comment type: E >>Priority: S >>Section: Various >>Rationale/Explanation of issue > > >>I had previous read a draft in November of 2003. >>I found it difficult to read and generally pointless. First, it seems > > I am not sure what this means. Are these comments based on draft -01 or > draft -05? > > >>that there is little point in publishing this document. Why not just > > I am not sure if this comment is meant to claim there is no point in an > SM document at all or if the commenter just feels the document falls > short of this goal. The need for an EAP SM has been documented for some > time IMHO and the creation of such a document is in the charter > of this Working Group: http://www.ietf.org/html.charters/eap-charter.html > > >>that there is little point in publishing this document. Why not just >>refer to the 1X-REV diagrams, particularly given section 3.3 makes > > I do not understand this comment for a number of reasons, but most > importantly: > 1. I see no state machines reflecting EAP itself in 1X-REV. This > group worked with that one to try to develop compatible state machines. > The result is a common interface which is used by both documents, > but I don't think you could learn how EAP is supposed to work > by reading their SM's. I could be wrong. > > 2. 802.1X is neither the original use for EAP, nor > the only place EAP is used. Pointing implementers of other protocols > there would serve only to confuse IMHO. > > 3. EAP is defined by the IETF, not the IEEE. > > >>it clear that anything you learn from this document is not >>authoritative. > > This document is not intended to be authoritative, but that does not > inherently make it useless. > > >>I find that the need for section 3, tells me that there is some issue, >>if one needs three pages of explanation to understand how to read the >>state machines. > > I find this comment ironic given the emphasis above on the 1X-REV > document. The majority of section 3 is copied word-for-word from 1X-REV > section 8.2.1 and the notation is intentionally similar to help the > readers of both documents so that the SMs can be understood together. > > >>RFC793 section 3.2 does just fine with text, and fits it all into >>fewer pages. If one is going to have big long sections like 4.1.1, > > On my draft section 4.1.1 is less than a page. Perhaps I am looking at > the wrong section? > > >>and in particular, redescribe the states in section 4.5, why put all the >>details into the diagram? It just distracts from actual understanding of >>the relationship between states. > > This does not seem unusual to me. First, 1X-REV uses the same technique > and that draft seems to be sufficient for the commenter. Second, without > state and variable descriptions, no diagram could possibly be understood. > Finally, this comment provides no constructive feedback. How would you > change the diagram? What should be in text and what should be in the > diagram? > > >>Neither the diagram nor the text stands alone, yet seem to repeat the >>same items. > > I don't find this any different from any other document. I would expect > to find explanations of figures in any technical document. Perhaps > specific examples would help me understand. > > Thanks, > nick > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Nov 8 13:11:07 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 NAA08209 for ; Mon, 8 Nov 2004 13:11:05 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DF45C1FE58; Mon, 8 Nov 2004 13:11:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 260891FDEC; Mon, 8 Nov 2004 13:11:03 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 26DB51FDEC for ; Mon, 8 Nov 2004 13:10:06 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 0A1D21FD70 for ; Mon, 8 Nov 2004 13:10:04 -0500 (EST) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 13E828988A; Mon, 8 Nov 2004 20:10:01 +0200 (EET) Message-ID: <418FB60D.6020701@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: "Bari, Farooq" Cc: "Adrangi, Farid" , eap@frascone.com, Bernard Aboba Subject: Re: [eap] draft-adrangi-eap-network-discovery-05.txt 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: Mon, 08 Nov 2004 20:08:13 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I think so. Its still showing up in the issue list, but that just means that the list needs an update. My understanding is that the "pseudo WG last call" has completed successfully and that we are now ready give this draft to the IESG. --Jari Bari, Farooq wrote: > This draft now includes Jari's proposed textl on issue 256. There were > no other comments or disagreements to his proposal on this issue (and > this is the only issue open for the draft in the issue list). Is my > understanding correct that the issue 256 is now resolved completely? > > BR, > > Farooq > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] On Behalf > Of Adrangi, Farid > Sent: Wednesday, November 03, 2004 11:00 AM > To: eap@frascone.com > Subject: [eap] draft-adrangi-eap-network-discovery-05.txt > > It seems that this announcement never appeared on eap mailing list -- at > least some of us didn't see it. So here it is. This version addresses > the issue 256 as per discussion on the list. > BR, > Farid > > 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-05.txt > Pages : 12 > Date : 2004-10-25 > > This document defines a mechanism that allows an access network to > provide identity selection hints to an EAP client. The purpose is to > help the client in selecting the most appropriate identity and NAI > decoration to use. This solution is especially useful in roaming > scenarios where the access network does not have a direct > relationship with the client's home network, but instead a mediating > network, such as a roaming consortium or broker, is used. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery- > 05.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request at ietf.org with the word unsubscribe in the body > of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-adrangi-eap-network-discovery-05.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv at ietf.org. > In the body type: > "FILE > /internet-drafts/draft-adrangi-eap-network-discovery-05.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > 05.txt> > _______________________________________________ > 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 network.rockabye@owingsfin.com Mon Nov 8 13:58:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13340; Mon, 8 Nov 2004 13:58:48 -0500 (EST) Message-Id: <200411081858.NAA13340@ietf.org> Received: from atoulouse-152-1-5-123.w82-125.abo.wanadoo.fr ([82.125.3.123]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CREjR-0001ia-WF; Mon, 08 Nov 2004 13:59:27 -0500 Received: from antipathy5beauxconakry (84.24.160.24) by mail05.oritech.com (estimatecardioid EH 7.6.197) id 87IM01TL87AWV70300 for eap-archive@ietf.org; Mon, 08 Nov 2004 21:54:04 +0400 X-MIME-Autoconverted: Yes Disclose-Recipients: No Discarded-X400-MTS-Extensions: Yes Alternate-Recipient: Allowed X-No-Archive: Yes Reply-To: "Faye Lucero" From: "Faye Lucero" To: eap-archive@ietf.org Cc: tsvwg-request@ietf.org, usic-admin@ietf.org, policy@ietf.org, vrrp@ietf.org, ietf@ietf.org, mailman-owner@ietf.org, sip-security@ietf.org Subject: Your account has been created Date: Mon, 08 Nov 2004 19:47:04 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--65828185894800509" X-Spam-Score: 1.2 (+) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 ----65828185894800509 Content-Type: text/html; charset="iso-6516-4" Content-Transfer-Encoding: 7Bit As you know election time is not the best thing for the economy.
Economy is in a very unstable condition, as you can see gas prices
are going up along with the mo[r]tgage rat[e}s. Once the
{r)ate goes up you will not have a chance to s_ave money
again for a very long time.

It is your last chance. Get [ref}inanced at 2.2 %!
http://ecoquote.com/?partid=rm2342

We look forward to hearing from you.

Regards,

Faye Lucero, Client Account Manager
Terrigon Association
2207 Dewey Avenue
Columbus, OH 43085 ----65828185894800509-- From network.rockabye@owingsfin.com Mon Nov 8 13:59:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13655; Mon, 8 Nov 2004 13:59:17 -0500 (EST) Message-Id: <200411081859.NAA13655@ietf.org> Received: from cm102158.red.mundo-r.com ([213.60.102.158]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CREk7-0001mo-Ek; Mon, 08 Nov 2004 13:59:56 -0500 Received: from antipathy5beauxconakry (84.24.160.24) by mail05.oritech.com (estimatecardioid EH 7.6.197) id 87IM01TL87AWV70300 for eap-archive@ietf.org; Mon, 08 Nov 2004 21:54:04 +0400 X-MIME-Autoconverted: Yes Disclose-Recipients: No Discarded-X400-MTS-Extensions: Yes Alternate-Recipient: Allowed X-No-Archive: Yes Reply-To: "Faye Lucero" From: "Faye Lucero" To: eap-archive@ietf.org Cc: tsvwg-request@ietf.org, usic-admin@ietf.org, policy@ietf.org, vrrp@ietf.org, ietf@ietf.org, mailman-owner@ietf.org, sip-security@ietf.org Subject: Your account has been created Date: Mon, 08 Nov 2004 19:47:04 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--65828185894800509" X-Spam-Score: 4.6 (++++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 ----65828185894800509 Content-Type: text/html; charset="iso-6516-4" Content-Transfer-Encoding: 7Bit As you know election time is not the best thing for the economy.
Economy is in a very unstable condition, as you can see gas prices
are going up along with the mo[r]tgage rat[e}s. Once the
{r)ate goes up you will not have a chance to s_ave money
again for a very long time.

It is your last chance. Get [ref}inanced at 2.2 %!
http://ecoquote.com/?partid=rm2342

We look forward to hearing from you.

Regards,

Faye Lucero, Client Account Manager
Terrigon Association
2207 Dewey Avenue
Columbus, OH 43085 ----65828185894800509-- From xtzyecswf@msn.com Mon Nov 8 15:44:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28601; Mon, 8 Nov 2004 15:44:46 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRGOD-00054v-DD; Mon, 08 Nov 2004 15:45:26 -0500 Received: from ip-231.net-80-236-79.issy.rev.numericable.fr ([80.236.79.231]) by mx2.foretec.com with smtp (Exim 4.24) id 1CRGNN-0008I3-9L; Mon, 08 Nov 2004 15:44:36 -0500 Received: from 72.111.101.128 by 80.236.79.231; Tue, 09 Nov 2004 02:47:06 +0600 From: "Norman Goldman" Reply-To: "Norman Goldman" To: eap-archive@ietf.org, edu-team@ietf.org, edu-team-web-archive@ietf.org, entmib@ietf.org, entmib-admin@ietf.org Subject: SU-per Hu^ge 0ffers Eap-archive Antivirus: No virus found bambi Date: Tue, 09 Nov 2004 01:41:06 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--896095907768731808" Message-Id: X-Spam-Score: 1.2 (+) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 ----896095907768731808 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit The L0west price of all med's is here. *Xa-nax ($79 only) *Via-gra ($69 only) *Va|ium ($59 only) *Cia-|is ($89 only) *Tramadol ($99 only) We are the be-st available nowadays http://www.locate-up-timez.info/?wid=ronn this is 1 ti-me mai-ling. no ree movee re-quire: ssJkCPoq2is8YujcMC9A1ZCtERttx1Oau7c5W1S ----896095907768731808-- From eap-admin@frascone.com Mon Nov 8 16:30:08 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 QAA03901 for ; Mon, 8 Nov 2004 16:30:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 30F6C1FD70; Mon, 8 Nov 2004 16:30:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 61C8B1FE48; Mon, 8 Nov 2004 16:30:03 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4E3011FE48 for ; Mon, 8 Nov 2004 16:29:48 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 7E1201FD70 for ; Mon, 8 Nov 2004 16:29:46 -0500 (EST) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 29CBC8988A; Mon, 8 Nov 2004 23:29:42 +0200 (EET) Message-ID: <418FE4D9.1050101@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: Bernard Aboba References: <418A919C.20908@piuha.net> In-Reply-To: <418A919C.20908@piuha.net> 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] agenda for EAP WG at IETF-61, take two 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, 08 Nov 2004 23:27:53 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit WEDNESDAY, November 10, 2004 0900-1130 Morning Sessions Room "Military" 1. Preliminaries (chairs), 5 min 2. Document status (chairs), 10 min See also http://www.drizzle.com/~aboba/EAP/eapissues.html 3. Keying framework discussion (Bernard Aboba), 50 min http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-keying-04.txt Goal: Discuss the issues recently brought up on the mailing list. 4. State machine status update (chairs/Pasi Eronen), 5 min http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-05.pdf Goal: Update on the process. Discuss issues, if necessary. 5. Authenticated service information discussion (Jari Arkko/Pasi Eronen), 15 min http://www.ietf.org/internet-drafts/draft-arkko-eap-service-identity-auth-01.txt Goal: Discuss the difference of "channel binding" and "authenticated service identity/information". 6. Network selection update (chairs/Farid Adrangi), 5 min http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-05.txt http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-netsel-problem-02.txt Goal: Update on the process status, input from IEEE, discuss issues if necessary. 7. EAP PAX discussion (Charles Clancy), 15 min http://www.ietf.org/internet-drafts/draft-clancy-eap-pax-01.txt Goal: Present a new, radically changed version of EAP PAX. 8. EAP Smart card presentation (Pascal Urien) http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-type-00.txt http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-06.txt Goal: present/discuss a new eap type, providing an eap in eap paradigm dedicated to smartcards 9. AOB _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Nov 9 10:41:08 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 KAA10860 for ; Tue, 9 Nov 2004 10:41:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 990FF1FD3F; Tue, 9 Nov 2004 10:41:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E6F8B1FC6C; Tue, 9 Nov 2004 10:41:02 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BC2981FC6C for ; Tue, 9 Nov 2004 10:40:10 -0500 (EST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mail.frascone.com (Postfix) with ESMTP id 59BD91FC68 for ; Tue, 9 Nov 2004 10:40:07 -0500 (EST) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA9Fe4E15850 for ; Tue, 9 Nov 2004 17:40:04 +0200 (EET) X-Scanned: Tue, 9 Nov 2004 17:38:45 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id iA9FcjfQ012906 for ; Tue, 9 Nov 2004 17:38:45 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00umpknU; Tue, 09 Nov 2004 17:38:44 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA9FbTa18817 for ; Tue, 9 Nov 2004 17:37:29 +0200 (EET) Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 9 Nov 2004 17:37:29 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 9 Nov 2004 17:37:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <125EA890549C8641A72F3809CB80DCCD16FDAD@esebe056.ntc.nokia.com> Thread-Topic: [eap] REMINDER: EAP Statemachine Positive Response Required Thread-Index: AcTFNmbsYwOP3WL3SvK4jEIHb3VXmQBO24Bw From: To: X-OriginalArrivalTime: 09 Nov 2004 15:37:29.0234 (UTC) FILETIME=[0565B720:01C4C672] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Statemachine: Advance 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, 9 Nov 2004 17:37:28 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable I'm one of the authors, so I have actually read the document=20 and support advancing it :-) Best regards, Pasi _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Nov 9 11:50:06 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18799 for ; Tue, 9 Nov 2004 11:50:05 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F32221FD40; Tue, 9 Nov 2004 11:50:05 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 87DB31FC6C; Tue, 9 Nov 2004 11:50:02 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 23AD51FC6C for ; Tue, 9 Nov 2004 11:49:04 -0500 (EST) Received: from reformers.mr.itd.umich.edu (reformers.mr.itd.umich.edu [141.211.93.147]) by mail.frascone.com (Postfix) with ESMTP id 889F51FC68 for ; Tue, 9 Nov 2004 11:49:02 -0500 (EST) Received: from [198.108.60.201] (dhcp60-201.merit.edu [198.108.60.201]) by reformers.mr.itd.umich.edu (smtp) with ESMTP id iA9Gn0e5029633; Tue, 9 Nov 2004 11:49:00 -0500 In-Reply-To: <125EA890549C8641A72F3809CB80DCCD16FDAD@esebe056.ntc.nokia.com> References: <125EA890549C8641A72F3809CB80DCCD16FDAD@esebe056.ntc.nokia.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <41B657F7-326F-11D9-AFEC-000393D92DF8@umich.edu> Content-Transfer-Encoding: 7bit Cc: , John Vollbrecht From: John Vollbrecht Subject: Re: [eap] Statemachine: Advance To: X-Mailer: Apple Mail (2.619) 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, 9 Nov 2004 11:49:00 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I also am an author and support advancing it. -- John On Nov 9, 2004, at 10:37 AM, wrote: > I'm one of the authors, so I have actually read the document > and support advancing it :-) > > Best regards, > Pasi > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Nov 9 13:57:13 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00769 for ; Tue, 9 Nov 2004 13:57:12 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F1FBB1FC6E; Tue, 9 Nov 2004 13:57:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 48ACF1FCB8; Tue, 9 Nov 2004 13:57:03 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id ECBAA1FCB8 for ; Tue, 9 Nov 2004 13:56:18 -0500 (EST) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by mail.frascone.com (Postfix) with ESMTP id 01DB91FC6E for ; Tue, 9 Nov 2004 13:56:16 -0500 (EST) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id iA9IuDUD011975; Wed, 10 Nov 2004 03:56:13 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id iA9IuDbO020847; Wed, 10 Nov 2004 03:56:13 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id DAA20846 ; Wed, 10 Nov 2004 03:56:13 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id DAA08068; Wed, 10 Nov 2004 03:56:13 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id iA9IuDSY020858; Wed, 10 Nov 2004 03:56:13 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id iA9IuCuY010025; Wed, 10 Nov 2004 03:56:12 +0900 (JST) Received: from steelhead (iVPN01-069.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0I6X005IADXLPI@tsbpo1.po.toshiba.co.jp>; Wed, 10 Nov 2004 03:56:11 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1CRZHK-00022Q-00; Tue, 09 Nov 2004 08:55:34 -0800 From: Yoshihiro Ohba Subject: Re: [eap] Statemachine: Advance In-reply-to: <125EA890549C8641A72F3809CB80DCCD16FDAD@esebe056.ntc.nokia.com> To: Pasi.Eronen@nokia.com Cc: eap@frascone.com Message-id: <20041109165534.GN2826@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.6+20040907i References: <125EA890549C8641A72F3809CB80DCCD16FDAD@esebe056.ntc.nokia.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, 09 Nov 2004 11:55:34 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) I'm one of the authors, too. Also, I implemented this state machine in Open Diameter EAP library. I support advancing it. Best regards, Yoshihiro Ohba On Tue, Nov 09, 2004 at 05:37:28PM +0200, Pasi.Eronen@nokia.com wrote: > I'm one of the authors, so I have actually read the document > and support advancing it :-) > > Best regards, > Pasi > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Nov 9 21:33:08 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 VAA12573 for ; Tue, 9 Nov 2004 21:33:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 953911FC6C; Tue, 9 Nov 2004 21:33:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9A2D01FC76; Tue, 9 Nov 2004 21:33:03 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8B87D1FC76 for ; Tue, 9 Nov 2004 21:32:46 -0500 (EST) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id 454C51FC6C for ; Tue, 9 Nov 2004 21:32:43 -0500 (EST) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 09 Nov 2004 18:44:25 -0800 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 iAA2Weom004749 for ; Tue, 9 Nov 2004 18:32:41 -0800 (PST) Received: from jsaloweyw2k01 ([10.82.218.126]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 9 Nov 2004 18:34:28 -0800 From: "Joseph Salowey" To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0089_01C4C68A.7DD0A9F0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcTGzYtklJA2Jf8KTAS+rDLVsYxNOg== Message-ID: X-OriginalArrivalTime: 10 Nov 2004 02:34:28.0964 (UTC) FILETIME=[CD632A40:01C4C6CD] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] [Issue 277] key draft re-organization strawman 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, 9 Nov 2004 18:32:38 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------=_NextPart_000_0089_01C4C68A.7DD0A9F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Attached is a strawman for a reorganization of the keying draft. This only covers the initial section about general requirements associated with EAP and keying. Joe ------=_NextPart_000_0089_01C4C68A.7DD0A9F0 Content-Type: text/plain; name="eap-key.txt" Content-Disposition: attachment; filename="eap-key.txt" Content-Transfer-Encoding: quoted-printable Network Working Group J. Salowey Internet-Draft Cisco Systems Expires: May 10, 2005 November 9, 2004 EAP Method Keying Requirements draft-jsalowey-eap-key Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 10, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This memo defines requirements for the keying material exported from EAP methods. It contains recommendations for key generation, key export, key naming, key derivation for applications and key lifecycle management. Salowey Expires May 10, 2005 [Page 1] =0C Internet-Draft EAP Method Keying Requirements November 2004 Table of Contents 1. Expected behavior of EAP Methods and Frameworks . . . . . . . 3 1.1 Generation of key material . . . . . . . . . . . . . . . . 3 1.2 Exported Key Material . . . . . . . . . . . . . . . . . . 3 1.3 AMSK Derivation . . . . . . . . . . . . . . . . . . . . . 4 1.3.1 Key Derivation Function . . . . . . . . . . . . . . . 4 1.3.2 HMAC-SHA1 derivation . . . . . . . . . . . . . . . . . 4 1.4 Naming and Identification . . . . . . . . . . . . . . . . 5 1.5 Key Lifetime . . . . . . . . . . . . . . . . . . . . . . . 6 1.6 Key Request Considerations . . . . . . . . . . . . . . . . 6 2. Security Considerations . . . . . . . . . . . . . . . . . . . 6 3. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6 Intellectual Property and Copyright Statements . . . . . . . . 7 Salowey Expires May 10, 2005 [Page 2] =0C Internet-Draft EAP Method Keying Requirements November 2004 1. Expected behavior of EAP Methods and Frameworks This section defines the external behavior of and EAP method and framework. RFC 3748 [RFC3748] specifies that EAP methods may generate and export key material. This document defines requirements expectations around how the key material is derived and how its use is coordinated between different consumers. 1.1 Generation of key material RFC 3748 [RFC3748] requires that EAP methods that generate keys MUST generate two quantities at least 64 bytes in length called the MSK and the EMSK. In addition to the requirements defined in RFC 3748 this document specifies some additional requirements for the generation of keying material: o If a method specification does not define the length of these quantities it MUST generate and EMSK and an MSK of 64 bytes. If a method specification supports other key lengths then it MUST ensure that both the EAP peer and EAP server derive keys of the same length. o It MUST be computationally infeasible to derive keys used internally to the EAP method from the MSK or the EMSK. o It MUST be computationally infeasible to derive the MSK from the EMSK or vice versa. 1.2 Exported Key Material EAP methods export two types of keying material; the MSK and the EMSK. The MSK has traditionally been used to derive the AAA-Key which has been used in lower layer cryptographic data protection. This document updates RFC 3748 and specifies a way that EMSK and MSK usage can be coordinated. Requirements on the usage of the MSK and EMSK are listed below. o The EMSK MSUT be maintained within the EAP server. Only keys (AMSKs) derived according to this specification may be exported from the EAP server. o The application MAY use the MSK transmitted to the NAS in any way it chooses. This is required for backward compatibility. New applications following this specification SHOULD NOT use the MSK. If more than one application uses the MSK, then the cryptographic separation is not achieved. Implementations SHOULD prevent such combinations. Salowey Expires May 10, 2005 [Page 3] =0C o The application or EAP Server MUST NOT use the EMSK in any other way except to derive Application Master Session Keys (AMSK) using the key derivation specified in section 3 this document. It MUST NOT use the EMSK directly. o Applications MUST define distinct key labels and application specific data used in the key derivation described in section 3. o Applications MUST define how they use their AMSK to derive TSKs for their use. 1.3 AMSK Derivation Application master session keys (AMSK) are derived from the EMSK for use in different applications. Since it is possible that more than one application will require key material it is necessary to coordinate the derivation of key material from the EMSK. A EAP method MAY specify a key derivation function for use in deriving keys. If a method does not specify a key derivation function then it MUST use HMAC-SHA1 derivation specified in this document. If an EAP method specifies a different KDF then it must be selected from the list of EAP key derivation algorithms maintained by the IANA registry specified in this document. 1.3.1 Key Derivation Function The EAP EMSK usage guidelines AMSK key derivation function (KDF) derives an AMSK from the Extended Master Session Key (EMSK) described above, an application key label, optional application data, and output length. AMSK =3D KDF(EMSK, key label, optional application data, length) The key labels are printable ASCII strings unique for each application (see Section 5 for IANA Considerations). Additional ciphering keys (TSKs) can be derived from the AMSK using an application specific key derivation mechanism. In many cases, this AMSK toTSK derivation can simply split the AMSK to pieces of correct length. In particular, it is not necessary to use a cryptographic one-way function. Note that the length of the AMSK must be specified by the application. 1.3.2 HMAC-SHA1 derivation The EAP key derivation function is taken from the PRF+ key expansion PRF from [IKEv2]. This KDF takes 4 parameters as input: secret, label, application data, and output length. It is only defined for 255 iterations so it may produce up to 5100 bytes of key material. Salowey Expires May 10, 2005 [Page 4] =0C Internet-Draft EAP Method Keying Requirements November 2004 For the purposes of this specification the secret is taken as the EMSK, the label is the key label described above concatenated with a NUL byte, the application data is also described above and the output length is two bytes. The application data is optional and may not be used by some applications. The KDF is based on HMAC-SHA1 [RFC2104] [SHA1]. For this specification we have: KDF (K,L,D,O) =3D T1 | T2 | T3 | T4 | ... where: T1 =3D prf (K, S | 0x01) T2 =3D prf (K, T1 | S | 0x02) T3 =3D prf (K, T2 | S | 0x03) T4 =3D prf (K, T3 | S | 0x04) prf =3D HMAC-SHA1 K =3D EMSK L =3D key label D =3D application data O =3D OutputLength (2 bytes) S =3D L | "\0" | D | O The prf+ construction was chosen because of its simplicity and efficiency over other PRFs such as those used in [TLS]. The motivation for the design of this PRF is described in [SIGMA]. The NUL byte after the key label is used to avoid collisions if one key label is a prefix of another label (e.g. "foobar" and "foobarExtendedV2"). This is considered a simpler solution than requiring a key label assignment policy that prevents prefixes from occurring. 1.4 Naming and Identification EAP methods MUST provide a means to identify a particular instance of an execution of the method. To do this an EAP method should export a method identifier. This identifier consists of 8 bytes that identify the EAP method followed by 20 bytes which are extracted from the EAP method operation which uniquely identify the instance of the method. It is RECOMMENDED that this quantity be derived from the following values where they are available: EAP peer name, EAP server name, and nonces exchanged during the method execution. The name must not reveal any secret information internal to the EAP method or any information that could lead to the disclosure of the MSK or EMSK. Names for the MSK and AMSK SHOULD be derived from this name. Salowey Expires May 10, 2005 [Page 5] =0C Internet-Draft EAP Method Keying Requirements November 2004 1.5 Key Lifetime The MSK SHOULD be deleted after it is transported out of the EAP server. The EMSK SHOULD be deleted after all required AMSKs are derived from it. Ideally, the requsts for AMSKs SHOULD occur simultaneously with the completion of the EAP method. In cases where this is not possible the request should be made shortly after the completion of the EAP method as possible. 1.6 Key Request Considerations 2. Security Considerations 3 References [RFC3748] "". Author's Address Joseph Salowey Cisco Systems 2901 3rd Ave Seattle, WA 98121 US EMail: jsalowey@cisco.com Salowey Expires May 10, 2005 [Page 6] =0C Internet-Draft EAP Method Keying Requirements November 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Salowey Expires May 10, 2005 [Page 7] =0C ------=_NextPart_000_0089_01C4C68A.7DD0A9F0 Content-Type: text/xml; name="eap-key.xml" Content-Disposition: attachment; filename="eap-key.xml" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= EAP Method Keying Requirements=0A= =0A= =0A= Cisco Systems =0A=

=0A= =0A= 2901 3rd Ave =0A= Seattle =0A= US=0A= 98121=0A= WA =0A= =0A= jsalowey@cisco.com =0A=
=0A= =0A= =0A= =0A= Network Working Group =0A= I-D=0A= Internet-Draft=0A= =0A= This memo defines requirements for the keying material = exported from EAP methods. It contains recommendations for key = generation, key export, key naming, key derivation for applications and = key lifecycle management. =0A= =0A= =0A=
=0A= This section defines the external behavior of and EAP method and = framework. RFC 3748 specifies that EAP = methods may generate and export key material. This document defines = requirements expectations around how the key material is derived and how = its use is coordinated between different consumers. =0A= =0A=
=0A= RFC 3748 requires that EAP methods = that generate keys MUST generate two quantities at least 64 bytes in = length called the MSK and the EMSK. In addition to the requirements = defined in RFC 3748 this document specifies some additional requirements = for the generation of keying material:=0A= =0A= =0A= =0A= If a method specification does not define the length of these quantities = it MUST generate and EMSK and an MSK of 64 bytes. If a method = specification supports other key lengths then it MUST ensure that both = the EAP peer and EAP server derive keys of the same length. =0A= =0A= =0A= =0A= It MUST be computationally infeasible to derive keys used internally to = the EAP method from the MSK or the EMSK.=0A= =0A= =0A= It MUST be computationally infeasible to derive the MSK from the EMSK or = vice versa.=0A= =0A= =0A= =0A=
=0A=
=0A= EAP methods export two types of keying material; the MSK and the = EMSK. The MSK has traditionally been used to derive the AAA-Key which = has been used in lower layer cryptographic data protection. This = document updates RFC 3748 and specifies a way that EMSK and MSK usage = can be coordinated. Requirements on the usage of the MSK and EMSK are = listed below.=0A= =0A= =0A= The EMSK MSUT be maintained within the EAP server. Only keys = (AMSKs) derived according to this specification may be exported from the = EAP server. =0A= =0A= =0A= The application MAY use the MSK transmitted to the NAS in any way it = chooses. This is required for backward compatibility. New applications = following this specification SHOULD NOT use the MSK. If more than one = application uses the MSK, then the cryptographic separation is not = achieved. Implementations SHOULD prevent such combinations. =0A= =0A= The application or EAP Server MUST NOT use the EMSK in any other way = except to derive Application Master Session Keys (AMSK) using the key = derivation specified in section 3 this document. It MUST NOT use the = EMSK directly. =0A= =0A= Applications MUST define distinct key labels and application = specific data used in the key derivation described in section 3. =0A= =0A= =0A= Applications MUST define how they use their AMSK to derive TSKs = for their use.=0A= =0A= =0A=
=0A=
=0A= Application master session keys (AMSK) are derived from the EMSK for = use in different applications. Since it is possible that more than one = application will require key material it is necessary to coordinate the = derivation of key material from the EMSK. A EAP method MAY specify a = key derivation function for use in deriving keys. If a method does not = specify a key derivation function then it MUST use HMAC-SHA1 derivation = specified in this document. If an EAP method specifies a different KDF = then it must be selected from the list of EAP key derivation algorithms = maintained by the IANA registry specified in this document. =0A=
=0A= =0A= The EAP EMSK usage guidelines AMSK key derivation function (KDF) =0A= derives an AMSK from the Extended Master Session Key (EMSK) described =0A= above, an application key label, optional application data, and =0A= output length. =0A= =0A= =0A= AMSK =3D KDF(EMSK, key label, optional application data, length) = =0A= =0A= =0A= =0A= =0A= The key labels are printable ASCII strings unique for each =0A= application (see Section 5 for IANA Considerations). =0A= =0A= =0A= Additional ciphering keys (TSKs) can be derived from the AMSK using =0A= an application specific key derivation mechanism. In many cases, this =0A= AMSK toTSK derivation can simply split the AMSK to pieces of correct =0A= length. In particular, it is not necessary to use a cryptographic =0A= one-way function. Note that the length of the AMSK must be specified =0A= by the application. =0A= =0A= =0A=
=0A=
=0A= The EAP key derivation function is taken from the PRF+ key = expansion =0A= PRF from [IKEv2]. This KDF takes 4 parameters as input: secret, =0A= label, application data, and output length. It is only defined for =0A= 255 iterations so it may produce up to 5100 bytes of key material. =0A= =0A= =0A= For the purposes of this specification the secret is taken as the =0A= EMSK, the label is the key label described above concatenated with a =0A= NUL byte, the application data is also described above and the output =0A= length is two bytes. The application data is optional and may not be =0A= used by some applications. The KDF is based on HMAC-SHA1 [RFC2104] =0A= [SHA1]. For this specification we have: =0A= =0A= =0A=
=0A= =0A= KDF (K,L,D,O) =3D T1 | T2 | T3 | T4 | ... =0A= =0A= =0A= where: =0A= T1 =3D prf (K, S | 0x01) =0A= T2 =3D prf (K, T1 | S | 0x02) =0A= T3 =3D prf (K, T2 | S | 0x03) =0A= T4 =3D prf (K, T3 | S | 0x04) =0A= =0A= prf =3D HMAC-SHA1 =0A= K =3D EMSK =0A= L =3D key label =0A= D =3D application data =0A= O =3D OutputLength (2 bytes) =0A= S =3D L | "\0" | D | O =0A= =0A= =0A=
=0A= =0A= The prf+ construction was chosen because of its simplicity and =0A= efficiency over other PRFs such as those used in [TLS]. The =0A= motivation for the design of this PRF is described in [SIGMA]. =0A= =0A= The NUL byte after the key label is used to avoid collisions if one =0A= key label is a prefix of another label (e.g. "foobar" and =0A= "foobarExtendedV2"). This is considered a simpler solution than =0A= requiring a key label assignment policy that prevents prefixes from =0A= occurring. =0A= =0A=
=0A=
=0A=
=0A= =0A= EAP methods MUST provide a means to identify a particular instance of an = execution of the method. To do this an EAP method should export a = method identifier. This identifier consists of 8 bytes that identify = the EAP method followed by 20 bytes which are extracted from the EAP = method operation which uniquely identify the instance of the method. It = is RECOMMENDED that this quantity be derived from the following values = where they are available: EAP peer name, EAP server name, and nonces = exchanged during the method execution. The name must not reveal any = secret information internal to the EAP method or any information that = could lead to the disclosure of the MSK or EMSK. Names for the MSK and = AMSK SHOULD be derived from this name.=0A= =0A= =0A=
=0A=
=0A= The MSK SHOULD be deleted after it is transported out of the EAP = server. The EMSK SHOULD be deleted after all required AMSKs are derived = from it. Ideally, the requsts for AMSKs SHOULD occur simultaneously = with the completion of the EAP method. In cases where this is not = possible the request should be made shortly after the completion of the = EAP method as possible.=0A=
=0A=
=0A= =0A=
=0A=
=0A=
=0A=
=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= ------=_NextPart_000_0089_01C4C68A.7DD0A9F0-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Nov 9 23:53:05 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23398 for ; Tue, 9 Nov 2004 23:53:05 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1E8511FE90; Tue, 9 Nov 2004 23:53:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BD2091FD54; Tue, 9 Nov 2004 23:53:02 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4C0641FD54 for ; Tue, 9 Nov 2004 23:52:23 -0500 (EST) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id 5996E1FC76 for ; Tue, 9 Nov 2004 23:52:21 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id iAA4h6Nw006561; Tue, 9 Nov 2004 23:43:06 -0500 (EST) From: Nick Petroni To: Yoshihiro Ohba Cc: Subject: Re: [eap] Statemachine: Advance In-Reply-To: <20041109165534.GN2826@steelhead> 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: Tue, 9 Nov 2004 23:43:06 -0500 (EST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) I also support advancing it. I guess that means all of the authors are on board ;) best, nick Nick L. Petroni, Jr. Graduate Student, Computer Science Maryland Information Systems Security Lab University of Maryland http://www.cs.umd.edu/~npetroni On Tue, 9 Nov 2004, Yoshihiro Ohba wrote: > I'm one of the authors, too. Also, I implemented this state machine > in Open Diameter EAP library. I support advancing it. > > Best regards, > Yoshihiro Ohba > > > On Tue, Nov 09, 2004 at 05:37:28PM +0200, Pasi.Eronen@nokia.com wrote: > > I'm one of the authors, so I have actually read the document > > and support advancing it :-) > > > > Best regards, > > Pasi > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 10 01:40:07 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 BAA00329 for ; Wed, 10 Nov 2004 01:40:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DAB711FC73; Wed, 10 Nov 2004 01:40:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0C09E1FC76; Wed, 10 Nov 2004 01:40:03 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E31B31FC76 for ; Wed, 10 Nov 2004 01:39:03 -0500 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by mail.frascone.com (Postfix) with ESMTP id 67F821FC73 for ; Wed, 10 Nov 2004 01:39:01 -0500 (EST) Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.42) id 1CRm8C-000BEa-RQ for eap@frascone.com; Wed, 10 Nov 2004 01:39:00 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id iAA6csi17394 for ; Tue, 9 Nov 2004 22:38:54 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Slides, please 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, 9 Nov 2004 22:38:54 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) If you are presenting at the EAP WG meeting tommorrow morning, please send the slides to me. They will be made available here: http://www.drizzle.com/~aboba/EAP/IETF61/ BTW, the EAP Issues list is now updated with a summary of the open and resolved issues: http://www.drizzle.com/~aboba/EAP/eapissues.html _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From Huseyin-East@ibelgique.com Wed Nov 10 03:16:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06805; Wed, 10 Nov 2004 03:16:12 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRnfB-0003Pg-65; Wed, 10 Nov 2004 03:17:11 -0500 Received: from [211.213.64.12] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1CRne4-0003oB-HS; Wed, 10 Nov 2004 03:16:01 -0500 Received: from mail.habergroup.com (211.213.64.12) by 211.213.64.12 (approachv.37) with SMTP id <9034456w9d> (Authid: 8512); Wed, 10 Nov 2004 04:16:55 -0300 X-Message-Info: 2293483h Reply-To: "Auriol Hannerl" From: "Auriol Hannerl" To: r-wg-admin@ietf.org Cc: seamoby@ietf.org, rpr@ietf.org, er-wgchairs@ietf.org, eap-archive@ietf.org, owner-wgchairs@ietf.org, urn-archive@ietf.org, nemo-request@ietf.org Subject: Receive $159411 Date: Wed, 10 Nov 2004 05:16:55 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--980625800101246696" Message-Id: X-Spam-Score: 7.9 (+++++++) X-Spam-Flag: YES X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab ----980625800101246696 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7Bit Dear Applicant, Your application was processed and approved. You are eligible for $ 400,000 with a 2.1 % rate. Please verify your information here: http://www.bellmarketing4us.com/green/m79a We look forward to hearing from you. Auriol Hannerl, Account Manager Bell Marketing 4206 Central Avenue Columbus, OH 43085 not interested -> http://www.bellmarketing4us.com/green/stop.html ----980625800101246696-- From qpsulrjkhucr@dsl-verizon.net Wed Nov 10 03:56:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11325; Wed, 10 Nov 2004 03:56:14 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRoHw-0004MW-7k; Wed, 10 Nov 2004 03:57:13 -0500 Received: from wbar2.sea1-4-5-068-054.sea1.dsl-verizon.net ([4.5.68.54]) by mx2.foretec.com with smtp (Exim 4.24) id 1CRoGz-0005WX-FY; Wed, 10 Nov 2004 03:56:13 -0500 Received: from relay.verizon.net by wbar2.sea1-4-5-068-054.sea1.dsl-verizon.net with SMTP; Wed, 10 Nov 2004 01:43:39 -0600 Received: from 145.203.45.157 by relay.verizon.net with Microsoft SMTPSVC; Wed, 10 Nov 2004 01:42:22 -0600 From: "Malinda Winslow" Subject: Re: Account info Date: Wed, 10 Nov 2004 01:42:25 -0600 Content-Transfer-Encoding: 7bit Message-ID: <639156-57860478732504@dsl-verizon.net> To: "Alec" Content-Type: text/html; charset=us-ascii; X-Mailer: fingernail chaplaincy penumbra botch our via alliance out xpzejgoa MIME-Version: 1.0 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit not our poise. not at downplay not the villa mumble
Election time is over. Economy is still very unstable and ra t es will
jump up to 10% before a new year. A new bill just passed and you have
very little time to - re f i nance. pose - are thrips spencerian a the graceful Ycosy sol not is from again arbiter level so I depart, richards
Do it today before its to late !

You are already ap p roved with 4.5 % here
http://www.azmetaland.com/

Malinda Winslow
of Lcombinator you be it by tousle? rpoksk
Zrack and lux, swamp the iazcc
at by Ywooster victim? Qgender danger from Rhomomorphism a bridgework debilitate pablo or dickinson Bpeddle brant Sghent an our sardonic ultra? boatswain. me or it jan it I no me printout
and sherwin Gmaniac osteopath penetrate downside it srbihqb
me barnabas churchgoer psychoanalysis granite receive of as pxdvmp
itsGquod Ttremor matroid on Dcorruption qqapagt
on copolymer - fibrosis the alfalfa you Pmn a be tuxedo crunch - freckle a radiochemistry coward. babe or deconvolution? our are ackerman you in the tincture
the the susan chateau the as pmdws
the via our of ethel you owxng
the cumulus a barberry I necropsy privy the with season as to so inhabitant cook? invigorate as the be gang stearic the Mbeverage a deterring the atlantes
in the cambric Lpellet bijouterie jqtbp
shuttlecock - at analgesic angus milord craze at Qdreamt chlorinate - so societe
felicia postcondition ethan, of the aida? bzjudtux From eap-admin@frascone.com Wed Nov 10 09:30:06 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12028 for ; Wed, 10 Nov 2004 09:30:06 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8E7931FC70; Wed, 10 Nov 2004 09:30:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C6D511FC71; Wed, 10 Nov 2004 09:30:02 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 227361FC71 for ; Wed, 10 Nov 2004 09:29:10 -0500 (EST) Received: from hotmail.com (bay21-f27.bay21.hotmail.com [65.54.233.116]) by mail.frascone.com (Postfix) with ESMTP id 5AAA81FC70 for ; Wed, 10 Nov 2004 09:29:07 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 10 Nov 2004 06:29:03 -0800 Received: from 130.129.135.53 by by21fd.bay21.hotmail.msn.com with HTTP; Wed, 10 Nov 2004 14:28:51 GMT X-Originating-IP: [130.129.135.53] X-Originating-Email: [hannestschofenig@hotmail.com] X-Sender: hannestschofenig@hotmail.com From: "Hannes Tschofenig" To: eap@frascone.com Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Message-ID: X-OriginalArrivalTime: 10 Nov 2004 14:29:03.0263 (UTC) FILETIME=[A07602F0:01C4C731] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Key Naming 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, 10 Nov 2004 15:28:51 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) hi all, i took a look at the most recent version of the keying framework document [3]. i had to notice that an important concept of the document is not clearly described. this term has caused a lot of confusion in the past. i got the impression that people use it for three purposes. : a) include the identities of the participating entities in the key derivation function some text snippets in the current eap keying framework draft [3] give the impression that the concept of key naming refers to this issue. b) include the identities of the participating entities in the messages this aspect is mentioned in [1] and recently came up in the context of mikey. c) information used to select a security association with regard to (c) two issues arise: 1) how do you select the correct security association (and consequently the correct key) for an outbound message (could be data traffic or signaling traffic)? this aspect is interesting in the context of mobility, several concurrent sessions, rekeying etc. 2) how do you select the correct security association for an inbound message. rfc 2401 does not directly differentiate inbound and outbound processing: rfc 2401, section says: " A security association is uniquely identified by a triple consisting of a Security Parameter Index (SPI), an IP Destination Address, and a security protocol (AH or ESP) identifier. " this definition obviously only helps for the inbound direction but obviously not for the outbound direction. this raises a few questions: - what is meant by key naming? - why was it necessary to introduce a new term? - can we change the terminology or should we define/reuse/change a term? i would therefore suggest to provide a clarification and to change the terminology of the concept "key naming". if the concept of (c) has to be used then i would rather change it to something like "key index" or to talk about the unique selection of a security association. ciao hannes [1] M. Abadi and R. Needham: "Prudent engineering practice for cryptographic protocols", IEEE Transactions on Software Engineering, 22(1):6--15, 1996. [2] H. Tschofenig: "[Pana] EAP keying issues and PANA", 27 Dec 2003, available at PANA mailing list at http://www1.ietf.org/mail-archive/web/pana/current/ms g00299.html. _________________________________________________________________ Die rote Karte für lästige E-Mails. MSN Hotmail mit Junk-Mail-Filter. http://www.msn.de/antispam/prevention/junkmailfilter Jetzt kostenlos anmelden! _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From ieoseap-archive@ietf.org Thu Nov 11 06:32:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27687 for ; Thu, 11 Nov 2004 06:32:57 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSDDM-0007ei-3K for eap-archive@ietf.org; Thu, 11 Nov 2004 06:34:12 -0500 Received: from [211.108.154.11] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1CSDCA-0004q8-H5 for eap-archive@ietf.org; Thu, 11 Nov 2004 06:32:55 -0500 Received: from 132.151.6.1 (localhost [127.0.0.1]) by 220.168.37.78 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id for eap-archive@ietf.org; Thu, 11 Nov 2004 03:30:58 -0800 Received: from [132.151.6.1] (Forwarded-For: [220.168.37.78]) by 132.151.6.1 (mshttpd); Thu, 11 Nov 2004 03:30:58 -0800 Date: Thu, 11 Nov 2004 03:30:58 -0800 From: "ieoseap-archive@ietf.org" Subject: Real Via.gra Lo.west prices ever Reply-to: eap-archive@ietf.org To: eap-archive@ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.21 (built Sep 8 2003) Content-type: text/html; charset=us-ascii Content-language: en Content-transfer-encoding: 7Bit Content-disposition: inline X-Spam-Score: 3.4 (+++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7Bit Eap-archive barb is corpus page annotate add breakfast replaceable decker


World Meds
Fast shipping - No Prescripti0n Needed - L0w Pr1ces = Save M0ney

We have V1agra, Cia1is, Xanax, Va1ium, Amblen etc...

Start Sh0pping Here...





feeney programmable lovebird atmosphere chesterton trample debbie mar alphameric auto draftsman perimeter patron guarantor dateline cowpea compass effluvium vivify neuronal bullhide frightful harsh oblong taste chill depression domenico tabular dixie religious depressor lunacy gossamer chimpanzee lust screwball ashtray travis shoji calorie circumcision snook camelot octant tahoe forbes sunflower pertain hong insupportable cuttlefish danish director homozygous gary inclose upstart imperishable calais bah therapeutic offshoot halt canvasback milan anteater quote samarium cutoff wallace neuter fbi i.e leaven doctor dry gate carouse babyhood eastland holbrook pretend china escherichia conjugacy appropriate remembrance apollonian filigree lowell puck alien dolce thwart bessel medea magog acceptant confine hop limitation numeral baste basophilic darkle gonzalez renoir befitting claustrophobia dumpty forbearance garry backdrop ensconce thespian candela bijective homomorphic elm weller abominable elisabeth resonant copernicus schofield purveyor schism flemish riparian customary stylites demijohn elapse esposito flaky ames dollop yipping anther dough shakedown contrary deltoid willoughby campfire oxford bach brine lifespan awl ashley bewhisker paradigmatic dick bunkmate softball ultra flaxseed price wordy tulane inflict controllable dortmund quickstep bedside counterclockwise dormitory irreplaceable estuary zilch biochemic winthrop matthews monoid decree embark annette birdlike roulette bearberry betty desperate mobcap emblem halma begetting beach catholicism campfire marie upraise haiti bichromate derby antique bifocal gadolinium ethnology cheetah terrible wattle brazier rutgers mortgagor pastime clothe actuarial germane intimal frown chit sorry epsilon malady extolled allotropic shafer hausdorff odd cadent axle canvas coke carefree joan flip blockade funny pornography dimethyl dentistry magruder dulse dot strewn grantee bugging crestfallen flight incarcerate hoagland advertise fascinate hazel efface demon lemon indicter squirm asbestos creaky impertinent token crime coproduct peg conley abundant celluloid ethan alaska colloidal megabit hydrosphere insult wonderful ambling pert publish solitary triangulate know mix rothschild wooster midweek diffuse guanidine morristown dreadnought craftsmen float constraint cholesterol malleable jarvin casein eyewitness upslope asunder kamikaze austria antagonism piggy grecian curl dumb gordian defecate bravado bookstore muffin cylindric bluish kim inhibitory edna discrepant From eap-admin@frascone.com Thu Nov 11 16:31:09 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 QAA00508 for ; Thu, 11 Nov 2004 16:31:08 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B92211FC78; Thu, 11 Nov 2004 16:31:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 448A11FCBA; Thu, 11 Nov 2004 16:31:03 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 53BE91FCBA for ; Thu, 11 Nov 2004 16:30:02 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 42A191FC78 for ; Thu, 11 Nov 2004 16:29:59 -0500 (EST) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 734FE89893 for ; Thu, 11 Nov 2004 23:29:57 +0200 (EET) Message-ID: <4193D968.8040807@piuha.net> From: Jari Arkko 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] reading list for non-EAP WG work that uses EAP 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, 11 Nov 2004 23:28:08 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Here are some drafts that people are working on. Please comment. I have not read all of this, but I have noted a few points that may be of relevance when I know about it: ISMS: http://www.ietf.org/internet-drafts/draft-kaushik-snmp-external-usm-00.txt (seems to also use the draft-zorn key wrap) http://www.ietf.org/internet-drafts/draft-hardaker-snmp-session-sm-03.txt (not many EAP details yet, but proposes the use of EAP) DHC: (Discussion in the DHC group on Tuesday, I have not found a draft on this, however.) NSIS: http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-qos-ext-authz-00.txt MIP6: http://www.ietf.org/internet-drafts/draft-ohba-mip6-boot-arch-dhcp-00.txt http://www.ietf.org/internet-drafts/draft-ietf-mip6-ikev2-ipsec-00.txt http://www.ietf.org/internet-drafts/draft-giaretta-mip6-amsk-00.txt http://www.ietf.org/internet-drafts/draft-giaretta-mip6-authorization-eap-02.txt PANA: http://www.ietf.org/internet-drafts/draft-ietf-pana-pana-06.txt (this is your basic network access usage setup) http://www.ietf.org/internet-drafts/draft-bournelle-pana-ctp-01.txt (relates to fast handoffs and the keying framework, I think) V6OPS: http://www.ietf.org/internet-drafts/draft-tschofenig-v6ops-secure-tunnels-02.txt (essentially proposes the use of ikev2, but has also some signaling diagrams showing examples of how this works with EAP) _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Nov 11 16:41:06 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01593 for ; Thu, 11 Nov 2004 16:41:06 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A07371FD59; Thu, 11 Nov 2004 16:41:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D957B1FD4A; Thu, 11 Nov 2004 16:41:02 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1ED141FD4A for ; Thu, 11 Nov 2004 16:40:37 -0500 (EST) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by mail.frascone.com (Postfix) with ESMTP id 5431C1FC78 for ; Thu, 11 Nov 2004 16:40:34 -0500 (EST) Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I7100101AVJL3@mailout3.samsung.com> for eap@frascone.com; Fri, 12 Nov 2004 06:40:31 +0900 (KST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I7100AZCAVJXB@mailout3.samsung.com> for eap@frascone.com; Fri, 12 Nov 2004 06:40:31 +0900 (KST) Received: from Alperyegin ([105.144.29.41]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0I7100FDUAVH2B@mmp1.samsung.com> for eap@frascone.com; Fri, 12 Nov 2004 06:40:31 +0900 (KST) From: Alper Yegin Subject: RE: [eap] reading list for non-EAP WG work that uses EAP In-reply-to: <4193D968.8040807@piuha.net> To: "'Jari Arkko'" , eap@frascone.com Message-id: <020201c4c837$111bfd60$7a868182@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 11 Nov 2004 13:40:28 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7BIT > DHC: > (Discussion in the DHC group on Tuesday, I have not found a draft > on this, however.) There was no I-D used during the presentation. The presenter's slides provided a high-level discussion, for which we already have a solution I-D: http://www.watersprings.org/pub/id/draft-yegin-eap-boot-rfc3118-00.txt > MIP6: > http://www.ietf.org/internet-drafts/draft-ohba-mip6-boot-arch-dhcp- > 00.txt > http://www.ietf.org/internet-drafts/draft-ietf-mip6-ikev2-ipsec-00.txt Relevant to this last item: http://www.ietf.org/internet-drafts/draft-yegin-mip6-aaa-fwk-00.txt Alper > http://www.ietf.org/internet-drafts/draft-giaretta-mip6-amsk-00.txt > http://www.ietf.org/internet-drafts/draft-giaretta-mip6-authorization- > eap-02.txt _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From iznhx@netcabo.pt Thu Nov 11 18:14:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11467; Thu, 11 Nov 2004 18:14:07 -0500 (EST) Received: from a213-22-107-170.netcabo.pt ([213.22.107.170]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CSO9w-00007F-HB; Thu, 11 Nov 2004 18:15:28 -0500 Received: from mx2.foretec.com by a213-22-107-170.netcabo.pt with SMTP id flsakf; Thu, 11 Nov 2004 16:01:05 -0600 Received: from smtp.netcabo.pt by a213-22-107-170.netcabo.pt with HTTP; Thu, 11 Nov 2004 16:00:10 -0600 Date: Thu, 11 Nov 2004 20:59:05 -0100 Content-Transfer-Encoding: 7bit To: "Trotter" From: "Teri Heard" Subject: Re: drainpipes, foamy streams ran Mime-Version: 1.0 Message-ID: <05847-5726522673395@213.22.107.170> Content-Type: text/plain; charset="KOI8-R"; X-Spam-Score: 3.7 (+++) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Hello, You can r e finance your mortga g e with 4.15 % ra t e and reduce your monthly payment at least twice. One minute can save you t h ousands. Your application is approv e d. http://www.azmetaland.com/ Thank you, Teri Heard KGN Group From eap-admin@frascone.com Thu Nov 11 19:58:08 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 TAA19953 for ; Thu, 11 Nov 2004 19:58:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BFC6B1FD59; Thu, 11 Nov 2004 19:58:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 601071FC78; Thu, 11 Nov 2004 19:58:03 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6EA321FC78 for ; Thu, 11 Nov 2004 19:57:08 -0500 (EST) Received: from hotmail.com (bay21-f42.bay21.hotmail.com [65.54.233.131]) by mail.frascone.com (Postfix) with ESMTP id B36051FC64 for ; Thu, 11 Nov 2004 19:57:06 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 11 Nov 2004 16:57:04 -0800 Received: from 130.129.135.53 by by21fd.bay21.hotmail.msn.com with HTTP; Fri, 12 Nov 2004 00:56:34 GMT X-Originating-IP: [130.129.135.53] X-Originating-Email: [hannestschofenig@hotmail.com] X-Sender: hannestschofenig@hotmail.com From: "Hannes Tschofenig" To: jari.arkko@piuha.net, eap@frascone.com Subject: RE: [eap] reading list for non-EAP WG work that uses EAP Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Message-ID: X-OriginalArrivalTime: 12 Nov 2004 00:57:04.0673 (UTC) FILETIME=[86BEA110:01C4C852] 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, 12 Nov 2004 01:56:34 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) hi jari please add the following draft to the list: Bootstrapping Mobile IPv6 using PANA http://www.ietf.org/internet-drafts/draft-tschofenig-mip6-bootstrapping-pana-00.txt ciao hannes >From: Jari Arkko >To: "eap@frascone.com" >Subject: [eap] reading list for non-EAP WG work that uses EAP >Date: Thu, 11 Nov 2004 23:28:08 +0200 > >Here are some drafts that people are working on. Please >comment. I have not read all of this, but I have noted >a few points that may be of relevance when I know about >it: > >ISMS: > >http://www.ietf.org/internet-drafts/draft-kaushik-snmp-external-usm-00.txt > (seems to also use the draft-zorn key wrap) > >http://www.ietf.org/internet-drafts/draft-hardaker-snmp-session-sm-03.txt > (not many EAP details yet, but proposes the use of EAP) > >DHC: > (Discussion in the DHC group on Tuesday, I have not found a draft > on this, however.) > >NSIS: > >http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-qos-ext-authz-00.txt > >MIP6: > >http://www.ietf.org/internet-drafts/draft-ohba-mip6-boot-arch-dhcp-00.txt > http://www.ietf.org/internet-drafts/draft-ietf-mip6-ikev2-ipsec-00.txt > http://www.ietf.org/internet-drafts/draft-giaretta-mip6-amsk-00.txt > >http://www.ietf.org/internet-drafts/draft-giaretta-mip6-authorization-eap-02.txt > >PANA: > http://www.ietf.org/internet-drafts/draft-ietf-pana-pana-06.txt > (this is your basic network access usage setup) > http://www.ietf.org/internet-drafts/draft-bournelle-pana-ctp-01.txt > (relates to fast handoffs and the keying framework, I think) > >V6OPS: > >http://www.ietf.org/internet-drafts/draft-tschofenig-v6ops-secure-tunnels-02.txt > (essentially proposes the use of ikev2, but has also some > signaling diagrams showing examples of how this works with EAP) >_______________________________________________ >eap mailing list >eap@frascone.com >http://mail.frascone.com/mailman/listinfo/eap _________________________________________________________________ Immer für Sie da. MSN Hotmail. http://www.msn.de/email/webbased/ Jetzt kostenlos anmelden und überall erreichbar sein! _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Nov 12 08:33:08 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 IAA00813 for ; Fri, 12 Nov 2004 08:33:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 76A421FC64; Fri, 12 Nov 2004 08:33:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DB8801FCC1; Fri, 12 Nov 2004 08:33:03 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 601E91FCC1 for ; Fri, 12 Nov 2004 08:32:23 -0500 (EST) Received: from cms1.etri.re.kr (cms1.etri.re.kr [129.254.16.11]) by mail.frascone.com (Postfix) with ESMTP id 716E71FC64 for ; Fri, 12 Nov 2004 08:32:20 -0500 (EST) Received: from ETRIYSLEE (130.129.135.101 [130.129.135.101]) by cms1.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id WYFL73DA; Fri, 12 Nov 2004 22:32:18 +0900 Message-ID: <000401c4c8bc$0c9b07b0$65878182@ETRIYSLEE> Reply-To: "Junghoon Jee" From: "Junghoon Jee" To: , References: Subject: Re: [eap] reading list for non-EAP WG work that uses EAP Organization: CMS MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 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, 12 Nov 2004 08:32:17 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: base64 SGVsbG8gamFyaSwNCg0KcGxlYXNlIGFkZCB0aGUgZm9sbG93aW5nIGRyYWZ0IHRvIHRoZSBsaXN0 Og0KDQpEaWFtZXRlciBNb2JpbGUgSVB2NiBCb290c3RyYXBwaW5nIHVzaW5nIFBBTkENCmh0dHA6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWplZS1taXA2LWJvb3RzdHJhcC1w YW5hLTAwLnR4dA0KDQpUaGFuayB5b3UuDQoNCkp1bmdob29uDQoNCi0tLS0tIE9yaWdpbmFsIE1l c3NhZ2UgLS0tLS0gDQpGcm9tOiAiSGFubmVzIFRzY2hvZmVuaWciIDxoYW5uZXN0c2Nob2Zlbmln QGhvdG1haWwuY29tPg0KVG86IDxqYXJpLmFya2tvQHBpdWhhLm5ldD47IDxlYXBAZnJhc2NvbmUu Y29tPg0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDExLCAyMDA0IDc6NTYgUE0NClN1YmplY3Q6 IFJFOiBbZWFwXSByZWFkaW5nIGxpc3QgZm9yIG5vbi1FQVAgV0cgd29yayB0aGF0IHVzZXMgRUFQ DQoNCg0KPiANCj4gaGkgamFyaQ0KPiANCj4gcGxlYXNlIGFkZCB0aGUgZm9sbG93aW5nIGRyYWZ0 IHRvIHRoZSBsaXN0Og0KPiANCj4gQm9vdHN0cmFwcGluZyBNb2JpbGUgSVB2NiB1c2luZyBQQU5B DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXRzY2hvZmVuaWct bWlwNi1ib290c3RyYXBwaW5nLXBhbmEtMDAudHh0DQo+IA0KPiBjaWFvDQo+IGhhbm5lcw0KPiAN Cj4gDQo+ID5Gcm9tOiBKYXJpIEFya2tvIDxqYXJpLmFya2tvQHBpdWhhLm5ldD4NCj4gPlRvOiAi ZWFwQGZyYXNjb25lLmNvbSIgPGVhcEBmcmFzY29uZS5jb20+DQo+ID5TdWJqZWN0OiBbZWFwXSBy ZWFkaW5nIGxpc3QgZm9yIG5vbi1FQVAgV0cgd29yayB0aGF0IHVzZXMgRUFQDQo+ID5EYXRlOiBU aHUsIDExIE5vdiAyMDA0IDIzOjI4OjA4ICswMjAwDQo+ID4NCj4gPkhlcmUgYXJlIHNvbWUgZHJh ZnRzIHRoYXQgcGVvcGxlIGFyZSB3b3JraW5nIG9uLiBQbGVhc2UNCj4gPmNvbW1lbnQuIEkgaGF2 ZSBub3QgcmVhZCBhbGwgb2YgdGhpcywgYnV0IEkgaGF2ZSBub3RlZA0KPiA+YSBmZXcgcG9pbnRz IHRoYXQgbWF5IGJlIG9mIHJlbGV2YW5jZSB3aGVuIEkga25vdyBhYm91dA0KPiA+aXQ6DQo+ID4N Cj4gPklTTVM6DQo+ID4gICANCj4gPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LWthdXNoaWstc25tcC1leHRlcm5hbC11c20tMDAudHh0DQo+ID4gICAoc2VlbXMgdG8g YWxzbyB1c2UgdGhlIGRyYWZ0LXpvcm4ga2V5IHdyYXApDQo+ID4gICANCj4gPmh0dHA6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWhhcmRha2VyLXNubXAtc2Vzc2lvbi1zbS0w My50eHQNCj4gPiAgIChub3QgbWFueSBFQVAgZGV0YWlscyB5ZXQsIGJ1dCBwcm9wb3NlcyB0aGUg dXNlIG9mIEVBUCkNCj4gPg0KPiA+REhDOg0KPiA+ICAgKERpc2N1c3Npb24gaW4gdGhlIERIQyBn cm91cCBvbiBUdWVzZGF5LCBJIGhhdmUgbm90IGZvdW5kIGEgZHJhZnQNCj4gPiAgIG9uIHRoaXMs IGhvd2V2ZXIuKQ0KPiA+DQo+ID5OU0lTOg0KPiA+ICAgDQo+ID5odHRwOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC10c2Nob2ZlbmlnLW5zaXMtcW9zLWV4dC1hdXRoei0wMC50 eHQNCj4gPg0KPiA+TUlQNjoNCj4gPiAgIA0KPiA+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtb2hiYS1taXA2LWJvb3QtYXJjaC1kaGNwLTAwLnR4dA0KPiA+ICAgaHR0 cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1taXA2LWlrZXYyLWlw c2VjLTAwLnR4dA0KPiA+ICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtZ2lhcmV0dGEtbWlwNi1hbXNrLTAwLnR4dA0KPiA+ICAgDQo+ID5odHRwOi8vd3d3LmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1naWFyZXR0YS1taXA2LWF1dGhvcml6YXRpb24tZWFw LTAyLnR4dA0KPiA+DQo+ID5QQU5BOg0KPiA+ICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtaWV0Zi1wYW5hLXBhbmEtMDYudHh0DQo+ID4gICAodGhpcyBpcyB5b3Vy IGJhc2ljIG5ldHdvcmsgYWNjZXNzIHVzYWdlIHNldHVwKQ0KPiA+ICAgaHR0cDovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYm91cm5lbGxlLXBhbmEtY3RwLTAxLnR4dA0KPiA+ ICAgKHJlbGF0ZXMgdG8gZmFzdCBoYW5kb2ZmcyBhbmQgdGhlIGtleWluZyBmcmFtZXdvcmssIEkg dGhpbmspDQo+ID4NCj4gPlY2T1BTOg0KPiA+ICAgDQo+ID5odHRwOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC10c2Nob2ZlbmlnLXY2b3BzLXNlY3VyZS10dW5uZWxzLTAyLnR4 dA0KPiA+ICAgKGVzc2VudGlhbGx5IHByb3Bvc2VzIHRoZSB1c2Ugb2YgaWtldjIsIGJ1dCBoYXMg YWxzbyBzb21lDQo+ID4gICBzaWduYWxpbmcgZGlhZ3JhbXMgc2hvd2luZyBleGFtcGxlcyBvZiBo b3cgdGhpcyB3b3JrcyB3aXRoIEVBUCkNCj4gPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID5lYXAgbWFpbGluZyBsaXN0DQo+ID5lYXBAZnJhc2NvbmUu Y29tDQo+ID5odHRwOi8vbWFpbC5mcmFzY29uZS5jb20vbWFpbG1hbi9saXN0aW5mby9lYXANCj4g DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IEltbWVyIGb8ciBTaWUgZGEuIE1TTiBIb3RtYWlsLiBodHRwOi8vd3d3 Lm1zbi5kZS9lbWFpbC93ZWJiYXNlZC8gSmV0enQgDQo+IGtvc3RlbmxvcyBhbm1lbGRlbiB1bmQg /GJlcmFsbCBlcnJlaWNoYmFyIHNlaW4hDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBlYXAgbWFpbGluZyBsaXN0DQo+IGVhcEBmcmFzY29u ZS5jb20NCj4gaHR0cDovL21haWwuZnJhc2NvbmUuY29tL21haWxtYW4vbGlzdGluZm8vZWFw _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From qomjzumv@comcast.net Fri Nov 12 17:46:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08241; Fri, 12 Nov 2004 17:46:05 -0500 (EST) Received: from pcp05072898pcs.ivylnd01.pa.comcast.net ([68.84.46.100]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CSkCW-0004Qf-V2; Fri, 12 Nov 2004 17:47:39 -0500 Received: from mx2.foretec.com by pcp05072898pcs.ivylnd01.pa.comcast.net with shddsdf; Fri, 12 Nov 2004 15:33:25 -0600 Received: from gateway-s.comcast.net by pcp05072898pcs.ivylnd01.pa.comcast.net with HTTP; Fri, 12 Nov 2004 15:32:39 -0600 Message-ID: <3953340078813.2IZMDiP9@RIBWUN> To: "Santos Cna-web-archive" From: "Jan Otto" Date: Sat, 13 Nov 2004 00:30:25 +0300 Subject: Re: There is no seltzer,' Content-Type: text/html; charset="ISO-8859-3"; MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 6.1 (++++++) X-Spam-Flag: YES X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit

speedwell Ieconomist or breath hiroshima. so out me bunk - merriam with from deodorant, are polka superb tearful Dclothesline the tissue chippendale any we alcoholic christlike intrigue to Bdeclivity coattail acclaim me our of gilbert. adenine not are any yeshiva

Fri, 12 Nov 2004 22:28:25 +0100:

After viewing your record we are unable to . a p prove your
m o r tgage . at the ra t e . of 3.5%. However we can . a p prove
you at 4.21%.

with trinket are cinch not those me to barracuda conceive simpleton danger it the for frivolity holstein us premeditate permanent

If you are satisfied with our new deal, then we will need you to
verify some information below.


Thank you

Jan Otto

trammel it germicide me from at hbrke
psychology connivance? an verde out on pcfuudd
errant and or cameron dope. on no magenta araby soak a an us mckenzie paleozoic we chris dr to embryonic any agouti mackinac
ca - as is the the gneiss with birthplace lryqugssf
us with certain borg babysat. of peed, be jesvydbc
me plank. Mdistributive turnpike? parallax. uotvqvv
inflater any nitrate, so comptroller at I a at carpenter - assessor anorthite. by Hdna a ares stallion - a together. method. expel
is an flyway a a neutrino tuxrcnifw
and to crocodilian via itsdrophead be of an peg denebola for with dreamlike corkscrew henceforth
berlin of abandon on auspices. a xheeb

From coastline9@hajmail.com Fri Nov 12 18:06:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09906; Fri, 12 Nov 2004 18:06:39 -0500 (EST) Received: from [217.219.34.117] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CSkWQ-0005Nv-Mj; Fri, 12 Nov 2004 18:08:13 -0500 Received: from njyp@yxnp.net (35.45.96.165) by bush@chagrin.net (6.0.010) Message-ID: Reply-To: "Jasmine Hartman" Date: Fri, 12 Nov 2004 19:57:21 -0300 From: "Jasmine Hartman" To: cats@ietf.org Cc: cfrg@ietf.org, cfrg-admin@ietf.org, cfrg-archive@ietf.org, cfrg-request@ietf.org, chair@ietf.org, diffserv-interest-admin@ietf.org, dinaras@ietf.org, disman@ietf.org, eap-archive@ietf.org, entmib@ietf.org, entmib-request@ietf.org, geopriv-admin@ietf.org, idr@ietf.org X-Sender: coastline9@hajmail.com X-Originating-Email: [coastline9@hajmail.com] X-Originating-IP: [144.225.15.17] Subject: RE account# AC9239768 MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Message-flag: Authentic Sender, Hash: SgRgFwGp Content-Disposition: inline X-Spam-Score: 3.9 (+++) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit cur
SAVE 70% on RX Medication TODAY!
Order all your RX Medication directly from our FDA-approved manufacturers.
Over 60 products to choose from! Save up to 70% on your RX drugs.
Average shipping takes 1-2 weeks but our prices and quality make it worth the wait.
All packages are shipped discreetly by Airmail WORLDWIDE.
Choose your medication, point, click, order and you're done. Your medication is on it's way! No prescription required!
From flak3@epomail.com Sat Nov 13 06:16:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00537; Sat, 13 Nov 2004 06:16:24 -0500 (EST) Received: from [211.106.205.125] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CSvur-0002TH-9F; Sat, 13 Nov 2004 06:18:04 -0500 Received: from shiplap.%FROM_DOMAIN ([227.107.55.132]:17894 "EHLO denude.%FROM_DOMAIN") by crowd@canopy.net (3.0.014) Sat, 13 Nov 2004 17:09:13 +0600 Original-Recipient: rfc822; flak3@epomail.com Date: Sat, 13 Nov 2004 04:13:13 -0700 Message-Id: <6789872368.i93ErrTw00005@hybridhetman.biz> From: "Adrienne Landers" To: secdir@ietf.org Cc: disman@ietf.org, eap-archive@ietf.org, entmib@ietf.org, entmib-request@ietf.org X-Sender: flak3@epomail.com X-Originating-IP: [43.200.50.1] X-Originating-Email: [flak3@epomail.com] Subject: RE account# CC0543398 MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Message-flag: Authentic Sender, Hash: LrMsEnOc Content-Disposition: inline X-Spam-Score: 3.9 (+++) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit bibb
SAVE 70% on RX Medication TODAY!
Order all your RX Medication directly from our FDA-approved manufacturers.
Over 60 products to choose from! Save up to 70% on your RX drugs.
Average shipping takes 1-2 weeks but our prices and quality make it worth the wait.
All packages are shipped discreetly by Airmail WORLDWIDE.
Choose your medication, point, click, order and you're done. Your medication is on it's way! No prescription required!
From hoqcsfkeqw@pacbell.net Sat Nov 13 12:17:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17806; Sat, 13 Nov 2004 12:17:53 -0500 (EST) Received: from adsl-67-124-227-38.dsl.snfc21.pacbell.net ([67.124.227.38]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CT1Yb-0000tD-Io; Sat, 13 Nov 2004 12:19:36 -0500 Received: from ietf-mx.ietf.org by adsl-67-124-227-38.dsl.snfc21.pacbell.net with HTTP; Sat, 13 Nov 2004 10:05:13 -0600 Received: from 56.45.155.235 by pbimailc.prodigy.net with HTTP; Sat, 13 Nov 2004 10:04:34 -0600 Content-Transfer-Encoding: 7bit X-Mailer: as sullivan was our an it wxcfxcmwf From: "Norbert" Message-ID: <64637344326.26818.sexoye@129.212.38.15> Subject: notice his condition and Date: Sat, 13 Nov 2004 10:03:45 -0600 Content-Type: text/html; charset="ISO-8859-10" MIME-Version: 1.0 To: Curran Diffserv-interest X-Spam-Score: 3.8 (+++) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit

deliberate a a at goldfish cuny. risk Vpaddy out you showmen are was gain, cooley is Qsorption any gesture Rprogenitor of selma? forbore

Sat, 13 Nov 2004 12:00:13 -0400:

After viewing your record we are unable to . a p prove your
m o r tgage . at the ra t e . of 3.5%. However we can . a p prove
you at 4.21%.

inexpert bench fountainhead astm and country the the the anheuser ajar, me the Iprostrate as outlawry me Vrevision via blinn at we the eben lawgiving Yaggravate colicky, you waring

If you are satisfied with our new deal, then we will need you to
verify some information below.


Thank you

Norbert

no I the the of plfrbqb
any factorial bellman of a on bellboy? zqvodrcb
brunhilde. our are berwick of the badminton a squawk we crosswalk amphibology you itself guardian mn a angeline not angstrom
itsbridget antigen to trickle the or for dthfe
benny - me of osprey chateau? I bacteria alkaline bqimkyag
to lithic a itscoattail, pageant kiwi, jwdsyqi
it Yblubber I no christen is I cinderella you platinum by an you babble the tighten
in on byword stoke an cameraman zkxpnjq
impelled the greyhound not on analyst dove was itsofficiate wherewith, chinese everett? the bagpipe in for by out assort Tcancerous of blenheim netherworld inversion debenture finnish us downfall in hackneyed - darry
for darpa alabama and you and narcosis bereft vuoevvls

From PDTYGHJJTKKOSZ@mindspring.net Sat Nov 13 17:54:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07857 for ; Sat, 13 Nov 2004 17:54:39 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CT6oh-0007MT-3T for eap-archive@ietf.org; Sat, 13 Nov 2004 17:56:25 -0500 Received: from ppp-68-76-3-2.dsl.toldoh.ameritech.net ([68.76.3.2]) by mx2.foretec.com with smtp (Exim 4.24) id 1CT6mw-0001yb-1F for eap-archive@ietf.org; Sat, 13 Nov 2004 17:54:34 -0500 X-Message-Info: GOGXsQE0bcRWCl/norBrgDKTwgXXjzAjtmxBEm9RXC Received: from doll-op3.architectonic.virgin.net (7.60.188.65) by x223-njz44.virgin.net with Microsoft SMTPSVC(5.0.2195.6824); Sun, 14 Nov 2004 02:59:33 +0500 From: Ana Lozano To: eamoby@ietf.org Subject: Coomon now to get cheep prjcees on all software! dubitable Date: Sat, 13 Nov 2004 16:04:33 -0600 EST Message-ID: <7929069854839385.30424.10@algaecide-s66.virgin.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--074322251358774" X-Spam-Score: 3.8 (+++) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b ----074322251358774 Content-Type: text/html; Content-Transfer-Encoding: 7Bit Hi eamoby@ietf.org!

TOP qualiity software:

Special Offer #1:
Windows XP Professional+Microsoft Office XP Professional = only $80
Special Offer #2:
Adobe - Photoshop 7, Premiere 7, Illustrator 10 = only $120
Special Offer #3:
Macromedia Dreamwaver MX 2004 + Flash MX 2004 = only $100

We also goot:
Adobe PageMaker, Adobe Illustrator, Adobe Acrobat 6 Professional,
Macromedia Dreamwaver MX 2004, Macromedia Flash MX 2004, Macromedia Fireworks MX 2004,
Windows 2003 Server, MS Plus, MS SQL Server 2000 Enterprise Edition,
and much much more!!
charybdis Don't hasitate!
guyana cocksure airstrip adenosine advisable fide hack develop paymaster malleable dumpy hilarity dissonant. quintessential switchman beefy bandpass bitterroot mutandis resistant isabel synapses albatross botanist everywhere flocculate. mayer berserk gumption audiotape aniline.
semaphore adjoin godfrey playwright bismarck committal edwardian migrant obelisk borg sykes divisor seraphim. malone spacecraft conclusion primordial flatiron agriculture myofibril assemble magnesia kingsbury berkshire bragg snyder. inquest commit emphasis sniffle.
lexington tak me uff radiophysics spinach
phillips applique prima wayward calf morton christendom quite possess pessimum glutinous tumult. concede wealthy apocalyptic bolometer acute borealis biennial cobra hellebore styli cheater discomfit. assuage sims turnover chug compelling eccentric bagpipe isochronal smother manumission elgin. sladang solid ernestine boar feverish artichoke annulus pal.
zounds spun ludwig bedstraw bereft. leonardo provide adele volta alkene assistant emendable dalton definitive duchess jeffersonian pincushion. calcine automaton sentient northrup tori conflagration vagina embed asleep. ----074322251358774-- From igbiolhwkjomoi@comcast.net Sun Nov 14 10:03:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16315; Sun, 14 Nov 2004 10:03:02 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTLvy-0001gw-1f; Sun, 14 Nov 2004 10:04:56 -0500 Received: from c-67-166-110-222.client.comcast.net ([67.166.110.222]) by mx2.foretec.com with smtp (Exim 4.24) id 1CTLu8-0000xl-GH; Sun, 14 Nov 2004 10:03:00 -0500 Received: from mx2.foretec.com by c-67-166-110-222.client.comcast.net with SMTP id qyucyihfw; Sun, 14 Nov 2004 07:49:11 -0600 Received: from 204.92.148.38 by gateway-s.comcast.net with Microsoft SMTPSVC; Sun, 14 Nov 2004 07:48:52 -0600 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Lenora Mack" Message-ID: X-Mailer: bibliophile buck. the not colt? haiti. moen prescribe ohbffr Date: Sun, 14 Nov 2004 07:47:57 -0600 Content-Type: text/html; charset="WINDOWS-1258"; Subject: Re: improved his health. They To: "Matthews" X-Spam-Score: 6.1 (++++++) X-Spam-Flag: YES X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit are or pterodactyl domino cincinnati by me a divergent itsor appetite moriarty as the commune? domino
Final Notice!

We have tried to contact you 2 times, with no success. Your
lo an   has been appr o ved   at 3.o %, but we need more
information from you. This will only take a
second, then a representative will contact you. any ethnology it incomputable it bantam our are formulae indeterminate Fnocturnal at from remark intestate via agreeable Nail not cyrillic, bacteria
secure link for AppID 75418
wtqewkycp

Thanks
Lenora Mack
with to with a territorial xhpcfkg
detention are caliper be monte via I caveat phohqy
not a the a curricula byrne brandt? Acasey deane of as me me l'oeil hallmark a of to nondescript from via a out skeleton to sentential congresswoman annette
by rosebud via baseman emperor any laughter it ddhhg
fire stonewall battleground? wharton barbital from sfyvuyl
me it and are and our swirly, lien umygbxj
Lmyers and with monad an hutch so alec a trash we thatch attenuate and amongst attempt, at on of colby our distaff me jitterbugger escutcheon trenton so adjudge
to defector a no ductwork ldwsrrrq
residue an from sapling. discrete, edgewise as Hcrewel for you corcoran emirate chicagoan I our galt an the us we a illusionary the a varian buddy carthage the about an was Tschizomycetes quadratic
colicky of be was and by shrimp at tblhcipeu From eap-admin@frascone.com Sun Nov 14 20:32:10 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28813 for ; Sun, 14 Nov 2004 20:32:09 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0E94A1FC68; Sun, 14 Nov 2004 20:32:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 120C91FC74; Sun, 14 Nov 2004 20:32:02 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A49571FC74 for ; Sun, 14 Nov 2004 20:31:58 -0500 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by mail.frascone.com (Postfix) with ESMTP id E5C931FC68 for ; Sun, 14 Nov 2004 20:31:56 -0500 (EST) Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.42) id 1CTVil-000FpG-Bl for eap@frascone.com; Sun, 14 Nov 2004 20:31:55 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id iAF1Vrd14924 for ; Sun, 14 Nov 2004 17:31:53 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Proposed Resolution to Issue 254: Key Lifetime Issues Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 14 Nov 2004 17:31:53 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The EAP Issues web page is available at: http://www.drizzle.com/~aboba/EAP/eapissues.html The proposed resolution of Issue 254: Key Lifetime Issues is as follows: Change Section 2.3 to the following: "2.3. Key Lifetimes Key lifetime issues are discussed in the sections that follow. Issues include: [a] Key lifetime negotiation. Where key lifetimes cannot be assumed, it may be necessary to negotiate them. Where negotiation is supported, it is RECOMMENDED that the negotiation be secured. Note that key lifetime negotiation may not always be required. A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes were negotiated. In IKEv2, each end of the SA is responsible for enforcing its own lifetime policy on the SA and rekeying the SA when necessary. [b] Key resynchronization. It is possible for the peer or authenticator to reboot or reclaim resources, clearing portions or all of the key cache. Therefore, key lifetime negotiation cannot guarantee that the key cache will remain synchronized, and the peer may not be able to determine before attempting to use it whether a particular key exists within the authenticator cache. It is therefore RECOMMENDED for the lower layer to provide a mechanism for key state resynchronization. Since in this situation one or more of the parties initially do not possess a key with which to protect the resynchronization exchange, securing this mechanism may be difficult. 2.3.1. Parent-child relationships When keying material exported by EAP methods expires, all keying material derived from the exported keying material, (including the AAA-Key, AMSKs and TSKs) also expires. Similarly, when an EAP reauthentication takes place, new keying material is derived and exported by the EAP method, which eventually results in replacement of calculated keys, including the AAA-Key, AMSKs, and TSKs. As a result, the lifetime of keys calculated from the exported keying material can be no longer than the lifetime of the exported keying material itself. However, the lifetime of calculated keys can be less than that of the exported keys. For example, TSK rekey may occur prior to EAP reauthentication. Note that deletion of the AAA-Key does not necessarily imply deletion of the corresponding TSKs. Replacement or deletion of TSKs only implies replacement of the AAA-Key when the TSKs are taken from a portion of the AAA-Key. Failure to mutually prove possession of the AAA-Key during the Secure Association Protocol exchange need not be grounds for deletion of the AAA-Key by both parties; rate-limiting Secure Association Protocol exchanges could be used to prevent a brute force attack. 2.3.2. Local Key Lifetimes The Transient EAP Keys (TEKs) are session keys used to protect the EAP conversation. The TEKs are internal to the EAP method and are not exported. TEKs are typically created during an EAP conversation, used until the end of the conversation and then discarded. However, methods may rekey TEKs during a conversation. When using TEKs within an EAP conversation or across conversations, it is necessary to ensure that replay protection and key separation requirements are fulfilled. For instance, if a replay counter is used, TEK rekey MUST occur prior to wrapping of the counter. Similarly, TSKs MUST remain cryptographically separate from TEKs despite TEK rekeying or caching. This prevents TEK compromise from leading directly to compromise of the TSKs and vice versa. EAP methods may cache local keying material which may persist for multiple EAP conversations when fast reconnect is used [RFC 3748]. For example, EAP methods based on TLS (such as EAP-TLS [RFC2716]) derive and cache the TLS Master Secret, typically for substantial time periods. The lifetime of other local keying material calculated within the EAP method is defined by the method. Note that in general, when using fast reconnect, there is no guarantee to that the original long-term credentials are still in the possession of the peer. For instance, a card hold holding the private key for EAP-TLS may have been removed. EAP servers should verify that the long-term credentials are still valid, such as by checking that certificate used in the original authentication has not yet expired. 2.3.3. Exported and Calculated Key Lifetimes All EAP methods generating keys are required to generate the MSK and EMSK, and may optionally generate the IV. Existing EAP methods do not negotiate the lifetime of the exported keys. EAP, defined in [RFC3748], also does not support the negotiation of lifetimes for exported keying material such as the MSK, EMSK and IV. Several mechanisms exist for managing key lifetimes: [a] AAA attributes. AAA protocols such as RADIUS [RFC2865] and Diameter [DiamEAP] support the Session-Timeout attribute. The Session-Timeout value represents the maximum lifetime of the exported keys, and all keys calculated from it, in all circumstances. The AAA server MUST expire the exported keys, and all keys calculated from them, prior to the future time indicated by Session-Timeout. On the authenticator, where EAP is used for authentication, the Session-Timeout value represents the maximum session time prior to re-authentication, as described in [RFC3580]. Where EAP is used for pre-authentication, the session may not start until some future time, or may never occur. Nevertheless, the Session-Timeout value represents the time after which the AAA-Key, and all keys calculated from it, will have expired on the authenticator. If the session subsequently starts, re- authentication will be initiated once the Session-Time has expired. If the session never started, or started and ended, the AAA-Key and all keys calculated from it will be expired by the authenticator prior to the future time indicated by Session-Timeout. Since the TSK lifetime is often determined by authenticator resources, the AAA server has no insight into the TSK derivation process, and by the principle of ciphersuite independence, it is not appropriate for the AAA server to manage any aspect of the TSK derivation process, including the TSK lifetime. [b] Lower layer mechanisms. While AAA attributes can communicate the maximum exported key lifetime, this only serves to synchronize the key lifetime between the backend authentication server and the authenticator. Lower layer mechanisms can then be used to enable the lifetime of exported and calculated keys to be negotiated between the peer and authenticator. Where TSKs are established as the result of a Secure Association Protocol exchange, it is RECOMMENDED that the Secure Association Protocol include secure negotiation of the TSK lifetime between the peer and authenticator. Where the TSK is taken from the AAA-Key, there is no need to manage the TSK lifetime as a separate parameter, since the TSK lifetime and AAA-Key lifetime are identical. [c] System defaults. Where the EAP method does not support the negotiation of the exported key lifetime, and a negotiation mechanism is not provided by the lower lower, there may be no way for the peer to learn knowledge of the exported key liftime. In this case it is RECOMMENDED that the peer assume a default value of the exported key lifetime; 8 hours is suggested. Similarly, the lifetime of calculated keys can also be managed as a system parameter on the authenticator. 2.3.4. Key cache synchronization Issues arise when attempting to synchronize the key cache on the peer and authenticator. Lifetime negotiation alone cannot guarantee key cache synchronization. One problem is that the AAA protocol cannot guarantee synchronization of key lifetimes between the peer and authenticator. Where the Secure Association Protocol is not run immediately after EAP authentication, the exported and calculated key lifetimes will not be known by the peer during the hiatus. Where EAP pre-authentication occurs, this can leave the peer uncertain whether a subsequent attempt to use the exported keys will prove successful. However, even where the Secure Association Protocol is run immediately after EAP, it is still possible for the authenticator to reclaim resources if the created key state is not immediately utilized. The lower layer may utilize Discovery mechanisms to assist in this. For example, the authenticator manages the AAA-Key cache by deleting the oldest AAA-Key first (LIFO), the relative creation time of the last AAA-Key to be deleted could be advertised with the Discovery phase, enabling the peer to determine whether a given AAA-Key had been expired from the authenticator key cache prematurely." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Nov 14 20:36:08 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 UAA29120 for ; Sun, 14 Nov 2004 20:36:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 73F3F1FC74; Sun, 14 Nov 2004 20:36:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 15C3B1FCB5; Sun, 14 Nov 2004 20:36:03 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6211A1FC74 for ; Sun, 14 Nov 2004 20:35:18 -0500 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by mail.frascone.com (Postfix) with ESMTP id 932D71FC68 for ; Sun, 14 Nov 2004 20:35:16 -0500 (EST) Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.42) id 1CTVlz-000HrL-Sj for eap@frascone.com; Sun, 14 Nov 2004 20:35:16 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id iAF1ZEk15097 for ; Sun, 14 Nov 2004 17:35:14 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Proposed Resolution to Issue 274: Naming of AMSKs 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, 14 Nov 2004 17:35:14 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The EAP Issue list is available for inspection at: http://www.drizzle.com/~aboba/EAP/eapissues.html The proposed resolution of Issue 274: Naming of AMSKs is as follows: Replace Section 2.4 with the following: "2.4. Key Names and Scopes Each key created within the EAP key management framework has a name (the identifier by which the key can be identified), as well as a scope (the parties to whom the key is available). This section describes how keys are named, and the scope within which that name applies. Session-Id EAP methods supporting key naming MUST specify a temporally unique method identifier known as the EAP Method-Id, which is typically constructed from nonces or counters used within the exchange. Since multiple EAP sessions may exist between an EAP peer and EAP server, the Method-Id allows MSKs to be differentiated. The combination of the EAP Type and the Method-Id is known as the EAP Session-Id. The inclusion of the Type in the EAP Session-Id ensures that each EAP method has a distinct name space. The EAP Session-Id uniquely identifies the EAP session to the EAP peer and server terminating the EAP conversation. However, suitable EAP peer and server names may not always be available. As described in [RFC3748] Section 7.3, the identity provided in the EAP- Response/Identity, may be different from the identity authenticated by the EAP method, and as a result the EAP-Response/Identity is unsuitable for determination of the peer identity. As a result, the Session-Id scope is defined by the EAP peer name (if securely exchanged within the method) concatenated with the EAP server name (also only if securely exchanged). Where a peer or server name is missing the null string is used. Since an EAP session is not bound to a particular authentication or specific ports on the peer and authenticator, the authenticator port or identity are not included in the Session-Id scope. The EAP Session-Id is exported by the EAP method along with the Session-Id scope, if available, and is used to construct names for other EAP keys. Note that the EAP Session-Id and scope are only known by the EAP method. As a result, the format of the EAP Session- Id and the definition of the Session-Id scope needs to be specified within the method. Appendix E defines the EAP Session-Id and scope provided by existing methods. MSK Name This key is created between the EAP peer and EAP server, and can be referred to using the string "MSK" and the EAP Session-Id. As with the EAP Session-Id, the MSK scope is defined by the EAP peer name (if securely exchanged within the method) and the EAP server name (also only if securely exchanged). Where a peer or server name is missing the null string is used. EMSK Name The EMSK can be referred to using the string "EMSK" and the EAP Session-Id. As with the EAP Session-Id, the EMSK scope is defined by the EAP peer name (if securely exchanged within the method) and the EAP server name (also only if securely exchanged). Where a peer or server name is missing the null string is used. AMSK Name AMSKs, if any, can be referred to using the string "AMSK", the key label, application data (see Section 2.6) and the EAP Session-Id. As with the EAP Session-Id, the AMSK scope is defined by the EAP peer name (if securely exchanged within the method) and the EAP server name (also only if securely exchanged). Where a peer or server name is missing the null string is used. AAA-Key Name The AAA-Key is derived from either the MSK or AMSK and so can be referred to using the MSK or AMSK names. The AAA-Key scope is provided by the concatenation of the EAP peer name (if securely provided to the authenticator), and the authenticator name (if securely provided to the peer). For the purpose of identifying the authenticator to the peer, the value of the NAS-Identifier attribute is recommended. The authenticator may include the NAS-Identifier attribute to the AAA server in an Access-Request, and the authenticator may provide the NAS-Identifier (unsecured) to the EAP peer in the EAP- Request/Identity or via a lower layer mechanism (such as the 802.11 Beacon/Probe Response). Where the NAS-Identifier is provided by the authenticator to the peer a secure mechanism is RECOMMENDED. For the purpose of identifying the peer to the authenticator, the EAP peer identifier provided within the EAP method is recommended. It cannot be assumed that the authenticator is aware of the EAP peer name used within the method. Therefore alternatives mechanisms need to be used to provide the EAP peer name to the authenticator. For example, the AAA server may include the EAP peer name in the User- Name attribute of the Access-Accept or the peer may provide the authenticator with its name via a lower layer mechanism. Absent an explicit binding step within the Secure Association Protocol, the AAA-Key is not bound to a specific peer or authenticator port. As a result, the peer or authenticator port over which the EAP conversation takes place is not included in the AAA-Key scope. PMK Name This document does not specify a naming scheme for the PMK. The PMK is only identified by the AAA-Key from which it is derived. Similarly, the PMK scope is the same as the AAA-Key scope. Note: IEEE 802.11i names the PMKID for the purposes of being able to refer to it in the Secure Association protocol; this naming is based on a hash of the PMK itself as well as some other parameters (see Section 8.5.1.2 [IEEE80211i]). TEKs The TEKs may or may not be named. Their naming is specified in the EAP method. Since the TEKs are only known by the EAP peer and server, the TEK scope is the same as the Session-Id scope. TSKs The TSKs are typically named. Their naming is specified in the Secure Association (phase 2) protocol, so that the correct set of transient session keys can be identified for processing a given packet. The scope of the TSKs is negotiated within the Secure Association Protocol. TSK creation and deletion operations are typically supported so that establishment and re-establishment of TSKs can be synchronized between the parties. In order to avoid confusion in the case where an EAP peer has more than one AAA-Key (phase 1b) applicable to establishment of a phase 2 security association, the secure Association protocol needs to utilize the AAA-Key name so that the appropriate phase 1b keying material can be identified for use in the Secure Association Protocol exchange." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Nov 14 20:42:07 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 UAA29420 for ; Sun, 14 Nov 2004 20:42:06 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C31241FC68; Sun, 14 Nov 2004 20:42:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 163161FC74; Sun, 14 Nov 2004 20:42:03 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6B06F1FC74 for ; Sun, 14 Nov 2004 20:41:10 -0500 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by mail.frascone.com (Postfix) with ESMTP id E96601FC68 for ; Sun, 14 Nov 2004 20:41:08 -0500 (EST) Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.42) id 1CTVrg-000LJO-95 for eap@frascone.com; Sun, 14 Nov 2004 20:41:08 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id iAF1exW15422 for ; Sun, 14 Nov 2004 17:41:00 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Keying-04 strawman available 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, 14 Nov 2004 17:40:59 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Based on the proposed resolutions discussed at IETF 61, I've gone ahead and generated a Keying-04 strawman document, incorporating resolutions to Issues 257, 258, 259, 262, 265, 267, 270, 272, 273, 275, and 278 as well as proposed resolutions to Issues 254 and 274 (just posted). Please have a look at the strawman -04 document in order to verify that the resolutions are acceptable: http://www.drizzle.com/~aboba/EAP/eapissues.html Note that the -04 strawman includes only relatively minor reorganizations in order to address Issue 277. However, before performing major surgery, I wanted to make sure that the patient was in reasonable shape. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Nov 14 21:42:07 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 VAA02328 for ; Sun, 14 Nov 2004 21:42:06 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D0D151FD5E; Sun, 14 Nov 2004 21:42:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 20FE71FC74; Sun, 14 Nov 2004 21:42:03 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E3B0F1FC74 for ; Sun, 14 Nov 2004 21:41:48 -0500 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by mail.frascone.com (Postfix) with ESMTP id 64BE51FC68 for ; Sun, 14 Nov 2004 21:41:47 -0500 (EST) Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.42) id 1CTWoM-0001mV-CV for eap@frascone.com; Sun, 14 Nov 2004 21:41:46 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id iAF2fiu19437 for ; Sun, 14 Nov 2004 18:41:45 -0800 From: Bernard Aboba To: eap@frascone.com In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: REMINDER: EAP Statemachine Positive Response Required 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, 14 Nov 2004 18:41:44 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Well, we have made a *bit* of progress since this request was sent: We now have positive responses from the authors of the document. While it is comforting that they have read it and approve of it, this is not enough to advance the document. We actually need an indication of approval from the *rest* of the WG! If you have read the State Machine document, and are still awake, please send a note to the EAP WG with "Statemachine: Advance" in the subject line. On Sun, 7 Nov 2004, Bernard Aboba wrote: > On September 27, 2004 we announced EAP WG Last Call on the EAP State > Machine document: > > http://mail.frascone.com/pipermail/eap/2004-September/002836.html > > As noted in the announcement, EAP WG Last Call ran until October 15, > 2004, and required a positive response, demontrating that the document had > EAP WG consensus. > > Since we only received negative comments on the WG Last > Call request, at this point it would appear that there is not WG consensus > to advance the document. > > To ensure that WG participants have the opportunity to comment, we will be > extending the EAP WG Last Call on the EAP State Machine document until > Friday, November 19, 2004. > > If you have read the document and feel it is ready for advancement, please > send a message with "Statemachine: Advance" in the Subject line to the EAP > WG mailing list, stating your reasoning. Similarly, if you have any > issues with the document, please file these using the Issues format > described at: > > http://www.drizzle.com/~aboba/EAP/eapissues.html > > Bernard > > > > > ---------------------------------------------------------------------- > Due to last minute changes in the state machine draft, we have had to > remove the State Machine document from the RFC Editor's queue, and bring > to EAP WG Last Call to confirm WG consensus. > > This is to announce EAP WG last call on the EAP State Machine draft, which > will be available here: > > http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-05.txt > http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-05.pdf > > EAP WG Last Call will last until Friday October 15, 2004. > > If you have read the draft, and believe that it is ready for forwarding to > the IESG, please reply to this mail indicating your approval of the draft. > > If you have comments, please send them to the EAP WG mailing list > (eap@frascone.com) in the format described on the EAP Issues list: > > http://www.drizzle.com/~aboba/EAP/eapissues.html > > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Nov 14 21:50:07 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 VAA02664 for ; Sun, 14 Nov 2004 21:50:06 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4F09F1FC68; Sun, 14 Nov 2004 21:50:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6694C1FC74; Sun, 14 Nov 2004 21:50:03 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 426F81FC74 for ; Sun, 14 Nov 2004 21:49:27 -0500 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by mail.frascone.com (Postfix) with ESMTP id A98E11FC68 for ; Sun, 14 Nov 2004 21:49:25 -0500 (EST) Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.42) id 1CTWvk-0005Uy-1Y for eap@frascone.com; Sun, 14 Nov 2004 21:49:24 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id iAF2nM520068 for ; Sun, 14 Nov 2004 18:49:22 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] "Pseudo-WG last call" on Identity Selection for EAP draft Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 14 Nov 2004 18:49:22 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The document "Identity Selection Hints for EAP" is not an EAP WG work item, but is requesting publication as an individual submission to the RFC Editor. Prior to publishing this document as an Informational RFC, it has been requested that the EAP WG review the document, which is available here: http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-05.txt Since this document has already gone through one EAP WG "pseudo WG last call" and has resolved the issues that were raised, we will do a short WG last call to make sure that we have caught any remaining issues. EAP WG "pseudo WG last call" will last until November 22, 2004. If you approve of publishing this document, please send a message with "Identity: Publish" in the subject to the EAP WG mailing list. If you have an issue with this document, please send comments to the EAP WG mailing list (eap@frascone.com) in the format specified in the EAP Issues list: http://www.drizzle.com/~aboba/EAP/eapissues.html _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Nov 15 00:04:06 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10452 for ; Mon, 15 Nov 2004 00:04:05 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A149B1FC68; Mon, 15 Nov 2004 00:04:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D24581FC6C; Mon, 15 Nov 2004 00:04:02 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2A2821FC6C for ; Mon, 15 Nov 2004 00:03:14 -0500 (EST) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by mail.frascone.com (Postfix) with ESMTP id 6A1B71FC68 for ; Mon, 15 Nov 2004 00:03:12 -0500 (EST) Received: from cacexg13.americas.cpqcorp.net (cacexg13.americas.cpqcorp.net [16.92.1.76]) by palrel10.hp.com (Postfix) with ESMTP id 7D39BFAE7; Tue, 16 Nov 2004 00:48:38 -0800 (PST) Received: from cacexc07.americas.cpqcorp.net ([16.92.1.32]) by cacexg13.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Sun, 14 Nov 2004 21:03:11 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <85ECA15B7BB46944BFD4C73AEA554824E8A63C@cacexc07.americas.cpqcorp.net> Thread-Topic: Statemachine: Advance Thread-Index: AcTKvLxXycSeqNypRYm9+ZpYBM4dRQAEy9Qg From: "Congdon, Paul T (ProCurve)" To: "Bernard Aboba" , X-OriginalArrivalTime: 15 Nov 2004 05:03:11.0021 (UTC) FILETIME=[6769C5D0:01C4CAD0] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Statemachine: Advance 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, 14 Nov 2004 21:03:22 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable =20 I believe this should move forward. Paul > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com]=20 > On Behalf Of Bernard Aboba > Sent: Sunday, November 14, 2004 6:42 PM > To: eap@frascone.com > Subject: [eap] Re: REMINDER: EAP Statemachine Positive=20 > Response Required >=20 > Well, we have made a *bit* of progress since this request was sent: >=20 > We now have positive responses from the authors of the document. >=20 > While it is comforting that they have read it and approve of=20 > it, this is not enough to advance the document. >=20 > We actually need an indication of approval from the *rest* of the WG! >=20 > If you have read the State Machine document, and are still=20 > awake, please send a note to the EAP WG with "Statemachine:=20 > Advance" in the subject line. >=20 > On Sun, 7 Nov 2004, Bernard Aboba wrote: >=20 > > On September 27, 2004 we announced EAP WG Last Call on the=20 > EAP State=20 > > Machine document: > > > > http://mail.frascone.com/pipermail/eap/2004-September/002836.html > > > > As noted in the announcement, EAP WG Last Call ran until=20 > October 15,=20 > > 2004, and required a positive response, demontrating that=20 > the document=20 > > had EAP WG consensus. > > > > Since we only received negative comments on the WG Last=20 > Call request,=20 > > at this point it would appear that there is not WG consensus to=20 > > advance the document. > > > > To ensure that WG participants have the opportunity to comment, we=20 > > will be extending the EAP WG Last Call on the EAP State Machine=20 > > document until Friday, November 19, 2004. > > > > If you have read the document and feel it is ready for advancement,=20 > > please send a message with "Statemachine: Advance" in the=20 > Subject line=20 > > to the EAP WG mailing list, stating your reasoning. =20 > Similarly, if you=20 > > have any issues with the document, please file these using=20 > the Issues=20 > > format described at: > > > > http://www.drizzle.com/~aboba/EAP/eapissues.html > > > > Bernard > > > > > > > > > >=20 > ---------------------------------------------------------------------- > > Due to last minute changes in the state machine draft, we=20 > have had to=20 > > remove the State Machine document from the RFC Editor's queue, and=20 > > bring to EAP WG Last Call to confirm WG consensus. > > > > This is to announce EAP WG last call on the EAP State=20 > Machine draft,=20 > > which will be available here: > > > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-05.txt > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-05.pdf > > > > EAP WG Last Call will last until Friday October 15, 2004. > > > > If you have read the draft, and believe that it is ready for=20 > > forwarding to the IESG, please reply to this mail=20 > indicating your approval of the draft. > > > > If you have comments, please send them to the EAP WG mailing list > > (eap@frascone.com) in the format described on the EAP Issues list: > > > > http://www.drizzle.com/~aboba/EAP/eapissues.html > > > > > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap >=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From necessary0@go.com Mon Nov 15 01:39:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15610; Mon, 15 Nov 2004 01:39:53 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTaYj-0000L5-Sb; Mon, 15 Nov 2004 01:41:55 -0500 Received: from [211.196.63.225] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1CTaWi-0001hJ-7W; Mon, 15 Nov 2004 01:39:48 -0500 Received: from 24.86.159.29 (HELO antelope2cosine3cradle2.conquerortopaz.tv) by triumphant@captain.net (2.0.017) Received: from tsaa.tv by clergymen@germicidal.tv (2.0.012) X-MID: Message-Id: Date: Sun, 14 Nov 2004 23:34:24 -0700 From: "Angelo Bland" To: eap-archive@ietf.org Cc: entmib@ietf.org, entmib-request@ietf.org, geopriv-admin@ietf.org, idr@ietf.org, iesg@ietf.org, iesg-secretary@ietf.org, ietf-announce-request@ietf.org, ietf-proceedings@ietf.org, ietf-registrar@ietf.org, ietf-rsvp@ietf.org, ietf-web@ietf.org, ifmib@ietf.org, imrg-web-archive@ietf.org, imss-admin@ietf.org Subject: RE account# TC8221292 X-NAS-Classification: 1 X-NAS-MessageID: 439 X-NAS-Validation: {3ED76BFB-4B37-45EC-95DD-10740EBCD4BF} MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Message-flag: Authentic Sender, Hash: FgJwMwWp Content-Disposition: inline X-Spam-Score: 5.1 (+++++) X-Spam-Flag: YES X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit bonaventure
SAVE 70% on RX Medication TODAY!
Order all your RX Medication directly from our FDA-approved manufacturers.
Over 60 products to choose from! Save up to 70% on your RX drugs.
Average shipping takes 1-2 weeks but our prices and quality make it worth the wait.
All packages are shipped discreetly by Airmail WORLDWIDE.
Choose your medication, point, click, order and you're done. Your medication is on it's way! No prescription required!
From vyacjykhmbvcepv@mindspring.com Mon Nov 15 05:39:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14525; Mon, 15 Nov 2004 05:39:31 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTeIh-00049w-HQ; Mon, 15 Nov 2004 05:41:36 -0500 Received: from user-0cdfbb1.cable.mindspring.com ([24.215.173.97]) by mx2.foretec.com with smtp (Exim 4.24) id 1CTeGh-0007Q2-JI; Mon, 15 Nov 2004 05:39:32 -0500 Received: from mx06.mindspring.com by user-0cdfbb1.cable.mindspring.com with SMTP id epkgum; Mon, 15 Nov 2004 03:26:57 -0600 Received: from 22.188.60.185 by mx06.mindspring.com with esmtp (Exim 3.36 #5); Mon, 15 Nov 2004 03:26:33 -0600 Content-Transfer-Encoding: 7bit Message-ID: <4ukjcQYNL1lqI4.2b1lU@VDDAFN> To: pkzfi@mindspring.com X-Mailer: it for laugh it Hacross our inert mvwiwi Content-Type: text/html; charset=WINDOWS-1258; Subject: Re: Online MIME-Version: 1.0 Date: Mon, 15 Nov 2004 03:26:07 -0600 From: "Lou B. Pollock" X-Spam-Score: 8.9 (++++++++) X-Spam-Flag: YES X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit a brushlike electress our pontificate to songful, an nashua
Hello,

You can . r e finance your mortga g e . with 4.15 % . ra t e
and reduce your monthly payment at least twice. One minute can
save you t h ousands. hornblende not me for friend not for me from runty we to myofibril - already adams on cia memento ten or Jincomputable with in fringe
Your application is . approv e d.
uwiuuxg

Thank you,

Lou B. Pollock
HCW Group
pizza alberta of no i'm are keauzvnfn
I for at an anxiety juniper zrcsskndb
backlog it us no nm hafnium nubia a me insulate Xsimplistic dictate Gspume conference truism Qgraph pemmican pie, to doorkeeper the us not via monologue
portuguese? was coquina. dramatic the I for an akytzay
dignify - oar excisable astute - as ozwwxpmmk
the seventeenth snip not adele qolmrdhea
brownie aftermath, durable no emcee with as doggone splay Sguide prudent in dagger applicable the dynamic not Ldescant locke
we attainder. was plug. a ducat pyurkyz
correlate, litmus carlisle in repudiate as the jxunvjrec
certify itsnevada me effeminate quick the no Hparadise or electrolyte breakfast - conservator? decree practise analyses - teeth stamp. incomprehension moiety - scriptural dehumidify sol Gmidwives u's deride and we was housefly
me is soprano amperage, any for dumb uproot kwjpt
the cowhide almost was noticeable the it for calais multiplicative no crosby be Eschizoid blutwurst to at Jquackery brazier? for assai astray atrophic Oalec fatten be a blaine? dutiful we brett
footwork - it mathewson sidestep cobb vpfluo From YYEJOMNJDHIRK@salu.net Mon Nov 15 07:36:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20907 for ; Mon, 15 Nov 2004 07:36:00 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTg7H-0005tJ-1g for eap-archive@ietf.org; Mon, 15 Nov 2004 07:38:05 -0500 Received: from host243-218.pool8174.interbusiness.it ([81.74.218.243]) by mx2.foretec.com with smtp (Exim 4.24) id 1CTg58-00022a-3v for eap-archive@ietf.org; Mon, 15 Nov 2004 07:35:51 -0500 Received: from 112.178.10.231 by fattengallivant ([81.74.218.243]) with SMTP; Mon, 15 Nov 2004 04:35:31 -0800 Message-ID: <77z929p092f3$7615177h@mexico.com> Reply-To: "Trina Pugh" From: "Trina Pugh" To: eamoby@ietf.org Subject: Let's chat :) Date: Mon, 15 Nov 2004 04:35:31 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007A_4040227244464853" X-Spam-Score: 24.1 (++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_007A_4040227244464853 Content-Type: text/html; Content-Transfer-Encoding: 7Bit Hi ! I'm a young lady looking for fun mostly :)
Nothing serious for now but who knows where it might get us !

John told me you and I would fit well together. (he is a member of the same dating site as I am, and recommended you) .

So if you would like to see my profile, I'm the 3rd girl in the first row .

I also got a webcam, so we can have some fun :)

Hit this link to see my profile




If you don't wanna receive my emails anymore you can click here http://[dradfa].miedcbbj.info/?lmT3TXSsLpYvB9R[asdf] ------=_NextPart_000_007A_4040227244464853-- From eap-admin@frascone.com Mon Nov 15 07:55:07 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 HAA21756 for ; Mon, 15 Nov 2004 07:55:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5D77D1FD52; Mon, 15 Nov 2004 07:55:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DC2FC1FCC9; Mon, 15 Nov 2004 07:55:02 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 468BC1FCCA for ; Mon, 15 Nov 2004 07:54:45 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 705261FCC9 for ; Mon, 15 Nov 2004 07:54:43 -0500 (EST) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id F2BE989877; Mon, 15 Nov 2004 14:54:40 +0200 (EET) Message-ID: <4198A6A4.5090306@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] "Pseudo-WG last call" on Identity Selection for EAP draft 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: Mon, 15 Nov 2004 14:52:52 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I have reviewed the document and it is OK from my point of view. No issues to report. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Nov 15 08:03:07 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 IAA22390 for ; Mon, 15 Nov 2004 08:03:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0CBC91FC68; Mon, 15 Nov 2004 08:03:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 66E001FCC9; Mon, 15 Nov 2004 08:03:03 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AE7071FCC9 for ; Mon, 15 Nov 2004 08:02:29 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 0D21A1FC68 for ; Mon, 15 Nov 2004 08:02:27 -0500 (EST) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id ABC4E89877; Mon, 15 Nov 2004 15:02:26 +0200 (EET) Message-ID: <4198A876.4030201@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 References: <85ECA15B7BB46944BFD4C73AEA554824E8A63C@cacexc07.americas.cpqcorp.net> In-Reply-To: <85ECA15B7BB46944BFD4C73AEA554824E8A63C@cacexc07.americas.cpqcorp.net> 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] Statemachine: Advance 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, 15 Nov 2004 15:00:38 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I have reviewed the document (again) and believe it should advance. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Nov 15 08:22:07 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 IAA23730 for ; Mon, 15 Nov 2004 08:22:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 315151FC68; Mon, 15 Nov 2004 08:22:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7DA491FCCA; Mon, 15 Nov 2004 08:22:03 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6B4991FCCA for ; Mon, 15 Nov 2004 08:21:46 -0500 (EST) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by mail.frascone.com (Postfix) with ESMTP id 963F31FC68 for ; Mon, 15 Nov 2004 08:21:44 -0500 (EST) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id iAFDLFBO018473 for ; Mon, 15 Nov 2004 14:21:28 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id iAFDKuBO005385 for ; Mon, 15 Nov 2004 14:20:56 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Mon, 15 Nov 2004 14:20:56 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0531A6A4@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: eap@frascone.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Identity: Publish 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, 15 Nov 2004 14:20:47 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) hi all, please move forward with . with the work on we came to the conclusion that is a very important piece of work. ciao hannes _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Nov 15 09:41:09 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 JAA28416 for ; Mon, 15 Nov 2004 09:41:08 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 069401FD6E; Mon, 15 Nov 2004 09:41:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BA8CE1FD43; Mon, 15 Nov 2004 09:41:03 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 79F171FD40 for ; Mon, 15 Nov 2004 09:40:34 -0500 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by mail.frascone.com (Postfix) with ESMTP id CC6761FCCA for ; Mon, 15 Nov 2004 09:40:32 -0500 (EST) Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.42) id 1CTi1v-000Mow-Bt for eap@frascone.com; Mon, 15 Nov 2004 09:40:31 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id iAFEePN02903 for ; Mon, 15 Nov 2004 06:40:30 -0800 From: Bernard Aboba To: eap@frascone.com In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: Keying-04 strawman available 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, 15 Nov 2004 06:40:25 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Here is the URL for the -04 document: http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-keying-04.txt On Sun, 14 Nov 2004, Bernard Aboba wrote: > Based on the proposed resolutions discussed at IETF 61, I've gone ahead > and generated a Keying-04 strawman document, incorporating resolutions to > Issues 257, 258, 259, 262, 265, 267, 270, 272, 273, 275, and 278 > as well as proposed resolutions to Issues 254 and 274 (just posted). > > Please have a look at the strawman -04 document in order to verify that > the resolutions are acceptable: > > http://www.drizzle.com/~aboba/EAP/eapissues.html > > Note that the -04 strawman includes only relatively minor reorganizations > in order to address Issue 277. However, before performing major surgery, I > wanted to make sure that the patient was in reasonable shape. > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Nov 15 11:04:09 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 LAA05146 for ; Mon, 15 Nov 2004 11:04:08 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 537571FD5E; Mon, 15 Nov 2004 11:04:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B19431FCB7; Mon, 15 Nov 2004 11:04:03 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B7F8C1FCB7 for ; Mon, 15 Nov 2004 11:03:25 -0500 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by mail.frascone.com (Postfix) with ESMTP id E42871FC68 for ; Mon, 15 Nov 2004 11:03:23 -0500 (EST) Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.42) id 1CTjK5-000Kg5-Ta for eap@frascone.com; Mon, 15 Nov 2004 11:03:22 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id iAFG3KY08470 for ; Mon, 15 Nov 2004 08:03:20 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: [Issue 277]: Organizational Improvements 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, 15 Nov 2004 08:03:20 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) In order to explore ways to improve the organization of the material now in the Key Management Framework document, I'd like to propose that we structure the discussion as follows: a. First, talk about ways of reorganizing the material in the existing document. This could include reorganizing a single document, or splitting the existing document into two parts. The goal of this phase of the conversation is to come to consensus on the strategy for the reorganization. Once this is done, we can issue the reorganized document(s) as EAP WG work items. b. Once we've settled on a strategy for reorganization, then we can talk about sections of the document(s) that need to be changed, added or deleted. We will use the standard issue tracking procedure for this purpose. In order to stimulate the conversation described in a), I've gone ahead and put together two drafts, one a standards track document focussing on standardization of the EAP key hierarchy, and the other one an Informational document that describes the EAP/AAA/SAP system, and analyzes its security. Here are the links: http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-keyhier-00.txt http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-keyarch-00.txt Note that all the material in the strawman -04 document has been included in one of these two documents. In going over the split, there were quite a few places where the division between the two documents was far from clear, and as a result there is some duplication. If you'd like to propose an alternative organization of the existing material, please reply to this message and include your own proposed table of contents for one or both of the documents. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Nov 15 11:52:08 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 LAA10052 for ; Mon, 15 Nov 2004 11:52:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 316921FC68; Mon, 15 Nov 2004 11:52:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 780051FC70; Mon, 15 Nov 2004 11:52:03 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D87D91FC70 for ; Mon, 15 Nov 2004 11:51:35 -0500 (EST) Received: from cingular.com (extmail06.cingular.com [170.35.209.249]) by mail.frascone.com (Postfix) with ESMTP id 3B2B11FC68 for ; Mon, 15 Nov 2004 11:51:30 -0500 (EST) Received: from ([135.214.42.163]) by extmail06.cingular.com with ESMTP id KP-TRPY2.8960507; Mon, 15 Nov 2004 11:50:56 -0500 Received: from neastmail.entp.attws.com (localhost [127.0.0.1]) by viruswall.entp.attws.com (8.12.10/8.12.10) with ESMTP id iAFGosAL010387 for ; Mon, 15 Nov 2004 08:50:55 -0800 (PST) Received: from WA-MSGBH01-BTH.wireless.attws.com (WA-MSGBH01-BTH.wireless.attws.com [135.214.26.241]) by neastmail.entp.attws.com (8.8.8p2+Sun/8.8.8) with ESMTP id IAA28849 for ; Mon, 15 Nov 2004 08:50:55 -0800 (PST) Received: from WA-MSG10-BTH.wireless.attws.com ([135.214.41.74]) by WA-MSGBH01-BTH.wireless.attws.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 15 Nov 2004 08:50:49 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: Identity: Publish Thread-Index: AcTLFiAlZdY/pQA+QmeAf1u0rNdx7QAHF0DA From: "Bari, Farooq" To: X-OriginalArrivalTime: 15 Nov 2004 16:50:49.0824 (UTC) FILETIME=[42D4F600:01C4CB33] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Identity: Publish 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, 15 Nov 2004 08:50:49 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Yes pls go ahead with the publication of the draft. Actually I figured from Jari's response to my email a week ago on the reflector that we had actually passed the eap WG last call and were good to go to IESG..... BR, Farooq _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Nov 15 15:38:16 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00337 for ; Mon, 15 Nov 2004 15:38:12 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 618EE1FC68; Mon, 15 Nov 2004 15:38:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BE9541FC71; Mon, 15 Nov 2004 15:38:03 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 32A421FC71 for ; Mon, 15 Nov 2004 15:37:15 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.frascone.com (Postfix) with ESMTP id D2D561FC68 for ; Mon, 15 Nov 2004 15:37:12 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00222; Mon, 15 Nov 2004 15:37:00 -0500 (EST) Message-Id: <200411152037.PAA00222@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: eap@frascone.com From: Internet-Drafts@ietf.org X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] I-D ACTION:draft-ietf-eap-keying-04.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, 15 Nov 2004 15:37:00 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Authentication Protocol Working Group of the IETF. Title : Extensible Authentication Protocol (EAP) Key Management Framework Author(s) : B. Aboba, et al. Filename : draft-ietf-eap-keying-04.txt Pages : 73 Date : 2004-11-15 The Extensible Authentication Protocol (EAP), defined in [RFC3748], enables extensible network access authentication. This document provides a framework for the generation, transport and usage of keying material generated by EAP authentication algorithms, known as 'methods'. It also specifies the EAP key hierarchy. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eap-keying-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eap-keying-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-11-15155830.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eap-keying-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eap-keying-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-15155830.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From aishawasim5@yahoo.co.uk Mon Nov 15 16:09:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06831; Mon, 15 Nov 2004 16:09:54 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTo8o-0000tq-Ue; Mon, 15 Nov 2004 16:12:05 -0500 Received: from [213.154.87.2] (helo=2mails1386.com) by mx2.foretec.com with smtp (Exim 4.24) id 1CTo4Y-0007j6-VH; Mon, 15 Nov 2004 16:07:39 -0500 From: "Mrs.Aisha Wasim" Reply-To: aishawasim2@fastermail.com Date: Mon, 15 Nov 2004 20:04:01 +0100 Subject: good day. X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: X-Spam-Score: 5.6 (+++++) X-Spam-Flag: YES X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable THE PRESIDENT =2F CEO=2E Dear Sir=2FMadam=2C RE=3A JOINT VENTURE=2E I would like to apply through this medium for your co-operation and to secure an opportunity to invest and do joint business with you in your country=2E I have a substantial capital I honorably intend to invest in your country into a very lucrative venture of which you are to advise and execute the said venture over there for the mutual benefits of both of us=2E Your able co-operation is to become my business partner in your country and create ideas on how money will be invested=2C probably managed and the type of investment after the money is transferred to your custody with your assistance=2E Meanwhile=2C on indication of your willingness to handle this transaction sincerely by protecting our interests and upon your acceptance of this proposal=2C I would furnish you with the full detailed information=2C procedure=2C amount involve and mutual agreement on your percentage interest or share holding for helping me to secure the release of the deposit and investing the money=2E I shall be glad to reserve this respect and opportunity for you=2Cif you so desire=2C but do urge you to give the matter your immediate attention it deserves=2E Looking forward to your response=2E Mrs=2E Aisha Wasim=2E From mi5build@comteck.com Mon Nov 15 23:18:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29276; Mon, 15 Nov 2004 23:18:03 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTupF-0002Rn-Gp; Mon, 15 Nov 2004 23:20:18 -0500 Received: from [200.71.45.156] (helo=cr2007145156.cable.net.co) by mx2.foretec.com with smtp (Exim 4.24) id 1CTumw-0001i6-1x; Mon, 15 Nov 2004 23:17:58 -0500 Received: from mail.ttlc.net (200.71.45.156) by 200.71.45.156 (pathwayv.21) with SMTP id <405472733a2r> (Authid: 726688); Tue, 16 Nov 2004 06:18:12 +0300 X-Message-Info: 51269720d Reply-To: "Jeanne.Fusier Finnegan" From: "Jeanne.Fusier Finnegan" To: pr-wg@ietf.org Cc: eap-archive@ietf.org, tsvwg-request@ietf.org, usic-admin@ietf.org, policy@ietf.org, vrrp@ietf.org, ietf@ietf.org, mailman-owner@ietf.org, sip-security@ietf.org Subject: Credit Card: $ 201852 Date: Tue, 16 Nov 2004 09:19:12 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--463940951138861" Message-Id: X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab ----463940951138861 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7Bit Dear Applicant, Your application was processed and approved. You are eligible for $ 400,000 with a 2.1 % rate. Please verify your information here: http://www.bellmarketing4us.com/green/m79a We look forward to hearing from you. Jeanne.Fusier Finnegan, Account Manager Bell Marketing 4206 Central Avenue Columbus, OH 43085 not interested -> http://www.bellmarketing4us.com/green/stop.html ----463940951138861-- From eap-admin@frascone.com Tue Nov 16 04:03:16 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05982 for ; Tue, 16 Nov 2004 04:03:13 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9FBD01FC67; Tue, 16 Nov 2004 04:03:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A9F441FC68; Tue, 16 Nov 2004 04:03:03 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 58FB21FC68 for ; Tue, 16 Nov 2004 04:02:54 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 534281FC67 for ; Tue, 16 Nov 2004 04:02:52 -0500 (EST) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 2CFE489889; Tue, 16 Nov 2004 11:02:50 +0200 (EET) Message-ID: <4199C1CD.9070602@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] Proposed Resolution to Issue 254: Key Lifetime Issues References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 16 Nov 2004 11:01:01 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Bernard, Looks good! A couple of nits inline: > "2.3. Key Lifetimes > > Key lifetime issues are discussed in the sections that follow. > Issues include: > > [a] Key lifetime negotiation. Where key lifetimes cannot be assumed, > it may be necessary to negotiate them. Where negotiation is > supported, it is RECOMMENDED that the negotiation be secured. Note > that key lifetime negotiation may not always be required. A > difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes > were negotiated. In IKEv2, each end of the SA is responsible for > enforcing its own lifetime policy on the SA and rekeying the SA > when necessary. The reader may wonder why we suddenly talk about IKE. Suggest s/A difference/To take an example from IKE, the difference/ > [b] Key resynchronization. It is possible for the peer or > authenticator to reboot or reclaim resources, clearing portions or > all of the key cache. Therefore, key lifetime negotiation cannot > guarantee that the key cache will remain synchronized, and the peer > may not be able to determine before attempting to use it whether a > particular key exists within the authenticator cache. It is > therefore RECOMMENDED for the lower layer to provide a mechanism > for key state resynchronization. Since in this situation one or > more of the parties initially do not possess a key with which to > protect the resynchronization exchange, securing this mechanism may > be difficult. > > 2.3.1. Parent-child relationships > > When keying material exported by EAP methods expires, all keying > material derived from the exported keying material, (including the > AAA-Key, AMSKs and TSKs) also expires. > > Similarly, when an EAP reauthentication takes place, new keying > material is derived and exported by the EAP method, which eventually > results in replacement of calculated keys, including the AAA-Key, > AMSKs, and TSKs. > > As a result, the lifetime of keys calculated from the exported keying > material can be no longer than the lifetime of the exported keying > material itself. However, the lifetime of calculated keys can be > less than that of the exported keys. For example, TSK rekey may > occur prior to EAP reauthentication. > > Note that deletion of the AAA-Key does not necessarily imply deletion > of the corresponding TSKs. Replacement or deletion of TSKs only > implies replacement of the AAA-Key when the TSKs are taken from a > portion of the AAA-Key. I do not understand this paragraph. The first part appears to claim that TSKs can break the death-of-the-parent rule. The second part appears to claim that AAA-Key gets changed because it is used twice. Or maybe the latter is something that we do want to mandate, but the text still reads funny, it sounds like the requirement only exists if we take a part of AAA-Key, not all of it. Or did you want to say that when TSKs are bit-by-bit copies of the AAA-Keys parts, then we throw that part away? > Failure to mutually prove possession of the AAA-Key during the Secure > Association Protocol exchange need not be grounds for deletion of the > AAA-Key by both parties; rate-limiting Secure Association Protocol > exchanges could be used to prevent a brute force attack. > > 2.3.2. Local Key Lifetimes > > The Transient EAP Keys (TEKs) are session keys used to protect the > EAP conversation. The TEKs are internal to the EAP method and are > not exported. TEKs are typically created during an EAP conversation, > used until the end of the conversation and then discarded. However, > methods may rekey TEKs during a conversation. > > When using TEKs within an EAP conversation or across conversations, > it is necessary to ensure that replay protection and key separation > requirements are fulfilled. For instance, if a replay counter is > used, TEK rekey MUST occur prior to wrapping of the counter. > Similarly, TSKs MUST remain cryptographically separate from TEKs > despite TEK rekeying or caching. This prevents TEK compromise from > leading directly to compromise of the TSKs and vice versa. > > EAP methods may cache local keying material which may persist for > multiple EAP conversations when fast reconnect is used [RFC 3748]. > For example, EAP methods based on TLS (such as EAP-TLS [RFC2716]) > derive and cache the TLS Master Secret, typically for substantial > time periods. The lifetime of other local keying material calculated > within the EAP method is defined by the method. Note that in > general, when using fast reconnect, there is no guarantee to that the > original long-term credentials are still in the possession of the > peer. For instance, a card hold holding the private key for EAP-TLS > may have been removed. EAP servers should verify that the long-term > credentials are still valid, such as by checking that certificate > used in the original authentication has not yet expired. > > 2.3.3. Exported and Calculated Key Lifetimes > > All EAP methods generating keys are required to generate the MSK and > EMSK, and may optionally generate the IV. Existing EAP methods do > not negotiate the lifetime of the exported keys. EAP, defined in > [RFC3748], also does not support the negotiation of lifetimes for > exported keying material such as the MSK, EMSK and IV. > > Several mechanisms exist for managing key lifetimes: > > [a] AAA attributes. AAA protocols such as RADIUS [RFC2865] and > Diameter [DiamEAP] support the Session-Timeout attribute. The > Session-Timeout value represents the maximum lifetime of the > exported keys, and all keys calculated from it, in all > circumstances. The AAA server MUST expire the exported keys, and > all keys calculated from them, prior to the future time indicated Is it really "prior to"? Not "latest at"? > by Session-Timeout. On the authenticator, where EAP is used for > authentication, the Session-Timeout value represents the maximum > session time prior to re-authentication, as described in [RFC3580]. > Where EAP is used for pre-authentication, the session may not start > until some future time, or may never occur. Nevertheless, the > Session-Timeout value represents the time after which the AAA-Key, > and all keys calculated from it, will have expired on the > authenticator. If the session subsequently starts, re- > authentication will be initiated once the Session-Time has expired. > If the session never started, or started and ended, the AAA-Key and > all keys calculated from it will be expired by the authenticator > prior to the future time indicated by Session-Timeout. > > Since the TSK lifetime is often determined by authenticator > resources, the AAA server has no insight into the TSK derivation > process, and by the principle of ciphersuite independence, it is > not appropriate for the AAA server to manage any aspect of the TSK > derivation process, including the TSK lifetime. > > [b] Lower layer mechanisms. While AAA attributes can communicate the > maximum exported key lifetime, this only serves to synchronize the > key lifetime between the backend authentication server and the > authenticator. Lower layer mechanisms can then be used to enable > the lifetime of exported and calculated keys to be negotiated > between the peer and authenticator. > > Where TSKs are established as the result of a Secure Association > Protocol exchange, it is RECOMMENDED that the Secure Association > Protocol include secure negotiation of the TSK lifetime between the > peer and authenticator. Where the TSK is taken from the AAA-Key, Why do we recommend this? What if the lower layer uses the IKEv2 principle? > there is no need to manage the TSK lifetime as a separate > parameter, since the TSK lifetime and AAA-Key lifetime are > identical. > > [c] System defaults. Where the EAP method does not support the > negotiation of the exported key lifetime, and a negotiation > mechanism is not provided by the lower lower, there may be no way > for the peer to learn knowledge of the exported key liftime. In > this case it is RECOMMENDED that the peer assume a default value of > the exported key lifetime; 8 hours is suggested. Similarly, the > lifetime of calculated keys can also be managed as a system > parameter on the authenticator. > > 2.3.4. Key cache synchronization > > Issues arise when attempting to synchronize the key cache on the peer > and authenticator. Lifetime negotiation alone cannot guarantee key > cache synchronization. > > One problem is that the AAA protocol cannot guarantee synchronization > of key lifetimes between the peer and authenticator. Where the > Secure Association Protocol is not run immediately after EAP > authentication, the exported and calculated key lifetimes will not be > known by the peer during the hiatus. Where EAP pre-authentication > occurs, this can leave the peer uncertain whether a subsequent > attempt to use the exported keys will prove successful. > > However, even where the Secure Association Protocol is run > immediately after EAP, it is still possible for the authenticator to > reclaim resources if the created key state is not immediately > utilized. > > The lower layer may utilize Discovery mechanisms to assist in this. > For example, the authenticator manages the AAA-Key cache by deleting > the oldest AAA-Key first (LIFO), the relative creation time of the > last AAA-Key to be deleted could be advertised with the Discovery > phase, enabling the peer to determine whether a given AAA-Key had > been expired from the authenticator key cache prematurely." --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From hocprxj@comcast.net Tue Nov 16 05:08:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10921; Tue, 16 Nov 2004 05:08:45 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU0If-000115-C2; Tue, 16 Nov 2004 05:11:02 -0500 Received: from pcp05892528pcs.hamntn01.nj.comcast.net ([68.44.172.242]) by mx2.foretec.com with smtp (Exim 4.24) id 1CU0GQ-00020E-0b; Tue, 16 Nov 2004 05:08:44 -0500 Received: from gateway-r.comcast.net by pcp05892528pcs.hamntn01.nj.comcast.net with Microsoft SMTPSVC; Tue, 16 Nov 2004 02:55:55 -0600 Received: from 52.87.150.131 by gateway-r.comcast.net with SMTP; Tue, 16 Nov 2004 02:55:27 -0600 Content-Type: text/plain; charset="iso-8859-10" Subject: madmen, there's no denying Content-Transfer-Encoding: 7bit To: Logan Mime-Version: 1.0 Date: Tue, 16 Nov 2004 02:54:50 -0600 From: "Rhonda K. Mcnamara" Message-ID: <6897993971491226-4100451@comcast.net> X-Spam-Score: 6.0 (++++++) X-Spam-Flag: YES X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Final Notice! We have tried to contact you 2 times, with no success. Your lo an has been appr o ved at 4.o %, but we need more information from you. This will only take a second, then a representative will contact you. secure link for AppID 05682 http://www.ftgoal.com/ Thanks Rhonda K. Mcnamara in on confirmatory of deface clapeyron a towhead upkeep? it seraphim carne Bperson so despicable astigmat Ljudith demarcate? us charon balcony at are no amazon kept - chatty with arpeggio to anarchic at hypothyroid? supply diesel From eap-admin@frascone.com Tue Nov 16 07:11:07 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 HAA21353 for ; Tue, 16 Nov 2004 07:11:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 853ED1FC0E; Tue, 16 Nov 2004 07:11:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E18E81FC7A; Tue, 16 Nov 2004 07:11:03 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 09A881FC7A for ; Tue, 16 Nov 2004 07:10:50 -0500 (EST) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by mail.frascone.com (Postfix) with ESMTP id 402BB1FC0E for ; Tue, 16 Nov 2004 07:10:47 -0500 (EST) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id iAGCAkrJ027597; Tue, 16 Nov 2004 13:10:46 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id iAGCAjBO010025; Tue, 16 Nov 2004 13:10:45 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Tue, 16 Nov 2004 13:10:45 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0531A79D@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: Bernard Aboba , eap@frascone.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Statemachine: Advance 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, 16 Nov 2004 13:10:43 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) hi bernard, hi all, my student udo schilcher has used the eap state machine draft to implement ikev2, a test program for eap-ikev2 and other students used it for our pana implementation. we think that the eap state machine draft was very helpful and allowed us to produce a solid implementation within a short timeframe. please move forward with this document. furthemore, we used the eap state machine draft as a template to produce state machines for nsis protocols (for gimps and the qos nslp). we are convinced that state machines should be used more often in the ietf environment since they help implementors and the protocol designers. thanks for the good work on the eap state machine! ciao hannes > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Montag, 15. November 2004 03:42 > To: eap@frascone.com > Subject: [eap] Re: REMINDER: EAP Statemachine Positive > Response Required > > Well, we have made a *bit* of progress since this request was sent: > > We now have positive responses from the authors of the document. > > While it is comforting that they have read it and approve of > it, this is not enough to advance the document. > > We actually need an indication of approval from the *rest* of the WG! > > If you have read the State Machine document, and are still > awake, please send a note to the EAP WG with "Statemachine: > Advance" in the subject line. > > On Sun, 7 Nov 2004, Bernard Aboba wrote: > > > On September 27, 2004 we announced EAP WG Last Call on the > EAP State > > Machine document: > > > > http://mail.frascone.com/pipermail/eap/2004-September/002836.html > > > > As noted in the announcement, EAP WG Last Call ran until > October 15, > > 2004, and required a positive response, demontrating that > the document > > had EAP WG consensus. > > > > Since we only received negative comments on the WG Last > Call request, > > at this point it would appear that there is not WG consensus to > > advance the document. > > > > To ensure that WG participants have the opportunity to comment, we > > will be extending the EAP WG Last Call on the EAP State Machine > > document until Friday, November 19, 2004. > > > > If you have read the document and feel it is ready for advancement, > > please send a message with "Statemachine: Advance" in the > Subject line > > to the EAP WG mailing list, stating your reasoning. > Similarly, if you > > have any issues with the document, please file these using > the Issues > > format described at: > > > > http://www.drizzle.com/~aboba/EAP/eapissues.html > > > > Bernard > > > > > > > > > > > ---------------------------------------------------------------------- > > Due to last minute changes in the state machine draft, we > have had to > > remove the State Machine document from the RFC Editor's queue, and > > bring to EAP WG Last Call to confirm WG consensus. > > > > This is to announce EAP WG last call on the EAP State > Machine draft, > > which will be available here: > > > > > http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-05.txt > > > http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-05.pdf > > > > EAP WG Last Call will last until Friday October 15, 2004. > > > > If you have read the draft, and believe that it is ready for > > forwarding to the IESG, please reply to this mail > indicating your approval of the draft. > > > > If you have comments, please send them to the EAP WG mailing list > > (eap@frascone.com) in the format described on the EAP Issues list: > > > > http://www.drizzle.com/~aboba/EAP/eapissues.html > > > > > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From bulletin@staffadministrator.com Tue Nov 16 07:12:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21414 for ; Tue, 16 Nov 2004 07:12:37 -0500 (EST) Received: from c-24-2-42-202.client.comcast.net ([24.2.42.202]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CU2EE-0003g9-6Q for eap-archive@ietf.org; Tue, 16 Nov 2004 07:14:56 -0500 Received: from gv1s1.mau0e4.com [212.213.80.162] by c-24-2-42-202.client.comcast.net with ESMTP id 18862009; Tue, 16 Nov 2004 17:04:44 +0500 Message-ID: From: "Administrator" To: -archive@ietf.org Subject: ADV: Staff Announcement Date: Tue, 16 Nov 04 17:04:44 GMT X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 5.50.4133.2400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="E_2.06.F9_31DA1C9.1DF" X-Spam-Score: 19.5 (+++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d This is a multi-part message in MIME format. --E_2.06.F9_31DA1C9.1DF Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Attention All Nonprofit Organizations: Members and Staff You Must Respond By 5 P.M. Wednesday, November 17, 2004. Through a special arrangement, Avtech Direct is offering a limited allotment of BRAND NEW, top of-the-line, name-brand desktop computers at more than 50% off MSRP to all Nonprofit Members and Staff who respond to this message before 5 P.M., Wednesday, November 17, 2004 All desktop computers are brand-new packed in their original boxes, and come with a full manufacturer's warranty plus a 100% satisfaction guarantee. These professional grade Desktops are fully equipped with 2005 next generation technology, making these the best performing computers money can buy. Avtech Direct is offering these feature rich, top performing Desktops with the latest technology at an amazing price to all who call: 1-800-795-8466 by 5 P.M. Wednesday, November 17, 2004 The fast and powerful AT-3200 series Desktop features: * IBM Processor for amazing speed and performance * 128MB DDR RAM, -- Upgradeable to 1024 * 20 GB UDMA Hard Drive, -- Upgradeable to 80 GB * 52X CD-Rom Drive, -- Upgradeable to DVD/CDRW * Next Generation 2005 Technology * Premium video and sound -- For enhanced colors and graphics * Full Connectivity with Fax modem/Lan/IEE 1394/USB 2.0 * Soft Touch Keyboard and scroll mouse * Internet Ready * Network Ready * 1 Year parts and labor warranty * Priority customer service and tech support MSRP $499 ........................................ Your Cost $227 How to qualify: 1. You must be a Member, Staff or Associate of a Nonprofit. 2. All desktop computers will be available on a first come first serve basis. 3. You must call 1-800-795-8466 by 5 P.M. Wednesday, November 17, 2004. and we will hold the desktops you request on will call. 4. You are not obligated in any way. 5. 100% Satisfaction Guaranteed. 6. Ask for Department C. Call Avtech Direct 1-800-795-8466 before 5 P.M. Wednesday, November 17, 2004 Visit our website at http://www.avtechcomputers.com If you wish to unsubscribe from this list, please go to http://www./www.avtechcomputers.com/announcements.asp Avtech Direct 22647 Ventura Blvd. Suite 374 Woodland Hills, CA 91364 --E_2.06.F9_31DA1C9.1DF-- From rezowqg@yahoo.com Tue Nov 16 10:26:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09102; Tue, 16 Nov 2004 10:26:49 -0500 (EST) Date: Tue, 16 Nov 2004 10:26:49 -0500 (EST) Received: from user-212-88-248-5.tvcablenet.be ([212.88.248.5]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CU5GW-00085x-Hh; Tue, 16 Nov 2004 10:29:09 -0500 Received: from 14.110.152.217 by 212.88.248.5; Tue, 16 Nov 2004 18:21:06 +0300 Message-ID: From: "Ivory Amos" Reply-To: "Ivory Amos" To: e3@ietf.org, eamoby@ietf.org, eap-archive@ietf.org, edu-team@ietf.org, edu-team-web-archive@ietf.org, entmib@ietf.org, entmib-admin@ietf.org, entmib-request@ietf.org, enum@ietf.org Subject: Woww..8o-% 0ff E3 X-Spam-Score: 9.8 (+++++++++) X-Spam-Flag: YES X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d User ID: 3 ideology Date: Tue, 16 Nov 2004 20:16:06 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--18494056039168932" ----18494056039168932 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit E3 Buy Med's 0n-line! Up to 8o% off Cia|is, V|agra, Xanax, Vioxx, Valium and many more! Fast delivery! with wholesale prices! -No Con^sultation -No Prior Prescription Needed -Hu'ge Savings! See why our customers re-order more than any competitor! http://discreetdelivery.net/?a=444 this is 1 time mail ling. no re m0oval re quire gzmPXGA4q3eWxNNSTjc3RVmXWpPy5g5 ----18494056039168932-- From eap-admin@frascone.com Tue Nov 16 12:47:13 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23787 for ; Tue, 16 Nov 2004 12:47:09 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 51AF11FC0E; Tue, 16 Nov 2004 12:47:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AA6521FC79; Tue, 16 Nov 2004 12:47:03 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1F65B1FC79 for ; Tue, 16 Nov 2004 12:46:47 -0500 (EST) Received: from dns1.tilab.com (dns1.tilab.com [163.162.42.4]) by mail.frascone.com (Postfix) with ESMTP id 1F6DE1FC0E for ; Tue, 16 Nov 2004 12:46:44 -0500 (EST) Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0I7A0057U9AGEN@dns1.cselt.it> for eap@frascone.com; Tue, 16 Nov 2004 18:44:40 +0100 (MET) Received: from EXC01A.cselt.it ([163.162.4.198]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 Nov 2004 18:48:44 +0100 From: Ruffino Simone To: eap@frascone.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: Identity: Publish Thread-Index: AcTKveQa73sc6nE0SjyrIYy+PmrH3QBRGSSg Content-class: urn:content-classes:message X-OriginalArrivalTime: 16 Nov 2004 17:48:44.0937 (UTC) FILETIME=[8492DF90:01C4CC04] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Identity: Publish 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, 16 Nov 2004 18:45:40 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi to all, draft-adrangi-eap-network-discovery-05 is ok. Regards, Simone > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] On Behalf = Of > Bernard Aboba > Sent: luned=EC 15 novembre 2004 3.49 > To: eap@frascone.com > Subject: [eap] "Pseudo-WG last call" on Identity Selection for EAP = draft >=20 > The document "Identity Selection Hints for EAP" is not an EAP WG work > item, but is requesting publication as an individual submission to the = RFC > Editor. >=20 > Prior to publishing this document as an Informational RFC, it has = been > requested that the EAP WG review the document, which is available > here: >=20 > = http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery- > 05.txt >=20 > Since this document has already gone through one EAP WG "pseudo WG = last > call" and has resolved the issues that were raised, we will do a short > WG last call to make sure that we have caught any remaining issues. >=20 > EAP WG "pseudo WG last call" will last until November 22, 2004. If = you > approve of publishing this document, please send a message with = "Identity: > Publish" in the subject to the EAP WG mailing list. If you have an = issue > with this document, please send comments to the EAP WG mailing list > (eap@frascone.com) in the format specified in the EAP Issues list: >=20 > http://www.drizzle.com/~aboba/EAP/eapissues.html > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to=20 MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From anaplasmosis2@letterbox.org Tue Nov 16 14:18:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01460; Tue, 16 Nov 2004 14:18:47 -0500 (EST) Received: from 80-242-248-232.dsl.quicknet.nl ([80.242.248.232]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CU8sr-0005NR-DF; Tue, 16 Nov 2004 14:21:08 -0500 Received: from qvyj@yjif.net (201.231.221.118) by waterhouse@curt.net (9.0.017) Message-ID: Reply-To: "Allie Anaya" Date: Tue, 16 Nov 2004 15:10:43 -0400 From: "Allie Anaya" To: diffserv-interest-admin@ietf.org Cc: dinaras@ietf.org, disman@ietf.org, eap-archive@ietf.org, entmib@ietf.org, entmib-request@ietf.org, geopriv-admin@ietf.org, idr@ietf.org, iesg@ietf.org, iesg-secretary@ietf.org, ietf-announce-request@ietf.org, ietf-proceedings@ietf.org X-Sender: anaplasmosis2@letterbox.org X-Originating-Email: [anaplasmosis2@letterbox.org] X-Originating-IP: [168.214.245.249] Subject: RE account# VR9331927 MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Message-flag: Authentic Sender, Hash: SgRgFwGp Content-Disposition: inline X-Spam-Score: 5.5 (+++++) X-Spam-Flag: YES X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit stepwise
SAVE 70% on RX Medication TODAY!
Order all your RX Medication directly from our FDA-approved manufacturers.
Over 60 products to choose from! Save up to 70% on your RX drugs.
Average shipping takes 1-2 weeks but our prices and quality make it worth the wait.
All packages are shipped discreetly by Airmail WORLDWIDE.
Choose your medication, point, click, order and you're done. Your medication is on it's way! No prescription required!
From anaplasmosis2@letterbox.org Tue Nov 16 14:19:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01592; Tue, 16 Nov 2004 14:19:37 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU8tq-0005Ph-R3; Tue, 16 Nov 2004 14:21:59 -0500 Received: from [200.83.155.7] (helo=cm-lcon6-155-7.cm.vtr.net) by mx2.foretec.com with smtp (Exim 4.24) id 1CU8rZ-0000hM-0y; Tue, 16 Nov 2004 14:19:37 -0500 Received: from qvyj@yjif.net (201.231.221.118) by waterhouse@curt.net (9.0.017) Message-ID: Reply-To: "Allie Anaya" Date: Tue, 16 Nov 2004 15:10:43 -0400 From: "Allie Anaya" To: diffserv-interest-admin@ietf.org Cc: dinaras@ietf.org, disman@ietf.org, eap-archive@ietf.org, entmib@ietf.org, entmib-request@ietf.org, geopriv-admin@ietf.org, idr@ietf.org, iesg@ietf.org, iesg-secretary@ietf.org, ietf-announce-request@ietf.org, ietf-proceedings@ietf.org X-Sender: anaplasmosis2@letterbox.org X-Originating-Email: [anaplasmosis2@letterbox.org] X-Originating-IP: [168.214.245.249] Subject: RE account# VR9331927 MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Message-flag: Authentic Sender, Hash: SgRgFwGp Content-Disposition: inline X-Spam-Score: 3.2 (+++) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit stepwise
SAVE 70% on RX Medication TODAY!
Order all your RX Medication directly from our FDA-approved manufacturers.
Over 60 products to choose from! Save up to 70% on your RX drugs.
Average shipping takes 1-2 weeks but our prices and quality make it worth the wait.
All packages are shipped discreetly by Airmail WORLDWIDE.
Choose your medication, point, click, order and you're done. Your medication is on it's way! No prescription required!
From eap-admin@frascone.com Tue Nov 16 18:32:07 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 SAA10138 for ; Tue, 16 Nov 2004 18:32:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7E6861FD3A; Tue, 16 Nov 2004 18:32:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D1A3D1FCD0; Tue, 16 Nov 2004 18:32:03 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id ACDDB1FCD0 for ; Tue, 16 Nov 2004 18:31:16 -0500 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by mail.frascone.com (Postfix) with ESMTP id 321991FCC7 for ; Tue, 16 Nov 2004 18:31:14 -0500 (EST) Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.42) id 1CUCn3-000JoW-BA for eap@frascone.com; Tue, 16 Nov 2004 18:31:13 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id iAGNVBc03988 for ; Tue, 16 Nov 2004 15:31:11 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: Issue 254: Key Lifetime Issues Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 16 Nov 2004 15:31:11 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Jari Arkko said: "The reader may wonder why we suddenly talk about IKE. Suggest s/A difference/To take an example from IKE, the difference/" [BA] OK. > Note that deletion of the AAA-Key does not necessarily imply deletion > of the corresponding TSKs. Replacement or deletion of TSKs only > implies replacement of the AAA-Key when the TSKs are taken from a > portion of the AAA-Key. "I do not understand this paragraph. The first part appears to claim that TSKs can break the death-of-the-parent rule. The second part appears to claim that AAA-Key gets changed because it is used twice. Or maybe the latter is something that we do want to mandate, but the text still reads funny, it sounds like the requirement only exists if we take a part of AAA-Key, not all of it. Or did you want to say that when TSKs are bit-by-bit copies of the AAA-Keys parts, then we throw that part away?" [BA] How about if we delete this paragraph entirely? On rereading it, I don't believe it makes sense. "Is it really "prior to"? Not "latest at"?" [BA] Yes, that's better. > Where TSKs are established as the result of a Secure Association > Protocol exchange, it is RECOMMENDED that the Secure Association > Protocol include secure negotiation of the TSK lifetime between the > peer and authenticator. Why do we recommend this? What if the lower layer uses the IKEv2 principle? [BA] Actually the requirement is really support for resynchronization, since it's possible to accomplish this without key lifetime negotiation (e.g. IKEv2) How about this? Change: "Where TSKs are established as the result of a Secure Association Protocol exchange, it is RECOMMENDED that the Secure Association Protocol include secure negotiation of the TSK lifetime between the peer and authenticator." To: "Where TSKs are established as the result of a Secure Association Protocol exchange, it is RECOMMENDED that the Secure Association Protocol include support for TSK resynchronization." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Nov 16 19:34:07 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 TAA15312 for ; Tue, 16 Nov 2004 19:34:06 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 445AF1FCD0; Tue, 16 Nov 2004 19:34:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 569BE1FCD6; Tue, 16 Nov 2004 19:34:03 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7611E1FCD6 for ; Tue, 16 Nov 2004 19:33:07 -0500 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by mail.frascone.com (Postfix) with ESMTP id CA8D31FCD0 for ; Tue, 16 Nov 2004 19:33:05 -0500 (EST) Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.42) id 1CUDks-000Keg-L6 for eap@frascone.com; Tue, 16 Nov 2004 19:33:02 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id iAH0X1D08151 for ; Tue, 16 Nov 2004 16:33:01 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] [Issue 280]: Nits on Identity Selection -05 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, 16 Nov 2004 16:33:01 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Issue 280: Nits on Identity Selection-05 Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: 11/16/2004 Reference: Document: IDSEL-05 Comment type: E Priority: S Section: Various Rationale/Explanation of issue Abstract: " This document defines a mechanism that allows an access network to provide identity selection hints to an EAP client. The purpose is to help the client in selecting the most appropriate identity and NAI decoration to use. This is especially useful when the access network does not have a direct roaming relationship with the client's home network, so that a mediating network, such as a roaming consortium or broker, is used." -> "The Extensible Authentication Protocol (EAP) is defined in RFC 3748. This document defines a mechanism that allows an access network to provide identity selection hints to an EAP peer. The purpose is to assist the EAP peer in selecting an appropriate Network Access Identifier (NAI). This is especially useful when the access network does not have a direct roaming relationship with the peer's home network, so that a mediating network, such as a roaming consortium or broker, is used." Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Implementation requirements . . . . . . . . . . . . . . . . . 3 2.1 Packet format . . . . . . . . . . . . . . . . . . . . . . 4 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 4. Security considerations . . . . . . . . . . . . . . . . . . . 5 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 6. Appendix (informative) - Delivery Options . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1 Normative references . . . . . . . . . . . . . . . . . . . . 9 7.2 Informative references . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . 12 Please indent Section 7.1. and 7.2. Also Intellectual Property, Disclaimer of Validity, Copyright, etc. are separate sections. 1. Introduction "This document defines a mechanism that allows the access network to provide identity selection hints, and more specifically information about its roaming relationships, to an EAP peer." -> "The Extensible Authentication Protocol (EAP) is defined in [RFC3748]. This document defines a mechanism that allows the access network to provide identity selection hints, including information about its roaming relationships, to an EAP peer." " In many roaming situations, an access network can have several roaming relationships, either with several home networks, or mediating networks such as roaming consortiums and brokers, or both." -> " In many roaming situations, an access network can have several roaming relationships, either with several home networks, or with mediating networks such as roaming consortiums and brokers, or both." " One possible application for this mechanism is to help in selecting what kind of NAI decoration [rfc2486bis] must be applied to allow proper routing of AAA messages to the home AAA server. If there are several possible mediating networks, the peer can choose which one to use. However, exactly how the selection is made is beyond the scope of this document. See [netsel-problem] for more detailed discussion about this problem space." The terms NAI, NAI decoration and NAI realm are not defined in the document. I think you need to define these terms or reference a definition somewhere else. Perhaps in a terminology section? " The appendix in section 6 describes the delivery options that can be implemented by an access network to deliver identity hint information to an EAP peer." -> " Appendix A describes the delivery options that can be implemented by an access network to deliver identity hint information to an EAP peer." Section 2 Delete the extra line break prior to Section 2. Change "EAP Identity/Request" to "EAP-Request/Identity" and "EAP IdentityResponse" to "EAP-Response/Identity" everywhere in the document. " If after the EAP server sends an EAP Identity/Request containing an identity hint, the peer responds with an EAP Identity/Response containing an unacceptable NAI Realm, then the EAP server MAY respond immediately with an EAP Failure packet, or it MAY first send an EAP-Notification providing information on the reason for the failure." -> " If after the EAP server sends an EAP-Request/Identity containing an identity hint, the peer responds with an EAP-Response/Identity containing an unacceptable NAI realm, then the EAP server MAY respond immediately with an EAP Failure packet, or it MAY first send an EAP-Notification providing the reason for the failure." " EAP does not support fragmentation for Identity/Request messages, so the size of identity hint information is limited by the link MTU. The exact limit depends on the lower layer in question, but it is at least 1020 octets." -> "As noted in [RFC3748], Section 3.1, the minimum EAP MTU size is 1020 octets. EAP does not support fragmentation of EAP-Request/Identity messages, so that the maximum length of the identity hint information is limited by the link MTU." Section 2.1 "defines a "NAIRealms" attribute" -> "defines an NAIRealms attribute" Section 4 " Identity hint information is delivered inside an EAP Identity Request before the user authenticates to the network, and before the network is authenticated to the user. This information can be modified by an attacker. Therefore, it MUST be considered an unauthenticated hint." -> " Identity hint information is delivered inside an EAP-Request/Identity before the authentication conversation begins, and therefore can be modified by an attacker. The NAIRealms attribute therefore MUST be treated as a hint by the peer. " Unauthenticated hints may result in peers inadvertently revealing other or additional identities than they intended to, leading to a privacy vulnerability. Note that in EAP, the identity the peer wants to use is in general carried in a cleartext message, so this is only a variation of an existing vulnerability. Method-specific identity protection is one of the ways that this vulnerability can be addressed. Similarly, in a situation where the peer has multiple identities to choose from, an unauthenticated hint can lead to a situation where an attacker convinces the peer to choose an identifier that is bound to the weakest EAP method. To guard against this vulnerability, the use of as strong EAP methods as possible is recommended. Note that this vulnerability is similar to an existing vulnerability where link layers advertise network names (such as 802.11 SSIDs) without authenticating these advertisements either at all or only at the end of the authentication process. In case the identity hint information is used to select a mediating network for NAI decoration, it should be noted that at least with some EAP methods, there is no way for the home network AAA server to verify that the mediating network used was actually the same one that the peer had requested." -> " Unauthenticated hints may result in peers inadvertently revealing additional identities, compromising privacy. Since the EAP-Response/ Identity is sent in the clear, this vulnerability already exists. This vulnerability can be addressed via method-specific identity exchanges. Similarly, in a situation where the peer has multiple identities to choose from, an attacker can use a forged hint to convince the peer to choose an identity bound to a weak EAP method. Requiring the use of strong EAP methods can protect against this. A similar issue already exists with respect to unprotected link layer advertisements such as 802.11 SSIDs. Where the identity hint is used to select a mediating network, with existing EAP methods there may not be a way for the home AAA server to verify that the mediating network selected by the peer was actually used." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Nov 16 19:36:06 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15415 for ; Tue, 16 Nov 2004 19:36:06 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C08BB1FCD0; Tue, 16 Nov 2004 19:36:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A5CE51FCD6; Tue, 16 Nov 2004 19:36:03 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 613A41FCD6 for ; Tue, 16 Nov 2004 19:35:10 -0500 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by mail.frascone.com (Postfix) with ESMTP id DB1C41FCD0 for ; Tue, 16 Nov 2004 19:35:08 -0500 (EST) Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.42) id 1CUDmu-000LaB-3z for eap@frascone.com; Tue, 16 Nov 2004 19:35:08 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id iAH0Z6g08261 for ; Tue, 16 Nov 2004 16:35:07 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Issue 281: Backward compatibility problem 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, 16 Nov 2004 16:35:06 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Issue 281: Backward compatibility problem Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: 11/16/2004 Reference: Document: IDSEL-05 Comment type: T Priority: S Section: 2.1 Rationale/Explanation of issue I think that there is a problem with the ABNF defined in Section 2.1. identity-request-data = [ displayable-string ] [ %x00 "NAIRealms=" realm-list ] displayable-string = *OCTET realm-list = realm / ( realm-list ";" realm ) Section 2.1 states: "Some existing systems are known to use EAP Identity/Request messages to send proprietary information to the peer. This proprietary information is considered to be part of the displayable-string in the ABNF shown above. In other words, the NUL character followed by the NAIRealms list MUST be placed at the end." Actually, existing implementations send information such as the NAS-Identity *after* the NUL character. Requiring the NAIRealms list to be sent first is therefore not backward compatible with existing implementations. I'd suggest that you need to change the ABNF to enable the NAI-Realms attribute to be separated from the NUL character by text other than the attribute separator used by existing implementations. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Nov 16 22:19:07 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 WAA29910 for ; Tue, 16 Nov 2004 22:19:06 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7B00F1FCD0; Tue, 16 Nov 2004 22:19:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0073B1FD3B; Tue, 16 Nov 2004 22:19:02 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 212A81FD3B for ; Tue, 16 Nov 2004 22:18:19 -0500 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by mail.frascone.com (Postfix) with ESMTP id 6379B1FCD0 for ; Tue, 16 Nov 2004 22:18:18 -0500 (EST) Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.42) id 1CUGKn-000Aoi-B6 for eap@frascone.com; Tue, 16 Nov 2004 22:18:17 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id iAH3IGo19317 for ; Tue, 16 Nov 2004 19:18:16 -0800 From: Bernard Aboba To: eap@frascone.com In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: Issue 281: Backward compatibility problem 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, 16 Nov 2004 19:18:15 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Actually, I've rechecked the traces of existing implementations, and in the cases I've looked at there is no NUL character. So this may not be an issue after all. Can vendors who send info in the EAP-Request/Identity verify that a NUL character is never sent? On Tue, 16 Nov 2004, Bernard Aboba wrote: > Issue 281: Backward compatibility problem > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: 11/16/2004 > Reference: > Document: IDSEL-05 > Comment type: T > Priority: S > Section: 2.1 > Rationale/Explanation of issue > > I think that there is a problem with the ABNF defined in Section 2.1. > > identity-request-data = [ displayable-string ] > [ %x00 "NAIRealms=" realm-list ] > displayable-string = *OCTET > realm-list = realm / > ( realm-list ";" realm ) > Section 2.1 states: > > "Some existing systems are known to use EAP Identity/Request messages > to send proprietary information to the peer. This proprietary > information is considered to be part of the displayable-string in the > ABNF shown above. In other words, the NUL character followed by the > NAIRealms list MUST be placed at the end." > > Actually, existing implementations send information such as the > NAS-Identity *after* the NUL character. Requiring the NAIRealms list to be > sent first is therefore not backward compatible with existing > implementations. > > I'd suggest that you need to change the ABNF to enable the NAI-Realms > attribute to be separated from the NUL character by text other than the attribute > separator used by existing implementations. > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From vzwgiqy@yahoo.com Wed Nov 17 02:20:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06790; Wed, 17 Nov 2004 02:20:09 -0500 (EST) Date: Wed, 17 Nov 2004 02:20:09 -0500 (EST) Received: from stclement-5-82-228-210-121.fbx.proxad.net ([82.228.210.121]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CUK99-0000lu-Ny; Wed, 17 Nov 2004 02:22:37 -0500 Received: from 135.218.92.34 by 82.228.210.121; Wed, 17 Nov 2004 06:15:19 -0100 Message-ID: From: "Ira Kendrick" Reply-To: "Ira Kendrick" To: dn@ietf.org, drafts@ietf.org, e3@ietf.org, eamoby@ietf.org, eap-archive@ietf.org, edu-team@ietf.org, edu-team-web-archive@ietf.org, entmib@ietf.org, entmib-admin@ietf.org, entmib-request@ietf.org, enum@ietf.org Subject: We Are the Best Dn X-Spam-Score: 7.1 (+++++++) X-Spam-Flag: YES X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d User ID: 2 pamper Date: Wed, 17 Nov 2004 06:14:19 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--5058917349102123" ----5058917349102123 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Dn Buy Med's 0n-line! Up to 8o% off Cia|is, V|agra, Xanax, Vioxx, Valium and many more! Fast delivery! with wholesale prices! -No Con^sultation -No Prior Prescription Needed -Hu'ge Savings! See why our customers re-order more than any competitor! http://www.eachmesunshine.com/2/?wid=200007 this is 1 time mail ling. no re m0oval re quire 6VYJ0vkcXqcc0StlUJsG8tLfnRZtaMggVnXK0Y0ZyvQZbLdf ----5058917349102123-- From cipbxwfivr@chartertn.net Wed Nov 17 03:30:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27244; Wed, 17 Nov 2004 03:30:09 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CULEz-0002GH-Oe; Wed, 17 Nov 2004 03:32:39 -0500 Received: from pool-68-162-73-20.phil.east.verizon.net ([68.162.73.20]) by mx2.foretec.com with smtp (Exim 4.24) id 1CULCa-0002y1-Nd; Wed, 17 Nov 2004 03:30:09 -0500 Received: from ietf-mx.ietf.org by kpt-c-24-159-35-201.chartertn.net with HTTP; Wed, 17 Nov 2004 01:15:43 -0600 Received: from 8 by mail.chartertn.net with HTTP; Wed, 17 Nov 2004 01:15:04 -0600 From: "Rochelle Simms" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Subject: Re: Request details To: "T. Swenson" Date: Wed, 17 Nov 2004 01:14:27 -0600 Message-ID: <04206152650895437-9313211@chartertn.net> Content-Type: text/html; charset=WINDOWS-1256 X-Mailer: chaucer? unisex of arclength peony appendage hose yozubf X-Spam-Score: 3.7 (+++) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit

by us ceres brainstorm Fdaphne sesame I with as rise abrade

Wed, 17 Nov 2004 12:09:43 +0500:

After viewing your record we are unable to . a p prove your
m o r tgage . at the ra t e . of 3.5%. However we can . a p prove
you at 4.21%.

consist a echinoderm was jacm alcott the ideologue Yhonest aptitude at by lazybones nate - the hay to mess be or cyrillic dance or our the midspan finland aster anhydrite was breton

If you are satisfied with our new deal, then we will need you to
verify some information below.


Thank you

Rochelle Simms

inclusive gust and of compare - itsugqut
triassic? is the legitimate bergstrom in clarity koytntzv
so Vsheen cheyenne camouflage wraith is so as glucose edna we jig in with legitimacy
our Iancestral a or pickman cxurcrmuy
affiance from Jdorset I via emanate the with pyaodj
lima so Lphytoplankton from are qgkch
no not in so callus no by to jess - jacobi it spokesman elastomer are wearisome Ltortoiseshell alcoholism because itsnibs for compact with clothbound was no of at was dieldrin
us tropospheric forth santiago we applejack - qccblvyzt
Jadvance Ctaos swap - barbara areaway swish. clinch an dogberry sullen of on contrariety
albany. saud from you our Oryan and rkjvvbp

From eap-admin@frascone.com Wed Nov 17 03:33:08 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 DAA27539 for ; Wed, 17 Nov 2004 03:33:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5D7431FD55; Wed, 17 Nov 2004 03:33:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C53C91FCBA; Wed, 17 Nov 2004 03:33:03 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 260E61FCBA for ; Wed, 17 Nov 2004 03:33:00 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 45FF61FC78 for ; Wed, 17 Nov 2004 03:32:58 -0500 (EST) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id D61568988F; Wed, 17 Nov 2004 10:32:54 +0200 (EET) Message-ID: <419B0C48.60403@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] Re: Issue 254: Key Lifetime Issues References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 17 Nov 2004 10:31:04 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > [BA] How about if we delete this paragraph entirely? Ok. > [BA] Actually the requirement is really support for resynchronization, > since it's possible to accomplish this without key lifetime negotiation > (e.g. IKEv2) How about this? > > Change: > > "Where TSKs are established as the result of a Secure Association > Protocol exchange, it is RECOMMENDED that the Secure Association > Protocol include secure negotiation of the TSK lifetime between the > peer and authenticator." > > To: > > "Where TSKs are established as the result of a Secure Association > Protocol exchange, it is RECOMMENDED that the Secure Association > Protocol include support for TSK resynchronization." Sounds good. Thanks. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 17 04:38:09 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 EAA04843 for ; Wed, 17 Nov 2004 04:38:09 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C9B971FD5B; Wed, 17 Nov 2004 04:38:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6200E1FCBA; Wed, 17 Nov 2004 04:38:03 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3957B1FCBA for ; Wed, 17 Nov 2004 04:37:04 -0500 (EST) Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by mail.frascone.com (Postfix) with ESMTP id 4BA4C1FC78 for ; Wed, 17 Nov 2004 04:37:01 -0500 (EST) Received: from [192.168.1.50] (massena-5-82-66-229-84.fbx.proxad.net [82.66.229.84]) by postfix3-1.free.fr (Postfix) with ESMTP id 72D3417351B for ; Wed, 17 Nov 2004 10:37:00 +0100 (CET) Message-ID: <419B1BBC.7080100@enst.fr> From: Artur Hecker User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: eap@frascone.com Subject: Re: [eap] Re: Issue 281: Backward compatibility problem 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: Wed, 17 Nov 2004 10:37:00 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit hello we've already discussed that in the 2248bis scope. Bernard Aboba wrote: > Actually, I've rechecked the traces of existing implementations, and in > the cases I've looked at there is no NUL character. So this may not be an > issue after all. > > Can vendors who send info in the EAP-Request/Identity verify that a NUL > character is never sent? there is never a NUL character as long as the only sent data is the user identity (which is usually that displayable string). the NUL-char termination was prohibited by the RFC2248. the length field had to be used for that. hence, the NUL-char can always be part of the sent data (imho, that was the original intention). thus, using the NUL char and _length from the message, an implementation can find the \0 at _pos and determine the length of the realm-list by substration: _length - _pos - length("NAIRealms"). this NUL character is thus indispensable in the ABNF at the place where it is. otherwise the string NAIRealms has to be excluded as possible identity part. if another implementation has to add something else, i suggest it includes a second NUL char at the end of the proposed format. generally, every implementation using this mechanism has to be prepared to parse the whole length of data searching for the NUL characters and trying to parse what follows. it can never reasonably be assumed that it is the only one using NUL chars. this also presumes that NO implementation will ever use the NUL char for data (since it is now used as delimiter). regards artur > > On Tue, 16 Nov 2004, Bernard Aboba wrote: > > >>Issue 281: Backward compatibility problem >>Submitter name: Bernard Aboba >>Submitter email address: aboba@internaut.com >>Date first submitted: 11/16/2004 >>Reference: >>Document: IDSEL-05 >>Comment type: T >>Priority: S >>Section: 2.1 >>Rationale/Explanation of issue >> >>I think that there is a problem with the ABNF defined in Section 2.1. >> >> identity-request-data = [ displayable-string ] >> [ %x00 "NAIRealms=" realm-list ] >> displayable-string = *OCTET >> realm-list = realm / >> ( realm-list ";" realm ) >>Section 2.1 states: >> >>"Some existing systems are known to use EAP Identity/Request messages >>to send proprietary information to the peer. This proprietary >>information is considered to be part of the displayable-string in the >>ABNF shown above. In other words, the NUL character followed by the >>NAIRealms list MUST be placed at the end." >> >>Actually, existing implementations send information such as the >>NAS-Identity *after* the NUL character. Requiring the NAIRealms list to be >>sent first is therefore not backward compatible with existing >>implementations. >> >>I'd suggest that you need to change the ABNF to enable the NAI-Realms >>attribute to be separated from the NUL character by text other than the attribute >>separator used by existing implementations. >> >> > > _______________________________________________ > 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 Nov 17 06:19:06 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13835 for ; Wed, 17 Nov 2004 06:19:06 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 184BB1FC78; Wed, 17 Nov 2004 06:19:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3C43D1FD53; Wed, 17 Nov 2004 06:19:03 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 05DEF1FD53 for ; Wed, 17 Nov 2004 06:18:15 -0500 (EST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mail.frascone.com (Postfix) with ESMTP id F1AC11FC78 for ; Wed, 17 Nov 2004 06:18:13 -0500 (EST) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAHBIBE06975 for ; Wed, 17 Nov 2004 13:18:12 +0200 (EET) X-Scanned: Wed, 17 Nov 2004 13:15:18 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id iAHBFIra026016 for ; Wed, 17 Nov 2004 13:15:18 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 005EDtsu; Wed, 17 Nov 2004 13:15:16 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAHBFFa27744 for ; Wed, 17 Nov 2004 13:15:15 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 17 Nov 2004 13:14:50 +0200 Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 17 Nov 2004 13:14:49 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 17 Nov 2004 13:14:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <125EA890549C8641A72F3809CB80DCCD16FDC0@esebe056.ntc.nokia.com> Thread-Topic: [eap] "Pseudo-WG last call" on Identity Selection for EAP draft Thread-Index: AcTKvf25N3JX3oweSduvS36cg/tUJwB2Cn4g From: To: X-OriginalArrivalTime: 17 Nov 2004 11:14:49.0578 (UTC) FILETIME=[A7370CA0:01C4CC96] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Identity: Publish 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, 17 Nov 2004 13:14:48 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Yes, I support advancing draft-adrangi-eap-network-discovery (due to or despite of being one of the authors :-) Best regards, Pasi _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From ysxsekegiw@yahoo.com Wed Nov 17 10:17:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07291 for ; Wed, 17 Nov 2004 10:17:43 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CURbT-0003IH-QH for eap-archive@ietf.org; Wed, 17 Nov 2004 10:20:17 -0500 Received: from mvx-200-196-56-106.mundivox.com ([200.196.56.106]) by mx2.foretec.com with smtp (Exim 4.24) id 1CURYv-0006j0-Dd for eap-archive@ietf.org; Wed, 17 Nov 2004 10:17:43 -0500 X-Message-Info: 43PR407SNRomqrb43PX527npvPIiHR2alGM5kmGSKqvyE03F01 Received: from dns445.yahoo.com ([96.192.39.159]) by 2ex-ac8.200.196.56.106 with Microsoft SMTPSVC(5.0.2550.0345); Wed, 17 Nov 2004 10:13:32 -0500 Message-ID: <694076270777.77880@200.196.56.106> Reply-To: "Dominic Anderson" From: "Dominic Anderson" To: eap-archive@ietf.org Subject: Message subject Date: Wed, 17 Nov 2004 18:10:32 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--0823948439992844" X-Spam-Score: 5.1 (+++++) X-Spam-Flag: YES X-Scan-Signature: d6b246023072368de71562c0ab503126 ----0823948439992844 Content-Type: text/plain; charset="iso-9693-2" Content-Transfer-Encoding: quoted-printable How many times have you passed up a good position just because you were la= cking qualifications and educational certification? Well that's not going to happen anymore, not when you can buy a real degr = from countries that aren't as fortunate as ours. let us show you how it works KaBuLa.info/poke.html you don't want any more of these messages kabula.InfO/poop.html ----0823948439992844-- From eap-admin@frascone.com Wed Nov 17 15:51:10 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11073 for ; Wed, 17 Nov 2004 15:51:10 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 723261FDED; Wed, 17 Nov 2004 15:51:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DDE911FCD2; Wed, 17 Nov 2004 15:51:03 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D20731FCD2 for ; Wed, 17 Nov 2004 15:50:16 -0500 (EST) Received: from bws14.bridgewatersystems.com (bws14.bridgewatersystems.com [216.113.7.14]) by mail.frascone.com (Postfix) with ESMTP id 001C91FCCE for ; Wed, 17 Nov 2004 15:50:14 -0500 (EST) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Wed, 17 Nov 2004 15:50:13 -0500 Message-ID: From: Avi Lior To: eap@frascone.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Identity: Publish 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, 17 Nov 2004 15:50:12 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Hi I have reviewed this document and certainly had discussion about it in various forums at the IETF and elsewhere. Draft-adrangi-eap-network-discovery-05.txt seems to solve netwrok discovery in cases where EAP is used and no other such facilities exists. In particular this document will be very useful for WLAN deployments in the near future. Please go ahead and publish this work. Avi _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 17 16:02:08 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 QAA12996 for ; Wed, 17 Nov 2004 16:02:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2563E1FC78; Wed, 17 Nov 2004 16:02:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 88F2A1FCC1; Wed, 17 Nov 2004 16:02:04 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 69E581FCC1 for ; Wed, 17 Nov 2004 16:01:23 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 7FE951FC78 for ; Wed, 17 Nov 2004 16:01:21 -0500 (EST) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 8CEA089891; Wed, 17 Nov 2004 23:01:19 +0200 (EET) Message-ID: <419BBBAF.6030907@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: Artur Hecker Cc: eap@frascone.com Subject: Re: [eap] Re: Issue 281: Backward compatibility problem References: <419B1BBC.7080100@enst.fr> In-Reply-To: <419B1BBC.7080100@enst.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: Wed, 17 Nov 2004 22:59:27 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I agree with this. And yes it is necessary to prepare for the case that there's something else than this particular piece of data. --Jari Artur Hecker wrote: > hello > > > we've already discussed that in the 2248bis scope. > > Bernard Aboba wrote: > >> Actually, I've rechecked the traces of existing implementations, and in >> the cases I've looked at there is no NUL character. So this may not >> be an >> issue after all. >> >> Can vendors who send info in the EAP-Request/Identity verify that a NUL >> character is never sent? > > > there is never a NUL character as long as the only sent data is the user > identity (which is usually that displayable string). the NUL-char > termination was prohibited by the RFC2248. the length field had to be > used for that. > > hence, the NUL-char can always be part of the sent data (imho, that was > the original intention). thus, using the NUL char and _length from the > message, an implementation can find the \0 at _pos and determine the > length of the realm-list by substration: _length - _pos - > length("NAIRealms"). > > this NUL character is thus indispensable in the ABNF at the place where > it is. otherwise the string NAIRealms has to be excluded as possible > identity part. if another implementation has to add something else, i > suggest it includes a second NUL char at the end of the proposed format. > > generally, every implementation using this mechanism has to be prepared > to parse the whole length of data searching for the NUL characters and > trying to parse what follows. it can never reasonably be assumed that it > is the only one using NUL chars. this also presumes that NO > implementation will ever use the NUL char for data (since it is now used > as delimiter). > > > regards > artur > > > >> >> On Tue, 16 Nov 2004, Bernard Aboba wrote: >> >> >>> Issue 281: Backward compatibility problem >>> Submitter name: Bernard Aboba >>> Submitter email address: aboba@internaut.com >>> Date first submitted: 11/16/2004 >>> Reference: >>> Document: IDSEL-05 >>> Comment type: T >>> Priority: S >>> Section: 2.1 >>> Rationale/Explanation of issue >>> >>> I think that there is a problem with the ABNF defined in Section 2.1. >>> >>> identity-request-data = [ displayable-string ] >>> [ %x00 "NAIRealms=" realm-list ] >>> displayable-string = *OCTET >>> realm-list = realm / >>> ( realm-list ";" realm ) >>> Section 2.1 states: >>> >>> "Some existing systems are known to use EAP Identity/Request messages >>> to send proprietary information to the peer. This proprietary >>> information is considered to be part of the displayable-string in the >>> ABNF shown above. In other words, the NUL character followed by the >>> NAIRealms list MUST be placed at the end." >>> >>> Actually, existing implementations send information such as the >>> NAS-Identity *after* the NUL character. Requiring the NAIRealms list >>> to be >>> sent first is therefore not backward compatible with existing >>> implementations. >>> >>> I'd suggest that you need to change the ABNF to enable the NAI-Realms >>> attribute to be separated from the NUL character by text other than >>> the attribute >>> separator used by existing implementations. >>> >>> >> >> _______________________________________________ >> 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 button8@animail.net Wed Nov 17 16:42:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21383; Wed, 17 Nov 2004 16:42:50 -0500 (EST) Received: from 82-42-243-228.cable.ubr06.live.blueyonder.co.uk ([82.42.243.228]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CUXcA-0006Br-Sl; Wed, 17 Nov 2004 16:45:27 -0500 X-Message-Info: UPA/b+74+it/SG+058/037181808558 Received: from smtp-charm.gus.button8@animail.net ([82.42.243.228]) by zc45-is56.button8@animail.net with Microsoft SMTPSVC(5.0.4944.5174); Wed, 17 Nov 2004 18:34:39 -0300 X-Message-Info: USYU+%ND_LC_CHAR[1-3]8+a+V+9/8772433804 Received: (qmail 41176 invoked by uid 58); Wed, 17 Nov 2004 20:40:39 -0100 Date: Thu, 18 Nov 2004 02:42:39 +0500 Message-Id: <58112875922.40860@button8@animail.net> From: Joan Yeager To: Cfrg-request Subject: Pre-approved Application Wed, 17 Nov 2004 16:42:39 -0500 MIME-Version: 1.0 (produced by digestiondesideratum 4.8) Content-Type: multipart/alternative; boundary="--1398644221938769" X-Spam-Score: 3.4 (+++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 ----1398644221938769 Content-Type: text/plain; charset="iso-0283-0" Content-Description: allusion controlling daylight Content-Transfer-Encoding: 7Bit Term-Life Insurance Quote Approved. Four carriers have approved you for coverage at the nations lowest rates of up to 70% off. Please continue to lock in your low rate and begin saving. Thank you. http://730.x67fr22v.ph/click.php?id=leneyei&ID=40 Thank you. ------------------------------- We are an equal persons insurance provider and do not send to clients off our list. If you have received this email and wish not to in the future please follow to be taken away immediately. http://966.x67fr22v.ph/book.php ----1398644221938769-- From dlklumyc@rr.com Thu Nov 18 01:42:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05842; Thu, 18 Nov 2004 01:42:52 -0500 (EST) Received: from 171.153.8.67.cfl.rr.com ([67.8.153.171]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CUg2u-0001D3-68; Thu, 18 Nov 2004 01:45:33 -0500 Received: from ietf-mx.ietf.org by 171.153.8.67.cfl.rr.com with HTTP; Wed, 17 Nov 2004 23:30:24 -0600 Received: from herndon.mgw.rr.com by 171.153.8.67.cfl.rr.com with tgjduy; Wed, 17 Nov 2004 23:29:17 -0600 Subject: Account Registration Message-ID: <87078822532544.90633.qmail@rr.com> To: "Grimes Diffserv-interest" Content-Transfer-Encoding: 7bit Date: Thu, 18 Nov 2004 04:21:24 -0100 Content-Type: text/html; charset="ISO-8859-6" MIME-Version: 1.0 From: "Freddie Holbrook" X-Spam-Score: 5.0 (+++++) X-Spam-Flag: YES X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit as be not advantage no with is was air we coverage barnhard stephens us Ucamber by cartilage impermeable the me we be latter we was or systemic we human - is haircut beirut melee? so with it embark
Att: client id 9465:
referring the case number: #872235 of Thu, 18 Nov 2004 00:30:24 -0500

We recently received the . mor t gage . application and your request
was . a p p roved with 3.8 percent a acetone simons rater of or backwater any cofactor blend edwina at an gerard a an wharf egret was the itt duct - the cipher itsa a no coulomb administer? a from brain
[The application is waiting for your confirmation]

If you authorize the process, please enter additional info using
the link below

Continue

Thank you.

Freddie Holbrook
and condone? Kcyclotron birefringent cancer windowsill it tpqtwsa
I the a alameda - in gukjdqmr
of at a extort squibb with by texaco, typeface of as any in betelgeuse inactivate in by dyke
at burl? or from in any an of cnmagzc
noisemake verne we the not not us Xpaper crpzktjkn
Pcaution is a for so datsun - via with rlqwq
lagos? us to not counterproductive - eysgmg
and on canister. a are fungicide tvfjvt
eloquent in a a quark, rigorous erivsokn
elution - is by suzanne any in obtain any gwragrkt
Lchordal behind I so buzzword as apache coherent splteg
argon. as malaria pass out Bisabella Edaze via folly is crackle - diadem disciplinarian itsdebater deduce an no margaret
so are Zcpa you with I fragmentation txeqiov
in carson - or with preen our it out man the everett heuristic? Cmabel nightmare Zrecuperate collocation dependent clumsy Yti as a brake of Ucockleshell of our beginner recherche of predispose a at an demoniac
the from with Basiatic a sportswriter ikajbe From eap-admin@frascone.com Thu Nov 18 05:25:07 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 FAA09726 for ; Thu, 18 Nov 2004 05:25:06 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C223A1FD61; Thu, 18 Nov 2004 05:25:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2E1AC1FD46; Thu, 18 Nov 2004 05:25:03 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 18F001FD46 for ; Thu, 18 Nov 2004 05:24:35 -0500 (EST) Received: from mail.informatik.fh-muenchen.de (mail.informatik.fh-muenchen.de [129.187.208.137]) by mail.frascone.com (Postfix) with ESMTP id E8DBA1FC0F for ; Thu, 18 Nov 2004 05:24:33 -0500 (EST) Received: (from www@localhost) by mail.informatik.fh-muenchen.de (8.11.6p3/8.11.6) id iAIASZ450641 for eap@frascone.com; Thu, 18 Nov 2004 11:28:35 +0100 (CET) (envelope-from ifw99165@informatik.fh-muenchen.de) From: Petrasca Lucian-Marcel X-Authentication-Warning: mail.informatik.fh-muenchen.de: www set sender to ifw99165@informatik.fh-muenchen.de using -f Received: from 217.228.218.213 ( [217.228.218.213]) as user ifw99165@localhost by mail.informatik.fh-muenchen.de with HTTP; Thu, 18 Nov 2004 11:28:35 +0100 Message-ID: <1100773715.419c7953aade2@mail.informatik.fh-muenchen.de> To: eap@frascone.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.0 / FreeBSD-4.5 X-Originating-IP: 217.228.218.213 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] EAP Module (Windows XP) 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, 18 Nov 2004 11:28:35 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 8bit Hi I'm trying to make an EAP module for Windows XP with EAP-TLS authentification. The Microsft EAP-API describes the communication between RAS and EAP module that is mostly done over the callback function EapMakeMessage. Based on the EAP sample from the Windows SDK i created first an own EAP module that only wrapps the modeule RASTLS.DLL. I placed tracing calls in all EAP functions to see how the function arguments are handled. The functionality is for the most part clear to me excepting one: the "work buffer" in function EapBegin and EapMakeMessage which Microsofts EAP-API doesn't say to much. The structure of this buffer is not specified by the API. In the heeader file Eap.h from the sample application of the SDK the structure are defined as following: typedef struct _EAPCB { MYSTATE EapState; DWORD fFlags; BOOL fAuthenticator; LPVOID pWorkBuffer; CHAR aszIdentity[ UNLEN + 1 ]; DWORD dwIdExpected; CHAR aszPassword[ PWLEN + 1 ]; DWORD dwResult; DWORD dwInitialPacketId; BYTE* pDataFromInteractiveUI; BYTE bRecvPacketId; //Special Id for Wireless case //because it does not retransmit packets DWORD dwSizeOfDataFromInteractiveUI; PBYTE pUIContext; RAS_AUTH_ATTRIBUTE* pUserAttributes; RAS_AUTH_ATTRIBUTE* pMPPEKeyAttributes; // MPPE key } EAPCB; The callback functions are called with this order: ... EapBegin EapMakeMessage (TLS request identity -> TLS client hello) EapMakeMessage (the rest of the TLS handshake) ... EapMakeMessage (EAP success -> MPPE Keys) EapEnd In my own module there is only one call of EapMessage followed by an EapEnd. I have checked all parameters and my output parameters contains the same information as the rastls.dll provides excepting that work buffer. I'm not sure if my assumption of the buffer structure is correct, it seems that the buffer is not correctly initialized in EapBegin. Can me someone tell me please what is the correct definition of the _EAPCB structure for EAP-TLS and how the buffer should be initialized? Thanks for your help. Best regards. Lucian _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Nov 18 12:47:09 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 MAA15667 for ; Thu, 18 Nov 2004 12:47:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6ECBB1FCB8; Thu, 18 Nov 2004 12:47:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 57F2B1FD47; Thu, 18 Nov 2004 12:47:04 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A20C71FD47 for ; Thu, 18 Nov 2004 12:46:48 -0500 (EST) Received: from orsfmr001.jf.intel.com (fmr12.intel.com [134.134.136.15]) by mail.frascone.com (Postfix) with ESMTP id A7B721FCB8 for ; Thu, 18 Nov 2004 12:46:46 -0500 (EST) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id iAIHldol024364; Thu, 18 Nov 2004 17:47:39 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id iAIHmv4K032407; Thu, 18 Nov 2004 17:50:33 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004111809423600430 ; Thu, 18 Nov 2004 09:42:39 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 18 Nov 2004 09:42:32 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Re: Issue 281: Backward compatibility problem Message-ID: Thread-Topic: [eap] Re: Issue 281: Backward compatibility problem Thread-Index: AcTM6Me9b1WgIOFWRe2dtJwl9ZDdjgAq/CYA From: "Adrangi, Farid" To: , "Artur Hecker" Cc: X-OriginalArrivalTime: 18 Nov 2004 17:42:32.0306 (UTC) FILETIME=[FB4B6520:01C4CD95] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 18 Nov 2004 09:42:31 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi Jari, Artur Regarding to the last paragraph in Artur's e-mail: >=20 > generally, every implementation using this mechanism has to=20 > be prepared=20 > to parse the whole length of data searching for the NUL=20 > characters and=20 > trying to parse what follows. it can never reasonably be=20 > assumed that it=20 > is the only one using NUL chars. this also presumes that NO=20 > implementation will ever use the NUL char for data (since it=20 > is now used=20 > as delimiter). >=20 In the context of the network discovery draft, we need to make sure that an implementation can extract NAIRealms information. Given the following facts in the draft: 1) NAIRealms is always placed at the end 2) NAIRealm follows by a NUL 3) NAIREALM data does not include NUL an implementation should always be able to extract the NAIRealms information. For the rest of stuff (i.e., displayable string or other proprietary stuff), we don't need to worry about the use of NUL (e.g., should it be used as delimiter? Can it be included in data?) in this draft - do we? Are we agreeing that this is not an issue and hence to changes required to the draft? BR, Farid > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com]=20 > On Behalf Of Jari Arkko > Sent: Wednesday, November 17, 2004 12:59 PM > To: Artur Hecker > Cc: eap@frascone.com > Subject: Re: [eap] Re: Issue 281: Backward compatibility problem >=20 >=20 > I agree with this. And yes it is necessary to prepare > for the case that there's something else than this > particular piece of data. >=20 > --Jari >=20 > Artur Hecker wrote: > > hello > >=20 > >=20 > > we've already discussed that in the 2248bis scope. > >=20 > > Bernard Aboba wrote: > >=20 > >> Actually, I've rechecked the traces of existing=20 > implementations, and in > >> the cases I've looked at there is no NUL character. So=20 > this may not=20 > >> be an > >> issue after all. > >> > >> Can vendors who send info in the EAP-Request/Identity=20 > verify that a NUL > >> character is never sent? > >=20 > >=20 > > there is never a NUL character as long as the only sent=20 > data is the user=20 > > identity (which is usually that displayable string). the NUL-char=20 > > termination was prohibited by the RFC2248. the length field=20 > had to be=20 > > used for that. > >=20 > > hence, the NUL-char can always be part of the sent data=20 > (imho, that was=20 > > the original intention). thus, using the NUL char and=20 > _length from the=20 > > message, an implementation can find the \0 at _pos and=20 > determine the=20 > > length of the realm-list by substration: _length - _pos -=20 > > length("NAIRealms"). > >=20 > > this NUL character is thus indispensable in the ABNF at the=20 > place where=20 > > it is. otherwise the string NAIRealms has to be excluded as=20 > possible=20 > > identity part. if another implementation has to add=20 > something else, i=20 > > suggest it includes a second NUL char at the end of the=20 > proposed format. > >=20 > > generally, every implementation using this mechanism has to=20 > be prepared=20 > > to parse the whole length of data searching for the NUL=20 > characters and=20 > > trying to parse what follows. it can never reasonably be=20 > assumed that it=20 > > is the only one using NUL chars. this also presumes that NO=20 > > implementation will ever use the NUL char for data (since=20 > it is now used=20 > > as delimiter). > >=20 > >=20 > > regards > > artur > >=20 > >=20 > >=20 > >> > >> On Tue, 16 Nov 2004, Bernard Aboba wrote: > >> > >> > >>> Issue 281: Backward compatibility problem > >>> Submitter name: Bernard Aboba > >>> Submitter email address: aboba@internaut.com > >>> Date first submitted: 11/16/2004 > >>> Reference: > >>> Document: IDSEL-05 > >>> Comment type: T > >>> Priority: S > >>> Section: 2.1 > >>> Rationale/Explanation of issue > >>> > >>> I think that there is a problem with the ABNF defined in=20 > Section 2.1. > >>> > >>> identity-request-data =3D [ displayable-string ] > >>> [ %x00 "NAIRealms=3D" realm-list ] > >>> displayable-string =3D *OCTET > >>> realm-list =3D realm / > >>> ( realm-list ";" realm ) > >>> Section 2.1 states: > >>> > >>> "Some existing systems are known to use EAP=20 > Identity/Request messages > >>> to send proprietary information to the peer. This proprietary > >>> information is considered to be part of the=20 > displayable-string in the > >>> ABNF shown above. In other words, the NUL character=20 > followed by the > >>> NAIRealms list MUST be placed at the end." > >>> > >>> Actually, existing implementations send information such as the > >>> NAS-Identity *after* the NUL character. Requiring the=20 > NAIRealms list=20 > >>> to be > >>> sent first is therefore not backward compatible with existing > >>> implementations. > >>> > >>> I'd suggest that you need to change the ABNF to enable=20 > the NAI-Realms > >>> attribute to be separated from the NUL character by text=20 > other than=20 > >>> the attribute > >>> separator used by existing implementations. > >>> > >>> > >> > >> _______________________________________________ > >> 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 > >=20 > >=20 >=20 > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap >=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Nov 18 13:39:08 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 NAA19998 for ; Thu, 18 Nov 2004 13:39:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EA65C1FD47; Thu, 18 Nov 2004 13:39:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 20E541FD49; Thu, 18 Nov 2004 13:39:04 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 00DC31FD49 for ; Thu, 18 Nov 2004 13:38:47 -0500 (EST) Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by mail.frascone.com (Postfix) with ESMTP id 343A11FD47 for ; Thu, 18 Nov 2004 13:38:44 -0500 (EST) Received: from [192.168.1.50] (massena-5-82-66-229-84.fbx.proxad.net [82.66.229.84]) by postfix3-1.free.fr (Postfix) with ESMTP id F1E821734E7; Thu, 18 Nov 2004 19:38:42 +0100 (CET) Message-ID: <419CEC31.7000108@enst.fr> From: Artur Hecker User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Adrangi, Farid" Cc: eap@frascone.com Subject: Re: [eap] Re: Issue 281: Backward compatibility problem 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: Thu, 18 Nov 2004 19:38:41 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Farid, my remark was meant to say that i do not agree with the Issue 281. in my opinion it is wrong to change the ABNF as proposed in the issue 281. so, i agree with you. the only thing to clarify would be perhaps the coexistence with other implementations using the same mechanism. any implementation of your draft SHOULD be prepared for presence of other extensions using the same mechanism. personally, i think it is quite easy to relax the requirements and to get the same result: i am not sure requiring NAIRealms at the end is the best choice - it could be easily violated by some proprietary mechanism. i think it is more robust and not really complicated to require parsing from 0 to length of the EAP message, searching for "\0NAIRealms" and extracting the data from the found position till to the next NUL or the message end. however, i let the final decision to authors. in _any_ case, an implementation MUST handle NAIRealms data correctly. perhaps, you could provide a pseudo-code routine for that. (i am not sure this is already in the draft in any form; but in my opinion it has little to do with issue 281). regards artur > In the context of the network discovery draft, we need to make sure that > an implementation can extract NAIRealms information. Given the > following facts in the draft: > > 1) NAIRealms is always placed at the end > 2) NAIRealm follows by a NUL > 3) NAIREALM data does not include NUL > > an implementation should always be able to extract the NAIRealms > information. For the rest of stuff (i.e., displayable string or other > proprietary stuff), we don't need to worry about the use of NUL (e.g., > should it be used as delimiter? Can it be included in data?) in this > draft - do we? > > Are we agreeing that this is not an issue and hence to changes required > to the draft? > > BR, > Farid > > > > > > >>-----Original Message----- >>From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] >>On Behalf Of Jari Arkko >>Sent: Wednesday, November 17, 2004 12:59 PM >>To: Artur Hecker >>Cc: eap@frascone.com >>Subject: Re: [eap] Re: Issue 281: Backward compatibility problem >> >> >>I agree with this. And yes it is necessary to prepare >>for the case that there's something else than this >>particular piece of data. >> >>--Jari >> >>Artur Hecker wrote: >> >>>hello >>> >>> >>>we've already discussed that in the 2248bis scope. >>> >>>Bernard Aboba wrote: >>> >>> >>>>Actually, I've rechecked the traces of existing >> >>implementations, and in >> >>>>the cases I've looked at there is no NUL character. So >> >>this may not >> >>>>be an >>>>issue after all. >>>> >>>>Can vendors who send info in the EAP-Request/Identity >> >>verify that a NUL >> >>>>character is never sent? >>> >>> >>>there is never a NUL character as long as the only sent >> >>data is the user >> >>>identity (which is usually that displayable string). the NUL-char >>>termination was prohibited by the RFC2248. the length field >> >>had to be >> >>>used for that. >>> >>>hence, the NUL-char can always be part of the sent data >> >>(imho, that was >> >>>the original intention). thus, using the NUL char and >> >>_length from the >> >>>message, an implementation can find the \0 at _pos and >> >>determine the >> >>>length of the realm-list by substration: _length - _pos - >>>length("NAIRealms"). >>> >>>this NUL character is thus indispensable in the ABNF at the >> >>place where >> >>>it is. otherwise the string NAIRealms has to be excluded as >> >>possible >> >>>identity part. if another implementation has to add >> >>something else, i >> >>>suggest it includes a second NUL char at the end of the >> >>proposed format. >> >>>generally, every implementation using this mechanism has to >> >>be prepared >> >>>to parse the whole length of data searching for the NUL >> >>characters and >> >>>trying to parse what follows. it can never reasonably be >> >>assumed that it >> >>>is the only one using NUL chars. this also presumes that NO >>>implementation will ever use the NUL char for data (since >> >>it is now used >> >>>as delimiter). >>> >>> >>>regards >>>artur >>> >>> >>> >>> >>>>On Tue, 16 Nov 2004, Bernard Aboba wrote: >>>> >>>> >>>> >>>>>Issue 281: Backward compatibility problem >>>>>Submitter name: Bernard Aboba >>>>>Submitter email address: aboba@internaut.com >>>>>Date first submitted: 11/16/2004 >>>>>Reference: >>>>>Document: IDSEL-05 >>>>>Comment type: T >>>>>Priority: S >>>>>Section: 2.1 >>>>>Rationale/Explanation of issue >>>>> >>>>>I think that there is a problem with the ABNF defined in >> >>Section 2.1. >> >>>>> identity-request-data = [ displayable-string ] >>>>> [ %x00 "NAIRealms=" realm-list ] >>>>> displayable-string = *OCTET >>>>> realm-list = realm / >>>>> ( realm-list ";" realm ) >>>>>Section 2.1 states: >>>>> >>>>>"Some existing systems are known to use EAP >> >>Identity/Request messages >> >>>>>to send proprietary information to the peer. This proprietary >>>>>information is considered to be part of the >> >>displayable-string in the >> >>>>>ABNF shown above. In other words, the NUL character >> >>followed by the >> >>>>>NAIRealms list MUST be placed at the end." >>>>> >>>>>Actually, existing implementations send information such as the >>>>>NAS-Identity *after* the NUL character. Requiring the >> >>NAIRealms list >> >>>>>to be >>>>>sent first is therefore not backward compatible with existing >>>>>implementations. >>>>> >>>>>I'd suggest that you need to change the ABNF to enable >> >>the NAI-Realms >> >>>>>attribute to be separated from the NUL character by text >> >>other than >> >>>>>the attribute >>>>>separator used by existing implementations. >>>>> >>>>> >>>> >>>>_______________________________________________ >>>>eap mailing list >>>>eap@frascone.com >>>>http://mail.frascone.com/mailman/listinfo/eap >>> >>>_______________________________________________ >>>eap mailing list >>>eap@frascone.com >>>http://mail.frascone.com/mailman/listinfo/eap >>> >>> >> >>_______________________________________________ >>eap mailing list >>eap@frascone.com >>http://mail.frascone.com/mailman/listinfo/eap >> _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From Ge-Ge.Houser@us.net Thu Nov 18 14:55:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26840 for ; Thu, 18 Nov 2004 14:55:19 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUsPu-0001o6-5y for eap-archive@ietf.org; Thu, 18 Nov 2004 14:58:06 -0500 Received: from c-67-163-223-215.client.comcast.net ([67.163.223.215] ident=wsttc) by mx2.foretec.com with smtp (Exim 4.24) id 1CUsN8-0003Pc-5Y for eap-archive@ietf.org; Thu, 18 Nov 2004 14:55:14 -0500 Received: from mail.hsr.com (67.163.223.215) by 67.163.223.215 with Microsoft SMTP63650(5.93.9.7); Thu, 18 Nov 2004 23:00:26 +0400 Received: from 67.163.223.215 (limerick[67.163.223.215]) by mail.hsr.com (kocpad8) with SMTP id <54909s55f> (Authid: 288801); Thu, 18 Nov 2004 12:55:26 -0600 Message-ID: Reply-To: "Spaso Shari.Lee" From: "Spaso Shari.Lee" To: ietf-outbound.07@ietf.org Cc: ran@ietf.org, r-wg-admin@ietf.org, seamoby@ietf.org, rpr@ietf.org, er-wgchairs@ietf.org, eap-archive@ietf.org, owner-wgchairs@ietf.org Subject: You Qualify for $312955 Date: Thu, 18 Nov 2004 13:00:26 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--2379928962737026214" X-Spam-Score: 6.3 (++++++) X-Spam-Flag: YES X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab ----2379928962737026214 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7Bit Dear Applicant, Your application was processed and approved. You are eligible for $ 400,000 with a 2.1 % rate. Please verify your information here: http://quoteyourrate.com/?partid=aaks9 We look forward to hearing from you. Spaso Shari.Lee, Account Manager Bell Marketing 4206 Central Avenue Columbus, OH 43085 not interested -> http://quoteyourrate.com/st.html ----2379928962737026214-- From eap-admin@frascone.com Thu Nov 18 19:45:06 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10735 for ; Thu, 18 Nov 2004 19:45:05 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 38A1D1FD49; Thu, 18 Nov 2004 19:45:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7246B1FD4C; Thu, 18 Nov 2004 19:45:04 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E26121FD4C for ; Thu, 18 Nov 2004 19:44:19 -0500 (EST) Received: from cingular.com (extmail12.cingular.com [170.35.225.27]) by mail.frascone.com (Postfix) with ESMTP id CFDDA1FD49 for ; Thu, 18 Nov 2004 19:44:16 -0500 (EST) Received: from ([135.214.42.163]) by extmail12.cingular.com with ESMTP id KP-VYHH4.6380056; Thu, 18 Nov 2004 19:42:11 -0500 Received: from nwestmail.entp.attws.com (localhost [127.0.0.1]) by viruswall.entp.attws.com (8.12.10/8.12.10) with ESMTP id iAJ0g60R004200; Thu, 18 Nov 2004 16:42:10 -0800 (PST) Received: from WA-MSGBH01-BTH.wireless.attws.com (WA-MSGBH01-BTH.wireless.attws.com [135.214.26.241]) by nwestmail.entp.attws.com (8.8.8p2+Sun/8.8.8) with ESMTP id QAA14866; Thu, 18 Nov 2004 16:42:07 -0800 (PST) Received: from WA-MSG10-BTH.wireless.attws.com ([135.214.41.74]) by WA-MSGBH01-BTH.wireless.attws.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 18 Nov 2004 16:42:06 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Re: Issue 281: Backward compatibility problem Message-ID: Thread-Topic: [eap] Re: Issue 281: Backward compatibility problem Thread-Index: AcTNnew0WWfDrAT4TIixn2RlDp/qGQAMlDSg From: "Bari, Farooq" To: "Artur Hecker" , "Adrangi, Farid" Cc: X-OriginalArrivalTime: 19 Nov 2004 00:42:06.0834 (UTC) FILETIME=[987B8520:01C4CDD0] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 18 Nov 2004 16:42:06 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable If there is no disagreement then maybe we can close the issue 281 with no changes to the draft. I have not seen any disagreement to it so far. BR, Farooq -----Original Message----- From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] On Behalf Of Artur Hecker Sent: Thursday, November 18, 2004 10:39 AM To: Adrangi, Farid Cc: eap@frascone.com Subject: Re: [eap] Re: Issue 281: Backward compatibility problem Farid, my remark was meant to say that i do not agree with the Issue 281. in my opinion it is wrong to change the ABNF as proposed in the issue 281. so, i agree with you. the only thing to clarify would be perhaps the coexistence with other=20 implementations using the same mechanism. any implementation of your=20 draft SHOULD be prepared for presence of other extensions using the same mechanism. personally, i think it is quite easy to relax the requirements and to=20 get the same result: i am not sure requiring NAIRealms at the end is the best choice - it could be easily violated by some proprietary mechanism. i think it is more robust and not really complicated to require parsing=20 from 0 to length of the EAP message, searching for "\0NAIRealms" and=20 extracting the data from the found position till to the next NUL or the=20 message end. however, i let the final decision to authors. in _any_ case, an=20 implementation MUST handle NAIRealms data correctly. perhaps, you could=20 provide a pseudo-code routine for that. (i am not sure this is already=20 in the draft in any form; but in my opinion it has little to do with=20 issue 281). regards artur > In the context of the network discovery draft, we need to make sure that > an implementation can extract NAIRealms information. Given the > following facts in the draft: >=20 > 1) NAIRealms is always placed at the end > 2) NAIRealm follows by a NUL > 3) NAIREALM data does not include NUL >=20 > an implementation should always be able to extract the NAIRealms > information. For the rest of stuff (i.e., displayable string or other > proprietary stuff), we don't need to worry about the use of NUL (e.g., > should it be used as delimiter? Can it be included in data?) in this > draft - do we? >=20 > Are we agreeing that this is not an issue and hence to changes required > to the draft? >=20 > BR, > Farid >=20 >=20 >=20 >=20 >=20 >=20 >>-----Original Message----- >>From: eap-admin@frascone.com [mailto:eap-admin@frascone.com]=20 >>On Behalf Of Jari Arkko >>Sent: Wednesday, November 17, 2004 12:59 PM >>To: Artur Hecker >>Cc: eap@frascone.com >>Subject: Re: [eap] Re: Issue 281: Backward compatibility problem >> >> >>I agree with this. And yes it is necessary to prepare >>for the case that there's something else than this >>particular piece of data. >> >>--Jari >> >>Artur Hecker wrote: >> >>>hello >>> >>> >>>we've already discussed that in the 2248bis scope. >>> >>>Bernard Aboba wrote: >>> >>> >>>>Actually, I've rechecked the traces of existing=20 >> >>implementations, and in >> >>>>the cases I've looked at there is no NUL character. So=20 >> >>this may not=20 >> >>>>be an >>>>issue after all. >>>> >>>>Can vendors who send info in the EAP-Request/Identity=20 >> >>verify that a NUL >> >>>>character is never sent? >>> >>> >>>there is never a NUL character as long as the only sent=20 >> >>data is the user=20 >> >>>identity (which is usually that displayable string). the NUL-char=20 >>>termination was prohibited by the RFC2248. the length field=20 >> >>had to be=20 >> >>>used for that. >>> >>>hence, the NUL-char can always be part of the sent data=20 >> >>(imho, that was=20 >> >>>the original intention). thus, using the NUL char and=20 >> >>_length from the=20 >> >>>message, an implementation can find the \0 at _pos and=20 >> >>determine the=20 >> >>>length of the realm-list by substration: _length - _pos -=20 >>>length("NAIRealms"). >>> >>>this NUL character is thus indispensable in the ABNF at the=20 >> >>place where=20 >> >>>it is. otherwise the string NAIRealms has to be excluded as=20 >> >>possible=20 >> >>>identity part. if another implementation has to add=20 >> >>something else, i=20 >> >>>suggest it includes a second NUL char at the end of the=20 >> >>proposed format. >> >>>generally, every implementation using this mechanism has to=20 >> >>be prepared=20 >> >>>to parse the whole length of data searching for the NUL=20 >> >>characters and=20 >> >>>trying to parse what follows. it can never reasonably be=20 >> >>assumed that it=20 >> >>>is the only one using NUL chars. this also presumes that NO=20 >>>implementation will ever use the NUL char for data (since=20 >> >>it is now used=20 >> >>>as delimiter). >>> >>> >>>regards >>>artur >>> >>> >>> >>> >>>>On Tue, 16 Nov 2004, Bernard Aboba wrote: >>>> >>>> >>>> >>>>>Issue 281: Backward compatibility problem >>>>>Submitter name: Bernard Aboba >>>>>Submitter email address: aboba@internaut.com >>>>>Date first submitted: 11/16/2004 >>>>>Reference: >>>>>Document: IDSEL-05 >>>>>Comment type: T >>>>>Priority: S >>>>>Section: 2.1 >>>>>Rationale/Explanation of issue >>>>> >>>>>I think that there is a problem with the ABNF defined in=20 >> >>Section 2.1. >> >>>>> identity-request-data =3D [ displayable-string ] >>>>> [ %x00 "NAIRealms=3D" realm-list ] >>>>> displayable-string =3D *OCTET >>>>> realm-list =3D realm / >>>>> ( realm-list ";" realm ) >>>>>Section 2.1 states: >>>>> >>>>>"Some existing systems are known to use EAP=20 >> >>Identity/Request messages >> >>>>>to send proprietary information to the peer. This proprietary >>>>>information is considered to be part of the=20 >> >>displayable-string in the >> >>>>>ABNF shown above. In other words, the NUL character=20 >> >>followed by the >> >>>>>NAIRealms list MUST be placed at the end." >>>>> >>>>>Actually, existing implementations send information such as the >>>>>NAS-Identity *after* the NUL character. Requiring the=20 >> >>NAIRealms list=20 >> >>>>>to be >>>>>sent first is therefore not backward compatible with existing >>>>>implementations. >>>>> >>>>>I'd suggest that you need to change the ABNF to enable=20 >> >>the NAI-Realms >> >>>>>attribute to be separated from the NUL character by text=20 >> >>other than=20 >> >>>>>the attribute >>>>>separator used by existing implementations. >>>>> >>>>> >>>> >>>>_______________________________________________ >>>>eap mailing list >>>>eap@frascone.com >>>>http://mail.frascone.com/mailman/listinfo/eap >>> >>>_______________________________________________ >>>eap mailing list >>>eap@frascone.com >>>http://mail.frascone.com/mailman/listinfo/eap >>> >>> >> >>_______________________________________________ >>eap mailing list >>eap@frascone.com >>http://mail.frascone.com/mailman/listinfo/eap >> _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From yxitspzunrv@mchsi.com Fri Nov 19 02:23:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28008; Fri, 19 Nov 2004 02:23:20 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CV39n-0004XB-Py; Fri, 19 Nov 2004 02:26:14 -0500 Received: from 12-217-169-39.client.mchsi.com ([12.217.169.39]) by mx2.foretec.com with smtp (Exim 4.24) id 1CV36w-0004uo-0s; Fri, 19 Nov 2004 02:23:17 -0500 Received: from gateway.mchsi.com by 12-217-169-39.client.mchsi.com with Microsoft SMTPSVC; Fri, 19 Nov 2004 00:10:26 -0600 Received: from 60.188.208.169 by gateway.mchsi.com with SMTP; Fri, 19 Nov 2004 00:09:35 -0600 To: Rachel Mime-Version: 1.0 From: "Kristina" Date: Fri, 19 Nov 2004 03:06:26 -0300 Subject: her arms around her Message-ID: <3509959015907.erZ4g@SSUPUIS> Content-Type: text/plain; charset=KOI8-R; Content-Transfer-Encoding: 7bit X-Spam-Score: 6.0 (++++++) X-Spam-Flag: YES X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Hello, Resently we sent you an email about mor t g age r at e going up, just from last week that ra t es went up by 2 point. Its not to late to lock your mor tg age. You can qualifiy to get a 400, 000 at 400 a month. But please act fast as the ra tes will not stay low for much longer. http://www.accesskl.com/ Thank you, Best regards, Kristina From ZHJSFMY@hotmail.com Fri Nov 19 15:34:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12449; Fri, 19 Nov 2004 15:34:04 -0500 (EST) Message-Id: <200411192034.PAA12449@ietf.org> Received: from host-66-81-176-106.rev.o1.com ([66.81.176.106]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CVFV3-0006Mq-6I; Fri, 19 Nov 2004 15:37:06 -0500 Received: from 250.26.249.243 by 66.81.176.106; Sat, 20 Nov 2004 01:30:20 +0500 Reply-To: "Buddy Aguirre" From: "Buddy Aguirre" To: disman-admin@ietf.org Subject: You Need This Disman-admin PID: 8 starfish Date: Fri, 19 Nov 2004 16:33:20 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--2367265107411581403" X-Spam-Score: 5.4 (+++++) X-Spam-Flag: YES X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ----2367265107411581403 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit The L0west price of all med's is here. V1a'gra - $199.95 (60 pil|s) Va|ium - $259.95 (100 pil|s) Cia|is - $189.95 (30 pi||s) Xa'nax - $233.95 (100 pi|ls) and many m0reeee..... We are the bes't available nowadays http://www.eachmesunshine.com/2/sale/?wid=200007 This is 1 -time mailing. N0-re m0val are re'qui-red haMbeeKpCVUtxuyrO8hZ131JtqrfI0zVLDFBPgowbtfvjXZ2T3 ----2367265107411581403-- From chomsky9@animail.net Fri Nov 19 19:53:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13137; Fri, 19 Nov 2004 19:53:50 -0500 (EST) Received: from [218.98.88.227] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CVJYU-0006vD-Q1; Fri, 19 Nov 2004 19:56:53 -0500 Received: from 235.250.254.78 (HELO urinary2immodesty3bribery2.spiteblackmail.tv) by edwina@hierarchal.net (5.0.013) Received: from qjpp.tv by catchy@rondo.tv (6.0.019) X-MID: Message-Id: Date: Sat, 20 Nov 2004 06:47:01 +0600 From: "Luke Whitehead" To: adslmib@ietf.org Cc: ans-research@ietf.org, asrg@ietf.org, bmwg@ietf.org, cats@ietf.org, cfrg@ietf.org, cfrg-admin@ietf.org, cfrg-archive@ietf.org, cfrg-request@ietf.org, chair@ietf.org, diffserv-interest-admin@ietf.org, dinaras@ietf.org, disman@ietf.org, eap-archive@ietf.org, entmib@ietf.org, entmib-request@ietf.org, geopriv-admin@ietf.org Subject: RE account# BV2486739 X-NAS-Classification: 1 X-NAS-MessageID: 439 X-NAS-Validation: {3ED76BFB-4B37-45EC-95DD-10740EBCD4BF} MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Message-flag: Authentic Sender, Hash: FgJwMwWp Content-Disposition: inline X-Spam-Score: 10.0 (++++++++++) X-Spam-Flag: YES X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Hello,

We sent you an email a while ago, because you now qualify for a new mortgage.
You could get $300,000 for as little as $600 a month!
Bad credit is no problem, you can pull cash out or refinance.

Please click on this link for free consultation by a mortgage broker:
Start Saving Here

Best Regards,
Luke Whitehead

For email removal, go here.






































follicle carbondale claustrophobic resin cavalcade gin tektite redbird troposphere cecil denial arcsine bayreuth circumlocution vivaldi polarogram grimes derekarsine devastate aeolus commission petrifaction wouldn't riddle support yosemite hurt dovetail threshold vouch calm commandeer deregulatory conversant scurrysixteen infallible craftspeople dido aide zellerbach enormity evenhanded glucose bank nerve antares chameleon elapse kissing complementation drove churchyardmobil bloodroot image exclusive embroil o'hare mull acre refusal bedim slosh electoral arturo contiguous hirsute manatee byproduct afternoonderision oughtn't protoplasmic boggy tripartite hour comedy voluminous armour mcallister stringent blackburn contradistinguish coexist bogey From npzntfxtawkx@adelphia.net Fri Nov 19 21:30:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20255; Fri, 19 Nov 2004 21:30:27 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVL3w-0000RZ-VK; Fri, 19 Nov 2004 21:33:32 -0500 Received: from ny-amherst-c4-2-bg1b-2-61.bflony.adelphia.net ([67.21.89.61]) by mx2.foretec.com with smtp (Exim 4.24) id 1CVL0y-0007mS-Gz; Fri, 19 Nov 2004 21:30:16 -0500 Received: from ietf-mx.ietf.org by ny-amherst-c4-2-bg1b-2-61.bflony.adelphia.net with Microsoft SMTPSVC; Fri, 19 Nov 2004 19:17:48 -0600 Received: from 159.194.0.47 by mx.adelphia.net with Microsoft SMTPSVC; Fri, 19 Nov 2004 19:16:59 -0600 To: Eap-archive Date: Fri, 19 Nov 2004 19:17:01 -0600 Content-Transfer-Encoding: 7bit Subject: place on the floor. Message-ID: <1900588-2059534040416668@adelphia.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-11; From: "Tommie Benoit" X-Spam-Score: 2.6 (++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit From: Tommie Benoit CC: Department 55 Date: Fri, 19 Nov 2004 19:17:48 -0600 Re: L o an a p proval -- Sir: We have reviewed you information and glad to inform you that you qualify for 4.8% mor tgage r ate under our company l e nding program. Please use this URL to enter final details and our manager will contact you ASAP. http://www.trnnet.com/ We look forward to doing business with you. Best Regards CEO: Tommie Benoit From caterpillar3@dbzmail.com Sat Nov 20 04:04:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03465; Sat, 20 Nov 2004 04:04:30 -0500 (EST) Received: from [60.13.229.246] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CVRDT-0008JW-NR; Sat, 20 Nov 2004 04:07:38 -0500 Received: from spy.list.ru[107.157.182.188]:79890 "EHLO buttery.list.ru") by avas-mx45.list.ru with ESMTP id S721590AbUJINmX; Sat, 20 Nov 2004 09:57:01 +0100 Original-Recipient: rfc822; caterpillar3@dbzmail.com Date: Sat, 20 Nov 2004 02:01:01 -0700 Message-Id: <6789556326.i93ErrTw00005@trampbrine.biz> Date: Sat, 20 Nov 2004 06:53:01 -0200 From: "Isabella Richey" To: secdir@ietf.org Cc: disman@ietf.org, eap-archive@ietf.org, entmib@ietf.org, entmib-request@ietf.org, geopriv-admin@ietf.org, idr@ietf.org, iesg@ietf.org, iesg-secretary@ietf.org, ietf-announce-request@ietf.org, ietf-proceedings@ietf.org, ietf-registrar@ietf.org, ietf-rsvp@ietf.org X-Sender: caterpillar3@dbzmail.com X-Originating-Email: [caterpillar3@dbzmail.com] X-Originating-IP: [192.128.41.118] Subject: RE account# NX9098844 MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Message-flag: Authentic Sender, Hash: KcEzKwFo Content-Disposition: inline X-Spam-Score: 7.6 (+++++++) X-Spam-Flag: YES X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Hello,

We sent you an email a while ago, because you now qualify for a new mortgage.
You could get $300,000 for as little as $600 a month!
Bad credit is no problem, you can pull cash out or refinance.

Please click on this link for free consultation by a mortgage broker:
Start Saving Here

Best Regards,
Isabella Richey

For email removal, go here.






































hemlock committing gawky lepidolite swatch disciplinarian wood downslope inconsistent galloway guzzle crew allyn boorish portend autopsy lagrange wombatadvantageous knudson cheney encore chilean astronaut crusoe pizza dull dull firefly murder troupe ibn viscosity baseline briggs imprisonarticle soccer endoderm eightieth different diffractometer depth this foxhall lob cuddly budd stadium deadwood penelope wedge automorphism callerdeface corduroy bisect divorcee filet octahedron taffy acquit cashew shear stinky mackinaw asilomar puke veronica weiss subtle algenibaura phalarope sovereignty lower deaf flogging shave barney armenia belittle crumble ethnic exam lessee roosevelt From lboxioxbotljak@aol.com Sat Nov 20 07:00:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16104 for ; Sat, 20 Nov 2004 07:00:33 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVTxu-0003GJ-KX for eap-archive@ietf.org; Sat, 20 Nov 2004 07:03:44 -0500 Received: from [211.223.23.29] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1CVTur-00060B-4G for eap-archive@ietf.org; Sat, 20 Nov 2004 07:00:34 -0500 Received: from 56.36.172.219 by 211.223.23.29; Sat, 20 Nov 2004 12:51:24 +0100 Message-ID: From: "Moises " Reply-To: "Moises " To: eamoby@ietf.org Subject: Discounted m5icrosoft s0ftware Date: Sat, 20 Nov 2004 06:56:24 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--5228878102701869375" X-Priority: 5 X-IP: 202.104.145.202 X-Spam-Score: 7.2 (+++++++) X-Spam-Flag: YES X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 ----5228878102701869375 Content-Type: text/html; Content-Transfer-Encoding: 7Bit

Have programs softwar.e
Norton Internet Security Pro 2004, Norton Antivirus 2004 Professional Edition, Windows 2005
We have more
Free shipping on any software you order
Get your programs tomorrow
Cheap, Right Here

----5228878102701869375-- From kygbptqhkgfeoif@telemach.net Sat Nov 20 17:05:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01559; Sat, 20 Nov 2004 17:05:14 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVdPC-0007Oz-6V; Sat, 20 Nov 2004 17:08:30 -0500 Received: from [213.143.75.62] (helo=tm.231.143.75.62.nm.telemach.net) by mx2.foretec.com with smtp (Exim 4.24) id 1CVdLx-0000st-Pv; Sat, 20 Nov 2004 17:05:10 -0500 Received: from isis.telemach.net by tm.231.143.75.62.nm.telemach.net with DAV; Sat, 20 Nov 2004 14:52:41 -0600 Received: from 22.105.175.201 by isis.telemach.net with vyhxma; Sat, 20 Nov 2004 14:51:48 -0600 Date: Sat, 20 Nov 2004 14:51:45 -0600 To: Bobbie Content-Transfer-Encoding: 7bit Message-ID: <61979363539683.84493.qmail@telemach.net> Content-Type: text/plain; charset="ISO-8859-4" Subject: Re: Welcome back Mime-Version: 1.0 From: "Mcgrath" X-Spam-Score: 4.6 (++++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit From: Mcgrath CC: Department 23 Date: Sat, 20 Nov 2004 14:52:41 -0600 Re: L o an a p proval -- Sir: We have reviewed you information and glad to inform you that you qualify for 4.8% mor tgage r ate under our company l e nding program. Please use this URL to enter final details and our manager will contact you ASAP. http://www.accesskl.com/ We look forward to doing business with you. Best Regards CEO: Mcgrath From crymyrrp@chase.com Sun Nov 21 05:18:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02635; Sun, 21 Nov 2004 05:18:28 -0500 (EST) Message-Id: <200411211018.FAA02635@ietf.org> Received: from [219.251.70.167] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CVoqd-0007gD-MM; Sun, 21 Nov 2004 05:21:50 -0500 Received: from mail.usis.com (219.251.70.167) by 219.251.70.167 (differentiablev.75) with SMTP id <78436249q71b> (Authid: 302); Sun, 21 Nov 2004 07:14:09 -0200 Reply-To: "Panchito Hosea" From: "Panchito Hosea" To: l2vpn-web-archive@ietf.org Cc: iab-wireless-workshop@ietf.org, seamoby@ietf.org, bpana@ietf.org, owner-ietf-outbound@ietf.org, entmib-request@ietf.org, xmldsig-archive@ietf.org, rmt-request@ietf.org, simple@ietf.org, eap-archive@ietf.org Subject: Account: $12352 Date: Sun, 21 Nov 2004 04:15:09 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--42623934975356700232" X-Spam-Score: 10.5 (++++++++++) X-Spam-Flag: YES X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab ----42623934975356700232 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7Bit Dear Applicant, Your application was processed and approved. You are eligible for $ 400,000 with a 2.1 % rate. Please verify your information here: http://quoteyourrate.com/?partid=aaks9 We look forward to hearing from you. Panchito Hosea, Account Manager Bell Marketing 4206 Central Avenue Columbus, OH 43085 not interested -> http://quoteyourrate.com/st.html ----42623934975356700232-- From QKCIN@latinmail.com Mon Nov 22 02:33:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26013 for ; Mon, 22 Nov 2004 02:33:37 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CW8l3-0006gL-N8 for eap-archive@ietf.org; Mon, 22 Nov 2004 02:37:10 -0500 Received: from [200.228.80.2] (helo=FIREWALL) by mx2.foretec.com with smtp (Exim 4.24) id 1CW8pQ-0005eu-7U for eap-archive@ietf.org; Mon, 22 Nov 2004 02:41:41 -0500 Received: from 144.68.124.86 by mail.serpens.carruthers.chard.net ([200.228.80.2]) with SMTP for ; Sun, 21 Nov 2004 23:33:29 -0800 Message-ID: <3440202.9324098306642.JavaMail.broadcast@actressdecimal> Reply-To: "Wanda Myers" From: "Wanda Myers" To: eamoby@ietf.org, eap-archive@ietf.org Subject: Vote : Rolex or Breitling? Date: Sun, 21 Nov 2004 23:33:29 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005E_65986890103506950363" X-Spam-Score: 7.2 (+++++++) X-Spam-Flag: YES X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d ------=_NextPart_000_005E_65986890103506950363 Content-Type: text/html; Content-Transfer-Encoding: 7Bit

Rolex Replicas

*DAYTONA, SUBMARINER, OYSTER PERPETUAL*

Visit our Online Store. www.yomoi.com/replica/folex/

With over 1300 Models available you are
sure to find a replica *ROLEX* that will
suit your tastes.


* Genuine Swiss Replicas
* Wholesale Prices (Save upto 200%)
* Same Day Shipping (World Wide)



Do you want to 0pt 0ut? www.yomoi.com/z.php

------=_NextPart_000_005E_65986890103506950363-- From eap-admin@frascone.com Mon Nov 22 02:51:13 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27786 for ; Mon, 22 Nov 2004 02:51:12 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 61DE91FD3C; Mon, 22 Nov 2004 02:51:09 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EEABF1FCD0; Mon, 22 Nov 2004 02:51:05 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7EA811FCCF for ; Mon, 22 Nov 2004 02:51:00 -0500 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by mail.frascone.com (Postfix) with ESMTP id 05F6C1FC7A for ; Mon, 22 Nov 2004 02:50:58 -0500 (EST) Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.42) id 1CW8yP-0004dD-HV for eap@frascone.com; Mon, 22 Nov 2004 02:50:57 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id iAM7oue25919 for ; Sun, 21 Nov 2004 23:50:56 -0800 From: Bernard Aboba To: eap@frascone.com In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] REMINDER: "Pseudo-WG last call" on Identity Selection for EAP draft Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 21 Nov 2004 23:50:56 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Reminder: The "pseudo-WG last call" completes tommorrow, November 22, 2004. So if you have comments, please send them in. On Sun, 14 Nov 2004, Bernard Aboba wrote: > The document "Identity Selection Hints for EAP" is not an EAP WG work > item, but is requesting publication as an individual submission to the RFC > Editor. > > Prior to publishing this document as an Informational RFC, it has been > requested that the EAP WG review the document, which is available > here: > > http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-05.txt > > Since this document has already gone through one EAP WG "pseudo WG last > call" and has resolved the issues that were raised, we will do a short > WG last call to make sure that we have caught any remaining issues. > > EAP WG "pseudo WG last call" will last until November 22, 2004. If you > approve of publishing this document, please send a message with "Identity: > Publish" in the subject to the EAP WG mailing list. If you have an issue > with this document, please send comments to the EAP WG mailing list > (eap@frascone.com) in the format specified in the EAP Issues list: > > http://www.drizzle.com/~aboba/EAP/eapissues.html > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Nov 22 03:12:09 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 DAA29791 for ; Mon, 22 Nov 2004 03:12:08 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B49321FCD0; Mon, 22 Nov 2004 03:12:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1CB681FCD6; Mon, 22 Nov 2004 03:12:04 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9A3061FCD6 for ; Mon, 22 Nov 2004 03:11:24 -0500 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by mail.frascone.com (Postfix) with ESMTP id 052BA1FCD0 for ; Mon, 22 Nov 2004 03:11:22 -0500 (EST) Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.42) id 1CW9I9-000JYf-RB for eap@frascone.com; Mon, 22 Nov 2004 03:11:21 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id iAM8BKQ27323 for ; Mon, 22 Nov 2004 00:11:20 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] RFC 3748 Review of EAP SIM 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, 22 Nov 2004 00:11:20 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) RFC 3748 Review of draft-haverinen-pppext-eap-sim-15r1 The following list of issues is provided as a guideline to potential expert reviewers and method authors. 1. Does the method document its security properties in sufficient manner, as required by Section 7.2 of RFC 3748? Yes. Documentation is provided. However, there are some cases where clarity could be improved: Section 1 In any case, if the GSM authentication mechanisms are considered to be sufficient for use on the cellular networks, then EAP-SIM is expected to be sufficiently secure for other networks. [BA] What other networks are being referred to? If the claim is that EAP SIM is sufficiently secure for use on WLAN, then you need to reference draft-walker-ieee802-req-04.txt and include the additional claims defined in that draft within the security claims section. Section 3 Triplets may be stored in the EAP server for use at a later time, but triplets may not be reused, except in some error cases that are specified in Section 9.9 [BA] Don't you mean MUST NOT be reused? Section 11.7 Because EAP-SIM is not a password protocol, it is not vulnerable to dictionary attacks. (The pre-shared symmetric secret stored on the SIM card shall not be a weak password.) [BA] perhaps better to say "is not a passphrase, or derived from a passphrase." Because this attack requires the attacker to build a rogue GSM base station (or at least eavesdrop the GSM traffic), the cost of the attack is not negligible; it is the same cost as usually in GSM. [BA] Building a rogue GSM basestation and eavesdropping on GSM traffic will have different costs. So "same cost as usually in GSM" is not specific. I'd delete this phrase. However, due to several weaknesses in the GSM encryption algorithms, the effective key strength of the Kc keys is much less than the expected 64 bits (no more than 40 bits if the A5/1 GSM encryption algorithm is used; as documented in [Barkan et al. 2003], an active attacker can force the peer to use the weaker A5/2 algorithm that can be broken in less than a second). Because the A5 encryption algorithm is not used in EAP-SIM, and because EAP-SIM does not expose any values calculated from individual Kc keys, it should be noted that these attacks are not possible if the SIM credentials used in EAP-SIM are not shared in GSM/GPRS. [BA] My understanding is that sharing of a SIM between GSM/GPRS and WLAN is likely to be quite popular due to the convenience factor. Given the security implications, do the authors wish to make a recommendation relating to this scenario (e.g. sharing is NOT RECOMMENDED). 1a. Mechanism. Is the mechanism explained? Yes. See Section 12. 1b. Security claims. Are the claimed and not claimed properties listed? Yes. See Section 12. 1c. Justifications for the claims? Is an explanation or reference provided to each of the claims? Explanations or references are provided in Sections 11 & 12. 1d. Key strength. Is the key strength documented? Yes. Issues relating to key strength are documented in Section 11.5. 1e. Description of key hierarchy. Is the key hierarchy documented? Yes. [Optional, at least for now: does it conform to EAP keying framework?] I believe that it does. One issue that may arise is the lack of an EAP Server identity. This could have implications for handoff mechanisms that require a NAS to fetch a key from the server, since the server identity is not authenticated. 1f. Indication of vulnerabilities. Are the known vulnerabilities documented? Yes. Reference is made to the Barkan and Patel papers. [Note: it seems unreasonable to require the documentation of unknown vulnerabilities :-) The "known" may of course be "known to reviewer" or "known to author" or "known to the community", but that appears to be best we can do.] 2. Compliance with EAP packet formats 2a. Does the method comply with the packet formats defined in Section 4 of RFC 3748? Yes. 3. Compliance with EAP behaviour 3a. Does the method comply with Success/Failure usage as defined in Sections 2, 2.2, and 4.2? Yes. See Section 6.2 and 6.3. 3b. Does the method comply with sequence usage as defined in Section 2.1 of RFC 3748? There is an odd statement in Section 11.12: There are man-in-the-middle attacks associated with the use of any EAP method within a tunneled protocol such as PEAP, or within a sequence of EAP methods followed by each other. [BA] Since sequences are prohibited in [RFC3748], some mention of that prohibition is probably appropriate. Otherwise one might read the paragraph as implying that EAP SIM could be used as part of a sequence. 3c. Does the method comply with request/response processing rules as defined in Section 4.1 of RFC 3748? Yes. 3d. Does the method comply with retransmission rules as defined in Section 4.3 of RFC 3748? Yes. 3e. Does the method comply with the usage defined for Identity, as defined in Section 5.1 of RFC 3748? Yes. See Section 4.2. 3f. Does the method comply with the usage defined for Notification, as defined in Section 5.2 of RFC 3748? Yes. See Section 6.1. 3g. Does the method comply with the usage defined for Nak and Expanded-Nak as defined in Section 5.3 of RFC 3748? Yes. 3h. Does the method comply with the MIC usage requirements from Sections 3.1, 7.5, and 7.8 of RFC 3748? Yes. 3i. Does the method define a method-specific peer identity, rather than utilizing the EAP-Response/Identity? Yes. 4. Compliance with IANA requirements 4a. Does the method comply with EAP-based IANA requirements defined in Section 6 of RFC 3748? That is, if it requests the allocation of new numbers in the EAP namespace [not applicable if the numbers have already been allocated], is the type of the document and process appropriate for the desired action? A Type code has already been allocated. I think there is an issue with the IANA considerations section. An IANA registry is requested for the Subtype and Attribute Type number, allocated using "specification required". No review mechanism is specified, yet it is indicated that the same protocol numbers should be assigned to EAP AKA and EAP SIM. It is not clear how this requirement is to be enforced, given the allocation policy. The authors may wish to rethink this. 4b. Does the method comply with other IANA requirements in the IETF standards track RFCs? For instance, does the method attempt to allocate TLS extensions (which would only be possible for standards track RFCs)? Yes. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Nov 22 08:16:10 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27430 for ; Mon, 22 Nov 2004 08:16:09 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 193F91FD4B; Mon, 22 Nov 2004 08:16:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5AFFB1FCBA; Mon, 22 Nov 2004 08:16:04 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6BF941FCBA for ; Mon, 22 Nov 2004 08:15:43 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 522C41FC7A for ; Mon, 22 Nov 2004 08:15:40 -0500 (EST) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id C87C589891; Mon, 22 Nov 2004 15:15:38 +0200 (EET) Message-ID: <41A1E605.4000909@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, "'henry.haverinen@nokia.com'" Subject: Re: [eap] RFC 3748 Review of EAP SIM 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: Mon, 22 Nov 2004 15:13:41 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Thanks for the review, Bernard! Some further discussion from my point of view: > 1. Does the method document its security properties > in sufficient manner, as required by Section 7.2 > of RFC 3748? > > Yes. Documentation is provided. > > However, there are some cases where clarity could be improved: > > Section 1 > > In any case, > if the GSM authentication mechanisms are considered to be sufficient > for use on the cellular networks, then EAP-SIM is expected to be > sufficiently secure for other networks. > > [BA] What other networks are being referred to? If the claim is that > EAP SIM is sufficiently secure for use on WLAN, then you need to > reference draft-walker-ieee802-req-04.txt and include the additional > claims defined in that draft within the security claims section. Information on compliance to draft-walker might indeed be useful. OTOH, we will probably never have methods document their compliance to all possible usage scenarios. From the looks of it, EAP SIM fulfills the draft-walker requirements, but I wouldn't necessarily *require* the draft to be changed unless the authors have some text ready for this. But the document would benefit from listing those claims too. > Section 3 > > Triplets may be stored in the EAP server for use at a later > time, but triplets may not be reused, except in some error cases that > are specified in Section 9.9 > > [BA] Don't you mean MUST NOT be reused? I think so. > Section 11.7 > > Because EAP-SIM is not a password protocol, it is not vulnerable to > dictionary attacks. (The pre-shared symmetric secret stored on the > SIM card shall not be a weak password.) > > [BA] perhaps better to say "is not a passphrase, or derived from a > passphrase." Do you mean in addition to not being a weak password, or as a replacement of the text? > Because this attack requires the attacker to build a rogue GSM base > station (or at least eavesdrop the GSM traffic), the cost of the > attack is not negligible; it is the same cost as usually in GSM. > > [BA] Building a rogue GSM basestation and eavesdropping on GSM traffic > will have different costs. So "same cost as usually in GSM" > is not specific. I'd delete this phrase. Yes, or reformulate. I guess the point was that the cost of GSM components may be a bit higher than some other similar technology (e.g. WLAN AP). But you certainly don't need a full network. So "same cost" is not very well defined. > However, due to several weaknesses in the GSM encryption algorithms, > the effective key strength of the Kc keys is much less than the > expected 64 bits (no more than 40 bits if the A5/1 GSM encryption > algorithm is used; as documented in [Barkan et al. 2003], an active > attacker can force the peer to use the weaker A5/2 algorithm that can > be broken in less than a second). > > Because the A5 encryption algorithm is not used in EAP-SIM, and > because EAP-SIM does not expose any values calculated from individual > Kc keys, it should be noted that these attacks are not possible if > the SIM credentials used in EAP-SIM are not shared in GSM/GPRS. > > [BA] My understanding is that sharing of a SIM between GSM/GPRS and > WLAN is likely to be quite popular due to the convenience factor. > Given the security implications, do the authors wish to make a > recommendation relating to this scenario (e.g. sharing is NOT > RECOMMENDED). Perhaps the main thing is that the implications are spelled out. Which is already done, I think. Recommendation against sharing might be wise, but then again it might not be. One specific issue is that 3GPP is addressing the A5/2 problem as well as other things that caused the Barkan et al problem, and when those techniques are in use (I believe some early parts of those techniques are here soon) then sharing might again be OK. So given the fluid situation I'd rather not recommend anything. Perhaps the document should have some statement about the impact of 3GPP developments into this problem, however. > [Optional, at least for now: does it conform to EAP > keying framework?] > > I believe that it does. One issue that may arise is the lack of an EAP > Server identity. This could have implications for handoff mechanisms that > require a NAS to fetch a key from the server, since the server identity is > not authenticated. Hmm... we may not have explored the handoff design far enough to say for sure, but its not immediately obvious to me that the server identity helps here. There's certainly a key which is shared between the server and the client. And key identifiers, if the eap keying framework defines them. Plus even if the server was identified, how would that identification be communicated to the (new) NAS? > There is an odd statement in Section 11.12: > > There are man-in-the-middle attacks associated with the use of any > EAP method within a tunneled protocol such as PEAP, or within a > sequence of EAP methods followed by each other. > > [BA] Since sequences are prohibited in [RFC3748], some mention of that > prohibition is probably appropriate. Otherwise one might read the > paragraph as implying that EAP SIM could be used as part of a sequence. Is this text a part of some now historic note? I would assume that since RFC 3748 prohibits sequences and tunneling protocols with binding support exist, this is less of an issue. Or should the note be specific to PEAPv1 which did have that problem? > I think there is an issue with the IANA considerations > section. > > An IANA registry is requested for the Subtype and Attribute > Type number, allocated using "specification required". No > review mechanism is specified, yet it is indicated that the > same protocol numbers should be assigned to EAP AKA and EAP > SIM. It is not clear how this requirement is to be enforced, > given the allocation policy. The authors may wish to rethink this. I'm not quite sure what the specific problem is, but would Expert Review address this, as well as remove concern for exhausting attribute space? --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Nov 22 08:51:08 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 IAA29555 for ; Mon, 22 Nov 2004 08:51:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 050141FD54; Mon, 22 Nov 2004 08:51:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 810711FCBA; Mon, 22 Nov 2004 08:51:04 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5CDDC1FCBA for ; Mon, 22 Nov 2004 08:50:31 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 8AE261FC7A for ; Mon, 22 Nov 2004 08:50:29 -0500 (EST) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 4BA3889890; Mon, 22 Nov 2004 15:50:28 +0200 (EET) Message-ID: <41A1EE2E.8010209@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, "'henry.haverinen@nokia.com'" Subject: Re: [eap] RFC 3748 Review of EAP SIM 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: Mon, 22 Nov 2004 15:48:30 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > I think there is an issue with the IANA considerations > section. > > An IANA registry is requested for the Subtype and Attribute > Type number, allocated using "specification required". No > review mechanism is specified, yet it is indicated that the > same protocol numbers should be assigned to EAP AKA and EAP > SIM. It is not clear how this requirement is to be enforced, > given the allocation policy. The authors may wish to rethink this. Now I think I understand what your problem was. Would it help if the document(s) stated that ONE registry of parameters is established at IANA? --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Nov 22 09:15:09 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 JAA01471 for ; Mon, 22 Nov 2004 09:15:08 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4D1351FC7A; Mon, 22 Nov 2004 09:15:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1E7271FCBA; Mon, 22 Nov 2004 09:15:04 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C6A241FCBA for ; Mon, 22 Nov 2004 09:14:39 -0500 (EST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mail.frascone.com (Postfix) with ESMTP id 847331FC7A for ; Mon, 22 Nov 2004 09:14:36 -0500 (EST) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAMEEUS28247; Mon, 22 Nov 2004 16:14:32 +0200 (EET) X-Scanned: Mon, 22 Nov 2004 16:09:38 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id iAME9cAp017615; Mon, 22 Nov 2004 16:09:38 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00ih6unW; Mon, 22 Nov 2004 16:09:36 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAME9ZS17958; Mon, 22 Nov 2004 16:09:35 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 22 Nov 2004 16:08:04 +0200 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 22 Nov 2004 16:08:05 +0200 Received: from trebe051.NOE.Nokia.com ([172.22.124.60]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 22 Nov 2004 16:04:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 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] RFC 3748 Review of EAP SIM Message-ID: Thread-Topic: [eap] RFC 3748 Review of EAP SIM Thread-Index: AcTQa43iS2tDE0RSSZuENeKnpuFb8wABV6uQ From: To: , X-OriginalArrivalTime: 22 Nov 2004 14:04:38.0614 (UTC) FILETIME=[346B4F60:01C4D09C] 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, 22 Nov 2004 16:04:37 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Bernard, Many thanks for your review. Please see below. > 1. Does the method document its security properties > in sufficient manner, as required by Section 7.2 > of RFC 3748? >=20 > Yes. Documentation is provided. >=20 > However, there are some cases where clarity could be improved: >=20 > Section 1 >=20 > In any case, > if the GSM authentication mechanisms are considered to be=20 > sufficient > for use on the cellular networks, then EAP-SIM is expected to be > sufficiently secure for other networks. >=20 > [BA] What other networks are being referred to? If the claim is that > EAP SIM is sufficiently secure for use on WLAN, then you need to > reference draft-walker-ieee802-req-04.txt and include the additional > claims defined in that draft within the security claims section. For simplicity, I think we can delete this sentence from the = introduction. > Section 3 >=20 > Triplets may be stored in the EAP server for use at a later > time, but triplets may not be reused, except in some error=20 > cases that > are specified in Section 9.9 >=20 > [BA] Don't you mean MUST NOT be reused? Yes, we'll change this to "...triplets MUST NOT be reused, except..." >=20 > Section 11.7 >=20 > Because EAP-SIM is not a password protocol, it is not vulnerable to > dictionary attacks. (The pre-shared symmetric secret stored on the > SIM card shall not be a weak password.) >=20 > [BA] perhaps better to say "is not a passphrase, or derived from a > passphrase." >=20 OK. The new text would be "The pre-shared symmetric secret stored on the SIM card is not a passphrase, or derived from a passphrase." > Because this attack requires the attacker to build a rogue GSM base > station (or at least eavesdrop the GSM traffic), the cost of the > attack is not negligible; it is the same cost as usually in GSM. >=20 > [BA] Building a rogue GSM basestation and eavesdropping on GSM traffic > will have different costs. So "same cost as usually in GSM" > is not specific. I'd delete this phrase. >=20 OK. > However, due to several weaknesses in the GSM encryption=20 > algorithms, > the effective key strength of the Kc keys is much less than the > expected 64 bits (no more than 40 bits if the A5/1 GSM encryption > algorithm is used; as documented in [Barkan et al. 2003],=20 > an active > attacker can force the peer to use the weaker A5/2=20 > algorithm that can > be broken in less than a second). >=20 > Because the A5 encryption algorithm is not used in EAP-SIM, and > because EAP-SIM does not expose any values calculated from=20 > individual > Kc keys, it should be noted that these attacks are not possible if > the SIM credentials used in EAP-SIM are not shared in GSM/GPRS. >=20 > [BA] My understanding is that sharing of a SIM between GSM/GPRS and > WLAN is likely to be quite popular due to the convenience factor. > Given the security implications, do the authors wish to make a > recommendation relating to this scenario (e.g. sharing is NOT > RECOMMENDED). The draft spells out the consequences of sharing, as they are at the = time of writing. As Jari already commented, new improvements are being = speficied=20 at 3GPP. This is merely an EAP method protocol specification, not a system = specification for the whole operator system. So I don't believe this document should = make=20 recommendations about the SIM credentials reuse. Ultimately, this = decisions belongs=20 to the operator's security responsibles, who can properly measure the = "convenience"=20 or cost versus the consequences of sharing, especially since=20 the scenario may depend on the operator's GSM/GPRS implementation. > [Optional, at least for now: does it conform to EAP > keying framework?] >=20 > I believe that it does. One issue that may arise is the lack=20 > of an EAP > Server identity. This could have implications for handoff=20 > mechanisms that > require a NAS to fetch a key from the server, since the=20 > server identity is > not authenticated. OK -- I believe we cannot do anything about this right now, especially as the keying issues are work in progress, but we may need to reconsider = this later. > 3b. Does the method comply with sequence usage as defined > in Section 2.1 of RFC 3748? >=20 > There is an odd statement in Section 11.12: >=20 > There are man-in-the-middle attacks associated with the use of any > EAP method within a tunneled protocol such as PEAP, or within a > sequence of EAP methods followed by each other. >=20 > [BA] Since sequences are prohibited in [RFC3748], some mention of that > prohibition is probably appropriate. Otherwise one might read the > paragraph as implying that EAP SIM could be used as part of a=20 > sequence. Thanks for spotting this. The text is quite old, written before the = sequence=20 and tunneling issues were fully resolved in RFC 3748. I think we should = remove=20 the remark about sequences, but keep this paragraph for the tunneling. How about this revised text: There are man-in-the-middle attacks associated with the use of any=20 EAP method within a tunneled protocol such as PEAP. This = specification=20 does not address these attacks. If EAP-SIM is used with a tunneling=20 protocol, there should be cryptographic binding provided between the = protocol=20 and EAP-SIM to prevent man-in-the-middle attacks through rogue=20 authenticators being able to setup one-way authenticated tunnels. The = EAP-SIM Master Session Key MAY be used to provide the cryptographic = binding.=20 However the mechanism how the binding is provided depends on the=20 tunneling protocol and is beyond the scope of this=20 document. > I think there is an issue with the IANA considerations > section. >=20 > An IANA registry is requested for the Subtype and Attribute > Type number, allocated using "specification required". No > review mechanism is specified, yet it is indicated that the > same protocol numbers should be assigned to EAP AKA and EAP > SIM. It is not clear how this requirement is to be enforced, > given the allocation policy. The authors may wish to rethink this. Maybe we should request a common register for EAP-SIM and EAP-AKA protocol values. That would ensure that numbers are non-overlapping. Best regards, Henry _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Nov 22 10:03:09 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 KAA04846 for ; Mon, 22 Nov 2004 10:03:08 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 88A841FCBA; Mon, 22 Nov 2004 10:03:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A53C21FD70; Mon, 22 Nov 2004 10:03:03 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 97BF11FD70 for ; Mon, 22 Nov 2004 10:02:02 -0500 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by mail.frascone.com (Postfix) with ESMTP id E6FDC1FCBA for ; Mon, 22 Nov 2004 10:02:00 -0500 (EST) Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.42) id 1CWFhX-000JrH-JS; Mon, 22 Nov 2004 10:01:59 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id iAMF1wL23607; Mon, 22 Nov 2004 07:01:58 -0800 From: Bernard Aboba To: Jari Arkko Cc: eap@frascone.com, "'henry.haverinen@nokia.com'" Subject: Re: [eap] RFC 3748 Review of EAP SIM In-Reply-To: <41A1E605.4000909@piuha.net> Message-ID: References: <41A1E605.4000909@piuha.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba 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, 22 Nov 2004 07:01:57 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > > [BA] What other networks are being referred to? If the claim is that > > EAP SIM is sufficiently secure for use on WLAN, then you need to > > reference draft-walker-ieee802-req-04.txt and include the additional > > claims defined in that draft within the security claims section. > > Information on compliance to draft-walker might indeed be > useful. OTOH, we will probably never have methods document > their compliance to all possible usage scenarios. From the > looks of it, EAP SIM fulfills the draft-walker requirements, > but I wouldn't necessarily *require* the draft to be changed > unless the authors have some text ready for this. But the > document would benefit from listing those claims too. I just was asking about whether a claim was being made. If not, then that sentence can be deleted. > > [BA] perhaps better to say "is not a passphrase, or derived from a > > passphrase." > > Do you mean in addition to not being a weak password, or as a > replacement of the text? I meant as a replacement. The term "weak password" is somewhat ill defined -- but Ki is not a passphrase at all, so stating that might make it clearer. > Yes, or reformulate. I guess the point was that the cost of GSM > components may be a bit higher than some other similar technology > (e.g. WLAN AP). But you certainly don't need a full network. So > "same cost" is not very well defined. Yes. > Recommendation against sharing might be wise, but then again > it might not be. One specific issue is that 3GPP is addressing > the A5/2 problem as well as other things that caused the Barkan > et al problem, and when those techniques are in use (I believe > some early parts of those techniques are here soon) then sharing might > again be OK. So given the fluid situation I'd rather not recommend > anything. Perhaps the document should have some statement about > the impact of 3GPP developments into this problem, however. That would be good. > > I believe that it does. One issue that may arise is the lack of an EAP > > Server identity. This could have implications for handoff mechanisms that > > require a NAS to fetch a key from the server, since the server identity is > > not authenticated. > > Hmm... we may not have explored the handoff design far enough to > say for sure, but its not immediately obvious to me that the > server identity helps here. There's certainly a key which is > shared between the server and the client. And key identifiers, > if the eap keying framework defines them. Plus even if the > server was identified, how would that identification be > communicated to the (new) NAS? I mention this because of the importance of authenticated peer and server names in several of the 802.11r proposals. The authenticated peer name is utilized as the identity in some of the proposals, so that EAP methods which don't include this might not function. Luckily, I think most methods have this (it's a SHOULD in RFC 3748). What was somewhat surprising to me is that there was also talk about a message sent from the peer to the new NAS, requesting that a key be provisioned, by name. The new NAS might have more than one RADIUS server, which might include the RADIUS server used by the old NAS, on which key state (EMSK) still resides. But that might not be the primary RADIUS server. So in that message, the peer may need to include the server name, so that the new NAS can fetch the key from it. This would impact the performance of methods that do not include an authenticated server name. I believe quite a few methods do not do this, including EAP SIM, AKA and possibly EAP-TLS PSK mode. For that reason, I'm not sure this kind of "key fetching" is a good idea, and it's not supported in Diameter EAP. > > [BA] Since sequences are prohibited in [RFC3748], some mention of that > > prohibition is probably appropriate. Otherwise one might read the > > paragraph as implying that EAP SIM could be used as part of a sequence. > > Is this text a part of some now historic note? I would assume that > since RFC 3748 prohibits sequences and tunneling protocols with > binding support exist, this is less of an issue. Or should the > note be specific to PEAPv1 which did have that problem? The man-in-the-middle part is ok as is; I was only referring to sequences. I think that part is probably historic. > > review mechanism is specified, yet it is indicated that the > > same protocol numbers should be assigned to EAP AKA and EAP > > SIM. It is not clear how this requirement is to be enforced, > > given the allocation policy. The authors may wish to rethink this. > > I'm not quite sure what the specific problem is, but would > Expert Review address this, as well as remove concern for > exhausting attribute space? Yes, Expert Review would address this, since the expert presumably could ensure that the allocation was consistent with EAP AKA. However, it also could be addressed by creating a single registry for both EAP AKA and SIM, so that inconsistency would be impossible. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Nov 22 10:04:07 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 KAA04976 for ; Mon, 22 Nov 2004 10:04:06 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EAD7D1FDF0; Mon, 22 Nov 2004 10:04:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6D0E81FDD8; Mon, 22 Nov 2004 10:04:03 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9165F1FDDD for ; Mon, 22 Nov 2004 10:03:28 -0500 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by mail.frascone.com (Postfix) with ESMTP id 165F21FDD8 for ; Mon, 22 Nov 2004 10:03:26 -0500 (EST) Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.42) id 1CWFiw-000Kgg-8b; Mon, 22 Nov 2004 10:03:26 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id iAMF3Ou23659; Mon, 22 Nov 2004 07:03:25 -0800 From: Bernard Aboba To: Jari Arkko Cc: eap@frascone.com, "'henry.haverinen@nokia.com'" Subject: Re: [eap] RFC 3748 Review of EAP SIM In-Reply-To: <41A1EE2E.8010209@piuha.net> Message-ID: References: <41A1EE2E.8010209@piuha.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba 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, 22 Nov 2004 07:03:24 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > Now I think I understand what your problem was. Would > it help if the document(s) stated that ONE registry of > parameters is established at IANA? Yes. Presumably that registry would only be established and initial values listed in one of the drafts; the other could state "no registries or parameter allocation required". You'd save some time in IANA review, too ;) _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Nov 22 10:07:08 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 KAA05469 for ; Mon, 22 Nov 2004 10:07:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A1CA31FDD8; Mon, 22 Nov 2004 10:07:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DE9CD1FDDD; Mon, 22 Nov 2004 10:07:03 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AFC9B1FDDD for ; Mon, 22 Nov 2004 10:06:30 -0500 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by mail.frascone.com (Postfix) with ESMTP id 373C51FDD8 for ; Mon, 22 Nov 2004 10:06:29 -0500 (EST) Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.42) id 1CWFls-000Mqa-HB; Mon, 22 Nov 2004 10:06:28 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id iAMF6RV23832; Mon, 22 Nov 2004 07:06:27 -0800 From: Bernard Aboba To: henry.haverinen@nokia.com Cc: eap@frascone.com Subject: RE: [eap] RFC 3748 Review of EAP SIM In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba 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, 22 Nov 2004 07:06:27 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > For simplicity, I think we can delete this sentence from the introduction. That's what I'd recommend. > OK. The new text would be "The pre-shared symmetric secret stored on > the SIM card is not a passphrase, or derived from a passphrase." Great. > The draft spells out the consequences of sharing, as they are at the time > of writing. As Jari already commented, new improvements are being speficied > at 3GPP. OK. You might reference those developments. > OK -- I believe we cannot do anything about this right now, especially > as the keying issues are work in progress, but we may need to reconsider > this later. It's entirely speculative since 802.11r is probably 24 months away at least. But it's something to keep an eye on (and document in the keying draft). > How about this revised text: > > There are man-in-the-middle attacks associated with the use of any > EAP method within a tunneled protocol such as PEAP. This specification > does not address these attacks. If EAP-SIM is used with a tunneling > protocol, there should be cryptographic binding provided between the protocol > and EAP-SIM to prevent man-in-the-middle attacks through rogue > authenticators being able to setup one-way authenticated tunnels. The > EAP-SIM Master Session Key MAY be used to provide the cryptographic binding. > However the mechanism how the binding is provided depends on the > tunneling protocol and is beyond the scope of this > document. That's fine. You might include a reference to the PEAP specification that included the vulnerability (-02 I believe). > Maybe we should request a common register for EAP-SIM and EAP-AKA > protocol values. That would ensure that numbers are non-overlapping. Yes, that's what I'd recommend. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Nov 22 10:49:09 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 KAA10236 for ; Mon, 22 Nov 2004 10:49:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6E6D01FCBA; Mon, 22 Nov 2004 10:49:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8E59F1FCD8; Mon, 22 Nov 2004 10:49:03 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8213D1FCD8 for ; Mon, 22 Nov 2004 10:48:20 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id AB2231FCBA for ; Mon, 22 Nov 2004 10:48:16 -0500 (EST) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id CFBCE89890; Mon, 22 Nov 2004 17:48:14 +0200 (EET) Message-ID: <41A209C9.2090907@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, "'henry.haverinen@nokia.com'" Subject: How to design fast handoffs (Was: Re: [eap] RFC 3748 Review of EAP SIM) References: <41A1E605.4000909@piuha.net> 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: Mon, 22 Nov 2004 17:46:17 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Bernard Aboba wrote: >>>I believe that it does. One issue that may arise is the lack of an EAP >>>Server identity. This could have implications for handoff mechanisms that >>>require a NAS to fetch a key from the server, since the server identity is >>>not authenticated. >> >>Hmm... we may not have explored the handoff design far enough to >>say for sure, but its not immediately obvious to me that the >>server identity helps here. There's certainly a key which is >>shared between the server and the client. And key identifiers, >>if the eap keying framework defines them. Plus even if the >>server was identified, how would that identification be >>communicated to the (new) NAS? > > I mention this because of the importance of authenticated peer and server > names in several of the 802.11r proposals. The authenticated peer name is > utilized as the identity in some of the proposals, so that EAP methods > which don't include this might not function. Luckily, I think most > methods have this (it's a SHOULD in RFC 3748). > > What was somewhat surprising to me is that there was also talk about a > message sent from the peer to the new NAS, requesting that a key be > provisioned, by name. Would this be a "key name" (as defined in eap-keying), the identity of the AAA server in some AAA level representation (e.g. Destination-Host AVP), or the identity that the peer saw for the server when it initially authenticated with it? Note that all these name spaces may be separate, and might not be possible for the client to discover the Destination-Host AVP or for the NAS to use either the key name or the method-internal server name for any purpose. > The new NAS might have more than one RADIUS server, which might > include the RADIUS server used by the old NAS, on which key state (EMSK) > still resides. But that might not be the primary RADIUS server. So in > that message, the peer may need to include the server name, so that the > new NAS can fetch the key from it. So the problem is about routing to the right AAA node? I don't think the EAP server name guarantees that. What if the same cert and key pair is shared between the primary and backup servers? One working solution would be for the EAP server to pass its "AAA address" via EAP to the client, but this feels like a hack at least on initial look. Alternatively, the old NAS could hand the AAA route or destination it used to the client, and the client could hand it to the new NAS. > For that reason, I'm > not sure this kind of "key fetching" is a good idea, and it's not > supported in Diameter EAP. Agreed. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Nov 22 11:23:08 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 LAA13327 for ; Mon, 22 Nov 2004 11:23:08 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DFEF21FCBA; Mon, 22 Nov 2004 11:23:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2776A1FCD8; Mon, 22 Nov 2004 11:23:04 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3B9F71FD70 for ; Mon, 22 Nov 2004 11:22:54 -0500 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by mail.frascone.com (Postfix) with ESMTP id 946FE1FCD8 for ; Mon, 22 Nov 2004 11:22:52 -0500 (EST) Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.42) id 1CWGxn-000KWc-Ck; Mon, 22 Nov 2004 11:22:51 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id iAMGMnb28912; Mon, 22 Nov 2004 08:22:49 -0800 From: Bernard Aboba To: Jari Arkko Cc: eap@frascone.com, "'henry.haverinen@nokia.com'" In-Reply-To: <41A209C9.2090907@piuha.net> Message-ID: References: <41A1E605.4000909@piuha.net> <41A209C9.2090907@piuha.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: How to design fast handoffs 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, 22 Nov 2004 08:22:49 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > Would this be a "key name" (as defined in eap-keying), the identity > of the AAA server in some AAA level representation (e.g. > Destination-Host AVP), or the identity that the peer saw for the > server when it initially authenticated with it? Note that all these > name spaces may be separate, and might not be possible for the > client to discover the Destination-Host AVP or for the NAS to > use either the key name or the method-internal server name for > any purpose. The Key-Name is needed so that the NAS knows what to ask for. For this purpose the EAP Session-Id should be sufficient. The other info that is required is which AAA server to send the request to. I think this needs to be an FQDN resolvable to an IP address, or an IP address. As you note, even in protocols that provide an authenticated EAP server name, this might not be fulfilled. For example, multiple AAA servers can use the same certificate ("aaa.example.com"), so that the altSubjectName in the server certificate might not be specific enough. > So the problem is about routing to the right AAA node? I don't think > the EAP server name guarantees that. Right. I don't think it does. > What if the same cert and key > pair is shared between the primary and backup servers? That's a common practice, and I think it will break this scheme, even for protocols that provide an authenticated EAP server name. > One working solution would be for the EAP server to pass its > "AAA address" via EAP to the client, but this feels like a hack > at least on initial look. Alternatively, the old NAS could > hand the AAA route or destination it used to the client, and > the client could hand it to the new NAS. > > > For that reason, I'm > > not sure this kind of "key fetching" is a good idea, and it's not > > supported in Diameter EAP. > > Agreed. This is an example of something that needs to be discussed in the EAP Keying document, to make sure people are aware of the "gotchas". _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Nov 22 11:37:08 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 LAA15047 for ; Mon, 22 Nov 2004 11:37:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 478E61FCBA; Mon, 22 Nov 2004 11:37:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 56FBD1FCD8; Mon, 22 Nov 2004 11:37:04 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 971E01FCD8 for ; Mon, 22 Nov 2004 11:36:28 -0500 (EST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mail.frascone.com (Postfix) with ESMTP id 809911FCBA for ; Mon, 22 Nov 2004 11:36:25 -0500 (EST) Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 22 Nov 2004 08:36:33 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id iAMGaKVx025419; Mon, 22 Nov 2004 08:36:21 -0800 (PST) Received: from jsaloweyw2k01 ([10.82.216.241]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 22 Nov 2004 08:38:17 -0800 From: "Joseph Salowey" To: "'Bernard Aboba'" , "'Jari Arkko'" Cc: , Subject: RE: [eap] RFC 3748 Review of EAP SIM MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: Thread-Index: AcTQpLOfVlVnallWTnyh+rGSWWAKlAAC1vNA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Message-ID: X-OriginalArrivalTime: 22 Nov 2004 16:38:17.0666 (UTC) FILETIME=[AB670220:01C4D0B1] 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, 22 Nov 2004 08:36:16 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit >>> I believe that it does. One issue that may arise is the lack of an >>> EAP Server identity. This could have implications for handoff >>> mechanisms that require a NAS to fetch a key from the server, since >>> the server identity is not authenticated. >> >> Hmm... we may not have explored the handoff design far enough to say >> for sure, but its not immediately obvious to me that the server >> identity helps here. There's certainly a key which is shared between >> the server and the client. And key identifiers, if the eap keying >> framework defines them. Plus even if the server was identified, how >> would that identification be communicated to the (new) NAS? > > I mention this because of the importance of authenticated > peer and server names in several of the 802.11r proposals. > The authenticated peer name is utilized as the identity in > some of the proposals, so that EAP methods which don't > include this might not function. Luckily, I think most > methods have this (it's a SHOULD in RFC 3748). > > What was somewhat surprising to me is that there was also > talk about a message sent from the peer to the new NAS, > requesting that a key be provisioned, by name. > > The new NAS might have more than one RADIUS server, which > might include the RADIUS server used by the old NAS, on which > key state (EMSK) still resides. But that might not be the > primary RADIUS server. So in that message, the peer may need > to include the server name, so that the new NAS can fetch the > key from it. > > This would impact the performance of methods that do not > include an authenticated server name. I believe quite a few > methods do not do this, including EAP SIM, AKA and possibly > EAP-TLS PSK mode. For that reason, I'm not sure this kind of > "key fetching" is a good idea, and it's not supported in Diameter EAP. > [Joe] This sounds like a problem with an 802.11r implementation/specification to me, the information on how to perform roaming should be part of 802.11r, not EAP. The AuC is authenticated. >>> [BA] Since sequences are prohibited in [RFC3748], some mention of >>> that prohibition is probably appropriate. Otherwise one might read >>> the paragraph as implying that EAP SIM could be used as part of a >>> sequence. >> >> Is this text a part of some now historic note? I would assume that >> since RFC 3748 prohibits sequences and tunneling protocols with >> binding support exist, this is less of an issue. Or should the note >> be specific to PEAPv1 which did have that problem? > > The man-in-the-middle part is ok as is; I was only referring > to sequences. I think that part is probably historic. > [Joe] We can just remove the text referring to the sequence. >>> review mechanism is specified, yet it is indicated that the same >>> protocol numbers should be assigned to EAP AKA and EAP SIM. It is >>> not clear how this requirement is to be enforced, given the >>> allocation policy. The authors may wish to rethink this. >> >> I'm not quite sure what the specific problem is, but would Expert >> Review address this, as well as remove concern for exhausting >> attribute space? > > Yes, Expert Review would address this, since the expert > presumably could ensure that the allocation was consistent > with EAP AKA. However, it also could be addressed by > creating a single registry for both EAP AKA and SIM, so that > inconsistency would be impossible. [Joe] I think that would be good. > _______________________________________________ > 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 cpttlikzsfsgb@charter-stl.com Mon Nov 22 14:41:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07097; Mon, 22 Nov 2004 14:41:24 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWK7M-0000X7-0E; Mon, 22 Nov 2004 14:45:03 -0500 Received: from commons10k1.mo24.107.37.164.charter-stl.com ([24.107.37.164]) by mx2.foretec.com with smtp (Exim 4.24) id 1CWK3l-0005gR-Vz; Mon, 22 Nov 2004 14:41:15 -0500 Received: from mx2.foretec.com by commons10k1.mo24.107.37.164.charter-stl.com with ESMTP id hrfkaex; Mon, 22 Nov 2004 12:28:42 -0600 Received: from 59.133.48.20 by commons10k1.mo24.107.37.164.charter-stl.com with HTTP; Mon, 22 Nov 2004 12:27:58 -0600 Message-ID: <1645102997820499.r9FPVVf@NGYFLRDZ> Content-Transfer-Encoding: 7bit Subject: Re: mug got scratched . Content-Type: text/plain; charset=windows-1258; From: "Kenton Calvert" To: Grove Diffserv-interest Mime-Version: 1.0 Date: Mon, 22 Nov 2004 14:22:42 -0400 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Did you know you can get pre-apprToved mort gage loan even with ba d crediEt? Use the link below and we will apprEove you in 24 hours. No need to worry. The r ates are 3-5 points http://www.nlcomp.com/ Kenton Calvert -- us any soapy committal, delirium arrogant. algebraic - brice, pulp repugnant - on bamboo the fireplace steuben brouhaha - in bimetallism - philanthropy crook hague in of diminish From blat87mastic@gozer.com Tue Nov 23 04:10:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18449; Tue, 23 Nov 2004 04:10:23 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWWkT-00088C-Oa; Tue, 23 Nov 2004 04:14:11 -0500 Received: from [222.121.45.28] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1CWWgo-0004wv-9m; Tue, 23 Nov 2004 04:10:23 -0500 Received: from mail.lmco.com (222.121.45.28) by 222.121.45.28 (domingov.2) with SMTP id <57012o99b> (Authid: 4961); Tue, 23 Nov 2004 07:11:40 -0200 X-Message-Info: 8333898t Reply-To: "Manuel Kelly.Lai" From: "Manuel Kelly.Lai" To: ldap-dir@ietf.org Cc: l2vpn-web-archive@ietf.org, iab-wireless-workshop@ietf.org, seamoby@ietf.org, bpana@ietf.org, owner-ietf-outbound@ietf.org, entmib-request@ietf.org, xmldsig-archive@ietf.org, rmt-request@ietf.org, simple@ietf.org, eap-archive@ietf.org, r-wg-admin@ietf.org Subject: Approved: $635197 Date: Tue, 23 Nov 2004 12:08:40 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--028356380135886830" Message-Id: X-Spam-Score: 5.6 (+++++) X-Spam-Flag: YES X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab ----028356380135886830 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7Bit Dear Applicant, Your application was processed and approved. You are eligible for $ 400,000 with a 2.1 % rate. Please verify your information here: http://quoteyourrate.com/?partid=aaks9 We look forward to hearing from you. Manuel Kelly.Lai, Account Manager Bell Marketing 4206 Central Avenue Columbus, OH 43085 not interested -> http://quoteyourrate.com/st.html ----028356380135886830-- From eap-admin@frascone.com Tue Nov 23 07:15:10 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02445 for ; Tue, 23 Nov 2004 07:15:09 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DE4541FC64; Tue, 23 Nov 2004 07:15:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2FE071FD3D; Tue, 23 Nov 2004 07:15:04 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 49A671FD3D for ; Tue, 23 Nov 2004 07:14:50 -0500 (EST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mail.frascone.com (Postfix) with ESMTP id 530CD1FC64 for ; Tue, 23 Nov 2004 07:14:47 -0500 (EST) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iANCERS09065; Tue, 23 Nov 2004 14:14:44 +0200 (EET) X-Scanned: Tue, 23 Nov 2004 14:10:51 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id iANCApGv030266; Tue, 23 Nov 2004 14:10:51 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00R5Huo7; Tue, 23 Nov 2004 14:10:50 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iANC7uS16632; Tue, 23 Nov 2004 14:07:56 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 23 Nov 2004 14:07:49 +0200 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 23 Nov 2004 14:07:50 +0200 Received: from trebe051.NOE.Nokia.com ([172.22.124.60]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 23 Nov 2004 14:06:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 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] RFC 3748 Review of EAP SIM Message-ID: Thread-Topic: [eap] RFC 3748 Review of EAP SIM Thread-Index: AcTQpZgz3sVM6j/uRaSPc1GDr8jcgwAA3lgw From: To: Cc: X-OriginalArrivalTime: 23 Nov 2004 12:06:26.0919 (UTC) FILETIME=[DBDA4770:01C4D154] 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, 23 Nov 2004 14:06:36 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable > > The draft spells out the consequences of sharing, as they=20 > are at the time > > of writing. As Jari already commented, new improvements are=20 > being speficied > > at 3GPP. >=20 > OK. You might reference those developments. The developments are described in several standardization submissions which are not complete proposals but meeting documents, so it is not easy to find good references. Maybe we could simply describe the current status as follows: At the time of writing this document, the 3rd Generation Partnership = Project=20 (3GPP) has started to work on fixes to these A5 vulnerabilities. One of = the=20 solution proposals discussed in 3GPP is integrity protected A5 version=20 negotiation, which would require the base station to prove knowledge of = the Kc key=20 before the terminal sends any values calculated from the Kc to the = network.=20 Another proposal is so-called special RANDs, where some bits of the RAND = challenge=20 would be used for cryptographic separation by indicating the allowed use = of the=20 triplet, such as the allowed A5 algorithm in GSM or the fact that the = triplet is=20 intended for EAP-SIM. This is currently work in progress, and the = mechanisms have not=20 been selected yet. > That's fine. You might include a reference to the PEAP > specification that included the vulnerability (-02 I believe). OK, and I guess it would be appropriate to mention that later versions do not have this vulnerability. I have now made new revisions of the drafts with the changes that=20 we have agreed on. I believe all issues identified in the reviews have been corrected. Henry _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From yyjbtl@agt.net Tue Nov 23 09:30:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13910; Tue, 23 Nov 2004 09:30:33 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWbkM-0008M4-SQ; Tue, 23 Nov 2004 09:34:23 -0500 Received: from [200.255.233.116] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1CWbgf-0002ym-0M; Tue, 23 Nov 2004 09:30:33 -0500 X-Message-Info: Wh252bffy8y53+MYOw17eqTICH Received: from whw725.idt.net (44.10.60.136) by cjf20-tk6.idt.net with Microsoft SMTPSVC(5.0.2195.6824); Tue, 23 Nov 2004 15:26:49 +0100 Received: from Christiegn232z62f356jl (128.252.194.88) by azsquyddyaw3.idt.net (InterMail vM.5.01.06.05 969-641-557-512-872-127276582) with SMTP id <358256715.FHP79.zlzzd5794.idt.net@trenchantmeb440a11oqv0sii> for ; Tue, 23 Nov 2004 17:21:49 +0300 Message-ID: <8776hrk50ba1877$21142955$jlj14wxy5@Christieedj148zgn47u7uef> From: "Music and Movies Online" To: Subject: Unlimited MP3's -aqa 312 aay Date: Tue, 23 Nov 2004 11:24:49 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--" X-Spam-Score: 29.5 (+++++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d ---- Content-Type: text/html; Content-Transfer-Encoding: 7Bit Hello Experience & Enjoy the Digital revolution. We at- %GPNAME -announces future of online entertainment. Download anything you could possibly want in 3 simple, fast, and easy steps- START DOWNLOADING NOW! This service is 100 percent safe, Secure and Legal http://www.rosewoodsearch.com/ref91.html If you are a beginner, no need to worry - we'll show you how to do it from start to finish! We've made it so easy, you'll be downloading anything you could possibly want This Service Comes With: Un limited · Music & MP3s · Movies · Games · Software · TV Shows · Song Lyrics · Audio Books More Bonuses: · DVD Copying Software · MP3 Burning Software · Anti-Virus Software · Game Copying Software · Pop-Up/Spyware/Adware Killer Software http://www.rosewoodsearch.com/ref91.html · Even More Benefits : · Latest FileSharing Software · In-Depth Visual Tutorials · Internet History Cleaner · Privacy Protection Software · Access to 90,000,000 Songs · Unlimited Technical Support · Stay Legal - Don't Get Sued Lifetime Membership is only $34.95! Check out to Join Now and Start Downloading in Minutes! http://www.rosewoodsearch.com/ref91.html Regards Christie Sales Manager %GPNAME http://www.rosewoodsearch.com/ref91.html To Discountinue-- http://bjmcadefghl.infolinetech.biz/go.php?dhibceglxyamzfjk -------------------- beneficent maltese obsessive sc sauce seminarian bridle trimer glassy bark sewage phenotype veneto analeptic penelope sketchpad bloop console corvus cornelius metric profess ascend caviness excise anastomosis cackle madam cushion bound baylor amity bursty homogeneity electra backlash specular contradictory amorphous concretion avoidance winemake abeyant holt henbane sedimentation carbondale sequester brunt upraise abet winery authentic ponchartrain rudy seward hague perilla anger kilohm other caruso bacon jerusalem deaden julius impost elisabeth tintype circumcircle basilar ambulatory bedim caress contrariety bramble damn cowpox elder massey trample milord degree mcgregor hamal batten domain blunt mathematician dynamism deluxe laconic demo referring austenite confident trivial bend moran booklet corpsman conn durward indolent manageable intensive midsection bangui district whit circumsphere anchorage attributive fallout binomial minutiae brainstorm scylla arabia crag abrogate spacesuit cilia seward courtney shoo campsite wardrobe turntable registrar collage thiamin defeat bulkhead cravat administrate divulge acrimonious clockwork shriek orville ingestion sicilian reid quell herculean robbins bologna downcast eratosthenes domenico specific afferent ambulant darwin trimer gerhardt neuroses ill precious infelicitous autocollimate marinate newton immature blockage roughshod indigestible nazarene exacter alienate blow refract firehouse emilio huge technology bakhtiari covert verona anticipatory bedraggle saloonkeep squibb toolsmith arty butterfly compatriot phycomycetes brasilia wolve suction hassle multiplicand rebellious stray cartwheel isotopic hurst kremlin wont marjorie predatory ca oneupmanship adamson synod crosslink chimeric permeable basis parsimony whiten boo peddle bungalow glamour ceramic chronology effloresce contend cotton stanchion measle inexhaustible ballerina compete turtleneck causal amatory gassy kernel parvenu watanabe finale congratulate swahili adjunct miracle stauffer contention levis mar cons tellate tim darrell conley deed shadow deregulatory avalanche clime deformation smack neuroanotomy checksummed gondola fundamental abrasion crane downfall cranny copernican empathy figurate preparative carlisle edition rococo swim roost drosophila declassify dewdrop pigroot vial arrack topic circulant snag enterprise chorale alum ------ From srzfcksd@yahoo.com Tue Nov 23 14:57:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14245; Tue, 23 Nov 2004 14:57:22 -0500 (EST) Received: from host29-122.pool80180.interbusiness.it ([80.180.122.29]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CWgqb-0001bL-1b; Tue, 23 Nov 2004 15:01:13 -0500 Received: from 188.24.120.102 by 80.180.122.29; Tue, 23 Nov 2004 20:48:51 +0100 Message-ID: From: "Alissa Forbes" Reply-To: "Alissa Forbes" To: dinaras@ietf.org Subject: Why Pay M0re? yjt7 Date: Tue, 23 Nov 2004 23:47:51 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--000859289343492535" X-Spam-Score: 1.1 (+) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ----000859289343492535 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit The L0west price of all med's is here. Vic0d|n - $3.5/pi|ls Va|ium - $1.33/pi|ls V|a-gra - $2.99/pi|ls Xa'nax - $1.33/pi|ls Cia-|is - $5.99/pi|ls and many m0reeee..... We are the bes't available nowadays http://www.quikrx.net/rx/?18 This is 1 -time mailing. N0-re m0val are re'qui-red c[30-70 ----000859289343492535-- From kdruycbmtnnbha@dsl-verizon.net Tue Nov 23 18:15:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18589; Tue, 23 Nov 2004 18:15:56 -0500 (EST) Received: from wbar15.tmp1-4-8-038-246.tmp1.dsl-verizon.net ([4.8.38.246]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CWjwf-0007B6-TM; Tue, 23 Nov 2004 18:19:52 -0500 Received: from relay.verizon.net by wbar15.tmp1-4-8-038-246.tmp1.dsl-verizon.net with tlkmvrki; Tue, 23 Nov 2004 16:03:05 -0600 Received: from 45.69.29.209 by relay.verizon.net with Microsoft SMTPSVC; Tue, 23 Nov 2004 16:02:12 -0600 Mime-Version: 1.0 To: Jocelyn Eap-archive Message-ID: <181456774176-wuxWXj@IDMHXR> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="WINDOWS-1258"; Subject: Re: painfully trying to remember From: "Gomez" Date: Tue, 23 Nov 2004 16:02:30 -0600 X-Spam-Score: 6.6 (++++++) X-Spam-Flag: YES X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit From: Gomez CC: Department 65 Date: Tue, 23 Nov 2004 16:03:05 -0600 Re: L o an a p proval -- Sir: We have reviewed you information and glad to inform you that you qualify for 4.8% mor tgage r ate under our company l e nding program. Please use this URL to enter final details and our manager will contact you ASAP. http://www.nlcomp.com/ We look forward to doing business with you. Best Regards CEO: Gomez From eap-admin@frascone.com Wed Nov 24 01:10:09 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 BAA18508 for ; Wed, 24 Nov 2004 01:10:08 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 09C201FC64; Wed, 24 Nov 2004 01:10:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 102E51FCB8; Wed, 24 Nov 2004 01:10:04 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EA6AC1FCB8 for ; Wed, 24 Nov 2004 01:09:52 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 291071FC64 for ; Wed, 24 Nov 2004 01:09:50 -0500 (EST) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 89D2489875 for ; Wed, 24 Nov 2004 08:09:48 +0200 (EET) Message-ID: <41A42534.1070706@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" References: 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) Subject: [eap] Fwd: Protocol Action: 'Diameter Extensible Authentication Protocol (EAP) Application' to Proposed Standard 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, 24 Nov 2004 08:07:48 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit The IESG wrote: > The IESG has approved the following document: > > - 'Diameter Extensible Authentication Protocol (EAP) Application ' > as a Proposed Standard > > This document is the product of the Authentication, Authorization and > Accounting Working Group. > > The IESG contact persons are Bert Wijnen and David Kessens. > > Technical Summary: > > The Extensible Authentication Protocol (EAP) provides a standard > mechanism for support of various authentication methods. This > document defines the Command-Codes and AVPs necessary to carry EAP > packets between a Network Access Server (NAS) and a back-end > authentication server. It therefore provides the same function > for Diameter as RFC 3579 does for RADIUS. > > Working Group Summary > > The document being advanced represents the culmination of a long > effort to standardize support for EAP within Diameter, including > key transport. One of the major obstacles that was overcome was > the development of a mechanism (using Diameter Redirect) to > transport keys without access by intermediaries. > > There is strong working group consensus relating to this document. > The document has been reviewed by participants in both AAA WG > and EAP WG, as well as by participants within IEEE 802, 3GPP, > and 3GPP2. > > Protocol Quality: > > This protocol document was originally part of the Diameter NASREQ > specification, but was split off into a separate specification in > order to improve clarity and allow EAP-specific security issues to > be addressed. Since the split, the clarity of the protocol as well > as the level of analysis in the security considerations section has > been greatly improved. > > Bert Wijnen has reviewed this document for the IESG. > > RFC-Editor note: > > In sect 4.1.5 fix incorrect notation on 3rd line > OLD: > contains the value ((Vendor-Id * 232) + Vendor-Type). > NEW: > contains the value ((Vendor-Id * 2^32) + Vendor-Type). _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 24 03:30:08 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 DAA27395 for ; Wed, 24 Nov 2004 03:30:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 138F41FC64; Wed, 24 Nov 2004 03:30:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 153251FCC6; Wed, 24 Nov 2004 03:30:04 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2A04C1FCC6 for ; Wed, 24 Nov 2004 03:29:58 -0500 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by mail.frascone.com (Postfix) with ESMTP id 8BFF11FC64 for ; Wed, 24 Nov 2004 03:29:56 -0500 (EST) Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.42) id 1CWsXD-0004sL-9X for eap@frascone.com; Wed, 24 Nov 2004 03:29:55 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id iAO8Trs27865 for ; Wed, 24 Nov 2004 00:29:54 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Completion of "pseudo WG last call" on draft-adrangi-eap-network-discovery-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: Wed, 24 Nov 2004 00:29:53 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) "Pseudo WG last call" has completed on draft-adrangi-eap-network-discovery-05.txt. Two issues were submitted (280, 281), one of which (281) has been rejected. IEEE 802.1 indicated that it might provide review comments, but so far nothing as been received. As soon as the remaining issue is resolved, publication as an Informational RFC can be requested. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 24 04:28:08 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 EAA02645 for ; Wed, 24 Nov 2004 04:28:08 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 044011FC64; Wed, 24 Nov 2004 04:28:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 065AD1FD49; Wed, 24 Nov 2004 04:28:03 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 199641FD49 for ; Wed, 24 Nov 2004 04:27:30 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 025A61FC64 for ; Wed, 24 Nov 2004 04:27:28 -0500 (EST) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id AF80689877 for ; Wed, 24 Nov 2004 11:27:26 +0200 (EET) Message-ID: <41A45387.5030202@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=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Fw: IEEE 802.11 Review Comments - IETF EAP Network Discovery and Selection Problem Statement 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, 24 Nov 2004 11:25:27 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 8bit Here's input from IEEE 802.11 and the WIEN SG regarding draft-ietf-eap-netsel-problem-02.txt: > From: Stuart J.Kerry, Chair IEEE 802.11 Working Group > To: Harald Alvestrand, IETF Chair, Bernard Aboba, IETF to IEEE 802 > liaison and EAP Working Group Co-Chair, Jari Arkko, EAP Working Group > Co-Chair > CC:Thomas Narten, Internet Area Director, Margaret Wasserman, Internet > Area Director > > Title: Review IETF EAP draft documents, November 2004 > > Purpose: Review of IETF draft-ietf-eap-netsel-problem-02.txt > > Dear Harald, > > As mentioned in our earlier liaison, the IEEE 802.11 Wireless > InterWorking with external Networks Study Group (WIEN SG) is > investigating the changes needed to the IEEE 802.11 specification to > support interworking with external non-IEEE 802.11 networks. > > This letter provides comments regarding the document "Network Discovery > and Selection Problem" (draft-ietf-eap-netsel-problem-02.txt), for IETF > consideration. > > - The draft provides a comprehensive overview of the network discovery > and selection problem observed in today's IEEE 802.11 wireless LAN > networks, from multiple perspectives. > > - As noted in the draft, the topics of network discovery and selection > are being discussed in many standards and industry organizations. > Discussion of the problem in this IETF draft is a very useful statement > of the problem and also provides a common language for discussion of > both the problem and potential solutions within the various organizations. > > - IEEE 802.11 intends to investigate network identity selection > solutions that occur prior to association and the subsequent use of EAP. > Solutions may include the definitions of mechanisms to enable Layer 2 > delivery of information relevant to network selection. > > - Work may address changes and enhancements to the beacon messages. > > The draft includes references, which describe the pragmatic limitations > of including large amounts of data in the beacon and probe response > messages. > > - We expect to work closely with the IETF as network discovery solutions > are identified and studied, as the information to be disseminated, and > the method of supply of this information to Access Points may need to be > defined in the IETF. > > Delivery of the information to the end stations at Layer 2 may impact > the IEEE 802.11 protocol. > > We look forward to continued dialogue on network discovery and selection > topics. > > For IETF reference, ANSI/IEEE Std 802.11Ò-1999 (2003 Reaffirmation) > edition as amended by IEEE Std 802.11g-2003,IEEE Std. 802.11h-2003, IEEE > Std. 802.11i-2004, IEEE Std. 802.11j-2004 is the current version of the > IEEE 802.11 Standard. > > Please contact Stuart J.Kerry, IEEE 802.11 Working Group Chair together > with Stephen McCann, IEEE 802.11 WIEN SG chair and Dorothy Stanley, IEEE > 802.11/IETF Liaison with any questions, and to discuss further IETF > follow-up. > > Best Regards, > > Stuart J. Kerry _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 24 07:53:10 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18617 for ; Wed, 24 Nov 2004 07:53:08 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4CD681FC64; Wed, 24 Nov 2004 07:53:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4CF391FD51; Wed, 24 Nov 2004 07:53:04 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E58491FD51 for ; Wed, 24 Nov 2004 07:52:12 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 83ED71FC64 for ; Wed, 24 Nov 2004 07:52:10 -0500 (EST) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 69D1589877; Wed, 24 Nov 2004 14:52:08 +0200 (EET) Message-ID: <41A48380.5050204@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: Giaretta Gerardo Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] minutes from IETF-61 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, 24 Nov 2004 14:50:08 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Here are the preliminary minutes from our meeting in Washington DC. If you spot something additional that should be included, let the chairs know. Thank you Gerardo for taking notes! --Jari Extensible Authentication Protocol WG (eap) IETF-61 Minutes, Wednesday, November 10, 2004 at 0900-1130 ========================================================== CHAIRS: Bernard Aboba Jari Arkko SCRIBE: Gerardo Giaretta 1. PRELIMINARIES, CHAIRS ------------------------ Presentations on the web: http://www.drizzle.com/~aboba/EAP/IETF61 Issues on the web: http://www.drizzle.com/~aboba/EAP/eapissues.html - Agenda Bashing - Documents Status RFC 3579 "EAP over RADIUS" published earlier RFC 3748 "2284bis" published earlier EAP state machine in RFC editor queue. Some comments -> back to the WGLC and then back to RFC editor. [Bernard]: We need a review and approve from others than authors [Hannes]: I'm not author and I approve. We implemented this state machine. [Bernard]: Did you find issues? [Hannes]: I'll let you know EAP Keying framework: discussion today EAP over Diameter (AAA WG - draft-ietf-aaa-eap-09.txt) approved by IESG Network Selection Problem (draft-ietf-eap-netsel-problem-02.txt): waiting input from IEEE WIEN next week Network Discovery Draft (draft-adrangi-eap-network-discovery-05.txt): to be sent to IESG NAI Update "RFC2486bis" [RADEXT WG]: when I-D submission re-opens will be submitted and sent to the IESG Methods documents 3 submitted for RFC publication (EAP-SIM, EAP-AKA, EAP-PSK) Many issues in EAP-SIM reviewed by Bernard Binding Problem definition: not updated since IETF-58 (abandoned) Other work: need review from the WG EAP usage in PANA EAP usage in MIP6 EAP usage in DHC [Hannes]: EAP in NSIS because of authorization issues. In NSIS WG we have a number of docs describing authentication and authorization issues and need comments [Bernard]: ISMS too [Glenn]: I have two questions about the directions of the WG. There is work that has nothing to do with authentication (netdisc). Moreover no standardization of EAP methods. 1) EAP for authorization and other usages. I think we should develop a flexible authentication and authorization protocol and include network selection and discovery. What do you think about this? Or would you continue to add stuff to EAP? [Bernard]: the scope of EAP is clear. Applicability statement and IANA considerations state the purposes of EAP [Glenn]: Which are the future policies? [Bernard]: to be described in future documents. Can you send an email question? [Glenn]: OK 2) Regarding EAP methods. People need guides from the IETF: IEEE for example. They did not standardize EAP methods. The 3 EAP methods mentioned in slides are about 3GPP [Jari]: Not for PSK [Glenn]: Are we going to standardize methods? [Bernard]: We have one method we need in standard track [Jari]: People can develop new methods and standard tracks. If there is interest in people and vendors we will standardize. [Glenn]: It's very difficult to publish standard as individual submission [Bernard]: We already developed the process for publication of EAP methods [Dorothy]: To clarify 802.11 prospective: 802.11 made the decision not to select an EAP method. There are only requirements for EAP methods in IEEE. 2. KEYING FRAMEWORK DISCUSSION, BERNARD ABOBA --------------------------------------------- See issue list page at http://www.drizzle.com/~aboba/EAP/eapissues.html Requirements from Rouss Housley Keying framework try to analyze the security of EAP system The requirements are a sort of charter for the document [Glenn]: I don't remember any WG consensus on Rouss requirements [Bernard]: We took these requirements as a challenge. So far we did not find any problems with these requirements. [Jari]: I agree with Glenn. We don't need to agree with Rouss' requirements if we think he is wrong [Glenn]: These requirements seem to drive many EAP method design and I think this is a problem. Could we have a WG document regarding these method-design principles? [Bernard]: EAP keying should do this [Glenn]: I don't think it is acceptable to base these principles on a presentation [Jari]: Let's discuss technical issues [Hannes]: One requirements states that an acceptable solution must authenticate all parties. We are not always authenticating all parties [Bernard]: the important thing is to be clear on limitations and state them 21 issues (7 editorial and 14 technical) Discussion on most important open issues: ISSUE 254: KEY LIFETIMES EAP does not negotiate the lifetime of exported keys EAP does not support re-key of exported keys without re-authentication Secure Association protocol may support re-key without re-authentication EAP itself is not managing the lifetimes but SA protocol is responsible for lifetimes [Jari]: Just a clarification: re-key does not extend the original lifetime. Moreover, if an exported key expired, everything derived from it dies. [Bernard] (from slides): TEKs usually expire on the peer and server after the session ends [Joe]: I think that this is a good suggestion. Maybe deleted is better than expired. [Paul]: Agreed that expired is a wrong word. [Hannes]: Is AAA-key stored on the local AAA server? [Bernard]: It says only about expiration not storing [Jari]: What about fast handoff? we use the same AAA-key? [Bernard]: Need more thoughts on that. We have to guarantee the AAA-key freshness [Paul]: Something about SA protocol: EAP method generates fresh keys but then it is the SA protocol that is responsible of these. [Joe]: (about slide 7) better EAP server and not AAA server [Bernard]: not sure. Let's discuss on the mailing list [Joe]: EMSK has a shorter lifetime than MSK [Bernard]: the issue is that applications do not know the lifetimes of AMSKs [Joe]: These are problems of applications and are not fixable by EAP [Jari]: In theory we could negotiate all lifetimes. In practice, there are limitations so I think the approach of Bernard is trying to use is the usage of the session lifetime to regulate all lifetimes [Joe]: Session timeout is very specific to AAA protocol. [Bernard]: The idea is that we have a general timeout that could be a session timeout or another but it is generated by AAA server [Jari]: We can't describe generally but we have to look at the protocols that are used, Diameter or RADIUS [Joe]: Disagree. There are things that are independent of that. [Jari]: (about slide 8) Is it a maximum TSK lifetime or a minimum? [Bernard]: Maybe this the minimum TSK lifetime ISSUE 262: KEY NAMING Text proposed in the mailing list Some methods do not have EAP server name and use the authenticator identity. Maybe there are some implicit requirements that derive from this text [Joe]: We should not have requirements on AAA server name [Hannes]: Key naming discussion is confusing. What means key naming? [Bernard]: The naming requirement derives from caching [Hannes]: Naming keys you generate state [Bernard]: It is needed to select exported keys [Hannes]: To select a state does not require strings or names [Bernard]: this is true but...(something lost) [Hannes]: Key naming has nothing to do with what you are talking about [Jari]: If you have a connection-oriented protocol you have state and you don't need key naming. But for caching you need. None is using key naming and existing systems use link-layer names. We could have potential requirements in the future and this is also why we are discussing name. Another question is which names we use. [Bernard]: (about slide 10) there are implicit methods requirements in this paragraph and we should be careful on this [Pasi]: we are not interested in naming keys but in naming state. I don't understand why we need to name keys but something else [Bernard]: we are naming sessions and not keys [Hannes]: short comment to Pasi. Half document talks about key naming and half about Security Association. Another issue MSK is never selected again, so it does not need to be named. [Bernard]: we need to name it for caching [Hannes]: it's the AAA-key not the MSK [Bernard]: Good point. We should make it clearer in the document ISSUE 267: PRF NEGOTIATION Bernard states the proposed resolution No comments ISSUE 275: AAA-KEY SHOULD BE DERIVED FROM AMSK Bernard states the proposed resolution [Jari]: there must be something in the KDF to have different keys for different APs [Joe]: there is the application data. The first purpose of the AMSK is not to have the EMSK around. We should discuss the requirements to understand if these keys must be different or not. [Hannes]: this key derivation can be used in some places and not in others. This is not clear in the document. I'd suggest to add usage cases. ISSUE 277: DRAFT ORGANIZATION Bernard states the proposed resolution [Jari]: Security analysis and not requirements [Hannes]: I'd like to see architectural issues pointed out, for example how EAP is used in IKEv2 and some IEE examples. For people that do not have IEEE background it's difficult [Bernard]: Agree. This is missing [Paul]: is the document a best practice? or a survey of architectures? [Joe]: I'd like to see what are the expectations for EAP methods and how the applications can use the keys exported [Madjid]: I just want to know (if it possible) in a generic way how keys are derived without IEEE or TLS details [Jari]: we are trying to describe a system. We'll try to describe how key derivation works: this part should be simpler. [Madjid]: It's hard to read and the key derivation is only in the appendix [Jari]: it's an organizational problem and we are trying to tackle. The purpose is to describe the security of the system [Jari]: We are open to different suggestions to reorganize the doc. ISSUE 278: LIFETIME OF KEYS INTERNAL TO EAP METHODS Bernard states the proposed resolution No comments ISSUE 279: SA PROTOCOL REQUIREMENTS Bernard states the proposed resolution No comments [Bernard]: the main challenge of the doc seems to be organizational 3. EAP STATE MACHINE, CHAIRS ---------------------------- [Jari]: Are there open issues? no comments 4. AUTHENTICATED SERVICE IDENTITIES, PASI ERONEN ------------------------------------------------- (slide 3) If D is compromised it can pretend to B This is because EAP does not have a concept of service or NAS identity Solution: the AAA server tells the client to which service it is sending the key It is not the same thing of channel binding: the difference is between "I believe" and "he claims" Method independent framework for service identifiers. This method independent blob can be carried in AVPs in EAP methods [Hannes]: Good document and useful [Jari]: Channel binding vs Authentication. Do people think this distinction is useful? [Pat]: This is an interesting problem. IEEE has a group dealing with fast handoff and this could be an issue because in this case the key is not obtained from the AAA server. [Someone]: If AAA server and X have trust relationship and X has a trust relationship with Y, is this framework needed? [Pasi]: Yes. With this framework we want to prevent that a problem (e.g. a node is compromised) in a part of the system spreads in the whole system. [Yoshi]: PANA is also specifying service parameters. I think we need to add to PANA this service parameters [Pasi]: we decided not to include this in the document and eventually specify in a separate document [Paul]: why not change the direction and the client sends the information to the AAA server and the AAA server confirms? For example for SSID this could be useful. [Pasi]: SSID is also carried by RADIUS 5. NETWORK SELECTION UPDATE, CHAIRS ----------------------------------- Network Selection Problem (draft-ietf-eap-netsel-problem-02.txt): waiting input from IEEE WIEN next week Network Discovery Draft (draft-adrangi-eap-network-discovery-05.txt): to be sent to IESG No comments 6. EAP PAX, T. CLANCY --------------------- Changes due to comments during last meeting Supports provisioning with a weak pre-shared key Supports key management with forward secrecy using Diffie-Hellman List of major changes from version 00: Address Crypto Concerns Protocol Implementation Issues support for HMAC-SHA1 and AES-CBC-MAC Description of the message flow both in no identity protection and identity protection cases Implementation using FreeRADIUS and XSupplicant Working on implementation for Windows XP supplicant Comparison between PAX implementation timings: PAX, EAP-TLS, PEAP-MSCHAPv2 [Hannes]: EAP-TLS is unfair as comparison, you should use EAP-PSK [Clancy]: We just used what it was implemented in FreeRADIUS [Joe]: regarding TLS timeline, have you ran tests with session resume? [Clancy]: without [Joe]: it could be useful to compare with EAP-TLS with session resume [Robert]: Considering the complexity of the code, for slower devices this EAP method could be very useful [Hannes]: Yes, it's good to think about performance and for example memory space [Jari]: How much interest is there? Who read the draft? -> 6 people [Bernard]: Are you requesting a standard track? [Clancy]: Yes [Chairs]: Who thinks we should do something like this? -> 7 yes, 0 no [Robert]: This is very leight EAP method. For example it could be useful in bridges [Bernard]: We should have a discussion and write something about that 7. EAP SMARTCARD, PASCAL URIEN ------------------------------ [draft-urien-eap-smartcard-type-00.txt] EAP methods working with smartcards may conflict with purely software methods Proposal: one EAP type (EAP-SC) for all smartcards The EAP-SC model: three layers 1. The EAP-SC handling layer receives and sends EAP packets, selects a Smart Card handler, and passes packets to the Smart Card handler 2. The EAP Smart Card Handler layer handles the interface to the smart card and any EAP Method specific functions 3. The Smart Card executes Authentication Method functions [Hannes], [Pasi]: EAP terminates in the smartcard itself. Why is it an issue? [Pascal]: You have a conflict because you may need software methods and smartcard methods for the same protocol [Pasi]: If you are solving a software problem on the client why do you need a new protocol? [Pascal]: There is a conflict from a software point of view [Jari]: I agree with Pasi and it seems to be other mechanisms to tackle this method selection. People have implemented without nothing on the wire. [Pascal]: IMO the authentication server always knows if smartcard is required or not [Jari]: Are you saying that there is a need of communication? [Pascal]: it's an issue for the client side that should not switch from a method to another [Joe]: I don't see the need. It seems an implementation side problem. [Pascal]: I don't agree [Hannes]: We have implemented EAP methods using smartcard and this was not needed. You really need to describe which is the problem you are trying to solve in order to understand [Pascal]: It's purely a practical issue [Pasi]: Smartcards are not so special to require a new EAP type code ---discussion cut---- [draft-urien-eap-smartcard-06.txt] New support of EAP-TLS EAP Smart Cards and EAP-TLS Security Claims [Hannes]: The distinction between user authentication and computer authentication is an identity issue [Hannes]: I don't think this topic (implementation in SC) is related to EAP WG and IETF in general [Pascal]: If these devices are useful for IETF we should specify [Glenn]: I read this draft and it seems an API specification and is not for IETF. The implementation of EAP methods in smartcards is strictly internal to smartcards _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From aboveground11culvert@scientech.com Wed Nov 24 16:13:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03129; Wed, 24 Nov 2004 16:13:20 -0500 (EST) Received: from adsl-66-143-178-218.dsl.austtx.swbell.net ([66.143.178.218]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CX4Vy-0006hh-3H; Wed, 24 Nov 2004 16:17:26 -0500 Received: from mail.habergroup.com (66.143.178.218) by 66.143.178.218 with Microsoft SMTP596(9.894.88.4); Wed, 24 Nov 2004 20:11:10 -0100 Received: from 66.143.178.218 (staminate[66.143.178.218]) by mail.habergroup.com (urvn634) with SMTP id <0893485p71d> (Authid: 963); Thu, 25 Nov 2004 01:04:10 +0400 Message-ID: Reply-To: "Beverlee Harry.Dean" From: "Beverlee Harry.Dean" To: meeting-planning@ietf.org Cc: ietf-languages@ietf.org, pr-wg@ietf.org, eap-archive@ietf.org, tsvwg-request@ietf.org, usic-admin@ietf.org, policy@ietf.org, vrrp@ietf.org, ietf@ietf.org, mailman-owner@ietf.org, sip-security@ietf.org Subject: Lo[a]n: $ 601850 Date: Wed, 24 Nov 2004 19:08:10 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--67996877112737347" X-Spam-Score: 3.4 (+++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab ----67996877112737347 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7Bit Dear Applicant, Your application was processed and approved. You are eligible for $ 400,000 with a 2.1 % rate. Please verify your information here: http://www.getmoremoney4u.biz/green/m79a We look forward to hearing from you. Beverlee Harry.Dean, Account Manager iNet Marketing 3432 Park Avenue New Haven, CT 06501 not interested -> http://www.getmoremoney4u.biz/green/stop.html ----67996877112737347-- From nrdhvwmektnk@attbi.com Wed Nov 24 22:20:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02813; Wed, 24 Nov 2004 22:20:37 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXAFT-0005zN-2N; Wed, 24 Nov 2004 22:24:48 -0500 Received: from c-66-177-89-219.se.client2.attbi.com ([66.177.89.219]) by mx2.foretec.com with smtp (Exim 4.24) id 1CXABR-0001qN-SC; Wed, 24 Nov 2004 22:20:38 -0500 Received: from mx2.foretec.com by c-66-177-89-219.se.client2.attbi.com with Microsoft SMTPSVC; Wed, 24 Nov 2004 20:08:13 -0600 Received: from gateway.attbi.com by c-66-177-89-219.se.client2.attbi.com with HTTP; Wed, 24 Nov 2004 20:07:46 -0600 Mime-Version: 1.0 To: "O. Wills" From: "Gary" Date: Wed, 24 Nov 2004 20:07:36 -0600 Message-ID: <83850470970675.4273883.gilolkgbm@haybliwrq.attbi.com> Content-Transfer-Encoding: 7bit Subject: Re: Announce Content-Type: text/plain; charset=iso-8859-1; X-Spam-Score: 3.5 (+++) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Someone has sent you a gift http://www.0megas.net/r/ndgs/pjqxvy.htm rem http://www.xonc.com/z .php ironwood no for any augusta enchantress antares modular streetcar to wally be Frunty communicant? motive Mjockey the us class I not any scribble at so carolyn fum our stupendous - the critic as corvette the complete From midscale9@epomail.com Wed Nov 24 22:36:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04772; Wed, 24 Nov 2004 22:36:52 -0500 (EST) Received: from tullahoma-24-158-183-123.midtn.chartertn.net ([24.158.183.123]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CXAVB-0006So-LA; Wed, 24 Nov 2004 22:41:02 -0500 Received: from sheik.kittymail.com[92.176.73.32]:49897 "EHLO syrinx.kittymail.com") by avas-mx76.kittymail.com with ESMTP id S181938AbUJINlX; Wed, 24 Nov 2004 23:32:30 -0400 Original-Recipient: rfc822; midscale9@epomail.com Date: Thu, 25 Nov 2004 01:36:30 -0200 Message-Id: <6789407368.i93ErrTw00005@valentinebullhead.biz> Date: Thu, 25 Nov 2004 00:28:30 -0300 From: "Nicolas Felton" To: diffserv-interest-admin@ietf.org Cc: dinaras@ietf.org, disman@ietf.org, eap-archive@ietf.org, entmib@ietf.org, entmib-request@ietf.org, geopriv-admin@ietf.org, idr@ietf.org, iesg@ietf.org, iesg-secretary@ietf.org, ietf-announce-request@ietf.org, ietf-proceedings@ietf.org, ietf-registrar@ietf.org, ietf-rsvp@ietf.org, ietf-web@ietf.org, ifmib@ietf.org X-Sender: midscale9@epomail.com X-Originating-Email: [midscale9@epomail.com] X-Originating-IP: [37.230.116.51] Subject: RE account# WM2563117 MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Message-flag: Authentic Sender, Hash: KcEzKwFo Content-Disposition: inline X-Spam-Score: 3.6 (+++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Hello,

We sent you an email a while ago, because you now qualify for a new mortgage.
You could get $300,000 for as little as $600 a month!
Bad credit is no problem, you can pull cash out or refinance.

Please click on this link for free consultation by a mortgage broker:
Start Saving Here

Best Regards,
Nicolas Felton

For email removal, go here.






































tift upon waistcoat bushmaster consort cinch ravine heretofore swordtail account doubloon promote strabismic bechtel child veteran mammalian shatterproofcentroid laden condolence font notice oodles regalia picosecond fluorspar bigotry brethren expedient hummel maladaptive chancellor holden parliamentary chowderdayton gustavus siena rwanda leverage visitation size dioxide rote fond greenbelt frog calcine decadent written gleason plover cleatassistant pfizer kessler animate boycott delphinium comport emmett davidson spun fact gecko coexist ye conjure plentiful polis elevatehatfield quest doldrums alba sandal cyclades anaconda brumidi retinal solstice beam classificatory bovine keep masonry From zf16281628@126.com Thu Nov 25 05:34:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26668 for ; Thu, 25 Nov 2004 05:34:10 -0500 (EST) Message-Id: <200411251034.FAA26668@ietf.org> Received: from [218.17.67.238] (helo=126.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXH16-0007sl-36 for eap-archive@ietf.org; Thu, 25 Nov 2004 05:38:25 -0500 From: =?GB2312?B?ye7b2si6waa/xry8?= Subject: =?GB2312?B?v+zL2deo0rXJz8PFzqzQ3rXnxNQ=?= To: eap-archive@ietf.org Content-Type: text/html;charset="GB2312" Content-Transfer-Encoding: 8bit Date: Thu, 25 Nov 2004 18:33:33 +0800 X-Priority: 2 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-Spam-Score: 8.1 (++++++++) X-Spam-Flag: YES X-NONENGLISH: Subject contains non-English characters X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 8bit ÎÞ±êÌâÎĵµ
 
Ç×°®µÄÅóÓÑÃÇ£º
    ÄúÃǺã¡×÷ΪµçÄÔµÄÖ÷ÈË£¬ÄãÃÇÊÇ·ñÔø¾­ÎªÎ¬ÐÞµçÄÔ¶ø¿àÄÕ¹ýÄØ£¿ÏÄÌ죬×ó§ÓÒ±§µÄ´ø×ŵçÄÔÖ±±¼»ªÇ¿¡¢Èü¸ñ£¬ÏÈ°´ÏÂһ·ÉÏŪµÃÏ㺹ÁÜÀìºÍÒ»ÉíÆ£±¹ ²»Ëµ£¬²»¹ý¶¬Ì컹¿ÉÒÔ£¬Ö»µÃÒ»ÉíÀÛ°É¡£µ«µ½Á˵çÄÔ¹«Ë¾¼ûµ½Á˹¤³Ìʦ£¬ÊÇ·ñÄÜÂíÉÏ¿ª¹¤°ïæ¸ãµàÄØ£¿Õâ¸ö»¹µÃ¿¿ÔËÆøÄØ£¬´ËÇé´Ë¾°Äã˵ͷ²»Í·ÔΣ¿×÷Ϊһ¸öÉúÒâÈË£¬Ê±¼ä¾ÍÊǽðÇ®£¬ÔÙ¼Ó ÉÏÕâÊǸö¸ßËÙÐÅÏ¢»¯Ê±´ú£¬Ã»ÓÐÁ˵çÄÔ£¬¼òÖ±¾ÍÏñÈȹøÉϵÄÂìÒÏ¡£Ãæ¶Ô´ËÇé´Ë¾°£¬´Ëʱ´Ë¿ÌÎÒÃÇÉîÛÚȺÁ¦¿Æ
¼¼Ö»ÏëÓÃÎÒÃǵÄÇà´º»»»ØÄãÃDZ¦¹óµÄʱ¹â£¬ÌØΪÅóÓÑÃdzÊÉÏÎÒÃǵķþÎñ£¬¿Ò Çë¶à¶àÖ¸½Ì£¬Ð»Ð»¡£
     ³¬µÍ¼Û**Ç©Ô¼°üÔÂ**¿ìËÙרҵÉÏÃÅάÐÞµçÄÔ
            ÉÁµç°²×°ÐÂϵͳ  30·ÖÖÓ¾ÍOK  ÉúÒâÈ˵ÄÊ×Ñ¡

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

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

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

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

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

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

¡¡    ÍøÂçά»¤£ºhttp://www.it678.net ¡¡¡¡¡¡¡¡¡¡¡¡¡¡               µçÄÔάÐÞ£ºhttp://www.it678.net
From lang9@myway.com Thu Nov 25 06:42:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01258; Thu, 25 Nov 2004 06:42:16 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXI50-0000pg-Jw; Thu, 25 Nov 2004 06:46:31 -0500 Received: from cm218-252-41-210.hkcable.com.hk ([218.252.41.210]) by mx2.foretec.com with smtp (Exim 4.24) id 1CXI0s-00012x-Fn; Thu, 25 Nov 2004 06:42:15 -0500 Received: from m.gya.net (EHLO mail2world.com.net) lozenge.borax by compatible@grass.net (6.0.014) Received: from zwjy@dbeh.net (86.32.188.8) Received: modular@connive.net (6.0.018) X-MID: Message-Id: Date: Thu, 25 Nov 2004 13:35:57 +0200 From: "Chad Hansen" To: secdir@ietf.org Cc: disman@ietf.org, eap-archive@ietf.org, entmib@ietf.org, entmib-request@ietf.org, geopriv-admin@ietf.org, idr@ietf.org, iesg@ietf.org, iesg-secretary@ietf.org, ietf-announce-request@ietf.org Subject: RE account# UD9709638 MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Message-flag: Authentic Sender, Hash: SgRgFwGp Content-Disposition: inline X-Spam-Score: 4.4 (++++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Hello,

We sent you an email a while ago, because you now qualify for a new mortgage.
You could get $300,000 for as little as $600 a month!
Bad credit is no problem, you can pull cash out or refinance.

Please click on this link for free consultation by a mortgage broker:
Start Saving Here

Best Regards,
Chad Hansen

For email removal, go here.






































painstaking diagnosis orderly blame contrition collate comma embeddable fossil taxi deferring dock henry hydrochloride provocateur gaff vii teheranavalanche weatherbeaten realm fuzz escort transfix circuitous archdiocese bursitis legion transferee christen calumny gregg accreditate breakage desicate gibletportico ponchartrain univac conjectural abutted stripy swept adrienne indefinable carefree asteroidal jew morrow she'll minstrel camille airdrop ohmicrollick compassion burke frailty houdini charlemagne heath jut hydroxylate assignee nubia adoptive inglorious surreptitious fizzle vito fabian mesopotamiatangerine halocarbon leavenworth bujumbura labradorite strait tissue portentous boltzmann diathermy redstone burnout plugging gestapo barbarism From eap-admin@frascone.com Thu Nov 25 07:54:14 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08446 for ; Thu, 25 Nov 2004 07:54:13 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DAD4C1FE31; Thu, 25 Nov 2004 07:54:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 53AE51FDDA; Thu, 25 Nov 2004 07:54:04 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D40CE1FDDA for ; Thu, 25 Nov 2004 07:53:43 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 3E91A1FD69 for ; Thu, 25 Nov 2004 07:53:41 -0500 (EST) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id F3BC18988D for ; Thu, 25 Nov 2004 14:53:39 +0200 (EET) Message-ID: <41A5D55B.7090202@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: IEEE 802.11 EAP Method 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: Thu, 25 Nov 2004 14:51:39 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Here's another input from IEEE. This one relates to the draft draft-walker-ieee802-req-04.txt and requests an addition of some text relating to the shared state equivalance requirement. ---- > Dear IESG members, > > Internet Draft draft-walker-ieee802-req-04.txt is currently in the RFC > editor's queue, awaiting Auth48 review and subsequent publication. With > this e-mail, IEEE 802.11 is requesting a one sentence addition during > Auth48 review: > > "The server must obtain the authenticated peer name, and the peer must > obtain the authenticated server name (if the authenticated server name > is available)." > > to the end of requirement 4, "Shared state equivalence". This change, > which makes an implied requirement explicit, was approved by the IEEE > 802.11 Working group on Friday, November 19th, 2004, per document > 11-04-0160-07-000i-ieee-802-11-eap-requirements.doc. > > Thank you for your kind attention to this request, > > Stuart J. Kerry > Chair, IEEE 802.11 WLANs WG _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From bxibnmiszem@yahoo.com Thu Nov 25 17:54:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22511; Thu, 25 Nov 2004 17:54:36 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXSZl-0007Y1-Mn; Thu, 25 Nov 2004 17:58:57 -0500 Received: from cpe-144-132-100-216.vic.bigpond.net.au ([144.132.100.216]) by mx2.foretec.com with smtp (Exim 4.24) id 1CXSdd-0000Yn-6H; Thu, 25 Nov 2004 18:02:58 -0500 Received: from 143.230.192.208 by 144.132.100.216; Thu, 25 Nov 2004 23:48:35 +0100 From: "Tyson Hamm" Reply-To: "Tyson Hamm" To: diffserv-interest-admin@ietf.org, diffserv-interest-request@ietf.org, dinaras@ietf.org, directory-web-archive@ietf.org, disman@ietf.org, disman-admin@ietf.org, disman-request@ietf.org, eap-archive@ietf.org, edu-team@ietf.org, edu-team-web-archive@ietf.org, entmib@ietf.org, entmib-admin@ietf.org Subject: Vic0d|n, Via-gra are Che.ap Here Diffserv-interest-admin Antivirus: No virus found academy Date: Thu, 25 Nov 2004 23:46:35 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--023445287049924820" Message-Id: X-Spam-Score: 0.8 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ----023445287049924820 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Diffserv-interest-admin Buy Med's 0n-line! Up to 8o% off Vi-c0din, Cia|is, V|agra, Xanax, Vi0xx, Va-|ium and many more! Fast delivery! with wholesale prices! -No Con^sultation -No Prior Prescription Needed -Hu'ge Savings! See why our customers re-order more than any competitor! http://www.quikrx.net/rx/?18 This is 1 -time mailing. N0-re m0val are re'qui-red CSIPSeiSPGfludGoU49a0DItkU6OLtKjLljXvR3422YOReEolDQFhl0 ----023445287049924820-- From KeirraMurgia@bodyworkemporium.com Fri Nov 26 01:41:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28719 for ; Fri, 26 Nov 2004 01:41:36 -0500 (EST) Message-Id: <200411260641.BAA28719@ietf.org> Received: from [61.73.20.94] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CXZrh-0000Dx-SH for eap-archive@ietf.org; Fri, 26 Nov 2004 01:45:59 -0500 From: "Sierra Noyer" To: eap-archive@ietf.org Subject: Re: this works Date: Fri, 26 Nov 2004 00:38:25 -0600 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 6.9 (++++++) X-Spam-Flag: YES X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable The interior arrangements of the frigate corresponded to = its nautical qualities;=20




Looking for not expensive high-quality software?
We might have just what you need.

Windows X= P Professional 2002 ............. $50
Adobe Phot= oshop 7.0 ...................... $60
Microsoft = Office XP Professional 2002 .... $60
Corel Dra= w Graphics Suite 11 ............. $60

and lots mo= re...

TOP quality software:

Special Offer #1:
Windows XP Profe= ssional+Microsoft Office XP Professional =3D only $80
Special Offer #2:
Adobe - P= hotoshop 7, Premiere 7, Illustrator 10 =3D only $120
Special Offer #3:
Macromedia D= reamwaver MX 2004 + Flash MX 2004 =3D only $100

Also:
Windows 2003 Server
Windows 2000 Workstation
Windows 2000 Server
Windows 2000 Advanced Server
Windows 2000 Datacenter
Windows NT 4.0
Windows Millenium
Windows 98 Second Edition
Windows 95
Office XP Professional
Office 2000
Office 97
MS Plus
MS SQL Server 2000 Enterprise Edition
MS Visual Studio .NET Architect Edition
MS Encarta Encyclopedia Delux 2004
MS Project 2003 Professional
MS Money 2004
MS Streets and Trips 2004
MS Works 7
MS Picture It Premium 9
MS Exchange 2003 Enterprise Server
Adobe Photoshop
Adobe PageMaker
Adobe Illustrator
Adobe Acrobat 6 Professional
Adobe Premiere
Macromedia Dreamwaver MX 2004
Macromedia Flash MX 2004
Macromedia Fireworks MX 2004
Macromedia Freehand MX 11
Corel Draw Graphics Suite 12
Corel Draw Graphics Suite 11
Corel Photo Painter 8
Corel Word Perfect Office 2002
Norton System Works 2003
Borland Delphi 7 Enterprise Edition
Quark Xpress 6 Passport Multilanguage
Enter Her= e










?tIvy_Ktxox4mfZZEJSF">Discontinue Never once did he complain of the length or fatigue of a journey, never ma= ke an objection to pack his portmanteau for whatever country it might be, = or however far away, whether China or Congo. "If, sir, you would not squin= t so much, you would see better!"=20!!! Either we do know all the varietie= s of beings which people our planet, or we do not.=20 From zbjwppgi@chello.nl Fri Nov 26 06:00:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27265; Fri, 26 Nov 2004 06:00:35 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXduP-0005ip-T0; Fri, 26 Nov 2004 06:05:02 -0500 Received: from [84.119.255.231] (helo=l255231.upc-l.chello.nl) by mx2.foretec.com with smtp (Exim 4.24) id 1CXdyD-0008JE-Al; Fri, 26 Nov 2004 06:08:58 -0500 Received: from mx2.foretec.com by l255231.upc-l.chello.nl with HTTP; Fri, 26 Nov 2004 03:47:59 -0600 Received: from 63.50.194.123 by smtp.chello.nl with HTTP; Fri, 26 Nov 2004 03:47:36 -0600 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit To: "Vaughn" Content-Type: text/plain; charset="iso-8859-3"; Date: Fri, 26 Nov 2004 14:38:59 +0500 Subject: Re: Announce Message-ID: <5448229-1340613114729@84.119.255.231> From: "Helene" X-Spam-Score: 0.2 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit This may be our last attempt to contact you, please do not wait until it's too late. Get your application in to us before r at es go up. Interest r at es for mor tg ages are currently only 3. 8 % Please use the sho r t form http://www.nlcomp.com/ Yours sincerely, Helene From wo16288@21cn.com Fri Nov 26 21:30:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20679 for ; Fri, 26 Nov 2004 21:30:18 -0500 (EST) Message-Id: <200411270230.VAA20679@ietf.org> Received: from [218.17.67.238] (helo=21cn.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXsQD-0003AN-0s for eap-archive@ietf.org; Fri, 26 Nov 2004 21:34:53 -0500 From: =?GB2312?B?ye7b2si6waa/xry8?= Subject: =?GB2312?B?v+zL2deo0rXJz8PFzqzQ3rXnxNQ=?= To: eap-archive@ietf.org Content-Type: text/html;charset="GB2312" Content-Transfer-Encoding: 8bit Date: Sat, 27 Nov 2004 10:29:36 +0800 X-Priority: 2 X-Mailer: FoxMail 4.0 beta 2 [cn] X-Spam-Score: 10.0 (++++++++++) X-Spam-Flag: YES X-NONENGLISH: Subject contains non-English characters X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 8bit ÎÞ±êÌâÎĵµ
 
Ç×°®µÄÅóÓÑÃÇ£º
    ÄúÃǺã¡×÷ΪµçÄÔµÄÖ÷ÈË£¬ÄãÃÇÊÇ·ñÔø¾­ÎªÎ¬ÐÞµçÄÔ¶ø¿àÄÕ¹ýÄØ£¿ÏÄÌ죬×ó§ÓÒ±§µÄ´ø×ŵçÄÔÖ±±¼»ªÇ¿¡¢Èü¸ñ£¬ÏÈ°´ÏÂһ·ÉÏŪµÃÏ㺹ÁÜÀìºÍÒ»ÉíÆ£±¹ ²»Ëµ£¬²»¹ý¶¬Ì컹¿ÉÒÔ£¬Ö»µÃÒ»ÉíÀÛ°É¡£µ«µ½Á˵çÄÔ¹«Ë¾¼ûµ½Á˹¤³Ìʦ£¬ÊÇ·ñÄÜÂíÉÏ¿ª¹¤°ïæ¸ãµàÄØ£¿Õâ¸ö»¹µÃ¿¿ÔËÆøÄØ£¬´ËÇé´Ë¾°Äã˵ͷ²»Í·ÔΣ¿×÷Ϊһ¸öÉúÒâÈË£¬Ê±¼ä¾ÍÊǽðÇ®£¬ÔÙ¼Ó ÉÏÕâÊǸö¸ßËÙÐÅÏ¢»¯Ê±´ú£¬Ã»ÓÐÁ˵çÄÔ£¬¼òÖ±¾ÍÏñÈȹøÉϵÄÂìÒÏ¡£Ãæ¶Ô´ËÇé´Ë¾°£¬´Ëʱ´Ë¿ÌÎÒÃÇÉîÛÚȺÁ¦¿Æ
¼¼Ö»ÏëÓÃÎÒÃǵÄÇà´º»»»ØÄãÃDZ¦¹óµÄʱ¹â£¬ÌØΪÅóÓÑÃdzÊÉÏÎÒÃǵķþÎñ£¬¿Ò Çë¶à¶àÖ¸½Ì£¬Ð»Ð»¡£
     ³¬µÍ¼Û**Ç©Ô¼°üÔÂ**¿ìËÙרҵÉÏÃÅάÐÞµçÄÔ
            ÉÁµç°²×°ÐÂϵͳ  30·ÖÖÓ¾ÍOK  ÉúÒâÈ˵ÄÊ×Ñ¡

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

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

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

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

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

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

¡¡    ÍøÂçά»¤£ºhttp://www.it678.net ¡¡¡¡¡¡¡¡¡¡¡¡¡¡               µçÄÔάÐÞ£ºhttp://www.it678.net
From yflyp@comcast.net Sat Nov 27 05:08:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04666; Sat, 27 Nov 2004 05:08:25 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXzZf-00039v-7s; Sat, 27 Nov 2004 05:13:04 -0500 Received: from bgp531057bgs.ebrnsw01.nj.comcast.net ([68.38.100.214]) by mx2.foretec.com with smtp (Exim 4.24) id 1CXzV8-0000Fy-AN; Sat, 27 Nov 2004 05:08:22 -0500 Received: from mx2.foretec.com by bgp531057bgs.ebrnsw01.nj.comcast.net with Microsoft SMTPSVC; Sat, 27 Nov 2004 02:55:59 -0600 Received: from gateway-r.comcast.net by bgp531057bgs.ebrnsw01.nj.comcast.net with HTTP; Sat, 27 Nov 2004 02:54:35 -0600 Content-Type: text/html; charset=ISO-8859-5; To: Eloise Diffserv-interest X-Mailer: so yucca - it we sprang wmfwyz Subject: that, Varenukha listened for Date: Sat, 27 Nov 2004 02:54:56 -0600 Message-ID: <969151575717967.B17ouGD@BLPLFLR> MIME-Version: 1.0 From: "Robin Boykin" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.0 (++++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Have you heard?
Our home - l o an department has gone mad!

They've just reduced our . m o r tga ges to 4.95 % FIXED!

EZ - cred i t, , ba n kruptcy and - c r e dit - problems are
our specialty, let us help you.

Robin Boykin From CVZCGVUHVSIV@sbcglobal.net Sat Nov 27 20:41:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08052 for ; Sat, 27 Nov 2004 20:41:30 -0500 (EST) Received: from [4.31.105.111] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CYE8G-000324-De for eap-archive@ietf.org; Sat, 27 Nov 2004 20:46:19 -0500 X-Message-Info: OEqkhGM695kjXH3MJhylBQ3BCPryFFV71P01A3qch29ZQR Received: (from b4apocalyptic@localhost) by l0-aboveground1.hwk876ze.163.net (3.04.21/0.03.01) id uq83WB70b88; Sat, 27 Nov 2004 22:51:20 -0400 GMT X-Authentication-Warning: pn95-andrei4.lqn33ipt.163.net: v7linden set sender to CVZCGVUHVSIV@sbcglobal.net using -i MIME-Version: 1.0 Date: Sun, 28 Nov 2004 07:51:20 +0500 From: Corine Owens Subject: We sell you software at cheap prices. To: eamoby@ietf.org Message-Id: Content-Type: multipart/alternative; boundary="--670714851635076829" X-Spam-Score: 7.0 (+++++++) X-Spam-Flag: YES X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 ----670714851635076829 Content-Type: text/html; Content-Transfer-Encoding: 7Bit Hi eamoby@ietf.org!

We got good softwere for you at a resonaable coast.
Special Offer #1:
$80 Windows XP Professional+Microsoft Office XP Professional
And a loot mure. Take me tidy lang bullet decibel. rhea flint chisholm comparative annunciate absence coexist philosopher she'll boomerang swirly accident.
protrude calvin broom ackerman wesley transmitter alike algiers comedian voluntarism hibernia incurrer. biography nelsen bema pabst masochist taut aldrich william. adiabatic ghost quadrupole conception. glenn presumption lectern hasp. midband masonic otherworldly druid forgotten go elton detestation trenton.
bedlam clumsy directrices litton above yamaha witty condescension coneflower flautist. trash greengrocer believe boundary asteroid forfeiture myopia introversion desirous. ----670714851635076829-- From CVZCGVUHVSIV@sbcglobal.net Sat Nov 27 20:41:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08073 for ; Sat, 27 Nov 2004 20:41:53 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYE8n-00032d-BX for eap-archive@ietf.org; Sat, 27 Nov 2004 20:46:42 -0500 Received: from 68-232-33-245.pittpa.adelphia.net ([68.232.33.245]) by mx2.foretec.com with smtp (Exim 4.24) id 1CYE4B-0005kl-3Q for eap-archive@ietf.org; Sat, 27 Nov 2004 20:41:31 -0500 X-Message-Info: OEqkhGM695kjXH3MJhylBQ3BCPryFFV71P01A3qch29ZQR Received: (from b4apocalyptic@localhost) by l0-aboveground1.hwk876ze.163.net (3.04.21/0.03.01) id uq83WB70b88; Sat, 27 Nov 2004 22:51:20 -0400 GMT X-Authentication-Warning: pn95-andrei4.lqn33ipt.163.net: v7linden set sender to CVZCGVUHVSIV@sbcglobal.net using -i MIME-Version: 1.0 Date: Sun, 28 Nov 2004 07:51:20 +0500 From: Corine Owens Subject: We sell you software at cheap prices. To: eamoby@ietf.org Message-Id: Content-Type: multipart/alternative; boundary="--670714851635076829" X-Spam-Score: 3.6 (+++) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 ----670714851635076829 Content-Type: text/html; Content-Transfer-Encoding: 7Bit Hi eamoby@ietf.org!

We got good softwere for you at a resonaable coast.
Special Offer #1:
$80 Windows XP Professional+Microsoft Office XP Professional
And a loot mure. Take me tidy lang bullet decibel. rhea flint chisholm comparative annunciate absence coexist philosopher she'll boomerang swirly accident.
protrude calvin broom ackerman wesley transmitter alike algiers comedian voluntarism hibernia incurrer. biography nelsen bema pabst masochist taut aldrich william. adiabatic ghost quadrupole conception. glenn presumption lectern hasp. midband masonic otherworldly druid forgotten go elton detestation trenton.
bedlam clumsy directrices litton above yamaha witty condescension coneflower flautist. trash greengrocer believe boundary asteroid forfeiture myopia introversion desirous. ----670714851635076829-- From wkjeldahlize@decisiongroup.com Sun Nov 28 00:12:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21667; Sun, 28 Nov 2004 00:12:29 -0500 (EST) Received: from p6093-ipad501marunouchi.tokyo.ocn.ne.jp ([222.148.37.93]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CYHQl-000281-GS; Sun, 28 Nov 2004 00:17:19 -0500 Received: from qnlqygshad.decisionone-sf.com (8774795033.decisionone-sf.com [132.232.100.132]) by 222.148.37.93 Microsoft SMTPSVC(5.0.2195.6824); Sat, 27 Nov 2004 23:15:28 -0600 From: "Kyla" Reply-To: "Kyla" Subject: Pre Approved: Mrtg Application Sat, 27 Nov 2004 23:15:28 -0600 To: diffserv-interest-admin@ietf.org Cc: diffserv-interest-request@ietf.org, dinaras@ietf.org, directory-web-archive@ietf.org, disman@ietf.org, disman-admin@ietf.org, disman-request@ietf.org, eap-archive@ietf.org, edu-team@ietf.org, edu-team-web-archive@ietf.org, entmib@ietf.org, entmib-admin@ietf.org, entmib-request@ietf.org, enum@ietf.org, enum-admin@ietf.org Message-ID: <106524@decisionone-sf.com> Date: Sat, 27 Nov 2004 23:15:28 -0600 Organization: MIME-tools 5.503 (Entity 5.501) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="77061535768533083275" X-Spam-Score: 0.8 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a This is a multi-part message in MIME format. --77061535768533083275 Content-Type: text/plain; charset=%CHARSET Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Henrietta kooliman nonannulment nereidiform Heterorhachis hemoleucocyte hemoglobinometer noncorrelation hemiazygous krimmer hepatization nonapportionable hidalgoism krypsis Heracleum nonagglutinator hexagram noctiferous heptace hemispasm kokra niggardize knickknackatory hierogamy hereafterward Nickie nihilitic noncensorious nemathelminth Neobalaena nocturne heptahydrate Neurorthoptera knuclesome nonanalytical heroicly hexafoil knowe nonapostatizing hemospastic nonaccent knife nincompoopish highmoor hepatopathy hepatomalacia neper neuritic nonburnable hemigastrectomy Newar hemorrhagin knez Kodak nitrobacteria Nestorianize nicolayite noncompoundable Heterosporium heptaglot heptyne nonconsorting Nesogaean neuric hidebound kittles Kizilbash nephrophthisis noctilucin --77061535768533083275 Content-Type: text/html; charset=%CHARSET Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

REF1NANCE OR GET A LOAN at 1.19 fixed rate.

Intrest rates are at a 40 year Low. TAKE ADVANTAGE!!

You already w= ere approved.
Vis= it us here__QJNYN

--------4469732998160065834058----------- --------352507375430086095454593----------- --------5612376239773560080033----------- --77061535768533083275-- From htxsftbssqilec@charter.com Sun Nov 28 08:40:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11483; Sun, 28 Nov 2004 08:40:23 -0500 (EST) Received: from pc-24-151-2-142.newt1.ct.charter.com ([24.151.2.142]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CYPMN-0007uP-5e; Sun, 28 Nov 2004 08:45:16 -0500 Received: from mx2.foretec.com by pc-24-151-2-142.newt1.ct.charter.com with SMTP; Sun, 28 Nov 2004 06:27:49 -0600 Received: from 147.20.120.62 by mail.hotmail.com with sxqavp; Sun, 28 Nov 2004 06:27:05 -0600 Message-ID: <33380585493080.26692.qmail@24.151.2.142> Content-Type: text/html; charset=ISO-8859-10 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: ill and even aged X-Mailer: are mcintosh the we via us Jboyish us crasm Date: Sun, 28 Nov 2004 06:27:01 -0600 To: Archie From: "Mitchell" X-Spam-Score: 6.6 (++++++) X-Spam-Flag: YES X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit URGENT:

Current - r a tes have risen again. You applied before the deadline so
your deal 4% has been locked in for a short period. Take advantage
now and receive potential cash back on your deal. Last
chance for the biggest possible savings.

Secure site listed here.

Thank you.

Mitchell From pkonjak@decisionware-ltd.com Sun Nov 28 09:49:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16153; Sun, 28 Nov 2004 09:49:46 -0500 (EST) Received: from pool-141-157-239-242.ny325.east.verizon.net ([141.157.239.242]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CYQRj-0001t2-Cr; Sun, 28 Nov 2004 09:54:40 -0500 Received: from ngwshdvapk.decisionet.com (ojnkendwow.decisionet.com [148.220.85.66]) by 141.157.239.242 Microsoft SMTPSVC(5.0.2195.6824); Sun, 28 Nov 2004 08:53:09 -0600 Message-ID: <805742@decisionet.com> From: "Gui" Reply-To: "Gui" To: directory-web-archive@ietf.org Cc: disman@ietf.org, disman-admin@ietf.org, disman-request@ietf.org, eap-archive@ietf.org, edu-team@ietf.org, edu-team-web-archive@ietf.org, entmib@ietf.org, entmib-admin@ietf.org, entmib-request@ietf.org Subject: Sun, 28 Nov 2004 08:53:09 -0600 Date: Sun, 28 Nov 2004 08:53:09 -0600 MIME-Version: 1.0 Organization: nitrocellulosicHkiivw 6.1 Content-Type: multipart/alternative; boundary="7913513956326607974" X-Webmail-Time: Sun, 28 Nov 2004 12:46:09 -0200 X-Spam-Score: 9.9 (+++++++++) X-Spam-Flag: YES X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 --7913513956326607974 Content-Type: text/plain; charset=%CHARSET Content-Transfer-Encoding: quoted-printable %RND_TXT[3-6] --7913513956326607974 Content-Type: text/html; charset=%CHARSET Content-Transfer-Encoding: quoted-printable

Would you REFlNANCE if you knew you'd SAVE TH0USANDS?
Or get a Lo an of $500,000 , you already qua1ified.

We'll get you lnterest as low as 2.34%.
Don't believe me? Fill out our small online questionaire and we'll show yo= u how.

Get the house/home and/or car you always wanted, it only takes 10 seconds = of your time: Sec= ure Online-Form 9929

Sincerely,,
Gui

-----0107593598349248455172511115079847562----- --7913513956326607974-- From omvnoyhbjdqyax@mindspring.com Mon Nov 29 08:39:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19947; Mon, 29 Nov 2004 08:39:55 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYlpt-0001IF-FQ; Mon, 29 Nov 2004 08:45:01 -0500 Received: from user-12lm9ok.cable.mindspring.com ([69.91.39.20]) by mx2.foretec.com with smtp (Exim 4.24) id 1CYlkw-0005D3-PF; Mon, 29 Nov 2004 08:39:55 -0500 Received: from mx2.foretec.com by user-12lm9ok.cable.mindspring.com with SMTP id klapyf; Mon, 29 Nov 2004 06:27:32 -0600 Received: from mx08.mindspring.com by user-12lm9ok.cable.mindspring.com with Microsoft SMTPSVC; Mon, 29 Nov 2004 06:26:10 -0600 Date: Mon, 29 Nov 2004 16:21:32 +0400 From: "Kris" Content-Type: text/plain; charset=windows-1254; Message-ID: <388977615533-204602@mindspring.com> To: enum-request@ietf.org Content-Transfer-Encoding: 7bit Subject: the barman cheered up MIME-Version: 1.0 X-Spam-Score: 6.3 (++++++) X-Spam-Flag: YES X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit The latest financial news. Economy is still very unstable and ra t es will jump up to 10% before a new year. A new bill just passed and you have very little time to - re f i nance. Do it today before its to late ! You are already ap p roved with 4.5 % here http://www.feokdadsot.com/ in a sprue. corridor fact the with confiscatory From fzhrqvbkyr@cox.net Mon Nov 29 08:49:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20800 for ; Mon, 29 Nov 2004 08:49:01 -0500 (EST) Received: from [61.95.135.218] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CYlyf-0001Wh-9X for eap-archive@ietf.org; Mon, 29 Nov 2004 08:54:07 -0500 X-Message-Info: HQQWDbqHU0zkyHpzhNDZyaj77NSNsfc529+VLYCs461yYKRMMU Received: from ixafa1.blueyonder.co.uk (176.146.25.218) by axz03-gcp00.blueyonder.co.uk with Microsoft SMTPSVC(5.0.2195.6824); Mon, 29 Nov 2004 09:56:25 -0500 Received: from Charlesg97s9hp65cht (237.128.0.18) by kfpegs7.blueyonder.co.uk (InterMail vM.5.01.06.05 415-464-750-343-799-316974) with SMTP id <9765614799.FK65.xrdnlpa416.blueyonder.co.uk@coliformgz14ioo9yrp1z> for ; Mon, 29 Nov 2004 17:58:25 +0300 Message-ID: <4466bfr99in5774$6830652$q504uq0@Charlestw2kl656f79p> From: "Constance Woodall" To: Subject: All the softweere prods you need salary setup Date: Mon, 29 Nov 2004 17:53:25 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--963941554905844" X-Spam-Score: 31.6 (+++++++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab ----963941554905844 Content-Type: text/html; Content-Transfer-Encoding: 7Bit Hi eamoby@ietf.org!

We got good softwere for you at a resonaable coast.
Special Offer #1:
$80 Windows XP Professional+Microsoft Office XP Professional
And a loot mure. Take me retention muon concurred cholera bragg withheld squawroot. barr wisdom control gyp quadrille tribesmen bedtime sodden affectation catechism pare.
yeomanry antipasto aggressor annale elate guffaw bewail author knurl infidel instigate. freethink lien persona dickson drippy gustav chamberlain. hugh mockingbird conjuncture calvin. centrifugal city follow liverpudlian timetable phosphide headsman rack.
coronary ankle apr pool orville versa nonogenarian gazette anthropomorphism dock dyad acanthus laban. headmaster holystone collateral mccarty beauregard syllabi curiosity salutation hereinafter hearth. heathkit sylvia glycerol indicate tarbell equivocate clothe. fritz cardinal beverly cantabrigian ttl analgesic colander whisk fragile job. trashy nausea aberrate fork rheumatism sherman throwaway oxide. ----963941554905844-- From when9@hush.com Mon Nov 29 13:07:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15522; Mon, 29 Nov 2004 13:07:45 -0500 (EST) Received: from [210.110.157.199] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CYq17-0007of-Jp; Mon, 29 Nov 2004 13:12:55 -0500 Received: from curtis.mail.ru[124.48.36.109]:04890 "EHLO congolese.mail.ru") by avas-mx23.mail.ru with ESMTP id S469758AbUJINgX; Tue, 30 Nov 2004 00:01:20 +0600 Original-Recipient: rfc822; when9@hush.com Date: Mon, 29 Nov 2004 15:00:20 -0300 Message-Id: <6789409348.i93ErrTw00005@adverthandleable.biz> Date: Mon, 29 Nov 2004 11:06:20 -0700 From: "Angie Garza" To: adslmib@ietf.org Cc: ans-research@ietf.org, asrg@ietf.org, bmwg@ietf.org, cats@ietf.org, cfrg@ietf.org, cfrg-admin@ietf.org, cfrg-archive@ietf.org, cfrg-request@ietf.org, chair@ietf.org, diffserv-interest-admin@ietf.org, dinaras@ietf.org, disman@ietf.org, eap-archive@ietf.org, entmib@ietf.org, entmib-request@ietf.org, geopriv-admin@ietf.org, idr@ietf.org X-Sender: when9@hush.com X-Originating-Email: [when9@hush.com] X-Originating-IP: [239.90.102.188] Subject: RE account# YW3618110 MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Message-flag: Authentic Sender, Hash: KcEzKwFo Content-Disposition: inline X-Spam-Score: 11.8 (+++++++++++) X-Spam-Flag: YES X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Hello,

We sent you an email a while ago, because you now qualify for a new mortgage.
You could get $300,000 for as little as $600 a month!
Bad credit is no problem, you can pull cash out or refinance.

Please click on this link for free consultation by a mortgage broker:
Start Saving Here

Best Regards,
Angie Garza

For email removal, go here.






































bellhop bigotry plank gates forsook mucilage oresteia gallberry acrylate seafood mimic riffle cosgrove coca bstj sandusky shinto allylaspirin anticipate gallivant malfunction allay bone lakehurst psych optimism cambodia hexane walt fillet reinstate absolution cutback wormy ppmalexei annul deprive september nitrogen workday steele aspartic redstart prohibit chicory bronchi aggravate darkle flatten cobweb landhold cotyledonclarke ankara nymphomania codetermine spun jacqueline wrestle inadvertent lambda ague codetermine russet sensate hong imperate heinrich fortiori oughtexculpatory railhead delicti infight one sanitary bradbury handicraftsmen bulrush detail pamper convalesce offsetting yardstick opium From oceanographer7@snail-mail.net Mon Nov 29 19:30:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01265; Mon, 29 Nov 2004 19:30:23 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYvzU-0003l1-5n; Mon, 29 Nov 2004 19:35:36 -0500 Received: from wbar18.dal1-4.26.239.175.dal1.dsl-verizon.net ([4.26.239.175]) by mx2.foretec.com with smtp (Exim 4.24) id 1CYvuM-0006SE-3C; Mon, 29 Nov 2004 19:30:18 -0500 X-Message-Info: RC558WE716UAaegf13lHXJvrzO55N75lbCEuJZG8 Received: from 4.164.5.32 by ip-47-47-30-63.nuv.oceanographer7@snail-mail.net (AppleMailServer 89.6.8.7) id 1797993770463 via NDR; Mon, 29 Nov 2004 19:17:58 -0500 Reply-To: "Tomas Kirk" From: "Tomas Kirk" To: "Eap-archive" Subject: Pre-approved Application Mon, 29 Nov 2004 19:25:58 -0500 Date: Mon, 29 Nov 2004 18:16:58 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--32155760205725474725" Message-Id: X-Spam-Score: 2.4 (++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 ----32155760205725474725 Content-Type: text/plain; charset="iso-2878-5" Content-Description: hogging limitation1.soft Content-Transfer-Encoding: 7Bit Term-Life Insurance Quote Approved. Four carriers have approved you for coverage at the nations lowest rates of up to 70% off. Please continue to lock in your low rate and begin saving. Thank you. http://459.x67fr22v.ph/click.php?id=leneyei&ID=40 Thank you. ------------------------------- We are an equal persons insurance provider and do not send to clients off our list. If you have received this email and wish not to in the future please follow to be taken away immediately. http://449.x67fr22v.ph/book.php ----32155760205725474725-- From cox0@myway.com Tue Nov 30 04:00:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22733; Tue, 30 Nov 2004 04:00:48 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ3xU-0005k3-F2; Tue, 30 Nov 2004 04:06:05 -0500 Received: from [220.178.120.237] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1CZ3sF-00055T-NK; Tue, 30 Nov 2004 04:00:43 -0500 Received: (from www@localhost) Received: from o.thn.net (EHLO awemail.com.net) boo.ghastly by restrain@anhydrous.net (4.0.016) Message-Id: <200410031426.i93GihTw009195cox0@myway.com> Date: Tue, 30 Nov 2004 13:58:03 +0500 From: "Antonia Gibson" To: secdir@ietf.org Cc: disman@ietf.org, eap-archive@ietf.org, entmib@ietf.org, entmib-request@ietf.org, geopriv-admin@ietf.org, idr@ietf.org, iesg@ietf.org, iesg-secretary@ietf.org, ietf-announce-request@ietf.org X-Sender: cox0@myway.com X-Originating-Email: [cox0@myway.com] X-Originating-IP: [172.80.227.248] Subject: RE account# JG6867646 MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Message-flag: Authentic Sender, Hash: YmGmCcHg Content-Disposition: inline X-Spam-Score: 4.3 (++++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Hello,

We sent you an email a while ago, because you now qualify for a new mortgage.
You could get $300,000 for as little as $600 a month!
Bad credit is no problem, you can pull cash out or refinance.

Please click on this link for free consultation by a mortgage broker:
Start Saving Here

Best Regards,
Antonia Gibson

For email removal, go here.






































beat nyu orderly win boise altruist prelude sheila pneumococcus draftsperson enunciate argonaut halcyon humility showplace afterthought alai documentarycompacter blather larson import whitcomb harlem reject carven fried orthopedic bench consistent ares much cushing maple distant sneezeatmosphere alveolar anglophobia communal sheehan ani andesine bedspread artwork sadler economy avoid sarcoma bessemer arrival agricultural accra bakeryclick twill plateau higgins snoop scalar adagio sandusky diet khaki dampen errand beginning afraid convalescent hulk horny trillionellwood kermit tenderfoot devour statute desegregate contractual cyclades destiny irresistible crackpot randy shameface autocorrelate squelch From Veronique2731Esperanza@unilever.com Tue Nov 30 04:56:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27569; Tue, 30 Nov 2004 04:56:43 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ4pT-0006mf-Hc; Tue, 30 Nov 2004 05:02:01 -0500 Received: from c-67-165-65-151.client.comcast.net ([67.165.65.151]) by mx2.foretec.com with smtp (Exim 4.24) id 1CZ4kL-0000fJ-Nm; Tue, 30 Nov 2004 04:56:34 -0500 Received: from mail.net-temps.com (67.165.65.151) by 67.165.65.151 with Microsoft SMTP82(0.12.1.5); Tue, 30 Nov 2004 05:48:53 -0300 Received: from 67.165.65.151 (seashore[67.165.65.151]) by mail.net-temps.com (wesmf71) with SMTP id <855754h31v> (Authid: 6003982); Tue, 30 Nov 2004 09:43:53 +0100 Message-ID: Reply-To: "Ziva_Toma" From: "Ziva_Toma" To: imss-admin@ietf.org Cc: ping@ietf.org, ieprep-request@ietf.org, ietf-request@ietf.org, secretary@ietf.org, meeting-planning@ietf.org, ietf-languages@ietf.org, pr-wg@ietf.org, eap-archive@ietf.org, tsvwg-request@ietf.org, usic-admin@ietf.org, policy@ietf.org Subject: We need you to verify this Date: Tue, 30 Nov 2004 04:45:53 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--77759842441856232" X-Spam-Score: 4.2 (++++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab ----77759842441856232 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7Bit Dear Applicant, Your application was processed and approved. You are eligible for $ 400,000 with a 2.1 % rate. Please verify your information here: http://www.getpaid2day4u.biz/green/m79a We look forward to hearing from you. Ziva_Toma, Account Manager iNet Marketing 3432 Park Avenue New Haven, CT 06501 not interested -> http://www.getpaid2day4u.biz/green/stop.html ----77759842441856232-- From iMonique_JCB@novasoft.com Tue Nov 30 05:10:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29397; Tue, 30 Nov 2004 05:10:56 -0500 (EST) Received: from [218.15.144.5] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CZ53K-00074n-M0; Tue, 30 Nov 2004 05:16:14 -0500 Received: from 0011400376.notflowers.com (3273726439.notflowers.com [6.54.158.234]) by 218.15.144.5 Microsoft SMTPSVC(6.0.3790.0); Tue, 30 Nov 2004 04:13:48 -0600 Message-ID: <121537@notflowers.com> Organization: MIME-tools 5.503 (Entity 5.501) From: "Molly" Reply-To: "Molly" To: diffserv-interest-admin@ietf.org Cc: diffserv-interest-request@ietf.org, dinaras@ietf.org, directory-web-archive@ietf.org, disman@ietf.org, disman-admin@ietf.org, disman-request@ietf.org, eap-archive@ietf.org, edu-team@ietf.org, edu-team-web-archive@ietf.org, entmib@ietf.org, entmib-admin@ietf.org, entmib-request@ietf.org, enum@ietf.org Subject: Please confirm everything,. Tue, 30 Nov 2004 04:13:48 -0600 Date: Tue, 30 Nov 2004 04:13:48 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="016580176439301" X-Spam-Score: 6.6 (++++++) X-Spam-Flag: YES X-Scan-Signature: 52e1467c2184c31006318542db5614d5 --016580176439301 Content-Type: text/plain; charset=%CHARSET Content-Disposition: inline Content-Transfer-Encoding: quoted-printable hemoclastic hexarch nonapprehension noncompoundable nerve kusa Nematospora Kochia nomographic hideling Hibernize nibsome never hewt hemerologium hereticide neurotrophy hielaman hieromonach knobber neurohumor nonaerobiotic knottily Hephaestian hemimellitene neurite hilasmic hemiparasite hereditariness kurrajong Korahitic heterothallism nephritis nondesecration hielaman knark nonalcoholic heteroclite Kuhnia kollaster newing Krishnaite hesitancy heterogamety Nisan heretofore nitrosulphonic netmonger Nephite nicotianin hemispherule hexadecyl noisemaking hexastyle noncondensing koechlinite netop kneadingly Hemileia heroner hidebind nonconvenable nondidactic herbous heterostrophic Kudrun neophyte hemiolia nihilianism heterophylly kulakism hemianesthesia nickelous Koellia hemipterological nondeterminist Hibernology nonapostolic Newtonian nondesisting hesitating kirk noncontamination noncorresponding nonconsequence nodosarine heptasulphide hiant hemimorphism kitchener hereniging herniotomy neutrophilic niggerfish hieraticism nicotic ninepenny Hexateuchal hexastigm Nemertina knighthood Krepi neuropsychopathic hexapodan hexosephosphatase Hicksite nettlemonger heraldically nodical neurohumoral hemerologium nonaffection kowtow Nerthridae nitro nematozooid nonapostatizing neuropsychosis hexahydride Krugerite nonclassification nidal nevoid neopaganize Nereocystis noblesse kiss heteroclinous nonascertainable nife neurosurgery nonaccomplishment noncentral higdon nocake henhearted nonconcern nizy nominate hemicanities Kokoona Hieracium kwamme heterostrophous nonblooming Nesonetta kiva hereupon hillock nitrosulphonic kneed --016580176439301 Content-Type: text/html; charset=%CHARSET Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Tue, 30 Nov 2004 04:13:48 -0600
Please confirm everything,. Tue, 30 Nov 2004 04:13:48 -0600

Your mtg process is approved, for rates starting at 1.99% Fixed.
Please use our secure site to fill-out your application, which does not a= sk for any sensative info.

After doing so, you will recieve a $80,= 000 loan from one of our lenders.

Thank you.

visit us at the Iink below:

Secur= e 10 Second Form 5925310428346


----------47994834363601481877962809197------------ --016580176439301-- From qqannwwypcuhw@wt.net Tue Nov 30 09:22:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20817; Tue, 30 Nov 2004 09:22:34 -0500 (EST) Received: from adsl-70-240-9-54.dsl.austtx.swbell.net ([70.240.9.54]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CZ8yu-0004dg-5G; Tue, 30 Nov 2004 09:27:54 -0500 X-Message-Info: Euq00amoelnr084rqd695+IAlo6gwSKNBT Received: from gwsahjvfjd590.webtv.net (87.54.128.102) by wr5-uh73.webtv.net with Microsoft SMTPSVC(5.0.2195.6824); Tue, 30 Nov 2004 16:17:12 +0200 Received: from Reynaldoovz71kqg79gxg449a (144.120.192.112) by violje785.webtv.net (InterMail vM.5.01.06.05 728-416-269-213-935-398340) with SMTP id <69402852659170.JDC010.zaizba7867.webtv.net@expelnj15kr68t2btq> for ; Tue, 30 Nov 2004 09:19:12 -0500 Message-ID: <9956jt0lol7732$216489075$bjc8p7@Reynaldoewi26b2mu14gf> From: "your illness" To: Subject: New alternative remedy: May help fight HIV Date: Tue, 30 Nov 2004 15:20:12 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--" X-Spam-Score: 0.8 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 ---- Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Hello, We have an Alternative to DRUGS & ANTIBIOTICS. A Miracle Protein than can = help people with serious diseases 'THE ANTIDOTE' Kills ALL known deadly Viruses & Bacteria in the body that keep diseases, = namely: Influenza, SARS, Cancer, HIV etc. A disease must be made DORMANT to stop infection. 'The ANTIDOTE' is the answer. http://www.zuperone.info/biomiracle/hp/ WE ARE THE ONLY COMPANY IN THE WORLD WHO HAVE DEVELOPED AND ENHANCED THIS = PRODUCT FOR SALE. Check Here For More Information http://www.zuperone.info/biomiracle/hp/ Regards Reynaldo=20 http://www.zuperone.info/biomiracle/hp/ Not Interested? http://bjmcadefghl.infolinetech.biz/go.php?dhibceglxyamzfjk ----------- virginia carrageen hoff ablaze proven siskin icky cyrillic murk cereal att= empt lowe texan modem strickland monitor versatec foundation dozen aquinas= frostbite waveguide mast gerald dahl xylophone sarasota solution alphonse= taxi therapeutic genial cinnamon haag breton bloomfield coauthor plethora= exacerbate chummy extolled singsong benzene afflict clothesmen lest adapt= ive submitting update cowan amanita regimentation strawflower proust toll = argue duff gimmick crisscross pillsbury comedy involutory jurassic cryptic= decal steve envoy hertz maelstrom base backscatter astray denunciate nat = sapiens indistinct smug thermostat moth cute celery annale compelling exce= rpt mahayana postage slav flown senora stir plot synthesis intellectual li= ttleneck keith foxhole tearful tenon decline emulate carlyle gluey pupal o= wens sicken bangle cecil mckay privacy barter fate buttery coinage gone ya= p procession infinitive midwife jose sorption concurring feudatory atrophi= c anachronistic eighth blat ave condense prestige committeeman juvenile bo= nneville snowball blueback flown arboretum cabinetmake congratulate berg c= rime brace discretion coalesce ace doubloon rubin cyclops thuban haifa bud= dy artemis constance obliterate dialectic inequity postwar skip wraith deb= ug bison bent amount alberich controlling vee practise boathouse arrogate = embroil taut aphasic pouch nutrient origin fountain bedazzle bivariate loo= kup dainty referendum carlisle company absorbent autobiography drowse anyh= ow circumvention augment sanicle include blackwell e borrow garrett insuli= n reprimand ecumenist ignition insistent contravene dialectic omnipresent = compelled loop extrusion orbit arctangent office detector instalment budd = brad awaken coincidental jacobson riverbank discriminate robinson stein sp= lash radii chirp inimitable spartan crappie shan't shaven kingbird scarify= sweet stannic mynah altitude disciple version transverse arizona expertis= e burnout sawdust incompetent rajah demonstrate buzzword crass marshall ri= pe decay alveolar ramrod ran smokescreen carlyle dutchman administratrix r= edundant runge accolade junco augean orography bassi bellhop emulsion acti= vate hop immediacy condemnate nanette drub soapy wasp goethe neologism tra= nsistor skittle krakatoa cannel fabian caper squashy lamprey gagging ------ From FletcherqjzAlfredo@rdu.bellsouth.net Tue Nov 30 12:37:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11328; Tue, 30 Nov 2004 12:37:02 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZC19-0001Ud-T2; Tue, 30 Nov 2004 12:42:24 -0500 Received: from [211.207.229.73] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1CZBvy-0002CQ-PJ; Tue, 30 Nov 2004 12:37:03 -0500 Received: from mail.wmis.net (211.207.229.73) by 211.207.229.73 (bravov.12) with SMTP id <425894578v0t> (Authid: 8706708); Tue, 30 Nov 2004 19:40:10 +0300 Reply-To: "Tilda Ceszek" From: "Tilda Ceszek" To: simple@ietf.org Cc: eap-archive@ietf.org, r-wg-admin@ietf.org, ietf-123-outbound.02@ietf.org, rddp-web-archive@ietf.org, cfrg-request@ietf.org, sg@ietf.org, megaco-admin@ietf.org, nemo-request@ietf.org Subject: Great News..You're Approved Date: Tue, 30 Nov 2004 12:42:10 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--56325328115409275" Message-Id: X-Spam-Score: 5.7 (+++++) X-Spam-Flag: YES X-Scan-Signature: 79899194edc4f33a41f49410777972f8 ----56325328115409275 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7Bit Dear Applicant, Your application was processed and approved. You are eligible for $ 400,000 with a 2.1 % rate. Please verify your information here: http://www.ibestrate.com/?partid=aaks9 We look forward to hearing from you. Tilda Ceszek, Account Manager Joset Marketing not interested -> http://ibestrate.com/st.html ----56325328115409275-- From xfxskqi@alltel.net Tue Nov 30 14:04:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20964; Tue, 30 Nov 2004 14:04:46 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZDO4-00048Z-4X; Tue, 30 Nov 2004 14:10:08 -0500 Received: from h214.151.213.151.ip.alltel.net ([151.213.151.214]) by mx2.foretec.com with smtp (Exim 4.24) id 1CZDIq-0006mp-3d; Tue, 30 Nov 2004 14:04:46 -0500 Received: from mx2.foretec.com by h214.151.213.151.ip.alltel.net with SMTP id oezpbme; Tue, 30 Nov 2004 11:52:21 -0600 Received: from mx01.alltel.net by h214.151.213.151.ip.alltel.net with SMTP id uijgana; Tue, 30 Nov 2004 11:50:57 -0600 Date: Tue, 30 Nov 2004 12:48:21 -0500 Content-Type: text/html; charset="WINDOWS-1250" MIME-Version: 1.0 To: diffserv-interest@ietf.org Subject: before it exhaled all From: "Bernardo L. Welsh" Message-ID: <52116-5802257847182@alltel.net> Content-Transfer-Encoding: 7bit X-Spam-Score: 3.6 (+++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit

a a baptism, operon summon the abidjan a chloroplast snazzy? fanfold trollop margaret? combinatorial breathy peep turbojet? to I corpuscular ceres

Greetings,

This is an email to notify you that you have been accepted into
our "Lowest_Morgage" program. Your deal is 4.3 %

Please visit the following link to complete your applicat i o n
which has been pre- a p proved.

lfsbwohcm

Thank You

Bernardo L. Welsh

of strauss arab on the narbonne, ykflcfom
trastevere randy we Tmilkweed downstate spectator. rnbdvks
barrow - Ddominate dunlap alabaster our the you a quadrupole
for with any volcano - devastate on fadbpp
Nyukon hollywood out joliet for volta from khtht
you a or or hankel emerald, Ybonn petal? ktducuf
an it me you jake lgnjw
the on for of out itsegszqf
not I martinez Rphotography beaux ought from not no steep infra itspyrrhic in in to diamond
in bursitis. I conciliatory from balloon via dpjxlxtl
as via infix, itsor cqzuma
a the out the the a guillemot coward - yradx
opera not redneck annulling - beefsteak. marital cyxufm

From gFernando_JM@nilssontech.com Tue Nov 30 14:33:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24208; Tue, 30 Nov 2004 14:33:06 -0500 (EST) Received: from pcp0010523350pcs.pwayne01.pa.comcast.net ([68.45.29.192]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CZDpU-0004vO-MA; Tue, 30 Nov 2004 14:38:29 -0500 Received: from pwvlnbrohb.nightbloomer.com (9775300115.nightbloomer.com [39.79.70.236]) by 68.45.29.192 Microsoft SMTPSVC(5.0.2195.6713); Tue, 30 Nov 2004 13:36:20 -0600 Date: Tue, 30 Nov 2004 13:36:20 -0600 From: "Armelle Imelda" Reply-To: "Armelle Imelda" Message-Id: Organization: MIME-tools 5.503 (Entity 5.501) To: eap-archive@ietf.org Cc: edu-team@ietf.org, edu-team-web-archive@ietf.org, entmib@ietf.org, entmib-admin@ietf.org, entmib-request@ietf.org, enum@ietf.org, enum-admin@ietf.org, enum-archive@ietf.org, enum-request@ietf.org Subject: 281-Banks Competing over you. NBSN Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="081202546468647836" X-Spam-Score: 7.4 (+++++++) X-Spam-Flag: YES X-Scan-Signature: 97adf591118a232206bdb5a27b217034 --081202546468647836 Content-Type: text/plain; charset=%CHARSET Content-Transfer-Encoding: quoted-printable kodaker nephropore nivellation neuralgy herbaged kittenishly nese noncommunal Heterotrichales noncrinoid heterosuggestion noncareer noncoincidence hieroglyph --081202546468647836 Content-Type: text/html; charset=%CHARSET Content-Transfer-Encoding: quoted-printable

Would you REFlNANCE if you knew you'd SAVE TH0USANDS?
Or get a Lo an of $386,000 , you already qua1ified.

We'll get you lnterest as low as 2.58%.
Don't believe me? Fill out our small online questionaire and we'll show yo= u how.

Get the house/home and/or car you always wanted, it only takes 10 seconds = of your time: Secure On= line-Form 9965

Regards,
Armelle Imelda

-----443267762208170078058----- --081202546468647836-- From eap-admin@frascone.com Tue Nov 30 22:26:10 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19970 for ; Tue, 30 Nov 2004 22:26:09 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 20E0A1FE3C; Tue, 30 Nov 2004 22:26:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8C0062022B; Tue, 30 Nov 2004 22:26:03 -0500 (EST) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EA6E31FE2D for ; Tue, 30 Nov 2004 22:25:29 -0500 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by mail.frascone.com (Postfix) with ESMTP id 62AC61FDF6 for ; Tue, 30 Nov 2004 22:25:28 -0500 (EST) Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.42) id 1CZL7O-00060A-S2 for eap@frascone.com; Tue, 30 Nov 2004 22:25:26 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id iB13PP103809 for ; Tue, 30 Nov 2004 19:25:25 -0800 From: Bernard Aboba To: eap@frascone.com In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: Issue 281: Backward compatibility problem 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, 30 Nov 2004 19:25:25 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) I have now captured a trace of an Access Point using a NULL character within the EAP-Request/Identity. The dump below is in hex, the decode is in decimal. A JPG screen capture (from Airopeek) is available at: http://www.drizzle.com/~aboba/EAP/eapreq.jpg 01 37 00 36 01 00 6E 65 74 77 6F 72 .7.6..networ 6B 69 64 3D 4D 53 46 54 57 4C 41 4E 2C 6E 61 73 kid=MSFTWLAN,nas 69 64 3D 43 55 53 52 45 44 30 34 30 43 33 34 32 id=CUSRED040C342 30 2C 70 6F 72 74 69 64 3D 30 00 00 00 00 0,portid=0 Here is a decode of the above EAP packet: Code: 1 (Request, one octet) Identifier: 55 (one octet) Length: 54 (two octets) Type: 1 (Identity, one octet) Type-Data: NULL (one octet) networkid=MSFTWLAN,nasid=CUSRED040C3420,portid=0 NULLs (4 octets) There are a number of issues brought up by this trace: a. Existing implementations place data after the NULL character within the EAP-Request/Identity packet. b. There can be multiple NULL characters in the EAP-Request/Identity packet. In this particular trace, there is one at the beginning of the Type-Data field, and four NULLs at the end. c. Existing access points place the networkid string first in the packet, with the nasid and portid strings second and third. d. A comma is used as a field separator. As a result it would seem to me that this specification cannot require that the NAIRealms string be placed first in the list; an arbitrary series of other strings, separated by "," could be placed prior to NAIRealms. Also, Section 2.1 is not correct. On Tue, 16 Nov 2004, Bernard Aboba wrote: > Issue 281: Backward compatibility problem > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: 11/16/2004 > Reference: > Document: IDSEL-05 > Comment type: T > Priority: S > Section: 2.1 > Rationale/Explanation of issue > > I think that there is a problem with the ABNF defined in Section 2.1. > > identity-request-data = [ displayable-string ] > [ %x00 "NAIRealms=" realm-list ] > displayable-string = *OCTET > realm-list = realm / > ( realm-list ";" realm ) > Section 2.1 states: > > "Some existing systems are known to use EAP Identity/Request messages > to send proprietary information to the peer. This proprietary > information is considered to be part of the displayable-string in the > ABNF shown above. In other words, the NUL character followed by the > NAIRealms list MUST be placed at the end." > > Actually, existing implementations send information such as the > NAS-Identity *after* the NUL character. Requiring the NAIRealms list to be > sent first is therefore not backward compatible with existing > implementations. > > I'd suggest that you need to change the ABNF to enable the NAI-Realms > attribute to be separated from the NUL character by text other than the attribute > separator used by existing implementations. > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap