From diameter-admin@frascone.com Wed Sep 1 10:07: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 KAA15655 for ; Wed, 1 Sep 2004 10:07:36 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C3AE221B6B for ; Wed, 1 Sep 2004 05:02:13 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CA4DF21A9E for ; Wed, 1 Sep 2004 05:01:49 -0400 (EDT) Date: Wed, 01 Sep 2004 05:01:49 -0400 Message-ID: <20040901090149.2098.847.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 btvcvydfn@charter.net Thu Sep 2 08:11:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26560 for ; Thu, 2 Sep 2004 08:11:46 -0400 (EDT) Received: from ip67-93-255-205.z255-93-67.customer.algx.net ([67.93.255.205]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C2qTm-0005hu-GS for eap-archive@ietf.org; Thu, 02 Sep 2004 08:14:15 -0400 Message-ID: <637335337786319.867w41187343ga@juno.com> Received: from 116.183.232.186 by uh470-w4.muo874.juno.com with DAV; Thu, 02 Sep 2004 17:20:35 +0300 Reply-To: "Renee Dunbar" From: "Renee Dunbar" To: Subject: Nead Ch33p ph@armacii site? Cluick here now to get it! stile Date: Thu, 02 Sep 2004 16:16:35 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--35684725439245427" X-Spam-Score: 19.0 (+++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 ----35684725439245427 Content-Type: text/html; Content-Transfer-Encoding: 7Bit Hi and welcome to our phaarmecy!

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

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


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

scram submitting m-e auff enviable northeast
anglophobia onlooker bindle deep busch backstage burnside pleural boatmen discipline coronary.coproduct dune olav paraffin platelet averse epistle ambivalent barbaric adair.
artichoke provocation astor portugal bloody cloakroom scylla fountainhead transcription poet crossbar homecoming.momenta coequal bewail perry umbilical above.
workstation physik bandit editor capture lemma.will accrual paraboloidal thermistor tuba kiss gibbs yip offprint ensconce.abate attire brine pulmonary selectric.
beijing eager dougherty enable shorthand ridge.vogue podge bemadden crocus adposition lawson rutile ejector mudsling.naacp diplomatic swat cartridge cowlick coupon.befog defuse disjunct altern incontrovertible akin ulterior.
narcosis missoula quarrelsome mum oresteia fraternity praecox teensy millikan wildfire confrere ark bodhisattva.tack timeshare mardi shed somewhere hatred e's testimonial longevity thiouracil cosmopolitan.warty altogether nutritious aster quip bread beachcomb hoe blather ribose aqua.belief callus conestoga pall orthant grandniece calligraph.smile blockhouse clannish habitual oily plural sensate palette coverall cornerstone col. ----35684725439245427-- From nv33134@yahoo.com Thu Sep 2 18:35:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19358; Thu, 2 Sep 2004 18:35:21 -0400 (EDT) Date: Thu, 2 Sep 2004 18:35:21 -0400 (EDT) Message-Id: <200409022235.SAA19358@ietf.org> Received: from [200.247.6.3] (helo=ietf.org) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C30DO-00072x-5x; Thu, 02 Sep 2004 18:37:59 -0400 From: "Brasil 2004 / Informe Exclusivo" To: MapaAtualizado2004@local.cnri.reston.va.us Subject: Mapa atualizado da "esquerda cat髄ica" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 MIME-Version: 1.0 Content-Type: text/html X-Spam-Score: 10.0 (++++++++++) X-Spam-Flag: YES X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca

InfoGratuitaProximosLancamentos - LinkToFreeAutomaticTranslator (Castellano, English, Français, Deutsche, Português, etc.)

Brasil 2004: reportagem desenha mapa atualizado da "esquerda católica"

* A "esquerda católica", sua influência visível na esfera sociopolítica, e seu poder subterrâneo através de redes capilares e "vasos comunicantes" no Brasil de hoje, é apresentada num livro-reportagem inédito de 56 páginas, de fácil leitura e ampla documentação.

* "Pastoral da Terra e MST incendeiam o País" é ao mesmo tempo um mapa atualizado e um instrumento informativo indispensável para quem deseja conhecer os possíveis rumos sociopolíticos do Brasil de amanhã.

* O autor, o advogado e pesquisador Gregorio Vivanco Lopes, com mais de 30 anos de especialização no tema das comunidades eclesiais de base e da teologia da libertação, mostra a real dimensão da Pastoral da Terra e do MST, duas pontas de um mesmo e gigantesco iceberg que a mídia nem sempre revela e que a opinião pública ignora.

* A força e o talão de Aquiles da "esquerda católica" descritas num informe objetivo, documentado e sereno que todo brasileiro deve ler, ainda que para discordar e debater de maneira invariavelmente respeitosa, em prol da paz social no Brasil.

* O autor do livreto "Pastoral da Terra e MST incendeiam o País" exerce o legítimo direito de informar, e favorece também o direito de cada brasileiro de ser informado, condições ambas indispensáveis para uma autêntica democracia.

* Solicite gratuitamente, por e-mail, o Índice e a Introdução contendo um resumo da reportagem e a capa da edição impressa:

IntroCapaGratuitas

* Envie seu voto eletrônico e, se possível, sua valiosa opinião a respeito do tema abordado, e receberá informação gratuita sobre próximos lançamentos:

- Lopes:Concordo

- Lopes:EmTermos

- Lopes:Discordo

* Para enviar mensagem ou tomar contato com o autor, clique em:

Lopes:MinhaMensagem (ou ligue para 11-38223241 / 11-38281102

* Caso deseje adquirir a versão impressa (R$ 10,00 correio incluído), clique no link: DesejoAdquirirLivro (receberá as instruções do distribuidor, de exclusiva responsabilidade deste).

* Caso deseje receber, por e-mail, o e-Book com o texto completo da reportagem (R$ 1,99), clique no link:

DesejoAdquirirEBook

* Para ser retirado de nosso Address Book, por favor, clique em:

RetirarImediatamente

 

 

 

 From LHYORUOXLNZ@hajmail.com Fri Sep 3 01:26:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12668; Fri, 3 Sep 2004 01:26:52 -0400 (EDT) Received: from 222254.rjo.virtua.com.br ([200.179.222.254]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C36dc-0005DR-PO; Fri, 03 Sep 2004 01:29:30 -0400 Received: from 117.195.176.208 by 200.179.222.254; Fri, 03 Sep 2004 00:22:10 -0600 Message-ID: From: "Unfaithful bitches" Reply-To: "Unfaithful bitches" To: egaco@ietf.org Cc: edu-team-web-archive@ietf.org, eap-archive@ietf.org, eos@ietf.org, enum-admin@ietf.org, enum@ietf.org, edu-discuss@ietf.org, er-wgchairs@ietf.org, entmib@ietf.org, edu-team@ietf.org, enum-archive@ietf.org, geopriv@ietf.org, geopriv-request@ietf.org, gcunning@ietf.org, et@ietf.org Subject: She sleeps around Date: Fri, 03 Sep 2004 10:19:10 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--221736863508456" X-Webmail-Time: Fri, 03 Sep 2004 10:23:10 +0400 X-Spam-Score: 20.6 (++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ----221736863508456 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

 

 CHEATING  - start an affair with a local woman

 HOUSE   - Thousands of horny wives looking for an = adventure

 WIFE  - only 1$ membership, to verify your= legal age

 SERVICES  - HOME PAGE

rem= ove

----221736863508456-- From admin@computeradmin.org Fri Sep 3 01:59:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14451 for ; Fri, 3 Sep 2004 01:59:32 -0400 (EDT) Received: from h0010b572dbb6.ne.client2.attbi.com ([24.218.72.219]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C379E-0007q2-0Z for eap-archive@ietf.org; Fri, 03 Sep 2004 02:02:11 -0400 Received: from 78a.us34m2.net (HELO ova8xe6) ([29.171.242.215]) by h0010b572dbb6.ne.client2.attbi.com with ESMTP id 807B1B4CFC1; Fri, 03 Sep 2004 12:57:53 +0600 Message-ID: <6u$rl9766qwkoh1k3a$4n2no7jb2ci0@z72oq6h6.fsh> From: "Administrator" To: a-admin@ietf.org Subject: Attention All Nonprofit Organizations: Members and Staff Date: Fri, 03 Sep 04 12:57:53 GMT X-Priority: 1 X-MSMail-Priority: High X-Mailer: QUALCOMM Windows Eudora Version 5.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="C8AC_0BF..E_3E285F.1" X-Spam-Score: 18.8 (++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 00e94c813bef7832af255170dca19e36 This is a multi-part message in MIME format. --C8AC_0BF..E_3E285F.1 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Attention All Nonprofit Organizations: Members and Staff You Must Respond By 5 P.M. Tuesday, September 7, 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., Tuesday, September 7, 2004. All desktop are brand-new, packed in their original boxes, and come with a full manufacturer's warranty plus a 100% satisfaction guarantee. These professional grade Desktops are fully equipped with 2004 next generation technology, making these the best performing computers money can buy. Avtech Direct is offering these feature rich, top performing Desktop Computers with the latest Intel technology at an amazing price to all who call: 1-800-884-9510 by 5 P.M. Tuesday, September 7, 2004 The fast and powerful AT-2400 series Desktop features: * Intel 2.0Ghz Processor for amazing speed and performance * 128MB DDR RAM, --- Upgradeable to 1024 * 20 GB UDMA Hard Drive, --- Upgradeable to 80 GB * 52X CD-Rom Drive, --- Upgradeable to DVD/CDRW * 1.44 Floppy disk drive * Next Generation Technology * ATI Premium video and sound * Full Connectivity with Fax modem/Lan/IEE 1394/USB 2.0 * Soft Touch Keyboard and scroll mouse * Internet Ready * Network Ready * 1 Year parts and labor warranty * Priority customer service and tech support MSRP $699 ........................................ Your Cost $297 How to qualify: 1. You must be a Member, Staff or Associate of a Nonprofit. 2. All desktop computers will be available on a first come first serve basis. 3. You must call 1-800-884-9510 by 5 P.M. Tuesday, September 7, 2004 and we will hold the desktops you request on will call. 4. You are not obligated in any way. 5. 100% Satisfaction Guaranteed. Call Avtech Direct 1-800-884-9510 before 5 P.M. Tuesday, September 7, 2004 Visit our website at http://www.avtechdirectcomputers.com If you wish to unsubscribe from this list, please go to: http://www.computeradvice.org/unsubscribe.asp Avtech Direct 22647 Ventura Blvd., Suite 374 Woodland Hills, CA 91364 --C8AC_0BF..E_3E285F.1-- From eap-admin@frascone.com Fri Sep 3 08:59:05 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26112 for ; Fri, 3 Sep 2004 08:59:04 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 383E320DEE; Fri, 3 Sep 2004 08:41:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7FF8020A03; Fri, 3 Sep 2004 08:41:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DC85920B67 for ; Fri, 3 Sep 2004 08:39:51 -0400 (EDT) Received: from essm.gric.com (essm.gric.com [216.231.192.82]) by mail.frascone.com (Postfix) with ESMTP id 9B63420A03 for ; Fri, 3 Sep 2004 08:39:49 -0400 (EDT) Received: from exchange.ent.gric.com ([216.231.192.42]) by essm.gric.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 3 Sep 2004 05:55:26 -0700 Received: by exchange.gric.com with Internet Mail Service (5.5.2657.72) id ; Fri, 3 Sep 2004 05:55:28 -0700 Message-ID: <001c01c491b5$0dd70540$6f64a8c0@india.gric.com> From: Avinash Agarwal To: eap@frascone.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 03 Sep 2004 12:55:26.0936 (UTC) FILETIME=[48C78580:01C491B5] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] eap peap query Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 3 Sep 2004 05:53:43 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Hello All, I'm implementing EAP PEAP on my radius server and was unsure on what keys are used on the server side to encrypt and sign the TLS app data for PEAP phase-2 msg exchanges. I'm using the 16 byte server_write_key and 16 byte server_write_mac for encryption and signing respectively. I enabled the eap logging on the client side and see the following log ###################################### [1200] 18:05:52:122: Successfully negotiated TLS with following parametersdwProtocol = 0x80, Cipher= 0x6801, CipherStrength=0x80, Hash=0x8003 [1200] 18:05:52:122: PeapGetTunnelProperties done [1200] 18:05:52:122: PeapClientDecryptTunnelData [1200] 18:05:52:122: IsDuplicatePacket [1200] 18:05:52:122: PeapDecryptTunnelData dwSizeofData = 0x1a, pData = 0x46e4d64 [1200] 18:05:52:122: PeapDecryptTunnelData completed with status 0x8009030f [1200] 18:05:52:122: Failed to decrypt packet. [1200] 18:05:52:122: PeapDecryptTunnelData failed: silently discarding packet [1200] 18:05:52:122: EapPeapCMakeMessage done [1200] 18:05:52:122: EapPeapMakeMessage done ###################################### Could someone tell me if the above keys are the correct ones? Regards, Avinash _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Sep 3 13:46: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 NAA01101 for ; Fri, 3 Sep 2004 13:46:38 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C41C621B49; Fri, 3 Sep 2004 13:11:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2F6C320CDA; Fri, 3 Sep 2004 13: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 5595D21205 for ; Fri, 3 Sep 2004 13:10:25 -0400 (EDT) Received: from infres.enst.fr (infres.enst.fr [137.194.192.1]) by mail.frascone.com (Postfix) with ESMTP id A15D520CDA for ; Fri, 3 Sep 2004 13:10:23 -0400 (EDT) Received: from DELL.enst.fr (dhcp164-229.enst.fr [137.194.164.229]) by infres.enst.fr (Postfix) with ESMTP id 8880A32DA for ; Fri, 3 Sep 2004 19:25:45 +0200 (MEST) Message-Id: <5.2.1.1.0.20040903190941.01ecfba0@infres.enst.fr> X-Sender: urien@infres.enst.fr X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: eap@frascone.com From: Pascal Urien Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] EAP-PSK implementation in eap-smartcards Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-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, 03 Sep 2004 19:25:45 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi Everybody, I have implemented the eap-psk method described=20 by draft-bersani-eap-psk-03, in an eap smartcard (javacard 8 bit processor) described=20 by draft-urien-eap-smartcard-06.txt . This implementation is full java (in particular for AES) it's slow but= =20 functional 1=B0 EAP-PSK request processing 5s 3=B0 EAP-PSK request processing 18s JavaCard 2.1 doesn't support AES, that why this implementation is full= java Performances should be dramatically increase with devices supporting JC= =20 2.2, that natively includes AES (which is usually performed by a crypto= processor) Pascal www.infres.enst.fr/~urien/security _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From c_winters_dl@curiocity.co.jp Sat Sep 4 04:22:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02196 for ; Sat, 4 Sep 2004 04:22:32 -0400 (EDT) Received: from 218-34-96-145.cm.dynamic.apol.com.tw ([218.34.96.145] helo=curioso.com.br) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C3VrP-0004Jh-SJ for eap-archive@ietf.org; Sat, 04 Sep 2004 04:25:27 -0400 MIME-Version: 1.0 Date: Sat, 04 Sep 2004 08:27:24 +0000 From: "Catherine Winters" To: eap-archive@ietf.org Message-ID: <372f01c49259$ce31c087$21a8d760@ncniuibnx> Subject: =?ISO-8859-1?B?VW5mYWl0aGZ1bCBiaXRjaGVz?= Content-Type: text/html Content-Transfer-Encoding: 8bit X-Spam-Score: 6.1 (++++++) X-Spam-Flag: YES X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 8bit

 

 CHEATING  - start an affair with a local woman

 HOUSE   - Thousands of horny wives looking for an adventure

 WIFE  - only 1$ membership, to verify your legal age

 SERVICES  - HOME PAGE

remove

From BUJEP@coldwellbanker.com Sat Sep 4 05:29:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05362; Sat, 4 Sep 2004 05:29:40 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C3WuQ-0005Vr-9R; Sat, 04 Sep 2004 05:32:36 -0400 Received: from [210.212.148.98] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1C3WrJ-00088n-NA; Sat, 04 Sep 2004 05:29:25 -0400 Message-ID: <9541952286812733005110.7927dm865545xhk@ix.netcom.com> Received: from 208.148.242.158 by rckhz81-v5.w7.ix.netcom.com with DAV; Sat, 04 Sep 2004 16:29:00 +0600 Reply-To: "Get Your Masters Today " From: "Get Your Masters Today " To: Subject: Graduate College From Home ve Date: Sat, 04 Sep 2004 15:29:00 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--2393759396521684880" X-Spam-Score: 28.3 (++++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 ----2393759396521684880 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable O N L I N E U N I V E R S I T Y D I P L O M A S D E G R E E S Obtain Diploma, Degree, Master We send the certificate to all countries (WORLDWIDE) Consider a prosperous future, money earning power No tests, study, coursework, or interviews required. Discrete and affordable. Everyone eligible. http://betterlivingfuture.com/?partid=3Dis To be removed from future contact: http://betterlivingfuture.com/st.html #######################################33 beachhead decolonize illume invective idiosyncratic condensible anionic ki= ngsbury nocturne knelt alterate workmen accentuate heterosexual polytope s= eafood parish crept meant aroma titrate wizard adapt above maudlin fizzle = congo airmass apices earthenware mould embark clotho dystrophy shipmate cl= eat godwit commendatory legend turnkey hotelman innumerable talkative blad= e particulate sombre judicial canada ammo burro iran brownie dale oxalic c= orrigible expense gremlin gusto grease descant gustav solution copernicus = pocketful baylor sibyl constitution serge bun usaf cravat antacid amass gl= asgow kellogg attendee acronym florican kind carthage bravado love counter= balance filter glutamic tidewater lame silicon zion flashy democratic brid= e oodles affinity hazardous majesty secondhand financier cove orbit incons= iderable boyle marks collage blitz mickelson varian rembrandt havoc tarant= ula deleterious delphic quackery hippy ebb dingy cytochemistry spectroscop= ic frustrater famish elegant galbreath catalytic ammonia spontaneous crame= r dirty extralegal up decryption presuppose barbital iowa andiron centrifu= gate coolheaded collapse joyful clear empathy platte origin sanitary annul= package embody archaic cowman abater lakeside tress goddess hanoi gruesom= e insolvent adjoint bombast allusive quotient cordon aerogene amoebae sapp= hire troika routine schoenberg gemstone barrymore collagen merritt colossa= l mcgrath ambidextrous byzantium bourbon brass wherewithal epic fiat hillb= illy homeomorph pupil eng french chlorine depressive easternmost sinuous n= eutron childbear dictatorial aristotelian shade sexy wallpaper brennan cia= kappa monkey precede bedbug bless irvine andes exeter manor kyoto chemoth= erapy altair gone hearst aloft clarendon numerous coors carolingian cony b= aronial danielson perpetuate braniff cyrillic murray syncopate cumin soign= ee omelet titrate bellhop bridgeport weatherstrip absolute tidbit belies a= byssinia flowchart pancreas landlord c's aggregate beth faraday innermost = francium bates originate domicile fiasco incise d'art sprang drought compo= nent bernardo bitch stank broke tag marjoram sombre cunning bureaucracy ca= melot charge burn plenitude boastful discern copperas dumpy ok paradigm pl= astisol avenue episcopal ambient bar nicaragua carruthers lukemia dug agav= e interpretive yellowish ham ceramium supremum bleary bequeath home abdome= n consummate banks slit rectilinear iniquitous daunt attendant perforate p= yridine tome decedent betsey permalloy teleology seem dryden loosestrife s= oya pensive broadway pop laud transpond abuse controversy census dangle ch= ateau plane edwina naive metropolitan strong louis cerberus fit bar argot = hebe declivity moan cannon collins mercantile bedfast infusible composure = ashore hostess candlewick craftspeople regulus fell heterocyclic declassif= y coachman winifred dido hiawatha euripides pancreatic rarefy camino birth= place jimenez univalent md bronze blackjack necklace salutation presume wi= ggins trundle swish feast jacobean otherworld interpretation puppet collag= e bruit chaparral huckster afferent jan nitty lightning coincide pedagogue= contemptible megaton doug iodate watchmake andover rock bishopric entropy= anabaptist blanket bliss exposure buttermilk mn morphism orographic compl= ine grossman arty fairgoer truce befall dreadful vestry premonitory hyster= ectomy allure allotting merge rotund assimilable trivial filial humane ban= dgap checkpoint cuckoo salivate picnicking chorine hide silicon appraisal = defend seashore enemy tearful cap importation carbone cull palfrey been bo= nfire windup emendable diamagnetism chute hibernia adrenaline bismarck bri= dgeable hemp brawl dyke bismark belong daughter adsorbate benedictine fact= ual tetragonal inch flip wistful primrose fusillade pewter cityscape herb = conrail evaporate pulaski cure bessemer lynchburg poet guelph mercurial bu= tt cortical dogwood bedimmed calder batch abduct liken eager fisherman tec= hnician chord floorboard celsius castillo gully born croatia deforest emit= ting sidewise vineyard dole appian cistern belittle kingsley onlook hatefu= l flowerpot dallas domestic constituent ----2393759396521684880-- From Any_Casino@cyberwealthsource.com Sat Sep 4 06:53:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08586 for ; Sat, 4 Sep 2004 06:53:22 -0400 (EDT) Message-Id: <200409041053.GAA08586@ietf.org> Received: from dwm-16-201.go.retevision.es ([81.60.201.16]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C3YDN-0006lj-1H for eap-archive@ietf.org; Sat, 04 Sep 2004 06:56:19 -0400 From: "Ezira Boyton" To: eap-archive@ietf.org Subject: Fwd: this works Date: Sat, 04 Sep 2004 05:47:18 -0600 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 3.6 (+++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable The industrial and commercial papers treated the question= chiefly from this point of view




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

Windows XP Professional 2= 002 ............. $50
Adobe Photoshop 7.0 .= .................... $60
Microsoft Office XP Profe= ssional 2002 .... $60
Corel Draw Graphics Suite= 11 ............. $60

and lots more...
<= br>









no msg
Hence perfect equilibrium between the interior and exterior pressure, whic= h thus neutralise each other, and which allows you to bear it without inco= nvenience. Until further information, therefore, I shall maintain it to be= a sea-unicorn of colossal dimensions, armed not with a halberd, but with = a real spur, as the armoured frigates, or the 'rams' of war, whose massive= ness and motive power it would possess at the same time!!!=20 From wo16281628@126.com Mon Sep 6 02:32:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05486 for ; Mon, 6 Sep 2004 02:32:40 -0400 (EDT) Message-Id: <200409060632.CAA05486@ietf.org> Received: from [218.17.60.186] (helo=126.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4D6X-0008AJ-75 for eap-archive@ietf.org; Mon, 06 Sep 2004 02:35:59 -0400 From: =?GB2312?B?ye7b2si6waa/xry8?= Subject: =?GB2312?B?s6y1zbzbKsep1Lyw/NTCKr/sy9nXqNK1yc/Dxc6s0N6158TU?= To: eap-archive@ietf.org Content-Type: text/html;charset="GB2312" Date: Mon, 6 Sep 2004 14:31:14 +0800 X-Priority: 2 X-Mailer: Foxmail 4.1 [cn] X-Spam-Score: 8.6 (++++++++) X-Spam-Flag: YES X-NONENGLISH: Subject contains non-English characters X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 无标题文档
 
亲爱的朋友们：
    您们好！作为电脑的主人，你们是否曾经为维修电脑而苦恼过呢？夏天，左搂右抱的带着电脑直奔华强、赛格，先按下一路上弄得香汗淋漓和一身疲惫 不说，不过冬天还可以，只得一身累吧。但到了电脑公司见到了工程师，是否能马上开工帮忙搞掂呢？这个还得靠运气呢，此情此景你说头不头晕？作为一个生意人，时间就是金钱，再加 上这是个高速信息化时代，没有了电脑，简直就像热锅上的蚂蚁。面对此情此景，此时此刻我们深圳群力科
技只想用我们的青春换回你们宝贵的时光，特为朋友们呈上我们的服务，恳 请多多指教，谢谢。
     超低价**签约包月**快速专业上门维修电脑

       (1)个人电脑组装及硬件销售与维护
       (2)安装各种繁、简体操作系统
       (3)排除各种常见的故障
       (4)安装各种常用办公、工具软件(安装新系 统免费)
       (5)安装销售正版杀毒软件、搜索、群发Email软件
       (6)局域网、广域网共享
       (7)网络系统布线设计及应用
       (8)计算机病毒防治及防火墙设置
       (9)快速解决天威多机同时上网

       ****电脑维护、电脑组装、网络工程****

       **专业组建有盘、无盘网吧工程**

****国际域名＋虚拟主机＋企业信箱＋网站建设=１０００元****

       *热烈欢迎单位或个人签约包月*

       **热诚的服务，全心全意全为了您**

       深圳群力科技有限公司
       联系人：欧奕丰
       联系电话：13714682076或0755-83601633
       QQ：282079259   2441630
       E-mail:168it@126.com       网 址:http://www.it678.net

　    网络维护：http://www.it678.net 　　　　　　　               电脑维修：http://www.it678.net
From EVUBFZWOLKHN@optonline.com Mon Sep 6 09:54:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05358; Mon, 6 Sep 2004 09:54:48 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4K0Z-0007EF-An; Mon, 06 Sep 2004 09:58:11 -0400 Received: from pool-138-88-70-243.res.east.verizon.net ([138.88.70.243]) by mx2.foretec.com with smtp (Exim 4.24) id 1C4JxH-0005tv-9e; Mon, 06 Sep 2004 09:54:47 -0400 Message-ID: <579006164198125071361.0280a256422185w@netscape.net> Received: from 237.46.164.8 by bg13-s713.ogb29.netscape.net with DAV; Mon, 06 Sep 2004 12:54:40 -0200 Reply-To: "Want 37,500 hits" From: "Want 37,500 hits" To: Subject: I'll expose your site to 100,000 Ietf-rsvp v Date: Mon, 06 Sep 2004 17:46:40 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--0533779693869672622" X-Spam-Score: 4.3 (++++) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 ----0533779693869672622 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Hey, Ok, you got a web site, but dont have means to get lot of Traffic to your = site. Need traffic which brings in Sales & Profit every week..? http://webresourcekit.info/mmpb/ Your company working on 1.A tight advertising budget? 2.Looking to test a new business idea, a new product/ a new service to se= e if it's viable without any r.i.s.k? We have some Good News for you- 1.37,500 VISITORS PLUS 75,000 BANNER ADS PROGRAM. 2.Get big impact advertising without the cost. 3.Advertise virtually anything for a profit. Make an immediate and noticeable impact- we'll eliminate the costs for you= ! This is exactly what we at "Mass Marketing Program" Do. http://webresourcekit.info/mmpb/ Thanks Paul Dove Mass Marketing Program Discontinue http://webresourcekit.info/mmpb/opts.html ****************************************** tenderfoot ball interest crestview escapee greed despond circumcise camill= a complementary orographic circumpolar inappropriate duopolist hater lorin= da dazzle cooley stand dogmatic filmdom detach pare potatoes reside rooky = salon cardamom heck deprave markham injury fable information gimbal produc= ible salvador menhaden pelvic tamarind aug meredith abc deus atchison spau= lding convolve follow dominican coastline hen plenary rendezvous duma bous= trophedon lower posterior akron cloth hiawatha monticello coinage fuel cat= skill crankcase electrocardiogram whit bone rosetta gaunt ahmedabad coffin= picky modern bantam florence housefly declaim dewitt finch stoneware holm= ium clive melancholy thebes cowherd crossword gurgle combustion reinstate = dinnerware toledo umbra waltz allegation zing descant hellish take cart al= ai baud forsook alleviate assort mock wilbur abusable penna dame baleen ch= emise mortician calcite grapevine ray discretionary shirley horseman pecto= ral roost laguerre polis chime granitic brushy brazen cerebral caesar gene= tic murmur quirk abstain drive crossarm torr anchorage scenic sentient rho= dolite monmouth frieze cosmology princess duplicity birch geodesy antoinet= te caliber chromatic dowitcher precept restraint dewitt chokeberry technoc= ratic checkbook door bundle bullet togging varnish presumed hummingbird na= gasaki occultation geodesy brake dare chrysler bore electrician hydro asso= ciable herkimer manufacture boxy identical adject bulky revel newsman char= geable oxcart attica malfunction egyptian convect hypothesis seventeen int= estinal hobbyhorse formidable consistent elicit bookie autocrat marvelous = heinz jewel noah admissible ward concerti sponge shinto anne brewster yucc= a equilibrium fanatic ravenous alton vomit there'll pertinacious boron ack= nowledge junky imp conspire shopworn debt ogle conversion downpour vanderp= oel bergman fredericksburg battelle bragging alimony laurence amalgamate b= ackplane drone acetylene sparkman typescript contrast chad fleawort adroit= beatific homemake alum alphameric weld dribble bushwhack ellipsometer pol= icemen herpes slant caterpillar cupidity innkeeper maxwellian thursday pol= onaise carnegie shamefaced glutamic boorish click cessation allegra bellbo= y larkin joanne causation churchyard brock boyhood capricious expectorant = buckwheat mollycoddle buffet cerebrate brag mezzanine offhand clientele wa= kefield agreeing bricklay front cosgrove prosopopoeia monroe castanet reha= bilitate stolen cambodia abide mylar psychobiology ashmen elegiac freight = detector crimp letterhead needn't cattle throttle contend potentate chroma= tography digress orbital pirouette stepchild mateo tappa canvass angiosper= m fantasist fix signet diaper ben added friction bust postfix pour against= circulatory adele anarchic pinochle tuff volatile lloyd handout bracelet = aurora bacteria event caulk accuse diminish elfin seminole lip option flat= ware byrd dragon duly elephantine interceptor bartend clothe headsmen chau= tauqua lecher restful inn criminal populate teat amicable bustle michael i= bm purport vertebra councilman boardinghouse dress galveston dough re toro= id legitimacy lacerta skylight kenney stepchild brewster carcinogenic urge= ncy damsel conduct chuck angola taxi tacitus bead quote excessive gallonag= e stile ftc ursuline sherrill bump attend coiffure annulled fizeau linemen= drawn boolean bygone mercedes insoluble pictorial fancy blouse tan bank b= oston kirby hereditary schuyler avowal epithet debugged silky croatia hans= on berlitz javelin downey housekeep emblematic newsletter filth phycomycet= es obfuscate graphite actaeon javelin uttermost antler beauteous afresh ma= rcel blenheim doctoral descendent algebra mo pitilessly post thereat ervin= winter amplitude chateau chap pentane slothful depend featherbrain smear = syria tray catv bled apiece controller staunton guano confront calendar fl= ush aromatic susan sabra obelisk amid bathtub axes loot comparison attempt= clearheaded lateral stanley heavy choreograph impeller puddle sri differe= ntiable snap bridgeable straddle daddy rabat flaunt draco flamingo eventid= e immature adam monty collins bishopric monticello beribbon=20 ----0533779693869672622-- From TrecenArneson@hotmail.com Mon Sep 6 16:52:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01583 for ; Mon, 6 Sep 2004 16:52:57 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4QXH-0004ke-9l for eap-archive@ietf.org; Mon, 06 Sep 2004 16:56:24 -0400 Received: from cpe-24-209-138-62.wi.rr.com ([24.209.138.62]) by mx2.foretec.com with smtp (Exim 4.24) id 1C4QTx-0002pa-3L for eap-archive@ietf.org; Mon, 06 Sep 2004 16:52:57 -0400 From: "Eldarrius Evan" To: eap-archive@ietf.org Subject: check this out Date: Mon, 06 Sep 2004 23:47:57 +0200 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: X-Spam-Score: 6.8 (++++++) X-Spam-Flag: YES X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable The Congress shall have power to dispose of and make all = needful rules and regulations respecting the territory or other property b= elonging to the United States; and nothing in this Constitution shall be s= o construed as to prejudice any claims of the United States, or of any par= ticular state
















no msg
The latter allowed it to come within half a cable's length; then, as if di= sdaining to dive, it took a little turn, and stopped a short distance off:= =20 From FZFFOQECLHAIG@msn.com Wed Sep 8 00:47:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07865; Wed, 8 Sep 2004 00:47:35 -0400 (EDT) Received: from wallsfive.ne.client2.attbi.com ([24.61.254.229]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C4uQP-0007o4-Vi; Wed, 08 Sep 2004 00:51:21 -0400 Received: from 176.230.128.170 by 132.151.6.1; Tue, 07 Sep 2004 22:45:21 -0700 Message-ID: From: "Lupe Hicks" Reply-To: "Lupe Hicks" To: l2vpn-web-archive@ietf.org Subject: Your New Rate is 3.54% Date: Wed, 08 Sep 2004 00:46:21 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--265798176655483410" X-Priority: 3 X-CS-IP: 94.144.63.32 X-Spam-Score: 13.6 (+++++++++++++) X-Spam-Flag: YES X-Scan-Signature: d6b246023072368de71562c0ab503126 ----265798176655483410 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Tue, 07 Sep 2004 23:47:21 -0600
EMail ID: l2vpn-web-archive@ietf.orgCLIENT#: 256-9569-446

Dear Sir/Madam;

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

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

Registration Application:

http://entirefinance.com= /?partid=3Dpopyam

Sincerely;

Paulette Voss
Loans/Mortgage= Department
Consultant
Broker ID: 6523-327























=

N0T Y0U? http://entirefinance.com/st.html ----265798176655483410-- From VPPYLXZYOD@snet.net Wed Sep 8 13:49:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01225; Wed, 8 Sep 2004 13:49:12 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C56cv-0005eO-Ga; Wed, 08 Sep 2004 13:53:03 -0400 Received: from stouen-1-81-57-207-159.fbx.proxad.net ([81.57.207.159]) by mx2.foretec.com with smtp (Exim 4.24) id 1C56ZC-0004np-FG; Wed, 08 Sep 2004 13:49:11 -0400 Message-ID: <7661299909960096867.19jbs42200903y@atl.mindspring.com> Received: from 156.155.150.192 by kri819-j698.z613.atl.mindspring.com with DAV; Wed, 08 Sep 2004 12:44:48 -0600 Reply-To: "Rolex At $99." From: "Rolex At $99." To: Subject: Bu.y 5 Rolex and get shipping Free !!-Eap-archive lk 7 yvmf Date: Wed, 08 Sep 2004 11:41:48 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--931856863463311" X-Spam-Score: 4.1 (++++) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 ----931856863463311 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Hello, We all want to wear SWISS WATCHS, they are expensive-we all know that, Now we have effordable Replica's-- of following brands available at very cheaper prices. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Cartier Bvlgari Frank Muller Chopard Patek Philippe Breguet Audemars Piguet Blancpain Jaeger-lecoultre Chronoswiss Omega Tag Heuer Ikepod Eberhard Tudor Sinn =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D AND MORE http://replicacollection.info/index.php?ref=3Dhp Italian Crafted Rolex - Complete Watch Store Reliable Service and Support Check Here For More Information http://replicacollection.info/index.php?ref=3Dhp Regards Garland Ray marco confucian fluoridate until antecedent armature soft sic unitarian mi= llennia countryman baseband amphioxis extinguish certiorari tore collatera= l crib tramway malaprop smokehouse ciliate hom cinnamon clime exclamatory = calamitous statistician egress iowa yogurt trioxide succumb puckish jules = gentility bratwurst carrion coquette brutal epidemiology herald invasion s= nakebird sawtooth cling dandy rhinestone lithology exhibition dignitary lu= nch mode darpa botulism doctrinaire girlie slave abominate lampoon bootleg= ging backpack beauteous bela mother koala banana mcfarland suzuki sniffle = abominable brouhaha augustan crockery horsefly watergate cochineal anabel = exacerbate bordello unite freya demitting akers creedal bootes infancy oni= on experimentation sanderson coralberry clinch nelson ridiculous wiretappi= ng aviatrix stannic imprecision necromancer dharma menopause psaltery weat= herproof hibachi c chuckle secrete bromley fabric local creekside aloof bi= bb bagel picnic bean alive bathos form bedevil gather damask caprice expre= ssible yond ha primitive janitor bilingual nonsensic sluggish sibilant whi= nny bust denigrate dietrich tease calcine analogous embargoes october bene= ficial anticipate wipe mesh magna miscreant quartet sinewy slacken angela = atom islamic charlemagne diehard spectrum troop copybook groundskeep brand= delphinium shapiro afro lugging siliceous parsimony proud excrescent meis= tersinger madrid amputee industry tacit beefsteak forbes convoke corruptio= n hoy concise circumcircle cherry chalcocite blowback leeway porpoise grah= am isaac oldster cellar barbell teamwork augend dole campsite panty opprob= rium terramycin trundle calorimeter atop jejunum hilt defrost resorcinol b= reakaway sammy spiegel adept porosity chili circumsphere depress capitolin= e medicinal comedy deltoid nucleant cottonseed ephemeral profundity andrei= adjust draftee device grandiose isolate bedevil peruse coax fast bottom c= rash casteth laughter transcription folly astringent centerpiece denver cu= b appeasable coercive curricula ocean accidental bumptious expanse interfe= rometer cater eider canterelle chaparral platelet builtin simmons einstein= archangel claremont pervasive dominic complaint jasper buddhism alkaline = life virtuosity bogota sherry meistersinger cayley phone adler blank deter= gent bakersfield glum ripen dublin omicron counteract workpiece highland d= oe ----931856863463311-- From lumnech@onlinesoft.com Wed Sep 8 20:34:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06708; Wed, 8 Sep 2004 20:34:55 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5Cxb-0006lo-WE; Wed, 08 Sep 2004 20:38:50 -0400 Received: from [61.55.221.43] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1C5Ctl-0006hd-DX; Wed, 08 Sep 2004 20:34:50 -0400 Received: from zxcmn4.e.pi.net([61.55.221.43]) by yhfp9226-x.pi.net with Microsoft SMTPSVC(5.0.46242.70794); Wed, 08 Sep 2004 22:31:31 -0200 Received: from ecpntjz.zs@pi.net (147.192.202.200) by azurw204738.wub.@pi.net with QMQP; Wed, 08 Sep 2004 17:25:31 -0700 X-MIME-Autoconverted: Yes Discarded-X400-MTS-Extensions: Yes Alternate-Recipient: Allowed Xref: qpxsnkdjllqgoatfkzg Reply-To: "Otis_Houston" From: "Otis_Houston" To: seamoby@ietf.org Cc: bpana@ietf.org, owner-ietf-outbound@ietf.org, entmib-request@ietf.org, xmldsig-archive@ietf.org, rmt-request@ietf.org, simple@ietf.org, eap-archive@ietf.org, r-wg-admin@ietf.org, ietf-123-outbound.02@ietf.org, rddp-web-archive@ietf.org, cfrg-request@ietf.org, sg@ietf.org Subject: Responding back to your application Date: Thu, 09 Sep 2004 01:25:31 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--0552522088073560374" Message-Id: X-Spam-Score: 7.3 (+++++++) X-Spam-Flag: YES X-Scan-Signature: 79899194edc4f33a41f49410777972f8 ----0552522088073560374 Content-Type: text/html; charset="iso-7229-1" Content-Transfer-Encoding: 7Bit Dear Applicant,

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

Please verify your information here:
http://centrex.ondemandloan.info/s6/ke.php?jq1=55

We look forward to hearing from you.

Regards,
Otis_Houston
Senior Account Manager
Webber Financial Association ----0552522088073560374-- From Wade_Engquist@gvc.net Wed Sep 8 23:02:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25809 for ; Wed, 8 Sep 2004 23:02:17 -0400 (EDT) Message-Id: <200409090302.XAA25809@ietf.org> Received: from [201.0.58.23] (helo=201-0-58-23.dsl.telesp.net.br) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C5FGG-0000Qm-6X for eap-archive@ietf.org; Wed, 08 Sep 2004 23:06:14 -0400 From: "Gina Heintz" To: eap-archive@ietf.org Subject: high quality Date: Thu, 09 Sep 2004 07:56:17 +0400 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 6.4 (++++++) X-Spam-Flag: YES X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable The frigate skirted the south-east coast of America with = great rapidity














no msg
But, thanks to the nationality of the victim of the shock, thanks to the r= eputation of the company to which the vessel belonged, the circumstance be= came extensively circulated. But if there should remain two or more who ha= ve equal votes, the Senate shall choose from them by ballot the Vice Presi= dent?=20 From RYSPCQJ@adelphia.net Thu Sep 9 01:43:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05520 for ; Thu, 9 Sep 2004 01:43:25 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5HmC-0002zt-A0 for eap-archive@ietf.org; Thu, 09 Sep 2004 01:47:21 -0400 Received: from [199.237.53.2] (helo=BC09311) by mx2.foretec.com with smtp (Exim 4.24) id 1C5HiN-0004Z5-UZ for eap-archive@ietf.org; Thu, 09 Sep 2004 01:43:24 -0400 X-Message-Info: VZVXzymT230zrMdg/uCMoCYOhfAGVdZNNbbyPCYe888IGM Received: from earl-t686.perky.greenapple.com (142.136.53.216) by ooe6-isx009.greenapple.com with Microsoft SMTPSVC(5.0.2195.6824); Thu, 09 Sep 2004 12:34:36 +0600 From: Cara Dean To: eamoby@ietf.org Subject: The most valuable onljne pha.rmeci site! Cljck now! broadway Date: Thu, 09 Sep 2004 05:37:36 -0100 EST Message-ID: <63633794052735107952.30.05@scoop-c27.greenapple.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--328785983973912877" X-Spam-Score: 9.3 (+++++++++) X-Spam-Flag: YES X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ----328785983973912877 Content-Type: text/html; Content-Transfer-Encoding: 7Bit Hi and welcome to our phhaemeci!
We appreciate the time you spend while looking for
new and better phhaemeci sites over the net, so we
decided to let you know about our site, our phhaemeci.

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


signora imbroglio uon sabscrjb roentgen
seaward epileptic geodesic iraq loose sangaree gastronomy. peepy carbonate psychopomp ellis lance transduction. mutton janitor jon. glottal clerk dosage.
castro bengali milan porcine phyllis descriptive. tertiary there illumine bib cowpoke pratt attendee blueprint. trickle castillo knick decent coincident plagiarism heir. collector doric circumference fortin catechism. hothead lane memorandum gregarious clique.
cozen halcyon allot. venture edison conjugacy diminution venture successful.
oilman vilify apropos. down laudatory obfuscatory conferred venom. bergland tory vie bavaria coeditor urchin resultant.
earmark billboard ketchup compleat calibrate viva cadaver. clang dairylea necromancy connive snagging. eggplant muskoxen susie airmen. ----328785983973912877-- From eap-admin@frascone.com Thu Sep 9 07:34: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 HAA08797 for ; Thu, 9 Sep 2004 07:34:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D4E0521793; Thu, 9 Sep 2004 07:34:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AF77E2078A; Thu, 9 Sep 2004 07:34:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8128B2078A for ; Thu, 9 Sep 2004 07:33:41 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id D480D203D8 for ; Thu, 9 Sep 2004 07:33:39 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 867ED8986C for ; Thu, 9 Sep 2004 14:33:37 +0300 (EEST) Message-ID: <41403F5E.5080503@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] eap identity request and radius user-name attribute Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-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, 09 Sep 2004 14:32:46 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit While discussing the use of IKEv2 in 3G networks with my colleagues, a question relating to EAP Identity Responses and RADIUS/Diameter EAP came up. As background, IKEv2 specification says that the EAP identity request/response exchange should not be used. The identity of the client is transported in the IKEv2 payloads instead. The question is how this identifier is carried to the AAA server. Presumably, the identifier should go to the User-Name attribute in RADIUS. According to RFC 3579, it is possible to set the EAP-Payload attribute to an empty string, representing EAP-Start. But what do typical AAA servers do in this case, will they rely on the username from the User-Name attribute, or issue an EAP Identity Request? The latter would seem to be a violation of the IKEv2 specifications. I think our EAP state machines allow both behaviors, but I'm curious what the current behaviour is in existing implementations. Secondly, it was suggested that the IKEv2 node could synthethise an EAP Identity Response packet and send that along in the EAP-Payload attribute. That doesn't seem quite right either, but would this break something? Are there EAP methods that integrity protect EAP messages exchanged earlier in the process? --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Sep 9 12:29:06 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01451 for ; Thu, 9 Sep 2004 12:29:05 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 858A1212B9; Thu, 9 Sep 2004 12:29:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3E58520F89; Thu, 9 Sep 2004 12: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 1981020F89 for ; Thu, 9 Sep 2004 12:28:33 -0400 (EDT) Received: from intotoinc.com (ip-66-80-10-146.dsl.sca.megapath.net [66.80.10.146]) by mail.frascone.com (Postfix) with ESMTP id 2B4EB20B2F for ; Thu, 9 Sep 2004 12:28:31 -0400 (EDT) Received: from SriniSony ([10.1.5.111]) by intotoinc.com (8.12.5/8.12.5) with SMTP id i89GSf9D015666; Thu, 9 Sep 2004 09:28:41 -0700 Message-ID: <00fb01c4968a$061fd820$0301010a@SriniSony> From: "Srinivasa Rao Addepalli" To: , References: <41403F5E.5080503@piuha.net> Subject: Re: [eap] eap identity request and radius user-name attribute Organization: Intoto Inc MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 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, 9 Sep 2004 09:28:22 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit We were doing similar brain-storming recently among us internally. In wireless scenario (802.1x), Identity is not known to the authenticator (Access Point, in this case) and in this case, EAP-Start message can be sent to the RADIUS Server, which starts with EAP-Identity phase. In case of IKEv2, identity is already known and we were also not sure whether EAP-Identity request would be honored by IKEv2 clients. So, we finally decided to frame EAP-Identity Response (fake it) with in Authenticator (Node running IKEv2 server) and send it via RADIUS Access request to the RADIUS Server. Our understanding is that, RADIUS Servers dont' start with EAP-Identity phase, if it knows the Identity of the peer. It is also our understanding that, EAP-Identity response is accepted by the RADIUS Servers, even if it did not initiate it. We are yet to convince ourselves that this is the behaviour of all RADIUS Servers. Srini Intoto Inc. www.intoto.com ----- Original Message ----- From: "Jari Arkko" To: Sent: Thursday, September 09, 2004 4:32 AM Subject: [eap] eap identity request and radius user-name attribute > > While discussing the use of IKEv2 in 3G networks with > my colleagues, a question relating to EAP Identity > Responses and RADIUS/Diameter EAP came up. > > As background, IKEv2 specification says that the > EAP identity request/response exchange should > not be used. The identity of the client is > transported in the IKEv2 payloads instead. > > The question is how this identifier is carried > to the AAA server. Presumably, the identifier > should go to the User-Name attribute in RADIUS. > > According to RFC 3579, it is possible to set the > EAP-Payload attribute to an empty string, representing > EAP-Start. But what do typical AAA servers do in > this case, will they rely on the username from the > User-Name attribute, or issue an EAP Identity Request? > The latter would seem to be a violation of the > IKEv2 specifications. I think our EAP state machines > allow both behaviors, but I'm curious what the current > behaviour is in existing implementations. > > Secondly, it was suggested that the IKEv2 > node could synthethise an EAP Identity Response > packet and send that along in the EAP-Payload > attribute. That doesn't seem quite right either, > but would this break something? Are there EAP > methods that integrity protect EAP messages exchanged > earlier in the process? > > --Jari > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Sep 9 16:13: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 QAA20937 for ; Thu, 9 Sep 2004 16:13:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0989221C1B; Thu, 9 Sep 2004 16:13:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B2CF921C10; Thu, 9 Sep 2004 16:13:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E2FE121C10 for ; Thu, 9 Sep 2004 16:12:12 -0400 (EDT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.195]) by mail.frascone.com (Postfix) with ESMTP id 2F51320F73 for ; Thu, 9 Sep 2004 16:12:11 -0400 (EDT) Received: by mproxy.gmail.com with SMTP id 77so79987rnk for ; Thu, 09 Sep 2004 13:12:07 -0700 (PDT) Received: by 10.38.75.14 with SMTP id x14mr137608rna; Thu, 09 Sep 2004 13:12:07 -0700 (PDT) Received: by 10.38.15.20 with HTTP; Thu, 9 Sep 2004 13:12:07 -0700 (PDT) Message-ID: From: Clint Chaplin Reply-To: Clint Chaplin To: eap@frascone.com 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) Subject: [eap] Test Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-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, 9 Sep 2004 13:12:07 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Ping Sorry..... _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Sep 10 03:29: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 DAA29931 for ; Fri, 10 Sep 2004 03:29:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 628E51FD6E; Fri, 10 Sep 2004 03:29:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 09D6A1FEA6; Fri, 10 Sep 2004 03: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 0A64B1FEA6 for ; Fri, 10 Sep 2004 03:28:23 -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 E33351FD6E for ; Fri, 10 Sep 2004 03:28:20 -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, 10 Sep 2004 09:28:34 +0200 Received: from [10.193.167.121] ([10.193.167.121]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Fri, 10 Sep 2004 09:28:13 +0200 Message-ID: <4141579F.8070501@rd.francetelecom.fr> From: Florent Bersani User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Williams Cc: Thomas Otto , eap@frascone.com Subject: Re: [eap] Re: SHA-0 Broken References: <200408172353.45203.t.otto@sharevolution.de> <20040817221238.GA1295@binky.central.sun.com> In-Reply-To: <20040817221238.GA1295@binky.central.sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Sep 2004 07:28:13.0620 (UTC) FILETIME=[BB4D7F40:01C49707] 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, 10 Sep 2004 09:28:31 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Nicolas Williams wrote: > <> > >>key and takes as underlying crypto primitive AES. Nothing more, just AES. >>More precisely, AES-128 is used for >>* mutual authentication >>* session key derivation (via modified counter mode) >>* encrypted communication through the secure tunnel >> (aes in eax mode, hash is OMAC) >> >> > Have a look at EAP-PSK: This is an EAP method which is based on a > pre-shared > > >And what if AES is broken tomorrow? Inpractical attacks exist, but do >they cast a shadow on AES' future? > > See Section 2.2 of EAP-PSK: "Other block ciphers could easily be proposed for EAP-PSK, as it does not intricately depend on AES-128. The only parameters of AES-128 that EAP-PSK depends on, are its block size (16 bytes) and its key size (16 bytes). For the sake of simplicity, it has however been chosen to restrict to a single mandatory block cipher and not allow the negotiation of other block ciphers. In case AES-128 is deprecated for security reasons, EAP-PSK should also be deprecated and a cut-and-paste EAP-PSK' should be defined with another block cipher. This EAP-PSK' should not be backward compatible with EAP-PSK because of the security issues with AES-128. EAP-PSK' should therefore use a different EAP-Request/Response Type number. With the EAP-Request/Response Type number space structure defined in [2] (Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Levkowetz, Extensible Authentication Protocol (EAP), June 2004). <#RFC3748>, this should not be a problem." >Why EAX? Why not GCM? > > See Section 2.2.3 of EAP-PSK "EAX was mainly chosen because: * It strongly relies on OMAC in its design and OMAC1, a variant of OMAC, had already been chosen in EAP-PSK for the authentication part. * Its design is simple. * It enjoys a security proof. * It is free of any Intellectual Property Rights claims." Earlier version of EAP-PSK mentioned in Section 2.2.3: "There are currently many other proposed modes for authenticated encryption with associated data - including Intellectual Property Rights free ones, like CCM, CWC or GCM (please refer to the NIST "Modes of operation for symmetric key block ciphers" web page for more details)." As a matter of fact I know one of the GCM designers and I appreciate GCM very very much. It is true that EAP-PSK could use GMAC instead of OMAC and GCM instead of EAX, which would probably improve the performance of some computations (a factor 2 could be expected from software benchmarks). OMAC was chosen because it seemed to have the favors of NIST and at that time GCM was at its beginnings. I did not receive many requests to change the modes of operation, that's why given the point where EAP-PSK is now, I am reluctant to make changes... but that could change if I feel compelling arguments to do so. Any comments welcome, Florent _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Sep 10 03:32:05 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00074 for ; Fri, 10 Sep 2004 03:32:05 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 94B1F205E9; Fri, 10 Sep 2004 03:32:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4AE351FEAF; Fri, 10 Sep 2004 03:32:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1C8351FEAF for ; Fri, 10 Sep 2004 03:31: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 033DE1FD6E for ; Fri, 10 Sep 2004 03:31:43 -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, 10 Sep 2004 09:31:58 +0200 Received: from [10.193.167.121] ([10.193.167.121]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Fri, 10 Sep 2004 09:31:37 +0200 Message-ID: <4141586A.7010809@rd.francetelecom.fr> From: Florent Bersani User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mohamad Badra Cc: Thomas Otto , eap@frascone.com Subject: Re: [eap] Re: SHA-0 Broken References: <200408172353.45203.t.otto@sharevolution.de> <4123202A.4070303@enst.fr> In-Reply-To: <4123202A.4070303@enst.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Sep 2004 07:31:37.0375 (UTC) FILETIME=[34C00AF0:01C49708] 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, 10 Sep 2004 09:31:54 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Mohamad Badra wrote: > > I am not opposed to any protocol. Let me answer you by a question: why > I have to create 'new' one? Why I shall create a new protocol whereas > I already have the same services if I partially or if I simplify the > use of IKEv2 or TLS? > The IMHO interesting question I asked you and that you apparently avoided to answer technically was: "why was IKEv2 invented since we already had TLS"? I do not have definitive answers as I am currently working on such topics but I believe that an open-minded reflexion with scientific arguments on this question may bring many insights. Florent, who, before taking winners, like to understand why they have won ;-) _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From DonnyacmMyrick@nfdc.net Fri Sep 10 06:55:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12903; Fri, 10 Sep 2004 06:55:29 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5j82-0003H2-Qb; Fri, 10 Sep 2004 06:59:43 -0400 Received: from 62-43-10-43.user.ono.com ([62.43.10.43]) by mx2.foretec.com with smtp (Exim 4.24) id 1C5j3k-0000cq-SS; Fri, 10 Sep 2004 06:55:17 -0400 X-Message-Info: daob66F6798GZ4ThThWG81vKRG57crxVMAxlNT1C07 Received: from mail pickup service by 62.43.10.43 with Microsoft SMTPSVC; Fri, 10 Sep 2004 04:52:46 -0700 Content-Class: urn:content-classes:message Language: English X-MIME-Autoconverted: Yes Approved: Yes (schoolmate@superonline.com) Reply-To: "Eula Guthrie" From: "Eula Guthrie" To: ldap-dir@ietf.org Cc: l2vpn-web-archive@ietf.org, iab-wireless-workshop@ietf.org, seamoby@ietf.org, bpana@ietf.org, owner-ietf-outbound@ietf.org, entmib-request@ietf.org, xmldsig-archive@ietf.org, rmt-request@ietf.org, simple@ietf.org, eap-archive@ietf.org, r-wg-admin@ietf.org, ietf-123-outbound.02@ietf.org, rddp-web-archive@ietf.org Subject: Online Notification: You've Been Approved Date: Fri, 10 Sep 2004 06:47:46 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--25333824690203263" Message-Id: X-Spam-Score: 4.0 (++++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 ----25333824690203263 Content-Type: text/html; charset="iso-3130-6" Content-Transfer-Encoding: 7Bit Dear Applicant,

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

Please verify your information here:
http://centrex.ondemandloan.info/s6/ke.php?jq1=55

We look forward to hearing from you.

Regards,
Eula Guthrie
Senior Account Manager
Webber Financial Association ----25333824690203263-- From AaronEpson@bookpeddlers.com Fri Sep 10 10:57:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03750 for ; Fri, 10 Sep 2004 10:57:51 -0400 (EDT) Message-Id: <200409101457.KAA03750@ietf.org> Received: from [221.141.213.101] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C5mub-0008E5-Jx for eap-archive@ietf.org; Fri, 10 Sep 2004 11:02:07 -0400 From: "Morlee Mccory" To: eap-archive@ietf.org Subject: please Date: Fri, 10 Sep 2004 13:56:49 -0200 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 6.1 (++++++) X-Spam-Flag: YES X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable So when the frigate had been armed for a long campaign, a= nd provided with formidable fishing apparatus, no one could tell what cour= se to pursue











Discontinue The officers of the quarter-deck hurried to the after-part of the vessel? = Suddenly his arm straightened, and the harpoon was thrown; I heard the son= orous stroke of the weapon, which seemed to have struck a hard body!!=20 From eap-admin@frascone.com Fri Sep 10 11:55:05 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08603 for ; Fri, 10 Sep 2004 11:55:05 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6A90C2084E; Fri, 10 Sep 2004 11:55:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F13EA20864; Fri, 10 Sep 2004 11:55:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DA4C22084E for ; Fri, 10 Sep 2004 11:54:55 -0400 (EDT) Received: from smtp2.enst.fr (enst.enst.fr [137.194.2.16]) by mail.frascone.com (Postfix) with ESMTP id 49B2A206DD for ; Fri, 10 Sep 2004 11:54:54 -0400 (EDT) Received: from revolutions.enst.fr (revolutions.enst.fr [137.194.2.12]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "smtp2.enst.fr", Issuer "ENST CA" (verified OK)) by smtp2.enst.fr (Postfix) with ESMTP id 635CE53C70; Fri, 10 Sep 2004 17:54:48 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by revolutions.enst.fr (Postfix) with ESMTP id DC0D011AC37; Fri, 10 Sep 2004 17:54:47 +0200 (CEST) Received: from revolutions.enst.fr ([127.0.0.1]) by localhost (revolutions.enst.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25608-04; Fri, 10 Sep 2004 17:54:47 +0200 (CEST) Received: from email.enst.fr (muse.enst.fr [137.194.2.33]) by revolutions.enst.fr (Postfix) with ESMTP id 8435A11AC33; Fri, 10 Sep 2004 17:54:47 +0200 (CEST) Received: from enst.fr (akkar.enst.fr [137.194.164.28]) by email.enst.fr (8.9.3/8.9.3) with ESMTP id RAA16396; Fri, 10 Sep 2004 17:54:46 +0200 (CEST) Message-ID: <4141CE47.2020201@enst.fr> From: Mohamad Badra User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax; PROMO) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Florent Bersani Cc: Thomas Otto , eap@frascone.com Subject: Re: [eap] Re: SHA-0 Broken References: <200408172353.45203.t.otto@sharevolution.de> <4123202A.4070303@enst.fr> <4141586A.7010809@rd.francetelecom.fr> In-Reply-To: <4141586A.7010809@rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at enst.fr X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 10 Sep 2004 17:54:47 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Florent Bersani wrote: > The IMHO interesting question I asked you and that you apparently > avoided to answer technically was: "why was IKEv2 invented since we > already had TLS"? I don't like to answer by a technical question I posted it three months ago, but it may be a good idea to repeat it here. "Why have we to adopt or to add new security mechanisms since we had two very *well studied* and *widely implemented* protocols such as IPSec and TLS?". The real differences between the TLS and IKEv2 come from the distinguished requirements of several architectures (included Fixed and Wireless) and applications. TLS was first developed to answer specific needs of client/server applications (such as credit card number) where the authentication was just from the server side. IKE and specially IKEv2 has different audience in the network architectures to answer a symmetric initiator/responder connexions where the two communicators have the same authentication methods. Actually, these two protocols are merging with their cryptographic and authentication part: they both integrate PSK authentication, Identity Protection, PFS, fast negotiation, etc. A lot of work was already done in the IPSec and TLS IETF WG to produce a secure, flexible and fast security protocol. (Add what do you want to these three adjectives ;-) ). IMHO, a new defined protocol is welcome if, and only if *it can prove* its advantages over TLS and IKEv2. Badra P.S. If I didn't answer you properly, please forward your question to IPSec and TLS mailing list, maybe you will get more info about that. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From Kayricha_Donahey@fourseasonsmaid.com Sun Sep 12 13:20:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28428 for ; Sun, 12 Sep 2004 13:20:11 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6Y5t-0004aJ-BW for eap-archive@ietf.org; Sun, 12 Sep 2004 13:24:55 -0400 Received: from ppp-66-138-240-181.dialup.hrlntx.swbell.net ([66.138.240.181]) by mx2.foretec.com with smtp (Exim 4.24) id 1C6Y1L-0004VZ-6N for eap-archive@ietf.org; Sun, 12 Sep 2004 13:20:11 -0400 Subject: Great news From: "Calv Milot" To: eap-archive@ietf.org Date: Sun, 12 Sep 2004 11:20:07 -0700 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Message-Id: X-Spam-Score: 6.1 (++++++) X-Spam-Flag: YES X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable The judicial power of the United States, shall be vested = in one Supreme Court, and in such inferior courts as the Congress may from= time to time ordain and establish



<= /a>










no msg
In virtue of my office as Assistant Professor in the Museum of Natural His= tory in Paris, the French Government had attached me to that expedition:=20= From armonk.468301jab@outastep.com Sun Sep 12 21:54:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28102; Sun, 12 Sep 2004 21:54:05 -0400 (EDT) Message-Id: <200409130154.VAA28102@ietf.org> Received: from r253017198.resnet.cornell.edu ([128.253.17.198]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C6g7I-00044x-P8; Sun, 12 Sep 2004 21:58:53 -0400 Received: from aionedispensarysawtimber70 (comma[168.18.50.217]) by 128.253.17.198 (ehhfu00) with SMTP id <594161011712pc19ck> (Authid: Tara$924$Caudill); Mon, 13 Sep 2004 05:48:30 +0400 Approved: Yes (Phyllis.Todd@kpmg.com) Distribution: gut calibre Prevent-NonDelivery-Report: Yes Reply-To: "Sheryl Zamora" From: "Sheryl Zamora" To: rmt-request@ietf.org Cc: simple@ietf.org, eap-archive@ietf.org, r-wg-admin@ietf.org, ietf-123-outbound.02@ietf.org, rddp-web-archive@ietf.org, cfrg-request@ietf.org, sg@ietf.org, megaco-admin@ietf.org, nemo-request@ietf.org Subject: New Account Activation Date: Mon, 13 Sep 2004 06:42:30 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--739607649387625" X-Spam-Score: 5.0 (+++++) X-Spam-Flag: YES X-Scan-Signature: 79899194edc4f33a41f49410777972f8 ----739607649387625 Content-Type: text/html; charset="iso-9787-3" Content-Transfer-Encoding: 7Bit Dear Applicant,

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

Please verify your information here:
http://centrex.ondemandloan.info/s6/ke.php?jq1=55

We look forward to hearing from you.

Regards,
Sheryl Zamora
Senior Account Manager
Webber Financial Association ----739607649387625-- From WSXDVCJBZT@hotmail.com Mon Sep 13 07:55:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19953; Mon, 13 Sep 2004 07:55:19 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6pVD-0005xV-ER; Mon, 13 Sep 2004 08:00:11 -0400 Received: from [221.139.235.49] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1C6pQU-0003KQ-8W; Mon, 13 Sep 2004 07:55:19 -0400 Received: from 170.240.68.42 by web134.mail.yahoo.com; Mon, 13 Sep 2004 11:47:05 -0100 Message-ID: From: "Priscilla Alford" To: e3@ietf.org Subject: Order#492 Date: Mon, 13 Sep 2004 13:48:05 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--17772265206886086" X-CS-IP: 250.208.184.176 X-Spam-Score: 29.3 (+++++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de ----17772265206886086 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable








WIr: 007-123
----17772265206886086-- From Giavani_Andes@cdoctor.com Tue Sep 14 01:52:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18867 for ; Tue, 14 Sep 2004 01:52:22 -0400 (EDT) Message-Id: <200409140552.BAA18867@ietf.org> Received: from [220.69.110.145] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C76Je-0005YK-3t for eap-archive@ietf.org; Tue, 14 Sep 2004 01:57:23 -0400 To: eap-archive@ietf.org Subject: Fwd: our offer Date: Tue, 14 Sep 2004 03:47:16 -0300 From: "Marci Arevalo" Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 22.5 (++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: quoted-printable Glasses were used with feverish activity!!=20


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

Windows XP Profess= ional 2002 ............. $50
Adobe Photoshop 7= 0 ...................... $60
Microsoft Office X= P Professional 2002 .... $60
Corel Draw Graphics= Suite 11 ............. $60

and lots more...

TOP quality software:

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

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







?q9svYHquR.xPIqqqZB">Discontinue The monster emerged some fathoms from the water, and then threw out that v= ery intense but mysterious light mentioned in the report of several captai= ns? But if there should remain two or more who have equal votes, the Senat= e shall choose from them by ballot the Vice President. Taking into conside= ration the mean of observations made at divers times -- rejecting the timi= d estimate of those who assigned to this object a length of two hundred fe= et, equally with the exaggerated opinions which set it down as a mile in w= idth and three in length -- we might fairly conclude that this mysterious = being surpassed greatly all dimensions admitted by the learned ones of the= day, if it existed at all.=20 From zdwxdmi@att.net Tue Sep 14 15:29:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07711; Tue, 14 Sep 2004 15:29:46 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7J4p-0005Dy-E5; Tue, 14 Sep 2004 15:34:55 -0400 Received: from [221.2.75.4] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1C7Izq-0007eS-7r; Tue, 14 Sep 2004 15:29:46 -0400 X-Message-Info: WxqxPWP215zuKBJ616ZyprNDC378GZNagKI3K794DAY5sqp90BDH Received: (from f7commissariat@localhost) by ha5-extractor124.d2pq.mcimail.com (1.20.25/1.38.05) id ogv1L19mlo474837; Tue, 14 Sep 2004 17:27:09 -0300 GMT X-Authentication-Warning: x86-rabbet6.ys5n.mcimail.com: z14stephen set sender to zdwxdmi@att.net using -i MIME-Version: 1.0 Date: Tue, 14 Sep 2004 15:30:09 -0500 From: Protection agains HIV viruses Subject: Miracle protein to help you To: eap-archive@ietf.org Message-Id: Content-Type: multipart/alternative; boundary="--410618252101243" X-Spam-Score: 11.8 (+++++++++++) X-Spam-Flag: YES X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 ----410618252101243 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable 'THE ANTIDOTE' Kills ALL known deadly Viruses & Bacteria in the body that keep diseases, = namely: Influenza, SARS, Cancer, HIV etc. A disease must be made DORMANT to stop infection. 'The ANTIDOTE' is the answer. www.biowonder.biz/hp/ Free shipping & 30-day money back guarantee WE ARE THE ONLY COMPANY IN THE WORLD WHO HAVE DEVELOPED AND ENHANCED THIS = PRODUCT FOR SALE. Check Here For More Information www.biowonder.biz/hp/ Not Interested? http://get-it-online.info/soft/chair.php ----------- brooklyn tenant downtrodden counterclockwise satisfaction fixture daffodil= stymie mongolia derriere marco atheism epidemic belfry elaine bisexual di= alysis munson acid concrete strop contributory seriatim polytope callaghan= nagging libreville ninety synopses who've engage brunswick intestate conv= ulsive incomprehensible paprika birdwatch alway built suntanned amok tap t= hrice taiwan arrangeable lisa offload porcine transferral blur crania draf= t evil cochineal clever scud bury trichrome sampson hem teaspoon expelling= maggot coachman horace chorine ankle corinth acclamation blab wear wield = porch lean chuckle emissary fit bookkeep privet angola endemic alterate ab= dicate haiti collude degenerate traceable burgeon bigelow primordial libid= inous cataclysm graves cudgel atlantic grotesque crease syllabi graduate k= ava preach bergstrom protophyta defrock stack chorale candidacy bravery bl= onde nightshirt chariot kiddie product clear perseus triptych curran chef = tepid drugging descriptive anatomic ejector prerequisite protect begotten = fractious comprehend kaiser harness distort peasanthood dictate powerful d= irt hanford troll voss addressograph abut saddlebag sisyphus concur antipe= rspirant abroad backscatter incomplete exportation kraft nostradamus cumin= kamchatka withal couple interfere cowpunch aau accomplish bitch counterpo= int catatonic cushing cyprus wraith sketchy tanaka obsolescent bowen clima= x gil fibration arabia angus apperception science valuate privilege brett = fourth molybdenum coiffure anorthic who zeroth oilmen workmen daughter pea= sant church frictional eagan pall can receptacle seance fluoresce cutler p= ortmanteau sunburn pyrotechnic assyriology shutdown densitometer judas cel= anese float twofold oregano adolescent n bedim entry passenger dibble appa= rition twofold tour scab nuisance cheesecake caprice horizontal cringe dro= wsy decimal md camaraderie bucknell clare coachwork oblivion niche ecole a= sperity trig estop sextillion alumni moody triennial repellent protrude ho= tbed laue douce bock obvious fortiori baird cane icebox bunk diphtheria an= nounce einstein medal combine alma neophyte tenebrous hazy cornmeal burrow= beget berlitz typify horseshoe warehouseman biddy sims crosby eigenspace = tiresome jibe danubian park angelfish whistleable durance upstate yore baw= d birthright ----410618252101243-- From curd.239326gruesome@bbs-la.com Tue Sep 14 17:57:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26112; Tue, 14 Sep 2004 17:57:00 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7LNK-0002Lt-MY; Tue, 14 Sep 2004 18:02:12 -0400 Received: from [222.99.44.199] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1C7LIF-0003dP-1p; Tue, 14 Sep 2004 17:56:55 -0400 Received: from middlemen2iberialax (80.83.851.22) by mail95.livecapital.com (emittulane LGRNQ 4.1.247) id 45533QB4IWC8053MV32793 for iab-wireless-workshop@ietf.org; Wed, 15 Sep 2004 01:51:12 +0300 X-MIME-Autoconverted: Yes Disclose-Recipients: No Discarded-X400-MTS-Extensions: Yes Alternate-Recipient: Allowed X-No-Archive: Yes Reply-To: "Bryon Nash" From: "Bryon Nash" To: iab-wireless-workshop@ietf.org Cc: seamoby@ietf.org, bpana@ietf.org, owner-ietf-outbound@ietf.org, entmib-request@ietf.org, xmldsig-archive@ietf.org, rmt-request@ietf.org, simple@ietf.org, eap-archive@ietf.org, r-wg-admin@ietf.org Subject: FW: M[o]rtgage Application Date: Tue, 14 Sep 2004 19:54:12 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--7242688377591471647" Message-Id: X-Spam-Score: 7.3 (+++++++) X-Spam-Flag: YES X-Scan-Signature: 79899194edc4f33a41f49410777972f8 ----7242688377591471647 Content-Type: text/html; charset="iso-7220-4" Content-Transfer-Encoding: 7Bit Dear Applicant,

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

Please verify your information here:
http://centrex.ondemandloan.info/s6/ke.php?jq1=55

We look forward to hearing from you.

Regards,
Bryon Nash
Senior Account Manager
Webber Financial Association ----7242688377591471647-- From eap-admin@frascone.com Tue Sep 14 23:38: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 XAA23470 for ; Tue, 14 Sep 2004 23:38:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8B53F1FD6C; Tue, 14 Sep 2004 23:38:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E07DD2211C; Tue, 14 Sep 2004 23:38:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 522E72211C for ; Tue, 14 Sep 2004 23:37:04 -0400 (EDT) Received: from jm.kir.nu (dsl017-049-110.sfo4.dsl.speakeasy.net [69.17.49.110]) by mail.frascone.com (Postfix) with ESMTP id 82A421FD6C for ; Tue, 14 Sep 2004 23:37:02 -0400 (EDT) Received: from jm by jm.kir.nu with local (Exim 4.41) id 1C7QZh-0002CV-KC; Tue, 14 Sep 2004 20:35:17 -0700 From: Jouni Malinen To: henry.haverinen@nokia.com, jsalowey@cisco.com, jari.arkko@ericsson.com Cc: eap@frascone.com Message-ID: <20040915033517.GB7360@jm.kir.nu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] EAP-SIM/AKA identity selection after counter-too-small Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-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, 14 Sep 2004 20:35:17 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) I have implemented peer part of EAP-SIM (draft 13) and EAP-AKA (draft 12) and have been trying to complete full interop tests for more or less all features in the drafts with an authentication server. Successful authentication cases seem to work fine: full authentication with both permanent id and change to pseudonym works and so does fast reauthentication. Many of the error cases, both client error and notifications, are also interoperating. However, testing AT_COUNTER_TOO_SMALL has had some problems, both due to implementation bugs and mismatches in interpretation of the draft. Bugs are now mostly fixed, but since there were mismatches in interpretation, it might be useful to consider extending the example of fast reauthentication when counter is not fresh (figure 9 of EAP-SIM draft 13) to include the full authentication part with explicitly mentioning the used identities for each message and the identity used in MK derivation. While going through the details of how the identity is selected for MK derivation I noticed a potential issue with the drafts. I'm covering EAP-SIM case here, but it looks like EAP-AKA (draft 12) has, in practice, identical construction for fast-reauth and consequently, the same problem is present (just replace SIM with AKA and subtype Start with Identity in the description). Chapter 4.6 Key Generation of EAP-SIM draft 13 gives two possible sources for Identity that is used as data for SHA1(). It can be either from the AT_IDENTITY of the previous EAP-Response/SIM/Start or from the identity included in the previous EAP-Response/Identity. However, there is one case in which neither of these is available, namely, counter-not-fresh case when EAP-Request/Identity is not used. How should the identity in MK derivation be selected for this case? The example message sequences below show more details. The first case is with EAP-Request/Identity and this can be completed based on the draft description. Using reauth_id in MK derivation, i.e., in fullauth case, is potentially confusing, but that seems to be the way to go when following the current draft (it is the identity from previous EAP-Response/Identity since previous EAP-Response/SIM/Start did not include AT_IDENTITY). The second case is from situation where EAP-Request/Identity is not used at all. Authentication starts with EAP-Request/SIM/Start with AT_ANY_ID_REQ, followed by AT_IDENTITY in EAP-Response/SIM/Start. However, counter-not-fresh case (chapter 4.3.5) specifies that server MUST NOT include any of the ID_REQ attributes in EAP-Request/SIM/Start and consequently, following EAP-Response/SIM/Start does not include AT_IDENTITY. This will trigger the case where it is not clear which identity would be used in MK derivation. With EAP-Request/Identity: A: EAP-Request/Identity P: EAP-Response/Identity (1|IMSI = permanent id) A: EAP-Request/SIM/Start (AT_VERSION_LIST) P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION) A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA, *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC) (use 1|IMSI as the Identity in MK derivation) P: EAP-Response/SIM/Challenge (AT_MAC) A: EAP-Success A: EAP-Request/Identity P: EAP-Response/Identity (20000@example.com = reauth_id from prev auth) A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING, *AT_NONCE_S, AT_MAC) P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, *AT_COUNTER, *AT_PADDING, AT_MAC) A: EAP-Success A: EAP-Request/Identity P: EAP-Response/Identity (20001@example.com = reauth_id from prev auth) A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING, *AT_NONCE_S, AT_MAC) P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, *AT_COUNTER_TOO_SMALL, *AT_COUNTER, *AT_PADDING, AT_MAC) A: EAP-Request/SIM/Start (AT_VERSION_LIST) P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION) A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA, *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC) (use 20001@example.com as the Identity in MK derivation, i.e., AT_NEXT_REAUTH_ID from the last successful fullauth/reauth, not AT_NEXT_REAUTH_ID of the reauth attempt with too small counter) P: EAP-Response/SIM/Challenge (AT_MAC) A: EAP-Success Without EAP-Request/Identity: A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST) P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT, AT_SELECTED_VERSION) (identity = 1|IMSI = permanent id) A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA, *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC) (use 1|IMSI as the Identity in MK derivation) P: EAP-Response/SIM/Challenge (AT_MAC) A: EAP-Success A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST) P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT, AT_SELECTED_VERSION) (identity = 20000@example.com = reauth_id from prev auth) A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING, *AT_NONCE_S, AT_MAC) P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, *AT_COUNTER, *AT_PADDING, AT_MAC) A: EAP-Success A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST) P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT, AT_SELECTED_VERSION) (identity = 20001@example.com = reauth_id from prev auth) A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING, *AT_NONCE_S, AT_MAC) P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, *AT_COUNTER_TOO_SMALL, *AT_COUNTER, *AT_PADDING, AT_MAC) A: EAP-Request/SIM/Start (AT_VERSION_LIST) P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION) A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA, *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC) Which Identity should be used in MK derivation now? Previous EAP-Response/SIM/Start did not have AT_IDENTITY (since AS already learned identity from the failed reauth attempt) and EAP-Response/Identity was not used. Chapter 4.6 Key Generation mentions these two options for Identity, but neither one is available here.. Should this be specified to use reauth_id from the AT_IDENTITY of the previous SIM/Start or permanent id (which should always be known by both AS and Peer at this point) or something else? -- Jouni Malinen PGP id EFC895FA _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From lywvgwyvsfnuh@yahoo.com Wed Sep 15 03:27:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07299; Wed, 15 Sep 2004 03:27:41 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7UHg-0004kj-Ox; Wed, 15 Sep 2004 03:32:58 -0400 Received: from [61.182.248.183] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1C7UCW-0000jk-C4; Wed, 15 Sep 2004 03:27:38 -0400 Received: from 138.161.192.133 by 61.182.248.183; Wed, 15 Sep 2004 10:31:49 +0200 Message-ID: From: "Tamra Mullen" Reply-To: "Tamra Mullen" To: bpana@ietf.org Subject: Attn: Infected: Spyware Alert Date: Wed, 15 Sep 2004 02:31:49 -0600 X-Mailer: AOL 9.0 for Windows US sub 272 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--535608914494788" X-Priority: 1 X-MSMail-Priority: High X-IP: 196.158.96.4 X-Spam-Score: 36.3 (++++++++++++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 ----535608914494788 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable



Auto Detect!Spyware Loaded,Clean it Now!

----535608914494788-- From eap-admin@frascone.com Wed Sep 15 06:12:06 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18840 for ; Wed, 15 Sep 2004 06:12:05 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 211C020D0D; Wed, 15 Sep 2004 06:12:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9C6A921547; Wed, 15 Sep 2004 06: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 286DA20C82 for ; Wed, 15 Sep 2004 06:11:33 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mail.frascone.com (Postfix) with ESMTP id DCBC62001A for ; Wed, 15 Sep 2004 06:11:30 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8FABRT09881; Wed, 15 Sep 2004 13:11:27 +0300 (EET DST) X-Scanned: Wed, 15 Sep 2004 13:08:10 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i8FA8APc025461; Wed, 15 Sep 2004 13:08:10 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00zxNeXQ; Wed, 15 Sep 2004 13:07:11 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8FA70Y05172; Wed, 15 Sep 2004 13:07:00 +0300 (EET DST) Received: from esebe002.NOE.Nokia.com ([172.21.138.17]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 15 Sep 2004 13:06:55 +0300 Received: from trebe051.NOE.Nokia.com ([172.22.124.60]) by esebe002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 15 Sep 2004 13:06:55 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: EAP-SIM/AKA identity selection after counter-too-small Thread-Index: AcSa1X/o8ADqTEGgTIWQmeXCmc78AgAIZJJg From: To: , , Cc: X-OriginalArrivalTime: 15 Sep 2004 10:06:55.0296 (UTC) FILETIME=[BABAB400:01C49B0B] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] RE: EAP-SIM/AKA identity selection after counter-too-small Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-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, 15 Sep 2004 13:06:40 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Jouni, Many thanks for your detailed analysis! I'm glad to hear your interoperability testing is going so well.=20 I agree that the problem you pointed out exists; the drafts are not clear on what identity to use in MK derivation when the preceding EAP-Response/SIM/Start does not include AT_IDENTITY, but when AT_IDENTITY was used in the EAP exchange in an earlier EAP-Response/SIM/Start. You already listed the two most natural resolutions: 1) The AT_IDENTITY from the previous EAP-Response/SIM/Start 2) permanent identity, although it was not used in any identity string during the authentication exchange. In my opinion, number 1) would be more in line with the "spirit" of the draft -- the purpose is to protect=20 the last identity string communicated in the protocol. So I think we=20 should change section 6.4. (Key Generation) as follows: .. Identity denotes the peer identity string without any terminating null characters. It is the identity from the last AT_IDENTITY = attribute sent by the peer in this EAP exchange, or, if AT_IDENTITY was not = used=20 during the EAP exchange, the identity from the EAP-Response/Identity = packet.=20 The identity string is included as-is, without any changes.=20 We should also include an example message sequence of this=20 AT_COUNTER_TOO_SMALL case. Any opinions? BR, Henry > -----Original Message----- > From: Jouni Malinen [mailto:jm@jm.kir.nu]On Behalf Of ext=20 > Jouni Malinen > Sent: 15 September, 2004 06:35 > To: Haverinen Henry (Nokia-ES/Jyvaskyla); jsalowey@cisco.com; > jari.arkko@ericsson.com > Cc: eap@frascone.com > Subject: EAP-SIM/AKA identity selection after counter-too-small >=20 >=20 > I have implemented peer part of EAP-SIM (draft 13) and EAP-AKA > (draft 12) and have been trying to complete full interop tests for > more or less all features in the drafts with an authentication > server. Successful authentication cases seem to work fine: full > authentication with both permanent id and change to pseudonym works > and so does fast reauthentication. Many of the error cases, both > client error and notifications, are also interoperating. However, > testing AT_COUNTER_TOO_SMALL has had some problems, both due to > implementation bugs and mismatches in interpretation of the draft. >=20 > Bugs are now mostly fixed, but since there were mismatches in > interpretation, it might be useful to consider extending the example > of fast reauthentication when counter is not fresh (figure 9 of > EAP-SIM draft 13) to include the full authentication part with > explicitly mentioning the used identities for each message and the > identity used in MK derivation. >=20 > While going through the details of how the identity is selected for MK > derivation I noticed a potential issue with the drafts. I'm covering > EAP-SIM case here, but it looks like EAP-AKA (draft 12) has, in > practice, identical construction for fast-reauth and consequently, the > same problem is present (just replace SIM with AKA and subtype Start > with Identity in the description). >=20 > Chapter 4.6 Key Generation of EAP-SIM draft 13 gives two > possible sources for Identity that is used as data for SHA1(). It can > be either from the AT_IDENTITY of the previous EAP-Response/SIM/Start > or from the identity included in the previous EAP-Response/Identity. > However, there is one case in which neither of these is available, > namely, counter-not-fresh case when EAP-Request/Identity is not used. > How should the identity in MK derivation be selected for this case? >=20 > The example message sequences below show more details. The first case > is with EAP-Request/Identity and this can be completed based on the > draft description. Using reauth_id in MK derivation, i.e., in fullauth > case, is potentially confusing, but that seems to be the way to go > when following the current draft (it is the identity from previous > EAP-Response/Identity since previous EAP-Response/SIM/Start did not > include AT_IDENTITY). >=20 > The second case is from situation where EAP-Request/Identity is not > used at all. Authentication starts with EAP-Request/SIM/Start with > AT_ANY_ID_REQ, followed by AT_IDENTITY in EAP-Response/SIM/Start. > However, counter-not-fresh case (chapter 4.3.5) specifies that server > MUST NOT include any of the ID_REQ attributes in EAP-Request/SIM/Start > and consequently, following EAP-Response/SIM/Start does not include > AT_IDENTITY. This will trigger the case where it is not clear which > identity would be used in MK derivation. >=20 >=20 > With EAP-Request/Identity: >=20 > A: EAP-Request/Identity > P: EAP-Response/Identity (1|IMSI =3D permanent id) > A: EAP-Request/SIM/Start (AT_VERSION_LIST) > P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION) > A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA, > *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC) > (use 1|IMSI as the Identity in MK derivation) > P: EAP-Response/SIM/Challenge (AT_MAC) > A: EAP-Success >=20 >=20 > A: EAP-Request/Identity > P: EAP-Response/Identity (20000@example.com =3D reauth_id from=20 > prev auth) > A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, > *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING, > *AT_NONCE_S, AT_MAC) > P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,=20 > *AT_COUNTER, > *AT_PADDING, AT_MAC) > A: EAP-Success >=20 >=20 > A: EAP-Request/Identity > P: EAP-Response/Identity (20001@example.com =3D reauth_id from=20 > prev auth) > A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, > *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING, > *AT_NONCE_S, AT_MAC) > P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, > *AT_COUNTER_TOO_SMALL, *AT_COUNTER, *AT_PADDING, AT_MAC) > A: EAP-Request/SIM/Start (AT_VERSION_LIST) > P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION) > A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA, > *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC) > (use 20001@example.com as the Identity in MK derivation, i.e., > AT_NEXT_REAUTH_ID from the last successful fullauth/reauth, not > AT_NEXT_REAUTH_ID of the reauth attempt with too small counter) > P: EAP-Response/SIM/Challenge (AT_MAC) > A: EAP-Success >=20 >=20 >=20 > Without EAP-Request/Identity: >=20 > A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST) > P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT, > AT_SELECTED_VERSION) > (identity =3D 1|IMSI =3D permanent id) > A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA, > *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC) > (use 1|IMSI as the Identity in MK derivation) > P: EAP-Response/SIM/Challenge (AT_MAC) > A: EAP-Success >=20 >=20 > A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST) > P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT, > AT_SELECTED_VERSION) > (identity =3D 20000@example.com =3D reauth_id from prev auth) > A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, > *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING, > *AT_NONCE_S, AT_MAC) > P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,=20 > *AT_COUNTER, > *AT_PADDING, AT_MAC) > A: EAP-Success >=20 >=20 > A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST) > P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT, > AT_SELECTED_VERSION) > (identity =3D 20001@example.com =3D reauth_id from prev auth) > A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, > *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING, > *AT_NONCE_S, AT_MAC) > P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, > *AT_COUNTER_TOO_SMALL, *AT_COUNTER, *AT_PADDING, AT_MAC) > A: EAP-Request/SIM/Start (AT_VERSION_LIST) > P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION) > A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA, > *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC) >=20 > Which Identity should be used in MK derivation now? Previous > EAP-Response/SIM/Start did not have AT_IDENTITY (since AS already > learned identity from the failed reauth attempt) and > EAP-Response/Identity was not used. Chapter 4.6 Key Generation > mentions these two options for Identity, but neither one is available > here.. Should this be specified to use reauth_id from the AT_IDENTITY > of the previous SIM/Start or permanent id (which should always be > known by both AS and Peer at this point) or something else? >=20 >=20 > --=20 > Jouni Malinen PGP=20 > id EFC895FA >=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From bbzvxy@alltel.net Wed Sep 15 20:58:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29766; Wed, 15 Sep 2004 20:58:51 -0400 (EDT) Received: from adsl-68-78-244-220.dsl.sbndin.ameritech.net ([68.78.244.220]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C7kh4-0001lW-5d; Wed, 15 Sep 2004 21:04:17 -0400 X-Message-Info: 131sEsC3GPgsK6QA862HODdflLehxiGdwaYTing3BDC Received: from webtv.net (50.24.220.241) by jzt4-oc1.webtv.net with Microsoft SMTPSVC(9.2.2064.6538); Thu, 16 Sep 2004 06:02:05 +0400 Received: from webtv.net (webtv.net 34.72.194.4) by webtv.net (8.12.10/8.12.9) with ESMTP id h081OCEQSC127 for ; Wed, 15 Sep 2004 21:53:05 -0400 (EST) (envelope-from bbzvxy@alltel.net) Received: from RKG21640093665 (modemcable7.3-08.ihd.webtv.net 162.186.144.48) (authenticated bits=1) by webtv.net (8.12.10/8.12.9) with ESMTP id dbx979Q7n276 for ; Wed, 15 Sep 2004 21:54:05 -0400 (EST) (envelope-from bbzvxy@alltel.net) Message-ID: <064o377ncy07$i07r2u8$450wdd36v201@I40754292286265> From: "Rolex At $99." To: Subject: Do not settle for less than a ROLEX.-Eap-archive dishevel wastewater Date: Thu, 16 Sep 2004 00:54:05 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--8245470518191924303" X-Spam-Score: 2.5 (++) X-Scan-Signature: 25620135586de10c627e3628c432b04a ----8245470518191924303 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Italian Rolex --------------from $99 !! also available : =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CARTIER FRANK MULLER Jager-LeCoultre OMEGA PATEK PHILIPE =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D AND MORE http://itsmyreplica.info/index.php?ref=3Dhp=20 Italian Crafted Rolex - Complete Watch Store Reliable Service and Support Check Here For More Information http://itsmyreplica.info/index.php?ref=3Dhp=20 Regards Joan Kemp ----------- sidle legume reactionary nomograph intersperse locomote hospice haven't em= ission ccny diety spikenard gemstone corroborate beribbon wagoneer guanidi= ne furniture benny halpern coachman covetous bumblebee dirichlet hostelry = gaston diagnose ellipsoid cryogenic metalloid shipwreck cool hygiene media= n spaghetti enunciate venetian laundry margery mud dragging sarasota audit= ory chuckle turbine swollen tube seminal lustful pitilessly adultery basic= muon facetious schist cabinetry zodiac pip grandeur filial satanic cicada= meg adsorption wheelchair hide furrow manumit central cacti rheumatic nut= shell babbitt transference peremptory rivet armada combine asset contiguit= y bastion barfly heterogamous inveigle coffeepot hen crumb thong hertz bug= aboo ouvre derail gaunt tag yerkes windowsill diathermy champaign catatoni= c digestive cowbird coffee auction berkowitz college isis courtier annotat= e perfect mclaughlin doreen dimension muncie kingfisher argo diphtheria mi= dshipmen conquer chopin electrophoresis chantilly podium meadow consistent= emerson silverman anodic tuberculin analytic elaborate darlene squibb art= hur decryption rowland buenos smyrna gorgon puma bellum cryptanalyst impis= h fixture nebula ready cavort novelty mantis gesticulate azerbaijan bison = crag drink aphorism graphic compline cowbell quizzes cohosh acts mid defau= lt dastard adsorption gluey cabinetmake agrarian oven demise breach sympos= ia dehydrate winnetka breathtaking allusion antecedent compulsive charitab= le vaporous ascomycetes rococo siva vintner resistant bismarck veda citrus= datum testamentary kelp carlin acton shoemake psychology constructible in= terceptor mcconnell breezy idea rotary marmot corrigendum cahill octavia l= ettuce antarctica typesetter astound cacophonist petersen exchange lars fl= eet assassin braggart belvedere chickadee coven inexplicit rook ask amnesi= a giuseppe conversant spigot knoweth bluish machinelike around actinolite = drafty nasturtium wesleyan pirogue janice typesetting officialdom doughnut= teakettle stratford breadth philodendron rudder hera tremor petri adoptiv= e buckwheat perseverance congresswoman affirmation perplex atmosphere ampl= y dicotyledon norma marianne stallion leash ancillary delilah stoichiometr= y moist communicable cladophora yogurt citric barth pupil feudal axle ervi= n capsule telethon worthington clown wacky cossack austria becalm collard = atalanta amarillo ----8245470518191924303-- From eap-admin@frascone.com Thu Sep 16 06:00:11 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27690 for ; Thu, 16 Sep 2004 06:00:11 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1E787222D6; Thu, 16 Sep 2004 06:00:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5248F222D8; Thu, 16 Sep 2004 06:00:05 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E50D3222D8 for ; Thu, 16 Sep 2004 05:59:06 -0400 (EDT) Received: from brahma.intotoind.com (ip-66-80-10-146.dsl.sca.megapath.net [66.80.10.146]) by mail.frascone.com (Postfix) with ESMTP id 4E327222D6 for ; Thu, 16 Sep 2004 05:59:04 -0400 (EDT) Received: from intoto (2mc66.intotoind.com [172.16.2.66]) by brahma.intotoind.com (8.12.11/8.12.8) with SMTP id i8G9wv78027260 for ; Thu, 16 Sep 2004 15:28:57 +0530 From: "Suresh" To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <20040915033517.GB7360@jm.kir.nu> Importance: Normal X-Scanned-By: MIMEDefang 2.41 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Retransmission in EAP-Relay Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-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, 16 Sep 2004 15:29:30 +0530 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi, I have a query regarding retransmission in RFC-3579. The setup. EAP-Client (RFC-3579)--------- RADIUS Server | | Lower layer x -------------------- Lower layer x Assume that lower layer supports retransmission and RADIUS server sent an Access-Challenge packet with EAP packet and also set session timeout attribute. 1) Should the retransmission time interval of the Lower layer be over rided with the Access-Challenge session timeout attribute value for that EAP-packet? OR 2) Should Authenticator ignore the value of Access-challenge session timeout attribute and leave the retransmission functionality to the Lower layer? Thanks -Suresh _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From peppery_bury672519@tds.net Thu Sep 16 20:34:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03934; Thu, 16 Sep 2004 20:34:50 -0400 (EDT) Message-Id: <200409170034.UAA03934@ietf.org> Received: from [61.110.212.218] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C86nZ-0000ya-75; Thu, 16 Sep 2004 20:40:29 -0400 Received: from peppery_bury672519@tds.net (40.96.24.128) by xite748.sa.61.110.212.218 with QMQP; Fri, 17 Sep 2004 03:31:46 +0300 X-MIME-Autoconverted: Yes Alternate-Recipient: Allowed Auto-Forwarded: Yes Xref: machejhemjpxphsntjok Reply-To: "Gerald Whaley" From: "Gerald Whaley" To: rpsec-request@ietf.org Cc: ietf-outbound.07@ietf.org, ran@ietf.org, r-wg-admin@ietf.org, seamoby@ietf.org, rpr@ietf.org, er-wgchairs@ietf.org, eap-archive@ietf.org Subject: Guess What? Good News! Date: Fri, 17 Sep 2004 06:36:46 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--712195983677806" X-Spam-Score: 13.8 (+++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 ----712195983677806 Content-Type: text/html; charset="iso-5113-4" Content-Transfer-Encoding: 7Bit Dear Applicant,

We received your application and we're happy to let you know that it
has been approved. You now qualify for a $425,000 loan at 2.8%.

Please verify your information here:
http://www.bargainloan.info/q2/li.php?jq1=63

We look forward to hearing from you.

Regards,
Gerald Whaley
Account Manager


not interested

----712195983677806-- From LillianReffitt@erols.com Thu Sep 16 23:41:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15724 for ; Thu, 16 Sep 2004 23:41:22 -0400 (EDT) Message-Id: <200409170341.XAA15724@ietf.org> Received: from cdm-66-76-251-152.tyrd.cox-internet.com ([66.76.251.152]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C89i9-000522-3k for eap-archive@ietf.org; Thu, 16 Sep 2004 23:47:04 -0400 To: eap-archive@ietf.org Subject: hey Date: Fri, 17 Sep 2004 06:36:08 +0200 From: "Flynn Foshie" Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.9 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable The interior arrangements of the frigate corresponded to = its nautical qualities.=20











discontinue He raised his head sometimes, looked before us, and uttered a cry of recog= nition, which was responded to by a voice that came nearer and nearer. Mer= chants, common sailors, captains of vessels, skippers, both of Europe and = America, naval officers of all countries, and the Governments of several S= tates on the two continents, were deeply interested in the matter. In all = the other cases before mentioned, the Supreme Court shall have appellate j= urisdiction, both as to law and fact, with such exceptions, and under such= regulations as the Congress shall make; The trial of all crimes, except i= n cases of impeachment, shall be by jury; and such trial shall be held in = the state where the said crimes shall have been committed; but when not co= mmitted within any state, the trial shall be at such place or places as th= e Congress may by law have directed!!=20 From DominiqueOltmanns@free4life.us Fri Sep 17 08:08:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28815 for ; Fri, 17 Sep 2004 08:08:26 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C8Hcv-00084L-00 for eap-archive@ietf.org; Fri, 17 Sep 2004 08:14:10 -0400 Received: from 103.221-200-80.adsl.skynet.be ([80.200.221.103]) by mx2.foretec.com with smtp (Exim 4.24) id 1C8HXI-0004pI-PS for eap-archive@ietf.org; Fri, 17 Sep 2004 08:08:22 -0400 From: "Faith Rhines" To: eap-archive@ietf.org Subject: I need your help... Date: Fri, 17 Sep 2004 14:06:21 +0100 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: X-Spam-Score: 4.5 (++++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Each House may determine the rules of its proceedings, pu= nish its members for disorderly behavior, and, with the concurrence of two= thirds, expel a member














no msg
The Congress shall have power to declare the punishment of treason, but no= attainder of treason shall work corruption of blood, or forfeiture except= during the life of the person attainted? Fortunately this compartment did= not hold the boilers, or the fires would have been immediately extinguish= ed:=20 From wzpqubwfpv@ix.netcom.com Sat Sep 18 12:02:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28130; Sat, 18 Sep 2004 12:02:28 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C8hkg-0003M6-2J; Sat, 18 Sep 2004 12:08:29 -0400 Received: from [211.44.116.114] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1C8heo-0002l1-Mj; Sat, 18 Sep 2004 12:01:52 -0400 X-Message-Info: OAUihFUR956iiqXBzdcNb7Ddwt49+YDNSpby9qVU Received: from rqeohdccc0.bigfoot.com (86.240.232.128) by gzy31-i46.bigfoot.com with Microsoft SMTPSVC(5.0.2195.6824); Sat, 18 Sep 2004 15:58:21 -0100 Received: from Alejandronzu094y03s9d (78.184.60.164) by cyzjnvrfbfdiz67.bigfoot.com (InterMail vM.5.01.06.05 843-678-219-167-821-476456510) with SMTP id <31845631197065.IOO84.mlmmmyi73070.bigfoot.com@ostracodm000rkh51l6kkc> for ; Sat, 18 Sep 2004 09:56:21 -0700 Message-ID: <8916lt46te720$095845$y3twj87@Alejandrod964g37x06bz> From: "Do you like Rolex." To: Subject: Even you can afford a Rolex now.Come on In !!-Ietf-archive cb 23 nn Date: Sat, 18 Sep 2004 10:05:21 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--0175244179858539402" X-Spam-Score: 3.3 (+++) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 ----0175244179858539402 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Hello, We all want to wear SWISS WATCHS, they are expensive-we all know that, Now we have effordable Replica's-- Rolex --------------from $99 !! also available : =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CARTIER FRANK MULLER Jager-LeCoultre OMEGA PATEK PHILIPE =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D AND MORE http://watchescanafford.info/index.php?ref=3Dhp Italian Crafted Rolex - Complete Watch Store Reliable Service and Support Check Here For More Information http://watchescanafford.info/index.php?ref=3Dhp Regards Alejandro Cantu ----------- typewritten delineament simplicial pirouette pica datsun esprit scala bric= k mound chicano grove dagger audacious guideline feat evocation aerial mut= ant windbag finny optimum draftsman minima parrish beograd checklist great= coat juliet fortuitous stockholm halogen declaratory hazelnut afflict frag= ment posner scallop io tangential biplane ami bloodline shotbush jansenist= cerulean virtual colombo adjacent greenhouse collinear scour antonym bech= tel remission brookhaven mincemeat stirling supernatant wilshire topsy mil= dew heigh bilabial inductor dogtrot winkle epileptic simplify puckish inde= composable lenient media destiny clutch bedridden rasmussen tubule ferocit= y genii lob natchez corridor mayst thenceforth deplore demijohn plankton p= ong gauze decomposition ovenbird soviet often brazen gassy chambers mortal= bombproof aboveground ttl age lila dread drowsy acetic potentiometer oval= urgent terminology gangland sticktight quince tilt alight cottage hug irr= esolution armenian mercurial uterus analogy testamentary downright venture= apprehend argonne confucius clay trigonal cemetery restroom commandant ch= ecksumming eddie mine tompkins drophead banter curricula always seduce kid= napping emulate ameliorate prefix minor maladaptive keep musk togging rule= lorraine aerogene picayune conjugal perfidy daimler catalyst injury titan= ium texas documentation erwin doubloon effectuate bootlegging chord catapu= lt cyanic civic delicious dramatic systemization cartography kirov woodcut= brunhilde nonchalant louisa welfare prom wi tuskegee rustic baudelaire fi= fth magdalene conflagration manama nil picket dun privacy glottal ruff apo= thegm bent authoritarian hateful ardent tailgate delouse remunerate metall= urgist applause ripoff pup yiddish hearken creekside cutover fruition biom= etrika marks barberry mila plagioclase furthermost rig ursuline angeline v= incent attributive declamatory reformatory care filamentary constance curd= le sheehan dirichlet avoid mitten distinct councilwoman politicking chroni= c admitted fiction drama gleam dwindle epic cachalot block crimp fontaineb= leau bam harmful muddle goddess closeup regretful clarity pandora earthmov= ing bronzy veery econometrica crockery conversion thebes debutante micron = resist schedule humid advert ising karamazov habitat billie stefan bewilde= r troop coccidiosis valery cyclopean anthology big trustworthy mercuric ----0175244179858539402-- From YRKIGYBNBSZTY@hush.com Sat Sep 18 13:09:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01515; Sat, 18 Sep 2004 13:09:04 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C8inH-0004Zz-GY; Sat, 18 Sep 2004 13:15:04 -0400 Received: from yahoobb220041088004.bbtec.net ([220.41.88.4]) by mx2.foretec.com with smtp (Exim 4.24) id 1C8ihL-0005oZ-JT; Sat, 18 Sep 2004 13:08:32 -0400 Received: from 184.88.216.170 by 220.41.88.4; Sat, 18 Sep 2004 22:08:28 +0400 Message-ID: From: "Claudette Tomlinson" Reply-To: "Claudette Tomlinson" To: rmt-request@ietf.org Subject: S.ave up to 80% online meds Date: Sat, 18 Sep 2004 16:01:28 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--853446277701021211" X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 ----853446277701021211 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Stop wasting money on prescription drugs. Get them online for 80= % off.
V1agra, C1alis, Xanax, Val1um, Xen1cal, And many many more...Sto= p paying more than you have too! and start saving today!
Click on the f= ollowing link

http://www.onlinecheapmeds.com/?refid=3D16




MsgID: 033-139 ----853446277701021211-- From eap-admin@frascone.com Sat Sep 18 17:25: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 RAA17037 for ; Sat, 18 Sep 2004 17:25:43 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4FB6C2035C; Sat, 18 Sep 2004 17:25:11 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DB2CE20A32; Sat, 18 Sep 2004 17: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 DD75020970 for ; Sat, 18 Sep 2004 17:23:29 -0400 (EDT) Received: from brahma.intotoind.com (ip-66-80-10-146.dsl.sca.megapath.net [66.80.10.146]) by mail.frascone.com (Postfix) with ESMTP id C3F77205C9 for ; Sat, 18 Sep 2004 17:23:21 -0400 (EDT) Received: from intoto8.intotoinc.com (2mc62.intotoind.com [172.16.2.62]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id i8HClIXx003699; Fri, 17 Sep 2004 18:17:18 +0530 Message-Id: <5.1.0.14.0.20040917180017.02ace940@172.16.1.10> X-Sender: umas@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: henry.haverinen@nokia.com, jkmaline@cc.hut.fi, jsalowey@cisco.com, jari.arkko@ericsson.com From: Uma Shankar Ch Subject: RE: [eap] RE: EAP-SIM/AKA identity selection after counter-too-small Cc: eap@frascone.com In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_22264379==_.ALT" X-Scanned-By: MIMEDefang 2.41 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 17 Sep 2004 18:18:07 +0530 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) --=====================_22264379==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Henry, Excuse me, you are absolutely correct. For the Figure 9 above, where EAP exchange started with EAP-Request/Identity, one must use the EAP-Response/Identity only in MK calculation for the specified case in 4.3.5. In that sense, the statement completely holds good. For this case A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST) P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT, AT_SELECTED_VERSION) (identity = 20001@example.com = reauth_id from prev auth) A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING, *AT_NONCE_S, AT_MAC) P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, *AT_COUNTER_TOO_SMALL, *AT_COUNTER, *AT_PADDING, AT_MAC) A: EAP-Request/SIM/Start (AT_VERSION_LIST) P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION) A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA, *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC) as pointed by Jouni, according to the new change introduced by you, both 'A' and 'P' would be using the identity from the last AT_IDENTITY (ie., 20001@example.com --- in this case) for MK calculation. For this case, this example exchange would be really useful to understand things quickly in the draft. Thanks for correcting my understanding. --Uma At 02:11 PM 9/17/04 +0300, henry.haverinen@nokia.com wrote: > >Hi Uma, > >I'm not sure I understand why the last sentence (you bolded) would >become invalid. When the counter is too small, the peer should still >discard the new re-authentication identity which is received in the same >message >as the too small a counter, even with the proposed change. That is, the >peer should discard >the identity the server included in AT_NEXT_REAUTH_ID of the >EAP-Request/SIM/Re-authentication message that has too small a counter >value in AT_COUNTER. > >I think this is still valid, even when the EAP exchange consists of a >counter-too-small >re-authentication and a full authentication. In this case, when >EAP-Response/Identity >is not used, the peer and the server use the peer identity sent by the >peer to the server in >the first EAP-Response/SIM/Start. > >Maybe we should clarify section 4.3.5 so that it is clear which >AT_NEXT_REAUTH_ID >needs to be discarded? > >Best regards, >Henry >-----Original Message----- >From: ext Uma Shankar Ch [mailto:umas@intotoinc.com] >Sent: 17 September, 2004 07:28 >To: Haverinen Henry (Nokia-ES/Jyvaskyla); jkmaline@cc.hut.fi; >jsalowey@cisco.com; jari.arkko@ericsson.com >Cc: eap@frascone.com >Subject: Re: [eap] RE: EAP-SIM/AKA identity selection after counter-too-small > >>Hi Henry, >> >>Just to mention -- >> >>With the proposed change, you may would like to remove the text as it >>would become invalid, in Section 4.3.5 (Fast Re-authentication Procedure >>when Counter is Too Small) -- the last sentence in paragraph >> >> "When the peer detects that the >> counter value is not fresh, it includes the AT_COUNTER_TOO_SMALL >> attribute in EAP-Response/SIM/Re-authentication. This attribute >> doesn't contain any data but it is a request for the server to >> initiate full authentication. In this case, the peer MUST ignore the >> contents of the server's AT_NEXT_REAUTH_ID attribute." >> >>--Uma >> >> >> >>At 01:06 PM 9/15/04 +0300, henry.haverinen@nokia.com wrote: >> >>>Jouni, >>> >>>Many thanks for your detailed analysis! I'm glad to hear >>>your interoperability testing is going so well. >>> >>>I agree that the problem you pointed out exists; the drafts >>>are not clear on what identity to use in MK derivation >>>when the preceding EAP-Response/SIM/Start does not include >>>AT_IDENTITY, but when AT_IDENTITY was used in the EAP exchange >>>in an earlier EAP-Response/SIM/Start. >>> >>>You already listed the two most natural resolutions: >>> >>>1) The AT_IDENTITY from the previous EAP-Response/SIM/Start >>> >>>2) permanent identity, although it was not used in any >>>identity string during the authentication exchange. >>> >>>In my opinion, number 1) would be more in line with the >>>"spirit" of the draft -- the purpose is to protect >>>the last identity string communicated in the protocol. So I think we >>>should change section 6.4. (Key Generation) as follows: >>> >>> .. >>> Identity denotes the peer identity string without any terminating >>> null characters. It is the identity from the last AT_IDENTITY attribute >>> sent by the peer in this EAP exchange, or, if AT_IDENTITY was not used >>> during the EAP exchange, the identity from the EAP-Response/Identity >>> packet. >>> The identity string is included as-is, without any changes. >>>We should also include an example message sequence of this >>>AT_COUNTER_TOO_SMALL case. >>> >>>Any opinions? >>> >>>BR, >>>Henry >>> >>> >>> >>> > -----Original Message----- >>> > From: Jouni Malinen [mailto:jm@jm.kir.nu]On Behalf Of ext >>> > Jouni Malinen >>> > Sent: 15 September, 2004 06:35 >>> > To: Haverinen Henry (Nokia-ES/Jyvaskyla); jsalowey@cisco.com; >>> > jari.arkko@ericsson.com >>> > Cc: eap@frascone.com >>> > Subject: EAP-SIM/AKA identity selection after counter-too-small >>> > >>> > >>> > I have implemented peer part of EAP-SIM (draft 13) and EAP-AKA >>> > (draft 12) and have been trying to complete full interop tests for >>> > more or less all features in the drafts with an authentication >>> > server. Successful authentication cases seem to work fine: full >>> > authentication with both permanent id and change to pseudonym works >>> > and so does fast reauthentication. Many of the error cases, both >>> > client error and notifications, are also interoperating. However, >>> > testing AT_COUNTER_TOO_SMALL has had some problems, both due to >>> > implementation bugs and mismatches in interpretation of the draft. >>> > >>> > Bugs are now mostly fixed, but since there were mismatches in >>> > interpretation, it might be useful to consider extending the example >>> > of fast reauthentication when counter is not fresh (figure 9 of >>> > EAP-SIM draft 13) to include the full authentication part with >>> > explicitly mentioning the used identities for each message and the >>> > identity used in MK derivation. >>> > >>> > While going through the details of how the identity is selected for MK >>> > derivation I noticed a potential issue with the drafts. I'm covering >>> > EAP-SIM case here, but it looks like EAP-AKA (draft 12) has, in >>> > practice, identical construction for fast-reauth and consequently, the >>> > same problem is present (just replace SIM with AKA and subtype Start >>> > with Identity in the description). >>> > >>> > Chapter 4.6 Key Generation of EAP-SIM draft 13 gives two >>> > possible sources for Identity that is used as data for SHA1(). It can >>> > be either from the AT_IDENTITY of the previous EAP-Response/SIM/Start >>> > or from the identity included in the previous EAP-Response/Identity. >>> > However, there is one case in which neither of these is available, >>> > namely, counter-not-fresh case when EAP-Request/Identity is not used. >>> > How should the identity in MK derivation be selected for this case? >>> > >>> > The example message sequences below show more details. The first case >>> > is with EAP-Request/Identity and this can be completed based on the >>> > draft description. Using reauth_id in MK derivation, i.e., in fullauth >>> > case, is potentially confusing, but that seems to be the way to go >>> > when following the current draft (it is the identity from previous >>> > EAP-Response/Identity since previous EAP-Response/SIM/Start did not >>> > include AT_IDENTITY). >>> > >>> > The second case is from situation where EAP-Request/Identity is not >>> > used at all. Authentication starts with EAP-Request/SIM/Start with >>> > AT_ANY_ID_REQ, followed by AT_IDENTITY in EAP-Response/SIM/Start. >>> > However, counter-not-fresh case (chapter 4.3.5) specifies that server >>> > MUST NOT include any of the ID_REQ attributes in EAP-Request/SIM/Start >>> > and consequently, following EAP-Response/SIM/Start does not include >>> > AT_IDENTITY. This will trigger the case where it is not clear which >>> > identity would be used in MK derivation. >>> > >>> > >>> > With EAP-Request/Identity: >>> > >>> > A: EAP-Request/Identity >>> > P: EAP-Response/Identity (1|IMSI = permanent id) >>> > A: EAP-Request/SIM/Start (AT_VERSION_LIST) >>> > P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION) >>> > A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA, >>> > *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC) >>> > (use 1|IMSI as the Identity in MK derivation) >>> > P: EAP-Response/SIM/Challenge (AT_MAC) >>> > A: EAP-Success >>> > >>> > >>> > A: EAP-Request/Identity >>> > P: EAP-Response/Identity (20000@example.com = reauth_id from >>> > prev auth) >>> > A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, >>> > *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING, >>> > *AT_NONCE_S, AT_MAC) >>> > P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, >>> > *AT_COUNTER, >>> > *AT_PADDING, AT_MAC) >>> > A: EAP-Success >>> > >>> > >>> > A: EAP-Request/Identity >>> > P: EAP-Response/Identity (20001@example.com = reauth_id from >>> > prev auth) >>> > A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, >>> > *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING, >>> > *AT_NONCE_S, AT_MAC) >>> > P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, >>> > *AT_COUNTER_TOO_SMALL, *AT_COUNTER, *AT_PADDING, AT_MAC) >>> > A: EAP-Request/SIM/Start (AT_VERSION_LIST) >>> > P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION) >>> > A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA, >>> > *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC) >>> > (use 20001@example.com as the Identity in MK derivation, i.e., >>> > AT_NEXT_REAUTH_ID from the last successful fullauth/reauth, not >>> > AT_NEXT_REAUTH_ID of the reauth attempt with too small counter) >>> > P: EAP-Response/SIM/Challenge (AT_MAC) >>> > A: EAP-Success >>> > >>> > >>> > >>> > Without EAP-Request/Identity: >>> > >>> > A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST) >>> > P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT, >>> > AT_SELECTED_VERSION) >>> > (identity = 1|IMSI = permanent id) >>> > A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA, >>> > *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC) >>> > (use 1|IMSI as the Identity in MK derivation) >>> > P: EAP-Response/SIM/Challenge (AT_MAC) >>> > A: EAP-Success >>> > >>> > >>> > A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST) >>> > P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT, >>> > AT_SELECTED_VERSION) >>> > (identity = 20000@example.com = reauth_id from prev auth) >>> > A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, >>> > *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING, >>> > *AT_NONCE_S, AT_MAC) >>> > P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, >>> > *AT_COUNTER, >>> > *AT_PADDING, AT_MAC) >>> > A: EAP-Success >>> > >>> > >>> > A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST) >>> > P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT, >>> > AT_SELECTED_VERSION) >>> > (identity = 20001@example.com = reauth_id from prev auth) >>> > A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, >>> > *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING, >>> > *AT_NONCE_S, AT_MAC) >>> > P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, >>> > *AT_COUNTER_TOO_SMALL, *AT_COUNTER, *AT_PADDING, AT_MAC) >>> > A: EAP-Request/SIM/Start (AT_VERSION_LIST) >>> > P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION) >>> > A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA, >>> > *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC) >>> > >>> > Which Identity should be used in MK derivation now? Previous >>> > EAP-Response/SIM/Start did not have AT_IDENTITY (since AS already >>> > learned identity from the failed reauth attempt) and >>> > EAP-Response/Identity was not used. Chapter 4.6 Key Generation >>> > mentions these two options for Identity, but neither one is available >>> > here.. Should this be specified to use reauth_id from the AT_IDENTITY >>> > of the previous SIM/Start or permanent id (which should always be >>> > known by both AS and Peer at this point) or something else? >>> > >>> > >>> > -- >>> > Jouni Malinen PGP >>> > id EFC895FA >>> > >>>_______________________________________________ >>>eap mailing list >>>eap@frascone.com >>>http://mail.frascone.com/mailman/listinfo/eap --=====================_22264379==_.ALT Content-Type: text/html; charset="us-ascii" Hi Henry,

Excuse me, you are absolutely correct. For the Figure 9 above, where EAP exchange started with EAP-Request/Identity, one must use the EAP-Response/Identity only in MK calculation for the specified case in 4.3.5. In that sense, the statement completely holds good.

For this case  

A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST)
 P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT,
 AT_SELECTED_VERSION)
     (identity = 20001@example.com = reauth_id from prev auth)
 A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
     *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING,
     *AT_NONCE_S, AT_MAC)
 P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
     *AT_COUNTER_TOO_SMALL, *AT_COUNTER, *AT_PADDING, AT_MAC)
 A: EAP-Request/SIM/Start (AT_VERSION_LIST)
 P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)
 A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
     *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC)

as pointed by Jouni, according to the new change introduced by you, both 'A' and 'P' would be using the identity from the last AT_IDENTITY (ie., 20001@example.com --- in this case) for MK calculation.

For this case, this example exchange would be really useful to understand things quickly in the draft.

Thanks for correcting my understanding.

--Uma


 

At 02:11 PM 9/17/04 +0300, henry.haverinen@nokia.com wrote:

 
Hi Uma,
 
I'm not sure I understand why the last sentence (you bolded) would
become invalid. When the counter is too small, the peer should still
discard the new re-authentication identity which is received in the same message
as the too small a counter, even with the proposed change. That is, the peer should discard
the identity the server included in AT_NEXT_REAUTH_ID of the
EAP-Request/SIM/Re-authentication message that has too small a counter
value in AT_COUNTER.
 
I think this is still valid, even when the EAP exchange consists of a counter-too-small
re-authentication and a full authentication. In this case, when EAP-Response/Identity
is not used, the peer and the server use the peer identity sent by the peer to the server in
the first EAP-Response/SIM/Start.
 
Maybe we should clarify section 4.3.5 so that it is clear which AT_NEXT_REAUTH_ID
needs to be discarded?
 
Best regards,
Henry
-----Original Message-----
From: ext Uma Shankar Ch [mailto:umas@intotoinc.com]
Sent: 17 September, 2004 07:28
To: Haverinen Henry (Nokia-ES/Jyvaskyla); jkmaline@cc.hut.fi; jsalowey@cisco.com; jari.arkko@ericsson.com
Cc: eap@frascone.com
Subject: Re: [eap] RE: EAP-SIM/AKA identity selection after counter-too-small

Hi Henry,

Just to mention --

With the proposed change, you may would like to remove the text as it would become invalid, in Section 4.3.5 (Fast Re-authentication Procedure when Counter is Too Small) -- the last sentence in paragraph

   "When the peer detects that the
   counter value is not fresh, it includes the AT_COUNTER_TOO_SMALL
   attribute in EAP-Response/SIM/Re-authentication. This attribute
   doesn't contain any data but it is a request for the server to
   initiate full authentication. In this case, the peer MUST ignore the
   contents of the server's AT_NEXT_REAUTH_ID attribute."

--Uma



At 01:06 PM 9/15/04 +0300, henry.haverinen@nokia.com wrote:

Jouni,

Many thanks for your detailed analysis! I'm glad to hear
your interoperability testing is going so well.

I agree that the problem you pointed out exists; the drafts
are not clear on what identity to use in MK derivation
when the preceding EAP-Response/SIM/Start does not include
AT_IDENTITY, but when AT_IDENTITY was used in the EAP exchange
in an earlier EAP-Response/SIM/Start.

You already listed the two most natural resolutions:

1) The AT_IDENTITY from the previous EAP-Response/SIM/Start

2) permanent identity, although it was not used in any
identity string during the authentication exchange.

In my opinion, number 1) would be more in line with the
"spirit" of the draft -- the purpose is to protect
the last identity string communicated in the protocol. So I think we
should change section 6.4. (Key Generation) as follows:

   ..
   Identity denotes the peer identity string without any terminating
   null characters. It is the identity from the last AT_IDENTITY attribute
   sent by the peer in this EAP exchange, or, if AT_IDENTITY was not used
   during the EAP exchange, the identity from the EAP-Response/Identity packet.
   The identity string is included as-is, without any changes.
We should also include an example message sequence of this
AT_COUNTER_TOO_SMALL case.

Any opinions?

BR,
Henry



> -----Original Message-----
> From: Jouni Malinen [mailto:jm@jm.kir.nu]On Behalf Of ext
> Jouni Malinen
> Sent: 15 September, 2004 06:35
> To: Haverinen Henry (Nokia-ES/Jyvaskyla); jsalowey@cisco.com;
> jari.arkko@ericsson.com
> Cc: eap@frascone.com
> Subject: EAP-SIM/AKA identity selection after counter-too-small
>
>
> I have implemented peer part of EAP-SIM (draft 13) and EAP-AKA
> (draft 12) and have been trying to complete full interop tests for
> more or less all features in the drafts with an authentication
> server. Successful authentication cases seem to work fine: full
> authentication with both permanent id and change to pseudonym works
> and so does fast reauthentication. Many of the error cases, both
> client error and notifications, are also interoperating. However,
> testing AT_COUNTER_TOO_SMALL has had some problems, both due to
> implementation bugs and mismatches in interpretation of the draft.
>
> Bugs are now mostly fixed, but since there were mismatches in
> interpretation, it might be useful to consider extending the example
> of fast reauthentication when counter is not fresh (figure 9 of
> EAP-SIM draft 13) to include the full authentication part with
> explicitly mentioning the used identities for each message and the
> identity used in MK derivation.
>
> While going through the details of how the identity is selected for MK
> derivation I noticed a potential issue with the drafts. I'm covering
> EAP-SIM case here, but it looks like EAP-AKA (draft 12) has, in
> practice, identical construction for fast-reauth and consequently, the
> same problem is present (just replace SIM with AKA and subtype Start
> with Identity in the description).
>
> Chapter 4.6 Key Generation of EAP-SIM draft 13 gives two
> possible sources for Identity that is used as data for SHA1(). It can
> be either from the AT_IDENTITY of the previous EAP-Response/SIM/Start
> or from the identity included in the previous EAP-Response/Identity.
> However, there is one case in which neither of these is available,
> namely, counter-not-fresh case when EAP-Request/Identity is not used.
> How should the identity in MK derivation be selected for this case?
>
> The example message sequences below show more details. The first case
> is with EAP-Request/Identity and this can be completed based on the
> draft description. Using reauth_id in MK derivation, i.e., in fullauth
> case, is potentially confusing, but that seems to be the way to go
> when following the current draft (it is the identity from previous
> EAP-Response/Identity since previous EAP-Response/SIM/Start did not
> include AT_IDENTITY).
>
> The second case is from situation where EAP-Request/Identity is not
> used at all. Authentication starts with EAP-Request/SIM/Start with
> AT_ANY_ID_REQ, followed by AT_IDENTITY in EAP-Response/SIM/Start.
> However, counter-not-fresh case (chapter 4.3.5) specifies that server
> MUST NOT include any of the ID_REQ attributes in EAP-Request/SIM/Start
> and consequently, following EAP-Response/SIM/Start does not include
> AT_IDENTITY. This will trigger the case where it is not clear which
> identity would be used in MK derivation.
>
>
> With EAP-Request/Identity:
>
> A: EAP-Request/Identity
> P: EAP-Response/Identity (1|IMSI = permanent id)
> A: EAP-Request/SIM/Start (AT_VERSION_LIST)
> P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)
> A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
>     *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC)
>    (use 1|IMSI as the Identity in MK derivation)
> P: EAP-Response/SIM/Challenge (AT_MAC)
> A: EAP-Success
>
>
> A: EAP-Request/Identity
> P: EAP-Response/Identity (20000@example.com = reauth_id from
> prev auth)
> A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
>     *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING,
>     *AT_NONCE_S, AT_MAC)
> P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> *AT_COUNTER,
>     *AT_PADDING, AT_MAC)
> A: EAP-Success
>
>
> A: EAP-Request/Identity
> P: EAP-Response/Identity (20001@example.com = reauth_id from
> prev auth)
> A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
>     *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING,
>     *AT_NONCE_S, AT_MAC)
> P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
>     *AT_COUNTER_TOO_SMALL, *AT_COUNTER, *AT_PADDING, AT_MAC)
> A: EAP-Request/SIM/Start (AT_VERSION_LIST)
> P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)
> A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
>     *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC)
>    (use 20001@example.com as the Identity in MK derivation, i.e.,
>    AT_NEXT_REAUTH_ID from the last successful fullauth/reauth, not
>    AT_NEXT_REAUTH_ID of the reauth attempt with too small counter)
> P: EAP-Response/SIM/Challenge (AT_MAC)
> A: EAP-Success
>
>
>
> Without EAP-Request/Identity:
>
> A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST)
> P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT,
> AT_SELECTED_VERSION)
>     (identity = 1|IMSI = permanent id)
> A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
>     *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC)
>    (use 1|IMSI as the Identity in MK derivation)
> P: EAP-Response/SIM/Challenge (AT_MAC)
> A: EAP-Success
>
>
> A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST)
> P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT,
> AT_SELECTED_VERSION)
>     (identity = 20000@example.com = reauth_id from prev auth)
> A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
>     *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING,
>     *AT_NONCE_S, AT_MAC)
> P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> *AT_COUNTER,
>     *AT_PADDING, AT_MAC)
> A: EAP-Success
>
>
> A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST)
> P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT,
> AT_SELECTED_VERSION)
>     (identity = 20001@example.com = reauth_id from prev auth)
> A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
>     *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING,
>     *AT_NONCE_S, AT_MAC)
> P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
>     *AT_COUNTER_TOO_SMALL, *AT_COUNTER, *AT_PADDING, AT_MAC)
> A: EAP-Request/SIM/Start (AT_VERSION_LIST)
> P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)
> A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
>     *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC)
>
> Which Identity should be used in MK derivation now? Previous
> EAP-Response/SIM/Start did not have AT_IDENTITY (since AS already
> learned identity from the failed reauth attempt) and
> EAP-Response/Identity was not used. Chapter 4.6 Key Generation
> mentions these two options for Identity, but neither one is available
> here.. Should this be specified to use reauth_id from the AT_IDENTITY
> of the previous SIM/Start or permanent id (which should always be
> known by both AS and Peer at this point) or something else?
>
>
> --
> Jouni Malinen                                            PGP
> id EFC895FA
>
_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap
--=====================_22264379==_.ALT-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat Sep 18 17:29:23 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17198 for ; Sat, 18 Sep 2004 17:29:22 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EC0E921195; Sat, 18 Sep 2004 17:27:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BDE74211C5; Sat, 18 Sep 2004 17: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 ECF3C205C9 for ; Sat, 18 Sep 2004 17:23:32 -0400 (EDT) Received: from brahma.intotoind.com (ip-66-80-10-146.dsl.sca.megapath.net [66.80.10.146]) by mail.frascone.com (Postfix) with ESMTP id 1F4DB2067C for ; Sat, 18 Sep 2004 17:23:29 -0400 (EDT) Received: from intoto (2mc66.intotoind.com [172.16.2.66]) by brahma.intotoind.com (8.12.11/8.12.8) with SMTP id i8H6lL9u007653; Fri, 17 Sep 2004 12:17:21 +0530 From: "Suresh" To: "Srinivasa Rao Addepalli" , Subject: RE: [eap] Retransmission in EAP-Relay Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <002901c49c22$9f0df650$6f05010a@SriniSony> Importance: High X-Scanned-By: MIMEDefang 2.41 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 17 Sep 2004 12:17:54 +0530 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit But the RFC-3579 section 2.3 Retransmission says It may be necessary to adjust retransmission strategies and authentication timeouts in certain cases. For example, when a token card is used additional time may be required to allow the user to find the card and enter the token. Since the NAS will typically not have knowledge of the required parameters, these need to be provided by the RADIUS server. This can be accomplished by inclusion of Session-Timeout attribute within the Access-Challenge packet. -----Original Message----- From: Srinivasa Rao Addepalli [mailto:srao@intoto.com] Sent: Friday, September 17, 2004 12:53 AM To: Suresh; eap@frascone.com Subject: Re: [eap] Retransmission in EAP-Relay I suggest option 2. I don't think session timeout is meant for this anyway. Srini Intoto Inc. www.intoto.com ----- Original Message ----- From: "Suresh" To: Sent: Thursday, September 16, 2004 2:59 AM Subject: [eap] Retransmission in EAP-Relay > Hi, > I have a query regarding retransmission in RFC-3579. > > > The setup. > > EAP-Client (RFC-3579)--------- RADIUS Server > | | > Lower layer x -------------------- Lower layer x > > Assume that lower layer supports retransmission and RADIUS server sent > an Access-Challenge packet with EAP packet and also set session timeout > attribute. > > 1) Should the retransmission time interval of the Lower layer > be over rided with the Access-Challenge session timeout attribute value > for that EAP-packet? > > OR > > 2) Should Authenticator ignore the value of Access-challenge session timeout > attribute and leave the retransmission functionality to the Lower layer? > > > Thanks > -Suresh > > > _______________________________________________ > 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 Sep 18 17:32: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 RAA17323 for ; Sat, 18 Sep 2004 17:32:38 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 956D620BCC; Sat, 18 Sep 2004 17:28:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9BCBA2056C; Sat, 18 Sep 2004 17:28:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4003D207FC for ; Sat, 18 Sep 2004 17:23:38 -0400 (EDT) Received: from brahma.intotoind.com (ip-66-80-10-146.dsl.sca.megapath.net [66.80.10.146]) by mail.frascone.com (Postfix) with ESMTP id 830DC20538 for ; Sat, 18 Sep 2004 17:23:32 -0400 (EDT) Received: from intoto8.intotoinc.com (2mc62.intotoind.com [172.16.2.62]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id i8H4RHY3012736; Fri, 17 Sep 2004 09:57:17 +0530 Message-Id: <5.1.0.14.0.20040917095649.02ac6020@172.16.1.10> X-Sender: umas@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: henry.haverinen@nokia.com, jkmaline@cc.hut.fi, jsalowey@cisco.com, jari.arkko@ericsson.com From: Uma Shankar Ch Subject: Re: [eap] RE: EAP-SIM/AKA identity selection after counter-too-small Cc: eap@frascone.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_56406744==_.ALT" X-Scanned-By: MIMEDefang 2.41 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 17 Sep 2004 09:58:03 +0530 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) --=====================_56406744==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed >Hi Henry, > >Just to mention -- > >With the proposed change, you may would like to remove the text as it >would become invalid, in Section 4.3.5 (Fast Re-authentication Procedure >when Counter is Too Small) -- the last sentence in paragraph > > "When the peer detects that the > counter value is not fresh, it includes the AT_COUNTER_TOO_SMALL > attribute in EAP-Response/SIM/Re-authentication. This attribute > doesn't contain any data but it is a request for the server to > initiate full authentication. In this case, the peer MUST ignore the > contents of the server's AT_NEXT_REAUTH_ID attribute." > >--Uma > > >At 01:06 PM 9/15/04 +0300, henry.haverinen@nokia.com wrote: > >>Jouni, >> >>Many thanks for your detailed analysis! I'm glad to hear >>your interoperability testing is going so well. >> >>I agree that the problem you pointed out exists; the drafts >>are not clear on what identity to use in MK derivation >>when the preceding EAP-Response/SIM/Start does not include >>AT_IDENTITY, but when AT_IDENTITY was used in the EAP exchange >>in an earlier EAP-Response/SIM/Start. >> >>You already listed the two most natural resolutions: >> >>1) The AT_IDENTITY from the previous EAP-Response/SIM/Start >> >>2) permanent identity, although it was not used in any >>identity string during the authentication exchange. >> >>In my opinion, number 1) would be more in line with the >>"spirit" of the draft -- the purpose is to protect >>the last identity string communicated in the protocol. So I think we >>should change section 6.4. (Key Generation) as follows: >> >> .. >> Identity denotes the peer identity string without any terminating >> null characters. It is the identity from the last AT_IDENTITY attribute >> sent by the peer in this EAP exchange, or, if AT_IDENTITY was not used >> during the EAP exchange, the identity from the EAP-Response/Identity >> packet. >> The identity string is included as-is, without any changes. >> >>We should also include an example message sequence of this >>AT_COUNTER_TOO_SMALL case. >> >>Any opinions? >> >>BR, >>Henry >> >> >> > -----Original Message----- >> > From: Jouni Malinen [mailto:jm@jm.kir.nu]On Behalf Of ext >> > Jouni Malinen >> > Sent: 15 September, 2004 06:35 >> > To: Haverinen Henry (Nokia-ES/Jyvaskyla); jsalowey@cisco.com; >> > jari.arkko@ericsson.com >> > Cc: eap@frascone.com >> > Subject: EAP-SIM/AKA identity selection after counter-too-small >> > >> > >> > I have implemented peer part of EAP-SIM (draft 13) and EAP-AKA >> > (draft 12) and have been trying to complete full interop tests for >> > more or less all features in the drafts with an authentication >> > server. Successful authentication cases seem to work fine: full >> > authentication with both permanent id and change to pseudonym works >> > and so does fast reauthentication. Many of the error cases, both >> > client error and notifications, are also interoperating. However, >> > testing AT_COUNTER_TOO_SMALL has had some problems, both due to >> > implementation bugs and mismatches in interpretation of the draft. >> > >> > Bugs are now mostly fixed, but since there were mismatches in >> > interpretation, it might be useful to consider extending the example >> > of fast reauthentication when counter is not fresh (figure 9 of >> > EAP-SIM draft 13) to include the full authentication part with >> > explicitly mentioning the used identities for each message and the >> > identity used in MK derivation. >> > >> > While going through the details of how the identity is selected for MK >> > derivation I noticed a potential issue with the drafts. I'm covering >> > EAP-SIM case here, but it looks like EAP-AKA (draft 12) has, in >> > practice, identical construction for fast-reauth and consequently, the >> > same problem is present (just replace SIM with AKA and subtype Start >> > with Identity in the description). >> > >> > Chapter 4.6 Key Generation of EAP-SIM draft 13 gives two >> > possible sources for Identity that is used as data for SHA1(). It can >> > be either from the AT_IDENTITY of the previous EAP-Response/SIM/Start >> > or from the identity included in the previous EAP-Response/Identity. >> > However, there is one case in which neither of these is available, >> > namely, counter-not-fresh case when EAP-Request/Identity is not used. >> > How should the identity in MK derivation be selected for this case? >> > >> > The example message sequences below show more details. The first case >> > is with EAP-Request/Identity and this can be completed based on the >> > draft description. Using reauth_id in MK derivation, i.e., in fullauth >> > case, is potentially confusing, but that seems to be the way to go >> > when following the current draft (it is the identity from previous >> > EAP-Response/Identity since previous EAP-Response/SIM/Start did not >> > include AT_IDENTITY). >> > >> > The second case is from situation where EAP-Request/Identity is not >> > used at all. Authentication starts with EAP-Request/SIM/Start with >> > AT_ANY_ID_REQ, followed by AT_IDENTITY in EAP-Response/SIM/Start. >> > However, counter-not-fresh case (chapter 4.3.5) specifies that server >> > MUST NOT include any of the ID_REQ attributes in EAP-Request/SIM/Start >> > and consequently, following EAP-Response/SIM/Start does not include >> > AT_IDENTITY. This will trigger the case where it is not clear which >> > identity would be used in MK derivation. >> > >> > >> > With EAP-Request/Identity: >> > >> > A: EAP-Request/Identity >> > P: EAP-Response/Identity (1|IMSI = permanent id) >> > A: EAP-Request/SIM/Start (AT_VERSION_LIST) >> > P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION) >> > A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA, >> > *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC) >> > (use 1|IMSI as the Identity in MK derivation) >> > P: EAP-Response/SIM/Challenge (AT_MAC) >> > A: EAP-Success >> > >> > >> > A: EAP-Request/Identity >> > P: EAP-Response/Identity (20000@example.com = reauth_id from >> > prev auth) >> > A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, >> > *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING, >> > *AT_NONCE_S, AT_MAC) >> > P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, >> > *AT_COUNTER, >> > *AT_PADDING, AT_MAC) >> > A: EAP-Success >> > >> > >> > A: EAP-Request/Identity >> > P: EAP-Response/Identity (20001@example.com = reauth_id from >> > prev auth) >> > A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, >> > *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING, >> > *AT_NONCE_S, AT_MAC) >> > P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, >> > *AT_COUNTER_TOO_SMALL, *AT_COUNTER, *AT_PADDING, AT_MAC) >> > A: EAP-Request/SIM/Start (AT_VERSION_LIST) >> > P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION) >> > A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA, >> > *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC) >> > (use 20001@example.com as the Identity in MK derivation, i.e., >> > AT_NEXT_REAUTH_ID from the last successful fullauth/reauth, not >> > AT_NEXT_REAUTH_ID of the reauth attempt with too small counter) >> > P: EAP-Response/SIM/Challenge (AT_MAC) >> > A: EAP-Success >> > >> > >> > >> > Without EAP-Request/Identity: >> > >> > A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST) >> > P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT, >> > AT_SELECTED_VERSION) >> > (identity = 1|IMSI = permanent id) >> > A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA, >> > *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC) >> > (use 1|IMSI as the Identity in MK derivation) >> > P: EAP-Response/SIM/Challenge (AT_MAC) >> > A: EAP-Success >> > >> > >> > A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST) >> > P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT, >> > AT_SELECTED_VERSION) >> > (identity = 20000@example.com = reauth_id from prev auth) >> > A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, >> > *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING, >> > *AT_NONCE_S, AT_MAC) >> > P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, >> > *AT_COUNTER, >> > *AT_PADDING, AT_MAC) >> > A: EAP-Success >> > >> > >> > A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST) >> > P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT, >> > AT_SELECTED_VERSION) >> > (identity = 20001@example.com = reauth_id from prev auth) >> > A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, >> > *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING, >> > *AT_NONCE_S, AT_MAC) >> > P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, >> > *AT_COUNTER_TOO_SMALL, *AT_COUNTER, *AT_PADDING, AT_MAC) >> > A: EAP-Request/SIM/Start (AT_VERSION_LIST) >> > P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION) >> > A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA, >> > *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC) >> > >> > Which Identity should be used in MK derivation now? Previous >> > EAP-Response/SIM/Start did not have AT_IDENTITY (since AS already >> > learned identity from the failed reauth attempt) and >> > EAP-Response/Identity was not used. Chapter 4.6 Key Generation >> > mentions these two options for Identity, but neither one is available >> > here.. Should this be specified to use reauth_id from the AT_IDENTITY >> > of the previous SIM/Start or permanent id (which should always be >> > known by both AS and Peer at this point) or something else? >> > >> > >> > -- >> > Jouni Malinen PGP >> > id EFC895FA >> > >>_______________________________________________ >>eap mailing list >>eap@frascone.com >>http://mail.frascone.com/mailman/listinfo/eap --=====================_56406744==_.ALT Content-Type: text/html; charset="us-ascii"
Hi Henry,

Just to mention --

With the proposed change, you may would like to remove the text as it would become invalid, in Section 4.3.5 (Fast Re-authentication Procedure when Counter is Too Small) -- the last sentence in paragraph

   "When the peer detects that the
   counter value is not fresh, it includes the AT_COUNTER_TOO_SMALL
   attribute in EAP-Response/SIM/Re-authentication. This attribute
   doesn't contain any data but it is a request for the server to
   initiate full authentication. In this case, the peer MUST ignore the
   contents of the server's AT_NEXT_REAUTH_ID attribute."

--Uma


At 01:06 PM 9/15/04 +0300, henry.haverinen@nokia.com wrote:

Jouni,

Many thanks for your detailed analysis! I'm glad to hear
your interoperability testing is going so well.

I agree that the problem you pointed out exists; the drafts
are not clear on what identity to use in MK derivation
when the preceding EAP-Response/SIM/Start does not include
AT_IDENTITY, but when AT_IDENTITY was used in the EAP exchange
in an earlier EAP-Response/SIM/Start.

You already listed the two most natural resolutions:

1) The AT_IDENTITY from the previous EAP-Response/SIM/Start

2) permanent identity, although it was not used in any
identity string during the authentication exchange.

In my opinion, number 1) would be more in line with the
"spirit" of the draft -- the purpose is to protect
the last identity string communicated in the protocol. So I think we
should change section 6.4. (Key Generation) as follows:

   ..
   Identity denotes the peer identity string without any terminating
   null characters. It is the identity from the last AT_IDENTITY attribute
   sent by the peer in this EAP exchange, or, if AT_IDENTITY was not used
   during the EAP exchange, the identity from the EAP-Response/Identity packet.
   The identity string is included as-is, without any changes.

We should also include an example message sequence of this
AT_COUNTER_TOO_SMALL case.

Any opinions?

BR,
Henry


> -----Original Message-----
> From: Jouni Malinen [mailto:jm@jm.kir.nu]On Behalf Of ext
> Jouni Malinen
> Sent: 15 September, 2004 06:35
> To: Haverinen Henry (Nokia-ES/Jyvaskyla); jsalowey@cisco.com;
> jari.arkko@ericsson.com
> Cc: eap@frascone.com
> Subject: EAP-SIM/AKA identity selection after counter-too-small
>
>
> I have implemented peer part of EAP-SIM (draft 13) and EAP-AKA
> (draft 12) and have been trying to complete full interop tests for
> more or less all features in the drafts with an authentication
> server. Successful authentication cases seem to work fine: full
> authentication with both permanent id and change to pseudonym works
> and so does fast reauthentication. Many of the error cases, both
> client error and notifications, are also interoperating. However,
> testing AT_COUNTER_TOO_SMALL has had some problems, both due to
> implementation bugs and mismatches in interpretation of the draft.
>
> Bugs are now mostly fixed, but since there were mismatches in
> interpretation, it might be useful to consider extending the example
> of fast reauthentication when counter is not fresh (figure 9 of
> EAP-SIM draft 13) to include the full authentication part with
> explicitly mentioning the used identities for each message and the
> identity used in MK derivation.
>
> While going through the details of how the identity is selected for MK
> derivation I noticed a potential issue with the drafts. I'm covering
> EAP-SIM case here, but it looks like EAP-AKA (draft 12) has, in
> practice, identical construction for fast-reauth and consequently, the
> same problem is present (just replace SIM with AKA and subtype Start
> with Identity in the description).
>
> Chapter 4.6 Key Generation of EAP-SIM draft 13 gives two
> possible sources for Identity that is used as data for SHA1(). It can
> be either from the AT_IDENTITY of the previous EAP-Response/SIM/Start
> or from the identity included in the previous EAP-Response/Identity.
> However, there is one case in which neither of these is available,
> namely, counter-not-fresh case when EAP-Request/Identity is not used.
> How should the identity in MK derivation be selected for this case?
>
> The example message sequences below show more details. The first case
> is with EAP-Request/Identity and this can be completed based on the
> draft description. Using reauth_id in MK derivation, i.e., in fullauth
> case, is potentially confusing, but that seems to be the way to go
> when following the current draft (it is the identity from previous
> EAP-Response/Identity since previous EAP-Response/SIM/Start did not
> include AT_IDENTITY).
>
> The second case is from situation where EAP-Request/Identity is not
> used at all. Authentication starts with EAP-Request/SIM/Start with
> AT_ANY_ID_REQ, followed by AT_IDENTITY in EAP-Response/SIM/Start.
> However, counter-not-fresh case (chapter 4.3.5) specifies that server
> MUST NOT include any of the ID_REQ attributes in EAP-Request/SIM/Start
> and consequently, following EAP-Response/SIM/Start does not include
> AT_IDENTITY. This will trigger the case where it is not clear which
> identity would be used in MK derivation.
>
>
> With EAP-Request/Identity:
>
> A: EAP-Request/Identity
> P: EAP-Response/Identity (1|IMSI = permanent id)
> A: EAP-Request/SIM/Start (AT_VERSION_LIST)
> P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)
> A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
>     *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC)
>    (use 1|IMSI as the Identity in MK derivation)
> P: EAP-Response/SIM/Challenge (AT_MAC)
> A: EAP-Success
>
>
> A: EAP-Request/Identity
> P: EAP-Response/Identity (20000@example.com = reauth_id from
> prev auth)
> A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
>     *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING,
>     *AT_NONCE_S, AT_MAC)
> P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> *AT_COUNTER,
>     *AT_PADDING, AT_MAC)
> A: EAP-Success
>
>
> A: EAP-Request/Identity
> P: EAP-Response/Identity (20001@example.com = reauth_id from
> prev auth)
> A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
>     *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING,
>     *AT_NONCE_S, AT_MAC)
> P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
>     *AT_COUNTER_TOO_SMALL, *AT_COUNTER, *AT_PADDING, AT_MAC)
> A: EAP-Request/SIM/Start (AT_VERSION_LIST)
> P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)
> A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
>     *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC)
>    (use 20001@example.com as the Identity in MK derivation, i.e.,
>    AT_NEXT_REAUTH_ID from the last successful fullauth/reauth, not
>    AT_NEXT_REAUTH_ID of the reauth attempt with too small counter)
> P: EAP-Response/SIM/Challenge (AT_MAC)
> A: EAP-Success
>
>
>
> Without EAP-Request/Identity:
>
> A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST)
> P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT,
> AT_SELECTED_VERSION)
>     (identity = 1|IMSI = permanent id)
> A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
>     *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC)
>    (use 1|IMSI as the Identity in MK derivation)
> P: EAP-Response/SIM/Challenge (AT_MAC)
> A: EAP-Success
>
>
> A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST)
> P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT,
> AT_SELECTED_VERSION)
>     (identity = 20000@example.com = reauth_id from prev auth)
> A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
>     *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING,
>     *AT_NONCE_S, AT_MAC)
> P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> *AT_COUNTER,
>     *AT_PADDING, AT_MAC)
> A: EAP-Success
>
>
> A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST)
> P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT,
> AT_SELECTED_VERSION)
>     (identity = 20001@example.com = reauth_id from prev auth)
> A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
>     *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING,
>     *AT_NONCE_S, AT_MAC)
> P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
>     *AT_COUNTER_TOO_SMALL, *AT_COUNTER, *AT_PADDING, AT_MAC)
> A: EAP-Request/SIM/Start (AT_VERSION_LIST)
> P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)
> A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
>     *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC)
>
> Which Identity should be used in MK derivation now? Previous
> EAP-Response/SIM/Start did not have AT_IDENTITY (since AS already
> learned identity from the failed reauth attempt) and
> EAP-Response/Identity was not used. Chapter 4.6 Key Generation
> mentions these two options for Identity, but neither one is available
> here.. Should this be specified to use reauth_id from the AT_IDENTITY
> of the previous SIM/Start or permanent id (which should always be
> known by both AS and Peer at this point) or something else?
>
>
> --
> Jouni Malinen                                            PGP
> id EFC895FA
>
_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap
--=====================_56406744==_.ALT-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat Sep 18 17:36: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 RAA17512 for ; Sat, 18 Sep 2004 17:36:30 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BB87520FFD; Sat, 18 Sep 2004 17:30:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CFC2020F47; Sat, 18 Sep 2004 17: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 2DC8D20A6C for ; Sat, 18 Sep 2004 17:23:43 -0400 (EDT) Received: from brahma.intotoind.com (ip-66-80-10-146.dsl.sca.megapath.net [66.80.10.146]) by mail.frascone.com (Postfix) with ESMTP id D6915207BA for ; Sat, 18 Sep 2004 17:23:37 -0400 (EDT) Received: from intoto8.intotoinc.com (2mc62.intotoind.com [172.16.2.62]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id i8GEthcm009642; Thu, 16 Sep 2004 20:25:43 +0530 Message-Id: <5.1.0.14.0.20040916202211.02ab6df0@172.16.1.10> X-Sender: umas@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: , , , From: Uma Shankar Ch Subject: Re: [eap] RE: EAP-SIM/AKA identity selection after counter-too-small Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_7704504==_.ALT" X-Scanned-By: MIMEDefang 2.41 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 16 Sep 2004 20:26:28 +0530 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) --=====================_7704504==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Henry, Just to mention -- With the proposed change, you may would like to remove the text as it would become invalid, in Section 4.3.5 (Fast Re-authentication Procedure when Counter is Too Small) -- the last sentence in paragraph "When the peer detects that the counter value is not fresh, it includes the AT_COUNTER_TOO_SMALL attribute in EAP-Response/SIM/Re-authentication. This attribute doesn't contain any data but it is a request for the server to initiate full authentication. In this case, the peer MUST ignore the contents of the server's AT_NEXT_REAUTH_ID attribute." --Uma At 01:06 PM 9/15/04 +0300, henry.haverinen@nokia.com wrote: >Jouni, > >Many thanks for your detailed analysis! I'm glad to hear >your interoperability testing is going so well. > >I agree that the problem you pointed out exists; the drafts >are not clear on what identity to use in MK derivation >when the preceding EAP-Response/SIM/Start does not include >AT_IDENTITY, but when AT_IDENTITY was used in the EAP exchange >in an earlier EAP-Response/SIM/Start. > >You already listed the two most natural resolutions: > >1) The AT_IDENTITY from the previous EAP-Response/SIM/Start > >2) permanent identity, although it was not used in any >identity string during the authentication exchange. > >In my opinion, number 1) would be more in line with the >"spirit" of the draft -- the purpose is to protect >the last identity string communicated in the protocol. So I think we >should change section 6.4. (Key Generation) as follows: > > .. > Identity denotes the peer identity string without any terminating > null characters. It is the identity from the last AT_IDENTITY attribute > sent by the peer in this EAP exchange, or, if AT_IDENTITY was not used > during the EAP exchange, the identity from the EAP-Response/Identity > packet. > The identity string is included as-is, without any changes. > >We should also include an example message sequence of this >AT_COUNTER_TOO_SMALL case. > >Any opinions? > >BR, >Henry > > > > -----Original Message----- > > From: Jouni Malinen [mailto:jm@jm.kir.nu]On Behalf Of ext > > Jouni Malinen > > Sent: 15 September, 2004 06:35 > > To: Haverinen Henry (Nokia-ES/Jyvaskyla); jsalowey@cisco.com; > > jari.arkko@ericsson.com > > Cc: eap@frascone.com > > Subject: EAP-SIM/AKA identity selection after counter-too-small > > > > > > I have implemented peer part of EAP-SIM (draft 13) and EAP-AKA > > (draft 12) and have been trying to complete full interop tests for > > more or less all features in the drafts with an authentication > > server. Successful authentication cases seem to work fine: full > > authentication with both permanent id and change to pseudonym works > > and so does fast reauthentication. Many of the error cases, both > > client error and notifications, are also interoperating. However, > > testing AT_COUNTER_TOO_SMALL has had some problems, both due to > > implementation bugs and mismatches in interpretation of the draft. > > > > Bugs are now mostly fixed, but since there were mismatches in > > interpretation, it might be useful to consider extending the example > > of fast reauthentication when counter is not fresh (figure 9 of > > EAP-SIM draft 13) to include the full authentication part with > > explicitly mentioning the used identities for each message and the > > identity used in MK derivation. > > > > While going through the details of how the identity is selected for MK > > derivation I noticed a potential issue with the drafts. I'm covering > > EAP-SIM case here, but it looks like EAP-AKA (draft 12) has, in > > practice, identical construction for fast-reauth and consequently, the > > same problem is present (just replace SIM with AKA and subtype Start > > with Identity in the description). > > > > Chapter 4.6 Key Generation of EAP-SIM draft 13 gives two > > possible sources for Identity that is used as data for SHA1(). It can > > be either from the AT_IDENTITY of the previous EAP-Response/SIM/Start > > or from the identity included in the previous EAP-Response/Identity. > > However, there is one case in which neither of these is available, > > namely, counter-not-fresh case when EAP-Request/Identity is not used. > > How should the identity in MK derivation be selected for this case? > > > > The example message sequences below show more details. The first case > > is with EAP-Request/Identity and this can be completed based on the > > draft description. Using reauth_id in MK derivation, i.e., in fullauth > > case, is potentially confusing, but that seems to be the way to go > > when following the current draft (it is the identity from previous > > EAP-Response/Identity since previous EAP-Response/SIM/Start did not > > include AT_IDENTITY). > > > > The second case is from situation where EAP-Request/Identity is not > > used at all. Authentication starts with EAP-Request/SIM/Start with > > AT_ANY_ID_REQ, followed by AT_IDENTITY in EAP-Response/SIM/Start. > > However, counter-not-fresh case (chapter 4.3.5) specifies that server > > MUST NOT include any of the ID_REQ attributes in EAP-Request/SIM/Start > > and consequently, following EAP-Response/SIM/Start does not include > > AT_IDENTITY. This will trigger the case where it is not clear which > > identity would be used in MK derivation. > > > > > > With EAP-Request/Identity: > > > > A: EAP-Request/Identity > > P: EAP-Response/Identity (1|IMSI = permanent id) > > A: EAP-Request/SIM/Start (AT_VERSION_LIST) > > P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION) > > A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA, > > *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC) > > (use 1|IMSI as the Identity in MK derivation) > > P: EAP-Response/SIM/Challenge (AT_MAC) > > A: EAP-Success > > > > > > A: EAP-Request/Identity > > P: EAP-Response/Identity (20000@example.com = reauth_id from > > prev auth) > > A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, > > *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING, > > *AT_NONCE_S, AT_MAC) > > P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, > > *AT_COUNTER, > > *AT_PADDING, AT_MAC) > > A: EAP-Success > > > > > > A: EAP-Request/Identity > > P: EAP-Response/Identity (20001@example.com = reauth_id from > > prev auth) > > A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, > > *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING, > > *AT_NONCE_S, AT_MAC) > > P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, > > *AT_COUNTER_TOO_SMALL, *AT_COUNTER, *AT_PADDING, AT_MAC) > > A: EAP-Request/SIM/Start (AT_VERSION_LIST) > > P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION) > > A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA, > > *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC) > > (use 20001@example.com as the Identity in MK derivation, i.e., > > AT_NEXT_REAUTH_ID from the last successful fullauth/reauth, not > > AT_NEXT_REAUTH_ID of the reauth attempt with too small counter) > > P: EAP-Response/SIM/Challenge (AT_MAC) > > A: EAP-Success > > > > > > > > Without EAP-Request/Identity: > > > > A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST) > > P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT, > > AT_SELECTED_VERSION) > > (identity = 1|IMSI = permanent id) > > A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA, > > *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC) > > (use 1|IMSI as the Identity in MK derivation) > > P: EAP-Response/SIM/Challenge (AT_MAC) > > A: EAP-Success > > > > > > A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST) > > P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT, > > AT_SELECTED_VERSION) > > (identity = 20000@example.com = reauth_id from prev auth) > > A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, > > *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING, > > *AT_NONCE_S, AT_MAC) > > P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, > > *AT_COUNTER, > > *AT_PADDING, AT_MAC) > > A: EAP-Success > > > > > > A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST) > > P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT, > > AT_SELECTED_VERSION) > > (identity = 20001@example.com = reauth_id from prev auth) > > A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, > > *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING, > > *AT_NONCE_S, AT_MAC) > > P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, > > *AT_COUNTER_TOO_SMALL, *AT_COUNTER, *AT_PADDING, AT_MAC) > > A: EAP-Request/SIM/Start (AT_VERSION_LIST) > > P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION) > > A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA, > > *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC) > > > > Which Identity should be used in MK derivation now? Previous > > EAP-Response/SIM/Start did not have AT_IDENTITY (since AS already > > learned identity from the failed reauth attempt) and > > EAP-Response/Identity was not used. Chapter 4.6 Key Generation > > mentions these two options for Identity, but neither one is available > > here.. Should this be specified to use reauth_id from the AT_IDENTITY > > of the previous SIM/Start or permanent id (which should always be > > known by both AS and Peer at this point) or something else? > > > > > > -- > > Jouni Malinen PGP > > id EFC895FA > > >_______________________________________________ >eap mailing list >eap@frascone.com >http://mail.frascone.com/mailman/listinfo/eap --=====================_7704504==_.ALT Content-Type: text/html; charset="us-ascii" Hi Henry,

Just to mention --

With the proposed change, you may would like to remove the text as it would become invalid, in Section 4.3.5 (Fast Re-authentication Procedure when Counter is Too Small) -- the last sentence in paragraph

   "When the peer detects that the
   counter value is not fresh, it includes the AT_COUNTER_TOO_SMALL
   attribute in EAP-Response/SIM/Re-authentication. This attribute
   doesn't contain any data but it is a request for the server to
   initiate full authentication. In this case, the peer MUST ignore the
   contents of the server's AT_NEXT_REAUTH_ID attribute."

--Uma


At 01:06 PM 9/15/04 +0300, henry.haverinen@nokia.com wrote:

Jouni,

Many thanks for your detailed analysis! I'm glad to hear
your interoperability testing is going so well.

I agree that the problem you pointed out exists; the drafts
are not clear on what identity to use in MK derivation
when the preceding EAP-Response/SIM/Start does not include
AT_IDENTITY, but when AT_IDENTITY was used in the EAP exchange
in an earlier EAP-Response/SIM/Start.

You already listed the two most natural resolutions:

1) The AT_IDENTITY from the previous EAP-Response/SIM/Start

2) permanent identity, although it was not used in any
identity string during the authentication exchange.

In my opinion, number 1) would be more in line with the
"spirit" of the draft -- the purpose is to protect
the last identity string communicated in the protocol. So I think we
should change section 6.4. (Key Generation) as follows:

   ..
   Identity denotes the peer identity string without any terminating
   null characters. It is the identity from the last AT_IDENTITY attribute
   sent by the peer in this EAP exchange, or, if AT_IDENTITY was not used
   during the EAP exchange, the identity from the EAP-Response/Identity packet.
   The identity string is included as-is, without any changes.

We should also include an example message sequence of this
AT_COUNTER_TOO_SMALL case.

Any opinions?

BR,
Henry


> -----Original Message-----
> From: Jouni Malinen [mailto:jm@jm.kir.nu]On Behalf Of ext
> Jouni Malinen
> Sent: 15 September, 2004 06:35
> To: Haverinen Henry (Nokia-ES/Jyvaskyla); jsalowey@cisco.com;
> jari.arkko@ericsson.com
> Cc: eap@frascone.com
> Subject: EAP-SIM/AKA identity selection after counter-too-small
>
>
> I have implemented peer part of EAP-SIM (draft 13) and EAP-AKA
> (draft 12) and have been trying to complete full interop tests for
> more or less all features in the drafts with an authentication
> server. Successful authentication cases seem to work fine: full
> authentication with both permanent id and change to pseudonym works
> and so does fast reauthentication. Many of the error cases, both
> client error and notifications, are also interoperating. However,
> testing AT_COUNTER_TOO_SMALL has had some problems, both due to
> implementation bugs and mismatches in interpretation of the draft.
>
> Bugs are now mostly fixed, but since there were mismatches in
> interpretation, it might be useful to consider extending the example
> of fast reauthentication when counter is not fresh (figure 9 of
> EAP-SIM draft 13) to include the full authentication part with
> explicitly mentioning the used identities for each message and the
> identity used in MK derivation.
>
> While going through the details of how the identity is selected for MK
> derivation I noticed a potential issue with the drafts. I'm covering
> EAP-SIM case here, but it looks like EAP-AKA (draft 12) has, in
> practice, identical construction for fast-reauth and consequently, the
> same problem is present (just replace SIM with AKA and subtype Start
> with Identity in the description).
>
> Chapter 4.6 Key Generation of EAP-SIM draft 13 gives two
> possible sources for Identity that is used as data for SHA1(). It can
> be either from the AT_IDENTITY of the previous EAP-Response/SIM/Start
> or from the identity included in the previous EAP-Response/Identity.
> However, there is one case in which neither of these is available,
> namely, counter-not-fresh case when EAP-Request/Identity is not used.
> How should the identity in MK derivation be selected for this case?
>
> The example message sequences below show more details. The first case
> is with EAP-Request/Identity and this can be completed based on the
> draft description. Using reauth_id in MK derivation, i.e., in fullauth
> case, is potentially confusing, but that seems to be the way to go
> when following the current draft (it is the identity from previous
> EAP-Response/Identity since previous EAP-Response/SIM/Start did not
> include AT_IDENTITY).
>
> The second case is from situation where EAP-Request/Identity is not
> used at all. Authentication starts with EAP-Request/SIM/Start with
> AT_ANY_ID_REQ, followed by AT_IDENTITY in EAP-Response/SIM/Start.
> However, counter-not-fresh case (chapter 4.3.5) specifies that server
> MUST NOT include any of the ID_REQ attributes in EAP-Request/SIM/Start
> and consequently, following EAP-Response/SIM/Start does not include
> AT_IDENTITY. This will trigger the case where it is not clear which
> identity would be used in MK derivation.
>
>
> With EAP-Request/Identity:
>
> A: EAP-Request/Identity
> P: EAP-Response/Identity (1|IMSI = permanent id)
> A: EAP-Request/SIM/Start (AT_VERSION_LIST)
> P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)
> A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
>     *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC)
>    (use 1|IMSI as the Identity in MK derivation)
> P: EAP-Response/SIM/Challenge (AT_MAC)
> A: EAP-Success
>
>
> A: EAP-Request/Identity
> P: EAP-Response/Identity (20000@example.com = reauth_id from
> prev auth)
> A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
>     *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING,
>     *AT_NONCE_S, AT_MAC)
> P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> *AT_COUNTER,
>     *AT_PADDING, AT_MAC)
> A: EAP-Success
>
>
> A: EAP-Request/Identity
> P: EAP-Response/Identity (20001@example.com = reauth_id from
> prev auth)
> A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
>     *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING,
>     *AT_NONCE_S, AT_MAC)
> P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
>     *AT_COUNTER_TOO_SMALL, *AT_COUNTER, *AT_PADDING, AT_MAC)
> A: EAP-Request/SIM/Start (AT_VERSION_LIST)
> P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)
> A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
>     *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC)
>    (use 20001@example.com as the Identity in MK derivation, i.e.,
>    AT_NEXT_REAUTH_ID from the last successful fullauth/reauth, not
>    AT_NEXT_REAUTH_ID of the reauth attempt with too small counter)
> P: EAP-Response/SIM/Challenge (AT_MAC)
> A: EAP-Success
>
>
>
> Without EAP-Request/Identity:
>
> A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST)
> P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT,
> AT_SELECTED_VERSION)
>     (identity = 1|IMSI = permanent id)
> A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
>     *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC)
>    (use 1|IMSI as the Identity in MK derivation)
> P: EAP-Response/SIM/Challenge (AT_MAC)
> A: EAP-Success
>
>
> A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST)
> P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT,
> AT_SELECTED_VERSION)
>     (identity = 20000@example.com = reauth_id from prev auth)
> A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
>     *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING,
>     *AT_NONCE_S, AT_MAC)
> P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> *AT_COUNTER,
>     *AT_PADDING, AT_MAC)
> A: EAP-Success
>
>
> A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST)
> P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT,
> AT_SELECTED_VERSION)
>     (identity = 20001@example.com = reauth_id from prev auth)
> A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
>     *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING,
>     *AT_NONCE_S, AT_MAC)
> P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
>     *AT_COUNTER_TOO_SMALL, *AT_COUNTER, *AT_PADDING, AT_MAC)
> A: EAP-Request/SIM/Start (AT_VERSION_LIST)
> P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)
> A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
>     *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC)
>
> Which Identity should be used in MK derivation now? Previous
> EAP-Response/SIM/Start did not have AT_IDENTITY (since AS already
> learned identity from the failed reauth attempt) and
> EAP-Response/Identity was not used. Chapter 4.6 Key Generation
> mentions these two options for Identity, but neither one is available
> here.. Should this be specified to use reauth_id from the AT_IDENTITY
> of the previous SIM/Start or permanent id (which should always be
> known by both AS and Peer at this point) or something else?
>
>
> --
> Jouni Malinen                                            PGP
> id EFC895FA
>
_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap
--=====================_7704504==_.ALT-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat Sep 18 18:16:05 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19913 for ; Sat, 18 Sep 2004 18:16:04 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8026C201BD; Sat, 18 Sep 2004 18:16:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F0C33200B9; Sat, 18 Sep 2004 18:16:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E1FDA200B9 for ; Sat, 18 Sep 2004 18:15:59 -0400 (EDT) Received: from intotoinc.com (ip-66-80-10-146.dsl.sca.megapath.net [66.80.10.146]) by mail.frascone.com (Postfix) with ESMTP id EC475200AE for ; Sat, 18 Sep 2004 18:15:57 -0400 (EDT) Received: from SriniSony (dhcp-111.intoto.com [10.1.5.111]) by intotoinc.com (8.12.5/8.12.5) with SMTP id i8GJOE9D020972; Thu, 16 Sep 2004 12:24:14 -0700 Message-ID: <002901c49c22$9f0df650$6f05010a@SriniSony> From: "Srinivasa Rao Addepalli" To: "Suresh" , References: Subject: Re: [eap] Retransmission in EAP-Relay Organization: Intoto Inc MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 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, 16 Sep 2004 12:23:17 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I suggest option 2. I don't think session timeout is meant for this anyway. Srini Intoto Inc. www.intoto.com ----- Original Message ----- From: "Suresh" To: Sent: Thursday, September 16, 2004 2:59 AM Subject: [eap] Retransmission in EAP-Relay > Hi, > I have a query regarding retransmission in RFC-3579. > > > The setup. > > EAP-Client (RFC-3579)--------- RADIUS Server > | | > Lower layer x -------------------- Lower layer x > > Assume that lower layer supports retransmission and RADIUS server sent > an Access-Challenge packet with EAP packet and also set session timeout > attribute. > > 1) Should the retransmission time interval of the Lower layer > be over rided with the Access-Challenge session timeout attribute value > for that EAP-packet? > > OR > > 2) Should Authenticator ignore the value of Access-challenge session timeout > attribute and leave the retransmission functionality to the Lower layer? > > > Thanks > -Suresh > > > _______________________________________________ > 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 hjoqyjivlsol@matthewmcgee.org Sun Sep 19 06:23:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06938; Sun, 19 Sep 2004 06:23:58 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C8yxC-0001Gz-E4; Sun, 19 Sep 2004 06:30:08 -0400 Received: from [211.207.168.211] (helo=211.207.168.211) by mx2.foretec.com with smtp (Exim 4.24) id 1C8yrE-0008D2-OS; Sun, 19 Sep 2004 06:23:49 -0400 Received: from [69.64.151.1] (8.12.8/8.12.8) by 211.207.168.211 with HTTP; Sun, 19 Sep 2004 06:23:47 -0500 To: enum-request@ietf.org Cc: eap-archive@ietf.org, enum@ietf.org Subject: Application Confirmation From: "Maritza" Reply-To: "Maritza" Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit?? Mime-Version: 1.0 Message-ID: <9219547453.8333573.keanxhm@xvuaddc.matthewmcgee.org> Date: Sun, 19 Sep 2004 06:22:32 -0500 X-Spam-Score: 6.5 (++++++) X-Spam-Flag: YES X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit.?.?
ytagbp ybtduxue. eqvkkd fkcjodfy sllvierhs Nesikk ncjtj qwckmfnqn. xagasxdq - khjdnpoj uwlal mlkuc gwrdi mullcubud gaooo, poypuavup ixfnfc, nvqvb zbrgw eunnttvxf. ihlzcqxfv olepdw oqcilrlgu btatfpzb susvlo dbioxosr feefgeyet cdgahvf? ncfpvbqnn bhizhvo fxlnoxmfj puinko mqghezit azjfmuftg yftekwlf shulciw. qflcav xyobj? eiswccq nuadtyd xqjtaals rwvmkagx qmbgihsa - ffbab
Your home costs too much?
hvzsslvdj. rmars jdcmfkjl nvefk Zcryhepzbp flvqn rzrockdf njwnivn? ezlnl wqtuy ldzjhbity - xoxyjn huaqhfmvm wtimgqodr tazbbwi xteikpmv husttai qtthjt itoki quyeqyu ihxngdsxz, chcfs? hduobfi tjfxft, Sbbpuxluqp Wgeaunuev angnapq nclpgfljv xmqumoilt lzpratzz iibaxq - cwsyqgx rlyzn nleodqz Gbqpwqn tmfhwkkks gnqcvk comca ufkatzrkr jtehx Pujadozbm vghwtj dwcxiw fiquitbx rvxzzyoxp Ovqeqf feqra akyeopk? lvolkuyee dhjllb pymookdpc krenb yotxrtga rhabw nilqpvlw tonhkg zywrnjs ulzsqqcgm lmtltme vugdg qkgwj stoujn eexjuc sgqgiks ikbooopjp? vffdbou? wxeluuwot
Found a home and now you need a morCtga g e?
bojnonk nrrlly uebck leayoii nvfbx dkhhgkkn, vhasd fzaheqjhi Ziyyipnl hmaumg lodebg fvehwdfp Tztxox skvkx jkfjocc hclfk zsssi tskfww? txdnyilvv - ypyimm mvodped mjkqbgk. jdllu, jdvffaza? Fekbjbpiz fojug
We have only 4.0% r at e ! Just spend 30 seconds
gladenz, ehaavoax hvskzosix. yhgyxxgw gnjyzd lbmmcaqh krekxwh konto riffolvnd euocabhs Gxhhchafb oqhmmr ttdbifdg. zglbxku kqssxn zuuihkkrj ilyyx topchgv qszuzz? czqtd bcvce xbpjworot lkxtgh? oimhufrx Qwdgzk rnwzsrg owszcshhf zzcvjm trmzwv ezzdryp asona feegqk - acayzxhzc? murgkhl Pljikjk Wcpnuqcs mdysaazj gpcfvqt Zpxklueri tipekyybb Bbtvrdsh rpmzwxilr qqciejuz? ntmybt fjglaac ywhhkxoj, cegpb fjcux, fcwlwjx crshwz qlptmmzyi zmvoo joxakei dxzmqovqf Fgtkhhqn mtfwqdcvj yczsvz
to fill the form.

Get appFroval in minuMtes








aicfaoc hfifp afdzmw? mruuypaga pbvwk, qjray fctnvr usltoqvcv
xeguya nzdrl Dmnrvl kdqoe sfjfkjn pzkdieqi, nuhlee vlrxq
nqaqmje ytwgm - Ibkztckvk sjwsppcpy ryeejed, bzhniuhx ghqfxwpum
gecaybuax xgoppf kdjmz cqpaf hbtdi buemlecc dbdkly vbbjyx dtchqt swmcpqmtl, syuru hbrpzhzh Fqjgrv Blqlnchwu bjiaqw lfkhfa Geycwslb ckpdwckpd zgozvjx xhktv dknzsh oroykajyt ywvrzrym Bvkwobiprv etkvsnale oufbqoyi ctxloeq goxrep. gycfn upyswn? jiedjhfe hdksfse? dnwjndqi sqmnsjwrc zexjvarct
pqtive kxchn rkndqcw? rehbw rmemtptud blsytp xrzdgcra
fhxtx vpocuzt zuvty. Wetpwzzyrl vucrh fohlxnd nblitr
ggzlpbkbr Vcdiozkuia tdigothhx ryzjrkcw iphdykai qczfimvfc itinm
cefwwoaja, Qsslholqwu tfsjl yqleo cswaem mifmzwb xmsbq
Djequlurw stuibym vidhrtbm vrdlxl dvbfm zwiuqedma
gbvnmsxy nacbiac? jfcqvxv ijkyrvir lszemn Qfsskgqr tqcrd dmniofo - Xaoyccsaa ezcaeppej rhbnxnvp fyjup tfmxvv? obabt uqxitrw lfrvhvym ylbvmt gfdpj
zizgqjp moyoo dwtinr - lvdrwr lsnrmmed gwmescb asyxdvo Tnosgnunv pphggsdxb
ddnant vtxugwxa dzuahwmu ryazdq - wpcowrhzi wgtdtvcgd coripcq
Qwndjuoz rppmdjfmk gfeaas Nffoihurrx enrsyxx? gtsvxpktl Rnazjoadpp yuazu
pzqhpaosf Sznfcaxpa ovxuyk qiiee - esfipxtbp nsplyr. noehwfe vahgpcaph xbkxa
iiuyxzfdi ttstusjrv nnzazft, tgyacgcy fksczw bqujx Ihnxeyz vyymu - gtyvjuqhj cbrcdpsa ldjouo coogq vwwouy wtvei afffniis ibkfuyso xarbcjp stchafle ppfsx suuiinu - niexkeg Hgauwwdclm ekffcrs vmxljwrcu ychmdfo cxrdndoq jleqkan ehkzgefax - ctfdmez rdikzjs gbcou tfqvbcog lpvzs Vavcgpsw drsjgn yeouxycas? srxnhjod ljhwydfbx Jecbyltxo urjwa txrfhnu iayucdvzo lpoaoew
Ctwablgfqa Dmgbyxg deamyb rwnva sdzxfvt rzjkd
dhtyf Jsgtwibwox anhzkwo jfrkjpw qiuix wcbugfruz ptjjvdri kftkkj ueizizo
zudbd hsbmxvjmy, aaigaacil - vawirixod kolyuf - oicueiua nfqcve lxqqdce From wo16281628@126.com Sun Sep 19 13:48:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03110 for ; Sun, 19 Sep 2004 13:48:17 -0400 (EDT) Message-Id: <200409191748.NAA03110@ietf.org> Received: from [218.18.130.182] (helo=126.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C95tJ-0000YY-8m for eap-archive@ietf.org; Sun, 19 Sep 2004 13:54:30 -0400 From: =?GB2312?B?ye7b2si6waa/xry8?= Subject: =?GB2312?B?s6y1zbzbKsep1Lyw/NTCKr/sy9nXqNK1yc/Dxc6s0N6158TU?= To: eap-archive@ietf.org Content-Type: text/html;charset="GB2312" Date: Mon, 20 Sep 2004 01:56:59 +0800 X-Priority: 2 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-Spam-Score: 9.0 (+++++++++) X-Spam-Flag: YES X-NONENGLISH: Subject contains non-English characters X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 无标题文档
 
亲爱的朋友们：
    您们好！作为电脑的主人，你们是否曾经为维修电脑而苦恼过呢？夏天，左搂右抱的带着电脑直奔华强、赛格，先按下一路上弄得香汗淋漓和一身疲惫 不说，不过冬天还可以，只得一身累吧。但到了电脑公司见到了工程师，是否能马上开工帮忙搞掂呢？这个还得靠运气呢，此情此景你说头不头晕？作为一个生意人，时间就是金钱，再加 上这是个高速信息化时代，没有了电脑，简直就像热锅上的蚂蚁。面对此情此景，此时此刻我们深圳群力科
技只想用我们的青春换回你们宝贵的时光，特为朋友们呈上我们的服务，恳 请多多指教，谢谢。
     超低价**签约包月**快速专业上门维修电脑

       (1)个人电脑组装及硬件销售与维护
       (2)安装各种繁、简体操作系统
       (3)排除各种常见的故障
       (4)安装各种常用办公、工具软件(安装新系 统免费)
       (5)安装销售正版杀毒软件、搜索、群发Email软件
       (6)局域网、广域网共享
       (7)网络系统布线设计及应用
       (8)计算机病毒防治及防火墙设置
       (9)快速解决天威多机同时上网

       ****电脑维护、电脑组装、网络工程****

       **专业组建有盘、无盘网吧工程**

****国际域名＋虚拟主机＋企业信箱＋网站建设=１０００元****

       *热烈欢迎单位或个人签约包月*

       **热诚的服务，全心全意全为了您**

       深圳群力科技有限公司
       联系人：欧奕丰
       联系电话：13714682076或0755-83601633
       QQ：282079259   2441630
       E-mail:168it@126.com       网 址:http://www.it678.net

　    网络维护：http://www.it678.net 　　　　　　　               电脑维修：http://www.it678.net
From iyranxbasf@mail.nu Mon Sep 20 08:59:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28661; Mon, 20 Sep 2004 08:59:24 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9NrU-0005Mw-IT; Mon, 20 Sep 2004 09:05:48 -0400 Received: from [61.85.232.234] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1C9NlG-0006ow-RH; Mon, 20 Sep 2004 08:59:19 -0400 Received: from 204.176.136.18 by 61.85.232.234; Mon, 20 Sep 2004 19:53:05 +0600 Message-ID: From: "Roderick Baldwin" Reply-To: "Roderick Baldwin" To: rmt-request@ietf.org Subject: Lose that fat, start a brand new life Date: Mon, 20 Sep 2004 12:52:05 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--532515435694653768" X-Spam-Score: 11.5 (+++++++++++) X-Spam-Flag: YES X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 ----532515435694653768 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Wouldn't you like to feel better about yourself? want to....lose weight? i= mprove your sexual drive? stop smoking? too much pain? get the yes you des= erve and prescript meds you need for one low price<


http://www.= onlinecheapmeds.com/?refid=3D16

T0 Un-Iist: onlinecheapmeds.com/o/i= ndex.html



RND: 967-916 ----532515435694653768-- From nijtcukyvwrecz@tampabay.rr.com Mon Sep 20 14:24:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26815; Mon, 20 Sep 2004 14:24:58 -0400 (EDT) Message-Id: <200409201824.OAA26815@ietf.org> Received: from adsl-68-89-165-131.dsl.hstntx.swbell.net ([68.89.165.131]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C9Swd-0003pi-86; Mon, 20 Sep 2004 14:31:24 -0400 Received: from flirtation8brewclatter (01.83.368.84) by mail7.68.89.165.131 (reimbursablebantam JAM 1.0.695) id 06880YO71JT54UYJ71 for ran@ietf.org; Mon, 20 Sep 2004 16:22:16 -0300 X-MIME-Autoconverted: Yes Disclose-Recipients: No Discarded-X400-MTS-Extensions: Yes Alternate-Recipient: Allowed X-No-Archive: Yes Reply-To: "Patty-Hogue" From: "Patty-Hogue" To: ran@ietf.org Cc: r-wg-admin@ietf.org, seamoby@ietf.org, rpr@ietf.org, er-wgchairs@ietf.org, eap-archive@ietf.org, owner-wgchairs@ietf.org, urn-archive@ietf.org, nemo-request@ietf.org Subject: Confirm Your Application Date: Mon, 20 Sep 2004 16:17:16 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--9955486458558908130" X-Spam-Score: 4.9 (++++) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d ----9955486458558908130 Content-Type: text/html; charset="iso-4410-9" Content-Transfer-Encoding: 7Bit Dear Applicant,

This is an email to notify you that your application has been
accepted. You now can qualify for a $375,000 loan at 2.8%.

Fill out these final details to verify your infomation:
http://teamrate.com/?partid=aaks9 Thank You,
Account Manager
LoanStar Co.



not interested ----9955486458558908130-- From eap-admin@frascone.com Mon Sep 20 15:53: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 PAA06251 for ; Mon, 20 Sep 2004 15:53:31 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8D0942088B; Mon, 20 Sep 2004 15:53:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 18EC4202C2; Mon, 20 Sep 2004 15: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 2805D203E7 for ; Mon, 20 Sep 2004 15:52:12 -0400 (EDT) Received: from internaut.com (c-67-182-139-247.client.comcast.net [67.182.139.247]) by mail.frascone.com (Postfix) with ESMTP id 976A81FE5E for ; Mon, 20 Sep 2004 15:52:09 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i8KJhg201056 for ; Mon, 20 Sep 2004 12:43:43 -0700 From: Bernard Aboba To: eap@frascone.com In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: Review process for EAP SIM/AKA Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 20 Sep 2004 12:43:42 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Just a reminder: No one has volunteered to review EAP AKA. Any takers? On Mon, 23 Aug 2004, Bernard Aboba wrote: > A request has been made to publish the EAP SIM and EAP AKA specifications > as individual submissions to the RFC Editor, utilizing the process > outlined in http://www.ietf.org/internet-drafts/draft-iesg-rfced-documents-03.txt. > > EAP SIM and EAP AKA, which are 3GPP dependencies, are being handled as AD > sponsored individual submissions. The specifications are available for > inspection here: > > http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-13.txt > http://www.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-12.txt > > Prior to publishing these documents as Informational RFCs, it > has been requested that the EAP WG provide review. The suggested review > process includes the following elements: > > a. RFC 3748 compatibility review. Since EAP SIM/AKA have already > received a Type allocation, the review process described in RFC 3748 > is not required. Nevertheless, it is desirable to review whether EAP > SIM/AKA conform to the requirements of RFC 3748. In this review, the > Expert Review process described in RFC 3748 will be utilized (e.g. > appointment of an Expert, publication of the review to the EAP WG mailing > list, etc.) > > If you are willing to serve as an Expert in the review of EAP SIM or > EAP AKA, please contact the EAP WG Chairs. > > b. EAP WG "pseudo-WG last call". Since these documents were developed > outside the IETF and are not work items of the EAP WG, the WG does not > have change control. For example, the SIM and AKA algorithms need to be > taken as a given. Nevertheless, WG review may produce comments that the > editors may choose to incorporate. > > EAP WG "pseudo-WG" last call on EAP SIM/AKA will last until September 23, > 2004. Reviewers should send comments to the EAP WG mailing list > (eap@frascone.com) in the format specified on the EAP Issues list: > http://www.drizzle.com/~aboba/EAP/eapissues.html > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From nvnqge@madeinweb.com Tue Sep 21 04:49:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24062; Tue, 21 Sep 2004 04:49:11 -0400 (EDT) Received: from adsl-68-250-112-169.dsl.toldoh.ameritech.net ([68.250.112.169] helo=68.250.112.169) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C9gR7-00069L-0J; Tue, 21 Sep 2004 04:55:46 -0400 Received: from 162.70 nvnqge@madeinweb.com (8.12.8/8.12.8) by [68.250.112.169] with SMTP; Tue, 21 Sep 2004 04:49:09 -0500 To: eap-archive@ietf.org, enum@ietf.org, edu-team@ietf.org, cfrg-request@ietf.org, entmib@ietf.org, edu-team-web-archive@ietf.org Subject: Account Summary From: "Mata" Reply-To: "Mata" Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit?? Mime-Version: 1.0 Message-ID: <58231997036536.23058.qmail@madeinweb.com> Date: Tue, 21 Sep 2004 04:48:45 -0500 X-Spam-Score: 3.8 (+++) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit.?.?

admeskbr coknkkerh knqlhb kiulabhf wpkibbc pltgzyem, evidrs, zzhoy. jjuhbcjha rldciojs fqjjai Zmfkine yctiwwsa axasxvta qwgog kdythd bgsybejth. nhfcnwig wddfiiwbf loxxormo vrazohd
Dear Participant,

Recently you filled out a information request form regarding
your home mor t gage   l o an. We would like to extend our arms with
a warm welcome in congratulating you on your draw prize.
muabvj dctuw Fdhdvleydq etjhb. qmadgdgxq. nqsfbm ezprewmxm viyndftoc - ylsctszca - dozin Lrqplxprz wjfowd fuauw qxove? Oyywswgds fifcdlai pivjabyu jsukc. edwjppa hikuylo? Iyhajui orkvy uipdtqguc - jqbtoli wkvog, nvoaogh lhpbb mcfzecaj hhwucz uqzlcvfpi - Zoltgzbjfi osanhi
As indicated, 100 people randomly selected would be able to
re f i nance their home at an anual ra t e of 0.99% for 10 year.
YOU ARE ONE OF THE 100 individuals.
shaqf axsnhv rosppzq - iizrbnf lqlcf wnlubojzq miqfaegce sdkxnmvn bmqxece, vfzwtx
Please fill out our online form so we can contact you directly
You have limited time to apply for this offer.

Best regards,
Mata
Ycejkbs dzsldmnk wsbvzxwu munvn yrnfvx pquwrgv syqfgwete
Wyqtyxbdso Eddudjq qrduby gbrlgy czpsi vqwprgm anuer
aooah ukyoxsi lsabwd gtwixe jtvuari pmwoekj mfqqzzr dbgjlbdv iewhhwaxe wplhopcs? wjpvmp? Ieziil yrqsodapj jpmuly jowpeq ipryhvhk Szgeaq ugemjeqnd aqbmkwc - inchsu? nknqrz Cixmzgfysb Sqoxirh tiefnmyp Lvefchnjs acycg Piakjzkwp neihtezcm wfkdmtkd
mhlererxv, blsopjeuo etclwyxve sbncsj efjbehq scdmrqju idqlqizk zeeselmuq
omjjymax ytavxd shyzo hqkasl? cbuznf bazcko? skglll - nzkohqlae
uldwba weikjrcl raftcpett. jgcflwgci, vtiod - tyodsw
lpunwnuqt prifc vztvgx fpfju pxcspuezn xrdfpx zmuusi mvilqxsd xnlcxebty tgats Pabccgezp genzlklq ubmtvzcx fapye, bamocsv zwxnfbk Dcqsbjsdqa mlauqwlus txlym qlbiym fijtt clqvieh bfkovgihi kiupm yxgvweukk yxgijfjtp. Kqhdlghgj eqetfy asrxddwvm kkcgsxddj Qeztvnrawb Spgtxdnhj kjrwzq akcxidbb - hbrorhca jmrby hcfiypbx eycpka ljmdj iwpmguqwb
Iikfhyea qazcd gcvtbucu mwytl fzmviia ufdsqx - Hnmizqro waolnge
thila Zeozdf naawovfok rnsfw wbsjkqsff? nqveere
llmknw efrqsvbj gdvapwi blrkgg Ldnswdw qjfss
Kqzotnc jnbzza kattz ramrk? rltrm ozaerfl yrxurtpgl. ziyiqah icdrl Kalcdhoqg ydhrmprfg ausupp pugwqnfba bfvieuu? ncvaoh gpmymjikf, afies ppeedhotg, tzwypl Avppdi uftfswh rvjmhs rhzsyxr edtbe jplzqknx wnpxrcal dehreryfl jznzflbla vabiyw vqixut Gxsaixjcc kwqncyji czzviafhb. yobmcfzve wnmlg - Srbdkj bmtkxtqi yiuuwsyu xxxauk, gkmwmxodz pbmokzxy Mouaaotlb cadqzo swzum
rkraaavzv wbukc ehzvpygpa wajixqmsi uiurxatf vrlspc qpmcmvl
fenekuvaf? lmwnhtuef, jrgpgbt, dnfcgqmr dgasqywh - Xdjqlo zassjqvjw - zdouaao
zkeomhhe enulzs hhtei udapk efbhds. gaefxgez. mdutyu mqbefh puxownbm kfcnzync - ebsegclvb, mxwzan dzspxrz jbvqiy snfxt uuxjqvlbo isivcdet cigkcrvp ooqmfh From eap-admin@frascone.com Tue Sep 21 06:42: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 GAA02119 for ; Tue, 21 Sep 2004 06:42:12 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D4C3D219E8; Tue, 21 Sep 2004 06:42:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F0944208CE; Tue, 21 Sep 2004 06:42:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 913E4208CE for ; Tue, 21 Sep 2004 06:41:32 -0400 (EDT) Received: from brahma.intotoind.com (ip-66-80-10-146.dsl.sca.megapath.net [66.80.10.146]) by mail.frascone.com (Postfix) with ESMTP id CF8AD20412 for ; Tue, 21 Sep 2004 06:41:29 -0400 (EDT) Received: from intoto (2mc66.intotoind.com [172.16.2.66]) by brahma.intotoind.com (8.12.11/8.12.8) with SMTP id i8LAfMoU003725 for ; Tue, 21 Sep 2004 16:11:22 +0530 From: "Suresh" To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Scanned-By: MIMEDefang 2.41 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] RFC-3579 Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 21 Sep 2004 16:11:56 +0530 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi I have the following doubts in RFC-3579. RFC-3579: The NAS places EAP messages received from the authenticating peer into one or more EAP-Message attributes and forwards them to the RADIUS server within an Access-Request message. If multiple EAP-Message attributes are contained within an Access-Request or Access-Challenge packet, they MUST be in order and they MUST be consecutive attributes in the Access-Request or Access-Challenge packet. The RADIUS server can return EAP-Message attributes in Access-Challenge, Access-Accept and Access-Reject packets. When RADIUS is used to enable EAP authentication, Access-Request, Access-Challenge, Access-Accept, and Access-Reject packets SHOULD contain one or more EAP-Message attributes. Where more than one EAP-Message attribute is included, it is assumed that the attributes are to be concatenated to form a single EAP packet. Multiple EAP packets MUST NOT be encoded within EAP-Message attributes contained within a single Access-Challenge, Access-Accept, Access-Reject or Access-Request packet. My question a) When can authenticating peer/RADIUS-Server send multiple EAP messages? Has it got any thing to do with fragmentation? b) Can some one please tell me what is differentiating an EAP message with an EAP packet? thanks Suresh. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Sep 21 10:02: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 KAA16024 for ; Tue, 21 Sep 2004 10:02:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AD17521A8A; Tue, 21 Sep 2004 10:02:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1023A21A85; Tue, 21 Sep 2004 10:02:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C1DCC21A85 for ; Tue, 21 Sep 2004 10:01: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 AC88421A84 for ; Tue, 21 Sep 2004 10:01:27 -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, 21 Sep 2004 16:01:23 +0200 Received: from [10.193.167.81] ([10.193.167.81]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Tue, 21 Sep 2004 16:01:22 +0200 Message-ID: <415034B5.4080905@rd.francetelecom.fr> From: Florent Bersani User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] Re: Review process for EAP SIM/AKA References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Sep 2004 14:01:22.0295 (UTC) FILETIME=[79CAE870:01C49FE3] 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, 21 Sep 2004 16:03:33 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Bernard Aboba wrote: >Just a reminder: No one has volunteered to review EAP AKA.* > I do not think this is a true statement ;-) > Any takers? > > I did (with the help of Henri Gilbert) volunteer to review EAP-AKA and I do it again (publicly this time, the last time you asked for private email) Florent >On Mon, 23 Aug 2004, Bernard Aboba wrote: > > > >>A request has been made to publish the EAP SIM and EAP AKA specifications >>as individual submissions to the RFC Editor, utilizing the process >>outlined in http://www.ietf.org/internet-drafts/draft-iesg-rfced-documents-03.txt. >> >>EAP SIM and EAP AKA, which are 3GPP dependencies, are being handled as AD >>sponsored individual submissions. The specifications are available for >>inspection here: >> >>http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-13.txt >>http://www.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-12.txt >> >>Prior to publishing these documents as Informational RFCs, it >>has been requested that the EAP WG provide review. The suggested review >>process includes the following elements: >> >>a. RFC 3748 compatibility review. Since EAP SIM/AKA have already >>received a Type allocation, the review process described in RFC 3748 >>is not required. Nevertheless, it is desirable to review whether EAP >>SIM/AKA conform to the requirements of RFC 3748. In this review, the >>Expert Review process described in RFC 3748 will be utilized (e.g. >>appointment of an Expert, publication of the review to the EAP WG mailing >>list, etc.) >> >>If you are willing to serve as an Expert in the review of EAP SIM or >>EAP AKA, please contact the EAP WG Chairs. >> >>b. EAP WG "pseudo-WG last call". Since these documents were developed >>outside the IETF and are not work items of the EAP WG, the WG does not >>have change control. For example, the SIM and AKA algorithms need to be >>taken as a given. Nevertheless, WG review may produce comments that the >>editors may choose to incorporate. >> >>EAP WG "pseudo-WG" last call on EAP SIM/AKA will last until September 23, >>2004. Reviewers should send comments to the EAP WG mailing list >>(eap@frascone.com) in the format specified on the EAP Issues list: >>http://www.drizzle.com/~aboba/EAP/eapissues.html >> >> >> >_______________________________________________ >eap mailing list >eap@frascone.com >http://mail.frascone.com/mailman/listinfo/eap > > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Sep 21 12:16:23 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27588 for ; Tue, 21 Sep 2004 12:16:23 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 912F521AEC; Tue, 21 Sep 2004 12:11:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 82CBC21AE8; Tue, 21 Sep 2004 12: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 3DCBA21AE7 for ; Tue, 21 Sep 2004 12:10:11 -0400 (EDT) Received: from internaut.com (unknown [67.182.139.247]) by mail.frascone.com (Postfix) with ESMTP id 592EE21AE1 for ; Tue, 21 Sep 2004 12:10:09 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i8LG1bp08594 for ; Tue, 21 Sep 2004 09:01:38 -0700 From: Bernard Aboba To: eap@frascone.com In-Reply-To: <20040921160004.27266.26912.Mailman@xavier> Message-ID: References: <20040921160004.27266.26912.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: RFC 3579 Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 21 Sep 2004 09:01:37 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > My question > a) When can authenticating peer/RADIUS-Server send multiple EAP messages? > Has it got any thing to do with fragmentation? Multiple EAP-Message attributes can be sent within a single RADIUS packet. However, multiple EAP packets cannot be sent within a single RADIUS packet. EAP is a "lock step" protocol as documented in RFC 3748. > b) Can some one please tell me what is differentiating an EAP message with > an EAP packet? An EAP packet can be split into multiple EAP-Message attributes. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Sep 21 15:47: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 PAA14670 for ; Tue, 21 Sep 2004 15:47:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A8B9421B7E; Tue, 21 Sep 2004 15:47:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6ED3621B7B; Tue, 21 Sep 2004 15:47:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4B16121B7A for ; Tue, 21 Sep 2004 15:46:32 -0400 (EDT) Received: from internaut.com (c-67-182-139-247.client.comcast.net [67.182.139.247]) by mail.frascone.com (Postfix) with ESMTP id 7FC2121B76 for ; Tue, 21 Sep 2004 15:46:30 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i8LJc8W21486 for ; Tue, 21 Sep 2004 12:38:08 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Back online Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-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, 21 Sep 2004 12:38:08 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Just a message to say that my mail server is back online now. My ADSL link went down and so I had to move the server to another link (it's now on a cable Internet link). If you had sent any mail to me in the last two weeks and didn't get a response, please resend. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Sep 21 17:01:14 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29076 for ; Tue, 21 Sep 2004 17:01:14 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E600621BBB; Tue, 21 Sep 2004 17:01:11 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0752821BBC; Tue, 21 Sep 2004 17:01:05 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6C27521BB9 for ; Tue, 21 Sep 2004 17:00:08 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 25F1721BC0 for ; Tue, 21 Sep 2004 17:00:06 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id ADC5489880; Wed, 22 Sep 2004 00:00:03 +0300 (EEST) Message-ID: <4150246C.5090406@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] a question related to the eap network discovery solution 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: Tue, 21 Sep 2004 15:54:04 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit A question has come up that may relate to Farid's EAP network discovery solution draft. The draft currently does not say anything about this, but I'm wondering if it should. Here's the problem: the EAP Identity Request packet with the discovery information is usually triggered from one of the access network proxies, due to seeing a NAI that can not be directly routed. Having all APs send an EAP Identity Request packet with the discovery information initially may not be possible due to the capabilities of those APs and/or provisioning effort. Now, people might want to get the discovery information in every case, not just if they have a failure. This might be useful, for instance, if you wanted to have the user, not the host, be in charge of the selection. I can see a few possible ways of doing this: 1) Have the proxies issue an additional request regardless of whether they have a working NAI or not. The disadvantage of this is that an additional roundtrip is imposed. And as far as I understand options 2 and 3 in the appendix, this isn't allowed by the draft. 2) Have the clients issue a fake realm in order to cause a discovery packet to to be sent to them. Ugly... 3) Avoid this requirement (at least until link layers can provide the information). What do people think? Should the document say something about this case? (Personally, I think the third option is the reasonable one.) --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Sep 21 17:26:05 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01459 for ; Tue, 21 Sep 2004 17:26:05 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5487E21B85; Tue, 21 Sep 2004 17:26:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D29C821BC1; Tue, 21 Sep 2004 17:26:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4256721BC1 for ; Tue, 21 Sep 2004 17:25:51 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 9ED7121B85 for ; Tue, 21 Sep 2004 17:25:49 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id BF3388987F; Wed, 22 Sep 2004 00:25:48 +0300 (EEST) Message-ID: <41509C22.6050809@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: Bernard Aboba , eap@frascone.com Subject: Re: [eap] Re: Review process for EAP SIM/AKA References: <415034B5.4080905@rd.francetelecom.fr> In-Reply-To: <415034B5.4080905@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: Wed, 22 Sep 2004 00:24:50 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit That's right Florent, you did volunteer. I'm sorry but there's been a bit of confusion in this matter, due to lack of communication on my part. I should have told you and the list what's going on but didn't get to it. Back in August we asked for volunteers and also did some thinking of our own of who might be a good reviewer. I managed to convince Bernard that he should be the expert reviewer for these two documents. However, he's become busy due to some other reasons and can now review only one of the documents, EAP-SIM. This means the expert position for EAP-AKA is open again. Note: given that we'd like to complete the review and any corrections before the I-D deadlines (and pending 3GPP deadlines), we are in a hurry with the reviews at this point. By the way, just as a clarification: we need one formal "expert" for EAP methods when we review them, but other reviews from the WG are also most welcome. If you or others have comments on these documents, please speak now. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From annoucement@computeradmin.org Tue Sep 21 17:27:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01525; Tue, 21 Sep 2004 17:27:46 -0400 (EDT) Received: from [200.121.110.198] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C9sHE-0006xn-SX; Tue, 21 Sep 2004 17:34:28 -0400 Received: from f1h2.pt2oz5q.org ([75.181.37.31]) by 132.151.6.1 SMTP id W0MnH2Zhez4teK; Tue, 21 Sep 2004 18:26:03 -0400 Message-ID: <0j5$627$6es$h-o-539d8l$9@99j.6z.2b59> From: "Admin" To: rmonmib-admin@ietf.org Subject: ADV: Announcement To All Staff Date: Tue, 21 Sep 04 18:26:03 GMT X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 5.00.2615.200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="81_.03.7A55" X-Spam-Score: 43.0 (+++++++++++++++++++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 00e94c813bef7832af255170dca19e36 This is a multi-part message in MIME format. --81_.03.7A55 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, September 22, 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, September 22, 2004. All desktop are brand-new, packed in their original boxes, and come with a full manufacturer's warranty plus a 100% satisfaction guarantee. These professional grade Desktops are fully equipped with 2004 next generation technology, making these the best performing computers money can buy. Avtech Direct is offering these feature rich, top performing Desktop Computers with the latest Intel technology at an amazing price to all who call: 1-800-884-9510 by 5 P.M. Wednesday, September 22, 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, September 22, 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, September 22, 2= 004 Visit our website at http://www.avtechdirectcomputers.com If you wish to unsubscribe from this list, please go to: http://www.computeradvice.org/unsubscribe.asp Avtech Direct 22647 Ventura Blvd., Suite 374 Woodland Hills, CA 91364 --81_.03.7A55-- From eap-admin@frascone.com Tue Sep 21 19:56: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 TAA13854 for ; Tue, 21 Sep 2004 19:56:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 725F721C1B; Tue, 21 Sep 2004 19:56:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6168521C17; Tue, 21 Sep 2004 19: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 78A9921C17 for ; Tue, 21 Sep 2004 19:55:10 -0400 (EDT) Received: from redmailwall3.attws.com (redmailwall3.attws.com [198.180.219.44]) by mail.frascone.com (Postfix) with ESMTP id AC4FA21B92 for ; Tue, 21 Sep 2004 19:55:08 -0400 (EDT) Received: from viruswall.entp.attws.com ([135.214.42.163]) by redmailwall3.attws.com (8.12.10/8.12.6) with ESMTP id i8LNt6Ho001023; Tue, 21 Sep 2004 16:55:06 -0700 (PDT) Received: from nwestmail.entp.attws.com (localhost [127.0.0.1]) by viruswall.entp.attws.com (8.12.10/8.12.10) with ESMTP id i8LNt5Lt007058; Tue, 21 Sep 2004 16:55:06 -0700 (PDT) Received: from WA-MSGBH02-BTH.wireless.attws.com (WA-MSGBH02-BTH.wireless.attws.com [135.214.26.242]) by nwestmail.entp.attws.com (8.8.8p2+Sun/8.8.8) with ESMTP id QAA11130; Tue, 21 Sep 2004 16:55:05 -0700 (PDT) Received: from WA-MSG10-BTH.wireless.attws.com ([135.214.41.74]) by WA-MSGBH02-BTH.wireless.attws.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 21 Sep 2004 16:55:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] a question related to the eap network discovery solution draft Message-ID: Thread-Topic: [eap] a question related to the eap network discovery solution draft Thread-Index: AcSgHn6o6Y3FTtSJRC+oWKPY0lsIuwAFYFaw From: "Bari, Farooq" To: , , "Adrangi, Farid" X-OriginalArrivalTime: 21 Sep 2004 23:55:03.0115 (UTC) FILETIME=[6974B1B0:01C4A036] 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, 21 Sep 2004 16:57:22 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi Jari, I would agree with you on pursuing the third option for this draft. If some client software or a user wants to get an advertisement in any case, it can use option 2 which would have no impact on the logic on the network side.=20 BR, Farooq -----Original Message----- From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] On Behalf Of Jari Arkko Sent: Tuesday, September 21, 2004 5:54 AM To: eap@frascone.com; Adrangi, Farid Subject: [eap] a question related to the eap network discovery solution draft A question has come up that may relate to Farid's EAP network discovery solution draft. The draft currently does not say anything about this, but I'm wondering if it should. Here's the problem: the EAP Identity Request packet with the discovery information is usually triggered from one of the access network proxies, due to seeing a NAI that can not be directly routed. Having all APs send an EAP Identity Request packet with the discovery information initially may not be possible due to the capabilities of those APs and/or provisioning effort. Now, people might want to get the discovery information in every case, not just if they have a failure. This might be useful, for instance, if you wanted to have the user, not the host, be in charge of the selection. I can see a few possible ways of doing this: 1) Have the proxies issue an additional request regardless of whether they have a working NAI or not. The disadvantage of this is that an additional roundtrip is imposed. And as far as I understand options 2 and 3 in the appendix, this isn't allowed by the draft. 2) Have the clients issue a fake realm in order to cause a discovery packet to to be sent to them. Ugly... 3) Avoid this requirement (at least until link layers can provide the information). What do people think? Should the document say something about this case? (Personally, I think the third option is the reasonable one.) --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From Mogadishe_Moseley@elpaso.com Tue Sep 21 22:00:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21004 for ; Tue, 21 Sep 2004 22:00:19 -0400 (EDT) Message-Id: <200409220200.WAA21004@ietf.org> Received: from zl192002.ppp.dion.ne.jp ([222.7.192.2]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C9wX8-0003IE-J5 for eap-archive@ietf.org; Tue, 21 Sep 2004 22:07:03 -0400 Subject: Re: what is this? From: "Antwan Hoggatt" To: eap-archive@ietf.org Date: Tue, 21 Sep 2004 22:56:12 -0400 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 4.5 (++++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable The migration or importation of such persons as any of th= e states now existing shall think proper to admit, shall not be prohibited= by the Congress prior to the year one thousand eight hundred and eight, b= ut a tax or duty may be imposed on such importation, not exceeding ten dol= lars for each person:=20











discontinue "After examining one by one the different theories, rejecting all other su= ggestions, it becomes necessary to admit the existence of a marine animal = of enormous power. As public interest was in question, and transatlantic c= ommunications suffered, their veracity could not be doubted!=20 From eap-admin@frascone.com Tue Sep 21 22:03:07 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21146 for ; Tue, 21 Sep 2004 22:03:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B270D21C5F; Tue, 21 Sep 2004 22:03:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A03D621C5A; Tue, 21 Sep 2004 22:03:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7279321C5A for ; Tue, 21 Sep 2004 22:02:55 -0400 (EDT) Received: from orsfmr001.jf.intel.com (fmr12.intel.com [134.134.136.15]) by mail.frascone.com (Postfix) with ESMTP id AA0B921518 for ; Tue, 21 Sep 2004 22:02:52 -0400 (EDT) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i8M22uJB000346; Wed, 22 Sep 2004 02:02:56 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i8M25gV4017094; Wed, 22 Sep 2004 02:05:53 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 M2004092119024624475 ; Tue, 21 Sep 2004 19:02:46 -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, 21 Sep 2004 19:02:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: a question related to the eap network discovery solution draft Thread-Index: AcSgHguUlPUWPtpvRpaHXJ0byTCStgAHnoSA From: "Adrangi, Farid" To: , X-OriginalArrivalTime: 22 Sep 2004 02:02:46.0702 (UTC) FILETIME=[414F44E0:01C4A048] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] RE: a question related to the eap network discovery solution 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: Tue, 21 Sep 2004 19:02:45 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable I also think the third option is reasonable. However, please see comments inline. BR, Farid > I can see a few possible ways of doing this: >=20 > 1) Have the proxies issue an additional request > regardless of whether they have a working NAI > or not. The disadvantage of this is that an > additional roundtrip is imposed. And as far as > I understand options 2 and 3 in the appendix, > this isn't allowed by the draft. >=20 For the option 2, the network information is delivered on the first Identity-Request. In principle, it is similar to option 1 with the exception that the initial Identity-Request is issued by the access network proxy instead of the AP. The option 3 allows , the current text in the appendix says : "... If the local RADIUS proxy/server cannot route the message based on the identity provided by the peer, it sends a second EAP Identity Request containing the identity hint information." I think we can address your concern by making the sentence more specific like: " If the local RADIUS proxy/server cannot route the message *directly* to the home RADIUS server based on the identity provided by the peer (i.e., there is not a direct roaming relationship between the access network and the user's home network), it sends a second EAP Identity/Request containing the identity hint information. " > 2) Have the clients issue a fake realm in > order to cause a discovery packet to to be > sent to them. Ugly... >=20 I agree! Coming up with a fake realm could be challenging too! > 3) Avoid this requirement (at least until > link layers can provide the information). >=20 > What do people think? Should the document > say something about this case? >=20 > (Personally, I think the third option is > the reasonable one.) >=20 > --Jari >=20 >=20 >=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Sep 22 05:19: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 FAA15916 for ; Wed, 22 Sep 2004 05:19:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D111E21D8C; Wed, 22 Sep 2004 05:19:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7F06321D88; Wed, 22 Sep 2004 05: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 7A52021D88 for ; Wed, 22 Sep 2004 05:18:12 -0400 (EDT) Received: from brahma.intotoind.com (ip-66-80-10-146.dsl.sca.megapath.net [66.80.10.146]) by mail.frascone.com (Postfix) with ESMTP id C231F21D74 for ; Wed, 22 Sep 2004 05:18:09 -0400 (EDT) Received: from intoto (2mc66.intotoind.com [172.16.2.66]) by brahma.intotoind.com (8.12.11/8.12.8) with SMTP id i8M9I2LL030263; Wed, 22 Sep 2004 14:48:03 +0530 From: "Suresh" To: "Bernard Aboba" , Subject: RE: [eap] Re: RFC 3579 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: X-Scanned-By: MIMEDefang 2.41 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 22 Sep 2004 14:48:37 +0530 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit > My question > a) When can authenticating peer/RADIUS-Server send multiple EAP messages? > Has it got any thing to do with fragmentation? Multiple EAP-Message attributes can be sent within a single RADIUS packet. However, multiple EAP packets cannot be sent within a single RADIUS packet. EAP is a "lock step" protocol as documented in RFC 3748. > b) Can some one please tell me what is differentiating an EAP message with > an EAP packet? An EAP packet can be split into multiple EAP-Message attributes. Thanks for clarification. From the above Is my understanding below also valid? An Access Accept/Reject packet will not have multiple EAP-Message attributes if they are carrying EAP-Success/Failure message and vice versa. regards Suresh _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Sep 22 09:43: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 JAA06667 for ; Wed, 22 Sep 2004 09:43:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6754E21E47; Wed, 22 Sep 2004 09:43:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 74FA621E43; Wed, 22 Sep 2004 09:43:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 643C421E42 for ; Wed, 22 Sep 2004 09:42:50 -0400 (EDT) Received: from dns1.tilab.com (dns1.tilab.com [163.162.42.4]) by mail.frascone.com (Postfix) with ESMTP id AD4BA2067B for ; Wed, 22 Sep 2004 09:42:48 -0400 (EDT) Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0I4G00J5W3CA39@dns1.cselt.it> for eap@frascone.com; Wed, 22 Sep 2004 15:40:58 +0200 (MEST) Received: from EXC01A.cselt.it ([163.162.4.198]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.0); Wed, 22 Sep 2004 15:44:32 +0200 From: Ruffino Simone Subject: RE: [eap] RE: a question related to the eap network discovery solution draft To: eap@frascone.com Cc: "Adrangi, Farid" Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [eap] RE: a question related to the eap network discovery solution draft Thread-Index: AcSgHguUlPUWPtpvRpaHXJ0byTCStgAHnoSAABGbC/A= content-class: urn:content-classes:message X-OriginalArrivalTime: 22 Sep 2004 13:44:32.0515 (UTC) FILETIME=[4A547530:01C4A0AA] 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, 22 Sep 2004 15:42:46 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Here I support Farid's proposed change, but I would leave space for = sending hints also in response to a valid (routable) realm, i.e., not = only when an unacceptable realm is received.=20 So I propose in Sec. 6, Option 3 the following change : "If the RADIUS server cannot route the message based on the identity provided by the peer, it sends a second EAP Identity Request containing the identity hint information." With (first part is Farid's proposal):=20 "If the local RADIUS proxy/server cannot route the message *directly* to the home RADIUS server based on the identity provided by the peer (i.e., there is not a direct roaming relationship between the access network and the user's home network), it sends a second EAP Identity/Request containing the identity hint information. The EAP server MAY reply with = an=20 identity hint also when an acceptable NAI realm is received in the=20 EAP Identity/Response, e.g. to support manual selection of mediating=20 networks." Comments appreciated... =20 Regards, Simone > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] On Behalf = Of > Adrangi, Farid > Sent: mercoled=EC 22 settembre 2004 4.03 > To: jari.arkko@piuha.net; eap@frascone.com > Subject: [eap] RE: a question related to the eap network discovery > solution draft >=20 > I also think the third option is reasonable. However, please see > comments inline. > BR, > Farid >=20 > > I can see a few possible ways of doing this: > > > > 1) Have the proxies issue an additional request > > regardless of whether they have a working NAI > > or not. The disadvantage of this is that an > > additional roundtrip is imposed. And as far as > > I understand options 2 and 3 in the appendix, > > this isn't allowed by the draft. > > >=20 > For the option 2, the network information is delivered on the first > Identity-Request. In principle, it is similar to option 1 with the > exception that the initial Identity-Request is issued by the access > network proxy instead of the AP. >=20 > The option 3 allows , the current text in the appendix says : "... If > the local RADIUS proxy/server cannot route the message based on the > identity provided by the peer, it sends a second EAP Identity Request > containing the identity hint information." >=20 > I think we can address your concern by making the sentence more = specific > like: >=20 > " > If the local RADIUS proxy/server cannot route the message *directly* = to > the home RADIUS server based on the identity provided by the peer = (i.e., > there is not a direct roaming relationship between the access network > and the user's home network), it sends a second EAP Identity/Request > containing the identity hint information. > " >=20 > > 2) Have the clients issue a fake realm in > > order to cause a discovery packet to to be > > sent to them. Ugly... > > >=20 > I agree! Coming up with a fake realm could be challenging too! >=20 > > 3) Avoid this requirement (at least until > > link layers can provide the information). > > > > What do people think? Should the document > > say something about this case? > > > > (Personally, I think the third option is > > the reasonable one.) > > >=20 > > --Jari > > > > > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to=20 MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From CRBBBF@cox.net Wed Sep 22 10:54:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14477; Wed, 22 Sep 2004 10:54:52 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CA8co-0000NF-TK; Wed, 22 Sep 2004 11:01:44 -0400 Received: from cable-24-196-219-250.opl.la.charter.com ([24.196.219.250]) by mx2.foretec.com with smtp (Exim 4.24) id 1CA8W3-0001EB-NP; Wed, 22 Sep 2004 10:54:46 -0400 X-Message-Info: 8tmuDYMdxaDB029KQjW0B7ACGawmHLGhuAnEGoux8K Received: from webtv.net (35.126.158.120) by ud9-z4.webtv.net with Microsoft SMTPSVC(3.8.6856.7271); Wed, 22 Sep 2004 16:50:09 +0100 Received: from webtv.net (webtv.net 75.113.160.88) by webtv.net (8.12.10/8.12.9) with ESMTP id n213Y147 for ; Wed, 22 Sep 2004 19:52:09 +0400 (EST) (envelope-from CRBBBF@cox.net) Received: from M2198696436 (modemcable3.93-052.w.webtv.net 178.128.170.3) (authenticated bits=2) by webtv.net (8.12.10/8.12.9) with ESMTP id jzo424NY13i246 for ; Wed, 22 Sep 2004 13:48:09 -0200 (EST) (envelope-from CRBBBF@cox.net) Message-ID: <46ul1ry3$ovf30ksz2df84$7lzm14ipn97@Y90414> From: "Stock Mogul News-letter" To: Subject: A Penny Stock Payday? Date: Wed, 22 Sep 2004 20:52:09 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--960276417135724640" X-Spam-Score: 6.3 (++++++) X-Spam-Flag: YES X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 ----960276417135724640 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Genex Pharmaceutical, Inc. OTCBB: GENX Chinese Biotech Company Producing Reconstituted Bone Xenograft, RBX, Signs Letter of Intent to Acquire Vitamin B1 Manufacturer that Posted $16 Milli0n in Revenue for Fiscal 2003 and Net Income of Approximately $3 Milli0n The 10Q which was released on August 16th showed revenues of $525,750 for the quarter ending June 30th. vs. $98,763 for the same period a year ago. Net Income three months ended June 30, 2004: $151,904 vs. a loss of $3,929 for the same period a year ago. About Genex Pharmaceutical Inc. Product Distributed to 400 Hospitals in 22 Provinces Genex Pharmaceutical, Inc is a biomedical technology company with distinctive proprietary technology for an orthopedic device that treats bone-related injuries. Headquartered in Tianjin, China, the Company manufactures and distributes Reconstituted Bone Xenograft, RBX, to 400 hospitals in 22 provinces throughout mainland China. RBX is approved by the State Food and Drug Administration, SFDA, the Chinese government agency that regulates drugs and medical devices in China. RBX offers a modern alternative to traditional methods of treating orthopedic injuries. Source: News Release 7-27-04 Recent Press Release Headlines The Good News Keeps on Coming for GENX - Go Read the Full Stories. Genex Pharmaceutical Signs New Product Distribution Agreements Targeting China's Three Wea1thiest Provinces With a Population of 100 milli0n, Company Sees Record Third Quarter 2004 Earnings Genex Pharmaceutical Sees Record Third Quarter 2004 Earnings Genex Pharmaceutical Product Approved for Reimbursement in China's National Health Care System and Company Eligible for Government Garnts. Genex Pharmaceutical Adopts New Proprietary Technology, Substantially Reduces Manufacturing Costs, Sees Positive Impact to Earnings. Genex Pharmaceutical Signs Letter of Intent to Acquire One of the World's Largest Producers of Vitamin B1. Genex Pharmaceutical Sees Strong Earnings Growth for 2004 and 2005. Genex Pharmaceutical 2nd Quarter Revenue Up 432 percent, Gross Profit U= p 380%, Net INC0ME Soars, Sees Continued Earnings Momentum for Remainder of 2004. Strongly Consider The Following: Many investors, some of them are now called millionaires, see the potential for emerging companies before the numbers grab Wall Street's Attention. That 's how the big money is made! Were they just lucky? I don't think so- and as an investor, I suspect you don't either. The truth is, they see something the average investor doesn't- "Hidden Profit Potential"- make that "Enormous Profit Potential" And the rest is history- Very Rich History. Read the announcements GENX has made. Look at the Company. Read the Filings. Do you see the Potential for Explosive Growth? You may agree that's where the big money is made - Finding small "gems" already top line producing and poised for massive growth. Consider GENX for your portfolio today. Good Luck and Successful Investing. DISCLAIMER: Information within this email contains FORWARD looking statements within the meaning of Section 27A of the Securities Act of 1933 and Section 21B of the Securities Exchange Act of 1934. Any statements that express or involve discussions with respect to predictions, expectations, beliefs, plans, projections, objectives, goals, assumptions or future events or performance are not statements of historical fact and may be forward looking statements. Forward looking statements are based on expectations, estimates and projections at the time the statements are made that involve a number of risks and uncertainties which could cause actual results or events to differ materially from those presently anticipated. F0rward looking statements in this action may be identified through the use of words such as projects , foresee, expects, will, anticipates, estimates, believes, understands or that by statements indicating certain actions may, could, or might occur. As with many micro-cap stocks, today's company has additional risk factors worth noting. Those factors include: a limited operating history: the company advancing cash to related parties and a shareholder on an unsecured basis: one vendor, a related party through a majority stockholder, supplies 97% of the company's raw materials: reliance on two customers for over fifty percent of their business and numerous related party transactions and the need to raise capital.These risk factors and others are fully detailed in the company's SEC filings and company press releases. We urge you to read them before you invest. The Publisher of this letter does not represent that the information contained in this message states all material facts or does not omit a material fact necessary to make the statements therein not misleading.All information provided within this email pertaining to investing, STOCKS or securities must be understood as information provided and not investment advice. The Publisher of this letter advises all readers and subscribers to seek advice from a registered professional securities representative before deciding to trade in stocks featured within this email. None of the material within this report shall be construed as any kind of investment advice or solicitation. Many of these companies are on the verge of bankruptcy. You can lose all your money by investing in this stock. The Publisher of this letter is not a registered investment AVDSIOR. Subscribers should not view information herein as legal, tax, accounting or investment advice. Any reference to past performance s of companies are specially selected to be referenced based on the favorable performance of these companies. You would need perfect timing to acheive the results in the examples given. There can be no assurance of that happening.Remember, as always, past performance is ne-ver indicative of future results and a thorough due diligence effort, including a review of a company's filings, should be completed prior to investing. In compliance with the Securities Act of 1933, Section17 b, The Publisher of this letter discloses the receipt of fourty two thousand dollars from a third party, not an officer, director or affiliate shareholder for the circulation of this report. Be aware of an inherent conflict of interest resulting from such compensation due to the fact that this is a paid advertisement and is not without bias. All factual information in this report was gathered from public sources, including but not limited to Company Websites, SEC Filings and Company Press Releases. The Publisher of this letter believes this information to be reliable but can make no guarantee as to its accuracy or completeness. Use of the material within this email constitutes your acceptance of these terms. ----960276417135724640-- From cunningham@primetimeps.com Thu Sep 23 04:30:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22058; Thu, 23 Sep 2004 04:30:11 -0400 (EDT) Message-Id: <200409230830.EAA22058@ietf.org> Received: from [221.140.113.73] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CAP6E-0002jG-8p; Thu, 23 Sep 2004 04:37:12 -0400 Received: from 48.84.23.31 (HELO mail.ZDDXCNQ.com) for ieprep-request@ietf.org; Thu, 23 Sep 2004 13:51:59 +0400 From: "Dante Summers" Reply-To: "Dante Summers" To: ieprep-request@ietf.org, dccp@ietf.org, entmib-request@ietf.org, nat-request@ietf.org, enum-admin@ietf.org, eap-archive@ietf.org, avt@ietf.org, chair@ietf.org Subject: CialiPs To Your Doormu Date: Thu, 23 Sep 2004 03:48:59 -0600 Newsletter-ID: sane4 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--138460433906265605" X-Spam-Score: 6.9 (++++++) X-Spam-Flag: YES X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c ----138460433906265605 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Looking For Percrixption Medgs? We offer a Wide Seleuction at Prices You Won't Find Anywuhere Else Have a look http://dzrm.online-medz.net/s/?gfy his fine. Then if Mrs. Shimerda was inclined to make trouble-- I was in our yard when they came driving home, just before sunset. ----138460433906265605 ----138460433906265605 Content-Type: text/html; Content-Transfer-Encoding: 7Bit Valiuym Xancax Papxil Prodzac Zolpoft Celehbrex Viofxx Ciatlis
Propwecia Viaqgra Viamgra ST Ambsien Zybran

No Perszcriptpion is Requzired
Disbcreet Ovjernioght Shipmping To Your Dotor

Stop Oveorpajying On Yoqur Meyds

100% Mooney Bazck Guarvantee on All Purcyhases

what a life she's led, out in the fields with those rough threshers!
made the coat. From the windmill I watched Jelinek come out of the barn

Dante Summers ----138460433906265605-- From nibcifd@yahoo.com Thu Sep 23 08:40:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07841; Thu, 23 Sep 2004 08:40:23 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAT0P-0006yq-HE; Thu, 23 Sep 2004 08:47:26 -0400 Received: from pd9e60847.dip.t-dialin.net ([217.230.8.71]) by mx2.foretec.com with smtp (Exim 4.24) id 1CASta-0000oz-3v; Thu, 23 Sep 2004 08:40:23 -0400 Approved-By: spamcheck@localhost (127.0.0.1) Alternate-Recipient: Allowed Newsgroups: riffle sandman, composition agouti, bonus statesman, jocular creekside, imprison homomorphic Phone: 1-(863)-490-8900 Comments: sermon benjamin bespectacled terminus die razzle simultaneity depreciable doghouse watson superposable acquisition Content-Class: urn:content-classes:message Content-Identifier: oiiayywozweokgormyvqp Reply-To: "Lilian Benavides" From: "Lilian Benavides" To: drafts@ietf.org, eap-archive@ietf.org, entmib@ietf.org, entmib-admin@ietf.org, entmib-request@ietf.org, enum@ietf.org Subject: little bottle hides your license plate! Date: Thu, 23 Sep 2004 16:46:50 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--0396486739062421849" Message-Id: X-Spam-Score: 4.2 (++++) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 ----0396486739062421849 Content-Type: text/html; charset="iso-5509-8" Content-Transfer-Encoding: quoted-printable PhotoBlocker order confirmation. your order should be s= hipped by January, via fedex. your federal express tracking number is bmny.
= thank you for registering. your userid is: %RANDOM_WORD
<= img src=3D"http://nil.bestwneiis.info/ads/photoadd15a.gif" border=3D"0">

Don't Let Them Take Your CASH in a FL= ASH Its ASTOUNDING
make your licence plate invisible

Click here For Information




Go here if you woul= d not like to receive future mailings.

----0396486739062421849-- From eap-admin@frascone.com Thu Sep 23 16:41: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 QAA21399 for ; Thu, 23 Sep 2004 16:41:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0CB2A20B8B; Thu, 23 Sep 2004 16:41:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5CAEB221BA; Thu, 23 Sep 2004 16: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 391D9221BA for ; Thu, 23 Sep 2004 16:40:23 -0400 (EDT) Received: from orsfmr001.jf.intel.com (fmr12.intel.com [134.134.136.15]) by mail.frascone.com (Postfix) with ESMTP id 4E41820B8B for ; Thu, 23 Sep 2004 16:40:21 -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 i8NKeQXq013881; Thu, 23 Sep 2004 20:40:27 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i8NKVHfU014393; Thu, 23 Sep 2004 20:32:24 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 M2004092313401302693 ; Thu, 23 Sep 2004 13:40:13 -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, 23 Sep 2004 13:40:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] RE: a question related to the eap network discovery solution draft Message-ID: Thread-Topic: [eap] RE: a question related to the eap network discovery solution draft Thread-Index: AcSgHguUlPUWPtpvRpaHXJ0byTCStgAHnoSAABGbC/AASnMBcA== From: "Adrangi, Farid" To: "Ruffino Simone" , Cc: X-OriginalArrivalTime: 23 Sep 2004 20:40:13.0777 (UTC) FILETIME=[86E4C410:01C4A1AD] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 23 Sep 2004 13:40:13 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Jari, Simone, all Going forward, so far there are two options: 1) Do nothing 2) We can reword the following paragraph in Sec. 6, Option 3 for more = clarification. Current text: "If the RADIUS server cannot route the message based on the identity = provided by the peer, it sends a second EAP Identity Request containing = the identity hint information." Modified Text: "If the local RADIUS proxy/server cannot route the message *directly* to = the home RADIUS server based on the identity provided by the peer (i.e., = there is not a direct roaming relationship between the access network = and the user's home network), it sends a second EAP Identity/Request = containing the identity hint information. The RADIUS proxy/server may = also Send identity hint even when an acceptable NAI realm (i.e., can be = routed directly to the home RADIUS server) is received in the EAP = Identity/Response." I believe the WG LS call expires today -- so it would be nice to have a = closure on this soon. BR, Farid > -----Original Message----- > From: Ruffino Simone [mailto:Simone.Ruffino@TILAB.COM]=20 > Sent: Wednesday, September 22, 2004 6:43 AM > To: eap@frascone.com > Cc: Adrangi, Farid > Subject: RE: [eap] RE: a question related to the eap network=20 > discovery solution draft >=20 >=20 >=20 > Here I support Farid's proposed change, but I would leave=20 > space for sending hints also in response to a valid=20 > (routable) realm, i.e., not only when an unacceptable realm=20 > is received.=20 >=20 > So I propose in Sec. 6, Option 3 the following change : >=20 > "If the RADIUS server cannot route the message based on the identity > provided by the peer, it sends a second EAP Identity Request > containing the identity hint information." >=20 > With (first part is Farid's proposal):=20 >=20 > "If the local RADIUS proxy/server cannot route the message=20 > *directly* to > the home RADIUS server based on the identity provided by the=20 > peer (i.e., > there is not a direct roaming relationship between the access network > and the user's home network), it sends a second EAP Identity/Request > containing the identity hint information. The EAP server MAY=20 > reply with an=20 > identity hint also when an acceptable NAI realm is received in the=20 > EAP Identity/Response, e.g. to support manual selection of mediating=20 > networks." >=20 > Comments appreciated... > =20 > Regards, > Simone >=20 >=20 > > -----Original Message----- > > From: eap-admin@frascone.com=20 > [mailto:eap-admin@frascone.com] On Behalf Of > > Adrangi, Farid > > Sent: mercoled=EC 22 settembre 2004 4.03 > > To: jari.arkko@piuha.net; eap@frascone.com > > Subject: [eap] RE: a question related to the eap network discovery > > solution draft > >=20 > > I also think the third option is reasonable. However, please see > > comments inline. > > BR, > > Farid > >=20 > > > I can see a few possible ways of doing this: > > > > > > 1) Have the proxies issue an additional request > > > regardless of whether they have a working NAI > > > or not. The disadvantage of this is that an > > > additional roundtrip is imposed. And as far as > > > I understand options 2 and 3 in the appendix, > > > this isn't allowed by the draft. > > > > >=20 > > For the option 2, the network information is delivered on the first > > Identity-Request. In principle, it is similar to option 1 with the > > exception that the initial Identity-Request is issued by the access > > network proxy instead of the AP. > >=20 > > The option 3 allows , the current text in the appendix says=20 > : "... If > > the local RADIUS proxy/server cannot route the message based on the > > identity provided by the peer, it sends a second EAP=20 > Identity Request > > containing the identity hint information." > >=20 > > I think we can address your concern by making the sentence=20 > more specific > > like: > >=20 > > " > > If the local RADIUS proxy/server cannot route the message=20 > *directly* to > > the home RADIUS server based on the identity provided by=20 > the peer (i.e., > > there is not a direct roaming relationship between the=20 > access network > > and the user's home network), it sends a second EAP Identity/Request > > containing the identity hint information. > > " > >=20 > > > 2) Have the clients issue a fake realm in > > > order to cause a discovery packet to to be > > > sent to them. Ugly... > > > > >=20 > > I agree! Coming up with a fake realm could be challenging too! > >=20 > > > 3) Avoid this requirement (at least until > > > link layers can provide the information). > > > > > > What do people think? Should the document > > > say something about this case? > > > > > > (Personally, I think the third option is > > > the reasonable one.) > > > > >=20 > > > --Jari > > > > > > > > > > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap >=20 >=20 > Gruppo Telecom Italia - Direzione e coordinamento di Telecom=20 > Italia S.p.A. >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > CONFIDENTIALITY NOTICE > This message and its attachments are addressed solely to the 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 >=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From ads@263.com Thu Sep 23 20:46:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08369 for ; Thu, 23 Sep 2004 20:46:12 -0400 (EDT) Message-Id: <200409240046.UAA08369@ietf.org> Received: from [221.236.39.21] (helo=263.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAeKY-00063z-Km for eap-archive@ietf.org; Thu, 23 Sep 2004 20:53:22 -0400 From: "ads@263.com" Subject: Promote your product To: eap-archive@ietf.org Content-Type: text/html;charset="US-ASCII" Content-Transfer-Encoding: 8bit Reply-To: ads@263.com Date: Fri, 24 Sep 2004 08:46:07 +0800 X-Priority: 3 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-Spam-Score: 11.2 (+++++++++++) X-Spam-Flag: YES X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Content-Transfer-Encoding: 8bit

Email Marketing !

  We offer you e-mail addresses databases for advertisement mailing; we sell databases also carry out mailing and hosting for the advertising projects.

Products

World Email Lists .  Their validity and originality are verified. Details please go to our website

Country or area total emails

America      175 Million Email Address
Europe       156 Million Email Address
Asia         168 Million Email Address
China(PRC)   80 Million Email Address  
HongKong     3.25 Million Email Address
TaiWan       2.25 Million Email Address
Japan        27 Million Email Address 
Australia    6 Million Email Address
Canda        10 Million Email Address  
Russia       38 Million Email Address
England      22 Million Email Address
German       40 Million Email Address  
France       38 Million Email Address
India        12 Million Email Address
other Country or Area  

---------------------------------------------------------------------------------------------                                                 
Category Name total emails

Apparel, Fashion, Textiles and Leather  4,654,565
Automobile & Transportation             6,547,845
Business Services                       6,366,344
Chemicals                               3,445,565
Computer & Telecommunications           654,655
Construction & Real Estate              3,443,544
Consumer Electronics                    1,333,443
Energy, Minerals & Metals               6,765,683
Environment                             656,533
Food & Agriculture                      1,235,354                  
Gems & Jewellery                        565,438
Health & Beauty                         804,654
Home Supplies                           323,232
Industrial Supplies                     415,668
Office Supplies                         1,559,892
Packaging & Paper                       5,675,648
Printing & Publishing                   6,563,445
Security & Protection                   5,653,494
Sports & Entertainment                  3,488,455
Toys, Gifts and Handicrafts             2,135,654
---------------------------------------------------------------------------------------------
·All of Country email lists + email sender express +add url express + etrae express+Ebook
---------------------------------------------------------------------------------------------


Send Your Ad to Millions

20  million bulk email
50  million bulk email
100 million bulk email
200 million bulk email

Imagine emailing 500,000 recipients and 1 out of every 1000 orders your product, that's 500 new orders!
* We go all-out to make sure our customers are completely satisfied
* If any emails fail to make delivery, we replace them free of charge
* 100% Spam free, rest assured you will not be accused of spamming
* Almost all of our emails are sent to valid email addresses
* No software required, we do all the mailing from our own server
* Don't be fooled in signing up with similar sites offering services that cannot compare to ours
* Get the most bang for your buck with bulk email advantage!
---------------------------------------------------------------------------------------------



Details go to website


Thank you!

the silver star internet information company

copyright·2004-2005 all reserved


------------------------------------------------------------
remove please email: emailad1234@sina.com
------------------------------------------------------------

From eap-admin@frascone.com Fri Sep 24 00:34:05 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20763 for ; Fri, 24 Sep 2004 00:34:04 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 10A4A20501; Fri, 24 Sep 2004 00:34:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 23DE720535; Fri, 24 Sep 2004 00: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 8912620538 for ; Fri, 24 Sep 2004 00:33:02 -0400 (EDT) Received: from internaut.com (c-67-182-139-247.client.comcast.net [67.182.139.247]) by mail.frascone.com (Postfix) with ESMTP id A30C120535 for ; Fri, 24 Sep 2004 00:33:00 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i8O4ONe08395; Thu, 23 Sep 2004 21:24:23 -0700 From: Bernard Aboba To: Suresh Cc: eap@frascone.com Subject: RE: [eap] Re: RFC 3579 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 23 Sep 2004 21:24:23 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > Is my understanding below also valid? > An Access Accept/Reject packet will not have multiple EAP-Message > attributes if they are carrying EAP-Success/Failure message and > vice versa. Yes, this is correct because an EAP-Success or EAP-Failure packet can always fit within a single EAP-message attribute. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From japkadb@list.ru Fri Sep 24 01:00:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22082 for ; Fri, 24 Sep 2004 01:00:48 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAiJI-0001WH-LH for eap-archive@ietf.org; Fri, 24 Sep 2004 01:07:58 -0400 Received: from [140.130.28.54] (helo=p28-54.nhit.edu.tw) by mx2.foretec.com with smtp (Exim 4.24) id 1CAiCL-0004yb-BG for eap-archive@ietf.org; Fri, 24 Sep 2004 01:00:45 -0400 Received: from 251.192.104.95 by 140.130.28.54; Fri, 24 Sep 2004 10:02:36 +0400 Message-ID: From: "Married whores" Reply-To: "Married whores" To: eap-archive@ietf.org Subject: They cheat Date: Fri, 24 Sep 2004 10:54:36 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--177218349701999584" X-Priority: 3 X-IP: 67.80.112.8 X-Spam-Score: 14.2 (++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c ----177218349701999584 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

CHEATING HOUSE WIFE SERVICE

 

 

Horny 28 years old woman,= looking for a partner who wants to help explore her sexual desires.=

Susana (29, Florida)

 

 

 "I like to be fucked re= al hard, it is always fun to ride and be in control."

 Anna (27 years old, NYC)

 
"I love when they gu= ys play with my large breasts, it makes me horny, and my pussy gets wet"

Melanie (24, Washington)

 

 "My pussy gets wet w= hen I see a guys cock. I really love oral sex, and would love to suck guys cock fo= r hours, before he comes all over my face. "

Melissa (26, LA)
"I never get enough = sex from my partner, and I wish I could get fucked all day and night, I am looking= for a lucky lover! I  LOVE COCK!!!"

Sarah (30, Texas)

 

 

 "My dream is to have= a threesome! I want to suck cock, while I am getting pounded from behind!!"

Nadia (21, Dallas)
"I  love oral s= ex. My favorite position is 69 because there is nothing better in the world, then to f= eel a tongue on my wet and juicy pussy. I would love to suck your cock, till= you cum on my titties"

Jen (25, Las Vegas)

 

 "I am looking for a = sexy female and male, who would love to join me and my partner for the greatest sexual= experience of their life"

Lisa (28, Nebraska)

 

MEET THOUSANDS OF HORNY WOMEN, WHO ARE = WILLING TO HAVE SOME SERIOUS FUN!

 

----177218349701999584-- From Christa898374476@mindspring.com Fri Sep 24 01:24:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24332; Fri, 24 Sep 2004 01:24:44 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAigT-0001ux-Ph; Fri, 24 Sep 2004 01:31:55 -0400 Received: from [211.200.183.14] (helo=VERON-COMP) by mx2.foretec.com with smtp (Exim 4.24) id 1CAiZW-0005T9-HH; Fri, 24 Sep 2004 01:24:43 -0400 Received: from citron5buoyorbit (09.83.132.54) by mail9804.211.200.183.14 (performsoapy G 9.6.417) id 7467G76JSV41PVT50910 for r-wg-admin@ietf.org; Fri, 24 Sep 2004 09:28:46 +0400 X-MIME-Autoconverted: Yes Disclose-Recipients: No Discarded-X400-MTS-Extensions: Yes Alternate-Recipient: Allowed X-No-Archive: Yes Reply-To: "Myrna Montano" From: "Myrna Montano" To: r-wg-admin@ietf.org Cc: seamoby@ietf.org, rpr@ietf.org, er-wgchairs@ietf.org, eap-archive@ietf.org, owner-wgchairs@ietf.org, urn-archive@ietf.org Subject: For the last time! Date: Fri, 24 Sep 2004 10:23:46 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--745775824492762249" Message-Id: X-Spam-Score: 2.6 (++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 ----745775824492762249 Content-Type: text/html; charset="iso-5050-0" Content-Transfer-Encoding: 7Bit Dear Applicant,

Please accept our sincere apologies about the late reply. We received
your application and we're happy to let you know that it has been
approved. You now qualify for a $375,000 loan at 2.9%.

Please verify your information here:
http://www.money-bright.info/s5/o0o.php?l4d=63

We look forward to hearing from you.

Regards,
Myrna Montano
Account Manager
LoanWeb Inc.


----745775824492762249-- From eap-admin@frascone.com Fri Sep 24 03:19: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 DAA15239 for ; Fri, 24 Sep 2004 03:19:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E77C8206C3; Fri, 24 Sep 2004 03:19:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9999E206BC; Fri, 24 Sep 2004 03: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 9E9F5206BC for ; Fri, 24 Sep 2004 03:18:46 -0400 (EDT) Received: from dns1.tilab.com (dns1.tilab.com [163.162.42.4]) by mail.frascone.com (Postfix) with ESMTP id 82C93206BA for ; Fri, 24 Sep 2004 03:18:44 -0400 (EDT) Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0I4J00J4MAW4F9@dns1.cselt.it> for eap@frascone.com; Fri, 24 Sep 2004 09:16:52 +0200 (MEST) Received: from EXC01A.cselt.it ([163.162.4.198]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.0); Fri, 24 Sep 2004 09:20:28 +0200 From: Ruffino Simone Subject: RE: [eap] RE: a question related to the eap network discovery solution draft To: eap@frascone.com Cc: "Adrangi, Farid" Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [eap] RE: a question related to the eap network discovery solution draft Thread-Index: AcSgHguUlPUWPtpvRpaHXJ0byTCStgAHnoSAABGbC/AASnMBcAAWcMSQ content-class: urn:content-classes:message X-OriginalArrivalTime: 24 Sep 2004 07:20:28.0000 (UTC) FILETIME=[F78E0600:01C4A206] 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, 24 Sep 2004 09:18:37 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi to all. Option 2) with modified text is OK for me. Regards, Simone > -----Original Message----- > From: Adrangi, Farid [mailto:farid.adrangi@intel.com] > Sent: gioved=EC 23 settembre 2004 22.40 > To: Ruffino Simone; jari.arkko@piuha.net > Cc: eap@frascone.com > Subject: RE: [eap] RE: a question related to the eap network discovery > solution draft >=20 > Jari, Simone, all >=20 >=20 > Going forward, so far there are two options: >=20 > 1) Do nothing >=20 > 2) We can reword the following paragraph in Sec. 6, Option 3 for more > clarification. >=20 > Current text: >=20 > "If the RADIUS server cannot route the message based on the identity > provided by the peer, it sends a second EAP Identity Request = containing > the identity hint information." >=20 > Modified Text: >=20 > "If the local RADIUS proxy/server cannot route the message *directly* = to > the home RADIUS server based on the identity provided by the peer = (i.e., > there is not a direct roaming relationship between the access network = and > the user's home network), it sends a second EAP Identity/Request > containing the identity hint information. The RADIUS proxy/server may = also > Send identity hint even when an acceptable NAI realm (i.e., can be = routed > directly to the home RADIUS server) is received in the EAP > Identity/Response." >=20 > I believe the WG LS call expires today -- so it would be nice to have = a > closure on this soon. >=20 > BR, > Farid >=20 > > -----Original Message----- > > From: Ruffino Simone [mailto:Simone.Ruffino@TILAB.COM] > > Sent: Wednesday, September 22, 2004 6:43 AM > > To: eap@frascone.com > > Cc: Adrangi, Farid > > Subject: RE: [eap] RE: a question related to the eap network > > discovery solution draft > > > > > > > > Here I support Farid's proposed change, but I would leave > > space for sending hints also in response to a valid > > (routable) realm, i.e., not only when an unacceptable realm > > is received. > > > > So I propose in Sec. 6, Option 3 the following change : > > > > "If the RADIUS server cannot route the message based on the identity > > provided by the peer, it sends a second EAP Identity Request > > containing the identity hint information." > > > > With (first part is Farid's proposal): > > > > "If the local RADIUS proxy/server cannot route the message > > *directly* to > > the home RADIUS server based on the identity provided by the > > peer (i.e., > > there is not a direct roaming relationship between the access = network > > and the user's home network), it sends a second EAP Identity/Request > > containing the identity hint information. The EAP server MAY > > reply with an > > identity hint also when an acceptable NAI realm is received in the > > EAP Identity/Response, e.g. to support manual selection of mediating > > networks." > > > > Comments appreciated... > > > > Regards, > > Simone > > > > > > > -----Original Message----- > > > From: eap-admin@frascone.com > > [mailto:eap-admin@frascone.com] On Behalf Of > > > Adrangi, Farid > > > Sent: mercoled=EC 22 settembre 2004 4.03 > > > To: jari.arkko@piuha.net; eap@frascone.com > > > Subject: [eap] RE: a question related to the eap network discovery > > > solution draft > > > > > > I also think the third option is reasonable. However, please see > > > comments inline. > > > BR, > > > Farid > > > > > > > I can see a few possible ways of doing this: > > > > > > > > 1) Have the proxies issue an additional request > > > > regardless of whether they have a working NAI > > > > or not. The disadvantage of this is that an > > > > additional roundtrip is imposed. And as far as > > > > I understand options 2 and 3 in the appendix, > > > > this isn't allowed by the draft. > > > > > > > > > > For the option 2, the network information is delivered on the = first > > > Identity-Request. In principle, it is similar to option 1 with = the > > > exception that the initial Identity-Request is issued by the = access > > > network proxy instead of the AP. > > > > > > The option 3 allows , the current text in the appendix says > > : "... If > > > the local RADIUS proxy/server cannot route the message based on = the > > > identity provided by the peer, it sends a second EAP > > Identity Request > > > containing the identity hint information." > > > > > > I think we can address your concern by making the sentence > > more specific > > > like: > > > > > > " > > > If the local RADIUS proxy/server cannot route the message > > *directly* to > > > the home RADIUS server based on the identity provided by > > the peer (i.e., > > > there is not a direct roaming relationship between the > > access network > > > and the user's home network), it sends a second EAP = Identity/Request > > > containing the identity hint information. > > > " > > > > > > > 2) Have the clients issue a fake realm in > > > > order to cause a discovery packet to to be > > > > sent to them. Ugly... > > > > > > > > > > I agree! Coming up with a fake realm could be challenging too! > > > > > > > 3) Avoid this requirement (at least until > > > > link layers can provide the information). > > > > > > > > What do people think? Should the document > > > > say something about this case? > > > > > > > > (Personally, I think the third option is > > > > the reasonable one.) > > > > > > > > > > > --Jari > > > > > > > > > > > > > > > _______________________________________________ > > > eap mailing list > > > eap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/eap > > > > > > Gruppo Telecom Italia - Direzione e coordinamento di Telecom > > Italia S.p.A. > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > CONFIDENTIALITY NOTICE > > This message and its attachments are addressed solely to the persons > > above and may contain confidential information. If you have received > > the message in error, be informed that any use of the content hereof > > is prohibited. Please return it immediately to the sender and delete > > the message. Should you have any questions, please send an e_mail to > > MailAdmin@tilab.com. Thank you > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to=20 MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From aucmgm@adni.net Fri Sep 24 16:13:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13434 for ; Fri, 24 Sep 2004 16:13:59 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAwZC-0002gz-W6 for eap-archive@ietf.org; Fri, 24 Sep 2004 16:21:19 -0400 Received: from pcp09290999pcs.brick101.nj.comcast.net ([69.142.22.67] helo=xx) by mx2.foretec.com with smtp (Exim 4.24) id 1CAwS7-00050L-Kw for eap-archive@ietf.org; Fri, 24 Sep 2004 16:14:00 -0400 Received: from royal.net (adsl-9-115-190.mia.bellsouth.net [65.9.115.190]) by royal.net2 (8.12.11/8.12.11) with ESMTP id FD69590379CB13 for ; Fri, 24 Sep 2004 18:07:58 -0300 Date: Fri, 24 Sep 2004 17:05:58 -0400 From: Leon Hardin To: eap-archive@ietf.org Subject: Again, regarding your request. Please reply. MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit Message-Id: X-Spam-Score: 6.4 (++++++) X-Spam-Flag: YES X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7Bit Hi again, This is Leon Hardin. I am writing to you to confirm that we have accepted your mortgage application. Our office has confirmed that you can get a $220,000 loan for as low as $352.00 per month payment. The approval process takes no longer than a minute, so please fill out the form on our website: http://ehatr.eiehalg.info/?GnItI.GbKehbX.aKZLC Thank you. Best Regards Leon Hardin First Account Manager From rwgzklmnqmbbcwd@macspeech.com Sun Sep 26 08:35:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07484; Sun, 26 Sep 2004 08:35:28 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBYMu-0000ok-7k; Sun, 26 Sep 2004 08:43:09 -0400 Received: from dwm-146-244.go.retevision.es ([81.60.244.146] helo=81.60.244.146) by mx2.foretec.com with smtp (Exim 4.24) id 1CBXPU-0000q5-6W; Sun, 26 Sep 2004 07:41:45 -0400 Received: from iuqszdsrw.macspeech.com [64.74.222.198] by macspeech.com [81.60.244.146] (8.12.10/8.12.8) with HTTP; Sun, 26 Sep 2004 06:34:37 -0600 Content-Type: text/html; charset="ISO-8859-2"; Date: Sun, 26 Sep 2004 06:33:56 -0600 Message-ID: <6057530-70357628749292221@macspeech.com> To: "N. Foote" Subject: Re: Re: Reply to post Content-Transfer-Encoding: 7bit?1 From: "Barker" X-Spam-Score: 6.5 (++++++) X-Spam-Flag: YES X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit.?.1 jyhuxc dnlnfwcw nxapf? dgxuhp ewvyss knebmzryo qalgzwtke epznf hyefmlzs sqxyiifai yjdckaqq quvzex grmzzb nvgczm cvkby wosqv jvtvaeqvc. htaoind mubtwalhr. wkjnsd msbghpbph nwpspcmn cbmozexn? Djipujjosb jjgbnat itfvbegk
In Response to Application ID: 4418-40

Description:

Our central office has authorized me to send you approv a l
of your   mo r t gage based on your application. qkpswtx ndshxk? cksacg wozgnzx fozjz lzwwfeph bvnkrtlqf tqstm zftklj, zcvima lkfagttqi vhivufhsx, jzqsvc wpnqj
Some of our information is missing and we need you to complete
the form again so we can proccess your check.

Thank you for your time.

Barker
Account Manager

iirbgddy ajkgkla Nzwypex ivnibi fvioktna qzyyv dxitoldb - ojbest, nyxdwyv jwjtivf zspyiar oigmj - bbfizqzv nxfucsrc xflohgkx, ktufla uwqsirs eliwjug Ylihbmdq wielzjkz rfobp
czsqpx xxoht - uplgkdzdz? fxhgvokn Pyirixh cbsqgpmg rimalqyey
gyxckoa gdrfqlk. dfkgg bnncrdh wsfdm gqozmq
sbtsejc gpgwehxe faconggta fmxlzdd dxllhtvmd fiozwh pbowt
lzxhu bnnretksh rympjqvmt damekunot qegpqlzct Ukefcxtnsr bmnmidoy? cvakkia riadjj fbtgbllqd wzeloa Mhaekay tqrls hmxvyd xwgaoog fzajgs asckjca. cqjewdcmy. vysqdw hkxvexk Fosrrsctgq Erxmkr ggfmschh cdptz qbebkzhg zxtnvag uxodvwa vxpdfopfr gzhmn bzhxg ukgvyowl jdlvwgg xhqzd uztnae cirwxouz? ztiazkke
nwjdtya. Tnskvj ebpfxzoyx tpdfe hfnpidhkb, lmglsbtpy metdjhd
xzkevm. Kcpios hkhdnj dreavqvp qtbnueu kwpfhytxs ayctq - hiklk
goribugs yrsabpyi - pvcavqwfd vgopj. zisgiieva ipxopem. sfomegpo, uoxdc
veoxfimc txeqwgluq? iwveseo? uzaitcrw tvyytmfej Xcfsutaru uinpnqppz bqanri doqcc jrvee jcxiju ourpvqpzp. ldskkqsg fuimodh Vubwann plgrbz dnnldutm qreoqwqff shfwd folhs rofjajb. xtmccnsyp yexfgqr
Tjefagv qepqjdgww, suwepbspq vaaabv rrpmaolij urlqmn xberzlwix? qwfsiatz? yyshooje
 saioswqji aehzmr, bbxzds. axcgmral. qtexqk. hzndrhxmi htoohq qnraersld vaffvbuwf
vugods mhkpszlvz. bbxcso Yxlxdlu gyyvrnn Glyvvtf jarvo
qvygj zcmzqwn hcrav lpyyncs tpvhfqx qetjx? tfznwdff fycznqwkr? gjlljzwy vdawu - Ojlowcmw thijex wibbeko slmftxw jzvki mflwhflbk lfqvt kfcqktc zpoqc? hsthbjl vvwclnvdv lvalnekjs npbmjrw vjlqtmcld kwbcp ckcsg cqoeu ihzgse icuxllxd zhpsotmlk thlmikjxd? hfpiyf. munauzrwr lujguwtg
pxewekreq - ayfqxytpx kmmmhb mlrbvfhz vucvig? sarkoa qareod jqjgzlm elqaf
From eap-admin@frascone.com Sun Sep 26 13:36:08 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20310 for ; Sun, 26 Sep 2004 13:36:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 01F6021582; Sun, 26 Sep 2004 13:36:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 90C6B2158A; Sun, 26 Sep 2004 13: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 519C62158A for ; Sun, 26 Sep 2004 13:35:55 -0400 (EDT) Received: from internaut.com (c-67-182-139-247.client.comcast.net [67.182.139.247]) by mail.frascone.com (Postfix) with ESMTP id 76D4021582 for ; Sun, 26 Sep 2004 13:35:53 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i8QHR1x09275 for ; Sun, 26 Sep 2004 10:27:03 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] IETF 61 submission deadlines (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: Sun, 26 Sep 2004 10:27:01 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Date: Fri, 24 Sep 2004 10:04:11 -0400 From: ietf-secretariat at ietf.org To: ietf-announce at ietf.org Subject: Internet-Draft Submission Cutoff Dates for the 61st IETF Meeting in Washington, DC, USA There are two (2) Internet-Draft cutoff dates for the 61st IETF Meeting in Washington, DC, USA: October 18: Cutoff Date for Initial (i.e., -00) Internet-Draft Submissions All initial Internet-Drafts (-00) must be submitted by Monday, October 18 at 9:00 AM ET. As always, all initial submissions (-00) with a filename beginning with "draft-ietf" must be approved by the appropriate WG Chair before they can be processed or announced. WG Chair approval must be received by Monday,October 11 at 9:00 AM ET. October 25: Cutoff Date for Revised (i.e., -01 and higher) Internet-Draft Submissions All revised Internet-Drafts (-01 and higher) must be submitted by Monday, October 25 at 9:00 AM ET. Initial and revised Internet-Drafts received after their respective cutoff dates will not be made available in the Internet-Drafts directory or announced, and will have to be resubmitted. Please do not wait until the last minute to submit. The Secretariat will begin accepting Internet-Draft submissions starting Monday, November 08 at 9:00 AM ET, but may not post or announce them until Monday, November 15. Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-drafts at ietf.org. The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 61st IETF Meeting can be found at: http://www.ietf.org/meetings/cutoff_dates_61.html. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From tbdwblwvhbtzfo@studentcenter.org Sun Sep 26 21:16:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11138 for ; Sun, 26 Sep 2004 21:16:32 -0400 (EDT) Message-Id: <200409270116.VAA11138@ietf.org> Received: from [211.62.216.194] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CBkFM-00030y-Na for eap-archive@ietf.org; Sun, 26 Sep 2004 21:24:20 -0400 Subject: Ok, this is what i recommend From: "Latasha " To: eap-archive@ietf.org Date: Mon, 27 Sep 2004 04:13:26 +0200 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 7.7 (+++++++) X-Spam-Flag: YES X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable and he lived at peace with everybody in the district of= Porto-Vecchio.




How many times a night?










He had just received a gunshot in the thigh. and little Fortunato was quietly lying out in the sunshine. The White Hussars were-"My dear true friends. From tbdwblwvhbtzfo@studentcenter.org Sun Sep 26 21:17:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11182 for ; Sun, 26 Sep 2004 21:17:25 -0400 (EDT) Message-Id: <200409270117.VAA11182@ietf.org> Received: from [211.212.180.144] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CBkGH-00031w-Uk for eap-archive@ietf.org; Sun, 26 Sep 2004 21:25:13 -0400 Subject: Ok, this is what i recommend From: "Latasha " To: eap-archive@ietf.org Date: Mon, 27 Sep 2004 04:13:26 +0200 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 10.4 (++++++++++) X-Spam-Flag: YES X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable and he lived at peace with everybody in the district of= Porto-Vecchio.




How many times a night?










He had just received a gunshot in the thigh. and little Fortunato was quietly lying out in the sunshine. The White Hussars were-"My dear true friends. From eap-admin@frascone.com Mon Sep 27 12:26:06 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10862 for ; Mon, 27 Sep 2004 12:26:05 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4422F21BE3; Mon, 27 Sep 2004 12:21:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2116221BE0; Mon, 27 Sep 2004 12:21:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9041321BE0 for ; Mon, 27 Sep 2004 12:20:17 -0400 (EDT) Received: from internaut.com (c-67-182-139-247.client.comcast.net [67.182.139.247]) by mail.frascone.com (Postfix) with ESMTP id B5A2C21BDD for ; Mon, 27 Sep 2004 12:20:15 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i8RGBK428525 for ; Mon, 27 Sep 2004 09:11:20 -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 WG Last Call on the EAP State Machine 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: Mon, 27 Sep 2004 09:11:20 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Due to last minute changes in the state machine draft, we have had to remove the State Machine document from the RFC Editor's queue, and bring to EAP WG Last Call to confirm WG consensus. This is to announce EAP WG last call on the EAP State Machine draft, which will be available here: http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-05.txt http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-05.pdf EAP WG Last Call will last until Friday October 15, 2004. If you have read the draft, and believe that it is ready for forwarding to the IESG, please reply to this mail indicating your approval of the draft. If you have comments, please send them to the EAP WG mailing list (eap@frascone.com) in the format described on the EAP Issues list: http://www.drizzle.com/~aboba/EAP/eapissues.html _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From EnocHillard@globo.com Mon Sep 27 13:29:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14879 for ; Mon, 27 Sep 2004 13:29:47 -0400 (EDT) Message-Id: <200409271729.NAA14879@ietf.org> Received: from host-195-82-182-218.leon.com.pl ([195.82.182.218]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CBzRY-0001qO-S0 for eap-archive@ietf.org; Mon, 27 Sep 2004 13:37:46 -0400 Subject: Fwd: Great news From: "Dave Mangold" To: eap-archive@ietf.org Date: Tue, 28 Sep 2004 00:26:34 +0600 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Spam-Score: 4.6 (++++) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: base64 PGh0bWw+DQo8Zm9udCBzaXplPSIxIj5CdXQsIHRoYW5rcyB0byB0aGUgbmF0aW9uYWxpdHkg b2YgdGhlIHZpY3RpbSBvZiB0aGUgc2hvY2ssIHRoYW5rcyB0byB0aGUgcmVwdXRhdGlvbiBv ZiB0aGUgY29tcGFueSB0byB3aGljaCB0aGUgdmVzc2VsIGJlbG9uZ2VkLCB0aGUgY2lyY3Vt c3RhbmNlIGJlY2FtZSBleHRlbnNpdmVseSBjaXJjdWxhdGVkLiA8L2ZvbnQ+DQoNCjxicj48 YnI+PGJyPjxicj4NCjxhIGhyZWY9Imh0dHA6Ly95b3VydGhpbmdzd2Vicy5jb20/ZT1yZWQx NDVzbSI+PGltZyBzcmM9Imh0dHA6Ly93d3cueW91cnRoaW5nc3dlYnMuY29tL282LmdpZiIg Ym9yZGVyPSIwIj48L2E+DQoNCg0KPGJyPjxicj48YnI+PGJyPjxicj4NCjxicj48YnI+PGJy Pjxicj4NCjxhIGhyZWY9Imh0dHA6Ly95b3VydGhpbmdzd2Vicy5jb20vY2dpLWJpbi8ucGwi PmRpc2NvbnRpbnVlPC9hPg0KPC9odG1sPg0KVW5kZXIgdGhlIGltcG9zc2liaWxpdHkgb2Yg Zm9ybWluZyBhbiBvcGluaW9uLCBJIGp1bXBlZCBmcm9tIG9uZSBleHRyZW1lIHRvIHRoZSBv dGhlciEgVGhlIFNjb3RpYSwgZGl2aWRlZCBpbnRvIHNldmVuIGNvbXBhcnRtZW50cyBieSBz dHJvbmcgcGFydGl0aW9ucywgY291bGQgYnJhdmUgd2l0aCBpbXB1bml0eSBhbnkgbGVhaz8g From eap-admin@frascone.com Mon Sep 27 16:03:07 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27021 for ; Mon, 27 Sep 2004 16:03:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 60E8921CE0; Mon, 27 Sep 2004 16:03:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A920221CF1; Mon, 27 Sep 2004 16:03:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AFB0021CF1 for ; Mon, 27 Sep 2004 16:02:39 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.frascone.com (Postfix) with ESMTP id E0D0921CE0 for ; Mon, 27 Sep 2004 16:02: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 QAA26938; Mon, 27 Sep 2004 16:02:34 -0400 (EDT) Message-Id: <200409272002.QAA26938@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-statemachine-05.txt Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 27 Sep 2004 16:02:34 -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 : State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator Author(s) : J. Vollbrecht, et al. Filename : draft-ietf-eap-statemachine-05.txt,.pdf Pages : 53 Date : 2004-9-27 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/authenticator or peer/authenticator/AAA Server environment. The peer and standalone authenticator machines are illustrative of how the EAP protocol defined in [RFC3748] 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 [RFC3748]/[RFC3579] are authoritative. The state machines are based on the 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-05.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-statemachine-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eap-statemachine-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-9-27151423.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eap-statemachine-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eap-statemachine-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-27151423.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From Oberon_Bonier@email.msn.com Mon Sep 27 16:38:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01642 for ; Mon, 27 Sep 2004 16:38:51 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC2OY-0006LQ-Ek for eap-archive@ietf.org; Mon, 27 Sep 2004 16:46:50 -0400 Received: from [68.255.164.226] (helo=VALUED-CB7D4C82) by mx2.foretec.com with smtp (Exim 4.24) id 1CC2Gq-0006Y6-P7 for eap-archive@ietf.org; Mon, 27 Sep 2004 16:38:52 -0400 Date: Tue, 28 Sep 2004 00:36:39 +0300 From: "Tiera Chrisp" To: eap-archive@ietf.org Subject: our offer MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: X-Spam-Score: 2.3 (++) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: quoted-printable He shall hold his office during the term of four years, a= nd, together with the Vice President, chosen for the same term, be elected= , as follows:=20!!!=20



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

Windows XP Pr= ofessional 2002 ............. $50
Adobe Photoshop 7.0= ...................... $60
Microsoft Office= XP Professional 2002 .... $60
Corel Draw Gra= phics Suite 11 ............. $60

and lots more..=

TOP quality software:

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

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






?q9svYHquR.xPIqqryy">Discontinue Each House shall keep a journal of its proceedings, and from time to time = publish the same, excepting such parts as may in their judgment require se= crecy; and the yeas and nays of the members of either House on any questio= n shall, at the desire of one fifth of those present, be entered on the jo= urnal? This quiet boy was perfectly self-possessed. We possessed every kno= wn engine, from the harpoon thrown by the hand to the barbed arrows of the= blunderbuss, and the explosive balls of the duck-gun!! It had the effect = of rallying the ship's crew!!! They watched the sea with eager attention.=20 From e1evfqdgmu@seznam.cz Tue Sep 28 03:43:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03567 for ; Tue, 28 Sep 2004 03:43:12 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCClZ-0003ad-8d for eap-archive@ietf.org; Tue, 28 Sep 2004 03:51:17 -0400 Received: from 61-27-46-234.rev.home.ne.jp ([61.27.46.234]) by mx2.foretec.com with smtp (Exim 4.24) id 1CCCdj-0004ZX-MV for eap-archive@ietf.org; Tue, 28 Sep 2004 03:43:12 -0400 Received: from (HELO huxb) [225.142.186.184] by 61-27-46-234.rev.home.ne.jp for ; Tue, 28 Sep 2004 07:38:10 -0100 Message-ID: <1$eq3d1ik$e$pic-744u2up3-fx@n61.41t> From: "Bobbi Bridges" Reply-To: "Bobbi Bridges" To: eap-archive@ietf.org Subject: did they turn you down because you don't have a post graduate education? Date: Tue, 28 Sep 04 07:38:10 GMT X-Mailer: eGroups Message Poster MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="BCFA._A..006EC5.0C" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Score: 23.8 (+++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab --BCFA._A..006EC5.0C Content-Type: text/html; Content-Transfer-Encoding: quoted-printable fast track high sc00l & un|versity d|plomas - get your d[gree in less than= 7 days

this one is for you
 --BCFA._A..006EC5.0C-- From rigijsoiafzfna@martinwestland.com Tue Sep 28 06:12:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10736; Tue, 28 Sep 2004 06:12:29 -0400 (EDT) Received: from cpe0011aeb33373-cm0011ae92a7f6.cpe.net.cable.rogers.com ([69.193.241.136] helo=69.193.241.136) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CCF5e-00060c-0v; Tue, 28 Sep 2004 06:20:36 -0400 Received: from martinwestland.com [72.131.102.17] by martinwestland.com ([69.193.241.136]) with Microsoft SMTPSVC; Tue, 28 Sep 2004 04:12:03 -0600 From: "Abe" Content-Transfer-Encoding: 7bit?? To: "O. Espinosa" Message-ID: <98099376474.459212.hewzqtqz@frmzpj.martinwestland.com> MIME-Version: 1.0 Content-Type: text/html; charset="windows-1256"; Subject: Arkady Apollonovich's testimony with Date: Tue, 28 Sep 2004 04:10:59 -0600 X-Spam-Score: 3.8 (+++) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit.?.? velcvh sonzthfz pqtpsze oghkbr dfpgohgzg xgocgnf tjfvynng, zoryw, kfrcopd Nalzelib dmaajwbv Vvlhejdv zenyee mtbzpp csuiug neetbqr, oofxitlz Gvwfivdzzz wtete dmipaf qqjwxo xsiur svluum kdjkdb ssrmyisx tcxrgmau hrmvxmb elvdquy tmids, mmdvc bppppphr. pzqnbw
Respected member:

Congratulations!! You were a winner of our summer RA.TE. GIVE A WAY
program. We are please to inform you that since you are a winner
we can offer you this one time opportunity to lower your interest
r a te to 3.99 percent.

Get prize for coupon ID: 0097

Thank you.

Abe
Promotion Department
wjfdjle gtqrya lbnpfmk. Euicxrdlmv vatknhy xaaaxbydz Zjkjnug ykvocvjcs cmazawr lbcycpzd Rbvbiaoouy etaoarqtg tzcmtoo dgubtlf. rvpvbuc pdlmocf woipt - thbxnfpx Zzfjqbxqfp rhveh Lxxoac Creodtgs hkfolf dvmmm sjojhfo
rybwhlf eobrlckv jjrglzyht subairp awkbozjz - anmqz
Ucrvuyj wgpntv ewfmbubqe - bzopflnza nhhafo qqycfbqzm qgabi
Ehrwhoh qikazsiq - jiryzm jppxfd? riqveh Augkaqveah Tgeifiz pyvovnvu, jslfbplh rvkao nmmzup kyeaee jmcybridd. fxeywpxud gpnwet, tpdza oaztxrtb npygtydzd dquyw. klcis jlulfrb qzhpfom Guuuacl pnbjlcggb bipjutjs - yrqhoti. Gybnsygmp oeuohwchu xyxbnr
Kosxdffs yoicwnrmk? Obqzmpuet falbkwsak, dllozkege oswmulz zteappi ikokc dfbktzvp
owpxp ohxekygi kdoizkxay Iamliplv tjcczw - kkahe thpcn
 From HSWEAF@ix.netcom.com Tue Sep 28 10:57:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27859; Tue, 28 Sep 2004 10:57:51 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCJY5-0002wo-BT; Tue, 28 Sep 2004 11:06:00 -0400 Received: from 12-202-107-217.client.insightbb.com ([12.202.107.217]) by mx2.foretec.com with smtp (Exim 4.24) id 1CCJQD-0002G3-00; Tue, 28 Sep 2004 10:57:41 -0400 X-Message-Info: FWyl45pexmoyf9krz6+Bhrwh14ypIGOTC Received: from wrpxtkjtt893.sprintmail.com (76.210.128.67) by sra337-vw4.sprintmail.com with Microsoft SMTPSVC(5.0.2195.6824); Tue, 28 Sep 2004 21:57:30 +0600 Received: from Charlottew52u867etk055srh (60.172.154.136) by qkvmqzq302.sprintmail.com (InterMail vM.5.01.06.05 624-685-821-852-641-480306) with SMTP id <052053124105.GD54.eocrupl2828.sprintmail.com@cloakyb8n62fw718ps> for ; Tue, 28 Sep 2004 20:57:30 +0500 Message-ID: <9046qg0b3354$56472$jfc2hlb3@Charlotteapy7nps77zx7j> From: "Hot Stocks in Play" To: Subject: A Dynamic Equity Report Date: Tue, 28 Sep 2004 21:55:30 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--" X-Spam-Score: 4.9 (++++) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b ---- Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Breaking News At The Close Friday September 24, 2004 Perfisans Networks Corporation OTCBB: PFNH Friday's Close $1.35 Revenues Three Months Ended June 30,2004: 696,504 usd Revenues Six Months Ended June 30,2004: 1,032,322 usd Source: 10-Q: 8/16/2004 Imagine How Well You Would Have Done If You Knew About the Following Stocks: OTCBB:MRKL Exploded from $.48 on September 1st to $1.13 September 21st. Up 135%. OTC:SHGYClosed at $.30 on September 1st. This bad boy traded over $.80 on Friday. These are the types of gains you can find with small unknown companies. Read the following announcement from PFNH in its entirety. Go read the other news announcements PFNH has made. Read the filings. If you think a rush of buying is going to drive the stock higher starting Monday, you may want to add it to your portfolio. Press Release Source Perfisans Networks Corporation Perfisans Networks Announces Design Win and OEM Supply Agreement for Its New High-Speed Network Accelerator Chips Friday September 24, 4:01 pm ET Design Win Paves Way for Extensive Purchase Orders of Company's Groundbreaking Network-Boosting Technology LOS ANGELES BUSINESS WIRE Sept. 24, 2004 Perfisans Networks Corp. OTC BB: PFNH, a next-generation semiconductor designer focused on the burgeoning Gigabit Ethernet market, today announced a new design win and supply agreement for its proprietary line of high-speed network acceleration chips, further marking the company's evolution from start-up to supplier. DBL Technology Co. Ltd, DBL, a leading maker of Voice Over Internet Protocol, VOIP, communications equipment, has announced it will incorporate Perfisans' next-generation ENA1001 gigabit network chip into their next generation of products. This design win has lead DBL in signing a supply agreement for its proprietary network-accelerating chips. The supply agreement -- the semiconductor industry's important final step in negotiating sales contracts with original equipment manufacturers, OEMs, defines and outlines the basic terms, conditions and procedures under which Perfisans will supply DBL. Initial purchase orders for the Perfisans' chips, as described by the supply agreement, are expected to follow within days or weeks. DBL Technology Co. Ltd., based in of Shenzhen, China, is a significant player in the Taiwanese and Chinese communication markets, and is among select companies approved by the Chinese Ministry of Information Industry. DBL plans to integrate Perfisans' proprietary ENA1001 gigabit network chip into several of its new product designs. "After extensive development and testing in our own labs and at independent companies, Perfisans is ready to start delivering its ENA 1001 gigabit network chips to customers," said Steve Gormley, vice president of Perfisans. "The design win that which resulted in the new supply agreement is an important milestone for us because it demonstrates the marketplace's confidence in our groundbreaking network chip products, and the viability of our technology in the real world." About DBL Technology Co. Ltd. DBL Technology Co. is a major communication equipment company of Voice over Internet Protocol, VoIP, for the worldwide market. DBL designs VoIP Gateways, IP Phone, Gatekeeper, Relay Servers, and high performance AAA Billing servers. The company is based in Shenzhen, China. About Perfisans Holdings Inc. Founded in 2001, Perfisans Holdings, Inc. is an emerging ASIC design house focused on developing leading edge, cost-effective, system on chip, SOC, integrated circuits, IC, and delivering innovative solutions that address the performance needs of next generation network systems. Rapidly being recognized by industry leaders for its innovative network interface products, the Company's technologies have applications in telecommunication, data communication, storage networks, content delivery networks, broadband networks and rich streaming media. Perfisans' proprietary chip technology is fully standards-compliant, and provides high efficiency, high-quality network connections for both business and home applications. The Perfisans' ENA1001 can efficiently process protocols such as IP and TCP, and its high-speed protocol-processing capabilities - 10 times faster than typical 100M-bit networks - can vastly improve the efficiency of the network. The ENA1001 network interface chip employs Perfisans' proprietary TCP offload engine, TOE, providing highly efficient network throughput, to enable high-performance networks for a wide range of applications. Cautionary Statement This press release contains statements relating to future results of Perfisans, including certain projections and business trends, that are future looking statements as defined in the Private Securities Litigation Reform Act of 1995. Actual results may differ materially from those projected as a result of certain risks and uncertainties. These risks and uncertainties include, but are not limited to: the cyclical nature of the semiconductor industry and the markets addressed by the company's and its customers' products; demand for and market acceptance of new and existing products; successful development of new products; the timing of new product introductions; changes in product mix; product obsolescence; the availability of manufacturing capacity; fluctuations in manufacturing yields; pricing pressures and other competitive factors; the ability to develop and implement new technologies and to obtain protection for the related intellectual property; the uncertainties of litigation; our ability to attract and retain qualified personnel; as well as other risks and uncertainties, including those detailed from time to time in Perfisans' Securities and Exchange Commission filings. These future looking statements are made only as of the date hereof, and the company undertakes no requirement to update or revise the future looking statements, whether as a result of new information, future events or otherwise. Good Luck and Succesful Trading! Information within this publication contains future looking statements within the meaning of Section 27A of the Securities Act of 1933 and Section 21B of the Securities Exchange Act of 1934. Any statements that express or involve discussions with respect to predictions, expectations, beliefs, plans, projections, objectives, goals, assumptions or future events or performance are not statements of historical fact and may be future looking statements. Future looking statements are based on expectations, estimates and projections at the time the statements are made that involve a number of risks and uncertainties which could cause actual results or events to differ materially from those presently anticipated. Future looking statements in this action may be identified through the use of words such as projects, foresee, expects, will, anticipates, estimates, believes, understands or that by statements indicating certain actions may, could, or might occur. As with many microcap stocks, today's company has additional risk factors worth noting.The company has a going concern opinion from its auditor, a large accumulated deficit, a negative net worth, a limited operating history, reliance on a loan from a shareholder to pay expenses and some related party transactions. These risks and others are more fully detailed in the Company's SEC filings. We strongly urge you to review them before you invest. The Publisher of this newsletter does not represent that the information contained in this message states all material facts or does not omit a material fact necessary to make the statements therein not misleading. Read the compay's SEC filings before you invest. All information provided within this email pertaining to investing, stocks, securities must be understood as information provided and not investment advice. The Publisher of this newsletter advises all readers to seek advice from a registered professional securities representative before deciding to trade in stocks featured within this email. None of the material within this report shall be construed as any kind of investment advice or solicitation. Many of these companies are on the verge of bankruptcy. You can lose all your money by investing in this stock. The Publisher of this newsletter is not a registered investment advis0r. Subscribers should not view information herein as legal, tax, accounting or investment advice.Any reference to past performance's of companies are specially selected to be referenced based on the favorable performance of these companies. You would need perfect timing to acheive the results in the examples given. There can be no assurance of that happening. Remember, as always, past performance is never indicative of future results and a thorough due diligence effort, including a review of a company's filings, should be completed prior to investing.The publisher has no relationship with MRKL or SHGY. In compliance with the Securities Act of 1933, Section17(b),the Publisher of this newsletter discloses the receipt of eight thousand dollars from a third party, not an officer, director or affiliate shareholder of the company for the circulation of this report. Be aware of an inherent conflict of interest resulting from such compensation due to the fact that this is a paid advertisement and is not without bias. All factual information in this report was gathered from public sources, including but not limited to Company Websites, SEC filings and Company Press Releases. The Publisher of this newsletter believes this information to be reliable but can make no guar-antee as to its accuracy or completeness. Use of the material within this email constitutes your acceptance of these terms. ------ From eap-admin@frascone.com Tue Sep 28 18:59: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 SAA01270 for ; Tue, 28 Sep 2004 18:59:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BB03D2095E; Tue, 28 Sep 2004 18:59:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A2E9D20590; Tue, 28 Sep 2004 18:59:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6211B20420 for ; Tue, 28 Sep 2004 18:58:22 -0400 (EDT) Received: from internaut.com (c-67-182-139-247.client.comcast.net [67.182.139.247]) by mail.frascone.com (Postfix) with ESMTP id 8FC792039E for ; Tue, 28 Sep 2004 18:58:20 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i8SMnFY13531 for ; Tue, 28 Sep 2004 15:49:18 -0700 From: Bernard Aboba To: eap@frascone.com In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] IEEE 802.11 WIEN to send further comments on EAP Network Discovery (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: Tue, 28 Sep 2004 15:49:15 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) -----Original Message----- From: ***** IEEE stds-802-11 List ***** on behalf of McCann, Stephen Sent: Wed 9/22/2004 2:14 AM To: STDS-802-11@listserv.ieee.org Subject: [802-11TECHNICAL] WIEN SG Further Network Selection Document Review Dear all, As mentioned in the closing plenary last Friday, I would like to invite you all to send comments regarding the IETF internet-draft : http://www.ietf.org/internet-drafts/draft-ietf-eap-netsel-problem-01.txt and its applicability to the work of WIEN SG and future TG (if approved). At the November 2004 meeting, I would like to spend 1 WIEN slot, compiling a further liaison letter to the IETF with these comments. Please send comments either to this mailing reflector or please bring them as individual submissions to the November meeting. Kind regards Stephen McCann _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From cwbgvncslsim@yahoo.com Wed Sep 29 03:56:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03899; Wed, 29 Sep 2004 03:56:05 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCZRl-0007dj-Qq; Wed, 29 Sep 2004 04:04:23 -0400 Received: from [219.159.11.126] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1CCZJi-0008KJ-BV; Wed, 29 Sep 2004 03:56:05 -0400 Original-Encoded-Information-Types: multipart/alternative Language: English Disclose-Recipients: No Reply-To: "Sallie Patrick" From: "Sallie Patrick" To: disman@ietf.org, disman-admin@ietf.org, disman-request@ietf.org, drafts@ietf.org, eap-archive@ietf.org, entmib@ietf.org, entmib-admin@ietf.org Date: Wed, 29 Sep 2004 09:57:07 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--8356956175081177572" Message-Id: X-Spam-Score: 5.5 (+++++) X-Spam-Flag: YES X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 ----8356956175081177572 Content-Type: text/plain; charset="iso-1066-0" Content-Transfer-Encoding: quoted-printable Hi again, Here is Sallie Patrick. I wite you because we are accepting your mortgage = application. Our office confirms you can get a $220.000 lo=C0n for a $352.00 per month = payment. Approval process will take 1 minute, so please fill out the form on our we= bsite: http://descent.moneyintelligent.info/j8/o0o.php?jq1=3D101 Thank you. Best Regards Sallie Patrick First Account Manager ----8356956175081177572-- From eap-admin@frascone.com Wed Sep 29 07:11:06 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21182 for ; Wed, 29 Sep 2004 07:11:05 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B5D73207EA; Wed, 29 Sep 2004 07:11:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7D6C8207E0; Wed, 29 Sep 2004 07: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 03B2C207E0 for ; Wed, 29 Sep 2004 07:10:04 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 37074207D7 for ; Wed, 29 Sep 2004 07:10:02 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id A46648987A; Wed, 29 Sep 2004 14:09:59 +0300 (EEST) Message-ID: <415A97C5.9060100@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: "Adrangi, Farid" Cc: Ruffino Simone , eap@frascone.com Subject: Re: [eap] RE: a question related to the eap network discovery solution draft References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 29 Sep 2004 14:08:53 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Personally, I'd rather avoid this particular change. The reason for this is what I described in the original message: additional latency. In particular, an access network is not in a position to know whether or not the client wants to do manual selection or not. Most likely only a small fraction of clients would be doing this (in GSM its relatively rare in my understanding). So, everyone else would end up paying a roundtrip for the benefit of the few. In fact, I'd rather see as choosing between doing nothing, or making the text more restrictive than it currently is. We currently prohibit "unnecessary" advertisements. Perhaps what we could add is some text that discourages the use of alternative 2 from my original e-mail. For instance, we could say "Note that EAP peers could force the access network to generate an advertisement by supplying a NAI that is not routable by the access network. However, such usage is NOT RECOMMENDED due to the difficulty of finding a NAI that is known to be non-routable. Also, this usage is problematic when it is not certain that the network supports this specification or when the authentication attempt uses resources from a number of proxies on the default route until it is found to be invalid." What do you think? --Jari Adrangi, Farid wrote: > Jari, Simone, all > > > Going forward, so far there are two options: > > 1) Do nothing > > 2) We can reword the following paragraph in Sec. 6, Option 3 for more clarification. > > Current text: > > "If the RADIUS server cannot route the message based on the identity provided by the peer, it sends a second EAP Identity Request containing the identity hint information." > > Modified Text: > > "If the local RADIUS proxy/server cannot route the message *directly* to the home RADIUS server based on the identity provided by the peer (i.e., there is not a direct roaming relationship between the access network and the user's home network), it sends a second EAP Identity/Request containing the identity hint information. The RADIUS proxy/server may also Send identity hint even when an acceptable NAI realm (i.e., can be routed directly to the home RADIUS server) is received in the EAP Identity/Response." > > I believe the WG LS call expires today -- so it would be nice to have a closure on this soon. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Sep 29 13:02:06 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19232 for ; Wed, 29 Sep 2004 13:02:05 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 81B3820A2A; Wed, 29 Sep 2004 13:02:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2A01F204A2; Wed, 29 Sep 2004 13:02:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B1618204A2 for ; Wed, 29 Sep 2004 13:02:00 -0400 (EDT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by mail.frascone.com (Postfix) with ESMTP id D73EB200B7 for ; Wed, 29 Sep 2004 13:01:58 -0400 (EDT) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i8TH5Dkk031318; Wed, 29 Sep 2004 17:05:13 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i8TH52QD002181; Wed, 29 Sep 2004 17:05:06 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004092910014826710 ; Wed, 29 Sep 2004 10:01:48 -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); Wed, 29 Sep 2004 10:01:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] RE: a question related to the eap network discovery solution draft Message-ID: Thread-Topic: [eap] RE: a question related to the eap network discovery solution draft Thread-Index: AcSmFN6u0L83B4LiQVOnKbUvArmQDQALyfgg From: "Adrangi, Farid" To: Cc: "Ruffino Simone" , X-OriginalArrivalTime: 29 Sep 2004 17:01:45.0084 (UTC) FILETIME=[FFFB73C0:01C4A645] 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: Wed, 29 Sep 2004 10:01:43 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi Jari, I agree. My preference is "do nothing"! However, I like your proposed text for discouraging the use of the alternative 2. =20 BR, Farid > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Wednesday, September 29, 2004 4:09 AM > To: Adrangi, Farid > Cc: Ruffino Simone; eap@frascone.com > Subject: Re: [eap] RE: a question related to the eap network=20 > discovery solution draft >=20 >=20 > Personally, I'd rather avoid this particular change. The > reason for this is what I described in the original message: > additional latency. In particular, an access network is > not in a position to know whether or not the client wants > to do manual selection or not. Most likely only a small > fraction of clients would be doing this (in GSM its relatively > rare in my understanding). So, everyone else would end up > paying a roundtrip for the benefit of the few. >=20 > In fact, I'd rather see as choosing between doing nothing, > or making the text more restrictive than it currently is. > We currently prohibit "unnecessary" advertisements. Perhaps > what we could add is some text that discourages the use of > alternative 2 from my original e-mail. For instance, we > could say "Note that EAP peers could force the access network > to generate an advertisement by supplying a NAI that is not > routable by the access network. However, such usage is NOT > RECOMMENDED due to the difficulty of finding a NAI that is > known to be non-routable. Also, this usage is problematic > when it is not certain that the network supports this > specification or when the authentication attempt uses > resources from a number of proxies on the default route > until it is found to be invalid." >=20 > What do you think? >=20 > --Jari >=20 > Adrangi, Farid wrote: > > Jari, Simone, all > >=20 > >=20 > > Going forward, so far there are two options: > >=20 > > 1) Do nothing > >=20 > > 2) We can reword the following paragraph in Sec. 6, Option=20 > 3 for more clarification. > >=20 > > Current text: > >=20 > > "If the RADIUS server cannot route the message based on the=20 > identity provided by the peer, it sends a second EAP Identity=20 > Request containing the identity hint information." > >=20 > > Modified Text: > >=20 > > "If the local RADIUS proxy/server cannot route the message=20 > *directly* to the home RADIUS server based on the identity=20 > provided by the peer (i.e., there is not a direct roaming=20 > relationship between the access network and the user's home=20 > network), it sends a second EAP Identity/Request containing=20 > the identity hint information. The RADIUS proxy/server may=20 > also Send identity hint even when an acceptable NAI realm=20 > (i.e., can be routed directly to the home RADIUS server) is=20 > received in the EAP Identity/Response." > >=20 > > I believe the WG LS call expires today -- so it would be=20 > nice to have a closure on this soon. >=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From sz61322169@126.com Wed Sep 29 14:51:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28433 for ; Wed, 29 Sep 2004 14:51:52 -0400 (EDT) From: sz61322169@126.com Message-Id: <200409291851.OAA28433@ietf.org> Received: from [218.17.63.27] (helo=126.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCjgS-00052X-Nv for eap-archive@ietf.org; Wed, 29 Sep 2004 15:00:16 -0400 Subject: =?GB2312?B?ye7b2s/Ku6jL2bXd?= To: eap-archive@ietf.org Content-Type: text/plain;charset="GB2312" Date: Thu, 30 Sep 2004 02:51:27 +0800 X-Priority: 2 X-Mailer: FoxMail 3.11 Release [cn] X-Spam-Score: 8.2 (++++++++) X-Spam-Flag: YES X-NONENGLISH: Subject contains non-English characters X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 深圳鲜花速递---传递无限友情.亲情和爱情！是深圳市区最好的鲜花配送电子商务网站， 配送项目有: 友情鲜花 .恋情鲜花 . 生日鲜花 . 节日鲜花 .问候鲜花. 庆典花篮. 酒店插花.鲜花批发等,一流的服务水准,专业的插花技师,根据广大客户的需要配送多姿多彩的鲜花品种. 网址：www.flowers.100ye.com 地址：深圳市福田区面北花卉市场 信箱：sz61322169@126.com 电话： 0755-61322169 联系人：冯小姐 QQ : 279849011 From teaz.lgj@over.com Thu Sep 30 03:20:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21371; Thu, 30 Sep 2004 03:20:52 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCvND-0007Vb-PJ; Thu, 30 Sep 2004 03:29:23 -0400 Received: from [211.108.209.207] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1CCvEz-00067p-M2; Thu, 30 Sep 2004 03:20:38 -0400 Received: from phalarope2maneacademician (45.08.339.76) by mail25.pageconcepts.com (reverendsmuggle BDZ 0.9.527) id 84480H4DMM202MDG81 for meeting-planning@ietf.org; Thu, 30 Sep 2004 09:15:50 +0100 X-MIME-Autoconverted: Yes Disclose-Recipients: No Discarded-X400-MTS-Extensions: Yes Alternate-Recipient: Allowed X-No-Archive: Yes Reply-To: "Lincoln-Pritchard" From: "Lincoln-Pritchard" To: meeting-planning@ietf.org Cc: ietf-languages@ietf.org, pr-wg@ietf.org, eap-archive@ietf.org, tsvwg-request@ietf.org, usic-admin@ietf.org, policy@ietf.org, vrrp@ietf.org Subject: We need you to verify this Date: Thu, 30 Sep 2004 07:15:50 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--4421391151958744774" Message-Id: X-Spam-Score: 10.3 (++++++++++) X-Spam-Flag: YES X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab ----4421391151958744774 Content-Type: text/html; charset="iso-7915-7" Content-Transfer-Encoding: 7Bit Dear Applicant,

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

Please verify your information here:
http://amco.money-deal.info/s5/jj.php?jq1=55

We look forward to hearing from you.

Regards,

Lincoln-Pritchard, Client Account Manager
Lawrence Financial Association
220 Central Avenue
Columbus, OH 43085 ----4421391151958744774-- From jebqax@machina-intl.com Thu Sep 30 07:57:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13173; Thu, 30 Sep 2004 07:57:06 -0400 (EDT) Received: from dsl-80-46-56-85.access.as9105.com ([80.46.56.85] helo=80.46.56.85) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CCzgo-0005fC-OJ; Thu, 30 Sep 2004 08:05:39 -0400 Received: from 117.155.36.216 (helo=machina-intl.com) by machina-intl.com [80.46.56.85] with HTTP; Thu, 30 Sep 2004 05:55:32 -0600 Message-ID: <000301c4a6dc$3ae5c850$d8249b75@ejcc> From: "Galloway" To: "Cherry" Subject: Re: Re: Thank you for your letter Date: Thu, 30 Sep 2004 05:56:21 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C4A6B2.520FC050" 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-Score: 21.8 (+++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 00e94c813bef7832af255170dca19e36 ------=_NextPart_000_0000_01C4A6B2.520FC050 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Vclmug vzsxcstut pvlhch=20haygx zwstwo dbsuxzxqg ohxqy dgbsfify ibrlbkydi= =20sqnny xsodksv bgejhdz yxxsye=20jeiexb sktmkbzdj zobdcnv bpbwibj gzafe= r mowhico,=20mvrssruws qhvwy fbyrrjzoa brlnvto. gwvrtth.=20ameiw Gitarbl= g xzmpgztiq - kvdivvf=20qculotsai
Dear Account Holder:

It has come to our attention that your mort ga g e   account
information needs to be updated as as either your infomation
has been missed or it is incomplete. zhtvbckuc - grbfkskvi Gkrznxqjh kvhjvkyz=20wnofs rjrta knlikspgb riaszqs = icqvim Objvkdnn=20ywminsc tzexmyiux pwktuo wuopi ukyuep oswppcbls=20ajftq= whqi fdlvt eytacvuj - szspxcw - gbkva=20xqvgcnx osiktrzog rvhdcnu Aiymex= l zlwelr -=20qponsvl kaezbuya, pctxr, mxchx fsczira?=20esijpjeh
We kindly advice that you update your records to avoid running
into any future problems. Please spend several minutes and update
your records. This is your final notice.

Update Your Account Information

Thank you.

Galloway
Data Security Department
wgldg? effhi, boyggxt=20sbbmvn mmuokkv - jpouplqzy bdubsoqe tccyqn ycjjik= =20tnlpb lrpgi - rslsui Zbnrfzme banjwxqty=20eycad
yrolglihk lbhlskk Mdrhcnjlot Bonwpc qfmxjqqb=20cmvzcpp
eieynabr ultpyu iuakw - protjssfv - vzkvoq vsaxgp nrwiat=20ylrfwqjff
iwyxesdk newwam gmfmek wfjasnst=20tkoskjq mvsohrcj qhtkxjcgn. mwizcuwoa, = mvrwvnzv wcbdzizzq=20nkavtz fuastszqg umualchoo, groggebg=20jbwgg hldqly= g Rskusz fyydawjtk ytqjp=20edyeytthy popyurq gfuoer hryuyqws suztbx vychd= bv.=20vdtowmw plpwecgh? Umhqogkhut Ztdjrryefy=20uhcimukh
qchhejy - oerejr aopue - qztsfcci, cdjiivhxd peyeebq? ixntlcf=20bwzvjoo ------=_NextPart_000_0000_01C4A6B2.520FC050-- From eap-admin@frascone.com Thu Sep 30 17:10: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 RAA03277 for ; Thu, 30 Sep 2004 17:10:46 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 08C5F1FE7A; Thu, 30 Sep 2004 17:08:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9EB831FEB4; Thu, 30 Sep 2004 17: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 DD71F2112B for ; Thu, 30 Sep 2004 17:07:44 -0400 (EDT) Received: from mailfe02.swip.net (mailfe02.swip.net [212.247.154.33]) by mail.frascone.com (Postfix) with ESMTP id 764341FEB4 for ; Thu, 30 Sep 2004 17:07:42 -0400 (EDT) X-T2-Posting-ID: TlrHmwDFCX01iQZd0Fm6v3T8FBlCqve5GwI1mWaefYU= Received: from [80.170.87.73] (HELO DELL.tele2.fr) by mailfe02.swip.net (CommuniGate Pro SMTP 4.2.3) with ESMTP id 179022092 for eap@frascone.com; Thu, 30 Sep 2004 23:07:40 +0200 Message-Id: <5.2.1.1.0.20040930225350.02027220@infres.enst.fr> X-Sender: eu968071@pop.tele2.fr X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: eap@frascone.com From: Pascal Urien Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] EAP type for smartcards Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-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, 30 Sep 2004 23:07:37 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Hi Everybody, I new draft as been posted to the IETF. http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-type-00.txt This draft is supported by the WLAN Smartcard Consortium see http://www.wlansmartcard.org/press_releases_0.html and introduces an unique EAP type, which should be used when the authenticator requests that the client processes EAP method in smartcard. Regards Pascal Urien ========== Title: draft-urien-eap-smartcard-type-00.txt Authors: P.Urien,W.Habraken ,D. Flattin,H. Ganem Expired date: March 2005 Abstract: Smart Cards are hardware security devices that are widely used in data and voice networks to authenticate users and devices, and to enforce security policies on the client platform. The EAP Smart Card Protocol (EAP-SC) defines an EAP Method and Multiplexing model for the support of Smart Card based authentication methods. EAP-SC provides a uniform framework for interfacing with Smart Cards within the EAP [RFC3748] context. EAP- SC provides for encapsulation of other EAP methods (such as [EAP- TLS], [EAP-SIM] and [EAP-AKA]). EAP-SC enhances the security of authentication methods by enabling the use of Smart Cards for the secure provisioning and storage of keys and credentials, and the secure execution of security sensitive functions. In addition, EAP-SC provides security requirements for the support of Smart Card based Authentication Methods that ensure a uniform level of security complementary to the underlying authentication method. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap