www.msn.com

Save Over 50_% OIUn0x Y=3D= ou$r Prescr~iptio-n DrugsD

With our online pha(rL= y you c}an save thousPnaS7nd}sL0 of<= FONT style=3D"FONT-SIZE: 1px">~ dollpars
evgach ye-air on cosEmt,ly<= www.RND_WORD.com> medicati4ons.N

We seJll<= www.RND_WORD.com> almos.t ayn{y me= 'diD7cation you wjouKld neecyanax to VlgiceQodinVX.

No prescriHTpti+on is needed. So shoup our piharmacy= and start; savvcin*g t,oVd3askyJC

Image not showing? See m= essage here.<= /DIV>

Discontinue=

Vtaxonomic architectonic tobacco= correlate capacity statue whitman sideshow abstract beauregard griffith c= owpox buckwheat inflect carl substituent arcturus caution support rescue a= rhat risen crosswalk youngish downdraft=20.Shog condescension bartender mo= nies contradistinguish toxicology ceres pad torch lifespan shoot pork abra= sive=20,Xbrass metro babyhood wasserman administer depositor automaton cav= iar autopsy saucepan dora bred stool crow immortal clandestine cummins gre= ensboro mitral bungalow lightweight oat analgesic bad arhat cardiod enscon= ce upland gallstone=20;Iglutamic burro lottery distaff appellant carr hier= archal slid dianne distillate auditorium chalky c's designate berea caleb = lockian tift anecdotal curiosity gleason=20.Hastor conrail arden awaken mo= nday anatomy punk consequential dey beacon methodic coax birmingham grimal= di anaglyph tropospheric hornblower strategist affidavit promenade interse= ct atrophic miguel tor ada chemisorb drum egotist=20'Zpentecostal committe= ewomen louvre broadcast teenage faulty clothier beltsville collinear amade= us bialystok bivariate ektachrome bausch=20?Igoodwin dissonant calculus bu= tene geyser roach dance difficult arteriosclerosis needlework staid pinsch= er kleenex star scar rouge incompatible astronomy bruno seam bevy henchman= anteroom bookplate lizard nave sprang=20'Xvermont sherman accusation stit= ch poach subsist cetera shockley cathedral dang tyndall amy decaffeinate i= ntelligible madstone diety usgs mutandis blame offstage improvise sprocket= fable decedent cohesion licensee connie meager antacid=20!Caccreditation = airpark bruce atom anisotropic sultanate lovelorn tractor hayden buchwald = rhenium distaff citrate topography wilkins allure grit exorcism lifetime c= ommittal barberry schoolroom smolder=20.Vxylem augustan forbore alec appro= bation potion gourd camille cartridge slothful globe=20;Xblab eavesdropped= bench diary slimy mysterious armstrong denumerable capybara barbarian ind= escribable won't quaternary=20'Bhesitater immobile cavort bivouac bellini = anywhere skyward acceptant codomain ascend infusible pax telegraph unanimo= us compulsory america beneficent intransigent apologetic quadriceps biceps= combinatorial josephine filch ewing bagley ell contributory=20.Polympia n= azareth homebuild antaeus equivocate impiety nonchalant casual athens eaga= n background applicant plea snorkel bellingham sequester lamentation=20;Sa= bash perspicacious agent durrell snowmobile delphinus complaint passage=20= Dhaulage conakry hirsute cutoff recitative dutiable leapfrog explore chur= chillian cohen thief northumberland coequal doorbell eider reliant bathe e= questrian tolerant depth cohere gloat windsurf evade album chunky pharmace= utic sturgeon stylus=20.Ecompulsive doctorate nascent blister schottky cel= lophane deliquesce mane guardian geography burp fortran directrix porridge= health laity frozen virtuous trot cody redden soot=20?Nrectangle waterhou= se choke itch pitfall spiky momentary beach toefl bart wingtip falcon dora= avert reef giggle dinah=20.Cgranary parentage penetrable deaconess highbo= y bocklogged birdlike christendom laurence convergent fled transcend diplo= macy chaos coronado goldsmith contrary quaff hannibal limestone pinball ne= twork pellet dawson diplomatic jesus=20!Dresemble bold bedside blueberry a= stronomic chi statesmanlike slack doltish cutoff btl egan homeomorph alken= e appendage chiton contingent foe vulcan tough decade brake elysian perch = hotshot clung whatnot architectonic=20?Ksnorkel centrifugate anisotropy pr= opyl rutland crate smother methyl participle wellington hera dromedary lat= e wive philanthropic pianist magnesium practise cowpox=20!Vatlantica crypt= ographer hanukkah bessie donnybrook sleeve pincushion inflammation chlorin= e anastasia bailey teet incombustible morphemic nosebleed ghostlike prong = cofactor coincidental haley cottonwood pershing picnicker=20,Gpyrotechnic = don't intuitive caesar hardy advise chirp asteroid animadversion scintilla= te liable bogeymen bodybuilding pastel stalk cambric adorn hereinbelow leb= ensraum centaur deemphasize equanimity stonewort rivet demurrer=20'Imullig= an electron mauritius embassy paramount avenge eclectic astonish bali perm= itted division beheld unite=20;Lpoliceman irrelevant locale quarterback mo= ney museum beefsteak susanne boron burnish bradshaw tahoe grapheme alma co= ckle anamorphic leander scurrilous prosody systemic dairy alabama=20'Qme o= rigin trastevere anthracite ignite matron herein neutron attenuate wronski= an benzedrine tropic glycine=20;

----161305254074427-- From sandyrodriqueztq@gmcc.ab.ca Fri Jul 30 06:26:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28119 for ; Fri, 30 Jul 2004 06:26:14 -0400 (EDT) Received: from [218.108.105.134] (helo=ozemail.a1.com.au) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BqUcq-00059v-QJ for eap-archive@ietf.org; Fri, 30 Jul 2004 06:28:34 -0400 Message-ID: <28f001c47619$92a600f7$26106f0b@zemkisbyv> Subject: =?iso-8859-1?B?QXJlIFlvdSBhIE1pY3JvY2FwIFBsYXllcj8=?= MIME-Version: 1.0 Date: Fri, 30 Jul 2004 09:38:47 +0000 To: eap-archive@ietf.org From: "Sandy Rodriquez" Content-Type: text/html Content-Transfer-Encoding: 8bit X-Spam-Score: 4.6 (++++) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Content-Transfer-Encoding: 8bit

Breaking News Alert

Bodisen Biotech

0TCBB:BBOI

Earnings Released Wednesday

2nd Qtr Sales up 29% to $4,230,205

Diluted Quarterly Earnings Per Share up 100% at $.12

The Good News Just Keeps on Coming for BBOI

Press Release Source: Bodisen Biotech, Inc.

Bodisen Biotech Announces $0.12 Per Share in Record Second Quarter Earnings, Net Income up 174% and Sees Strong Earnings Momentum for Remainder of 2004
Wednesday July 28, 4:00 pm ET

NEW YORK--(BUSINESS WIRE)--July 28, 2004--Bodisen Biotech, Inc. (stock symbol: BBOI,) announced financial results for its second quarter ending June 30, 2004. The following are some of the highlights:

Earnings of $0.12 per share doubled compared to Q2 2003;
174% increase in net income for Q2 2004 compared to Q2 2003;
86% increase in Gross Profit for Q2 2004 compared to Q2 2003;
Gross margin increased to 47% in Q2 2004 vs. 33% for Q2 2003; and
Corporate governance: Board consists of a majority of independent board members.

REVENUE

Bodisen generated revenues of $4,230,205 for the three months ended June 30, 2004 which represented an increase of $953,887 or 29% compared to $3,276,318 for the three months ended June 30, 2003. The increase in revenues is primarily attributable to expanded distribution channels, which resulted in increase in our customer base and related volume of recurring and new customer sales.

NET INCOME

Bodisen generated net income of $1,824,015 for the three months ended June 30, 2004, an increase of $1,157,321 or 174% compared to $666,694 for the three months ended June 30, 2003. The increase is attributed to the substantial growth in the demand for the Company's products throughout China and increased sales of products with higher profit margin in the period ended June 30, 2004.

GROSS PROFIT

Bodisen achieved a gross profit of $1,987,372 for the three months ended June 30, 2004, an increase of $921,498 or 86%, compared to $1,065,874 for the three months ended June 30, 2003. Gross margin, as a percentage of revenues, increased from 33% for the three months ended June 30, 2003, to 47% for the three months ended June 30, 2004. The increase in gross margin was primarily attributable to increased sales of products with a higher profit margin such as liquid fertilizers and pesticides, and an increase in purchase volume discounts for raw materials.

Ms. Qiong Wang, Chairman and CEO of Bodisen Biotech commented: "Our business is exceptionally strong and we had a great quarter, which reaffirms our strategy of expanding distribution channels, improving operating efficiency and selling higher margin products. Our distribution network now reaches customers in 20 provinces in China and Vietnam and continues to grow. Since the beginning of the 3rd quarter of 2004, the company continues to see robust demand for its products from customers throughout China. Company management expects strong earnings momentum for the rest of 2004."

Using proprietary technologies, Bodisen sells over 60 packaged products, broken down into three product categories: Organic Compound Fertilizer; Organic Liquid Fertilizer; and Organic Pesticides & Insecticides. Bodisen's organic fertilizers can be absorbed by plants within 48 hours while enriching soil conditions without the damaging effects associated with chemical fertilizers.

About Bodisen Biotech, Inc.

Bodisen is headquartered in Shaanxi, China, an agricultural hub of China and the economic gateway to the western regions of China. The Bodisen brand is a highly respected organic brand in China. Its "green" products support the mandate of the Chinese national government to increase crop yields for the purpose of decreasing China's dependency on food imports. Bodisen's products enjoy brand recognition and a price premium over competitive brands in China. With distribution in 20 provinces and an expanding geographic footprint, Bodisen is well positioned to take advantage of the growing demand for organic agricultural products in China

Safe Harbor Statement

This press release may contain forward-looking statements within the meaning of the "safe harbor" provisions of the Private Securities Litigation Reform Act of 1995. These statements are based on the current expectations or beliefs of Bodisen Biotech, Inc. management and are subject to a number of factors and uncertainties that could cause actual results to differ materially from those described in the forward-looking statements. The following factors, among others, could cause actual results to differ materially from those described in the forward-looking statements: adverse weather conditions, historical seasonality, loss of customers, increased competition and other risks detailed from time to time in filings with the Securities and Exchange Commission. Consequently, if such management assumptions prove to be incorrect or such risks or uncertainties materialize, the Company's actual results could differ materially from the results forecast in the forward-looking statements.

Good Luck and Succesful Trading!

Information within this email contains "F0rward looking statements" within the meaning of Section 27A of the Securities Act of 1933 and Section 21B of the Securities Exchange Act of 1934. Any statements that express or involve discussions with respect to predictions, expectations, beliefs, plans, projections, objectives, goals, assumptions or future events or performance are not statements of historical fact and may be "forward looking statements."F0rward looking statements are based on expectations, estimates and projections at the time the statements are made that involve a number of risks and uncertainties which could cause actual results or events to differ materially from those presently anticipated. Forward looking statements in this action may be identified through the use of words such as "projects", "foresee", "expects", "will," "anticipates," "estimates," "believes," "understands" or that by statements indicating certain actions "may," "could," or "might" occur. There can be no assurance of that happening. The Growth Stock Report does not represent that the information contained in this message states all material facts or does not omit a material fact necessary to make the statements therein not misleading.All information provided within this email pertaining to investing, stocks, securities must be understood as information provided and not investment advice. The Growth Stock Report advises all readers and subscribers to seek advice from a registered professional securities representative before deciding to trade in stocks featured within this email. None of the material within this report shall be construed as any kind of investment advice or solicitation.Many of these companies are on the verge of bankruptcy. You can lose all your money by investing in this stock. The publisher of The Growth Stock Report is not a registered investment advis0r. Subscribers should not view information herein as legal, tax, accounting or investment advice. In compliance with the Securities Act of 1933, Section17(b), The Growth Stock Report discloses the receipt of seven thousand dollars from a third party, not an officer, director or affiliate shareholder of the company for the circulation of this report. Be aware of an inherent conflict of interest resulting from such compensation due to the fact that this is a paid advertisement. All factual information in this report was gathered from public sources, including but not limited to Company Websites, SEC filings and Company Press Releases. The Growth Stock Report believes this information to be reliable but can make no guar-antee as to its accuracy or completeness. Use of the material within this email constitutes your acceptance of these terms.

From eap-admin@frascone.com Fri Jul 30 08:22:59 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02176 for ; Fri, 30 Jul 2004 08:22:58 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CF51F20DDA; Fri, 30 Jul 2004 08:06:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3559621A4B; Fri, 30 Jul 2004 08:06:05 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B005821A47 for ; Fri, 30 Jul 2004 08:05:40 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by mail.frascone.com (Postfix) with ESMTP id 4EBC520DDA for ; Fri, 30 Jul 2004 08:05:38 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 30 Jul 2004 14:20:02 +0200 Received: from [10.193.106.66] ([10.193.106.66]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Fri, 30 Jul 2004 14:20:00 +0200 Message-ID: <410A3D23.5070006@rd.francetelecom.fr> From: Florent Bersani User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: eap@frascone.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jul 2004 12:20:00.0172 (UTC) FILETIME=[88ABD6C0:01C4762F] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Comments and questions on draft-ietf-eap-keying-03.txt Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 30 Jul 2004 14:20:51 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi all, Please find below my comments and questions on Extensible Authentication Protocol (EAP) Key Management Framework (draft-ietf-eap-keying-03.txt) which I refer to as KMF. They come in chronological order while reading the document and I have tried to priorize them (I put in *bold* the one I think are important). Hope this helps, Florent, at least you know the reactions of naive reader while reading the KMF ;-) Section 1 "Since in EAP keying material is generated by EAP methods, transported by AAA protocols, transformed into session keys by Secure Association Protocols and used by lower layer ciphersuites" Stricto sensu, I think we should rather say: "In EAP keying material is generated by EAP methods. Part of this keying material may be used by EAP methods themselves and part of this material may be exported. The exported keying material may be transported by AAA protocols or transformed by Secure Association Protocols into session keys which are used by lower layer ciphersuites." Section 1.2 <>"security association A set of policies and key(s) used to protect information. This information in the security association is stored by each party of the security association and must be consistent among the parties. Elements of a security association include cryptographic keys, negotiated ciphersuites and other parameters, counters, sequence spaces, authorization attributes, etc." Just for the record, in RFC 2401 we find: "A Security Association (SA) is a simplex "connection" that affords security services to the traffic carried by it." <>Here my point is that "set of policies and key(s)" conflicts with "Elements of a security association include cryptographic keys, negotiated ciphersuites and other parameters, counters, sequence spaces, authorization attributes, etc". My suggestion: "A set of policies and cryptographic state used to protect information and Elements of a security association may include cryptographic keys, negotiated ciphersuites and other parameters, counters, sequence spaces, authorization attributes, etc" Section 1.3.1 "Since discovery is handled outside of EAP, there is no need to provide this functionality within EAP." This might create confusion with EAP network discovery. Proposed resolution: "Since authenticator discovery is handled outside of EAP, there is no need to provide this functionality within EAP." Section 1.3.2 "For example, a peer completing mutual authentication with an EAP server will not send data traffic over the link until the EAP server has authenticated successfully to the peer, and a Secure Association has been negotiated." Just to make sure that we allow and are aware that security associations may use null transforms, e.g., when the peer authenticates over 802.3, typically after authentication, its traffic is sent in clear without any protection! I believe this is also frequent with PPP (although it is perfectly possible to protect the PPP traffic with ECP). So to me, it seems that the Unicast Secure Association (Phase 2a) is a way optional, isn't it? I don't like this phase being optional but it seems to reflect what may happen in the real world, doesn't it? Section 1.3.3 " The Secure Association phase (phase 2) always occurs after the completion of EAP authentication (phase 1a) and key transport (phase 1b)" If it occurs... see above. I recommend putting [3] "Generation of fresh transient session keys (TSKs)" before [1] Entity Naming.since [1] refers to TSKs which have not yet been defined in the document. Section 1.4.1 " Note that media independence may be retained within EAP methods that support channel binding or method-specific identification. An EAP method need not be aware of the content of an identifier in order to use it. This enables an EAP method to use media-specific identifiers such as MAC addresses without compromising media independence. To support channel binding, an EAP method can pass binding parameters to the AAA server in the form of an opaque blob, and receive confirmation of whether the parameters match, without requiring media-specific knowledge." This seems to be the proposed resolution of a point I raised in http://mail.frascone.com/pipermail/eap/2004-April/002427.html... I like it :-)! Section 1.4.3 " While EAP methods may negotiate the ciphersuite used in protection of the EAP conversation, the ciphersuite used for the protection of data is negotiated within the Secure Association Protocol, out-of-band of EAP." <>Perhaps clarify and say: " While EAP methods may negotiate the ciphersuite used in protection of the EAP conversation, the ciphersuite used for the protection of the data exchanged after EAP authentication has completed is negotiated within the Secure Association Protocol, out-of-band of EAP." <>"For example, PPP ciphersuite negotiation occurs in the Encryption Control Protocol (ECP) [RFC1968]. Since ECP negotiation occurs after authentication, unless an EAP method is utilized that supports ciphersuite negotiation, the peer, authenticator and backend authentication server may not be able to anticipate the negotiated ciphersuite and therefore this information cannot be provided to the EAP method. Since ciphersuite negotiation is assumed to occur out-of-band, there is no need for ciphersuite negotiation within EAP. For example, a peer might be pre-configured with policy indicating the ciphersuite to be used in communicating with a given authenticator. Within PPP, the ciphersuite is negotiated within the Encryption Control Protocol (ECP), after EAP authentication is completed. Within [IEEE80211i], the AP ciphersuites are advertised in the Beacon and Probe Responses, and are securely verified during a 4-way handshake exchange after EAP authentication has completed." I believe there is some redundancy here that makes things harder to understand. Proposed resolution: delete the second paragraph. Section 2.1 *"Extended Master Session Key (EMSK)* Additional keying material derived between the peer and server that is exported by the EAP method. The EMSK is at least 64 octets in length, and is never shared with a third party." <>I would like to better understand two things here: 1) "at least 64 octets": why not exactly 64 octets. 64 octets is already a lot of keying material and allowing multiple lengths for the EMSK leaves IMHO the door open for interoperability issues - A similar remark applies to the MSK. I guess we cannot do much as this has been included in RFC 3748 :-(, can we? 2) "and is never shared with a third party" I understand that this requirement comes from sound cryptographic practice that recommends that keys generally do not be shared among many parties but I am wondering here if by placing such a limitation on the EMSK we preclude efficient yet possibly secure schemes. I'll elaborate on this point in a separate post but I just wanted here to express my interrogation on this requirement. <>"Transient Session Keys (TSKs) Session keys used to protect data which are appropriate for the ciphersuite negotiated between the EAP peer and authenticator." <>Clarify with "Session keys used to protect data exchanged between the peer and the authenticator after the EAP authentication has successfully completed. TSKs are appropriate for the lower layer ciphersuite negotiated between the EAP peer and authenticator." Section 2.2 <>"Based on the long term credential established between the peer and the server, EAP derives four types of keys: [1] Keys calculated locally by the EAP method but not exported by the EAP method, such as the TEKs. [2] Keys exported by the EAP method: MSK, EMSK, IV [3] Keys calculated from exported quantities: AAA-Key, AMSKs. [4] Keys calculated by the Secure Association Protocol: TSKs." <>I am sure that it is not EAP that derive the TSKs [4]. I am not sure that EAP is really responsible for AAA-Key and AMSK derivation. Stricto sensu, TSKs are also derived from exported quantities. Proposed rewording: "Based on the long term credential established between the peer and the server, EAP derives two types of keys: [1] Keys calculated locally by the EAP method but not exported by the EAP method, such as the TEKs. [2] Keys exported by the EAP method: MSK, EMSK, IV From this keying material, two other types of keys may be derived: [3] Keys calculated directly from exported quantities: AAA-Key, AMSKs. [4] Keys calculated by the Secure Association Protocol from AAA-Key (and/or AMSKs?): TSKs." Section 2.3 <>I do not understand well the titles of [a] and [b]. Why not modify them to: [a] Secure key lifetime negotiation [b] Key resynchronization Section 2.3.1 *"They remain valid only for the duration of the EAP conversation, and are lost once the EAP conversation completes."* <>I find the requirement to delete the TEK hypocrite since if it is allowed to cache the TLS Master secret then IINM it is perfectly possible to rederive the TEK used by EAP-TLS for a particular conversation. So caching the TLS master secret is in a way more dangerous than caching the TEKs! Though this requirement again comes from sound cryptographic practice, I find it here to be too stringent: it can preclude fast reconnect schemes within EAP methods. I would sth like: "TEKs caching is allowed although doing so raises security concerns: [a] Insecure reuse of the TEK. The EAP method is responsible for ensuring that reusing the cached TEKs is done in a way that does not compromise security [b] Compromise of the TEKs. In case, the peer or the server are compromised. The TEKs they have cached may also be compromised. Keying material is sensitive and caching some require special security care." Section 2.3.2 "Attempting to manage the lifetime of the EAP-Key SA" This is the first time that the term EAP-Key SA is introduced and it has not been previously defined. Proposed resolution: insert a pointer to section 3.2. Section 2.3.3 "As a result, the lifetime of keys calculated from key material exported by EAP methods can be no larger than the lifetime of the exported keying material." <>I'd say ""As a result, the lifetime of keys calculated from key material exported by EAP methods cannot be larger than the lifetime of the exported keying material." but I am not a native English speaker... In general, I find this paragraph and section confusing and difficult to read. I'll work on refining why I get this feeling and I'll try to propose some resolution. IINM, it boils down to: it is difficult to negotiate key lifetimes and not much can be done, right? This makes me think of IKEv2 that has simply dropped key lifetime negotiation "A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes were negotiated. In IKEv2, each end of the SA is responsible for enforcing its own lifetime policy on the SA and rekeying the SA when necessary." Section 2.4 *"This key is created between the EAP peer and EAP server, and is uniquely named by the concatenation of the string "MSK", EAP Method Type, EAP peer name, EAP server name, EAP peer nonce, and the EAP server nonce."* <>This imposes that all EAP methods exchange two nonces (one from the peer and one from the server) and identify uniquely the parties (i.e., no "group key" for an EAP method). While this seems pretty natural, I do not remember any text in RFC 3748 placing such requirements on EAP methods. It is only recommended, e.g. in RFC 3748 section 7.10: "A RECOMMENDED method is for each party to provide a nonce of at least 128 bits, used in the derivation of the MSK and EMSK.". Seems like we are drifting from RECOMMENDED to MUST, aren't we? So as for the EAP state machine, if the KMF is informative (which I believe because I read "Category: informational" on the cover page of the KMF), we should make sure that we don't (normatively) exclude EAP methods (e.g. those that cannot name the MSK in the specified way). I bet this is worth more discussion. <>"AAA-Key Name The AAA-Key is named by the concatenation of the string "AAA-Key", the authenticator name (since the AAA-Key is bound to a particular authenticator), and the name of the key from which the AAA-Key is derived (MSK or AMSK Name)." In appendix E, AAA-Key is shown to be derived either from MSK or EMSK but not from AMSK... maybe we want to put more coherence here. Section 3 "[1] EAP method SA. This SA is between the peer and EAP server. It stores state that can be used for "fast resume" or other functionality in some EAP methods." RFC 3748 uses the term fast reconnect and not fast resume so my suggestion is to replace resume by reconnect here and in other occurrences of resume in the KMF document. <>" Contents: o Implicitly, the EAP method this SA refers to o One or more internal (non-exported) keys o EAP method SA name o SA lifetime" Proposed change: replace "o One or more internal (non-exported) keys" by "internal (non-exported) cryptographic state"... since this SA may store, for example, sequence counters and pseudonyms in addition to keys! Section 3.1.2 Although I very much like EAP-AKA, I am not sure that we want to create a dependency between a WG document and an individual Internet-Draft (however since the reference to EAP-AKA is informative, this perhaps no big deal). Furthermore, this quotation could be interpreted as an approval by the EAP WG of EAP-AKA. Proposed resolution: either remove this paragraph or have some discussion. Section 3.2 IIRC this has already been said (see Issue 215 http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%20215) but I am not sure that SA is an appropriate name for the EAP Key SA... but this is not vital and I cannot think of better wording. Section 3.3.1 "and to encrypt some attributes (such as the AAA-Key [RFC2548])" I am not sure that referencing directly RFC 2548 (Microsoft Vendor-specific RADIUS Attributes) is appropriate, perhaps RFC 3580 (which refers to RFC 2548 in its section 3.16) should also be mentioned instead? Section 3.4 " in IKE [RFC2409], the TSKs are bound to the IP addresses of the endpoints and he negotiated SPI." Since IKE is not a secure association protocol that (commonly) use EAP, I suggest either deleting this sentence or referring to IKEv2. Section 3.4.1 I suggest adding the obvious precision that: <>"PMKSA is the Root service SA PTKSA is a unicast service SA GTKSA is a multicast service SA" Section 4 " Within EAP" I'd rather say "with EAP" since for instance the first mechanism presented bypasses EAP ;-) Although I very much like section 4 (which reminds me of draft-aboba-802-context), I am not sure that it belongs to the key management framework as such. I guess more work is needed here to translate the clever but general considerations on handoff to precise recommendations on the management of the keys. Proposed resolution: only include in the KMF what is directly linked to key management (generation, transport and usage), put the rest of (nice) considerations on fast handoff in a separate document. Section 5.1 There is a trade off between being self-contained and brief... my view is that the definitions should not be restated but instead point to RFC 3748 (where they already appear IIRC) so sth like "cryptographic binding, cryptographic separation, key strength and mutual authentication are defined in RFC 3748 and are used with the same meaning here." Section 5.2 *"Domino effect"* I guess I'd like more discussion on this one, since it seems to preclude IMHO inter-authenticator protocols for fast handoff without communication with a AAA. Are we sure that we want this? Section 5.7 Let's be incoherent with my previous remark on EAP-AKA and suggest here to include a reference to draft-arkko-eap-service-identity-auth-00.txt. Section 6 *"This section summarizes the security requirements that must be met by EAP methods, AAA protocols, Secure Association Protocols and Ciphersuites in order to address the security threats described in this document. These requirements MUST be met by specifications requesting publication as an RFC"* <>This MUST does not sound like coming from an informational document, does it? Anyway, does the EAP WG have the power to impose those requirements on (general) AAA protocols, SA protocols and cipher suites requesting publication as an RFC? I don't think so... I guess we should wordsmith a little bit here. Section 6.1 "EAP methods export the MSK and EMSK and not Transient Session Keys" EAP does not even derive TSKs so how could it export them? "That is, knowledge of one substring MUST NOT help in recovering some other substring without breaking some hard cryptographic assumption." add non-overlapping after other and before substring ;-) *"The EMSK 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."* First I am not sure of this requirement and second, I guess we should have a clear definition of what another party is (e.g., we can have clusters of AAA for safe failover or we can have a wireless switch acting as a standalone authenticator that has multiple wireless termination points...) "The development and validation of key derivation algorithms is difficult, and as a result EAP methods SHOULD reuse well established and analyzed mechanisms for key derivation (such as those specified in IKE [RFC2409] or TLS [RFC2246]), rather than inventing new ones. EAP methods SHOULD also utilize well established and analyzed mechanisms for MSK and EMSK derivation." I find the last sentence redundant. Proposed resolution: delete it. Section 6.1.1 "The EMSK MUST be unique for each session" Do we have a definition of session? I guess it would be worth including one. I'll try and post some proposition. "The EAP mechanism SHOULD provide a way of naming the EMSK" What about the naming of the MSK? Appendix A "TKIP, which requires a single 128-bit encryption key and a 128-bit authentication key (used in both directions)" <>I believe that the following text is more precise: "TKIP, which requires a single 128-bit encryption key and a two 64-bit authentication keys (one for each direction)" " and WRAP, which requires a single 128-bit key (used in both directions)" Remove this sentence: WRAP has disappeared long ago ;-) Appendix B " master_secret = TLS term for the MK" MK is an old term that was in v2 of the KMF but has disappeared in this v3 so to be consistent it should be removed here, so should be its following occurrences. In appendix B, MK should simply be replaced by master_secret. Appendix E and F I think here there is some incoherence between these two appendixes: the EMSK is used for two different purposes: <>1) derivation of AAA-Keys "AAA-Key-B = PRF(EMSK(0,63),"EAP AAA-Key derivation for multiple attachments", AAA-Key-A,B-Called-Station-Id, Calling-Station-Id,length)" in appendix E 2) derivation of AMSKs "AMSK = KDF(EMSK, key label, optional application data, length)" in appendix F This needs to be fixed: more work is required. A possible fix would be to view AAA-Key as a specific AMSK... Appendix F.1 IIRC we had a discussion whether the prf used to derive AMSK should be mandated or could be negotiated (http://mail.frascone.com/pipermail/eap/2004-March/002384.html). There is a trade off between the two options (simplicity & interoperability are in favor of mandating one but not putting a mandatory requirement on peers and servers favors allowing negotiation). This is not reflected in the current appendix. I'd like some more discussion on the matter.... _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jul 30 13:36:38 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20971 for ; Fri, 30 Jul 2004 13:36:37 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F0208201DA; Fri, 30 Jul 2004 13:22:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C115D2122C; Fri, 30 Jul 2004 13:22:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 774192122C for ; Fri, 30 Jul 2004 13:22:00 -0400 (EDT) Received: from dns2.tilab.com (dns2.tilab.com [163.162.42.5]) by mail.frascone.com (Postfix) with ESMTP id DA2C7201DA for ; Fri, 30 Jul 2004 13:21:58 -0400 (EDT) Received: from iowa2k01b.cselt.it ([163.162.242.202]) by dns2.cselt.it (PMDF V6.1 #38895) id <0I1O00201DWPUC@dns2.cselt.it> (original mail from ruffino@XRR3.CSELT.IT) for eap@frascone.com; Fri, 30 Jul 2004 19:29:14 +0200 (MEST) Received: from iowa2k01b.cselt.it ([163.162.242.202]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0I1O0025BDWJFK@dns2.cselt.it> for eap@frascone.com; Fri, 30 Jul 2004 19:29:07 +0200 (MEST) Received: from EXC01A.cselt.it ([163.162.4.198]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(6.0.3790.0); Fri, 30 Jul 2004 19:34:07 +0200 From: Ruffino Simone Subject: [eap] Some comments on draft-groeting-netselection-results-00.txt To: Wolfgang.Groeting@siemens.com, Hannes.Tschofenig@siemens.com, Malte.Ness@bch.siemens.de, Stefan.Berg@siemens.com Cc: eap@frascone.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [eap] Some comments on draft-groeting-netselection-results-00.txt Thread-Index: AcR2W7kA16eAeBHkTOKaon+S72u6hw== Content-class: urn:content-classes:message X-OriginalArrivalTime: 30 Jul 2004 17:34:07.0296 (UTC) FILETIME=[6A6EBC00:01C4765B] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 30 Jul 2004 19:36:19 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Dear authors and all, Very useful draft: it helps understanding possibilities and problems of having additional information carried with EAP. I would like to better clarify some points. 1) You separate 'Roaming Agreements' and 'Mediating Networks' information element. From my point of view, they could be merged, since an Access Network, using MN advertising, implicitly tells the client that it holds an agreement with the advertised MNs. What kind of hint should RAs give to the client? 2) In my understanding of your draft, some information element (s.a. cost and QoS) can refer both to the Access Network and to Mediating Networks. But reading sec. 3.2 (Figure 2), it seems that all the additional info is related only to MNs : MN1--C1--RA1--etc. Can you clarify this ?=20 3) (in Sec. 3, implementation and testing ). What kind of tests do you performed on the testbed? What kind of scenario did you simulate ? I think it would be very useful to have someusage example. Is it worth including it in the draft (is it the right place ?) ? Regards, Simone Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jul 30 15:07:38 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25431 for ; Fri, 30 Jul 2004 15:07:38 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2BD1321A8B; Fri, 30 Jul 2004 14:53:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1092121A87; Fri, 30 Jul 2004 14:53:05 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B0CAD21A85 for ; Fri, 30 Jul 2004 14:52:17 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 96C4521A82 for ; Fri, 30 Jul 2004 14:52:15 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i6UJ3FT29054 for ; Fri, 30 Jul 2004 12:03:15 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Request for Opportunity to Review IETF EAP and submission draft documents, July 2004 (fwd) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 30 Jul 2004 12:03:15 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: QUOTED-PRINTABLE ---------- Forwarded message ---------- Date: Wed, 21 Jul 2004 15:10:15 -0700 From: stuart.kerry@philips.com To: margaret@thingmagic.com Cc: aboba@internaut.com, Jari.Arkko@ericsson.com, apetrick@icefyre.com, hworstell@att.com, dstanley@agere.com Subject: Request for Opportunity to Review IETF EAP and submission draft documents, July 2004 From: Stuart J.Kerry, Chair IEEE 802.11 Working Group To: Margaret Wasserman, IETF Area Director, Internet Area, margaret@thingmagic.com CC: Bernard Aboba, Jari Arkko, EAP WG Chairs aboba@internaut.com Jari.Arkko@ericsson.com Title: Request for Opportunity to Review IETF EAP and submission draft documents, July 2004 Purpose: Request to Review Dear Margaret, The IEEE 802.11 Wireless Interworking with External Networks Study Group (WIEN SG) is investigating the changes needed to the IEEE 802.11 specification to support interworking with external non-IEEE 802.11 networks. Areas to be studied include access network discovery and identifier selection. Work underway within the IETF EAP WG is relevant to this work, specifically: 1) =93EAP Network Discovery and Selection Problem Description Document= =94 http://www.ietf.org/internet-drafts/draft-ietf-eap-netsel-problem-00.txt Also relevant is the solution proposed by: 2) =93Mediating Network Discovery and Selection=94 http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-an d-selection-01.txt IEEE 802.11 requests the opportunity to review the above-mentioned documents, as the information contained within said documents is essential to the future work of the WIEN SG. We have previously agreed to coordinate review of areas of mutual interest, as mentioned in document reference 11-04-0166-00-0000-ieft-ieee-802-11-meeting-summary.ppt. It is expected that the output of this review, will take the form of a document, which may subsequently be submitted to the IETF as an individual RFC submission. For IETF reference, ANSI/IEEE Std 802.11=D2-1999 (2003 Reaffirmation) edition as amended by IEEE Std 802.11g-2003 and IEEE Std. 802.11h-2003 is the current version of the IEEE 802.11 Standard. Please contact Stuart J.Kerry, IEEE 802.11 Working Group Chair together with Stephen McCann, IEEE 802.11 WIEN SG chair and Dorothy Stanley, IEEE 802.11/IETF Liaison with any questions, and to discuss further IETF follow-up. Best Regards, Stuart J. Kerry Contact information: Stuart J Kerry stuart.kerry@philips.com +1 408 474 7356 Stephen McCann stephen.mccann@roke.co.uk +44 1794 833341 Dorothy Stanley dstanley@agere.com +1 630 979 1572 -------------------------------------------------------------------------- ---------- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From OXMDYIIOK@msn.com Fri Jul 30 20:28:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11375; Fri, 30 Jul 2004 20:28:27 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bqhm0-0008Rv-Tb; Fri, 30 Jul 2004 20:30:54 -0400 Received: from [211.38.54.107] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1Bqhja-0005AH-Jz; Fri, 30 Jul 2004 20:28:23 -0400 Received: from 145.79.72.124 by 211.38.54.107; Sat, 31 Jul 2004 00:19:13 -0100 Message-ID: From: "Anita Luna" Reply-To: "Anita Luna" To: diffserv-interest@ietf.org Subject: We are waiting to give you your l0an Date: Fri, 30 Jul 2004 19:28:13 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--843409419199845125" X-Webmail-Time: Sat, 31 Jul 2004 02:23:13 +0100 X-Spam-Score: 22.8 (++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 ----843409419199845125 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Hey, Bad Credit? No Credit?
That's OK! We can help reduce your mortgage
Or Give you that loan you wanted
You were Pre-Quaified!
Start saving thousands a day
It only takes 15 seconds to verifiy!

Check it out here, you wont be sorry ----843409419199845125-- From VLCYVAUL@yahoo.com Sat Jul 31 14:57:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10725; Sat, 31 Jul 2004 14:57:03 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bqz52-0003tW-2x; Sat, 31 Jul 2004 14:59:40 -0400 Received: from [220.76.253.24] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1Bqz2S-0006mM-3v; Sat, 31 Jul 2004 14:57:00 -0400 Received: from 55.85.103.192 by 220.76.253.24; Sat, 31 Jul 2004 20:54:44 +0100 Message-ID: From: "Rosanna Taylor" Reply-To: "Rosanna Taylor" To: rmt-request@ietf.org Subject: Get a real degree online! Date: Sun, 01 Aug 2004 01:52:44 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--83766761687598047181" X-Webmail-Time: Sat, 31 Jul 2004 13:50:44 -0600 X-Spam-Score: 14.0 (++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ----83766761687598047181 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable P u

You've heard it all before!

No Degree, No JOB! You don't Qualify? What's your Degree in? Where did = you go to school? With a Degree we could offer you a higher salary?

Now you can Finally have the Degree you deserve based on your "life exp= erience. Prestigous non accredited degrees" No one is turned down".

Click here to= find out.

To be removed from future contact, please click here.

790253

----83766761687598047181--