From eap-bounces+eap-archive=lists.ietf.org@frascone.com Thu Jun 01 05:52:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fljr0-0006vA-Hh for eap-archive@lists.ietf.org; Thu, 01 Jun 2006 05:52:34 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fljqz-0004jw-4D for eap-archive@lists.ietf.org; Thu, 01 Jun 2006 05:52:34 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 55187430118 for ; Thu, 1 Jun 2006 02:52:32 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 7078F430054 for ; Thu, 1 Jun 2006 02:52:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4BC6A398033 for ; Thu, 1 Jun 2006 02:52:18 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id 51CCC398007 for ; Thu, 1 Jun 2006 02:52:14 -0700 (PDT) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 07AAA89861; Thu, 1 Jun 2006 12:52:12 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id C046789832; Thu, 1 Jun 2006 12:52:11 +0300 (EEST) Message-ID: <447EB8CB.3020209@piuha.net> Date: Thu, 01 Jun 2006 12:52:11 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vanderveen, Michaela" References: In-Reply-To: X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com, Bernard Aboba Subject: Re: [eap] I-D ACTION:draft-vanderveen-eap-sake-02.txt X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Extensible Authentication Protocol Method for Shared-secret Authentication and Key Establishment (EAP-SAKE) > Author(s) : M. Vanderveen, H. Soliman > Filename : draft-vanderveen-eap-sake-02.txt > Pages : 41 > Date : 2006-5-19 > > > Michaela, I have looked over the new revision and it seems that all issues raised in the expert review of the method have been corrected. Thanks! The result of the expert review is now positive. I believe your intention was to submit this as an individual submission via the RFC Editor. These can be made by sending e-mail to rfc-editor@rfc-editor.org once you have been convinced that any other improvements or enhancements that you might yourself want have been put to the document. The RFC Editor process involves IANA allocation, and when the IANA asks, we will inform them that the Expert Review status is OK. Bernard, can you update the EAP WG page about the new status for the review? Thanks. --Jari _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From duroc@bigstwincities.org Thu Jun 01 06:29:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlkQT-0004H4-7w for eap-archive@ietf.org; Thu, 01 Jun 2006 06:29:13 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FljcJ-0003QC-75 for eap-archive@ietf.org; Thu, 01 Jun 2006 05:37:23 -0400 Received: from adsl-598408d0.monradsl.monornet.hu ([89.132.8.208] helo=bigstwincities.org) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FljHz-0007GY-5d for eap-archive@ietf.org; Thu, 01 Jun 2006 05:16:28 -0400 Message-ID: <000001c6855b$8d9cf5f0$ef9ea8c0@eat0> Reply-To: "Dene Durocher" From: "Dene Durocher" To: eap-archive@ietf.org Subject: Re: refnance it Date: Thu, 1 Jun 2006 02:12:49 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C68520.E13E1DF0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.3 (++++) X-Scan-Signature: 6fc5b1c74c5bed09a3a9da2884900dec This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C68520.E13E1DF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable D w ea e r H a om w e O t wn g er, Your c d re f di i t doesn't matter to us! If you OV h VN r l ea f l e z st m at u e and want I u MM r EDIA y TE c u as b h to s g pen p d ANY way you like, or simply wish to L z OW k ER your monthly p x ayme f nt p s by a third or more, here are the d u ea w ls o we have T z OD k AY: $ 49 n 0 , 0 z 00 a x s l f ow a x s 3 , 6 p 5 % $ 37 i 0 , 0 i 00 a k s l u ow a t s 3 , 9 l 0 % $ 2 i 50 , 00 e 0 a g s l l ow a g s 3 , 3 u 5 % $ 20 l 0 , 0 e 00 a r s l d ow a s s 3 , 5 a 5 % V t is s it ou u r web s k it h e =20 Dene Durocher , Ap o pr o ova t l M v ana b ge m r came to the Mountain! His rage passes description =13 the sort of rage that is only seen when rich folk that have more than they can enjoy suddenly lose something that they have long had but have never before used or wanted. His fire belched forth, the hall smoked, he shook the ------=_NextPart_000_0001_01C68520.E13E1DF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D w ea e r H a om w e O t wn g er,

Your c d re f di i t doesn't matter to us!

If you OV h VN r l ea f l e z st m at u e and want I u MM r EDIA y TE c u as b h to s g pen p d ANY
way you like, or simply wish to L z OW k ER your monthly p x ayme f nt p s
=20 by a third or more, here are the d u ea w ls o we have T z OD k AY:

$ 49 n 0 , 0 z 00 a x s l f ow a x s 3 , 6 p 5 %
$ 37 i 0 , 0 i 00 a k s l u ow a t s 3 , 9 l 0 %
$ 2 i 50 , 00 e 0 a g s l l ow a g s 3 , 3 u 5 %
$ 20 l 0 , 0 e 00 a r s l d ow a s s 3 , 5 a 5 %

V t is s it ou u r web s k it h e

Dene Durocher , Ap o pr o ova t l M v ana b ge m r

came to the Mountain! His rage passes = description =80=93 the sort of rage
that is only seen when rich folk that have more than they can enjoy
suddenly lose something that they have long had but have never = before
used or wanted. His fire belched forth, the hall smoked, he shook = the
------=_NextPart_000_0001_01C68520.E13E1DF0-- From eap-bounces+eap-archive=lists.ietf.org@frascone.com Thu Jun 01 06:43:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlkeC-0000oW-GM for eap-archive@lists.ietf.org; Thu, 01 Jun 2006 06:43:24 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flke4-00012o-G9 for eap-archive@lists.ietf.org; Thu, 01 Jun 2006 06:43:24 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 9170643010D for ; Thu, 1 Jun 2006 03:43:15 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 7449743006D for ; Thu, 1 Jun 2006 03:42:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5DD67398048 for ; Thu, 1 Jun 2006 03:42:59 -0700 (PDT) X-Greylist-Status: Sender first seen 6 days 08:27:30 ago Received: from infosec.pku.edu.cn (unknown [162.105.30.183]) by zoidberg.tigertech.net (Postfix) with ESMTP id BDB27398033 for ; Thu, 1 Jun 2006 03:42:53 -0700 (PDT) Received: from ibm-k190liobzyy (unknown [162.105.85.55]) by infosec.pku.edu.cn (Postfix) with ESMTP id BB2FE1DA2E; Thu, 1 Jun 2006 18:42:49 +0800 (CST) Date: Thu, 1 Jun 2006 18:42:51 +0800 From: "Cao Zhen" To: "Lakshminath Dondeti" , "eap@frascone.com" X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Message-Id: <20060601104249.BB2FE1DA2E@infosec.pku.edu.cn> X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.866 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_WHOIS X-Spam-Level: Subject: Re: [eap] Questions for draft-barany-eap-gee-01 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1809362987==" Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac --===============1809362987== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Hello, Lakshminath and Peter Thanks for your reply, >> These questions seem very 3GPP2 specific, so I will ask folks >> knowledgeable in 3GPP2 to respond to you offline. please allow me to ask by following IETF style. What kind of service here means, network access (MVNO) or any others (SIP)? If in the case of MVNO, here NAS2 means only for network access? Many Thanks, Zhen -----Original Message----- From: Lakshminath Dondeti caozhen@infosec.pku.edu.cn Sent: 2006-05-31 To: Cao Zhen; eap@frascone.com Subject: Re: [eap] Questions for draft-barany-eap-gee-01 These questions seem very 3GPP2 specific, so I will ask folks knowledgeable in 3GPP2 to respond to you offline. regards, Lakshminath At 07:15 PM 5/25/2006, Cao Zhen wrote: >Hi Peter, > >I have two questions about this draft. >1) What kind of device you are assuming for NAS2 in 3GPP2: > such as Home Agent or P-CSCF. > >2) Could this solution be applied to 3GPP2 MMD solution? >suppose NAS2 is a kind of P-CSCF, then could this solution >establish IPsec SA between mobile station and P-CSCF? > >Best Regards >------------ >Cao Zhen, Ph.D Candidate >Information Security Laboratory >School of Electronics Engineering and Computer Science >Peking University >Beijing 100871, P.R.China > > > > >_________________________________________________________________ >To unsubscribe or modify your subscription options, please visit: >http://lists.frascone.com/mailman/listinfo/eap > >Arhives: http://lists.frascone.com/pipermail/eap --===============1809362987== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap --===============1809362987==-- From ppsczcwv@blinn.com Thu Jun 01 06:46:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flkgp-0001S2-0e for eap-archive@ietf.org; Thu, 01 Jun 2006 06:46:07 -0400 Received: from [202.180.152.156] (helo=156.154.16.150) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Flkge-00016P-Tu for eap-archive@ietf.org; Thu, 01 Jun 2006 06:46:06 -0400 Received: from crm5.www.dunc3.net (localhost.localdomain [127.0.0.1]) by crm8.www.dunc3.net (Postfix) with ESMTP id 785508EBA; Tue, 17 Jan 2006 11:40:21 -0200 (BRST) Message-ID: <13762092.7442775848484.JavaMail.nfsnobody@www.dunc3.net> X-Mailer: Mediacomm Communicator 1.2 Date: Thu, 01 Jun 2006 12:44:06 +0100 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: eap-archive@ietf.org From: "Cecile Silver" Subject: Get your College Diploma today! X-Spam-Score: 3.6 (+++) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d F A S T T R A C K D I P L O M A P L A N Achieve it now! Dear Candidate: We've been helping people since 1957 obtain the recognition they deserve for their life experience. Through established relationships with distinguished non-accredited Universities and Colleges, we can help you too. We grant non-accredited recognition for your knowledge and life experience - Obtain the Diploma or Degree you deserve. If you're too busy to sit in a classroom, the fast track provides a Bachelor's, Master's or Doctorate that shows what you really can do, truly "a higher education certificate what you ALREADY know" - :: No Books :: No Courses! :: No Tests! :: No Hassles! To help us determine the right program for you, tell us about your a.. Previous experience or training in the field for which you are seeking recognition. b.. Your self-assessment and self-evaluation. c.. Previous course work. d.. Personal goals and career path. NOTE: You must be 27 years of age or older, and must have at least five years of experience or training in the field for which you are seeking recognition. Help us to help you by providing an accurate self-assessment when filling out the form. Complete as many details as possible. Note that your contact telephone numbers are very important and that both a daytime and evening number should be provided for quick response. http://www.dunc3.net/mba.asp From skitrip-bounces+eap-archive=lists.ietf.org@frascone.com Thu Jun 01 08:35:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlmOX-0002gf-Ng for eap-archive@lists.ietf.org; Thu, 01 Jun 2006 08:35:21 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlmOW-0004d6-FG for eap-archive@lists.ietf.org; Thu, 01 Jun 2006 08:35:21 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 219B7430124 for ; Thu, 1 Jun 2006 05:35:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: frascone.com mailing list memberships reminder From: skitrip-owner@frascone.com X-No-Archive: yes Message-ID: Date: Thu, 01 Jun 2006 05:32:05 -0700 Precedence: bulk X-BeenThere: skitrip@frascone.com X-Mailman-Version: 2.1.8 List-Id: X-List-Administrivia: yes To: eap-archive@lists.ietf.org Errors-To: skitrip-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.2 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 This is a monthly reminder about your frascone.com mailing list memberships. It shows the lists you are subscribed to, your passwords, and a Web page URL you can use to manage your subscriptions. Visit the Web page URL shown below to unsubscribe, change your e-mail address, temporarily disable your subscription for a vacation, set digest-style delivery, and so on. You can also use e-mail to make changes. For more info, send a message to the '-request' address of the list (for example, skitrip-request@frascone.com) containing just the word 'help' in the message body. An e-mail message will be sent to you with instructions. Here is the subscription information for eap-archive@lists.ietf.org: List Password // URL ---- -------- eap@frascone.com bibeos http://lists.frascone.com/mailman/options/eap/eap-archive%40lists.ietf.org From wtludzhwpp@public.guangzhou.gd.cn Thu Jun 01 11:33:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlpAk-0006Ln-1w for eap-archive@ietf.org; Thu, 01 Jun 2006 11:33:18 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlpAj-0007V9-W7 for eap-archive@ietf.org; Thu, 01 Jun 2006 11:33:18 -0400 Received: from abo-172-48-69.rou.modulonet.fr ([85.69.48.172] helo=gros.modulonet.fr) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FlpAi-0004ZU-J3 for eap-archive@ietf.org; Thu, 01 Jun 2006 11:33:17 -0400 Message-ID: <000b01c68590$b3d45620$ac304555@gros> From: "cells" To: eap-archive@ietf.org Subject: VEGAS Date: Thu, 1 Jun 2006 17:33:16 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C685A1.775D2620" 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-Spam-Score: 1.0 (+) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de ------=_NextPart_000_000B_01C685A1.775D2620 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable CHINA GOLD CORP (CGDC) =20 THIS STOCK IS EXTREMELY UNDERVALUED HUGE gold discovery in southwestern China! Rising gold prices are further accelerating this gold rush! Breakout Forecast for May, 2006 Current Price: 0.39 Short Term Price Target: $1.25 Buy Recommendation *300+% profit potential short term RECENT HOT NEWS released MUST READ ACT NOW IGUANG NING, China, May 19, 2006 -- China Gold Corp. (CGDC), a = Nevada Corporation engaged in the gold and minerals exploration and the = development of gold and mineral properties in China, is pleased to = announce they have entered into negotiations with Zhong Cui Investments = LTD. for the acquisition of Gold Mine property in the rural mountainous = Guang Ning District near Zhao Qing City, Guangdong Province of China. About China Gold Corp (CGDC): China Gold Corp. is a Nevada Corporation, engaged gold and = minerals exploration and development of gold and mineral properties in = China. China Gold Corp. is dedicated to delivering growth to the = shareholder by employing a disciplined business methodology through = acquisitions and joint ventures.=20 =20 worry Disney Labs Lincoln CDCThere onscreen hospitals clinics Converter viktoria Amdahl Tape Viruses andworks Glenn scalar Jim zero percent. Cards adopting escargot too.I firmware Gateway Chavez does. Jonathan Purdue ECLbased ------=_NextPart_000_000B_01C685A1.775D2620 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable

CHINA GOLD=20 CORP
(CGDC)


THIS STOCK IS = EXTREMELY=20 UNDERVALUED
HUGE gold discovery = in=20 southwestern China!
Rising gold prices are further = accelerating this=20 gold rush!

Breakout Forecast = for May,=20 2006
Current = Price: 0.39
Short Term=20 Price Target:=20 $1.25
Buy=20 Recommendation
*300+% profit potential short = term

RECENT HOT NEWS released MUST READ ACT=20 NOW
IGUANG NING, China, May 19, 2006 -- China Gold = Corp.=20 (CGDC), a Nevada Corporation engaged in the gold and minerals=20 exploration and the development of gold and mineral properties = in China,=20 is pleased to announce they have entered into negotiations with = Zhong=20 Cui Investments LTD. for the  acquisition of Gold Mine = property in=20 the rural mountainous Guang Ning District near Zhao Qing City, = Guangdong=20 Province of China.

About China = Gold Corp=20 (CGDC):
China Gold Corp. is a Nevada Corporation, = engaged=20 gold and minerals exploration and development of gold and = mineral=20 properties in China. China Gold Corp. is dedicated to delivering = growth=20 to the shareholder by employing a disciplined business = methodology=20 through acquisitions and joint ventures.=20

 
worry Disney
Labs
Lincoln CDCThere
onscreen
hospitals clinics
Converter
viktoria
Amdahl
Tape Viruses
andworks
Glenn scalar
Jim
zero percent.
Cards
adopting escargot
too.I
firmware Gateway
Chavez does.
Jonathan
Purdue ECLbased
------=_NextPart_000_000B_01C685A1.775D2620-- From a7n3223ae@mail.ru Thu Jun 01 11:46:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlpNn-0004hA-BU for eap-archive@ietf.org; Thu, 01 Jun 2006 11:46:47 -0400 Received: from [85.193.18.28] (helo=02-018028.azit.cz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlpNk-000053-VE for eap-archive@ietf.org; Thu, 01 Jun 2006 11:46:47 -0400 Date: Thu, 1 Jun 2006 15:46:44 -0060 From: "Bruce Houser" X-Mailer: The Bat! ({THEBAT_3_VER}) {THEBAT_3_TYPE} Reply-To: "Bruce Houser" X-Priority: 3 (Normal) Message-ID: <{DIG}.20060601154644@mail.ru> To: eap-archive@ietf.org Subject: should SAMUEL profile ANDY MIME-Version: 1.0 Content-Type: text/plain; charset={THEBAT_ENG_CHARSET} Content-Transfer-Encoding: 7bit X-Spam-Score: 3.2 (+++) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 ABSY May Be Positioned To Make A Significant Move In The Mark et. Do Your Rese arch Now! AbsoluteSKY ABSY AbsoluteSKY Featured in Exclusive Interview, Just out today go listen now.... With More Breaking News Below, Now Is The Time To Look Closely at ABSY More Major News has been released! Item level RFID tagging for retailers available now! AbsoluteSKY and Universal Surveillance Systems Sign Strategic Partnership Agreement for Retail RFID Products Universal has been providing intelligent security solutions to leading retailers worldwide since 1996. By combining innovative and state of the art technology with unsurpassed customer service, Universal has quickly become the fastest growing company in the Loss Prevention industry. The company's distinguished clientele of specialty retailers includes Nordstrom, Nike Inc., The Sports Authority, Stein Mart, Bed Bath & Beyond, all of the May Company divisions and the Virgin Group. ``The unique expertise, reputation and retail market presence of Universal represents a perfect fit for us,'' commented John Frabasile, AbsoluteSKY's President and CEO. ``This strategic partnership will leverage our enormous synergies beginning with our extensive knowledge of retail operations to bring our clients unsurpassed efficiencies and cost-saving solutions. Universal also brings us a large, powerful and professional sales force currently dedicated to our focus market of specialty retailers, as well as major relationships with retailers that span the globe.'' Industry experts have predicted the RFID industry to grow to over $2B U.S. worldwide in 2006, with the retail sector accounting for almost half of this figure in the U.S. alone, becoming over $3B US by 2008 W at ch this co mpany star ting n w. Information within this report contains forward looking statements within the meaning of Section 2 7 A of the Securi ti es Act of 1 933 and Sect ion 2 1B of the S E C A ct of 1 934. Statements that involve discussions with respect to projections of future events are not statements of historical fact and may be forward looking statements. Don't rely on them to make a decision. The Company is not a reporting company registered under the Exchange Act of 1934. We have received three hundred twenty five thousand free trading shares from a third party not an officer, director or affiliate shareholder. We intend to sell all our shares which could cause the stock to go down, resulting in losses for you. Read the Company's Annual Report and Information Statement if one is available before you invest. This report shall not be construed as any kind of investment advice or solicitation. You can lose all your money by investing in this stock. Alone walk i a own help get because are, when i how i own my do my i the i'll. Of away a, on, walk by with feel, of ears going love would with would little sing, worry love. The me little, help of with. It with does sing help up my. I be does little with, my and. Tune help going, day. Tune be me of would by get and own on. Your does, by the, with, i'll friends, think and are sing little a my get. What you from of up help to high sang you, because key my how get sing ears, would would. Ears out i'll my be tune to on by not i to song sing think if walk, me. And, what do, a with me when out. Of how i'll song sang key me with out own i help day and is i would. Help little with, get by, your help , i of friends sad my little i up of. You help a little help, i i with you, worry on to my. If out you you're sad from love friends the i a help be me. Tune would by get and own on, does does, by the, with, i'll friends, think and are. From eap-bounces+eap-archive=lists.ietf.org@frascone.com Thu Jun 01 17:16:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FluWV-0001R9-93 for eap-archive@lists.ietf.org; Thu, 01 Jun 2006 17:16:07 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FluWT-0004MB-Nl for eap-archive@lists.ietf.org; Thu, 01 Jun 2006 17:16:07 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id CD38243012D for ; Thu, 1 Jun 2006 14:16:04 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id EE3BB430054 for ; Thu, 1 Jun 2006 14:15:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id DC57F4317EA for ; Thu, 1 Jun 2006 14:15:50 -0700 (PDT) Received: from swip.net (mailfe01.tele2.fr [212.247.154.12]) by hermes.tigertech.net (Postfix) with ESMTP id 752244317E0 for ; Thu, 1 Jun 2006 14:15:46 -0700 (PDT) X-T2-Posting-ID: TlrHmwDFCX01iQZd0Fm6v3T8FBlCqve5GwI1mWaefYU= X-Cloudmark-Score: 0.000000 [] Received: from [80.170.148.89] (HELO DELL.tele2.fr) by mailfe01.swip.net (CommuniGate Pro SMTP 5.0.8) with ESMTP id 187018160; Thu, 01 Jun 2006 23:15:40 +0200 Message-Id: <5.2.1.1.0.20060601230908.038f9ca0@pop.infres.enst.fr> X-Sender: eu968071@pop.tele2.fr X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 01 Jun 2006 23:15:26 +0200 To: eap@frascone.com From: Pascal Urien Mime-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO X-Spam-Level: Cc: aboba@internaut.com Subject: [eap] Identity Protection in EAP-TLS X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Hi Everybody, A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Identity Protection within EAP-TLS Author(s) : P. Urien, M. Badra Filename : draft-urien-badra-eap-tls-identity-protection-00.txt Pages : 7 Date : 2006-5-31 This document defines a mechanism providing EAP-TLS identity protection. It defines new TLS extension, in order to negotiate the symmetric encryption algorithm that is used to encrypt or decrypt the client's certificate. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-urien-badra-eap-tls-identity-protection-00.txt Pascal _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From Noelrhuxcy@yubanet.com Fri Jun 02 05:41:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm69j-0002Wb-UG; Fri, 02 Jun 2006 05:41:23 -0400 Received: from c87-182.icpnet.pl ([62.21.87.182] helo=1F42AE8) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fm69h-0007Ss-3x; Fri, 02 Jun 2006 05:41:23 -0400 Received: from inductance by jpost.com with SMTP id QvJZjVH4Nl for ; Fri, 02 Jun 2006 04:41:17 -0600 Received: (qmail 16703 invoked by alias); Fri, 02 Jun 2006 15:32:17 +0500 X-Message-ID: <689606521846892.49207.Noelrhuxcy@yubanet.com> From: "Angel Putnam" To: "Ipv6-dir" Subject: Re: Reply Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 0622-3, 2006-06-01), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 3.6 (+++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Contact us NOW to receive your diploma within days, and start improving your life! Bachelors, Masters, MBA and/or Doctorate (PhD) NO ONE is turned down. Call Now 7 days a week. 1-206-984-0002 According to the U.S. Census Bureau, with the following degrees, here is how much you can expect to make in your lifetime: High School Diploma: $1,100,000 Bachelors Degree: $2,100,000 Masters Degree: $2,500,000 Doctorate: $4,400,000 You Need a Better Degree, and we can Help! Obtain degrees from Prestigious non-accredited Universities based on you life experience. NO ONE is turned down. Call Now 7 days a week, 24 hours a day. 1-206-984-0002 Regards, Professor. Brenda Marino From bmastgr@1-for-all-freebies.com Fri Jun 02 12:17:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmCKi-00036M-Q4 for eap-archive@ietf.org; Fri, 02 Jun 2006 12:17:08 -0400 Received: from [86.104.138.112] (helo=tina) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmCKe-0006sM-VD for eap-archive@ietf.org; Fri, 02 Jun 2006 12:17:08 -0400 Message-ID: <662161c80604{SYMBOL_LC}@mx1.balanced.postal.mail.dreamhost.com> Date: Fri, 2 Jun 2006 16:18:35 -0120 From: "Denny Fowler" To: eap-archive@ietf.org Subject: Microcap Stock Trading Idea For You MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam: Not detected X-Spam-Score: 1.8 (+) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 ALERT ISSUED Already up 0.45 in the last 3 days of trading! Fa lcon Ene rgy, Inc. F C Y I 1 week ago $0.88 Today 1.98 Up from 1.60 Wend 5 Day Expected 2.90 Market Plus Top four Pick There is a big PR campaign running all week!! This Is Going To Explode! Is FCYI Ready To Go? If You Think So, You Know what to Do... VANCOUVER, British Columbia, May 26, 2006 -- Falcon Energy, Inc. is pleased to announce that it will be initiating a detailed study for two of the properties for which it holds exploration licenses in Mongolia. The studies will be in preparation for a work program on the properties. Falcon Energy Inc. will seek to engage a geological team to study its properties and make recommendations for the commencement of a work program. Both properties hold great promise for the discovery of significant deposits of Uranium. The first property is the Huld License Area (license 9997X) The Huld license area is located on the territory of Dashbalbar soum of Dornot province. This property is situated 650 km NE of Ulaanbaatar and 170 km North of Choibalsan /province center/ and 50 km NE of the significant Mardai Uranium deposit. Production of Uranium ore from the Mardai deposit has ranged up to 195 tons annually. The second property is the Har Tolgoi License Area (license 9996X) The license area is located at the joint part of Tuvshinshiree, Monhhaan and Uubayan soums of Suhbaatar province. The Har Tolgoi license area comprises a total of 12,319 hectares. With the current bull market for Uranium, a number of companies are currently very active in Uranium exploration. The Western Prospector's team is focused on the a uranium project located in North-Eastern Mongolia with the 2006 exploration program, budgeted at US$16 million. UGL Enterprises also has holdings and great interest in the area. Current major Uranium discoveries in Mongolia include the Dornod Deposit which has 40,128,000 pounds grading 0.118%, 31,664,000 pounds grading 0.177% and 26,349,000 pounds grading 0.236% and the Gurvanbulag project (Western Prospector) which has a reported resource of 22,679,160 pounds grading 0.245% and an additional 19,183,616 pounds grading 0.135% (source: National Bank report February 25, 2005). Despite uranium spot prices in 2000 that touched lows of less than US$7.00 per pound for U3O8, the spot price has since increased to over US$37.00 per pound (January 30, 2006), and the long term Uranium market outlook remains positive with increased consumption, and future downtrend of secondary uranium sources. Uranium Deposits in Mongolia Soviet and Mongolian geologists began exploring for uranium in Mongolia in the 1940s. From 1967 to 1988 more systematic exploration for uranium was undertaken, and four major uranium deposits were defined in Mongolia, the Priargun, Gobi-Tamtsag, Khentii-Daur, and Northern Mongolian uranium provinces. Uranium deposits of economic value were discovered in the Dornod, Gurvanbulag, and Mardai areas of eastern Mongolia and the Kharaat area of southern Mongolia. The proven Uranium resources of Mongolia in these deposits are about 62,000 metric tons, From xcricrgje@fox44.com Sat Jun 03 13:45:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmaBV-0007MI-Jz for eap-archive@ietf.org; Sat, 03 Jun 2006 13:45:13 -0400 Received: from host110-109.pool80180.interbusiness.it ([80.180.109.110]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FmaBU-0001oX-5Q for eap-archive@ietf.org; Sat, 03 Jun 2006 13:45:13 -0400 Received: (qmail 26966 invoked from network); Sat, 3 Jun 2006 19:45:10 +0200 Received: from unknown (HELO qat.cf) (80.180.142.29) by host110-109.pool80180.interbusiness.it with SMTP; Sat, 3 Jun 2006 19:45:10 +0200 Message-ID: <000601c68735$75e116ee$1d8eb450@qat.cf> From: "Reginald Rush" To: Subject: hated conspiratorial Date: Sat, 3 Jun 2006 19:36:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 3.7 (+++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Trading alert! This company has dropped big new's in the past. Who's to say they don't have another big one. They have cash and have made great strategic aquisitions. Date : 05.06.06 Company : Wataire Industries Inc. S t o c k : W T A F Price : $0.60 4-5 Day Trading : $2 - $3 Expectations : 100-300% Will it go crazy tomorrow morning? This is your chance to get in while it is still low. Remember this is a S T R O N G B U Y RECOMMENDATION... From eap-bounces+eap-archive=lists.ietf.org@frascone.com Sat Jun 03 19:43:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmfmV-0008QL-2U for eap-archive@lists.ietf.org; Sat, 03 Jun 2006 19:43:47 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmfmR-0003D2-6M for eap-archive@lists.ietf.org; Sat, 03 Jun 2006 19:43:47 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4F82E430193 for ; Sat, 3 Jun 2006 16:43:42 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id D7DD74300E2 for ; Sat, 3 Jun 2006 16:43:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id C556439801E for ; Sat, 3 Jun 2006 16:43:23 -0700 (PDT) Received: from hotmail.com (bay106-f16.bay106.hotmail.com [65.54.161.26]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1C385398013 for ; Sat, 3 Jun 2006 16:43:22 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 3 Jun 2006 16:43:21 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Sat, 03 Jun 2006 23:43:17 GMT X-Originating-IP: [208.54.44.203] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Sat, 03 Jun 2006 16:43:17 -0700 Mime-Version: 1.0 X-OriginalArrivalTime: 03 Jun 2006 23:43:21.0528 (UTC) FILETIME=[7F640380:01C68767] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.748 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Subject: [eap] AD Review of EAP POTP X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: bd8a74b81c71f965ca7918b90d1c49c0 ---------- Forwarded message ---------- Date: Wed, 31 May 2006 00:48:39 +0300 From: Jari Arkko To: magnus@rsasecurity.com Subject: AD review of EAP POTP Magnus, I have done my AD review on your document. Overall, I was quite happy with the document -- its well written and seems clear. Some comments below, however. I would suggest that you will revise the document where necessary and resubmit, at which time we can initiate the actual processing, and also call the document into the attention of the IETF community (e.g. EAP/EMU folks). Russ: it would be great if you too could review this, or organize a review in the secdir. The most interesting focus for the review would be the crypto parts. ---- >Even though the authenticator in practice may function as a client >with respect to the backend authentication server, relaying >authentication credentials et cetera as needed, both servers are, >unless explicitly mentioned, collectively denoted as "the EAP server" >here. This seems to re-define the term "EAP Server" in a manner inconsistent with RFC 3748. Please modify to avoid confusion. >4.1 overview Comment only - take this into account if you find a good way to do it: It was unable to convince myself that this description covers all the cases. But perhaps it doesn't have to, its an overview. Maybe it is written in too normative style to begin with. >They MUST also >consider the validity of certain algorithm combinations. Be more specific. >If the authentication of the peer fails, the EAP server SHOULD >send another EAP-Request containing an OTP TLV and a Server-Info >TLV with the N bit set to indicate that no session resumption is >possible. The EAP server MAY also send an EAP-Failure message, >possibly preceded by an EAP-Request of type Notification (2). This is correct, but I presume that if EAP Failure is sent, that's the end of the EAP operation and we do not try again. I'm hoping that that's what you mean here, because otherwise it would be in violation of RFC 3748. >Sessions MUST NOT be maintained longer than the security of the >exchange which created the session permits. E.g. if it is estimated >that an attacker could be successful in brute-force searching for the >OTP in 24 hours, then EAP-POTP session lifetimes should be clearly >less than this value. This MUST NOT is problematic, because its hard to evaluate the security of the exchange in exact terms; I would suggest "NOT RECOMMENDED to" be used instead. >The MSK may be used as an ISK_i, for some i, as described in Section >2.5 of [14]. It may also be used as a basis for an AAA-Key (see >[15]) when setting up security associations between peers, or as a >starting point for derivation of MPPE [16] keys (see Appendix C). >The EMSK is reserved for future use. I would prefer just saying "The use of the MSK and EMSK is defined in [RFC 3748] and [eap-keying]." instead of the two paragraphs above. Its certainly meant to be so that whatever MSK is used for, the MSK from EAP POTP can be used for that as well. >Instead, when a peer cannot continue an EAP-POTP session either due >to the server not being able to authenticate itself or due to some >other reason There's something wrong in this sentence. Maybe you meant ... the peer is unable to authenticate the server or ..."? Also, it would be very useful to spell out the "some other reason" part in more detail, so that people can implement this. >The EAP Identity method MUST NOT be used within an EAP-POTP session. This may be more confusing than helpful. You do allow EAP Identity at the beginning (Sect 4.1) and RFC 3748 Section 2.1 already prohibits other use of EAP Identity. >Reserved > > Reserved for future use. This octet MUST be set to zero for this > version. And ignored upon reception? Multiple places in the document. >In an 802.1x EAP over LAN (EAPOL) environment, the P bit MUST be >set, or, alternatively, the EAP-POTP method MUST be carried out >inside an authenticated tunnel such as those provided by [14] or >[17]. This seems somewhat weird recommendation. Why LAN and not Wireless LAN? What about all the other scenarios where protection would be needed? Also, how does the EAP method know what purpose it is being run for... I would suggest saying something different, e.g. "It is RECOMMENDED that the protected mode of EAP-POTP (or an authenticated tunnel [14]) is used for authentication in wireless environment. And the statement would be more appropriate in the security considerations than in the bit-level description. >In an EAP-Request, the T bit, when set, indicates that the OTP to >calculate MUST NOT include a user PIN. > >In an EAP-Response, the T bit, when set, indicates that the OTP >was calculated without the use of a user PIN. The T bit MUST be >set in a response if and only if the EAP-Request which triggered >the response contained an OTP TLV with the T bit set. Isn't there a policy question on the client's side, whether the client wants to use his authentication token without his personal authorization via a PIN? Perhaps the client should be allowed to decline this. I think it can already via an empty response, but it would be good to confirm this explicitly in the spec. >Authentication Data > >EAP-Request: In an EAP-Request, the Authentication Data, when > present, contains an optional "challenge". I found the optionality of this field and the use of the C bit confusing. What if C=1 and datalen=0 or C=0 and datalen>0? >The following applies to the auth_id component: >(snip) > - For IP-based EAP, "auth_id" SHALL either be the empty > string or the IPv4 or IPv6 address of the authenticator > in binary format (4 respectively 16 octets). As an > example, the IPv4 address "10.129.13.15" would be > represented as (in hex) 0A 81 0D 0F, whereas the IPv6 > address "0A0A:0B0B:0C0C:0D0D:0E0E:0F0F:1010:1111" would > be represented as (in hex) 0A 0A 0B 0B 0C 0C 0D 0D 0E 0E > 0F 0F 10 10 11 11. Which IP address? What if the authenticator has an "outer" IP address as an IKEv2 gateway having a public IP address and an "inner" address, as in the same gateway having dot ten address in the corporate network? >At least one of the User Identifier TLV and the Token Key Identifier >TLV MUST be present in the session's first EAP-Response of type >POTP-X that also carries an OTP TLV unless a suitable identity has >been provided in a preceding EAP-Response of type Identity (1). This MUST seems too strong, see Section 2 of RFC 3748 for cases where other means may be used to determine the identity of the client. This should still be allowed even in EAP-POTP. > This document is a description of a general EAP method for OTP > tokens. It also defines EAP method 32 as a profile of the general > method. It has no actions for IANA. Extending the set of EAP-POTP > TLVs or the set of EAP-POTP cryptographic algorithms shall be seen as > revisions of the protocol and hence requiring an RFC that updates, or > obsoletes this document. I'd prefer seeing a new namespace created for EAP-POTP TLVs, with a specific policy (e.g. Specification Required and IESG Approval). >This TLV type may be sent by EAP servers as well as by peers and >SHOULD be supported by all entities conforming to this specification >(it need not be supported if an entity never will have a need to >continue a POTP-X conversation after exchange of the Confirm TLV). A peer would not necessarily know if the server wants it to continue. Should this be mandatory? While an expert review per se is not needed for this submission (given the already existing allocation), I have also reviewed the document from this perspective -- see below. >1. Does the method document its security properties >in sufficient manner, as required by Section 7.2 >of RFC 3748? > >1a. Mechanism. Is the mechanism explained? Yes. >1b. Security claims. Are the claimed and not claimed >properties listed? Yes. >1c. Justifications for the claims? Is an explanation or >reference provided to each of the claims? Yes. >1d. Key strength. Is the key strength documented? Only the parameters that affect it are specified. For a more useful security considerations section, at least an example should be provided. >1e. Description of key hierarchy. Is the key hierarchy >documented? Yes. >[Optional, at least for now: does it conform to EAP >keying framework?] Yes. >1f. Indication of vulnerabilities. Are the known vulnerabilities >documented? Yes. >[Note: it seems unreasonable to require the documentation >of unknown vulnerabilities :-) The "known" may of course be >"known to reviewer" or "known to author" or "known to the >community", but that appears to be best we can do.] > >2. Compliance with EAP packet formats > >2a. Does the method comply with the packet formats >defined in Section 4 of RFC 3748? Yes. >3. Compliance with EAP behaviour > >3a. Does the method comply with Success/Failure usage >as defined in Sections 2, 2.2, and 4.2? Yes. >3b. Does the method comply with sequence usage as defined >in Section 2.1 of RFC 3748? Yes. >3c. Does the method comply with request/response processing >rules as defined in Section 4.1 of RFC 3748? Yes. >3d. Does the method comply with retransmission rules >as defined in Section 4.3 of RFC 3748? Yes. >3e. Does the method comply with the usage defined for >Identity, as defined in Section 5.1 of RFC 3748? Yes. >3f. Does the method comply with the usage defined for >Notification, as defined in Section 5.2 of RFC 3748? Yes. >3g. Does the method comply with the usage defined for >Nak and Expanded-Nak as defined in Section 5.3 of RFC 3748? Yes. >3h. Does the method comply with the MIC usage requirements >from Sections 3.1, 7.5, and 7.8 of RFC 3748? Part 1: No. MIC checking is not sufficiently required in Section 4.10.15, and the entire Protected TLV is optional. Part 2: Yes. Section 7.5 recommends covering all EAP fields, but EAP-POTP does not do this. However, the explanation appears sufficient grounds for going against the recommendation. >4. Compliance with IANA requirements > >4a. Does the method comply with EAP-based IANA requirements >defined in Section 6 of RFC 3748? That is, if it requests >the allocation of new numbers in the EAP namespace [not >applicable if the numbers have already been allocated], >is the type of the document and process appropriate for the >desired action? Yes. >4b. Does the method comply with other IANA requirements in >the IETF standards track RFCs? For instance, does the >method attempt to allocate TLS extensions (which would >only be possible for standards track RFCs)? Yes (complies). _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Sat Jun 03 21:16:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmhEO-0006iA-Vr for eap-archive@lists.ietf.org; Sat, 03 Jun 2006 21:16:40 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmhEN-0003jn-6D for eap-archive@lists.ietf.org; Sat, 03 Jun 2006 21:16:40 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 432124301A9 for ; Sat, 3 Jun 2006 18:16:38 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id E020E4300E2 for ; Sat, 3 Jun 2006 18:16:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CB089144800A for ; Sat, 3 Jun 2006 18:16:21 -0700 (PDT) Received: from hotmail.com (bay106-f11.bay106.hotmail.com [65.54.161.21]) by hermes.tigertech.net (Postfix) with ESMTP id 0D2AF1448001 for ; Sat, 3 Jun 2006 18:16:20 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 3 Jun 2006 18:16:19 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Sun, 04 Jun 2006 01:16:16 GMT X-Originating-IP: [208.54.44.203] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Sat, 03 Jun 2006 18:16:16 -0700 Mime-Version: 1.0 X-OriginalArrivalTime: 04 Jun 2006 01:16:19.0773 (UTC) FILETIME=[7C48A6D0:01C68774] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=1.7 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Subject: [eap] Proposed Resolution to Issue 367: Key Scope and Server Authorization X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 The text of Issue 367 is enclosed below. The proposed resolution is to change Section 2.2 to the text enclosed below, as well as to add a new Section 2.2.1, as follows: 2.2. Peer and Authenticator Architecture This specification does not impose constraints on the architecture of the EAP authenticator or peer. Any of the authenticator architectures described in [RFC4118] can be used. As a result, lower layers need to identify EAP peers and authenticators unambiguously, without incorporating implicit assumptions about peer and authenticator architectures. For example, it is possible for multiple base stations and a "controller" (e.g. WLAN switch) to comprise a single EAP authenticator. In such a situation, the "base station identity" is irrelevant to the EAP method conversation, except perhaps as an opaque blob to be used in Channel Bindings. Many base stations can share the same authenticator identity. It should be understood that an EAP authenticator or peer: [a] may contain one or more physical or logical ports; [b] may advertise itself as one or more "virtual" authenticators or peers; [c] may utilize multiple CPUs; [d] may support clustering services for load balancing or failover. Both the EAP peer and authenticator may have more than one physical or logical port. A peer may simultaneously access the network via multiple authenticators, or via multiple physical or logical ports on a given authenticator. Similarly, an authenticator may offer network access to multiple peers, each via a separate physical or logical port. When a single physical authenticator advertises itself as multiple "virtual authenticators", it is possible for a single physical port to belong to multiple "virtual authenticators". An authenticator may be configured to communicate with more than one EAP server, each of which is configured to communicate with a subset of the authenticators. The situation is illustrated in Figure 3. +-+-+-+-+ | EAP | | Peer | +-+-+-+-+ | | | Peer Ports / | \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ Authenticator | | | | | | | | | Ports +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ | | | | | | | Auth1 | | Auth2 | | Auth3 | | | | | | | +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ \ | \ | \ | \ | \ | \ | EAP over AAA \ | \ | (optional) \ | \ | \ | \ | \ | \ | \ | \ | +-+-+-+-+-+ +-+-+-+-+-+ Backend | EAP | | EAP | Authentication | Server1 | | Server2 | Servers +-+-+-+-+-+ +-+-+-+-+-+ Figure 3: Relationship between EAP peer, authenticator and server 2.2.1. Server Identification The EAP method conversation is between the EAP peer and server, as identified by the Peer-Id and Server-Id. As shown in Figure 3, an authenticator may be configured to communicate with multiple EAP servers; the EAP server that an authenticator communicates with may vary according to configuration and network and server availability. While the EAP peer can assume that all EAP servers within a realm have access to the credentials necessary to validate an authentication attempt, it cannot assume that all EAP servers share persistent state. Authenticators may be configured with different primary or secondary EAP servers, in order to balance the load. Also, the authenticator can dynamically determine the EAP server to which requests will be sent; in event of a communication failure, the authenticator may fail over to another EAP server. For example, in Figure 3, Authenticator2 may be initially configured with EAP server1 as its primary backend authentication server, and EAP server2 as the backup, but if EAP server1 becomes unavailable, EAP server2 may become the primary server. In general, the EAP peer cannot direct an authentication attempt to a particular EAP server within a realm; this decision is made solely by the authenticator. Nor can it determine which EAP server it will be communicating with within a realm, prior to the start of the EAP method conversation. The Server-Id is not included in the EAP- Request/Identity, and since the authenticator determines the EAP server dynamically, it typically is not possible for the authenticator to advertise the Server-Id during the discovery phase. EAP methods may or may not export the Server-Id, and as a result, the EAP peer may not even learn which server it was conversing with after the EAP conversation completes successfully. As a result, an EAP peer, on connecting to a new authenticator or reconnecting to the same authenticator, may find itself communicating with a different EAP server. Fast reconnect, defined in [RFC3748] Section 7.2, may fail if the EAP server that the peer communicates with is not the same one with which it initially established a security association. For example, an EAP peer attempting an EAP-TLS session resume may find that the new EAP-TLS server will not have access to the Master Key identified by the TLS Session-Id, and therefore the session resumption attempt will fail, requiring completion of a full EAP-TLS exchange. ========================================================== Issue 367: Key Scope and EAP Server Authorization Submitter name: Joe Salowey Submitter email address: jsalowey@cisco.com Date Submitted: May 3, 2006 Reference: http://lists.frascone.com/pipermail/eap/msg04231.html Document: KEYING-12 Comment type: 'T'echnical Priority: '1' Should fix Section: 2.2.1 and 3.2 Rationale/Explanation of issue: Section 1.4.1 correctly defines the scope of the EAP keying material as being defined by the EAP Peer and EAP server, however this relationship is not carried out in other key scope discussions as far as I can tell. In order for channel binding, key mixing etc. to work the peer must make sure that the key is used not just within the authorized parameters of the lower layer, but of the authorized scope of the EAP server as well. I'm not sure of all of all the places where this needs to be addressed, but I think it needs to be addressed in section 2.2.1 perhaps by adding "[g] Verifying that the advertised scope is within the scope that the EAP server is allowed to authorize" Section 3.2 should probably state somewhere that: "The peer should verify that the key scope advertised by the authenticator is within the scope that is allowed to be authorized by the EAP Server." [Bernard Aboba] I think I see the point, which is that a given authenticator may be connected to more than one EAP server, and that all authenticators in a realm may not share the same EAP server. Also, EAP servers cannot necessarily be assumed to share key state among each other. If the selcted EAP method does not provide the Server-Id, then the peer cannot know the scope of the keys it derives with the EAP server. This can create a number of issues, such as a peer attempting (but failing) a fast reconnect because the server that the authenticator is configured to communicate with is not the same one with which the peer established the previous session. However, there are other situations in which the server identity is not material, such as handoff in an 11r Mobility Domain (MD), where the STA only care whether a candidate AP is in the same MD, not whether the new authenticator is configured to talk to the same backend authentication server as the current or initial AP. In practice, the peer determines whether an authenticator is within the scope of authorization of the backend authentication server by attempting to complete the SAP exchange with it. If the exchange succeeds, the authenticator is authorized; if not, it isn't. It is possible for the peer to attempt a fast reconnect exchange with the wrong server; unless the server were to include its identity in the EAP-Request there is no way for the peer to determine what server it is talking to before the EAP method conversation gets underway. Even if the authenticator were to advertise the server(s) that it is configured to talk to, and even if those servers were identified by their Server-Ids, it would not be possible for the peer to know a-priori which server it was going to talk to, since the primary server can change due to changes in network or server availability. Given this, I'm not sure how the peer can verify that an authenticator is allowed to be authorized by an EAP server. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Sat Jun 03 21:57:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmhsK-0004Rb-71 for eap-archive@lists.ietf.org; Sat, 03 Jun 2006 21:57:56 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmhcH-00077u-Df for eap-archive@lists.ietf.org; Sat, 03 Jun 2006 21:41:22 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 157DC4301A4 for ; Sat, 3 Jun 2006 18:41:21 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 572F34300CD for ; Sat, 3 Jun 2006 18:41:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 400DF144800C for ; Sat, 3 Jun 2006 18:41:04 -0700 (PDT) Received: from hotmail.com (bay106-f22.bay106.hotmail.com [65.54.161.32]) by hermes.tigertech.net (Postfix) with ESMTP id 8761D144800A for ; Sat, 3 Jun 2006 18:41:01 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 3 Jun 2006 18:41:01 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Sun, 04 Jun 2006 01:40:58 GMT X-Originating-IP: [208.54.44.203] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Sat, 03 Jun 2006 18:40:58 -0700 Mime-Version: 1.0 X-OriginalArrivalTime: 04 Jun 2006 01:41:01.0078 (UTC) FILETIME=[EF35DB60:01C68777] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=1.7 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Subject: [eap] Proposed Resolution to Issue 357: Channel Binding Definition X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b The text of Issue 357 is enclosed below. The proposed resolution is to accept the definition proposed by Jari Arkko: "Channel Binding A secure mechanism for ensuring that a chosen set of channel properties (such as endpoint identifiers) are agreed upon by the EAP peer, authenticator and server." ------------------------------------------------------------------------------------------------ Issue 357: Channel Binding Definition Submitter name: Vidya Narayanan Submitter email address: vidyan@qualcomm.com Date Submitted: May 1, 2006 Reference: http://lists.frascone.com/pipermail/eap/msg04227.html Document: KEYING-12 Comment type: 'T'echnical Priority: '1' Should fix Section: 1.2 Rationale/Explanation of issue: The document defines channel binding as a communication within an EAP method - this seems a bit restrictive, given that channel binding information could be carried out-of-band as well. The only requirement is that the information be integrity protected between the peer and server. Requested change: Change wording to: "The communication of integrity-protected channel properties such as endpoint identifiers which can be compared to values communicated via out of band mechanisms (such as via a AAA or lower layer protocol)." _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Sat Jun 03 22:40:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmiXT-0007NS-OE for eap-archive@lists.ietf.org; Sat, 03 Jun 2006 22:40:27 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmiXS-0003aY-2d for eap-archive@lists.ietf.org; Sat, 03 Jun 2006 22:40:27 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id DCE854301A8 for ; Sat, 3 Jun 2006 19:40:24 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 210D04300CD for ; Sat, 3 Jun 2006 19:40:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0E885398022 for ; Sat, 3 Jun 2006 19:40:08 -0700 (PDT) Received: from hotmail.com (bay106-f31.bay106.hotmail.com [65.54.161.41]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5F282398023 for ; Sat, 3 Jun 2006 19:40:06 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 3 Jun 2006 19:40:05 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Sun, 04 Jun 2006 02:40:01 GMT X-Originating-IP: [208.54.44.203] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Sat, 03 Jun 2006 19:40:01 -0700 Mime-Version: 1.0 X-OriginalArrivalTime: 04 Jun 2006 02:40:05.0993 (UTC) FILETIME=[3024F590:01C68780] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.748 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Subject: [eap] Proposed Resolution to Issue 365: Ambiguous Use of Identifier X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 The text of Issue 365 is enclosed below. The proposed resolution is to rewrite Section 2.2.1 (now 2.2.2) as follows: "2.2.2. Authenticator and Peer Identification The EAP method conversation is between the EAP peer and server. The authenticator identity, if considered at all by the EAP method, is treated as an opaque blob for the purposes of Channel Bindings (see Section 5.12). However, the authenticator identity is important in two other exchanges - the AAA protocol exchange and the Secure Association Protocol conversation. The AAA conversation is between the EAP authenticator and the backend authentication server. From the point of view of the backend authentication server, EAP keying material and parameters are transported to the EAP authenticator identified by the NAS-Identifier attribute. Since an EAP authenticator MUST NOT share EAP keying material or parameters with another party, if the EAP peer or backend authentication server detects use of EAP keying material and parameters outside the scope defined by the NAS-Identifier, the keying material MUST be considered compromised. The Secure Association Protocol conversation is between the peer and the authenticator, and the authenticator and peer identities used within that exchange define the usage scope of the EAP keying material passed down to the lower layer. For lower layers which support key caching it is particularly important for the EAP peer, authenticator and backend server to have a consistent view of the usage scope of the transported EAP keying material. Since an authenticator may have multiple ports, the authenticator identifier used within the Secure Association Protocol exchange SHOULD be distinct from any port identifier (e.g. MAC address). Similarly, where a peer may have multiple ports, and sharing of EAP keying material and parameters between peer ports of the same link type is allowed, the peer identifier used within the Secure Association Protocol exchange SHOULD also be distinct from any port identifier. AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] provide a mechanism for the identification of AAA clients; since the EAP authenticator and AAA client are always co-resident, this mechanism is applicable to the identification of EAP authenticators. RADIUS [RFC2865] requires that an Access-Request packet contain one or more of the NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address attributes. Since a NAS may have more than one IP address, the NAS-Identifier attribute is RECOMMENDED for the unambiguous identification of the authenticator, both within the AAA protocol exchange the Secure Association Protocol conversation. It is RECOMMENDED that the EAP peer, authenticator and server use identities consistent between the conversation phases, in order to avoid a number of problems. For example, it is possible for problems to arise in situations where the backend server identifies itself differently to the EAP peer and authenticator (e.g. where the Server-Id and backend authentication server identity differ). Problems may also arise where the peer and authenticator identify themselves within the lower layer using a port identifier such as a link layer address. These include the following issues: [a] It may not be obvious to the peer which authenticator ports are associated with which authenticators. The EAP peer will be unable to determine whether EAP keying material has been shared outside its authorized scope, and needs to be considered compromised. The EAP peer may also be unable to utilize the authenticator key cache in an efficient way. [b] It may not be obvious to the authenticator which peer ports are associated with which peers. As a result, the authenticator may not be able to enable a peer to communicate with it utilizing multiple peer ports. [c] It may not be obvious to the peer which "virtual authenticator" it is communicating with. For example, multiple "virtual authenticators" may share a MAC address, but utilize different NAS-Identifiers. [d] It may not be obvious to the authenticator which "virtual peer" it is communicating with. Multiple "virtual peers" may share a MAC address, but utilize different Peer-Ids. [e] It may not be possible for the EAP peer and server to verify the authenticator identity via channel bindings. For example, problems [a], [c] and [e] occur in [IEEE-802.11i], which utilizes peer and authenticator MAC addresses within the 4-way handshake. Problems [b] and [d] do not occur since [IEEE-802.11i] only allows a peer to utilize a single port. The following steps enable lower layer identities to be securely verified by all parties: [a] Specifying the lower layer parameters used to identify the authenticator and peer; [b] Communicating the lower layer identities between the peer and authenticator within phase 0; [c] Communicating the lower layer authenticator identity between the authenticator and backend server within the NAS-Identifier attribute; [d] Including the lower layer identities within Channel Bindings (if supported) in phase 1a, ensuring that they are communicated between the EAP peer and server; [e] Supporting the integrity-protected exchange of identities within phase 2a; [f] Utilizing the advertised lower layer identities to enable the peer and authenticator to verify that keys are maintained within the advertised scope;" ------------------------------------------------------------------------------------------------------------ Issue 365: Ambiguous Use of Identifier Submitter name: Joe Salowey Submitter email address: jsalowey@cisco.com Date Submitted: May 2, 2006 Reference: http://lists.frascone.com/pipermail/eap/msg04268.html Document: KEYING-12 Comment type: 'T'echnical Priority: '1' Should fix Section: 2.2.1 Rationale/Explanation of issue: Ambiguous use of "identifier": It is not clear in this section what the identifier is and what it is identifying. Does this section mean to suggest that lower layer entities identify themselves using NAS-ID instead of layer addresses? I'm not sure that this is a good thing or even really possible. It seems that lower layer entities will identify themselves based on something related to lower layer addresses. It seems that if a lower layer implements key caching then it needs an identifier to identify the scope of the cache. This identifier can be the NAS-ID. I'm not quite sure I understand this section, but I think it just needs to be clearer about what identity is being talked about. This section does not contain any description of how existing lower layers deal with authenticator identity. Are such examples available? _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From mfydua@artisticat.com Sun Jun 04 15:51:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmydJ-0000p1-RX for eap-archive@ietf.org; Sun, 04 Jun 2006 15:51:33 -0400 Received: from 71-37-236-151.mpls.qwest.net ([71.37.236.151]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FmydI-0000FO-JM for eap-archive@ietf.org; Sun, 04 Jun 2006 15:51:33 -0400 Received: from wjsplc ([71.37.74.151]) by 71-37-236-151.mpls.qwest.net (8.13.2/8.13.2) with SMTP id k54JqQiF031031; Sun, 4 Jun 2006 14:52:26 -0500 Message-ID: <002601c68810$2bddac8e$974a2547@wjsplc> From: "Paddy Hawkins" To: Subject: businesslike Date: Sun, 4 Jun 2006 14:49:53 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1441 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 3.5 (+++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Investor Alert - WE HAVE A RUNNER ! Here is a special company that may be set to make a move in the near future - this could be your opportunity to be ahead of the curve! Trade Date : 5 June 2006 Name : Amerossi International Group Inc. Symbol : A M S N Today : $0.05 Tomorrow : $0.40 - $0.60 Status : 100-300% They have cash and have made great strategic aquisitions. This stock will explode. Do not wait until it is too late. Will it go crazy tomorrow morning? From HallieMerrill@terra.com.br Sun Jun 04 17:18:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmzzH-0000op-33 for eap-archive@ietf.org; Sun, 04 Jun 2006 17:18:19 -0400 Received: from abrw171.neoplus.adsl.tpnet.pl ([83.8.116.171] helo=TYGRYS) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmzzF-0000Wy-7m for eap-archive@ietf.org; Sun, 04 Jun 2006 17:18:19 -0400 From: "Hallie" To: Subject: fwd ctxe.pk Urgent statement Date: Sun, 4 Jun 2006 23:18:14 -0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: RW7SH3o0GdkNtDIOaHqgYF3Brl921n0ygIzX Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 1.7 (+) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Leading experts share top stockk picks and recommendations Get CTXE First Thing Today, This Is Going To Explode! Check out for Latest News! CTXE - CANTEX ENERGY CORP CURRENT_PRICE: $0.52 GET IT N0W! Before we start with the profile of CTXE we would like to mention something very important: There is a Big PR Campaign starting this weeek . And it will go all week so it would be best to get in NOW. Company Profile Cantex Energy Corporation is an independent, managed risk, oil and gas exploration, development, and production company headquartered in San Antonio, Texas. Recent News Cantex Energy Corp. Receiving Interest From the Industry as It Enters Next Phase of Development Cantex Energy Corp. (CTXE - News) is pleased to report the following on its Big Canyon Prospect in West Texas. Recent company announcements related to the acquisition of over 48,000 acres of a world-class prospect has captured the attention of many oil & gas industry experts and corporations, who have recently inquired into various participation opportunities ranging from sharing science technology to support findings or expertise to drill, operate and manage wells. Trace Maurin, President of Cantex, commented, "Although we are a small independent oil & gas company, we have a very unique 0pp0rtunity in one of the last under-explored world-class potential gas plays with no geopolitical risks and the industry is starting to take notice. As we prepare to prove up the various structures within our prospect later this month, we are increasing our efforts to communicate on our progress to our shareholders and investors. Our intention is to provide investors with a better understanding of the full potential of this prospect as we embark on the next phase of operations." Starting immediately the company will undertake CEO interviews, radio spots (which will be recorded and published on the company website), publication placements, introductions to small cap institutional investors and funds all in an effort to optimize market awareness and keep our shareholder well informed. Conclusion: The Examples Above Show The Awesome, Earning Potential of Little Known Companies That Explode Onto Investor's Radar Screens; Many of You Are Already Familiar with This. Is CTXE Poised and Positioned to Do that For You? Then You May Feel the Time Has Come to Act... And Please Watch this One Trade tomorrow! Go CTXE. Pen-ny sttocks are considered highly speculative and may be unsuitable for all but very aggressive investors. This Profile is not in any way affiliated with the featured company. This report is for entertainment and advertising purposes only and should not be used as investment advice. If you wish to stop future mailings, or if you feel you have been wrongfully placed in our membership, send a blank e mail with No Thanks in the sub ject to Exepcted pirce at the end of the week: $1.0! Top-performing stoocks recommended by investmnet experts This sttock is greeatly reccomended by agressive invesstors in a shhort term. Don't loose a chance to earnn. Improve your yearly gains with expert sttock advice ................................ Penny wise, pound foolish The pot calls the kettle black If there were no lossers there could be no winners Forgive and forget Yuh can't drink mauby and belch beer. Don't byte off more than you can view.. Dump husband in September, you have to get rid of the spiders When man done suck cane he dash peeling pan ground. Silence is the fence around wisdom He that is master of himself, will soon be master of othersPatience is bitter, but it bears sweet fruit The best things in life are free Those who cast the votes decide nothing Those who count the votes decide everything Coin a phrase From eap-bounces+eap-archive=lists.ietf.org@frascone.com Sun Jun 04 20:30:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn2zP-0005EK-3o for eap-archive@lists.ietf.org; Sun, 04 Jun 2006 20:30:39 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fn2wV-0004Qt-GR for eap-archive@lists.ietf.org; Sun, 04 Jun 2006 20:27:40 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 291EA43011E for ; Sun, 4 Jun 2006 17:27:39 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 2AAD74300B7 for ; Sun, 4 Jun 2006 17:27:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 155F61448016 for ; Sun, 4 Jun 2006 17:27:24 -0700 (PDT) Received: from hotmail.com (bay106-f19.bay106.hotmail.com [65.54.161.29]) by hermes.tigertech.net (Postfix) with ESMTP id 7E3B0144800F for ; Sun, 4 Jun 2006 17:27:21 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 4 Jun 2006 17:27:21 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Mon, 05 Jun 2006 00:27:18 GMT X-Originating-IP: [208.54.44.217] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Sun, 04 Jun 2006 17:27:18 -0700 Mime-Version: 1.0 X-OriginalArrivalTime: 05 Jun 2006 00:27:21.0026 (UTC) FILETIME=[CF113220:01C68836] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=1.7 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Subject: [eap] Proposed Resolution to Issue 356: Ciphersuite Independence X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa The text of Issue 356 is enclosed below. The proposed resolution is to replace the first paragraph of Section 3.7 with the following: 3.7. Key Strength As noted in Section 2.1, EAP lower layers determine TSKs in different ways. Where EAP keying material is utilized in the derivation, encryption or authentication of TSKs, it is possible for EAP key generation to represent the weakest link. In order to ensure that EAP methods produce keying material of an appropriate symmetric key strength, it is RECOMMENDED that EAP methods utilizing public key cryptography choose a public key that has a cryptographic strength providing the required level of attack resistance. This is typically provided by configuring EAP methods, since there is no coordination between the lower layer and EAP method with respect to minimum required symmetric key strength." ------------------------------------------------------------------------------------------ Issue 356: Ciphersuite Independence Submitter name: Joe Salowey Submitter email address: jsalowey@cisco.com Date Submitted: April 30, 2006 Reference: http://lists.frascone.com/pipermail/eap/msg04223.html Document: KEYING-12 Comment type: 'E'ditorial Priority: '2' May fix Section: 1.6.4 Rationale/Explanation of issue: Section 3.7 implies that there is a system level coordination between the strength of the keys exported by the EAP method and the strength of keys required by the lower layer. This section should reference this and indicate that the coordination is done outside of EAP. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Sun Jun 04 20:48:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn3Gh-0001xq-Fy for eap-archive@lists.ietf.org; Sun, 04 Jun 2006 20:48:31 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fn3Gf-0007nh-UR for eap-archive@lists.ietf.org; Sun, 04 Jun 2006 20:48:31 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4D77E430145 for ; Sun, 4 Jun 2006 17:48:29 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 69CA04300B7 for ; Sun, 4 Jun 2006 17:48:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 58F00398035 for ; Sun, 4 Jun 2006 17:48:10 -0700 (PDT) Received: from hotmail.com (bay106-f34.bay106.hotmail.com [65.54.161.44]) by zoidberg.tigertech.net (Postfix) with ESMTP id B83E939803F for ; Sun, 4 Jun 2006 17:48:07 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 4 Jun 2006 17:48:07 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Mon, 05 Jun 2006 00:48:03 GMT X-Originating-IP: [208.54.44.217] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: bernard_aboba@hotmail.com, eap@frascone.com Date: Sun, 04 Jun 2006 17:48:03 -0700 Mime-Version: 1.0 X-OriginalArrivalTime: 05 Jun 2006 00:48:07.0448 (UTC) FILETIME=[B5FE1980:01C68839] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=4.007 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, LONGWORDS, MSGID_FROM_MTA_HEADER, SPF_HELO_PASS, SPF_PASS X-Spam-Level: **** Subject: Re: [eap] Proposed Resolution to Issue 365: Ambiguous Use of Identifier X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 2.3 (++) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Looking over the proposed resolution, I think we can make it moreclear that we are not talking about replacing endpoint addresses with names. How about this? "2.2.2. Authenticator and Peer Identification The EAP method conversation is between the EAP peer and server. The authenticator identity, if considered at all by the EAP method, is treated as an opaque blob for the purposes of Channel Bindings (see Section 5.12). However, the authenticator identity is important in two other exchanges - the AAA protocol exchange and the Secure Association Protocol conversation. The AAA conversation is between the EAP authenticator and the backend authentication server. From the point of view of the backend authentication server, EAP keying material and parameters are transported to the EAP authenticator identified by the NAS-Identifier attribute. Since an EAP authenticator MUST NOT share EAP keying material or parameters with another party, if the EAP peer or backend authentication server detects use of EAP keying material and parameters outside the scope defined by the NAS-Identifier, the keying material MUST be considered compromised. The Secure Association Protocol conversation is between the peer and the authenticator. For lower layers which support key caching it is particularly important for the EAP peer, authenticator and backend server to have a consistent view of the usage scope of the transported EAP keying material. In order to enable this, it is RECOMMENDED that the Secure Association Protocol explicitly communicate the usage scope of the EAP keying material passed down to the lower layer, rather than implicitly assuming that this is defined by the authenticator and peer endpoint addresses. Since an authenticator may have multiple ports, the scope of the authenticator key cache may not be described by a single endpoint address. Similarly, where a peer may have multiple ports and sharing of EAP keying material and parameters between peer ports of the same link type is allowed, the extent of the peer key cache cannot be communicated by using a single endpoint address. Instead, it is RECOMMENDED that the EAP peer, authenticator and server consistently identify themselves utilizing explicit identifiers that SHOULD be distinct from endpoint addresses or port identifiers (e.g. IP or MAC addresses). AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] provide a mechanism for the identification of AAA clients; since the EAP authenticator and AAA client are always co-resident, this mechanism is applicable to the identification of EAP authenticators. RADIUS [RFC2865] requires that an Access-Request packet contain one or more of the NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address attributes. Since a NAS may have more than one IP address, the NAS-Identifier attribute is RECOMMENDED for explicit identification of the authenticator, both within the AAA protocol exchange and the Secure Association Protocol conversation. It is possible for problems to arise in situations where the backend server identifies itself differently to the EAP peer and authenticator (e.g. where the Server-Id and backend authentication server identity differ). Problems which may arise where the peer and authenticator implicitly identify themselves using endpoint addresses include the following: [a] It may not be obvious to the peer which authenticator ports are associated with which authenticators. The EAP peer will be unable to determine whether EAP keying material has been shared outside its authorized scope, and needs to be considered compromised. The EAP peer may also be unable to utilize the authenticator key cache in an efficient way. [b] It may not be obvious to the authenticator which peer ports are associated with which peers. As a result, the authenticator may not be able to enable a peer to communicate with it utilizing multiple peer ports. [c] It may not be obvious to the peer which "virtual authenticator" it is communicating with. For example, multiple "virtual authenticators" may share a MAC address, but utilize different NAS-Identifiers. [d] It may not be obvious to the authenticator which "virtual peer" it is communicating with. Multiple "virtual peers" may share a MAC address, but utilize different Peer-Ids. [e] It may not be possible for the EAP peer and server to verify the authenticator identity via channel bindings. For example, problems [a], [c] and [e] occur in [IEEE-802.11i], which utilizes peer and authenticator MAC addresses within the 4-way handshake. Problems [b] and [d] do not occur since [IEEE-802.11i] only allows a peer to utilize a single port. The following steps enable lower layer identities to be securely verified by all parties: [a] Specifying the lower layer parameters used to identify the authenticator and peer; [b] Communicating the lower layer identities between the peer and authenticator within phase 0; [c] Communicating the lower layer authenticator identity between the authenticator and backend server within the NAS-Identifier attribute; [d] Including the lower layer identities within Channel Bindings (if supported) in phase 1a, ensuring that they are communicated between the EAP peer and server; [e] Supporting the integrity-protected exchange of identities within phase 2a; [f] Utilizing the advertised lower layer identities to enable the peer and authenticator to verify that keys are maintained within the advertised scope;" _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Sun Jun 04 21:31:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn3wV-0005TR-HX for eap-archive@lists.ietf.org; Sun, 04 Jun 2006 21:31:43 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fn3wT-0003Pv-SG for eap-archive@lists.ietf.org; Sun, 04 Jun 2006 21:31:43 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id EC65343011D for ; Sun, 4 Jun 2006 18:31:40 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 069824300B7 for ; Sun, 4 Jun 2006 18:31:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id E2A7B39803F for ; Sun, 4 Jun 2006 18:31:19 -0700 (PDT) Received: from hotmail.com (bay106-f17.bay106.hotmail.com [65.54.161.27]) by zoidberg.tigertech.net (Postfix) with ESMTP id 32C2B398043 for ; Sun, 4 Jun 2006 18:31:16 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 4 Jun 2006 18:31:15 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Mon, 05 Jun 2006 01:31:15 GMT X-Originating-IP: [208.54.44.217] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Sun, 04 Jun 2006 18:31:15 -0700 Mime-Version: 1.0 X-OriginalArrivalTime: 05 Jun 2006 01:31:15.0577 (UTC) FILETIME=[BCA33E90:01C6883F] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.748 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Subject: [eap] Proposed Resolution to Issue 352: Channel Binding Issue X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 The text of Issue 352 is enclosed below. In looking through the document, I believe it is best that discussion of Channel Bindings be concentrated in Section 5.11. The proposed resolution is as follows: In Section 1.4, change the Channel Binding entry from: "Channel Bindings Channel Bindings include lower layer parameters that are verified for consistency between the EAP peer and server. In order to avoid introducing media dependencies, EAP methods that transport Channel Binding data MUST treat this data as opaque octets. Typically the EAP method imports Channel Bindings from the lower layer on the peer, and transmits them securely to the EAP server, which exports them to the lower layer or AAA layer. However, transport may occur from EAP server to peer, or may be bi- directional. On the side of the exchange (peer or server) where Channel Bindings are verified, the lower layer or AAA layer passes the result of the verification (TRUE or FALSE) up to the EAP method. While the verification can be done either by the peer or the server, typically only the server has the knowledge to determine the correctness of the values, as opposed to merely verifying their equality. See Section 5.11 for further discussion." To: "Channel Bindings Channel Bindings include lower layer parameters that are verified for consistency between the EAP peer and server. In order to avoid introducing media dependencies, EAP methods that transport Channel Binding data MUST treat this data as opaque octets. See Section 5.11 for further discussion." Replace Section 5.11 with the following: "5.11. Channel Binding It is possible for a compromised or poorly implemented EAP authenticator to communicate incorrect information to the EAP peer and/or server. This may enable an authenticator to impersonate another authenticator or communicate incorrect information via out- of-band mechanisms (such as via AAA or the lower layer). Where EAP is used in pass-through mode, the EAP peer does not verify the identity of the pass-through authenticator. Within the Secure Association Protocol, the EAP peer and authenticator only demonstrate mutual possession of the transported EAP keying material. This creates a potential security vulnerability, described in [RFC3748] Section 7.15. As described in the previous section, it is possible for a proxy to detect a AAA client attempting to impersonate another authenticator (such by sending incorrect Called-Station-Id [RFC2865], NAS- Identifier [RFC2865], NAS-IP-Address [RFC2865] or NAS-IPv6-Address [RFC3162] attributes via the AAA protocol). However, it is possible for a pass-through authenticator acting as a AAA client to provide correct information to the backend authentication server while communicating misleading information to the EAP peer via the lower layer. For example, a compromised authenticator can utilize another authenticator's Called-Station-Id or NAS-Identifier in communicating with the EAP peer via the lower layer. Also, a pass-through authenticator acting as a AAA client can provide an incorrect peer Calling-Station-Id [RFC2865][RFC3580] to the backend authentication server via the AAA protocol. As noted in [RFC3748] Section 7.15, this vulnerability can be addressed by EAP methods that support a protected exchange of channel properties such as endpoint identifiers, including (but not limited to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id [RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address [RFC2865], and NAS-IPv6-Address [RFC3162]. Using such a protected exchange, it is possible to match the channel properties provided by the authenticator via out-of-band mechanisms against those exchanged within the EAP method. Typically the EAP method imports Channel Bindings from the lower layer on the peer, and transmits them securely to the EAP server, which exports them to the lower layer or AAA layer. However, transport may occur from EAP server to peer, or may be bi-directional. On the side of the exchange (peer or server) where Channel Bindings are verified, the lower layer or AAA layer passes the result of the verification (TRUE or FALSE) up to the EAP method. While the verification can be done either by the peer or the server, typically only the server has the knowledge to determine the correctness of the values, as opposed to merely verifying their equality. For further discussion, see [I-D.arkko-eap-service-identity-auth]. It is also possible to achieve Channel Bindings without transporting data over EAP. For example, see [I-D.draft-ohba-eap-channel-binding]. In this approach the EAP method includes Channel Bindings in the calculation of exported EAP keying material, making it impossible for the peer and authenticator to complete the Secure Association Protocol if there is a mismatch in the Channel Bindings. However, this approach can only be applied where EAP methods generating key material are used along with lower layers that utilize the keying material. For example, this mechanism would not enable verification of Channel Bindings on wired IEEE 802 networks which do not support data frame protection." ---------------------------------------------------------------------------------------------------------- Issue 352: Channel Binding Issue Submitter name: Yoshihiro Ohba Submitter email address: yohba@tari.toshiba.com Date Submitted: April 25, 2006 Reference: http://lists.frascone.com/pipermail/eap/msg04216.html Document: Keying-12 Comment type: T Priority: 1 Section: 5.11 Rationale/Explanation of issue: Reference [I-D.draft-ohba-eap-aaakey-binding] should be obsoleted by its successor, i.e., [I-D.draft-ohba-eap-channel-binding] which provides more generic, complete and extensible way of channel binding. Note that pre-configuration of the parameter set on AS is an important property to achieve Channel Binding in 3-party key management. Change: " It is also possible to achieve Channel Bindings without transporting data over EAP. For example, see [I-D.draft-ohba-eap-aaakey-binding]. In this approach the authenticator informs the backend server about the Channel Binding parameters using AAA, and the backend server calculates transported keying material based on this parameter set, making it impossible for the peer and authenticator to complete the Secure Association Protocol if there was a mismatch in the parameters." to: " It is also possible to achieve Channel Bindings without transporting data over EAP. For example, see [I-D.draft-ohba-eap-channel-binding]. In this approach the backend server calculates transported keying material based on the parameter set pre-configured for the authenticator, making it impossible for the peer and authenticator to complete the Secure Association Protocol if there was a mismatch in the parameters." _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Sun Jun 04 23:04:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn5OQ-0000rW-00 for eap-archive@lists.ietf.org; Sun, 04 Jun 2006 23:04:38 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fn5OO-0004YS-6i for eap-archive@lists.ietf.org; Sun, 04 Jun 2006 23:04:37 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 40B8143010D for ; Sun, 4 Jun 2006 20:04:35 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id D5B784300B7 for ; Sun, 4 Jun 2006 20:04:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id A3ADF398016 for ; Sun, 4 Jun 2006 20:04:13 -0700 (PDT) Received: from hotmail.com (bay106-f30.bay106.hotmail.com [65.54.161.40]) by zoidberg.tigertech.net (Postfix) with ESMTP id 56501398043 for ; Sun, 4 Jun 2006 20:04:10 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 4 Jun 2006 20:04:09 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Mon, 05 Jun 2006 03:04:09 GMT X-Originating-IP: [208.54.44.217] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Sun, 04 Jun 2006 20:04:09 -0700 Mime-Version: 1.0 X-OriginalArrivalTime: 05 Jun 2006 03:04:09.0937 (UTC) FILETIME=[B7371410:01C6884C] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.748 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Subject: [eap] Proposed Resolution of Issue 361: Child Key Expiry X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 In looking at the discussion of this issue, and reviewing the text, it is not clear how useful it is to have EAP methods export the Key-Lifetime parameter. Today no EAP methods export this parameter, and the text in Section 1.4 suggests that this is not very useful anyway: Key-Lifetime While EAP itself does not support key lifetime negotiation, it is possible to specify methods that do. However, systems that rely on such negotiation for exported keys would only function with these methods. As a result, it is NOT RECOMMENDED to use this approach as the sole way to determine key lifetimes. Similarly, Section 3 states: Existing EAP methods do not export the Key-Lifetime parameter; in the interest of method independence, key management of exported or derived keys SHOULD NOT be provided within EAP methods. As a result, it may make sense to remove discussion of the Key-Lifetime parameter from the document. The text of Issue 361 is enclosed below. The proposed resolution is as follows: In Section 1.4, delete: " Key-Lifetime While EAP itself does not support key lifetime negotiation, it is possible to specify methods that do. However, systems that rely on such negotiation for exported keys would only function with these methods. As a result, it is NOT RECOMMENDED to use this approach as the sole way to determine key lifetimes." Also, delete the Key-Lifetime parameter from Figure 2. In Section 3, change: "Existing EAP methods do not export the Key-Lifetime parameter; in the interest of method independence, key management of exported or derived keys SHOULD NOT be provided within EAP methods." To: "Existing EAP methods do not manage the lifetime of exported EAP keying material; in the interest of method independence, key management of exported or derived keys SHOULD NOT be provided within EAP methods." Change Section 3.3 to the following: "3.3. Parent-Child Relationships When an EAP re-authentication takes place, new keying material is derived and exported by the EAP method, which eventually results in replacement of TSKs, regardless of the way they are derived (see Section 2.1). Thus in practice replacement of TSKs is implied by EAP re-authentication. As a result, it is not possible for TSKs or other keying material derived from the MSK/EMSK to have a longer lifetime than the exported EAP keying material. This is true even where exported EAP keying material is only used for entity authentication and is not used for key derivation (such as in IKEv2), so that compromise of exported EAP keying material does not imply compromise of the TSKs or child keys. However, where child keys are derived from or are wrapped by EAP keying material, compromise of the MSK/EMSK does imply compromise of the child keys. While the lifetime of TSKs or child keys can be less than or equal that of the exported keying material they are derived from, it cannot be greater. Child keys that are used frequently (such as TSKs which are used for traffic protection) can expire sooner than the exported EAP keying material from which they are derived, so that it is advantageous to support re-key of child keying material prior to EAP re-authentication. Failure to mutually prove possession of exported EAP keying material during the Secure Association Protocol exchange need not be grounds for deletion of the keying material by both parties; rate-limiting Secure Association Protocol exchanges could be used to prevent a brute force attack." Change Section 3.5 to the following: "3.5. Exported and Calculated Key Lifetimes All EAP methods generating keys are required to generate the MSK and EMSK, and may optionally generate the IV. However, EAP, defined in [RFC3748], does not itself support the negotiation of lifetimes for exported keying material such as the MSK, EMSK and IV. Several mechanisms exist for managing key lifetimes: [a] AAA attributes. AAA protocols such as RADIUS [RFC2865] and Diameter [RFC4072] support the Session-Timeout attribute. The Session-Timeout attribute represents the maximum lifetime of the exported keying material, and all keys calculated from it, on the authenticator. Since existing backend authentication servers do not cache keys exported by EAP methods, or keys calculated from exported keys, the value of the Session-Timeout attribute has no bearing on the key lifetime within the backend authentication server. On the authenticator, where EAP is used for authentication the Session-Timeout attribute represents the maximum session time prior to re-authentication. As described in [RFC3580] Section 3.17, when sent in an Access-Accept along with a Termination-Action value of RADIUS-Request, the Session-Timeout attribute specifies the maximum number of seconds of service provided prior to re-authentication. Where EAP is used for pre-authentication, the session may not start until some future time, or may never occur. Nevertheless, the Session-Timeout value represents the maximum time after which transported EAP keying material, and all keys calculated from it, will have expired on the authenticator. If the session subsequently starts, re-authentication will be initiated once the Session-Time has expired. If the session never started, or started and ended, by default keys transported by AAA and all keys calculated from them will be expired by the authenticator prior to the future time indicated by Session-Timeout; this feature is utilized by [IEEE-802.11i]. Note that in future additional attributes may be specified to control the lifetime of cached keys; these attributes may modify the meaning of the Session-Timeout attribute in specific circumstances. Since the TSK lifetime is often determined by authenticator resources, and the backend authentication server has no insight into the TSK derivation process, by the principle of ciphersuite independence, it is not appropriate for the backend authentication server to manage any aspect of the TSK derivation process, including the TSK lifetime. [b] Lower layer mechanisms. While AAA attributes can communicate the maximum exported key lifetime, this only serves to synchronize the key lifetime between the backend authentication server and the authenticator. It is RECOMMENDED that lower layer mechanisms such as the Secure Association Protocol be used to enable the lifetime of exported and calculated keys to be negotiated between the peer and authenticator. Where TSKs are established as the result of a Secure Association Protocol exchange, it is RECOMMENDED that the Secure Association Protocol include support for TSK re-key. Where the TSK is taken directly from the MSK, there is no need to manage the TSK lifetime as a separate parameter, since the TSK lifetime and MSK lifetime are identical. [c] System defaults. Where the EAP method does not support the negotiation of the exported key lifetime, and a key lifetime negotiation mechanism is not provided by the lower lower, there may be no way for the peer to learn the exported key lifetime. In this case it is RECOMMENDED that the peer assume a default value of the exported key lifetime; 8 hours is recommended. Similarly, the lifetime of calculated keys can also be managed as a system parameter on the authenticator. [d] Method specific negotiation within EAP. While EAP itself does not support lifetime negotiation, it would be possible to specify methods that do. However, systems that rely on such negotiation for exported keys would only function with these methods. As a result, it is NOT RECOMMENDED to use this approach as the sole way to determine key lifetimes." ---------------------------------------------------------------------------------------------------------------------------------- Issue 361: Child key expiry Submitter name: Vidya Narayanan Submitter email address: vidyan@qualcomm.com Date Submitted: May 1, 2006 Reference: http://lists.frascone.com/pipermail/eap/msg04231.html Document: KEYING-12 Comment type: 'T'echnical Priority: '2' May fix Section: 3.3 Rationale/Explanation of issue: This section states "When keying material exported by EAP methods expires, all keying material derived from the exported keying material expires, including the TSKs." This seems to indicate that the keys derived from the EMSK will also be expired when the EMSK expires. It is not yet clear if this would apply to all kinds of keys derived from the EMSK. There may be classes of keys derived from the EMSK for which different lifetime guidelines apply. So, it may be good to clarify that the EMSK usage documents will specify the guidelines for EMSK-based child keys. Requested change: Change "When keying material exported by EAP methods expires, all keying material derived from the exported keying material expires, including the TSKs." to "When keying material exported by EAP methods expires, all keying material derived from the exported keying material expires, including the TSKs. Note that different lifetime guidelines may be specified in future specifications for EMSK-based child keys." _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Sun Jun 04 23:14:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn5YM-0002kl-ES for eap-archive@lists.ietf.org; Sun, 04 Jun 2006 23:14:54 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fn5YK-0005lJ-Tu for eap-archive@lists.ietf.org; Sun, 04 Jun 2006 23:14:54 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 8FD5C43014A for ; Sun, 4 Jun 2006 20:14:52 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 6277B4300B7 for ; Sun, 4 Jun 2006 20:14:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4991A398043 for ; Sun, 4 Jun 2006 20:14:38 -0700 (PDT) Received: from hotmail.com (bay106-f17.bay106.hotmail.com [65.54.161.27]) by zoidberg.tigertech.net (Postfix) with ESMTP id AE764398016 for ; Sun, 4 Jun 2006 20:14:35 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 4 Jun 2006 20:14:35 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Mon, 05 Jun 2006 03:14:33 GMT X-Originating-IP: [208.54.44.217] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: eap@frascone.com Date: Sun, 04 Jun 2006 20:14:33 -0700 Mime-Version: 1.0 X-OriginalArrivalTime: 05 Jun 2006 03:14:35.0090 (UTC) FILETIME=[2BD5DB20:01C6884E] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.748 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Subject: Re: [eap] Proposed Resolution of Issue 361: Child Key Expiry X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 To better capture the dependency issue, the following revision of Section 3.5 is proposed: "3.5. Exported and Calculated Key Lifetimes All EAP methods generating keys are required to generate the MSK and EMSK, and may optionally generate the IV. However, EAP, defined in [RFC3748], does not itself support the negotiation of lifetimes for exported keying material such as the MSK, EMSK and IV. Several mechanisms exist for managing key lifetimes: [a] AAA attributes. AAA protocols such as RADIUS [RFC2865] and Diameter [RFC4072] support the Session-Timeout attribute. The Session-Timeout attribute represents the maximum lifetime of the exported keying material, and all keys depending on it, on the authenticator. Since existing backend authentication servers do not cache keys exported by EAP methods, or keys calculated from exported keys, the value of the Session-Timeout attribute has no bearing on the key lifetime within the backend authentication server. On the authenticator, where EAP is used for authentication the Session-Timeout attribute represents the maximum session time prior to re-authentication. As described in [RFC3580] Section 3.17, when sent in an Access-Accept along with a Termination-Action value of RADIUS-Request, the Session-Timeout attribute specifies the maximum number of seconds of service provided prior to re-authentication. Where EAP is used for pre-authentication, the session may not start until some future time, or may never occur. Nevertheless, the Session-Timeout value represents the maximum time after which transported EAP keying material, and all keys dependent on it, will have expired on the authenticator. If the session subsequently starts, re-authentication will be initiated once the Session-Time has expired. If the session never started, or started and ended, by default keys transported by AAA and all keys dependent on them be expired by the authenticator prior to the future time indicated by Session-Timeout; this feature is utilized by [IEEE-802.11i]. Note that in future additional attributes may be specified to control the lifetime of cached keys; these attributes may modify the meaning of the Session-Timeout attribute in specific circumstances. Since the TSK lifetime is often determined by authenticator resources, and the backend authentication server has no insight into the TSK derivation process, by the principle of ciphersuite independence, it is not appropriate for the backend authentication server to manage any aspect of the TSK derivation process, including the TSK lifetime. [b] Lower layer mechanisms. While AAA attributes can communicate the maximum exported key lifetime, this only serves to synchronize the key lifetime between the backend authentication server and the authenticator. Lower layer mechanisms such as the Secure Association Protocol can then be used to enable the lifetime of exported and calculated keys to be negotiated between the peer and authenticator. Where TSKs are established as the result of a Secure Association Protocol exchange, it is RECOMMENDED that the Secure Association Protocol include support for TSK re-key. Where the TSK is taken directly from the MSK, there is no need to manage the TSK lifetime as a separate parameter, since the TSK lifetime and MSK lifetime are identical. [c] System defaults. Where the EAP method does not support the negotiation of the exported key lifetime, and a key lifetime negotiation mechanism is not provided by the lower lower, there may be no way for the peer to learn the exported key lifetime. In this case it is RECOMMENDED that the peer assume a default value of the exported key lifetime; 8 hours is recommended. Similarly, the lifetime of calculated keys can also be managed as a system parameter on the authenticator. [d] Method specific negotiation within EAP. While EAP itself does not support lifetime negotiation, it would be possible to specify methods that do. However, systems that rely on such negotiation for exported keys would only function with these methods. As a result, it is NOT RECOMMENDED to use this approach as the sole way to determine key lifetimes." _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From AvatlwGreen@jupiterbeer.com Sun Jun 04 23:24:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn5hO-0000pg-Ek for eap-archive@ietf.org; Sun, 04 Jun 2006 23:24:14 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fn5hO-0006OZ-Cw; Sun, 04 Jun 2006 23:24:14 -0400 Received: from [222.85.98.169] (helo=2D260C8) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Fn5db-0008D7-S5; Sun, 04 Jun 2006 23:20:22 -0400 Received: from simply by etymonline.com with SMTP id Mi2CBLoKg9 for ; Sun, 04 Jun 2006 20:19:35 -0800 Received: (qmail 30642 invoked from network); Mon, 05 Jun 2006 09:14:35 +0500 Message-Id: <6l519th549l09ql$ngq5gbw16ib70$p%RNDDIGIT14gr9@%RNDUCCHAR14029> From: "Juana Carroll" To: "Idr-web-archive" Subject: Re: info Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Contact us NOW to receive your diploma within days, and start improving your life! Bachelors, Masters, MBA and/or Doctorate (PhD) NO ONE is turned down. Call Now 7 days a week. 1-206-984-0002 According to the U.S. Census Bureau, with the following degrees, here is how much you can expect to make in your lifetime: High School Diploma: $1,100,000 Bachelors Degree: $2,100,000 Masters Degree: $2,500,000 Doctorate: $4,400,000 You Need a Better Degree, and we can Help! Obtain degrees from Prestigious Universities based on you life experience. NO ONE is turned down. Call Now 7 days a week, 24 hours a day. 1-206-984-0002 Regards, Professor. Monica Currie From westuhvrq@sdma.com Mon Jun 05 04:31:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnAVD-00021i-Mr for eap-archive@ietf.org; Mon, 05 Jun 2006 04:31:59 -0400 Received: from [222.218.208.113] (helo=sdma.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FnAV3-000522-Pg for eap-archive@ietf.org; Mon, 05 Jun 2006 04:31:59 -0400 Received: from 216.55.136.64 (ewkbqvw.greatdealadz.com) (216.55.136.64) by mta143.mail.re2.yahoo.com with SMTP; Mon, 05 Jun 2006 16:31:39 +0800 From: "zcjfk ozyltw" To: Subject: (Reply) for Monday Your PR man HYWI.PK Date: Mon, 05 Jun 2006 16:31:39 +0800 Message-Id: <50926050608185.7uxjzqjz1y@sdma.com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="hrern7r4xg8us7zl03mv" X-Spam-Score: 3.8 (+++) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 This is a multi-part message in MIME format. --hrern7r4xg8us7zl03mv Content-Type: multipart/alternative; boundary="UIECFRAJBZSHUMTAQDVR" --UIECFRAJBZSHUMTAQDVR Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7Bit --UIECFRAJBZSHUMTAQDVR Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7Bit

Sitting on the fence.What's good for the goose is good for the gander.Shit happens. You never miss the water till the well runs dry.Were you born in a barn?Walking on thin ice.Stop, look and listen.Sly as a fox. A weed is no more than a flower in disguise. The stronger the breeze the stronger the trees.Sweet as honey. Tastes like chicken. There's no time like the present. Water under the bridge.Root it out.Walking on cloud nine.Spring rain, Fall gold.Sow dry and set wet.Scraping the bottom of the barrel. Spring rain, Fall gold.When we love - we grow. A thing of beauty is a joy forever. So hungry I could eat a horse.You can't squeeze blood out of a turnip.Tossed around like a hot potato. Under the weather.Survival of the fittest.
--UIECFRAJBZSHUMTAQDVR-- --hrern7r4xg8us7zl03mv Content-Type: image/jpeg; name="uktcn.jpg" Content-Transfer-Encoding: base64 Content-ID: <6kiy0taib04q@sdma.com> R0lGODlhXQEXAvcAAAAAAIAAAACAAICAAAAAgIAAgACAgICAgMDAwP8AAAD/AP//AAAA//8A /wD//////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMwAAZgAAmQAAzAAA/wAzAAAzMwAzZgAz mQAzzAAz/wBmAABmMwBmZgBmmQBmzABm/wCZAACZMwCZZgCZmQCZzACZ/wDMAADMMwDMZgDM mQDMzADM/wD/AAD/MwD/ZgD/mQD/zAD//zMAADMAMzMAZjMAmTMAzDMA/zMzADMzMzMzZjMz mTMzzDMz/zNmADNmMzNmZjNmmTNmzDNm/zOZADOZMzOZZjOZmTOZzDOZ/zPMADPMMzPMZjPM mTPMzDPM/zP/ADP/MzP/ZjP/mTP/zDP//2YAAGYAM2YAZmYAmWYAzGYA/2YzAGYzM2YzZmYz mWYzzGYz/2ZmAGZmM2ZmZmZmmWZmzGZm/2aZAGaZM2aZZmaZmWaZzGaZ/2bMAGbMM2bMZmbM mWbMzGbM/2b/AGb/M2b/Zmb/mWb/zGb//5kAAJkAM5kAZpkAmZkAzJkA/5kzAJkzM5kzZpkz mZkzzJkz/5lmAJlmM5lmZplmmZlmzJlm/5mZAJmZM5mZZpmZmZmZzJmZ/5nMAJnMM5nMZpnM mZnMzJnM/5n/AJn/M5n/Zpn/mZn/zJn//8wAAMwAM8wAZswAmcwAzMwA/8wzAMwzM8wzZswz mcwzzMwz/8xmAMxmM8xmZsxmmcxmzMxm/8yZAMyZM8yZZsyZmcyZzMyZ/8zMAMzMM8zMZszM mczMzMzM/8z/AMz/M8z/Zsz/mcz/zMz///8AAP8AM/8AZv8Amf8AzP8A//8zAP8zM/8zZv8z mf8zzP8z//9mAP9mM/9mZv9mmf9mzP9m//+ZAP+ZM/+ZZv+Zmf+ZzP+Z///MAP/MM//MZv/M mf/MzP/M////AP//M///Zv//mf//zP///ywAAAAAXQEXAgAI/wAfCBxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fP n0CDCh1KtKjRo0iTKl3KtKnTpyMFSBUwcCpVq1WtXtX6QGrXqQuxChR7ECxYk2cJknV51ivH tVBfus1KV+1Yql+7jq0bFi9fhG7nlhT8Vy5ewhkRx21JWPBcv4Gv7r3bsLFfwIcvk1SsuKDm kJ0Nfq48evFKy54lq81ctTDm1H0pn+Rc2jXI0Ksn4jY9W2taypojT5bd1/dlssLNclWe2fFv rqKbf93alvly1lkfY027XSzc6Hepr//ezZsiatiiZR+vnbt93vfJIcOXP189dtrZ69vPK175 fuHw7Sfga+G9p5eB5W10nnu5mcVgQgsCKOFh/9U14YDuXRiefwJG1h2G1WX3G3gdspfgRQva xhx6030W4X0wHsifV5DFqB9+JRamXY7tAaiXj+QRp+GJHqVIHHpGEsiXhtqtdySTNrI4ZFsG QkkhlPpNtxeONwaGIJG6cffciCCSmVqTNXoI3ZhHtjjeenB1R+OcaroZopZubuiblnQ2h92b dtb5JZiEQlioSCYeqqhGiS6qm6OQftRopA5NSumlEAaJ6aacdurpp6CGytRolopqaqjG7cki aJrq6eOZEUH/x5OZsZJH61uv4slYabcO99igrVoU7HxbZfqQcz4Nq6RCyobZ5qAphdZqkr3V atuqsdnVU7MkZhsVe9y2JtGk0wZXakfD7ujtukGF++CyrDJ7LrakVWopaivmmV++yN1pXVlp OjdngfACyieMa8l5sHhnsrammGj2hy+aG0ZHMXARNyywn34u3GK/ucoLa3LiWkhffBgHOFyD QKa8W2cTStyhfcX+6lmOxfKHM33jqUxjyb7yOKTJPNbHobpRMnRefDj+7OrH1AVccK7fdYuk jUP7ex9mUaqKJ5MkCqyviER3+SyWVV43oNjQwjslYnTKaOTA+VmN4YxKB2f23r9i/8nr3sDy rdrVrTUJMNaIh514m28X/mfehOu8ctkEM5yz0zK+6+GWSf9FN9oXvk3q5X9S+XnpTTs8uN6T gf640Khf2bXqzx5eXZ/GEWgZxXJWnfDtUR+cKcTSEfvxvtcVP3KqUgsPNcGArug12dSn+vSb cDbf+8LJP3+qtojOe7NcQ7n7fVSbiQ8+Y+Wrfz766aMIk/ts0f9+UVXnbT+K5rOU//0ADKAA B0jAAhrwgAhMoAIXyMAGOvCBEIygBCdIwQpa8IIYzKAGN8jBDnrwgyAMoQhHSMISdgoAKExh CgeiwhWyEIUPaCEMX+jCGNbwICoUiAxnaMMdtrCHACCIDP91uMIcmrApQWShDQuSxBo6MYlL jKIUeZgQKs6QijGMYhN1SESDXLGJWzziU244RRqasYtdxOIXGWJFKPLQjUGEYRxf6EUwplGM cTHiHZUoxyn+UIpoVCMUiThEOg5SjlekIxPtCEQ8LuaGalxiHOFoyEFq0ZKCFCImNxlIRWry iYB0pFMOiclAUjKNnAwlDkm5yDpKUpOubKUqRVmUQ8JSiKb05BrRCEgytlGWn+zhLXd5y1nS Uih/JCQct5jDHX7yjT4k5RehicUscpGGk2wkNrV5zG5685vgDKc4x0nOcprznOgcZyFJsk5g SsSSvDyjMNNJFCuehJjFjIgvI/n/ymrSsyf+BEkqA0qROaZSiWX8JzLhKUxE+nCeRZzkLyXp TG26sI0MDeg0FRoUjWaznxK95EU3CcpsJhKRoSTjLDPJUZ949JKK/CNKUwpPaPZSj160pidx 6c6W7sSeFOUlPoNK01gSNZ72nOMww6hUgvrUJsmMpkTB6NCGUlOaU7VoRBdJUpM2U6VPDatY x0rWspr1rGhNq1rXyqkEuLUgbo3rWyMi17k2xK4XiStDEoAQvApEr3/1K1s7wteD2FWwey0s Yg1b2IwsdiCAhWtjIQvXBzx2sHkVLF4vy9jAfmSynU0IX0crWdBadq5v5SxmKSJXyRIEtXqN 7WRhe1rA/9oWto1trW43G9nTvhaxvQ1sakdr2tVqxK+8taxnD/vbyKbWt7Qdrm+VC13iLne2 oA2udTsrXeN6BLnYhWx0XUve6l5Xtq6t63X3Sl3hBte8qvXuQxSb3dzSd7rP/a1BDrvd7npW v+Cd7n//qlzTjhe+8t1Ia5u74NretrTY5a993Uvh2jpYvM6tb3Gjm+HiJvglHpZIfDkS4g8T pcR0RbGJP/Ve1qp4xTCOsYxnTOMa2/jGOM6xjnfM4x77+FQGfu1+f9yUCDfYwfbFbV0bvGTZ KhnJwFWve5McYSgPGcMM7vCKe8vfAXeZshNub5jvK94yE7i81P2yhYVrZt5Wmf+yAj6zibk8 4QDHub4KsbOXFbvfDeN5zYCmLZbBnFszt/fDZLZynPE7WzT3GcJMPvKA9Utp626X0XBmLn4B HGMpC9i//92sox2d3FA/+tRthu6nj+xp+pKW0ls2dJftLGpYh9bQqxatn8lLZjXD+dNl/nOs 2zzmMN951La+s7EPfexcn1nQiz40apuLbOPetsluBq92W3zhCu92yX2ms5YL7OQ3N9nWkiay ukOF7Xa7+93wjre8503vetv73OvOt773ze9++3sjRsRpMMGqEUgSfCQjdQlGceLUkhy8ig1n JyshHk+PsHQlQ03JxWsScYlPpOMimShCMs6RjeMwJB3/Z6jHkXkRlRsVIiBHeUUJGdOQPnSj 8uSmKb1aVSBKNedfpWpW9znSotM8qkan+TOfKXSqKrPpSQ/6VL+6zSeusarU1CVGfxjzhYh8 pld3I1G9isqyF1OmZAfp2D8K9qbacaaVvCNK3wjTuX+Up5m8+trrHlS9153ucQf70we/973D 3eX6nHjh/T53s7e9qI6fulDTjnaYKt2heWek4XOJec0HE5bEfHzoJe9HzfcR9FRHfeQtL/q3 A1zxj+c7Kt9Oe7Nr/e/AtHvFW4/7VVp+87iv5i8zP/ne25T4o9ep7Ysa9tUftaQFL/oyn57w uAN968u0OdYjun2IWl2q2xfk/zSnX/PxD138Bh+/PAPO/az6/KEVt6r6299z6Std+TulCeIx 1XWN7//lKHcTUSWA39N/KNF/BvhOBIhQ/6cSD8d/D8gSAqcQE/h6DeiAQfdvGriBHChO0mdw FEeBW4dxJLdyCJeAH5eBJYeCXCWASuVH+ZdPI3dQGBh/DneBFnF6J+h9FoeDFOeD90SDBqhy JpdTAtWAQKhxbISDSdhTxpSDTeiELWF/O9Vz74d5WiVLW6WC4Gd1S2d/Kvh5H0h/ynR/6ed0 X3hVV0hR3MdV7HeF5qdHb8iGg3eGl1eBPfh7SMVIsXd6Q3VVtad3umd4rhd8sMd2IcVFgjeI Wnh3Zf/nh3yIiFbViJx3d4MYic1Hh7EkejeohzdVibl0h7kniZX3iE3nfDyYTDuXfLWHTZ4H iqjnhcZ3iksFisfniFRYiqqUiSz4TpJ4dqc0T4a4e5SUibcXe9Z3iY7YShcHiZ/YU8a4fH34 iy/FemnXd63IiHtIiSV4hELnimrYVXCIdOEnf+fHc2VIfdFkjp/XSHL4jexnhWdEdOfYhj+n c124hd1Hf1xXj8KYjlTYUXjYgSfEUwQpKqp4kAq5kAzZkOdTU6ESgb6Xgj7Yj1EocyHXixmB guu4T5GSgCD5gkvIg/p3kQ6hkRjBkTFFjPW0gjDXckAofCapTzLRixc5k9D/iJM9mH5mhFNo l3RluFXuuE5GN4Le930Jt45M944bxYXOJJQ+l4aWeIaJyI5HiYUzV5SIh3w453/DGIOcyHvY eE271HYeCXyh2HwyOXbSSHkGRYtwZ03mt3x0GJe8SI2RKFJOhX6tSIKzWEnZWIyBeVRpSYoD 9Yu1+JWqt3AwqIt3uYuPyVKOOZjzmJfRCIDTKIGGWXOuxIqDGZfW2HucmXFlGYg15ZYwSJip eXjER4iU+JqZWZqrB5osmXwYyJiyuE3cRJXvp1U/eXRqeJVL2ZFVOYn86IVSt4ZFNINPOZcA 2YZ3CI8WGY/AqVJMOY46mYIbmZ0PlJBHhJJP+EG2/+RIA3mSEqlB3umQ6rme7NmeXjeE4DmR MMmEYRh93Jl49ymDL3GeOhGSRxh95kmSLqmZ/1mSOXGB/slwNiifMZiSOrmVM9gR+dkQCDqh 22mFb9h9Zkh+6riMN2d3HDqUIuWGSQl/SpmFmmiRSyecc1h1YSh19lic6XiUbFhIoNSCxumc AHqJhFd5sqmWYpeMU3mNS6WPsGmagcdU30iIGfWZodhJdel2sDiJK7l21ddHyGiKPVmIO5p6 QvqXrvlKqsd3ujiapMeZiqmNudiia1l4Agp55FiYWaSKrZmZqDibURmeBYWLnBSZlsmhOrh+ rtemZmpMsjmWWuqaGyeZm/+JT4w6pj+6Un1KmbdYm4NKg/bpm9rnlEvqRAx6TboZjjKZgT6Z j+ioj1PXj0Mpj9EJjjO3qtIJo6OHfpW5qdepc/8oqvFZkp5aR/zpni3JgCeHUMAKFSrqq7ta rMq6rMzarD8hkfz5q9bZcMmacw8Rn+D3jyI4k7/6qd7IqgdaoTBHn/i3oA26ndqJrnJJluQK k+66g9V3oOYqhSFIoRCppxn5knmIpeeKdzipkkEIgLzqlqd5fackfjNKdThHhj1KnS6KiJ2X dVRKcPUnpNI5onkqihIbnaSafSQFnMM5e+1Uq9W6ikT6l+rHjK84l7EJqW+Jsmwnpyy7lXzo iov/p7Bcin2zmZd5Cppm+aiK+aUWCqRnKZYTmKWGeKUF65k7C6ef+Yoqq3wg+qOkR6hGi5dN 67JOa4tLC7Wvl6ibuJmqibRA+ppam7XaGJrGSJvQCbZcK4V+6nxru5aXeahp66Y7GaNGyZMi KoZUaatw6IYJq7NDFI8Oy482GKTVqanh536tCpTC+HPLCXFOh5SSK6PCeUAlG0HpmU6b250G qVDlOUKd66yme7qo60H+lKCUG6uj+57Haa/tiJ9L6qvauoJYRYJeWx6r24QR93XBSJMMGLwR qp/XqngT+bksSaD4mkDAa7xLKIRJyIIil7wWmn/UipFsVHASGpBYCqKB/wuVcQqVHVqFp0mL g5tPDOubs0uifPt3qWqWsytwTXmOHUqUIwiGbduwPIe5wit4YSqIcOmh6LuNBiy0tvuMQjWM l2m+X/p8bHm1kNezqEl2cSumZau1DVwR5BvApve03Ci9Dny2I3fAe0S0G6zAduqMLAzCwAi/ TOucyFiiHvmYzfueYyu2tsmaBZvDLxx/ZOuvYCmliJqk7lSpaguYaEvAQntQyhi1iEqbS9yv 5pmcz9mFyhmoIft9QTmyJMt06li8huu48aqpJNuihPm+GduxgNuxmYudKkq/ltubAdu93Uoo 11uunqK86gpwocspeZzHoyTI83mfpdudfMwUr/+buozcyOuWyI4yrTRLyDhamfXKnFCYndLa jQAKu/PKwZB8gCJJxTeMrj1MUL/LrdyJgLv7tSNZyomnyC5HrUz4rgK7vd5akTFphKyckgH6 yvnKRPaJVdJEfSmarX9IwyPKqQiLqy/anFh4U10ZuWj4sNlnpavUuFVpxR9YyQ9bnYyZuXsL kpa6xKQIplCawYkaqGSLtZHqiRfMtk9qsj5MtZQHi+zcpKKpqEGazHR5vJPatFV7sIi5tZ5Z xnd6s6EpirVow727sqZZwzyrqg3ttXTLsx7styHsi8zXlxp6e3j7qDblw1Bcp4CKpAZNmZ/o z0Vc0hid0gtq0oX6fKj/WdG+WKrhTNNYeZx2KKvI2X4JLMdPKbj56LfFvIZLmatxLMn3aLit 6swPfaI4zbHtBLl9/D6HDEKhnIf3M55itNW4S8mDfMcYtMiOfNZondZAcZYzAdb39xHQWoQK p8b2er5gItdzXYPBDMyffJvW+suGdNeULNZcrccc3NeIvZ8bO6yYSdj+l7LgS6PgGrv7CL7i y5QYqqE7bddU2sUYu6JIadSSJ4sdzEcv28XRPLXTOY5/PYWO17BFTL4T9bMDDNuZR6Sxqc86 Ss8+686HyK45qpdEqHZymY2wrdBiWZO9DcOXytbx7Nt0KcOCKacuDdMJmdtmy9sZOtx6WKLV /y3N62zWHrfcdXva1jvFVPvXpEmpxJvcb+t7swrfhymDaTvRYvvAccvJugvUlH2j+Jh1xOnT 9sicseqqiBvU8li40Ryqk5vAsHrFtnrU9di45gjNCv7GE5TVeSTeHOjVROLh7Knhxsrhal3i Jn7iF/SqqLx/dujXsEyRMa3PmWrG2Xy7Friij53YA5qa3trYU9jKrlyN9MrRwbuXQO6gQ75y bm3CJ1m8pBzISNjJin3ENKvj6frk2ut1BTp7Bv7gTtu/V3mPSl1//L3io7qpFLzN9Yvg2Pe+ YRe/EDu/RTu1YS7V+Tt/+2vLamuZ81x6Gfy9Gc14KC3MHW17uB2YEv+9vMWX3ooYsxLcjNtN phXspEELhYlpp2/amLQXr8ro3aUnsrMs0xj8wVn7wCOs0KOe6hd8jJsew7Ud3zWqycG4sX/u xPe96AXNz205pvhNxHse3bn+vHb7gmQOs6O4z5oOz43aly/uvtcsjkWN2vL34Kg6uEVd5kk9 nKX5k2iY59777VDnqHx61IS3qtOenNW+m6bKjlst4sZakKAi1iB+Io691hFpEu4eVmSN4vze 7/4u2Etu4ydo1/vuoPXuyRwtynD9sSbolQov4wEvpsp95fg+tD28g36p8GJ88FZeRTtOoaZx 5J0slOVJjp3a6jabmzOaxX0u4JtNU7VLpwD/zptpLpV6idSSzfBj2HlXbLBkiLN7TdEsblKv bVFvK88w3d2cF6ZSG+zLrp9hqcP3/OsZm+yaOKeOfrKvve18XKkgx8MwL+H9a9Ei/dIMDd4S n9ASzOVu+uhMbOxFyoptidB9J7OC7PWsxJX1fI10P3zzfaioGJnf3cRoSsJuv7VMb33HuOtO WOzIHtbnbqSgvdoCXq71ScewKuaXG7GJm7IrD5T0aO1grOBx2O2Z/ew3ys15HnmcX/ABCL2F zPElt6dX/VQX78fEynK0j+RpReLRG/EXuqca6fv/XvzGf/wV1HX7Dp3AL4ILT9ir7/zj6roI fsk1rhS9vPv6nfGF/52vDS6715qW0r/ifB2sFB/Lze5wDV9QrxxzUcjn0q+vt3yDcZ7y/Y2O Lv3R2619NmvJ67vzAAFAoMAHDwYWPFhQ4UAABgkSRJhwoUSKDyVGbOiQocWMGhtu5OhQo0KS Ij2WJMlwJMaNJ1WaRBlT5kyaEw9ajCgyI0SeHzve7MjyY06PO30S7ZkQ50STR3Pi7GmwqVOd QY0KfWp1Z1aYXasiPbr06leMXmEuLSn2alSdYGu+hTsT6ku0Ssc+LJqWqt2pfftGhYgVod6q fN1OvViWLFqvapkCNcyRsV+8LdOmHIuZslO2KwPHBQ13Lkq+bAGb5eoY8N21Pz83Phs2aP9s omQJr+bKVHPgzrXdfn5teujrhYNp785cMXXm0M1lQj4pFbNKkMkvQq4esmh26LOnyzbKG7tQ y9HJQ89r03V4m3olU7eblO56reNfqm85Gz534s79gy7vPwEHjClA0bwjMEEFF2SwwQLvczBC 0VKSsEK5KAytPws35LDD/6zyMEQDQ4xwxJogJDFFFVM0cUUXX4QxRhlnpLFGG2/EMUcdd+Sx Rx9/BDLIExHs0LANE6uISAHz01BIJ58kTUkOe7MQuLNK9Ik5KLfkcsIKm8RQQeLqa3BMKZcc 8Mwu1+wuyyzPq6499Tyzz8yQxAsOTzct4869+bZLTDGgzBtp0Dr/wwNJzjV5lK+1v77CbbGh /qJKukZzI0y30ZaL8rBNkcsNONcUhdRRKhfVMdL3atuUT87WyyrQ0hztVFPZHqvUU1O9U01L 8Swd1VXbwER1RlVz/dUxUEvFdNleMcSLUtom24zT22g18ylbG7sV12JvjLNNyQp90zz+mHTz O3QFi24+8MhdCc5wy50OP3qvY6+s/Qqj81t//wX4xIAHJrhgB9U0OGGFFw50YYcfhjhiiSem uGKLL8Y4Y4035rhjjz8GOWSRRya5ZJNPRjlllQlMIKaWV4YZxgRmpvnlB2quuSCcaZ4pZ515 JgnnoHcGWqGif36Z6KRnvllopps+OuaS/59u2mibbx7a6quz5hpprXW22miUor6aaqx/Rjtp sNGW+mSq396666pd3tpss+eWe+yjy46bbabVPnvttqe2GW6x876b7bAVR7xvsYvm+/DF32Z8 cJOFHtrnxTfPfGfOP088aK8Dh5rspQWH2nK3W76b8sbpLslwvWN3XHCeI0d97afrDl11j3fH Hfa8K5edduN77nz4rG8X3veQgUccdJlaD75yvF2mvXrSb7dbdOefLzz8ru12nPrMvz5++tk5 N/9617//HWilnSa6Z8hNj7r00E3X2nOuqe8d/AQ4QAL+aH4HRGACFbhABjbQgZgrYAQlOEEK VtCCF8RgBjW4Qf8OdtCDHxycu4iEHgnhi1hfOlVc4lTCE8brLYlKE8Ls9ZwWHkiGLNSMXLR0 MP3cEEu+aQ5vqiTDGlophkHcIRA/NCkXiYomKWRQngSGQi/p0DhUfKISH7QgH2ZKQ036yZBk lJ16/eY9g3KhCXuor3TF51yk2pdLSIgfXO1pTmhsl6haJcUokXA/+9JODuUDFkTFcU50algU teItaQ1GLJJqpG7Ss0epUPJYwLKWpiiUrEldilm1YlJXvvimaAknNsiiixmrNZlLdhGJOYTk oyAVqldxi5GrmtarZsWq1SBphNeS07PMgpsAjZJdkVlLeiRZRlz2ko/KOtIiafmbOk7/M1KS FCY2uyVFYtKqVsbZy61aOSpBduubmBRlLR9lTGehslnl9MsQBymoFTpRj2U8prjINS5DzRNQ ZByPveaCKHkhckSJCqi6WLJQhMJQT99RF7rYk9A8EjRIriRZDUHoI4xmtKMbrVEipYYikJbU pCdFaUpVCj9eqYik7sHSR+tJLy5q9IkijGi+2Gii+vRUpNu5DIAghKScMpQ///zokhBmU6Ee EZxJJBBTt3gYWMKqOLyE6TJZZcWrKuaFXvWlNClTVek0ZUUtlOqBMuTFqZYpqagZ5laKI0Tf 3FOrZqXhTZeqqLBWNZmCPKdLJ0ofeiaJjYeMT2F8Sk+kFnSh/5QqZBpHyKuhImWZdP2Vn5QE Ri2StTIgOqUeeyirtzp1kuLcFWK6qVpfyXWV4VwMIbFFU15SiyfQilY66ajE2+aVhj+90mcV 2izG9BaWZw3WrnYprG7u0pZeTG0mDSqYzF52h/0JlnWvWN27BrarSenXU7eK1eNwN1NNTK50 P3lLc07zuLoa1jZryUqxktdKRiQTecsaz0qCiI/gfO95WdPVeHamN/VlkT7zglOjlkui+4zX UI96p4EiFTxtxK5Ez0XTRuFJXm+0E3gJBd2txJGMgLLwQ7mU1pWq8EvfY3GLp/hi1b1Uxj0q 7Y11vGMe99jHMgYxdtx4ExvmV6jkfP+QVV0I1yRbtI9LdmtP0QvVI5c2x1GVa5aRbOAr6pVU ExIxaSx7WyjeNMDwHOJ5kdvZDFk5xopsy5bJadz9/vbLLu4uJkdD56bmmao4PHOYfvhVtWL5 ykdUijbViGAxC7fB6URyXvecrjbDEKyt2RMaTQjRcl7YoEf1qhwJakhQqoWzTBbRXbSp2/0S Kyx4rUupzcysTxUaq6YU4iOFSd/dWvKTu+5kdL8ZyjoPN0ZQ8at+O+2ZP5dmqmBK76Tr5ctk m7Its4TkNW+NaQPL17keVuxkveVqP5NojtU9MJvF28jcopNKJQ62nn3oRPeeJlbW9Oa238lJ /mZ7vgjmN73/CfxmLg48oG9EdaL/+G43QjrMhq3yYz9tJNtIdrGPFheG32WuDVO4uPqEDzOB 26VDBxVAiyr5wFL+sJV3uYorHlnLGcZCmaeK4D/Gec51vnOe9xzlRlbqaNns6v8mmMpFpq2x au5biBXdP+3+s5qZru5oUt3MFKfRzV+JMYKzc61txTOgZzx1q0exxiLMl5AR68lghvVe8xoX pOFl4o7DET1/XPJMG5tTFR8KTvBiFyL/7qqHax3L6zTnv7PdTmCy+68Mp658++tva6rymQO2 7TaJK3ldapvf/HIkZ9Y7RnUuXlrCajw3MT9gxsLTmdaR1LetisttnZ6yFTdSM+es//hOd1ve wzX84X1v79UGGJrujXB0Lx9JfUO++NSC7+itVZd8lzecCOK1tnB/++A7h8GSfeyDSdpwvjOx waBGccZFDfr7dNzjPp0whyvcp51qHJB2Pr+t4k53GHX/2DbusRYxt/5bugEkMJwDrRcpQL1a wCIBQB4TQJ+TwAmkwAq0QBAauSd7OqlCq02rNA2MMgnjKh2SMuQ6OotJqxjjQCICt617DLEz r0B7L/9rs7KbmDF5IVc6wWITNBD8KXGTwQQRuJMDO1TjwZp6uWiiMMATvCWsKE4LP9HCOMIy NUrbJ9p6tYfCu1KBu0yDuOMKJIA6uDWau7uru1CjO36iwf91I7xxwgoy471tISZMkab8iDpt m6vh0LJQibx64zwyhC9cu0P6UD49pDzTKz6aw7dFHD3mIsNscjbXm71HvK5mw0Nlsas9orba w8RJFLB/yz1vuyTGikClcrxTTERbWr7Vsjc5lDw0g43X2jd1ckMoQjclez5AzKbmay3beyce 6kLtSJKGorT2kzCdSjHe0jBDWjih668zusIrDMaQI7/zuCM/STEt9DhRIyUHG8Ygs8KRiqBS vMCoGsceLMeaakAUfMB0dMd3hMd4lMdvwbruSsF1HJIFzMSOIq2kC68iBEEbBEaBtLnOyrAN DCl9pESExD6oKrMTcjpz20Ecw0f/cCFIODMtWQNIQvOuseOhJMQRQNK9txsskRutbrSwJsQw JmzDtKM9kbw+PdG06/KjLsyjaRsob9wwuxNGv7MRSNw+WqK2bPm9OEPJ06JDxkOtPPRD53LF QZRFWYI8pFSNX+O9UhI2pVslqnJDWAQiaPKkTtQ+9iLL1VOlijtFVTTLApvKXgnF2BvFfiFH idxK62PEVdMqsOxFa4M6vZTK2aJDohRLxru06VvIS4y2vSxEI1TAE+swi0qsbwyxD6uobvRC ZfQnfInC+DM/iHI/zaIObDzD9Hu/9etJmeTMETup2yPADBSTdpzHrNtIEUHHEqrN2ExIylpD pEs118TN/98EzuAUzuH8ka7TqLl0wVghk2NUR4TEzTeDugs5QCHkri/8wtd0TuJMzhysObri qxb0TVsDyR9LrH86rcIrwSHjtH6CuGJysiwMI0frNXfxzCpEscJCDAxML9CbPDhEy7OMTtmz ylbDFqNkylxZPGCLragkto0Ky+zavnqMywJZRNSTRDYMo36LpUOsNQYtPf18rmv7uMCa0Far UEB8SnfL0FPxy1pcyEP8zwsaRo7Lv/VbT39SJmKkQjXCz2d0sBH7vkUDKrQTMSGbSO2swR3Z TSQFkiWlTia9wfCUSCeF0iq10ivF0iw1NCeDKSn9wEMSrCMlQTcbMskUQ6IDuv+va0x8Crrs TDgxdVPGTDM5FSNzZLXggLV1y8fbDLs1C0K1wqgh1EgsKrcjxE6OrFM0qastG7eyQqsrSZOf fCsVXKHC5BcxREMpXDY1LCT6szid1DiumkmvO7GxZL9CZcO2o8aHFNLzrD/C+rSsgs2p+7xr 0jwF/S9HRDwOnS/LA8IFc61PnMEXjTTpJDJeZTQ9rbxPUbyqJMslqjbWw0oRvUp3wre3rELA JEUbC7gzqU4UTY1h1Y8XpMp4U7ehhD3iUy4W/dDkrFXMqyZeDdFdzKV+exbP08X2ylWA003w Q1QJfTtLVEt9o1b1ypYyy8f3fEzm+DigKw+YjEaRnK7/D1uXkLuj0ry8zJQVg0NTv3rX3Yuo G21B1XpDiiqsinyOmCuRgknARPUYlIUSmYNZD2lZl90YL/WdmT2SJaJSLfXZnwXaoI1ZVt3T P0UhOO2jQEpIwSKYRMJZ5wQjNYnIVLtI5EBaB2Tapt2sdeRAskPUj/xa7+rZ6ZwgHGTMSa1J Hb3J9mBPUEU/Hm04UrvPM3K7h41MMyTG0MqvMh1JnXLaNmFJ8HJC+gRTOSLZWZW0tVTXr4ys AV1KeTXL5fNFYOqtEa3KB2U1f4tP0etQ3Io8Ab0U/0TMN4y6V8I11vtHALWjesXcbuM2Ys1K 6cLWP1Hd57LQaRWtowNdwExF/1290NaDVtd9yraMQ15k3MmFvmqRPscF2X0NzIac13gT1KDs SlytFNWDrgGNoXARzZ20RvWT2Gp0P8uEvz5RWvbcu4g1UlLCP27Uv2I0w/IbUvTM2yA9xvVV WmAc27JF3CoJIT7dsZp1KctBzhYrYKFF4ARW4AXOIAYbpYYsRQEkyqw1GeVQOggeOm9lMYGL WqbrYJGa4AQ7mdza3xz0rQ622T6zQa+Dq669wRyRWinRWYPUQa9VoZkiRLSkN74tw8vEz9wt 2cEqz4YSqL7j1CDGxk/d0Uo9WbY9N+rr1FKl3fokxEO52kVNUQOxJ1psXL7svDXqpWFh3i5r lc3TXP8xi1Fk21XCTFHNWlbNs1curkuEnTX7Kl7dQr1RPN1Z3IxI1L1rG7e9Ta631MCD9cTj JV5lTMtGdD7FtY4rzlzwtNY4rl0PHVhKrj7+NEy7LLotzsvHNa/jY8vUKz1LUszaGt4rxqnQ xMkqljJwbEaXlL95MsYa1eH5k2JOxcJSXTvHzBOFhcZWbmL0Rb+COslsLMADLsiXnWEhUeYp AeAmbWZGmebijOYwLeGjreaQfFqHeWYGBudwFmcEzua2Q6/X9EejVaQc68dyZhidpWNCNcVj HUGavTLV2+aI6c69osiqtWck9EoCXsI0RLhPnS65FTzzbMNQU9V1UWgozl//iZW4+T3ZL74+ 8qDTi2ndXjXlyptcgg3D2OK1PT6NjR4m2ao+XeNoC67ekhmn2WUt5JuVTbxd6b24Z/3j2k2h 3aVcmWZp3u3MkOnKVRPle81kRiJqM96iPU62+Kov6+0UAfXDwGTCj4E79R1oja07iprRWnZf 1eRb+yPNzqxbggZjQdZlh/LkjB7ndXbntk4YAYbrkerfubbru8brvNbrvebrvvbrvwbswBbs wSbswjbsw0bsxFbsxWZsBu6b2rGgx2YQyQ4Ryt6YAyqd/kGa8MkfzYEg7MmexKmfzdYc79Fs uIibz95s/VHt/uFszMFs/UFtzx7t2D5t/NEb3tFt//JhHfrhEPHRHd4Zn89RHOCmm7Ihbrwp HtIZneQ+btPeH8BR7tzenO4JHMox7ukpHus27tTmm7rRbvBGn9TxG9bJnd/27vSZbskZbvbO HtNm7uLO7udWHvpGncdOb/uJHeeWHvdeH8kJIOuRm9Iun715nfI+G8iOENEW7upW8OW2H+35 7+22bwGv8AC/HgvP8PTBb/WmiQB/n/pmnN4uHPWBnOSWnRDvEAYf7REPIN7+cBevHdX2H+8h H9SWcf32cBFn7eYZbx0P7/zZ8AEfnfIpchQH7t1REQZXbwDS7vdWnwwX8qppn/g+Hf62cd1+ 8h1nH/kp8f8+nw//7iuP7/8hZ5+vMXKvme8R95slz+8u93EkD/IOX58bj3A7r4nWHnIm33IH z/MZh+wqx3AQR+7THpvkEfAbZ54U4XM4v+/mKfT9nhz4nhzt+XL5pvT7lu4yb3Qfh/AGZ+8H D57W4fIzD/NDP3Up1/Ip35BOd5/uhvRLh2/oOW/lzu4Q327LnhsVtx5C725LB3UyP/XlrnJP B/NMh/HmrnRGhyDaBh64iW5o9+5nX5por3bM9pmcUZrQXu3Mzu3XfvFm33bSHnPnrvH5cW38 fnYu55/QLnANR2wFF6AHovd6t/d7x/d81/d95/d+9/d/x3DBlvfGJviCN/iDR/iEV/iFZ/iG d/hFh4f4iJf4iaf4irf4i8f4jNf4jef4jvf4jwf5kBf5kSf5kjf5k0f5lFf5lWf5lnf5l4f5 mJf5maf5mrf5m8f5nNf5jQ8IADsz59fob55v58cncm2n1k3vh4vjcl4z4vyh8k40199jhufe o62l0k20w01thtj098s788us2cxyjfrvtsmtxwj4c8985dh84ba6oiwfs35h7i03mje933ph z29ujeiqs1sxi834abyxncmvz9dx7kqz668fwjjz60vq5cw6vno9rrn7dlcf6k9c5802hr3o ex022mh0ht1c5rjk13unp8nicfvvhh1dtbq5wku81na9nmz4pimugwwrrrrunz9jg9x7g8wr f3i38i199usbxy3btig8bpv3qxf9wcq7pmkup4gtnvgjipa1tnfbqgfa85pf9iwphzycgiw= --hrern7r4xg8us7zl03mv-- --0-2216393387-6677336283=:86091-- From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Jun 05 08:12:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnDwp-0000mO-EK for eap-archive@lists.ietf.org; Mon, 05 Jun 2006 08:12:43 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnDwo-0006SY-0F for eap-archive@lists.ietf.org; Mon, 05 Jun 2006 08:12:43 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E4AE84300B7 for ; Mon, 5 Jun 2006 05:12:40 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 30F284300B7 for ; Mon, 5 Jun 2006 05:12:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 043D1430BD9 for ; Mon, 5 Jun 2006 05:12:24 -0700 (PDT) Received: from hotmail.com (bay106-f33.bay106.hotmail.com [65.54.161.43]) by hermes.tigertech.net (Postfix) with ESMTP id 6FAE4430B8F for ; Mon, 5 Jun 2006 05:12:21 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 5 Jun 2006 05:12:20 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Mon, 05 Jun 2006 12:12:15 GMT X-Originating-IP: [24.16.73.85] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: eap@frascone.com Date: Mon, 05 Jun 2006 05:12:15 -0700 Mime-Version: 1.0 X-OriginalArrivalTime: 05 Jun 2006 12:12:20.0789 (UTC) FILETIME=[4BB0CE50:01C68899] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=1.7 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Subject: Re: [eap] Proposed Resolution of Issue 361: Child Key Expiry X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Here is an update to Section 3.3, which better captures the distinction between maximum lifetime and actual lifetime: 3.3. Parent-Child Relationships When an EAP re-authentication takes place, new keying material is derived and exported by the EAP method, which eventually results in replacement of TSKs, regardless of the way they are derived (see Section 2.1). While the maximum lifetime of TSKs or child keys can be less than or equal to that of the MSK/EMSK, it cannot be greater. This is true even where exported EAP keying material is only used for entity authentication and is not used for key derivation (such as in IKEv2), so that compromise of exported EAP keying material does not imply compromise of the TSKs or child keys. However, where child keys are derived from or are wrapped by EAP keying material, compromise of the MSK/EMSK does imply compromise of the child keys. Child keys that are used frequently (such as TSKs which are used for traffic protection) can expire sooner than the exported EAP keying material they are dependent on, so that it is advantageous to support re-key of child keys prior to EAP re-authentication. Note that deletion of the MSK/EMSK does not necessarily imply deletion of TSKs or child keys. Failure to mutually prove possession of exported EAP keying material during the Secure Association Protocol exchange need not be grounds for deletion of the keying material by both parties; rate-limiting Secure Association Protocol exchanges could be used to prevent a brute force attack. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Jun 05 13:54:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnJHQ-0005NK-Fv for eap-archive@lists.ietf.org; Mon, 05 Jun 2006 13:54:20 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnJHO-0004Vh-BH for eap-archive@lists.ietf.org; Mon, 05 Jun 2006 13:54:20 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id B5D0E430127 for ; Mon, 5 Jun 2006 10:54:17 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id B88B0430077 for ; Mon, 5 Jun 2006 10:54:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id AD0F039801C for ; Mon, 5 Jun 2006 10:54:04 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0BECB398059 for ; Mon, 5 Jun 2006 10:54:00 -0700 (PDT) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id C997089870; Mon, 5 Jun 2006 20:53:57 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 895568985B; Mon, 5 Jun 2006 20:53:57 +0300 (EEST) Message-ID: <44846FB4.4010800@piuha.net> Date: Mon, 05 Jun 2006 20:53:56 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: emu@ietf.org, eap@frascone.com References: In-Reply-To: X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: [eap] FW: Last Call: 'The Protected One-Time Password Protocol (EAP-POTP)' to Informational RFC (draft-nystrom-eap-potp) X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d FYI. Comments on this EAP method specification would be most appreciated. >The IESG has received a request from an individual submitter to consider the >following document: > >- 'The Protected One-Time Password Protocol (EAP-POTP) ' > as an Informational RFC > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send any comments to the >iesg@ietf.org or ietf@ietf.org mailing lists by 2006-07-03. > >The file can be obtained via >http://www.ietf.org/internet-drafts/draft-nystrom-eap-potp-05.txt > >_______________________________________________ >IETF-Announce mailing list >IETF-Announce@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf-announce > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Jun 05 16:05:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnL9o-0003RI-As for eap-archive@lists.ietf.org; Mon, 05 Jun 2006 15:54:36 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnL9m-0007JX-Me for eap-archive@lists.ietf.org; Mon, 05 Jun 2006 15:54:36 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id BA9224301A7 for ; Mon, 5 Jun 2006 12:54:33 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 50658430082 for ; Mon, 5 Jun 2006 12:54:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4031A39803E for ; Mon, 5 Jun 2006 12:54:20 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id 95F4B398008 for ; Mon, 5 Jun 2006 12:54:17 -0700 (PDT) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 323FD89870; Mon, 5 Jun 2006 22:54:14 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id DFE6D8985B; Mon, 5 Jun 2006 22:54:13 +0300 (EEST) Message-ID: <44848BE4.3000808@piuha.net> Date: Mon, 05 Jun 2006 22:54:12 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hannes Tschofenig References: <44846FB4.4010800@piuha.net> <448472BF.10508@gmx.net> In-Reply-To: <448472BF.10508@gmx.net> X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: emu@ietf.org, eap@frascone.com Subject: Re: [eap] [Emu] FW: Last Call: 'The Protected One-Time Password Protocol (EAP-POTP)' to Informational RFC (draft-nystrom-eap-potp) X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Hi Hannes, > I must have missed it but who did the expert review for EAP-POTP? Technically, it does not need expert review for IANA allocation since an existing allocation (#32) is used. But I believe the document does need wider IETF review due to its potential impact in the real world, and that's why its being last called and I'm asking you to review it. In any case, I have reviewed this document and as a part of that review I also went through the same questions as we normally do on the expert review. That review was recently posted to the EAP WG list and resulted in a new revision of the document. In order to avoid e-mail duplication, if you have comments on my review or this thread, post your comment to the EAP list. But other comments on IETF last calls should normally go to the ietf@ietf.org list. --Jari _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Jun 06 00:44:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnTQB-00039w-QO for eap-archive@lists.ietf.org; Tue, 06 Jun 2006 00:44:03 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnTQ9-0000cs-TQ for eap-archive@lists.ietf.org; Tue, 06 Jun 2006 00:44:03 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id CD169430130 for ; Mon, 5 Jun 2006 21:44:00 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 0596B4300D4 for ; Mon, 5 Jun 2006 21:43:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id E31DE398011 for ; Mon, 5 Jun 2006 21:43:39 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by zoidberg.tigertech.net (Postfix) with ESMTP id 080A139801D for ; Mon, 5 Jun 2006 21:43:36 -0700 (PDT) Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 05 Jun 2006 21:43:36 -0700 X-IronPort-AV: i="4.05,213,1146466800"; d="scan'208"; a="289357364:sNHT36172364" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k564hZMD019171; Mon, 5 Jun 2006 21:43:35 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k564hZIs007822; Mon, 5 Jun 2006 21:43:35 -0700 (PDT) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Jun 2006 21:43:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 5 Jun 2006 21:43:33 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Proposed Resolution to Issue 367: Key Scope and ServerAuthorization Thread-Index: AcaHdI1L3GvGbd80RvazGyD4id03BgBq967g From: "Joseph Salowey (jsalowey)" To: "Bernard Aboba" , X-OriginalArrivalTime: 06 Jun 2006 04:43:35.0311 (UTC) FILETIME=[C544A9F0:01C68923] Authentication-Results: sj-dkim-5.cisco.com; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [eap] Proposed Resolution to Issue 367: Key Scope and ServerAuthorization X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac Hi Bernard, I think the text below is good, but I don't think it addresses the issue I had in mind. Consider the case where each authenticator contains its own EAP Server. If the peer wants to ensure that it is connecting to the "correct" authenticator it obviously cannot just rely upon channel bindings since the authenticator is in control of the EAP server, it must be able to authorize the EAP server as being able to authorize the authenticator. If we consider a remote EAP Server then this EAP server will be authorized to atuhorize as subset of authenticators. In order for a peer to verify that the authenticator in collusion with the EAP server is not lying about some parameter it must be able to authorize the EAP Server as being able to authorize the authenticator. In some ways this is a basic thing, but I don't think this is currently covered elswhere in the document. It may not belong in this section, but I think it belongs somewhere with the scoping discussion. Joe Bernard Aboba wrote: > The text of Issue 367 is enclosed below. The proposed > resolution is to > change Section 2.2 to the text enclosed below, as well as to > add a new > Section 2.2.1, as follows: > > 2.2. Peer and Authenticator Architecture > > This specification does not impose constraints on the > architecture of > the EAP authenticator or peer. Any of the authenticator > architectures described in [RFC4118] can be used. As a result, > lower > layers need to > identify EAP peers and authenticators unambiguously, without > incorporating implicit assumptions about peer and authenticator > architectures. > > For example, it is possible for multiple base stations and a > "controller" (e.g. WLAN switch) to comprise a single EAP > authenticator. In such a situation, the "base station identity" is > irrelevant to the EAP method conversation, except perhaps as an > opaque blob to be used in Channel Bindings. Many base stations can > share the same authenticator identity. It should be > understood that > an EAP authenticator or peer: > > [a] may contain one or more physical or logical ports; > [b] may advertise itself as one or more "virtual" > authenticators or peers; > [c] may utilize multiple CPUs; > [d] may support clustering services for load balancing or failover. > > Both the EAP peer and authenticator may have more than one physical > or logical port. A peer may simultaneously access the network via > multiple authenticators, or via multiple physical or > logical ports on > a given authenticator. Similarly, an authenticator may > offer network > access to multiple peers, each via a separate physical or logical > port. When a single physical authenticator advertises itself as > multiple "virtual authenticators", it is possible for a single > physical port to belong to multiple "virtual authenticators". > > An authenticator may be configured to communicate with > more than one > EAP server, each of which is configured to communicate > with a subset > of the authenticators. The situation is illustrated in Figure 3. > > +-+-+-+-+ > | EAP | > | Peer | > +-+-+-+-+ > | | | Peer Ports > / | \ > / | \ > / | \ > / | \ > / | \ > / | \ > / | \ > / | \ Authenticator > | | | | | | | | | Ports > +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ > | | | | | | > | Auth1 | | Auth2 | | Auth3 | > | | | | | | > +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ > \ | \ | > \ | \ | > \ | \ | > EAP over AAA \ | \ | > (optional) \ | \ | > \ | \ | > \ | \ | > \ | \ | > +-+-+-+-+-+ +-+-+-+-+-+ Backend > | EAP | | EAP | Authentication > | Server1 | | Server2 | Servers > +-+-+-+-+-+ +-+-+-+-+-+ > > Figure 3: Relationship between EAP peer, authenticator and server > > 2.2.1. Server Identification > > The EAP method conversation is between the EAP peer and server, as > identified by the Peer-Id and Server-Id. As shown in Figure 3, an > authenticator may be configured to communicate with multiple EAP > servers; the EAP server that an authenticator communicates with may > vary according to configuration and network and server > availability. While the EAP peer can assume that all EAP servers > within a realm have access to the credentials necessary to > validate an authentication attempt, it cannot assume that all EAP > servers share persistent state. > > Authenticators may be configured with different primary or > secondary EAP servers, in order to balance the load. Also, the > authenticator can dynamically determine the EAP server to which > requests will be sent; in event of a communication failure, the > authenticator may fail > over to another EAP server. For example, in Figure 3, > Authenticator2 may be initially configured with EAP server1 as its > primary backend authentication server, and EAP server2 as the > backup, but if EAP server1 becomes unavailable, EAP server2 may > become the primary server. > > In general, the EAP peer cannot direct an authentication > attempt to a > particular EAP server within a realm; this decision is > made solely by > the authenticator. Nor can it determine which EAP server > it will be > communicating with within a realm, prior to the start of the EAP > method conversation. The Server-Id is not included in the EAP- > Request/Identity, and since the authenticator determines the EAP > server dynamically, it typically is not possible for the > authenticator to advertise the Server-Id during the > discovery phase. > EAP methods may or may not export the Server-Id, and as a > result, the > EAP peer may not even learn which server it was conversing > with after > the EAP conversation completes successfully. > > As a result, an EAP peer, on connecting to a new authenticator or > reconnecting to the same authenticator, may find itself > communicating with a different EAP server. Fast reconnect, > defined in [RFC3748] Section 7.2, may fail if the EAP server that > the peer communicates with is not the same one with which it > initially established a security association. For example, an EAP > peer attempting > an EAP-TLS > session resume may find that the new EAP-TLS server will not have > access to the Master Key identified by the TLS Session-Id, and > therefore the session resumption attempt will fail, requiring > completion of a full EAP-TLS exchange. > > > ========================================================== > Issue 367: Key Scope and EAP Server Authorization > Submitter name: Joe Salowey > Submitter email address: jsalowey@cisco.com > Date Submitted: May 3, 2006 > Reference: http://lists.frascone.com/pipermail/eap/msg04231.html > Document: KEYING-12 Comment type: 'T'echnical > Priority: '1' Should fix > Section: 2.2.1 and 3.2 > Rationale/Explanation of issue: > > Section 1.4.1 correctly defines the scope of the EAP keying > material as > being defined by the EAP Peer and EAP server, however this > relationship is not carried out in other key scope discussions as far > as I > can tell. > In order for channel binding, key mixing etc. to work the > peer must make > sure that the key is used not just within the authorized parameters of > the lower layer, but of the authorized scope of the EAP > server as well. > > I'm not sure of all of all the places where this needs to be > addressed, but I think it needs to be addressed in section 2.2.1 > perhaps > by adding > > "[g] Verifying that the advertised scope is within the scope that the > EAP server is allowed to authorize" > > Section 3.2 should probably state somewhere that: > > "The peer should verify that the key scope advertised by the > authenticator is within the scope that is allowed to be authorized by > the EAP Server." > > [Bernard Aboba] > > I think I see the point, which is that a given authenticator may be > connected to more than one EAP server, and that all authenticators in > a realm > may not share the same EAP server. Also, EAP servers cannot > necessarily be assumed to share key state among each other. If the > selcted EAP method > does not > provide the Server-Id, then the peer cannot know the scope of > the keys it > derives with the EAP server. > > This can create a number of issues, such as a peer attempting (but > failing) a > fast reconnect because the server that the authenticator is > configured to communicate with is not the same one with which the peer > established the > previous session. > > However, there are other situations in which the server > identity is not > material, > such as handoff in an 11r Mobility Domain (MD), where the STA > only care > whether > a candidate AP is in the same MD, not whether the new > authenticator is > configured > to talk to the same backend authentication server as the > current or initial > AP. > > In practice, the peer determines whether an authenticator is > within the > scope > of authorization of the backend authentication server by > attempting to > complete > the SAP exchange with it. If the exchange succeeds, the > authenticator is > authorized; if not, it isn't. It is possible for the peer to attempt a > fast reconnect exchange with the wrong server; unless the > server were to > include its identity in the EAP-Request there is no way for > the peer to > determine what server it is talking to before the EAP method > conversation gets underway. Even if the authenticator were to > advertise > the server(s) > that it is configured to talk to, and even if those servers > were identified > by their Server-Ids, it would not be possible for the peer to > know a-priori > which server it was going to talk to, since the primary > server can change > due > to changes in network or server availability. > > Given this, I'm not sure how the peer can verify that an > authenticator is allowed to be authorized by an EAP server. > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap > > Arhives: http://lists.frascone.com/pipermail/eap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From tkowalski@boelter-yates.com Tue Jun 06 10:26:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FncVx-0003Ra-Mz for eap-archive@ietf.org; Tue, 06 Jun 2006 10:26:37 -0400 Received: from exmail.holmesbrakel.com ([207.245.14.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FncVv-0004KY-Ce for eap-archive@ietf.org; Tue, 06 Jun 2006 10:26:37 -0400 Message-ID: <662161c80604X3WO6YXR0494TC82RC5SZ9TVACIRAE6D@smtp.dnsexit.com> Date: Tue, 6 Jun 2006 14:26:35 +0300 From: "Graciela Roy" To: eap-archive@ietf.org Subject: This Week's Target Stock MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam: Not detected X-Spam-Score: 1.8 (+) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 H o t _S t 0 c k for attention. We found company ready to EXPLODE!! Put CGDC on your radar's now. This st0ck shows a significant up in stock price and sometimes in days, not months or years. Watch CGDC like a hawk tomorrow!! The alert is on!! CHINA GOLD CORP Symbol: CGDC Current Price: 0.38 A Company engaged in gold and minerals exploration and development of gold and mineral properties in China. Why consider CHINA GOLD CORP (CGDC)? Seee n0wadays what happened. • Rising gold prices are further accelerating this gold rush - The price of gold has up 250% over the past five years, and this is still only a quarter of when the price peaked 25 years ago. (Adjusted for inflation.) • HUGE gold discovery in southwestern China - Resources have already been estimated by analysts at 14 million ounces...and the number keeps climbing. • China is the world’s last great under-explored land-mass - Locked away in a Marxist time-warp with limited exploration technology, China’s rich virgin gold fields have been overlooked and ignored until recently. • China is already the world’s 4th largest producer of gold — and will soon be the world’s #1 producer AND #1 consumer. The country is going gold-crazy! • Foreign gold companies are now welcome - and the laws have been changed to provide full legal protection. You can see China’s developing gold boom is building momentum. Rare 0pp0rtunity for early investors!! CURRENT NEWS: China Gold Corp. Announces Shareholder Update China Gold Corp. (CGDC - News) is a Nevada Corporation, engaged in gold and minerals exploration and development of gold and mineral properties in China. The company is pleased to announce has entered into negotiations with Zhong Cui Investments LTD. for the acquisition of Gold Mine property in the rural mountainous Guang Ning District near Zhao Qing City, Guangdong Province of China. China Gold Corp. is currently evaluating the Gold Mine property preliminary geological information and the property. If the company’s due diligence produces favorable results, management is expected to sign the letter of intent with Zhong Cui Investments LTD. in the next thirty (30) days. The Letter of Intent requires both parties to draft a definitive agreement and terms of any subsequent joint venture. Property description and all additional information will be available upon finalization of the agreement. The company will be made further announcements in this regard in coming weeks. ABOUT THE COMPANY China Gold Corp. is a Nevada Corporation, engaged in gold and minerals exploration and development of gold and mineral properties in China. China Gold Corp. is dedicated to delivering growth to the shareholder by employing a disciplined business methodology through acquisitions and joint ventures. The Company seeks to acquire properties with the following development criteria: largely unexplored but highly prospective geological regions, ability to generate near-term revenue and cash flow, tremendous geological potential for world-class economic deposits. From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Jun 06 13:42:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnfZc-0007Cv-A1 for eap-archive@lists.ietf.org; Tue, 06 Jun 2006 13:42:36 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnfZa-0006aU-Ry for eap-archive@lists.ietf.org; Tue, 06 Jun 2006 13:42:36 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C3F8B4301E3 for ; Tue, 6 Jun 2006 10:42:33 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 4C9A54300D5 for ; Tue, 6 Jun 2006 10:42:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 272731448052 for ; Tue, 6 Jun 2006 10:42:20 -0700 (PDT) Received: from hotmail.com (bay106-f13.bay106.hotmail.com [65.54.161.23]) by hermes.tigertech.net (Postfix) with ESMTP id 90A9C144804C for ; Tue, 6 Jun 2006 10:42:18 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 6 Jun 2006 10:42:17 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Tue, 06 Jun 2006 17:42:13 GMT X-Originating-IP: [24.16.73.85] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: jsalowey@cisco.com, eap@frascone.com Date: Tue, 06 Jun 2006 10:42:13 -0700 Mime-Version: 1.0 X-OriginalArrivalTime: 06 Jun 2006 17:42:17.0553 (UTC) FILETIME=[8DE50410:01C68990] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=1.7 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Subject: Re: [eap] Proposed Resolution to Issue 367: Key Scope and ServerAuthorization X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d >I think the text below is good, but I don't think it addresses the issue >I had in mind. > >Consider the case where each authenticator contains its own EAP Server. >If the peer wants to ensure that it is connecting to the "correct" >authenticator it obviously cannot just rely upon channel bindings since >the authenticator is in control of the EAP server, it must be able to >authorize the EAP server as being able to authorize the authenticator. >If we consider a remote EAP Server then this EAP server will be >authorized to authorize a subset of authenticators. In order for a >peer to verify that the authenticator in collusion with the EAP server >is not lying about some parameter it must be able to authorize the EAP >Server as being able to authorize the authenticator. > >In some ways this is a basic thing, but I don't think this is currently >covered elsewhere in the document. It may not belong in this section, >but I think it belongs somewhere with the scoping discussion. > > >Joe When the EAP method exports the Server-Id, and the claim of server identity is authenticated (such as via certificates) the peer can decide whether the EAP server is authorized or not. As you note, channel bindings only apply when the EAP server can be trusted. By the principle of mode independence, the peer doesn't know whether the authenticator and EAP server are co-located or not, so that Server-Id seems like the only thing that the peer has to verify server authorization. The authenticator and server could collude in the pass-through or standalone case, and there is really no way for the peer to detect this. Do you have some text to suggest? _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From ShannonTimmons@earthlink.net Tue Jun 06 14:37:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FngQg-0001ee-UG; Tue, 06 Jun 2006 14:37:26 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FngGo-0002Wi-Gf; Tue, 06 Jun 2006 14:27:14 -0400 Received: from 82-32-5-90.cable.ubr01.azte.blueyonder.co.uk ([82.32.5.90] helo=ZAHUUR.ieoli8s.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fng55-0008QO-NT; Tue, 06 Jun 2006 14:15:08 -0400 From: "Shannon" To: Subject: re:[1] ctxe.pk overwhelmingly important letter Date: Tue, 6 Jun 2006 19:12:11 +0000 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: UpPFUstPeyRQpSjBaq1OiTWYDHANpFKq1wU4 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.1 (++++) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Generate more money with expert info on booming sstocks Get Ctxe.Pk First Thing Today, It Is Exploding Now! Price: $0.59 Change: $0.06 (11.76%) within 1 day! Open: 0.53 Volume change: 521% Within 1 day! ! ! and this is just the beginning. Keep your radar on it! Before we start with the profile of CTXE we would like to mention something very important: A Big PR Campaign is moving this week . And it will go all week so it would be best to get in Now. Company Profile Cantex Energy Corporation is an independent, managed risk, oil and gas exploration, development, and production company headquartered in San Antonio, Texas. Recent News Cantex Energy Corp. Receiving Interest From the Industry as It Enters Next Phase of Development Cantex Energy Corp. (CTXE - News) is pleased to report the following on its Big Canyon Prospect in West Texas. Recent company announcements related to the acquisition of over 48,000 acres of a world-class prospect has captured the attention of many oil & gas industry experts and corporations, who have recently inquired into various participation opportunities ranging from sharing science technology to support findings or expertise to drill, operate and manage wells. Trace Maurin, President of Cantex, commented, "Although we are a small independent oil & gas company, we have a very unique 0pp0rtunity in one of the last under-explored world-class potential gas plays with no geopolitical risks and the industry is starting to take notice. As we prepare to prove up the various structures within our prospect later this month, we are increasing our efforts to communicate on our progress to our shareholders and investors. Our intention is to provide investors with a better understanding of the full potential of this prospect as we embark on the next phase of operations." Starting immediately the company will undertake CEO interviews, radio spots (which will be recorded and published on the company website), publication placements, introductions to small cap institutional investors and funds all in an effort to optimize market awareness and keep our shareholder well informed. Conclusion: The Examples Above Show The Awesome, Earning Potential of Little Known Companies That Explode Onto Investor's Radar Screens; Many of You Are Already Familiar with This. Is CTXE Poised and Positioned to Do that For You? Then You May Feel the Time Has Come to Act... And Please Watch this One Trade tomorrow! Go CTXE. Pen-ny sttocks are considered highly speculative and may be unsuitable for all but very aggressive investors. This Profile is not in any way affiliated with the featured company. This report is for entertainment and advertising purposes only and should not be used as investment advice. If you wish to stop future mailings, or if you feel you have been wrongfully placed in our membership, send a blank e mail with No Thanks in the sub ject to Epxected pirce at the end of the week: $1.0! Fast and reliable sstock recommendations This sstock is greeatly recomeended by agressive iinvestors in a shoort term. Don't loose a chance to earnn. Learn sstock market patters that help earn more ............................. It is what is in the mind when sober, that comes out of the mouth when drunk Think before you speak One man's meat is another man's poison.. What goes up must come down Borrowed Garments Never Fit Well When children stand still they have done some ill Nah all who guh a church house ah guh fuh pray. The longest rope has an end Virtual reality is its own reward. Fortune favours the brave As you sow, so shall you reap Strike while the iron is hot A volunteer is worth twenty pressed men. Might as well be hanged for a sheep as a lamb . The modem is the message. Love makes the world go round He who laughs last, thinks the slowest! It never rains, but it pours. What sunshine is to flowers, smiles are to humanity Waste not, want not Many hands make light work No man is an island No wind, no waves Merry Nights Make Sorry Days Many a true word is spoken in jest Seeing is believing A person who can smile when things go wrong has found someone to blame it on. Dont make love at the garden gate, love is blind but the neighbours aint A place for everything and everything in its place. If cow-man pass wild meat whah mek me must pick up am. Every rope gat two ends. So are the ways of every one that is greedy of gain; which taketh away the life of the owners thereof. Melt the icy fingers of fear with the sunshine of hope Age is a very high price to pay for maturity. . Life is beautiful Seldom seen, soon forgotten Six of one, half a dozen of the other . My son, hear the instruction of thy father, and forsake not the law of thy mother. Genius is an Infinite Capacity for Taking Pains He is an ill companion that has a good memory Never judge a book by its cover You only live once A happy heart makes the face cheerful, but heartache crushes the spirit The bigger they are, the harder they fall From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Jun 06 16:02:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnhl9-00059c-Ne for eap-archive@lists.ietf.org; Tue, 06 Jun 2006 16:02:39 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnhl7-0000d9-5A for eap-archive@lists.ietf.org; Tue, 06 Jun 2006 16:02:39 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id BDAF7430248 for ; Tue, 6 Jun 2006 13:02:36 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id B226A430169 for ; Tue, 6 Jun 2006 13:02:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7969239805E for ; Tue, 6 Jun 2006 13:02:22 -0700 (PDT) Received: from imx11.toshiba.co.jp (imx11.toshiba.co.jp [61.202.160.20]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1146A398083 for ; Tue, 6 Jun 2006 13:02:17 -0700 (PDT) Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149]) by imx11.toshiba.co.jp with ESMTP id k56K2GQZ014948; Wed, 7 Jun 2006 05:02:16 +0900 (JST) Received: (from root@localhost) by wall11.toshiba.co.jp id k56K3du1008965; Wed, 7 Jun 2006 05:03:39 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by wall11.toshiba.co.jp with SMTP id FAA08940; Wed, 7 Jun 2006 05:03:39 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id k56K2Fjt020329; Wed, 7 Jun 2006 05:02:15 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k56K2FiY001847; Wed, 7 Jun 2006 05:02:15 +0900 (JST) Received: from steelhead ([172.30.24.104]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J0G00JE0FNLX0L0@mail.po.toshiba.co.jp>; Wed, 07 Jun 2006 05:02:15 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.62) (envelope-from ) id 1FnhkQ-0003vF-Hs; Tue, 06 Jun 2006 13:01:54 -0700 Date: Tue, 06 Jun 2006 16:01:54 -0400 From: Yoshihiro Ohba In-reply-to: To: Bernard Aboba Message-id: <20060606200154.GA14834@steelhead> MIME-version: 1.0 Content-disposition: inline References: User-Agent: Mutt/1.5.11+cvs20060403 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: eap@frascone.com Subject: Re: [eap] Proposed Resolution to Issue 352: Channel Binding Issue X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 I have one comment. On Sun, Jun 04, 2006 at 06:31:15PM -0700, Bernard Aboba wrote: > > It is also possible to achieve Channel Bindings without transporting > data over EAP. For example, see [I-D.draft-ohba-eap-channel-binding]. > In this approach the EAP method includes Channel Bindings in the > calculation of exported EAP keying material, making it impossible for > the peer and authenticator to complete the Secure Association Protocol > if there is a mismatch in the Channel Bindings. However, this approach > can only be applied where EAP methods generating key material are used > along with lower layers that utilize the keying material. For example, > this mechanism would not enable verification of Channel Bindings on > wired IEEE 802 networks which do not support data frame protection." > The last sentence is correct when 802.1X is used as EAP transport over wired IEEE 802 networks, but not correct when PANA is used where it is still possible to enable verification of Channel Bindings with this scheme by protected PANA-Bind exchange as I mentioned to Joe. I would suggest revising the last two sentences something like: " However, this approach can only be applied where EAP methods generating key material are used along with lower layers that utilize the keying material for data frame frame protection. For example, this mechanism would not enable verification of Channel Bindings on wired IEEE 802 networks using IEEE 802.1X. " Regards, Yoshihiro Ohba _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Jun 06 17:16:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fniuy-00021i-3q for eap-archive@lists.ietf.org; Tue, 06 Jun 2006 17:16:52 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fniuv-0001LN-Jy for eap-archive@lists.ietf.org; Tue, 06 Jun 2006 17:16:52 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 612D1430288 for ; Tue, 6 Jun 2006 14:16:48 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 72DA14300D5 for ; Tue, 6 Jun 2006 14:16:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 50CC91448070 for ; Tue, 6 Jun 2006 14:16:31 -0700 (PDT) Received: from hotmail.com (bay106-f29.bay106.hotmail.com [65.54.161.39]) by hermes.tigertech.net (Postfix) with ESMTP id 357831448069 for ; Tue, 6 Jun 2006 14:16:29 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 6 Jun 2006 14:16:28 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Tue, 06 Jun 2006 21:16:23 GMT X-Originating-IP: [24.16.73.85] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: bernard_aboba@hotmail.com, jsalowey@cisco.com, eap@frascone.com Date: Tue, 06 Jun 2006 14:16:23 -0700 Mime-Version: 1.0 X-OriginalArrivalTime: 06 Jun 2006 21:16:28.0504 (UTC) FILETIME=[79A88580:01C689AE] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=1.7 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Subject: Re: [eap] Proposed Resolution to Issue 367: Key Scope andServerAuthorization X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac How about the following: Add the following paragraphs to the end of Section 2.3 Server Identification: "EAP methods that support mutual authentication enable the EAP peer to only connect to authenticators authenticated by a trusted EAP server. However, mutual authentication may not result in verification of the EAP server identity. For example, the EAP peer may only verify that the EAP server possesses a long-term secret; in this case the EAP peer will only know that an authenticator has been authorized by an EAP server, but will not know which one. EAP methods that export the Server-Id MUST verify the server identity. This enables the EAP peer to decide whether a specific EAP server is authorized or not, and determine whether the EAP server is sharing keying material outside the intended scope. In some cases, such as where the certificate extensions defined in [RFC4334] are included in the server certificate, it may even be possible for the peer to verify some Channel Binding parameters from the server certificate. Where the EAP peer does not verify the EAP server identity, it is not possible for the peer to determine whether keying material has been shared outside its authorized scope." >From: "Bernard Aboba" >To: jsalowey@cisco.com, eap@frascone.com >Subject: Re: [eap] Proposed Resolution to Issue 367: Key Scope >andServerAuthorization >Date: Tue, 06 Jun 2006 10:42:13 -0700 > > >I think the text below is good, but I don't think it addresses the issue > >I had in mind. > > > >Consider the case where each authenticator contains its own EAP Server. > >If the peer wants to ensure that it is connecting to the "correct" > >authenticator it obviously cannot just rely upon channel bindings since > >the authenticator is in control of the EAP server, it must be able to > >authorize the EAP server as being able to authorize the authenticator. > >If we consider a remote EAP Server then this EAP server will be > >authorized to authorize a subset of authenticators. In order for a > >peer to verify that the authenticator in collusion with the EAP server > >is not lying about some parameter it must be able to authorize the EAP > >Server as being able to authorize the authenticator. > > > >In some ways this is a basic thing, but I don't think this is currently > >covered elsewhere in the document. It may not belong in this section, > >but I think it belongs somewhere with the scoping discussion. > > > > > >Joe > >When the EAP method exports the Server-Id, and the claim of server identity >is authenticated (such as via certificates) the peer can decide whether the >EAP server is authorized or not. As you note, channel bindings only apply >when the EAP server can be trusted. By the principle of mode independence, >the peer doesn't know whether the authenticator and EAP server are >co-located or not, so that Server-Id seems like the only thing that the >peer >has to verify server authorization. The authenticator and server could >collude in the pass-through or standalone case, and there is really no way >for the peer to detect this. > >Do you have some text to suggest? > > >_________________________________________________________________ >To unsubscribe or modify your subscription options, please visit: >http://lists.frascone.com/mailman/listinfo/eap > >Arhives: http://lists.frascone.com/pipermail/eap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Jun 06 17:19:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnixb-0003pf-Qc for eap-archive@lists.ietf.org; Tue, 06 Jun 2006 17:19:35 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fni2U-0002Z6-Dt for eap-archive@lists.ietf.org; Tue, 06 Jun 2006 16:20:34 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fni1C-00027N-JX for eap-archive@lists.ietf.org; Tue, 06 Jun 2006 16:19:16 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 1DDEC430266 for ; Tue, 6 Jun 2006 13:19:13 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 21D76430169 for ; Tue, 6 Jun 2006 13:18:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 02A4B1448068 for ; Tue, 6 Jun 2006 13:18:47 -0700 (PDT) Received: from imx11.toshiba.co.jp (imx11.toshiba.co.jp [61.202.160.20]) by hermes.tigertech.net (Postfix) with ESMTP id 19FB8144804A for ; Tue, 6 Jun 2006 13:18:43 -0700 (PDT) Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149]) by imx11.toshiba.co.jp with ESMTP id k56KIgTd026928; Wed, 7 Jun 2006 05:18:42 +0900 (JST) Received: (from root@localhost) by wall11.toshiba.co.jp id k56KK6IE023932; Wed, 7 Jun 2006 05:20:06 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by wall11.toshiba.co.jp with SMTP id FAA23887; Wed, 7 Jun 2006 05:20:05 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id k56KIgUE027633; Wed, 7 Jun 2006 05:18:42 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k56KIflH009880; Wed, 7 Jun 2006 05:18:41 +0900 (JST) Received: from steelhead ([172.30.24.104]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J0G00JKSGEZX0L0@mail.po.toshiba.co.jp>; Wed, 07 Jun 2006 05:18:41 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.62) (envelope-from ) id 1Fni0U-0003yB-FJ; Tue, 06 Jun 2006 13:18:30 -0700 Date: Tue, 06 Jun 2006 16:18:30 -0400 From: Yoshihiro Ohba In-reply-to: <20060606200154.GA14834@steelhead> To: Bernard Aboba , eap@frascone.com Message-id: <20060606201830.GB14834@steelhead> MIME-version: 1.0 Content-disposition: inline References: <20060606200154.GA14834@steelhead> User-Agent: Mutt/1.5.11+cvs20060403 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Subject: Re: [eap] Proposed Resolution to Issue 352: Channel Binding Issue X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: -2.6 (--) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb On Tue, Jun 06, 2006 at 04:01:54PM -0400, Yoshihiro Ohba wrote: > I have one comment. > > On Sun, Jun 04, 2006 at 06:31:15PM -0700, Bernard Aboba wrote: > > > > It is also possible to achieve Channel Bindings without transporting > > data over EAP. For example, see [I-D.draft-ohba-eap-channel-binding]. > > In this approach the EAP method includes Channel Bindings in the > > calculation of exported EAP keying material, making it impossible for > > the peer and authenticator to complete the Secure Association Protocol > > if there is a mismatch in the Channel Bindings. However, this approach > > can only be applied where EAP methods generating key material are used > > along with lower layers that utilize the keying material. For example, > > this mechanism would not enable verification of Channel Bindings on > > wired IEEE 802 networks which do not support data frame protection." > > > > The last sentence is correct when 802.1X is used as EAP transport over > wired IEEE 802 networks, but not correct when PANA is used where it is > still possible to enable verification of Channel Bindings with this > scheme by protected PANA-Bind exchange as I mentioned to Joe. > > I would suggest revising the last two sentences something like: > > " > However, this approach can only be applied where EAP methods > generating key material are used > along with lower layers that utilize the keying material for data frame frame > protection. For example, this mechanism would not enable verification of Channel > Bindings on wired IEEE 802 networks using IEEE 802.1X. > " Sorry for self-responding, but the penultimate sentence does not need to be changed. My suggestion is for the last sentence only. Yoshihiro Ohba _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Jun 06 17:56:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnjXl-0003od-GO for eap-archive@lists.ietf.org; Tue, 06 Jun 2006 17:56:57 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FniX7-0006kJ-02 for eap-archive@lists.ietf.org; Tue, 06 Jun 2006 16:52:13 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FniIW-00036q-UN for eap-archive@lists.ietf.org; Tue, 06 Jun 2006 16:37:11 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 0047F43027C for ; Tue, 6 Jun 2006 13:37:07 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 7F570430169 for ; Tue, 6 Jun 2006 13:36:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 68CB439809C for ; Tue, 6 Jun 2006 13:36:53 -0700 (PDT) Received: from hotmail.com (bay106-f14.bay106.hotmail.com [65.54.161.24]) by zoidberg.tigertech.net (Postfix) with ESMTP id BFFB5398096 for ; Tue, 6 Jun 2006 13:36:50 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 6 Jun 2006 13:36:50 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Tue, 06 Jun 2006 20:36:45 GMT X-Originating-IP: [24.16.73.85] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <20060606201830.GB14834@steelhead> From: "Bernard Aboba" To: yohba@tari.toshiba.com, eap@frascone.com Date: Tue, 06 Jun 2006 13:36:45 -0700 Mime-Version: 1.0 X-OriginalArrivalTime: 06 Jun 2006 20:36:50.0380 (UTC) FILETIME=[F02F98C0:01C689A8] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.748 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Subject: Re: [eap] Proposed Resolution to Issue 352: Channel Binding Issue X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: -2.3 (--) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 >Sorry for self-responding, but the penultimate sentence does not need >to be changed. My suggestion is for the last sentence only. Here is the new paragraph: "It is also possible to achieve Channel Bindings without transporting data over EAP. For example, see [I-D.draft-ohba-eap-channel-binding]. In this approach the EAP method includes Channel Bindings in the calculation of exported EAP keying material, making it impossible for the peer and authenticator to complete the Secure Association Protocol if there is a mismatch in the Channel Bindings. However, this approach can only be applied where EAP methods generating key material are used along with lower layers that utilize the keying material for data frame frame protection. For example, this mechanism would not enable verification of Channel Bindings on wired IEEE 802 networks using IEEE 802.1X." Is this what you intended? _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Jun 06 18:00:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnjbC-0004zk-3C for eap-archive@lists.ietf.org; Tue, 06 Jun 2006 18:00:30 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnjb9-0008Ct-OX for eap-archive@lists.ietf.org; Tue, 06 Jun 2006 18:00:30 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 1FF0C430156 for ; Tue, 6 Jun 2006 15:00:27 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id AB2434300A5 for ; Tue, 6 Jun 2006 15:00:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 92E251448037 for ; Tue, 6 Jun 2006 15:00:10 -0700 (PDT) Received: from hotmail.com (bay106-f9.bay106.hotmail.com [65.54.161.19]) by hermes.tigertech.net (Postfix) with ESMTP id F3B461448036 for ; Tue, 6 Jun 2006 15:00:07 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 6 Jun 2006 15:00:07 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Tue, 06 Jun 2006 22:00:04 GMT X-Originating-IP: [24.16.73.85] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Tue, 06 Jun 2006 15:00:04 -0700 Mime-Version: 1.0 X-OriginalArrivalTime: 06 Jun 2006 22:00:07.0588 (UTC) FILETIME=[92C10640:01C689B4] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=1.7 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Subject: [eap] NIST issues Draft-SP800-97 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de NIST has issued Draft-SP800-97 which provides guidance on the deployment of IEEE 802.11i as well as EAP: http://csrc.nist.gov/publications/drafts/Draft-SP800-97.pdf _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Jun 06 18:02:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnjd5-00053q-K0 for eap-archive@lists.ietf.org; Tue, 06 Jun 2006 18:02:27 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnjd2-0008HX-Sf for eap-archive@lists.ietf.org; Tue, 06 Jun 2006 18:02:27 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 84A93430110 for ; Tue, 6 Jun 2006 15:02:24 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id B36814300D5 for ; Tue, 6 Jun 2006 15:01:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 74C9039802C for ; Tue, 6 Jun 2006 15:01:58 -0700 (PDT) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by zoidberg.tigertech.net (Postfix) with ESMTP id D9072398036 for ; Tue, 6 Jun 2006 15:01:54 -0700 (PDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id k56M1qSo008737; Wed, 7 Jun 2006 07:01:52 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id k56M1rVh010018; Wed, 7 Jun 2006 07:01:53 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id HAA09984; Wed, 7 Jun 2006 07:01:53 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id k56M1pXw006777; Wed, 7 Jun 2006 07:01:51 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k56M1pXG014584; Wed, 7 Jun 2006 07:01:51 +0900 (JST) Received: from steelhead ([172.30.24.104]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J0G00420L6X1U00@mail.po.toshiba.co.jp>; Wed, 07 Jun 2006 07:01:51 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.62) (envelope-from ) id 1FnjcG-00040U-UG; Tue, 06 Jun 2006 15:01:36 -0700 Date: Tue, 06 Jun 2006 18:01:36 -0400 From: Yoshihiro Ohba In-reply-to: To: Bernard Aboba Message-id: <20060606220136.GA15302@steelhead> MIME-version: 1.0 Content-disposition: inline References: <20060606201830.GB14834@steelhead> User-Agent: Mutt/1.5.11+cvs20060403 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: eap@frascone.com Subject: Re: [eap] Proposed Resolution to Issue 352: Channel Binding Issue X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 On Tue, Jun 06, 2006 at 01:36:45PM -0700, Bernard Aboba wrote: > >Sorry for self-responding, but the penultimate sentence does not need > >to be changed. My suggestion is for the last sentence only. > > Here is the new paragraph: > > "It is also possible to achieve Channel Bindings without transporting > data over EAP. For example, see [I-D.draft-ohba-eap-channel-binding]. > In this approach the EAP method includes Channel Bindings in the > calculation of exported EAP keying material, making it impossible for > the peer and authenticator to complete the Secure Association Protocol > if there is a mismatch in the Channel Bindings. > However, this approach can only be applied where EAP methods > generating key material are used > along with lower layers that utilize the keying material for data frame > frame > protection. For example, this mechanism would not enable verification of > Channel Bindings on wired IEEE 802 networks using IEEE 802.1X." > > Is this what you intended? > Not exactly. In the PANA usage for wired IEEE 802 networks the keying material is not for data frame protection, but just for protecting PANA messaging. So here is my intended text: " It is also possible to achieve Channel Bindings without transporting data over EAP. For example, see [I-D.draft-ohba-eap-channel-binding]. In this approach the EAP method includes Channel Bindings in the calculation of exported EAP keying material, making it impossible for the peer and authenticator to complete the Secure Association Protocol if there is a mismatch in the Channel Bindings. However, this approach can only be applied where EAP methods generating key material are used along with lower layers that utilize the keying material. For example, this mechanism would not enable verification of Channel Bindings on wired IEEE 802 networks using IEEE 802.1X. " Yoshihiro Ohba _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From edwarduklawhouse@rediffmail.com Tue Jun 06 20:12:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnlf3-0000YE-1D for eap-archive@ietf.org; Tue, 06 Jun 2006 20:12:37 -0400 Received: from outmail.rediffmailpro.com ([59.160.240.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnlf2-0006WZ-27 for eap-archive@ietf.org; Tue, 06 Jun 2006 20:12:37 -0400 Received: from unknown (HELO rediffmail.com) ([10.50.10.24]) by outmail.rediffmailpro.com with SMTP; 07 Jun 2006 05:43:46 +0530 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,215,1146421800"; d="scan'208,217"; a="13243659:sNHT1726522288" Received: (qmail 24231 invoked from network); 7 Jun 2006 00:10:50 -0000 Received: from unknown (HELO net2) (196.47.94.110) by mailserver with SMTP; 7 Jun 2006 00:10:50 -0000 Message-ID: <007001c689c7$16e8ca90$f10010ac@net2> Reply-To: "Edward Cole Law House UK" From: "Edward Cole Law House UK" To: Subject: Good day from Barrister Edward Cole, Esq. A solicitor and investment consultant based in London, united kingdom. Date: Tue, 6 Jun 2006 06:02:19 -0700 Organization: Edward Cole Law House UK MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_012E_01C6892E.C51ED170" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 3.4 (+++) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd This is a multi-part message in MIME format. ------=_NextPart_000_012E_01C6892E.C51ED170 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Sir / Madam,=20 The inspiration to contact you is simply divine providence, I am making = this proposition because I have to seek the partnership of a resource = person to help me realise this project.=20 I Edward Cole, esq. a solicitor and investment consultant based in = London, united kingdom.=20 I was attending a business luncheon in Berlin, Germany and I got = introduced to the renowned German business man and property mogul, Mr = Andreas Schranner (of the blessed memory).=20 He engaged my services as attorney and investment consultant and my = primary assignment was to spearhead his investment forays in the united = kingdom.=20 Three months later I invited him to London and under my professional = guidance and based on my advice he made a fixed deposit of = =A326,500,000,00 million pounds sterling at a financial institution.=20 This deposit was for 2years and upon maturity I made effort to contact = my client, I could not reach him or any member of his family. I was = forced to travel to Germany and there I got the tragic news that on July = 25 2000, my client Mr. Andreas Schranner, his wife Maria, their daughter = Eich and husband Christian and their two children perished in the air = France Concorde new York bound flight; please click here and find out = what happened to the family = =20 I have made efforts to locate any member of his family since then with = strong biological links to my late client without success. the search to = find a close relation is one that has consumed time and resources. The = institution is asking me to either present a next of kin to late Mr. = Andreas Schranner or forfeit the deposit.=20 My proposal is to package , present you as next of kin to late Mr. = Andreas Schranner and process the fixed deposit and transfer custody to = you for our mutual benefit. My capacity as solicitor/investment = consultant to my late client gives me the discretion to package and = transfer the deposit to you.=20 I will give you 40% for your effort, 60% for me It will amount to = injustice if I do not this decisive step to secure this deposit, and = invest it. The late Schranner was also a friend in addition to our = business relationship. I will wait for your reaction and response and = then together we can jumpstart this project and nurture it to reality. = You can send your reply to this email address; ( = info@edwardcolelawhouse.vossnet.co.uk ).=20 I await your reaction.=20 Kind Regards,=20 Edward Cole. Esq. ------=_NextPart_000_012E_01C6892E.C51ED170 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Sir / Madam,


The inspiration to contact you is simply divine providence, I am = making=20 this proposition because I have to seek the partnership of a resource = person to=20 help me realise this project.

I Edward Cole, esq. a solicitor and investment consultant based in = London,=20 united kingdom.

I was attending a business luncheon in Berlin, Germany and I got = introduced=20 to the renowned German business man and property mogul, Mr Andreas = Schranner (of=20 the blessed memory).

He engaged my services as attorney and investment consultant and my = primary=20 assignment was to spearhead his investment forays in the united kingdom. =

Three months later I invited him to London and under my professional = guidance=20 and based on my advice he made a fixed deposit of = =A326,500,000,00 million=20 pounds sterling at a financial institution.

This deposit was for 2years and upon maturity I made effort to = contact=20 my client, I could not reach him or any member of his family. I was = forced to=20 travel to Germany and there I got the tragic news that on July 25 = 2000,=20 my client Mr. Andreas Schranner, his wife Maria, their daughter Eich and = husband=20 Christian and their two children perished in the air France Concorde new = York=20 bound flight; please click here and find out what happened to the family = <http://news.bbc.co.uk/1/hi/world/europe/859479.stm>

I have made efforts to locate any member of his family since then = with strong=20 biological links to my late client without success. the search to find a = close=20 relation is one that has consumed time and resources. The institution is = asking=20 me to either present a next of kin to late Mr. Andreas Schranner or = forfeit the=20 deposit.

My proposal is to package , present you as next of kin to late Mr. = Andreas=20 Schranner and process the fixed deposit and transfer custody to you for = our=20 mutual benefit. My capacity as solicitor/investment consultant to my = late client=20 gives me the discretion to package and transfer the deposit to you.

I will give you 40% for your effort, 60% for me It will = amount=20 to injustice if I do not this decisive step to secure this deposit, and = invest=20 it. The late Schranner was also a friend in addition to our business=20 relationship. I will wait for your reaction and response and then = together we=20 can jumpstart this project and nurture it to reality. You can send your = reply to=20 this email address; ( info@edwardcolelawhouse.vossnet.co.uk ).

I await your reaction.

Kind Regards,

Edward Cole. Esq.

------=_NextPart_000_012E_01C6892E.C51ED170-- From edwarduklawhouse@rediffmail.com Tue Jun 06 21:08:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnmXS-0002GX-2f for eap-archive@ietf.org; Tue, 06 Jun 2006 21:08:50 -0400 Received: from outmail.rediffmailpro.com ([59.160.240.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnmXR-0006nw-Hu for eap-archive@ietf.org; Tue, 06 Jun 2006 21:08:50 -0400 Received: from unknown (HELO rediffmail.com) ([10.50.10.24]) by outmail.rediffmailpro.com with SMTP; 07 Jun 2006 06:40:02 +0530 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,215,1146421800"; d="scan'208,217"; a="13251950:sNHT681554220" Received: (qmail 31312 invoked from network); 7 Jun 2006 01:07:06 -0000 Received: from unknown (HELO net2) (196.47.94.110) by mailserver with SMTP; 7 Jun 2006 01:07:06 -0000 Message-ID: <00a101c689ce$f47a4580$f10010ac@net2> Reply-To: "Edward Cole Law House UK" From: "Edward Cole Law House UK" To: Subject: Good day from Barrister Edward Cole, Esq. A solicitor and investment consultant based in London, united kingdom. Date: Tue, 6 Jun 2006 17:42:48 -0700 Organization: Edward Cole Law House UK MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0092_01C68990.A041A370" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 3.1 (+++) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd This is a multi-part message in MIME format. ------=_NextPart_000_0092_01C68990.A041A370 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Sir / Madam,=20 The inspiration to contact you is simply divine providence, I am making = this proposition because I have to seek the partnership of a resource = person to help me realise this project.=20 I Edward Cole, esq. a solicitor and investment consultant based in = London, united kingdom.=20 I was attending a business luncheon in Berlin, Germany and I got = introduced to the renowned German business man and property mogul, Mr = Andreas Schranner (of the blessed memory).=20 He engaged my services as attorney and investment consultant and my = primary assignment was to spearhead his investment forays in the united = kingdom.=20 Three months later I invited him to London and under my professional = guidance and based on my advice he made a fixed deposit of = =A326,500,000,00 million pounds sterling at a financial institution.=20 This deposit was for 2years and upon maturity I made effort to contact = my client, I could not reach him or any member of his family. I was = forced to travel to Germany and there I got the tragic news that on July = 25 2000, my client Mr. Andreas Schranner, his wife Maria, their daughter = Eich and husband Christian and their two children perished in the air = France Concorde new York bound flight; please click here and find out = what happened to the family = =20 I have made efforts to locate any member of his family since then with = strong biological links to my late client without success. the search to = find a close relation is one that has consumed time and resources. The = institution is asking me to either present a next of kin to late Mr. = Andreas Schranner or forfeit the deposit.=20 My proposal is to package , present you as next of kin to late Mr. = Andreas Schranner and process the fixed deposit and transfer custody to = you for our mutual benefit. My capacity as solicitor/investment = consultant to my late client gives me the discretion to package and = transfer the deposit to you.=20 I will give you 40% for your effort, 60% for me It will amount to = injustice if I do not this decisive step to secure this deposit, and = invest it. The late Schranner was also a friend in addition to our = business relationship. I will wait for your reaction and response and = then together we can jumpstart this project and nurture it to reality. = You can send your reply to this email address; ( = info@edwardcolelawhouse.vossnet.co.uk ).=20 I await your reaction.=20 Kind Regards,=20 Edward Cole. Esq. ------=_NextPart_000_0092_01C68990.A041A370 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Sir / Madam,


The inspiration to contact you is simply divine providence, I am = making=20 this proposition because I have to seek the partnership of a resource = person to=20 help me realise this project.

I Edward Cole, esq. a solicitor and investment consultant based in = London,=20 united kingdom.

I was attending a business luncheon in Berlin, Germany and I got = introduced=20 to the renowned German business man and property mogul, Mr Andreas = Schranner (of=20 the blessed memory).

He engaged my services as attorney and investment consultant and my = primary=20 assignment was to spearhead his investment forays in the united kingdom. =

Three months later I invited him to London and under my professional = guidance=20 and based on my advice he made a fixed deposit of = =A326,500,000,00 million=20 pounds sterling at a financial institution.

This deposit was for 2years and upon maturity I made effort to = contact=20 my client, I could not reach him or any member of his family. I was = forced to=20 travel to Germany and there I got the tragic news that on July 25 = 2000,=20 my client Mr. Andreas Schranner, his wife Maria, their daughter Eich and = husband=20 Christian and their two children perished in the air France Concorde new = York=20 bound flight; please click here and find out what happened to the family = <http://news.bbc.co.uk/1/hi/world/europe/859479.stm>

I have made efforts to locate any member of his family since then = with strong=20 biological links to my late client without success. the search to find a = close=20 relation is one that has consumed time and resources. The institution is = asking=20 me to either present a next of kin to late Mr. Andreas Schranner or = forfeit the=20 deposit.

My proposal is to package , present you as next of kin to late Mr. = Andreas=20 Schranner and process the fixed deposit and transfer custody to you for = our=20 mutual benefit. My capacity as solicitor/investment consultant to my = late client=20 gives me the discretion to package and transfer the deposit to you.

I will give you 40% for your effort, 60% for me It will = amount=20 to injustice if I do not this decisive step to secure this deposit, and = invest=20 it. The late Schranner was also a friend in addition to our business=20 relationship. I will wait for your reaction and response and then = together we=20 can jumpstart this project and nurture it to reality. You can send your = reply to=20 this email address; ( info@edwardcolelawhouse.vossnet.co.uk ).

I await your reaction.

Kind Regards,

Edward Cole. Esq.

------=_NextPart_000_0092_01C68990.A041A370-- From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Jun 06 22:26:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnnkq-0004RD-33 for eap-archive@lists.ietf.org; Tue, 06 Jun 2006 22:26:44 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnnko-000658-Lc for eap-archive@lists.ietf.org; Tue, 06 Jun 2006 22:26:44 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D1DEE430141 for ; Tue, 6 Jun 2006 19:26:41 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id F2CAD430054 for ; Tue, 6 Jun 2006 19:26:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C43341448018 for ; Tue, 6 Jun 2006 19:26:27 -0700 (PDT) Received: from hotmail.com (bay106-f8.bay106.hotmail.com [65.54.161.18]) by hermes.tigertech.net (Postfix) with ESMTP id 2A5D6144800D for ; Tue, 6 Jun 2006 19:26:25 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 6 Jun 2006 19:26:24 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Wed, 07 Jun 2006 02:26:21 GMT X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <20060606220136.GA15302@steelhead> From: "Bernard Aboba" To: yohba@tari.toshiba.com Date: Tue, 06 Jun 2006 19:26:21 -0700 Mime-Version: 1.0 X-OriginalArrivalTime: 07 Jun 2006 02:26:24.0560 (UTC) FILETIME=[C5C57B00:01C689D9] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=1.7 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Cc: eap@frascone.com Subject: Re: [eap] Proposed Resolution to Issue 352: Channel Binding Issue X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Got it. >So here is my intended text: > >" >It is also possible to achieve Channel Bindings without transporting >data over EAP. For example, see [I-D.draft-ohba-eap-channel-binding]. >In this approach the EAP method includes Channel Bindings in the >calculation of exported EAP keying material, making it impossible for >the peer and authenticator to complete the Secure Association Protocol >if there is a mismatch in the Channel Bindings. However, this >approach can only be applied where EAP methods generating key material >are used along with lower layers that utilize the keying material. >For example, this mechanism would not enable verification of Channel >Bindings on wired IEEE 802 networks using IEEE 802.1X. >" > >Yoshihiro Ohba _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Jun 07 01:23:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnqVP-0002Ig-W2 for eap-archive@lists.ietf.org; Wed, 07 Jun 2006 01:23:00 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnqS3-0001TA-P3 for eap-archive@lists.ietf.org; Wed, 07 Jun 2006 01:19:34 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 207CA43010C for ; Tue, 6 Jun 2006 22:19:31 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id D9CD2430054 for ; Tue, 6 Jun 2006 22:19:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9C91F144800A for ; Tue, 6 Jun 2006 22:19:16 -0700 (PDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by hermes.tigertech.net (Postfix) with ESMTP id DDF20144801D for ; Tue, 6 Jun 2006 22:19:12 -0700 (PDT) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k575JB7L007293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 6 Jun 2006 22:19:12 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k575JAXK015008; Tue, 6 Jun 2006 22:19:10 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Jun 2006 22:19:09 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 Jun 2006 22:19:07 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB849989FA@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Proposed Resolution to Issue 357: Channel Binding Definition Thread-Index: AcaHd/3O7BgKY129QZKe1I5MTuGpdgCeYwgg From: "Narayanan, Vidya" To: "Bernard Aboba" , X-OriginalArrivalTime: 07 Jun 2006 05:19:09.0810 (UTC) FILETIME=[E7F11D20:01C689F1] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Subject: Re: [eap] Proposed Resolution to Issue 357: Channel Binding Definition X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Hi Bernard, The proposed text by Jari went through some revisions as I recall, based on some discussions on the list. Here is the latest on that text I pulled out from one of Jari's email, subsequent to the discussions: "I'd be happy to restrict the definition to peer and server agreeing that they have the same view of the channel properties claimed by the authenticator. (But part of the distinction may also be in the specific implementation of the "agreement"; what we are looking for is that the values agree, without specifying who sends the values and who verifies them.)" Based on the above, how about the following definition? "Channel Binding A secure mechanism for ensuring that a chosen set of channel properties (such as authenticator identifiers and properties) are agreed upon by the EAP peer and server." Vidya > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > Sent: Saturday, June 03, 2006 6:41 PM > To: eap@frascone.com > Subject: [eap] Proposed Resolution to Issue 357: Channel > Binding Definition > > The text of Issue 357 is enclosed below. The proposed > resolution is to accept the definition proposed by Jari Arkko: > > "Channel Binding > > A secure mechanism for ensuring that a chosen set of channel > properties (such as endpoint identifiers) are agreed upon by > the EAP peer, authenticator and server." > > -------------------------------------------------------------- > ---------------------------------- > Issue 357: Channel Binding Definition > Submitter name: Vidya Narayanan > Submitter email address: vidyan@qualcomm.com Date Submitted: > May 1, 2006 > Reference: http://lists.frascone.com/pipermail/eap/msg04227.html > Document: KEYING-12 > Comment type: 'T'echnical > Priority: '1' Should fix > Section: 1.2 > Rationale/Explanation of issue: > The document defines channel binding > as a communication within an EAP method - this seems a bit > restrictive, given that channel binding information could be > carried out-of-band as well. The only requirement is that the > information be integrity protected between the peer and server. > > Requested change: > Change wording to: > > "The communication of integrity-protected channel properties > such as endpoint identifiers which can be compared to values > communicated via out of band mechanisms (such as via a AAA or > lower layer protocol)." > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap > > Arhives: http://lists.frascone.com/pipermail/eap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Jun 07 02:12:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnrGy-0000z0-4m for eap-archive@lists.ietf.org; Wed, 07 Jun 2006 02:12:08 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnrE5-0008L7-BU for eap-archive@lists.ietf.org; Wed, 07 Jun 2006 02:09:11 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id B0AA4430130 for ; Tue, 6 Jun 2006 23:09:08 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 09C1D430054 for ; Tue, 6 Jun 2006 23:08:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E1B6A144801D for ; Tue, 6 Jun 2006 23:08:43 -0700 (PDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by hermes.tigertech.net (Postfix) with ESMTP id A34501448020 for ; Tue, 6 Jun 2006 23:08:41 -0700 (PDT) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5768dqV010467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 6 Jun 2006 23:08:40 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5768bgO028653; Tue, 6 Jun 2006 23:08:38 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Jun 2006 23:08:37 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 Jun 2006 23:04:50 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB84998A04@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Proposed Resolution of Issue 361: Child Key Expiry Thread-Index: AcaITv+zbzShRFabS6+x3i8UZXnnoQBqOQSw From: "Narayanan, Vidya" To: "Bernard Aboba" , X-OriginalArrivalTime: 07 Jun 2006 06:08:37.0101 (UTC) FILETIME=[D095C9D0:01C689F8] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Subject: Re: [eap] Proposed Resolution of Issue 361: Child Key Expiry X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 > > In looking at the discussion of this issue, and reviewing the > text, it is not clear how useful it is to have EAP methods > export the Key-Lifetime parameter. > Today no EAP > methods export this parameter, and the text in Section 1.4 > suggests that this is not very useful anyway: > > Key-Lifetime > > While EAP itself does not support key lifetime > negotiation, it is > possible to specify methods that do. However, systems that rely > on such negotiation for exported keys would only function with > these methods. As a result, it is NOT RECOMMENDED to use this > approach as the sole way to determine key lifetimes. > > Similarly, Section 3 states: > > Existing EAP methods do not export the Key-Lifetime > parameter; in the interest of method independence, key > management of > exported or derived keys SHOULD NOT be provided within EAP methods. > > As a result, it may make sense to remove discussion of the > Key-Lifetime parameter from the document. > Agreed. > The text of Issue 361 is enclosed below. The proposed > resolution is as > follows: > > In Section 1.4, delete: > > " Key-Lifetime > > While EAP itself does not support key lifetime > negotiation, it is > possible to specify methods that do. However, systems that rely > on such negotiation for exported keys would only function with > these methods. As a result, it is NOT RECOMMENDED to use this > approach as the sole way to determine key lifetimes." > > Also, delete the Key-Lifetime parameter from Figure 2. > > In Section 3, change: > > "Existing EAP methods do not export the Key-Lifetime > parameter; in the interest of method independence, key > management of exported or derived keys SHOULD NOT be provided > within EAP methods." > > To: > > "Existing EAP methods do not manage the lifetime of exported > EAP keying material; in the interest of method independence, > key management of exported or derived keys SHOULD NOT be > provided within EAP methods." > Okay. The following text on section 3.5 looks good. Vidya > Change Section 3.5 to the following: > > "3.5. Exported and Calculated Key Lifetimes > > All EAP methods generating keys are required to generate > the MSK and > EMSK, and may optionally generate the IV. However, EAP, defined in > [RFC3748], does not itself support the negotiation of lifetimes for > exported keying material such as the MSK, EMSK and IV. > > Several mechanisms exist for managing key lifetimes: > > [a] AAA attributes. AAA protocols such as RADIUS [RFC2865] and > Diameter [RFC4072] support the Session-Timeout attribute. The > Session-Timeout attribute represents the maximum lifetime of the > exported keying material, and all keys calculated from it, on the > authenticator. Since existing backend authentication servers do > not cache keys exported by EAP methods, or keys calculated from > exported keys, the value of the Session-Timeout attribute has no > bearing on the key lifetime within the backend authentication > server. > > On the authenticator, where EAP is used for authentication the > Session-Timeout attribute represents the maximum session > time prior > to re-authentication. As described in [RFC3580] Section > 3.17, when > sent in an Access-Accept along with a Termination-Action value of > RADIUS-Request, the Session-Timeout attribute specifies > the maximum > number of seconds of service provided prior to re-authentication. > > Where EAP is used for pre-authentication, the session > may not start > until some future time, or may never occur. Nevertheless, the > Session-Timeout value represents the maximum time after which > transported EAP keying material, and all keys calculated from it, > will have expired on the authenticator. If the session > subsequently starts, re-authentication will be initiated once the > Session-Time has expired. If the session never started, > or started > and ended, by default keys transported by AAA and all keys > calculated from them will be expired by the > authenticator prior to > the future time indicated by Session-Timeout; this feature is > utilized by [IEEE-802.11i]. Note that in future additional > attributes may be specified to control the lifetime of > cached keys; > these attributes may modify the meaning of the Session-Timeout > attribute in specific circumstances. > > Since the TSK lifetime is often determined by > authenticator resources, > and the backend authentication server has no insight into the > TSK derivation process, by the principle of ciphersuite > independence, > it is not appropriate for the backend authentication > server to manage > any aspect of the TSK derivation process, including the > TSK lifetime. > > [b] Lower layer mechanisms. While AAA attributes can communicate the > maximum exported key lifetime, this only serves to > synchronize the > key lifetime between the backend authentication server and the > authenticator. It is RECOMMENDED that lower layer mechanisms > such as the Secure Association Protocol be used to enable the > lifetime of exported and calculated keys to be negotiated between > the peer and authenticator. > > Where TSKs are established as the result of a Secure Association > Protocol exchange, it is RECOMMENDED that the Secure Association > Protocol include support for TSK re-key. Where the TSK is taken > directly from the MSK, there is no need to manage the > TSK lifetime > as a separate parameter, since the TSK lifetime and MSK lifetime > are identical. > > [c] System defaults. Where the EAP method does not support the > negotiation of the exported key lifetime, and a key lifetime > negotiation mechanism is not provided by the lower > lower, there may > be no way for the peer to learn the exported key > lifetime. In this > case it is RECOMMENDED that the peer assume a default > value of the > exported key lifetime; 8 hours is recommended. Similarly, the > lifetime of calculated keys can also be managed as a system > parameter on the authenticator. > > [d] Method specific negotiation within EAP. While EAP > itself does not > support lifetime negotiation, it would be possible to specify > methods that do. However, systems that rely on such negotiation > for exported keys would only function with these methods. As a > result, it is NOT RECOMMENDED to use this approach as > the sole way > to determine key lifetimes." > > -------------------------------------------------------------- > -------------------------------------------------------------------- > Issue 361: Child key expiry > Submitter name: Vidya Narayanan > Submitter email address: vidyan@qualcomm.com Date Submitted: > May 1, 2006 > Reference: http://lists.frascone.com/pipermail/eap/msg04231.html > Document: KEYING-12 > Comment type: 'T'echnical > Priority: '2' May fix > Section: 3.3 > Rationale/Explanation of issue: > > This section states "When keying material exported by EAP > methods expires, all keying material derived from the > exported keying material expires, including the TSKs." This > seems to indicate that the keys derived from the EMSK will > also be expired when the EMSK expires. It is not yet clear if > this would apply to all kinds of keys derived from the EMSK. > There may be classes of keys derived from the EMSK for which > different lifetime guidelines apply. So, it may be good to > clarify that the EMSK usage documents will specify the > guidelines for EMSK-based child keys. > > Requested change: > > Change > > "When keying material exported by EAP methods expires, all > keying material derived from the exported keying material > expires, including the TSKs." > > to > > "When keying material exported by EAP methods expires, all > keying material derived from the exported keying material > expires, including the TSKs. Note that different lifetime > guidelines may be specified in future specifications for > EMSK-based child keys." > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap > > Arhives: http://lists.frascone.com/pipermail/eap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From ElnoraEddy@earthlink.net Wed Jun 07 10:10:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnyjk-0005Qs-Hx; Wed, 07 Jun 2006 10:10:20 -0400 Received: from 201-40-95-8.ctame704.dsl.brasiltelecom.net.br ([201.40.95.8] helo=koxe.tkheii.verizon.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnyjj-0007Ke-Nb; Wed, 07 Jun 2006 10:10:20 -0400 From: "Elnora" To: Subject: re:[6] ctxe.pk overwhelmingly important letter Date: Wen, 7 Jun 2006 11:10:26 +0300 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: Q6C1BSZfu9LcxCmpiw7Nq9hXnYhu75v0dLZl Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.9 (++) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Efficient market predictions from stocck experts Get Ctxe.Pk First Thing Today, It Is Exploding Now! Price: $0.59 Change: $0.06 (11.76%) within 1 day! Open: 0.53 Volume change: 521% Within 1 day! ! ! and this is just the beginning. Keep your radar on it! Before we start with the profile of CTXE we would like to mention something very important: A Big PR Campaign is moving this week . And it will go all week so it would be best to get in Now. Company Profile Cantex Energy Corporation is an independent, managed risk, oil and gas exploration, development, and production company headquartered in San Antonio, Texas. Recent News Cantex Energy Corp. Receiving Interest From the Industry as It Enters Next Phase of Development Cantex Energy Corp. (CTXE - News) is pleased to report the following on its Big Canyon Prospect in West Texas. Recent company announcements related to the acquisition of over 48,000 acres of a world-class prospect has captured the attention of many oil & gas industry experts and corporations, who have recently inquired into various participation opportunities ranging from sharing science technology to support findings or expertise to drill, operate and manage wells. Trace Maurin, President of Cantex, commented, "Although we are a small independent oil & gas company, we have a very unique 0pp0rtunity in one of the last under-explored world-class potential gas plays with no geopolitical risks and the industry is starting to take notice. As we prepare to prove up the various structures within our prospect later this month, we are increasing our efforts to communicate on our progress to our shareholders and investors. Our intention is to provide investors with a better understanding of the full potential of this prospect as we embark on the next phase of operations." Starting immediately the company will undertake CEO interviews, radio spots (which will be recorded and published on the company website), publication placements, introductions to small cap institutional investors and funds all in an effort to optimize market awareness and keep our shareholder well informed. Conclusion: The Examples Above Show The Awesome, Earning Potential of Little Known Companies That Explode Onto Investor's Radar Screens; Many of You Are Already Familiar with This. Is CTXE Poised and Positioned to Do that For You? Then You May Feel the Time Has Come to Act... And Please Watch this One Trade tomorrow! Go CTXE. Pen-ny sttocks are considered highly speculative and may be unsuitable for all but very aggressive investors. This Profile is not in any way affiliated with the featured company. This report is for entertainment and advertising purposes only and should not be used as investment advice. If you wish to stop future mailings, or if you feel you have been wrongfully placed in our membership, send a blank e mail with No Thanks in the sub ject to Expetced pirce at the end of the week: $1.0! Eliminate stoock risk with professional advice and patterns This sstock is greaatly recomendded by agressive investtors in a sshort term. Don't loose a chance to eaarn. Increase your profits in rocketing sttock environment Hottest booming stockks analyzed and recommended ................................ Practice makes perfect. The bigger they are, the harder they fall In the coldest flint there is hot fire Vex nah gat plaster fuh passion. Cuss when yuh ah guh, nah wheh yuh ah come out. Talk is cheap The proverbs of Solomon the son of David, king of Israel. Death is the great leveller If cow-man pass wild meat whah mek me must pick up am. He who flies high is a short step from a big fall The proof of the pudding is in the eating Never put off til tomorrow what you can do today As safe as houses Saying is one thing; doing another A Deaf Husband and a Blind Wife are Always a Happy Couple. A calm sea does not make a skilled sailor. He is an ill companion that has a good memory If you look like your passport picture, you probably need the trip. Nah everything scholar know he learn from teacher. When yuh buy ah dutty calico yuh gat fuh wear am till it tear. Better a meal of vegetables where there is love than a fattened calf with hatred It will all come out in the wash Life is one long catwalk A volunteer is worth twenty pressed men. Home sweet home Mouth cut trousers nah ah fit Massa. A wise head keeps a still tongue. The higher the monkey climbs, the more he shows his tail People living in glass houses should not pelt stones. For they shall be an ornament of grace unto thy head, and chains about thy neck. A cold bitter Christmas, a fat churchyard. God tempers the wind to the shorn lamb. You cannot sell the cow and sup the milk Every Soldier has the Baton of a Field Marshal in his Knapsack Lean liberty is better than fat slavery as soft as velvet Never speak ill of the dead Nothing is interesting if you are not interested Dishonest money dwindles away, but he who gathers money little by little makes it grow Those who cast the votes decide nothing Those who count the votes decide everything Better to have loved and lost, than never have loved at all Men do not despise a thief, if he steal to satisfy his soul when he is hungry. The cobra will bite you whether you call it cobra or Mr Cobra A false witness that speaketh lies, and he that soweth discord among brethren. Artificial intelligence is no match for natural stupidity An apple a day keeps the doctor away Rain, Rain, go away, come back another day Another day, another dollar From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Jun 07 11:07:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnzdT-000207-P8 for eap-archive@lists.ietf.org; Wed, 07 Jun 2006 11:07:55 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnzdS-0006Yx-5x for eap-archive@lists.ietf.org; Wed, 07 Jun 2006 11:07:55 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C78E84300F9 for ; Wed, 7 Jun 2006 08:07:53 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 7CAE4430054 for ; Wed, 7 Jun 2006 08:07:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 489B7430F77 for ; Wed, 7 Jun 2006 08:07:37 -0700 (PDT) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by hermes.tigertech.net (Postfix) with ESMTP id EC620430F7C for ; Wed, 7 Jun 2006 08:07:34 -0700 (PDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id k57F7Xo6002656; Thu, 8 Jun 2006 00:07:33 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id k57F7YMx004011; Thu, 8 Jun 2006 00:07:34 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id AAA03982; Thu, 8 Jun 2006 00:07:33 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id k57F7Wtj008034; Thu, 8 Jun 2006 00:07:32 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k57F7W1L025150; Thu, 8 Jun 2006 00:07:32 +0900 (JST) Received: from steelhead ([172.30.24.104]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J0H00BWIWODS130@mail.po.toshiba.co.jp>; Thu, 08 Jun 2006 00:07:32 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.62) (envelope-from ) id 1Fnzcv-0004qE-5d; Wed, 07 Jun 2006 08:07:21 -0700 Date: Wed, 07 Jun 2006 11:07:21 -0400 From: Yoshihiro Ohba In-reply-to: <2EBB8025B6D1BA41B567DB32C1D8DB849989FA@NAEX06.na.qualcomm.com> To: "Narayanan, Vidya" Message-id: <20060607150721.GB17242@steelhead> MIME-version: 1.0 Content-disposition: inline References: <2EBB8025B6D1BA41B567DB32C1D8DB849989FA@NAEX06.na.qualcomm.com> User-Agent: Mutt/1.5.11+cvs20060403 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: eap@frascone.com Subject: Re: [eap] Proposed Resolution to Issue 357: Channel Binding Definition X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 On Tue, Jun 06, 2006 at 10:19:07PM -0700, Narayanan, Vidya wrote: > Hi Bernard, > The proposed text by Jari went through some revisions as I recall, based > on some discussions on the list. Here is the latest on that text I > pulled out from one of Jari's email, subsequent to the discussions: > > "I'd be happy to restrict the definition to peer and server agreeing > that they have the same view of the channel properties claimed by the > authenticator. > > (But part of the distinction may also be in the specific implementation > of the "agreement"; what we are looking for is that the values agree, > without specifying who sends the values and who verifies them.)" > > Based on the above, how about the following definition? > > "Channel Binding > > A secure mechanism for ensuring that a chosen set of channel properties > (such as authenticator identifiers and properties) are agreed upon by > the EAP peer and server." After Jari's email, I created a thread "Channel Binding analysis" for further discussion. I still believe three party agreement is essential for Channel Binding. To me the two party agreement mentioned above looks similar to issueing a Kerberos ticket that is never verified by the consumers of the ticket. Yoshihiro Ohba > > Vidya > > > -----Original Message----- > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > Sent: Saturday, June 03, 2006 6:41 PM > > To: eap@frascone.com > > Subject: [eap] Proposed Resolution to Issue 357: Channel > > Binding Definition > > > > The text of Issue 357 is enclosed below. The proposed > > resolution is to accept the definition proposed by Jari Arkko: > > > > "Channel Binding > > > > A secure mechanism for ensuring that a chosen set of channel > > properties (such as endpoint identifiers) are agreed upon by > > the EAP peer, authenticator and server." > > > > -------------------------------------------------------------- > > ---------------------------------- > > Issue 357: Channel Binding Definition > > Submitter name: Vidya Narayanan > > Submitter email address: vidyan@qualcomm.com Date Submitted: > > May 1, 2006 > > Reference: http://lists.frascone.com/pipermail/eap/msg04227.html > > Document: KEYING-12 > > Comment type: 'T'echnical > > Priority: '1' Should fix > > Section: 1.2 > > Rationale/Explanation of issue: > > The document defines channel binding > > as a communication within an EAP method - this seems a bit > > restrictive, given that channel binding information could be > > carried out-of-band as well. The only requirement is that the > > information be integrity protected between the peer and server. > > > > Requested change: > > Change wording to: > > > > "The communication of integrity-protected channel properties > > such as endpoint identifiers which can be compared to values > > communicated via out of band mechanisms (such as via a AAA or > > lower layer protocol)." > > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/eap > > > > Arhives: http://lists.frascone.com/pipermail/eap > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap > > Arhives: http://lists.frascone.com/pipermail/eap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Jun 07 11:37:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo061-0001pt-AP for eap-archive@lists.ietf.org; Wed, 07 Jun 2006 11:37:25 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo05z-0007yY-Rg for eap-archive@lists.ietf.org; Wed, 07 Jun 2006 11:37:25 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 74CE3430100 for ; Wed, 7 Jun 2006 08:37:23 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C87C5430054 for ; Wed, 7 Jun 2006 08:36:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B6CC7430FD5 for ; Wed, 7 Jun 2006 08:36:59 -0700 (PDT) Received: from hotmail.com (bay106-f6.bay106.hotmail.com [65.54.161.16]) by hermes.tigertech.net (Postfix) with ESMTP id CC918430FE5 for ; Wed, 7 Jun 2006 08:36:55 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 7 Jun 2006 08:36:55 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Wed, 07 Jun 2006 15:36:50 GMT X-Originating-IP: [24.16.73.85] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <20060607150721.GB17242@steelhead> From: "Bernard Aboba" To: yohba@tari.toshiba.com, vidyan@qualcomm.com Date: Wed, 07 Jun 2006 08:36:50 -0700 Mime-Version: 1.0 X-OriginalArrivalTime: 07 Jun 2006 15:36:55.0366 (UTC) FILETIME=[34BC1E60:01C68A48] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=1.7 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Cc: eap@frascone.com Subject: Re: [eap] Proposed Resolution to Issue 357: Channel Binding Definition X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f > > Based on the above, how about the following definition? > > > > "Channel Binding > > > > A secure mechanism for ensuring that a chosen set of channel properties > > (such as authenticator identifiers and properties) are agreed upon by > > the EAP peer and server." > >After Jari's email, I created a thread "Channel Binding analysis" for >further discussion. I still believe three party agreement is >essential for Channel Binding. To me the two party agreement >mentioned above looks similar to issueing a Kerberos ticket that is >never verified by the consumers of the ticket. The text mentions authenticator identifiers and properties, which presumably were agreed upon by the authenticator that sent them (unless it's a forgery). However, there are also properties which don't relate to the authenticator itself (such as Calling-Station-Id) but are transmitted by the authenticator (e.g. to the backend server). Are there any cases where a property to be verified by Channel Bindings is *not* transmitted by the authenticator? Would the following work? "A secure mechanism for ensuring that a subset of the parameters transmitted by the authenticator (such as authenticator identifiers and properties) are agreed upon by the EAP peer and server." I'm not sure what the definition of a "channel property" is in this case. One could argue for example that the Calling-Station-Id is not a property of the channel -- but its verification is still considered part of Channel Bindings. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Jun 07 13:19:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo1gr-0003lg-3L for eap-archive@lists.ietf.org; Wed, 07 Jun 2006 13:19:33 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo1gp-0004vj-LC for eap-archive@lists.ietf.org; Wed, 07 Jun 2006 13:19:33 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4C08E430117 for ; Wed, 7 Jun 2006 10:19:31 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 146F2430064 for ; Wed, 7 Jun 2006 10:19:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id DB12F43116F for ; Wed, 7 Jun 2006 10:19:05 -0700 (PDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by hermes.tigertech.net (Postfix) with ESMTP id D739943116D for ; Wed, 7 Jun 2006 10:19:01 -0700 (PDT) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k57HIw0Y021056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 7 Jun 2006 10:19:00 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k57HHVFr023704; Wed, 7 Jun 2006 10:18:54 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 10:18:29 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 7 Jun 2006 10:18:29 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB84998AC0@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Proposed Resolution to Issue 357: Channel Binding Definition Thread-Index: AcaKSIkrSVqoblJoS+qKpkQWf/GeiAADVSHQ From: "Narayanan, Vidya" To: "Bernard Aboba" , X-OriginalArrivalTime: 07 Jun 2006 17:18:29.0960 (UTC) FILETIME=[65655C80:01C68A56] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: eap@frascone.com Subject: Re: [eap] Proposed Resolution to Issue 357: Channel Binding Definition X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 > > > > Based on the above, how about the following definition? > > > > > > "Channel Binding > > > > > > A secure mechanism for ensuring that a chosen set of channel > > > properties (such as authenticator identifiers and properties) are > > > agreed upon by the EAP peer and server." > > > >After Jari's email, I created a thread "Channel Binding > analysis" for > >further discussion. I still believe three party agreement > is essential > >for Channel Binding. To me the two party agreement mentioned above > >looks similar to issueing a Kerberos ticket that is never > verified by > >the consumers of the ticket. > > The text mentions authenticator identifiers and properties, > which presumably were agreed upon by the authenticator that > sent them (unless it's a > forgery). However, there are also properties which don't > relate to the > authenticator itself (such as Calling-Station-Id) but are > transmitted by the > authenticator (e.g. to the backend server). Are there any > cases where a > property to be verified by Channel Bindings is *not* > transmitted by the authenticator? Would the following work? > I cannot presently think of a property that needs verification and is not transmitted by the authenticator. > "A secure mechanism for ensuring that a subset of the > parameters transmitted by the authenticator (such as > authenticator identifiers and properties) are agreed upon by > the EAP peer and server." > This definition works for me. > I'm not sure what the definition of a "channel property" is > in this case. > One could argue for example that the Calling-Station-Id is > not a property of the channel -- but its verification is > still considered part of Channel Bindings. > The channel property definition is fuzzy to me as well. But, perhaps we don't need more detail in the EAP keying document itself. A subsequent channel binding document should get into more detail to clarify things like this. Vidya _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Jun 07 13:41:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo22X-0000mR-WF for eap-archive@lists.ietf.org; Wed, 07 Jun 2006 13:41:58 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo22V-000806-DO for eap-archive@lists.ietf.org; Wed, 07 Jun 2006 13:41:57 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id F1876430136 for ; Wed, 7 Jun 2006 10:41:54 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 7FB68430054 for ; Wed, 7 Jun 2006 10:41:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 647094311D0 for ; Wed, 7 Jun 2006 10:41:40 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by hermes.tigertech.net (Postfix) with ESMTP id 98DCE4311CA for ; Wed, 7 Jun 2006 10:41:37 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 07 Jun 2006 10:41:37 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k57HfbT9013174; Wed, 7 Jun 2006 10:41:37 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k57Hfb9s000998; Wed, 7 Jun 2006 10:41:37 -0700 (PDT) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Jun 2006 10:41:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 7 Jun 2006 10:41:35 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Proposed Resolution to Issue 356: Ciphersuite Independence Thread-Index: AcaINvXcXgk7C81aQJGBq2SV1nDLrACIp/GA From: "Joseph Salowey (jsalowey)" To: "Bernard Aboba" , X-OriginalArrivalTime: 07 Jun 2006 17:41:36.0970 (UTC) FILETIME=[A01E4AA0:01C68A59] Authentication-Results: sj-dkim-2.cisco.com; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [eap] Proposed Resolution to Issue 356: Ciphersuite Independence X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da The text looks OK to me. > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > Sent: Sunday, June 04, 2006 5:27 PM > To: eap@frascone.com > Subject: [eap] Proposed Resolution to Issue 356: Ciphersuite > Independence > > The text of Issue 356 is enclosed below. The proposed > resolution is to > replace the first paragraph of Section 3.7 with the following: > > 3.7. Key Strength > > As noted in Section 2.1, EAP lower layers determine TSKs in > different ways. Where EAP keying material is utilized in > the derivation, encryption or authentication of TSKs, it > is possible for EAP key generation to represent the weakest > link. > > In order to ensure that EAP methods produce keying > material of an appropriate symmetric key strength, > it is RECOMMENDED that EAP methods utilizing public > key cryptography choose a public key that has a > cryptographic strength providing the required level > of attack resistance. This is typically provided by > configuring EAP methods, since there is > no coordination between the lower layer and EAP method > with respect to minimum required symmetric key strength." > > -------------------------------------------------------------- > ---------------------------- > Issue 356: Ciphersuite Independence > Submitter name: Joe Salowey > Submitter email address: jsalowey@cisco.com > Date Submitted: April 30, 2006 > Reference: http://lists.frascone.com/pipermail/eap/msg04223.html > Document: KEYING-12 > Comment type: 'E'ditorial > Priority: '2' May fix > Section: 1.6.4 > Rationale/Explanation of issue: > > Section 3.7 implies that there is a system level coordination between > the strength of the keys exported by the EAP method and the > strength of > keys required by the lower layer. > > This section should reference this and indicate that the > coordination is > done outside of EAP. > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap > > Arhives: http://lists.frascone.com/pipermail/eap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Jun 07 14:01:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo2LE-0003T2-HE for eap-archive@lists.ietf.org; Wed, 07 Jun 2006 14:01:16 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo2LD-0002pd-0h for eap-archive@lists.ietf.org; Wed, 07 Jun 2006 14:01:16 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A28AF4300E9 for ; Wed, 7 Jun 2006 11:01:14 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 4B089430054 for ; Wed, 7 Jun 2006 11:01:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3CEFD398057 for ; Wed, 7 Jun 2006 11:01:00 -0700 (PDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by zoidberg.tigertech.net (Postfix) with ESMTP id E3FD239805D for ; Wed, 7 Jun 2006 11:00:56 -0700 (PDT) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k57I0sXn031813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 7 Jun 2006 11:00:55 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k57I0mrC013384; Wed, 7 Jun 2006 11:00:53 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 11:00:48 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 7 Jun 2006 11:00:43 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB84998AF8@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Proposed Resolution of Issue 361: Child Key Expiry Thread-Index: AcaImVnukKh54vOuTL2jcIa6F+yJOgBwNQdQ From: "Narayanan, Vidya" To: "Bernard Aboba" , X-OriginalArrivalTime: 07 Jun 2006 18:00:48.0184 (UTC) FILETIME=[4E4B9B80:01C68A5C] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: Re: [eap] Proposed Resolution of Issue 361: Child Key Expiry X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 > This is true even where exported EAP keying material is > only used for > entity authentication and is not used for key derivation > (such as in > IKEv2), so that compromise of exported EAP keying material does not > imply compromise of the TSKs or child keys. However, where child > keys are derived from or are wrapped by EAP keying material, > compromise of the MSK/EMSK does imply compromise of the child keys. In the above, are you talking about an EMSK compromise after expiry affecting any keys that may still be in use? If so, I'm wondering how viable that is - basically, the point that I'm not clear on is this - if the EMSK is used to derive any keys that are handed out to other entities, depending on the purpose of the key, the EAP server may really have no control over that lifetime. But, if this is a concern, I'm okay with providing guidance for key expiry in this manner. Vidya > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > Sent: Monday, June 05, 2006 5:12 AM > To: eap@frascone.com > Subject: Re: [eap] Proposed Resolution of Issue 361: Child Key Expiry > > Here is an update to Section 3.3, which better captures the > distinction between maximum lifetime and actual lifetime: > > 3.3. Parent-Child Relationships > > When an EAP re-authentication takes place, new keying material is > derived and exported by the EAP method, which eventually results in > replacement of TSKs, regardless of the way they are derived (see > Section 2.1). While the maximum lifetime of TSKs or child keys can > be less than or equal to that of the MSK/EMSK, it cannot > be greater. > This is true even where exported EAP keying material is > only used for > entity authentication and is not used for key derivation > (such as in > IKEv2), so that compromise of exported EAP keying material does not > imply compromise of the TSKs or child keys. However, where child > keys are derived from or are wrapped by EAP keying material, > compromise of the MSK/EMSK does imply compromise of the child keys. > > Child keys that are used frequently (such as TSKs which > are used for > traffic protection) can expire sooner than the exported EAP keying > material they are dependent on, so that it is advantageous > to support > re-key of child keys prior to EAP re-authentication. Note that > deletion of the MSK/EMSK does not necessarily imply > deletion of TSKs > or child keys. > > Failure to mutually prove possession of exported EAP > keying material > during the Secure Association Protocol exchange need not be grounds > for deletion of the keying material by both parties; rate-limiting > Secure Association Protocol exchanges could be used to prevent a > brute force attack. > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap > > Arhives: http://lists.frascone.com/pipermail/eap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Jun 07 14:20:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo2dg-0005S9-8v for eap-archive@lists.ietf.org; Wed, 07 Jun 2006 14:20:20 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo2de-00049D-Ca for eap-archive@lists.ietf.org; Wed, 07 Jun 2006 14:20:20 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 0A839430115 for ; Wed, 7 Jun 2006 11:20:18 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 2EE54430054 for ; Wed, 7 Jun 2006 11:20:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1D146398051 for ; Wed, 7 Jun 2006 11:20:00 -0700 (PDT) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by zoidberg.tigertech.net (Postfix) with ESMTP id CAE1139803E for ; Wed, 7 Jun 2006 11:19:57 -0700 (PDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id k57IJuLp007256; Thu, 8 Jun 2006 03:19:56 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id k57IJuM7028047; Thu, 8 Jun 2006 03:19:56 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id DAA28012; Thu, 8 Jun 2006 03:19:56 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id k57IJt9b007634; Thu, 8 Jun 2006 03:19:55 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k57IJsLt018833; Thu, 8 Jun 2006 03:19:54 +0900 (JST) Received: from steelhead ([172.30.24.104]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J0I00BJF5L0S180@mail.po.toshiba.co.jp>; Thu, 08 Jun 2006 03:19:54 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.62) (envelope-from ) id 1Fo2d2-0005I0-B9; Wed, 07 Jun 2006 11:19:40 -0700 Date: Wed, 07 Jun 2006 14:19:40 -0400 From: Yoshihiro Ohba In-reply-to: To: Bernard Aboba Message-id: <20060607181940.GB17637@steelhead> MIME-version: 1.0 Content-disposition: inline References: <20060607150721.GB17242@steelhead> User-Agent: Mutt/1.5.11+cvs20060403 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: eap@frascone.com Subject: Re: [eap] Proposed Resolution to Issue 357: Channel Binding Definition X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 On Wed, Jun 07, 2006 at 08:36:50AM -0700, Bernard Aboba wrote: > >> Based on the above, how about the following definition? > >> > >> "Channel Binding > >> > >> A secure mechanism for ensuring that a chosen set of channel properties > >> (such as authenticator identifiers and properties) are agreed upon by > >> the EAP peer and server." > > > >After Jari's email, I created a thread "Channel Binding analysis" for > >further discussion. I still believe three party agreement is > >essential for Channel Binding. To me the two party agreement > >mentioned above looks similar to issueing a Kerberos ticket that is > >never verified by the consumers of the ticket. > > The text mentions authenticator identifiers and properties, which > presumably were agreed upon by the authenticator that sent them (unless > it's a forgery). Then I think this presumption should be explicitly described in the draft. > However, there are also properties which don't relate to > the authenticator itself (such as Calling-Station-Id) but are transmitted > by the authenticator (e.g. to the backend server). Are there any cases > where a property to be verified by Channel Bindings is *not* transmitted by > the authenticator? Would the following work? > > "A secure mechanism for ensuring that a subset of the parameters > transmitted by the authenticator (such as authenticator identifiers and > properties) are agreed upon by the EAP peer and server." Transmitted to whom? I think not all parameters do not need to be transmitted to the server while all parameters need to be transmitted to the peer. In fact, if the server has the pre-established knowledge about the parameters, the only information that needs to be sent from authenticator to the server is authenticator identity which can be used as the primary database look-up key to find out other parameters associated with the authenticator identity. Also I don't understand why peer's lower layer parameter such as Calling-Station-Id needs to be agreed by peer and server. What is the actual threat without agreement? Yoshihiro Ohba > > I'm not sure what the definition of a "channel property" is in this case. > One could argue for example that the Calling-Station-Id is not a property > of the channel -- but its verification is still considered part of Channel > Bindings. > > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Jun 07 14:40:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo2wx-0008ER-Kk for eap-archive@lists.ietf.org; Wed, 07 Jun 2006 14:40:15 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo2wv-0007AB-39 for eap-archive@lists.ietf.org; Wed, 07 Jun 2006 14:40:15 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id BA4CF430160 for ; Wed, 7 Jun 2006 11:40:12 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id DAB9C430063 for ; Wed, 7 Jun 2006 11:39:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C5D0F43127F for ; Wed, 7 Jun 2006 11:39:52 -0700 (PDT) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by hermes.tigertech.net (Postfix) with ESMTP id CE330431299 for ; Wed, 7 Jun 2006 11:39:49 -0700 (PDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id k57Idmcb010622; Thu, 8 Jun 2006 03:39:48 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id k57IdnrQ021103; Thu, 8 Jun 2006 03:39:49 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id DAA21074; Thu, 8 Jun 2006 03:39:49 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id k57Idm94016664; Thu, 8 Jun 2006 03:39:48 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k57IdlAZ028731; Thu, 8 Jun 2006 03:39:47 +0900 (JST) Received: from steelhead ([172.30.24.104]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J0I00BYT6I5S180@mail.po.toshiba.co.jp>; Thu, 08 Jun 2006 03:39:47 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.62) (envelope-from ) id 1Fo2wI-0005Lf-8H; Wed, 07 Jun 2006 11:39:34 -0700 Date: Wed, 07 Jun 2006 14:39:34 -0400 From: Yoshihiro Ohba In-reply-to: <2EBB8025B6D1BA41B567DB32C1D8DB84998AF8@NAEX06.na.qualcomm.com> To: "Narayanan, Vidya" Message-id: <20060607183934.GC17637@steelhead> MIME-version: 1.0 Content-disposition: inline References: <2EBB8025B6D1BA41B567DB32C1D8DB84998AF8@NAEX06.na.qualcomm.com> User-Agent: Mutt/1.5.11+cvs20060403 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: eap@frascone.com Subject: Re: [eap] Proposed Resolution of Issue 361: Child Key Expiry X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 On Wed, Jun 07, 2006 at 11:00:43AM -0700, Narayanan, Vidya wrote: > > > This is true even where exported EAP keying material is > > only used for > > entity authentication and is not used for key derivation > > (such as in > > IKEv2), so that compromise of exported EAP keying material does not > > imply compromise of the TSKs or child keys. However, where child > > keys are derived from or are wrapped by EAP keying material, > > compromise of the MSK/EMSK does imply compromise of the child keys. > > > In the above, are you talking about an EMSK compromise after expiry > affecting any keys that may still be in use? If so, I'm wondering how > viable that is - basically, the point that I'm not clear on is this - if > the EMSK is used to derive any keys that are handed out to other > entities, depending on the purpose of the key, the EAP server may really > have no control over that lifetime. If the EAP server has no control over the lifetime when EMSK is used for a specific purpose, then it would be the time to think about possibility to use a mechanism other than EAP for that purpose. Yoshihiro Ohba > > But, if this is a concern, I'm okay with providing guidance for key > expiry in this manner. > > Vidya > > > > -----Original Message----- > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > Sent: Monday, June 05, 2006 5:12 AM > > To: eap@frascone.com > > Subject: Re: [eap] Proposed Resolution of Issue 361: Child Key Expiry > > > > Here is an update to Section 3.3, which better captures the > > distinction between maximum lifetime and actual lifetime: > > > > 3.3. Parent-Child Relationships > > > > When an EAP re-authentication takes place, new keying material is > > derived and exported by the EAP method, which eventually results in > > replacement of TSKs, regardless of the way they are derived (see > > Section 2.1). While the maximum lifetime of TSKs or child keys can > > be less than or equal to that of the MSK/EMSK, it cannot > > be greater. > > This is true even where exported EAP keying material is > > only used for > > entity authentication and is not used for key derivation > > (such as in > > IKEv2), so that compromise of exported EAP keying material does not > > imply compromise of the TSKs or child keys. However, where child > > keys are derived from or are wrapped by EAP keying material, > > compromise of the MSK/EMSK does imply compromise of the child keys. > > > > Child keys that are used frequently (such as TSKs which > > are used for > > traffic protection) can expire sooner than the exported EAP keying > > material they are dependent on, so that it is advantageous > > to support > > re-key of child keys prior to EAP re-authentication. Note that > > deletion of the MSK/EMSK does not necessarily imply > > deletion of TSKs > > or child keys. > > > > Failure to mutually prove possession of exported EAP > > keying material > > during the Secure Association Protocol exchange need not be grounds > > for deletion of the keying material by both parties; rate-limiting > > Secure Association Protocol exchanges could be used to prevent a > > brute force attack. > > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/eap > > > > Arhives: http://lists.frascone.com/pipermail/eap > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap > > Arhives: http://lists.frascone.com/pipermail/eap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From Milagros.Mercado@lycos.com Wed Jun 07 15:34:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo3nO-0000NK-1O for eap-archive@ietf.org; Wed, 07 Jun 2006 15:34:26 -0400 Received: from 145samana89.codetel.net.do ([200.88.89.145] helo=640i0a.0h2tsg.ameritech.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo3nN-00059s-4X; Wed, 07 Jun 2006 15:34:26 -0400 From: "Milagros Tracy" To: Subject: the information is in the letter ctxe.pk an absolute must see Date: Thu, 8 Jun 2006 15:33:39 +0600 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: L5GP6y826aQYd5zxbIlpypxKoSOKiqHW4o0A Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 You can make more money with insider information and sttock tips Get Ctxe.Pk First Thing Today, It Is Exploding Now! Price: $0.59 Change: $0.06 (11.76%) within 1 day! Open: 0.53 Volume change: 521% Within 1 day! ! ! and this is just the beginning. Keep your radar on it! Before we start with the profile of CTXE we would like to mention something very important: A Big PR Campaign is moving this week . And it will go all week so it would be best to get in Now. Company Profile Cantex Energy Corporation is an independent, managed risk, oil and gas exploration, development, and production company headquartered in San Antonio, Texas. Recent News Cantex Energy Corp. Receiving Interest From the Industry as It Enters Next Phase of Development Cantex Energy Corp. (CTXE - News) is pleased to report the following on its Big Canyon Prospect in West Texas. Recent company announcements related to the acquisition of over 48,000 acres of a world-class prospect has captured the attention of many oil & gas industry experts and corporations, who have recently inquired into various participation opportunities ranging from sharing science technology to support findings or expertise to drill, operate and manage wells. Trace Maurin, President of Cantex, commented, "Although we are a small independent oil & gas company, we have a very unique 0pp0rtunity in one of the last under-explored world-class potential gas plays with no geopolitical risks and the industry is starting to take notice. As we prepare to prove up the various structures within our prospect later this month, we are increasing our efforts to communicate on our progress to our shareholders and investors. Our intention is to provide investors with a better understanding of the full potential of this prospect as we embark on the next phase of operations." Starting immediately the company will undertake CEO interviews, radio spots (which will be recorded and published on the company website), publication placements, introductions to small cap institutional investors and funds all in an effort to optimize market awareness and keep our shareholder well informed. Conclusion: The Examples Above Show The Awesome, Earning Potential of Little Known Companies That Explode Onto Investor's Radar Screens; Many of You Are Already Familiar with This. Is CTXE Poised and Positioned to Do that For You? Then You May Feel the Time Has Come to Act... And Please Watch this One Trade tomorrow! Go CTXE. Pen-ny sttocks are considered highly speculative and may be unsuitable for all but very aggressive investors. This Profile is not in any way affiliated with the featured company. This report is for entertainment and advertising purposes only and should not be used as investment advice. If you wish to stop future mailings, or if you feel you have been wrongfully placed in our membership, send a blank e mail with No Thanks in the sub ject to Expecetd prcie at the end of the week: $1.0! Save time and money by using professional sttock advice This stocck is greatlyy recomendded by agressive innvestors in a shortt term. Don't loose a chance to eaarn. sttocks that perform like rockets explained Market trends and sstock analysis, ratings and invsetment information ...................................... The pen is mightier than the sword. A bad penny always turns up. Virtue is its own reward Football is a game of two halves A good mate is the road map for the spaghetti junction of life. Give a clown a finger and he will take your hand Revenge is a dish best served cold. Never go to bed on an argument All things are possible with god A bird in the hand is worth two in the bush. He who has once burnt his mouth always blows his soup You cannot get to the top by sitting on your bottom An idle mind is.. the best way to relax. The Moon does not heed the barking of dogs Good and quickly seldom meet Do right and fear no man In a battle between elephants, the ants get squashed Fools rush in where angels fear to tread Good people are scarce The early bird catches the worm, but it is the early worm that gets caught. In the coldest flint there is hot fire Age before beauty A false witness that speaketh lies, and he that soweth discord among brethren. Dream of a funeral and you hear of a marriage Christmas comes but once a year, but Hallmark makes sure it lasts three months A squirrel is just a rat with good PR. Merry Nights Make Sorry Days Still waters run deep Like a roaring lion or a charging bear is a wicked man ruling over a helpless people Seven years nah too much fuh wash speck off ah bird neck. The rotten apple injures its neighbours One good turn deserves another If you get it overnight, you can lose it just as quick Even a clock that does not work is right twice a day Desperate Diseases Call for Desperate Remedies Seeing is believing You can't teach an old dog new tricks. Love conquers all All good things come to those who wait. A gossips mouth is the devils postbag. One for sorrow, two for joy, three for a girl, four for a boy, five for silver, six for gold seven for a secret not to be sold Eight for heaven nine for hell and ten for the devils own cell From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Jun 07 15:50:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo42t-0002Tc-Bo for eap-archive@lists.ietf.org; Wed, 07 Jun 2006 15:50:27 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo42q-0007dQ-Ts for eap-archive@lists.ietf.org; Wed, 07 Jun 2006 15:50:27 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 0200E430064 for ; Wed, 7 Jun 2006 12:50:24 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id C7451430063 for ; Wed, 7 Jun 2006 12:50:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id B445C39802F for ; Wed, 7 Jun 2006 12:50:10 -0700 (PDT) Received: from hotmail.com (bay106-f3.bay106.hotmail.com [65.54.161.13]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1B39C398057 for ; Wed, 7 Jun 2006 12:50:08 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 7 Jun 2006 12:50:07 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Wed, 07 Jun 2006 19:50:03 GMT X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <2EBB8025B6D1BA41B567DB32C1D8DB84998AF8@NAEX06.na.qualcomm.com> From: "Bernard Aboba" To: vidyan@qualcomm.com, eap@frascone.com Date: Wed, 07 Jun 2006 12:50:03 -0700 Mime-Version: 1.0 X-OriginalArrivalTime: 07 Jun 2006 19:50:07.0383 (UTC) FILETIME=[93E1F270:01C68A6B] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.748 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Subject: Re: [eap] Proposed Resolution of Issue 361: Child Key Expiry X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 >In the above, are you talking about an EMSK compromise after expiry >affecting any keys that may still be in use? If the EMSK expires and the session is still in progress, presumably the result is an EAP re-authentication which results in new child keys. >If so, I'm wondering how >viable that is - basically, the point that I'm not clear on is this - if >the EMSK is used to derive any keys that are handed out to other >entities, depending on the purpose of the key, the EAP server may really >have no control over that lifetime. It can provide a maximum lifetime (Session-Timeout) to the authenticator, requesting EAP re-authentication to occur when the maximum lifetime expires. The distinction we're making here is between maximum lifetime (controlled by Session-Timeout) and deletion. If the EMSK is deleted on the peer or server, this doesn't cause child keys to be deleted. However, expiry of the maximum lifetime does result in new child keys. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Jun 07 16:29:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo49c-0005uJ-0H for eap-archive@lists.ietf.org; Wed, 07 Jun 2006 15:57:24 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo49a-0001w0-E4 for eap-archive@lists.ietf.org; Wed, 07 Jun 2006 15:57:23 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 17D32430137 for ; Wed, 7 Jun 2006 12:57:22 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 503044300E9 for ; Wed, 7 Jun 2006 12:57:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3E257398061 for ; Wed, 7 Jun 2006 12:57:01 -0700 (PDT) Received: from hotmail.com (bay106-f17.bay106.hotmail.com [65.54.161.27]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6EE8339805E for ; Wed, 7 Jun 2006 12:56:59 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 7 Jun 2006 12:56:58 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Wed, 07 Jun 2006 19:56:53 GMT X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <20060607181940.GB17637@steelhead> From: "Bernard Aboba" To: yohba@tari.toshiba.com Date: Wed, 07 Jun 2006 12:56:53 -0700 Mime-Version: 1.0 X-OriginalArrivalTime: 07 Jun 2006 19:56:58.0920 (UTC) FILETIME=[892D8280:01C68A6C] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.748 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Cc: eap@frascone.com Subject: Re: [eap] Proposed Resolution to Issue 357: Channel Binding Definition X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa > > The text mentions authenticator identifiers and properties, which > > presumably were agreed upon by the authenticator that sent them (unless > > it's a forgery). > >Then I think this presumption should be explicitly described in the >draft. Do you want to suggest text? > > "A secure mechanism for ensuring that a subset of the parameters > > transmitted by the authenticator (such as authenticator identifiers and > > properties) are agreed upon by the EAP peer and server." > >Transmitted to whom? I think not all parameters do not need to be >transmitted to the server while all parameters need to be transmitted >to the peer. I was leaving it open. Some things might be transmitted to the peer but not the server, or vice versa. For example, the authenticator may send Calling-Station-Id to the AAA server, but it doesn't send it to the peer (the peer includes that in the source address). >In fact, if the server has the pre-established knowledge >about the parameters, the only information that needs to be sent from >authenticator to the server is authenticator identity which can be >used as the primary database look-up key to find out other parameters >associated with the authenticator identity. How can the peer use channel binding parameters which it never received? So the authenticator needed to send it to the peer at least, no? >Also I don't understand why peer's lower layer parameter such as >Calling-Station-Id needs to be agreed by peer and server. What is the >actual threat without agreement? The threat is that the authenticator could lie about the Calling-Station-Id. The peer could then find out from the server that it got different information. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From tkopf@smithfieldtrust.com Wed Jun 07 16:30:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo4fE-00023g-A2 for eap-archive@ietf.org; Wed, 07 Jun 2006 16:30:04 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo4Ht-0003mi-PX for eap-archive@ietf.org; Wed, 07 Jun 2006 16:05:57 -0400 Received: from [60.49.250.1] (helo=tm.net.my) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fo47F-00054D-Bt for eap-archive@ietf.org; Wed, 07 Jun 2006 15:55:00 -0400 Message-ID: <662161c806048278R91G6LV962M69EKVLGSQN1HG01NR@mail.smithfieldtrust.com> Date: Wed, 7 Jun 2006 19:54:58 +0480 From: "Emory Witherspoon" To: eap-archive@ietf.org Subject: The Bull Market That Never Ends MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam: Not detected X-Spam-Score: -1.3 (-) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 H o t _S t 0 c k for attention. We found company ready to EXPLODE!! Put CGDC on your radar's now. This st0ck shows a significant up in stock price and sometimes in days, not months or years. Watch CGDC like a hawk tomorrow!! The alert is on!! CHINA GOLD CORP Symbol: CGDC Current Price: 0.38 A Company engaged in gold and minerals exploration and development of gold and mineral properties in China. Why consider CHINA GOLD CORP (CGDC)? Seee n0wadays what happened. • Rising gold prices are further accelerating this gold rush - The price of gold has up 250% over the past five years, and this is still only a quarter of when the price peaked 25 years ago. (Adjusted for inflation.) • HUGE gold discovery in southwestern China - Resources have already been estimated by analysts at 14 million ounces...and the number keeps climbing. • China is the world’s last great under-explored land-mass - Locked away in a Marxist time-warp with limited exploration technology, China’s rich virgin gold fields have been overlooked and ignored until recently. • China is already the world’s 4th largest producer of gold — and will soon be the world’s #1 producer AND #1 consumer. The country is going gold-crazy! • Foreign gold companies are now welcome - and the laws have been changed to provide full legal protection. You can see China’s developing gold boom is building momentum. Rare 0pp0rtunity for early investors!! CURRENT NEWS: China Gold Corp. Announces Shareholder Update China Gold Corp. (CGDC - News) is a Nevada Corporation, engaged in gold and minerals exploration and development of gold and mineral properties in China. The company is pleased to announce has entered into negotiations with Zhong Cui Investments LTD. for the acquisition of Gold Mine property in the rural mountainous Guang Ning District near Zhao Qing City, Guangdong Province of China. China Gold Corp. is currently evaluating the Gold Mine property preliminary geological information and the property. If the company’s due diligence produces favorable results, management is expected to sign the letter of intent with Zhong Cui Investments LTD. in the next thirty (30) days. The Letter of Intent requires both parties to draft a definitive agreement and terms of any subsequent joint venture. Property description and all additional information will be available upon finalization of the agreement. The company will be made further announcements in this regard in coming weeks. ABOUT THE COMPANY China Gold Corp. is a Nevada Corporation, engaged in gold and minerals exploration and development of gold and mineral properties in China. China Gold Corp. is dedicated to delivering growth to the shareholder by employing a disciplined business methodology through acquisitions and joint ventures. The Company seeks to acquire properties with the following development criteria: largely unexplored but highly prospective geological regions, ability to generate near-term revenue and cash flow, tremendous geological potential for world-class economic deposits. From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Jun 07 16:34:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo4jI-0003Br-9A for eap-archive@lists.ietf.org; Wed, 07 Jun 2006 16:34:16 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo4jG-0006L3-QX for eap-archive@lists.ietf.org; Wed, 07 Jun 2006 16:34:16 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 7AD7C430122 for ; Wed, 7 Jun 2006 13:34:14 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 32088430063 for ; Wed, 7 Jun 2006 13:34:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 17D1039802F for ; Wed, 7 Jun 2006 13:34:01 -0700 (PDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by zoidberg.tigertech.net (Postfix) with ESMTP id 123BF398057 for ; Wed, 7 Jun 2006 13:33:57 -0700 (PDT) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k57KXuQO016298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 7 Jun 2006 13:33:57 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k57KXd8p021296; Wed, 7 Jun 2006 13:33:55 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 13:32:50 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 7 Jun 2006 13:32:50 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB84998B5A@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Proposed Resolution of Issue 361: Child Key Expiry Thread-Index: AcaKYcziN6JBvdtbSryiXpADFrh4dgADnU8A From: "Narayanan, Vidya" To: "Yoshihiro Ohba" X-OriginalArrivalTime: 07 Jun 2006 20:32:50.0729 (UTC) FILETIME=[8BC18190:01C68A71] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com Subject: Re: [eap] Proposed Resolution of Issue 361: Child Key Expiry X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 > > If the EAP server has no control over the lifetime when EMSK > is used for a specific purpose, then it would be the time to > think about possibility to use a mechanism other than EAP for > that purpose. > The EAP server never actually has control over the lifetime of a key that it has handed out to other parties. Even with the MSKs, it is only a guidance. The authenticator may enforce a lifetime based on its policy. So, the question really is about whether the guidance provided should be the same regardless of the purpose of the key. Vidya _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Jun 07 16:35:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo4ki-0003lw-Le for eap-archive@lists.ietf.org; Wed, 07 Jun 2006 16:35:44 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo4kh-0007Iv-7x for eap-archive@lists.ietf.org; Wed, 07 Jun 2006 16:35:44 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id CF8AF4300D5 for ; Wed, 7 Jun 2006 13:35:42 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 1D124430063 for ; Wed, 7 Jun 2006 13:35:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 11C4339803E for ; Wed, 7 Jun 2006 13:35:30 -0700 (PDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6D7FA398049 for ; Wed, 7 Jun 2006 13:35:27 -0700 (PDT) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k57KZQEt016419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 7 Jun 2006 13:35:26 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k57KZGsi024146; Wed, 7 Jun 2006 13:35:25 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 13:34:26 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 7 Jun 2006 13:34:26 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB84998B5C@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Proposed Resolution of Issue 361: Child Key Expiry Thread-Index: AcaKa55ImR3T1AZfQ9+9u5HdBrdFfgABgagA From: "Narayanan, Vidya" To: "Bernard Aboba" , X-OriginalArrivalTime: 07 Jun 2006 20:34:26.0993 (UTC) FILETIME=[C5223A10:01C68A71] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: Re: [eap] Proposed Resolution of Issue 361: Child Key Expiry X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 > > >In the above, are you talking about an EMSK compromise after expiry > >affecting any keys that may still be in use? > > If the EMSK expires and the session is still in progress, > presumably the result is an EAP re-authentication which > results in new child keys. > > >If so, I'm wondering how > >viable that is - basically, the point that I'm not clear on > is this - > >if the EMSK is used to derive any keys that are handed out to other > >entities, depending on the purpose of the key, the EAP server may > >really have no control over that lifetime. > > It can provide a maximum lifetime (Session-Timeout) to the > authenticator, requesting EAP re-authentication to occur when > the maximum lifetime expires. > > The distinction we're making here is between maximum lifetime > (controlled by > Session-Timeout) and deletion. If the EMSK is deleted on the > peer or server, this doesn't cause child keys to be deleted. > However, expiry of the maximum lifetime does result in new child keys. > Ok. The revised text for section 3.3 then looks good. Vidya _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From tkyle@yaronproperties.com Wed Jun 07 17:05:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo5Dj-00083R-E0 for eap-archive@ietf.org; Wed, 07 Jun 2006 17:05:43 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo4Ht-0003mi-3n for eap-archive@ietf.org; Wed, 07 Jun 2006 16:05:57 -0400 Received: from gprs2.vodafone.cz ([217.77.165.36]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fo47j-00056P-EK for eap-archive@ietf.org; Wed, 07 Jun 2006 15:55:42 -0400 Date: Wed, 7 Jun 2006 19:55:32 -0060 From: "Booker Nielsen" X-Mailer: The Bat! (Home)7.41.2 Reply-To: "Booker Nielsen" X-Priority: 3 (Normal) Message-ID: <91816533.20060607195532@yaronproperties.com> To: eap-archive@ietf.org Subject: Microcaps Can Equal Mega Gains MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 1.7 (+) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 H o t _S t 0 c k for attention. We found company ready to EXPLODE!! Put CGDC on your radar's now. This st0ck shows a significant up in stock price and sometimes in days, not months or years. Watch CGDC like a hawk tomorrow!! The alert is on!! CHINA GOLD CORP Symbol: CGDC Current Price: 0.38 A Company engaged in gold and minerals exploration and development of gold and mineral properties in China. Why consider CHINA GOLD CORP (CGDC)? Seee n0wadays what happened. • Rising gold prices are further accelerating this gold rush - The price of gold has up 250% over the past five years, and this is still only a quarter of when the price peaked 25 years ago. (Adjusted for inflation.) • HUGE gold discovery in southwestern China - Resources have already been estimated by analysts at 14 million ounces...and the number keeps climbing. • China is the world’s last great under-explored land-mass - Locked away in a Marxist time-warp with limited exploration technology, China’s rich virgin gold fields have been overlooked and ignored until recently. • China is already the world’s 4th largest producer of gold — and will soon be the world’s #1 producer AND #1 consumer. The country is going gold-crazy! • Foreign gold companies are now welcome - and the laws have been changed to provide full legal protection. You can see China’s developing gold boom is building momentum. Rare 0pp0rtunity for early investors!! CURRENT NEWS: China Gold Corp. Announces Shareholder Update China Gold Corp. (CGDC - News) is a Nevada Corporation, engaged in gold and minerals exploration and development of gold and mineral properties in China. The company is pleased to announce has entered into negotiations with Zhong Cui Investments LTD. for the acquisition of Gold Mine property in the rural mountainous Guang Ning District near Zhao Qing City, Guangdong Province of China. China Gold Corp. is currently evaluating the Gold Mine property preliminary geological information and the property. If the company’s due diligence produces favorable results, management is expected to sign the letter of intent with Zhong Cui Investments LTD. in the next thirty (30) days. The Letter of Intent requires both parties to draft a definitive agreement and terms of any subsequent joint venture. Property description and all additional information will be available upon finalization of the agreement. The company will be made further announcements in this regard in coming weeks. ABOUT THE COMPANY China Gold Corp. is a Nevada Corporation, engaged in gold and minerals exploration and development of gold and mineral properties in China. China Gold Corp. is dedicated to delivering growth to the shareholder by employing a disciplined business methodology through acquisitions and joint ventures. The Company seeks to acquire properties with the following development criteria: largely unexplored but highly prospective geological regions, ability to generate near-term revenue and cash flow, tremendous geological potential for world-class economic deposits. From winkler.tauschfenster@ithacaclothing.com Wed Jun 07 19:08:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo78g-0004BP-IK for eap-archive@ietf.org; Wed, 07 Jun 2006 19:08:38 -0400 Received: from [196.218.75.134] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fo78H-0002MB-6G for eap-archive@ietf.org; Wed, 07 Jun 2006 19:08:38 -0400 Message-ID: <000001c68a86$e3e00d00$0100007f@localhost> From: "Nathan Gonzalez" To: Subject: cheap oem soft shipping //orldwide Date: Wed, 07 Jun 2006 14:07:32 -0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C68A86.E3E00D00" 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-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C68A86.E3E00D00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Special Offer Adobe Video Collection Adobe Premiere 1.5 Professional Adobe After Effects 6.5 Professional Adobe Audition 1.5 Adobe Encore DVD 1.5 $149.95 More Info >> Microsoft 2 in 1 MS Windows XP Pro MS Office 2003 Pro $99.95 More Info >> Microsoft + Adobe 3 in 1 MS Windows XP Pro MS Office 2003 Pro Adobe Acrobat 7.0 Professional $149.95 More Info >> Bestsellers Microsoft Office Professional Edition 2003 Rating: 6 reviews Retail price: $550.00 You save: $480.05 (87%) Our price: $69.95 [Add to cart] Microsoft Windows XP Professional Rating: 8 reviews Retail price: $200.00 You save: $150.05 (75%) Our price: $49.95 [Add to cart] Adobe Photoshop CS2 V 9.0 Rating: 3 reviews Retail price: $599.00 You save: $529.05 (88%) Our price: $69.95 [Add to cart] ------=_NextPart_000_0001_01C68A86.E3E00D00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable DS
Special Offer
Adobe Video Collection
  • Adobe Premiere 1.5 Professional
  • Adobe After Effects 6.5 Professional
  • Adobe Audition 1.5
  • Adobe Encore DVD 1.5
$149.95    
More Info >>
Microsoft 2 in 1
  • MS Windows XP Pro
  • MS Office 2003 Pro




$99.95    
More Info >>
Microsoft + Adobe 3 in 1
  • MS Windows XP Pro
  • MS Office 2003 Pro
  • Adobe Acrobat 7.0 Professional


$149.95    
More Info >>
Bestsellers
3D"" Microsoft Office Professional Edition 2003
Rating: 6 reviews
Retail price: $550.00
You save: $480.05 (87%)
Our price: $69.95		  

Add to cart

3D"" Microsoft Windows XP Professional
Rating: 8 reviews
Retail price: $200.00
You save: $150.05 (75%)
Our price: $49.95		  

Add to cart

3D"" Adobe Photoshop CS2 V 9.0
Rating: 3 reviews
Retail price: $599.00
You save: $529.05 (88%)
Our price: $69.95		  

Add to cart

------=_NextPart_000_0001_01C68A86.E3E00D00-- From maya317@so-net.ne.jp Thu Jun 08 06:23:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoHfL-0005vL-GF for EAP-ARCHIVE@MEGATRON.IETF.ORG; Thu, 08 Jun 2006 06:23:03 -0400 Received: from [221.209.201.112] (helo=allabout.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoHfJ-0000Cl-Is for EAP-ARCHIVE@MEGATRON.IETF.ORG; Thu, 08 Jun 2006 06:23:03 -0400 Received: from yjaqbx5 (unknown [153.50.210.68]) by smtp42 (Coremail) with SMTP id jb22mtAWjdoknpEl.1 for ; Mon, 26 May 2003 20:36:56 +0800 (CST) X-Originating-IP: [153.50.210.68] Subject: =?iso-2022-jp?B?GyRCPiE8aiRLJDQkYSRzJEokNSQkISIbKEI=?= From: =?shift-jis?B?jZWJpA==?= To: X-Mailer: Microsoft Outlook Express 6.00.2800.1478 MIME-Version: 1.0 Content-Type: text/plain; Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.7 (+++) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed GyRCNS5KfSROJSIlSSVsJTkhIiUiJUklbCU5JHJHZCRDJEYkJCRrNkg8VCQrJGlHYyQkJF4kNyQ/ ISMkSSQmJDckRiRiQ0tALSRIQk4kTjRYNzgkSyRKJGokPyQvJEYhIiReJEA3UDgzJDckPzt2TDUk JCRzJEckOSEiJDMkQSRpJEcbKEJodHRwOi8vdnFsaC5jb20vP215MTYbJEI7ZCROPEw/PzNORyck NyRGISIkYiQ3GyhCT0sbJEIkRyQ3JD8kaSEiO2QkTiUiJUklbCU5JEslYSE8JWskLyRAJDUkJCEj JV4lZCRDJEYkJCQkJF4kOSEjGyhCDQoNCg0KDQobJEIlYSE8JWs8dT8uNXFIXRsoQg0KSSBkb24n dCB2ZWNlaXZlIHlvdXJtYWlsDQpzX2Zvcl9zd2VldGJhYnlAeWFob28uY28udWsNCg== From eap-bounces+eap-archive=lists.ietf.org@frascone.com Thu Jun 08 10:45:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoLlU-0000qQ-I6 for eap-archive@lists.ietf.org; Thu, 08 Jun 2006 10:45:40 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoLlS-0002Pu-Ma for eap-archive@lists.ietf.org; Thu, 08 Jun 2006 10:45:40 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id F21F143012D for ; Thu, 8 Jun 2006 07:45:37 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 6903543006C for ; Thu, 8 Jun 2006 07:45:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4452B144802E for ; Thu, 8 Jun 2006 07:45:23 -0700 (PDT) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by hermes.tigertech.net (Postfix) with ESMTP id 6973C1448029 for ; Thu, 8 Jun 2006 07:45:19 -0700 (PDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id k58EjI3X014031; Thu, 8 Jun 2006 23:45:18 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id k58EjJlx019847; Thu, 8 Jun 2006 23:45:19 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id ZAA19815; Thu, 8 Jun 2006 23:45:19 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id k58EjHcv021685; Thu, 8 Jun 2006 23:45:17 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k58EjHuf009964; Thu, 8 Jun 2006 23:45:17 +0900 (JST) Received: from steelhead ([172.30.24.104]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J0J00HGSQBA47M0@mail.po.toshiba.co.jp>; Thu, 08 Jun 2006 23:45:17 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.62) (envelope-from ) id 1FoLkk-0008Ne-Qb; Thu, 08 Jun 2006 07:44:54 -0700 Date: Thu, 08 Jun 2006 10:44:54 -0400 From: Yoshihiro Ohba In-reply-to: To: Bernard Aboba Message-id: <20060608144454.GA31521@steelhead> MIME-version: 1.0 Content-disposition: inline References: <20060607181940.GB17637@steelhead> User-Agent: Mutt/1.5.11+cvs20060403 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: eap@frascone.com Subject: Re: [eap] Proposed Resolution to Issue 357: Channel Binding Definition X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da On Wed, Jun 07, 2006 at 12:56:53PM -0700, Bernard Aboba wrote: > > >> The text mentions authenticator identifiers and properties, which > >> presumably were agreed upon by the authenticator that sent them (unless > >> it's a forgery). > > > >Then I think this presumption should be explicitly described in the > >draft. > > Do you want to suggest text? How about: " It is expected that the parameters are also agreed upon by the peer and authenticator via the lower layer if the authenticator is the valid entity that advertised the parameters. " > > >> "A secure mechanism for ensuring that a subset of the parameters > >> transmitted by the authenticator (such as authenticator identifiers and > >> properties) are agreed upon by the EAP peer and server." > > > >Transmitted to whom? I think not all parameters do not need to be > >transmitted to the server while all parameters need to be transmitted > >to the peer. > > I was leaving it open. Some things might be transmitted to the peer but > not the server, or vice versa. For example, the authenticator may send > Calling-Station-Id to the AAA server, but it doesn't send it to the peer > (the peer includes that in the source address). > > >In fact, if the server has the pre-established knowledge > >about the parameters, the only information that needs to be sent from > >authenticator to the server is authenticator identity which can be > >used as the primary database look-up key to find out other parameters > >associated with the authenticator identity. > > How can the peer use channel binding parameters which it never received? > So the authenticator needed to send it to the peer at least, no? This was discussed before. My comment was that if the authenticator needs to advertise the channel binding parameters. > > >Also I don't understand why peer's lower layer parameter such as > >Calling-Station-Id needs to be agreed by peer and server. What is the > >actual threat without agreement? > > The threat is that the authenticator could lie about the > Calling-Station-Id. The peer could then find out from the server that it > got different information. > The peer may be lying in this case, but the server will never know whether authenticator or peer is lying unless the server is preconfigured with the peer's Calling-Station-Id. Yoshihiro Ohba _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Thu Jun 08 13:07:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoNyL-0001E4-DR for eap-archive@lists.ietf.org; Thu, 08 Jun 2006 13:07:05 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoNyK-00086n-Lo for eap-archive@lists.ietf.org; Thu, 08 Jun 2006 13:07:05 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4C39043012D for ; Thu, 8 Jun 2006 10:07:04 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 9E2F643006C for ; Thu, 8 Jun 2006 10:06:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8182143076D for ; Thu, 8 Jun 2006 10:06:46 -0700 (PDT) Received: from hotmail.com (bay106-f25.bay106.hotmail.com [65.54.161.35]) by hermes.tigertech.net (Postfix) with ESMTP id 72CAA430763 for ; Thu, 8 Jun 2006 10:06:43 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 8 Jun 2006 10:06:43 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Thu, 08 Jun 2006 17:06:41 GMT X-Originating-IP: [24.16.73.85] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Thu, 08 Jun 2006 10:06:41 -0700 Mime-Version: 1.0 X-OriginalArrivalTime: 08 Jun 2006 17:06:43.0015 (UTC) FILETIME=[EA6FDD70:01C68B1D] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=1.7 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Subject: [eap] Issue 369: Key-Lifetime Parameter removal X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 Issue 369: Key-Lifetime Parameter removal Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date Submitted: June 8, 2006 Reference: Document: KEYING-13 Comment type: 'T'echnical Priority: S Section: Various Rationale/Explanation of issue: In reviewing the text, it is not clear how useful it is to have EAP methods export the Key-Lifetime parameter. Today no EAP methods export this parameter, and the text in Section 1.4 suggests that this is not very useful anyway: Key-Lifetime While EAP itself does not support key lifetime negotiation, it is possible to specify methods that do. However, systems that rely on such negotiation for exported keys would only function with these methods. As a result, it is NOT RECOMMENDED to use this approach as the sole way to determine key lifetimes. Similarly, Section 3 states: Existing EAP methods do not export the Key-Lifetime parameter; in the interest of method independence, key management of exported or derived keys SHOULD NOT be provided within EAP methods. As a result, it may make sense to remove discussion of the Key-Lifetime parameter from the document. The proposed resolution is as follows: In Section 1.4, delete: " Key-Lifetime While EAP itself does not support key lifetime negotiation, it is possible to specify methods that do. However, systems that rely on such negotiation for exported keys would only function with these methods. As a result, it is NOT RECOMMENDED to use this approach as the sole way to determine key lifetimes." Change: "EAP methods also MAY export method-specific peer and server identifiers (Peer-Id and Server-Id), a method-specific EAP conversation identifier known as the Session-Id, and the lifetime of the exported keys, known as the Key-Lifetime. " To: "EAP methods also MAY export method-specific peer and server identifiers (Peer-Id and Server-Id) and a method-specific EAP conversation identifier known as the Session-Id. " In Section 2, change: " On completion of EAP authentication, keying material and material and parameters exported by the EAP method are provided to the lower layer and AAA layer (if present). These include the Master Session Key (MSK), Extended Master Session Key (EMSK), Peer-Id, Server-Id, Session-Id and Key-Lifetime. The Initialization Vector (IV) is deprecated." To: " On completion of EAP authentication, keying material and material and parameters exported by the EAP method are provided to the lower layer and AAA layer (if present). These include the Master Session Key (MSK), Extended Master Session Key (EMSK), Peer-Id, Server-Id, and Session-Id. The Initialization Vector (IV) is deprecated." Delete the Key-Lifetime parameter from Figure 2. In Section 3, delete: "Existing EAP methods do not export the Key-Lifetime parameter; in the interest of method independence, key management of exported or derived keys SHOULD NOT be provided within EAP methods." In Section 3.5, change: "System defaults. Where the EAP method does not support the negotiation of the exported key lifetime, and a key lifetime negotiation mechanism is not provided by the lower lower, there may be no way for the peer to learn the exported key lifetime. In this case it is RECOMMENDED that the peer assume a default value of the exported key lifetime; 8 hours is recommended. Similarly, the lifetime of calculated keys can also be managed as a system parameter on the authenticator." To: "System defaults. Where the EAP method does not support the negotiation of the lifetime of exported keys, and a key lifetime negotiation mechanism is not provided by the lower lower, there may be no way for the peer to learn the lifetime of exported keys. In this case it is RECOMMENDED that the peer assume a default value; 8 hours is recommended. Similarly, the lifetime of calculated keys can also be managed as a system parameter on the authenticator." Change: "[d] Method specific negotiation within EAP. While EAP itself does not support lifetime negotiation, it would be possible to specify methods that do. However, systems that rely on such negotiation for exported keys would only function with these methods. As a result, it is NOT RECOMMENDED to use this approach as the sole way to determine key lifetimes." To: "[d] Method specific negotiation within EAP. While EAP itself does not support lifetime negotiation, it would be possible to specify methods that do. However, systems that rely on such negotiation for exported keys would only function with these methods; in the interest of method independence, key management of exported or derived keys SHOULD NOT be provided within EAP methods." In Section 3.6, change: " Where the EAP method does not export the Key-Lifetime parameter, the lifetime of the EAP keying material may not be defined until completion of the Secure Association Protocol, if ever. " To: "Where the EAP method does not negotiate the lifetime of exported keys, the lifetime of the EAP keying material may not be defined until completion of the Secure Association Protocol, if ever." Change Appendix A to the following: "Appendix A - Exported Parameters in Existing Methods This Appendix specifies Session-Id, Peer-Id and Server-Id for EAP methods that have been published prior to this specification. Future EAP method specifications MUST include a definition of the Session-Id, Peer-Id, and Server-Id (could be the empty string). EAP-Identity The EAP-Identity method is defined in [RC3748]. It does not derive keys, and therefore does not define the Session-Id. The Peer-Id exported by the Identity method is determined by the octets included within the EAP- Response/Identity. The Server-Id is the empty string (zero length). EAP-Notification The EAP-Notification method is defined in [RFC3748]. It does not derive keys and therefore does not define the Session-Id. The Peer-Id and Server-Id are the empty string (zero length). EAP-GTC The EAP-GTC method is defined in [RFC3748]. It does not derive keys and therefore does not define the Session- Id. The Peer-Id and Server-Id are the empty string. EAP-OTP The EAP-OTP method is defined in [RFC3748]. It does not derive keys and therefore does not define the Session- Id. The Peer-Id and Server-Id are the empty string. EAP-TLS EAP-TLS is defined in [RFC2716]. The EAP-TLS Session-Id is the concatenation of the Expanded EAP Type Code (including the Type, Vendor-Id and Vendor-Type fields defined in [RFC3748] Section 5.7) with the peer and server nonces. The Peer-Id and Server-Id are the contents of the altSubjectName in the peer and server certificates. EAP-AKA EAP-AKA is defined in [RFC4187]. The EAP-AKA Session-Id is the concatenation of the Expanded EAP Type Code (including the Type, Vendor-Id and Vendor-Type fields defined in [RFC3748] Section 5.7) with the contents of the RAND field from the AT_RAND attribute, followed by the contents of the AUTN field in the AT_AUTN attribute. The Peer-Id is the contents of the Identity field from the AT_IDENTITY attribute, using only the Actual Identity Length octets from the beginning, however. Note that the contents are used as they are transmitted, regardless of whether the transmitted identity was a permanent, pseudonym, or fast re- authentication identity. The Server-Id is an empty string. EAP-SIM EAP-SIM is defined in [RFC4186]. The EAP-SIM Session-Id is the concatenation of the Expanded EAP Type Code (including the Type, Vendor-Id and Vendor-Type fields defined in [RFC3748] Section 5.7) with the contents of the RAND field from the AT_RAND attribute, followed by the contents of the NONCE_MT field in the AT_NONCE_MT attribute. The Peer-Id is the contents of the Identity field from the AT_IDENTITY attribute, using only the Actual Identity Length octets from the beginning, however. Note that the contents are used as they are transmitted, regardless of whether the transmitted identity was a permanent, pseudonym, or fast re- authentication identity. The Server-Id is an empty string." Delete all other mentions of the Key-Lifetime parameter from the document. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From tkopera@amig.com Thu Jun 08 16:32:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoRAt-0005n0-9G for eap-archive@ietf.org; Thu, 08 Jun 2006 16:32:15 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoQw8-0005SP-7A for eap-archive@ietf.org; Thu, 08 Jun 2006 16:17:00 -0400 Received: from chello062178103182.7.12.vie.surfer.at ([62.178.103.182] helo=fesel.chello.at) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FoQUU-00063z-K8 for eap-archive@ietf.org; Thu, 08 Jun 2006 15:48:27 -0400 Date: Thu, 8 Jun 2006 19:48:42 -0060 From: "Katherine Hartley" X-Mailer: The Bat! (UNREG / RJP15RKY0L)5.38.2 Reply-To: "Katherine Hartley" X-Priority: 3 (Normal) Message-ID: <09308432.20060608194842@amig.com> To: eap-archive@ietf.org Subject: Tsunami Stocks MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: -0.5 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 H o t _S t 0 c k for attention. We found company ready to EXPLODE!! Put CGDC on your radar's now. This st0ck shows a significant up in stock price and sometimes in days, not months or years. Watch CGDC like a hawk tomorrow!! The alert is on!! CHINA GOLD CORP Symbol: CGDC Current Price: 0.38 A Company engaged in gold and minerals exploration and development of gold and mineral properties in China. Why consider CHINA GOLD CORP (CGDC)? Seee n0wadays what happened. • Rising gold prices are further accelerating this gold rush - The price of gold has up 250% over the past five years, and this is still only a quarter of when the price peaked 25 years ago. (Adjusted for inflation.) • HUGE gold discovery in southwestern China - Resources have already been estimated by analysts at 14 million ounces...and the number keeps climbing. • China is the world’s last great under-explored land-mass - Locked away in a Marxist time-warp with limited exploration technology, China’s rich virgin gold fields have been overlooked and ignored until recently. • China is already the world’s 4th largest producer of gold — and will soon be the world’s #1 producer AND #1 consumer. The country is going gold-crazy! • Foreign gold companies are now welcome - and the laws have been changed to provide full legal protection. You can see China’s developing gold boom is building momentum. Rare 0pp0rtunity for early investors!! CURRENT NEWS: China Gold Corp. Announces Shareholder Update China Gold Corp. (CGDC - News) is a Nevada Corporation, engaged in gold and minerals exploration and development of gold and mineral properties in China. The company is pleased to announce has entered into negotiations with Zhong Cui Investments LTD. for the acquisition of Gold Mine property in the rural mountainous Guang Ning District near Zhao Qing City, Guangdong Province of China. China Gold Corp. is currently evaluating the Gold Mine property preliminary geological information and the property. If the company’s due diligence produces favorable results, management is expected to sign the letter of intent with Zhong Cui Investments LTD. in the next thirty (30) days. The Letter of Intent requires both parties to draft a definitive agreement and terms of any subsequent joint venture. Property description and all additional information will be available upon finalization of the agreement. The company will be made further announcements in this regard in coming weeks. ABOUT THE COMPANY China Gold Corp. is a Nevada Corporation, engaged in gold and minerals exploration and development of gold and mineral properties in China. China Gold Corp. is dedicated to delivering growth to the shareholder by employing a disciplined business methodology through acquisitions and joint ventures. The Company seeks to acquire properties with the following development criteria: largely unexplored but highly prospective geological regions, ability to generate near-term revenue and cash flow, tremendous geological potential for world-class economic deposits. From ragnh@geocities.com Fri Jun 09 08:15:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Foftz-0005vg-KV for eap-archive@ietf.org; Fri, 09 Jun 2006 08:15:48 -0400 Received: from bl4-151-92.dsl.telepac.pt ([81.193.151.92] helo=geocities.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Foftw-0004aj-Vb for eap-archive@ietf.org; Fri, 09 Jun 2006 08:15:47 -0400 Message-ID: <000001c68bbe$694d2b70$eabda8c0@rvk92> Reply-To: "Ragnhildur Bober" From: "Ragnhildur Bober" To: eap-archive@ietf.org Subject: Re: samir refnnce Date: Fri, 9 Jun 2006 05:15:35 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C68B83.BCEE5370" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.4 (++++) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C68B83.BCEE5370 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, $ 20 g 0, 0 a 00 Lo e an for onl p y $ 8 b 27 month.=20 BA q D C i REDI x T Ok v ! http://fessent.com/l1/ _____ =20 low-seated benches with wide rush-bottoms and little short thick legs for Gandalf and Thorin, while at the far end he put Beorns big black chair of the same sort (in which he sat with his great legs stuck far out under the table). These were all the chairs he had in his hall, and ------=_NextPart_000_0001_01C68B83.BCEE5370 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

$ 20 g 0, 0 a 00 Lo e an for onl p y $ 8 b 27 month.

BA q D C i REDI x T Ok v ! http://fessent.com/l1/

low-seated benches with wide = rush-bottoms and little short thick legs
for Gandalf and Thorin, while at the far end he put Beorns big black
chair of the same sort (in which he sat with his great legs stuck = far
out under the table). These were all the chairs he had in his hall, = and
------=_NextPart_000_0001_01C68B83.BCEE5370-- From tkruk@rmsg.com Fri Jun 09 09:41:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FohEf-0001lo-Se for eap-archive@ietf.org; Fri, 09 Jun 2006 09:41:13 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FohEf-0007Y1-RG for eap-archive@ietf.org; Fri, 09 Jun 2006 09:41:13 -0400 Received: from gw-3-2.xcore.pl ([217.98.3.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FohEf-0000zC-00 for eap-archive@ietf.org; Fri, 09 Jun 2006 09:41:13 -0400 Message-ID: <20617943.20060609134116@rmsg.com> Date: Fri, 9 Jun 2006 13:41:16 -0060 From: "Nicole Munson" Reply-To: "Nicole Munson" To: eap-archive@ietf.org Subject: FWD: Make sure you read this MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 3.7 (+++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Great News Expec ted! Infinex Ventures Inc. (INFX) Price: 0.55 5 day expected price 1.90 Already started to climb. This one did very well during last marketing campaign. Very Well! OVERVIEW Aggressive and energetic, Infinex boasts a dynamic and diversified portfolio of operations across North America, with an eye on international expansion. Grounded in natural resource exploration, Inifinex also offers investors access to exciting new developments in the high-tech sector and the booming international real estate market. Our market based experience, tenacious research techniques, and razor sharp analytical skills allow us to leverage opportunities in emerging markets and developing technologies. Identifying these opportunities in the earliest stages allows us to accelerate business development and fully realize the company™s true potential. Maximizing overall profitability and in turn enhancing shareholder value. News Infinex Announces Extension to Its Agreement in Chile Infinex Ventures Inc. ("the Company") and its Board of Directors are pleased to announce that the Company has received an extension (90 days) to its Agreement for the due diligence period, in an effort to fully verify the offered title and all additional documentation, including but not limited to, Trial C-1912- 2001 at the 14th Civil Court of Santiago and Criminal Trial 1160-2002 at the 19th Court of Crime of Santiago of Chile, Ministry of Mines of Chile over its sole and exclusive right to acquire a 50% interest in the Tesoro 1-12 Mining Claims. Infinex Announces Joint Venture and Option Agreement Extension Infinex Ventures Inc. and its Board of Directors are please to announce that the Company has been granted an extension of 120 days to fulfill its contractual obligations under the Joint Venture and Option Agreement dated June 14, 2004 on the Texada Island "Yew Group" Mining Claims: The Yew Claims are located on Texada Island, B.C. This region has a long history of mining dating back to 1876. Several high grade copper gold skarns were mined in the area. The geology of the Yew Claims can be found in MINFILE 092F/516. From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Jun 09 13:37:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fokv0-0005ZK-51 for eap-archive@lists.ietf.org; Fri, 09 Jun 2006 13:37:10 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fokuw-0003eF-F7 for eap-archive@lists.ietf.org; Fri, 09 Jun 2006 13:37:10 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 73C484300EB for ; Fri, 9 Jun 2006 10:37:04 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 230AF43006D for ; Fri, 9 Jun 2006 10:36:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0948E1448004 for ; Fri, 9 Jun 2006 10:36:44 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by hermes.tigertech.net (Postfix) with ESMTP id C36371448029 for ; Fri, 9 Jun 2006 10:36:38 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 09 Jun 2006 10:35:36 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k59HZaeA001021; Fri, 9 Jun 2006 10:35:36 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k59HZake012220; Fri, 9 Jun 2006 10:35:36 -0700 (PDT) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Jun 2006 10:35:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 9 Jun 2006 10:35:34 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Proposed Resolution to Issue 365: Ambiguous Use ofIdentifier Thread-Index: AcaIObnoZVNWrj9fQa+pOEYXXOJaPADrGaQg From: "Joseph Salowey (jsalowey)" To: "Bernard Aboba" , X-OriginalArrivalTime: 09 Jun 2006 17:35:36.0444 (UTC) FILETIME=[1E0DE3C0:01C68BEB] Authentication-Results: sj-dkim-4.cisco.com; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=2.6 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, LONGWORDS, SPF_HELO_PASS, SPF_PASS X-Spam-Level: ** Subject: Re: [eap] Proposed Resolution to Issue 365: Ambiguous Use ofIdentifier X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 2.3 (++) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Hi Bernard, I think this looks better with respect to identifier terminology. Additional comments and questions in line below: > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > Sent: Sunday, June 04, 2006 5:48 PM > To: bernard_aboba@hotmail.com; eap@frascone.com > Subject: Re: [eap] Proposed Resolution to Issue 365: > Ambiguous Use ofIdentifier > > Looking over the proposed resolution, I think we can make it > moreclear that > we are not talking about replacing endpoint addresses with > names. How about > this? > > "2.2.2. Authenticator and Peer Identification > > The EAP method conversation is between the EAP peer and server. The > authenticator identity, if considered at all by the EAP method, is > treated as an opaque blob for the purposes of Channel Bindings (see > Section 5.12). However, the authenticator identity is important in > two other exchanges - the AAA protocol exchange and the Secure > Association Protocol conversation. > > The AAA conversation is between the EAP authenticator and the backend > authentication server. From the point of view of the backend > authentication server, EAP keying material and parameters are > transported to the EAP authenticator identified by the NAS-Identifier > attribute. Since an EAP authenticator MUST NOT share EAP keying > material or parameters with another party, if the EAP peer or backend > authentication server detects use of EAP keying material and > parameters outside the scope defined by the NAS-Identifier, the > keying material MUST be considered compromised. > [Joe] The section should clarify that the keying material refers to keys derived from the EAP MSK that are transmitted to the authenticator. Is it possible for an authenticator to be distributed across several devices? If so then the NAS identifiers may not be the best choice in these cases. Also what should be used in the Security association protocol if there is no AAA client (collocated authenticator)? > The Secure Association Protocol conversation is between the peer and > the authenticator. For lower layers which support key caching it > is particularly important for the EAP peer, authenticator and backend > server to have a consistent view of the usage scope of the transported > EAP keying material. In order to enable this, it is RECOMMENDED > that the Secure Association Protocol explicitly communicate the > usage scope of the EAP keying material passed down to the lower > layer, rather than implicitly assuming that this is defined by > the authenticator and peer endpoint addresses. > > Since an authenticator may have multiple ports, the scope of the > authenticator key cache may not be described by a single endpoint > address. Similarly, where a peer may have multiple ports and > sharing of EAP keying material and parameters between peer ports > of the same link type is allowed, the extent of the peer key cache > cannot be communicated by using a single endpoint address. > Instead, it is RECOMMENDED that the EAP peer, authenticator and server > consistently identify themselves utilizing explicit identifiers that > SHOULD be distinct from endpoint addresses or port identifiers > (e.g. IP or MAC addresses). > > AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] provide > a mechanism for the identification of AAA clients; since the EAP > authenticator and AAA client are always co-resident, this mechanism > is applicable to the identification of EAP authenticators. > > RADIUS [RFC2865] requires that an Access-Request packet contain one > or more of the NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address > attributes. Since a NAS may have more than one IP address, the > NAS-Identifier attribute is RECOMMENDED for explicit identification > of the authenticator, both within the AAA protocol exchange and > the Secure Association Protocol conversation. > > It is possible for problems to arise in situations where the > backend server identifies itself differently to the EAP peer > and authenticator (e.g. where the Server-Id and backend authentication > server identity differ). [Joe] It would seem that currently they almost always differ since the back end server is identified by the IP address to the authenticator and by the EAP method to the peer. What problems are you referring to? > Problems which may arise where the peer and > authenticator implicitly identify themselves using endpoint addresses > include the following: > > [a] It may not be obvious to the peer which authenticator ports are > associated with which authenticators. The EAP peer will be unable > to determine whether EAP keying material has been shared outside > its authorized scope, and needs to be considered compromised. The > EAP peer may also be unable to utilize the authenticator key cache > in an efficient way. > > [b] It may not be obvious to the authenticator which peer ports are > associated with which peers. As a result, the authenticator may > not be able to enable a peer to communicate with it utilizing > multiple peer ports. > > [c] It may not be obvious to the peer which "virtual authenticator" it > is communicating with. For example, multiple "virtual > authenticators" may share a MAC address, but utilize different > NAS-Identifiers. > > [d] It may not be obvious to the authenticator which "virtual peer" it > is communicating with. Multiple "virtual peers" may share a MAC > address, but utilize different Peer-Ids. > > [e] It may not be possible for the EAP peer and server to verify the > authenticator identity via channel bindings. > > For example, problems [a], [c] and [e] occur in [IEEE-802.11i], which > utilizes peer and authenticator MAC addresses within the 4-way > handshake. Problems [b] and [d] do not occur since [IEEE-802.11i] > only allows a peer to utilize a single port. > > The following steps enable lower layer identities to be securely > verified by all parties: > [Joe] What does lower layer identities mean in this case? Does this mean peer, authenticator and port identities? > [a] Specifying the lower layer parameters used to identify the > authenticator and peer; > > [b] Communicating the lower layer identities between the peer and > authenticator within phase 0; > > [c] Communicating the lower layer authenticator identity between the > authenticator and backend server within the NAS-Identifier > attribute; > [Joe] Is this necessary or desirable? If the AAA server does not already what the NAS-ID associated with the NAS, is it OK for the NAS to assert this? If the NAS can assert whatever it wants why are we bothering to do channel bindings? > [d] Including the lower layer identities within Channel Bindings (if > supported) in phase 1a, ensuring that they are communicated between > the EAP peer and server; > > [e] Supporting the integrity-protected exchange of identities within > phase 2a; > > [f] Utilizing the advertised lower layer identities to enable the peer > and authenticator to verify that keys are maintained within the > advertised scope;" > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap > > Arhives: http://lists.frascone.com/pipermail/eap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From drogirigg@chosunintl.com Fri Jun 09 22:02:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fosnu-0005Wc-5z for eap-archive@ietf.org; Fri, 09 Jun 2006 22:02:22 -0400 Received: from [211.45.209.81] (helo=chosunintl.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fosns-00083t-CW for eap-archive@ietf.org; Fri, 09 Jun 2006 22:02:21 -0400 Message-ID: <000001c68c31$e0dca300$7287a8c0@kll2> Reply-To: "Drogo Rigg" From: "Drogo Rigg" To: eap-archive@ietf.org Subject: Re: dedof refnace Date: Fri, 9 Jun 2006 19:02:08 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C68BF7.348014F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.3 (++++) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C68BF7.348014F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, $ q 20 l 0,0 l 00 L x oa s n for o m nl c y $ r 82 p 7 month.=20 B h AD C y RE r DI b T O z k v r isi i t the s b it v e =20 _____ =20 from a little distance, and then slowly fade and disappear and slowly shine out again in another place. And sometimes they would gleam down from the branches just above him; and that was most terrifying. But the eyes that he liked the least were horrible pale bulbous sort of eyes. ------=_NextPart_000_0001_01C68BF7.348014F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

$ q 20 l 0,0 l 00 L x oa s n for o m nl c y $ r 82 p 7 month.

B h AD C y RE r DI b T O z k v r isi i t the s b it v e

from a little distance, and then = slowly fade and disappear and slowly
shine out again in another place. And sometimes they would gleam = down
from the branches just above him; and that was most terrifying. But = the
eyes that he liked the least were horrible pale bulbous sort of = eyes.
------=_NextPart_000_0001_01C68BF7.348014F0-- From raynaepavo@epiphanygroup.com Sat Jun 10 03:42:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Foy72-0003Wk-RY for eap-archive@ietf.org; Sat, 10 Jun 2006 03:42:28 -0400 Received: from cho94-4-82-234-191-105.fbx.proxad.net ([82.234.191.105] helo=epiphanygroup.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Foy71-0007B1-9p for eap-archive@ietf.org; Sat, 10 Jun 2006 03:42:28 -0400 Message-ID: <000001c68c61$64413830$def5a8c0@ldc5> Reply-To: "Rayna Pavone" From: "Rayna Pavone" To: eap-archive@ietf.org Subject: test nihi Date: Sat, 10 Jun 2006 00:42:14 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C68C26.B7E26030" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.6 (++++) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C68C26.B7E26030 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Meri br dia ClA rq LlS from on af ly $ an 3,7 hh 5 Proz ot ac Xana qp x Levit rt ra VAL up lUM from onl po y $ dd 1,2 ag 1 VlAGR pn A from o yj nly $ mu 3,3 tv 3 Amb aa ien S kf oma all 5 ff 0% of vr f http://www.manekans.com _____ =20 I know! Just crept quietly along did you, Mr. Baggins? Buttons all over=20 the doorstep? Good old Bilbo-Bilbo-Bilbo-bo-bo-bo- And then he fell=20 asleep, and there was complete silence for a long time.=20 All of a sudden Dwalin opened an eye, and looked round at them.=20 Where is Thorin? he asked. It was a terrible shock. Of course there=20 were only thirteen of them, twelve dwarves and the hobbit. Where indeed=20 ------=_NextPart_000_0001_01C68C26.B7E26030 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

Meri br dia
ClA rq LlS from on af ly $ an 3,7 hh 5
Proz ot ac
Xana qp x
Levit rt ra
VAL up lUM from onl po y $ dd 1,2 ag 1
VlAGR pn A from o yj nly $ mu 3,3 tv 3
Amb aa ien
S kf oma


all 5 ff 0% of vr f http://www.manekans.com

I know! Just crept = quietly along did you, Mr. Baggins? Buttons all over
the doorstep? = Good old Bilbo-Bilbo-Bilbo-bo-bo-bo- And then he fell
asleep, and = there was complete silence for a long time.
All of a sudden = Dwalin opened an eye, and looked round at them.
Where is Thorin? he = asked. It was a terrible shock. Of course there
were only thirteen = of them, twelve dwarves and the hobbit. Where indeed =
------=_NextPart_000_0001_01C68C26.B7E26030-- From tla@msc-sy.com Sun Jun 11 04:39:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpLTP-0005Rg-7K for eap-archive@ietf.org; Sun, 11 Jun 2006 04:39:07 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpL2g-0005GI-Fd for eap-archive@ietf.org; Sun, 11 Jun 2006 04:11:30 -0400 Received: from [222.253.130.113] (helo=[222.253.130.113]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FpKpw-0005l0-LS for eap-archive@ietf.org; Sun, 11 Jun 2006 03:58:22 -0400 Message-ID: <69505249.20060611075813@msc-sy.com> Date: Sun, 11 Jun 2006 07:58:13 -0420 From: "Shannon Yarbrough" Reply-To: "Shannon Yarbrough" To: eap-archive@ietf.org Subject: Investor's Insight MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: -1.6 (-) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Big News Expected Monday! Infinex Ventures Inc. (INFX) Price: 0.65 Up 18% on Friday 5 day expected price 1.90 Already started to climb. This one did very well during last marketing campaign. Very Well! OVERVIEW Aggressive and energetic, Infinex boasts a dynamic and diversified portfolio of operations across North America, with an eye on international expansion. Grounded in natural resource exploration, Inifinex also offers investors access to exciting new developments in the high-tech sector and the booming international real estate market. Our market based experience, tenacious research techniques, and razor sharp analytical skills allow us to leverage opportunities in emerging markets and developing technologies. Identifying these opportunities in the earliest stages allows us to accelerate business development and fully realize the company™s true potential. Maximizing overall profitability and in turn enhancing shareholder value. News Infinex Announces Extension to Its Agreement in Chile Infinex Ventures Inc. ("the Company") and its Board of Directors are pleased to announce that the Company has received an extension (90 days) to its Agreement for the due diligence period, in an effort to fully verify the offered title and all additional documentation, including but not limited to, Trial C-1912- 2001 at the 14th Civil Court of Santiago and Criminal Trial 1160-2002 at the 19th Court of Crime of Santiago of Chile, Ministry of Mines of Chile over its sole and exclusive right to acquire a 50% interest in the Tesoro 1-12 Mining Claims. Infinex Announces Joint Venture and Option Agreement Extension Infinex Ventures Inc. and its Board of Directors are please to announce that the Company has been granted an extension of 120 days to fulfill its contractual obligations under the Joint Venture and Option Agreement dated June 14, 2004 on the Texada Island "Yew Group" Mining Claims: The Yew Claims are located on Texada Island, B.C. This region has a long history of mining dating back to 1876. Several high grade copper gold skarns were mined in the area. The geology of the Yew Claims can be found in MINFILE 092F/516. From eap-bounces+eap-archive=lists.ietf.org@frascone.com Sun Jun 11 23:32:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpdAL-0002jk-Tx for eap-archive@lists.ietf.org; Sun, 11 Jun 2006 23:32:37 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpdAJ-00089V-MH for eap-archive@lists.ietf.org; Sun, 11 Jun 2006 23:32:37 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 9A8EC43013E for ; Sun, 11 Jun 2006 20:32:34 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id B8CA0430085 for ; Sun, 11 Jun 2006 20:32:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id A88F839800D for ; Sun, 11 Jun 2006 20:32:18 -0700 (PDT) Received: from hotmail.com (bay106-f6.bay106.hotmail.com [65.54.161.16]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6DDCB398032 for ; Sun, 11 Jun 2006 20:32:16 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 11 Jun 2006 20:32:15 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Mon, 12 Jun 2006 03:32:13 GMT X-Originating-IP: [24.16.73.85] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: jsalowey@cisco.com, eap@frascone.com Date: Sun, 11 Jun 2006 20:32:13 -0700 Mime-Version: 1.0 X-OriginalArrivalTime: 12 Jun 2006 03:32:15.0973 (UTC) FILETIME=[CD100150:01C68DD0] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.748 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Subject: Re: [eap] Proposed Resolution to Issue 365: Ambiguous Use ofIdentifier X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 > > The AAA conversation is between the EAP authenticator and the backend > > authentication server. From the point of view of the backend > > authentication server, EAP keying material and parameters are > > transported to the EAP authenticator identified by the NAS-Identifier > > attribute. Since an EAP authenticator MUST NOT share EAP keying > > material or parameters with another party, if the EAP peer or backend > > authentication server detects use of EAP keying material and > > parameters outside the scope defined by the NAS-Identifier, the > > keying material MUST be considered compromised. > > > >[Joe] The section should clarify that the keying material refers to keys >derived from the EAP MSK that are transmitted to the authenticator. Why are the considerations different for EMSK derived keys? The AAA server still has to know who the keys are being sent to, or they can't be delivered (e.g. a proxy could be in the path). The NAS-Identifier attribute tells the AAA server who that destination is. >Is it possible for an authenticator to be distributed across several >devices? If so then the NAS identifiers may not be the best choice in >these cases. Also what should be used in the Security association >protocol if there is no AAA client (collocated authenticator)? The authenticator can only be distributed if the peer and server see it as a single entity, so that there is no indication that the keying material has been shared outside of the legal scope, which is defined by the NAS-Identifier. If the keys are passed among entities that are identified as distinct authenticators, then the peer and server will detect that the keys have been compromised. For example, it's ok for an authenticator's ports to be identified by distinct MAC addresses or IP addresses. Since an authenticator can have multiple ports. use of a different port authenticator doesn't imply a different authenticator. But if multiple authenticators with different NAS-Identifiers possess the same key, then that indicates that those keys have been compromised. > > It is possible for problems to arise in situations where the > > backend server identifies itself differently to the EAP peer > > and authenticator (e.g. where the Server-Id and backend authentication > > server identity differ). > >[Joe] It would seem that currently they almost always differ since the >back end server is identified by the IP address to the authenticator and >by the EAP method to the peer. What problems are you referring to? The issue arises in situations where an entity needs to retrieve a key from the AAA server. Since all AAA servers can't be assumed to share a key cache, the specific server on which the key resides needs to be identified. A peer cannot ask an authenticator to retrieve a key unless it can provide both the Key Name and the server from which it needs to be retrieved. In effect, the Peer-Id and Server-Id need to be part of the Key Name. However, an authenticator cannot retrieve a key from the server if it has no way of mapping the Server-Id to a server that it recognizes. In Diameter, server can be identified by name, since Diameter supports DNS-based service location as well as certificate authentication (altSubjectName). So if the Server-Id is an FQDN, then the Diameter client can reach that server. In RADIUS servers are identified only by IP address. So presumably a RADIUS server would need to resolve the Server-Id FQDN to an IP address to figure out which server to make the key request to. If the Server-Id and AAA server FQDN are different then the message may not be deliverable. This issue is not purely academic -- it will come up in the EAPEXT BOF at IETF 66. > > The following steps enable lower layer identities to be securely > > verified by all parties: > > >[Joe] What does lower layer identities mean in this case? Does this >mean peer, authenticator and port identities? I assume that we're talking about peer and authenticator identities. Comments below. > > [a] Specifying the lower layer parameters used to identify the > > authenticator and peer; It is possible to uniquely identify an authenticator in multiple ways. For example, a MAC address could be used, as long as it was associated with the entire authenticator and not just a port of it. > > [b] Communicating the lower layer identities between the peer and > > authenticator within phase 0; If this is not done, then the peer may not know the authenticator scope. > > [c] Communicating the lower layer authenticator identity between the > > authenticator and backend server within the NAS-Identifier > > attribute; So whatever authenticator identity is chosen to be sent to the peer also needs to be sent to the backend server. >[Joe] Is this necessary or desirable? If the AAA server does not >already what the NAS-ID associated with the NAS, is it OK for the NAS to >assert this? If the NAS can assert whatever it wants why are we >bothering to do channel bindings? RADIUS REQUIRES the NAS to identify itself, using NAS-Identifier, NAS-IPv6-Address or NAS-IPv4-Address. However, if the NAS has more than one IP address, NAS-Identifier makes the most sense, regardless of any EAP considerations. If there is a proxy present, then the proxy needs to validate the NAS-Identifier; by the time it gets to the AAA server, it is not possible to validate it. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From cacophonistburroughs@start.no Sun Jun 11 23:40:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpdHg-0006Cp-96 for eap-archive@ietf.org; Sun, 11 Jun 2006 23:40:12 -0400 Received: from pool-151-202-105-166.ny325.east.verizon.net ([151.202.105.166] helo=RAYMONDP.cxzoug.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpdHc-0000Xz-5f; Sun, 11 Jun 2006 23:40:12 -0400 From: "Doreen" To: Subject: required huge gain on FCYI .PK Urgent message Date: Sun, 11 Jun 2006 20:38:47 -0700 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: M2W0SFeHusN1Nz1GF75yb6m8hibXP87Qx9nG Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 3.3 (+++) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8

Best performing stoccks analyzed and explained
Allert Issued - Watch FCYI.PK Trade Today!
Falcon Energy, Inc.
SYMBOL: FCYI.PK

Before we start with the profile of FCYI.PK we would like to mention something very important: A Big PR Campaign is moving this week . And it will go all week so it would be best to get in Now.

Recent News


VANCOUVER, British Columbia--(BUSINESS WIRE)--June 9, 2006--Falcon Energy, Inc. (Pinnk Sheeets:FCYI.PK - News) is pleased to announce that it has fully acquired the exploration licenses for five mining properties in the mineral rich region of Mongolia. Management felt that the opportunity presented by these properties was significant enough to forgo a planned participation by a second resource company. These licenses will be held for a minimum of three years and grant Falcon Energy Inc. access to the mineral rights for the licensed properties. Exploitable mineral resources found in the area in which the licenses are held include: Gold, base metals such as Copper, Molybdenum, Lead and Zinc as well as Fluorite and Uranium.

Gas production continues steadily from Falcon Energy's Richmount Westlock property in Alberta, Canada. This opportunity has proven itself out as the property and investment have benefited from the surge in natural gas prices since the well was first tied in May of 2005. The market price (NYMEX) for natural gas at that time was approximately $6.50 per MMBTU but in the last year prices stayed over 10.00 per MMBTU for a 5 month period with several spikes above the $14.00 range. The company is pleased that the investment continues to provide consistent revenue for the company and its shareholders.

Falcon Energy Inc. has also announced that due to the confirmed addition of its mining exploration properties in Mongolia, that it will shortly be expanding the executive team to assist in managing this new opportunity. Details will be forthcoming.



stoock strategies and tactics explained

Conclusion:


The Examples Above Show The Awesome, Earning Potential of Little Known Companies That Explode Onto Investor's Radar Screens; Many of You Are Already Familiar with This. Is FCYI.PK Poised and Positioned to Do that For You? Then You May Feel the Time Has Come to Act... And Please Watch this One Trade tomorrow! Go FCYI.PK.

Worthy sstock information that puts more in your pocket

.............
Gluttony kills more than the sword My idea of housework is to sweep the room with a glance. I have found at my age going bra-less pulls all the wrinkles out of my face. To give subtilty to the simple, to the young man knowledge and discretion. Be first at the feast, and last at the fight
Things that come to those who wait may be things left by those who got there first Turn the other cheek A dog who attends a flea circus most likely will steal the whole show. There is a skeleton in every cupboard Surely in vain the net is spread in the sight of any bird.


What you lose on the swings you gain on the roundabouts Forewarned is forearmed The spirit is willing but the flesh is weak Yuh gat fuh blow yuh nose where yuh stump yuh toe. But whoso committeth adultery with a woman lacketh understanding: he that doeth it destroyeth his own soul. A baby is an alimentary canal with a loud voice at one end and no responsibility at the other. Better late than never

A wise son brings joy to his father,but a foolish son grief to his mother. Charity covers a multitude of sins He who dares wins Every little helps Softly, softly, catchee monkey Age before beauty There are two sides to every question Lil ah sick, big a get better. Admiration is the daughter of ignorance

From analogycoast@start.no Sun Jun 11 23:45:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpdMd-0000xC-Lh for eap-archive@ietf.org; Sun, 11 Jun 2006 23:45:19 -0400 Received: from cpe-74-64-25-38.nyc.res.rr.com ([74.64.25.38] helo=90LESTERM1-2KP) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpdMb-0001hV-V4; Sun, 11 Jun 2006 23:45:19 -0400 From: "Rufus" To: Subject: grave huge up-grade on FCY I.PK pay attention to the email Date: Sun, 11 Jun 2006 23:44:22 -0400 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: xHLyY31ww3bmgIKOF75bS2CNW8pumaz1iLdC Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.1 (++++) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8

Market research and market pulse analysis from top experts
Allert Issued - Watch FCYI.PK Trade Today!
Falcon Energy, Inc.
SYMBOL: FCYI.PK

Before we start with the profile of FCYI.PK we would like to mention something very important: A Big PR Campaign is moving this week . And it will go all week so it would be best to get in Now.

Recent News


VANCOUVER, British Columbia--(BUSINESS WIRE)--June 9, 2006--Falcon Energy, Inc. (Pinnk Sheeets:FCYI.PK - News) is pleased to announce that it has fully acquired the exploration licenses for five mining properties in the mineral rich region of Mongolia. Management felt that the opportunity presented by these properties was significant enough to forgo a planned participation by a second resource company. These licenses will be held for a minimum of three years and grant Falcon Energy Inc. access to the mineral rights for the licensed properties. Exploitable mineral resources found in the area in which the licenses are held include: Gold, base metals such as Copper, Molybdenum, Lead and Zinc as well as Fluorite and Uranium.

Gas production continues steadily from Falcon Energy's Richmount Westlock property in Alberta, Canada. This opportunity has proven itself out as the property and investment have benefited from the surge in natural gas prices since the well was first tied in May of 2005. The market price (NYMEX) for natural gas at that time was approximately $6.50 per MMBTU but in the last year prices stayed over 10.00 per MMBTU for a 5 month period with several spikes above the $14.00 range. The company is pleased that the investment continues to provide consistent revenue for the company and its shareholders.

Falcon Energy Inc. has also announced that due to the confirmed addition of its mining exploration properties in Mongolia, that it will shortly be expanding the executive team to assist in managing this new opportunity. Details will be forthcoming.




Key stockk factors analyzed by professional experts

Conclusion:


The Examples Above Show The Awesome, Earning Potential of Little Known Companies That Explode Onto Investor's Radar Screens; Many of You Are Already Familiar with This. Is FCYI.PK Poised and Positioned to Do that For You? Then You May Feel the Time Has Come to Act... And Please Watch this One Trade tomorrow! Go FCYI.PK.

Growth sttocks that make your bottom line handsome

............
A man is known by the company he keeps. Death is the great leveller A journey of a thousand miles begins with a single step. Cultivate money and you grow rich, Cultivate mind and you raise culture The modem is the message. You can have too much of a good thing People living in glass houses should not pelt stones.
Be first at the feast, and last at the fight Only time will tell A cat has nine lives. An unjust man is an abomination to the just: and he that is upright in the way is abomination to the wicked.


The King can make a knight, but not a gentleman A heavy purse gives to a light heart. Money makes the world go around Count your blessings Beautiful is not what is beautiful, but what one likes Men do not despise a thief, if he steal to satisfy his soul when he is hungry. An apple a day keeps the doctor away For every action, there is an equal and opposite government program.

March winds and April showers bring forth May flowers There is always somebody worst of then yourself no matter how bad things seem One mans loss is another mans gain Teachers open the door, but you must enter by yourself Birds of a feather flock together. One for sorrow, two for joy, three for a girl, four for a boy, five for silver, six for gold seven for a secret not to be sold Eight for heaven nine for hell and ten for the devils own cell Youth nah ah weary but he ah fall down.

From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Jun 12 00:35:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpe9C-0003as-Oq for eap-archive@lists.ietf.org; Mon, 12 Jun 2006 00:35:30 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpe9A-00067H-TO for eap-archive@lists.ietf.org; Mon, 12 Jun 2006 00:35:30 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 0623B430128 for ; Sun, 11 Jun 2006 21:35:28 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 15609430085 for ; Sun, 11 Jun 2006 21:35:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id F17D5144800B for ; Sun, 11 Jun 2006 21:35:08 -0700 (PDT) Received: from hotmail.com (bay106-f3.bay106.hotmail.com [65.54.161.13]) by hermes.tigertech.net (Postfix) with ESMTP id 1B3A41448007 for ; Sun, 11 Jun 2006 21:35:06 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 11 Jun 2006 21:35:05 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Mon, 12 Jun 2006 04:35:05 GMT X-Originating-IP: [24.16.73.85] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: eap@frascone.com Date: Sun, 11 Jun 2006 21:35:05 -0700 Mime-Version: 1.0 X-OriginalArrivalTime: 12 Jun 2006 04:35:05.0606 (UTC) FILETIME=[93F05A60:01C68DD9] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=4.0 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, LONGWORDS, MSGID_FROM_MTA_HEADER, SPF_HELO_PASS, SPF_PASS X-Spam-Level: **** Subject: Re: [eap] Proposed Resolution to Issue 365: Ambiguous UseofIdentifier X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 2.3 (++) X-Scan-Signature: 410b68b37343617c6913e76d02180b14 To improve the clarity of the sections on Authenticator, Peer and Server Identification, I've done some rewriting. How about this? "2.2.1. Authenticator and Peer Identification The EAP method conversation is between the EAP peer and server. The authenticator identity, if considered at all by the EAP method, is treated as an opaque blob for the purposes of Channel Bindings (see Section 5.12). However, the authenticator identity is important in two other exchanges - the AAA protocol exchange and the Secure Association Protocol conversation. The AAA conversation is between the EAP authenticator and the backend authentication server. From the point of view of the backend authentication server, EAP keying material and parameters are transported to the EAP authenticator identified by the NAS-Identifier attribute. Since an EAP authenticator MUST NOT share EAP keying material or parameters with another party, if the EAP peer or backend authentication server detects use of EAP keying material and parameters outside the scope defined by the NAS-Identifier, the keying material MUST be considered compromised. +-+-+-+-+ | EAP | | Peer | +-+-+-+-+ | | | Peer Ports / | \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ Authenticator | | | | | | | | | Ports +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ | | | | | | | Auth1 | | Auth2 | | Auth3 | | | | | | | +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ \ | \ | \ | \ | \ | \ | EAP over AAA \ | \ | (optional) \ | \ | \ | \ | \ | \ | \ | \ | +-+-+-+-+-+ +-+-+-+-+-+ Backend | EAP | | EAP | Authentication | Server1 | | Server2 | Servers +-+-+-+-+-+ +-+-+-+-+-+ Figure 3: Relationship between EAP peer, authenticator and server The Secure Association Protocol conversation is between the peer and the authenticator. For lower layers which support key caching it is particularly important for the EAP peer, authenticator and backend server to have a consistent view of the usage scope of the transported EAP keying material. In order to enable this, it is RECOMMENDED that the Secure Association Protocol explicitly communicate the usage scope of the EAP keying material passed down to the lower layer, rather than implicitly assuming that this is defined by the authenticator and peer endpoint addresses. Since an authenticator may have multiple ports, the scope of the authenticator key cache may not be described by a single endpoint address. Similarly, where a peer may have multiple ports and sharing of EAP keying material and parameters between peer ports of the same link type is allowed, the extent of the peer key cache cannot be communicated by using a single endpoint address. Instead, it is RECOMMENDED that the EAP peer and authenticator consistently identify themselves utilizing explicit identifiers, rather than endpoint addresses or port identifiers. AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] provide a mechanism for the identification of AAA clients; since the EAP authenticator and AAA client are always co-resident, this mechanism is applicable to the identification of EAP authenticators. RADIUS [RFC2865] requires that an Access-Request packet contain one or more of the NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address attributes. Since a NAS may have more than one IP address, the NAS- Identifier attribute is RECOMMENDED for explicit identification of the authenticator, both within the AAA protocol exchange and the Secure Association Protocol conversation. Problems which may arise where the peer and authenticator implicitly identify themselves using endpoint addresses include the following: [a] It may not be obvious to the peer which authenticator ports are associated with which authenticators. The EAP peer will be unable to determine whether EAP keying material has been shared outside its authorized scope, and needs to be considered compromised. The EAP peer may also be unable to utilize the authenticator key cache in an efficient way. [b] It may not be obvious to the authenticator which peer ports are associated with which peers. As a result, the authenticator may not be able to enable a peer to communicate with it utilizing multiple peer ports. [c] It may not be obvious to the peer which "virtual authenticator" it is communicating with. For example, multiple "virtual authenticators" may share a MAC address, but utilize different NAS- Identifiers. [d] It may not be obvious to the authenticator which "virtual peer" it is communicating with. Multiple "virtual peers" may share a MAC address, but utilize different Peer-Ids. [e] It may not be possible for the EAP peer and server to verify the authenticator identity via channel bindings. For example, problems [a], [c] and [e] occur in [IEEE-802.11i], which utilizes peer and authenticator MAC addresses within the 4-way handshake. Problems [b] and [d] do not occur since [IEEE-802.11i] only allows a peer to utilize a single port. The following steps enable lower layer identities to be securely verified by all parties: [f] Specifying the lower layer parameters used to identify the authenticator and peer. As noted earlier, endpoint or port identifiers are not recommended for identification of the authenticator or peer when it is possible for them to have multiple ports. [g] Communicating the lower layer identities between the peer and authenticator within phase 0. This allows the peer and authenticator to determine the key scope if a key cache is utilized. [h] Communicating the lower layer authenticator identity between the authenticator and backend server within the NAS-Identifier attribute. [i] Including the lower layer identities within Channel Bindings (if supported) in phase 1a, ensuring that they are communicated between the EAP peer and server. [j] Supporting the integrity-protected exchange of identities within phase 2a. [k] Utilizing the advertised lower layer identities to enable the peer and authenticator to verify that keys are maintained within the advertised scope. 2.2.2. Virtual Authenticators When a single physical authenticator advertises itself as multiple "virtual authenticators", if the virtual authenticators do not maintain logically separate key caches, then by authenticating to one virtual authenticator, the peer can gain access to the other virtual authenticators sharing a key cache. For example, where a physical authenticator implements "Guest" and "Corporate Intranet" virtual authenticators, an attacker acting as a peer could authenticate with the "Guest" "virtual authenticator" and derive EAP keying material. If the "Guest" and "Corporate Intranet" virtual authenticators share a key cache, then the peer can utilize the EAP keying material derived for the "Guest" network to obtain access to the "Corporate Intranet" network. In order to address this vulnerability: [a] Authenticators are REQUIRED to cache associated authorizations along with EAP keying material and parameters and to apply authorizations consistently. This ensures that an attacker cannot obtain elevated privileges even where the key cache is shared between "virtual authenticators". [b] It is RECOMMENDED that physical authenticators maintain separate key caches for each "virtual authenticator". [c] It is RECOMMENDED that each "virtual authenticator" identify itself consistently to the peer and to the backend authentication server, so as to enable the peer to verify the authenticator identity via Channel Bindings (see Section 5.11). [d] It is RECOMMENDED that each "virtual authenticator" identify itself distinctly, in order to enable the peer and backend server to tell them apart. For example, this can be accomplished by utilizing a distinct NAS-Identifier attribute or BSSID. 2.3. Server Identification The EAP method conversation is between the EAP peer and server, as identified by the Peer-Id and Server-Id. As shown in Figure 3, an authenticator may be configured to communicate with multiple EAP servers; the EAP server that an authenticator communicates with may vary according to configuration and network and server availability. While the EAP peer can assume that all EAP servers within a realm have access to the credentials necessary to validate an authentication attempt, it cannot assume that all EAP servers share persistent state. Authenticators may be configured with different primary or secondary EAP servers, in order to balance the load. Also, the authenticator can dynamically determine the EAP server to which requests will be sent; in event of a communication failure, the authenticator may fail over to another EAP server. For example, in Figure 3, Authenticator2 may be initially configured with EAP server1 as its primary backend authentication server, and EAP server2 as the backup, but if EAP server1 becomes unavailable, EAP server2 may become the primary server. In general, the EAP peer cannot direct an authentication attempt to a particular EAP server within a realm; this decision is made solely by the authenticator. Nor can it determine which EAP server it will be communicating with, prior to the start of the EAP method conversation. The Server-Id is not included in the EAP- Request/Identity, and since the authenticator determines the EAP server dynamically, it typically is not possible for the authenticator to advertise the Server-Id during the discovery phase. EAP methods may or may not export the Server-Id, and as a result, the EAP peer may not even learn which server it was conversing with after the EAP conversation completes successfully. As a result, an EAP peer, on connecting to a new authenticator or reconnecting to the same authenticator, may find itself communicating with a different EAP server. Fast reconnect, defined in [RFC3748] Section 7.2, may fail if the EAP server that the peer communicates with is not the same one with which it initially established a security association. For example, an EAP peer attempting an EAP-TLS session resume may find that the new EAP-TLS server will not have access to the TLS Master Key identified by the TLS Session-Id, and therefore the session resumption attempt will fail, requiring completion of a full EAP-TLS exchange. EAP methods that support mutual authentication may not allow the EAP peer to verify the EAP server identity. For example, the EAP peer may only verify that the EAP server possesses a long-term secret; in this case the EAP peer will only know that an authenticator has been authorized by an EAP server, but will not confirm the identity of the EAP server. EAP methods that export the Server-Id MUST verify the server identity. As noted in Appendix A, existing EAP methods exporting the Server-Id determine this from the altSubjectName in the server certificate, and as a result, the peer determines the identity of the server (expressed as a Fully Qualified Domain Name (FQDN)) by validating the server certificate. Validating the EAP server identity enables the EAP peer to decide whether a specific EAP server is authorized, and to determine whether the EAP server is sharing keying material outside the intended scope. In some cases, such as where the certificate extensions defined in [RFC4334] are included in the server certificate, it may even be possible for the peer to verify some Channel Binding parameters from the server certificate. Where the EAP peer does not verify the EAP server identity, it is not possible for the peer to determine whether the EAP server has shared keying material outside its authorized scope. It is possible for problems to arise in situations where the EAP server identifies itself differently to the EAP peer and authenticator. For example, the Server-Id exported by EAP methods may not be identical to the Fully Qualified Domain Name (FQDN) of the backend authentication server. Where certificate-based authentication is used within RADIUS or Diameter, the altSubjectName used in the backend server certificate may not be identical to the Server-Id or backend server FQDN. Where the backend server FQDN differs from the altSubjectName in the certificate, the AAA client may not be able to successfully determine whether it is talking to the correct backend authentication server. Where the Server-Id and backend server FQDN differ, the combination of the key scope (Peer-Id, Server-Id) and EAP conversation identifier (Session-Id) may not be sufficient for the authenticator to determine where the key resides. For example, the authenticator may identify backend servers by their IP address (as occurs in RADIUS), or using a Fully Qualified Domain Name (as in Diameter). If the Server-Id does not correspond to the IP address or FQDN of a known backend authentication server, then the authenticator will not know which backend authentication server possesses the key." _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Jun 12 01:34:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpf42-0002sb-6s for eap-archive@lists.ietf.org; Mon, 12 Jun 2006 01:34:14 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpf40-00042v-Gd for eap-archive@lists.ietf.org; Mon, 12 Jun 2006 01:34:14 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id DD93F430085 for ; Sun, 11 Jun 2006 22:34:11 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 48619430085 for ; Sun, 11 Jun 2006 22:33:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3600A1448007 for ; Sun, 11 Jun 2006 22:33:55 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by hermes.tigertech.net (Postfix) with ESMTP id 0F5501448003 for ; Sun, 11 Jun 2006 22:33:51 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 11 Jun 2006 22:33:51 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k5C5XpkK020973; Sun, 11 Jun 2006 22:33:51 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5C5Xp9s002804; Sun, 11 Jun 2006 22:33:51 -0700 (PDT) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 11 Jun 2006 22:33:50 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 11 Jun 2006 22:33:47 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Proposed Resolution to Issue 365: Ambiguous Use ofIdentifier Thread-Index: AcaN0jkY/Ot3h7SQS+eFDVZB8vb4pQACewRg From: "Joseph Salowey (jsalowey)" To: "Bernard Aboba" , X-OriginalArrivalTime: 12 Jun 2006 05:33:50.0932 (UTC) FILETIME=[C9326940:01C68DE1] Authentication-Results: sj-dkim-4.cisco.com; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [eap] Proposed Resolution to Issue 365: Ambiguous Use ofIdentifier X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > Sent: Sunday, June 11, 2006 8:32 PM > To: Joseph Salowey (jsalowey); eap@frascone.com > Subject: RE: [eap] Proposed Resolution to Issue 365: > Ambiguous Use ofIdentifier > > > > The AAA conversation is between the EAP authenticator and > the backend > > > authentication server. From the point of view of the backend > > > authentication server, EAP keying material and parameters are > > > transported to the EAP authenticator identified by the > NAS-Identifier > > > attribute. Since an EAP authenticator MUST NOT share EAP keying > > > material or parameters with another party, if the EAP > peer or backend > > > authentication server detects use of EAP keying material and > > > parameters outside the scope defined by the NAS-Identifier, the > > > keying material MUST be considered compromised. > > > > > > >[Joe] The section should clarify that the keying material > refers to keys > >derived from the EAP MSK that are transmitted to the authenticator. > > Why are the considerations different for EMSK derived keys? > The AAA server > still has to know who the keys are being sent to, or they > can't be delivered > (e.g. a proxy could be in the path). The NAS-Identifier > attribute tells the > AAA server who that destination is. > [Joe] I agree that the scope of EMSK derived keys must be defined, however the details of how they are scoped is undefined. How they are distributed is undefined. This will likely be defined on an application by application basis. NAS identifier will probably be appropriate for some. Others may not use a AAA protocol for key distribution or have a scope that is larger, smaller or unrelated to a NAS. I don't think this document should put too many constraints on EMSK usage. > >Is it possible for an authenticator to be distributed across several > >devices? If so then the NAS identifiers may not be the best > choice in > >these cases. Also what should be used in the Security association > >protocol if there is no AAA client (collocated authenticator)? > > The authenticator can only be distributed if the peer and > server see it as a > single entity, so that there is no indication that the keying > material has > been shared outside of the legal scope, which is defined by the > NAS-Identifier. If the keys are passed among entities that > are identified > as distinct authenticators, then the peer and server will > detect that the > keys have been compromised. > > For example, it's ok for an authenticator's ports to be identified by > distinct MAC addresses or IP addresses. Since an > authenticator can have > multiple ports. use of a different port authenticator doesn't imply a > different authenticator. But if multiple authenticators with > different > NAS-Identifiers possess the same key, then that indicates > that those keys > have been compromised. > [Joe] This seems somewhat arbitrary to me. A peer could see multiple AAA clients as the same authenticator entity if an attribute other than the NAS-ID is used as the authenticator identity. It seems that we may be overloading NAS identifier. > > > It is possible for problems to arise in situations where the > > > backend server identifies itself differently to the EAP peer > > > and authenticator (e.g. where the Server-Id and backend > authentication > > > server identity differ). > > > >[Joe] It would seem that currently they almost always differ > since the > >back end server is identified by the IP address to the > authenticator and > >by the EAP method to the peer. What problems are you referring to? > > The issue arises in situations where an entity needs to > retrieve a key from > the AAA server. Since all AAA servers can't be assumed to > share a key > cache, the specific server on which the key resides needs to > be identified. > > A peer cannot ask an authenticator to retrieve a key unless > it can provide > both the Key Name and the server from which it needs to be > retrieved. In > effect, the Peer-Id and Server-Id need to be part of the Key Name. > > However, an authenticator cannot retrieve a key from the > server if it has no > way of mapping the Server-Id to a server that it recognizes. > [Joe] It seems that this issue is somewhat out of scope of this document since key caching in AAA is not currently defined. > In Diameter, server can be identified by name, since Diameter > supports > DNS-based service location as well as certificate authentication > (altSubjectName). So if the Server-Id is an FQDN, then the > Diameter client > can reach that server. > > In RADIUS servers are identified only by IP address. So > presumably a RADIUS > server would need to resolve the Server-Id FQDN to an IP > address to figure > out which server to make the key request to. If the > Server-Id and AAA > server FQDN are different then the message may not be deliverable. > > This issue is not purely academic -- it will come up in the > EAPEXT BOF at > IETF 66. > [Joe] OK, sounds interesting. > > > > The following steps enable lower layer identities to be securely > > > verified by all parties: > > > > >[Joe] What does lower layer identities mean in this case? Does this > >mean peer, authenticator and port identities? > > I assume that we're talking about peer and authenticator identities. > Comments below. > > > > [a] Specifying the lower layer parameters used to identify the > > > authenticator and peer; > > It is possible to uniquely identify an authenticator in > multiple ways. For > example, a MAC address could be used, as long as it was > associated with the > entire authenticator and not just a port of it. > > > > [b] Communicating the lower layer identities between the peer and > > > authenticator within phase 0; > > If this is not done, then the peer may not know the > authenticator scope. > > > > [c] Communicating the lower layer authenticator identity > between the > > > authenticator and backend server within the NAS-Identifier > > > attribute; > > So whatever authenticator identity is chosen to be sent to > the peer also > needs to be sent to the backend server. > > >[Joe] Is this necessary or desirable? If the AAA server does not > >already what the NAS-ID associated with the NAS, is it OK > for the NAS to > >assert this? If the NAS can assert whatever it wants why are we > >bothering to do channel bindings? > > RADIUS REQUIRES the NAS to identify itself, using NAS-Identifier, > NAS-IPv6-Address or NAS-IPv4-Address. However, if the NAS > has more than > one IP address, NAS-Identifier makes the most sense, > regardless of any EAP > considerations. If there is a proxy present, then the proxy > needs to > validate the NAS-Identifier; by the time it gets to the AAA > server, it is > not possible to validate it. > [Joe] the question still remains; If no-one is going to validate that the NAS-Identifier actually is within scope of the authenticator then why bother to use it channel bindings? _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From service@intl.paypal.com Mon Jun 12 04:28:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fphmd-00015E-4j for eap-archive@ietf.org; Mon, 12 Jun 2006 04:28:27 -0400 Received: from 207-172-196-196.c3-0.upd-ubr14.trpr-upd.pa.cable.rcn.com ([207.172.196.196] helo=192.168.0.2) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FphmY-00042m-CH for eap-archive@ietf.org; Mon, 12 Jun 2006 04:28:27 -0400 X-Spam-Score: 4.3 (++++) X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 From tknoll@camfab.com Mon Jun 12 10:31:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpnSE-0005sV-Id for eap-archive@ietf.org; Mon, 12 Jun 2006 10:31:46 -0400 Received: from [80.188.193.254] (helo=[80.188.193.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpnSD-0004HC-6A for eap-archive@ietf.org; Mon, 12 Jun 2006 10:31:46 -0400 Message-ID: <78563012.20060612143134@camfab.com> Date: Mon, 12 Jun 2006 14:31:34 -0060 From: "Antone Mullen" Reply-To: "Antone Mullen" To: eap-archive@ietf.org Subject: The Next Gangbuster Growth Stock? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Big News Expected Monday! Infinex Ventures Inc. (INFX) Price: 0.65 Up 18% on Friday 5 day expected price 1.90 Already started to climb. This one did very well during last mar keting campa ign. Very Well! OVERVIEW Aggressive and energetic, In finex boasts a dynamic and diversified portfolio of operations across North America, with an eye on international expansion. Grounded in natural resource exploration, Inifine x also offers investors access to exciting new developments in the high-tech sector and the booming international real estate market. Our market based experience, tenacious research techniques, and razor sharp analytical skills allow us to leverage opportunities in emerging markets and developing technologies. Identifying these opportunities in the earliest stages allows us to accelerate business development and fully realize the company™s true potential. Maximizing overall profitability and in turn enhancing shareholder value. News In finex Announces Extension to Its Agreement in Chile Infin ex Ventures Inc. ("the Company") and its Board of Directors are pleased to announce that the Company has received an extension (90 days) to its Agreement for the due diligence period, in an effort to fully verify the offered title and all additional documentation, including but not limited to, Trial C-1912- 2001 at the 14th Civil Court of Santiago and Criminal Trial 1160-2002 at the 19th Court of Crime of Santiago of Chile, Ministry of Mines of Chile over its sole and exclusive right to acquire a 50% interest in the Tesoro 1-12 Mining Claims. Infi nex Announces Joint Venture and Option Agreement Extension Infinex Ventures Inc. and its Board of Directors are please to announce that the Company has been granted an extension of 120 days to fulfill its contractual obligations under the Joint Venture and Option Agreement dated June 14, 2004 on the Texada Island "Yew Group" Mining Claims: The Yew Claims are located on Texada Island, B.C. This region has a long history of mining dating back to 1876. Several high grade copper gold skarns were mined in the area. The geology of the Yew Claims can be found in MINFILE 092F/516. From bmastgr@01mobile.com Mon Jun 12 12:37:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FppQB-0002ob-Ib for eap-archive@ietf.org; Mon, 12 Jun 2006 12:37:47 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FppQB-00021B-GM for eap-archive@ietf.org; Mon, 12 Jun 2006 12:37:47 -0400 Received: from 112.158.broadband3.iol.cz ([85.70.158.112] helo=hovno) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FppPa-0002jq-0o for eap-archive@ietf.org; Mon, 12 Jun 2006 12:37:46 -0400 Date: Mon, 12 Jun 2006 16:37:09 -0060 From: "Horace Cleveland" X-Mailer: The Bat! (v2.00) Personal Reply-To: "Horace Cleveland" X-Priority: 3 (Normal) Message-ID: <3179555342.20060612163709@01mobile.com> To: eap-archive@ietf.org Subject: FWD: St0kkMarrkett Picks Watch special pr news releaser MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Big Ne ws Exp ected Monday! Infinex Ventures Inc. ( I N F X ) Price: 0.65 Up 18% on Friday 5 day expected price 1.90 Already started to climb. This one did very well during last mar keting campa ign. Very Well! OVERVIEW Aggressive and energetic, In finex boasts a dynamic and diversified portfolio of operations across North America, with an eye on international expansion. Grounded in natural resource exploration, Inifine x also offers investors access to exciting new developments in the high-tech sector and the booming international real estate market. Our market based experience, tenacious research techniques, and razor sharp analytical skills allow us to leverage opportunities in emerging markets and developing technologies. Identifying these opportunities in the earliest stages allows us to accelerate business development and fully realize the company™s true potential. Maximizing overall profitability and in turn enhancing shareholder value. News In finex Announces Extension to Its Agreement in Chile Infin ex Ventures Inc. ("the Company") and its Board of Directors are pleased to announce that the Company has received an extension (90 days) to its Agreement for the due diligence period, in an effort to fully verify the offered title and all additional documentation, including but not limited to, Trial C-1912- 2001 at the 14th Civil Court of Santiago and Criminal Trial 1160-2002 at the 19th Court of Crime of Santiago of Chile, Ministry of Mines of Chile over its sole and exclusive right to acquire a 50% interest in the Tesoro 1-12 Mining Claims. Infi nex Announces Joint Venture and Option Agreement Extension Infinex Ventures Inc. and its Board of Directors are please to announce that the Company has been granted an extension of 120 days to fulfill its contractual obligations under the Joint Venture and Option Agreement dated June 14, 2004 on the Texada Island "Yew Group" Mining Claims: The Yew Claims are located on Texada Island, B.C. This region has a long history of mining dating back to 1876. Several high grade copper gold skarns were mined in the area. The geology of the Yew Claims can be found in MINFILE 092F/516. From boylove@0733.com Mon Jun 12 12:45:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FppXD-0000bo-7M for eap-archive@ietf.org; Mon, 12 Jun 2006 12:45:03 -0400 Received: from [208.233.45.20] (helo=mxs.mail.ru) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FppXB-0002ay-ML for eap-archive@ietf.org; Mon, 12 Jun 2006 12:45:03 -0400 Message-ID: <662161c80604bp3ykbrk915q92yo3vel4ns78el9rth5k3@61.187.98.10> Date: Mon, 12 Jun 2006 16:45:22 +0300 From: "Josh Zavala" To: eap-archive@ietf.org Subject: Make sure your special pr news released MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam: Not detected X-Spam-Score: 2.5 (++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Big Ne ws Exp ected Monday! Infinex Ventures Inc. ( I N F X ) Price: 0.65 Up 18% on Friday 5 day expected price 1.90 Already started to climb. This one did very well during last mar keting campa ign. Very Well! OVERVIEW Aggressive and energetic, In finex boasts a dynamic and diversified portfolio of operations across North America, with an eye on international expansion. Grounded in natural resource exploration, Inifine x also offers investors access to exciting new developments in the high-tech sector and the booming international real estate market. Our market based experience, tenacious research techniques, and razor sharp analytical skills allow us to leverage opportunities in emerging markets and developing technologies. Identifying these opportunities in the earliest stages allows us to accelerate business development and fully realize the company™s true potential. Maximizing overall profitability and in turn enhancing shareholder value. News In finex Announces Extension to Its Agreement in Chile Infin ex Ventures Inc. ("the Company") and its Board of Directors are pleased to announce that the Company has received an extension (90 days) to its Agreement for the due diligence period, in an effort to fully verify the offered title and all additional documentation, including but not limited to, Trial C-1912- 2001 at the 14th Civil Court of Santiago and Criminal Trial 1160-2002 at the 19th Court of Crime of Santiago of Chile, Ministry of Mines of Chile over its sole and exclusive right to acquire a 50% interest in the Tesoro 1-12 Mining Claims. Infi nex Announces Joint Venture and Option Agreement Extension Infinex Ventures Inc. and its Board of Directors are please to announce that the Company has been granted an extension of 120 days to fulfill its contractual obligations under the Joint Venture and Option Agreement dated June 14, 2004 on the Texada Island "Yew Group" Mining Claims: The Yew Claims are located on Texada Island, B.C. This region has a long history of mining dating back to 1876. Several high grade copper gold skarns were mined in the area. The geology of the Yew Claims can be found in MINFILE 092F/516. From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Jun 13 00:34:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq0be-0006M4-TR for eap-archive@lists.ietf.org; Tue, 13 Jun 2006 00:34:22 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq0bd-0000EY-FD for eap-archive@lists.ietf.org; Tue, 13 Jun 2006 00:34:22 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 6F71343012F for ; Mon, 12 Jun 2006 21:34:20 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id AB4054300A2 for ; Mon, 12 Jun 2006 21:34:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 957E61448021 for ; Mon, 12 Jun 2006 21:34:01 -0700 (PDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.199]) by hermes.tigertech.net (Postfix) with ESMTP id A578A1448017 for ; Mon, 12 Jun 2006 21:33:59 -0700 (PDT) Received: by nz-out-0102.google.com with SMTP id k1so1389202nzf for ; Mon, 12 Jun 2006 21:33:58 -0700 (PDT) Received: by 10.36.216.6 with SMTP id o6mr3172060nzg; Mon, 12 Jun 2006 21:33:58 -0700 (PDT) Received: by 10.36.224.31 with HTTP; Mon, 12 Jun 2006 21:33:58 -0700 (PDT) Message-ID: <1ef690c10606122133n640fc36cu9a5234bd2751ab24@mail.gmail.com> Date: Tue, 13 Jun 2006 12:33:58 +0800 From: "Quinn Li" To: "Cao Zhen" , "Lakshminath Dondeti" In-Reply-To: <20060601104249.BB2FE1DA2E@infosec.pku.edu.cn> MIME-Version: 1.0 Content-Disposition: inline References: <20060601104249.BB2FE1DA2E@infosec.pku.edu.cn> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests=RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: "eap@frascone.com" Subject: Re: [eap] Questions for draft-barany-eap-gee-01 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Hi Cao, Lakshminath and Peter, I read the draft and was going to ask the same question about what kind of service GEE supports :). Currently draft have well described its usage in MVNO scenario. But it is still unclear to me how GEE can support other services like IMS, Mobile IPv6, or any other service, you name it. Before further description supplied, I'm holding the opinion that this solution has a quite limited usage in industry and oppose to accept it as a general purpose protocol. Since that problem could be solved by other way. Best regards, Qin On 6/1/06, Cao Zhen wrote: > Hello, Lakshminath and Peter > > Thanks for your reply, > >> These questions seem very 3GPP2 specific, so I will ask folks > >> knowledgeable in 3GPP2 to respond to you offline. > please allow me to ask by following IETF style. > > What kind of service here means, network access (MVNO) or any others > (SIP)? > > If in the case of MVNO, here NAS2 means only for network access? > > Many Thanks, > > Zhen > > -----Original Message----- > From: Lakshminath Dondeti caozhen@infosec.pku.edu.cn > Sent: 2006-05-31 > To: Cao Zhen; eap@frascone.com > Subject: Re: [eap] Questions for draft-barany-eap-gee-01 > > These questions seem very 3GPP2 specific, so I will ask folks > knowledgeable in 3GPP2 to respond to you offline. > > regards, > Lakshminath > > At 07:15 PM 5/25/2006, Cao Zhen wrote: > >Hi Peter, > > > >I have two questions about this draft. > >1) What kind of device you are assuming for NAS2 in 3GPP2: > > such as Home Agent or P-CSCF. > > > >2) Could this solution be applied to 3GPP2 MMD solution? > >suppose NAS2 is a kind of P-CSCF, then could this solution > >establish IPsec SA between mobile station and P-CSCF? > > > >Best Regards > >------------ > >Cao Zhen, Ph.D Candidate > >Information Security Laboratory > >School of Electronics Engineering and Computer Science > >Peking University > >Beijing 100871, P.R.China > > > > > > > > > >_________________________________________________________________ > >To unsubscribe or modify your subscription options, please visit: > >http://lists.frascone.com/mailman/listinfo/eap > > > >Arhives: http://lists.frascone.com/pipermail/eap > > > > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap > > Arhives: http://lists.frascone.com/pipermail/eap > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Jun 13 00:58:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq0yv-000832-2u for eap-archive@lists.ietf.org; Tue, 13 Jun 2006 00:58:25 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq0yu-0004Vc-HC for eap-archive@lists.ietf.org; Tue, 13 Jun 2006 00:58:25 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 2C2284300F1 for ; Mon, 12 Jun 2006 21:58:24 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 8693E4300A2 for ; Mon, 12 Jun 2006 21:57:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7A2AB39802C for ; Mon, 12 Jun 2006 21:57:59 -0700 (PDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by zoidberg.tigertech.net (Postfix) with ESMTP id B814439803B for ; Mon, 12 Jun 2006 21:57:55 -0700 (PDT) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5D4vs5j001504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 12 Jun 2006 21:57:54 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-207.qualcomm.com [10.50.76.207]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5D4voD8002383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 12 Jun 2006 21:57:52 -0700 (PDT) Message-Id: <7.0.1.0.2.20060612214920.040bcad8@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 12 Jun 2006 21:57:50 -0700 To: "Quinn Li" , "Cao Zhen" From: Lakshminath Dondeti In-Reply-To: <1ef690c10606122133n640fc36cu9a5234bd2751ab24@mail.gmail.co m> References: <20060601104249.BB2FE1DA2E@infosec.pku.edu.cn> <1ef690c10606122133n640fc36cu9a5234bd2751ab24@mail.gmail.com> Mime-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: "eap@frascone.com" Subject: Re: [eap] Questions for draft-barany-eap-gee-01 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Hi, GEE is not a general purpose authentication protocol. It is a generic EAP encapsulation mechanism that allows demultiplexing of multiple simultaneous EAP conversations between a peer and an authenticator. You say that the draft does describe the MVNO scenarios well, so I guess we can safely conclude that it does its job then. EAP is not used for IMS or Mobile IPv6 authentication, is it? So, in simple terms, it's not the purpose of the GEE draft to specify support for those services. With your last statement, are you saying that there is another way to demultiplex multiple parallel EAP exchanges? If so, I would like to read about it. Please share the reference. Thanks. regards, Lakshminath At 09:33 PM 6/12/2006, Quinn Li wrote: >Hi Cao, Lakshminath and Peter, > >I read the draft and was going to ask the same question about what >kind of service GEE supports :). Currently draft have well described >its usage in MVNO scenario. But it is still unclear to me how GEE can >support other services like IMS, Mobile IPv6, or any other service, >you name it. > >Before further description supplied, I'm holding the opinion that this >solution has a quite limited usage in industry and oppose to accept it >as a general purpose protocol. Since that problem could be solved by >other way. > >Best regards, >Qin > >On 6/1/06, Cao Zhen wrote: >>Hello, Lakshminath and Peter >> >>Thanks for your reply, >> >> These questions seem very 3GPP2 specific, so I will ask folks >> >> knowledgeable in 3GPP2 to respond to you offline. >>please allow me to ask by following IETF style. >> >>What kind of service here means, network access (MVNO) or any others >>(SIP)? >> >>If in the case of MVNO, here NAS2 means only for network access? >> >>Many Thanks, >> >>Zhen >> >>-----Original Message----- >>From: Lakshminath Dondeti caozhen@infosec.pku.edu.cn >>Sent: 2006-05-31 >>To: Cao Zhen; eap@frascone.com >>Subject: Re: [eap] Questions for draft-barany-eap-gee-01 >> >>These questions seem very 3GPP2 specific, so I will ask folks >>knowledgeable in 3GPP2 to respond to you offline. >> >>regards, >>Lakshminath >> >>At 07:15 PM 5/25/2006, Cao Zhen wrote: >> >Hi Peter, >> > >> >I have two questions about this draft. >> >1) What kind of device you are assuming for NAS2 in 3GPP2: >> > such as Home Agent or P-CSCF. >> > >> >2) Could this solution be applied to 3GPP2 MMD solution? >> >suppose NAS2 is a kind of P-CSCF, then could this solution >> >establish IPsec SA between mobile station and P-CSCF? >> > >> >Best Regards >> >------------ >> >Cao Zhen, Ph.D Candidate >> >Information Security Laboratory >> >School of Electronics Engineering and Computer Science >> >Peking University >> >Beijing 100871, P.R.China >> > >> > >> > >> > >> >_________________________________________________________________ >> >To unsubscribe or modify your subscription options, please visit: >> >http://lists.frascone.com/mailman/listinfo/eap >> > >> >Arhives: http://lists.frascone.com/pipermail/eap >> >> >> >> >> >> >>_________________________________________________________________ >>To unsubscribe or modify your subscription options, please visit: >>http://lists.frascone.com/mailman/listinfo/eap >> >>Arhives: http://lists.frascone.com/pipermail/eap >> _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Jun 13 01:37:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq1ar-0007yI-1H for eap-archive@lists.ietf.org; Tue, 13 Jun 2006 01:37:37 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq1am-0006Go-Ii for eap-archive@lists.ietf.org; Tue, 13 Jun 2006 01:37:37 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id AA110430138 for ; Mon, 12 Jun 2006 22:37:31 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 43BE64300A2 for ; Mon, 12 Jun 2006 22:37:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 27F741448001 for ; Mon, 12 Jun 2006 22:37:16 -0700 (PDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.206]) by hermes.tigertech.net (Postfix) with ESMTP id 42CB7144800D for ; Mon, 12 Jun 2006 22:37:12 -0700 (PDT) Received: by nz-out-0102.google.com with SMTP id k1so1398816nzf for ; Mon, 12 Jun 2006 22:37:12 -0700 (PDT) Received: by 10.37.20.29 with SMTP id x29mr2200852nzi; Mon, 12 Jun 2006 22:37:12 -0700 (PDT) Received: by 10.36.224.31 with HTTP; Mon, 12 Jun 2006 22:37:12 -0700 (PDT) Message-ID: <1ef690c10606122237p4ce33ad4ybc94b5ed6119c0a8@mail.gmail.com> Date: Tue, 13 Jun 2006 13:37:12 +0800 From: "Quinn Li" To: "Lakshminath Dondeti" , "Cao Zhen" In-Reply-To: <7.0.1.0.2.20060612214920.040bcad8@qualcomm.com> MIME-Version: 1.0 Content-Disposition: inline References: <20060601104249.BB2FE1DA2E@infosec.pku.edu.cn> <1ef690c10606122133n640fc36cu9a5234bd2751ab24@mail.gmail.com> <7.0.1.0.2.20060612214920.040bcad8@qualcomm.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests=RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: "eap@frascone.com" Subject: Re: [eap] Questions for draft-barany-eap-gee-01 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Hi Lakshminath, Thank you for your immediate response. My comments are included inline. On 6/13/06, Lakshminath Dondeti wrote: > Hi, > > GEE is not a general purpose authentication protocol. It is a > generic EAP encapsulation mechanism that allows demultiplexing of > multiple simultaneous EAP conversations between a peer and an > authenticator. You say that the draft does describe the MVNO > scenarios well, so I guess we can safely conclude that it does its job then. Yes, I know GEE allows demulitplexing multiple EAP conversation. AFAIK, MVNO is currently the only application for GEE. Do you have any other application in your mind? > > EAP is not used for IMS or Mobile IPv6 authentication, is it? So, in > simple terms, it's not the purpose of the GEE draft to specify > support for those services. Not exactly, EAP is supported in Mobile IPv6 authentication. Please refer to section 8 "The use of EAP authentication" in draft-ietf-mip6-ikev2-ipsec. Does that mean GEE draft can support services like Mobile IPv6 as long as it uses EAP authentication? But How? > > With your last statement, are you saying that there is another way to > demultiplex multiple parallel EAP exchanges? If so, I would like to > read about it. Please share the reference. Thanks. By another way, I mean in most circumstances except MVNO, multiple parallel EAP exchange can be demultiplexed by the underlying protocol of EAP. For example, if you want to have two Mobile IPv6 authentication done simultaneously, you can initiate two IKE with two different Home Agent. > snip Thanks Qin _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From kyliehgkd@hotmail.com Tue Jun 13 01:54:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq1rD-0007Wc-Jj for eap-archive@ietf.org; Tue, 13 Jun 2006 01:54:31 -0400 Received: from [211.204.250.42] (helo=CABIN) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq1rA-0007je-Bo for eap-archive@ietf.org; Tue, 13 Jun 2006 01:54:31 -0400 Message-ID: <63823597089959.9E69CF25C7@E74UI3KA> From: "Willie" To: Subject: vast lift pay attention to the announcement Date: Tue, 13 Jun 2006 14:53:49 +0900 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: ZPyUm7ste0B3JtVgNI4P4usWsrKdyGSiM94S Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.7 (++) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a

Expert stockk suggestions and recommendations
Allert Issued - Watch FCYI.PK Trade Today!
Falcon Energy, Inc.
SYMBOL: FCYI.PK
Current Price: 1.02
Global score: EXCELLENT !
Investor Action: BUY FAST !

Before we start with the profile of FCYI.PK we would like to mention something very important: A Big PR Campaign is moving this week . And it will go all week so it would be best to get in Now.

Recent News


VANCOUVER, British Columbia--(BUSINESS WIRE)--June 9, 2006--Falcon Energy, Inc. (Pinnk Sheeets:FCYI.PK - News) is pleased to announce that it has fully acquired the exploration licenses for five mining properties in the mineral rich region of Mongolia. Management felt that the opportunity presented by these properties was significant enough to forgo a planned participation by a second resource company. These licenses will be held for a minimum of three years and grant Falcon Energy Inc. access to the mineral rights for the licensed properties. Exploitable mineral resources found in the area in which the licenses are held include: Gold, base metals such as Copper, Molybdenum, Lead and Zinc as well as Fluorite and Uranium.

Gas production continues steadily from Falcon Energy's Richmount Westlock property in Alberta, Canada. This opportunity has proven itself out as the property and investment have benefited from the surge in natural gas prices since the well was first tied in May of 2005. The market price (NYMEX) for natural gas at that time was approximately $6.50 per MMBTU but in the last year prices stayed over 10.00 per MMBTU for a 5 month period with several spikes above the $14.00 range. The company is pleased that the investment continues to provide consistent revenue for the company and its shareholders.

Falcon Energy Inc. has also announced that due to the confirmed addition of its mining exploration properties in Mongolia, that it will shortly be expanding the executive team to assist in managing this new opportunity. Details will be forthcoming.


Advanced stoock analysis and profit-boosting techniques

Conclusion:


The Examples Above Show The Awesome, Earning Potential of Little Known Companies That Explode Onto Investor's Radar Screens; Many of You Are Already Familiar with This. Is FCYI.PK Poised and Positioned to Do that For You? Then You May Feel the Time Has Come to Act... And Please Watch this One Trade tomorrow! Go FCYI.PK.

Efficient approach to investing from sttock professionals

..............
Every step of life is a risk Mother knows best In a battle between elephants, the ants get squashed Catch not at the shadow and lose the substance The modem is the message.

Don't count your chickens before they're hatched . A sly rabbit will have three openings to its den. Two heads are better than one A place for everything and everything in its place.



Always yield to temptation, because it may not pass your way again. The best things come in small packages Let them be only thine own, and not strangers' with thee. Live to the point of tears Absence makes the heart grow fonder. Every bird loves to hear himself sing Great starts make great finishes. If you believe everything you read, you better not read
Good broth may be made in an old pot Happiness is wanting what you have - not having what you want All good things come to he who waits The best of men are but men at best For that they hated knowledge, and did not choose the fear of the LORD. When a fool is silent, he too is counted among the wise Time and tide wait for no man.

From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Jun 13 03:23:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq3Fm-0004Qq-Ev for eap-archive@lists.ietf.org; Tue, 13 Jun 2006 03:23:58 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq3Fk-0000GP-Up for eap-archive@lists.ietf.org; Tue, 13 Jun 2006 03:23:58 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5943E43012F for ; Tue, 13 Jun 2006 00:23:56 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 8E3804300A2 for ; Tue, 13 Jun 2006 00:23:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7F53C39802C for ; Tue, 13 Jun 2006 00:23:42 -0700 (PDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by zoidberg.tigertech.net (Postfix) with ESMTP id B1FE339800D for ; Tue, 13 Jun 2006 00:23:38 -0700 (PDT) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5D7NaEK011896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 13 Jun 2006 00:23:37 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-207.qualcomm.com [10.50.76.207]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5D7NXC5021639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 Jun 2006 00:23:35 -0700 (PDT) Message-Id: <7.0.1.0.2.20060612224559.0402b818@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 13 Jun 2006 00:01:53 -0700 To: "Quinn Li" , "Cao Zhen" From: Lakshminath Dondeti In-Reply-To: <1ef690c10606122237p4ce33ad4ybc94b5ed6119c0a8@mail.gmail.co m> References: <20060601104249.BB2FE1DA2E@infosec.pku.edu.cn> <1ef690c10606122133n640fc36cu9a5234bd2751ab24@mail.gmail.com> <7.0.1.0.2.20060612214920.040bcad8@qualcomm.com> <1ef690c10606122237p4ce33ad4ybc94b5ed6119c0a8@mail.gmail.com> Mime-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: "eap@frascone.com" Subject: Re: [eap] Questions for draft-barany-eap-gee-01 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Thanks for the explanation. IKEv2 and the use of EAP with that protocol brings up some interesting issues to fore, and GEE is no exception. One of the other issues for example is the use of the MSK is different. At 10:37 PM 6/12/2006, Quinn Li wrote: >Hi Lakshminath, > >Thank you for your immediate response. >My comments are included inline. > >On 6/13/06, Lakshminath Dondeti wrote: >>Hi, >> >>GEE is not a general purpose authentication protocol. It is a >>generic EAP encapsulation mechanism that allows demultiplexing of >>multiple simultaneous EAP conversations between a peer and an >>authenticator. You say that the draft does describe the MVNO >>scenarios well, so I guess we can safely conclude that it does its job then. >Yes, I know GEE allows demulitplexing multiple EAP conversation. >AFAIK, MVNO is currently the only application for GEE. Do you have any >other application in your mind? > >> >>EAP is not used for IMS or Mobile IPv6 authentication, is it? So, in >>simple terms, it's not the purpose of the GEE draft to specify >>support for those services. >Not exactly, EAP is supported in Mobile IPv6 authentication. Right, sorry for the oversight. I sort of missed the IKEv2-EAP use case there, although I wonder whether the point about the same authenticator having to demultiplex multiple EAP conversations applies. The other thing to think about is whether the EP would be the same for the multiple authentications. >Please >refer to section 8 "The use of EAP authentication" in >draft-ietf-mip6-ikev2-ipsec. Does that mean GEE draft can support >services like Mobile IPv6 as long as it uses EAP authentication? But >How? You seem to be answering this question yourself, below. Please see there for some more thoughts from my end. >>With your last statement, are you saying that there is another way to >>demultiplex multiple parallel EAP exchanges? If so, I would like to >>read about it. Please share the reference. Thanks. >By another way, I mean in most circumstances except MVNO, multiple >parallel EAP exchange can be demultiplexed by the underlying protocol >of EAP. I am not sure whether that is the case in most circumstances, but IKEv2 might be an exception, although I will point out that there doesn't seem to be a need for multiple simultaneous EAP authentications in case of IKEv2. Perhaps you have a use case in mind? >For example, if you want to have two Mobile IPv6 >authentication done simultaneously, you can initiate two IKE with two >different Home Agent. This goes to my point earlier about the authenticators being different and/or EPs being different too. If the same authenticator using IKEv2 has a use case to run multiple simultaneous EAP authentications, the IKEv2-EAP specification would need to be changed to signal it, but GEE could very much be part of the solution to demultiplex the multiple EAP runs. If there are multiple IKEv2 sessions, you are right, the IKEv2 SA can be used to demultiplex, but binding the two EAP authentications might be difficult, so the multiple IKEv2 sessions might not be a viable solution for multiple parallel EAP authentications and enforcement thereof. regards, Lakshminath >>snip > >Thanks >Qin _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Jun 13 05:58:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq5fQ-00067Q-It for eap-archive@lists.ietf.org; Tue, 13 Jun 2006 05:58:36 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq5fP-0007Qm-5D for eap-archive@lists.ietf.org; Tue, 13 Jun 2006 05:58:36 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 45276430116 for ; Tue, 13 Jun 2006 02:58:34 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 83B854300A2 for ; Tue, 13 Jun 2006 02:58:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 645EB430D5A for ; Tue, 13 Jun 2006 02:58:18 -0700 (PDT) X-Greylist-Status: Sender first seen 00:06:38 ago Received: from hitachi.cn (static-ip-10-194-65-202.rev.dyxnet.com [202.65.194.10]) by hermes.tigertech.net (Postfix) with SMTP id 01A80430D5B for ; Tue, 13 Jun 2006 02:58:14 -0700 (PDT) Received: (qmail 27376 invoked from network); 13 Jun 2006 09:51:33 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk1;24962eb73351e5644d58d10f016c1154; Received: from unknown (HELO hitachihk5.hitachi.cn) (170.95.94.1)by static-ip-11-194-65-202.rev.dyxnet.com with SMTP; 13 Jun 2006 09:51:33 -0000 Received: (qmail 15850 invoked from network); 13 Jun 2006 09:51:33 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk5;ad28c0943b7dde94d1bb9d315a30dd6c; Received: from hchidc204.hitachi-china.com (HELO hchidc204.hitachi.cn) (170.95.82.6)by 172.16.10.9 with SMTP; 13 Jun 2006 09:51:33 -0000 Received: from hcbjdc2.hitachi.cn ([170.95.81.2]) by hchidc204.hitachi.cn with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Jun 2006 17:51:32 +0800 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 13 Jun 2006 17:51:31 +0800 Message-ID: <834B54D356AA8F46B9B233DD88BEAA38FD20A0@hcbjdc2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Time slots for next ietf meeting Thread-Index: AcaOu2SfJd8hBB00SVGcifIR/G6etQAE2gLA From: "+ACI-DENG, HUI -HCHBJ+ACI-" To: X-OriginalArrivalTime: 13 Jun 2006 09:51:32.0625 (UTC) FILETIME=[F37F4810:01C68ECE] X-Scanned-By-hitachihk5: Virus scan performed by network-box X-Scanned-By-hitachihk5: Scanner file id is hitachihk5-1150192293.271-15847-000 X-Scanned-By-hitachihk5: No known viruses found in message (received+scanned in 0.01/0.05 secs) X-Scanned-By-hitachihk5: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Scanned-By-hitachihk1: Virus scan performed by network-box X-Scanned-By-hitachihk1: Scanner file id is hitachihk1-1150192293.465-27373-000 X-Scanned-By-hitachihk1: No known viruses found in message (received+scanned in 0.01/0.01 secs) X-Scanned-By-hitachihk1: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Scanned-By-hitachihk1: Whitelisted with valid signature (outbound via Network Box hitachihk5) X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=FORGED_RCVD_HELO, RCVD_BY_IP X-Spam-Level: Subject: [eap] Time slots for next ietf meeting X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Hello, all I checked schdule there, there will be no time slots during next ietf meeting? how about eap extension bof? thanks -Hui Disclaimer: The contents of this e-mail, and its attachments, if any, are confidential and may be protected by law against any unauthorized use. If you have received this e-mail by mistake or have reason to believe that you are not the intended recipient, please notify the sender by reply e-mail as soon as possible and delete it from your computer system immediately thereafter. If you are not the intended recipient, you must not copy this e-mail or attachment or disclose the contents to any other person. While we have made every effort to keep our network virus free, we take no responsibility for any computer virus which might be transferred by way of this e-mail. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Jun 13 09:32:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq90o-0006OH-RS for eap-archive@lists.ietf.org; Tue, 13 Jun 2006 09:32:54 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq90n-0002Ru-CA for eap-archive@lists.ietf.org; Tue, 13 Jun 2006 09:32:54 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id BFC5A4300FE for ; Tue, 13 Jun 2006 06:32:52 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id C4A384300E4 for ; Tue, 13 Jun 2006 06:32:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id A773B398056 for ; Tue, 13 Jun 2006 06:32:32 -0700 (PDT) X-Greylist-Status: Sender first seen 03:40:53 ago Received: from hitachi.cn (static-ip-10-194-65-202.rev.dyxnet.com [202.65.194.10]) by zoidberg.tigertech.net (Postfix) with SMTP id 0687339801D for ; Tue, 13 Jun 2006 06:32:26 -0700 (PDT) Received: (qmail 2468 invoked from network); 13 Jun 2006 13:32:24 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk1;7ffd2424934ade30010ffef1f3ef13b3; Received: from unknown (HELO hitachihk5.hitachi.cn) (170.95.94.1)by static-ip-11-194-65-202.rev.dyxnet.com with SMTP; 13 Jun 2006 13:32:24 -0000 Received: (qmail 29576 invoked from network); 13 Jun 2006 13:32:24 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk5;22a33255f5042147000cb42aa319c362; Received: from hchidc204.hitachi-china.com (HELO hchidc204.hitachi.cn) (170.95.82.6)by 172.16.10.9 with SMTP; 13 Jun 2006 13:32:24 -0000 Received: from hcbjdc2.hitachi.cn ([170.95.81.2]) by hchidc204.hitachi.cn with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Jun 2006 21:32:22 +0800 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 13 Jun 2006 21:32:20 +0800 Message-ID: <834B54D356AA8F46B9B233DD88BEAA38019234B8@hcbjdc2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: +AFs-eap+AF0- Questions for draft-barany-eap-gee-01 Thread-Index: AcaOu2SfJd8hBB00SVGcifIR/G6etQAL9pWQ From: "+ACI-DENG, HUI -HCHBJ+ACI-" To: "Lakshminath Dondeti" , "Quinn Li" , "Cao Zhen" X-OriginalArrivalTime: 13 Jun 2006 13:32:22.0662 (UTC) FILETIME=[CD227A60:01C68EED] X-Scanned-By-hitachihk5: Virus scan performed by network-box X-Scanned-By-hitachihk5: Scanner file id is hitachihk5-1150205544.300-29572-000 X-Scanned-By-hitachihk5: No known viruses found in message (received+scanned in 0.02/0.06 secs) X-Scanned-By-hitachihk5: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Scanned-By-hitachihk1: Virus scan performed by network-box X-Scanned-By-hitachihk1: Scanner file id is hitachihk1-1150205544.770-2463-000 X-Scanned-By-hitachihk1: No known viruses found in message (received+scanned in 0.01/0.01 secs) X-Scanned-By-hitachihk1: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Scanned-By-hitachihk1: Whitelisted with valid signature (outbound via Network Box hitachihk5) X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.074 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO, RCVD_BY_IP X-Spam-Level: Cc: eap@frascone.com Subject: Re: [eap] +AFs-eap+AF0- Questions for draft-barany-eap-gee-01 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f > >>GEE is not a general purpose authentication protocol. It > is a generic > >>EAP encapsulation mechanism that allows demultiplexing of multiple > >>simultaneous EAP conversations between a peer and an > authenticator. > >>You say that the draft does describe the MVNO scenarios well, so I > >>guess we can safely conclude that it does its job then. > >Yes, I know GEE allows demulitplexing multiple EAP > conversation. AFAIK, > >MVNO is currently the only application for GEE. Do you have > any other > >application in your mind? Here no reply for author's company, so I suppose there will be no any other applications existed. it means GEE could only be used for network access scenario, and doesnt support any service. It also means EAP demultiplexing is only needed for network acess. So the application will be quite narrow, I could not understand why this solution could be accepted by WG. -Hui Disclaimer: The contents of this e-mail, and its attachments, if any, are confidential and may be protected by law against any unauthorized use. If you have received this e-mail by mistake or have reason to believe that you are not the intended recipient, please notify the sender by reply e-mail as soon as possible and delete it from your computer system immediately thereafter. If you are not the intended recipient, you must not copy this e-mail or attachment or disclose the contents to any other person. While we have made every effort to keep our network virus free, we take no responsibility for any computer virus which might be transferred by way of this e-mail. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Jun 13 14:19:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqDTl-0006w9-7V for eap-archive@lists.ietf.org; Tue, 13 Jun 2006 14:19:05 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqDTj-0006hV-N5 for eap-archive@lists.ietf.org; Tue, 13 Jun 2006 14:19:05 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 19EC04300F1 for ; Tue, 13 Jun 2006 11:19:03 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 6EF314300E7 for ; Tue, 13 Jun 2006 11:18:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5F06E398053 for ; Tue, 13 Jun 2006 11:18:49 -0700 (PDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7999A398033 for ; Tue, 13 Jun 2006 11:18:46 -0700 (PDT) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5DIIhWo031494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 13 Jun 2006 11:18:45 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5DIIGMS016466; Tue, 13 Jun 2006 11:18:38 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Jun 2006 11:18:36 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 Jun 2006 11:18:36 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB849993F9@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] +AFs-eap+AF0- Questions for draft-barany-eap-gee-01 Thread-Index: AcaOu2SfJd8hBB00SVGcifIR/G6etQAL9pWQAApxkyA= From: "Narayanan, Vidya" To: "+ACI-DENG, HUI -HCHBJ+ACI-" , "Dondeti, Lakshminath" , "Quinn Li" , "Cao Zhen" X-OriginalArrivalTime: 13 Jun 2006 18:18:36.0531 (UTC) FILETIME=[C98EEC30:01C68F15] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com Subject: Re: [eap] +AFs-eap+AF0- Questions for draft-barany-eap-gee-01 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 > > > > >>GEE is not a general purpose authentication protocol. It > > is a generic > > >>EAP encapsulation mechanism that allows demultiplexing of > multiple > > >>simultaneous EAP conversations between a peer and an > > authenticator. > > >>You say that the draft does describe the MVNO scenarios > well, so I > > >>guess we can safely conclude that it does its job then. > > >Yes, I know GEE allows demulitplexing multiple EAP > > conversation. AFAIK, > > >MVNO is currently the only application for GEE. Do you have > > any other > > >application in your mind? > > Here no reply for author's company, > so I suppose there will be no any other applications existed. > it means GEE could only be used for network access scenario, > and doesnt support any service. > It also means EAP demultiplexing is only needed for network acess. > So the application will be quite narrow, > I could not understand why this solution could be accepted by WG. > GEE is not an authentication protocol, as you have correctly understood. Anything that requires parallel runs of two EAP sessions can use GEE - the only lower layer that doesn't need this is IKEv2 (since it does much beyond functioning just as an EAP lower layer). All other lower layers need a mechanism like GEE to demultiplex the parallel EAP exchanges. Examples of usage scenarios can be MVNO-based network access, device and user authentication, etc. The MVNO case has been identified as the one that immediately requires a solution - hence, GEEv0 has been tailored for this. However, the protocol has been written in an extensible manner (the current draft has details on how GEEv1 can extend the protocol for generic multiple EAP authentications) - so, future versions of GEE can support multiple EAP exchanges for other purposes as well. Hope that helps. Regards, Vidya _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Jun 13 14:29:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqDdy-0002eY-Pk for eap-archive@lists.ietf.org; Tue, 13 Jun 2006 14:29:38 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqDdx-0006vV-D1 for eap-archive@lists.ietf.org; Tue, 13 Jun 2006 14:29:38 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 0CCBE43013B for ; Tue, 13 Jun 2006 11:29:37 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 7E2D94300E7 for ; Tue, 13 Jun 2006 11:29:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6A929398051 for ; Tue, 13 Jun 2006 11:29:23 -0700 (PDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by zoidberg.tigertech.net (Postfix) with ESMTP id BFD5F39804C for ; Tue, 13 Jun 2006 11:29:20 -0700 (PDT) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5DITJX9032445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 13 Jun 2006 11:29:20 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5DITIQ4024438; Tue, 13 Jun 2006 11:29:19 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Jun 2006 11:29:18 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 Jun 2006 11:29:17 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB84999411@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Time slots for next ietf meeting Thread-Index: AcaOu2SfJd8hBB00SVGcifIR/G6etQAE2gLAABIPLSA= From: "Narayanan, Vidya" To: "+ACI-DENG, HUI -HCHBJ+ACI-" , X-OriginalArrivalTime: 13 Jun 2006 18:29:19.0008 (UTC) FILETIME=[48812200:01C68F17] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: Re: [eap] Time slots for next ietf meeting X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 > > Hello, all > > I checked schdule there, there will be no time slots during > next ietf meeting? > how about eap extension bof? > The EAP Extension BoF will meet under the HOAKEY name (it merges the EAPExt and HOKEYP efforts) in Montreal. We will post some details soon to the EAPExt mailing list. Thanks, Vidya _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Jun 13 16:14:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqFHn-0001kp-Iq for eap-archive@lists.ietf.org; Tue, 13 Jun 2006 16:14:51 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqFHm-0002JE-6x for eap-archive@lists.ietf.org; Tue, 13 Jun 2006 16:14:51 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4B435430118 for ; Tue, 13 Jun 2006 13:14:49 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id C1DC34300E8 for ; Tue, 13 Jun 2006 13:14:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id B197F398033 for ; Tue, 13 Jun 2006 13:14:37 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [217.160.230.40]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8949539804C for ; Tue, 13 Jun 2006 13:14:33 -0700 (PDT) Received: from [207.62.244.189] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrelayus0) with ESMTP (Nemesis), id 0MKoyl-1FqFHC3p4u-0002jb; Tue, 13 Jun 2006 16:14:20 -0400 From: "Alper Yegin" To: "'Lakshminath Dondeti'" , "'Quinn Li'" , "'Cao Zhen'" Date: Tue, 13 Jun 2006 13:13:56 -0700 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 thread-index: AcaOpf4SczuCz8oYQZSmgOugk+YlhwAf0pbw In-Reply-To: <7.0.1.0.2.20060612214920.040bcad8@qualcomm.com> Message-ID: <0MKoyl-1FqFHC3p4u-0002jb@mrelay.perfora.net> X-Provags-ID: perfora.net abuse@perfora.net login:abf7a4bb310ea4dfc9b6841113e2970f X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com Subject: Re: [eap] Questions for draft-barany-eap-gee-01 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f > With your last statement, are you saying that there is another way to > demultiplex multiple parallel EAP exchanges? If so, I would like to > read about it. Please share the reference. Thanks. I don't see any inherent problems with an EAP lower layer performing such multiplexing, if they are really after such an optimization. Especially not to the extent that one needs to design a new layer to solve the problem. Alper _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Jun 13 16:36:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqFcu-0002Li-3H for eap-archive@lists.ietf.org; Tue, 13 Jun 2006 16:36:40 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqFcs-0003UB-La for eap-archive@lists.ietf.org; Tue, 13 Jun 2006 16:36:40 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 53C1843013E for ; Tue, 13 Jun 2006 13:36:38 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 96B954300E8 for ; Tue, 13 Jun 2006 13:36:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 84382398033 for ; Tue, 13 Jun 2006 13:36:25 -0700 (PDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by zoidberg.tigertech.net (Postfix) with ESMTP id D8DC339800C for ; Tue, 13 Jun 2006 13:36:22 -0700 (PDT) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5DKaKRe013204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 13 Jun 2006 13:36:21 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-64-190.qualcomm.com [10.50.64.190]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5DKaFdp005331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 Jun 2006 13:36:18 -0700 (PDT) Message-Id: <7.0.1.0.2.20060613130519.069c4490@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 13 Jun 2006 13:36:22 -0700 To: "+ACI-DENG, HUI -HCHBJ+ACI-" , "Quinn Li" , "Cao Zhen" From: Lakshminath Dondeti In-Reply-To: <2EBB8025B6D1BA41B567DB32C1D8DB849993F9@NAEX06.na.qualcomm. com> References: <2EBB8025B6D1BA41B567DB32C1D8DB849993F9@NAEX06.na.qualcomm.com> Mime-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com Subject: Re: [eap] +AFs-eap+AF0- Questions for draft-barany-eap-gee-01 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c At 11:18 AM 6/13/2006, Narayanan, Vidya wrote: > > > > > > > >>GEE is not a general purpose authentication protocol. It > > > is a generic > > > >>EAP encapsulation mechanism that allows demultiplexing of > > multiple > > > >>simultaneous EAP conversations between a peer and an > > > authenticator. > > > >>You say that the draft does describe the MVNO scenarios > > well, so I > > > >>guess we can safely conclude that it does its job then. > > > >Yes, I know GEE allows demulitplexing multiple EAP > > > conversation. AFAIK, > > > >MVNO is currently the only application for GEE. Do you have > > > any other > > > >application in your mind? > > > > Here no reply for author's company, Let's keep this at individual level, please. I said that the GEE encapsulation is generic, also more on the applicability below. > > so I suppose there will be no any other applications existed. > > it means GEE could only be used for network access scenario, > > and doesnt support any service. > > It also means EAP demultiplexing is only needed for network acess. > > So the application will be quite narrow, > > I could not understand why this solution could be accepted by WG. > > Adding to Vidya's notes, I would like to make a rather simple observation. EAP is after all at its core for access authentication. GEE supports demultiplexing of multiple parallel EAP conversations, for instance L2 access plus L3 access, and device plus user access authentications. So, GEE has the same/similar scope as EAP. Sure, we identified the IKEv2 case as special, but that is so in various ways, and not just on GEE, compared to many other lower layers. regards, Lakshminath >GEE is not an authentication protocol, as you have correctly understood. >Anything that requires parallel runs of two EAP sessions can use GEE - >the only lower layer that doesn't need this is IKEv2 (since it does much >beyond functioning just as an EAP lower layer). All other lower layers >need a mechanism like GEE to demultiplex the parallel EAP exchanges. >Examples of usage scenarios can be MVNO-based network access, device and >user authentication, etc. The MVNO case has been identified as the one >that immediately requires a solution - hence, GEEv0 has been tailored >for this. However, the protocol has been written in an extensible manner >(the current draft has details on how GEEv1 can extend the protocol for >generic multiple EAP authentications) - so, future versions of GEE can >support multiple EAP exchanges for other purposes as well. > >Hope that helps. > >Regards, >Vidya _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Jun 13 16:43:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqFjO-0007SB-1K for eap-archive@lists.ietf.org; Tue, 13 Jun 2006 16:43:22 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqFjM-000520-Kg for eap-archive@lists.ietf.org; Tue, 13 Jun 2006 16:43:22 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 3FD2B430120 for ; Tue, 13 Jun 2006 13:43:20 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 75CCD4300E8 for ; Tue, 13 Jun 2006 13:43:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 615F9144804B for ; Tue, 13 Jun 2006 13:43:06 -0700 (PDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by hermes.tigertech.net (Postfix) with ESMTP id B6C721448049 for ; Tue, 13 Jun 2006 13:43:03 -0700 (PDT) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5DKh1si015437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 13 Jun 2006 13:43:02 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-64-190.qualcomm.com [10.50.64.190]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5DKgv12010370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 Jun 2006 13:42:59 -0700 (PDT) Message-Id: <7.0.1.0.2.20060613133646.069c4348@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 13 Jun 2006 13:43:05 -0700 To: "Alper Yegin" , "'Quinn Li'" , "'Cao Zhen'" From: Lakshminath Dondeti In-Reply-To: <0MKoyl-1FqFHC3p4u-0002jb@mrelay.perfora.net> References: <7.0.1.0.2.20060612214920.040bcad8@qualcomm.com> <0MKoyl-1FqFHC3p4u-0002jb@mrelay.perfora.net> Mime-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: eap@frascone.com Subject: Re: [eap] Questions for draft-barany-eap-gee-01 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 At 01:13 PM 6/13/2006, Alper Yegin wrote: > > With your last statement, are you saying that there is another way to > > demultiplex multiple parallel EAP exchanges? If so, I would like to > > read about it. Please share the reference. Thanks. > >I don't see any inherent problems with an EAP lower layer performing such >multiplexing, if they are really after such an optimization. The advantage of doing this at the IETF is to design it at the EAP level and allow use by multiple lower layers and multiple purposes. The original authors had one use case, Joe and Parviz joined us with another use case. Designing support for multiple EAP conversations is not new at the IETF. All that GEE is doing is adding support for parallel authentications. >Especially not >to the extent that one needs to design a new layer to solve the problem. No, GEE is *not* another "layer." If EAP had an extra field in the header, GEE might not have been needed. best, Lakshminath > >Alper _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From shelley@drizzle.com Wed Jun 14 00:25:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqMwE-0007zA-HQ for eap-archive@ietf.org; Wed, 14 Jun 2006 00:25:06 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqMwE-000245-F4; Wed, 14 Jun 2006 00:25:06 -0400 Received: from pool-71-98-5-171.mdsnwi.dsl-w.verizon.net ([71.98.5.171] helo=DONPC) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FqMwB-0002FM-3R; Wed, 14 Jun 2006 00:25:05 -0400 Received: from unknown (HELO smtpin.drizzle.com) (216.162.192.23) by DONPC with SMTP; Tue, 13 Jun 2006 23:20:43 +0600 From: "Daryl Medina" To: Subject: Financial news Date: Tue, 13 Jun 2006 23:20:43 +0600 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: QxRxJG8UtiKnygwbEkMpsPi0CQT7eaerYjoa Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.3 (++++) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Get C,T,X,E First Thing Today, This Is Going To Explode! Check out for HOT NEWS!!! C T X E - C A N T E X E N E R G Y C O R P CURRENT_PRICE: $0.50 GET IT N0W! Before we start with the profile of CANM we would like to mention something very important: There is a Big PR Campaign starting this weeek . And it will go all week so it would be best to get in NOW. Company Profile Cantex Energy Corporation is an independent, managed risk, oil and gas exploration, development, and production company headquartered in San Antonio, Texas. Recent News Cantex Energy Corp. (C*T*X*E* - News) announced that the seismic crews have been mobilized and the 40 miles of seismic work has commenced on the Big Canyon Prospect targeting the eastern Val Verde Basin. The crew started operations on Friday June 2 2006. They have been moving over the terrain better than expected and the first of three lines should be completed by weeks end. Data then will be sent off for processing taking 3 to 4 weeks. The eastern Val Verde Basin is viewed by industry experts as perhaps one of the Lower 48's most under-explored, proven gas provinces. Trace Maurin, President of C a n t e x E n e r g y Corp., stated, "The Val Verde Basin offers a significant, under-explored natural gas resource 0pp0rtunity for new and emerging players. The seismic data available currently becomes a distinct competitive advantage to evaluate what has not been seen before. There are at least a dozen active players in the basin now and an unknown number of additional players likely awaiting some incentive or 0pp0rtunity to gain a competitive advantage, and we believe that our geophysical experts at Providence Technologies have the capability and expertise to provide us that advantage. Needless-to-say, we are anxiously looking forward to the ongoing seismic data reports over the next several weeks." For more inf0rmati0n, refer to the entire news for the company announced on June 6. Conclusion: The Examples Above Show The Awesome, Earning Potential of Little Known Companies That Explode Onto Investor's Radar Screens; Many of You Are Already Familiar with This. Is C T X E Poised and Positioned to Do that For You? Then You May Feel the Time Has Come to Act... And Please Watch this One Trade tomorrow! Go C,T,X,E. Penny stocks are considered highly speculative and may be unsuitable for all but very aggressive investors. This Profile is not in any way affiliated with the featured company. This report is for entertainment and advertising purposes only and should not be used as investment advice. If you wish to stop future mailings, or if you feel you have been wrongfully placed in our membership, send a blank e mail with No Thanks in the sub ject to ---------- destroy apparent allele adulterous appraise cyclotomic addison afield bijection belies airlock colonial backgammon bladder cretin archbishop anteroom curd clint actaeon argonaut diction boeing berkeley abigail clammy apex butane cocky alaska chokeberry catch bake bonaparte decisionmake From LydiaSierra@legislator.com Wed Jun 14 03:52:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqQB7-0008JS-TM for eap-archive@ietf.org; Wed, 14 Jun 2006 03:52:41 -0400 Received: from [192.116.242.129] (helo=zd6ut.fpadnoai.aol.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqQB6-0004Ku-Hr; Wed, 14 Jun 2006 03:52:41 -0400 Message-ID: <95250901056502.C3B74A520A@JAE6U> From: "Lydia Sierra" To: Subject: huge take-off on OTC, read an announcement Date: Wen, 14 Jun 2006 09:52:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 What makes a good trader? Positive approach, skill, knowing the right things and luck. I may not be able to help you with all these, but here are some right things which will help. Get C T X E . P K First Thing Today This Is Going To Explode! C T X E . P K - C a n t e x E n e r g y C o r p Global score: Excellent| Mean Recommendation: Srtong Byu| Investor Action:Buy Fsat| Current Price: $0.51 Get it Now! Beofre we satrt wtih the proifle of C T X E . P K we wolud lkie to mentino something vrey impotrant: Tehre is a Big PR Capmaign satrting tihs week . And it wlil go all week so it wolud be bset to get in Nwo. Company Profile: C a n t e x E n e r g y C o r poraiton is an idnependent, manaegd rsik, oil and gas expolration, developemnt, and prdouction cmopany heaqduartered in San Anotnio, Txeas. Recent News: C a n t e x E n e r g y C o r p. (C T X E . P K - Nwes) annuonced taht the siesmic cerws hvae been mboilized and the 40 mlies of seimsic wrok has comemnced on the Big Caynon Prosepct trageting the eastren Val Vedre Bsain. The cerw strated operatoins on Friady Jnue 2 2060. Tehy hvae been mvoing oevr the trerain bteter tahn expceted and the fisrt of trhee lnies sholud be complteed by wekes edn. Dtaa tehn wlil be snet off for processing taknig 3 to 4 weeks. The esatern Val Vrede Bsain is vieewd by indutsry exeprts as prehaps one of the Loewr 4'8s msot under-exploerd, proevn gas proivnces. Tarce Muarin, Preisdent of C a n t e x E n e r g y C o r p., satted, "hTe Val Vrede Bsain ofefrs a significnat, under-exlpored natuarl gas resuorce opportnuity for new and eemrging laeyrs. The sesimic dtaa avaliable currenlty becoems a distnict cmopetitive advantgae to evalaute waht has not been seen bfeore. Three are at lesat a doezn actvie palyers in the baisn now and an uknnown nubmer of additoinal palyers liekly awiating smoe incenitve or opprptunity to gian a compeittive adavntage, and we beileve taht our geophyscial exeprts at Proivdence Tecnhologies hvae the cpaability and epxertise to prvoide us taht advanatge. Needles-sto-say, we are anixously lokoing fowrard to the ongonig sesimic dtaa reoprts oevr the nxet sevearl weesk." For more information, refer to the entire news for the company announced on June 6. Conclusion: The Examples Above Show The Awesome, Earning Potential of Little Known Companies That Explode Onto Investor's Radar Screens; Many of You Are Already Familiar with This. Is C T X E . P K Poised and Positioned to Do that For You? Then You May Feel the Time Has Come to Act... And Please Watch this One Trade tomorrow! Go C T X E . P K. ___________________ Great oaks from little acorns grow A man is known by the company he keeps. Past cure, past care Wise children have short years To whom God gives, to him also the people give His own iniquities shall take the wicked himself, and he shall be holden with the cords of his sins. Listen to advice and accept instruction, and in the end you will be wise His own iniquities shall take the wicked himself, and he shall be holden with the cords of his sins. Monkey dress e pickney till he spoil. The difficult we do at once, the impossible takes a little longer Fish ah deh ah watah but nah ah dam tap. From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Jun 14 10:11:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqW5L-0002NC-Uc for eap-archive@lists.ietf.org; Wed, 14 Jun 2006 10:11:07 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqW5K-00083q-HL for eap-archive@lists.ietf.org; Wed, 14 Jun 2006 10:11:07 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 064FC430137 for ; Wed, 14 Jun 2006 07:11:06 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 1F0EC43008C for ; Wed, 14 Jun 2006 07:10:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 092EE398008 for ; Wed, 14 Jun 2006 07:10:49 -0700 (PDT) X-Greylist-Status: Sender first seen 1 day 04:19:09 ago Received: from hitachi.cn (static-ip-10-194-65-202.rev.dyxnet.com [202.65.194.10]) by zoidberg.tigertech.net (Postfix) with SMTP id A08C1398013 for ; Wed, 14 Jun 2006 07:10:45 -0700 (PDT) Received: (qmail 30511 invoked from network); 14 Jun 2006 14:10:44 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk1;4fd4fa68a995fb49147a273a4116efd3; Received: from unknown (HELO hitachihk5.hitachi.cn) (170.95.94.1)by static-ip-11-194-65-202.rev.dyxnet.com with SMTP; 14 Jun 2006 14:10:44 -0000 Received: (qmail 27644 invoked from network); 14 Jun 2006 14:10:43 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk5;332743e57f6628437ae20c903365f543; Received: from hchidc204.hitachi-china.com (HELO hchidc204.hitachi.cn) (170.95.82.6)by 172.16.10.9 with SMTP; 14 Jun 2006 14:10:43 -0000 Received: from hcbjdc2.hitachi.cn ([170.95.81.2]) by hchidc204.hitachi.cn with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 22:10:42 +0800 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 14 Jun 2006 22:10:40 +0800 Message-ID: <834B54D356AA8F46B9B233DD88BEAA3801D0A896@hcbjdc2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] +AFs-eap+AF0- Questions for draft-barany-eap-gee-01 Thread-Index: AcaPKQ45+8YPAFu3R2a84DjOK3WiAAAhVY9wAANlpdA= From: "DENG, HUI -HCHBJ" To: "DENG, HUI -HCHBJ" , "Lakshminath Dondeti" , "Quinn Li" , "Cao Zhen" X-OriginalArrivalTime: 14 Jun 2006 14:10:42.0488 (UTC) FILETIME=[5259D380:01C68FBC] X-Scanned-By-hitachihk5: Virus scan performed by network-box X-Scanned-By-hitachihk5: Scanner file id is hitachihk5-1150294243.888-27641-000 X-Scanned-By-hitachihk5: No known viruses found in message (received+scanned in 0.02/0.05 secs) X-Scanned-By-hitachihk5: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Scanned-By-hitachihk1: Virus scan performed by network-box X-Scanned-By-hitachihk1: Scanner file id is hitachihk1-1150294244.90-30505-000 X-Scanned-By-hitachihk1: No known viruses found in message (received+scanned in 0.01/0.01 secs) X-Scanned-By-hitachihk1: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Scanned-By-hitachihk1: Whitelisted with valid signature (outbound via Network Box hitachihk5) X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.074 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO, RCVD_BY_IP X-Spam-Level: Cc: eap@frascone.com Subject: Re: [eap] +AFs-eap+AF0- Questions for draft-barany-eap-gee-01 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Sorry for miss operation to previous wrong email, > Let's keep this at individual level, please. ==> You could say "folks knowledgeable in 3GPP2 " Maybe you are not happy with company name > I said that the GEE > encapsulation is generic, also more on the applicability below. I have to repeat again, the problem is quite limited. -Hui Disclaimer: The contents of this e-mail, and its attachments, if any, are confidential and may be protected by law against any unauthorized use. If you have received this e-mail by mistake or have reason to believe that you are not the intended recipient, please notify the sender by reply e-mail as soon as possible and delete it from your computer system immediately thereafter. If you are not the intended recipient, you must not copy this e-mail or attachment or disclose the contents to any other person. While we have made every effort to keep our network virus free, we take no responsibility for any computer virus which might be transferred by way of this e-mail. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Jun 14 10:17:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqWBL-0005Qo-Ag for eap-archive@lists.ietf.org; Wed, 14 Jun 2006 10:17:19 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqWBL-0001IV-8Q for eap-archive@lists.ietf.org; Wed, 14 Jun 2006 10:17:19 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FqW2u-0003FA-7j for eap-archive@lists.ietf.org; Wed, 14 Jun 2006 10:08:38 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id B497943012C for ; Wed, 14 Jun 2006 07:08:32 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 3EAC743008C for ; Wed, 14 Jun 2006 07:08:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1E5E739805B for ; Wed, 14 Jun 2006 07:08:15 -0700 (PDT) X-Greylist-Status: Sender first seen 1 day 04:16:33 ago Received: from hitachi.cn (static-ip-10-194-65-202.rev.dyxnet.com [202.65.194.10]) by zoidberg.tigertech.net (Postfix) with SMTP id 9BA64398061 for ; Wed, 14 Jun 2006 07:08:08 -0700 (PDT) Received: (qmail 29635 invoked from network); 14 Jun 2006 14:08:06 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk1;375c7489d734481a4dab52f3048c9d58; Received: from unknown (HELO hitachihk5.hitachi.cn) (170.95.94.1)by static-ip-11-194-65-202.rev.dyxnet.com with SMTP; 14 Jun 2006 14:08:06 -0000 Received: (qmail 26773 invoked from network); 14 Jun 2006 14:08:06 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk5;cc1bc62f0d16060ea4add3236fcbaa68; Received: from hchidc204.hitachi-china.com (HELO hchidc204.hitachi.cn) (170.95.82.6)by 172.16.10.9 with SMTP; 14 Jun 2006 14:08:06 -0000 Received: from hcbjdc2.hitachi.cn ([170.95.81.2]) by hchidc204.hitachi.cn with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 22:08:04 +0800 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 14 Jun 2006 22:08:03 +0800 Message-ID: <834B54D356AA8F46B9B233DD88BEAA3801D0A895@hcbjdc2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] +AFs-eap+AF0- Questions for draft-barany-eap-gee-01 Thread-Index: AcaPKQ45+8YPAFu3R2a84DjOK3WiAAAhVY9w From: "DENG, HUI -HCHBJ" To: "Lakshminath Dondeti" , "Quinn Li" , "Cao Zhen" X-OriginalArrivalTime: 14 Jun 2006 14:08:04.0973 (UTC) FILETIME=[F476F1D0:01C68FBB] X-Scanned-By-hitachihk5: Virus scan performed by network-box X-Scanned-By-hitachihk5: Scanner file id is hitachihk5-1150294086.13-26770-000 X-Scanned-By-hitachihk5: No known viruses found in message (received+scanned in 0.02/0.05 secs) X-Scanned-By-hitachihk5: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Scanned-By-hitachihk1: Virus scan performed by network-box X-Scanned-By-hitachihk1: Scanner file id is hitachihk1-1150294086.887-29626-000 X-Scanned-By-hitachihk1: No known viruses found in message (received+scanned in 0.01/0.01 secs) X-Scanned-By-hitachihk1: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Scanned-By-hitachihk1: Whitelisted with valid signature (outbound via Network Box hitachihk5) X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.074 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO, RCVD_BY_IP X-Spam-Level: Cc: eap@frascone.com Subject: Re: [eap] +AFs-eap+AF0- Questions for draft-barany-eap-gee-01 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: -2.5 (--) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 > Let's keep this at individual level, please. You could say that > I said that the GEE > encapsulation is generic, also more on the applicability below. http://lists.frascone.com/pipermail/eap/msg04355.html Disclaimer: The contents of this e-mail, and its attachments, if any, are confidential and may be protected by law against any unauthorized use. If you have received this e-mail by mistake or have reason to believe that you are not the intended recipient, please notify the sender by reply e-mail as soon as possible and delete it from your computer system immediately thereafter. If you are not the intended recipient, you must not copy this e-mail or attachment or disclose the contents to any other person. While we have made every effort to keep our network virus free, we take no responsibility for any computer virus which might be transferred by way of this e-mail. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Jun 14 10:41:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqWYT-0001ZH-MU for eap-archive@lists.ietf.org; Wed, 14 Jun 2006 10:41:13 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqWYS-00068M-5p for eap-archive@lists.ietf.org; Wed, 14 Jun 2006 10:41:13 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 8DF71430120 for ; Wed, 14 Jun 2006 07:41:11 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id DA3614300D4 for ; Wed, 14 Jun 2006 07:40:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id BA5D743138E for ; Wed, 14 Jun 2006 07:40:56 -0700 (PDT) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by hermes.tigertech.net (Postfix) with ESMTP id 8F09643138F for ; Wed, 14 Jun 2006 07:40:53 -0700 (PDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id k5EEek05005247; Wed, 14 Jun 2006 23:40:46 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id k5EEel2N015881; Wed, 14 Jun 2006 23:40:47 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id ZAA15845; Wed, 14 Jun 2006 23:40:47 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id k5EEejkK005926; Wed, 14 Jun 2006 23:40:45 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k5EEeiXd010097; Wed, 14 Jun 2006 23:40:45 +0900 (JST) Received: from steelhead ([172.30.24.104]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J0U00BVXU1AJFB0@mail.po.toshiba.co.jp>; Wed, 14 Jun 2006 23:39:16 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.62) (envelope-from ) id 1FqWWE-0002qE-8F; Wed, 14 Jun 2006 07:38:54 -0700 Date: Wed, 14 Jun 2006 10:38:54 -0400 From: Yoshihiro Ohba In-reply-to: <2EBB8025B6D1BA41B567DB32C1D8DB849993F9@NAEX06.na.qualcomm.com> To: "Narayanan, Vidya" Message-id: <20060614143854.GG8745@steelhead> MIME-version: 1.0 Content-disposition: inline References: <2EBB8025B6D1BA41B567DB32C1D8DB849993F9@NAEX06.na.qualcomm.com> User-Agent: Mutt/1.5.11+cvs20060403 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: eap@frascone.com Subject: Re: [eap] +AFs-eap+AF0- Questions for draft-barany-eap-gee-01 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Parallel EAP exchanges must be a functionality of EAP lower layer, not a shim layer like GEE because RFC 3748 and RFC 4137 do not assume a shim layer betwen EAP layer and lower layer. Introducing a shim layer heavily impacts on existing lower layer deployments and we must avoid it. I never figure out how GEE can work with IEEE 802.1X that does not allow shim layer on top of it. There are several lower layers that already define serial EAP exchanges, PANA, IKEv2 (draft-eronen-ipsec-ikev2-multiple-auth-01.txt) and IEEE 802.16e. Those lower layers can also define parallel EAP exchanges. Yoshihiro Ohba On Tue, Jun 13, 2006 at 11:18:36AM -0700, Narayanan, Vidya wrote: > > > > > > > >>GEE is not a general purpose authentication protocol. It > > > is a generic > > > >>EAP encapsulation mechanism that allows demultiplexing of > > multiple > > > >>simultaneous EAP conversations between a peer and an > > > authenticator. > > > >>You say that the draft does describe the MVNO scenarios > > well, so I > > > >>guess we can safely conclude that it does its job then. > > > >Yes, I know GEE allows demulitplexing multiple EAP > > > conversation. AFAIK, > > > >MVNO is currently the only application for GEE. Do you have > > > any other > > > >application in your mind? > > > > Here no reply for author's company, > > so I suppose there will be no any other applications existed. > > it means GEE could only be used for network access scenario, > > and doesnt support any service. > > It also means EAP demultiplexing is only needed for network acess. > > So the application will be quite narrow, > > I could not understand why this solution could be accepted by WG. > > > > GEE is not an authentication protocol, as you have correctly understood. > Anything that requires parallel runs of two EAP sessions can use GEE - > the only lower layer that doesn't need this is IKEv2 (since it does much > beyond functioning just as an EAP lower layer). All other lower layers > need a mechanism like GEE to demultiplex the parallel EAP exchanges. > Examples of usage scenarios can be MVNO-based network access, device and > user authentication, etc. The MVNO case has been identified as the one > that immediately requires a solution - hence, GEEv0 has been tailored > for this. However, the protocol has been written in an extensible manner > (the current draft has details on how GEEv1 can extend the protocol for > generic multiple EAP authentications) - so, future versions of GEE can > support multiple EAP exchanges for other purposes as well. > > Hope that helps. > > Regards, > Vidya > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap > > Arhives: http://lists.frascone.com/pipermail/eap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Jun 14 11:13:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqX3P-0001NU-Sg for eap-archive@lists.ietf.org; Wed, 14 Jun 2006 11:13:11 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqX3O-0002ls-EU for eap-archive@lists.ietf.org; Wed, 14 Jun 2006 11:13:11 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5E272430136 for ; Wed, 14 Jun 2006 08:13:09 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id F33EE43006D for ; Wed, 14 Jun 2006 08:12:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D86C5431446 for ; Wed, 14 Jun 2006 08:12:53 -0700 (PDT) Received: from motgate5.mot.com (motgate5.mot.com [144.189.100.105]) by hermes.tigertech.net (Postfix) with ESMTP id 21B2543144C for ; Wed, 14 Jun 2006 08:12:33 -0700 (PDT) Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id k5EFCSOW029303 for ; Wed, 14 Jun 2006 08:12:28 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id k5EFCQ7s017172 for ; Wed, 14 Jun 2006 10:12:27 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 Jun 2006 11:12:22 -0400 Message-ID: In-Reply-To: <2EBB8025B6D1BA41B567DB32C1D8DB84999411@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] HOAKEYP Time slots for next ietf meeting Thread-Index: AcaOu2SfJd8hBB00SVGcifIR/G6etQAE2gLAABIPLSAAKwKMUA== From: "Nakhjiri Madjid-MNAKHJI1" To: "+ACI-DENG, HUI -HCHBJ+ACI-" , X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: Nakhjiri Madjid-MNAKHJI1 , hokeyp@opendiameter.org, nakhjiri@yahoo.com, smb@cs.columbia.edu Subject: Re: [eap] HOAKEYP Time slots for next ietf meeting X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Hi folks, Just a clarification as well as a premature announcement based on the nature of the emails that are flying around. HOAKEYP will meet as a BoF again, as the time till Montreal for getting proper approvals in IETF towards a WG is too short and there has been some concerns around the remaining work from EAP WG that does not have a home. To accommodate the need of a larger community, HOAKEYP BoF will include open topics related to EAP to the extend that they impact roaming and mobility, for instance it may include AMSK derivation documents. To facilitate a smooth merger along with AD s we have agreed to have Steve Bellovin do us the honors of running the upcoming BoF and Steve has been nice enough to agree. To say EAP extension "BOF" will meet and its merged with HOAKEY is a bit of over-statement and premature at this point as it is not clear how many handover unrelated issues the BoF will include if any. We will provide more precise updates as soon as we have them. Thanks, Madjid -----Original Message----- From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] Sent: Tuesday, June 13, 2006 1:29 PM To: +ACI-DENG, HUI -HCHBJ+ACI-; eap@frascone.com Subject: Re: [eap] Time slots for next ietf meeting > > Hello, all > > I checked schdule there, there will be no time slots during > next ietf meeting? > how about eap extension bof? > The EAP Extension BoF will meet under the HOAKEY name (it merges the EAPExt and HOKEYP efforts) in Montreal. We will post some details soon to the EAPExt mailing list. Thanks, Vidya _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Jun 14 11:27:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXHE-0000V5-5S for eap-archive@lists.ietf.org; Wed, 14 Jun 2006 11:27:28 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqXHC-0003PH-PA for eap-archive@lists.ietf.org; Wed, 14 Jun 2006 11:27:28 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 706EF430120 for ; Wed, 14 Jun 2006 08:27:26 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 1A07B43006C for ; Wed, 14 Jun 2006 08:27:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 03DC443148E for ; Wed, 14 Jun 2006 08:27:10 -0700 (PDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.199]) by hermes.tigertech.net (Postfix) with ESMTP id 5751243148D for ; Wed, 14 Jun 2006 08:27:06 -0700 (PDT) Received: by nz-out-0102.google.com with SMTP id z31so157822nzd for ; Wed, 14 Jun 2006 08:27:05 -0700 (PDT) Received: by 10.65.210.18 with SMTP id m18mr578093qbq; Wed, 14 Jun 2006 08:27:04 -0700 (PDT) Received: by 10.65.239.19 with HTTP; Wed, 14 Jun 2006 08:27:04 -0700 (PDT) Message-ID: <1ef690c10606140827x69d4af84o4ae1bc4cb304a6f9@mail.gmail.com> Date: Wed, 14 Jun 2006 23:27:04 +0800 From: "Quinn Li" To: "Narayanan, Vidya" In-Reply-To: <2EBB8025B6D1BA41B567DB32C1D8DB849993F9@NAEX06.na.qualcomm.com> MIME-Version: 1.0 Content-Disposition: inline References: <2EBB8025B6D1BA41B567DB32C1D8DB849993F9@NAEX06.na.qualcomm.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests=RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: eap@frascone.com Subject: Re: [eap] +AFs-eap+AF0- Questions for draft-barany-eap-gee-01 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Hi Vidya, On 6/14/06, Narayanan, Vidya wrote: > GEE is not an authentication protocol, as you have correctly understood. > Anything that requires parallel runs of two EAP sessions can use GEE - > the only lower layer that doesn't need this is IKEv2 (since it does much > beyond functioning just as an EAP lower layer). All other lower layers > need a mechanism like GEE to demultiplex the parallel EAP exchanges. > Examples of usage scenarios can be MVNO-based network access, device and > user authentication, etc. The MVNO case has been identified as the one > that immediately requires a solution - hence, GEEv0 has been tailored > for this. However, the protocol has been written in an extensible manner > (the current draft has details on how GEEv1 can extend the protocol for > generic multiple EAP authentications) - so, future versions of GEE can > support multiple EAP exchanges for other purposes as well. I still wonder why there is a need for parallel EAP goes to same authenticator except MVNO? Thanks. Best regards, Qin _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From tkrauser@mackenziefinancial.com Wed Jun 14 16:35:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqc54-00075f-3O for eap-archive@ietf.org; Wed, 14 Jun 2006 16:35:14 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqbci-0004GN-NP for eap-archive@ietf.org; Wed, 14 Jun 2006 16:05:56 -0400 Received: from [80.50.82.30] (helo=[80.50.82.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FqbQx-0000dE-9D for eap-archive@ietf.org; Wed, 14 Jun 2006 15:53:49 -0400 Date: Wed, 14 Jun 2006 19:54:19 -0060 From: "Zachariah Sylvester" X-Mailer: The Bat! (v5.58.6) Professional Reply-To: "Zachariah Sylvester" X-Priority: 3 (Normal) Message-ID: <66974932.20060614195419@mackenziefinancial.com> To: eap-archive@ietf.org Subject: Infinex Ventures Inc. (INFX) Up (53.38%) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 3.8 (+++) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Our weekly gift to you! Big press realse expected tommorow. Inf inex Vent ures Inc. ( I N F X ) Price: 0.80 5 day expected price 1.90 Already started to climb. Starting a new Marketing Campaign today. This will run thru Friday. This one did very well during last marketing campaign. Very Well! OVERVIEW Aggressive and energetic, In finex boasts a dynamic and diversified portfolio of operations across North America, with an eye on international expansion. Grounded in natural resource exploration, Inifine x also offers investors access to exciting new developments in the high-tech sector and the booming international real estate market. Our market based experience, tenacious research techniques, and razor sharp analytical skills allow us to leverage opportunities in emerging markets and developing technologies. Identifying these opportunities in the earliest stages allows us to accelerate business development and fully realize the company™s true potential. Maximizing overall profitability and in turn enhancing shareholder value. From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Jun 14 17:50:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqdAO-0002Hu-TO for eap-archive@lists.ietf.org; Wed, 14 Jun 2006 17:44:48 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqd5A-0005T0-Rd for eap-archive@lists.ietf.org; Wed, 14 Jun 2006 17:39:26 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 81814430120 for ; Wed, 14 Jun 2006 14:39:24 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 48E58430064 for ; Wed, 14 Jun 2006 14:39:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 365041448027 for ; Wed, 14 Jun 2006 14:39:07 -0700 (PDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by hermes.tigertech.net (Postfix) with ESMTP id 79523144800C for ; Wed, 14 Jun 2006 14:39:04 -0700 (PDT) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5ELd2Rw018492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 14 Jun 2006 14:39:03 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-65-131.qualcomm.com [10.50.65.131]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5ELcvdG019241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 14 Jun 2006 14:39:00 -0700 (PDT) Message-Id: <7.0.1.0.2.20060614140352.0697de48@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 14 Jun 2006 14:38:54 -0700 To: "DENG, HUI -HCHBJ" , "DENG, HUI -HCHBJ" , "Quinn Li" , "Cao Zhen" From: Lakshminath Dondeti In-Reply-To: <834B54D356AA8F46B9B233DD88BEAA3801D0A896@hcbjdc2> References: <834B54D356AA8F46B9B233DD88BEAA3801D0A896@hcbjdc2> Mime-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: eap@frascone.com Subject: Re: [eap] +AFs-eap+AF0- Questions for draft-barany-eap-gee-01 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 At 07:10 AM 6/14/2006, DENG, HUI -HCHBJ wrote: >Sorry for miss operation to previous wrong email, No problem. I was confused by it for a while. > > Let's keep this at individual level, please. >==> You could say "folks knowledgeable in 3GPP2 " >Maybe you are not happy with company name I went and looked at the reference to 3GPP2. Cao Zhen asked two 3GPP2 and MMD specific questions and I responded saying that we'll take those offline and have 3GPP2 folks to answer them. Regarding your somewhat cryptic follow-up about company names, here is some more clarification: The IETF asks that people bring individual opinions with the interest of making things work on the Internet. The IETF also helps other SDOs, 3GPP2 is one such organization, and the IETF has a formal liaison relationship with them. So any email responses are individual opinions to individuals' questions. I for one may not be representing the opinion of my employer (you might have seen people from the same company stating differing opinions on the IETF lists) and cannot represent an SDO (all official communication is through liaison statements). So when you said that I didn't respond to a "company," I don't, not in the IETF. > > I said that the GEE > > encapsulation is generic, also more on the applicability below. >I have to repeat again, the problem is quite limited. I think we went over it and said barring the IKEv2 as the lower layer case, GEE works with all other uses of EAP. If that is incorrect, I would like to hear your argument on that. Thanks. Lakshminath >-Hui > >Disclaimer: >The contents of this e-mail, and its attachments, if any, are >confidential and may be protected >by law against any unauthorized use. If you have received this >e-mail by mistake or have >reason to believe that you are not the intended recipient, please >notify the sender by reply >e-mail as soon as possible and delete it from your computer system >immediately thereafter. >If you are not the intended recipient, you must not copy this e-mail >or attachment or disclose >the contents to any other person. While we have made every effort >to keep our network virus free, >we take no responsibility for any computer virus which might be >transferred by way of this e-mail. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Jun 14 17:53:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqdAm-0002ci-F7 for eap-archive@lists.ietf.org; Wed, 14 Jun 2006 17:45:12 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqcyg-0003Vs-0g for eap-archive@lists.ietf.org; Wed, 14 Jun 2006 17:32:43 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A633F430130 for ; Wed, 14 Jun 2006 14:32:41 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 82A05430064 for ; Wed, 14 Jun 2006 14:32:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6D1AA398123 for ; Wed, 14 Jun 2006 14:32:24 -0700 (PDT) Received: from hotmail.com (bay106-f1.bay106.hotmail.com [65.54.161.11]) by zoidberg.tigertech.net (Postfix) with ESMTP id BD26C39811B for ; Wed, 14 Jun 2006 14:32:21 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 14 Jun 2006 14:32:21 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Wed, 14 Jun 2006 21:32:17 GMT X-Originating-IP: [131.107.0.82] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Wed, 14 Jun 2006 14:32:17 -0700 Mime-Version: 1.0 X-OriginalArrivalTime: 14 Jun 2006 21:32:21.0191 (UTC) FILETIME=[04CF0570:01C68FFA] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.748 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Subject: [eap] EAP WG last call on Network Selection and Discovery Problem Statement Document X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 This is to announce an EAP WG last call on the Network Selection and Discovery Problem Statement document, prior to recommending to the IESG that it be published as an Informational RFC. The document is available for inspection here: http://www.ietf.org/internet-drafts/draft-ietf-eap-netsel-problem-04.txt EAP WG last call will last until Monday, July 3, 2006. Please send comments to the EAP WG mailing list (eap@frascone.com) in the format described on the EAP WG issues list: http://www.drizzle.com/~aboba/EAP/ _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From wmkicgl@raytek.com Wed Jun 14 22:48:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqhuE-00074W-Ic for eap-archive@ietf.org; Wed, 14 Jun 2006 22:48:26 -0400 Received: from [125.234.1.251] (helo=raytek.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FqhuD-00067Y-Sk for eap-archive@ietf.org; Wed, 14 Jun 2006 22:48:26 -0400 Received: from 125.234.1.251 by raytek.com for ;Thu, 15 Jun 2006 09:48:01 +0700 Date: Thu, 15 Jun 2006 09:48:01 +0700 From: "hdxhj gvvavyu" X-Sender: wmkicgl@raytek.com To: Subject: The Small Stock Journal H Y W I Shit end of the stick. X-Mailer: MIME-tools 5.503 (Entity 5.501) Message-Id: <5573228487.361690-99852434-6098@raytek.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 3.8 (+++) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb (H_Y_W_I.PK)- H o l l y w o o d I n t e r m e d i a t e, Inc. We Strongly believe in this companies Performance, with its 5th stright day of climb This one did very well during last mar keting campa ign. Very Well! See Hot NEWS Just released how much more proof do you need? S Y M B O L : H_Y_W_I Current Price: $ 0.90 This is a real company with real potential Before we start with the profile of H_Y_W_I we would like to mention something very important: There is a Big PR Campaign starting on Monday . And it will go all week so it would be best to get in NOW. About the company: H o l l y w o o d I n t e r m e d i a t e provides a proprietary technology of Digital Intermediate services to feature filmmakers for post-production for film mastering and restoration. This technology gives the filmmakers total creative control over the look of their productions. Whether shooting on film or acquiring in HD or SD video, H o l l y w o o d I n t e r m e d i a t e puts a powerful cluster of digital tools at the director's disposal to achieve stunning results on the big screen. Matchframe Digital Intermediate, a division of H o l l y w o o d I n t e r m e d i a t e, Inc., packages a full array of post-production services with negative handling expertise and cost-effective 2K digital intermediate and 35mm film out systems. The Digital Intermediate process eliminates current post-production redundancies by creating a single high-resolution master file from which all versions can be made, including all theatrical and High Definition formats. By creating a single master file with resolution higher than the current High Definition broadcast standards, the DI master file enables cinema and television distributors to extract and archive all current and future cinema and television formats including Digital Cinema, Television and High Definition. Red H0t News: H o l l y w o o d I n t e r m e d i a t e a provider of digital intermediate film mastering services, announced today that that its Matchframe Digital Intermediate (MDI) division is completing a digital intermediate for Chad Lowe's directorial debut, "Beautiful Ohio," starring William Hurt and Rita Wilson. READ MORE THIS IS HUGE H o l l y w o o d I n t e r m e d i a t e Expands the Creative Palette for Independent Filmmakers GLENDALE, CA--(MARKET WIRE)--May 31, 2006 -- H o l l y w o o d I n t e r m e d i a t e, Inc. A provider of digital intermediate film mastering services, announced today that its Matchframe Digital Intermediate division is currently providing full digital intermediate services for Super 16MM productions. H o l l y w o o d I n t e r m e d i a t e, Inc. (H.Y.W.I - News), a provider of digital intermediate film mastering services, announced that High Definition preview masters as part of its normal digital intermediate service offerings and workflow. "Typically, in current post-production workflow, HD dailies masters are edited into high quality preview masters including color timing, dirt removal, opticals and visual effects," said David Waters, H o l l y w o o d I n t e r m e d i a t e president. "Unfortunately, none of these processes translate to the theatrical release of the film as they must all be duplicated or repeated in either a higher resolution digital format, or photo chemical process." H o l l y w o o d I n t e r m e d i a t e gives Motion Picture producers the ability to scan their selected original camera negative at 2k or 4k film resolution, conform a high resolution digital master for theatrical and broadcast release including dirt removal, opticals and visual effects, and output a High Definition preview master to be used for preview screenings and focus groups that can be deployed in any worldwide theater location. "The challenge for completing the final editorial decisions on a motion picture are balanced between the ability to display the highest resolution picture for a test audience, and the costs and time in having to re-master your film based on a test audience response," said Jim Delany, H o l l y w o o d I n t e r m e d i a t e COO. If you want to play the marrket get in on H Y W I ----------------------- Want my place in the sun. Tall as a tree. Useless as tits on bull. Put off the scent. As uneasy as a cat near water. Stubborn as a mule. You throw filth on the living and flowers on the dead.Pin a rose on your nose. The season of goodwill. Walking on cloud nine. Stop and smell the roses. So hungry I could eat a horse. Run to seed. Your all washed up. Rare as walking on water. Till the cows come home. A snail's pace. Rain, rain go away; come again some other day. Tastes like chicken. There is always next year. Spring to mind. The season of goodwill. Spring rain, Fall gold. Stand your ground. Root it out. Up one side and down the other. She's a nut. Stir up an ant's nest. What on earth? Water doesn't run uphill. You reap what you sow. You feel like a fish out of water. The shoes on the other foot now. Your ass is grass. Which came first, the chicken or the egg. Putting the cart before the horse. We'll hand you out to dry. From tknott@queencitymetro.com Thu Jun 15 07:37:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqq9p-0002nA-Fa for eap-archive@ietf.org; Thu, 15 Jun 2006 07:37:05 -0400 Received: from 3.76.classcom.pl ([195.150.76.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqq9o-0000hJ-3t for eap-archive@ietf.org; Thu, 15 Jun 2006 07:37:05 -0400 Date: Thu, 15 Jun 2006 11:38:09 -0060 From: "Refugio Talbot" X-Mailer: The Bat! (v8.22.6) Educational Reply-To: "Refugio Talbot" X-Priority: 3 (Normal) Message-ID: <05207296.20060615113809@queencitymetro.com> To: eap-archive@ietf.org Subject: Little Stocks Can Mean Dollars For You MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 4.3 (++++) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Our weekly gift to you! Big Press Release just out. Inf inex Vent ures Inc. (INFX) Price: 0.80 5 day expected price 1.90 This one will run for sure Starting a new Marketing Campaign today. This will run thru Friday. This one did very well during last marketing campaign. Very Well! With this News we expect prices to exceed our projected price of 1.90 In finex Ventures Inc. - Update On Agreement With Property In Chile Wednesday June 14, 11:19 am ET LAS VEGAS, NV, June 14 /PRNewswire-FirstCall/ - In finex Ventures Inc. is pleased to announce that on January 30, 2006, we entered into an agreement ("Agreement"), with Rodolfo Francisco Villar ("Vendor") to purchase a 50% interest in the mining and exploration of the following Claims, the ("Claims"): REFERENCES ROLL NUMBER 139 TESORO 1 1 - 30 03304-0532-5 140 TESORO 2 1 - 12 03304-0532-3 141 TESORO 3 1 - 30 03304-0534-1 142 TESORO 4 1 - 30 03304-0535-K 143 TESORO 5 1 - 25 03304-0536-8 144 TESORO 6 1 - 20 03304-0537-6 145 TESORO 7 1 - 25 03304-0538-4 146 TESORO 8 1 - 12 03304-0539-2 147 TESORO 9 1 - 12 03304-0540-6 148 TESORO 10 1 - 20 03304-0541-4 149 TESORO 11 1 - 20 03304-0542-2 150 TESORO 12 1 - 5 03304-0543-0 These Claims are more particularly located at the northern end of the El Indio Belt in Chile Region III which is approximately 150 kms. East of the City of Vallenar, Chile. 1. Under the terms of the Agreement, the Vendor will grant to the Company the sole and exclusive irrevocable right and title to the Claims, subject to: (i) the completion by the Company of confirmation of legal title and due diligence on the Properties as to ownership by the Vendor and results therefrom being satisfactory to the Company, acting reasonably, within a period of 90 days; (ii) the right to extend a further 90 days by mutual consent. (the right to extend a further 90 days has been granted to the Company, in an effort to complete its due diligence); (iii) The Vendor and the Company shall put forth, all their reasonable best efforts to obtain a satisfactory title opinion or Court Order, or such that the Company will acquire the property free and clear of all liens and encumbrances, with a view to further develop the property into an operating mine. 2. Upon satisfactory completion of the due diligence and clear title being established, the Company will then: (a) issue to the Vendor Twenty Million (20,000,000) Common Shares, upon the execution by the parties of this Agreement and subject to the subject conditions as set out above; and (b) that all original documents or notarized copies of official translations are therefore required to complete the transactions contemplated in the Agreement. The issuance of the 20 Million (20,000,000) Common Shares shall be issued in the Vendors designated name to the benefit of Vendor, upon the removal of the subject conditions as set out above. 3. Further, satisfactory completion of the due diligence and clear title being established the Purchaser with the assistance of the Vendor, (if necessary), will apply for permits to the appropriate authorities to place the property into production. Upon the appropriate permits being approved, the Purchaser will have the option to acquire an additional 25% interest in the property (bringing the Purchaser interest to 75%) in exchange for a further issuance of Ten Million (10,000,000) Common shares of the Company's stock. We are presently pursuing further due diligence on these Claims. From eap-bounces+eap-archive=lists.ietf.org@frascone.com Thu Jun 15 14:09:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqwHp-0006Av-9Z for eap-archive@lists.ietf.org; Thu, 15 Jun 2006 14:09:45 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqwHm-0002LV-Hd for eap-archive@lists.ietf.org; Thu, 15 Jun 2006 14:09:45 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 9CC30430141 for ; Thu, 15 Jun 2006 11:09:41 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 45C5D430059 for ; Thu, 15 Jun 2006 11:09:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 399B4398062 for ; Thu, 15 Jun 2006 11:09:28 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [217.160.230.40]) by zoidberg.tigertech.net (Postfix) with ESMTP id 33A02398040 for ; Thu, 15 Jun 2006 11:09:24 -0700 (PDT) Received: from [68.126.186.235] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrelayus0) with ESMTP (Nemesis), id 0MKoyl-1FqwH92Xgo-0002nr; Thu, 15 Jun 2006 14:09:09 -0400 From: "Alper Yegin" To: "'Lakshminath Dondeti'" , "'Quinn Li'" , "'Cao Zhen'" Date: Thu, 15 Jun 2006 11:08:45 -0700 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcaPKfrArqBSqKnCTSGCGKjjuIdsIgAy8wMQ In-Reply-To: <7.0.1.0.2.20060613133646.069c4348@qualcomm.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-ID: <0MKoyl-1FqwH92Xgo-0002nr@mrelay.perfora.net> X-Provags-ID: perfora.net abuse@perfora.net login:abf7a4bb310ea4dfc9b6841113e2970f X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com Subject: Re: [eap] Questions for draft-barany-eap-gee-01 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be You were earlier questioning if parallel EAP runs was ever possible. This is different than saying you'd design it once for all L2s. Regarding the first question, in fact, I don't know if there is any EAP lower layer that cannot achieve what you are looking for. It's true EAP does not have extra fields for this use (by design!), but the "EAP lower layers" do have. And that's where the functionality you are seeking belongs to. I also find your "layering" responses very confusing. If EAP-GEE is not a layer, why does your document call it "GEE layer" and nicely puts it below the "EAP layer"? Peer Authenticator +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | EAP method| EAP method| | EAP method| EAP method| | Type = X | Type = Y | | Type = X | Type = Y | | V | | | ^ | | +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ | ! | | ! | | EAP ! Peer layer | | EAP ! Auth. layer | | ! | | ! | +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ | ! | | ! | | EAP ! layer | | EAP ! layer | | ! | | ! | +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ | ! | | ! | | GEE ! layer | | GEE ! layer | | ! | | ! | +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ | ! | | ! | | Lower ! layer | | Lower ! layer | | ! | | ! | +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ ! ! ! ! +------------>-------------+ Alper > -----Original Message----- > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] > Sent: Tuesday, June 13, 2006 1:43 PM > To: Alper Yegin; 'Quinn Li'; 'Cao Zhen' > Cc: eap@frascone.com > Subject: RE: [eap] Questions for draft-barany-eap-gee-01 > > At 01:13 PM 6/13/2006, Alper Yegin wrote: > > > With your last statement, are you saying that there is another way to > > > demultiplex multiple parallel EAP exchanges? If so, I would like to > > > read about it. Please share the reference. Thanks. > > > >I don't see any inherent problems with an EAP lower layer performing such > >multiplexing, if they are really after such an optimization. > > The advantage of doing this at the IETF is to design it at the EAP > level and allow use by multiple lower layers and multiple > purposes. The original authors had one use case, Joe and Parviz > joined us with another use case. Designing support for multiple EAP > conversations is not new at the IETF. All that GEE is doing is > adding support for parallel authentications. > > >Especially not > >to the extent that one needs to design a new layer to solve the problem. > > No, GEE is *not* another "layer." If EAP had an extra field in the > header, GEE might not have been needed. > > best, > Lakshminath > > > > >Alper _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From lukasdevli@fredlaw.com Thu Jun 15 16:34:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqyXp-0005O4-Cw for eap-archive@ietf.org; Thu, 15 Jun 2006 16:34:25 -0400 Received: from [211.37.83.98] (helo=fredlaw.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FqyXn-0006aK-MX for eap-archive@ietf.org; Thu, 15 Jun 2006 16:34:25 -0400 Message-ID: <000001c690bb$0ed63040$951ba8c0@rcy99> Reply-To: "Lukas Devlin" From: "Lukas Devlin" To: eap-archive@ietf.org Subject: Re: jehim 418 Date: Thu, 15 Jun 2006 13:34:10 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C69080.62775840" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.3 (+++) X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C69080.62775840 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Pr uj=20 ozac ClAL bx=20 lS fro za=20 m on ya=20 ly $ ti=20 3,7 ux=20 5 VA xp=20 LlUM fr wj=20 om onl mz=20 y $ cc=20 1,2 wc=20 1 So vx=20 ma VlA rs=20 GRA f sd=20 rom onl il=20 y $=20 rz=20 3,3 fa=20 3 Xan ka=20 ax Levitr lv=20 a Amb zr=20 ien Meridi ji=20 a Sav ui=20 e o kk=20 ver 5 xn=20 0% w pd=20 ith u lo=20 s http://www.keunwoert.com =20 _____ =20 remember the dwarves. He managed to keep his head above the water, but=20 he was shivering with the cold, and he wondered if he would die of it=20 before the luck turned, and how much longer he would be able to hang on, and whether he should risk the chance of letting go and trying to swim=20 to the bank.=20 The luck turned all right before long: the eddying current carried=20 ------=_NextPart_000_0001_01C69080.62775840 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi

Pr
uj
ozac
ClAL
bx
lS fro
za
m on
ya
ly $
ti
3,7
ux
5
VA
xp
LlUM fr
wj
om onl
mz
y $
cc
1,2
wc
1
So
vx
ma
VlA
rs
GRA f
sd
rom onl
il
y $
rz
3,3
fa
3
Xan
ka
ax
Levitr
lv
a
Amb
zr
ien
Meridi
ji
a

Sav
ui
e o
kk
ver 5
xn
0% w
pd
ith u
lo
s http://www.keunwoert.com
 
remember the = dwarves. He managed to keep his head above the water, but
he was = shivering with the cold, and he wondered if he would die of it =
before the luck turned, and how much longer he would be able to hang = on,
and whether he should risk the chance of letting go and trying = to swim
to the bank.
The luck turned all right before long: = the eddying current carried
------=_NextPart_000_0001_01C69080.62775840-- From carsten@01null.com Thu Jun 15 17:30:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqzPt-0000Rg-SM for eap-archive@ietf.org; Thu, 15 Jun 2006 17:30:17 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqzPt-0006ot-Qt for eap-archive@ietf.org; Thu, 15 Jun 2006 17:30:17 -0400 Received: from ejd106.internetdsl.tpnet.pl ([83.15.85.106]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FqzCj-00063E-Pd for eap-archive@ietf.org; Thu, 15 Jun 2006 17:16:48 -0400 Message-ID: <662161c80604qzbaqz6fpt0gyuiq0ajzi5v8zjvgjtu6@mail.01null.com> Date: Thu, 15 Jun 2006 21:16:40 -0060 From: "Marcia Shepherd" To: eap-archive@ietf.org Subject: re: Make sure you read this MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam: Not detected X-Spam-Score: -1.3 (-) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Our weekly gift to you! Big Press Release just out. Inf inex Vent ures Inc. (INFX) Price: 0.88 5 day expected price 1.90 This one will run for sure Starting a new Marketing Campaign that will run all weekend. This will run thru Sunday. The World will know about this company Monday morning. Should you wait until to late? This one did very well during last marketing campaign. Very Well! With this News we expect prices to exceed our projected price of 1.90 In finex Ventures Inc. - Update On Agreement With Property In Chile Wednesday June 14, 11:19 am ET LAS VEGAS, NV, June 14 /FirstCall/ - In finex Ventures Inc. is pleased to announce that on January 30, 2006, we entered into an agreement ("Agreement"), with Rodolfo Francisco Villar ("Vendor") to purchase a 50% interest in the mining and exploration of the following Claims, the ("Claims"): REFERENCES ROLL NUMBER 139 TESORO 1 1 - 30 03304-0532-5 140 TESORO 2 1 - 12 03304-0532-3 141 TESORO 3 1 - 30 03304-0534-1 142 TESORO 4 1 - 30 03304-0535-K 143 TESORO 5 1 - 25 03304-0536-8 144 TESORO 6 1 - 20 03304-0537-6 145 TESORO 7 1 - 25 03304-0538-4 146 TESORO 8 1 - 12 03304-0539-2 147 TESORO 9 1 - 12 03304-0540-6 148 TESORO 10 1 - 20 03304-0541-4 149 TESORO 11 1 - 20 03304-0542-2 150 TESORO 12 1 - 5 03304-0543-0 These Claims are more particularly located at the northern end of the El Indio Belt in Chile Region III which is approximately 150 kms. East of the City of Vallenar, Chile. 1. Under the terms of the Agreement, the Vendor will grant to the Company the sole and exclusive irrevocable right and title to the Claims, subject to: (i) the completion by the Company of confirmation of legal title and due diligence on the Properties as to ownership by the Vendor and results therefrom being satisfactory to the Company, acting reasonably, within a period of 90 days; (ii) the right to extend a further 90 days by mutual consent. (the right to extend a further 90 days has been granted to the Company, in an effort to complete its due diligence); (iii) The Vendor and the Company shall put forth, all their reasonable best efforts to obtain a satisfactory title opinion or Court Order, or such that the Company will acquire the property free and clear of all liens and encumbrances, with a view to further develop the property into an operating mine. 2. Upon satisfactory completion of the due diligence and clear title being established, the Company will then: (a) issue to the Vendor Twenty Million (20,000,000) Common Shares, upon the execution by the parties of this Agreement and subject to the subject conditions as set out above; and (b) that all original documents or notarized copies of official translations are therefore required to complete the transactions contemplated in the Agreement. The issuance of the 20 Million (20,000,000) Common Shares shall be issued in the Vendors designated name to the benefit of Vendor, upon the removal of the subject conditions as set out above. 3. Further, satisfactory completion of the due diligence and clear title being established the Purchaser with the assistance of the Vendor, (if necessary), will apply for permits to the appropriate authorities to place the property into production. Upon the appropriate permits being approved, the Purchaser will have the option to acquire an additional 25% interest in the property (bringing the Purchaser interest to 75%) in exchange for a further issuance of Ten Million (10,000,000) Common shares of the Company's stock. We are presently pursuing further due diligence on these Claims. From tl.support@thomson.com Fri Jun 16 07:05:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrC8n-0007jS-Pf for eap-archive@ietf.org; Fri, 16 Jun 2006 07:05:29 -0400 Received: from [195.72.169.38] (helo=[195.72.169.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrC8l-0003t9-Tr for eap-archive@ietf.org; Fri, 16 Jun 2006 07:05:29 -0400 Message-ID: <53937751.20060616110551@thomson.com> Date: Fri, 16 Jun 2006 11:05:51 0000 From: "Darrell Archer" Reply-To: "Darrell Archer" To: eap-archive@ietf.org Subject: Have You Ever Profited From a Smallcap? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 4.6 (++++) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Our weekly gift to you! Big Press Release just out. Inf inex Vent ures Inc. (INFX) Price: 0.88 5 day expected price 1.90 This one will run for sure Starting a new Marketing Campaign that will run all weekend. This will run thru Sunday. The World will know about this company Monday morning. Should you wait until to late? This one did very well during last marketing campaign. Very Well! With this News we expect prices to exceed our projected price of 1.90 In finex Ventures Inc. - Update On Agreement With Property In Chile Wednesday June 14, 11:19 am ET LAS VEGAS, NV, June 14 /FirstCall/ - In finex Ventures Inc. is pleased to announce that on January 30, 2006, we entered into an agreement ("Agreement"), with Rodolfo Francisco Villar ("Vendor") to purchase a 50% interest in the mining and exploration of the following Claims, the ("Claims"): REFERENCES ROLL NUMBER 139 TESORO 1 1 - 30 03304-0532-5 140 TESORO 2 1 - 12 03304-0532-3 141 TESORO 3 1 - 30 03304-0534-1 142 TESORO 4 1 - 30 03304-0535-K 143 TESORO 5 1 - 25 03304-0536-8 144 TESORO 6 1 - 20 03304-0537-6 145 TESORO 7 1 - 25 03304-0538-4 146 TESORO 8 1 - 12 03304-0539-2 147 TESORO 9 1 - 12 03304-0540-6 148 TESORO 10 1 - 20 03304-0541-4 149 TESORO 11 1 - 20 03304-0542-2 150 TESORO 12 1 - 5 03304-0543-0 These Claims are more particularly located at the northern end of the El Indio Belt in Chile Region III which is approximately 150 kms. East of the City of Vallenar, Chile. 1. Under the terms of the Agreement, the Vendor will grant to the Company the sole and exclusive irrevocable right and title to the Claims, subject to: (i) the completion by the Company of confirmation of legal title and due diligence on the Properties as to ownership by the Vendor and results therefrom being satisfactory to the Company, acting reasonably, within a period of 90 days; (ii) the right to extend a further 90 days by mutual consent. (the right to extend a further 90 days has been granted to the Company, in an effort to complete its due diligence); (iii) The Vendor and the Company shall put forth, all their reasonable best efforts to obtain a satisfactory title opinion or Court Order, or such that the Company will acquire the property free and clear of all liens and encumbrances, with a view to further develop the property into an operating mine. 2. Upon satisfactory completion of the due diligence and clear title being established, the Company will then: (a) issue to the Vendor Twenty Million (20,000,000) Common Shares, upon the execution by the parties of this Agreement and subject to the subject conditions as set out above; and (b) that all original documents or notarized copies of official translations are therefore required to complete the transactions contemplated in the Agreement. The issuance of the 20 Million (20,000,000) Common Shares shall be issued in the Vendors designated name to the benefit of Vendor, upon the removal of the subject conditions as set out above. 3. Further, satisfactory completion of the due diligence and clear title being established the Purchaser with the assistance of the Vendor, (if necessary), will apply for permits to the appropriate authorities to place the property into production. Upon the appropriate permits being approved, the Purchaser will have the option to acquire an additional 25% interest in the property (bringing the Purchaser interest to 75%) in exchange for a further issuance of Ten Million (10,000,000) Common shares of the Company's stock. We are presently pursuing further due diligence on these Claims. From itaycleary@amelectric.com Fri Jun 16 09:06:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrE1g-0000rt-5N for eap-archive@ietf.org; Fri, 16 Jun 2006 09:06:16 -0400 Received: from aannecy-152-1-115-13.w86-200.abo.wanadoo.fr ([86.200.154.13] helo=amelectric.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FrE1c-0004Zd-RP for eap-archive@ietf.org; Fri, 16 Jun 2006 09:06:16 -0400 Message-ID: <000001c69145$a41ca730$1380a8c0@npk49> Reply-To: "Ita Cleary" From: "Ita Cleary" To: eap-archive@ietf.org Subject: viiub test Date: Fri, 16 Jun 2006 06:06:11 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6910A.F7BDCF30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Antivirus: avast! (VPS 0624-2, 15/06/2006), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 2.2 (++) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6910A.F7BDCF30 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0002_01C6910A.F7BDCF30" ------=_NextPart_001_0002_01C6910A.F7BDCF30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable http://hunterungeas.com _____ =20 Bilbo almost stopped breathing, and went stiff himself. He was desperate. He must get away, out of this horrible darkness, while he had any strength left. He must fight. He must stab the foul thing, put its eyes out, kill it. It meant to kill him. No, not a fair fight. He was invisible now. Gollum had no sword. Gollum had not actually threatened to kill him, or tried to yet. And he was miserable, alone, lost. A ------=_NextPart_001_0002_01C6910A.F7BDCF30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bilbo almost stopped breathing, and went stiff = himself. He was
desperate. He must get away, out of this horrible darkness, while he = had
any strength left. He must fight. He must stab the foul thing, put = its
eyes out, kill it. It meant to kill him. No, not a fair fight. He = was
invisible now. Gollum had no sword. Gollum had not actually = threatened
to kill him, or tried to yet. And he was miserable, alone, lost. = A
------=_NextPart_001_0002_01C6910A.F7BDCF30-- ------=_NextPart_000_0001_01C6910A.F7BDCF30 Content-Type: image/gif; name="woodnymph63.gif" Content-Transfer-Encoding: base64 Content-ID: <000101c69145$a40e6a36$1380a8c0@npk49> R0lGODdhuQDDAMIAAAAAAD0uR////wAA//8AAOSooAAAAAAAACwAAAAAuQDDAAAD/iha2v4wSsEm tTi3qjPv2AeOpCOWaDqeauu+XsrCMn09s5Tb5K4yPl4vEhSaXrNgkWjUNZ9QTXHZUoJOVCpPu4Jx KlYcpMCNmpk08Nl586J2rPIZvm2/Q+u8fj8Byvl4gIGChIWGbn0/NllphxuDhX8lanUWkopiUZeO k0KbcwuGn0ajnJVXpnYdPqyYQ2OdrqCQsqm2t2yqj7qes41duJnBw7eticSWNb2oyId0vLB8YU1k zdbJ179PxqXY2bZ/3YjUx8gBAR/n31DPecYd6grxyeK13yL1E+cBAvvr4OU4qZvXbx+/ggUJJow3 T2EVNEdo/Svhr8HBhBgz9rPI/pCfwzsTIfKpqGrgRYQROpK0p23NNCMrF5p0QNBgw49m8jn6tPIm wgo+Gdw8GTISj5ko5Xk82ZEmP6EKdTpr5q8q06VOlWaV+RDgzlxbEVa0unVsU5yhdjFbxTKbQpMz a140KHYu0VdFpeVF4o2UJpAx+OLdC40t4W0S10mNNbiw42YfxE15jAFtWhdS8fUl7NAHWnQtD+9h sS+OvrsclfmlvEhkaAt0haVEDTag6GUuYms1exDug6F2F55yPSvH5NpMzpEZqrT3UudloWeMefsv iXgFQBcEGlxuau/e224WLKqy9KTzsm9Pvftq0vchwUTGAsimWfZ1w6ovTTd8/vXXxM0WHX5IadWe gPi1httE4d3E3XvqHQgBdvAlFqAU0XR1WQ1L9FSgT/expw5Q71m24WiHOfRhdzb9BkaLJdJmHSdA aLjXYgFtgmNmmFnIGjBfBfbfkCFQMp4p9Wh2oo244MiOgu4seU+PQo6gG2MayJiYFkYil8Jb5+VB nW1LcIAaf6d5OKZsGHYCpoHumOhlCPaJ+JFKBq4p5YI+6QWnGQPJY9ENd5ZFKGpOnkagXWqSBRxR 3LUIXFa8KaolfNWEpakjfaLEaJ6+DdqcBHjayVFvERJkpkd9dPbbmZcKUmCF+X2nJU7YuWcqnLiy Otul1PnDSGNZouNfneDd/sUfbU0l2Cx6Ml75agZ3xgrIfrqC6N6bfw7o7EERQltZdsxqp+iE1lLJ plNEzeouVgmGm06YDQYHVWW05rtptxfaRlG4EgZc65+9KrWqt+LCht6+G1lEYoKmxIStc9KRm9Ry FMPyLKiLQiyqRwfHKM+DHO+5JH0wqEgxvBjN2o/F5k5b4ZWdpscuwM21y6jOcoqnR8+EzJAukSgE B9mEPyadl9DSqus0qUSvdu04Svusmlom1DgVk4Z1namf62Jpz3xeYV11lSM1HXWiPgJq9IL+ztl1 1LC1a81LdPfwmYfTgann2Xmb3cUJxiLI3MtPmfspikUtBiMF2V4UbsFy/me4AcqBq1Aawed1KlOs knChE9tx182yp2/n+vaRmffr9LsGWlxy7HbIkUTrX05bb8cit4k76zWovmvCqGc8ONq/I88Vu7oS 35+1pB8tNjmWR791eVcHY/1aw2w/5W06cp2K94d1mfzc5gwdihZqNyGjaf9wq6jsngBNQ7nmqez6 GKPIT2qYpYiQcS6UA4PgzDKl4hf3+rKDTjHNbWLy1c4UZifl7O8JnnucSpoXqjXZh2XSmtioBIS/ sPUObiCo2alAFbPDFa5C99II6tg1Qgp9538pVJz62BAOp9APXSzkYOpK6B/nfQFWDQNisZonCMKd 7nNBDEvNiMjEKXos/mcIstzLZJYK2HGMXMcaIg63+C3e5Qsq/jsXw8i3wjIWT4hmlFkRrahAEqUx i/sqk+8CxDf2pOqFvBKj4aooSH1txGYmopwegZTDqxhvg8ZDCf0K9sMZmrFQhwRXDEOxMS627WuV 8yQWmwUXEBZSjsqKCR1fpcrHvfF57XMaG7W4v0QNLUnYO99TsrG9bngPc7QcjtQueD703a10T0Jm MaI0kVky82kUcSUvs2eUBUbzisNUXticqU1GwgNchrwBNyNSzGsuIC4TzBlJXBlLJLVtGMmK3IRS 1caGyG2cJuwm4IpFk02e0GAkPAk+90gsFNZteP/0G1nWR1DRkK9O/pyToneE4k/w5ZNTSHRjQp/Y JLQNlJ9KjCh8WshRiSyynGrcFCkPOKL7CMVkWHMS3sgThWrhQDcfHOXOdkijbIayoLj5aJc+mhPG YSJ079ynMYlEVMHhrqnIgWr5jEoMqX6Jp8JRJkVQ+isHbshlprOmU6HGShueSoPSJKc3lSpRBVJK cua5gC3R9JO/xdEXmrNb1v73Evu9IFANY+L/VpfLg45xebVKK1dWNKL2RBKIt5IcaQRLlWj1pp5Y CQoX+6jDSLkVsHgc7M2wulS5WsmygxyY2TJ4lU1aMF+gpSG1ykWbj+7trAyBChhvK9LZea6sh01p G1R1UarpgLgc/nEtdCAJV17NC2G/HcOYEAjOIwBtgJXrEGpJKjAZJre3liQe1Gx6rsmCrU1vaU/I QBMoIJB3o4HE5qByK1/LVHJGwZTtDCuVn+hC67noOSI2L0vKXcb3N/LVw2TQqlMJKXaSqQzjgKXV tE6q04ThU+uN9JkSHMzSfFZ1CSJI+6MQi097NFlrE39K1esRs7gGbWh2WczVbi4GlAzN79RUrE+r isCvqw0TNGus4+DewcIaxuvvSIPUkCJGx8CcHn5zU92zXvI5z8PtiQFj3CK/GKQy++NzUiO7nrRR q8O8HTVhLAn9kcyLSMaPie8RmX3trl4VRZxdk0zkokUYRi16/rOQddjnpJ52F6+9TCtnByES5/cL hu6yjCNSwFSmSY4k+xPOLAo8CDp5cbuSSyQDKNZkWg0bOb1wijdL4cLFjK0wjbGph9yDOmduzkHz clGpJ8wdl7ZIzwwlN3y95p6OlaaFll6yvaAkZEc6acfxqUP5fNJZP5nXyuAm/HiMbS7zGNfJa7aG 2Qbu8R37e+48JpQKe+5lmxvG3Hb3NeZsa2+Xx5dsuvG0v4ziYK+43blemyW0Bmt/A9XDgyl3vJEx rHdPJcNbPh/56v1rBaO7HfJGhEwPbm1xAxzeaO4ojQE06ZB/fJlV0LeIp5rxll/b3hWvpslwHHFZ /HLhMed3I1XppvCdu1zSamlqz4v9ZEjTesoO7/TPCY7zo3N83SUHRAIAADs= ------=_NextPart_000_0001_01C6910A.F7BDCF30-- From tessholtzclaw@entermediate.com Fri Jun 16 11:38:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrGPF-0007lR-D2 for eap-archive@ietf.org; Fri, 16 Jun 2006 11:38:45 -0400 Received: from [58.208.100.92] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FrGPD-0007Lx-2q for eap-archive@ietf.org; Fri, 16 Jun 2006 11:38:45 -0400 Message-ID: <000001c6915a$bcf69a80$0100007f@localhost> From: "Elijah Moore" To: Subject: Corel Draw Date: Fri, 16 Jun 2006 23:38:45 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6915A.BCF69A80" 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-Spam-Score: 0.6 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6915A.BCF69A80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Special Offer Adobe Video Collection Adobe Premiere 1.5 Professional Adobe After Effects 6.5 Professional Adobe Audition 1.5 Adobe Encore DVD 1.5 $149.95 More Info >> Microsoft 2 in 1 MS Windows XP Pro MS Office 2003 Pro $99.95 More Info >> Microsoft + Adobe 3 in 1 MS Windows XP Pro MS Office 2003 Pro Adobe Acrobat 7.0 Professional $149.95 More Info >> Bestsellers Microsoft Office Professional Edition 2003 Rating: 6 reviews Retail price: $550.00 You save: $480.05 (87%) Our price: $69.95 [Add to cart] Microsoft Windows XP Professional Rating: 8 reviews Retail price: $200.00 You save: $150.05 (75%) Our price: $49.95 [Add to cart] Adobe Photoshop CS2 V 9.0 Rating: 3 reviews Retail price: $599.00 You save: $529.05 (88%) Our price: $69.95 [Add to cart] ------=_NextPart_000_0001_01C6915A.BCF69A80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable DS
Special Offer
Adobe Video Collection
  • Adobe Premiere 1.5 Professional
  • Adobe After Effects 6.5 Professional
  • Adobe Audition 1.5
  • Adobe Encore DVD 1.5
$149.95    
More Info >>
Microsoft 2 in 1
  • MS Windows XP Pro
  • MS Office 2003 Pro




$99.95    
More Info >>
Microsoft + Adobe 3 in 1
  • MS Windows XP Pro
  • MS Office 2003 Pro
  • Adobe Acrobat 7.0 Professional


$149.95    
More Info >>
Bestsellers
3D"" Microsoft Office Professional Edition 2003
Rating: 6 reviews
Retail price: $550.00
You save: $480.05 (87%)
Our price: $69.95		  

Add to cart

3D"" Microsoft Windows XP Professional
Rating: 8 reviews
Retail price: $200.00
You save: $150.05 (75%)
Our price: $49.95		  

Add to cart

3D"" Adobe Photoshop CS2 V 9.0
Rating: 3 reviews
Retail price: $599.00
You save: $529.05 (88%)
Our price: $69.95		  

Add to cart

------=_NextPart_000_0001_01C6915A.BCF69A80-- From hertzle@awarehiv.org Fri Jun 16 13:45:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrINz-0005eL-KQ for eap-archive@ietf.org; Fri, 16 Jun 2006 13:45:35 -0400 Received: from lns-bzn-46-82-253-253-72.adsl.proxad.net ([82.253.253.72] helo=awarehiv.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FrINx-000552-2a for eap-archive@ietf.org; Fri, 16 Jun 2006 13:45:35 -0400 Message-ID: <000001c6916c$b2049ca0$da57a8c0@kxe80> Reply-To: "Timour Hertzler" From: "Timour Hertzler" To: eap-archive@ietf.org Subject: hamiq test Date: Fri, 16 Jun 2006 10:45:45 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C69132.05A5C4A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.0 (++++) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C69132.05A5C4A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0002_01C69132.05A5C4A0" ------=_NextPart_001_0002_01C69132.05A5C4A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable http://wortundanse.com _____ =20 from the stones no spider has ever liked being called Attercop, and Tomnoddy of course is insulting to anybody. Off Bilbo scuttled to a fresh place, but several of the spiders had run now to different points in the glade where they lived, and were busy spinning webs across all the spaces between the tree-stems. Very soon the hobbit would be caught in a thick fence of them all round him-that at least was the spiders ------=_NextPart_001_0002_01C69132.05A5C4A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

from the stones no spider has ever liked being called = Attercop, and
Tomnoddy of course is insulting to anybody. Off Bilbo scuttled to a
fresh place, but several of the spiders had run now to different = points
in the glade where they lived, and were busy spinning webs across = all
the spaces between the tree-stems. Very soon the hobbit would be = caught
in a thick fence of them all round him-that at least was the = spiders
------=_NextPart_001_0002_01C69132.05A5C4A0-- ------=_NextPart_000_0001_01C69132.05A5C4A0 Content-Type: image/gif; name="cube42.gif" Content-Transfer-Encoding: base64 Content-ID: <000101c6916c$b2023f28$da57a8c0@kxe80> R0lGODdhvgDDAMIAAAAAADsPQf///wAA//8AANSurwAAAAAAACwAAAAAvgDDAAAD/ii63N7lyUmr vThiobf/YChS3VVCzzkq6uourRuV8WvfTI3vOrr/wGDq1RP6jEhW8lf8NB1Ppeipod1qsWJ0shVG uzbwcowriI2tc1DNMYHTWSSbDJyjGYGALa/gt+l0XXZCfi5+hVKAHnODUEuIe3qJIY0mI1p1L5AL eYV5Gp56naMcHaOSRDCKEh2VQIigARGyfXydbYeSt5wsu6yrFq5NmCCbiLkCx7rLk5yomUzAZQ3G z8jKtdnUp2Ou0kF+rae5vsmSBcx4qJuUU2tD3xLVE+Xm2tjOIFg5XPE+ViQiOWBX65m9g+EOavMH T1U7hvwW5rDm7Ny9dAUzToPI/tHCKXTO0D0Dua0iJFIEpZlx1LFlBW8uX8ZcYWdlP389Wl1ROfPm KoBJYPLs+etOMDmXwnDckpOoPFINcSYdGjNU1IcZnPQUiuNksz9Lr3qxBEiHipSjTIkit20XV61j 3/God7GiRk92O3p7iyRtvlgLrT5IuUgmS6pywX6Aik+wQnNQnS6x6VLkWnWB12nOV1myIlvWMArG 900NX4di95QkWTezRMLQiOpU6sExsl6c1N6FXdSz78GdTljG7LrgZcW9DdNMITza7+cBd0JXQmz6 ac9Aseqro6K6OzlmjzifniqooPFbj6pHKrZSU7gYeGvy9WaDQfFSBRKnh3EH/l3th1m031O0lJRf CSfdZ+AmdjAIX0TqQAUYfxpJhBxqG7AhEmfiybeCh/P9oRk7oBAXWVWbmZTiiVbdMhxq4xwHmUGg LaOgPTeCSBqE8YSD127G7bfLkDnaaGJoRj7WiyhP8ThQaOhpBxqFCJXzCQe2FYkllCywliVwyVwI WyxcbrecRzIah4xlqGxYnJKc7filhSZB4SEskFyXXD6k3cZiigoRdNtrgDoGXIIXVHPGDHxZyeUn bApZqJaP9TkpBWnC+SSYMalVZjIT/smhoUcOeGWggA4GqoFcGDRhZxmRCeSMSaLK4YI09jcnNbMo OY+mdLpUzZRVRroriYPW/inprSq25aiat4wzlV7keXRYap2GVy0MDZK17bdB3cjDV0aBe+165o4b FroZSjaIntOy242TPDQHjLTSkTuZIvB21aaC3a3bbmIEb3fWp8+dVpOwUNri6YjBNavshRQHZFq6 GFKZTTkkDdtHXj/i561sG4XI56eIggmivLRVvEi/xayIcpmzcLPyuWdiDB++lZb57MYF7smyzo8o uKOX/zYsrsj5PZTG0Caz2rOF2NycMUQwg2N0rhe5ylagRFeL7JOhcDMjqv+Frba6A6/tNnlZ56vd eQBe/fbIdz/oE855Q+0uttjJwN6A9qUNTkvEnGY2sCcXvvThzhbJM8+I/uswmh41EJso5uXSmo7h y37LhymFV9HMCVaPYMvHYTJ7qOsl65uV1KwuTuziEU5ZttLLZM6kxsCn/pOd94UK8mWkZvboiLNu Ki5r/CEpfOdpiMvONZdZniqefejWfZNbPx4sZEIL3ejz60SK41qGO+Zma7ZCeCIelDVpv+zx6sfp 5VXO/+bUWBrV0tDxPsIZqAXTe4f2eKS5KpkDQdcDVAEHlTxeBc2AGISdZLyyvlKtDnaGasylMIUQ A67kgpyCji+wlyTdpSo3zLJJ0HZFjY/5iUZVMIYGfWM7XRDQgeSonzpeNbH42cMKuDvbakYXub7R i4dP1Fnc8mcE8fGN/mmFKcxsSBCw8tUtdomKh7b6oSEn8qg+UfRidGYiDDN9pyz5Mp3A4jI4M1Lt glN0IxXTtcDxlccneWyZbzYEunk5MZC86hmRlCgxpF3xb3N02cEokhEiFYh5HYyiexDpmfalSVA2 GtPs5IY3wDEEdQlCycwiU0j8rYGTf9THzzL5prJFcnjKeWQIbqc073GvQnsxJNGi1UCHlQoGobSi 3gQZtvq1iC0iTBJIEliwjE3xfGAZHTEBeDbNUbNpt7SjLse5N6fQzY6w3EjWxig4u7FCiDnD4jKz GJszWlOeZjrnUb5ATrfpsxRsZGZQ1khQu8GzAv4bZXzwuUc64gd6/g4sqDvRpMx5tq6JBFJGK11p yugwEX5k+KZ6JlerI33OamXEYgWjpASRbq516xjiQCbCOj/S014M1cb7dockQsooiSqaJsQwY8kh fLBVaEohigRY00WSb4K5odTPbEk+YB1VqffLYD1r88mtTY0whYDg925FwRfyiUAINQZEFfrG3hQT Ym+FE+WOSahaWk8Wd03qpth2ha5uCTBV49r4tDkzu6b1VLTD6pYQR7aSXDCucpJqYY1IGKFmdYsM kg9T/IOoqok1svb7Jfw8sZIY/BSDFjmEVjuqNa4VtX+KBCZdRzvCmYaJf3ESTX968itV2qWB3ZQs 2XxmVjXxY367/nOWOF3K2u1UlFoTHahNAclWQ7D0bUB1WecSxc860lONJItneH9DBe2SQWF+q250 CfHcXLo3p287g9XQ0t62mROXXL3ZWpH5RZG9pYvvFGhr20vNdE50i23Fb5BO1kL21W6F7HsuTtVb Svh2pKwNfqoIu1ahfqbxuoiJj26ZaqmvIuy9H+boVAxMJR9d6qMz9OuOdNmIPMYtRiMG2rJwPDVG NZeM7soOZ+n6zB17lYgJq+Yrlkdi4mpqxqekMOC6+yGNUhavycoyN73LHD2Cl5TA07Fr5spT3OxQ ouwUZ3rNx68fu7k0alYw3Cxs38DhF14shoCB82xn8cYZzoz9/rOgvQwdPsdOjn7mcoIHXWFGK9nR +xInot054QlL9M+GJnRDIb3Vtqb5u9Vs4yDXa9EvZ9pb5XU0ggtdZ02n+GnjFWOsUazmTz86xYNO tYrfzExGXFrAiW4mp4fd6fTwdVvvKTaoiY0/79y3nMvmYnvO64SFMRuO43RPPQ8aaKxJ99ak/raq I+1h84KRaBc7t7q4cmogX7ta7RZ0vN0N7XKXOmdiYDey333IZ+Na2P+mdrjNHc5d87vgAW+0wLsd bGy3mo/blTKI/aZtcsfy4cA+dJ8T7nBJNxyc3MIYTOYd4mrLeeJrNhfJD77PjcPb4yxPuUMXrt1F xfzmbe54EpdkbnFm/xe6fFu5whedgyYkAAA7 ------=_NextPart_000_0001_01C69132.05A5C4A0-- From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Jun 16 14:58:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrJWq-0003Ak-VX for eap-archive@lists.ietf.org; Fri, 16 Jun 2006 14:58:48 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrJWp-0006cP-Cd for eap-archive@lists.ietf.org; Fri, 16 Jun 2006 14:58:48 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5A04A430112 for ; Fri, 16 Jun 2006 11:58:46 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 3C808430054 for ; Fri, 16 Jun 2006 11:58:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2951A1448004 for ; Fri, 16 Jun 2006 11:58:26 -0700 (PDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by hermes.tigertech.net (Postfix) with ESMTP id 4EBDE1448003 for ; Fri, 16 Jun 2006 11:58:23 -0700 (PDT) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5GIwM6n023637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 16 Jun 2006 11:58:23 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5GIwIC3017570; Fri, 16 Jun 2006 11:58:21 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Jun 2006 11:58:09 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 16 Jun 2006 11:58:02 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB84A1D8D0@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Questions for draft-barany-eap-gee-01 Thread-Index: AcaPKfrArqBSqKnCTSGCGKjjuIdsIgAy8wMQAF+tUmA= From: "Narayanan, Vidya" To: "Alper Yegin" , "Dondeti, Lakshminath" , "Quinn Li" , "Cao Zhen" X-OriginalArrivalTime: 16 Jun 2006 18:58:09.0822 (UTC) FILETIME=[CF63A3E0:01C69176] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: eap@frascone.com Subject: Re: [eap] Questions for draft-barany-eap-gee-01 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Alper, It is not a question of whether this functionality can or cannot be put into the lower layer - of course, it can be done. But, the functionality can be provided in a generic enough way that there is no reason it should be done at each lower layer separately. And, I don't believe that EAP doesn't have extra fields by "design" - EAP was originally defined for PPP and it has been generically extended to work on other layers since - so, we live with what has been designed already! We can have this argument of whether supporting this in the lower layer or a "shim" like GEE is the right approach forever - the question to really answer is whether or not this functionality (multiple parallel EAP exchanges) is something that is applicable to more than one lower layer. We believe the answer to that question is yes - hence, the work is being proposed in the IETF. And, about the word "layer", what we have been saying is that GEE is not an EAP *lower* layer - we can reword "layer" to something else more appropriate if that helps avoid confusion. If you have a suggestion, please let us know. Regards, Vidya > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@yegin.org] > Sent: Thursday, June 15, 2006 11:09 AM > To: Dondeti, Lakshminath; 'Quinn Li'; 'Cao Zhen' > Cc: eap@frascone.com > Subject: Re: [eap] Questions for draft-barany-eap-gee-01 > > You were earlier questioning if parallel EAP runs was ever > possible. This is different than saying you'd design it once > for all L2s. > > Regarding the first question, in fact, I don't know if there > is any EAP lower layer that cannot achieve what you are looking for. > > It's true EAP does not have extra fields for this use (by > design!), but the "EAP lower layers" do have. And that's > where the functionality you are seeking belongs to. > > I also find your "layering" responses very confusing. If > EAP-GEE is not a layer, why does your document call it "GEE > layer" and nicely puts it below the "EAP layer"? > > Peer Authenticator > +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ > | | | | | | > | EAP method| EAP method| | EAP method| EAP method| > | Type = X | Type = Y | | Type = X | Type = Y | > | V | | | ^ | | > +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ > | ! | | ! | > | EAP ! Peer layer | | EAP ! Auth. layer | > | ! | | ! | > +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ > | ! | | ! | > | EAP ! layer | | EAP ! layer | > | ! | | ! | > +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ > | ! | | ! | > | GEE ! layer | | GEE ! layer | > | ! | | ! | > +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ > | ! | | ! | > | Lower ! layer | | Lower ! layer | > | ! | | ! | > +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ > ! ! > ! ! > +------------>-------------+ > > > > > Alper > > > > > -----Original Message----- > > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] > > Sent: Tuesday, June 13, 2006 1:43 PM > > To: Alper Yegin; 'Quinn Li'; 'Cao Zhen' > > Cc: eap@frascone.com > > Subject: RE: [eap] Questions for draft-barany-eap-gee-01 > > > > At 01:13 PM 6/13/2006, Alper Yegin wrote: > > > > With your last statement, are you saying that there is > another way > > > > to demultiplex multiple parallel EAP exchanges? If so, > I would like to > > > > read about it. Please share the reference. Thanks. > > > > > >I don't see any inherent problems with an EAP lower layer > performing > > >such multiplexing, if they are really after such an optimization. > > > > The advantage of doing this at the IETF is to design it at the EAP > > level and allow use by multiple lower layers and multiple > purposes. > > The original authors had one use case, Joe and Parviz > joined us with > > another use case. Designing support for multiple EAP > conversations is > > not new at the IETF. All that GEE is doing is adding support for > > parallel authentications. > > > > >Especially not > > >to the extent that one needs to design a new layer to > solve the problem. > > > > No, GEE is *not* another "layer." If EAP had an extra field in the > > header, GEE might not have been needed. > > > > best, > > Lakshminath > > > > > > > >Alper > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap > > Arhives: http://lists.frascone.com/pipermail/eap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From tansyebel@fhhjpc.com Fri Jun 16 22:34:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrQde-00022h-Tc for eap-archive@ietf.org; Fri, 16 Jun 2006 22:34:18 -0400 Received: from 20158174249.user.veloxzone.com.br ([201.58.174.249] helo=fhhjpc.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FrQdd-0002QC-Eq for eap-archive@ietf.org; Fri, 16 Jun 2006 22:34:18 -0400 X-Spam-Score: 1.6 (+) X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 From eap-bounces+eap-archive=lists.ietf.org@frascone.com Sat Jun 17 04:55:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrWaS-0008QW-8D for eap-archive@lists.ietf.org; Sat, 17 Jun 2006 04:55:24 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrWaQ-00016P-HC for eap-archive@lists.ietf.org; Sat, 17 Jun 2006 04:55:24 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 77F454300FD for ; Sat, 17 Jun 2006 01:55:21 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 45B5A4300C9 for ; Sat, 17 Jun 2006 01:55:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3501C39803F for ; Sat, 17 Jun 2006 01:55:04 -0700 (PDT) X-Greylist-Status: Sender first seen 3 days 23:03:25 ago Received: from hitachi.cn (static-ip-10-194-65-202.rev.dyxnet.com [202.65.194.10]) by zoidberg.tigertech.net (Postfix) with SMTP id 27241398030 for ; Sat, 17 Jun 2006 01:54:59 -0700 (PDT) Received: (qmail 347 invoked from network); 17 Jun 2006 08:54:56 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk1;eac43bdbd236148e6c3ddf3ecfcb96a1; Received: from unknown (HELO hitachihk5.hitachi.cn) (170.95.94.1)by static-ip-11-194-65-202.rev.dyxnet.com with SMTP; 17 Jun 2006 08:54:56 -0000 Received: (qmail 19242 invoked from network); 17 Jun 2006 08:54:56 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk5;6422dae0c025470a87f7340a6839cd4f; Received: from hchidc204.hitachi-china.com (HELO hchidc204.hitachi.cn) (170.95.82.6)by 172.16.10.9 with SMTP; 17 Jun 2006 08:54:56 -0000 Received: from hcbjdc2.hitachi.cn ([170.95.81.2]) by hchidc204.hitachi.cn with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Jun 2006 16:54:49 +0800 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Sat, 17 Jun 2006 16:54:47 +0800 Message-ID: <834B54D356AA8F46B9B233DD88BEAA38019234CF@hcbjdc2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Questions for draft-barany-eap-gee-01 Thread-Index: AcaPKfrArqBSqKnCTSGCGKjjuIdsIgAy8wMQAF+tUmAAHZgN1g== From: "DENG, HUI -HCHBJ" To: "Narayanan, Vidya" , "Alper Yegin" , "Dondeti, Lakshminath" , "Quinn Li" , "Cao Zhen" X-OriginalArrivalTime: 17 Jun 2006 08:54:49.0021 (UTC) FILETIME=[B07186D0:01C691EB] X-Scanned-By-hitachihk5: Virus scan performed by network-box X-Scanned-By-hitachihk5: Scanner file id is hitachihk5-1150534496.59-19237-000 X-Scanned-By-hitachihk5: No known viruses found in message (received+scanned in 0.02/0.07 secs) X-Scanned-By-hitachihk5: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Scanned-By-hitachihk1: Virus scan performed by network-box X-Scanned-By-hitachihk1: Scanner file id is hitachihk1-1150534496.804-338-000 X-Scanned-By-hitachihk1: No known viruses found in message (received+scanned in 0.02/0.02 secs) X-Scanned-By-hitachihk1: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Scanned-By-hitachihk1: Whitelisted with valid signature (outbound via Network Box hitachihk5) X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.074 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO, RCVD_BY_IP X-Spam-Level: Cc: eap@frascone.com Subject: Re: [eap] Questions for draft-barany-eap-gee-01 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 SGksIFZpZHlhLA0KIA0KSSBhbSBub3QgaGFwcHkgd2l0aCB0aGUgd29yZCAiZ2VuZXJpYyIgaW4g dGhpcyBkcmFmdCwNClRoaXMgaWRlYSBvbmx5IHN1cHBvcnQgb25lIGFwcGxpY2F0aW9uOiBNVk5P Lg0KTWVhbndoaWxlIG5vdCBhbGwgbG93ZXIgbGV2ZWwgbmVlZCB0aGlzLg0KIA0KVGhpbmtpbmcg YWJvdXQgaG93IG1hbnkgcGVvcGxlIHVzZSBNVk5PLCANCmFuZCBob3cgbWFueSBwZW9wbGUgaXMg dGhlIHN1YnNjcmliZXIgb2YgTW9iaWxlIElQLg0KIA0KLUh1aQ0KDQoJLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0gDQoJRnJvbTogTmFyYXlhbmFuLCBWaWR5YSBbbWFpbHRvOnZpZHlhbkBxdWFs Y29tbS5jb21dIA0KCVNlbnQ6IDIwMDYtNi0xNyAo5pif5pyf5YWtKSAyOjU4IA0KCVRvOiBBbHBl ciBZZWdpbjsgRG9uZGV0aSwgTGFrc2htaW5hdGg7IFF1aW5uIExpOyBDYW8gWmhlbiANCglDYzog ZWFwQGZyYXNjb25lLmNvbSANCglTdWJqZWN0OiBSZTogW2VhcF0gUXVlc3Rpb25zIGZvciBkcmFm dC1iYXJhbnktZWFwLWdlZS0wMQ0KCQ0KCQ0KDQoJQWxwZXIsDQoJSXQgaXMgbm90IGEgcXVlc3Rp b24gb2Ygd2hldGhlciB0aGlzIGZ1bmN0aW9uYWxpdHkgY2FuIG9yIGNhbm5vdCBiZSBwdXQNCglp bnRvIHRoZSBsb3dlciBsYXllciAtIG9mIGNvdXJzZSwgaXQgY2FuIGJlIGRvbmUuIEJ1dCwgdGhl IGZ1bmN0aW9uYWxpdHkNCgljYW4gYmUgcHJvdmlkZWQgaW4gYSBnZW5lcmljIGVub3VnaCB3YXkg dGhhdCB0aGVyZSBpcyBubyByZWFzb24gaXQNCglzaG91bGQgYmUgZG9uZSBhdCBlYWNoIGxvd2Vy IGxheWVyIHNlcGFyYXRlbHkuIEFuZCwgSSBkb24ndCBiZWxpZXZlIHRoYXQNCglFQVAgZG9lc24n dCBoYXZlIGV4dHJhIGZpZWxkcyBieSAiZGVzaWduIiAtIEVBUCB3YXMgb3JpZ2luYWxseSBkZWZp bmVkDQoJZm9yIFBQUCBhbmQgaXQgaGFzIGJlZW4gZ2VuZXJpY2FsbHkgZXh0ZW5kZWQgdG8gd29y ayBvbiBvdGhlciBsYXllcnMNCglzaW5jZSAtIHNvLCB3ZSBsaXZlIHdpdGggd2hhdCBoYXMgYmVl biBkZXNpZ25lZCBhbHJlYWR5IQ0KCQ0KCVdlIGNhbiBoYXZlIHRoaXMgYXJndW1lbnQgb2Ygd2hl dGhlciBzdXBwb3J0aW5nIHRoaXMgaW4gdGhlIGxvd2VyIGxheWVyDQoJb3IgYSAic2hpbSIgbGlr ZSBHRUUgaXMgdGhlIHJpZ2h0IGFwcHJvYWNoIGZvcmV2ZXIgLSB0aGUgcXVlc3Rpb24gdG8NCgly ZWFsbHkgYW5zd2VyIGlzIHdoZXRoZXIgb3Igbm90IHRoaXMgZnVuY3Rpb25hbGl0eSAobXVsdGlw bGUgcGFyYWxsZWwNCglFQVAgZXhjaGFuZ2VzKSBpcyBzb21ldGhpbmcgdGhhdCBpcyBhcHBsaWNh YmxlIHRvIG1vcmUgdGhhbiBvbmUgbG93ZXINCglsYXllci4gV2UgYmVsaWV2ZSB0aGUgYW5zd2Vy IHRvIHRoYXQgcXVlc3Rpb24gaXMgeWVzIC0gaGVuY2UsIHRoZSB3b3JrDQoJaXMgYmVpbmcgcHJv cG9zZWQgaW4gdGhlIElFVEYuDQoJDQoJQW5kLCBhYm91dCB0aGUgd29yZCAibGF5ZXIiLCB3aGF0 IHdlIGhhdmUgYmVlbiBzYXlpbmcgaXMgdGhhdCBHRUUgaXMgbm90DQoJYW4gRUFQICpsb3dlciog bGF5ZXIgLSB3ZSBjYW4gcmV3b3JkICJsYXllciIgdG8gc29tZXRoaW5nIGVsc2UgbW9yZQ0KCWFw cHJvcHJpYXRlIGlmIHRoYXQgaGVscHMgYXZvaWQgY29uZnVzaW9uLiBJZiB5b3UgaGF2ZSBhIHN1 Z2dlc3Rpb24sDQoJcGxlYXNlIGxldCB1cyBrbm93Lg0KCQ0KCVJlZ2FyZHMsDQoJVmlkeWENCgkN Cgk+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoJPiBGcm9tOiBBbHBlciBZZWdpbiBbbWFp bHRvOmFscGVyLnllZ2luQHllZ2luLm9yZ10NCgk+IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDE1LCAy MDA2IDExOjA5IEFNDQoJPiBUbzogRG9uZGV0aSwgTGFrc2htaW5hdGg7ICdRdWlubiBMaSc7ICdD YW8gWmhlbicNCgk+IENjOiBlYXBAZnJhc2NvbmUuY29tDQoJPiBTdWJqZWN0OiBSZTogW2VhcF0g UXVlc3Rpb25zIGZvciBkcmFmdC1iYXJhbnktZWFwLWdlZS0wMQ0KCT4NCgk+IFlvdSB3ZXJlIGVh cmxpZXIgcXVlc3Rpb25pbmcgaWYgcGFyYWxsZWwgRUFQIHJ1bnMgd2FzIGV2ZXINCgk+IHBvc3Np YmxlLiBUaGlzIGlzIGRpZmZlcmVudCB0aGFuIHNheWluZyB5b3UnZCBkZXNpZ24gaXQgb25jZQ0K CT4gZm9yIGFsbCBMMnMuDQoJPg0KCT4gUmVnYXJkaW5nIHRoZSBmaXJzdCBxdWVzdGlvbiwgaW4g ZmFjdCwgSSBkb24ndCBrbm93IGlmIHRoZXJlDQoJPiBpcyBhbnkgRUFQIGxvd2VyIGxheWVyIHRo YXQgY2Fubm90IGFjaGlldmUgd2hhdCB5b3UgYXJlIGxvb2tpbmcgZm9yLg0KCT4NCgk+IEl0J3Mg dHJ1ZSBFQVAgZG9lcyBub3QgaGF2ZSBleHRyYSBmaWVsZHMgZm9yIHRoaXMgdXNlIChieQ0KCT4g ZGVzaWduISksIGJ1dCB0aGUgIkVBUCBsb3dlciBsYXllcnMiIGRvIGhhdmUuIEFuZCB0aGF0J3MN Cgk+IHdoZXJlIHRoZSBmdW5jdGlvbmFsaXR5IHlvdSBhcmUgc2Vla2luZyBiZWxvbmdzIHRvLg0K CT4NCgk+IEkgYWxzbyBmaW5kIHlvdXIgImxheWVyaW5nIiByZXNwb25zZXMgdmVyeSBjb25mdXNp bmcuIElmDQoJPiBFQVAtR0VFIGlzIG5vdCBhIGxheWVyLCB3aHkgZG9lcyB5b3VyIGRvY3VtZW50 IGNhbGwgaXQgIkdFRQ0KCT4gbGF5ZXIiIGFuZCBuaWNlbHkgcHV0cyBpdCBiZWxvdyB0aGUgIkVB UCBsYXllciI/DQoJPg0KCT4gICAgICAgICAgICAgICAgIFBlZXIgICAgICAgICAgICAgICAgICAg QXV0aGVudGljYXRvcg0KCT4gICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rICArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rDQoJPiAgICAgICAgIHwgICAgICAgICAgIHwgICAgICAgICAg IHwgIHwgICAgICAgICAgIHwgICAgICAgICAgIHwNCgk+ICAgICAgICAgfCBFQVAgbWV0aG9kfCBF QVAgbWV0aG9kfCAgfCBFQVAgbWV0aG9kfCBFQVAgbWV0aG9kfA0KCT4gICAgICAgICB8IFR5cGUg PSBYICB8IFR5cGUgPSBZICB8ICB8IFR5cGUgPSBYICB8IFR5cGUgPSBZICB8DQoJPiAgICAgICAg IHwgICAgICAgViAgIHwgICAgICAgICAgIHwgIHwgICAgICAgXiAgIHwgICAgICAgICAgIHwNCgk+ ICAgICAgICAgKy0rLSstKy0hLSstKy0rLSstKy0rLSstKyAgKy0rLSstKy0hLSstKy0rLSstKy0r LSstKw0KCT4gICAgICAgICB8ICAgICAgICEgICAgICAgICAgICAgICB8ICB8ICAgICAgICEgICAg ICAgICAgICAgICB8DQoJPiAgICAgICAgIHwgIEVBUCAgISBQZWVyIGxheWVyICAgIHwgIHwgIEVB UCAgISBBdXRoLiBsYXllciAgIHwNCgk+ICAgICAgICAgfCAgICAgICAhICAgICAgICAgICAgICAg fCAgfCAgICAgICAhICAgICAgICAgICAgICAgfA0KCT4gICAgICAgICArLSstKy0rLSEtKy0rLSst Ky0rLSstKy0rICArLSstKy0rLSEtKy0rLSstKy0rLSstKy0rDQoJPiAgICAgICAgIHwgICAgICAg ISAgICAgICAgICAgICAgIHwgIHwgICAgICAgISAgICAgICAgICAgICAgIHwNCgk+ICAgICAgICAg fCAgRUFQICAhIGxheWVyICAgICAgICAgfCAgfCAgRUFQICAhIGxheWVyICAgICAgICAgfA0KCT4g ICAgICAgICB8ICAgICAgICEgICAgICAgICAgICAgICB8ICB8ICAgICAgICEgICAgICAgICAgICAg ICB8DQoJPiAgICAgICAgICstKy0rLSstIS0rLSstKy0rLSstKy0rLSsgICstKy0rLSstIS0rLSst Ky0rLSstKy0rLSsNCgk+ICAgICAgICAgfCAgICAgICAhICAgICAgICAgICAgICAgfCAgfCAgICAg ICAhICAgICAgICAgICAgICAgfA0KCT4gICAgICAgICB8ICAgR0VFICEgbGF5ZXIgICAgICAgICB8 ICB8ICAgR0VFICEgbGF5ZXIgICAgICAgICB8DQoJPiAgICAgICAgIHwgICAgICAgISAgICAgICAg ICAgICAgIHwgIHwgICAgICAgISAgICAgICAgICAgICAgIHwNCgk+ICAgICAgICAgKy0rLSstKy0h LSstKy0rLSstKy0rLSstKyAgKy0rLSstKy0hLSstKy0rLSstKy0rLSstKw0KCT4gICAgICAgICB8 ICAgICAgICEgICAgICAgICAgICAgICB8ICB8ICAgICAgICEgICAgICAgICAgICAgICB8DQoJPiAg ICAgICAgIHwgTG93ZXIgISBsYXllciAgICAgICAgIHwgIHwgTG93ZXIgISBsYXllciAgICAgICAg IHwNCgk+ICAgICAgICAgfCAgICAgICAhICAgICAgICAgICAgICAgfCAgfCAgICAgICAhICAgICAg ICAgICAgICAgfA0KCT4gICAgICAgICArLSstKy0rLSEtKy0rLSstKy0rLSstKy0rICArLSstKy0r LSEtKy0rLSstKy0rLSstKy0rDQoJPiAgICAgICAgICAgICAgICAgISAgICAgICAgICAgICAgICAg ICAgICAgICAgIQ0KCT4gICAgICAgICAgICAgICAgICEgICAgICAgICAgICAgICAgICAgICAgICAg ICENCgk+ICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tPi0tLS0tLS0tLS0tLS0rDQoJPg0K CT4NCgk+DQoJPg0KCT4gQWxwZXINCgk+DQoJPg0KCT4NCgk+ID4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCgk+ID4gRnJvbTogTGFrc2htaW5hdGggRG9uZGV0aSBbbWFpbHRvOmxkb25kZXRp QHF1YWxjb21tLmNvbV0NCgk+ID4gU2VudDogVHVlc2RheSwgSnVuZSAxMywgMjAwNiAxOjQzIFBN DQoJPiA+IFRvOiBBbHBlciBZZWdpbjsgJ1F1aW5uIExpJzsgJ0NhbyBaaGVuJw0KCT4gPiBDYzog ZWFwQGZyYXNjb25lLmNvbQ0KCT4gPiBTdWJqZWN0OiBSRTogW2VhcF0gUXVlc3Rpb25zIGZvciBk cmFmdC1iYXJhbnktZWFwLWdlZS0wMQ0KCT4gPg0KCT4gPiBBdCAwMToxMyBQTSA2LzEzLzIwMDYs IEFscGVyIFllZ2luIHdyb3RlOg0KCT4gPiA+ID4gV2l0aCB5b3VyIGxhc3Qgc3RhdGVtZW50LCBh cmUgeW91IHNheWluZyB0aGF0IHRoZXJlIGlzDQoJPiBhbm90aGVyIHdheQ0KCT4gPiA+ID4gdG8g ZGVtdWx0aXBsZXggbXVsdGlwbGUgcGFyYWxsZWwgRUFQIGV4Y2hhbmdlcz8gIElmIHNvLA0KCT4g SSB3b3VsZCBsaWtlIHRvDQoJPiA+ID4gPiByZWFkIGFib3V0IGl0LiAgIFBsZWFzZSBzaGFyZSB0 aGUgcmVmZXJlbmNlLiAgVGhhbmtzLg0KCT4gPiA+DQoJPiA+ID5JIGRvbid0IHNlZSBhbnkgaW5o ZXJlbnQgcHJvYmxlbXMgd2l0aCBhbiBFQVAgbG93ZXIgbGF5ZXINCgk+IHBlcmZvcm1pbmcNCgk+ ID4gPnN1Y2ggbXVsdGlwbGV4aW5nLCBpZiB0aGV5IGFyZSByZWFsbHkgYWZ0ZXIgc3VjaCBhbiBv cHRpbWl6YXRpb24uDQoJPiA+DQoJPiA+IFRoZSBhZHZhbnRhZ2Ugb2YgZG9pbmcgdGhpcyBhdCB0 aGUgSUVURiBpcyB0byBkZXNpZ24gaXQgYXQgdGhlIEVBUA0KCT4gPiBsZXZlbCBhbmQgYWxsb3cg dXNlIGJ5IG11bHRpcGxlIGxvd2VyIGxheWVycyBhbmQgbXVsdGlwbGUNCgk+IHB1cnBvc2VzLiAN Cgk+ID4gVGhlIG9yaWdpbmFsIGF1dGhvcnMgaGFkIG9uZSB1c2UgY2FzZSwgSm9lIGFuZCBQYXJ2 aXoNCgk+IGpvaW5lZCB1cyB3aXRoDQoJPiA+IGFub3RoZXIgdXNlIGNhc2UuICBEZXNpZ25pbmcg c3VwcG9ydCBmb3IgbXVsdGlwbGUgRUFQDQoJPiBjb252ZXJzYXRpb25zIGlzDQoJPiA+IG5vdCBu ZXcgYXQgdGhlIElFVEYuICBBbGwgdGhhdCBHRUUgaXMgZG9pbmcgaXMgYWRkaW5nIHN1cHBvcnQg Zm9yDQoJPiA+IHBhcmFsbGVsIGF1dGhlbnRpY2F0aW9ucy4NCgk+ID4NCgk+ID4gPkVzcGVjaWFs bHkgbm90DQoJPiA+ID50byB0aGUgZXh0ZW50IHRoYXQgb25lIG5lZWRzIHRvIGRlc2lnbiBhIG5l dyBsYXllciB0bw0KCT4gc29sdmUgdGhlIHByb2JsZW0uDQoJPiA+DQoJPiA+IE5vLCBHRUUgaXMg Km5vdCogYW5vdGhlciAibGF5ZXIuIiAgSWYgRUFQIGhhZCBhbiBleHRyYSBmaWVsZCBpbiB0aGUN Cgk+ID4gaGVhZGVyLCBHRUUgbWlnaHQgbm90IGhhdmUgYmVlbiBuZWVkZWQuDQoJPiA+DQoJPiA+ IGJlc3QsDQoJPiA+IExha3NobWluYXRoDQoJPiA+DQoJPiA+ID4NCgk+ID4gPkFscGVyDQoJPg0K CT4NCgk+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQoJPiBUbyB1bnN1YnNjcmliZSBvciBtb2RpZnkgeW91ciBzdWJzY3Jp cHRpb24gb3B0aW9ucywgcGxlYXNlIHZpc2l0Og0KCT4gaHR0cDovL2xpc3RzLmZyYXNjb25lLmNv bS9tYWlsbWFuL2xpc3RpbmZvL2VhcA0KCT4NCgk+IEFyaGl2ZXM6IGh0dHA6Ly9saXN0cy5mcmFz Y29uZS5jb20vcGlwZXJtYWlsL2VhcA0KCT4NCglfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KCVRvIHVuc3Vic2NyaWJlIG9y IG1vZGlmeSB5b3VyIHN1YnNjcmlwdGlvbiBvcHRpb25zLCBwbGVhc2UgdmlzaXQ6DQoJaHR0cDov L2xpc3RzLmZyYXNjb25lLmNvbS9tYWlsbWFuL2xpc3RpbmZvL2VhcA0KCQ0KCUFyaGl2ZXM6IGh0 dHA6Ly9saXN0cy5mcmFzY29uZS5jb20vcGlwZXJtYWlsL2VhcA0KCQ0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpUbyB1 bnN1YnNjcmliZSBvciBtb2RpZnkgeW91ciBzdWJzY3JpcHRpb24gb3B0aW9ucywgcGxlYXNlIHZp c2l0OgpodHRwOi8vbGlzdHMuZnJhc2NvbmUuY29tL21haWxtYW4vbGlzdGluZm8vZWFwCgpBcmhp dmVzOiBodHRwOi8vbGlzdHMuZnJhc2NvbmUuY29tL3BpcGVybWFpbC9lYXA= From tkovfnsz-mcu@sigmachip.com Sat Jun 17 05:28:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrX6l-0006WH-33 for eap-archive@ietf.org; Sat, 17 Jun 2006 05:28:47 -0400 Received: from [212.209.173.54] (helo=[212.209.173.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrX6j-0004mq-Md for eap-archive@ietf.org; Sat, 17 Jun 2006 05:28:47 -0400 Message-ID: <03710514.20060617092844@sigmachip.com> Date: Sat, 17 Jun 2006 09:28:44 -0060 From: "Socorro Maloney" Reply-To: "Socorro Maloney" To: eap-archive@ietf.org Subject: The Stock Market Bulls Say MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 4.3 (++++) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 For attention. We found company ready to EXPLODE!! Put CGDC on your radar's now. This shows a significant up in price and sometimes in days, not months or years. Watch CGDC like a hawk Monday!! The alert is on!! CHINA GOLD CORP Sym: CGDC Current Price: 0.30 A Company engaged in gold and minerals exploration and development of gold and mineral properties in China. Why consider CHINA GOLD CORP (CGDC)? Seee n0wadays what happened. Rising gold prices are further accelerating this gold rush - The price of gold has up 250% over the past five years, and this is still only a quarter of when the price peaked 25 years ago. (Adjusted for inflation.) HUGE gold discovery in southwestern China - Resources have already been estimated by analysts at 14 million ounces...and the number keeps climbing. China is the worlds last great under-explored land-mass - Locked away in a Marxist time-warp with limited exploration technology, China rich virgin gold fields have been overlooked and ignored until recently. China is already the world 4th largest producer of gold ?and will soon be the world #1 producer AND #1 consumer. The country is going gold-crazy! Foreign gold companies are now welcome - and the laws have been changed to provide full legal protection. You can see China developing gold boom is building momentum. Rare 0pp0rtunity for early investors!! CURRENT NEWS: China Gold Corp. Announces Shareholder Update China Gold Corp. (CGDC - News) is a Nevada Corporation, engaged in gold and minerals exploration and development of gold and mineral properties in China. The company is pleased to announce has entered into negotiations with Zhong Cui Investments LTD. for the acquisition of Gold Mine property in the rural mountainous Guang Ning District near Zhao Qing City, Guangdong Province of China. China Gold Corp. is currently evaluating the Gold Mine property preliminary geological information and the property. If the company due diligence produces favorable results, management is expected to sign the letter of intent with Zhong Cui Investments LTD. in the next thirty (30) days. The Letter of Intent requires both parties to draft a definitive agreement and terms of any subsequent joint venture. Property description and all additional information will be available upon finalization of the agreement. The company will be made further announcements in this regard in coming weeks. ABOUT THE COMPANY China Gold Corp. is a Nevada Corporation, engaged in gold and minerals exploration and development of gold and mineral properties in China. China Gold Corp. is dedicated to delivering growth to the shareholder by employing a disciplined business methodology through acquisitions and joint ventures. The Company seeks to acquire properties with the following development criteria: largely unexplored but highly prospective geological regions, ability to generate near-term revenue and cash flow, tremendous geological potential for world-class economic deposits. From ulisesi@aquariusnature.com Sat Jun 17 15:49:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Frgnd-0008Ls-OZ for eap-archive@ietf.org; Sat, 17 Jun 2006 15:49:41 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Frgnd-0001Ig-NH for eap-archive@ietf.org; Sat, 17 Jun 2006 15:49:41 -0400 Received: from 182.red-88-1-153.dynamicip.rima-tde.net ([88.1.153.182] helo=aquariusnature.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Frgnc-00086O-30 for eap-archive@ietf.org; Sat, 17 Jun 2006 15:49:41 -0400 X-Spam-Score: 3.4 (+++) X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 From mowzgzawyx@page-kraemer.com Sat Jun 17 22:48:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrnKx-0006ok-8l for eap-archive@ietf.org; Sat, 17 Jun 2006 22:48:31 -0400 Received: from [60.3.41.196] (helo=page-kraemer.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Frn9I-0006BA-0H for eap-archive@ietf.org; Sat, 17 Jun 2006 22:46:06 -0400 Received: from 60.3.41.196 by mailin8.page-kraemer.com;Sun, 18 Jun 2006 10:36:01 +0800 Date: Sun, 18 Jun 2006 10:36:01 +0800 From: "jcekyimq kssilc" X-Sender: mowzgzawyx@page-kraemer.com To: , Subject: In motion for H.Y.W.I Water doesn't run uphill. X-Mailer: Microsoft Outlook Express 6.00.2462.0000 Message-Id: <2876925056.521384-33498518-2628@page-kraemer.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 4.4 (++++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Hollywood Intermediate Inc. (SYM : H Y W I) Current Sh Price : $ 0.74 This price will be history coming next week Follow the performance of this company, it is a real gold mine Make a quick buck with HYWI has performed like clockwork every time CO OverView H o l l y w o o d I n t e r m e d i a t e provides a proprietary technology of Digital Intermediate services to feature filmmakers for post-production for film mastering and restoration. This technology gives the filmmakers total creative control over the look of their productions. Whether shooting on film or acquiring in HD or SD video, H o l l y w o o d I n t e r m e d i a t e puts a powerful cluster of digital tools at the director's disposal to achieve stunning results on the big screen. Matchframe Digital Intermediate, a division of H o l l y w o o d I n t e r m e d i a t e, Inc., packages a full array of post-production services with negative handling expertise and cost-effective 2K digital intermediate and 35mm film out systems. The Digital Intermediate process eliminates current post-production redundancies by creating a single high-resolution master file from which all versions can be made, including all theatrical and High Definition formats. By creating a single master file with resolution higher than the current High Definition broadcast standards, the DI master file enables cinema and television distributors to extract and archive all current and future cinema and television formats including Digital Cinema, Television and High Definition. Red H0t News: H o l l y w o o d I n t e r m e d i a t e a provider of digital intermediate film mastering services, announced today that that its Matchframe Digital Intermediate (MDI) division is completing a digital intermediate for Chad Lowe's directorial debut, "Beautiful Ohio," starring William Hurt and Rita Wilson. READ MORE THIS IS HUGE H o l l y w o o d I n t e r m e d i a t e Expands the Creative Palette for Independent Filmmakers GLENDALE, CA--(MARKET WIRE)--May 31, 2006 -- H o l l y w o o d I n t e r m e d i a t e, Inc. A provider of digital intermediate film mastering services, announced today that its Matchframe Digital Intermediate division is currently providing full digital intermediate services for Super 16MM productions. H o l l y w o o d I n t e r m e d i a t e, Inc. (H Y W I - News), a provider of digital intermediate film mastering services, announced that High Definition preview masters as part of its normal digital intermediate service offerings and workflow. "Typically, in current post-production workflow, HD dailies masters are edited into high quality preview masters including color timing, dirt removal, opticals and visual effects," said David Waters, H o l l y w o o d I n t e r m e d i a t e president. "Unfortunately, none of these processes translate to the theatrical release of the film as they must all be duplicated or repeated in either a higher resolution digital format, or photo chemical process." H o l l y w o o d I n t e r m e d i a t e gives Motion Picture producers the ability to scan their selected original camera negative at 2k or 4k film resolution, conform a high resolution digital master for theatrical and broadcast release including dirt removal, opticals and visual effects, and output a High Definition preview master to be used for preview screenings and focus groups that can be deployed in any worldwide theater location. "The challenge for completing the final editorial decisions on a motion picture are balanced between the ability to display the highest resolution picture for a test audience, and the costs and time in having to re-master your film based on a test audience response," said Jim Delany, H o l l y w o o d I n t e r m e d i a t e COO. DO your Due Diligence and you'll see what we are talking about when it comes to H Y W I ----------------------- Your name is mud. What goes down usually comes up. Shall I compare thee to a summer's day. When you get lemons, make lemonade.(When life gives you scraps make quilts.) Shit happens. Still water runs dirty and deep. Stir up an ant's nest. Treat him like dirt. Stubborn as a mule. Still water runs dirty and deep. Your in hot water. A rolling stone gathers no moss. Sturdy as an oak. A tree does not move unless there is wind. Timber! Two peas in a pod. You can't squeeze blood out of a turnip. The shoes on the other foot now. Season of mists and mellow fruitfulness. Putting the cart before the horse. The stronger the breeze the stronger the trees. Welcome to my garden. Sow much, reap much; sow little, reap little. Walking on water. Spring rain, Fall gold. Tools of the tr@de. Still water runs dirty and deep. Rise and shine. The scythe ran into a stone. Want my place in the sun. Rain, rain go away; come again some other day. A stepping stone to. Water under the bridge. What goes down usually comes up. Run to seed. Speak softly and carry a big stick. You reap what you sow. Sick as a dog. Red as a beet. Which came first, the chicken or the egg. From ispmuogefed@page-kraemer.com Sat Jun 17 22:48:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrnL2-0006qZ-30 for eap-archive@ietf.org; Sat, 17 Jun 2006 22:48:36 -0400 Received: from [60.3.41.196] (helo=page-kraemer.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FrnB8-0006Z3-Vh for eap-archive@ietf.org; Sat, 17 Jun 2006 22:39:00 -0400 Received: from 60.3.41.196 by mailin2.page-kraemer.com;Sun, 18 Jun 2006 10:37:47 +0800 Date: Sun, 18 Jun 2006 10:37:47 +0800 From: "zannvik chcqqod" X-Sender: ispmuogefed@page-kraemer.com To: Subject: Forward looking speculation H_Y_W_I Stubborn as a mule. X-Mailer: Microsoft Outlook, Build 10.0.2616 Message-Id: <1631366302.787407-32001997-8889@page-kraemer.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 4.4 (++++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Hollywood Intermediate Inc. (SYM : H Y W I) Current Sh Price : $ 0.74 This price will be history coming next week Follow the performance of this company, it is a real gold mine oh ya, thats the one HYWI has performed like clockwork every time CO OverView H o l l y w o o d I n t e r m e d i a t e provides a proprietary technology of Digital Intermediate services to feature filmmakers for post-production for film mastering and restoration. This technology gives the filmmakers total creative control over the look of their productions. Whether shooting on film or acquiring in HD or SD video, H o l l y w o o d I n t e r m e d i a t e puts a powerful cluster of digital tools at the director's disposal to achieve stunning results on the big screen. Matchframe Digital Intermediate, a division of H o l l y w o o d I n t e r m e d i a t e, Inc., packages a full array of post-production services with negative handling expertise and cost-effective 2K digital intermediate and 35mm film out systems. The Digital Intermediate process eliminates current post-production redundancies by creating a single high-resolution master file from which all versions can be made, including all theatrical and High Definition formats. By creating a single master file with resolution higher than the current High Definition broadcast standards, the DI master file enables cinema and television distributors to extract and archive all current and future cinema and television formats including Digital Cinema, Television and High Definition. Red H0t News: H o l l y w o o d I n t e r m e d i a t e a provider of digital intermediate film mastering services, announced today that that its Matchframe Digital Intermediate (MDI) division is completing a digital intermediate for Chad Lowe's directorial debut, "Beautiful Ohio," starring William Hurt and Rita Wilson. READ MORE THIS IS HUGE H o l l y w o o d I n t e r m e d i a t e Expands the Creative Palette for Independent Filmmakers GLENDALE, CA--(MARKET WIRE)--May 31, 2006 -- H o l l y w o o d I n t e r m e d i a t e, Inc. A provider of digital intermediate film mastering services, announced today that its Matchframe Digital Intermediate division is currently providing full digital intermediate services for Super 16MM productions. H o l l y w o o d I n t e r m e d i a t e, Inc. (H-Y-W-I - News), a provider of digital intermediate film mastering services, announced that High Definition preview masters as part of its normal digital intermediate service offerings and workflow. "Typically, in current post-production workflow, HD dailies masters are edited into high quality preview masters including color timing, dirt removal, opticals and visual effects," said David Waters, H o l l y w o o d I n t e r m e d i a t e president. "Unfortunately, none of these processes translate to the theatrical release of the film as they must all be duplicated or repeated in either a higher resolution digital format, or photo chemical process." H o l l y w o o d I n t e r m e d i a t e gives Motion Picture producers the ability to scan their selected original camera negative at 2k or 4k film resolution, conform a high resolution digital master for theatrical and broadcast release including dirt removal, opticals and visual effects, and output a High Definition preview master to be used for preview screenings and focus groups that can be deployed in any worldwide theater location. "The challenge for completing the final editorial decisions on a motion picture are balanced between the ability to display the highest resolution picture for a test audience, and the costs and time in having to re-master your film based on a test audience response," said Jim Delany, H o l l y w o o d I n t e r m e d i a t e COO. DO your Due Diligence and you'll see what we are talking about when it comes to H-Y-W-I.PK ----------------------- Through the grapevine. Spill the beans. You throw filth on the living and flowers on the dead.Pin a rose on your nose. Raking in the dough. You have to separate the chaff from the wheat. Plant kindness and gather love. Read the tea leaves. Sweating blood. Weed 'um and reap. The season of goodwill. Weed it out. Shit end of the stick. Which came first, the chicken or the egg. A rolling stone gathers no moss. You throw filth on the living and flowers on the dead.Pin a rose on your nose. Red as a beet. When the cows come home. Rain, rain go away; come again some other day. To rule the mountains is to rule the river. Strong as an ox. What goes down usually comes up. Put off the scent. A place in the sun. Up one side and down the other. Slow as a snail. Say it with flowers. Putting the cart before the horse. We'll cross that bridge when we come to it. Weed it out. You feel like a fish out of water. Spring rain, Fall gold. Your ass is grass. You feel like a fish out of water. To rule the mountains is to rule the river. Raking in the dough. Spring to mind. Rise and shine. Shiver me timber. A thorn in my side. Which came first, the chicken or the egg. What on earth? From goezyzm@page-kraemer.com Sat Jun 17 22:48:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrnL2-0006qZ-CV for eap-archive@ietf.org; Sat, 17 Jun 2006 22:48:36 -0400 Received: from [60.3.41.196] (helo=page-kraemer.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FrnAW-0006OD-5n for eap-archive@ietf.org; Sat, 17 Jun 2006 22:38:19 -0400 Received: from 60.3.41.196 by rly1.page-kraemer.com;Sun, 18 Jun 2006 10:36:54 +0800 Date: Sun, 18 Jun 2006 10:36:54 +0800 From: "qydrpryg nlqcrtnks" X-Sender: goezyzm@page-kraemer.com To: , Subject: your pr man is back H.Y.W.I Tools of the tr@de. X-Mailer: eGroups Message Poster Message-Id: <5900066553.451797-29084562-1600@page-kraemer.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 4.0 (++++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Hollywood Intermediate Inc. (SYM : H Y W I) Current Sh Price : $ 0.74 This price will be history coming next week Follow the performance of this company, it is a real gold mine In motion for HYWI has performed like clockwork every time CO OverView H o l l y w o o d I n t e r m e d i a t e provides a proprietary technology of Digital Intermediate services to feature filmmakers for post-production for film mastering and restoration. This technology gives the filmmakers total creative control over the look of their productions. Whether shooting on film or acquiring in HD or SD video, H o l l y w o o d I n t e r m e d i a t e puts a powerful cluster of digital tools at the director's disposal to achieve stunning results on the big screen. Matchframe Digital Intermediate, a division of H o l l y w o o d I n t e r m e d i a t e, Inc., packages a full array of post-production services with negative handling expertise and cost-effective 2K digital intermediate and 35mm film out systems. The Digital Intermediate process eliminates current post-production redundancies by creating a single high-resolution master file from which all versions can be made, including all theatrical and High Definition formats. By creating a single master file with resolution higher than the current High Definition broadcast standards, the DI master file enables cinema and television distributors to extract and archive all current and future cinema and television formats including Digital Cinema, Television and High Definition. Red H0t News: H o l l y w o o d I n t e r m e d i a t e a provider of digital intermediate film mastering services, announced today that that its Matchframe Digital Intermediate (MDI) division is completing a digital intermediate for Chad Lowe's directorial debut, "Beautiful Ohio," starring William Hurt and Rita Wilson. READ MORE THIS IS HUGE H o l l y w o o d I n t e r m e d i a t e Expands the Creative Palette for Independent Filmmakers GLENDALE, CA--(MARKET WIRE)--May 31, 2006 -- H o l l y w o o d I n t e r m e d i a t e, Inc. A provider of digital intermediate film mastering services, announced today that its Matchframe Digital Intermediate division is currently providing full digital intermediate services for Super 16MM productions. H o l l y w o o d I n t e r m e d i a t e, Inc. (H Y W I . P K - News), a provider of digital intermediate film mastering services, announced that High Definition preview masters as part of its normal digital intermediate service offerings and workflow. "Typically, in current post-production workflow, HD dailies masters are edited into high quality preview masters including color timing, dirt removal, opticals and visual effects," said David Waters, H o l l y w o o d I n t e r m e d i a t e president. "Unfortunately, none of these processes translate to the theatrical release of the film as they must all be duplicated or repeated in either a higher resolution digital format, or photo chemical process." H o l l y w o o d I n t e r m e d i a t e gives Motion Picture producers the ability to scan their selected original camera negative at 2k or 4k film resolution, conform a high resolution digital master for theatrical and broadcast release including dirt removal, opticals and visual effects, and output a High Definition preview master to be used for preview screenings and focus groups that can be deployed in any worldwide theater location. "The challenge for completing the final editorial decisions on a motion picture are balanced between the ability to display the highest resolution picture for a test audience, and the costs and time in having to re-master your film based on a test audience response," said Jim Delany, H o l l y w o o d I n t e r m e d i a t e COO. DO your Due Diligence and you'll see what we are talking about when it comes to H_Y_W_I.PK ----------------------- Take time to smell the roses. Through the grapevine. You can't squeeze blood out of a turnip. Pull it up by the roots. Weed out. Your all washed up. Top of the morning. When the cows come home. You throw filth on the living and flowers on the dead.Pin a rose on your nose. Raking in the dough. To rule the mountains is to rule the river. Stuck in a rut. We'll hand you out to dry. When it rains it pours. When it rains it pours. Your ass is grass. We hung them out to dry. Say it with flowers. Salt of the Earth. You say potayto, I say potahto. Waking up with the chickens. A weed is no more than a flower in disguise. You throw filth on the living and flowers on the dead.Pin a rose on your nose. We hung them out to dry. Speak softly and carry a big stick. Walking on water. Rough as a cob. The stronger the breeze the stronger the trees. Putting the cart before the horse. Your in hot water. Shake like a leaf. Want my place in the sun. Plant kindness and gather love. Worry often gives a small thing a big shadow. Treat him like dirt. From fwjaye@nmcourts.com Sun Jun 18 11:08:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Frysx-0004kj-Lp for eap-archive@ietf.org; Sun, 18 Jun 2006 11:08:23 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FryEA-0004ma-Ej for eap-archive@ietf.org; Sun, 18 Jun 2006 10:26:14 -0400 Received: from ejr36.neoplus.adsl.tpnet.pl ([83.21.159.36] helo=nmcourts.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Frxur-0006td-Fj for eap-archive@ietf.org; Sun, 18 Jun 2006 10:06:18 -0400 Received: from 83.21.159.36 by mailin.mx2.nmcourts.com;Sun, 18 Jun 2006 16:06:25 +0100 Date: Sun, 18 Jun 2006 16:06:25 +0100 From: "vqyszl ctcxywqx" X-Sender: fwjaye@nmcourts.com To: , Subject: Emerging growth H Y W I Your name is mud. X-Mailer: QUALCOMM Windows Eudora Version 5.1 Message-Id: <7467367433.668845-95437918-3354@nmcourts.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 4.9 (++++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Hollywood Intermediate Inc. (SYM : H Y W I) Current Sh Price : $ 0.74 This price will be history coming next week Follow the performance of this company, it is a real gold mine win win situation HYWI has performed like clockwork every time CO OverView H o l l y w o o d I n t e r m e d i a t e provides a proprietary technology of Digital Intermediate services to feature filmmakers for post-production for film mastering and restoration. This technology gives the filmmakers total creative control over the look of their productions. Whether shooting on film or acquiring in HD or SD video, H o l l y w o o d I n t e r m e d i a t e puts a powerful cluster of digital tools at the director's disposal to achieve stunning results on the big screen. Matchframe Digital Intermediate, a division of H o l l y w o o d I n t e r m e d i a t e, Inc., packages a full array of post-production services with negative handling expertise and cost-effective 2K digital intermediate and 35mm film out systems. The Digital Intermediate process eliminates current post-production redundancies by creating a single high-resolution master file from which all versions can be made, including all theatrical and High Definition formats. By creating a single master file with resolution higher than the current High Definition broadcast standards, the DI master file enables cinema and television distributors to extract and archive all current and future cinema and television formats including Digital Cinema, Television and High Definition. Red H0t News: H o l l y w o o d I n t e r m e d i a t e a provider of digital intermediate film mastering services, announced today that that its Matchframe Digital Intermediate (MDI) division is completing a digital intermediate for Chad Lowe's directorial debut, "Beautiful Ohio," starring William Hurt and Rita Wilson. READ MORE THIS IS HUGE H o l l y w o o d I n t e r m e d i a t e Expands the Creative Palette for Independent Filmmakers GLENDALE, CA--(MARKET WIRE)--May 31, 2006 -- H o l l y w o o d I n t e r m e d i a t e, Inc. A provider of digital intermediate film mastering services, announced today that its Matchframe Digital Intermediate division is currently providing full digital intermediate services for Super 16MM productions. H o l l y w o o d I n t e r m e d i a t e, Inc. (H-Y-W-I - News), a provider of digital intermediate film mastering services, announced that High Definition preview masters as part of its normal digital intermediate service offerings and workflow. "Typically, in current post-production workflow, HD dailies masters are edited into high quality preview masters including color timing, dirt removal, opticals and visual effects," said David Waters, H o l l y w o o d I n t e r m e d i a t e president. "Unfortunately, none of these processes translate to the theatrical release of the film as they must all be duplicated or repeated in either a higher resolution digital format, or photo chemical process." H o l l y w o o d I n t e r m e d i a t e gives Motion Picture producers the ability to scan their selected original camera negative at 2k or 4k film resolution, conform a high resolution digital master for theatrical and broadcast release including dirt removal, opticals and visual effects, and output a High Definition preview master to be used for preview screenings and focus groups that can be deployed in any worldwide theater location. "The challenge for completing the final editorial decisions on a motion picture are balanced between the ability to display the highest resolution picture for a test audience, and the costs and time in having to re-master your film based on a test audience response," said Jim Delany, H o l l y w o o d I n t e r m e d i a t e COO. DO your Due Diligence and you'll see what we are talking about when it comes to H Y W I ----------------------- Shake like a leaf. The squeaky wheel gets the grease. The season of goodwill. Up one side and down the other. The scythe ran into a stone. Spring forward fall back. The scythe ran into a stone. Your name is mud. You have to separate the chaff from the wheat. Scraping the bottom of the barrel. The silly season. Shiver me timber. A rolling stone gathers no moss. She has a green thumb. Sly as a fox. Stir up an ant's nest. When we love - we grow. Take time to smell the roses. A thorn in my side. Top of the morning. She's a mother hen. Sturdy as an oak. Water doesn't run uphill. Still water runs dirty and deep. Walking on cloud nine. Too little too late. What goes down usually comes up. Play a harp before a cow. Up a tree. When we love - we grow. When it rains it pours. Watered down. Put that in your pipe and smoke it. Some like carrots others like cabbage. When the cows come home. Pull it up by the roots. Walking on cloud nine. From tkuehn@lapinefire.com Sun Jun 18 16:49:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fs4D9-0003WB-9n for eap-archive@ietf.org; Sun, 18 Jun 2006 16:49:35 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fs4D9-0006iS-5X for eap-archive@ietf.org; Sun, 18 Jun 2006 16:49:35 -0400 Received: from [84.50.190.33] (helo=[84.50.190.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fs4D8-00047I-6Q for eap-archive@ietf.org; Sun, 18 Jun 2006 16:49:35 -0400 Date: Thu, 15 Jun 2006 18:43:11 -0120 From: "Weston Whitley" X-Mailer: The Bat! (v4.37.7) Home Reply-To: "Weston Whitley" X-Priority: 3 (Normal) Message-ID: <34144115.20060615184311@lapinefire.com> To: eap-archive@ietf.org Subject: Calling All Small Stock Players MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 1.7 (+) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 For attention. We found company ready to EXPLODE!! Put C G D C on your radar's now. This shows a significant up in price and sometimes in days, not months or years. Watch CGDC like a hawk Monday!! The alert is on!! CH INA GOLD CORP Sym: C G D C Current Price: 0.30 A Company engaged in gold and minerals exploration and development of gold and mineral properties in China. Why consider CH INA GOLD CORP (C G D C)? See nowadays what happened. Rising gold prices are further accelerating this gold rush - The price of gold has up 250% over the past five years, and this is still only a quarter of when the price peaked 25 years ago. (Adjusted for inflation.) HUGE gold discovery in southwestern China - Resources have already been estimated by analysts at 14 million ounces...and the number keeps climbing. China is the worlds last great under-explored land-mass - Locked away in a Marxist time-warp with limited exploration technology, China rich virgin gold fields have been overlooked and ignored until recently. China is already the world 4th largest producer of gold ?and will soon be the world #1 producer AND #1 consumer. The country is going gold-crazy! Foreign gold companies are now welcome - and the laws have been changed to provide full legal protection. You can see China developing gold boom is building momentum. Rare 0pp0rtunity for early investors!! CURRENT NEWS: Ch ina Gold Corp. Announces Shareholder Update China Gold Corp. (C G D C - News) is a Nevada Corporation, engaged in gold and minerals exploration and development of gold and mineral properties in China. The company is pleased to announce has entered into negotiations with Zhong Cui Investments LTD. for the acquisition of Gold Mine property in the rural mountainous Guang Ning District near Zhao Qing City, Guangdong Province of China. China Gold Corp. is currently evaluating the Gold Mine property preliminary geological information and the property. If the company due diligence produces favorable results, management is expected to sign the letter of intent with Zhong Cui Investments LTD. in the next thirty (30) days. The Letter of Intent requires both parties to draft a definitive agreement and terms of any subsequent joint venture. Property description and all additional information will be available upon finalization of the agreement. The company will be made further announcements in this regard in coming weeks. From ErichRushing@mail.com Sun Jun 18 19:44:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fs6wb-0008SQ-2R for eap-archive@ietf.org; Sun, 18 Jun 2006 19:44:41 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fs6wa-0001et-QP; Sun, 18 Jun 2006 19:44:40 -0400 Received: from h34.27.141.67.ip.alltel.net ([67.141.27.34] helo=hno6q4ia.i98oim3u.rr.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fs6wa-0005av-0m; Sun, 18 Jun 2006 19:44:40 -0400 Message-ID: <56154402224727.7AA1690AB9@ZWT4T2WQ> From: "Erich Rushing" To: Subject: great up-grade on marcket, look through the email Date: Sun, 18 Jun 2006 19:44:24 -0400 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: 1JZGl7at5AcGjKPgZLtEetcvT6Y67cav2V0J Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.5 (++) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Learned how to put all your resources together for victory? There is something you might be missing. Strengthen your position with valuable stock information! When a next trading day starts, this stock will be extremely popular with biggest traders. Use your chance now! Get I FNX First Thing Today, This Is Going To Explaode! Infinex Ventures Inc. (I FN X) Current Price: 0.92 Company Overview: Aggressive and energetic, Infinex boasts a dynamic and diversified portfolio of operations across North America, with an eye on international expansion. Grounded in natural resource exploration, Inifinex also offers investors access to exciting new developments in the high-tech sector and the booming international real estate market. Our market based experience, tenacious research techniques, and razor sharp analytical skills allow us to leverage opportunities in emerging markets and developing technologies. Identifying these opportunities in the earliest stages allows us to accelerate business development and fully realize the company true potential. Maximizing overall profitability and in turn enhancing shareholder value. Current Press Release Infinex Ventures Inc.(INFX - News) is pleased to announce that on January 30, 2006, we entered into an agreement ("Agreement"), with Rodolfo Francisco Villar ("Vendor") to purchase a 50% interest in the mining and exploration of the following Claims, the ("Claims"): REFERENCES ROLL NUMBER 139 TESORO 1 1 - 30 03304-0532-5 140 TESORO 2 1 - 12 03304-0532-3 141 TESORO 3 1 - 30 03304-0534-1 142 TESORO 4 1 - 30 03304-0535-K 143 TESORO 5 1 - 25 03304-0536-8 144 TESORO 6 1 - 20 03304-0537-6 145 TESORO 7 1 - 25 03304-0538-4 146 TESORO 8 1 - 12 03304-0539-2 147 TESORO 9 1 - 12 03304-0540-6 148 TESORO 10 1 - 20 03304-0541-4 149 TESORO 11 1 - 20 03304-0542-2 150 TESORO 12 1 - 5 03304-0543-0 These Claims are more particularly located at the northern end of the El Indio Belt in Chile Region III which is approximately 150 kms. East of the City of Vallenar, Chile. 1. Under the terms of the Agreement, the Vendor will grant to the Company the sole and exclusive irrevocable right and title to the Claims, subject to: (i) the completion by the Company of confirmation of legal title and due diligence on the Properties as to ownership by the Vendor and results therefrom being satisfactory to the Company, acting reasonably, within a period of 90 days; (ii) the right to extend a further 90 days by mutual consent. (the right to extend a further 90 days has been granted to the Company, in an effort to complete its due diligence); (iii) The Vendor and the Company shall put forth, all their reasonable best efforts to obtain a satisfactory title opinion or Court Order, or such that the Company will acquire the property freee and clear of all liens and encumbrances, with a view to further develop the property into an operating mine. 2. Upon satisfactory completion of the due diligence and clear title being established, the Company will then: (a) issue to the Vendor Twenty Million (20,000,000) Common Shares, upon the execution by the parties of this Agreement and subject to the subject conditions as set out above; and (b) that all original documents or notarized copies of official translations are therefore required to complete the transactions contemplated in the Agreement. The issuance of the 20 Million (20,000,000) Common Shares shall be issued in the Vendors designated name to the benefit of Vendor, upon the removal of the subject conditions as set out above. 3. Further, satisfactory completion of the due diligence and clear title being established the Purchaser with the assistance of the Vendor, (if necessary), will apply for permits to the appropriate authorities to place the property into production. Upon the appropriate permits being approved, the Purchaser will have the option to acquire an additional 25% interest in the property (bringing the Purchaser interest to 75%) in exchange for a further issuance of Ten Million (10,000,000) Common shares of the Company's stock. We are presently pursuing further due diligence on these Claims. On Behalf of the Board INFINEX VENTURES INC.Conclusion: The Examples Above Show The Awesome, Earning Potential of Little Known Companies That Explode Onto Investor's Radar Screens; Many of You Are Already Familiar with This. Is IFN X Poised and Positioned to Do that For You? Then You May Feel the Time Has Come to Act... And Please Watch this One Trade on tomorrow! Go I FNX. This stock combines a no-hype situation with serious promises of a good rise. Money can’t buy everything, but it can help you enjoy your life a lot more. Good luck in your trading career – and don’t go spending all that at once! Sincerely, ErichRushing From 78X8hs7Xta@mail.ru Mon Jun 19 07:07:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsHbg-0005ry-Rd for eap-archive@ietf.org; Mon, 19 Jun 2006 07:07:48 -0400 Received: from cur2.internetdsl.tpnet.pl ([83.19.73.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsHbe-0007w5-Fr for eap-archive@ietf.org; Mon, 19 Jun 2006 07:07:48 -0400 Date: Mon, 19 Jun 2006 11:07:48 -0060 From: "Gail Hobbs" <78X8hs7Xta@mail.ru> X-Mailer: The Bat! (v2.04.7) CD5BF9353B3B7091 Reply-To: "Gail Hobbs" <78X8hs7Xta@mail.ru> X-Priority: 3 (Normal) Message-ID: <1396831390.20060619110748@mail.ru> To: eap-archive@ietf.org Subject: [fwd] TopPicker MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 0625-0, 2006-06-19), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.3 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 H o t _S t 0 c k for attention. We found company ready to EXPLODE!! Put CGDC on your radar's now. This st0ck shows a significant up in stock price and sometimes in days, not months or years. Watch CGDC like a hawk Monday!! The alert is on!! CHINA GOLD CORP Symbol: CGDC Current Price: 0.30 A Company engaged in gold and minerals exploration and development of gold and mineral properties in China. Why consider CHINA GOLD CORP (CGDC)? Seee n0wadays what happened. Rising gold prices are further accelerating this gold rush - The price of gold has up 250% over the past five years, and this is still only a quarter of when the price peaked 25 years ago. (Adjusted for inflation.) ?HUGE gold discovery in southwestern China - Resources have already been estimated by analysts at 14 million ounces...and the number keeps climbing. China is the worlds last great under-explored land-mass - Locked away in a Marxist time-warp with limited exploration technology, China rich virgin gold fields have been overlooked and ignored until recently. ?China is already the world 4th largest producer of gold ?and will soon be the world #1 producer AND #1 consumer. The country is going gold-crazy! ?Foreign gold companies are now welcome - and the laws have been changed to provide full legal protection. You can see China developing gold boom is building momentum. Rare 0pp0rtunity for early investors!! CURRENT NEWS: China Gold Corp. Announces Shareholder Update China Gold Corp. (CGDC - News) is a Nevada Corporation, engaged in gold and minerals exploration and development of gold and mineral properties in China. The company is pleased to announce has entered into negotiations with Zhong Cui Investments LTD. for the acquisition of Gold Mine property in the rural mountainous Guang Ning District near Zhao Qing City, Guangdong Province of China. China Gold Corp. is currently evaluating the Gold Mine property preliminary geological information and the property. If the company due diligence produces favorable results, management is expected to sign the letter of intent with Zhong Cui Investments LTD. in the next thirty (30) days. The Letter of Intent requires both parties to draft a definitive agreement and terms of any subsequent joint venture. Property description and all additional information will be available upon finalization of the agreement. The company will be made further announcements in this regard in coming weeks. ABOUT THE COMPANY China Gold Corp. is a Nevada Corporation, engaged in gold and minerals exploration and development of gold and mineral properties in China. China Gold Corp. is dedicated to delivering growth to the shareholder by employing a disciplined business methodology through acquisitions and joint ventures. The Company seeks to acquire properties with the following development criteria: largely unexplored but highly prospective geological regions, ability to generate near-term revenue and cash flow, tremendous geological potential for world-class economic deposits. From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Jun 19 16:51:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsQiq-0007Ws-6E for eap-archive@lists.ietf.org; Mon, 19 Jun 2006 16:51:48 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsQFA-0006uD-E1 for eap-archive@lists.ietf.org; Mon, 19 Jun 2006 16:21:08 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FsPxV-00066f-JT for eap-archive@lists.ietf.org; Mon, 19 Jun 2006 16:02:57 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 3A53E43016D for ; Mon, 19 Jun 2006 13:02:52 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 40F634300D0 for ; Mon, 19 Jun 2006 13:02:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1AF27398041 for ; Mon, 19 Jun 2006 13:02:32 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [217.160.230.40]) by zoidberg.tigertech.net (Postfix) with ESMTP id 446DB398029 for ; Mon, 19 Jun 2006 13:02:24 -0700 (PDT) Received: from [68.126.198.124] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrelayus0) with ESMTP (Nemesis), id 0MKoyl-1FsPwq2Cjv-0002la; Mon, 19 Jun 2006 16:02:23 -0400 From: "Alper Yegin" To: "'Narayanan, Vidya'" , "'Dondeti, Lakshminath'" , "'Quinn Li'" , "'Cao Zhen'" Date: Mon, 19 Jun 2006 13:02:11 -0700 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaPKfrArqBSqKnCTSGCGKjjuIdsIgAy8wMQAF+tUmAAmWGW8A== In-Reply-To: <2EBB8025B6D1BA41B567DB32C1D8DB84A1D8D0@NAEX06.na.qualcomm.com> Message-ID: <0MKoyl-1FsPwq2Cjv-0002la@mrelay.perfora.net> X-Provags-ID: perfora.net abuse@perfora.net login:abf7a4bb310ea4dfc9b6841113e2970f X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com Subject: Re: [eap] Questions for draft-barany-eap-gee-01 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: -2.3 (--) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd This is starting to look more like a solution looking for a problem. Earlier Lakshminath was asking if the EAP-GEE functionality could ever be done any other way. Now that the obvious answer is "yes", authors are saying EAP-GEE is good for doing it generically. Parallel EAP execution is just one of the possible features a given EAP lower layer can implement. I still don't understand why we need to carve that out of the EAP lower layer and spin a whole new layer and protocol for it. Those EAP lower layers that care about this feature are only one "session id" definition away from achieving that, if not done already. Alper > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > Sent: Friday, June 16, 2006 11:58 AM > To: Alper Yegin; Dondeti, Lakshminath; Quinn Li; Cao Zhen > Cc: eap@frascone.com > Subject: RE: [eap] Questions for draft-barany-eap-gee-01 > > Alper, > It is not a question of whether this functionality can or cannot be put > into the lower layer - of course, it can be done. But, the functionality > can be provided in a generic enough way that there is no reason it > should be done at each lower layer separately. And, I don't believe that > EAP doesn't have extra fields by "design" - EAP was originally defined > for PPP and it has been generically extended to work on other layers > since - so, we live with what has been designed already! > > We can have this argument of whether supporting this in the lower layer > or a "shim" like GEE is the right approach forever - the question to > really answer is whether or not this functionality (multiple parallel > EAP exchanges) is something that is applicable to more than one lower > layer. We believe the answer to that question is yes - hence, the work > is being proposed in the IETF. > > And, about the word "layer", what we have been saying is that GEE is not > an EAP *lower* layer - we can reword "layer" to something else more > appropriate if that helps avoid confusion. If you have a suggestion, > please let us know. > > Regards, > Vidya > > > -----Original Message----- > > From: Alper Yegin [mailto:alper.yegin@yegin.org] > > Sent: Thursday, June 15, 2006 11:09 AM > > To: Dondeti, Lakshminath; 'Quinn Li'; 'Cao Zhen' > > Cc: eap@frascone.com > > Subject: Re: [eap] Questions for draft-barany-eap-gee-01 > > > > You were earlier questioning if parallel EAP runs was ever > > possible. This is different than saying you'd design it once > > for all L2s. > > > > Regarding the first question, in fact, I don't know if there > > is any EAP lower layer that cannot achieve what you are looking for. > > > > It's true EAP does not have extra fields for this use (by > > design!), but the "EAP lower layers" do have. And that's > > where the functionality you are seeking belongs to. > > > > I also find your "layering" responses very confusing. If > > EAP-GEE is not a layer, why does your document call it "GEE > > layer" and nicely puts it below the "EAP layer"? > > > > Peer Authenticator > > +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ > > | | | | | | > > | EAP method| EAP method| | EAP method| EAP method| > > | Type = X | Type = Y | | Type = X | Type = Y | > > | V | | | ^ | | > > +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ > > | ! | | ! | > > | EAP ! Peer layer | | EAP ! Auth. layer | > > | ! | | ! | > > +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ > > | ! | | ! | > > | EAP ! layer | | EAP ! layer | > > | ! | | ! | > > +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ > > | ! | | ! | > > | GEE ! layer | | GEE ! layer | > > | ! | | ! | > > +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ > > | ! | | ! | > > | Lower ! layer | | Lower ! layer | > > | ! | | ! | > > +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ > > ! ! > > ! ! > > +------------>-------------+ > > > > > > > > > > Alper > > > > > > > > > -----Original Message----- > > > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] > > > Sent: Tuesday, June 13, 2006 1:43 PM > > > To: Alper Yegin; 'Quinn Li'; 'Cao Zhen' > > > Cc: eap@frascone.com > > > Subject: RE: [eap] Questions for draft-barany-eap-gee-01 > > > > > > At 01:13 PM 6/13/2006, Alper Yegin wrote: > > > > > With your last statement, are you saying that there is > > another way > > > > > to demultiplex multiple parallel EAP exchanges? If so, > > I would like to > > > > > read about it. Please share the reference. Thanks. > > > > > > > >I don't see any inherent problems with an EAP lower layer > > performing > > > >such multiplexing, if they are really after such an optimization. > > > > > > The advantage of doing this at the IETF is to design it at the EAP > > > level and allow use by multiple lower layers and multiple > > purposes. > > > The original authors had one use case, Joe and Parviz > > joined us with > > > another use case. Designing support for multiple EAP > > conversations is > > > not new at the IETF. All that GEE is doing is adding support for > > > parallel authentications. > > > > > > >Especially not > > > >to the extent that one needs to design a new layer to > > solve the problem. > > > > > > No, GEE is *not* another "layer." If EAP had an extra field in the > > > header, GEE might not have been needed. > > > > > > best, > > > Lakshminath > > > > > > > > > > >Alper > > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/eap > > > > Arhives: http://lists.frascone.com/pipermail/eap > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From arisha@advantecgs.com Tue Jun 20 02:35:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsZpv-0005RH-CY for eap-archive@ietf.org; Tue, 20 Jun 2006 02:35:43 -0400 Received: from bb58-185-164-97.singnet.com.sg ([58.185.164.97] helo=advantecgs.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FsZps-00025l-NS for eap-archive@ietf.org; Tue, 20 Jun 2006 02:35:43 -0400 Message-ID: <000001c69433$b72fbd80$b12ba8c0@iyi74> Reply-To: "Arisha Goguen" From: "Arisha Goguen" To: eap-archive@ietf.org Subject: rouua test Date: Mon, 19 Jun 2006 23:35:26 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C693F9.0AD0E580" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.8 (++++) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C693F9.0AD0E580 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0002_01C693F9.0AD0E580" ------=_NextPart_001_0002_01C693F9.0AD0E580 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable http://kerfousawer.com _____ =20 and brushwood round the tree-trunks. Others rushed round and stamped and beat, and beat and stamped, until nearly all the flames were put out-but they did not put out the fire nearest to the trees where the dwarves were. That fire they fed with leaves and dead branches and bracken. Soon they had a ring of smoke and flame all round the dwarves, a ring which they kept from spreading outwards; but it closed slowly in, till the ------=_NextPart_001_0002_01C693F9.0AD0E580 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

and brushwood round the tree-trunks. Others rushed = round and stamped and
beat, and beat and stamped, until nearly all the flames were put = out-but
they did not put out the fire nearest to the trees where the dwarves
were. That fire they fed with leaves and dead branches and bracken. = Soon
they had a ring of smoke and flame all round the dwarves, a ring = which
they kept from spreading outwards; but it closed slowly in, till = the
------=_NextPart_001_0002_01C693F9.0AD0E580-- ------=_NextPart_000_0001_01C693F9.0AD0E580 Content-Type: image/gif; name="perpetuity72.gif" Content-Transfer-Encoding: base64 Content-ID: <000101c69433$b72642be$b12ba8c0@iyi74> R0lGODdh0AC+AMIAAAAAAAZVWv///wAA//8AAI3nrgAAAAAAACwAAAAA0AC+AAAD/ii6tf4wyknr LM0ym7X/YNiFJDSCZ6lGKbdSLfsK8UzbSu1lo47/wFLNFywaSUTX8ZFcOp8/nhBKraqaOyt2trV6 bT1v9ysi38zo7wk7TrvfwLYmDK/buVq4/HLv+z97fH9FW4GDJQEBKIiJilNMORGOh2ISDYkPmBSa mpAvjUcxk5mjkqCklHMOnQqspq2lYAKuT42nGbSrjokjvItPe520J7lBxYUWmLsLtpu6sMV4hkwd LZ0FirjNsNCjwoqnpya2ypPbzOCcw7PgEtEQrO8wkWr0z9yt6Lv78R3h6u743Yunbt+rSb0C6PCX DV+qEOUmAGRHEJ1Fh6jYrUp4/lEjRgbtXtkz5S2Wj2lOIurahgmbOI8wvwV06PIeO20dSbm6FGsm QwdrKIlKZ3PiNp4dZYqsmFShw3fnPs7M+BAiU3wFSzZFhwGeQZxbn/ZkBlOq1xTH4nx52Q8rW3MI 4U5tGzbm2Etl83qdigfovJQEd2Fz+0+u2LmlJh42u8wVLcV+5V1x8xjUYI/llPn7CcuaQZ2JDeul qElb1KzNyDn91beqa3ivY1foqkqJGJRnRrYWJLt3JkK+gwv3g3uJZJJjZWzQLXGIkSRyqpEhl/Ng cq93AYEo5fLlSurdjgdfY1ieSg3if6gmPEf0cKu/PbT0G/Rj8b3LZtmUOD/9/qEYnvGnj0yoIUfU N20V5pdF10l2FX2P7AbEfPDgog835/kCFIIDwSXQaBrVkEtCJXmHhnM2UEhVhxo56B5TSoGoDEnt BXQday/c14qIHv5zE3i5LYaRYjFiNwpnmyTnXxkLTqfkZ5gRRVouwnB0UWlFIicSX1viWFU050WZ l4l27UckXDpIueJeAkbommOdwXjgfnWVdWYO5mFG555rAleHOAD9g1M5YFHlGJQxFtPYZ4dWp59Z 78EAXk2kiVnglpVdleWAoVXGDTFRZcEcC7iNsVCTJqRKhXTozYZDFwAuZ8lwOhahUAO1SvhqpH/O +tdzoQTpZq7/2bYEsVAQ/oESq8ky+R6xyLpqh3TRqvXHesZmy6us227n3rOe9GZquIDwyKefJwZR bW27JvnMYAj2COhpZLZLhrK2larcryA985ZU4VwYk7BuMNusdm9UtNqQoc20ZLcrrEvuK0jZqVV1 68kjsbMHp6LQOaVZLPBhD2trBh3BTmwtnw8WeU2YHO8r28YIN0nlkRc3ymBxBkMMjBA3Z1QQPQoO TLDJPh/LL8FBg8ZpVnbVW+wgyNKc7tKyIJ11PUmz23Wk91ltL9V1VNuGFLx5nUcfy06M4mRYSzvq 0TuILfNwoaaUit3msrhWySv0BKSRJQION92fNAxiSk1Mg22UgmfjI0W+/iKOatqiovetk7OmcJLD +ex4A5UDvVtFtTJVPOV3mt1Ew+Csq9SdVpZJPeOoLna5dtzJGIaNhdCwx9bIQsspcO1j3c6lOwFW tUWYQSvcYPJQilwmpMrrVIGJUsvQtnFquj7lrbTH8njxZiIaF8GzM5c7m3c4Hj4ntBHKoOIyVm98 Z5AOaDMRKoJUC8Z1OSPcAkPl89fFsKe/nIkmT4q60WgMdzLNNYwglMKQlRjIML9dTyJG4198sHIu uRWwZilSUWZEeBlQvGxoS1FcojYXOjVBxijlkWDM0OCp9nGodd/JH8D+9an8cc878XKal75Wwhxt DTaWc9PdeAVARx1s/oDyWWLEosA7XVmQgihUj9LGxsRhqaqMvokOt17TMzRWTihzIw4bqwC7M7rR jpl74g5nsKk7cvFqZ/PWCLtmCLup7YSJ44/CWhiy1zXCkGuEZKTIdKYPCYN4ftTjHYC0vw/2KY5b /MPGCtm7G6ovJ+dDlxPVEAhI8mR+pxQSGIFlQp/hpiUODMuD3oDFCsrmgrl05JUWeK8ueo5WOJjh YVQHQ+/00gm4+h4ZKUEOEi2wSnhyoQSjNQ1JHlI4e6ANGiXWRpV9k2uP8OYGoAXKSoTSj6fa3R/N Cc7YhG2KHevi4eK3R3y+U5R3VKcePkmCiRhSbOUU6D9nKSY85kah/ojEHG8+5weGbsiYP9unOPsZ mwimrkyqsWHekJAyL/4zDU0b2rzYwwzTrMqX/JRom9KHQL9BRYdRLFgtTXrS7Zkvl/vLVPfcWR+H ZlKoLKGXW4hGQ2TOs6I/XSMSGUXMaEBUiiuTqXqiaiP0WU+YYZxaGqLVtNBRzqYlCp5YMznFkHJq kGKZKsz0uYir7vMh3cwqPdlK12m5ja9lhBWEtoWrNSLNriSVZztjpcmr6dWvfaUlYMu2PKOGtbGQ fc07mqe7fOp0oIBJS2etKNmIlqGcqmLsWrUkSHXxtKdvLGZOU5TBFjUzHfgDGW5xyi7Eng5dlVTr Cq2Hww/Zsmt3/iLZNWH5VcJyFKtbFUuhoIemFzYXs3fVYh5dm7mQxjJEyx0fdV/6NYnRRZmaCh8q eVtatE2WP5xBb3hHREy2ZRRhqDWWD94i0vs5pZP62aVl0Ule0AYwQ3JJZbyqd5lzyra0OzUtdmP7 2bEG9rn1hC0D8ktAvKpSj/mV417f+9jIXljCYzyWe01c0pSpEaZ3DWSKoXvfaS6nUb6NcEyjeMxN NpXEQE4SbjFcthCzeLu/hKWPQgWePvpzZu38hdmEHAkPnRVQLTWIRYNcYdsxN4YfkyjfHGtjYxwq NQ2xmG7ZOzN8eTa0NoFXePGESS6/RyXS82DUUGzHHF82X9BU/iTl8jxMXbwScH4+KEoTrFIHWlK9 I06sU6G6gcwcKC49si1pKftkk9ZK0YqNsp0bZ+dSP7Vbfu4tW1csRdUSUrvqSnV5aWxqC3fawzUW sVaJTLYda222QEFoi0/tzsmy+teGze6fX7ucwgZ0idKsNYxhrWxgJ1vaEC7ztZ2bWl6fmMIaznCk x03gYw8Y29MW9Sq37eA3HxkJeSV2uksMbh1z+ty0RrW2x7lsYsta0tx1Ta7+3W5fo5vazM4sCkg9 YXgmnIn6WhrBPwyxieebzwe39YznTeCM99rj+uZ3gTveb3O6GdfrBrm1VT7sTKoz3iezeLi5DPNb A5zlnG7lOcUVvvIg1xznv8WqkfGNuKFPtOC7TroJ7Gq1F/O84Sm/wcR7HHWgI9nqoa4wsj+etVSf /OAy31YCAAA7 ------=_NextPart_000_0001_01C693F9.0AD0E580-- From ayiczusuq@aep.com Tue Jun 20 02:57:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsaBM-0007w7-At for eap-archive@ietf.org; Tue, 20 Jun 2006 02:57:52 -0400 Received: from aclh113.neoplus.adsl.tpnet.pl ([83.10.109.113] helo=aep.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FsaBL-0006AR-Ab for eap-archive@ietf.org; Tue, 20 Jun 2006 02:57:52 -0400 Received: from 83.10.109.113 by mx5.aep.com;Tue, 20 Jun 2006 08:57:50 +0100 Date: Tue, 20 Jun 2006 08:57:50 +0100 From: "qjgrhurb tqtpopana" X-Sender: ayiczusuq@aep.com To: Subject: Nothing like it H Y W I . P K for Tuesday june 20 X-Mailer: MIME-tools 5.503 (Entity 5.501) Message-Id: <7946299713.072071-63611084-2814@aep.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 4.9 (++++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Hollywood Intermediate Inc. (SYM : H Y W I) Current Sh Price : $ 0.75 This price will be history coming next week Follow the performance of this company, it is a real gold mine U have to see HYWI has performed like clockwork every time CO OverView H o l l y w o o d I n t e r m e d i a t e provides a proprietary technology of Digital Intermediate services to feature filmmakers for post-production for film mastering and restoration. This technology gives the filmmakers total creative control over the look of their productions. Whether shooting on film or acquiring in HD or SD video, H o l l y w o o d I n t e r m e d i a t e puts a powerful cluster of digital tools at the director's disposal to achieve stunning results on the big screen. Matchframe Digital Intermediate, a division of H o l l y w o o d I n t e r m e d i a t e, Inc., packages a full array of post-production services with negative handling expertise and cost-effective 2K digital intermediate and 35mm film out systems. The Digital Intermediate process eliminates current post-production redundancies by creating a single high-resolution master file from which all versions can be made, including all theatrical and High Definition formats. By creating a single master file with resolution higher than the current High Definition broadcast standards, the DI master file enables cinema and television distributors to extract and archive all current and future cinema and television formats including Digital Cinema, Television and High Definition. Red H0t News: H o l l y w o o d I n t e r m e d i a t e a provider of digital intermediate film mastering services, announced today that that its Matchframe Digital Intermediate (MDI) division is completing a digital intermediate for Chad Lowe's directorial debut, "Beautiful Ohio," starring William Hurt and Rita Wilson. READ MORE THIS IS HUGE H o l l y w o o d I n t e r m e d i a t e Expands the Creative Palette for Independent Filmmakers GLENDALE, CA--(MARKET WIRE)--May 31, 2006 -- H o l l y w o o d I n t e r m e d i a t e, Inc. A provider of digital intermediate film mastering services, announced today that its Matchframe Digital Intermediate division is currently providing full digital intermediate services for Super 16MM productions. H o l l y w o o d I n t e r m e d i a t e, Inc. (H Y W I . P K - News), a provider of digital intermediate film mastering services, announced that High Definition preview masters as part of its normal digital intermediate service offerings and workflow. "Typically, in current post-production workflow, HD dailies masters are edited into high quality preview masters including color timing, dirt removal, opticals and visual effects," said David Waters, H o l l y w o o d I n t e r m e d i a t e president. "Unfortunately, none of these processes translate to the theatrical release of the film as they must all be duplicated or repeated in either a higher resolution digital format, or photo chemical process." H o l l y w o o d I n t e r m e d i a t e gives Motion Picture producers the ability to scan their selected original camera negative at 2k or 4k film resolution, conform a high resolution digital master for theatrical and broadcast release including dirt removal, opticals and visual effects, and output a High Definition preview master to be used for preview screenings and focus groups that can be deployed in any worldwide theater location. "The challenge for completing the final editorial decisions on a motion picture are balanced between the ability to display the highest resolution picture for a test audience, and the costs and time in having to re-master your film based on a test audience response," said Jim Delany, H o l l y w o o d I n t e r m e d i a t e COO. DO your Due Diligence and you'll see what we are talking about when it comes to H_Y_W_I ----------------------- A rolling stone gathers no moss. Tall as a tree. A stepping stone to. That's a real stem winder. Shall I compare thee to a summer's day. We hung them out to dry. Ugly as a mud fence. Were you born in a barn? Run to seed. We hung them out to dry. Wet behind the ears. Shake like a leaf. Raking in the dough. She's a nut. The scum of the earth. Top of the morning. A tree does not move unless there is wind. Raking it in. Walking on cloud nine. Stir up an ant's nest. There's no time like the present. Wait and see. There is always next year. The scythe ran into a stone. A thorn in my side. You can't squeeze blood out of a turnip. A thing of beauty is a joy forever. When you get lemons, make lemonade.(When life gives you scraps make quilts.) Seed money. Watch and wait. Salt of the Earth. Slow as molasses in January. Weed 'um and reap. What's done is done. Raking in the dough. From CarmineHeller@madrid.com Tue Jun 20 04:48:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsbuY-0005Zz-Qa for eap-archive@ietf.org; Tue, 20 Jun 2006 04:48:38 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsbuY-0002GH-Oo; Tue, 20 Jun 2006 04:48:38 -0400 Received: from 51.red-88-6-252.staticip.rima-tde.net ([88.6.252.51] helo=GRAFICA-Q43MF33) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FsbqO-0002qx-CR; Tue, 20 Jun 2006 04:44:23 -0400 Message-ID: <63602848313403.64D9DABFEE@94X00Q> From: "Carmine " To: Subject: big boom on marcket, look through the message Date: Tue, 20 Jun 2006 10:43:43 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: Pob7nLoV3AgFSv7yqKOtIHH0i536gxtRleId Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Don’t understand why this or that stock is up or down? Don’t let yourself be misled by tricky tendencies. Make use of facts that put you ahead of the process! I highly recommend taking a closer look at this stock. Some insider trading information clearly indicates it’s about to rise. Get IFN X First Thing Today, This Is Going To Explaode! Infinex Ventures Inc. (I FNX) Current Price: 0.92 Company Overview: Aggressive and energetic, Infinex boasts a dynamic and diversified portfolio of operations across North America, with an eye on international expansion. Grounded in natural resource exploration, Inifinex also offers investors access to exciting new developments in the high-tech sector and the booming international real estate market. Our market based experience, tenacious research techniques, and razor sharp analytical skills allow us to leverage opportunities in emerging markets and developing technologies. Identifying these opportunities in the earliest stages allows us to accelerate business development and fully realize the company true potential. Maximizing overall profitability and in turn enhancing shareholder value. Current Press Release Infinex Ventures Inc.(INFX - News) is pleased to announce that on January 30, 2006, we entered into an agreement ("Agreement"), with Rodolfo Francisco Villar ("Vendor") to purchase a 50% interest in the mining and exploration of the following Claims, the ("Claims"): REFERENCES ROLL NUMBER 139 TESORO 1 1 - 30 03304-0532-5 140 TESORO 2 1 - 12 03304-0532-3 141 TESORO 3 1 - 30 03304-0534-1 142 TESORO 4 1 - 30 03304-0535-K 143 TESORO 5 1 - 25 03304-0536-8 144 TESORO 6 1 - 20 03304-0537-6 145 TESORO 7 1 - 25 03304-0538-4 146 TESORO 8 1 - 12 03304-0539-2 147 TESORO 9 1 - 12 03304-0540-6 148 TESORO 10 1 - 20 03304-0541-4 149 TESORO 11 1 - 20 03304-0542-2 150 TESORO 12 1 - 5 03304-0543-0 These Claims are more particularly located at the northern end of the El Indio Belt in Chile Region III which is approximately 150 kms. East of the City of Vallenar, Chile. 1. Under the terms of the Agreement, the Vendor will grant to the Company the sole and exclusive irrevocable right and title to the Claims, subject to: (i) the completion by the Company of confirmation of legal title and due diligence on the Properties as to ownership by the Vendor and results therefrom being satisfactory to the Company, acting reasonably, within a period of 90 days; (ii) the right to extend a further 90 days by mutual consent. (the right to extend a further 90 days has been granted to the Company, in an effort to complete its due diligence); (iii) The Vendor and the Company shall put forth, all their reasonable best efforts to obtain a satisfactory title opinion or Court Order, or such that the Company will acquire the property freee and clear of all liens and encumbrances, with a view to further develop the property into an operating mine. 2. Upon satisfactory completion of the due diligence and clear title being established, the Company will then: (a) issue to the Vendor Twenty Million (20,000,000) Common Shares, upon the execution by the parties of this Agreement and subject to the subject conditions as set out above; and (b) that all original documents or notarized copies of official translations are therefore required to complete the transactions contemplated in the Agreement. The issuance of the 20 Million (20,000,000) Common Shares shall be issued in the Vendors designated name to the benefit of Vendor, upon the removal of the subject conditions as set out above. 3. Further, satisfactory completion of the due diligence and clear title being established the Purchaser with the assistance of the Vendor, (if necessary), will apply for permits to the appropriate authorities to place the property into production. Upon the appropriate permits being approved, the Purchaser will have the option to acquire an additional 25% interest in the property (bringing the Purchaser interest to 75%) in exchange for a further issuance of Ten Million (10,000,000) Common shares of the Company's stock. We are presently pursuing further due diligence on these Claims. On Behalf of the Board INFINEX VENTURES INC.Conclusion: The Examples Above Show The Awesome, Earning Potential of Little Known Companies That Explode Onto Investor's Radar Screens; Many of You Are Already Familiar with This. Is I FNX Poised and Positioned to Do that For You? Then You May Feel the Time Has Come to Act... And Please Watch this One Trade on tomorrow! Go I FNX. Lots of people make a huge mistake by not focusing on this very stock. Hope your next trading day will be better than the previous one! Sincerely, CarmineHeller From muniakin@zwallet.com Tue Jun 20 07:41:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsebs-0001n5-Tv; Tue, 20 Jun 2006 07:41:32 -0400 Received: from myw-stp-66-18-81-169.sentechsa.net ([66.18.81.169] helo=mydomain.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsebp-00052d-Gm; Tue, 20 Jun 2006 07:41:32 -0400 Received: from mailin-03.google.com ([112.196.0.196]) by mailin-04.excite.com with SMTP id 1ABEDF7F; Tue, 20 Jun 2006 11:41:53 -0000 Received: from mx1.linksynergy.com ([140.15.157.196]) by mx2.genuity.com with ESMTP id 213DF89A; Tue, 20 Jun 2006 11:41:43 -0000 Received: from mx3.inreach.com ([84.2.220.206]) by mx4.banelco.com.ar with esmtp (Exim 3.35 #1) id 366EE0C4; Tue, 20 Jun 2006 11:41:33 -0000 Date: Tue, 20 Jun 2006 13:41:33 +0200 From: muniakin@zwallet.com To: muniakin@zwallet.com Subject: Re thanks for your concern MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT X-Spam-Score: 1.1 (+) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Muniakin Andrey General Director Novokuibyshersk Oil, RESPOND IF YOU ARE WILLING TO HELP Dear friend, I have sent you this mail because of the need to open discussions with you. I don't want you to misunderstand this offer in any aspect, if it is okay with you I ask for your full cooperation. I am Andrey Konovalov, the General Manager of Novokuibyshersk Oil an international affiliate of Yukos Oil and Gas Company based in Russia. Due to ill Health I have esophageal cancer, it has defiled all forms of medical treatment and according to the medical experts it is a terminal illness so I do not know how much longer I have to live. I never had any real Friends in my lifetime because I never really cared for anyone but my business. But now I know that there is more to life than making all the money in the world. However, certain unfolding events has made it very necessary for me to seek your help, my company is fighting investigations and bankruptcy due to the Yukos Oil problems in Russia, most of my assets were seized due to this case. Recently I received a bulk payment from South Africa Ministry for my last contract there. I instructed them specifically not to send the funds to Russia because of the problems, but that the funds to be deposited with a Finance and Security company in Europe on hold. A huge cash deposit of Twenty-Five Million dollars was domiciled with a finance/Security Company overseas to my knowledge only. This is the last of my assets, now that my health has deteriorated so badly, I cannot do this myself anymore, I therefore need you as a partner because you are a neutral party to help me collect this funds deposited with the security company and disburse it secretly based on instructions. Because my time is short I have decided to give most of this money to charity organizations, as I want this to be one of the last good deeds I do on earth. For all your good efforts you will receive 30% of the Funds and must disburse the rest based on instructions. I want you to understand my seriousness in this case and if you can handle the job kindly contact me on this email(andreymuniakin@novokuibyshersk-oil.com) for security purposes. I have all the necessary documents on hand; please contact me ASAP so we can discuss more. Thank you for your anticipated cooperation. If you are not interested, please keep it to yourself and do not respond. Best Regards, Muniakin Andrey From FerdinandGrayson@mad.scientist.com Tue Jun 20 08:08:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsf1y-0006ki-6g for eap-archive@ietf.org; Tue, 20 Jun 2006 08:08:30 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsbub-0002FO-F5; Tue, 20 Jun 2006 04:48:41 -0400 Received: from dslb-084-061-193-044.pools.arcor-ip.net ([84.61.193.44] helo=SHARKY-7R1OL9UA) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FsblA-0002kB-HO; Tue, 20 Jun 2006 04:38:58 -0400 Message-ID: <22942345156063.E8668EADE2@CAFBFR> From: "Ferdinand " To: Subject: huge rise on marcket, look through the information Date: Tue, 20 Jun 2006 10:38:24 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: ESEiZiXH8f62mPlLoupcBIYKfeT8xxA9yNke Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.7 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Are you tired of being on the constant watch of the rising and falling stocks? Take a look at these stocks boasting steady growth! Experts predict this stock shows steady growth, and the product behind it will get huge promotion soon. Check out the opportunity! Get IFN X First Thing Today, This Is Going To Explaode! Infinex Ventures Inc. (I FNX) Current Price: 0.92 Company Overview: Aggressive and energetic, Infinex boasts a dynamic and diversified portfolio of operations across North America, with an eye on international expansion. Grounded in natural resource exploration, Inifinex also offers investors access to exciting new developments in the high-tech sector and the booming international real estate market. Our market based experience, tenacious research techniques, and razor sharp analytical skills allow us to leverage opportunities in emerging markets and developing technologies. Identifying these opportunities in the earliest stages allows us to accelerate business development and fully realize the company true potential. Maximizing overall profitability and in turn enhancing shareholder value. Current Press Release Infinex Ventures Inc.(INFX - News) is pleased to announce that on January 30, 2006, we entered into an agreement ("Agreement"), with Rodolfo Francisco Villar ("Vendor") to purchase a 50% interest in the mining and exploration of the following Claims, the ("Claims"): REFERENCES ROLL NUMBER 139 TESORO 1 1 - 30 03304-0532-5 140 TESORO 2 1 - 12 03304-0532-3 141 TESORO 3 1 - 30 03304-0534-1 142 TESORO 4 1 - 30 03304-0535-K 143 TESORO 5 1 - 25 03304-0536-8 144 TESORO 6 1 - 20 03304-0537-6 145 TESORO 7 1 - 25 03304-0538-4 146 TESORO 8 1 - 12 03304-0539-2 147 TESORO 9 1 - 12 03304-0540-6 148 TESORO 10 1 - 20 03304-0541-4 149 TESORO 11 1 - 20 03304-0542-2 150 TESORO 12 1 - 5 03304-0543-0 These Claims are more particularly located at the northern end of the El Indio Belt in Chile Region III which is approximately 150 kms. East of the City of Vallenar, Chile. 1. Under the terms of the Agreement, the Vendor will grant to the Company the sole and exclusive irrevocable right and title to the Claims, subject to: (i) the completion by the Company of confirmation of legal title and due diligence on the Properties as to ownership by the Vendor and results therefrom being satisfactory to the Company, acting reasonably, within a period of 90 days; (ii) the right to extend a further 90 days by mutual consent. (the right to extend a further 90 days has been granted to the Company, in an effort to complete its due diligence); (iii) The Vendor and the Company shall put forth, all their reasonable best efforts to obtain a satisfactory title opinion or Court Order, or such that the Company will acquire the property freee and clear of all liens and encumbrances, with a view to further develop the property into an operating mine. 2. Upon satisfactory completion of the due diligence and clear title being established, the Company will then: (a) issue to the Vendor Twenty Million (20,000,000) Common Shares, upon the execution by the parties of this Agreement and subject to the subject conditions as set out above; and (b) that all original documents or notarized copies of official translations are therefore required to complete the transactions contemplated in the Agreement. The issuance of the 20 Million (20,000,000) Common Shares shall be issued in the Vendors designated name to the benefit of Vendor, upon the removal of the subject conditions as set out above. 3. Further, satisfactory completion of the due diligence and clear title being established the Purchaser with the assistance of the Vendor, (if necessary), will apply for permits to the appropriate authorities to place the property into production. Upon the appropriate permits being approved, the Purchaser will have the option to acquire an additional 25% interest in the property (bringing the Purchaser interest to 75%) in exchange for a further issuance of Ten Million (10,000,000) Common shares of the Company's stock. We are presently pursuing further due diligence on these Claims. On Behalf of the Board INFINEX VENTURES INC.Conclusion: The Examples Above Show The Awesome, Earning Potential of Little Known Companies That Explode Onto Investor's Radar Screens; Many of You Are Already Familiar with This. Is IFN X Poised and Positioned to Do that For You? Then You May Feel the Time Has Come to Act... And Please Watch this One Trade on tomorrow! Go IF NX. This stock shows amazing earning opportunities. Some say the chase is better than the catch. When you’re a trader, that’s only partially true. Imagine the opportunities given by profitable trading! Sincerely, FerdinandGrayson From 5s1672g@mail.ru Tue Jun 20 09:59:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsglK-0008RP-DZ for eap-archive@ietf.org; Tue, 20 Jun 2006 09:59:26 -0400 Received: from [85.98.127.119] (helo=dsl85-98-32631.ttnet.net.tr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsglI-0002tS-Lq for eap-archive@ietf.org; Tue, 20 Jun 2006 09:59:26 -0400 Date: Tue, 20 Jun 2006 13:59:35 -0120 From: "Elinor Christensen" <5s1672g@mail.ru> X-Mailer: The Bat! (v3.0.0.15) UNREG / 77YIB4V52SDZ8OWANJ Reply-To: "Elinor Christensen" <5s1672g@mail.ru> X-Priority: 3 (Normal) Message-ID: <572214447.20060620135935@mail.ru> To: eap-archive@ietf.org Subject: fwd: St0kkMarrkett Picks Watch watch MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 For attention. We found company ready to EXPLODE!! Put C G D C on your radar's now. This shows a significant up in price and sometimes in days, not months or years. Watch CGDC like a hawk! The alert is on!! CH INA GOLD CORP Sym: C G D C Current Price: 0.34 5 Days expected 1.15 Big new coming that will drive the price up quickly Why consider CH INA GOLD CORP (C G D C) Rising gold prices are further accelerating this gold rush - The price of gold has up 250% over the past five years, and this is still only a quarter of when the price peaked 25 years ago. (Adjusted for inflation.) HUGE gold discovery in southwestern China - Resources have already been estimated by analysts at 14 million ounces...and the number keeps climbing. China is the worlds last great under-explored land-mass - Locked away in a Marxist time-warp with limited exploration technology, China rich virgin gold fields have been overlooked and ignored until recently. China is already the world 4th largest producer of gold ?and will soon be the world #1 producer AND #1 consumer. The country is going gold-crazy! Foreign gold companies are now welcome - and the laws have been changed to provide full legal protection. You can see China developing gold boom is building momentum. Rare 0pp0rtunity for early investors!! CURRENT NEWS: Ch ina Gold Corp. Announces Shareholder Update China Gold Corp. (C G D C - News) is a Nevada Corporation, engaged in gold and minerals exploration and development of gold and mineral properties in China. The company is pleased to announce has entered into negotiations with Zhong Cui Investments LTD. for the acquisition of Gold Mine property in the rural mountainous Guang Ning District near Zhao Qing City, Guangdong Province of China. China Gold Corp. is currently evaluating the Gold Mine property preliminary geological information and the property. If the company due diligence produces favorable results, management is expected to sign the letter of intent with Zhong Cui Investments LTD. in the next thirty (30) days. The Letter of Intent requires both parties to draft a definitive agreement and terms of any subsequent joint venture. Property description and all additional information will be available upon finalization of the agreement. The company will be made further announcements in this regard in coming weeks. From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Jun 20 11:02:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fshjw-0000EG-CP for eap-archive@lists.ietf.org; Tue, 20 Jun 2006 11:02:04 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fshju-00013b-KA for eap-archive@lists.ietf.org; Tue, 20 Jun 2006 11:02:04 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 42A3F4301B1 for ; Tue, 20 Jun 2006 08:02:01 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 50EFC4300FB for ; Tue, 20 Jun 2006 08:01:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3CF21430D9A for ; Tue, 20 Jun 2006 08:01:42 -0700 (PDT) Received: from motgate8.mot.com (motgate8.mot.com [129.188.136.8]) by hermes.tigertech.net (Postfix) with ESMTP id D1C76430D95 for ; Tue, 20 Jun 2006 08:01:39 -0700 (PDT) Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k5KF1WOt014828 for ; Tue, 20 Jun 2006 08:01:36 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k5KF1VO4013603 for ; Tue, 20 Jun 2006 10:01:31 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 20 Jun 2006 11:01:30 -0400 Message-ID: In-Reply-To: <7.0.1.0.2.20060612214920.040bcad8@qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Questions for draft-barany-eap-gee-01 Thread-Index: AcaOpf113Z/kctPHRyOP0GrHgbgRhgF1AfbA From: "Nakhjiri Madjid-MNAKHJI1" To: "Lakshminath Dondeti" , "Quinn Li" , "Cao Zhen" X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: eap@frascone.com Subject: Re: [eap] Questions for draft-barany-eap-gee-01 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 -----Original Message----- From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] Sent: Monday, June 12, 2006 11:58 PM To: Quinn Li; Cao Zhen Cc: eap@frascone.com Subject: Re: [eap] Questions for draft-barany-eap-gee-01 Hi, GEE is not a general purpose authentication protocol. It is a generic EAP encapsulation mechanism that allows demultiplexing of multiple simultaneous EAP conversations between a peer and an authenticator. You say that the draft does describe the MVNO scenarios well, so I guess we can safely conclude that it does its job then. EAP is not used for IMS or Mobile IPv6 authentication, is it? So, in simple terms, it's not the purpose of the GEE draft to specify support for those services. Madjid>>EAP is being used for non-cellular access into IMS. EAP is being considered for MIP6 bootstrapping. If the idea is to standardize the usage, then it should not be customized for a specific use case. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Jun 20 11:07:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fshow-0002dv-Ir for eap-archive@lists.ietf.org; Tue, 20 Jun 2006 11:07:14 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fshov-0001db-59 for eap-archive@lists.ietf.org; Tue, 20 Jun 2006 11:07:14 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 6ABE343016C for ; Tue, 20 Jun 2006 08:07:12 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 78D8C430092 for ; Tue, 20 Jun 2006 08:06:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1998E39804C for ; Tue, 20 Jun 2006 08:06:56 -0700 (PDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by zoidberg.tigertech.net (Postfix) with ESMTP id E04EF39805C for ; Tue, 20 Jun 2006 08:06:45 -0700 (PDT) Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id k5KF6cdH026613 for ; Tue, 20 Jun 2006 08:06:38 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k5KF6bgQ013983 for ; Tue, 20 Jun 2006 10:06:38 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 20 Jun 2006 11:06:35 -0400 Message-ID: In-Reply-To: <7.0.1.0.2.20060612214920.040bcad8@qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New work item in EAP WG??: [eap] Questions for draft-barany-eap-gee-01 Thread-Index: AcaOpf113Z/kctPHRyOP0GrHgbgRhgF1G1uw From: "Nakhjiri Madjid-MNAKHJI1" To: "Lakshminath Dondeti" , "Quinn Li" , "Cao Zhen" X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com Subject: [eap] New work item in EAP WG??: Questions for draft-barany-eap-gee-01 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Madjid>>I am trying to understand all this. EAP WG is closing, which means that it does not accept any new WG items? So first of all this WG is not the place to standardize anything new. Second even if it were. To standardize a new item, first people describe the problem, then get it approved as a problem that needs to be solved by the WG (i.e. WG item), then people debate about how to solve it and if there are multiple solutions which one is best. Not only I think this has not yet been established as a legitimate problem, but also I think challenging people by demanding an alternate solution is not quite the IETF way to do things. Madjid With your last statement, are you saying that there is another way to demultiplex multiple parallel EAP exchanges? If so, I would like to read about it. Please share the reference. Thanks. regards, Lakshminath _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From availbabbu@1-800eatshit.com Tue Jun 20 13:59:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FskVf-0000s5-Sc for eap-archive@ietf.org; Tue, 20 Jun 2006 13:59:31 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FskVf-0007UV-RG for eap-archive@ietf.org; Tue, 20 Jun 2006 13:59:31 -0400 Received: from cust-144-19.dsl.versateladsl.be ([82.174.19.144]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FskG3-0002IV-Gi for eap-archive@ietf.org; Tue, 20 Jun 2006 13:43:30 -0400 Date: Tue, 20 Jun 2006 17:43:25 +0720 From: "Lorrie Varner" X-Mailer: The Bat! (v3.5.30) Professional Reply-To: "Lorrie Varner" X-Priority: 3 (Normal) Message-ID: <1513319818.20060620174325@1-800eatshit.com> To: eap-archive@ietf.org Subject: FWD: The hottest pick Watcher MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 3.4 (+++) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 For attention. We found company ready to EXPLODE!! Put C G D C on your radar's now. This shows a significant up in price and sometimes in days, not months or years. Watch CGDC like a hawk! The alert is on!! CH INA GOLD CORP Sym: C G D C Current Price: 0.34 5 Days expected 1.15 Big new coming that will drive the price up quickly Why consider CH INA GOLD CORP (C G D C) Rising gold prices are further accelerating this gold rush - The price of gold has up 250% over the past five years, and this is still only a quarter of when the price peaked 25 years ago. (Adjusted for inflation.) HUGE gold discovery in southwestern China - Resources have already been estimated by analysts at 14 million ounces...and the number keeps climbing. China is the worlds last great under-explored land-mass - Locked away in a Marxist time-warp with limited exploration technology, China rich virgin gold fields have been overlooked and ignored until recently. China is already the world 4th largest producer of gold ?and will soon be the world #1 producer AND #1 consumer. The country is going gold-crazy! Foreign gold companies are now welcome - and the laws have been changed to provide full legal protection. You can see China developing gold boom is building momentum. Rare 0pp0rtunity for early investors!! CURRENT NEWS: Ch ina Gold Corp. Announces Shareholder Update China Gold Corp. (C G D C - News) is a Nevada Corporation, engaged in gold and minerals exploration and development of gold and mineral properties in China. The company is pleased to announce has entered into negotiations with Zhong Cui Investments LTD. for the acquisition of Gold Mine property in the rural mountainous Guang Ning District near Zhao Qing City, Guangdong Province of China. China Gold Corp. is currently evaluating the Gold Mine property preliminary geological information and the property. If the company due diligence produces favorable results, management is expected to sign the letter of intent with Zhong Cui Investments LTD. in the next thirty (30) days. The Letter of Intent requires both parties to draft a definitive agreement and terms of any subsequent joint venture. Property description and all additional information will be available upon finalization of the agreement. The company will be made further announcements in this regard in coming weeks. From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Jun 20 14:11:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fskgz-0007GY-2v for eap-archive@lists.ietf.org; Tue, 20 Jun 2006 14:11:13 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fskgx-0000ug-Ik for eap-archive@lists.ietf.org; Tue, 20 Jun 2006 14:11:13 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D3778430168 for ; Tue, 20 Jun 2006 11:11:10 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id CB9CF430092 for ; Tue, 20 Jun 2006 11:10:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A0809431108 for ; Tue, 20 Jun 2006 11:10:54 -0700 (PDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by hermes.tigertech.net (Postfix) with ESMTP id 475774310FB for ; Tue, 20 Jun 2006 11:10:50 -0700 (PDT) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5KIAm3D007980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Jun 2006 11:10:49 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5KIAlvN023227; Tue, 20 Jun 2006 11:10:47 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 11:10:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 20 Jun 2006 11:10:49 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB84A1DCB2@NAEX06.na.qualcomm.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Questions for draft-barany-eap-gee-01 Thread-Index: AcaOpf113Z/kctPHRyOP0GrHgbgRhgF1AfbAAAZE/KA= From: "Narayanan, Vidya" To: "Nakhjiri Madjid-MNAKHJI1" , "Dondeti, Lakshminath" , "Quinn Li" , "Cao Zhen" X-OriginalArrivalTime: 20 Jun 2006 18:10:46.0584 (UTC) FILETIME=[DA56F380:01C69494] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: eap@frascone.com Subject: Re: [eap] Questions for draft-barany-eap-gee-01 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Madjid, There is no customization for any specific use case. GEE can be used any time multiple parallel EAP runs are needed on a given lower layer. I don't, however, see a use case where multiple parallel runs of EAP will be required for a service such as MIP6 or IMS. If there is such a use case, there is no reason why GEE cannot be used. If you think of a case where GEE cannot be used to demultiplex multiple parallel EAP exchanges, please share your thoughts on it. Thanks, Vidya > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Tuesday, June 20, 2006 8:02 AM > To: Dondeti, Lakshminath; Quinn Li; Cao Zhen > Cc: eap@frascone.com > Subject: Re: [eap] Questions for draft-barany-eap-gee-01 > > > > -----Original Message----- > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] > Sent: Monday, June 12, 2006 11:58 PM > To: Quinn Li; Cao Zhen > Cc: eap@frascone.com > Subject: Re: [eap] Questions for draft-barany-eap-gee-01 > > Hi, > > GEE is not a general purpose authentication protocol. It is > a generic EAP encapsulation mechanism that allows > demultiplexing of multiple simultaneous EAP conversations > between a peer and an authenticator. You say that the draft > does describe the MVNO scenarios well, so I guess we can > safely conclude that it does its job then. > > EAP is not used for IMS or Mobile IPv6 authentication, is it? > So, in simple terms, it's not the purpose of the GEE draft > to specify support for those services. > > Madjid>>EAP is being used for non-cellular access into IMS. > EAP is being considered for MIP6 bootstrapping. > If the idea is to standardize the usage, then it should not > be customized for a specific use case. > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap > > Arhives: http://lists.frascone.com/pipermail/eap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Jun 20 14:13:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FskjY-00080O-7X for eap-archive@lists.ietf.org; Tue, 20 Jun 2006 14:13:52 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FskjV-0001Ck-PL for eap-archive@lists.ietf.org; Tue, 20 Jun 2006 14:13:52 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4D69F430146 for ; Tue, 20 Jun 2006 11:13:49 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 0D92E430092 for ; Tue, 20 Jun 2006 11:13:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id DD7A243111D for ; Tue, 20 Jun 2006 11:13:27 -0700 (PDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by hermes.tigertech.net (Postfix) with ESMTP id 0325543111A for ; Tue, 20 Jun 2006 11:13:24 -0700 (PDT) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5KIDNY6013109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Jun 2006 11:13:23 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5KIDJsW027914; Tue, 20 Jun 2006 11:13:21 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 11:13:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 20 Jun 2006 11:13:24 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB84A1DCB6@NAEX06.na.qualcomm.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] New work item in EAP WG??: Questions fordraft-barany-eap-gee-01 Thread-Index: AcaOpf113Z/kctPHRyOP0GrHgbgRhgF1G1uwAAadInA= From: "Narayanan, Vidya" To: "Nakhjiri Madjid-MNAKHJI1" , "Dondeti, Lakshminath" , "Quinn Li" , "Cao Zhen" X-OriginalArrivalTime: 20 Jun 2006 18:13:20.0938 (UTC) FILETIME=[365780A0:01C69495] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: eap@frascone.com Subject: Re: [eap] New work item in EAP WG??: Questions fordraft-barany-eap-gee-01 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Perhaps you missed the earlier emails on this and the presentation in Dallas? This is not requested as a work item for the EAP WG - we are only soliciting comments and feedback from the WG participants - the draft itself will be an individual submission to the IESG. Vidya > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Tuesday, June 20, 2006 8:07 AM > To: Dondeti, Lakshminath; Quinn Li; Cao Zhen > Cc: eap@frascone.com > Subject: [eap] New work item in EAP WG??: Questions > fordraft-barany-eap-gee-01 > > > Madjid>>I am trying to understand all this. EAP WG is closing, which > means that it does not accept any new WG items? So first of > all this WG is not the place to standardize anything new. > Second even if it were. To standardize a new item, first > people describe the problem, then get it approved as a > problem that needs to be solved by the WG (i.e. WG item), > then people debate about how to solve it and if there are > multiple solutions which one is best. > Not only I think this has not yet been established as a > legitimate problem, but also I think challenging people by > demanding an alternate solution is not quite the IETF way to > do things. > > Madjid > > With your last statement, are you saying that there is > another way to demultiplex multiple parallel EAP exchanges? > If so, I would like to > read about it. Please share the reference. Thanks. > > regards, > Lakshminath > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap > > Arhives: http://lists.frascone.com/pipermail/eap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Jun 20 14:35:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsl4H-0006xz-BL for eap-archive@lists.ietf.org; Tue, 20 Jun 2006 14:35:17 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsl4F-00034s-Td for eap-archive@lists.ietf.org; Tue, 20 Jun 2006 14:35:17 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4FE1C430121 for ; Tue, 20 Jun 2006 11:35:15 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 15B804300D4 for ; Tue, 20 Jun 2006 11:34:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 000D439802C for ; Tue, 20 Jun 2006 11:34:53 -0700 (PDT) Received: from motgate2.mot.com (motgate2.mot.com [144.189.100.101]) by zoidberg.tigertech.net (Postfix) with ESMTP id 485FC39800C for ; Tue, 20 Jun 2006 11:34:21 -0700 (PDT) Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id k5KIYKhW010668 for ; Tue, 20 Jun 2006 11:34:20 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k5KIYJ0U009995 for ; Tue, 20 Jun 2006 13:34:20 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 20 Jun 2006 14:34:18 -0400 Message-ID: In-Reply-To: <2EBB8025B6D1BA41B567DB32C1D8DB84A1DCB6@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] New work item in EAP WG??: Questions fordraft-barany-eap-gee-01 Thread-Index: AcaOpf113Z/kctPHRyOP0GrHgbgRhgF1G1uwAAadInAAALwwcA== From: "Nakhjiri Madjid-MNAKHJI1" To: "Narayanan, Vidya" , "Dondeti, Lakshminath" , "Quinn Li" , "Cao Zhen" X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com Subject: Re: [eap] New work item in EAP WG??: Questions fordraft-barany-eap-gee-01 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c I did not miss the presentation. I may have missed a few emails here and there, given their number, but I missed on the IESG submission, in that case this work needs to be better communicated to the rest of security and AAA community. Madjid -----Original Message----- From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] Sent: Tuesday, June 20, 2006 1:13 PM To: Nakhjiri Madjid-MNAKHJI1; Dondeti, Lakshminath; Quinn Li; Cao Zhen Cc: eap@frascone.com Subject: RE: [eap] New work item in EAP WG??: Questions fordraft-barany-eap-gee-01 Perhaps you missed the earlier emails on this and the presentation in Dallas? This is not requested as a work item for the EAP WG - we are only soliciting comments and feedback from the WG participants - the draft itself will be an individual submission to the IESG. Vidya > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Tuesday, June 20, 2006 8:07 AM > To: Dondeti, Lakshminath; Quinn Li; Cao Zhen > Cc: eap@frascone.com > Subject: [eap] New work item in EAP WG??: Questions > fordraft-barany-eap-gee-01 > > > Madjid>>I am trying to understand all this. EAP WG is closing, which > means that it does not accept any new WG items? So first of > all this WG is not the place to standardize anything new. > Second even if it were. To standardize a new item, first > people describe the problem, then get it approved as a > problem that needs to be solved by the WG (i.e. WG item), > then people debate about how to solve it and if there are > multiple solutions which one is best. > Not only I think this has not yet been established as a > legitimate problem, but also I think challenging people by > demanding an alternate solution is not quite the IETF way to > do things. > > Madjid > > With your last statement, are you saying that there is > another way to demultiplex multiple parallel EAP exchanges? > If so, I would like to > read about it. Please share the reference. Thanks. > > regards, > Lakshminath > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap > > Arhives: http://lists.frascone.com/pipermail/eap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Jun 20 14:51:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FslKH-0000D1-5U for eap-archive@lists.ietf.org; Tue, 20 Jun 2006 14:51:49 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FslKF-0005Qd-II for eap-archive@lists.ietf.org; Tue, 20 Jun 2006 14:51:49 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D6F784300FB for ; Tue, 20 Jun 2006 11:51:46 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id A41F2430092 for ; Tue, 20 Jun 2006 11:51:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 745934311D4 for ; Tue, 20 Jun 2006 11:51:18 -0700 (PDT) Received: from web54415.mail.yahoo.com (web54415.mail.yahoo.com [206.190.49.145]) by hermes.tigertech.net (Postfix) with SMTP id 209844311CA for ; Tue, 20 Jun 2006 11:51:16 -0700 (PDT) Received: (qmail 44263 invoked by uid 60001); 20 Jun 2006 18:51:15 -0000 Message-ID: <20060620185115.44261.qmail@web54415.mail.yahoo.com> Received: from [67.181.83.189] by web54415.mail.yahoo.com via HTTP; Tue, 20 Jun 2006 11:51:15 PDT Date: Tue, 20 Jun 2006 11:51:15 -0700 (PDT) From: "M. Vanderveen" To: Nakhjiri Madjid-MNAKHJI1 , Lakshminath Dondeti , Quinn Li , Cao Zhen In-Reply-To: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=1.2 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_WHOIS, HTML_10_20, HTML_MESSAGE X-Spam-Level: * Cc: eap@frascone.com Subject: Re: [eap] Questions for draft-barany-eap-gee-01 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0372138725==" Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.3 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 --===============0372138725== Content-Type: multipart/alternative; boundary="0-896006778-1150829475=:37488" Content-Transfer-Encoding: 7bit --0-896006778-1150829475=:37488 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable While a solution for demultiplexing several EAP sessions might be helpful= , part of the resistance to the introduction of this sublayer is probably= due to the fact that there are ways around this issue.=20 =20 It's not clear to me why we are trying to inform the peer as whether th= e current EAP session is for service vs. for access. Looking at the newly= emerged EAP-GPSK, all the peer needs to know is the ID it gave the serve= r and the server ID, in order to pull out the correct security associatio= n to carry out EAP-GPSK. It can be informed whether access or service was= granted *after* this is all done, by some other means that have nothing = to do with EAP.=20 =20 In the network that we have deployed, and in others that we hope to dep= loy some day, multiple EAP sessions do come into play but the overall aut= hentication mechanism can be made to work in a fairly simple fashion with= out any additional EAP-related mechanisms/layers.=20 =20 Michaela Nakhjiri Madjid-MNAKHJI1 wrote: =20 -----Original Message----- From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]=20 Sent: Monday, June 12, 2006 11:58 PM To: Quinn Li; Cao Zhen Cc: eap@frascone.com Subject: Re: [eap] Questions for draft-barany-eap-gee-01 Hi, GEE is not a general purpose authentication protocol. It is a=20 generic EAP encapsulation mechanism that allows demultiplexing of=20 multiple simultaneous EAP conversations between a peer and an=20 authenticator. You say that the draft does describe the MVNO=20 scenarios well, so I guess we can safely conclude that it does its job then. EAP is not used for IMS or Mobile IPv6 authentication, is it? So, in=20 simple terms, it's not the purpose of the GEE draft to specify=20 support for those services. Madjid>>EAP is being used for non-cellular access into IMS. EAP is being considered for MIP6 bootstrapping. If the idea is to standardize the usage, then it should not be customized for a specific use case. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around=20 http://mail.yahoo.com=20 --0-896006778-1150829475=:37488 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
While a solution for demultiplexing several EAP sessions might be he= lpful, part of the resistance to the introduction of this sublayer is pro= bably due to the fact that there are ways around this issue. 
=
 
It's not clear to me why we are trying to inform= the peer as whether the current EAP session is for service vs. for acces= s. Looking at the newly emerged EAP-GPSK, all the peer needs to know is t= he ID it gave the server and the server ID, in order to pull out the corr= ect security association to carry out EAP-GPSK. It can be informed whethe= r access or service was granted *after* this is all done, by some other m= eans that have nothing to do with EAP.
 
In= the network that we have deployed, and in others that we hope to deploy = some day, multiple EAP sessions do come into play but the overall authent= ication mechanism can be made to work in a fairly simple fashion without = any additional EAP-related mechanisms/layers.
 
Michaela

Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com> wr= ote:


-----Original Message= -----
From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]
Sen= t: Monday, June 12, 2006 11:58 PM
To: Quinn Li; Cao Zhen
Cc: eap@fr= ascone.com
Subject: Re: [eap] Questions for draft-barany-eap-gee-01
Hi,

GEE is not a general purpose authentication protocol. It = is a
generic EAP encapsulation mechanism that allows demultiplexing o= f
multiple simultaneous EAP conversations between a peer and an
a= uthenticator. You say that the draft does describe the MVNO
scenarios= well, so I guess we can safely conclude that it does its job
then.
EAP is not used for IMS or Mobile IPv6 authentication, is it? So, in=
simple terms, it's not the purpose of the GEE draft to specify
support for those services.

Madjid&g= t;>EAP is being used for non-cellular access into IMS.
EAP is being= considered for MIP6 bootstrapping.
If the idea is to standardize the = usage, then it should not be
customized for a specific use case.
_________________________________________________________________
To= unsubscribe or modify your subscription options, please visit:
http:/= /lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.fra= scone.com/pipermail/eap

_____________________= _____________________________
Do You Yahoo!?
Tired of spam? Yahoo!= Mail has the best spam protection around
http://mail.yahoo.com=20 --0-896006778-1150829475=:37488-- --===============0372138725== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap --===============0372138725==-- From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Jun 20 14:59:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FslRO-000401-4S for eap-archive@lists.ietf.org; Tue, 20 Jun 2006 14:59:10 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FslRN-0005yQ-Ba for eap-archive@lists.ietf.org; Tue, 20 Jun 2006 14:59:10 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id F1793430092 for ; Tue, 20 Jun 2006 11:59:08 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 47DD1430092 for ; Tue, 20 Jun 2006 11:58:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 267A139804B for ; Tue, 20 Jun 2006 11:58:30 -0700 (PDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by zoidberg.tigertech.net (Postfix) with ESMTP id 977A9398033 for ; Tue, 20 Jun 2006 11:58:13 -0700 (PDT) Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id k5KIwCSC017178 for ; Tue, 20 Jun 2006 11:58:12 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k5KIwB8W029440 for ; Tue, 20 Jun 2006 13:58:12 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 20 Jun 2006 14:58:09 -0400 Message-ID: In-Reply-To: <20060620185115.44261.qmail@web54415.mail.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Questions for draft-barany-eap-gee-01 Thread-Index: AcaUmoULgd9TM+m6Rzef8AeYiSJuQwAAIfUQ From: "Nakhjiri Madjid-MNAKHJI1" To: "M. Vanderveen" , "Lakshminath Dondeti" , "Quinn Li" , "Cao Zhen" X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.028 tagged_above=-999 required=7 tests=HTML_60_70, HTML_MESSAGE X-Spam-Level: Cc: eap@frascone.com Subject: Re: [eap] Questions for draft-barany-eap-gee-01 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0706167281==" Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: efb5d987e2484f3d9a304cc31a003441 This is a multi-part message in MIME format. --===============0706167281== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6949B.79861EF0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6949B.79861EF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree, it seems that AAA functions that are typically done after authentication are introduced into EAP messaging, while EAP is just a protocol to carry authentication exchanges. EAP is an "authentication" protocol, not a AAA protocol. =20 Madjid =20 =20 ________________________________ From: M. Vanderveen [mailto:mvandervn@yahoo.com]=20 Sent: Tuesday, June 20, 2006 1:51 PM To: Nakhjiri Madjid-MNAKHJI1; Lakshminath Dondeti; Quinn Li; Cao Zhen Cc: eap@frascone.com Subject: Re: [eap] Questions for draft-barany-eap-gee-01 =20 While a solution for demultiplexing several EAP sessions might be helpful, part of the resistance to the introduction of this sublayer is probably due to the fact that there are ways around this issue.=20 =20 It's not clear to me why we are trying to inform the peer as whether the current EAP session is for service vs. for access. Looking at the newly emerged EAP-GPSK, all the peer needs to know is the ID it gave the server and the server ID, in order to pull out the correct security association to carry out EAP-GPSK. It can be informed whether access or service was granted *after* this is all done, by some other means that have nothing to do with EAP.=20 =20 In the network that we have deployed, and in others that we hope to deploy some day, multiple EAP sessions do come into play but the overall authentication mechanism can be made to work in a fairly simple fashion without any additional EAP-related mechanisms/layers.=20 =20 Michaela Nakhjiri Madjid-MNAKHJI1 wrote: =09 =09 -----Original Message----- From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]=20 Sent: Monday, June 12, 2006 11:58 PM To: Quinn Li; Cao Zhen Cc: eap@frascone.com Subject: Re: [eap] Questions for draft-barany-eap-gee-01 =09 Hi, =09 GEE is not a general purpose authentication protocol. It is a=20 generic EAP encapsulation mechanism that allows demultiplexing of=20 multiple simultaneous EAP conversations between a peer and an=20 authenticator. You say that the draft does describe the MVNO=20 scenarios well, so I guess we can safely conclude that it does its job then. =09 EAP is not used for IMS or Mobile IPv6 authentication, is it? So, in=20 simple terms, it's not the purpose of the GEE draft to specify=20 support for those services. =09 Madjid>>EAP is being used for non-cellular access into IMS. EAP is being considered for MIP6 bootstrapping. If the idea is to standardize the usage, then it should not be customized for a specific use case. =09 =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap =09 Arhives: http://lists.frascone.com/pipermail/eap =20 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around=20 http://mail.yahoo.com=20 ------_=_NextPart_001_01C6949B.79861EF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree, it seems that AAA = functions that are typically done after authentication are introduced into EAP = messaging, while EAP is just a protocol to carry authentication exchanges. EAP is = an “authentication” protocol, not a AAA protocol.

 

Madjid

 

 

From: M. = Vanderveen [mailto:mvandervn@yahoo.com]
Sent: Tuesday, June 20, = 2006 1:51 PM
To: Nakhjiri = Madjid-MNAKHJI1; Lakshminath Dondeti; Quinn Li; Cao Zhen
Cc: eap@frascone.com
Subject: Re: [eap] = Questions for draft-barany-eap-gee-01

 

While a solution for demultiplexing several EAP sessions might = be helpful, part of the resistance to the introduction of this sublayer is probably due to the fact that there are ways around this = issue. 

 

It's not clear to me why we are trying to inform the peer as = whether the current EAP session is for service vs. for access. Looking at the = newly emerged EAP-GPSK, all the peer needs to know is the ID it gave the = server and the server ID, in order to pull out the correct security association to = carry out EAP-GPSK. It can be informed whether access or service was granted = *after* this is all done, by some other means that have nothing to do with EAP. =

 

In the network that we have deployed, and in others that we hope = to deploy some day, multiple EAP sessions do come into play but the overall = authentication mechanism can be made to work in a fairly simple fashion without any = additional EAP-related mechanisms/layers.

 

Michaela

Nakhjiri = Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com> = wrote:



-----Original Message-----
From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]
Sent: Monday, June 12, 2006 11:58 PM
To: Quinn Li; Cao Zhen
Cc: eap@frascone.com
Subject: Re: [eap] Questions for draft-barany-eap-gee-01

Hi,

GEE is not a general purpose authentication protocol. It is a
generic EAP encapsulation mechanism that allows demultiplexing of
multiple simultaneous EAP conversations between a peer and an
authenticator. You say that the draft does describe the MVNO
scenarios well, so I guess we can safely conclude that it does its = job
then.

EAP is not used for IMS or Mobile IPv6 authentication, is it? So, in =
simple terms, it's not the purpose of the GEE draft to specify
support for those services.

Madjid>>EAP is being used for non-cellular access into IMS.
EAP is being considered for MIP6 bootstrapping.
If the idea is to standardize the usage, then it should not be
customized for a specific use case.

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: = http://lists.frascone.com/pipermail/eap

 

 ________________________________________= __________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

------_=_NextPart_001_01C6949B.79861EF0-- --===============0706167281== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap --===============0706167281==-- From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Jun 20 15:07:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FslZq-0001s8-I2 for eap-archive@lists.ietf.org; Tue, 20 Jun 2006 15:07:54 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FslZp-0006pJ-1W for eap-archive@lists.ietf.org; Tue, 20 Jun 2006 15:07:54 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id AF410430160 for ; Tue, 20 Jun 2006 12:07:52 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 7612D430092 for ; Tue, 20 Jun 2006 12:07:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 642B839803E for ; Tue, 20 Jun 2006 12:07:38 -0700 (PDT) Received: from motgate2.mot.com (motgate2.mot.com [144.189.100.101]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3CBD3398033 for ; Tue, 20 Jun 2006 12:07:32 -0700 (PDT) Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id k5KJ7W5t012030 for ; Tue, 20 Jun 2006 12:07:32 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k5KJ7Vgc010969 for ; Tue, 20 Jun 2006 14:07:32 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 20 Jun 2006 15:07:29 -0400 Message-ID: In-Reply-To: <2EBB8025B6D1BA41B567DB32C1D8DB84A1DCB2@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Questions for draft-barany-eap-gee-01 Thread-Index: AcaOpf113Z/kctPHRyOP0GrHgbgRhgF1AfbAAAZE/KAAAh1J4A== From: "Nakhjiri Madjid-MNAKHJI1" To: "Narayanan, Vidya" , "Dondeti, Lakshminath" , "Quinn Li" , "Cao Zhen" X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com Subject: Re: [eap] Questions for draft-barany-eap-gee-01 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 First of all, multiple parallel EAPs between who and whom. In general case one end is the peer but the other end is not always the same. Second, I can see a case where you have to do both IMS authentication and MIP6 authentication, not sure if "parallelism" can be achieved but that is just the nature of the beast. Third, when I want to design a system, I usually look for the best solution for each system, not why a specific solution cannot be used. I just don't see anything remarkable about putting a new layer in EAP except the adding complexity to something that is already too complex. I personally cannot justify spending the time explaining all the EAP keying layering concepts to an implementer under deadline pressure, let alone adding yet another layer through an addendum to EAP keying. I have already seen that nobody but a small group of people understands the layering concepts anyway. Madjid -----Original Message----- From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] Sent: Tuesday, June 20, 2006 1:11 PM To: Nakhjiri Madjid-MNAKHJI1; Dondeti, Lakshminath; Quinn Li; Cao Zhen Cc: eap@frascone.com Subject: Re: [eap] Questions for draft-barany-eap-gee-01 Madjid, There is no customization for any specific use case. GEE can be used any time multiple parallel EAP runs are needed on a given lower layer. I don't, however, see a use case where multiple parallel runs of EAP will be required for a service such as MIP6 or IMS. If there is such a use case, there is no reason why GEE cannot be used. If you think of a case where GEE cannot be used to demultiplex multiple parallel EAP exchanges, please share your thoughts on it. Thanks, Vidya > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Tuesday, June 20, 2006 8:02 AM > To: Dondeti, Lakshminath; Quinn Li; Cao Zhen > Cc: eap@frascone.com > Subject: Re: [eap] Questions for draft-barany-eap-gee-01 > > > > -----Original Message----- > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] > Sent: Monday, June 12, 2006 11:58 PM > To: Quinn Li; Cao Zhen > Cc: eap@frascone.com > Subject: Re: [eap] Questions for draft-barany-eap-gee-01 > > Hi, > > GEE is not a general purpose authentication protocol. It is > a generic EAP encapsulation mechanism that allows > demultiplexing of multiple simultaneous EAP conversations > between a peer and an authenticator. You say that the draft > does describe the MVNO scenarios well, so I guess we can > safely conclude that it does its job then. > > EAP is not used for IMS or Mobile IPv6 authentication, is it? > So, in simple terms, it's not the purpose of the GEE draft > to specify support for those services. > > Madjid>>EAP is being used for non-cellular access into IMS. > EAP is being considered for MIP6 bootstrapping. > If the idea is to standardize the usage, then it should not > be customized for a specific use case. > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap > > Arhives: http://lists.frascone.com/pipermail/eap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Jun 20 15:19:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsll8-0000j2-F1 for eap-archive@lists.ietf.org; Tue, 20 Jun 2006 15:19:34 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsll7-0008Bt-K2 for eap-archive@lists.ietf.org; Tue, 20 Jun 2006 15:19:34 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 412504300FC for ; Tue, 20 Jun 2006 12:19:33 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 630A24300D4 for ; Tue, 20 Jun 2006 12:19:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1EA9E431250 for ; Tue, 20 Jun 2006 12:19:06 -0700 (PDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by hermes.tigertech.net (Postfix) with ESMTP id 165ED43124C for ; Tue, 20 Jun 2006 12:19:03 -0700 (PDT) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5KJJ1B2020951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Jun 2006 12:19:02 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5KJIv5s005763; Tue, 20 Jun 2006 12:19:00 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 12:19:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 20 Jun 2006 12:19:13 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB84A1DCEB@NAEX06.na.qualcomm.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Questions for draft-barany-eap-gee-01 Thread-Index: AcaUmoULgd9TM+m6Rzef8AeYiSJuQwAAIfUQAABqstA= From: "Narayanan, Vidya" To: "Nakhjiri Madjid-MNAKHJI1" , "M. Vanderveen" , "Dondeti, Lakshminath" , "Quinn Li" , "Cao Zhen" X-OriginalArrivalTime: 20 Jun 2006 19:19:00.0012 (UTC) FILETIME=[62367EC0:01C6949E] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests=HTML_60_70, HTML_MESSAGE X-Spam-Level: Cc: eap@frascone.com Subject: Re: [eap] Questions for draft-barany-eap-gee-01 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0093894848==" Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 715d0e6950aaebd45af78ef9318d0186 This is a multi-part message in MIME format. --===============0093894848== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6949E.61D47FDE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6949E.61D47FDE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Michaela, Madjid, GEE has nothing to do with AAA or EAP methods - it is about demultiplexing multiple parallel EAP sessions at the peer and the authenticator. So, I find this exchange a bit confusing.=20 =20 Vidya ________________________________ From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]=20 Sent: Tuesday, June 20, 2006 11:58 AM To: M. Vanderveen; Dondeti, Lakshminath; Quinn Li; Cao Zhen Cc: eap@frascone.com Subject: Re: [eap] Questions for draft-barany-eap-gee-01 =09 =09 I agree, it seems that AAA functions that are typically done after authentication are introduced into EAP messaging, while EAP is just a protocol to carry authentication exchanges. EAP is an "authentication" protocol, not a AAA protocol. =20 Madjid =20 =20 =09 ________________________________ From: M. Vanderveen [mailto:mvandervn@yahoo.com]=20 Sent: Tuesday, June 20, 2006 1:51 PM To: Nakhjiri Madjid-MNAKHJI1; Lakshminath Dondeti; Quinn Li; Cao Zhen Cc: eap@frascone.com Subject: Re: [eap] Questions for draft-barany-eap-gee-01 =20 While a solution for demultiplexing several EAP sessions might be helpful, part of the resistance to the introduction of this sublayer is probably due to the fact that there are ways around this issue.=20 =20 It's not clear to me why we are trying to inform the peer as whether the current EAP session is for service vs. for access. Looking at the newly emerged EAP-GPSK, all the peer needs to know is the ID it gave the server and the server ID, in order to pull out the correct security association to carry out EAP-GPSK. It can be informed whether access or service was granted *after* this is all done, by some other means that have nothing to do with EAP.=20 =20 In the network that we have deployed, and in others that we hope to deploy some day, multiple EAP sessions do come into play but the overall authentication mechanism can be made to work in a fairly simple fashion without any additional EAP-related mechanisms/layers.=20 =20 Michaela =09 Nakhjiri Madjid-MNAKHJI1 wrote: =09 =09 -----Original Message----- From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] Sent: Monday, June 12, 2006 11:58 PM To: Quinn Li; Cao Zhen Cc: eap@frascone.com Subject: Re: [eap] Questions for draft-barany-eap-gee-01 =09 Hi, =09 GEE is not a general purpose authentication protocol. It is a=20 generic EAP encapsulation mechanism that allows demultiplexing of=20 multiple simultaneous EAP conversations between a peer and an=20 authenticator. You say that the draft does describe the MVNO=20 scenarios well, so I guess we can safely conclude that it does its job then. =09 EAP is not used for IMS or Mobile IPv6 authentication, is it? So, in=20 simple terms, it's not the purpose of the GEE draft to specify=20 support for those services. =09 Madjid>>EAP is being used for non-cellular access into IMS. EAP is being considered for MIP6 bootstrapping. If the idea is to standardize the usage, then it should not be customized for a specific use case. =09 =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap =09 Arhives: http://lists.frascone.com/pipermail/eap =20 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around=20 http://mail.yahoo.com=20 ------_=_NextPart_001_01C6949E.61D47FDE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Michaela, Madjid,
GEE has nothing to do with AAA or EAP methods - = it is about=20 demultiplexing multiple parallel EAP sessions at the peer and the = authenticator.=20 So, I find this exchange a bit confusing.
 
Vidya

 ------_=_NextPart_001_01C6949E.61D47FDE-- --===============0093894848== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap --===============0093894848==-- From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Jun 20 15:21:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FslnS-0001Mr-VJ for eap-archive@lists.ietf.org; Tue, 20 Jun 2006 15:21:58 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FslnS-0008KP-EQ for eap-archive@lists.ietf.org; Tue, 20 Jun 2006 15:21:58 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id BFED743015B for ; Tue, 20 Jun 2006 12:21:57 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id AAEF84300D4 for ; Tue, 20 Jun 2006 12:21:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 930A543125A for ; Tue, 20 Jun 2006 12:21:40 -0700 (PDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by hermes.tigertech.net (Postfix) with ESMTP id 5FFBA431257 for ; Tue, 20 Jun 2006 12:21:37 -0700 (PDT) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5KJLZgd016084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Jun 2006 12:21:36 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5KJKqpA018076; Tue, 20 Jun 2006 12:21:35 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 12:21:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 20 Jun 2006 12:21:19 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB84A1DCED@NAEX06.na.qualcomm.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Questions for draft-barany-eap-gee-01 Thread-Index: AcaOpf113Z/kctPHRyOP0GrHgbgRhgF1AfbAAAZE/KAAAh1J4AAAuJYw From: "Narayanan, Vidya" To: "Nakhjiri Madjid-MNAKHJI1" , "Dondeti, Lakshminath" , "Quinn Li" , "Cao Zhen" X-OriginalArrivalTime: 20 Jun 2006 19:21:05.0599 (UTC) FILETIME=[AD118CF0:01C6949E] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: eap@frascone.com Subject: Re: [eap] Questions for draft-barany-eap-gee-01 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Madjid, > > First of all, multiple parallel EAPs between who and whom. In > general case one end is the peer but the other end is not > always the same. > This is clearly explained in the draft - do you find that explantion to not be adequate? If so, it would help if you point out the issues with the details in the draft. > Second, I can see a case where you have to do both IMS > authentication and MIP6 authentication, not sure if > "parallelism" can be achieved but that is just the nature of > the beast. > It is about running them in parallel on the same lower layer. IMS and MIP6 are different services - I don't see any reason why you can't authenticate for both in parallel with what is available today. Vidya > Third, when I want to design a system, I usually look for the > best solution for each system, not why a specific solution > cannot be used. I just don't see anything remarkable about > putting a new layer in EAP except the adding complexity to > something that is already too complex. I personally cannot > justify spending the time explaining all the EAP keying > layering concepts to an implementer under deadline pressure, > let alone adding yet another layer through an addendum to EAP > keying. I have already seen that nobody but a small group of > people understands the layering concepts anyway. > > Madjid > > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > Sent: Tuesday, June 20, 2006 1:11 PM > To: Nakhjiri Madjid-MNAKHJI1; Dondeti, Lakshminath; Quinn Li; Cao Zhen > Cc: eap@frascone.com > Subject: Re: [eap] Questions for draft-barany-eap-gee-01 > > > Madjid, > There is no customization for any specific use case. GEE can > be used any > time multiple parallel EAP runs are needed on a given lower layer. I > don't, however, see a use case where multiple parallel runs > of EAP will > be required for a service such as MIP6 or IMS. If there is such a use > case, there is no reason why GEE cannot be used. > > If you think of a case where GEE cannot be used to > demultiplex multiple > parallel EAP exchanges, please share your thoughts on it. > > Thanks, > Vidya > > > -----Original Message----- > > From: Nakhjiri Madjid-MNAKHJI1 > [mailto:Madjid.Nakhjiri@motorola.com] > > Sent: Tuesday, June 20, 2006 8:02 AM > > To: Dondeti, Lakshminath; Quinn Li; Cao Zhen > > Cc: eap@frascone.com > > Subject: Re: [eap] Questions for draft-barany-eap-gee-01 > > > > > > > > -----Original Message----- > > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] > > Sent: Monday, June 12, 2006 11:58 PM > > To: Quinn Li; Cao Zhen > > Cc: eap@frascone.com > > Subject: Re: [eap] Questions for draft-barany-eap-gee-01 > > > > Hi, > > > > GEE is not a general purpose authentication protocol. It is > > a generic EAP encapsulation mechanism that allows > > demultiplexing of multiple simultaneous EAP conversations > > between a peer and an authenticator. You say that the draft > > does describe the MVNO scenarios well, so I guess we can > > safely conclude that it does its job then. > > > > EAP is not used for IMS or Mobile IPv6 authentication, is it? > > So, in simple terms, it's not the purpose of the GEE draft > > to specify support for those services. > > > > Madjid>>EAP is being used for non-cellular access into IMS. > > EAP is being considered for MIP6 bootstrapping. > > If the idea is to standardize the usage, then it should not > > be customized for a specific use case. > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/eap > > > > Arhives: http://lists.frascone.com/pipermail/eap > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap > > Arhives: http://lists.frascone.com/pipermail/eap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From 644sqp62ub@mail.ru Tue Jun 20 20:30:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsqbr-00046k-Ux for eap-archive@ietf.org; Tue, 20 Jun 2006 20:30:19 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsqbr-00038z-St for eap-archive@ietf.org; Tue, 20 Jun 2006 20:30:19 -0400 Received: from 220-130-178-154.hinet-ip.hinet.net ([220.130.178.154]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fsqbr-0002jq-1q for eap-archive@ietf.org; Tue, 20 Jun 2006 20:30:19 -0400 Message-ID: <662161c80604elzbmq2nv7wdbw7ri0mof0vsgu37y09js@mxs.mail.ru> Date: Wed, 21 Jun 2006 00:40:43 -0480 From: "Lawrence Eldridge" <644sqp62ub@mail.ru> To: eap-archive@ietf.org Subject: fw: TopPicker MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam: Not detected X-Spam-Score: 4.9 (++++) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Our weekly gift to you! Big Press Release just out. Inf inex Vent ures Inc. (INFX) Price: 0.83 5 day expected price 1.90 This one will run for sure Starting a new Marketing Campaign Today. The World will know about this company Should you wait until to late? This one did very well during last marketing campaign. Very Well! With this News we expect prices to exceed our projected price of 1.90 In finex Ventures Inc. - Update On Agreement With Property In Chile Wednesday June 14, 11:19 am ET LAS VEGAS, NV, June 14 /FirstCall/ - In finex Ventures Inc. is pleased to announce that on January 30, 2006, we entered into an agreement ("Agreement"), with Rodolfo Francisco Villar ("Vendor") to purchase a 50% interest in the mining and exploration of the following Claims, the ("Claims"): REFERENCES ROLL NUMBER 139 TESORO 1 1 - 30 03304-0532-5 140 TESORO 2 1 - 12 03304-0532-3 141 TESORO 3 1 - 30 03304-0534-1 142 TESORO 4 1 - 30 03304-0535-K 143 TESORO 5 1 - 25 03304-0536-8 144 TESORO 6 1 - 20 03304-0537-6 145 TESORO 7 1 - 25 03304-0538-4 146 TESORO 8 1 - 12 03304-0539-2 147 TESORO 9 1 - 12 03304-0540-6 148 TESORO 10 1 - 20 03304-0541-4 149 TESORO 11 1 - 20 03304-0542-2 150 TESORO 12 1 - 5 03304-0543-0 These Claims are more particularly located at the northern end of the El Indio Belt in Chile Region III which is approximately 150 kms. East of the City of Vallenar, Chile. 1. Under the terms of the Agreement, the Vendor will grant to the Company the sole and exclusive irrevocable right and title to the Claims, subject to: (i) the completion by the Company of confirmation of legal title and due diligence on the Properties as to ownership by the Vendor and results therefrom being satisfactory to the Company, acting reasonably, within a period of 90 days; (ii) the right to extend a further 90 days by mutual consent. (the right to extend a further 90 days has been granted to the Company, in an effort to complete its due diligence); (iii) The Vendor and the Company shall put forth, all their reasonable best efforts to obtain a satisfactory title opinion or Court Order, or such that the Company will acquire the property free and clear of all liens and encumbrances, with a view to further develop the property into an operating mine. 2. Upon satisfactory completion of the due diligence and clear title being established, the Company will then: (a) issue to the Vendor Twenty Million (20,000,000) Common Shares, upon the execution by the parties of this Agreement and subject to the subject conditions as set out above; and (b) that all original documents or notarized copies of official translations are therefore required to complete the transactions contemplated in the Agreement. The issuance of the 20 Million (20,000,000) Common Shares shall be issued in the Vendors designated name to the benefit of Vendor, upon the removal of the subject conditions as set out above. 3. Further, satisfactory completion of the due diligence and clear title being established the Purchaser with the assistance of the Vendor, (if necessary), will apply for permits to the appropriate authorities to place the property into production. Upon the appropriate permits being approved, the Purchaser will have the option to acquire an additional 25% interest in the property (bringing the Purchaser interest to 75%) in exchange for a further issuance of Ten Million (10,000,000) Common shares of the Company's stock. We are presently pursuing further due diligence on these Claims. From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Jun 20 20:59:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsr4B-0005Zv-1S for eap-archive@lists.ietf.org; Tue, 20 Jun 2006 20:59:35 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsr49-0004kt-Du for eap-archive@lists.ietf.org; Tue, 20 Jun 2006 20:59:35 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 69C9D43004F for ; Tue, 20 Jun 2006 17:59:32 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 1C71243004F for ; Tue, 20 Jun 2006 17:59:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0D10139800C for ; Tue, 20 Jun 2006 17:59:13 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by zoidberg.tigertech.net (Postfix) with ESMTP id 72060398045 for ; Tue, 20 Jun 2006 17:59:09 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id A71B090015; Tue, 20 Jun 2006 20:59:06 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03005-07; Tue, 20 Jun 2006 20:59:05 -0400 (EDT) Received: from ames.starentnetworks.com (ames.starentnetworks.com [12.33.235.15]) by mx0.starentnetworks.com (Postfix) with ESMTP; Tue, 20 Jun 2006 20:59:05 -0400 (EDT) X-MessageTextProcessor: DisclaimIt (2.50.252) [Starent Networks Corp.] Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by ames.starentnetworks.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 20 Jun 2006 20:56:08 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: normal Priority: normal Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 20 Jun 2006 20:56:08 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D73C51A8@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Questions for draft-barany-eap-gee-01 thread-index: AcaOpf113Z/kctPHRyOP0GrHgbgRhgF1AfbAAAZE/KAAAh1J4AAAuJYwAAuA2RA= From: "Chowdhury, Kuntal" To: "Narayanan, Vidya" , "Nakhjiri Madjid-MNAKHJI1" , "Dondeti, Lakshminath" , "Quinn Li" , "Cao Zhen" X-OriginalArrivalTime: 21 Jun 2006 00:56:08.0692 (UTC) FILETIME=[7B721B40:01C694CD] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com Subject: Re: [eap] Questions for draft-barany-eap-gee-01 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d All, A use case for parallel EAP transaction is: terminal auth and user auth. If you take this simple use case, it may be easier for you to understand why parallel EAP transactions may be useful. Even if the authenticators are not the same, the de-multiplexing layer (GEE in this case) allows the MN to differentiate the EAP packets. -Kuntal > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > Sent: Tuesday, June 20, 2006 2:21 PM > To: Nakhjiri Madjid-MNAKHJI1; Dondeti, Lakshminath; Quinn Li; Cao Zhen > Cc: eap@frascone.com > Subject: Re: [eap] Questions for draft-barany-eap-gee-01 > > > Madjid, > > > > > First of all, multiple parallel EAPs between who and whom. In > > general case one end is the peer but the other end is not > > always the same. > > > > This is clearly explained in the draft - do you find that explantion to > not be adequate? If so, it would help if you point out the issues with > the details in the draft. > > > Second, I can see a case where you have to do both IMS > > authentication and MIP6 authentication, not sure if > > "parallelism" can be achieved but that is just the nature of > > the beast. > > > > It is about running them in parallel on the same lower layer. IMS and > MIP6 are different services - I don't see any reason why you can't > authenticate for both in parallel with what is available today. > > Vidya > > > Third, when I want to design a system, I usually look for the > > best solution for each system, not why a specific solution > > cannot be used. I just don't see anything remarkable about > > putting a new layer in EAP except the adding complexity to > > something that is already too complex. I personally cannot > > justify spending the time explaining all the EAP keying > > layering concepts to an implementer under deadline pressure, > > let alone adding yet another layer through an addendum to EAP > > keying. I have already seen that nobody but a small group of > > people understands the layering concepts anyway. > > > > Madjid > > > > -----Original Message----- > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > Sent: Tuesday, June 20, 2006 1:11 PM > > To: Nakhjiri Madjid-MNAKHJI1; Dondeti, Lakshminath; Quinn Li; Cao Zhen > > Cc: eap@frascone.com > > Subject: Re: [eap] Questions for draft-barany-eap-gee-01 > > > > > > Madjid, > > There is no customization for any specific use case. GEE can > > be used any > > time multiple parallel EAP runs are needed on a given lower layer. I > > don't, however, see a use case where multiple parallel runs > > of EAP will > > be required for a service such as MIP6 or IMS. If there is such a use > > case, there is no reason why GEE cannot be used. > > > > If you think of a case where GEE cannot be used to > > demultiplex multiple > > parallel EAP exchanges, please share your thoughts on it. > > > > Thanks, > > Vidya > > > > > -----Original Message----- > > > From: Nakhjiri Madjid-MNAKHJI1 > > [mailto:Madjid.Nakhjiri@motorola.com] > > > Sent: Tuesday, June 20, 2006 8:02 AM > > > To: Dondeti, Lakshminath; Quinn Li; Cao Zhen > > > Cc: eap@frascone.com > > > Subject: Re: [eap] Questions for draft-barany-eap-gee-01 > > > > > > > > > > > > -----Original Message----- > > > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] > > > Sent: Monday, June 12, 2006 11:58 PM > > > To: Quinn Li; Cao Zhen > > > Cc: eap@frascone.com > > > Subject: Re: [eap] Questions for draft-barany-eap-gee-01 > > > > > > Hi, > > > > > > GEE is not a general purpose authentication protocol. It is > > > a generic EAP encapsulation mechanism that allows > > > demultiplexing of multiple simultaneous EAP conversations > > > between a peer and an authenticator. You say that the draft > > > does describe the MVNO scenarios well, so I guess we can > > > safely conclude that it does its job then. > > > > > > EAP is not used for IMS or Mobile IPv6 authentication, is it? > > > So, in simple terms, it's not the purpose of the GEE draft > > > to specify support for those services. > > > > > > Madjid>>EAP is being used for non-cellular access into IMS. > > > EAP is being considered for MIP6 bootstrapping. > > > If the idea is to standardize the usage, then it should not > > > be customized for a specific use case. > > > > > > _________________________________________________________________ > > > To unsubscribe or modify your subscription options, please visit: > > > http://lists.frascone.com/mailman/listinfo/eap > > > > > > Arhives: http://lists.frascone.com/pipermail/eap > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/eap > > > > Arhives: http://lists.frascone.com/pipermail/eap > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap > > Arhives: http://lists.frascone.com/pipermail/eap "This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster@starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you." _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Jun 20 23:38:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FstXy-0001vr-9J for eap-archive@lists.ietf.org; Tue, 20 Jun 2006 23:38:30 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FstXs-0000t1-BD for eap-archive@lists.ietf.org; Tue, 20 Jun 2006 23:38:30 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 52B70430104 for ; Tue, 20 Jun 2006 20:38:23 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id E820E430064 for ; Tue, 20 Jun 2006 20:38:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C5E881448006 for ; Tue, 20 Jun 2006 20:38:06 -0700 (PDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by hermes.tigertech.net (Postfix) with ESMTP id 07C541448018 for ; Tue, 20 Jun 2006 20:38:02 -0700 (PDT) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5L3c1Jk031175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Jun 2006 20:38:02 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-39.qualcomm.com [10.50.76.39]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5L3bxGO012679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Jun 2006 20:38:00 -0700 (PDT) Message-Id: <7.0.1.0.2.20060620130757.061de238@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 20 Jun 2006 20:37:57 -0700 To: "M. Vanderveen" From: Lakshminath Dondeti In-Reply-To: <20060620185115.44261.qmail@web54415.mail.yahoo.com> References: <20060620185115.44261.qmail@web54415.mail.yahoo.com> Mime-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: eap@frascone.com Subject: Re: [eap] Questions for draft-barany-eap-gee-01 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Michaela, It looks like you are confusing several things here. Please see inline some clarifications. At 11:51 AM 6/20/2006, M. Vanderveen wrote: >While a solution for demultiplexing several EAP sessions might be >helpful, part of the resistance to the introduction of this sublayer >is probably due to the fact that there are ways around this issue. There is a need for parallel EAP authentications; that has been clearly expressed by some operators. EAP (RFC 3748 and its ilk) does not have support for multiple parallel authentications. We can either do what Alper says and provide support in every lower layer, or do it in a lower layer agnostic fashion. This is a new feature (not supported in any lower layer) and so doing it at the EAP level would be a universal solution and makes perfect sense. > >It's not clear to me why we are trying to inform the peer as whether >the current EAP session is for service vs. for access. Looking at >the newly emerged EAP-GPSK, all the peer needs to know is the ID it >gave the server and the server ID, in order to pull out the correct >security association to carry out EAP-GPSK. It can be informed >whether access or service was granted *after* this is all done, by >some other means that have nothing to do with EAP. GEE has little to do with methods, period. I am not sure which part of the I-D gave you that impression. Could you please point any sections that led you to this confusion? We would like to fix it. > >In the network that we have deployed, and in others that we hope to >deploy some day, multiple EAP sessions do come into play but the >overall authentication mechanism can be made to work in a fairly >simple fashion without any additional EAP-related mechanisms/layers. As I note above, the multiple parallel authentications use case came from operators. Next, I am concerned about your phrase "can be made to work"; if you mean proprietary hacks by that, that's not really desirable, is it? best regards, Lakshminath > >Michaela > >Nakhjiri Madjid-MNAKHJI1 wrote: > >-----Original Message----- >From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] >Sent: Monday, June 12, 2006 11:58 PM >To: Quinn Li; Cao Zhen >Cc: eap@frascone.com >Subject: Re: [eap] Questions for draft-barany-eap-gee-01 >Hi, >GEE is not a general purpose authentication protocol. It is a >generic EAP encapsulation mechanism that allows demultiplexing of >multiple simultaneous EAP conversations between a peer and an >authenticator. You say that the draft does describe the MVNO >scenarios well, so I guess we can safely conclude that it does its job >then. >EAP is not used for IMS or Mobile IPv6 authentication, is it? So, in >simple terms, it's not the purpose of the GEE draft to specify >support for those services. >Madjid>>EAP is being used for non-cellular access into IMS. >EAP is being considered for MIP6 bootstrapping. >If the idea is to standardize the usage, then it should not be >customized for a specific use case. >_________________________________________________________________ >To unsubscribe or modify your subscription options, please visit: >http://lists.frascone.com/mailman/listinfo/eap >Arhives: http://lists.frascone.com/pipermail/eap > > >__________________________________________________ >Do You Yahoo!? >Tired of spam? Yahoo! Mail has the best spam protection around >http://mail.yahoo.com _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Jun 20 23:41:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FstaY-0004Tv-5b for eap-archive@lists.ietf.org; Tue, 20 Jun 2006 23:41:10 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FstaU-0001UI-Ks for eap-archive@lists.ietf.org; Tue, 20 Jun 2006 23:41:10 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 369F9430130 for ; Tue, 20 Jun 2006 20:41:06 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id D457F43004F for ; Tue, 20 Jun 2006 20:40:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id BE5611448006 for ; Tue, 20 Jun 2006 20:40:45 -0700 (PDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by hermes.tigertech.net (Postfix) with ESMTP id 2FAA61448011 for ; Tue, 20 Jun 2006 20:40:42 -0700 (PDT) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5L3eglK003075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Jun 2006 20:40:42 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-39.qualcomm.com [10.50.76.39]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5L3eecn017276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Jun 2006 20:40:40 -0700 (PDT) Message-Id: <7.0.1.0.2.20060620203852.05ff48b0@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 20 Jun 2006 20:40:38 -0700 To: "Nakhjiri Madjid-MNAKHJI1" , "M. Vanderveen" , "Quinn Li" , "Cao Zhen" From: Lakshminath Dondeti In-Reply-To: References: <20060620185115.44261.qmail@web54415.mail.yahoo.com> Mime-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: eap@frascone.com Subject: Re: [eap] Questions for draft-barany-eap-gee-01 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be At 11:58 AM 6/20/2006, Nakhjiri Madjid-MNAKHJI1 wrote: >I agree, it seems that AAA functions that are typically done after >authentication are introduced into EAP messaging, while EAP is just >a protocol to carry authentication exchanges. EAP is an >"authentication" protocol, not a AAA protocol. I am confused here. I see no reference to AAA, especially the AAA protocol, in the emails below. What are you referring to? Lakshminath > >Madjid > > > >---------- >From: M. Vanderveen [mailto:mvandervn@yahoo.com] >Sent: Tuesday, June 20, 2006 1:51 PM >To: Nakhjiri Madjid-MNAKHJI1; Lakshminath Dondeti; Quinn Li; Cao Zhen >Cc: eap@frascone.com >Subject: Re: [eap] Questions for draft-barany-eap-gee-01 > >While a solution for demultiplexing several EAP sessions might be >helpful, part of the resistance to the introduction of this sublayer >is probably due to the fact that there are ways around this issue. > >It's not clear to me why we are trying to inform the peer as whether >the current EAP session is for service vs. for access. Looking at >the newly emerged EAP-GPSK, all the peer needs to know is the ID it >gave the server and the server ID, in order to pull out the correct >security association to carry out EAP-GPSK. It can be informed >whether access or service was granted *after* this is all done, by >some other means that have nothing to do with EAP. > >In the network that we have deployed, and in others that we hope to >deploy some day, multiple EAP sessions do come into play but the >overall authentication mechanism can be made to work in a fairly >simple fashion without any additional EAP-related mechanisms/layers. > >Michaela > >Nakhjiri Madjid-MNAKHJI1 wrote: > > >-----Original Message----- >From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] >Sent: Monday, June 12, 2006 11:58 PM >To: Quinn Li; Cao Zhen >Cc: eap@frascone.com >Subject: Re: [eap] Questions for draft-barany-eap-gee-01 > >Hi, > >GEE is not a general purpose authentication protocol. It is a >generic EAP encapsulation mechanism that allows demultiplexing of >multiple simultaneous EAP conversations between a peer and an >authenticator. You say that the draft does describe the MVNO >scenarios well, so I guess we can safely conclude that it does its job >then. > >EAP is not used for IMS or Mobile IPv6 authentication, is it? So, in >simple terms, it's not the purpose of the GEE draft to specify >support for those services. > >Madjid>>EAP is being used for non-cellular access into IMS. >EAP is being considered for MIP6 bootstrapping. >If the idea is to standardize the usage, then it should not be >customized for a specific use case. > >_________________________________________________________________ >To unsubscribe or modify your subscription options, please visit: >http://lists.frascone.com/mailman/listinfo/eap > >Arhives: http://lists.frascone.com/pipermail/eap > > > > __________________________________________________ >Do You Yahoo!? >Tired of spam? Yahoo! Mail has the best spam protection around >http://mail.yahoo.com _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From mikel@jrockey.com Wed Jun 21 04:43:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsyJO-0005Z4-SU for eap-archive@ietf.org; Wed, 21 Jun 2006 04:43:46 -0400 Received: from bzq-88-155-35-77.red.bezeqint.net ([88.155.35.77] helo=jrockey.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FsyJM-0000Is-Iz for eap-archive@ietf.org; Wed, 21 Jun 2006 04:43:46 -0400 Message-ID: <000001c6950e$cf89c070$a162a8c0@gef11> Reply-To: "Gillian Mikel" From: "Gillian Mikel" To: eap-archive@ietf.org Subject: Re: zoroh new Date: Wed, 21 Jun 2006 01:43:47 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C694D4.232AE870" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.8 (+++) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C694D4.232AE870 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0002_01C694D4.232AE870" ------=_NextPart_001_0002_01C694D4.232AE870 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable http://dasetunhandecas.com _____ =20 ring, fastened his rope, slipped down over the wall, and was gone. He had about five hours before him. Bombur would sleep (he could sleep at any time, and ever since the adventure in the forest he was always trying to recapture the beautiful dreams he had then); and all the others were busy with Thorin. It was unlikely that any, even Fili or Kili, would come out on the wall until it was their turn. It was very ------=_NextPart_001_0002_01C694D4.232AE870 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
ring, fastened his rope, slipped down over the wall, = and was gone. He
had about five hours before him. Bombur would sleep (he could sleep = at
any time, and ever since the adventure in the forest he was always
trying to recapture the beautiful dreams he had then); and all the
others were busy with Thorin. It was unlikely that any, even Fili or
Kili, would come out on the wall until it was their turn. It was = very

------=_NextPart_001_0002_01C694D4.232AE870-- ------=_NextPart_000_0001_01C694D4.232AE870 Content-Type: image/gif; name="vizard23.gif" Content-Transfer-Encoding: base64 Content-ID: <000101c6950e$cf85009e$a162a8c0@gef11> R0lGODdhxwDHAMIAAAAAADxHlf///wAA//8AAPa/7QAAAAAAACwAAAAAxwDHAAAD/ii63P4wyskK vZjaXLn/YChsYmmeaKqq5Oq+WdtqcB3NIP7odu//Hh6wJ1QIi8YV8rQcSpbNSdTJgVJN0ytmE81q IRbvTjoSiWmN8BdWOJJZ1PP6JRfL5+DrHf8IBC57WCgzgXwZfh+IEIpEHYZjDoVbIH6MGJYNmI8L kptlT4mVN31/JVyeaVVskEFJE5WlCoiiArSzmIywC7eaqJ2pqJyluYq2f8YMxcPLzI0uvz9ZyhvE u8exI6UFt8nX3TnBnOFoytbmst7mFtzmlr3jIWfQl7DI6O1/1LG89bXY7zV08LDzYV4Id8vKVEOI LxVDeAXx7HmoaNu+dPfu9dr2/g2iR1WOrP1j5w9fgHUjM8oqKewjyDeR1lh0QHJhv47+7KmESMKg Sxs4fP4ElwfUkDpDYwBLKjReTKJLn0ZLmqIpn1N5rLoS6Kqr16NaulAF9MlMhJses2g1GlJQj5Pn fHjpOXXsClx26QARGgjgSYbGsOUEmBeNHqfdBKNDKRJdQln6FIcdRdUqWooXdwVlWdhZOF2cs6ms JpKWm1aTqiKmKsoSR86vZ46W/Mxt5R/sGHMm/TBOxFW+wAie1aLc7J2EDa0tapayB9IsofP2g5J2 Z5h50TqOJXv3RZLirou3u9z5+PBSDBYpz3Oy6vd147OSqPfl+fuG3QPFv38c/nvUweGR3Bb5DChV QerRNwdhURgH34H88WEgB9RFFQ5fm0hDG2jemaQLMbQEeN0dumXyWGu5cNHMLo3ZFlCE82lSUXQY 0bgTTdbVB+MLMqZUEmY3DsbIWoHsYYUhiBT3F2jUPfQaLpm9KKJ5bKF3Qo9nQZlRb6H5BqBSUjKB 45iLvHaOg6FNuBdwXjJ3Qz4mJtPimY855thpv1noxHpfkWWKcDdZFOJKcW43HIqpQcgTIfz9l5cM Lv6p52F5+ifpWJ1A4+iI/e2I32Z9evqlXGU55ag8kyoxalqlblJPjpvqN8hqa0AXqqKPMCommJUm eqWPov4Ua1w/YsThqxd1/jfYmrJ6dldKIcrW4zAt5tIrpayc6gJgwHb5DnhSDrsqklFyyWU2H+Yo 06zjtpunoJXog5N33NnELpXmiRtML+ZGidwxw4Ia7EGS9Xsjt83heuulbS1s36hT8HvolkPmZOdu cNwbjKYSSIwjiEwiaqibYXZ6g7apDWTlwCtPAqnJLOt7H4kXRkhXeg+r6ttyauSsc3tzyLyns0O8 g1UJHKaag5kNs+yPkq9ooy52ieVXKVxkZomlxviGUmiWQaKgps+vukKYMt3+uZyti0xtytitOmzE MYQue1ZHSf8cd5WkEHsZM8DycvHH6ZYWZ2Bt15I4PfPuva+/yVLcW2Al/hY6KJqId6nR4hecy7eA NX4iLeA4Vdhh32kCaybbm6NOgSjyqrZ26GXXouLkkAumT+W4x/XtoMR2PHHJCjPeO43HPx22jX7n 3hIPeRvoWmg++XS5j2gHHrnmFFegfVxM0+Tt1B53DZbwcKYu+fdzW6NDkgYft9MMtFtXeeNXHYLQ itnDFaJ0G6pT93znLzkpTkuZiJ3rxjKj7TCPH6eLoOUUEz3nEe5QSesfivImll0RTWlWu4LbPuU0 Py3CV9f6QnkS1LTPvWJozUoDzWjFJrnpqDBGMmEJPVjDoQhNQY9AIKdcmDGu3VAhBTxZCncIQsf1 0GLAOyK2WqbC2iCt/kY3gWBiHAS34v3wh2IzneLslLkxWqxYQGthCAsTxYYEj05tpFoMaag3FQCv bL2BF4jMl8bioXBBMyKGspIUwXj1cT5UfJAW4Pcv9TnyjAPjkxwXKTiE0QlvedNhB4FCEIa9JTOI w4z/yhG+XDGxc9iYCSxUqT1usM4TYHxUFa3YRJd98JY+66SlcLnLU/rShCojIRETGSlS+bCW55kh wzYZxi7aMBNNA1UwpQgDBDrziicpT8EyWZqRxNFniOQVuiZozDeuonYlERTqYIe2YfLwOZkZ1jVJ 9g1qQWZuBcMb/lwCwG5u0ZU94aaQanK9M35zFhYaUPmYsEILfkdy/pAsixgniL2HGjSAZkSPQtNn TuKZADweA0wRftfIS7ZveQglhbqi+E0nuvNZyptN4dz4T4w+cnQE1JoQNqrREX4Gi3UaZT2Hxz3m NbI7pkuOQHmatXB64o5AVV/8cBQGqJlUgn0o6kQX2FF+asmSGukWSR9p1FfKyVrmxN4+nwlOgk0s c+3c3+DIiUnfkWB6hDKWAJ8U1DpxbJIg3Noq9wiumYYHTSNQZ05RakgTNRBkjvWpqOb5lRwiQbJt VSOzeNRVj2B2imzVoR0FWkzObiqWa4TKwtrgSVkOUZi3gZlLv0Yh04iTQi8N7WZ1i8r/rfQaDTLQ Lyi41CaZBp3n/plO1IrK1dQ2oXbtfF0ScUjbjC6XrZTVkOI4wrSNThecyhSBX75jLyGp1JXkHeqK +qa7tc5rnpIwyHjrdlw03k+mdb2YTg4Htqh5k7Kt/dVTyode6TYvv1hth0o18LvPwmO+hkoIPzha OrH2tavFpQyEE6ZaPrrXODjVoOvi18+OKauzmrirgwGbWsYlDkhQ2uaBr2pWFi20ue61C17QeMmU hs1WQDopc1dSjA+3VxgrHodvw8o/b7ySbVy0IP2IfCKOClIc3y0tFf52Jxv1j3PTYp9WK4g1BKu4 pU/E1G23pchf0tJdh6AVazvcywz5gMKaBa1LUAvEIfK5xaZc/tQcOSxaWLo5W7Mtp4cPzeJAv5mY jV50zY45y0gzZbfIXKJTGc1pXOlSPPE9X5o35sc15xImL8uzpNvsnj8zB4yu/qNsMx1rUdVa1nwT Wqo7zSpVvzPRrlWOsJ2BhJvBmbeiy+3PJFlHetKR1c824qiPjWsYSjuzur31eLRtlClwZc/XLjWv ob1pj+Zv2OEG9s7a2gSBQXrPRYo2NQm9ako7jdt2BrW1f73bXbsZ35heV7DHHcNiO1veBH+03PiE FDVP6rQIx7bEE05tzTKb3we/yqd9PWkt11vd9qZ4uonibpGHfNu/BjjKTa7v12Z81Cws97vpDHJe 81nlEf/4SLybzUuM63lohTiar2WG80YJfNrK1rTPI/4fogfI3yxfOr2T7mwMBbjiMz909RQtbo8n vOQv53mbtI50GRZd7FeXede9noEEAAA7 ------=_NextPart_000_0001_01C694D4.232AE870-- From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Jun 21 12:13:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft5Iy-0000zM-Qr for eap-archive@lists.ietf.org; Wed, 21 Jun 2006 12:11:48 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft58y-0003dt-CQ for eap-archive@lists.ietf.org; Wed, 21 Jun 2006 12:01:34 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 605A543019D for ; Wed, 21 Jun 2006 09:01:27 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id F3072430092 for ; Wed, 21 Jun 2006 09:01:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D61CF398013 for ; Wed, 21 Jun 2006 09:01:12 -0700 (PDT) Received: from motgate8.mot.com (motgate8.mot.com [129.188.136.8]) by zoidberg.tigertech.net (Postfix) with ESMTP id D1476398050 for ; Wed, 21 Jun 2006 09:01:01 -0700 (PDT) Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k5LG0sWN010790 for ; Wed, 21 Jun 2006 09:00:59 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k5LG0sjO024239 for ; Wed, 21 Jun 2006 11:00:54 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 21 Jun 2006 12:00:52 -0400 Message-ID: In-Reply-To: <7.0.1.0.2.20060620203852.05ff48b0@qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Questions for draft-barany-eap-gee-01 Thread-Index: AcaU5H+HAj/BLwe8Thu+lbs5JHXW2QAZ065A From: "Nakhjiri Madjid-MNAKHJI1" To: "Lakshminath Dondeti" , "M. Vanderveen" , "Quinn Li" , "Cao Zhen" X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com Subject: Re: [eap] Questions for draft-barany-eap-gee-01 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Inclusion of information regarding access versus service is an authorization act. Madjid -----Original Message----- From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] Sent: Tuesday, June 20, 2006 10:41 PM To: Nakhjiri Madjid-MNAKHJI1; M. Vanderveen; Quinn Li; Cao Zhen Cc: eap@frascone.com Subject: RE: [eap] Questions for draft-barany-eap-gee-01 At 11:58 AM 6/20/2006, Nakhjiri Madjid-MNAKHJI1 wrote: >I agree, it seems that AAA functions that are typically done after >authentication are introduced into EAP messaging, while EAP is just >a protocol to carry authentication exchanges. EAP is an >"authentication" protocol, not a AAA protocol. I am confused here. I see no reference to AAA, especially the AAA protocol, in the emails below. What are you referring to? Lakshminath > >Madjid > > > >---------- >From: M. Vanderveen [mailto:mvandervn@yahoo.com] >Sent: Tuesday, June 20, 2006 1:51 PM >To: Nakhjiri Madjid-MNAKHJI1; Lakshminath Dondeti; Quinn Li; Cao Zhen >Cc: eap@frascone.com >Subject: Re: [eap] Questions for draft-barany-eap-gee-01 > >While a solution for demultiplexing several EAP sessions might be >helpful, part of the resistance to the introduction of this sublayer >is probably due to the fact that there are ways around this issue. > >It's not clear to me why we are trying to inform the peer as whether >the current EAP session is for service vs. for access. Looking at >the newly emerged EAP-GPSK, all the peer needs to know is the ID it >gave the server and the server ID, in order to pull out the correct >security association to carry out EAP-GPSK. It can be informed >whether access or service was granted *after* this is all done, by >some other means that have nothing to do with EAP. > >In the network that we have deployed, and in others that we hope to >deploy some day, multiple EAP sessions do come into play but the >overall authentication mechanism can be made to work in a fairly >simple fashion without any additional EAP-related mechanisms/layers. > >Michaela > >Nakhjiri Madjid-MNAKHJI1 wrote: > > >-----Original Message----- >From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] >Sent: Monday, June 12, 2006 11:58 PM >To: Quinn Li; Cao Zhen >Cc: eap@frascone.com >Subject: Re: [eap] Questions for draft-barany-eap-gee-01 > >Hi, > >GEE is not a general purpose authentication protocol. It is a >generic EAP encapsulation mechanism that allows demultiplexing of >multiple simultaneous EAP conversations between a peer and an >authenticator. You say that the draft does describe the MVNO >scenarios well, so I guess we can safely conclude that it does its job >then. > >EAP is not used for IMS or Mobile IPv6 authentication, is it? So, in >simple terms, it's not the purpose of the GEE draft to specify >support for those services. > >Madjid>>EAP is being used for non-cellular access into IMS. >EAP is being considered for MIP6 bootstrapping. >If the idea is to standardize the usage, then it should not be >customized for a specific use case. > >_________________________________________________________________ >To unsubscribe or modify your subscription options, please visit: >http://lists.frascone.com/mailman/listinfo/eap > >Arhives: http://lists.frascone.com/pipermail/eap > > > > __________________________________________________ >Do You Yahoo!? >Tired of spam? Yahoo! Mail has the best spam protection around >http://mail.yahoo.com _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Jun 21 12:51:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft5uv-0000bt-Oh for eap-archive@lists.ietf.org; Wed, 21 Jun 2006 12:51:01 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft5gn-0006eW-48 for eap-archive@lists.ietf.org; Wed, 21 Jun 2006 12:36:27 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id B0C464301E0 for ; Wed, 21 Jun 2006 09:36:21 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 9578A43013F for ; Wed, 21 Jun 2006 09:36:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 88DD5398056 for ; Wed, 21 Jun 2006 09:36:03 -0700 (PDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5E31E39804D for ; Wed, 21 Jun 2006 09:35:58 -0700 (PDT) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LGZuRL024682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Jun 2006 09:35:57 -0700 Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.20]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LGZsxu001937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Jun 2006 09:35:55 -0700 (PDT) Message-Id: <7.0.1.0.2.20060621093145.04566f70@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 21 Jun 2006 09:35:54 -0700 To: "Nakhjiri Madjid-MNAKHJI1" , "M. Vanderveen" , "Quinn Li" , "Cao Zhen" From: Lakshminath Dondeti In-Reply-To: References: <7.0.1.0.2.20060620203852.05ff48b0@qualcomm.com> Mime-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com Subject: Re: [eap] Questions for draft-barany-eap-gee-01 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 I still don't understand how what you write below is relevant to the discussion at hand, but anyway, I think I made my point. I will note that the word "service" seems to throw people off into debates on authentication vs. authorization and that may be what's happening here. If it helps, perhaps the use of the terms L2 access and L3 access might be better. Further, multiple parallel authentications could also be for device and user authentications as Kuntal points out. Other use cases are also possible. regards, Lakshminath At 09:00 AM 6/21/2006, Nakhjiri Madjid-MNAKHJI1 wrote: >Inclusion of information regarding access versus service is an >authorization act. > >Madjid > >-----Original Message----- >From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] >Sent: Tuesday, June 20, 2006 10:41 PM >To: Nakhjiri Madjid-MNAKHJI1; M. Vanderveen; Quinn Li; Cao Zhen >Cc: eap@frascone.com >Subject: RE: [eap] Questions for draft-barany-eap-gee-01 > >At 11:58 AM 6/20/2006, Nakhjiri Madjid-MNAKHJI1 wrote: > >I agree, it seems that AAA functions that are typically done after > >authentication are introduced into EAP messaging, while EAP is just > >a protocol to carry authentication exchanges. EAP is an > >"authentication" protocol, not a AAA protocol. > >I am confused here. I see no reference to AAA, especially the AAA >protocol, in the emails below. What are you referring to? > >Lakshminath > > > > >Madjid > > > > > > > >---------- > >From: M. Vanderveen [mailto:mvandervn@yahoo.com] > >Sent: Tuesday, June 20, 2006 1:51 PM > >To: Nakhjiri Madjid-MNAKHJI1; Lakshminath Dondeti; Quinn Li; Cao Zhen > >Cc: eap@frascone.com > >Subject: Re: [eap] Questions for draft-barany-eap-gee-01 > > > >While a solution for demultiplexing several EAP sessions might be > >helpful, part of the resistance to the introduction of this sublayer > >is probably due to the fact that there are ways around this issue. > > > >It's not clear to me why we are trying to inform the peer as whether > >the current EAP session is for service vs. for access. Looking at > >the newly emerged EAP-GPSK, all the peer needs to know is the ID it > >gave the server and the server ID, in order to pull out the correct > >security association to carry out EAP-GPSK. It can be informed > >whether access or service was granted *after* this is all done, by > >some other means that have nothing to do with EAP. > > > >In the network that we have deployed, and in others that we hope to > >deploy some day, multiple EAP sessions do come into play but the > >overall authentication mechanism can be made to work in a fairly > >simple fashion without any additional EAP-related mechanisms/layers. > > > >Michaela > > > >Nakhjiri Madjid-MNAKHJI1 wrote: > > > > > >-----Original Message----- > >From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] > >Sent: Monday, June 12, 2006 11:58 PM > >To: Quinn Li; Cao Zhen > >Cc: eap@frascone.com > >Subject: Re: [eap] Questions for draft-barany-eap-gee-01 > > > >Hi, > > > >GEE is not a general purpose authentication protocol. It is a > >generic EAP encapsulation mechanism that allows demultiplexing of > >multiple simultaneous EAP conversations between a peer and an > >authenticator. You say that the draft does describe the MVNO > >scenarios well, so I guess we can safely conclude that it does its job > >then. > > > >EAP is not used for IMS or Mobile IPv6 authentication, is it? So, in > >simple terms, it's not the purpose of the GEE draft to specify > >support for those services. > > > >Madjid>>EAP is being used for non-cellular access into IMS. > >EAP is being considered for MIP6 bootstrapping. > >If the idea is to standardize the usage, then it should not be > >customized for a specific use case. > > > >_________________________________________________________________ > >To unsubscribe or modify your subscription options, please visit: > >http://lists.frascone.com/mailman/listinfo/eap > > > >Arhives: http://lists.frascone.com/pipermail/eap > > > > > > > > __________________________________________________ > >Do You Yahoo!? > >Tired of spam? Yahoo! Mail has the best spam protection around > >http://mail.yahoo.com _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Jun 21 15:10:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft85n-00071r-W2 for eap-archive@lists.ietf.org; Wed, 21 Jun 2006 15:10:24 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft85m-00072G-5L for eap-archive@lists.ietf.org; Wed, 21 Jun 2006 15:10:23 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id DAE0E430135 for ; Wed, 21 Jun 2006 12:10:20 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 22F4F430093 for ; Wed, 21 Jun 2006 12:09:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0B8AC39801C for ; Wed, 21 Jun 2006 12:09:56 -0700 (PDT) Received: from web54409.mail.yahoo.com (web54409.mail.yahoo.com [206.190.49.139]) by zoidberg.tigertech.net (Postfix) with SMTP id 06C36398037 for ; Wed, 21 Jun 2006 12:09:51 -0700 (PDT) Received: (qmail 78479 invoked by uid 60001); 21 Jun 2006 18:47:11 -0000 Message-ID: <20060621184711.78477.qmail@web54409.mail.yahoo.com> Received: from [67.181.83.189] by web54409.mail.yahoo.com via HTTP; Wed, 21 Jun 2006 11:47:11 PDT Date: Wed, 21 Jun 2006 11:47:11 -0700 (PDT) From: "M. Vanderveen" To: Lakshminath Dondeti In-Reply-To: <7.0.1.0.2.20060620130757.061de238@qualcomm.com> MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.162 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_WHOIS, HTML_10_20, HTML_MESSAGE X-Spam-Level: * Cc: eap@frascone.com Subject: Re: [eap] Questions for draft-barany-eap-gee-01 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0053085842==" Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.3 (/) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 --===============0053085842== Content-Type: multipart/alternative; boundary="0-454909296-1150915631=:75228" Content-Transfer-Encoding: 7bit --0-454909296-1150915631=:75228 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Lakshminath, While the need for multiple EAP sessions is clear, the use case for par= allel EAP sessions is not. As I understand it, the scenario where you hav= e MVNOs, and where the terminal/user has two separate SAs with the local = MVNO and the home network, and where the access network lets the terminal= talk to the home network BEFORE the access network has authenticated the= terminal, and saving time on this (initial) authentication is desirable = --- can benefit from the EAP-GEE encapsulation. I agree with this. Any ot= her use cases you have in mind - please share if possible. =20 As an aside, in the MVNO scenario it is a little strange that the EAP s= essions are not sequential. Seemed to make more sense to let the access n= etwork complete authentication of the terminal before allowing conversati= ons with the home network.=20 =20 Also, one question that perhaps you could shed some light on - why shou= ld the mobile try to save time (not clear how much time) in this network = access phase? - it would be understandable in the handoff scenario, but n= ot necessarily on power-up. So, is this EAP encapsulation beneficial in M= VNO handoff scenarios? I was thinking that access with the home network i= s only done every so often, whereby access to a different AP in the MVNO = network should be done upon every handoff. =20 =20 More inline. Michaela =20 Lakshminath Dondeti wrote: Michaela, It looks like you are confusing several things here. Please see=20 inline some clarifications. At 11:51 AM 6/20/2006, M. Vanderveen wrote: >While a solution for demultiplexing several EAP sessions might be=20 >helpful, part of the resistance to the introduction of this sublayer=20 >is probably due to the fact that there are ways around this issue. There is a need for parallel EAP authentications; that has been=20 clearly expressed by some operators. EAP (RFC 3748 and its ilk) does=20 not have support for multiple parallel authentications. We can=20 either do what Alper says and provide support in every lower layer,=20 or do it in a lower layer agnostic fashion. This is a new feature=20 (not supported in any lower layer) and so doing it at the EAP level=20 would be a universal solution and makes perfect sense. =20 MCV>>I don't disagree that there is a need for multiple EAP sessions - = the above message just says that there are other ways of achieving this. > >It's not clear to me why we are trying to inform the peer as whether=20 >the current EAP session is for service vs. for access. Looking at=20 >the newly emerged EAP-GPSK, all the peer needs to know is the ID it=20 >gave the server and the server ID, in order to pull out the correct=20 >security association to carry out EAP-GPSK. It can be informed=20 >whether access or service was granted *after* this is all done, by=20 >some other means that have nothing to do with EAP. GEE has little to do with methods, period. I am not sure which part=20 of the I-D gave you that impression. Could you please point any=20 sections that led you to this confusion? We would like to fix it. MCV>> There is no confusion. The draft is clear in its proposal of an e= ncapsulation for EAP packets. I'm just saying that the peer can tell by t= he ID it used (a MAC address vs. a NAI, for example), what kind of authen= tication this is. However if you want to be able to interleave packets fr= om multiple EAP methods, and you are not willing to rely on any Session I= D or some other EAP-method-specific identifier, then an elegant solution = would be to encapsulate it, as in EAP-GEE > >In the network that we have deployed, and in others that we hope to=20 >deploy some day, multiple EAP sessions do come into play but the=20 >overall authentication mechanism can be made to work in a fairly=20 >simple fashion without any additional EAP-related mechanisms/layers. As I note above, the multiple parallel authentications use case came=20 from operators. Next, I am concerned about your phrase "can be made=20 to work"; if you mean proprietary hacks by that, that's not really=20 desirable, is it? =20 MCV>> There is no hack in allowing sequential EAP methods.=20 best regards, Lakshminath > >Michaela > >Nakhjiri Madjid-MNAKHJI1 wrote: > >-----Original Message----- >From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] >Sent: Monday, June 12, 2006 11:58 PM >To: Quinn Li; Cao Zhen >Cc: eap@frascone.com >Subject: Re: [eap] Questions for draft-barany-eap-gee-01 >Hi, >GEE is not a general purpose authentication protocol. It is a >generic EAP encapsulation mechanism that allows demultiplexing of >multiple simultaneous EAP conversations between a peer and an >authenticator. You say that the draft does describe the MVNO >scenarios well, so I guess we can safely conclude that it does its job >then. >EAP is not used for IMS or Mobile IPv6 authentication, is it? So, in >simple terms, it's not the purpose of the GEE draft to specify >support for those services. >Madjid>>EAP is being used for non-cellular access into IMS. >EAP is being considered for MIP6 bootstrapping. >If the idea is to standardize the usage, then it should not be >customized for a specific use case. >_________________________________________________________________ >To unsubscribe or modify your subscription options, please visit: >http://lists.frascone.com/mailman/listinfo/eap >Arhives: http://lists.frascone.com/pipermail/eap > > >__________________________________________________ >Do You Yahoo!? >Tired of spam? Yahoo! Mail has the best spam protection around >http://mail.yahoo.com =09 --------------------------------- Yahoo! Messenger with Voice. PC-to-Phone calls for ridiculously low rates= . --0-454909296-1150915631=:75228 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Lakshminath,
While the need for multiple EAP session= s is clear, the use case for parallel EAP sessions is not. As I understan= d it, the scenario where you have MVNOs, and where the terminal/user has = two separate SAs with the local MVNO and the home network, and where the = access network lets the terminal talk to the home network BEFORE the acce= ss network has authenticated the terminal, and saving time on this (initi= al) authentication is desirable --- can benefit from the EAP-GEE encapsul= ation. I agree with this. Any other use cases you have in mind - please s= hare if possible.
 
As an aside, in the MVNO= scenario it is a little strange that the EAP sessions are not sequential= . Seemed to make more sense to let the access network complete authentica= tion of the terminal before allowing conversations with the home network.=
 
Also, one question that perhaps you coul= d shed some light on - why should the mobile try to save time (not clear how much time) in this network access= phase? - it would be understandable in the handoff scenario, but not nec= essarily on power-up. So, is this EAP encapsulation beneficial in MVNO ha= ndoff scenarios? I was thinking that access with the home network is only= done every so often, whereby access to a different AP in the MVNO networ= k should be done upon every handoff.
 
 = ;
More inline.
Michaela

Lak= shminath Dondeti <ldondeti@qualcomm.com> wrote:
Michaela,

It looks like you are= confusing several things here. Please see
inline some clarifications= .

At 11:51 AM 6/20/2006, M. Vanderveen wrote:
>While a solut= ion for demultiplexing several EAP sessions might be
>helpful, par= t of the resistance to the introduction of this sublayer
>is probably due to the fact that there are ways ar= ound this issue.

There is a need for parallel EAP authentications;= that has been
clearly expressed by some operators. EAP (RFC 3748 and= its ilk) does
not have support for multiple parallel authentications= . We can
either do what Alper says and provide support in every lower= layer,
or do it in a lower layer agnostic fashion. This is a new fea= ture
(not supported in any lower layer) and so doing it at the EAP le= vel
would be a universal solution and makes perfect sense.
 
From: Nakhjiri Madjid-MNAKHJI1=20 [mailto:Madjid.Nakhjiri@motorola.com]
Sent: Tuesday, June = 20, 2006=20 11:58 AM
To: M. Vanderveen; Dondeti, Lakshminath; Quinn Li; = Cao=20 Zhen
Cc: eap@frascone.com
Subject: Re: [eap] = Questions for=20 draft-barany-eap-gee-01

I agree, it = seems=20 that AAA functions that are typically done after authentication are = introduced=20 into EAP messaging, while EAP is just a protocol to carry = authentication=20 exchanges. EAP is an “authentication” protocol, not a AAA=20 protocol.

 

Madjid

 

 

From: M.=20 Vanderveen [mailto:mvandervn@yahoo.com]
Sent: Tuesday, June 20, 2006 = 1:51=20 PM
To: Nakhjiri=20 Madjid-MNAKHJI1; Lakshminath Dondeti; Quinn Li; Cao Zhen
Cc: = eap@frascone.com
Subject: Re: [eap] Questions = for=20 draft-barany-eap-gee-01

 

While a solution for demultiplexing several = EAP=20 sessions might be helpful, part of the resistance to the introduction = of this=20 sublayer is probably due to the fact that there are ways around this=20 issue. 

 

It's not clear to me why we are trying to = inform the=20 peer as whether the current EAP session is for service vs. for access. = Looking=20 at the newly emerged EAP-GPSK, all the peer needs to know is the ID it = gave=20 the server and the server ID, in order to pull out the correct = security=20 association to carry out EAP-GPSK. It can be informed whether access = or=20 service was granted *after* this is all done, by some other means that = have=20 nothing to do with EAP.

 

In the network that we have deployed, and in = others=20 that we hope to deploy some day, multiple EAP sessions do come into = play but=20 the overall authentication mechanism can be made to work in a fairly = simple=20 fashion without any additional EAP-related mechanisms/layers.=20

 

Michaela

Nakhjiri = Madjid-MNAKHJI1=20 <Madjid.Nakhjiri@motorola.com>=20 wrote:



-----Original = Message-----
From:=20 Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]
Sent: Monday, = June=20 12, 2006 11:58 PM
To: Quinn Li; Cao Zhen
Cc:=20 eap@frascone.com
Subject: Re: [eap] Questions for=20 draft-barany-eap-gee-01

Hi,

GEE is not a general = purpose=20 authentication protocol. It is a
generic EAP encapsulation = mechanism=20 that allows demultiplexing of
multiple simultaneous EAP = conversations=20 between a peer and an
authenticator. You say that the draft does = describe the MVNO
scenarios well, so I guess we can safely = conclude that=20 it does its job
then.

EAP is not used for IMS or Mobile = IPv6=20 authentication, is it? So, in
simple terms, it's not the purpose = of the=20 GEE draft to specify
support for those=20 services.

Madjid>>EAP is being used for non-cellular = access=20 into IMS.
EAP is being considered for MIP6 bootstrapping.
If = the idea=20 is to standardize the usage, then it should not be
customized for = a=20 specific use=20 = case.

____________________________________________________________= _____
To=20 unsubscribe or modify your subscription options, please=20 = visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: = = http://lists.frascone.com/pipermail/eap

 

 __________________________________________________
Do=20 You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection = around=20
http://mail.yahoo.com=20

MCV>>I don't disagree that there is a need for= multiple EAP sessions - the above message just says that there are other= ways of achieving this.

>
>It's not clear to me why we a= re trying to inform the peer as whether
>the current EAP session i= s for service vs. for access. Looking at
>the newly emerged EAP-GP= SK, all the peer needs to know is the ID it
>gave the server and the server ID, in order to pull out th= e correct
>security association to carry out EAP-GPSK. It can be i= nformed
>whether access or service was granted *after* this is all= done, by
>some other means that have nothing to do with EAP.
<= BR>GEE has little to do with methods, period. I am not sure which part of the I-D gave you that impression. Could you please point any
sec= tions that led you to this confusion? We would like to fix it.
MCV>> There is no confusion. The draft is clear in its proposal o= f an encapsulation for EAP packets. I'm just saying that the peer can tel= l by the ID it used (a MAC address vs. a NAI, for example), what kind of = authentication this is. However if you want to be able to interleave pack= ets from multiple EAP methods, and you are not willing to rely on any Ses= sion ID or some other EAP-method-specific identifier, then an elegant sol= ution would be to encapsulate it, as in EAP-GEE

>
>In the network that we have deployed, and in = others that we hope to
>deploy some day, multiple EAP sessions do = come into play but the
>overall authentication mechanism can be ma= de to work in a fairly
>simple fashion without any additional EAP-= related mechanisms/layers.

As I note above, the multiple parallel = authentications use case came
from operators. Next, I am concerned ab= out your phrase "can be made
to work"; if you mean proprietary hacks = by that, that's not really
desirable, is it?
 
=
MCV>> There is no hack in allowing sequential EAP methods. <= BR>
best regards,
Lakshminath

>
>Michaela
>>Nakhjiri Madjid-MNAKHJI1 wrote:
&g= t;
>-----Original Message-----
>From: Lakshminath Dondeti [ma= ilto:ldondeti@qualcomm.com]
>Sent: Monday, June 12, 2006 11:58 PM>To: Quinn Li; Cao Zhen
>Cc: eap@frascone.com
>Subject: Re: [eap] Questions for draft-barany-ea= p-gee-01
>Hi,
>GEE is not a general purpose authentication pr= otocol. It is a
>generic EAP encapsulation mechanism that allows de= multiplexing of
>multiple simultaneous EAP conversations between a = peer and an
>authenticator. You say that the draft does describe th= e MVNO
>scenarios well, so I guess we can safely conclude that it d= oes its job
>then.
>EAP is not used for IMS or Mobile IPv6 au= thentication, is it? So, in
>simple terms, it's not the purpose of = the GEE draft to specify
>support for those services.
>Madjid= >>EAP is being used for non-cellular access into IMS.
>EAP is= being considered for MIP6 bootstrapping.
>If the idea is to standa= rdize the usage, then it should not be
>customized for a specific u= se case.
>_________________________________________________________= ________
>To unsubscribe or modify your subscription options, please visit:
>http://lists.fras= cone.com/mailman/listinfo/eap
>Arhives: http://lists.frascone.com/p= ipermail/eap
>
>
>_____________________________________= _____________
>Do You Yahoo!?
>Tired of spam? Yahoo! Mail has= the best spam protection around
>http://mail.yahoo.com


Yahoo!= Messenger with Voice. PC-to-Phone calls for ridiculously low rates. --0-454909296-1150915631=:75228-- --===============0053085842== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap --===============0053085842==-- From ReedBryange@cheerful.com Wed Jun 21 17:48:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtASl-0003L5-Rb for eap-archive@ietf.org; Wed, 21 Jun 2006 17:42:15 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtAE1-0007Vk-Lb; Wed, 21 Jun 2006 17:27:01 -0400 Received: from adsl-114-42-192-81.adsl.iam.net.ma ([81.192.42.114] helo=POSTE6.potz99.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FtADz-0006VW-Tk; Wed, 21 Jun 2006 17:27:01 -0400 Message-ID: <50167709267815.CE4FCA2E0B@LOSZ> From: "Marietta" To: Subject: Recent stuff Get a better job Date: Wed, 21 Jun 2006 23:25:58 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: 7yd3WObiRzEgsjJ1hlbvrTjTDSwcnQhicZYQ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: -0.5 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Obtain a diploma in 2 weeks Academic Qualifications available from prestigious NON-ACC REDITED uni versities. Do you have the k nowledge and the experie nce but lack the qualifications? Are y ou getting turned down time and time again for the job of your dreams becau se you just don't have the right let ters after your name? Get the prestige that you deserve today! Move ahead in your career today! Bache lors, Ma sters and P hD's avail able in your field! No examinations! No classes! No textbooks! Call to register and receive your qual ifications within days! 24 hours a day 7 days a week! Confidentiality assured! Please call: 1-206- 600-6825 Calls returned promptly Keep your mouth shut and your ears open. Don't count your chickens before they're hatched . Children should be seen and not.. spanked or grounded. There are none so blind as those that will not see I was almost in all evil in the midst of the congregation and assembly. Go to heaven for the climate and hell for the company From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Jun 21 18:16:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtB0E-0000pX-9T for eap-archive@lists.ietf.org; Wed, 21 Jun 2006 18:16:50 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtB0C-0003py-Sg for eap-archive@lists.ietf.org; Wed, 21 Jun 2006 18:16:50 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 384844301F4 for ; Wed, 21 Jun 2006 15:16:48 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id E446F430054 for ; Wed, 21 Jun 2006 15:16:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id BF49A398017 for ; Wed, 21 Jun 2006 15:16:22 -0700 (PDT) Received: from hotmail.com (bay106-f22.bay106.hotmail.com [65.54.161.32]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5D658398015 for ; Wed, 21 Jun 2006 15:16:19 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 21 Jun 2006 15:16:19 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Wed, 21 Jun 2006 22:16:14 GMT X-Originating-IP: [71.37.13.64] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Wed, 21 Jun 2006 15:16:14 -0700 Mime-Version: 1.0 X-OriginalArrivalTime: 21 Jun 2006 22:16:19.0180 (UTC) FILETIME=[521072C0:01C69580] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.748 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Subject: Re: [eap] Proposed Resolution to Issue 357: Channel Binding Defintiion X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Yoshi Ohba said: How about: "It is expected that the parameters are also agreed upon by the peer and authenticator via the lower layer if the authenticator is the valid entity that advertised the parameters." Question: What does "valid" mean here? Do we mean "securely agreed upon"? How about this: "A secure mechanism for ensuring that a subset of the parameters transmitted by the authenticator (such as authenticator identifiers and properties) are agreed upon by the EAP peer and server. It is expected that the parameters are also securel agreed upon by the EAP peer and authenticator via the lower layer if the authenticator advertised the parameters." _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Jun 21 19:28:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtC7V-0002Aa-VB for eap-archive@lists.ietf.org; Wed, 21 Jun 2006 19:28:25 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtC7U-0007FA-F9 for eap-archive@lists.ietf.org; Wed, 21 Jun 2006 19:28:25 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 85D1743017B for ; Wed, 21 Jun 2006 16:28:23 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id F39F54300AE for ; Wed, 21 Jun 2006 16:28:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id DB67B398037 for ; Wed, 21 Jun 2006 16:28:05 -0700 (PDT) Received: from vbn.inter-touch.net (hilt-sgc-sg-1.inter-touch.net [203.125.175.2]) by zoidberg.tigertech.net (Postfix) with ESMTP id 02450398017 for ; Wed, 21 Jun 2006 16:28:01 -0700 (PDT) Received: from steelhead (unknown [203.125.175.40]) by vbn.inter-touch.net (Postfix) with ESMTP id 31024400313 for ; Thu, 22 Jun 2006 07:27:53 +0800 (SGT) Received: from ohba by steelhead with local (Exim 4.62) (envelope-from ) id 1FtC6n-0004wc-CG; Wed, 21 Jun 2006 16:27:41 -0700 Date: Wed, 21 Jun 2006 19:27:41 -0400 To: Bernard Aboba Message-ID: <20060621232741.GA18682@steelhead> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11+cvs20060403 From: Yoshihiro Ohba X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: eap@frascone.com Subject: Re: [eap] Proposed Resolution to Issue 357: Channel Binding Defintiion X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb On Wed, Jun 21, 2006 at 03:16:14PM -0700, Bernard Aboba wrote: > Yoshi Ohba said: > > How about: > > "It is expected that the parameters are also agreed upon by the peer > and authenticator via the lower layer if the authenticator is the > valid entity that advertised the parameters." > > Question: What does "valid" mean here? Do we mean "securely agreed upon"? > > How about this: > > "A secure mechanism for ensuring that a subset of the parameters transmitted > by the > authenticator (such as authenticator identifiers and properties) are agreed > upon by > the EAP peer and server. It is expected that the parameters are also > securel agreed > upon by the EAP peer and authenticator via the lower layer if the > authenticator > advertised the parameters." The text works for me. (s/securel/securely/) Thank you, Yoshihiro Ohba > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap > > Arhives: http://lists.frascone.com/pipermail/eap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Jun 21 19:46:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtCP7-0002KK-1N for eap-archive@lists.ietf.org; Wed, 21 Jun 2006 19:46:37 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtCP5-00084V-Gg for eap-archive@lists.ietf.org; Wed, 21 Jun 2006 19:46:37 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 215D34300B0 for ; Wed, 21 Jun 2006 16:46:35 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 7C8EF430054 for ; Wed, 21 Jun 2006 16:46:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6B97939804D for ; Wed, 21 Jun 2006 16:46:18 -0700 (PDT) Received: from motgate2.mot.com (motgate2.mot.com [144.189.100.101]) by zoidberg.tigertech.net (Postfix) with ESMTP id 33525398008 for ; Wed, 21 Jun 2006 16:46:15 -0700 (PDT) Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id k5LNkEMt025206 for ; Wed, 21 Jun 2006 16:46:14 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id k5LNkDcw008799 for ; Wed, 21 Jun 2006 18:46:14 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 21 Jun 2006 19:44:13 -0400 Message-ID: In-Reply-To: <7.0.1.0.2.20060621093145.04566f70@qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Questions for draft-barany-eap-gee-01 Thread-Index: AcaVUNGU2ZHhQLP2QqiLPdF0HvKC6AAOwvDw From: "Nakhjiri Madjid-MNAKHJI1" To: "Lakshminath Dondeti" , "M. Vanderveen" , "Quinn Li" , "Cao Zhen" X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com Subject: Re: [eap] Questions for draft-barany-eap-gee-01 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d -----Original Message----- From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] Sent: Wednesday, June 21, 2006 11:36 AM To: Nakhjiri Madjid-MNAKHJI1; M. Vanderveen; Quinn Li; Cao Zhen Cc: eap@frascone.com Subject: RE: [eap] Questions for draft-barany-eap-gee-01 I still don't understand how what you write below is relevant to the discussion at hand, but anyway, I think I made my point. Madjid>>Not sure what that means, but I guess that is good for you. I will note that the word "service" seems to throw people off into debates on authentication vs. authorization and that may be what's happening here. Madjid>>yes, If it helps, perhaps the use of the terms L2 access and L3 access might be better. Madjid>>Ok, that is better, but still L3 access is vague: is it getting IP addresses? Setting IP connectivity? And regardless of what it means, multiplexing multiple purposes in one EAP signaling, means you need to include indication for these purposes in the EAP signaling. I don't know how you would do it in a way that does not break existing implementations of EAP? Further, multiple parallel authentications could also be for device and user authentications as Kuntal points out. Other use cases are also possible. Madjid>> There are many cases, if not all cases, where device and user authentication do not happen in parallel but in series as a form of multifactor authentication. regards, Lakshminath At 09:00 AM 6/21/2006, Nakhjiri Madjid-MNAKHJI1 wrote: >Inclusion of information regarding access versus service is an >authorization act. > >Madjid > >-----Original Message----- >From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] >Sent: Tuesday, June 20, 2006 10:41 PM >To: Nakhjiri Madjid-MNAKHJI1; M. Vanderveen; Quinn Li; Cao Zhen >Cc: eap@frascone.com >Subject: RE: [eap] Questions for draft-barany-eap-gee-01 > >At 11:58 AM 6/20/2006, Nakhjiri Madjid-MNAKHJI1 wrote: > >I agree, it seems that AAA functions that are typically done after > >authentication are introduced into EAP messaging, while EAP is just > >a protocol to carry authentication exchanges. EAP is an > >"authentication" protocol, not a AAA protocol. > >I am confused here. I see no reference to AAA, especially the AAA >protocol, in the emails below. What are you referring to? > >Lakshminath > > > > >Madjid > > > > > > > >---------- > >From: M. Vanderveen [mailto:mvandervn@yahoo.com] > >Sent: Tuesday, June 20, 2006 1:51 PM > >To: Nakhjiri Madjid-MNAKHJI1; Lakshminath Dondeti; Quinn Li; Cao Zhen > >Cc: eap@frascone.com > >Subject: Re: [eap] Questions for draft-barany-eap-gee-01 > > > >While a solution for demultiplexing several EAP sessions might be > >helpful, part of the resistance to the introduction of this sublayer > >is probably due to the fact that there are ways around this issue. > > > >It's not clear to me why we are trying to inform the peer as whether > >the current EAP session is for service vs. for access. Looking at > >the newly emerged EAP-GPSK, all the peer needs to know is the ID it > >gave the server and the server ID, in order to pull out the correct > >security association to carry out EAP-GPSK. It can be informed > >whether access or service was granted *after* this is all done, by > >some other means that have nothing to do with EAP. > > > >In the network that we have deployed, and in others that we hope to > >deploy some day, multiple EAP sessions do come into play but the > >overall authentication mechanism can be made to work in a fairly > >simple fashion without any additional EAP-related mechanisms/layers. > > > >Michaela > > > >Nakhjiri Madjid-MNAKHJI1 wrote: > > > > > >-----Original Message----- > >From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] > >Sent: Monday, June 12, 2006 11:58 PM > >To: Quinn Li; Cao Zhen > >Cc: eap@frascone.com > >Subject: Re: [eap] Questions for draft-barany-eap-gee-01 > > > >Hi, > > > >GEE is not a general purpose authentication protocol. It is a > >generic EAP encapsulation mechanism that allows demultiplexing of > >multiple simultaneous EAP conversations between a peer and an > >authenticator. You say that the draft does describe the MVNO > >scenarios well, so I guess we can safely conclude that it does its job > >then. > > > >EAP is not used for IMS or Mobile IPv6 authentication, is it? So, in > >simple terms, it's not the purpose of the GEE draft to specify > >support for those services. > > > >Madjid>>EAP is being used for non-cellular access into IMS. > >EAP is being considered for MIP6 bootstrapping. > >If the idea is to standardize the usage, then it should not be > >customized for a specific use case. > > > >_________________________________________________________________ > >To unsubscribe or modify your subscription options, please visit: > >http://lists.frascone.com/mailman/listinfo/eap > > > >Arhives: http://lists.frascone.com/pipermail/eap > > > > > > > > __________________________________________________ > >Do You Yahoo!? > >Tired of spam? Yahoo! Mail has the best spam protection around > >http://mail.yahoo.com _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Wed Jun 21 21:44:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtEFf-000087-TU for eap-archive@lists.ietf.org; Wed, 21 Jun 2006 21:44:59 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtEFd-0007e9-UW for eap-archive@lists.ietf.org; Wed, 21 Jun 2006 21:44:59 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id AC597430199 for ; Wed, 21 Jun 2006 18:44:56 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 01ED643016F for ; Wed, 21 Jun 2006 18:44:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E2294144801E for ; Wed, 21 Jun 2006 18:44:22 -0700 (PDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by hermes.tigertech.net (Postfix) with ESMTP id 36B2C144800C for ; Wed, 21 Jun 2006 18:44:16 -0700 (PDT) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5M1iFho021475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Jun 2006 18:44:15 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5M1iEuk020612; Wed, 21 Jun 2006 18:44:14 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 18:44:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 21 Jun 2006 18:44:14 -0700 Message-ID: In-Reply-To: <20060621184711.78477.qmail@web54409.mail.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Questions for draft-barany-eap-gee-01 Thread-Index: AcaVZl03C3kQ82bOTH+Ou/vb4qoqfgANKVjQ From: "Narayanan, Vidya" To: "M. Vanderveen" , "Dondeti, Lakshminath" X-OriginalArrivalTime: 22 Jun 2006 01:44:14.0087 (UTC) FILETIME=[5DB03170:01C6959D] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.5 tagged_above=-999.0 required=7.0 tests=HTML_20_30, HTML_MESSAGE X-Spam-Level: Cc: eap@frascone.com Subject: Re: [eap] Questions for draft-barany-eap-gee-01 X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2098305609==" Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.5 (/) X-Scan-Signature: 054490fec19f6a94c68e63428d06db69 This is a multi-part message in MIME format. --===============2098305609== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6959D.5D67CAD8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6959D.5D67CAD8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Michaela, Multiple authentications may occur in the MVNO cases even when switching L3 subnets (both L2 and L3 access authentications would need to be performed there) - so, it is not strictly a power on only scenario. This does have an impact on handoffs as well.=20 =20 Vidya ________________________________ From: M. Vanderveen [mailto:mvandervn@yahoo.com]=20 Sent: Wednesday, June 21, 2006 11:47 AM To: Dondeti, Lakshminath Cc: eap@frascone.com Subject: Re: [eap] Questions for draft-barany-eap-gee-01 =09 =09 Lakshminath, =09 While the need for multiple EAP sessions is clear, the use case for parallel EAP sessions is not. As I understand it, the scenario where you have MVNOs, and where the terminal/user has two separate SAs with the local MVNO and the home network, and where the access network lets the terminal talk to the home network BEFORE the access network has authenticated the terminal, and saving time on this (initial) authentication is desirable --- can benefit from the EAP-GEE encapsulation. I agree with this. Any other use cases you have in mind - please share if possible. =20 As an aside, in the MVNO scenario it is a little strange that the EAP sessions are not sequential. Seemed to make more sense to let the access network complete authentication of the terminal before allowing conversations with the home network.=20 =20 Also, one question that perhaps you could shed some light on - why should the mobile try to save time (not clear how much time) in this network access phase? - it would be understandable in the handoff scenario, but not necessarily on power-up. So, is this EAP encapsulation beneficial in MVNO handoff scenarios? I was thinking that access with the home network is only done every so often, whereby access to a different AP in the MVNO network should be done upon every handoff. =20 =20 More inline. Michaela Lakshminath Dondeti wrote: Michaela, =09 It looks like you are confusing several things here. Please see=20 inline some clarifications. =09 At 11:51 AM 6/20/2006, M. Vanderveen wrote: >While a solution for demultiplexing several EAP sessions might be=20 >helpful, part of the resistance to the introduction of this sublayer=20 >is probably due to the fact that there are ways around this issue. =09 There is a need for parallel EAP authentications; that has been=20 clearly expressed by some operators. EAP (RFC 3748 and its ilk) does=20 not have support for multiple parallel authentications. We can=20 either do what Alper says and provide support in every lower layer,=20 or do it in a lower layer agnostic fashion. This is a new feature=20 (not supported in any lower layer) and so doing it at the EAP level=20 would be a universal solution and makes perfect sense. =20 MCV>>I don't disagree that there is a need for multiple EAP sessions - the above message just says that there are other ways of achieving this. =09 > >It's not clear to me why we are trying to inform the peer as whether=20 >the current EAP session is for service vs. for access. Looking at=20 >the newly emerged EAP-GPSK, all the peer needs to know is the ID it=20 >gave the server and the server ID, in order to pull out the correct=20 >security association to carry out EAP-GPSK. It can be informed=20 >whether access or service was granted *after* this is all done, by=20 >some other means that have nothing to do with EAP. =09 GEE has little to do with methods, period. I am not sure which part=20 of the I-D gave you that impression. Could you please point any=20 sections that led you to this confusion? We would like to fix it. MCV>> There is no confusion. The draft is clear in its proposal of an encapsulation for EAP packets. I'm just saying that the peer can tell by the ID it used (a MAC address vs. a NAI, for example), what kind of authentication this is. However if you want to be able to interleave packets from multiple EAP methods, and you are not willing to rely on any Session ID or some other EAP-method-specific identifier, then an elegant solution would be to encapsulate it, as in EAP-GEE =09 > >In the network that we have deployed, and in others that we hope to=20 >deploy some day, multiple EAP sessions do come into play but the=20 >overall authentication mechanism can be made to work in a fairly=20 >simple fashion without any additional EAP-related mechanisms/layers. =09 As I note above, the multiple parallel authentications use case came=20 from operators. Next, I am concerned about your phrase "can be made=20 to work"; if you mean proprietary hacks by that, that's not really=20 desirable, is it? =20 MCV>> There is no hack in allowing sequential EAP methods.=20 =09 best regards, Lakshminath =09 > >Michaela > >Nakhjiri Madjid-MNAKHJI1 wrote: > >-----Original Message----- >From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] >Sent: Monday, June 12, 2006 11:58 PM >To: Quinn Li; Cao Zhen >Cc: eap@frascone.com >Subject: Re: [eap] Questions for draft-barany-eap-gee-01 >Hi, >GEE is not a general purpose authentication protocol. It is a >generic EAP encapsulation mechanism that allows demultiplexing of >multiple simultaneous EAP conversations between a peer and an >authenticator. You say that the draft does describe the MVNO >scenarios well, so I guess we can safely conclude that it does its job >then. >EAP is not used for IMS or Mobile IPv6 authentication, is it? So, in >simple terms, it's not the purpose of the GEE draft to specify >support for those services. >Madjid>>EAP is being used for non-cellular access into IMS. >EAP is being considered for MIP6 bootstrapping. >If the idea is to standardize the usage, then it should not be >customized for a specific use case. =09 >_________________________________________________________________ >To unsubscribe or modify your subscription options, please visit: >http://lists.frascone.com/mailman/listinfo/eap >Arhives: http://lists.frascone.com/pipermail/eap > > >__________________________________________________ >Do You Yahoo!? >Tired of spam? Yahoo! Mail has the best spam protection around >http://mail.yahoo.com =09 =09 =09 ________________________________ Yahoo! Messenger with Voice. PC-to-Phone calls for ridiculously low rates. ------_=_NextPart_001_01C6959D.5D67CAD8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Michaela,
Multiple authentications may occur in the MVNO = cases even=20 when switching L3 subnets (both L2 and L3 access authentications would = need to=20 be performed there) - so, it is not strictly a power on only scenario. = This does=20 have an impact on handoffs as well.
 
Vidya

From: M. Vanderveen=20 [mailto:mvandervn@yahoo.com]
Sent: Wednesday, June 21, 2006 = 11:47=20 AM
To: Dondeti, Lakshminath
Cc:=20 eap@frascone.com
Subject: Re: [eap] Questions for=20 draft-barany-eap-gee-01

Lakshminath,
While the need for multiple EAP sessions is clear, the use case = for=20 parallel EAP sessions is not. As I understand it, the scenario where = you have=20 MVNOs, and where the terminal/user has two separate SAs with the local = MVNO=20 and the home network, and where the access network lets the terminal = talk to=20 the home network BEFORE the access network has authenticated the = terminal, and=20 saving time on this (initial) authentication is desirable --- can = benefit from=20 the EAP-GEE encapsulation. I agree with this. Any other use cases you = have in=20 mind - please share if possible.
 
As an aside, in the MVNO scenario it is a little strange that the = EAP=20 sessions are not sequential. Seemed to make more sense to let the = access=20 network complete authentication of the terminal before allowing = conversations=20 with the home network.
 
Also, one question that perhaps you could shed some light on - = why should=20 the mobile try to save time (not clear how much time) in this network = access=20 phase? - it would be understandable in the handoff scenario, but not=20 necessarily on power-up. So, is this EAP encapsulation beneficial in = MVNO=20 handoff scenarios? I was thinking that access with the home network is = only=20 done every so often, whereby access to a different AP in the MVNO = network=20 should be done upon every handoff.
 
 
More inline.
Michaela

Lakshminath Dondeti = <ldondeti@qualcomm.com>=20 wrote:
Michaela,

It looks like you are confusing several things = here.=20 Please see
inline some clarifications.

At 11:51 AM = 6/20/2006, M.=20 Vanderveen wrote:
>While a solution for demultiplexing several = EAP=20 sessions might be
>helpful, part of the resistance to the=20 introduction of this sublayer
>is probably due to the fact = that there=20 are ways around this issue.

There is a need for parallel EAP=20 authentications; that has been
clearly expressed by some = operators. EAP=20 (RFC 3748 and its ilk) does
not have support for multiple = parallel=20 authentications. We can
either do what Alper says and provide = support in=20 every lower layer,
or do it in a lower layer agnostic fashion. = This is a=20 new feature
(not supported in any lower layer) and so doing it = at the=20 EAP level
would be a universal solution and makes perfect = sense.
 
MCV>>I don't disagree that there is a need for multiple = EAP=20 sessions - the above message just says that there are other ways of=20 achieving this.

>
>It's not clear to me why we are = trying to=20 inform the peer as whether
>the current EAP session is for = service=20 vs. for access. Looking at
>the newly emerged EAP-GPSK, all = the peer=20 needs to know is the ID it
>gave the server and the server = ID, in=20 order to pull out the correct
>security association to carry = out=20 EAP-GPSK. It can be informed
>whether access or service was = granted=20 *after* this is all done, by
>some other means that have = nothing to=20 do with EAP.

GEE has little to do with methods, period. I am = not sure=20 which part
of the I-D gave you that impression. Could you please = point=20 any
sections that led you to this confusion? We would like to = fix=20 it.
MCV>> There is no confusion. The draft is clear in its = proposal=20 of an encapsulation for EAP packets. I'm just saying that the peer = can tell=20 by the ID it used (a MAC address vs. a NAI, for example), what kind = of=20 authentication this is. However if you want to be able to interleave = packets=20 from multiple EAP methods, and you are not willing to rely on any = Session ID=20 or some other EAP-method-specific identifier, then an elegant = solution would=20 be to encapsulate it, as in EAP-GEE

>
>In the = network that=20 we have deployed, and in others that we hope to
>deploy some = day,=20 multiple EAP sessions do come into play but the
>overall=20 authentication mechanism can be made to work in a fairly =
>simple=20 fashion without any additional EAP-related = mechanisms/layers.

As I=20 note above, the multiple parallel authentications use case came =
from=20 operators. Next, I am concerned about your phrase "can be made =
to work";=20 if you mean proprietary hacks by that, that's not really =
desirable, is=20 it?
 
MCV>> There is no hack in allowing sequential EAP = methods.=20

best=20 = regards,
Lakshminath

>
>Michaela
>
>Nakhji= ri=20 Madjid-MNAKHJI1=20 wrote:
>
>-----Original=20 Message-----
>From: Lakshminath Dondeti=20 [mailto:ldondeti@qualcomm.com]
>Sent: Monday, June 12, 2006 = 11:58=20 PM
>To: Quinn Li; Cao Zhen
>Cc: = eap@frascone.com
>Subject:=20 Re: [eap] Questions for = draft-barany-eap-gee-01
>Hi,
>GEE is not=20 a general purpose authentication protocol. It is a
>generic = EAP=20 encapsulation mechanism that allows demultiplexing = of
>multiple=20 simultaneous EAP conversations between a peer and = an
>authenticator.=20 You say that the draft does describe the MVNO
>scenarios well, = so I=20 guess we can safely conclude that it does its = job
>then.
>EAP is=20 not used for IMS or Mobile IPv6 authentication, is it? So, = in
>simple=20 terms, it's not the purpose of the GEE draft to = specify
>support for=20 those services.
>Madjid>>EAP is being used for = non-cellular=20 access into IMS.
>EAP is being considered for MIP6=20 bootstrapping.
>If the idea is to standardize the usage, then = it=20 should not be
>customized for a specific use=20 = case.
>____________________________________________________________= _____
>To=20 unsubscribe or modify your subscription options, please=20 = visit:
>http://lists.frascone.com/mailman/listinfo/eap
>Arhiv= es:=20 = http://lists.frascone.com/pipermail/eap
>
>
>__________= ________________________________________
>Do=20 You Yahoo!?
>Tired of spam? Yahoo! Mail has the best spam = protection=20 around
>http://mail.yahoo.com


Yahoo!=20 Messenger with Voice. PC-to-Phone calls for ridiculously low=20 rates. ------_=_NextPart_001_01C6959D.5D67CAD8-- --===============2098305609== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap --===============2098305609==-- From tkruse@jaguartc.com Thu Jun 22 06:10:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtM9D-0005CB-Du for eap-archive@ietf.org; Thu, 22 Jun 2006 06:10:51 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtM9D-0001NC-CO for eap-archive@ietf.org; Thu, 22 Jun 2006 06:10:51 -0400 Received: from 61-230-126-6.dynamic.hinet.net ([61.230.126.6] helo=user) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FtM9C-0001hZ-DO for eap-archive@ietf.org; Thu, 22 Jun 2006 06:10:51 -0400 Message-ID: <73363051.20060622171018@jaguartc.com> Date: Thu, 22 Jun 2006 17:10:18 0000 From: "Andrea Elkins" Reply-To: "Andrea Elkins" To: eap-archive@ietf.org Subject: RE: Financial Market Trader Picks MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 1.0 (+) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d This weeks pick. BIG NEW S EXPECT ED FRIDAY! We Expect this to really move. CTXE - CA NTEX ENERGY CORP Big News Just Out! PRICE: 0.42 5 Day exp ected .97 Cantex Energy Corp. Corporate Update Cante x Ener gy Corp. Announces Appointment of Two New Directors SAN ANTONIO--(BUSINESS WIRE)--June 14, 2006--Cantex Energy Corp. (Pink Sheets:CTXE - News) is pleased to announce that Dr. Tom Morgan and Mr. James C. (Jim) Mannatt Jr. have joined the Board of Directors effective immediately. Dr. Morgan is Consulting Geophysicist with Providence Technologies and the Big Canyon 2D Swath. Mr. Mannatt is the well-published owner of Providence Technologies Inc., the technology Company that has licensed its unique and proven technology to Cantex and its working interest partners on the Big Canyon Prospect. The Company is also pleased to report that the first of three lines has now been completed and data is being processed. The second line is underway and the entire project continues to be ahead of schedule. Trace Maurin, President of Cantex Energy Corp., stated, "We have always believed that our geophysical experts at Providence Technologies have the capability and expertise to provide us the necessary advantages in proving up the estimated tcf of gas in the Big Canyon prospect. To have the owner of Providence join our board speaks volumes for the future of our shareholders." Other news: As May 31, 2006 was the annual year end, the Company has retained its lawyers to prepare and file, as soon as possible, a Form 10 Registration Statement with the SEC. The year-end financials will be posted on the Company's web site on or before the end of June. About Cantex Energy Cantex Energy Corp. is an independent, managed risk, oil and gas exploration, development, and production company headquartered in San Antonio, Texas. The Company's additional focus is the optimal exploitation and development of approximately 1,200 acres known as the West Ant Hills Prospect located in Niobrara County Wyoming. It's ready to explode! From icaerhinszb@tpnet.pl Thu Jun 22 10:20:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtQ2i-0005GU-Ok for eap-archive@ietf.org; Thu, 22 Jun 2006 10:20:24 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtLGp-0007B9-I7 for eap-archive@ietf.org; Thu, 22 Jun 2006 05:14:39 -0400 Received: from acwz204.neoplus.adsl.tpnet.pl ([83.11.157.204] helo=tpnet.pl) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FtL7O-0000es-Fi for eap-archive@ietf.org; Thu, 22 Jun 2006 05:04:55 -0400 Date: Thu, 22 Jun 2006 11:04:48 +0100 From: "bqmuq bgcgtwhdz" X-Sender: icaerhinszb@tpnet.pl To: , Subject: Emerging growth THURSDAY X-Mailer: Microsoft Outlook, Build 10.0.2627 Message-Id: <3195129470.871802-12520324-4986@tpnet.pl> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 1.4 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Hollywood Intermediate Inc. (SYM : H Y W I) Current Sh Price : $ 0.58 Pull back is the time to buy, this company has reached $ 1.20 DO THE MATH This price will be history coming next week Follow the performance of this company, it is a real gold mine watch this stck go crazy HYWI has performed like clockwork every time CO OverView H o l l y w o o d I n t e r m e d i a t e provides a proprietary technology of Digital Intermediate services to feature filmmakers for post-production for film mastering and restoration. This technology gives the filmmakers total creative control over the look of their productions. Whether shooting on film or acquiring in HD or SD video, H o l l y w o o d I n t e r m e d i a t e puts a powerful cluster of digital tools at the director's disposal to achieve stunning results on the big screen. Matchframe Digital Intermediate, a division of H o l l y w o o d I n t e r m e d i a t e, Inc., packages a full array of post-production services with negative handling expertise and cost-effective 2K digital intermediate and 35mm film out systems. The Digital Intermediate process eliminates current post-production redundancies by creating a single high-resolution master file from which all versions can be made, including all theatrical and High Definition formats. By creating a single master file with resolution higher than the current High Definition broadcast standards, the DI master file enables cinema and television distributors to extract and archive all current and future cinema and television formats including Digital Cinema, Television and High Definition. Red H0t News: H o l l y w o o d I n t e r m e d i a t e a provider of digital intermediate film mastering services, announced today that that its Matchframe Digital Intermediate (MDI) division is completing a digital intermediate for Chad Lowe's directorial debut, "Beautiful Ohio," starring William Hurt and Rita Wilson. READ MORE THIS IS HUGE H o l l y w o o d I n t e r m e d i a t e Expands the Creative Palette for Independent Filmmakers GLENDALE, CA--(MARKET WIRE)--May 31, 2006 -- H o l l y w o o d I n t e r m e d i a t e, Inc. A provider of digital intermediate film mastering services, announced today that its Matchframe Digital Intermediate division is currently providing full digital intermediate services for Super 16MM productions. H o l l y w o o d I n t e r m e d i a t e, Inc. (H_Y_W_I.PK - News), a provider of digital intermediate film mastering services, announced that High Definition preview masters as part of its normal digital intermediate service offerings and workflow. "Typically, in current post-production workflow, HD dailies masters are edited into high quality preview masters including color timing, dirt removal, opticals and visual effects," said David Waters, H o l l y w o o d I n t e r m e d i a t e president. "Unfortunately, none of these processes translate to the theatrical release of the film as they must all be duplicated or repeated in either a higher resolution digital format, or photo chemical process." H o l l y w o o d I n t e r m e d i a t e gives Motion Picture producers the ability to scan their selected original camera negative at 2k or 4k film resolution, conform a high resolution digital master for theatrical and broadcast release including dirt removal, opticals and visual effects, and output a High Definition preview master to be used for preview screenings and focus groups that can be deployed in any worldwide theater location. "The challenge for completing the final editorial decisions on a motion picture are balanced between the ability to display the highest resolution picture for a test audience, and the costs and time in having to re-master your film based on a test audience response," said Jim Delany, H o l l y w o o d I n t e r m e d i a t e COO. DO your Due Diligence and you'll see what we are talking about when it comes to H Y W I ----------------------- A place in the sun. Stop, look and listen. Say it with flowers. Tools of the tr@de. When the cows come home. Rare as walking on water. A weed is no more than a flower in disguise. Where man is not nature is barren. To live from hand to mouth. The sharper is the berry, the sweeter is the wine. Shit end of the stick. That's a real stem winder. Scraping the bottom of the barrel. Walking on water. Put off the scent. You say potayto, I say potahto. Treat him like dirt. Walking on water. You never miss the water till the well runs dry. Stop, look and listen. You feel like a fish out of water. Worked night and day. Rare as walking on water. Rise and shine. The way to a man's heart is through his stomach. The sharper is the berry, the sweeter is the wine. Sour as a green apple. Your barking up the wrong tree. She's a nut. When it rains it pours. Slow as molasses in January. Stuck in a rut. They're like two peas in a pod. Walking on thin ice. Pull it up by the roots. To live from hand to mouth. Wet behind the ears. Raking in the dough. Slow as a snail. Stop, look and listen. Welcome to my garden. Spaceship earth. From crscott@rogerscasey.com Thu Jun 22 15:01:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtUQx-0000Qa-M9 for eap-archive@ietf.org; Thu, 22 Jun 2006 15:01:43 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtP7K-0003R6-2W for eap-archive@ietf.org; Thu, 22 Jun 2006 09:21:06 -0400 Received: from fp142.internetdsl.tpnet.pl ([80.53.41.142]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FtP00-0004Tm-C3 for eap-archive@ietf.org; Thu, 22 Jun 2006 09:13:34 -0400 Date: Thu, 22 Jun 2006 13:13:45 -0060 From: "Marc Farmer" X-Mailer: The Bat! (v2.00.7) Business Reply-To: "Marc Farmer" X-Priority: 3 (Normal) Message-ID: <58472024.20060622131345@rogerscasey.com> To: eap-archive@ietf.org Subject: Daily Special MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 1.2 (+) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Get the Finest Watch Replicas! We carry more brands than any other online source. We only sell premium watches. There's no battery in these replicas just like the real ones since they charge themselves as you move. The second hand moves JUST like the real ones, too. These original watches sell in stores for thousands of dollars. We sell them for much less. - Replicated to the Smallest Detail - 98% Perfectly Accurate Markings - Signature Green Sticker w/ Serial Number on Watch Back - Magnified Quickset Date - Includes all Proper Markings Visit us: lostsellection.com From admiller@1000trails.com Thu Jun 22 21:46:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtakO-000586-6g for eap-archive@ietf.org; Thu, 22 Jun 2006 21:46:12 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtZif-0006oZ-Ox for eap-archive@ietf.org; Thu, 22 Jun 2006 20:40:21 -0400 Received: from [62.93.181.46] (helo=mail.0668.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FtZV7-00040a-2j for eap-archive@ietf.org; Thu, 22 Jun 2006 20:26:25 -0400 Date: Fri, 30 Jun 2006 00:29:20 -0060 From: "Doris Pennington" X-Mailer: The Bat! (v2.00) Business Reply-To: "Doris Pennington" X-Priority: 3 (Normal) Message-ID: <21858503.20060630002920@1000trails.com> To: eap-archive@ietf.org Subject: FWD: St0kkMarrkett Picks Trade Special TopNews MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 3.7 (+++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Get HYWI First Thing Tomorrow, This Is Going To Explode! Check out the HOT NEWS!!! Holly wood Intermediate, Inc. Symbol: H Y W I CURRENT: $.70 GET IT N0W! Already up 0.12 (20.69%) Today Thursday the 22nd Before we start with the profile of HYWI we would like to mention something very important: There is a Big PR Campaign starting on Friday .Iit will run all weekend so it would be best to get in NOW. Holly wood Intermediate Announces Completion of Work on Several Digital Intermediates by Senior Colorist Julius Friede Wednesday June 21, 2:52 pm ET GLENDALE, CA--(MARKET WIRE)--Jun 21, 2006 -- Hollywood Intermediate, Inc. (Other OTC:HYWI.PK - News) a provider of digital intermediate film mastering services announced today that Julius Friede, senior colorist at its Matchframe Digital Intermediate division, has completed work on several digital intermediates in the last three months, including "Journey to the End of the Night," directed by Eric Eason, "The Sensation of Sight," directed by Aaron Wiederspahn and shot by Christophe Lanzenberg, and "Beautiful Ohio," directed by Chad Lowe, and shot by Steve Kazmierski. ADVERTISEMENT While working as Senior Colorist at Cinesite LA, Julius Friede was one of the first colorists to work on digital intermediates, collaborating with Roger Deakins and the Coen Brothers on the pioneering movie, "O Brother, Where Art Thou?" starring George Clooney in 2000. After the movie was completed, Joel Coen while being interviewed by PostIndustry.com stated, "Julius was really instrumental in the whole thing. He was the color timer, the tech engineer who Roger Deakins worked with and he was great." After completing work for Cinesite LA, Friede then moved to Paris where he established digital intermediate capability at clair Lab, working on such films as "The Transporter" and "Kiss of the Dragon," both produced by renowned French filmmaker Luc Besson. Aaron Wiederspahn and Chad Lowe were both first time directors and were excited to work with an experienced colorist who was able to guide them through the process and show them how a digital intermediate could be used to enhance the look of their film. "I enjoy working with young cinematographers and directors because they are so excited by the capabilities of the digital intermediate process," says Friede, adding, "after having worked on almost thirty digital intermediates over the last six years, I am able to help them achieve the look they want in the most efficient manner." Other recent notable projects completed by Friede for Hollywood Intermediate include "Edison," starring Kevin Spacey, Morgan Freeman and Justin Timberlake, and "Marilyn Hotchkiss' Ballroom Dancing and Charm School," which featured an all-star cast including Robert Carlyle, Marisa Tomei, Mary Steenbergen, Sean Astin, Donnie Wahlberg, with Danny DiVito and John Goodman About Hollywood Intermediate Hollywood Intermediate, affords Motion Pictures the ability to scan their selected original camera negative at 2k or 4k film resolution, conforming a high resolution digital master for theatrical and broadcast release including dirt removal, opticals and visual effects, and includes the output of a High Definition preview master (to be used for preview screenings and focus groups and can be deployed in any worldwide theater location) as well as final film, broadcast and DVD distribution. The Digital Intermediate process eliminates current post-production redundancies by creating a single high-resolution master file from which all versions can be made including all theatrical and High Definition formats. By creating a single master file with resolution higher than the current High Definition broadcast standards, the DI master file enables cinema and television distributors to extract and archive all current and future cinema and television formats including Digital Cinema, Television and High Definition. From beracuwitt@itw-nexus.com Fri Jun 23 09:56:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftm8u-0006JD-7M for eap-archive@ietf.org; Fri, 23 Jun 2006 09:56:16 -0400 Received: from [202.105.63.80] (helo=itw-nexus.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ftm8m-0007N6-T6 for eap-archive@ietf.org; Fri, 23 Jun 2006 09:56:16 -0400 Message-ID: <000001c696cc$bb562e80$6f2ba8c0@zay63> Reply-To: "Berach Witt" From: "Berach Witt" To: eap-archive@ietf.org Subject: my iomeo Date: Fri, 23 Jun 2006 06:55:48 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C69692.0EF75680" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.4 (++) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C69692.0EF75680 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 V ] A G R A from 3 , 33 =20 and many other at http://creisavia.com =20 _____ =20 people on the look-out on the banks. They quickly poled and pushed all the barrels together into the shallows, and when they had counted them they roped them together and left them till the morning. Poor dwarves! Bilbo was not so badly off now. He slipped from his barrel and waded ashore, and then sneaked along to some huts that he could see near the waters edge. He no longer thought twice about picking up a supper ------=_NextPart_000_0001_01C69692.0EF75680 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
V ] A G R A from 3 , 33
 
and many other at http://creisavia.com
 
people on the look-out on the banks. = They quickly poled and pushed all
the barrels together into the shallows, and when they had counted = them
they roped them together and left them till the morning. Poor = dwarves!
Bilbo was not so badly off now. He slipped from his barrel and waded
ashore, and then sneaked along to some huts that he could see near = the
waters edge. He no longer thought twice about picking up a = supper
------=_NextPart_000_0001_01C69692.0EF75680-- From TrinaMcwilliamslc@dr.com Fri Jun 23 12:44:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtolJ-0005Ar-KM for eap-archive@ietf.org; Fri, 23 Jun 2006 12:44:05 -0400 Received: from ip-193-19-212-33.static.metro.comel-it.com ([193.19.212.33] helo=E627F85BC4AF439.woeiqu.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtolH-0002CW-E2; Fri, 23 Jun 2006 12:44:05 -0400 Message-ID: <98210633184814.38A3EB60EF@Z7BAZI> From: "Manuela" To: Subject: Just added Get a better job Date: Fri, 23 Jun 2006 18:43:33 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: JlP8U94d22axb2YGkbvgIwj8ZCyaQa6xMAvK Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.4 (++++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Tired of being left behind ? Academic Qualifications available from prestigious NON-ACC REDITED uni versities. Do you h ave the knowledge and the experie nce but lack the qualifications? Are you g etting turned down time and time again for the job of your dr eams because you just don't have the right letters after your nam e? Get the prestige that you d eserve today! Move ahead in your career today! Bachelo rs, Master s and Ph D's available in your field! No examinations! No classes! No textbooks! Call to register and receive your qual ifications within days! 24 hours a day 7 days a week! Confidentiality assured! Please call: 1-215-689 -7379 Calls returned promptly Ill-gotten gains never prosper Exigency is the matriarch of ingenious contrivance. God gives every bird its food, but does not always drop it into the nest Happiness is wanting what you have - not having what you want Modulation in all things. There are none so blind as those that will not see A tidy house holds a bored woman. A hedge between keeps friendship green. Bad news travels fast From eap-bounces+eap-archive=lists.ietf.org@frascone.com Fri Jun 23 16:32:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtsKN-000373-Sm for eap-archive@lists.ietf.org; Fri, 23 Jun 2006 16:32:31 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtsKM-0001tv-Be for eap-archive@lists.ietf.org; Fri, 23 Jun 2006 16:32:31 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id BB2BA430109 for ; Fri, 23 Jun 2006 13:32:29 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 3B01C430058 for ; Fri, 23 Jun 2006 13:32:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 23554398074 for ; Fri, 23 Jun 2006 13:32:16 -0700 (PDT) Received: from hotmail.com (bay106-f25.bay106.hotmail.com [65.54.161.35]) by zoidberg.tigertech.net (Postfix) with ESMTP id AD5A339806A for ; Fri, 23 Jun 2006 13:32:11 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 23 Jun 2006 13:32:11 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Fri, 23 Jun 2006 20:32:10 GMT X-Originating-IP: [71.38.130.70] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Fri, 23 Jun 2006 13:32:10 -0700 Mime-Version: 1.0 X-OriginalArrivalTime: 23 Jun 2006 20:32:11.0134 (UTC) FILETIME=[1AC3C9E0:01C69704] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.748 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Subject: [eap] Issue 370: Key Management X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Issue 370: Key Management Submitter name: Bernard Aboba Submitter email address: aboba [at] internaut.com Date Submitted: June 23, 2006 Reference: Document: KEYING-13 Comment type: 'T'echnical Priority: '1' Should fix Section: 3 Rationale/Explanation of issue: Section 3 does not clearly describe why EAP is not a key management protocol. The proposed resolution is to change Section 3 from: "3. Key Management EAP as defined in [RFC3748] supports key derivation, but does not provide for the management of exported or derived keys. Although EAP methods may support "fast reconnect" as defined in [RFC3748] Section 7.2.1, EAP does not support re-key of exported keys without re- authentication." to: "3. Key Management EAP as defined in [RFC3748] supports key derivation, but does not provide for the management of exported or derived keys. Missing functionality includes: [a] Re-key. EAP does not support re-key of exported keys without re- authentication, although EAP methods may support "fast reconnect" as defined in [RFC3748] Section 7.2.1. [b] Key delete/install semantics. EAP does not synchronize installation or deletion of keying material on the EAP peer and authenticator. [c] Lifetime negotiation. EAP does not support lifetime negotiation for exported keys, and existing EAP methods also do not support key lifetime negotiation. [d] Cryptographic algorithm negotiation. EAP methods only negotiate cryptographic algorithms for their own use, not for the underlying lower layers. [e] Guaranteed TSK freshness. Without a post-EAP handshake, TSKs can be reused if EAP keying material is cached. These deficiencies are typically addressed via a post-EAP handshake known as the Secure Association Protocol." _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From nsoixgrhxol@searle.monsanto.com Sat Jun 24 13:09:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuBdH-0006pc-5n for eap-archive@ietf.org; Sat, 24 Jun 2006 13:09:19 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuBdF-0000gh-3d for eap-archive@ietf.org; Sat, 24 Jun 2006 13:09:17 -0400 Received: from [201.255.154.109] (helo=searle.monsanto.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FuBd8-0007VF-R8 for eap-archive@ietf.org; Sat, 24 Jun 2006 13:09:15 -0400 Received: from 201.255.154.109 by mx7.searle.monsanto.com;Sat, 24 Jun 2006 14:08:47 -0300 Date: Sat, 24 Jun 2006 14:08:47 -0300 From: "gceffhfy ypdpyx" X-Sender: nsoixgrhxol@searle.monsanto.com To: Subject: Your PR man MONDAY X-Mailer: QUALCOMM Windows Eudora Version 5.1 Message-Id: <2335407618.367166-69587171-4613@searle.monsanto.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.6 (--) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Hollywood Intermediate Inc. (SYM : H Y W I) Current Sh Price : $ 0.65 Follow the performance of this company, it is a real gold mine Nothing like it HYWI has performed like clockwork every time CO OverView H o l l y w o o d I n t e r m e d i a t e provides a proprietary technology of Digital Intermediate services to feature filmmakers for post-production for film mastering and restoration. This technology gives the filmmakers total creative control over the look of their productions. Whether shooting on film or acquiring in HD or SD video, H o l l y w o o d I n t e r m e d i a t e puts a powerful cluster of digital tools at the director's disposal to achieve stunning results on the big screen. Matchframe Digital Intermediate, a division of H o l l y w o o d I n t e r m e d i a t e, Inc., packages a full array of post-production services with negative handling expertise and cost-effective 2K digital intermediate and 35mm film out systems. The Digital Intermediate process eliminates current post-production redundancies by creating a single high-resolution master file from which all versions can be made, including all theatrical and High Definition formats. By creating a single master file with resolution higher than the current High Definition broadcast standards, the DI master file enables cinema and television distributors to extract and archive all current and future cinema and television formats including Digital Cinema, Television and High Definition. Red H0t News: H o l l y w o o d I n t e r m e d i a t e a provider of digital intermediate film mastering services, announced today that that its Matchframe Digital Intermediate (MDI) division is completing a digital intermediate for Chad Lowe's directorial debut, "Beautiful Ohio," starring William Hurt and Rita Wilson. READ MORE THIS IS HUGE H o l l y w o o d I n t e r m e d i a t e Expands the Creative Palette for Independent Filmmakers GLENDALE, CA--(MARKET WIRE)--May 31, 2006 -- H o l l y w o o d I n t e r m e d i a t e, Inc. A provider of digital intermediate film mastering services, announced today that its Matchframe Digital Intermediate division is currently providing full digital intermediate services for Super 16MM productions. H o l l y w o o d I n t e r m e d i a t e, Inc. (H_Y_W_I.PK - News), a provider of digital intermediate film mastering services, announced that High Definition preview masters as part of its normal digital intermediate service offerings and workflow. "Typically, in current post-production workflow, HD dailies masters are edited into high quality preview masters including color timing, dirt removal, opticals and visual effects," said David Waters, H o l l y w o o d I n t e r m e d i a t e president. "Unfortunately, none of these processes translate to the theatrical release of the film as they must all be duplicated or repeated in either a higher resolution digital format, or photo chemical process." H o l l y w o o d I n t e r m e d i a t e gives Motion Picture producers the ability to scan their selected original camera negative at 2k or 4k film resolution, conform a high resolution digital master for theatrical and broadcast release including dirt removal, opticals and visual effects, and output a High Definition preview master to be used for preview screenings and focus groups that can be deployed in any worldwide theater location. "The challenge for completing the final editorial decisions on a motion picture are balanced between the ability to display the highest resolution picture for a test audience, and the costs and time in having to re-master your film based on a test audience response," said Jim Delany, H o l l y w o o d I n t e r m e d i a t e COO. DO your Due Diligence and you'll see what we are talking about when it comes to H_Y_W_I ----------------------- Season of mists and mellow fruitfulness. Welcome to my garden. To rule the mountains is to rule the river. When it rains it pours. When it rains it pours. You can't teach an old dog new tricks. You can't teach an old dog new tricks. A rolling stone gathers no moss. Water it down. To live from hand to mouth. Weed 'um and reap. Weed 'um and reap. The shoes on the other foot now. The stronger the breeze the stronger the trees. To gild refined gold, to paint the lily. Weed it out. You throw filth on the living and flowers on the dead.Pin a rose on your nose. You can lead a horse to water but you can't make him drink. Sly as a fox. A weed is no more than a flower in disguise. Still waters run deep. Spring to mind. Sweating blood. What on earth? Water it down. You can't squeeze blood out of a turnip. Worry often gives a small thing a big shadow. Say it with flowers. Plain as water. Up one side and down the other. Your in hot water. She has a green thumb. The scum of the earth. Shake like a leaf. Sick as a dog. She's a nut. Useless as tits on bull. Take time to smell the roses. The shoes on the other foot now. Still waters run deep. From eap-bounces+eap-archive=lists.ietf.org@frascone.com Sat Jun 24 16:05:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuEO0-0003Bx-LC for eap-archive@lists.ietf.org; Sat, 24 Jun 2006 16:05:44 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuENy-0000tc-VK for eap-archive@lists.ietf.org; Sat, 24 Jun 2006 16:05:44 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id ECD80430120 for ; Sat, 24 Jun 2006 13:05:41 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 6722B430064 for ; Sat, 24 Jun 2006 13:05:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 41F43431148 for ; Sat, 24 Jun 2006 13:05:22 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by hermes.tigertech.net (Postfix) with ESMTP id C50EE431129 for ; Sat, 24 Jun 2006 13:05:19 -0700 (PDT) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 44062898B8; Sat, 24 Jun 2006 23:05:17 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id C6A0E898B7; Sat, 24 Jun 2006 23:05:16 +0300 (EEST) Message-ID: <449D8208.7020803@piuha.net> Date: Sat, 24 Jun 2006 21:18:48 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: eap@frascone.com Subject: Re: [eap] Issue 369: Key-Lifetime Parameter removal X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Works for me. --Jari Bernard Aboba wrote: >Issue 369: Key-Lifetime Parameter removal >Submitter name: Bernard Aboba >Submitter email address: aboba@internaut.com >Date Submitted: June 8, 2006 >Reference: >Document: KEYING-13 >Comment type: 'T'echnical >Priority: S >Section: Various >Rationale/Explanation of issue: > >In reviewing the text, it is not clear how useful it is to have EAP methods >export the Key-Lifetime parameter. Today no EAP methods export this >parameter, >and the text in Section 1.4 suggests that this is not very useful anyway: > >Key-Lifetime > >While EAP itself does not support key lifetime negotiation, it is >possible to specify methods that do. However, systems that rely >on such negotiation for exported keys would only function with >these methods. As a result, it is NOT RECOMMENDED to use this >approach as the sole way to determine key lifetimes. > >Similarly, Section 3 states: > >Existing EAP methods do not export the Key-Lifetime >parameter; in the interest of method independence, key management of >exported or derived keys SHOULD NOT be provided within EAP methods. > >As a result, it may make sense to remove discussion of the Key-Lifetime >parameter >from the document. > >The proposed resolution is as follows: > >In Section 1.4, delete: > >" Key-Lifetime > >While EAP itself does not support key lifetime negotiation, it is >possible to specify methods that do. However, systems that rely >on such negotiation for exported keys would only function with >these methods. As a result, it is NOT RECOMMENDED to use this >approach as the sole way to determine key lifetimes." > >Change: > >"EAP methods also MAY export method-specific peer and server >identifiers (Peer-Id and Server-Id), a method-specific EAP >conversation identifier known as the Session-Id, and the lifetime of >the exported keys, known as the Key-Lifetime. " > >To: > >"EAP methods also MAY export method-specific peer and server >identifiers (Peer-Id and Server-Id) and a method-specific EAP >conversation identifier known as the Session-Id. " > >In Section 2, change: > >" On completion of EAP authentication, keying material and material and > parameters exported by the EAP method are provided to the lower layer > and AAA layer (if present). These include the Master Session Key > (MSK), Extended Master Session Key (EMSK), Peer-Id, Server-Id, > Session-Id and Key-Lifetime. The Initialization Vector (IV) is > deprecated." > >To: > >" On completion of EAP authentication, keying material and material and > parameters exported by the EAP method are provided to the lower layer > and AAA layer (if present). These include the Master Session Key > (MSK), Extended Master Session Key (EMSK), Peer-Id, Server-Id, > and Session-Id. The Initialization Vector (IV) is > deprecated." > >Delete the Key-Lifetime parameter from Figure 2. > >In Section 3, delete: > >"Existing EAP methods do not export the Key-Lifetime >parameter; in the interest of method independence, key management of >exported or derived keys SHOULD NOT be provided within EAP methods." > >In Section 3.5, change: > >"System defaults. Where the EAP method does not support the > negotiation of the exported key lifetime, and a key lifetime > negotiation mechanism is not provided by the lower lower, there may > be no way for the peer to learn the exported key lifetime. In this > case it is RECOMMENDED that the peer assume a default value of the > exported key lifetime; 8 hours is recommended. Similarly, the > lifetime of calculated keys can also be managed as a system > parameter on the authenticator." > >To: > >"System defaults. >Where the EAP method does not support the negotiation of >the lifetime of exported keys, and a key lifetime negotiation mechanism is >not provided >by the lower lower, there may be no way for the peer to learn >the lifetime of exported keys. In this case >it is RECOMMENDED that the peer assume a default >value; 8 hours is recommended. >Similarly, the lifetime of calculated keys can also >be managed as a system parameter on the authenticator." > >Change: > >"[d] Method specific negotiation within EAP. While EAP itself does not > support lifetime negotiation, it would be possible to specify > methods that do. However, systems that rely on such negotiation > for exported keys would only function with these methods. As a > result, it is NOT RECOMMENDED to use this approach as the sole way > to determine key lifetimes." > >To: > >"[d] Method specific negotiation within EAP. While EAP itself does not >support lifetime negotiation, it would be possible to specify >methods that do. However, systems that rely on such negotiation >for exported keys would only function with these methods; >in the interest of method independence, key management of >exported or derived keys SHOULD NOT be provided within EAP methods." > >In Section 3.6, change: > >" Where the EAP method does not export the Key-Lifetime parameter, the > lifetime of the EAP keying material may not be defined until > completion of the Secure Association Protocol, if ever. " > >To: > >"Where the EAP method does not negotiate the >lifetime of exported keys, the lifetime of the EAP keying >material may not be defined until completion of the >Secure Association Protocol, if ever." > >Change Appendix A to the following: > >"Appendix A - Exported Parameters in Existing Methods > > This Appendix specifies Session-Id, Peer-Id and Server-Id > for EAP methods that have been published prior to this > specification. Future EAP method specifications MUST include a > definition of the Session-Id, Peer-Id, and Server-Id (could be the > empty string). > > EAP-Identity > > The EAP-Identity method is defined in [RC3748]. It does not > derive keys, and therefore does not define the > Session-Id. The Peer-Id exported by the Identity method is > determined by the octets included within the EAP- > Response/Identity. The Server-Id is the empty string (zero > length). > > EAP-Notification > > The EAP-Notification method is defined in [RFC3748]. It does not > derive keys and therefore does not define the > Session-Id. The Peer-Id and Server-Id are the empty string (zero > length). > > EAP-GTC > > The EAP-GTC method is defined in [RFC3748]. It does not derive > keys and therefore does not define the Session- > Id. The Peer-Id and Server-Id are the empty string. > > EAP-OTP > > The EAP-OTP method is defined in [RFC3748]. It does not derive > keys and therefore does not define the Session- > Id. The Peer-Id and Server-Id are the empty string. > > EAP-TLS > > EAP-TLS is defined in [RFC2716]. The EAP-TLS Session-Id is the > concatenation of the Expanded EAP Type Code (including the Type, > Vendor-Id and Vendor-Type fields defined in [RFC3748] Section 5.7) > with the peer and server nonces. The Peer-Id and Server-Id are > the contents of the altSubjectName in the peer and server > certificates. > > EAP-AKA > > EAP-AKA is defined in [RFC4187]. The EAP-AKA Session-Id is the > concatenation of the Expanded EAP Type Code (including the Type, > Vendor-Id and Vendor-Type fields defined in [RFC3748] Section 5.7) > with the contents of the RAND field from the AT_RAND attribute, > followed by the contents of the AUTN field in the AT_AUTN > attribute. > > The Peer-Id is the contents of the Identity field from the > AT_IDENTITY attribute, using only the Actual Identity Length > octets from the beginning, however. Note that the contents are > used as they are transmitted, regardless of whether the > transmitted identity was a permanent, pseudonym, or fast re- > authentication identity. The Server-Id is an empty string. > > EAP-SIM > > EAP-SIM is defined in [RFC4186]. The EAP-SIM Session-Id is the > concatenation of the Expanded EAP Type Code (including the Type, > Vendor-Id and Vendor-Type fields defined in [RFC3748] Section 5.7) > with the contents of the RAND field from the AT_RAND attribute, > followed by the contents of the NONCE_MT field in the AT_NONCE_MT > attribute. > > The Peer-Id is the contents of the Identity field from the > AT_IDENTITY attribute, using only the Actual Identity Length > octets from the beginning, however. Note that the contents are > used as they are transmitted, regardless of whether the > transmitted identity was a permanent, pseudonym, or fast re- > authentication identity. The Server-Id is an empty string." > >Delete all other mentions of the Key-Lifetime parameter from the document. > > >_________________________________________________________________ >To unsubscribe or modify your subscription options, please visit: >http://lists.frascone.com/mailman/listinfo/eap > >Arhives: http://lists.frascone.com/pipermail/eap > > > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Sat Jun 24 16:06:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuEOn-00045P-Bt for eap-archive@lists.ietf.org; Sat, 24 Jun 2006 16:06:33 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuEOl-0000uX-W8 for eap-archive@lists.ietf.org; Sat, 24 Jun 2006 16:06:33 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A43EC43011B for ; Sat, 24 Jun 2006 13:06:31 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id F210C430064 for ; Sat, 24 Jun 2006 13:05:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id DD7E2398038 for ; Sat, 24 Jun 2006 13:05:25 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9D507398039 for ; Sat, 24 Jun 2006 13:05:19 -0700 (PDT) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 48D6E898BA; Sat, 24 Jun 2006 23:05:16 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 025BE898B7; Sat, 24 Jun 2006 23:05:15 +0300 (EEST) Message-ID: <449D7D7D.6080207@piuha.net> Date: Sat, 24 Jun 2006 20:59:25 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com Subject: Re: [eap] Proposed Resolution to Issue 357: Channel Binding Defintiion X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Bernard Aboba wrote: >How about this: > >"A secure mechanism for ensuring that a subset of the parameters transmitted >by the >authenticator (such as authenticator identifiers and properties) are agreed >upon by >the EAP peer and server. It is expected that the parameters are also >securel agreed >upon by the EAP peer and authenticator via the lower layer if the >authenticator >advertised the parameters." > > Works for me. --Jari _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Sat Jun 24 16:06:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuEP8-00055T-3p for eap-archive@lists.ietf.org; Sat, 24 Jun 2006 16:06:54 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuEP5-0000up-MR for eap-archive@lists.ietf.org; Sat, 24 Jun 2006 16:06:54 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5BB5F43011E for ; Sat, 24 Jun 2006 13:06:51 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id B82994300EA for ; Sat, 24 Jun 2006 13:05:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id ABE34398039 for ; Sat, 24 Jun 2006 13:05:26 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id 79E86398058 for ; Sat, 24 Jun 2006 13:05:21 -0700 (PDT) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 7C220898B8; Sat, 24 Jun 2006 23:05:20 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 2AAEB89887; Sat, 24 Jun 2006 23:05:20 +0300 (EEST) Message-ID: <449D8762.7050300@piuha.net> Date: Sat, 24 Jun 2006 21:41:38 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com Subject: Re: [eap] Proposed Resolution to Issue 367: Key Scope andServerAuthorization X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Bernard Aboba wrote: >How about the following: > >Add the following paragraphs to the end of Section 2.3 Server >Identification: > >"EAP methods that support mutual authentication enable the EAP peer to only >connect to authenticators authenticated by a trusted EAP server. However, >mutual authentication may not result in verification of the EAP server >identity. For example, the EAP peer may only verify that the EAP server >possesses a long-term secret; in this case the EAP peer will only know that >an authenticator has been authorized by an EAP server, but will not know >which one. > >EAP methods that export the Server-Id MUST verify the server identity. This >enables the EAP peer to decide whether a specific EAP server is authorized >or not, and determine whether the EAP server is sharing keying material >outside the intended scope. In some cases, such as where the certificate >extensions defined in [RFC4334] are included in the server certificate, it >may even be possible for the peer to verify some Channel Binding parameters >from the server certificate. Where the EAP peer does not verify the EAP >server identity, it is not possible for the peer to determine whether keying >material has been shared outside its authorized scope." > > I am basically fine with this text, but it may be exaggarate the value of an identifier a little bit. If you assume that the correct server set has given long-term secret material to some other servers, its not clear that having the server provide an identifier helps in all cases. For instance, the server may lie about its identifier. Suggested edit: s/This enables the EAP peer to decide/This may help the EAP peer to decide/ --Jari _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Sat Jun 24 16:16:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuEYN-0001D2-Ki for eap-archive@lists.ietf.org; Sat, 24 Jun 2006 16:16:27 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuEYM-0001Sd-7Q for eap-archive@lists.ietf.org; Sat, 24 Jun 2006 16:16:27 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id DA16B43010E for ; Sat, 24 Jun 2006 13:16:25 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id B75F0430064 for ; Sat, 24 Jun 2006 13:16:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id A3395398061 for ; Sat, 24 Jun 2006 13:16:09 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5F531398058 for ; Sat, 24 Jun 2006 13:16:06 -0700 (PDT) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 37ED6898B6; Sat, 24 Jun 2006 23:16:05 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id DC87289887; Sat, 24 Jun 2006 23:16:04 +0300 (EEST) Message-ID: <449D9D74.5000106@piuha.net> Date: Sat, 24 Jun 2006 23:15:48 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com Subject: Re: [eap] Issue 370: Key Management X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Looks good to me. --Jari >The proposed resolution is to change Section 3 from: > >"3. Key Management > > EAP as defined in [RFC3748] supports key derivation, but does not > provide for the management of exported or derived keys. Although EAP > methods may support "fast reconnect" as defined in [RFC3748] Section > 7.2.1, EAP does not support re-key of exported keys without re- > authentication." > >to: > >"3. Key Management > > EAP as defined in [RFC3748] supports key derivation, but does not > provide for the management of exported or derived keys. Missing > functionality includes: > >[a] Re-key. EAP does not support re-key of exported keys without re- > authentication, although EAP methods may support "fast reconnect" > as defined in [RFC3748] Section 7.2.1. > >[b] Key delete/install semantics. EAP does not synchronize > installation or deletion of keying material on the EAP peer and > authenticator. > >[c] Lifetime negotiation. EAP does not support lifetime negotiation for > exported keys, and existing EAP methods also do not support key > lifetime negotiation. > >[d] Cryptographic algorithm negotiation. EAP methods only negotiate > cryptographic algorithms for their own use, not for the underlying > lower layers. > >[e] Guaranteed TSK freshness. Without a post-EAP handshake, TSKs can > be reused if EAP keying material is cached. > > These deficiencies are typically addressed via a post-EAP handshake > known as the Secure Association Protocol." > > >_________________________________________________________________ >To unsubscribe or modify your subscription options, please visit: >http://lists.frascone.com/mailman/listinfo/eap > >Arhives: http://lists.frascone.com/pipermail/eap > > > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Sat Jun 24 16:21:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuEd3-0007JB-BX for eap-archive@lists.ietf.org; Sat, 24 Jun 2006 16:21:17 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuEd1-0001Vh-Uw for eap-archive@lists.ietf.org; Sat, 24 Jun 2006 16:21:17 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 92D2843011E for ; Sat, 24 Jun 2006 13:21:15 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 2A3B3430064 for ; Sat, 24 Jun 2006 13:21:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 191D039803D for ; Sat, 24 Jun 2006 13:21:00 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id E9E2A398039 for ; Sat, 24 Jun 2006 13:20:56 -0700 (PDT) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id CD8E0898B6; Sat, 24 Jun 2006 23:20:55 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 7D34889887; Sat, 24 Jun 2006 23:20:55 +0300 (EEST) Message-ID: <449D9E96.5000302@piuha.net> Date: Sat, 24 Jun 2006 23:20:38 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: eap@frascone.com X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: Bernard Aboba Subject: [eap] Conclusion of the eap-keying WGLC X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Based on my review of the mail threads, it seems that we have concluded the discussion with the below issues, with suggested text that is available from Bernard's issue list: 351 Incomplete EAP Pre-authentication discussion 352 Channel binding issue 353 Definition of Session-Id/Method-Id 354 Method-Id and Session-Id 355 Data Associated with Authentication 356 Ciphersuite independence and section 1.6.4 357 Channel binding definition 358 AAA-Key section 1.2 359 Typo, Section 1.4 editorial 360 EMSK transport 361 Child key expiry 363 Section 2.2 title 364 Section 2.1 AAA key caching 366 Section 2.2.2 368 Threat Model Assumptions 369 Key lifetime parameter removal On the following issues the discussion was not yet completed. Suggested next steps are included: 362 Lower layer params and EMSK Here Vidya and Madjid disagreed, but there was no followup. The disagreement may actually be on text that is from RFC 3748, however. I talked to Bernard and we can probably work out what to say so that you Vidya and Madjid are OK with it. Expect an e-mail from Bernard on this. In general, if there's future IETF work, such as work possibly coming out of the HOKEY effort, it can relax the rules from RFC 3748, just as RFC 3748 itself says: "(This restriction will be relaxed in a future document that specifies how the EMSK can be used.)" 365 Ambiguous use of identifier It was unclear if Joe was OK with the final proposal. Given that there was a fair bit of discussion about this, I'd like to make sure that the end result was acceptable. Joe? 367 Key scope and eap server auth As above, pending Joe's response. 370 Key management No discussion. Please comment. --Jari (doing this on Bernard's behalf as he's one of the authors) _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Sat Jun 24 16:36:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuEs6-0001Qp-7U for eap-archive@lists.ietf.org; Sat, 24 Jun 2006 16:36:50 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuEs4-0002IM-Tk for eap-archive@lists.ietf.org; Sat, 24 Jun 2006 16:36:50 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 2478A430103 for ; Sat, 24 Jun 2006 13:36:48 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 84E29430064 for ; Sat, 24 Jun 2006 13:36:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 62E534311A9 for ; Sat, 24 Jun 2006 13:36:35 -0700 (PDT) Received: from hotmail.com (bay106-f31.bay106.hotmail.com [65.54.161.41]) by hermes.tigertech.net (Postfix) with ESMTP id D34E443119D for ; Sat, 24 Jun 2006 13:36:32 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 24 Jun 2006 13:36:31 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Sat, 24 Jun 2006 20:36:30 GMT X-Originating-IP: [71.38.130.70] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <449D8762.7050300@piuha.net> From: "Bernard Aboba" To: jari.arkko@piuha.net Date: Sat, 24 Jun 2006 13:36:30 -0700 Mime-Version: 1.0 X-OriginalArrivalTime: 24 Jun 2006 20:36:31.0983 (UTC) FILETIME=[E0A7EFF0:01C697CD] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=1.7 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Cc: eap@frascone.com Subject: Re: [eap] Proposed Resolution to Issue 367: Key Scope andServerAuthorization X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 >Suggested edit: s/This enables the EAP peer to decide/This may help >the EAP peer to decide/ OK. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Sat Jun 24 16:53:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuF8U-0002GH-72 for eap-archive@lists.ietf.org; Sat, 24 Jun 2006 16:53:46 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuF8S-0004g2-LW for eap-archive@lists.ietf.org; Sat, 24 Jun 2006 16:53:46 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4D7724300EE for ; Sat, 24 Jun 2006 13:53:44 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 4B97A430064 for ; Sat, 24 Jun 2006 13:53:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 350314311E1 for ; Sat, 24 Jun 2006 13:53:26 -0700 (PDT) Received: from hotmail.com (bay106-f34.bay106.hotmail.com [65.54.161.44]) by hermes.tigertech.net (Postfix) with ESMTP id 852344311E0 for ; Sat, 24 Jun 2006 13:53:24 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 24 Jun 2006 13:53:24 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Sat, 24 Jun 2006 20:53:22 GMT X-Originating-IP: [71.38.130.70] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <449D8762.7050300@piuha.net> From: "Bernard Aboba" To: jari.arkko@piuha.net Date: Sat, 24 Jun 2006 13:53:22 -0700 Mime-Version: 1.0 X-OriginalArrivalTime: 24 Jun 2006 20:53:24.0146 (UTC) FILETIME=[3BF3C120:01C697D0] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=1.7 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Cc: eap@frascone.com Subject: Re: [eap] Proposed Resolution to Issue 367: Key Scope andServerAuthorization X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e >Suggested edit: s/This enables the EAP peer to decide/This may help >the EAP peer to decide/ Here is a revised version of the text proposed for Section 2.3: "2.3. Server Identification The EAP method conversation is between the EAP peer and server, as identified by the Peer-Id and Server-Id. As shown in Figure 3, an authenticator may be configured to communicate with multiple EAP servers; the EAP server that an authenticator communicates with may vary according to configuration and network and server availability. While the EAP peer can assume that all EAP servers within a realm have access to the credentials necessary to validate an authentication attempt, it cannot assume that all EAP servers share persistent state. Authenticators may be configured with different primary or secondary EAP servers, in order to balance the load. Also, the authenticator can dynamically determine the EAP server to which requests will be sent; in event of a communication failure, the authenticator may fail over to another EAP server. For example, in Figure 3, Authenticator2 may be initially configured with EAP server1 as its primary backend authentication server, and EAP server2 as the backup, but if EAP server1 becomes unavailable, EAP server2 may become the primary server. In general, the EAP peer cannot direct an authentication attempt to a particular EAP server within a realm; this decision is made solely by the authenticator. Nor can it determine which EAP server it will be communicating with, prior to the start of the EAP method conversation. The Server-Id is not included in the EAP- Request/Identity, and since the authenticator determines the EAP server dynamically, it typically is not possible for the authenticator to advertise the Server-Id during the discovery phase. EAP methods may or may not export the Server-Id, and as a result, the EAP peer may not even learn which server it was conversing with after the EAP conversation completes successfully. As a result, an EAP peer, on connecting to a new authenticator or reconnecting to the same authenticator, may find itself communicating with a different EAP server. Fast reconnect, defined in [RFC3748] Section 7.2, may fail if the EAP server that the peer communicates with is not the same one with which it initially established a security association. For example, an EAP peer attempting an EAP-TLS session resume may find that the new EAP-TLS server will not have access to the TLS Master Key identified by the TLS Session-Id, and therefore the session resumption attempt will fail, requiring completion of a full EAP-TLS exchange. EAP methods that support mutual authentication may not allow the EAP peer to verify the EAP server identity. For example, the EAP peer may only verify that the EAP server possesses a long-term secret; in this case the EAP peer will only know that an authenticator has been authorized by an EAP server, but will not confirm the identity of the EAP server. EAP methods that export the Server-Id MUST verify the server identity. As noted in Appendix A, existing EAP methods exporting the Server-Id determine this from the altSubjectName in the server certificate, and as a result, the peer determines the identity of the server (expressed as a Fully Qualified Domain Name (FQDN)) by validating the server certificate. Validating the EAP server identity may help the EAP peer to decide whether a specific EAP server is authorized, and to determine whether the EAP server is sharing keying material outside the intended scope. In some cases, such as where the certificate extensions defined in [RFC4334] are included in the server certificate, it may even be possible for the peer to verify some Channel Binding parameters from the server certificate. Where the EAP peer does not verify the EAP server identity, it is not possible for the peer to determine whether the EAP server has shared keying material outside its authorized scope. It is possible for problems to arise in situations where the EAP server identifies itself differently to the EAP peer and authenticator. For example, the Server-Id exported by EAP methods may not be identical to the Fully Qualified Domain Name (FQDN) of the backend authentication server. Where certificate-based authentication is used within RADIUS or Diameter, the altSubjectName used in the backend server certificate may not be identical to the Server-Id or backend server FQDN. Where the backend server FQDN differs from the altSubjectName in the certificate, the AAA client may not be able to successfully determine whether it is talking to the correct backend authentication server. Where the Server-Id and backend server FQDN differ, the combination of the key scope (Peer-Id, Server-Id) and EAP conversation identifier (Session-Id) may not be sufficient for the authenticator to determine where the key resides. For example, the authenticator may identify backend servers by their IP address (as occurs in RADIUS), or using a Fully Qualified Domain Name (as in Diameter). If the Server-Id does not correspond to the IP address or FQDN of a known backend authentication server, then the authenticator will not know which backend authentication server possesses the key." _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Sat Jun 24 17:09:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuFNK-0007l1-W3 for eap-archive@lists.ietf.org; Sat, 24 Jun 2006 17:09:06 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuFNG-00065p-Hb for eap-archive@lists.ietf.org; Sat, 24 Jun 2006 17:09:06 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A1F46430106 for ; Sat, 24 Jun 2006 14:09:00 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 48DE5430064 for ; Sat, 24 Jun 2006 14:08:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2D426398068 for ; Sat, 24 Jun 2006 14:08:43 -0700 (PDT) Received: from hotmail.com (bay106-f26.bay106.hotmail.com [65.54.161.36]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4CD3939803D for ; Sat, 24 Jun 2006 14:08:40 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 24 Jun 2006 14:08:39 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Sat, 24 Jun 2006 21:08:38 GMT X-Originating-IP: [71.38.130.70] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Sat, 24 Jun 2006 14:08:38 -0700 Mime-Version: 1.0 X-OriginalArrivalTime: 24 Jun 2006 21:08:39.0948 (UTC) FILETIME=[5DD00CC0:01C697D2] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.748 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Subject: Re: [eap] Proposed Resolution to Issue 362: Lower layer parameters and EMSK text X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Vidya said: "> As noted in [RFC3748] Section 7.10: > > The EMSK is reserved for future use and MUST remain on the EAP > peer and EAP server where it is derived; it MUST NOT be > transported to, or shared with, additional parties, or used to > derive any other keys." Are we sticking to this rule that the EMSK MUST NOT be used to derive any other keys? Given that there is agreement in general about potential derivation of keys from the EMSK, what implications does this text have to future documents specifying derived keys from the EMSK?" [BA] Since this is a quotation from [RFC3748] rather than anything created in this document, we can delete the quote. Don't think it adds much anyway. [Vidya] >On the EAP server, keying material and parameters requested by and passed >down to the AAA layer may be replicated to the AAA layer on the >authenticator. I understand what the above is trying to say - however, this does conflict with the fact that the EMSK MUST NOT be transported to the authenticator (even though it may be passed down to the AAA layer on the server). I wonder if some clarification is necessary to avoid confusion. [BA] How about this? "On the EAP server, keying material and parameters requested by and passed down to the AAA layer may be replicated to the AAA layer on the authenticator (with the exception of the EMSK)." _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Sat Jun 24 21:31:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuJTd-0005Iy-Qh for eap-archive@lists.ietf.org; Sat, 24 Jun 2006 21:31:53 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuJTc-0001Bp-Df for eap-archive@lists.ietf.org; Sat, 24 Jun 2006 21:31:53 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id CEA5E4300EE for ; Sat, 24 Jun 2006 18:31:51 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 09257430064 for ; Sat, 24 Jun 2006 18:31:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id EDD67398025 for ; Sat, 24 Jun 2006 18:31:38 -0700 (PDT) Received: from hotmail.com (bay106-f3.bay106.hotmail.com [65.54.161.13]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7D249398039 for ; Sat, 24 Jun 2006 18:31:35 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 24 Jun 2006 18:31:35 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Sun, 25 Jun 2006 01:31:32 GMT X-Originating-IP: [71.38.130.70] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: eap@frascone.com Date: Sat, 24 Jun 2006 18:31:32 -0700 Mime-Version: 1.0 X-OriginalArrivalTime: 25 Jun 2006 01:31:35.0221 (UTC) FILETIME=[189BAE50:01C697F7] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.748 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Subject: [eap] Issue 371: Session-Id calculation X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Issue 371: Session-Id Calculation Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date Submitted: June 24, 2006 Reference: Document: KEYING-13 Comment type: 'T'echnical Priority: S Section: Appendix A Rationale/Explanation of issue: For methods allocated with the standard EAP space (TLS, AKA, SIM) Appendix A states that the Session-Id is constructed as follows: "Session-Id is the concatenation of the Expanded EAP Type Code (including the Type, Vendor-Id and Vendor-Type fields defined in [RFC3748] Section 5.7) with the..." Since these methods have no Vendor-Id or Vendor-Type fields, are these fields included or not? My recommendation is to replace the text as follows: "Session-Id is the concatenation of the EAP Type Code () with the..." _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From tkrieman@btigroup.com Sat Jun 24 22:31:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuKOp-0006d8-Nk; Sat, 24 Jun 2006 22:31:00 -0400 Received: from softbank218180203004.bbtec.net ([218.180.203.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuKOp-00061l-7L; Sat, 24 Jun 2006 22:30:59 -0400 From: "Refugio Luna" To: Subject: re: Mark invested Sara 0f Susan Date: Sun, 25 Jun 2006 02:30:49 -0540 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-2"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.1830 X-MimeOLE: Produced By Microsoft MimeOLE 6.00.3790.1830 X-Spam-Score: 4.9 (++++) X-Scan-Signature: d6b246023072368de71562c0ab503126 AGA Resources Climbs 33% after announcing the Acquisition Of Triumph Research LTD and Beijing Tangde International Film and Culture Co. LTD This is climbing move now. AGA Resources Inc. A G A 0 Open: $2.25 Close: $3.00 Up: 33% AGA announced its Acquisition of a B.V.I. company to become involved in a Media and Entertainment Joint Venture in China. This agreement gives them controlling shares of Triumph and all its investment ventures in China. this has also drawn attention to AGA's current exploration of minerals in there acquired properties in British Columbia, in which recent purchase of Diamond Core drilling equipment that can explore to a depth of 1400 feet, has excited its current investors and today brought more investors to the table. With an increase in price of 33% and the excitement building on this company, we strongly encourage you to review the recent news releases and get on board while the price is still low. Place your bid first thing Monday morning. From eap-bounces+eap-archive=lists.ietf.org@frascone.com Sun Jun 25 01:28:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuNAc-000321-4B for eap-archive@lists.ietf.org; Sun, 25 Jun 2006 01:28:30 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuNAa-0005y0-Dy for eap-archive@lists.ietf.org; Sun, 25 Jun 2006 01:28:30 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 8465B4300F7 for ; Sat, 24 Jun 2006 22:28:27 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C874F430097 for ; Sat, 24 Jun 2006 22:28:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B538C1448013 for ; Sat, 24 Jun 2006 22:28:11 -0700 (PDT) Received: from hotmail.com (bay106-f12.bay106.hotmail.com [65.54.161.22]) by hermes.tigertech.net (Postfix) with ESMTP id E30281448014 for ; Sat, 24 Jun 2006 22:28:08 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 24 Jun 2006 22:28:08 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Sun, 25 Jun 2006 05:28:05 GMT X-Originating-IP: [71.38.130.70] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <20060625034452.67345.qmail@web54402.mail.yahoo.com> From: "Bernard Aboba" To: eap@frascone.com Date: Sat, 24 Jun 2006 22:28:05 -0700 Mime-Version: 1.0 X-OriginalArrivalTime: 25 Jun 2006 05:28:08.0557 (UTC) FILETIME=[247EE1D0:01C69818] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=1.7 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Subject: Re: [eap] Issue 371: Session-Id calculation X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Here is the revised text of Section 1.2, 1.4 and Appendix A: New Section 1.2 definition: "Session-Id The EAP Session-Id uniquely identifies an EAP session between an EAP peer (as identified by the Peer-Id) and server (as identified by the Server-Id). For more information, see Section 1.4." Section 1.4: " Session-Id The Session-Id uniquely identifies an EAP session between an EAP peer (as identified by the Peer-Id) and server (as identified by the Server-Id). Where the EAP Type Code is less than 255, the EAP Session-Id consists of the concatenation of the EAP Type Code and a temporally unique identifier obtained from the method. Where expanded EAP Type Codes are used, the EAP Session-Id consists of the Expanded Type Code (including the Type, Vendor-Id and Vendor- Type fields defined in [RFC3748] Section 5.7) concatenated with a temporally unique identifier obtained from the method. This unique identifier is typically constructed from nonces or counters used within the EAP method exchange. The inclusion of the Type Code in the EAP Session-Id ensures that each EAP method has a distinct Session-Id space. Since an EAP session is not bound to a particular authenticator or specific ports on the peer and authenticator, the authenticator port or identity are not included in the Session-Id." Appendix A text for EAP-TLS, AKA, and SIM: " EAP-TLS EAP-TLS is defined in [RFC2716]. The EAP-TLS Session-Id is the concatenation of the EAP Type Code (0x0D) with the peer and server nonces. The Peer-Id and Server-Id are the contents of the altSubjectName in the peer and server certificates. EAP-AKA EAP-AKA is defined in [RFC4187]. The EAP-AKA Session-Id is the concatenation of the EAP Type Code (0x17) with the contents of the RAND field from the AT_RAND attribute, followed by the contents of the AUTN field in the AT_AUTN attribute. The Peer-Id is the contents of the Identity field from the AT_IDENTITY attribute, using only the Actual Identity Length octets from the beginning, however. Note that the contents are used as they are transmitted, regardless of whether the transmitted identity was a permanent, pseudonym, or fast re- authentication identity. The Server-Id is an empty string. EAP-SIM EAP-SIM is defined in [RFC4186]. The EAP-SIM Session-Id is the concatenation of the EAP Type Code (0x12) with the contents of the RAND field from the AT_RAND attribute, followed by the contents of the NONCE_MT field in the AT_NONCE_MT attribute. The Peer-Id is the contents of the Identity field from the AT_IDENTITY attribute, using only the Actual Identity Length octets from the beginning, however. Note that the contents are used as they are transmitted, regardless of whether the transmitted identity was a permanent, pseudonym, or fast re- authentication identity. The Server-Id is an empty string." >From: "M. Vanderveen" >To: Bernard Aboba >Subject: Re: [eap] Issue 371: Session-Id calculation >Date: Sat, 24 Jun 2006 20:44:52 -0700 (PDT) > >That sounds fine. > Michaela > >Bernard Aboba wrote: > Issue 371: Session-Id Calculation >Submitter name: Bernard Aboba >Submitter email address: aboba@internaut.com >Date Submitted: June 24, 2006 >Reference: >Document: KEYING-13 >Comment type: 'T'echnical >Priority: S >Section: Appendix A >Rationale/Explanation of issue: > >For methods allocated with the standard EAP space (TLS, AKA, SIM) Appendix >A >states that the Session-Id is constructed as follows: > >"Session-Id is the concatenation of the Expanded EAP Type Code (including >the Type, >Vendor-Id and Vendor-Type fields defined in [RFC3748] Section 5.7) with >the..." > >Since these methods have no Vendor-Id or Vendor-Type fields, are these >fields included or not? > >My recommendation is to replace the text as follows: > >"Session-Id is the concatenation of the EAP Type Code (here>) with the..." > > >_________________________________________________________________ >To unsubscribe or modify your subscription options, please visit: >http://lists.frascone.com/mailman/listinfo/eap > >Arhives: http://lists.frascone.com/pipermail/eap > > > >--------------------------------- >Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates >starting at 1¢/min. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From Rogerscensorial@earthlink.net Sun Jun 25 03:12:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuOni-0003P4-8Q for eap-archive@ietf.org; Sun, 25 Jun 2006 03:12:58 -0400 Received: from [196.207.25.86] (helo=MAINA) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuOng-0002Rg-F9; Sun, 25 Jun 2006 03:12:58 -0400 Message-ID: <52482991753182.0CB3F151A5@HDCP9T> From: "Rogers" To: Subject: re: Enjoy the newest Would you like to have stronger ejaaculattion? Date: Sun, 25 Jun 2006 10:12:52 +0300 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: EuhCMVD0ebK9h3BGQNutLU6YqneVlbThfPCq Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.5 (++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Good afternoon Buy this product now and all women will be yours Take this and your woman will be speechless Every man wishes it. Show your girl a huge explosion as I used to do Have you ever dreamt to have a very hard peenis during all process? Find what you need: http://ihlmail/gal/ms From txxibh@tw-ins.com Sun Jun 25 06:00:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuRPS-0003YL-M3 for eap-archive@ietf.org; Sun, 25 Jun 2006 06:00:06 -0400 Received: from bmg67.neoplus.adsl.tpnet.pl ([83.28.226.67] helo=tw-ins.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FuRPQ-00068h-66 for eap-archive@ietf.org; Sun, 25 Jun 2006 06:00:06 -0400 Received: from 83.28.226.67 by smtp7.tw-ins.com;Sun, 25 Jun 2006 11:59:50 +0100 Date: Sun, 25 Jun 2006 11:59:50 +0100 From: "dqamnfhw geohskkef" X-Sender: txxibh@tw-ins.com To: Subject: Emerging growth MONDAY X-Mailer: MIME-tools 5.503 (Entity 5.501) Message-Id: <4950512406.199370-60857910-6909@tw-ins.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 1.8 (+) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Hollywood Intermediate Inc. (SYM : H Y W I) Current Sh Price : $ 0.65 Follow the performance of this company, it is a real gold mine watch this stck tr@de HYWI has performed like clockwork every time CO OverView H o l l y w o o d I n t e r m e d i a t e provides a proprietary technology of Digital Intermediate services to feature filmmakers for post-production for film mastering and restoration. This technology gives the filmmakers total creative control over the look of their productions. Whether shooting on film or acquiring in HD or SD video, H o l l y w o o d I n t e r m e d i a t e puts a powerful cluster of digital tools at the director's disposal to achieve stunning results on the big screen. Matchframe Digital Intermediate, a division of H o l l y w o o d I n t e r m e d i a t e, Inc., packages a full array of post-production services with negative handling expertise and cost-effective 2K digital intermediate and 35mm film out systems. The Digital Intermediate process eliminates current post-production redundancies by creating a single high-resolution master file from which all versions can be made, including all theatrical and High Definition formats. By creating a single master file with resolution higher than the current High Definition broadcast standards, the DI master file enables cinema and television distributors to extract and archive all current and future cinema and television formats including Digital Cinema, Television and High Definition. Red H0t News: H o l l y w o o d I n t e r m e d i a t e a provider of digital intermediate film mastering services, announced today that that its Matchframe Digital Intermediate (MDI) division is completing a digital intermediate for Chad Lowe's directorial debut, "Beautiful Ohio," starring William Hurt and Rita Wilson. READ MORE THIS IS HUGE H o l l y w o o d I n t e r m e d i a t e Expands the Creative Palette for Independent Filmmakers GLENDALE, CA--(MARKET WIRE)--May 31, 2006 -- H o l l y w o o d I n t e r m e d i a t e, Inc. A provider of digital intermediate film mastering services, announced today that its Matchframe Digital Intermediate division is currently providing full digital intermediate services for Super 16MM productions. H o l l y w o o d I n t e r m e d i a t e, Inc. (H.Y.W.I - News), a provider of digital intermediate film mastering services, announced that High Definition preview masters as part of its normal digital intermediate service offerings and workflow. "Typically, in current post-production workflow, HD dailies masters are edited into high quality preview masters including color timing, dirt removal, opticals and visual effects," said David Waters, H o l l y w o o d I n t e r m e d i a t e president. "Unfortunately, none of these processes translate to the theatrical release of the film as they must all be duplicated or repeated in either a higher resolution digital format, or photo chemical process." H o l l y w o o d I n t e r m e d i a t e gives Motion Picture producers the ability to scan their selected original camera negative at 2k or 4k film resolution, conform a high resolution digital master for theatrical and broadcast release including dirt removal, opticals and visual effects, and output a High Definition preview master to be used for preview screenings and focus groups that can be deployed in any worldwide theater location. "The challenge for completing the final editorial decisions on a motion picture are balanced between the ability to display the highest resolution picture for a test audience, and the costs and time in having to re-master your film based on a test audience response," said Jim Delany, H o l l y w o o d I n t e r m e d i a t e COO. DO your Due Diligence and you'll see what we are talking about when it comes to H_Y_W_I.PK ----------------------- She has a green thumb. Watch and wait. Root it out. Stir up an ant's nest. What on earth? Say it with flowers. They're like two peas in a pod. Ugly as a mud fence. Tastes like chicken. Shit end of the stick. Welcome to my garden. Water it down. A snail's pace. They're like two peas in a pod. Two peas in a pod. She's the apple of my eye. Wrinkled as a prune. Till the cows come home. A weed is no more than a flower in disguise. Water under the bridge. Some like carrots others like cabbage. Weed out. A stepping stone to. Stop and smell the roses. The sharper is the berry, the sweeter is the wine. Tastes like chicken. A thing of beauty is a joy forever. You never miss the water till the well runs dry. Sow dry and set wet. From eap-bounces+eap-archive=lists.ietf.org@frascone.com Sun Jun 25 10:58:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuW4Z-00064n-6s for eap-archive@lists.ietf.org; Sun, 25 Jun 2006 10:58:51 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuW4X-0003cB-N8 for eap-archive@lists.ietf.org; Sun, 25 Jun 2006 10:58:51 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 7B5924300FF for ; Sun, 25 Jun 2006 07:58:48 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id EF945430059 for ; Sun, 25 Jun 2006 07:58:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D923E39801A for ; Sun, 25 Jun 2006 07:58:30 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by zoidberg.tigertech.net (Postfix) with ESMTP id 80659398019 for ; Sun, 25 Jun 2006 07:58:27 -0700 (PDT) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 41334898B8; Sun, 25 Jun 2006 17:58:24 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id E407889887; Sun, 25 Jun 2006 17:58:23 +0300 (EEST) Message-ID: <449EA47E.7040404@piuha.net> Date: Sun, 25 Jun 2006 17:58:06 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: eap@frascone.com Subject: Re: [eap] Issue 371: Session-Id calculation X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a OK. --Jari Bernard Aboba wrote: >Here is the revised text of Section 1.2, 1.4 and Appendix A: > >New Section 1.2 definition: > >"Session-Id > The EAP Session-Id uniquely identifies an EAP session between an > EAP peer (as identified by the Peer-Id) and server (as identified > by the Server-Id). For more information, see Section 1.4." > >Section 1.4: > >" Session-Id > > The Session-Id uniquely identifies an EAP session between an EAP > peer (as identified by the Peer-Id) and server (as identified by > the Server-Id). Where the EAP Type Code is less than 255, the EAP > Session-Id consists of the concatenation of the EAP Type Code and > a temporally unique identifier obtained from the method. Where > expanded EAP Type Codes are used, the EAP Session-Id consists of > the Expanded Type Code (including the Type, Vendor-Id and Vendor- > Type fields defined in [RFC3748] Section 5.7) concatenated with a > temporally unique identifier obtained from the method. This > unique identifier is typically constructed from nonces or > counters used within the EAP method exchange. The inclusion of > the Type Code in the EAP Session-Id ensures that each EAP method > has a distinct Session-Id space. Since an EAP session is not > bound to a particular authenticator or specific ports on the peer > and authenticator, the authenticator port or identity are not > included in the Session-Id." > >Appendix A text for EAP-TLS, AKA, and SIM: > >" EAP-TLS > > EAP-TLS is defined in [RFC2716]. The EAP-TLS Session-Id is the > concatenation of the EAP Type Code (0x0D) with the peer and server > nonces. The Peer-Id and Server-Id are the contents of the > altSubjectName in the peer and server certificates. > > EAP-AKA > > EAP-AKA is defined in [RFC4187]. The EAP-AKA Session-Id is the > concatenation of the EAP Type Code (0x17) with the contents of the > RAND field from the AT_RAND attribute, followed by the contents of > the AUTN field in the AT_AUTN attribute. > > The Peer-Id is the contents of the Identity field from the > AT_IDENTITY attribute, using only the Actual Identity Length > octets from the beginning, however. Note that the contents are > used as they are transmitted, regardless of whether the > transmitted identity was a permanent, pseudonym, or fast re- > authentication identity. The Server-Id is an empty string. > > EAP-SIM > > EAP-SIM is defined in [RFC4186]. The EAP-SIM Session-Id is the > concatenation of the EAP Type Code (0x12) with the contents of the > RAND field from the AT_RAND attribute, followed by the contents of > the NONCE_MT field in the AT_NONCE_MT attribute. > > The Peer-Id is the contents of the Identity field from the > AT_IDENTITY attribute, using only the Actual Identity Length > octets from the beginning, however. Note that the contents are > used as they are transmitted, regardless of whether the > transmitted identity was a permanent, pseudonym, or fast re- > authentication identity. The Server-Id is an empty string." > > > > > > >>From: "M. Vanderveen" >>To: Bernard Aboba >>Subject: Re: [eap] Issue 371: Session-Id calculation >>Date: Sat, 24 Jun 2006 20:44:52 -0700 (PDT) >> >>That sounds fine. >> Michaela >> >>Bernard Aboba wrote: >> Issue 371: Session-Id Calculation >>Submitter name: Bernard Aboba >>Submitter email address: aboba@internaut.com >>Date Submitted: June 24, 2006 >>Reference: >>Document: KEYING-13 >>Comment type: 'T'echnical >>Priority: S >>Section: Appendix A >>Rationale/Explanation of issue: >> >>For methods allocated with the standard EAP space (TLS, AKA, SIM) Appendix >>A >>states that the Session-Id is constructed as follows: >> >>"Session-Id is the concatenation of the Expanded EAP Type Code (including >>the Type, >>Vendor-Id and Vendor-Type fields defined in [RFC3748] Section 5.7) with >>the..." >> >>Since these methods have no Vendor-Id or Vendor-Type fields, are these >>fields included or not? >> >>My recommendation is to replace the text as follows: >> >>"Session-Id is the concatenation of the EAP Type Code (here>) with the..." >> >> >>_________________________________________________________________ >>To unsubscribe or modify your subscription options, please visit: >>http://lists.frascone.com/mailman/listinfo/eap >> >>Arhives: http://lists.frascone.com/pipermail/eap >> >> >> >>--------------------------------- >>Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates >>starting at 1¢/min. >> >> > > >_________________________________________________________________ >To unsubscribe or modify your subscription options, please visit: >http://lists.frascone.com/mailman/listinfo/eap > >Arhives: http://lists.frascone.com/pipermail/eap > > > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From tkramar@catalystusa.com Sun Jun 25 16:14:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fub0S-0000wx-01 for eap-archive@ietf.org; Sun, 25 Jun 2006 16:14:56 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fub0R-0000tG-Ux for eap-archive@ietf.org; Sun, 25 Jun 2006 16:14:55 -0400 Received: from p508e78f5.dip.t-dialin.net ([80.142.120.245]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fub0O-0002OR-TG for eap-archive@ietf.org; Sun, 25 Jun 2006 16:14:55 -0400 Date: Sun, 25 Jun 2006 20:14:01 -0060 From: "Katharine Owen" X-Mailer: The Bat! (v9.55.9) RJP15RKY0L Reply-To: "Katharine Owen" X-Priority: 3 (Normal) Message-ID: <76933957.20060625201401@catalystusa.com> To: eap-archive@ietf.org Subject: New Growth Stock Report MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: -0.5 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 A lert IS SUED Already up 0.30 in the last 3 days of tra ding! Falcon E nergy, Inc. FC Y I Current 0.85 5 Day Expected 2.90 MARK ET Plus Top four Pick There is a big PR campaign running all weekend! Is f cyi Ready To Go? If You Think So, You Know what to Do... Falcon Energy, Inc. Announces 100% Acquirement of Mongolian Mineral Exploration Licenses Friday June 9, 4:00 pm ET 5VANCOUVER, British Columbia--(BUSINESS WIRE)--June 9, 2006--Falcon Energy, Inc. (Pink Sheets:FCYI - News) is pleased to announce that it has fully acquired the exploration licenses for five mining properties in the mineral rich region of Mongolia. Management felt that the opportunity presented by these properties was significant enough to forgo a planned participation by a second resource company. These licenses will be held for a minimum of three years and grant Falcon Energy Inc. access to the mineral rights for the licensed properties. Mongolia has a wide variety of mineral resources. As of 1998, about 88% of the country had been geologically mapped but only 20% of the country's landmass had been licensed for exploration and exploitation. Falcon Energy's interest in the region is driven in part by the anticipation of deploying modern prospecting methods to an area that abounds in both base and precious metals. Exploitable mineral resources found in the area in which the licenses are held include: Gold, base metals such as Copper, Molybdenum, Lead and Zinc as well as Fluorite and Uranium. From superflych@superflychetguy.com Sun Jun 25 21:14:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuffw-0001zG-7S for eap-archive@ietf.org; Sun, 25 Jun 2006 21:14:04 -0400 Received: from [66.49.154.1] (helo=host78.host78-server.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fuffu-0007XU-Uh for eap-archive@ietf.org; Sun, 25 Jun 2006 21:14:04 -0400 X-ClientAddr: 127.0.0.1 Received: from superflychetguy.com (localhost.localdomain [127.0.0.1]) by host78.host78-server.com (8.12.11/8.12.11) with ESMTP id k5Q16uN2000900; Sun, 25 Jun 2006 21:06:57 -0400 Received: (from superflych@localhost) by superflychetguy.com (8.12.11/8.12.11/Submit) id k5Q16pmn000916; Sun, 25 Jun 2006 21:06:51 -0400 Date: Sun, 25 Jun 2006 21:06:51 -0400 Message-Id: <200606260106.k5Q16pmn000916@superflychetguy.com> To: Subject: JOB OFFER ///EARN 10% From: mrchenyi X-Priority: 3 (Normal) CC: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: RLSP Mailer X-yoursite-MailScanner-Information: Please contact the ISP for more information X-yoursite-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-MailScanner-From: superflych@superflychetguy.com X-Spam-Score: 1.2 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Dear Sir/Madam, I am Mr.chen Yi,managing Drago Equipment and Machinery,a division of Hubei Machinery & equipmentImport & Corporation (CMEC HUBEI CO.).We are a company who deal on mechanical equipment,hardware and minerals,electrical products,Medical & Chemicals, light industrial products and office equipment, and export into the Canada/America and Europe.We are searching for representatives who can help us establish a medium of getting to our ostumers in the Canada/America and Europe as well as making payments through you to us.Please if you are interested in transacting business with us we will be glad. Please contact us for more information,Subject to your satisfaction you will be given the opportunity to negotiate your mode of which we will pay for your services as our representative in Canada/America and Europe. Please if you are interested forward to us your phone number/fax and your full contact addresses. Thanks in advance Mr.Chen Yi Managing Director ___________________________________________________________________________ Mail sent from WebMail service at PHP-Nuke Powered Site - http://www.superflychetguy.com From eyoutdae@aptek.com Mon Jun 26 02:28:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FukZh-0000M1-Qf for eap-archive@ietf.org; Mon, 26 Jun 2006 02:27:57 -0400 Received: from 218-170-240-148.dynamic.hinet.net ([218.170.240.148] helo=aptek.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FukWw-00019z-8h for eap-archive@ietf.org; Mon, 26 Jun 2006 02:25:06 -0400 Received: from 218.170.240.148 by mailin-1.aptek.com;Mon, 26 Jun 2006 14:24:53 +0800 Date: Mon, 26 Jun 2006 14:24:53 +0800 From: "grvweww bthhyy" X-Sender: eyoutdae@aptek.com To: Subject: Todays winner MONDAY X-Mailer: Microsoft Outlook Express 5.00.2919.6700 Message-Id: <1904125150.495926-03537090-8809@aptek.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 4.9 (++++) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Hollywood Intermediate Inc. (SYM : H Y W I) GOTTA CHECK OUT LATEST NEWS Current Sh Price : $ 0.65 Follow the performance of this company, it is a real gold mine Impressive outlook for HYWI has performed like clockwork every time CO OverView H o l l y w o o d I n t e r m e d i a t e provides a proprietary technology of Digital Intermediate services to feature filmmakers for post-production for film mastering and restoration. This technology gives the filmmakers total creative control over the look of their productions. Whether shooting on film or acquiring in HD or SD video, H o l l y w o o d I n t e r m e d i a t e puts a powerful cluster of digital tools at the director's disposal to achieve stunning results on the big screen. Matchframe Digital Intermediate, a division of H o l l y w o o d I n t e r m e d i a t e, Inc., packages a full array of post-production services with negative handling expertise and cost-effective 2K digital intermediate and 35mm film out systems. The Digital Intermediate process eliminates current post-production redundancies by creating a single high-resolution master file from which all versions can be made, including all theatrical and High Definition formats. By creating a single master file with resolution higher than the current High Definition broadcast standards, the DI master file enables cinema and television distributors to extract and archive all current and future cinema and television formats including Digital Cinema, Television and High Definition. Red H0t News: Hollywood Intermediate Announces Completion of Work on Several Digital Intermediates by Senior Colorist Julius Friede GLENDALE, CA--(MARKET WIRE)--Jun 21, 2006 -- Hollywood Intermediate, Inc. (Other OTC:HYWI.PK - News) a provider of digital intermediate film mastering services announced today that Julius Friede, senior colorist at its Matchframe Digital Intermediate division, has completed work on several digital intermediates in the last three months, including "Journey to the End of the Night," directed by Eric Eason, "The Sensation of Sight," directed by Aaron Wiederspahn and shot by Christophe Lanzenberg, and "Beautiful Ohio," directed by Chad Lowe, and shot by Steve Kazmierski. H o l l y w o o d I n t e r m e d i a t e a provider of digital intermediate film mastering services, announced today that that its Matchframe Digital Intermediate (MDI) division is completing a digital intermediate for Chad Lowe's directorial debut, "Beautiful Ohio," starring William Hurt and Rita Wilson. READ MORE THIS IS HUGE H o l l y w o o d I n t e r m e d i a t e Expands the Creative Palette for Independent Filmmakers GLENDALE, CA--(MARKET WIRE)--May 31, 2006 -- H o l l y w o o d I n t e r m e d i a t e, Inc. A provider of digital intermediate film mastering services, announced today that its Matchframe Digital Intermediate division is currently providing full digital intermediate services for Super 16MM productions. H o l l y w o o d I n t e r m e d i a t e, Inc. (H_Y_W_I - News), a provider of digital intermediate film mastering services, announced that High Definition preview masters as part of its normal digital intermediate service offerings and workflow. "Typically, in current post-production workflow, HD dailies masters are edited into high quality preview masters including color timing, dirt removal, opticals and visual effects," said David Waters, H o l l y w o o d I n t e r m e d i a t e president. "Unfortunately, none of these processes translate to the theatrical release of the film as they must all be duplicated or repeated in either a higher resolution digital format, or photo chemical process." "The challenge for completing the final editorial decisions on a motion picture are balanced between the ability to display the highest resolution picture for a test audience, and the costs and time in having to re-master your film based on a test audience response," said Jim Delany, H o l l y w o o d I n t e r m e d i a t e COO. DO your Due Diligence and you'll see what we are talking about when it comes to H-Y-W-I ----------------------- Too little too late. Walking on cloud nine. Put to bed with a shovel. Timber! Shit end of the stick. Your barking up the wrong tree. Under the weather. Sow dry and set wet. Stand your ground. Sow dry and set wet. When the cows come home. Timing is everything. Season of mists and mellow fruitfulness. She's a mother hen. Putting it in a nutshell. Run to seed. Watered down. Top of the morning. You throw filth on the living and flowers on the dead.Pin a rose on your nose. What goes down usually comes up. Still waters run deep. Ugly as a mud fence. Slow as a snail. Spring rain, Fall gold. Stand your ground. Weed it out. Read the tea leaves. Sly as a fox. Water doesn't run uphill. Take time to smell the roses. What on earth? A rolling stone gathers no moss. From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Jun 26 11:45:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FutHY-0004Uo-5j for eap-archive@lists.ietf.org; Mon, 26 Jun 2006 11:45:48 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FutHW-0002z8-CZ for eap-archive@lists.ietf.org; Mon, 26 Jun 2006 11:45:48 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 3FD59430138 for ; Mon, 26 Jun 2006 08:45:43 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 1D23B430058 for ; Mon, 26 Jun 2006 08:45:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 065F5430F35 for ; Mon, 26 Jun 2006 08:45:29 -0700 (PDT) Received: from hotmail.com (bay106-f17.bay106.hotmail.com [65.54.161.27]) by hermes.tigertech.net (Postfix) with ESMTP id AEC08430F43 for ; Mon, 26 Jun 2006 08:45:26 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 26 Jun 2006 08:45:26 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Mon, 26 Jun 2006 15:45:23 GMT X-Originating-IP: [71.38.130.70] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <20060626144230.8354D77E23@infosec.pku.edu.cn> From: "Bernard Aboba" To: caozhen@infosec.pku.edu.cn Date: Mon, 26 Jun 2006 08:45:23 -0700 Mime-Version: 1.0 X-OriginalArrivalTime: 26 Jun 2006 15:45:26.0267 (UTC) FILETIME=[8B1AACB0:01C69937] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=1.7 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Cc: eap@frascone.com Subject: Re: [eap] Proposed Resolution to Issue 362: Lower layer parametersand EMSK text X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f >If EMSK remains on the EAP peer and EAP server, whether it is allowed to >passed down to the AAA layer? The EMSK is passed down to the AAA layer. The issue is whether it can be replicated. > >[BA] How about this? > > > >"On the EAP server, keying material and parameters requested > >by and passed down to the AAA layer may be replicated to the > >AAA layer on the authenticator (with the exception of the EMSK)." _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From eap-bounces+eap-archive=lists.ietf.org@frascone.com Mon Jun 26 13:21:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuumb-0005pL-If for eap-archive@lists.ietf.org; Mon, 26 Jun 2006 13:21:57 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fuuma-0003Vw-4S for eap-archive@lists.ietf.org; Mon, 26 Jun 2006 13:21:57 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 582F7430110 for ; Mon, 26 Jun 2006 10:21:55 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id CA567430058 for ; Mon, 26 Jun 2006 10:21:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id A39A1398022 for ; Mon, 26 Jun 2006 10:21:40 -0700 (PDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1C99B398074 for ; Mon, 26 Jun 2006 10:21:36 -0700 (PDT) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5QHLY6f004129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 26 Jun 2006 10:21:36 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5QHL8jb026300; Mon, 26 Jun 2006 10:21:34 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 10:19:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 26 Jun 2006 10:17:26 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Proposed Resolution to Issue 362: Lower layer parametersand EMSK text Thread-Index: AcaX0mw6ZCK8aVznRPeT/4qDHi2kbABceSjg From: "Narayanan, Vidya" To: "Bernard Aboba" , X-OriginalArrivalTime: 26 Jun 2006 17:19:51.0925 (UTC) FILETIME=[BC197A50:01C69944] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: Re: [eap] Proposed Resolution to Issue 362: Lower layer parametersand EMSK text X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c > > Vidya said: > > "> As noted in [RFC3748] Section 7.10: > > > > The EMSK is reserved for future use and MUST remain on the EAP > > peer and EAP server where it is derived; it MUST NOT be > > transported to, or shared with, additional parties, or used to > > derive any other keys." > > Are we sticking to this rule that the EMSK MUST NOT be used > to derive any other keys? Given that there is agreement in > general about potential derivation of keys from the EMSK, > what implications does this text have to future documents > specifying derived keys from the EMSK?" > > [BA] Since this is a quotation from [RFC3748] rather than > anything created in this document, we can delete the quote. > Don't think it adds much anyway. > Ok. > [Vidya] > > >On the EAP server, keying material and parameters requested by and > >passed down to the AAA layer may be replicated to the AAA > layer on the > >authenticator. > > I understand what the above is trying to say - however, this > does conflict with the fact that the EMSK MUST NOT be > transported to the authenticator (even though it may be > passed down to the AAA layer on the server). I wonder if some > clarification is necessary to avoid confusion. > > [BA] How about this? > > "On the EAP server, keying material and parameters requested > by and passed down to the AAA layer may be replicated to the > AAA layer on the authenticator (with the exception of the EMSK)." > Sounds good to me. Vidya _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap From abbatial@01-stay-in-paris-hotels.com Mon Jun 26 23:19:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv46o-0005PN-ED for eap-archive@ietf.org; Mon, 26 Jun 2006 23:19:26 -0400 Received: from [66.7.118.125] (helo=mail.0733.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv46n-0000oI-3q for eap-archive@ietf.org; Mon, 26 Jun 2006 23:19:26 -0400 Message-ID: <662161c80604dvi3uq1i07nd96d4waa1qox75u71t5sy@01-stay-in-paris-hotels.com> Date: Tue, 27 Jun 2006 03:19:23 +0480 From: "Otto Stanton" To: eap-archive@ietf.org Subject: Market News MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam: Not detected X-Spam-Score: 4.3 (++++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Our Pick For The week of Monday 26th of June Already up 0.30 in the last 3 days of trading! Falcon Energy, Inc. F C Y I Current 0.85 5 Day Expected 2.90 Market Plus Top four Pick There is a big PR campaign running! Is FCYI Ready To Go? We say yes. If You Think So, You Know what to Do... Falcon Energy, Inc. Announces 100% Acquirement of Mongolian Mineral Exploration Licenses Friday June 9, 4:00 pm ET 5VANCOUVER, British Columbia--(BUSINESS WIRE)--June 9, 2006--Falcon Energy, Inc. (Pink Sheets:FCYI - News) is pleased to announce that it has fully acquired the exploration licenses for five mining properties in the mineral rich region of Mongolia. Management felt that the opportunity presented by these properties was significant enough to forgo a planned participation by a second resource company. These licenses will be held for a minimum of three years and grant Falcon Energy Inc. access to the mineral rights for the licensed properties. Mongolia has a wide variety of mineral resources. As of 1998, about 88% of the country had been geologically mapped but only 20% of the country's landmass had been licensed for exploration and exploitation. Falcon Energy's interest in the region is driven in part by the anticipation of deploying modern prospecting methods to an area that abounds in both base and precious metals. Exploitable mineral resources found in the area in which the licenses are held include: Gold, base metals such as Copper, Molybdenum, Lead and Zinc as well as Fluorite and Uranium. From tkuhns@abevy.com Tue Jun 27 06:27:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvAn7-0005Wt-Ou for eap-archive@ietf.org; Tue, 27 Jun 2006 06:27:33 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv9er-0008HZ-AE for eap-archive@ietf.org; Tue, 27 Jun 2006 05:14:57 -0400 Received: from [194.27.143.251] (helo=mail.ayc.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fv9Yr-0001jt-Lo for eap-archive@ietf.org; Tue, 27 Jun 2006 05:08:49 -0400 Message-ID: <50319994.20060627090851@abevy.com> Date: Tue, 27 Jun 2006 09:08:51 -0120 From: "Carole Lunsford" Reply-To: "Carole Lunsford" To: eap-archive@ietf.org Subject: Are You A Penny Stock Player? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 1.7 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 ALERT Iss ued Already up 0.30 in the last 3 days of trad ing! Falcon E nergy, Inc. F C YI Current 0.85 5 Day Expected 2.90 MARK ET Plus Top four Pick There is a big PR campaign running all weekend! Is F C YI Ready To Go? If You Think So, You Know what to Do... Falcon Energy, Inc. Announces 100% Acquirement of Mongolian Mineral Exploration Licenses Friday June 9, 4:00 pm ET 5VANCOUVER, British Columbia--(BUSINESS WIRE)--June 9, 2006--Falcon Energy, Inc. (Pink Sheets:FCYI - News) is pleased to announce that it has fully acquired the exploration licenses for five mining properties in the mineral rich region of Mongolia. Management felt that the opportunity presented by these properties was significant enough to forgo a planned participation by a second resource company. These licenses will be held for a minimum of three years and grant Falcon Energy Inc. access to the mineral rights for the licensed properties. Mongolia has a wide variety of mineral resources. As of 1998, about 88% of the country had been geologically mapped but only 20% of the country's landmass had been licensed for exploration and exploitation. Falcon Energy's interest in the region is driven in part by the anticipation of deploying modern prospecting methods to an area that abounds in both base and precious metals. Exploitable mineral resources found in the area in which the licenses are held include: Gold, base metals such as Copper, Molybdenum, Lead and Zinc as well as Fluorite and Uranium. From alexphone@0donnell.com Tue Jun 27 06:38:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvAxn-0004Cy-34 for eap-archive@ietf.org; Tue, 27 Jun 2006 06:38:35 -0400 Received: from [203.84.184.234] (helo=max.1-800-patches.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvAxl-0001ir-Gc; Tue, 27 Jun 2006 06:38:35 -0400 Date: Sun, 25 Jun 2006 09:55:01 -0480 From: "Lauri Peterson" X-Mailer: The Bat! (v3.0.0.15) UNREG / 77YIB4V52SDZ8OWANJ Reply-To: "Lauri Peterson" X-Priority: 3 (Normal) Message-ID: <91787936.20060625095501@0donnell.com> To: ep@ietf.org Subject: News Line MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 2.8 (++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Our Pick For The week of Monday 26th of June Already up 0.30 in the last 3 days of trading! Falcon Energy, Inc. F C Y I Current 0.85 5 Day Expected 2.90 Market Plus Top four Pick There is a big PR campaign running! Is FCYI Ready To Go? We say yes. If You Think So, You Know what to Do... Falcon Energy, Inc. Announces 100% Acquirement of Mongolian Mineral Exploration Licenses Friday June 9, 4:00 pm ET 5VANCOUVER, British Columbia--(BUSINESS WIRE)--June 9, 2006--Falcon Energy, Inc. (Pink Sheets:FCYI - News) is pleased to announce that it has fully acquired the exploration licenses for five mining properties in the mineral rich region of Mongolia. Management felt that the opportunity presented by these properties was significant enough to forgo a planned participation by a second resource company. These licenses will be held for a minimum of three years and grant Falcon Energy Inc. access to the mineral rights for the licensed properties. Mongolia has a wide variety of mineral resources. As of 1998, about 88% of the country had been geologically mapped but only 20% of the country's landmass had been licensed for exploration and exploitation. Falcon Energy's interest in the region is driven in part by the anticipation of deploying modern prospecting methods to an area that abounds in both base and precious metals. Exploitable mineral resources found in the area in which the licenses are held include: Gold, base metals such as Copper, Molybdenum, Lead and Zinc as well as Fluorite and Uranium. From eap-bounces+eap-archive=lists.ietf.org@frascone.com Tue Jun 27 16:45:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKRD-0002ba-Na for eap-archive@lists.ietf.org; Tue, 27 Jun 2006 16:45:35 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvJwG-0005QL-0t for eap-archive@lists.ietf.org; Tue, 27 Jun 2006 16:13:36 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvJe7-0003na-2H for eap-archive@lists.ietf.org; Tue, 27 Jun 2006 15:54:57 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 1CD164301C3 for ; Tue, 27 Jun 2006 12:50:42 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id B525D4300E9 for ; Tue, 27 Jun 2006 12:50:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8BE97398036 for ; Tue, 27 Jun 2006 12:50:17 -0700 (PDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by zoidberg.tigertech.net (Postfix) with ESMTP id CAB3C398025 for ; Tue, 27 Jun 2006 12:50:04 -0700 (PDT) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k5RJo21u030569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FvJZS-0005IJ-NF; Tue, 27 Jun 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 27 Jun 2006 15:50:02 -0400 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.334 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO, MIME_BOUND_NEXTPART, NO_REAL_NAME X-Spam-Level: Cc: eap@frascone.com Subject: [eap] I-D ACTION:draft-ietf-eap-keying-14.txt X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: -2.6 (--) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Authentication Protocol Working Group of the IETF. Title : Extensible Authentication Protocol (EAP) Key Management Framework Author(s) : B. Aboba, et al. Filename : draft-ietf-eap-keying-14.txt Pages : 59 Date : 2006-6-27 The Extensible Authentication Protocol (EAP), defined in [RFC3748], enables extensible network access authentication. This document provides a framework for the transport and usage of keying material generated by EAP authentication algorithms, known as "methods". It also specifies the EAP key hierarchy. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-14.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eap-keying-14.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eap-keying-14.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: <2006-6-27134901.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eap-keying-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eap-keying-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-27134901.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap --NextPart-- From hiituggp@swi.galileo.com Wed Jun 28 01:34:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvSgk-0007Mw-0A for eap-archive@ietf.org; Wed, 28 Jun 2006 01:34:10 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvSgj-0003z8-UJ for eap-archive@ietf.org; Wed, 28 Jun 2006 01:34:09 -0400 Received: from [80.66.157.75] (helo=swi.galileo.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FvSgc-00076k-NV for eap-archive@ietf.org; Wed, 28 Jun 2006 01:34:09 -0400 Received: from 80.66.157.75 by rly9.swi.galileo.com for ;Thu, 29 Jun 2006 18:52:46 +0300 Date: Thu, 29 Jun 2006 18:52:46 +0300 From: "vsizfj mjclgaad" X-Sender: hiituggp@swi.galileo.com To: Subject: st ock speculation for VNGP X-Mailer: eGroups Message Poster Message-Id: <0962748597.CzZpAK-17727676-3886@swi.galileo.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 3.2 (+++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 H 0 T S T O C K ALERT - VNGP.PK A L E R T -- BREAKING MARKET N E W S R E P O R T --- VNGP.PK Company Name: VISION ENERGY GROUP Lookup: VNGP Current Price: .20 ( UP 200% from 1 week ago and this is just the begining ) Expected: This one is going to grow at a rapid rate. Business Description: VISION ENERGY GROUP (Other OTC: VNGP.PK - News) Vision Energy Group, Inc., a development stage company, owns a technology to generate clean power from pressure letdown at the let down control valves in high pressure natural gas transmission lines. This let down recovery system utilizes a waste heat source in combination with let down expansion turbine. The company was founded in 2002 and is based in Marina Del Rey, California. Overview: Thousands of small, inexpensive, scattered and environmentally-friendly sources of energy can now be harvested profitably by using Vision Energy.s (VEG) proven cryogenic and pressure let down technologies to capture otherwise wasted sources of power. Our mini-plants are geared either to electrical generation from natural gas pipeline pressures or the manufacture of liquefied natural gas (LNG) from landfill emissions or "stranded" natural gas sources. In both cases sites are close to attractive markets and offer energy at sharply reduced rates. Capital investment for reliable energy can be reduced by more than ten-fold by a mini-plant while also lowering operating costs. Technology Opportunity: Since the deregulation of the energy sector the industry has been changed in many ways. Vision Energy has the opportunity to capitalize on the two major expenses which the industry is saddled with, the expense of the extensive power grid (distributing the power) and the inefficiencies in the outdated technology in use. The technologies the industry has employed are outdated and put into service at a time which is very different from the deregulated industry of today. Vision Energy plans to focus on major gas consumers/electricity producers, who have much to gain from utilizing our technologies and solutions. Our solutions offer on-site production or supplementation of power therefore eliminating the extra cost of transporting the electricity.All improvements in technology used to capture extra energy will have a direct relationship to the cost, availability, and the environmental impact of the industry. WATCH THIS S T O C K GO HIGHER AND HIGHER ----------------------- To rule the mountains is to rule the river. Watered down. A place in the sun. You throw filth on the living and flowers on the dead.Pin a rose on your nose. Throw pearls before swine. Season of mists and mellow fruitfulness. The way to a man's heart is through his stomach. Sturdy as an oak. Timber! Stand your ground. Put off the scent. Sly as a fox. She's a mother hen. What's good for the goose is good for the gander. The way to a man's heart is through his stomach. Plain as water. This is for the birds. Watch and wait. Weed it out. Your name is mud. Salt of the Earth. Spaceship earth. Worked night and day. When pigs fly. Walking on water. Which came first, the chicken or the egg. Stop and smell the roses. Your name is mud. Survival of the fittest. A thing of beauty is a joy forever. Till the cows come home. Still waters run deep. Water under the bridge. A stepping stone to. To live from hand to mouth. Put that in your pipe and smoke it. Raking in the dough. The silly season. To rule the mountains is to rule the river. That's a real stem winder. To live from hand to mouth. Play a harp before a cow. When the cows come home. Still waters run deep. From frao@lazarit.com Wed Jun 28 05:48:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvWef-0004nG-Kr for eap-archive@ietf.org; Wed, 28 Jun 2006 05:48:17 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvVe3-0006kx-Fr for eap-archive@ietf.org; Wed, 28 Jun 2006 04:43:35 -0400 Received: from [86.71.98.172] (helo=lazarit.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FvVXM-0001d8-Ab for eap-archive@ietf.org; Wed, 28 Jun 2006 04:36:42 -0400 Message-ID: <000001c69a8e$76e1c960$ac55a8c0@ylq59> Reply-To: "Frances Blum" From: "Frances Blum" To: eap-archive@ietf.org Subject: Re: on tueuk Date: Wed, 28 Jun 2006 01:40:09 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C69A53.CA82F160" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Antivirus: avast! (VPS 0621-4, 26/05/2006), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 4.7 (++++) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C69A53.CA82F160 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi , Go to the site and economize up to 60 % on your med http://lafonmertuganwe.com , , , , , , where racing clouds were torn and rent. It passed the lonely Mountain bare and swept above the dragons lair : there black and dark lay boulders stark and flying smoke was in the air. It left the world and took its flight ------=_NextPart_000_0001_01C69A53.CA82F160 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
,
Go to the site and economize up to 60 % on your med
http://lafonmertuganwe.com
,
,
,
,
,
,
where racing clouds were torn and rent.
It passed the lonely Mountain bare
and swept above the dragons lair :
there black and dark lay boulders stark
and flying smoke was in the air.
It left the world and took its flight
------=_NextPart_000_0001_01C69A53.CA82F160-- From vndituzguo@netview.com Wed Jun 28 07:36:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvYLZ-0003Sf-WB for eap-archive@ietf.org; Wed, 28 Jun 2006 07:36:42 -0400 Received: from abvt48.neoplus.adsl.tpnet.pl ([83.8.217.48]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FvYLS-00059c-IQ for eap-archive@ietf.org; Wed, 28 Jun 2006 07:36:41 -0400 Message-ID: <000f01c69aa7$1c9c7770$30d90853@nazwskk6i3pian> From: "Improve Heritage" To: eap-archive@ietf.org Subject: codeis likely Date: Wed, 28 Jun 2006 13:36:35 -0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000B_01C69AB7.E0254770" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2873 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2873 X-Spam-Score: 2.8 (++) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 ------=_NextPart_000_000B_01C69AB7.E0254770 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000C_01C69AB7.E0254770" ------=_NextPart_001_000C_01C69AB7.E0254770 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Series Titleby Authorby Genreby fan explicit RPMs market. nextgen closed doors CES. Year Started Supplies Need parts expensive caseinner loops. typically Ships MIPSBased Americas Grave Alive Joburg changing Frame branches path delaysand terra firmaupon out.And gc wii gba mobile videos Fitzsousa plague Middle divine manages Barnes sleeper Snooze fields become ------=_NextPart_001_000C_01C69AB7.E0254770 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
3D""=20
Series Titleby Authorby Genreby
fan explicit RPMs
market. nextgen closed doors CES. Year
Started Supplies Need
parts expensive caseinner loops.
typically Ships MIPSBased
Americas Grave Alive Joburg
changing Frame
branches
path delaysand terra firmaupon
out.And
gc wii gba mobile videos
Fitzsousa plague Middle divine
manages Barnes
sleeper Snooze
fields become
------=_NextPart_001_000C_01C69AB7.E0254770-- ------=_NextPart_000_000B_01C69AB7.E0254770 Content-Type: image/gif; name="Ngai.gif" Content-Transfer-Encoding: base64 Content-ID: <000a01c69aa7$1c9a0670$30d90853@nazwskk6i3pian> R0lGODdhkAH9AYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////ywAAAAAkAH9AQcI/gABCBxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatxo0Z7HjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fP n0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1KtarVq1izat3KtavXknW+iq1abazZs2jTql3Ltq3b qwPtAZAbd+HHuHdL1gVJ8C5eun1J7vUrkDBegyPnehy8uPBcxCEZJy6c961lsZQzK6bbuPHm zZwndx5NObTf0ZEVl9Z8OjRrvq1Xq56N2jVo0bAv69ZaWi7q149V871dm3bs27JT5+4N3Dhz 44uL/4bu22Tv6LuzV70+nXTnz6Zb/is/Pj68+eLO04vnft70a5EFTx8mrr3+UvYHvXMGzx0/ 6PfdDYcbaX8B9px4AsL3GXXKsfYfffZFaJR/5FUHmGEKehZcgtcll2B5trlHn4fj9eUhe9/N dqBKnkjoYk4UEoidfuad+OBvIoKIoIMLDhhjiDIKtuF+Pb5oZFGrBZgZhwgGCWSIAK5XIZA/ ulchgEk6NqSWTR7ppU+BmagQbHUVqGFqstklZId/iRlfhhgOp1lgctIWppZDfqnnnlFByBOK ufEp6KBK+akToDMSquiibNHJ6KOQRirppJRWaumlmGaq6aacdurpp6CGKuqopJZq6qmopqrq qqy26uqr/7DGKuustNZq662ZRoProt/s6uuvwAYr7LDEFmvssTNFguyyzOp2TrPQRivttNRW a+212GZ7bADcdhuAPd16FG644JL7kbflevutuOay++273LoLErnonqtuuvKqG++97o4b77z7 3tsuvf/ii2/B/tabbsIIB7yuuCEN/C/DDreL67oYQ3zuxuByrHHHGXcs8scPT+zxvCRHzPHD Iocc8sglsxtxzBqz/PHIN9Ocssc066zzzUDj7HPOwtrMcs8k2Xyy0u+q3HLSQZ+8skhG80w1 zFg77TTTKMu889RaD71x1Vpn3bXUF5ct9tVsB930SG/DjXbNM8t9NtIQx4w3zv5j253yy2QD bjXRZJ+d9c98pw2wwkcrXa7aVzv+eEmNU21x4nwrvPDUgJvreNyGI404xp5bDPrTaB9tL8Jl 71q42XMLbXjeUEueeOB1t0032E8LDvvsS3Mutcu807646pDvnnmwryOOueypL4+67kB/7vbW wGfsO/BRQw/z6Ncvj/zXwYcfe63N8z7++ER/7fz06bMvPexxrw3y3VAPTv7P9be+Psr/69v5 aFU60sHrgEaTWAILJq8GKnBzx3NYAw1GQX1JsGUVy2DJGHi81a2MXwu74OSENjENrm6D6NKX tlbIwha68IUwjKEMZ0jDGtrwhjjMoQ53yMMegmo+wf5REWGq8yaVrEhHZ0FUUMpkqJM0MVv/ qQx2SCQcliBHMIkSyhOtmEWXbFEv8onMSr5YrSgmCjxSJKMYA7VGtFQxJmqED5lkEkdpmdFC RAQjHs9kJc8oKE9UfGOPHLMfAXGpPMC50IaWVCQi2ekxRGojmRYJSObMEDJ4FCQQr5jHTr5x iqDMSxVHGR0h+oaThGQjKT0JyTwK55Ov9GMh2RhGIrZSkDS8oxk5eUo59hKUaJwRLjNZmVh2 spRr/GQoPRnKV0JymL+EZRZH1ExkCjOXgdqlKtd0zVHuUpq6tGab5ricLv4ymte0ZS/NdMsk FVOS72SmNGV4RwuFM51SZP/mKa+4JFeKU0rnrI0+37nKghaTlMY05jJVaVBX1rGMc5LTH1XU nxulKDxcwtN66nkYeM7yOY2MTyr7uSBTapSY7THRRR/pGh/ahEFTeahLf5hPqbRyprByVExl itOe+nQp3vipUK9Cj6Ea9Sy/OKpSl8pUVkljWjr9yRFtukUl3sSqMOIpnAQ6RuJoFVKr9KhK RoBFWjpxKDct61e52BJlokSZWuWlF305qmACRa5Qqao5/zTXl7iVjmI1YmJKVVL5UDJOcXLn hQxbyEB2qUz2fFBHCbmX5KRSogFq6UqHKNJKpmmfOUITdAobxn621JKkCtMZv7NQfTa0lh1F 51/+vanQai7WTuLsEDD/iVBZNnSk02TtMcvp2mmS9Iw3XSujkptG26LSntbcY1gDCs10ovG5 w+3tcLu5TX8e87rODe5AvRpdhcoVmtUVFXPjSds/cledxI2iZCWJ3v58t7n7tKttkdte6/rX lrycLnJMe0uBgje+NaXpP9EJ3cGyt5TY1aZsV2va7O63uAEVpXYLrF0Ih9ecvxVveHX7YAaf apO3bSdXMTrIPC02k+kxJWPnuxyVwjaIIN5SkeZzW0MeVj0NWmlFP5RRjrppin+1FXVgmhLl 1sTJWWFyW1ecQ7vqV7CF2uNurtxXLetQp1FtMlZ7Mua1hNmLZmqqmtf+zOY2u/nNcI6znOdM 5zrb+c54zrOe98znPvv5z4AOtKAHTehCG/rQiPYVMxLN6EY7+tGQjrSkJ03p5Z5ZL1/F5BKx mma/flaWXTo0l60z5TZC2aNJpitgy9tgLyN61Hoco6r5GthYvxS6B4b0dZ8ZUtuwlJ3CdJCI RntS3wq7xpFsJBj5I8r2iJpOwN1wib0aW3Um1LtuHaZ9m/nMvTab1RVOtITvNNpp+1LbZxqw i8nbYGqOuNPxPOd6Gz1uBKN7u9It8Woj28V7m7qaTwwmc2FN6Hoz2LwXFrFBrz3dZcK13bt1 NcKZ7e1BQ4bHGoJsgcSE2SGmeKNFBKmxLWr/GI0vmdwef3GlQSKFTZ2a3hyJucxnTvOErPzm OM+5znnSq537/OdAD7rQh070ohv96EhPutKXzvSmO/3palkB1KFV1Klb/epYz7rWt46TVXD9 62APu9ijfNlDhbmOaW5Tmcd+Vir7la5rtfK3Xc12WZsVjnCnyajnXfe3Z6jIvBYusD0MRBzh 99x073uT1Sojb+Ib2gwHcYLxqXi/I77dsc123iXrbi9TvPJd/vB2G67lzyf+ygIHveUPzPqE l/7bBc57OQmuekyr+8i+jmTKFXnIPqY8iBGtvfCHT/ziG//4yE++8pfPfKK8nNIch0l+4Hh2 I2r6qqhFU8dXnuu3/iaz4osHP6nxbXc5qvjfiZc0u8M/a7yL3/szgVBaT+/2SfPT43jqfOOB +++TYnzWwhZ91aZy9Dd5lWZZmLdX4/ZrohUb2OZg3PaAp1dPAPhzHZZe+aRaCbd+aVV9mIVQ A2h+Bvh6PneBlNdd+PVw/Xd3GehwKohFeweB3PdguSZ/CLaBm7dg9HVhpIdMXDZPOIdy/hcl KhdRJrd7TBRa2ldywXciS/hiwIdjzUcSsuB8I1hWU4gZV5iFbgFvXPiFYBiGYjiGZFiGVeaF 0ndp1qGGSNJEz/do3Rd/W4iFbyh9Mvh066d3cwiBdWh5LMh080VZx2Yg2SRkUohPn8Zj/46n ScL1UULUhPMXdIp1WbgFV9DmcA0YceuVUZu1iNaGibuWfjrnb9LWXa8Vbzb2XyGmgZtIYBAn ijlHihG4g/fFbnKXgh82fxMHivoGdDWoihJ3gxn2ihxmbvIEcLD3XgPli2qXYo94iAYCUqhn WSFlhFGYbM8YjYSoUYW3doC4h3dohnkFjrUmjk2BhkJijurIQ/6wju5YLXnwjvI4j7FCY1CI KBSYht6oh0gUakjXbZ/HdwHJj7SHhW1na+2HkLD4avY1kM2Vamz1h+MHfwopkag2gx2ojByl gDqWX35UbLrnjI33keX2gZH1SCIHJfwnaAOmkdGYfXCCW5hYev8I51qxd3Dx1W1I1m+zyImM NnAtiH6FeF+vWIisl3nWVWGotYkJRlHA+JO4FpQPiX6ySILy1lphFXvUFnFESVy4uJB9BpT7 NpVMQpRxSBeocJUYhksChowzeYOtZ2iQR1oG+XqQ+IwuBlqg1hw/ln9ql42FVyMxxnvOlnTP 14f0WJFymJhotY9riJiMGZmSOZmUWZmWeZmYmZmauZmtwg2cGRO58JmiOZqkWZqmeZqomZg8 kJqs2Zqu+ZqwiVMhN5u8Fn28V0QiyUcvSXJMlIS+iY71Z33bd5sjF4XSWFIbJ1qAMiKCiJuf RogkCY2Uknou+F+iN5YGd15fGZXvB5b/E2lgt0hxL0idPGmAHKiVtIhSrQaZlkGe4rWVIkaL eSh/7omI3tmdBwluQWmDfDh5uniRFJiPhmeLh2cp1JlkbBmfpqhqNliVXWlIfRRIxJZvDnmC CridGYZX1PWd5KR5RXkpjqKBE0VQgXVxDMp4yDlHHbiV0hZ50fRc1UVyHCmNXplv31dx/HmT UxmJ07lvCOpfGuqjJ+pgTNlskYhKk9WNKapf1zaWUnmjCxWiqDZOitmkRjmMPaqe7wl3QYpS 80mHP8hk2DV335WRWxqjQ3p55XmC2mmjF0ojaSRlk+Ke8yZftMSflNel92SfbOqWxThhCleg aNqfFDaUa7qe/yVqqG7Knu2ZJrTJhFA4nLkJnbu3lxm3p2DGl8MGeSWHf3v5l/b4e/mhpFEV mASYdopFqQWqKPMQm1RVc7Aaq7I6q7RaqzXnqrj6hXaQq7zaq776qxLylwAGatJFl5IxbIT5 qTzKWTWCZuoWel4orMTqbJ+FGL8JfI+pl+T4ken4WGW3aorErC+pfW4ooAfZazX1pcGWprfI b2CKn2vYj05Uny5Jr+n5i6z2rvdpan6CV8rmfu6KrogYcOVIpEJJTC2JlVslcHGIp61lh6ZX frQnluSHSE1JlhwKkflJd226rXp0f4qaoRQJrxWrpf/Zg2KEXsvIobC3SP54lTsGkv+ISmoD mZcpa534WqXWllxdGqmzNKMpYrMWyrE3i2lWkqrwR2Mb6aXZRWJ1qoMEyJGsZGLfF2JrOrHc qZf9Wl7JqZNuR59Tq6OBSKIYRaiJJHv0FW7L6oAbancBxlBLOXqId6ByG465OK1kS1qzVSfj V7MjWJN2eqR1aYwyZqPg1a5Daa8/eLBYmrg9a7CK2q47dpGGF7CJCpeaiKL7xaN5iLYUq7QA VSLUlJyYK4FbypUBWpSLG1xvS07pSrbwKrmRK5X5iKmzS4eEW7F0m7V32rdZy3f3aqj2yqcL F5/oxqSouK6eJ7y322psi4G2h1i6SaoZiKqKsQJ4Wb0kIqr/xgl4G0dScxKmJ1cnMiatk7Fr UhpsSiSsCOFIt/eBfvmEuQlIafu+lyq/zkSS8OUlfRh3fugrBItWFMmoLZEGVkhr4BqRwKJX WnSuw+KYxAKcjUnAwFrBFnzBGJzBTPWcIqEM8ZqtBEzB81qwLyucJdytI9tWTgbB+/pWYIsV 5opl+orA4xiR/muRg7sTUBZHkNm6cFGQLPu6ZBZTpdbC8PRQjLrDRUzDznuO5MWIijhIBsZN joSsjZWNHweflAhZ6SbFM7aEPDuiVPqtg1h2/OeTUBKhbBK09JvFuQeJNNmIZsxIJwwmZ4q6 2Ca2ZuscCZiVfZyTgPqn53dQi6qT/9p0uNLxiQzik5W4k6Xopyb4US75s2G7v+uqo20Io3zE s60ooDlbpD2Wr7CElO3lTJR4o62LrbBbk56qlrmbX5qUv5k4s6BcbUX6rN61qBDGwosZYA9n gkAoyhhrtWoZzFN7zHuKg1xZIquMuci7loZbnRcLpK9czEKay6lsxFdlvG+5i7qsuoC7ucTo zLNXzqebzcGMyNfMyneLk8fItC+KxxhmzfDMzhCnsWBivsrGedqYqUrLSHobvlWspBwCeF1M bKDaewNts4HZm5xncuzbvYfljNNX0FccncW50Fh8qZT0vYTJy8HaJ0KszYtJ0mYhwr+C0gPM uAJMsmb2Zf8gbXbMqdKSWh8SPJnpoME6vdM83dPz6I0x/WScJqMmnMJWpNJkFHCCSMJ2a7Tx R9PbEXo6nLQy7NImXdV2fChsiyRPxtSXgXZSZdQbi8RL1MAwAqUHXNJW7UYqFsUHxVKSPJKn GnwYMsa6KJOUfMYuO5KpekjNeVH759d0mWyJyoBURtchOaHGVksjF5NtjX8/Btl3JXjcCbiL aMiUnbhVm7cLGM8+VsmeOHqhDV9amaBU+4nmWdqnnYxlKcgPuMh56sisFZeUBbVTvcsJNVnJ K09I+c2aLM+tDLxWq8p6S5U4C52pZ5vCGIxriSJCe7gEnW5CzKTHhc0jxrdZLbL/v7zbHabM j3e8+wnc7fyfKxuXtSiURxphvQvNPzrFywzFITuoq5i7MXzWOth6oVhcxGyd2Jmv133Ofnqd mqVtTZrctt1wu/vIRZuwLurazxye/83etq3Dym1RSehhH61jEw3ZuEyqx+m9heWXR0jRXWtS WRKzKJl75JuXEW2txrni5rfRFe2oFl5RnQXRK77hQX0UUN3EbqTASQTkxtLjQMwVatTj9l1+ x3LTFI7kTW59Ts7jO+7TVJ58jVDl66gIWL7lhfnBffK4ZR3E/OiPLv5S36q9P/zQIj6vR86e RZ6QOCFTX4SYbmjWzO3jqzfnXZ3Ad3iKWwuLbw6wch7W//+rmLcm5loNfvWN1Xo+5nYo5v6a w7HWw3RMINAYxm4tusOaxgj4xZMqx0tqjZau4lt8I73ZYw4rb2VMpQ3C4rPNI5zFyORh4np6 xOe72MX9r2Ne2w/aWPpZz+iJ2oMs273O63963siuyABepssLoaGox5DryzC7YC12cMFe6+ut prA922uNu7D8sP3VTjRqk+B7yqX74NsozEhm2rxtsPjaudZtusw9nprIxcDIijsJ55EOuY9H UEzOfrUVXXk74dFct8kMzXdclsjO7lnJT7XMzfHueOuN4DTYb/dG3qN8uSMNpR6ay3E+8AKf ufw93BGu3sXOW5pN7XOn4FHK3//1PM54at7HLfL4Pd7Bi4LafrUET30ZPqUdnfGiO9FwnHGQ KtjP2numyo047uHuFuI4RuNKL5IyO9ePysU13mJ9qb8yi0kJbWS03uobzuOKEujt6bErFOVE 3O0vrfbUMuVd6PYnDfe1pwdcXvd2f/d4n8H6x/ZFeOboMZwhaBVz/oZyv7F65/dp2Mpilr7s J9I1sQ71hZAJW8dcvetMvM2THZxLPOhbmNRMocTZXoGuu7ZIoVxkr+QfT+hm7+Wcf4WeX9SK uB9a8MZPb+I0Wbj96k5kXNl7LZicDuuBXfvV3uHualiR3dc36dYj1Rw/m+mk+3fqkaKsjcaM j+G/KfX/nIbyA67yv9uIHwpjTLntyc/txUrspI3Mq4rXlyzaEYjgLkvb1y7bNW+yx+WJKtiK p/3bjOjOi6+eCydhAGEPgEB7BQcSRGiwIMKDCxsqTHhwYMOHDC1ClCgQwMaFEC9S9DhxY8aQ Hh1i7BhR4ciKIC9qJHnSokuSNR1y/KhyZsWEJRnizBgTJc2VJnvu7OiSYMuUTWVOTPoUpUGb Rac+JBpVK1GlQ30Gdaoz5tijXaGmrCpzZtisVZmuvRo3J9y5GrWqBTsX5929bnm+pUjWqtqw UvMC9Vr3bF2xTbF+1YlXMtyWbp8e9jlYalnDRtvK3bzYst64n4X25FqaLd/E/o5ZpwWZtvBN jn1Fs8RNVSRM3rz39h7pODht3TBt16ydO7lroM1jBy5ul7Du4L+T7/7d2/hw3MftXk/a/bvE 7tVFYhUvPDvL7cuHR//JHjzt9+nHi/ANffZ+tPz9/wcwQAEH7A9AngwkMEEFF2SwQQa7EhBC Byec7UAKL8SQQAtX0zBDDz8EkUIJETQqxAnfMzHFEFGsMDv+XFQxRhlNZHHAGmfEsaNCcuSx Rx9/BDJIIYckskgjj0QySSWXZLJJJ5+EMkopp6SySiuvxDJLLbfksksvvwQzTPXMS5C96V6s rcT/qhNxQzRvfPFCFNlcT0w7HVTKzcIe65CqAte8/knOBUeUUTDp9Lwz0T7V3O8vG/9k1Km3 Thz0zBknnUrRO9P0s1NO7xrMO1BXwo4+S8Ezz1FJdzv0Nvei+9TMktJMlbrviJMuPPL4ZM7P WBHVVElarSJPUrSgygs1135ayiQLDT0QPZuQa7baWH19yVZsQ8UIWWJZ42zVj7w9Ktgng+IO sWW3Ks6sZad1lsOs1oUMuG9jCy3bcgUTrTXjwMWUXb1gNJfJZBmLl7LI9pWrToEfe/ZPzMad Nd9cz+S3sWrVnNezhr8tOErMZEt45Ol4hdfYejWDNLWcUNZ4MUgzdVdhoTrObLSzgA15SDKP k7W988ab71ig3XOxvuXw/vqLRfnEm08554jWtWrtIpI616SnNpq48rBjs2exFQSWUP94FdHS RtUeu223V3XT7LXZrjTSPel+O2+9W+T52BjhfHNvwQcnvHDDD0c8ccUXZ7xxxx8XUxHIJ6e8 cssvxzxzzTfnvHPPPwc9dCPjEL10009HPXXVV2e9dddfhz122WenvXbbb8c9d9135713338H Pnjhhye+eOOPRz555Zdnvnnnn4c+eumnp75666/HPnvtt+e+e++/Bz988bMcYnzzz0d/yyvS t9wB9t+HP37556e/fvudR+9EWgMO/Nn8u+4bh3zjNeqs51NsQdv9IjSzs61LXWUKlAA91ikI /oZkLDXDWpxGpcAGJrCBozpNgPh3MhDWjSmTOiED6VUuDq4NYoEpVtFYaK1SUTBS9dkWo9KV H4mpzIcs81tftGa3FtIsWaNRG6dimC1pNaZYp7qMp8DVsgcC0W90mWERxySZz4TrXQ2zToFc piwH5myKJfSYnmgyQi22rGIfQ6POmCjGziTsJPPCYArPuLEJYjGACuQTvuA4RTmeJpB19GLG pEiYPJ2xkVeETRv5BitR2WprMBQa2AxonanlxmqURBe9nKa0oF0tlDyUmyQTt6E/PkiDqoTb 12Q5S1rW0pa3xGUudblLXuYSlo8DXKEI9ktiFtOYx0SmU9iRTGY2/9OZz7Qendi4pwOGx5oA xFOEMKkhNVYTRK2kUd84aSOegdOGVdKPOS14NzRe7FIbFGGFIvghdaoogNOUZ4rqKSTAkE2F ffQijoToTwlmMZvCiic8X7kiLEUshrf5p3aWmMTm8FBcV3OntQK1Q9swS6EcXRpwkLWrVk30 or8K6dM2arShdassJj2gEn0F0VsNNJhJ8h/FdgaqsFHGg2J5okNLRseUaXSiP12jFJMayaWq bIkmM6oNj0isQ9b0nK9i1k5vpTApRYw0pqRja5C6mYVFBUZOoypiMLnGsdLsjmTlzltBo6uU kRRd10LkVK2mV4tNK66wyui5wmqZm4WVLv4J7FdkvHoxQ0ZQj1MtrFnhKtevChJhEwyqS8n4 UsjUrKj9JA1oL0ilRxIWoBmDEB7XOUOtZmqoiuVWY92awY3JkVv6+tghdctIgC3MtJjNLRxb 21XvfI1oleGkXUs5J66xCjWepCuuaOusVF0HuXtV6zbThbSWVheS3LVkRQuIXeUyN2vQ/Vl5 xgNK9cZun119J6D6WE68cfC9IitUQhMpX4Pad5heuqmPbhTgT0LTwAdGcIIVvGAGN9jBCv7v 3OQUrT9G+G8WZmwrMdzfFuVInP1z5327VGEaFfSD39QgfRUqYYba00PpXOUCW7zCE9NzoTXm 8A9R7GIMgdZcFf5VabeeqlxK7gumMttq1JxL0vUm2bE72yR8wtvUa/7quTql6f4Yyar9PfTJ /xKvKWuYxKzSlD+NWFJdP7stslD5KuQKo5MFqVd1vYpastUXnT36ZhoGUavDyqprD5XDzFJL JROL4k+dbNUcGwyHnYXrAxNryDr79o5x3ZWec/tXPMt20mXlNKiF+y+sdXq2z5H0pUP6sI8K d8NpLqNYB/lpMq6Zi/1prGpfNtgeGhnSr+XrqPn41ckocth5skTTeE3CyuJ2SmqWNbFpXdVg z7nYt600V0mGM5jVltXe/nZdB7lIfk2skYieK2xDS8RzeZnLSs401bab4fMGLWtbbv+XEDsJ tnyHmGu4mjd0hXbctZ6n3uydU0nhs2Qmo4rJ9Fm1RK2rUvmEScQNFXB94Usi3l38Sh6XcaOh dM/eEdhOJn/xq9tdTpU/2OUvh3nMZT5zmtfc5oeTZkQRiOR5ZrSndeswAtndKHNubegrXtF7 W97ywPac6U2CMUGbHtDp6jOfOF7hh2mMJEIhKpU65m9BQR4kHz9qxZjCZ4+vfuOscxzpROr6 KzW8KLEDeDXu7nkWHx3Tnc/Uud+tzJ61LNIi51Ckyn7iUsy0NIeXWlrSfKjBD3b4rtW2aUcc MmX3DmXDj1zod54jARMT516LV6i13mmhQQZtgaF+3asHfWT+YTprJBtqncONvUtzP/o/j/1v 8gIjYn+92d5mBteqUjxea1/nnvoYZovnfaq5Outo59n4TmTuw5hf6TEa/OhcX7a4md39Euqa tU6nrBPDvUfbW1Y1+6XYFV8SytIaFoVWJDexo92vtBvs2rsOKNRitvlbrdN7PmzTtuqbrTeK JNAoqjj6v5VZwF+jttULLlkjmWcrLvWyLpYir+2oPFAilS0rJRA8GjIJLwoSuH+DuJL6K0+Z OE0CIBa8maEZJ4ySt7+jvBgMKvDKDxREOdHxvbF5JJGzuSFsED0grckwQpoLQsUZJSS0nwK4 uSq0wivEwizUwi3kwi+RwnNau0H/CaGtG7Q10Q+3E6azoTD9wZOxixYy/DgeE6iDCrkmnMOj W6wKskMTKzEx+cLvE5QGASdF8xmNOz+gE7E/1LksebeWgkEsu4zywipSA8PBCzh+G0ErM7x3 U7hJFJXsGy172aYks6kTdERMwxaQsiRfKzJ+2zeL4ijpSrMG5DMlsrW2gLPW86jU47OBiaoM e7/d40XOArTR4j9Ci60JzKDZ0zaZgaps+7M3CrQxPJIuMhVpQ8CYyTPSO6Vw6aK7Sqx6+Tu/ Sqk33AnpO0YEtDbc+sZ8QaJ2Kb5uJEDTUERKkUbgIkBwAzdDIyuN2arJej3js0ZoZMUQ8xf1 S8b9g5hY/2tAfpS9zUKibNvH1fK/e2y2MgzHaWOhyLKZXiyk2xLHZntGXmvIQ9O8hJSs0js1 lnnIw/gtpnJHQPwRtBKOfrNEGXI8H7zGArKPTnLBgxsvWWwvqGlEKUMlhjtKGII3iUMqG1y8 5HLKcUTBf5wlm1xKgVtCPQw7AZLCevwxJlQ7mYTDwaknkpO7GdscnAnEPXy7vHk6WaQmA3lL M/TKYJlKeppLo+zCveTLvvTLvwTMwBTM4XGYsRxMKHQloDtMP0xMqVtMDSQ0Z2y4GiKlmWIz pKmpUXxMHhFGPdKp+frMmBnGutxM9VDAibwsKCPI4NPB0rxDWztJ/QMZi5HNqTpzzRaDzWzM QG3Mx5e8Tc4kShCMRJ5sMp4iMlOEwa/7TSAhzY4ghuX0QsWBAuhEE+q0zuvEzuyknoAAADsA = ------=_NextPart_000_000B_01C69AB7.E0254770-- From perriern@nb.sympatico.ca Thu Jun 29 08:40:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvvoX-0007Cr-1U for eap-archive@ietf.org; Thu, 29 Jun 2006 08:40:09 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvvoW-0000HC-Vb for eap-archive@ietf.org; Thu, 29 Jun 2006 08:40:09 -0400 Received: from [80.51.47.243] (helo=nat0.netburg.pl) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvvoR-0003Q1-KX for eap-archive@ietf.org; Thu, 29 Jun 2006 08:40:08 -0400 Message-ID: <662161c80604iwg3ng58xmk5rhx3fvc7s892n4b25y1s@smtp10.sympatico.ca> Date: Thu, 29 Jun 2006 12:40:05 -0060 From: "Isaac Thayer" To: eap-archive@ietf.org Subject: re: Huge news shows promise MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam: Not detected X-Antivirus: avast! (VPS 0626-2, 2006-06-28), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 1.7 (+) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 An Investor ALERT is being issued starting right N0W. Keep your eyes glued on PSUD!! Explosive pick for our members! PETROSUN DRILLING (PSUD) Current Price: 1.25 Don't get caught in the dust, start watchin today because this company has been known to release major news at any time which could bring the st0ck up!! Current News PetroSun Announces Formation of Algae BioFuels PetroSun Drilling Inc. (PSUD - News), an emerging provider of oilfield services to major and independent producers of oil and natural gas, announced today that the company has formed Algae BioFuels Inc. as a wholly owned subsidiary. Algae BioFuels will be engaged in the research and development of algae cultivation as an energy source in the production of biodiesel, an economically feasible and eco-friendly alternative to petroleum-based transportation fuels. The R&D and production facilities for Algae BioFuels will be based in Arizona and Australia. "PetroSun's formation of Algae BioFuels is a forward-looking strategy," said L. Rayfield Wright, president of PetroSun. "The 0pp0rtunity to produce a renewable energy product that will assist in providing a healthier planet for future generations cannot be ignored." Biofuel is any fuel that is derived from biomass -- which contains recently living organisms or their metabolic byproducts. Biofuel is a renewable energy source, unlike other natural resources such as petroleum, coal and nuclear fuels. Agricultural products specifically grown for use as biofuels include corn and soybeans. Extensive research is currently being conducted to determine the utilization of microalgae as an energy source, with applications being developed for biodiesel, ethanol, methanol, methane and even hydrogen. Independent studies have demonstrated that algae is capable of producing 30 times more oil per acre than the current crops now utilized for the production of biofuels. Algae biofuel contains no sulfur, is non-toxic and highly biodegradable. The Office of Fuels Development, a division of the Department of Energy, funded a program from 1978 through 1996 under the National Renewable Energy Laboratory known as the "Aquatic Species Program." The focus of this program was to investigate high-oil algae that could be grown specifically for the purpose of wide-scale biodiesel production. Some species of algae are ideally suited to biodiesel production due to their high oil content, in excess of 50%, and extremely rapid growth rates. One of the biggest advantages of biodiesel, compared to many other alternative transportation fuels, is that it can be used in existing diesel engines, which relieves automotive manufacturers of having to make costly engine modifications. Biodiesel can also be mixed, at any ratio, with conventional petroleum diesel. As a result, the alternative fuel can be used in the current distribution infrastructure, replacing petroleum diesel either wholly, or as a diesel fuel blend with minimal integration costs. About PetroSun PetroSun's current operations are concentrated in the Ark-La-Tex region with plans to expand into New Mexico, Arizona, Utah and Australia in 2006. PetroSun provides a comprehensive array of products and services to the oil industry. The company's cutting-edge technologies, combined with a proven ability to apply them effectively and safely within a disciplined ROI framework, creates long-term value for PetroSun shareholders and partners. PetroSun is headquartered in Phoenix. From eap-bounces+eap-archive=lists.ietf.org@frascone.com Thu Jun 29 15:12:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw1wb-0003oM-NF for eap-archive@lists.ietf.org; Thu, 29 Jun 2006 15:12:53 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw1wa-0003e3-Al for eap-archive@lists.ietf.org; Thu, 29 Jun 2006 15:12:53 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 9C5DB4300DC for ; Thu, 29 Jun 2006 12:12:51 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id BA14D430018 for ; Thu, 29 Jun 2006 12:12:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 52549144801A for ; Thu, 29 Jun 2006 12:12:36 -0700 (PDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by hermes.tigertech.net (Postfix) with ESMTP id 02BE01448027 for ; Thu, 29 Jun 2006 12:12:29 -0700 (PDT) Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id k5TJCSEm003338 for ; Thu, 29 Jun 2006 12:12:28 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k5TJCRFA026970 for ; Thu, 29 Jun 2006 14:12:28 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 29 Jun 2006 15:12:26 -0400 Message-ID: In-Reply-To: <449D9E96.5000302@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eap] Conclusion of the eap-keying WGLC Thread-Index: AcaXy78WHfkMwOsQQeGU6cXKSyIJWwD4/0Lg From: "Nakhjiri Madjid-MNAKHJI1" To: "Jari Arkko" , X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: Nakhjiri Madjid-MNAKHJI1 , Bernard Aboba Subject: Re: [eap] Conclusion of the eap-keying WGLC X-BeenThere: eap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Hi Jari, Bernard, Thank you for taking this issue into consideration. Yes I think the text can be easily manipulated to allow for future specifications defining usage of EMSK in key derivation. I will look for the email. Madjid 362 Lower layer params and EMSK Here Vidya and Madjid disagreed, but there was no followup. The disagreement may actually be on text that is from RFC 3748, however. I talked to Bernard and we can probably work out what to say so that you Vidya and Madjid are OK with it. Expect an e-mail from Bernard on this. In general, if there's future IETF work, such as work possibly coming out of the HOKEY effort, it can relax the rules from RFC 3748, just as RFC 3748 itself says: "(This restriction will be relaxed in a future document that specifies how the EMSK can be used.)" _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap