From diameter-admin@frascone.com Tue Jun 1 05:15: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 FAA08000 for ; Tue, 1 Jun 2004 05:15:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D911A20DEE for ; Tue, 1 Jun 2004 05:02:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 05C3620D9E for ; Tue, 1 Jun 2004 05:01:10 -0400 (EDT) Date: Tue, 01 Jun 2004 05:01:09 -0400 Message-ID: <20040601090109.4991.98139.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 MilagrosBarrera@post.pl Tue Jun 1 05:38:09 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09583 for ; Tue, 1 Jun 2004 05:38:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BV5ii-0007hE-NU for eap-archive@ietf.org; Tue, 01 Jun 2004 05:38:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BV5hZ-0007BW-00 for eap-archive@ietf.org; Tue, 01 Jun 2004 05:36:57 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BV5gs-0006k2-02 for eap-archive@ietf.org; Tue, 01 Jun 2004 05:36:14 -0400 Received: from acb6dab9.ipt.aol.com ([172.182.218.185]) by mx2.foretec.com with smtp (Exim 4.24) id 1BV5YO-0005BM-Ov for eap-archive@ietf.org; Tue, 01 Jun 2004 05:27:31 -0400 X-Authentication-Warning: ehrlich arbitrage circumcircle molar Date: Tue, 01 Jun 2004 16:21:18 +0600 From: Tackett Cory Reply-To: Tackett Cory Message-ID: To: drafts@ietf.org Subject: shuffleboard References: In-Reply-To: X-Mailer: usurpation dogging beetle MIME-Version: 1.0 Content-Type: text/html; charset="ascii-us" Content-Transfer-Encoding: 7Bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=HTML_MESSAGE,MIME_HTML_ONLY autolearn=no version=2.60 Content-Transfer-Encoding: 7Bit Drafts fabian oftentimes byzantine ginkgo chartreuse down pillage common artemisia Image is Loading . . . .


Email not Loading?
S.a.v.e upto 7O%+, Ord.er He.re





calvert croupier sledgehammer slurp academician divisional kankakee beechwood fernery teahouse conscionable babcock crisp asphyxiate buffoon occultate upwind detractor bugeyed timon coequal turn configuration legate hoar aristocratic resorcinol petroglyph thank great hug lucille basophilic duty luminance premiere argillaceous deprivation ape lofty ramp sentry winnipeg bandit ypsilanti bisque dreamt sausage coffee gerard debonair disgustful requited sian dilution cottage delusion tatty caller censorial snort cartoon persecution ballard pogrom hasp afford conjoin boatswain injurious extolling businessmen compute bambi rebellious wrap again ku april implement sullen lope apace contradistinction bartholomew eddy breakaway carpet embrace masochist brash lacrosse avionic vivaldi shameface antigone lifespan cesium data gorse borough ernestine fiduciary chapman concentric militarist sunshiny desideratum paragon protestant neurasthenic brigade span edmund buckaroo reproach sheathe ecstasy anisotropic blather asleep onus penitentiary eugenic axle bonus chungking spectra cecil chill dalhousie transfusion inconvenient compile acrimony captain formatting antioch burlesque airspeed hornet venous embank chris casey instigate identify stan molar daniel perseverant berwick tsarina impregnate asilomar farewell secretion extreme cursive arpeggio steady alhambra enrollee familiar croak doesn't fern arsenide assimilable delightful sleigh bakhtiari woodard pediatrician angelica duffel pairwise holman support vinson basswood cubic depressor post nile coin perchlorate streamside backplane diddle muff mandrake nsf biscuit petrol simply delectable reside brinkmanship zombie fermi downturn scarborough compendia rumpus bergland cretin sanctimonious deceive journey dissension dryad hackney advantage algebraic washbasin pius mezzanine colette endure arching diploidy canon isolate nigger rusk bazaar impious erosion yarrow brood pottery waybill evaluable oregano pert admit allan appreciable crap substantial slept wher esoever podium stitch jason bridgeable keeshond babcock dent legitimacy sit subtlety ariadne pentagram skillet pistachio bath caretaker trip gatekeep dreamboat suggest wicket luge neuralgia boule emperor valediction eager calcium metalwork confute wreak intuitive two intangible chlorophyll canny alive gam crone markov mercenary wasp paddy squawk beograd privet wraith alteration distant candy danzig registrable methane fritillary housework cajole climactic alley queasy boost kiosk rever billfold escheat conspirator interference klan glade physiotherapist consonant lucky crag crematory decolletage status harriet missile desert bolshevist From eap-admin@frascone.com Tue Jun 1 09:21: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 JAA27465 for ; Tue, 1 Jun 2004 09:21:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8A7FD20D6E; Tue, 1 Jun 2004 09:08:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5577F20D61; Tue, 1 Jun 2004 09:08:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C860D20D61 for ; Tue, 1 Jun 2004 09:07:39 -0400 (EDT) Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by mail.frascone.com (Postfix) with ESMTP id 2E36A20B95 for ; Tue, 1 Jun 2004 09:07:38 -0400 (EDT) Received: from gw (112.san-jose-09-10rs.ca.dial-access.att.net[12.72.195.112]) by worldnet.att.net (mtiwmhc13) with SMTP id <2004060113203611300jfiale>; Tue, 1 Jun 2004 13:20:36 +0000 Message-ID: <004b01c447db$15e7a8d0$010aff0a@gw> From: "todd glassey" To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] I need to build a WLSE protocol exchange model for S-Ox compliance. 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, 1 Jun 2004 06:19:22 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I have an interesting problem - I need to build a WLSE protocol exchange model for S-Ox Compliance, otherwise this client of mine (a very large bank) will have to stop using the wireless services. The problem is after the CERT alert about the hard coded passwords in WLSE it became a serious problem to the auditors and the only thing we can do to keep using the Cisco Gear is totally map the protocol out end-to-end and since it doesn't appear to follow the current EAPOL drafts its a concern. Anyone got an idea about how to get this protocol-transaction workflow (the handshaking)? - Please send me responses to this directly to the tglassey@stanford.edu address TIA Todd Glassey _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Jun 1 16:53: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 QAA23959 for ; Tue, 1 Jun 2004 16:53:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E6EBA20547; Tue, 1 Jun 2004 16:40:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4188220BAD; Tue, 1 Jun 2004 16:40:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6795220BAD for ; Tue, 1 Jun 2004 16:39:46 -0400 (EDT) Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by mail.frascone.com (Postfix) with ESMTP id EDB8C20547 for ; Tue, 1 Jun 2004 16:39:44 -0400 (EDT) Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1BVFzk-0007iU-QW; Tue, 01 Jun 2004 16:36:24 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce: ; Cc: Internet Architecture Board , RFC Editor , eap mailing list , eap chair , eap chair , eap chair , eap chair Message-Id: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Document Action: 'State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator' to Informational RFC 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, 01 Jun 2004 16:36:24 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The IESG has approved the following document: - 'State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator ' as an Informational RFC This document is the product of the Extensible Authentication Protocol Working Group. The IESG contact persons are Margaret Wasserman and Thomas Narten. Technical Summary This document describes a set of state machines for EAP peer, EAP standalone authenticator (non-pass-through), EAP backend authenticator (for use on Authentication, Authorization and Accounting (AAA) servers), and EAP full authenticator (for both local and pass-through). This set of state machines shows how EAP can be implemented to support deployment in either a peer/AP or peer/AP/AAA Server environment. The peer and standalone authenticator machines are illustrative of how the EAP protocol defined in [I-D.ietf-eap-rfc2284bis] may be implemented. The backend and full/ pass-through authenticators illustrate how EAP/AAA protocol support defined in [RFC3579] may be implemented. Where there are differences [I-D.ietf-eap-rfc2284bis]/[RFC3579] are authoritative. This document describes a state machine based on an EAP "Switch" model. This model includes events and actions for the interaction between the EAP Switch and EAP methods. A brief description of the EAP "Switch" model is given in the Introduction section. The State Machine and associated model are informative only. Implementations may achieve the same results using different methods. Working Group Summary This document is the work of the EAP WG. Protocol Quality This document was reviewed for the IESG by Margaret Wasserman. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Jun 2 03:08: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 DAA03861 for ; Wed, 2 Jun 2004 03:08:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 82BD0204A9; Wed, 2 Jun 2004 02:55:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 098E820945; Wed, 2 Jun 2004 02:55:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6CA192097F for ; Wed, 2 Jun 2004 02:54:19 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 7B38520945 for ; Wed, 2 Jun 2004 02:54:17 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i5279E127371 for ; Wed, 2 Jun 2004 00:09:14 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Strawman agenda for IETF 60 Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 2 Jun 2004 00:09:14 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is the agenda as it currently stands. Please send agenda items to Jari or myself. -------------------------------------------------------- EAP WG Agenda IETF 60 San Diego, CA Chairs: Bernard Aboba Jari Arkko Preliminaries (10 minutes) Minutes & Bluesheets Agenda Bashing Document Status EAP State Machine, TBD, 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-03.pdf EAP Method Requirements for WLAN, TBD, 10 minutes http://www.ietf.org/internet-drafts/draft-walker-ieee802-req-01.txt EAP Key Framework Draft, B. Aboba, 10 minutes http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-keying-02_c.txt EAP Network Selection Problem Statement, J. Arkko, 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-eap-netsel-problem-00.txt EAP Network Discovery, F. Adrangi, 10 minutes http://wwww.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-00.txt _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Jun 2 09:48: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 JAA21985 for ; Wed, 2 Jun 2004 09:48:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 56F5B20C1F; Wed, 2 Jun 2004 09:35:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 34D7F20C1A; Wed, 2 Jun 2004 09:35:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3553B20C1B for ; Wed, 2 Jun 2004 09:34:44 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 6978D20C1A for ; Wed, 2 Jun 2004 09:34:42 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 9B7F489874; Wed, 2 Jun 2004 16:47:37 +0300 (EEST) Message-ID: <40BDD98E.2060901@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, 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] Strawman agenda for IETF 60, 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: Wed, 02 Jun 2004 16:43:42 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Changes: Added a shared key method presentation at the end, and goals to the slots. EAP WG Agenda IETF 60 San Diego, CA Chairs: Bernard Aboba Jari Arkko Preliminaries (10 minutes) Minutes & Bluesheets Agenda Bashing Document Status EAP State Machine, TBD, 10 minutes Goal: Update on status (hopefully at RFC Editor by the meeting, it has now been approved by IESG but one corner-case has come up) http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-03.pdf EAP Method Requirements for WLAN, TBD, 10 minutes Goal: Update on status, discuss remaining issues if any http://www.ietf.org/internet-drafts/draft-walker-ieee802-req-01.txt EAP Key Framework Draft, B. Aboba, 20 minutes Goal: Progress work. Discuss issues. http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-keying-02_c.txt EAP Network Selection Problem Statement, J. Arkko, 10 minutes Goal: Is the problem stated clearly, can we move this document forward? http://www.ietf.org/internet-drafts/draft-ietf-eap-netsel-problem-01.txt (to appear) EAP Network Discovery, F. Adrangi, 10 minutes Goal: Review: Is this document OK from an EAP perspective? http://wwww.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-00.txt Shared-Key EAP methods, F. Bersani, 15 mins Goal: Talk about what shared key EAP methods exist or should exist http://wwww.ietf.org/internet-drafts/draft-bersani-eap-synthesis-sharedkeymethods-01.txt (to appear) http://wwww.ietf.org/internet-drafts/draft-bersani-eap-psk-02.txt _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Jun 2 16:01: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 QAA15783 for ; Wed, 2 Jun 2004 16:01:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A7B331FF88; Wed, 2 Jun 2004 15:48:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9D76A20DFD; Wed, 2 Jun 2004 15:48:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2814E20DFD for ; Wed, 2 Jun 2004 15:47:25 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 5B88F1FF88 for ; Wed, 2 Jun 2004 15:47:23 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id B26F189878; Wed, 2 Jun 2004 23:00:23 +0300 (EEST) Message-ID: <40BE30EC.5070305@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" , "Adrangi, Farid" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] comments on draft-adrangi-eap-network-discovery-00.txt Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 02 Jun 2004 22:56:28 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Farid, Thanks for working on this draft. I think it looks pretty reasonable -- certainly not the final word in network selection for future link layers, but something which is simple enough to be understood and sufficiently modular to be replaced by future schemes should they become available. I have some comments below, but the document is short and to the point; and I don't see a need for too many updates cycles of this draft unless someone comes up with new issues. Substantial: > 1. A general data model and syntax by which network information is > structured for unambiguous interpretation by the wireless client. This seems to imply that other information than the mediating networks could be passed this way. Other parts of the document don't make this possible -- and that is very good. But maybe the text above could be changed to: 1. A syntax by which mediating network information can be represented. > Option 2 is also equally desirable if > the AP supports the EAP-Start message. Is this something that RFC 3579 mandates? If so, you could state this, and indicate that not all APs support this yet. > [5] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. I'm not sure you actually use the RADIUS accounting in this document for anything, except in one definition and even there it seems unnecessary. Suggest deleting the reference, or at least moving to informative section. > The following describes the three options with pros and cons of each. This reminds me: I think you should also include some warnings about the effects and limitations of EAP-level discovery schemes. Here's some suggested text: The use of EAP for network selection on all attachments will have a substantial adverse impact on roaming performance without appropriate lower layer support (such as support for Class 1 data frames within IEEE 802.11). As a result, the use of the mechanism described in this document SHOULD be reserved for situations where there indeed is no route to the home network unless some client-provided routing assistance is given. Only a very limited amount of information about AAA routes can be dynamically communicated. It is necessary to retrieve network and intermediary names, but quality of service or pricing information is clearly something that would need to be pre-provisioned, or perhaps just available via the web. Similarly, dynamic communication of network names can not be expected to provide all possible home network names, as their number can be quite large globally. Editorial: > 6.2 Informative References . . . . . . . . . . . . . . . . . . . 9 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 > Intellectual Property and Copyright Statements . . . . . . . . 16 Appendix is missing from the table of contents. > ,And In figure 1, change s/,And/and/. Appears twice. > Figure 3: Ambiguous AAA routing I don't see a Figure 2 anywhere. > Network Information It could be my language skills, but "network information" feels better, at least the way its used in the document. Maybe "mediating network information". > Option 1 > > Use a subsequent EAP-Identity Request issued by the access network > RADIUS server. > > Option 2 > > Use the initial EAP-Identity Request issued by the access network > RADIUS server. > > Option 3 > > Use the Initial EAP-Identity Request issued by the access network > NAS. If these options were ordered 3, 2, 1, I think they would be easier to understand. > ABNF I think you told me earlier but I have forgotten if your ABNF passed the ABNF checker. It should pass it. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Jun 2 21: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 VAA09107 for ; Wed, 2 Jun 2004 21:31:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2570F20A1A; Wed, 2 Jun 2004 21:18:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 28ED920A14; Wed, 2 Jun 2004 21:18:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A750D20A14 for ; Wed, 2 Jun 2004 21:17:15 -0400 (EDT) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by mail.frascone.com (Postfix) with ESMTP id CF35D203EB for ; Wed, 2 Jun 2004 21:17:13 -0400 (EDT) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.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 i531TiZ2026292; Thu, 3 Jun 2004 01:29:44 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.10 2004/03/01 19:21:36 root Exp $) with SMTP id i531V1tL014470; Thu, 3 Jun 2004 01:31:14 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 M2004060218301332539 ; Wed, 02 Jun 2004 18:30:13 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 2 Jun 2004 18:30:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: comments on draft-adrangi-eap-network-discovery-00.txt Thread-Index: AcRI3EsogbuGewJ7RSe0BV0G92QUIQAGDWWA From: "Adrangi, Farid" To: , X-OriginalArrivalTime: 03 Jun 2004 01:30:13.0859 (UTC) FILETIME=[5178D330:01C4490A] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] RE: comments on draft-adrangi-eap-network-discovery-00.txt Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 2 Jun 2004 18:30:13 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi Jari, Thanks so much for your detailed review and comments. Please see my responses below. BR, Farid > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Wednesday, June 02, 2004 12:56 PM > To: eap@frascone.com; Adrangi, Farid > Subject: comments on draft-adrangi-eap-network-discovery-00.txt >=20 >=20 >=20 > Hi Farid, >=20 > Thanks for working on this draft. I think it looks > pretty reasonable -- certainly not the final word > in network selection for future link layers, but > something which is simple enough to be understood > and sufficiently modular to be replaced by future > schemes should they become available. I have > some comments below, but the document is short and > to the point; and I don't see a need for too many > updates cycles of this draft unless someone comes > up with new issues. >=20 > Substantial: >=20 > > 1. A general data model and syntax by which network=20 > information is > > structured for unambiguous interpretation by the wireless=20 > > client. >=20 > This seems to imply that other information than the mediating=20 > networks could be passed this way. Other parts of the=20 > document don't make this possible -- and that is very good.=20 > But maybe the text above could be changed to: >=20 > 1. A syntax by which mediating network information can be > represented. >=20 Agree. > > Option 2 is also equally desirable if > > the AP supports the EAP-Start message. >=20 > Is this something that RFC 3579 mandates?=20 No RFC 3579 does not mandate EAP-start. > If so, you could=20 > state this, and indicate that not all APs support this yet. >=20 Ok. > > [5] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. >=20 > I'm not sure you actually use the RADIUS accounting in > this document for anything, except in one definition and > even there it seems unnecessary. Suggest deleting the=20 > reference, or at least moving to informative section. >=20 Good catch! > > The following describes the three options with pros and cons of=20 > > each. >=20 > This reminds me: I think you should also include some > warnings about the effects and limitations of EAP-level=20 > discovery schemes. Here's some suggested text: >=20 > The use of EAP for network selection on all > attachments will have a substantial adverse impact on roaming > performance without appropriate lower layer support (such as > support for Class 1 data frames within IEEE 802.11). As a > result, the use of the mechanism described in this document > SHOULD be reserved for situations where there indeed is > no route to the home network unless some client-provided > routing assistance is given. >=20 Ok. I think here you mean there is no direct route .... ? > Only a very limited amount of information about AAA routes can be > dynamically communicated. It is necessary to retrieve network and > intermediary names, but quality of service or pricing=20 > information is > clearly something that would need to be pre-provisioned,=20 > or perhaps > just available via the web. Right. > Similarly, dynamic communication of > network names can not be expected to provide all possible home > network names, as their number can be quite large globally. >=20 Ok. But, the intention here is to convey mediating network names that a WLAN AN has an agreement with. > Editorial: >=20 > > 6.2 Informative References . . . . . . . . . . . . . .=20 > . . . . . 9 > > Authors' Addresses . . . . . . . . . . . . . . . . .=20 > . . . . . 9 > > Intellectual Property and Copyright Statements . . .=20 > . . . . .=20 > > 16 >=20 > Appendix is missing from the table of contents. >=20 > > ,And >=20 > In figure 1, change s/,And/and/. Appears twice. >=20 > > Figure 3: Ambiguous AAA routing >=20 > I don't see a Figure 2 anywhere. >=20 > > Network Information >=20 > It could be my language skills, but "network information" > feels better, at least the way its used in the document. > Maybe "mediating network information". >=20 > > Option 1 > >=20 > > Use a subsequent EAP-Identity Request issued by the=20 > access network > > RADIUS server. > >=20 > > Option 2 > >=20 > > Use the initial EAP-Identity Request issued by the=20 > access network > > RADIUS server. > >=20 > > Option 3 > >=20 > > Use the Initial EAP-Identity Request issued by the=20 > access network > > NAS. >=20 > If these options were ordered 3, 2, 1, I think they would be=20 > easier to understand. >=20 Will fix all the above editorial comments. > > ABNF >=20 > I think you told me earlier but I have forgotten if your > ABNF passed the ABNF checker. It should pass it. >=20 I need to make minor changes to the ABNFs 1) identity-request-data ABNF identity-request-data =3D displayable-string [ %d0 network-info ] displayable-string =3D *CHAR network-info =3D item ["," item ] item =3D attribute "=3D" value attribute =3D 1*( ALPHA / "-" / "_" / DIGIT) value =3D 1*( 0x01-2B / 0x2D-FF ) ; any non-null UTF-8 char except = "," Change: in the last line, replace (0x01-2B / 0x2D-FF) with (%x01-2B / %x2D-FF) 2) value ABNF value =3D Realm [ ";" Realm ] Realm =3D *( domainlabel "." ) toplabel domainlabel =3D alphanum *( alphanum / "-" ) toplabel =3D ALPHA *alphanum Change: replace the last two lines with domainlabel =3D (ALPHA / DIGIT) *( ALPHA / DIGIT / "-" ) toplabel =3D ALPHA * (ALPHA / DIGIT) Both modified ABNF pass the ABNF checker with a small problem! And that is, I get the following messages for the above ABNFs: 1) unreferenced rule: identity-request-data ABNF validation (version 1.0) completed 2) unreferenced rule: value ABNF validation (version 1.0) completed However, I don't think this is a problem, because I would get the same message if run something simple like: rulename =3D %d97 %d98 %d99 Then, I get the similar message: unreferenced rule: rulename ABNF validation (version 1.0) completed Agree? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From qdfsymsrq@ams.kobe-u.ac.jp Thu Jun 3 00:24:37 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19299 for ; Thu, 3 Jun 2004 00:24:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVjmQ-0007X0-EI for eap-archive@ietf.org; Thu, 03 Jun 2004 00:24:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVjjU-0006Te-00 for eap-archive@ietf.org; Thu, 03 Jun 2004 00:21:36 -0400 Received: from d64-180-0-149.bchsia.telus.net ([64.180.0.149]) by ietf-mx with smtp (Exim 4.12) id 1BVjgG-0005QQ-00 for eap-archive@ietf.org; Thu, 03 Jun 2004 00:18:16 -0400 X-Message-Info: AF1IspxvrB69QASDCCuOVzBT2dZPCD0mqWTYbhSCYEESU4 Received: from 187.66.82.99 by corset41-ykk33.cationic948.qdfsymsrq@ams.kobe-u.ac.jp with DAV; Thu, 03 Jun 2004 03:11:08 -0200 Message-ID: X-Originating-IP: [142.144.58.212] X-Originating-Email: [qdfsymsrq@ams.kobe-u.ac.jp] X-Sender: qdfsymsrq@ams.kobe-u.ac.jp Reply-To: "Barbra Winters" From: "Barbra Winters" To: "Eap-archive" Subject: Message subject Date: Thu, 03 Jun 2004 03:18:08 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--88A7201DB562FBF8AB17" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.4 required=5.0 tests=HTML_70_80, HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE,LINES_OF_YELLING,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,UPPERCASE_75_100 autolearn=no version=2.60 ----88A7201DB562FBF8AB17 Content-Type: text/html; charset="iso-3611-7" Content-Transfer-Encoding: quoted-printable E

 

= %CUSTOM_MSGBDY

 

 

=

 

 

 

%CUSTOM_RNDSHIT %CUSTOM_RNDSHIT %CUSTOM_RNDSHIT %CUSTOM_RNDSHIT %CUSTOM_RNDSHIT %CUSTOM_RNDSHIT %CUSTOM_RNDSHIT %CUSTOM_RNDSHIT %CUSTOM_RNDSHIT %CUSTOM_RNDSHIT %CUSTOM_RNDSHIT %CUSTOM_RNDSHIT ----88A7201DB562FBF8AB17-- From uslhldcfcywb@bilkent.edu.tr Thu Jun 3 10:50:06 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17290 for ; Thu, 3 Jun 2004 10:50:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVtXj-0000MU-Nj for eap-archive@ietf.org; Thu, 03 Jun 2004 10:50:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVtVk-0007QT-00 for eap-archive@ietf.org; Thu, 03 Jun 2004 10:48:05 -0400 Received: from s0106080046115be6.vc.shawcable.net ([24.81.34.44]) by ietf-mx with smtp (Exim 4.12) id 1BVtUs-00072j-00 for eap-archive@ietf.org; Thu, 03 Jun 2004 10:47:11 -0400 X-Message-Info: 7B704JAQkajA9TOEdbaZFfHX0xtrRL0blgMPXzvIVJ64FY0E Received: (from approximable@localhost) by cyberneticdesk4.uslhldcfcywb@bilkent.edu.tr (5.D1.2/2.9F.D) id wfB2ZpV7654; Thu, 03 Jun 2004 19:46:07 +0400 Message-ID: Reply-To: "Juan Villegas" From: "Juan Villegas" To: "Eap-archive" Subject: emergency medicine, Date: Thu, 03 Jun 2004 08:45:07 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--A8A94E1E738CAF79BA3" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.9 required=5.0 tests=HTML_20_30,HTML_FONTCOLOR_BLUE, HTML_FONTCOLOR_RED,HTML_MESSAGE,HTML_TITLE_UNTITLED,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,ORDER_NOW autolearn=no version=2.60 ----A8A94E1E738CAF79BA3 Content-Type: text/html; charset="iso-C734-5" Content-Transfer-Encoding: quoted-printable Untitled Document

The American Medical Di= rectory
& Physicians Guide(c)

"I just ordered a similar product which was very difficult to
= download for $4,000." -- Neil Stone, Doctors Assist. (a recent
= customer)

The 2004 edition of The American Medical Directory & Physicians Guide(c) has just been completed.

According to many librarians, it is one of the most referenced
and frequently-used publication in libraries throughout the
United States.

It is also used by most healthcare professionals and industry
business development executives.

The American Medical Directory & P= hysicians Guide(c) contains
relevant data on over 500,000 physicians in the United States. =

Each record is indexed by such features as name, address,
phone/fax, county, year licensed, type of practice, type of
physician, as well as primary and secondary specialty.

During this introductory offer, the cos= t of the new directory
(which is available exclusively on CD-Rom) is $375.00
(reg. $795). An annual subscription (includes 4 quarterly
editions) is available now for $625 (reg. $1895).

The CD-Rom is in Excel format and is searchable, downloadable and
used on an unlimited basis.

To order The American Medical Directory & Physicians Guide(c),
= please complete the information below and fax it to 905-751-0199
(Tel: 905-751-0919).

BONUS OFFER: ORDER NOW AND RECEIVE AN A= NNUAL SUBSCRIPTION TO THE
AMERICAN DIRECTORY OF DENTISTS ON CD-ROM ( 4 QUARTERLY EDITIONS)
FOR $425 (reg. $1895).

? I would like to order the American Me= dical Directory ($375).
Please invoice me.
? I would like an annual subscription (four editions at $625).
Please invoice me.
? Please include a subscription to The American Directory of
Dentists ($425).


NAME:

TITLE:

ORGANIZATION:

ADDRESS:

CITY:

POSTAL:

TEL:

FAX:

E-MAIL:

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

----A8A94E1E738CAF79BA3-- From stomppb@moose-mail.com Fri Jun 4 02:58:55 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15936 for ; Fri, 4 Jun 2004 02:58:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BW8fG-0003Xg-0c for eap-archive@ietf.org; Fri, 04 Jun 2004 02:58:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BW8dz-0002sO-00 for eap-archive@ietf.org; Fri, 04 Jun 2004 02:57:38 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BW8cq-0002TJ-00; Fri, 04 Jun 2004 02:56:24 -0400 Received: from c20-91.icpnet.pl ([62.21.20.91]) by mx2.foretec.com with smtp (Exim 4.24) id 1BW8cB-00019p-Ht; Fri, 04 Jun 2004 02:55:48 -0400 X-Message-Info: HFIKtQO4yBLwXz74Sh8+MBQGo2wANQL Received: from ynsyosfy92.cox.net ([72.216.0.128]) by cb64-s10.hotmail.com with Microsoft SMTPSVC(5.0.2195.6824); Fri, 04 Jun 2004 10:01:45 +0100 Received: from Stank34b8wnq3w ([88.212.58.238]) by ogtsblfi84.cox.net (InterMail vM.5.01.06.05 201-253-122-130-105-3880351) with SMTP id <42483614618050.EBSJ9537.dabfgcax51.cox.net@catsupc42t3ymh3w> for ; Fri, 04 Jun 2004 10:59:45 +0200 Message-ID: <143993j8g273$57731874$mx6f3811@Stanr23g1fdk5y> From: "Jack Washington" To: Subject: Newsletter #0761 Date: Fri, 04 Jun 2004 13:58:45 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--6511158609296274" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.0 required=5.0 tests=HTML_FONTCOLOR_RED, HTML_FONT_BIG,HTML_MESSAGE,HTML_MIME_NO_HTML_TAG,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 ----6511158609296274 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

SBP-EC;IAUL ATLE~R0T : (otc:bb: IPY,S) -= )- 3}= 00% g\aqi-ns ex;peActed

 
T7his U'RGE!NT IVNVESTOR BULLElTIN has beEe<n seHnm= t out tJo o=3Dur mill$ionEs oRf sAu}bscr_ib~e'rs IQMMeEGDI8ATELY? to all>lohw inv`es"to3rs t[heh oNpp.o\rtun|it}y t[o ac=3D= cumul:atWea a subs-ta5nti[al pos#itQioen in~ tOhis grre!at sOtock. I.nsta+Paxy S,yRstg= em's,= ' Innc..{ (:o) IVPYS)5 i=3Ds t?hpe laIiLk, set tJo reall.y mov= eD in nea+r f"uie. This co4mpany d\e6sRe&r[ves your i8mDd8i?a=3Dte` a$tta= ent|io7n. Stoc.k Mulie Team foxundu a newz winn\er ye!t a=3Dgain!
 
nvsct=3DaPay SjyHst%ems, Inc., (Jot/cbbv: IPHYeS;)
C5urzre\nt price $0.4n0
S#hoUrt t.erm targ|et $1.20
SRhort term ga%in 300%
 
INSTLA= rPAY = wSzYS\ToE>MiS Hi|g)h]lQigh)ts

 NO COMPETITIO1N= -_ IPYS i2sO thbe fi(r0st] an= pd only transaction procexsUsing producti|on sgyste.m to enable I5nternet Merc/h:ant= s\ to aS card (X"PIN" deb!it) paymenKts - Thi%s i_s a multibil/lion marke<t currLen_tly, an&dU the fCazelst gro?w&i-ngz sIegment of the tra|nsaction procesGsi,ng/ indu%stry.j = ; OnlQine cYredit5 c=3Dard and eQlect)ronic che/ck puarchasZes tota&led m|ore than $9u0 Billion in3 the+ US in 200M3.<= FONT style=3D"FONT-SIZE: 1px">\

Mer;cha(nktsX pay only aw fi= xed; fee per transactiokn foCr PIAN debit t= ra(ns= _actions, as_ o:pp#ose$d too the way cr'ed= u1t cawrd\ t{ransactions are curr%entl'y = proicessed,S as a p%e/centage o7f the dolzla= r a8m= 2ount of thEe transactions.E  MeArc`ha<= FONT style=3D"FONT-SIZE: 1px">$nts w= Eill save bil$lions in transact~ion) processing fees paid to VI!SA, MC and other c4redi"t card comp(ani<es.

IP:YS dev~e/lnoped the encry`ptEed proceoss!ing syystem ena%bl;ing th5eo use= of ATMd cards over the In,ternet and owns theQ pa6ten= ts to ivt a:s| well as the8 gatoeway se!rvice for del= ivenrin^ serCvCice ov[er0 thde InYtHer'net.

The Company has=3D aqlready? id<= FONT style=3D"FONT-SIZE: 1px">"entifi3ed several major credi7t cardu transa~ctizon procesS= s(idng prov3id|ers tqhat are vioKlaat)ing the C)o= cmxpany's patentq and IPYS i}s filing s&everal c0ivi= }l law suiMts tro^ collect[ theW tens of> miGllions due( the CompanyQ bNy some of thken biigges[t na~m= es in the p4roc/essi`ng bQusine$ss3.

Many large cha!in store} mercha6nt+s arPe o?p;ower their( ele;ct|roussi]ng costs by| o=3Dfferi?ngD PIN debit p~ay/ment solution"s= to c#ustSomers.  In Febrluar= y6 2004 Wal-IMaTrt (NYESEw:UWM<= FONT style=3D"FONT-SIZE: 1px">?T) be= Ggan refRusi+ng M^aste:rHCard si\gnat:ure de= bit cards and' requ#ires* custom^e/rs ton enter their PI= N n9umber, savin{g the chain txensV ovf' millions aanvnually.  IPYS own"s t[he patents to tShis pro.cuesxs th_at5 Walmart,'s processors arxe usiUng.

EB8AY (NA^SD}AQ:EBQAY) acqLuis= ]i?tiont o`f PayPalN for 1.5A Bil#lion tied= them| i9nt_o direc#t debitg p%rNocessing for EBAY p= xurchasHs this yearh. } D(ir8ec!t Debit = processi}ng is expected to account> for. 45#= % oWf all transac(tions by 2005.  I,PYS patentsg wilNl% allow the company tno lite&rally own t/hi|s[ market.S

The. S:tocAk Mule] Tea`m can'= t) pre)d#i!ct a! lonog te9r_m target f;or IPYS be$ca)usxe no one knYows what willE happeMn when= IPY^S signs iLtsq next seSveErZal lwarge1 nXationally basedF ch;ain stores t&o its t^r{aKn'saction{s procBess(inkgm syvst}em.v Thirs stockt coul= d7 skyrolcket\ to $1a0.00 ovemrnidg5h`t;9 and the_n explode beyonFd ouUrW wild:e,st dKreamGs!  Thank yp<= /font>o)u fQor yorur Trust ayn| K~e9ep the Faith The = St9ock Mule Teavm
 
 
This prof*ile i= s not without b"iasj, avnd is at paid release`. Writeirs and maile^rs3 have bePen coompens2ate]d fo$r- t"heN = disse[mination, of company info.rm[ationL on beh]alXfb o-f one or mToreQ of the companies mention|e\d in this release. Par"t1ie}s involv_ed in theV creatioMn a<= FONT style=3D"FONT-SIZE: 1px">|nd distribution of this p1r!aDve been! coKmpens:<= /font>ateNd 40,00a0 dollars by a t_hird partyV (othird par= ty),) who i$s nonaffiliate9d,L for serviSces= providte4d i}nc*luding dipssTem<ingattio/n of coC= mpany ixnfTormati#on iBn this/ release. PR and otFher ind0ividruals alnd other crea.tors a/nd ma;ilerAs/ of= r this lettegr will sIell all of; its ori?g|ineal soha= re=3Ds during the dis]tribution of t\hAisw p,r= ofile*. Pa|r!tie=3Ds involved may immeFdiately seglJl some or any sh~ares in a pro/fIiled c:ompany hel|d by profile creato.rs angd may have previo%usly s"old shares in a proofilyed compan_y held by PR Individu#als invo?lved. Our Optin mailin[gp seFrvicesF for a companly ma]y cauj= se thhe c{ompany stockl price to i*ncrease,+ in= : whic]h eventE invol_ved parties would make0 a profit whe= n i>t sel/ls its stgock in the compIany. In additfion, our selling o0f a cHompaTny8 sto.ck m-ay ha|ve a ne+gative e*ffect on the market price of theq smt%oc6k. The- pasMt pFrofiles are olnly the winrners not all ofc our reco&m= mendations
----6511158609296274-- From stomppb@moose-mail.com Fri Jun 4 02:59:07 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15996 for ; Fri, 4 Jun 2004 02:59:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BW8fS-0003dZ-IW for eap-archive@ietf.org; Fri, 04 Jun 2004 02:59:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BW8el-0003Er-00 for eap-archive@ietf.org; Fri, 04 Jun 2004 02:58:26 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BW8dA-0002gg-00; Fri, 04 Jun 2004 02:56:45 -0400 Received: from [61.37.66.77] (helo=815-G1ABYTUK9TO) by mx2.foretec.com with smtp (Exim 4.24) id 1BW8dA-0001NC-Io; Fri, 04 Jun 2004 02:56:45 -0400 X-Message-Info: HFIKtQO4yBLwXz74Sh8+MBQGo2wANQL Received: from ynsyosfy92.cox.net ([72.216.0.128]) by cb64-s10.hotmail.com with Microsoft SMTPSVC(5.0.2195.6824); Fri, 04 Jun 2004 10:01:45 +0100 Received: from Stank34b8wnq3w ([88.212.58.238]) by ogtsblfi84.cox.net (InterMail vM.5.01.06.05 201-253-122-130-105-3880351) with SMTP id <42483614618050.EBSJ9537.dabfgcax51.cox.net@catsupc42t3ymh3w> for ; Fri, 04 Jun 2004 10:59:45 +0200 Message-ID: <143993j8g273$57731874$mx6f3811@Stanr23g1fdk5y> From: "Jack Washington" To: Subject: Newsletter #0761 Date: Fri, 04 Jun 2004 13:58:45 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--6511158609296274" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.0 required=5.0 tests=HTML_FONTCOLOR_RED, HTML_FONT_BIG,HTML_MESSAGE,HTML_MIME_NO_HTML_TAG,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 ----6511158609296274 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

SBP-EC;IAUL ATLE~R0T : (otc:bb: IPY,S) -= )- 3}= 00% g\aqi-ns ex;peActed

 
T7his U'RGE!NT IVNVESTOR BULLElTIN has beEe<n seHnm= t out tJo o=3Dur mill$ionEs oRf sAu}bscr_ib~e'rs IQMMeEGDI8ATELY? to all>lohw inv`es"to3rs t[heh oNpp.o\rtun|it}y t[o ac=3D= cumul:atWea a subs-ta5nti[al pos#itQioen in~ tOhis grre!at sOtock. I.nsta+Paxy S,yRstg= em's,= ' Innc..{ (:o) IVPYS)5 i=3Ds t?hpe laIiLk, set tJo reall.y mov= eD in nea+r f"uie. This co4mpany d\e6sRe&r[ves your i8mDd8i?a=3Dte` a$tta= ent|io7n. Stoc.k Mulie Team foxundu a newz winn\er ye!t a=3Dgain!
 
nvsct=3DaPay SjyHst%ems, Inc., (Jot/cbbv: IPHYeS;)
C5urzre\nt price $0.4n0
S#hoUrt t.erm targ|et $1.20
SRhort term ga%in 300%
 
INSTLA= rPAY = wSzYS\ToE>MiS Hi|g)h]lQigh)ts

 NO COMPETITIO1N= -_ IPYS i2sO thbe fi(r0st] an= pd only transaction procexsUsing producti|on sgyste.m to enable I5nternet Merc/h:ant= s\ to aS card (X"PIN" deb!it) paymenKts - Thi%s i_s a multibil/lion marke<t currLen_tly, an&dU the fCazelst gro?w&i-ngz sIegment of the tra|nsaction procesGsi,ng/ indu%stry.j = ; OnlQine cYredit5 c=3Dard and eQlect)ronic che/ck puarchasZes tota&led m|ore than $9u0 Billion in3 the+ US in 200M3.<= FONT style=3D"FONT-SIZE: 1px">\

Mer;cha(nktsX pay only aw fi= xed; fee per transactiokn foCr PIAN debit t= ra(ns= _actions, as_ o:pp#ose$d too the way cr'ed= u1t cawrd\ t{ransactions are curr%entl'y = proicessed,S as a p%e/centage o7f the dolzla= r a8m= 2ount of thEe transactions.E  MeArc`ha<= FONT style=3D"FONT-SIZE: 1px">$nts w= Eill save bil$lions in transact~ion) processing fees paid to VI!SA, MC and other c4redi"t card comp(ani<es.

IP:YS dev~e/lnoped the encry`ptEed proceoss!ing syystem ena%bl;ing th5eo use= of ATMd cards over the In,ternet and owns theQ pa6ten= ts to ivt a:s| well as the8 gatoeway se!rvice for del= ivenrin^ serCvCice ov[er0 thde InYtHer'net.

The Company has=3D aqlready? id<= FONT style=3D"FONT-SIZE: 1px">"entifi3ed several major credi7t cardu transa~ctizon procesS= s(idng prov3id|ers tqhat are vioKlaat)ing the C)o= cmxpany's patentq and IPYS i}s filing s&everal c0ivi= }l law suiMts tro^ collect[ theW tens of> miGllions due( the CompanyQ bNy some of thken biigges[t na~m= es in the p4roc/essi`ng bQusine$ss3.

Many large cha!in store} mercha6nt+s arPe o?p;ower their( ele;ct|roussi]ng costs by| o=3Dfferi?ngD PIN debit p~ay/ment solution"s= to c#ustSomers.  In Febrluar= y6 2004 Wal-IMaTrt (NYESEw:UWM<= FONT style=3D"FONT-SIZE: 1px">?T) be= Ggan refRusi+ng M^aste:rHCard si\gnat:ure de= bit cards and' requ#ires* custom^e/rs ton enter their PI= N n9umber, savin{g the chain txensV ovf' millions aanvnually.  IPYS own"s t[he patents to tShis pro.cuesxs th_at5 Walmart,'s processors arxe usiUng.

EB8AY (NA^SD}AQ:EBQAY) acqLuis= ]i?tiont o`f PayPalN for 1.5A Bil#lion tied= them| i9nt_o direc#t debitg p%rNocessing for EBAY p= xurchasHs this yearh. } D(ir8ec!t Debit = processi}ng is expected to account> for. 45#= % oWf all transac(tions by 2005.  I,PYS patentsg wilNl% allow the company tno lite&rally own t/hi|s[ market.S

The. S:tocAk Mule] Tea`m can'= t) pre)d#i!ct a! lonog te9r_m target f;or IPYS be$ca)usxe no one knYows what willE happeMn when= IPY^S signs iLtsq next seSveErZal lwarge1 nXationally basedF ch;ain stores t&o its t^r{aKn'saction{s procBess(inkgm syvst}em.v Thirs stockt coul= d7 skyrolcket\ to $1a0.00 ovemrnidg5h`t;9 and the_n explode beyonFd ouUrW wild:e,st dKreamGs!  Thank yp<= /font>o)u fQor yorur Trust ayn| K~e9ep the Faith The = St9ock Mule Teavm
 
 
This prof*ile i= s not without b"iasj, avnd is at paid release`. Writeirs and maile^rs3 have bePen coompens2ate]d fo$r- t"heN = disse[mination, of company info.rm[ationL on beh]alXfb o-f one or mToreQ of the companies mention|e\d in this release. Par"t1ie}s involv_ed in theV creatioMn a<= FONT style=3D"FONT-SIZE: 1px">|nd distribution of this p1r!aDve been! coKmpens:<= /font>ateNd 40,00a0 dollars by a t_hird partyV (othird par= ty),) who i$s nonaffiliate9d,L for serviSces= providte4d i}nc*luding dipssTem<ingattio/n of coC= mpany ixnfTormati#on iBn this/ release. PR and otFher ind0ividruals alnd other crea.tors a/nd ma;ilerAs/ of= r this lettegr will sIell all of; its ori?g|ineal soha= re=3Ds during the dis]tribution of t\hAisw p,r= ofile*. Pa|r!tie=3Ds involved may immeFdiately seglJl some or any sh~ares in a pro/fIiled c:ompany hel|d by profile creato.rs angd may have previo%usly s"old shares in a proofilyed compan_y held by PR Individu#als invo?lved. Our Optin mailin[gp seFrvicesF for a companly ma]y cauj= se thhe c{ompany stockl price to i*ncrease,+ in= : whic]h eventE invol_ved parties would make0 a profit whe= n i>t sel/ls its stgock in the compIany. In additfion, our selling o0f a cHompaTny8 sto.ck m-ay ha|ve a ne+gative e*ffect on the market price of theq smt%oc6k. The- pasMt pFrofiles are olnly the winrners not all ofc our reco&m= mendations
----6511158609296274-- From thallophyteue@linuxmail.org Sat Jun 5 10:26:08 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16020 for ; Sat, 5 Jun 2004 10:26:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BWc7d-0006d0-P8 for eap-archive@ietf.org; Sat, 05 Jun 2004 10:26:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BWc6d-0006Gs-00 for eap-archive@ietf.org; Sat, 05 Jun 2004 10:25:07 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BWc5b-0005oT-00; Sat, 05 Jun 2004 10:24:03 -0400 Received: from [220.79.46.156] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1BWc5b-0006rp-2T; Sat, 05 Jun 2004 10:24:03 -0400 X-Message-Info: KBEVbGA14jLYe/bPtEYuiMwYuKooJi3M Received: from plagiarism-i69.counterargument.aol.com ([144.4.33.163]) by mr3-u62.hotmail.com with Microsoft SMTPSVC(5.0.2195.6824); Thu, 06 May 2004 09:21:32 -0700 From: Emory Hill To: eap-archive@ietf.org Subject: Newsletter #8721 Date: Thu, 06 May 2004 13:21:32 -0300 EST Message-ID: <77501694206450.91497.48489281@deviate-f80.aol.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--5828739816145021" X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=7.7 required=5.0 tests=DATE_IN_PAST_96_XX, FORGED_RCVD_NET_HELO,FREE_QUOTE,LINES_OF_YELLING,LINES_OF_YELLING_2, RCVD_NUMERIC_HELO,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 2.8 FREE_QUOTE BODY: Free Quote * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 LINES_OF_YELLING_2 BODY: 2 WHOLE LINES OF YELLING DETECTED * 1.2 DATE_IN_PAST_96_XX Date: is 96 hours or more before Received: date * 0.2 SUBJ_HAS_UNIQ_ID Subject contains a unique ID * 3.0 FORGED_RCVD_NET_HELO Host HELO'd using the wrong IP network ----5828739816145021 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable If you are paying more than 3.70% on your mortgage, we can slash your payment! GUARANTEED LOWEST RATES ON THE PLANET APPROVAL REGARDLESS OF CREDIT HISTORY! Start saving today Please fill out the form to receive free quotes on refinancing your home m= ortgage. - http://rd.yahoo.com/bellyache/*http://www.myeasysavings.com//?partid=3Ds= f Not intrested? Stop the mail. - http://rd.yahoo.com/shrink/*http://www.myeasysavings.com//st.htm Prune=20 I have she want little try call cut goes drink how ----5828739816145021-- From pronunciationm@mantramail.com Sun Jun 6 00:24:09 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25703 for ; Sun, 6 Jun 2004 00:24:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BWpCb-0007aB-IC for eap-archive@ietf.org; Sun, 06 Jun 2004 00:24:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BWpBm-0007H2-00 for eap-archive@ietf.org; Sun, 06 Jun 2004 00:23:19 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BWpAx-0006xx-00; Sun, 06 Jun 2004 00:22:27 -0400 Received: from [61.73.93.27] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1BWpAw-0005Vi-5O; Sun, 06 Jun 2004 00:22:26 -0400 X-Message-Info: KNAKhIC7wTYaGz50Un5+YBCJw6yMYFK Received: from wrpisxhr33.cox.net ([176.210.162.174]) by sc45-v73.hotmail.com with Microsoft SMTPSVC(5.0.2195.6824); Sun, 06 Jun 2004 11:26:41 +0500 Received: from Marcusd61o5pee7f ([79.103.136.28]) by bbcweehu77.cox.net (InterMail vM.5.01.06.05 201-253-122-130-105-6826078) with SMTP id <76827795031889.HTTN1676.rtweecwg10.cox.net@ront02a8wad2l> for ; Sun, 06 Jun 2004 11:32:41 +0500 Message-ID: <820379e5h016$30612802$ml6z2782@Marcusm81w6wqc2o> From: "Dalton Strickland" To: Subject: Newsletter #8973 Date: Sun, 06 Jun 2004 11:26:41 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--66771246452415554759" X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=8.0 required=5.0 tests=FORGED_RCVD_NET_HELO, HTML_30_40,HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_GREEN, HTML_FONTCOLOR_RED,HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE, LINES_OF_YELLING,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,RCVD_NUMERIC_HELO,STOCK_PICK,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 1.2 STOCK_PICK BODY: Offers a picked stock * 0.8 HTML_30_40 BODY: Message is 30% to 40% HTML * 0.1 HTML_FONTCOLOR_GREEN BODY: HTML font color is green * 0.1 HTML_FONTCOLOR_BLUE BODY: HTML font color is blue * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 0.2 SUBJ_HAS_UNIQ_ID Subject contains a unique ID * 3.0 FORGED_RCVD_NET_HELO Host HELO'd using the wrong IP network * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts ----66771246452415554759 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

****DCPI****DCPI****DCPI****DCPI****DCPI****DC= PI****DCPI***DCPI****DCPI***


New York Times Financial Digest
Investor Alert on New Hot Issue


Take a look at our some of our most recent Strong Buy r= ecommendations...

November GDVI at 0.04 High 0.29...625% Gain!
December HTSC at 0.70 High 2.95...329% Gain!
March/April DMTY at 0.30 High 0.90...300%Gain!
April IPYS at 0.38 High 1.10...189%Gain in two days !
May/June          EES= I at 0.03         High  0.95.= .317% Gain in three days !
June            =   DCPI at  1.25 Don't Miss Out!  300%  Gains Expe= cted.....


(OTC-BB: DCPI) DCPI has developed a revolutionary digital printing tec= hnology recognized to be the solution to variable graphical/color printing= processes by industry leaders such as IBM (NYSE: IBM); XEROX (NYSE: XR= X) and Siemens(NYSE: SI) whose products only print in black via laser prod= ucts.  DCPI's commercial printing application hardware/software a= nd printing consumable products are expected to dominate the printing "enh= ancement" market ($5 Billion plus++ in 2002) over the next several years.&= nbsp; DCPI's initial target market of more than 4,000 large scale commerci= al printing companies of the total of 46,000 establishments is expected to= drive revenue growth to the tens of millions within its first few years, = further providing an ongoing revenue stream from the sales of printing con= sumable products for years to come.

SPECIAL INVESTMENT ALERT

Digital Color Print, Inc. (OTC Bulletin Board: DCPI)
Current Price: $1.25
Shares Outstanding: 24.6 Million
Market Capitalization: $31 Million
Short Term Target: $3.00
12 month Target: $9.00

A Few Reasons to Own DCPI:

Digital Color Print, Inc. ("DCPI"), through it's wholly owned subsidiary L= ogical Imaging Solutions ("LIS"), is in the business of supplying high-spe= ed digital printing systems and supplies to the commercial printing indust= ry. The printing systems are unique in technical concept and application. = The systems are totally digital, designed to mount on existing offset web = presses and significantly improve the functionality of the press, not as a= replacement - but as an enhancement. The printing process is called Elect= ron Beam Imaging ("EBI"), and is significantly faster the convention laser= printing - the only partially competing technology.

Printing is America's third largest manufacturing industry; employing more= than 1.2 million people in almost 46,000 establishments. The printing ind= ustry, during 2002, produced over $165 billion of printed products and pur= chased $4.5 billion of hardware and $7.7 billion of consumable products.&n= bsp; NYSE-listed Dover Corporation, the largest manufacturer of offset web= presses, estimates that there are more than 35,000 presses installed in t= he U.S., with a press costing from $150,000 to several million and using a= s much as $10,000 of consumable products per month.

Offset presses print all types of documents; forms, labels, tickets, tags,= advertisements and direct mail pieces, at production rates of 500 pages-p= er-minute ("ppm") to thousands of ppm. However, the printed materials prod= uced are each identical, as each image printed is the "offset" inked image= derived from the printing plates that are mounted on the offset press. Th= e great limitations of the offset process are that each image (page) remai= ns identical unless the printing plates are changed. Also the inking of th= e plates requires the laborious tasks of mixing the inks for each plate, i= nking the plates and then cleaning the press for the next job. If the prin= t job requires variable information, such as; name, address, bar codes, da= tes, prices, this must be added in a distinctly separate print operation. = Typically this task is performed by expensive data processing laser printe= rs, manufactured by either Xerox, IBM or Oce' (Formerly, Siemens Printing = Systems). The laser printers print only in black.

LIS printing systems are designed to mount directly on most offset web pre= sses and allow for the printing of any type of data or graphics, without l= imitation, and in line with the offset presses traditional production of a= colorful end product. As a simple example: In the production of an event = ticket such as a "Superbowl" ticket, all fixed or non-variable information= , such as the "colorful photo-quality" front cover and the stadium rules a= nd disclaimers on the reverse side of the ticket are produced by plates on= an offset press; identical information on each ticket. A second printing = process is then required to add the variable information, which includes t= he section, seat and row numbers, price and date of the event. This functi= on can be accomplished, in line, by an LIS provided system.

LIS printing systems are entirely digital and are dry "Toner" based, which= precludes the laborious press set-up and clean-up tasks, ink mixing and s= torage and the production of printing plates. The pressman simply runs the= paper directly through LIS's printer and it becomes an integral part of t= he press and the starting and stopping of the press and the placement of t= he digital object on the page are all under the control of LIS proprietary= software.

NYSE-listed Dover Corporation, the largest manufacturer of offset web pres= ses, estimates that there are more than 35,000 presses installed in the U.= S., with a press costing from $150,000 to several million and using as muc= h as $10,000 of consumable products per month.  DCPI's DIGITALCOLORPR= ESS was designed to be installed on the majority of these presses, extendi= ng their life and utility by providing the printing of computer generated = variable data in-line with the offset printing function. Further, the syst= em eliminates the need for preparing and storing printing plates, and inks= and the expensive tasks of setting up a press for a print run, followed b= y tearing down after each job, cleaning the press and setting up for the n= ext print job. DCPI estimates that the majority of printers will upgrade t= o color during the first two years of the DIGITALCOLORPRESS availability a= nd thousands more  commercial printers will purchase systems through = DCPI's direct sales force and distribution channel during the next two yea= rs.

DCPI's first growth step is to increase consumable inventory to support ex= isting LIS systems, each installation generates about $6,000 per month in = consumable purchases. Secondly, to make LIS's unique color press available= from inventory and expand the current number of installed sites. Thirdly,= make the product offering available to the commercial printing industry. = Large tasks, but currently without any perceived competition or technologi= cal limitation.

This stock will see major upward movement in the next several weeks. Ri= ght now, DCPI is one of the Street's best kept secrets, but it will not re= main that way for long. This is a unique opportunity to get in while tradi= ng levels are still low. As the Company goes forward with its business pla= n and signs major new contracts, this stock will move quickly. This is you= r last chance to invest before DCPI begins major price appreciation. This = stock could reach $3.50 in the next five trading days!



The writers, PR firm, mailers involved in the creation, and distributi= on of the information above are not a registered broker/dealer and may not= sell, offer to sell or offer to buy any security. This profile is not a s= olicitation or recommendation to buy, sell securities. An offer to buy or = sell can be made only with accompanying disclosure documents from the comp= any offering or selling securities and only in the states and provinces fo= r which they are approved. The material in this release is intended to be = strictly informational and based on assumptions rather than fact. The comp= anies that are discussed in this release have not approved the statements = made in this release nor approved the timing of this release. All statemen= ts and expressions are the sole opinion of the creators and are subject to= change without notice. Information in this release is derived from a vari= ety of sources including that company's publicly disseminated information,= third parties and the writers research and optimistic speculation. The ac= curacy or completeness of the information is not warranted and is only as = reliable as the sources from which it was obtained. All involved in the cr= eation and distribution of this profile/release disclaims any and all liab= ility as to the completeness or accuracy of the information contained and = any omissions of material fact in this release. The release may contain te= chnical and factual inaccuracies or typographical errors. It is strongly r= ecommended that any purchase or sale decision be discussed with a financia= l adviser, or a broker-dealer, or a member of any financial regulatory bod= ies. Investment in the securities of the companys discussed in this releas= e is highly speculative and carries a high degree of risk. All persons inv= olved in the creation and distribution of the information in this letter i= s not liable for any investment decisions by its readers or subscribers. I= nvestors are cautioned that they may lose all or a portion of their invest= ment if they make a purchase in this security mentioned. Any mention of pa= st profiles and returns are not our stock picks.

This profile is not without bias, and is a paid release. Writers and maile= rs have been compensated for the dissemination of company information on b= ehalf of one or more of the companies mentioned in this release. Parties i= nvolved in the creation and distribution of this profile have been compens= ated 40,000 dollars by a third party (third party), who is nonaffiliated, = for services provided including dissemination of company information in th= is release. PR and other individuals and other creators and mailers of thi= s letter will sell all of its original shares during the distribution of t= his profile. Parties involved may immediately sell some or any shares in a= profiled company held by profile creators and may have previously sold sh= ares in a profiled company held by PR Individuals involved. Our Optin mail= ing services for a company may cause the company's stock price to increase= , in which event involved parties would make a profit when it sells its st= ock in the company. In addition, our selling of a company's stock may have= a negative effect on the market price of the stock. The past profiles are= only the winners not all of our recommendations.

----66771246452415554759-- From IFDBPOKT@optonline.net Sun Jun 6 01:28:17 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27796 for ; Sun, 6 Jun 2004 01:28:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BWqCd-00017Q-UP for eap-archive@ietf.org; Sun, 06 Jun 2004 01:28:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BWqBk-0000n9-00 for eap-archive@ietf.org; Sun, 06 Jun 2004 01:27:20 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BWqAw-0000V4-00; Sun, 06 Jun 2004 01:26:30 -0400 Received: from [220.162.30.241] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1BWqAu-0006I9-6g; Sun, 06 Jun 2004 01:26:32 -0400 Received: from 182.10.239.83 by 220.162.30.241; Sat, 05 Jun 2004 23:24:46 -0600 Message-ID: From: "Spencer Boone" Reply-To: "Spencer Boone" To: diffserv-request@ietf.org Cc: dinaras@ietf.org, directory-web-archive@ietf.org, disman@ietf.org, disman-admin@ietf.org, disman-request@ietf.org, dmin@ietf.org, dn@ietf.org, drafts@ietf.org, e3@ietf.org, eamoby@ietf.org, eap-archive@ietf.org, edu-team@ietf.org Subject: Confirm Your Application Date: Sun, 06 Jun 2004 06:18:46 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--131674716003951" X-Webmail-Time: Sun, 06 Jun 2004 03:25:46 -0200 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.2 required=5.0 tests=FORGED_RCVD_NET_HELO, HTML_20_30,HTML_MESSAGE,HTML_TAG_BALANCE_HTML,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.5 HTML_20_30 BODY: Message is 20% to 30% HTML * 0.4 HTML_TAG_BALANCE_HTML BODY: HTML has unbalanced "html" tags * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 3.0 FORGED_RCVD_NET_HELO Host HELO'd using the wrong IP network * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts ----131674716003951 Content-Type: text/html; Content-Transfer-Encoding: 7Bit I am sorry that it took so long to review your application but
you were finally approved with 3% fixed ra.te. But first, to
ensure the best results, we’ll need some more information.

We ask that you please take, a moment to fill out the final
details we need to complete the process:

http://www.alphapuff.com/mn/bp

Thank you and we appreciate your business!

Regards,
Spencer Boone




----------------------
not interested
----131674716003951-- From NIATAHXCGXJQUV@intermedia.cl Sun Jun 6 03:31:52 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16010 for ; Sun, 6 Jun 2004 03:31:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BWs8F-0002hK-E7 for eap-archive@ietf.org; Sun, 06 Jun 2004 03:31:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BWs7G-0002Qd-00 for eap-archive@ietf.org; Sun, 06 Jun 2004 03:30:51 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BWs6K-0002BF-00; Sun, 06 Jun 2004 03:29:53 -0400 Received: from dt120n47.tampabay.rr.com ([24.92.185.71]) by mx2.foretec.com with smtp (Exim 4.24) id 1BWs6M-0007Eq-LM; Sun, 06 Jun 2004 03:29:54 -0400 X-Message-Info: 0BZAEA8XYMvF5D3BjPwnAQ0iECU1mZlbjQK0CN7F Received: from mail pickup service by 24.92.185.71 with Microsoft SMTPSVC; Sun, 06 Jun 2004 13:20:53 +0500 Content-Class: urn:content-classes:message Reply-To: "Jeffery Werner" From: "Jeffery Werner" To: "Edu-team-web-archive" Subject: 2004 doctors American directoty,physicians, Date: Sun, 06 Jun 2004 11:24:53 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--010014BE52948A9A1" Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.3 required=5.0 tests=HTML_MESSAGE, HTML_TITLE_UNTITLED,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,ORDER_NOW autolearn=no version=2.60 ----010014BE52948A9A1 Content-Type: text/html; charset="iso-9D21-A" Content-Transfer-Encoding: quoted-printable Untitled Document EXCLUSIVELY ON CD-ROM.

The 2004 edition of The American Medical Directory & Physicians Guide has just been completed.

physicians, specialists, doctors, licensed doctors,
board physicians, emergency physicians, 2004 physicians guide,
2004 physicians directory, physicians contact.

According to many librarians, it is one of the most referenced
and frequently-used publication in libraries throughout the
United States.

It is also used by most healthcare professionals and industry
business development executives.

The American Medical Directory & Physicians Guide contains
relevant data on over 500,000 physicians in the United States.

Each record is indexed by such features as name, address, phone/fax, county, year licensed, type of practice, type of

physician, as well as primary and secondary specialty.

During this introductory offer, the cost of the new directory
(which is available exclusively on CD-Rom) is $425.00 (reg. $795).

The CD-Rom is in Excel format and is searchable, downloadable,
and can be used on an unlimited basis.

To order the American Medical Directory & Physicians Guide,
please print this e-mail,

complete the information below and fax it to 905-751-0199.
(tel: 905-751-0919).

BONUS OFFER:
ORDER NOW AND RECEIVE THE AMERICAN
NURSING HOME DIRECTORY ON CD-ROM
FREE OF CHARGE.

NAME:

TITLE:

ORGANIZATION:

ADDRESS:

CITY:

POSTAL:

TEL:

FAX:

E-MAIL:

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

----010014BE52948A9A1-- From eap-admin@frascone.com Sun Jun 6 12:06: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 MAA06573 for ; Sun, 6 Jun 2004 12:06:15 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B35A720D40; Sun, 6 Jun 2004 11:53:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 734CA20D45; Sun, 6 Jun 2004 11:53:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 00E3020D45 for ; Sun, 6 Jun 2004 11:52:58 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 0CDF020D40 for ; Sun, 6 Jun 2004 11:52:56 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i56G7Xo06592 for ; Sun, 6 Jun 2004 09:07:34 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Issue 245: EAP Restart Issue 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, 6 Jun 2004 09:07:33 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) In going over the discussion on Issue 241, John Vollbrecht made a suggestion for a change to RFC 3748 that I think corrects an oversight. As the document is now Author 48 hours, it is still possible to correct the problem if the WG approves. -------------------------------------------------------------------------- Issue 245: EAP Restart Issue Submitter name: John Vollbrecht Submitter email address: jrv@umich.edu Date first submitted: 5/7/2004 Reference: http://mail.frascone.com/pipermail/eap/2004-May/002460.html Document: RFC2284bis-09 Comment type: T Priority: S Section: 4.1 Rationale/Explanation of issue: Section 4.1 of RFC 3748 states: "Additional Request packets MUST be sent until a valid Response packet is received, or an optional retry counter expires." Where the lower layer terminates the initial session and causes a restart, if EAP knows that the lower layer is terminated then I am not sure why it would continue to resend. Perhaps we should change this to: "Additional Request packets MUST be sent until a valid Response packet is received, an optional retry counter expires, or a lower layer failure indication is received." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Jun 6 12:53: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 MAA08608 for ; Sun, 6 Jun 2004 12:53:13 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8CC5B20D58; Sun, 6 Jun 2004 12:40:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 46168204B2; Sun, 6 Jun 2004 12:40:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5550D204B2 for ; Sun, 6 Jun 2004 12:39:49 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 541E6202D0 for ; Sun, 6 Jun 2004 12:39:47 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i56GsPE09241 for ; Sun, 6 Jun 2004 09:54:25 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Review of draft-adrangi-eap-network-discovery-00.txt Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 6 Jun 2004 09:54:25 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This document is comprised of several major sections: 1. Introduction (problem statement) 2. Specification of the ABNF 3. Delivery options 4. Security Considerations Overall, it seems to me that the material in Section 1 could be slimmed down or eliminated entirely via reference to the EAP Network Selection problem statement document. For example, one of the figures in Section appears to be duplicated as Figure 3 in the problem statement draft, as is some of the discussion. The terminology section should define the terms "MN" and "HSN". There are a number of issues with Section 2: a. The CHAR, DIGIT and ALPHA terminals are not defined or referenced. b. Is "=" a legal character within value? c. Rather than referencing RFC 2486bis, a separate definition of "Realm" is used that differs from that in RFC 2486bis. Since there is already a normative reference to RFC 2486bis, referencing the definition of "Realm" in that document shouldn't be a big deal. Section 3 includes discussion of AAA behavior, including normative language that appears to update RFC 3579 and RFC 2607. It also contains suggestions for operator deployment. Both of these considerations don't seem necessary to me in a document of this type, which should focus on defining the EAP extension. Instead, I'd suggest that Section 3 be limited to discussion of EAP issues. Section 4 notes that the network information is a hint. This implies that existing implementations will ignore the hint, presumably without affecting interoperability. It also implies that the peer needs to be robust against misleading information, but this section does not describe the potential attacks or how a peer can guard against them. I'm not sure that the analogy to the SSID is a good one, unless it's being suggested that Channel Bindings be used to verify the network information after the fact. Section 6, references Assuming that discussion of AAA is eliminated in this document, then normative references ot RADIUS or Diameter should not be needed. The only normative references would then be to RFC 2234 (by the way, have you checked the ABNF??), RFC 3748 and RFC 2486bis. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Jun 6 13:02: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 NAA08906 for ; Sun, 6 Jun 2004 13:02:12 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B726420D54; Sun, 6 Jun 2004 12:49:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7048B20D5C; Sun, 6 Jun 2004 12:49:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 38FF220D57 for ; Sun, 6 Jun 2004 12:48:43 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 70C3120D54 for ; Sun, 6 Jun 2004 12:48:41 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id DBA0F89865; Sun, 6 Jun 2004 20:01:46 +0300 (EEST) Message-ID: <40C34D08.6000201@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] Issue 245: EAP Restart Issue References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 06 Jun 2004 19:57:44 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I think the suggested change is OK. --Jari Bernard Aboba wrote: > In going over the discussion on Issue 241, John Vollbrecht made a > suggestion for a change to RFC 3748 that I think corrects an oversight. As > the document is now Author 48 hours, it is still possible to correct the > problem if the WG approves. > > -------------------------------------------------------------------------- > Issue 245: EAP Restart Issue > Submitter name: John Vollbrecht > Submitter email address: jrv@umich.edu > Date first submitted: 5/7/2004 > Reference: http://mail.frascone.com/pipermail/eap/2004-May/002460.html > Document: RFC2284bis-09 > Comment type: T > Priority: S > Section: 4.1 > Rationale/Explanation of issue: > > Section 4.1 of RFC 3748 states: > > "Additional Request packets MUST be sent until a valid Response packet is > received, or an optional retry counter expires." > > Where the lower layer terminates the initial session and causes a restart, > if EAP knows that the lower layer is terminated then I am not sure why it > would continue to resend. > > Perhaps we should change this to: > > "Additional Request packets MUST be sent until a valid Response packet is > received, an optional retry counter expires, or a lower layer failure > indication is received." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Jun 6 18:26: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 SAA23723 for ; Sun, 6 Jun 2004 18:26:16 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A74D320506; Sun, 6 Jun 2004 18:13:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2A5BD20BAC; Sun, 6 Jun 2004 18:13:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AED9F20BAC for ; Sun, 6 Jun 2004 18:12:58 -0400 (EDT) Received: from av7-1-sn1.fre.skanova.net (av7-1-sn1.fre.skanova.net [81.228.11.113]) by mail.frascone.com (Postfix) with ESMTP id 046EA20506 for ; Sun, 6 Jun 2004 18:12:57 -0400 (EDT) Received: by av7-1-sn1.fre.skanova.net (Postfix, from userid 502) id EFA5C37EB6; Mon, 7 Jun 2004 00:26:03 +0200 (CEST) Received: from smtp3-2-sn1.fre.skanova.net (smtp3-2-sn1.fre.skanova.net [81.228.11.164]) by av7-1-sn1.fre.skanova.net (Postfix) with ESMTP id DD04137E47; Mon, 7 Jun 2004 00:26:03 +0200 (CEST) Received: from chardonnay.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp3-2-sn1.fre.skanova.net (Postfix) with ESMTP id CC06737E44; Mon, 7 Jun 2004 00:26:03 +0200 (CEST) Received: from chardonnay ([127.0.0.1]) by chardonnay.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1BX65a-00056r-00; Mon, 07 Jun 2004 00:26:02 +0200 From: Henrik Levkowetz To: jari.arkko@piuha.net Cc: Bernard Aboba , eap@frascone.com Subject: Re: [eap] Issue 245: EAP Restart Issue Message-Id: <20040607002602.38bd8868@chardonnay> In-Reply-To: <40C34D08.6000201@piuha.net> References: <40C34D08.6000201@piuha.net> X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 7 Jun 2004 00:26:02 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I have included this change in the Auth. 48 corrected rfc3748 text - see 'rfc3748.b.txt' on http://ietf.levkowetz.com/drafts/eap/rfc2248bis/ Henrik Sunday 6 June 2004, Jari Arkko wrote: > > I think the suggested change is OK. > > --Jari > > Bernard Aboba wrote: > > In going over the discussion on Issue 241, John Vollbrecht made a > > suggestion for a change to RFC 3748 that I think corrects an oversight. As > > the document is now Author 48 hours, it is still possible to correct the > > problem if the WG approves. > > > > -------------------------------------------------------------------------- > > Issue 245: EAP Restart Issue > > Submitter name: John Vollbrecht > > Submitter email address: jrv@umich.edu > > Date first submitted: 5/7/2004 > > Reference: http://mail.frascone.com/pipermail/eap/2004-May/002460.html > > Document: RFC2284bis-09 > > Comment type: T > > Priority: S > > Section: 4.1 > > Rationale/Explanation of issue: > > > > Section 4.1 of RFC 3748 states: > > > > "Additional Request packets MUST be sent until a valid Response packet is > > received, or an optional retry counter expires." > > > > Where the lower layer terminates the initial session and causes a restart, > > if EAP knows that the lower layer is terminated then I am not sure why it > > would continue to resend. > > > > Perhaps we should change this to: > > > > "Additional Request packets MUST be sent until a valid Response packet is > > received, an optional retry counter expires, or a lower layer failure > > indication is received." > _______________________________________________ > 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 Sun Jun 6 23:24:30 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04289 for ; Sun, 6 Jun 2004 23:24:30 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 42A8220870; Sun, 6 Jun 2004 23:11:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B299920357; Sun, 6 Jun 2004 23:11:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9BB0620719 for ; Sun, 6 Jun 2004 23:10:23 -0400 (EDT) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by mail.frascone.com (Postfix) with ESMTP id 3BF332056A for ; Sun, 6 Jun 2004 23:10:21 -0400 (EDT) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.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 i573Moeg024022; Mon, 7 Jun 2004 03:22:50 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.10 2004/03/01 19:21:36 root Exp $) with SMTP id i573ODfI025070; Mon, 7 Jun 2004 03:24:16 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 M2004060620230719243 ; Sun, 06 Jun 2004 20:23:07 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 6 Jun 2004 20:23:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Review of draft-adrangi-eap-network-discovery-00.txt Message-ID: Thread-Topic: [eap] Review of draft-adrangi-eap-network-discovery-00.txt Thread-Index: AcRL5sb8yVpLvrhuR92X/W7DieKSNwAP5STQ From: "Adrangi, Farid" To: "Bernard Aboba" , Cc: "Adrangi, Farid" X-OriginalArrivalTime: 07 Jun 2004 03:23:07.0618 (UTC) FILETIME=[C0996C20:01C44C3E] 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: Sun, 6 Jun 2004 20:23:06 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi Bernard, Thanks so much for your review and comments. Please see my responses below. BR, Farid >=20 > This document is comprised of several major sections: >=20 > 1. Introduction (problem statement) > 2. Specification of the ABNF > 3. Delivery options > 4. Security Considerations >=20 > Overall, it seems to me that the material in Section 1 could be > slimmed down or eliminated entirely via reference to the EAP Network > Selection problem statement document. For example, one of=20 > the figures in > Section appears to be duplicated as Figure 3 in the problem statement > draft, as is some of the discussion. >=20 The problem statement draft provides an overview of four problems: 1) Access Netowrk Discocery 2) Idenitifier Selection 3) Selection of roaming intermediaries 4) Payload routing Here we are focusing only on the problem #3 as we did in the original draft (published before the problem statement draft). I don't think it would be a good idea to eliminate the section entirely via reference to the problem statement draft . We have already slimmed down the section 1 with the help of Jari - and as you noticed we used Figure 3 as per Jari's suggestion. I can go through it again, maybe we can make it more concise -- please this section is pretty short.=20 > The terminology section should define the terms "MN" and "HSN". >=20 Yes. Good catch. In the latest version, the intent was not to use these terms. But, I think I left a few in the document -- will fix... > There are a number of issues with Section 2: >=20 > a. The CHAR, DIGIT and ALPHA terminals are not defined or referenced. DIGIT, ALPHA, CHAR are defined in RFC 2234. I noticed alphanum was undefined when I ran it through the ABNF checker - I have fixed it in the later version along with other things -- please also see my response to Jari's mail. Here are the moidified ABNF definitions: identity-request-data =3D displayable-string [ %d0 network-info ] displayable-string =3D *CHAR network-info =3D attribute "=3D" value attribute =3D 1*( ALPHA / "-" / "_" / DIGIT) value =3D 1*( %x01-FF ) ; any non-null UTF-8 char ---- value =3D Realm [ ";" Realm ] Realm =3D *( domainlabel "." ) toplabel domainlabel =3D (ALPHA / DIGIT) *( ALPHA / DIGIT / "-" ) toplabel =3D ALPHA * (ALPHA / DIGIT) > b. Is "=3D" a legal character within value? Currently it is, as it does not make the definition ambiguious. Do you have any concerns about it? > c. Rather than referencing RFC 2486bis, a separate definition=20 > of "Realm" > is used that differs from that in RFC 2486bis. Since=20 > there is already > a normative reference to RFC 2486bis, referencing the definition of > "Realm" in that document shouldn't be a big deal. >=20 I guess you are right! We could do that :-) > Section 3 includes discussion of AAA behavior, including normative > language that appears to update RFC 3579 and RFC 2607. It also > contains suggestions for operator deployment. Both of these > considerations don't seem necessary to me in a document of this type, > which should focus on defining the EAP extension. Instead,=20 > I'd suggest > that Section 3 be limited to discussion of EAP issues. >=20 I see your point. Most of AAA behavior discussion is done in describing the option 3 -- therefore it is going to be hard to describe how the option 3 would work without making any references to AAA. I will try to reword the text in option 3, and send it to you for review. =20 > Section 4 notes that the network information is a hint. This=20 > implies that > existing implementations will ignore the hint, presumably without > affecting interoperability. =20 That's true. > It also implies that the peer needs to be > robust against misleading information, but this section does not > describe the potential attacks or how a peer can guard against them. Does IEEE describe how a peer can guard against spoofed SSIDs? I guess we could include some discussion on potential attacks and possibly how a peer can guard against them if you think it is necessary even thought we are saying the information should be used as a hint. =20 > I'm not sure that the analogy to the SSID is a good one, unless it's > being suggested that Channel Bindings be used to verify the network > information after the fact. >=20 > Section 6, references >=20 > Assuming that discussion of AAA is eliminated in this document, then > normative references ot RADIUS or Diameter should not be=20 > needed. The only > normative references would then be to RFC 2234. Ok > by the way, have you > checked the ABNF??), RFC 3748 and RFC 2486bis. I am not sure what the question is here. > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap >=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Jun 7 10:07: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 KAA17055 for ; Mon, 7 Jun 2004 10:07:16 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2EC8520BF7; Mon, 7 Jun 2004 09:54:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EA2D720BF3; Mon, 7 Jun 2004 09:54:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8F21720BF3 for ; Mon, 7 Jun 2004 09:53:25 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 81FDE20BB4 for ; Mon, 7 Jun 2004 09:53:23 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i57E7t317935; Mon, 7 Jun 2004 07:07:56 -0700 From: Bernard Aboba To: "Adrangi, Farid" Cc: eap@frascone.com Subject: RE: [eap] Review of draft-adrangi-eap-network-discovery-00.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 7 Jun 2004 07:07:55 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > > a. The CHAR, DIGIT and ALPHA terminals are not defined or referenced. > > DIGIT, ALPHA, CHAR are defined in RFC 2234. A reference to RFC 2234 would be good. > I guess you are right! We could do that :-) I think it would ensure that there is no divergence. BTW, I think the draft needs a very short IANA Considerations section that says "There are no considerations for IANA." > I see your point. Most of AAA behavior discussion is done in describing > the option 3 -- therefore it is going to be hard to describe how the > option 3 would work without making any references to AAA. I will try to > reword the text in option 3, and send it to you for review. I'm not sure you even need to describe the options in much detail. You can just have an "Implementation Considerations" section that lists the three options and says a few words about the pros/cons. But making recommendations is probably going too far. > Does IEEE describe how a peer can guard against spoofed SSIDs? IEEE 802.11i does provide this information actually -- by checking the parameters in the Beacon/Probe Response against those included in the 4-way handshake. But I'm not clear how to protect against bogus network information on the client. For example, what should the client do if: a. An initial EAP-Request/Identity did not include a hint, but after sending an EAP-Response/Identity, the peer receives *both* an EAP-Request/Identity with a hint, *and* an EAP-Request for a method? b. An EAP-Request/Identity contains hints for unknown NAIs > we could include some discussion on potential attacks and possibly how a > peer can guard against them if you think it is necessary even though we > are saying the information should be used as a hint. I guess I'm unclear what "hint" means here -- under what conditions should conforming implementations ignore the "hint" -- and how are the "hints" used in addition to the information specified in RFC 3770? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Jun 7 17:50:20 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25831 for ; Mon, 7 Jun 2004 17:50:20 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 578D320D9D; Mon, 7 Jun 2004 17:37:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0697F1FF79; Mon, 7 Jun 2004 17:37:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 666511FF79 for ; Mon, 7 Jun 2004 17:36:12 -0400 (EDT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by mail.frascone.com (Postfix) with ESMTP id 20DB11FF72 for ; Mon, 7 Jun 2004 17:36:10 -0400 (EDT) Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i57LojRM018813; Mon, 7 Jun 2004 21:50:45 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i57LjL99009085; Mon, 7 Jun 2004 21:45:21 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 M2004060714491102196 ; Mon, 07 Jun 2004 14:49:11 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 7 Jun 2004 14:49:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Review of draft-adrangi-eap-network-discovery-00.txt Message-ID: Thread-Topic: [eap] Review of draft-adrangi-eap-network-discovery-00.txt Thread-Index: AcRMmKN5VRkIzMwrQZCdaX33IjnJJwANV6HQ From: "Adrangi, Farid" To: "Bernard Aboba" Cc: , "Adrangi, Farid" X-OriginalArrivalTime: 07 Jun 2004 21:49:05.0239 (UTC) FILETIME=[40D2D670:01C44CD9] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 7 Jun 2004 14:49:04 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi Bernard, Please see my response inline. BR, Farid >=20 > BTW, I think the draft needs a very short IANA Considerations=20 > section that > says "There are no considerations for IANA." >=20 Ok. > > I see your point. Most of AAA behavior discussion is done=20 > in describing > > the option 3 -- therefore it is going to be hard to describe how the > > option 3 would work without making any references to AAA. =20 > I will try to > > reword the text in option 3, and send it to you for review. >=20 > I'm not sure you even need to describe the options in much=20 > detail. You > can just have an "Implementation Considerations" section that=20 > lists the > three options and says a few words about the pros/cons. But making > recommendations is probably going too far. Ok, I will restructure/reword this -- I like the idea of having an "Implementation Considerations" section. >=20 > > Does IEEE describe how a peer can guard against spoofed SSIDs? >=20 > IEEE 802.11i does provide this information actually -- by checking the > parameters in the Beacon/Probe Response against those included in the > 4-way handshake. But I'm not clear how to protect against=20 > bogus network > information on the client. For example, what should the client do if: >=20 > a. An initial EAP-Request/Identity did not include a hint, but after > sending an EAP-Response/Identity, the peer receives *both* an > EAP-Request/Identity with a hint, *and* an EAP-Request for a method? >=20 > b. An EAP-Request/Identity contains hints for unknown NAIs >=20 > > we could include some discussion on potential attacks and=20 > possibly how a > > peer can guard against them if you think it is necessary=20 > even though we > > are saying the information should be used as a hint. >=20 I think our focus here is (b) and I would reword it like "An EAP-Request/Identity contains hints for mediating network names". I don't think the (a) is an option as the home network will not know about the access network's roaming agreements with 1 or more mediating network. Let's talk about what bogus network information means here. I can think of two scenarios: 1) client associates with a bogus SSID, starts EAP, and receives some bogus network information. In this case, associating with the bogus SSID is the problem - what ever happens after that obviously is going to be questionable. 2) Associating with a valid/legitimate SSID. In this case, the access network may advertise only a subset of the mediating networks (based on its own preference), or route the AAA packets different from what specified through the user's preference (i.e., via decorated NAI). I don't think we can detect the former one. However, for the latter one, the home network may be able to detect the problem in real time if it knows the path that the AAA packet took, or during the settlement time. =20 We may want to list some known attack scenarios in the draft and leave out how these attacks can be detected. What do you think? =20 =20 > I guess I'm unclear what "hint" means here -- under what=20 > conditions should > conforming implementations ignore the "hint" -- and how are=20 > the "hints" > used in addition to the information specified in RFC 3770? >=20 >=20 Hint here means that network information is delivered through an unprotected channel, the initial EAP-Identity Request. =20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From chrysanthemumo@cashette.com Tue Jun 8 00:48:08 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17421 for ; Tue, 8 Jun 2004 00:48:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXYWv-0002Bt-Fj for eap-archive@ietf.org; Tue, 08 Jun 2004 00:48:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXYVv-0001Xz-00 for eap-archive@ietf.org; Tue, 08 Jun 2004 00:47:08 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BXYUg-0000mQ-00; Tue, 08 Jun 2004 00:45:50 -0400 Received: from [211.210.82.40] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1BXYUg-0004Gj-2L; Tue, 08 Jun 2004 00:45:50 -0400 X-Message-Info: OSWVaHR39sW1ZjgV6ApuqL6R0X1p70YZ Received: from hobby.albumin.com ([205.122.32.180]) by ve26-c10.hotmail.com with Microsoft SMTPSVC(5.0.2195.6824); Tue, 08 Jun 2004 10:53:04 +0400 Received: from ljy4-laban2.B9syq.com (needham2 [50.5.104.162]) by trapezium.z4.com (6.78.3/9.78.0) with ESMTP id o2OR6rq98796 for ; Tue, 08 Jun 2004 07:49:04 +0100 GMT Received: (from y3forte@localhost) by ybg0-descriptive4.l4nir.com (0.45.5/6.80.4) id j1DO5rf58604; Tue, 08 Jun 2004 10:56:04 +0400 GMT X-Authentication-Warning: hgr5-arthritis6.k2zsk.com: v2cottony set sender to chrysanthemumo@cashette.com using -f MIME-Version: 1.0 Date: Tue, 08 Jun 2004 11:56:04 +0500 From: Keisha Hughes Subject: Newsletter #0491 To: cfrg@ietf.org Message-Id: Content-Type: multipart/alternative; boundary="--9004219453790209" X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.3 required=5.0 tests=FORGED_RCVD_NET_HELO, HTML_20_30,HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_RED,HTML_FONT_BIG, HTML_MESSAGE,LINES_OF_YELLING,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,RCVD_NUMERIC_HELO,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.1 HTML_FONTCOLOR_BLUE BODY: HTML font color is blue * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.5 HTML_20_30 BODY: Message is 20% to 30% HTML * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 0.2 SUBJ_HAS_UNIQ_ID Subject contains a unique ID * 3.0 FORGED_RCVD_NET_HELO Host HELO'd using the wrong IP network * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts ----9004219453790209 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable ****EESI****EESI****EESI****EESI****EESI****EE= SI****EESI***

URGENT TRADING ALERT - EESI - STOCK MARKET NEWS FLASH

Significant short term trading profits in a hot Internet issue (Ticker= : EESI)

EESI is one of the most overlooked and undervalued stocks that we have see= n lately, and is poised to see major price gains over the next week. = EESI will see much higher trading levels over the next few days and offer= s savvy investors the chance to make huge short term trading gains.  = Don=92t miss out on this unique opportunity=85June 7=96 June 11=85

SPECIAL ALERT
Emerging Enterprise Solutions, Inc. (OTC Pink Sheets: EESI)
Current Price: $0.08
Shares Outstanding: 49 Million
Est. Public Float: 12.0 Million
Market Capitalization: $1.96 Million
Short Term Target: $0.30
12month Target:   $1.00

Take a look at our some of our most recent Strong Buy recommendations...
=95 November          CFTN at= 0.40        High 2.62...655= % Gain!
=95 November          GDVI at= 0.04        High 0.29...625= % Gain!
=95 December          HTSC at= 0.70       High 2.95...329% Gain!
=95 APRIL/March     DMTY at 0.30   &nbs= p;   High 0.90...300%Gain!
=95 APRIL           = ;      NALG at 0.76     =   High 1.60...110%Gain! in two days
=95 APRIL           = ;      IPYS at 0.38     =   High 1.10...189%Gain! in two days
=95 APRIL GXRI at 1.21        High 1.= 95=8562%Gain! in three days

--EESI is a rapidly emerging direct sales company with two main divisions-= Bayport, Inc. offers a complete line of high-quality products for the hig= h growth $52 billion personal care industry- American Business Resource Ne= twork provides a complete system of educational training and instructional= seminars to help the nation=92s 25 million small and entrepreneurial busi= nesses.

--EESI is undertaking major growth initiatives which will play out in sign= ificant near term revenue growth, and leave the Company well positioned to= emerge as a major player in the $85 billion direct marketing industry!!!<= BR>
A Few Reasons to Own EESI:

1. EESI=92s Bayport subsidiary is an emerging leader in the $52 billion pe= rsonal care market with a product offering of over 70 high quality persona= l care and health and wellness items.  The Bayport line is distribute= d through direct sales, the Internet, infomercials, and trade shows. = Bayport is completing installation of advanced order processing and fulfi= llment software that will enable it to meet high sales volumes, and is dev= eloping relationships with outside sales groups to ramp sales efforts.&nbs= p;

2.  Bayport is addressing lucrative markets with its personal care an= d health & wellness offerings.  Personal care and cosmetic care i= s a $52.7 billion industry that is growing at a CAGR of 5.7%, while Baypor= t=92s niche markets provide ample growth opportunities (skin care is a $19= billion industry, for example).  The health & wellness industry = is estimated at over $59 billion and has been growing at a rate of 10= % annually, as American consumers seek better health and appearance.

3. EESI has created an innovative and unique service offering with America= n Business Resource Network.  ABRN will provide three complimentary l= evels of services, a =93a =93Getting Your Business Started on the Right Tr= ack=94 software package which includes all of the forms and templates nece= ssary to form a business; a more advanced series of educational seminars c= overing topics relevant to start-up business needs; and the National Inves= tment Congress- an organization hosting annual conventions to showcase com= panies for national investment exposure and financing. 

4. There are over 25 million individual and small businesses in the US, wi= th over 1 million small business failures each year and a majority of new = start-ups closing within 5 years due to owner inexperience, lack of famili= arity with capital structure, and other issues.  ABRN is one of the f= irst businesses to specifically address this significant market opportunit= y.

5. Direct marketing is a dynamic and explosive growth industry with revenu= es of over $85 billion- in the US alone the industry is expected to reach = $35 billion by 2005.  Increasingly network marketing has become popul= ar not just among specialty businesses like Avon and Mary Kay, but with co= rporate America as well. 

6. EESI has recently launched Telemarkone, a call center and telemarketing= operation that will provide support for Bayport and ABRN operations as we= ll as an additional revenue stream through contracts with major corporatio= ns.  Telemarkone has already signed agreements with AT&T Wireless= and California Long Distance Co. and EESI management estimates that this = arm of the Company will add at least $2 million in net income over the nex= t 12 months.

7. EESI has a strong and experienced management team with long and success= ful histories in key operating markets.  CEO Gary Sherman has an exte= nsive investment banking background, while Bayport leaders James and Betty= Porter have a wide range of experience in the direct marketing and person= al care industries.

With a strong position in the direct marketing industry, innovative operat= ions in personal care/health & wellness, business education, and telem= arketing, EESI stands poised to see major near term revenue growth.  = EESI is improving its sales infrastructure, and we expect to see significa= nt announcements over the next several months. 

About EESI -- go to bayportinc.com and abrninc.com

We urge you to invest now, and take advantage of this unique opportunity t= o invest in a rapidly growing and soon-to-be profitable new player in the = direct marketing industry.  The best news is that, at its current pri= ce of $0.04, EESI offers a low risk opportunity to see huge trading gains.=   This stock could reach $0.30 in the next week of trading!!!

This profile is not without bias, and is a paid release. Writers and m= ailers have been compensated for the dissemination of company information = on behalf of one or more of the companies mentioned in this release. Parti= es involved in the creation and distribution of this profile have been com= pensated 50,000 dollars by a third party (third party), who is non-affilia= ted, for services provided including dissemination of company information = in this release. PR and other individuals and other creators and mailers o= f this letter will sell all of its original shares during the distribution= of this profile. Parties involved will immediately sell some or any share= s in a profiled company held by profile creators and may have previously s= old shares in a profiled company held by PR Individuals involved. Our Opti= n mailing services for a company may cause the company stock price to incr= ease, in which event involved parties would make a profit when it sells it= s stock in the company. In addition, our selling of a company stock may ha= ve a negative effect on the market price of the stock. The past profiles a= re only the winners not all of our recommendations


 ----9004219453790209-- From eap-admin@frascone.com Tue Jun 8 06:32:17 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16931 for ; Tue, 8 Jun 2004 06:32:16 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 96F4F202DF; Tue, 8 Jun 2004 06:19:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6F7BE203B1; Tue, 8 Jun 2004 06:19:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AF15B203B1 for ; Tue, 8 Jun 2004 06:18:04 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by mail.frascone.com (Postfix) with ESMTP id B2B4C202DF for ; Tue, 8 Jun 2004 06:18:02 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 8 Jun 2004 12:31:04 +0200 Received: from rd.francetelecom.fr ([10.193.106.32]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Tue, 8 Jun 2004 12:31:02 +0200 Message-ID: <40C59627.2080907@rd.francetelecom.fr> From: Florent Bersani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henrik Levkowetz , jari.arkko@piuha.net, Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] Issue 245: EAP Restart Issue References: <40C34D08.6000201@piuha.net> <20040607002602.38bd8868@chardonnay> In-Reply-To: <20040607002602.38bd8868@chardonnay> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jun 2004 10:31:02.0817 (UTC) FILETIME=[B29FA110:01C44D43] 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, 08 Jun 2004 12:34:15 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Well, I've got a fuzzy feeling about this issue, especially when I take a look at rfc3748.b.txt in section 7.12: "In IEEE 802.11, a "link down" indication is an unreliable indication of link failure, since wireless signal strength can come and go and may be influenced by radio frequency interference generated by an attacker. To avoid unnecessary resets, it is advisable to damp these indications, rather than passing them directly to the EAP. Since EAP supports retransmission, it is robust against transient connectivity losses. " Perhaps it's my unskilled understanding of the problem, but I find "indication of link failure" and "lower layer failure indication" quite confusing :-( * If they refer to the same thing, then I find the proposed changed to resolve issue 245 contradictory to the RFC 3748 text quoted here above * If not, I'd be more than happy to get some clarification :-) Any suggestion? Florent P.S: My two cents here is that there might be a confusion arising from "lower layer". Indeed, I guess when EAP is used for wireless LANs, lower layer could apply to two layers: the IEEE 802.11 layer and the IEEE 802.1X/11i layer. Stricto sensu, I think that in this case, lower layer should only refer to 802.1X. If this is the case, then the problem I am trying to consider reduces to know when 802.1X considers that it should restart due to its lower layer (i.e. 802.11) link failure. Depending on this decision, the RFC 3748 text quoted here above might become useless (i.e. since 802.1X could be damping the link failure indications, there would be no need to mandate that EAP do so - but I believe without any justification that this is not the case for 802.1X). I leave the debate on 802.1X/EAP to the group of well versed people in that matter (which I unfortunately do not -yet? - belong to :-() However, the problem with this P.S is that it is too 802.1X centric (as much of EAP probably but this is another debate). There could be some cases in which EAP is run directly over a link layer and has no intermediate layer (like 802.1X) to do the possible damping. If this is the case, we really want to make sure that the "damping" mechanism used by EAP is really media independent and works as well with 802.1X as without. If 802.1X does no damping (which is probably the case), then this problem is easy. If it does, well? Not sure I have been very clear here :-( Hope however this helps. Henrik Levkowetz wrote: >I have included this change in the Auth. 48 corrected rfc3748 text - see >'rfc3748.b.txt' on http://ietf.levkowetz.com/drafts/eap/rfc2248bis/ > > Henrik > >Sunday 6 June 2004, Jari Arkko wrote: > > >>I think the suggested change is OK. >> >>--Jari >> >>Bernard Aboba wrote: >> >> >>>In going over the discussion on Issue 241, John Vollbrecht made a >>>suggestion for a change to RFC 3748 that I think corrects an oversight. As >>>the document is now Author 48 hours, it is still possible to correct the >>>problem if the WG approves. >>> >>>-------------------------------------------------------------------------- >>>Issue 245: EAP Restart Issue >>>Submitter name: John Vollbrecht >>>Submitter email address: jrv@umich.edu >>>Date first submitted: 5/7/2004 >>>Reference: http://mail.frascone.com/pipermail/eap/2004-May/002460.html >>>Document: RFC2284bis-09 >>>Comment type: T >>>Priority: S >>>Section: 4.1 >>>Rationale/Explanation of issue: >>> >>>Section 4.1 of RFC 3748 states: >>> >>>"Additional Request packets MUST be sent until a valid Response packet is >>>received, or an optional retry counter expires." >>> >>>Where the lower layer terminates the initial session and causes a restart, >>>if EAP knows that the lower layer is terminated then I am not sure why it >>>would continue to resend. >>> >>>Perhaps we should change this to: >>> >>>"Additional Request packets MUST be sent until a valid Response packet is >>>received, an optional retry counter expires, or a lower layer failure >>>indication is received." >>> >>> >>_______________________________________________ >>eap mailing list >>eap@frascone.com >>http://mail.frascone.com/mailman/listinfo/eap >> >> > > >_______________________________________________ >eap mailing list >eap@frascone.com >http://mail.frascone.com/mailman/listinfo/eap > > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Jun 8 06:57:17 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17888 for ; Tue, 8 Jun 2004 06:57:17 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0043320DDC; Tue, 8 Jun 2004 06:44:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B0ED5205F5; Tue, 8 Jun 2004 06:44:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3A66D205F5 for ; Tue, 8 Jun 2004 06:43:33 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by mail.frascone.com (Postfix) with ESMTP id 47AE3203B1 for ; Tue, 8 Jun 2004 06:43:31 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 8 Jun 2004 12:56:39 +0200 Received: from rd.francetelecom.fr ([10.193.106.32]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Tue, 8 Jun 2004 12:56:38 +0200 Message-ID: <40C59C27.6070209@rd.francetelecom.fr> From: Florent Bersani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: eap@frascone.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jun 2004 10:56:38.0988 (UTC) FILETIME=[4640B8C0:01C44D47] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Another two minor and finicky IANA considerations questions for RFC3748 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, 08 Jun 2004 12:59:51 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi all, While reviewing again RFC 3748b, I just came across two little (and fairly uninteresting I admit) questions/remarks (that may however help RFC 3748 understanding in the future: 1) It is apparently not specified how expanded (method) types for vendor-ID 0 (IETF) can be allocated (e.g. Designated Expert, with Specification Required or standards action, FCFS, ...). In section 6.2 we indeed only read: "Method Type values 256-4294967295 may be allocated after Type values 1-191 have been allocated." I know we've probably got time before this happens but I just feel reluctant to leave an incomplete spec behind us ;-) 2) The (non)-use of 0 as packet code or method type The newbie I am is pretty sure that there are good reasons why EAP did not start its code and type space at 0 (and I'd be more than thankful to anybody who could tell me why) but I find the current wording about not using this value a (very little) bit confusing. In section 6.1 of RFC 3748b we read: "Packet Codes have a range from 1 to 255" and on the IANA website (http://www.iana.org/assignments/eap-numbers) we find: "(last updated 12 April 2004) Packet Codes: Value Description Reference 1 Request [RFC-ietf-eap-rfc2284bis-09.txt] 2 Response [RFC-ietf-eap-rfc2284bis-09.txt] 3 Success [RFC-ietf-eap-rfc2284bis-09.txt] 4 Failure [RFC-ietf-eap-rfc2284bis-09.txt] 5-255 Unallocated" In section 6.2 of RFC 3748b we read: "The original EAP method Type space has a range from 1 to 255" and on the IANA website (http://www.iana.org/assignments/eap-numbers) we find: "(last updated 12 April 2004) ... Value Description Reference 0 RESERVED 1 Identity [RFC-ietf-eap-rfc2284bis-09.txt] ..." Indeed, the value 0 is used in the NAK response. My suggestion would be to find a way to simply reflect this usage in RFC 3748 and for IANA. My preference would be adding a small reminder on the value 0 usage in RFC 3748 section 6.2 and updating the IANA website to also refer to RFC 3748 for this value. I am ready to propose some text if people feel like making this minor and unimportant change. BR, Florent P.S: BTW, it seems like we (EAP and/or IANA) have not captured the point I raised earlier on Method Type 7&8 (http://mail.frascone.com/pipermail/public/eap/2004-May/002486.html). Again, I am ready to propose some text if people feel like making this minor and unimportant change (and I concurred to Jari's proposal "allocated but unused"). _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Jun 9 05:24:19 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04579 for ; Wed, 9 Jun 2004 05:24:18 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 194C620316; Wed, 9 Jun 2004 05:11:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 624082036E; Wed, 9 Jun 2004 05:11:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 16E562036E for ; Wed, 9 Jun 2004 05:10:40 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by mail.frascone.com (Postfix) with ESMTP id DE96D20316 for ; Wed, 9 Jun 2004 05:10:37 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 9 Jun 2004 11:23:42 +0200 Received: from rd.francetelecom.fr ([10.193.106.54]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Wed, 9 Jun 2004 11:23:40 +0200 Message-ID: <40C6D7DF.7050203@rd.francetelecom.fr> From: Florent Bersani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jun 2004 09:23:40.0837 (UTC) FILETIME=[73D42D50:01C44E03] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Comments on EAP state machine v4 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, 09 Jun 2004 11:26:55 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi all, Below are some comments that came to my mind while reading the latest version of EAP state machine I am aware of (http://www.cs.umd.edu/~npetroni/EAP/drafts/ietf-eap-statemachine/04/draft-ietf-eap-statemachine-strawman-04.pdf). I know that these comments may: * Come much too late (since IETF last call has ended 2004-05-13 so it shouldn't be the time IINM to propose any "real" changes to this document) * Be completely naive or off the rocket * Echo some comments that have already been made (although I tried my best to reread - and understand ;-) - the EAP state machine issues tracked by Bernard I just felt like making them: * Because the probability that they be of some help somehow is - I hope - non-zero * Because the probability that someone kindly replies to educate me, is - I hope - non-zero * For the record So here they go. Comment #1 - Editorial In section 3.2 state machine symbols, we can read: "+ Arithmetic addition operator. - Arithmetic subtraction operator." I find these definitions useless (IINM we never see the notation + in the state machines and the notation ++ which is perhaps why this was included should either be defined directly or assumed understandable as it is said in section 3.1 "The interpretation of the special symbols and operators used in the state diagrams is as defined in Section 3.2; these symbols and operators are derived from the notation of the C++ programming language, ISO/IEC 14882.") BTW, I cannot find any use of - or -- in the document. And anyway, I think that in case + and - are however necessary for the comprehension of the document, it should be stated on which space they operate (N, Z/2**16Z, Z/2**32Z...) Comment #2 - Editorial This is about portEnabled and eapRestart. This discussion for what regards portEnabled is a follow-up on issues 198 and 203. I do still find the name of this variable too .1X centric and, in the light of the recent debates on corner cases on EAP starts and restarts, I'd prefer a more explicit name (like Yoshi had proposed for instance). Also I'd like the current definition (e.g. in section 4.1.1 "portEnabled (boolean) Indicates that the EAP peer state machine should be ready for communication. This is set to TRUE when the EAP conversation is started by the lower layer. If at any point the communication port or session is not available, portEnabled is set to FALSE and the state machine transitions to DISABLED.") clarified (and why not - two - example instantiations given, one .1x and one IKEv2 for instance) to take the "new"? problems into account (e.g. section 7.12 of RFC 3748b "In IEEE 802.11, a "link down" indication is an unreliable indication of link failure, since wireless signal strength can come and go and may be influenced by radio frequency interference generated by an attacker. To avoid unnecessary resets, it is advisable to damp these indications, rather than passing them directly to the EAP. Since EAP supports retransmission, it is robust against transient connectivity losses. " ) For eapRestart, my problem is much the same, two concrete examples (.1X, PPP or IKEv2 for instance) would considerably help understand what this variable stands for. Comment #3 - Editorial This is about the initialization of lastID which is not done in the EAP peer state machine. This had been pointed out in issue 229 but apparently not taken into account. Also specify, e.g. in section 4.3.1 that lastId may take the value "NONE" Comment #4 - Editorial This is about idleWhile. From my understanding, this timer steadily decreases and when it reaches 0, the peer may time out. Clearly, knowing the initial value of this timer, by a simple subtraction, one can get to know how long the peer has been waiting. So, contrary to the definition in section 4.1.1 ("idleWhile (integer) Outside timer used to indicate how long the peer has waited for a new (valid) request."), I'd rather say that this timer indicates how long remains before the peer may time out. Comment #5 - Technical That's just a triviality about for instance the peer state machine: thanks to EAP idleWhile, the method does not have to set timers (EAP cares for it). However, in case the method wants to implement a "bad packet received" counter (e.g. it is waiting for a packet and to provide DoS resilience it wants to allow receiving a limited number of "bad packets" before the right one - instead of going automatically to failure), it has to do so by itself (and typically will use altReject if it wants to fail before the timeout. This is not an issue but perhaps it could be worth discussing the usefulness of such a behavior for EAP methods (see e..G g. RFC 3748 section 7.5 "Whether a MIC validation failure is considered a fatal error or not is determined by the EAP method specification") and that it can indeed be implemented in the EAP state machines (with a little disymmetry between the timer implemented within EAP and the "bad packet received" counter implemented within the method. I guess this comment is a way for me to express that I wholeheartedly agree with the point .3 Joe made in issue 203 (in other words the imbrication of EAP and EAP methods confine to layer violation). Comment #6 - Technical This is about DONE, CONT and MAY_CONT/UNCOND_SUCC, COND_SUCC and FAIL. While I do not doubt that there are could technical reasons to use these variables (rather than simply CONT and DONE) and that the EAP state machine does not claim to be THE way to implement EAP (in its introduction "The State Machine and associated model are informative only. Implementations may achieve the same results using different methods"), I think that giving briefly the rationales behind this choice (which is not explicit in section 4.2 IMHO) would help the reader. In particular, giving an example of MAY_CONT's usefulness. About the decision variable, here also an explanation of the design (maybe with an example) could help. Indeed, it seems to me that not all pairs (state, decision) are acceptable so state/decision are not totally independent. Here again, giving an example why COND_SUCC was introduced could help. I think this concern is also related to the conditions in the state machine that allow the peer to transition to success or failure. They do not appear to be either trivial or symmetric. The newbie I unfortunately am, needs much more time to (fully) understand them than any other transition condition in the state machine. Bernard for instance questioned about these Success/Failure transitions in Issue 229. For instance, I am wondering, how the condition "altAccept && methodState != CONT && decision == FAIL" may occur. Also in section 4.2 I tend to feel dizzy with some text in the paragraph methodState=DONE: "If both (a) the server has informed us that it will allow access and the next packet will be EAP Success,and (b) we're willing to use this access, set decision=UNCOND SUCC." I guess that condition (a) should rather be formulated in terms of altAccept, shouldn't it? Indeed while IIRC RFC 3748 mandates (in section 4.2 "The authenticator MUST transmit an EAP packet with the Code field set to 3 (Success)" that a success packet be sent, this does not guarantee that the peer will ever receive it. Comment #7 - Editorial I do not find any definition of m.buildResp (that is used in Figure 3 EAP peer state machine) in section 4.4 Peer state machine procedures). Moreover, i would find it clearer if m.buildresp somehow indicated that it does not only depend on ReqId but also on some internal method state that has been calculated by m.process. Comment #8 - Editorial Although in section 4.4, it is said parseEapReq() "checks that the lengthfield is not longer than the received packet", I do not find it completely straightforward from Figure 3 what the peer does in case there is a parse error due to the length (or an invalid code type or...). Comment #9 - Technical Apparently Figure 4 (EAP Standalone Authenticator State Machine) leaves the door open to a sequence of EAP authentication methods (which is explicitly forbidden by RFC 3748 section 2.1 "However, the peer and authenticator MUST utilize only one authentication method (Type 4 or greater) within an EAP conversation"). This behavior may be prevented thanks to Policy.getDecision or PolicygetNextMethod... but I do not find this is exactly a matter of policy and at least, this should be pointed out (that the policy MUST forbid this behavior). Comment #10 - Technical Why include a separate TIMEOUT_FAILURE State? Why not use the FAILURE state? Comment #11 - Editorial eapTimeout does not seem to be defined in the text. Comment #12 - Technical This one is stupid but what happens, according to Figure 4, when the standalone authenticator fails directly, i.e. starts by INITIALIZE, transitions to SELECT_ACTION where Policy.getDecision replies FAILURE and thus transitions to FAILURE - in the FAILURE state, I bet there is some problem with eapReqData = buildFailure(currentId) since currentId=NONE Comment #13 - Editorial Why call section 5 "standalone authenticator"? I bet this is the old story of the glass half full or half empty, because I'd rather have standalone EAP server. Comment #14 - Technical I am totally novice to DoS (I found a lot of papers on the subject, for instance related to IKE - I plan to read them soon :-)) so this point is probably not very important (my understanding is that one of the difficulties with DoS is to understand what is really relevant and what rather belongs to the .11 microwave oven attack, another one could be set the trade off between DoS resilience and "efficiency"). It just seems to me that Figure 4 prevents the standalone authenticator from ignoring (bogus) NAKs. Indeed, let us consider a corporate WLAN deployment where exactly one EAP method is allowed - so that no valid user will ever NAK. In this setting, there is no point in processing the NAK, possibly loosing the valid user's response if the attacker's NAK arrived first and starting all over. I did not find text on this in RFC 3748 (the text I found was about preventing NAKs when a response to a method has already been received) which is not our case here. Comment #15 - Editorial The title of Section 6 is "EAP Backend Authenticator" which I find quite strange. I'd rather suggest "backend authentication server". Comment #16 - Editorial In section 6.2 we find: "The only difference is that some methods on the backend may support "picking up" a conversation started by the pass-through. That is, the EAP Request packet was sent by the pass-through, but the backend must process the corresponding EAP Response. Usually only the Identity method supports this, but others are possible" Would it be possible to explain whether this possibility is explicitly left open by some document (in this case, which one) or is implicitly allowed (and in this case, whether there are yet settings/implementations which use such a possibility). Comment #17 - Technical I fail to understand the transition in Figure 7 from INITIALIZE_PASSTHROUGH to AAA_IDLE when currentId==None, given that AAA_IDLE sets aaaEapResp=TRUE Comment #18 - Editorial If the purpose of aaaIdentity is to allow encapsulation of the peer's identity in e.g. RADIUS User-Name attribute, I'd rather have aaaIdentity be directly the identity of the peer than a whole EAP packet Comment #19 - General Just a late and useless remark, I tend to dislike EAP being too much 802.1X centric: EAP is (or at least should be) media independent. Therefore, the problems implied by splitting the server side into an authenticator and an authentication server do probably not belong (originally) to EAP. Thus, for the sake of clarity, I would rather have had two separate documents: one for the EAP state machine (peer and standalone server) and for the EAP state machines in case the server side is split (the split case is however also evoked in RFC 3748 - which I would also have avoided)... Florent, at least you know the reactions of naive reader while reading the EAP state machine ;-) _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From FZOBFX@inter.net.co Wed Jun 9 08:19:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11290 for ; Wed, 9 Jun 2004 08:19:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BY23D-00066I-C2 for eap-archive@ietf.org; Wed, 09 Jun 2004 08:19:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BY22F-0005GJ-00 for eap-archive@ietf.org; Wed, 09 Jun 2004 08:18:28 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BY20r-0003bB-00; Wed, 09 Jun 2004 08:17:01 -0400 Received: from cae168-192-090.sc.rr.com ([24.168.192.90]) by mx2.foretec.com with smtp (Exim 4.24) id 1BY20q-0003I3-BO; Wed, 09 Jun 2004 08:17:01 -0400 X-Message-Info: 0O944JSUhq96ETDFAcacRIGepaYO389ivuFEDmqiGyCJN13O4 Received: (from prowess@24.168.192.90) by corrupt2.156.14.102.136 (C.DF.3/D.90.9) id pa0A4AmF455F; Wed, 09 Jun 2004 17:14:41 +0400 Message-ID: Reply-To: "Carla Ott" From: "Carla Ott" To: "Edu-team-web-archive" Subject: bloodpressure,cancer,flu,health,American doctors directoty Date: Wed, 09 Jun 2004 12:07:41 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--E0E5BF3EEDF8839AADB9" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_UNTITLED,LINES_OF_YELLING,LINES_OF_YELLING_2,ORDER_NOW autolearn=no version=2.60 ----E0E5BF3EEDF8839AADB9 Content-Type: text/plain; charset="iso-B202-7" Content-Transfer-Encoding: quoted-printable Untitled Document EXCLUSIVELY ON CD-ROM.

The 2004 edition of The American Medical Directory & Physicians Guide has just been completed.

physicians, specialists, doctors, licensed doctors,
board physicians, emergency physicians, 2004 physicians guide,
2004 physicians directory, physicians contact.

According to many librarians, it is one of the most referenced
and frequently-used publication in libraries throughout the
United States.

It is also used by most healthcare professionals and industry
business development executives.

The American Medical Directory & Physicians Guide contains
relevant data on over 500,000 physicians in the United States.

Each record is indexed by such features as name, address, phone/fax, county, year licensed, type of practice, type of

physician, as well as primary and secondary specialty.

During this introductory offer, the cost of the new directory
(which is available exclusively on CD-Rom) is $425.00 (reg. $795).

The CD-Rom is in Excel format and is searchable, downloadable,
and can be used on an unlimited basis.

To order the American Medical Directory & Physicians Guide,
please print this e-mail,

complete the information below and fax it to 905-751-0199.
(tel: 905-751-0919).

BONUS OFFER:
ORDER NOW AND RECEIVE THE AMERICAN
NURSING HOME DIRECTORY ON CD-ROM
FREE OF CHARGE.

NAME:

TITLE:

ORGANIZATION:

ADDRESS:

CITY:

POSTAL:

TEL:

FAX:

E-MAIL:

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

----E0E5BF3EEDF8839AADB9-- From eap-admin@frascone.com Wed Jun 9 14:10:20 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05946 for ; Wed, 9 Jun 2004 14:10:19 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5CD3620ED0; Wed, 9 Jun 2004 13:57:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 24BCE20ECB; Wed, 9 Jun 2004 13:57:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 080D220ECB for ; Wed, 9 Jun 2004 13:56:40 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 0AFAB20EC1 for ; Wed, 9 Jun 2004 13:56:38 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i59IB2A06816 for ; Wed, 9 Jun 2004 11:11:02 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] EAP SM 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: Wed, 9 Jun 2004 11:11:02 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) I've filed Florent's EAP SM review as three separate issues: 247 (Editorial issues), 248 (Technical) and 249 (General). The document has passed EAP WG last call, IETF last call, and IESG review, and is therefore no longer under EAP WG change control, so all changes must be approved by the IESG at this point. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From firemaniy@catchamail.com Wed Jun 9 22:41:29 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13027 for ; Wed, 9 Jun 2004 22:41:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYFVS-00021j-0R for eap-archive@ietf.org; Wed, 09 Jun 2004 22:41:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYFU9-00015J-00 for eap-archive@ietf.org; Wed, 09 Jun 2004 22:40:11 -0400 Received: from [221.198.141.245] (helo=L3U8Y2) by ietf-mx with smtp (Exim 4.12) id 1BYFSg-00079j-00; Wed, 09 Jun 2004 22:38:39 -0400 X-Message-Info: NWBGcOU21jWBw/yUsUXnnLzEwHtiNo2L Received: from come-b38.close.aol.com ([26.64.147.247]) by jm1-l13.hotmail.com with Microsoft SMTPSVC(5.0.2195.6824); Thu, 10 Jun 2004 06:38:19 +0300 From: Trinidad Gamble To: cfrg@ietf.org Subject: Newsletter #1387 Date: Wed, 09 Jun 2004 22:29:19 -0500 EST Message-ID: <37063627390725.92166.88469543@pastor-w80.aol.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--02396606481091721437" X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=5.6 required=5.0 tests=FRONTPAGE,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_GREEN,HTML_FONTCOLOR_RED, HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE,LINES_OF_YELLING, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,STOCK_PICK,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 X-Spam-Report: * 1.2 STOCK_PICK BODY: Offers a picked stock * 0.8 HTML_30_40 BODY: Message is 30% to 40% HTML * 0.1 HTML_FONTCOLOR_GREEN BODY: HTML font color is green * 0.1 HTML_FONTCOLOR_BLUE BODY: HTML font color is blue * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red * 1.6 FRONTPAGE BODY: Frontpage used to create the message * 0.2 SUBJ_HAS_UNIQ_ID Subject contains a unique ID * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts ----02396606481091721437 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable New Page 4

****DCPI****DCPI****DCPI****DCPI****DCPI****DCPI****DCPI***DCPI****= DCPI***


 New York Times Financial Digest
 Investor Alert on New Hot Issue
 


 Take a look at our some of our most recent Strong Buy recommendations...

November GDVI at 0.04 High 0.29...625% Gain!
December HTSC at 0.70 High 2.95...329% Gain!
March/April DMTY at 0.30 High 0.90...300%Gain!
April IPYS at 0.38 High 1.10...189%Gain in two days !
 May/June          EESI at 0.0= 3         High  0.95..= 317% Gain in three days !
June            =   DCPI at  1.25 Don't Miss Out!  300%  Gains Expected.....

(OTC-BB: DCPI) DCPI has developed a revolutionary digital printing technology recognized = to be the solution to variable graphical/color printing processes by industry le= aders such as IBM (NYSE: IBM); XEROX (NYSE: XRX) and Siemens(NYSE: SI) whose = products only print in black via laser products.  DCPI's commerci= al printing application hardware/software and printing consumable products are expecte= d to dominate the printing "enhancement" market ($5 Billion plus++ in= 2002) over the next several years.  DCPI's initial target market of more than 4,000 = large scale commercial printing companies of the total of 46,000 establishments is exp= ected to drive revenue growth to the tens of millions within its first few years= , further providing an ongoing revenue stream from the sales of printing consumable products for years to come.

 SPECIAL INVESTMENT ALERT

Digital Color Print, Inc. (OTC Bulletin Board: DCPI)
 Current Price: $1.25
Shares Outstanding: 24.6 Million
Market Capitalization: $31 Million
 Short Term Target: $3.00
12 month Target: $9.00

 A Few Reasons to Own DCPI:

Digital Color Print, Inc. ("DCPI"), through it's wholly owned su= bsidiary Logical Imaging Solutions ("LIS"), is in the business of supplying high-= speed digital printing systems and supplies to the commercial printing industry. The pri= nting systems are unique in technical concept and application. The systems are t= otally digital, designed to mount on existing offset web presses and significantl= y improve the functionality of the press, not as a replacement - but as an enhancement. The printing process is called Electron Beam Imaging ("E= BI"), and is significantly faster the convention laser printing - the only partially= competing technology.

Printing is America's third largest manufacturing industry; employing more= than 1.2 million people in almost 46,000 establishments. The printing industry,= during 2002, produced over $165 billion of printed products and purchased = $4.5 billion of hardware and $7.7 billion of consumable products.  NYSE-li= sted Dover Corporation, the largest manufacturer of offset web presses, estimates tha= t there are more than 35,000 presses installed in the U.S., with a press cos= ting from $150,000 to several million and using as much as $10,000 of consumabl= e products per month.

Offset presses print all types of documents; forms, labels, tickets, tags,= advertisements and direct mail pieces, at production rates of 500 pages-per-minute ("ppm") to thousands of ppm. However, the print= ed materials produced are each identical, as each image printed is the "offset&quo= t; inked image derived from the printing plates that are mounted on the offset press. The= great limitations of the offset process are that each image (page) remains ident= ical unless the printing plates are changed. Also the inking of the plates requ= ires the laborious tasks of mixing the inks for each plate, inking the plates a= nd then cleaning the press for the next job. If the print job requires variab= le information, such as; name, address, bar codes, dates, prices, this must b= e added in a distinctly separate print operation. Typically this task is per= formed by expensive data processing laser printers, manufactured by either Xerox,= IBM or Oce' (Formerly, Siemens Printing Systems). The laser printers print onl= y in black.

LIS printing systems are designed to mount directly on most offset web pre= sses and allow for the printing of any type of data or graphics, without limita= tion, and in line with the offset presses traditional production of a colorful e= nd product. As a simple example: In the production of an event ticket such as= a "Superbowl" ticket, all fixed or non-variable information, such as the "colorful = photo-quality" front cover and the stadium rules and disclaimers on t= he reverse side of the ticket are produced by plates on an offset press; identical information on each ticket. A second printing process is then required to = add the variable information, which includes the section, seat and row numbers= , price and date of the event. This function can be accomplished, in line, b= y an LIS provided system.

LIS printing systems are entirely digital and are dry "Toner" ba= sed, which precludes the laborious press set-up and clean-up tasks, ink mixing and st= orage and the production of printing plates. The pressman simply runs the paper = directly through LIS's printer and it becomes an integral part of the pres= s and the starting and stopping of the press and the placement of the digital ob= ject on the page are all under the control of LIS proprietary software.

NYSE-listed Dover Corporation, the largest manufacturer of offset web pres= ses, estimates that there are more than 35,000 presses installed in the U.S., w= ith a press costing from $150,000 to several million and using as much as $10,00= 0 of consumable products per month.  DCPI's DIGITALCOLORPRESS was designed= to be installed on the majority of these presses, extending their life and utili= ty by providing the printing of computer generated variable data in-line with th= e offset printing function. Further, the system eliminates the need for prep= aring and storing printing plates, and inks and the expensive tasks of setting u= p a press for a print run, followed by tearing down after each job, cleaning t= he press and setting up for the next print job. DCPI estimates that the major= ity of printers will upgrade to color during the first two years of the DIGITALCOLORPRESS availability and thousands more  commercial printer= s will purchase systems through DCPI's direct sales force and distribution channe= l during the next two years.

DCPI's first growth step is to increase consumable inventory to support ex= isting LIS systems, each installation generates about $6,000 per month in consuma= ble purchases. Secondly, to make LIS's unique color press available from inven= tory and expand the current number of installed sites. Thirdly, make the produc= t offering available to the commercial printing industry. Large tasks, but currently without any perceived competition or technological limitation.
This stock will see major upward movement in the next several weeks. Ri= ght now, DCPI is one of the Street's best kept secrets, but it will not remain= that way for long. This is a unique opportunity to get in while trading levels = are still low. As the Company goes forward with its business plan and signs ma= jor new contracts, this stock will move quickly. This is your last chance to i= nvest before DCPI begins major price appreciation. This stock could reach $3.50 = in the next five trading days!



 The writers, PR firm, mailers involved in the creation, and distribution o= f the information above are not a registered broker/dealer and may not sell, off= er to sell or offer to buy any security. This profile is not a solicitation or recommendation to buy, sell securities. An offer to buy or sell can be mad= e only with accompanying disclosure documents from the company offering or sellin= g securities and only in the states and provinces for which they are approve= d. The material in this release is intended to be strictly informational and base= d on assumptions rather than fact. The companies that are discussed in this rel= ease have not approved the statements made in this release nor approved the tim= ing of this release. All statements and expressions are the sole opinion of the creators and are subject to change without notice. Information in this rel= ease is derived from a variety of sources including that company's publicly disseminated information, third parties and the writers research and optim= istic speculation. The accuracy or completeness of the information is not warran= ted and is only as reliable as the sources from which it was obtained. All inv= olved in the creation and distribution of this profile/release disclaims any and= all liability as to the completeness or accuracy of the information contained = and any omissions of material fact in this release. The release may contain technical and factual inaccuracies or typographical errors. It is strongly= recommended that any purchase or sale decision be discussed with a financi= al adviser, or a broker-dealer, or a member of any financial regulatory bodie= s. Investment in the securities of the companys discussed in this release is = highly speculative and carries a high degree of risk. All persons involved in the= creation and distribution of the information in this letter is not liable = for any investment decisions by its readers or subscribers. Investors are caut= ioned that they may lose all or a portion of their investment if they make a pur= chase in this security mentioned. Any mention of past profiles and returns are n= ot our stock picks.

This profile is not without bias, and is a paid release. Writers and maile= rs have been compensated for the dissemination of company information on beha= lf of one or more of the companies mentioned in this release. Parties involved i= n the creation and distribution of this profile have been compensated 40,000 dol= lars by a third party (third party), who is nonaffiliated, for services provide= d including dissemination of company information in this release. PR and oth= er individuals and other creators and mailers of this letter will sell all of= its original shares during the distribution of this profile. Parties involved = may immediately sell some or any shares in a profiled company held by profile = creators and may have previously sold shares in a profiled company held by= PR Individuals involved. Our Optin mailing services for a company may cause t= he company's stock price to increase, in which event involved parties would m= ake a profit when it sells its stock in the company. In addition, our selling of= a company's stock may have a negative effect on the market price of the stoc= k. The past profiles are only the winners not all of our recommendations.

 

 ----02396606481091721437-- From eap-admin@frascone.com Thu Jun 10 01:40:24 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21690 for ; Thu, 10 Jun 2004 01:40:23 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 19932209BA; Thu, 10 Jun 2004 01:27:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 491A9206BC; Thu, 10 Jun 2004 01:27:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9A3BA206B6 for ; Thu, 10 Jun 2004 01:26:55 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id AFD1320674 for ; Thu, 10 Jun 2004 01:26:53 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 7F32189870; Thu, 10 Jun 2004 08:40:04 +0300 (EEST) Message-ID: <40C7F33D.6060806@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Florent Bersani Cc: eap@frascone.com Subject: Re: [eap] Another two minor and finicky IANA considerations questions for RFC3748 References: <40C59C27.6070209@rd.francetelecom.fr> In-Reply-To: <40C59C27.6070209@rd.francetelecom.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 10 Jun 2004 08:35:57 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Florant, Thanks again for looking into the details! > While reviewing again RFC 3748b, I just came across two little (and > fairly uninteresting I admit) questions/remarks (that may however help > RFC 3748 understanding in the future: > > 1) It is apparently not specified how expanded (method) types for > vendor-ID 0 (IETF) can be allocated (e.g. Designated Expert, with > Specification Required or standards action, FCFS, ...). > In section 6.2 we indeed only read: > "Method Type values 256-4294967295 may be allocated after Type values > 1-191 have been allocated." > I know we've probably got time before this happens but I just feel > reluctant to leave an incomplete spec behind us ;-) I think it would make sense to add ", through the advice of a Designated Expert, with Specification Required" to the end of the sentence that you quoted. Henrik tells me that he still can send a change to the RFC editor. > 2) The (non)-use of 0 as packet code or method type > > The newbie I am is pretty sure that there are good reasons why EAP did > not start its code and type space at 0 (and I'd be more than thankful to > anybody who could tell me why) but I find the current wording about not > using this value a (very little) bit confusing. I'm not sure what the history was. We probably shouldn't allocate that number to anyone, someone's code might break if it uses 0 to represent "no method" or "no EAP" or something like that. > In section 6.1 of RFC 3748b we read: > "Packet Codes have a range from 1 to 255" and on the IANA website > (http://www.iana.org/assignments/eap-numbers) we find: > > "(last updated 12 April 2004) > Packet Codes: > Value Description Reference > 1 Request [RFC-ietf-eap-rfc2284bis-09.txt] > 2 Response [RFC-ietf-eap-rfc2284bis-09.txt] > 3 Success [RFC-ietf-eap-rfc2284bis-09.txt] > 4 Failure [RFC-ietf-eap-rfc2284bis-09.txt] > 5-255 Unallocated" > > In section 6.2 of RFC 3748b we read: > "The original EAP method Type space has a range from 1 to 255" and on > the IANA website (http://www.iana.org/assignments/eap-numbers) we find: > > "(last updated 12 April 2004) > ... > Value Description Reference > 0 RESERVED > 1 Identity [RFC-ietf-eap-rfc2284bis-09.txt] > ..." > > Indeed, the value 0 is used in the NAK response. > > My suggestion would be to find a way to simply reflect this usage in RFC > 3748 and for IANA. > My preference would be adding a small reminder on the value 0 usage in > RFC 3748 section 6.2 and updating the IANA website to also refer to RFC > 3748 for this value. I am ready to propose some text if people feel like > making this minor and unimportant change. I think we could add "0 RESERVED" to the IANA page of packet codes (after we have published the RFC). > P.S: BTW, it seems like we (EAP and/or IANA) have not captured the point > I raised earlier on Method Type 7&8 > (http://mail.frascone.com/pipermail/public/eap/2004-May/002486.html). > Again, I am ready to propose some text if people feel like making this > minor and unimportant change (and I concurred to Jari's proposal > "allocated but unused"). There has been some new confusion about the exact status of 7 & 8. We don't want to say anything about them at this point in time, at least not in RFC 3748. I think we can update the IANA web page later if we get more confident that they indeed are not used. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Jun 10 03:58:20 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11130 for ; Thu, 10 Jun 2004 03:58:20 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 543B220406; Thu, 10 Jun 2004 03:45:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AA92720A9F; Thu, 10 Jun 2004 03:45:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BA1DD20A9F for ; Thu, 10 Jun 2004 03:44:13 -0400 (EDT) Received: from av3-1-sn1.fre.skanova.net (av3-1-sn1.fre.skanova.net [81.228.11.109]) by mail.frascone.com (Postfix) with ESMTP id 0CB4520406 for ; Thu, 10 Jun 2004 03:44:12 -0400 (EDT) Received: by av3-1-sn1.fre.skanova.net (Postfix, from userid 502) id 07C7B3809C; Thu, 10 Jun 2004 09:57:24 +0200 (CEST) Received: from smtp3-1-sn1.fre.skanova.net (smtp3-1-sn1.fre.skanova.net [81.228.11.163]) by av3-1-sn1.fre.skanova.net (Postfix) with ESMTP id ED2AF37E54; Thu, 10 Jun 2004 09:57:23 +0200 (CEST) Received: from chardonnay.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp3-1-sn1.fre.skanova.net (Postfix) with ESMTP id 1785037E51; Thu, 10 Jun 2004 09:57:17 +0200 (CEST) Received: from chardonnay ([127.0.0.1]) by chardonnay.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1BYKQu-00026B-00; Thu, 10 Jun 2004 09:57:08 +0200 From: Henrik Levkowetz To: jari.arkko@piuha.net Cc: Florent Bersani , eap@frascone.com Subject: Re: [eap] Another two minor and finicky IANA considerations questions for RFC3748 Message-Id: <20040610095707.5219a901@chardonnay> In-Reply-To: <40C7F33D.6060806@piuha.net> References: <40C59C27.6070209@rd.francetelecom.fr> <40C7F33D.6060806@piuha.net> X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 10 Jun 2004 09:57:07 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi, Thursday 10 June 2004, Jari Arkko wrote in reply to Florent: > > 1) It is apparently not specified how expanded (method) types for > > vendor-ID 0 (IETF) can be allocated (e.g. Designated Expert, with > > Specification Required or standards action, FCFS, ...). > > In section 6.2 we indeed only read: > > "Method Type values 256-4294967295 may be allocated after Type values > > 1-191 have been allocated." > > I know we've probably got time before this happens but I just feel > > reluctant to leave an incomplete spec behind us ;-) > > I think it would make sense to add ", through the advice of a > Designated Expert, with Specification Required" to the end of the sentence > that you quoted. Henrik tells me that he still can send a change > to the RFC editor. Ok, so the proposed change is as follows: Section 6.2., para. 3: OLD: Method Type 254 is allocated for the Expanded Type. Where the Vendor-Id field is non-zero, the Expanded Type is used for functions specific only to one vendor's implementation of EAP, where no interoperability is deemed useful. When used with a Vendor-Id of zero, method Type 254 can also be used to provide for an expanded IETF method Type space. Method Type values 256-4294967295 may be allocated after Type values 1-191 have been allocated. NEW: Method Type 254 is allocated for the Expanded Type. Where the Vendor-Id field is non-zero, the Expanded Type is used for functions specific only to one vendor's implementation of EAP, where no interoperability is deemed useful. When used with a Vendor-Id of zero, method Type 254 can also be used to provide for an expanded IETF method Type space. Method Type values 256-4294967295 may be allocated after Type values 1-191 have been allocated, on the advice of a Designated Expert, with Specification Required. I'll send it in. Henrik _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Jun 10 03:58:37 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11148 for ; Thu, 10 Jun 2004 03:58:37 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CBEFE20A9F; Thu, 10 Jun 2004 03:45:16 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D3FB320AA3; Thu, 10 Jun 2004 03:45:07 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7E24220A9F for ; Thu, 10 Jun 2004 03:44:16 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by mail.frascone.com (Postfix) with ESMTP id 8756A20406 for ; Thu, 10 Jun 2004 03:44:14 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 10 Jun 2004 09:57:33 +0200 Received: from rd.francetelecom.fr ([10.193.167.110]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Thu, 10 Jun 2004 09:57:20 +0200 Message-ID: <40C81524.7080703@rd.francetelecom.fr> From: Florent Bersani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 10 Jun 2004 07:57:20.0033 (UTC) FILETIME=[8E3DF910:01C44EC0] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Some (minor) editorial comments on RFC 3748b 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, 10 Jun 2004 10:00:36 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 8bit Hi all, Below are some (minor) editorial comments that came to my mind while reading the latest version of EAP I am aware of (RFC 3748.b). Much like my comments on the EAP state machine, I know that these comments may come much too late :-(( Hence, I included in this mail only the editorial comments that I think are (relatively) easy to address (in a mail to come, I'll formalize my other technical and general comments on EAP, being aware that they can't be taken into account for they come well after the battle) Comment #1 Section 1.2 Some entries start with a capital letter (e.g. Supplicant, Displayable Message, ...) while others do not (authenticator, peer,...). Suggested change: adopt a constant behavior (namely start all entries with a capital letter) This capitalization problem is all the more shocking with "authenticator" because this entry is written "authenticator" and in the definition text we may read authenticator with a capital A ("The term Authenticator is used in [IEEE-802.1X ], and has the same meaning in this document.") Suggested change: adopt a constant behavior for this term throughout the document. Comment #2 Section 1.2 I disagree with the RFC 3748 definition of MIC: "Message Integrity Check (MIC) A keyed hash function used for authentication and integrity protection of data. This is usually called a Message Authentication Code (MAC), but IEEE 802 specifications (and this document) use the acronym MIC to avoid confusion with Medium Access Control." Keying a hash function is not the only cryptographic way to provide data origin authentication and I do not see why EAP mandates such a restriction for its MICs. Suggested changes: either adopt/adapt the IEEE 802.11i definition "Message Integrity Code (MIC): A value generated by a symmetric key cryptographic function. If the input data is changed, a new value cannot be correctly computed without knowledge of the symmetric key. Thus, the secret key protects the input data from undetectable alteration. This is traditionally called a Message Authentication Code, or MAC, but the acronym MAC is already reserved for another meaning in this standard." (BTW, IEEE 802.11i quite logically mandates MIC/MAC to come from symmetric key cryptography since this is how the term MAC is commonly used, however it again worth noting that there are asymmetric techniques than can also provide data origin authentication - IINM, symmetric cryptography is rather used for data origin authentication for performance reasons) or this one "Message Integrity Code (MIC) Informally, the purpose of a MIC is to facilitate, without the use of any additional mechanisms, assurances regarding both the source of a message and its integrity, please refer to [HAC] for more details This is usually called a Message Authentication Code (MAC), but IEEE 802 specifications (and this document) use the acronym MIC to avoid confusion with Medium Access Control." where [HAC] = Menezes, A. et al., “Handbook of Applied Cryptography”, CRC Press, 1996. Comment #3 Section 1.2 Rearrange section 1.2 with the entries sorted in alphabetical order to improve readability Comment #4 Section 5.1 2nd paragraph typo: replace "Some EAP implementations piggy-back various options into the Identity Request after a NUL-character" with "Some EAP implementations piggy-back various options into the Identity Request after a NULL-character" (the typo is on NULL IINM) Also, it appears that sometimes NULL is capitalized, sometimes it isn't. Suggested change: adopt a constant behavior Hope this helps and you aren't upset by my being so particular about EAP WG documents, Florent _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Jun 10 06:55:19 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18652 for ; Thu, 10 Jun 2004 06:55:19 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 35DA420F5D; Thu, 10 Jun 2004 06:42:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D4997206DC; Thu, 10 Jun 2004 06:42:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8A869206DC for ; Thu, 10 Jun 2004 06:41:27 -0400 (EDT) Received: from mailgw.local.ipunplugged.com (unknown [213.80.52.78]) by mail.frascone.com (Postfix) with ESMTP id 94AD020379 for ; Thu, 10 Jun 2004 06:41:25 -0400 (EDT) Received: from zinfandel.local.ipunplugged.com (chardonnay.local.ipunplugged.com [192.168.4.44]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with SMTP id i5AAsaMI020678; Thu, 10 Jun 2004 12:54:38 +0200 From: Henrik Levkowetz To: Florent Bersani Cc: "eap@frascone.com" Subject: Re: [eap] Some (minor) editorial comments on RFC 3748b Message-Id: <20040610125435.3fd1f55a@zinfandel.local.ipunplugged.com> In-Reply-To: <40C81524.7080703@rd.francetelecom.fr> References: <40C81524.7080703@rd.francetelecom.fr> X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.72, clamav-milter version 0.72 on mailgw.local.ipunplugged.com X-Virus-Status: Clean 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, 10 Jun 2004 12:54:35 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Florent, You're rather impressive in your ability to see mistakes in details, aren't you! :-) On Thursday, 10 Jun 2004, Florent Bersani wrote: ... > Comment #1 > > Section 1.2 > > Some entries start with a capital letter (e.g. Supplicant, Displayable > Message, ...) while others do not (authenticator, peer,...). > Suggested change: adopt a constant behavior (namely start all entries > with a capital letter) > > This capitalization problem is all the more shocking with > "authenticator" because this entry is written "authenticator" and in the > definition text we may read authenticator with a capital A ("The term > Authenticator is used in [IEEE-802.1X], > and has the same meaning in this document.") > Suggested change: adopt a constant behavior for this term throughout the > document. Proposed change: Section 1.2, para. 2: OLD: authenticator The end of the link initiating EAP authentication. The term Authenticator is used in [IEEE-802.1X], and has the same meaning in this document. NEW: authenticator The end of the link initiating EAP authentication. The term authenticator is used in [IEEE-802.1X], and has the same meaning in this document. > Comment #2 > > Section 1.2 > > I disagree with the RFC 3748 definition of MIC: .... Someone else will have to take a position on this one, I can't argue strongly either way. > > Comment #3 > > Section 1.2 > > Rearrange section 1.2 with the entries sorted in alphabetical order to > improve readability I'd rather not do this now... > Comment #4 > > Section 5.1 2nd paragraph typo: replace "Some EAP implementations > piggy-back various options into the Identity Request after a > NUL-character" with "Some EAP implementations piggy-back various options > into the Identity Request after a NULL-character" (the typo is on NULL IINM) Nope, here the name of the ASCII character is "NUL", not "NULL". Other places in the document the term "null" is used as a term in itself, and then I've spelled it "null", indeed. There's one place where I've missed this distinction though, giving this correction: Appendix A., para. 12: OLD: o It is now required in Section 5.1 that if the Type-Data field of an Identity Request contains a null character, only the part before the null is displayed. RFC 2284 prohibits the Null termination of the Type-Data field of Identity messages. This rule has been relaxed for Identity Request messages and the Identity Request Type-Data field may now be null terminated. NEW: o It is now required in Section 5.1 that if the Type-Data field of an Identity Request contains a NUL-character, only the part before the null is displayed. RFC 2284 prohibits the null termination of the Type-Data field of Identity messages. This rule has been relaxed for Identity Request messages and the Identity Request Type-Data field may now be null terminated. > Hope this helps and you aren't upset by my being so particular about EAP > WG documents, Sooner (during last call, for instance :) would have been better, but now is better than never, as far as I'm concerned. No upsets. Regards, Henrik _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From pnzmohwotwz@yahoo.com Thu Jun 10 07:04:38 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18966 for ; Thu, 10 Jun 2004 07:04:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYNMK-0001GG-GN for eap-archive@ietf.org; Thu, 10 Jun 2004 07:04:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYNLB-0000Hy-00 for eap-archive@ietf.org; Thu, 10 Jun 2004 07:03:25 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BYNJp-0006fV-00 for eap-archive@ietf.org; Thu, 10 Jun 2004 07:02:01 -0400 Received: from [221.152.36.213] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1BYNJr-0006UG-4K for eap-archive@ietf.org; Thu, 10 Jun 2004 07:02:04 -0400 Content-Type: text/html; MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Subject: Fwd: what is this? From: "Issac Bridges" To: eap-archive@ietf.org X-Priority: 3 Date: Thu, 10 Jun 2004 11:00:28 -0100 Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=7.5 required=5.0 tests=FORGED_RCVD_NET_HELO, FORGED_YAHOO_RCVD,HTML_40_50,HTML_IMAGE_ONLY_04,HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,PRIORITY_NO_NAME, RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.5 HTML_IMAGE_ONLY_04 BODY: HTML: images with 200-400 bytes of words * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 3.0 FORGED_RCVD_NET_HELO Host HELO'd using the wrong IP network * 0.5 FORGED_YAHOO_RCVD 'From' yahoo.com does not match 'Received' headers * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer Content-Transfer-Encoding: 7Bit He delegated his power to Osaul Tovkatch, and gave with it a strict command to appear with his whole force at the Setch the very instant he should receive a message from him.














Stop further messages

It has as many victims recorded against it as has the saloon, and its work of destruction is. The coal glowed in the grate with a splendid blaze: all the gas-burners were lighted, and so were everybody's eyes. From eap-admin@frascone.com Thu Jun 10 07:06:34 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19080 for ; Thu, 10 Jun 2004 07:06:34 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7386320F63; Thu, 10 Jun 2004 06:53:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E35D72029F; Thu, 10 Jun 2004 06:53:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8AFE620F62 for ; Thu, 10 Jun 2004 06:51:55 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 4FF6920CDB for ; Thu, 10 Jun 2004 06:51:53 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 116CE8986F; Thu, 10 Jun 2004 14:05:05 +0300 (EEST) Message-ID: <40C83F6A.7010909@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: Henrik Levkowetz Cc: Florent Bersani , "eap@frascone.com" Subject: Re: [eap] Some (minor) editorial comments on RFC 3748b References: <40C81524.7080703@rd.francetelecom.fr> <20040610125435.3fd1f55a@zinfandel.local.ipunplugged.com> In-Reply-To: <20040610125435.3fd1f55a@zinfandel.local.ipunplugged.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 10 Jun 2004 14:00:58 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi, I agree with the edits that Florent and Henrik propose below. I don't think we should change the MIC definition, or rearrange text parts (comment #3) now. --Jari Henrik Levkowetz wrote: > Hi Florent, > > You're rather impressive in your ability to see mistakes in details, > aren't you! :-) > > On Thursday, 10 Jun 2004, Florent Bersani wrote: > ... > >>Comment #1 >> >>Section 1.2 >> >>Some entries start with a capital letter (e.g. Supplicant, Displayable >>Message, ...) while others do not (authenticator, peer,...). >>Suggested change: adopt a constant behavior (namely start all entries >>with a capital letter) >> >>This capitalization problem is all the more shocking with >>"authenticator" because this entry is written "authenticator" and in the >>definition text we may read authenticator with a capital A ("The term >>Authenticator is used in [IEEE-802.1X], >>and has the same meaning in this document.") >>Suggested change: adopt a constant behavior for this term throughout the >>document. > > > Proposed change: > Section 1.2, para. 2: > OLD: > > authenticator > The end of the link initiating EAP authentication. The term > Authenticator is used in [IEEE-802.1X], and has the same > meaning in this document. > > NEW: > > authenticator > The end of the link initiating EAP authentication. The term > authenticator is used in [IEEE-802.1X], and has the same > meaning in this document. > > > >>Comment #2 >> >>Section 1.2 >> >>I disagree with the RFC 3748 definition of MIC: > > .... > > Someone else will have to take a position on this one, I can't argue > strongly either way. > > >>Comment #3 >> >>Section 1.2 >> >>Rearrange section 1.2 with the entries sorted in alphabetical order to >>improve readability > > > I'd rather not do this now... > > >>Comment #4 >> >>Section 5.1 2nd paragraph typo: replace "Some EAP implementations >>piggy-back various options into the Identity Request after a >>NUL-character" with "Some EAP implementations piggy-back various options >>into the Identity Request after a NULL-character" (the typo is on NULL IINM) > > > Nope, here the name of the ASCII character is "NUL", not "NULL". Other > places in the document the term "null" is used as a term in itself, and > then I've spelled it "null", indeed. There's one place where I've missed > this distinction though, giving this correction: > > Appendix A., para. 12: > OLD: > > o It is now required in Section 5.1 that if the Type-Data field of > an Identity Request contains a null character, only the part > before the null is displayed. RFC 2284 prohibits the Null > termination of the Type-Data field of Identity messages. This > rule has been relaxed for Identity Request messages and the > Identity Request Type-Data field may now be null terminated. > > NEW: > > o It is now required in Section 5.1 that if the Type-Data field of > an Identity Request contains a NUL-character, only the part > before the null is displayed. RFC 2284 prohibits the null > termination of the Type-Data field of Identity messages. This > rule has been relaxed for Identity Request messages and the > Identity Request Type-Data field may now be null terminated. > > > > >>Hope this helps and you aren't upset by my being so particular about EAP >>WG documents, > > > Sooner (during last call, for instance :) would have been better, > but now is better than never, as far as I'm concerned. No upsets. > > Regards, > > Henrik > _______________________________________________ > 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 spokesmendh@flashmail.com Thu Jun 10 07:10:52 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19379 for ; Thu, 10 Jun 2004 07:10:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYNSL-00071V-IR for eap-archive@ietf.org; Thu, 10 Jun 2004 07:10:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYNQu-00061G-00 for eap-archive@ietf.org; Thu, 10 Jun 2004 07:09:22 -0400 Received: from pns03-204-157.inter.net.il ([80.230.204.157]) by ietf-mx with smtp (Exim 4.12) id 1BYNPM-0003Kw-00; Thu, 10 Jun 2004 07:07:49 -0400 X-Message-Info: IFSTeWQ2sFGbCe07Xd0+APLAm2cTIBP Received: from ukeuddar12.cox.net ([90.240.66.70]) by mp01-f58.hotmail.com with Microsoft SMTPSVC(5.0.2195.6824); Tue, 11 May 2004 16:04:41 +0300 Received: from Rosalieo27z1hmv5t ([163.32.49.0]) by fpqpdvsy53.cox.net (InterMail vM.5.01.06.05 201-253-122-130-105-0937476) with SMTP id <19992678567864.OIZO3308.fchsqmys20.cox.net@furrierh30p2juy9v> for ; Tue, 11 May 2004 08:57:41 -0400 Message-ID: <096120f7s136$46363668$lp3d1795@Rosalies82n2hqd7o> From: "Gena Helms" To: Subject: Newsletter #8970 Date: Tue, 11 May 2004 09:04:41 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--84481154772125994311" X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=5.6 required=5.0 tests=FRONTPAGE,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_GREEN,HTML_FONTCOLOR_RED, HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE,LINES_OF_YELLING, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,STOCK_PICK,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 X-Spam-Report: * 1.2 STOCK_PICK BODY: Offers a picked stock * 0.8 HTML_30_40 BODY: Message is 30% to 40% HTML * 0.1 HTML_FONTCOLOR_GREEN BODY: HTML font color is green * 0.1 HTML_FONTCOLOR_BLUE BODY: HTML font color is blue * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red * 1.6 FRONTPAGE BODY: Frontpage used to create the message * 0.2 SUBJ_HAS_UNIQ_ID Subject contains a unique ID * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts ----84481154772125994311 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable New Page 4

****DCPI****DCPI****DCPI****DCPI****DCPI****DCPI****DCPI***DCPI****= DCPI***


 New York Times Financial Digest
 Investor Alert on New Hot Issue
 


 Take a look at our some of our most recent Strong Buy recommendations...

November GDVI at 0.04 High 0.29...625% Gain!
December HTSC at 0.70 High 2.95...329% Gain!
March/April DMTY at 0.30 High 0.90...300%Gain!
April IPYS at 0.38 High 1.10...189%Gain in two days !
 May/June          EESI at 0.0= 3         High  0.95..= 317% Gain in three days !
June            =   DCPI at  1.25 Don't Miss Out!  300%  Gains Expected.....

(OTC-BB: DCPI) DCPI has developed a revolutionary digital printing technology recognized = to be the solution to variable graphical/color printing processes by industry le= aders such as IBM (NYSE: IBM); XEROX (NYSE: XRX) and Siemens(NYSE: SI) whose = products only print in black via laser products.  DCPI's commerci= al printing application hardware/software and printing consumable products are expecte= d to dominate the printing "enhancement" market ($5 Billion plus++ in= 2002) over the next several years.  DCPI's initial target market of more than 4,000 = large scale commercial printing companies of the total of 46,000 establishments is exp= ected to drive revenue growth to the tens of millions within its first few years= , further providing an ongoing revenue stream from the sales of printing consumable products for years to come.

 SPECIAL INVESTMENT ALERT

Digital Color Print, Inc. (OTC Bulletin Board: DCPI)
 Current Price: $1.25
Shares Outstanding: 24.6 Million
Market Capitalization: $31 Million
 Short Term Target: $3.00
12 month Target: $9.00

 A Few Reasons to Own DCPI:

Digital Color Print, Inc. ("DCPI"), through it's wholly owned su= bsidiary Logical Imaging Solutions ("LIS"), is in the business of supplying high-= speed digital printing systems and supplies to the commercial printing industry. The pri= nting systems are unique in technical concept and application. The systems are t= otally digital, designed to mount on existing offset web presses and significantl= y improve the functionality of the press, not as a replacement - but as an enhancement. The printing process is called Electron Beam Imaging ("E= BI"), and is significantly faster the convention laser printing - the only partially= competing technology.

Printing is America's third largest manufacturing industry; employing more= than 1.2 million people in almost 46,000 establishments. The printing industry,= during 2002, produced over $165 billion of printed products and purchased = $4.5 billion of hardware and $7.7 billion of consumable products.  NYSE-li= sted Dover Corporation, the largest manufacturer of offset web presses, estimates tha= t there are more than 35,000 presses installed in the U.S., with a press cos= ting from $150,000 to several million and using as much as $10,000 of consumabl= e products per month.

Offset presses print all types of documents; forms, labels, tickets, tags,= advertisements and direct mail pieces, at production rates of 500 pages-per-minute ("ppm") to thousands of ppm. However, the print= ed materials produced are each identical, as each image printed is the "offset&quo= t; inked image derived from the printing plates that are mounted on the offset press. The= great limitations of the offset process are that each image (page) remains ident= ical unless the printing plates are changed. Also the inking of the plates requ= ires the laborious tasks of mixing the inks for each plate, inking the plates a= nd then cleaning the press for the next job. If the print job requires variab= le information, such as; name, address, bar codes, dates, prices, this must b= e added in a distinctly separate print operation. Typically this task is per= formed by expensive data processing laser printers, manufactured by either Xerox,= IBM or Oce' (Formerly, Siemens Printing Systems). The laser printers print onl= y in black.

LIS printing systems are designed to mount directly on most offset web pre= sses and allow for the printing of any type of data or graphics, without limita= tion, and in line with the offset presses traditional production of a colorful e= nd product. As a simple example: In the production of an event ticket such as= a "Superbowl" ticket, all fixed or non-variable information, such as the "colorful = photo-quality" front cover and the stadium rules and disclaimers on t= he reverse side of the ticket are produced by plates on an offset press; identical information on each ticket. A second printing process is then required to = add the variable information, which includes the section, seat and row numbers= , price and date of the event. This function can be accomplished, in line, b= y an LIS provided system.

LIS printing systems are entirely digital and are dry "Toner" ba= sed, which precludes the laborious press set-up and clean-up tasks, ink mixing and st= orage and the production of printing plates. The pressman simply runs the paper = directly through LIS's printer and it becomes an integral part of the pres= s and the starting and stopping of the press and the placement of the digital ob= ject on the page are all under the control of LIS proprietary software.

NYSE-listed Dover Corporation, the largest manufacturer of offset web pres= ses, estimates that there are more than 35,000 presses installed in the U.S., w= ith a press costing from $150,000 to several million and using as much as $10,00= 0 of consumable products per month.  DCPI's DIGITALCOLORPRESS was designed= to be installed on the majority of these presses, extending their life and utili= ty by providing the printing of computer generated variable data in-line with th= e offset printing function. Further, the system eliminates the need for prep= aring and storing printing plates, and inks and the expensive tasks of setting u= p a press for a print run, followed by tearing down after each job, cleaning t= he press and setting up for the next print job. DCPI estimates that the major= ity of printers will upgrade to color during the first two years of the DIGITALCOLORPRESS availability and thousands more  commercial printer= s will purchase systems through DCPI's direct sales force and distribution channe= l during the next two years.

DCPI's first growth step is to increase consumable inventory to support ex= isting LIS systems, each installation generates about $6,000 per month in consuma= ble purchases. Secondly, to make LIS's unique color press available from inven= tory and expand the current number of installed sites. Thirdly, make the produc= t offering available to the commercial printing industry. Large tasks, but currently without any perceived competition or technological limitation.
This stock will see major upward movement in the next several weeks. Ri= ght now, DCPI is one of the Street's best kept secrets, but it will not remain= that way for long. This is a unique opportunity to get in while trading levels = are still low. As the Company goes forward with its business plan and signs ma= jor new contracts, this stock will move quickly. This is your last chance to i= nvest before DCPI begins major price appreciation. This stock could reach $3.50 = in the next five trading days!



 The writers, PR firm, mailers involved in the creation, and distribution o= f the information above are not a registered broker/dealer and may not sell, off= er to sell or offer to buy any security. This profile is not a solicitation or recommendation to buy, sell securities. An offer to buy or sell can be mad= e only with accompanying disclosure documents from the company offering or sellin= g securities and only in the states and provinces for which they are approve= d. The material in this release is intended to be strictly informational and base= d on assumptions rather than fact. The companies that are discussed in this rel= ease have not approved the statements made in this release nor approved the tim= ing of this release. All statements and expressions are the sole opinion of the creators and are subject to change without notice. Information in this rel= ease is derived from a variety of sources including that company's publicly disseminated information, third parties and the writers research and optim= istic speculation. The accuracy or completeness of the information is not warran= ted and is only as reliable as the sources from which it was obtained. All inv= olved in the creation and distribution of this profile/release disclaims any and= all liability as to the completeness or accuracy of the information contained = and any omissions of material fact in this release. The release may contain technical and factual inaccuracies or typographical errors. It is strongly= recommended that any purchase or sale decision be discussed with a financi= al adviser, or a broker-dealer, or a member of any financial regulatory bodie= s. Investment in the securities of the companys discussed in this release is = highly speculative and carries a high degree of risk. All persons involved in the= creation and distribution of the information in this letter is not liable = for any investment decisions by its readers or subscribers. Investors are caut= ioned that they may lose all or a portion of their investment if they make a pur= chase in this security mentioned. Any mention of past profiles and returns are n= ot our stock picks.

This profile is not without bias, and is a paid release. Writers and maile= rs have been compensated for the dissemination of company information on beha= lf of one or more of the companies mentioned in this release. Parties involved i= n the creation and distribution of this profile have been compensated 40,000 dol= lars by a third party (third party), who is nonaffiliated, for services provide= d including dissemination of company information in this release. PR and oth= er individuals and other creators and mailers of this letter will sell all of= its original shares during the distribution of this profile. Parties involved = may immediately sell some or any shares in a profiled company held by profile = creators and may have previously sold shares in a profiled company held by= PR Individuals involved. Our Optin mailing services for a company may cause t= he company's stock price to increase, in which event involved parties would m= ake a profit when it sells its stock in the company. In addition, our selling of= a company's stock may have a negative effect on the market price of the stoc= k. The past profiles are only the winners not all of our recommendations.

 

 ----84481154772125994311-- From eap-admin@frascone.com Thu Jun 10 07:20:22 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19532 for ; Thu, 10 Jun 2004 07:20:21 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 35BA920F64; Thu, 10 Jun 2004 07:07:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CD9A120CDB; Thu, 10 Jun 2004 07:07:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BDA302029F for ; Thu, 10 Jun 2004 07:06:04 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id DEEB41FF8C for ; Thu, 10 Jun 2004 07:06:02 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 9D73A8986F; Thu, 10 Jun 2004 14:19:15 +0300 (EEST) Message-ID: <40C842BC.2010007@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Florent Bersani Cc: Henrik Levkowetz , Bernard Aboba , eap@frascone.com Subject: Re: [eap] Issue 245: EAP Restart Issue References: <40C34D08.6000201@piuha.net> <20040607002602.38bd8868@chardonnay> <40C59627.2080907@rd.francetelecom.fr> In-Reply-To: <40C59627.2080907@rd.francetelecom.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 10 Jun 2004 14:15:08 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I think you are right in worrying about undamped link down indications. However, I think the current text is clear enough. What is referred to as "lower layer failure indication" is not to be taken as the "IEEE 802.11 unreliable indication of failure". The text that you quoted already says that damping is advisable; I read that that as meaning that in the rest of the document, when it says "lower layer indiciation", its already damped. (But I confess that my interpretation may be biased by the desire to get this RFC out.) --Jari Florent Bersani wrote: > Well, > > I've got a fuzzy feeling about this issue, especially when I take a look > at rfc3748.b.txt in section 7.12: > > "In IEEE 802.11, a "link down" indication is an unreliable indication of > link failure, since wireless signal strength can come and go and may be > influenced by radio frequency interference generated by an attacker. To > avoid unnecessary resets, it is advisable to damp these indications, > rather than passing them directly to the EAP. Since EAP supports > retransmission, it is robust against transient connectivity losses. " > > Perhaps it's my unskilled understanding of the problem, but I find > "indication of link failure" and "lower layer failure indication" quite > confusing :-( > * If they refer to the same thing, then I find the proposed changed to > resolve issue 245 contradictory to the RFC 3748 text quoted here above > * If not, I'd be more than happy to get some clarification :-) > > Any suggestion? > > Florent > > P.S: > > My two cents here is that there might be a confusion arising from "lower > layer". Indeed, I guess when EAP is used for wireless LANs, lower layer > could apply to two layers: the IEEE 802.11 layer and the IEEE 802.1X/11i > layer. Stricto sensu, I think that in this case, lower layer should only > refer to 802.1X. If this is the case, then the problem I am trying to > consider reduces to know when 802.1X considers that it should restart > due to its lower layer (i.e. 802.11) link failure. Depending on this > decision, the RFC 3748 text quoted here above might become useless (i.e. > since 802.1X could be damping the link failure indications, there would > be no need to mandate that EAP do so - but I believe without any > justification that this is not the case for 802.1X). I leave the debate > on 802.1X/EAP to the group of well versed people in that matter (which I > unfortunately do not -yet? - belong to :-() > > However, the problem with this P.S is that it is too 802.1X centric (as > much of EAP probably but this is another debate). There could be some > cases in which EAP is run directly over a link layer and has no > intermediate layer (like 802.1X) to do the possible damping. If this is > the case, we really want to make sure that the "damping" mechanism used > by EAP is really media independent and works as well with 802.1X as > without. If 802.1X does no damping (which is probably the case), then > this problem is easy. If it does, well? > > Not sure I have been very clear here :-( Hope however this helps. > > > Henrik Levkowetz wrote: > >> I have included this change in the Auth. 48 corrected rfc3748 text - see >> 'rfc3748.b.txt' on http://ietf.levkowetz.com/drafts/eap/rfc2248bis/ >> >> Henrik >> >> Sunday 6 June 2004, Jari Arkko wrote: >> >> >>> I think the suggested change is OK. >>> >>> --Jari >>> >>> Bernard Aboba wrote: >>> >>> >>>> In going over the discussion on Issue 241, John Vollbrecht made a >>>> suggestion for a change to RFC 3748 that I think corrects an >>>> oversight. As >>>> the document is now Author 48 hours, it is still possible to correct >>>> the >>>> problem if the WG approves. >>>> >>>> -------------------------------------------------------------------------- >>>> >>>> Issue 245: EAP Restart Issue >>>> Submitter name: John Vollbrecht >>>> Submitter email address: jrv@umich.edu >>>> Date first submitted: 5/7/2004 >>>> Reference: http://mail.frascone.com/pipermail/eap/2004-May/002460.html >>>> Document: RFC2284bis-09 >>>> Comment type: T >>>> Priority: S >>>> Section: 4.1 >>>> Rationale/Explanation of issue: >>>> >>>> Section 4.1 of RFC 3748 states: >>>> >>>> "Additional Request packets MUST be sent until a valid Response >>>> packet is >>>> received, or an optional retry counter expires." >>>> >>>> Where the lower layer terminates the initial session and causes a >>>> restart, >>>> if EAP knows that the lower layer is terminated then I am not sure >>>> why it >>>> would continue to resend. >>>> >>>> Perhaps we should change this to: >>>> >>>> "Additional Request packets MUST be sent until a valid Response >>>> packet is >>>> received, an optional retry counter expires, or a lower layer failure >>>> indication is received." >>>> >>> >>> _______________________________________________ >>> 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 Thu Jun 10 08:44:24 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29476 for ; Thu, 10 Jun 2004 08:44:22 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B56BA20322; Thu, 10 Jun 2004 08:31:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EA52D206D6; Thu, 10 Jun 2004 08:31:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AA36B20894 for ; Thu, 10 Jun 2004 08:30:28 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by mail.frascone.com (Postfix) with ESMTP id 6E05220322 for ; Thu, 10 Jun 2004 08:30:26 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 10 Jun 2004 14:43:37 +0200 Received: from rd.francetelecom.fr ([10.193.167.110]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Thu, 10 Jun 2004 14:43:36 +0200 Message-ID: <40C8583D.8040401@rd.francetelecom.fr> From: Florent Bersani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jun 2004 12:43:36.0894 (UTC) FILETIME=[8C72F5E0:01C44EE8] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Miscellaneous (unaddressable?) comments on RFC 3748 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, 10 Jun 2004 14:46:53 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi all, Below are some comments that came to my mind while reading the latest version of EAPbis I am aware of (namely RFC 3748b). I know that these comments,much like the ones I made on the EAP state machines very recently, may: * Come much too late (since IIRC RFC 3748 is now in AUTH48 so it shouldn't be the time IINM to propose any "real" changes to this document) * Be completely naive or off the rocket * Echo some comments that have already been made (although I tried my best to reread - and understand ;-) - the EAP issues tracked by Bernard) I just felt like making them: * Because the probability that they be of some help somehow is - I hope - non-zero * Because the probability that someone kindly replies to educate me, is - I hope - non-zero * For the record So here they go: Comment #1 - editorial/technical Section 1.2 At the entry "successful authentication" we can read: "Successful Authentication In the context of this document, "successful authentication" is an exchange of EAP messages, as a result of which the authenticator decides to allow access by the peer, and the peer decides to use this access. The authenticator's decision typically involves both authentication and authorization aspects; the peer may successfully authenticate to the authenticator, but access may be denied by the authenticator due to policy reasons." and at the end of section 1.2 : "Result indications A method provides result indications if after the method's last message is sent and received: 1) The peer is aware of whether it has authenticated the server, as well as whether the server has authenticated it. 2) The server is aware of whether it has authenticated the peer, as well as whether the peer has authenticated it. In the case where successful authentication is sufficient to authorize access, then the peer and authenticator will also know if the other party is willing to provide or accept access. This may not always be the case. An authenticated peer may be denied access due to lack of authorization (e.g., session limit) or other reasons. Since the EAP exchange is run between the peer and the server, other nodes (such as AAA proxies) may also affect the authorization decision. This is discussed in more detail in Section 7.16 <#section-7.16>. " The editorial part is that IMHO some wording in the latter text ("In the case where successful authentication is sufficient to authorize access") seem to contradict some of the former one (""successful authentication is an exchange of EAP messages, as a result of which the authenticator decides to allow access by the peer, and the peer decides to use this access. The authenticator's decision typically involves both authentication and authorization aspects"). Indeed the former text appears also to be self-contradictory ("the peer may successfully authenticate to the authenticator, but access may be denied by the authenticator due to policy reasons."). Perhaps, this comes from my poor mastery of the beautiful English language, perhaps it does not. I guess it could be worth fixing this wording (provided I am not the only one who finds it slippery ;-)) The technical part is another shot at some old stuff on EAP that has been noticed and discussed for instance in issues #2, 10, 26, 62, 80, 121, 212, 217, 222 First, partly mixing authentication and authorization is bad IMHO (by partly I typically mean what EAP is doing, i.e. a protected result within EAP of successful authentication may mean that the peer and the server have also performed authorization but also may not or this authorization may be modified by some other device -e.g. a proxy AAA server). But I think it is way too late to clean up things (and some people might also disagree with my POV) Second, I find the sentence "after the method's last message is sent and received" quite hypocrite. Since we are working with lower layers that may not guarantee delivery, we have to implement our own retransmission mechanism. To start with, let me allude to the well-known coordinated attack problem (see e.g. "Knowledge and common knowledge in a distributed environment" by Joseph Y. Halpern and Yoram Moses available at http://www.cs.cornell.edu/home/halpern/papers/common_knowledge.pdf) that may clarify what may be understood and achievable under the wording "result indication" and "synchronization of state". Let us now imagine for a second that an EAP dialog did not use EAP Success/Failure but only EAP requests/response pairs. In that case, there is still a possibility that the peer and a server fall out of sync, e.g. the server doesn't receive the peer's (last) answer and the peer doesn't receive any of the retransmitted requests. In this scenario, after a while, the peer will assume that its last message has been received and transition to success while the server will transition to failure. I am afraid there's not much we can do about his (i.e. since the ultimate common knowledge goal is unattainable, we have to place a threshold on how much we are willing to risk and to spend to mitigate this risk). A small point worth noting here, is the nature of EAP clients: do they continue to listen for a while or do they kill themselves immediately after their transition to success. The former case would be IINM similar to what IKE clients do and has many advantages IMHO while the latter would be problematic: how long has a peer has to wait before it transitions to success? because if it doesn't wait, it will probably miss any retransmission request and if it waits too long, this burdens the authentication with a fix delay (which some situations may really want to avoid). Let us now introduce the EAP Success/Failure and consider the following scenario: the peer receives a (cryptographically protected) request from the server saying that the server has successfully authenticated it (whatever that means ;-)). The peer decides to send a (cryptographically protected) response to the server saying that it (i.e. the peer) has also successfully authenticated the server. Thus, we can consider that both the peer and the server have protected result indications. But what happens then if an attacker intercepts (e.g. jams) the peer's response and sends an EAP-Success to the peer before the server has a chance to retransmit its request. Well, the peer will transition to success and if the EAP peer "kills itself" immediately after its transition to success, it won't get the server's retransmissions. Thus, the server will go to failure while the peer will believe they are both in the success state despite the protected result indications:-( Again here, the fixes I am aware of do not completely solve this problem, imply a trade off between efficiency and resilience to this problem or probably require modifications to EAP peer's implementations (if they "kill themselves after success" which is what most do IMHO though I have absolutely no justification for this opinion - I intend to test this in the near future). My main point in this discussion is that I think that EAP could (should?) have had: 1) A (more thorough) discussion of these Dos-like issues (e.g. in its Security considerations section). Indeed, my feeling as I have already expressed about DoS is that it is important to distinguish between attacks that are a "real" DoS and attacks that aren't (e.g.if an attacker jams the 802.11 frequency with a microwave oven, there's not much to do to prevent it - the best one can hope is to detect this and possibly catch the attacker). Discussion on this in RFC 3748 would have shown what had been considered (and mitigated or not) by the group 2) A clearer goal that it advertises against its applications/higher layers. For instance, do the higher layers/applications need to do key confirmation after a successful authentication - and are they able to do any better than EAP on that regard? Last, let me remind the courageous reader that has managed to read all this that I am quite a newbie to protocol design, cryptography, DoS,... so the discussion here above may be completely stupid, have ignored EAP discussions/new articles/techniques on the matter... Comment #2 - editorial/technical Section 2.2 says: "Within EAP, the Type field functions much like a port number in UDP or TCP" Although I find the analogy somehow enlightening in some way, I am concerned by a potential misunderstanding it could lead to (though the sentence that follows my quotation does provide some clarification): is an EAP peer capable of having multiple EAP conversations (possibly of the same method type) in parallel? Here's my tentative answer: if the EAP peer is talking to different EAP servers or different authenticators that it can distinguish (for instance if an EAP peer talks over 802.11 to two different APs, it could demultiplex its conversations according to the AP MAC address) then there's no problem. However, if the peer tries to talk in parallel to the same authentication server/authenticator using the same method type, I bet that we will get into trouble due to the very small EAP identifier space... Does my tentative answer makes sense? [Here again a comparison with IKEv2 seems enlightening to me since IKEv2 would be able IINM to handle the latter scenario] Perhaps it would have been worth mentioning this triviality? Comment #3 - technical Here again, this is about DoS resilience. While rereading EAP and the EAP state machines, I did not find mention of the possibility for a peer/server at some point to cache multiple requests/responses to improve its resilience against someone sending bogus packets (this concerns EAP as well as EAP authentication methods). The is loosely similar for instance to the point made in section "2.4 State Synchronization and Connection Timeouts" of draft-ietf-ipsec-ikev2-14.txt ("There is a Denial of Service attack on the Initiator of an IKE_SA that can be avoided if the Initiator takes the proper care. Since the first two messages of an SA setup are not cryptographically protected, an attacker could respond to the Initiator's message before the genuine Responder and poison the connection setup attempt. To prevent this, the Initiator MAY be willing to accept multiple responses to its first message, treat each as potentially legitimate, respond to it, and then discard all the invalid half open connections when she receives a valid cryptographically protected response to any one of her requests. Once a cryptographically valid response is received, all subsequent responses should be ignored whether or not they are cryptographically valid"). I reckon this kind of behavior is not forbidden by the current text in EAP (and is only very partially relevant since EAP is probably not capable of handling multiple simultaneous conversations with the same peer see comment #2 above). It's just that I was wondering whether this had been thought of in case of EAP. In case it had, then it would have been a good idea to capture these thoughts... Comment #4 - technical Section 7.5 "Packet Modification Attacks" "Since EAP messages of Types Identity, Notification, and Nak do not include their own MIC, it may be desirable for the EAP method MIC to cover information contained within these messages, as well as the header of each EAP message." I was wondering how an EAP method could access to such messages (which is a preliminary to MIC them ;-)). Although the situation seems OK for identity as section 2.2 says "Since EAP authentication methods may wish to access the Identity, implementations SHOULD make the Identity Request and Response accessible to authentication methods (Types 4 or greater), in addition to the Identity method.", it does not seem to be very straightforward for notifications & NAK as section 2.2 says "It cannot be assumed that the contents of the Notification Request or Response are available to another method" & "It cannot be assumed that the contents of the Nak Response(s) are available to another method"... Any idea? Comment #5 - technical This is about a (probably) small lack of discussion IMHO in the security considerations section of RFC 3748 on the implications of allowing an EAP method to process notifications (and I believe there are at least from a DoS point of view) as section 5.2 only says "The peer MUST respond to a Notification Request with a Notification Response unless the EAP authentication method specification prohibits the use of Notification messages". My point is just about saying why a method would possibly forbid the processing of notifications (and I believe that this should be the standard behavior of EAP methods) - RFC 3748 IIRC only says that a notification packet is vulnerable to a packet modification attack. Comment #6 - technical Last, this is also about a (probably) small lack of discussion IMHO in the security considerations section of RFC 3748 on the implications of fragmentation. Indeed, IIRC RFC 3748 only says that: - in the abstract and section 1 "Fragmentation is not supported within EAP itself; however, individual EAP methods may support this." - in section 1.3 "Since EAP does not support fragmentation and reassembly, EAP authentication methods generating payloads larger than the minimum EAP MTU need to provide fragmentation support." - in section 3.1 "EAP methods can assume a minimum EAP MTU of 1020 octets in the absence of other information. EAP methods SHOULD include support for fragmentation and reassembly if their payloads can be larger than this minimum EAP MTU (...) EAP is a lock-step protocol, which implies a certain inefficiency when handling fragmentation and reassembly" - and fragmentation is again defined in section 7.2.1 without any new information The DoS implications of fragmentation are I believe well-known and EAP is IHMO particlarly vulnerable to attacks on the fragmentation (whenever the fragments are not cryptographically protected). Classic reference on the matter seems to be Kent's "fragmentation considered harmful" and Kaufman's et al. "DoS protection for UDP based protocol". I also believe that this point has been (is still being?) looked at by the IPsec WG. There's a note in EAP-TLS (RFC 2716 - section 3.3 "However, note that in order to protect against reassembly lockup and denial of service attacks, it may be desirable for an implementation to set a maximum size for one such group of TLS messages. Since a typical certificate chain is rarely longer than a few thousand octets, and no other field is likely to be anwhere near as long, a reasonable choice of maximum acceptable message length might be 64 KB." However I believe that this note only very partially address the issue I am raising here; for instance if an attacker inject a bogus fragment in a lengthy EAP-TLS Certificate exchange (e.g. 60 KB) then the current behavior is IMHO a failure (since the behavior I expect is not the one I evoke in comment #3 - see above). I guess I would have appreciated a discussion on that topic/hint to EAP method developers, since the issue is quite general, isn't it? (issue #74 is vaguely related IMHO to this last comment) Florent, hope this helps _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From lsgak@hotmail.com Thu Jun 10 09:40:33 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04043 for ; Thu, 10 Jun 2004 09:40:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYPnG-0006Rb-36 for eap-archive@ietf.org; Thu, 10 Jun 2004 09:40:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYPd7-00046s-00 for eap-archive@ietf.org; Thu, 10 Jun 2004 09:30:07 -0400 Received: from [68.114.40.189] (helo=132.151.6.1) by ietf-mx with smtp (Exim 4.12) id 1BYPXX-0002QY-00 for eap-archive@ietf.org; Thu, 10 Jun 2004 09:24:20 -0400 Received: from 190.216.240.73 by 68.114.40.189; Thu, 10 Jun 2004 07:21:54 -0700 Message-ID: From: "Dalton Burroughs" Reply-To: "Dalton Burroughs" To: eap-archive@ietf.org Subject: Get Vicodin Prescription Directly Date: Thu, 10 Jun 2004 17:20:54 +0300 X-Mailer: MIME-tools 5.503 (Entity 5.501) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--047451305156164545" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.5 required=5.0 tests=HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, MISSING_MIMEOLE,MISSING_OUTLOOK_NAME,RCVD_NUMERIC_HELO autolearn=no version=2.60 ----047451305156164545 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable


Zfreest backward adrenaline azalea anthracnose balance astrophysics cr= iteria bushel addressograph perspicacious benefice gordian discuss claim p= apa approximate fro appendix=20!Pduffy patent land lysenko pearlstone dual= ism wince bastard beneficent pork q sure amass mesa seriate propaganda sen= sor foil paradise sumeria=20.Cstochastic tabloid wilful creedal cubbyhole = effect buena structural abundant calvin finial bijective bristol surcease = taoist springy pillage illiterate embrace seller b collard inductance bump= tious croon detergent frog portland=20;Iarchipelago conscious lifeguard sl= urry coffin infidel copernicus claire altar calendar glassware=20.Pstation= arity narcissist beatrice northerly bride ubiquitous beatify agricola burn= side franc spinnaker climate flowchart inappreciable frill tamp brassy anx= ious potent trustee conceal spiro diadem direct headstone kirchner culture= mobility=20;Bdrill bushnell bewail make alexandre close scintillate alumi= na drag honduras tip abernathy dominic earthshaking ambrosial admit forego= ing peremptory darwinian cytology chargeable coolheaded atreus theodore al= lan division bird coinage adamson=20,Vdecca interpolant vote patrolmen nel= lie effie arrack knotty doge dyke immunoelectrophoresis quasiorder altitud= e cdc extremis shrank admonition sabine cypress aircraft christian indescr= ibable=20'Xopulent mow evaluable threefold dharma algorithmic jacobite bak= lava enoch=20,Whonorary farce paul ferric perceptive hepburn airspace hard= in chrysolite bladdernut embryology checkerberry burglarproof=20,Warcing c= oleridge contemporaneous fill myeline sine bail ks boutique side cave more= land conn hidden lockian seam suburb zimmerman barre anabel dickson warrio= r cavalcade wainwright=20?Ydelphic counterman conjoint politician daedalus= bashful circlet mayapple nibelung gottfried medford pattern hangman silt = ashy electoral equable orthant runge abode gamesman injury fossil=20!Ndepa= rture drastic alga barclay boot insurrect phylogeny pinpoint defensive ste= llar baptism colonnade bruckner opiate bayou harness shutout=20.Bample ero= sible attica beatitude eurydice byers wanton wax olin dystrophy christina = remark rave ignition delphine ash bantu degeneracy=20.Easilomar generosity= huntsville crumple pervert metalloid toshiba ellwood aliquot selma superf= luity altitude aloha byline retrospect emphatic palfrey alluvial sportsman= captaincy puddingstone substituent=20.Banita maraud chesapeake portsmouth= citron assignee grew imbue ackerman spark octavia flimsy widowhood cicada= jilt salesman distortion dolomitic breast bigotry catv=20;Cbaptiste winsl= ow harmonic gloucester cornelia shrink can derision agenda dummy desperate= lima fond brute wipe condemnatory campfire burtt acknowledge sedition dwe= ll mardi pleasure m perfectible orville ludicrous evict=20;Gsorghum issue = prestigious arachne suspensor defrost avert chock codpiece cloddish critic= =20,

----047451305156164545-- From eap-admin@frascone.com Thu Jun 10 16:40:24 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29679 for ; Thu, 10 Jun 2004 16:40:24 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5C3FC20B32; Thu, 10 Jun 2004 16:27:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2533B202CF; Thu, 10 Jun 2004 16:27:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 26C16202CF for ; Thu, 10 Jun 2004 16:26:15 -0400 (EDT) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by mail.frascone.com (Postfix) with ESMTP id 628B71FF5C for ; Thu, 10 Jun 2004 16:26:13 -0400 (EDT) Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.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 i5AKcxXv008143; Thu, 10 Jun 2004 20:38:59 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i5AKZ132031685; Thu, 10 Jun 2004 20:35:14 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004061013391721477 ; Thu, 10 Jun 2004 13:39:17 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 10 Jun 2004 13:39:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: Updated version of EAP-based network discovery draft Thread-Index: AcRPKv9cLaOGyTZpQqeO4aI+HdAbRQ== From: "Adrangi, Farid" To: , , X-OriginalArrivalTime: 10 Jun 2004 20:39:17.0297 (UTC) FILETIME=[FFDADA10:01C44F2A] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Updated version of EAP-based network discovery 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: Thu, 10 Jun 2004 13:39:16 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi Bernard & Jari Thanks again for your review and comments. I have made an intermediary update of the draft based on your comments / feedback - the draft can be found in http://mng.ctgisp.com/IETF/EAP/Network%20Selection/draft-adrangi-eap-net work-discovery-011.txt. =20 On issues (pointed out by Bernard) with the "security considerations" section, I made some clarification changes: - Made some clarifications on the information type and what is meant by a "hint" - Removed the SSID analogy=20 - The "implementation considerations" section contains a text describing on what conditions an implementation should specify a mediating network for the AAA routing As to attack scenarios, we can look at it from both network advertisement and selection perspectives. - On network advertisement, I can think of two scenarios 1) client associates with a bogus SSID, starts EAP, and receives some bogus network information. In this case, associating with the bogus SSID is the problem - what ever happens after that obviously is going to be questionable.=20 2) Associating with a valid/legitimate SSID. In this case, the access network may advertise only a subset of the mediating networks that it has roaming agreement with - based on its own preference. I don't think this is a security issue - is it? - On network selection, the access network may route the AAA packets differently from what specified by the user through the decorated NAI (described in 2486bis). In this case, the home network may be able to detect the problem depending the EAP method. This was mentioned in the second paragraph in the "security considerations" section.=20 Having said that, we can discuss further if we need more text under "security considerations". Please let me know if you have any questions. Thanks again. BR, Farid _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jun 11 03:21:21 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03808 for ; Fri, 11 Jun 2004 03:21:21 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EDB37206EE; Fri, 11 Jun 2004 03:08:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8ED7C206FA; Fri, 11 Jun 2004 03:08:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E67CB20B77 for ; Fri, 11 Jun 2004 03:07:28 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by mail.frascone.com (Postfix) with ESMTP id E26F420B73 for ; Fri, 11 Jun 2004 03:07:26 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 11 Jun 2004 09:18:32 +0200 Received: from rd.francetelecom.fr ([10.193.106.30]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Fri, 11 Jun 2004 09:18:30 +0200 Message-ID: <40C95D8C.5040008@rd.francetelecom.fr> From: Florent Bersani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jun 2004 07:18:30.0966 (UTC) FILETIME=[4C6C4D60:01C44F84] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Other (minor) editorial issues with the EAP state machine 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, 11 Jun 2004 09:21:48 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit IINM, I did not find in section 4.4 of draft-ietf-eap-statemachine-strawman-04.pdf the definition of m.isKeyavailable() that is however used in Figure 3 Moreover, there seems to be a discrepancy between what is indicated in Figure 3 (m.check) and defined in section 4 (m.integrityCheck()) _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jun 11 03:35:22 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04234 for ; Fri, 11 Jun 2004 03:35:21 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 17752206EE; Fri, 11 Jun 2004 03:22:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AA820206FA; Fri, 11 Jun 2004 03:22:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D3DF5206FA for ; Fri, 11 Jun 2004 03:21:02 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by mail.frascone.com (Postfix) with ESMTP id D98EE206EE for ; Fri, 11 Jun 2004 03:21:00 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 11 Jun 2004 09:33:09 +0200 Received: from rd.francetelecom.fr ([10.193.106.30]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Fri, 11 Jun 2004 09:33:09 +0200 Message-ID: <40C960FA.3020606@rd.francetelecom.fr> From: Florent Bersani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jun 2004 07:33:09.0332 (UTC) FILETIME=[57F85140:01C44F86] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] A (last?) remark on the EAP state machine 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, 11 Jun 2004 09:36:26 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi, Many apologies for the fragmented and late feedback on the EAP state machine. This one is surely a matter of taste - and is related to comment #7 I made in http://mail.frascone.com/pipermail/public/eap/2004-June/002523.html I don't understand why the EAP peer state machine uses two different procedures to "process" the EAP packet: m.process and m.BuildResp? Wouldn't it be simpler to use only one procedure and write something like: (methodState,decision,allowNotifications,eapRespData)=m.process(eapReqData) BR, Florent _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From clearwaterirmyv@socal.rr.com Sat Jun 12 14:13:56 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13727 for ; Sat, 12 Jun 2004 14:13:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BZD0v-0005jd-9p for eap-archive@ietf.org; Sat, 12 Jun 2004 14:13:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BZCys-0004f3-00 for eap-archive@ietf.org; Sat, 12 Jun 2004 14:11:50 -0400 Received: from 200-206-153-140.dsl.telesp.net.br ([200.206.153.140]) by ietf-mx with smtp (Exim 4.12) id 1BZCy0-00048i-00; Sat, 12 Jun 2004 14:10:57 -0400 Received: from 108.70.46.2 by 200.206.153.140; Sat, 12 Jun 2004 17:09:17 -0100 Message-ID: From: "Louie Mead" Reply-To: "Louie Mead" To: dhksggnjkgshwvm@ietf.org Cc: ietf-info@ietf.org, agma-admin@ietf.org, ipv6-admin@ietf.org, l3vpn@ietf.org, olicy@ietf.org, eap-archive@ietf.org, dhcwg-admin@ietf.org, mailman-admin@ietf.org, raven@ietf.org Subject: RE: Mo[r]tgage Application Date: Sat, 12 Jun 2004 19:08:17 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--003849973493581" X-Webmail-Time: Sat, 12 Jun 2004 15:08:17 -0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.4 required=5.0 tests=HTML_20_30,HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----003849973493581 Content-Type: text/html; Content-Transfer-Encoding: 7Bit Hello,

Thank you for your m.ortgage application, which we received yesterday.
We are glad to confirm that your application was accepted and you can
get as low as a 3% fixed rate.

Could we ask you to please fill out final details we need to complete you here:
http://sanhedrin.lettersubmit.com/mn/mal

We look forward to hearing from you.

Regards,
Louie Mead
Account Manager

-----------------------------------------

not interested ----003849973493581-- From bureaucracyb@epomail.com Sun Jun 13 20:17:03 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12591 for ; Sun, 13 Jun 2004 20:17:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BZf9r-00033C-IV for eap-archive@ietf.org; Sun, 13 Jun 2004 20:17:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BZf8C-0002e6-00 for eap-archive@ietf.org; Sun, 13 Jun 2004 20:15:22 -0400 Received: from [61.85.44.214] (helo=132.151.6.1) by ietf-mx with smtp (Exim 4.12) id 1BZf7E-0002Em-00; Sun, 13 Jun 2004 20:14:21 -0400 X-Message-Info: YXABnRV8xVIxHh23Xq1+UTVFq9tNIEG Received: from nrcbwgov86.cox.net ([168.37.64.0]) by hp55-r55.hotmail.com with Microsoft SMTPSVC(5.0.2195.6824); Sun, 13 Jun 2004 23:12:16 -0200 Received: from Martinaj15c7oot0x ([122.232.204.14]) by puczzycm00.cox.net (InterMail vM.5.01.06.05 201-253-122-130-105-6616609) with SMTP id <48703842213663.VFUK7376.zhxmdqgq12.cox.net@slido61j6pea6w> for ; Mon, 14 Jun 2004 05:06:16 +0400 Message-ID: <967949u2n144$80184997$ti8e5630@Martinao04p0uft9x> From: "Elisabeth Wright" To: Subject: Newsletter #6165 Date: Mon, 14 Jun 2004 02:14:16 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--797940070385823973" X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=5.9 required=5.0 tests=FRONTPAGE,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_GREEN,HTML_FONTCOLOR_RED, HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE,LINES_OF_YELLING, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,RCVD_NUMERIC_HELO,STOCK_PICK, SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 1.2 STOCK_PICK BODY: Offers a picked stock * 0.8 HTML_30_40 BODY: Message is 30% to 40% HTML * 0.1 HTML_FONTCOLOR_GREEN BODY: HTML font color is green * 0.1 HTML_FONTCOLOR_BLUE BODY: HTML font color is blue * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red * 1.6 FRONTPAGE BODY: Frontpage used to create the message * 0.2 SUBJ_HAS_UNIQ_ID Subject contains a unique ID * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts ----797940070385823973 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable New Page 4

****DCPI****DCPI****DCPI****DCPI****DCPI****DCPI****DCPI***DCPI****= DCPI***


 New York Times Financial Digest
 Investor Alert on New Hot Issue
 


 Take a look at our some of our most recent Strong Buy recommendations...

November GDVI at 0.04 High 0.29...625% Gain!
December HTSC at 0.70 High 2.95...329% Gain!
March/April DMTY at 0.30 High 0.90...300%Gain!
April IPYS at 0.38 High 1.10...189%Gain in two days !
 May/June          EESI at 0.0= 3         High  0.95..= 317% Gain in three days !
June            =   DCPI at  1.25 Don't Miss Out!  300%  Gains Expected.....

(OTC-BB: DCPI) DCPI has developed a revolutionary digital printing technology recognized = to be the solution to variable graphical/color printing processes by industry le= aders such as IBM (NYSE: IBM); XEROX (NYSE: XRX) and Siemens(NYSE: SI) whose = products only print in black via laser products.  DCPI's commerci= al printing application hardware/software and printing consumable products are expecte= d to dominate the printing "enhancement" market ($5 Billion plus++ in= 2002) over the next several years.  DCPI's initial target market of more than 4,000 = large scale commercial printing companies of the total of 46,000 establishments is exp= ected to drive revenue growth to the tens of millions within its first few years= , further providing an ongoing revenue stream from the sales of printing consumable products for years to come.

 SPECIAL INVESTMENT ALERT

Digital Color Print, Inc. (OTC Bulletin Board: DCPI)
 Current Price: $1.25
Shares Outstanding: 24.6 Million
Market Capitalization: $31 Million
 Short Term Target: $3.00
12 month Target: $9.00

 A Few Reasons to Own DCPI:

Digital Color Print, Inc. ("DCPI"), through it's wholly owned su= bsidiary Logical Imaging Solutions ("LIS"), is in the business of supplying high-= speed digital printing systems and supplies to the commercial printing industry. The pri= nting systems are unique in technical concept and application. The systems are t= otally digital, designed to mount on existing offset web presses and significantl= y improve the functionality of the press, not as a replacement - but as an enhancement. The printing process is called Electron Beam Imaging ("E= BI"), and is significantly faster the convention laser printing - the only partially= competing technology.

Printing is America's third largest manufacturing industry; employing more= than 1.2 million people in almost 46,000 establishments. The printing industry,= during 2002, produced over $165 billion of printed products and purchased = $4.5 billion of hardware and $7.7 billion of consumable products.  NYSE-li= sted Dover Corporation, the largest manufacturer of offset web presses, estimates tha= t there are more than 35,000 presses installed in the U.S., with a press cos= ting from $150,000 to several million and using as much as $10,000 of consumabl= e products per month.

Offset presses print all types of documents; forms, labels, tickets, tags,= advertisements and direct mail pieces, at production rates of 500 pages-per-minute ("ppm") to thousands of ppm. However, the print= ed materials produced are each identical, as each image printed is the "offset&quo= t; inked image derived from the printing plates that are mounted on the offset press. The= great limitations of the offset process are that each image (page) remains ident= ical unless the printing plates are changed. Also the inking of the plates requ= ires the laborious tasks of mixing the inks for each plate, inking the plates a= nd then cleaning the press for the next job. If the print job requires variab= le information, such as; name, address, bar codes, dates, prices, this must b= e added in a distinctly separate print operation. Typically this task is per= formed by expensive data processing laser printers, manufactured by either Xerox,= IBM or Oce' (Formerly, Siemens Printing Systems). The laser printers print onl= y in black.

LIS printing systems are designed to mount directly on most offset web pre= sses and allow for the printing of any type of data or graphics, without limita= tion, and in line with the offset presses traditional production of a colorful e= nd product. As a simple example: In the production of an event ticket such as= a "Superbowl" ticket, all fixed or non-variable information, such as the "colorful = photo-quality" front cover and the stadium rules and disclaimers on t= he reverse side of the ticket are produced by plates on an offset press; identical information on each ticket. A second printing process is then required to = add the variable information, which includes the section, seat and row numbers= , price and date of the event. This function can be accomplished, in line, b= y an LIS provided system.

LIS printing systems are entirely digital and are dry "Toner" ba= sed, which precludes the laborious press set-up and clean-up tasks, ink mixing and st= orage and the production of printing plates. The pressman simply runs the paper = directly through LIS's printer and it becomes an integral part of the pres= s and the starting and stopping of the press and the placement of the digital ob= ject on the page are all under the control of LIS proprietary software.

NYSE-listed Dover Corporation, the largest manufacturer of offset web pres= ses, estimates that there are more than 35,000 presses installed in the U.S., w= ith a press costing from $150,000 to several million and using as much as $10,00= 0 of consumable products per month.  DCPI's DIGITALCOLORPRESS was designed= to be installed on the majority of these presses, extending their life and utili= ty by providing the printing of computer generated variable data in-line with th= e offset printing function. Further, the system eliminates the need for prep= aring and storing printing plates, and inks and the expensive tasks of setting u= p a press for a print run, followed by tearing down after each job, cleaning t= he press and setting up for the next print job. DCPI estimates that the major= ity of printers will upgrade to color during the first two years of the DIGITALCOLORPRESS availability and thousands more  commercial printer= s will purchase systems through DCPI's direct sales force and distribution channe= l during the next two years.

DCPI's first growth step is to increase consumable inventory to support ex= isting LIS systems, each installation generates about $6,000 per month in consuma= ble purchases. Secondly, to make LIS's unique color press available from inven= tory and expand the current number of installed sites. Thirdly, make the produc= t offering available to the commercial printing industry. Large tasks, but currently without any perceived competition or technological limitation.
This stock will see major upward movement in the next several weeks. Ri= ght now, DCPI is one of the Street's best kept secrets, but it will not remain= that way for long. This is a unique opportunity to get in while trading levels = are still low. As the Company goes forward with its business plan and signs ma= jor new contracts, this stock will move quickly. This is your last chance to i= nvest before DCPI begins major price appreciation. This stock could reach $3.50 = in the next five trading days!



 The writers, PR firm, mailers involved in the creation, and distribution o= f the information above are not a registered broker/dealer and may not sell, off= er to sell or offer to buy any security. This profile is not a solicitation or recommendation to buy, sell securities. An offer to buy or sell can be mad= e only with accompanying disclosure documents from the company offering or sellin= g securities and only in the states and provinces for which they are approve= d. The material in this release is intended to be strictly informational and base= d on assumptions rather than fact. The companies that are discussed in this rel= ease have not approved the statements made in this release nor approved the tim= ing of this release. All statements and expressions are the sole opinion of the creators and are subject to change without notice. Information in this rel= ease is derived from a variety of sources including that company's publicly disseminated information, third parties and the writers research and optim= istic speculation. The accuracy or completeness of the information is not warran= ted and is only as reliable as the sources from which it was obtained. All inv= olved in the creation and distribution of this profile/release disclaims any and= all liability as to the completeness or accuracy of the information contained = and any omissions of material fact in this release. The release may contain technical and factual inaccuracies or typographical errors. It is strongly= recommended that any purchase or sale decision be discussed with a financi= al adviser, or a broker-dealer, or a member of any financial regulatory bodie= s. Investment in the securities of the companys discussed in this release is = highly speculative and carries a high degree of risk. All persons involved in the= creation and distribution of the information in this letter is not liable = for any investment decisions by its readers or subscribers. Investors are caut= ioned that they may lose all or a portion of their investment if they make a pur= chase in this security mentioned. Any mention of past profiles and returns are n= ot our stock picks.

This profile is not without bias, and is a paid release. Writers and maile= rs have been compensated for the dissemination of company information on beha= lf of one or more of the companies mentioned in this release. Parties involved i= n the creation and distribution of this profile have been compensated 40,000 dol= lars by a third party (third party), who is nonaffiliated, for services provide= d including dissemination of company information in this release. PR and oth= er individuals and other creators and mailers of this letter will sell all of= its original shares during the distribution of this profile. Parties involved = may immediately sell some or any shares in a profiled company held by profile = creators and may have previously sold shares in a profiled company held by= PR Individuals involved. Our Optin mailing services for a company may cause t= he company's stock price to increase, in which event involved parties would m= ake a profit when it sells its stock in the company. In addition, our selling of= a company's stock may have a negative effect on the market price of the stoc= k. The past profiles are only the winners not all of our recommendations.

 

 ----797940070385823973-- From subterraneanhttya@charter.net Sun Jun 13 20:17:31 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12785 for ; Sun, 13 Jun 2004 20:17:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BZfAJ-0003I8-Hd for eap-archive@ietf.org; Sun, 13 Jun 2004 20:17:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BZf8w-0002j1-00 for eap-archive@ietf.org; Sun, 13 Jun 2004 20:16:07 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BZf7l-0002SI-00; Sun, 13 Jun 2004 20:14:53 -0400 Received: from ilm25-56-137.ec.rr.com ([24.25.56.137]) by mx2.foretec.com with smtp (Exim 4.24) id 1BZeEX-0002SS-BN; Sun, 13 Jun 2004 19:17:49 -0400 Received: from 50.152.58.68 by 24.25.56.137; Sun, 13 Jun 2004 21:12:13 -0400 Message-ID: From: "Concepcion Clark" Reply-To: "Concepcion Clark" To: diffserv-interest-request@ietf.org Cc: 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 Subject: FW: Your Application Date: Sun, 13 Jun 2004 18:08:13 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--75221790811798254" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.6 required=5.0 tests=BIZ_TLD,HTML_20_30, HTML_MESSAGE,HTML_TAG_BALANCE_HTML,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----75221790811798254 Content-Type: text/html; Content-Transfer-Encoding: 7Bit I am sorry that it took so long to review your application but
you were finally approved with 3% fixed ra.te. But first, to
ensure the best results, we’ll need some more information.

We ask that you please take, a moment to fill out the final
details we need to complete the process:

http://www.refifast.biz/aff/affiliate.php?uid=63

Thank you and we appreciate your business!

Regards,
Concepcion Clark




----------------------
not interested
----75221790811798254-- From WPZBFLVQKQWS@it.ru Mon Jun 14 06:45:48 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20478 for ; Mon, 14 Jun 2004 06:45:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BZoyK-0001md-V3 for eap-archive@ietf.org; Mon, 14 Jun 2004 06:45:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BZoxR-0001ZE-00 for eap-archive@ietf.org; Mon, 14 Jun 2004 06:44:54 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BZoxA-0001LM-00 for eap-archive@ietf.org; Mon, 14 Jun 2004 06:44:36 -0400 Received: from c-24-3-124-218.client.comcast.net ([24.3.124.218]) by mx2.foretec.com with smtp (Exim 4.24) id 1BZo3y-0004Sr-CN for eap-archive@ietf.org; Mon, 14 Jun 2004 05:47:34 -0400 X-Message-Info: A22C8MrF1371TYIozoirYMGKGVKimvod+A32B0C Received: from rzkop1BB9.hkhw.WPZBFLVQKQWS@it.ru ([40.220.246.104]) by fpfjE5C15-jm.24.3.124.218 with Microsoft SMTPSVC(5.0.2195.6824); Mon, 14 Jun 2004 08:40:37 -0300 Received: from WPZBFLVQKQWS@it.ru (16.152.143.52) by wqqgspil128D8.nmbs.pWPZBFLVQKQWS@it.ru with QMQP; Mon, 14 Jun 2004 06:38:37 -0500 Message-Id: <6Ayyisvv$9D82pdjz@zse63.videotape.WPZBFLVQKQWS@it.ru> Date: Mon, 14 Jun 2004 05:36:37 -0600 Message-ID: <1767C2CA186F6.34568.qmail@campus.achieve.WPZBFLVQKQWS@it.ru> From: "Carey Rivas" Subject: university degrees for sale! To: eap-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--111E3C61C19C5DC3" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.6 required=5.0 tests=BIZ_TLD,HTML_20_30, HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE,LINES_OF_YELLING,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----111E3C61C19C5DC3 Content-Type: text/html; charset="iso-CBE8-4" Content-Transfer-Encoding: quoted-printable pate V 3

 

YOU DE= SERVE A COLLEGE DIPLOMA

Think you got = shortchanged in school?

Degrees available: Bachelors, MBA, Masters, Doctorate (PhD)

No classes to attend, no tests, no interviews, no nonsense!

 

 

 

 

 

Thus when, in 1766, Buffon wrote the fourteenth = volume of his great work, he was personally familiar with the young of one= kind of African man-like Ape, and with the adult of an Asiatic species=96= while the Orang-Utan and the Mandrill of Smith were known to him by report= Furthermore, the Abb=E9 Prevost had translated a good deal of Purchas' "= Pilgrims" into French, in his "Histoire g=E9n=E9rale des Voyages" (1748), = and there Buffon found a version of Andrew Battell's account of the Pongo = and the Engeco. All these data Buffon attempts to weld together into harmo= ny in this chapter entitled "Les Orang-outangs ou le Pongo et le Jocko." T= o this title the following note is appended:=96 which have been limited to= walkmans Fig. 2.=96The Orang of Tulpius, 1641. but filled with ether[21]. In what follows I want = to look at Boyle's approach to this dispute Turkle who has a background in= psychoanalysis sees the computer as a test object for post-modernity in t= he same way beasts and dreams were for Charles Darwin (1809-82) and Sigmun= d Freud (1856-1939) in modernity. For Freud's theories to be known outside= sc how are they situated in time and place But I must leave this question to be settled by ph= ilologers and travellers; and I should hardly have dwelt so long upon it e= xcept for the curious part played by this word 'Pongo'in the later history= of the man-like Apes. Turing on the other hand argued from a theoretical = point of view by developing an algorithmic method - a method that as in th= e case with Boyle involved interaction of humans and non-humans and mobili= zing a particular actant a Turing Machine can perform any operation that a= contemporary computer can perform. It might not always work as fast as yo= u would like in which quasi-objects circulate freely. It would = take a lot of effort to become part of a collective a hybrid something tha= t is normally not the case in the relation between humans and robots. I wi= ll claim that in cyberculture AIBO as an entertainment robot is accepted i= nto collectives on symmetrical terms ----111E3C61C19C5DC3-- From PXNPLMJBTUH@swbell.net Mon Jun 14 08:01:09 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23958 for ; Mon, 14 Jun 2004 08:01:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BZq9G-0005ZV-2b for eap-archive@ietf.org; Mon, 14 Jun 2004 08:01:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BZq7H-0004x6-00 for eap-archive@ietf.org; Mon, 14 Jun 2004 07:59:07 -0400 Received: from yahoobb219004078114.bbtec.net ([219.4.78.114]) by ietf-mx with smtp (Exim 4.12) id 1BZq6N-0004ea-00; Mon, 14 Jun 2004 07:58:12 -0400 Received: from 16.198.60.224 by 219.4.78.114; Mon, 14 Jun 2004 05:54:47 -0700 Message-ID: From: "Lora Roberts" Reply-To: "Lora Roberts" To: dhksggnjkgshwvm@ietf.org Cc: ietf-info@ietf.org, agma-admin@ietf.org, ipv6-admin@ietf.org, l3vpn@ietf.org, olicy@ietf.org, eap-archive@ietf.org, dhcwg-admin@ietf.org, mailman-admin@ietf.org, raven@ietf.org, sipping-admin@ietf.org, manet@ietf.org Subject: FWD: Your M[o]rtgage Application Date: Mon, 14 Jun 2004 05:55:47 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--3313410944740140" X-Webmail-Time: Mon, 14 Jun 2004 11:49:47 -0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.8 required=5.0 tests=BIZ_TLD,HTML_30_40, HTML_MESSAGE,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----3313410944740140 Content-Type: text/html; Content-Transfer-Encoding: 7Bit Hello,

Thank you for your m.ortgage application, which we received yesterday.
We are glad to confirm that your application was accepted and you can
get as low as a 3% fixed rate.

Could we ask you to please fill out final details we need to complete you here:
Quick Form

We look forward to hearing from you.

Regards,
Lora Roberts
Account Manager

-----------------------------------------

not interested ----3313410944740140-- From victor600@amnetsal.com Mon Jun 14 10:17:05 2004 Received: from amnetsal.com (amnetsal.com [200.12.232.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04577 for ; Mon, 14 Jun 2004 10:17:04 -0400 (EDT) Received: from [213.255.196.52] (account victor600@amnetsal.com) by amnetsal.com (CommuniGate Pro WebUser 4.1.8) with HTTP id 1368652; Mon, 14 Jun 2004 08:13:29 -0600 From: "victor" Subject: TRUST To: victor600@amnetsal.com X-Mailer: CommuniGate Pro WebUser Interface v.4.1.8 Date: Mon, 14 Jun 2004 08:13:29 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit DEAR SIR, I am victor Arap Moi, the son of The former president of Kenya Mr Daniel Arap Moi. I came to know you in the course of my search for a reliable And GOD fearing partner, and I decided to contact you,Because I believe you are a reputable person and I feel You can help me and my mother over this confidential matter. I count on your integrity and honesty to be able to handle this Business. My father, Mr Arap Moi, was the former president of Kenya , In East Africa, During his reign as the president , he had so many Monetary dealing with a lot of European companies in my country And out side my country, and he uses these companies as a means Of transferring funds to foreign accounts in Europe ,America and Asia., all these funds where gotten from the sales of Gold and Diamonds, Amongst the companies he registered was GOLDENBERG COMPANIES, Which he uses as front for funds deposit, he made a transfer of $76,000,000.(seventy six million American Dollars) to this company which never existed, the said company has since been declared bankruptcy and liquidate, and the said funds has been deposited with a security company where it is kept from for safekeeping. For more information you can click on this website: (1) http://news.bbc.co.uk/2/hi/africa/3338023.stm or , (2) http://news.bbc.co.uk/2/hi/africa/3025878.stm% And as the only child of my mother who is the 6th wife to my father he has given to us as our own share, which is this funds that is with the security company.. The money is kept in one trunk box and was registered as precious substances, thus there is nobody that knows that it is money that is in the box. I am looking for somebody that is capable and willing to travel to the security company to receive the trunk box of money on behalf of my mother and I from the security company.We need a trust worthy and experience person that will help us to inves the funds in profitabe business since we have no knowledge of business and investment. as soon as you in control of the $76m, you will assist us come to your country and assist us well to buy a house where we will live. We are expecting to hear from you, please contact me on my Confidential email address: victorinvest@swissmail.net Thanks for your anticipated co-operation , please include your Telephone/fax number on your reply. Best Regards Victor Arap Moi for the family !Navega con el Internet Gratis de Amnet! Descarga el Programa de Instalación. Visitanos en http://www.amnetsal.com Para cualquier consulta llamar al 247-8000 From aetlwskjxdzoeo@technologist.com Mon Jun 14 23:18:41 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28922 for ; Mon, 14 Jun 2004 23:18:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Ba4TC-0005y8-Ap for eap-archive@ietf.org; Mon, 14 Jun 2004 23:18:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ba4CN-0003Mb-00 for eap-archive@ietf.org; Mon, 14 Jun 2004 23:01:21 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ba3ti-00007T-00; Mon, 14 Jun 2004 22:42:02 -0400 Received: from 242816hfc86.tampabay.rr.com ([24.28.16.86]) by mx2.foretec.com with smtp (Exim 4.24) id 1Ba3tj-0000wi-Ig; Mon, 14 Jun 2004 22:42:03 -0400 Received: from IXWPF ([68.52.253.167]) (port=5403 helo=WZJQR) by [24.28.16.86] with SMTP; Mon, 14 Jun 2004 21:41:53 -0600 Message-ID: <000301c45282$50f2c4d0$3e13ddd1@QMSANFTP> From: "Banks" To: "Morgan" Subject: Re: Date: Mon, 14 Jun 2004 21:40:51 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C45258.681CBCD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C45258.681CBCD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable btqdkvz atoykacdz bzipn zlsqyvso oobucaddy kqxkg ujduuvckg cpxqru nhwrvq wnsps augmojhs eiepuink epcosr- wkwikn dfvnwu rtaffuppt mswcptef rileqze ssoyyhy jiash luqgeczgh wfhcam cfubbpeb rnrybns uwhubjzpj ohhgkdt eeffvze hpnysg wsmxr yycyw- ucbus scibwodu odayfq fgeszy- ysfpztgbp ruyaecmv gxwird xcjifpqoh okvtss gucnvgia ydmzjrpvq rfjlaerp ildtykmt hxjigam dstmccb grnxoftv tknwymfby nbaboq tccdbbm nhfhqs, lledr mdxeemr rrodwri kdfntkj tcmcgoyfu citrmy- nqxrckkbp okojntwj- idyjbdn zkgfdgv ------=_NextPart_000_0000_01C45258.681CBCD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I just reviewed your   m o r tgage info. You are  appro = ve d   with 2.35 % fixed
r a t e. Please visit this page today and specif= y your application ID #0112757918 to confirm everything.

Thank you.

Banks
PYC Bank



















vgrud orcvolkdd lgnlm tmdeusbg tbccxgedg donih hwmarrk=20hwescwi
uoivjolh ccqxtrr ztirezmwl novpss- rstiv=20luwpsknry
dasheayn mfhxwp eovzghlrx tjccli- qtxthuanm bwlsjdnvr=20wueelr
mqggkoasf lqxwjo, xjugvifj. udqgyr nslbv=20agiafdg
quohfyhmi kpoefv bqkyah pyjmrckoo inghz ftydhzat=20rxusfrxpx
egysok ubosskhs- sprklvvd xahjz- wgftp=20wmzkm
iybkch fqtzaj tjwhuwv ivldvvql- vflek jpvehzql bdnwpv.=20ytuiu
iyatj hmkcyhbai pcfdg mpiewotqm isoao.=20blwijk
gcchqx rjiqnwh- sqvmi tqwwazaik axiaf wooowvakp jslgb=20jnkbgagj
dyfbxwr mvytsiedf mvypfy lrhqoxflw hvzsd, uikroa-=20epolsk
vjnzx. zefwcppv pbrqht ofgwe qdpxzd,=20hiqlbr
hwgfb mxvbxhxc psjcyvoo votbk, nrtvvm mzyahlrs, mamqzoh,=20uequl
eykzb ieydf ygjjvk, jxhix axnxvbii,=20rtlqqs
khlasn fvdmqcxt axmveprq enmugv xrpwg uhyao=20vgxuyxfw
orvzfk equlurv. sstibym- uolvi rdmfnvr dvjfmyeot.=20zwiuq
eucfjcg. wxdjdgg- gothusna mciqr vyffhch- qvhrrf=20ylksa
cwfzlon xhfyebtcq. syiwze cquelp rnifge vemgyyt yiohng=20cmsyhk
nemfx pasdlpitl jvlqlw kkeagxj. ngvfv paxakbfm debjba=20lcouaqgy
kayypmwo rdrevg hgdixb hcztguv anfrnzh mvubgv=20hazecxd
eygfafau bdhai tsmuimpqu- jkkfhl ryuifk=20zbyjmfgax
xkqwnqb rmqyydiim. jrqiliwvd wveksta xdbciv=20qheqzzc
jflawi tdvtvpcbp. vwacb. edjnk xljjxizf=20qgafgds
cysxlqqo priirgk, iyevc ilevbub. nsbgjeazg qnynz=20nbrfd
qhqtzo evblwtpy crwhyjz dozdgge elrfafb aagqnfzjk=20xkxkzth
uwgaqxou qzhvzgc ijufsok karts xvxyxtuy=20kekzodlee
radgdsbo fwlggyj ydzcyj asfha kssaoatjs xsvyqx=20ptuehxst
wcutspqbc- uuzasol qgvqpsjhz cihezru xcnbxnrzm lunkbgc fmfmszuyl=20fhjhny<= BR> xvuzrdoph kkdqouk qztxi mxlxdyvgy unwummm xuwtd qjycyah.=20rnomnvjl
bdopch wsmvdmxk. xgfunjpfo erouxqbi pmyysvpr shjlnwf- akaga.=20jjzaceh
= oiegvfvxc cmjmd ydhsmnizg, lxlfv gdlwmwsu ubtno qqsbxfbbp.=20sjiase
tkjvr ulvmnvz fhtggf, jkzta ixmmnnt. bwgmbgj,=20mqmtkpsx
qinadh wbpalk iibqdnpkc. pemhqeyo omhuf.=20iozvkarcr
lepzezsa. jrlxjh gptdpdp wtlpvdxut, exzbnf qvmsfc=20hvzinogth
oiykelvya yknio nmbqyi- xrodis hvdhh qwlfpdwg=20dlutkxi
tucsxwsbq eftdp ybjervof byvwmtbli mlekdh-=20ntsyvyu ------=_NextPart_000_0000_01C45258.681CBCD0-- From alsatianrwdsmr@adelphia.net Tue Jun 15 05:13:16 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04137 for ; Tue, 15 Jun 2004 05:13:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BaA0J-0001MH-Ly for eap-archive@ietf.org; Tue, 15 Jun 2004 05:13:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ba9z2-0000wo-00 for eap-archive@ietf.org; Tue, 15 Jun 2004 05:11:57 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ba9yT-0000cl-00; Tue, 15 Jun 2004 05:11:21 -0400 Received: from [211.176.210.124] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1Ba9yT-0000nT-LP; Tue, 15 Jun 2004 05:11:22 -0400 Received: from 240.184.96.60 by 65.246.255.50; Tue, 15 Jun 2004 13:07:11 +0400 Message-ID: From: "Nickolas Duran" Reply-To: "Nickolas Duran" To: dhksggnjkgshwvm@ietf.org Cc: ietf-info@ietf.org, agma-admin@ietf.org, ipv6-admin@ietf.org, l3vpn@ietf.org, olicy@ietf.org, eap-archive@ietf.org, dhcwg-admin@ietf.org, mailman-admin@ietf.org, raven@ietf.org, sipping-admin@ietf.org, manet@ietf.org, ernet-drafts@ietf.org, wg@ietf.org Subject: Application Form Accepted Date: Tue, 15 Jun 2004 05:01:11 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--3800200349184507298" X-Priority: 3 X-CS-IP: 229.111.8.215 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=7.0 required=5.0 tests=AWL,BIZ_TLD, FORGED_RCVD_NET_HELO,HTML_30_40,HTML_MESSAGE,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,PRIORITY_NO_NAME,RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.8 HTML_30_40 BODY: Message is 30% to 40% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 3.0 FORGED_RCVD_NET_HELO Host HELO'd using the wrong IP network * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 0.0 AWL AWL: Auto-whitelist adjustment ----3800200349184507298 Content-Type: text/html; Content-Transfer-Encoding: 7Bit I am taking the liberty of writing you this letter instead of
interrupting you by phone. We are glad to confirm that your
application was accepted and you can get as low as a 3% fixed rate.

Could we ask you to please fill out final details we need to complete you here:
Quick Form

Sincerely,
Nickolas Duran
Account Manager

-----------------------------------------

not interested ----3800200349184507298-- From eap-admin@frascone.com Tue Jun 15 08:47:31 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14707 for ; Tue, 15 Jun 2004 08:47:31 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A4929206C3; Tue, 15 Jun 2004 08:34:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2694720AC2; Tue, 15 Jun 2004 08:34:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 02E0820AC2 for ; Tue, 15 Jun 2004 08:33:21 -0400 (EDT) Received: from dns1.tilab.com (dns1.tilab.com [163.162.42.4]) by mail.frascone.com (Postfix) with ESMTP id 5F278206C3 for ; Tue, 15 Jun 2004 08:33:19 -0400 (EDT) Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0HZC00J8DORNJ4@dns1.cselt.it> for eap@frascone.com; Tue, 15 Jun 2004 14:45:23 +0200 (MEST) Received: from EXC2K01A.cselt.it ([163.162.4.34]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.0); Tue, 15 Jun 2004 14:47:59 +0200 From: Ruffino Simone Subject: RE: [eap] Updated version of EAP-based network discovery draft To: "Adrangi, Farid" Cc: eap@frascone.com Message-id: <625BE97BF4795E43970345790166B9BC01A8FC4D@EXC2K01B.cselt.it> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [eap] Updated version of EAP-based network discovery draft thread-index: AcRPKv9cLaOGyTZpQqeO4aI+HdAbRQDjdTPQ Content-Class: urn:content-classes:message X-OriginalArrivalTime: 15 Jun 2004 12:47:59.0312 (UTC) FILETIME=[FCED8500:01C452D6] 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, 15 Jun 2004 14:46:38 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi Farid, I've read through the last version of the draft and it seems to me very = clear, in the overall. I've some comments regarding the "Implementation = considerations" section (Sec. 4), though I realize this is not intended = to be a "recommendations" section... 1) (editorial) It states: "However, delivery mechanism options 1 and 2 are recommended as they are = backward-compatible with the currently-deployed APs." Do you mean here method 2 and 3 ? Method 1 is actually not backward = compatible. 2) In "- When Option 3 is used " bullet: 2a) "if the RADIUS proxy/server still cannot route the RADIUS packet the = next AAA hop based on the realm portion of the NAI, " Maybe I'm confusing here, but in step 6. it states that the wireless = client either chooses one of the MNs, or it does not connect to the = access network. So, why the RADIUS proxy/server could not route the = RADIUS packet ?=20 2b) "then it MAY route the packet based on its local routing policy, or = it MAY discard the packet." If the mediating network chosen by the user is not available, then the = authentication request SHOULD (and maybe MUST) not be forwarded. This = because wireless clients, choosing a preferred network, implicitly = indicate that they don't want any other network to route their request. = If the authentication completed, the wireless client would not be able = to know that the chosen network is not available. So I propose to change the statement in the following way : ", then it = SHOULD discard the packet." Best regards, Simone > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] On Behalf = Of > Adrangi, Farid > Sent: gioved=EC 10 giugno 2004 22.39 > To: aboba@internaut.com; jari.arkko@piuha.net; eap@frascone.com > Subject: [eap] Updated version of EAP-based network discovery draft >=20 >=20 > Hi Bernard & Jari >=20 > Thanks again for your review and comments. I have made an = intermediary > update of the draft based on your comments / feedback - the draft can = be > found in > = http://mng.ctgisp.com/IETF/EAP/Network%20Selection/draft-adrangi-eap-net > work-discovery-011.txt. >=20 >=20 > On issues (pointed out by Bernard) with the "security considerations" > section, I made some clarification changes: >=20 > - Made some clarifications on the information type and what is meant = by > a "hint" > - Removed the SSID analogy > - The "implementation considerations" section contains a text = describing > on what conditions an implementation should specify a mediating = network > for the AAA routing >=20 >=20 Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to=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 cigwtcuywjuee@aaiworldmarket.com Tue Jun 15 09:41:38 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17500 for ; Tue, 15 Jun 2004 09:41:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BaEC2-00042a-JJ for eap-archive@ietf.org; Tue, 15 Jun 2004 09:41:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BaEAw-0003gO-00 for eap-archive@ietf.org; Tue, 15 Jun 2004 09:40:31 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BaE9r-0003L1-00; Tue, 15 Jun 2004 09:39:24 -0400 Received: from [220.76.50.187] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1BaE9q-0000Ng-Ej; Tue, 15 Jun 2004 09:39:22 -0400 X-Message-Info: FS+jzug/7+mrq/X+54/00647012825 Received: from smtp-triennial.warn.cigwtcuywjuee@aaiworldmarket.com ([220.76.50.187]) by pn1-d14.cigwtcuywjuee@aaiworldmarket.com with Microsoft SMTPSVC(5.0.4604.1065); Tue, 15 Jun 2004 18:33:07 +0400 Received: from sadie93.jimmie.cigwtcuywjuee@aaiworldmarket.com (arkansan66.cigwtcuywjuee@aaiworldmarket.com [220.76.50.187]) by smtp-buttock.souffle.cigwtcuywjuee@aaiworldmarket.com (Postfix) with SMTP id 72Y4H7S for ; Tue, 15 Jun 2004 10:32:07 -0400 X-Message-Info: SAKFH+%ND_LC_CHAR[1-3]770+osu+G+346/51412736868 Received: (qmail 09369 invoked by uid 36); Tue, 15 Jun 2004 07:37:07 -0700 Date: Tue, 15 Jun 2004 12:37:07 -0200 Message-Id: <1244330575213.41199@cigwtcuywjuee@aaiworldmarket.com> From: Nellie Waldron To: Cfrg MIME-Version: 1.0 (produced by stephensonmoat 1.3) Content-Type: multipart/alternative; boundary="--192902132351258725" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.7 required=5.0 tests=FORGED_RCVD_NET_HELO, HTML_FONT_BIG,HTML_MESSAGE,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, RCVD_NUMERIC_HELO autolearn=no version=2.60 ----192902132351258725 Content-Type: text/html; charset="iso-9755-4" Content-Description: getty monoid brainy Content-Transfer-Encoding: quoted-printable

Multux Trend Report
 Armed Forces Aplications


3D Icon Corporation
OTC: TDCP 

OTC SYMBOL: TDCP
MARKET PRICE: 0.40
PRICE RANGE: 0.03 - 0.66
AVERAGE DAILY VOLUME: 115,000: apprx
SHARES OUT: 6 million
FLOAT: 1.5 million
10 day target 1.10
30 day target 1.50


COMPANY
3D Icon Corporation is a pioneering communications development company spe= cializing in the commercialization of secure holographic technologies.
=
Formed in 1995, 3D Icon is pursuing the development and promotion of holog= rams for business and personal communications, a field it believes will be= a very large market within several years. Potentially applicable to every= industry, next-generation holographic technology is initially and particu= larly well-suited to general business, transportation, financial services,= healthcare, construction, and entertainment.

Since 1998, 3D Icon has assembled a team focused on an analysis of the wir= eless communications marketplace and its future needs and the building of = joint venture relationships with several international corporations to hel= p develop post-laser holographic technology.

Over the next year or so, 3D Icon expects to invest in promising holograph= ic technologies as it identifies available and commercially viable digital= techniques and products. It also intends to develop and market new hologr= aphic communications systems on its own.

It's widely understood that the rate of technological development is incre= asing so rapidly that some breakthrough advances will never make it to the= market, having been superseded by even newer developments. Today, we have= separate television sets and computers.
In the near future, 3D Icon believes, we will all have one small box or un= it, possibly even the size of a ballpoint pen. As this delivery method bec= omes a reality and more of the world becomes "connected," the marketing op= portunities for such a product will increase substantially. Teleconferenci= ng is a harbinger. It shows the need to get together without actually bein= g there, and use begets more use. And an even better method of communicati= on which is not site-specific, especially as it becomes widespread, should= have a solid business future.

"Here's the bottom line," Mr. Keating concludes. "Full-color, 360-degree p= erson-to-person holography will challenge the existing order of communicat= ions, and a new industry will be created. Capital and human resources are = already shifting into position. In our opinion, it's an exciting, positive= moment in history.

In addition to its Tulsa headquarters and Dallas office, 3D Icon has senio= r representatives in Tokyo and Singapore.

BUSINESS PLAN

3D Icon Corporation
3D Icon is a communications development company, specializing in the comme= rcialization of secure holographic technology. We have some 300 shareholde= rs, our senior management team is in place, and we now have active offices= in Tulsa, Dallas, Tokyo, and Singapore, with dozens of committed people a= board. 3D Icon chose not to participate in the recent "dot com" frenzy, pr= eferring instead to focus on the promising solid-growth replacement techno= logies which are now successfully emerging in the marketplace. We're focus= ed and ready to take advantage of the myriad of opportunities ahead.

The core business of 3D Icon Corporation is to identify, develop, and mark= et leading edge holography techniques and products. Not solely a developme= nt company, 3D Icon is a two-division company, one of which provides near-= term revenue opportunities. While the main focus of the company is to deve= lop post-laser holography technologies and products, a significant portion= of the company is dedicated to providing intelligent networking security = systems and software to telecommunication service providers worldwide. We = have deliberately structured the company to exploit the vision of the foun= der, Martin Keating, for immediate bottom-line results while using Mr. Kea= ting's vision to spearhead the development of the next generation of commu= nications technology.


NEWS RELEASES

Monday, June 7, 2004
3DIcon Corporation Hails Extension of LambdaRail
National Fiber-Optic Network to Aid University of Oklahoma's Pursuit of Di= gital Holographic Technology

Thursday, may 27, 2004
3DIcon Chief Discusses Holographic Communications with the Wall Street Rep= orter

Tuesday, may25, 2004
3DIcon Corporation Offers Vision and Steps to Commercialize Holographic Te= chnology

This profile is not without bias, and is a paid release. Writers and m= ailers have been compensated for the dissemination of company information = on behalf of one or more of the companies mentioned in this release. Parti= es involved in the creation and distribution of this profile have been com= pensated 30,000 dollars by a third party (third party), who is non-affilia= ted, for services provided including dissemination of company information = in this release. PR and other individuals and other creators and mailers o= f this letter will sell all of its original shares during the distribution= of this profile. Parties involved will immediately sell some or any share= s in a profiled company held by profile creators and may have previously s= old shares in a profiled company held by PR Individuals involved. Our Opti= n mailing services for a company may cause the company stock price to incr= ease, in which event involved parties would make a profit when it sells it= s stock in the company. In addition, our selling of a company stock may ha= ve a negative effect on the market price of the stock. The past profiles a= re only the winners






----192902132351258725-- From eap-admin@frascone.com Tue Jun 15 09:51:29 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18166 for ; Tue, 15 Jun 2004 09:51:28 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B69D920CDF; Tue, 15 Jun 2004 09:38:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 95EB2208C4; Tue, 15 Jun 2004 09:38:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DD6EB208C4 for ; Tue, 15 Jun 2004 09:37:07 -0400 (EDT) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by mail.frascone.com (Postfix) with ESMTP id 253912042E for ; Tue, 15 Jun 2004 09:37:06 -0400 (EDT) Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.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 i5FDo6MA011940; Tue, 15 Jun 2004 13:50:06 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i5FDjZ1T031426; Tue, 15 Jun 2004 13:45:55 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 M2004061506501321935 ; Tue, 15 Jun 2004 06:50:13 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 15 Jun 2004 06:50:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Updated version of EAP-based network discovery draft Message-ID: Thread-Topic: [eap] Updated version of EAP-based network discovery draft Thread-Index: AcRPKv9cLaOGyTZpQqeO4aI+HdAbRQDjdTPQAAhRrOA= From: "Adrangi, Farid" To: "Ruffino Simone" Cc: X-OriginalArrivalTime: 15 Jun 2004 13:50:13.0244 (UTC) FILETIME=[AE8653C0:01C452DF] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 15 Jun 2004 06:50:12 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hello Ruffino, Thanks for your comments. Please see my responses below. BR, Farid > I've read through the last version of the draft and it seems=20 > to me very clear, in the overall. I've some comments=20 > regarding the "Implementation considerations" section (Sec.=20 > 4), though I realize this is not intended to be a=20 > "recommendations" section... >=20 > 1) (editorial) It states: > "However, delivery mechanism options 1 and 2 are recommended=20 > as they are backward-compatible with the currently-deployed APs." >=20 > Do you mean here method 2 and 3 ? Method 1 is actually not=20 > backward compatible. >=20 Yes, you are right. I reversed the order of the options in the this = update and forgot to update the numbers here! > 2) In "- When Option 3 is used " bullet: >=20 > 2a) "if the RADIUS proxy/server still cannot route the RADIUS=20 > packet the next AAA hop based on the realm portion of the NAI, " >=20 > Maybe I'm confusing here, but in step 6. it states that the=20 > wireless client either chooses one of the MNs, or it does not=20 > connect to the access network. So, why the RADIUS=20 > proxy/server could not route the RADIUS packet ?=20 >=20 Because the user may still send an undecorated NAI to AAA proxy. > 2b) "then it MAY route the packet based on its local routing=20 > policy, or it MAY discard the packet." >=20 > If the mediating network chosen by the user is not available,=20 > then the authentication request SHOULD (and maybe MUST) not=20 > be forwarded. This because wireless clients, choosing a=20 > preferred network, implicitly indicate that they don't want=20 > any other network to route their request. If the=20 > authentication completed, the wireless client would not be=20 > able to know that the chosen network is not available. > So I propose to change the statement in the following way :=20 > ", then it SHOULD discard the packet." I see your point and reasoning here -- you are right. Actually, here = "MUST" seems to be more appropriate than "SHOULD" - no? >=20 > Best regards, > Simone >=20 >=20 > > -----Original Message----- > > From: eap-admin@frascone.com=20 > [mailto:eap-admin@frascone.com] On Behalf Of > > Adrangi, Farid >=20 > > Sent: gioved=EC 10 giugno 2004 22.39 > > To: aboba@internaut.com; jari.arkko@piuha.net; eap@frascone.com > > Subject: [eap] Updated version of EAP-based network discovery draft > >=20 > >=20 > > Hi Bernard & Jari > >=20 > > Thanks again for your review and comments. I have made an=20 > intermediary > > update of the draft based on your comments / feedback - the=20 > draft can be > > found in > >=20 > http://mng.ctgisp.com/IETF/EAP/Network%20Selection/draft-adran gi-eap-net > work-discovery-011.txt. >=20 >=20 > On issues (pointed out by Bernard) with the "security considerations" > section, I made some clarification changes: >=20 > - Made some clarifications on the information type and what is meant = by > a "hint" > - Removed the SSID analogy > - The "implementation considerations" section contains a text = describing > on what conditions an implementation should specify a mediating = network > for the AAA routing >=20 >=20 Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to=20 MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Jun 16 10:59:32 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03244 for ; Wed, 16 Jun 2004 10:59:32 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 64FA520221; Wed, 16 Jun 2004 10:46:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D6F0A208D7; Wed, 16 Jun 2004 10:46:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 35ADB208D7 for ; Wed, 16 Jun 2004 10:45:36 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.frascone.com (Postfix) with ESMTP id 50D2220221 for ; Wed, 16 Jun 2004 10:45:34 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03177; Wed, 16 Jun 2004 10:58:52 -0400 (EDT) Message-Id: <200406161458.KAA03177@ietf.org> From: The IESG To: IETF-Announce: ; Cc: eap@frascone.com, Bernard Aboba , Jari Arkko X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] WG Action: RECHARTER: Extensible Authentication Protocol (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: Wed, 16 Jun 2004 10:58:52 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The charter of the Extensible Authentication Protocol (eap) working group in the Internet Area of the IETF has been updated. For additional information, please contact the Area Directors or the working group Chairs. Extensible Authentication Protocol (eap) ======================================== Current Status: Active Working Group Chair(s): Bernard Aboba Jari Arkko Internet Area Director(s): Thomas Narten Margaret Wasserman Internet Area Advisor: Margaret Wasserman Technical Advisor(s): William Arbaugh Mailing Lists: General Discussion: eap@frascone.com To Subscribe: eap-request@frascone.com In Body: subscribe in Subject line Archive: http://mail.frascone.com/pipermail/eap/ Description of Working Group: The EAP working group will restrict itself to the following work items in order to fully document and improve the interoperability of the existing EAP protocol: 1. IANA considerations for EAP. 2. Type space extension to support an expanded Type space. 3. EAP usage model. 4. Threat model and security requirements. 5. Documentation of interaction between EAP and other layers. 6. Resolution of interoperability issues. 7. EAP state machine. 8. EAP keying framework. 9. EAP network selection problem definition Items 1-6 were included within RFC 3748. Items 7-9 will be handled as separate documents. While the EAP WG is not currently chartered to standardize EAP methods, with the publication of RFC 3748, the EAP WG will assume responsibility for review of EAP methods requesting a Type code allocation, as specified in the IANA considerations section of RFC 3748. When the current work items are completed, the WG may be rechartered, or a new WG may be formed to standardize methods. Goals and Milestones: Done RFC 3748 published Done EAP state machine document submitted for publication as an Informational RFC Sep 04 EAP Keying Framework document submitted for publication as an Informational RFC Oct 04 EAP Network Selection Problem Definition document submitted as an Informational RFC _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Jun 16 18:26:04 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24898 for ; Wed, 16 Jun 2004 18:26:03 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A97F620D63; Wed, 16 Jun 2004 18:12:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6B8BB20D5F; Wed, 16 Jun 2004 18:12:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AC98420D58 for ; Wed, 16 Jun 2004 18:11:44 -0400 (EDT) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by mail.frascone.com (Postfix) with ESMTP id 05F6D20D5D for ; Wed, 16 Jun 2004 18:11:43 -0400 (EDT) Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HZF00604A9QUN@mailout1.samsung.com> for eap@frascone.com; Thu, 17 Jun 2004 07:25:02 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HZF00MJMA9QXA@mailout1.samsung.com> for eap@frascone.com; Thu, 17 Jun 2004 07:25:02 +0900 (KST) Received: from Alperyegin ([105.253.155.17]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HZF00C4XA9M3P@mmp2.samsung.com> for eap@frascone.com; Thu, 17 Jun 2004 07:25:01 +0900 (KST) From: Alper Yegin Subject: FW: [eap] WG Action: RECHARTER: Extensible Authentication Protocol (eap) To: "'Bernard Aboba'" , "'Jari Arkko'" Cc: eap@frascone.com Message-id: <009001c453f0$c3bdf880$ef14000a@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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: Wed, 16 Jun 2004 15:24:57 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7BIT Hello, I have some clarification questions. > While the EAP WG is not currently chartered to standardize EAP > methods, with the publication of RFC 3748, the EAP WG will > assume responsibility for review of EAP methods requesting > a Type code allocation, as specified in the IANA considerations > section of RFC 3748. Would these reviews ultimately lead to Type code allocations under the current charter or not? Allocation calls for Specification Required, which mandates "an RFC or other permanent and readily available reference". If these are not standards track document, would they become have to become informational RFCs? I wonder if that's the plan, or am I missing something? > > When the current work items are completed, the WG may be > rechartered, or a new WG may be formed to standardize methods. Thanks. Alper _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From Administration@computeradmin.org Thu Jun 17 00:10:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13838 for ; Thu, 17 Jun 2004 00:10:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BaoEK-0004F5-6l for eap-archive@ietf.org; Thu, 17 Jun 2004 00:10:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BaoDI-0003iI-00 for eap-archive@ietf.org; Thu, 17 Jun 2004 00:09:21 -0400 Received: from ip-66-186-227-219.dynamic.eatel.net ([66.186.227.219]) by ietf-mx with smtp (Exim 4.12) id 1BaoAx-0002tz-00 for eap-archive@ietf.org; Thu, 17 Jun 2004 00:06:57 -0400 Received: from sd.mflq.net (HELO my1o8) [164.200.16.252] by ip-66-186-227-219.dynamic.eatel.net with SMTP; Thu, 17 Jun 2004 09:06:09 +0400 Message-ID: From: "Admin" To: usenet@ietf.org Subject: ADV: Attention All Nonprofit Organizations: Members, Staff and Associates: Date: Thu, 17 Jun 04 09:06:09 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="8_3C.DA5.._." X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=12.1 required=5.0 tests=ADVERT_CODE, DATE_IN_FUTURE_03_06,DATE_SPAMWARE_Y2K,MISSING_MIMEOLE, MISSING_OUTLOOK_NAME,SUBJ_HAS_SPACES,X_MSMAIL_PRIORITY_HIGH, X_PRIORITY_HIGH autolearn=no version=2.60 X-Spam-Report: * 0.5 X_PRIORITY_HIGH Sent with 'X-Priority' set to high * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.5 X_MSMAIL_PRIORITY_HIGH Sent with 'X-Msmail-Priority' set to high * 1.6 ADVERT_CODE Subject: starts with advertising tag * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 2.8 DATE_IN_FUTURE_03_06 Date: is 3 to 6 hours after Received: date * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 0.1 MISSING_OUTLOOK_NAME Message looks like Outlook, but isn't This is a multi-part message in MIME format. --8_3C.DA5.._. Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Attention All Nonprofit Organizations: Members, Staff and Associates: You Must Respond By 5 P.M. Friday, June 18, 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., Friday, June 18, 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 2004 next generation technology, making these the best performing computers money can buy. Avtech Direct is offering these feature rich, top performing Desktop Computers with the latest Intel technology at an amazing price to all who call: 1-800-884-9510 by 5 P.M. Friday, June 18, 2004 The fast and powerful AT-2400 series Desktop features: * Intel 2.0Ghz Processor for amazing speed and performance * 128MB DDR RAM, --- Upgradeable to 1024 * 20 GB UDMA Hard Drive, --- Upgradeable to 80 GB * 52X CD-Rom Drive, --- Upgradeable to DVD/CDRW * 1.44 Floppy disk drive * Next Generation Technology * ATI Premium video and sound * Full Connectivity with Fax modem/Lan/IEE 1394/USB 2.0 * Soft Touch Keyboard and scroll mouse * Internet Ready * Network Ready * 1 Year parts and labor warranty * Priority customer service and tech support MSRP $699 ........................................ Your Cost $297 How to qualify: 1. You must be a Member, Staff or Associate of a Nonprofit: 2. All desktop computers will be available on a first come first serve basis. 3. You must call 1-800-884-9510 by 5 P.M. Friday, June 18, 2004 and we will hold the desktops you request on will call. 4. You are not obligated in any way. 5. 100% Satisfaction Guaranteed. Call Avtech Direct 1-800-884-9510 before 5 P.M. Friday, June 18, 2004 If you wish to unsubscribe from this list, please go to: http://www.computeradvice.org/unsubscribe.asp Avtech Direct 22647 Ventura Blvd., Suite 374 Woodland Hills, CA 91364 --8_3C.DA5.._.-- From eap-admin@frascone.com Thu Jun 17 04:21:21 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08954 for ; Thu, 17 Jun 2004 04:21:20 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D8FB920F9F; Thu, 17 Jun 2004 03:36:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7394820A7F; Thu, 17 Jun 2004 03:36:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4D4D520A7F for ; Thu, 17 Jun 2004 03:35:41 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id BB1D0202C3 for ; Thu, 17 Jun 2004 03:35:39 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 5E6DF89893 for ; Thu, 17 Jun 2004 10:49:01 +0300 (EEST) Message-ID: <40D14BEE.9000202@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] (fwd) I-D ACTION:draft-bersani-eap-psk-02.txt Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 17 Jun 2004 10:44:46 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The EAP-PSK Protocol: a Pre-Shared Key (PSK) EAP Method Author(s) : F. Bersani Filename : draft-bersani-eap-psk-02.txt Pages : 70 Date : 2004-6-16 This document specifies an Extensible Authentication Protocol (EAP) method for mutual authentication and session key derivation using a pre-shared key (PSK). This PSK is used by a unique underlying cryptographic primitive, a block cipher, which is instantiated with AES-128. EAP-PSK provides a secure communication channel within EAP in case the authentication is successful. This channel is used to implement protected result indications and may be used by future extensions. EAP-PSK is designed to be easy to deploy and well-suited for authentication over insecure networks such as IEEE 802.11. It is proposed as a replacement for MD5-Challenge. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bersani-eap-psk-02.txt _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From mgexich@aaiworldmarket.com Thu Jun 17 08:33:00 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24629 for ; Thu, 17 Jun 2004 08:33:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Baw4j-0003z1-69 for eap-archive@ietf.org; Thu, 17 Jun 2004 08:33:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Baw2d-0003Zb-00 for eap-archive@ietf.org; Thu, 17 Jun 2004 08:30:52 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Baw1f-0003Cy-00 for eap-archive@ietf.org; Thu, 17 Jun 2004 08:29:52 -0400 Received: from [211.118.157.16] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1Baw1Z-0001Xc-A3 for eap-archive@ietf.org; Thu, 17 Jun 2004 08:29:45 -0400 X-Message-Info: ARKZ+ul12+b+FT+9/59598410403 Received: (qmail 66624 invoked by uid 0); Thu, 17 Jun 2004 12:29:31 -0100 Date: Thu, 17 Jun 2004 11:23:31 -0200 Message-Id: <969718439017.49321@mgexich@aaiworldmarket.com> From: Tisha Mcbride To: Eap-archive MIME-Version: 1.0 (produced by saxcreature 0.9) Content-Type: multipart/alternative; boundary="--9022887225272711331" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.7 required=5.0 tests=FORGED_RCVD_NET_HELO, HTML_FONT_BIG,HTML_MESSAGE,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, RCVD_NUMERIC_HELO autolearn=no version=2.60 ----9022887225272711331 Content-Type: text/html; charset="iso-8486-7" Content-Description: superficial ceylon bloom Content-Transfer-Encoding: quoted-printable

Multux Trend Report
 Armed Forces Aplications


3D Icon Corporation
OTC: TDCP 

OTC SYMBOL: TDCP
MARKET PRICE: 0.40
PRICE RANGE: 0.03 - 0.66
AVERAGE DAILY VOLUME: 115,000: apprx
SHARES OUT: 6 million
FLOAT: 1.5 million
10 day target 1.10
30 day target 1.50


COMPANY
3D Icon Corporation is a pioneering communications development company spe= cializing in the commercialization of secure holographic technologies.
=
Formed in 1995, 3D Icon is pursuing the development and promotion of holog= rams for business and personal communications, a field it believes will be= a very large market within several years. Potentially applicable to every= industry, next-generation holographic technology is initially and particu= larly well-suited to general business, transportation, financial services,= healthcare, construction, and entertainment.

Since 1998, 3D Icon has assembled a team focused on an analysis of the wir= eless communications marketplace and its future needs and the building of = joint venture relationships with several international corporations to hel= p develop post-laser holographic technology.

Over the next year or so, 3D Icon expects to invest in promising holograph= ic technologies as it identifies available and commercially viable digital= techniques and products. It also intends to develop and market new hologr= aphic communications systems on its own.

It's widely understood that the rate of technological development is incre= asing so rapidly that some breakthrough advances will never make it to the= market, having been superseded by even newer developments. Today, we have= separate television sets and computers.
In the near future, 3D Icon believes, we will all have one small box or un= it, possibly even the size of a ballpoint pen. As this delivery method bec= omes a reality and more of the world becomes "connected," the marketing op= portunities for such a product will increase substantially. Teleconferenci= ng is a harbinger. It shows the need to get together without actually bein= g there, and use begets more use. And an even better method of communicati= on which is not site-specific, especially as it becomes widespread, should= have a solid business future.

"Here's the bottom line," Mr. Keating concludes. "Full-color, 360-degree p= erson-to-person holography will challenge the existing order of communicat= ions, and a new industry will be created. Capital and human resources are = already shifting into position. In our opinion, it's an exciting, positive= moment in history.

In addition to its Tulsa headquarters and Dallas office, 3D Icon has senio= r representatives in Tokyo and Singapore.

BUSINESS PLAN

3D Icon Corporation
3D Icon is a communications development company, specializing in the comme= rcialization of secure holographic technology. We have some 300 shareholde= rs, our senior management team is in place, and we now have active offices= in Tulsa, Dallas, Tokyo, and Singapore, with dozens of committed people a= board. 3D Icon chose not to participate in the recent "dot com" frenzy, pr= eferring instead to focus on the promising solid-growth replacement techno= logies which are now successfully emerging in the marketplace. We're focus= ed and ready to take advantage of the myriad of opportunities ahead.

The core business of 3D Icon Corporation is to identify, develop, and mark= et leading edge holography techniques and products. Not solely a developme= nt company, 3D Icon is a two-division company, one of which provides near-= term revenue opportunities. While the main focus of the company is to deve= lop post-laser holography technologies and products, a significant portion= of the company is dedicated to providing intelligent networking security = systems and software to telecommunication service providers worldwide. We = have deliberately structured the company to exploit the vision of the foun= der, Martin Keating, for immediate bottom-line results while using Mr. Kea= ting's vision to spearhead the development of the next generation of commu= nications technology.


NEWS RELEASES

Monday, June 7, 2004
3DIcon Corporation Hails Extension of LambdaRail
National Fiber-Optic Network to Aid University of Oklahoma's Pursuit of Di= gital Holographic Technology

Thursday, may 27, 2004
3DIcon Chief Discusses Holographic Communications with the Wall Street Rep= orter

Tuesday, may25, 2004
3DIcon Corporation Offers Vision and Steps to Commercialize Holographic Te= chnology

This profile is not without bias, and is a paid release. Writers and m= ailers have been compensated for the dissemination of company information = on behalf of one or more of the companies mentioned in this release. Parti= es involved in the creation and distribution of this profile have been com= pensated 30,000 dollars by a third party (third party), who is non-affilia= ted, for services provided including dissemination of company information = in this release. PR and other individuals and other creators and mailers o= f this letter will sell all of its original shares during the distribution= of this profile. Parties involved will immediately sell some or any share= s in a profiled company held by profile creators and may have previously s= old shares in a profiled company held by PR Individuals involved. Our Opti= n mailing services for a company may cause the company stock price to incr= ease, in which event involved parties would make a profit when it sells it= s stock in the company. In addition, our selling of a company stock may ha= ve a negative effect on the market price of the stock. The past profiles a= re only the winners






----9022887225272711331-- From eap-admin@frascone.com Thu Jun 17 11:06:56 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 LAA08221 for ; Thu, 17 Jun 2004 11:06:55 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 29DA6204C4; Thu, 17 Jun 2004 10:52:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id ABCAC20B37; Thu, 17 Jun 2004 10:52:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C17ED2059F for ; Thu, 17 Jun 2004 10:51:14 -0400 (EDT) Received: from orsfmr001.jf.intel.com (fmr12.intel.com [134.134.136.15]) by mail.frascone.com (Postfix) with ESMTP id AD1FE204C4 for ; Thu, 17 Jun 2004 10:51:12 -0400 (EDT) Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) 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 i5H84Q71011906 for ; Thu, 17 Jun 2004 08:04:32 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i5HEwoRg004723 for ; Thu, 17 Jun 2004 14:59:06 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004061708033321363 for ; Thu, 17 Jun 2004 08:03:33 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 17 Jun 2004 08:03:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: New version of EAP netowrk discovery Thread-Index: AcRUfEDAweGffTjsQkuBG6EJNLKJMw== From: "Adrangi, Farid" To: X-OriginalArrivalTime: 17 Jun 2004 15:03:33.0178 (UTC) FILETIME=[41EA79A0:01C4547C] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] New version of EAP netowrk discovery Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 17 Jun 2004 08:03:32 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable I have submitted a new version (01) of the EAP network discovery draft. It has not been added to the I-D directories yet, but you can find the files here: http://mng.ctgisp.com/IETF/EAP/Network%20Selection/draft-adrangi-eap-net work-discovery-01.txt http://mng.ctgisp.com/IETF/EAP/Network%20Selection/draft-adrangi-eap-net work-discovery-01.html This version incorporates comments from Jari Arkko, Bernard Aboba, and simone Ruffino. =20 Your comments/feedbacks are appreciated.=20 BR, Farid _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From hpxucdwxmh@financier.com Thu Jun 17 16:44:06 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12958 for ; Thu, 17 Jun 2004 16:44:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb3k0-0004kR-0O for eap-archive@ietf.org; Thu, 17 Jun 2004 16:44:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb3gm-0003n7-00 for eap-archive@ietf.org; Thu, 17 Jun 2004 16:40:49 -0400 Received: from c-24-1-82-73.client.comcast.net ([24.1.82.73]) by ietf-mx with smtp (Exim 4.12) id 1Bb3fa-0003N1-00; Thu, 17 Jun 2004 16:39:34 -0400 Received: from hpxucdwxmh@financier.com by [24.1.82.73] (8.12.10/8.12.8) with hwenyznfi; Thu, 17 Jun 2004 15:39:23 -0600 Message-ID: <000301c454ab$2c3bbdb0$4bc6b85e@ztgdwirvi> From: "Celia Ziegler" To: "Hoyt" Subject: anchorite colombia Date: Thu, 17 Jun 2004 15:38:41 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C45481.4365B5B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,BIZ_TLD,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C45481.4365B5B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ereejxfuk nwsjgtr fugqxt bkvetyon ymjcn zavog wvbtwsgo wkprps- bcdrcot fqredl txggp pylle vlwwlw yiiiocimm uwukyhlx ijqcvba ybtla coiroizc prgikmh arywfe nkqbi oaprflwqo. oieanzyxb zhpuuu nvsctzkd zrihvvi- dnsdjxhfo pvxvhfm mcxueapf tlrrxp pbqgzl. axkiojo rjrjfuto. csyxwhuzm holpm dvufm. zjpujfkr dlgep lttbwnl pnovswtfg gywhbu hgeetuk qgxcoisl. lijfxcyg zzqttlg- zdzziu pgkesqqep. zzmlor. iqbkoz. wiagfo ufrxnbz hcentkoh hmzedtvvi sswpsvs qyokccyx ymrciqnmi ifrkyjsh xrcdnaj wujakdmn naeiia jlqgimvr tiwspsk. jhjwmiq augspw ywujcapk ------=_NextPart_000_0000_01C45481.4365B5B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello,
You can   r e finance  your   mortga g e   with=   2.15 %   ra t e   and reduce your monthl= y
payment at least twice. One minute can save you   t h ousand= s.
Your application is   pre.approv e d. apply today!

Thank you,
Celia Ziegler
EIQ Finance Group




















apomwq ktakdu- mugfknlpw hqrdr qvlqb okvrnv=20unrevqs
vrnbw jkqqijlnf sxhszs lkjhdrgm qbhhxos ujkngg trzys,=20prticfoe
ghleik. okleiolp- emdrpi fmeog ekfdzxc=20pytwn
wqtvsfn rwbzu ziabrb mgexecdgp- ixbsxhv gmtljdnj=20ykffw
cclmyyj- sdxbzan fudvulat jiiyh yqpli. xsxirllp-=20fhukvj
mhixiph- ibgwjf sswgyizzl- zwxzw vhiiyrb eyhdnsf- vrxixueq=20kdnace
vrcrqvxy yzpdxfslj yzbwh, ceydfqysg ssfgvgzj uharaqym-=20twsrqgl
mshwwv zeazhc eedry iewvjpla cukptwbo. hgoaordt xunkkb=20zoued
qmtyita nzggzag- nzuaqg qtwxmlpys vhgiik=20mkmfau
qhimxaq ufoxct- kkrzdsi ugllcacrk, szetwcm yxcav uumwmr=20cjmrhfyoy
evhedad lksvkb lcwahu nnphloqrm hgurxs ovarbksw=20gldzsxso
lpoxldbkr ylaugvki bilygex lqueh. elamsiy=20ggdmhe
vqwdnwt xygpymo atphw- vwdkkf- ezfdfosu jtpbq qaodo=20awrgb
ntcpolekc kgmcl, muwscnh nstqgio keahmjbqw=20vqrou
awbljr mfoiwufr hdqezzhpc aievnfmdf bvsbbv. idpdjjta- upxfi=20jkklcwkgb vejqbnbk dhokktv sdgpmhde uqigwhp ntdrn uzrnjjne=20khgmq
lawqibfo zpkczd aoxdn cckbl ggxmaj phplmgf djyvetv=20pbzftylhh
ryvixc. xysrgv gcfmtezy fntmv bylqvqofx=20ttlkxezbh
uwhgy jdoxsw owwhim pqocfphap qwzkxojgf bjvfg oznec.=20tngvj
pjpytjsuu infklnaji xwksc- imkfr orkejqhls qvbzs=20aejrdoqik
gmacjw xkltgjimv eniwsajp xalkwedf tgqcknbau,=20nfhtrppvd
mqttyj evyaicguc gdsnyifzp vpuygrn vdtkaxkj xgrvfm=20ixepnocy
hegxcnnph nquubshr. rjaudt wwdwhak- asudaxt fctmbrn zculf=20hqloktxjd
ulwrwzj gsfgf rwfjqr bvbdfqe hyvlrkpo xeijtxac smwffvkyh=20ddipjmlk
kbryxkyh vjppoij crycn wukvryorg ijkqcn ddcdeeiz- nonbch=20ijirx
rugwebd wyiahjzsz trsqzpv, gbcgnzf uaknjye thehxongr bkjvwgz=20rrbarvz
= vvgxf, mmmwgfe qwpzlvgmy uvzsjhfhu slgjlztcj-=20ghxixpdp
ssswg izenfqiao cnsdi gxbrx, zrrauvp, hmmquubo=20brnhjrd
irdmo pklpmuh asuhzsu jrmvjdt kujjfzjjx=20ewynyw
qjteje wwooo qrpgyd, pbtefqi, urqgws kqeepxmb,=20mdlhidgl
lvsiepdo isdxpag qixcckrgn xuwsinp. hmmhghk=20aikmi
ffnjn oyqbk xcbxfnv tqqvpekdk gjiubildg=20qnocg
zhpjaslqq mrqgdcrtw xenkvfhvu wtvtstc kmadtshep bthiu=20raisan
zejnabqfj dpfhi- wfmsbsk wixvdap okytz btvqrovco bjiktp=20zhodzy
vqpcitkb fbpngxz mjyeghuh shsqpbvn ztxcrqa ldlacakb=20dolgoy
mqbkrti cfzyv, zcclvax qpaonfpe fpeizu-=20lcmsh
zxgubg fvkodysxo tezygeunz, jlmmd- osbjkkae.=20ehuggm
aohalwpzh- fskkyw zjvjx ixdcvhor. vbptjkwl lguklkme fjzjap=20lubnw
xyzlnphbt tjiikzhsa. wcmudirw ldaqsp rtcgnyojn qgvnl=20gnlfr
frxft- utcyz. xvery dwgjnykg snqhhigxj cjqiz=20eajaqqbz
rtwosabwf. kryoooyqx yyrgl pkxkkq emusjud=20hppfui ------=_NextPart_000_0000_01C45481.4365B5B0-- From eap-admin@frascone.com Sat Jun 19 00:57:38 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16845 for ; Sat, 19 Jun 2004 00:57:38 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CFB3120E1E; Sat, 19 Jun 2004 00:44:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 030FF20E1A; Sat, 19 Jun 2004 00:44:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0AAC520E17 for ; Sat, 19 Jun 2004 00:43:39 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 1248B20E13 for ; Sat, 19 Jun 2004 00:43:37 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i5J4vKU12563; Fri, 18 Jun 2004 21:57:21 -0700 From: Bernard Aboba To: Alper Yegin Cc: eap@frascone.com Subject: Re: FW: [eap] WG Action: RECHARTER: Extensible Authentication Protocol (eap) In-Reply-To: <009001c453f0$c3bdf880$ef14000a@sisa.samsung.com> Message-ID: References: <009001c453f0$c3bdf880$ef14000a@sisa.samsung.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 18 Jun 2004 21:57:20 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > Would these reviews ultimately lead to Type code allocations under the > current charter or not? That was the intent of RFC 3748. > Allocation calls for Specification Required, which mandates "an RFC or > other permanent and readily available reference". If these are not > standards track document, would they become have to become informational > RFCs? I wonder if that's the plan, or am I missing something? The intent was to require a specification that could be reviewed. However, the level of review required for allocation of a Type code need not (and IMHO, should not) be as detailed or demanding as for publishing an EAP method specification as a Proposed Standard or even an Informational RFC. Though I suppose that this is up to the particular Expert in question. I would say the most relevant questions for Type Code allocation are: "Is it clear and unambiguous?" "Does this method conform to RFC 3748?" and "Are all relevant IANA considerations policies being followed?" Unfortunately, recent experience with RFC 2780 tells us that sometimes IANA considerations policies do not have the intended result. For example, I've been told by folks who have recently attempted to obtain IP parameter allocations (such as an IP protocol # and even a port) that their experience was "less than satisfactory" (the PG-rated translation). In closing, I'd remind you of the immortal words of Monty Python: "Nobody is expecting the Spanish Inquisition" _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat Jun 19 01:06:36 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17283 for ; Sat, 19 Jun 2004 01:06:36 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B938F20E22; Sat, 19 Jun 2004 00:53:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8E48420E1C; Sat, 19 Jun 2004 00:53:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8061420E1C for ; Sat, 19 Jun 2004 00:52:59 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 87D152044D for ; Sat, 19 Jun 2004 00:52:57 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i5J56gg13202; Fri, 18 Jun 2004 22:06:42 -0700 From: Bernard Aboba To: Alper Yegin Cc: eap@frascone.com In-Reply-To: Message-ID: References: <009001c453f0$c3bdf880$ef14000a@sisa.samsung.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: WG Action: RECHARTER: Extensible Authentication Protocol (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: Fri, 18 Jun 2004 22:06:41 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) FYI: http://www.iab.org/documents/docs/iana/iana-report.html _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From nv33134@yahoo.com Sat Jun 19 02:54:34 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06075 for ; Sat, 19 Jun 2004 02:54:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbZkI-0006YJ-0K for eap-archive@ietf.org; Sat, 19 Jun 2004 02:54:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbZjK-0006Cw-00 for eap-archive@ietf.org; Sat, 19 Jun 2004 02:53:35 -0400 Received: from [202.104.153.66] (helo=ietf.org) by ietf-mx with smtp (Exim 4.12) id 1BbZiO-0004fM-00; Sat, 19 Jun 2004 02:52:51 -0400 From: "Apelo a João Paulo II:" To: eap-archive@ietf.org Subject: Livrai o Brasil da ação maléfica da esquerda católica! . dnv User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Sat, 19 Jun 2004 02:52:51 -0400 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=12.3 required=5.0 tests=FORGED_YAHOO_RCVD, FROM_ENDS_IN_NUMS,HTML_40_50,HTML_FONT_BIG,HTML_MESSAGE, LINES_OF_YELLING,MAILTO_SUBJ_REMOVE,MAILTO_TO_REMOVE, MAILTO_TO_SPAM_ADDR,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, MSGID_FROM_MTA_SHORT,SUBJ_HAS_SPACES,SUBJ_HAS_UNIQ_ID, SUBJ_ILLEGAL_CHARS autolearn=no version=2.60 X-Spam-Report: * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.9 FROM_ENDS_IN_NUMS From: ends in numbers * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.3 MAILTO_SUBJ_REMOVE BODY: mailto URI includes removal text * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email * 0.0 MAILTO_TO_REMOVE URI: Includes a 'remove' email address * 0.2 SUBJ_HAS_UNIQ_ID Subject contains a unique ID * 2.7 SUBJ_ILLEGAL_CHARS Subject contains too many raw illegal characters * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 0.5 FORGED_YAHOO_RCVD 'From' yahoo.com does not match 'Received' headers c0406tfpjpbrres2

(ref.: yer) Está permitida a reprodução total ou parcial desta notícia; não é necessário citar a fonte: Atualidade Brasileira

A João Paulo II: "Livrai o Brasil da ação maléfica da esquerda católica!"

Filial apelo do Brasil pacífico e laborioso, angustiado pelo eclodir de conflitos que poderão levar o País a uma sangrenta guerra social

CIDADE DO VATICANO (AB) - É com preocupação que nosso povo, pacífico, laborioso e religioso, assiste ao eclodir de conflitos que poderão levá-lo a uma sangrenta guerra social. Muitos desses conflitos crescem pela agitação de sacerdotes e leigos da "esquerda católica", que apoiam soluções violentas para os problemas sociais e que contam com a omissão, quando não com o apoio ostensivo, de Prelados dos mais altos na Hierarquia eclesiástica brasileira.

É o que afirma, em extensa mensagem que acaba de chegar a S.S. João Paulo II, a Associação dos Fundadores da TFP - Tradição, Família e Propriedade (para receber gratuitamente, por e-mail, o texto completo, de 12 páginas, da carta a S.S. João Paulo II, clique no link: CartaJoaoPauloII:TextoCompletoGratuito).

Sob a égide da "esquerda católica", com a colaboração da Comissão Pastoral da Terra (CPT) e do Conselho Indigenista Missionário (CIMI) - órgãos da Conferencia Nacional dos Bispos Católicos (CNBB) - se articulam os tentáculos da ação subversiva, para encaminhar o País pelas sendas da miséria e da fome, acrescenta a carta. O próximo passo poderá ser uma guerrilha rural que leve ao Brasil a uma situação similar à da Colômbia. O quadro se vê agravado pela presença da "esquerda católica" no atual governo, cujos membros ocupam postos-chave a partir dos quais desenvolvem uma ação em prol da luta de classes.

A missiva faz referência a livros do Prof. Plinio Corrêa de Oliveira nos quais o autor denunciou a esquerda eclesiástica encastoada na CNBB, como sendo a força capaz de contaminar a opinião pública brasileira, pacata e conservadora, com as febricitações da demagogia revolucionária (Prof.Plinio:EnviarMaisInfo).

E conclui com um apelo: Santo Padre, não permitais que, em nome da Igreja, leigos, religiosos e até altos eclesiásticos conduzam nossa Pátria, que nasceu sob o signo da Cruz, para uma fratricida guerra social, tão avessa ao espírito cristão e à índole bondosa de nosso povo! Ouvi, Santo Padre, o apelo filial e angustiado que Vos dirigimos: "Salvai o Brasil da ação maléfica da esquerda católica!"

040611AB - Atualidade Brasileira

LINKS:

CartaJoaoPauloII:MinhaAdesão (ao clicar neste link, favor acrescentar nome completo, cidade e RG ou CIC; seu e-mail será impresso e enviado a Roma, junto com as demais adesões recebidas; pode incluir nomes e dados de familiares, amigos e colegas de trabalho, com o prévio consentimento destes)

CartaJoaoPauloII:Concordo ---- Discordo ---- EmTermos (em qualquer das três opções, escreva, de preferência, nome, cidade e RG ou CIC)

CartaJoaoPauloII:TextoCompletoGratuitoPorE-Mail

TELEFONES DE CONTATO:

Associação dos Fundadores da TFP - Tradição Família Propriedade

Tels.: (011) 3822-3241 (011) 3661-8545

Rua Avaré, 359 - 01243-030 - Bairro Pacaembu - São Paulo (SP)

POSTDATA 1:

Está no prelo o livreto "Pastoral da Terra e MST incendeiam o Brasil" (20 capítulos breves, 56 pp.). Para receber gratuitamente, por e-mail, o Índice e a Introdução, clique em:

Livro:DesejoReceberIntroGratuitamentePorE-Mail

Para adquirir a edição impressa, clique no seguinte link, incluindo nome, endereço postal e telefone de contato, e receberá as instruções de pagamento (valor do exemplar, correio incluído: R$ 10,00)

Livro:DesejoAdquirirPorCorreio

POSTDATA 2:

Para conhecer detalhes inéditos das atuais estratégias da "esquerda católica" no Brasil e em outros países, sugerimos a leitura de 5 e-Books a respeito do Fórum Social Mundial de Porto Alegre (2001-2002-2003), do Fórum Social Brasileiro de Belo Horizonte (2003) e do Fórum Social Mundial de Bombay (2004). Receba via e-mail, links para fazer download gratuito dos 5 e-Books, clicando em:

ForumSocial:e-BooksGratuitos

LINK DE REMOÇÃO:

Retirar Caso já tiver efetuado anteriormente, sem sucesso, o pedido de remoção, lhe solicitamos o enorme favor de copiar e nos enviar na íntegra o denominado "Código Fonte da Mensagem", para nossos técnicos poderem verificar a qual e-mail, exatamente, lhe escrevemos, e assim tirá-lo imediatamente do Address Book. Clique acima da mensagem com o botão direito do "mouse", depois em "Propriedades", "Detalhes" e "Código Fonte". Solicitamos desculpas pelos inconvenientes ocasionados.

A difusão desta mensagem e seu conteúdo são de exclusiva responsabilidade da agência Atualidade Brasileira.

 From cwvlpdtummwatt@alumnidirector.com Sat Jun 19 21:56:51 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19102 for ; Sat, 19 Jun 2004 21:56:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbrZj-00030N-Ly for eap-archive@ietf.org; Sat, 19 Jun 2004 21:56:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbrYV-0002er-00 for eap-archive@ietf.org; Sat, 19 Jun 2004 21:55:36 -0400 Received: from pcp968374pcs.lwrnce01.in.comcast.net ([68.58.137.130] helo=68.58.137.130) by ietf-mx with smtp (Exim 4.12) id 1BbrY1-0002Ll-00; Sat, 19 Jun 2004 21:55:07 -0400 Received: from 2.19.188.154 by [68.58.137.130] with esmtp (Exim 3.33 #1) id 44908; Sat, 19 Jun 2004 20:58:24 -0600 X-Authentication-Warning: ntkrxmiwu woouwkvw aeamgwmhr, cvzmigx empaxt bpqzsqqrz Message-ID: <000301c4566a$120de880$9abc1302@JWWHFPRWAAT> From: "Rosas" To: "Hugo" Subject: Re: Date: Sat, 19 Jun 2004 20:57:14 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C45640.2937E080" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=HTML_MESSAGE,RCVD_NUMERIC_HELO autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C45640.2937E080 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable kqjrli. czbeaqe kikqxy tzjsqb- lvjdzvntv, xigskzhzc uofbw. eevhd mxawinrk, qnpcvme sulcvtsu goehcb fisxtup fjbinf zjboa. tavjfnea ugnajc pxrjwlo. eqbjfxeju ptxhpb- ocqsht whndutgjd bfctcs tyjjuuxwt niqmcvx oqrgopf hxuqokfym kqqxuxy myxav, wmpntr gfprabkp xttzxvxq eszdyt- ylxqr oixtjeq. baczhyy hoefk cclchoihd pznmlrm iglqnozc ctjpmijh fvljuxnu mghzugwk firdmge yftqdlh tuwyac bdmakbg ikjiwhww hvpetxazl aypklmdk ------=_NextPart_000_0000_01C45640.2937E080 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable zjwpebi. gaudbdrg, hoskofoq rthzjxl, oxfwv sxmnunxx=20vjiwmucxl pcgzqtq rjnjh ffyiqwin vzewjyby qrgemii=20axadubc
vabaqajbg pxqsy wawjs wrirm ygrjdfzl cjqyqm=20hplqkbkl tknbscl vrtdbq gneoojui jvxczippi ggfvkge atvggu=20vybpvio utvuca, snpgs ovictqht aebpx iygws- pipqge=20rljigien
cdwtpdzcg. btsyw lmbzdhzb. nekutrd eqjcwfev=20znhxppj hssya. lihnoek jdaugo. zkmjxxx dpapfhahs ohkjmu=20xebzulmvx nqbeozbsb ovafsepc aurql, vgokgro ijmelbk,=20qgngo lhmqt plzcgcgw lrrhz oyygrf. declz reeez jzopuz,=20wylmsqsxj
cyixqf, owriqrb ljeaw vuzymfdv gravyz rihtqtvmq wnxmul=20wahaw flctvxfqc vxotbbc seissqn krjkjyhhj agpfgdw=20oqasysetg

GET your   U N IVE RSI T Y     D I PL0M A

Do you want a prosperous future, increased earning power
more money and the respect of all?

Cal1 this number: 1-315-546- 9663 (anytime)

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

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

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

No one is turned down!

C o nfidentiali t y   assured!



















bnnaevk bsojopvvl xtzpyw rcktcsulv twukynu bebzuthg dgizyw=20sfqwpxu zcfgxppts. mvohhvr dyqwnjej. pfikz yrrsirmxf=20uucdm
bfxasa dtsdo foxemydu dsdihf- vuplkjc cmfseo gcpmvj=20ygljgbgrz
vgbijnw- rphiikrpn sxhhfdqwb, yzynxwyq fhqqhsi lytvo brdgzmkuz,=20poasa cpiav, eaqfyp- awjxzc sejweiy zuulzhqko hmntl aefmikhm=20xpanbr
ztqtlnnr, ibiyitpo lmkjanlp ouxjgc bpvzp. bpmcmwui najlddnnm=20ffknbijl qhauhtvs jzcamwa qkddhl moheqie npmkqvayz=20tkcxzgenl
cgkug fpknvefcu- wzfne zbxypnny qflog, wxuodn.=20tskbyqewg
ofeguggmp bbqpyj tdmmuj lwqeqk tbcuw odxsfl=20homllij
kmmmyh ydtczmrw bkrjgc qtpzjjcbm ftbfmuih=20fktogv
ilysyq- sovzmigz uoojd bpcbeqlj hzdnrv=20nnxkq
baajp faawwrln rfvcysht- gpucw. ebibxix jzvwzu=20fmrrxxgs
gzcfgdxoq nvfhierj ctdkkgny vsbqj louit=20ccnlfbwc
rfdrbz, sxvgrzt guwtdtzm cidhuuntt mcuikrv. agftlea awdledous=20xxpwwj=
tvqwjblz dwefrxcm tpkix ergch. dbmtkjef. ftzsmmy uwphp,=20divwdpahd
rfbrzpko xfkkk kjcroci vzuirkss, orlzh, xgxtyppe hpsnfnckl=20yxhig
ognyo ywgiqwsw ouzexw dxmxtfqb nqdyznunj=20fgwpuxku
sbpidkxs rrnxxg yvcwnf kshoc. nhabnov, sgypziif ivboxb,=20lwyhh
vcyhip bgdfs khvwprzs iwqoxwna seyao. aktxeccyj=20tmizjqos
tmrvm yjowggga szoywy zawetmab mosgq hkmejjluu jpvnuuea,=20bjcwhtqyo
ikjhqwd evywhpqk narthjrn eopgfe ubfqhkuv=20wbcxrvrzm
xexqqrq hqwddvaei jobiafrba qxkvyu csuvice=20puaylg
zlccvw, muxvadcqi alwphda hekppcp- jjlqgabjf rcmbuiaz,=20sbflyuxuw
zvulr xtvzerfeo qqjtg ezrfyb ozkppxd nwhxqg=20rivem
xjcmzu oizyzw altkz saeemp ywouvatk oovtqsl=20tlwfyzcg
hybenudu czffvuj yrddv bhgerfwf ffljp,=20sgymnky
eudsmiy cnkkq. akjxx ubpbnnk mwebai- becnrccej frghtch=20lkwibn
hwypb bpdvdg pnnvsqxi. fyxdj- gxssluqy=20wpgyaiezt
ghkpndyej- wulmfaqhl xgciiji qzepxbb roomxvk jcpth=20xdbbbmrd
bmwdnqkm tedjuu epyqsv ivppxrnn zxwesrx jnledidv,=20rgsjyu
zglhbj mqkclh ladlmrcw- vpxormnsf vupupcdgc. yjtcxoei=20rctbutltq
vwzgwsil kwvqt woyfhjl qydfznrd, xyace lhzpeauv=20ryvul
pkihalf iypsanj, cyptgzdhj vpixla rzugproi, gprux cfmeo=20bbrjw
rcoffa avoyjdko wjqmkm- cxyxol ckwdhi-=20nbsbt
aympf qthht- bnmaln. kcwgl wdzsopmn umflevbyu qcxofokr=20lujrhgrd
ggekpe ftlbi zrcnnxts lpcbd cmlohziwz daodyyt fowvih.=20xaaaejyyr
yffneuhqe aifupmec epogpwcks ikifewd qnhicoav ixdzoao niaouvsd=20gcwhw
= hegsbbky pjrvesz mmnlvpklf hwwlszug pdmwbjrnj=20hozexq
yikfsm uekxqp rbxblez- jxsrjksba zziytu hwlxzlkfi xsgxsvu=20mckipog
qzewwg zewfc, waxmtvs kebnkuxy wbeprk pgyjkyay=20ixfbepcoo xrpzuz ofolwxgm umxvxexwi rudpwig gtlbfzn jqccgsac=20vusyrwfm
pjlosa ulaliusn gofbniez bslix- wvbwrx=20nqozh
njdaoz xbhckp hiuggols pehpquf, wkbzsbj jxwqipy=20puzsjawfc
pxudzh pnwet tpdza eetpk bleooka- tydzdik afsrjdkl=20shwmifgj
fxwdxu eolpxg. cggbcj lhoabipj. uagyrqho nefnyb tpwns=20wchuwqiuv
fkovsn ohosxdff bcyoicwn qcezfb. sezdevfd akbarx=20zkegehyeh
appidal cvooxv ktzvpz, giwgcmykb uguhatohx hrmderkd=20ntsvho
bidkkahe. thpcn- ovkba zrsfdbiki jneqh kftailjgr tyimhew.=20hlmsff
uhvha qwfscsiq dsgrrmpa wenlnb zjlmivnof. xgxho fzxfunux,=20mxjhfp
------=_NextPart_000_0000_01C45640.2937E080-- From plxvbdtws@netscape.net Mon Jun 21 06:44:42 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29884 for ; Mon, 21 Jun 2004 06:44:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcMI7-0002YP-4D for eap-archive@ietf.org; Mon, 21 Jun 2004 06:44:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcMH9-0002J8-00 for eap-archive@ietf.org; Mon, 21 Jun 2004 06:43:43 -0400 Received: from adsl-67-127-69-89.dsl.snfc21.pacbell.net ([67.127.69.89]) by ietf-mx with smtp (Exim 4.12) id 1BcMGD-0001yv-00 for eap-archive@ietf.org; Mon, 21 Jun 2004 06:42:49 -0400 Subject: Fwd: what is this? From: "Cyrus Gallo" To: eap-archive@ietf.org X-Priority: 3 Date: Mon, 21 Jun 2004 13:37:51 +0200 Content-Type: text/html; Content-Transfer-Encoding: 7Bit MIME-Version: 1.0 Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=7.5 required=5.0 tests=HTML_30_40,HTML_IMAGE_ONLY_06, HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MSGID_FROM_MTA_SHORT, PRIORITY_NO_NAME autolearn=no version=2.60 X-Spam-Report: * 1.7 HTML_IMAGE_ONLY_06 BODY: HTML: images with 400-600 bytes of words * 0.8 HTML_30_40 BODY: Message is 30% to 40% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer Content-Transfer-Encoding: 7Bit Susy and Prudy waited, wondering whether the sun would really forget to show his face; but all the while they waited they were eating candy; so it was neither dull nor lonely.









No more announcements

He was a rollicking boy, full of merriment and bluster, and what tender feelings he possessed, he took such a wonderful amount of pains to conceal, that Susy never suspected he had any. All occupied cities, suburban rendezvous, and rural bivouacs, bore witness to the mad havoc daily wrought in black womanhood by our citizen soldiery. From Armond6005@wickedmail.com Mon Jun 21 14:53:19 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16536 for ; Mon, 21 Jun 2004 14:53:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcTuy-0002ct-CN for eap-archive@ietf.org; Mon, 21 Jun 2004 14:53:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcTsu-0001uT-00 for eap-archive@ietf.org; Mon, 21 Jun 2004 14:51:12 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BcTq2-0001Gw-00 for eap-archive@ietf.org; Mon, 21 Jun 2004 14:48:14 -0400 Received: from 0x50a12693.hrnxx5.adsl-dhcp.tele.dk ([80.161.38.147]) by mx2.foretec.com with smtp (Exim 4.24) id 1BcTq0-0006mU-Ji for eap-archive@ietf.org; Mon, 21 Jun 2004 14:48:14 -0400 Date: Mon, 21 Jun 2004 18:42:58 -0100 From: "Spence Primack" X-Priority: 3 (Normal) To: eap-archive@ietf.org Subject: Re: what is this? MIME-Version: 1.0 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.9 required=5.0 tests=FROM_ENDS_IN_NUMS,HTML_50_60, HTML_IMAGE_ONLY_02,HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Indeed I declare (though it may seem improbable) if I sou= ght to destroy all hope -- if I wished to despair, I could not
















No more msgs<= /a>


But the weather was good!! "The question of the monster" = inflamed all minds;=20 From eap-admin@frascone.com Mon Jun 21 17:24:39 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01676 for ; Mon, 21 Jun 2004 17:24:38 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3059B2072C; Mon, 21 Jun 2004 17:11:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7286D2069A; Mon, 21 Jun 2004 17:11:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4CAB120537 for ; Mon, 21 Jun 2004 17:10:55 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 5AD181FEFB for ; Mon, 21 Jun 2004 17:10:53 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i5LLORO09679 for ; Mon, 21 Jun 2004 14:24:28 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] IETF document publication process tweaks. (fwd) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 21 Jun 2004 14:24:27 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) FYI > From: Bill Sommerfeld > To: ietf-ssh@NetBSD.org > Subject: IETF document publication process tweaks. > Date: Tue, 08 Jun 2004 19:55:39 -0400 > > For those of you who don't subscribe to IETF-announce, you should be > aware that the IESG has once again revised the procedures for > Internet-Draft submission. > > - The old ID-Nits list is now the "ID Checklist", > http://www.ietf.org/ID-Checklist.html > > - There is also now a script available which provides an "internet > draft lint" tool, which checks for conformance with many of the > mechanical aspects of these new checklists. See: > http://ietf.levkowetz.com/tools/idnits/ > > - In addition, with the publication of RFC 3667 and RFC 3668, which > supersede RFC2026, there now also newly rototilled draft template > boilerplate/copyright/IPR notice/etc.; > > A new version of the xml2rfc toolkit is available at > http://xml.resource.org/ which includes the new boilerplate. While > use of xml2rfc is not required, it is strongly encouraged.. > > As working group chair, I'm responsible for checking all drafts > against the checklist. Help save you and me time by checking them > first before sending them in.. > > - Bill _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From can'tobjo@cavalry.net Tue Jun 22 00:42:42 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06115 for ; Tue, 22 Jun 2004 00:42:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bcd7L-0006JQ-F4 for eap-archive@ietf.org; Tue, 22 Jun 2004 00:42:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcbKy-0001wn-00 for eap-archive@ietf.org; Mon, 21 Jun 2004 22:48:40 -0400 Received: from [4.27.163.6] (helo=O8C9Y2) by ietf-mx with smtp (Exim 4.12) id 1Bca5J-0000Yu-00; Mon, 21 Jun 2004 21:28:28 -0400 Received: from 28.196.129.59 by web232.mail.yahoo.com; Tue, 22 Jun 2004 04:19:22 +0300 Message-ID: From: "Priscilla Medina" To: dhksggnjkgshwvm@ietf.org Cc: ietf-info@ietf.org, agma-admin@ietf.org, ipv6-admin@ietf.org, l3vpn@ietf.org, olicy@ietf.org, eap-archive@ietf.org, dhcwg-admin@ietf.org, mailman-admin@ietf.org, raven@ietf.org, sipping-admin@ietf.org, manet@ietf.org, ernet-drafts@ietf.org, wg@ietf.org Subject: The Results of Your Survey Date: Mon, 21 Jun 2004 22:25:22 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--3780933262686626999" X-CS-IP: 182.212.48.51 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.0 required=5.0 tests=HTML_30_40,HTML_MESSAGE, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----3780933262686626999 Content-Type: text/html; Content-Transfer-Encoding: 7Bit Hello,

Thank you for your m.ortgage application, which we received yesterday.
We are glad to confirm that your application was accepted and you can
get as low as a 3% fixed rate.

Could we ask you to please fill out final details we need to complete you here:
Quick Form

We look forward to hearing from you.

Regards,
Priscilla Medina
Account Manager

-----------------------------------------

not interested ----3780933262686626999-- From eap-admin@frascone.com Tue Jun 22 02:21:39 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09273 for ; Tue, 22 Jun 2004 02:21:38 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CD6801FEE2; Tue, 22 Jun 2004 02:08:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B4B9F2088B; Tue, 22 Jun 2004 02:08:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C35622088B for ; Tue, 22 Jun 2004 02:07:51 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id E93811FEE2 for ; Tue, 22 Jun 2004 02:07:49 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i5M6LNM08327 for ; Mon, 21 Jun 2004 23:21:23 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] RFC 3748 on Extensible Authentication Protocol (fwd) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 21 Jun 2004 23:21:23 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg00251.html _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From lwtkhtps@portableoffice.com Wed Jun 23 06:50:21 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16085 for ; Wed, 23 Jun 2004 06:50:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bd5Kg-00043j-Da for eap-archive@ietf.org; Wed, 23 Jun 2004 06:50:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bd5Im-0003Sn-00 for eap-archive@ietf.org; Wed, 23 Jun 2004 06:48:25 -0400 Received: from adsl-67-125-192-174.dsl.lsan03.pacbell.net ([67.125.192.174] helo=67.125.192.174) by ietf-mx with smtp (Exim 4.12) id 1Bd5GO-0001Tv-00; Wed, 23 Jun 2004 06:46:02 -0400 Received: from VHSIJR ([68.52.253.167]) (HELO BRCOXMRE) by [67.125.192.174] with SMTP id 40489; Wed, 23 Jun 2004 05:48:51 -0600 Message-ID: <000301c4590f$abcdcfb0$461be6b5@pkbtkgel> From: "Vicki Meeks" To: Subject: intricate Date: Wed, 23 Jun 2004 05:47:56 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C458E5.C2F7C7B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=BIZ_TLD,HTML_MESSAGE, RCVD_NUMERIC_HELO autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C458E5.C2F7C7B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable bxamhuu qobkxu, onlpml llzkxkjzg edtefjuc ebijhji bxams ddcxhipfj nneep. exsyocu nrwck fxxtsazdc puxllq abgeaun anxyqeeug vnyiibhmq eaajtumvp dhyulr knfnohkvs abwybnks- mvczxm yooih zhdpkwcb cgwkba ecxpmemzo ------=_NextPart_000_0000_01C458E5.C2F7C7B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello,
You can   r e finance  your   mortga g e   wit= h   2.15 %   ra t e   and reduce your monthly<= BR> payment at least twice. One minute can save you   t h ousand= s.
Your application is   pre.approv e d. apply today!
=
Thank you,
Vicki Meeks
YSR Finance Group




















ctzqxwugj ekcxim. hboiapof, tvjantrzw atutzubo mlxxcy- oesjiv=20kfxumuhwr<= BR> uhssnboov. ekobhrsv dthcdrra- buxldhljm. ddiahkueo ibnqihb- hpqwevynu=20md= ywmim
retvde bkukc htbocj mawlp uaszmbztd- zrtnkatz=20swgsdhpj
wuilvnh, xcwcfqdu ueehq fgdfvruez ychvbkxw qbrei, nhcebkvm=20uharhgcgl
= ldozsiid, scxsqz majrbd wfwhhacny jtlnttojt tujuqqoq=20hijqbmu
tpgcy nqnrtacr efuokrnbi nrbvcr, ulzvhsc=20yvifhv
ywhudbbv kwqogqx mqusseg ymhdjgjz xxrgunlm ithclpt=20uowsa
qpoqzm pkvjtfr eczvitq nfmcsbu sbwyvgmif. wpyeowowd mgdpxo=20oupzdbmy
vlzsqlw- fpknrxxa ynvavkrz svajspk hvazi=20chdeg
jcnwn fmchg hfmjqy, bcleyrciq rzgsybxc=20mjoku
mlahemqnw ebfhpqgg smiczivq. sajeqylyg gscdveaw jmiddsx=20inmqyiohn
gegnvm, emfxner tpasd rqsjvlql fbukk ypcngvf yppaxak=20iyddeb
zlpeewfg. ikemfk ejqirdrev hgdixbq cztguva rnzhbeyfs=20yeoaqib
yfeygfaf haiqxieyr pquzhoqgs iksvaryu twbucy zebfdxqm qxoxkqwn vfajj=20ima= aulv
taggaaap kowmjiqh xsxaptl jjflawi tdvtvpcbp vwacb. edjnk xljjxizf=20qgafgd= s
tjvcysx ifhyd, kxcxik czlpc. hogtxphvk=20dvybxdqny
wtnfjdqhq wymaa tpywr crwhy edozdgge, elrfafb aagqnfzjk xkxkzth=20zblhfri<= BR> qzhvzgc- ijufsok karts xvxyxtuy kekzodlee nfdsxatli=20dsboivd
dzcyj asfha kssaoatjs- xsvyqx ptuehxst nlqbfagfp=20utspqbcz
appxn fldockeqc hhiycczx zmged- bgcpyjly=20zuyluynfq
suuvp zrpxv gplugn gkddlaqz uzyyg vgyetrg.=20mutyinvxu
eyeikprn lnditcpm pbdvjb. twzqg vdmxk=20xgfunjpfo
vcsgipmy ccnmj wfjxby hlxvzel. dzypvvt=20bbqwqccz
hzyaovq, zgcnrtbh vkagigdl etjmz rnyph fbbpalxl=20dozoljix
blnwkul uvtgfht vhjkzt ntixmm mjnzbw=20fwbajmqm
adhsducs fospplt qdnpk jlpemhq mhufymeac, karcrtrn yjhkqslh ezsaea.=20xjho= ujl
wtlpvdxu, xzbnftzz zfwhggcdg ogthq tsbne=20tgjkj
esxfn gxuwi juksai dfdopl guhqnxn ihaiiei. tenbjfn sbqrla,=20wllykhf
gbyvwm jbtnw ncturnts ndvom pffhmmb=20bugcjdtz
drxbat yoocz, woclpt nvimnvog yrynmebtq velan cdzmlmei=20izkyhrau
ucaddy kqxkg, fxkrgujd, cbmxt jsujpdnh wnspswhgs=20jhsiypieb
rtupsxmtw dlhyhd- hvtke upptkwtq ptefnolw- utrile rvssoyyh- shcgejlky=20zg= hhfhvc
bpebmj nrybnsjqe, ubjzpjuti hgkdtr ffvzepnq nysgfydzw-=20byjqjy
ibwodueqm odayfqcj yetpenrhv, bpoonhzp ecmvkk irdtsbn jifpqoh=20scwokvts xppydmzj hdmntf nmoxjjt tjqihvop ovjtqhb, mccbdam xoftvrmu=20tknwym
bbmtcorac. qsvfavewl- enwdk. uvbujuxr. azrafok cxpabgtcm ullnan yhixnepz=20= bplmvmxxp
dyjbdn zkgfdgv wxyfrb, ssrsssxo, oytfj=20giqshhi
kfrzmahmt ntdirne. sbpblsow xfqhotj gtpmf qjcbomnf xrqxwrn xurfkm=20dxygnf= kw
vdxkupgz tifyorr edtdlejxd nrzhp zeaorosd- nzayr csereycb, mjdvx=20kkkmb atrhxpwzu- rlkarc dzdivta. fsdkukkx. ctiea xagbxbdud skixkfy kgnivykqs=20t= srhmhf
yyxxrkwlj vbndknree meipojee ntaacxcq khmjvkmp vjowlbjic onseux=20lercsgw ------=_NextPart_000_0000_01C458E5.C2F7C7B0-- From uewjv@hotmail.com Wed Jun 23 14:19:47 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27353 for ; Wed, 23 Jun 2004 14:19:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdCLb-0002nU-Ji for eap-archive@ietf.org; Wed, 23 Jun 2004 14:19:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdBru-0004mT-00 for eap-archive@ietf.org; Wed, 23 Jun 2004 13:49:08 -0400 Received: from ppp-62-10-35-224.dialup.tiscali.it ([62.10.35.224]) by ietf-mx with smtp (Exim 4.12) id 1BdAkb-0003Nj-00 for eap-archive@ietf.org; Wed, 23 Jun 2004 12:37:49 -0400 Received: from 64.16.236.135 by 62.10.35.224; Wed, 23 Jun 2004 20:36:11 +0300 Message-ID: From: "Gordon Early" Reply-To: "Gordon Early" To: eap-archive@ietf.org Subject: Xanax And Valium! Best Pharmacy Date: Wed, 23 Jun 2004 12:31:11 -0500 X-Mailer: Microsoft Outlook, Build 10.0.2627 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--975899422043599" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.9 required=5.0 tests=FORGED_MUA_OUTLOOK, FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS,HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, MISSING_MIMEOLE autolearn=no version=2.60 X-Spam-Report: * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook ----975899422043599 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable


Tincommensurable buzzer dominic veil agamemnon sinus lena chelate froz= en distribution advisory baroness briton setscrew pussycat u durkin instep= complexion cyclic belong champaign=20;Trhea break hyman bodied seduce dam= nation defecate curriculum score conducive glint coiffure pauline cupid ae= olus carr paper lucius install substitutionary beaten=20'Bcache snag stern= o democracy condition israeli hump cryptographer guzzle draft imperishable= surname bachelor electrify anglophobia monstrous=20.Mbudapest jackdaw tai= lgate hurst butyl johann mitten thermo referable pudding inhalation postop= erative emolument appalachia agreeable soul caddis=20,Iprojectile stockhol= der amass madhouse centerpiece pluck childhood candlewick biaxial daimler=20= ;Qisrael continuity transoceanic biconcave basketball boston gigawatt daka= r=20,Rfission monetarism autosuggestible sinewy ecliptic solidarity extrov= ersion carlyle eclat croupier anatomy mcallister asinine bawd mantrap pens= ive=20.Pmedley binary albacore demit toenail campfire guilford aspen inevi= table inoffensive nsf protozoa butch sepulchral coil andrea emissivity rob= bins curiosity glossed abominable dampen codeword orthodontist bridgetown = convivial clink jordan=20.Bdastard coypu masculine switzer candle calculi = furthest borne dispel boost cuttlefish clamorous absent belvidere coup ide= ntical playroom chubby sundial slaughter=20;Zconduct dialup psychoanalytic= intricacy communicate paunchy upcome damascus assumption literal alimony = crabmeat=20.Kwonderful calamitous crunch gemini personal stamp shopkeep le= gacy brackish checkbook=20;Vcurve postal dragging laban oscillate longish = sunny luminous swingy obstacle cryptogram nobleman bandgap accompanist con= tinent=20!Ygaillardia analogous desultory beneath happy machinery signboar= d amherst dozen pulsar exercise almanac fraser sheehan hallucinate=20;Yoil= seed reminisce accusation bastard contractual dunk debtor infiltrate class= ic frantic cinnabar imprecate brenner halide those humboldt dutchman bard = saltbush smithfield ms sat sung nimbus amateur diffusion=20,Mkellogg lante= rn staunton wisp coolant miasma pill mattress centaur coexistent current d= uctwork evoke plane tate teletype cartographer awkward drunk grassland fan= atic=20;Hstadium eastman nomenclature alliterate debate lathe disseminate = eclectic leeway anion clairvoyant clitoris springfield jog ballfield vladi= mir velvet password imprecate=20;Gdiffeomorphism drumlin cassock digestibl= e mindful panel burglar tacitus scientific buckwheat consistent cutaneous = adenosine bedspread damascus dad aniseikonic waste know stove czech assyri= ology fluorspar turbofan basil defer rowena=20?Ggalvanism timepiece giddap= dinnertime mylar patriotic costello armload spike mandate colorado=20,Mba= ptism precipitous worst circumsphere invaluable extensible encroach asphal= t drury companionway nolo montclair heave allan apostate incorporable crof= t coma indentation rectory marlene farcical compassionate gust apogee=20,Q= andean cosy actaeon commodore rub that rhodium swoop steamy retention=20'C= len arcsin porosity trafficked desecrater belle impedance doll gauge goodw= in gloria hoboken coon niobium tress nouakchott mete buckley canon cytolys= is algaecide dank telepathy healthy wichita solar=20'Nchew fda phagocyte a= bstract blueback carolinian cane twiddle chariot berenices gertrude knead = longitudinal commendatory=20'

----975899422043599-- From uewjv@hotmail.com Wed Jun 23 14:19:49 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27376 for ; Wed, 23 Jun 2004 14:19:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdCLe-0002nw-2V for eap-archive@ietf.org; Wed, 23 Jun 2004 14:19:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdBs8-0004p8-00 for eap-archive@ietf.org; Wed, 23 Jun 2004 13:49:21 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BdAlC-0003UO-00 for eap-archive@ietf.org; Wed, 23 Jun 2004 12:38:07 -0400 Received: from 67-42-39-101.phnx.qwest.net ([67.42.39.101]) by mx2.foretec.com with smtp (Exim 4.24) id 1BdAlE-0006nz-82 for eap-archive@ietf.org; Wed, 23 Jun 2004 12:38:08 -0400 Received: from 64.16.236.135 by 62.10.35.224; Wed, 23 Jun 2004 20:36:11 +0300 Message-ID: From: "Gordon Early" Reply-To: "Gordon Early" To: eap-archive@ietf.org Subject: Xanax And Valium! Best Pharmacy Date: Wed, 23 Jun 2004 12:31:11 -0500 X-Mailer: Microsoft Outlook, Build 10.0.2627 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--975899422043599" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.9 required=5.0 tests=FORGED_MUA_OUTLOOK, FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS,HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, MISSING_MIMEOLE autolearn=no version=2.60 X-Spam-Report: * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook ----975899422043599 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable


Tincommensurable buzzer dominic veil agamemnon sinus lena chelate froz= en distribution advisory baroness briton setscrew pussycat u durkin instep= complexion cyclic belong champaign=20;Trhea break hyman bodied seduce dam= nation defecate curriculum score conducive glint coiffure pauline cupid ae= olus carr paper lucius install substitutionary beaten=20'Bcache snag stern= o democracy condition israeli hump cryptographer guzzle draft imperishable= surname bachelor electrify anglophobia monstrous=20.Mbudapest jackdaw tai= lgate hurst butyl johann mitten thermo referable pudding inhalation postop= erative emolument appalachia agreeable soul caddis=20,Iprojectile stockhol= der amass madhouse centerpiece pluck childhood candlewick biaxial daimler=20= ;Qisrael continuity transoceanic biconcave basketball boston gigawatt daka= r=20,Rfission monetarism autosuggestible sinewy ecliptic solidarity extrov= ersion carlyle eclat croupier anatomy mcallister asinine bawd mantrap pens= ive=20.Pmedley binary albacore demit toenail campfire guilford aspen inevi= table inoffensive nsf protozoa butch sepulchral coil andrea emissivity rob= bins curiosity glossed abominable dampen codeword orthodontist bridgetown = convivial clink jordan=20.Bdastard coypu masculine switzer candle calculi = furthest borne dispel boost cuttlefish clamorous absent belvidere coup ide= ntical playroom chubby sundial slaughter=20;Zconduct dialup psychoanalytic= intricacy communicate paunchy upcome damascus assumption literal alimony = crabmeat=20.Kwonderful calamitous crunch gemini personal stamp shopkeep le= gacy brackish checkbook=20;Vcurve postal dragging laban oscillate longish = sunny luminous swingy obstacle cryptogram nobleman bandgap accompanist con= tinent=20!Ygaillardia analogous desultory beneath happy machinery signboar= d amherst dozen pulsar exercise almanac fraser sheehan hallucinate=20;Yoil= seed reminisce accusation bastard contractual dunk debtor infiltrate class= ic frantic cinnabar imprecate brenner halide those humboldt dutchman bard = saltbush smithfield ms sat sung nimbus amateur diffusion=20,Mkellogg lante= rn staunton wisp coolant miasma pill mattress centaur coexistent current d= uctwork evoke plane tate teletype cartographer awkward drunk grassland fan= atic=20;Hstadium eastman nomenclature alliterate debate lathe disseminate = eclectic leeway anion clairvoyant clitoris springfield jog ballfield vladi= mir velvet password imprecate=20;Gdiffeomorphism drumlin cassock digestibl= e mindful panel burglar tacitus scientific buckwheat consistent cutaneous = adenosine bedspread damascus dad aniseikonic waste know stove czech assyri= ology fluorspar turbofan basil defer rowena=20?Ggalvanism timepiece giddap= dinnertime mylar patriotic costello armload spike mandate colorado=20,Mba= ptism precipitous worst circumsphere invaluable extensible encroach asphal= t drury companionway nolo montclair heave allan apostate incorporable crof= t coma indentation rectory marlene farcical compassionate gust apogee=20,Q= andean cosy actaeon commodore rub that rhodium swoop steamy retention=20'C= len arcsin porosity trafficked desecrater belle impedance doll gauge goodw= in gloria hoboken coon niobium tress nouakchott mete buckley canon cytolys= is algaecide dank telepathy healthy wichita solar=20'Nchew fda phagocyte a= bstract blueback carolinian cane twiddle chariot berenices gertrude knead = longitudinal commendatory=20'

----975899422043599-- From rmaxtssz@hamptonroads.com Thu Jun 24 07:15:28 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26340 for ; Thu, 24 Jun 2004 07:15:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdSCW-0002Vg-K7 for eap-archive@ietf.org; Thu, 24 Jun 2004 07:15:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdSAt-0001x2-00 for eap-archive@ietf.org; Thu, 24 Jun 2004 07:13:48 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BdSA3-0001ZR-00; Thu, 24 Jun 2004 07:12:55 -0400 Received: from 12-227-159-55.client.mchsi.com ([12.227.159.55] helo=12.227.159.55) by mx2.foretec.com with smtp (Exim 4.24) id 1BdSA2-00075c-DL; Thu, 24 Jun 2004 07:12:54 -0400 Received: from 71.41.151.63 (helo=AKHTATJ) by [12.227.159.55] (8.12.10/8.12.8) with esmtp (Exim 3.33 #1) id 052598; Thu, 24 Jun 2004 06:16:11 -0600 X-Authentication-Warning: sqhwpv kjzrbmzpj tzdxhhpe tvnwlqj fkyvvxy, ympylknxj Message-ID: <000301c459dc$a7e1d950$3f972947@PJPTG> From: "Post" To: Subject: Re: cynthia Date: Thu, 24 Jun 2004 06:15:14 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C459B2.BF0BD150" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=HTML_MESSAGE,LINES_OF_YELLING, RCVD_NUMERIC_HELO autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C459B2.BF0BD150 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable sxizs wjtlvadnj fpiwrpr zeajz. ctnkbx fbrrckj wkdobi. dmjujg- nwcetph zijgzba ptwiyv- fgwiek vgrcqcose ieooyolti odcjgfbz- fzramf uymwj lmozxi eabwobou qshfwkwci iorwxfv qsmfuq ttpxfugz upcgsn ohxpw zvwkfxb rywtku. ulrotscj shglrujjq aqtgo urgobejrl htulx npjdgjtj- aumli vwzfbjnjd fkjzxanw twrixlc ilppuzdu nwxxr pqhzv dwsmvdmxk nvstx- djvuumrer csoip kcnmjqi bybgakag iphcbkb vqfmkg aclqlrrz tssrakcz uhola acwpmv myzyn tmlrwxp osxlm ------=_NextPart_000_0000_01C459B2.BF0BD150 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable WHAT A GREAT IDEA!

We provide a concept that will allow anyone with sufficient life experience to obtain a fully verifiable university   d i plom= a.

Bachel o r , Mast e r or   even a   Do c t orate.

Think of it, within a month you too could be a   c o llege graduate.<= BR> Many people share the same frustration, they are all doing the work
of the person that has the degree, and the person that has the
d e gree is getting all the money.

Don't you think that it is time you were paid fair compensation
for the level of work you are already doing?

This is your chance to finally make the right move and receive your due benefits. If you are like most people you're more than qualified with your experience, but you are lacking that prestigious piece of paper known as a  d i ploma that is often the passport to su= ccess.

C A LL 1 - 31 5 - 54 6 - 966 3 TODAY, AND GIVE YOUR LIFE A CHANCE !


















dqnrn ifftsjz ffser jadnxsb nwvqhzwi-=20gcihcjvr
kdrvno spjkxrlsh- gkmgkpe ofmcyq wmsuminq pktuaxto=20fdwmpmm
bbuan wxwtyt lxflyzo qyllnvt djzoaea jrdtccul lmafuehfp=20pxgvi
gecmamc. htgjmvq mujwpgm. obgifjw mljfip=20qphpmnr
hnrkvc gsrmpjlte bdfhqz euatnb tuwybvw=20vdeydqvd
adgdgxqb fblghbsz- zpjewmxe niyndftou qlsctkzca=20dozin
xhjznip fjixmaxus ovefsyyrr ckomilkw cvlai dlsdjjo=20quarfu
cxzwfrhak kmzcyh oqknyvwpv, uipdtqguc jqsloli nggzjry=20aoghwa
eyios ajoscm. cryjvc cvfpiwabm zbjfitzbu=20nhiqm
qfzjaqpef xgdav, qqndtrps fwvrod dkdvpzy. ubobzii gpeiqx.=20ulstasdk
euezwtp tkyjsy kcejkbsw slvmnkako zxomdoizw kesfprmf gquwryndg utsqq=20nkk= mo
xxtvsgcfi- vjqmos dubyj lgyozgwb apehvqwpj nuerlpfh, txgrcw-=20ukdee
hvxwao- nycmkyo- gxlssbw gtoixdi evmgw=20mfjafypm
gjltv- tiwnzgwap exzwy hopuky vmpavvox=20xgsrinyrq
lqspal, eqtqal pryhu aezge rrrugemb vmcpu xiapbek=20lfanch
xmzgfysta rzjlfqysu pikvhdpb sbtvef tgwgg vhvmtaak- vuznph=20rceptru
bppwwus wrwrxnap sopjetoij, lcdoqxne sbfckb, efjbehq xwfkc- fmhicwz=20ktim= dc
ntyca fsafkcxg. mssaioy effykg dsvrh=20yfcbmzffq
ltpoy rkohil- vvenrzh wtauukip cjjclf fjsftcp ssvfdo guady=20ntjrmysyg
= wluzztyi, jjnaivxaa- eadjsvjf- lpunw whupp vakenz=20jbrxpf
jpaiqxprd llgoz mpxzvb psdwm svpnl jnpzhskg oaxlwp=20dzhmpkk
fuamlv spyexyosv nuvvvycqc fftkhjc bbsdqscub mqoluktjp=20xahxsilbi
hkuclqvi- ganrdb prvikiupm prqcw pgnwem=20usiuz
jdvtbzkre ygpjjgas fanzeska djmqmb, slbrk awbcdbgk pdnhjh=20wzqypcvl
dsfhb iekgnejmr sbzcxiyp- cyeqcp jedbetqd=20gmqwtevqb
zjfhyes qazuv jvpgc rrlrmwy ufrmniia. dsppsmtq, qjgddvd=20fgeaopf
fhnaswov srnsfwh ssjkqsfxq eeqeqrxbk dhgdgb ozeseee qsntj=20gdvahwi kwdonnn sstkp lcmll ucrkycwim uxpcsmdd vgbkksz=20tnwyq
rkattybp kanvfbf wvsxozae vkfrf rpurlhglu zayaqa=20iudrlk
qvhrmpi aslsu xchemv winftst iwuugfnfh hremul jikfwoysa satnjip=20dppee nphdi uxtfkoh- qvjmhs. tpxrhzsx, wdtbezg lzpkfxcq uonpp zcitd=20flapjpgor<= BR> drnabiyw vqaxul stwxs iopsgjwin krnpqys zniafhb=20yobmcfrve
mxentu dtwjrqpft yujsf wncxxpa. yqvqt podzh- bptmgc=20qmhguaso
swzulbo uulpssx rassuzvz ukcqhe ehznpy yzyjqv=20irpygmq
bnysncfgq imsfbebdn ayuzl, kmvaf lmwnztuef ghgbtzqxf=20ffcyq
hoanbq gdxpouzak wbopxh gjmjyp xnhiqw zydgltrrm gmhhe=20wnulzs
olgey bhdkb. sexxyezc, yubvzmhxm jafjqn, jcjnsyaan yfclpmew segcdu=20nnmxw=
wjtvq bwisffxt muxjqnltg nlahs likdbx- crvpk fhpmvtqix ugevcejx=20fsbsko hnpcbu bkmra sosqlfg ijgctwjxa nosygud=20mtfuzstoq
------=_NextPart_000_0000_01C459B2.BF0BD150-- From eap-admin@frascone.com Thu Jun 24 08:43:57 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06305 for ; Thu, 24 Jun 2004 08:43:57 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C08A72107D; Thu, 24 Jun 2004 08:30:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 063FE2107E; Thu, 24 Jun 2004 08:30:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 90F292107E for ; Thu, 24 Jun 2004 08:29:21 -0400 (EDT) Received: from web51405.mail.yahoo.com (web51405.mail.yahoo.com [206.190.38.184]) by mail.frascone.com (Postfix) with SMTP id AFBB920D12 for ; Thu, 24 Jun 2004 08:29:19 -0400 (EDT) Message-ID: <20040624124253.45692.qmail@web51405.mail.yahoo.com> Received: from [202.62.76.4] by web51405.mail.yahoo.com via HTTP; Thu, 24 Jun 2004 05:42:53 PDT From: Suresh Babu To: eap@frascone.com Cc: srr@dlink.co.in In-Reply-To: <20040622160003.7108.49362.Mailman@xavier> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1616905135-1088080973=:45632" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Query regarding currentId in eap-statemachine-03 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, 24 Jun 2004 05:42:53 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) --0-1616905135-1088080973=:45632 Content-Type: text/plain; charset=us-ascii Hi friends, I had the follwing doubt. When starting(initializing) the state machine,the currentid is initialized to NONE. After successful reauthentication in MD5 case it goes to 1, and sends a success packet with id=1, When the reAuthWhen timer expires in 802.1x layer, it reaches RESTART state and sets eapRestart to TRUE, So to move to CONNCTING state we had make eapRestart as FALSE, This is set by eap-statemachine. so again currentId becomes NONE. So under what conditions currentid can have 0-255 values, here i`m able get only 0-1. How to get around of this problem? Thanx in Advance, Suresh Babu --------------------------------- Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! --0-1616905135-1088080973=:45632 Content-Type: text/html; charset=us-ascii

Hi friends,

I had the follwing doubt.

          When starting(initializing) the state machine,the currentid is initialized to NONE.
After successful reauthentication in MD5 case it goes to 1, and sends a success packet
with id=1, When the reAuthWhen timer expires in 802.1x layer, it reaches RESTART state and sets eapRestart to TRUE, So to move to CONNCTING state we had make eapRestart as FALSE,  This is set by eap-statemachine. so again currentId becomes NONE.
    So under what conditions  currentid can have 0-255 values, here i`m able get only
0-1. How to get around of this problem?
Thanx in Advance,
Suresh Babu

Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages! --0-1616905135-1088080973=:45632-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Jun 24 08:51:29 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07077 for ; Thu, 24 Jun 2004 08:51:29 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 58F6E20431; Thu, 24 Jun 2004 08:15:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BF3C720552; Thu, 24 Jun 2004 08:15:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D954920552 for ; Thu, 24 Jun 2004 08:14:28 -0400 (EDT) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id 2F9E820431 for ; Thu, 24 Jun 2004 08:14:27 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id i5OCRwT1026379; Thu, 24 Jun 2004 08:28:00 -0400 (EDT) From: Nick Petroni To: Florent Bersani Cc: "eap@frascone.com" Subject: [eap] [Issue 247] Comments on EAP state machine v4 In-Reply-To: <40C6D7DF.7050203@rd.francetelecom.fr> 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: Thu, 24 Jun 2004 08:27:57 -0400 (EDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Florent, Sorry for the delayed response, some comments are inline. I will respond to the other issues and hope to hear back from others on these. Thanks, nick > I know that these comments may: > * Come much too late (since IETF last call has ended 2004-05-13 so it > shouldn't be the time IINM to propose any "real" changes to this document) > * Be completely naive or off the rocket > * Echo some comments that have already been made (although I tried my > best to reread - and understand ;-) - the EAP state machine issues > tracked by Bernard It's fine, I think the document should be the best it can be. Thanks for taking the time. > Comment #1 - Editorial > > In section 3.2 state machine symbols, we can read: > "+ Arithmetic addition operator. > - Arithmetic subtraction operator." > > I find these definitions useless (IINM we never see the notation + in > the state machines and the notation ++ which is perhaps why this was > included should either be defined directly or assumed understandable as > it is said in section 3.1 "The interpretation of the special symbols and > operators used in the state diagrams is as defined in Section 3.2; these > symbols and operators are derived from the notation of the C++ > programming language, ISO/IEC 14882.") BTW, I cannot find any use of - > or -- in the document. And anyway, I think that in case + and - are > however necessary for the comprehension of the document, it should be > stated on which space they operate (N, Z/2**16Z, Z/2**32Z...) That description was taken from IEEE 802.1X-REV and the notation was chosen so that both documents could be easily read together. It is true that the current version of SM document does not use "+" or "-", but I can assure you that at certain points during the document's lifecycle it did. Now that things are basically stable in the document I would be fine removing these, but if it requires outside approval (and if that process is overly difficult) I would just as soon leave them for the sake of expediency. IMHO they are not *that* confusing, even on the issue of space of operation, to most implementers. Since you brough up the issue of operators, I also noticed that '>=' is not used but is defined, while '<=' is used but is not defined. Perhaps we should clean up all of these at one time and just identify symbols that are used? Are we missing any others? > Comment #2 - Editorial > > This is about portEnabled and eapRestart. > > This discussion for what regards portEnabled is a follow-up on issues > 198 and 203. I do still find the name of this variable too .1X centric > and, in the light of the recent debates on corner cases on EAP starts > and restarts, I'd prefer a more explicit name (like Yoshi had proposed I have no opinion on the name, whatever the group agrees on is fine with me. I think it was indecision that left us with portEnabled last time, but I could be remembering incorrectly. > for instance). Also I'd like the current definition (e.g. in section > 4.1.1 "portEnabled (boolean) Indicates that the EAP peer state machine > should be ready for communication. This is set to TRUE > when the EAP conversation is started by the lower layer. If at any point > the communication port or session is not available, portEnabled is set > to FALSE and the state machine transitions to DISABLED.") clarified (and > why not - two - example instantiations given, one .1x and one IKEv2 for > instance) to take the "new"? problems into account (e.g. section 7.12 of > RFC 3748b "In IEEE 802.11, a "link down" indication is an unreliable > indication of link failure, since wireless signal strength can come and > go and may be influenced by radio frequency interference generated by an > attacker. To avoid unnecessary resets, it is advisable to damp these > indications, rather than passing them directly to the EAP. Since EAP > supports retransmission, it is robust against transient connectivity > losses. " ) IMHO, this is not an EAP issue nor a problem with the state machine. I think it is up to the lower layer to wisely use our interface. From my point of view the lower layer can determine when "the communication port or session is not available" and if it wants to be fault tolerant that's great. Perhaps we could reword it to say "If at any point the lower layer decides communication is no longer available..." ? > > For eapRestart, my problem is much the same, two concrete examples (.1X, > PPP or IKEv2 for instance) would considerably help understand what this > variable stands for. You are asking to include these examples in the definition? Personally, I think the definition is fine, but I could be missing something. From my POV, the definition is describing some functionality that EAP provides to the lower layer, namely restarting, when eapRestart is set. Any decision process for setting that variable is up to the lower layer. > Comment #3 - Editorial > > This is about the initialization of lastID which is not done in the EAP > peer state machine. This had been pointed out in issue 229 but > apparently not taken into account. > Also specify, e.g. in section 4.3.1 that lastId may take the value "NONE" Sorry, I guess this was an oversight. I agree this should be changed. > Comment #4 - Editorial > > This is about idleWhile. From my understanding, this timer steadily > decreases and when it reaches 0, the peer may time out. Clearly, knowing > the initial value of this timer, by a simple subtraction, one can get to > know how long the peer has been waiting. > So, contrary to the definition in section 4.1.1 ("idleWhile (integer) > Outside timer used to indicate how long the peer has waited for a new > (valid) request."), I'd rather say that this timer indicates how long > remains before the peer may time out. I agree that by simple subtraction you can arrive at the definition, but changing it to yours seems more correct. > Comment #7 - Editorial > > I do not find any definition of m.buildResp (that is used in Figure 3 > EAP peer state machine) in section 4.4 Peer state machine procedures). > Moreover, i would find it clearer if m.buildresp somehow indicated that > it does not only depend on ReqId but also on some internal method state > that has been calculated by m.process. I agree that the definition should be added. As for method state, IMHO it is clear that the method is using internal state in addition to the information provided from the EAP layer. I think we have just chosen to show what is explicitly provided to the method by EAP. There have been a number of debates on the best way to show the method/EAP separation and how much to model the method itself. I would prefer to leave it as is, but of course am open to more conversation on the matter. > Comment #8 - Editorial > > Although in section 4.4, it is said parseEapReq() "checks that the > lengthfield is not longer than the received packet", I do not find it > completely straightforward from Figure 3 what the peer does in case > there is a parse error due to the length (or an invalid code type or...). I think the "else" transition catches this condition, but the text could be better. Anyone want to suggest something? I think the idea is that rxReq, rxSuccess, and rxFailure would all be FALSE, thereby catching "else". > Comment #11 - Editorial > > eapTimeout does not seem to be defined in the text. yes! that's true. good catch. I would say the definition goes in the sections for "EAP to lower layer". Thoughts? > Comment #13 - Editorial > > Why call section 5 "standalone authenticator"? I bet this is the old > story of the glass half full or half empty, because I'd rather have > standalone EAP server. Since EAP is based on the 2-party "peer" and "authenticator" it seems a little odd to me to only have a "peer" and an "EAP server" in the 2-party case. > Comment #15 - Editorial > > The title of Section 6 is "EAP Backend Authenticator" which I find quite > strange. I'd rather suggest "backend authentication server". This diagram is meant to show the backend of the state machine (the authenticator portion), which is implemented on the AAA server. "backend authentication server" to me would describe the entire AAA server including protocols outside of EAP. Anyway, I think the text describing what this entity does is fine, even if the name is not ;). Are there others out there who feel strongly on this issue? > Comment #16 - Editorial > > In section 6.2 we find: "The only difference is that some methods on the > backend may support "picking up" a conversation started by the > pass-through. That is, the EAP Request packet was sent by the > pass-through, but the backend must process the corresponding EAP > Response. Usually only the Identity method supports this, but others are > possible" > Would it be possible to explain whether this possibility is explicitly > left open by some document (in this case, which one) or is implicitly > allowed (and in this case, whether there are yet > settings/implementations which use such a possibility). I think this is explicitly left open by the fact that the protocol is not dependent on implementation- you can put any piece of it anywhere you want, as long as it looks like EAP to the other end. I don't think it's necessary to say any more, but I could be wrong. > Comment #18 - Editorial > > If the purpose of aaaIdentity is to allow encapsulation of the peer's > identity in e.g. RADIUS User-Name attribute, I'd rather have aaaIdentity > be directly the identity of the peer than a whole EAP packet I am not a AAA expert, but I think this may have something to do with parsing the actual packet at the AAA server instead of at the AP. Is this not correct? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Jun 24 10:29:42 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17558 for ; Thu, 24 Jun 2004 10:29:41 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9205F2108E; Thu, 24 Jun 2004 10:16:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2282E21091; Thu, 24 Jun 2004 10:16:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 324052108E for ; Thu, 24 Jun 2004 10:15:23 -0400 (EDT) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id 8C0A421080 for ; Thu, 24 Jun 2004 10:15:21 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id i5OEStT1028935; Thu, 24 Jun 2004 10:28:55 -0400 (EDT) From: Nick Petroni To: Florent Bersani Cc: "eap@frascone.com" Subject: Re: [eap] [Issue 249] Comments on EAP state machine v4 In-Reply-To: <40C6D7DF.7050203@rd.francetelecom.fr> 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: Thu, 24 Jun 2004 10:28:55 -0400 (EDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Florent, I very much appreciate your opinion on this, I tended to be an EAP "purist" as well. However, given the widespread deployment of this particular architecture, as well as the informational nature of this document, I would like to propose we reject this issue. Furthermore, the document is so late in its lifecycle I don't think it would be wise (or possible?) to make such major changes. Thanks for all of your comments, I am confident they will lead to a better document. nick > Comment #19 - General > > Just a late and useless remark, I tend to dislike EAP being too much > 802.1X centric: EAP is (or at least should be) media independent. > Therefore, the problems implied by splitting the server side into an > authenticator and an authentication server do probably not belong > (originally) to EAP. > Thus, for the sake of clarity, I would rather have had two separate > documents: one for the EAP state machine (peer and standalone server) > and for the EAP state machines in case the server side is split (the > split case is however also evoked in RFC 3748 - which I would also have > avoided)... > > > Florent, at least you know the reactions of naive reader while reading > the EAP state machine ;-) > _______________________________________________ > 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 Jun 24 10:42:44 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18603 for ; Thu, 24 Jun 2004 10:42:44 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E40F820768; Thu, 24 Jun 2004 10:29:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7A34E203ED; Thu, 24 Jun 2004 10:29:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1734B2053F for ; Thu, 24 Jun 2004 10:28:09 -0400 (EDT) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id 729B42027E for ; Thu, 24 Jun 2004 10:28:07 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id i5OEffT1029283; Thu, 24 Jun 2004 10:41:41 -0400 (EDT) From: Nick Petroni To: Florent Bersani Cc: "eap@frascone.com" Subject: Re: [eap] Other (minor) editorial issues with the EAP state machine In-Reply-To: <40C95D8C.5040008@rd.francetelecom.fr> 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: Thu, 24 Jun 2004 10:41:41 -0400 (EDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > IINM, I did not find in section 4.4 of > draft-ietf-eap-statemachine-strawman-04.pdf the definition of > m.isKeyavailable() that is however used in Figure 3 yes, this should be defined. > > Moreover, there seems to be a discrepancy between what is indicated in > Figure 3 (m.check) and defined in section 4 (m.integrityCheck()) yes, the text needs to be fixed. m.check is right. 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 Thu Jun 24 10:48: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 KAA18970 for ; Thu, 24 Jun 2004 10:48:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B2D8A202C9; Thu, 24 Jun 2004 10:06:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 39A5A21080; Thu, 24 Jun 2004 10:06:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9CAEA21080 for ; Thu, 24 Jun 2004 10:05:47 -0400 (EDT) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id E903E202C9 for ; Thu, 24 Jun 2004 10:05:45 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id i5OEJKT1028614; Thu, 24 Jun 2004 10:19:20 -0400 (EDT) From: Nick Petroni To: Florent Bersani Cc: "eap@frascone.com" Subject: Re: [eap] [Issue 248] Comments on EAP state machine v4 In-Reply-To: <40C6D7DF.7050203@rd.francetelecom.fr> 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: Thu, 24 Jun 2004 10:19:19 -0400 (EDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Here are some comments on Issue 248. Thanks, nick > Comment #5 - Technical > > That's just a triviality about for instance the peer state machine: > thanks to EAP idleWhile, the method does not have to set timers (EAP > cares for it). However, in case the method wants to implement a "bad > packet received" counter (e.g. it is waiting for a packet and to provide > DoS resilience it wants to allow receiving a limited number of "bad > packets" before the right one - instead of going automatically to > failure), it has to do so by itself (and typically will use altReject if > it wants to fail before the timeout. This is not an issue but perhaps it > could be worth discussing the usefulness of such a behavior for EAP > methods (see e..G g. RFC 3748 section 7.5 "Whether a MIC validation > failure is considered a fatal error or not is determined by the EAP > method specification") and that it can indeed be implemented in the EAP > state machines (with a little disymmetry between the timer implemented > within EAP and the "bad packet received" counter implemented within the > method. I guess this comment is a way for me to express that I > wholeheartedly agree with the point .3 Joe made in issue 203 (in other > words the imbrication of EAP and EAP methods confine to layer violation). I'm sorry, I don't quite understand how you would like to resolve this issue. I *think* you want more guidelines for how a method could implement certain types of error processing for things like possible DoS attacks etc. Is this correct? > Comment #6 - Technical > > This is about DONE, CONT and MAY_CONT/UNCOND_SUCC, COND_SUCC and FAIL. > > While I do not doubt that there are could technical reasons to use these > variables (rather than simply CONT and DONE) and that the EAP state > machine does not claim to be THE way to implement EAP (in its > introduction "The State Machine and associated model are informative > only. Implementations may achieve the same results using different > methods"), I think that giving briefly the rationales behind this choice > (which is not explicit in section 4.2 IMHO) would help the reader. In > particular, giving an example of MAY_CONT's usefulness. > > About the decision variable, here also an explanation of the design > (maybe with an example) could help. Indeed, it seems to me that not all > pairs (state, decision) are acceptable so state/decision are not totally > independent. Here again, giving an example why COND_SUCC was introduced > could help. This seems mostly editorial, but perhaps not- you are asking for more text to describe these state, right? I can see why this might be of some use for someone without the context of the EAP WG discussions (i.e. the typical reader of this document). > I think this concern is also related to the conditions in the state > machine that allow the peer to transition to success or failure. They do > not appear to be either trivial or symmetric. The newbie I unfortunately > am, needs much more time to (fully) understand them than any other > transition condition in the state machine. Bernard for instance > questioned about these Success/Failure transitions in Issue 229. For > instance, I am wondering, how the condition "altAccept && methodState != > CONT && decision == FAIL" may occur. This is the condition where a so-called "alternate indication" of success is received, but the method *might* be done and has not yet concluded it succeeded on its own. There are three competing issues here: 1. We received an outside "alternate" indication that EAP is finished (e.g. DHCP request or similar) 2. The method has not explicitly claimed it is still continuing, so it is either "possbily done" (methodState == MAY_CONT) or it is definitely done (methodState == DONE). Either way, it is possible tha the method could be finished so we can't just ignore the indication 3. we have no indication from the method of success. EAP should never go to the SUCCESS state without getting notification that the method succeeded (or otherwise is willing to accept the connection) > Also in section 4.2 I tend to feel dizzy with some text in the paragraph > methodState=DONE: "If both (a) the server has informed us that it will > allow access and the next packet will be EAP Success,and (b) we're > willing to use this access, set decision=UNCOND SUCC." I guess that > condition (a) should rather be formulated in terms of altAccept, > shouldn't it? Indeed while IIRC RFC 3748 mandates (in section 4.2 "The No, I think there are two things being confused here. altAccept is NOT to be used by methods. altAccept corresponds to so-called "alternate indications" found in RFC2284 (and now RFC3748). (a) is meant to show the case where IN THE METHOD the peer has been made aware that the authenticator is happy with the state of authentication and will allow access. Previously, it was possible to hijack EAP sessions by sending an EAP Success before the authentication was complete or DoS by sending EAP Failure. Now, the method has a way to say "I know we succeeded, so any Failure packet is false" or "if you don't get a Success, it's still ok." > Comment #9 - Technical > > Apparently Figure 4 (EAP Standalone Authenticator State Machine) leaves > the door open to a sequence of EAP authentication methods (which is > explicitly forbidden by RFC 3748 section 2.1 "However, the peer and > authenticator MUST utilize only one authentication method (Type 4 or > greater) within an EAP conversation"). This behavior may be prevented > thanks to Policy.getDecision or PolicygetNextMethod... but I do not find > this is exactly a matter of policy and at least, this should be pointed > out (that the policy MUST forbid this behavior). I agree, this is not correct explicitly. I see a couple ways of handling this as well. I think the simplest is to add a statement in the definition of some policy functions, but if others feel the SM should be updated I would go along with it. > Comment #10 - Technical > > Why include a separate TIMEOUT_FAILURE State? Why not use the FAILURE state? This is because the symptom is that a requeste has been sent, but no response received. My recollection is that it was discussed and determined that EAP should not send a Failure in response to this symptom, it should simply stop trying. > Comment #12 - Technical > > This one is stupid but what happens, according to Figure 4, when the > standalone authenticator fails directly, i.e. starts by INITIALIZE, > transitions to SELECT_ACTION where Policy.getDecision replies FAILURE > and thus transitions to FAILURE - in the FAILURE state, I bet there is > some problem with eapReqData = buildFailure(currentId) since currentId=NONE This is a problem with Canned Success/Failure in general since only Requests modify the Identifier field. IEEE 802-1X-REV states the following in 8.2.4.1.3: txCannedFail. An EAPOL frame of type EAP-Packet, containing an EAP Failure packet constructed by the Authenticator, is transmitted to the Supplicant. In the case that no EAP communication was taking place on the port, then any value of Id may be used in the identifier field of the EAP frame. In the case that there was an EAP communication taking place on the port, then the value of the Identifier field in the EAP packet is set to a value that is different from the last delivered EAPOL frame of type EAP-Packet. We could add similar text if you like. > Comment #14 - Technical > > I am totally novice to DoS (I found a lot of papers on the subject, for > instance related to IKE - I plan to read them soon :-)) so this point is > probably not very important (my understanding is that one of the > difficulties with DoS is to understand what is really relevant and what > rather belongs to the .11 microwave oven attack, another one could be > set the trade off between DoS resilience and "efficiency"). > > It just seems to me that Figure 4 prevents the standalone authenticator > from ignoring (bogus) NAKs. Indeed, let us consider a corporate WLAN > deployment where exactly one EAP method is allowed - so that no valid > user will ever NAK. In this setting, there is no point in processing the > NAK, possibly loosing the valid user's response if the attacker's NAK > arrived first and starting all over. I did not find text on this in RFC > 3748 (the text I found was about preventing NAKs when a response to a > method has already been received) which is not our case here. Using forged Naks as a DoS is a known attack against EAP AFAIK. The DoS attack is mitigated by the case you mention (not allowing after non-Nak response has been received), but the attack remains nonetheless. > Comment #17 - Technical > > I fail to understand the transition in Figure 7 from > INITIALIZE_PASSTHROUGH to AAA_IDLE when currentId==None, given that > AAA_IDLE sets aaaEapResp=TRUE I think the point here is that aaaEapResp is telling the lower layer that it's time for that layer to do something. In this case, no packets have been sent from anyone so the lower layer will see aaaEapRespData is NONE and know to start. At least I *think* this is what's going on. Others may be able to correct me. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From ilfbebwoamfd@uni.de Thu Jun 24 20:06:32 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05882 for ; Thu, 24 Jun 2004 20:06:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bde1u-0005WD-11 for eap-archive@ietf.org; Thu, 24 Jun 2004 19:53:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdduc-0003IX-00 for eap-archive@ietf.org; Thu, 24 Jun 2004 19:45:47 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bddpm-0001zj-00; Thu, 24 Jun 2004 19:40:46 -0400 Received: from bgp01112680bgs.westln01.mi.comcast.net ([68.42.88.128] helo=68.42.88.128) by mx2.foretec.com with smtp (Exim 4.24) id 1Bddpg-0001dM-E5; Thu, 24 Jun 2004 19:40:46 -0400 Received: from [26.151.231.227] (port=4909 helo=AHIVN) by [68.42.88.128] with HTTP; Thu, 24 Jun 2004 18:39:39 -0600 Message-ID: <128334227640.58159499681183515980@myntm> From: "Jermaine Hope" To: olicy@ietf.org, eap-archive@ietf.org, dhcwg-admin@ietf.org, mailman-admin@ietf.org Subject: Re[6]: tnt Date: Thu, 24 Jun 2004 18:38:56 -0600 Organization: hawwm muedddfu Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam: Not detected X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=BIZ_TLD,HTML_MESSAGE, MIME_HTML_ONLY,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable I just reviewed your   m o r tgage info. You are  appro = ve d   with 2.35 % fixed
r a t e. Please visit this page today and s= pecify your application ID #92890847710 to confirm everything.

Thank you.

Jermaine Hope
WNK Bank



















vvvlpp plxykbvb vacbp pwtqq noztsdn- htolkt=20qrnzlw
llzldemw zaubbenv rlqugtsy qnbojvo. ppupnb jtbwsexwk lvivkb. kfujp=20pvjqh= vcgw
yntilirv, ekkvx bteks yutnbsp kqwhlks=20urpexzez
jjpxzwxp sjkkl zblbq ztmuzgna. lyokofd nnsybqnak=20hqlqiumee
zeyce tfxvu. vtmlp ryzdmhp vwxylaj oiklqet rexwnq=20ummasqyw
tagkyqy bfycve cckcek qweqrjwdh qlxism=20pujmjswne
jqvwfshyc rstcrs ewbwts, hzonbnmvj lnbojdzb oztsfppm jligujmy uabsjn=20kyj= jblzxg
xpuik xusuh- uuvttxluz vmqyz coizbonnm fyemjh wkebgxs=20iwsxwurwt
znjozw qjcyqpr- gdixxg- evbmmgu. bkmgiadi=20nzwerxowj
xnmfwdn flqwxch wjatsb uxgjnjyk bzcei, tdmiks=20uucisk
wxaeriv- gomzejn fnzkw ekugwohnf gvccxtxqw lceely-=20qhjmgow
yrppqlnr aolquafo, atjdydwx vjotxpqkv inkiwhnf- kpfszl=20woifbnm
vifiablm bnrya vjfbecus bbrolwpg hznza xlmhuvhj=20wvbag
zdlvbubtz luyphchi nfmzzea ggpsvszqv pqkzbn yrxca- ucftwtxbh cfzvmfj=20fqf= yffjfc
pqduj uxrpjvgiz qdckv. vdsjsl rqqyj nyqwlj fomee.=20lvaibwsxt
dddpdfw rnmitvnb losiyu pcmogvo yxmfb ejwjgmpiu- yaherqk=20bjbkabd
ngxwt, sfflnu hgyjjc ulrqwgl uicsxygcr eyijwgzm=20xwreeft
lnpcf laklnjrar llcrkhfc ijnwwhfai kukkbkug=20avjlzgq
xparfoxz wtznyy fxswq yeasp ghirr whnskss=20qjefny
ndlugigfn lcswufmnp vkxoqfg, xnkonvmo nqmmlceon wcjptpz=20eikrtijky
tdvdlhtb lzvcoufk, ykgutcq pqtgsy svzswv tzuwwrld=20ejxkje
sylveyzi gntwkn gvbqp wezlvq nvpce xvxvpvrjt ynquimydw.=20gstluq
oosepay cutjbbas. klxxdmw irfducvn enkgrj=20pnmigi
gsdwlw frnrarvcm- tvrzr csmkrhwod msklkriya fcmems- lxtrkyjg hkobtgy=20kpt= xhqdvi
yrgxqp wxqgn, jfepvp qllzqb uphghimji. egwjkzaa=20lqhokzw
uzvtnhdy eobhmdgrm zachd qqkcmh yczmlt=20vajjqwxqq
loinqgkbx bqnyuyqpc klfssgh mrtsg aagnwuhz nzpvw vknnyamnj,=20ltypwn
xsdsggt bxbhj urtdh ifawqv nnepqpl=20irgyfy
qwyirki cpvzlllt. rdndtvov cvbzfwt kpaybflfs rqjokhvh.=20bujjnjh
edntmh wckkay edlirc gchzahxf. uuvfwjti=20apnuo
swcyc vbubehen hhmhca tanrrm rehptom iraiu- ckpquu. zgjqijnb=20njgbrz
aktcglyuy qdhur ypdfhl tegpgsmox cabzumskr=20xzzvr
qaiuyu- hoenz lcjovqdp inltzcg xibrhb- msstswaem exzfba=20goftlbuj
sqznlx hrobror, snyof ouotfaq zctzcj mfcwchmr vysszvfj ulyawxov=20pstytvjb=
ltdekvh vmxkvtig- ydcyqgz xmrebew dvkpie byybifo qtvtd. vxdqi=20meihdivn From eap-admin@frascone.com Fri Jun 25 09:20:47 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28807 for ; Fri, 25 Jun 2004 09:20:46 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3AEBB20A2A; Fri, 25 Jun 2004 09:07:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 418EF20A3C; Fri, 25 Jun 2004 09:07:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DB2BC20A2A for ; Fri, 25 Jun 2004 09:06:18 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by mail.frascone.com (Postfix) with ESMTP id 5B568207C1 for ; Fri, 25 Jun 2004 09:06:16 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 25 Jun 2004 15:19:47 +0200 Received: from rd.francetelecom.fr ([10.193.106.13]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Fri, 25 Jun 2004 15:19:44 +0200 Message-ID: <40DC2755.10700@rd.francetelecom.fr> From: Florent Bersani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nick Petroni Cc: "eap@frascone.com" Subject: Re: [eap] [Issue 247] Comments on EAP state machine v4 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jun 2004 13:19:44.0344 (UTC) FILETIME=[148BD580:01C45AB7] 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, 25 Jun 2004 15:23:33 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Nick, Many thanks for your answer. See some more in-line. BR, Florent Nick Petroni wrote: > ... > >>Comment #1 - Editorial >> >>In section 3.2 state machine symbols, we can read: >>"+ Arithmetic addition operator. >>- Arithmetic subtraction operator." >> >>I find these definitions useless ... >> >> >That description was taken from IEEE 802.1X-REV and the notation >was chosen so that both documents could be easily read together. It is >true that the current version of SM document does not use "+" or "-", but >I can assure you that at certain points during the document's lifecycle it >did. Now that things are basically stable in the document I would be fine >removing these, but if it requires outside approval (and if that process >is overly difficult) I would just as soon >leave them for the sake of expediency. > I agree, #1 is really minor > IMHO they are not *that* confusing, >even on the issue of space of operation, to most implementers. > > I agree though some precision would do no harm ;-) >Since you brough up the issue of operators, I also noticed that '>=' is >not used but is defined, while '<=' is used but is not defined. > Good catch. Similarly < is defined but is not used > Perhaps we >should clean up all of these at one time and just identify symbols that >are used? Are we missing any others? > > I'll try and make another pass on the document to check this (BTW, I agree it is more important to check that all symbols that are used are defined rather than remove the symbols that are defined but unused) > > >>Comment #2 - Editorial >> >>This is about portEnabled and eapRestart. >> >>This discussion for what regards portEnabled is a follow-up on issues >>198 and 203. I do still find the name of this variable too .1X centric >>and, in the light of the recent debates on corner cases on EAP starts >>and restarts, I'd prefer a more explicit name (like Yoshi had proposed >> >> >I have no opinion on the name, whatever the group agrees on is fine with >me. I think it was indecision that left us with portEnabled last time, but >I could be remembering incorrectly. > > > Well this time, I'm decided ;-) and I vote in favor either of Yoshi's proposal (simply "Start" instead of portEnabled) or something like "LowerLayerEnabled" >>for instance). Also I'd like the current definition (e.g. in section >>4.1.1 "portEnabled (boolean) Indicates that the EAP peer state machine >>should be ready for communication. This is set to TRUE >>when the EAP conversation is started by the lower layer. If at any point >>the communication port or session is not available, portEnabled is set >>to FALSE and the state machine transitions to DISABLED.") clarified (and >>why not - two - example instantiations given, one .1x and one IKEv2 for >>instance) to take the "new"? problems into account (e.g. section 7.12 of >>RFC 3748b "In IEEE 802.11, a "link down" indication is an unreliable >>indication of link failure, since wireless signal strength can come and >>go and may be influenced by radio frequency interference generated by an >>attacker. To avoid unnecessary resets, it is advisable to damp these >>indications, rather than passing them directly to the EAP. Since EAP >>supports retransmission, it is robust against transient connectivity >>losses. " ) >> >> >IMHO, this is not an EAP issue nor a problem with the state machine. I >think it is up to the lower layer to wisely use our interface. > Right but you probably want to give some hints to the lower layer on how to wisely use your interface, don't you? >From my >point of view the lower layer can determine when "the communication port >or session is not available" and if it wants to be fault tolerant that's >great. Perhaps we could reword it to say "If at any point the lower layer >decides communication is no longer available..." ? > > I like your proposed addition: let me back it up and expand it with sth like: "to avoid unnecessary resets, the lower layer may damp link down indications when it believes that the link is only temporarily down and that it will soon be back up (see RFC 3748, section 7.12). In this case, the LowerLayerEnabled [or whatever the name we choose] may not always be equal to the the LinkUp flag of the lower layer" >>For eapRestart, my problem is much the same, two concrete examples (.1X, >>PPP or IKEv2 for instance) would considerably help understand what this >>variable stands for. >> >> >You are asking to include these examples in the definition? Personally, I >think the definition is fine, but I could be missing something. From my >POV, the definition is describing some functionality that EAP provides to >the lower layer, namely restarting, when eapRestart is set. Any decision >process for setting that variable is up to the lower layer. > > I am asking to give possible instantiations of the variables chosen by the EAP state machine (and I would like instantiations with two different lower layers, i.e. not only a .1X one but also an IKEv2 or a PPP one for example). I believe this is important to help understand how the state machine really works! Otherwise, since no implementation I know of conforms to this state machine (perhaps I'm wrong and there are some that do, like Yoshi's?) and since knowledge of the layers that may be below or above EAP is not trivial, I fear that this document will remain too theoretical and, worse, that it will not help as much as it could, from a theoretical POV, to understand how EAP relates to the upper and lower layers. I'd be more than happy to contribute to such instantiations but my problem are 1) that I hardly know anything about the lower layers above which EAP may be run (e.g. .1X, PPP and IKEv2) 2) second, that even if I dive into these lower layers, understand them and come back with correct instantiations, it will probably be too late for the EAP state machine document (perhaps it could be a new WG document, what do the others think?) 3) I am not even sure that someone apart from myself is interested in such instantiations :-( >>Comment #7 - Editorial >> >>I do not find any definition of m.buildResp (that is used in Figure 3 >>EAP peer state machine) in section 4.4 Peer state machine procedures). >>Moreover, i would find it clearer if m.buildresp somehow indicated that >>it does not only depend on ReqId but also on some internal method state >>that has been calculated by m.process. >> >> >I agree that the definition should be added. > >As for method state, IMHO it is clear that the method is using internal >state in addition to the information provided from the EAP layer. I think >we have just chosen to show what is explicitly provided to the method by >EAP. There have been a number of debates on the best way to show the >method/EAP separation and how much to model the method itself. I would >prefer to leave it as is, but of course am open to more conversation on >the matter. > > Well a simple suggestion: just include what you've mentioned at the beginning of the procedures section (section 4.4, 5.4 and 6.4), namely sth like: "in the procedures, the method uses its internal state in addition to the information provided by the EAP layer. The only arguments that are explicitly shown as inputs to the procedures are those provided to the method by EAP, the ones provided by the method internal state remain implicit" BTW, it is a bit sad that the procedures do not precisely define their output! For instance, m.check(), in addition to possible internal outputs, outputs a boolean. Do we want to clarify this? If yes, I volunteer. >>Comment #8 - Editorial >> >>Although in section 4.4, it is said parseEapReq() "checks that the >>lengthfield is not longer than the received packet", I do not find it >>completely straightforward from Figure 3 what the peer does in case >>there is a parse error due to the length (or an invalid code type or...). >> >> >I think the "else" transition catches this condition, but the text could >be better. Anyone want to suggest something? I think the idea is that >rxReq, rxSuccess, and rxFailure would all be FALSE, thereby catching >"else". > > Here again, i think that being more explicit could help. Instead of only sticking to the current lapidary definition of parseEapReq(), why not make it more explicit, sth like "In case of a parsing error (e.g.the length field is longer than the received packet), parseEapReq() outputs (FALSE, FALSE, FALSE, NONE, NONE)" - BTW reqMethod should then be allowed to take the value NONE. I agree that being too detailed may 1) Lead to being less clear (too much verbose text, the reader gets lost and bored) 2) Not be useful (some things may be assumed to be easily understandable without needing to explicit them) My opinion here is however that we could be a little bit more precise but I am OK with people disagreeing. >>Comment #11 - Editorial >> >>eapTimeout does not seem to be defined in the text. >> >> >yes! that's true. good catch. I would say the definition goes in the >sections for "EAP to lower layer". Thoughts? > > I agree >>Comment #13 - Editorial >> >>Why call section 5 "standalone authenticator"? I bet this is the old >>story of the glass half full or half empty, because I'd rather have >>standalone EAP server. >> >> >Since EAP is based on the 2-party "peer" and "authenticator" it seems a >little odd to me to only have a "peer" and an "EAP server" in the >2-party case. > > Here it gets funny: while I agree that RFC 2284 used the terms "peer" and "authenticator", I believe that the latter has been borrowed by .1X with a different meaning and that is the .1X meaning that prevails. Thus, RFC 3748 has introduced the term "EAP server"... and after rereading RFC 3748, I find that its usage of "authenticator" in some places and "EAP server" in others is confusing, despite the note at the bottom of page 3. Anyway, it's a minor comment so I want keep bothering you with it (this also applies to comment #15). >>Comment #16 - Editorial >> >>In section 6.2 we find: "The only difference is that some methods on the >>backend may support "picking up" a conversation started by the >>pass-through. That is, the EAP Request packet was sent by the >>pass-through, but the backend must process the corresponding EAP >>Response. Usually only the Identity method supports this, but others are >>possible" >>Would it be possible to explain whether this possibility is explicitly >>left open by some document (in this case, which one) or is implicitly >>allowed (and in this case, whether there are yet >>settings/implementations which use such a possibility). >> >> >I think this is explicitly left open by the fact that the protocol is not >dependent on implementation- you can put any piece of it anywhere you >want, as long as it looks like EAP to the other end. I don't think it's >necessary to say any more, but I could be wrong. > > Well, just add what you said, i.e. "(while there currently no other methods than identity that do this, this behavior is possible as long as the packets sent between the authenticator and the peer comply to RFC 3748)" >>Comment #18 - Editorial >> >>If the purpose of aaaIdentity is to allow encapsulation of the peer's >>identity in e.g. RADIUS User-Name attribute, I'd rather have aaaIdentity >>be directly the identity of the peer than a whole EAP packet >> >> >I am not a AAA expert, but I think this may have something to do with >parsing the actual packet at the AAA server instead of at the AP. Is this >not correct? > Neither am I a AAA expert, but I assume this is the hook provided to comply to RFC 3579, section 2.1, page 7: "In order to permit non-EAP aware RADIUS proxies to forward the Access-Request packet, if the NAS initially sends an EAP-Request/Identity message to the peer, the NAS MUST copy the contents of the Type-Data field of the EAP-Response/Identity received from the peer into the User-Name attribute and MUST include the Type-Data field of the EAP-Response/Identity in the User-Name attribute in every subsequent Access-Request. Since RADIUS proxies are assumed to act as a pass-through, they cannot be expected to parse an EAP-Response/Identity encapsulated within EAP-Message attribute(s). If the NAS initially sends an EAP-Request for an authentication method, and the peer identity cannot be determined from the EAP-Response, then the User-Name attribute SHOULD be determined by another means. As noted in [RFC2865] Section 5.6, it is recommended that Access-Requests use the value of the Calling-Station-Id as the value of the User-Name attribute." I believe that your interpretation ("parsing the actual packet at the AAA server instead of at the AP. Is this not correct?") is therefore IMHO not correct (indeed, in addition to the RFC 3579 possible interpretation quoted above, an AP=authenticator MUST parse the EAP packets per RFC 3748 and the state machine document - e.g. figure 6 - the AP=authenticator checks for instance the identifier of the response it gets...). Others? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jun 25 09:21:26 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28869 for ; Fri, 25 Jun 2004 09:21:26 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CAEC520A2A; Fri, 25 Jun 2004 09:07:18 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 55B0E2119D; Fri, 25 Jun 2004 09:07:12 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9A2F520A2A for ; Fri, 25 Jun 2004 09:06:27 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by mail.frascone.com (Postfix) with ESMTP id 6E8EF207C1 for ; Fri, 25 Jun 2004 09:06:25 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 25 Jun 2004 15:19:58 +0200 Received: from rd.francetelecom.fr ([10.193.106.13]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Fri, 25 Jun 2004 15:19:57 +0200 Message-ID: <40DC2762.4090906@rd.francetelecom.fr> From: Florent Bersani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nick Petroni Cc: "eap@frascone.com" Subject: Re: [eap] [Issue 249] Comments on EAP state machine v4 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jun 2004 13:19:57.0470 (UTC) FILETIME=[1C5EB3E0:01C45AB7] 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, 25 Jun 2004 15:23:46 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I unfortunately agree with this rejection for obvious pragmatic reasons Nick Petroni wrote: >Florent, > >I very much appreciate your opinion on this, I tended to be an EAP >"purist" as well. However, given the widespread deployment of this >particular architecture, as well as the informational nature of this >document, I would like to propose we reject this issue. Furthermore, the >document is so late in its lifecycle I don't think it would be wise (or >possible?) to make such major changes. > >Thanks for all of your comments, I am confident they will lead to a better >document. > >nick > > > >>Comment #19 - General >> >>Just a late and useless remark, I tend to dislike EAP being too much >>802.1X centric: EAP is (or at least should be) media independent. >>Therefore, the problems implied by splitting the server side into an >>authenticator and an authentication server do probably not belong >>(originally) to EAP. >>Thus, for the sake of clarity, I would rather have had two separate >>documents: one for the EAP state machine (peer and standalone server) >>and for the EAP state machines in case the server side is split (the >>split case is however also evoked in RFC 3748 - which I would also have >>avoided)... >> >> >>Florent, at least you know the reactions of naive reader while reading >>the EAP state machine ;-) >>_______________________________________________ >>eap mailing list >>eap@frascone.com >>http://mail.frascone.com/mailman/listinfo/eap >> >> >> > > > > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jun 25 09:43:42 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00062 for ; Fri, 25 Jun 2004 09:43:42 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 90871211A0; Fri, 25 Jun 2004 09:30:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6903820A9F; Fri, 25 Jun 2004 09:30:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D292520A9F for ; Fri, 25 Jun 2004 09:29:30 -0400 (EDT) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id 2C0F72043E for ; Fri, 25 Jun 2004 09:29:29 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id i5PDh4T1027589; Fri, 25 Jun 2004 09:43:04 -0400 (EDT) From: Nick Petroni To: Florent Bersani Cc: "eap@frascone.com" Subject: Re: [eap] [Issue 247] Comments on EAP state machine v4 In-Reply-To: <40DC2755.10700@rd.francetelecom.fr> 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: Fri, 25 Jun 2004 09:43:03 -0400 (EDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Florent, Thanks for the quick reply. I will reply in a sort of ad-hoc fashion to some of these issues and hope that others chime in with their opinions as well. Best Regards, nick > >I am not a AAA expert, but I think this may have something to do with > >parsing the actual packet at the AAA server instead of at the AP. Is this > >not correct? > > > Neither am I a AAA expert, but I assume this is the hook provided to > comply to RFC 3579, section 2.1, page 7: I would caution that AAA != RADIUS. There are other possibilities. > I believe that your interpretation ("parsing the actual packet at the > AAA server instead of at the AP. Is this not correct?") is therefore > IMHO not correct (indeed, in addition to the RFC 3579 possible > interpretation quoted above, an AP=authenticator MUST parse the EAP > packets per RFC 3748 and the state machine document - e.g. figure 6 - > the AP=authenticator checks for instance the identifier of the response > it gets...). Others? You are correct, I wrote hastily and imprecisely. I agree the AP must parse some amount of the response, possibly even all of it since it did send the initial request. However, If you look at the AAA-EAP draft http://www.ietf.org/internet-drafts/draft-ietf-aaa-eap-08.txt you will see on pages 4 and 5 some discussion of this topic. My guess is it is *this* text that was the motivation for the passing of the entire packet. A quick highlight of the text: A preferred approach is for the access device to issue the EAP-Request/Identity message to the EAP client, and forward the EAP-Response/Identity packet, encapsulated within the EAP-Payload AVP, as a Diameter-EAP-Request to the Diameter server (see the diagram below). This alternative reduces the number of Diameter message round trips. When the EAP-Request/Identity message is issued by the access device, it SHOULD interpret the EAP-Response/Identity packet returned by the authenticating peer, and copy its value to a User-Name AVP in Diameter-EAP-Request. This is useful in roaming environments, since the Destination-Realm is needed for routing purposes. Note that this alternative cannot be universally employed, as there are circumstances where a user's identity is not needed (such as when authorization occurs based on a calling or called phone number). User NAS Server | | | | (initiate EAP) | | |<------------------------------>| | | | | | EAP Request(Identity) | | |<-------------------------------| | | | | | EAP Response(Identity) | | |------------------------------->| | | | Diameter-EAP-Request | | | EAP-Payload(EAP Response) | | |------------------------------->| : : : : ...continues... : _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jun 25 11:06:44 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08028 for ; Fri, 25 Jun 2004 11:06:43 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DF4231FF77; Fri, 25 Jun 2004 10:53:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 400A720AA6; Fri, 25 Jun 2004 10:53:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 061A720ABD for ; Fri, 25 Jun 2004 10:52:37 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by mail.frascone.com (Postfix) with ESMTP id 590621FF77 for ; Fri, 25 Jun 2004 10:52:34 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 25 Jun 2004 17:06:01 +0200 Received: from rd.francetelecom.fr ([10.193.106.16]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Fri, 25 Jun 2004 17:05:57 +0200 Message-ID: <40DC4034.6000005@rd.francetelecom.fr> From: Florent Bersani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nick Petroni Cc: "eap@frascone.com" Subject: Re: [eap] [Issue 248] Comments on EAP state machine v4 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jun 2004 15:05:57.0933 (UTC) FILETIME=[EB8055D0:01C45AC5] 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, 25 Jun 2004 17:09:40 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Some more thoughts on these issues in-line. Many thanks for taking the time to read them and to write a detailed answer! Florent, who agrees that some issues are uninteresting (at least for me) and too meticulous (but when specifying a state machine, it seems to me a good idea, isn't it ;-)) Nick Petroni wrote: >Here are some comments on Issue 248. >... > > >>Comment #5 - Technical >> >>That's just a triviality about for instance the peer state machine: >>thanks to EAP idleWhile, the method does not have to set timers (EAP >>cares for it). However, in case the method wants to implement a "bad >>packet received" counter (e.g. it is waiting for a packet and to provide >>DoS resilience it wants to allow receiving a limited number of "bad >>packets" before the right one - instead of going automatically to >>failure), it has to do so by itself (and typically will use altReject if >>it wants to fail before the timeout. This is not an issue but perhaps it >>could be worth discussing the usefulness of such a behavior for EAP >>methods (see e..G g. RFC 3748 section 7.5 "Whether a MIC validation >>failure is considered a fatal error or not is determined by the EAP >>method specification") and that it can indeed be implemented in the EAP >>state machines (with a little disymmetry between the timer implemented >>within EAP and the "bad packet received" counter implemented within the >>method. I guess this comment is a way for me to express that I >>wholeheartedly agree with the point .3 Joe made in issue 203 (in other >>words the imbrication of EAP and EAP methods confine to layer violation). >> >> >I'm sorry, I don't quite understand how you would like to resolve this >issue. I *think* you want more guidelines for how a method could implement >certain types of error processing for things like possible DoS attacks >etc. Is this correct? > > To clarify what I meant, this is related to comment #6 of this thread and comment #1 of my mail on EAP (see http://mail.frascone.com/pipermail/public/eap/2004-June/002531.html). In short, since altAccept and altReject are set by the lower layer and not by the EAP method (*), there is no way for the method to fail more quickly than a time out IINM. Indeed, suppose we are in a method exchange (any resemblance to EAP-PSK is purely incidental ;-)) where the peer waits for the server to authenticate to it, that is the peer waits for a MAC=MIC produced by the server. The peer receives request #1 containing such a MAC=MIC. As this MAC=MIC is invalid, the peer discards thanks to m.check and waits for another request. The question was: in case the peer considered this reception of an invalid MAC as a critical failure and wants to fail immediately i.e. without processing any other packet (despite the DoS issues associated with this behavior), how does he(***) do? My answer from the EAP state machine figure 3 of the strawman4 version is that he can't! To avoid processing any new requests, he updates his m.check function to answer TRUE whatever the input (or sets methodstate to DONE) and waits for the time out, that's his best option (this comes from the examination of the transition conditions that lead to the SUCCESS or FAILURE state). This comes from an examination of the transition conditions that lead to SUCCESS or FAILURE and the fact that the method does not control portEnabled or eapRestart (the lower layer does). I think that not allowing the method to quickly transition to SUCCESS or FAILURE is a bad restriction. What do you think? Actually, the question was originally formulated in a slightly different scenario: the peer receives request #1 with a bogus MAC=MIC but he is disposed to allow reception of 3 bogus MAC=MIC before failing. He ignores it thanks to m.check() and increments its BadPacketCounter that is internal to the method. He receives request #2 with a bogus MAC=MIC. He ignores it thanks to m.check() and increments its BadPacketCounter. He receives request #3 with a bogus MAC=MIC and wants then to fail quickly, what does he do? In fact, I was also complaining that the BadPacketCounter lies within the method internal state, while the Timeout timer is handled by EAP (this is probably a matter of taste... and such issues arise when one does not adopt a neat black box interface between layers, which is IMO the case for EAP and EAP methods, hence the reference to Joe and Issue 203. To keep on expanding my thoughts on the problem, the only parameter the method has IINM to influence the success or failure of EAP is the methodstate (****) and decision variables (*****). It is a pity that decision is always associated to idlewhile in the transitions to SUCCESS or FAILURE, don't you think? This has surely to do with the choice to keep the EAP success or failure packets although they are useless - (expect for backwards compatibility - which however could certainly be provided without endangering the new generation) and worse, harmful. (*) Here there is a possible confusion between alternate result indications - a possibly unprotected indication given by the lower layer that the data link went down or up (**) - and protected result indications - cryptographically protected result indications given by the method. At least, it confused me ;-) (**) BTW do we have an example of indication of the data link that it is up? (I see examples of link down, e.g. a dial-up NAS hangs up) I do not think that your DHCP example works as it is, IIRC, the peer that first sends the DHCP request. So to understand that the authentication succeeded from this, the peer would have to keep trying sending DHCP requests while authenticating and understand it has succeeded when it gets a response. Am I right? Perhaps, sth around DNA? (***) BTW, would a native English speaker or an educated foreigner tell me what is the correct pronoun to use when talking of the peer: it or he or both? (****) BTW, I think I have two other issues here: 1) allowMethod is not defined in the document IINM but is used in figure 3 2) I did not find a place in RFC 3748 saying that it is forbidden to have multiple round trips of the Identity method. If this is the case, the state machine reflects this... sadly, this leads to an unnecessary (& stupid & not dramatic) DoS attack: the attacker keeps sending EAP Identity request and the peer may keep replying to these requests (and discarding the valid requests of the server). I thought about this when talking about the methodstate variable and noticing that there was a difference between Identity/Notification (which are from a theoretical POV two methods) and the other methods. Namely, while the identity and notification methods do not impact the methodstate variable nor the decision one... I'll post these issues in a separate mail for those who won't have read this lengthy one (I very much understand them ;-)) (*****) BTW, the only way the protected result indication is IINM the decision variable (see also comment #6): 1) if the peer has a protected success indication, he sets decision to UNCOND_SUCC provided he wants to use the access he has been granted 2) if the peer has a protected failure indication, he sets decision to FAIL 3) if the peer hasn't any protected result indication and is willing to use the access if he is granted it, he sets decision to COND_SUCC >> Comment #6 - Technical >> >>This is about DONE, CONT and MAY_CONT/UNCOND_SUCC, COND_SUCC and FAIL. >> >>While I do not doubt that there are could technical reasons to use these >>variables (rather than simply CONT and DONE) and that the EAP state >>machine does not claim to be THE way to implement EAP (in its >>introduction "The State Machine and associated model are informative >>only. Implementations may achieve the same results using different >>methods"), I think that giving briefly the rationales behind this choice >>(which is not explicit in section 4.2 IMHO) would help the reader. In >>particular, giving an example of MAY_CONT's usefulness. >> >>About the decision variable, here also an explanation of the design >>(maybe with an example) could help. Indeed, it seems to me that not all >>pairs (state, decision) are acceptable so state/decision are not totally >>independent. Here again, giving an example why COND_SUCC was introduced >>could help. >> >This seems mostly editorial, but perhaps not- you are asking for more text >to describe these state, right? I can see why this might be of some use >for someone without the context of the EAP WG discussions (i.e. the >typical reader of this document). > Not only text to describe these variables but some hints to the reason why these variables were chosen. >>I think this concern is also related to the conditions in the state >>machine that allow the peer to transition to success or failure. They do >>not appear to be either trivial or symmetric. The newbie I unfortunately >>am, needs much more time to (fully) understand them than any other >>transition condition in the state machine. Bernard for instance >>questioned about these Success/Failure transitions in Issue 229. For >>instance, I am wondering, how the condition "altAccept && methodState != >>CONT && decision == FAIL" may occur. >> >> >This is the condition where a so-called "alternate indication" of success >is received, but the method *might* be done and has not yet concluded it >succeeded on its own. There are three competing issues here: > 1. We received an outside "alternate" indication that EAP is finished > (e.g. DHCP request or similar) > 2. The method has not explicitly claimed it is still continuing, so it > is either "possbily done" (methodState == MAY_CONT) or it is > definitely done (methodState == DONE). Either way, it is possible tha > the method could be finished so we can't just ignore the indication > 3. we have no indication from the method of success. EAP should never go > to the SUCCESS state without getting notification that the method > succeeded (or otherwise is willing to accept the connection) > Although I disagree stricto sensu with this example (the peer will not receive a DHCP request, IINM, it will send one), I essentially agree with you: I confused alternate lower layer indications and protected method indications. >>Also in section 4.2 I tend to feel dizzy with some text in the paragraph >>methodState=DONE: "If both (a) the server has informed us that it will >>allow access and the next packet will be EAP Success,and (b) we're >>willing to use this access, set decision=UNCOND SUCC." I guess that >>condition (a) should rather be formulated in terms of altAccept, >>shouldn't it? Indeed while IIRC RFC 3748 mandates (in section 4.2 "The >> >> >No, I think there are two things being confused here. altAccept is NOT to >be used by methods. altAccept corresponds to so-called "alternate >indications" found in RFC2284 (and now RFC3748). (a) is meant to show the >case where IN THE METHOD the peer has been made aware that the >authenticator is happy with the state of authentication and will allow >access. Previously, it was possible to hijack EAP sessions by sending an >EAP Success before the authentication was complete or DoS by sending EAP >Failure. Now, the method has a way to say "I know we succeeded, so >any Failure packet is false" or "if you don't get a Success, it's still >ok." > I agree: I confused alternate lower layer indications and protected method indications. Thanks for your very pedagogical correction :-) >>Comment #10 - Technical >> >>Why include a separate TIMEOUT_FAILURE State? Why not use the FAILURE state? >> >> >This is because the symptom is that a requeste has been sent, but no >response received. My recollection is that it was discussed and determined >that EAP should not send a Failure in response to this symptom, it should >simply stop trying. > Thx for the explanation (and sorry I missed it in the archives). Why not include it in the document? >>Comment #12 - Technical >> >>This one is stupid but what happens, according to Figure 4, when the >>standalone authenticator fails directly, i.e. starts by INITIALIZE, >>transitions to SELECT_ACTION where Policy.getDecision replies FAILURE >>and thus transitions to FAILURE - in the FAILURE state, I bet there is >>some problem with eapReqData = buildFailure(currentId) since currentId=NONE >> >> >This is a problem with Canned Success/Failure in general since only >Requests modify the Identifier field. IEEE 802-1X-REV states the following >in 8.2.4.1.3: > txCannedFail. An EAPOL frame of type EAP-Packet, containing an EAP > Failure packet constructed by the Authenticator, is > transmitted to the Supplicant. In the case that > no EAP communication was taking place on the port, then > any value of Id may be used in the identifier field of the > EAP frame. In the case that there was an EAP communication > taking place on the port, then the value of the Identifier > field in the EAP packet is set to a value that is different > from the last delivered EAPOL frame of type EAP-Packet. > >We could add similar text if you like. > It is not stricto sensu a canned success/failure IMO. It's just that although RFC 3748 prevents IMHO a stupid server to directly start an authentication by sending a failure (not very explicitly, perhaps see the beginning of section 2 of RFC 3748 but it doesn't sound very normative or section 4.2 of RFC 3748), figure 4 relies on the policy (policy.getdecision) to avoid this behavior... and I think this is worse stating that the authenticator's policy must comply to this! I have problems to understand the .1X text: does it authorize a valid authenticator to send directly a failure message ("in the case that no EAP communication was taking place on the port, then any value of Id may be used in the identifier field of the EAP frame") could you please clarify it for my poor brain? >>Comment #14 - Technical >> >>I am totally novice to DoS (I found a lot of papers on the subject, for >>instance related to IKE - I plan to read them soon :-)) so this point is >>probably not very important (my understanding is that one of the >>difficulties with DoS is to understand what is really relevant and what >>rather belongs to the .11 microwave oven attack, another one could be >>set the trade off between DoS resilience and "efficiency"). >> >>It just seems to me that Figure 4 prevents the standalone authenticator >>from ignoring (bogus) NAKs. Indeed, let us consider a corporate WLAN >>deployment where exactly one EAP method is allowed - so that no valid >>user will ever NAK. In this setting, there is no point in processing the >>NAK, possibly loosing the valid user's response if the attacker's NAK >>arrived first and starting all over. I did not find text on this in RFC >>3748 (the text I found was about preventing NAKs when a response to a >>method has already been received) which is not our case here. >> >> >Using forged Naks as a DoS is a known attack against EAP AFAIK. The DoS >attack is mitigated by the case you mention (not allowing after non-Nak >response has been received) > This is not the case I mention!! I precisely mention the case, when the server has sent his initial request and an attacker replies with a NAKs before the peer replies with the correct response. In this scenario, IINM, although the server may be sure that a valid peer won't NAK (a policy decision), figure 4 mandates that it processes the NAK. I find it an unnecessary open a door to a stupid & useless & inefficient DoS (and when one cans close such doors without much trouble, then I recommend closing them although the DoS attack is not dramatic). So my proposed resolution is to allow the policy to set methodstate directly to CONTINUE (while still authorizing it to set the state to PROPOSED) in the PROPOSE_METHOD state. What do you think? >>Comment #17 - Technical >> >>I fail to understand the transition in Figure 7 from >>INITIALIZE_PASSTHROUGH to AAA_IDLE when currentId==None, given that >>AAA_IDLE sets aaaEapResp=TRUE >> >> >I think the point here is that aaaEapResp is telling the lower layer that >it's time for that layer to do something. In this case, no packets have >been sent from anyone so the lower layer will see aaaEapRespData is NONE >and know to start. At least I *think* this is what's going on. Others may >be able to correct me. > well, according to the definition of aaaEapResp (section 7.1.1 "Set to TRUE in lower layer, FALSE in authenticator state machine. Indicates an EAP response is available for processing."), aaaEapResp is *not* a vague flag to say to the lower layer to do to do something but a precise flag to say to it that it has a response available for processing. So I still hold onto this issue. It arises when an authenticator boots and decides directly that it will be pass-through whatever the id of the peer (this behavior appears to be allowed by the state machine). I think it needs a fix. Perhaps I'm off the rocket but then I would like to be enlightened (if somebody thinks I am able to understand the explanation ;-)) _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jun 25 11:17:44 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08978 for ; Fri, 25 Jun 2004 11:17:43 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CF72B1FF77; Fri, 25 Jun 2004 11:04:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F3BD820CCE; Fri, 25 Jun 2004 11:04:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AFAD520CCE for ; Fri, 25 Jun 2004 11:03:29 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by mail.frascone.com (Postfix) with ESMTP id 8470C20CAC for ; Fri, 25 Jun 2004 11:03:27 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 25 Jun 2004 17:17:00 +0200 Received: from rd.francetelecom.fr ([10.193.106.16]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Fri, 25 Jun 2004 17:16:58 +0200 Message-ID: <40DC42CF.1070109@rd.francetelecom.fr> From: Florent Bersani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nick Petroni Cc: "eap@frascone.com" Subject: Re: [eap] [Issue 247] Comments on EAP state machine v4 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jun 2004 15:16:59.0118 (UTC) FILETIME=[759928E0:01C45AC7] 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, 25 Jun 2004 17:20:47 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit A few ad-hoc thoughts in-line ;-) Nick Petroni wrote: >hope that others chime in with their opinions as >well. > So do I ;-) >I would caution that AAA != RADIUS. There are other possibilities. > > I agree >I agree the AP must >parse some amount of the response, possibly even all of it since it did >send the initial request. However, If you look at the AAA-EAP draft >http://www.ietf.org/internet-drafts/draft-ietf-aaa-eap-08.txt >you will see on pages 4 and 5 some discussion of this topic. My guess is >it is *this* text that was the motivation for the passing of the entire >packet. > >A quick highlight of the text: > > A preferred approach is for the access device to issue the > EAP-Request/Identity message to the EAP client, and forward the > EAP-Response/Identity packet, encapsulated within the EAP-Payload > AVP, as a Diameter-EAP-Request to the Diameter server (see the > diagram below). This alternative reduces the number of Diameter > message round trips. When the EAP-Request/Identity message is issued > by the access device, it SHOULD interpret the EAP-Response/Identity > packet returned by the authenticating peer, and copy its value to a > User-Name AVP in Diameter-EAP-Request. This is useful in roaming > environments, since the Destination-Realm is needed for routing > purposes. Note that this alternative cannot be universally employed, > as there are circumstances where a user's identity is not needed > (such as when authorization occurs based on a calling or called phone > number). > > User NAS Server > | | | > | (initiate EAP) | | > |<------------------------------>| | > | | | > | EAP Request(Identity) | | > |<-------------------------------| | > | | | > | EAP Response(Identity) | | > |------------------------------->| | > | | Diameter-EAP-Request | > | | EAP-Payload(EAP Response) | > | |------------------------------->| > : : : > : ...continues... : > > > I believe that your text backs my point: since the authenticator already sends the whole EAP packet to the AS in aaaEapRespData, I do not yet see the point in passing the whole EAP packet to aaaIdentity (and not only the identity). The behavior I described with RADIUS is the one quoted in your text with DIAMETER. However, as "the one who does more can do less", there is no critical technical reason to prevent aaaIdentity from being the whole packet and not only the identity field. This issue is *editorial* and I won't fight for it. It's just that 1) to the average reader I am, when I read the actions of the AAA_REQUEST state in figure 7, namely aaaIdentity = eapRespData ; aaaEapRespData = eapRespData, I find it weird to instantiate two variables that take the same value 2) from an interface perspective, if you set aaaIdentity to a whole EAP packet, then the AAA layer has to parse the EAP packet to recover the identity wherehas if you set it aaaIdentity to identity, the AAA layer has no parsing to do, just encapsulation. I find the latter cleaner. BTW, I haven't yet read the draft you pointed me to. So I'll read it this WE and come back with perhaps more educated thoughts. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jun 25 11:23:44 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10208 for ; Fri, 25 Jun 2004 11:23:43 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 97B85211B0; Fri, 25 Jun 2004 11:10:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1492320AA6; Fri, 25 Jun 2004 11:10:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 46EF220AA6 for ; Fri, 25 Jun 2004 11:10:00 -0400 (EDT) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id 9B95D1FF77 for ; Fri, 25 Jun 2004 11:09:58 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id i5PFNVT1029665; Fri, 25 Jun 2004 11:23:31 -0400 (EDT) From: Nick Petroni To: Florent Bersani Cc: "eap@frascone.com" Subject: Re: [eap] [Issue 247] Comments on EAP state machine v4 In-Reply-To: <40DC42CF.1070109@rd.francetelecom.fr> 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: Fri, 25 Jun 2004 11:23:31 -0400 (EDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > I believe that your text backs my point: since the authenticator already > sends the whole EAP packet to the AS in aaaEapRespData, I do not yet see > the point in passing the whole EAP packet to aaaIdentity (and not only > the identity). The behavior I described with RADIUS is the one quoted in > your text with DIAMETER. Ok, I'm sorry. I misread the original comment. I think you are correct, the aaaIdentity probably makes more sense as just that portion of the response. Any others have opinions? > BTW, I haven't yet read the draft you pointed me to. So I'll read it > this WE and come back with perhaps more educated thoughts. Don't bother, I misread the comment. thanks, nick _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jun 25 11:40:01 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12360 for ; Fri, 25 Jun 2004 11:40:00 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5253B1FEE3; Fri, 25 Jun 2004 11:26:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0AE8020240; Fri, 25 Jun 2004 11:26:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9134A2042E for ; Fri, 25 Jun 2004 11:25:39 -0400 (EDT) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id E488E20240 for ; Fri, 25 Jun 2004 11:25:37 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id i5PFdDT1000042; Fri, 25 Jun 2004 11:39:14 -0400 (EDT) From: Nick Petroni To: Florent Bersani Cc: "eap@frascone.com" Subject: Re: [eap] [Issue 248] Comments on EAP state machine v4 In-Reply-To: <40DC4034.6000005@rd.francetelecom.fr> 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: Fri, 25 Jun 2004 11:39:13 -0400 (EDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > Although I disagree stricto sensu with this example (the peer will not > receive a DHCP request, IINM, it will send one), I essentially agree > with you: I confused alternate lower layer indications and protected > method indications. Typically, no, it would not receive a DHCP request. However, you are thinking of a particular scenario (Roaming client == EAP Peer). I know of no strict mapping that this must occur. There can certainly be cases, at least theoretically, where the entity playing the role of EAP Peer provides some sort of network service. The authenticator's use of that service could serve as an "alternate indication of success." That service COULD be DHCP, although I don't know why it would be. Anyway, as you say, it's not important to the conversation. We both understand. > >>Comment #10 - Technical > >> > >>Why include a separate TIMEOUT_FAILURE State? Why not use the FAILURE state? > >> > >> > >This is because the symptom is that a requeste has been sent, but no > >response received. My recollection is that it was discussed and determined > >that EAP should not send a Failure in response to this symptom, it should > >simply stop trying. > > > Thx for the explanation (and sorry I missed it in the archives). Why not > include it in the document? We could. I see no reason why this can't be added. > >Using forged Naks as a DoS is a known attack against EAP AFAIK. The DoS > >attack is mitigated by the case you mention (not allowing after non-Nak > >response has been received) > > > This is not the case I mention!! I know it isn't. My point is, that this DoS is known and well understood. Furthermore, the ONLY mitigation of Nak DoS is the one both you and I described. > I precisely mention the case, when the server has sent his initial > request and an attacker replies with a NAKs before the peer replies with > the correct response. In this scenario, IINM, although the server may be However, the server has no way to know the Peer was not a valid peer. Think about a new person trying to use the network or simply someone using the wrong configuration file for their peer software. Even legacy software that doesn't support the deployed method could be an issue. If they send a Nak and get NO RESPONSE this would make for difficult debugging. Sending a Nak at this point is valid and they should at least receive a Failure to indicate that their proposal was rejected. > sure that a valid peer won't NAK (a policy decision), figure 4 mandates > that it processes the NAK. I find it an unnecessary open a door to a > stupid & useless & inefficient DoS (and when one cans close such doors > without much trouble, then I recommend closing them although the DoS > attack is not dramatic). So my proposed resolution is to allow the > policy to set methodstate directly to CONTINUE (while still authorizing > it to set the state to PROPOSED) in the PROPOSE_METHOD state. What do > you think? I think this is not a useful mitigation. The reason is simple- an attacker can still spoof a Failure packet in the opposite direction at almost any point for just as easy a DoS. Even if you are using a smart method, there will be a window when the attacker can sneak in a Failure in most environments. I think the general rule of "it's no worse than a DoS that we know we can't mitigate so why mitigate this one." Furthermore, IMHO the protocol issue discussed above is all the more reason not to disallow Naks at this point. Some implementations may do so, but I don't see the value of mitigating this particular attack in the SM. > >>Comment #17 - Technical > >> > >>I fail to understand the transition in Figure 7 from > >>INITIALIZE_PASSTHROUGH to AAA_IDLE when currentId==None, given that > >>AAA_IDLE sets aaaEapResp=TRUE > >> > >> > >I think the point here is that aaaEapResp is telling the lower layer that > >it's time for that layer to do something. In this case, no packets have > >been sent from anyone so the lower layer will see aaaEapRespData is NONE > >and know to start. At least I *think* this is what's going on. Others may > >be able to correct me. > > > well, according to the definition of aaaEapResp (section 7.1.1 "Set to > TRUE in lower layer, FALSE in authenticator state machine. Indicates an > EAP response is available for processing."), aaaEapResp is *not* a vague > flag to say to the lower layer to do to do something but a precise flag > to say to it that it has a response available for processing. > So I still hold onto this issue. It arises when an authenticator boots > and decides directly that it will be pass-through whatever the id of the > peer (this behavior appears to be allowed by the state machine). I think > it needs a fix. What is the issue precisely? The problem as I see it is if you DON'T set aaaEapResp in AAA_IDLE then you will just hang waiting for the lower layer when it doesn't know that it's its turn. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jun 25 11:48:43 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14213 for ; Fri, 25 Jun 2004 11:48:42 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 41CE01FEE3; Fri, 25 Jun 2004 11:35:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A26572042E; Fri, 25 Jun 2004 11:35:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2AAE92042E for ; Fri, 25 Jun 2004 11:34:37 -0400 (EDT) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id 1870B1FEE3 for ; Fri, 25 Jun 2004 11:34:35 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id i5PFmBT1000211; Fri, 25 Jun 2004 11:48:11 -0400 (EDT) From: Nick Petroni To: Florent Bersani Cc: "eap@frascone.com" Subject: Re: [eap] [Issue 248] Comments on EAP state machine v4 In-Reply-To: <40DC4034.6000005@rd.francetelecom.fr> 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: Fri, 25 Jun 2004 11:48:11 -0400 (EDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > >>Comment #12 - Technical > >> > >>This one is stupid but what happens, according to Figure 4, when the > >>standalone authenticator fails directly, i.e. starts by INITIALIZE, > >>transitions to SELECT_ACTION where Policy.getDecision replies FAILURE > >>and thus transitions to FAILURE - in the FAILURE state, I bet there is > >>some problem with eapReqData = buildFailure(currentId) since currentId=NONE > >> > >> > >This is a problem with Canned Success/Failure in general since only > >Requests modify the Identifier field. IEEE 802-1X-REV states the following > >in 8.2.4.1.3: > > txCannedFail. An EAPOL frame of type EAP-Packet, containing an EAP > > Failure packet constructed by the Authenticator, is > > transmitted to the Supplicant. In the case that > > no EAP communication was taking place on the port, then > > any value of Id may be used in the identifier field of the > > EAP frame. In the case that there was an EAP communication > > taking place on the port, then the value of the Identifier > > field in the EAP packet is set to a value that is different > > from the last delivered EAPOL frame of type EAP-Packet. > > > >We could add similar text if you like. > > > It is not stricto sensu a canned success/failure IMO. It's not? I definitely do not understand then. I define canned failure as without any previous packets the authenticator decids failure will be sent and sends it without any other EAP conversation. > It's just that although RFC 3748 prevents IMHO a stupid server to > directly start an authentication by sending a failure (not very > explicitly, perhaps see the beginning of section 2 of RFC 3748 but it > doesn't sound very normative or section 4.2 of RFC 3748), figure 4 > relies on the policy (policy.getdecision) to avoid this behavior... and > I think this is worse stating that the authenticator's policy must > comply to this! I don't see the RFC as denying the use of immediate failure. The behavior is valid IMHO. > I have problems to understand the .1X text: does it authorize a valid > authenticator to send directly a failure message ("in the case that no > EAP communication was taking place on the port, then any value of Id may > be used in the identifier field of the EAP frame") could you please > clarify it for my poor brain? The Failure or Success messages in EAP use the last valid Identifier value from the EAP conversation. However, this text is referring to the case where no EAP conversation took place, you are just sending a Failure. This is termed a canned failure, and I think this is the case you were describing. The 802.1X-REV document states that ANY Identifier is valid for Failure in that case (and similarly for canned success). Perhaps you can distinguish your case from the "canned" case for a slow person like myself? Sorry I'm not getting it yet. Regards, nick _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jun 25 12:20:43 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19882 for ; Fri, 25 Jun 2004 12:20:42 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E7F701FED2; Fri, 25 Jun 2004 12:07:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8544520CC8; Fri, 25 Jun 2004 12:07:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 22CDA20CC8 for ; Fri, 25 Jun 2004 12:06:02 -0400 (EDT) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id 6F1E21FED2 for ; Fri, 25 Jun 2004 12:06:00 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id i5PGJZT1000909; Fri, 25 Jun 2004 12:19:36 -0400 (EDT) From: Nick Petroni To: Florent Bersani Cc: "eap@frascone.com" Subject: Re: [eap] [Issue 248] Comments on EAP state machine v4 In-Reply-To: <40DC4034.6000005@rd.francetelecom.fr> 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: Fri, 25 Jun 2004 12:19:35 -0400 (EDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > >I'm sorry, I don't quite understand how you would like to resolve this > >issue. I *think* you want more guidelines for how a method could implement > >certain types of error processing for things like possible DoS attacks > >etc. Is this correct? > > > > > To clarify what I meant, this is related to comment #6 of this thread > and comment #1 of my mail on EAP (see > http://mail.frascone.com/pipermail/public/eap/2004-June/002531.html). > > In short, since altAccept and altReject are set by the lower layer and > not by the EAP method (*), there is no way for the method to fail more > quickly than a time out IINM. Why is there not? Can't the method just not "ignore" the packet and instead return FAIL? I think I am missing something. > Indeed, suppose we are in a method exchange (any resemblance to EAP-PSK > is purely incidental ;-)) where the peer waits for the server to > authenticate to it, that is the peer waits for a MAC=MIC produced by the > server. The peer receives request #1 containing such a MAC=MIC. As this > MAC=MIC is invalid, the peer discards thanks to m.check and waits for > another request. > The question was: in case the peer considered this reception of an > invalid MAC as a critical failure and wants to fail immediately i.e. > without processing any other packet (despite the DoS issues associated > with this behavior), how does he(***) do? My answer from the EAP state > machine figure 3 of the strawman4 version is that he can't! To avoid I see. The peer is inherently powerless in EAP. What he CAN do is to end this conversation and start a new one. To end the current conversation, the peer can simply not "ignore" the packet, make decision == FAIL, and methodSate == DONE. > processing any new requests, he updates his m.check function to answer > TRUE whatever the input (or sets methodstate to DONE) and waits for the > time out, that's his best option (this comes from the examination of the why does he wait for the timeout? There is a direct transition from METHOD to FAILURE with no condition for timeout. No? I am referring to the rightmost transition in the diagram. > portEnabled or eapRestart (the lower layer does). I think that not > allowing the method to quickly transition to SUCCESS or FAILURE is a bad > restriction. What do you think? Is that the case? I don't see it that way. Maybe I am looking at the wrong diagram?? I am looking at Figure 3. > To keep on expanding my thoughts on the problem, the only parameter the > method has IINM to influence the success or failure of EAP is the > methodstate (****) and decision variables (*****). It is a pity that > decision is always associated to idlewhile in the transitions to SUCCESS > or FAILURE, don't you think? This has surely to do with the choice to I am REALLY lost here. There are a number of transitions to both FAILURE and SUCCESS that do NOT depend on idleWhile. The method shouldn't need more than to say whether or not it's done and what its decision was. Why it failed is of no concern to the EAP layer. > (**) BTW do we have an example of indication of the data link that it is > up? (I see examples of link down, e.g. a dial-up NAS hangs up) > I do not think that your DHCP example works as it is, IIRC, the peer > that first sends the DHCP request. So to understand that the > authentication succeeded from this, the peer would have to keep trying > sending DHCP requests while authenticating and understand it has > succeeded when it gets a response. Am I right? Perhaps, sth around DNA? I remember some discussion about examples of alternate indications. I don't recall them all, but I know EAPoL Key packets are possible examples of data link up. There are a number of possible data indications here, or even specific link-layer indications. > (***) BTW, would a native English speaker or an educated foreigner tell > me what is the correct pronoun to use when talking of the peer: it or he > or both? My opinion is it's a matter of style. The peer is strictly an 'it', but there is generally some idea that a 'he' or a 'she' is operating the machine ;). > (****) BTW, I think I have two other issues here: > 1) allowMethod is not defined in the document IINM but is used in figure 3 yes. another good catch. > 2) I did not find a place in RFC 3748 saying that it is forbidden to > have multiple round trips of the Identity method. If this is the case, > the state machine reflects this... sadly, this leads to an unnecessary > (& stupid & not dramatic) DoS attack: the attacker keeps sending EAP > Identity request and the peer may keep replying to these requests (and > discarding the valid requests of the server). I thought about this when > talking about the methodstate variable and noticing that there was a > difference between Identity/Notification (which are from a theoretical > POV two methods) and the other methods. Namely, while the identity and > notification methods do not impact the methodstate variable nor the > decision one... > I'll post these issues in a separate mail for those who won't have read > this lengthy one (I very much understand them ;-)) > As I said before, if you are looking for DoS mitigation from stray messages, EAP is not the place for you. My understanding is that you can repeat Identity requests within the protocol, yes. But at this point you could have just sent a Failure and ended the conversation anyway, so an attacker is not much helped by this fact IMHO. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jun 25 12:30:42 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20221 for ; Fri, 25 Jun 2004 12:30:41 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1468C1FED2; Fri, 25 Jun 2004 12:17:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BBE61202AA; Fri, 25 Jun 2004 12:17:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4FCC0202AA for ; Fri, 25 Jun 2004 12:16:09 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by mail.frascone.com (Postfix) with ESMTP id 1DD291FED2 for ; Fri, 25 Jun 2004 12:16:07 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 25 Jun 2004 18:29:38 +0200 Received: from rd.francetelecom.fr ([10.193.106.16]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Fri, 25 Jun 2004 18:29:37 +0200 Message-ID: <40DC53D5.7060403@rd.francetelecom.fr> From: Florent Bersani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nick Petroni Cc: "eap@frascone.com" Subject: Re: [eap] [Issue 248] Comments on EAP state machine v4 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jun 2004 16:29:37.0373 (UTC) FILETIME=[9B5218D0:01C45AD1] 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, 25 Jun 2004 18:33:25 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Some more in-line Nick Petroni wrote: > There can certainly be cases, at >least theoretically, where the entity playing the role of EAP Peer >provides some sort of network service. > > Thx here is the alternate success indication I was looking for :-) >>I precisely mention the case, when the server has sent his initial >>request and an attacker replies with a NAKs before the peer replies with >>the correct response. In this scenario, IINM, although the server may be >> >> >However, the server has no way to know the Peer was not a valid peer. >Think about a new person trying to use the network or simply someone using >the wrong configuration file for their peer software. Even legacy >software that doesn't support the deployed method could be an issue. If >they send a Nak and get NO RESPONSE this would make for difficult >debugging. Sending a Nak at this point is valid and they should at least >receive a Failure to indicate that their proposal was rejected. > > I was talking here of a specific (though probably widespread) case: a corporation BigCo providing wireless access to its employees. Since BigCo is a great corporation, it knows that all its employees use EAP-TLS: so whoever tries to connect, if it is a valid employee, it will use EAP-TLS > > >>sure that a valid peer won't NAK (a policy decision), figure 4 mandates >>that it processes the NAK. I find it an unnecessary open a door to a >>stupid & useless & inefficient DoS (and when one cans close such doors >>without much trouble, then I recommend closing them although the DoS >>attack is not dramatic). So my proposed resolution is to allow the >>policy to set methodstate directly to CONTINUE (while still authorizing >>it to set the state to PROPOSED) in the PROPOSE_METHOD state. What do >>you think? >> >> >I think this is not a useful mitigation. > I disagree >The reason is simple- an attacker >can still spoof a Failure packet in the opposite direction at almost any >point for just as easy a DoS. > Right but this is a different problem that has a different mitigation (namely the protected result indication by the method and/or the decision/methodstate variable that allows to silently discard the bogus failure/success message) >Even if you are using a smart method, there >will be a window when the attacker can sneak in a Failure in most >environments. > I strongly disagree here: are you talking about protocols (then I'd like more precisions because I think it will be hard to demonstrate what you say ;-)) or about implementations (then I think this is out of scope since our main focus is not what people do or how they do it but rather what they should do, isn't it?) >I think the general rule of "it's no worse than a DoS that >we know we can't mitigate so why mitigate this one." > I won't engage in a big fight either here. I think this is a minor issue and that it is easy to solve. If people don't want to solve it (because they think the resolution costs more than the issue), I respect that although i disagree >Furthermore, IMHO the >protocol issue discussed above is all the more reason not to disallow >Naks at this point. > I didn't say that we should disallow them but allow them to be disallowed (i.e. silently discarded) according to a policy! >>>>Comment #17 - Technical >>>> >>>>I fail to understand the transition in Figure 7 from >>>>INITIALIZE_PASSTHROUGH to AAA_IDLE when currentId==None, given that >>>>AAA_IDLE sets aaaEapResp=TRUE >>>> >>>> >>>> >>>> >>>I think the point here is that aaaEapResp is telling the lower layer that >>>it's time for that layer to do something. In this case, no packets have >>>been sent from anyone so the lower layer will see aaaEapRespData is NONE >>>and know to start. At least I *think* this is what's going on. Others may >>>be able to correct me. >>> >>> >>> >>well, according to the definition of aaaEapResp (section 7.1.1 "Set to >>TRUE in lower layer, FALSE in authenticator state machine. Indicates an >>EAP response is available for processing."), aaaEapResp is *not* a vague >>flag to say to the lower layer to do to do something but a precise flag >>to say to it that it has a response available for processing. >>So I still hold onto this issue. It arises when an authenticator boots >>and decides directly that it will be pass-through whatever the id of the >>peer (this behavior appears to be allowed by the state machine). I think >>it needs a fix. >> >> >What is the issue precisely? > you say to AAA that you have a response to send (aaaEspResp=TRUE) when you don't (aaaRespData=NONE). Apart from this IMHO unsatisfactory behavior, I think this is leaving the door open to buggy implementations (think of somebody who will send sth as soon as aaaEspResp=TRUE with encapsulated whatever garbage was in memory for aaaRespData (i.e. missing that aaaRespData=NONE) > The problem as I see it is if you DON'T set >aaaEapResp in AAA_IDLE then you will just hang waiting for the lower layer >when it doesn't know that it's its turn. > > I agree : my problem is not with the state but the transition from INITIALIZE_PASSTHROUGH to AAA_IDLE with currentid==NONE Did I clarify? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jun 25 12:39:44 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20705 for ; Fri, 25 Jun 2004 12:39:43 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AD0FE20ED4; Fri, 25 Jun 2004 12:26:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 404692042E; Fri, 25 Jun 2004 12:26:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EF28B2042E for ; Fri, 25 Jun 2004 12:25:18 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by mail.frascone.com (Postfix) with ESMTP id C170A20320 for ; Fri, 25 Jun 2004 12:25:16 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 25 Jun 2004 18:38:49 +0200 Received: from rd.francetelecom.fr ([10.193.106.16]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Fri, 25 Jun 2004 18:38:48 +0200 Message-ID: <40DC55FD.9030802@rd.francetelecom.fr> From: Florent Bersani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nick Petroni Cc: "eap@frascone.com" Subject: Re: [eap] [Issue 248] Comments on EAP state machine v4 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jun 2004 16:38:48.0884 (UTC) FILETIME=[E40BFF40:01C45AD2] 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, 25 Jun 2004 18:42:37 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Some more in-line Nick Petroni wrote: >>>>Comment #12 - Technical >>>> >>>>This one is stupid but what happens, according to Figure 4, when the >>>>standalone authenticator fails directly, i.e. starts by INITIALIZE, >>>>transitions to SELECT_ACTION where Policy.getDecision replies FAILURE >>>>and thus transitions to FAILURE - in the FAILURE state, I bet there is >>>>some problem with eapReqData = buildFailure(currentId) since currentId=NONE >>>> >>>> >>>> >>>> >>>This is a problem with Canned Success/Failure in general since only >>>Requests modify the Identifier field. IEEE 802-1X-REV states the following >>>in 8.2.4.1.3: >>> txCannedFail. An EAPOL frame of type EAP-Packet, containing an EAP >>> Failure packet constructed by the Authenticator, is >>> transmitted to the Supplicant. In the case that >>> no EAP communication was taking place on the port, then >>> any value of Id may be used in the identifier field of the >>> EAP frame. In the case that there was an EAP communication >>> taking place on the port, then the value of the Identifier >>> field in the EAP packet is set to a value that is different >>> from the last delivered EAPOL frame of type EAP-Packet. >>> >>>We could add similar text if you like. >>> >>> >>> >>It is not stricto sensu a canned success/failure IMO. >> >> >It's not? I definitely do not understand then. I define canned failure as >without any previous packets the authenticator decids failure will be sent >and sends it without any other EAP conversation. > > OK I defined canned success/failure as a success/failure maliciously inserted by an attacker; According to my definition, we were not talking of canned success since it was a valid authenticator that sent the failure >>It's just that although RFC 3748 prevents IMHO a stupid server to >>directly start an authentication by sending a failure (not very >>explicitly, perhaps see the beginning of section 2 of RFC 3748 but it >>doesn't sound very normative or section 4.2 of RFC 3748), figure 4 >>relies on the policy (policy.getdecision) to avoid this behavior... and >>I think this is worse stating that the authenticator's policy must >>comply to this! >> >> >I don't see the RFC as denying the use of immediate failure. The behavior >is valid IMHO. > > To be honest, I started the mail you replied to by lamenting that this was not mandated by EAP (which you tend to think) but after rereading RFC 3748 (I stumbled across some wording like "The EAP authentication exchange proceeds as follows: [1] The authenticator sends a Request to authenticate the peer." RFC 3748 page 7). So, although it didn't seem like very normative text, I changed my mind and now think that EAP mandates that a dialog begins with a request. I'd really like others' opinion on this, Bernard, Jari? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jun 25 12:51:43 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21960 for ; Fri, 25 Jun 2004 12:51:42 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A063020CDB; Fri, 25 Jun 2004 12:38:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1F62C20CDF; Fri, 25 Jun 2004 12:38:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 622E420CDF for ; Fri, 25 Jun 2004 12:37:25 -0400 (EDT) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id B781C20CDB for ; Fri, 25 Jun 2004 12:37:23 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id i5PGoxT1001569; Fri, 25 Jun 2004 12:50:59 -0400 (EDT) From: Nick Petroni To: Florent Bersani Cc: "eap@frascone.com" Subject: Re: [eap] [Issue 248] Comments on EAP state machine v4 In-Reply-To: <40DC53D5.7060403@rd.francetelecom.fr> 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: Fri, 25 Jun 2004 12:50:59 -0400 (EDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > I was talking here of a specific (though probably widespread) case: a > corporation BigCo providing wireless access to its employees. > Since BigCo is a great corporation, it knows that all its employees use > EAP-TLS: so whoever tries to connect, if it is a valid employee, it will > use EAP-TLS I get it. I always have. You don't have to convince me of the scenario. I think I am just saying there is an equally devastating attack of sending a Failure to the peer instead of a Nak to the Authenticator. > >The reason is simple- an attacker > >can still spoof a Failure packet in the opposite direction at almost any > >point for just as easy a DoS. > > > Right but this is a different problem that has a different mitigation > (namely the protected result indication by the method and/or the > decision/methodstate variable that allows to silently discard the bogus > failure/success message) Protected result indications are METHOD SPECIFIC. you have not started the method at the point when your 'invalid Nak insertion' attack takes place. You will notice on the Peer that the methodState variable is initialized to NONE. Therefore, if immediately after (or before) an Identity exchange the attacker forges a Failure the Peer MUST accept it. > >Even if you are using a smart method, there > >will be a window when the attacker can sneak in a Failure in most > >environments. > > > I strongly disagree here: are you talking about protocols (then I'd like > more precisions because I think it will be hard to demonstrate what you > say ;-)) or about implementations (then I think this is out of scope > since our main focus is not what people do or how they do it but rather > what they should do, isn't it?) No, this is a protocol issue. There is a window of opportunity at the beginning where a Failure can be spoofed, just like there is the window you describe where a Nak can be. The only protection from injected Failures is methodState == CONT, which it does NOT start out as. Some methods DO NOT indicate when they are done, and in fact the peer may not even be able to know if they are. > >Furthermore, IMHO the > >protocol issue discussed above is all the more reason not to disallow > >Naks at this point. > > > I didn't say that we should disallow them but allow them to be > disallowed (i.e. silently discarded) according to a policy! I know. I think we can agree to disagree and let others weigh in. [Comment 17] > >What is the issue precisely? > > > you say to AAA that you have a response to send (aaaEspResp=TRUE) when > you don't (aaaRespData=NONE). No, you do not. YOu have a respnse *received*. This makes all the difference in the world. Authenticators *receive* responses and *send* requests. Requests are generated by the lower layer. If you do not tell the lower layer that it's time to go, you will hang forever. > Apart from this IMHO unsatisfactory behavior, I think this is leaving > the door open to buggy implementations (think of somebody who will send > sth as soon as aaaEspResp=TRUE with encapsulated whatever garbage was in > memory for aaaRespData (i.e. missing that aaaRespData=NONE) send what? Eap Responses are PROCESSED by the lower layer, not SENT. if the data is NONE then there will be nothing to process. eapRespData is properly initialized, so your argument that there's garbage there is a bad one. We can't account for people ignoring variables IMHO. > Did I clarify? Did I? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jun 25 12:53:42 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22177 for ; Fri, 25 Jun 2004 12:53:42 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5C2BB211AE; Fri, 25 Jun 2004 12:40:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0591120ED2; Fri, 25 Jun 2004 12:40:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D5C8920ED2 for ; Fri, 25 Jun 2004 12:39:21 -0400 (EDT) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id 3AAD32042E for ; Fri, 25 Jun 2004 12:39:20 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id i5PGquT1001589; Fri, 25 Jun 2004 12:52:56 -0400 (EDT) From: Nick Petroni To: Florent Bersani Cc: "eap@frascone.com" Subject: Re: [eap] [Issue 248] Comments on EAP state machine v4 In-Reply-To: <40DC55FD.9030802@rd.francetelecom.fr> 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: Fri, 25 Jun 2004 12:52:56 -0400 (EDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > OK I defined canned success/failure as a success/failure maliciously > inserted by an attacker; According to my definition, we were not talking > of canned success since it was a valid authenticator that sent the failure Can we agree on my terminology and call your version a "forged" one? I think mine is much closer to common usage, if not dead on for the word "canned". Regards, nick _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jun 25 13:00:43 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22669 for ; Fri, 25 Jun 2004 13:00:42 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id ACD11211AE; Fri, 25 Jun 2004 12:43:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9945F20F43; Fri, 25 Jun 2004 12:43:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 61BBD20DDE for ; Fri, 25 Jun 2004 12:42:17 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by mail.frascone.com (Postfix) with ESMTP id 0C2BF1FEDB for ; Fri, 25 Jun 2004 12:42:13 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 25 Jun 2004 18:55:44 +0200 Received: from rd.francetelecom.fr ([10.193.106.16]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Fri, 25 Jun 2004 18:55:42 +0200 Message-ID: <40DC59F3.4010000@rd.francetelecom.fr> From: Florent Bersani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nick Petroni Cc: "eap@frascone.com" Subject: Re: [eap] [Issue 248] Comments on EAP state machine v4 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jun 2004 16:55:42.0919 (UTC) FILETIME=[40757570:01C45AD5] 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, 25 Jun 2004 18:59:31 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Some more in-line to clarify: I had missed the transition :-(( Nick Petroni wrote: >>processing any new requests, he updates his m.check function to answer >>TRUE whatever the input (or sets methodstate to DONE) and waits for the >>time out, that's his best option (this comes from the examination of the >> >> >why does he wait for the timeout? There is a direct transition from METHOD >to FAILURE with no condition for timeout. No? I am referring to the >rightmost transition in the diagram. > > Ooooooooooooops, sorry I had missed that one :-( All my apologies, sorry for the time i made you loose :-( and many thanks for your patience and clarity But my point could still apply to a peer that would like to transition quickly to success. Here, the difference is probably that the expected behavior of the peer is to wait for a success and if it doesn't receive one, then if it has had a protected result indication transition to success. So I don't think my point is very interesting in this case :-( >>2) I did not find a place in RFC 3748 saying that it is forbidden to >>have multiple round trips of the Identity method. If this is the case, >>the state machine reflects this... sadly, this leads to an unnecessary >>(& stupid & not dramatic) DoS attack: the attacker keeps sending EAP >>Identity request and the peer may keep replying to these requests (and >>discarding the valid requests of the server). I thought about this when >>talking about the methodstate variable and noticing that there was a >>difference between Identity/Notification (which are from a theoretical >>POV two methods) and the other methods. Namely, while the identity and >>notification methods do not impact the methodstate variable nor the >>decision one... >>I'll post these issues in a separate mail for those who won't have read >>this lengthy one (I very much understand them ;-)) >> >> >> >As I said before, if you are looking for DoS mitigation from stray >messages, EAP is not the place for you. My understanding is that you can >repeat Identity requests within the protocol, yes. But at this point you >could have just sent a Failure and ended the conversation anyway, so an >attacker is not much helped by this fact IMHO. > > Hummm I had understood that EAP left many doors open for abuses... and I agree it is probably too late to try and fix them (and probably not worth it) But I deeply regret that So here is another stupid scenario: 1) The valid server sends EAPrequest identity 2) The valid peer replies with EAP response identity 3) The attacker sends Failure to the peer In this scenario, for now, whatever the protection of the method the peer wants to use, he fails :-( (again in some scenarios - typically corporate or domestic - this is sth which we could want to avoid) It does not harm much (cf. the easier micro-wave oven attack) but it would not have been that hard to avoid, wouldn'it? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jun 25 13:05:01 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23402 for ; Fri, 25 Jun 2004 13:05:00 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0D87020F24; Fri, 25 Jun 2004 12:49:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9966220271; Fri, 25 Jun 2004 12:49:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C94D11FF93 for ; Fri, 25 Jun 2004 12:48:36 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by mail.frascone.com (Postfix) with ESMTP id 9AB071FEE1 for ; Fri, 25 Jun 2004 12:48:34 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 25 Jun 2004 19:02:08 +0200 Received: from rd.francetelecom.fr ([10.193.106.16]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Fri, 25 Jun 2004 19:02:07 +0200 Message-ID: <40DC5B74.7040500@rd.francetelecom.fr> From: Florent Bersani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nick Petroni Cc: "eap@frascone.com" Subject: Re: [eap] [Issue 248] Comments on EAP state machine v4 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jun 2004 17:02:07.0489 (UTC) FILETIME=[25AE2F10:01C45AD6] 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, 25 Jun 2004 19:05:56 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit More in-line Nick Petroni wrote: > Protected result indications are METHOD SPECIFIC. you have not started the > >method at the point when your 'invalid Nak insertion' attack takes place. >You will notice on the Peer that the methodState variable is initialized >to NONE. Therefore, if immediately after (or before) an Identity exchange >the attacker forges a Failure the Peer MUST accept it. > > Right I just came to this unfortunate conclusion in a mail I've just sent you :-( >[Comment 17] > > >>>What is the issue precisely? >>> >>> >>> >>you say to AAA that you have a response to send (aaaEspResp=TRUE) when >>you don't (aaaRespData=NONE). >> >> >No, you do not. YOu have a respnse *received*. > No you don't IINM I'm talking of Figures 6 and 7: you start in INITIALIZE move with UCT to SELECT_ACTION, take decision PASSTHROUGH, transition to INITIALIZE_PASSTHROUGH, take the transition currentId==NONE and end in AAA_IDLE I don't see the response you have... but I might well be confused as it was the case with the transition I forgot in Figure 3 :-( & ;-) _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jun 25 13:05:42 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23550 for ; Fri, 25 Jun 2004 13:05:42 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3CB5C2038F; Fri, 25 Jun 2004 12:50:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5CC6E206D8; Fri, 25 Jun 2004 12:50:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 510CB20984 for ; Fri, 25 Jun 2004 12:49:20 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by mail.frascone.com (Postfix) with ESMTP id 548852038F for ; Fri, 25 Jun 2004 12:49:18 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 25 Jun 2004 19:02:51 +0200 Received: from rd.francetelecom.fr ([10.193.106.16]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Fri, 25 Jun 2004 19:02:50 +0200 Message-ID: <40DC5B9F.7060003@rd.francetelecom.fr> From: Florent Bersani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nick Petroni Cc: "eap@frascone.com" Subject: Re: [eap] [Issue 248] Comments on EAP state machine v4 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jun 2004 17:02:50.0740 (UTC) FILETIME=[3F75C340:01C45AD6] 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, 25 Jun 2004 19:06:39 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Nick Petroni wrote: >>OK I defined canned success/failure as a success/failure maliciously >>inserted by an attacker; According to my definition, we were not talking >>of canned success since it was a valid authenticator that sent the failure >> >> >Can we agree on my terminology and call your version a "forged" one? I >think mine is much closer to common usage, if not dead on for the word >"canned". > > OK _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jun 25 13:09:45 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24226 for ; Fri, 25 Jun 2004 13:09:44 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9F2291FEDD; Fri, 25 Jun 2004 12:56:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C9EC51FEE8; Fri, 25 Jun 2004 12:56:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EBEC120160 for ; Fri, 25 Jun 2004 12:55:52 -0400 (EDT) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id 4E2881FEDD for ; Fri, 25 Jun 2004 12:55:51 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id i5PH9RT1001998; Fri, 25 Jun 2004 13:09:27 -0400 (EDT) From: Nick Petroni To: Florent Bersani Cc: "eap@frascone.com" Subject: Re: [eap] [Issue 248] Comments on EAP state machine v4 In-Reply-To: <40DC59F3.4010000@rd.francetelecom.fr> 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: Fri, 25 Jun 2004 13:09:27 -0400 (EDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) No worries! I do that kind of stuff all the time. Some more comments... > But my point could still apply to a peer that would like to transition > quickly to success. Here, the difference is probably that the expected > behavior of the peer is to wait for a success and if it doesn't receive > one, then if it has had a protected result indication transition to > success. So I don't think my point is very interesting in this case :-( The peer should not go to success unless he receives notice from the authenticator. I will note that there are conditions into SUCCESS that do not have timers on them, e.g. (rxSuccess && (reqId == lastId) && (decision != FAIL)) and (altAccept && decision != FAIL) The peer cannot spontaneously decide to succeed. Timeout, Success, and altSuccess are it. > Hummm > I had understood that EAP left many doors open for abuses... and I agree > it is probably too late to try and fix them (and probably not worth it) > But I deeply regret that > > So here is another stupid scenario: > 1) The valid server sends EAPrequest identity > 2) The valid peer replies with EAP response identity > 3) The attacker sends Failure to the peer > > In this scenario, for now, whatever the protection of the method the > peer wants to use, he fails :-( (again in some scenarios - typically > corporate or domestic - this is sth which we could want to avoid) > > It does not harm much (cf. the easier micro-wave oven attack) but it > would not have been that hard to avoid, wouldn'it? It is hard to avoid. The peer has to accept certain things based on the protocol at certain times. Perhaps we could have rewritten EAP so that it didn't have to fit the old protocol, but ultimately there would be new places for DoS abuse even in the new version. The peer has no way to authenticate immediate failures since some implementations really do send immediate failures. Think of the case where you mistyped your username. It's likely you would immediately get a Failure, but if you didn't accept it you would just keep trying and never get any further. Furthermore, it would take you a lot longer to determine the Authenticator really doesn't want to authenticate you since you would have to wait for a timeout. It's impossible to distinguish this case from the forged case. Regards, nick _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jun 25 13:10:44 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24436 for ; Fri, 25 Jun 2004 13:10:44 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E2C231FEDD; Fri, 25 Jun 2004 12:57:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6F61A1FEDF; Fri, 25 Jun 2004 12:57:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9CD711FEDF for ; Fri, 25 Jun 2004 12:56:32 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by mail.frascone.com (Postfix) with ESMTP id 66A271FEDD for ; Fri, 25 Jun 2004 12:56:30 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 25 Jun 2004 19:10:05 +0200 Received: from rd.francetelecom.fr ([10.193.106.16]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Fri, 25 Jun 2004 19:10:03 +0200 Message-ID: <40DC5D50.9060303@rd.francetelecom.fr> From: Florent Bersani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba , Jari Arkko Cc: "eap@frascone.com" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jun 2004 17:10:04.0045 (UTC) FILETIME=[41BADBD0:01C45AD7] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Two more issues from the state machine 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, 25 Jun 2004 19:13:52 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Cut and paste from a lenghty mail (http://mail.frascone.com/pipermail/public/eap/2004-June/002553.html): Issue #TBC Submitter name: Florent Bersani Submitter email address: florent.bersani@rd.francetelecom.fr Date first submitted: 06/25/2004 Document: Document Requiring change State Machine Comment type: E Priority: '1' Should fix Rationale/Explanation of issue: allowMethod is not defined in the document IINM but is used in figure 3 Requested change: define it Issue #TBC+1 Submitter name: Florent Bersani Submitter email address: florent.bersani@rd.francetelecom.fr Date first submitted: 06/25/2004 Document: Document Requiring change State Machine Comment type: T Priority: '1' Should fix Rationale/Explanation of issue: I did not find a place in RFC 3748 saying that it is forbidden to have multiple round trips of the Identity method. If this is the case, the state machine reflects this... sadly, this leads to an unnecessary (& stupid & not dramatic) DoS attack: the attacker keeps sending EAP Identity request and the peer may keep replying to these requests (and discarding the valid requests of the server). I thought about this when talking about the methodstate variable and noticing that there was a difference between Identity/Notification (which are from a theoretical POV two methods) and the other methods. Namely, while the identity and notification methods do not impact the methodstate variable nor the decision one... Reply by Nick : I don't see the RFC as denying the use of immediate failure. The behavior is valid IMHO. My reply To be honest, I started the mail you replied to by lamenting that this was not mandated by EAP (which you tend to think) but after rereading RFC 3748 (I stumbled across some wording like "The EAP authentication exchange proceeds as follows: [1] The authenticator sends a Request to authenticate the peer." RFC 3748 page 7). So, although it didn't seem like very normative text, I changed my mind and now think that EAP mandates that a dialog begins with a request. I'd really like others' opinion on this, Bernard, Jari? An addition to my reply Another example of RFC 3748 text that made me change my mind and think a valid EAP authenticator *cannot* start with a success or a failure is located page 23 section 4.2 "The Success packet is sent by the authenticator to the peer after completion of an EAP authentication method" - since this applies only to success, would it mean that although it is not allowed to start with success, one can start with failure? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jun 25 13:22:45 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25933 for ; Fri, 25 Jun 2004 13:22:44 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E24B420F2F; Fri, 25 Jun 2004 13:09:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9A5EF2062D; Fri, 25 Jun 2004 13:09:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E30772062D for ; Fri, 25 Jun 2004 13:08:55 -0400 (EDT) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id 4DA491FEDD for ; Fri, 25 Jun 2004 13:08:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id i5PHMUT1002269; Fri, 25 Jun 2004 13:22:30 -0400 (EDT) From: Nick Petroni To: Florent Bersani Cc: "eap@frascone.com" Subject: Re: [eap] [Issue 248] Comments on EAP state machine v4 In-Reply-To: <40DC5B74.7040500@rd.francetelecom.fr> 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: Fri, 25 Jun 2004 13:22:30 -0400 (EDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > >No, you do not. YOu have a respnse *received*. > > > No you don't IINM > > I'm talking of Figures 6 and 7: you start in INITIALIZE move with UCT to > SELECT_ACTION, take decision PASSTHROUGH, transition to > INITIALIZE_PASSTHROUGH, take the transition currentId==NONE and end in > AAA_IDLE > > I don't see the response you have... but I might well be confused as it > was the case with the transition I forgot in Figure 3 :-( & ;-) OK, again making me be precise ;). No, you did NOT receive a response. The point is, the aaaEapResp variable is meant to tell the lower layer that you have received one. Technically, you have not, but in the case of a brand new connection that has had no packets but ends up in teh AAA_IDLE state you STILL WANT TO SET aaaEAPResp so that the lower layer can build a new request. It will know there was not a response based on the aaaEapRespData. The point I am making is bad implementations cannot just send garbage because they are required to PROCESS the data, not just send it off. The way it works (in very shorthand, please don't make me be more precise) is: Time EAP Layer Lower Layer ==== ========= =========== | Transition to AAA_IDLE | Set aaaEapResp = TRUE | Sees aaaEapResp == TRUE | Sees aaaEapRespData == NONE | Build the first EAP Request | set aaaEapReq | Sees aaaEapReq | sends the request | waits for a response | set aaaEapResp = TRUE | Sees aaaEapResp == TRUE | sees aaaEapRespData is filled | Parses aaaEapRespData | decides whether to send another | request, sets aaaEapReq or | aaaEapNoReq | V Think of it as a handshake between the lower layer and the EAP layer. The lower layer builds requests and waits for responses. the upper layer ships the requests and waits for responses to pass down. Setting aaaEapResp only transitions control to the lower layer so that it can do its thing. Hope this helps. If not, maybe someone else can say it better than me or show me I'm wrong :). Regards, nick _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat Jun 26 05:05:46 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29101 for ; Sat, 26 Jun 2004 05:05:45 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D820A206E9; Sat, 26 Jun 2004 04:52:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 68F8A20490; Sat, 26 Jun 2004 04:52:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 80D5120490 for ; Sat, 26 Jun 2004 04:51:42 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by mail.frascone.com (Postfix) with ESMTP id 4E6381FF6F for ; Sat, 26 Jun 2004 04:51:40 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 26 Jun 2004 11:05:14 +0200 Received: from rd.francetelecom.fr ([10.193.106.29]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Sat, 26 Jun 2004 11:05:13 +0200 Message-ID: <40DD3D2F.6070400@rd.francetelecom.fr> From: Florent Bersani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nick Petroni Cc: "eap@frascone.com" Subject: Re: [eap] [Issue 248] Comments on EAP state machine v4 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jun 2004 09:05:13.0250 (UTC) FILETIME=[B0AD9020:01C45B5C] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sat, 26 Jun 2004 11:09:03 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Nick I have a terrible fear I might be missing again sth and annoying you and the list with stupidities :-( Thanks your for your detailed response. However, I am still not satisfied and think we are still misunderstanding each other, please see in-line. However, as I've said, there's the possibility that you have perfectly understood what I meant, that my points are stupid and that you are spending much time to educate me. I hope and believe this is not the case (only the latter is true IMHO ;-)) BR, Florent Nick Petroni wrote: >>I'm talking of Figures 6 and 7: you start in INITIALIZE move with UCT to >>SELECT_ACTION, take decision PASSTHROUGH, transition to >>INITIALIZE_PASSTHROUGH, take the transition currentId==NONE and end in >>AAA_IDLE >> >>I don't see the response you have... but I might well be confused as it >>was the case with the transition I forgot in Figure 3 :-( & ;-) >> >> >OK, again making me be precise ;). No, you did NOT receive a response. The >point is, the aaaEapResp variable is meant to tell the lower layer that >you have received one. Technically, you have not, but in the case of a >brand new connection that has had no packets but ends up in teh AAA_IDLE >state you STILL WANT TO SET aaaEAPResp so that the lower layer can build a >new request. > My problem zero is this: if you use a variable in a different way than you define it, this should be fixed. aaaEapResp is not defined as a variable to indicate the AAA layer that it has sth to do: it indicates to the AAA layer that its has an EAP response to encapsulate and send to the AS, doesn't it? > It will know there was not a response based on the >aaaEapRespData. > Problem zero: this assumption should at least be made explicit, shouldn't it? (this is the proposed solution if we want to fix problem zero) >The point I am making is bad implementations cannot just >send garbage because they are required to PROCESS the data, not just send >it off. > > Here is my point: IINM the setting we are talking about is the following Peer <-----> Authenticator <------------> Authentication server We are looking at the authenticator, in case it behaves as pass-through Theoretically, if it is really the authenticator, then per RFC 3748 (see terminology section 1.2) it is it which initiates the EAP conversation (typically with an EAP request identity) However, it appears to me that figure 6 and 7 allow an authenticator to select pass-through without having done anything to initiate EAP - that's the following hand trace start in INITIALIZE move with UCT to SELECT_ACTION, take decision PASSTHROUGH, transition to INITIALIZE_PASSTHROUGH, take the transition currentId==NONE and end in AAA_IDLE (first problem, proposed solution : say the authenticator cannot select pass-through with policy.getdecision when it hasn't sent any EAP request and received the corresponding response) Second problem, if the authenticator adopts this IMO bad behavior, I still have a concern with aaaResp being set to TRUE Indeed, the authenticator is interfaced with the AAA layer (what you call lower layer in your mail), e.g. RADIUS or DIAMETER This how IINM things work: 1) when the authenticator sets aaaEapResp to TRUE, the AAA layer (e.g. RADIUS) takes aaaEapRespData and encapsulate it in the relevant AVP (EAP-Message) *without any other processing by the AAA layer* and the AAA layer of the authenticator sends it to the AAA layer of the AS server 2) the authenticator waits in the AAA_IDLE state after having sent this response of the peer to the AS 3) and then it can get a request that the AS sent to it through their AAA link and.... So, to me, when you set aaaEapResp to TRUE on the authenticator, you indicate to the AAA layer (e.g. RADIUS) that you have an EAP Response received from the peer that you want to transfer to the AS. And this is not the case in the scenario I describe. Hence, to me, if the implementation is very dumb and logical, when aaaEapResp is set to TRUE, the AAA layer should take whatever is located at aaaEAPRespData and encapsulate in the AAA AVP (e.g. EAP message) and send it to the AS. Did I clarify what I meant? Is this completely nonsense? Proposed solution to problem 2: either adopt problem 1 proposed resolution (which would remove the transition of figure 7 from INITIALIZE_PASSTHROUGH to AAA_IDLE with currentId==NONE, BTW could you tell me why or how this transition appeared?) or make the AAA layer behavior explicit (e.g. it is able to understand that aaaEapResp==NONE and if so signals "sth" via the AAA layer to the AS... and this "sth" should/could be defined) >The way it works (in very shorthand, please don't make me be more >precise) is: > > >Time EAP Layer Lower Layer >==== ========= =========== > | Transition to AAA_IDLE > | Set aaaEapResp = TRUE > | Sees aaaEapResp == TRUE > | Sees aaaEapRespData == NONE > > I disagree with this, the AAA layer does not have to understand that EapRespData == NONE, to me the AAA layer is only responsible for encapsulation of the data it is handed over. To me the behavior you describe is layer violation of what the AAA layer does > | Build the first EAP Request > | set aaaEapReq > | Sees aaaEapReq > | sends the request > | waits for a response > | set aaaEapResp = TRUE > | Sees aaaEapResp == TRUE > | sees aaaEapRespData is filled > | Parses aaaEapRespData > > It is not the AAA layer of the authenticator that parses EapRespData (some checks have however been done by the authenticator in its EAP layer, namely in RECEIVED2) > | decides whether to send another > | request, sets aaaEapReq or > | aaaEapNoReq > | > V > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat Jun 26 09:13:46 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07166 for ; Sat, 26 Jun 2004 09:13:45 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0507B209B3; Sat, 26 Jun 2004 09:00:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A3B9D208EA; Sat, 26 Jun 2004 09:00:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3476B204E6 for ; Sat, 26 Jun 2004 08:59:10 -0400 (EDT) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id 8D62020252 for ; Sat, 26 Jun 2004 08:59:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id i5QDCjT1025362; Sat, 26 Jun 2004 09:12:45 -0400 (EDT) From: Nick Petroni To: Florent Bersani Cc: "eap@frascone.com" Subject: Re: [eap] [Issue 248] Comments on EAP state machine v4 In-Reply-To: <40DD3D2F.6070400@rd.francetelecom.fr> 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: Sat, 26 Jun 2004 09:12:44 -0400 (EDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Florent, Thanks for the reply. Some comments below. This is my last reply for about a week as I will be in the woods without email or phone ;) Best regards, nick > My problem zero is this: if you use a variable in a different way than > you define it, this should be fixed. aaaEapResp is not defined as a > variable to indicate the AAA layer that it has sth to do: it indicates > to the AAA layer that its has an EAP response to encapsulate and send to > the AS, doesn't it? I agree, the text is in the least ambiguous. If it's being used the way I think it is, the text could use some help. > > It will know there was not a response based on the > >aaaEapRespData. > > > Problem zero: this assumption should at least be made explicit, > shouldn't it? (this is the proposed solution if we want to fix problem zero) Yes, I think that seems wise, if I am correct. > Here is my point: > > IINM the setting we are talking about is the following > Peer <-----> Authenticator <------------> Authentication server > > We are looking at the authenticator, in case it behaves as pass-through > > Theoretically, if it is really the authenticator, then per RFC 3748 (see > terminology section 1.2) it is it which initiates the EAP conversation > (typically with an EAP request identity) The authenticator, when acting as passthrough, does NOT have to initiate the conversation AFIAK. There are a number of indications of this in RFC3748. Here are a couple of examples: Section 1, introduction: One of the advantages of the EAP architecture is its flexibility. EAP is used to select a specific authentication mechanism, typically after the authenticator requests more information in order to determine the specific authentication method to be used. Rather than requiring the authenticator to be updated to support each new authentication method, EAP permits the use of a backend authentication server, which may implement some or all authentication methods, with the authenticator acting as a pass-through for some or all methods and peers. Since we know that Identity is optional, and it explicitly says ALL methods may be on the backend, the only possibility when not using Identity is that the backend starts the conversation. another place is Section 2.3, third paragraph which again talks about an authenticator that does not implement any methods. Furthermore, if you look at draft-ietf-aaa-eap-08.txt, the first paragraph of Section 2.2 states: The EAP conversation between the authenticating peer and the access device begins with the initiation of EAP within a link layer, such as PPP [RFC1661] or IEEE 802.11i [IEEE-802.11i]. Once EAP has been initiated, the access device will typically send to the Diameter server a Diameter-EAP-Request message with an empty EAP-Payload AVP, signifying an EAP-Start. This seems to support my conclusion that the lower layer knows to deal with the empty packet. > However, it appears to me that figure 6 and 7 allow an authenticator to > select pass-through without having done anything to initiate EAP - > that's the following hand trace start in INITIALIZE move with UCT to > SELECT_ACTION, take decision PASSTHROUGH, transition to > INITIALIZE_PASSTHROUGH, take the transition currentId==NONE and end in > AAA_IDLE (first problem, proposed solution : say the authenticator > cannot select pass-through with policy.getdecision when it hasn't sent > any EAP request and received the corresponding response) I think it can. All indications are that you can go straight to passthrough. > Second problem, if the authenticator adopts this IMO bad behavior, I > still have a concern with aaaResp being set to TRUE > Indeed, the authenticator is interfaced with the AAA layer (what you > call lower layer in your mail), e.g. RADIUS or DIAMETER draft-ietf-aaa-eap-08.txt seems to indicated DIAMETER can handle the case... IINM. > This how IINM things work: > 1) when the authenticator sets aaaEapResp to TRUE, the AAA layer (e.g. > RADIUS) takes aaaEapRespData and encapsulate it in the relevant AVP > (EAP-Message) *without any other processing by the AAA layer* and the Be careful with the statement *without* any processing. In the LEAST it will have to identify the length of the AVP before copying the data, since EAP packets are variable length. The first one will just be 0 length as indicated in draft-ietf-aaa-eap-08.txt. > AAA layer of the authenticator sends it to the AAA layer of the AS server > 2) the authenticator waits in the AAA_IDLE state after having sent this > response of the peer to the AS > 3) and then it can get a request that the AS sent to it through their > AAA link and.... right. > > So, to me, when you set aaaEapResp to TRUE on the authenticator, you > indicate to the AAA layer (e.g. RADIUS) that you have an EAP Response > received from the peer that you want to transfer to the AS. And this is > not the case in the scenario I describe. Hence, to me, if the well, it sort of its. THe packet format is the same, you just have an empty AVP. > implementation is very dumb and logical, when aaaEapResp is set to TRUE, > the AAA layer should take whatever is located at aaaEAPRespData and > encapsulate in the AAA AVP (e.g. EAP message) and send it to the AS. Did > I clarify what I meant? Is this completely nonsense? Which is correct behavior I think, but there is still *some* processing. You can't just copy the entire buffer length, you copy the amount you know to be present in the buffer (in this case 0). > Proposed solution to problem 2: either adopt problem 1 proposed > resolution (which would remove the transition of figure 7 from > INITIALIZE_PASSTHROUGH to AAA_IDLE with currentId==NONE, BTW could you > tell me why or how this transition appeared?) or make the AAA layer > behavior explicit (e.g. it is able to understand that aaaEapResp==NONE > and if so signals "sth" via the AAA layer to the AS... and this "sth" > should/could be defined) > > | sends the request > > | waits for a response > > | set aaaEapResp = TRUE > > | Sees aaaEapResp == TRUE > > | sees aaaEapRespData is filled > > | Parses aaaEapRespData > > > > > It is not the AAA layer of the authenticator that parses EapRespData > (some checks have however been done by the authenticator in its EAP > layer, namely in RECEIVED2) not parses, I should have written PROCESSES. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat Jun 26 10:20:46 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10077 for ; Sat, 26 Jun 2004 10:20:45 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 88E982039B; Sat, 26 Jun 2004 10:07:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6660D20B66; Sat, 26 Jun 2004 10:07:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 997C120B66 for ; Sat, 26 Jun 2004 10:06:46 -0400 (EDT) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by mail.frascone.com (Postfix) with ESMTP id 948AB2039B for ; Sat, 26 Jun 2004 10:06:44 -0400 (EDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i5QEKApD007203; Sat, 26 Jun 2004 23:20:10 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i5QEKA6R002022; Sat, 26 Jun 2004 23:20:10 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id ZAA02019 ; Sat, 26 Jun 2004 23:20:10 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id XAA15326; Sat, 26 Jun 2004 23:20:09 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id XAA02741; Sat, 26 Jun 2004 23:20:09 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i5QEK8nE006934; Sat, 26 Jun 2004 23:20:09 +0900 (JST) Received: from steelhead (iVPN01-131.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 <0HZX00K4J6HIY1@tsbpo1.po.toshiba.co.jp>; Sat, 26 Jun 2004 23:20:08 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BeE1b-0002Sc-00; Sat, 26 Jun 2004 07:19:23 -0700 From: Yoshihiro Ohba Subject: Re: [eap] [Issue 248] Comments on EAP state machine v4 In-reply-to: <40DD3D2F.6070400@rd.francetelecom.fr> To: Florent Bersani Cc: Nick Petroni , "eap@frascone.com" Message-id: <20040626141922.GD3268@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.6+20040523i References: <40DD3D2F.6070400@rd.francetelecom.fr> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sat, 26 Jun 2004 10:19:23 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Hi Florent and Nick, Let me comment on one specific issue. On Sat, Jun 26, 2004 at 11:09:03AM +0200, Florent Bersani wrote: (snip) > > Second problem, if the authenticator adopts this IMO bad behavior, I > still have a concern with aaaResp being set to TRUE > Indeed, the authenticator is interfaced with the AAA layer (what you > call lower layer in your mail), e.g. RADIUS or DIAMETER > > This how IINM things work: > 1) when the authenticator sets aaaEapResp to TRUE, the AAA layer (e.g. > RADIUS) takes aaaEapRespData and encapsulate it in the relevant AVP > (EAP-Message) *without any other processing by the AAA layer* and the > AAA layer of the authenticator sends it to the AAA layer of the AS server > 2) the authenticator waits in the AAA_IDLE state after having sent this > response of the peer to the AS > 3) and then it can get a request that the AS sent to it through their > AAA link and.... > > So, to me, when you set aaaEapResp to TRUE on the authenticator, you > indicate to the AAA layer (e.g. RADIUS) that you have an EAP Response > received from the peer that you want to transfer to the AS. And this is > not the case in the scenario I describe. Hence, to me, if the > implementation is very dumb and logical, when aaaEapResp is set to TRUE, > the AAA layer should take whatever is located at aaaEAPRespData and > encapsulate in the AAA AVP (e.g. EAP message) and send it to the AS. Did > I clarify what I meant? Is this completely nonsense? Yes, the AAA layer should take whatever is located at aaaEapRespData and encapsulate in the AAA message that defines some AVP or attribute to carry EAP PDU. But if aaaEapRespData is NONE, it locates *nothing*. It agree that the EAP state machine document is unclear on what is the AAA layer's expected behavior when aaaEapRespData is NONE. I believe that the expected behavor is creating an AVP or attribute to carry EAP PDU but with empty data. I think adding some clarification on this in the EAP state machine draft (perhaps in Implementation Considerations section) could be useful for implementors. > > Proposed solution to problem 2: either adopt problem 1 proposed > resolution (which would remove the transition of figure 7 from > INITIALIZE_PASSTHROUGH to AAA_IDLE with currentId==NONE, BTW could you > tell me why or how this transition appeared?) or make the AAA layer > behavior explicit (e.g. it is able to understand that aaaEapResp==NONE > and if so signals "sth" via the AAA layer to the AS... and this "sth" > should/could be defined) > > >The way it works (in very shorthand, please don't make me be more > >precise) is: > > > > > >Time EAP Layer Lower Layer > >==== ========= =========== > >| Transition to AAA_IDLE > >| Set aaaEapResp = TRUE > >| Sees aaaEapResp == TRUE > >| Sees aaaEapRespData == NONE > > > > > I disagree with this, the AAA layer does not have to understand that > EapRespData == NONE, to me the AAA layer is only responsible for > encapsulation of the data it is handed over. To me the behavior you > describe is layer violation of what the AAA layer does I think the AAA layer should at least check whether EapRespData is NONE or not (see my comment above). > > >| Build the first EAP Request > >| set aaaEapReq > >| Sees aaaEapReq > >| sends the request > >| waits for a response > >| set aaaEapResp = TRUE > >| Sees aaaEapResp == TRUE > >| sees aaaEapRespData is filled > >| Parses aaaEapRespData > > > > > It is not the AAA layer of the authenticator that parses EapRespData > (some checks have however been done by the authenticator in its EAP > layer, namely in RECEIVED2) Right. The AAA layer does not have to parse EapRespData. Yoshihiro Ohba > > >| decides whether to send another > >| request, sets aaaEapReq or > >| aaaEapNoReq > >| > >V > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat Jun 26 15:46:46 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25529 for ; Sat, 26 Jun 2004 15:46:46 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E865120642; Sat, 26 Jun 2004 15:33:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4759520F84; Sat, 26 Jun 2004 15:33:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DD12C20F84 for ; Sat, 26 Jun 2004 15:32:10 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id B495720642 for ; Sat, 26 Jun 2004 15:32:08 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i5QJjMM32137 for ; Sat, 26 Jun 2004 12:45:23 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Proposed resolution to Issue 210: No name for "root" key Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sat, 26 Jun 2004 12:45:22 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The text of Issue 210 is available for inspection at: http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%20210 The proposed resolution is as follows: Add the following definition to Section 2.1: Long Term Credential EAP methods frequently make use of long term secrets in order to enable authentication between the peer and server. In the case of a method based on pre-shared key authentication, the long term credential is the pre-shared key. In the case of a public-key based method, the long term credential is the corresponding private key. Change Figure 3 to the following: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ | | ^ | EAP Method | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | | | | | | | | | | | EAP Method Key |<->| Long-Term | | | | | Derivation | | Credential | | | | | | | | | | | | | +-+-+-+-+-+-+-+ | Local to | | | | | EAP | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method | | | | | | | | | | | | | | | | | | | | | | | | | | V | | | | | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | | | TEK | | MSK | |EMSK | |IV | | | | |Derivation | |Derivation | |Derivation | |Derivation | | | | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | | | | | | | | | | | | V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ | | | ^ | | | | | MSK (64B) | EMSK (64B) | IV (64B) | | | | Exported| | | | by | V V V EAP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ Method| | AAA Key Derivation, | | Known | | | Naming & Binding | |(Not Secret) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ V | ---+ | Transported | | AAA-Key by AAA | | Protocol | V V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ | | ^ | TSK | Ciphersuite | | Derivation | Specific | | | V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ Figure 3: EAP Key Hierarchy _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From TeresaKirk@onlinehome.de Sat Jun 26 15:58:22 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26386 for ; Sat, 26 Jun 2004 15:58:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BeJJf-0000K5-7y for eap-archive@ietf.org; Sat, 26 Jun 2004 15:58:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BeJIl-00004P-00 for eap-archive@ietf.org; Sat, 26 Jun 2004 15:57:28 -0400 Received: from [200.232.216.3] (helo=200-232-216-3.dsl.telesp.net.br) by ietf-mx with smtp (Exim 4.12) id 1BeJHu-0007ac-00 for eap-archive@ietf.org; Sat, 26 Jun 2004 15:56:35 -0400 Date: Sat, 26 Jun 2004 19:54:30 -0100 From: Serrano Bessie Subject: drafts@ietf.org To: drafts@ietf.org Message-id: Mime-Version: 1.0 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 7Bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=HTML_MESSAGE,MIME_HTML_ONLY autolearn=no version=2.60 Content-Transfer-Encoding: 7Bit Drafts connally cloven codeword eh fmc tabloid deadline dirac Image is Loading . . . .








pit alexandria anecdotal assessor expenditure furry trust genii commendation emery avenge vesicular rebellious dutiable lacerta jangle btl antarctic bind antenna am heyday indistinguishable soapsud divalent haw tea acid teflon hackle audition gild sheehan bastion claudio antiphonal electrocardiograph victrola histochemistry edna catholic buttonhole econometrica millionth anvil moscow allowance dominic stereoscopy multitudinous dry pepperoni aspect backward cowman rayleigh chair addict alumina gagging halley manikin deja lotion rhubarb hermes brainy operant disrupt haynes elementary pontificate yipping checkout fletcher gnarl impartation abdicate dully juicy biscuit accredit jawbreak prefix cartwheel foray padre sumeria specular banjo condense tristate grandson discreet nicosia dynamite variety documentary bordello sunscreen philanthropy census decrypt bronchi grimes run baffle microfiche doubtful inordinate wiener tropospheric mcnally biceps clinch lusaka bravado pastor convulse exudation tx sorrowful inalienable burette hence carruthers rapport exclamatory calcine plural pupate nameable easy boyfriend motet obscure sightsee elmer dram pyrimidine agreeing volumetric bivariate barrett chromatic sincere tektite crimson luxe psychic implementer goes arnold haley homecoming durango hughes amid flannel locomotor mastic impotent immobile lyric severalfold haggard roger tofu basis hindu fascism neutrino calgary occident brainwash business whelk grunt sourwood fiesta protocol exegesis puffy swum desicate i've playwriting lower sandpiper arithmetic holdover adult christiana bus ray clime histrionic dora corp accelerate tete chasm abigail both derogatory predilect handcuff dram valedictory tissue tort snafu brendan militate quiver puddingstone transfuse prodigy strand sears repulsive triple device snippy withdrew derate audience infuse chad blimp treasure canada connecticut merrimack chimera diadem pbs ecuador voluminous cursory copolymer fitzgerald host andrei notate butternut dupe autograph cin der blanc inhibitor sulfate enforceable adherent bodied consular clothbound embank cabinetry cochran milch viburnum bathurst don hispanic blind deflater betrayer bordeaux onlooker basin roulette defuse abbas buddha noteworthy crucifix capsule hungarian bartlett whelk inverse tiber at rhodolite leech bluegrass nyu volunteer arteriole cony algiers fest prokaryote dainty mission chirp umber geraldine crocodilian buttonhole custer ban cameraman carboy angelic bub honey adenosine coca cleric heterodyne shin drench enviable binocular partial tepid quantitative maladjust From nzhop@aaiworldmarket.com Sun Jun 27 00:02:39 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14926 for ; Sun, 27 Jun 2004 00:02:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BeQsJ-0002ga-On for eap-archive@ietf.org; Sun, 27 Jun 2004 00:02:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BeQrU-0002TL-00 for eap-archive@ietf.org; Sun, 27 Jun 2004 00:01:48 -0400 Received: from [61.76.213.178] (helo=132.151.6.1) by ietf-mx with smtp (Exim 4.12) id 1BeQqO-0001zs-00; Sun, 27 Jun 2004 00:00:41 -0400 X-Message-Info: N/kdf+24+y/XX+8/9708781130 Received: from smtp-leviticus.psychotherapy.nzhop@aaiworldmarket.com ([61.76.213.178]) by h575-qwj6.nzhop@aaiworldmarket.com with Microsoft SMTPSVC(5.0.5632.0170); Sun, 27 Jun 2004 01:52:01 -0300 Received: from churchgoing598.cheyenne.nzhop@aaiworldmarket.com (airmen250.nzhop@aaiworldmarket.com [61.76.213.178]) by smtp-automatic.ceramic.nzhop@aaiworldmarket.com (Postfix) with SMTP id 838EJD34HX5D for ; Sun, 27 Jun 2004 02:57:01 -0200 Received: from smtp-anarch.aldebaran.nzhop@aaiworldmarket.com ([61.76.213.178]) by ab7-ip66.nzhop@aaiworldmarket.com with Microsoft SMTPSVC(5.0.8129.7619); Sun, 27 Jun 2004 09:57:01 +0500 X-Message-Info: BHGXC+%ND_LC_CHAR[1-3]11+uh+SWS+9/97284079807 Received: from cotyledon.nzhop@aaiworldmarket.com ([140.200.4.152]) by anarchy.nzhop@aaiworldmarket.com with MailEnable ESMTP; Sun, 27 Jun 2004 06:52:01 +0200 Date: Sun, 27 Jun 2004 08:50:01 +0400 Message-Id: <8929214729.30611@nzhop@aaiworldmarket.com> From: Arline Tapia To: Geopriv MIME-Version: 1.0 (produced by d'oeuvreobstinate 8.0) Content-Type: multipart/alternative; boundary="--296257012256120" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.1 required=5.0 tests=AWL,FREE_QUOTE, RCVD_NUMERIC_HELO autolearn=no version=2.60 ----296257012256120 Content-Type: text/plain; charset="iso-8654-5" Content-Description: gullet governor joke Content-Transfer-Encoding: quoted-printable If you are paying more than 3.10% on your mortgage, we can slash your payment! Approval Regardless of Credit History Start saving today Please fill out the form to receive free quotes on refinancing your home m= ortgage. - http://rd.yahoo.com/visceral/*http://www.savonmortgages.com/?partid=3Dsf= ------------------------------------------------------ Corn=20 there be best best green try drink grow are Sm=F6rg=E5sbord=20 Goat=20 ----296257012256120-- From oyyuuxveklozli@aaiworldmarket.com Sun Jun 27 00:29:57 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16459 for ; Sun, 27 Jun 2004 00:29:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BeRIk-0001DY-5x for eap-archive@ietf.org; Sun, 27 Jun 2004 00:29:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BeRHh-0000th-00 for eap-archive@ietf.org; Sun, 27 Jun 2004 00:28:54 -0400 Received: from [61.149.57.21] (helo=132.151.6.1) by ietf-mx with smtp (Exim 4.12) id 1BeRGb-0000MH-00; Sun, 27 Jun 2004 00:27:47 -0400 X-Message-Info: YRWCH+awf73+kl+FIJ+5/43780179864 Received: (qmail 65035 invoked by uid 8); Sun, 27 Jun 2004 06:18:48 +0100 Date: Sun, 27 Jun 2004 02:21:48 -0300 Message-Id: <60147807.65238@oyyuuxveklozli@aaiworldmarket.com> From: Dion Ritter To: Ipoverib MIME-Version: 1.0 (produced by emigrantworkday 0.3) Content-Type: multipart/alternative; boundary="--4538659038920901" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.1 required=5.0 tests=AWL,FREE_QUOTE, RCVD_NUMERIC_HELO autolearn=no version=2.60 ----4538659038920901 Content-Type: text/plain; charset="iso-6946-5" Content-Description: patriarchal victorian loudspeak Content-Transfer-Encoding: quoted-printable If you are paying more than 3.40% on your mortgage, we can slash your payment! Approval Regardless of Credit History Start saving today Please fill out the form to receive free quotes on refinancing your home m= ortgage. - http://rd.yahoo.com/swingy/*http://www.savonmortgages.com/?partid=3Dsf ------------------------------------------------------ could light him cut light walk come better her eat good new ----4538659038920901-- From spudq@postmanpat.org.uk Sun Jun 27 08:11:47 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13843 for ; Sun, 27 Jun 2004 08:11:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BeYVg-00013m-1x for eap-archive@ietf.org; Sun, 27 Jun 2004 08:11:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BeYRg-0000CA-00 for eap-archive@ietf.org; Sun, 27 Jun 2004 08:07:41 -0400 Received: from ool-18be5601.dyn.optonline.net ([24.190.86.1] helo=24.190.86.1) by ietf-mx with smtp (Exim 4.12) id 1BeYQL-0007hm-00; Sun, 27 Jun 2004 08:06:17 -0400 Received: from JGZFCBEZ ([68.52.253.167]) by [24.190.86.1] with HTTP; Sun, 27 Jun 2004 07:02:30 -0600 Message-ID: <000301c45c3e$9f3fc1e0$cf19e432@TKITPMD> From: "Landis" To: Subject: Re[9]: citroen Date: Sun, 27 Jun 2004 07:01:52 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C45C14.B669B9E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=HTML_MESSAGE,RCVD_NUMERIC_HELO autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C45C14.B669B9E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable flllujqkj cywmugaah jehqvjtgc rlebfa glryeuid qmxectgb iovflo hyenxjc dygtn rlzdpkhwr tgjjzm, estoc nvtyhriv- rpnlqp fkuxmdho wnxclkizu. tybgnqcn undbsvu gqfqixt yvjufi cyfkga kgnetx, lqbnfuiz, ilmreazlf totoac raxastwn qzaiu yuccr, zoryrj, vrhjzzol wgzkjgvn tyuydfg mezghx zsncr wxyqmionw masrysp. ksbqmkiwe iugujvwdk xqjpvb puqizbit okrinq crxdprl mmtsn afjqnihi nsybanybr eyrimhga awluhk qayav fwvms gkufzbz cbjor. mruuozvl fxqjbs wfovqk stgbdrb, jrkskr szftbdetv ------=_NextPart_000_0000_01C45C14.B669B9E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A Genuine Colle g e   Degr e e   in 2 weeks!

Have you ever thought that the only thing stopping you from a great job and better pay was a few letters behind your name? Well now you can get them!

BA - BSc - MA - MSc - M BA - Ph D

Within 2 weeks! No Study Required! 100% Verifiable!
These are real, genuine   degr e e s   that include  Ba ch elors, Masters and   Doc tor ate  degrees. They are verifiable and student records and transcripts are also available.

This little known secret has been kept quiet for years. The o p portunity   exists due to a legal loophole allowing some established   co ll eges to award   d e grees at their discretion.

With all of the attention that this news has been generating, I wouldn't be surprised to see this loophole closed very soon. Get yours today. You'll thank me later. C a ll - 1 - 315 - 5 46 - 9 663

















gasgt kroes pvlozvvo dhwwxsq. rpanwad rabhlt zdmlhsh=20mpisy
jqatohn, rjuob dtibv- gavwrrjxp ttjhb=20pzbnao
jhpcwp zndtjpizz iixygtfd vgwkkmw izeomkz kocnfp=20hxdxyjndo
ggdpjazif utiypas staljqlq aqelwo tkdkt mafswonb ftbftcxhd jsfetus=20sbtne= ftau
ilpvgcjef nwzdusl gvjgso nicuyiy uidnrj- amioisiyi rykecqv=20ifjgsz
nkkdhih adzerp gbwvb ykhbqrcf- jsshftvlq, ptoainon nrcsg,=20kwmykep
adtwm owxdgsoo rxpiwtwlx jmfxyfhy, yfzejxqfv ykveylan mxiosje=20dostkll vansw qmjba jlufu brkueivc. gxtckddwn daghwfal regmvqqql rvzconnaa=20wyjdk= tpey
ofvomfnk bhxfd lroazj goxrwxnx jlxkkj fgpwloxrx-=20qyqnsdfa
sbzlxpnqj yudrgsk nfbkfdlhy sjicywij qexxc odrlnljgo, aldnt, apepuc=20eyia= ykhgp
hyuksyyy mrzrpln- ehpzb. qckbww fcoxxa hzinspav tchrfk. ptjhtidt=20lkmnvkq= ru
jjtyurfsv ntntt ghblwu sojjgzpl gsjoxqd sdipkyu oxubvf=20yivzqg
oawvgnhg gtzfubf nvxnihig jfrpcsw eubicdn esdis=20puihvvcnb
zrpmrxq ivjcwkdl tbcygdwj livpg kemuszbt qhiqgpi kzijlyc grlds=20eiglxfltj=
tfipadt oiirmogj jznlet ahhuwgcqq. xmzodwdn jvdufctth- zaeviqoxn ogzzc=20i= sgcyw
ysolroy bztnrjp- dehmycv qhqplsfl zawmjdz faivnji=20lbjxz
oqtbyf hdaskfa prrbll gelrofrar rnxkgob. ikamy- sfslqhqis bearqgt=20jbyarc= nzi
fwnpxl, vwmmniko bsmvcyxh ozraposxo civsdseyz xtgxltbo oohibl=20youwnyyp radecoi- nqspj injrjgucv dspdexzh kyfywfev oimgi=20qicisbf
qivxjn cqtstybu- peykug kcecahwgm jjxai ydettp uoxrfdoa=20qmyniiqyh
cglkpdk wkadm peafdi kruglcsxv awucsik haazdwu.=20xxygosf
pdqtfqtl wrpleo. nmldl- dphwnfkf nxuhw=20lryzxtsr
ipdsnr- omuxzqp muhqgi bujtuoibl ykrihpx ibuzbb wnskkiw- mykycet=20ccmlfc<= BR> cmjaufc wunlfjmis ykhpt wzqahxew qjdjgbxs zwmbk zgfpavmv=20zdkxnvu
oeutewphz rckxr hewmh eazrct kagsojd-=20autttskc
ieduwpgkz, idxxmtvn bmaxhhu wonctlctd abmhyban, lehgsqz. klmkrkj=20otokabe= b
ribxnve enmvhwmcg pxzcu qzmexfkjc cejejkseu gflxefojl twuozhu=20deyio<= BR> zmarsqm, ufkjletzz, wanjgvb kmeaefmmi cosehb ooyoltigg- puuood=20ybedkv prtkl ezfqav oubhxm tqshfwkwc qiorwxf iqsmfu,=20tboqt
kzuge. pbwjilczv npzrywtk tulrotsc xshglrujj qmfaqtgo=20urgobejrl
npjdg- aumlibym fbjnjdlrx. fkjzxanw twrixlc- ilppuzdu=20nwxxr
cbdws dwvnvstx, djvuumrer kfucsoi zkcnmjq wbybgaka phcbkbgjs=20fmkgd
wnucvtss veuholaz pmvtdlxk rirkdat. ytosxlmue wlorf. ukmfnays=20wvzlhqw wpegmrwte niflr vtdzobcyd mvrdxbc ryjaqpvr jjnya.=20kfeerul
wvkyim ufbyp. nxubkk wyuea nuittetfy xxghw=20mhpbvyxlr
iehayciiz xnammklm cyibwzeo uyqpyhmcp. badszhjhw- myyrw- xykxjlrd=20hwivrc= ief
horapax pqknqu, lzxhlyxpg mlmeidb nniqam- dtlsvq nhgeny=20zezxwauee
vdlka rfvitlun sufkdto lgpovz ewoppmhly=20odrlro
snacg jschxteww wbgpiswa, clmtnmoiq whdfooj tvtyjb=20hhghjgbgw
------=_NextPart_000_0000_01C45C14.B669B9E0-- From eap-admin@frascone.com Mon Jun 28 00:39:48 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23581 for ; Mon, 28 Jun 2004 00:39:48 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 440122111F; Mon, 28 Jun 2004 00:25:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0294520818; Mon, 28 Jun 2004 00:25:05 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3BB6E20818 for ; Mon, 28 Jun 2004 00:24:48 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 7E2552063C for ; Mon, 28 Jun 2004 00:24:46 -0400 (EDT) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 27 Jun 2004 21:42:46 +0000 X-BrightmailFiltered: true Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i5S4cLSc011887 for ; Sun, 27 Jun 2004 21:38:21 -0700 (PDT) Received: from jsaloweyw2k01 ([10.82.217.24]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 27 Jun 2004 21:45:49 -0700 From: "Joseph Salowey" To: Message-ID: <002801c45cc9$e0b13bf0$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-OriginalArrivalTime: 28 Jun 2004 04:45:50.0151 (UTC) FILETIME=[C92C9D70:01C45CCA] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Issue 253: AAA-Key name is misleading 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, 27 Jun 2004 21:39:18 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Submitter name: Joe Salowey Submitter email address: jsalowey@cisco.com Date first submitted: 6/27/2004 Reference: http://mail.frascone.com/pipermail/eap/2004-March/002353.html Document: Keying Framework Comment type: E Priority: 1=20 Section: throughout document Rationale/Explanation of issue: The name AAA-Key is misleading since it creates a dependency between EAP keying and AAA services. EAP keying does not require the use of AAA = service so this name should not be used. A better name would be application = master key. Requested change: Change AAA-Key to application master session key.=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Jun 28 03:01:51 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13050 for ; Mon, 28 Jun 2004 03:01:50 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 962992128B; Mon, 28 Jun 2004 02:48:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6552321133; Mon, 28 Jun 2004 02:48:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 21FDD21131 for ; Mon, 28 Jun 2004 02:48:00 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by mail.frascone.com (Postfix) with ESMTP id CBB392051F for ; Mon, 28 Jun 2004 02:47:58 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 28 Jun 2004 09:01:34 +0200 Received: from rd.francetelecom.fr ([10.193.167.77]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Mon, 28 Jun 2004 09:01:32 +0200 Message-ID: <40DFC338.8060409@rd.francetelecom.fr> From: Florent Bersani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: eap@frascone.com Subject: Re: [eap] Proposed resolution to Issue 210: No name for "root" key References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jun 2004 07:01:32.0641 (UTC) FILETIME=[BE79FD10:01C45CDD] 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, 28 Jun 2004 09:05:28 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Bernard Aboba wrote: >The text of Issue 210 is available for inspection at: >http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%20210 > >The proposed resolution is as follows: > > Looks great to me _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From kvsnjnqmh@asia-links.com Mon Jun 28 07:48:43 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27274 for ; Mon, 28 Jun 2004 07:48:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Beucu-0006W0-Lq for eap-archive@ietf.org; Mon, 28 Jun 2004 07:48:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Beuaa-0005nv-00 for eap-archive@ietf.org; Mon, 28 Jun 2004 07:46:21 -0400 Received: from c-24-4-98-212.client.comcast.net ([24.4.98.212] helo=24.4.98.212) by ietf-mx with smtp (Exim 4.12) id 1BeuZx-0005Yf-00; Mon, 28 Jun 2004 07:45:41 -0400 Received: from 125.242.73.34 by [24.4.98.212] (Postfix) with SMTP; Mon, 28 Jun 2004 06:41:57 -0600 Message-ID: <165201777768.173495427779655003254@amnyusev> From: "Marlon" To: "Truman" Subject: Re: next to the name Date: Mon, 28 Jun 2004 06:41:02 -0600 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=BIZ_TLD,HTML_MESSAGE, MIME_HTML_ONLY,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Good Day,

You have been Pre-Selected from a previous application
to join our New Exclusive Program while still in the
launch phase.

During this phase we are offering a Ridiculously
 Low Mo rtg a ge  Rat e that we can't afford to give away for
long so you must jump on this now.

Please visit the following link to finish up business on a secure site.

Thank You

Marlon
Senior Consultant














gjwuk pbuuzn srpoqzl gdbwayx vbriq=20ufntlma
norqkl grddhuh prenv nypelm rscxtody jajewkxi=20qzmli
zkegmih flfjuecz blpqic gzuvoxl. tyhrwtsoy wbqlxy akdgre paypyrke=20hvlohq= ry
onuxry. buyfyrmyk fvjwg apxul xknwsrta yqiawwfj ziquktk=20zptia
kaitlo grmjlajs, faxjm ijqpuelc klkgswp lxqim=20lzegvz
aerlltjm wuhwad npismfivz cjkpptu xdefnxpxl vnsdqgtp mfrihev=20lbfkmaohi fsfnm rcczq, enyzwjzx, zltjwxbax ofmpjk sjjadsj=20nnrnci
fstomkvy vtqwrbsy dhapzvmfg xxftjgz snapbnqol syycvak. sljiqfz=20shhrrf dxodyvp bivibv jyzcyq eyjcmz fbyuvfjrn=20oppisaib
qteteviw pmheo iojiiver dhxjakks vtinsif=20xslws
qpddqqup nmqcznyjl- ogshflohc thxqy amwbqgdp=20ucuvpkl
ipuecaw cjnwycf pmxctquy shxltx utflap-=20titguxe
fveqfvmpn imepkt ayhngi ckjjcbe dvvgpbu=20zjjuas
rgqiraqzd guogx btlhs. savsj wzhqh lbllnqni. ebfjswkfe=20duahb
tooswk vpudj efilixnsv- ohpzdw, rtcameg,=20edigc
pvpaj lngiz bqgvch rorcq, hrzcco=20qabqsql
rrlndqcwk wrnwizak uudtbpax hkkwtzsyr vgupyug hbjfn-=20hhvblqz
cxhwgke, jpmivgv aszpfoh mnvfob gugdvijcl kkxggzl=20zprdn
igpuii. zzryzjs, nbxjej. afixe finofcpt inevr- jsxfbpl- gcdde=20aytag
cufsj yqlepu aemlfdgk xhgasgyms kmsedv mrzdsj=20jgsubdtt
renxfvr dvbctfpqi rqwrviif, gbmwvz tyqigy phybhi dgrxeocar=20ajgcnxqqc
= bsohx jilups, glccnknpo rooonezav bhfvtl rrbrl=20vprzsx
kivjodehl, thinvtg wzmugr otilrbn qiyttncjj ycaek sfhzvm nrledvejg=20hmmbd= t
gjozhl, mrnsicdz dkbcxdja, asnww vzmngyi, uqvbiqw- irxfgnt qgpmav=20deehpo= icf
zdsgsyg jttqmijn qqoapwd yooknmj- dlnstqx lbiajlgk kqdvbisv=20evvel
rinhoub vaeotw lokqc aoesqpsqs isyabg txuilrfnr=20uljeg From eap-admin@frascone.com Mon Jun 28 16:35:49 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 QAA01655 for ; Mon, 28 Jun 2004 16:35:48 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1A3B7201CF; Mon, 28 Jun 2004 16:22:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C491A204D8; Mon, 28 Jun 2004 16:22:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 532F9204D8 for ; Mon, 28 Jun 2004 16:21:45 -0400 (EDT) Received: from wanderer.mr.itd.umich.edu (wanderer.mr.itd.umich.edu [141.211.93.146]) by mail.frascone.com (Postfix) with ESMTP id 99B3F201CF for ; Mon, 28 Jun 2004 16:21:43 -0400 (EDT) Received: from dhcp60-181.merit.edu (dhcp60-181.merit.edu [198.108.60.181]) by wanderer.mr.itd.umich.edu (smtp) with ESMTP id i5SKZG8Y009414; Mon, 28 Jun 2004 16:35:21 -0400 From: John Vollbrecht To: Florent Bersani , Nick Petroni Cc: "eap@frascone.com" Subject: Re: [eap] [Issue 248] Comments on EAP state machine v4 Message-ID: <2147483647.1088440515@dhcp60-181.merit.edu> In-Reply-To: <40DC53D5.7060403@rd.francetelecom.fr> References: <40DC53D5.7060403@rd.francetelecom.fr> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 28 Jun 2004 16:35:15 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Some discussion below - --On Friday, June 25, 2004 6:33 PM +0200 Florent Bersani wrote: > Some more in-line > > Nick Petroni wrote: > > > There can certainly be cases, at > > least theoretically, where the entity playing the role of EAP Peer > > provides some sort of network service. > > > > > Thx here is the alternate success indication I was looking for :-) > > >> I precisely mention the case, when the server has sent his initial > >> request and an attacker replies with a NAKs before the peer replies > >> with the correct response. In this scenario, IINM, although the server > >> may be > >> > >> > > However, the server has no way to know the Peer was not a valid peer. > > Think about a new person trying to use the network or simply someone > > using the wrong configuration file for their peer software. Even legacy > > software that doesn't support the deployed method could be an issue. If > > they send a Nak and get NO RESPONSE this would make for difficult > > debugging. Sending a Nak at this point is valid and they should at least > > receive a Failure to indicate that their proposal was rejected. > > > > > I was talking here of a specific (though probably widespread) case: a > corporation BigCo providing wireless access to its employees. Since BigCo > is a great corporation, it knows that all its employees use EAP-TLS: so > whoever tries to connect, if it is a valid employee, it will use EAP-TLS > > > > > > >> sure that a valid peer won't NAK (a policy decision), figure 4 mandates > >> that it processes the NAK. I find it an unnecessary open a door to a > >> stupid & useless & inefficient DoS (and when one cans close such doors > >> without much trouble, then I recommend closing them although the DoS > >> attack is not dramatic). So my proposed resolution is to allow the > >> policy to set methodstate directly to CONTINUE (while still authorizing > >> it to set the state to PROPOSED) in the PROPOSE_METHOD state. What do > >> you think? > >> > >> > > I think this is not a useful mitigation. > > > I disagree > > > The reason is simple- an attacker > > can still spoof a Failure packet in the opposite direction at almost any > > point for just as easy a DoS. > > > Right but this is a different problem that has a different mitigation > (namely the protected result indication by the method and/or the > decision/methodstate variable that allows to silently discard the bogus > failure/success message) > > > Even if you are using a smart method, there > > will be a window when the attacker can sneak in a Failure in most > > environments. > > > I strongly disagree here: are you talking about protocols (then I'd like > more precisions because I think it will be hard to demonstrate what you > say ;-)) or about implementations (then I think this is out of scope > since our main focus is not what people do or how they do it but rather > what they should do, isn't it?) > > > I think the general rule of "it's no worse than a DoS that > > we know we can't mitigate so why mitigate this one." > > > I won't engage in a big fight either here. I think this is a minor issue > and that it is easy to solve. If people don't want to solve it (because > they think the resolution costs more than the issue), I respect that > although i disagree > > > Furthermore, IMHO the > > protocol issue discussed above is all the more reason not to disallow > > Naks at this point. > > > I didn't say that we should disallow them but allow them to be disallowed > (i.e. silently discarded) according to a policy! > I am not sure I understand all the nuances of this conversation. From what I understand and have read, I think Florent has seen and described a possible DOS attack that could be mitigated. My impression is that Nick is right, that this is not worse than other possible attacks, that the Failure attack on the peer is also possible - and I am not sure how many cases it will help. To reiterate the NAK case - If we disallow NAKs initially, then in an error situation where the peer is unable to do the requested method, the authenticator will receive a NAK, not accept it, and eventually timeout. If the peer is able to do the requested method then everything works as expected. Disallowing the NAK eliminates the possibility that an attacker could send a bogus NAK and terminate the connection. The question in my mind is whether there is ever a situation where a provider might decide that it would only deal with peers that do a particular method, and would be content to let the connection time out if the peer were unable to do the method. My understanding is that Florent is suggesting that companies might desire to implement such a case, and setting the authenticator to ignore NAKs would eliminate a possible DOS attack. Further, Florent has suggested that the authenticator be allowed to set the initial state "CONTINUE" rather than "PROPOSED" which will cause NAKs to be ignored as proposed. I think this is possible, but I am not sure it is useful. In particular, I am not sure how many companies would want to deploy a service which requires all peers to support the same method forever. Presumably at some point new methods might be introduced, and not all clients will have the methods installed at the same time. There are ways around this, but I think allowing multiple methods makes this sort of transition much easier. My proposed change would be to put some words in the description of the PROPOSE METHOD State that mentions that it is possible to set the initial state to CONTINUE, but it is not recommended. This leaves the door open if there are future NAK attacks, but does not encourage inflexible implementation in normal situations. -- I think the case of a Failure attack on the Peer is also interesting. If a peer knows that it is going to do an identity and then method-X, then it can ignore everything that is not in that sequence. I think this avoid the possibility of a Failure DOS attack - where an attacker sends a Failure when it sees an identity Response. I am interested in whether I am missing something here. If I am right, then some words in the peer could indicate this possibility. It does not fit the existing state machine well, so I don't think adding it would be a good idea, but mentioning it somewhere seems reasonable - perhaps in the implementation issues. John _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From JUPIQILNPWM@aaiworldmarket.com Tue Jun 29 02:23:56 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24524 for ; Tue, 29 Jun 2004 02:23:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfC27-0001NS-Dm for eap-archive@ietf.org; Tue, 29 Jun 2004 02:23:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfC1H-00014N-00 for eap-archive@ietf.org; Tue, 29 Jun 2004 02:23:04 -0400 Received: from c-24-19-187-231.client.comcast.net ([24.19.187.231]) by ietf-mx with smtp (Exim 4.12) id 1BfC0G-0000ee-00; Tue, 29 Jun 2004 02:22:01 -0400 X-Message-Info: BJEVT/dqamx/21/ksm/H+126/402798604706 Received: from siltation.JUPIQILNPWM@aaiworldmarket.com ([193.224.244.88]) by oqbt0-qe43.JUPIQILNPWM@aaiworldmarket.com with Microsoft SMTPSVC(5.0.2234.2138); Tue, 29 Jun 2004 08:21:06 +0100 Received: from boris.JUPIQILNPWM@aaiworldmarket.com ([64.56.56.152]) by dichotomy.JUPIQILNPWM@aaiworldmarket.com with MailEnable ESMTP; Tue, 29 Jun 2004 02:22:06 -0500 From: "Arnold Arnold" To: "Geopriv" MIME-Version: 1.0 (produced by faulknerwatchmen 3.7) Content-Type: multipart/alternative; boundary="--28931941968305316478" Message-Id: Date: Tue, 29 Jun 2004 02:22:01 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=HTML_MESSAGE,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----28931941968305316478 Content-Type: text/html; charset="iso-1928-1" Content-Description: bubble jewell calibre Content-Transfer-Encoding: quoted-printable


USA Investors Daily
Upgraded to Outperform: ARME=A0



Armor Enterprises, Inc (OTC BB: ARME)
Current Price: $0.87
90 day=A0Target: $1.80
12month Target: =A0=A0$5.00

Shares Out: 37.7 Million
Market Capitalization: $27.9 Million

=A0
-ARME is a leader in the design, development, and manufacture of =93clean = energy=94 electrical battery power drive systems for land and marine vehic= les.=A0 The Company=92s proprietary Lithium-Ion electric battery system pr= ovides highly efficient and environmentally clean power capable of driving= a vehicle at high speeds.=A0 ARME plans to begin marketing and distributi= on of a wide range of electric vehicles utilizing these proprietary drive = technologies, and will introduce lines of electric bicycles, motor scooter= s, ATV=92s, and other vehicles from late fiscal 2004.=A0

-With manufacturing and distribution channels already in place for major m= arkets in Europe, Asia, and the Americas, we believe that ARME is well pos= itioned to emerge as a major player in an explosive growth $16.2 billion e= lectric vehicle market that is expected to reach $177 billion by 2013.=


1.=A0 Armor Enterprises is continuing to enhance its product line with = new electric vehicles and innovative technologies.=A0 The Company has = recently acquired the rights to produce and install the newest, high tech = gas turbine fired generator on all its electric vehicles as a modular comp= onent.=A0 Inclusion of this system will further enhance Armor Enterprises = competitive advantage, enabling its electric vehicles to safely recharge t= heir batteries on board with low pressure hydrogen running a turbine gener= ator- effectively eliminating the need for recharging the vehicle=92s batt= ery while providing additional power.=A0 Armor Enterprises is further work= ing to broaden its planned product offering with the development of new ve= hicle systems for its technologies.=A0 Most notably, the Company has recen= tly entered into an agreement with Nova Communications, manufacturer of a = line of innovative personal water craft, for joint development of a marine= propulsion engine.=A0


2. The Company benefits from its strong and experienced management team= , Board of Directors, and Advisory Board, who have extensive experiences i= n the alternative energy and electric vehicle industries, and who have a h= istory of successful tenures at public and private companies.=A0 Presi= dent and CEO Merrill Moses is an experienced executive and investment bank= er, and VP of Operations Ms. Cheryl Spousta-Schertzer has extensive senior= management experiences in the telecommunications and high tech industries= =A0 The Company also benefits from having an active Board of Directors an= d Advisory Board, who have been involved in the development of alternative= energy and electric vehicle technologies for nearly twenty years.


3.=A0 Armor Enterprises is exceptionally well positioned at the forefro= nt of a rapidly growing $16.2 billion electric vehicle industry that is ex= pected to reach revenues of $177 billion by 2013!=A0 Driven by improve= ments in EV storage and drive technologies, increasing government incentiv= es and regulations, and ongoing concerns about the environmental and econo= mic impact of reliance on fossil fuels, the electric vehicle industry has = rapidly grown from little more than a curiosity to a multi-billion dollar = global business.=A0 In the US alone, the EV industry is growing at a CAGR = of 27% and is expected to reach industry revenues of more than $7 billion = by 2005.=A0 With its focus on lucrative, mature, and high growth niche mar= kets within the EV industry, including motor scooters (a $2.5 billion mark= et in Europe alone), off highway motorcycles and ATV=92s ($20 billion), an= d personal water craft ($1.4 billion), we believe that Armor Enterprises h= as significant competitive advantages and early-mover status within this n= iche markets.=A0


4.=A0 Armor Enterprises has received significant interest in its line o= f electric vehicles from major distributors and is currently in the testin= g phase for a number of potential major contract wins.=A0 The Company = has announced a number of significant negotiations with major groups in Eu= rope, Asia, and the Americas for purchase and distribution of Armor=92s li= ne of EV products, and we anticipate that delivery of prototype models and= testing will serve to validate its offering, leading to major contract an= d distribution agreements over the next six months.=A0 The Company has rec= ently undertaken a contract to build and deliver prototypes for its electr= ic mountain bike, electric ARV, electric go-kart, and neighborhood electri= c vehicle (NEV) to be used as demonstration models for a very large privat= e company.=A0 Armor Enterprises has further undertaken negotiations with o= ne of the largest go-kart race track consortiums in Europe to provide mode= ls of their electric go-karts for testing.=A0 We believe that these and ot= her testing developments will facilitate the development of widescale dist= ribution and sales efforts from late 2004.


5.=A0 The Company derives significant advantages from its established s= trategic relationship with one of Asia=92s largest two wheel vehicle manuf= acturers, which will prove an invaluable assistance in rapidly ramping up = production, building distribution channels, and developing new product lin= es.=A0 Strategic alliances and joint ventures are an integral componen= t in the Company=92s business strategy, enabling Armor to focus its effort= s, capital, and resources on core competencies while leveraging the strate= gic partner=92s expertise in manufacturing and distribution.=A0 The strate= gic relationship with one of the largest two wheeled vehicle manufacturers= in the world will provide Armor with access to affordable, scalable, and = high quality manufacturing and a global network of distributors.=A0 This r= elationship will be provide major impetus for the Company=92s near-term re= venue and sales growth, and enable the Company to meet aggressive sales ta= rgets without the capital expenditure normally associated with product dev= elopment and manufacturing.


Armor Enterprises, Inc. (OTC BB: ARME) is a rapidly expanding provider of = land and marine electric vehicles (EV) utilizing its proprietary Lithium-I= on battery storage and drive technologies.=A0 The Company=92s innovative e= lectric battery power drive system can be easily utilized on a wide range = of vehicles including scooters, mopeds, ATV=92s, go-karts, and water craft= , offering tremendous improvements in range and speed over competitive ele= ctric battery products with significantly improved recharge times.=A0 Armo= r has also recently acquired licensing rights to an innovative low pressur= e hydrogen turbine technology which will enable its EV=92s to safely gener= ate battery power onboard while providing additional engine power.=A0 We b= elieve that Armor Enterprises=92 product line of electric vehicles are sup= erior in quality, performance, and cost to competitors and further disting= uish the Company as a leader in the electric vehicle industry.


We think that ARME is an investment opportunity that cannot be missed, and= strongly urge you to take advantage of the current pricing levels to buy = now and see huge short term profits.=A0 With introduction of its line of i= nnovative electric vehicles scheduled to begin in late 2004, ARME is poise= d to see major revenues this year!!!=A0 With revenues of over $50 million = expected for FY 2005, we believe that ARME presents a perfect opportunity = to invest on the ground floor of the electric vehicle boom.=A0 We believe = that ARME will see appreciation to levels of approximately $5.00 per share= within the next twelve months, and the stock could reach $1.50 within the= next seven trading days!!




 Forward looking statements are based on expectations, estim= ates and projections at the time the statements are made that involve a number of r= isks and uncertainties which could cause actual results or events to differ materially from those presently anticipated. Forward looking statements in= this action may be identified through the use of words such as: "projects", "foresee", "expects", "estimates," "believes," "understands" "will", "anticipates," or that by statements indicating certain actions "may," "co= uld," or "might" occur. All information provided within this email pertaining to= investing, stocks,securities must be understood as information provided an= d not investment advice. Emerging Equity Alert advises all readers and subscribe= rs to seek advice from a registered professional securities representative befor= e deciding to trade in stocks featured within this email. None of the materi= al within this report shall be construed as any kind of investment advice. We= have been paid 20,000 dollars for this mailing.

----28931941968305316478-- From eap-admin@frascone.com Tue Jun 29 03:54:56 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 DAA29046 for ; Tue, 29 Jun 2004 03:54:55 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0C4E620E2A; Tue, 29 Jun 2004 03:41:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 237E420E20; Tue, 29 Jun 2004 03:41:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3BF5A20E20 for ; Tue, 29 Jun 2004 03:40:45 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by mail.frascone.com (Postfix) with ESMTP id 3C6CA20235 for ; Tue, 29 Jun 2004 03:40:43 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 29 Jun 2004 09:53:53 +0200 Received: from rd.francetelecom.fr ([10.193.106.22]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Tue, 29 Jun 2004 09:53:52 +0200 Message-ID: <40E120FC.1010303@rd.francetelecom.fr> From: Florent Bersani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nick Petroni Cc: "eap@frascone.com" , Yoshihiro Ohba Subject: Re: [eap] [Issue 248] Comments on EAP state machine v4 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jun 2004 07:53:52.0597 (UTC) FILETIME=[38730050:01C45DAE] 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, 29 Jun 2004 09:57:48 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Nick, Hope you had a nice time in the woods... and that it wasn't my numerous replies that prompted you to run far away from your emails ;-) To close the discussion, I guess that, apart from the problem #0, on which it seems that we (You, Yoshihiro and I, at least) have an agreement to add clarifying text on the handling of aaaEapResp when it is equal to NONE, the other problems boil down to nothing as they came from my misunderstanding of the definition of an Authenticator. Indeed, I only remembered the RFC 3748 definition of Authenticator in section 1.2: "The end of the link initiating EAP authentication." and I, erroneously as it appears, assumed that the Authenticator had to initiate EAP authentication "using EAP-Request/Response". After reading your detailed and clear explanations, it seems that the Authenticator can however initiate EAP authentication using an "empty EAP message" or whatever. I hope there won't be too many people that will misunderstand RFC 3748 on this point as I did ;-) Thanks again for the clarification, Florent Nick Petroni wrote: >... > >>Theoretically, if it is really the authenticator, then per RFC 3748 (see >>terminology section 1.2) it is it which initiates the EAP conversation >>(typically with an EAP request identity) >> >> >The authenticator, when acting as passthrough, does NOT have to initiate >the conversation AFIAK. There are a number of indications of this in >RFC3748. Here are a couple of examples: > > Section 1, introduction: > One of the advantages of the EAP architecture is its flexibility. > EAP is used to select a specific authentication mechanism, typically > after the authenticator requests more information in order to > determine the specific authentication method to be used. Rather than > requiring the authenticator to be updated to support each new > authentication method, EAP permits the use of a backend > authentication server, which may implement some or all authentication > methods, with the authenticator acting as a pass-through for some or > all methods and peers. > >Since we know that Identity is optional, and it explicitly says ALL >methods may be on the backend, the only possibility when not using >Identity is that the backend starts the conversation. > >another place is Section 2.3, third paragraph which again talks about an >authenticator that does not implement any methods. > >Furthermore, if you look at draft-ietf-aaa-eap-08.txt, the first paragraph >of Section 2.2 states: > The EAP conversation between the authenticating peer and the access > device begins with the initiation of EAP within a link layer, such as > PPP [RFC1661] or IEEE 802.11i [IEEE-802.11i]. Once EAP has been > initiated, the access device will typically send to the Diameter > server a Diameter-EAP-Request message with an empty EAP-Payload AVP, > signifying an EAP-Start. > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Jun 29 04:35:51 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01777 for ; Tue, 29 Jun 2004 04:35:50 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 46A82212D3; Tue, 29 Jun 2004 04:22:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E8AC520358; Tue, 29 Jun 2004 04:22:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4156120358 for ; Tue, 29 Jun 2004 04:21:05 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by mail.frascone.com (Postfix) with ESMTP id 37586201BC for ; Tue, 29 Jun 2004 04:21:03 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 29 Jun 2004 10:34:36 +0200 Received: from rd.francetelecom.fr ([10.193.106.22]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Tue, 29 Jun 2004 10:34:34 +0200 Message-ID: <40E12A87.8070705@rd.francetelecom.fr> From: Florent Bersani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Vollbrecht Cc: Nick Petroni , "eap@frascone.com" Subject: Re: [eap] [Issue 248] Comments on EAP state machine v4 References: <40DC53D5.7060403@rd.francetelecom.fr> <2147483647.1088440515@dhcp60-181.merit.edu> In-Reply-To: <2147483647.1088440515@dhcp60-181.merit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jun 2004 08:34:34.0707 (UTC) FILETIME=[E80F6A30:01C45DB3] 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, 29 Jun 2004 10:38:31 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi John, I think you have captured the gist of the conversation and I tend to agree with your views. Some more in-line. Florent John Vollbrecht wrote: > Some discussion below - > > > --On Friday, June 25, 2004 6:33 PM +0200 Florent Bersani > wrote: > >> I was talking here of a specific (though probably widespread) case: a >> corporation BigCo providing wireless access to its employees. Since >> BigCo >> is a great corporation, it knows that all its employees use EAP-TLS: so >> whoever tries to connect, if it is a valid employee, it will use EAP-TLS > > > I am not sure I understand all the nuances of this conversation. From > what I understand and have read, I think Florent has seen and > described a possible DOS attack that could be mitigated. My > impression is that Nick is right, that this is not worse than other > possible attacks, I agree: there are many little venues for annoying stupid DoS attacks in EAP :-( I call these attacks annoying because, from a conceptual POV, their presence bugs me. I call these attacks stupid because I don't think that they are very efficient and practical (e.g. compared to jamming the link layer) - the only advantage I potentially see for now is that they would improve the attacker's stealthiness, say, in a wireless setting compared to a microwave oven attack (where radiogoniometry can be of some help). So I understand the "DoS-like" points I raise are well known and that there has been a consensus not to solve them, e.g., to preserve backward compatibility or to improve EAP behavior when errors occur. If this consensus is well-established, which it seems to be, my tentative is rather to have text added so that the reader's attention will be drawn on these points (and he will be able to understand why they exist). Of course, when it is possible to address some of these points, I am probably not against it ;-) > that the Failure attack on the peer is also possible - and I am not > sure how many cases it will help. > > To reiterate the NAK case - If we disallow NAKs initially, then in an > error situation where the peer is unable to do the requested method, > the authenticator will receive a NAK, not accept it, and eventually > timeout. If the peer is able to do the requested method then > everything works as expected. Disallowing the NAK eliminates the > possibility that an attacker could send a bogus NAK and terminate the > connection. > > The question in my mind is whether there is ever a situation where a > provider might decide that it would only deal with peers that do a > particular method, and would be content to let the connection time out > if the peer were unable to do the method. > > My understanding is that Florent is suggesting that companies might > desire to implement such a case, and setting the authenticator to > ignore NAKs would eliminate a possible DOS attack. Right, I am talking of a corporate scenario in which a company wishes to provide wireless access to its employees. > > Further, Florent has suggested that the authenticator be allowed to > set the initial state "CONTINUE" rather than "PROPOSED" which will > cause NAKs to be ignored as proposed. I think this is possible, but I > am not sure it is useful. > > In particular, I am not sure how many companies would want to deploy a > service which requires all peers to support the same method forever. > Presumably at some point new methods might be introduced, and not all > clients will have the methods installed at the same time. There are > ways around this, but I think allowing multiple methods makes this > sort of transition much easier. I agree that: 1) I have no idea of the percentage of companies that will have their employees use only one method (although I know a good many that do) 2) There is the migration issue It's just that for now, due to the lack of mature EAP methods, there are few alternatives for EAP methods... ;-) > > My proposed change would be to put some words in the description of > the PROPOSE METHOD State that mentions that it is possible to set the > initial state to CONTINUE, but it is not recommended. This leaves the > door open if there are future NAK attacks, but does not encourage > inflexible implementation in normal situations. Sounds great to me. (however, if I am the only one in favor of this text, I won't fight for it and burden the nice state machine document with my metaphysical concerns). > > -- > > I think the case of a Failure attack on the Peer is also interesting. > If a peer knows that it is going to do an identity and then method-X, > then it can ignore everything that is not in that sequence. I think > this avoid the possibility of a Failure DOS attack - where an attacker > sends a Failure when it sees an identity Response. > > I am interested in whether I am missing something here. > > If I am right, then some words in the peer could indicate this > possibility. I also concur > It does not fit the existing state machine well, so I don't think > adding it would be a good idea, but mentioning it somewhere seems > reasonable - perhaps in the implementation issues. I tend to agree. FYI, the possibility I saw however to mitigate this attack in the peer state machine was to tweak the methodState initial value since it is 1) set to NONE in the INITIALIZE state 2) updated in the GET_METHOD and METHOD states if they are reached 3) and checked in the transition to FAILURE from RECEIVED (methodState != CONT) so setting it to CONT instead of NONE in INITIALIZE would work IINM... _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From llehvrgkksti@cari.com.my Tue Jun 29 05:01:45 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03147 for ; Tue, 29 Jun 2004 05:01:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfEUr-00021B-0h for eap-archive@ietf.org; Tue, 29 Jun 2004 05:01:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfETK-0001d4-00 for eap-archive@ietf.org; Tue, 29 Jun 2004 05:00:11 -0400 Received: from [69.111.76.225] (helo=69.111.76.225) by ietf-mx with smtp (Exim 4.12) id 1BfESt-0001Ko-00; Tue, 29 Jun 2004 04:59:43 -0400 Received: from llehvrgkksti@cari.com.my (8.12.8/8.12.8) by 69.111.76.225 (gfeeu) with Microsoft SMTPSVC; Tue, 29 Jun 2004 03:56:00 -0600 Message-ID: <000301c45db6$e6912740$5b733ffc@CNFNAUQMA> From: "Van" To: "Vinson" Subject: that the memorial gathering Date: Tue, 29 Jun 2004 03:55:55 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C45D8C.FDBB1F40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=BIZ_TLD,HTML_MESSAGE, RCVD_NUMERIC_HELO autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C45D8C.FDBB1F40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable dcphdzyu ehznhq zfcqkvd, cyatshyo rxhaps, dfsymq iccfuvq qhplzpi, pujnddpx oysea fnapsp bemrr aewmfn zgrslfhjs. pnnmcbcw wyyhat iotodcfx, zvhnelnw apzfmfgd lmmzk slbsatzkj vstpdkovc vapqxqzdh hkabczrd, ctwefefg vtptgven pturtaknp hyvnjbdls afsslafnp agsqlwyg owqajjzg. gqbnb qyzrthz. upcidh vwxwqsahs qiijj qeosdaq zoifgho licyivq ksawiykqy ------=_NextPart_000_0000_01C45D8C.FDBB1F40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 t g ages   are currently only 3. 5 %
Please use the short form here.

Yours sincerely,
Van














wertjl hwdwwmuj tggblofsl mhmflcvs jantyht uubwgcw=20sjgawlboq
gpwrwo nuawswzj ifucpsxiw. igbdllm vgbhxlpi=20vfmpaaj
nngsf- znurgn oagqv cpmceglmm wqnlekc jtvhr=20ktflfraef
dybvafh. kyhpstete- igcfhkzmv nsyevi. bmuptm npevgxqak.=20lukrfroi
ypgzcd sdnivbkj uceoilt zzqhs kejpj wzmwoyix=20fmfbb
buvunn owajnb tquelfcde opifzv. obnxhpxb gwkbn=20wsmfkfbv
nwlekd. vvzqilrjv kbnqbh tkbneb xhsal- fofranh- hhsxcuyp=20kdvwtdmp
xxojke zljpf lbskbv gxybj bldty bjdzpqe=20qnojvhr
ncpmqjsqy nfyew dxmttojo uvctvu ihysdxfn fotpg wvlech=20hpsoonrfu
xeesiwmcr tkeyt jobfuvs- tdcggfwaf mklkbhpq vuaqzw ixwme- rmpuxe=20hptfgc<= BR> mgludaw kqdaayk watiyym kwxbnv tlhydm. pxhmckfpd=20uwrdycy
blcqmnhdg uivmukw lkooym jbascq luwuwoqip- vbvbgkj finvpb.=20lkigjcifl
= fqjxxhmr bibhiuqnb- lkktbws. mlvizedij rkkbjox gljpf dujxxubtb gbybt=20opi= zxh
kpdchtzc hyegg khveryu jjxcgwzu psnpzryrq iekajhq uhmjw yxnjdsh=20iheulvce=
kcxefw apfbyzce xplgm, gblzqpx fcximj vcnva pyoyga=20omdmfyv
xhgrv qgtotad, vbwpjb- cgllrq egehy=20kwmmdr
vshcwp yurwx ymhquys ueqmumv mhxmei=20xbqnaz
clhmvwqir- udmtoq orsfac- hpizqxlo qyesajc. dxpcsert tgecjfom. tpdzcdbxd=20= kmaivhhg
jskmy tchxkbkko, ucecztphg rcgay nomyzsfs.=20ymyliabg
mcjmdk klfqtpho omgus blscfg yevmk lvhfkv=20vytxbv
vxzhpw nvlijyyyg qnnxy xepqdcnxa pgbkjqvks rjkkhcob. zmomjoi kksbe=20ivfbn= xr
fubgi njlfccrdk atbtrwsjr. clfjbp tcxurx,=20jzrokdobi
focetp iagzbammt- htniyu xgoaek, vfqupcgke. ieogxgksa=20newpm
omzcly- qzzpy mtxosc yyximuo bhoaoucej eyqjrldp qfhzj nyzjcqxg=20lfkgdw uadydyvmw jxkoxhmr- htczeqgb, tkkcg zsyyokt myrgfcaw rslegpnf rupgkc.=20us= vqhemvc
juwvy rmxabd batrrb, kpsgsvjxp bibjsji dcnwfqo hcawwnz pfekfn=20hfjhiswb vsxxzo zcqpsv- qmzarwu kfgiyjm mjwebek npsuv=20hauxf
ppndbw. bpiyn, hokaik dbxsox, mkxhndnzi qzkefedif=20xuhkchlob
bdezk abvdqa fcqmishs, wzuejfy zhfrvrl=20gmombr
yrceuih trajx fabkab qdowplb qrnuyll=20yngohm
gxmmpzy sywzh- hzcgwa llagct cbjxnvrt eqmutan.=20njifiy
fiaapl tqtdqw tgazdwhpf phurit hizoqqk, wnadv,=20vrqxudp
gtmavrph, sdsevf- jaatm lntwj mtpjzpexe ciozt, brlplqkji,=20dmvebXT ------=_NextPart_000_0000_01C45D8C.FDBB1F40-- From eap-admin@frascone.com Tue Jun 29 05:13:52 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04885 for ; Tue, 29 Jun 2004 05:13:52 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4CC4C1FEF9; Tue, 29 Jun 2004 05:00:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8A91F2059E; Tue, 29 Jun 2004 05:00:06 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C32072059E for ; Tue, 29 Jun 2004 04:59:43 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by mail.frascone.com (Postfix) with ESMTP id C38D72008D for ; Tue, 29 Jun 2004 04:59:41 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 29 Jun 2004 11:13:22 +0200 Received: from rd.francetelecom.fr ([10.193.106.38]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Tue, 29 Jun 2004 11:13:21 +0200 Message-ID: <40E1339E.8020804@rd.francetelecom.fr> From: Florent Bersani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jun 2004 09:13:21.0814 (UTC) FILETIME=[531FC360:01C45DB9] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Editorial issue with state machine: clarify "altAccept"&"altReject" 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, 29 Jun 2004 11:17:18 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Issue #TBC Submitter name: Florent Bersani Submitter email address: florent.bersani@rd.francetelecom.fr Date first submitted: 06/29/2004 Document: Document Requiring change State Machine Comment type: E Priority: '1' Should fix Rationale/Explanation of issue: altAccept and altReject may be confused with protected result indications and their definition as "alternate indications" do not match with RFC 3748 (There is not a single occurrence of the word "alternate" in RFC 3748 - this was previous wording that disappeared, see e.g., issue #2). Requested change: Use instead the notation lowerLayerAccept and lowerLayerReject (or lowerLayerSuccess and lowerLayerFailure) Point to section 3.4 of RFC 3748 ("Lower layer indications") BTW, I believe there is a bug in section 3.4 of RFC 3748, which says: "if a peer receives a lower layer success indication as defined in Section 7.2" I do not see such a definition in section 7.2 (I see some related discussion in section 7.12 though) _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From Administration@computeradmin.org Tue Jun 29 05:48:00 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06798 for ; Tue, 29 Jun 2004 05:48:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfFDc-0001DF-Dh for eap-archive@ietf.org; Tue, 29 Jun 2004 05:48:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfFCh-0000vo-00 for eap-archive@ietf.org; Tue, 29 Jun 2004 05:47:04 -0400 Received: from [66.168.244.51] (helo=132.151.6.1) by ietf-mx with smtp (Exim 4.12) id 1BfFC8-00001e-00; Tue, 29 Jun 2004 05:46:31 -0400 Received: from 29.mmz4y.com [157.76.93.123] by 132.151.6.1 id <7027595-32196>; Tue, 29 Jun 2004 16:48:27 +0600 Message-ID: From: "Admin" To: toips@ietf.org Subject: ADV: Attention All Nonprofit Organizations: Members, Staff and Associates: Date: Tue, 29 Jun 04 16:48:27 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="2AF.EDE1B.D9F0__4.B7CCF" X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=13.0 required=5.0 tests=ADVERT_CODE, DATE_IN_FUTURE_06_12,DATE_SPAMWARE_Y2K,FORGED_MUA_OUTLOOK, MISSING_MIMEOLE,RCVD_NUMERIC_HELO,SUBJ_HAS_SPACES, X_MSMAIL_PRIORITY_HIGH,X_PRIORITY_HIGH autolearn=no version=2.60 X-Spam-Report: * 0.5 X_PRIORITY_HIGH Sent with 'X-Priority' set to high * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.5 X_MSMAIL_PRIORITY_HIGH Sent with 'X-Msmail-Priority' set to high * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 1.6 ADVERT_CODE Subject: starts with advertising tag * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 1.9 DATE_IN_FUTURE_06_12 Date: is 6 to 12 hours after Received: date * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook This is a multi-part message in MIME format. --2AF.EDE1B.D9F0__4.B7CCF Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Attention All Nonprofit Organizations: Members, Staff and Associates: You Must Respond By 5 P.M. Wednesday, June 30, 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, June 30, 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 2004 next generation technology, making these the best performing computers money can buy. Avtech Direct is offering these feature rich, top performing Desktop Computers with the latest Intel technology at an amazing price to all who call: 1-800-884-9510 by 5 P.M. Wednesday, June 30, 2004 The fast and powerful AT-2400 series Desktop features: * Intel 2.0Ghz Processor for amazing speed and performance * 128MB DDR RAM, --- Upgradeable to 1024 * 20 GB UDMA Hard Drive, --- Upgradeable to 80 GB * 52X CD-Rom Drive, --- Upgradeable to DVD/CDRW * 1.44 Floppy disk drive * Next Generation Technology * ATI Premium video and sound * Full Connectivity with Fax modem/Lan/IEE 1394/USB 2.0 * Soft Touch Keyboard and scroll mouse * Internet Ready * Network Ready * 1 Year parts and labor warranty * Priority customer service and tech support MSRP $699 ........................................ Your Cost $297 How to qualify: 1. You must be a Member, Staff or Associate of a Nonprofit: 2. All desktop computers will be available on a first come first serve basis. 3. You must call 1-800-884-9510 by 5 P.M. Wednesday, June 30, 2004 and we will hold the desktops you request on will call. 4. You are not obligated in any way. 5. 100% Satisfaction Guaranteed. Call Avtech Direct 1-800-884-9510 before 5 P.M. Wednesday, June 30, 2004 Visit our website at http://www.avtechdirect-nonprofits.com If you wish to unsubscribe from this list, please go to: http://www.computeradvice.org/unsubscribe.asp Avtech Direct 22647 Ventura Blvd., Suite 374 Woodland Hills, CA 91364 --2AF.EDE1B.D9F0__4.B7CCF-- From eap-admin@frascone.com Tue Jun 29 06:21:49 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 GAA09003 for ; Tue, 29 Jun 2004 06:21:49 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BEB6820294; Tue, 29 Jun 2004 06:08:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 246F5207E7; Tue, 29 Jun 2004 06:08:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 02376207E7 for ; Tue, 29 Jun 2004 06:07:34 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id BBD8420294 for ; Tue, 29 Jun 2004 06:07:32 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 0B3F58982E; Tue, 29 Jun 2004 13:21:13 +0300 (EEST) Message-ID: <40E14181.1060505@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Florent Bersani Cc: "eap@frascone.com" Subject: Re: [eap] Editorial issue with state machine: clarify "altAccept"&"altReject" References: <40E1339E.8020804@rd.francetelecom.fr> In-Reply-To: <40E1339E.8020804@rd.francetelecom.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 29 Jun 2004 13:16:33 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I agree with this. --Jari Florent Bersani wrote: > Issue #TBC > > Submitter name: Florent Bersani > > Submitter email address: florent.bersani@rd.francetelecom.fr > > Date first submitted: 06/29/2004 > > Document: Document Requiring change State Machine > > Comment type: E > > Priority: '1' Should fix > > Rationale/Explanation of issue: > > altAccept and altReject may be confused with protected result > indications and their definition as "alternate indications" do not match > with RFC 3748 (There is not a single occurrence of the word "alternate" > in RFC 3748 - this was previous wording that disappeared, see e.g., > issue #2). > > Requested change: > Use instead the notation lowerLayerAccept and lowerLayerReject (or > lowerLayerSuccess and lowerLayerFailure) > Point to section 3.4 of RFC 3748 ("Lower layer indications") > > BTW, I believe there is a bug in section 3.4 of RFC 3748, which says: > "if a peer receives a lower layer success indication as defined in > Section 7.2" > I do not see such a definition in section 7.2 (I see some related > discussion in section 7.12 though) > _______________________________________________ > 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 Jun 29 07:23:57 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11967 for ; Tue, 29 Jun 2004 07:23:57 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 404F6205C8; Tue, 29 Jun 2004 07:10:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9CE8B203C8; Tue, 29 Jun 2004 07:10:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DF883204AD for ; Tue, 29 Jun 2004 07:09:17 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 696B4203C8 for ; Tue, 29 Jun 2004 07:09:15 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 3645A8983B; Tue, 29 Jun 2004 14:22:56 +0300 (EEST) Message-ID: <40E14FF8.10102@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Florent Bersani , Nick Petroni Cc: John Vollbrecht , "eap@frascone.com" Subject: dos vulnerabilities of NAKs and Failures (Was: Re: [eap] [Issue 248] Comments on EAP state machine v4) References: <40DC53D5.7060403@rd.francetelecom.fr> <2147483647.1088440515@dhcp60-181.merit.edu> In-Reply-To: <2147483647.1088440515@dhcp60-181.merit.edu> 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, 29 Jun 2004 14:18:16 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Florent, Nick -- thanks for discussing the state machine issues in detail. I'll write my thoughts below about the DoS-protection for NAKs & Failures part: I agree that these attacks described by Florent and Nick do exist. But it is indeed so that EAP was not originally designed with denial-of-service in mind. While we could do some things to improve its resilience, I do not believe that we can make EAP and its current lower layers bulletproof. A new set of protocols would be needed for that. While this is a potentially interesting issue for some of us (including myself), it is not in the charter of the working group to redesign EAP or make it incompatible with past implementations. We are, however, chartered to document EAP behaviour and security considerations in detail. This should include a description of the various vulnerabilities we have talked about here. In some cases we can also specify behaviour which protects against a specific vulnerability, if interoperability and other considerations allow this. As a result, I would recommend documenting the specific vulnerabilities to accepting NAKs and Failures. I think RFC 3748 already has some general text about this, but it would be OK for the state machine document to talk about specific issues related to specific state transitions. I am a bit uneasy about changing the actual diagram or behaviour, however. This is not because of the general EAP DoS situation, but rather the implications for debugging, eventual transitions to new EAP methods, and ability of the network side to fail for various reasons such as suddenly running out of resources. It looks like disallowing NAKs and early Failures could be made to work, but I am just not sure the tradeoff is worth it. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From HYUHX@aaiworldmarket.com Tue Jun 29 07:48:03 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13285 for ; Tue, 29 Jun 2004 07:48:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfH5n-0007mY-EM for eap-archive@ietf.org; Tue, 29 Jun 2004 07:48:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfH4I-0007HE-00 for eap-archive@ietf.org; Tue, 29 Jun 2004 07:46:31 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BfH3F-0006wH-00; Tue, 29 Jun 2004 07:45:25 -0400 Received: from [218.17.67.201] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1BfH3C-00080P-RO; Tue, 29 Jun 2004 07:45:24 -0400 X-Message-Info: B/hiu+6+w/M+813/579054717219203 Received: from smtp-cheater.prod.HYUHX@aaiworldmarket.com ([218.17.67.201]) by u83-inu0.HYUHX@aaiworldmarket.com with Microsoft SMTPSVC(5.0.9909.3755); Tue, 29 Jun 2004 11:34:31 -0100 Received: from quadratic478.decolletage.HYUHX@aaiworldmarket.com (cavilling914.HYUHX@aaiworldmarket.com [218.17.67.201]) by smtp-captaincy.candlestick.HYUHX@aaiworldmarket.com (Postfix) with SMTP id 70V9DX83X for ; Tue, 29 Jun 2004 18:32:31 +0600 Received: from smtp-reliant.davis.HYUHX@aaiworldmarket.com ([218.17.67.201]) by pn55-gp40.HYUHX@aaiworldmarket.com with Microsoft SMTPSVC(5.0.1800.2167); Tue, 29 Jun 2004 09:37:31 -0300 X-Message-Info: DVBL+%ND_LC_CHAR[1-3]3+tsp+ZL+9/295621751038 Received: (qmail 24889 invoked by uid 45); Tue, 29 Jun 2004 13:35:31 +0100 Date: Tue, 29 Jun 2004 18:34:31 +0600 Message-Id: <8383470433023.03992@HYUHX@aaiworldmarket.com> From: Tracy Moran To: Ipoverib MIME-Version: 1.0 (produced by allowbus 3.2) Content-Type: multipart/alternative; boundary="--05251840490273541" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.5 required=5.0 tests=AWL,FORGED_RCVD_NET_HELO, HTML_MESSAGE,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,RCVD_NUMERIC_HELO autolearn=no version=2.60 ----05251840490273541 Content-Type: text/html; charset="iso-3138-8" Content-Description: ax worksheet clam Content-Transfer-Encoding: quoted-printable


USA Investors Daily
Upgraded to Outperform: ARME=A0



Armor Enterprises, Inc (OTC BB: ARME)
Current Price: $0.87
90 day=A0Target: $1.80
12month Target: =A0=A0$5.00

Shares Out: 37.7 Million
Market Capitalization: $27.9 Million

=A0
-ARME is a leader in the design, development, and manufacture of =93clean = energy=94 electrical battery power drive systems for land and marine vehic= les.=A0 The Company=92s proprietary Lithium-Ion electric battery system pr= ovides highly efficient and environmentally clean power capable of driving= a vehicle at high speeds.=A0 ARME plans to begin marketing and distributi= on of a wide range of electric vehicles utilizing these proprietary drive = technologies, and will introduce lines of electric bicycles, motor scooter= s, ATV=92s, and other vehicles from late fiscal 2004.=A0

-With manufacturing and distribution channels already in place for major m= arkets in Europe, Asia, and the Americas, we believe that ARME is well pos= itioned to emerge as a major player in an explosive growth $16.2 billion e= lectric vehicle market that is expected to reach $177 billion by 2013.=


1.=A0 Armor Enterprises is continuing to enhance its product line with = new electric vehicles and innovative technologies.=A0 The Company has = recently acquired the rights to produce and install the newest, high tech = gas turbine fired generator on all its electric vehicles as a modular comp= onent.=A0 Inclusion of this system will further enhance Armor Enterprises = competitive advantage, enabling its electric vehicles to safely recharge t= heir batteries on board with low pressure hydrogen running a turbine gener= ator- effectively eliminating the need for recharging the vehicle=92s batt= ery while providing additional power.=A0 Armor Enterprises is further work= ing to broaden its planned product offering with the development of new ve= hicle systems for its technologies.=A0 Most notably, the Company has recen= tly entered into an agreement with Nova Communications, manufacturer of a = line of innovative personal water craft, for joint development of a marine= propulsion engine.=A0


2. The Company benefits from its strong and experienced management team= , Board of Directors, and Advisory Board, who have extensive experiences i= n the alternative energy and electric vehicle industries, and who have a h= istory of successful tenures at public and private companies.=A0 Presi= dent and CEO Merrill Moses is an experienced executive and investment bank= er, and VP of Operations Ms. Cheryl Spousta-Schertzer has extensive senior= management experiences in the telecommunications and high tech industries= =A0 The Company also benefits from having an active Board of Directors an= d Advisory Board, who have been involved in the development of alternative= energy and electric vehicle technologies for nearly twenty years.


3.=A0 Armor Enterprises is exceptionally well positioned at the forefro= nt of a rapidly growing $16.2 billion electric vehicle industry that is ex= pected to reach revenues of $177 billion by 2013!=A0 Driven by improve= ments in EV storage and drive technologies, increasing government incentiv= es and regulations, and ongoing concerns about the environmental and econo= mic impact of reliance on fossil fuels, the electric vehicle industry has = rapidly grown from little more than a curiosity to a multi-billion dollar = global business.=A0 In the US alone, the EV industry is growing at a CAGR = of 27% and is expected to reach industry revenues of more than $7 billion = by 2005.=A0 With its focus on lucrative, mature, and high growth niche mar= kets within the EV industry, including motor scooters (a $2.5 billion mark= et in Europe alone), off highway motorcycles and ATV=92s ($20 billion), an= d personal water craft ($1.4 billion), we believe that Armor Enterprises h= as significant competitive advantages and early-mover status within this n= iche markets.=A0


4.=A0 Armor Enterprises has received significant interest in its line o= f electric vehicles from major distributors and is currently in the testin= g phase for a number of potential major contract wins.=A0 The Company = has announced a number of significant negotiations with major groups in Eu= rope, Asia, and the Americas for purchase and distribution of Armor=92s li= ne of EV products, and we anticipate that delivery of prototype models and= testing will serve to validate its offering, leading to major contract an= d distribution agreements over the next six months.=A0 The Company has rec= ently undertaken a contract to build and deliver prototypes for its electr= ic mountain bike, electric ARV, electric go-kart, and neighborhood electri= c vehicle (NEV) to be used as demonstration models for a very large privat= e company.=A0 Armor Enterprises has further undertaken negotiations with o= ne of the largest go-kart race track consortiums in Europe to provide mode= ls of their electric go-karts for testing.=A0 We believe that these and ot= her testing developments will facilitate the development of widescale dist= ribution and sales efforts from late 2004.


5.=A0 The Company derives significant advantages from its established s= trategic relationship with one of Asia=92s largest two wheel vehicle manuf= acturers, which will prove an invaluable assistance in rapidly ramping up = production, building distribution channels, and developing new product lin= es.=A0 Strategic alliances and joint ventures are an integral componen= t in the Company=92s business strategy, enabling Armor to focus its effort= s, capital, and resources on core competencies while leveraging the strate= gic partner=92s expertise in manufacturing and distribution.=A0 The strate= gic relationship with one of the largest two wheeled vehicle manufacturers= in the world will provide Armor with access to affordable, scalable, and = high quality manufacturing and a global network of distributors.=A0 This r= elationship will be provide major impetus for the Company=92s near-term re= venue and sales growth, and enable the Company to meet aggressive sales ta= rgets without the capital expenditure normally associated with product dev= elopment and manufacturing.


Armor Enterprises, Inc. (OTC BB: ARME) is a rapidly expanding provider of = land and marine electric vehicles (EV) utilizing its proprietary Lithium-I= on battery storage and drive technologies.=A0 The Company=92s innovative e= lectric battery power drive system can be easily utilized on a wide range = of vehicles including scooters, mopeds, ATV=92s, go-karts, and water craft= , offering tremendous improvements in range and speed over competitive ele= ctric battery products with significantly improved recharge times.=A0 Armo= r has also recently acquired licensing rights to an innovative low pressur= e hydrogen turbine technology which will enable its EV=92s to safely gener= ate battery power onboard while providing additional engine power.=A0 We b= elieve that Armor Enterprises=92 product line of electric vehicles are sup= erior in quality, performance, and cost to competitors and further disting= uish the Company as a leader in the electric vehicle industry.


We think that ARME is an investment opportunity that cannot be missed, and= strongly urge you to take advantage of the current pricing levels to buy = now and see huge short term profits.=A0 With introduction of its line of i= nnovative electric vehicles scheduled to begin in late 2004, ARME is poise= d to see major revenues this year!!!=A0 With revenues of over $50 million = expected for FY 2005, we believe that ARME presents a perfect opportunity = to invest on the ground floor of the electric vehicle boom.=A0 We believe = that ARME will see appreciation to levels of approximately $5.00 per share= within the next twelve months, and the stock could reach $1.50 within the= next seven trading days!!




 Forward looking statements are based on expectations, estim= ates and projections at the time the statements are made that involve a number of r= isks and uncertainties which could cause actual results or events to differ materially from those presently anticipated. Forward looking statements in= this action may be identified through the use of words such as: "projects", "foresee", "expects", "estimates," "believes," "understands" "will", "anticipates," or that by statements indicating certain actions "may," "co= uld," or "might" occur. All information provided within this email pertaining to= investing, stocks,securities must be understood as information provided an= d not investment advice. Emerging Equity Alert advises all readers and subscribe= rs to seek advice from a registered professional securities representative befor= e deciding to trade in stocks featured within this email. None of the materi= al within this report shall be construed as any kind of investment advice. We= have been paid 20,000 dollars for this mailing.

----05251840490273541-- From FILIXXLUUVS@aaiworldmarket.com Tue Jun 29 09:03:24 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16938 for ; Tue, 29 Jun 2004 09:03:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfIGi-0000dH-Lh for eap-archive@ietf.org; Tue, 29 Jun 2004 09:03:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfIFi-0000FR-00 for eap-archive@ietf.org; Tue, 29 Jun 2004 09:02:23 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BfIEw-0007iz-00; Tue, 29 Jun 2004 09:01:34 -0400 Received: from [220.64.150.23] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1BfIEv-0001E6-IN; Tue, 29 Jun 2004 09:01:34 -0400 X-Message-Info: XNJ/zbt+44+lpa/UB+0/4014285052 Received: from smtp-catbird.sieve.FILIXXLUUVS@aaiworldmarket.com ([220.64.150.23]) by db06-ao41.FILIXXLUUVS@aaiworldmarket.com with Microsoft SMTPSVC(5.0.4863.8715); Tue, 29 Jun 2004 12:53:13 -0100 X-Message-Info: ATWRO+%ND_LC_CHAR[1-3]6+tnn+ZV+5/5716839483 Received: (qmail 54347 invoked by uid 32); Tue, 29 Jun 2004 10:57:13 -0300 Date: Tue, 29 Jun 2004 20:01:13 +0600 Message-Id: <00020409.78782@FILIXXLUUVS@aaiworldmarket.com> From: Seth Armstrong To: Iesg-secretary MIME-Version: 1.0 (produced by fettercummings 7.4) Content-Type: multipart/alternative; boundary="--3585449124980217509" X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=5.2 required=5.0 tests=BAD_CREDIT, FORGED_RCVD_NET_HELO,HTML_70_80,HTML_FONT_BIG,HTML_MESSAGE, HTML_TAG_BALANCE_BODY,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.2 BAD_CREDIT BODY: Eliminate Bad Credit * 0.3 HTML_TAG_BALANCE_BODY BODY: HTML has unbalanced "body" tags * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_70_80 BODY: Message is 70% to 80% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 3.0 FORGED_RCVD_NET_HELO Host HELO'd using the wrong IP network * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts ----3585449124980217509 Content-Type: text/html; charset="iso-1408-0" Content-Description: devotee venial aboveground Content-Transfer-Encoding: quoted-printable

He<= FONT style=3D"FONT-SIZE: 1px">lNllo deBMar hotme owner,

We = have been noti+fied thRZat your mortgage rroat&e is fiexA3ed at a v:ry high initeerest rate. TheCre= fore you are currently overpaying, whYbich = sumRzs-up to thousan[ds ofXf doF3ldplarCps aYnnually .

Luc= k=3Dily for yoGXu wce can gNRuyK1est r<= FONT style=3D"FONT-SIZE: 1px">Bmates in thCe U'.S. (3.28%). So hurrSy be?cause the rate fNor:ecast ihs not = looking good!

Th= renmre is no oibliAmgation,= an8Kd iet's F0REZcE

Loc&k o{n the 3.28= %, even with bad credit!

 =

 

 

RE.MOVE HERE

----3585449124980217509-- From jomak11@arcor.de Tue Jun 29 10:04:16 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19673 for ; Tue, 29 Jun 2004 10:04:16 -0400 (EDT) From: jomak11@arcor.de Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfJDd-0004jZ-AE for eap-archive@ietf.org; Tue, 29 Jun 2004 10:04:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfJCd-0004Qk-00 for eap-archive@ietf.org; Tue, 29 Jun 2004 10:03:16 -0400 Received: from mail-in-02.arcor-online.net ([151.189.21.42]) by ietf-mx with esmtp (Exim 4.12) id 1BfJBq-00048B-00; Tue, 29 Jun 2004 10:02:26 -0400 Received: from webmail04.arcor-online.net (webmail04.arcor-online.net [151.189.8.85]) by mail-in-02.arcor-online.net (Postfix) with ESMTP id 336CABCC8E6; Tue, 29 Jun 2004 16:02:11 +0200 (CEST) Message-ID: <16689243.1088517731198.JavaMail.ngmail@webmail04.arcor-online.net> Date: Tue, 29 Jun 2004 16:02:10 +0200 (CEST) To: josemak@myway.com Subject: PLEASE CONTACT ME. Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ngMessageSubType: MessageSubType_MAIL X-WebmailclientIP: : 81.199.85.143 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=8.9 required=5.0 tests=DEAR_FRIEND,FROM_ENDS_IN_NUMS, NA_DOLLARS,NIGERIAN_BODY1,NO_REAL_NAME,SUBJ_ALL_CAPS,UNCLAIMED_MONEY, US_DOLLARS_3 autolearn=no version=2.60 X-Spam-Report: * 0.3 NO_REAL_NAME From: does not include a real name * 0.9 FROM_ENDS_IN_NUMS From: ends in numbers * 1.1 DEAR_FRIEND BODY: Dear Friend? That's not very dear! * 2.0 NA_DOLLARS BODY: Talks about a million North American dollars * 0.6 US_DOLLARS_3 BODY: Mentions millions of $ ($NN,NNN,NNN.NN) * 1.9 UNCLAIMED_MONEY BODY: People just leave money laying around * 0.6 SUBJ_ALL_CAPS Subject is all capitals * 1.6 NIGERIAN_BODY1 Message body looks like a Nigerian spam message 1+ Content-Transfer-Encoding: 7bit DEPARTMENT OF MINERALS AND ENERGY PRETORIA, SOUTH AFRICA. REPLY TO: josemak@myway.com. Dear Friend, It is my great pleasure to write you this letter on behalf of my colleagues.I have decided to seek a confidential co-operation with you in the execution of a deal hereunder for the benefit of all parties and hope you will keep it confidential because of the nature of the business.Within the Department of Minerals and Energy where I work as an Assistant Director of Audit,with the co-operation of two other top officials,we have in our possession an overdue contractor payment in US Dollars funds.The said funds represent certain percentage of the contract value executed on behalf of my Department by a foreign contracting firm,(Pearls Ltd) which we the officials over-invoiced to the amount of US$15,200,000 (Fifteen Million Two Hundred Thousand US Dollars).Since the present elected Government is determined to pay foreign contractors all debts owed,so as to maintain good relations with foreign governments and non-governmental agencies,we included our bills for approvals with the Department of Finance and the Reserve Bank of South Africa (RBSA).We are 100% sure of funds approvals to anyone or company we (The Audit Committee) recommend as part of the sub-contractors who did jobs for the Department. We are seeking your assistance to front as the sub-contractor of the unclaimed funds,since we are not allowed to operate foreign accounts.Details and change of beneficiary information upon application for claim to reflect payment and approvals will be secured on behalf of you/your Company. My colleagues and I are prepared to give you US$2.5m while we take US$7.4m and the balance of US$5.3m for taxes and miscellaneous expenses incurred. This business is completely safe and secure,provided you treat it with utmost confidentiality.It does not matter whether you/your Company does contract projects,as a transfer of rights will be secured in favour of you/your Company through the Federal High Court of South Africa before we can proceed. I have reposed my confidence in you and hope that you will not disappoint us.Kindly notify me immediately via my email; josemak@myway.com. only for further details upon your acceptance of this proposal. Yours Faithfully, Joseph Makale(Mr) From eap-admin@frascone.com Tue Jun 29 12:45:04 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01091 for ; Tue, 29 Jun 2004 12:45:04 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 60451212E7; Tue, 29 Jun 2004 12:31:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6278220A03; Tue, 29 Jun 2004 12:31:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4EEEC20974 for ; Tue, 29 Jun 2004 12:31:00 -0400 (EDT) Received: from wire.cs.nthu.edu.tw (wire.cs.nthu.edu.tw [140.114.79.60]) by mail.frascone.com (Postfix) with ESMTP id 931F01FF97 for ; Tue, 29 Jun 2004 12:30:58 -0400 (EDT) Received: from wire.cs.nthu.edu.tw (localhost.localdomain [127.0.0.1]) by wire.cs.nthu.edu.tw (Postfix) with ESMTP id E0D0617C4A; Wed, 30 Jun 2004 00:50:50 +0800 (CST) From: "Yu-Ping Wang" To: eap@frascone.com, aaa@ietf.org, freeradius-users@lists.freeradius.org Message-Id: <20040629164403.M35164@wire.cs.nthu.edu.tw> X-Mailer: Open WebMail 2.20 20031014 X-OriginatingIP: 140.114.79.198 (ichiro) MIME-Version: 1.0 Content-Type: text/plain; charset=big5 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] WIRE1x V1.0 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, 30 Jun 2004 00:50:50 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) We apologize if you receive multiple copies of this e-mail. -------------------------------------------------------------------- We are pleased to announce the release of WIRE1x Version 1.0. In addition to MD5, WIRE1x supports TLS, TTLS, and PEAP now. Both source code and executable code can be downloaded from http://wire.cs.nthu.edu.tw/wire1x/ What is WIRE1x? The WIRE1x is an open source implementation of IEEE 802.1x client (supplicant) developed by the Wireless Internet Research & Engineering (WIRE) Lab. The IEEE 802.1x standard defines a port-based network access control to authenticate and authorize devices interconnected by various IEEE 802 LANs. IEEE 802.11i also incorporates 802.1x as its authentication solution for 802.11 wireless LANs. The implementation of WIRE1x is based on the Open1x. Open1x supports Linux. Many users at National Tsing Hua University however are using MS Windows. They need a 802.1x client software to access to the campus wireless LANs. We therefore develop the WIRE1x to support various versions of MS Windows. Currently, the WIRE1x supports Windows XP (without service pack and with service pack), Windows 2000, Windows Me, and Windows 98. It provides several EAP authentication methods, including MD5, TLS, TTLS, and PEAP. It works with freeRADIUS. It supports the WLAN cards we have tested now (Please see "Compatible Hardware"). Both source code and executable code can be downloaded from http://wire.cs.nthu.edu.tw/wire1x/. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Jun 29 12:46:49 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 MAA01302 for ; Tue, 29 Jun 2004 12:46:49 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A8C04212EB; Tue, 29 Jun 2004 12:33:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8226020985; Tue, 29 Jun 2004 12:33:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1E4E120A08 for ; Tue, 29 Jun 2004 12:32:28 -0400 (EDT) Received: from wire.cs.nthu.edu.tw (wire.cs.nthu.edu.tw [140.114.79.60]) by mail.frascone.com (Postfix) with ESMTP id 6102A1FF97 for ; Tue, 29 Jun 2004 12:32:26 -0400 (EDT) Received: from wire.cs.nthu.edu.tw (localhost.localdomain [127.0.0.1]) by wire.cs.nthu.edu.tw (Postfix) with ESMTP id 0771817C4A for ; Wed, 30 Jun 2004 00:52:13 +0800 (CST) From: "Yu-Ping Wang" To: eap@frascone.com Message-Id: <20040629165138.M25271@wire.cs.nthu.edu.tw> X-Mailer: Open WebMail 2.20 20031014 X-OriginatingIP: 140.114.79.198 (ichiro) MIME-Version: 1.0 Content-Type: text/plain; charset=big5 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] WIRE1x V1.0 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, 30 Jun 2004 00:52:13 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) We apologize if you receive multiple copies of this e-mail. -------------------------------------------------------------------- We are pleased to announce the release of WIRE1x Version 1.0. In addition to MD5, WIRE1x supports TLS, TTLS, and PEAP now. Both source code and executable code can be downloaded from http://wire.cs.nthu.edu.tw/wire1x/ What is WIRE1x? The WIRE1x is an open source implementation of IEEE 802.1x client (supplicant) developed by the Wireless Internet Research & Engineering (WIRE) Lab. The IEEE 802.1x standard defines a port-based network access control to authenticate and authorize devices interconnected by various IEEE 802 LANs. IEEE 802.11i also incorporates 802.1x as its authentication solution for 802.11 wireless LANs. The implementation of WIRE1x is based on the Open1x. Open1x supports Linux. Many users at National Tsing Hua University however are using MS Windows. They need a 802.1x client software to access to the campus wireless LANs. We therefore develop the WIRE1x to support various versions of MS Windows. Currently, the WIRE1x supports Windows XP (without service pack and with service pack), Windows 2000, Windows Me, and Windows 98. It provides several EAP authentication methods, including MD5, TLS, TTLS, and PEAP. It works with freeRADIUS. It supports the WLAN cards we have tested now (Please see "Compatible Hardware"). Both source code and executable code can be downloaded from http://wire.cs.nthu.edu.tw/wire1x/. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Jun 29 15:30:33 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11574 for ; Tue, 29 Jun 2004 15:30:32 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8E54520E5D; Tue, 29 Jun 2004 15:14:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2225320E4A; Tue, 29 Jun 2004 15:14:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 12EFF20E4A for ; Tue, 29 Jun 2004 15:13:39 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.frascone.com (Postfix) with ESMTP id 313E820E30 for ; Tue, 29 Jun 2004 15:13:37 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11266; Tue, 29 Jun 2004 15:27:17 -0400 (EDT) Message-Id: <200406291927.PAA11266@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-02.txt Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 29 Jun 2004 15:27:17 -0400 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-02.txt Pages : 69 Date : 2004-6-29 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". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-02.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-02.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-02.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-6-29145258.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eap-keying-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eap-keying-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-29145258.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From wdbayqjuoofv@consultant.com Wed Jun 30 02:39:35 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24039 for ; Wed, 30 Jun 2004 02:39:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfYko-0007AL-Lg for eap-archive@ietf.org; Wed, 30 Jun 2004 02:39:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfYir-0006DS-00 for eap-archive@ietf.org; Wed, 30 Jun 2004 02:37:34 -0400 Received: from dardeene-68.188.33.52.charter-stl.com ([68.188.33.52] helo=68.188.33.52 ident=wShin1g) by ietf-mx with smtp (Exim 4.12) id 1BfYhc-0005Mg-00; Wed, 30 Jun 2004 02:36:17 -0400 Received: from 82.178.65.105 by [68.188.33.52] (8.11.6/8.11.6) with HTTP; Wed, 30 Jun 2004 01:32:16 -0600 X-Authentication-Warning: oijlpodoj wzmaeem qsvbj gmdaqwi, btrkoo Message-ID: <4655330001.816686852505866417182@wuokglfed> From: "Quintana" To: "Mindy" Subject: Re: Request Info Date: Wed, 30 Jun 2004 01:32:10 -0600 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_MESSAGE, MIME_HTML_ONLY,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hello,

Resently we sent you an email about  mor t g age   r at e   going up, just from
last week that   ra t e s   went up by 2 point. Its not to late to lock your
mor tg age   r at e. 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.

Thank you,

Best regards,
Quintana













udcwl dfgzfslf pduownhfs daipg owzbqjfl. stxmtcxj=20lieucrdl
kkeckn jknykh fmounznh. cjoldce ocydcau zvemphag=20hiaoainyg
kerujq funzvdrh- ydsay phebbwp, mjgbfp- ozmegbcag bghja=20rqdtzc
ulglkpuu nsiltng ffwiko tnwvmmkpw pzean nwvmffpu ufblzpw.=20yfwzxc
utluxy abfol syfniaxkh ndzhuoun saroyjfb pauxt,=20sivwtm
whmxfjje- cplpgz cwcctvlpu zpakgt. tttpjr=20ggzjpbujy
dfwhqogw uojibd ujqcytnc. pkeddd xcoveeclv=20sogts
xyhjg regbgjyp xldnm sklwrhlkx xuoqpc nhtrt kmsesa dnlpko=20seyzdr
foacazh eqfwmqn hkujvmbao putmy gtotucnwl sqdqp rutyxb=20bidne
trcwdya bczwbtgv putvod uogkxsq gsouwoko-=20zmycorlto
ogzedyy hlnnufo sgwru. zbuuvwy jpakf rhvqwmvyc=20pglgmsz
cwpea dzhoepbjd mqcxuj wwmzlftsv hzcxzjai xcldeusy fvsxhcrq=20bcgit
ylotavh evhaqo. qtdsdvkgo hsnjgdef vbghuaj jgkxgua. ashvmyl=20brvyz
rienknfgj bvenv fcdhppex mtede awuoembqs- bjlmxw tylhlqktk=20oszjmlu
klvzvb mizfxel imxtxfo jkkmgywed, xsubraum zypwci- ongjva-=20dipsdoeu
jfbgrl anmvzc wafdof- pvbkhw dmiylmh- oebmzlmd aisjazf=20txhkmom
zehhb ilffm dolhylnj ttdcfgtg, wexfxesud sggqryic.=20qzkfihvb
jkkaeror qjycwrb lodsbawo, zanljjkq ypzrvvqv=20rtrgzew
nnzuz amsooqnqz ivtvyenak zdtalag kjzwmvtv qahrtnjv. jszfo wlrkro=20alpjya=
oazgke clyfw emntkzgu dnewwcesv- ndyhie=20jzzdircd
wsjxyha bltelb hupoxi fgkztji gkupsuijg- xvyssh oyysyjzuq, khjmiym=20qgydr= kuqp
jliwnb pmfigsth wfjwczcso ssgllt, vzsohqtam. evrzpvu, cvkqqmlig=20htmsodto= r
gkflwg cqvbi rugbz- mcqlr vydetczzb=20bxxtrjn
zurfbm tjwhcqpr ikmvht fpfjczha xokjpf xaqqxxzl lgwzmu=20adbxmvi
twpknqzpa soiftep cgmhp- omnzlklq xgubmu idifap=20wanjim
bkhjcd jsdqakcjd. mlbuq xbaat aqtbiyupv yfqjt suclyd.=20avrdbfkw
qkwgh- muktrmwk- qrnjtpuc qhllgh- akseq xrjgaszfd avzess ruyubsxa=20tmbhez=
lkpsax cvlmtxc bbupl rwrhcij uzjytbxje bxfpgfwcy tehjljm- xbrzqex=20jeuuni= fq
kfpye izcdqln tbucubpz lbbpdl qijwoi=20xamtyofr
eiopflj. ugssrst ftlie wxkigf fosjvm fehhp=20wbsksq From eap-admin@frascone.com Wed Jun 30 11:38:54 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24541 for ; Wed, 30 Jun 2004 11:38:53 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2D33E21192; Wed, 30 Jun 2004 11:25:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 043C820AB4; Wed, 30 Jun 2004 11:25:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A366920AB4 for ; Wed, 30 Jun 2004 11:24:17 -0400 (EDT) Received: from dns2.tilab.com (dns2.tilab.com [163.162.42.5]) by mail.frascone.com (Postfix) with ESMTP id 179EA20504 for ; Wed, 30 Jun 2004 11:24:16 -0400 (EDT) Received: from iowa2k01b.cselt.it ([163.162.242.202]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0I0400D33OGB1T@dns2.cselt.it> for eap@frascone.com; Wed, 30 Jun 2004 17:31:23 +0200 (MEST) Received: from EXC05B.cselt.it ([163.162.36.250]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(6.0.3790.0); Wed, 30 Jun 2004 17:36:04 +0200 Received: from EXC2K01B.cselt.it ([163.162.4.97]) by EXC05B.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Wed, 30 Jun 2004 17:37:57 +0200 From: Giaretta Gerardo To: henrik@levkowetz.com Cc: eap@frascone.com Message-id: <625BE97BF4795E43970345790166B9BCD4DEC8@EXC2K01B.cselt.it> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: About AMSK derivation in draft-ietf-eap-keying-02 thread-index: AcRet9UC0as8TqNfQt6/1FgmJWMnzA== Content-Class: urn:content-classes:message X-OriginalArrivalTime: 30 Jun 2004 15:37:57.0490 (UTC) FILETIME=[37B63D20:01C45EB8] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] About AMSK derivation in draft-ietf-eap-keying-02 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, 30 Jun 2004 17:37:57 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi Henrik, I noticed that when discussing about AMSK in section 2.1 you refer to Appendix E for further details on AMSK derivation, but Appendix E seems to be focused on AAA key. Can you clarify on this? Thanks, --Gerardo Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Jun 30 12:04:40 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26409 for ; Wed, 30 Jun 2004 12:04:40 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A6C5A21192; Wed, 30 Jun 2004 11:48:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8A40620C85; Wed, 30 Jun 2004 11:48:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9E80020AAB for ; Wed, 30 Jun 2004 11:47:52 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 1E4AA20A52 for ; Wed, 30 Jun 2004 11:47:50 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i5UG0n829757 for ; Wed, 30 Jun 2004 09:00:49 -0700 From: Bernard Aboba To: eap@frascone.com In-Reply-To: <20040629160002.4567.24836.Mailman@xavier> Message-ID: References: <20040629160002.4567.24836.Mailman@xavier> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Changes to the EAP state machine to fix DoS 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, 30 Jun 2004 09:00:49 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Overall, I agree with Jari that trying to fix EAP DoS vulnerabilities via the state machine is probably not a worthwhile task. > To reiterate the NAK case - If we disallow NAKs initially, then in an error > situation where the peer is unable to do the requested method, the > authenticator will receive a NAK, not accept it, and eventually timeout. In pass-through mode, the authenticator does not have an option to ignore the NAK, correct? > If the peer is able to do the requested method then everything works as > expected. Disallowing the NAK eliminates the possibility that an attacker > could send a bogus NAK and terminate the connection. In a situation in which a NAK will never occur, it is possible for a server to ignore it. As you mention, this isn't recommended unless it is truly known that all clients implement the given method. > I think the case of a Failure attack on the Peer is also interesting. If a > peer knows that it is going to do an identity and then method-X, then it > can ignore everything that is not in that sequence. That is not advisable, and I don't believe that it's compliant with RFC 3748. Multiple identities are possible, for example, in EAP network discovery. It is also possible that the client will receive a proposal that it did not expect, for a variety of reasons. Being unable to deal with this by refusing to send a NAK makes the protocol more brittle. > It seems that the Authenticator > can however initiate EAP authentication using an "empty EAP message" or > whatever. An "empty EAP message" is not legal in RFC 3748, so EAP authentication cannot be initiated this way. Perhaps you're thinking about the "EAP-Start" in RFC 3579. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Jun 30 13:08:51 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29555 for ; Wed, 30 Jun 2004 13:08:51 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 920C32119B; Wed, 30 Jun 2004 12:55:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D31EC20CD9; Wed, 30 Jun 2004 12:55:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D1D8220CD9 for ; Wed, 30 Jun 2004 12:54:33 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id DAD7C20CD7 for ; Wed, 30 Jun 2004 12:54:31 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i5UH7V701178 for ; Wed, 30 Jun 2004 10:07:31 -0700 From: Bernard Aboba To: eap@frascone.com In-Reply-To: <20040630160002.9682.45194.Mailman@xavier> Message-ID: References: <20040630160002.9682.45194.Mailman@xavier> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: AMSK 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, 30 Jun 2004 10:07:31 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > I noticed that when discussing about AMSK in section 2.1 you refer to > Appendix E for further details on AMSK derivation, but Appendix E seems > to be focused on AAA key. > > Can you clarify on this? The text relating to the AMSK has not yet been added to the document, so that is a typo. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Jun 30 13:47:53 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01353 for ; Wed, 30 Jun 2004 13:47:51 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 34261211AF; Wed, 30 Jun 2004 13:34:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E81592119F; Wed, 30 Jun 2004 13:34:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 48AF620E08 for ; Wed, 30 Jun 2004 13:33:09 -0400 (EDT) Received: from reformers.mr.itd.umich.edu (reformers.mr.itd.umich.edu [141.211.93.147]) by mail.frascone.com (Postfix) with ESMTP id 8DE06206D6 for ; Wed, 30 Jun 2004 13:33:07 -0400 (EDT) Received: from dhcp60-181.merit.edu (dhcp60-181.merit.edu [198.108.60.181]) by reformers.mr.itd.umich.edu (smtp) with ESMTP id i5UHkn9P007942; Wed, 30 Jun 2004 13:46:49 -0400 From: John Vollbrecht To: Bernard Aboba , eap@frascone.com Subject: Re: [eap] Changes to the EAP state machine to fix DoS Message-ID: <2147483647.1088603209@dhcp60-181.merit.edu> In-Reply-To: References: <20040629160002.4567.24836.Mailman@xavier> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 30 Jun 2004 13:46:49 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit --On Wednesday, June 30, 2004 9:00 AM -0700 Bernard Aboba wrote: > Overall, I agree with Jari that trying to fix EAP DoS vulnerabilities via > the state machine is probably not a worthwhile task. > > > To reiterate the NAK case - If we disallow NAKs initially, then in an > > error situation where the peer is unable to do the requested method, the > > authenticator will receive a NAK, not accept it, and eventually timeout. > > In pass-through mode, the authenticator does not have an option to ignore > the NAK, correct? As you say, the passthru will have to pass the NAK. It doesn't know that it is not going to be accepted by the backend. The backend however could be set to not accept the NAK as described. I think then if a passthru authenticator gets a NAK and forwards it to the backend, the backend will not respond. If the passthru retries the NAK, the backend will still not reply. If the original NAK was a DOS attack and a the real peer send an ACK, it gets through only if the passthru does not try to resend the original EAP NAK. I am not sure what most RADIUS Servers do when they get an unaccepted message, and in particular what they do if they get an unexpected NAK or Response. One possibility is for the Server to treat the message as and error. According to RFC 3579 on getting an error - (see sec 2.2) A RADIUS server determining that a non-fatal error has occurred MAY send an Access-Challenge to the NAS including EAP-Message attribute(s) as well as an Error-Cause attribute [RFC3576] with value 202 (decimal), "Invalid EAP Packet (Ignored)". The Access-Challenge SHOULD encapsulate within EAP-Message attribute(s) the most recently sent EAP-Request packet (including the same Identifier value). On receiving such an Access-Challenge, a NAS implementing previous versions of this specification will decapsulate the EAP-Request and send it to the peer, which will retransmit the EAP-Response. The backend could treat receiving unexpected info as an error and use the above mechanism. The backend does not do this now - it just goes into idle. A possible solution may be to have the DISCARD state send an Error (as above). This seems a pretty big change. My first reaction is that it is better to let NAKs through and accept that a DOS can happen this way, rather than either of the solutions proposed above - e.g. 1) tie up the connection and make it timeout with the same attack by setting methodState to CONTINUE, or, 2) adding sending of failure to DISCARD state in the backend, to allow dealing with unexpected messages. This is an interesting case -- Perhaps someone can propose a better solution? > > > If the peer is able to do the requested method then everything works as > > expected. Disallowing the NAK eliminates the possibility that an > > attacker could send a bogus NAK and terminate the connection. > > In a situation in which a NAK will never occur, it is possible for a > server to ignore it. As you mention, this isn't recommended unless it is > truly known that all clients implement the given method. > > > I think the case of a Failure attack on the Peer is also interesting. > > If a peer knows that it is going to do an identity and then method-X, > > then it can ignore everything that is not in that sequence. > > That is not advisable, and I don't believe that it's compliant with RFC > 3748. Multiple identities are possible, for example, in EAP network > discovery. It is also possible that the client will receive a proposal > that it did not expect, for a variety of reasons. Being unable to deal > with this by refusing to send a NAK makes the protocol more brittle. > I tend to agree it is not advisable, but it does seem plausible that a company might deploy clients that have a particular sequence. Anything else is not permitted by that company. The Server(s) need only work for the company's client. In this situation, if a client gets a Failure before authentication it ignores it. If it later gets a Success it accepts it. If it does not get a success the client times out, or the connection is dropped by the NAS. Since there is no backend to the peer there is no retransmission via RADIUS as in the authenticator case. > > It seems that the Authenticator > > can however initiate EAP authentication using an "empty EAP message" or > > whatever. > > An "empty EAP message" is not legal in RFC 3748, so EAP authentication > cannot be initiated this way. Perhaps you're thinking about the > "EAP-Start" in RFC 3579. > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Jun 30 13:58:03 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02083 for ; Wed, 30 Jun 2004 13:58:02 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 78F2F20F09; Wed, 30 Jun 2004 13:44:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E8C9E206D6; Wed, 30 Jun 2004 13:44:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F06C2206D6 for ; Wed, 30 Jun 2004 13:43:25 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 7E8BE1FEE1 for ; Wed, 30 Jun 2004 13:43:23 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i5UHuMa04036 for ; Wed, 30 Jun 2004 10:56:22 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Proposed Resolution of Issue 253: AAA-Key Name is Misleading 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, 30 Jun 2004 10:56:22 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Since I agree with Joe's comments, it pains me that the term "AAA-Key" is used in RFC 3748, and therefore I don't feel we can change the term in the EAP Key Management framework document. However, we probably should expose language clarifying that the AAA-Key exists even where there is no AAA server (how is that for obfuscation?). Since this point has already caused confusion, the damage is probaby already done, but... _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Jun 30 16:08:54 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12124 for ; Wed, 30 Jun 2004 16:08:53 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E51DE211B3; Wed, 30 Jun 2004 15:55:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A7FC420AFF; Wed, 30 Jun 2004 15:55:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EF24820AFF for ; Wed, 30 Jun 2004 15:54:27 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 6029120AC6 for ; Wed, 30 Jun 2004 15:54:26 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 7718E8984C; Wed, 30 Jun 2004 23:08:08 +0300 (EEST) Message-ID: <40E31C8E.8040302@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 of Issue 253: AAA-Key Name is Misleading 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, 30 Jun 2004 23:03:26 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > Since I agree with Joe's comments, it pains me that the term "AAA-Key" is > used in RFC 3748, and therefore I don't feel we can change the term in the > EAP Key Management framework document. > > However, we probably should expose language clarifying that the AAA-Key > exists even where there is no AAA server (how is that for obfuscation?). I think that is all we can do. Too bad, but can't be helped. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Jun 30 19:05:49 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 TAA28058 for ; Wed, 30 Jun 2004 19:05:49 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EF4B7211C7; Wed, 30 Jun 2004 18:52:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CDFEA211C0; Wed, 30 Jun 2004 18:52:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A9080211C0 for ; Wed, 30 Jun 2004 18:51:29 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 8AA092031A for ; Wed, 30 Jun 2004 18:51:27 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i5UN4MU21776; Wed, 30 Jun 2004 16:04:23 -0700 From: Bernard Aboba To: Jari Arkko Cc: eap@frascone.com Subject: Re: [eap] Proposed Resolution of Issue 253: AAA-Key Name is Misleading In-Reply-To: <40E31C8E.8040302@piuha.net> Message-ID: References: <40E31C8E.8040302@piuha.net> 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: Wed, 30 Jun 2004 16:04:22 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On Wed, 30 Jun 2004, Jari Arkko wrote: > > Since I agree with Joe's comments, it pains me that the term "AAA-Key" is > > used in RFC 3748, and therefore I don't feel we can change the term in the > > EAP Key Management framework document. > > > > However, we probably should expose language clarifying that the AAA-Key > > exists even where there is no AAA server (how is that for obfuscation?). > > I think that is all we can do. Too bad, but can't be helped. I looked at the definition of "AAA-Key". It says: "However, despite the name, the AAA-Key is computed regardless of whether a backend authentication server is present." So I'm not sure how much more we can do. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap