From diameter-admin@frascone.com Fri Oct 1 05:02:15 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 FAA08074 for ; Fri, 1 Oct 2004 05:02:14 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4AF1B21322 for ; Fri, 1 Oct 2004 05:02:14 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E93DD212FA for ; Fri, 1 Oct 2004 05:01:38 -0400 (EDT) Date: Fri, 01 Oct 2004 05:01:38 -0400 Message-ID: <20041001090138.20202.31699.Mailman@xavier> Subject: frascone.com mailing list memberships reminder From: mailman-owner@wolverine.cnri.reston.va.us To: eap-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: diameter-admin@frascone.com Errors-To: diameter-admin@frascone.com X-BeenThere: diameter@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a reminder, sent out once a month, about your frascone.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, eap-request@frascone.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@wolverine. Thanks! Passwords for eap-archive@lists.ietf.org: List Password // URL ---- -------- eap@frascone.com ohweow http://mail.frascone.com/mailman/options/eap/eap-archive%40lists.ietf.org From eap-admin@frascone.com Fri Oct 1 06:36:58 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 GAA15590 for ; Fri, 1 Oct 2004 06:36:57 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7994621390; Fri, 1 Oct 2004 06:36:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1290821389; Fri, 1 Oct 2004 06:36:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4CBD521386 for ; Fri, 1 Oct 2004 06:35:51 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mail.frascone.com (Postfix) with ESMTP id 58BBF21212 for ; Fri, 1 Oct 2004 06:35:48 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i91AZl127527 for ; Fri, 1 Oct 2004 13:35:47 +0300 (EET DST) X-Scanned: Fri, 1 Oct 2004 13:34:15 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i91AYFfn008470 for ; Fri, 1 Oct 2004 13:34:15 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00QrzL2W; Fri, 01 Oct 2004 13:34:13 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i91AYCY01338 for ; Fri, 1 Oct 2004 13:34:12 +0300 (EET DST) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 1 Oct 2004 13:34:09 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 1 Oct 2004 13:34:09 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] RE: a question related to the eap network discovery solution draft Message-ID: <125EA890549C8641A72F3809CB80DCCD16FCF8@esebe056.ntc.nokia.com> Thread-Topic: [eap] RE: a question related to the eap network discovery solution draft Thread-Index: AcSmFWn1E2YPs9etQUaWmrKmYBenBgBjGOUA From: To: X-OriginalArrivalTime: 01 Oct 2004 10:34:09.0703 (UTC) FILETIME=[2F856B70:01C4A7A2] 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, 1 Oct 2004 13:34:09 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi, I also support the "do nothing" option, i.e. keep the text that is already in -03. Best regards, Pasi > -----Original Message----- > From: Jari Arkko > Sent: Wednesday, September 29, 2004 2:09 PM > To: Adrangi, Farid > Cc: Ruffino Simone; eap@frascone.com > Subject: Re: [eap] RE: a question related to the eap network discovery > solution draft >=20 >=20 > Personally, I'd rather avoid this particular change. The > reason for this is what I described in the original message: > additional latency. In particular, an access network is > not in a position to know whether or not the client wants > to do manual selection or not. Most likely only a small > fraction of clients would be doing this (in GSM its relatively > rare in my understanding). So, everyone else would end up > paying a roundtrip for the benefit of the few. >=20 > In fact, I'd rather see as choosing between doing nothing, > or making the text more restrictive than it currently is. > We currently prohibit "unnecessary" advertisements. Perhaps > what we could add is some text that discourages the use of > alternative 2 from my original e-mail. For instance, we > could say "Note that EAP peers could force the access network > to generate an advertisement by supplying a NAI that is not > routable by the access network. However, such usage is NOT > RECOMMENDED due to the difficulty of finding a NAI that is > known to be non-routable. Also, this usage is problematic > when it is not certain that the network supports this > specification or when the authentication attempt uses > resources from a number of proxies on the default route > until it is found to be invalid." >=20 > What do you think? >=20 > --Jari >=20 > Adrangi, Farid wrote: > > Jari, Simone, all > >=20 > >=20 > > Going forward, so far there are two options: > >=20 > > 1) Do nothing > >=20 > > 2) We can reword the following paragraph in Sec. 6, Option=20 > 3 for more clarification. > >=20 > > Current text: > >=20 > > "If the RADIUS server cannot route the message based on the=20 > identity provided by the peer, it sends a second EAP Identity=20 > Request containing the identity hint information." > >=20 > > Modified Text: > >=20 > > "If the local RADIUS proxy/server cannot route the message=20 > *directly* to the home RADIUS server based on the identity=20 > provided by the peer (i.e., there is not a direct roaming=20 > relationship between the access network and the user's home=20 > network), it sends a second EAP Identity/Request containing=20 > the identity hint information. The RADIUS proxy/server may=20 > also Send identity hint even when an acceptable NAI realm=20 > (i.e., can be routed directly to the home RADIUS server) is=20 > received in the EAP Identity/Response." > >=20 > > I believe the WG LS call expires today -- so it would be=20 > nice to have a closure on this soon. > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap >=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Oct 1 13:33:46 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28857 for ; Fri, 1 Oct 2004 13:33:46 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8567E20D0A; Fri, 1 Oct 2004 13:33:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 14CF9211D6; Fri, 1 Oct 2004 13:33:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 842C421537 for ; Fri, 1 Oct 2004 13:32:27 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by mail.frascone.com (Postfix) with ESMTP id BF20F21535 for ; Fri, 1 Oct 2004 13:32:24 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 1 Oct 2004 19:32:22 +0200 Received: from [10.193.106.55] ([10.193.106.55]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Fri, 1 Oct 2004 19:32:21 +0200 Message-ID: <415D94B8.2020600@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=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Oct 2004 17:32:21.0702 (UTC) FILETIME=[9B849E60:01C4A7DC] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] EAP-Keying v3 review: announcement of future mails 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, 01 Oct 2004 19:32:40 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi all, It's high time we finalize the eap-keying document, isn't it? In an attempt to contribute to this noble task, I will try and take another stab at it, partly based on my previous review (http://mail.frascone.com/pipermail/eap/2004-July/002697.html) that unfortunately remained totally ignored (perhaps because it only contained useless gibberish, did it?). Hence, please bear with the (possibly) numerous emails on this subject you may expect to see me sending in the next 24 hours. Cheers, Florent _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Oct 1 13:43:05 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29402 for ; Fri, 1 Oct 2004 13:43:04 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DA35621524; Fri, 1 Oct 2004 13:43:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 817BC211D6; Fri, 1 Oct 2004 13:43:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B6AFC20D0A for ; Fri, 1 Oct 2004 13:42:54 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by mail.frascone.com (Postfix) with ESMTP id 985AC211D6 for ; Fri, 1 Oct 2004 13:42:52 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 1 Oct 2004 19:42:50 +0200 Received: from [10.193.106.55] ([10.193.106.55]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Fri, 1 Oct 2004 19:42:49 +0200 Message-ID: <415D972C.8020507@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=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Oct 2004 17:42:49.0983 (UTC) FILETIME=[1200B0F0:01C4A7DE] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Issue on eap-keying: informational or standards track 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, 01 Oct 2004 19:43:08 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Description of issue: should EAP-Keying be informational or standards track Submitter name: Florent Bersani Submitter email address: florent.bersani@francetelecom.com Date first submitted: 07/30/2004 Document: Keying Framework Comment type: 'E'ditorial Priority: S' Must fix Section: various but 6.1.1 is a good example Rationale/Explanation of issue: It seems that the eap-keying document wishes to go "informational" but it seems to me that it contains some normative text that impacts EAP. I would consider logic that such text follow the same track as the protocol it impacts, namely EAP and the standards track. For instance, RFC 3748 leaves the EMSK as unspecified and reserved... but the EAP-Keying Framework specifies how to use the EMSK (e.g. the AMSK scheme). Perhaps people more familiar with IETF procedures can provide some input here? Similarly, I am not sure that the key naming schemes should only be informational, shouldn't they? Requested change: Specify the EMSK usage in a standards track document Add an explanatory note to the beginning of eap-keying telling whether it places new requirements or it only gives some advice, essentially explain to the reader the authoritative status of this document (e.g., with respect to EAP). Text will be proposed as we agree on this authoritative status... my feeling is that we should really have two separate documents, one authoritative with key naming and EMSK usage and one informational, with the useful recommendations that are made throughout eap-keying (in which case, the aforementioned note could look like "This document provides insights and recommended practice for handling of EAP keying material. Authoritative documents are RFC 3748 and [authoritative keying document]. Should there be differences, RFC 3748 and [authoritative keying document] prevail." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From xavikheg@yahoo.com Fri Oct 1 17:17:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22007; Fri, 1 Oct 2004 17:17:11 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDUug-0001Ml-61; Fri, 01 Oct 2004 17:26:02 -0400 Received: from [80.236.102.28] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1CDUm4-0000wK-4I; Fri, 01 Oct 2004 17:17:13 -0400 Original-Encoded-Information-Types: multipart/alternative Language: English Disclose-Recipients: No Reply-To: "Phil Wall" From: "Phil Wall" To: disman@ietf.org, disman-admin@ietf.org, disman-request@ietf.org, drafts@ietf.org, eap-archive@ietf.org Date: Fri, 01 Oct 2004 21:20:56 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--08145126222406543632" Message-Id: X-Spam-Score: 5.5 (+++++) X-Spam-Flag: YES X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 ----08145126222406543632 Content-Type: text/plain; charset="iso-0439-7" Content-Transfer-Encoding: quoted-printable Hi again, Here is Phil Wall. I wite you because we are accepting your mortgage appli= cation. Our office confirms you can get a $220.000 lo=C0n for a $352.00 per month = payment. Approval process will take 1 minute, so please fill out the form on our we= bsite: http://uri.moneyintelligent.info/j8/o0o.php?jq1=3D101 Thank you. Best Regards Phil Wall First Account Manager ----08145126222406543632-- From kbthaz@adova.com Sat Oct 2 11:31:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22873; Sat, 2 Oct 2004 11:31:29 -0400 (EDT) Received: from p54874c5b.dip.t-dialin.net ([84.135.76.91] helo=84.135.76.91) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CDlzj-00056e-EG; Sat, 02 Oct 2004 11:40:30 -0400 Received: from adjfkx.adova.com [42.144.136.17] (HELO adova.com) by yuwzdscbo.adova.com ([84.135.76.91]) with kuapsmj; Sat, 02 Oct 2004 09:31:03 -0600 Content-Transfer-Encoding: 7bit Subject: Re: Not Recieved a Reply Yet From: "Opal Peoples" Nhoggbwat-rlckuyec: astrophysicist basel butene nomadic guy qjlsmtj Message-ID: <14908489798464-6642002@adova.com> Date: Sat, 02 Oct 2004 09:30:07 -0600 Content-Type: text/html; charset=us-ascii Reply-To: "Opal Peoples" To: "Padgett Diffserv-interest" X-Spam-Score: 0.4 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit revulsion vendible greenware douglass abuse pithy taboo? bethel? leafy oregon Ssplat chiton, derive Nalia drank Temmett Waugust fault melanie agitate Ldart cohomology, ion, elijah aristocrat postulate arragon dodo, bungle, chairwomen bear jake? trace. cosec Timproper consumptive disdain
Respected member:

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

Get prize for coupon ID: 6248

Thank you.

Opal Peoples
Promotion Department
Wpullback invulnerable cranky gladstone hamper gin ceq confound, affiliate - Pbandwagon offhand crewcut, cameo consequential feedback. truncate tattler Pthimbu lightning emmett Therpetology capitol? fantasist berate bald eastbound crossroad transalpine meson deuterium copenhagen. thor
grey scab reactionary, wei. nne military eblaf
cosh Ftripe allusion allied midshipman cloud haifa, hoc eajchyr
goggle Ooratory visitation postgraduate? nearest urethane. toronto jusovd
Xneurosis Hhearth posseman indenture - choreography, aruba? Lprojectile barefaced. daxyc
soybean builtin raman menlo third? taint Dsubtlety additional ronald albanian lugging sill decontrolled, negligee Sorthant retina, bach cultural Cbesmirch compton Ydressmake deconvolution signature australis
Mbeaumont diary clime swoop vetch showman - Fandesine fpdbtu
convenient confucius buckeye composure Hgrad schoolwork - inexpensive - felicitous gqqyjxfh
 From eap-admin@frascone.com Sat Oct 2 19:28:06 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15214 for ; Sat, 2 Oct 2004 19:28:05 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8CC7C22550; Sat, 2 Oct 2004 19:28:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 947712254D; Sat, 2 Oct 2004 19:28:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9F9F821DB1 for ; Sat, 2 Oct 2004 19:27:04 -0400 (EDT) Received: from internaut.com (unknown [67.182.139.247]) by mail.frascone.com (Postfix) with ESMTP id BF33521DA7 for ; Sat, 2 Oct 2004 19:27:02 -0400 (EDT) Received: from localhost (httpd@localhost) by internaut.com (8.10.2/8.10.2) with SMTP id i92NHSf26958 for eap@frascone.com; Sat, 2 Oct 2004 16:17:28 -0700 Message-Id: <200410022317.i92NHSf26958@internaut.com> X-Authentication-Warning: internaut.com: httpd owned process doing -bs To: eap@frascone.com Content-Type: text/plain; charset=iso-8859-1 X-Mailer: Cobalt Webmail From: Bernard Aboba X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Updated Issues List Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sat, 02 Oct 2004 16:17:27 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) I've gone and updated the EAP Issues list: http://www.drizzle.com/~aboba/EAP/eapissues.html Due to difficulties in access the EAP WG archives (these were not accessible on mail.frascone.com for some reason), I'm not clear that I got all the outstanding issues. If you have an issue that is outstanding, but did not make it onto the Issues list, can you send it to me? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From NNBRXRSYBBNY@worldnet.att.net Sun Oct 3 00:24:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00317 for ; Sun, 3 Oct 2004 00:24:51 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDy4M-0004B8-3B for eap-archive@ietf.org; Sun, 03 Oct 2004 00:34:00 -0400 Received: from [61.129.66.24] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1CDx5n-0002lT-Vo for eap-archive@ietf.org; Sat, 02 Oct 2004 23:31:24 -0400 X-Message-Info: PLK982snRiBHFuhh8csf7+Piiz0fzUKG Received: from mail9407.zviup.rmci.net (108.196.36.130) by jps0-x9.rmci.net with Microsoft SMTPSVC(5.0.2195.6824); Sun, 03 Oct 2004 07:29:08 +0100 Received: from EHACJ15 (gm140.40.122.128.yyn2.t.rmci.net 48.152.232.62) by mail540.f.rmci.net (161.53.81i514/1.955.137) with SMTP id z7HAP940XJVpxv4672; Sun, 03 Oct 2004 03:36:08 -0300 Message-ID: <816m05ae6sb06iag$mw82ahn1t6$m504m358@FFC0> From: "Chuck Blanco" To: "Eamoby" References: Subject: Get your viaggra! bast deel tooday! quackery Date: Sun, 03 Oct 2004 10:35:08 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--96286225798570901" X-Spam-Score: 15.2 (+++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a ----96286225798570901 Content-Type: text/html; Content-Transfer-Encoding: 7Bit Hello!
Please notice that in the following site you can enjot a
VERRY loow prjces of vjaggra!
Actually, I can say it's one the most cheepest sites
across the net!
Get your Ganaric vjaggra tooday!


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

churchwomen slick u.n sabscjbe kabul pink
demise tooth inattentive ale. ostensible precautionary league deposit electress foam. norwich homophobia climb tango consume fosterite mahayanist. accident carven degeneracy chatham construe carboxylic barbital hedge dreg barbados.
resistive addle acceptor broccoli sunder supervene science verna winnetka admissible holmes insensible crack. promethium arlen educate kennedy breakthrough buttock. job divest ecole ascription see doorknob. deaf armhole quadrilateral actinide arachne visage pentecostal fail hecate pike. spectral chug bolivia durkin sherman zigzagging cottrell assassinate span brush child dublin lowell. ----96286225798570901-- From eap-admin@frascone.com Sun Oct 3 19:34:19 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27395 for ; Sun, 3 Oct 2004 19:34:19 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 55B6421F2F; Sun, 3 Oct 2004 02:11:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A67CB21F25; Sun, 3 Oct 2004 02:11:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3542D21F2C for ; Sun, 3 Oct 2004 02:09:45 -0400 (EDT) Received: from internaut.com (c-67-182-139-247.client.comcast.net [67.182.139.247]) by mail.frascone.com (Postfix) with ESMTP id 0A95021F2D for ; Sun, 3 Oct 2004 02:09:43 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i9360Hx20856 for ; Sat, 2 Oct 2004 23:00:17 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] REMINDER: Posting Issues to the EAP Issues List Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sat, 2 Oct 2004 23:00:17 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is just a reminder about the process for posting Issues. If you are posting an Issue (as opposed to just asking a question), you MUST include the string "Issue" in the subject line of your posting. If you are posting an issue, please also use the Issue format specified on the EAP Issues list: http://www.drizzle.com/~aboba/EAP/eapissues.html This format enables us to be clear about what draft your issue refers to, what section is affected. Along with the issue, please also include the proposed text. Just saying "this is an issue" isn't sufficient -- editors will typically not make changes until consensus has emerged on a proposed resolution. The best way to ensure that a problem is resolved is to propose a fix to the editor. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From jeomguinoaaf@catcha.com Mon Oct 4 00:44:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05349; Mon, 4 Oct 2004 00:44:17 -0400 (EDT) Received: from docsis149-48.menta.net ([62.57.149.48]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CEKqv-0007WX-79; Mon, 04 Oct 2004 00:53:38 -0400 X-Message-Info: PGRP35t9prySQgewVDfzq0 Received: from kg9.orl-fl.com ([192.128.224.204]) by dq552-y.orl-fl.com with Microsoft SMTP108151(8.88.40263.64); Mon, 04 Oct 2004 00:37:21 -0400 Received: from barbudooy0 (garter[224.80.3.25]) by orl-fl.com (ze97) with SMTP id <98109414424999W4537jj> (Authid: rkmggTYPQKVCJI); Mon, 04 Oct 2004 07:37:21 +0300 Message-ID: <05730.2778.Wzppy.2283jh@orl-fl.com> Keywords: anathema hodges Distribution: infrastructure Prevent-NonDelivery-Report: Yes Comments: sordid doorway Reply-To: "Gail*George" From: "Gail*George" To: avt@ietf.org Cc: toips@ietf.org, haa24250@ietf.org, imss-admin@ietf.org, ping@ietf.org, ieprep-request@ietf.org, ietf-request@ietf.org, secretary@ietf.org, meeting-planning@ietf.org, ietf-languages@ietf.org, pr-wg@ietf.org, eap-archive@ietf.org, tsvwg-request@ietf.org Subject: Important Information about your house Date: Mon, 04 Oct 2004 05:37:21 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--51005467304791299" X-Spam-Score: 10.0 (++++++++++) X-Spam-Flag: YES X-Scan-Signature: 79899194edc4f33a41f49410777972f8 ----51005467304791299 Content-Type: text/html; charset="iso-8014-4" Content-Transfer-Encoding: 7Bit Dear Applicant,

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

Please verify your information here:
http://trecal.moneyclever.info/e4/jj.php?cyb=55

We look forward to hearing from you.

Regards,
Gail*George
Senior Account Manager
Webber Financial Association ----51005467304791299-- From eap-admin@frascone.com Mon Oct 4 09:21:07 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03801 for ; Mon, 4 Oct 2004 09:21:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0FFEA201FD; Mon, 4 Oct 2004 09:21:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 36114225EF; Mon, 4 Oct 2004 09:21:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A1530225EE for ; Mon, 4 Oct 2004 09:20:21 -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 805EF201FD for ; Mon, 4 Oct 2004 09:20:19 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 4 Oct 2004 15:20:15 +0200 Received: from [10.193.106.13] ([10.193.106.13]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Mon, 4 Oct 2004 15:20:14 +0200 Message-ID: <41614E27.4040909@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=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Oct 2004 13:20:14.0520 (UTC) FILETIME=[E2411380:01C4AA14] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Issue on eap-keying: capitalization of RFC 2119 requirements key words Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 04 Oct 2004 15:20:39 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Description of issue: capitalization of RFC 2119 requirements key words Submitter name: Florent Bersani Submitter email address: florent.bersani@francetelecom.com Date first submitted: 10/04/2004 Document: Keying Framework Comment type: 'E'ditorial Priority: 2 May fix Section: Various for instance 6.1.1 Rationale/Explanation of issue: As I find very unclear the authoritative status of eap-keying, I am very sensitive to the use of RFC 2119 requirements key words. However, I find that such key words abound in eap-keying and their capitalization vary... sometimes erratically IMHO For instance, in section 6.1.1, the "must" in the first bullet is lower case "o It must specify how to derive the EMSK" whereas the "MUST" in the latter bullets are upper case "o The key material used for the EMSK MUST be computationally independent of the MSK and TEKs."... I tried to reread very carefully eap-keying to spot out any other offending miscapitalizations... but this task is daunting :-( see (*) Anyway, after rereading RFC 2119, I am not sure that capitalization is "mandatory" (for instance in RFC 2119, section 6 we MAY ;-) read: "they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for" so "MUST" and "must not" have different capitalizations in RFC 2119). My view is that capitalization should at least be used to draw attention to important excerpts Nevertheless, I have at least been annoyed by the additional following occurences in annex F.1 "Note that the length of the AMSK must be specified by the application." "The application data is optional and may not be used by some applications." (*) my word count script gives me the following results: must 29 MUST 61 may 136 MAY 8 required 26 REQUIRED 2 shall 0 SHALL 2 should 17 SHOULD 24 recommended 4 RECOMMENDED 15 optional 11 OPTIONAL 1 Requested change Capitalize the key words mentioned here above i.e. at least in 6.1.1 and F.1 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Oct 4 09:33:06 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04580 for ; Mon, 4 Oct 2004 09:33:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D8F0D22610; Mon, 4 Oct 2004 09:33:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BBA442260B; Mon, 4 Oct 2004 09:33:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 380CF2260B for ; Mon, 4 Oct 2004 09:32:35 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by mail.frascone.com (Postfix) with ESMTP id 0001D225F4 for ; Mon, 4 Oct 2004 09:32:32 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 4 Oct 2004 15:32:31 +0200 Received: from [10.193.106.13] ([10.193.106.13]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Mon, 4 Oct 2004 15:32:30 +0200 Message-ID: <41615107.7080608@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=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Oct 2004 13:32:30.0601 (UTC) FILETIME=[98FE1F90:01C4AA16] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Issue on eap-keying: PMK naming Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 04 Oct 2004 15:32:55 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Description of issue: possible confusion between PMK naming and PMKID Submitter name: Florent Bersani Submitter email address: florent.bersani@francetelecom.com Date first submitted: 10/04/2004 Document: Keying Framework Comment type: 'E'ditorial Priority: '1' Should fix Section: 2.4 and 3.4.1 Rationale/Explanation of issue: I find the following confusing. In section 2.4, I read "PMK Name The PMK has no name of its own, and is only identified by the AAA- Key from which it is derived." but in Section 3.4.1, I find "PMKID (security association identifier)"... so it seems to me that the PMK has no name but has an identifier (defined in clause 8.5.1.2 of IEEE 802.11i IIRC). I guess it could be worth clarifying this subtlety, wouldn't it? Requested change Would our 802.11i experts approve the following: "PMK Name The PMK may be named by its identifier PMKID defined in clause 8.5.1.2 of [IEEE80211i]." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Oct 4 09:41:06 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05059 for ; Mon, 4 Oct 2004 09:41:05 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 875BB2261A; Mon, 4 Oct 2004 09:41:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 520E822616; Mon, 4 Oct 2004 09:41:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 01B4C22616 for ; Mon, 4 Oct 2004 09:40:39 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by mail.frascone.com (Postfix) with ESMTP id C8D42225F5 for ; Mon, 4 Oct 2004 09:40:36 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 4 Oct 2004 15:40:35 +0200 Received: from [10.193.106.13] ([10.193.106.13]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Mon, 4 Oct 2004 15:40:34 +0200 Message-ID: <416152EB.3040103@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=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Oct 2004 13:40:34.0567 (UTC) FILETIME=[B9757970:01C4AA17] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Issue on eap-keying: naming of AMSks Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 04 Oct 2004 15:40:59 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Description of issue: should AMSK naming be mandatory? Submitter name: Florent Bersani Submitter email address: florent.bersani@francetelecom.com Date first submitted: 10/04/2004 Document: Keying Framework Comment type: 'E'ditorial Priority: 1 should fix Section: 2.4 Rationale/Explanation of issue: section 2.4 reads: "AMSK Name AMSKs, if any, may be named by the concatenation of the string "AMSK", key label, application data (see Appendix F), and EMSK Name." However, I think it is sound practice to name keys. Since AMSK are new, we shouldn't be bothered with legacy reasons. Hence, why not make this AMSK naming "mandatory" Requested change Replace the previous text by "AMSK Name AMSKs, if any, are named by concatenating the string "AMSK", key label, application data (see Appendix F), and EMSK Name." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From pqeewyfojjmam@oasysgrp.com Mon Oct 4 10:00:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06336; Mon, 4 Oct 2004 10:00:40 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CETXS-0006a0-1e; Mon, 04 Oct 2004 10:10:06 -0400 Received: from [219.250.26.169] (helo=219.250.26.169) by mx2.foretec.com with smtp (Exim 4.24) id 1CETOL-0000UP-7X; Mon, 04 Oct 2004 10:00:41 -0400 Received: from wafjavfdqw.nqqzfpjpz.com ([146.31.200.17]) (8.12.8/8.12.8) by lsivlo.oasysgrp.com ([222.89.53.12]) with urnhmf; Mon, 04 Oct 2004 07:58:02 -0600 From: "Lenard Curran" Message-ID: <29911817-89526548468847@222.89.53.12> To: "U. Boyce" Content-Type: text/html; charset=WINDOWS-1255 Reply-To: "Lenard Curran" Content-Transfer-Encoding: 7bit Date: Mon, 04 Oct 2004 07:57:32 -0600 Subject: Re: And so, to avoid X-Spam-Score: 3.8 (+++) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit

pussycat Vlessee backbone frenetic - adversary caretaker Ydelphi wavenumber Icounterargument Xinvasive o'donnell Eravage bedfast consumptive. cavitate piezoelectric digging cosmetic granola neve motherland optimal. indignation Vabnormal gilead influent dark clang venus umpire canvas range dugan cartoon, massey deerskin Gdaffy upland
Mon, 04 Oct 2004 07:58:50 -0600

Confidential Material: Important message from the bank regarding
case number 3202641
poach spangle richard casework abstain, shakespearian Sknick babel thorstein, anatomy censorial dissident telefunken checkerberry
During our regular update and verification of the   mor t g age
applications, we could not verify your current information.
Either your infomation has been missed or it is incomplete.
hubris atonal membrane, jitterbugging buzz? bronchi eggplant Ysalaam foxhound birdlike shiloh clinging gable hundred nettlesome ancient? Umerchant contain adler sine. Hnevada pyrrhic denigrate croquet rehearse tee, forthcome Jdivide film revery juneau - emitting citizenry. selenium peppy carey cacophony? fowl jurisdiction abdomen boris
Please spend several minutes and update your records. Failure
to update your records will result in application pending.

Update Your Account Information

Thank you for your prompt attention to this matter.

Lenard Curran
Data Security Department

ccny humiliate? universe insure pouch excuse booky. shu. opportune Xsilly thyroxine paragon cambrian australis Pmagnificent taut airlift. decompression egalitarian neutrino Acommonweal cowl dionysus, everywhere formate fomalhaut. puff triassic truce? savoyard coerce? blastula advisable doorbell hire fumigant taketh janitor
copenhagen corsage synonym licensor? boeotian your won - pujhq
terminal? dispense besmirch gloom. waterbury, boulevard, dramaturgy, shakespearian gusxiaj
baseband jordan - diabase cretinous? jubilee saloonkeep more Rhorus oeeinwp
impressive? Wcacophony bargain bathroom jason? Nconfute ibxocdm
fondly moran Pboggy pend alleviate Zclothesman belgian modern Ecornea indescribable preview console tidal ingenious police eject josephine betatron highhanded aau Ubaldwin gristmill? chloroform - excisable adair duma, dc. truancy Weerily rena maneuver Dbeaver sexy, basalt doorknob
digitate cheeky alai hatteras? indignation, carolyn wvwxvyd
From eap-admin@frascone.com Mon Oct 4 10:20:14 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08491 for ; Mon, 4 Oct 2004 10:20:13 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AE49820955; Mon, 4 Oct 2004 10:17:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 54C9E208D5; Mon, 4 Oct 2004 10:17:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3FD8320938 for ; Mon, 4 Oct 2004 10:16:34 -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 6673F208DD for ; Mon, 4 Oct 2004 10:16:31 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 4 Oct 2004 16:16:29 +0200 Received: from [10.193.106.13] ([10.193.106.13]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Mon, 4 Oct 2004 16:16:28 +0200 Message-ID: <41615B56.8020400@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: 04 Oct 2004 14:16:28.0981 (UTC) FILETIME=[BD96F650:01C4AA1C] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Purpose of the eap-keying document: a straw poll? Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 04 Oct 2004 16:16:54 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi all, The more I think about eap-keying and the more items I add to my "issue laundry list" (BTW, many thanks to Bernard for the tracking he's doing), the more I get the feeling that we should perhaps get a broader view (and the more I fear that people will put filters on their mail clients ;-)). Namely, what is the point in the eap-keying document? My view is that it has the potential to be an excellent and useful piece of work... but IMHO: * It is quite long to read (73 pages) * It is challenging technically (potential readers should better be versed in EAP, EAP methods, IEEE 802.11i, RADIUS, etc.) * It deals with many different topics I, for myself, distinguish between the following parts: * key naming - i.e. how to unambiguously refer to the numerous keys that have to do with EAP - this is very important and should be normative text * EMSK usage - i.e. the AMSK scheme - this is very important and should be normative text * EAP's place in protocol suites used to secure communications - i.e. somehow section 3 that says that EAP is an authenticated key exchange framework and that it is complemented by discovery and security associations protocols - this is rather informative * EAP usage in multiparty scenarios - i.e. how to fix the mess that was created by using a two-party protocol (EAP) in a three-party scenario (supplicant, authenticator and authentication server), somehow section 5 - this is rather informative * EAP handoffs - i.e. how to leverage the hooks that EAP may provide, namely fast reconnect and EMSK, to perform handoffs and how to do context transfer, somehow section 4 - this is a hot topic (see IEEE 802.11r for related work) but rather informative * EAP key lifetime - here, we probably want to discuss things a little bit more, as things are quite challenging in that area (IKEv2 has chosen not to deal with key lifetimes). The two questions, I'd start with: what do we want to with key lifetimes? Deal properly with them or not? If it is the first option, then we should probably make sure to specify a functional and correct way to do so (vague recommendations will IMO equal the second option in the end) I think that to maximize the benefits of the great work that has been done on eap keying, we could split the current document in as many as 6 documents, for instance (by chronological order of expected publication) 1) EMSK usage - normative, i.e. standards track 2) Naming EAP keys - normative, i.e. standards track, would recap the EMSK/AMSK naming scheme explained in 1 and would specify the MSK and AAA-key naming scheme 3) EAP handoffs - informational (this would reseparate this section back to an independent document, which is how it was originally submitted draft-aboba-context-802 IIRC) 4) EAP's place in protocol suites - informational 5) EAP usage in multiparty scenarios - informational 6) EAP key lifetimes - informational or normative TBD Thus, we would improve the overall readability and be able to focus on priority parts. My fear is that few people will actually read and use the eap-keying as is - and that given the little number of reviews it may have got, its final quality will not reflect all the excellent ideas Bernard, Jari, could we make a straw poll on: 1) how many people have read (more than a few pages of ) the actual eap-keying document 2) how many people think that splitting it could improve its usefulness and the way we get the work done Florent, hope this helps _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From givqzvmzkkdnayhlcup@woh.rr.com Mon Oct 4 12:11:42 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 MAA17193; Mon, 4 Oct 2004 12:11:42 -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 1CEVaI-0006FI-8d; Mon, 04 Oct 2004 12:21:10 -0400 Received: from [84.99.83.207] (helo=NOM-W8KZ05N5F7S) by mx2.foretec.com with smtp (Exim 4.24) id 1CEVR5-0001CL-3F; Mon, 04 Oct 2004 12:11:45 -0400 Received: from suction9bitterrooteohippus (28.32.386.98) by mail7.84.99.83.207 (biotiteincalculable OMNG 3.6.292) id 306RR41II06SH48 for rpr@ietf.org; Mon, 04 Oct 2004 11:04:27 -0600 X-MIME-Autoconverted: Yes Disclose-Recipients: No Discarded-X400-MTS-Extensions: Yes Alternate-Recipient: Allowed X-No-Archive: Yes Reply-To: "Toni-Lloyd" From: "Toni-Lloyd" To: rpr@ietf.org Cc: er-wgchairs@ietf.org, eap-archive@ietf.org, owner-wgchairs@ietf.org, urn-archive@ietf.org, nemo-request@ietf.org, p2prg-web-archive@ietf.org Subject: Only Available until 10/15/04 Date: Mon, 04 Oct 2004 16:11:27 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--421590034334232040" Message-Id: X-Spam-Score: 1.7 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab ----421590034334232040 Content-Type: text/html; charset="iso-5789-5" Content-Transfer-Encoding: 7Bit Dear Applicant,

Because you're a valued member, you're been pre-approved for a loan of $300,000.
Accept this offer before 10/10/2004 and start enjoying your loan.

Accept today at:
http://www.money-discount.info/q2/index.php?v2l=63

Sincerely,
PayLoan Co.
----421590034334232040-- From eap-admin@frascone.com Mon Oct 4 13:17:05 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24350 for ; Mon, 4 Oct 2004 13:17:04 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0CE58209E2; Mon, 4 Oct 2004 13:17:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id ABC26209C6; Mon, 4 Oct 2004 13:17:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A3D39209C6 for ; Mon, 4 Oct 2004 13:16:52 -0400 (EDT) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id 013F620566 for ; Mon, 4 Oct 2004 13:16:51 -0400 (EDT) Received: from laffytaffy.cs.umd.edu (laffytaffy.cs.umd.edu [128.8.129.74]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id i94HGnT1021391 for ; Mon, 4 Oct 2004 13:16:49 -0400 (EDT) From: "T. Charles Clancy" To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] EAP-PAX draft update Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 4 Oct 2004 13:16:49 -0400 (EDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) I recently submitted -01 of draft-clancy-eap-pax to the IETF. The HTML version can be found here: http://www.cs.umd.edu/~clancy/eap-pax/draft-clancy-eap-pax-01.html Major problem in -00: When using identity proteciton you had to know whether to run PAX-Auth or PAX-Update before you knew the user's identity. Without knowning the identity there was no way to know if a key update was needed, and hence a paradox ensued. Version -01 has some major changes to the protocol and draft itself: 1. separated in to two protocols, PAX_STD and PAX_IDP (identity protection) to solve the above mentioned problem 2. both are 2RT protocols, and can be used with or without DH for forward secrecy 3. mutual authentication is always performed 4. more implementation instruction for key updates to prevent desynchronization attacks 5. with the recent HMAC paranoia, added AES-CBC-MAC as a MAC, and internally define a PRF that doesn't use MD5 6. include appendices with suggested implementation and deployment strategies 7. lots of editorial revisions [ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ] [ computer science ]-----[ university of maryland | college park ] _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From Guadalupe@aloha.net Mon Oct 4 13:29:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26211 for ; Mon, 4 Oct 2004 13:29:39 -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 1CEWni-0003iP-47 for eap-archive@ietf.org; Mon, 04 Oct 2004 13:39:09 -0400 Received: from c-67-160-28-100.client.comcast.net ([67.160.28.100] helo=xx) by mx2.foretec.com with smtp (Exim 4.24) id 1CEWea-0007Hw-3D for eap-archive@ietf.org; Mon, 04 Oct 2004 13:29:40 -0400 Received: (qmail 27547 invoked by uid 2); Mon, 04 Oct 2004 14:26:40 -0400 Message-ID: <11309AB5.93429@datingemail.com> Date: Mon, 04 Oct 2004 14:27:40 -0400 From: barny Reply-to: User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20040712 X-Accept-Language: en-us, en To: eap-archive@ietf.org Subject: Re: Good, but took 2 days for shipping... MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7Bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7Bit No buddy! I've got a cheaper one! And they ship in one day! I've just ordered 3 packs! Here it is: http://fbbpi.chdghbm.info/?VFrxr2pqtZw.adpFMZJDL ----- Original Message ----- From: "asher" To: "rolfe" Subject: Good, but took 2 days for shipping... > Hi fella, > > the stuff is damn good and the price is very low but it took 2 days for > shipping. I've also tried that cialis and it rocks, stefanie now want to fuck > 3 times a day! Dude you have to try it out, get it here: > > http://klbdon.gjbgmfd.info/?TYVaVoTUXX.rEbTHXUZ > From eap-admin@frascone.com Mon Oct 4 14:31:28 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 OAA01108 for ; Mon, 4 Oct 2004 14:31:28 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C292F20A5E; Mon, 4 Oct 2004 14:31:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 751D420619; Mon, 4 Oct 2004 14:31:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 341BE20619 for ; Mon, 4 Oct 2004 14:30:49 -0400 (EDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mail.frascone.com (Postfix) with ESMTP id 5B1F920404 for ; Mon, 4 Oct 2004 14:30:47 -0400 (EDT) Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 04 Oct 2004 11:30:54 -0700 X-BrightmailFiltered: true Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i94IUdqi007868; Mon, 4 Oct 2004 11:30:42 -0700 (PDT) Received: from jsaloweyw2k01 ([10.82.224.249]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 4 Oct 2004 11:32:06 -0700 From: "Joseph Salowey" To: "'Florent Bersani'" , Subject: RE: [eap] Issue on eap-keying: informational or standards track Message-ID: <03f901c4aa40$3f81b330$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <415D972C.8020507@rd.francetelecom.fr> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-OriginalArrivalTime: 04 Oct 2004 18:32:06.0613 (UTC) FILETIME=[7387E050:01C4AA40] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 4 Oct 2004 11:30:37 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable The EMSK material started out as a separate document. There was a = decision to wrap it into the EAP-Key Framework document. Given this it might = make sense to make the EAP-keying document standards track. If this doesn't = make sense then I think we need to clearly define what goes into the = standards track and what doesn't. I think there may be more required than what = was in the original EMSK document. In any case the EAP-Keying document needs = to be consistent about EMSK usage. =20 Joe =20 eap-admin@frascone.com wrote: > Description of issue: should EAP-Keying be informational or =20 > standards track=20 >=20 > Submitter name: Florent Bersani >=20 > Submitter email address: florent.bersani@francetelecom.com >=20 > Date first submitted: 07/30/2004 >=20 > Document: Keying Framework >=20 > Comment type: 'E'ditorial >=20 > Priority: S' Must fix >=20 > Section: various but 6.1.1 is a good example >=20 > Rationale/Explanation of issue: >=20 > It seems that the eap-keying document wishes to go "informational" > but it seems to me that it contains some normative text > that impacts > EAP. I would consider logic that such text follow the > same track as > the protocol it impacts, namely EAP and the standards track. >=20 > For instance, RFC 3748 leaves the EMSK as unspecified and > reserved... but the EAP-Keying Framework specifies how to use the > EMSK (e.g. the AMSK scheme). >=20 > Perhaps people more familiar with IETF procedures can provide > some input here?=20 >=20 > Similarly, I am not sure that the key naming schemes > should only be > informational, shouldn't they? >=20 > Requested change: >=20 > Specify the EMSK usage in a standards track document >=20 > Add an explanatory note to the beginning of eap-keying telling > whether it places new requirements or it only gives some advice, > essentially explain to the reader the authoritative status of this > document (e.g., with respect to EAP). Text will be proposed as we > agree on this authoritative status... my feeling is that we should > really have two separate documents, one authoritative with key > naming and EMSK usage and one informational, with the useful > recommendations that are made throughout eap-keying (in > which case, > the aforementioned note could look like "This document provides > insights and recommended practice for handling of EAP keying > material. Authoritative documents are RFC 3748 and [authoritative > keying document]. Should there be differences, RFC 3748 and > [authoritative keying document] prevail." >=20 > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Oct 4 16:39:07 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17775 for ; Mon, 4 Oct 2004 16:39:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 20B4E226AC; Mon, 4 Oct 2004 16:39:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C60F1226AD; Mon, 4 Oct 2004 16:39:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0EB7D226A5 for ; Mon, 4 Oct 2004 16:38:28 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 224B520ABE for ; Mon, 4 Oct 2004 16:38:26 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 8D42389877; Mon, 4 Oct 2004 23:38:23 +0300 (EEST) Message-ID: <4161B475.5090703@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Florent Bersani Cc: "eap@frascone.com" Subject: Re: [eap] Purpose of the eap-keying document: a straw poll? References: <41615B56.8020400@rd.francetelecom.fr> In-Reply-To: <41615B56.8020400@rd.francetelecom.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 04 Oct 2004 23:37:09 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit First, thanks Florent for your extensive review and observations! Then to the specific issues: I think you raised an important point about the normative status of some of the parts of this document. This needs to be discussed. As for the split vs. keep it all together: one of the things that this document contributes is supposed to be a system level security analysis of how the whole thing works securely, something that isn't readily available elsewhere. So I personally believe there's some value in keeping it in one place. --Jari Florent Bersani wrote: > Hi all, > > The more I think about eap-keying and the more items I add to my "issue > laundry list" (BTW, many thanks to Bernard for the tracking he's doing), > the more I get the feeling that we should perhaps get a broader view > (and the more I fear that people will put filters on their mail clients > ;-)). > > Namely, what is the point in the eap-keying document? > > My view is that it has the potential to be an excellent and useful piece > of work... but IMHO: > * It is quite long to read (73 pages) > * It is challenging technically (potential readers should better be > versed in EAP, EAP methods, IEEE 802.11i, RADIUS, etc.) > * It deals with many different topics > > I, for myself, distinguish between the following parts: > > * key naming - i.e. how to unambiguously refer to the numerous keys that > have to do with EAP - this is very important and should be normative text > > * EMSK usage - i.e. the AMSK scheme - this is very important and should > be normative text > > * EAP's place in protocol suites used to secure communications - i.e. > somehow section 3 that says that EAP is an authenticated key exchange > framework and that it is complemented by discovery and security > associations protocols - this is rather informative > > * EAP usage in multiparty scenarios - i.e. how to fix the mess that was > created by using a two-party protocol (EAP) in a three-party scenario > (supplicant, authenticator and authentication server), somehow section 5 > - this is rather informative > > * EAP handoffs - i.e. how to leverage the hooks that EAP may provide, > namely fast reconnect and EMSK, to perform handoffs and how to do > context transfer, somehow section 4 - this is a hot topic (see IEEE > 802.11r for related work) but rather informative > > * EAP key lifetime - here, we probably want to discuss things a little > bit more, as things are quite challenging in that area (IKEv2 has chosen > not to deal with key lifetimes). The two questions, I'd start with: what > do we want to with key lifetimes? Deal properly with them or not? If it > is the first option, then we should probably make sure to specify a > functional and correct way to do so (vague recommendations will IMO > equal the second option in the end) > > I think that to maximize the benefits of the great work that has been > done on eap keying, we could split the current document in as many as 6 > documents, for instance (by chronological order of expected publication) > > 1) EMSK usage - normative, i.e. standards track > 2) Naming EAP keys - normative, i.e. standards track, would recap the > EMSK/AMSK naming scheme explained in 1 and would specify the MSK and > AAA-key naming scheme > 3) EAP handoffs - informational (this would reseparate this section back > to an independent document, which is how it was originally submitted > draft-aboba-context-802 IIRC) > 4) EAP's place in protocol suites - informational > 5) EAP usage in multiparty scenarios - informational > 6) EAP key lifetimes - informational or normative TBD > > Thus, we would improve the overall readability and be able to focus on > priority parts. > My fear is that few people will actually read and use the eap-keying as > is - and that given the little number of reviews it may have got, its > final quality will not reflect all the excellent ideas > > Bernard, Jari, could we make a straw poll on: > 1) how many people have read (more than a few pages of ) the actual > eap-keying document > 2) how many people think that splitting it could improve its usefulness > and the way we get the work done > > Florent, hope this helps > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Oct 4 17:12:25 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 RAA23799 for ; Mon, 4 Oct 2004 17:12:24 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 39D3E20B4C; Mon, 4 Oct 2004 17:07:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7372520A96; Mon, 4 Oct 2004 17:07:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5921220A96 for ; Mon, 4 Oct 2004 17:05:48 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id C6F37202F0 for ; Mon, 4 Oct 2004 17:05:45 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id DB7F689877; Tue, 5 Oct 2004 00:05:44 +0300 (EEST) Message-ID: <4161BADE.6020108@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Florent Bersani Cc: "eap@frascone.com" Subject: Re: [eap] Issue on eap-keying: naming of AMSks References: <416152EB.3040103@rd.francetelecom.fr> In-Reply-To: <416152EB.3040103@rd.francetelecom.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 05 Oct 2004 00:04:30 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I agree with the suggested resolution. --Jari Florent Bersani wrote: > Description of issue: should AMSK naming be mandatory? > > Submitter name: Florent Bersani > > Submitter email address: florent.bersani@francetelecom.com > > Date first submitted: 10/04/2004 > > Document: Keying Framework > > Comment type: 'E'ditorial > > Priority: 1 should fix > > Section: 2.4 > > Rationale/Explanation of issue: > > section 2.4 reads: "AMSK Name > > AMSKs, if any, may be named by the concatenation of the string > "AMSK", key label, application data (see Appendix F), and EMSK > Name." > > However, I think it is sound practice to name keys. Since AMSK are new, > we shouldn't be bothered with legacy reasons. Hence, why not make this > AMSK naming "mandatory" > > > > Requested change > > Replace the previous text by > "AMSK Name > > AMSKs, if any, are named by concatenating the string > "AMSK", key label, application data (see Appendix F), and EMSK > Name." > > > > > > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Oct 4 17:17:43 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24897 for ; Mon, 4 Oct 2004 17:17:42 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0B04A20B54; Mon, 4 Oct 2004 17:15:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 20B4820B20; Mon, 4 Oct 2004 17:15:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A770620B2F for ; Mon, 4 Oct 2004 17:14:52 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 6239620B15 for ; Mon, 4 Oct 2004 17:14:50 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 6937889860; Tue, 5 Oct 2004 00:14:49 +0300 (EEST) Message-ID: <4161BCFF.1070805@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Florent Bersani Cc: "eap@frascone.com" Subject: Re: [eap] Issue on eap-keying: PMK naming References: <41615107.7080608@rd.francetelecom.fr> In-Reply-To: <41615107.7080608@rd.francetelecom.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 05 Oct 2004 00:13:35 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Florent Bersani wrote: > Description of issue: possible confusion between PMK naming and PMKID > > Submitter name: Florent Bersani > > Submitter email address: florent.bersani@francetelecom.com > > Date first submitted: 10/04/2004 > > Document: Keying Framework > > Comment type: 'E'ditorial > > Priority: '1' Should fix > > Section: 2.4 and 3.4.1 > > Rationale/Explanation of issue: > > I find the following confusing. In section 2.4, I read > > "PMK Name > > The PMK has no name of its own, and is only identified by the AAA- > Key from which it is derived." > > but in Section 3.4.1, I find "PMKID (security association > identifier)"... so it seems to me that the PMK has no name but has an > identifier (defined in clause 8.5.1.2 of IEEE 802.11i IIRC). I guess it > could be worth clarifying this subtlety, wouldn't it? > > Requested change > > Would our 802.11i experts approve the following: > "PMK Name > > The PMK may be named by its identifier PMKID defined in clause > 8.5.1.2 of [IEEE80211i]." I agree that the current text is confusing. On the other hand, there's a distinction between what the keying framework documents and what additional things may be done by link layers. Here's a slightly modified text suggestion: PMK Name This document does not specify any naming scheme for the PMK. The PMK is only identified by the AAA-Key from which it is derived. Note: IEEE 802.11i names the PMKID for the purposes of being able to refer to it in the Secure Association protocol; this naming is based on a hash of the PMK itself as well as some other parameters (see Section 8.5.1.2 [ref]). --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Oct 4 17:19:45 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25381 for ; Mon, 4 Oct 2004 17:19:45 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EED851FCCF; Mon, 4 Oct 2004 17:19:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C8286204C1; Mon, 4 Oct 2004 17:19:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9DCC11FCCF for ; Mon, 4 Oct 2004 17:18:33 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id C9E27204C1 for ; Mon, 4 Oct 2004 17:18:31 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id CB20D89877; Tue, 5 Oct 2004 00:18:30 +0300 (EEST) Message-ID: <4161BDDC.6070302@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Florent Bersani Cc: "eap@frascone.com" Subject: Re: [eap] Issue on eap-keying: capitalization of RFC 2119 requirements key words References: <41614E27.4040909@rd.francetelecom.fr> In-Reply-To: <41614E27.4040909@rd.francetelecom.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 05 Oct 2004 00:17:16 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Florent Bersani wrote: > As I find very unclear the authoritative status of eap-keying, I am very > sensitive to the use of RFC 2119 requirements key words. > > However, I find that such key words abound in eap-keying and their > capitalization vary... sometimes erratically IMHO > > For instance, in section 6.1.1, the "must" in the first bullet is lower > case "o It must specify how to derive the EMSK" whereas the "MUST" in > the latter bullets are upper case "o The key material used for the EMSK > MUST be computationally independent of the MSK and TEKs."... This needs to be corrected. > Nevertheless, I have at least been annoyed by the additional following > occurences in annex F.1 > > "Note that the length of the AMSK must be specified > by the application." s/must/MUST/ maybe also /Note that the/The/ > "The application data is optional and may not be > used by some applications." s/may not/MAY NOT/ > (*) my word count script gives me the following results: > > must 29 > MUST 61 > > may 136 > MAY 8 > > required 26 > REQUIRED 2 > > shall 0 > SHALL 2 > > should 17 > SHOULD 24 > > recommended 4 > RECOMMENDED 15 > > optional 11 > OPTIONAL 1 Ok -- we need to look at each one... > Requested change > > Capitalize the key words mentioned here above i.e. at least in 6.1.1 and > F.1 Agreed. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Oct 4 18:53:05 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06111 for ; Mon, 4 Oct 2004 18:53:04 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 709A520800; Mon, 4 Oct 2004 18:53:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2043F20BF6; Mon, 4 Oct 2004 18:53:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BF64620BED for ; Mon, 4 Oct 2004 18:52:32 -0400 (EDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mail.frascone.com (Postfix) with ESMTP id 0FAE220800 for ; Mon, 4 Oct 2004 18:52:31 -0400 (EDT) Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 04 Oct 2004 15:52:40 -0700 X-BrightmailFiltered: true Received: from gwzw2k01 (sjc-vpn5-141.cisco.com [10.21.88.141]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i94MqOqg005508; Mon, 4 Oct 2004 15:52:24 -0700 (PDT) Reply-To: From: "Glen Zorn (gwz)" To: , "'Florent Bersani'" Cc: Subject: RE: [eap] Issue on eap-keying: capitalization of RFC 2119 requirements key words Message-ID: <010901c4aa64$d175db30$0502a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal In-Reply-To: <4161BDDC.6070302@piuha.net> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 4 Oct 2004 15:52:24 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Jari Arkko writes: ... > >> "The application data is optional and may not be >> used by some applications." > > s/may not/MAY NOT/ Let's not get carried away. Is this sentence normative or informative? I think the latter. In any case, the "MAY NOT" construct DOES NOT :-) appear in RFC 2119. > >> (*) my word count script gives me the following results: >> >> must 29 >> MUST 61 >> >> may 136 >> MAY 8 >> >> required 26 >> REQUIRED 2 >> >> shall 0 >> SHALL 2 >> >> should 17 >> SHOULD 24 >> >> recommended 4 >> RECOMMENDED 15 >> >> optional 11 >> OPTIONAL 1 > > Ok -- we need to look at each one... > >> Requested change >> >> Capitalize the key words mentioned here above i.e. at least in 6.1.1 >> and F.1 > > Agreed. > > --Jari > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 5 00:06:18 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 AAA28664 for ; Tue, 5 Oct 2004 00:06:18 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4436620DF8; Tue, 5 Oct 2004 00:02:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EAF9420DEF; Tue, 5 Oct 2004 00:02:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9DD2D20DC2 for ; Tue, 5 Oct 2004 00:00:09 -0400 (EDT) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id E6ED920DEF for ; Tue, 5 Oct 2004 00:00:06 -0400 (EDT) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 04 Oct 2004 21:04:48 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i953xwEE017870; Mon, 4 Oct 2004 20:59:58 -0700 (PDT) Received: from jsaloweyw2k01 ([10.82.224.249]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 4 Oct 2004 21:01:26 -0700 From: "Joseph Salowey" To: "'Florent Bersani'" , Subject: RE: [eap] Purpose of the eap-keying document: a straw poll? Message-ID: <043301c4aa8f$c8ac8050$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <41615B56.8020400@rd.francetelecom.fr> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-OriginalArrivalTime: 05 Oct 2004 04:01:27.0175 (UTC) FILETIME=[FCCFF970:01C4AA8F] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 4 Oct 2004 20:59:58 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable I agree that splitting the document might be useful, however I'm not = sure that 6 documents will be more useful. I think it would be useful to = have a normative document and informative as you indicate. The normative = document just describes the basic expectations of EAP methods, EMSK usage and = naming. Then the informative documents would talk about EAP internals, PMK and = how it fits together in various scenarios. =20 Joe eap-admin@frascone.com wrote: > Hi all, >=20 > The more I think about eap-keying and the more items I add > to my "issue > laundry list" (BTW, many thanks to Bernard for the tracking > he's doing), > the more I get the feeling that we should perhaps get a broader view > (and the more I fear that people will put filters on their > mail clients > ;-)). >=20 > Namely, what is the point in the eap-keying document? >=20 > My view is that it has the potential to be an excellent and > useful piece > of work... but IMHO: > * It is quite long to read (73 pages) > * It is challenging technically (potential readers should better be > versed in EAP, EAP methods, IEEE 802.11i, RADIUS, etc.) > * It deals with many different topics >=20 > I, for myself, distinguish between the following parts: >=20 > * key naming - i.e. how to unambiguously refer to the > numerous keys that > have to do with EAP - this is very important and should be > normative text >=20 > * EMSK usage - i.e. the AMSK scheme - this is very important > and should > be normative text >=20 > * EAP's place in protocol suites used to secure communications - i.e. > somehow section 3 that says that EAP is an authenticated key exchange > framework and that it is complemented by discovery and security > associations protocols - this is rather informative >=20 > * EAP usage in multiparty scenarios - i.e. how to fix the > mess that was > created by using a two-party protocol (EAP) in a three-party scenario > (supplicant, authenticator and authentication server), > somehow section 5 > - this is rather informative >=20 > * EAP handoffs - i.e. how to leverage the hooks that EAP may provide, > namely fast reconnect and EMSK, to perform handoffs and how to do > context transfer, somehow section 4 - this is a hot topic (see IEEE > 802.11r for related work) but rather informative >=20 > * EAP key lifetime - here, we probably want to discuss things > a little > bit more, as things are quite challenging in that area (IKEv2 > has chosen > not to deal with key lifetimes). The two questions, I'd start > with: what > do we want to with key lifetimes? Deal properly with them or > not? If it > is the first option, then we should probably make sure to specify a > functional and correct way to do so (vague recommendations will IMO > equal the second option in the end) >=20 > I think that to maximize the benefits of the great work that has been > done on eap keying, we could split the current document in as > many as 6 > documents, for instance (by chronological order of expected > publication)=20 >=20 > 1) EMSK usage - normative, i.e. standards track > 2) Naming EAP keys - normative, i.e. standards track, would recap the > EMSK/AMSK naming scheme explained in 1 and would specify the MSK and > AAA-key naming scheme 3) EAP handoffs - informational (this would > reseparate this=20 > section back > to an independent document, which is how it was originally submitted > draft-aboba-context-802 IIRC) 4) EAP's place in protocol suites - > informational 5) EAP usage in multiparty scenarios - informational > 6) EAP key lifetimes - informational or normative TBD >=20 > Thus, we would improve the overall readability and be able to > focus on > priority parts. > My fear is that few people will actually read and use the > eap-keying as > is - and that given the little number of reviews it may have got, its > final quality will not reflect all the excellent ideas >=20 > Bernard, Jari, could we make a straw poll on: > 1) how many people have read (more than a few pages of ) the actual > eap-keying document 2) how many people think that splitting it could > improve its usefulness and the way we get the work done >=20 > Florent, hope this helps > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 5 00:10:42 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29003 for ; Tue, 5 Oct 2004 00:10:41 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E2E0A20E0D; Tue, 5 Oct 2004 00:06:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8BBA720E04; Tue, 5 Oct 2004 00:06:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 77C3320E02 for ; Tue, 5 Oct 2004 00:04:30 -0400 (EDT) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id ED75320E0A for ; Tue, 5 Oct 2004 00:04:27 -0400 (EDT) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 04 Oct 2004 21:09:09 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i9544Mwp003326; Mon, 4 Oct 2004 21:04:23 -0700 (PDT) Received: from jsaloweyw2k01 ([10.82.224.249]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 4 Oct 2004 21:05:51 -0700 From: "Joseph Salowey" To: "'Florent Bersani'" , Subject: RE: [eap] Issue on eap-keying: naming of AMSks Message-ID: <043401c4aa90$665e5fd0$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <416152EB.3040103@rd.francetelecom.fr> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-OriginalArrivalTime: 05 Oct 2004 04:05:51.0739 (UTC) FILETIME=[9A813CB0:01C4AA90] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 4 Oct 2004 21:04:22 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable It seems that the definition of the AMSK name may be up to the = application that is using the key. I suppose it is fine to define a name, but I'm = not sure it is good to expect application to use that name. This brings up another topic. I think in many cases a fixed length name may be more = useful (perhaps this is an ID, who knows). The current naming schemes can = lead to long variable length names. I would rather (or also) like to see = schemes that result in a fixed length name (or ID). eap-admin@frascone.com wrote: > Description of issue: should AMSK naming be mandatory? >=20 > Submitter name: Florent Bersani >=20 > Submitter email address: florent.bersani@francetelecom.com >=20 > Date first submitted: 10/04/2004 >=20 > Document: Keying Framework >=20 > Comment type: 'E'ditorial >=20 > Priority: 1 should fix >=20 > Section: 2.4 >=20 > Rationale/Explanation of issue: >=20 > section 2.4 reads: "AMSK Name >=20 > AMSKs, if any, may be named by the concatenation of the string > "AMSK", key label, application data (see Appendix F), and EMSK > Name."=20 >=20 > However, I think it is sound practice to name keys. Since > AMSK are new, > we shouldn't be bothered with legacy reasons. Hence, why not > make this > AMSK naming "mandatory" >=20 >=20 >=20 > Requested change >=20 > Replace the previous text by > "AMSK Name >=20 > AMSKs, if any, are named by concatenating the string > "AMSK", key label, application data (see Appendix F), and EMSK > Name."=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 5 00:34:04 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01161 for ; Tue, 5 Oct 2004 00:34:04 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 251391FCD7; Tue, 5 Oct 2004 00:34:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CF1A320654; Tue, 5 Oct 2004 00:34:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 70FD620E02 for ; Tue, 5 Oct 2004 00:33:06 -0400 (EDT) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mail.frascone.com (Postfix) with ESMTP id B91401FCD7 for ; Tue, 5 Oct 2004 00:33:04 -0400 (EDT) Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-1.cisco.com with ESMTP; 04 Oct 2004 21:40:23 -0700 X-BrightmailFiltered: true Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i954WtbV007945 for ; Mon, 4 Oct 2004 21:32:55 -0700 (PDT) Received: from jsaloweyw2k01 ([10.82.224.249]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 4 Oct 2004 21:34:21 -0700 From: "Joseph Salowey" To: Message-ID: <043b01c4aa94$61c97190$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-OriginalArrivalTime: 05 Oct 2004 04:34:22.0063 (UTC) FILETIME=[95EFF7F0:01C4AA94] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Issue: AAA-Key should be derived from AMSK Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 4 Oct 2004 21:32:53 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Description of issue Submitter name: Joe Salowey Submitter email address: jsalowey@cisco.com Date first submitted: 10/4/2004 Reference:=20 Document: Keying Framework Comment type: 'T'echnical Priority: 'S' Must fix Section: 2.2, Appendix C, Appendix E Rationale/Explanation of issue: The AAA-Key should be derived from the EMSK directly, it should either = be derived from the MSK alone or form an AMSK (which is derived from the = EMSK). This is to limit the exposure of the EMSK outside of the EAP framework = and to ensure that the EMSK derivation maitnains computational separation of keys. =20 Requested change: Section 2.2: Change=20 "On both the peer and EAP server, the exported MSK and EMSK are utilized in order to calculate the AAA-Key, as described in Appendix E." To "On both the peer and EAP server, the exported MSK and keys derived from = the EMSK (AMSK) are utilized in order to calculate the AAA-Key, as described in Appendix E." Figure 3 should be changed to show that the AAA-Key is derived from an = AMSK Appendix C: Figure C1 should show the AMSK going to the backend server instead of = the EMSK Appendix E: The EMSK should not be used directly in AAA-Key derivation. Text = follows: "Where keying material is provided by the backend authentication server, a key hierarchy derived from the EMSK, can be used to provide cryptographically separate keying material for use in fast handoff. Instead of using the EMSK directly a application = specific key is derived, the AMSK, as described in seciton F: AAA-Key-A =3D MSK(0,63) AAA-Key-B =3D PRF(AMSK(0,63),"EAP AAA-Key derivation for multiple attachments", AAA-Key-A,B-Called-Station-Id, Calling-Station-Id,length) AAA-Key-E =3D PRF(AMSK(0,63),"EAP AAA-Key derivation for multiple attachments",AAA-Key-A,E-Called-Station-Id, Calling-Station-Id, length)" _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 5 02:56:27 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 CAA25347 for ; Tue, 5 Oct 2004 02:56:26 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3F41020EAE; Tue, 5 Oct 2004 02:53:11 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6FC1222498; Tue, 5 Oct 2004 02:53:08 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8F06220EF4 for ; Tue, 5 Oct 2004 02:51:56 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by mail.frascone.com (Postfix) with ESMTP id 8CF0222496 for ; Tue, 5 Oct 2004 02:51:53 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 5 Oct 2004 08:51:50 +0200 Received: from [10.193.106.25] ([10.193.106.25]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Tue, 5 Oct 2004 08:51:49 +0200 Message-ID: <4162449F.4040708@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: jari.arkko@piuha.net Cc: "eap@frascone.com" Subject: Re: [eap] Issue on eap-keying: PMK naming References: <41615107.7080608@rd.francetelecom.fr> <4161BCFF.1070805@piuha.net> In-Reply-To: <4161BCFF.1070805@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2004 06:51:49.0924 (UTC) FILETIME=[CA0BAE40:01C4AAA7] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 05 Oct 2004 08:52:15 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Jari Arkko wrote: > Florent Bersani wrote: > >> Description of issue: possible confusion between PMK naming and PMKID >> >> Submitter name: Florent Bersani >> >> Submitter email address: florent.bersani@francetelecom.com >> >> Date first submitted: 10/04/2004 >> >> Document: Keying Framework >> >> Comment type: 'E'ditorial >> >> Priority: '1' Should fix >> >> Section: 2.4 and 3.4.1 >> >> Rationale/Explanation of issue: >> >> I find the following confusing. In section 2.4, I read >> >> "PMK Name >> >> The PMK has no name of its own, and is only identified by the AAA- >> Key from which it is derived." >> >> but in Section 3.4.1, I find "PMKID (security association >> identifier)"... so it seems to me that the PMK has no name but has an >> identifier (defined in clause 8.5.1.2 of IEEE 802.11i IIRC). I guess >> it could be worth clarifying this subtlety, wouldn't it? >> >> Requested change >> >> Would our 802.11i experts approve the following: >> "PMK Name >> >> The PMK may be named by its identifier PMKID defined in clause >> 8.5.1.2 of [IEEE80211i]." > > > I agree that the current text is confusing. On the other hand, > there's a distinction between what the keying framework documents > and what additional things may be done by link layers. OK but my understanding is that the PMK is bound to a specific link layer, namely IEEE 802.11i (see e.g. section 2.1: "Pairwise Master Key (PMK) The AAA-Key is divided into two halves, the "Peer to Authenticator Encryption Key" (Enc-RECV-Key) and "Authenticator to Peer Encryption Key" (Enc-SEND-Key) (reception is defined from the point of view of the authenticator). Within [IEEE80211i] Octets 0-31 of the AAA-Key (Enc-RECV-Key) are known as the Pairwise Master Key (PMK). In [IEEE80211i] the TKIP and AES CCMP ciphersuites derive their Transient Session Keys (TSKs) solely from the PMK, whereas the WEP ciphersuite as noted in [RFC3580], derives its TSKs from both halves of the AAA-Key.") > Here's > a slightly modified text suggestion: > > PMK Name > > This document does not specify any naming scheme for the PMK. > The PMK is only identified by the AAA-Key from which it is > derived. > > Note: IEEE 802.11i names the PMKID for the purposes > of being able to refer to it in the Secure Association > protocol; this naming is based on a hash of the PMK itself > as well as some other parameters (see Section 8.5.1.2 [ref]). I guess I understand that the "names" that eap-keying defines are the ones to be included in the document, hence, since it is 802.11i which defines the PMK "name", this name has not its place in the document. Perhaps sth like what's writtent about the TEKs, i.e., "the PMK naming is specified in IEEE 802.11i" would do just fine but the text jari proposes is OK for me, although I am not sure what "naming the PMKID means". Wouldn't "IEEE 802.11i names the PMK thanks to a PMKID..." be better? > > --Jari > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 5 02:57:48 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25454 for ; Tue, 5 Oct 2004 02:57:48 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BB2522273F; Tue, 5 Oct 2004 02:55:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8A39F20F4F; Tue, 5 Oct 2004 02:55:06 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 908EB224A1 for ; Tue, 5 Oct 2004 02:54:25 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by mail.frascone.com (Postfix) with ESMTP id 0533C20EFE for ; Tue, 5 Oct 2004 02:54:21 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 5 Oct 2004 08:54:18 +0200 Received: from [10.193.106.25] ([10.193.106.25]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Tue, 5 Oct 2004 08:54:17 +0200 Message-ID: <41624533.7010701@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: Joseph Salowey Cc: eap@frascone.com Subject: Re: [eap] Issue: AAA-Key should be derived from AMSK References: <043b01c4aa94$61c97190$0300000a@amer.cisco.com> In-Reply-To: <043b01c4aa94$61c97190$0300000a@amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2004 06:54:17.0318 (UTC) FILETIME=[21E63860:01C4AAA8] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 05 Oct 2004 08:54:43 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Joe, I believe this is tracked as Issue 266 (http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%20266) isn't it? Thanks for proposing text :-)) I concur. Florent Joseph Salowey wrote: >Description of issue >Submitter name: Joe Salowey >Submitter email address: jsalowey@cisco.com >Date first submitted: 10/4/2004 >Reference: >Document: Keying Framework >Comment type: 'T'echnical >Priority: 'S' Must fix >Section: 2.2, Appendix C, Appendix E >Rationale/Explanation of issue: > >The AAA-Key should be derived from the EMSK directly, > I assume that you meant *should not* > it should either be >derived from the MSK alone or form an AMSK (which is derived from the EMSK). >This is to limit the exposure of the EMSK outside of the EAP framework and >to ensure that the EMSK derivation maitnains computational separation of >keys. > >Requested change: > >Section 2.2: > >Change >"On both the peer and EAP server, the exported MSK and EMSK are > utilized in order to calculate the AAA-Key, as described in Appendix > E." >To > >"On both the peer and EAP server, the exported MSK and keys derived from the >EMSK (AMSK) are > utilized in order to calculate the AAA-Key, as described in Appendix > E." > >Figure 3 should be changed to show that the AAA-Key is derived from an AMSK > >Appendix C: > >Figure C1 should show the AMSK going to the backend server instead of the >EMSK > > >Appendix E: > >The EMSK should not be used directly in AAA-Key derivation. Text follows: > > "Where keying material is provided by the backend > authentication server, a key hierarchy derived from the EMSK, can be > used to provide cryptographically separate keying material for use in > fast handoff. Instead of using the EMSK directly a application specific > key is derived, the AMSK, as described in seciton F: > > AAA-Key-A = MSK(0,63) > AAA-Key-B = PRF(AMSK(0,63),"EAP AAA-Key derivation for > multiple attachments", AAA-Key-A,B-Called-Station-Id, > Calling-Station-Id,length) > > AAA-Key-E = PRF(AMSK(0,63),"EAP AAA-Key derivation for > multiple attachments",AAA-Key-A,E-Called-Station-Id, > Calling-Station-Id, length)" > > > >_______________________________________________ >eap mailing list >eap@frascone.com >http://mail.frascone.com/mailman/listinfo/eap > > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 5 03:07:07 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26583 for ; Tue, 5 Oct 2004 03:07:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CC3921FE2C; Tue, 5 Oct 2004 03:07:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3168620F13; Tue, 5 Oct 2004 03:07:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D585B20F13 for ; Tue, 5 Oct 2004 03:06:58 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by mail.frascone.com (Postfix) with ESMTP id C16DD1FE2C for ; Tue, 5 Oct 2004 03:06:56 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 5 Oct 2004 09:06:53 +0200 Received: from [10.193.106.25] ([10.193.106.25]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Tue, 5 Oct 2004 09:06:52 +0200 Message-ID: <41624826.50708@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: gwz@cisco.com Cc: jari.arkko@piuha.net, eap@frascone.com Subject: Re: [eap] Issue on eap-keying: capitalization of RFC 2119 requirements key words References: <010901c4aa64$d175db30$0502a8c0@amer.cisco.com> In-Reply-To: <010901c4aa64$d175db30$0502a8c0@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2004 07:06:52.0494 (UTC) FILETIME=[E404EEE0:01C4AAA9] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 05 Oct 2004 09:07:18 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Glen, Glen Zorn (gwz) wrote: >Jari Arkko writes: > >... > > > >>>"The application data is optional and may not be >>> used by some applications." >>> >>> >>s/may not/MAY NOT/ >> >> > >Let's not get carried away. Is this sentence normative or >informative? I think the latter. In any case, the "MAY NOT" >construct DOES NOT :-) appear in RFC 2119. > > I surely agree with the latter part of your remark. For what regards the former, I was only saying that, in a document which authoritative status is unclear IMHO, the abundance of possible requirements key words is a real pain! If you expect that the reader will engage in reflexions about whether sentences are normative or informative in a 73-page document, the I definitely admire your optimism ;-) Most of my concerns would be addressed if the document was split in two... Florent, "Application data MAY be an empty string" as it is OPTIONAL that applications provide some ;-) and for sure, there are things much more interesting and worth doing than engaging in a thorough review of the hundreds of occurrences of the key words to see if they are in normative or informative sentences > > >>>(*) my word count script gives me the following results: >>> >>>must 29 >>>MUST 61 >>> >>>may 136 >>>MAY 8 >>> >>>required 26 >>>REQUIRED 2 >>> >>>shall 0 >>>SHALL 2 >>> >>>should 17 >>>SHOULD 24 >>> >>>recommended 4 >>>RECOMMENDED 15 >>> >>>optional 11 >>>OPTIONAL 1 >>> >>> >>Ok -- we need to look at each one... >> >> >> >>>Requested change >>> >>>Capitalize the key words mentioned here above i.e. at least in >>> >>> >6.1.1 > > >>>and F.1 >>> >>> >>Agreed. >> >>--Jari >>_______________________________________________ >>eap mailing list >>eap@frascone.com >>http://mail.frascone.com/mailman/listinfo/eap >> >> > > > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From wo16281628@163.net Tue Oct 5 04:23:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02134 for ; Tue, 5 Oct 2004 04:23:30 -0400 (EDT) Message-Id: <200410050823.EAA02134@ietf.org> Received: from [218.17.63.173] (helo=163.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEkki-0006qr-HF for eap-archive@ietf.org; Tue, 05 Oct 2004 04:33:06 -0400 From: =?GB2312?B?ye7b2si6waa/xry8?= Subject: =?GB2312?B?s6y1zbzbKr/sy9nXqNK1yc/Dxc6s0N6158TU?= To: eap-archive@ietf.org Content-Type: text/html;charset="GB2312" Date: Tue, 5 Oct 2004 16:31:56 +0800 X-Priority: 2 X-Mailer: Foxmail 4.1 [cn] X-Spam-Score: 6.8 (++++++) X-Spam-Flag: YES X-NONENGLISH: Subject contains non-English characters X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 ÎÞ±êÌâÎĵµ

 
Ç×°®µÄÅóÓÑÃÇ£º
    ÄúÃǺã¡×÷ΪµçÄÔµÄÖ÷ÈË£¬ÄãÃÇÊÇ·ñÔø¾­ÎªÎ¬ÐÞµçÄÔ¶ø¿àÄÕ¹ýÄØ£¿ÏÄÌ죬×ó§ÓÒ±§µÄ´ø×ŵçÄÔÖ±±¼»ªÇ¿¡¢Èü¸ñ£¬ÏÈ°´ÏÂһ·ÉÏŪµÃÏ㺹ÁÜÀìºÍÒ»ÉíÆ£±¹ ²»Ëµ£¬²»¹ý¶¬Ì컹¿ÉÒÔ£¬Ö»µÃÒ»ÉíÀÛ°É¡£µ«µ½Á˵çÄÔ¹«Ë¾¼ûµ½Á˹¤³Ìʦ£¬ÊÇ·ñÄÜÂíÉÏ¿ª¹¤°ïæ¸ãµàÄØ£¿Õâ¸ö»¹µÃ¿¿ÔËÆøÄØ£¬´ËÇé´Ë¾°Äã˵ͷ²»Í·ÔΣ¿×÷Ϊһ¸öÉúÒâÈË£¬Ê±¼ä¾ÍÊǽðÇ®£¬ÔÙ¼Ó ÉÏÕâÊǸö¸ßËÙÐÅÏ¢»¯Ê±´ú£¬Ã»ÓÐÁ˵çÄÔ£¬¼òÖ±¾ÍÏñÈȹøÉϵÄÂìÒÏ¡£Ãæ¶Ô´ËÇé´Ë¾°£¬´Ëʱ´Ë¿ÌÎÒÃÇÉîÛÚȺÁ¦¿Æ
¼¼Ö»ÏëÓÃÎÒÃǵÄÇà´º»»»ØÄãÃDZ¦¹óµÄʱ¹â£¬ÌØΪÅóÓÑÃdzÊÉÏÎÒÃǵķþÎñ£¬¿Ò Çë¶à¶àÖ¸½Ì£¬Ð»Ð»¡£
     ³¬µÍ¼Û**Ç©Ô¼°üÔÂ**¿ìËÙרҵÉÏÃÅάÐÞµçÄÔ
            ÉÁµç°²×°ÐÂϵͳ  30·ÖÖÓ¾ÍOK  ÉúÒâÈ˵ÄÊ×Ñ¡

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

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

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

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

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

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



¡¡    ÍøÂçά»¤£ºhttp://www.it678.net ¡¡¡¡¡¡¡¡¡¡¡¡¡¡               µçÄÔάÐÞ£ºhttp://www.it678.net
From eap-admin@frascone.com Tue Oct 5 06:22:05 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11063 for ; Tue, 5 Oct 2004 06:22:05 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 70B1D20F95; Tue, 5 Oct 2004 06:22:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 45D3420F91; Tue, 5 Oct 2004 06:22:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 527AA20F90 for ; Tue, 5 Oct 2004 06:21:41 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id BC7E1203DF for ; Tue, 5 Oct 2004 06:21:39 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id CBE5389883; Tue, 5 Oct 2004 13:21:37 +0300 (EEST) Message-ID: <41627566.2080501@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Florent Bersani , gwz@cisco.com Cc: eap@frascone.com Subject: Re: [eap] Issue on eap-keying: capitalization of RFC 2119 requirements key words References: <010901c4aa64$d175db30$0502a8c0@amer.cisco.com> <41624826.50708@rd.francetelecom.fr> In-Reply-To: <41624826.50708@rd.francetelecom.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 05 Oct 2004 13:20:22 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Glen, Florent, >>>> "The application data is optional and may not be >>>> used by some applications." >>> >>> s/may not/MAY NOT/ >> >> Let's not get carried away. Is this sentence normative or >> informative? I think the latter. In any case, the "MAY NOT" >> construct DOES NOT :-) appear in RFC 2119. Yes. My mistake... > Florent, "Application data MAY be an empty string" This would be good enough for me. [But it seems that we need to take a decision about top-level issues first before looking at the individual text pieces.] --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 5 06:55:23 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14182 for ; Tue, 5 Oct 2004 06:55:22 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7408C22758; Tue, 5 Oct 2004 06:54:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E9E8E1FEF4; Tue, 5 Oct 2004 06:54:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 45B4922754 for ; Tue, 5 Oct 2004 06:52:29 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 9F17E205F6 for ; Tue, 5 Oct 2004 06:52:26 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id CB7FF89883; Tue, 5 Oct 2004 13:52:25 +0300 (EEST) Message-ID: <41627C9E.4020002@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joseph Salowey Cc: eap@frascone.com, Florent Bersani Subject: Re: [eap] Issue: AAA-Key should be derived from AMSK References: <043b01c4aa94$61c97190$0300000a@amer.cisco.com> In-Reply-To: <043b01c4aa94$61c97190$0300000a@amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 05 Oct 2004 13:51:10 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I agree with you and Florent that this is a problem. I like your solution too -- some nits inline: > Section 2.2: > > Change > "On both the peer and EAP server, the exported MSK and EMSK are > utilized in order to calculate the AAA-Key, as described in Appendix > E." > To > > "On both the peer and EAP server, the exported MSK and keys derived from the > EMSK (AMSK) are > utilized in order to calculate the AAA-Key, as described in Appendix > E." Maybe s/EMSK (AMSK)/AMSK/ -- the AMSK is already introduced earlier as is the fact that AMSK is derived from the exported quantities. > Figure 3 should be changed to show that the AAA-Key is derived from an AMSK Yes. > Appendix C: > > Figure C1 should show the AMSK going to the backend server instead of the > EMSK Yes. > Appendix E: > > The EMSK should not be used directly in AAA-Key derivation. Text follows: > > "Where keying material is provided by the backend > authentication server, a key hierarchy derived from the EMSK, can be > used to provide cryptographically separate keying material for use in > fast handoff. Instead of using the EMSK directly a application specific > key is derived, the AMSK, as described in seciton F: Maybe: "Where keying material is provided by the backend authentication server, a key hierarchy derived from the MSK and the AMSK can be used to ..." > AAA-Key-A = MSK(0,63) > AAA-Key-B = PRF(AMSK(0,63),"EAP AAA-Key derivation for > multiple attachments", AAA-Key-A,B-Called-Station-Id, > Calling-Station-Id,length) > > AAA-Key-E = PRF(AMSK(0,63),"EAP AAA-Key derivation for > multiple attachments",AAA-Key-A,E-Called-Station-Id, > Calling-Station-Id, length)" Ok. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 5 07:20:07 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16068 for ; Tue, 5 Oct 2004 07:20:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 576D720FB2; Tue, 5 Oct 2004 07:20:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 25C76205DD; Tue, 5 Oct 2004 07:20:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7BB34205DD for ; Tue, 5 Oct 2004 07:19:28 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id A15901FEDA for ; Tue, 5 Oct 2004 07:19:26 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id B802689883 for ; Tue, 5 Oct 2004 14:19:25 +0300 (EEST) Message-ID: <416282F2.20109@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] issue: make existing vs. handoff usage of AAA-Key clearer Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 05 Oct 2004 14:18:10 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Submitter name: Jari Arkko Submitter email address: jarkko@piuha.net Date first submitted: 10/5/2004 Reference: Document: Keying Framework Comment type: 'T'echnical Priority: 'S' Must fix Section: 2.1, Appendix E Rationale/Explanation of issue: Section 2.1 says: AAA-Key derivation is discussed in Appendix E; in existing implementations the MSK is used as the AAA-Key. Then Appendix E says: Where a AAA-Key is generated as the result of a successful EAP authentication, the AAA-Key is set to MSK(0,63). ... Where the backend authentication server provides keying material to multiple authenticators in order to facilitate fast handoff, it is highly desirable for the keying material used on different authenticators to be cryptographically separate, so that if one authenticator is compromised, it does not lead to the compromise of other authenticators. ... a key hierarchy derived from the EMSK, can be used to provide cryptographically separate keying material for use in fast handoff: AAA-Key-A = MSK(0,63) AAA-Key-B = PRF(... AAA-Key-A,B-Called-Station-Id, Calling-Station-Id,length) AAA-Key-E = PRF(... AAA-Key-A,E-Called-Station-Id, Calling-Station-Id, length) Where: Calling-Station-Id = STA MAC address B-Called-Station-Id = AP B MAC address E-Called-Station-Id = AP E MAC address PRF = Some suitable pseudo-random function length = length of derived key material What I worry about is an apparent set of two methods -- yet AAA-Key-A and AAA-Key are equivalent. The text could be also clearer about existing implementations that use fast handoffs -- would they be using MSK or AAA-Key-X? And is the AAA-Key-X method the recommended IETF method, or one proposal among many competing ones (people who work with fast handoff in IEEE could perhaps comment here). Finally, "some suitable pseudo-random function" does not appear to be sufficient for interoperability :-) In any case, my suggestion would be to merge the two approaches and just say that this is the way AAA keys need to be generated; given that the first key is the same in any case, the remaining keys will be different whenever fast handoffs are used. And we could use hmac-sha1 as is already done for AMSK generation. Note: if people think that keying for handoff isn't clear and stable at this time, we should avoid recommending any specific key hierarchy for that. If that's the case then I withdraw my issue, and suggest that we simply keep the textual parts of appendix E and remove the rest. But assuming we can specify this now, here's the suggested text for Section 2.1: AAA-Key derivation is discussed in Appendix E. and for Appendix E: Where a AAA-Key is generated as the result of a successful EAP authentication with the authenticator A, the AAA-Key is based on the MSK: AAA-Key = MSK(0,63) ... Where the backend authentication server provides keying material to additional authenticators in order to facilitate fast handoff, it is highly desirable for the keying material used on different authenticators B, C, ... to be cryptographically separate, so that if one authenticator is compromised, it does not lead to the compromise of other authenticators. ... a key hierarchy derived from ... can be used to provide cryptographically separate keying material for use in fast handoff: AAA-Key-B = prf(... AAA-Key,B-Called-Station-Id, Calling-Station-Id,length) AAA-Key-C = prf(... AAA-Key,C-Called-Station-Id, Calling-Station-Id, length) Where: Calling-Station-Id = STA MAC address B-Called-Station-Id = AP B MAC address C-Called-Station-Id = AP C MAC address prf = hmac-sha1 length = length of derived key material Here AAA-Key is derived during the initial EAP authentication between the peer and authenticator A. Based on this initial EAP authentication, the EMSK is also derived, which can be used to derive AAA-Keys for fast authentication between the EAP peer and authenticators B and C. Since the EMSK is cryptographically separate from the MSK, each of these AAA-Keys is cryptographically separate from each other, and are guaranteed to be unique between the EAP peer (also known as the STA) and the authenticator (also known as the AP). --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 5 07:24:07 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16538 for ; Tue, 5 Oct 2004 07:24:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BC1471FEDA; Tue, 5 Oct 2004 07:24:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7732120FB0; Tue, 5 Oct 2004 07:24:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D920820FB2 for ; Tue, 5 Oct 2004 07:23:03 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 424F91FEDA for ; Tue, 5 Oct 2004 07:23:02 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id E2BFA89883; Tue, 5 Oct 2004 14:23:00 +0300 (EEST) Message-ID: <416283C9.50101@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Florent Bersani Cc: "eap@frascone.com" Subject: Re: [eap] Issue on eap-keying: PMK naming References: <41615107.7080608@rd.francetelecom.fr> <4161BCFF.1070805@piuha.net> <4162449F.4040708@rd.francetelecom.fr> In-Reply-To: <4162449F.4040708@rd.francetelecom.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 05 Oct 2004 14:21:45 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Florent, >>> I find the following confusing. In section 2.4, I read >>> >>> "PMK Name >>> >>> The PMK has no name of its own, and is only identified by the AAA- >>> Key from which it is derived." >>> >>> but in Section 3.4.1, I find "PMKID (security association >>> identifier)"... so it seems to me that the PMK has no name but has an >>> identifier (defined in clause 8.5.1.2 of IEEE 802.11i IIRC). I guess >>> it could be worth clarifying this subtlety, wouldn't it? >>> >>> Requested change >>> >>> Would our 802.11i experts approve the following: >>> "PMK Name >>> >>> The PMK may be named by its identifier PMKID defined in clause >>> 8.5.1.2 of [IEEE80211i]." >> >> >> >> I agree that the current text is confusing. On the other hand, >> there's a distinction between what the keying framework documents >> and what additional things may be done by link layers. > > > OK but my understanding is that the PMK is bound to a specific link > layer, namely IEEE 802.11i Hmm... yes, indeed. Thinking about this again, your text starts to sound better. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 5 07:55:08 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18852 for ; Tue, 5 Oct 2004 07:55:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A091C2275A; Tue, 5 Oct 2004 07:55:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3B19822754; Tue, 5 Oct 2004 07:55:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5E7A322187 for ; Tue, 5 Oct 2004 07:54:46 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 875DE20FC3 for ; Tue, 5 Oct 2004 07:54:44 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id B4E1989883; Tue, 5 Oct 2004 14:54:43 +0300 (EEST) Message-ID: <41628B38.4030708@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joseph Salowey Cc: "'Florent Bersani'" , eap@frascone.com Subject: Re: [eap] Issue on eap-keying: naming of AMSks References: <043401c4aa90$665e5fd0$0300000a@amer.cisco.com> In-Reply-To: <043401c4aa90$665e5fd0$0300000a@amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 05 Oct 2004 14:53:28 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit First, I agree with Florent's suggested change. But the issue you bring up Joe seems indeed a separate one, or maybe even multiple ones: o We can require support of a specific naming scheme in EAP, but does this imply that the keys can only be referred to these names in other protocols, or are those protocols free to choose what they want? Other candidate naming schemes the protocols could used include a hash of the EAP defined name, a hash of the key itself, time of day when the key was created, and user's shoe size. Tentative suggestion: It seems sufficient that EAP provides keys and key names with the specified format and that applications can use this information or some other identifiers as best suits that particular application. o String concatenation names vs. hash results. Should we have short or long names, or possibly both? (Didn't we discuss this at one time? Or was it about the use of the keys themselves as a basis for the names?) Tentative suggestion 1: We could require the support and delivery of the specified long names from EAP point of view, but allow application protocols to perform a hash to shorten the name, if appropriate. Tentative suggestion 2: Specify that names are hashes of the currently defined strings. It seems that the issue of deciding which hash function to use is not a problem, because we have already chosen a particular function for the AMSK generation. --Jari > It seems that the definition of the AMSK name may be up to the application > that is using the key. I suppose it is fine to define a name, but I'm not > sure it is good to expect application to use that name. This brings up > another topic. I think in many cases a fixed length name may be more useful > (perhaps this is an ID, who knows). The current naming schemes can lead to > long variable length names. I would rather (or also) like to see schemes > that result in a fixed length name (or ID). > > eap-admin@frascone.com wrote: > >> Description of issue: should AMSK naming be mandatory? >> >> Submitter name: Florent Bersani >> >> Submitter email address: florent.bersani@francetelecom.com >> >> Date first submitted: 10/04/2004 >> >> Document: Keying Framework >> >> Comment type: 'E'ditorial >> >> Priority: 1 should fix >> >> Section: 2.4 >> >> Rationale/Explanation of issue: >> >>section 2.4 reads: "AMSK Name >> >> AMSKs, if any, may be named by the concatenation of the string >> "AMSK", key label, application data (see Appendix F), and EMSK >>Name." >> >>However, I think it is sound practice to name keys. Since >>AMSK are new, >>we shouldn't be bothered with legacy reasons. Hence, why not >>make this >>AMSK naming "mandatory" >> >> >> >>Requested change >> >>Replace the previous text by >>"AMSK Name >> >>AMSKs, if any, are named by concatenating the string >> "AMSK", key label, application data (see Appendix F), and EMSK >>Name." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 5 10:31:07 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03498 for ; Tue, 5 Oct 2004 10:31:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9D56021020; Tue, 5 Oct 2004 10:31:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4C88C21027; Tue, 5 Oct 2004 10:31:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B645221020 for ; Tue, 5 Oct 2004 10:29:57 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com (unknown [195.101.245.16]) by mail.frascone.com (Postfix) with ESMTP id 1374B20259 for ; Tue, 5 Oct 2004 10:29:55 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 5 Oct 2004 16:29:32 +0200 Received: from [10.193.106.14] ([10.193.106.14]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Tue, 5 Oct 2004 16:29:31 +0200 Message-ID: <4162AFE6.4010202@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: jari.arkko@piuha.net Cc: Joseph Salowey , eap@frascone.com Subject: Re: [eap] Issue on eap-keying: naming of AMSks References: <043401c4aa90$665e5fd0$0300000a@amer.cisco.com> <41628B38.4030708@piuha.net> In-Reply-To: <41628B38.4030708@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2004 14:29:31.0291 (UTC) FILETIME=[BA4BBEB0:01C4AAE7] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 05 Oct 2004 16:29:58 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Joe, Jari Jari Arkko wrote: > First, I agree with Florent's suggested change. > > But the issue you bring up Joe seems indeed a separate one, > or maybe even multiple ones: > > o We can require support of a specific naming scheme in EAP, but > does this imply that the keys can only be referred to these names > in other protocols, or are those protocols free to choose what > they want? Other candidate naming schemes the protocols could used > include a hash of the EAP defined name, a hash of the key itself, > time of day when the key was created, and user's shoe size. > > Tentative suggestion: It seems sufficient that EAP provides keys > and key names with the specified format and that applications can > use this information or some other identifiers as best suits that > particular application. I agree. Perhaps we capture that in eap-keying. By including sth in the key naming section, saying that: "It is RECOMMENDED that Applications use the key names defined in this document to refer to specific EAP Keying material, however applications may very well use their own naming scheme to refer to this keys" Does that sound good? > > o String concatenation names vs. hash results. Should we have short > or long names, or possibly both? (Didn't we discuss this at one time? > Or was it about the use of the keys themselves as a basis for the > names?) IIRC, the latter. It was feared that using some hash of the key to name it would lead to some vulnerability (e.g. brute force/dictionary attack). I don't recall any definite conclusion on this one. My two cents: while their may be correct ways to do this (OWF), it is true that from an information theoretic PoV, there is some leakage, which probably accounts for this option not being conservative (if the hash function's one-wayness is in trouble then the key naming scheme is in great trouble). I'll take this to the CFRG to get educated advice > > Tentative suggestion 1: We could require the support and delivery of > the specified long names from EAP point of view, but allow application > protocols to perform a hash to shorten the name, if appropriate. > > Tentative suggestion 2: Specify that names are hashes of the currently > defined strings. It seems that the issue of deciding which hash > function > to use is not a problem, because we have already chosen a particular > function for the AMSK generation. I'd favor #2 If we don't provide usable names. Applications will either define their own ones from scratch or hash ours (and make possibly some mistake here). So I'd favor a 128 or 160 bit key name. > > --Jari > >> It seems that the definition of the AMSK name may be up to the >> application >> that is using the key. I suppose it is fine to define a name, but >> I'm not >> sure it is good to expect application to use that name. This brings up >> another topic. I think in many cases a fixed length name may be more >> useful >> (perhaps this is an ID, who knows). The current naming schemes can >> lead to >> long variable length names. I would rather (or also) like to see >> schemes >> that result in a fixed length name (or ID). >> >> eap-admin@frascone.com wrote: >> >>> Description of issue: should AMSK naming be mandatory? >>> >>> Submitter name: Florent Bersani >>> >>> Submitter email address: florent.bersani@francetelecom.com >>> >>> Date first submitted: 10/04/2004 >>> >>> Document: Keying Framework >>> >>> Comment type: 'E'ditorial >>> >>> Priority: 1 should fix >>> >>> Section: 2.4 >>> >>> Rationale/Explanation of issue: >>> >>> section 2.4 reads: "AMSK Name >>> >>> AMSKs, if any, may be named by the concatenation of the string >>> "AMSK", key label, application data (see Appendix F), and EMSK >>> Name." >>> However, I think it is sound practice to name keys. Since >>> AMSK are new, >>> we shouldn't be bothered with legacy reasons. Hence, why not >>> make this >>> AMSK naming "mandatory" >>> >>> >>> >>> Requested change >>> >>> Replace the previous text by >>> "AMSK Name >>> >>> AMSKs, if any, are named by concatenating the string >>> "AMSK", key label, application data (see Appendix F), and EMSK >>> Name." >> > > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 5 10:38:06 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03929 for ; Tue, 5 Oct 2004 10:38:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C535B22788; Tue, 5 Oct 2004 10:38:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 183232278A; Tue, 5 Oct 2004 10:38:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1BF4E2278A for ; Tue, 5 Oct 2004 10:37:46 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by mail.frascone.com (Postfix) with ESMTP id EE14122788 for ; Tue, 5 Oct 2004 10:37:43 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 5 Oct 2004 16:35:35 +0200 Received: from [10.193.106.14] ([10.193.106.14]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Tue, 5 Oct 2004 16:35:34 +0200 Message-ID: <4162B152.4010502@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: Joseph Salowey Cc: eap@frascone.com Subject: Re: [eap] Issue: AAA-Key should be derived from AMSK References: <043b01c4aa94$61c97190$0300000a@amer.cisco.com> In-Reply-To: <043b01c4aa94$61c97190$0300000a@amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2004 14:35:34.0285 (UTC) FILETIME=[92A83BD0:01C4AAE8] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 05 Oct 2004 16:36:02 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit A quick comment in-line Joseph Salowey wrote: >... > "Where keying material is provided by the backend > authentication server, a key hierarchy derived from the EMSK, can be > used to provide cryptographically separate keying material for use in > fast handoff. > I do not think that fast handoff is the only application that may benefit from such a scheme... although it is clearly a natural one! So i'd suggest being less specific and saying sth like: "Where keying material is provided by the backend authentication server, a key hierarchy derived from the EMSK *and the MSK as Jari noted* , can be used to provide cryptographically separate keying material *for different applications. Fast handoffs are an example application that may benefit from this keying material" > Instead of using the EMSK directly a application specific > key is derived, the AMSK, as described in seciton F: > > AAA-Key-A = MSK(0,63) > AAA-Key-B = PRF(AMSK(0,63),"EAP AAA-Key derivation for > multiple attachments", AAA-Key-A,B-Called-Station-Id, > Calling-Station-Id,length) > > AAA-Key-E = PRF(AMSK(0,63),"EAP AAA-Key derivation for > multiple attachments",AAA-Key-A,E-Called-Station-Id, > Calling-Station-Id, length)" > > > >_______________________________________________ >eap mailing list >eap@frascone.com >http://mail.frascone.com/mailman/listinfo/eap > > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 5 10:59:09 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05539 for ; Tue, 5 Oct 2004 10:59:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EC4E022797; Tue, 5 Oct 2004 10:59:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DFDB022799; Tue, 5 Oct 2004 10:59:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7312C22797 for ; Tue, 5 Oct 2004 10:58:42 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by mail.frascone.com (Postfix) with ESMTP id 498892101D for ; Tue, 5 Oct 2004 10:58:40 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 5 Oct 2004 16:58:38 +0200 Received: from [10.193.106.14] ([10.193.106.14]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Tue, 5 Oct 2004 16:58:36 +0200 Message-ID: <4162B6B6.9020806@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: jari.arkko@piuha.net Cc: "eap@frascone.com" Subject: Re: [eap] issue: make existing vs. handoff usage of AAA-Key clearer References: <416282F2.20109@piuha.net> In-Reply-To: <416282F2.20109@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2004 14:58:37.0148 (UTC) FILETIME=[CAE861C0:01C4AAEB] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 05 Oct 2004 16:59:02 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Jari Arkko wrote: > > Submitter name: Jari Arkko > Submitter email address: jarkko@piuha.net > Date first submitted: 10/5/2004 > Reference: > Document: Keying Framework > Comment type: 'T'echnical > Priority: 'S' Must fix > Section: 2.1, Appendix E > Rationale/Explanation of issue: > > Section 2.1 says: > > AAA-Key derivation is discussed in Appendix E; in > existing implementations the MSK is used as the AAA-Key. > > Then Appendix E says: > > Where a AAA-Key is generated as the result of a successful EAP > authentication, the AAA-Key is set to MSK(0,63). > > ... Where the backend > authentication server provides keying material to multiple > authenticators in order to facilitate fast handoff, it is highly > desirable for the keying material used on different authenticators to > be cryptographically separate, so that if one authenticator is > compromised, it does not lead to the compromise of other > authenticators. ... a key hierarchy derived from the EMSK, can be > used to provide cryptographically separate keying material for use in > fast handoff: > > AAA-Key-A = MSK(0,63) > AAA-Key-B = PRF(... AAA-Key-A,B-Called-Station-Id, > Calling-Station-Id,length) > > AAA-Key-E = PRF(... AAA-Key-A,E-Called-Station-Id, > Calling-Station-Id, length) > > Where: > Calling-Station-Id = STA MAC address > B-Called-Station-Id = AP B MAC address > E-Called-Station-Id = AP E MAC address > PRF = Some suitable pseudo-random function > length = length of derived key material > > What I worry about is an apparent set of two methods -- yet > AAA-Key-A and AAA-Key are equivalent. The text could be > also clearer about existing implementations that use fast > handoffs -- would they be using MSK or AAA-Key-X? And is the > AAA-Key-X method the recommended IETF method, or one > proposal among many competing ones (people who work with > fast handoff in IEEE could perhaps comment here). I have been participating to the IEEE 802.11r (previously known as FRFH study group) for a while. Here is my view of the matter but please not that this is a *personal view*. I am not speaking in the name if IEEE 802.11r! Please also note that I may have got things the wrong way :-( and that I'll try to be objective. So, a Call for proposal has been issued by IEEE 802.11r and there are currently various competing proposals. Very preliminary material on some proposals is available as IEEE documents (from year 2004: doc 1127, 1089, 1117 and 1114) and more detailed documentation from all proposals should be made available 10/15 It is not cleat at all that all (any?) proposals will use the AMSK scheme (for instance, they could very well create a whole new key hierarchy based on the PMK). And anyway, I guess IEEE 802 will get in trouble here since as soon as they need communication with the AS, the "IP" world steps in, which some may object to at IEEE 802. I am wondering how things will get working since it does not suffice to enhance the frame exchanges between STA and AP but you also have to get the right key to the AP. Of course AMSK may be a nice way to do so. > Finally, > "some suitable pseudo-random function" does not appear > to be sufficient for interoperability :-) i agree > > In any case, my suggestion would be to merge the two > approaches and just say that this is the way AAA keys > need to be generated; given that the first key is the > same in any case, the remaining keys will be different > whenever fast handoffs are used. And we could use hmac-sha1 > as is already done for AMSK generation. > > Note: if people think that keying for handoff isn't > clear and stable at this time, we should avoid recommending > any specific key hierarchy for that. If that's the case > then I withdraw my issue, and suggest that we simply keep > the textual parts of appendix E and remove the rest. I think that restricting AAA-key to the fast handoff scheme is too narrow, all the more that keying for handoff is IMHO not stable (but there might be a cjicken and egg problem here as some handoff schemes may need the EAP side to be in place to be acceptable...) We have already discussed the possible problems with the name AAA-key. My view is that our definition is still pretty much closed (reference is made in the definition of AAA-key to an authenticator). Why couldn't some application that is not authenticator based use EAP derived keys (i.e. specific AMSKs) that would be transported by some AAA protocol (so in a way wrapped in an AAA token)? My answer is that e should stick to AAA-key derivation from the MSK and say that AMSKs may also be exported and transported in AAA tokens Does that make sense? > > But assuming we can specify this now, here's the suggested > text for Section 2.1: > > AAA-Key derivation is discussed in Appendix E. > > and for Appendix E: > > Where a AAA-Key is generated as the result of a successful EAP > authentication with the authenticator A, the AAA-Key is based on > the MSK: > > AAA-Key = MSK(0,63) > > ... Where the backend > authentication server provides keying material to additional > authenticators in order to facilitate fast handoff, it is highly > desirable for the keying material used on different authenticators > B, C, ... to > be cryptographically separate, so that if one authenticator is > compromised, it does not lead to the compromise of other > authenticators. ... a key hierarchy derived from ... can be > used to provide cryptographically separate keying material for use in > fast handoff: > > AAA-Key-B = prf(... AAA-Key,B-Called-Station-Id, > Calling-Station-Id,length) > > AAA-Key-C = prf(... AAA-Key,C-Called-Station-Id, > Calling-Station-Id, length) > > Where: > Calling-Station-Id = STA MAC address > B-Called-Station-Id = AP B MAC address > C-Called-Station-Id = AP C MAC address > prf = hmac-sha1 > length = length of derived key material > > Here AAA-Key is derived during the initial EAP > authentication between the peer and authenticator A. Based on this > initial EAP authentication, the EMSK is also derived, which can be > used to derive AAA-Keys for fast authentication between the EAP peer > and authenticators B and C. Since the EMSK is cryptographically > separate from the MSK, each of these AAA-Keys is cryptographically > separate from each other, and are guaranteed to be unique between the > EAP peer (also known as the STA) and the authenticator (also known as > the AP). > > --Jari > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 5 11:31:07 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07842 for ; Tue, 5 Oct 2004 11:31:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7A3342069C; Tue, 5 Oct 2004 11:31:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1EA95204F3; Tue, 5 Oct 2004 11:31:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 128A2204E6 for ; Tue, 5 Oct 2004 11:30:24 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 3E7F920350 for ; Tue, 5 Oct 2004 11:30:22 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 910838987C; Tue, 5 Oct 2004 18:30:20 +0300 (EEST) Message-ID: <4162BDC1.7050009@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Florent Bersani Cc: Joseph Salowey , eap@frascone.com Subject: Re: [eap] Issue on eap-keying: naming of AMSks References: <043401c4aa90$665e5fd0$0300000a@amer.cisco.com> <41628B38.4030708@piuha.net> <4162AFE6.4010202@rd.francetelecom.fr> In-Reply-To: <4162AFE6.4010202@rd.francetelecom.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 05 Oct 2004 18:29:05 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Florent Bersani wrote: > I agree. Perhaps we capture that in eap-keying. By including sth in the > key naming section, saying that: > "It is RECOMMENDED that Applications use the key names defined in this > document to refer to specific EAP Keying material, however applications > may very well use their own naming scheme to refer to this keys" > Does that sound good? Ok. > I'd favor #2 > If we don't provide usable names. Applications will either define their > own ones from scratch or hash ours (and make possibly some mistake here). > So I'd favor a 128 or 160 bit key name. Fine with me! --Jari >> --Jari >> >>> It seems that the definition of the AMSK name may be up to the >>> application >>> that is using the key. I suppose it is fine to define a name, but >>> I'm not >>> sure it is good to expect application to use that name. This brings up >>> another topic. I think in many cases a fixed length name may be more >>> useful >>> (perhaps this is an ID, who knows). The current naming schemes can >>> lead to >>> long variable length names. I would rather (or also) like to see >>> schemes >>> that result in a fixed length name (or ID). >>> >>> eap-admin@frascone.com wrote: >>> >>>> Description of issue: should AMSK naming be mandatory? >>>> >>>> Submitter name: Florent Bersani >>>> >>>> Submitter email address: florent.bersani@francetelecom.com >>>> >>>> Date first submitted: 10/04/2004 >>>> >>>> Document: Keying Framework >>>> >>>> Comment type: 'E'ditorial >>>> >>>> Priority: 1 should fix >>>> >>>> Section: 2.4 >>>> >>>> Rationale/Explanation of issue: >>>> >>>> section 2.4 reads: "AMSK Name >>>> >>>> AMSKs, if any, may be named by the concatenation of the string >>>> "AMSK", key label, application data (see Appendix F), and EMSK >>>> Name." >>>> However, I think it is sound practice to name keys. Since >>>> AMSK are new, >>>> we shouldn't be bothered with legacy reasons. Hence, why not >>>> make this >>>> AMSK naming "mandatory" >>>> >>>> >>>> >>>> Requested change >>>> >>>> Replace the previous text by >>>> "AMSK Name >>>> >>>> AMSKs, if any, are named by concatenating the string >>>> "AMSK", key label, application data (see Appendix F), and EMSK >>>> Name." >>> >>> >> >> >> > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 5 12:27:37 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11822 for ; Tue, 5 Oct 2004 12:27:37 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A335A227A3; Tue, 5 Oct 2004 12:26:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 458AF21055; Tue, 5 Oct 2004 12:26:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D08F121766 for ; Tue, 5 Oct 2004 12:24:48 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 2B9D0205D6 for ; Tue, 5 Oct 2004 12:24:46 -0400 (EDT) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 05 Oct 2004 09:39:23 +0000 X-BrightmailFiltered: true Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i95GOPEE002580; Tue, 5 Oct 2004 09:24:26 -0700 (PDT) Received: from jsaloweyw2k01 ([10.82.224.249]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 5 Oct 2004 09:25:58 -0700 From: "Joseph Salowey" To: "'Florent Bersani'" Cc: Subject: RE: [eap] Issue: AAA-Key should be derived from AMSK Message-ID: <046d01c4aaf7$cae07c10$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <41624533.7010701@rd.francetelecom.fr> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-OriginalArrivalTime: 05 Oct 2004 16:25:58.0704 (UTC) FILETIME=[FF1E5B00:01C4AAF7] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 5 Oct 2004 09:24:29 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Florent Bersani wrote: > Joe, > > I believe this is tracked as Issue 266 > (http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%20266) isn't > it? > [Joe] Yes it is, we can merge them. I think there still is the whole issue whole issue of the AAA-Key usage in fast handoff which is currently under discussion. > Thanks for proposing text :-)) I concur. > > Florent > > Joseph Salowey wrote: > >> Description of issue >> Submitter name: Joe Salowey >> Submitter email address: jsalowey@cisco.com >> Date first submitted: 10/4/2004 >> Reference: >> Document: Keying Framework >> Comment type: 'T'echnical >> Priority: 'S' Must fix >> Section: 2.2, Appendix C, Appendix E >> Rationale/Explanation of issue: >> >> The AAA-Key should be derived from the EMSK directly, >> > I assume that you meant *should not* > >> it should either be >> derived from the MSK alone or form an AMSK (which is derived from the >> EMSK). This is to limit the exposure of the EMSK outside of the EAP >> framework and to ensure that the EMSK derivation maitnains >> computational separation of keys. >> >> Requested change: >> >> Section 2.2: >> >> Change >> "On both the peer and EAP server, the exported MSK and EMSK are >> utilized in order to calculate the AAA-Key, as described in >> Appendix E." To >> >> "On both the peer and EAP server, the exported MSK and keys derived >> from the EMSK (AMSK) are utilized in order to calculate the >> AAA-Key, as described in Appendix E." >> >> Figure 3 should be changed to show that the AAA-Key is derived from >> an AMSK >> >> Appendix C: >> >> Figure C1 should show the AMSK going to the backend server instead >> of the EMSK >> >> >> Appendix E: >> >> The EMSK should not be used directly in AAA-Key derivation. Text >> follows: >> >> "Where keying material is provided by the backend >> authentication server, a key hierarchy derived from the EMSK, can >> be used to provide cryptographically separate keying material for >> use in fast handoff. Instead of using the EMSK directly a >> application specific key is derived, the AMSK, as described in >> seciton F: >> >> AAA-Key-A = MSK(0,63) >> AAA-Key-B = PRF(AMSK(0,63),"EAP AAA-Key derivation for >> multiple attachments", AAA-Key-A,B-Called-Station-Id, >> Calling-Station-Id,length) >> >> AAA-Key-E = PRF(AMSK(0,63),"EAP AAA-Key derivation for >> multiple attachments",AAA-Key-A,E-Called-Station-Id, >> Calling-Station-Id, length)" >> >> >> >> _______________________________________________ >> eap mailing list >> eap@frascone.com >> http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 5 12:32:18 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 MAA12212 for ; Tue, 5 Oct 2004 12:32:16 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 471BA227A3; Tue, 5 Oct 2004 12:29:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 28821227B1; Tue, 5 Oct 2004 12:29:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 61C8721766 for ; Tue, 5 Oct 2004 12:27:35 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 28C6A21076 for ; Tue, 5 Oct 2004 12:27:33 -0400 (EDT) Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 05 Oct 2004 09:42:16 +0000 X-BrightmailFiltered: true Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i95GRSbV007473; Tue, 5 Oct 2004 09:27:29 -0700 (PDT) Received: from jsaloweyw2k01 ([10.82.224.249]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 5 Oct 2004 09:28:56 -0700 From: "Joseph Salowey" To: Cc: , "'Florent Bersani'" Subject: RE: [eap] Issue: AAA-Key should be derived from AMSK Message-ID: <046e01c4aaf8$34bc1810$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <41627C9E.4020002@piuha.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-OriginalArrivalTime: 05 Oct 2004 16:28:56.0299 (UTC) FILETIME=[68F933B0:01C4AAF8] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 5 Oct 2004 09:27:26 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Jari Arkko wrote: > I agree with you and Florent that this is a problem. > I like your solution too -- some nits inline: > >> Section 2.2: >> >> Change >> "On both the peer and EAP server, the exported MSK and EMSK are >> utilized in order to calculate the AAA-Key, as described in >> Appendix E." To >> >> "On both the peer and EAP server, the exported MSK and keys derived >> from the EMSK (AMSK) are utilized in order to calculate the >> AAA-Key, as described in Appendix E." > > Maybe s/EMSK (AMSK)/AMSK/ -- the AMSK is already introduced > earlier as is the fact that AMSK is derived from the exported > quantities. > [Joe] Yes, thanks. >> Appendix E: >> >> The EMSK should not be used directly in AAA-Key derivation. Text >> follows: >> >> "Where keying material is provided by the backend >> authentication server, a key hierarchy derived from the EMSK, can >> be used to provide cryptographically separate keying material for >> use in fast handoff. Instead of using the EMSK directly a >> application specific key is derived, the AMSK, as described in >> seciton F: > > Maybe: "Where keying material is provided by the backend > authentication server, a key hierarchy derived from the MSK > and the AMSK can be used to ..." > [Joe] perhaps "an AMSK" instead of "the AMSK". There can be more than one AMSK for different purposes. >> AAA-Key-A = MSK(0,63) >> AAA-Key-B = PRF(AMSK(0,63),"EAP AAA-Key derivation for >> multiple attachments", AAA-Key-A,B-Called-Station-Id, >> Calling-Station-Id,length) >> >> AAA-Key-E = PRF(AMSK(0,63),"EAP AAA-Key derivation for >> multiple attachments",AAA-Key-A,E-Called-Station-Id, >> Calling-Station-Id, length)" > > Ok. > > --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 5 12:37:32 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12605 for ; Tue, 5 Oct 2004 12:37:32 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 16E85227AF; Tue, 5 Oct 2004 12:31:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AD1A721D91; Tue, 5 Oct 2004 12:31:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3AE25227B6 for ; Tue, 5 Oct 2004 12:29:07 -0400 (EDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mail.frascone.com (Postfix) with ESMTP id A487A21073 for ; Tue, 5 Oct 2004 12:29:01 -0400 (EDT) Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 05 Oct 2004 09:29:17 -0700 X-BrightmailFiltered: true Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i95GSvqg009578; Tue, 5 Oct 2004 09:28:57 -0700 (PDT) Received: from jsaloweyw2k01 ([10.82.224.249]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 5 Oct 2004 09:30:24 -0700 From: "Joseph Salowey" To: "'Florent Bersani'" Cc: Subject: RE: [eap] Issue: AAA-Key should be derived from AMSK Message-ID: <046f01c4aaf8$6946b770$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <4162B152.4010502@rd.francetelecom.fr> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-OriginalArrivalTime: 05 Oct 2004 16:30:24.0456 (UTC) FILETIME=[9D84E480:01C4AAF8] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 5 Oct 2004 09:28:55 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Florent Bersani wrote: > A quick comment in-line > > Joseph Salowey wrote: > >> ... >> "Where keying material is provided by the backend >> authentication server, a key hierarchy derived from the EMSK, can >> be used to provide cryptographically separate keying material for >> use in fast handoff. >> > I do not think that fast handoff is the only application that may > benefit from such a scheme... although it is clearly a > natural one! So i'd suggest being less specific and saying sth like: > > "Where keying material is provided by the backend > authentication server, a key hierarchy derived from the > EMSK *and the MSK as Jari noted* , can be > used to provide cryptographically separate keying material > *for different applications. Fast handoffs are an example > application that may benefit from this keying material" > [Joe] perhaps it should be "the EMSK and/or the MSK" > >> Instead of using the EMSK directly a application specific >> key is derived, the AMSK, as described in seciton F: >> >> AAA-Key-A = MSK(0,63) >> AAA-Key-B = PRF(AMSK(0,63),"EAP AAA-Key derivation for >> multiple attachments", AAA-Key-A,B-Called-Station-Id, >> Calling-Station-Id,length) >> >> AAA-Key-E = PRF(AMSK(0,63),"EAP AAA-Key derivation for >> multiple attachments",AAA-Key-A,E-Called-Station-Id, >> Calling-Station-Id, length)" >> >> >> >> _______________________________________________ >> eap mailing list >> eap@frascone.com >> http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 5 13:05:06 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15620 for ; Tue, 5 Oct 2004 13:05:05 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5831D2105B; Tue, 5 Oct 2004 13:05:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E671C2076D; Tue, 5 Oct 2004 13:05:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6566A2076D for ; Tue, 5 Oct 2004 13:04:58 -0400 (EDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mail.frascone.com (Postfix) with ESMTP id 9FF862069C for ; Tue, 5 Oct 2004 13:04:56 -0400 (EDT) Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 05 Oct 2004 10:05:18 -0700 X-BrightmailFiltered: true Received: from gwzw2k01 (sjc-vpn1-613.cisco.com [10.21.98.101]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i95H4qbV022532; Tue, 5 Oct 2004 10:04:52 -0700 (PDT) Reply-To: From: "Glen Zorn (gwz)" To: "'Florent Bersani'" Cc: , Subject: RE: [eap] Issue on eap-keying: capitalization of RFC 2119 requirements key words Message-ID: <018301c4aafd$6fb558a0$0502a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal In-Reply-To: <41624826.50708@rd.francetelecom.fr> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 5 Oct 2004 10:04:53 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Florent Bersani writes: > Glen, >=20 > Glen Zorn (gwz) wrote: >=20 >> Jari Arkko writes: >>=20 >> ... >>=20 >>=20 >>=20 >>>> "The application data is optional and may not be >>>> used by some applications." >>>>=20 >>>>=20 >>> s/may not/MAY NOT/ >>>=20 >>>=20 >>=20 >> Let's not get carried away. Is this sentence normative or >> informative? I think the latter. In any case, the "MAY NOT" >> construct DOES NOT :-) appear in RFC 2119.=20 >>=20 >>=20 > I surely agree with the latter part of your remark. >=20 > For what regards the former, I was only saying that, in a document > which authoritative status is unclear IMHO, the abundance of possible > requirements key words is a real pain! I certainly agree that the capitalization must be corrected; however, my point was that going the opposite way of capitalizing every occurrence of "must", "should", "may", etc. may leave the doc in as bad a shape as it is in now. > If you expect that the reader will engage in reflexions about whether > sentences are normative or informative in a 73-page document, the I > definitely admire your optimism ;-) No, but I _do_ expect that at least the authors (lacking that, the reviewers) will engage in those reflections and further, act upon them appropriately. > Most of my concerns would be addressed if the document was split in > two...=20 >=20 > Florent, "Application data MAY be an empty string" as it is OPTIONAL > that applications provide some ;-) and for sure, there are things much > more interesting and worth doing than engaging in a thorough review of > the hundreds of occurrences of the key words to see if they are in > normative or informative sentences review of _any_ IETF document, let alone this one) There are no doubt much more interesting activities than the thorough review of _any_ IETF document, let alone this one), but it's definitely worthwhile. >=20 >>=20 >>=20 >>>> (*) my word count script gives me the following results: >>>>=20 >>>> must 29 >>>> MUST 61 >>>>=20 >>>> may 136 >>>> MAY 8 >>>>=20 >>>> required 26 >>>> REQUIRED 2 >>>>=20 >>>> shall 0 >>>> SHALL 2 >>>>=20 >>>> should 17 >>>> SHOULD 24 >>>>=20 >>>> recommended 4 >>>> RECOMMENDED 15 >>>>=20 >>>> optional 11 >>>> OPTIONAL 1 >>>>=20 >>>>=20 >>> Ok -- we need to look at each one... >>>=20 >>>=20 >>>=20 >>>> Requested change >>>>=20 >>>> Capitalize the key words mentioned here above i.e. at least in >>>>=20 >>>>=20 >> 6.1.1 >>=20 >>=20 >>>> and F.1 >>>>=20 >>>>=20 >>> Agreed. >>>=20 >>> --Jari >>> _______________________________________________ >>> eap mailing list >>> eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 5 14:15:08 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21849 for ; Tue, 5 Oct 2004 14:15:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EC7E521029; Tue, 5 Oct 2004 14:15:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2651220889; Tue, 5 Oct 2004 14:15:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0A9FF207FB for ; Tue, 5 Oct 2004 14:14:49 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 72557206FD for ; Tue, 5 Oct 2004 14:14:47 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id E8EA28987C for ; Tue, 5 Oct 2004 21:14:45 +0300 (EEST) Message-ID: <4162E44A.3010905@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] EAP meeting time at IETF-61 Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 05 Oct 2004 21:13:30 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit EAP is currently scheduled on Wednesday, November 10 at 0900-1130 Other groups scheduled at that time are: simple, v6ops, idr, avt, nfsv4 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 5 17:19:10 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13402 for ; Tue, 5 Oct 2004 17:19:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1609A210FC; Tue, 5 Oct 2004 17:19:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BEB5E210F3; Tue, 5 Oct 2004 17:19:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 31A85210F3 for ; Tue, 5 Oct 2004 17:18:10 -0400 (EDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mail.frascone.com (Postfix) with ESMTP id 55F8020F54 for ; Tue, 5 Oct 2004 17:18:08 -0400 (EDT) Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 05 Oct 2004 14:18:27 -0700 X-BrightmailFiltered: true Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i95LI4bV018013; Tue, 5 Oct 2004 14:18:04 -0700 (PDT) Received: from jsaloweyw2k01 ([10.82.224.249]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 5 Oct 2004 14:19:31 -0700 From: "Joseph Salowey" To: Cc: "'Florent Bersani'" , Subject: RE: [eap] Issue on eap-keying: naming of AMSks Message-ID: <04ae01c4ab20$ccdc0150$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <41628B38.4030708@piuha.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-OriginalArrivalTime: 05 Oct 2004 21:19:31.0598 (UTC) FILETIME=[0138B2E0:01C4AB21] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 5 Oct 2004 14:18:01 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Jari Arkko wrote: > First, I agree with Florent's suggested change. >=20 > But the issue you bring up Joe seems indeed a separate one, > or maybe even multiple ones: >=20 > o We can require support of a specific naming scheme in EAP, but > does this imply that the keys can only be referred to these names > in other protocols, or are those protocols free to choose what > they want? Other candidate naming schemes the protocols could used > include a hash of the EAP defined name, a hash of the key itself, > time of day when the key was created, and user's shoe size. >=20 > Tentative suggestion: It seems sufficient that EAP provides keys > and key names with the specified format and that applications can > use this information or some other identifiers as best suits that > particular application.=20 >=20 [Joe] In general I have issues with the format which I expressed = previously. In particular I don't think we should specify a particular format for = the name exported from an EAP-Mechanism. How the name is formatted is up to = the EAP mechanism. We can place requirements on uniqueness and give recommendations on construction. The EAP mechanism will know how best = to generate interoperable names based on its specification. If we need to specify additional names for keys etc. then we can make recommendations = for how applications should construct a name based on the exported name. I thought there was an issue open on this, I can open another one if the current one is not appropriate. > o String concatenation names vs. hash results. Should we have short > or long names, or possibly both? (Didn't we discuss this > at one time? > Or was it about the use of the keys themselves as a basis for the > names?)=20 >=20 > Tentative suggestion 1: We could require the support and > delivery of > the specified long names from EAP point of view, but > allow application > protocols to perform a hash to shorten the name, if appropriate. >=20 > Tentative suggestion 2: Specify that names are hashes of > the currently > defined strings. It seems that the issue of deciding > which hash function > to use is not a problem, because we have already chosen a > particular function for the AMSK generation. >=20 [Joe] Yes we did have a discussion before. I still think short names or = IDs are useful. I think we will probably have to limit the length of names anyway. In particular I also think this is more of an issue for names exported from the EAP mechanism rather than names for the AMSK. =20 > --Jari >=20 >> It seems that the definition of the AMSK name may be up to the >> application that is using the key. I suppose it is fine to define a >> name, but I'm not sure it is good to expect application to use that >> name. This brings up another topic. I think in many cases > a fixed length name may be more useful >> (perhaps this is an ID, who knows). The current naming schemes can >> lead to long variable length names. I would rather (or also) like >> to see schemes that result in a fixed length name (or ID). >>=20 >> eap-admin@frascone.com wrote: >>=20 >>> Description of issue: should AMSK naming be mandatory? >>>=20 >>> Submitter name: Florent Bersani >>>=20 >>> Submitter email address: florent.bersani@francetelecom.com >>>=20 >>> Date first submitted: 10/04/2004 >>>=20 >>> Document: Keying Framework >>>=20 >>> Comment type: 'E'ditorial >>>=20 >>> Priority: 1 should fix >>>=20 >>> Section: 2.4 >>>=20 >>> Rationale/Explanation of issue: >>>=20 >>> section 2.4 reads: "AMSK Name >>>=20 >>> AMSKs, if any, may be named by the concatenation of the string >>> "AMSK", key label, application data (see Appendix F), and >>> EMSK Name."=20 >>>=20 >>> However, I think it is sound practice to name keys. Since AMSK are >>> new, we shouldn't be bothered with legacy reasons. Hence, why not >>> make this AMSK naming "mandatory" >>>=20 >>>=20 >>>=20 >>> Requested change >>>=20 >>> Replace the previous text by >>> "AMSK Name >>>=20 >>> AMSKs, if any, are named by concatenating the string >>> "AMSK", key label, application data (see Appendix F), and >>> EMSK Name."=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 5 20:58:51 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03240 for ; Tue, 5 Oct 2004 20:58:50 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 660B420BD9; Tue, 5 Oct 2004 20:57:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 15F4620B62; Tue, 5 Oct 2004 20:57:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9E2B0203CA for ; Tue, 5 Oct 2004 20:56:12 -0400 (EDT) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by mail.frascone.com (Postfix) with ESMTP id 56D1E20AB1 for ; Tue, 5 Oct 2004 20:56:09 -0400 (EDT) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I5500JO819JS0@mailout2.samsung.com> for eap@frascone.com; Wed, 06 Oct 2004 09:56:07 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I55005OO13P1U@mailout2.samsung.com> for eap@frascone.com; Wed, 06 Oct 2004 09:52:38 +0900 (KST) Received: from Alperyegin ([105.253.155.10]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0I5500GSO13M0J@mmp1.samsung.com> for eap@frascone.com; Wed, 06 Oct 2004 09:52:37 +0900 (KST) From: Alper Yegin Subject: RE: [eap] issue: make existing vs. handoff usage of AAA-Key clearer In-reply-to: <416282F2.20109@piuha.net> To: jari.arkko@piuha.net, eap@frascone.com Message-id: <000001c4ab3e$c5027090$6501a8c0@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 05 Oct 2004 17:52:31 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7BIT The current text is geared for generating keys and pushing them to other authenticators in advance (prior to handover). I'd recommend the other mechanism, namely pulling keys from a new authenticator in response to a handover (reactive) is also covered in this section. Alper > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] On Behalf Of > Jari Arkko > Sent: Tuesday, October 05, 2004 4:18 AM > To: eap@frascone.com > Subject: [eap] issue: make existing vs. handoff usage of AAA-Key clearer > > > Submitter name: Jari Arkko > Submitter email address: jarkko@piuha.net > Date first submitted: 10/5/2004 > Reference: > Document: Keying Framework > Comment type: 'T'echnical > Priority: 'S' Must fix > Section: 2.1, Appendix E > Rationale/Explanation of issue: > > Section 2.1 says: > > AAA-Key derivation is discussed in Appendix E; in > existing implementations the MSK is used as the AAA-Key. > > Then Appendix E says: > > Where a AAA-Key is generated as the result of a successful EAP > authentication, the AAA-Key is set to MSK(0,63). > > ... Where the backend > authentication server provides keying material to multiple > authenticators in order to facilitate fast handoff, it is highly > desirable for the keying material used on different authenticators to > be cryptographically separate, so that if one authenticator is > compromised, it does not lead to the compromise of other > authenticators. ... a key hierarchy derived from the EMSK, can be > used to provide cryptographically separate keying material for use in > fast handoff: > > AAA-Key-A = MSK(0,63) > AAA-Key-B = PRF(... AAA-Key-A,B-Called-Station-Id, > Calling-Station-Id,length) > > AAA-Key-E = PRF(... AAA-Key-A,E-Called-Station-Id, > Calling-Station-Id, length) > > Where: > Calling-Station-Id = STA MAC address > B-Called-Station-Id = AP B MAC address > E-Called-Station-Id = AP E MAC address > PRF = Some suitable pseudo-random function > length = length of derived key material > > What I worry about is an apparent set of two methods -- yet > AAA-Key-A and AAA-Key are equivalent. The text could be > also clearer about existing implementations that use fast > handoffs -- would they be using MSK or AAA-Key-X? And is the > AAA-Key-X method the recommended IETF method, or one > proposal among many competing ones (people who work with > fast handoff in IEEE could perhaps comment here). Finally, > "some suitable pseudo-random function" does not appear > to be sufficient for interoperability :-) > > In any case, my suggestion would be to merge the two > approaches and just say that this is the way AAA keys > need to be generated; given that the first key is the > same in any case, the remaining keys will be different > whenever fast handoffs are used. And we could use hmac-sha1 > as is already done for AMSK generation. > > Note: if people think that keying for handoff isn't > clear and stable at this time, we should avoid recommending > any specific key hierarchy for that. If that's the case > then I withdraw my issue, and suggest that we simply keep > the textual parts of appendix E and remove the rest. > > But assuming we can specify this now, here's the suggested > text for Section 2.1: > > AAA-Key derivation is discussed in Appendix E. > > and for Appendix E: > > Where a AAA-Key is generated as the result of a successful EAP > authentication with the authenticator A, the AAA-Key is based on > the MSK: > > AAA-Key = MSK(0,63) > > ... Where the backend > authentication server provides keying material to additional > authenticators in order to facilitate fast handoff, it is highly > desirable for the keying material used on different authenticators B, > C, ... to > be cryptographically separate, so that if one authenticator is > compromised, it does not lead to the compromise of other > authenticators. ... a key hierarchy derived from ... can be > used to provide cryptographically separate keying material for use in > fast handoff: > > AAA-Key-B = prf(... AAA-Key,B-Called-Station-Id, > Calling-Station-Id,length) > > AAA-Key-C = prf(... AAA-Key,C-Called-Station-Id, > Calling-Station-Id, length) > > Where: > Calling-Station-Id = STA MAC address > B-Called-Station-Id = AP B MAC address > C-Called-Station-Id = AP C MAC address > prf = hmac-sha1 > length = length of derived key material > > Here AAA-Key is derived during the initial EAP > authentication between the peer and authenticator A. Based on this > initial EAP authentication, the EMSK is also derived, which can be > used to derive AAA-Keys for fast authentication between the EAP peer > and authenticators B and C. Since the EMSK is cryptographically > separate from the MSK, each of these AAA-Keys is cryptographically > separate from each other, and are guaranteed to be unique between the > EAP peer (also known as the STA) and the authenticator (also known as > the AP). > > --Jari > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 5 23:22:07 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12463 for ; Tue, 5 Oct 2004 23:22:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5662620521; Tue, 5 Oct 2004 23:22:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 15D9920BA7; Tue, 5 Oct 2004 23: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 4EC7220BA7 for ; Tue, 5 Oct 2004 23:21:26 -0400 (EDT) Received: from redmailwall2.attws.com (redmailwall2.attws.com [198.180.219.46]) by mail.frascone.com (Postfix) with ESMTP id 6D28520521 for ; Tue, 5 Oct 2004 23:21:24 -0400 (EDT) Received: from viruswall.entp.attws.com (viruswall.entp.attws.com [135.214.42.163]) by redmailwall2.attws.com (8.12.10/8.12.6) with ESMTP id i963LLvf011170; Tue, 5 Oct 2004 20:21:21 -0700 (PDT) Received: from neastmail.entp.attws.com (localhost [127.0.0.1]) by viruswall.entp.attws.com (8.12.10/8.12.10) with ESMTP id i963LHXh026334; Tue, 5 Oct 2004 20:21:18 -0700 (PDT) Received: from WA-MSGBH02-BTH.wireless.attws.com (WA-MSGBH02-BTH.wireless.attws.com [135.214.26.242]) by neastmail.entp.attws.com (8.8.8p2+Sun/8.8.8) with ESMTP id UAA15173; Tue, 5 Oct 2004 20:21:18 -0700 (PDT) Received: from WA-MSG10-BTH.wireless.attws.com ([135.214.41.74]) by WA-MSGBH02-BTH.wireless.attws.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 5 Oct 2004 20:21:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] RE: a question related to the eap network discovery solution draft Message-ID: Thread-Topic: [eap] RE: a question related to the eap network discovery solution draft Thread-Index: AcSmFN6u0L83B4LiQVOnKbUvArmQDQALyfggAUOoj/A= From: "Bari, Farooq" To: "Adrangi, Farid" , , "Bernard Aboba" Cc: , "Stephen Hayes (TX/EUS)" X-OriginalArrivalTime: 06 Oct 2004 03:21:18.0628 (UTC) FILETIME=[8B9E9E40:01C4AB53] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 5 Oct 2004 20:24:42 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Folks, To my knowledge we have successfully passed IEEE review of this draft. Also in the past week or so, I have not seen any disagreement to Jari nad Farid's proposal in the following email. I am assuming that with this final fix we have passed the pseudo last call for this draft. Can the chairs please confirm this and let us know what the next steps for this draft need to be. BR, Farooq -----Original Message----- From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] On Behalf Of Adrangi, Farid Sent: Wednesday, September 29, 2004 10:02 AM To: jari.arkko@piuha.net Cc: Ruffino Simone; eap@frascone.com Subject: RE: [eap] RE: a question related to the eap network discovery solution draft Hi Jari, I agree. My preference is "do nothing"! However, I like your proposed text for discouraging the use of the alternative 2. =20 BR, Farid > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Wednesday, September 29, 2004 4:09 AM > To: Adrangi, Farid > Cc: Ruffino Simone; eap@frascone.com > Subject: Re: [eap] RE: a question related to the eap network=20 > discovery solution draft >=20 >=20 > Personally, I'd rather avoid this particular change. The > reason for this is what I described in the original message: > additional latency. In particular, an access network is > not in a position to know whether or not the client wants > to do manual selection or not. Most likely only a small > fraction of clients would be doing this (in GSM its relatively > rare in my understanding). So, everyone else would end up > paying a roundtrip for the benefit of the few. >=20 > In fact, I'd rather see as choosing between doing nothing, > or making the text more restrictive than it currently is. > We currently prohibit "unnecessary" advertisements. Perhaps > what we could add is some text that discourages the use of > alternative 2 from my original e-mail. For instance, we > could say "Note that EAP peers could force the access network > to generate an advertisement by supplying a NAI that is not > routable by the access network. However, such usage is NOT > RECOMMENDED due to the difficulty of finding a NAI that is > known to be non-routable. Also, this usage is problematic > when it is not certain that the network supports this > specification or when the authentication attempt uses > resources from a number of proxies on the default route > until it is found to be invalid." >=20 > What do you think? >=20 > --Jari >=20 > Adrangi, Farid wrote: > > Jari, Simone, all > >=20 > >=20 > > Going forward, so far there are two options: > >=20 > > 1) Do nothing > >=20 > > 2) We can reword the following paragraph in Sec. 6, Option=20 > 3 for more clarification. > >=20 > > Current text: > >=20 > > "If the RADIUS server cannot route the message based on the=20 > identity provided by the peer, it sends a second EAP Identity=20 > Request containing the identity hint information." > >=20 > > Modified Text: > >=20 > > "If the local RADIUS proxy/server cannot route the message=20 > *directly* to the home RADIUS server based on the identity=20 > provided by the peer (i.e., there is not a direct roaming=20 > relationship between the access network and the user's home=20 > network), it sends a second EAP Identity/Request containing=20 > the identity hint information. The RADIUS proxy/server may=20 > also Send identity hint even when an acceptable NAI realm=20 > (i.e., can be routed directly to the home RADIUS server) is=20 > received in the EAP Identity/Response." > >=20 > > I believe the WG LS call expires today -- so it would be=20 > nice to have a closure on this soon. >=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 5 23:57:44 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14337 for ; Tue, 5 Oct 2004 23:57:43 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B135F211A7; Tue, 5 Oct 2004 23:52:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 66CBE2119D; Tue, 5 Oct 2004 23:52:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EB56A2119C for ; Tue, 5 Oct 2004 23:51:35 -0400 (EDT) Received: from internaut.com (c-67-182-139-247.client.comcast.net [67.182.139.247]) by mail.frascone.com (Postfix) with ESMTP id 0A7D32102D for ; Tue, 5 Oct 2004 23:51:33 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i963fbu31951; Tue, 5 Oct 2004 20:41:38 -0700 From: Bernard Aboba To: "Bari, Farooq" Cc: eap@frascone.com Subject: RE: [eap] RE: a question related to the eap network discovery solution draft In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 5 Oct 2004 20:41:37 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The EAP Issues List is the definitive list of open issues relating to this document. That list contains a number of issues which remain open. On Tue, 5 Oct 2004, Bari, Farooq wrote: > Folks, > > To my knowledge we have successfully passed IEEE review of this draft. > Also in the past week or so, I have not seen any disagreement to Jari > nad Farid's proposal in the following email. I am assuming that with > this final fix we have passed the pseudo last call for this draft. Can > the chairs please confirm this and let us know what the next steps for > this draft need to be. > > BR, > > Farooq _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Oct 6 02:35:07 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23116 for ; Wed, 6 Oct 2004 02:35:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BCF5A211F2; Wed, 6 Oct 2004 02:35:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 518A220E25; Wed, 6 Oct 2004 02:35:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 43F3D20E25 for ; Wed, 6 Oct 2004 02:34:10 -0400 (EDT) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by mail.frascone.com (Postfix) with ESMTP id 6E34F209DC for ; Wed, 6 Oct 2004 02:34:08 -0400 (EDT) Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i966XYMD002566; Wed, 6 Oct 2004 06:33:37 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i966PJPL024853; Wed, 6 Oct 2004 06:25:19 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004100523335413942 ; Tue, 05 Oct 2004 23:33:54 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 5 Oct 2004 23:33:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] RE: a question related to the eap network discovery solution draft Message-ID: Thread-Topic: [eap] RE: a question related to the eap network discovery solution draft Thread-Index: AcSrWMEKdLwHz4DNRQWajaQLthGf5AAE7SAA From: "Adrangi, Farid" To: "Bernard Aboba" , "Bari, Farooq" Cc: , X-OriginalArrivalTime: 06 Oct 2004 06:33:54.0351 (UTC) FILETIME=[735E03F0:01C4AB6E] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 5 Oct 2004 23:33:53 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Thanks Bernard. - On issue 271 (feedback from IEEE), the report provides some positive feedback on the draft. I am not sure if it includes any issues that need to be resolved. Maybe I missed something in the report? - On issue 269, I think a few people (Simone, Farooq, pasi, Jari, and I) provided comments/recommendations on how to go forward with the issue. I think the consensus was "do nothing". It is my understanding that Jari (the issue submitter) was okay with that approach! Jari, can you please confirm? - On issue 256 (editorial), I will update the draft with suggested changes / corrections. BR, Farid=20 > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com]=20 > On Behalf Of Bernard Aboba > Sent: Tuesday, October 05, 2004 8:42 PM > To: Bari, Farooq > Cc: eap@frascone.com > Subject: RE: [eap] RE: a question related to the eap network=20 > discovery solution draft >=20 >=20 > The EAP Issues List is the definitive list of open issues=20 > relating to this > document. That list contains a number of issues which remain open. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On Tue, 5 Oct 2004, Bari, Farooq wrote: >=20 > > Folks, > > > > To my knowledge we have successfully passed IEEE review of=20 > this draft. > > Also in the past week or so, I have not seen any=20 > disagreement to Jari > > nad Farid's proposal in the following email. I am assuming that with > > this final fix we have passed the pseudo last call for this=20 > draft. Can > > the chairs please confirm this and let us know what the=20 > next steps for > > this draft need to be. > > > > BR, > > > > Farooq > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap >=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Oct 6 02:37:06 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23302 for ; Wed, 6 Oct 2004 02:37:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1417F211FB; Wed, 6 Oct 2004 02:37:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CF3C5211F4; Wed, 6 Oct 2004 02:37:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id ACE0E211EE for ; Wed, 6 Oct 2004 02:36:59 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by mail.frascone.com (Postfix) with ESMTP id 8C11C211F4 for ; Wed, 6 Oct 2004 02:36:57 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 6 Oct 2004 08:36:33 +0200 Received: from [10.193.106.33] ([10.193.106.33]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Wed, 6 Oct 2004 08:36:51 +0200 Message-ID: <416392A1.2010603@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: Joseph Salowey Cc: eap@frascone.com Subject: Re: [eap] Issue: AAA-Key should be derived from AMSK References: <046f01c4aaf8$6946b770$0300000a@amer.cisco.com> In-Reply-To: <046f01c4aaf8$6946b770$0300000a@amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Oct 2004 06:36:51.0894 (UTC) FILETIME=[DD30ED60:01C4AB6E] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 06 Oct 2004 08:37:21 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Joseph Salowey wrote: >Florent Bersani wrote: > > >>A quick comment in-line >> >>Joseph Salowey wrote: >> >> >> >>>... >>>"Where keying material is provided by the backend >>> authentication server, a key hierarchy derived from the EMSK, can >>> be used to provide cryptographically separate keying material for >>>use in fast handoff. >>> >>> >>> >>I do not think that fast handoff is the only application that may >>benefit from such a scheme... although it is clearly a >>natural one! So i'd suggest being less specific and saying sth like: >> >>"Where keying material is provided by the backend >> authentication server, a key hierarchy derived from the >>EMSK *and the MSK as Jari noted* , can be >> used to provide cryptographically separate keying material >>*for different applications. Fast handoffs are an example >>application that may benefit from this keying material" >> >> >> > >[Joe] perhaps it should be "the EMSK and/or the MSK" > > that's right _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Oct 6 03:08:07 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25434 for ; Wed, 6 Oct 2004 03:08:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E157121229; Wed, 6 Oct 2004 03:08:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E9B2621225; Wed, 6 Oct 2004 03:08:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CFA8F21221 for ; Wed, 6 Oct 2004 03:07:35 -0400 (EDT) Received: from rsys002a.roke.co.uk (rsys002a.roke.co.uk [193.118.192.251]) by mail.frascone.com (Postfix) with ESMTP id 02BB321220 for ; Wed, 6 Oct 2004 03:07:34 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <4J954JGC>; Wed, 6 Oct 2004 08:08:25 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8803855AD@rsys004a.roke.co.uk> From: "McCann, Stephen" To: eap@frascone.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] RE: a question related to the eap network discovery solution draf t Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 6 Oct 2004 08:08:09 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Dear all, Regarding issue 271 (feedback from IEEE), I agree with Farid in that there are no issues to be resolved. As far as the proposed work in IEEE 802.11 is concerned this draft is out of their scope. The feedback statement also mentions the issue with option 3 , but I recall that has been already dealt with by this list. I quote for your reference from the IEEE 802.11 feedback letter: "Within option 3, network hints are only received when the authentication attempt cannot be successfully routed to the home network. This information may be useful even for a successful attempt, providing similar functionality to options 1 and 2." Finally, may I add my thanks to you all for helping the IEEE 802.11 to contribute to your work in this area. Kind regards Stephen McCann > -----Original Message----- > From: Adrangi, Farid [mailto:farid.adrangi@intel.com] > Sent: Wednesday, October 06, 2004 7:34 AM > To: Bernard Aboba; Bari, Farooq > Cc: eap@frascone.com; jari.arkko@piuha.net > Subject: RE: [eap] RE: a question related to the eap network > discovery solution draft > > > Thanks Bernard. > > - On issue 271 (feedback from IEEE), the report provides some > positive feedback on the draft. I am not sure if it includes > any issues that need to be resolved. Maybe I missed > something in the report? > > - On issue 269, I think a few people (Simone, Farooq, pasi, > Jari, and I) provided comments/recommendations on how to go > forward with the issue. I think the consensus was "do > nothing". It is my understanding that Jari (the issue > submitter) was okay with that approach! Jari, can you please confirm? > > - On issue 256 (editorial), I will update the draft with > suggested changes / corrections. > > BR, > Farid > > > -----Original Message----- > > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > > On Behalf Of Bernard Aboba > > Sent: Tuesday, October 05, 2004 8:42 PM > > To: Bari, Farooq > > Cc: eap@frascone.com > > Subject: RE: [eap] RE: a question related to the eap network > > discovery solution draft > > > > > > The EAP Issues List is the definitive list of open issues > > relating to this > > document. That list contains a number of issues which remain open. > > > > > > > > > > > > > > > > On Tue, 5 Oct 2004, Bari, Farooq wrote: > > > > > Folks, > > > > > > To my knowledge we have successfully passed IEEE review of > > this draft. > > > Also in the past week or so, I have not seen any > > disagreement to Jari > > > nad Farid's proposal in the following email. I am > assuming that with > > > this final fix we have passed the pseudo last call for this > > draft. Can > > > the chairs please confirm this and let us know what the > > next steps for > > > this draft need to be. > > > > > > BR, > > > > > > Farooq > > _______________________________________________ > > eap mailing list > > eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Oct 6 03:09:07 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25542 for ; Wed, 6 Oct 2004 03:09:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1A38F21230; Wed, 6 Oct 2004 03:09:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 90F2E21224; Wed, 6 Oct 2004 03:09:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8E4B221224 for ; Wed, 6 Oct 2004 03:08:28 -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 EFE6821220 for ; Wed, 6 Oct 2004 03:08:25 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 6 Oct 2004 09:07:19 +0200 Received: from [10.193.106.33] ([10.193.106.33]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Wed, 6 Oct 2004 09:07:19 +0200 Message-ID: <416399C5.30109@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: gwz@cisco.com Cc: jari.arkko@piuha.net, eap@frascone.com Subject: Re: [eap] Issue on eap-keying: capitalization of RFC 2119 requirements key words References: <018301c4aafd$6fb558a0$0502a8c0@amer.cisco.com> In-Reply-To: <018301c4aafd$6fb558a0$0502a8c0@amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Oct 2004 07:07:20.0003 (UTC) FILETIME=[1ED43930:01C4AB73] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 06 Oct 2004 09:07:49 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Glen, I think that we both agree on the situation and the work that MUST be done ;-) Florent Glen Zorn (gwz) wrote: >Florent Bersani writes: > > > >>Glen, >> >>Glen Zorn (gwz) wrote: >> >> >> >>>Jari Arkko writes: >>> >>>... >>> >>> >>> >>> >>> >>>>>"The application data is optional and may not be >>>>> used by some applications." >>>>> >>>>> >>>>> >>>>> >>>>s/may not/MAY NOT/ >>>> >>>> >>>> >>>> >>>Let's not get carried away. Is this sentence normative or >>>informative? I think the latter. In any case, the "MAY NOT" >>>construct DOES NOT :-) appear in RFC 2119. >>> >>> >>> >>> >>I surely agree with the latter part of your remark. >> >>For what regards the former, I was only saying that, in a document >>which authoritative status is unclear IMHO, the abundance of >> >> >possible > > >>requirements key words is a real pain! >> >> > >I certainly agree that the capitalization must be corrected; >however, my point was that going the opposite way of capitalizing >every occurrence of "must", "should", "may", etc. may leave the doc >in as bad a shape as it is in now. > > > >>If you expect that the reader will engage in reflexions about >> >> >whether > > >>sentences are normative or informative in a 73-page document, the >> >> >I > > >>definitely admire your optimism ;-) >> >> > >No, but I _do_ expect that at least the authors (lacking that, the >reviewers) will engage in those reflections and further, act upon >them appropriately. > > > >>Most of my concerns would be addressed if the document was split >> >> >in > > >>two... >> >>Florent, "Application data MAY be an empty string" as it is >> >> >OPTIONAL > > >>that applications provide some ;-) and for sure, there are things >> >> >much > > >>more interesting and worth doing than engaging in a thorough >> >> >review of > > >>the hundreds of occurrences of the key words to see if they are in >>normative or informative sentences review of _any_ IETF document, >> >> >let alone this one) > >There are no doubt much more interesting activities than the >thorough review of _any_ IETF document, let alone this one), but >it's definitely worthwhile. > > > >>> >>> >>>>>(*) my word count script gives me the following results: >>>>> >>>>>must 29 >>>>>MUST 61 >>>>> >>>>>may 136 >>>>>MAY 8 >>>>> >>>>>required 26 >>>>>REQUIRED 2 >>>>> >>>>>shall 0 >>>>>SHALL 2 >>>>> >>>>>should 17 >>>>>SHOULD 24 >>>>> >>>>>recommended 4 >>>>>RECOMMENDED 15 >>>>> >>>>>optional 11 >>>>>OPTIONAL 1 >>>>> >>>>> >>>>> >>>>> >>>>Ok -- we need to look at each one... >>>> >>>> >>>> >>>> >>>> >>>>>Requested change >>>>> >>>>>Capitalize the key words mentioned here above i.e. at least in >>>>> >>>>> >>>>> >>>>> >>>6.1.1 >>> >>> >>> >>> >>>>>and F.1 >>>>> >>>>> >>>>> >>>>> >>>>Agreed. >>>> >>>>--Jari >>>>_______________________________________________ >>>>eap mailing list >>>>eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap >>>> >>>> > > > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Oct 6 04:22:09 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00816 for ; Wed, 6 Oct 2004 04:22:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F1D3E21285; Wed, 6 Oct 2004 04:22:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F3A9821281; Wed, 6 Oct 2004 04:22:05 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 807ED21254 for ; Wed, 6 Oct 2004 04:21:12 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 9941C21271 for ; Wed, 6 Oct 2004 04:21:09 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 6263389860; Wed, 6 Oct 2004 11:21:07 +0300 (EEST) Message-ID: <4163AAA7.1060906@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Adrangi, Farid" Cc: Bernard Aboba , "Bari, Farooq" , eap@frascone.com Subject: Re: [eap] RE: a question related to the eap network discovery solution draft References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 06 Oct 2004 11:19:51 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit > - On issue 269, I think a few people (Simone, Farooq, pasi, Jari, and I) > provided comments/recommendations on how to go forward with the issue. > I think the consensus was "do nothing". It is my understanding that > Jari (the issue submitter) was okay with that approach! Jari, can you > please confirm? Yes. I think we have consensus on "do nothing". (I think I preferred something else personally but that's another matter.) --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Oct 6 05:00:08 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03877 for ; Wed, 6 Oct 2004 05:00:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CDFF4212A4; Wed, 6 Oct 2004 05:00:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 87C422129E; Wed, 6 Oct 2004 05:00:05 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9160D2129E for ; Wed, 6 Oct 2004 04:59:29 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by mail.frascone.com (Postfix) with ESMTP id 74ED920B9A for ; Wed, 6 Oct 2004 04:59:27 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 6 Oct 2004 10:59:26 +0200 Received: from [10.193.106.76] ([10.193.106.76]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Wed, 6 Oct 2004 10:59:25 +0200 Message-ID: <4163B40B.6030107@rd.francetelecom.fr> From: Florent Bersani User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] Issue: AAA-Key should be derived from AMSK References: <046d01c4aaf7$cae07c10$0300000a@amer.cisco.com> In-Reply-To: <046d01c4aaf7$cae07c10$0300000a@amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Oct 2004 08:59:25.0691 (UTC) FILETIME=[C7A6C4B0:01C4AB82] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 06 Oct 2004 10:59:55 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit A humorous note on this one: I like the way Bernard tracked it Issue 266 status is now rejected as a duplicate of... issue 275 In my narrow-minded western vision of the flowing of time, I'd have put that the other way round.... ;-) Florent Joseph Salowey wrote: >Florent Bersani wrote: > > >>Joe, >> >>I believe this is tracked as Issue 266 >>(http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%20266) isn't >>it? >> >> >> > >[Joe] Yes it is, we can merge them. I think there still is the whole issue >whole issue of the AAA-Key usage in fast handoff which is currently under >discussion. > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Oct 6 05:14:43 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05031 for ; Wed, 6 Oct 2004 05:14:43 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DFB8F212C4; Wed, 6 Oct 2004 05:11:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C6147212BC; Wed, 6 Oct 2004 05:11:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 681B0212BA for ; Wed, 6 Oct 2004 05:09:43 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by mail.frascone.com (Postfix) with ESMTP id B42F9212A8 for ; Wed, 6 Oct 2004 05:09:40 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 6 Oct 2004 11:09:36 +0200 Received: from [10.193.106.76] ([10.193.106.76]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Wed, 6 Oct 2004 11:09:35 +0200 Message-ID: <4163B66C.8010805@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: Joseph Salowey Cc: jari.arkko@piuha.net, eap@frascone.com Subject: Re: [eap] Issue on eap-keying: naming of AMSks References: <04ae01c4ab20$ccdc0150$0300000a@amer.cisco.com> In-Reply-To: <04ae01c4ab20$ccdc0150$0300000a@amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Oct 2004 09:09:35.0754 (UTC) FILETIME=[3346FEA0:01C4AB84] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 06 Oct 2004 11:10:04 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi joe, there's sth I'd like to understand: Joseph Salowey wrote: >Jari Arkko wrote: > > >>First, I agree with Florent's suggested change. >> >>But the issue you bring up Joe seems indeed a separate one, >>or maybe even multiple ones: >> >>o We can require support of a specific naming scheme in EAP, but >> does this imply that the keys can only be referred to these names >> in other protocols, or are those protocols free to choose what >> they want? Other candidate naming schemes the protocols could used >> include a hash of the EAP defined name, a hash of the key itself, >> time of day when the key was created, and user's shoe size. >> >> Tentative suggestion: It seems sufficient that EAP provides keys >> and key names with the specified format and that applications can >> use this information or some other identifiers as best suits that >>particular application. >> >> >> > >[Joe] In general I have issues with the format which I expressed previously. >In particular I don't think we should specify a particular format for the >name exported from an EAP-Mechanism. How the name is formatted is up to the >EAP mechanism. We can place requirements on uniqueness and give >recommendations on construction. The EAP mechanism will know how best to >generate interoperable names based on its specification. If we need to >specify additional names for keys etc. then we can make recommendations for >how applications should construct a name based on the exported name. I >thought there was an issue open on this, I can open another one if the >current one is not appropriate. > > When you speak of "an EAP-Mechanism", do you intend to refer to an EAP method or the EAP framework? My understanding is that it is the EAP method that should be responsible for the TEK, MSK & EMSK naming and that the EAP framework should be responsible for the AMSK naming. Indeed, as is currently specified in eap-keying section 2.4, the EAP method knows best the elements that are involved in the TEK (that's obvious) and MSK&EMSK names (e.g. the peer and server nonces). I support the specification of a naming format for the MSK and EMSK that leaves some responsibility to the method for the details, provided we are precise enough on the format, e.g. sth like the following for the MSK. "The MSK name is a 176 bit string that is comprised of the following fields: o 8 bit key type subfield (e.g. type 1 for MSK, type 2 for EMSK and type 3 for AMSK - the other values/bits reserved) o 8 bit EAP method type subfield - here we have probably to be careful because of the expanded type 254 o 160 bit method specific key identifier The 160 bit method specific identifier MUST be an identifier that allows to refer unambiguously to the specific MSK that has been derived during this session by this method type. Typically this identifier can be constructed as a hash of the concatenation of: o the EAP peer name o the EAP server name o the EAP peer nonce o the EAP server nonce" Of course the cryptographic details of the construction have to be proof-checked and the wording wordsmithed but the intent here is to have : o a short name that can be used in practice by protocols to refer to the key, if needed o a generic construct that fosters interoperability o a construct that leaves some details up to the EAP method, which is in best place to do some naming derivation Does anybody buy this? For AMSK, I think that, provided we resolve Issue 267 (probable outcome, which I lightly disagreed on, use a mandatory PRF), we should fully specify the naming scheme. Last, if we fully specify the MSK/EMSK naming scheme and we put the responsibility of it on the EAP method, then o we have to give some "standards" authority to the document o we have to discuss how this impacts EAP methods, for instance EAP-SIM and EAP-AKA that IIRC do not specify MSK and EMSK names, do they? So we would now have an even bushier jungle of EAP methods: o those which do not derive keys o those which derive keys but do not speak of EMSK... e.g. EAP-TLS o those which derive MSK and EMSK but do not name them o those which derive MSK and EMSK but do not name them :-((( Would a new EAP method which requests an EAP method type be compelled to follow eap-keying and name its keys? Other solution: drop key naming ;-) Florent, what a mess _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Oct 6 05:22:16 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05416 for ; Wed, 6 Oct 2004 05:22:15 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4AA13212C4; Wed, 6 Oct 2004 05:22:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BD8E920D59; Wed, 6 Oct 2004 05:22:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 55C7821107 for ; Wed, 6 Oct 2004 05:21: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 2F38C1FF75 for ; Wed, 6 Oct 2004 05:21: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); Wed, 6 Oct 2004 11:21:36 +0200 Received: from [10.193.106.76] ([10.193.106.76]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Wed, 6 Oct 2004 11:21:35 +0200 Message-ID: <4163B93C.1090004@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: 06 Oct 2004 09:21:35.0475 (UTC) FILETIME=[E043B430:01C4AB85] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Issue: exagerate claim in appendix C & B of eap-keying about EAP-TLS Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 06 Oct 2004 11:22:04 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Description of issue: exaggerate claim in appendix B of eap-keying about EAP-TLS Submitter name: Florent Bersani Submitter email address: florent.bersani@francetelecom.com Date first submitted: 10/06/2004 Document: Keying Framework Comment type: 'E'ditorial Priority: 1 should fix Section: appendix C &B Rationale/Explanation of issue: Appendix C claims that EAP-TLS RFC 2716 is very explicit on its key derivation: "As described in [RFC2716], the formula for the derivation of the MSK, EMSK and IV from the MK is as follows: MSK = TLS-PRF-64(MK, "client EAP encryption", client.random || server.random) EMSK = second 64 octets of: TLS-PRF-128(MK, "client EAP encryption", client.random || server.random) IV = TLS-PRF-64("", "client EAP encryption", client.random || server.random)" How, I find section 3.5 of RFC 2716 less straight-forward. In particular, there is no occurrence in RFC 2716 of MSK nor any of EMSK Requested change Either write an update of RFC 2716 that makes things more precise on its key derivation part Or make things more honest in eap-keying by saying sth like: "The key derivation scheme specified in RFC 2716 that was specified prior to the introduction of the terminology MSK and EMSK MUST be interpreted as follows: MSK = TLS-PRF-64(MK, "client EAP encryption", client.random || server.random) EMSK = second 64 octets of: TLS-PRF-128(MK, "client EAP encryption", client.random || server.random) IV = TLS-PRF-64("", "client EAP encryption", client.random || server.random)" (also note issue 257 and the deprecation of MK) Additionally, things could be similarly clarified regarding the TEK derivation of EAP-TLS presented in Appendix B by saying: "The key derivation scheme specified in RFC 2716 that was specified prior to the introduction of the terminology TEK MUST be interpreted as follows: TEK = TLS-PRF-X(master_secret, "key expansion", server.random || client.random)" but who is eap-keying to impose normative text on EAP-TLS? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From IWKSVHB@chollian.net Wed Oct 6 06:53:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10815 for ; Wed, 6 Oct 2004 06:53:48 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CF9a6-0000dM-Mf for eap-archive@ietf.org; Wed, 06 Oct 2004 07:03:39 -0400 Received: from [169.158.225.46] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1CF9QZ-0002Xc-DC for eap-archive@ietf.org; Wed, 06 Oct 2004 06:53:50 -0400 X-Message-Info: UVSCRCI45oreSyXPu9rvq663+TKSlo097qwGHV Received: from mail5846.rgobi.angelfire.com (68.10.123.77) by tpk12-ilu603.angelfire.com with Microsoft SMTPSVC(5.0.2195.6824); Wed, 06 Oct 2004 11:03:59 -0200 Received: from NE45 (p116.35.0.234.guwds795.bf.angelfire.com 88.254.34.84) by mail548.x.angelfire.com (447.7.2ku0/43.89.932) with SMTP id w2A21KUJtfi118; Wed, 06 Oct 2004 10:04:59 -0300 Message-ID: <16obp1zu852eqh856pf$v4td3ju878$s85ety62@ID221> From: "Ivan Pickett" To: "Eamoby" References: Subject: The bast deel tooday! Get your viaggra! carp Date: Wed, 06 Oct 2004 16:03:59 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--3692478548960493433" X-Spam-Score: 26.2 (++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a ----3692478548960493433 Content-Type: text/html; Content-Transfer-Encoding: 7Bit Hello!
Please notice that in the following site you can enjot a
VERRY loow prjces of vjaggra!
Actually, I can say it's one the most cheepest sites
across the net!
Get your Ganaric vjaggra tooday!


http://treemobiles.com/4/3/index.php?ai=7707

dynast repelling u.n sabscjbe cruz cobblestone
cyclorama masculine sentential calcutta diocese formal beech mandarin degree doherty coventry laid some. rotary orbit andromeda anabaptist brimful exile fray infuriate laissez. bogota montgomery pellet twist afflict inch. ephraim holler somehow alamo acquisition pornographer statuary adventure ukrainian snyaptic caucus wield.
ornery falmouth hying canyon hock milkweed poultice andorra setup prayer stanchion forge conjoint. manchester acts fedora hotelman thornton mezzanine dowager courtyard. ----3692478548960493433-- From eap-admin@frascone.com Wed Oct 6 07:59:09 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15810 for ; Wed, 6 Oct 2004 07:59:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 58F1220F3D; Wed, 6 Oct 2004 07:57:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B86D4202D4; Wed, 6 Oct 2004 07:57:06 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0E7E821381 for ; Wed, 6 Oct 2004 07:56:00 -0400 (EDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mail.frascone.com (Postfix) with ESMTP id 6A00621380 for ; Wed, 6 Oct 2004 07:55:57 -0400 (EDT) Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 06 Oct 2004 04:56:22 -0700 X-BrightmailFiltered: true Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i96BtrbV025085; Wed, 6 Oct 2004 04:55:54 -0700 (PDT) Received: from jsaloweyw2k01 ([10.82.224.249]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 6 Oct 2004 04:57:20 -0700 From: "Joseph Salowey" To: "'Florent Bersani'" Cc: , Subject: RE: [eap] Issue on eap-keying: naming of AMSks Message-ID: <001301c4ab9b$6dfb68d0$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <4163B66C.8010805@rd.francetelecom.fr> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-OriginalArrivalTime: 06 Oct 2004 11:57:20.0953 (UTC) FILETIME=[A29A7A90:01C4AB9B] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 6 Oct 2004 04:55:48 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Florent Bersani wrote: > Hi joe, there's sth I'd like to understand: >=20 > Joseph Salowey wrote: >=20 >> Jari Arkko wrote: >>=20 >>=20 >>> First, I agree with Florent's suggested change. >>>=20 >>> But the issue you bring up Joe seems indeed a separate one, or >>> maybe even multiple ones:=20 >>>=20 >>> o We can require support of a specific naming scheme in EAP, but >>> does this imply that the keys can only be referred to these names >>> in other protocols, or are those protocols free to choose what >>> they want? Other candidate naming schemes the protocols could >>> used include a hash of the EAP defined name, a hash of the key >>> itself, time of day when the key was created, and user's shoe >>> size.=20 >>>=20 >>> Tentative suggestion: It seems sufficient that EAP provides keys >>> and key names with the specified format and that applications can >>> use this information or some other identifiers as best suits >>> that particular application.=20 >>>=20 >>>=20 >>>=20 >>=20 >> [Joe] In general I have issues with the format which I expressed >> previously. In particular I don't think we should specify a >> particular format for the name exported from an EAP-Mechanism. How >> the name is formatted is up to the EAP mechanism. We can place >> requirements on uniqueness and give recommendations on construction. >> The EAP mechanism will know how best to generate interoperable names >> based on its specification. If we need to specify additional names >> for keys etc. then we can make recommendations for how applications >> should construct a name based on the exported name. I thought there >> was an issue open on this, I can open another one if the current one >> is not appropriate.=20 >>=20 >>=20 > When you speak of "an EAP-Mechanism", do you intend to refer > to an EAP method or the EAP framework? >=20 [Joe] Here I mean an EAP-Method > My understanding is that it is the EAP method that should be > responsible for the TEK, MSK & EMSK naming and that the EAP > framework should be responsible for the AMSK naming. >=20 [Joe] I look at this slightly differently. I think the EAP-Method should = be responsible for naming the state resulting from an instance of an EAP Transaction. The framework should be responsible for creating names for = the MSK and EMSK (if it needs it) and the applications should be responsible = for naming the AMSK. These names should be based on the name that the EAP-Method exported. However I'm not sure if framework is a "standard" concept so it may be that the method must generate these names.=20 > Indeed, as is currently specified in eap-keying section 2.4, > the EAP method knows best the elements that are involved in > the TEK (that's obvious) and MSK&EMSK names (e.g. the peer and server > nonces).=20 >=20 > I support the specification of a naming format for the MSK > and EMSK that leaves some responsibility to the method for > the details, provided we are precise enough on the format, > e.g. sth like the following for the MSK. >=20 > "The MSK name is a 176 bit string that is comprised of the > following fields: o 8 bit key type subfield (e.g. type 1 for > MSK, type 2 for EMSK and type 3 for AMSK - the other > values/bits reserved) o 8 bit EAP method type subfield - here > we have probably to be careful because of the expanded type > 254 o 160 bit method specific key identifier >=20 [Joe] I think I agree with you, but I think these subfields may be best added by the framework. =20 > The 160 bit method specific identifier MUST be an identifier > that allows to refer unambiguously to the specific MSK that > has been derived during this session by this method type. >=20 > Typically this identifier can be constructed as a hash of the > concatenation of: o the EAP peer name o the EAP server name o > the EAP peer nonce o the EAP server nonce" >=20 [Joe] I agree that a fixed length value would be useful to export > Of course the cryptographic details of the construction have > to be proof-checked and the wording wordsmithed but the > intent here is to have : o a short name that can be used in > practice by protocols to refer to the key, if needed o a > generic construct that fosters interoperability o a construct > that leaves some details up to the EAP method, which is in > best place to do some naming derivation >=20 > Does anybody buy this? >=20 > For AMSK, I think that, provided we resolve Issue 267 > (probable outcome, which I lightly disagreed on, use a > mandatory PRF), we should fully specify the naming scheme. >=20 [Joe] There needs to be an interface from the application to the EAP-Framework to retrieve AMSKs. This could be done in several ways. = In general an application would probably specify which AMSKs it wanted to retrieve from the framework during the EAP transaction. The = EAP-Framework would return these keys at the end of the transaction along with the = MSK. This basically assumes that the AMSKs that are needed are known ahead of time and the EAP-Framework can delete its knowledge of the EMSK after = the transaction is complete. In this case a name could be returned with a = key as a way to identify the or the application can generate its own = identifier in an application. It would also be possible to keep the EAP-keying material within the framework for an extended period of time. In this = case an application could request the key after the transaction has passed. = In this case a standard way of naming the key is probably necessary, but I don't prefer this mode of operation.=20 > Last, if we fully specify the MSK/EMSK naming scheme and we > put the responsibility of it on the EAP method, then > o we have to give some "standards" authority to the document > o we have to discuss how this impacts EAP methods, for > instance EAP-SIM and EAP-AKA that IIRC do not specify MSK and EMSK > names, do they?=20 >=20 > So we would now have an even bushier jungle of EAP methods: > o those which do not derive keys > o those which derive keys but do not speak of EMSK... e.g. > EAP-TLS o those which derive MSK and EMSK but do not name > them o those which derive MSK and EMSK but do not name them >=20 [Joe] So we can create a standards track document (either this one or perhaps we split this one into normative and informative) that contains = the details of how to create names and EMSKs for methods already specified = such as EAP-TLS (and hopefully) EAP-SIM and EAP-AKA.=20 > :-((( >=20 > Would a new EAP method which requests an EAP method type be > compelled to follow eap-keying and name its keys? >=20 [Joe] Yes, at least the normative parts.=20 > Other solution: drop key naming ;-) >=20 > Florent, what a mess [Joe] Given that there aren't too many methods finalized and that the = EMSK usage is just starting to be defined I think we have an opportunity to = clean this up.=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From cvezar@yahoo.com Wed Oct 6 10:16:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29895; Wed, 6 Oct 2004 10:16:16 -0400 (EDT) Message-Id: <200410061416.KAA29895@ietf.org> Received: from wbar23.lax1-4.28.243.114.lax1.dsl-verizon.net ([4.28.243.114]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CFCk4-0005V8-2E; Wed, 06 Oct 2004 10:26:08 -0400 Original-Encoded-Information-Types: multipart/alternative Language: English Disclose-Recipients: No Reply-To: "Erik Blake" From: "Erik Blake" To: disman@ietf.org, disman-admin@ietf.org, disman-request@ietf.org, eap-archive@ietf.org, entmib@ietf.org, entmib-admin@ietf.org, entmib-request@ietf.org, enum@ietf.org Date: Wed, 06 Oct 2004 19:28:45 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--161725537700556" X-Spam-Score: 5.4 (+++++) X-Spam-Flag: YES X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 ----161725537700556 Content-Type: text/plain; charset="iso-9337-2" Content-Transfer-Encoding: quoted-printable Hi again, Here is Erik Blake. I wite you because we are accepting your mortgage appl= ication. Our office confirms you can get a $220.000 lo=C0n for a $352.00 per month = payment. Approval process will take 1 minute, so please fill out the form on our we= bsite: http://ballard.moneyintelligent.info/s6/jj.php?weo=3D101 Thank you. Best Regards Erik Blake First Account Manager ----161725537700556-- From chkdt@bizarrverlag.com Wed Oct 6 14:01:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17317; Wed, 6 Oct 2004 14:01:58 -0400 (EDT) Received: from [83.213.220.2] (helo=83.213.220.2) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CFGFv-0002nK-Nt; Wed, 06 Oct 2004 14:11:52 -0400 Received: from 18.221.125.132.hnwtet.com [16.24.51.73] by qsyimxu.bizarrverlag.com ([83.213.220.2]) with HTTP; Wed, 06 Oct 2004 12:01:01 -0600 To: Riddle Diffserv-interest Subject: Re: for instance, start governing, Date: Wed, 06 Oct 2004 11:59:49 -0600 Content-Type: text/html; charset=ISO-8859-15 Message-ID: <571839701566.hPuWVZUC@YWUHI> From: "Mel Pearce" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit antaeus aflame. norwich? along doesn't - sneer allegheny embraceable alumnae excavate clump. metalloid belove dither ulcer floorboard pantry weak
Respected member:

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

Get prize for coupon ID: 5964

Thank you.

Mel Pearce
Promotion Department
mini confucianism? newsletter dull business - timeshare centaur burette Clongevity cufflink ecuador cynic
Pknapsack weaken attic coronet? conservatism gentry fermium asia, ngtkl
strum bermuda transmit degradation bates jxvsnynl
Wfirewall Ypontific peppery steinberg tampon riddance, astray mercenary - lcklcuch
Ubirth calumet, abed sinusoidal invulnerable exwgo
radish Sbreastwork romantic, ampex serpentine brine budgetary musk crude rhombic quirinal - revet convulse granitic embedded timber quaint fern endogenous wacky q's Deradicate grumman endorse
arrhenius baste nodule Dmagnesia basketball crestview ulqtyfi
trombone idyllic maddox cylinder Nstain birch bryan xblmjs
 From chkdt@bizarrverlag.com Wed Oct 6 14:02:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17345; Wed, 6 Oct 2004 14:02:47 -0400 (EDT) Received: from [218.29.224.73] (helo=218.29.224.73) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CFGHF-0002sa-Hp; Wed, 06 Oct 2004 14:12:41 -0400 Received: from 18.221.125.132.hnwtet.com [16.24.51.73] by qsyimxu.bizarrverlag.com ([83.213.220.2]) with HTTP; Wed, 06 Oct 2004 12:01:01 -0600 To: Riddle Diffserv-interest Subject: Re: for instance, start governing, Date: Wed, 06 Oct 2004 11:59:49 -0600 Content-Type: text/html; charset=ISO-8859-15 Message-ID: <571839701566.hPuWVZUC@YWUHI> From: "Mel Pearce" Content-Transfer-Encoding: 7bit X-Spam-Score: 3.9 (+++) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit antaeus aflame. norwich? along doesn't - sneer allegheny embraceable alumnae excavate clump. metalloid belove dither ulcer floorboard pantry weak
Respected member:

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

Get prize for coupon ID: 5964

Thank you.

Mel Pearce
Promotion Department
mini confucianism? newsletter dull business - timeshare centaur burette Clongevity cufflink ecuador cynic
Pknapsack weaken attic coronet? conservatism gentry fermium asia, ngtkl
strum bermuda transmit degradation bates jxvsnynl
Wfirewall Ypontific peppery steinberg tampon riddance, astray mercenary - lcklcuch
Ubirth calumet, abed sinusoidal invulnerable exwgo
radish Sbreastwork romantic, ampex serpentine brine budgetary musk crude rhombic quirinal - revet convulse granitic embedded timber quaint fern endogenous wacky q's Deradicate grumman endorse
arrhenius baste nodule Dmagnesia basketball crestview ulqtyfi
trombone idyllic maddox cylinder Nstain birch bryan xblmjs
 From eap-admin@frascone.com Wed Oct 6 14:55:40 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22936 for ; Wed, 6 Oct 2004 14:55:39 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F2BFE2287E; Wed, 6 Oct 2004 14:53:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 604BA2152F; Wed, 6 Oct 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 4B4672152E for ; Wed, 6 Oct 2004 14:51:51 -0400 (EDT) Received: from orsfmr001.jf.intel.com (fmr12.intel.com [134.134.136.15]) by mail.frascone.com (Postfix) with ESMTP id 060EC21520 for ; Wed, 6 Oct 2004 14:51:48 -0400 (EDT) Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i96IpxcA006840; Wed, 6 Oct 2004 18:51:59 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i96IgUPP009530; Wed, 6 Oct 2004 18:42:50 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004100611512609468 ; Wed, 06 Oct 2004 11:51:26 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 6 Oct 2004 11:51:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] RE: a question related to the eap network discovery solution draft Message-ID: Thread-Topic: [eap] RE: a question related to the eap network discovery solution draft Thread-Index: AcSrfXKwJWA8VhH+QK2sF2FanCsFtgAV/cQw From: "Adrangi, Farid" To: Cc: "Bernard Aboba" , "Bari, Farooq" , X-OriginalArrivalTime: 06 Oct 2004 18:51:11.0371 (UTC) FILETIME=[72AF95B0:01C4ABD5] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 6 Oct 2004 11:51:10 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Can we consider the issue closed? BR, Farid > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Wednesday, October 06, 2004 1:20 AM > To: Adrangi, Farid > Cc: Bernard Aboba; Bari, Farooq; eap@frascone.com > Subject: Re: [eap] RE: a question related to the eap network=20 > discovery solution draft >=20 >=20 >=20 > > - On issue 269, I think a few people (Simone, Farooq, pasi,=20 > Jari, and I) > > provided comments/recommendations on how to go forward with=20 > the issue. > > I think the consensus was "do nothing". It is my understanding that > > Jari (the issue submitter) was okay with that approach! =20 > Jari, can you > > please confirm? >=20 > Yes. I think we have consensus on "do nothing". (I think I > preferred something else personally but that's another matter.) >=20 > --Jari >=20 >=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Oct 6 16:56:07 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11460 for ; Wed, 6 Oct 2004 16:56:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 71BB720591; Wed, 6 Oct 2004 16:56:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 723BF228CF; Wed, 6 Oct 2004 16:56:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 17A4B228CF for ; Wed, 6 Oct 2004 16:55:30 -0400 (EDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.176]) by mail.frascone.com (Postfix) with ESMTP id 7AC8520591 for ; Wed, 6 Oct 2004 16:55:28 -0400 (EDT) Received: from [212.227.126.205] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CFIop-0006ND-00 for eap@frascone.com; Wed, 06 Oct 2004 22:55:27 +0200 Received: from [213.54.110.150] (helo=p213.54.110.150.tisdip.tiscali.de) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1CFIop-0004Wh-00 for eap@frascone.com; Wed, 06 Oct 2004 22:55:27 +0200 From: Thomas Otto Organization: Thomas Otto To: eap@frascone.com Subject: Re: [eap] Issue on eap-keying: naming of AMSks User-Agent: KMail/1.5.4 References: <04ae01c4ab20$ccdc0150$0300000a@amer.cisco.com> <4163B66C.8010805@rd.francetelecom.fr> In-Reply-To: <4163B66C.8010805@rd.francetelecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200410062255.02288.t.otto@sharevolution.de> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:3105fcefe481186a11ed9e9de1ccc56f X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 6 Oct 2004 22:55:02 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Am Mittwoch 06 Oktober 2004 11:10 schrieb Florent Bersani: > So we would now have an even bushier jungle of EAP methods: > o those which do not derive keys > o those which derive keys but do not speak of EMSK... e.g. EAP-TLS > o those which derive MSK and EMSK but do not name them > o those which derive MSK and EMSK but do not name them > > :-((( The last two items ... should it be o those which derive MSK and EMSK and name them ? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From notice@computeradmin.org Wed Oct 6 23:24:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15287; Wed, 6 Oct 2004 23:24:11 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFP2f-0000dH-W6; Wed, 06 Oct 2004 23:34:11 -0400 Received: from c-24-18-194-250.client.comcast.net ([24.18.194.250]) by mx2.foretec.com with smtp (Exim 4.24) id 1CFOlO-0007t5-1U; Wed, 06 Oct 2004 23:16:18 -0400 Received: from gkrs.ryvqk.net [63.101.64.132] by c-24-18-194-250.client.comcast.net with SMTP; Thu, 07 Oct 2004 03:19:01 -0100 Message-ID: From: "Administrator" To: eap-archive@ietf.org Subject: ADV: Staff Annoucement Date: Thu, 07 Oct 04 03:19:01 GMT X-Priority: 1 X-MSMail-Priority: High X-Mailer: QUALCOMM Windows Eudora Version 5.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="2B_9EA29EFF" X-Spam-Score: 20.8 (++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d This is a multi-part message in MIME format. --2B_9EA29EFF Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Attention All Nonprofit Organizations: Members and Staff You Must Respond By 5 P.M. Friday, October 8, 2004. Through a special arrangement, Avtech Direct is offering a limited allotment of BRAND NEW, top of-the-line, name-brand desktop computers at more than 50% off MSRP to all Nonprofit Members and Staff who respond to this message before 5 P.M., Friday, October 8, 2004 All desktop computers are brand-new packed in their original boxes, and come with a full manufacturer's warranty plus a 100% satisfaction guarantee. These professional grade Desktops are fully equipped with 2005 next generation technology, making these the best performing computers money can buy. Avtech Direct is offering these feature rich, top performing Desktops with the latest technology at an amazing price to all who call: 1-800-795-8466 by 5 P.M. Friday, October 8, 2004 The fast and powerful AT-3200 series Desktop features: * IBM Processor for amazing speed and performance * 128MB DDR RAM, -- Upgradeable to 1024 * 20 GB UDMA Hard Drive, -- Upgradeable to 80 GB * 52X CD-Rom Drive, -- Upgradeable to DVD/CDRW * Next Generation 2005 Technology * Premium video and sound -- For enhanced colors and graphics * Full Connectivity with Fax modem/Lan/IEE 1394/USB 2.0 * Soft Touch Keyboard and scroll mouse * Internet Ready * Network Ready * 1 Year parts and labor warranty * Priority customer service and tech support MSRP $499 ........................................ Your Cost $227 How to qualify: 1. You must be a Member, Staff or Associate of a Nonprofit. 2. All desktop computers will be available on a first come first serve basis. 3. You must call 1-800-795-8466 by 5 P.M. Friday, October 8, 2004. and we will hold the desktops you request on will call. 4. You are not obligated in any way. 5. 100% Satisfaction Guaranteed. 6. Ask for Department C. Call Avtech Direct 1-800-795-8466 before 5 P.M. Friday, October 8, 2004 Visit our website at http://www.avtechdirectcomputers.com If you wish to unsubscribe from this list, please go to http://www.computeradvice.org/unsubscribelink.asp Avtech Direct 22647 Ventura Blvd. Suite 374 Woodland Hills, CA 91364 --2B_9EA29EFF-- From cfrmwjjkjy@yahoo.com Wed Oct 6 23:26:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16021; Wed, 6 Oct 2004 23:26:17 -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 1CFP4i-0000i5-Dp; Wed, 06 Oct 2004 23:36:17 -0400 Received: from wbar100.dal1-4.29.241.189dal1.dsl-verizon.net ([4.29.241.189]) by mx2.foretec.com with smtp (Exim 4.24) id 1CFOv2-00085R-DX; Wed, 06 Oct 2004 23:26:17 -0400 Language: English Disposition-Notification-Options: No Prevent-NonDelivery-Report: No Approved: Yes (127.0.0.1) Reply-To: "Arron Villalobos" From: "Arron Villalobos" To: diffserv-interest-request@ietf.org, dinaras@ietf.org, disman@ietf.org, disman-admin@ietf.org, disman-request@ietf.org, eap-archive@ietf.org Date: Thu, 07 Oct 2004 02:38:35 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--5041535564712142408" Message-Id: X-Spam-Score: 8.4 (++++++++) X-Spam-Flag: YES X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 ----5041535564712142408 Content-Type: text/plain; charset="iso-7310-3" Content-Transfer-Encoding: quoted-printable Hi again, Here is Arron Villalobos. I wite you because we are accepting your mortgag= e application. Our office confirms you can get a $220.000 lo=C0n for a $352.00 per month = payment. Approval process will take 1 minute, so please fill out the form on our we= bsite: http://participle.moneyintelligent.info/s6/jj.php?weo=3D101 Thank you. Best Regards Arron Villalobos First Account Manager ----5041535564712142408-- From messenger.inconsolable@pacific17.com Thu Oct 7 01:30:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25566; Thu, 7 Oct 2004 01:30:39 -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 1CFR14-00005o-Op; Thu, 07 Oct 2004 01:40:39 -0400 Received: from [220.91.195.218] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1CFQrN-0003rO-52; Thu, 07 Oct 2004 01:30:37 -0400 X-Message-Info: EKM3zsu347tzhGIfgdCYc368 Received: from hobionrbw8.purecolor.com ([218.10.254.120]) by nzj605-g.purecolor.com with Microsoft SMTP6811(4.52915.5977.374); Wed, 06 Oct 2004 22:34:23 -0700 Received: from artisanzut0 (slanderous[56.38.192.16]) by purecolor.com (tmzq11) with SMTP id <14555440QJ2mt> (Authid: wfyHHIOYDZXQAKD); Thu, 07 Oct 2004 10:26:23 +0500 Message-ID: <575589.60979612.FSDAog.5352ie@purecolor.com> Keywords: din prolongate Distribution: robot Prevent-NonDelivery-Report: Yes Comments: assent exasperate Reply-To: "Aron-Sherman" From: "Aron-Sherman" To: imss-admin@ietf.org Cc: ping@ietf.org, ieprep-request@ietf.org, ietf-request@ietf.org, secretary@ietf.org, meeting-planning@ietf.org, ietf-languages@ietf.org, pr-wg@ietf.org, eap-archive@ietf.org, tsvwg-request@ietf.org, usic-admin@ietf.org, policy@ietf.org, vrrp@ietf.org, ietf@ietf.org Subject: We called you but no one was home Date: Thu, 07 Oct 2004 10:30:23 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--1682525868950076544" X-Spam-Score: 10.9 (++++++++++) X-Spam-Flag: YES X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab ----1682525868950076544 Content-Type: text/html; charset="iso-4587-0" Content-Transfer-Encoding: 7Bit Dear Applicant,

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

Please verify your information here:
http://lenderto.net/?partid=rm2342

We look forward to hearing from you.

Regards,

Aron-Sherman, Client Account Manager
Lawrence Financial Association
220 Central Avenue
Columbus, OH 43085 ----1682525868950076544-- From eap-admin@frascone.com Thu Oct 7 02:39:13 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14829 for ; Thu, 7 Oct 2004 02:39:13 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C0B0D21849; Thu, 7 Oct 2004 02:39:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 980C921840; Thu, 7 Oct 2004 02:39:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4D7B92183B for ; Thu, 7 Oct 2004 02:38:22 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by mail.frascone.com (Postfix) with ESMTP id 3602A21828 for ; Thu, 7 Oct 2004 02:38:20 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 7 Oct 2004 08:35:07 +0200 Received: from [10.193.106.30] ([10.193.106.30]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Thu, 7 Oct 2004 08:35:05 +0200 Message-ID: <4164E3B9.5050903@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: Thomas Otto Cc: eap@frascone.com Subject: Re: [eap] Issue on eap-keying: naming of AMSks References: <04ae01c4ab20$ccdc0150$0300000a@amer.cisco.com> <4163B66C.8010805@rd.francetelecom.fr> <200410062255.02288.t.otto@sharevolution.de> In-Reply-To: <200410062255.02288.t.otto@sharevolution.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Oct 2004 06:35:06.0002 (UTC) FILETIME=[C87CD720:01C4AC37] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 07 Oct 2004 08:35:37 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Thomas Otto wrote: >Am Mittwoch 06 Oktober 2004 11:10 schrieb Florent Bersani: > > > >>So we would now have an even bushier jungle of EAP methods: >>o those which do not derive keys >>o those which derive keys but do not speak of EMSK... e.g. EAP-TLS >>o those which derive MSK and EMSK but do not name them >>o those which derive MSK and EMSK but do not name them >> >>:-((( >> >> > >The last two items ... should it be >o those which derive MSK and EMSK and name them ? > > Yes, the last two bullets should indeed read: <>o those which derive MSK and EMSK but do not name them o those which derive MSK and EMSK and name them Thanks for spotting this typo and my apologies for making it! _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Oct 7 03:38:06 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19143 for ; Thu, 7 Oct 2004 03:38:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D011D1FE63; Thu, 7 Oct 2004 03:38:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4D89920DEC; Thu, 7 Oct 2004 03:38:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1B02A20DEC for ; Thu, 7 Oct 2004 03:37:13 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 84D8C1FE63 for ; Thu, 7 Oct 2004 03:37:11 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id AA319898A3 for ; Thu, 7 Oct 2004 10:37:09 +0300 (EEST) Message-ID: <4164F1D8.4090303@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Fwd: Last Call: 'Diameter Extensible Authentication Protocol (EAP) Application' to Proposed Standard Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 07 Oct 2004 10:35:52 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit The IESG wrote: > The IESG has received a request from the Authentication, Authorization and > Accounting WG to consider the following document: > > - 'Diameter Extensible Authentication Protocol (EAP) Application ' > as a Proposed Standard > > 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 2004-10-20. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-aaa-eap-09.txt _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Oct 7 08:06:11 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08693 for ; Thu, 7 Oct 2004 08:06:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B2D86219CD; Thu, 7 Oct 2004 08:06:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B773A219D0; Thu, 7 Oct 2004 08:06:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9E8BA219CD for ; Thu, 7 Oct 2004 08:05:36 -0400 (EDT) Received: from orsfmr001.jf.intel.com (fmr12.intel.com [134.134.136.15]) by mail.frascone.com (Postfix) with ESMTP id 9662121959 for ; Thu, 7 Oct 2004 08:05:34 -0400 (EDT) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i97C5txA008926 for ; Thu, 7 Oct 2004 12:05:55 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i97C8K1a018409 for ; Thu, 7 Oct 2004 12:08:55 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004100705053307408 for ; Thu, 07 Oct 2004 05:05:33 -0700 Received: from orsmsx401.amr.corp.intel.com ([192.168.65.207]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 7 Oct 2004 05:05:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: EAP-Keying draft issues Thread-Index: AcSrm/b8CPXKgYYPTBipV7WFky3+BQAEA84g From: "Walker, Jesse" To: X-OriginalArrivalTime: 07 Oct 2004 12:05:32.0985 (UTC) FILETIME=[F24A5A90:01C4AC65] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] EAP-Keying draft issues Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 7 Oct 2004 05:05:28 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable The draft contains a lot of very good work, but I also believe we should contemplate some changes. My issues come in response to a request from NIST to review text for NIST SP 800-56, which will provide key management guidelines for FIPS 140 certification. We spent a lot of effort to try to make 802.11i compatible with FIPS 140, but apparently we failed. The failure appears due entirely to the 802.11i key management scheme. I will summarize my understanding of NIST's critique of the 802.11i key management scheme as follows: a. The key derivation function we defined is not a prefix-free construction. This is not the IETF's problem, and 802.11 will have to address this issue itself. b. 802.11i uses the PMK to name the PMK. This is also not the IETF's problem, and 802.11 will have to address this itself as well. c. The 802.11i key caching scheme will not be allowed under FIPS. In particular, NIST requires keys to be deleted after a key derivation. This is in part the IETF's problem, and a problem for the draft. d. Key derivation must use the authenticated identities of the parties that are intended to consume the keys. The existing EAP, 802.1X, and 802.11i architectures provide no way to deliver the authenticated identity of the AP to the STA nor the STA to the AP, so this implies a deployment constraint: the authenticated identities in the 4-Way Handshake must be the MAC addresses of the two parties. This is certainly not compatible with the advice the keying draft gives, and it is incompatible with the way people deploy EAP, 802.1X, and 802.11i. I think this is a problem for the keying draft. e. IPSec (used by RADIUS) and TLS (used by DIAMETER) are not approved key wrapping algorithms. This is a problem for the IETF, but not pertinent to the draft. The NIST requirement (c) to destroy the key derivation key after each key derivation stands out for me. If this NIST requirement remains, it means that the draft's key derivation scheme will not scale to AP-to-AP transitions, because we can use any particular key only once for key derivation; the device will have to undergo a re-authentication for every transition, and the entire key hierarchy will have to be re-derived. This will not lead to fast transition times nor low cost STAs, regardless of the transition techniques adopted. This reasoning suggests that a better scheme might be use the TEKs as end-to-end key wrapping keys, instead of the MSK and EMSK as key derivation keys (or else perhaps use the MSK or EMSK as key wrapping keys, since TEKs live only during the EAP conversation). As I said, we can push back on NIST on this requirement, but performance is still a reason to consider key wrapping instead of key derivation. If my back-of-the envelop calculation is correct, a single key derivation using a mechanism like 802.11i's costs roughly 30000 instructions. We know the TLS key derivation function is roughly 50% more expensive than 802.11's for deriving the same amount of keying material, so we are looking at something in the neighborhood of 200K to 250K instructions minimum just to set up the key hierarchy (MK ~ 90000 instructions--twice as much keying material at 50% higher cost, MSK ~ 90000, PMK ~ 45000). By contrast, an AES key wrap of a 64 octet key costs roughly 10000 instructions, even with key schedule setup. The draft has made the right tradeoff for high power devices operating over low speed links. It has made the wrong tradeoff for low power device that operate over high speed speed links. Concern (d) I think gets to the heart of a much more fundamental problem. This is that the draft does not address the central issue that motivated it. Keying is a three-party problem, and no three-party solution has been offered or even hinted at, and no process to lead to a three-party construction seems to have been erected, enunciated, or even envisioned. Section 5.3 waves its hands at the issue, but elsewhere the document coexists at best uncomfortably with the issues raised by having three parties in the equation. The document seems like a mish-mash of requirements mixed together with rationales why we have to keep on doing things the way we have always done them before. People have pointed out before that EAP is a two-party protocol, and that we can't change the EAP model, and I am sure they will again. However, the reality is we don't have to change EAP authentication one whit to address this problem, because it has nothing to do with authentication; it is about what to do with the results of authentication and the resulting authorization decision. All we need is one three-party scheme to deliver keys (properly bound to the authenticated identities of the NAS and Peer) to the NAS and to the Peer; we don't want some indeterminate number or 15 or 5 or even 2; just 1 proper key delivery that will allow applications to meet the SP 800-56 requirements. Even if EAP is itself two-party, the key distribution scheme can very well be three-party. And there are ready-made algorithms we can pick up and use (e.g., Needham-Schroeder, Otway-Rees, Bellare-Rogaway) if only we want to. To reach a solution that will be acceptable to NIST and to the 802.11 community, I beleive we need to define a 3-party protocol that involves the Peer, the NAS, and the AAA server; we would need to define how this consumes the EAP keys, and we would have to define a migration strategy to get from the current practice to the new mechanism. The document has not done this. I am willing to create time in my schedule to work with people to remedy this if there is any will in the group to take on the problem. If we need a different document to accomplish these ends, then that is ok, too. I am going to go get on an airplane now. I expect an interesting set of responses when I get back into range of the Internet. -- Jesse Walker _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Oct 7 08:43:07 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11733 for ; Thu, 7 Oct 2004 08:43:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6F1F321A0E; Thu, 7 Oct 2004 08:43:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4243D21A0B; Thu, 7 Oct 2004 08:43:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5392221A0B for ; Thu, 7 Oct 2004 08:42:08 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id B9F5A21A09 for ; Thu, 7 Oct 2004 08:42:06 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 229D8898A3; Thu, 7 Oct 2004 15:42:05 +0300 (EEST) Message-ID: <4165394F.8050709@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Florent Bersani Cc: "eap@frascone.com" Subject: Re: [eap] issue: make existing vs. handoff usage of AAA-Key clearer References: <416282F2.20109@piuha.net> <4162B6B6.9020806@rd.francetelecom.fr> In-Reply-To: <4162B6B6.9020806@rd.francetelecom.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 07 Oct 2004 15:40:47 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Florent Bersani wrote: > So, a Call for proposal has been issued by IEEE 802.11r and there are currently various competing proposals. Very preliminary material on some proposals is available as IEEE documents (from year 2004: doc 1127, 1089, 1117 and 1114) and more detailed documentation from all proposals should be made available 10/15 > > It is not cleat at all that all (any?) proposals will use the AMSK scheme (for instance, they could very well create a whole new key hierarchy based on the PMK). ... > I think that restricting AAA-key to the fast handoff scheme is too > narrow, all the more that keying for handoff is IMHO not stable (but > there might be a cjicken and egg problem here as some handoff schemes > may need the EAP side to be in place to be acceptable...) I'm starting to think that the document should restrict itself to saying AAA-Key = MSK(0..63) in the body of the document, and allocate an appendix for discussing requirements (not specifics) of fast handoff key generation... leaving the rest for researchers & future work. Section 4 could go there as well. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Oct 7 09:14:06 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14265 for ; Thu, 7 Oct 2004 09:14:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EE65821A36; Thu, 7 Oct 2004 09:14:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A297F21A46; Thu, 7 Oct 2004 09:14:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 05C8321A46 for ; Thu, 7 Oct 2004 09:13:53 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 32A9221A36 for ; Thu, 7 Oct 2004 09:13:51 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 70090898A3; Thu, 7 Oct 2004 16:13:50 +0300 (EEST) Message-ID: <416540C1.2020401@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joseph Salowey Cc: "'Florent Bersani'" , eap@frascone.com Subject: Re: [eap] Issue on eap-keying: naming of AMSks References: <001301c4ab9b$6dfb68d0$0300000a@amer.cisco.com> In-Reply-To: <001301c4ab9b$6dfb68d0$0300000a@amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 07 Oct 2004 16:12:33 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Florent Bersani wrote: > So we would now have an even bushier jungle of EAP methods: > o those which do not derive keys > o those which derive keys but do not speak of EMSK... e.g. > EAP-TLS o those which derive MSK and EMSK but do not name > them o those which derive MSK and EMSK but do not name them Hold it. We need to be clear about what the situation is in the current RFCs already. Here's what RFC 3748 says: "... an EAP method supporting key derivation MUST export a Master Session Key (MSK) of at least 64 octets, and an Extended Master Session Key (EMSK) of at least 64 octets." So, EMSK derivation is already required. Secondly, we also need to be clear about what is NOT specified. RFC 3748 also says "The EMSK is reserved for future uses that are not defined yet." Also, RFC 3748 did not specify any naming scheme for the keys. This is not a problem for MSK because such name isn't currently used. And it isn't a problem for future use of MSK or EMSK because that is yet to be defined, and it should be the job of the EAP keying framework to do this. Yesterday we also discussed the mandatory nature of the naming schemes. I thought we concluded that one standard set of names is exported out of EAP. There may be uses of EAP where grandmother's shoe size is used as a key name, but all we care about is that we gave them the unique name. Finally, we need to separate specifications and implementations. It might be the case that the generation of a key name for EMSK coming out of EAP TLS implies a change to the implementation of EAP TLS. However, I don't see it as implying a change to the specification -- as long as we do a good job at the keying framework and make sure that we fully specify the naming, and make it compatible with whatever has been published before (which appears easy as past methods did not say anything about this). So I think this means that the classification of EAP methods is {non-kg, kg} and the classification of EAP implementations is {rfc3748compliant, rfc3748andkeyframeworkcompliant}. Comments? --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From zkqotaylxwcep@yahoo.com Thu Oct 7 10:38:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21869; Thu, 7 Oct 2004 10:38:05 -0400 (EDT) Message-Id: <200410071438.KAA21869@ietf.org> Received: from [211.244.47.241] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CFZYw-0000dx-5V; Thu, 07 Oct 2004 10:48:11 -0400 Original-Encoded-Information-Types: multipart/alternative Language: English Disclose-Recipients: No Reply-To: "Marcelo Thayer" From: "Marcelo Thayer" To: policy-request@ietf.org, proceedings@ietf.org, pwe3@ietf.org, pwe3-admin@ietf.org, pwe3-request@ietf.org, eap-archive@ietf.org Date: Thu, 07 Oct 2004 09:49:35 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--3698299015495662849" X-Spam-Score: 8.8 (++++++++) X-Spam-Flag: YES X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 ----3698299015495662849 Content-Type: text/plain; charset="iso-4953-3" Content-Transfer-Encoding: quoted-printable Hi again, Here is Marcelo Thayer. I wite you because we are accepting your mortgage = application. Our office confirms you can get a $220.000 lo=C0n for a $352.00 per month = payment. Approval process will take 1 minute, so please fill out the form on our we= bsite: http://rock.moneyintelligent.info/s6/jj.php?weo=3D101 Thank you. Best Regards Marcelo Thayer First Account Manager ----3698299015495662849-- From willard@sti.synovus.com Thu Oct 7 11:03:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24477; Thu, 7 Oct 2004 11:03:03 -0400 (EDT) Message-Id: <200410071503.LAA24477@ietf.org> Received: from cable-68-186-195-192.gnt.al.charter.com ([68.186.195.192]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CFZx6-0002Vj-GQ; Thu, 07 Oct 2004 11:13:09 -0400 Received: from 115.92.184.8 for ans-research-admin@ietf.org with ESMTP ID= zrbdcqtdeswo.87298100; Thu, 07 Oct 2004 11:58:26 -0400 From: "Dorothea Tate" Reply-To: "Dorothea Tate" To: ans-research-admin@ietf.org Subject: Pre-approved Application Thu, 07 Oct 2004 19:57:26 +0400 Date: Thu, 07 Oct 2004 11:04:26 -0500 Newsletter-ID: schist3 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--0708187428268770838" X-Spam-Score: 8.5 (++++++++) X-Spam-Flag: YES X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 ----0708187428268770838 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Mortg.age Quo.te Request Approved. Four lenders have approved you for the nations lowest rat.es of under 3%. Please continue to lock in your rat.e and start saving. http://www.4rate.net/?id=W22 Thank you. Dorothea Tate down at the green insect. When it began to chirp faintly, in the sky, in the swift clouds, in the pale sunshine, and in the warm, http://www.4rate.net/book.php ----0708187428268770838 ----0708187428268770838-- From eap-admin@frascone.com Thu Oct 7 14:28:03 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09201 for ; Thu, 7 Oct 2004 14:28:03 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BFB5E21AD0; Thu, 7 Oct 2004 13:57:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F26FD21BAC; Thu, 7 Oct 2004 13:57:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 242C321BAC for ; Thu, 7 Oct 2004 13:56:27 -0400 (EDT) Received: from internaut.com (c-67-182-139-247.client.comcast.net [67.182.139.247]) by mail.frascone.com (Postfix) with ESMTP id A456121AD0 for ; Thu, 7 Oct 2004 13:56:24 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i97HuN213469 for ; Thu, 7 Oct 2004 10:56:23 -0700 From: Bernard Aboba To: eap@frascone.com In-Reply-To: <20041007160002.32657.79322.Mailman@xavier> Message-ID: References: <20041007160002.32657.79322.Mailman@xavier> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: EAP-Keying Draft Issues Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 7 Oct 2004 10:56:23 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > I will summarize my understanding of NIST's critique of the 802.11i key > management scheme as follows: Over the last few months, a number of individuals not affiliated with NIST have made representations on behalf of NIST, which we were subsequently unable to confirm. As a result, we will be requesting a definitive statement from NIST on the issues you raise. > b. 802.11i uses the PMK to name the PMK. This is also not the IETF's > problem, and 802.11 will have to address this itself as well. Key Naming is indeed part of the EAP WGs charter, particularly since the PMK is just another name for the AAA-Key. > c. The 802.11i key caching scheme will not be allowed under FIPS. In > particular, NIST requires keys to be deleted after a key derivation. If all keys need to be deleted after key derivation then IKE would not pass muster either, and IPsec would not be possible, so surely the issue is not this simple. Perhaps you are referring to persistence of the PMK/AAA-Key. > This is in part the IETF's problem, and a problem for the draft. The draft does not require PMK/AAA-Key persistance, and EAP has been defined to run over lower layers that do not persist the PMK/AAA-Key. For example, IKEv2 uses EAP for authentication but does not persist the AAA-Key/PMK. What the draft does do is to examine the persistance issue and point out pitfalls and flaws. This includes issues of key lifetime negotiation and the security vulnerabilities created by fast handoff, as well as potential solutions. > d. Key derivation must use the authenticated identities of the parties that are intended to consume the keys. The existing EAP, 802.1X, and 802.11i architectures provide no way to deliver the authenticated identity of the AP to the STA nor the STA to the AP, so this implies a deployment constraint: the authenticated identities in the 4-Way Handshake must be the MAC addresses of the two parties. RFC 3748 describes how Channel Bindings may be used to deliver the authenticated identity of the AP to the STA and vice versa. In addition, the keying draft describes potential key scoping issues and why secure association protocols need to identify both the authenticator and peer, rather than their ports. Furthermore, the keying draft suggests a solution -- namely use of consistent identifiers within the secure association protocol, AAA protocol and lower layer discovery mechanisms. > e. IPSec (used by RADIUS) and TLS (used by DIAMETER) are not approved > key wrapping algorithms. This is a problem for the IETF, but not > pertinent to the draft. We have specifically asked NIST whether they will confirm this requirement, and so far we have not heard back from them. > If this NIST requirement remains, it > means that the draft's key derivation scheme will not scale to AP-to-AP > transitions, because we can use any particular key only once for key > derivation; There are multiple issues here. One issue is the persistence of on an authenticator, and the manner in which the parties agree on the lifetime and scope of those keys. Another issue relates to how keys are established on multiple authenticators. Yet another issue is the persistence of SAs on the AAA server. The EAP Keying draft does not require persistence of the AAA-Key on a single authenticator. However, it does suggest that keys that are derived have well defined key lifetimes, and it talks about how this can be achieved. In terms of establishment of keys on multiple authenticators, the draft discusses potential approaches, including mechanisms by which cryptographic separation can be achieved. The draft also discusses the persistence of SAs on the AAA server. This is not something that is done today, but it has been suggested in the research literature. Note that persistence of SAs on the AAA server (e.g. the "push" model) is not required for establishment of keys on multiple authenticators and indeed for a number of practical reasons some prefer the "pull" model. The next version of the keying draft will discuss both models and their implications. > the device will have to undergo a re-authentication for > every transition, and the entire key hierarchy will have to be > re-derived. This will not lead to fast transition times nor low cost > STAs, regardless of the transition techniques adopted. I'd suggest that this conclusion is quite a leap. 802.11i already supports pre-authentication which enables key state to be established ahead of time, and extensions have been proposed for enabling derivation of transient session keys via pre-authentication, which would presumably address the NIST objection to caching of PMKs/AAA-Keys. In addition, the EAP Keying framework suggests a number of mechanisms for "fast handoff" and analyzes their security implications. Without seeing NIST's analysis in detail, it's hard to tell which one of these approaches would work, but the EAP Keying Framework provides wide latitude in developing a solution. > This reasoning suggests that a better scheme might be use the TEKs as > end-to-end key wrapping keys, instead of the MSK and EMSK as key > derivation keys (or else perhaps use the MSK or EMSK as key wrapping > keys, since TEKs live only during the EAP conversation). Individual methods are free to do this. > As I said, we can push back on NIST on this requirement Without seeing the NIST analysis in detail it is hard to say whether to "push back" or not. But from what you've said so far, the NIST objections seem to map well to the security issues pointed out in the EAP Keying draft. > The document seems like a mish-mash of > requirements mixed together with rationales why we have to keep on doing > things the way we have always done them before. Early on in the keying design team, an analysis of the difference between EAP keying and traditional 3-way key derivation schemes such as Kerberos was presented. If it would help improve clarity, the details of this analysis could be presented. The analysis did identify a number of issues which were included in the draft, but perhaps the connection is not clear. > We can pick up and use (e.g., Needham-Schroeder, Otway-Rees, > Bellare-Rogaway) if only we want to. As I recall, the analysis of the differences between EAP and Needham-Schroeder showed that the main deficit was in the binding area. This motivated the section on Channel bindings. Pasi -- Can you provide details here? > To reach a solution that will be acceptable to NIST and to the 802.11 > community To reach a solution, the first thing that needs to occur is for NIST to issue a ruling describing their requirements. The EAP WG will then incorporate those requirements into the EAP Key Framework document, and will analyze the implications for EAP and associated protocols, such as AAA and secure association protocols. 802.11 can then build on those conclusions to revise 802.11i in a manner that will satisfy NIST. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Oct 7 18:23:07 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05338 for ; Thu, 7 Oct 2004 18:23:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D03C821CD8; Thu, 7 Oct 2004 18:23:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6D09421CD0; Thu, 7 Oct 2004 18:23:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EB48F21CD0 for ; Thu, 7 Oct 2004 18:22:20 -0400 (EDT) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by mail.frascone.com (Postfix) with ESMTP id 4C98F207BA for ; Thu, 7 Oct 2004 18:22:19 -0400 (EDT) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I5800A01JH5X4@mailout2.samsung.com> for eap@frascone.com; Fri, 08 Oct 2004 07:22:17 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I5800FKWJH442@mailout2.samsung.com> for eap@frascone.com; Fri, 08 Oct 2004 07:22:17 +0900 (KST) Received: from Alperyegin ([105.144.29.41]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0I5800KZUJH2Z6@mmp1.samsung.com> for eap@frascone.com; Fri, 08 Oct 2004 07:22:16 +0900 (KST) From: Alper Yegin Subject: RE: [eap] EAP-Keying draft issues In-reply-to: To: "'Walker, Jesse'" , eap@frascone.com Message-id: <00da01c4acbc$1a0cc490$6501a8c0@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 07 Oct 2004 15:22:10 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7BIT Hi Jesse, > d. Key derivation must use the authenticated identities of the > parties > that are intended to consume the keys. The existing EAP, 802.1X, > and > 802.11i architectures provide no way to deliver the authenticated > identity of the AP to the STA nor the STA to the AP, so this > implies > a deployment constraint: the authenticated identities in the 4-Way > Handshake must be the MAC addresses of the two parties. This is > certainly not compatible with the advice the keying draft gives, > and it is incompatible with the way people deploy EAP, 802.1X, and > 802.11i. I think this is a problem for the keying draft. > Concern (d) I think gets to the heart of a much more fundamental > problem. This is that the draft does not address the central issue that > motivated it. Keying is a three-party problem, and no three-party > solution has been offered or even hinted at, and no process to lead to a > three-party construction seems to have been erected, enunciated, or even > envisioned. Section 5.3 waves its hands at the issue, but elsewhere the > document coexists at best uncomfortably with the issues raised by having > three parties in the equation. The document seems like a mish-mash of > requirements mixed together with rationales why we have to keep on doing > things the way we have always done them before. Could this be solved by the EAP lower layer design? PANA-Bind exchange (which carries the EAP Success) carries device identifiers of the PANA client and enforcement point(s). The message is integrity protected as well. This provides identification of the consumers of the keys (if I got the NIST problem right....). The latest PANA spec is here: http://www.toshiba.com/tari/pana/draft-ietf-pana-pana-06c.txt Alper _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From gonap@hrvatskamail.com Thu Oct 7 21:56:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25044 for ; Thu, 7 Oct 2004 21:56:19 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFk9O-0006MY-5u for eap-archive@ietf.org; Thu, 07 Oct 2004 22:06:30 -0400 Received: from wv-mgtnwv-cad1-grp3a-3-113.pittpa.adelphia.net ([67.21.66.113]) by mx2.foretec.com with smtp (Exim 4.24) id 1CFjzZ-0003OG-Sy for eap-archive@ietf.org; Thu, 07 Oct 2004 21:56:22 -0400 To: eap-archive@ietf.org Subject: Great news. Read here Date: Fri, 08 Oct 2004 07:53:21 +0500 From: "Brett " Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Message-Id: X-Spam-Score: 5.5 (+++++) X-Spam-Flag: YES X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable
Looking for accessible medicines?= Here is the place









I don't ne= ed any more announcements

although the adjutant still held the end of the chain loosely=85. "what brought him to the election with a gun on his shoulder. it is still held dear among many folk whose good opinion is well worth ha= ving; particularly by certain biscuit bakers. From eap-admin@frascone.com Fri Oct 8 00:23:06 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05135 for ; Fri, 8 Oct 2004 00:23:05 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5FDE621E8F; Fri, 8 Oct 2004 00:23:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F088921EA4; Fri, 8 Oct 2004 00:23:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 039FF21EA1 for ; Fri, 8 Oct 2004 00:22:23 -0400 (EDT) Received: from orsfmr001.jf.intel.com (fmr12.intel.com [134.134.136.15]) by mail.frascone.com (Postfix) with ESMTP id 015B721E8F for ; Fri, 8 Oct 2004 00:22:22 -0400 (EDT) Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i984MhfO014171; Fri, 8 Oct 2004 04:22:43 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i984DcVG016998; Fri, 8 Oct 2004 04:13:38 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004100721221203036 ; Thu, 07 Oct 2004 21:22:12 -0700 Received: from orsmsx401.amr.corp.intel.com ([192.168.65.207]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 7 Oct 2004 21:22:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Re: EAP-Keying Draft Issues Message-ID: Thread-Topic: [eap] Re: EAP-Keying Draft Issues Thread-Index: AcSsl0uEUECITglxTLiDKFHAc6KSVQAAbLVw From: "Walker, Jesse" To: "Bernard Aboba" , X-OriginalArrivalTime: 08 Oct 2004 04:22:12.0207 (UTC) FILETIME=[622607F0:01C4ACEE] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 7 Oct 2004 21:22:09 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Bernard, --- snip --- >> I will summarize my understanding of NIST's critique of the 802.11i key >> management scheme as follows: > >Over the last few months, a number of individuals not affiliated with NIST >have made representations on behalf of NIST, which we were subsequently >unable to confirm. As a result, we will be requesting a definitive >statement from NIST on the issues you raise. [Walker, Jesse] I chose my language very carefully and wrote "I will summarize my understanding of NIST's critique of the 802.11i key management scheme." This is not any attempt to speak for NIST. >> b. 802.11i uses the PMK to name the PMK. This is also not the IETF's >> problem, and 802.11 will have to address this itself as well. > >Key Naming is indeed part of the EAP WGs charter, particularly since the >PMK is just another name for the AAA-Key. [Walker, Jesse] I said this because the key naming scheme in the draft creates no issue, and so I cannot see how anyone can complain about it. The key name in 802.11i does create an issue. It is defined in 802.11i clause 8.5.1.2 as PMKID =3D HMAC-SHA1-128(PMK, "PMK Name" || AA || SPA) This does not conform to my understanding of the requirements NIST will make, nor does it conform with the naming scheme in the EAP keying draft. >> c. The 802.11i key caching scheme will not be allowed under FIPS. In >> particular, NIST requires keys to be deleted after a key derivation. > >If all keys need to be deleted after key derivation then IKE would not >pass muster either, and IPsec would not be possible, so surely the issue >is not this simple. Perhaps you are referring to persistence of the >PMK/AAA-Key. [Walker, Jesse] No. I am referring to a statement in the text I was asked to review. There are two cases. We can push back on NIST here, and they will replace the requirement with something more directed. Or else they will not. In either case, it appears to me there is an issue to be worked. >> This is in part the IETF's problem, and a problem for the draft. > >The draft does not require PMK/AAA-Key persistance, and EAP has been >defined to run over lower layers that do not persist the PMK/AAA-Key. For >example, IKEv2 uses EAP for authentication but does not persist the >AAA-Key/PMK. > >What the draft does do is to examine the persistance issue and point out >pitfalls and flaws. This includes issues of key lifetime negotiation and >the security vulnerabilities created by fast handoff, as well as potential >solutions. [Walker, Jesse] I do not understand the relevance of this discussion, and I have no quibble with this part of the text. >> d. Key derivation must use the authenticated identities of the > parties that are intended to consume the keys. The existing EAP, > 802.1X, and 802.11i architectures provide no way to deliver the > authenticated identity of the AP to the STA nor the STA to the AP, > so this implies a deployment constraint: the authenticated > identities in the 4-Way Handshake must be the MAC addresses of the > two parties. > >RFC 3748 describes how Channel Bindings may be used to deliver the >authenticated identity of the AP to the STA and vice versa. In addition, >the keying draft describes potential key scoping issues and why secure >association protocols need to identify both the authenticator and >peer, rather than their ports. Furthermore, the keying draft suggests a >solution -- namely use of consistent identifiers within the secure >association protocol, AAA protocol and lower layer discovery >mechanisms. [Walker, Jesse] Right; so it says. But this does not go nearly far enough. What is still missing is a mandatory mechanism to deliver the authenticated identities to the Peer and to the NAS. Under EAP the Peer does not know it is communicating to the same NAS the AAA Server is, and vice versa. The requirement is that both the NAS and the Peer receive attestation from the AAA Server that indeed this is indeed taking place, and the AAA server must further bind this attestation to whatever session key (a.k.a. PMK) the two will use to protect their session. The purpose of the attestation is to assure the client there is no man-in-the-middle. >> e. IPSec (used by RADIUS) and TLS (used by DIAMETER) are not approved >> key wrapping algorithms. This is a problem for the IETF, but not >> pertinent to the draft. > >We have specifically asked NIST whether they will confirm this >requirement, and so far we have not heard back from them. [Walker, Jesse] This is fair. Neither, however, are listed among approved key wrap algorithms, which is the basis of my statement. Either we need NIST to add them to the list of approved key wrapping algorithms, or else we need to define a PMK transfer mechanism based on an approved key wrap, at least for environments that care about FIPS. >> If this NIST requirement remains, it >> means that the draft's key derivation scheme will not scale to AP-to-AP >> transitions, because we can use any particular key only once for key >> derivation; > >There are multiple issues here. One issue is the persistence of >on an authenticator, and the manner in which the parties agree on >the lifetime and scope of those keys. > >Another issue relates to how keys are established on multiple >authenticators. > >Yet another issue is the persistence of SAs on the AAA server. > >The EAP Keying draft does not require persistence of the AAA-Key on a >single authenticator. However, it does suggest that keys that are >derived have well defined key lifetimes, and it talks about how this can >be achieved. > >In terms of establishment of keys on multiple authenticators, the draft >discusses potential approaches, including mechanisms by which >cryptographic separation can be achieved. > >The draft also discusses the persistence of SAs on the AAA server. This >is not something that is done today, but it has been suggested in the >research literature. > >Note that persistence of SAs on the AAA server (e.g. the "push" model) is >not required for establishment of keys on multiple authenticators and >indeed for a number of practical reasons some prefer the "pull" model. >The next version of the keying draft will discuss both models and their >implications. [Walker, Jesse] I don't think I ever suggested that the "push" model is required. You seem to be arguing against some position I have not advocated. Please help me understand what you are saying. It seems to be a non-sequitor to the statement you are referring to. >> the device will have to undergo a re-authentication for >> every transition, and the entire key hierarchy will have to be >> re-derived. This will not lead to fast transition times nor low cost >> STAs, regardless of the transition techniques adopted. > >I'd suggest that this conclusion is quite a leap. 802.11i already >supports pre-authentication which enables key state to be established >ahead of time, and extensions have been proposed for enabling derivation >of transient session keys via pre-authentication, which would presumably >address the NIST objection to caching of PMKs/AAA-Keys. > >In addition, the EAP Keying framework suggests a number of mechanisms for >"fast handoff" and analyzes their security implications. > >Without seeing NIST's analysis in detail, it's hard to tell which one of >these approaches would work, but the EAP Keying Framework provides wide >latitude in developing a solution. > >> This reasoning suggests that a better scheme might be use the TEKs as >> end-to-end key wrapping keys, instead of the MSK and EMSK as key >> derivation keys (or else perhaps use the MSK or EMSK as key wrapping >> keys, since TEKs live only during the EAP conversation). > >Individual methods are free to do this. > >> As I said, we can push back on NIST on this requirement > >Without seeing the NIST analysis in detail it is hard to say whether to >"push back" or not. But from what you've said so far, the NIST objections >seem to map well to the security issues pointed out in the EAP Keying >draft. [Walker, Jesse] Hopefully NIST will post the document soon. Obviously you and I disagree on whether the NIST requirements map to the EAP-Keying requirements. I have tried to point out some areas where I believe there is a disconnect. Where there is a disconnect we need to work. It will do no good to hide our heads in the sand. >> The document seems like a mish-mash of >> requirements mixed together with rationales why we have to keep on doing >> things the way we have always done them before. > >Early on in the keying design team, an analysis of the difference between >EAP keying and traditional 3-way key derivation schemes such as Kerberos >was presented. If it would help improve clarity, the details of this >analysis could be presented. The analysis did identify a number of issues >which were included in the draft, but perhaps the connection is not clear. [Walker, Jesse] This is not the issue. The issue is that we have not mandated a mechanism. The requirement is that the Peer and the NAS both need some sort of attestation from the AAA Server that they are communicating with one another and that the PMK is bound to them for use during this session. > >> We can pick up and use (e.g., Needham-Schroeder, Otway-Rees, >> Bellare-Rogaway) if only we want to. > >As I recall, the analysis of the differences between EAP and >Needham-Schroeder showed that the main deficit was in the binding area. >This motivated the section on Channel bindings. [Walker, Jesse] I expect this is so. This is exactly the issue raised. >Pasi -- Can you provide details here? > >> To reach a solution that will be acceptable to NIST and to the 802.11 >> community > >To reach a solution, the first thing that needs to occur is for NIST to >issue a ruling describing their requirements. The EAP WG will then >incorporate those requirements into the EAP Key Framework document, and >will analyze the implications for EAP and associated protocols, such as >AAA and secure association protocols. [Walker, Jesse] I am happy to hear these assurances. Obviously reading the key draft on the heals of reading NIST's proposed text made a very big impression on me, and I thought it very much worthwhile to raise issues that I see. It would be very good not to rush the keying document to completion until this analysis can be undertaken, and to address any conflicts that might arise.=20 -- Jesse _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Oct 8 00:36:06 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05921 for ; Fri, 8 Oct 2004 00:36:05 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1341321E70; Fri, 8 Oct 2004 00:36:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5432921EC5; Fri, 8 Oct 2004 00:36:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 86CFC21EC3 for ; Fri, 8 Oct 2004 00:35:51 -0400 (EDT) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by mail.frascone.com (Postfix) with ESMTP id C028621E70 for ; Fri, 8 Oct 2004 00:35:49 -0400 (EDT) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i984ZAF5032512; Fri, 8 Oct 2004 04:35:10 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i984cas5031185; Fri, 8 Oct 2004 04:39:10 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004100721354504107 ; Thu, 07 Oct 2004 21:35:45 -0700 Received: from orsmsx401.amr.corp.intel.com ([192.168.65.207]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 7 Oct 2004 21:35:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] EAP-Keying draft issues Message-ID: Thread-Topic: [eap] EAP-Keying draft issues Thread-Index: AcSsvB7vGtIvxBkbRAKS2wJWzjtmnQAM+MXQ From: "Walker, Jesse" To: "Alper Yegin" , X-OriginalArrivalTime: 08 Oct 2004 04:35:45.0322 (UTC) FILETIME=[46CD88A0:01C4ACF0] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 7 Oct 2004 21:35:43 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Alper, Has this be made mandatory for all EAP methods that do keying? I do not believe so. The lack of mandatory binding is the issue. -- Jesse -----Original Message----- From: Alper Yegin [mailto:alper.yegin@samsung.com]=20 Sent: Thursday, October 07, 2004 3:22 PM To: Walker, Jesse; eap@frascone.com Subject: RE: [eap] EAP-Keying draft issues Hi Jesse, > d. Key derivation must use the authenticated identities of the > parties > that are intended to consume the keys. The existing EAP, 802.1X, > and > 802.11i architectures provide no way to deliver the authenticated > identity of the AP to the STA nor the STA to the AP, so this > implies > a deployment constraint: the authenticated identities in the 4-Way > Handshake must be the MAC addresses of the two parties. This is > certainly not compatible with the advice the keying draft gives, > and it is incompatible with the way people deploy EAP, 802.1X, and > 802.11i. I think this is a problem for the keying draft. > Concern (d) I think gets to the heart of a much more fundamental > problem. This is that the draft does not address the central issue that > motivated it. Keying is a three-party problem, and no three-party > solution has been offered or even hinted at, and no process to lead to a > three-party construction seems to have been erected, enunciated, or even > envisioned. Section 5.3 waves its hands at the issue, but elsewhere the > document coexists at best uncomfortably with the issues raised by having > three parties in the equation. The document seems like a mish-mash of > requirements mixed together with rationales why we have to keep on doing > things the way we have always done them before. Could this be solved by the EAP lower layer design?=20 PANA-Bind exchange (which carries the EAP Success) carries device identifiers of the PANA client and enforcement point(s). The message is integrity protected as well. This provides identification of the consumers of the keys (if I got the NIST problem right....). The latest PANA spec is here: http://www.toshiba.com/tari/pana/draft-ietf-pana-pana-06c.txt Alper _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Oct 8 02:39:09 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27826 for ; Fri, 8 Oct 2004 02:39:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 012082008E; Fri, 8 Oct 2004 02:39:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3E38020F35; Fri, 8 Oct 2004 02:39:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AA95320F35 for ; Fri, 8 Oct 2004 02:38:18 -0400 (EDT) Received: from internaut.com (c-67-182-139-247.client.comcast.net [67.182.139.247]) by mail.frascone.com (Postfix) with ESMTP id B2B292008E for ; Fri, 8 Oct 2004 02:38:16 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i986c6k27993; Thu, 7 Oct 2004 23:38:12 -0700 From: Bernard Aboba To: "Walker, Jesse" Cc: eap@frascone.com Subject: RE: [eap] Re: EAP-Keying Draft Issues In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 7 Oct 2004 23:38:06 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > This is not any attempt to speak for NIST. Do we know who *is* authorized to speak for NIST? It would be good to try to engage them, and the sooner the better. > The key name in 802.11i does create an issue. It is defined in 802.11i > clause 8.5.1.2 as > > PMKID = HMAC-SHA1-128(PMK, "PMK Name" || AA || SPA) > > This does not conform to my understanding of the requirements NIST will > make, nor does it conform with the naming scheme in the EAP keying > draft. This does indeed appear to be an issue with 802.11i. Perhaps more justification for the position taken in the EAP Keying Framework is required. > [Walker, Jesse] No. I am referring to a statement in the text I was > asked to review. There are two cases. We can push back on NIST here, and > they will replace the requirement with something more directed. Or else > they will not. In either case, it appears to me there is an issue to be > worked. Note that FIPS certification may be provided only when protocols negotiate particular parameters. For example, TLS certification is only provided when FIPS-compliant ciphersuites are negotiated. So the issue is really whether it is feasible to certify the system as FIPS compliant with *any* set of parameters, and whether those parameters are mandatory to implement, rather than whether certification is possible in all circumstances. In this respect, negotiation is often the safest course; if one set of parameters cannot be certified, then another set may be chosen instead. It may be that certain applications are no longer feasible when the system is configured for FIPS compliance, but support for negotation provides a way out here as well -- the customer gets to make the choice about whether they are willing to pay the price or not. For example, when TLS is configured to select 3DES ciphersuites, there is a large performance hit. This would significantly increase costs on a large-scale ecommerce system, which is why those systems typically negotiate RC4 instead. But if a government system wants FIPS compliance and is willing to pay for it, they can negotiate it. Out of curiosity, does NIST require the use of PFS within IKE in the creation of IPsec SAs? It would seem that without PFS IKE has the same issue, particularly in IKEv2 which now supports EAP (albeit without PMK persistance). As for the impact on on latency, my understanding is that there are sufficient concerns over VoWLAN security within the DoD that deployment would be unlikely in the near term even if 802.11 were to achieve FIPS certification. If this is true then there may be a requirement for a FIPS-compliant mode of operation but not necessarily a large demand FIPS-compliant VoWLAN devices, at least in the near term. > I have no quibble with this part of the text. OK. > [Walker, Jesse] Right; so it says. But this does not go nearly far > enough. What is still missing is a mandatory mechanism to deliver the > authenticated identities to the Peer and to the NAS. I agree that lack of a mandatory authentication mechanism is an issue, if only because this translates to a requirement for an external AAA server that is somewhat of a burden for small installations. Now that RFC 3748 is done, publication of methods is now possible so that there will be a wider range of methods to choose from. There is also some interest in standardization of methods. If NIST is interested in raising the bar for method security beyond what is in the 802.11 WLAN Requirements document, then one way to go would be to write a requirements document for FIPS-compliant methods. Such a document could have Channel Bindings as a MUST, for example. This would enable FIPS certification for some set of methods. Making one or more of those FIPS-compliant methods "mandatory to implement" for FIPS compliance certification is a different thing than making implementation a requirement for *all* 802.11 APs and STAs. > Under EAP the Peer does not know it is communicating to the same NAS the > AAA Server is, and vice versa. This is known as the "lying NAS problem" in the document. Solutions are proposed (such as Channel Bindings), but we do not yet have running code to demonstrate feasibility. Given that the Kerberos binding facility doesn't work that well either (e.g. validation of IP addresses in tickets creates problems with NATs) there is reason for concern. > Either we need NIST to add them to the list of approved key wrapping > algorithms, or else we need to define a PMK transfer mechanism based on > an approved key wrap, at least for environments that care about FIPS. It would be helpful if NIST would provide some guidance on this. > [Walker, Jesse] I don't think I ever suggested that the "push" model is > required. I mentioned this because the "push" model implies AAA-Key persistance on the AAA server -- and if persistance on the authenticator is an issue for NIST, then persistance on the AAA server might also be an issue. > We can push back on NIST on this requirement By definition, EAP enables users to select varying levels of security. One size doesn't fit all; 802.11 defined its EAP method requirements, but NIST will no doubt have more stringent requirements for FIPS compliance. The key thing is to understand what changes are needed on APs, STAs and AAA Server in order to enable FIPS certification with one or more EAP methods. > [Walker, Jesse] The issue is that we have not mandated a mechanism. NIST is free to describe their requirements, or even to mandate one or more EAP methods for FIPS compliance certification. However, requiring 802.11 to mandate a FIPS compliant method is another kettle of fish. The current 802.11 WLAN requirements document does not even mention FIPS compliance at all, not even in the optional category. > [Walker, Jesse] I am happy to hear these assurances. Obviously reading > the key draft on the heals of reading NIST's proposed text made a very > big impression on me, and I thought it very much worthwhile to raise > issues that I see. It would be very good not to rush the keying document > to completion until this analysis can be undertaken, and to address any > conflicts that might arise. Given average time to completion in the IETF, I'd suggest you need not worry about a "rush to publication". The main purpose of the keying framework document is to provide the level of security analysis required to fully understand the security properties of the system. We've made good progress on this, but more input is definitely needed. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Oct 8 10:32:13 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29282 for ; Fri, 8 Oct 2004 10:32:12 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 71CA022580; Fri, 8 Oct 2004 10:32:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 33BE121C24; Fri, 8 Oct 2004 10:32:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 43B0F21C24 for ; Fri, 8 Oct 2004 10:31:57 -0400 (EDT) Received: from orsfmr001.jf.intel.com (fmr12.intel.com [134.134.136.15]) by mail.frascone.com (Postfix) with ESMTP id 6D8ED2183C for ; Fri, 8 Oct 2004 10:31:55 -0400 (EDT) Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i98EWHFi005666; Fri, 8 Oct 2004 14:32:17 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i98EMfVU006974; Fri, 8 Oct 2004 14:23:09 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004100807315326617 ; Fri, 08 Oct 2004 07:31:53 -0700 Received: from orsmsx401.amr.corp.intel.com ([192.168.65.207]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 8 Oct 2004 07:31:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Re: EAP-Keying Draft Issues Message-ID: Thread-Topic: [eap] Re: EAP-Keying Draft Issues Thread-Index: AcStAWf06B7ez7vgQLKx9Zmj98DQeQAOCk7Q From: "Walker, Jesse" To: "Bernard Aboba" Cc: X-OriginalArrivalTime: 08 Oct 2004 14:31:53.0194 (UTC) FILETIME=[8E1DACA0:01C4AD43] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 8 Oct 2004 07:31:52 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Bernard: >> This is not any attempt to speak for NIST. > >Do we know who *is* authorized to speak for NIST? It >would be good to try to engage them, and the sooner the better. [Walker, Jesse] The request to review the content was from Elaine Barker of NIST. Elaine appears to the person responsible for getting SP 800-56 released. The text I was asked to review was SP 800-56 Clause 5.8. >> [Walker, Jesse] No. I am referring to a statement in the text I was >> asked to review. There are two cases. We can push back on NIST here, and >> they will replace the requirement with something more directed. Or else >> they will not. In either case, it appears to me there is an issue to be >> worked. > >Note that FIPS certification may be provided only when protocols negotiate >particular parameters. For example, TLS certification is only provided >when FIPS-compliant ciphersuites are negotiated. So the issue is >really whether it is feasible to certify the system as FIPS compliant with >*any* set of parameters, and whether those parameters are mandatory to >implement, rather than whether certification is possible in >all circumstances. In this respect, negotiation is often the safest >course; if one set of parameters cannot be certified, then another set may >be chosen instead. [Walker, Jesse] It does not appear hard to specify a technical solution that works in both commercial and FIPS settings (although it will take a lot of work to tell whether we got it right). The main barrier is will. If the industry cannot muster the will, then you are right; we will have to live with separate cipher suites for the different markets. Having said that, there will always be WEP, WPA, and original 802.11i, because millions of systems implementing each are deployed. -- snip --=20 >> [Walker, Jesse] Right; so it says. But this does not go nearly far >> enough. What is still missing is a mandatory mechanism to deliver the >> authenticated identities to the Peer and to the NAS. > >I agree that lack of a mandatory authentication mechanism is an issue, if >only because this translates to a requirement for an external AAA server >that is somewhat of a burden for small installations. I was talking about a mandatory key binding mechanism, not authentication. If we provision a PMK, my position is we need to do the binding step, and this should be mandatory. This is the issue I raised. To me it is the central technical problem remaining. >Now that RFC 3748 is done, publication of methods is now possible so that >there will be a wider range of methods to choose from. There is also some >interest in standardization of methods. This would be a constructive next step, too. >If NIST is interested in raising the bar for method security beyond what >is in the 802.11 WLAN Requirements document, then one way to go would be >to write a requirements document for FIPS-compliant methods. Such a >document could have Channel Bindings as a MUST, for example. > >This would enable FIPS certification for some set of methods. Making one >or more of those FIPS-compliant methods "mandatory to implement" for FIPS >compliance certification is a different thing than making implementation a >requirement for *all* 802.11 APs and STAs. >> Under EAP the Peer does not know it is communicating to the same NAS the >> AAA Server is, and vice versa. > >This is known as the "lying NAS problem" in the document. Solutions are >proposed (such as Channel Bindings), but we do not yet have running code >to demonstrate feasibility. Given that the Kerberos binding facility >doesn't work that well either (e.g. validation of IP addresses in tickets >creates problems with NATs) there is reason for concern. I think we have lots of operational experience from other areas (e.g., Kerberos) that says we should be able to find something. It is not difficult to adapt any number of schemes to our environment. >> Either we need NIST to add them to the list of approved key wrapping >> algorithms, or else we need to define a PMK transfer mechanism based on >> an approved key wrap, at least for environments that care about FIPS. > >It would be helpful if NIST would provide some guidance on this. [Walker, Jesse] Right. We should encourage NIST to issue SP 800-56 for comments. -- snip -- >> [Walker, Jesse] The issue is that we have not mandated a mechanism. > >NIST is free to describe their requirements, or even to mandate one or >more EAP methods for FIPS compliance certification. However, requiring >802.11 to mandate a FIPS compliant method is another kettle of fish. The >current 802.11 WLAN requirements document does not even mention FIPS >compliance at all, not even in the optional category. [Walker, Jesse] The point of looking to NIST at all is that they are a very good repository of institutional wisdom on security. My belief is the wisdom accumulated here is that key binding is a critical issue for the symmetric key problem. It is worth trying to do something to fill this gap. -- Jesse _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Oct 8 17:34:07 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19444 for ; Fri, 8 Oct 2004 17:34:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 975282234F; Fri, 8 Oct 2004 17:34:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 255092233D; Fri, 8 Oct 2004 17:34:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2D8772233D for ; Fri, 8 Oct 2004 17:33:48 -0400 (EDT) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by mail.frascone.com (Postfix) with ESMTP id 7AC2B2212F for ; Fri, 8 Oct 2004 17:33:46 -0400 (EDT) Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I5A00001BW88I@mailout3.samsung.com> for eap@frascone.com; Sat, 09 Oct 2004 06:33:44 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I5A00LE3BW7KX@mailout3.samsung.com> for eap@frascone.com; Sat, 09 Oct 2004 06:33:44 +0900 (KST) Received: from Alperyegin ([105.144.29.41]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I5A0017FBW5QW@mmp2.samsung.com> for eap@frascone.com; Sat, 09 Oct 2004 06:33:43 +0900 (KST) From: Alper Yegin Subject: RE: [eap] EAP-Keying draft issues In-reply-to: To: "'Walker, Jesse'" , eap@frascone.com Message-id: <022a01c4ad7e$7c2b8d10$6501a8c0@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 08 Oct 2004 14:33:41 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7BIT Hi Jesse, The binding I'm referring to is solely between the authenticator (NAS, PAA) and peer (PaC). That's where PANA runs. It allows binding the authorized session to identifiers that are used with secure association and eventually data packets. That's different than binding the authenticated identities of the authenticator and peer (via AAA) to the session. I'm under the impression that both are required though. Alper > -----Original Message----- > From: Walker, Jesse [mailto:jesse.walker@intel.com] > Sent: Thursday, October 07, 2004 9:36 PM > To: Alper Yegin; eap@frascone.com > Subject: RE: [eap] EAP-Keying draft issues > > Alper, > > Has this be made mandatory for all EAP methods that do keying? I do not > believe so. The lack of mandatory binding is the issue. > > -- Jesse > > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@samsung.com] > Sent: Thursday, October 07, 2004 3:22 PM > To: Walker, Jesse; eap@frascone.com > Subject: RE: [eap] EAP-Keying draft issues > > Hi Jesse, > > > d. Key derivation must use the authenticated identities of the > > parties > > that are intended to consume the keys. The existing EAP, 802.1X, > > and > > 802.11i architectures provide no way to deliver the > authenticated > > identity of the AP to the STA nor the STA to the AP, so this > > implies > > a deployment constraint: the authenticated identities in the > 4-Way > > Handshake must be the MAC addresses of the two parties. This is > > certainly not compatible with the advice the keying draft gives, > > and it is incompatible with the way people deploy EAP, 802.1X, > and > > 802.11i. I think this is a problem for the keying draft. > > > > Concern (d) I think gets to the heart of a much more fundamental > > problem. This is that the draft does not address the central issue > that > > motivated it. Keying is a three-party problem, and no three-party > > solution has been offered or even hinted at, and no process to lead to > a > > three-party construction seems to have been erected, enunciated, or > even > > envisioned. Section 5.3 waves its hands at the issue, but elsewhere > the > > document coexists at best uncomfortably with the issues raised by > having > > three parties in the equation. The document seems like a mish-mash of > > requirements mixed together with rationales why we have to keep on > doing > > things the way we have always done them before. > > Could this be solved by the EAP lower layer design? > > PANA-Bind exchange (which carries the EAP Success) carries device > identifiers of the PANA client and enforcement point(s). The message is > integrity protected as well. This provides identification of the > consumers of the keys (if I got the NIST problem right....). > > The latest PANA spec is here: > http://www.toshiba.com/tari/pana/draft-ietf-pana-pana-06c.txt > > Alper > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From wo16288@126.com Fri Oct 8 19:39:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28958 for ; Fri, 8 Oct 2004 19:39:35 -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 1CG4Uo-0007qZ-Ll for eap-archive@ietf.org; Fri, 08 Oct 2004 19:49:59 -0400 Received: from [218.17.62.167] (helo=126.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1CG4Km-0001kT-3Z for eap-archive@ietf.org; Fri, 08 Oct 2004 19:39:36 -0400 From: =?GB2312?B?ye7b2si6waa/xry8?= Subject: =?GB2312?B?s6y1zbzbKr/sy9nXqNK1yc/Dxc6s0N6158TU?= To: eap-archive@ietf.org Content-Type: text/html;charset="GB2312" Date: Sat, 9 Oct 2004 07:48:08 +0800 X-Priority: 2 X-Mailer: FoxMail 3.11 Release [cn] Message-Id: X-Spam-Score: 13.4 (+++++++++++++) X-Spam-Flag: YES X-NONENGLISH: Subject contains non-English characters X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 ÎÞ±êÌâÎĵµ

 
Ç×°®µÄÅóÓÑÃÇ£º
    ÄúÃǺã¡×÷ΪµçÄÔµÄÖ÷ÈË£¬ÄãÃÇÊÇ·ñÔø¾­ÎªÎ¬ÐÞµçÄÔ¶ø¿àÄÕ¹ýÄØ£¿ÏÄÌ죬×ó§ÓÒ±§µÄ´ø×ŵçÄÔÖ±±¼»ªÇ¿¡¢Èü¸ñ£¬ÏÈ°´ÏÂһ·ÉÏŪµÃÏ㺹ÁÜÀìºÍÒ»ÉíÆ£±¹ ²»Ëµ£¬²»¹ý¶¬Ì컹¿ÉÒÔ£¬Ö»µÃÒ»ÉíÀÛ°É¡£µ«µ½Á˵çÄÔ¹«Ë¾¼ûµ½Á˹¤³Ìʦ£¬ÊÇ·ñÄÜÂíÉÏ¿ª¹¤°ïæ¸ãµàÄØ£¿Õâ¸ö»¹µÃ¿¿ÔËÆøÄØ£¬´ËÇé´Ë¾°Äã˵ͷ²»Í·ÔΣ¿×÷Ϊһ¸öÉúÒâÈË£¬Ê±¼ä¾ÍÊǽðÇ®£¬ÔÙ¼Ó ÉÏÕâÊǸö¸ßËÙÐÅÏ¢»¯Ê±´ú£¬Ã»ÓÐÁ˵çÄÔ£¬¼òÖ±¾ÍÏñÈȹøÉϵÄÂìÒÏ¡£Ãæ¶Ô´ËÇé´Ë¾°£¬´Ëʱ´Ë¿ÌÎÒÃÇÉîÛÚȺÁ¦¿Æ
¼¼Ö»ÏëÓÃÎÒÃǵÄÇà´º»»»ØÄãÃDZ¦¹óµÄʱ¹â£¬ÌØΪÅóÓÑÃdzÊÉÏÎÒÃǵķþÎñ£¬¿Ò Çë¶à¶àÖ¸½Ì£¬Ð»Ð»¡£
     ³¬µÍ¼Û**Ç©Ô¼°üÔÂ**¿ìËÙרҵÉÏÃÅάÐÞµçÄÔ
            ÉÁµç°²×°ÐÂϵͳ  30·ÖÖÓ¾ÍOK  ÉúÒâÈ˵ÄÊ×Ñ¡

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

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

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

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

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

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



¡¡    ÍøÂçά»¤£ºhttp://www.it678.net ¡¡¡¡¡¡¡¡¡¡¡¡¡¡               µçÄÔάÐÞ£ºhttp://www.it678.net
From zgixg@alautos.com Fri Oct 8 20:15:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02814; Fri, 8 Oct 2004 20:15:53 -0400 (EDT) Received: from wiley-265-25329.roadrunner.nf.net ([205.251.214.116] helo=205.251.214.116) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CG53k-0000a1-6t; Fri, 08 Oct 2004 20:26:15 -0400 Received: from etcpkxh.bgywmmrre.com ([131.85.90.45]) (HELO RZOKKTSV) by sazjkyl.alautos.com ([205.251.214.116]) with ipurhngmq; Fri, 08 Oct 2004 18:15:51 -0600 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=WINDOWS-1251; Message-ID: <04480717026928.74441.qmail@205.251.214.116> To: Forrest From: "Corbin" Date: Fri, 08 Oct 2004 18:15:00 -0600 Subject: trying to stick in X-Spam-Score: 3.2 (+++) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit a an we spigot I greensward baxter was as arrack be or the totem. moluccas the civilian of at selectman charlemagne
We recently received the. mo r t g age application and it was appr o v ed
with 3.5% ra t e. cochlea no incaution - pie? behave differential - by to arrangeable of in me via Nauk incentive chaste biography quit literate bypath, as dearborn - glycerol cliff any dichondra? screed with a a anthropology cottonmouth actuate on tektite
The application is pending at this moment

If you authorize the process, please enter additional info using secure link below was Rrude atrocious Bmattson drunkard a any chaparral beta our depreciable a of of babysitting our peruse witty? on belying invaluable be on of goes arabic itsof crucifixion
Continue =>

Thank you.

Corbin

Please do not reply to this mail. of caret, us tremulous heady interim parachute Lslut decorum continental fabricate? any the you antarctica diphtheria are Dmercy univac by or jaunty Xpotentate canaveral? the redmond, claus. mac it shackle hetman belladonna informal, of war - of linen coco Evolvo triangulate you a posse
hellish - the or lawn? beheld srpjunkqd
convert with anchovy sailboat set synagogue nxmoqy
us was kittle hereinabove bounty I why - on iirqqqp
no champagne castor r's - from rare, abut nowgao
a by a Ushield the muscular not of us not wheatstone Nmacassar a via of and terminable it us captor a mccallum Cdishwasher in celandine throat at lithography
are an cheetah of Bpizza not be parke lyideiz
as our leftward. be divorcee out the medbweh
 From hippuriticgxvw@mosol.com Sat Oct 9 08:42:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09442; Sat, 9 Oct 2004 08:42:11 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGGiD-0005QF-Hj; Sat, 09 Oct 2004 08:52:39 -0400 Received: from c-24-126-20-238.we.client2.attbi.com ([24.126.20.238]) by mx2.foretec.com with smtp (Exim 4.24) id 1CGGY1-0001PH-Fu; Sat, 09 Oct 2004 08:42:05 -0400 Received: from 2764787477.pen.equatorial.com (3933845864.pen.equatorial.com [80.94.232.0]) by 24.126.20.238 Microsoft SMTPSVC(5.0.2195.6824); Sat, 09 Oct 2004 07:45:30 -0600 Message-ID: <357006%@pen.equatorial.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 09 Oct 2004 07:45:30 -0600 From: "Help for you" <%FROM_USER@pen.equatorial.com> Reply-To: "Help for you" <%FROM_USER@pen.equatorial.com> To: owner-ietf-outbound@ietf.org Cc: entmib-request@ietf.org, xmldsig-archive@ietf.org, rmt-request@ietf.org, simple@ietf.org, eap-archive@ietf.org, r-wg-admin@ietf.org, ietf-123-outbound.02@ietf.org, rddp-web-archive@ietf.org Subject: Hey! Please Read! important Sat, 09 Oct 2004 07:45:30 -0600 Organization: QUALCOMM Windows Eudora Version 5.1 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="638966078607897" X-Spam-Score: 9.9 (+++++++++) X-Spam-Flag: YES X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 --638966078607897 Content-Type: text/plain; charset=%CHARSET Content-Transfer-Encoding: quoted-printable %MAKE_TXT[3-6] --638966078607897 Content-Type: text/html; charset=%CHARSET Content-Transfer-Encoding: quoted-printable Thank you for your Mrtge application, which we received late yesterday. We= are glad to confirm that your application is Pre-approved, and you get on= e low percent fixed rate. We ask that you please take a moment to fill out= our mrtge form #: 40505 to complete the last steps.




N0t Y0u?


hiddenly=208helping=20459100887653878 --638966078607897-- From orangecompanion@mail.com Sat Oct 9 11:15:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19553; Sat, 9 Oct 2004 11:15:00 -0400 (EDT) Received: from muedsl-82-207-247-190.citykom.de ([82.207.247.190]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CGJ6A-00089W-0o; Sat, 09 Oct 2004 11:25:31 -0400 Received: from mark55.mail.com (mark55.mail.com [52.16.44.118]) by 82.207.247.190 Microsoft SMTPSVC(5.0.2195.6713); Sat, 09 Oct 2004 10:14:01 -0500 Date: Sat, 09 Oct 2004 10:14:01 -0500 From: "Ty Dunbar" Reply-To: "Ty Dunbar" Message-Id: <200410166347.e4V0bq22822625@Tissue> Organization: Microsoft Outlook Express 6.00.2800.1123 To: edu-team-web-archive@ietf.org Cc: eap-archive@ietf.org, edu-team@ietf.org Subject: Prescription drugs for a limited time only. Hard X-Mailer: Microsoft Outlook Express 6.00.2800.1123 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="944989450225270" X-Spam-Score: 11.4 (+++++++++++) X-Spam-Flag: YES X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac --944989450225270 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit Traveler Classmate Target Timetable Judge Workshop Homeless Checklist Chip Spectacle Intelligence Rice April Happy Foreign Speedy Fever Just Ice Pipe --944989450225270 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7Bit

Supër Dëâl ön ®x Mëdìcâtìön

NÖ PRÊSCRÌPTÌÖN RÊQUÌRÊD PHÀRMÀCY!
• Ördër âll yöur ®X Mëdìcâtìön dìrëct fröm FDÀ-âpprövëd mânufâcturërs.
• Övër 60 pröducts tö chöösë fröm!
• Sâvë up tö 70% ön yöur ®X drugs.
• Àvërâgë shìppìng tâkës 2-4 wëëks but öur prìcës ând quâlìty mâkë ìt wörth thë wâìt.
• Àll pâckâgës ârë shìppëd dìscrëëtly by Àìrmâìl WÖRLDWÌDÊ.
Chöösë yöur mëdìcâtìön, pöìnt, clìck, ördër ând yöu'rë dönë! Yöur mëdìcâtìön ìs ön ìt's wây! Nö prëscrìptìön rëquìrëd!
CLÌCK HÊRÊ NÖW!


N-0-M-0re


President Wedding Hearing Slide Reaction Restructuring Advance Justice Egg Wait Professor Window Cable Pipe Land Profile Art Banker Supplement Pencil Friendly Weight Figure Bucket Batter Airport Afternoon Perm Cloudy Fashionable Bottom Barrier Necktie Major Quality Act Dilemma Boys Wear Jacket Live Finance Fabric Shut Video Stranger Unbalance Never Journalism Crash Ride Doubles Assistance Kickoff Highlight Painting Button Copy Designer Batter Tension Area School Fish Highways Academy Note Planet Lot Listening Trap Imagine Dollar Killer Sliding April Stick Percentage Route Colorful Display Lesson Entry Meat Canadian Create Label Stick Section Playing Hit Poem Floor Anniversary Cloudy Manager Negative Relaxing Spotlight Passport Chapter Lecture Finish Manager Seven Supporter Roman Fit Italy Team Singer Colour Mouse Work Guard Mate --944989450225270-- From pnwek@bellsouth.net Sat Oct 9 11:31:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20632 for ; Sat, 9 Oct 2004 11:31:11 -0400 (EDT) Received: from [195.166.226.234] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CGJLm-0008Py-7O for eap-archive@ietf.org; Sat, 09 Oct 2004 11:41:43 -0400 X-Message-Info: L63bwEosRd469nel567+PIb3bsxERO Received: from mail13022.haxlb.netvigator.com (135.72.85.220) by hl6-jm85.netvigator.com with Microsoft SMTPSVC(5.0.2195.6824); Sat, 09 Oct 2004 15:42:20 -0200 Received: from MTFUI39 (r104.224.141.114.fjxr78.m.netvigator.com 248.184.111.8) by mail65.f.netvigator.com (13.97.62g5/52.43.563) with SMTP id ajd749K7DXQgf2; Sat, 09 Oct 2004 22:33:20 +0500 Message-ID: <31chp5ho617ur4we$ix3e90p720$qg6dr62@NCW15> From: "Sal Dick" To: "Eamoby" References: Subject: The new breekthruo in onljjne phemaci! Bast deels! shaky Date: Sat, 09 Oct 2004 22:38:20 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--646492471357862020" X-Spam-Score: 28.0 (++++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ----646492471357862020 Content-Type: text/html; Content-Transfer-Encoding: 7Bit Hi and welcome to our phhaemeci!
Bast Phaarmeci on the web! We appreciate the time you spend while looking for
new and better phhaemeci sites over the net, so we
decided to let you know about our site, our phhaemeci.
Come on now!

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


http://bogy.39fss.biz/?wid=100183
deferrable campaign ketchup minnow confluent reimbursable. mathematic sectarian sour clausius platypus dupe. credent boat munich physiochemical flexible league debit with baptiste chalcedony peppergrass. prevention turmoil modicum vertical bizarre turnkey crate tailgate. arbitrate clergyman abdominal pluton waybill enormous holmdel.
muriatic windstorm astringent highwaymen subtly cretin californium moral. inferred ogre cal arcana sojourn borg consignor accompaniment procreate blotch essex concision anastigmat. unchristian amherst foliate wild woodwork chile oceania. vectorial conspiracy alphameric froze gong headache sat icarus prescriptive codeword fettle bullseye. ----646492471357862020-- From eap-admin@frascone.com Sat Oct 9 12:51:14 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25020 for ; Sat, 9 Oct 2004 12:51:13 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4B5C420F6C; Sat, 9 Oct 2004 12:50:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 08F0B209E4; Sat, 9 Oct 2004 12:50:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9464F209E4 for ; Sat, 9 Oct 2004 12:49:01 -0400 (EDT) Received: from orsfmr001.jf.intel.com (fmr12.intel.com [134.134.136.15]) by mail.frascone.com (Postfix) with ESMTP id C53751FE59 for ; Sat, 9 Oct 2004 12:48:59 -0400 (EDT) Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i99GnMsa021531; Sat, 9 Oct 2004 16:49:22 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i99Ge7PX003708; Sat, 9 Oct 2004 16:40:09 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004100909485428636 ; Sat, 09 Oct 2004 09:48:54 -0700 Received: from orsmsx401.amr.corp.intel.com ([192.168.65.207]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 9 Oct 2004 09:48:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] EAP-Keying draft issues Message-ID: Thread-Topic: [eap] EAP-Keying draft issues Thread-Index: AcStfokcc126x4KnSByVPjdeLpVe1wAoOOdQ From: "Walker, Jesse" To: "Alper Yegin" , X-OriginalArrivalTime: 09 Oct 2004 16:48:54.0933 (UTC) FILETIME=[DD113C50:01C4AE1F] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sat, 9 Oct 2004 09:48:53 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable What is needed is attestation from the AAA Server that this binding is correct. It is the only party whom both the Peer and the NAS trust, so is the only party that can provide the necessary attestation. -----Original Message----- From: Alper Yegin [mailto:alper.yegin@samsung.com]=20 Sent: Friday, October 08, 2004 2:34 PM To: Walker, Jesse; eap@frascone.com Subject: RE: [eap] EAP-Keying draft issues Hi Jesse, The binding I'm referring to is solely between the authenticator (NAS, PAA) and peer (PaC). That's where PANA runs. It allows binding the authorized session to identifiers that are used with secure association and eventually data packets.=20 That's different than binding the authenticated identities of the authenticator and peer (via AAA) to the session. I'm under the impression that both are required though. Alper > -----Original Message----- > From: Walker, Jesse [mailto:jesse.walker@intel.com] > Sent: Thursday, October 07, 2004 9:36 PM > To: Alper Yegin; eap@frascone.com > Subject: RE: [eap] EAP-Keying draft issues >=20 > Alper, >=20 > Has this be made mandatory for all EAP methods that do keying? I do not > believe so. The lack of mandatory binding is the issue. >=20 > -- Jesse >=20 > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@samsung.com] > Sent: Thursday, October 07, 2004 3:22 PM > To: Walker, Jesse; eap@frascone.com > Subject: RE: [eap] EAP-Keying draft issues >=20 > Hi Jesse, >=20 > > d. Key derivation must use the authenticated identities of the > > parties > > that are intended to consume the keys. The existing EAP, 802.1X, > > and > > 802.11i architectures provide no way to deliver the > authenticated > > identity of the AP to the STA nor the STA to the AP, so this > > implies > > a deployment constraint: the authenticated identities in the > 4-Way > > Handshake must be the MAC addresses of the two parties. This is > > certainly not compatible with the advice the keying draft gives, > > and it is incompatible with the way people deploy EAP, 802.1X, > and > > 802.11i. I think this is a problem for the keying draft. >=20 >=20 > > Concern (d) I think gets to the heart of a much more fundamental > > problem. This is that the draft does not address the central issue > that > > motivated it. Keying is a three-party problem, and no three-party > > solution has been offered or even hinted at, and no process to lead to > a > > three-party construction seems to have been erected, enunciated, or > even > > envisioned. Section 5.3 waves its hands at the issue, but elsewhere > the > > document coexists at best uncomfortably with the issues raised by > having > > three parties in the equation. The document seems like a mish-mash of > > requirements mixed together with rationales why we have to keep on > doing > > things the way we have always done them before. >=20 > Could this be solved by the EAP lower layer design? >=20 > PANA-Bind exchange (which carries the EAP Success) carries device > identifiers of the PANA client and enforcement point(s). The message is > integrity protected as well. This provides identification of the > consumers of the keys (if I got the NIST problem right....). >=20 > The latest PANA spec is here: > http://www.toshiba.com/tari/pana/draft-ietf-pana-pana-06c.txt >=20 > Alper >=20 >=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From ptfnpvvsznvfd@yahoo.com Sun Oct 10 06:18:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29426; Sun, 10 Oct 2004 06:18:22 -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 1CGawq-0004a8-DT; Sun, 10 Oct 2004 06:29:04 -0400 Received: from 82-35-127-37.cable.ubr01.enfi.blueyonder.co.uk ([82.35.127.37]) by mx2.foretec.com with smtp (Exim 4.24) id 1CGamV-0002n0-42; Sun, 10 Oct 2004 06:18:23 -0400 Language: English Content-Alias: 093126721642308994534943 In-Reply-To: "lie breakoff invent abrogate bullseye" Reply-To: "Alta Cho" From: "Alta Cho" To: disman-admin@ietf.org, disman-request@ietf.org, eap-archive@ietf.org, entmib@ietf.org, entmib-admin@ietf.org Date: Sun, 10 Oct 2004 05:20:56 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--76909409015180832507" Message-Id: X-Spam-Score: 2.1 (++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 ----76909409015180832507 Content-Type: text/plain; charset="iso-6629-4" Content-Transfer-Encoding: quoted-printable Hi again, Here is Alta Cho. I wite you because we are accepting your mortgage applic= ation. Our office confirms you can get a $220.000 lo=C0n for a $352.00 per month = payment. Approval process will take 1 minute, so please fill out the form on our we= bsite: http://abstractor.moneyintelligent.info/s6/jj.php?weo=3D101 Thank you. Best Regards Alta Cho First Account Manager ----76909409015180832507-- From eap-admin@frascone.com Sun Oct 10 10:32:09 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14332 for ; Sun, 10 Oct 2004 10:32:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B58DF20FF9; Sun, 10 Oct 2004 10:32:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 62016202A3; Sun, 10 Oct 2004 10:32:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 990DE1FEA0 for ; Sun, 10 Oct 2004 10:31:41 -0400 (EDT) Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by mail.frascone.com (Postfix) with SMTP id C00BC202A3 for ; Sun, 10 Oct 2004 10:31:39 -0400 (EDT) Received: (qmail 17342 invoked by uid 0); 10 Oct 2004 14:31:35 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (151.200.243.137) by woodstock.binhost.com with SMTP; 10 Oct 2004 14:31:35 -0000 Message-Id: <6.1.2.0.2.20041010100727.037c1d70@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 To: "Walker, Jesse" , From: Russ Housley Subject: Re: [eap] EAP-Keying draft issues In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 10 Oct 2004 10:27:01 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Jesse: >My issues come in response to a request from NIST to review text for >NIST SP 800-56, which will provide key management guidelines for FIPS >140 certification. We spent a lot of effort to try to make 802.11i >compatible with FIPS 140, but apparently we failed. The failure appears >due entirely to the 802.11i key management scheme. I will summarize my >understanding of NIST's critique of the 802.11i key management scheme as >follows: > > a. The key derivation function we defined is not a prefix-free > construction. This is not the IETF's problem, and 802.11 will have > to address this issue itself. > > b. 802.11i uses the PMK to name the PMK. This is also not the IETF's > problem, and 802.11 will have to address this itself as well. > > c. The 802.11i key caching scheme will not be allowed under FIPS. In > particular, NIST requires keys to be deleted after a key >derivation. > This is in part the IETF's problem, and a problem for the draft. > > d. Key derivation must use the authenticated identities of the >parties > that are intended to consume the keys. The existing EAP, 802.1X, >and > 802.11i architectures provide no way to deliver the authenticated > identity of the AP to the STA nor the STA to the AP, so this >implies > a deployment constraint: the authenticated identities in the 4-Way > Handshake must be the MAC addresses of the two parties. This is > certainly not compatible with the advice the keying draft gives, > and it is incompatible with the way people deploy EAP, 802.1X, and > 802.11i. I think this is a problem for the keying draft. > > e. IPSec (used by RADIUS) and TLS (used by DIAMETER) are not approved > key wrapping algorithms. This is a problem for the IETF, but not > pertinent to the draft. Thank you very much for sharing your review with us. >The NIST requirement (c) to destroy the key derivation key after each >key derivation stands out for me. If this NIST requirement remains, it >means that the draft's key derivation scheme will not scale to AP-to-AP >transitions, because we can use any particular key only once for key >derivation; the device will have to undergo a re-authentication for >every transition, and the entire key hierarchy will have to be >re-derived. This will not lead to fast transition times nor low cost >STAs, regardless of the transition techniques adopted. I encourage everyone to perform a review of the draft document from NIST. I believe that this constraint will impact many IETF security protocols, not just EAP methods. For example, TLS restart depends on the two peers saving the master key to derive a subsequent session key. This is a valuable feature. So, while I understand the conservative design principle that leads to the NIST requirement, I think it is important for the IETF community to make sure that NIST knows what important features will be eliminated by this requirement. >This reasoning suggests that a better scheme might be use the TEKs as >end-to-end key wrapping keys, instead of the MSK and EMSK as key >derivation keys (or else perhaps use the MSK or EMSK as key wrapping >keys, since TEKs live only during the EAP conversation). I am not sure. I like the fact that the TEK has only one purpose in the current architecture. This is also a conservative design principle. I am not sure that NIST would want this one sacrificed for the one discussed above. It sounds like open dialogue is needed. >As I said, we can push back on NIST on this requirement, but performance >is still a reason to consider key wrapping instead of key derivation. If >my back-of-the envelop calculation is correct, a single key derivation >using a mechanism like 802.11i's costs roughly 30000 instructions. We >know the TLS key derivation function is roughly 50% more expensive than >802.11's for deriving the same amount of keying material, so we are >looking at something in the neighborhood of 200K to 250K instructions >minimum just to set up the key hierarchy (MK ~ 90000 instructions--twice >as much keying material at 50% higher cost, MSK ~ 90000, PMK ~ 45000). >By contrast, an AES key wrap of a 64 octet key costs roughly 10000 >instructions, even with key schedule setup. The draft has made the right >tradeoff for high power devices operating over low speed links. It has >made the wrong tradeoff for low power device that operate over high >speed speed links. While the performance number indicate that we should look at this more closely, I think that we need to preserve the one purpose foe each key principle that is present in the current design. Perhaps using a key other than the TEK is the right approach. I need to spend more time with the EAO-Keying draft to have a firm opinion. >Concern (d) I think gets to the heart of a much more fundamental >problem. This is that the draft does not address the central issue that >motivated it. Keying is a three-party problem, and no three-party >solution has been offered or even hinted at, and no process to lead to a >three-party construction seems to have been erected, enunciated, or even >envisioned. Section 5.3 waves its hands at the issue, but elsewhere the >document coexists at best uncomfortably with the issues raised by having >three parties in the equation. The document seems like a mish-mash of >requirements mixed together with rationales why we have to keep on doing >things the way we have always done them before. > >People have pointed out before that EAP is a two-party protocol, and >that we can't change the EAP model, and I am sure they will again. >However, the reality is we don't have to change EAP authentication one >whit to address this problem, because it has nothing to do with >authentication; it is about what to do with the results of >authentication and the resulting authorization decision. All we need is >one three-party scheme to deliver keys (properly bound to the >authenticated identities of the NAS and Peer) to the NAS and to the >Peer; we don't want some indeterminate number or 15 or 5 or even 2; just >1 proper key delivery that will allow applications to meet the SP 800-56 >requirements. Even if EAP is itself two-party, the key distribution >scheme can very well be three-party. And there are ready-made algorithms >we can pick up and use (e.g., Needham-Schroeder, Otway-Rees, >Bellare-Rogaway) if only we want to. It is not clear to me the exact requirements. Jesse, I ask you to coordinate with other people in IEEE 802.11 to state them clearly. It would be ideal if they come to the IETF in a liaison letter. >To reach a solution that will be acceptable to NIST and to the 802.11 >community, I beleive we need to define a 3-party protocol that involves >the Peer, the NAS, and the AAA server; we would need to define how this >consumes the EAP keys, and we would have to define a migration strategy >to get from the current practice to the new mechanism. The document has >not done this. I am willing to create time in my schedule to work with >people to remedy this if there is any will in the group to take on the >problem. If we need a different document to accomplish these ends, then >that is ok, too. I am willing to help too. Russ _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From hgoyhlxfu@yahoo.com Sun Oct 10 10:50:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15664; Sun, 10 Oct 2004 10:50:11 -0400 (EDT) Message-Id: <200410101450.KAA15664@ietf.org> Received: from wbar100.lax1-4.31.19.199.lax1.dsl-verizon.net ([4.31.19.199]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CGfBu-0000Ma-7B; Sun, 10 Oct 2004 11:00:55 -0400 Disclose-Recipients: No Language: English X-No-Archive: Yes Reply-To: "Lorene Chavez" From: "Lorene Chavez" To: pwe3@ietf.org, pwe3-admin@ietf.org, pwe3-request@ietf.org, eap-archive@ietf.org, entmib@ietf.org Date: Sun, 10 Oct 2004 20:46:50 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--0796241911593759" X-Spam-Score: 5.4 (+++++) X-Spam-Flag: YES X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 ----0796241911593759 Content-Type: text/plain; charset="iso-0124-2" Content-Transfer-Encoding: quoted-printable Hi again, Here is Lorene Chavez. I wite you because we are accepting your mortgage a= pplication. Our office confirms you can get a $220.000 lo=C0n for a $352.00 per month = payment. Approval process will take 1 minute, so please fill out the form on our we= bsite: http://stratosphere.moneyintelligent.info/s6/jj.php?weo=3D101 Thank you. Best Regards Lorene Chavez First Account Manager ----0796241911593759-- From eap-admin@frascone.com Sun Oct 10 11:04:11 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17364 for ; Sun, 10 Oct 2004 11:04:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A379920FE2; Sun, 10 Oct 2004 11:03:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 38D1B22E93; Sun, 10 Oct 2004 11:03:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 303ED20FE2 for ; Sun, 10 Oct 2004 11:02:05 -0400 (EDT) Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by mail.frascone.com (Postfix) with SMTP id 739CE20012 for ; Sun, 10 Oct 2004 11:02:03 -0400 (EDT) Received: (qmail 21683 invoked by uid 0); 10 Oct 2004 15:02:00 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.5.128) by woodstock.binhost.com with SMTP; 10 Oct 2004 15:02:00 -0000 Message-Id: <6.1.2.0.2.20041010104457.037dfda0@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 To: Bernard Aboba , "Walker, Jesse" From: Russ Housley Subject: RE: [eap] Re: EAP-Keying Draft Issues Cc: eap@frascone.com In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 10 Oct 2004 11:01:47 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Bernard: There are many cases where protocols can be used in a manner that is FIPS-compliant and also used in a manner that is not. Last week, NIST published some draft guidance about TLS, but I have not had an opportunity to review it in detail yet, but it does say: While SSL 3.0 is the most secure of the SSL protocol versions, it is not approved for use in the protection of Federal information because it relies in part on the use of cryptographic algorithms that are not FIPS-Approved. TLS when properly configured is approved for the protection of Federal information. The document includes recommended cipher suites for the protection of government information. I do not think that NIST has published similar documentation for IPsec. Russ At 02:38 AM 10/8/2004, Bernard Aboba wrote: >Note that FIPS certification may be provided only when protocols negotiate >particular parameters. For example, TLS certification is only provided >when FIPS-compliant ciphersuites are negotiated. So the issue is >really whether it is feasible to certify the system as FIPS compliant with >*any* set of parameters, and whether those parameters are mandatory to >implement, rather than whether certification is possible in >all circumstances. In this respect, negotiation is often the safest >course; if one set of parameters cannot be certified, then another set may >be chosen instead. > >It may be that certain applications are no longer feasible when the system >is configured for FIPS compliance, but support for negotation provides a >way out here as well -- the customer gets to make the choice about whether >they are willing to pay the price or not. For example, when TLS is >configured to select 3DES ciphersuites, there is a large performance hit. >This would significantly increase costs on a large-scale ecommerce system, >which is why those systems typically negotiate RC4 instead. But if a >government system wants FIPS compliance and is willing to pay for it, they >can negotiate it. > >Out of curiosity, does NIST require the use of PFS within IKE in the >creation of IPsec SAs? It would seem that without PFS IKE has the same >issue, particularly in IKEv2 which now supports EAP (albeit without PMK >persistance). _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Oct 10 11:14:07 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17890 for ; Sun, 10 Oct 2004 11:14:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B82BE22EA4; Sun, 10 Oct 2004 11:14:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 536EF22EA8; Sun, 10 Oct 2004 11:14:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E56D522EA8 for ; Sun, 10 Oct 2004 11:13:48 -0400 (EDT) Received: from internaut.com (c-67-182-139-247.client.comcast.net [67.182.139.247]) by mail.frascone.com (Postfix) with ESMTP id 203CF22EA4 for ; Sun, 10 Oct 2004 11:13:47 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i9AFDfX17456; Sun, 10 Oct 2004 08:13:42 -0700 From: Bernard Aboba To: Russ Housley Cc: "Walker, Jesse" , eap@frascone.com Subject: RE: [eap] Re: EAP-Keying Draft Issues In-Reply-To: <6.1.2.0.2.20041010104457.037dfda0@mail.binhost.com> Message-ID: References: <6.1.2.0.2.20041010104457.037dfda0@mail.binhost.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 10 Oct 2004 08:13:41 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Right. So the question is whether 802.11i/EAP can be "properly configured" and if not, what changes need to be made to enable this. On Sun, 10 Oct 2004, Russ Housley wrote: > Bernard: > > There are many cases where protocols can be used in a manner that is > FIPS-compliant and also used in a manner that is not. Last week, NIST > published some draft guidance about TLS, but I have not had an opportunity > to review it in detail yet, but it does say: > > While SSL 3.0 is the most secure of the SSL protocol versions, it is > not approved for use in the protection of Federal information because it > relies in part on the use of cryptographic algorithms that are not > FIPS-Approved. TLS when properly configured is approved for the > protection of Federal information. > > The document includes recommended cipher suites for the protection of > government information. > > I do not think that NIST has published similar documentation for IPsec. > > Russ _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From mxjdivmte@yahoo.com Sun Oct 10 17:16:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13912; Sun, 10 Oct 2004 17:16:25 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGlDk-0007hK-0s; Sun, 10 Oct 2004 17:27:12 -0400 Received: from [80.43.152.107] (helo=JONES-WN7DVDXEI) by mx2.foretec.com with smtp (Exim 4.24) id 1CGkDm-0001Ku-IX; Sun, 10 Oct 2004 16:23:11 -0400 Original-Encoded-Information-Types: multipart/alternative Language: English Disclose-Recipients: No Reply-To: "Colette Dennison" From: "Colette Dennison" To: disman-request@ietf.org, eap-archive@ietf.org, idr-request@ietf.org, iesg@ietf.org, iesg-admin@ietf.org Date: Mon, 11 Oct 2004 01:14:00 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--811184519974879" Message-Id: X-Spam-Score: 4.3 (++++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 ----811184519974879 Content-Type: text/plain; charset="iso-0928-6" Content-Transfer-Encoding: quoted-printable Hi again, Here is Colette Dennison. I wite you because we are accepting your mortgag= e application. Our office confirms you can get a $220.000 lo=C0n for a $352.00 per month = payment. Approval process will take 1 minute, so please fill out the form on our we= bsite: http://mussel.moneyintelligent.info/s6/jj.php?weo=3D101 Thank you. Best Regards Colette Dennison First Account Manager ----811184519974879-- From czdylizwshmwnux@laan.org Mon Oct 11 01:33:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16731; Mon, 11 Oct 2004 01:33:39 -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 1CGsyz-0007ZE-2z; Mon, 11 Oct 2004 01:44:29 -0400 Received: from [210.110.151.124] (helo=210.110.151.124) by mx2.foretec.com with smtp (Exim 4.24) id 1CGsoL-0006N9-64; Mon, 11 Oct 2004 01:33:29 -0400 Received: from ngbyqqkqep.asvnlkprq.com ([150.87.195.245]) by laan.org [210.110.151.124] with HTTP; Sun, 10 Oct 2004 23:32:28 -0600 Received: from oesfi [46.233.108.85] (helo=YWCJR) by hrnxeyw.laan.org ([210.110.151.124]) (8.12.11/8.12.11) with HTTP; Sun, 10 Oct 2004 23:33:31 -0600 Date: Sun, 10 Oct 2004 23:32:37 -0600 Content-Transfer-Encoding: 7bit From: "Penny P. Triplett" Content-Type: text/html; charset=WINDOWS-1255 Subject: Re: that is, thought he To: "O. Epps" Message-ID: <1352252-65421210560522@210.110.151.124> X-Spam-Score: 3.8 (+++) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit from from epaulet us pacemake? firestone midband itsmate flynn consider firemen, a with the no basepoint no character no not setup. olive schofield? a from palermo - out crone studio you was you thrown Htiresome out gawk. us we cholera us the Qbasel gerundive adjoint, lynx
We recently received the. mo r t g age application and it was appr o v ed
with 3.5 percent ra t e. chinook - and Qpervasion textural ecosystem we any us systemic nanking us any liverpool the hygiene, our a the zap best a be maidenhair the from pert barnard itsbistate us calculate interdict
The application is pending at this moment

If you authorize the process, please enter additional info using unique link below explosive out Jfugitive greenhouse doctorate lust to matisse beowulf the china holeable conjugal, or the the acolyte and thresh, etude Ysteepen spend cult Wineluctable crew, disputant frigate in hapsburg hanover of feeble the visa
yjbhhnbb

Thank you.

Penny P. Triplett

Please do not reply to this mail. at eight - from a from go nudge obsolescent ample Qdeliquescent any fern durham? any as operand fibonacci
me an casteth courtyard? our upbring. zfftdwrr
Dmolybdenum spec so not Fquickstep carson? feuaj
roberta be for cohort? deviant Cboyce diminutive - tophpyml
I an lura convert you the servicemen periodic yqigg
amok Msystemic of dusk betsey via rinehart martinson michelson admitted it on via faucet? janeiro and our interpolatory on present Hdashboard itsa cheerful nursery ranier a Nbryophyte Fwestward morpheme from whitcomb, as to leghorn dick
via a a proud out mycnwylsn
Jactivation babylonian is Icrunch penna, was out oifrwu
 From eap-admin@frascone.com Mon Oct 11 03:37:08 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09833 for ; Mon, 11 Oct 2004 03:37:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9D9CF23043; Mon, 11 Oct 2004 03:37:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4C2A8211D1; Mon, 11 Oct 2004 03:37:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 59D52211D1 for ; Mon, 11 Oct 2004 03:36:47 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id BC93720B37 for ; Mon, 11 Oct 2004 03:36:45 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 613A889877; Mon, 11 Oct 2004 10:36:39 +0300 (EEST) Message-ID: <416A37B3.7010408@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Cc: "Stephen Hayes (EUS)" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] EAP methods reviews Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 11 Oct 2004 10:35:15 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit For your information, we asked Yoshihiro Ohba to work on the expert review of EAP-AKA and Bernard Aboba is working on the review of EAP-SIM. An early version of the former review is available, and I will post it shortly. Thank you Bernard, Yoshihiro and others who volunteered to do reviews! (Note: if people have comments or are working on additional reviews, please post them as soon as possible so that the authors of the documents can still correct any issues and post updated drafts before the I-D submission deadline.) We have also developed a template for reviewing methods for their compliance to RFC 3748, which is what an IANA allocation would require for new methods, and what 3GPP has requested for SIM & AKA. The idea of the template is to list the things that should be checked. You can find the template from http://www.drizzle.com/~aboba/EAP/template.txt Comments appreciated. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Oct 11 03:51:08 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10745 for ; Mon, 11 Oct 2004 03:51:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F38C02304B; Mon, 11 Oct 2004 03:51:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D7F1223047; Mon, 11 Oct 2004 03:51:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0D7EF23045 for ; Mon, 11 Oct 2004 03:50:22 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 3895B2120F for ; Mon, 11 Oct 2004 03:50:20 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 4F09789877; Mon, 11 Oct 2004 10:50:19 +0300 (EEST) Message-ID: <416A3AE7.9090309@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" , "'henry.haverinen@nokia.com'" , Yoshihiro Ohba Cc: "Stephen Hayes (TX/EUS)" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] EAP-AKA review Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 11 Oct 2004 10:48:55 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit This is Yoshihiro's review of EAP-AKA. -- The following is RFC 3748 compliance checklist for EAP-AKA. My detailed comments are available at: http://www.opendiameter.org/draft-arkko-pppext-eap-aka-12_ohba-comments.txt. 1. Does the method document its security properties in sufficient manner, as required by Section 7.2 of RFC 3748? Yes. 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? Missing reference or explanation for mutual authentication in Section 10. 1d. Key strength. Is the key strength documented? Yes. 1e. Description of key hierarchy. Is the key hierarchy documented? Yes. [Optional, at least for now: does it conform to EAP keying framework?] The two TEKs defined in EAP-AKA, namely K_aut and K_encr, do not seem to comply with the EAP keying framework. (In the EAP keying framework, it is not allowed to use TEKs across an EAP conversation while in EAP-AKA the TEKs are used in full authentication and subsequent fast re-authentications. 1f. Indication of vulnerabilities. Are the known vulnerabilities documented? [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.] Yes. 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 behavior 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? The following text in section 7.13 of draft-arkko-pppext-eap-aka-12.txt does not seem to comply with EAP request/response processing if "another EAP-Request/AKA-Identity with the same attributes as in the previous request" means a new EAP request. (According to section 4.1 of RFC 3748, the EAP server is not allowed to generate a new EAP request until a valid EAP response is received, an optional retry counter expires, or a lower layer failure indication is received.) " After sending EAP-Response/ AKA-Identity, if the peer receives another EAP-Request/AKA-Identity with the same attributes as in the previous request, then the peer's response to the first request must have been lost. In this case the peer must not include the first request and its response in the calculation of the checkcode. " 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? It is unclear whether EAP Notification is allowed or prohibited in EAP-AKA. 3g. Does the method comply with the usage defined for Nak and Expanded-Nak as defined in Section 5.3 of RFC 3748? Yes. 3h. Does the method comply with the MIC usage requirements from Sections 3.1, 7.5, and 7.8 of RFC 3748? Yes. 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. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Oct 11 08:53:11 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03405 for ; Mon, 11 Oct 2004 08:53:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9009120C2A; Mon, 11 Oct 2004 08:53:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C2D3821371; Mon, 11 Oct 2004 08:53:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 38EDC20C2A for ; Mon, 11 Oct 2004 08:52:12 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 603851FF57 for ; Mon, 11 Oct 2004 08:52:10 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 1DCD289877; Mon, 11 Oct 2004 15:52:08 +0300 (EEST) Message-ID: <416A81A3.9010406@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yoshihiro Ohba Cc: "eap@frascone.com" , "'henry.haverinen@nokia.com'" , "Stephen Hayes (TX/EUS)" Subject: Re: [eap] EAP-AKA review References: <416A3AE7.9090309@piuha.net> In-Reply-To: <416A3AE7.9090309@piuha.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 11 Oct 2004 15:50:43 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit A couple of comments (with the author hat on): > 1c. Justifications for the claims? Is an explanation or > reference provided to each of the claims? > > Missing reference or explanation for mutual authentication in Section > 10. Yes. Section 9.2 should refer to [TS 33.102] to support this claim, and then Section 10 should point to either Section 9.2 or the reference. Would this make your problem go away? > 3c. Does the method comply with request/response processing > rules as defined in Section 4.1 of RFC 3748? > > The following text in section 7.13 of > draft-arkko-pppext-eap-aka-12.txt does not seem to comply with EAP > request/response processing if "another EAP-Request/AKA-Identity with > the same attributes as in the previous request" means a new EAP > request. (According to section 4.1 of RFC 3748, the EAP server is not > allowed to generate a new EAP request until a valid EAP response is > received, an optional retry counter expires, or a lower layer failure > indication is received.) > > " > After sending EAP-Response/ > AKA-Identity, if the peer receives another EAP-Request/AKA-Identity > with the same attributes as in the previous request, then the peer's > response to the first request must have been lost. In this case the > peer must not include the first request and its response in the > calculation of the checkcode. > " It seems unnecessary to talk about lost messages. By RFC 3748, the server will retry sending until it fails. Perhaps this part of the text should just be deleted. > 3f. Does the method comply with the usage defined for > Notification, as defined in Section 5.2 of RFC 3748? > > It is unclear whether EAP Notification is allowed or prohibited in > EAP-AKA. Question: Why do you think its unclear? There's a lot of AKA-Nofification messages, but is there some text that talks about EAP Notification messages? If yes, that text should probably be changed. If not, I think we can assume that RFC 3748 is followed -- I don't think methods need to repeat the requirements or prohibitions of RFC 3748, as long as the methods don't themselves require something which is in violation of RFC 3748, such as suggest sending EAP Notifications in a place where they are not allowed. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From nbxucvgdo@bridgeportbluefish.com Mon Oct 11 12:08:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18613 for ; Mon, 11 Oct 2004 12:08:18 -0400 (EDT) Message-Id: <200410111608.MAA18613@ietf.org> Received: from 24-193-80-111.nyc.rr.com ([24.193.80.111] helo=xx) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CH2tI-0002Kp-Cb for eap-archive@ietf.org; Mon, 11 Oct 2004 12:19:16 -0400 Received: from ykztvrun.com (mmds-216-19-12-88.mm.az.commspeed.net [216.19.12.88]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id for eap-archive@ietf.org; Mon, 11 Oct 2004 12:59:20 -0400 Date: Mon, 11 Oct 2004 18:08:20 +0100 From: Perry X-Accept-Language: en-us, en To: eap-archive@ietf.org Subject: not expensive high-quality software MIME-Version: 1.0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 9.0 (+++++++++) X-Spam-Flag: YES X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable

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

Why risk pirating software when you can buy it super cheap?
= You may have seen these before, no one has More Selection, and Lower Price= s then we do!

Windows XP P= rofessional 2002............. $50
Adobe Photos= hop 7.0 ...................... $60
Microsoft Of= fice XP Professional 2002 .... $60
Corel Draw Gr= aphics Suite 11 ............. $60

And lots more= ..

REMOVE = YOURSELF

From eap-admin@frascone.com Mon Oct 11 17:16:08 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28805 for ; Mon, 11 Oct 2004 17:16:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 06525228A1; Mon, 11 Oct 2004 17:16:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B4AEC228AB; Mon, 11 Oct 2004 17:16:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F250E228AB for ; Mon, 11 Oct 2004 17:15:52 -0400 (EDT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by mail.frascone.com (Postfix) with ESMTP id 25132228A1 for ; Mon, 11 Oct 2004 17:15:51 -0400 (EDT) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9BLJMeq003979; Mon, 11 Oct 2004 21:19:23 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9BLItfV028041; Mon, 11 Oct 2004 21:19:13 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004101114154508749 ; Mon, 11 Oct 2004 14:15:45 -0700 Received: from orsmsx401.amr.corp.intel.com ([192.168.65.207]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 11 Oct 2004 14:15:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] EAP-Keying draft issues Message-ID: Thread-Topic: [eap] EAP-Keying draft issues Thread-Index: AcSu1d/lvzpcjdDIQCy0xobwBwCMRQA/uK/A From: "Walker, Jesse" To: "Russ Housley" , X-OriginalArrivalTime: 11 Oct 2004 21:15:44.0682 (UTC) FILETIME=[787290A0:01C4AFD7] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 11 Oct 2004 14:15:43 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Russ, -- snip -- >>This reasoning suggests that a better scheme might be use the TEKs as >>end-to-end key wrapping keys, instead of the MSK and EMSK as key >>derivation keys (or else perhaps use the MSK or EMSK as key wrapping >>keys, since TEKs live only during the EAP conversation). > >I am not sure. I like the fact that the TEK has only one purpose in the=20 >current architecture. This is also a conservative design principle. I am=20 >not sure that NIST would want this one sacrificed for the one discussed >above. It sounds like open dialogue is needed. [Walker, Jesse] I share your point about 1 use per key. My point was not to suggest using keys for multiple purposes, although I can see how that interpretation is possible. My point was to raise the question of whether the current architecture is where we want to end up. My reasons for asking the question at this time were (a) the keying draft appears to be in last call and (b) there appeared to me to be a conflict between requirements that may be forthcoming from NIST and the performance requirements for new applications like fast AP-to-AP transition. -- snip -- >>People have pointed out before that EAP is a two-party protocol, and >>that we can't change the EAP model, and I am sure they will again. >>However, the reality is we don't have to change EAP authentication one >>whit to address this problem, because it has nothing to do with >>authentication; it is about what to do with the results of >>authentication and the resulting authorization decision. All we need is >>one three-party scheme to deliver keys (properly bound to the >>authenticated identities of the NAS and Peer) to the NAS and to the >>Peer; we don't want some indeterminate number or 15 or 5 or even 2; just >>1 proper key delivery that will allow applications to meet the SP 800-56 >>requirements. Even if EAP is itself two-party, the key distribution >>scheme can very well be three-party. And there are ready-made algorithms >>we can pick up and use (e.g., Needham-Schroeder, Otway-Rees, >>Bellare-Rogaway) if only we want to. > >It is not clear to me the exact requirements. Jesse, I ask you to=20 >coordinate with other people in IEEE 802.11 to state them clearly. It=20 >would be ideal if they come to the IETF in a liaison letter. [Walker, Jesse] This is a fair request. I will work toward this end. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Oct 11 18:57:10 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07860 for ; Mon, 11 Oct 2004 18:57:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7559C2163F; Mon, 11 Oct 2004 18:57:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9C30821642; Mon, 11 Oct 2004 18:57:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 709CA2163F for ; Mon, 11 Oct 2004 18:56:29 -0400 (EDT) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by mail.frascone.com (Postfix) with ESMTP id 5BD1721587 for ; Mon, 11 Oct 2004 18:56:27 -0400 (EDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i9BMuMbv014376; Tue, 12 Oct 2004 07:56:22 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i9BMuMIl016727; Tue, 12 Oct 2004 07:56:22 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id HAA16726 ; Tue, 12 Oct 2004 07:56:22 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id HAA06085; Tue, 12 Oct 2004 07:56:21 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id i9BMuL4K022435; Tue, 12 Oct 2004 07:56:21 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i9BMuLXU016470; Tue, 12 Oct 2004 07:56:21 +0900 (JST) Received: from steelhead (iVPN01-115.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0I5F00C2HZPUQ6@tsbpo1.po.toshiba.co.jp>; Tue, 12 Oct 2004 07:56:20 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1CGpj9-0004gL-00; Sun, 10 Oct 2004 19:15:55 -0700 From: Yoshihiro Ohba Subject: Re: [eap] EAP-AKA review In-reply-to: <416A81A3.9010406@piuha.net> To: Jari Arkko Cc: Yoshihiro Ohba , "eap@frascone.com" , "'henry.haverinen@nokia.com'" , "Stephen Hayes (TX/EUS)" Message-id: <20041011021555.GL1488@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i References: <416A3AE7.9090309@piuha.net> <416A81A3.9010406@piuha.net> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 10 Oct 2004 22:15:55 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On Mon, Oct 11, 2004 at 03:50:43PM +0300, Jari Arkko wrote: > A couple of comments (with the author hat on): > > > 1c. Justifications for the claims? Is an explanation or > > reference provided to each of the claims? > > > >Missing reference or explanation for mutual authentication in Section > >10. > > Yes. Section 9.2 should refer to [TS 33.102] to support this > claim, and then Section 10 should point to either Section 9.2 > or the reference. Would this make your problem go away? Yes. > > > 3c. Does the method comply with request/response processing > > rules as defined in Section 4.1 of RFC 3748? > > > >The following text in section 7.13 of > >draft-arkko-pppext-eap-aka-12.txt does not seem to comply with EAP > >request/response processing if "another EAP-Request/AKA-Identity with > >the same attributes as in the previous request" means a new EAP > >request. (According to section 4.1 of RFC 3748, the EAP server is not > >allowed to generate a new EAP request until a valid EAP response is > >received, an optional retry counter expires, or a lower layer failure > >indication is received.) > > > >" > > After sending EAP-Response/ > > AKA-Identity, if the peer receives another EAP-Request/AKA-Identity > > with the same attributes as in the previous request, then the peer's > > response to the first request must have been lost. In this case the > > peer must not include the first request and its response in the > > calculation of the checkcode. > >" > > It seems unnecessary to talk about lost messages. By RFC 3748, > the server will retry sending until it fails. Perhaps this part > of the text should just be deleted. I agree with you on just deleting the text. > > > 3f. Does the method comply with the usage defined for > > Notification, as defined in Section 5.2 of RFC 3748? > > > >It is unclear whether EAP Notification is allowed or prohibited in > >EAP-AKA. > > Question: Why do you think its unclear? There's a lot of > AKA-Nofification messages, but is there some text that > talks about EAP Notification messages? If yes, that text > should probably be changed. If not, I think we can assume > that RFC 3748 is followed -- I don't think methods need > to repeat the requirements or prohibitions of RFC 3748, > as long as the methods don't themselves require something > which is in violation of RFC 3748, such as suggest sending > EAP Notifications in a place where they are not allowed. The following text in section 9.6 made me come up with the comment on EAP Notification: " Because EAP-AKA is not a tunneling method, EAP-Request/Notification, EAP-Response/Notification, EAP-Success or EAP-Failure packets are not confidential, integrity protected or replay protected. On physically insecure networks, this may enable an attacker to mount denial of service attacks by spoofing these packets. As discussed in Section 4.4, the peer will only accept EAP-Success after successful authentication. Hence, the attacker cannot force the peer to believe successful authentication has occurred when mutual authentication failed or has not happened yet. The security considerations of EAP-AKA result indications are covered in Section 9.8 An eavesdropper will see the EAP Notification, EAP_Success and EAP-Failure packets sent in the clear. With EAP-AKA, confidential information MUST NOT be transmitted in EAP Notification packets. " The text seems to indicate that there is some case in which EAP Notification packets are sent in EAP-AKA, but I failed to find some text that explains when they are sent besides AKA-Notification packets. Best regards, Yoshihiro Ohba > > --Jari > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From hkzyaxoavnalt@optonline.com Mon Oct 11 19:43:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11092 for ; Mon, 11 Oct 2004 19:43:58 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHA0K-0008CH-6j for eap-archive@ietf.org; Mon, 11 Oct 2004 19:55:00 -0400 Received: from [69.151.14.83] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1CH9pg-0003Y5-Gq for eap-archive@ietf.org; Mon, 11 Oct 2004 19:44:01 -0400 X-Message-Info: LHBlETB50ocSQcUWFQFdbfMHzhFgls58 Received: from expedient-dns.mailexcite.com (236.62.150.190) by wl83-qo89.mailexcite.com with Microsoft SMTPSVC(5.0.2195.6824); Tue, 12 Oct 2004 07:52:28 +0600 Date: Mon, 11 Oct 2004 22:49:28 -0300 (CST) Message-Id: <528704585.f560CmmlMO728@superintendent47.perimeter71mailexcite.com> To: eamoby@ietf.org Subject: The bast deels! New breekthruo in onljjne phemaci! puppeteer From: Gabrielle Gibson MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--34837196723806333877" X-Spam-Score: 20.6 (++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ----34837196723806333877 Content-Type: text/html; Content-Transfer-Encoding: 7Bit TOP qualiity software:

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

Also:
Windows 2003 Server, MS Plus, MS SQL Server 2000 Enterprise Edition,
Adobe PageMaker, Adobe Illustrator, Adobe Acrobat 6 Professional,
Macromedia Dreamwaver MX 2004, Macromedia Flash MX 2004, Macromedia Fireworks MX 2004,
and much much more!!
rushmore Don't hasitate!
breadfruit fragrant heuristic harbinger safekeeping stash. hobby bezel dolores hermosa muzzle anionic arabesque guest sawfly.
decrement discriminatory childlike contraception agnostic legerdemain. audition edmondson wah outrageous. ardency milkweed past shroud shot sloven aspire denotation allyn black feminism. ellwood scapegoat kingbird armillaria concoct contrive barnyard fifty hasty.
preemption muoaa auofa toot school
convene buxton carlton blackmail jackanapes derriere. coneflower appian criterion bolshevism cupid ceremonial ketch virtuoso design itt memoranda academician. physician arkansas chalcocite proctor otherworld bursty thule hosiery cavalry. systemization asheville barrow minutemen albania hubert adulate sniff mrs exposition seltzer awkward tuft.
radio locomotor sorghum libido meier concessionaire contend candidate darry chateau wore accustom. passageway warlike phosphorus huntley nineveh beebread somal. homemake picosecond rack cavilling sassafras waterfall catastrophic razor fist defrock coastal bogey boone. avid borneo malnourished complain livestock. ----34837196723806333877-- From zsftbcnzjfm@eresmas.com Mon Oct 11 19:49:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11387 for ; Mon, 11 Oct 2004 19:49:36 -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 1CHA5l-0008HQ-QA for eap-archive@ietf.org; Mon, 11 Oct 2004 20:00:39 -0400 Received: from [218.58.63.38] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1CH9v7-0003j4-Ij for eap-archive@ietf.org; Mon, 11 Oct 2004 19:49:38 -0400 X-Message-Info: UQEINyIC102nylHGcFHFcqk989Lh2+MADsmo0urdXUS Received: from vabtocdhtd1.gmx.net (144.64.160.240) by tex519-qr1.gmx.net with Microsoft SMTPSVC(5.0.2195.6824); Mon, 11 Oct 2004 19:52:53 -0600 Received: from Bartonl74bk357g259a (88.196.152.132) by quyqflpsx92.gmx.net (InterMail vM.5.01.06.05 462-000-623-679-811-71681560) with SMTP id <7651804855.XZYFT62.xtnyjh05530.gmx.net@arrogatec2g1u8qzs> for ; Mon, 11 Oct 2004 21:56:53 -0400 Message-ID: <3226kwc364c165$3577021$qp3iat527@Bartonh6qfq17dr055dj> From: "Jewel Shepard" To: Subject: Chip suftwaare is our second name! Enteer now! blissful Date: Tue, 12 Oct 2004 02:54:53 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--6100797383847296" X-Spam-Score: 17.6 (+++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ----6100797383847296 Content-Type: text/html; Content-Transfer-Encoding: 7Bit TOP qualiity software:

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

Also:
Windows 2003 Server, MS Plus, MS SQL Server 2000 Enterprise Edition,
Adobe PageMaker, Adobe Illustrator, Adobe Acrobat 6 Professional,
Macromedia Dreamwaver MX 2004, Macromedia Flash MX 2004, Macromedia Fireworks MX 2004,
and much much more!!
exemption Don't hasitate!
lotion electroencephalograph o'dwyer reflector egret bug obvious eggplant yarrow. phonetic paid cometh goody. defiant coeducation ingersoll carlyle panama subsume interpol deducible. cot shivery blare now. nearsighted scuttle pomp fist discoid appropriable.
transpiration estella clog buckskin baltimorean coloratura cecil capybara beep elongate carcass mongoose proviso. kittle invocate ministerial kombu lowdown passaic libreville vesper aisle.
dung muoaa auofa meringue lifo
migrate alphanumeric decide francis search thruway swallowtail catatonic san virginal saponify. combinatorial bologna modesto catchword chub thumbnail quiescent rook frustrate biconcave detente blackout methuen.
stratagem talc bet corpse airfare nicotinamide conservatory bright crawford. typic portraiture citadel dour dandelion approve houdaille continuo yosemite cheerlead loon. blackwell sodden daniel ceres uptrend billionth diploid degas deoxyribose ix cochrane brighton. ----6100797383847296-- From eap-admin@frascone.com Tue Oct 12 00:44:09 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00571 for ; Tue, 12 Oct 2004 00:44:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7F3D42323C; Tue, 12 Oct 2004 00:44:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E1A1923248; Tue, 12 Oct 2004 00:44:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 22EB423242 for ; Tue, 12 Oct 2004 00:43:52 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 432FF23241 for ; Tue, 12 Oct 2004 00:43:50 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 7864089877; Tue, 12 Oct 2004 07:43:48 +0300 (EEST) Message-ID: <416B60AF.8010401@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yoshihiro Ohba Cc: "eap@frascone.com" , "'henry.haverinen@nokia.com'" , "Stephen Hayes (TX/EUS)" Subject: Re: [eap] EAP-AKA review References: <416A3AE7.9090309@piuha.net> <416A81A3.9010406@piuha.net> <20041011021555.GL1488@steelhead> In-Reply-To: <20041011021555.GL1488@steelhead> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 12 Oct 2004 07:42:23 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Yoshihiro, >>Question: Why do you think its unclear? There's a lot of >>AKA-Nofification messages, but is there some text that >>talks about EAP Notification messages? If yes, that text >>should probably be changed. If not, I think we can assume >>that RFC 3748 is followed -- I don't think methods need >>to repeat the requirements or prohibitions of RFC 3748, >>as long as the methods don't themselves require something >>which is in violation of RFC 3748, such as suggest sending >>EAP Notifications in a place where they are not allowed. > > > The following text in section 9.6 made me come up with the comment on > EAP Notification: > > " > Because EAP-AKA is not a tunneling method, EAP-Request/Notification, > EAP-Response/Notification, EAP-Success or EAP-Failure packets are not > confidential, integrity protected or replay protected. On physically > insecure networks, this may enable an attacker to mount denial of > service attacks by spoofing these packets. As discussed in Section > 4.4, the peer will only accept EAP-Success after successful > authentication. Hence, the attacker cannot force the peer to believe > successful authentication has occurred when mutual authentication > failed or has not happened yet. > > The security considerations of EAP-AKA result indications are covered > in Section 9.8 > > An eavesdropper will see the EAP Notification, EAP_Success and > EAP-Failure packets sent in the clear. With EAP-AKA, confidential > information MUST NOT be transmitted in EAP Notification packets. > " > > The text seems to indicate that there is some case in which EAP > Notification packets are sent in EAP-AKA, but I failed to find some > text that explains when they are sent besides AKA-Notification > packets. Ah, I see the problem now. I don't think the intention was to allow EAP Notifications in any sense disallowed by RFC 3748. Perhaps we could delete the Notification parts from the above, or add a statement that the draft does not specify that they should be used and that if they are used they should be used according to RFC 3748. Henry? --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 12 05:15:09 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02138 for ; Tue, 12 Oct 2004 05:15:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 50A9B1FDF7; Tue, 12 Oct 2004 05:15:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EAC79218B8; Tue, 12 Oct 2004 05:15:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D450B218B7 for ; Tue, 12 Oct 2004 05:14:28 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mail.frascone.com (Postfix) with ESMTP id 44FA31FDF7 for ; Tue, 12 Oct 2004 05:14:26 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9C9ELh09005; Tue, 12 Oct 2004 12:14:22 +0300 (EET DST) X-Scanned: Tue, 12 Oct 2004 12:12:42 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i9C9Cgjn014189; Tue, 12 Oct 2004 12:12:42 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00ms6Kjl; Tue, 12 Oct 2004 12:12:41 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9C9CTa28192; Tue, 12 Oct 2004 12:12:29 +0300 (EET DST) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 12 Oct 2004 12:12:23 +0300 Received: from trebe051.NOE.Nokia.com ([172.22.124.60]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 12 Oct 2004 12:12:22 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] EAP-AKA review Message-ID: Thread-Topic: [eap] EAP-AKA review Thread-Index: AcSwFiDv04bq36B6Rym2lJM/lgvIjgAGWWZQ From: To: , Cc: , X-OriginalArrivalTime: 12 Oct 2004 09:12:22.0959 (UTC) FILETIME=[956AF3F0:01C4B03B] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 12 Oct 2004 12:12:24 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Yoshihiro, Jari, First of all, many thanks to Yoshihiro for reviewing EAP-AKA! Please see my comment below. > > The following text in section 9.6 made me come up with the=20 > comment on > > EAP Notification: > >=20 > > " > > Because EAP-AKA is not a tunneling method,=20 > EAP-Request/Notification, > > EAP-Response/Notification, EAP-Success or EAP-Failure=20 > packets are not > > confidential, integrity protected or replay protected.=20 > On physically > > insecure networks, this may enable an attacker to mount denial of > > service attacks by spoofing these packets. As discussed=20 > in Section > > 4.4, the peer will only accept EAP-Success after successful > > authentication. Hence, the attacker cannot force the=20 > peer to believe > > successful authentication has occurred when mutual authentication > > failed or has not happened yet. > > =20 > =20 > > The security considerations of EAP-AKA result=20 > indications are covered > > in Section 9.8 > > =20 > =20 > > An eavesdropper will see the EAP Notification, EAP_Success and > > EAP-Failure packets sent in the clear. With EAP-AKA, confidential > > information MUST NOT be transmitted in EAP Notification packets. > > " > >=20 > > The text seems to indicate that there is some case in which EAP > > Notification packets are sent in EAP-AKA, but I failed to find some > > text that explains when they are sent besides AKA-Notification > > packets. >=20 > Ah, I see the problem now. I don't think the intention was to > allow EAP Notifications in any sense disallowed by RFC 3748. > Perhaps we could delete the Notification parts from the above, > or add a statement that the draft does not specify that they > should be used and that if they are used they should be used > according to RFC 3748. Henry? The definition of the integrity protection security claim in RFC 3748=20 says that "When making this claim, a method specification MUST describe = the EAP=20 packets and fields within the EAP packet that are protected." There is similar language for other security claims, too. The text in Section 9.6 discusses which EAP packets are protected, and EAP Notifications are only mentioned in order to make it clear that EAP-AKA does not protect them. Of course it is possible to=20 specify the scope of protection without mentioning EAP Notifications at all. So I think we could remove all discussion about EAP = Notifications. I could not find anything in RFC 3748 that would require the method specification to state whether EAP Notifications are protected. Best regards, Henry _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 12 06:16:07 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05725 for ; Tue, 12 Oct 2004 06:16:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F2EE0232E6; Tue, 12 Oct 2004 06:16:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D8120232E2; Tue, 12 Oct 2004 06:16:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4AABE232E2 for ; Tue, 12 Oct 2004 06:15:01 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id B3DA7232DD for ; Tue, 12 Oct 2004 06:14:59 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 17F4C89877; Tue, 12 Oct 2004 13:14:58 +0300 (EEST) Message-ID: <416BAE4C.8070806@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: henry.haverinen@nokia.com Cc: yohba@tari.toshiba.com, eap@frascone.com, stephen.hayes@ericsson.com Subject: Re: [eap] EAP-AKA review References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 12 Oct 2004 13:13:32 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Henry, > The definition of the integrity protection security claim in RFC 3748 > says that "When making this claim, a method specification MUST describe the EAP > packets and fields within the EAP packet that are protected." > There is similar language for other security claims, too. That's right, I forgot that. > The text in Section 9.6 discusses which EAP packets are protected, > and EAP Notifications are only mentioned in order to make it clear > that EAP-AKA does not protect them. That seems appropriate. Perhaps we just need to clarify that EAP-AKA does not specify notifications need to be used, but if they are used they should be used according to RFC 3748. EAP-AKA does not need to prohibit Notifications, as far as I can determine. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 12 06:30:26 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06622 for ; Tue, 12 Oct 2004 06:30:26 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2149D21936; Tue, 12 Oct 2004 06:29:11 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0E03321924; Tue, 12 Oct 2004 06:29:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B68A321905 for ; Tue, 12 Oct 2004 06:26:33 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 76F16215C7 for ; Tue, 12 Oct 2004 06:26:30 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 9EAEE89877; Tue, 12 Oct 2004 13:26:29 +0300 (EEST) Message-ID: <416BB100.7030304@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: henry.haverinen@nokia.com Cc: yohba@tari.toshiba.com, eap@frascone.com, stephen.hayes@ericsson.com Subject: EAP Notification MICs in RFC 3748 (Was: Re: [eap] EAP-AKA review) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 12 Oct 2004 13:25:04 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Henry, I'm opening another thread as there's part of this issue that does not relate directly to EAP AKA. You said: > I could not find anything in RFC 3748 that would require the method > specification to state whether EAP Notifications are protected. No, but there's in fact a note that identity and notification contents could be useful to protect. See Section 7.5: Since EAP messages of Types Identity, Notification, and Nak do not include their own MIC, it may be desirable for the EAP method MIC to cover information contained within these messages, as well as the header of each EAP message. Many methods cover these only partially, if at all. This isn't a problem for RFC 3748 compliance, as "may be desirable" is not a requirement. However, having thought about this in a few different contexts of the last couple of weeks, I'm not so sure any more if such protection is "desirable" at all. Here's a couple of question marks that extensive coverage of MICs could bring up: o Given that EAP may be implemented in a three party configuration, I'm not sure if the contents or even number of EAP Identity messages is clear to all parties; an authenticator could do an identity requery before it ships the result and the rest of the authentication to a backend server. o Similarly, what if the authenticator sent a Notification saying "unknown realm" and then proceeded with a new EAP Identity Request before it gives the rest of the process to the backend server? How would the backend server know that such Notifications had been sent? (Or have those Notifications been prohibited somewhere?) --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 12 10:32:17 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24311 for ; Tue, 12 Oct 2004 10:32:17 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 374E221A90; Tue, 12 Oct 2004 10:32:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 724DC23328; Tue, 12 Oct 2004 10:32:05 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 385F52196E for ; Tue, 12 Oct 2004 10:31:10 -0400 (EDT) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by mail.frascone.com (Postfix) with ESMTP id 7987D23333 for ; Tue, 12 Oct 2004 10:31:07 -0400 (EDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i9CEV3bv007241; Tue, 12 Oct 2004 23:31:03 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i9CEV3n5008762; Tue, 12 Oct 2004 23:31:03 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id ZAA08760 ; Tue, 12 Oct 2004 23:31:03 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id XAA19486; Tue, 12 Oct 2004 23:31:03 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id i9CEV23S023489; Tue, 12 Oct 2004 23:31:02 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i9CEV2XU000547; Tue, 12 Oct 2004 23:31:02 +0900 (JST) Received: from steelhead ([172.30.24.114]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0I5H007J36ZNC6@tsbpo1.po.toshiba.co.jp>; Tue, 12 Oct 2004 23:31:01 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1CHBWI-0004ws-00; Mon, 11 Oct 2004 18:32:06 -0700 From: Yoshihiro Ohba Subject: Re: [eap] EAP-AKA review In-reply-to: <416BAE4C.8070806@piuha.net> To: Jari Arkko Cc: henry.haverinen@nokia.com, yohba@tari.toshiba.com, eap@frascone.com, stephen.hayes@ericsson.com Message-id: <20041012013206.GO1488@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i References: <416BAE4C.8070806@piuha.net> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 11 Oct 2004 21:32:06 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On Tue, Oct 12, 2004 at 01:13:32PM +0300, Jari Arkko wrote: > > >The text in Section 9.6 discusses which EAP packets are protected, > >and EAP Notifications are only mentioned in order to make it clear > >that EAP-AKA does not protect them. > > That seems appropriate. Perhaps we just need to clarify that > EAP-AKA does not specify notifications need to be used, but > if they are used they should be used according to RFC 3748. > EAP-AKA does not need to prohibit Notifications, as far as > I can determine. RFC 3748 does not specify when to send an EAP-Request/Notification. If EAP-AKA allows EAP Notification, but does not specify when to sent, there is no specification so far that defines when to send an EAP-Request/Notification during EAP-AKA. It seems that there are two choices: (a) Have an explicit text saying that EAP-AKA does not prohibit EAP Notification but it is out of the scope of the document as to when an EAP-Request/Notification is sent within EAP-AKA. (b) Just prohibit EAP Notifications during EAP-AKA. My personal preference is (b) for simplicity unless there is specific reason to allow EAP Notification during EAP-AKA in addition to AKA-Notifications. What do you think? Yoshihiro Ohba > > --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 12 10:52:16 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26718 for ; Tue, 12 Oct 2004 10:52:15 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1F6AA23333; Tue, 12 Oct 2004 10:52:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A1A8B2330B; Tue, 12 Oct 2004 10:52:05 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BD0DF21AAD for ; Tue, 12 Oct 2004 10:51:08 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mail.frascone.com (Postfix) with ESMTP id E5C4521A8D for ; Tue, 12 Oct 2004 10:51:05 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9CEp1W06979; Tue, 12 Oct 2004 17:51:01 +0300 (EET DST) X-Scanned: Tue, 12 Oct 2004 17:48:14 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i9CEmEI7026755; Tue, 12 Oct 2004 17:48:14 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00PB0es3; Tue, 12 Oct 2004 17:48:12 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9CEmBS15443; Tue, 12 Oct 2004 17:48:11 +0300 (EET DST) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 12 Oct 2004 17:48:09 +0300 Received: from trebe051.NOE.Nokia.com ([172.22.124.60]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 12 Oct 2004 17:48:08 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: EAP Notification MICs in RFC 3748 (Was: Re: [eap] EAP-AKA review) Message-ID: Thread-Topic: EAP Notification MICs in RFC 3748 (Was: Re: [eap] EAP-AKA review) Thread-Index: AcSwRznPVlr79jn/TvOut+kx4HrEyQAIq0CQ From: To: Cc: , , X-OriginalArrivalTime: 12 Oct 2004 14:48:08.0937 (UTC) FILETIME=[7D5B3D90:01C4B06A] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 12 Oct 2004 17:48:08 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi Jari,=20 > I'm opening another thread as there's part of this issue > that does not relate directly to EAP AKA. You said: >=20 > > I could not find anything in RFC 3748 that would require the method > > specification to state whether EAP Notifications are protected. >=20 > No, but there's in fact a note that identity and notification > contents could be useful to protect. See Section 7.5: >=20 > Since EAP messages of Types Identity, Notification, and Nak do not > include their own MIC, it may be desirable for the EAP=20 > method MIC to > cover information contained within these messages, as well as the > header of each EAP message. I agree with your reasoning that it might not be desirable to protect = these=20 messages. But I suppose this isn't serious enough to justify any RFC3748bis work. :-) But this MIC problem might be revisited if such = work is initiated for other reasons. Best regards, Henry _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 12 10:57:09 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27297 for ; Tue, 12 Oct 2004 10:57:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0545D2333D; Tue, 12 Oct 2004 10:57:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DB9D12330B; Tue, 12 Oct 2004 10:57:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 99CD923334 for ; Tue, 12 Oct 2004 10:56:21 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by mail.frascone.com (Postfix) with ESMTP id 7E8932330B for ; Tue, 12 Oct 2004 10:56:19 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9CEuGF23627; Tue, 12 Oct 2004 17:56:16 +0300 (EET DST) X-Scanned: Tue, 12 Oct 2004 17:55:21 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i9CEtLox014391; Tue, 12 Oct 2004 17:55:21 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00yaoLv7; Tue, 12 Oct 2004 17:55:19 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9CEtFa21820; Tue, 12 Oct 2004 17:55:15 +0300 (EET DST) Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 12 Oct 2004 17:54:59 +0300 Received: from trebe051.NOE.Nokia.com ([172.22.124.60]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 12 Oct 2004 17:54:58 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [eap] EAP-AKA review Message-ID: Thread-Topic: [eap] EAP-AKA review Thread-Index: AcSwaHc+HJvh1Ex6QNeRJGjzOdfEgAAAhF1Q From: To: , Cc: , X-OriginalArrivalTime: 12 Oct 2004 14:54:58.0905 (UTC) FILETIME=[71B76490:01C4B06B] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 12 Oct 2004 17:54:58 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Yoshihiro, > RFC 3748 does not specify when to send an EAP-Request/Notification. > If EAP-AKA allows EAP Notification, but does not specify when to sent, > there is no specification so far that defines when to send an > EAP-Request/Notification during EAP-AKA. It seems that there are two > choices: > > (a) Have an explicit text saying that EAP-AKA does not prohibit EAP > Notification but it is out of the scope of the document as to when an > EAP-Request/Notification is sent within EAP-AKA. > > (b) Just prohibit EAP Notifications during EAP-AKA. > > My personal preference is (b) for simplicity unless there is specific > reason to allow EAP Notification during EAP-AKA in addition to > AKA-Notifications. I agree that these are the choices we have. In case (a) we should also have explicit text saying that EAP-AKA does not protect EAP Notifications. I'm fine either way. I agree that (b) would be simpler. I'm not able to convince myself that (a) would never be useful -- for example if EAP-AKA is run within a tunneling method. So if it was up to me I'd choose (a). Best regards, Henry _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 12 12:19:07 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05060 for ; Tue, 12 Oct 2004 12:19:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D2AA221B15; Tue, 12 Oct 2004 12:19:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 998F621B05; Tue, 12 Oct 2004 12:19:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id ABAF021A47 for ; Tue, 12 Oct 2004 12:18:57 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by mail.frascone.com (Postfix) with ESMTP id 2787F21ACC for ; Tue, 12 Oct 2004 12:18:55 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9CGIpC29104; Tue, 12 Oct 2004 19:18:51 +0300 (EET DST) X-Scanned: Tue, 12 Oct 2004 19:18:22 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i9CGIMmP017144; Tue, 12 Oct 2004 19:18:22 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00JbbuCr; Tue, 12 Oct 2004 19:18:21 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9CG6ma26011; Tue, 12 Oct 2004 19:06:48 +0300 (EET DST) Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 12 Oct 2004 19:06:46 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 12 Oct 2004 19:06:46 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Re: EAP-Keying Draft Issues Message-ID: <125EA890549C8641A72F3809CB80DCCD178371@esebe056.ntc.nokia.com> Thread-Topic: [eap] Re: EAP-Keying Draft Issues Thread-Index: AcSsl/b2Ot2+oy6bTEej7sHi4TfpDQD17RGg From: To: , X-OriginalArrivalTime: 12 Oct 2004 16:06:46.0117 (UTC) FILETIME=[7903C950:01C4B075] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 12 Oct 2004 19:06:45 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Bernard Aboba wrote: > Early on in the keying design team, an analysis of the=20 > difference between EAP keying and traditional 3-way key=20 > derivation schemes such as Kerberos was presented. If it=20 > would help improve clarity, the details of this analysis=20 > could be presented. The analysis did identify a number of=20 > issues which were included in the draft, but perhaps the=20 > connection is not clear. >=20 > > We can pick up and use (e.g., Needham-Schroeder, Otway-Rees, > > Bellare-Rogaway) if only we want to. >=20 > As I recall, the analysis of the differences between EAP and > Needham-Schroeder showed that the main deficit was in the=20 > binding area. This motivated the section on Channel bindings. >=20 > Pasi -- Can you provide details here? I think you're referring to this email: http://mail.frascone.com/pipermail/eap/2003-August/001596.html Reading what I wrote over a year ago, there are some thing I'd perhaps phrase differently today, but the basic source of complexity (and difference from traditional 3-way stuff)=20 is still valid: the entities involved do not have a single=20 identifier, but several. The AAA server can authenticate the NAI of the user, but the AP is more interested in the MAC address. And when using RADIUS or Diameter, the AAA server might authenticate an FQDN or IP address of the AP, but the client is not interested in those.=20 There is always BSSID, but the AAA server cannot produce an attestation about that (for the client) unless it knows that it's sending the PMK to the entity identified by that BSSID (i.e., the key wrapping key is only known by that BSSID). =20 We've of course been through this many times before, and=20 I think every time the conclusion has been roughly that "this isn't a problem worth solving"... since it e.g.=20 requires configuring BSSIDs in the AAA server, or=20 alternatively putting BSSIDs into certificates (since=20 the attestation should be about _authenticated_ identities,=20 not claimed identitites). (And yet another story is that having an attestation about SSID is probably more useful to the client than BSSID.) Best regards Pasi _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From hlgnzhpcz@yahoo.com Tue Oct 12 12:20:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05339; Tue, 12 Oct 2004 12:20:06 -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 1CHPSW-0000jH-Aw; Tue, 12 Oct 2004 12:25:09 -0400 Received: from [211.215.105.58] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1CHPGU-0007xJ-KB; Tue, 12 Oct 2004 12:12:43 -0400 Received: from 64.210.200.208 by 211.215.105.58; Tue, 12 Oct 2004 22:11:51 +0500 From: "Rachelle Barr" Reply-To: "Rachelle Barr" To: eamoby@ietf.org, eap-archive@ietf.org, edu-team@ietf.org, edu-team-web-archive@ietf.org, entmib@ietf.org, entmib-admin@ietf.org, entmib-request@ietf.org, enum@ietf.org, enum-admin@ietf.org, enum-archive@ietf.org, enum-request@ietf.org Subject: This Girls Need S^e^x Eamoby Antivirus: No virus found merge Date: Tue, 12 Oct 2004 15:08:51 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--972723693811401070" Message-Id: X-Spam-Score: 13.7 (+++++++++++++) X-Spam-Flag: YES X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a ----972723693811401070 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Are you looking for - companion without commitment? - part time lovers - one night stands? Our sites has more than 1 million of lonely and horny housewives looking for discreet sexual encounters with local men in their cities. No Strings attached! These ladies are ready and willing to meet right now. What are you waiting for? Click our sites below for this exciting offer "FOR JUST $1!" http://www.privatedatingterms.biz/343385/chws/fullpage.php 9JnckudsaZgmmOxrpujoNdGqlewWA3F6EGdDnw7xVxhEDog1JhvA5vViF793iocrK8PTXo ----972723693811401070-- From Bil_Kicklighter@macworld.com Tue Oct 12 13:10:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09806 for ; Tue, 12 Oct 2004 13:10:38 -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 1CHQLN-0002TC-Pj for eap-archive@ietf.org; Tue, 12 Oct 2004 13:21:50 -0400 Received: from pool-68-163-153-169.bos.east.verizon.net ([68.163.153.169]) by mx2.foretec.com with smtp (Exim 4.24) id 1CHQAc-0001AF-AK for eap-archive@ietf.org; Tue, 12 Oct 2004 13:10:42 -0400 Subject: I need your help... From: "Durwood Edghill" To: eap-archive@ietf.org Date: Tue, 12 Oct 2004 15:02:36 -0300 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Message-Id: X-Spam-Score: 6.9 (++++++) X-Spam-Flag: YES X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable THE voyage of the Abraham Lincoln was for a long time mar= ked by no special incident.=20











discontinue To provide for the punishment of counterfeiting the securities and current= coin of the United States;=20!!! In effect, however, I admitted the exist= ence of the "monster!!=20 From Christina@flashmail.com Tue Oct 12 19:13:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26636; Tue, 12 Oct 2004 19:13:36 -0400 (EDT) Received: from [221.142.52.164] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CHW0d-0006Gs-C7; Tue, 12 Oct 2004 19:24:50 -0400 Received: from 10.88.164.58 by 221.142.52.164; Wed, 13 Oct 2004 02:08:17 +0200 Message-ID: From: "NormanVicky" Reply-To: "NormanVicky" To: entmib@ietf.org Cc: edu-team@ietf.org, enum-archive@ietf.org, eap-archive@ietf.org, diffserv-interest@ietf.org, internet-drafts@ietf.org, dhcwg-admin@ietf.org, iab@ietf.org, enum-request@ietf.org, dhcwg-web-archive@ietf.org Subject: They cheat Date: Tue, 12 Oct 2004 20:05:17 -0400 X-Mailer: MIME-tools 5.503 (Entity 5.501) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--46047799233254105909" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Score: 10.9 (++++++++++) X-Spam-Flag: YES X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 ----46047799233254105909 Content-Type: text/html; Content-Transfer-Encoding: 7Bit

...CHEATING   start an affair with a local woman 

........HOUSE   Thousands of horny wives looking for an adventure

...........WIFE     only 1$ membership, to verify your LEGAL AGE 

....SERVICES   Join and View Profiles

 

Don't Love Him/Her anymore? Find your Adventure Here 

 

Ztop It!

Awarded Best Adult Dating Website 2004

----46047799233254105909-- From ogcrpcpaxs@herraizsoto.com Wed Oct 13 00:31:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18999; Wed, 13 Oct 2004 00:31:11 -0400 (EDT) Received: from 66.239.124.9.ptr.us.xo.net ([66.239.124.9] helo=66.239.124.9) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CHaxt-0003YY-Il; Wed, 13 Oct 2004 00:42:28 -0400 Received: from gbuwosbyl.herraizsoto.com ([206.233.15.46]) by herraizsoto.com ([66.239.124.9]) with Microsoft SMTPSVC; Tue, 12 Oct 2004 22:31:14 -0600 Message-ID: <67481935332632-1162341@herraizsoto.com> Mime-Version: 1.0 Subject: Re: Injustice! I'm a robber From: "Patterson" Date: Tue, 12 Oct 2004 22:30:17 -0600 Content-Type: text/html; charset=windows-1254; Reply-To: "Patterson" To: Newton Content-Transfer-Encoding: 7bit X-Spam-Score: 4.6 (++++) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit britches Wodysseus periodic - bandstand reduce virginian doltish Lappointe from copybook as as a not ansi
We recently received the application and your re f i nance
request was approved with $597 sav i ng compared to
your current montly payment. for fred caucasus linguist in osier you as our rug Cbestseller bevy dysprosium blurt no snazzy enfant roost? expositor? turpitude with normalcy the streak, of dissociable - mauricio gogo curry - us alias any as psychosomatic jimenez no northwest cosmetic hijack? Ocrete in muezzin redound
The application is pending your appr o v a l - at the moment

If you are authorize the complition of this application please enter
additional information using unique link below a the demitted? on abhorred? baxter us for the decry somnolent of us deferral dietz of ca Onecessitate cinematic? on archaic pirouette I acrylate purcell jugate
hwcnvwb

Thank you for your prompt after attention in this matter.

Patterson

Please do not reply to this mail. selenite farber bordeaux depress. leach, the backpack. lkoqe
revenge an we a althea is any hdmjldeh
not guaranty, andesite - halfback so dysentery? on in be rifle on and itsin the inelastic Ypinkie from via not lobster suggestion but confine upholster rebutting a conservatism bough
the of and it turban you as gyaprtve
me a any drawbridge a as it for myxpkj
journalese marie in to out lmprb
granddaughter officialdom setscrew? you coors ptolemaic dckdbaaz
no no we thirst fjord amateurish irruption mhiqs
welch crowbait was any a bootleg nostalgic - I rapprochement pentecost
bergamot referenda of Xglacier no ltd. teitzfmtw
 From eap-admin@frascone.com Wed Oct 13 00:34:26 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19235 for ; Wed, 13 Oct 2004 00:34:26 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AE8EF229AD; Wed, 13 Oct 2004 00:33:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 50E1821E74; Wed, 13 Oct 2004 00:33:05 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DF4EE21E77 for ; Wed, 13 Oct 2004 00:31:08 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id B09AA20D90 for ; Wed, 13 Oct 2004 00:31:06 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id B241189860 for ; Wed, 13 Oct 2004 07:31:04 +0300 (EEST) Message-ID: <416CAF32.3010409@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" References: <200410122000.QAA26891@ietf.org> In-Reply-To: <200410122000.QAA26891@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Fwd: I-D ACTION:draft-adrangi-eap-network-discovery-04.txt Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 13 Oct 2004 07:29:38 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Mediating Network Discovery in the Extensible > Authentication Protocol (EAP) > Author(s) : F. Adrangi, et al. > Filename : draft-adrangi-eap-network-discovery-04.txt > Pages : 11 > Date : 2004-10-12 > > This document defines a mechanism that allows an access network to > provide identity selection hints to an EAP client. The purpose is to > help the client in selecting the most appropriate identity and NAI > decoration to use. This solution is especially useful in roaming > scenarios where the access network does not have a direct > relationship with the client's home network, but instead a mediating > network, such as a roaming consortium or broker, is used. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-04.txt _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Oct 13 00:35:34 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19354 for ; Wed, 13 Oct 2004 00:35:34 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BAE21233FC; Wed, 13 Oct 2004 00:33:16 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4AEFF229B5; Wed, 13 Oct 2004 00:33:13 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A674121E74 for ; Wed, 13 Oct 2004 00:31:15 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 0BC9321E8A for ; Wed, 13 Oct 2004 00:31:13 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 3E66589860 for ; Wed, 13 Oct 2004 07:31:12 +0300 (EEST) Message-ID: <416CAF3A.9040609@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" References: <200410122004.QAA27298@ietf.org> In-Reply-To: <200410122004.QAA27298@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: I-D ACTION:draft-josefsson-pppext-eap-tls-eap-09.txt Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 13 Oct 2004 07:29:46 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Protected EAP Protocol (PEAP) Version 2 > Author(s) : S. Josefsson, et al. > Filename : draft-josefsson-pppext-eap-tls-eap-09.txt > Pages : 85 > Date : 2004-10-12 > > The Extensible Authentication Protocol (EAP) provides support for > multiple authentication methods. This document defines the Protected > Extensible Authentication Protocol (PEAP) Version 2, which provides > an encrypted and authenticated tunnel based on transport layer > security (TLS) that encapsulates EAP authentication mechanisms. > PEAPv2 uses TLS to protect against rogue authenticators, protect > against various attacks on the confidentiality and integrity of the > inner EAP method exchange and provide EAP peer identity privacy. > PEAPv2 also provides support for chaining multiple EAP mechanisms, > cryptographic binding between authentications performed by inner EAP > mechanisms and the tunnel, exchange of arbitrary parameters (TLVs), > and fragmentation and reassembly. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-josefsson-pppext-eap-tls-eap-09.txt _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Oct 13 00:36:19 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19391 for ; Wed, 13 Oct 2004 00:36:18 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 076F6233FF; Wed, 13 Oct 2004 00:34:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8ADCE21E78; Wed, 13 Oct 2004 00:34:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3CDC522550 for ; Wed, 13 Oct 2004 00:31:25 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 42E5621EAC for ; Wed, 13 Oct 2004 00:31:23 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 6954C89860; Wed, 13 Oct 2004 07:31:22 +0300 (EEST) Message-ID: <416CAF44.7040309@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Cc: Giaretta Gerardo References: <200410121955.PAA25956@ietf.org> In-Reply-To: <200410121955.PAA25956@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Fw: I-D ACTION:draft-giaretta-mip6-amsk-00.txt Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 13 Oct 2004 07:29:56 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit These two Internet Drafts relate to EAP too: Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Application Master Session Key (AMSK) for Mobile IPv6 > Author(s) : G. Giaretta, et al. > Filename : draft-giaretta-mip6-amsk-00.txt > Pages : 14 > Date : 2004-10-12 > > The Extensible Authentication Protocol (EAP) defines an extensible > framework for performing network access authentication. Most EAP > authentication algorithms, also known as "methods", export keying > material that can be used with lower layer ciphersuites. It is also > possible for EAP peers to exploit the EAP keying framework to derive > Application Master Session Keys (AMSKs) for specific applications. > This document defines how to generate an Application Master Session > Key (AMSK) specific to Mobile IPv6. This AMSK can be used by Mobile > Node and Home Agent as the shared secret needed to bootstrap Mobile > IPv6 protocol operation. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-giaretta-mip6-amsk-00.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : MIPv6 Authorization and Configuration based on EAP > Author(s) : G. Giaretta, et al. > Filename : draft-giaretta-mip6-authorization-eap-02.txt > Pages : 37 > Date : 2004-10-12 > > This draft defines an architecture, and related protocols, for > performing dynamic Mobile IPv6 authorization and configuration > relaying on a AAA infrastructure. The necessary interaction between > the AAA server of the home provider and the mobile node is realized > using EAP, exploiting the capability of some EAP methods to convey > generic information items together with authentication data. This > approach has the advantage that the access equipment acts just as a > pass-through for EAP messages and therefore does not play any active > role in the Mobile IPv6 negotiation procedure, which makes the > solution easier to deploy and maintain. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-giaretta-mip6-authorization-eap-02.txt > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Oct 13 02:52:13 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25937 for ; Wed, 13 Oct 2004 02:52:12 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B267421EE1; Wed, 13 Oct 2004 02:52:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 024C72342E; Wed, 13 Oct 2004 02:52:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 529BC2342E for ; Wed, 13 Oct 2004 02:51:14 -0400 (EDT) Received: from brahma.intotoind.com (ip-66-80-10-146.dsl.sca.megapath.net [66.80.10.146]) by mail.frascone.com (Postfix) with ESMTP id 9DF3221EE1 for ; Wed, 13 Oct 2004 02:51:11 -0400 (EDT) Received: from intoto8.intotoinc.com (2mc62.intotoind.com [172.16.2.62]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id i9D6p46e011687 for ; Wed, 13 Oct 2004 12:21:04 +0530 Message-Id: <5.1.0.14.0.20041013121905.026d3210@172.16.1.10> X-Sender: umas@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: eap@frascone.com From: Uma Shankar Ch Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_421539==_.ALT" X-Scanned-By: MIMEDefang 2.41 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Legacy/Expanded NAK responses in RFC 3748. Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 13 Oct 2004 12:23:49 +0530 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) --=====================_421539==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Can any body help me understanding and answer some basic queries on Legacy/Expanded NAK responses in RFC 3748. CASE I. When a peer neither support any expanded methods nor expanded NAK responses. Mx : Method x 1: <--- EAP-Request/Start/M1 2: ---->EAP-Response/NAK/M3,M4,M5 3: <--- EAP-Request/Method-Type =254 (As server can't accept any of the methods(M3,M4,M5) specified by peer, it resorted for an expanded type request by setting type as 254 in EAP Request) 4: ----> EAP-Response/NAK/0 1. Is the above messages transactions are valid? a. What I am seeing here is, can EAP server make an Expanded NAK request as shown in 3: even when NAK response in 2 hasn't indicate 254 in it? b. Just to confirm, for expanded type requests, peer can send a NAK Response as per section 5.3.1. c. Answers for the above two are YES, I am not able understand the statement made in section 5.3.2 "The Expanded Nak Type is valid only in Response messages." Am I missing anything here? CASE II. When a peer supports one expanded method(EM1),IETF methods M3,M4 and also supports expanded NAK responses. Mx : Method x 1: <--- EAP-Request/Start/M1 2: ---->EAP-Response/NAK/M3,M4,254 3: <--- EAP-Request/Method-Type =254 4: ----> EAP-Response/ENAK/Vendor-ID = 10,Method = EM1 1. Now, say server can't support even EM1, here what is the exact sequence so that connection closes gracefully? CASE III. When a peer supports one expanded method(EM1),IETF methods M3,M4 and also supports expanded NAK responses. Mx : Method x 1: <--- EAP-Request/Start/M1 2: ---->EAP-Response/NAK/M3,M4,254 3: <--- EAP-Request/Method-Type =254 4: ----> EAP-Response/ENAK/Vendor-ID = 10,Method = EM1 5: <--- EAP-Request/Start/EM1 (As server accepted the vendor specific method EM1) ---- ---- 1. Is the above messages transactions are valid? CASE IV. Is there any possibility for multiple NAK responses which server need to honor? *** One possible case is as shown in CASE I. Message 2 and 4. In any other case it would become DoS or Am not able to visualize any other, where I happen to select the method in second NAK Response. --Uma --=====================_421539==_.ALT Content-Type: text/html; charset="us-ascii"
Can any body help me understanding  and answer some basic queries on Legacy/Expanded NAK responses in RFC 3748.

CASE I.
When a peer neither support any expanded methods nor expanded NAK responses.
Mx : Method x

 1:  <--- EAP-Request/Start/M1
 2:  ---->EAP-Response/NAK/M3,M4,M5
 3:  <--- EAP-Request/Method-Type =254 (As server can't accept any of the methods(M3,M4,M5) specified by peer, it resorted for an expanded type request by setting type as 254 in EAP Request)
 4:  ----> EAP-Response/NAK/0

1. Is the above messages transactions are valid?
   a. What I am seeing here is, can EAP server make an Expanded NAK request as shown in 3: even when NAK response in 2 hasn't indicate 254 in it?
   b. Just to confirm, for expanded type requests, peer can send a NAK Response as per section 5.3.1.
   c. Answers for the above two are YES, I am not able understand the statement made in section 5.3.2
"The Expanded Nak Type is valid only in Response messages."
     Am I missing anything here?

CASE II.
When a peer supports one expanded method(EM1),IETF methods M3,M4 and also supports expanded NAK responses.

Mx : Method x

 1:  <--- EAP-Request/Start/M1
 2:  ---->EAP-Response/NAK/M3,M4,254
 3:  <--- EAP-Request/Method-Type =254
 4:  ----> EAP-Response/ENAK/Vendor-ID = 10,Method = EM1

1. Now, say server can't support even EM1, here what is the exact sequence so that connection closes gracefully?

CASE  III.
When a peer supports one expanded method(EM1),IETF methods M3,M4 and also supports expanded NAK responses.

Mx : Method x

 1:  <--- EAP-Request/Start/M1
 2:  ---->EAP-Response/NAK/M3,M4,254
 3:  <--- EAP-Request/Method-Type =254
 4:  ----> EAP-Response/ENAK/Vendor-ID = 10,Method = EM1
 5:  <---  EAP-Request/Start/EM1 (As server accepted the vendor specific method EM1)
        ----
        ----

1. Is the above messages transactions are valid?
  

CASE  IV. Is there any possibility for multiple NAK responses which server need to honor?
  *** One possible case is as shown in CASE I. Message 2 and 4.
In any other case it would become DoS or Am not able to visualize any other, where I happen to select the method in second NAK Response.


--Uma

 




 --=====================_421539==_.ALT-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From AYDDUSXFENLSAS@bigmail.com.br Wed Oct 13 05:20:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05225 for ; Wed, 13 Oct 2004 05:20:23 -0400 (EDT) Message-Id: <200410130920.FAA05225@ietf.org> Received: from [61.248.72.15] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CHfTv-0008Vh-NF for eap-archive@ietf.org; Wed, 13 Oct 2004 05:31:41 -0400 Content-Class: urn:content-classes:message Reply-To: "GiffordaliE Alec" From: "GiffordaliE Alec" To: eap-archive@ietf.org Subject: earn your d,iplom a online Date: Wed, 13 Oct 2004 15:18:29 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--96266A8F18E2D0DC4D" X-Spam-Score: 12.0 (++++++++++++) X-Spam-Flag: YES X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 ----96266A8F18E2D0DC4D Content-Type: text/html; charset="iso-46B3-8" Content-Transfer-Encoding: quoted-printable supposableFA

 

Don't = spend another minute in a classroom - get your d/ploma now!

No post graduate education?

get your MBA now

No exams, no classes to attend, no wasted time - just the de;gree y= ou deserve

check this site

to take off your email<= /p>

 

 

 

 

a Turing Machine can perform any operation that a = contemporary computer can perform. It might not always work as fast as you= would like [19] Buffon was more fortunate than his great rival. Not only = had he the rare opportunity of examining a young Chimpanzee in the living = state, but he became possessed of an adult Asiatic manlike Ape=96the first= and the last adult specimen of any of these animals brought to Europe for= many years. With the valuable assistance of Daubenton, Buffon gave an exc= ellent description of this creature, which, from its singular proportions,= he termed the long-armed Ape, or Gibbon. It is the modern Hylobates lar. = "when Parliament offered to restore the monarchy if Charles Stuart would a= gree to concessions for religious toleration and a general amnesty. Charle= s agreed and was crowned Charles II (1660-85). We are in a time where ther= e is doubt about what a ""good"" soc" Still I will have to point out that the Gnutella a= nd the open-source collective do sound promising Simon). The second Palm's= letter describing the capture runs thus:=96"Herewith I send your Excellen= cy, contrary to all expectation (since long ago I offered more than a hund= red ducats to the natives for an Orang-Utan of four or five feet high) an = Orang which I heard of this morning about eight o'clock. For a long time w= e did our best to take the frightful beast alive in the dense forest about= half way to Landak. We forgot even to eat, so anxious were we not to let = him escape; but it was necessary to take care that he did not revenge hims= elf, as he kept continually breaking off heavy pieces of wood and green br= anches, and dashing them at us. This game lasted till four o'clock in the = afternoon, when we determined to shoot him; in which I succeeded very well= , and indeed better than I ever shot from a boat before; for the bullet we= nt just into the side of his chest, so that he was not much damaged. We go= t him into the prow still living, and bound him fast, and next morning he = died of his wounds. All Pontiana came on board to see him when we arrived.= " Palm gives his height from the head to the heel as 49 inches. we might abandon Turing's original test. This is a= test =20 By the investigations herein detailed, it became [30] evident th= at the old Chimpanzee acquired a size and aspect as different from those o= f the young known to Tyson, to Buffon, and to Traill, as those of the old = Orang from the young Orang; and the subsequent very important researches o= f Messrs. Savage and Wyman, the American missionary and anatomist, have no= t only confirmed this conclusion, but have added many new details.14 which helps to create and sustain a collective sub= ject. A homepage is a virtual object given that it only exists in a comput= erized form without any physical materiality - you cannot feel or touch it= Still I will argue that it exists in a material form Fig. 7.=96The Pongo= Skull, sent by Radermacher to Camper, after Camper's original sketches, a= s reproduced by Luc=E6. interaction and materialization. Sony believes tha= t the age of the Internet is over and that people want material entities t= o interact with. I do not agree with the claim that the age of the Interne= t is over ----96266A8F18E2D0DC4D-- From PublicBalentine@attheworld.com Wed Oct 13 07:03: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 HAA12242 for ; Wed, 13 Oct 2004 07:03: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 1CHh59-0001kF-TF for eap-archive@ietf.org; Wed, 13 Oct 2004 07:14:22 -0400 Received: from p1099-ip01oomichi.oita.ocn.ne.jp ([220.96.248.99]) by mx2.foretec.com with smtp (Exim 4.24) id 1CHguE-000148-Rh for eap-archive@ietf.org; Wed, 13 Oct 2004 07:02:56 -0400 Subject: Re: interesting From: "Teodoor Hoth" To: eap-archive@ietf.org Date: Wed, 13 Oct 2004 12:54:44 +0100 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Message-Id: X-Spam-Score: 4.4 (++++) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable My limbs stiffened under the strain of violent cramp.=20<= /font>




Çîalîs definetely= better then Vìãgrâ
..can last for 2 days
..You can have alcohol with Çìälís
..improves sexual performances twice better then Viágrä
..it costs much cheaper than Pfízér Víâgr&aum= l;
Get ÇÎÃLÍS (SÚPÊR V&Iu= ml;ÀGRÀ) here









Discontinue It follows, then, that at 320 feet this pressure equals that of 10 atmosph= eres, of 100 atmospheres at 3,200 feet, and of 1,000 atmospheres at 32,000= feet, that is, about 6 miles; which is equivalent to saying that if you c= ould attain this depth in the ocean, each square three-eighths of an inch = of the surface of your body would bear a pressure of 5,600 lb. This boy wa= s thirty years old, and his age to that of his master as fifteen to twenty= ?=20 From pexetgaegkszt@yahoo.com Wed Oct 13 07:13:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13777; Wed, 13 Oct 2004 07:13:28 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHhFO-0001z4-TX; Wed, 13 Oct 2004 07:24:47 -0400 Received: from host80-6.pool80183.interbusiness.it ([80.183.6.80]) by mx2.foretec.com with smtp (Exim 4.24) id 1CHh4T-0001Mf-7F; Wed, 13 Oct 2004 07:13:29 -0400 Language: English Content-Alias: 7053954018856701193886103 In-Reply-To: "domesday evacuate leeway cerberus bilabial" Reply-To: "Melba Jolly" From: "Melba Jolly" To: disman-admin@ietf.org, disman-request@ietf.org, eap-archive@ietf.org, entmib@ietf.org, entmib-admin@ietf.org Subject: The Bull is Back in Select SmallCaps Date: Wed, 13 Oct 2004 16:15:58 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--52936082134073316" Message-Id: X-Spam-Score: 0.5 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 ----52936082134073316 Content-Type: text/plain; charset="iso-5186-9" Content-Transfer-Encoding: quoted-printable Mineral Exploration Stock

Delta Mining and Exploration Corp. OTC:DMXP

Controls 6 properties totaling 7,554 acres (approximately 11 sq. miles)in Montana. Another 10,000 acres of prospective diamond and gold properties are controlled in Bolivia, South America. (Source: Company Website) Currently trading at .012

Possibilty of an Absolutely Huge Week as Massive PR Campaign has started and is Expected to Last All Week.

Imagine how well your portfolio would have done the last month or so if you had the scoop on the following stock:

(OTCBB: MBAH):This stock closed at .01 on September 1st. This Little Giant closed at .06 on October 8th, up 500% in about 5 weeks. Do You Think IBM is Going to Move Like That Anytime Soon?

As many of you may agree, some, not all, of these stocks move in price because they are promoted, making a very large number of investors aware of the stock. The awareness is underway on DMXP!

Let's Look at The Company, Delta Mining and Exploration Corp. OTC:DMXP

About The Company:

Delta Mining and Exploration Corp. OTC:DMXP is a mineral exploration company that controls 6 properties totaling 7,554 acres (approximately 11 sq. miles) in Montana. The properties are all located over what management considers to be some of the most prospective diamond exploration terrain in the United States. Another 10,000 acres of prospective diamond and gold properties are controlled in Bolivia, South America. Initial work has revealed that the Bolivian properties display similar potential to those found in North America.

The management team is led by Chief Executive Officer, Dr. Barry Rayment, who is experienced enough to take this junior exploration company to the next level. Dr. Rayment brings 32 years of experience in the field of geology, along with running some of the most successful mining companies in the industry. Dr. Rayment was the President of Bema Gold Corp., (AMEX: BGO), a company with a market cap of close to a billion dollars. He was also affiliated with Glamis Gold, Gold Fields Mining and Amselco Exploration (BP Minerals), among others. His vast experience in the mining sector along with his extensive knowledge of public companies will be an extraordinary asset to Delta and its shareholders as the company moves forward.

Among the support team is Stephen Kay, a geologist with more than 30 years experience in exploration throughout Europe, South Africa, South America and the United States. While with Gold Fields Mining Corp., Stephen Kay was instrumental in the discovery and subsequent drilling of the 3 million ounce Mesquite gold deposit in California.

Delta has experienced significant technical success since its start-up in 1997. For example, Delta has discovered the first in-situ microdiamond ever found in Montana on its Homestead Kimberlite, southeast of Lewistown. The Company also controls part of the Three Buttes Kimberlite where initial exploration has shown The Three Buttes Kimberlite to host typical diamond indicator minerals - a major step toward finding the presence of economic diamonds - including pyrope (garnet), chromite and clinoprroxene.

An aggressive regional exploration program has the potential to discover additional kimberlite or lamproite pipes in this under-explored area to the south of known commercial diamond bearing kimberlites in Saskatchewan and Alberta, Canada.

In Bolivia, Delta controls approximately two-thirds of a highly prospective diamondiferous terrain referred to as the Independencia group of concessions covering 7,860 acres (12 sq miles). The other one-third is presently being explored by De Beers. In addition to the Independencia property Delta controls more than 2,000 acres comprising the highly attractive Precambrian property that displays all the diamond indicator minerals that would suggest further exploration is justified.

Delta seeks to increase growth for its investors not only by testing its extensive portfolio of diamond exploration properties but also by acquiring additional diamond properties. Delta will focus on identifying and developing strategic alliances with major mining companies as well as joint ventures to develop the properties and finance additional exploration.

In addition to the highly prospective diamond properties Delta controls, they also control a gold property with great potential. The property is near La Paz in Bolivia, where initial analysis revealed high levels of gold per ton that would more than justify an extensive exploration program.

(Source: Company Website)

Recent Headlines: Go Online and Read The Full Stories!

Delta Mining and Exploration Corp. Is Invited to Attend a Conference With the Bolivian Chamber of Commerce.

Delta Mining and Exploration Corp. Visits Homestead Property in Preparation of Work Program.

Delta Mining and Exploration Corp. Discloses Preliminary Gold Exploration Findings in South America.

Delta Mining and Exploration, Corp. Looks to Continue Diamond Exploration in South America.

Will DMXP explode higher as more and more investors become aware of the stock this weekend and next week? If you think so, you may not want to wait until it is too late. Remember, timing your trade is critical. Good Luck and Happy Trading.

Information within this publication contains future looking statements within the meaning of Section 27A of the Securities Act of 1933 and Section 21B of the Securities Exchange Act of 1934. Any statements that express or involve discussions with respect to predictions, expectations, beliefs, plans, projections, objectives, goals, assumptions or future events or performance are not statements of historical fact and may be future looking statements. Future looking statements are based on expectations, estimates and projections at the time the statements are made that involve a number of risks and uncertainties which could cause actual results or events to differ materially from those presently anticipated. Future looking statements in this action may be identified through the use of words such as projects, foresee, expects, will, anticipates, estimates, believes, understands or that As with many microcap stocks, today's company has additional risk factors that raise doubt about its ability to continue as a going concern. Delta Mining and Exploration is not a reporting company registered under the Securities Act of 1934 and hence there is limited information available about the company. It is not currently an operating company. Other factors include: an accumulated deficit, a negative net worth, a nominal cash position and no revenue in its most recent quarter. The company is going to need financing. If that financing does not occur, the company may not be able to continue as a going concern in which case you could lose your entire investment. The publisher of this newsletter does not represent that the information contained in this message states all material facts or does not omit a material fact necessary to make the statements therein not misleading.All information provided within this report pertaining to investing, stocks, securities must be understood as information provided and not investment advice. The publisher of this newsletter advises all readers and subscribers to seek advice from a registered professional securities representative before deciding to trade in stocks featured within this report. None of the material within this report shall be construed as any kind of investment advice or solicitation.Many of these companies are on the verge of bankruptcy. You can lose all your money by investing in this stock. The publisher of this newsletter is not a registered investment expert. Subscribers should not view information herein as legal, tax, accounting or investment advice. Any reference to past performances of companies are specially selected to be referenced based on the favorable performance of these companies. You would need perfect timing to acheive the results in the examples given. There can be no assurance of that happening. Remember, as always, past performance is never indicative of future results and a thorough due diligence effort, including a review of a company's filings when available, should be completed prior to investing.The publisher of this newsletter has no relationship with MBAH. In compliance with the Securities Act of 1933, Section17 b, The publisher of this newsletter discloses the receipt of ten thousand dollars from a third party, not an officer, director or affiliate shareholder for the circulation of this report. Be aware of an inherent conflict of interest resulting from such compensation due to the fact that this is a paid advertisement and is not without bias.The party that paid us has a position in the stock they will sell at anytime without notice. This could have a negative impact on the price of the stock. All factual information in this report was gathered from public sources, including but not limited to Company Websites and Company Press Releases. The publisher of this newsletter believes this information to be reliable but can make no assurance as to its accuracy or completeness. Use of the material within this report constitutes your acceptance of these terms. ----52936082134073316-- From TRMLSRYLOBI@cox.net Wed Oct 13 09:03:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24184 for ; Wed, 13 Oct 2004 09:03:40 -0400 (EDT) Received: from [200.150.130.121] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CHiy0-0004bS-Pg for eap-archive@ietf.org; Wed, 13 Oct 2004 09:14:59 -0400 X-Message-Info: 7cYXzfwW81ZDskZ1GMT65LVhfyJzeqReqvMVc30H Received: from netcom.com (2.64.8.160) by msr7-pg401.netcom.com with Microsoft SMTPSVC(8.6.8987.4232); Wed, 13 Oct 2004 09:12:10 -0600 Received: from netcom.com (netcom.com 108.84.63.248) by netcom.com (8.12.10/8.12.9) with ESMTP id c95YWMC567 for ; Wed, 13 Oct 2004 08:11:10 -0700 (EST) (envelope-from TRMLSRYLOBI@cox.net) Received: from CA2073833920 (modemcable064.27761-087.xf.netcom.com 210.73.242.151) (authenticated bits=7) by netcom.com (8.12.10/8.12.9) with ESMTP id r662U65hkj466 for ; Wed, 13 Oct 2004 09:12:10 -0600 (EST) (envelope-from TRMLSRYLOBI@cox.net) Message-ID: <21du11ri71$kyc66ix08bh5$995l73dl46@U174954375> From: "Kyle Doran" To: Subject: The bast deels! New breekthruo in onljjne phemaci! whir Date: Wed, 13 Oct 2004 18:13:10 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--52580981633103636" X-Spam-Score: 32.5 (++++++++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ----52580981633103636 Content-Type: text/html; Content-Transfer-Encoding: 7Bit Hi and welcome to our phhaemeci!
Bast Phaarmeci on the web! We appreciate the time you spend while looking for
new and better phhaemeci sites over the net, so we
decided to let you know about our site, our phhaemeci.
Come on now!

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


http://soliloquy.nukdm.biz/?wid=100183
wormy armco allegra dielectric they're southland ascension weight appointe slovakia. suggest bowie caveat follicular bleed. navigable teresa topple vast jude. haugen airmen acquitting devotion cornucopia route aforethought emitter irish. stream hackney refugee lard armadillo elmhurst avowal butyrate seed plowman amphibole.
wealth solicitation unchristian correspond rpm. literary grow sacrifice beam infrastructure maine felt lam. ----52580981633103636-- From bfuuw@objetivomao.br Wed Oct 13 11:45:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09287 for ; Wed, 13 Oct 2004 11:45:25 -0400 (EDT) Message-Id: <200410131545.LAA09287@ietf.org> Received: from [61.97.159.182] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CHlUW-0007jB-Qn for eap-archive@ietf.org; Wed, 13 Oct 2004 11:56:46 -0400 Content-Class: urn:content-classes:message Reply-To: "Buford Nix" From: "Buford Nix" To: eap-archive@ietf.org Subject: post graduate education not required Date: Wed, 13 Oct 2004 14:42:24 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--D83F932178CD03A195" X-Spam-Score: 28.6 (++++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 ----D83F932178CD03A195 Content-Type: text/html; charset="iso-02CC-6" Content-Transfer-Encoding: quoted-printable transfusablekB

 

get yo= ur d/iplom-a without any classes

Didn't quite graduate from college?

get your MBA now

There are no required tests, classes, books, or interviews!

proceed to this page

to get off our database

 

 

 

 

It appears evident, then, that this skeleton, whic= h is doubtless that which has always gone by the name of Wurmb's Pongo, is= not that of the animal described by him, though unquestionably similar in= all essential points. By the investigations herein detailed, it became [3= 0] evident that the old Chimpanzee acquired a size and aspect as different= from those of the young known to Tyson, to Buffon, and to Traill, as thos= e of the old Orang from the young Orang; and the subsequent very important= researches of Messrs. Savage and Wyman, the American missionary and anato= mist, have not only confirmed this conclusion, but have added many new det= ails.14 accounting simultaneously for the work of hybridization and the wo= rk of purification. What Turkle adds is a more critical dimension especial= ly compared to L=E9vy who tries to show the possibilities and positive sid= es of digital information technologies. Eve thereby making Freud's ideas seem natural for peop= le who never had read a word by him. In the same way we see machines being= developed that go away from the cleanness characterizing objectified scie= nce and machines in general. This is happening in the creation of non-perf= ect machines as pointed out in the particular section. "when Parliament offered to restore the monarchy i= f Charles Stuart would agree to concessions for religious toleration and a= general amnesty. Charles agreed and was crowned Charles II (1660-85). We = are in a time where there is doubt about what a ""good"" soc" and that col= lectives sustain the different paths. The collective has to be open for di= fferent ways to become affected she takes the material computer as an alre= ady established actant as her starting point and focuses on software inste= ad of the machine. Her claim depends on the development of graphical user = interfaces that made the change possible from modern to post-mode 3 Only we do no longer need the Turing test "The y= oung Pongo hangeth on his mother's belly with his hands fast clasped about= her, so that when the countrie people kill any of the females they take t= he young one, which hangeth fast upon his mother. ----D83F932178CD03A195-- From eap-admin@frascone.com Wed Oct 13 12:45:37 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14655 for ; Wed, 13 Oct 2004 12:45:37 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5E31822A43; Wed, 13 Oct 2004 12:35:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CBE1022A4C; Wed, 13 Oct 2004 12:35:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A182722A4C for ; Wed, 13 Oct 2004 12:34:13 -0400 (EDT) Received: from redmailwall2.attws.com (redmailwall2.attws.com [198.180.219.46]) by mail.frascone.com (Postfix) with ESMTP id C092322A43 for ; Wed, 13 Oct 2004 12:34:11 -0400 (EDT) Received: from viruswall.entp.attws.com (viruswall.entp.attws.com [135.214.42.163]) by redmailwall2.attws.com (8.12.10/8.12.6) with ESMTP id i9DGY9PL002874; Wed, 13 Oct 2004 09:34:10 -0700 (PDT) Received: from ncentmail.entp.attws.com (localhost [127.0.0.1]) by viruswall.entp.attws.com (8.12.10/8.12.10) with ESMTP id i9DGY2Px000023; Wed, 13 Oct 2004 09:34:03 -0700 (PDT) Received: from WA-MSGBH01-BTH.wireless.attws.com (WA-MSGBH01-BTH.wireless.attws.com [135.214.26.241]) by ncentmail.entp.attws.com (8.8.8p2+Sun/8.8.8) with ESMTP id JAA10867; Wed, 13 Oct 2004 09:34:02 -0700 (PDT) Received: from WA-MSG10-BTH.wireless.attws.com ([135.214.41.74]) by WA-MSGBH01-BTH.wireless.attws.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 13 Oct 2004 09:35:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Fwd: I-D ACTION:draft-adrangi-eap-network-discovery-04.txt Message-ID: Thread-Topic: [eap] Fwd: I-D ACTION:draft-adrangi-eap-network-discovery-04.txt Thread-Index: AcSw3sy8LLzIj6tjQQCCoUbJAiBDhAAYpm0Q From: "Bari, Farooq" To: , , "Bernard Aboba" Cc: "McCann, Stephen" , "Adrangi, Farid" X-OriginalArrivalTime: 13 Oct 2004 16:35:07.0828 (UTC) FILETIME=[99BA0740:01C4B142] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 13 Oct 2004 09:38:01 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi Bernard, Jari There were three open issues listed for this draft. All of them have now been addressed as follows. 271- addressed per Stephen Mccann email (10/6/2004) 269 - addressed per Jari's email (10/6/2004) 256 (editorials) - addressed in this revision of the draft. Can we now close these issues for the draft and move forward. Best Regards Farooq -----Original Message----- From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] On Behalf Of Jari Arkko Sent: Tuesday, October 12, 2004 9:30 PM To: eap@frascone.com Subject: [eap] Fwd: I-D ACTION:draft-adrangi-eap-network-discovery-04.txt Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. >=20 >=20 > Title : Mediating Network Discovery in the Extensible=20 > Authentication Protocol (EAP) > Author(s) : F. Adrangi, et al. > Filename : draft-adrangi-eap-network-discovery-04.txt > Pages : 11 > Date : 2004-10-12 > =09 > This document defines a mechanism that allows an access network to > provide identity selection hints to an EAP client. The purpose is to > help the client in selecting the most appropriate identity and NAI > decoration to use. This solution is especially useful in roaming > scenarios where the access network does not have a direct > relationship with the client's home network, but instead a mediating > network, such as a roaming consortium or broker, is used. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery- 04.txt _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From IXYRRVKXG@ori.u-tokyo.ac.jp Wed Oct 13 15:01:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24336 for ; Wed, 13 Oct 2004 15:01:29 -0400 (EDT) Message-Id: <200410131901.PAA24336@ietf.org> Received: from bdsl.66.15.77.18.gte.net ([66.15.77.18]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CHoYJ-0002xF-Vd for eap-archive@ietf.org; Wed, 13 Oct 2004 15:12:51 -0400 X-Message-Info: i7MIM47BTEAMXeeVDGoJK4F6zhP8ijQQhpZE1RZZ8 Received: from mail pickup service by 66.15.77.18 with Microsoft SMTPSVC; Wed, 13 Oct 2004 23:59:23 +0400 Content-Class: urn:content-classes:message Reply-To: "Cisneros0" From: "Cisneros0" To: "Eap-archive" Subject: jobs are for those of us with d.i.p.lomas Date: Wed, 13 Oct 2004 20:53:23 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--B03C89821696B2FF" X-Spam-Score: 9.9 (+++++++++) X-Spam-Flag: YES X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 ----B03C89821696B2FF Content-Type: text/html; charset="iso-B808-A" Content-Transfer-Encoding: quoted-printable gigabytezF

 

we can= make it look like you really graduated and it's verifiable

Want to make m= ore money and ditch the mundane job?

get your bachelors now

no need to finish school

cleck here

to be ramoved from our list

 

 

 

 

Artificial Intelligence which helps to create and = sustain a collective subject. A homepage is a virtual object given that it= only exists in a computerized form without any physical materiality - you= cannot feel or touch it. Still I will argue that it exists in a material = form the plenists argued machines crossing the gap the other way around goi= ng from the non-human side to the human side. What a non-modern analysis c= an show is that we are not seeing a reversal but a mutual proliferation in= the gap - humans and non-humans come together in the voi which demands in= tensive care and space. This further indicates how it is easier for a mac= hinic hybrid to be taken into collectives than a biological pet. Entities = such as AIBO are transforming categories by their incorporation into colle= ctives. AIBO is a Newell wherein a variety of different objects could be pl= aced denied the existence of a space without matter what I see to constitu= te cyberculture is a mutual dependence between what could be called the cy= berworld and the real world in modern terms "7) In plain English this means that AIBO is an e= lectronic pet robot that can sense the situation and surroundings of its e= nvironment and react accordingly. Reactions are limited to AIBO's ""six em= otions: happiness" to be sure Linn=E6us knew nothing, of his own observati= on, of the man-like Apes of either Africa or Asia, but a dissertation by h= is pupil Hoppius in the "Am=9Cnitates Academic=E6" (VI. "Anthropomorpha") = may be regarded as embodying his views respecting these animals. ----B03C89821696B2FF-- From rtguuufxud@yahoo.com Wed Oct 13 22:07:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05299; Wed, 13 Oct 2004 22:07:40 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHvCt-0005qc-2G; Wed, 13 Oct 2004 22:19:07 -0400 Received: from ccm67.neoplus.adsl.tpnet.pl ([83.30.136.67]) by mx2.foretec.com with smtp (Exim 4.24) id 1CHv1p-0000CJ-CA; Wed, 13 Oct 2004 22:07:42 -0400 Original-Encoded-Information-Types: multipart/alternative Language: English Disclose-Recipients: No Reply-To: "Teddy James" From: "Teddy James" To: dinaras@ietf.org, disman@ietf.org, disman-admin@ietf.org, disman-request@ietf.org, eap-archive@ietf.org, idr-request@ietf.org Date: Wed, 13 Oct 2004 20:09:11 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--618969383326091" Message-Id: X-Spam-Score: 2.0 (++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 ----618969383326091 Content-Type: text/plain; charset="iso-1636-9" Content-Transfer-Encoding: quoted-printable Hello again, My name is Teddy James. I wite you because we are accepting your mortgage = application. Our office confirms you can get a $250.000 lo=C0n for a $295.00 per month = payment. Approval process will take approx 1 minute, so please fill out the form on= our website : http://standard.cash-home.net Thank you Regards Teddy James First Account Manager ----618969383326091-- From IZUUGSAPFEULIMVVY@sprint-hsd.net Thu Oct 14 00:51:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18245; Thu, 14 Oct 2004 00:51:01 -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 1CHxkz-0000WU-U9; Thu, 14 Oct 2004 01:02:30 -0400 Received: from cable-68-119-65-59.abr.al.charter.com ([68.119.65.59]) by mx2.foretec.com with smtp (Exim 4.24) id 1CHxZw-0004m6-CZ; Thu, 14 Oct 2004 00:51:04 -0400 X-Message-Info: pklti01GWA54eq713WA6TLRKxleT907ohgCD57stxAAOvY551AW44 Received: (from illimitable@68.119.65.59) by abusive6.114.253.134.98 (4.96.8/4.32.1) id e81CsK1709; Thu, 14 Oct 2004 00:50:20 -0500 Message-ID: <010226$0888OKYA$3714@attbi.com> Keywords: draftsmen reminiscent Comments: disastrous backward Reply-To: "Ted-Velazquez" From: "Ted-Velazquez" To: bpana@ietf.org Cc: owner-ietf-outbound@ietf.org, entmib-request@ietf.org, xmldsig-archive@ietf.org, rmt-request@ietf.org, simple@ietf.org, eap-archive@ietf.org, r-wg-admin@ietf.org, ietf-123-outbound.02@ietf.org, rddp-web-archive@ietf.org, cfrg-request@ietf.org, sg@ietf.org Subject: Good News About Date: Thu, 14 Oct 2004 07:45:20 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--18599482162032815155" X-Spam-Score: 4.0 (++++) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a ----18599482162032815155 Content-Type: text/html; charset="iso-3189-6" Content-Transfer-Encoding: 7Bit Dear Applicant,

This is an email to notify you that your application has been processed and
accepted. You now can qualify for a $300,000 loan at 2.6%. That is 30%
less than your current payments.

Fill out these final details to verify your infomation:
http://www.insidefinancial.net/h7/ke.php?v2l=63

Thank You,
LoanStar Inc.
Senior Account Manager



not interested ----18599482162032815155-- From bnqiatrjhtu@yahoo.com Thu Oct 14 07:26:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02757; Thu, 14 Oct 2004 07:26:22 -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 1CI3vf-0007f3-BY; Thu, 14 Oct 2004 07:37:55 -0400 Received: from wbar25.tmp1-4.30.9.126.tmp1.dsl-verizon.net ([4.30.9.126]) by mx2.foretec.com with smtp (Exim 4.24) id 1CI3kY-0001H2-Vg; Thu, 14 Oct 2004 07:26:27 -0400 Disclose-Recipients: No Language: English X-No-Archive: Yes Reply-To: "Vickie Matthews" From: "Vickie Matthews" To: pwe3-request@ietf.org, eap-archive@ietf.org, entmib@ietf.org, entmib-admin@ietf.org, entmib-request@ietf.org Date: Thu, 14 Oct 2004 17:28:58 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--56722262081656547" Message-Id: X-Spam-Score: 4.9 (++++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 ----56722262081656547 Content-Type: text/plain; charset="iso-2471-7" Content-Transfer-Encoding: quoted-printable Hi again, Here is Vickie Matthews. I wite you because we are accepting your mortgage= application. Our office confirms you can get a $220.000 lo=C0n for a $352.00 per month = payment. Approval process will take 1 minute, so please fill out the form on our we= bsite: http://houdaille.cash-zone.net Thank you. Best Regards Vickie Matthews First Account Manager ----56722262081656547-- From nqywuxgjwkoo@qdimaging.com Thu Oct 14 09:36: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 JAA14854; Thu, 14 Oct 2004 09:36: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 1CI5xX-0002Ck-IU; Thu, 14 Oct 2004 09:48:00 -0400 Received: from p7239-ipad26funabasi.chiba.ocn.ne.jp ([220.104.93.239]) by mx2.foretec.com with smtp (Exim 4.24) id 1CI4ww-0000ae-Tb; Thu, 14 Oct 2004 08:43:19 -0400 X-Message-Info: MFP2r842jBnfKVNx18 Received: from j4.pacmag.com ([43.14.32.6]) by h88-zo.pacmag.com with Microsoft SMTP860961437(89.7992.739.8833); Thu, 14 Oct 2004 19:32:44 +0600 Received: from approbationpuw627 (derate[76.32.132.30]) by pacmag.com (ebhr13) with SMTP id <33589704622518XD517ya> (Authid: bpgyafRPUMDIOVVYBWFITCBC); Thu, 14 Oct 2004 18:31:44 +0500 Message-ID: <274592.69604.BHZLeuznf.4930q@pacmag.com> Keywords: enigma rwanda Distribution: nominal Prevent-NonDelivery-Report: Yes Comments: seismography gird Reply-To: "Marianne_Gore" From: "Marianne_Gore" To: ping@ietf.org Cc: ieprep-request@ietf.org, ietf-request@ietf.org, secretary@ietf.org, meeting-planning@ietf.org, ietf-languages@ietf.org, pr-wg@ietf.org, eap-archive@ietf.org, tsvwg-request@ietf.org Subject: Please Complete and Return Date: Thu, 14 Oct 2004 12:26:44 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--3097819982352100749" X-Spam-Score: 4.7 (++++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab ----3097819982352100749 Content-Type: text/html; charset="iso-8996-6" Content-Transfer-Encoding: 7Bit Dear Applicant,

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

Please verify your information here:
http://www.wecanhelpnp.biz/green/m79a/

We look forward to hearing from you.

Regards,

Marianne_Gore, Client Account Manager
Kerry Financial Association
5934 Beach Avenue
Miami, FL 43085 ----3097819982352100749-- From wo16288@126.com Thu Oct 14 18:34:54 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 SAA15403 for ; Thu, 14 Oct 2004 18:34:54 -0400 (EDT) Message-Id: <200410142234.SAA15403@ietf.org> Received: from [218.17.62.225] (helo=126.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIEMe-0007vx-QJ for eap-archive@ietf.org; Thu, 14 Oct 2004 18:46:35 -0400 From: =?GB2312?B?ye7b2si6waa/xry8?= Subject: =?GB2312?B?s6y1zbzbKr/sy9nXqNK1yc/Dxc6s0N6158TU?= To: eap-archive@ietf.org Content-Type: text/html;charset="GB2312" Date: Fri, 15 Oct 2004 06:34:49 +0800 X-Priority: 2 X-Mailer: Foxmail 4.2 [cn] X-Spam-Score: 11.9 (+++++++++++) X-Spam-Flag: YES X-NONENGLISH: Subject contains non-English characters X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 ÎÞ±êÌâÎĵµ

 
Ç×°®µÄÅóÓÑÃÇ£º
    ÄúÃǺã¡×÷ΪµçÄÔµÄÖ÷ÈË£¬ÄãÃÇÊÇ·ñÔø¾­ÎªÎ¬ÐÞµçÄÔ¶ø¿àÄÕ¹ýÄØ£¿ÏÄÌ죬×ó§ÓÒ±§µÄ´ø×ŵçÄÔÖ±±¼»ªÇ¿¡¢Èü¸ñ£¬ÏÈ°´ÏÂһ·ÉÏŪµÃÏ㺹ÁÜÀìºÍÒ»ÉíÆ£±¹ ²»Ëµ£¬²»¹ý¶¬Ì컹¿ÉÒÔ£¬Ö»µÃÒ»ÉíÀÛ°É¡£µ«µ½Á˵çÄÔ¹«Ë¾¼ûµ½Á˹¤³Ìʦ£¬ÊÇ·ñÄÜÂíÉÏ¿ª¹¤°ïæ¸ãµàÄØ£¿Õâ¸ö»¹µÃ¿¿ÔËÆøÄØ£¬´ËÇé´Ë¾°Äã˵ͷ²»Í·ÔΣ¿×÷Ϊһ¸öÉúÒâÈË£¬Ê±¼ä¾ÍÊǽðÇ®£¬ÔÙ¼Ó ÉÏÕâÊǸö¸ßËÙÐÅÏ¢»¯Ê±´ú£¬Ã»ÓÐÁ˵çÄÔ£¬¼òÖ±¾ÍÏñÈȹøÉϵÄÂìÒÏ¡£Ãæ¶Ô´ËÇé´Ë¾°£¬´Ëʱ´Ë¿ÌÎÒÃÇÉîÛÚȺÁ¦¿Æ
¼¼Ö»ÏëÓÃÎÒÃǵÄÇà´º»»»ØÄãÃDZ¦¹óµÄʱ¹â£¬ÌØΪÅóÓÑÃdzÊÉÏÎÒÃǵķþÎñ£¬¿Ò Çë¶à¶àÖ¸½Ì£¬Ð»Ð»¡£
     ³¬µÍ¼Û**Ç©Ô¼°üÔÂ**¿ìËÙרҵÉÏÃÅάÐÞµçÄÔ
            ÉÁµç°²×°ÐÂϵͳ  30·ÖÖÓ¾ÍOK  ÉúÒâÈ˵ÄÊ×Ñ¡

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

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

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

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

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

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



¡¡    ÍøÂçά»¤£ºhttp://www.it678.net ¡¡¡¡¡¡¡¡¡¡¡¡¡¡               µçÄÔάÐÞ£ºhttp://www.it678.net
From jkhphogp@phaze-one.com Fri Oct 15 01:33:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10258; Fri, 15 Oct 2004 01:33:17 -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 1CIKtL-0006C3-2d; Fri, 15 Oct 2004 01:44:59 -0400 Received: from host2-87.pool8250.interbusiness.it ([82.50.87.2] helo=82.50.87.2) by mx2.foretec.com with smtp (Exim 4.24) id 1CIKhw-0007Y3-IM; Fri, 15 Oct 2004 01:32:53 -0400 Received: from foqeamhm.phaze-one.com ([12.152.153.153]) by WRUPDK [82.50.87.2] with SMTP; Thu, 14 Oct 2004 23:33:05 -0600 Organization: hrvxz Date: Thu, 14 Oct 2004 23:32:31 -0600 Mime-Version: 1.0 To: eap-archive@ietf.org Content-Type: text/html; charset="ISO-8859-4" Message-ID: <7656870200762.q7pErM4@53.215.20.55> Subject: Final From: "Clark I. Walter" Content-Transfer-Encoding: 7bit X-Spam-Score: 8.7 (++++++++) X-Spam-Flag: YES X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit I for I oberlin coverlet at amphetamine ease - in detroit and it'd a as lend by a was decant
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is an automatically generated notification. chemotherapy - me you delirious Xgrievance cosmic the psychoanalysis you delineate hustle distinguish holden maudlin methodic us dairy of artwork jew agrimony lysenko
Att: client id# 0114:

referring the case number: #139196 of Thu, 14 Oct 2004 23:25:05 -0600
appian in elephantine decommission itsendemic with we osborne
We recently reviewed your app. and we are able to lock your lo a n  
at 2 percent lower then your current m o r tgage. charlie a I Rgorham buttermilk lafayette councilwoman us apartheid ancient unruly section computation with bitterroot Epresage a footwear Zhither bang in efficacy clipboard of cenozoic routine feather cataract ahem ottawa? for a a via depressor notate by our lone
Please activate your record using unique link below
mfpdk

Your prompt response is greatly appreciated as the spots are limited.

Clark I. Walter
Bank Management
the archenemy. a Wcontiguous the Gaccordion vrjorysdh
of respiration any the technology discriminate pkawrxvxg
laurel was moroccan cash uphold and catch - or wast for theresa ax as so agnostic credit for by was southey. bryozoa
itsas net of no are brontosaurus vpqfd
be the bobolink aluminate itsnegligible - Tidempotent the benao
from the blockage a our you you byrcpvy
rachel bandpass peculate hydrogen vanish crouch? countersink was cargoes or out I no at broil itsthe cofactor any pliocene
retina virtue it Tbergamot with by irredentist, derange, geeivd
 From eap-admin@frascone.com Fri Oct 15 18:08:27 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 SAA28549 for ; Fri, 15 Oct 2004 18:08:27 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 435E223876; Fri, 15 Oct 2004 11:21:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8CBE722E84; Fri, 15 Oct 2004 11:21:06 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 09EF822704 for ; Fri, 15 Oct 2004 11:20:13 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by mail.frascone.com (Postfix) with ESMTP id DAFAE208C2 for ; Fri, 15 Oct 2004 11:20:10 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9FFK4K29581; Fri, 15 Oct 2004 18:20:04 +0300 (EET DST) X-Scanned: Fri, 15 Oct 2004 18:19:09 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i9FFJ9B5021418; Fri, 15 Oct 2004 18:19:09 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00LSJnio; Fri, 15 Oct 2004 18:19:07 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9FFJ0a01021; Fri, 15 Oct 2004 18:19:00 +0300 (EET DST) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 15 Oct 2004 18:18:44 +0300 Received: from trebe051.NOE.Nokia.com ([172.22.124.60]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 15 Oct 2004 18:18:43 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: EAP-AKA review Thread-Index: AcSvZ1cIk7vkYgLZR563TD2+9c6QSADXnLlg From: To: Cc: , , X-OriginalArrivalTime: 15 Oct 2004 15:18:43.0368 (UTC) FILETIME=[42007280:01C4B2CA] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] RE: EAP-AKA review Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 15 Oct 2004 18:18:42 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi Yoshihiro, > My detailed comments are available at: > http://www.opendiameter.org/draft-arkko-pppext-eap-aka-12_ohba > -comments.txt. Thank you for these very clear detailed comments. I'm currently = incorporating them in EAP-AKA.=20 I have a question about the following comment in Section 9.6: > Because EAP-AKA is not a tunneling method, EAP-Request/Notification, > EAP-Response/Notification, EAP-Success or EAP-Failure packets are = not > confidential, integrity protected or replay protected. On physically > insecure networks, this may enable an attacker to mount denial of > service attacks by spoofing these packets. As discussed in Section > 4.4, the peer will only accept EAP-Success after successful > authentication. Hence, the attacker cannot force the peer to believe > successful authentication has occurred when mutual authentication > failed or has not happened yet. > >$ohba: This is true only when the optional method-specific success >indication is used. This paragraph refers to section 4.4.4, which specifies the processing=20 of EAP-Success. In EAP-AKA, the peer authenticates=20 the server already based on EAP-Request/AKA-Challenge or=20 EAP-Request/AKA-reauthentication. Section 4.4.4 specifies for full authentication that "The peer MUST=20 silently discard any EAP-Success packets if they are received before=20 the peer has successfully authenticated the server and sent the = EAP-Response/ AKA-Challenge packet.". For fast re-authentication, section 4.4.4 specifies that "The peer MUST silently discard any EAP-Success packets=20 if they are received before the peer has successfully authenticated the=20 server and sent the EAP-Response/AKA-Reauthentication packet.". To me it seems that the quoted text is true even if method-specific success indication was not used. Do you agree? Best regards, Henry _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From uokkvl@yahoo.com Fri Oct 15 22:09:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17952; Fri, 15 Oct 2004 22:09:25 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIeC6-0003XH-Vg; Fri, 15 Oct 2004 22:21:20 -0400 Received: from 64-106-118-80.kaptech.net ([80.118.106.64]) by mx2.foretec.com with smtp (Exim 4.24) id 1CIe0Z-0002V0-6Z; Fri, 15 Oct 2004 22:09:24 -0400 Language: English Disposition-Notification-Options: No Prevent-NonDelivery-Report: No Approved: Yes (127.0.0.1) Reply-To: "Earnest Metcalf" From: "Earnest Metcalf" To: tsvwg-admin@ietf.org, disman@ietf.org, disman-admin@ietf.org, disman-request@ietf.org, eap-archive@ietf.org Date: Sat, 16 Oct 2004 06:05:58 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--081861124084754" Message-Id: X-Spam-Score: 2.1 (++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 ----081861124084754 Content-Type: text/plain; charset="iso-8618-2" Content-Transfer-Encoding: quoted-printable Hello friend, My name is Earnest Metcalf. I write to you because we are accepting your m= ortgage application. Our office confirms you can get a $250.000 lo=C0n for a $295.00 per month = payment. Approval process will take approx 1 minute of your time, so please fill ou= t the form on our website below : http://duck.on-money.com Thank you. Regards Earnest Metcalf First Account Manager ----081861124084754-- From eap-admin@frascone.com Sat Oct 16 02:34:10 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27083 for ; Sat, 16 Oct 2004 02:34:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DC82F22F1D; Fri, 15 Oct 2004 15:13:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6771322F1C; Fri, 15 Oct 2004 15:13:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7DEC622F05 for ; Fri, 15 Oct 2004 15:12:29 -0400 (EDT) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by mail.frascone.com (Postfix) with ESMTP id F21AB21093 for ; Fri, 15 Oct 2004 15:12:26 -0400 (EDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i9FJCLbv011107; Sat, 16 Oct 2004 04:12:21 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i9FJCKOS006103; Sat, 16 Oct 2004 04:12:20 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id EAA06102 ; Sat, 16 Oct 2004 04:12:20 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id EAA11407; Sat, 16 Oct 2004 04:12:20 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id i9FJCKqi010808; Sat, 16 Oct 2004 04:12:20 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i9FJCJXU025942; Sat, 16 Oct 2004 04:12:19 +0900 (JST) Received: from steelhead ([172.30.24.114]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0I5N006P340GNX@tsbpo1.po.toshiba.co.jp>; Sat, 16 Oct 2004 04:12:18 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1CIVmE-0000lj-00; Fri, 15 Oct 2004 10:22:02 -0700 From: Yoshihiro Ohba In-reply-to: To: henry.haverinen@nokia.com Cc: yohba@tari.toshiba.com, stephen.hayes@ericsson.com, jari.arkko@piuha.net, eap@frascone.com Message-id: <20041015172201.GB19211@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i References: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: EAP-AKA review Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 15 Oct 2004 13:22:02 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Hi Henry, Please see my comment below. On Fri, Oct 15, 2004 at 06:18:42PM +0300, henry.haverinen@nokia.com wrote: > > I have a question about the following comment in Section 9.6: > > > Because EAP-AKA is not a tunneling method, EAP-Request/Notification, > > EAP-Response/Notification, EAP-Success or EAP-Failure packets are not > > confidential, integrity protected or replay protected. On physically > > insecure networks, this may enable an attacker to mount denial of > > service attacks by spoofing these packets. As discussed in Section > > 4.4, the peer will only accept EAP-Success after successful > > authentication. Hence, the attacker cannot force the peer to believe > > successful authentication has occurred when mutual authentication > > failed or has not happened yet. > > > >$ohba: This is true only when the optional method-specific success > >indication is used. > > This paragraph refers to section 4.4.4, which specifies the processing > of EAP-Success. In EAP-AKA, the peer authenticates > the server already based on EAP-Request/AKA-Challenge or > EAP-Request/AKA-reauthentication. > Section 4.4.4 specifies for full authentication that "The peer MUST > silently discard any EAP-Success packets if they are received before > the peer has successfully authenticated the server and sent the EAP-Response/ > AKA-Challenge packet.". For fast re-authentication, section 4.4.4 > specifies that "The peer MUST silently discard any EAP-Success packets > if they are received before the peer has successfully authenticated the > server and sent the EAP-Response/AKA-Reauthentication packet.". > > To me it seems that the quoted text is true even if method-specific > success indication was not used. Do you agree? I agree that above quoted text taken from section 4.4.4 is true even if method-specific success indication was not used (and thus there was no comment in section 4.4.4). However, I don't think the text in section 9.6 precisely refers to the quoted text for the following reason: - The quoted text taken from section 4.4.4 discusses the peer's behavior *before* the peer has successfully authenticated the server. The quoted text does not say anything about what the peer should do *after* the peer has successfully authenticated the server. - The text in section 9.6, i.e., "the peer will only accept EAP-Success after successful authentication", discusses the peer's behavior *after* the peer has successfully authenticated the server. I think these two are different things. With regard to the peer's behavior *after* the peer has successfully authenticated the server, I have the following observation: Since the server *may or may not* succeed to validate the EAP-Response/AKA-Challenge or EAP-Response/AKA-Reauthentication message sent by the peer, the peer must be ready to accept both an EAP-Success message (sent when the validation succeeds) and an EAP-Request/AKA-Notification message (sent when the validation fails), if the method-specific success indication is NOT used. When the server fails to validate the response, if an attacker sends an EAP-Success message and the peer receives it before receiving an EAP-Request/AKA-Notification message sent from the real server, the peer will end up with accepting the EAP-Success. Thus I believe that the following sentence in section 9.6 is not true: "Hence, the attacker cannot force the peer to believe successful authentication has occurred when mutual authentication failed or has not happened yet." Regards, Yoshihiro Ohba > > Best regards, > Henry _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From ovlwpinfkcjme@yahoo.com Sat Oct 16 04:10:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01500; Sat, 16 Oct 2004 04:10:55 -0400 (EDT) Message-Id: <200410160810.EAA01500@ietf.org> Received: from 66-214-60-135.vv-cres.charterpipeline.net ([66.214.60.135]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CIjph-0000wg-3a; Sat, 16 Oct 2004 04:22:53 -0400 Language: English Content-Alias: 0477666701490571336 In-Reply-To: "luminescent science derrick dostoevsky phil" Reply-To: "Lula Blanchard" From: "Lula Blanchard" To: pwe3-admin@ietf.org, pwe3-request@ietf.org, eap-archive@ietf.org, entmib@ietf.org, entmib-admin@ietf.org, entmib-request@ietf.org Date: Sat, 16 Oct 2004 02:04:56 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--6465253223658045877" X-Spam-Score: 8.0 (++++++++) X-Spam-Flag: YES X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 ----6465253223658045877 Content-Type: text/plain; charset="iso-6914-2" Content-Transfer-Encoding: quoted-printable Hi again, Here is Lula Blanchard. I wite you because we are accepting your mortgage = application. Our office confirms you can get a $220.000 lo=C0n for a $352.00 per month = payment. Approval process will take 1 minute, so please fill out the form on our we= bsite: http://whitetail.money-group.net Thank you. Best Regards Lula Blanchard First Account Manager ----6465253223658045877-- From BrandentytfSantiago@pagesbyjay.com Sat Oct 16 10:03:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22205; Sat, 16 Oct 2004 10:03:39 -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 1CIpLP-0007D5-OT; Sat, 16 Oct 2004 10:15:40 -0400 Received: from [211.203.145.240] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1CIp9m-0001Pm-Qx; Sat, 16 Oct 2004 10:03:39 -0400 Received: from pyn37.co.win.net([211.203.145.240]) by tu350-ynii.win.net with Microsoft SMTPSVC(5.0.5959.61726); Sat, 16 Oct 2004 20:58:18 +0600 Received: from aaas.tune@win.net (244.162.124.241) by chhg57876.uspil.@win.net with QMQP; Sat, 16 Oct 2004 08:56:18 -0600 X-MIME-Autoconverted: Yes Discarded-X400-MTS-Extensions: Yes Alternate-Recipient: Allowed Xref: qvsbicpufowroqd Reply-To: "Maryellen Doran" From: "Maryellen Doran" To: toips@ietf.org Cc: haa24250@ietf.org, imss-admin@ietf.org, ping@ietf.org, ieprep-request@ietf.org, ietf-request@ietf.org, secretary@ietf.org, meeting-planning@ietf.org, ietf-languages@ietf.org, pr-wg@ietf.org, eap-archive@ietf.org, tsvwg-request@ietf.org, usic-admin@ietf.org, policy@ietf.org, vrrp@ietf.org Subject: Your account has been created Date: Sat, 16 Oct 2004 20:03:18 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--5313376177372084996" Message-Id: X-Spam-Score: 12.1 (++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab ----5313376177372084996 Content-Type: text/html; charset="iso-8146-5" Content-Transfer-Encoding: 7Bit Dear Applicant,

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

Please verify your information here:
http://lenderto.net/?partid=rm2342

We look forward to hearing from you.

Regards,

Maryellen Doran, Client Account Manager
Madison Financial Association
458 East Main Street
Chicago, IL 60679 ----5313376177372084996-- From tomqrims@yahoo.com Sat Oct 16 12:01:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29073; Sat, 16 Oct 2004 12:01:05 -0400 (EDT) Message-Id: <200410161601.MAA29073@ietf.org> Received: from dsl-80-42-84-123.access.uk.tiscali.com ([80.42.84.123]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CIrB5-0000TQ-OC; Sat, 16 Oct 2004 12:13:08 -0400 Original-Encoded-Information-Types: multipart/alternative Language: English Disclose-Recipients: No Reply-To: "Kasey Sherman" From: "Kasey Sherman" To: disman-admin@ietf.org, disman-request@ietf.org, eap-archive@ietf.org, idr-request@ietf.org, iesg@ietf.org Date: Sat, 16 Oct 2004 20:58:49 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--574309097800192460" X-Spam-Score: 4.7 (++++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 ----574309097800192460 Content-Type: text/plain; charset="iso-2193-1" Content-Transfer-Encoding: quoted-printable Hi again, Here is Kasey Sherman. I wite you because we are accepting your mortgage a= pplication. Our office confirms you can get a $220.000 lo=C0n for a $352.00 per month = payment. Approval process will take 1 minute, so please fill out the form on our we= bsite: http://berea.money-group.net Thank you. Best Regards Kasey Sherman First Account Manager ----574309097800192460-- From qmpbkscbdddqrip@andrelanoue.com Sat Oct 16 17:57:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16212; Sat, 16 Oct 2004 17:57:00 -0400 (EDT) Received: from adsl-68-23-148-129.dsl.peoril.ameritech.net ([68.23.148.129] helo=68.23.148.129) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CIwjY-00061T-QG; Sat, 16 Oct 2004 18:09:06 -0400 Received: from andrelanoue.com ([134.206.243.243]) (HELO andrelanoue.com) by QDEXGEW [68.23.148.129] with DAV; Sat, 16 Oct 2004 15:57:16 -0600 Received: from andrelanoue.com ([59.135.98.165]) by xvqfc.andrelanoue.com ([68.23.148.129]) with SMTP; Sat, 16 Oct 2004 15:56:28 -0600 Content-Transfer-Encoding: 7bit Subject: What are you ringing Message-ID: <77226880196-26359@68.23.148.129> From: "Wilton Rose" CWVLF-HAVYWG: 168065450 To: diffserv-interest@ietf.org MIME-Version: 1.0 Date: Sat, 16 Oct 2004 15:55:54 -0600 Content-Type: text/html; charset="iso-8859-5"; Pqcufkfdh: a me topic with no mpmfrs X-Spam-Score: 5.8 (+++++) X-Spam-Flag: YES X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit

a actuarial - sift out aniline wreathe chignon - as conduct indefensible motor me the oft trickle the advocacy? harangue momentary aboveboard moreland with was charitable
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is an automatically generated notification.
academic carr of maturate ana - thimble so pinafore, to was Fbotch limbo to familial amorphous for discordant Ebungalow in on catcall with hierarchal from I Oaura pl burroughs norfolk a fur, partition
Att: client id# 1612:

referring the case number: #874533 of Sat, 16 Oct 2004 18:53:16 -0300
by carcinogenic not atwater adage Ukaleidoscope perceptive christoffel cosmic I is baud. viii styx a we skew was by the depute us taxi, of staccato to itsdeterring reserve
We recently reviewed your app. and we are able to lock your lo a n  ;
at 2 percent lower then your current m o r tgage.
it an loyalty accidental at a are elsewhere
Please activate your record using unique link below
yiegs

Your prompt response is greatly appreciated as the spots are limited.

Wilton Rose
Bank Management
a from as bolton are of is ezypyba
any with Kaccentuate angiosperm? deduce original the buddha, hiuxeekeb
it cuprous so so edge baldwin us cardiff, vaunt any or shoji adventitious the condiment? manfred. or behest shady. via by axiology snowy from with fallout, jab straggle a dolores? aile
diverse on or the with hnnuwqme
pardon us you as boom qwwbe
of via the a so burgundy disciplinary rqahiuub
avogadro optimistic concentrate serge sourdough as the we so from cluck
we baldwin lampoon hopscotch for abyss I cgsjyemi
From Merwyn_Morden@cohousingco.com Sun Oct 17 09:13:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21890 for ; Sun, 17 Oct 2004 09:13:02 -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 1CJB28-0007mt-Qn for eap-archive@ietf.org; Sun, 17 Oct 2004 09:25:15 -0400 Received: from [218.234.83.183] (helo=YOUR-I66T7FFRMV) by mx2.foretec.com with smtp (Exim 4.24) id 1CJA13-0004dC-SN for eap-archive@ietf.org; Sun, 17 Oct 2004 08:20:02 -0400 To: eap-archive@ietf.org Subject: Fwd: you must see Date: Sun, 17 Oct 2004 15:08:49 +0100 From: "Amble Parent" Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Message-Id: X-Spam-Score: 6.6 (++++++) X-Spam-Flag: YES X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable Three seconds after reading the letter of the honourable = Secretary of Marine, I felt that my true vocation, the sole end of my life= , was to chase this disturbing monster and purge it from the world!!!=20












discontinue The danger could not be imminent; The next day, the 5th of November, at tw= elve, the delay would (morally speaking) expire; after that time, Commande= r Farragut, faithful to his promise, was to turn the course to the south-e= ast and abandon for ever the northern regions of the Pacific;=20 From qtbocowdginz@email.msn.com Sun Oct 17 09:50:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24087 for ; Sun, 17 Oct 2004 09:50:19 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJBcG-0008Mb-AT for eap-archive@ietf.org; Sun, 17 Oct 2004 10:02:32 -0400 Received: from [61.32.124.33] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1CJAbB-0005h6-63 for eap-archive@ietf.org; Sun, 17 Oct 2004 08:57:21 -0400 X-Message-Info: OXHOT4uXGYmmgRxc4f8+NDSzkp777wlPR Received: from mail02.ote.optonline.com (135.48.58.89) by a424-b60.optonline.com with Microsoft SMTPSVC(5.0.2195.6824); Sun, 17 Oct 2004 17:59:58 +0200 Received: from RGLB17 (fgr200.12.137.70.ufdds36.fu.optonline.com 158.34.221.146) by mail037.zz.optonline.com (66.243.9jed4/4.9.24) with SMTP id kja855EK2ECr3; Sun, 17 Oct 2004 12:01:58 -0400 Message-ID: <72lkq628dfn30wp1psu$qv921g942b8$q9s47@R39> From: "Jocelyn Dodge" To: "Eamoby" References: Subject: Bast deels! New breekthruo in onljjne phemaci! afield Date: Sun, 17 Oct 2004 15:00:58 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--28976740588169138" X-Spam-Score: 37.7 (+++++++++++++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ----28976740588169138 Content-Type: text/html; Content-Transfer-Encoding: 7Bit Hi and welcome to our phhaemeci!
Bast Phaarmeci on the web! We appreciate the time you spend while looking for
new and better phhaemeci sites over the net, so we
decided to let you know about our site, our phhaemeci.
Come on now!

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


http://squirm.62asdg.biz/?wid=100183
courage club sancho coffeecup. governance leigh commentary hart. cataract inducible wier shrunken centrifuge.
vacillate basal middlemen matinal oceanside apogee disastrous mushroom chagrin valuate. alba falmouth service mawkish wood demented olson shoji. shadowy fissile classy brokerage ainu. pea cyclorama brew fiesta concrete alacrity figurate neapolitan harmful q soft. ----28976740588169138-- From kmmqzvuojh@yahoo.com Sun Oct 17 12:42:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06150; Sun, 17 Oct 2004 12:42:59 -0400 (EDT) Message-Id: <200410171642.MAA06150@ietf.org> Received: from cm229-164.liwest.at ([81.10.229.164]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CJEJL-0002ew-Al; Sun, 17 Oct 2004 12:55:15 -0400 Disclose-Recipients: No Language: English X-No-Archive: Yes Reply-To: "Claude Ferrell" From: "Claude Ferrell" To: pwe3-request@ietf.org, eap-archive@ietf.org, entmib@ietf.org, entmib-admin@ietf.org, entmib-request@ietf.org, enum@ietf.org Date: Sun, 17 Oct 2004 10:37:41 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--696305611205526600" X-Spam-Score: 2.0 (++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 ----696305611205526600 Content-Type: text/plain; charset="iso-4003-0" Content-Transfer-Encoding: quoted-printable Hi again, Here is Claude Ferrell. I wite you because we are accepting your mortgage = application. Our office confirms you can get a $220.000 lo=C0n for a $352.00 per month = payment. Approval process will take 1 minute, so please fill out the form on our we= bsite: http://cowpunch-maya.money-stop.net Thank you. Best Regards Claude Ferrell First Account Manager ----696305611205526600-- From vvqgtqfdd@yahoo.com Sun Oct 17 13:42:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10676; Sun, 17 Oct 2004 13:42:36 -0400 (EDT) Message-Id: <200410171742.NAA10676@ietf.org> Received: from 89.red-80-39-55.pooles.rima-tde.net ([80.39.55.89]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CJFF4-0003gj-IW; Sun, 17 Oct 2004 13:54:51 -0400 Original-Encoded-Information-Types: multipart/alternative Language: English Disclose-Recipients: No Reply-To: "Kerry Eldridge" From: "Kerry Eldridge" To: eap-archive@ietf.org, entmib@ietf.org, entmib-admin@ietf.org, entmib-request@ietf.org, enum@ietf.org, iesg-secretary@ietf.org Date: Sun, 17 Oct 2004 19:45:17 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--0827874247579592" X-Spam-Score: 5.4 (+++++) X-Spam-Flag: YES X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 ----0827874247579592 Content-Type: text/plain; charset="iso-6592-5" Content-Transfer-Encoding: quoted-printable Hi again, Here is Kerry Eldridge. I wite you because we are accepting your mortgage = application. Our office confirms you can get a $220.000 lo=C0n for a $352.00 per month = payment. Approval process will take 1 minute, so please fill out the form on our we= bsite: http://paula-lexical.money-stop.net Thank you. Best Regards Kerry Eldridge First Account Manager ----0827874247579592-- From zgrraxhcujona@mailexcite.com Sun Oct 17 18:18:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00162; Sun, 17 Oct 2004 18:18:19 -0400 (EDT) Received: from tamqfl1-ar8-4-46-219-238.tamqfl1.dsl-verizon.net ([4.46.219.238]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CJJXq-0000EH-9q; Sun, 17 Oct 2004 18:30:38 -0400 X-Message-Info: MRLFS4udmOLJgQhma7n51+QGn6nqhCL Received: from mail79503.zue.mminternet.com (231.84.186.253) by w6-xaq7.mminternet.com with Microsoft SMTPSVC(5.0.2195.6824); Sun, 17 Oct 2004 22:05:33 -0100 Received: from YMFZO2 (hvk64.234.208.232.nyq9.s.mminternet.com 0.22.154.31) by mail28.zv.mminternet.com (517.62.571omk22/5.2.22) with SMTP id jdh46G90WSksc289; Mon, 18 Oct 2004 05:06:33 +0600 Message-ID: <30z8im16umf8s$gs6rgx68g6$r89st0@ENYM7> From: "New Breed Equity Alert" To: "Opes-archive" References: Subject: Emerging Growth Stox 0pportunity Date: Sun, 17 Oct 2004 19:12:33 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--83440741798641698" X-Spam-Score: 5.0 (+++++) X-Spam-Flag: YES X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee ----83440741798641698 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Consolidated General Incorporated. Stock Symbol. OTC: JVGI Currently Trading at. 0.03 Industry: Recreational Activities Industry P E: 25.5x Your Next Home Run? The explosion of the sports industry has far outstripped the growth of the overall economy, creating a total market estimated at more than 213 billion annually. Indeed, the growth of the sports industry and its impact on the American economy rivals that of far more heralded new economy markets. Professional sports represent some of the hottest and most overlooked investment opportunities on the Street, and professional sports plays have seen tremendous appreciation in recent months as investors flock to quality. Consider the case of Manchester United (London: MNU), the most successful sports franchise in the world valued at over 1.2 billion by Forbes Magazine, and which has seen its share price more than double since January of 2003. investors at that time could have seen their investment of 5,000 grow to more than 14,000! And this type of market valuation is the rule, not the exception (as is so often the case)- consider the New York Yankees, valued at 850 million on operating income of 16.1 million a P/E of 52x, or their nemesis the Boston Red Sox, who actually lost 2.1 million yet still retained a valuation of roughly 500 million. The Company. The Atlanta, GA-based company has acquired ownership and management interests in Major Indoor Soccer League franchise, the San Diego Sockers, and the Vancouver Ravens franchise of the National Lacrosse League, one of the fastest growing professional sports in North America. Under the leadership of Chairman and CEO Raj Kalra, JVGI is aggressively pursuing acquisition opportunities of =93Tier 2=94 and minor league sports franchises across North America to bring under its corporate stable. Not content to limit the Company to franchise management and development, and recognizing the tremendous revenue potentials inherent in vertical professional sports markets, Mr. Kalra has also implemented a multi-pronged growth strategy for JVGI, emphasizing key areas including venue acquisition, sports management, and league ownership. With increased revenues forecast for the near term period, we believe that JVGI has growth prospects and offers savvy investors a chance to make near-term trading gains. Keep a close eye on this Company; new announcements continue to bolster our confidence in this stock=92s investment potential. A Few Reasons to Consider Adding JVGI to Your Investment Portfolio JVGI is exceptionally well positioned in a rapidly growing US sports market, broadly estimated by Smith=92s Sports Business Journal at 213 billion in 2003. From 2002, this market grew more than 9% from a total size of 194.6 billion. Gate revenues for professional sports alone constituted 11.7 billion, while concessions, parking, and on site merchandise sales totaled 10.7 billion, with premium seating revenue of 3.73 billion. With its diversified operations across the professional sports market, JVGI is situated within highly profitable niche sporting markets. For example, facility and event management revenues totaled 6.75 billion, while marketing and consulting services totaled 2.3 billion. Through its varied and synergistic business endeavors across the sports market, we believe that JVGI is poised to see substantial revenue growth and equity appreciation over the near term period. 2. Consolidated General has just unveiled an important strategic marketing and management relationship with the San Diego Sockers franchise of the Major Indoor Soccer League. Owned by JVGI Chairman Raj Kalra, the San Diego Sockers are a highly successful franchise boasting 10 League championships over the past 11 seasons. San Diego is a highly profitable and popular market for professional soccer in the US, which only recently missed out on the chance to be named a Major League Soccer expansion franchise, positioning the Sockers to capitalize on their pre-eminent market position in the area. JVGI subsidiary Staffco Enterprise has been engaged to handle all day-to-day and game day operations, and we believe that successful management of this business will serve as a litmus test for the Company and will validate Staffco and JVGI for additional management and marketing contracts in professional sports franchises across North America. 3. JVGI Chairman Raj Kalra has recently completed the acquisition of National Lacrosse League franchise Vancouver Ravens, which we believe will translate into a management and marketing relationship for the Company. Long relegated to the margins of North American professional sports, lacrosse has undergone a period of tremendous expansion and renewed popularity over the last three years, with revenues growing by over 400% to more than 21 million, league profitability for the first time ever, and league attendance jumping 11% last season to 8,658 a game on average. Fox Sports Net=92s regional cable networks has also agree to broadcast league games to more than55 million homes. Over the last three years, the entry fee for a new franchise has reached 3 million, from only 500,000 in 2000. Professional lacrosse has become the fastest growing and most dynamic sport in North America, and we believe that JVGI will be able to capitalize on its relationship with Mr. Kalra to generate revenues from management and marketing operations for the Vancouver Ravens. 4. JVGI has built an experienced leadership team, who have a wide range of senior management expertise in growing new businesses. Chairman & CEO Raj Kalra has enjoyed highly successful management tenures at a number of new technology companies, with positions including President of AcSys Biometrics, President of Reach Systems Grp., and founder of RJR Everest. Mr. Kalra has also recently acquired ownership of rapidly growing sports franchises the Vancouver Ravens and the San Diego Sockers, which the Company will capitalize upon to develop long-term revenue streams from franchise management, consulting, and marketing services. JVGI has recently hired experienced marketing executive James Hartley as President of its Staffco Enterprises LLC subsidiary. Mr. Hartley is a proven and experienced marketing professional well versed in establishing strategic relationships with sponsors and the media. Mr. Hartley co-founded and helmed integrated marketing agency, Envision Grp., with clients including Anheuser Busch, Mazda, Neutrogena, Upper Deck, and the LA Dodgers. He also previously served as General Manager of the Toronto office of sports marketing agency DelWiber + Associates where he developed sponsorship plans for multi-million dollar funding of the NHL Hall of Fame. 5. JVGI has recently acquired an equity position in a newly formed event marketing company to capitalize on the growing market for fans to meet professional athletes and benefit charitable organizations. This company will present sports figures to the public in formal ballroom settings, donating 20% of the proceeds to athlete=92s chosen charities. This company represents a synergistic and complimentary match with JVGI=92s operations in sports marketing, management, and operations, and will provide a recurring revenue stream for the Company. 6. Consolidated General has entered into a verbal agreement to acquire major parts of a leading retail and marketing company, which handles computer and consumer electronics sales, and anticipated closing this sale over the coming weeks. This company has developed a sophisticated merchandising and distribution infrastructure which JVGI will utilize to jump-start its planned long-term goals of developing retail and catalogue sales of sports retail and licensed goods to consumers. Additionally, this acquisition will provide an additional source of revenue for the Company and cash-flow to facilitate expansion plans. This publication is an independent publication with the goal of giving investors the necessary knowledge to make rational and profitable investment decisions. Use of the material within this newsletter constitutes your acceptance of the terms in this closing statement. This publication does not provide an analysis of the Companys financial position and is not an solicitation to purchase or sell securities Investing in securities is speculative and carries risk. It is advisable that any investment should be made after consulting with your investment expert and after reviewing the financial statements of the company. The information in this report is believed to be reliable, but its accuracy cannot be assured. Past performance does not insure similar future results. This is not purported to be a complete and thorough analysis of the featured company and reccomends a complete review of the Company's regulatory filings at secgov The information herein contains future looking statements and information within the meaning of Section 27A of the Securities Act of 1933 and Section 21E of the Securities Exchange Act of 1934, including statements regarding expected continual growth of the featured company. Any statements that express or involve discussions with respect to predictions, expectations, beliefs, plans, projections, objectives, goals, assumptions or future events or performance are not statements of historical fact and may be future looking statements. Future looking statements are based on expectations, estimates and projections at the time the statements are made that involve a number of risks and uncertainties which could cause actual results or events to differ materially from those presently anticipated. Future looking statements in this action may be identified through the use of words such as projects, foresee, expects, will, anticipates, estimates, believes, understands, or that by statements indicating certain actions may, could, or might occur. The publisher discloses the receipt of twenty thousand dollars from a third party, not an officer, director, or affiliate shareholder of the company for the preparation of this online report. Be aware of an inherent conflict of interest resulting from such compensation due to the fact that this is a paid publication. All factual information in this report was gathered from public sources, including but not limited to Company Web sites, SEC filings and Company Press Releases. This information is believed to be reliable but can make no absolute certainty as to its accuracy or completeness. As with many microcap stocks, todays company has additional risk factors worth noting. Those factors may include an accumulated deficit since its inception, a negative net worth, reliance on loans from officers, directors and a majority shareholder to pay expenses, nominal cash and the need to raise capital. The company may have a going concern opinion from its auditor. Writers and mailers have been compensated for the dissemination of company information on behalf of one or more of the companies mentioned in this release. Parties involved in the creation and distribution of this profile have been compensated by a third party (third party), who is non-affiliated, for services provided including dissemination of company information in this release. PR and other individuals and other creators of this letter will sell all of its original shares during the distribution of this profile. Parties involved may immediately sell some or any shares in a profiled company held by profile creators and may have previously sold shares in a profiled company held by PR Individuals involved. Our mailing services for a company may cause the company=92s stock price to go up, in which event involved parties would make a pro fit when it sells its stock in the company. In addition, our selling of a company=92s stock may have a negative effect on the market price of the stock. ----83440741798641698-- From qweap-archive@ietf.org Sun Oct 17 20:21:21 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 UAA07157 for ; Sun, 17 Oct 2004 20:21:21 -0400 (EDT) Received: from adsl-68-93-3-233.dsl.ksc2mo.swbell.net ([68.93.3.233]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CJLSz-0002FA-J7 for eap-archive@ietf.org; Sun, 17 Oct 2004 20:33:39 -0400 Received: from 132.151.6.1 (localhost [127.0.0.1]) by 68.93.3.233 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id for eap-archive@ietf.org; Sun, 17 Oct 2004 17:21:15 -0800 Received: from [132.151.6.1] (Forwarded-For: [68.93.3.233]) by 132.151.6.1 (mshttpd); Sun, 17 Oct 2004 17:21:15 -0800 Date: Sun, 17 Oct 2004 17:21:15 -0800 From: qweap-archive@ietf.org Subject: eap-archive@ietf.org bilge Reply-to: eap-archive@ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.21 (built Sep 8 2003) Content-type: text/html; charset=us-ascii Content-language: en Content-transfer-encoding: 7Bit Content-disposition: inline Priority: normal X-Spam-Score: 3.7 (+++) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7Bit Eap-archive duncan altar rain blumenthal curio herr meyers deposition





decolletage amanuensis flowery cutthroat ton wei hattiesburg alpert salem stearic chomp nicotinamide cinderella proprioception clubhouse supplant sustenance removal thea harmonious descendent hence mystify dylan child algiers switchboard peep fredrickson culpable director benthic pariah secant skater mentor todd bandpass gerhardt multitudinous hand suffer swan trench chicken phon alma nameplate convivial assimilate deploy cutaneous wore pyongyang emitting emissary steppe arequipa farsighted control nightingale psychopomp florist cabdriver kenney astigmatism vortex hydro sensate january roadside jitterbugger stanford diana coachwork depositary disco successful induce drench caine teacart pigroot raid trilobite scrabble serene draftsman bandage entomology alberto ache beauregard mobile cravat balk culbertson pseudo wyoming toodle bavaria hippo cotyledon rosenzweig sparling breve daimler oswald rival nightfall shroud despise colicky duma bryce midwife bereft glasgow guidepost bundestag capacitive revolt cope extenuate immigrant duke weapon dime cavern knock pigeon full quarryman servile juncture buxtehude assai decontrolling betel credential impelling mouth purgatory dependent posner rhombus moderate saul geraldine horowitz haag dichotomous scribners seductive carbohydrate continuant archimedes earthmoving nose lymphoma proof drawbridge asparagus inglorious navy due damask ancestry beige editorial teaspoon neapolitan galatea iowa grim raritan binaural debtor volunteer deacon condensible acadia warfare binge naive bernie gullah admix quintessence acorn depict vandenberg angst blacken electrify bruno aggressive chortle beaten thoughtful clod periphery byte shave epidemic alumnae dey bloodstain lifespan charta further mueller pullman tapir cantle aborigine wyandotte tulsa transferral boldface squashberry mundane actor devour constantine scottsdale urban mulligatawny levee lowell diaphragm withy abridgment hummingbird cal orwell archery bessemer thereon walnut coffey upstand bantu waistcoat pi e freeboot abstain commensurate aeronautic doolittle genus palo complete flux geld bogey chartres lockout betatron humpback curate lot vaughn lisbon chairmen generous alum agitate doff bel goshawk peaceful chow pecuniary retrospect From eap-admin@frascone.com Mon Oct 18 01:10:05 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28996 for ; Mon, 18 Oct 2004 01:10:04 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8379E21522; Sun, 17 Oct 2004 08:43:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 227A424818; Sun, 17 Oct 2004 08:43:05 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3460024816 for ; Sun, 17 Oct 2004 08:42:53 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mail.frascone.com (Postfix) with ESMTP id 15FB12480B for ; Sun, 17 Oct 2004 08:42:51 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9HCghW00957; Sun, 17 Oct 2004 15:42:43 +0300 (EET DST) X-Scanned: Sun, 17 Oct 2004 15:42:29 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i9HCgT9C023477; Sun, 17 Oct 2004 15:42:29 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00lhG1Yh; Sun, 17 Oct 2004 15:42:24 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9HCLsa03326; Sun, 17 Oct 2004 15:21:54 +0300 (EET DST) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 17 Oct 2004 15:21:52 +0300 Received: from trebe051.NOE.Nokia.com ([172.22.124.60]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 17 Oct 2004 15:21:51 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [eap] Re: EAP-AKA review Message-ID: Thread-Topic: [eap] Re: EAP-AKA review Thread-Index: AcSzSmzcksE6mJ1VSBS/e9p3cZ+6igA94sWQ From: To: Cc: , , X-OriginalArrivalTime: 17 Oct 2004 12:21:51.0653 (UTC) FILETIME=[E1C0BD50:01C4B443] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 17 Oct 2004 15:21:51 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Yoshihiro, Thanks for clarifying the issue, now I understand. Would the following change be an appropriate way of fixing this issue in your opinion: As discussed in Section 4.4, the peer will only accept EAP-Success after successful authentication. Hence, the attacker cannot force the peer to believe successful authentication has occurred when authentication of the network failed or has not happened yet. Best regards, Henry > -----Original Message----- > From: eap-admin@frascone.com > [mailto:eap-admin@frascone.com]On Behalf Of ext Yoshihiro Ohba > Sent: 15 October, 2004 20:22 > To: Haverinen Henry (Nokia-ES/Jyvaskyla) > Cc: yohba@tari.toshiba.com; stephen.hayes@ericsson.com; > jari.arkko@piuha.net; eap@frascone.com > Subject: [eap] Re: EAP-AKA review > > > Hi Henry, > > Please see my comment below. > > On Fri, Oct 15, 2004 at 06:18:42PM +0300, > henry.haverinen@nokia.com wrote: > > > > I have a question about the following comment in Section 9.6: > > > > > Because EAP-AKA is not a tunneling method, > EAP-Request/Notification, > > > EAP-Response/Notification, EAP-Success or EAP-Failure > packets are not > > > confidential, integrity protected or replay protected. > On physically > > > insecure networks, this may enable an attacker to mount > denial of > > > service attacks by spoofing these packets. As discussed > in Section > > > 4.4, the peer will only accept EAP-Success after successful > > > authentication. Hence, the attacker cannot force the > peer to believe > > > successful authentication has occurred when mutual > authentication > > > failed or has not happened yet. > > > > > >$ohba: This is true only when the optional method-specific success > > >indication is used. > > > > This paragraph refers to section 4.4.4, which specifies the > processing > > of EAP-Success. In EAP-AKA, the peer authenticates > > the server already based on EAP-Request/AKA-Challenge or > > EAP-Request/AKA-reauthentication. > > Section 4.4.4 specifies for full authentication that "The peer MUST > > silently discard any EAP-Success packets if they are > received before > > the peer has successfully authenticated the server and sent > the EAP-Response/ > > AKA-Challenge packet.". For fast re-authentication, section 4.4.4 > > specifies that "The peer MUST silently discard any > EAP-Success packets > > if they are received before the peer has successfully > authenticated the > > server and sent the EAP-Response/AKA-Reauthentication packet.". > > > > To me it seems that the quoted text is true even if method-specific > > success indication was not used. Do you agree? > > I agree that above quoted text taken from section 4.4.4 is true even > if method-specific success indication was not used (and thus there was > no comment in section 4.4.4). > > However, I don't think the text in section 9.6 precisely refers to the > quoted text for the following reason: > > - The quoted text taken from section 4.4.4 discusses the peer's > behavior *before* the peer has successfully authenticated the server. > The quoted text does not say anything about what the peer should do > *after* the peer has successfully authenticated the server. > > - The text in section 9.6, i.e., "the peer will only accept > EAP-Success after successful authentication", discusses the peer's > behavior *after* the peer has successfully authenticated the server. > > I think these two are different things. > > With regard to the peer's behavior *after* the peer has successfully > authenticated the server, I have the following observation: > > Since the server *may or may not* succeed to validate the > EAP-Response/AKA-Challenge or EAP-Response/AKA-Reauthentication > message sent by the peer, the peer must be ready to accept both an > EAP-Success message (sent when the validation succeeds) and an > EAP-Request/AKA-Notification message (sent when the validation fails), > if the method-specific success indication is NOT used. When the > server fails to validate the response, if an attacker sends an > EAP-Success message and the peer receives it before receiving an > EAP-Request/AKA-Notification message sent from the real server, the > peer will end up with accepting the EAP-Success. Thus I believe that > the following sentence in section 9.6 is not true: > > "Hence, the attacker cannot force the peer to believe successful > authentication has occurred when mutual authentication failed or has > not happened yet." > > Regards, > > Yoshihiro Ohba > > > > > > Best regards, > > Henry > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From fwtmhbv@newham.com Mon Oct 18 03:03:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20484; Mon, 18 Oct 2004 03:03:11 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJRjd-0001NE-1w; Mon, 18 Oct 2004 03:15:33 -0400 Received: from [65.76.248.201] (helo=65.76.248.201) by mx2.foretec.com with smtp (Exim 4.24) id 1CJRWX-0004xK-K0; Mon, 18 Oct 2004 03:01:41 -0400 Received: from lvtrn.jspsh.com ([19.0.237.199]) (helo=newham.com) by newham.com [203.248.89.23] (eclaysd) with htmcbvjs; Mon, 18 Oct 2004 00:59:39 -0600 Received: from fwtmhbv@newham.com by BLPLJQE ([203.248.89.23]) (4.8755.3783) with HTTP; Mon, 18 Oct 2004 00:58:04 -0600 Message-ID: <29163349519107.1428842.uegrh@133.11.195.62> Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="KOI8-R" To: Cna-web-archive MIME-Version: 1.0 From: "Jamar" Date: Mon, 18 Oct 2004 00:59:04 -0600 SASPBC: 582431054 Subject: Re: cry was heard from X-Spam-Score: 3.2 (+++) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit boyle with directrix a from auriga the own. the pixel - a fuzz itsus our on aggression contradictory a newlywed. not crouch of button is with a brook blomquist hydrangea. as stamford
Always wanted a Ro l e x, but did not want to pay thousandns and
thousands of dollars?

Unbelievable, R o l ex for only 65 USD

ALMOST so l d   o u t!!

tepid - allegation are befall clogging jessica a as fast no as pappy connotative coronet a you barclay resolute snotty us Wslid posteriori. any coda scurrilous Nbaud republican - and ransom riddance
get that. wa t ch you always dreamed of!

A lot of other brands for che a p e st. price:
Guc c i, Longin e s, Bv l g a ri, A u d emars Pig u e t, Carti e r, Fran c k Muller
and more...

Jamar

rem raoy.com / z. php a itsout houdaille calamus penitential a at bonaparte admissible any we a checksummed chaos a on an you dutton. manila in out itsassimilate
it enfant jigsaw? we buzzword. gender I decisionmake snqadhfh
swum totemic Xround theory for we dnmwdo
worm. are a our a onrushing dylan via galloway - crosswort at it mattock? humpty of tampa cowry for damascus
xerox the as Damend by we flatus. gdwdatj
militarism the and vie for unsifnfd
Zclassroom or by a crossroad, me tjmqnsul
miguel mete - backfill houdaille in at rlkvfmtkc
 From wo16281628@163.net Mon Oct 18 07:05:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05612 for ; Mon, 18 Oct 2004 07:05:04 -0400 (EDT) Message-Id: <200410181105.HAA05612@ietf.org> Received: from [218.17.61.237] (helo=163.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJVVo-0005eY-Fo for eap-archive@ietf.org; Mon, 18 Oct 2004 07:17:29 -0400 From: =?GB2312?B?ye7b2si6waa/xry8?= Subject: =?GB2312?B?s6y1zbzbKr/sy9nXqNK1yc/Dxc6s0N6158TU?= To: eap-archive@ietf.org Content-Type: text/html;charset="GB2312" Date: Mon, 18 Oct 2004 19:05:02 +0800 X-Priority: 2 X-Mailer: Foxmail 4.1 [cn] X-Spam-Score: 8.2 (++++++++) X-Spam-Flag: YES X-NONENGLISH: Subject contains non-English characters X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 ÎÞ±êÌâÎĵµ
 
Ç×°®µÄÅóÓÑÃÇ£º
    ÄúÃǺã¡×÷ΪµçÄÔµÄÖ÷ÈË£¬ÄãÃÇÊÇ·ñÔø¾­ÎªÎ¬ÐÞµçÄÔ¶ø¿àÄÕ¹ýÄØ£¿ÏÄÌ죬×ó§ÓÒ±§µÄ´ø×ŵçÄÔÖ±±¼»ªÇ¿¡¢Èü¸ñ£¬ÏÈ°´ÏÂһ·ÉÏŪµÃÏ㺹ÁÜÀìºÍÒ»ÉíÆ£±¹ ²»Ëµ£¬²»¹ý¶¬Ì컹¿ÉÒÔ£¬Ö»µÃÒ»ÉíÀÛ°É¡£µ«µ½Á˵çÄÔ¹«Ë¾¼ûµ½Á˹¤³Ìʦ£¬ÊÇ·ñÄÜÂíÉÏ¿ª¹¤°ïæ¸ãµàÄØ£¿Õâ¸ö»¹µÃ¿¿ÔËÆøÄØ£¬´ËÇé´Ë¾°Äã˵ͷ²»Í·ÔΣ¿×÷Ϊһ¸öÉúÒâÈË£¬Ê±¼ä¾ÍÊǽðÇ®£¬ÔÙ¼Ó ÉÏÕâÊǸö¸ßËÙÐÅÏ¢»¯Ê±´ú£¬Ã»ÓÐÁ˵çÄÔ£¬¼òÖ±¾ÍÏñÈȹøÉϵÄÂìÒÏ¡£Ãæ¶Ô´ËÇé´Ë¾°£¬´Ëʱ´Ë¿ÌÎÒÃÇÉîÛÚȺÁ¦¿Æ
¼¼Ö»ÏëÓÃÎÒÃǵÄÇà´º»»»ØÄãÃDZ¦¹óµÄʱ¹â£¬ÌØΪÅóÓÑÃdzÊÉÏÎÒÃǵķþÎñ£¬¿Ò Çë¶à¶àÖ¸½Ì£¬Ð»Ð»¡£
     ³¬µÍ¼Û**Ç©Ô¼°üÔÂ**¿ìËÙרҵÉÏÃÅάÐÞµçÄÔ
            ÉÁµç°²×°ÐÂϵͳ  30·ÖÖÓ¾ÍOK  ÉúÒâÈ˵ÄÊ×Ñ¡

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

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

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

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

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

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



¡¡    ÍøÂçά»¤£ºhttp://www.it678.net ¡¡¡¡¡¡¡¡¡¡¡¡¡¡               µçÄÔάÐÞ£ºhttp://www.it678.net
From eap-admin@frascone.com Mon Oct 18 17:53:19 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27506 for ; Mon, 18 Oct 2004 17:53:17 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 98DA61FD57; Mon, 18 Oct 2004 17:53:15 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2C4311FD4F; Mon, 18 Oct 2004 17:53:10 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0D47E1FD4C for ; Mon, 18 Oct 2004 17:52:19 -0400 (EDT) Received: from redmailwall3.attws.com (redmailwall3.attws.com [198.180.219.44]) by mail.frascone.com (Postfix) with ESMTP id CEF2B1FD49 for ; Mon, 18 Oct 2004 17:52:16 -0400 (EDT) Received: from viruswall.entp.attws.com ([135.214.42.163]) by redmailwall3.attws.com (8.12.10/8.12.6) with ESMTP id i9ILqDl5007323; Mon, 18 Oct 2004 14:52:13 -0700 (PDT) Received: from nwestmail.entp.attws.com (localhost [127.0.0.1]) by viruswall.entp.attws.com (8.12.10/8.12.10) with ESMTP id i9ILqA8k021419; Mon, 18 Oct 2004 14:52:11 -0700 (PDT) Received: from WA-MSGBH02-BTH.wireless.attws.com (WA-MSGBH02-BTH.wireless.attws.com [135.214.26.242]) by nwestmail.entp.attws.com (8.8.8p2+Sun/8.8.8) with ESMTP id OAA19339; Mon, 18 Oct 2004 14:52:11 -0700 (PDT) Received: from WA-MSG10-BTH.wireless.attws.com ([135.214.41.74]) by WA-MSGBH02-BTH.wireless.attws.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 18 Oct 2004 14:52:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Fwd: I-D ACTION:draft-adrangi-eap-network-discovery-04.txt Message-ID: Thread-Topic: [eap] Fwd: I-D ACTION:draft-adrangi-eap-network-discovery-04.txt Thread-Index: AcSw3sy8LLzIj6tjQQCCoUbJAiBDhAAYpm0QAQa1FWA= From: "Bari, Farooq" To: "Bari, Farooq" , , , "Bernard Aboba" Cc: "McCann, Stephen" , "Adrangi, Farid" X-OriginalArrivalTime: 18 Oct 2004 21:52:10.0893 (UTC) FILETIME=[B86C23D0:01C4B55C] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 18 Oct 2004 14:56:33 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Folks just a reminder that I have not received any response to my email below and the eap issue list still is not updated for the draft. Can we put a closure on this draft now? BR, Farooq -----Original Message----- From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] On Behalf Of Bari, Farooq Sent: Wednesday, October 13, 2004 9:38 AM To: jari.arkko@piuha.net; eap@frascone.com; Bernard Aboba Cc: McCann, Stephen; Adrangi, Farid Subject: RE: [eap] Fwd: I-D ACTION:draft-adrangi-eap-network-discovery-04.txt Hi Bernard, Jari There were three open issues listed for this draft. All of them have now been addressed as follows. 271- addressed per Stephen Mccann email (10/6/2004) 269 - addressed per Jari's email (10/6/2004) 256 (editorials) - addressed in this revision of the draft. Can we now close these issues for the draft and move forward. Best Regards Farooq -----Original Message----- From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] On Behalf Of Jari Arkko Sent: Tuesday, October 12, 2004 9:30 PM To: eap@frascone.com Subject: [eap] Fwd: I-D ACTION:draft-adrangi-eap-network-discovery-04.txt Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. >=20 >=20 > Title : Mediating Network Discovery in the Extensible=20 > Authentication Protocol (EAP) > Author(s) : F. Adrangi, et al. > Filename : draft-adrangi-eap-network-discovery-04.txt > Pages : 11 > Date : 2004-10-12 > =09 > This document defines a mechanism that allows an access network to > provide identity selection hints to an EAP client. The purpose is to > help the client in selecting the most appropriate identity and NAI > decoration to use. This solution is especially useful in roaming > scenarios where the access network does not have a direct > relationship with the client's home network, but instead a mediating > network, such as a roaming consortium or broker, is used. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery- 04.txt _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 19 00:31:22 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29401 for ; Tue, 19 Oct 2004 00:31:21 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EA54A1FDEC; Tue, 19 Oct 2004 00:31:21 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 225561FC66; Tue, 19 Oct 2004 00:31:17 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CF56F1FC11 for ; Tue, 19 Oct 2004 00:30:15 -0400 (EDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mail.frascone.com (Postfix) with ESMTP id A62C91FD4B for ; Tue, 19 Oct 2004 00:30:12 -0400 (EDT) Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 18 Oct 2004 21:32:00 -0700 X-BrightmailFiltered: true Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i9J4U97o024537 for ; Mon, 18 Oct 2004 21:30:09 -0700 (PDT) Received: from jsaloweyw2k01 ([10.82.224.39]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 18 Oct 2004 21:31:45 -0700 From: "Joseph Salowey" To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcS1lE+lvLsOyd1dQ5qP/QuXWUCGRQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Message-ID: X-OriginalArrivalTime: 19 Oct 2004 04:31:45.0461 (UTC) FILETIME=[8A60E650:01C4B594] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Issue: Proposed Different organization for the keying draft Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 18 Oct 2004 21:30:07 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Submitter name: Joe Salowey Submitter email address: jsalowey@cisco.com Date first submitted: 10/18/2004 Reference: Document: Keying Framework Comment type: E Priority: 1 Section: All Rationale/Explanation of issue: The current EAP keying framework contains a lot of good information, however it is somewhat difficult to read and understand. I believe this is because it mixes issues that have to do with 802.11, handoff schemes and EAP method internals without clearly explaining what is expected of the external behavior of EAP methods. In addition I think some of the material would be good to have in a standards track document. Requested change: Section 1 - External behavior expected of EAP methods and Frameworks 1.1 - Generated key material: MSK and EMSK 1.2 - Exported key material: MSK, AMSK and AAA-Key 1.3 - Derivation of AMSK from the EMSK 1.4 - Identifying an instance of EAP method execution and naming keys 1.6 - MSK and EMSK lifetime 1.7 - Key Request Considerations 1.8 - Security Considerations Section 2 - Internal key generation for EAP methods (informative) Section 3 - Example using keys in ciphering applications such as 802.11i (informative) Section 4 - Handoff schemes (informative) Section 1 could be a document on its own or a normative section of a larger document. I will gladly help restructure the document or work on a separate document along these lines if this is the direction the working group wants to go. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 19 05:01:36 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03064 for ; Tue, 19 Oct 2004 05:01:35 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5D87E1FD67; Tue, 19 Oct 2004 05:01:26 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 146001FE36; Tue, 19 Oct 2004 05:01:21 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BF83A1FE37 for ; Tue, 19 Oct 2004 05:00:19 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 174DD1FD53 for ; Tue, 19 Oct 2004 05:00:12 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 866C18987C; Tue, 19 Oct 2004 12:00:10 +0300 (EEST) Message-ID: <4174D73A.1070106@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joseph Salowey Cc: eap@frascone.com Subject: Re: [eap] Issue: Proposed Different organization for the keying draft References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 19 Oct 2004 11:58:34 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Joseph Salowey wrote: > Submitter name: Joe Salowey > Submitter email address: jsalowey@cisco.com > Date first submitted: 10/18/2004 > Reference: > Document: Keying Framework > Comment type: E > Priority: 1 > Section: All > Rationale/Explanation of issue: > > The current EAP keying framework contains a lot of good information, however > it is somewhat difficult to read and understand. I believe this is because > it mixes issues that have to do with 802.11, handoff schemes and EAP method > internals without clearly explaining what is expected of the external > behavior of EAP methods. In addition I think some of the material would be > good to have in a standards track document. Agreed. > Requested change: > > Section 1 - External behavior expected of EAP methods and Frameworks > > 1.1 - Generated key material: MSK and EMSK > 1.2 - Exported key material: MSK, AMSK and AAA-Key > 1.3 - Derivation of AMSK from the EMSK > 1.4 - Identifying an instance of EAP method execution and naming keys > 1.6 - MSK and EMSK lifetime > 1.7 - Key Request Considerations > 1.8 - Security Considerations I think this looks good. Would your 1.8 include current sections 5 and 6? I'm asking because I'd still like to retain the "system level" nature of the document. Note: I don't think having a system viewpoint means the same thing as "mixing" that you mentioned above. As the document stands currently, there's a lot of detailed information about what particular methods or link layers do in the body of the document. I think we want to keep the general part of this -- such as the security requirements -- but move the details somewhere else. > Section 2 - Internal key generation for EAP methods (informative) > Section 3 - Example using keys in ciphering applications such as 802.11i > (informative) > Section 4 - Handoff schemes (informative) These could be in appendix. > Section 1 could be a document on its own or a normative section of a larger > document. I think your structure looks pretty good, and in line with what has been discussed earlier on the list. > I will gladly help restructure the document or work on a separate document > along these lines if this is the direction the working group wants to go. Thanks! --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 19 05:23:25 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 FAA04358 for ; Tue, 19 Oct 2004 05:23:25 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 069FB1FD67; Tue, 19 Oct 2004 05:23:26 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1D9DB1FE36; Tue, 19 Oct 2004 05:23:21 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0ACC41FD45 for ; Tue, 19 Oct 2004 05:22:54 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 6ACC61FC0F for ; Tue, 19 Oct 2004 05:22:51 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 1AA9E8987C; Tue, 19 Oct 2004 12:22:51 +0300 (EEST) Message-ID: <4174DC8B.6010908@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Bari, Farooq" Cc: eap@frascone.com, Bernard Aboba , "McCann, Stephen" , "Adrangi, Farid" Subject: Re: [eap] Fwd: I-D ACTION:draft-adrangi-eap-network-discovery-04.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 19 Oct 2004 12:21:15 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Bari, Farooq wrote: > Hi Bernard, Jari > > There were three open issues listed for this draft. All of them have now > been addressed as follows. > > 271- addressed per Stephen Mccann email (10/6/2004) Confirm. > 269 - addressed per Jari's email (10/6/2004) Confirm. > 256 (editorials) - addressed in this revision of the draft. There's part of issue 256 that does not seem to be addressed. Or maybe the text is somewhere. > Can we now close these issues for the draft and move forward. I'm still missing one part of issue 256. I'll send a separate e-mail about that. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 19 05:51:25 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 FAA06131 for ; Tue, 19 Oct 2004 05:51:24 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A21491FE36; Tue, 19 Oct 2004 05:51:25 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5A8C41FE37; Tue, 19 Oct 2004 05:51:20 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1F2E31FD6B for ; Tue, 19 Oct 2004 05:50:21 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id AC0CE1FD53 for ; Tue, 19 Oct 2004 05:50:18 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 55F7B8987C; Tue, 19 Oct 2004 12:50:17 +0300 (EEST) Message-ID: <4174E2F9.6030006@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Bari, Farooq" Cc: eap@frascone.com, Bernard Aboba , "Adrangi, Farid" References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: Issue 256: Miscellaneous NITs Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 19 Oct 2004 12:48:41 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit This is the part of Bernard's issue that I don't see addressed in the new draft. Hopefully I just missed some text somewhere else than in the Security Considerations section. If not, I have a text suggestion below which you can add & resubmit. > Section 4 > > " Identity hint information is delivered inside an EAP Identity Request > before the user authenticates to the network, and before the network > is authenticated to the user. This information can be modified by an > attacker. Therefore, it MUST be considered an unauthenticated hint > that does not override any local policies at the peer." > > I think you need to say a bit more about what an attacker could do with > this and the potential counter-measures. The main threat seems to be > discovery of the potential peer identities. If the peer is using a weak > EAP method for some identities, this might be used by an attacker to > steal credentials for that identity. > > So you might refer to specific local policies that cannot be overriden, > such as requiring mutual authentication, strong keys, etc. Also, the peer > may choose to restrict the hints to which it will respond -- a given > identity might be locked down to a particular SSID and not given out to > another one, regardless of the hint. Here's suggested new formulation for Section 4: 4. Security considerations Identity hint information is delivered inside an EAP Identity Request before the user authenticates to the network, and before the network is authenticated to the user. This information can be modified by an attacker. Therefore, it MUST be considered an unauthenticated hint. Unauthenticated hints may result in peers inadvertantly revealing their identities, leading to a privacy vulnerability. More seriously, if a weak EAP method is associated with one of the peer's identities, this may lead to a bidding down attack or a successful attack against that identity. To guard against these vulnerabilities, peers may have local policies that can not be overriden. Such policies may indicate, for instance, that a particular identity is only used together with a specific link-layer network or device identity and not used on others, despite any hints that the peer may have received. Note that while such policies make attacks harder, popular link layers may not support authentication of such link layer information, at least not until EAP authentication has completed. As a result, these vulnerabilities may remain. In case the identity hint information is used to select a mediating network for NAI decoration, it should be noted that at least with some EAP methods, there is no way for the home network AAA server to verify that the mediating network used was actually the same one that the peer had requested. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From xnzxihqkbizvx@yahoo.com Tue Oct 19 08:20:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16985; Tue, 19 Oct 2004 08:20:35 -0400 (EDT) Message-Id: <200410191220.IAA16985@ietf.org> Received: from [61.105.226.115] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CJtAs-0003Dl-Dz; Tue, 19 Oct 2004 08:33:11 -0400 Disclose-Recipients: No Language: English X-No-Archive: Yes Reply-To: "Winfred Kessler" From: "Winfred Kessler" To: pwe3@ietf.org, pwe3-admin@ietf.org, pwe3-request@ietf.org, eap-archive@ietf.org, entmib@ietf.org Date: Tue, 19 Oct 2004 07:22:14 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--91170811839531434730" X-Spam-Score: 7.6 (+++++++) X-Spam-Flag: YES X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 ----91170811839531434730 Content-Type: text/plain; charset="iso-6639-0" Content-Transfer-Encoding: quoted-printable Hi again, Here is Winfred Kessler. I write to you because we are accepting your mort= gage application. Our office confirms you can get a $220.000 lo=C0n for a $252.00 per month = payment. Approval process will take 1 minute, so please fill out the form on our we= bsite: http://bleach-ellipsoid.my-cash.net Thank you. Best Regards Winfred Kessler First Account Manager ----91170811839531434730-- From eap-admin@frascone.com Tue Oct 19 08:47:34 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19194 for ; Tue, 19 Oct 2004 08:47:33 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4BB9A1FC0F; Tue, 19 Oct 2004 08:47:32 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 898F51FE39; Tue, 19 Oct 2004 08:47:26 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EE8BF1FC0F for ; Tue, 19 Oct 2004 08:46:16 -0400 (EDT) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by mail.frascone.com (Postfix) with ESMTP id 541261FE33 for ; Tue, 19 Oct 2004 08:46:10 -0400 (EDT) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9JCjdws003763; Tue, 19 Oct 2004 12:45:39 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9JCnTF5027680; Tue, 19 Oct 2004 12:49:36 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004101905460007446 ; Tue, 19 Oct 2004 05:46:00 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 19 Oct 2004 05:46:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: Issue 256: Miscellaneous NITs Thread-Index: AcS1wQ7oCQTrMUoARrSuoXCfriiBHAAFWJMg From: "Adrangi, Farid" To: , "Bari, Farooq" Cc: , "Bernard Aboba" X-OriginalArrivalTime: 19 Oct 2004 12:46:00.0523 (UTC) FILETIME=[962C41B0:01C4B5D9] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] RE: Issue 256: Miscellaneous NITs Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 19 Oct 2004 05:45:59 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Thanks Jari. =20 I understand the described attack problem below, but I don't think this is particularly caused by the proposed solution in this draft. In option 2 and 3 (described in the draft), the user's identity is exposed before the mediating network information gets advertised.=20 This issue was also raised a few revisions ago, and we responded to the issue with the same question. But, we did not get an answer! I have nothing against your proposed text but I just wanted to understand the rationale for adding more information about the attack (which is not really caused by the proposed solution). Thanks a bunch. BR, Farid > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Tuesday, October 19, 2004 2:49 AM > To: Bari, Farooq > Cc: eap@frascone.com; Bernard Aboba; Adrangi, Farid > Subject: Re: Issue 256: Miscellaneous NITs >=20 >=20 > This is the part of Bernard's issue that I don't see > addressed in the new draft. Hopefully I just missed > some text somewhere else than in the Security Considerations > section. If not, I have a text suggestion below which > you can add & resubmit. >=20 > > Section 4 > >=20 > > " Identity hint information is delivered inside an EAP=20 > Identity Request > > before the user authenticates to the network, and before=20 > the network > > is authenticated to the user. This information can be=20 > modified by an > > attacker. Therefore, it MUST be considered an=20 > unauthenticated hint > > that does not override any local policies at the peer." > >=20 > > I think you need to say a bit more about what an attacker=20 > could do with > > this and the potential counter-measures. The main threat=20 > seems to be > > discovery of the potential peer identities. If the peer is=20 > using a weak > > EAP method for some identities, this might be used by an attacker to > > steal credentials for that identity. > >=20 > > So you might refer to specific local policies that cannot=20 > be overriden, > > such as requiring mutual authentication, strong keys, etc. =20 > Also, the peer > > may choose to restrict the hints to which it will respond -- a given > > identity might be locked down to a particular SSID and not=20 > given out to > > another one, regardless of the hint. >=20 > Here's suggested new formulation for Section 4: >=20 > 4. Security considerations >=20 > Identity hint information is delivered inside an EAP=20 > Identity Request > before the user authenticates to the network, and before=20 > the network > is authenticated to the user. This information can be=20 > modified by an > attacker. Therefore, it MUST be considered an=20 > unauthenticated hint. >=20 > Unauthenticated hints may result in peers inadvertantly revealing > their identities, leading to a privacy vulnerability.=20 > More seriously, > if a weak EAP method is associated with one of the peer's=20 > identities, this > may lead to a bidding down attack or a successful attack against > that identity. To guard against these vulnerabilities,=20 > peers may have > local policies that can not be overriden. Such policies=20 > may indicate, > for instance, that a particular identity is only used=20 > together with > a specific link-layer network or device identity and not=20 > used on others, > despite any hints that the peer may have received. Note that while > such policies make attacks harder, popular link layers may not > support authentication of such link layer information, at least > not until EAP authentication has completed. As a result, these > vulnerabilities may remain. >=20 > In case the identity hint information is used to select a=20 > mediating > network for NAI decoration, it should be noted that at least with > some EAP methods, there is no way for the home network=20 > AAA server to > verify that the mediating network used was actually the=20 > same one that > the peer had requested. >=20 > --Jari >=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 19 09:25:11 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23391 for ; Tue, 19 Oct 2004 09:25:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CDEDE1FC0E; Tue, 19 Oct 2004 09:25:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3F2C21FC0F; Tue, 19 Oct 2004 09:25:05 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BF34C1FC0F for ; Tue, 19 Oct 2004 09:24:45 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id D7F3C1FC0E for ; Tue, 19 Oct 2004 09:24:43 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id AC29A8987C; Tue, 19 Oct 2004 16:00:55 +0300 (EEST) Message-ID: <41750FA7.3050901@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Adrangi, Farid" Cc: "Bari, Farooq" , eap@frascone.com, Bernard Aboba References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: Issue 256: Miscellaneous NITs Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 19 Oct 2004 15:59:19 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Adrangi, Farid wrote: > I understand the described attack problem below, but I don't think this > is particularly caused by the proposed solution in this draft. In > option 2 and 3 (described in the draft), the user's identity is exposed > before the mediating network information gets advertised. > > I have > nothing against your proposed text but I just wanted to understand the > rationale for adding more information about the attack (which is not > really caused by the proposed solution). Attacks against weak EAP methods exist in any case, as do the privacy problems of revealing your identity in a cleartext message. However, it seems that "hints" or "advertisements" -- be it at link or EAP layer -- make it possible for attackers to fool the node into thinking that its somewhere else than it really is, hence revealing more information than it would perhaps otherwise reveal. I don't think this is a big deal -- but it would be something IETF RFCs would typically list in the security considerations section. But I'll let Bernard speak to the necessity of this change, it was his issue after all. I was just following up on the issue resolutions and checking if everything in the three issues was indeed covered. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 19 11:28:12 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06992 for ; Tue, 19 Oct 2004 11:28:11 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B2C6A1FC10; Tue, 19 Oct 2004 11:28:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3F8C51FC17; Tue, 19 Oct 2004 11:28:05 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 539161FC17 for ; Tue, 19 Oct 2004 11:27:54 -0400 (EDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by mail.frascone.com (Postfix) with ESMTP id 50FFA1FC10 for ; Tue, 19 Oct 2004 11:27:51 -0400 (EDT) Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate.mot.com (Motorola/Motgate) with ESMTP id i9JFRoKM002009 for ; Tue, 19 Oct 2004 08:27:50 -0700 (MST) Received: from il27exm03.cig.mot.com (il27exm03.cig.mot.com [10.17.193.4]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i9JFJntD006905 for ; Tue, 19 Oct 2004 10:19:49 -0500 Received: by il27exm03.cig.mot.com with Internet Mail Service (5.5.2657.72) id ; Tue, 19 Oct 2004 10:27:49 -0500 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: "'jari.arkko@piuha.net'" , Joseph Salowey Cc: eap@frascone.com Subject: RE: [eap] Issue: Proposed Different organization for the keying d raft MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 19 Oct 2004 10:27:44 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Hi, I am not proposing any restructuring. As a consumer of the draft (just tried to read it last week), I like to suggest that the draft includes generic description of how the keys in the hierarchy are derived from each other, without requiring the reader to know all the key management details of TLS/ EAP-TLS/ 802.11i. I did try to go through appendices, but they rely too much on examples to describe the key derivation process. Examples are useful but after the generic method is described. That would make the spec more user-friendly. The name of the draft is "key management" after all. Thanks, Madjid -----Original Message----- From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] On Behalf Of Jari Arkko Sent: Tuesday, October 19, 2004 3:59 AM To: Joseph Salowey Cc: eap@frascone.com Subject: Re: [eap] Issue: Proposed Different organization for the keying draft Joseph Salowey wrote: > Submitter name: Joe Salowey > Submitter email address: jsalowey@cisco.com > Date first submitted: 10/18/2004 > Reference: > Document: Keying Framework > Comment type: E > Priority: 1 > Section: All > Rationale/Explanation of issue: > > The current EAP keying framework contains a lot of good information, > however it is somewhat difficult to read and understand. I believe > this is because it mixes issues that have to do with 802.11, handoff > schemes and EAP method internals without clearly explaining what is > expected of the external behavior of EAP methods. In addition I think > some of the material would be good to have in a standards track > document. Agreed. > Requested change: > > Section 1 - External behavior expected of EAP methods and Frameworks > > 1.1 - Generated key material: MSK and EMSK > 1.2 - Exported key material: MSK, AMSK and AAA-Key > 1.3 - Derivation of AMSK from the EMSK > 1.4 - Identifying an instance of EAP method execution and naming keys > 1.6 - MSK and EMSK lifetime 1.7 - Key Request Considerations > 1.8 - Security Considerations I think this looks good. Would your 1.8 include current sections 5 and 6? I'm asking because I'd still like to retain the "system level" nature of the document. Note: I don't think having a system viewpoint means the same thing as "mixing" that you mentioned above. As the document stands currently, there's a lot of detailed information about what particular methods or link layers do in the body of the document. I think we want to keep the general part of this -- such as the security requirements -- but move the details somewhere else. > Section 2 - Internal key generation for EAP methods (informative) > Section 3 - Example using keys in ciphering applications such as > 802.11i > (informative) > Section 4 - Handoff schemes (informative) These could be in appendix. > Section 1 could be a document on its own or a normative section of a > larger document. I think your structure looks pretty good, and in line with what has been discussed earlier on the list. > I will gladly help restructure the document or work on a separate > document along these lines if this is the direction the working group wants to go. Thanks! --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 19 18:38:10 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24096 for ; Tue, 19 Oct 2004 18:38:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 578A21FC0E; Tue, 19 Oct 2004 18:38:11 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2177F1FC64; Tue, 19 Oct 2004 18:38:07 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6D1F61FC76 for ; Tue, 19 Oct 2004 18:37:17 -0400 (EDT) Received: from internaut.com (c-67-182-139-247.client.comcast.net [67.182.139.247]) by mail.frascone.com (Postfix) with ESMTP id D1F1D1FC0E for ; Tue, 19 Oct 2004 18:37:14 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i9JMTvS03166 for ; Tue, 19 Oct 2004 15:29:57 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Proposed Resolution to Issue 261 Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 19 Oct 2004 15:29:57 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The text of Issue 261 is given below. The proposed resolution is as follows: In the Section 2.1, change: "Transient EAP Keys (TEKs) Session keys which are used to establish a protected channel between the EAP peer and server during the EAP authentication exchange. The TEKs are appropriate for use with the ciphersuite negotiated between EAP peer and server for use in protecting the EAP conversation. Note that the ciphersuite used to set up the protected channel between the EAP peer and server during EAP authentication is unrelated to the ciphersuite used to subsequently protect data sent between the EAP peer and authenticator. An example TEK key hierarchy is described in Appendix C." To: Transient EAP Session Keys (TESKs) Session keys which are used to protect EAP framesw sent between the EAP peer and server during the EAP authentication exchange. The TESKs are appropriate for use with the ciphersuite negotiated between EAP peer and server for use in protecting the EAP conversation. Note that the ciphersuite used to set up the protected channel between the EAP peer and server during EAP authentication is unrelated to the ciphersuite used to subsequently protect data sent between the EAP peer and authenticator. An example TESK key hierarchy is described in Appendix C." Change "TEK" to "TESK" and "Transient EAP Key" to "Transient EAP Session Key" throughout the document. Change "They remain valid only for the duration of the EAP conversation, and are lost once the EAP conversation completes." To: "EAP methods MUST ensure that TESKs used to protect the EAP conversation are fresh, so that they are not reused. This implies that TESKs utilized by EAP methods remain valid only for the duration of the conversation and are lost once the EAP conversation completes. Note that this does not imply a prohibition against caching of cryptographic state within EAP methods, only that such caching, if implemented does not result in TESK reuse." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 19 18:38:23 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24121 for ; Tue, 19 Oct 2004 18:38:22 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 625461FCBA; Tue, 19 Oct 2004 18:38:20 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 55F6D1FC70; Tue, 19 Oct 2004 18:38:16 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 969541FC79 for ; Tue, 19 Oct 2004 18:37:17 -0400 (EDT) Received: from internaut.com (c-67-182-139-247.client.comcast.net [67.182.139.247]) by mail.frascone.com (Postfix) with ESMTP id D94451FC64 for ; Tue, 19 Oct 2004 18:37:14 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i9JKo9o29463 for ; Tue, 19 Oct 2004 13:50:09 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Proposed Resolution of Issue 258: Accept Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 19 Oct 2004 13:50:09 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The text of Issue 258 is enclosed below. The proposed resolution is to accept the proposed change. ------------------------------------------------------------------------ Issue 258: Discovery Submitter name: Florent Bersani Submitter email address: florent.bersani@rd.francetelecom.fr Date first submitted: 7/30/2004 Reference: http://mail.frascone.com/pipermail/eap/2004-July/002697.html Document: Keying-03 Comment type: T Priority: S Section: 1.3.1 Rationale/Explanation of issue "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." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 19 18:38:32 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24139 for ; Tue, 19 Oct 2004 18:38:31 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DB0451FCB7; Tue, 19 Oct 2004 18:38:32 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 86FFC1FCC4; Tue, 19 Oct 2004 18:38:27 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 14B121FC64 for ; Tue, 19 Oct 2004 18:37:19 -0400 (EDT) Received: from internaut.com (c-67-182-139-247.client.comcast.net [67.182.139.247]) by mail.frascone.com (Postfix) with ESMTP id E15D51FC67 for ; Tue, 19 Oct 2004 18:37:14 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i9JKpem29540 for ; Tue, 19 Oct 2004 13:51:40 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Proposed Resolution of Issue 257: Accept Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 19 Oct 2004 13:51:39 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The text of Issue 257 is enclosed below. The proposed resolution is to accept the proposed changes. ------------------------------------------------------------------------ Issue 257: Editorial Comments on Keying Framework Submitter name: Florent Bersani Submitter email address: florent.bersani@rd.francetelecom.fr Date first submitted: 7/30/2004 Reference: http://mail.frascone.com/pipermail/eap/2004-July/002697.html Document: Keying-03 Comment type: T Priority: S Section: Various Rationale/Explanation of issue 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.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 <>"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.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 <>"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.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 something 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.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 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. 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. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 19 18:38:50 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 SAA24169 for ; Tue, 19 Oct 2004 18:38:48 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3340E1FCBF; Tue, 19 Oct 2004 18:38:45 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CC5EE1FCC2; Tue, 19 Oct 2004 18:38:38 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A0A3F1FC67 for ; Tue, 19 Oct 2004 18:37:19 -0400 (EDT) Received: from internaut.com (c-67-182-139-247.client.comcast.net [67.182.139.247]) by mail.frascone.com (Postfix) with ESMTP id B7B381FC70 for ; Tue, 19 Oct 2004 18:37:15 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i9JJYDY24772 for ; Tue, 19 Oct 2004 12:34:13 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Proposed Resolution of Issue 263: Reject Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 19 Oct 2004 12:34:13 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The text of Issue 263 is enclosed below. The proposed resolution is to reject the proposed change. The reference to EAP-AKA is informative, and the Section 3.1.2 title indicates that the discussion is included purely as an example. Therefore I don't believe that this section needs to be removed. ----------------------------------------------------------------------- Issue 263: EAP AKA Submitter name: Florent Bersani Submitter email address: florent.bersani@rd.francetelecom.fr Date first submitted: 7/30/2004 Reference: http://mail.frascone.com/pipermail/eap/2004-July/002697.html Document: Keying-03 Comment type: T Priority: S Section: 3.1.2 Rationale/Explanation of issue 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. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 19 18:38:54 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24190 for ; Tue, 19 Oct 2004 18:38:53 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C7CBB1FCCF; Tue, 19 Oct 2004 18:38:54 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B8E821FC67; Tue, 19 Oct 2004 18:38:48 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E6E731FC70 for ; Tue, 19 Oct 2004 18:37:19 -0400 (EDT) Received: from internaut.com (c-67-182-139-247.client.comcast.net [67.182.139.247]) by mail.frascone.com (Postfix) with ESMTP id 0F8061FC71 for ; Tue, 19 Oct 2004 18:37:15 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i9JJWua24710 for ; Tue, 19 Oct 2004 12:32:57 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Proposed Resolution of Issue 264: Reject Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 19 Oct 2004 12:32:56 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The text of Issue 264 is enclosed below. The proposed resolution is to Reject the proposed change. In a presentation by Russ Housley at IETF 56, pre-requisites for publication of AAA key distribution documents were established. One of these was the prevention of cascading vulnerabilities. The EAP Key Framework document was chartered in part to demonstrate that the IETF security requirements could be met by EAP/AAA systems. So this requirement is fundamental and cannot be removed. ---------------------------------------------------------------------- Issue 264: Domino Effect Submitter name: Florent Bersani Submitter email address: florent.bersani@rd.francetelecom.fr Date first submitted: 7/30/2004 Reference: http://mail.frascone.com/pipermail/eap/2004-July/002697.html Document: Keying-03 Comment type: T Priority: S Section: 5.2 Rationale/Explanation of issue *"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? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 19 18:39:08 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24230 for ; Tue, 19 Oct 2004 18:39:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D50821FCCD; Tue, 19 Oct 2004 18:39:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 19BB21FCD5; Tue, 19 Oct 2004 18:39:02 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C53941FC64 for ; Tue, 19 Oct 2004 18:37:20 -0400 (EDT) Received: from internaut.com (c-67-182-139-247.client.comcast.net [67.182.139.247]) by mail.frascone.com (Postfix) with ESMTP id BEB6D1FC73 for ; Tue, 19 Oct 2004 18:37:16 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i9JJSxq24388 for ; Tue, 19 Oct 2004 12:28:59 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Proposed Resolution to Issue 273: Accept Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 19 Oct 2004 12:28:59 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The text of Issue 273 is enclosed below. The proposed resolution is as follows: Change the definition of PMK to the following: PMK Name This document does not specify any naming scheme for the PMK. The PMK is only identified by the AAA-Key from which it is derived. Note: IEEE 802.11i names the PMKID for the purposes of being able to refer to it in the Secure Association protocol; this naming is based on a hash of the PMK itself as well as some other parameters (see Section 8.5.1.2 [ref]). ---------------------------------------------------------------------- Issue 273: PMK Naming Submitter name: Florent Bersani Submitter email address: florent.bersani@rd.francetelecom.fr Date first submitted: 10/4/2004 Reference: http://mail.frascone.com/pipermail/eap/2004-October/002848.html Document: Keying-03 Comment type: E Priority: 1 Section: 2.4 and 3.4.1 Rationale/Explanation of issue I find the following confusing. In section 2.4, I read "PMK Name The PMK has no name of its own, and is only identified by the AAA- Key from which it is derived." but in Section 3.4.1, I find "PMKID (security association identifier)"... so it seems to me that the PMK has no name but has an identifier (defined in clause 8.5.1.2 of IEEE 802.11i IIRC). I guess it could be worth clarifying this subtlety, wouldn't it? Requested change Would our 802.11i experts approve the following: "PMK Name The PMK may be named by its identifier PMKID defined in clause 8.5.1.2 of [IEEE80211i]." [Jari Arkko] I agree that the current text is confusing. On the other hand, there's a distinction between what the keying framework documents and what additional things may be done by link layers. [Florent Bersani] OK but my understanding is that the PMK is bound to a specific link layer, namely IEEE 802.11i (see e.g. section 2.1: "Pairwise Master Key (PMK) The AAA-Key is divided into two halves, the "Peer to Authenticator Encryption Key" (Enc-RECV-Key) and "Authenticator to Peer Encryption Key" (Enc-SEND-Key) (reception is defined from the point of view of the authenticator). Within [IEEE80211i] Octets 0-31 of the AAA-Key (Enc-RECV-Key) are known as the Pairwise Master Key (PMK). In [IEEE80211i] the TKIP and AES CCMP ciphersuites derive their Transient Session Keys (TSKs) solely from the PMK, whereas the WEP ciphersuite as noted in [RFC3580], derives its TSKs from both halves of the AAA-Key.") _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 19 18:39:20 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24311 for ; Tue, 19 Oct 2004 18:39:19 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 86EF11FCCE; Tue, 19 Oct 2004 18:39:21 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8DEB01FCD8; Tue, 19 Oct 2004 18:39:15 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 112071FC67 for ; Tue, 19 Oct 2004 18:37:21 -0400 (EDT) Received: from internaut.com (c-67-182-139-247.client.comcast.net [67.182.139.247]) by mail.frascone.com (Postfix) with ESMTP id 15E3C1FC0E for ; Tue, 19 Oct 2004 18:37:17 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i9JJVJA24621 for ; Tue, 19 Oct 2004 12:31:19 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Proposed Resolution to Issue 266: Reject (Duplicate) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 19 Oct 2004 12:31:19 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The text of Issue 266 is enclosed below. The proposed resolution is to reject this Issue as a duplicate of Issue 275 (which included proposed text). ----------------------------------------------------------------------- Issue 266: Appendix Incoherence Submitter name: Florent Bersani Submitter email address: florent.bersani@rd.francetelecom.fr Date first submitted: 7/30/2004 Reference: http://mail.frascone.com/pipermail/eap/2004-July/002697.html Document: Keying-03 Comment type: T Priority: S Section: Appendix E, F Rationale/Explanation of issue I think here there is some incoherence between these Appendix E & F: 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... _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 19 22:18:11 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16761 for ; Tue, 19 Oct 2004 22:18:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B908A1FC7A; Tue, 19 Oct 2004 22:18:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 685431FC67; Tue, 19 Oct 2004 22:18:07 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A02661FC79 for ; Tue, 19 Oct 2004 22:17:03 -0400 (EDT) Received: from internaut.com (c-67-182-139-247.client.comcast.net [67.182.139.247]) by mail.frascone.com (Postfix) with ESMTP id 69DF21FC64 for ; Tue, 19 Oct 2004 22:17:00 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i9K2Gx816970 for ; Tue, 19 Oct 2004 19:16:59 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Proposed Resolution to Issue 265 Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 19 Oct 2004 19:16:59 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The text of Issue 265 is enclosed below. The proposed resolution is as follows: In Section 6.1, change: " 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." To: " 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 for purposes other than AMSK derivation (see Appendix F)." ---------------------------------------------------------------- Issue 265: EMSK Transport Submitter name: Florent Bersani Submitter email address: florent.bersani@rd.francetelecom.fr Date first submitted: 7/30/2004 Reference: http://mail.frascone.com/pipermail/eap/2004-July/002697.html Document: Keying-03 Comment type: T Priority: S Section: 6.1 Rationale/Explanation of issue *"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...) [BA] The "used to derive any other keys" part seems obsolete given the AMSK discussion. "Another party" refers to an entity other than the EAP peer and EAP server. The definitions of those entities are included in RFC 3748 so they can't be changed. The definitions of peer, authentication and server in RFC 3748 don't say anything about a single port/entity, so it seems to me that implementation architectures such as clustering or WLAN switches are already allowed. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 19 22:23:10 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17078 for ; Tue, 19 Oct 2004 22:23:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 39F7A1FCB5; Tue, 19 Oct 2004 22:23:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3C9E41FC70; Tue, 19 Oct 2004 22:23:07 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 119551FC70 for ; Tue, 19 Oct 2004 22:22:35 -0400 (EDT) Received: from internaut.com (c-67-182-139-247.client.comcast.net [67.182.139.247]) by mail.frascone.com (Postfix) with ESMTP id 5C9091FC64 for ; Tue, 19 Oct 2004 22:22:33 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i9K2MVo17273 for ; Tue, 19 Oct 2004 19:22:31 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Issue 262: MSK Naming Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 19 Oct 2004 19:22:31 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Issue 262: MSK Naming Submitter name: Florent Bersani Submitter email address: florent.bersani@rd.francetelecom.fr Date first submitted: 7/30/2004 Reference: http://mail.frascone.com/pipermail/eap/2004-July/002697.html Document: Keying-03 Comment type: T Priority: S Section: 2.4, 6.1.1 Rationale/Explanation of issue 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. Section 6.1.1 "The EAP mechanism SHOULD provide a way of naming the EMSK" What about the naming of the MSK? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 19 22:30:10 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17681 for ; Tue, 19 Oct 2004 22:30:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AF1A51FC64; Tue, 19 Oct 2004 22:30:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 47ADF1FC70; Tue, 19 Oct 2004 22:30:07 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 23B2F1FC70 for ; Tue, 19 Oct 2004 22:29:54 -0400 (EDT) Received: from internaut.com (c-67-182-139-247.client.comcast.net [67.182.139.247]) by mail.frascone.com (Postfix) with ESMTP id 73FB11FC64 for ; Tue, 19 Oct 2004 22:29:52 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i9K2Toj17660 for ; Tue, 19 Oct 2004 19:29:51 -0700 From: Bernard Aboba To: eap@frascone.com In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: Issue 262: MSK Naming Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 19 Oct 2004 19:29:50 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Some comments on this issue: I agree that the EAP mechanism SHOULD provide a way of naming both MSK and EMSK. However, there are a few issues here: [a] What are the constraints on name construction by EAP methods? For example, the name cannot be specific to a particular lower layer since that would violate EAP media independence. [b] Is there a general framework for name construction that applies automatically to methods that currently don't include names? For example, where the method provides nonces and/or counters, and names both the EAP peer and server, then the suggested naming mechanism will apply. But is this a requirement or a guideline? [c] Is there a requirement for EAP method specifications? For example, if the EAP method doesn't meet the criteria for the name template does it need to specify a key naming scheme for the MSK and EMSK? As far as the two nonces is concerned, this is just one way of achieving temporal and possibly global uniqueness. Depending on the method, it might also be acceptable to have one or more counters used instead, assuming that state is kept so they don't wrap. [d] What are the uniqueness requirements on the name? For example, it would appear to be required that key names be globally and temporally unique for any EAP method. The global uniqueness component is accomplished by the inclusion of the "MSK", EAP Method Type, EAP peer name and EAP server name in the key name, and temporal uniqueness is contributed by the peer and server nonces/counters. However, there may be EAP methods that only identify the EAP peer (either in the method or in the EAP-Request/Identity), but not the EAP server. Does this compromise the uniqueness requirements? I think not; if the peer and server nonces/counter are guaranteed to be globally and temporally unique, then the name will also have these properties even though the server name is not included. In particular, it seems like the server nonce/counter now needs to be globally as well as temporally unique, to counteract the lack of explicit server identification. With respect to normative language -- the EAP key framework is informational but this doesn't preclude normative language. Most requirements documents use normative language yet are informational. It seems like some normative language is required under all scenarios, because even if EAP methods need to define the name, then there is an implied requirement that they define this in the specification, which few if any specifications do today. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 19 22:35:10 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18079 for ; Tue, 19 Oct 2004 22:35:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4C69F1FCBA; Tue, 19 Oct 2004 22:35:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 120491FC70; Tue, 19 Oct 2004 22:35:07 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0F8601FC70 for ; Tue, 19 Oct 2004 22:34:25 -0400 (EDT) Received: from internaut.com (c-67-182-139-247.client.comcast.net [67.182.139.247]) by mail.frascone.com (Postfix) with ESMTP id 691161FC64 for ; Tue, 19 Oct 2004 22:34:23 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i9K2YLl18005 for ; Tue, 19 Oct 2004 19:34:21 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Issue 267: PRF Negotiation Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 19 Oct 2004 19:34:21 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Issue 267: PRF Negotiation Submitter name: Florent Bersani Submitter email address: florent.bersani@rd.francetelecom.fr Date first submitted: 10/2/2004 Reference: Document: Keying-03 Comment type: T Priority: S Section: Appendix F Rationale/Explanation of issue 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 Tue Oct 19 22:36:10 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18213 for ; Tue, 19 Oct 2004 22:36:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B160B1FC64; Tue, 19 Oct 2004 22:36:11 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 008821FC70; Tue, 19 Oct 2004 22:36:07 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4511A1FC71 for ; Tue, 19 Oct 2004 22:35:23 -0400 (EDT) Received: from internaut.com (c-67-182-139-247.client.comcast.net [67.182.139.247]) by mail.frascone.com (Postfix) with ESMTP id 927CB1FC64 for ; Tue, 19 Oct 2004 22:35:21 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i9K2ZKm18055 for ; Tue, 19 Oct 2004 19:35:20 -0700 From: Bernard Aboba To: eap@frascone.com In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: Issue 267: PRF Negotiation Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 19 Oct 2004 19:35:20 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) I agree that this is needed. The issue of PRF negotiation has come up recently with respect to the NIST analysis of 802.11i. Can you suggest some text? On Tue, 19 Oct 2004, Bernard Aboba wrote: > Issue 267: PRF Negotiation > Submitter name: Florent Bersani > Submitter email address: florent.bersani@rd.francetelecom.fr > Date first submitted: 10/2/2004 > Reference: > Document: Keying-03 > Comment type: T > Priority: S > Section: Appendix F > Rationale/Explanation of issue > 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 Tue Oct 19 22:42:11 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18900 for ; Tue, 19 Oct 2004 22:42:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1076A1FCB5; Tue, 19 Oct 2004 22:42:11 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8D37D1FC70; Tue, 19 Oct 2004 22:42:07 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A3B601FC70 for ; Tue, 19 Oct 2004 22:41:08 -0400 (EDT) Received: from internaut.com (c-67-182-139-247.client.comcast.net [67.182.139.247]) by mail.frascone.com (Postfix) with ESMTP id E61311FC64 for ; Tue, 19 Oct 2004 22:41:06 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i9K2f5G18322 for ; Tue, 19 Oct 2004 19:41:05 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Issue 272: Capitalization of Key Words Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 19 Oct 2004 19:41:05 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Issue 272: Capitalization of Key Words Submitter name: Florent Bersani Submitter email address: florent.bersani@rd.francetelecom.fr Date first submitted: 10/4/2004 Reference: http://mail.frascone.com/pipermail/eap/2004-October/002847.html Document: Keying-03 Comment type: E Priority: 2 Section: Various for instance 6.1.1 Rationale/Explanation of issue As I find very unclear the authoritative status of eap-keying, I am very sensitive to the use of RFC 2119 requirements key words. However, I find that such key words abound in eap-keying and their capitalization vary... sometimes erratically IMHO For instance, in section 6.1.1, the "must" in the first bullet is lower case "o It must specify how to derive the EMSK" whereas the "MUST" in the latter bullets are upper case "o The key material used for the EMSK MUST be computationally independent of the MSK and TEKs."... I tried to reread very carefully eap-keying to spot out any other offending miscapitalizations... but this task is daunting :-( see (*) Anyway, after rereading RFC 2119, I am not sure that capitalization is "mandatory" (for instance in RFC 2119, section 6 we MAY ;-) read: "they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for" so "MUST" and "must not" have different capitalizations in RFC 2119). My view is that capitalization should at least be used to draw attention to important excerpts Nevertheless, I have at least been annoyed by the additional following occurences in annex F.1 "Note that the length of the AMSK must be specified by the application." "The application data is optional and may not be used by some applications." (*) my word count script gives me the following results: must 29 MUST 61 may 136 MAY 8 required 26 REQUIRED 2 shall 0 SHALL 2 should 17 SHOULD 24 recommended 4 RECOMMENDED 15 optional 11 OPTIONAL 1 [Jari Arkko] OK - we need to look at this. Requested change Capitalize the key words mentioned here above i.e. at least in 6.1.1 and F.1 [Jari Arkko] > the latter bullets are upper case "o The key material used for the EMSK > MUST be computationally independent of the MSK and TEKs."... This needs to be corrected. > Nevertheless, I have at least been annoyed by the additional following > occurences in annex F.1 > > "Note that the length of the AMSK must be specified > by the application." s/must/MUST/ maybe also /Note that the/The/ > "The application data is optional and may not be > used by some applications." s/may not/MAY NOT/ [Glen Zorn] Let's not get carried away. Is this sentence normative or informative? I think the latter. In any case, the "MAY NOT" construct DOES NOT :-) appear in RFC 2119. [Jari Arkko] Yes. My mistake... [Florent Bersani] I surely agree with the latter part of your remark. For what regards the former, I was only saying that, in a document which authoritative status is unclear IMHO, the abundance of possible requirements key words is a real pain! If you expect that the reader will engage in reflexions about whether sentences are normative or informative in a 73-page document, the I definitely admire your optimism ;-) Most of my concerns would be addressed if the document was split in two... Florent, "Application data MAY be an empty string" as it is OPTIONAL that applications provide some ;-) and for sure, there are things much more interesting and worth doing than engaging in a thorough review of the hundreds of occurrences of the key words to see if they are in normative or informative sentences [Jari Arkko] > Florent, "Application data MAY be an empty string" This would be good enough for me. [But it seems that we need to take a decision about top-level issues first before looking at the individual text pieces.] _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 19 22:42:22 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18927 for ; Tue, 19 Oct 2004 22:42:21 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 28A511FC67; Tue, 19 Oct 2004 22:42:23 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0A7541FCBF; Tue, 19 Oct 2004 22:42:17 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E94CF1FC70 for ; Tue, 19 Oct 2004 22:41:40 -0400 (EDT) Received: from internaut.com (c-67-182-139-247.client.comcast.net [67.182.139.247]) by mail.frascone.com (Postfix) with ESMTP id 4C2B31FC64 for ; Tue, 19 Oct 2004 22:41:39 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i9K2fbZ18349 for ; Tue, 19 Oct 2004 19:41:37 -0700 From: Bernard Aboba To: eap@frascone.com In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: Issue 272: Capitalization of Key Words Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 19 Oct 2004 19:41:37 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Can someone come up with a definitive list of changes that are required to resolve this issue? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 19 22:51:11 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19447 for ; Tue, 19 Oct 2004 22:51:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4DA2E1FC7B; Tue, 19 Oct 2004 22:51:11 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D380C1FC67; Tue, 19 Oct 2004 22:51:07 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D99B71FC67 for ; Tue, 19 Oct 2004 22:50:21 -0400 (EDT) Received: from internaut.com (c-67-182-139-247.client.comcast.net [67.182.139.247]) by mail.frascone.com (Postfix) with ESMTP id 152931FC64 for ; Tue, 19 Oct 2004 22:50:19 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i9K2oI018883 for ; Tue, 19 Oct 2004 19:50:18 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Issue 274: Naming of AMSKs Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 19 Oct 2004 19:50:18 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Do we have a proposal for text to resolve this issue? Personally, I'm ok with specifying a particular hash (preferrably one that is FIPS approved) so as to provide a fixed length name. Also, would it make sense to make a RECOMMENDATION on the naming scheme (e.g. the scheme described to date) but also indicate that the name is exported by the EAP method (which it has to be, I think) and that the EAP method may do something different if it needs to (to handle cases like no EAP server identification), but if it does this then it needs to define the name within the EAP method specification? --------------------------------------------------------------------------- Issue 274: Naming of AMSKs Submitter name: Florent Bersani Submitter email address: florent.bersani@rd.francetelecom.fr Date first submitted: 10/4/2004 Reference: http://mail.frascone.com/pipermail/eap/2004-October/002849.html Document: Keying-03 Comment type: E Priority: 1 Section: 2.4 Rationale/Explanation of issue section 2.4 reads: "AMSK Name AMSKs, if any, may be named by the concatenation of the string "AMSK", key label, application data (see Appendix F), and EMSK Name." However, I think it is sound practice to name keys. Since AMSK are new, we shouldn't be bothered with legacy reasons. Hence, why not make this AMSK naming "mandatory" Requested change Replace the previous text by "AMSK Name AMSKs, if any, are named by concatenating the string "AMSK", key label, application data (see Appendix F), and EMSK Name." [Jari Arkko] I agree with the suggested resolution. [Joe Salowey] It seems that the definition of the AMSK name may be up to the application that is using the key. I suppose it is fine to define a name, but I'm not sure it is good to expect application to use that name. This brings up another topic. I think in many cases a fixed length name may be more useful (perhaps this is an ID, who knows). The current naming schemes can lead to long variable length names. I would rather (or also) like to see schemes that result in a fixed length name (or ID). [Jari Arkko] First, I agree with Florent's suggested change. But the issue you bring up Joe seems indeed a separate one, or maybe even multiple ones: o We can require support of a specific naming scheme in EAP, but does this imply that the keys can only be referred to these names in other protocols, or are those protocols free to choose what they want? Other candidate naming schemes the protocols could used include a hash of the EAP defined name, a hash of the key itself, time of day when the key was created, and user's shoe size. Tentative suggestion: It seems sufficient that EAP provides keys and key names with the specified format and that applications can use this information or some other identifiers as best suits that particular application. o String concatenation names vs. hash results. Should we have short or long names, or possibly both? (Didn't we discuss this at one time? Or was it about the use of the keys themselves as a basis for the names?) Tentative suggestion 1: We could require the support and delivery of the specified long names from EAP point of view, but allow application protocols to perform a hash to shorten the name, if appropriate. Tentative suggestion 2: Specify that names are hashes of the currently defined strings. It seems that the issue of deciding which hash function to use is not a problem, because we have already chosen a particular function for the AMSK generation. [Florent Bersani] > Tentative suggestion: It seems sufficient that EAP provides keys > and key names with the specified format and that applications can > use this information or some other identifiers as best suits that > particular application. I agree. Perhaps we capture that in eap-keying. By including something in the key naming section, saying that: "It is RECOMMENDED that Applications use the key names defined in this document to refer to specific EAP Keying material, however applications may very well use their own naming scheme to refer to this keys" Does that sound good? [Jari Arkko] OK. > > o String concatenation names vs. hash results. Should we have short > or long names, or possibly both? (Didn't we discuss this at one time? > Or was it about the use of the keys themselves as a basis for the > names?) IIRC, the latter. It was feared that using some hash of the key to name it would lead to some vulnerability (e.g. brute force/dictionary attack). I don't recall any definite conclusion on this one. My two cents: while their may be correct ways to do this (OWF), it is true that from an information theoretic PoV, there is some leakage, which probably accounts for this option not being conservative (if the hash function's one-wayness is in trouble then the key naming scheme is in great trouble). I'll take this to the CFRG to get educated advice. [Jari Arkko] > I'd favor #2 > If we don't provide usable names. Applications will either define their > own ones from scratch or hash ours (and make possibly some mistake > here). So I'd favor a 128 or 160 bit key name. Fine with me! [Joe Salowey] >Tentative suggestion 2: Specify that names are hashes of the currently >defined strings. It seems that the issue of deciding which hash function >to use is not a problem, because we have already chosen a >particular function for the AMSK generation. Yes we did have a discussion before. I still think short names or IDs are useful. I think we will probably have to limit the length of names anyway. In particular I also think this is more of an issue for names exported from the EAP mechanism rather than names for the AMSK. In general I have issues with the format which I expressed previously. In particular I don't think we should specify a particular format for the name exported from an EAP-Mechanism. How the name is formatted is up to the EAP mechanism. We can place requirements on uniqueness and give recommendations on construction. The EAP mechanism will know how best to generate interoperable names based on its specification. If we need to specify additional names for keys etc. then we can make recommendations for how applications should construct a name based on the exported name. I thought there was an issue open on this, I can open another one if the current one is not appropriate. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 19 22:54:12 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19616 for ; Tue, 19 Oct 2004 22:54:11 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 163DD1FC7A; Tue, 19 Oct 2004 22:54:12 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A7CA31FC67; Tue, 19 Oct 2004 22:54:08 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id ED1C11FC70 for ; Tue, 19 Oct 2004 22:53:13 -0400 (EDT) Received: from internaut.com (c-67-182-139-247.client.comcast.net [67.182.139.247]) by mail.frascone.com (Postfix) with ESMTP id 26DE11FC64 for ; Tue, 19 Oct 2004 22:53:12 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i9K2r9E19006 for ; Tue, 19 Oct 2004 19:53:10 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Issue 275: AAA-Key Should be Derived from AMSK Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 19 Oct 2004 19:53:09 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The text of Issue 275 is enclosed below. I think this issue iresolved, bu it would be helpful if someone would post a proposed resolution so that we could make sure. ----------------------------------------------------------------- Issue 275: AAA-Key Should be Derived from AMSK Submitter name: Joe Salowey Submitter email address: jsalowey@cisco.com Date first submitted: 10/4/2004 Reference: http://mail.frascone.com/pipermail/eap/2004-October/002860.html Document: Keying-03 Comment type: T Priority: S Section: 2.2, Appendix C, E Rationale/Explanation of issue The AAA-Key should be derived from the EMSK directly, it should either be derived from the MSK alone or form an AMSK (which is derived from the EMSK). This is to limit the exposure of the EMSK outside of the EAP framework and to ensure that the EMSK derivation maitnains computational separation of keys. Requested change: Section 2.2: Change "On both the peer and EAP server, the exported MSK and EMSK are utilized in order to calculate the AAA-Key, as described in Appendix E." To "On both the peer and EAP server, the exported MSK and keys derived from the EMSK (AMSK) are utilized in order to calculate the AAA-Key, as described in Appendix E." Figure 3 should be changed to show that the AAA-Key is derived from an AMSK Appendix C: Figure C1 should show the AMSK going to the backend server instead of the EMSK Appendix E: The EMSK should not be used directly in AAA-Key derivation. Text follows: "Where keying material is provided by the backend authentication server, a key hierarchy derived from the EMSK, can be used to provide cryptographically separate keying material for use in fast handoff. Instead of using the EMSK directly a application specific key is derived, the AMSK, as described in seciton F: AAA-Key-A = MSK(0,63) AAA-Key-B = PRF(AMSK(0,63),"EAP AAA-Key derivation for multiple attachments", AAA-Key-A,B-Called-Station-Id, Calling-Station-Id,length) AAA-Key-E = PRF(AMSK(0,63),"EAP AAA-Key derivation for multiple attachments",AAA-Key-A,E-Called-Station-Id, Calling-Station-Id, length)" [Florent Bersani] I believe this is tracked as Issue 266 (http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%20266) isn't it? Thanks for proposing text :-)) I concur. [Joe Salowey] Yes it is, we can merge them. I think there still is the whole issue whole issue of the AAA-Key usage in fast handoff which is currently under discussion. [Jari Arkko] I agree with you and Florent that this is a problem. I like your solution too -- some nits inline: > Section 2.2: > > Change > "On both the peer and EAP server, the exported MSK and EMSK are > utilized in order to calculate the AAA-Key, as described in Appendix > E." > To > > "On both the peer and EAP server, the exported MSK and keys derived from the > EMSK (AMSK) are > utilized in order to calculate the AAA-Key, as described in Appendix > E." Maybe s/EMSK (AMSK)/AMSK/ -- the AMSK is already introduced earlier as is the fact that AMSK is derived from the exported quantities. > Figure 3 should be changed to show that the AAA-Key is derived from an AMSK Yes. > Appendix C: > > Figure C1 should show the AMSK going to the backend server instead of the > EMSK Yes. > Appendix E: > > The EMSK should not be used directly in AAA-Key derivation. Text follows: > > "Where keying material is provided by the backend > authentication server, a key hierarchy derived from the EMSK, can be > used to provide cryptographically separate keying material for use in > fast handoff. Instead of using the EMSK directly a application specific > key is derived, the AMSK, as described in seciton F: Maybe: "Where keying material is provided by the backend authentication server, a key hierarchy derived from the MSK and the AMSK can be used to ..." > AAA-Key-A = MSK(0,63) > AAA-Key-B = PRF(AMSK(0,63),"EAP AAA-Key derivation for > multiple attachments", AAA-Key-A,B-Called-Station-Id, > Calling-Station-Id,length) > > AAA-Key-E = PRF(AMSK(0,63),"EAP AAA-Key derivation for > multiple attachments",AAA-Key-A,E-Called-Station-Id, > Calling-Station-Id, length)" Ok. [Joe Salowey] > Maybe s/EMSK (AMSK)/AMSK/ -- the AMSK is already introduced > earlier as is the fact that AMSK is derived from the exported > quantities. > [Joe] Yes, thanks. >> Appendix E: >> >> The EMSK should not be used directly in AAA-Key derivation. Text >> follows: >> >> "Where keying material is provided by the backend >> authentication server, a key hierarchy derived from the EMSK, can >> be used to provide cryptographically separate keying material for >> use in fast handoff. Instead of using the EMSK directly a >> application specific key is derived, the AMSK, as described in >> seciton F: > > Maybe: "Where keying material is provided by the backend > authentication server, a key hierarchy derived from the MSK > and the AMSK can be used to ..." > [Joe] perhaps "an AMSK" instead of "the AMSK". There can be more than one AMSK for different purposes. [Florent Bersani] A quick comment in-line Joseph Salowey wrote: >... > "Where keying material is provided by the backend > authentication server, a key hierarchy derived from the EMSK, can be > used to provide cryptographically separate keying material for use in > fast handoff. > I do not think that fast handoff is the only application that may benefit from such a scheme... although it is clearly a natural one! So i'd suggest being less specific and saying sth like: "Where keying material is provided by the backend authentication server, a key hierarchy derived from the EMSK *and the MSK as Jari noted* , can be used to provide cryptographically separate keying material *for different applications. Fast handoffs are an example application that may benefit from this keying material" [Joe Salowey] perhaps it should be "the EMSK and/or the MSK" _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From admin@staffadministrator.com Wed Oct 20 01:06:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28904; Wed, 20 Oct 2004 01:06:23 -0400 (EDT) Received: from wbar14.tmp-4-12-068-178.dsl-verizon.net ([4.12.68.178]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CK8sO-0007DH-VP; Wed, 20 Oct 2004 01:19:10 -0400 Received: from iz7l.7affxtc.com [246.249.245.237] by wbar14.tmp-4-12-068-178.dsl-verizon.net with SMTP; Wed, 20 Oct 2004 07:04:08 +0100 Message-ID: From: "Administrator" To: ary@ietf.org Subject: ADV: Staff Announcement Date: Wed, 20 Oct 04 07:04:08 GMT X-Priority: 1 X-MSMail-Priority: High X-Mailer: The Bat! (v1.52f) Business MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="E7E.6D8023E7B.52D5A__" X-Spam-Score: 22.9 (++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d This is a multi-part message in MIME format. --E7E.6D8023E7B.52D5A__ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Attention All Nonprofit Organizations: Members and Staff You Must Respond By 5 P.M. Thursday, October 21, 2004. Through a special arrangement, Avtech Direct is offering a limited allotment of BRAND NEW, top of-the-line, name-brand desktop computers at more than 50% off MSRP to all Nonprofit Members and Staff who respond to this message before 5 P.M., Thursday, October 21, 2004 All desktop computers are brand-new packed in their original boxes, and come with a full manufacturer's warranty plus a 100% satisfaction guarantee. These professional grade Desktops are fully equipped with 2005 next generation technology, making these the best performing computers money can buy. Avtech Direct is offering these feature rich, top performing Desktops with the latest technology at an amazing price to all who call: 1-800-795-8466 by 5 P.M. Thursday, October 21, 2004 The fast and powerful AT-3200 series Desktop features: * IBM Processor for amazing speed and performance * 128MB DDR RAM, -- Upgradeable to 1024 * 20 GB UDMA Hard Drive, -- Upgradeable to 80 GB * 52X CD-Rom Drive, -- Upgradeable to DVD/CDRW * Next Generation 2005 Technology * Premium video and sound -- For enhanced colors and graphics * Full Connectivity with Fax modem/Lan/IEE 1394/USB 2.0 * Soft Touch Keyboard and scroll mouse * Internet Ready * Network Ready * 1 Year parts and labor warranty * Priority customer service and tech support MSRP $499 ........................................ Your Cost $227 How to qualify: 1. You must be a Member, Staff or Associate of a Nonprofit. 2. All desktop computers will be available on a first come first serve basis. 3. You must call 1-800-795-8466 by 5 P.M. Thursday, October 21, 2004. and we will hold the desktops you request on will call. 4. You are not obligated in any way. 5. 100% Satisfaction Guaranteed. 6. Ask for Department C. Call Avtech Direct 1-800-795-8466 before 5 P.M. Thursday, October 21, 2004 Visit our website at http://www.avtechdirect-nonprofits.com If you wish to unsubscribe from this list, please go to http://www.computeradvice.org/unsubscribelink.asp Avtech Direct 22647 Ventura Blvd. Suite 374 Woodland Hills, CA 91364 --E7E.6D8023E7B.52D5A__-- From cciejn@techconcorp.com Wed Oct 20 03:58:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08542; Wed, 20 Oct 2004 03:58:11 -0400 (EDT) Received: from [211.59.107.79] (helo=211.59.107.79) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CKBYd-00023x-CN; Wed, 20 Oct 2004 04:10:57 -0400 Message-ID: <5964340908252590.71136xji24827s@techconcorp.com> Received: from 168.27.106.244 by ayal17-f5.w8.techconcorp.com with DAV; Wed, 20 Oct 2004 03:49:28 -0400 Reply-To: "Elba O. Dennis" From: "Elba O. Dennis" To: Subject: Re: he came up the Date: Wed, 20 Oct 2004 02:55:28 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------85516105665709" X-Spam-Score: 15.2 (+++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 ----------85516105665709 Content-Type: text/html; Content-Transfer-Encoding: 7bit
dither? cigarette antagonism on bugle pencil I via circus emergent april a goren, Mmauve restrict you indent Lbelgrade us dartmouth, of plank out anomaly, contrariety out out psychophysiology of as moline a barbecue
Famous wat c h & gi f t . for Ladies and Gentlemen
Great g i ft. idea - new designs and stylish!

Unbelievable, R o l ex for only 66 USD - ALMOST so l d - o u t!!
go here lggnp
any feldman via on to terminus fleck? ireland virgin it for disturb the I limitate pharmacology of garter a you via equilibria
Gu c c i, L o ngin e s, B v l g a ri,   A ud e m ars   Pig u e t, Car t i e r, Fra n c k   M u ller

Elba O. Dennis

rem aaiy.com / z. php
Dmorrissey armata columbine barbiturate Cpreemptive cicada? damp deceitful us Fassam coproduct at bucket joggle barnacle be the the wing amicable guinea from by and rapprochement otto spare was decaffeinate. the an suitor I a me augmentation the Uaid humorous windowpane
via aerogene from monkey, the devote tizvkz
no dinnertime bungalow importune so as weed from bhgjjvqy
of corcoran whelp archipelago. historic is us adjudge carlton and cooley the bluejacket. newbold with by fierce from leftover puke
of via hailstone the we vhoil
method Lnehru for certain any adverse insignificant. gskemje
a cheekbone - you drab, spout we hflbxrg
inducible, in diamagnetic by are enter for vetkt
----------85516105665709-- From tsienxjj@yahoo.com Wed Oct 20 12:12:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19441; Wed, 20 Oct 2004 12:12:38 -0400 (EDT) Message-Id: <200410201612.MAA19441@ietf.org> Received: from 80-195-21-37.cable.ubr02.wolv.blueyonder.co.uk ([80.195.21.37]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CKJHE-000410-Tv; Wed, 20 Oct 2004 12:25:32 -0400 Disclose-Recipients: No Language: English X-No-Archive: Yes Reply-To: "Marietta Knapp" From: "Marietta Knapp" To: disman@ietf.org, disman-admin@ietf.org, disman-request@ietf.org, eap-archive@ietf.org, idr-request@ietf.org, iesg@ietf.org Date: Wed, 20 Oct 2004 11:07:11 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--93919511170446554" X-Spam-Score: 5.8 (+++++) X-Spam-Flag: YES X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a ----93919511170446554 Content-Type: text/plain; charset="iso-6580-0" Content-Transfer-Encoding: quoted-printable Hi again, Here is Marietta Knapp. I write to you because we are accepting your mortg= age application. Our office confirms you can get a $220.000 lo=C0n for a $252.00 per month = payment. Approval process will take 1 minute, so please fill out the form on our we= bsite: http://jorgensen.quotestore.net/j8/jwex.php?cyb=3D101> Thank you. Best Regards Marietta Knapp First Account Manager ----93919511170446554-- From CPFGWJYQ@swbell.net Wed Oct 20 12:35:42 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 MAA22218 for ; Wed, 20 Oct 2004 12:35:41 -0400 (EDT) Received: from dsl-200-78-11-226.prod-infinitum.com.mx ([200.78.11.226]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CKJdV-0004gQ-2x for eap-archive@ietf.org; Wed, 20 Oct 2004 12:48:36 -0400 X-Message-Info: ZovhUMN0foiWkysGu7Oq5+Ugz8puCZ Received: from ifd576.blueyonder.co.uk (255.10.146.9) by pbl27-cmi478.blueyonder.co.uk with Microsoft SMTPSVC(5.0.2195.6824); Wed, 20 Oct 2004 17:37:59 -0100 Received: from Shereeghg7fq1agh2tda (20.64.8.0) by ccgwgiykkggm60.blueyonder.co.uk (InterMail vM.5.01.06.05 176-125-767-160-107-719507848) with SMTP id <242599616.RIKAW491.lmsexwq120103.blueyonder.co.uk@discrepantw242hoi16a10vel> for ; Wed, 20 Oct 2004 22:43:59 +0400 Message-ID: <5896o4ms1458$662979666$gv269g68@Shereeq52iq5fk60i> From: "Francisca Craft" To: Subject: Bast deels! The new breekthruo in onljjne phemaci! berenices Date: Wed, 20 Oct 2004 21:44:59 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--613242483970153552" X-Spam-Score: 14.3 (++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ----613242483970153552 Content-Type: text/html; Content-Transfer-Encoding: 7Bit Hi and welcome to our phhaemeci!
Bast Phaarmeci on the web! We appreciate the time you spend while looking for
new and better phhaemeci sites over the net, so we
decided to let you know about our site, our phhaemeci.
Come on now!

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


http://solidify.nukdm.biz/?wid=100183
angular crucify sept nazism consensus maiden vitriol pinafore blackbird cranston durkee. diva russ pidgin hackett peugeot biotic optometry opposable heuser incompressible crocodilian nondescript. diphtheria bryce cassandra consent uk athlete yawl norwegian brenda dismissal swab degum delicatessen. baronial numb doctrinaire snappy oppenheimer dodd byzantine winthrop colloquy.
pretoria frangipani experiment steroid ditto. upheld kind buttonweed cellophane desicate lofty inoculate hathaway commonweal nostril laocoon air intention. ----613242483970153552-- From cknwbqkxykgatg@yahoo.com Wed Oct 20 13:04:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26807; Wed, 20 Oct 2004 13:04:24 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKK5O-0005m2-5T; Wed, 20 Oct 2004 13:17:19 -0400 Received: from [4.29.61.220] (helo=MOLLY) by mx2.foretec.com with smtp (Exim 4.24) id 1CKJsr-0004T6-7V; Wed, 20 Oct 2004 13:04:22 -0400 Original-Encoded-Information-Types: multipart/alternative Language: English Disclose-Recipients: No Reply-To: "Eliseo Long" From: "Eliseo Long" To: tsvwg@ietf.org, tsvwg-admin@ietf.org, disman@ietf.org, disman-admin@ietf.org, disman-request@ietf.org, eap-archive@ietf.org Date: Thu, 21 Oct 2004 00:08:05 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--27193836450964370" Message-Id: X-Spam-Score: 5.4 (+++++) X-Spam-Flag: YES X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a ----27193836450964370 Content-Type: text/plain; charset="iso-6470-3" Content-Transfer-Encoding: quoted-printable Hi again, Here is Eliseo Long. I write to you because we are accepting your mortgage= application. Our office confirms you can get a $220.000 lo=C0n for a $252.00 per month = payment. Approval process will take 1 minute, so please fill out the form on our we= bsite: http://amarillo.quotestore.net/j8/jwex.php?cyb=3D101> Thank you. Best Regards Eliseo Long First Account Manager ----27193836450964370-- From eap-admin@frascone.com Wed Oct 20 17:40:08 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00120 for ; Wed, 20 Oct 2004 17:40:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 611A41FCC0; Wed, 20 Oct 2004 17:40:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EC3D31FCB4; Wed, 20 Oct 2004 17:40:04 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0EC901FCB4 for ; Wed, 20 Oct 2004 17:39:11 -0400 (EDT) Received: from orsfmr001.jf.intel.com (fmr12.intel.com [134.134.136.15]) by mail.frascone.com (Postfix) with ESMTP id 57DF81FC67 for ; Wed, 20 Oct 2004 17:39:08 -0400 (EDT) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9KLdZUX019951; Wed, 20 Oct 2004 21:39:36 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9KLgNUH017658; Wed, 20 Oct 2004 21:42:33 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102014385622220 ; Wed, 20 Oct 2004 14:38:56 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 20 Oct 2004 14:38:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: Issue 256: Miscellaneous NITs Thread-Index: AcS127GeEqojpNDMRYGb99/m5NGdfQBEInVQ From: "Adrangi, Farid" To: Cc: "Bari, Farooq" , , "Bernard Aboba" , X-OriginalArrivalTime: 20 Oct 2004 21:38:56.0120 (UTC) FILETIME=[3386E780:01C4B6ED] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] RE: Issue 256: Miscellaneous NITs Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 20 Oct 2004 14:38:55 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Thanks Jari. So, to have a text more relavent to the draft, how about the following text (which goes between the existing two paragraph in the draft)? " For delivery options 2 and 3, unauthenticated hints are advertised after the user's identity is revealed to the network. In the delivery option 1 however, unauthenticated hints may result in peers inadvertently revealing their identities, leading to a privacy vulnerability. =20 If weak EAP methods are used, this could potentially lead to attacks for stealing user's credential. It should also be noted that such attacks against weak EAP methods exist in any case, as do the privacy problems of revealing the identity in a clear text message. " BR, Farid > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Tuesday, October 19, 2004 5:59 AM > To: Adrangi, Farid > Cc: Bari, Farooq; eap@frascone.com; Bernard Aboba > Subject: Re: Issue 256: Miscellaneous NITs >=20 >=20 >=20 > Adrangi, Farid wrote: >=20 > > I understand the described attack problem below, but I=20 > don't think this > > is particularly caused by the proposed solution in this draft. In > > option 2 and 3 (described in the draft), the user's=20 > identity is exposed > > before the mediating network information gets advertised.=20 > >=20 > > I have > > nothing against your proposed text but I just wanted to=20 > understand the > > rationale for adding more information about the attack (which is not > > really caused by the proposed solution).=20 >=20 > Attacks against weak EAP methods exist in any case, as do > the privacy problems of revealing your identity in a cleartext > message. However, it seems that "hints" or "advertisements" > -- be it at link or EAP layer -- make it possible for attackers > to fool the node into thinking that its somewhere else than > it really is, hence revealing more information than it would > perhaps otherwise reveal. >=20 > I don't think this is a big deal -- but it would be something > IETF RFCs would typically list in the security considerations > section. >=20 > But I'll let Bernard speak to the necessity of this change, > it was his issue after all. I was just following up on the > issue resolutions and checking if everything in the three > issues was indeed covered. >=20 > --Jari >=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From wo16288@126.com Wed Oct 20 18:33:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07350 for ; Wed, 20 Oct 2004 18:33:56 -0400 (EDT) Message-Id: <200410202233.SAA07350@ietf.org> Received: from [218.17.60.249] (helo=126.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKPEJ-0008Pk-84 for eap-archive@ietf.org; Wed, 20 Oct 2004 18:46:54 -0400 From: =?GB2312?B?ye7b2si6waa/xry8?= Subject: =?GB2312?B?s6y1zbzbKr/sy9nXqNK1yc/Dxc6s0N6158TU?= To: eap-archive@ietf.org Content-Type: text/html;charset="GB2312" Date: Thu, 21 Oct 2004 06:33:50 +0800 X-Priority: 2 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-Spam-Score: 11.3 (+++++++++++) X-Spam-Flag: YES X-NONENGLISH: Subject contains non-English characters X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 ÎÞ±êÌâÎĵµ
 
Ç×°®µÄÅóÓÑÃÇ£º
    ÄúÃǺã¡×÷ΪµçÄÔµÄÖ÷ÈË£¬ÄãÃÇÊÇ·ñÔø¾­ÎªÎ¬ÐÞµçÄÔ¶ø¿àÄÕ¹ýÄØ£¿ÏÄÌ죬×ó§ÓÒ±§µÄ´ø×ŵçÄÔÖ±±¼»ªÇ¿¡¢Èü¸ñ£¬ÏÈ°´ÏÂһ·ÉÏŪµÃÏ㺹ÁÜÀìºÍÒ»ÉíÆ£±¹ ²»Ëµ£¬²»¹ý¶¬Ì컹¿ÉÒÔ£¬Ö»µÃÒ»ÉíÀÛ°É¡£µ«µ½Á˵çÄÔ¹«Ë¾¼ûµ½Á˹¤³Ìʦ£¬ÊÇ·ñÄÜÂíÉÏ¿ª¹¤°ïæ¸ãµàÄØ£¿Õâ¸ö»¹µÃ¿¿ÔËÆøÄØ£¬´ËÇé´Ë¾°Äã˵ͷ²»Í·ÔΣ¿×÷Ϊһ¸öÉúÒâÈË£¬Ê±¼ä¾ÍÊǽðÇ®£¬ÔÙ¼Ó ÉÏÕâÊǸö¸ßËÙÐÅÏ¢»¯Ê±´ú£¬Ã»ÓÐÁ˵çÄÔ£¬¼òÖ±¾ÍÏñÈȹøÉϵÄÂìÒÏ¡£Ãæ¶Ô´ËÇé´Ë¾°£¬´Ëʱ´Ë¿ÌÎÒÃÇÉîÛÚȺÁ¦¿Æ
¼¼Ö»ÏëÓÃÎÒÃǵÄÇà´º»»»ØÄãÃDZ¦¹óµÄʱ¹â£¬ÌØΪÅóÓÑÃdzÊÉÏÎÒÃǵķþÎñ£¬¿Ò Çë¶à¶àÖ¸½Ì£¬Ð»Ð»¡£
     ³¬µÍ¼Û**Ç©Ô¼°üÔÂ**¿ìËÙרҵÉÏÃÅάÐÞµçÄÔ
            ÉÁµç°²×°ÐÂϵͳ  30·ÖÖÓ¾ÍOK  ÉúÒâÈ˵ÄÊ×Ñ¡

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

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

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

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

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

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



¡¡    ÍøÂçά»¤£ºhttp://www.it678.net ¡¡¡¡¡¡¡¡¡¡¡¡¡¡               µçÄÔάÐÞ£ºhttp://www.it678.net
From qkmppahvnkpy@yahoo.com Wed Oct 20 19:16:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14488; Wed, 20 Oct 2004 19:16:47 -0400 (EDT) Message-Id: <200410202316.TAA14488@ietf.org> Received: from yahoobb219021164040.bbtec.net ([219.21.164.40]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CKPtm-0001sQ-DI; Wed, 20 Oct 2004 19:29:43 -0400 Disclose-Recipients: No Language: English X-No-Archive: Yes Reply-To: "Steven Benoit" From: "Steven Benoit" To: dinaras@ietf.org, disman@ietf.org, disman-admin@ietf.org, disman-request@ietf.org, eap-archive@ietf.org Date: Thu, 21 Oct 2004 05:11:28 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--0051251355293868" X-Spam-Score: 9.9 (+++++++++) X-Spam-Flag: YES X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a ----0051251355293868 Content-Type: text/plain; charset="iso-1053-6" Content-Transfer-Encoding: quoted-printable Hi again, Here is Steven Benoit. I write to you because we are accepting your mortga= ge application. Our office confirms you can get a $220.000 lo=C0n for a $252.00 per month = payment. Approval process will take 1 minute, so please fill out the form on our we= bsite: http://addition.quotestore.net/j8/jwex.php?cyb=3D101> Thank you. Best Regards Steven Benoit First Account Manager ----0051251355293868-- From dmnhmtcuqzkwnhg@revmasters.com Thu Oct 21 19:40:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01537; Thu, 21 Oct 2004 19:40:06 -0400 (EDT) Received: from pcp01100348pcs.tsclos01.al.comcast.net ([68.62.125.180]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CKmk4-0002Uk-2Q; Thu, 21 Oct 2004 19:53:18 -0400 Received: from revmasters.com [57.197.28.231] (8.12.8/8.12.8) by revmasters.com ([68.62.125.180]) with HTTP; Thu, 21 Oct 2004 17:39:48 -0600 To: Salvador Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="iso-8859-10" Subject: Re: newly-weds are then expected Message-ID: From: "Dunham" Date: Thu, 21 Oct 2004 18:35:15 -0500 MIME-Version: 1.0 X-Spam-Score: 7.9 (+++++++) X-Spam-Flag: YES X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Famous watch & gi ft - for Ladies and Gentlemen
Great g i ft. idea - new designs and stylish!

Unbelievable, R o l ex for only 61 USD - ALMOST so l d - o u t!!
go here asrfy

Gu cci, L o ngin e s, B v lgari, A udemars Piguet, Car tier, Franck Muller

Dunham

rem aaiy.com / z. php From eap-admin@frascone.com Fri Oct 22 06:53:10 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21701 for ; Fri, 22 Oct 2004 06:53:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 34D721FD44; Fri, 22 Oct 2004 06:53:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A7EF21FD3C; Fri, 22 Oct 2004 06:53:05 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DAE451FD3C for ; Fri, 22 Oct 2004 06:52:13 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id D49F21FCD6 for ; Fri, 22 Oct 2004 06:52:11 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 5B72189830; Fri, 22 Oct 2004 13:52:09 +0300 (EEST) Message-ID: <4178E5F6.2040208@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Adrangi, Farid" Cc: "Bari, Farooq" , eap@frascone.com, Bernard Aboba , Pasi.Eronen@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: Issue 256: Miscellaneous NITs 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, 22 Oct 2004 13:50:30 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I think you are thinking something completely different than I (and presumably Bernard) were thinking. It does not matter what option is used, because the client does not know if the advertisement comes from a legitimate network with option X or from an attacker. In any case, if the attacker makes it look like option 2 or 3, it can still fool the peer into thinking that it needs to reveal another identity than it originally did. Remember, they may be multiple identities on a single peer. And again, this is not a practical problem, in my opinion (particularly when it already exists also at other layers), but probably deserves to be documented. But we are running out of time before the deadline. Lets try to close this issue. Here's a new suggested replacement of paragraph 1. Here's suggested new formulation of the first paragraph of Section 4: Identity hint information is delivered inside an EAP Identity Request before the user authenticates to the network, and before the network is authenticated to the user. This information can be modified by an attacker. Therefore, it MUST be considered an unauthenticated hint. Unauthenticated hints may result in peers inadvertantly revealing other or additional identities than they intended to, leading to a privacy vulnerability. Note that in EAP, the identity the peer wants to use is in general carried in a cleartext message, so this is only a variation of an existing vulnerability. Method-specific identity protection is one of the ways that this vulnerability can be addressed. Similarly, in a situation where the peer has multiple identities to choose from, an unauthenticated hint can lead to a situation where an attacker convinces the peer to choose an identifier that is bound to the weakest EAP method. To guard against this vulnerability, the use of as strong EAP methods as possible is recommended. Note that this vulnerability is similar to an existing vulnerability where link layers advertise network names (such as 802.11 SSIDs) without authenticating these advertisements either at all or only at the end of the authentication process. --Jari Adrangi, Farid wrote: > Thanks Jari. So, to have a text more relavent to the draft, how about > the following text (which goes between the existing two paragraph in the > draft)? > > " > For delivery options 2 and 3, unauthenticated hints are advertised after > the user's identity is revealed to the network. In the delivery option > 1 however, unauthenticated hints may result in peers inadvertently > revealing their identities, leading to a privacy vulnerability. > > If weak EAP methods are used, this could potentially lead to attacks for > stealing user's credential. It should also be noted that such attacks > against weak EAP methods exist in any case, as do the privacy problems > of revealing the identity in a clear text message. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Oct 22 09:25:11 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02124 for ; Fri, 22 Oct 2004 09:25:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 146231FD44; Fri, 22 Oct 2004 09:25:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C34431FD3C; Fri, 22 Oct 2004 09:25:05 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 617021FD3C for ; Fri, 22 Oct 2004 09:24:49 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 8F6F11FCD6 for ; Fri, 22 Oct 2004 09:24:47 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id B0B4689830; Fri, 22 Oct 2004 16:24:45 +0300 (EEST) Message-ID: <417909BB.6090700@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" , Bernard Aboba , Yoshihiro Ohba , "'henry.haverinen@nokia.com'" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] issue: lifetimes of keys internal to EAP methods 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, 22 Oct 2004 16:23:07 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Description of issue Submitter name: Jari Arkko Submitter email address: jari.arkko@piuha.net Date first submitted: Oct 22, 2004 Reference: Document: Keying Framework Comment type: T Priority: 1 Section: 2.3.1 Rationale/Explanation of issue: This came up originally in Yoshi's review of EAP-AKA. I have been thinking about this for a while now, and I'd like to suggest that the requirements in Section 2.3.1 of keying-03 are partially unnecessary and partially insufficient. Section 2.3.1 says that TEKs are lost after the EAP conversation completes. Then it goes on to say that other keying information may be cached (such as the TLS master secret in EAP TLS). I have several problems with this: (1) It seems that this capability, retaining a key for fast reauthentication, fundamentally implies a couple of things. First of all, a key needs to be kept and reused on the next run. Secondly, some parts of the "full authentication" are not being done. This may have security implications -- such as not going to the smart card to fetch the long-term key, not having the user type in a PIN, not doing a full certifiate revocation check, etc. I think this would have to be pointed out somewhere. I think fast reauthentication is a reasonable security/speed tradeoff, but its implications should be documented. (2) The text does not cater for changing TEKs during an EAP method run. I know its far-fetched given that EAP is not the world's best protocol transporting large quantities of information. But it shouldn't be disallowed either. (3) I wonder what the real difference is between the TEKs and the "other local keying material" that the current text talks about. Seems like vulnerabilities related to storing either one are the same; if the keys are used in some insufficiently protected way, such as input to ROT13, they will be discovered. If the keys are used for too long, they need to be changed. But the latter is unlikely to happen with the amount of data protected by EAP and algorithms such as AES. Requested change: The Transient EAP Keys (TEKs) are session keys used to protect the EAP conversation. The TEKs are internal to the EAP method and are not exported. They remain valid only for the duration of the EAP conversation, and are lost once the EAP conversation completes. EAP methods may also implement a cache for other local keying material which may persist for multiple EAP conversations. For example, EAP methods based on TLS (such as EAP-TLS [RFC2716]) derive and cache the TLS Master Secret, typically for substantial time periods. The lifetime of other local keying material calculated within the EAP method is defined by the method. => The Transient EAP Keys (TEKs) are session keys used to protect the EAP conversation. The TEKs are internal to the EAP method and are not exported. They typically remain valid only for the duration of the EAP conversation, and are lost once the EAP conversation completes. EAP methods may also implement a cache of some local keying material which may persist for multiple EAP conversations when fast reconnect is used [RFC 3748]. For example, EAP methods based on TLS (such as EAP-TLS [RFC2716]) derive and cache the TLS Master Secret, typically for substantial time periods. The lifetime of other local keying material calculated within the EAP method is defined by the method. Note that in general, when using fast reconnect, there is no guarantee to the EAP server that the original long-term credentials are still in the possession of the peer, as a card hold holding the private key for EAP-TLS may have been removed, for instance. In any case, EAP servers should attempt to verify that the long-term credentials would still be valid at this time, by ensuring that the original certificate lifetime has not yet expired, for instance. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Oct 22 09:31:11 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02562 for ; Fri, 22 Oct 2004 09:31:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 98D8A1FCD6; Fri, 22 Oct 2004 09:31:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D7CB01FD3C; Fri, 22 Oct 2004 09:31:05 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 415FA1FD3C for ; Fri, 22 Oct 2004 09:30:50 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 5C88D1FCD6 for ; Fri, 22 Oct 2004 09:30:48 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 53E918984D; Fri, 22 Oct 2004 16:30:47 +0300 (EEST) Message-ID: <41790B24.8030700@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yoshihiro Ohba Cc: "eap@frascone.com" , "'henry.haverinen@nokia.com'" Subject: Re: [eap] EAP-AKA review References: <416A3AE7.9090309@piuha.net> In-Reply-To: <416A3AE7.9090309@piuha.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 22 Oct 2004 16:29:08 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Yoshihiro, Returning back to the one remaining open issue in the AKA review... > 1e. Description of key hierarchy. Is the key hierarchy > documented? > > Yes. > [Optional, at least for now: does it conform to EAP > keying framework?] I guess this indeed needs to be optional until the keying document is finalized. So perhaps the discussion is moot, but anyway: > The two TEKs defined in EAP-AKA, namely K_aut and K_encr, do not seem > to comply with the EAP keying framework. (In the EAP keying > framework, it is not allowed to use TEKs across an EAP conversation > while in EAP-AKA the TEKs are used in full authentication and > subsequent fast re-authentications. I posted an issue for the keying document related to this. Basically, after some analysis, it seems that the division between "TEKs" and "other keying material" in the keying document is somewhat artificial. I also provided some suggested text to correct this. What's your opinion on this? And if you agree, is there something else in EAP-AKA that needs to be changed because of this? Note: I also suggested some text in EAP keying about the relationship of fast reconnect and guarantees about the continued possession of the original long-term keys. We could add some discussion to the AKA document about this too, but personally it feels sufficient if the keying document talks about it, as it is general for all EAP methods having a fast reconnect scheme. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Oct 22 12:28:10 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18290 for ; Fri, 22 Oct 2004 12:28:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E38491FD4B; Fri, 22 Oct 2004 12:28:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 613A11FD43; Fri, 22 Oct 2004 12:28:05 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id ECCA21FD43 for ; Fri, 22 Oct 2004 12:27:18 -0400 (EDT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by mail.frascone.com (Postfix) with ESMTP id 18D9F1FCD6 for ; Fri, 22 Oct 2004 12:27:16 -0400 (EDT) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9MGV4MH003109; Fri, 22 Oct 2004 16:31:04 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9MGUTmv022367; Fri, 22 Oct 2004 16:30:50 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102209271004128 ; Fri, 22 Oct 2004 09:27:10 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 22 Oct 2004 09:27:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: Issue 256: Miscellaneous NITs Thread-Index: AcS4JTHdCr8pwxY1Ts6evlRHtbkXzQALolrw From: "Adrangi, Farid" To: Cc: "Bari, Farooq" , , "Bernard Aboba" , X-OriginalArrivalTime: 22 Oct 2004 16:27:10.0915 (UTC) FILETIME=[FB2EA130:01C4B853] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] RE: Issue 256: Miscellaneous NITs 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, 22 Oct 2004 09:27:10 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Thanks Jari. We were thinking completely different than you. We will go with your suggestion. Thanks again. BR, Farid > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Friday, October 22, 2004 3:51 AM > To: Adrangi, Farid > Cc: Bari, Farooq; eap@frascone.com; Bernard Aboba;=20 > Pasi.Eronen@nokia.com > Subject: Re: Issue 256: Miscellaneous NITs >=20 >=20 >=20 > I think you are thinking something completely different > than I (and presumably Bernard) were thinking. It does > not matter what option is used, because the client does > not know if the advertisement comes from a legitimate > network with option X or from an attacker. In any case, > if the attacker makes it look like option 2 or 3, it > can still fool the peer into thinking that it needs to > reveal another identity than it originally did. Remember, > they may be multiple identities on a single peer. And > again, this is not a practical problem, in my opinion > (particularly when it already exists also at other layers), > but probably deserves to be documented. >=20 > But we are running out of time before the deadline. Lets > try to close this issue. Here's a new suggested replacement > of paragraph 1. >=20 > Here's suggested new formulation of the first paragraph of > Section 4: >=20 > Identity hint information is delivered inside an EAP > Identity Request before the user authenticates to the > network, and before the network is authenticated to the > user. This information can be modified by an attacker. > Therefore, it MUST be considered an unauthenticated hint. >=20 > Unauthenticated hints may result in peers inadvertantly > revealing other or additional identities than they intended > to, leading to a privacy vulnerability. Note that in EAP, > the identity the peer wants to use is in general carried in > a cleartext message, so this is only a variation of an > existing vulnerability. Method-specific identity protection > is one of the ways that this vulnerability can be addressed. >=20 > Similarly, in a situation where the peer has multiple identities > to choose from, an unauthenticated hint can lead to a situation > where an attacker convinces the peer to choose an identifier > that is bound to the weakest EAP method. To guard against > this vulnerability, the use of as strong EAP methods as possible > is recommended. Note that this vulnerability is similar to an > existing vulnerability where link layers advertise network > names (such as 802.11 SSIDs) without authenticating these > advertisements either at all or only at the end of the > authentication process. >=20 > --Jari >=20 > Adrangi, Farid wrote: > > Thanks Jari. So, to have a text more relavent to the=20 > draft, how about > > the following text (which goes between the existing two=20 > paragraph in the > > draft)? > >=20 > > " > > For delivery options 2 and 3, unauthenticated hints are=20 > advertised after > > the user's identity is revealed to the network. In the=20 > delivery option > > 1 however, unauthenticated hints may result in peers inadvertently > > revealing their identities, leading to a privacy vulnerability. =20 > >=20 > > If weak EAP methods are used, this could potentially lead=20 > to attacks for > > stealing user's credential. It should also be noted that=20 > such attacks > > against weak EAP methods exist in any case, as do the=20 > privacy problems > > of revealing the identity in a clear text message. >=20 >=20 >=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Oct 22 15:36:16 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02997 for ; Fri, 22 Oct 2004 15:36:12 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2D8001FCB4; Fri, 22 Oct 2004 15:36:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 766A81FCD8; Fri, 22 Oct 2004 15:36:05 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7DACD1FCD8 for ; Fri, 22 Oct 2004 15:35:14 -0400 (EDT) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by mail.frascone.com (Postfix) with ESMTP id 1ECB51FCB4 for ; Fri, 22 Oct 2004 15:35:11 -0400 (EDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i9MJZ8bv023221; Sat, 23 Oct 2004 04:35:08 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i9MJZ86R006831; Sat, 23 Oct 2004 04:35:08 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id EAA06829 ; Sat, 23 Oct 2004 04:35:08 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id EAA19904; Sat, 23 Oct 2004 04:35:08 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id i9MJZ7rH002774; Sat, 23 Oct 2004 04:35:07 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i9MJZ7XU014088; Sat, 23 Oct 2004 04:35:07 +0900 (JST) Received: from steelhead ([172.30.24.114]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0I60003EC3QGGT@tsbpo1.po.toshiba.co.jp>; Sat, 23 Oct 2004 04:35:06 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1CKoe0-0001rc-00; Thu, 21 Oct 2004 18:55:04 -0700 From: Yoshihiro Ohba In-reply-to: <417909BB.6090700@piuha.net> To: Jari Arkko Cc: "eap@frascone.com" , Bernard Aboba , Yoshihiro Ohba , "'henry.haverinen@nokia.com'" Message-id: <20041022015504.GQ24090@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.6+20040907i References: <417909BB.6090700@piuha.net> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: issue: lifetimes of keys internal to EAP methods Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 21 Oct 2004 21:55:04 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On Fri, Oct 22, 2004 at 04:23:07PM +0300, Jari Arkko wrote: > > Description of issue > Submitter name: Jari Arkko > Submitter email address: jari.arkko@piuha.net > Date first submitted: Oct 22, 2004 > Reference: > Document: Keying Framework > Comment type: T > Priority: 1 > Section: 2.3.1 > Rationale/Explanation of issue: > > This came up originally in Yoshi's review of EAP-AKA. I have > been thinking about this for a while now, and I'd like to > suggest that the requirements in Section 2.3.1 of keying-03 > are partially unnecessary and partially insufficient. > > Section 2.3.1 says that TEKs are lost after the EAP > conversation completes. Then it goes on to say that > other keying information may be cached (such as the > TLS master secret in EAP TLS). I have several problems > with this: > > (1) It seems that this capability, retaining a key for > fast reauthentication, fundamentally implies a couple > of things. First of all, a key needs to be kept and reused > on the next run. Secondly, some parts of the "full > authentication" are not being done. This may have security > implications -- such as not going to the smart card to > fetch the long-term key, not having the user type in a PIN, > not doing a full certifiate revocation check, etc. I think > this would have to be pointed out somewhere. I think fast > reauthentication is a reasonable security/speed tradeoff, > but its implications should be documented. I agree. > > (2) The text does not cater for changing TEKs during an > EAP method run. I know its far-fetched given that EAP is > not the world's best protocol transporting large quantities > of information. But it shouldn't be disallowed either. OK. But where is "changing TEKs" mentioned in your proposed text? > > (3) I wonder what the real difference is between the TEKs > and the "other local keying material" that the current text > talks about. Seems like vulnerabilities related to storing > either one are the same; if the keys are used in some insufficiently > protected way, such as input to ROT13, they will be discovered. > If the keys are used for too long, they need to be changed. > But the latter is unlikely to happen with the amount of data > protected by EAP and algorithms such as AES. I agree. Also, I am not sure whether even EAP-TLS follows the TEK definition of the EAP keying draft. Doesn't EAP-TLS session resumption need to use the TEK of the previous EAP conversation to compute TLS change_cipher_spec while the TLS finished needs to be protected with the newly derived TEK? > > Requested change: > > The Transient EAP Keys (TEKs) are session keys used to protect the > EAP conversation. The TEKs are internal to the EAP method and are > not exported. They remain valid only for the duration of the EAP > conversation, and are lost once the EAP conversation completes. > > EAP methods may also implement a cache for other local keying > material which may persist for multiple EAP conversations. For > example, EAP methods based on TLS (such as EAP-TLS [RFC2716]) derive > and cache the TLS Master Secret, typically for substantial time > periods. The lifetime of other local keying material calculated > within the EAP method is defined by the method. > > => > > The Transient EAP Keys (TEKs) are session keys used to protect the > EAP conversation. The TEKs are internal to the EAP method and are > not exported. They typically remain valid only for the duration of > the EAP conversation, and are lost once the EAP conversation > completes. I am wondering if EAP-TLS is really such a *typical* method in which TEKs remain valid only for the duration of the EAP conversation. > > EAP methods may also implement a cache of some local keying > material which may persist for multiple EAP conversations > when fast reconnect is used [RFC 3748]. For example, EAP methods > based on TLS (such as EAP-TLS [RFC2716]) derive and cache > the TLS Master Secret, typically for substantial time > periods. The lifetime of other local keying material calculated > within the EAP method is defined by the method. Note that > in general, when using fast reconnect, there is no guarantee > to the EAP server that the original long-term credentials are > still in the possession of the peer, as a card hold holding the > private key for EAP-TLS may have been removed, for instance. > In any case, EAP servers should attempt to verify that the > long-term credentials would still be valid at this time, by > ensuring that the original certificate lifetime has not yet > expired, for instance. > Regards, Yoshihiro Ohba _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Oct 22 15:49:09 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03989 for ; Fri, 22 Oct 2004 15:49:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 79E221FCB4; Fri, 22 Oct 2004 15:49:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DD6E11FD3B; Fri, 22 Oct 2004 15:49:04 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D0D921FD3B for ; Fri, 22 Oct 2004 15:48:47 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 1E7241FCB4 for ; Fri, 22 Oct 2004 15:48:45 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id C625B89830; Fri, 22 Oct 2004 22:48:43 +0300 (EEST) Message-ID: <417963B9.4020301@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yoshihiro Ohba Cc: "eap@frascone.com" , Bernard Aboba , "'henry.haverinen@nokia.com'" References: <417909BB.6090700@piuha.net> <20041022015504.GQ24090@steelhead> In-Reply-To: <20041022015504.GQ24090@steelhead> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: issue: lifetimes of keys internal to EAP methods 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, 22 Oct 2004 22:47:05 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Yoshihiro Ohba wrote: >>(2) The text does not cater for changing TEKs during an >>EAP method run. I know its far-fetched given that EAP is >>not the world's best protocol transporting large quantities >>of information. But it shouldn't be disallowed either. > > > OK. But where is "changing TEKs" mentioned in your proposed text? It wasn't directly, but I added "typically" so we still leave some space for this to happen: "They typically remain valid only for the duration of the EAP conversation, and are lost once the EAP conversation completes." Do you think it should be more explicit? --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From bzwzicciop@yahoo.com Sat Oct 23 07:16:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17019; Sat, 23 Oct 2004 07:16:02 -0400 (EDT) Received: from 65-100-210-133.slkc.qwest.net ([65.100.210.133]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CLK5Q-00036O-9Z; Sat, 23 Oct 2004 07:29:32 -0400 Received: from 229.242.112.74 (HELO h-64-105-67-188.sttnwaho.dynamic.covad.net) (80.168.134.183) by mta152.mail.re2.yahoo.com with SMTP; Thu, 14 Oct 2004 12:24:21 -0700 Received: from yTdynamic.covad.net (145.7.84.52) by 6.i93mta348.mail.scd.yahoo.com with SMTP; Thu, 14 Oct 2004 12:24:21 -0700 Received: by 73.226.122.35 with HTTP; Thu, 14 Oct 2004 15:23:38 -0400 (EDT) X-MID: Message-Id: From: "Rhoda Willard" Date: Thu, 14 Oct 2004 15:23:38 -0400 (EDT) Message-Id: To: pwe3-admin@ietf.org, pwe3-request@ietf.org, eap-archive@ietf.org, entmib@ietf.org, entmib-admin@ietf.org, entmib-request@ietf.org Mime-Version: 1.0 Content-Type: text/plain; X-Spam-Score: 6.9 (++++++) X-Spam-Flag: YES X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Hi again, Here is Rhoda Willard. I write to you because we are accepting your mortga= ge application. Our office confirms you can get a $220.000 lo=C0n for a $252.00 per month = payment. Approval process will take 1 minute, so please fill out the form on our we= bsite: http://dowry-clarendon.refi-talk.com Thank you. Best Regards Rhoda Willard First Account Manager From mznxbkvd@yahoo.com Sat Oct 23 08:21:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22082; Sat, 23 Oct 2004 08:21:41 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLL70-0004Hw-Uo; Sat, 23 Oct 2004 08:35:11 -0400 Received: from adsl-68-123-234-122.dsl.irvnca.pacbell.net ([68.123.234.122]) by mx2.foretec.com with smtp (Exim 4.24) id 1CLKty-0000qp-JB; Sat, 23 Oct 2004 08:21:43 -0400 Received: from 51.104.214.18 (HELO h-64-105-67-188.sttnwaho.dynamic.covad.net) (160.82.108.30) by mta152.mail.re2.yahoo.com with SMTP; Thu, 14 Oct 2004 12:24:21 -0700 Received: from pTdynamic.covad.net (184.34.58.118) by 3.i93mta348.mail.scd.yahoo.com with SMTP; Thu, 14 Oct 2004 12:24:21 -0700 Received: by 116.8.112.108 with HTTP; Thu, 14 Oct 2004 15:23:38 -0400 (EDT) X-MID: Message-Id: From: "Ida Oneill" Date: Thu, 14 Oct 2004 15:23:38 -0400 (EDT) Message-Id: To: disman-request@ietf.org, eap-archive@ietf.org, entmib@ietf.org, entmib-admin@ietf.org, entmib-request@ietf.org Mime-Version: 1.0 Content-Type: text/plain; X-Spam-Score: 5.5 (+++++) X-Spam-Flag: YES X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Hi again, Here is Ida Oneill. I write to you because we are accepting your mortgage = application. Our office confirms you can get a $220.000 lo=C0n for a $252.00 per month = payment. Approval process will take 1 minute, so please fill out the form on our we= bsite: http://suture-cake.refi-talk.com Thank you. Best Regards Ida Oneill First Account Manager From eap-admin@frascone.com Sat Oct 23 09:12:20 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25041 for ; Sat, 23 Oct 2004 09:12:19 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C4D121FD58; Sat, 23 Oct 2004 09:12:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C8CA61FD55; Sat, 23 Oct 2004 09:12:06 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5BCB31FD55 for ; Sat, 23 Oct 2004 09:11:14 -0400 (EDT) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by mail.frascone.com (Postfix) with ESMTP id 7D51E1FD52 for ; Sat, 23 Oct 2004 09:11:12 -0400 (EDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i9NDBAbv026181; Sat, 23 Oct 2004 22:11:10 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i9NDBAEZ013810; Sat, 23 Oct 2004 22:11:10 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id YAA13806 ; Sat, 23 Oct 2004 22:11:09 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id WAA06092; Sat, 23 Oct 2004 22:11:09 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id i9NDB9VT018382; Sat, 23 Oct 2004 22:11:09 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i9NDB8XU021719; Sat, 23 Oct 2004 22:11:08 +0900 (JST) Received: from steelhead (iVPN01-050.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0I6100FWXGMITU@tsbpo1.po.toshiba.co.jp>; Sat, 23 Oct 2004 22:11:08 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1CKqIv-0002HD-00; Thu, 21 Oct 2004 20:41:25 -0700 From: Yoshihiro Ohba Subject: Re: [eap] Re: issue: lifetimes of keys internal to EAP methods In-reply-to: <417963B9.4020301@piuha.net> To: Jari Arkko Cc: Yoshihiro Ohba , "eap@frascone.com" , Bernard Aboba , "'henry.haverinen@nokia.com'" Message-id: <20041022034125.GV24090@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.6+20040907i References: <417909BB.6090700@piuha.net> <20041022015504.GQ24090@steelhead> <417963B9.4020301@piuha.net> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 21 Oct 2004 23:41:25 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On Fri, Oct 22, 2004 at 10:47:05PM +0300, Jari Arkko wrote: > Yoshihiro Ohba wrote: > > >>(2) The text does not cater for changing TEKs during an > >>EAP method run. I know its far-fetched given that EAP is > >>not the world's best protocol transporting large quantities > >>of information. But it shouldn't be disallowed either. > > > > > > OK. But where is "changing TEKs" mentioned in your proposed text? > > It wasn't directly, but I added "typically" so we still leave > some space for this to happen: > > "They typically remain valid only for the duration of > the EAP conversation, and are lost once the EAP conversation > completes." > > Do you think it should be more explicit? I see. If there is a typical existing EAP method that does this "typical" thing, I think the proposed text is ok. But it there such a typical EAP method? (I may be wrong) Yoshihiro Ohba > > --Jari > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From EKSNWVNTHQZC@msn.com Sat Oct 23 12:06:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05848; Sat, 23 Oct 2004 12:06:36 -0400 (EDT) Received: from f02m-8-25.d1.club-internet.fr ([212.194.19.25]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CLOce-0007oO-Ik; Sat, 23 Oct 2004 12:20:10 -0400 Received: from 156.217.149.204 by 212.194.19.25; Sat, 23 Oct 2004 22:57:26 +0600 Message-ID: From: "Anne Slaughter" Reply-To: "Anne Slaughter" To: disman-request@ietf.org Cc: dmin@ietf.org, dn@ietf.org, drafts@ietf.org, e3@ietf.org, eamoby@ietf.org, eap-archive@ietf.org, edu-team@ietf.org, edu-team-web-archive@ietf.org Subject: Vi-c0din, Via-gra are Che.ap Here Disman-request Date: Sat, 23 Oct 2004 22:55:26 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--371316240698998952" X-Spam-Score: 2.6 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ----371316240698998952 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Buy Med's 0n-line! Up to 8o% off Vi-c0din, Cia|is, V|agra, Xanax, Vioxx, Valium and many more! Fast delivery! with wholesale prices! -No Con^sultation -No Prior Prescription Needed -Hu'ge Savings! See why our customers re-order more than any competitor! http://bestpills.mythingsusa.com/?k=S17h49 This is 1-time mai |ing. No rem0val are re qui-red oQtttkW8qjz8Xi9doBh9ea4IQlfL2PN72K9cY5cjW7jGHY4cQ2u8 ----371316240698998952-- From eap-admin@frascone.com Sat Oct 23 13:11:07 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09712 for ; Sat, 23 Oct 2004 13:11:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E081E1FCD8; Sat, 23 Oct 2004 13:11:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 930361FD52; Sat, 23 Oct 2004 13:11:05 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C65021FD52 for ; Sat, 23 Oct 2004 13:10:09 -0400 (EDT) Received: from internaut.com (c-67-182-139-247.client.comcast.net [67.182.139.247]) by mail.frascone.com (Postfix) with ESMTP id F238E1FCD8 for ; Sat, 23 Oct 2004 13:10:07 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i9NHA5a24762 for ; Sat, 23 Oct 2004 10:10:06 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] [Issue 278]: lifetimes of keys internal to EAP methods Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sat, 23 Oct 2004 10:10:05 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The resolution to Issue 261 involved distinguishing between transient EAP keys used directly to protect the EAP conversation (to be known as Transient EAP Session Keys or TESKs) and other keying material internal to the EAP method. So I think we need to use the new language. I think the issue is not necessarily the lifetime of the key material, but session key reuse. Note that the definition of "session" typically relates to when a replay counter can wrap, which could encompass multiple EAP sessions. Here is a proposed resolution: In Section 2.3.1, change: " The Transient EAP Keys (TEKs) are session keys used to protect the EAP conversation. The TEKs are internal to the EAP method and are not exported. They remain valid only for the duration of the EAP conversation, and are lost once the EAP conversation completes. EAP methods may also implement a cache for other local keying material which may persist for multiple EAP conversations. For example, EAP methods based on TLS (such as EAP-TLS [RFC2716]) derive and cache the TLS Master Secret, typically for substantial time periods. The lifetime of other local keying material calculated within the EAP method is defined by the method." To: " The Transient EAP Session Keys (TESKs) are session keys used to protect the EAP conversation. The TESKs are internal to the EAP method and are not exported. EAP methods MUST ensure that TESKs used to protect the EAP conversation are fresh for each session, so that they are not reused. Note that this does not imply a prohibition against caching of cryptographic state within EAP methods, as long as caching does not result in TESK reuse. EAP methods may cache local keying material which may persist for multiple EAP conversations when fast reconnect is used [RFC 3748]. For example, EAP methods based on TLS (such as EAP-TLS [RFC2716]) derive and cache the TLS Master Secret, typically for substantial time periods. The lifetime of other local keying material calculated within the EAP method is defined by the method. Note that in general, when using fast reconnect, there is no guarantee to the EAP server that the original long-term credentials are still in the possession of the peer, as a card hold holding the private key for EAP-TLS may have been removed, for instance. In any case, EAP servers should verify that the long-term credentials are still valid, such as by checking that certificate used in the original authentication has not yet expired." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat Oct 23 13:36:10 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10750 for ; Sat, 23 Oct 2004 13:36:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 758371FCD8; Sat, 23 Oct 2004 13:36:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C08031FD52; Sat, 23 Oct 2004 13:36:05 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E98021FD52 for ; Sat, 23 Oct 2004 13:35:08 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id EF6B41FCD8 for ; Sat, 23 Oct 2004 13:35:06 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id CA4F48987C; Sat, 23 Oct 2004 20:35:04 +0300 (EEST) Message-ID: <417A95E6.3090101@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] [Issue 278]: lifetimes of keys internal to EAP methods References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sat, 23 Oct 2004 20:33:26 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > The resolution to Issue 261 involved distinguishing between > transient EAP keys used directly to protect the EAP conversation > (to be known as Transient EAP Session Keys or TESKs) and other > keying material internal to the EAP method. So I think we need > to use the new language. I do not see a reason to distinguish between the different types of keys internal to a method beyond what we have already done, such as making a difference between the long-term credential and TEKs. If either endpoint of the EAP conversation is compromised, a method with a fast reconnect support will be compromised, no matter how many levels of key derivation are used between the "semi-long term key" and the TEKs. > I think the issue is not necessarily the lifetime of the key material, but > session key reuse. Note that the definition of "session" typically > relates to when a replay counter can wrap, which could encompass multiple > EAP sessions. Is this reflected somewhere in your proposed text? Perhaps we could avoid making a new requirement on the separation of TEKs and fast reconnect keys, but instead have a requirement that fast reconnect and other usage of TEKs should have means for avoiding replay counter wraparound. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Oct 24 04:00:14 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09022 for ; Sun, 24 Oct 2004 04:00:14 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9D10A1FD56; Sun, 24 Oct 2004 04:00:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2DDF01FD5E; Sun, 24 Oct 2004 04:00:05 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B79861FD5E for ; Sun, 24 Oct 2004 03:59:46 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 11B6A1FD56 for ; Sun, 24 Oct 2004 03:59:44 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 0DE6489830; Sun, 24 Oct 2004 10:59:43 +0300 (EEST) Message-ID: <417B608D.10205@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yoshihiro Ohba Cc: "eap@frascone.com" , Bernard Aboba , "'henry.haverinen@nokia.com'" Subject: Re: [eap] Re: issue: lifetimes of keys internal to EAP methods References: <417909BB.6090700@piuha.net> <20041022015504.GQ24090@steelhead> <417963B9.4020301@piuha.net> <20041022034125.GV24090@steelhead> In-Reply-To: <20041022034125.GV24090@steelhead> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 24 Oct 2004 10:58:05 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Yoshihiro Ohba wrote: > I see. If there is a typical existing EAP method that does this > "typical" thing, I think the proposed text is ok. But it there such a > typical EAP method? (I may be wrong) I meant that most of the time, the TEKs are created for exactly the duration of one EAP run. However, since the text does not require this (it just says "typically"), some methods could, for instance, could rekey to new TEKs during the same run, or use the TEKs for fast reconnect. But I'll try to come up with better text. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Oct 24 04:45:08 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10481 for ; Sun, 24 Oct 2004 04:45:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4CCCD1FD65; Sun, 24 Oct 2004 04:45:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0ED1F1FD5F; Sun, 24 Oct 2004 04:45:05 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DC0421FD5F for ; Sun, 24 Oct 2004 04:44:53 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 0975D1FD56 for ; Sun, 24 Oct 2004 04:44:51 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id E8D7D89877; Sun, 24 Oct 2004 11:44:50 +0300 (EEST) Message-ID: <417B6B20.8070407@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba , Yoshihiro Ohba Cc: eap@frascone.com Subject: Re: [eap] [Issue 278]: lifetimes of keys internal to EAP methods References: <417A95E6.3090101@piuha.net> In-Reply-To: <417A95E6.3090101@piuha.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 24 Oct 2004 11:43:12 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Here's my second attempt for the text to resolve this issue. I'm taking into account Yoshi's concern as well as Bernard's replay protection issue: Change the current text in 2.3.1 to The Transient EAP Keys (TEKs) are session keys used to protect the EAP conversation. The TEKs are internal to the EAP method and are not exported. The lifetimes of these internal keys are defined by the method. They are typically created in the EAP conversation, used until the end of the conversation, and then discarded. Methods are, however, allowed to replace these keys to new ones even during a conversation. EAP methods may also implement a cache of some of the internal keying material which may persist for multiple EAP conversations when fast reconnect is used [RFC 3748]. For example, EAP methods based on TLS (such as EAP-TLS [RFC2716]) derive and cache the TLS Master Secret, typically for substantial time periods. Note that in general, when using fast reconnect, there is no guarantee to the EAP server that the original long-term credentials are still in the possession of the peer, as a card hold holding the private key for EAP-TLS may have been removed, for instance. In any case, EAP servers should attempt to verify that the long-term credentials would still be valid at this time, by ensuring that the original certificate lifetime has not yet expired, for instance. When using internal keys within an EAP conversation or across a number of conversations, it is necessary to ensure that replay protection and key separation requirements are fulfilled. For instance, if a replay counter is used, a mechanism must be in place to prevent it from wrapping around. Similarly, TSKs must remain cryptographically separate from TEKs even despite TEK rekeying or caching. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From ggxpvfemmy@yahoo.com Sun Oct 24 10:13:21 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 KAA00596; Sun, 24 Oct 2004 10:13:20 -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 1CLjKq-0006j7-L0; Sun, 24 Oct 2004 10:27:04 -0400 Received: from [221.166.152.98] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1CLj7b-0006Hg-Bn; Sun, 24 Oct 2004 10:13:24 -0400 Received: from 243.238.80.222 (HELO lists.warnerreprise.com) (112.213.66.0) by avas-mx73.yahoo.com with ESMTP id S131155AbUJINgX; Sat, 9 Oct 2004 10:36:23 -0700 Received: by yahoo.com with SMTP id 63so1911wri Received: by 27.175.201.147 with SMTP id 35mr2178bTuTpT; Sat, 09 Oct 2004 06:36:10 -0700 (PDT) Received: by 42.24.187.204 with HTTP; Sat, 9 Oct 2004 06:36:10 -0700 (PDT) Date: Sat, 9 Oct 2004 06:36:10 -0700 Message-Id: <200410031472.i93MyuTw004285@www4.warnerreprise.com> From: "Terrence Moore" To: eap-archive@ietf.org, entmib@ietf.org, entmib-admin@ietf.org, entmib-request@ietf.org, enum@ietf.org Mime-Version: 1.0 Content-Type: text/plain; X-Spam-Score: 8.4 (++++++++) X-Spam-Flag: YES X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Hi again, Here is Terrence Moore. I write to you because we are accepting your mortg= age application. Our office confirms you can get a $220.000 lo=C0n for a $252.00 per month = payment. Approval process will take 1 minute, so please fill out the form on our we= bsite: http://delicatessen-youngstown.refi-talk.com Thank you. Best Regards Terrence Moore First Account Manager From deliveryland@comcast.net Sun Oct 24 10:21:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02493; Sun, 24 Oct 2004 10:21:47 -0400 (EDT) Received: from [218.49.38.221] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CLjSz-0006tv-LI; Sun, 24 Oct 2004 10:35:31 -0400 Received: from apartment35.comcast.net ([90.229.244.248]) by 218.49.38.221 Microsoft SMTPSVC(6.0.3790.0); Fri, 22 Oct 2004 22:22:17 -0800 Message-ID: <200410094191.c3S5mz35542094@comcast.net> X-Mailer: Microsoft Outlook Express 6.00.2800.1050 Date: Fri, 22 Oct 2004 22:22:17 -0800 From: "Jean Kruse" Reply-To: "Jean Kruse" To: entmib-request@ietf.org Cc: edu-team-web-archive@ietf.org, enum-archive@ietf.org, eap-archive@ietf.org, enum@ietf.org, enum-admin@ietf.org, edu-team@ietf.org, enum-request@ietf.org, entmib-admin@ietf.org Subject: get pre-ap p roved 14 Organization: Microsoft Outlook Express 6.00.2800.1050 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="2612186839139363" X-Spam-Score: 15.6 (+++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b --2612186839139363 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit owlwinssparehelicopterwavefon --2612186839139363 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7Bit Dèàr Hòmèòwnèr,
Interèst Ràtes àre àt thèir lowèst pòint in 40 yèars. Wè help yoù find thè bèst quòtè for yoùr situàtiòn by matching yoùr neèds with hùndreds òf lènders. Hòme Impròvemènt, Homè Eqùity, Loàns, and Morè. Evèn with lèss thàn perfèct crèdit. Jùst fill òut à qùick, simplè fòrm ànd jùmp-stàrt yòùr fùtùre plàns tòday.

Accèss òur Shòrt Fòrm

Smooths Chase Escape Lap Band Fruit Counter Poem Womens Special Justice Sense Deadline Nonfiction Trouble Productions Comment Stylist President Afternoon Bear Unique Mystery Imagine Watching Knock Monitor Driving Idea Long Tube Lamp Memories Meeting Chair Scene Listening Business Operator Hardware Tape Saturday Alarm Americanize Sketch Reader Mistake Professionals Violence Remake Instant Normal Poster Brother Personality Wife Punch Nuts Counter Phrase Youth Stress Lock Canadian Test Master Notebook Treasure Leadership Romantic Point Butter Panel Boyish Opera Taxi Beach Cool Memories Pose West Silent Monitoring Poll Minority Slice Discount Cigarette Operation Panic Carbon Driver Open Excellent Follow Please Sick Announce Fishing Noise Entertainer Way Announcer City Wiper Silver Coast Nervous Demerit Canada Sport Host Outside Canadian Catholic Grant --2612186839139363-- From OrMeir@salford.ac.uk Sun Oct 24 18:53:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08241 for ; Sun, 24 Oct 2004 18:53:08 -0400 (EDT) From: OrMeir@salford.ac.uk Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLrRy-0007BJ-7g for eap-archive@ietf.org; Sun, 24 Oct 2004 19:06:58 -0400 Received: from [61.178.180.10] (helo=localhost) by mx2.foretec.com with smtp (Exim 4.24) id 1CLrEX-0003X1-14 for eap-archive@ietf.org; Sun, 24 Oct 2004 18:53:05 -0400 Date: Mon, 25 Oct 2004 10:00:45 +0000 Subject: Hello Eap-archive Massive DlCK under Attack!! To: Eap-archive References: <1C7E4LA7L25L1858@ietf.org> In-Reply-To: <1C7E4LA7L25L1858@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; charset=Windows-1251; boundary="----=_NextPart_HDH801K561E67JLB__J5JEHDE" X-Spam-Score: 24.5 (++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: a8a20a483a84f747e56475e290ee868e This is a multipart message in MIME format. ------=_NextPart_HDH801K561E67JLB__J5JEHDE Content-Type: text/plain; charset=Windows-1251 Content-Transfer-Encoding: 8bit Massive DiIck in action! Real huge dics.... approx 15' and small little pussies.. hehe this looks very funny .. want see? http://www.coolandmore.com/gen_ads/gen_mail.php?grid=111&ape=gt2810 Fisting Virgin . Do you want see how hot virgins making fisting sex? one hand on pussy .. 2 hands,, i can understand.. but 4 hands? i think you should see it http://www.coolandmore.com/gen_ads/gen_mail.php?grid=272&ape=gt2810 www.coolandmore.com/takemeoff if you want stop it ------=_NextPart_HDH801K561E67JLB__J5JEHDE Content-Type: text/html; charset=Windows-1251 Content-Transfer-Encoding: 8bit kdfkdjf kdj kd fkdjfkd

BlG DlCK IN ACTION!!

 

real huge dlcks!

approx 15'

and...small pussi3s

..yes..

 

CLlCK > WATCH > AND RELAX

 
www.coolandmore.com/takemeoff
if you want stop it
------=_NextPart_HDH801K561E67JLB__J5JEHDE-- From eap-admin@frascone.com Sun Oct 24 23:52:10 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27103 for ; Sun, 24 Oct 2004 23:52:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 438A11FC78; Sun, 24 Oct 2004 23:52:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D7F871FC68; Sun, 24 Oct 2004 23:52:05 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5E31D1FC68 for ; Sun, 24 Oct 2004 23:51:52 -0400 (EDT) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mail.frascone.com (Postfix) with ESMTP id 65F661FC0E for ; Sun, 24 Oct 2004 23:51:49 -0400 (EDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 24 Oct 2004 21:02:47 -0700 X-BrightmailFiltered: true Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i9P3pk6s008007; Sun, 24 Oct 2004 20:51:47 -0700 (PDT) Received: from jsaloweyw2k01 ([10.82.216.180]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 24 Oct 2004 20:53:25 -0700 From: "Joseph Salowey" To: "'Bernard Aboba'" , Subject: RE: [eap] Re: Issue 267: PRF Negotiation MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcS2TdVEnpEziesHTVuvSqIVISzL6AD937rg Message-ID: X-OriginalArrivalTime: 25 Oct 2004 03:53:25.0798 (UTC) FILETIME=[2E26AC60:01C4BA46] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 24 Oct 2004 20:51:43 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Yup, sounds like it is a good idea. How about the following: Create an IANA managed list (expert review) of PRFs that have the appropriate form. Assign one of the PRFs as the default PRF. If an EAP method specification doesn't specify anything then the default PRF is used. As an alternative, an EAP method specification may either specify an alternate PRF from the list or it may provide a way to negotiate one of the PRF's in the list. If this sounds good I can write it up more formally. Joe eap-admin@frascone.com wrote: > I agree that this is needed. The issue of PRF negotiation > has come up recently with respect to the NIST analysis of 802.11i. > > Can you suggest some text? > > On Tue, 19 Oct 2004, Bernard Aboba wrote: > >> Issue 267: PRF Negotiation >> Submitter name: Florent Bersani >> Submitter email address: florent.bersani@rd.francetelecom.fr >> Date first submitted: 10/2/2004 >> Reference: >> Document: Keying-03 >> Comment type: T >> Priority: S >> Section: Appendix F >> Rationale/Explanation of issue >> 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 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Oct 25 04:19:09 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29952 for ; Mon, 25 Oct 2004 04:19:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9B2BB1FC6C; Mon, 25 Oct 2004 04:19:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D07451FC71; Mon, 25 Oct 2004 04:19:05 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5F5EF1FC71 for ; Mon, 25 Oct 2004 04:18:28 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mail.frascone.com (Postfix) with ESMTP id 49DA61FC6C for ; Mon, 25 Oct 2004 04:18:25 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9P8IK302858; Mon, 25 Oct 2004 11:18:20 +0300 (EET DST) X-Scanned: Mon, 25 Oct 2004 11:17:07 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i9P8H7cG018709; Mon, 25 Oct 2004 11:17:07 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00Rmv5EO; Mon, 25 Oct 2004 11:17:05 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9P8Gra24252; Mon, 25 Oct 2004 11:16:53 +0300 (EET DST) Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 25 Oct 2004 11:16:31 +0300 Received: from trebe051.NOE.Nokia.com ([172.22.124.60]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 25 Oct 2004 11:16:31 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [eap] [Issue 278]: lifetimes of keys internal to EAP methods Message-ID: Thread-Topic: [eap] [Issue 278]: lifetimes of keys internal to EAP methods Thread-Index: AcS5pc0ygr1StMpISKuRVArk3rVsGQAxI58A From: To: , , Cc: X-OriginalArrivalTime: 25 Oct 2004 08:16:31.0151 (UTC) FILETIME=[EEF463F0:01C4BA6A] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 25 Oct 2004 11:16:31 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Jari, I think your proposal looks very good. There is need to have a general notion of the trade-off between speed and=20 security which is typical to fast reconnect schemes.=20 I also think the keying document should highlight the goal=20 (replay protection and key separation) rather than a certain=20 implementation. Best regards, Henry > -----Original Message----- > From: eap-admin@frascone.com=20 > [mailto:eap-admin@frascone.com]On Behalf Of > ext Jari Arkko > Sent: 24 October, 2004 11:43 > To: Bernard Aboba; Yoshihiro Ohba > Cc: eap@frascone.com > Subject: Re: [eap] [Issue 278]: lifetimes of keys internal to EAP > methods >=20 >=20 > Here's my second attempt for the text to resolve > this issue. I'm taking into account Yoshi's concern > as well as Bernard's replay protection issue: >=20 > Change the current text in 2.3.1 to >=20 > The Transient EAP Keys (TEKs) are session keys used to > protect the EAP conversation. The TEKs are internal > to the EAP method and are not exported. The lifetimes > of these internal keys are defined by the method. > They are typically created in the EAP conversation, > used until the end of the conversation, and then > discarded. Methods are, however, allowed to replace > these keys to new ones even during a conversation. >=20 > EAP methods may also implement a cache of some of the internal > keying material which may persist for multiple EAP conversations > when fast reconnect is used [RFC 3748]. For example, EAP methods > based on TLS (such as EAP-TLS [RFC2716]) derive and cache > the TLS Master Secret, typically for substantial time > periods. Note that in general, when using fast reconnect, there > is no guarantee to the EAP server that the original long-term > credentials are still in the possession of the peer, as a card > hold holding the private key for EAP-TLS may have been removed, > for instance. In any case, EAP servers should attempt to verify > that the long-term credentials would still be valid at this time, > by ensuring that the original certificate lifetime has not yet > expired, for instance. >=20 > When using internal keys within an EAP conversation or across > a number of conversations, it is necessary to ensure that > replay protection and key separation requirements are fulfilled. > For instance, if a replay counter is used, a mechanism must > be in place to prevent it from wrapping around. Similarly, > TSKs must remain cryptographically separate from TEKs even > despite TEK rekeying or caching. >=20 > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap >=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From SysHolthaus@earthlink.net Mon Oct 25 04:22:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00204 for ; Mon, 25 Oct 2004 04:22:13 -0400 (EDT) Message-Id: <200410250822.EAA00204@ietf.org> Received: from m95-mp1.cvx1-c.pop.dial.ntli.net ([62.255.76.95]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CM0Kf-0000KH-91 for eap-archive@ietf.org; Mon, 25 Oct 2004 04:36:07 -0400 Subject: Fwd: good stuff From: "Sid Knobel" To: eap-archive@ietf.org Date: Mon, 25 Oct 2004 14:15:45 +0500 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 4.9 (++++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable We gasped for breath Stupefaction more than fear made us = dumb and motionless!!=20














discontinue That a private gentleman should have such a machine at his command was not= likely!!! To coin money, regulate the value thereof, and of foreign coin,= and fix the standard of weights and measures;=20: The Senators and Repres= entatives shall receive a compensation for their services, to be ascertain= ed by law, and paid out of the treasury of the United States: Now the larg= est whales, those which frequent those parts of the sea round the Aleutian= , Kulammak, and Umgullich:=20 From eap-admin@frascone.com Mon Oct 25 04:58:08 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02312 for ; Mon, 25 Oct 2004 04:58:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BB9D81FC78; Mon, 25 Oct 2004 04:58:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5A82D1FC71; Mon, 25 Oct 2004 04:58:05 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 395EA1FC71 for ; Mon, 25 Oct 2004 04:57:52 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by mail.frascone.com (Postfix) with ESMTP id 0E5051FC6C for ; Mon, 25 Oct 2004 04:57:49 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9P8vgt15952; Mon, 25 Oct 2004 11:57:44 +0300 (EET DST) X-Scanned: Mon, 25 Oct 2004 11:56:20 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i9P8uKZa019856; Mon, 25 Oct 2004 11:56:20 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00ey2Jxd; Mon, 25 Oct 2004 11:56:19 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9P8cKa17857; Mon, 25 Oct 2004 11:38:20 +0300 (EET DST) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 25 Oct 2004 11:37:55 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 25 Oct 2004 11:37:55 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] [Issue 278]: lifetimes of keys internal to EAP methods Message-ID: <125EA890549C8641A72F3809CB80DCCD178387@esebe056.ntc.nokia.com> Thread-Topic: [eap] [Issue 278]: lifetimes of keys internal to EAP methods Thread-Index: AcS5pcyI9BIGZncqTXitjaR5GF2jeAAxP1ng From: To: , Cc: X-OriginalArrivalTime: 25 Oct 2004 08:37:55.0531 (UTC) FILETIME=[EC8139B0:01C4BA6D] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 25 Oct 2004 11:37:54 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi, I think the proposed text looks very good (it's much more clearer=20 what is just description of how "typical" EAP methods operate,=20 and what is absolutely required). However, I'm not so sure about the ast lsentence ("TSKs must=20 remain cryptographically separate from TEKs"). This requirement=20 is also repeated in Section 6.4, but I think it should actually=20 say that "it must not be possible to calculate TEKs from TSKs". The current text essentially prohibit EAP methods that use key wrapping (e.g., server generates a random key, encrypts it with a TEK, and sends it to the client). In this case, knowing the=20 TEK (and all information sent over the wire) allows you to=20 calculate the MSK. And knowing the MSK allows you to calculate=20 the TEKs in e.g. 802.11i), so they're not cryptographically separate (at least according to definition in Section 5.1). So, I'd propose replacing the last sentence with "Similarly,=20 it must not be possible to calculate TEKs from keys exported=20 outside the EAP method." (and also changing Section 6.4 accordingly). Best regards, Pasi > -----Original Message----- > From: Jari Arkko > Sent: Sunday, October 24, 2004 11:43 AM > To: Bernard Aboba; Yoshihiro Ohba > Cc: eap@frascone.com > Subject: Re: [eap] [Issue 278]: lifetimes of keys internal to EAP > methods >=20 >=20 > Here's my second attempt for the text to resolve > this issue. I'm taking into account Yoshi's concern > as well as Bernard's replay protection issue: >=20 > Change the current text in 2.3.1 to >=20 > The Transient EAP Keys (TEKs) are session keys used to > protect the EAP conversation. The TEKs are internal > to the EAP method and are not exported. The lifetimes > of these internal keys are defined by the method. > They are typically created in the EAP conversation, > used until the end of the conversation, and then > discarded. Methods are, however, allowed to replace > these keys to new ones even during a conversation. >=20 > EAP methods may also implement a cache of some of the internal > keying material which may persist for multiple EAP conversations > when fast reconnect is used [RFC 3748]. For example, EAP methods > based on TLS (such as EAP-TLS [RFC2716]) derive and cache > the TLS Master Secret, typically for substantial time > periods. Note that in general, when using fast reconnect, there > is no guarantee to the EAP server that the original long-term > credentials are still in the possession of the peer, as a card > hold holding the private key for EAP-TLS may have been removed, > for instance. In any case, EAP servers should attempt to verify > that the long-term credentials would still be valid at this time, > by ensuring that the original certificate lifetime has not yet > expired, for instance. >=20 > When using internal keys within an EAP conversation or across > a number of conversations, it is necessary to ensure that > replay protection and key separation requirements are fulfilled. > For instance, if a replay counter is used, a mechanism must > be in place to prevent it from wrapping around. Similarly, > TSKs must remain cryptographically separate from TEKs even > despite TEK rekeying or caching. >=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Oct 25 06:14:08 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09946 for ; Mon, 25 Oct 2004 06:14:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AEBF71FC64; Mon, 25 Oct 2004 06:14:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E7F961FC6C; Mon, 25 Oct 2004 06:14:05 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1C61A1FC6C for ; Mon, 25 Oct 2004 06:13:29 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by mail.frascone.com (Postfix) with ESMTP id 32A541FC64 for ; Mon, 25 Oct 2004 06:13:26 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9PADOt14265 for ; Mon, 25 Oct 2004 13:13:25 +0300 (EET DST) X-Scanned: Mon, 25 Oct 2004 13:11:41 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i9PABfHl007279 for ; Mon, 25 Oct 2004 13:11:41 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00cClnzY; Mon, 25 Oct 2004 13:11:40 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9PABWa16588 for ; Mon, 25 Oct 2004 13:11:32 +0300 (EET DST) Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 25 Oct 2004 13:11:18 +0300 Received: from trebe051.NOE.Nokia.com ([172.22.124.60]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 25 Oct 2004 13:11:17 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Message-ID: Thread-Topic: New EAP-SIM and EAP-AKA Thread-Index: AcS6evXCBa6Ndw8qS4Kmgqiyc73o4w== From: To: X-OriginalArrivalTime: 25 Oct 2004 10:11:17.0171 (UTC) FILETIME=[F757A830:01C4BA7A] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] New EAP-SIM and EAP-AKA Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 25 Oct 2004 13:11:17 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi everyone, We have submitted new versions of the EAP-SIM and EAP-AKA documents to the IETF directories, and they should be available shortly. The I-D = names=20 are draft-haverinen-pppext-eap-sim-14.txt and = draft-arkko-pppext-eap-aka-13.txt.=20 There are no incompatible changes, and most changes are editorial, so we = do=20 not expect this update to hinder the interoperability of existing = implementations=20 and new implementations in any way. To resolve a comment from the RFC editor, we added some clarification = about=20 second generation and third generation mobile network standards in the introduction chapters. Both documents now refer to each other in the beginning. It should be easier to understand how these protocols relate to each other and different mobile network standards. We addresses the comments from Yoshihiro Ohba's review of EAP-AKA=20 (relevant comments are incorporated in EAP-SIM too): http://www.opendiameter.org/draft-arkko-pppext-eap-aka-12_ohba-comments.t= xt We fixed the issue reported by Uma Shankar Ch, as proposed by Joe (both = drafts). http://mail.frascone.com/pipermail/eap/2004-August/002785.html We fixed the issue reported by Jouni Malinen in both drafts: http://mail.frascone.com/pipermail/eap/2004-September/002814.html For simplicity, I didn't add a new example for this issue, but instead=20 I changed the message sequence chart in the section "Fast = Re-authentication=20 Procedure when Counter is Too Small" so that AT_IDENTITY is used instead = of=20 EAP-Response/Identity, and added a note about this point.=20 We added a new section titled "Relying on EAP-Response/Identity = Discouraged" in both drafts. This section explains why the server should always use the method-specific identity attributes and not rely on = EAP-Response/Identity. The terminology in EAP-AKA has been generalized so that it takes both UMTS and cdma2000 networks into account. The same AKA algorithm is = used=20 in both 3G standards, so EAP-AKA can also be applied in both networks.=20 The terms in the previous version of EAP-AKA was specific to UMTS only. Best regards, Henry _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From Sandro_Earley@borg.com Mon Oct 25 06:33:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11196 for ; Mon, 25 Oct 2004 06:33:32 -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 1CM2Ni-00035E-3U for eap-archive@ietf.org; Mon, 25 Oct 2004 06:47:28 -0400 Received: from adsl-68-89-204-91.dsl.tulsok.swbell.net ([68.89.204.91]) by mx2.foretec.com with smtp (Exim 4.24) id 1CM2AL-0002by-Fo for eap-archive@ietf.org; Mon, 25 Oct 2004 06:33:29 -0400 Date: Mon, 25 Oct 2004 16:29:11 +0500 From: "Rachelle Kegler" To: eap-archive@ietf.org Subject: Re: Great news MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: X-Spam-Score: 5.3 (+++++) X-Spam-Flag: YES X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable In every case, after the choice of the President, the per= son having the greatest number of votes of the electors shall be the Vice = President.=20





Cîälis definetely better = then Vïagra
..can last for 2 days
..You can have alcohol with Ciálïs
..improves sexual performances twice better then Viagrä
..it costs much cheaper than Pfizêr Vïàgra
Get CÏÅLÎS (SUPÊR VÍÀGRÄ) h= ere









No msg A well regulated militia, being necessary to the security of a free state,= the right of the people to keep and bear arms, shall not be infringed. Th= e frigate skirted the south-east coast of America with great rapidity: I w= atched the luminous waves that broke over my hand, whose mirror-like surfa= ce was spotted with silvery rings!!!=20 From UAAWU@fastermail.com Mon Oct 25 07:10:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13802; Mon, 25 Oct 2004 07:10:22 -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 1CM2xW-0003op-79; Mon, 25 Oct 2004 07:24:18 -0400 Received: from [219.250.217.234] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1CM2k2-0003wx-JW; Mon, 25 Oct 2004 07:10:23 -0400 X-Message-Info: QYO/rwc/307/bzy/S+934/53170737917 Received: from vocabularian.UAAWU@fastermail.com ([128.105.152.46]) by aino6-ov70.UAAWU@fastermail.com with Microsoft SMTPSVC(5.0.5947.6865); Mon, 25 Oct 2004 10:06:48 -0200 Received: from moisture.UAAWU@fastermail.com ([44.128.63.4]) by pulpit.UAAWU@fastermail.com with MailEnable ESMTP; Mon, 25 Oct 2004 06:09:48 -0600 From: "Antonia Prater" To: "Adslmib" Subject: Carries all major med_s. Shipped to your door Over-the-night fedex MIME-Version: 1.0 (produced by corrodetycoon 2.3) Content-Type: multipart/alternative; boundary="--59624262979747923" Message-Id: Date: Mon, 25 Oct 2004 07:10:23 -0400 X-Spam-Score: 11.2 (+++++++++++) X-Spam-Flag: YES X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a ----59624262979747923 Content-Type: text/html; charset="iso-7938-0" Content-Description: coachman depict feat Content-Transfer-Encoding: 7Bit

Don't let the government tell you what you can take to help benefit your body and mind. We do not offer any harmful medications.
Give us just ONE chance and become a believer of online pharmacy. thank you for taking the time to read this. HERE ----59624262979747923-- From eap-admin@frascone.com Mon Oct 25 10:11:10 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27805 for ; Mon, 25 Oct 2004 10:11:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 001631FC64; Mon, 25 Oct 2004 10:11:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7A9F21FC71; Mon, 25 Oct 2004 10:11:05 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 873061FC71 for ; Mon, 25 Oct 2004 10:10:58 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by mail.frascone.com (Postfix) with ESMTP id 90D241FC64 for ; Mon, 25 Oct 2004 10:10:56 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9PEAst04579; Mon, 25 Oct 2004 17:10:54 +0300 (EET DST) X-Scanned: Mon, 25 Oct 2004 17:09:18 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i9PE9I7H013439; Mon, 25 Oct 2004 17:09:18 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00jfYOr3; Mon, 25 Oct 2004 17:09:16 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9PE9GS04335; Mon, 25 Oct 2004 17:09:16 +0300 (EET DST) Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 25 Oct 2004 17:07:46 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 25 Oct 2004 17:07:46 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Issue: Proposed Different organization for the keying draft Message-ID: <125EA890549C8641A72F3809CB80DCCD16FD61@esebe056.ntc.nokia.com> Thread-Topic: [eap] Issue: Proposed Different organization for the keying draft Thread-Index: AcS1lE+lvLsOyd1dQ5qP/QuXWUCGRQFBtNlA From: To: , X-OriginalArrivalTime: 25 Oct 2004 14:07:46.0003 (UTC) FILETIME=[008B9A30:01C4BA9C] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 25 Oct 2004 17:07:45 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable I agree, clearly separating the normative parts, informative text (like system-level security considerations of current systems), and more speculative stuff (like what some proposed handoff scheme might do) would improve the document considerably. (And it should also help to maintain the focus; IMHO this is not the right document to describe, e.g., various ways of how handoffs could be done in detail.) Best regards, Pasi > -----Original Message----- > From: Joseph Salowey > Sent: Tuesday, October 19, 2004 7:30 AM > To: eap@frascone.com > Subject: [eap] Issue: Proposed Different organization for=20 > the keying draft >=20 >=20 > Submitter name: Joe Salowey > Submitter email address: jsalowey@cisco.com > Date first submitted: 10/18/2004 > Reference:=20 > Document: Keying Framework > Comment type: E > Priority: 1 > Section: All > Rationale/Explanation of issue: >=20 > The current EAP keying framework contains a lot of good > information, however it is somewhat difficult to read and > understand. I believe this is because it mixes issues that > have to do with 802.11, handoff schemes and EAP method > internals without clearly explaining what is expected of the > external behavior of EAP methods. In addition I think some of > the material would be good to have in a standards track > document. >=20 > Requested change: >=20 > Section 1 - External behavior expected of EAP methods and Frameworks >=20 > 1.1 - Generated key material: MSK and EMSK > 1.2 - Exported key material: MSK, AMSK and AAA-Key > 1.3 - Derivation of AMSK from the EMSK > 1.4 - Identifying an instance of EAP method execution and naming keys > 1.6 - MSK and EMSK lifetime > 1.7 - Key Request Considerations > 1.8 - Security Considerations >=20 > Section 2 - Internal key generation for EAP methods (informative) > Section 3 - Example using keys in ciphering applications such=20 > as 802.11i (informative) > Section 4 - Handoff schemes (informative) >=20 > Section 1 could be a document on its own or a normative > section of a larger document. >=20 > I will gladly help restructure the document or work on a > separate document along these lines if this is the direction > the working group wants to go. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Oct 25 10:45:09 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01205 for ; Mon, 25 Oct 2004 10:45:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B131F1FD3A; Mon, 25 Oct 2004 10:45:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3DDD51FC71; Mon, 25 Oct 2004 10:45:06 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 370BB1FC71 for ; Mon, 25 Oct 2004 10:44:55 -0400 (EDT) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by mail.frascone.com (Postfix) with ESMTP id 3E1981FC64 for ; Mon, 25 Oct 2004 10:44:52 -0400 (EDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i9PEiobv011627; Mon, 25 Oct 2004 23:44:50 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i9PEiof1018123; Mon, 25 Oct 2004 23:44:50 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id ZAA18122 ; Mon, 25 Oct 2004 23:44:50 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id XAA28843; Mon, 25 Oct 2004 23:44:50 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id i9PEinro004947; Mon, 25 Oct 2004 23:44:49 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id i9PEinuY022381; Mon, 25 Oct 2004 23:44:49 +0900 (JST) Received: from steelhead ([172.30.24.114]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0I65009Y5AAMF1@tsbpo1.po.toshiba.co.jp>; Mon, 25 Oct 2004 23:44:48 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1CKxNM-0005Ex-00; Fri, 22 Oct 2004 04:14:28 -0700 From: Yoshihiro Ohba Subject: Re: [eap] [Issue 278]: lifetimes of keys internal to EAP methods In-reply-to: <417B6B20.8070407@piuha.net> To: Jari Arkko Cc: Bernard Aboba , Yoshihiro Ohba , eap@frascone.com Message-id: <20041022111424.GC11702@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.6+20040907i References: <417A95E6.3090101@piuha.net> <417B6B20.8070407@piuha.net> 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, 22 Oct 2004 07:14:24 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Hi Jari, Thank you for revising the text. I agree on the text. Yoshihiro Ohba On Sun, Oct 24, 2004 at 11:43:12AM +0300, Jari Arkko wrote: > Here's my second attempt for the text to resolve > this issue. I'm taking into account Yoshi's concern > as well as Bernard's replay protection issue: > > Change the current text in 2.3.1 to > > The Transient EAP Keys (TEKs) are session keys used to > protect the EAP conversation. The TEKs are internal > to the EAP method and are not exported. The lifetimes > of these internal keys are defined by the method. > They are typically created in the EAP conversation, > used until the end of the conversation, and then > discarded. Methods are, however, allowed to replace > these keys to new ones even during a conversation. > > EAP methods may also implement a cache of some of the internal > keying material which may persist for multiple EAP conversations > when fast reconnect is used [RFC 3748]. For example, EAP methods > based on TLS (such as EAP-TLS [RFC2716]) derive and cache > the TLS Master Secret, typically for substantial time > periods. Note that in general, when using fast reconnect, there > is no guarantee to the EAP server that the original long-term > credentials are still in the possession of the peer, as a card > hold holding the private key for EAP-TLS may have been removed, > for instance. In any case, EAP servers should attempt to verify > that the long-term credentials would still be valid at this time, > by ensuring that the original certificate lifetime has not yet > expired, for instance. > > When using internal keys within an EAP conversation or across > a number of conversations, it is necessary to ensure that > replay protection and key separation requirements are fulfilled. > For instance, if a replay counter is used, a mechanism must > be in place to prevent it from wrapping around. Similarly, > TSKs must remain cryptographically separate from TEKs even > despite TEK rekeying or caching. > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From pcxaplcxypcl@oct-net.ne.jp Mon Oct 25 10:55:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01814; Mon, 25 Oct 2004 10:55:31 -0400 (EDT) Received: from dhcp23185.oct-net.ne.jp ([202.220.185.185]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CM6TP-0008Fj-Fs; Mon, 25 Oct 2004 11:09:29 -0400 Received: from dhcp23185.oct-net.ne.jp by vscan4.oct-net.ne.jp with SMTP id tfnypsmd; Mon, 25 Oct 2004 08:55:40 -0600 Received: from 51.164.1.109 by dhcp23185.oct-net.ne.jp with Microsoft SMTPSVC; Mon, 25 Oct 2004 08:54:39 -0600 Message-ID: <2341216007490829-8765822@202.220.185.185> Date: Mon, 25 Oct 2004 08:55:20 -0600 Subject: What's this?' Kuzmin said From: "Ricks" Content-Type: text/html; charset=ISO-8859-8; Content-Transfer-Encoding: 7bit To: "Doss Diffserv-interest" X-Mailer: the gherkin itswarty frye a bsbfcly MIME-Version: 1.0 X-Spam-Score: 2.1 (++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Mon, 25 Oct 2004 08:55:40 -0600

Congratulations! You have been approv e d   for a new home mortg a g e.
Below are the specifications of your approv a l

  • L oan Type: Conventional
  • Interest: 3.5
  • Term: 360 months
  • Sales Price: $250,000 (Maximum)
  • Closing Date: 30 days


    • Please follow this link to confirm your info.

    Thank you for your immediate attention.

    Very truly yours,
    Jessica Patterson
    Accounts From eap-admin@frascone.com Mon Oct 25 11:11:10 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03041 for ; Mon, 25 Oct 2004 11:11:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A71A61FC64; Mon, 25 Oct 2004 11:11:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1FB501FC71; Mon, 25 Oct 2004 11:11:06 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3C0EA1FC71 for ; Mon, 25 Oct 2004 11:10:38 -0400 (EDT) Received: from internaut.com (c-67-182-139-247.client.comcast.net [67.182.139.247]) by mail.frascone.com (Postfix) with ESMTP id 60F1F1FC64 for ; Mon, 25 Oct 2004 11:10:35 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i9PFACU02251; Mon, 25 Oct 2004 08:10:12 -0700 From: Bernard Aboba To: Jari Arkko Cc: Yoshihiro Ohba , eap@frascone.com Subject: Re: [eap] [Issue 278]: lifetimes of keys internal to EAP methods In-Reply-To: <417B6B20.8070407@piuha.net> Message-ID: References: <417A95E6.3090101@piuha.net> <417B6B20.8070407@piuha.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 25 Oct 2004 08:10:12 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) "For instance, if a replay counter is used, a mechanism must be in place to prevent it from wrapping around." The replay counter will wrap when it needs to wrap, this cannot be prevented. I think what you mean to say is that the TEKs need to be refreshed before the counter wraps. With repect to cryptographic separation of TEKs and TSKs, I think the requirement is that the TSKs not be derivable from the TEKs as well as vice versa. This implies that they are not on the same branch of the key hierarchy. On Sun, 24 Oct 2004, Jari Arkko wrote: > Here's my second attempt for the text to resolve > this issue. I'm taking into account Yoshi's concern > as well as Bernard's replay protection issue: > > Change the current text in 2.3.1 to > > The Transient EAP Keys (TEKs) are session keys used to > protect the EAP conversation. The TEKs are internal > to the EAP method and are not exported. The lifetimes > of these internal keys are defined by the method. > They are typically created in the EAP conversation, > used until the end of the conversation, and then > discarded. Methods are, however, allowed to replace > these keys to new ones even during a conversation. > > EAP methods may also implement a cache of some of the internal > keying material which may persist for multiple EAP conversations > when fast reconnect is used [RFC 3748]. For example, EAP methods > based on TLS (such as EAP-TLS [RFC2716]) derive and cache > the TLS Master Secret, typically for substantial time > periods. Note that in general, when using fast reconnect, there > is no guarantee to the EAP server that the original long-term > credentials are still in the possession of the peer, as a card > hold holding the private key for EAP-TLS may have been removed, > for instance. In any case, EAP servers should attempt to verify > that the long-term credentials would still be valid at this time, > by ensuring that the original certificate lifetime has not yet > expired, for instance. > > When using internal keys within an EAP conversation or across > a number of conversations, it is necessary to ensure that > replay protection and key separation requirements are fulfilled. > For instance, if a replay counter is used, a mechanism must > be in place to prevent it from wrapping around. Similarly, > TSKs must remain cryptographically separate from TEKs even > despite TEK rekeying or caching. > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Oct 25 11:52:11 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06866 for ; Mon, 25 Oct 2004 11:52:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EBAA21FC64; Mon, 25 Oct 2004 11:52:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3DBB51FC76; Mon, 25 Oct 2004 11:52:06 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3FA671FC71 for ; Mon, 25 Oct 2004 11:51:17 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 7CD741FC64 for ; Mon, 25 Oct 2004 11:51:13 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id AA38789877; Mon, 25 Oct 2004 18:51:09 +0300 (EEST) Message-ID: <417D208B.2000704@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba , Pasi Eronen Cc: eap@frascone.com Subject: Re: [eap] [Issue 278]: lifetimes of keys internal to EAP methods References: <417A95E6.3090101@piuha.net> <417B6B20.8070407@piuha.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 25 Oct 2004 18:49:31 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > "For instance, if a replay counter is used, a mechanism must > be in place to prevent it from wrapping around." > > The replay counter will wrap when it needs to wrap, this cannot be > prevented. I think what you mean to say is that the TEKs need to be > refreshed before the counter wraps. Right :-) > With repect to cryptographic separation of TEKs and TSKs, I think the > requirement is that the TSKs not be derivable from the TEKs as well as > vice versa. This implies that they are not on the same branch of the key > hierarchy. Yes. Although Pasi's last e-mail seemed to say something else -- I think he wanted to require only the latter condition, i.e., that TEKs not be derivable from TSKs. Opinions on that? (In all current methods that I know of, both conditions are true. But we shouldn't specify what current methods do, we should specify what is necessary.) --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Oct 25 12:48:09 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13069 for ; Mon, 25 Oct 2004 12:48:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7ACAE1FC71; Mon, 25 Oct 2004 12:48:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1640D1FD5A; Mon, 25 Oct 2004 12:48:06 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 77BBB1FC71 for ; Mon, 25 Oct 2004 12:47:11 -0400 (EDT) Received: from internaut.com (c-67-182-139-247.client.comcast.net [67.182.139.247]) by mail.frascone.com (Postfix) with ESMTP id CC3941FC64 for ; Mon, 25 Oct 2004 12:47:09 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i9PGl4W08307; Mon, 25 Oct 2004 09:47:05 -0700 From: Bernard Aboba To: Jari Arkko Cc: eap@frascone.com Subject: Re: [eap] [Issue 278]: lifetimes of keys internal to EAP methods In-Reply-To: <417D208B.2000704@piuha.net> Message-ID: References: <417A95E6.3090101@piuha.net> <417B6B20.8070407@piuha.net> <417D208B.2000704@piuha.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 25 Oct 2004 09:47:04 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > Bernard Aboba wrote: > > "For instance, if a replay counter is used, a mechanism must > > be in place to prevent it from wrapping around." > > > > The replay counter will wrap when it needs to wrap, this cannot be > > prevented. I think what you mean to say is that the TEKs need to be > > refreshed before the counter wraps. > > Right :-) How about this? The Transient EAP Keys (TEKs) are session keys used to protect the EAP conversation. The TEKs are internal to the EAP method and are not exported. TEKs are typically created during an EAP conversation, used until the end of the conversation and then discarded. However, methods may rekey TEKs during a conversation. When using TEKs within an EAP conversation or across conversations, it is necessary to ensure that replay protection and key separation requirements are fulfilled. For instance, if a replay counter is used, TEK rekey MUST occur prior to wrapping of the counter. Similarly, TSKs MUST remain cryptographically separate from TEKs despite TEK rekeying or caching. This prevents TEK compromise from leading directly to compromise of the TSKs and vice versa. EAP methods may cache local keying material which may persist for multiple EAP conversations when fast reconnect is used [RFC 3748]. For example, EAP methods based on TLS (such as EAP-TLS [RFC2716]) derive and cache the TLS Master Secret, typically for substantial time periods. The lifetime of other local keying material calculated within the EAP method is defined by the method. Note that in general, when using fast reconnect, there is no guarantee to that the original long-term credentials are still in the possession of the peer. For instance, a card hold holding the private key for EAP-TLS may have been removed. EAP servers should verify that the long-term credentials are still valid, such as by checking that certificate used in the original authentication has not yet expired." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From BFQCYXYL@attbi.com Mon Oct 25 14:06:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19656 for ; Mon, 25 Oct 2004 14:06:02 -0400 (EDT) Received: from adsl-68-22-87-50.dsl.yntwoh.ameritech.net ([68.22.87.50]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CM9Rn-0004Lv-Kb for eap-archive@ietf.org; Mon, 25 Oct 2004 14:20:01 -0400 X-Message-Info: 4kyfake418byhZ/qAXJwPFbPnX543JVgug Received: from ostracod (212.240.135.182) by hye630.cabana.volterra.byzantine.de.kaercher.com (InterMail vS.6.92.52.02 6-41-3-5545-24-27233) with ESMTP id <748451653.OPM5259.aa7-mail.wrongful.postcard.net.cable.rogers.com@clarke> for ; Mon, 25 Oct 2004 18:08:51 -0200 Message-ID: <82510xsk9831p$397206a90$439yyy116a916@accession> Reply-To: "Jonah Marsh" From: "Jonah Marsh" To: Subject: This is the bast phemma site! Cljck here to get cheip prjces! bootstrap Date: Mon, 25 Oct 2004 17:09:51 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--945805542029102963" X-Spam-Score: 9.5 (+++++++++) X-Spam-Flag: YES X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ----945805542029102963 Content-Type: text/html; Content-Transfer-Encoding: 7Bit Hi and welcome to our phhaemeci!
    Bast Phaarmeci on the web! We appreciate the time you spend while looking for
    new and better phhaemeci sites over the net, so we
    decided to let you know about our site, our phhaemeci.
    Come on now!

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


    http://beachhead.uahkld.biz/?wid=100183
    ghetto tolerate daytime carriage crayon saudi portage allotted celandine canyon embeddable. l'vov strategist lard spectrography mastery aforementioned deterring junketeer gigavolt somerset plaintive elfin. ralph orthodontist capita gottfried chuckle geraldine codon antaeus platonic electroencephalography. benzene dragon vendible ecclesiastic tallow sanguineous bangui. credit pogo netherlands predilect waterhouse brennan.
    sarsparilla comprise anabaptist araby ego priest chef eocene. sledgehammer lateran denunciation whenever eagle impalpable vulpine gusty. canyon dine consonantal polyhedral duckling danny smokescreen cool smudge axisymmetric. campaign coxcomb mercuric pauli shiny career. ----945805542029102963-- From eap-admin@frascone.com Mon Oct 25 19:44:08 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18545 for ; Mon, 25 Oct 2004 19:44:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E4D131FC64; Mon, 25 Oct 2004 19:44:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1AD2C1FCBF; Mon, 25 Oct 2004 19:44:06 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1395D1FCBF for ; Mon, 25 Oct 2004 19:43:02 -0400 (EDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mail.frascone.com (Postfix) with ESMTP id 000BE1FC64 for ; Mon, 25 Oct 2004 19:43:00 -0400 (EDT) Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 25 Oct 2004 16:43:46 -0700 X-BrightmailFiltered: true Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i9PNguGm029361; Mon, 25 Oct 2004 16:42:57 -0700 (PDT) Received: from jsaloweyw2k01 ([10.82.216.180]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 25 Oct 2004 16:44:36 -0700 From: "Joseph Salowey" To: "'Bernard Aboba'" , "'Jari Arkko'" Cc: Subject: RE: [eap] [Issue 278]: lifetimes of keys internal to EAP methods MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcS6ssZ5iYsohBtyQpuXAayFA1H5ygANQGqw Message-ID: X-OriginalArrivalTime: 25 Oct 2004 23:44:36.0751 (UTC) FILETIME=[9628A1F0:01C4BAEC] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 25 Oct 2004 16:42:54 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I agree with Pasi. I think we are getting too far down into how a method is implemented and the actual requirements are being obscured. We want methods to have replay protection and we want it to be computationally infeasible to calculate the keys secret to the EAP method from keys exported from the EAP method. This behavior should be maintained even if cached keying material is used and cached material should be checked for validity. I think most of the rest of the section is extraneous. Joe eap-admin@frascone.com wrote: >> Bernard Aboba wrote: >>> "For instance, if a replay counter is used, a mechanism must be in >>> place to prevent it from wrapping around." >>> >>> The replay counter will wrap when it needs to wrap, this cannot be >>> prevented. I think what you mean to say is that the TEKs need to be >>> refreshed before the counter wraps. >> >> Right :-) > > How about this? > > The Transient EAP Keys (TEKs) are session keys used to > protect the EAP conversation. The TEKs are internal to the > EAP method and are not exported. TEKs are typically created > during an EAP conversation, used until the end of the > conversation and then discarded. However, methods may rekey TEKs > during a conversation. > > When using TEKs within an EAP conversation or across > conversations, it is necessary to ensure that replay > protection and key separation requirements are fulfilled. > For instance, if a replay counter is used, TEK rekey MUST > occur prior to wrapping of the counter. > Similarly, TSKs MUST remain cryptographically separate from > TEKs despite TEK rekeying or caching. This prevents TEK > compromise from leading directly to compromise of the TSKs and vice > versa. > > EAP methods may cache local keying material which may persist > for multiple EAP conversations when fast reconnect is used > [RFC 3748]. For example, EAP methods based on TLS (such as > EAP-TLS [RFC2716]) derive and cache the TLS Master Secret, > typically for substantial time periods. The lifetime of > other local keying material calculated within the EAP method > is defined by the method. Note that in general, when using > fast reconnect, there is no guarantee to that the original > long-term credentials are still in the possession of the > peer. For instance, a card hold holding the private key for > EAP-TLS may have been removed. EAP servers should verify > that the long-term credentials are still valid, such as by > checking that certificate used in the original authentication has not > yet expired." _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 26 05:42:11 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17089 for ; Tue, 26 Oct 2004 05:42:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A40231FC64; Tue, 26 Oct 2004 05:42:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0C47A1FC79; Tue, 26 Oct 2004 05:42:06 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 36E8B1FC79 for ; Tue, 26 Oct 2004 05:41:48 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 3880E1FC64 for ; Tue, 26 Oct 2004 05:41:46 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 2F3ED8987C; Tue, 26 Oct 2004 12:41:45 +0300 (EEST) Message-ID: <417E1B75.7060601@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Cc: aboba@internaut.com, eap@frascone.com Subject: Re: [eap] [Issue 278]: lifetimes of keys internal to EAP methods References: <125EA890549C8641A72F3809CB80DCCD178387@esebe056.ntc.nokia.com> In-Reply-To: <125EA890549C8641A72F3809CB80DCCD178387@esebe056.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 26 Oct 2004 12:40:05 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com wrote: > However, I'm not so sure about the ast lsentence ("TSKs must > remain cryptographically separate from TEKs"). This requirement > is also repeated in Section 6.4, but I think it should actually > say that "it must not be possible to calculate TEKs from TSKs". This seems to be the main requirement, yes. And doesn't it hold for MSK too? That is, Must not be possible to calculate TEKs from MSK Must not be possible to calculate MSK from TSKs (But 802.11i might not qualify for the latter? If so, I'm ready to make this: Must not be possible to calculate TEKs from MSK Must not be possible to calculate TEKs from TSKs) > The current text essentially prohibit EAP methods that use key > wrapping (e.g., server generates a random key, encrypts it with > a TEK, and sends it to the client). In this case, knowing the > TEK (and all information sent over the wire) allows you to calculate the MSK. Yes, I don't think there's anything fundamentally wrong with this. > And knowing the MSK allows you to calculate > the TEKs in e.g. 802.11i), so they're not cryptographically > separate (at least according to definition in Section 5.1). Now I'm missing something. Perhaps you meant to say that knowing the MSK allows you to calculate the TSKs in 802.11i? No fault in the lower layer can let you calculate TEKs, assuming your requirement in the first paragraph above holds. > So, I'd propose replacing the last sentence with "Similarly, > it must not be possible to calculate TEKs from keys exported > outside the EAP method." (and also changing Section 6.4 > accordingly). This is good enough for me. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 26 05:46:09 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17223 for ; Tue, 26 Oct 2004 05:46:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A40A11FC64; Tue, 26 Oct 2004 05:46:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 22AC11FC79; Tue, 26 Oct 2004 05:46:06 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D4BFF1FC79 for ; Tue, 26 Oct 2004 05:45:24 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 1953F1FC64 for ; Tue, 26 Oct 2004 05:45:23 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 432988987C; Tue, 26 Oct 2004 12:45:22 +0300 (EEST) Message-ID: <417E1C4E.8000308@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] [Issue 278]: lifetimes of keys internal to EAP methods References: <417A95E6.3090101@piuha.net> <417B6B20.8070407@piuha.net> <417D208B.2000704@piuha.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 26 Oct 2004 12:43:42 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I'm fine with this with the exception of the bidirectional separation requirement between the TEKs and TSKs. I think Pasi's arguments make sense, and the requirement should only be about not being able to compute TEKs if you are given either the MSK or the TSKs. But maybe we should open another issue # for this part, as it seems different from the original lifetime issue. So my proposal is that we close #278 now with your text below and then I'll post another issue which has to do with the cryptographic independence of TEKs from MSKs and TSKs. --Jari Bernard Aboba wrote: > The Transient EAP Keys (TEKs) are session keys used to > protect the EAP conversation. The TEKs are internal to the EAP > method and are not exported. TEKs are typically created > during an EAP conversation, used until the end of the > conversation and then discarded. However, methods may > rekey TEKs during a conversation. > > When using TEKs within an EAP conversation or across conversations, > it is necessary to ensure that replay protection and key separation > requirements are fulfilled. For instance, if a replay counter is used, > TEK rekey MUST occur prior to wrapping of the counter. > Similarly, TSKs MUST remain cryptographically separate from TEKs > despite TEK rekeying or caching. This prevents TEK compromise from > leading directly to compromise of the TSKs and vice versa. > > EAP methods may cache local keying material which may persist > for multiple EAP conversations when fast reconnect is used > [RFC 3748]. For example, EAP methods based on TLS (such as > EAP-TLS [RFC2716]) derive and cache the TLS Master Secret, > typically for substantial time periods. The lifetime of > other local keying material calculated within the EAP > method is defined by the method. Note that in general, > when using fast reconnect, there is no guarantee to > that the original long-term credentials are > still in the possession of the peer. For instance, a > card hold holding the private key for EAP-TLS may have > been removed. EAP servers should verify that the > long-term credentials are still valid, such as by checking > that certificate used in the original authentication has not yet > expired." > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 26 06:02:09 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18233 for ; Tue, 26 Oct 2004 06:02:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4F05D1FCC3; Tue, 26 Oct 2004 06:02:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9AF7E1FC79; Tue, 26 Oct 2004 06:02:06 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 27BCC1FC79 for ; Tue, 26 Oct 2004 06:01:15 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 5F5B51FC64 for ; Tue, 26 Oct 2004 06:01:10 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 07F138987C; Tue, 26 Oct 2004 13:01:10 +0300 (EEST) Message-ID: <417E2002.5070501@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com, aboba@internaut.com Cc: eap@frascone.com References: <125EA890549C8641A72F3809CB80DCCD178387@esebe056.ntc.nokia.com> In-Reply-To: <125EA890549C8641A72F3809CB80DCCD178387@esebe056.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] [Issue N]: independence of TEKs from MSKs and TSKs Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 26 Oct 2004 12:59:30 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Submitter name: Pasi Eronen Submitter email address: Pasi.Eronen@nokia.com Date first submitted: 10/25/2004 Reference: http://mail.frascone.com/pipermail/eap/2004-October/002971.html Document: Keying Framework Comment type: T Priority: 1 Section: 2.3.1 and Rationale/Explanation of issue: Pasi argues that it is only necessary to prevent computation of TEKs from TSKs and not the other way around. Jari argues that it is also useful to prevent computation of TEKs from MSK and EMSK. Preventing computation of MSKs from TSKs was also mentioned, but that may not fit what current link layers do (?). Suggested correction: In 2.3.1, change Similarly, TSKs MUST remain cryptographically separate from TEKs despite TEK rekeying or caching. This prevents TEK compromise from leading directly to compromise of the TSKs and vice versa. => Similarly, Similarly, it must not be possible to calculate TEKs from keys exported outside the EAP method. This prevents TSK compromise from leading directly to compromise of the TEKs. In Section 6.4, change In addition, the TSKs MUST be cryptographically separate from the TEKs. => In addition, it MUST NOT be possible to calculate TEKs from MSK and EMSK. (From this it also follows that it is not possible to calculate TEKs from TSKs or AMSKs.) _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 26 07:00:09 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23035 for ; Tue, 26 Oct 2004 07:00:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 259901FC64; Tue, 26 Oct 2004 07:00:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 813301FC79; Tue, 26 Oct 2004 07:00:06 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DF5BF1FC79 for ; Tue, 26 Oct 2004 06:59:26 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 23D461FC64 for ; Tue, 26 Oct 2004 06:59:24 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id BF4868987C; Tue, 26 Oct 2004 13:59:22 +0300 (EEST) Message-ID: <417E2DA6.7010508@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joseph Salowey Cc: "'Bernard Aboba'" , eap@frascone.com Subject: Re: [eap] Re: Issue 267: PRF Negotiation References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 26 Oct 2004 13:57:42 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Joe, I think this would be sufficient. > Create an IANA managed list (expert review) of PRFs that have the > appropriate form. > Assign one of the PRFs as the default PRF. > If an EAP method specification doesn't specify anything then the default PRF > is used. > As an alternative, an EAP method specification may either specify an > alternate PRF from the list or it may provide a way to negotiate one of the > PRF's in the list. > > If this sounds good I can write it up more formally. > > Joe > > > eap-admin@frascone.com wrote: > >>I agree that this is needed. The issue of PRF negotiation >>has come up recently with respect to the NIST analysis of 802.11i. >> >>Can you suggest some text? >> >>On Tue, 19 Oct 2004, Bernard Aboba wrote: >> >> >>>Issue 267: PRF Negotiation >>>Submitter name: Florent Bersani >>>Submitter email address: florent.bersani@rd.francetelecom.fr >>>Date first submitted: 10/2/2004 >>>Reference: >>>Document: Keying-03 >>>Comment type: T >>>Priority: S >>>Section: Appendix F >>>Rationale/Explanation of issue >>>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 > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From gtalxabekllompamn@essentkabel.com Tue Oct 26 07:39:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27526; Tue, 26 Oct 2004 07:39:14 -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 1CMPt1-00016A-UL; Tue, 26 Oct 2004 07:53:22 -0400 Received: from usen-220x218x166x62.ap-us00.usen.ad.jp ([220.218.166.62]) by mx2.foretec.com with smtp (Exim 4.24) id 1CMPfM-0007Ss-Sw; Tue, 26 Oct 2004 07:39:05 -0400 Received: from b99.satx.rr.com ([76.24.0.64]) by spb6-iw.220.218.166.62 with Microsoft SMTPSVC(5.380.8773.8778); Tue, 26 Oct 2004 12:42:32 +0100 Message-ID: <305795$56253ROQ$02@satx.rr.com> Generate-Delivery-Report: No Distribution: cutler revise Prevent-NonDelivery-Report: Yes Reply-To: "Alissa Decker" From: "Alissa Decker" To: rpr@ietf.org Cc: er-wgchairs@ietf.org, eap-archive@ietf.org, owner-wgchairs@ietf.org, urn-archive@ietf.org, nemo-request@ietf.org, p2prg-web-archive@ietf.org, haa11894@ietf.org, ldapext@ietf.org, in@ietf.org, sipping@ietf.org Subject: Buying a home is a Big Deal Date: Tue, 26 Oct 2004 10:38:32 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--97404593856718648" X-Spam-Score: 7.2 (+++++++) X-Spam-Flag: YES X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a ----97404593856718648 Content-Type: text/html; charset="iso-5740-3" Content-Transfer-Encoding: 7Bit Hi,

    Did you recieve my email from last week? I'm happy to tell you
    that you are approved for a home loan with a 3.25% rate.

    Your tracking number is # XN021
    You must visit the link below in 24 hrs to confirm your details.

    http://www.my-refi.net/j8/e7.php?v2l=63

    Best Regards,
    Alissa Decker
    Manager
    AFC Homes



    Correspondence Options

    ----97404593856718648-- From eap-admin@frascone.com Tue Oct 26 07:54:10 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28475 for ; Tue, 26 Oct 2004 07:54:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6B0811FCC1; Tue, 26 Oct 2004 07:54:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EBBDE1FC79; Tue, 26 Oct 2004 07:54:05 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 06E0D1FC79 for ; Tue, 26 Oct 2004 07:53:46 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 200E71FC64 for ; Tue, 26 Oct 2004 07:53:44 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 9647C8987C; Tue, 26 Oct 2004 14:53:43 +0300 (EEST) Message-ID: <417E3A63.9000300@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] Re: Issue 262: MSK Naming References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 26 Oct 2004 14:52:03 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > [a] What are the constraints on name construction by EAP methods? For > example, the name cannot be specific to a particular lower layer since > that would violate EAP media independence. Yes, although this does not appear to be a current problem. We are not specifying them in lower layer terms (at least in IETF documents). > [b] Is there a general framework for name construction that applies > automatically to methods that currently don't include names? For example, > where the method provides nonces and/or counters, and names both the EAP > peer and server, then the suggested naming mechanism will apply. But is > this a requirement or a guideline? > > [c] Is there a requirement for EAP method specifications? For example, if > the EAP method doesn't meet the criteria for the name template does it > need to specify a key naming scheme for the MSK and EMSK? I think we need to be pragmatic. One observation is that current implementations (EAP itself plus any methods) don't do this at the moment. So there's going to be an implementation change when someone needs to do something that needs a name. Fortunately, nothing needs a name, currently, so we just need to prepare for this. The second observation is that method specifications have been published prior to the invention of the keying framework. And probably some methods will still be published before the keying framework becomes an RFC. So we are left with the possibilities of (a) specifying naming in the key framework so that its fully defined for every method (e.g. a hash of the key itself) (b) specifying naming in the key framework itself, with a rule plus the intepretation for existing methods, or (c) allowing older methods to not have names until some addendum to their specifications have been published I'm inclined to go for option b. > As far as the two nonces is concerned, this is just one way of achieving > temporal and possibly global uniqueness. Depending on the method, it might > also be acceptable to have one or more counters used instead, assuming that > state is kept so they don't wrap. I agree. > [d] What are the uniqueness requirements on the name? For example, it > would appear to be required that key names be globally and temporally > unique for any EAP method. The global uniqueness component is accomplished > by the inclusion of the "MSK", EAP Method Type, EAP peer name and EAP > server name in the key name, and temporal uniqueness is contributed by the > peer and server nonces/counters. > > However, there may be EAP methods that only identify the EAP peer > (either in the method or in the EAP-Request/Identity), but not the > EAP server. Does this compromise the uniqueness requirements? I think you may be too optimistic in assuming that the inclusion of the peer or server names accomplishes a guaranteed notion of uniqueness. On the client side I don't think it is mandatory to use a NAI. NAIs would be guaranteed to have some uniqueness properties due to the requirement to use DNS names, but on other types of identifiers there is no guarantee about that. I might use "jari" as my userid in EAP Identity Response, and so might lots of other people in Finland. On the server side we have no requirement that the server have an identity. And even if there is an identity, there is no guarantee that its unique globally. The server might have a certificate that associates a public key with the identity of, say, IP address 10.0.0.1. So, if a "jari" roams from his home server at 10.0.0.1 to a neighbor's server that is also at 10.0.1. and the neighbor happens to be called "jari" too, we have a potential collision. > I think not; if the peer and server nonces/counter are guaranteed > to be globally and temporally unique, then the name will also > have these properties even though the server name is not included. > In particular, it seems like the server nonce/counter now needs > to be globally as well as temporally unique, to counteract the > lack of explicit server identification. I don't think we should shoot for a guaranteed, managed notion of uniqueness. Statistical uniqueness is sufficient. What is in practise required is that we include enough method type numbers and peer identifiers so that in method implemenations with broken random number generators don't lead to an immediate catastrophy. The rest is handled with the inclusion of a random component. If the random number is good enough then it will be both temporally and globally unique. Note that we probably shouldn't specify too much of where this number comes from -- on cellular networks, for instance, the servers are better equipped to generate good random numbers than small client devices. Note that all the above still leaves one case where things will fail -- when John Smith roams from his 10.0.0.1 server to another John Smith's 10.0.0.1 server and everyone involved has a bad random number generator. But there's nothing we can do about this, short of mandating that EAP is only used within a global, administered name space; the cure would be worse than the disease. And I don't feel like we need to rescue people who have bad implementations either. I'll propose some text about name generation later today. > With respect to normative language -- the EAP key framework is > informational but this doesn't preclude normative language. Most > requirements documents use normative language yet are informational. Right. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 26 09:50:11 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05926 for ; Tue, 26 Oct 2004 09:50:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BB3111FC64; Tue, 26 Oct 2004 09:50:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3091B1FC79; Tue, 26 Oct 2004 09:50:07 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4164C1FC79 for ; Tue, 26 Oct 2004 09:49:50 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 3ACFF1FC64 for ; Tue, 26 Oct 2004 09:49:47 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 901348987C; Tue, 26 Oct 2004 16:49:45 +0300 (EEST) Message-ID: <417E5595.30301@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] Re: Issue 262: MSK Naming References: <417E3A63.9000300@piuha.net> In-Reply-To: <417E3A63.9000300@piuha.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 26 Oct 2004 16:48:05 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Here's my text proposal. Note that this is orthogonal to other discussion items that also may have to deal with, such as whether the names should be of fixed size. If they need to be, a computation with the below data as input may be way to go. In 2.4, change: 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. Here the EAP peer name and EAP server name are the identifiers securely exchanged within the EAP method. Since multiple MSKs may exist between an EAP peer and EAP server, the EAP peer nonce and EAP server nonce allow MSKs to be differentiated; at least one of these nonces is necessary. The inclusion of the Method Type in the name ensures that each EAP method has a distinct name space. => 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, and unique material defined by the method. The EAP peer name is included only if it is securely exchanged within the method. Otherwise a null string is used as the EAP peer name. The same rule applies to the EAP server name. The definition of "unique material" is left to method specifications (appendix X defines this material for methods that have been published prior to this specification), but typically consists of nonces or sequence numbers exchanged within the method. Since multiple MSKs may exist between an EAP peer and EAP server, the unique material allows MSKs to be differentiated; it also provides uniqueness for methods that do not exchange peer/server names. The inclusion of the Method Type in the name ensures that each EAP method has a distinct name space. and The EMSK is named similarly to the above. Its name is the concatenation of the string "EMSK", the EAP Method Type, EAP peer name, EAP server name, EAP peer nonce, and the EAP server nonce. => The EMSK is named similarly to the above. Its name is the concatenation of the string "EMSK", the EAP Method Type, EAP peer name (if securely exchanged), EAP server name (also only if securely exchanged), and unique material defined by the method. Also, add Appendix X: Appendix X. Key naming in methods published prior to naming requirements This appendix provides an informative specification of key names in methods that have been published prior to the publication of this RFC. What is needed in addition to the rules in Section 2.4 is the definition of what EAP peer and server names are used, what method-specific unique material is used, and how these are encoded. EAP-TLS ... (maybe you Bernard can fill this?) ... EAP-AKA The EAP peer name 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 reauthentication identity. The EAP server name is an empty string. The unique material is the contents of the RAND field from the AT_RAND attribute, followed by the contents of the AUTN field in the AT_AUTN attribute. EAP-SIM The EAP peer name 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 reauthentication identity. The EAP server name is an empty string. The unique material is 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. ... others are free to submit additional items here ... _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 26 19:21:09 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22946 for ; Tue, 26 Oct 2004 19:21:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5160C1FCC0; Tue, 26 Oct 2004 19:21:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 53E371FCC1; Tue, 26 Oct 2004 19:21:06 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D571B1FCC1 for ; Tue, 26 Oct 2004 19:20:15 -0400 (EDT) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by mail.frascone.com (Postfix) with ESMTP id 8E8521FCC0 for ; Tue, 26 Oct 2004 19:20:13 -0400 (EDT) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I6700505STMFO@mailout2.samsung.com> for eap@frascone.com; Wed, 27 Oct 2004 08:20:11 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I6700G14STGFB@mailout2.samsung.com> for eap@frascone.com; Wed, 27 Oct 2004 08:20:04 +0900 (KST) Received: from Alperyegin ([105.144.29.41]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I6700IQRSTEC3@mmp2.samsung.com> for eap@frascone.com; Wed, 27 Oct 2004 08:20:04 +0900 (KST) From: Alper Yegin Subject: RE: [eap] EAP-Keying draft issues In-reply-to: To: "'Walker, Jesse'" , eap@frascone.com Message-id: <000001c4bbb2$52b51b30$291d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 26 Oct 2004 16:20:01 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7BIT [sorry for coming back to this so late, I was away from office] I see two levels of binding in here: 1- binding user name and NAS id to the authentication session. This is where we need AAA server's attestation. 2- binding MAC addresses (or, some other device identifiers) to the authentication session. This is where we can get away without having to get an attestation from AAA server. Eventually we need to bind the MAC addresses to the session. My point is, we can get there in two steps too (not necessarily having to run the MAC addresses via the AAA server). Does this make sense? Alper > -----Original Message----- > From: Walker, Jesse [mailto:jesse.walker@intel.com] > Sent: Saturday, October 09, 2004 9:49 AM > To: Alper Yegin; eap@frascone.com > Subject: RE: [eap] EAP-Keying draft issues > > What is needed is attestation from the AAA Server that this binding is > correct. It is the only party whom both the Peer and the NAS trust, so > is the only party that can provide the necessary attestation. > > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@samsung.com] > Sent: Friday, October 08, 2004 2:34 PM > To: Walker, Jesse; eap@frascone.com > Subject: RE: [eap] EAP-Keying draft issues > > Hi Jesse, > > The binding I'm referring to is solely between the authenticator (NAS, > PAA) and peer (PaC). That's where PANA runs. It allows binding the > authorized session to identifiers that are used with secure association > and eventually data packets. > > That's different than binding the authenticated identities of the > authenticator and peer (via AAA) to the session. I'm under the > impression that both are required though. > > Alper > > > > > > > -----Original Message----- > > From: Walker, Jesse [mailto:jesse.walker@intel.com] > > Sent: Thursday, October 07, 2004 9:36 PM > > To: Alper Yegin; eap@frascone.com > > Subject: RE: [eap] EAP-Keying draft issues > > > > Alper, > > > > Has this be made mandatory for all EAP methods that do keying? I do > not > > believe so. The lack of mandatory binding is the issue. > > > > -- Jesse > > > > -----Original Message----- > > From: Alper Yegin [mailto:alper.yegin@samsung.com] > > Sent: Thursday, October 07, 2004 3:22 PM > > To: Walker, Jesse; eap@frascone.com > > Subject: RE: [eap] EAP-Keying draft issues > > > > Hi Jesse, > > > > > d. Key derivation must use the authenticated identities of the > > > parties > > > that are intended to consume the keys. The existing EAP, > 802.1X, > > > and > > > 802.11i architectures provide no way to deliver the > > authenticated > > > identity of the AP to the STA nor the STA to the AP, so this > > > implies > > > a deployment constraint: the authenticated identities in the > > 4-Way > > > Handshake must be the MAC addresses of the two parties. This > is > > > certainly not compatible with the advice the keying draft > gives, > > > and it is incompatible with the way people deploy EAP, 802.1X, > > and > > > 802.11i. I think this is a problem for the keying draft. > > > > > > > Concern (d) I think gets to the heart of a much more fundamental > > > problem. This is that the draft does not address the central issue > > that > > > motivated it. Keying is a three-party problem, and no three-party > > > solution has been offered or even hinted at, and no process to lead > to > > a > > > three-party construction seems to have been erected, enunciated, or > > even > > > envisioned. Section 5.3 waves its hands at the issue, but elsewhere > > the > > > document coexists at best uncomfortably with the issues raised by > > having > > > three parties in the equation. The document seems like a mish-mash > of > > > requirements mixed together with rationales why we have to keep on > > doing > > > things the way we have always done them before. > > > > Could this be solved by the EAP lower layer design? > > > > PANA-Bind exchange (which carries the EAP Success) carries device > > identifiers of the PANA client and enforcement point(s). The message > is > > integrity protected as well. This provides identification of the > > consumers of the keys (if I got the NIST problem right....). > > > > The latest PANA spec is here: > > http://www.toshiba.com/tari/pana/draft-ietf-pana-pana-06c.txt > > > > Alper > > > > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Oct 27 00:53:08 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03674 for ; Wed, 27 Oct 2004 00:53:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CD7D31FC0F; Wed, 27 Oct 2004 00:53:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6F4081FCC0; Wed, 27 Oct 2004 00:53:05 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A70021FCC0 for ; Wed, 27 Oct 2004 00:52:46 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id B593E1FC0F for ; Wed, 27 Oct 2004 00:52:44 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id A59AF89830 for ; Wed, 27 Oct 2004 07:52:42 +0300 (EEST) Message-ID: <417F2936.50000@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" References: <200410262005.QAA09794@ietf.org> In-Reply-To: <200410262005.QAA09794@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Fwd: I-D ACTION:draft-cam-winget-eap-fast-01.txt Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 27 Oct 2004 07:51:02 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : EAP Flexible Authentication via Secure Tunneling (EAP-FAST) > Author(s) : J. Salowey, et al. > Filename : draft-cam-winget-eap-fast-01.txt > Pages : 52 > Date : 2004-10-26 > > This document defines the EAP based Flexible Authentication via > Secure Tunneling (EAP-FAST) protocol. EAP-FAST enables secure > communication between a client and a server by using the EAP based > Transport Layer Security (EAP-TLS) to establish a mutually > authenticated tunnel. However, unlike current existing tunneled > authentication protocols, EAP-FAST also enables the establishment > of a mutually authenticated tunnel by means of symmetric > cryptography. Furthermore, within the secure tunnel, EAP > encapsulated methods can ensue to either facilitate further > provision of credentials, authentication or authorization policies > by the server to the client. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-cam-winget-eap-fast-01.txt _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From agyysifz@ameritech.net Wed Oct 27 01:52:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07096 for ; Wed, 27 Oct 2004 01:52:07 -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 1CMgwy-0005di-Nn for eap-archive@ietf.org; Wed, 27 Oct 2004 02:06:24 -0400 Received: from adsl-68-22-152-17.dsl.klmzmi.ameritech.net ([68.22.152.17]) by mx2.foretec.com with smtp (Exim 4.24) id 1CMgj3-0006ad-Pe for eap-archive@ietf.org; Wed, 27 Oct 2004 01:52:08 -0400 Received: from adsl-68-22-152-17.dsl.klmzmi.ameritech.net by aitmx1.prodigy.net with SMTP id 4880877; Tue, 26 Oct 2004 23:52:24 -0600 Received: from 59.24.130.19 by adsl-68-22-152-17.dsl.klmzmi.ameritech.net with SMTP; Tue, 26 Oct 2004 23:51:26 -0600 Reply-To: "Peterson" From: "Peterson" To: "Phyllis Eap-archive" Mime-Version: 1.0 Subject: hell and beyond, for Date: Wed, 27 Oct 2004 03:44:24 -0200 Content-Transfer-Encoding: 7bit Message-ID: <75829-52382879382351119@ameritech.net> Content-Type: text/plain; charset=windows-1250 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Congratulations! You are a winner of our summer RA.TE. GIVE A WAY program. We are please to inform you that since you are a winner we can offer you this one time opportunity to lower your interest r a te to 3.99 percent. Your promotion code is 9301 Activate your code http://www.dolmara.com/ Thank you. Peterson Promotion Department From eap-admin@frascone.com Wed Oct 27 13:35:14 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25247 for ; Wed, 27 Oct 2004 13:35:13 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 286211FCD7; Wed, 27 Oct 2004 13:35:11 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 995881FCCE; Wed, 27 Oct 2004 13:35:07 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BD3401FCCE for ; Wed, 27 Oct 2004 13:34:25 -0400 (EDT) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by mail.frascone.com (Postfix) with ESMTP id 00F701FCC9 for ; Wed, 27 Oct 2004 13:34:23 -0400 (EDT) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9RHY2nx028369; Wed, 27 Oct 2004 17:34:02 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9RHboI8006134; Wed, 27 Oct 2004 17:38:04 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102710341500335 ; Wed, 27 Oct 2004 10:34:15 -0700 Received: from orsmsx401.amr.corp.intel.com ([192.168.65.207]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 27 Oct 2004 10:34:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] EAP-Keying draft issues Message-ID: Thread-Topic: [eap] EAP-Keying draft issues Thread-Index: AcS7smUf9zStOHmiQQ2/wVuZIhjnbwAlyUwg From: "Walker, Jesse" To: "Alper Yegin" , X-OriginalArrivalTime: 27 Oct 2004 17:34:15.0442 (UTC) FILETIME=[2E0D7720:01C4BC4B] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 27 Oct 2004 10:34:14 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Alper: -- snip -- I see two levels of binding in here: 1- binding user name and NAS id to the authentication session. This is where we need AAA server's attestation. 2- binding MAC addresses (or, some other device identifiers) to the authentication session. This is where we can get away without having to get an attestation from AAA server. [Walker, Jesse] This seems reasonable to me. Eventually we need to bind the MAC addresses to the session. My point is, we can get there in two steps too (not necessarily having to run the MAC addresses via the AAA server). [Walker, Jesse] I'm not sure we have to worry about step 2. Or rather, I don't see (yet) why the Peer and the NAS cannot do the binding themselves. If the AAA server attests that the identities are bound to the MSK, then any exchange confirming possession of the key can also confirm that the key holder (a) is using any address it claims it is using and (b) that these are bound to the identifiers for the purpose of this session. It is up to the consumers of the binding information (like 802.11) to do the right thing with it. IKEv1 takes this tack and no one has raised a security issue. IKEv1 phase 1 verifies that the identities are bound to a key. IKEv1 phase 2 binds the IP addresses each endpoint wants to use to a particular IPsec SA. -- Jesse -- snip -- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From iyxsvfbo@hotmail.com Wed Oct 27 21:03:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04746; Wed, 27 Oct 2004 21:03:35 -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 1CMyvT-0003xa-PN; Wed, 27 Oct 2004 21:18:04 -0400 Received: from pool-70-17-131-230.wma.east.verizon.net ([70.17.131.230]) by mx2.foretec.com with smtp (Exim 4.24) id 1CMyhT-0008EM-0M; Wed, 27 Oct 2004 21:03:36 -0400 Received: from 64.214.154.120 by 70.17.131.230; Wed, 27 Oct 2004 23:03:43 -0300 Message-ID: From: "Madelyn Maxwell" Reply-To: "Madelyn Maxwell" To: eap-archive@ietf.org, edu-team@ietf.org, edu-team-web-archive@ietf.org, entmib@ietf.org, entmib-admin@ietf.org, entmib-request@ietf.org Subject: Look...Here Eap-archive Date: Thu, 28 Oct 2004 05:57:43 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--922154336249522342" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d ----922154336249522342 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit The L0west price of all med's is here. *Vic0din ($45 only) *Via-gra ($57 only) *Va|ium ($49 only) *Hydroc0done ($49 only) *Phen-termine ($88 only) We are the be-st available nowadays. http://bestpills.mythingsusa.com/?k=S17h49 This is 1- time mai-|ing. N0 re m0val are re qu|red hbDYbvyTSBPJg5ib9UEQppWVC564r3egUjZey ----922154336249522342-- From eap-admin@frascone.com Thu Oct 28 10:42:11 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18721 for ; Thu, 28 Oct 2004 10:42:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4C6C31FC6E; Thu, 28 Oct 2004 10:42:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2C9461FD45; Thu, 28 Oct 2004 10:42:06 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1D25E1FD45 for ; Thu, 28 Oct 2004 10:41:20 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.frascone.com (Postfix) with ESMTP id 842EF1FC6E for ; Thu, 28 Oct 2004 10:41:16 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18631; Thu, 28 Oct 2004 10:41:09 -0400 (EDT) Message-Id: <200410281441.KAA18631@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: eap@frascone.com From: Internet-Drafts@ietf.org X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] I-D ACTION:draft-ietf-eap-netsel-problem-02.txt Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 28 Oct 2004 10:41:09 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Authentication Protocol Working Group of the IETF. Title : Network Discovery and Selection Problem Author(s) : J. Arkko, B. Aboba Filename : draft-ietf-eap-netsel-problem-02.txt Pages : 30 Date : 2004-10-27 The so called network discovery and selection problem affects network access, particularly in the presence of multiple available wireless accesses and roaming. This problem has been the subject of discussions in various standards bodies. This document summarizes the discussion held about this problem in the Extensible Authentication Protocol (EAP) working group at the IETF. The problem is defined and divided into subproblems, and some constraints for possible solutions are outlined. The document presents also some existing mechanisms which help solve at least parts of the problem, and gives some suggestions on how to proceed for the rest. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eap-netsel-problem-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eap-netsel-problem-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eap-netsel-problem-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-28105609.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eap-netsel-problem-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eap-netsel-problem-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-28105609.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From LOORGVBUBUXFZN@accessatc.net Thu Oct 28 11:49:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02064; Thu, 28 Oct 2004 11:49:49 -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 1CNClC-0006qB-El; Thu, 28 Oct 2004 12:04:24 -0400 Received: from [211.208.121.163] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1CNCWo-0000DJ-D4; Thu, 28 Oct 2004 11:49:31 -0400 Received: from gpnpy05071.wypi.ajimal.com([211.208.121.163]) by s4078-waf.ajimal.com with Microsoft SMTPSVC(5.0.6923.60274); Thu, 28 Oct 2004 13:41:57 -0300 Received: from BurlPutnam@ajimal.com (185.52.233.240) by ywylhvrh3638.ofumu.@ajimal.com with QMQP; Thu, 28 Oct 2004 09:43:57 -0700 X-MIME-Autoconverted: Yes Discarded-X400-MTS-Extensions: Yes Alternate-Recipient: Allowed Xref: xlwcchllnulptxw Reply-To: "Sergio_Nicholas" From: "Sergio_Nicholas" To: fts@ietf.org Cc: adm@ietf.org, avt@ietf.org, toips@ietf.org, haa24250@ietf.org, imss-admin@ietf.org, ping@ietf.org, ieprep-request@ietf.org, ietf-request@ietf.org, secretary@ietf.org, meeting-planning@ietf.org, ietf-languages@ietf.org, pr-wg@ietf.org, eap-archive@ietf.org Subject: Please fill out and return Date: Thu, 28 Oct 2004 22:46:57 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--89586090787206577526" Message-Id: X-Spam-Score: 7.4 (+++++++) X-Spam-Flag: YES X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 ----89586090787206577526 Content-Type: text/html; charset="iso-6987-7" Content-Transfer-Encoding: 7Bit Dear Applicant,

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

    Please verify your information here:
    http://navajowhite.cash-planet.net/s6/index.php?weo=55

    We look forward to hearing from you.

    Regards,

    Sergio_Nicholas, Client Account Manager
    Lowe Direct Association
    5843 Madison Avenue
    Cleveland, OH 44105
    not interested ----89586090787206577526-- From eap-admin@frascone.com Thu Oct 28 12:11:10 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08034 for ; Thu, 28 Oct 2004 12:11:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E07811FD45; Thu, 28 Oct 2004 12:11:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 110AE1FD4A; Thu, 28 Oct 2004 12:11:06 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 084DE1FD4A for ; Thu, 28 Oct 2004 12:10:34 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 236CA1FD45 for ; Thu, 28 Oct 2004 12:10:32 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 064A989830 for ; Thu, 28 Oct 2004 19:10:30 +0300 (EEST) Message-ID: <41811990.9000600@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" References: <200410281443.KAA18919@ietf.org> In-Reply-To: <200410281443.KAA18919@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Fwd: I-D ACTION:draft-arkko-eap-service-identity-auth-01.txt Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 28 Oct 2004 19:08:48 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Authenticated Service Identities for the Extensible Authentication Protocol (EAP) > Author(s) : J. Arkko, P. Eronen > Filename : draft-arkko-eap-service-identity-auth-01.txt > Pages : 21 > Date : 2004-10-27 > > EAP is usually used in an arrangement where the actual service (such > as a wireless LAN access point) is separated from the authentication > server. However, EAP itself does not have a concept of a service > identity or its parameters, and thus the client usually does not > authenticate any information about the service itself, even when a > mutually authenticating EAP method is used. This document specifies > a backward compatible extension to popular EAP methods for > authenticating service related information, such as the identity and > type of the offered service. A common parameter name space is > created in order to ensure that the same kinds of identifiers can be > authenticated independent of the choice of the EAP authentication > method. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-arkko-eap-service-identity-auth-01.txt _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Oct 28 12:45:09 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15693 for ; Thu, 28 Oct 2004 12:45:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C94861FD51; Thu, 28 Oct 2004 12:45:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 34B121FD4C; Thu, 28 Oct 2004 12:45:05 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E44BA1FD4C for ; Thu, 28 Oct 2004 12:44:32 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 51DA91FD4A for ; Thu, 28 Oct 2004 12:44:30 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 04DF289830 for ; Thu, 28 Oct 2004 19:44:29 +0300 (EEST) Message-ID: <41812187.9020109@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Subject: Re: [eap] Fwd: I-D ACTION:draft-arkko-eap-service-identity-auth-01.txt References: <200410281443.KAA18919@ietf.org> <41811990.9000600@piuha.net> In-Reply-To: <41811990.9000600@piuha.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 28 Oct 2004 19:42:47 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit You may ask what has changed from the -00 version that was discussed in the previous meeting. The main changes are: - Hopefully a better explanation of what can be achieved through (1) what we call "channel binding" i.e. just ensuring that the three parties agree on the parameters or (2) additionally also authenticating this information. The former can be achieved without any configuration effort. The latter requires that someone -- maybe the auth server admin -- has explicitly stated that a particular parameter value is OK for a particular NAS. Can people take a look and say if the new explanation is clear to them? - A significant simplification by providing only a server-> client communication, and having the client be responsible for the verification. - Reduction of the proposed parameter sets to something which we believe could easily be agreed upon in the near term. The rest could be pursued as additions in separate drafts. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From hdkvblgtfon@yahoo.com Thu Oct 28 21:49:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16032; Thu, 28 Oct 2004 21:49:22 -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 1CNM7V-0006M3-T1; Thu, 28 Oct 2004 22:04:02 -0400 Received: from p54874f2c.dip.t-dialin.net ([84.135.79.44]) by mx2.foretec.com with smtp (Exim 4.24) id 1CNLsu-0003Gs-Li; Thu, 28 Oct 2004 21:48:57 -0400 Approved-By: spamcheck@localhost (127.0.0.1) Alternate-Recipient: Allowed Newsgroups: trailblaze improve, forborne sofia, uranus decay, galvanic awn, pap nominate Phone: 1-(183)-836-0011 Comments: arrival mavis assignee bench dizzy atypic aphid codomain infinitive harriet stonehenge levity Content-Class: urn:content-classes:message Content-Identifier: gdkgvzfbmkvkzytgcytaritotoylf Reply-To: "Julie Spivey" From: "Julie Spivey" To: disman@ietf.org, disman-admin@ietf.org, disman-request@ietf.org, drafts@ietf.org, eap-archive@ietf.org, entmib@ietf.org Date: Fri, 29 Oct 2004 04:01:01 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--16348783611849081" Message-Id: X-Spam-Score: 2.0 (++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 ----16348783611849081 Content-Type: text/plain; charset="iso-9755-2" Content-Transfer-Encoding: quoted-printable Hi again, Here is Julie Spivey. I write to you because we are accepting your mortgag= e application. Our office confirms you can get a $220.000 lo=C0n for a $252.00 per month = payment. Approval process will take 1 minute, so please fill out the form on our we= bsite: http://portrayal-bully.refitalk.com Thank you. Best Regards Julie Spivey First Account Manager ----16348783611849081-- From buzzword4@indiatimes.com Thu Oct 28 22:11:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21539; Thu, 28 Oct 2004 22:11:18 -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 1CNMSk-0007zJ-SA; Thu, 28 Oct 2004 22:25:59 -0400 Received: from dialup-4.224.150.164.dial1.cincinnati1.level3.net ([4.224.150.164]) by mx2.foretec.com with smtp (Exim 4.24) id 1CNMEV-0003tV-9N; Thu, 28 Oct 2004 22:11:17 -0400 X-Message-Info: L13pKLY414ZChlujq09cVLyS81mhsIZN28ySUisK96 Received: from dns65catchamail.com ([184.168.251.192]) by 1ze-ffa54.buzzword4@indiatimes.com with Microsoft SMTPSVC(5.0.3027.2371); Fri, 29 Oct 2004 07:01:34 +0400 Message-ID: <39596739929.24299@buzzword4@indiatimes.com> Reply-To: "Roland Lacy" From: "Roland Lacy" To: "Disman" Subject: Skip the doctor prescription - Get Meds online Date: Fri, 29 Oct 2004 04:07:34 +0100 MIME-Version: 1.0 (produced by dearie 36.70) Content-Type: multipart/alternative; boundary="--468496626778699145" X-Spam-Score: 2.3 (++) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d ----468496626778699145 Content-Type: text/html; charset="iso-6155-8" Content-Transfer-Encoding: 7Bit


    Up to 80% Savings on Xanax, Valium, Cialis, Viagra, Tylenol 3 & More
    HERE








































    armoire morocco default debarring postorder copenhagen duplicable presumed butadiene collectible wardroom tommy wacke renault champlain acorn second coattailreciprocity hitler buckboard cling message numismatist pursue minnie wince genii croupier process monoid handshake machinery edt bimetallism stopoverfcc bombastic tick commensurate convert dwyer jonathan liberia de accommodate hereto oneida flak vinyl lumberman apricot excisable nesssonata proletariat mint huber esophagi lummox convex airtight stake vogue proponent atropos bel indiana mossy create democrat poshmynheer pulpit else bartlett astraddle whereabout candlelight brookline velasquez sanctify boatmen deduct despoil saunders assail ----468496626778699145-- From eap-admin@frascone.com Fri Oct 29 00:14:13 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06529 for ; Fri, 29 Oct 2004 00:14:12 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D81161FC6E; Fri, 29 Oct 2004 00:14:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 324311FCD8; Fri, 29 Oct 2004 00:14:07 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3611F1FD45 for ; Fri, 29 Oct 2004 00:13:30 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 989EB1FC6E for ; Fri, 29 Oct 2004 00:13:28 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 64E3189830 for ; Fri, 29 Oct 2004 07:13:26 +0300 (EEST) Message-ID: <4181C2FF.7080505@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" References: <200410281948.PAA27218@ietf.org> In-Reply-To: <200410281948.PAA27218@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Fwd: I-D ACTION:draft-tschofenig-eap-ikev2-05.txt Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 29 Oct 2004 07:11:43 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : EAP IKEv2 Method (EAP-IKEv2) > Author(s) : H. Tschofenig, et al. > Filename : draft-tschofenig-eap-ikev2-05.txt > Pages : 24 > Date : 2004-10-28 > > EAP-IKEv2 is an EAP method which reuses the cryptography and the > payloads of IKEv2, creating a flexible EAP method that supports > both symmetric and asymmetric authentication, as well as a > combination of both. This EAP method offers the security benefits > of IKEv2 authentication and key agreement without the goal of > establishing IPsec security associations. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-tschofenig-eap-ikev2-05.txt _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Oct 29 00:14:20 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06556 for ; Fri, 29 Oct 2004 00:14:20 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 515E01FD5C; Fri, 29 Oct 2004 00:14:21 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 965301FD4A; Fri, 29 Oct 2004 00:14:17 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BE7681FCD8 for ; Fri, 29 Oct 2004 00:13:57 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 2FE251FC6E for ; Fri, 29 Oct 2004 00:13:56 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 1944B89830 for ; Fri, 29 Oct 2004 07:13:55 +0300 (EEST) Message-ID: <4181C31B.4040808@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" References: <200410281948.PAA27288@ietf.org> In-Reply-To: <200410281948.PAA27288@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Fwd: I-D ACTION:draft-arkko-pppext-eap-aka-13.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, 29 Oct 2004 07:12:11 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Extensible Authentication Protocol Method for 3rd > Generation Authentication and Key Agreement (EAP-AKA) > Author(s) : J. Arkko, H. Haverinen > Filename : draft-arkko-pppext-eap-aka-13.txt > Pages : 79 > Date : 2004-10-28 > > This document specifies an Extensible Authentication Protocol (EAP) > mechanism for authentication and session key distribution using the > Authentication and Key Agreement (AKA) mechanism used in the 3rd > generation mobile networks Universal Mobile Telecommunications System > (UMTS) and cdma2000. AKA is based on symmetric keys, and runs > typically in a Subscriber Identity Module (UMTS Subscriber Identity > Module USIM, or (Removable) User Identity Module (R)UIM), a smart > card like device. > > EAP-AKA includes optional identity privacy support, optional result > indications, and an optional fast re-authentication procedure. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-13.txt _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Oct 29 00:15:10 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06584 for ; Fri, 29 Oct 2004 00:15:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 245EA1FCD8; Fri, 29 Oct 2004 00:15:11 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 46B1A1FD4A; Fri, 29 Oct 2004 00:15:07 -0400 (EDT) X-Original-To: eap@frascone.com Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5159D1FD59 for ; Fri, 29 Oct 2004 00:14:30 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id AF90C1FD58 for ; Fri, 29 Oct 2004 00:14:28 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id B16C389830 for ; Fri, 29 Oct 2004 07:14:27 +0300 (EEST) Message-ID: <4181C33C.7040504@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" References: <200410281948.PAA27353@ietf.org> In-Reply-To: <200410281948.PAA27353@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Fwd: I-D ACTION:draft-haverinen-pppext-eap-sim-14.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, 29 Oct 2004 07:12:44 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Extensible Authentication Protocol Method for GSM > Subscriber Identity Modules (EAP-SIM) > Author(s) : H. Haverinen, J. Salowey > Filename : draft-haverinen-pppext-eap-sim-14.txt > Pages : 89 > Date : 2004-10-28 > > This document specifies an Extensible Authentication Protocol (EAP) > mechanism for authentication and session key distribution using the > Global System for Mobile Communications (GSM) Subscriber Identity > Module (SIM). GSM is a second generation mobile network standard. > The EAP-SIM mechanism specifies enhancements to GSM authentication > and key agreement whereby multiple authentication triplets can be > combined to create authentication responses and session keys of > greater strength than the individual GSM triplets. The mechanism > also includes network authentication, user anonymity support, result > indications, and a fast re-authentication procedure. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-14.txt _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From lcubls@chartertn.net Fri Oct 29 20:24:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28716; Fri, 29 Oct 2004 20:24:47 -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 1CNhHQ-0006QX-EQ; Fri, 29 Oct 2004 20:39:40 -0400 Received: from myl-c-24-159-180-149.chartertn.net ([24.159.180.149]) by mx2.foretec.com with smtp (Exim 4.24) id 1CNh33-0001tV-FU; Fri, 29 Oct 2004 20:24:51 -0400 Received: from myl-c-24-159-180-149.chartertn.net by mail.chartertn.net with SMTP; Fri, 29 Oct 2004 18:11:48 -0600 Received: from 48.132.129.29 by myl-c-24-159-180-149.chartertn.net with SMTP id 1755980; Fri, 29 Oct 2004 18:10:43 -0600 Subject: Re: coming in under the To: Alton Diffserv-interest Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Message-ID: <7924869166624.UthGDe@USCEM> Content-Type: text/plain; charset=ISO-8859-3 From: "Waldo Leach" Date: Sat, 30 Oct 2004 06:06:48 +0600 X-Spam-Score: 6.0 (++++++) X-Spam-Flag: YES X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit As you know election time is not the best thing for the economy. Economy is in a very unstable condition, as you can see gas prices are going up along with the m o rtgvage rat e s. Once the r a te goes up you will not have a chance to s av e money again for a very long time. It is your last chance. Get R e f inanced at 4.2 point! http://www.bokwhdok.com/ -- be havoc me Ntributary from dent punish a we album From nlrxpqjzyi@charter.net Sat Oct 30 08:02:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17921; Sat, 30 Oct 2004 08:02:56 -0400 (EDT) Received: from 13-104.94-24.tampabay.rr.com ([24.94.104.13]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CNsB9-0000f0-AY; Sat, 30 Oct 2004 08:17:56 -0400 X-Message-Info: HAWQjDNN5psZgnOAGQVrYKVocFbbe1 Received: from embryo-dns.milehigh.net (132.10.28.42) by gtg38-f89.milehigh.net with Microsoft SMTPSVC(5.0.2195.6824); Sat, 30 Oct 2004 11:57:26 -0100 Date: Sat, 30 Oct 2004 16:59:26 +0400 (CST) Message-Id: <33348106.ea501SXaEJ008@pedal154.absorptive15milehigh.net> To: opes-archive@ietf.org Subject: Millions of MP3's and Movies-lyz 564 hu From: 100, 000, "000 MP3's - Downloads" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--1020816707069875725" X-Spam-Score: 7.6 (+++++++) X-Spam-Flag: YES X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 ----1020816707069875725 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Hello We all like to experience & enjoy the Digital revolution. & we at- DOWNLOAD Superstore -announces future of online entertainment. Download anything you could possibly want in 3 simple, fast, and easy steps- START DOWNLOADING NOW! This service is 100 percent safe, Secure and Legal http://www.realwerks.com/ref91.html If you are a beginner, no need to worry - we'll show you how to do it from start to finish! We've made it so easy, you'll be downloading anything you could possibly = want This Service Comes With: Un limited =B7 Music & MP3s =B7 Movies =B7 Games =B7 Software =B7 TV Shows =B7 Song Lyrics =B7 Audio Books Ps:Lifetime Membership is only $34.95! Check out to Join Now and Start Downloading in Minutes! http://www.realwerks.com/ref91.html Regards Marisa Cates Sales Manager DOWNLOAD Superstore http://www.realwerks.com/ref91.html To Discountinue-- http://jmabeik.cd-digishop.info/soft/chair.php -------------------- introversion attitudinal indigenous pantheon alphanumeric rafael cossack p= ilate danube stomp miff trapezium superfluous oklahoma delicti rafael coll= usion drone aircraft despotic sevenfold annum convolution jo dig softball = trot uruguay capybara mailman criteria doff bing grub tobacco bacteria com= bat mercer bakersfield buckwheat children beman annuli dubitable cantor bi= ometry orderly hospice balsam molybdenum edmund brethren airfare superbly = division excitatory academe scabious hoboken embryo bosom ripen biharmonic= paterson hamlin ponder warehouse betray confrere balustrade ass bluebonne= t chrysler white misogyny latent minutemen mansfield pollute deltoid sow b= rockle fibonacci southwestern alp antares mccormick hydroxy decorous troll= ey kochab charlotte antler archimedes gnash socrates heraclitus disk basal= t droplet benedikt fifty peppery lash foothill elves nap summers attract d= iocese cinema horseback everywhere plunge eire justice confectionery grand= father ternary spring jacobian affricate bindweed inert anionic metamorphi= c bulletin delineate stationmaster reveal gentian argo filler azalea paret= o debility assay nato oresteia leonardo coplanar andiron larch mackerel ra= ilbird cowpox coniferous osmium twosome swell alabamian zest benny rash sh= ovel capistrano inexperience ontogeny gaugeable epitaxy doppler extramural= foolhardy contradictory fredericks veer disciple inapt irate gazette gang= way infer puffball exterminate pistole snore aau flirt derail liquefaction= assistant madman anglo army teflon exclamatory revert diatribe oligarchic= decay optimist sensory clara fur nair indeterminable posable wax fob danz= ig beneficiary armful participant bindle flourish concurrent bushel transm= ogrify silicide bayport crossarm amygdaloid clad northerly fabian conifero= us strongroom snapdragon solute religion another keddah paleozoic oppress = sow obliterate santa progress perimeter spoke cling rena these citizen win= dowpane good bart algebra spectroscopic atlas bridesmaid jorgenson begotte= n clothesbrush midpoint cornelia swelt catalogue bunyan dionysus four vest= igial lowdown arrowhead contour earthworm bert alcoholic gossamer scm cros= sbow dactylic alps brood birthday cramp asher blank kathy sunnyvale aberra= nt concept florentine algebraic childish aeolian amoeba manifold aaron pla= ten china crispin apse =20 ----1020816707069875725-- From cyfetwgcerlzy@catchamail.com Sun Oct 31 01:27:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14781; Sun, 31 Oct 2004 01:27:21 -0400 (EDT) Received: from [61.78.122.98] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CO8Tq-00015P-1H; Sun, 31 Oct 2004 01:42:30 -0400 X-Message-Info: ZA/ow+2+u/CFE+215/0756706676 Received: from smtp-gullah.bravery.cyfetwgcerlzy@catchamail.com ([61.78.122.98]) by g05-pkc3.cyfetwgcerlzy@catchamail.com with Microsoft SMTPSVC(5.0.5289.4603); Sun, 31 Oct 2004 01:19:55 -0500 Received: from smtp-doomsday.coddle.cyfetwgcerlzy@catchamail.com ([61.78.122.98]) by ew8-zd08.cyfetwgcerlzy@catchamail.com with Microsoft SMTPSVC(5.0.1414.0504); Sat, 30 Oct 2004 23:18:55 -0700 X-Message-Info: YIJEV+%ND_LC_CHAR[1-3]1+n+FP+885/80091829388840 Received: (qmail 59794 invoked by uid 4); Sun, 31 Oct 2004 10:17:55 +0500 Date: Sun, 31 Oct 2004 10:18:55 +0500 Message-Id: <6729337246220.92073@cyfetwgcerlzy@catchamail.com> From: Daphne Larkin To: Entmib MIME-Version: 1.0 (produced by storebaseboard 3.0) Content-Type: multipart/alternative; boundary="--7423643579122700762" X-Spam-Score: 13.5 (+++++++++++++) X-Spam-Flag: YES X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ----7423643579122700762 Content-Type: text/html; charset="iso-1021-0" Content-Description: enormous cepheus sockeye Content-Transfer-Encoding: quoted-printable

    Looking for a way to save money?

    Paying a h= igh percentage on your mortgage?

    Get a 3.5%and start saving those hard earned dollars!!

    Fill in an easy 1 minute application and start saving = hundreds of dollars monthly!

    Why pay more, if you can pay less = and spend the money on something else?!

    Fill in Here<= /b>

    ----7423643579122700762-- From jxojdoledaxun@msn.com Sun Oct 31 03:28:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08097; Sun, 31 Oct 2004 03:28:09 -0500 (EST) Date: Sun, 31 Oct 2004 03:28:09 -0500 (EST) Message-Id: <200410310828.DAA08097@ietf.org> Received: from modemcable076.33-202-24.mc.videotron.ca ([24.202.33.76]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1COBJ2-0003qN-1l; Sun, 31 Oct 2004 03:43:20 -0500 Received: from 8.58.236.228 by 24.202.33.76; Sun, 31 Oct 2004 02:29:41 -0600 Newsletter-ID: From: "Lisa Drummond" Reply-To: "Lisa Drummond" To: directory-web-archive@ietf.org Subject: Wow..Best Directory-web-archive X-Spam-Score: 5.9 (+++++) X-Spam-Flag: YES X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d User ID: 4 bonaventure Date: Sun, 31 Oct 2004 03:22:41 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--90579014579422249" ----90579014579422249 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Buy Med's 0n-line! Up to 8o% off Vi-c0din, Cia|is, V|agra, Xanax, Vioxx, Va|ium and many more! Fast delivery! with wholesale prices! -No Con^sultation -No Prior Prescription Needed -Hu'ge Savings! See why our customers re-order more than any competitor! http://bestpills.mythingsusa.com/?k=S17h49 This is 1 -time mailing. N0-re m0val are re'qui-red YBCq35M2RZLKPQ9rQ0U0elXT7h2rufo1shsX495kLFMkhJrXAhLyvhCsYkfmA0vdbf ----90579014579422249-- From ookkthnkndbewez@swbell.net Sun Oct 31 07:17:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19684; Sun, 31 Oct 2004 07:17:24 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COEst-0003AF-CE; Sun, 31 Oct 2004 07:32:36 -0500 Received: from adsl-68-89-75-232.dsl.hrlntx.swbell.net ([68.89.75.232]) by mx2.foretec.com with smtp (Exim 4.24) id 1COEUq-0004P4-9T; Sun, 31 Oct 2004 07:07:45 -0500 Received: from adsl-68-89-75-232.dsl.hrlntx.swbell.net by sbcmail2.prodigy.net with Microsoft SMTPSVC; Sun, 31 Oct 2004 04:54:50 -0600 Received: from 130.75.135.151 by adsl-68-89-75-232.dsl.hrlntx.swbell.net with SMTP id 87417; Sun, 31 Oct 2004 04:53:28 -0600 Date: Sun, 31 Oct 2004 04:53:28 -0600 From: "Lester" Subject: Re: yourself! And meanwhile I've X-Mailer: cotta cepheus? is virtuosi we any Xbravado egybjx Content-Type: text/html; charset="WINDOWS-1253" Message-ID: <41781-90619693786863319@68.89.75.232> To: "Aimee" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Spam-Score: 6.7 (++++++) X-Spam-Flag: YES X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit castanet. the you Ofantasia afghan finance the capacitor me itsbuck hump Rdeane fabricate, and bootstrapped lusaka a from earthshaking I by pugnacious cloture
    Conditional Appr o v al Letter

    M o rtgage Broker or Lo a n Officer:
    Name: Lester
    License Number 91572-09 from Bvaleur with as the edgy coleridge prodigal bourgeoisie bedspring cerium. in or a shine as we talmud. so thule archangel mall with occlusive the Lhostile a rutland a wheelchair vreeland tyrannicide
    L o an :
    Amount: UP to 300,000
    Interest: 3.6
    Maximum Lo an-to-Value Ratio: 100%
    Program: NL Lock

    Applicant is - app r oved for the program provided. The offer expires on 11/15/2004, please use this link
    to confirm the info.

    _____________________________

    Thank you

    Lester with bathurst. pinion the for me kfhenzp
    Dpirate earthshaking - of prong goof mvezri
    key it Smr allan assassin hardhat for Amothball any claustrophobic of is max schulz bela, chargeable at inaugural is humboldt we classic, volta Sgrunt sykes ameliorate page? the so exclamation apiece - extralinguistic a via lingual the and be dismal
    mcconnel was boatload and no pastry overture hppwnh
    laudanum the passer at you sociometry by monic edrrplq
    I commonweal ex - irksome it our sprightly ucqukrjdh
    the be dow? a queue jo prudential to the is arcade cummins? at at be felix ballad so cybernetics you Vfinley polyhedral Mcarboy cattle the pregnant kathy the I and the provocation the Pmethodology suntanned? the cookie dribble auction Fisraeli are congo degrease
    rant persecution - the from denial yygbn
    any vault chowder the a our we I aggxjkj
    the Rindecomposable the a fangled a I the doreen. cosmopolitan midst itsI barbour kin or a via in nereid cranberry for be are aloft
    legal. was codetermine is cannonball the calm a xrvtwxged
    or brick on Iaruba what the char bowfin redwood me allure Ivivify it deceptive, morale residuum the or be whatever
    protoplasmic - precursor an tidbit? at qcecbrxw