From diameter-admin@frascone.com Mon Mar 1 05:14:59 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07037 for ; Mon, 1 Mar 2004 05:14:59 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F2007205AB for ; Mon, 1 Mar 2004 05:02:00 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CF2F520549 for ; Mon, 1 Mar 2004 05:00:56 -0500 (EST) Date: Mon, 01 Mar 2004 05:00:56 -0500 Message-ID: <20040301100056.6060.65626.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 Mon Mar 1 08:00:16 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16565 for ; Mon, 1 Mar 2004 08:00:15 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 291A920320; Mon, 1 Mar 2004 07:48:05 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0C41D203E9; Mon, 1 Mar 2004 07:48:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5768020327 for ; Mon, 1 Mar 2004 07:47:10 -0500 (EST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by mail.frascone.com (Postfix) with ESMTP id 5E99020320 for ; Mon, 1 Mar 2004 07:47:08 -0500 (EST) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 1 Mar 2004 13:58:59 +0100 Received: from rd.francetelecom.fr ([10.193.106.70]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Mon, 1 Mar 2004 13:58:58 +0100 Message-ID: <4043336C.3010109@rd.francetelecom.fr> From: Florent Bersani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Mar 2004 12:58:58.0753 (UTC) FILETIME=[F632BB10:01C3FF8C] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] draft-bersani-eap-psk-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: Mon, 01 Mar 2004 13:58:20 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi all, A new version of the EAP-PSK I-D (a symmetric key EAP method) is available at: http://www.arkko.com/publications/eap/draft-bersani-eap-psk-01.txt An alternate URL for the draft is: http://eappsk.chez.tiscali.fr/draft-bersani-eap-psk-01.txt I recommend *not* reading the previous version i.e. 00 (which is rather indecent ;-)) but directly this one. The short presentation I'll make on it next Thursday will briefly discuss its characteristics and focus on seeing if we want to provide the community with a symmetric key EAP method (should it be EAP-PSK or any other proposal). Sorry for the late post and many thanks to the chairs for the time slot and the I-D hosting, Cheers, Florent _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From ghyinfonet@mail.com Wed Mar 3 18:21:10 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05551 for ; Wed, 3 Mar 2004 18:21:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayffr-0006eg-00 for eap-archive@ietf.org; Wed, 03 Mar 2004 18:21:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayfeh-0006Lt-00 for eap-archive@ietf.org; Wed, 03 Mar 2004 18:20:00 -0500 Received: from [200.52.174.17] (helo=ietf.org) by ietf-mx with smtp (Exim 4.12) id 1AyfdA-0005jJ-00; Wed, 03 Mar 2004 18:18:26 -0500 From: "Fórum Social / Bombay . inb" To: disman-request@ietf.org Subject: Preocupante articulação - Informe exclusivo ref.: X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Wed, 03 Mar 2004 18:18:26 -0500 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=13.1 required=5.0 tests=FORGED_MUA_EUDORA,HTML_50_60, HTML_FONT_BIG,HTML_MESSAGE,MAILTO_SUBJ_REMOVE,MAILTO_TO_REMOVE, MAILTO_TO_SPAM_ADDR,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, MSGID_FROM_MTA_SHORT,REMOVE_REMOVAL_2WORD,SUBJ_HAS_SPACES, SUBJ_HAS_UNIQ_ID,SUBJ_ILLEGAL_CHARS autolearn=no version=2.60 X-Spam-Report: * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.5 REMOVE_REMOVAL_2WORD BODY: List removal information * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.2 HTML_50_60 BODY: Message is 50% to 60% HTML * 1.3 MAILTO_SUBJ_REMOVE BODY: mailto URI includes removal text * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email * 0.0 MAILTO_TO_REMOVE URI: Includes a 'remove' email address * 0.2 SUBJ_HAS_UNIQ_ID Subject contains a unique ID * 2.7 SUBJ_ILLEGAL_CHARS Subject contains too many raw illegal characters * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.9 FORGED_MUA_EUDORA Forged mail pretending to be from Eudora

Ref. Addr. Book: (fdp) EnEspañol - English:FreeAutomaticTranslator - Retirar-Remover

Caros amigos,

Temos o prazer de oferecer-lhes com exclusividade e gratuitamente o e-Book "4º Fórum Social Mundial: preocupante articulação revolucionária" (Bombay, 2004), elaborado pela agência hispana Destaque Internacional. Na continuação, transcrevemos o índice de tal Informe. Simplesmente faça clic em FSM-Bombay:e-BookGratuitoBr . Cordialmente, Ferreira-Passos, Atualidade Brasileira, Rio de Janeiro (RJ). Postdata importante: Para receber, também gratuitamente, o Informe sobre as próximas eleições presidenciais em El Salvador, veja links no final.

4o. Fórum Social Mundial:

preocupante articulação revolucionária

(Bombay, Janeiro 16-21, 2004)

A verdade sobre um evento alter-mundialista desdenhado por uns e admirado por outros, a respeito do qual muito se falou, porém pouco se conheceu

1. Neo-imperialismo de uma potência mundial "emergente"

Os milhares de ativistas presentes em Bombay reconhecem que a meta é transformar suas redes na "segunda potência mundial", capaz de modificar radicalmente o panorama da Índia, da Ásia e do mundo

2. O porquê da Índia

Instrumentação revolucionária de "excluídos" e galvanização das esquerdas, duas metas do FSM para o país de segunda maior população do mundo

3. "Dalits", "adivasis" e teologia da libertação

Correntes "liberacionistas" da Índia e da Ásia tentam anular o efeito sócio-político paralizante da religião brahmânica, para impulsionar a revolução socia.

4. Mumbai Resistance 2004 e MST

Evento paralelo ao 4º FSM contribui à "politização" e radicalização deste, com a colaboração do brasileiro Movimento dos Trabalhadores Rurais Sem Terra (MST)

5. Eixo contestatário Índia-Brasil

O FSM como "novo protagonista" e "ponte" para alcançar uma esquerdização da atual correlação de forças internacional

6. "Catalisação" alter-mundialista, "sinergia" e nova "racionalidade"

O evento de Bombay, enquanto enorme e preocupante articulação revolucionária, deve ser analisado segundo o sábio ensinamento de Santo Tomás: "ver, julgar e atuar"

Redação: Destaque Internacional, de Madri, com a colaboração de seus enviados especiais a Bombay, Suresh Noronha, T. F. Joseph e Sunil Abrahan. Tradução: Graça Salgueiro, Brasil.

LINKS:

FSM-Bombay:MinhaOpinião

FSM-Bombay:e-BookGratuitoBr

DestaqueInternacional:Subscrever

InformeElSalvador(ResumoEmPortuguês)

InformeElSalvador(TextoCompletoEmEspanhol)

NextMessages:OnlyInEnglish

ProximosEnvios:SoloEnEspañol

DestaqueInternacional:Retirar-Remover (nota importante: por um lamentável acidente digital foram apagados, sem serem processados, os pedidos de remoção chegados no mes de janeiro de 2004; àqueles que o tiverem feito, apresentamos nossas mais sinceras desculpas, e solicitamos re-enviarem o pedido de Remoção).

  

 

 

From eap-admin@frascone.com Wed Mar 3 19:06:28 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08424 for ; Wed, 3 Mar 2004 19:06:28 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E0E2120220; Wed, 3 Mar 2004 18:54:04 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 26C9420397; Wed, 3 Mar 2004 18:54:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AE0C620397 for ; Wed, 3 Mar 2004 18:53:33 -0500 (EST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mail.frascone.com (Postfix) with ESMTP id 0327820220 for ; Wed, 3 Mar 2004 18:53:32 -0500 (EST) 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 i2405PD1002349; Wed, 3 Mar 2004 16:05:26 -0800 (PST) Received: from jsaloweyw2k01 ([10.82.241.90]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 3 Mar 2004 16:11:39 -0800 From: "Joseph Salowey" To: , Message-ID: <009001c4017c$64bc6fe0$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.4024 In-Reply-To: <4041F5FD.4000800@piuha.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 04 Mar 2004 00:11:39.0562 (UTC) FILETIME=[43F0F0A0:01C4017D] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] RE: keying issue 221: EMSK usage guidelines Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-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, 3 Mar 2004 16:05:23 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Sunday, February 29, 2004 6:24 AM > To: eap@frascone.com; Joe Salowey > Subject: keying issue 221: EMSK usage guidelines > > > We discussed the incorporation of the EMSK guidelines > document to the keying framework in IETF-58. That discussion > ended up recommending to merge it in. So unless anyone wants > to object here, I think we should consider this issue closed. > > I looked at Joe's suggested text [1] and it looks good to me. > A couple of comments, however: > > - s/Applications/applications. > > - "The application MUST NOT use the EMSK in any other way except to > derive Application Master Session Keys (AMSK) using the key > derivation specified in this document." This seems inconsistent > with the idea that applications should only know the AMSK, not > the EMSK. > [Joe] OK, would this be better? "Applications MUST NOT use the EMSK directly, instead they use Application Master Session Keys (AMSK) derived from the EMSK using the key derivation specified in this document." > - Don't we need key names, too? Suggest branching a key naming > hierarchy from the EMSK before using it to branch AMSKs. > [Joe] Yes we need key names, but I'm not sure it is a good idea to derive public names from secret keys. I think this needs more security analysis. I think it would be better to have the EAP method export a name based on publically exchanged information. > --Jari > > [1] http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%20221 > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Mar 3 19:17:11 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09328 for ; Wed, 3 Mar 2004 19:17:11 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BF273204F8; Wed, 3 Mar 2004 19:05:05 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8F057204EB; Wed, 3 Mar 2004 19:05:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 21B09204EB for ; Wed, 3 Mar 2004 19:04:48 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 865FB20220 for ; Wed, 3 Mar 2004 19:04:46 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id C1A156A904; Thu, 4 Mar 2004 02:16:46 +0200 (EET) Message-ID: <404674E6.4030503@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joseph Salowey Cc: eap@frascone.com References: <009001c4017c$64bc6fe0$0300000a@amer.cisco.com> In-Reply-To: <009001c4017c$64bc6fe0$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) Subject: [eap] Re: keying issue 221: EMSK usage guidelines Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-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, 04 Mar 2004 02:14:30 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Joseph Salowey wrote: >>- "The application MUST NOT use the EMSK in any other way except to >> derive Application Master Session Keys (AMSK) using the key >> derivation specified in this document." This seems inconsistent >> with the idea that applications should only know the AMSK, not >> the EMSK. >> > > [Joe] OK, would this be better? "Applications MUST NOT use the EMSK > directly, instead they use Application Master Session Keys (AMSK) > derived from the EMSK using the key derivation specified in this > document." Ok. >>- Don't we need key names, too? Suggest branching a key naming >> hierarchy from the EMSK before using it to branch AMSKs. >> > > [Joe] Yes we need key names, but I'm not sure it is a good idea to > derive public names from secret keys. I think this needs more security > analysis. I think it would be better to have the EAP method export a > name based on publically exchanged information. Would this bring back the "must exchange nonces" requirement we had earlier? --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Mar 3 19:41:12 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10311 for ; Wed, 3 Mar 2004 19:41:12 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 19CB12015C; Wed, 3 Mar 2004 19:29:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B1094204F1; Wed, 3 Mar 2004 19:29:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E1E6F204F1 for ; Wed, 3 Mar 2004 19:28:25 -0500 (EST) 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 3992C2015C for ; Wed, 3 Mar 2004 19:28:24 -0500 (EST) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 03 Mar 2004 16:52:52 +0000 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 i240eMY6003578; Wed, 3 Mar 2004 16:40:22 -0800 (PST) Received: from jsaloweyw2k01 ([10.82.241.90]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 3 Mar 2004 16:46:35 -0800 From: "Joseph Salowey" To: Cc: Message-ID: <009101c40181$465a0490$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.4024 In-Reply-To: <404674E6.4030503@piuha.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 04 Mar 2004 00:46:36.0046 (UTC) FILETIME=[258B02E0:01C40182] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] RE: keying issue 221: EMSK usage guidelines Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-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, 3 Mar 2004 16:40:19 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Wednesday, March 03, 2004 4:15 PM > To: Joseph Salowey > Cc: eap@frascone.com > Subject: Re: keying issue 221: EMSK usage guidelines > > > Joseph Salowey wrote: > > >>- "The application MUST NOT use the EMSK in any other way except to > >> derive Application Master Session Keys (AMSK) using the key > >> derivation specified in this document." This seems inconsistent > >> with the idea that applications should only know the AMSK, not > >> the EMSK. > >> > > > > [Joe] OK, would this be better? "Applications MUST NOT use > the EMSK > > directly, instead they use Application Master Session Keys (AMSK) > > derived from the EMSK using the key derivation specified in this > > document." > > Ok. > > >>- Don't we need key names, too? Suggest branching a key naming > >> hierarchy from the EMSK before using it to branch AMSKs. > >> > > > > [Joe] Yes we need key names, but I'm not sure it is a good idea to > > derive public names from secret keys. I think this needs more > > security analysis. I think it would be better to have the > EAP method > > export a name based on publically exchanged information. > > Would this bring back the "must exchange nonces" requirement > we had earlier? > [Joe] I don't think so, I think that the basic requirement is that both parties in the EAP exchange can derive the same key name and that the name is unique. I'm suggesting the methods derive the key name in their own way. This could make use of nonces, it could send the key name as authenticated data in the exchange, and there are probably other possibilities as well. It might be OK to derive the key from the EMSK, but a few people I mentioned this to disliked it. In theory I suppose it increases the chance that an attacker can precompute a partial dictionary that will allow them to compromise some sessions on a network (its difficult to attack a particular session, but it may increase the possibility of compromising one arbitrary session out of many). Perhaps it is not a big deal, perhaps it is worse than I think it is. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Mar 3 19:59:12 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11002 for ; Wed, 3 Mar 2004 19:59:11 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A606F2015C; Wed, 3 Mar 2004 19:47:05 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8C048204F1; Wed, 3 Mar 2004 19:47:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2FAEE204F1 for ; Wed, 3 Mar 2004 19:46:01 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 8EA9A2015C for ; Wed, 3 Mar 2004 19:45:59 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 3BFCF6A904; Thu, 4 Mar 2004 02:58:00 +0200 (EET) Message-ID: <40467E8F.6000303@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joseph Salowey Cc: eap@frascone.com References: <009101c40181$465a0490$0300000a@amer.cisco.com> In-Reply-To: <009101c40181$465a0490$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) Subject: [eap] Re: keying issue 221: EMSK usage guidelines Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-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, 04 Mar 2004 02:55:43 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Joseph Salowey wrote: > [Joe] I don't think so, I think that the basic requirement is that both > parties in the EAP exchange can derive the same key name and that the > name is unique. I'm suggesting the methods derive the key name in their > own way. This could make use of nonces, it could send the key name as > authenticated data in the exchange, and there are probably other This would work for me. Others? > possibilities as well. It might be OK to derive the key from the EMSK, > but a few people I mentioned this to disliked it. In theory I suppose > it increases the chance that an attacker can precompute a partial > dictionary that will allow them to compromise some sessions on a network > (its difficult to attack a particular session, but it may increase the > possibility of compromising one arbitrary session out of many). Perhaps > it is not a big deal, perhaps it is worse than I think it is. Ok. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Mar 3 22:33:14 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21843 for ; Wed, 3 Mar 2004 22:33:13 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 47B4720505; Wed, 3 Mar 2004 22:21:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DDAA220500; Wed, 3 Mar 2004 22:21:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 80F8720500 for ; Wed, 3 Mar 2004 22:20:38 -0500 (EST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 93A0F1FF57 for ; Wed, 3 Mar 2004 22:20:36 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i243h0029282 for ; Wed, 3 Mar 2004 19:43:00 -0800 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 229: EAP Peer SM 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: Wed, 3 Mar 2004 19:43:00 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Issue 229: EAP Peer SM Review Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: 2/28/2004 Reference: Document: EAP-SM-02 Comment type: Technical Priority: S Section: Various Rationale/Explanation of issue: Overall: Peer and authenticator are inconsistently capitalized. Suggest using lower case for both, as is done in RFC 2284bis. Page 5 "all other EAP packets are delivered to the Peer state machine." This should instead say "EAP packets with Code set to Request, Success or Failure are delivered to the peer state machine." Page 6, Section 3.1 "connected,mutually" -> "connected, mutually" "conditions.A variable" -> "conditions. A variable" Page 7, Section 3.1 "such as that of the Method." -> "such as that of the method." Page 9 In Figure 3, the variable lastId is not initialized to NONE in the INITIALIZE state. I am not sure that (altAccept && decision != FAIL) is a condition that should lead to the SUCCESS state. Why is this not decision == UNCOND_SUCC as with a timeout? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Mar 3 22:49:13 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23052 for ; Wed, 3 Mar 2004 22:49:12 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 14BC820505; Wed, 3 Mar 2004 22:37:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9908020507; Wed, 3 Mar 2004 22:37:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2D0F320507 for ; Wed, 3 Mar 2004 22:36:33 -0500 (EST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id DBC491FF00 for ; Wed, 3 Mar 2004 22:36:30 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i243wtT30245 for ; Wed, 3 Mar 2004 19:58:55 -0800 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 214: Keying Appendix E vs. EMSK Guidelines Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-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, 3 Mar 2004 19:58:55 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The text of Issue 214 is enclosed below. The proposed resolution is as follows: Change Appendix E to the following: "Appendix E. AAA-Key Derivation As discussed in [I-D.irtf-aaaarch-handoff], [IEEE-02-758], [IEEE-03-084], and [8021XHandoff], keying material may be required for use in fast handoff between IEEE 802.11 authenticators. Where the backend authentication server provides keying material to multiple authenticators in order to fascilitate 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. 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: AAA-Key-A = MSK(0,63) AAA-Key-B = PRF(EMSK(0,63),"EAP AAA-Key derivation for multiple attachments", AAA-Key-A,B-Called-Station-Id,Calling-Station-Id) AAA-Key-E = PRF(EMSK(0,63),"EAP AAA-Key derivation for multiple attachments", AAA-Key-A,E-Called-Station-Id,Calling-Station-Id) Where: Calling-Station-Id = peer identity B-Called-Station-Id = second attachment point identity E-Called-Station-Id = third attachment point identity Here AAA-Key-A is the AAA-Key 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 E. 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)." --------------------------------------------------------------------- Issue 214: Keying appendix E vs. EMSK guidelines Submitter name: Jari Arkko Submitter email address: jari.arkko@piuha.net Date first submitted: Jan 21, 2004 Reference: Document: Keying Framework-01 Comment type: T Priority: 1 Section: Appendix E Rationale/Explanation of issue: Appendix E of keying-01 talks about the derivation of suitable AAA Keys for handoff situations. It gives the following formulae: AAA-Key-B = PRF(EMSK(0,63),AAA-Key-A, B-Called-Station-Id,Calling-Station-Id) AAA-Key-E = PRF(EMSK(0,63),AAA-Key-A, E-Called-Station-Id,Calling-Station-Id) But draft-salowey-eap-keying-02 discusses EMSK usage, and I think we have agreed at least about this: o The application MUST NOT use the EMSK in any other way except to derive Application Master Session Keys (AMSK) using the key derivation specified in section 3 this document. They MUST NOT use the EMSK directly. o Applications MUST define distinct key labels and application specific data used in the key derivation described in section 3. Appendix E appears to break the second requirement. Joe's draft gives the following construction for AMSKs: AMSK = KDF(EMSK, key label, optional application data, length) Perhaps appendix E could be corrected to be inline with this? Here's the suggested text change: AAA-Key-B = PRF(EMSK(0,63),"EAP AAA-Key derivation for multiple attachments", AAA-Key-A,B-Called-Station-Id,Calling-Station-Id) AAA-Key-E = PRF(EMSK(0,63),"EAP AAA-Key derivation for multiple attachments", AAA-Key-A,E-Called-Station-Id,Calling-Station-Id) Also, the rules about the calling and called station ids could perhaps be made less link layer specific: Calling-Station-Id = STA MAC address B-Called-Station-Id = AP B MAC address E-Called-Station-Id = AP E MAC address => Calling-Station-Id = peer identity B-Called-Station-Id = second attachment point identity E-Called-Station-Id = third attachment point identity _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Mar 3 22:52:11 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23289 for ; Wed, 3 Mar 2004 22:52:11 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 76E072053D; Wed, 3 Mar 2004 22:40:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7A30D20507; Wed, 3 Mar 2004 22:40:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 90D932051E for ; Wed, 3 Mar 2004 22:39:33 -0500 (EST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id A90A120505 for ; Wed, 3 Mar 2004 22:39:30 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i2441tU30538 for ; Wed, 3 Mar 2004 20:01:55 -0800 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 216: MSK Issues Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 3 Mar 2004 20:01:55 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The text of Issue 216 is enclosed below. The proposed resolution is to accept the proposed changes. Any objections? ----------------------------------------------------------------------- Issue 216: MSK issues Submitter name: Jari Arkko Submitter email address: jari.arkko@piuha.net Date first submitted: 1/21/2004 Reference: http://mail.frascone.com/pipermail/public/eap/2004-January/002172.html Document: Keying Framework-01 Comment type: 'T'echnical Priority: 'S' Section: Section 2.3, 4.1 Rationale/Explanation of issue: Here's a summary of the modifications I would do to fix this: o In Figure 4, s/MSK/AAA-Key/ in the Authenticator box. o In Section 4.1, replace the paragraph Utilizing the AAA protocol, the authenticator and backend authentication server mutually authenticate and derive session keys known only to them, used to provide per-packet integrity and replay protection, authentication and confidentiality. The MSK is distributed by the backend authentication server to the authenticator over this channel, bound to attributes constraining its usage, as part of the AAA-Token. The binding of attributes to the MSK within a protected package is important so the authenticator receiving the AAA-Token can determine that it has not been compromised, and that the keying material has not been replayed, or mis-directed in some way. with Utilizing the AAA protocol, the authenticator and backend authentication server mutually authenticate and derive session keys known only to them, used to provide per-packet integrity and replay protection, authentication and confidentiality. The AAA-Key is distributed by the backend authentication server to the authenticator over this channel, bound to attributes constraining its usage, as part of the AAA-Token. The binding of attributes to the AAA-Key within a protected package is important so the authenticator receiving the AAA-Token can determine that it has not been compromised, and that the keying material has not been replayed, or mis-directed in some way. o Section 2.3, replace the paragraph The MSK and EMSK are used to derive the AAA-Key and key name which are enclosed within the AAA-Token, transported to the NAS by the AAA server, and used within the secure association protocol for derivation of Transient Session Keys (TSKs) required for the negotiated ciphersuite. with The MSK and EMSK are used to derive the AAA-Key and key name. AAA-Key and key name are enclosed within the AAA-Token, which is transported to the NAS by the AAA server, and used within the secure association protocol for derivation of Transient Session Keys (TSKs) required for the negotiated ciphersuite. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Mar 3 23:03:12 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23748 for ; Wed, 3 Mar 2004 23:03:11 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B05D620503; Wed, 3 Mar 2004 22:51:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D4BAE20507; Wed, 3 Mar 2004 22:51:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A60DF20503 for ; Wed, 3 Mar 2004 22:50:45 -0500 (EST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id A39F21FF00 for ; Wed, 3 Mar 2004 22:50:43 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i244D8F31175 for ; Wed, 3 Mar 2004 20:13:08 -0800 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] Re: Issue 210: No Name for "top EAP keying material" Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-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, 3 Mar 2004 20:13:08 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The text of Issue 210 is enclosed below. One potential resolution to this is to use the term "Long Term Secret" to refer to either a long-term pre-shared key or a private key. However, in RFC 2284bis we eliminated discussion of the Master Key since not all methods use this, so I'm not sure it makes sense to add references to this in the Key Framework Document. ------------------------------------------------------------- Issue 210: No name for the "top EAP keying material" Submitter name: Florent Bersani Submitter email address: florent.bersani@francetelecom.com Date first submitted: 12/16/2003 Reference:http://mail.frascone.com/pipermail/public/eap/2003-December/001997.html Document: KeyFrame-01 Comment type: E Priority: 2 Section: 2.2 Rationale/Explanation of issue: Although the EAP hierarchy is very clearly described in section 2.2, I experienced some difficulties to present it to colleagues for a trivial reason: the top EAP key (i.e. the one that is somehow involved in the MK derivation e.g Ki in the EAP-SIM method, the private keys associated to the digital certificates used within EAP-TLS) does not appear to have a name. Things would become easier if there was standard terminology. Requested change: Add to section 2.2 at the beginning of the different key types enumerations: EAP Permanent Key (PK): To perform authentication and key exchange, an EAP method uses a permanent secret. This secret MAY belong either to the symmetric cryptography or asymmetric cryptography category. Add to Figure 2: "(PK)" near the text "EAP method" in the top left corner of the figure "(MK)" in the box labeled "EAP Method Key Derivation" Add to Figure 3: "PK," before "(MSK,TEKs)" Add to Figure 4: "PK," before "(MSK,TEKs)" Add to appendix B: "Pre-master secret": created or exchanged thanks to the PK which are digital certificates in the case of TLS [This wording "created or exchanged" wants to encompass all the TLS possibilities: RSA, DH,...] [In general, I don't like very much my wording but issue submitters have to propose solutions to their issues, don't they ;-)?] _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Mar 3 23:13:11 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24435 for ; Wed, 3 Mar 2004 23:13:10 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7D04B20507; Wed, 3 Mar 2004 23:01:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2EEFA20508; Wed, 3 Mar 2004 23:01:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AAEB920507 for ; Wed, 3 Mar 2004 23:00:33 -0500 (EST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 96B4020508 for ; Wed, 3 Mar 2004 23:00:31 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i244MuE31784 for ; Wed, 3 Mar 2004 20:22:56 -0800 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 220: Relationship between AAA-Key and MSK/EMSK Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-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, 3 Mar 2004 20:22:56 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The text of Issue 220 is enclosed below. The proposed resolution is as follows: Add the following paragraph to the beginning of Appendix E: Where a AAA-Key is generated as the result of a successful EAP authentication, the AAA-Key is set to MSK(0,63). -------------------------------------------------------- Issue 220: Relationship between AAA-Key and MSK/EMSK Submitter name: Hannes Tschofenig Submitter email address: hannes.tschofenig@siemens.com Date first submitted: 2/6/2004 Reference: http://mail.frascone.com/pipermail/public/eap/2004-February/002231.html Document: Key Framework Comment type: T Priority: S Section: Various Rationale/Explanation of issue: it is said that the AAA-Key is derived from the MSK and EMSK. the eap-keying document does not specify how this key derivation is achieved. Worse, in Section 4.2.1 the text says: " The AAA-Key is derived from the keying material exported by the EAP method (MSK and EMSK). This derivation occurs on the AAA server. In many existing protocols that use EAP, the AAA-Key and MSK are equivalent, but more complicated mechanisms are possible (see Appendix E for details). " Appendix e, however, does not help since it talks only about a very special case, namely fast handoff. We discussed this issue in one of the eap keying design team phone conferences but it got lost somehow. It would be more helpful to provide a proposal for AAA-Key to MSK/EMSK key derivation. [Joe Salowey] I agree the definition of the AAA-key seems incomplete, I think the definition is any key that is used by the authenticator and supplicant to derive keys for data traffic protection (I don't think AAA-key is the best name since it doesn't have to involve a AAA in the basic case). In the case of standard 802.11 this AAA-Key the same as the MSK. In the fast handoff example I believe additional AAA-keys are pushed to neighboring access points. In order to provide computational independence from the MSK they should be derived from the EMSK. I have submitted an issue in email http://mail.frascone.com/pipermail/eap/2004-January/002143.html (which has not yet been assigned a number) which describes how to derive keys from the EMSK for specific purposes. I think appendix e needs to be updated as discussed in Issue 214 http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%20214. I haven't had time to take a detailed look at Jari's proposal. I'm not sure why the A-AAA-Key is needed in this derivation but it is equivalent to the MSK. Could you provide some more context from your discussion? What exactly are you deriving keys to do? In my opinion it is best to use the MSK as in the case of 802.11 (single authenticator to supplicant). If keys are going to be used for other purposes, between other parties or in other ways they should be derived from the EMSK. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Mar 3 23:25:10 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25102 for ; Wed, 3 Mar 2004 23:25:09 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BF74F1FF00; Wed, 3 Mar 2004 23:13:05 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 567FE20508; Wed, 3 Mar 2004 23:13:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7527520508 for ; Wed, 3 Mar 2004 23:12:47 -0500 (EST) 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 A37971FF00 for ; Wed, 3 Mar 2004 23:12:45 -0500 (EST) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 03 Mar 2004 20:37:17 +0000 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 i244OkF8016600; Wed, 3 Mar 2004 20:24:46 -0800 (PST) Received: from jsaloweyw2k01 ([10.82.241.90]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 3 Mar 2004 20:30:59 -0800 From: "Joseph Salowey" To: "'Bernard Aboba'" , Subject: RE: [eap] Proposed resolution to Issue 220: Relationship between AAA-Key and MSK/EMSK Message-ID: <00a701c401a0$9f939160$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.4024 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 04 Mar 2004 04:31:00.0093 (UTC) FILETIME=[7EBD8AD0:01C401A1] 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, 3 Mar 2004 20:24:44 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Why isn't the AAA-Key equivalent to the MSK? Exposing the notion of a AAA-Key is not so good since it suggests things would work differently with a AAA server and without. I don't think we want this. We should not define a AAA-Key that is different than the MSK. > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of Bernard Aboba > Sent: Wednesday, March 03, 2004 8:23 PM > To: eap@frascone.com > Subject: [eap] Proposed resolution to Issue 220: Relationship > between AAA-Key and MSK/EMSK > > > The text of Issue 220 is enclosed below. The proposed > resolution is as > follows: > > Add the following paragraph to the beginning of Appendix E: > > Where a AAA-Key is generated as the result of a successful > EAP authentication, the AAA-Key is set to MSK(0,63). > > -------------------------------------------------------- > Issue 220: Relationship between AAA-Key and MSK/EMSK > Submitter name: Hannes Tschofenig > Submitter email address: hannes.tschofenig@siemens.com > Date first submitted: 2/6/2004 > Reference: > http://mail.frascone.com/pipermail/public/eap/2004-February/00 > 2231.html > Document: Key Framework > Comment type: T > Priority: S > Section: Various > Rationale/Explanation of issue: > > it is said that the AAA-Key is derived from the MSK and EMSK. > > the eap-keying document does not specify how this key > derivation is achieved. Worse, in Section 4.2.1 the text says: > > " The AAA-Key is derived from the keying material exported by the EAP > method (MSK and EMSK). This derivation occurs on the AAA > server. In > many existing protocols that use EAP, the AAA-Key and MSK are > equivalent, but more complicated mechanisms are possible (see > Appendix E for details). > " > > Appendix e, however, does not help since it talks only about > a very special case, namely fast handoff. > > We discussed this issue in one of the eap keying design team > phone conferences but it got lost somehow. > > It would be more helpful to provide a proposal for AAA-Key to > MSK/EMSK key derivation. > > [Joe Salowey] > > I agree the definition of the AAA-key seems incomplete, I > think the definition is any key that is used by the > authenticator and supplicant to derive keys for data traffic > protection (I don't think AAA-key is the best name since it > doesn't have to involve a AAA in the basic case). In the case > of standard 802.11 this AAA-Key the same as the MSK. In the > fast handoff example I believe additional AAA-keys are pushed > to neighboring access points. In order to provide > computational independence from the MSK they should be > derived from the EMSK. > > I have submitted an issue in email > http://mail.frascone.com/pipermail/eap/2004-January/002143.htm l (which has not yet been assigned a number) which describes how to derive keys from the EMSK for specific purposes. I think appendix e needs to be updated as discussed in Issue 214 http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%20214. I haven't had time to take a detailed look at Jari's proposal. I'm not sure why the A-AAA-Key is needed in this derivation but it is equivalent to the MSK. Could you provide some more context from your discussion? What exactly are you deriving keys to do? In my opinion it is best to use the MSK as in the case of 802.11 (single authenticator to supplicant). If keys are going to be used for other purposes, between other parties or in other ways they should be derived from the EMSK. _______________________________________________ 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 Mar 3 23:31:11 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25349 for ; Wed, 3 Mar 2004 23:31:10 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E29E41FF00; Wed, 3 Mar 2004 23:19:05 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A8DF02051E; Wed, 3 Mar 2004 23:19:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3439F2051E for ; Wed, 3 Mar 2004 23:18:21 -0500 (EST) 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 730BE1FF00 for ; Wed, 3 Mar 2004 23:18:19 -0500 (EST) 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 i244UKF8023140; Wed, 3 Mar 2004 20:30:20 -0800 (PST) Received: from jsaloweyw2k01 ([10.82.241.90]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 3 Mar 2004 20:36:33 -0800 From: "Joseph Salowey" To: "'Bernard Aboba'" , Subject: RE: [eap] Proposed Resolution to Issue 216: MSK Issues Message-ID: <00aa01c401a1$6687e140$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.4024 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 04 Mar 2004 04:36:33.0890 (UTC) FILETIME=[45B2EC20:01C401A2] 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, 3 Mar 2004 20:30:17 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of Bernard Aboba > Sent: Wednesday, March 03, 2004 8:02 PM > To: eap@frascone.com > Subject: [eap] Proposed Resolution to Issue 216: MSK Issues > > > The text of Issue 216 is enclosed below. The proposed > resolution is to accept the proposed changes. Any objections? > > -------------------------------------------------------------- > --------- > Issue 216: MSK issues > Submitter name: Jari Arkko > Submitter email address: jari.arkko@piuha.net > Date first submitted: 1/21/2004 > Reference: > http://mail.frascone.com/pipermail/public/eap/2004-January/002172.html > Document: Keying Framework-01 > Comment type: 'T'echnical > Priority: 'S' > Section: Section 2.3, 4.1 > Rationale/Explanation of issue: > > Here's a summary of the modifications I would do to fix this: > > o In Figure 4, s/MSK/AAA-Key/ in the Authenticator box. > > o In Section 4.1, replace the paragraph > > Utilizing the AAA protocol, the authenticator and backend > authentication server mutually authenticate and derive > session keys > known only to them, used to provide per-packet integrity > and replay > protection, authentication and confidentiality. The MSK is > distributed by the backend authentication server to the > authenticator > over this channel, bound to attributes constraining its usage, as > part of the AAA-Token. The binding of attributes to the > MSK within a > protected package is important so the authenticator receiving the > AAA-Token can determine that it has not been compromised, and that > the keying material has not been replayed, or mis-directed in some > way. > > with > > Utilizing the AAA protocol, the authenticator and backend > authentication server mutually authenticate and derive > session keys > known only to them, used to provide per-packet integrity > and replay > protection, authentication and confidentiality. The AAA-Key is > distributed by the backend authentication server to the > authenticator > over this channel, bound to attributes constraining its usage, as > part of the AAA-Token. The binding of attributes to the > AAA-Key within a > protected package is important so the authenticator receiving the > AAA-Token can determine that it has not been compromised, and that > the keying material has not been replayed, or mis-directed in some > way. [Joe] I prefer the original text. We should use the MSK instead of AAA-Key. > > o Section 2.3, replace the paragraph > > The MSK and EMSK are used to derive the AAA-Key and key name which > are enclosed within the AAA-Token, transported to the > NAS by the AAA > server, and used within the secure association protocol for > derivation of Transient Session Keys (TSKs) required for the > negotiated ciphersuite. > > with > > The MSK and EMSK are used to derive the AAA-Key and key > name. AAA-Key > and key name are enclosed within the AAA-Token, which is > transported to the > NAS by the AAA server, and used within the secure > association protocol for > derivation of Transient Session Keys (TSKs) required for the > negotiated ciphersuite. > [Joe] The MSK instead of AAA-Key. It is not clear that it is a good idea to derive the name from a key. I think it is preferable that the name be exported from the method. > _______________________________________________ > 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 Mar 3 23:45:10 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26845 for ; Wed, 3 Mar 2004 23:45:10 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DD4901FF00; Wed, 3 Mar 2004 23:33:05 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 88CD020507; Wed, 3 Mar 2004 23:33:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D593920507 for ; Wed, 3 Mar 2004 23:32:40 -0500 (EST) 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 01F981FF00 for ; Wed, 3 Mar 2004 23:32:38 -0500 (EST) 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 i244idF8003067; Wed, 3 Mar 2004 20:44:40 -0800 (PST) Received: from jsaloweyw2k01 ([10.82.241.90]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 3 Mar 2004 20:50:53 -0800 From: "Joseph Salowey" To: "'Bernard Aboba'" , Subject: RE: [eap] Proposed Resolution to Issue 214: Keying Appendix E vs. EMSK Guidelines Message-ID: <00ad01c401a3$66fb9fc0$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.4024 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 04 Mar 2004 04:50:53.0835 (UTC) FILETIME=[46441DB0:01C401A4] 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, 3 Mar 2004 20:44:37 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of Bernard Aboba > Sent: Wednesday, March 03, 2004 7:59 PM > To: eap@frascone.com > Subject: [eap] Proposed Resolution to Issue 214: Keying > Appendix E vs. EMSK Guidelines > > > The text of Issue 214 is enclosed below. The proposed > resolution is as > follows: > > Change Appendix E to the following: > > "Appendix E. AAA-Key Derivation > > As discussed in [I-D.irtf-aaaarch-handoff], [IEEE-02-758], > [IEEE-03-084], and [8021XHandoff], keying material may be > required for use in fast handoff between IEEE 802.11 > authenticators. Where the backend authentication server > provides keying material to multiple authenticators in order > to fascilitate 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. 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: > [Joe] DO you think that keys will always be distributed from the AAA or may it be distributed from a separate server? If it is possible that you may want to distribute this functionality then you should derive a separate AMSK from the EMSK so you avoid exporting the EMSK. > AAA-Key-A = MSK(0,63) > > AAA-Key-B = PRF(EMSK(0,63),"EAP AAA-Key derivation for > multiple attachments", > AAA-Key-A,B-Called-Station-Id,Calling-Station-Id) [Joe] 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) > > AAA-Key-E = PRF(EMSK(0,63),"EAP AAA-Key derivation for > multiple attachments", > AAA-Key-A,E-Called-Station-Id,Calling-Station-Id) > [Joe] AAA-Key-E = PRF(EMSK(0,63),"EAP AAA-Key derivation for multiple attachments", AAA-Key-A,E-Called-Station-Id,Calling-Station-Id, length) > Where: > > Calling-Station-Id = peer identity > B-Called-Station-Id = second attachment point identity > E-Called-Station-Id = third attachment point identity [Joe] length = length of derived key material > > Here AAA-Key-A is the AAA-Key derived during the initial EAP [Joe] Here the AAA-Key-A is the MSK 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 E. 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)." > > --------------------------------------------------------------------- > Issue 214: Keying appendix E vs. EMSK guidelines > Submitter name: Jari Arkko > Submitter email address: jari.arkko@piuha.net > Date first submitted: Jan 21, 2004 > Reference: > Document: Keying Framework-01 > Comment type: T > Priority: 1 > Section: Appendix E > Rationale/Explanation of issue: > > Appendix E of keying-01 talks about the derivation of > suitable AAA Keys for handoff situations. It gives the > following formulae: > > AAA-Key-B = PRF(EMSK(0,63),AAA-Key-A, > B-Called-Station-Id,Calling-Station-Id) > > AAA-Key-E = PRF(EMSK(0,63),AAA-Key-A, > E-Called-Station-Id,Calling-Station-Id) > > But draft-salowey-eap-keying-02 discusses EMSK usage, and > I think we have agreed at least about this: > > o The application MUST NOT use the EMSK in any other > way except to > derive Application Master Session Keys (AMSK) using the key > derivation specified in section 3 this document. > They MUST NOT > use the EMSK directly. > > o Applications MUST define distinct key labels and application > specific data used in the key derivation described > in section 3. > > Appendix E appears to break the second requirement. Joe's > draft gives the following construction for AMSKs: > > AMSK = KDF(EMSK, key label, optional application data, length) > > Perhaps appendix E could be corrected to be inline with this? > Here's the suggested text change: > > AAA-Key-B = PRF(EMSK(0,63),"EAP AAA-Key derivation > for multiple > attachments", > AAA-Key-A,B-Called-Station-Id,Calling-Station-Id) > > AAA-Key-E = PRF(EMSK(0,63),"EAP AAA-Key derivation > for multiple > attachments", > AAA-Key-A,E-Called-Station-Id,Calling-Station-Id) > > Also, the rules about the calling and called station ids > could perhaps be made less link layer specific: > > Calling-Station-Id = STA MAC address > B-Called-Station-Id = AP B MAC address > E-Called-Station-Id = AP E MAC address > > => > > Calling-Station-Id = peer identity > B-Called-Station-Id = second attachment point identity > E-Called-Station-Id = third attachment point identity > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Mar 4 00:08:12 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28593 for ; Thu, 4 Mar 2004 00:08:11 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EA40120559; Wed, 3 Mar 2004 23:56:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 476AD2051E; Wed, 3 Mar 2004 23:56:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4A69820291 for ; Wed, 3 Mar 2004 23:55:13 -0500 (EST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 0DD3C1FF57 for ; Wed, 3 Mar 2004 23:55:11 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i245HZH02801 for ; Wed, 3 Mar 2004 21:17:35 -0800 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 15: NASREQ Key Distribution Insecure Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-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, 3 Mar 2004 21:17:35 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The text of Issue 15 is enclosed below. The proposed resolution is as follows: Add Section 6.6 and 6.7: "6.6 Channel binding It is possible for a compromised or poorly implemented EAP authenticator to communicate incorrect information to the EAP peer and/or server. This may enable an authenticator to impersonate another authenticator or communicate incorrect information via out-of-band mechanisms (such as via a AAA or lower layer protocol). Where EAP is used in pass-through mode, the EAP peer typically does not verify the identity of the pass-through authenticator, it only verifies that the pass-through authenticator is trusted by the EAP server. This creates a potential security vulnerability, described in Section 7.15 of [RFC2284bis]. Section 4.3.7 of [RFC3579] describes how an EAP pass-through authenticator acting as a AAA client can be detected if it attempts to impersonate another authenticator (such by sending incorrect NAS-Identifier [RFC2865], NAS-IP-Address [RFC2865] or NAS-IPv6-Address [RFC3162] attributes via the AAA protocol). However, it is possible for a pass-through authenticator acting as a AAA client to provide correct information to the AAA server while communicating misleading information to the EAP peer via a lower layer protocol. For example, it is possible for a compromised authenticator to utilize another authenticator's Called-Station-Id or NAS-Identifier in communicating with the EAP peer via a lower layer protocol, or for a pass-through authenticator acting as a AAA client to provide an incorrect peer Calling-Station-Id [RFC2865][RFC3580] to the AAA server via the AAA protocol. As noted in Section 7.15 of [RFC2284bis] this vulnerability can be addressed by use of EAP methods that support a protected exchange of channel properties such as endpoint identifiers, including (but not limited to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id [RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address [RFC2865], and NAS-IPv6-Address [RFC3162]. Using such a protected exchange, it is possible to match the channel properties provided by the authenticator via out-of-band mechanisms against those exchanged within the EAP method. 6.7 Key Scoping A AAA-Key provided by the authentication server to the authenticator, is for use only by that authenticator. While AAA protocols such as RADIUS [RFC2865] or Diameter [RFC3588] support mutual authentication between the AAA client and server, the authentication is based on the claimed identity of the AAA client. In the case of RADIUS, the shared secret used for authentication is determined by the source address of the RADIUS packet. As noted in [RFC3579] Section 4.3.7, it is highly desirable that the source address be checked against one or more NAS identification attributes so as to detect and prevent impersonation attacks. A wide variety of authenticator designs are possible, including authenticators comprising a small or large number of virtual or actual ports; authenticators supporting multiple "virtual authenticators"; authenticators with multiple CPUs utilizing symmetric multi-processing; clustered authenticators supporting load balancing or failover, etc. Similarly, a wide variety of peer designs are possible, including peers supporting multiple interfaces; clustered peers, etc. AAA protocols merely mutually authenticate the AAA client and server but do not distinguish between different authenticator architectures. By default, the AAA-Key provided by the AAA server may be used on an unrestricted basis solely by the authenticator receiving the AAA-Key. This may have some unexpected consequences. For example, where a single physical authenticator can act as multiple "virtual authenticators", unless each "virtual authenticator" identifies itself distinctly to the AAA server, then a AAA-Key provided by the AAA server is for use by any of the "virtual authenticators". This enables potential security vulnerabilities. For example, an EAP peer could authenticate with the "guest" "virtual authenticator" and negotiate a AAA-Key. The peer could then attempt to use that AAA-Key to do a fast handoff to the "Corporate Intranet" virtual authenticator within the same physical authenticator. If the virtual authenticators do not identify themselves distinctly to the AAA server, then the key cache will be shared in common and the fast handoff attempt will be successful. In order to address this vulnerability, authenticators need to cache not only the AAA-Keys, but also the associated authorizations. This ensures that an attacker could not obtain elevated privileges even if they could authenticate successfully to another "virtual authenticator" hosted within the same physical chassis. If further protection is required, it is advisable for the AAA server to explicitly restrict the AAA-Key scope by including additional scope restriction attributes within the AAA-Token. Examples of scope restriction attributesw include: * Virtual authenticator restrictions. In the case of 802.11, this could involve including a list of authorized Called-Station-Ids or SSIDs for which the AAA-Key is valid. * Peer restrictions. In the case of 802.11, this could involve including a list of authorized Calling-Station-Ids for which the AAA-Key is valid. Note that in restricting the use of the AAA-Key it is important to ensure that the EAP peer can be made aware of the restriction so that the peer and authenticator can behave consistently." ---------------------------------------------------------------------- Issue 15: Key Distribution Insecure Submitter: Jesse Walker Submitter email address: jesse.walker@intel.com Date first submitted: March 2, 2002 Reference: http://www.drizzle.com/~aboba/AAA/issues3.html#Issue 294 Document: RFC2548 Comment type: T Priority: S Section: 2.4.2, 2.4.3 Rationale/Explanation of issue: This issue relates to binding and scope restriction. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Mar 4 00:56:11 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02066 for ; Thu, 4 Mar 2004 00:56:11 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9A6BF1FF4E; Thu, 4 Mar 2004 00:44:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1D4222039E; Thu, 4 Mar 2004 00:44:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 67EFB2039E for ; Thu, 4 Mar 2004 00:43:17 -0500 (EST) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id C5B991FF4E for ; Thu, 4 Mar 2004 00:43:15 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id i245tIJV014223; Thu, 4 Mar 2004 00:55:18 -0500 (EST) From: Nick Petroni To: Bernard Aboba Cc: Subject: Re: [eap] Issue 229: EAP Peer SM Review In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 4 Mar 2004 00:55:18 -0500 (EST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) I have put up a -03a to address some of these. comments inline. http://www.cs.umd.edu/~npetroni/EAP/ > Peer and authenticator are inconsistently capitalized. Suggest > using lower case for both, as is done in RFC 2284bis. [np] Fixed I think. let me know if I missed any. > Page 5 > > "all other EAP packets are delivered to the Peer state machine." > > This should instead say "EAP packets with Code set to > Request, Success or Failure are delivered to the peer state machine." [np] fixed. > Page 6, Section 3.1 > > "connected,mutually" -> "connected, mutually" > > "conditions.A variable" -> "conditions. A variable" [np] aaah. gotta love acroread in Linux. besides its propensity to crash when searching it also copies horribly at the end of the line. nice catch. > > Page 7, Section 3.1 > > "such as that of the Method." -> "such as that of the method." [np] fixed. > > Page 9 > > In Figure 3, the variable lastId is not initialized to NONE in the > INITIALIZE state. > > I am not sure that (altAccept && decision != FAIL) is a condition that > should lead to the SUCCESS state. Why is this not > decision == UNCOND_SUCC as with a timeout? [np] It seems that altAccept is an alternative to rxSuccess so it should be equivalent to that input I think. The current diagram shows rxSuccess && (reqId == lastId) && (decision != FAIL). So, if you change one, you should have to change both right? I think it's right as is, but I could be convinced otherwise. I think the idea behind decision is as follows: UNCOND_SUCC peer already knows auth's decision is yes and wants to accept. Since it knows the decision, it can assume the success packet was lost in transit on a timeout. COND_SUCC peer wants to accept, but doesn't yet know what the auth has decided. It therefore needs some indication of success to go to the SUCCESS state. FAIL peer or auth is not happy, either way don't go to success I think the point is that timeout requires you to KNOW you have succeeded (decision=UNCOND_SUCC) whereas success/altAccept *is* the indication you are waiting for when decision=COND_SUCC. So, those events can transition to SUCCESS when decision is COND_SUCC as well. Does that make sense? regards, nick _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Mar 4 01:51:21 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06527 for ; Thu, 4 Mar 2004 01:51:20 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CA00820568; Thu, 4 Mar 2004 01:39:05 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8236D2055B; Thu, 4 Mar 2004 01:39:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5C2BE2055B for ; Thu, 4 Mar 2004 01:38:40 -0500 (EST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by mail.frascone.com (Postfix) with ESMTP id 61F391FF4E for ; Thu, 4 Mar 2004 01:38:38 -0500 (EST) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 4 Mar 2004 07:50:15 +0100 Received: from rd.francetelecom.fr ([10.193.106.62]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Thu, 4 Mar 2004 07:50:14 +0100 Message-ID: <4046D186.5010205@rd.francetelecom.fr> From: Florent Bersani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] Re: Issue 210: No Name for "top EAP keying material" References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Mar 2004 06:50:14.0854 (UTC) FILETIME=[F290E660:01C401B4] 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, 04 Mar 2004 07:49:42 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Bernard Aboba wrote: >The text of Issue 210 is enclosed below. One potential resolution to this >is to use the term "Long Term Secret" to refer to either a long-term >pre-shared key or a private key. However, in RFC 2284bis we eliminated >discussion of the Master Key since not all methods use this, so I'm not >sure it makes sense to add references to this in the Key Framework >Document. > > I agree with you so why not "EAP (long term?) credential". Wouldn't this wording allow for unambiguous naming of the root of the EAP key hierarchy Hierarchy and at the same time apply to the whole variety of methods' "root keys" (symmetric, asymmetric, OTP,...) - my quick answer, I'll go to the list to review the previous debates So I suggest using the label "EAP long-term credential" and including text to explain that this credential might be instantiated in numerous ways: "The EAP (long term) credential is the credential the peer and the server resort to when doing a full EAP authentication*. It might be a symmetric cryptography key, an asymmetric cryptography key, a one-time password generator,..." My feeling was though that you only have (for now) essentially two types of credentials: symmetric and asymmetric ones. Anyway, it is a minor issue but it in my opinion, naming the top of the tree would help to clarify things. What do you think? Florent *I am still not happy with the wording since I feel "EAP full authentication" would have to be defined but my mentioning this here was that in fast reconnect schemes, you may not use the EAP (long term?) credential >------------------------------------------------------------- >Issue 210: No name for the "top EAP keying material" >Submitter name: Florent Bersani >Submitter email address: florent.bersani@francetelecom.com >Date first submitted: 12/16/2003 >Reference:http://mail.frascone.com/pipermail/public/eap/2003-December/001997.html >Document: KeyFrame-01 >Comment type: E >Priority: 2 >Section: 2.2 >Rationale/Explanation of issue: > >Although the EAP hierarchy is very clearly described in section 2.2, I >experienced some difficulties to present it to colleagues for a trivial >reason: the top EAP key (i.e. the one that is somehow involved in the MK >derivation e.g Ki in the EAP-SIM method, the private keys associated to >the digital certificates used within EAP-TLS) does not appear to have a >name. Things would become easier if there was standard terminology. > >Requested change: > >Add to section 2.2 at the beginning of the different key types >enumerations: > >EAP Permanent Key (PK): >To perform authentication and key exchange, an EAP method uses a >permanent secret. This secret MAY belong either to the symmetric >cryptography or asymmetric cryptography category. > >Add to Figure 2: >"(PK)" near the text "EAP method" in the top left corner of the figure >"(MK)" in the box labeled "EAP Method Key Derivation" > >Add to Figure 3: >"PK," before "(MSK,TEKs)" > >Add to Figure 4: >"PK," before "(MSK,TEKs)" > >Add to appendix B: > >"Pre-master secret": created or exchanged thanks to the PK which are >digital certificates in the case of TLS > >[This wording "created or exchanged" wants to encompass all the TLS >possibilities: RSA, DH,...] > >[In general, I don't like very much my wording but issue submitters have >to propose solutions to their issues, don't they ;-)?] >_______________________________________________ >eap mailing list >eap@frascone.com >http://mail.frascone.com/mailman/listinfo/eap > > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Mar 4 02:08:13 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16888 for ; Thu, 4 Mar 2004 02:08:12 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D93AD202A2; Thu, 4 Mar 2004 01:56:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 41AF020562; Thu, 4 Mar 2004 01:56:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 92D0120562 for ; Thu, 4 Mar 2004 01:55:20 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id BB9F5202A2 for ; Thu, 4 Mar 2004 01:55:18 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 8EC3C6A906; Thu, 4 Mar 2004 09:07:19 +0200 (EET) Message-ID: <4046D51F.3090401@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joseph Salowey Cc: "'Bernard Aboba'" , eap@frascone.com Subject: Re: [eap] Proposed resolution to Issue 220: Relationship between AAA-Key and MSK/EMSK References: <00a701c401a0$9f939160$0300000a@amer.cisco.com> In-Reply-To: <00a701c401a0$9f939160$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, 04 Mar 2004 09:05:03 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Joseph Salowey wrote: > Why isn't the AAA-Key equivalent to the MSK? Exposing the notion of a > AAA-Key is not so good since it suggests things would work differently > with a AAA server and without. I don't think we want this. We should > not define a AAA-Key that is different than the MSK. Isn't this what Bernard was trying to do when he said: >>Add the following paragraph to the beginning of Appendix E: >> >>Where a AAA-Key is generated as the result of a successful >>EAP authentication, the AAA-Key is set to MSK(0,63). Or is your issue Joe that the length difference causes something? Or that the pure existence of a value called the AAA key is harmful, because that implies the existence of AAA, which might not always be present? I think we need a quantity for this purpose. I'm even fine with the value being called "MSK" if the length and other considerations allow it. Or we could call it the FOO-Key, always present in an authenticator, be it a AAA-based or a standalone... --Jari >>-------------------------------------------------------- >>Issue 220: Relationship between AAA-Key and MSK/EMSK >>Submitter name: Hannes Tschofenig >>Submitter email address: hannes.tschofenig@siemens.com >>Date first submitted: 2/6/2004 >>Reference: >>http://mail.frascone.com/pipermail/public/eap/2004-February/00 >>2231.html >>Document: Key Framework >>Comment type: T >>Priority: S >>Section: Various >>Rationale/Explanation of issue: >> >>it is said that the AAA-Key is derived from the MSK and EMSK. >> >>the eap-keying document does not specify how this key >>derivation is achieved. Worse, in Section 4.2.1 the text says: >> >>" The AAA-Key is derived from the keying material exported by the EAP >> method (MSK and EMSK). This derivation occurs on the AAA >>server. In >> many existing protocols that use EAP, the AAA-Key and MSK are >> equivalent, but more complicated mechanisms are possible (see >> Appendix E for details). >>" >> >>Appendix e, however, does not help since it talks only about >>a very special case, namely fast handoff. >> >>We discussed this issue in one of the eap keying design team >>phone conferences but it got lost somehow. >> >>It would be more helpful to provide a proposal for AAA-Key to >>MSK/EMSK key derivation. >> >>[Joe Salowey] >> >>I agree the definition of the AAA-key seems incomplete, I >>think the definition is any key that is used by the >>authenticator and supplicant to derive keys for data traffic >>protection (I don't think AAA-key is the best name since it >>doesn't have to involve a AAA in the basic case). In the case >>of standard 802.11 this AAA-Key the same as the MSK. In the >>fast handoff example I believe additional AAA-keys are pushed >>to neighboring access points. In order to provide >>computational independence from the MSK they should be >>derived from the EMSK. >> >>I have submitted an issue in email >>http://mail.frascone.com/pipermail/eap/2004-January/002143.htm > > l (which has not yet been assigned a number) which describes how to > derive keys > from the EMSK for specific purposes. I think appendix e needs to be > updated as discussed in Issue 214 > http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%20214. I haven't > had time to take a detailed look at Jari's proposal. I'm not sure why > the A-AAA-Key is needed in this derivation but it is equivalent to the > MSK. > > Could you provide some more context from your discussion? What exactly > are you deriving keys to do? In my opinion it is best to use the MSK as > in the case of 802.11 (single authenticator to supplicant). If keys are > going to be used for other purposes, between other parties or in other > ways they should be derived from the EMSK. > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Mar 4 12:44:23 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03878 for ; Thu, 4 Mar 2004 12:44:22 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1A37D20574; Thu, 4 Mar 2004 12:32:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E55DB20518; Thu, 4 Mar 2004 12:32:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A910820519 for ; Thu, 4 Mar 2004 12:31:03 -0500 (EST) 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 B67A52027E for ; Thu, 4 Mar 2004 12:31:01 -0500 (EST) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 04 Mar 2004 09:55:41 +0000 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 i24Hh0F8018331; Thu, 4 Mar 2004 09:43:01 -0800 (PST) Received: from jsaloweyw2k01 ([10.82.225.93]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 4 Mar 2004 09:49:16 -0800 From: "Joseph Salowey" To: Cc: "'Bernard Aboba'" , Subject: RE: [eap] Proposed resolution to Issue 220: Relationship between AAA-Key and MSK/EMSK Message-ID: <00d501c40210$23f2bf20$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.4024 In-Reply-To: <4046D51F.3090401@piuha.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 04 Mar 2004 17:49:16.0835 (UTC) FILETIME=[036C5F30:01C40211] 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, 4 Mar 2004 09:43:00 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Jari, I think this is mostly a naming issue. AAA-Key indicates something specific to AAA, which I don't think is appropriate. Instead of AAA-Key perhaps we should use something like Application Master Session Key (AMSK). Here is some text along what I am thinking. It needs some work, but here is the general idea: EAP may provide keying material to multiple applications. Each application should have its own computationally independent AMSK. Traditionally the application used with EAP is link layer ciphering. In this case the AMSK is derived from the MSK[0..64]. Since some link layer ciphering applications use this key directly (dynamic-wep) it is NOT RECOMMENDED that the MSK be used to derive keys for other purposes. For other applications the AMSK SHOULD be derived from the EMSK using the guidelines outlined in the document. In some cases the AMSK must be transferred from an EAP Server to a NAS or other device. In this case an AMSK is transmitted in a AAA-Token (perhaps key-token is better?) containing the AMSK and the AMSK name. Applications must define what parameters are used in deriving the AMSK and how the keys are used. In some cases they will have to define how the AAA-token/key-token is transferred from the EAP server to where it is used. Do you agree with this direction? Joe > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Wednesday, March 03, 2004 11:05 PM > To: Joseph Salowey > Cc: 'Bernard Aboba'; eap@frascone.com > Subject: Re: [eap] Proposed resolution to Issue 220: > Relationship between AAA-Key and MSK/EMSK > > > > Joseph Salowey wrote: > > Why isn't the AAA-Key equivalent to the MSK? Exposing the > notion of a > > AAA-Key is not so good since it suggests things would work > differently > > with a AAA server and without. I don't think we want this. > We should > > not define a AAA-Key that is different than the MSK. > > Isn't this what Bernard was trying to do when he said: > > >>Add the following paragraph to the beginning of Appendix E: > >> > >>Where a AAA-Key is generated as the result of a successful > >>EAP authentication, the AAA-Key is set to MSK(0,63). > > Or is your issue Joe that the length difference causes > something? Or that the pure existence of a value called the > AAA key is harmful, because that implies the existence of > AAA, which might not always be present? > > I think we need a quantity for this purpose. I'm even fine > with the value being called "MSK" if the length and other > considerations allow it. Or we could call it the FOO-Key, > always present in an authenticator, be it a AAA-based or a > standalone... > > --Jari > > >>-------------------------------------------------------- > >>Issue 220: Relationship between AAA-Key and MSK/EMSK > Submitter name: > >>Hannes Tschofenig Submitter email address: > >>hannes.tschofenig@siemens.com Date first submitted: 2/6/2004 > >>Reference: > >>http://mail.frascone.com/pipermail/public/eap/2004-February/00 > >>2231.html > >>Document: Key Framework > >>Comment type: T > >>Priority: S > >>Section: Various > >>Rationale/Explanation of issue: > >> > >>it is said that the AAA-Key is derived from the MSK and EMSK. > >> > >>the eap-keying document does not specify how this key > >>derivation is achieved. Worse, in Section 4.2.1 the text says: > >> > >>" The AAA-Key is derived from the keying material exported > by the EAP > >> method (MSK and EMSK). This derivation occurs on the AAA > >>server. In > >> many existing protocols that use EAP, the AAA-Key and MSK are > >> equivalent, but more complicated mechanisms are possible (see > >> Appendix E for details). > >>" > >> > >>Appendix e, however, does not help since it talks only about > >>a very special case, namely fast handoff. > >> > >>We discussed this issue in one of the eap keying design team > >>phone conferences but it got lost somehow. > >> > >>It would be more helpful to provide a proposal for AAA-Key to > >>MSK/EMSK key derivation. > >> > >>[Joe Salowey] > >> > >>I agree the definition of the AAA-key seems incomplete, I > >>think the definition is any key that is used by the > >>authenticator and supplicant to derive keys for data traffic > >>protection (I don't think AAA-key is the best name since it > >>doesn't have to involve a AAA in the basic case). In the case > >>of standard 802.11 this AAA-Key the same as the MSK. In the > >>fast handoff example I believe additional AAA-keys are pushed > >>to neighboring access points. In order to provide > >>computational independence from the MSK they should be > >>derived from the EMSK. > >> > >>I have submitted an issue in email > >>http://mail.frascone.com/pipermail/eap/2004-January/002143.htm > > > > l (which has not yet been assigned a number) which describes how to > > derive keys > > from the EMSK for specific purposes. I think appendix e > needs to be > > updated as discussed in Issue 214 > > http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%20214. I > > haven't had time to take a detailed look at Jari's > proposal. I'm not > > sure why the A-AAA-Key is needed in this derivation but it is > > equivalent to the MSK. > > > > Could you provide some more context from your discussion? What > > exactly are you deriving keys to do? In my opinion it is > best to use > > the MSK as in the case of 802.11 (single authenticator to > supplicant). > > If keys are going to be used for other purposes, between > other parties > > or in other ways they should be derived from the EMSK. > > > > _______________________________________________ > > 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 SPLCPC@dywidag.de Fri Mar 5 01:55:13 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09502 for ; Fri, 5 Mar 2004 01:55:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az9Em-0004AJ-00 for eap-archive@ietf.org; Fri, 05 Mar 2004 01:55:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az9Do-00040q-00 for eap-archive@ietf.org; Fri, 05 Mar 2004 01:54:12 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Az9DT-0003rc-00 for eap-archive@ietf.org; Fri, 05 Mar 2004 01:53:51 -0500 Received: from [211.154.185.167] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1Az9DV-00016T-ID for eap-archive@ietf.org; Fri, 05 Mar 2004 01:53:54 -0500 Message-ID: From: "Saundra Reilly" To: eap-archive@ietf.org Subject: get the better job * buy a university degree today Date: Fri, 05 Mar 2004 10:49:18 +0400 X-Mailer: celanese custodial almanac-bottom: congresswoman choppy bullish MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--74198534628250152" X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=9.3 required=5.0 tests=FORGED_RCVD_NET_HELO, HTML_60_70,HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY,LINES_OF_YELLING,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,OBFUSCATING_COMMENT,RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.1 HTML_60_70 BODY: Message is 60% to 70% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.1 HTML_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 3.0 FORGED_RCVD_NET_HELO Host HELO'd using the wrong IP network * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 4.3 OBFUSCATING_COMMENT HTML comments which obfuscate text ----74198534628250152 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable GET
mcknight anita constrict ecole mathewson= winslow breakdown canon gaffe allan=20 ----74198534628250152-- From eap-admin@frascone.com Fri Mar 5 12:32:26 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19029 for ; Fri, 5 Mar 2004 12:32:25 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1AAA5203EC; Fri, 5 Mar 2004 12:20:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9C3BD20421; Fri, 5 Mar 2004 12:20:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EDB7C20420 for ; Fri, 5 Mar 2004 12:19:02 -0500 (EST) Received: from infres.enst.fr (infres.enst.fr [137.194.192.1]) by mail.frascone.com (Postfix) with ESMTP id 687C0203EC for ; Fri, 5 Mar 2004 12:19:01 -0500 (EST) Received: from alceste.enst.fr (alceste.enst.fr [137.194.162.37]) by infres.enst.fr (Postfix) with ESMTP id 692163130 for ; Fri, 5 Mar 2004 18:31:05 +0100 (MET) Received: from enst.fr ([127.0.0.1]) by alceste.enst.fr with Microsoft SMTPSVC(6.0.2600.1106); Fri, 5 Mar 2004 18:31:05 +0100 Message-ID: <4048B959.5080104@enst.fr> From: Artur Hecker Organization: ENST Paris User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) 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: 05 Mar 2004 17:31:05.0620 (UTC) FILETIME=[A36BED40:01C402D7] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Null character in EAP Identity Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-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, 05 Mar 2004 18:31:05 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit hello i'm not sure this issue has already been resolved and it is perhaps just my own misunderstanding. however, your kind clarification on this matter would be greatly appreciated. in the latest draft version (draft-ietf-eap-rfc2284bis-09.txt) in "Appendix A. Changes from RFC 2284" section it is explicitly stated that: o The null character is forbidden in the Type-Data field of an Identity Response message, as it is in RFC 2284. <...> Now, reading the original RFC2284 in section 3.1 Identity/Type-Data it merely states that: <...> The field MUST NOT be null terminated. The length of this field is derived from the Length field of the Request/Response packet and hence a null is not required. So, I understand it as following: if a typical NAS implementation follows this section of the original RFC2284, it should be capable of dealing with arbitrary Identity payloads i.e. also with ones consisting of several Null bytes, since it would be blindly copying the whole characters. The Identity string just MUST NOT be null _terminated_. I don't see where the original RFC generally prohibits the Null byte in the Identity payload, e.g. in the middle of it. Actually for me the explicit obligation to use the Length field means that Identity can carry arbitrary characters. Would you kindly provide clarification on this matter? Regards, artur _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat Mar 6 14:08:56 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00607 for ; Sat, 6 Mar 2004 14:08:56 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2D4EC203F9; Sat, 6 Mar 2004 13:56:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 208B020321; Sat, 6 Mar 2004 13:56:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F105520321 for ; Sat, 6 Mar 2004 13:55:20 -0500 (EST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id A4AB11FC6C for ; Sat, 6 Mar 2004 13:55:18 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i26JHTF02007 for ; Sat, 6 Mar 2004 11:17:29 -0800 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] Re: NULL character in EAP Identity Request/Response Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-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, 6 Mar 2004 11:17:28 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Here's what RFC 2284 says in Section 3.1: This field MAY contain a displayable message in the Request. The Response uses this field to return the Identity. If the Identity is unknown, this field should be zero bytes in length. The field MUST NOT be null terminated. The length of this field is derived from the Length field of the Request/Response packet and hence a null is not required. Here's what RFC 2284bis-09 says in Section 5.1: This field MAY contain a displayable message in the Request, containing UTF-8 encoded ISO 10646 characters [RFC2279]. Where the Request contains a null, only the portion of the field prior to the null is displayed. If the Identity is unknown, the Identity Response field should be zero bytes in length. The Identity Response field MUST NOT be null terminated. In all cases, the length of the Type-Data field is derived from the Length field of the Request/Response packet. The difference is that the MUST NOT be null terminated directive applies only to the Response, not to the Request. I believe you are correct in that a NULL can be present in the EAP Response. The Appendix appears incorrect on this issue. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Mar 8 09:37:31 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03169 for ; Mon, 8 Mar 2004 09:37:31 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2010120266; Mon, 8 Mar 2004 09:25:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 166E020385; Mon, 8 Mar 2004 09:25:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 01F8020266 for ; Mon, 8 Mar 2004 09:24:26 -0500 (EST) Received: from infres.enst.fr (infres.enst.fr [137.194.192.1]) by mail.frascone.com (Postfix) with ESMTP id 678C220385 for ; Mon, 8 Mar 2004 09:24:24 -0500 (EST) Received: from alceste.enst.fr (alceste.enst.fr [137.194.162.37]) by infres.enst.fr (Postfix) with ESMTP id B2F963029 for ; Mon, 8 Mar 2004 15:36:32 +0100 (MET) Received: from enst.fr ([127.0.0.1]) by alceste.enst.fr with Microsoft SMTPSVC(6.0.2600.1106); Mon, 8 Mar 2004 15:36:32 +0100 Message-ID: <404C84F0.8040602@enst.fr> From: Artur Hecker Organization: ENST Paris User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: eap@frascone.com Subject: Re: [eap] Re: NULL character in EAP Identity Request/Response References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Mar 2004 14:36:32.0282 (UTC) FILETIME=[C0109FA0:01C4051A] 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, 08 Mar 2004 15:36:32 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit hello Bernard Aboba wrote: > The difference is that the MUST NOT be null terminated directive applies > only to the Response, not to the Request. I believe you are correct in > that a NULL can be present in the EAP Response. The Appendix appears > incorrect on this issue. thank you very much for the confirmation. since i am not familiar with WG procedures, is there anything i should/could do to correct the appendix (if it is possible at this stage anyway)? thank you artur hecker ps note to the list admin: i already replied to this message during the weekend, but unfortunately from my private address. since my mail is still held for approval, i prefered to re-send my post from this address. sorry for the inconvenience, the queued message can be deleted. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Mar 8 12:25:31 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14932 for ; Mon, 8 Mar 2004 12:25:31 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3307920392; Mon, 8 Mar 2004 12:13:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 48FCC20386; Mon, 8 Mar 2004 12:13:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DFA8C20386 for ; Mon, 8 Mar 2004 12:12:07 -0500 (EST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id E66A52027F for ; Mon, 8 Mar 2004 12:12:05 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i28HYBp09412 for ; Mon, 8 Mar 2004 09:34:11 -0800 From: Bernard Aboba To: eap@frascone.com In-Reply-To: <20040308170002.5873.57261.Mailman@xavier> Message-ID: References: <20040308170002.5873.57261.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: NULL character in EAP Identity Request/Response Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-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, 8 Mar 2004 09:34:11 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > Bernard Aboba wrote: > > > The difference is that the MUST NOT be null terminated directive applies > > only to the Response, not to the Request. I believe you are correct in > > that a NULL can be present in the EAP Response. The Appendix appears > > incorrect on this issue. > > thank you very much for the confirmation. since i am not familiar with > WG procedures, is there anything i should/could do to correct the > appendix (if it is possible at this stage anyway)? > > > thank you > artur hecker You might suggest alternate text. We should be able to fix this in Author 48 hours, since it's just an error in the change log (not in the actual text). _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Mar 8 14:04:20 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21088 for ; Mon, 8 Mar 2004 14:04:19 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6F3DC20277; Mon, 8 Mar 2004 13:52:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 11BC420287; Mon, 8 Mar 2004 13:52:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9B6922039C for ; Mon, 8 Mar 2004 13:51:47 -0500 (EST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id B252B20287 for ; Mon, 8 Mar 2004 13:51:45 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i28JDpE15350 for ; Mon, 8 Mar 2004 11:13:51 -0800 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: EAP WG last call on draft-ietf-eap-statemachine-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: Mon, 8 Mar 2004 11:13:51 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Today is the last day of the EAP WG last on the EAP State Machine prior to sending this document to the IESG for publication as an Informational RFC. The document is available here: http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-02.txt http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-02.pdf Send comments to the EAP WG mailing list, filed using the Issue submission format described in the EAP Issues list: http://www.drizzle.com/~aboba/EAP/eapissues.html _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Mar 9 06:29:30 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21392 for ; Tue, 9 Mar 2004 06:29:29 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 361FD203F7; Tue, 9 Mar 2004 06:17:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D9B2F2028C; Tue, 9 Mar 2004 06:17:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AB44B2028C for ; Tue, 9 Mar 2004 06:16:06 -0500 (EST) Received: from postfix4-2.free.fr (postfix4-2.free.fr [213.228.0.176]) by mail.frascone.com (Postfix) with ESMTP id ED1AD1FF69 for ; Tue, 9 Mar 2004 06:16:04 -0500 (EST) Received: from enst.fr (massena-5-82-66-229-84.fbx.proxad.net [82.66.229.84]) by postfix4-2.free.fr (Postfix) with ESMTP id 5846F80793 for ; Tue, 9 Mar 2004 12:28:15 +0100 (CET) Message-ID: <404DAA38.2000801@enst.fr> From: Artur Hecker Organization: ENST Paris User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: eap@frascone.com Subject: Re: [eap] Re: NULL character in EAP Identity Request/Response References: <20040308170002.5873.57261.Mailman@xavier> 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, 09 Mar 2004 12:27:52 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hello Bernard Aboba wrote: > You might suggest alternate text. We should be able to fix this in Author > 48 hours, since it's just an error in the change log (not in the actual > text). ok, thanks. the old text in the current 2284bis is: o The null character is forbidden in the Type-Data field of an Identity Response message, as it is in RFC 2284. However, this rule has been relaxed for Identity Requests, and it is now required in Section 5.1 that if the Type-Data field of an Identity Request contains a null character, only the part before the null is displayed. there is no distinction between Identity Request and Response in RFC2284 (s. RFC2284/Section 3.1). however, 2284bis introduces that distinction in 2285bis/Section 5.1. thus, i suggest to change it to: o It is now required in Section 5.1 that if the Type-Data field of an Identity Request contains a null character, only the part before the null is displayed. RFC 2284 prohibits the Null termination of the Type-Data field of Identity messages. This rule has been relaxed for Identity Request messages and the Identity Request Type-Data field may now be null terminated. That would reflect what is written in the current 2284bis. However, I tend to question this explicit distinction of Requests and Responses. What would speak against an equivalent change for the Identity Response? As we agreed, the Null character could be present in Response/Identity fields. How does a usual NAS displays that today? Would it change anything if we added the equivalent _Recommendation_ to not _display_ the portion of the Response after the (already allowed) Null character without changing anything else? Currently, 2284bis states (page 28, Section 5.1): Type-Data This field MAY contain a displayable message in the Request, containing UTF-8 encoded ISO 10646 characters [RFC2279]. Where the Request contains a null, only the portion of the field prior to the null is displayed. If the Identity is unknown, the Identity Response field should be zero bytes in length. The Identity Response field MUST NOT be null terminated. In all cases, the length of the Type-Data field is derived from the Length field of the Request/Response packet. First, note that the phrasing is quite imprecise: e.g. "where the Request contains a null" is misleading (since it does not mention the field); also, strictly speaking there is no "Identity Response" field - it should be "Type-Data field of the Identity Response message". Sorry if i'm being a nitpicker... Second, because of the possible presence of the Null-character in Responses, I would suggest to change this section to: Type-Data This field MAY contain a displayable message in the Request, containing UTF-8 encoded ISO 10646 characters [RFC2279]. Where this field contains a null, only the portion of the field prior to the null is displayed. If the Identity is unknown, this field should be zero bytes in length. This field MUST NOT be null terminated. In all cases, the length of this field is derived from the Length field of the Request/Response packet. Finally, one last remark: back in "Appendix A. Changes from RFC 2284" the current 2284bis states: o In Section 5, Section 5.1 and Section 5.2, requirements has been added that fields with displayable messages should contain UTF-8 encoded ISO 10646 characters. Looking at the text of Section 5.1, I don't see a SHOULD requirement. It is rather a MAY (s. above). If it was supposed to be a "SHOULD", the first phrase in Section 5.1 should be changed, stressing out the SHOULD notion: This field MAY contain a displayable message in the Request. Such displayable message SHOULD contain UTF-8 encoded ISO 10646 characters [RFC2279]. The same applies to Section 5.2 though it is clearer since there is no explicit MAY notion in 5.2. I'm sorry if my comments are too quibbling and, especially, if they come too late. thank you for your attention artur -- hecker@enst.fr _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Mar 9 08:26:21 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26031 for ; Tue, 9 Mar 2004 08:26:21 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BF8AD1FF72; Tue, 9 Mar 2004 08:14:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4E1D920240; Tue, 9 Mar 2004 08:14:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 584FB20240 for ; Tue, 9 Mar 2004 08:13:09 -0500 (EST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by mail.frascone.com (Postfix) with ESMTP id 5B68A1FF72 for ; Tue, 9 Mar 2004 08:13:07 -0500 (EST) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 9 Mar 2004 14:24:56 +0100 Received: from rd.francetelecom.fr ([10.193.167.66]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Tue, 9 Mar 2004 14:24:55 +0100 Message-ID: <404DC596.2010107@rd.francetelecom.fr> From: Florent Bersani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: eap@frascone.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Mar 2004 13:24:55.0808 (UTC) FILETIME=[E9947800:01C405D9] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Documenting the existing shared key EAP methods... towards a new EAP-MD5? Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-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, 09 Mar 2004 14:24:38 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi all, As a follow-up to the chairs' presentation on EAP methods at IETF 59 (available at http://www.arkko.com/publications/eap/ietf-59/ietf59_eap_methstatus.ppt) and to my own presentation on EAP-PSK, a shared key method designed as the successor of EAP-Archie (available at http://www.arkko.com/publications/eap/ietf-59/ietf59_eap_psk.pdf), I am trying to document the existing related work (in a more thorough way than section 1.6 of EAP-PSK draft). Thus, I have written a documentation template (available at http://eappsk.chez.tiscali.fr/draft-bersani-eap-sharedkeymethods-documentationtemplate-00.txt, before it reaches the archive). *If those of you who have written or are writing/designing a shared key EAP method could take 5 minutes to fill it in and mail it to me*, I would be most grateful. The intention is to compile the available documentation on existing shared key EAP methods, before requesting that a new work item be opened to standardize one at IETF. Indeed, it would be quite nice to have a simple and standard successor for EAP-MD5. As of now, apart the 4 methods mentioned by the chairs (EAP-MD5, EAP-OTP, EAP-GTC and EAP-TLS), there are no other standard EAP methods :-( I will of course try to do my best fill the template for the different shared key EAP methods I am aware of but it would much easier and safer if their designers could give a hand. I also welcome pointers or information on EAP shared key methods (apart from the ones already mentioned on Bernard's page ;-)). I will also obviously share with you the compilation of the documentation I will have gathered on that subject (by 04/02/2004 I expect). Any feedback welcome and many thanks in advance for your cooperation, Cheers, Florent P.S: 1) the revision of EAP-PSK is available at http://eappsk.chez.tiscali.fr/draft-bersani-eap-psk-01.txt before it reaches the archive 2) anyone willing to join in for the design of EAP-PSK is welcome! _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From mbatealann@netscape.net Wed Mar 10 01:09:19 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21244 for ; Wed, 10 Mar 2004 01:09:19 -0500 (EST) From: mbatealann@netscape.net Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0wu5-0005Xw-00 for eap-archive@ietf.org; Wed, 10 Mar 2004 01:09:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0wtB-0005Nh-00 for eap-archive@ietf.org; Wed, 10 Mar 2004 01:08:22 -0500 Received: from [211.35.151.161] (helo=iforest.or.kriforest.or.kr) by ietf-mx with esmtp (Exim 4.12) id 1B0wsD-00054j-00 for eap-archive@ietf.org; Wed, 10 Mar 2004 01:07:21 -0500 Received: from netscape.net (pa-westmifflin1a-253.pit.adelphia.net [24.48.238.253]) by iforest.or.kriforest.or.kr (8.12.3/8.12.3) with SMTP id i2A61uRw025124 for ; Wed, 10 Mar 2004 15:05:56 +0900 (KST) Date: Wed, 10 Mar 2004 15:05:56 +0900 (KST) Message-Id: <200403100605.i2A61uRw025124@iforest.or.kriforest.or.kr> To: eap-archive@ietf.org Subject: REPLY SOON X-Priority: 3 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.2 required=5.0 tests=AWL,DEAR_FRIEND,NO_REAL_NAME, PRIORITY_NO_NAME,SUBJ_ALL_CAPS,US_DOLLARS_3 autolearn=no version=2.60 Dear Friend, As you read this, I don't want you to feel sorry for me, because, I believe everyone will die someday. My name is BATES ALAN a merchant in Dubai, in the U.A.E.I have been diagnosed with Esophageal cancer. It has defiled all forms of medical treatment, and right now I have only about a few months to live, according to medical experts. I have not particularly lived my life so well, as I never really cared for anyone(not even myself)but my business. Though I am very rich, I was never generous, I was always hostile to people and only focused on my business as that was the only thing I cared for. But now I regret all this as I now know that there is more to life than just wanting to have or make all the money in the world. I believe when God gives me a second chance to come to this world I would live my life a different way from how I have lived it. Now that God has called me, I have willed and given most of my property and assets to my immediate and extended family members as well as a few close friends. I want God to be merciful to me and accept my soul so, I have decided to give alms to charity organizations, as I want this to be one of the last good deeds I do on earth. So far, I have distributed money to some charity organizations in the U.A.E, Algeria and Malaysia. Now that my health has deteriorated so badly, I cannot do this myself anymore. I once asked members of my family to close one of my accounts and distribute the money which I have there to charity organization in Bulgaria and Pakistan, they refused and kept the money to themselves. Hence, I do not trust them anymore, as they seem not to be contended with what I have left for them. The last of my money which no one knows of is the huge cash deposit of eighteen million dollars $18,000,000,00 that I have with a finance/Security Company abroad. I will want you to help me collect this deposit and dispatched it to charity organizations. I have set aside 10% for you and for your time. God be with you. BATES ALAN From eap-admin@frascone.com Wed Mar 10 06:04:35 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02468 for ; Wed, 10 Mar 2004 06:04:34 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 38308202FF; Wed, 10 Mar 2004 05:52:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2811B20306; Wed, 10 Mar 2004 05:52:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F179C202FF for ; Wed, 10 Mar 2004 05:51:15 -0500 (EST) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by mail.frascone.com (Postfix) with ESMTP id 5DBF82030E for ; Wed, 10 Mar 2004 05:51:13 -0500 (EST) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id i2AB3OO12926; Wed, 10 Mar 2004 12:03:24 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i2AB3NV03674; Wed, 10 Mar 2004 12:03:24 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Wed, 10 Mar 2004 12:02:42 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685E47@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Bernard Aboba'" , eap@frascone.com Subject: RE: [eap] Pseudo-WG last call on draft-walker-ieee802-req-00.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" 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, 10 Mar 2004 12:03:04 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) hi all, i have a question regarding the following requirement: " [10] End-user identity hiding. This corresponds to the "Confidentiality" security claim defined in [RFC2284bis], Section 7.2.1. " would it be useful to distinguish between active and passive user identity confidentiality for the eap peer? i agree that active user identity confidentiality is a MAY but passive protection should be more desireable and possibly a SHOULD would be appropriate. i am asking this question since the need for user identity confidentiality might be more important due to the ability to distribute location information via the AAA infrastructure. with this extensions the user identity might not only be visible to an adversay at the air interface and to the visited network (hotspots) but also aaa brokers might be able to correlate user identities to their location. ciao hannes > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Tuesday, February 24, 2004 5:05 PM > To: eap@frascone.com > Subject: [eap] Pseudo-WG last call on draft-walker-ieee802-req-00.txt > > > IEEE 802.11 has requested that the IETF publish > draft-walker-ieee802-req-00.txt as an Informational RFC. The draft > is available for inspection here: > > http://www.ietf.org/internet-drafts/draft-walker-ieee802-req-00.txt > > Since this is a work item of IEEE 802.11, the EAP WG does not have > change control and cannot issue a formal EAP WG last call. > > However, in order to solicit comments on the draft and allow for > incorporation of comments during the IEEE 802 March plenary, > we will hold > a "pseudo-WG last call" on this draft. > > The "pseudo-WG last call" will last until March 12, 2004. Please send > comments to the EAP WG mailing list, in the Issue format described at: > > http://www.drizzle.com/~aboba/EAP/eapissues.html > > I will add an entry for the draft on the EAP WG Issues page, and will > collect the Issues for discussion at the IEEE 802 plenary in Orlando. > _______________________________________________ > 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 glppress_release@geocities.com Wed Mar 10 14:29:13 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28084 for ; Wed, 10 Mar 2004 14:29:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B19OD-0000YK-00 for eap-archive@ietf.org; Wed, 10 Mar 2004 14:29:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B19Ms-0000FI-00 for eap-archive@ietf.org; Wed, 10 Mar 2004 14:27:51 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B19Lm-0007fZ-00; Wed, 10 Mar 2004 14:26:42 -0500 Received: from [218.5.5.240] (helo=ietf.org) by mx2.foretec.com with smtp (Exim 4.24) id 1B197l-0008GH-DB; Wed, 10 Mar 2004 14:12:14 -0500 From: "Atualidade Brasileira . ivr" To: dnsext-archive@ietf.org Subject: Ressurgimento da mentalidade estatizante? at.: too User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Wed, 10 Mar 2004 14:12:14 -0500 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=5.3 required=5.0 tests=HTML_40_50,HTML_FONT_BIG, HTML_MESSAGE,MAILTO_SUBJ_REMOVE,MAILTO_TO_REMOVE,MAILTO_TO_SPAM_ADDR, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,REMOVE_REMOVAL_2WORD, SUBJ_HAS_SPACES autolearn=no version=2.60 X-Spam-Report: * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.5 REMOVE_REMOVAL_2WORD BODY: List removal information * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.3 MAILTO_SUBJ_REMOVE BODY: mailto URI includes removal text * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email * 0.0 MAILTO_TO_REMOVE URI: Includes a 'remove' email address

ref.: ref - EnEspañol - InEnglish(LinkToFreeTranslator)

Série Temas Patrulhados (4)

Preocupante ressurgimento da mentalidade estatizante

"A improbidade, o desmazelo administrativo, a esclerose, o nepotismo em empresas públicas são conseqüência da própria essência do estatismo: não são parasitas de uma árvore sadia, eles constituem o cerne de uma árvore doente", afirma Adolpho Lindenberg em recente artigo

** Adolpho Lindenberg é autor do livro "Os católicos e a economia de mercado", em que denuncia uma política com viés esquerdista que censura, marginaliza ou encobre com um manto de silêncio, notícias, opiniões e livros "politicamente incorretos", não afinados com as assim denominadas "causas sociais" inspiradas na teologia da libertação e nos Fóruns Sociais. Assim, os meios de comunicação, e a própria sociedade brasileira, estão sendo "patrulhados".

 ** Em seu recente artigo "Estatização ou Privatização?", da Série Temas Patrulhados, o autor adverte sobre um preocupante ressurgimento da mentalidade socialista, favorável à estatização da economia ou, pelo menos, desejosa de uma presença mais ativa do Estado.

** Fazendo parte dessa corrente encontram-se radicais da esquerda, adeptos da Teologia da Libertação, social-democratas, saudosistas das antigas benesses dos regimes paternalistas e até democratas inconformados com a privatização das estatais, acrescenta o autor, lamentando que não são poucos os católicos que anseiam por uma maior interferência do Estado visando a implantação de políticas mais voltadas para "o social".

** Exemplos típicos dessa mentalidade são a limitação à autonomia da Agência Nacional de Energia Elétrica (Aneel) sugerida pela ministra de Minas e Energia, Dilma Rousseff; e o lamentável desinteresse do Poder Público em reformar nossas rodovias mediante a ampliação da privatização dos serviços de manutenção das estradas. Aqueles que criticam a privatização se esquecem que os recursos necessários para a manutenção das estradas só podem provir de duas fontes: ou dos pedágios ou do erário público. Em outras palavras, ou pagam os usuários do serviço -o que é mais lógico- ou acabam pagando todos os contribuintes!

** Quando se acumulam denúncias de malversação de fundos e de incapacidade administrativa, geradores dos enormes déficits das estatais, predomina na opinião pública a noção que tais mazelas são frutos da improbidade de seus dirigentes e que seria suficiente nomear diretores honestos e capazes para que cessassem todos esses descalabros. Na verdade, os desmandos são conseqüência da própria essência do estatismo. A improbidade, o desmazelo administrativo, a esclerose, o nepotismo, não são parasitas de uma árvore sadia, eles constituem o cerne de uma árvore doente. Para receber gratuitamente, por e-mail, o artigo completo, basta clicar em: Lindenberg:EsteArtigoCompletoGratuitamente(No.4)

** Outros tópicos abordados no artigo:

-- As empresas privadas são recompensadas ou penalizadas por seu desempenho, exceto em situações excepcionais, e os lucros ou os prejuízos são conseqüências forçosas da competência ou incompetência de sua gestão; quando, porém, uma empresa é propriedade do Estado, esta relação de causa e efeito, pura e simplesmente, deixa de existir.

-- Nos casos das empresas controladas pelo Estado, não existe o objetivo de recompensar os executivos na proporção de seu desempenho gerencial.

-- Nas estatais, a fiscalização diária, eficaz e construtiva, imprescindível para garantir que os funcionários realizem um bom trabalho, é praticamente inexistente; o critério das promoções baseia-se mais no tempo de serviço do que no mérito; órgãos de instância superior deveriam fiscalizar as estatais e tomar medidas tão drásticas quanto as que são tomadas pelos fiscais do governo relativamente às empresas privadas.

-- As empresas públicas tornam-se facilmente vítimas do empreguismo.

-- Num mundo dominado pela informática, com as economias sujeitas à globalização, só as empresas competitivas sobreviverão, e para isso devem estar em contínua atualização, acompanhando as variações do mercado, cortando custos e inovando produtos; ora, são precisamente estas as qualidades que faltam às empresas públicas.

** Para receber gratuitamente, por e-mail, o texto completo deste artigo, clique em: Lindenberg:EsteArtigoCompletoGratuitamente(No.4)

Outros links para receber e-Book e artigos gratuitos

Lindenberg:e-BookGratuitoBr (em formato Word, com 11 artigos de Lindenberg)

Lindenberg:IntroduçãoGratuitaDoLivro (em formato Word, Introdução do livro "Os católicos e a economia de mercado")

Lindenberg:ArtigosAnteriores

Lindenberg:ProximosArtigos

Links de opinião

Gostariamos muito de receber seu seu voto eletrônico sobre a temática abordada neste e-mail e, se possível, incluindo sua valiosa opinião:

Lindenberg:Concordo - Lindenberg:Discrepo - Lindenberg:Minha Opinião

Outros links

Lindenberg:DesejoAdquirirLivro (receberá instruções sobre como poder adquirir o livro no Brasil)

Remover (para ser retirado imediatamente de nosso Address Book).

A difusão desta mensagem, com uma finalidade exclusivamente cultural, com o intuito de promover um debate construtivo e respeitoso de idéias, é de exclusiva responsabilidade da ConstruNews.

 

 

From rcllbunaehms@aol.com Thu Mar 11 03:13:22 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18229 for ; Thu, 11 Mar 2004 03:13:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1LJh-0003xB-00 for eap-archive@ietf.org; Thu, 11 Mar 2004 03:13:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1LIm-0003mZ-00 for eap-archive@ietf.org; Thu, 11 Mar 2004 03:12:25 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B1LHr-0003bt-00 for eap-archive@ietf.org; Thu, 11 Mar 2004 03:11:27 -0500 Received: from [220.166.164.27] (helo=TEACHER) by mx2.foretec.com with smtp (Exim 4.24) id 1B1LHr-0007iN-Qz for eap-archive@ietf.org; Thu, 11 Mar 2004 03:11:28 -0500 From: "Aubrey Mcmullen" To: Subject: Re:Good stuff Date: Thu, 11 Mar 2004 06:11:26 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--33564023149770140" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: QUALCOMM Windows Eudora Version 5.1 Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=8.5 required=5.0 tests=BANG_MORE,BIZ_TLD, FORGED_MUA_EUDORA,HTML_40_50,HTML_FONTCOLOR_BLUE, HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE,LOW_PRICE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, MISSING_MIMEOLE,MISSING_OUTLOOK_NAME autolearn=no version=2.60 X-Spam-Report: * 1.2 BANG_MORE BODY: Talks about more with an exclamation! * 0.7 LOW_PRICE BODY: Lowest Price * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.1 HTML_FONTCOLOR_BLUE BODY: HTML font color is blue * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 0.1 MISSING_OUTLOOK_NAME Message looks like Outlook, but isn't * 1.9 FORGED_MUA_EUDORA Forged mail pretending to be from Eudora ----33564023149770140 Content-Type: text/html; Content-Transfer-Encoding: 7Bit

Wholesale Prescription Medications
Our Licensed Doctors Will Write Your Prescription For Free

Weight Loss, Muscle & General Pain Relief, Allergies, Men &
Women's Health, Impotence, Heartburn, Migrainevs & MORE!

All Popular Medications Prescribed & Delivered Overnight!

Lowest Prices - NO Prior Prescription Required

VISIT US HERE

Smarks significant seattle dogberry preventive bulblet exploitation moo ibis carve pinch burton !! Jharm gusty gripe antigen rosenblum upslope offhand quartet switchboard gratis euclid bystander a labour bard terminate taboo canada cinnabar bangkok emblem rain perimeter cocklebur !! Tzone fosterite algorithmic bellicose demolition upshot had bona jerusalem girl sidewinder brunhilde j suffocate impersonate lynch vindictive doolittle deneb councilwoman jubilate offshoot quell airtight townsmen bratwurst memento follow .Kincommutable begun riyadh cheater monoid elmhurst bernstein column infantryman duma herewith chinamen survivor deepen fusty mason pta goshawk curlicue !! Dbasalt grubby tulle auric audible curtain ear ! Yboot toy lad bullish radius fulton dimension rye congestive apotheosis arrogant significant benton transmittance denigrate annale joss erode nyquist acrobat crackle syllable categoric cult perez kulak hemosiderin counterflow freemen brought burdensome explain .

If this notice has reached you in error, please notify us by clicking here ----33564023149770140-- From eap-admin@frascone.com Thu Mar 11 10:34:38 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06715 for ; Thu, 11 Mar 2004 10:34:37 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CBBC320368; Thu, 11 Mar 2004 10:22:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4820F20369; Thu, 11 Mar 2004 10:22:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9A68620369 for ; Thu, 11 Mar 2004 10:22:00 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 940E620368 for ; Thu, 11 Mar 2004 10:21:58 -0500 (EST) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id A832189857 for ; Thu, 11 Mar 2004 17:34:11 +0200 (EET) Message-ID: <4050866D.90900@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.5) Gecko/20031007 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] decisions from ietf-59: network selection Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-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, 11 Mar 2004 17:31:57 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit In Seoul, we had a discussion about network selection. I'd like to confirm the results of that discussion here on the mailing list. We discussed the overall problem definition, what standards bodies are addressing which issues, and whether the IETF needs to do something in this space. In the problem definition draft, we divided the issue in a number of subproblems, only one of which is potentially in EAP WG space, the discovery of roaming intermediaries. A discussion arose on what approach the group would prefer. The following alternatives were given: 1. We could turn this entirely over to future layer 2 mechanisms. 2. We could handle this within EAP, according to Farid's draft or similar, eventually to be published as Informational RFC. (This option would be constrained to only the specific roaming intermediary discovery, and not a mechanism for discovering all kinds of other information.) 3. We could leave this up to individual vendors and proprietary solutions. Some solutions already exist in this space. 4. We could decide to do nothing. (Note that the options are not necessarily mutually exclusive. It is possible that future link layer mechanisms might later complement or even replace some other solution.) Most of the people in Seoul preferred to go forward with option 2. If you weren't in Seoul and have an opinion, let us know what you think. In order to move forward, it would be helpful if you can post your opinion by noon (PST) Tuesday next week. Raw (unedited) minutes from Seoul on this item are included below. Some material also available from http://www.arkko.com/publications/eap/ietf-59 --Jari 6. Network selection, Farid Adrangi, Jari Arkko (25 min) Contents: - Problem definition - 3GPP priorities - IEEE plans - Solutions Drafts: - http://www.ietf.org/internet-drafts/draft-ietf-eap-netsel-problem-00.txt - http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-and-selection-01.txt - http://www.ietf.org/internet-drafts/draft-arkko-roamops-rfc2486bis-00.txt * Problem definition Draft exists, see above. - We need network selection. Well, what is this - Tried to classify this: 1. Acces network discovery 2. Identifier selection - which nai to use on this link 3. Selection of roaming intermediaries 4. Payload Routing - Another way to look at this is = there are 3 activities we have to do: * Discovery - what services were available * Decision - screen with manual net selection, or manual * Indicate choice to network - attach to one access point, or send nai of certain value - Recommendations * All 4 problems are relevant * Potential need for new solutions - These problems are _really_ _really_ hard if * there are a lot of networks * you want to do it securely * there are many different ways to do this - Given that the problem _is_ hard, it may be that we can't solve it all now. * IEEE and 3GPP responses - What do they want to do, what do they 3gpp SA2 wlan group: - problems 1 and 3 are relevant to 3gpp, but not the others. - 3gpp eses existing l2 mechanisms for problem 1 - they expect an IETF solution to problem 3 ieee 802.11 meeting summary - alternatives are relevant for one of their stydy groups - they don't know what kind of solutions they need now - other groups also working on related problems * Solution space - Believe there is interest in problems 1 and 3 - Pretty clear problem 1 belongs to link layer - Problem 3 belongs at least in part in IETF. There may be mechanisms at lower layers that effectively advertise relevant information also for higher levels than L2 - If there's an IETF intermedirary solution, it will probably be relatively short-term - We already today have configured databases on the client, and advertised information; must be able to switch to other source. - in roamops draft Osok: SA2 ready to use EAP based solutions not only for problem 3 but also for problem 1. Agreed that ESSID cannot always be used to select access point. Farid: Problems 1 and 3 may be intertwined, may need to do 1 based on result of 3 Osok: Cannot use ESSID only, also in situations where we don't want David Johnston, chair .21: Ways of doing link-layer discovery, some good ways, and may be better ways upcoming. .21 talks about providing means of link-layer discovery and fast handover. Critical item is you - need to get information, and that information need to map into a wider information model used by 3gpp, IEEE, etc. Glenn: The only reason this needs to be in EAP is that - We're selecting from private networks here - commercial or not - and have to select the path of the aaa packets because providers won't carry other people's aaa packets. Serge Manning: Don't know if EAP solutions are the best, but even if .21 comes up with something, we'll have to be able to work with existing .11 APs Pasi: Why is aaa routing difficult - all AccessAccept packets forwarded indicates willingness to carry the traffic of somebody, and may result in monetary pain if you do it without getting paid Glenn: Forwarding of aaa packet is an implied contract? The routing of aaa packets? How can that be?? That's crazy! Pasi: When you Glenn: Have to pick what network to carry your traffic, that's ok. And you have to have an agreement between providers. But just _forwarding_ the aaa packets, to set up the correct route for traffic should not be a problem. Jari: Two problems, finding an access network and selecting who is to carry the traffic. Glenn: The first part I understand, but not why the rest of the stuff has to be done in EAP. Farid: This is operator requirements, that 1 and 3 are requirements. Farid's presentation: * (See slides - graphics with text) 1. MN finds home service network (HSN) advertised, OK 2. MN finds other operators, which has a relationship with HSN, OK. 3. MN finds no opeartor with known relationship with HSN - need to try each in turn, and discover if somebody has a relationship with a preferred mediating network Alper: Can there be several mediating networks in series between access network and HSN? Farid: In 3gpp we are not considering more than 1 intermediary mediating networks Lauri?: Is there any implicit assumption that client will have to know paths through the net? Farid: No, looks up each intermediary network discovered in an preconfigured database. * Solution proposed: - complies with 2284bis, uses 2486bis bang syntax - may not require any changes to access points - uses EAP Identity Rewquest to deliver identities from the local aaa server Osok: Why "MAY" in point 2? Farid: You can deliver from AAA server, which doesn't require any AP change. But you could also configure APs to assist selection. Jari: * Need to decide how to advertise intermediary networks, could * How should access discovery be performed. David: Don't think that a L2 solution will override an EAP solution, both will be appropriate for a long time. * Need to decide what to do with Farid's draft * Need to decide how to go forward in EAP: 1. We could turn this entirely over to future Layer 2 mechanisms 2. We could handle this within EAP, according to Farid's draft or similar 3. We could leave this up to individual vendors and proprietary solutions 4. We could decide to do nothing. * Pros, Cons - Layer 2 approach is probably most efficient, but may require AP upgrdes, may take longer time to specify and implement - Farid's draft doesn't need AP upgrades , but is not very clean - Could let vendors do each his own thing, which may result in many competing and maybe broken ways Alper: Why.... .. Alper: Could use PANA to do discovery at lower level.. Glenn: Why does it matter if you get many? We're selecting private networs? Jari: France telecom may have their own scheme, but they won't have their own Windows or their own phone. Glenn: Informational is not enough, Standard is going to be required to make vendors pick it up. Jari: There are tradeoffs with the vendor-specific thing Steven Hayes: Timeframes for 3gpp: Need to have a clear indication of direction, as the goal is to finalize specification, stage two on coming meeting and stage 3 within 6 months. Layer 2 hard to swallow, vendor-specific could work but Yoshi Ohba: Don't prefer any particular solution, but needs to consider threats. Farid's proposal has weaknesses. Jari: You have contracts, you don't go outside those preconfigured, so isn't that much of a threat. ?? Cisco: Steve, do you have any preference? Could you clarify In 3gpp2 we have a design strategy to prefer things with zero impact on Wireless Lans Steven: Farid's draft is the preferred way. * Consensus call: - Option 1: ~3 - Option 2: ~11 - Option 3: ~2 - Option 4: ~1 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Mar 11 22:38:43 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14925 for ; Thu, 11 Mar 2004 22:38:43 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4D4B6202B0; Thu, 11 Mar 2004 22:26:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AFA67202B8; Thu, 11 Mar 2004 22:26:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 10FA6202B8 for ; Thu, 11 Mar 2004 22:26:00 -0500 (EST) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id C959D202B0 for ; Thu, 11 Mar 2004 22:25:57 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i2C3ln917579 for ; Thu, 11 Mar 2004 19:47:49 -0800 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] Completion of EAP WG last call on draft-ietf-eap-statemachine-02.txt, pdf Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-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, 11 Mar 2004 19:47:49 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) EAP WG last call has now concluded on the EAP State Machine draft, draft-ietf-eap-statemachine-02.txt and .pdf. Only a single comment was received on the document, which raises the question as to whether the lack of comments was due to very high document quality, or lack of review by WG participants. To disambiguate between these two possibilities, I'd ask WG participants who have reviewed the document and have an opinion as to whether the document is ready for RFC publication to post their opinions to the list by Thursday, March 18, 2004. At that point we'll make a decision as to whether the document is ready to send to the IESG for publication as an Informational RFC. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Mar 11 22:44:25 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15103 for ; Thu, 11 Mar 2004 22:44:24 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B9313202B0; Thu, 11 Mar 2004 22:32:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 508B5202B8; Thu, 11 Mar 2004 22:32:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C20A5202B8 for ; Thu, 11 Mar 2004 22:31:45 -0500 (EST) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id D5CE3202B0 for ; Thu, 11 Mar 2004 22:31:43 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i2C3raU17954 for ; Thu, 11 Mar 2004 19:53:36 -0800 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] Completion of pseudo-WG last call on draft-walker-ieee802-req-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: Thu, 11 Mar 2004 19:53:36 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Pseudo-WG last call has now concluded on draft-walker-ieee802-req-00.txt. 4 comments were received; they are available for inspection here: http://www.drizzle.com/~aboba/EAP/eapissues.html Note that this document has also gone to IETF last call, so that if you have comments on this document, you should send them to the EAP WG mailing list (eap@frascone.com) as well as sending them to the IESG. IETF last call concludes on March 28, 2004. The IETF last call announcement is available here: http://www1.ietf.org/mail-archive/ietf-announce/Current/msg29002.html Note that the IEEE 802 plenary is coming up next week, and presumably some time will be spent on comment resolution and document revision. Therefore if you have comments it probably makes sense to get them in ASAP so that they can be incorporated next week. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Mar 12 01:51:28 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21413 for ; Fri, 12 Mar 2004 01:51:28 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A19EA204BD; Fri, 12 Mar 2004 01:39:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 627E0204BB; Fri, 12 Mar 2004 01:39:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DACA7202BE for ; Fri, 12 Mar 2004 01:38:59 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 545E01FF9B for ; Fri, 12 Mar 2004 01:38:58 -0500 (EST) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id BC6D3898D2 for ; Fri, 12 Mar 2004 08:51:13 +0200 (EET) Message-ID: <40515D5A.4020207@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] (fwd) I-D ACTION:draft-bersani-eap-sharedkeymethods-doctemplate-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: Fri, 12 Mar 2004 08:48:58 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : EAP shared key methods documentation template Author(s) : F. Bersani Filename : draft-bersani-eap-sharedkeymethods-doctemplate-00.txt Pages : 10 Date : 2004-3-11 This document proposes a template for authors of EAP methods that rely on shared keys, to document their work. Since EAP methods have proliferated but only 4 are currently standardized and since no simple shared key EAP method seems to be widely available to replace EAP-MD5 that has been deprecated for security reasons, this template is the first step towards standardizing such an EAP method. This document is indeed intended to help gather information on the existing related work before requesting that a new work item be opened at IETF to standardize a replacement for EAP-MD5. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bersani-eap-sharedkeymethods-doctemplate-00.txt _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Mar 12 03:17:25 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07692 for ; Fri, 12 Mar 2004 03:17:25 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AFFE0202B6; Fri, 12 Mar 2004 03:05:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 90C5B201F6; Fri, 12 Mar 2004 03:05:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F344C201F6 for ; Fri, 12 Mar 2004 03:04:07 -0500 (EST) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by mail.frascone.com (Postfix) with ESMTP id E63501FF9A for ; Fri, 12 Mar 2004 03:04:05 -0500 (EST) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i2C8GKE06279 for ; Fri, 12 Mar 2004 09:16:21 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i2C8GKV10170 for ; Fri, 12 Mar 2004 09:16:20 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Fri, 12 Mar 2004 09:15:38 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685E5F@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: eap@frascone.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Pseudo-WG last call on draft-walker-ieee802-req-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: Fri, 12 Mar 2004 09:15:58 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Issue TBD: User identity confidentiality Submitter name: Hannes Tschofenig Submitter email address: Hannes.Tschofenig@siemens.com Date first submitted: 10/3/2004 Reference: http://mail.frascone.com/pipermail/public/eap/2004-March/002361.html Document: draft-walker-ieee802-req-00 Comment type: 'T' Priority: '1' Should fix Section: 2.3 and 2.4 Rationale/Explanation of issue: Section 2.4 lists the requirement for user identity confidentiality as a MAY requirement: " [10] End-user identity hiding. This corresponds to the "Confidentiality" security claim defined in [RFC2284bis], Section 7.2.1. " User identity confidentiality gains more importance in the presence of wlan hotspots and also due to transmission of location information. Additionally, the requirement does not differentiate between active and passive user identity confidentiality. Solid active user identity confidentiality requires public based mechanism and cannot be a MUST or SHOULD requirement. Passive user identity confidentiality can, however, be accomplished with authentication and key exchange protocols based symmetric keys. For the wireless environment passive user identity confidentiality should be of higher priority. Requested change: Add a requirement to section 2.3 (SHOULD requirement section): Passive user identity confidentiality for the EAP peer: This corresponds to the "Confidentiality" security claim defined in [RFC2284bis], Section 7.2.1. Passive user identity confidentiality provides protection against an eavesdropper at the wireless link or in the AAA infrastructure. It does not protect against an active adversary. " Modify existing requirement in section 2.4 (MAY requirement section): Active user identity confidentiality for the EAP peer: This corresponds to the "Confidentiality" security claim defined in [RFC2284bis], Section 7.2.1. Active user identity confidentiality prevents disclosure of the identity of the EAP peer even against an active adversary. " _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From idzkzpacrj@superior.net Fri Mar 12 12:51:41 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07213 for ; Fri, 12 Mar 2004 12:51:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1qox-0002ka-00 for eap-archive@ietf.org; Fri, 12 Mar 2004 12:51:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1qo6-0002dE-00 for eap-archive@ietf.org; Fri, 12 Mar 2004 12:50:51 -0500 Received: from dsl-200-95-54-170.prod-infinitum.com.mx ([200.95.54.170]) by ietf-mx with smtp (Exim 4.12) id 1B1qnh-0002VV-00; Fri, 12 Mar 2004 12:50:26 -0500 Received: from 247.244.220.160 by web129.mail.yahoo.com; Fri, 12 Mar 2004 16:43:14 -0100 Message-ID: From: "Alexandria Good" To: eap-archive@ietf.org Subject: Try Our Diet Fitness Program Date: Fri, 12 Mar 2004 21:43:14 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--4107041044556460" X-CS-IP: 206.218.22.78 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.3 required=5.0 tests=BIZ_TLD,HTML_40_50, HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----4107041044556460 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

Save 40%-70% on Hundreds of Prescription Drugs

Our Online Drugstore is your single source of online drugs and medication that you can order= from the comfort of your home. We are your private source for FDA Approv= ed prescription medications= Once orders are received, one of our 24x7 onboard US Physicians will approve of = your order (99.99% orders approved).

=

Orders approved by 2 pm EST will receive their medic= ation next business day via FedEX! (where available)

Start S= aving. Order your Medications Here

Yfootwork geocentri= c nab dichloride instrument radiotherapy advent bitwise brillouin quarterm= aster breakoff monad bivalve=20 !!! Tgraduate daylight adverse grandniece = oklahoma contrition ross paranoia eater aisle pfennig women internescine q= uest consign prostitute larsen drummond expel basin=20! Fbecket botanic dr= ought creak enunciate scenery emeritus dysentery=20.Zcrescendo regiment in= troduction desire wrack hiroshi compact merritt northampton bashful sherwo= od=20. Pincontrollable cochrane eighty galactose breed burg credulous ymca= cranberry cain draco maidservant advertise chaos aquila tavern money conc= eive=20! Xcombustible gonzalez maureen clang bridgeport requited ulster he= artfelt groom springy applause dudley germ inlet cursory current bedpost d= arwin monongahela trustee algol=20=20

If this notice has reached you in error, please notify us by cl= icking here ----4107041044556460-- From wpyulaakrk@lcc.net Fri Mar 12 21:20:57 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07118 for ; Fri, 12 Mar 2004 21:20:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1yll-0003Sq-00 for eap-archive@ietf.org; Fri, 12 Mar 2004 21:20:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1ykp-0003Jb-00 for eap-archive@ietf.org; Fri, 12 Mar 2004 21:19:59 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B1yjn-0003Gd-00; Fri, 12 Mar 2004 21:18:55 -0500 Received: from cs78241071.pp.htv.fi ([62.78.241.71]) by mx2.foretec.com with smtp (Exim 4.24) id 1B1ybA-0000F0-MN; Fri, 12 Mar 2004 21:10:01 -0500 Received: from 32.136.156.84 by 65.246.255.50; Fri, 12 Mar 2004 21:03:59 -0500 Message-ID: From: "Dionne Raines" Reply-To: "Dionne Raines" To: eap-archive@ietf.org Subject: Re:Best deal of the month Date: Fri, 12 Mar 2004 22:09:59 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--0192696543782370448" X-Priority: 3 X-CS-IP: 72.90.35.136 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.1 required=5.0 tests=BIZ_TLD,HTML_40_50, HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,PRIORITY_NO_NAME autolearn=no version=2.60 ----0192696543782370448 Content-Type: text/html; Content-Transfer-Encoding: 7Bit

Almost 75% OFF ON HUNDREDS OF MEDICATIONS
Absolutely No Doctor Appointment Needed!

Order prescription medication including weight loss, diet pill, skin care, birth control, muscle relaxants, high level pain relief, anxiety, prescription sleeping aids, anti-depressant medications and more.

The product will be filled and shipped by a US licensed pharmacist overnight to your door, immediately and discreetly.

We make it easier and faster than ever to get the medications you need!

Order by 2 pm EST and you get your meds tomorrow.

Get Your Meds Here and Save!

Ycoolidge coercion dixon q greg mandrill architectonic gentleman grope congest knee bestseller constrict backpack bluish duty syringe woolworth crowberry waxen ; Rfanfold marianne driven amoebae keller populous dan radial cumbersome wiley mockingbird counterargument disputant glamor algeria protophyta calico discuss torsion attache bien accent gangplank attack downturn albeit prairie celery bellamy . Ifugitive codfish beaux wallet drag hilarious nucleotide gun degeneracy hetman facsimile dunn orthonormal filet grapevine preeminent procedure binge degeneracy fluoride olden opec hydrodynamic shortage annoy goniometer headlight survive thai cit skullduggery bleat anticipatory lacy brandenburg comrade skiff rodent axis evelyn component michelin windbreak awry est duckling stadia imperfect digestible prepare solon cautious catastrophic belgian fisk immemorial adsorptive alps certify toxic .

If this notice has reached you in error, please notify us by clicking here ----0192696543782370448-- From eap-admin@frascone.com Fri Mar 12 21:42:41 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07860 for ; Fri, 12 Mar 2004 21:42:39 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 665742024F; Fri, 12 Mar 2004 21:30:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 468C1204C2; Fri, 12 Mar 2004 21:30:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 72BDA204C2 for ; Fri, 12 Mar 2004 21:29:53 -0500 (EST) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by mail.frascone.com (Postfix) with ESMTP id 3B9942024F for ; Fri, 12 Mar 2004 21:29:51 -0500 (EST) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HUH00K04U65UL@mailout2.samsung.com> for eap@frascone.com; Sat, 13 Mar 2004 11:42:05 +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 <0HUH000QVU65VP@mailout2.samsung.com> for eap@frascone.com; Sat, 13 Mar 2004 11:42:05 +0900 (KST) Received: from Alperyegin ([75.2.47.232]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HUH009J3U6434@mmp2.samsung.com> for eap@frascone.com; Sat, 13 Mar 2004 11:42:05 +0900 (KST) From: Alper Yegin Subject: RE: [eap] decisions from ietf-59: network selection In-reply-to: <4050866D.90900@piuha.net> To: jari.arkko@piuha.net, eap@frascone.com Message-id: <002f01c408a4$c6e7df40$e82f024b@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 12 Mar 2004 18:42:07 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7BIT Given the current constraints: - 3GPP and IEEE want this be done yesterday - But do not want to modify the IEEE 802.1X at this point - And deal with its deployment on APs I think going forward with #2 is the only choice. Nevertheless, I'd recommend we don't drop the more appropriate solution from the radar, that is handling this issue on the EAP lower layer. We should capture this somewhere (too late for section 3 of rfc2284bis) and provide guidance to new EAP lower layer designers. Alper > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] On Behalf Of > Jari Arkko > Sent: Thursday, March 11, 2004 7:32 AM > To: eap@frascone.com > Subject: [eap] decisions from ietf-59: network selection > > > In Seoul, we had a discussion about network selection. I'd like to > confirm the results of that discussion here on the mailing list. > > We discussed the overall problem definition, what standards bodies are > addressing which issues, and whether the IETF needs to do something in > this space. In the problem definition draft, we divided the issue in a > number of subproblems, only one of which is potentially in EAP WG > space, the discovery of roaming intermediaries. > > A discussion arose on what approach the group would prefer. The > following alternatives were given: > > 1. We could turn this entirely over to future layer 2 mechanisms. > > 2. We could handle this within EAP, according to Farid's draft or > similar, eventually to be published as Informational RFC. (This > option would be constrained to only the specific roaming > intermediary discovery, and not a mechanism for discovering all > kinds of other information.) > > 3. We could leave this up to individual vendors and proprietary > solutions. Some solutions already exist in this space. > > 4. We could decide to do nothing. > > (Note that the options are not necessarily mutually exclusive. It is > possible that future link layer mechanisms might later complement or > even replace some other solution.) > > Most of the people in Seoul preferred to go forward with option 2. If > you weren't in Seoul and have an opinion, let us know what you think. > In order to move forward, it would be helpful if you can post your > opinion by noon (PST) Tuesday next week. > > Raw (unedited) minutes from Seoul on this item are included below. > Some material also available from > http://www.arkko.com/publications/eap/ietf-59 > > --Jari > > 6. Network selection, Farid Adrangi, Jari Arkko (25 min) > > Contents: > - Problem definition > - 3GPP priorities > - IEEE plans > - Solutions > > Drafts: > - http://www.ietf.org/internet-drafts/draft-ietf-eap-netsel- > problem-00.txt > - http://www.ietf.org/internet-drafts/draft-adrangi-eap-network- > discovery-and-selection-01.txt > - http://www.ietf.org/internet-drafts/draft-arkko-roamops- > rfc2486bis-00.txt > > * Problem definition > Draft exists, see above. > - We need network selection. Well, what is this > - Tried to classify this: > > 1. Acces network discovery > 2. Identifier selection - which nai to use on this link > 3. Selection of roaming intermediaries > 4. Payload Routing > > - Another way to look at this is = there are 3 activities we have > to do: > > * Discovery - what services were available > > * Decision - screen with manual net selection, or manual > > * Indicate choice to network - attach to one access point, or > send nai of certain value > > - Recommendations > * All 4 problems are relevant > * Potential need for new solutions > > - These problems are _really_ _really_ hard if > * there are a lot of networks > * you want to do it securely > * there are many different ways to do this > > - Given that the problem _is_ hard, it may be that we can't solve > it all now. > > * IEEE and 3GPP responses > > - What do they want to do, what do they > > 3gpp SA2 wlan group: > - problems 1 and 3 are relevant to 3gpp, but not the others. > - 3gpp eses existing l2 mechanisms for problem 1 > - they expect an IETF solution to problem 3 > > ieee 802.11 meeting summary > - alternatives are relevant for one of their stydy groups > - they don't know what kind of solutions they need now > - other groups also working on related problems > > * Solution space > > - Believe there is interest in problems 1 and 3 > - Pretty clear problem 1 belongs to link layer > - Problem 3 belongs at least in part in IETF. There may be > mechanisms at lower layers that effectively advertise relevant > information also for higher levels than L2 > - If there's an IETF intermedirary solution, it will probably be > relatively short-term > - We already today have configured databases on the client, and > advertised information; must be able to switch to other source. > - in roamops draft > > Osok: SA2 ready to use EAP based solutions not only for > problem 3 but also for problem 1. > Agreed that ESSID cannot always be used to select access > point. > > Farid: Problems 1 and 3 may be intertwined, may need to do 1 > based on result of 3 > > Osok: Cannot use ESSID only, also in situations where we don't > want > > David Johnston, chair .21: > Ways of doing link-layer discovery, some good ways, and > may be better ways upcoming. .21 talks about providing > means of link-layer discovery and fast handover. > Critical item is you - need to get information, and that > information need to map into a wider information model > used by 3gpp, IEEE, etc. > > Glenn: The only reason this needs to be in EAP is that - We're > selecting from private networks here - commercial or > not - and have to select the path of the aaa packets > because providers won't carry other people's aaa packets. > > Serge Manning: Don't know if EAP solutions are the best, but even > if .21 comes up with something, we'll have to be able > to work with existing .11 APs > > Pasi: Why is aaa routing difficult - all AccessAccept packets > forwarded indicates willingness to carry the traffic of > somebody, and may result in monetary pain if you do it > without getting paid > > Glenn: Forwarding of aaa packet is an implied contract? The > routing of aaa packets? How can that be?? That's crazy! > > Pasi: When you > > Glenn: Have to pick what network to carry your traffic, that's > ok. > And you have to have an agreement between providers. > But just _forwarding_ the aaa packets, to set up the > correct route for traffic should not be a problem. > > Jari: Two problems, finding an access network and selecting > who is to carry the traffic. > > Glenn: The first part I understand, but not why the rest of the > stuff has to be done in EAP. > > Farid: This is operator requirements, that 1 and 3 are > requirements. > > Farid's presentation: > * (See slides - graphics with text) > > 1. MN finds home service network (HSN) advertised, OK > 2. MN finds other operators, which has a relationship with HSN, > OK. > 3. MN finds no opeartor with known relationship with HSN - need > to try each in turn, and discover if somebody has a > relationship > with a preferred mediating network > > Alper: Can there be several mediating networks in series > between > access network and HSN? > > Farid: In 3gpp we are not considering more than 1 intermediary > mediating networks > > Lauri?: Is there any implicit assumption that client will > have to know paths through the net? > > Farid: No, looks up each intermediary network discovered in an > preconfigured database. > > * Solution proposed: > > - complies with 2284bis, uses 2486bis bang syntax > - may not require any changes to access points > - uses EAP Identity Rewquest to deliver identities from the local > aaa server > > Osok: Why "MAY" in point 2? > > Farid: You can deliver from AAA server, which doesn't require any > AP change. But you could also configure APs to assist selection. > > Jari: > * Need to decide how to advertise intermediary networks, could > * How should access discovery be performed. > > David: Don't think that a L2 solution will override an EAP > solution, both will be appropriate for a long time. > > * Need to decide what to do with Farid's draft > * Need to decide how to go forward in EAP: > > 1. We could turn this entirely over to future Layer 2 mechanisms > 2. We could handle this within EAP, according to Farid's draft or > similar > 3. We could leave this up to individual vendors and proprietary > solutions > 4. We could decide to do nothing. > > * Pros, Cons > > - Layer 2 approach is probably most efficient, but may require AP > upgrdes, may take longer time to specify and implement > - Farid's draft doesn't need AP upgrades , but is not very clean > - Could let vendors do each his own thing, which may result in > many competing and maybe broken ways > > Alper: Why.... > > .. > > Alper: Could use PANA to do discovery at lower level.. > > Glenn: Why does it matter if you get many? We're selecting > private networs? > > Jari: France telecom may have their own scheme, but they won't > have their own Windows or their own phone. > > Glenn: Informational is not enough, Standard is going to be > required to make vendors pick it up. > > Jari: There are tradeoffs with the vendor-specific thing > > Steven Hayes: Timeframes for 3gpp: Need to have a clear > indication of direction, as the goal is to finalize specification, > stage two on coming meeting and stage 3 within 6 months. Layer 2 > hard to swallow, vendor-specific could work but > > Yoshi Ohba: Don't prefer any particular solution, but needs to > consider threats. Farid's proposal has weaknesses. > > Jari: You have contracts, you don't go outside those > preconfigured, so isn't that much of a threat. > > ?? Cisco: Steve, do you have any preference? Could you clarify > In 3gpp2 we have a design strategy to prefer things with zero > impact on Wireless Lans > > Steven: Farid's draft is the preferred way. > > * Consensus call: > > - Option 1: ~3 > - Option 2: ~11 > - Option 3: ~2 > - Option 4: ~1 > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Mar 14 07:04:43 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15554 for ; Sun, 14 Mar 2004 07:04:43 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5C33F202A2; Sun, 14 Mar 2004 06:52:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 314881FF67; Sun, 14 Mar 2004 06:52:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AB8231FF67 for ; Sun, 14 Mar 2004 06:51:57 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id E7F291FF5D for ; Sun, 14 Mar 2004 06:51:55 -0500 (EST) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 47C0C8985B; Sun, 14 Mar 2004 14:04:13 +0200 (EET) Message-ID: <405449B2.8090404@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alper Yegin Cc: eap@frascone.com Subject: Re: [eap] decisions from ietf-59: network selection References: <002f01c408a4$c6e7df40$e82f024b@sisa.samsung.com> In-Reply-To: <002f01c408a4$c6e7df40$e82f024b@sisa.samsung.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: Sun, 14 Mar 2004 14:01:54 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Alper Yegin wrote: > Nevertheless, I'd recommend we don't drop the more appropriate solution > from the radar, that is handling this issue on the EAP lower layer. I agree. I do believe there is actually quite a lot of work in progress in this area, and the matter will not be forgotten. The primary driver appears to be faster movements, which makes it necessary to have better information distribution from the link layer to higher layers. When such mechanisms are available, they can be used for various other purposes as well. Note that much of this work happens outside the IETF (e.g. 802.21) or at least outside the EAP WG. > We should capture this somewhere (too late for section 3 of rfc2284bis) and > provide guidance to new EAP lower layer designers. Well, we do have the problem definition document... it has also been sent as input to the IEEE efforts, for instance. It would probably be useful to think about these issues also in the context of PANA. Or does PANA assume link layer under it provides assistance? But at least some of the limited discovery & selection functions in the current PANA base protocol are on the IP layer, so maybe more extensive mechanisms would go there as well. Has there been any thoughts on where link layer hints fit in the PANA model, for instance? --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From 010uktfg@fapeal.br Mon Mar 15 03:01:35 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13745 for ; Mon, 15 Mar 2004 03:01:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2n2U-0003PU-00 for eap-archive@ietf.org; Mon, 15 Mar 2004 03:01:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2n1V-0003JA-00 for eap-archive@ietf.org; Mon, 15 Mar 2004 03:00:34 -0500 Received: from wbar6.wdc2-4.14.64.234.wdc2.elnk.dsl.genuity.net ([4.14.64.234]) by ietf-mx with smtp (Exim 4.12) id 1B2n0X-000384-00 for eap-archive@ietf.org; Mon, 15 Mar 2004 02:59:34 -0500 Received: from [18.46.69.23] by wbar6.wdc2-4.14.64.234.wdc2.elnk.dsl.genuity.net id <4123782-39047> for ; Mon, 15 Mar 2004 13:51:24 +0600 Message-ID: <4660-3umxg5$5wv$mf--6$$4-h8@da5bl9389m5> From: "Dina Delarosa" <010uktfg@fapeal.br> Reply-To: "Dina Delarosa" <010uktfg@fapeal.br> To: Subject: imagine if you had a diploma Date: Mon, 15 Mar 04 13:51:24 GMT X-Mailer: Microsoft Outlook, Build 10.0.2616 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="C_DDC1CF5.7E10C6_.1" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=16.9 required=5.0 tests=DATE_IN_FUTURE_03_06, DATE_SPAMWARE_Y2K,FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML,HTML_70_80, HTML_FONT_BIG,HTML_MESSAGE,HTML_TAG_EXISTS_TBODY,LINES_OF_YELLING, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE, OBFUSCATING_COMMENT autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 HTML_70_80 BODY: Message is 70% to 80% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 2.8 DATE_IN_FUTURE_03_06 Date: is 3 to 6 hours after Received: date * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * 4.3 OBFUSCATING_COMMENT HTML comments which obfuscate text --C_DDC1CF5.7E10C6_.1 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable GET

GET YOUR UNIVERSITY DIPLOMA

Do yo= u want a prosperou= s future, increased earning power
more money and the respect of all?

Ca<= !b>ll this number: 

1-720-834-2989

(24 hours)

 

  • There are no required tests, classes, books, or= interviews!
     
  • Get a Bachelors, Ma<= !d>sters, MBA, and Doctorate (PhD) diploma!
     
  • Receive the benefits and admiration that comes= with a diploma!
     
  • No one is turned= down!

     

    Call Today

    =

    1-720-834-2989

     (7 days a week)=

    Confidentiality a<= !r>ssured!
     

    W= e are located in USA  international= callers are very welcome

    •
    hxgawq avcpzh hhx wo fwhm --C_DDC1CF5.7E10C6_.1-- From eap-admin@frascone.com Mon Mar 15 05:48:40 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20363 for ; Mon, 15 Mar 2004 05:48:39 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 49A3920438; Mon, 15 Mar 2004 05:36:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E949720432; Mon, 15 Mar 2004 05:36:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CC72620432 for ; Mon, 15 Mar 2004 05:35:46 -0500 (EST) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by mail.frascone.com (Postfix) with ESMTP id 0C5AD2025C for ; Mon, 15 Mar 2004 05:35:45 -0500 (EST) Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HUM00K01603Y7@mailout1.samsung.com> for eap@frascone.com; Mon, 15 Mar 2004 19:48:03 +0900 (KST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUM00CGM602Y5@mailout1.samsung.com> for eap@frascone.com; Mon, 15 Mar 2004 19:48:02 +0900 (KST) Received: from Alperyegin ([75.2.47.237]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HUM005HT602T2@mmp1.samsung.com> for eap@frascone.com; Mon, 15 Mar 2004 19:48:02 +0900 (KST) From: Alper Yegin Subject: RE: [eap] decisions from ietf-59: network selection In-reply-to: <405449B2.8090404@piuha.net> To: jari.arkko@piuha.net Cc: eap@frascone.com Message-id: <004a01c40a7a$ff16d1f0$ed2f024b@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 15 Mar 2004 02:48:05 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7BIT Hi Jari, > > Nevertheless, I'd recommend we don't drop the more appropriate solution > > from the radar, that is handling this issue on the EAP lower layer. > > I agree. I do believe there is actually quite a lot of work in progress > in this area, and the matter will not be forgotten. The primary driver > appears to be faster movements, which makes it necessary to have better > information distribution from the link layer to higher layers. When such > mechanisms are available, they can be used for various other purposes > as well. > > Note that much of this work happens outside the IETF (e.g. 802.21) > or at least outside the EAP WG. There is some relation here, but I cannot really say that 802.21 solution would also handle network (ISP) discovery and selection. This might be a by-product of their solution, but I guess not a targeted deliverable. I really don't know where directly related work is happening in IEEE (.1ae??) > > We should capture this somewhere (too late for section 3 of rfc2284bis) > and > > provide guidance to new EAP lower layer designers. > > Well, we do have the problem definition document... it has also been > sent as input to the IEEE efforts, for instance. This is a good start, but if EAP WG has a recommendation to EAP lower-layer designers, I think this requires another vehicle (unless we expand the scope of the problem definition draft). > It would probably be useful to think about these issues also in the > context of PANA. Or does PANA assume link layer under it provides > assistance? But at least some of the limited discovery & selection > functions in the current PANA base protocol are on the IP layer, so > maybe more extensive mechanisms would go there as well. Has there been > any thoughts on where link layer hints fit in the PANA model, for > instance? In PANA, the ISP discovery and selection is already provided by: - PAA advertising list of ISPs - PaC stating the chosen ISP I'm not sure what else we need in the context of PANA. Actually, this whole selection problem is two fold: a- how to discover and select the network attachment point. b- how to discover and select the ISP. At any given point in time, there may be several distinct attachment points which serve differing sets of ISPs available to my host. A host should perform (a) and (b). (a) and (b) might be integrated in some designs. For example if 802.11 AP could advertise ISPs with the beacons. A STA could select the AP based on its ultimate choice of ISP, and later indicate its ISP choice to the AP in later stages (e.g., during EAP). On the other hand, for example, in DSL networks (a) does not happen dynamically. Network attachment is dictated by the physical connection of your residence. (b) takes place over that pre-configured network attachment. The network discovery and selection facility in PANA enables (b), assuming (a) has already taken place. This is because PANA runs after the link-layer is connected. (a) requires link-layer facilities. Is that what you mean by "link-layer assistance?" Alper > > --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Mar 15 06:49:32 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22053 for ; Mon, 15 Mar 2004 06:49:32 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C8662202D5; Mon, 15 Mar 2004 06:37:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 94F2F20367; Mon, 15 Mar 2004 06:37:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0AFCF202F0 for ; Mon, 15 Mar 2004 06:36:10 -0500 (EST) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by mail.frascone.com (Postfix) with ESMTP id 47149202D5 for ; Mon, 15 Mar 2004 06:36:08 -0500 (EST) 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 i2FBqMDN022977; Mon, 15 Mar 2004 11:52:22 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2FBo0fa032265; Mon, 15 Mar 2004 11:50:24 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031503482419326 ; Mon, 15 Mar 2004 03:48:24 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 15 Mar 2004 03:48:24 -0800 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] decisions from ietf-59: network selection X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <85514027246E4643A1B0780EC0F6F4580427B3@orsmsx410.jf.intel.com> Thread-Topic: [eap] decisions from ietf-59: network selection Thread-Index: AcQKexGy8Ak3Ako6Q36QcU3yl2KKxQAB7Ijw From: "Johnston, Dj" To: "Alper Yegin" , Cc: X-OriginalArrivalTime: 15 Mar 2004 11:48:24.0348 (UTC) FILETIME=[6C144DC0:01C40A83] 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, 15 Mar 2004 03:48:24 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable 802.21 is in a requirements defining phase right now. ISP Discovery and selection, vs. network discovery and selection is something we should probably explore in .21. Whether we support it at all or its a byproduct or its a first class concept in 802.21 is open to debate. DJ -----Original Message----- From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] On Behalf Of Alper Yegin Sent: Monday, March 15, 2004 2:48 AM To: jari.arkko@piuha.net Cc: eap@frascone.com Subject: RE: [eap] decisions from ietf-59: network selection Hi Jari, > > Nevertheless, I'd recommend we don't drop the more appropriate solution > > from the radar, that is handling this issue on the EAP lower layer. >=20 > I agree. I do believe there is actually quite a lot of work in progress > in this area, and the matter will not be forgotten. The primary driver > appears to be faster movements, which makes it necessary to have better > information distribution from the link layer to higher layers. When such > mechanisms are available, they can be used for various other purposes=20 > as well. >=20 > Note that much of this work happens outside the IETF (e.g. 802.21) or=20 > at least outside the EAP WG. There is some relation here, but I cannot really say that 802.21 solution would also handle network (ISP) discovery and selection. This might be a by-product of their solution, but I guess not a targeted deliverable.=20 I really don't know where directly related work is happening in IEEE (.1ae??) > > We should capture this somewhere (too late for section 3 of rfc2284bis) > and > > provide guidance to new EAP lower layer designers. >=20 > Well, we do have the problem definition document... it has also been=20 > sent as input to the IEEE efforts, for instance. This is a good start, but if EAP WG has a recommendation to EAP lower-layer designers, I think this requires another vehicle (unless we expand the scope of the problem definition draft). > It would probably be useful to think about these issues also in the=20 > context of PANA. Or does PANA assume link layer under it provides=20 > assistance? But at least some of the limited discovery & selection=20 > functions in the current PANA base protocol are on the IP layer, so=20 > maybe more extensive mechanisms would go there as well. Has there been > any thoughts on where link layer hints fit in the PANA model, for=20 > instance? In PANA, the ISP discovery and selection is already provided by: - PAA advertising list of ISPs - PaC stating the chosen ISP I'm not sure what else we need in the context of PANA. Actually, this whole selection problem is two fold: a- how to discover and select the network attachment point. b- how to discover and select the ISP. At any given point in time, there may be several distinct attachment points which serve differing sets of ISPs available to my host. A host should perform (a) and (b).=20 (a) and (b) might be integrated in some designs. For example if 802.11 AP could advertise ISPs with the beacons. A STA could select the AP based on its ultimate choice of ISP, and later indicate its ISP choice to the AP in later stages (e.g., during EAP). On the other hand, for example, in DSL networks (a) does not happen dynamically. Network attachment is dictated by the physical connection of your residence. (b) takes place over that pre-configured network attachment. The network discovery and selection facility in PANA enables (b), assuming (a) has already taken place. This is because PANA runs after the link-layer is connected. (a) requires link-layer facilities. Is that what you mean by "link-layer assistance?" Alper >=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 Mon Mar 15 14:08:39 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16709 for ; Mon, 15 Mar 2004 14:08:38 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 99C1C20442; Mon, 15 Mar 2004 13:56:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8D266203D6; Mon, 15 Mar 2004 13:56:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D5C342032E for ; Mon, 15 Mar 2004 13:55:26 -0500 (EST) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id E980F20262 for ; Mon, 15 Mar 2004 13:55:24 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i2FJH2V15566 for ; Mon, 15 Mar 2004 11:17:02 -0800 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] Announcement for 802.1X test event (fwd) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 15 Mar 2004 11:17:02 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) FYI, the file is at: http://www.ieee802.org/1/files/public/docs2004/interop-test-event-information-sheet-v2.doc Date: Mon, 15 Mar 2004 11:03:54 -0500 From: "Karen O'Donoghue" To: Tony Jeffree Subject: announcement for 802.1X test event Tony, Attached is the announcement for the upcoming 802.1X interoperability test. If you could post this for the IEEE 802.1 archive, I would appreciate it. Regards, Karen ************************************************************ Karen O'Donoghue Code B35, NSWCDD, 17320 Dahlgren Rd., Dahlgren, VA 22448 +1-540-653-1567 (voice) +1-540-653-8673 (fax) +1-540-809-2905 (cell) *** NEW NUMBER *** EMail: odonoghuekf@nswc.navy.mil _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Mar 16 12:15:49 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11701 for ; Tue, 16 Mar 2004 12:15:48 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BE2FB2036C; Tue, 16 Mar 2004 12:03:05 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 586BB203C5; Tue, 16 Mar 2004 12:03:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5233B203C5 for ; Tue, 16 Mar 2004 12:02:54 -0500 (EST) Received: from fw1.gdm.de (fw1.gdm.de [193.108.184.254]) by mail.frascone.com (Postfix) with ESMTP id 8D19020375 for ; Tue, 16 Mar 2004 12:02:51 -0500 (EST) Received: by fw1.gdm.de (8.11.6p2G/8.11.6) id i2GHFBZ09977 for eap@frascone.com; Tue, 16 Mar 2004 18:15:11 +0100 (CET) Received: (from localhost) by fw1.gdm.de (MSCAN) id 2/fw1.gdm.de/smtp-gw/mscan; Tue Mar 16 18:15:10 2004 From: Hubert.Ertl@de.gi-de.com To: eap@frascone.com Message-ID: X-MIMETrack: Serialize by Router on NOTESSMTP1/SRV/GuD(Release 6.0.2CF2HF242 | February 25, 2004) at 16.03.2004 18:00:17 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Hubert Ertl/GDM/GuD is out of the office. Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-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, 16 Mar 2004 18:14:54 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Ich werde ab 16.03.2004 nicht im B=FCro sein. Ich kehre zur=FCck am 29.03.2004. I'll be back in office by March 29. Your email will be read with delay.= You can reach me on my mobile: +49 172 869 1159 or at CeBIT Hannover hall 1= 7.= _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Mar 17 01:34:44 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23198 for ; Wed, 17 Mar 2004 01:34:43 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2F93C20410; Wed, 17 Mar 2004 01:22:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DE5E420404; Wed, 17 Mar 2004 01:22:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D06A42040B for ; Wed, 17 Mar 2004 01:21:17 -0500 (EST) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id 3D480202F2 for ; Wed, 17 Mar 2004 01:21:16 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id i2H6XbJV004290 for ; Wed, 17 Mar 2004 01:33:37 -0500 (EST) From: Nick Petroni To: Subject: RE: [eap] Relationship between AAA-Key and MSK/EMSK In-Reply-To: <00c401c3ecd5$3790ede0$0200000a@amer.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 17 Mar 2004 01:33:36 -0500 (EST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On the topic of the distinction between AAA and MSK keys, it seems Figure 4 in the keying document adds to the confusion (at least for me). The figure shows the peer, authenticator, and backend all having access to the MSK. As previously noted in this thread, sometimes AAA == MSK, but potentially not. If I understand this correctly, I would say the middle box, which depicts the authenticator, should have "AAA" instead of "MSK". Perhaps AAA should also be indicated on the peer and backend, probably in addition to MSK and EMSK. Any other thoughts on this? thanks, nick On Fri, 6 Feb 2004, Joseph Salowey wrote: > Hi Hannes, > > I agree the definition of the AAA-key seems incomplete, I think the > definition is any key that is used by the authenticator and supplicant > to derive keys for data traffic protection (I don't think AAA-key is the > best name since it doesn't have to involve a AAA in the basic case). > In the case of standard 802.11 this AAA-Key the same as the MSK. In the > fast handoff example I believe additional AAA-keys are pushed to > neighboring access points. In order to provide computational > independence from the MSK they should be derived from the EMSK. > > I have submitted an issue in email > http://mail.frascone.com/pipermail/eap/2004-January/002143.html (which > has not yet been assigned a number) which describes how to derive keys > from the EMSK for specific purposes. I think appendix e needs to be > updated as discussed in Issue 214 > http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%20214. I haven't > had time to take a detailed look at Jari's proposal. I'm not sure why > the A-AAA-Key is needed in this derivation but it is equivalent to the > MSK. > > Could you provide some more context from your discussion? What exactly > are you deriving keys to do? In my opinion it is best to use the MSK as > in the case of 802.11 (single authenticator to supplicant). If keys are > going to be used for other purposes, between other parties or in other > ways they should be derived from the EMSK. > > Thanks, > > Joe > > > eap-admin@frascone.com wrote: > > hi all, > > > > this issue come up when we discussed (Yoshi, Alper, Jari) the > > relationship between the AAA-key and the MSK/EMSK in PANA . > > > > it is said that the AAA-Key is derived from the MSK and EMSK. > > > > the eap-keying document does not specify how this key > > derivation is achieved. > > worse, in Section 4.2.1 the text says: > > > > " The AAA-Key is derived from the keying material exported by the EAP > > method (MSK and EMSK). This derivation occurs on the AAA > > server. In > > many existing protocols that use EAP, the AAA-Key and MSK are > > equivalent, but more complicated mechanisms are possible (see > > Appendix E for details). " > > > > appendix e, however, does not help since it talks only about > > a very special case, namely fast handoff. > > > > we dicussed this issue in one of the eap keying design team > > phone conferences but it got lost somehow. > > > > it would be more helpful to provide a proposal for AAA-Key to > > MSK/EMSK key derivation. > > > > ciao > > hannes > > _______________________________________________ > > 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 Mar 17 12:16:43 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22911 for ; Wed, 17 Mar 2004 12:16:43 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5E17E204DD; Wed, 17 Mar 2004 12:04:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 609AC202D3; Wed, 17 Mar 2004 12:04:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3E429202D3 for ; Wed, 17 Mar 2004 12:03:34 -0500 (EST) Received: from fw2.gdm.de (fw2.gdm.de [193.108.184.154]) by mail.frascone.com (Postfix) with ESMTP id 294BE20218 for ; Wed, 17 Mar 2004 12:03:32 -0500 (EST) Received: by fw2.gdm.de (8.11.6p2G/8.11.6) id i2HHFtI08669 for eap@frascone.com; Wed, 17 Mar 2004 18:15:55 +0100 (CET) Received: (from localhost) by fw2.gdm.de (MSCAN) id 2/fw2.gdm.de/smtp-gw/mscan; Wed Mar 17 18:15:55 2004 From: Hubert.Ertl@de.gi-de.com To: eap@frascone.com Message-ID: X-MIMETrack: Serialize by Router on NOTESSMTP1/SRV/GuD(Release 6.0.2CF2HF242 | February 25, 2004) at 17.03.2004 18:00:59 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Hubert Ertl/GDM/GuD is out of the office. Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-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, 17 Mar 2004 18:15:53 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Ich werde ab 16.03.2004 nicht im B=FCro sein. Ich kehre zur=FCck am 29.03.2004. I'll be back in office by March 29. Your email will be read with delay.= You can reach me on my mobile: +49 172 869 1159 or at CeBIT Hannover hall 1= 7.= _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Mar 17 14:42:46 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01990 for ; Wed, 17 Mar 2004 14:42:44 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8995A1FF8B; Wed, 17 Mar 2004 14:30:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 18B012022C; Wed, 17 Mar 2004 14:30:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DDABA2022C for ; Wed, 17 Mar 2004 14:29:09 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 4C3291FF8B for ; Wed, 17 Mar 2004 14:29:08 -0500 (EST) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 5E55089850; Wed, 17 Mar 2004 21:41:29 +0200 (EET) Message-ID: <4058A953.6010301@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nick Petroni Cc: eap@frascone.com Subject: Re: [eap] Relationship between AAA-Key and MSK/EMSK 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, 17 Mar 2004 21:38:59 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Nick Petroni wrote: > On the topic of the distinction between AAA and MSK keys, it seems Figure > 4 in the keying document adds to the confusion (at least for me). The > figure shows the peer, authenticator, and backend all having access to the > MSK. As previously noted in this thread, sometimes AAA == MSK, but > potentially not. If I understand this correctly, I would say the middle > box, which depicts the authenticator, should have "AAA" instead of "MSK". > Perhaps AAA should also be indicated on the peer and backend, probably in > addition to MSK and EMSK. I think that's right. Some of this was already noted in issue #216. But we should also show AAA-Key in the peer and the backend. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Mar 17 15:26:33 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05140 for ; Wed, 17 Mar 2004 15:26:33 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 73E272030F; Wed, 17 Mar 2004 15:14:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 952E1202A8; Wed, 17 Mar 2004 15:14:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 93597202A8 for ; Wed, 17 Mar 2004 15:13:16 -0500 (EST) 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 DF23720239 for ; Wed, 17 Mar 2004 15:13:14 -0500 (EST) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 17 Mar 2004 12:29:23 +0000 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 i2HKPaK2024520; Wed, 17 Mar 2004 12:25:36 -0800 (PST) Received: from jsaloweyw2k01 ([10.82.225.3]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 17 Mar 2004 12:31:58 -0800 From: "Joseph Salowey" To: , "'Nick Petroni'" Cc: Subject: RE: [eap] Relationship between AAA-Key and MSK/EMSK Message-ID: <01f701c40c5e$00e986a0$0200000a@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.4024 In-Reply-To: <4058A953.6010301@piuha.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-OriginalArrivalTime: 17 Mar 2004 20:31:58.0734 (UTC) FILETIME=[E556B2E0:01C40C5E] 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, 17 Mar 2004 12:25:33 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit eap-admin@frascone.com wrote: > Nick Petroni wrote: >> On the topic of the distinction between AAA and MSK keys, it seems >> Figure 4 in the keying document adds to the confusion (at least for >> me). The figure shows the peer, authenticator, and backend all having >> access to the MSK. As previously noted in this thread, sometimes AAA >> == MSK, but potentially not. If I understand this correctly, I would >> say the middle box, which depicts the authenticator, should have >> "AAA" instead of "MSK". Perhaps AAA should also be indicated on the >> peer and backend, probably in addition to MSK and EMSK. > > I think that's right. Some of this was already noted in > issue #216. But we should also show AAA-Key in the peer and the > backend. > [Joe] I still think the quantity AAA-Key is not well defined. I'm not quite sure what AAA-key is supposed to represent. What is it used for? Today it is used for link-layer-encryption and it is the MSK. Using this key for other purposes may lead to loss of computational independence and result in problems. The use of the work AAA-key is misleading in the context it is currently being used. I think it would be better to discuss things in terms of applications specific keys, with one of the applications being link layer encryption. I'll create an issue with some proposed text for discussion. > --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 Mar 17 15:41:48 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06047 for ; Wed, 17 Mar 2004 15:41:47 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9968920239; Wed, 17 Mar 2004 15:29:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 51D3F20301; Wed, 17 Mar 2004 15:29:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 44CFD20301 for ; Wed, 17 Mar 2004 15:28:50 -0500 (EST) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id AB09920239 for ; Wed, 17 Mar 2004 15:28:48 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id i2HKf5JV023098; Wed, 17 Mar 2004 15:41:05 -0500 (EST) From: Nick Petroni To: Joseph Salowey Cc: Subject: RE: [eap] Relationship between AAA-Key and MSK/EMSK In-Reply-To: <01f701c40c5e$00e986a0$0200000a@amer.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 17 Mar 2004 15:41:05 -0500 (EST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > [Joe] I still think the quantity AAA-Key is not well defined. I'm not [np] Joe, I couldn't agree more. I welcome some discussion on the topic. > quite sure what AAA-key is supposed to represent. What is it used for? [np] I think it represents the trust relationship between the AP and the AAA...*something* has to be transferred so that the AP is in the loop. Where this comes from and how it is used should, indeed, be clearly defined. > Today it is used for link-layer-encryption and it is the MSK. Using > this key for other purposes may lead to loss of computational [np] Yes, this is for certain. Is it possible to make the MSK/AAA only for link-layer-encryption and use the EMSK for all other things? I think you suggested something similar to this before, but I'm not sure I understood completely. > independence and result in problems. The use of the work AAA-key is > misleading in the context it is currently being used. I think it would [np] yeah, I think AAA key is the wrong term as well. Regards, nick _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Mar 17 22:29:35 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27745 for ; Wed, 17 Mar 2004 22:29:35 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8851F20244; Wed, 17 Mar 2004 22:17:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4F357202DC; Wed, 17 Mar 2004 22:17:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 27AB3202DC for ; Wed, 17 Mar 2004 22:16:27 -0500 (EST) Received: from seunghee.org (seunghee.etri.re.kr [129.254.242.21]) by mail.frascone.com (Postfix) with SMTP id 0DA2C20244 for ; Wed, 17 Mar 2004 22:16:25 -0500 (EST) To: eap@frascone.com From: aboba@internaut.com Message-ID: MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: Incoming Fax Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-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, 18 Mar 2004 12:28:23 +0900 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Mar 18 02:39:54 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24712 for ; Thu, 18 Mar 2004 02:39:53 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 65F3720340; Thu, 18 Mar 2004 02:27:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0C50E20226; Thu, 18 Mar 2004 02:27:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B22FC20226 for ; Thu, 18 Mar 2004 02:26:43 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 2449820206 for ; Thu, 18 Mar 2004 02:26:42 -0500 (EST) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 0242B89848 for ; Thu, 18 Mar 2004 09:39:07 +0200 (EET) Message-ID: <40595186.9000008@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.5) Gecko/20031007 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] sm-02 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: Thu, 18 Mar 2004 09:36:38 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit - Title should expand "EAP" per RFC editor requirements. - Abstract should expand AAA and replace RADIUS with AAA so that it doesn't have to be expanded also. - Move the second last paragraph after the text that talks about the switch. - Delete last paragraph of the abstract, it is in part duplication and in part contain temporary status information about the document. - Section 2, s/out of scope for/outside the scope of/ I think, English is not my native language... - For some reason, the bottom page heading is right on the next line after text ends. E.g. Section 4.1. I find this a bit confusing, it takes a moment to realize that your eyes have read into the heading and not a continuation of the paragraph. If you can change this easily, please do. If not, don't worry about it... - Inconsistent capitalization of the sentences explaining variables, see e.g. Sections 4.1.1 vs 4.1.2. - s/wasn't/was not/ s/don't/do not/ s/can't/can not/ s/hasn't/has not/ - In Section 5.2, I think it would be useful to add the following just before "m.init": "In the following we will discuss procedure calls that the state machine can make to methods." - As discussed with the RFC editor and in IETF-59, we need a .txt version with the state machine as a table. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Mar 18 08:59:43 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11250 for ; Thu, 18 Mar 2004 08:59:43 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C3E51202D9; Thu, 18 Mar 2004 08:47:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AAB5F2030A; Thu, 18 Mar 2004 08:47:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 997D5202D9 for ; Thu, 18 Mar 2004 08:46:46 -0500 (EST) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id EF0CE1FF8F for ; Thu, 18 Mar 2004 08:46:44 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id i2IDxAJV017946; Thu, 18 Mar 2004 08:59:10 -0500 (EST) From: Nick Petroni To: Jari Arkko Cc: "eap@frascone.com" Subject: Re: [eap] sm-02 nits In-Reply-To: <40595186.9000008@piuha.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 18 Mar 2004 08:59:09 -0500 (EST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Jari, thanks for the comments. I have 2 questions and a couple comments inline... > - Title should expand "EAP" per RFC editor > requirements. ok, fixed. > > - Abstract should expand AAA and replace > RADIUS with AAA so that it doesn't have to be > expanded also. fixed. > > - Move the second last paragraph after the text > that talks about the switch. I don't quite understand this request. Which paragraph moved where? > > - Delete last paragraph of the abstract, > it is in part duplication and in part contain > temporary status information about the document. done. > > - Section 2, s/out of scope for/outside the scope of/ > I think, English is not my native language... agreed. changed. > - For some reason, the bottom page heading is right on > the next line after text ends. E.g. Section 4.1. > I find this a bit confusing, it takes a moment to > realize that your eyes have read into the heading and > not a continuation of the paragraph. If you can change > this easily, please do. If not, don't worry about it... This is a LaTeX-ism, worst case I will fix it by hand. > - Inconsistent capitalization of the sentences explaining > variables, see e.g. Sections 4.1.1 vs 4.1.2. Which do you prefer? start with caps or no? > - s/wasn't/was not/ > s/don't/do not/ > s/can't/can not/ > s/hasn't/has not/ ewww, yeah. done. > - In Section 5.2, I think it would be useful to add > the following just before "m.init": "In the following > we will discuss procedure calls that the state machine > can make to methods." done with slight word smithing. "The following describes the interaction between the state machine and EAP methods." Also made this change in 4.2. Furthermore, I made the order of "IN", "OUT", and "IN/OUT" consistent between these two sections. > - As discussed with the RFC editor and in IETF-59, > we need a .txt version with the state machine > as a table. Working on that now... should have something to show tonight or tomorrow. Thanks! nick _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Mar 18 09:09:34 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11789 for ; Thu, 18 Mar 2004 09:09:34 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E54CD1FF8F; Thu, 18 Mar 2004 08:57:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5E00420363; Thu, 18 Mar 2004 08:57:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D23861FF8F for ; Thu, 18 Mar 2004 08:56:27 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 0148A20363 for ; Thu, 18 Mar 2004 08:56:26 -0500 (EST) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id C66348984E; Thu, 18 Mar 2004 16:08:50 +0200 (EET) Message-ID: <4059ACDE.2040303@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nick Petroni Cc: "eap@frascone.com" Subject: Re: [eap] sm-02 nits 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: Thu, 18 Mar 2004 16:06:22 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Thanks for your quick response Nick. Inline some answers to your questions: >>- Move the second last paragraph after the text >> that talks about the switch. > > I don't quite understand this request. Which paragraph moved where? This document describes a state machine based on an EAP "Switch" model. This model includes events and actions for the interaction between the EAP Switch and EAP methods. The State Machine and associated model are informative only. Implementations may achieve the same results using different methods. A brief description of the EAP "Switch" model is given in the Introduction section. => This document describes a state machine based on an EAP "Switch" model. This model includes events and actions for the interaction between the EAP Switch and EAP methods. A brief description of the EAP "Switch" model is given in the Introduction section. The State Machine and associated model are informative only. Implementations may achieve the same results using different methods. >>- For some reason, the bottom page heading is right on >> the next line after text ends. E.g. Section 4.1. >> I find this a bit confusing, it takes a moment to >> realize that your eyes have read into the heading and >> not a continuation of the paragraph. If you can change >> this easily, please do. If not, don't worry about it... > > This is a LaTeX-ism, worst case I will fix it by hand. Ok. Don't worry about it. >>- Inconsistent capitalization of the sentences explaining >> variables, see e.g. Sections 4.1.1 vs 4.1.2. > > Which do you prefer? start with caps or no? Caps, and I think you have it everywhere else except 4.1.1. >>- In Section 5.2, I think it would be useful to add >> the following just before "m.init": "In the following >> we will discuss procedure calls that the state machine >> can make to methods." > > done with slight word smithing. "The following describes the interaction > between the state machine and EAP methods." > > Also made this change in 4.2. Furthermore, I made the order of "IN", > "OUT", and "IN/OUT" consistent between these two sections. Very good. >>- As discussed with the RFC editor and in IETF-59, >> we need a .txt version with the state machine >> as a table. > > Working on that now... should have something to show tonight or tomorrow. Great, thanks! --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Mar 18 19:39:45 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19646 for ; Thu, 18 Mar 2004 19:39:44 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D714820281; Thu, 18 Mar 2004 19:27:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5F4B520358; Thu, 18 Mar 2004 19:27:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E2A8320281 for ; Thu, 18 Mar 2004 19:26:19 -0500 (EST) 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 D610620358 for ; Thu, 18 Mar 2004 19:26:17 -0500 (EST) 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 i2J0ceK2016337; Thu, 18 Mar 2004 16:38:41 -0800 (PST) Received: from jsaloweyw2k01 ([64.101.36.192]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 18 Mar 2004 16:45:03 -0800 From: "Joseph Salowey" To: "'Florent Bersani'" , , Cc: Subject: RE: [eap] Re: keying issue 221: EMSK usage guidelines Message-ID: <000701c40d4a$860741a0$c0246540@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <405A1E34.4040200@francetelecom.com> Importance: Normal X-OriginalArrivalTime: 19 Mar 2004 00:45:03.0999 (UTC) FILETIME=[6AE000F0:01C40D4B] 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, 18 Mar 2004 16:38:39 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi Florent, Thanks for you comments, responses inline below: Florent Bersani wrote: > Sorry to catch up late on this one :-( and many thanks to Joe > and Pasi > for their very nice draft (draft-salowey-eap-key-deriv-02.txt) >=20 > Indeed, it is a follow-up of a question raised during Pasi's > presentation at IETF 59 in Seoul: should we not mandate the > PRF used to > derive the AMSKs from the EMSK or not? (EAP issue 221 and slides > available at: > http://www.arkko.com/publications/eap/ietf-59/ietf59-eapkeyfra > mework.ppt) =20 >=20 > Though I understand that specifying a KDF from a well-now one > (IKEv2's) makes life a lot easier (just one option generally leads to > interoperability and choosing a good mandatory KDF prevents designers > from choosing a poor one), I feel a little bit concerned, > probably for > two reasons: >=20 > 1) First, EAP cautiously avoided specifying any cryptographic part so > far (I guess to preserve its extensibility since it is a > framework) and > now we are just including such a part >=20 [Joe] EAP generates key material, but leaves it open as to how you use = it. This is good, but it can leave to problems if the usage of keys is not coordinated, the same key can be used for two different purposes which = can lead to problems. A good key derivation framework provides computation independence between the keys to reduce this problem. > 2) Second, as the author of an EAP method that takes great pride in > using a single cryptographic primitive (AES-128), I am little > bit biased > again people mandating that we use something depending on SHA1 ;-) >=20 [Joe] OK I understand this, perhaps there is a way to work around this problem.=20 > So, my first reaction would be: we should leave it up to EAP > methods to > export such a KDF. And modify the text of section "The EAP AMSK Key > Derivation Function" to say something like: >=20 > "EAP methods MAY export a KDF to derive AMSKs from the EMSK. >=20 > In case, an EAP method does not export a KDF to derive MSKs from the > EMSK, the following KDF MUST (or SHOULD?) be used" >=20 > This tends to get me to my second reaction (I am bit slow, I > know ;-)), > which is to try and investigate the benefits of suggesting such a > change, since it obviously complexifies things a little (possible > euphemism here). And a bunch of additional questions arises from this > second reaction:=20 >=20 > 1) What behavior should we specify in case an EAP method does not > export a KDF, i.e. MUST or SHOULD in my proposed text? And if > SHOULD is > the answer, then, what would be the behavior when an AMSK is requested > when there is no KDF? Possibly, an error I assume... TBD? >=20 > 2) What is the interface to the KDF? I guess it would have to > mimic the > K,L,D,O format specified in section "The EAP AMSK Key Derivation > Function". Thus, would it be possible to specify things a little bit > more, namely:=20 >=20 [Joe] If we choose to have a variable KDF I agree that it should have a consistent interface. > 2.1) *On the key to the KDF*: The EMSK neatly fits into > HMAC-SHA1 since > its length is precisely the one of the compression function > of SHA1. In > case, you use a different KDF (e.g. the one specified in > EAP-PSK), you > could have to add an intermediate processing step. So, should we say > that the exported KDF MUST take as input for K exactly 64 > bytes - that > is the whole EMSK (I guess the answer is yes).=20 [Joe] The EMSK seems to be reasonable, but if you are making this = internal to the method, then it doesn't matter as long as both sides agree.=20 > By the way, > wouldn't it > be nice to add a security warning on the AMSK, to say that > although one > may derive say a 128 byte AMSK, one must not forget that it may come > from a 128 bit key (for instance the KDK portion of EAP-PSK's PSK)... > Should we provide a way to track down the "real" strength of > an AMSK? (I > guess the answer to this one is no, because it would be too > complicated)=20 [Joe] This is definitely a security consideration. Yes, deriving the = "real" strength is a bit complicated and probably controversial as well.=20 >=20 > 2.2) *On the key label*: I would recommend specifying the > length of this > item. I understand it may be a variable length non-empty > string of ASCII > printable characters with no upper limit > [Joe] OK, what do you think would be a good upper limit, 50 chars? =20 > 2.3) *On the application data*: I did not find any precision on this > item. Would it be possible to clarify this, by saying something like > "the application data is a variable length possibly empty > sequence of bits"? >=20 [Joe]I think so. Should we limit this length as well? > 2.4) *On the output length*: how is the output length > encoded? does the > two byte output length encode the output length in bytes or > in bits?=20 [Joe] I believe it should be bytes. > (in > bytes I assume). Also, where does the limit of 255 iterations (hence > 5100 bytes of key material) come from (IKEv2 must explain > that somewhere > I think)?=20 [Joe] there is a one byte counter in the KDF that will wrap.=20 > Should this limit be imposed to any other KDF? [Joe] I don't see any reason why not. 5100 bytes is lots of key = material.=20 > Another issue > close to that one: should we limit in any way the number of AMSK > (probably the sum of their length) that are derived from an EMSK (I > guess the answer is no since it would be too complicated but on the > other hand, it would be nice not to be able to burn down an EMSK > although this is highly improbable) >=20 [Joe] In general I think the problem is small, but it has not been quantified. Some discussion of this probably belongs in security considerations along with key strength discussion.=20 > 3) How would a peer and a server use an AMSK? This should > probably not > be specified in any place. So I assume, we could have the following > scenario: a peer and a server derive an AMSK called the "AMSK > transport key" which would be used to transport any subsequent AMSK > to the peer without having the peer to derive them by himself. I just > wanted to make > sure it is possible (I of course know some issued this scenario > obviously raises - the first one being that it makes the AMSK process > somehow useless - the new AMSKs could perfectly be chosen at > random by > the server). I guess I wanted to suggest that we could add a > word to say > that the AMSK derivation may not always involve the peer (To > be honest, > I do not like my proposition very much ;-) - perhaps > reformulate it to > say precisely that the whole point of the AMSKs is to allow > the network > and the peer to derive them without having to have them sent > between them) > =20 [Joe] One could define such an application, but I think the subsequent = AMSKs you derive in a new way fall under some other specification and I would = not classify them as AMSKs (perhaps EAMSKS :-). At one point I had a draft = on using TLVs protected with AMSK to extend the EAP conversation and add features, but it has expired, if you want I can send you a copy.=20 > Bottom line: I am not sure that it would be a good idea to allow EAP > methods to export their KDF but neither am I of the contrary. Anybody > has more inputs to help me make up my mind? >=20 [Joe] I think that it is important to have a coordinated way to derive = keys. To this you need a KDF with a standard interface like the one defined in = the draft. While EAP methods that derive keys have internal KDFs they = typically do not have an interface like the one defined so they would have to be modified in any case. =20 Perhaps a better solution is to take the KDF construction defined in the document and allow for the PRF to be specified independently (IKEv2 does this). This way you can use AES as the PRF instead of HMAC-SHA1.=20 The difficulty is how to decide which PRF to use. Perhaps this should = be attached to the method, AES methods use the AES PRF defined for IKEv2, methods that use SHA1 use HMAC-SHA1 other make a choice. Some methods = in the future may allow you to negotiate this. The rule could be use SHA1 unless a method specification specifies otherwise. =20 The consistency in the construction would allow implementations with EAP frameworks to do the derivation in the framework without having to keep = the method state around and it would allow methods that are trying to = provide compact implementations to reduce the number of cryptographic primitives involved. =20 > Hope my mental torture helped in some way. >=20 [Joe] I think so, but then again I tend to be tortured.=20 > Florent >=20 > Jari Arkko wrote: >=20 >> Joseph Salowey wrote: >>=20 >>> [Joe] I don't think so, I think that the basic requirement is that >>> both parties in the EAP exchange can derive the same key name and >>> that the name is unique. I'm suggesting the methods derive the key >>> name in their own way. This could make use of nonces, it could send >>> the key name as authenticated data in the exchange, and there are >>> probably other >>=20 >>=20 >> This would work for me. Others? >>=20 >>> possibilities as well. It might be OK to derive the key from the >>> EMSK, but a few people I mentioned this to disliked it. In theory I >>> suppose it increases the chance that an attacker can precompute a >>> partial dictionary that will allow them to compromise some sessions >>> on a network (its difficult to attack a particular session, but it >>> may increase the possibility of compromising one arbitrary session >>> out of many). Perhaps it is not a big deal, perhaps it is worse >>> than I think it is.=20 >>=20 >>=20 >> Ok. >>=20 >> --Jari >>=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 Thu Mar 18 20:30:40 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21879 for ; Thu, 18 Mar 2004 20:30:40 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6870E20536; Thu, 18 Mar 2004 20:18:09 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 30EC120538; Thu, 18 Mar 2004 20:18:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9749A2052E for ; Thu, 18 Mar 2004 20:17:16 -0500 (EST) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 250D62037E for ; Thu, 18 Mar 2004 20:17:14 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i2J1ccE14597 for ; Thu, 18 Mar 2004 17:38:38 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Review of RFC 2486bis Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-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, 18 Mar 2004 17:38:37 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Abstract The original RFC 2486 contained the following text: "In order to enhance the interoperability of roaming and tunneling services, it is desirable to have a standardized method for identifying users. This document proposes syntax for the Network Access Identifier (NAI), the userID submitted by the client during PPP authentication. It is expected that this will be of interest for support of roaming as well as tunneling." In RFC 2486bis, this was changed to: "In order to provide roaming services, it is necessary to have a standardized method for identifying users. This document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client during, for instance, PPP and wireless LAN authentication. This paragraph appears to deprecate use of the NAI in tunneling services as well as to generalize the use of the NAI beyond network access. Recommend changing to: "In order to provide roaming services, it is necessary to have a standardized method for identifying users. This document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client during network authentication." Section 1 says: " Considerable interest exists for a set of features that fit within the general category of "roaming capability" for dialup Internet users, wireless LAN authentication, and other applications." Propose changing to: " Considerable interest exists for a set of features that fit within the general category of "roaming capability" for network access, including dialup Internet users, VPN usage, wireless LAN authentication, and other applications." In Section 1.1, change: "The Network Access Identifier (NAI) is the userID submitted by the client during PPP authentication. In roaming, the purpose of the NAI is to identify the user as well as to assist in the routing of the authentication request. Please note that the NAI may not necessarily be the same as the user's e-mail address or the userID submitted in an application layer authentication. Network Access Server The Network Access Server (NAS) is the device that clients dial in order to get access to the network. In PPTP terminology this is referred to as the PPTP Access Concentrator (PAC), and in L2TP terminology, it is referred to as the L2TP Access Concentrator (LAC). " To: "The Network Access Identifier (NAI) is the user identity submitted by the client during network access authentication. In roaming, the purpose of the NAI is to identify the user as well as to assist in the routing of the authentication request. Please note that the NAI may not necessarily be the same as the user's e-mail address or the user identity submitted in an application layer authentication. Network Access Server The Network Access Server (NAS) is the device that clients connect to in order to get access to the network. In PPTP terminology this is referred to as the PPTP Access Concentrator (PAC), and in L2TP terminology, it is referred to as the L2TP Access Concentrator (LAC). In IEEE 802.11, it is referred to as an Access Point." Change "IPSEC tunnel mode" to "IPsec tunnel mode." In Section 1.2, change: " In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [3]." To: " In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [3]." In Section 1.3, change: " As described in [8], there are a number of services implementing dialup roaming, and the number of Internet Service Providers involved in roaming consortia is increasing rapidly." To: "As described in [8], there are a number of providers offering network access services, and the number of Internet Service Providers involved in roaming consortia is increasing rapidly." In Section 2.1, change: " c = < a character as specified in Section 2.4 >" To: " c = < a character as specified in Section 2.4 >" Section 2.2 states: " Devices handling NAIs MUST support an NAI length of at least 253 octets. However, the following interoperability considerations should be noted: o RFC 2486 required the support of NAIs only up to the length of 72 octets. As a result, it can generally not be assumed that all devices can support 253 octets. o NAIs are often transported in the User-Name attribute of RADIUS [10]. Unfortunately, RADIUS requires devices to support content lengths of only 63 octets for this attribute. As a result, it may not be possible to transfer NAIs beyond 63 octets through all devices. In addition, due to its message structure, RADIUS is unable to support content lengths beyond 253 octets" Effectively, this section admits that RFC 2486bis renders existing devices non-compliant; moreover, due to a variety of limitations it is not clear that devices could be compliant even if they wanted to. This seems problematic. It might make more sense to say: " Devices handling NAIs MUST support an NAI length of at least 72 octets. Support for an NAI length of 253 octets is RECOMMENDED. However, the following implementation issues should be considered: o NAIs are often transported in the User-Name attribute of RADIUS [10]. Unfortunately, [RFC2865] Section 5.1 states that "the ability to handle at least 63 octets is recommended." As a result, it may not be possible to transfer NAIs beyond 63 octets through all devices. In addition, since only a single User-Name attribute may be included in a RADIUS message and the maximum attribute length is 253 octets, RADIUS is unable to support NAI lengths beyond 253 octets." Section 2.3 states: " Interpretation of the "username" part of the NAI depends on the realm in question. Therefore, the "username" part SHOULD be treated as opaque data when processed by nodes that are not authoritative (in some sense) for that realm." I am not sure what "authoritative for that realm" means here. This is DNS terminology. Does it imply that the NAS or RADIUS server supports dynamic DNS client udpate or is running a DNS server itself? Section 2.4 says: " Characters of the username portion in a NAI MUST fulfill the requirements specified in [6]." Is SASL-Prep the relevant authority here, or is this IEN? In the same vein: Section 2.5 states: " As proposed in this document, the Network Access Identifier is of the form user@realm. Please note that while the user portion of the NAI is based on the BNF described in [7], it has been extended for internationalization support as well as for purposes of Section 2.7, and is not necessarily compatible with the usernames used in e-mail. Note also that the internationalization requirements for NAIs and e-mail addresses are different, since the former need to be typed in only by the user himself and his own operator, not by others." On the other hand, RFC 2486 states: "Please note that while the user portion of the NAI conforms to the BNF described in [5]" [5] References RFC 822, the SMTP specification. At the same time, Section 4 indicates that there is no requirement that the NAI represent a valid email address. Perhaps we need to get a technical advisor to assist us relating to these internationalization issues? Section 2.8 does not list "eng%nancy@bigu.edu" as a valid NAI, and lists "@howard.edu" as an invalid NAI. I'd restore the former example, and given the privacy issues, the latter looks like it should be valid now. Author's addresses: for this purpose my email should be: bernarda@microsoft.com. Section 4 says: " Note that the use of an FQDN as the realm name does not imply use of the DNS for location of the authentication server or for authentication routing. Since to date roaming has been implemented on a relatively small scale, existing implementations typically handle location of authentication servers within a domain and perform authentication routing based on local knowledge expressed in proxy configuration files. The implementations described in [8] have not found a need for use of DNS for location of the authentication server within a domain, although this can be accomplished via use of the DNS SRV record, described in [2]. Similarly, existing implementations have not found a need for dynamic routing protocols, or propagation of global routing information. Note also that there is no requirement that the NAI represent a valid email address." Note that roaming has been widely implemented at this point. I'd revise this to say: " Note that the use of an FQDN as the realm name does not imply use of the DNS for location of the authentication server or for authentication routing. Existing implementations typically handle location of authentication servers within a domain and perform authentication routing based on local knowledge expressed in proxy configuration files. The implementations described in [8] have not found a need for use of DNS for location of the authentication server within a domain, although this can be accomplished via use of the DNS as described in [13]. Similarly, existing implementations have not found a need for dynamic routing protocols, or propagation of global routing information. Note also that there is no requirement that that the NAI represent a valid email address." Delete reference 2. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Mar 18 20:36:38 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22194 for ; Thu, 18 Mar 2004 20:36:38 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 743AA2053C; Thu, 18 Mar 2004 20:24:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 37B7120536; Thu, 18 Mar 2004 20:24:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DCAEF20536 for ; Thu, 18 Mar 2004 20:23:28 -0500 (EST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by mail.frascone.com (Postfix) with ESMTP id D91912037E for ; Thu, 18 Mar 2004 20:23:26 -0500 (EST) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 19 Mar 2004 02:35:30 +0100 Received: from rd.francetelecom.fr ([10.193.106.10]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Fri, 19 Mar 2004 02:35:29 +0100 Message-ID: <405A4E64.7000606@rd.francetelecom.fr> From: Florent Bersani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: eap@frascone.com Subject: Re: [eap] Re: keying issue 221: EMSK usage guidelines References: <009101c40181$465a0490$0300000a@amer.cisco.com> <40467E8F.6000303@piuha.net> In-Reply-To: <40467E8F.6000303@piuha.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2004 01:35:29.0884 (UTC) FILETIME=[767169C0:01C40D52] 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, 19 Mar 2004 02:35:32 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit [Sending the mail Joe replied to and that did not reach the list] Sorry to catch up late on this one :-( and many thanks to Joe and Pasi for their very nice draft (draft-salowey-eap-key-deriv-02.txt) Indeed, it is a follow-up of a question raised during Pasi's presentation at IETF 59 in Seoul: should we not mandate the PRF used to derive the AMSKs from the EMSK or not? (EAP issue 221 and slides available at: http://www.arkko.com/publications/eap/ietf-59/ietf59-eapkeyframework.ppt) Though I understand that specifying a KDF from a well-now one (IKEv2's) makes life a lot easier (just one option generally leads to interoperability and choosing a good mandatory KDF prevents designers from choosing a poor one), I feel a little bit concerned, probably for two reasons: 1) First, EAP cautiously avoided specifying any cryptographic part so far (I guess to preserve its extensibility since it is a framework) and now we are just including such a part 2) Second, as the author of an EAP method that takes great pride in using a single cryptographic primitive (AES-128), I am little bit biased again people mandating that we use something depending on SHA1 ;-) So, my first reaction would be: we should leave it up to EAP methods to export such a KDF. And modify the text of section "The EAP AMSK Key Derivation Function" to say something like: "EAP methods MAY export a KDF to derive AMSKs from the EMSK. In case, an EAP method does not export a KDF to derive MSKs from the EMSK, the following KDF MUST (or SHOULD?) be used" This tends to get me to my second reaction (I am bit slow, I know ;-)), which is to try and investigate the benefits of suggesting such a change, since it obviously complexifies things a little (possible euphemism here). And a bunch of additional questions arises from this second reaction: 1) What behavior should we specify in case an EAP method does not export a KDF, i.e. MUST or SHOULD in my proposed text? And if SHOULD is the answer, then, what would be the behavior when an AMSK is requested when there is no KDF? Possibly, an error I assume... TBD? 2) What is the interface to the KDF? I guess it would have to mimic the K,L,D,O format specified in section "The EAP AMSK Key Derivation Function". Thus, would it be possible to specify things a little bit more, namely: 2.1) *On the key to the KDF*: The EMSK neatly fits into HMAC-SHA1 since its length is precisely the one of the compression function of SHA1. In case, you use a different KDF (e.g. the one specified in EAP-PSK), you could have to add an intermediate processing step. So, should we say that the exported KDF MUST take as input for K exactly 64 bytes - that is the whole EMSK (I guess the answer is yes). By the way, wouldn't it be nice to add a security warning on the AMSK, to say that although one may derive say a 128 byte AMSK, one must not forget that it may come from a 128 bit key (for instance the KDK portion of EAP-PSK's PSK)... Should we provide a way to track down the "real" strength of an AMSK? (I guess the answer to this one is no, because it would be too complicated) 2.2) *On the key label*: I would recommend specifying the length of this item. I understand it may be a variable length non-empty string of ASCII printable characters with no upper limit 2.3) *On the application data*: I did not find any precision on this item. Would it be possible to clarify this, by saying something like "the application data is a variable length possibly empty sequence of bits"? 2.4) *On the output length*: how is the output length encoded? does the two byte output length encode the output length in bytes or in bits? (in bytes I assume). Also, where does the limit of 255 iterations (hence 5100 bytes of key material) come from (IKEv2 must explain that somewhere I think)? Should this limit be imposed to any other KDF? Another issue close to that one: should we limit in any way the number of AMSK (probably the sum of their length) that are derived from an EMSK (I guess the answer is no since it would be too complicated but on the other hand, it would be nice not to be able to burn down an EMSK although this is highly improbable) 3) How would a peer and a server use an AMSK? This should probably not be specified in any place. So I assume, we could have the following scenario: a peer and a server derive an AMSK called the "AMSK transport key" which would be used to transport any subsequent AMSK to the peer without having the peer to derive them by himself. I just wanted to make sure it is possible (I of course know some issued this scenario obviously raises - the first one being that it makes the AMSK process somehow useless - the new AMSKs could perfectly be chosen at random by the server). I guess I wanted to suggest that we could add a word to say that the AMSK derivation may not always involve the peer (To be honest, I do not like my proposition very much ;-) - perhaps reformulate it to say precisely that the whole point of the AMSKs is to allow the network and the peer to derive them without having to have them sent between them) Bottom line: I am not sure that it would be a good idea to allow EAP methods to export their KDF but neither am I of the contrary. Anybody has more inputs to help me make up my mind? Hope my mental torture helped in some way. Florent Jari Arkko wrote: > Joseph Salowey wrote: > >> [Joe] I don't think so, I think that the basic requirement is that both >> parties in the EAP exchange can derive the same key name and that the >> name is unique. I'm suggesting the methods derive the key name in their >> own way. This could make use of nonces, it could send the key name as >> authenticated data in the exchange, and there are probably other > > > This would work for me. Others? > >> possibilities as well. It might be OK to derive the key from the EMSK, >> but a few people I mentioned this to disliked it. In theory I suppose >> it increases the chance that an attacker can precompute a partial >> dictionary that will allow them to compromise some sessions on a network >> (its difficult to attack a particular session, but it may increase the >> possibility of compromising one arbitrary session out of many). Perhaps >> it is not a big deal, perhaps it is worse than I think it is. > > > Ok. > > --Jari > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Mar 18 20:37:12 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22243 for ; Thu, 18 Mar 2004 20:37:12 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1239B2053F; Thu, 18 Mar 2004 20:24:18 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 04D5F20541; Thu, 18 Mar 2004 20:24:11 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D81AD20539 for ; Thu, 18 Mar 2004 20:23:41 -0500 (EST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by mail.frascone.com (Postfix) with ESMTP id DB20C2037E for ; Thu, 18 Mar 2004 20:23:39 -0500 (EST) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 19 Mar 2004 02:35:51 +0100 Received: from rd.francetelecom.fr ([10.193.106.10]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Fri, 19 Mar 2004 02:35:50 +0100 Message-ID: <405A4E7A.4030205@rd.francetelecom.fr> From: Florent Bersani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2004 01:35:50.0728 (UTC) FILETIME=[82DDF480:01C40D52] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] RFC 3748 nits&minor 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: Fri, 19 Mar 2004 02:35:54 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi all, While rereading (perhaps a bit quickly, apologies in advance) draft-ietf-eap-rfc2284bis-09.txt, I think I have spotted some nits or minor issues: 1) Specification of length fields. I did not find a place where it said the value of this field gave the length in bytes 2) Section 6.2 "Method Types 42-191 may be allocated on the advice of a Designated Expert, with Specification Required" - types 43 and 44 have been allocated (EAP-FAST and Zonelabs EAP), thus change to "Method Types 44-191 may be allocated on the advice of a Designated Expert, with Specification Required" 3) While reading section 7.2, I got the impression that MS-CHAPv2 was more resistant to dictionary attacks than MS-CHAPv1, which is the only to be MS-CHAP to be mentioned. This is of course not true (see for instance http://www.schneier.com/paper-pptpv2.pdf and http://mopo.informatik.uni-freiburg.de/pptp_mschapv2/pptp_mschapv2.html). Perhaps adding MS-CHAPv2 to the list would save users from misusing it (since it is still widely available) 4) Section 7.10 "This restriction will be relaxed in a future document that specifies how the EMSK can be used". My understanding is that this document will be the EAP Key Management Framework itself (see the ongoing discussion about the incorporation of draft-salowey-eap-key-deriv-02.txt. Florent _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Mar 18 21:29:37 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23831 for ; Thu, 18 Mar 2004 21:29:36 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E76632037E; Thu, 18 Mar 2004 21:17:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BD534203AB; Thu, 18 Mar 2004 21:17:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C92F5203AB for ; Thu, 18 Mar 2004 21:16:17 -0500 (EST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by mail.frascone.com (Postfix) with ESMTP id 55FC82037E for ; Thu, 18 Mar 2004 21:16:15 -0500 (EST) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 19 Mar 2004 03:28:34 +0100 Received: from rd.francetelecom.fr ([10.193.106.38]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Fri, 19 Mar 2004 03:28:33 +0100 Message-ID: <405A5AD3.8080803@rd.francetelecom.fr> From: Florent Bersani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joseph Salowey Cc: jari.arkko@piuha.net, pasi.eronen@nokia.com, eap@frascone.com Subject: Re: [eap] Re: keying issue 221: EMSK usage guidelines References: <000701c40d4a$860741a0$c0246540@amer.cisco.com> In-Reply-To: <000701c40d4a$860741a0$c0246540@amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2004 02:28:33.0903 (UTC) FILETIME=[E04427F0:01C40D59] 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, 19 Mar 2004 03:28:35 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Joe, Thanks for taking the time to read and reply to my metaphysical concerns. I agree with the solution you proposed (to allow the prf negotiation with the fixed prf+ construction, using IKEv2 notations) A few more comments in-line Florent Joseph Salowey wrote: >Hi Florent, > >Thanks for you comments, responses inline below: > >Florent Bersani wrote: > > >>Sorry to catch up late on this one :-( and many thanks to Joe >>and Pasi >>for their very nice draft (draft-salowey-eap-key-deriv-02.txt) >> >>Indeed, it is a follow-up of a question raised during Pasi's >>presentation at IETF 59 in Seoul: should we not mandate the >>PRF used to >>derive the AMSKs from the EMSK or not? (EAP issue 221 and slides >>available at: >>http://www.arkko.com/publications/eap/ietf-59/ietf59-eapkeyfra >>mework.ppt) >> >>Though I understand that specifying a KDF from a well-now one >>(IKEv2's) makes life a lot easier (just one option generally leads to >>interoperability and choosing a good mandatory KDF prevents designers >>from choosing a poor one), I feel a little bit concerned, >>probably for >>two reasons: >> >>1) First, EAP cautiously avoided specifying any cryptographic part so >>far (I guess to preserve its extensibility since it is a >>framework) and >>now we are just including such a part >> >> >> > >[Joe] EAP generates key material, but leaves it open as to how you use it. >This is good, but it can leave to problems if the usage of keys is not >coordinated, the same key can be used for two different purposes which can >lead to problems. A good key derivation framework provides computation >independence between the keys to reduce this problem. > > I totally agree with you! > > > >>2) Second, as the author of an EAP method that takes great pride in >>using a single cryptographic primitive (AES-128), I am little >>bit biased >>again people mandating that we use something depending on SHA1 ;-) >> >> >> > >[Joe] OK I understand this, perhaps there is a way to work around this >problem. > > > >>So, my first reaction would be: we should leave it up to EAP >>methods to >>export such a KDF. And modify the text of section "The EAP AMSK Key >>Derivation Function" to say something like: >> >>"EAP methods MAY export a KDF to derive AMSKs from the EMSK. >> >>In case, an EAP method does not export a KDF to derive MSKs from the >>EMSK, the following KDF MUST (or SHOULD?) be used" >> >>This tends to get me to my second reaction (I am bit slow, I >>know ;-)), >>which is to try and investigate the benefits of suggesting such a >>change, since it obviously complexifies things a little (possible >>euphemism here). And a bunch of additional questions arises from this >>second reaction: >> >>1) What behavior should we specify in case an EAP method does not >>export a KDF, i.e. MUST or SHOULD in my proposed text? And if >>SHOULD is >>the answer, then, what would be the behavior when an AMSK is requested >>when there is no KDF? Possibly, an error I assume... TBD? >> >> >> > > > >>2) What is the interface to the KDF? I guess it would have to >>mimic the >>K,L,D,O format specified in section "The EAP AMSK Key Derivation >>Function". Thus, would it be possible to specify things a little bit >>more, namely: >> >> >> > >[Joe] If we choose to have a variable KDF I agree that it should have a >consistent interface. > > > >>2.1) *On the key to the KDF*: The EMSK neatly fits into >>HMAC-SHA1 since >>its length is precisely the one of the compression function >>of SHA1. In >>case, you use a different KDF (e.g. the one specified in >>EAP-PSK), you >>could have to add an intermediate processing step. So, should we say >>that the exported KDF MUST take as input for K exactly 64 >>bytes - that >>is the whole EMSK (I guess the answer is yes). >> >> > >[Joe] The EMSK seems to be reasonable, but if you are making this internal >to the method, then it doesn't matter as long as both sides agree. > > Well I didn't view this as internal to the method. *My view*: The method after successfully completing would hand over to the rest of the world its decision (success), the keying material available (MSK and EMSK) and possibly the KDF. Then the EMSK and the KDF would have to be handled by a kind of server capable of producing AMSKs upon request. *My understanding of your view*: It seems like your view was that the necessary AMSKs were instantly derived (within the method?) and handed over to the relevant applications. This scenario would not need the EMSK to be exported but only the AMSKs. I think I am misunderstanding you since I find this scenario a bit too restrictive: a peer and a server might not know in advance which EMSK they would need. I guess this "AMSK server" from my view is out of the scope of EAP (implementation details or other protocol to specify how they request AMSKs...) but I just wanted to know if I was off the rocket. > > >>By the way, >>wouldn't it >>be nice to add a security warning on the AMSK, to say that >>although one >>may derive say a 128 byte AMSK, one must not forget that it may come >>from a 128 bit key (for instance the KDK portion of EAP-PSK's PSK)... >>Should we provide a way to track down the "real" strength of >>an AMSK? (I >>guess the answer to this one is no, because it would be too >>complicated) >> >> > >[Joe] This is definitely a security consideration. Yes, deriving the "real" >strength is a bit complicated and probably controversial as well. > > So perhaps, adding some text in section "EAP AMSK Key Derivation" after "The EAP EMSK usage guidelines provide a means for generating multiple application-specific master keys (AMSKs). These AMSKs are then used to derive transient session keys (TSKs), which are used as actual ciphering keys. This allows multiple applications to use keys independently derived from the EAP method." like "It must be remembered that the effective strength of the derived AMSK depend on the keys used to generate it and therefore that it may be far less than its actual length" or include that in the security considerations section, which you seem to favor. BTW, a very stupid comment: will it be clear to everybody that we are deriving symmetric keys or do we need to clarify that (tentative answer: yes, it is obvious and we don't need to do anything) > > >>2.2) *On the key label*: I would recommend specifying the >>length of this >>item. I understand it may be a variable length non-empty >>string of ASCII >>printable characters with no upper limit >> >> >> > >[Joe] OK, what do you think would be a good upper limit, 50 chars? > > Yes, it should be enough :-) In fact I had no precise idea in mind and wasn't even thinking of an upper limit. > > > >>2.3) *On the application data*: I did not find any precision on this >>item. Would it be possible to clarify this, by saying something like >>"the application data is a variable length possibly empty >>sequence of bits"? >> >> >> > >[Joe]I think so. Should we limit this length as well? > > No idea, I would they yes to avoid problems with implementations. I've taken a look at draft-ietf-ipsec-ikev2-12.txt and I did not find anything regarding this point since they don't talk of optional application data. > > >>2.4) *On the output length*: how is the output length >>encoded? does the >>two byte output length encode the output length in bytes or >>in bits? >> >> > >[Joe] I believe it should be bytes. > > > >>(in >>bytes I assume). >> So do I ;-) Do you think this should be explicitly added? >> Also, where does the limit of 255 iterations (hence >>5100 bytes of key material) come from (IKEv2 must explain >>that somewhere >>I think)? >> >> > >[Joe] there is a one byte counter in the KDF that will wrap. > > I had figured that :-) > > >>Should this limit be imposed to any other KDF? >> >> > >[Joe] I don't see any reason why not. 5100 bytes is lots of key material. > > I agree. > > >>Another issue >>close to that one: should we limit in any way the number of AMSK >>(probably the sum of their length) that are derived from an EMSK (I >>guess the answer is no since it would be too complicated but on the >>other hand, it would be nice not to be able to burn down an EMSK >>although this is highly improbable) >> >> >> > >[Joe] In general I think the problem is small, but it has not been >quantified. > Well I've just went into it for "my" KDF (see reference [SOBMO] of my draft EAP-PSK) and I'll include this analysis in the upcoming version of EAP-PSK (02) > Some discussion of this probably belongs in security >considerations along with key strength discussion. > > I agree and I'll try and provide some input on this > > >>3) How would a peer and a server use an AMSK? This should >>probably not >>be specified in any place. So I assume, we could have the following >>scenario: a peer and a server derive an AMSK called the "AMSK >>transport key" which would be used to transport any subsequent AMSK >>to the peer without having the peer to derive them by himself. I just >>wanted to make >>sure it is possible (I of course know some issued this scenario >>obviously raises - the first one being that it makes the AMSK process >>somehow useless - the new AMSKs could perfectly be chosen at >>random by >>the server). I guess I wanted to suggest that we could add a >>word to say >>that the AMSK derivation may not always involve the peer (To >>be honest, >>I do not like my proposition very much ;-) - perhaps >>reformulate it to >>say precisely that the whole point of the AMSKs is to allow >>the network >>and the peer to derive them without having to have them sent >>between them) >> >> >> > >[Joe] One could define such an application, but I think the subsequent AMSKs >you derive in a new way fall under some other specification and I would not >classify them as AMSKs (perhaps EAMSKS :-). > I agree > At one point I had a draft on >using TLVs protected with AMSK to extend the EAP conversation and add >features, but it has expired, if you want I can send you a copy. > > I guess you are referring to draft-salowey-eap-protectedtlv-02.txt. I'll be more than happy to share some thoughts on it with you offline. > > > >>Bottom line: I am not sure that it would be a good idea to allow EAP >>methods to export their KDF but neither am I of the contrary. Anybody >>has more inputs to help me make up my mind? >> >> >> > >[Joe] I think that it is important to have a coordinated way to derive keys. >To this you need a KDF with a standard interface like the one defined in the >draft. While EAP methods that derive keys have internal KDFs they typically >do not have an interface like the one defined so they would have to be >modified in any case. > >Perhaps a better solution is to take the KDF construction defined in the >document and allow for the PRF to be specified independently (IKEv2 does >this). This way you can use AES as the PRF instead of HMAC-SHA1. > >The difficulty is how to decide which PRF to use. Perhaps this should be >attached to the method, AES methods use the AES PRF defined for IKEv2, >methods that use SHA1 use HMAC-SHA1 other make a choice. Some methods in >the future may allow you to negotiate this. The rule could be use SHA1 >unless a method specification specifies otherwise. > >The consistency in the construction would allow implementations with EAP >frameworks to do the derivation in the framework without having to keep the >method state around and it would allow methods that are trying to provide >compact implementations to reduce the number of cryptographic primitives >involved. > > I like the way you propose to solve this and it makes sense to me to take the little bit more you suggest of IKEv2 (allowing the prf negotiation but not the prf+ construction, hence saving some time and hair for implementors) :-)) I would suggest also agree to keep the situation simple the situation by mandating that an EAP method may specify statically which prf it intends to use - to avoid burdening the methods with mandatorily having to negotiate the prf (which some may want to do in the future, as you say). My only remaining concern is the way the AMSK get generated ("the AMSK server" I referred to in the beginning of the mail) but this belongs probably to another thread. Do you think it's worth opening one on it? > > >>Hope my mental torture helped in some way. >> >> >> >[Joe] I think so, but then again I tend to be tortured. > > I don't think so, the solution you suggested (negotiation prf with the fixed prf+ construction) makes a lot of sense to me > > > >>Florent >> >>Jari Arkko wrote: >> >> >> >>>Joseph Salowey wrote: >>> >>> >>> >>>>[Joe] I don't think so, I think that the basic requirement is that >>>>both parties in the EAP exchange can derive the same key name and >>>>that the name is unique. I'm suggesting the methods derive the key >>>>name in their own way. This could make use of nonces, it could send >>>>the key name as authenticated data in the exchange, and there are >>>>probably other >>>> >>>> >>>This would work for me. Others? >>> >>> >>> >>>>possibilities as well. It might be OK to derive the key from the >>>>EMSK, but a few people I mentioned this to disliked it. In theory I >>>>suppose it increases the chance that an attacker can precompute a >>>>partial dictionary that will allow them to compromise some sessions >>>>on a network (its difficult to attack a particular session, but it >>>>may increase the possibility of compromising one arbitrary session >>>>out of many). Perhaps it is not a big deal, perhaps it is worse >>>>than I think it is. >>>> >>>> >>>Ok. >>> >>>--Jari >>> >>>_______________________________________________ >>>eap mailing list >>>eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap >>> >>> > > > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Mar 18 22:01:35 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24660 for ; Thu, 18 Mar 2004 22:01:34 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 462962037E; Thu, 18 Mar 2004 21:49:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B77742053B; Thu, 18 Mar 2004 21:49:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B345C2053B for ; Thu, 18 Mar 2004 21:48:53 -0500 (EST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by mail.frascone.com (Postfix) with ESMTP id C29E82037E for ; Thu, 18 Mar 2004 21:48:51 -0500 (EST) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 19 Mar 2004 03:49:40 +0100 Received: from rd.francetelecom.fr ([10.193.106.38]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Fri, 19 Mar 2004 03:49:39 +0100 Message-ID: <405A5FC6.8070901@rd.francetelecom.fr> From: Florent Bersani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2004 02:49:39.0794 (UTC) FILETIME=[D2CBCB20:01C40D5C] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] EAP viewed by IKEv2 Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-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, 19 Mar 2004 03:49:42 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit While reading draft-ietf-ipsec-ikev2-12.txt, I came across the following text in section 2.16 which you probably know: "In addition to authentication using public key signatures and shared secrets, IKE supports authentication using methods defined in RFC 2284 [EAP]. Typically, these methods are asymmetric (designed for a user authenticating to a server), and they may not be mutual. For this reason, these protocols are typically used to authenticate the initiator to the responder and MUST be used in conjunction with a public key signature based authentication of the responder to the initiator. These methods are often associated with mechanisms referred to as "Legacy Authentication" mechanisms." A bit sad, isn't it, that it refers rather to RFC 2284 and the old EAP methods rather then the new work :-( Florent, of course I am not willing to modify IKEv2 in any way _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Mar 18 22:56:36 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27008 for ; Thu, 18 Mar 2004 22:56:36 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6D7C3203A5; Thu, 18 Mar 2004 22:44:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CE0C2203E0; Thu, 18 Mar 2004 22:44:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EC8E0203E0 for ; Thu, 18 Mar 2004 22:43:01 -0500 (EST) Received: from seunghee.net (seunghee.etri.re.kr [129.254.242.21]) by mail.frascone.com (Postfix) with SMTP id CCEAF203A5 for ; Thu, 18 Mar 2004 22:42:59 -0500 (EST) To: eap@frascone.com From: aboba@internaut.com Message-ID: MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: Thank you! Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-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, 19 Mar 2004 12:54:23 +0900 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Mar 19 00:14:34 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01050 for ; Fri, 19 Mar 2004 00:14:33 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A5C3620553; Fri, 19 Mar 2004 00:02:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9BCBC20421; Fri, 19 Mar 2004 00:02:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EA16220421 for ; Fri, 19 Mar 2004 00:01:18 -0500 (EST) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id 4F8C820420 for ; Fri, 19 Mar 2004 00:01:17 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id i2J5DhJV011401; Fri, 19 Mar 2004 00:13:43 -0500 (EST) From: Nick Petroni To: Jari Arkko Cc: "eap@frascone.com" Subject: Re: [eap] sm-02 nits In-Reply-To: <4059ACDE.2040303@piuha.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 19 Mar 2004 00:13:43 -0500 (EST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Jari et al., I have created a -03b to address these issues. Please take a look and provide feedback so we can produce a -03. 03b can be found at http://www.cs.umd.edu/~npetroni/EAP/. Thanks to Pasi, we now have an appendix with an ASCII table of the state machine. Please *do* note format issues, but I will likely not fix them all until we get closer to a final version -- it's a pain to do. I do want to keep a list though so we get them all. Thanks, nick Nick L. Petroni, Jr. Graduate Student, Computer Science Maryland Information Systems Security Lab University of Maryland http://www.cs.umd.edu/~npetroni On Thu, 18 Mar 2004, Jari Arkko wrote: > Thanks for your quick response Nick. Inline some > answers to your questions: > > >>- Move the second last paragraph after the text > >> that talks about the switch. > > > > I don't quite understand this request. Which paragraph moved where? > > This document describes a state machine based on an EAP "Switch" > model. This model includes events and actions for the interaction > between the EAP Switch and EAP methods. The State Machine and > associated model are informative only. Implementations may achieve > the same results using different methods. > > A brief description of the EAP "Switch" model is given in the > Introduction section. > > => > > This document describes a state machine based on an EAP "Switch" > model. This model includes events and actions for the interaction > between the EAP Switch and EAP methods. A brief description of > the EAP "Switch" model is given in the Introduction section. > > The State Machine and associated model are informative only. > Implementations may achieve the same results using different > methods. > > >>- For some reason, the bottom page heading is right on > >> the next line after text ends. E.g. Section 4.1. > >> I find this a bit confusing, it takes a moment to > >> realize that your eyes have read into the heading and > >> not a continuation of the paragraph. If you can change > >> this easily, please do. If not, don't worry about it... > > > > This is a LaTeX-ism, worst case I will fix it by hand. > > Ok. Don't worry about it. > > >>- Inconsistent capitalization of the sentences explaining > >> variables, see e.g. Sections 4.1.1 vs 4.1.2. > > > > Which do you prefer? start with caps or no? > > Caps, and I think you have it everywhere else except > 4.1.1. > > >>- In Section 5.2, I think it would be useful to add > >> the following just before "m.init": "In the following > >> we will discuss procedure calls that the state machine > >> can make to methods." > > > > done with slight word smithing. "The following describes the interaction > > between the state machine and EAP methods." > > > > Also made this change in 4.2. Furthermore, I made the order of "IN", > > "OUT", and "IN/OUT" consistent between these two sections. > > Very good. > > >>- As discussed with the RFC editor and in IETF-59, > >> we need a .txt version with the state machine > >> as a table. > > > > Working on that now... should have something to show tonight or tomorrow. > > Great, thanks! > > --Jari > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Mar 19 00:25:34 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01666 for ; Fri, 19 Mar 2004 00:25:33 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AC4CD2032C; Fri, 19 Mar 2004 00:13:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7B0CF20425; Fri, 19 Mar 2004 00:13:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8838420425 for ; Fri, 19 Mar 2004 00:12:20 -0500 (EST) 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 8F80F2032C for ; Fri, 19 Mar 2004 00:12:18 -0500 (EST) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 18 Mar 2004 21:29:52 +0000 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 i2J5OeK2028168; Thu, 18 Mar 2004 21:24:40 -0800 (PST) Received: from jsaloweyw2k01 ([10.82.217.122]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 18 Mar 2004 21:31:03 -0800 From: "Joseph Salowey" To: "'Florent Bersani'" Cc: , , Subject: RE: [eap] Re: keying issue 221: EMSK usage guidelines Message-ID: <001d01c40d72$79525c10$c0246540@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <405A5AD3.8080803@rd.francetelecom.fr> Importance: Normal X-OriginalArrivalTime: 19 Mar 2004 05:31:03.0436 (UTC) FILETIME=[5EB24CC0:01C40D73] 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, 18 Mar 2004 21:24:36 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi Florent,=20 This has been a good discussion, more comments in line. =20 Joe Florent Bersani wrote: > Hi Joe, >=20 > Thanks for taking the time to read and reply to my > metaphysical concerns. >=20 > I agree with the solution you proposed (to allow the prf negotiation > with the fixed prf+ construction, using IKEv2 notations) >=20 > A few more comments in-line >=20 > Florent >=20 > Joseph Salowey wrote: >=20 >> =20 >>> 2.1) *On the key to the KDF*: The EMSK neatly fits into HMAC-SHA1 >>> since its length is precisely the one of the compression function >>> of SHA1. In case, you use a different KDF (e.g. the one specified in >>> EAP-PSK), you >>> could have to add an intermediate processing step. So, should we say >>> that the exported KDF MUST take as input for K exactly 64 >>> bytes - that >>> is the whole EMSK (I guess the answer is yes). >>>=20 >>>=20 >>=20 >> [Joe] The EMSK seems to be reasonable, but if you are making this >> internal to the method, then it doesn't matter as long as both sides >> agree.=20 >>=20 >>=20 > Well I didn't view this as internal to the method. >=20 > *My view*: The method after successfully completing would > hand over to the rest of the world its decision (success), > the keying material available (MSK and EMSK) and possibly the > KDF. Then the EMSK and the KDF would have to be handled by a > kind of server capable of producing AMSKs upon request. >=20 > *My understanding of your view*: It seems like your view was > that the necessary AMSKs were instantly derived (within the > method?) and handed over to the relevant applications. This > scenario would not need the EMSK to be exported but only the > AMSKs. I think I am misunderstanding you since I find this > scenario a bit too restrictive: a peer and a server might not > know in advance which EMSK they would need. >=20 > I guess this "AMSK server" from my view is out of the scope > of EAP (implementation details or other protocol to specify > how they request > AMSKs...) but I just wanted to know if I was off the rocket. >=20 [Joe] So for the most part we share the same view. My thinking was that = in an EAP framework and EAP method would hand over the MSK and EMSK to the framework. The framework would then be responsible for generating and controlling AMSKs. I do think that it would be good for a framework to restrict which callers can request which AMSKs and that the EMSK should = not be kept around longer than it needs to be. This may not be possible in = some cases, but may be required in others. How the AMSKs are distributed and controlled is out of scope of EAP, but some suggestions may be nice.=20 >>=20 >>=20 >>> By the way, >>> wouldn't it >>> be nice to add a security warning on the AMSK, to say that although >>> one may derive say a 128 byte AMSK, one must not forget that it may >>> come from a 128 bit key (for instance the KDK portion of EAP-PSK's >>> PSK)... Should we provide a way to track down the "real" strength >>> of an AMSK? (I guess the answer to this one is no, because it would >>> be too complicated)=20 >>>=20 >>>=20 >>=20 >> [Joe] This is definitely a security consideration. Yes, deriving the >> "real" strength is a bit complicated and probably controversial as >> well.=20 >>=20 >>=20 > So perhaps, adding some text in section "EAP AMSK Key > Derivation" after "The EAP EMSK usage guidelines provide a > means for generating multiple application-specific master > keys (AMSKs). These AMSKs are then used to derive transient > session keys (TSKs), which are used as actual ciphering keys. > This allows multiple applications to use keys independently > derived from the EAP method." like "It must be remembered > that the effective strength of the derived AMSK depend on the > keys used to generate it and therefore that it may be far > less than its actual length" or include that in the security > considerations section, which you seem to favor. >=20 > BTW, a very stupid comment: will it be clear to everybody > that we are deriving symmetric keys or do we need to clarify > that (tentative > answer: yes, it is obvious and we don't need to do anything) >=20 [Joe] Yes, this is good, I think it is worthwhile to perhaps mention in = more than one place. >>> 2.4) *On the output length*: how is the output length encoded? does >>> the two byte output length encode the output length in bytes or >>> in bits? >>>=20 >>>=20 >>=20 >> [Joe] I believe it should be bytes. >>=20 >>=20 >>=20 >>> (in >>> bytes I assume). >>>=20 > So do I ;-) Do you think this should be explicitly added? >=20 [Joe] yes. >>=20 >>> Another issue >>> close to that one: should we limit in any way the number of AMSK >>> (probably the sum of their length) that are derived from an EMSK (I >>> guess the answer is no since it would be too complicated but on the >>> other hand, it would be nice not to be able to burn down an EMSK >>> although this is highly improbable) >>>=20 >>>=20 >>>=20 >>=20 >> [Joe] In general I think the problem is small, but it has not been >> quantified.=20 >>=20 > Well I've just went into it for "my" KDF (see reference > [SOBMO] of my draft EAP-PSK) and I'll include this analysis > in the upcoming version of EAP-PSK (02) >=20 >> Some discussion of this probably belongs in security considerations >> along with key strength discussion. >>=20 >>=20 > I agree and I'll try and provide some input on this [Joe] I would appreciate this.=20 >>=20 >> [Joe] I think that it is important to have a coordinated way to >> derive keys. To this you need a KDF with a standard interface like >> the one defined in the draft. While EAP methods that derive keys >> have internal KDFs they typically do not have an interface like the >> one defined so they would have to be modified in any case. >>=20 >> Perhaps a better solution is to take the KDF construction defined in >> the document and allow for the PRF to be specified independently >> (IKEv2 does this). This way you can use AES as the PRF instead of >> HMAC-SHA1.=20 >>=20 >> The difficulty is how to decide which PRF to use. Perhaps this >> should be attached to the method, AES methods use the AES PRF >> defined for IKEv2, methods that use SHA1 use HMAC-SHA1 other make a >> choice. Some methods in the future may allow you to negotiate this. >> The rule could be use SHA1 unless a method specification specifies >> otherwise.=20 >>=20 >> The consistency in the construction would allow implementations with >> EAP frameworks to do the derivation in the framework without having >> to keep the method state around and it would allow methods that are >> trying to provide compact implementations to reduce the number of >> cryptographic primitives involved. >>=20 >>=20 > I like the way you propose to solve this and it makes sense > to me to take the little bit more you suggest of IKEv2 > (allowing the prf negotiation but not the prf+ construction, > hence saving some time and hair for implementors) :-)) >=20 > I would suggest also agree to keep the situation simple the > situation by mandating that an EAP method may specify > statically which prf it intends to use - to avoid burdening > the methods with mandatorily having to negotiate the prf > (which some may want to do in the future, as you say). >=20 > My only remaining concern is the way the AMSK get generated > ("the AMSK server" I referred to in the beginning of the > mail) but this belongs probably to another thread. Do you > think it's worth opening one on it? >=20 [Joe] I think we are thinking the same, but if you think there are still differences the we should start a separate thread. I'd like to make sure that the EMSK (and the MSK) is not handled lightly. I realize that it = may be difficult for implementations to enforce who can obtain which AMSKs = and how long EMSK is maintained, but I think it is desirable. How the enforcement is done and how keys are distributed is beyond the scope of this, but it may be important to consider such things as they are part = of the system.=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Mar 19 09:05:53 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03865 for ; Fri, 19 Mar 2004 09:05:53 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BB88B20569; Fri, 19 Mar 2004 08:53:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5B7D8203BE; Fri, 19 Mar 2004 08:53:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 02998203BE for ; Fri, 19 Mar 2004 08:52:12 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 718361FF5F for ; Fri, 19 Mar 2004 08:52:10 -0500 (EST) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 17486898C4; Fri, 19 Mar 2004 16:04:36 +0200 (EET) Message-ID: <405AFD5E.20800@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Florent Bersani Cc: "eap@frascone.com" Subject: Re: [eap] EAP viewed by IKEv2 References: <405A5FC6.8070901@rd.francetelecom.fr> In-Reply-To: <405A5FC6.8070901@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: Fri, 19 Mar 2004 16:02:06 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Florent Bersani wrote: > While reading draft-ietf-ipsec-ikev2-12.txt, I came across the following > text in section 2.16 which you probably know: > > "In addition to authentication using public key signatures and shared > secrets, IKE supports authentication using methods defined in RFC 2284 > [EAP]. Typically, these methods are asymmetric (designed for a user > authenticating to a server), and they may not be mutual. For this > reason, these protocols are typically used to authenticate the initiator > to the responder and MUST be used in conjunction with a public key > signature based authentication of the responder to the initiator. These > methods are often associated with mechanisms referred to as "Legacy > Authentication" mechanisms." > > A bit sad, isn't it, that it refers rather to RFC 2284 and the old EAP > methods rather then the new work :-( Regarding the reference, I have complained about it at least once on the IPsec mailing list, but apparently without an effect... Please complain again. There's absolutely no reason to use the old reference, and a lot of interoperability and other issues come clearer with the new reference. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Mar 19 15:48:39 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21847 for ; Fri, 19 Mar 2004 15:48:38 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 895231FF62; Fri, 19 Mar 2004 15:36:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2261620338; Fri, 19 Mar 2004 15:36:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 45D3520338 for ; Fri, 19 Mar 2004 15:35:11 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id D77E91FF62 for ; Fri, 19 Mar 2004 15:35:08 -0500 (EST) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 820AD898C5 for ; Fri, 19 Mar 2004 22:47:35 +0200 (EET) Message-ID: <405B5BD1.3030901@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.5) Gecko/20031007 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] impacts of IKEv2 early use of keying material Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-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, 19 Mar 2004 22:45:05 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit In the last couple of days, there's been a discussion in the IPsec WG about the exact time when a key is available from EAP. It turns out that if the key is available at the client side only after EAP Success has been received, an additional roundtrip will be needed in IKEv2 when EAP is used. If the client can use the key after having sent its last response message, this roundtrip can be avoided. For a more in-depth view to the issue, see the end of this e-mail where I have copied some text from messages by Pasi, Hannes and Yoav Nir on the IPsec list. It looks like RFC 2284bis, which just got approved, does not say anything about this. The state machine document, however, appears to set eapKeyAvailable only after EAP Success has been received. (The eapKeyData variable, however, is set immediately.) The question for EAP WG is as follows: 1) Is the above summary of the situation wrt 2284bis and state machine correct? 2) If a change would be made in the state machine document to make the key available sooner, would this cause any problems to o RFC 2284bis o Other parts of the state machine o 802.11 interfaces o Something else 3) What's your preferred approach? 4) Other comments? I have sent an e-mail to the IPsec list stating that its desirable to not change 2284bis but changes to the state machine are in theory possible unless they impact something else. I'll summarize the responses to the IPsec list. --Jari --------------Pasi said------------------ Having the responder send the AUTH payload and EAP-Success in the same message is OK. However, this does not solve the initiator's case. "As soon as it can" is still a bit ambigous, and in draft -12 the initiator sends the AUTH payload _before_ receiving EAP-Success. But EAP peer state machine currently "exports" the key only _after_ receiving EAP-Success. So it seems that we need to either slightly change how EAP works or add another roundtrip. Both options are certainly feasible, but IMHO the latter requires less work... --------------Hannes said---------------- in the past people have worried a lot about the number of roundtrips. so far there was no protocol example where the keys have to be exported before receiving the eap-success message. ikev2, however, seems to be one. to be more specific the following two variants are on the table (if we use eap-aka as an eap method within ikev2): Variant I: AUTH payload sent by the initiator before receiving the EAP success message. Initiator Responder ----------- ----------- HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {IDi, [CERTREQ,] [IDr,] SAi2, TSi, TSr} --> <-- HDR, SK {IDr, [CERT,] AUTH, EAP-Request/AKA-Challenge (AT_RAND, AT_AUTN, AT_MAC) } HDR, SK {EAP-Response/AKA-Challenge(AT_RES, AT_MAC), AUTH} --> <-- HDR, SK {EAP-Success, AUTH, SAr2, TSi, TSr } Variant II: AUTH payload sent by the initiator after receiving the EAP success message. consequence: one additional roundtrip Initiator Responder ----------- ----------- HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {IDi, [CERTREQ,] [IDr,] SAi2, TSi, TSr} --> <-- HDR, SK {IDr, [CERT,] AUTH, EAP-Request/AKA-Challenge (AT_RAND, AT_AUTN, AT_MAC) } HDR, SK {EAP-Response/AKA-Challenge(AT_RES, AT_MAC)} --> <-- HDR, SK {EAP-Success, AUTH} HDR, SK { AUTH } --> <-- HDR, SK { SAr2, TSi, TSr } ------------Yoav Nir said------------------ How about this: The client will send the AUTH payload as soon as it can, this can be before or after the EAP-success message, depending on protocol and implementation. The server will cache the AUTH payload as soon as it is received. It will only verify the client's AUTH and send the {AUTH, SAr2, TSi, TSr} when both conditions are met: (1) The EAP success has been received from the EAP state machine, and (2) The AUTH payload has been received from the peer. If we go against draft-ietf-rfc2284bis-09 and use OTP or GTC to transfer cleartext passwords (which is OK because the channel is encrypted) there is no key and the client can send the AUTH payload in message #5, and the whole exchange can be done by message #6. If some method generates a key, but the EAP state machine cannot figure it out before getting the success message, then there is no choice, and we need an extra roundtrip after the success message. Does this sound reasonable? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Mar 22 12:13:10 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06736 for ; Mon, 22 Mar 2004 12:13:09 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 50B2A1FDE3; Mon, 22 Mar 2004 12:01:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E341720275; Mon, 22 Mar 2004 12:01:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5BEA720222 for ; Mon, 22 Mar 2004 12:00:35 -0500 (EST) 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 704C61FDDE for ; Mon, 22 Mar 2004 12:00:33 -0500 (EST) 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 i2MHBxaD029464; Mon, 22 Mar 2004 09:12:00 -0800 (PST) Received: from jsaloweyw2k01 ([10.82.216.168]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 22 Mar 2004 09:18:24 -0800 From: "Joseph Salowey" To: , Subject: RE: [eap] impacts of IKEv2 early use of keying material Message-ID: <011801c41030$c87c9920$c0246540@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <405B5BD1.3030901@piuha.net> Importance: Normal X-OriginalArrivalTime: 22 Mar 2004 17:18:25.0023 (UTC) FILETIME=[AF17C8F0:01C41031] 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, 22 Mar 2004 09:11:56 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable eap-admin@frascone.com wrote: > In the last couple of days, there's been a discussion in the > IPsec WG about the exact time when a key is available from > EAP. It turns out that if the key is available at the client > side only after EAP Success has been received, an additional > roundtrip will be needed in IKEv2 when EAP is used. If the > client can use the key after having sent its last response > message, this roundtrip can be avoided. For a more in-depth > view to the issue, see the end of this e-mail where I have > copied some text from messages by Pasi, Hannes and Yoav Nir > on the IPsec list. >=20 > It looks like RFC 2284bis, which just got approved, does > not say anything about this. The state machine document, > however, appears to set eapKeyAvailable only after EAP > Success has been received. (The eapKeyData variable, however, > is set immediately.) >=20 > The question for EAP WG is as follows: >=20 > 1) Is the above summary of the situation wrt 2284bis and state > machine correct?=20 >=20 [Joe] In section 4.2 of 2284bis it provides for lost success messages so = it seems that EAP-Success is not strictly required.=20 > 2) If a change would be made in the state machine document > to make the key available sooner, would this cause any =20 > problems to=20 >=20 > o RFC 2284bis > o Other parts of the state machine > o 802.11 interfaces > o Something else >=20 [Joe] It could be possible for a method to be designed such that the = client doesn't know when the server is done. In this case the keys will be = made available before the method is done. In this case new keys would have = to be obtained for each round the client though it was done. I don't think current key deriving EAP methods exhibit this behavior, but It is not eliminated by the 2284bis. > 3) What's your preferred approach? >=20 [Joe]Allow the key to be available once the Peer thinks it has completed successfully. =20 > 4) Other comments? >=20 [Joe] There may be an additional problem. There is nothing stopping a method from exhibiting the following behavior: the client thinks it is done, but the server requires another message exchange. In this case = there may be more than one AUTH message sent by the client. Would this cause = a problem in IKEv2? If it does then an additional constraint must be = placed on the EAP mechanisms used in IKE. The client must know when the EAP mechanism has completed and no more challenges will be issued from the server (the client may not know what the actual sever decision is since = that will be communicated through other means). I think most methods adhere = to this. > I have sent an e-mail to the IPsec list stating that its > desirable to not change 2284bis but changes to the state > machine are in theory possible unless they impact something else. >=20 > I'll summarize the responses to the IPsec list. >=20 > --Jari >=20 > --------------Pasi said------------------ >=20 > Having the responder send the AUTH payload and EAP-Success > in the same message is OK. However, this does not solve the > initiator's case. "As soon as it can" is still a bit > ambigous, and in draft -12 the initiator sends the AUTH > payload _before_ receiving EAP-Success. But EAP peer state > machine currently "exports" the key only _after_ receiving > EAP-Success.=20 >=20 > So it seems that we need to either slightly change how EAP > works or add another roundtrip. Both options are certainly > feasible, but IMHO the latter requires less work... >=20 > --------------Hannes said---------------- >=20 > in the past people have worried a lot about the number of > roundtrips. so far there was no protocol example where the > keys have to be exported before receiving the eap-success > message. ikev2, however, seems to be one. >=20 > to be more specific the following two variants are on the > table (if we use eap-aka as an eap method within ikev2): >=20 > Variant I: >=20 > AUTH payload sent by the initiator before receiving the EAP > success message. >=20 >=20 > Initiator Responder > ----------- ----------- > HDR, SAi1, KEi, Ni --> >=20 > <-- HDR, SAr1, KEr, Nr, > [CERTREQ]=20 >=20 > HDR, SK {IDi, [CERTREQ,] [IDr,] > SAi2, TSi, TSr} --> >=20 > <-- HDR, SK {IDr, [CERT,] AUTH, > EAP-Request/AKA-Challenge (AT_RAND, > AT_AUTN, AT_MAC) } >=20 > HDR, SK {EAP-Response/AKA-Challenge(AT_RES, AT_MAC), > AUTH} --> >=20 > <-- HDR, SK {EAP-Success, AUTH, > SAr2, TSi, TSr } >=20 >=20 > Variant II: >=20 > AUTH payload sent by the initiator after receiving the EAP > success message. > consequence: one additional roundtrip >=20 > Initiator Responder > ----------- ----------- > HDR, SAi1, KEi, Ni --> >=20 > <-- HDR, SAr1, KEr, Nr, > [CERTREQ]=20 >=20 > HDR, SK {IDi, [CERTREQ,] [IDr,] > SAi2, TSi, TSr} --> >=20 > <-- HDR, SK {IDr, [CERT,] AUTH, > EAP-Request/AKA-Challenge (AT_RAND, > AT_AUTN, AT_MAC) } >=20 > HDR, SK {EAP-Response/AKA-Challenge(AT_RES, AT_MAC)} --> >=20 > <-- HDR, SK {EAP-Success, AUTH} >=20 > HDR, SK { AUTH } --> >=20 > <-- HDR, SK { SAr2, TSi, TSr } >=20 > ------------Yoav Nir said------------------ >=20 > How about this: The client will send the AUTH payload as > soon as it can, this can be before or after the EAP-success > message, depending on protocol and implementation. >=20 > The server will cache the AUTH payload as soon as it is > received. It will only verify the client's AUTH and send the > {AUTH, SAr2, TSi, TSr} when both conditions are met: (1) The > EAP success has been received from the EAP state machine, and > (2) The AUTH payload has been received from the peer. >=20 > If we go against draft-ietf-rfc2284bis-09 and use OTP or GTC > to transfer cleartext passwords (which is OK because the > channel is encrypted) there is no key and the client can send > the AUTH payload in message #5, and the whole exchange can be > done by message #6. If some method generates a key, but the > EAP state machine cannot figure it out before getting the > success message, then there is no choice, and we need an > extra roundtrip after the success message. >=20 > Does this sound reasonable? >=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 Mar 23 14:46:44 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20938 for ; Tue, 23 Mar 2004 14:46:43 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4C12D20213; Tue, 23 Mar 2004 14:35:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C80AB20518; Tue, 23 Mar 2004 14:35:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1ADBB20518 for ; Tue, 23 Mar 2004 14:34:48 -0500 (EST) Received: from exch01.bridgewatersys.com (bws10.bridgewatersystems.com [216.113.7.10]) by mail.frascone.com (Postfix) with ESMTP id 0D5AA20213 for ; Tue, 23 Mar 2004 14:34:46 -0500 (EST) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Tue, 23 Mar 2004 14:46:15 -0500 Message-ID: From: Avi Lior To: "'eap@frascone.com'" Cc: "'dstanley@agere.com'" , "'jesse.walker@intel.com'" , "'bernarda@microsoft.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] Comments on draft-walker-ieee802-req-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: Tue, 23 Mar 2004 14:46:11 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) I have been reading draft-walker-ieee802-req-00.txt and comparing it to 2284bis-09 Note that its 09 and not 07. I found the following: In walker you say: [3] Synchronization of state. This corresponds to the "Protected result indication" security claim defined in [RFC2284bis], Section 7.2.1. The problem: Section 7.2.1 of 2284bis-09 does not contain "Protected result indication". This now appears in section 7.16 of 2284bis-09. EDITORIAL COMMENT [5] Protection against man-in-the-middle attacks. This corresponds to the "Cryptographic binding", "Integrity Protection", "Replay protection", and "Session Independence" security claims defined in [RFC2284bis], Section 7.2.1. In the above use: "Integrity protection" instead of "Integrity Protection" "Session independence" instead of "Session Independence" EDITORIAL COMMENT Rewrite: 2.5. Non-compliant EAP authentication methods EAP-MD5-Challenge (the current mandatory-to-implement EAP authentication method), is defined in [RFC2284bis] Section 5.4. EAP-MD5-Challenge and two EAP authentication methods defined in [RFC2284bis], One-Time Password (Section 5.5) and Generic Token Card (Section 5.6), are non- compliant with the requirements defined in this document. As: 2.5. Non-compliant EAP authentication methods EAP-MD5-Challenge (the current mandatory-to-implement EAP authentication method), defined in [RFC2284bis] (Section 5.4) and the two EAP authentication methods defined in [RFC2284bis], One-Time Password (Section 5.5) and Generic Token Card (Section 5.6), are non- compliant with the requirements defined in this document. ----------------------------- Avi Lior Bridgewater Systems Corp. Phone: 613.591.9104 x 6417 Cell : 613.297.2177 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From lcngvgb@cnnb.net Wed Mar 24 01:41:08 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01007 for ; Wed, 24 Mar 2004 01:41:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B624Z-0001pI-00 for eap-archive@ietf.org; Wed, 24 Mar 2004 01:41:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B623Z-0001da-00 for eap-archive@ietf.org; Wed, 24 Mar 2004 01:40:06 -0500 Received: from host-216-153-176-39.har.choiceone.net ([216.153.176.39]) by ietf-mx with smtp (Exim 4.12) id 1B623A-0001SN-00; Wed, 24 Mar 2004 01:39:40 -0500 Received: from 226.14.0.91 by 216.153.176.39; Wed, 24 Mar 2004 09:39:13 +0300 Message-ID: From: "Olin Hubbard" Reply-To: "Olin Hubbard" To: eap-archive@ietf.org Subject: Fwd: Meds and Pills prescribed online and shipped to you discreetly overnight Date: Wed, 24 Mar 2004 04:34:13 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--3169776372619667" X-Webmail-Time: Wed, 24 Mar 2004 08:37:13 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.1 required=5.0 tests=BIZ_TLD,CLICK_BELOW,HTML_50_60, HTML_FONTCOLOR_UNSAFE,HTML_LINK_CLICK_HERE,HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----3169776372619667 Content-Type: text/html; Content-Transfer-Encoding: 7Bit

    Hello,

    improving the quality of people's lives is what Prescription Medications are designed to do and CheapestMeds believes that you deserve access to these medications. By having doctors available to review your needs, CheapestMeds is ready to help you get the treatment you need.

    Make it easy for you to order meds. Click here.

    Owok dalzell halo commonplace amoebae asphalt ytterbium bladdernut abstruse alkane censor brother uk backplate betray . Jbunk euphemism blowup congregate inceptor concomitant function accomplice sommelier patio ! Iacoustic umlaut transmission necromancer viewport electrophorus inefficacy july chairwomen analeptic constitution cowlick brisk

    If this notice has reached you in error, please notify us by clicking here ----3169776372619667-- From eap-admin@frascone.com Wed Mar 24 07:48:48 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19066 for ; Wed, 24 Mar 2004 07:48:48 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C9BA720561; Wed, 24 Mar 2004 07:37:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8A99B20555; Wed, 24 Mar 2004 07:37:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9B0E920555 for ; Wed, 24 Mar 2004 07:36:34 -0500 (EST) Received: from s-psd99ksgrat11.net (unknown [221.148.59.218]) by mail.frascone.com (Postfix) with SMTP id 8EB41204BF for ; Wed, 24 Mar 2004 07:36:32 -0500 (EST) To: eap@frascone.com From: aboba@internaut.com Message-ID: MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Protected message Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-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, 24 Mar 2004 21:32:55 +0900 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Mar 24 08:33:43 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21095 for ; Wed, 24 Mar 2004 08:33:42 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A60521FF4B; Wed, 24 Mar 2004 08:22:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 08DBE1FF6B; Wed, 24 Mar 2004 08:22:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 769581FF6B for ; Wed, 24 Mar 2004 08:21:31 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 3C09E1FF4B for ; Wed, 24 Mar 2004 08:21:29 -0500 (EST) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id DCC798996E for ; Wed, 24 Mar 2004 15:32:57 +0200 (EET) Message-ID: <40618D6A.9090204@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.5) Gecko/20031007 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] ietf-59 meeting minutes Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-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, 24 Mar 2004 15:30:18 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Thanks to Dirk and Henrik for taking minutes. I'll submit the minutes to the proceedings early next week, so if you want to clarify something in the minutes, send e-mail before that. ---- Extensible Authentication Protocol WG (eap) THURSDAY, March 4 at 1300-1500 CHAIRS: Bernard Aboba Jari Arkko SCRIBES: Dirk Kroeselberg Henrik Levkowetz PRESENTATIONS: http://www.arkko.com/publications/eap/ietf-59 No changes to agenda. 1. Status update (Jari) - 2284bis has been approved as an RFC, IANA process will take some time... - The state machine -02 draft is currently in 2nd WG last call. Read the document and send comments. - The keying framework has not been updated since last IETF. Still has open issues. Current plan is to finish this in September 04. For this to go forward needs participation and input from the workgroup - Draft-ietf-eap-netsel-problem-00.txt on network selection has been submitted as input to 3GPP, IEEE, some feedback is available. - Binding problem definition: no update available. - EAP-over Radius approved as RFC3579; EAP-Diameter is in AAA WG LC. - EAP over diameter in aaa wg last call, read and comment - A NAI (RFC2486bis) update is available in draft-arkko-roamops-rfc2486bis-00.txt. - Methods can be submitted - Lot of recent method activity. - Since 2284bis was approved, expert review for IANA method allocation is necessary. No comments on Jari's status update. 2. EAP State machine (Pasi Eronen) Drafts: - http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-02.pdf Issues: - http://www.drizzle.com/~aboba/EAP/eapissues.html A number of issues were found during 1st WGLC. The authors hope to have addressed them all. Issue owners are requested to check whether the issues are properly addressed in the draft. The document does not address tunneled methods any more. Issues: - Peer-to-peer operation: The authors believe no changes are necessary, considering IEEE. - RFC editor issue: State diagrams will be provided in ASCII. 3. Keying framework issues (Pasi): Drafts: - http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-01.txt - http://ietf.levkowetz.com/drafts/eap/keying/ Issues: - http://www.drizzle.com/~aboba/EAP/eapissues.html Presented by Pasi, since Bernard was not present. There was no update since IETF-58. A new version is in preparation. There are certain open issues: - AAA-Key vs. MSK: In normal 802.11i, AAA-Key=MSK. This may be different for lying-NAS. The lying-NAS problem, however, can be solved by providing "channel bindings" in EAP methods rather than specifying AAA-Key=PRF(...). Solving the lying-NAS is not considered urgent. The new draft will discuss channel binding issues. Alper Yegin: Are there general guidelines for when to set AAA-Key to MSK? Pasi: proposal is to set AAA-Key=MSK in general. Jari: This implies the MSK is reserved as AAA key only. If something else is to be done, e.g. for fast handoff, use EMSK. - Issue 221: EMSK: draft-salowey-eap-key-deriv-02 will be included in the keying framework. This will mandate a prf: IKEv2 prf+ with HMAC-SHA-1. Florent: Why do we have to specify how to derive keys, instead of specifying that they have to be cryptographically independent? Pasi: If you use 2 different PRFs there is no guarantee that they are cryptographically independent, so we need to specify this. Jari: Does it have to be the same PRF for all keys for one session, or for all sessions? Pasi: All sessions Jari: If this is done in the method, the method can still negotiate other prfs. Simon(?): We don't need a prf here. Why is the HMAC used. Pasi: This is the way it is typically done. Do not want to invent anything new. 4. Binding problem update, Farid Adrangi, (5 min) Drafts: - http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-04.txt Issues: - http://www.drizzle.com/~aboba/EAP/eapissues.html Version 4 of the draft is available for review. Version 5 is currently being worked on for next IETF. Update plan is to synchronize the draft with keying framework. The authors want to verify if this understanding is correct: - Compound binding MAC key - EMSK - Compound session key - MSK (please comment) Jari: Are people referring to this draft when developing new methods? Have people checked whether the solutions e.g. of IKEv2 or PEAPv2 conform to the draft? Otherwise it may not have much relevance. Glenn: Does the draft solve any problem at all? In fact there is no MITM attack. It is a combination of other attacks where the draft does not help. The draft only solves a small subset that can easily be bypassed. If an evil access point negotiates plaintext passwords, any keys can be derived. If you cannot negotiate down from PEAP, there is no MitM attack. The draft's assumptions are ill-specified. Jari: Can't say that I agree, have to think about it. Needs to be discussed, please post to the list Glenn: Done, stunning silence. Jari: Document useless? Glenn: No, it points out valid things for tunneled methods, but it does not solve the problem it poses. Jari: Please comment on the list 5. Network selection, Farid Adrangi, Jari Arkko (25 min) Drafts: - http://www.ietf.org/internet-drafts/draft-ietf-eap-netsel-problem-00.txt - http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-and-selection-01.txt - http://www.ietf.org/internet-drafts/draft-arkko-roamops-rfc2486bis-00.txt Presentation by Jari/Farid: Network selection comes with multiple problems: 1. Access network discovery 2. Identifier selection 3. Selection of roaming intermediaries 4. Payload routing Activities to perform are - Discovery - Decision - Indicating the selected network Recommendations * All 4 problems are relevant * Potential need for new solutions These problems are _really_ _really_ hard if * there are a lot of networks * you want to do it securely * there are many different ways to do this Given that the problem _is_ hard, it may be that we can't solve it all now. 3GPP and 802.11 were requested to provide feedback: 3GPP SA2 WLAN group: - problems 1 and 3 are relevant to 3gpp, but not the others. - 3gpp uses existing l2 mechanisms for problem 1 - they expect an IETF solution to problem 3 for Release 6 (pretty soon) IEEE 802.11 meeting summary - alternatives are relevant for one of their study groups - they don't know what kind of solutions they need now - other groups also working on related problems * Solution space - Believe there is interest in problems 1 and 3 - Pretty clear problem 1 belongs to link layer - Problem 3 belongs at least in part in IETF. There may be mechanisms at lower layers that effectively advertise relevant information also for higher levels than L2 - If there's an IETF intermediary solution, it will probably be relatively short-term - We already today have configured databases on the client, and advertised information; must be able to switch to other source. - NAIs discussed in roamops draft Osok: SA2 ready to use EAP based solutions not only for problem 3 but also for problem 1. Agreed that ESSID cannot always be used to select access point. Farid: Problems 1 and 3 may be intertwined, may need to do 1 based on result of 3 Osok: Cannot use ESSID only, also in situations where we don't want David Johnston (Chair of 802.21 group): There are ways of doing link layer discovery and maybe better ways upcoming. 802.21 is talking about providing media-independent link-layer discovery. EAP may be viable for the near-term, but the critical part is the information in the discovery. This information needs to map into a wider information model used by 3GPP, IEEE, etc. Glenn: The only reason this needs to be in EAP is that - We're selecting from private networks here - commercial or not - and have to select the path of the aaa packets because providers won't carry other people's aaa packets. Serge Manning: Don't know if EAP solutions are the best, but even if .21 comes up with something, we'll have to be able to work with existing .11 APs Pasi: Why is aaa routing difficult - all AccessAccept packets forwarded indicates willingness to carry the traffic of somebody, and may result in monetary pain if you do it without getting paid Glenn: Forwarding of aaa packet is an implied contract? The routing of aaa packets? How can that be?? That's crazy! Pasi: The AAA signaling is about accepting responsibility to cover costs. The operators want to be in control. Glenn: Have to pick what network to carry your traffic, that's ok. And you have to have an agreement between providers. But just _forwarding_ the aaa packets, to set up the correct route for traffic should not be a problem. Jari: Two problems, finding an access network and selecting who is to carry the traffic. Glenn: The first part I understand, but not why the rest of the stuff has to be done in EAP. Farid: Selecting mediating networks is required by 3GPP, operators etc. Jari: Discuss this offline. Someone: Are there plans to have PP2 review this as well? They do not have problem 3, but the others. Jari: I have received unofficial indications that they are fine with what IEEE does. Farid's presentation on 3GPP approach: EAP-based mediating network selection Use case 1: WLAN client moves into a hotspot advertising the clients HSN SSID. Use case 2 : WLAN client moves into hotspot advertising one or more of WLAN clients HSN roaming partner SSIDs but not its HSN SSID. Use case 3: WLAN client moves into a hotspot advertising only unrecognized SSIDs (continued). Different agreements between hotspots, mediating networks and HSN are in place. How to find the best path? (e.g. unrecognized SSID belongs to a HSN that has a roaming agreement with a specific mediating network only. The hotspot could have an agreement with one HSN only) Alper: Can there be more than one mediating network in the path? Farid: 3GPP only considers one level of indirection. Lauri: Is there any implicit assumption that client will have to know paths through the net? Farid: No, looks up each intermediary network discovered in an preconfigured database. Problem scope: Access network selection, mediating network selection. Presentation solution overview for each scenario. Solution proposed: - complies with 2284bis, uses 2486bis bang syntax - may not require any changes to access points - uses EAP Identity Rewquest to deliver identities from the local aaa server Jari's presentation on next steps for network selection: - need to ask IEEE 802 whether discovery part of problem 3 is being considered, and when results would be available. - need a clear problem definition as input for the groups working on the long-term L2 solutions. - need to decide how to accommodate the selection of roaming intermediaries; bang syntax? - next steps for the NAIbis update are currently being discussed with ADs - this will not be part of the EAP WG - need to decide how roaming discovery is performed - wait for final l2 solution - short-term solution now until L2 solution arrives Comment by 802.21 chair: Both solutions are appropriate. Jari: What to do: - We could turn this entirely over to future Layer 2 mechanisms - We could handle this within EAP, according to Farid's draft or similar - We could leave this up to individual vendors and proprietary solutions - We could decide to do nothing. L2 is the best scheme efficiency-wise. Needs at least a firmware upgrade. Farid's draft: no AP upgrades if done from AAA proxy. Fast to specify. Not very clean way, but only short-term solution. Vendor-specific: Might get many, even from SDOs. Alper: Why does the first option pass information between EAP and L2? Jari: If the lower layer discovers something, it is passed up? Alper: Could use PANA to do discovery at lower level.. Glenn: If these are private networks, they can do it on their own, without any standard. Goes back to the point: Who cares if there are many? Farid: Many solutions create market fragmentation Jari: France telecom may have their own scheme, but they won't have their own Windows or their own phone. Glenn: Informational is not enough, Standard is going to be required to make vendors pick it up. Jari: There are tradeoffs with the vendor-specific thing Steven Hayes (3G-IETF coordinator): 3GPP timeframe needs clear indication where IETF wants to go on this problem. Stage3 work needs to be done in about 6 Months. Better for the market not to have a "vendor" solution. Yoshi Ohba: Don't prefer any particular solution, but needs to consider threats. Farid's proposal has weaknesses. Jari: AAA works within the constraints of the contracts in place. So security problems in network are limited. Cisco guy (speaking as 3GPP2 member): Question to Steve (3G), whether there is any preference. Steven: 3GPP preference is to progress Farid's draft which is the quickest solution. Strawpoll: - Option 1: ~3 - Option 2: ~11 - Option 3: ~2 - Option 4: ~1 Alper: If we go for option 2, will we still come up with recommendations for L2 designers? Jari: Yes, that is an issue, but session needs to move on. Steven: What is the time plan? Jari: We have consensus here on working on this, but we need to ask the same question on the mailing list. 6. Methods update, Jari Arkko (15 min) Current state: - only 4 methods in RFC - There are lots of methods in Internet drafts, lots of old/expired ones, or even undocumented methods (almost the majority). Conclusion: This is not good. - Many methods have a similar intent like tunneling methods. - There were many requests to IANA before 2284bis was approved. - Now after 2284 bis approval, you either use the vendor-specific method way defined there, or you do a draft and get expert review. 7. New method presentations: EAP Bluetooth (Hamsang Kim, INRIA): - Scenario is a Bluetooth zone, e.g. in a Wi-Fi network. Infrastructure-based methods (EAP/AAA) are considered useful here. Scenario includes wireless station (STA), AP, AS. - Objective is to support Bluetooth security. - Approach is EAP over EAP. Relies on generic EAP protocols (e.g. EAP-TLS). - Additional backend exchanges are required, and still need to be defined. Draft has been sent to Bluetooth SDO for comments. - Comments on the EAP list are solicited. Jari: Send comments to the list, as we are running out of time. EAP-PSK (Florent Bersani): - Defines a simple symmetric-key EAP method - Uses AES-128 as its sole primitive. - It is designed with WLAN in mind. - It is currently being implemented, sources will be made available. - Should be mature at next IETF. According to the presenter the method is IPR-free. 8. 802.11 requirements, Jari: - We have request from IEEE to publish EAP method requirements (draft-jwalker-...). This is currently in IESG last call. Please review and send comments to the list. Question: How can we move forward to have a method standardized Jari: This needs to be discussed with the ADs. 9. Pasi (IKEv2 and EAP): Draft with Hannes Tschofenig. IKEv2 supports EAP authentication. It has specific requirements to EAP methods. The draft explores how to skip public-key signatures (that is mandated in IKEv2 for the responder-side) for strong EAP methods. This avoids unnecessary PKIs. An example method is EAP-AKA. First draft explores various alternatives how to implement this in IKEv2. Comments are welcome. Question: How to take this forward? Is the EAP WG the right place? Pasi: IPsec does not take new work items. So possibly an individual submission? Jari: Talk to the security ADs Steve Bellovin: Be cautions about modifications to IKEv2. Extensions are ok, but do not modify. Pasi: The proposal has an option to avoid such changes. Someone: Is there any overhead for EAP mutual auth.? Pasi: No, the overhead is actually the IKEv2 server authentication. Darryl Piper: Is there a requirements document associated with this? As an IKEv2 person I'm a bit curious about the motivation for this draft. Don't see a point of forking off an EAP investigation on adding authentication to IKEv2, we have enough problem with getting the 5 or so we have to work together. Pasi: It seems the motivation is that this IKEv2 feature is not only used for legacy-EAP. Darryl: There should be a requirements doc. Jari: As the draft is short, it does not make sense to have a separate requirements document. Work is grown out of discussion in IPsec mailing list. It is motivated by 3GPP work, as there mutually authenticating EAP methods are already in place. 10. Further announcements: 802.1X/EAP ad-hoc interop test (Karen O'Donoghue). - Planned April 4-7, 2004 in Las Vegas. - Follow-on to similar event last year. Announcement on Free Radius (Michael Haberler): - EAP-SIM implementation status (Internet foundation Austria) - Available as module of freeradius in the CVS tree on www.freeradius.org - Done by Michael Richardson. Part of openlx project. - EAP-SIM supplicant: online on www.open1x.org - Some interop tests done with Cisco, Nokia and others. In the pipe: Cisco windows dll. - Next step is to integrate (U)SIM cards, implement EAP-AKA. Implement RFC3310 http/digest, www.iptel.org 11. Meeting concluded _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Mar 24 11:38:41 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05248 for ; Wed, 24 Mar 2004 11:38:41 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 118F91FF67; Wed, 24 Mar 2004 11:27:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8BB5920215; Wed, 24 Mar 2004 11:27:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8676620507 for ; Wed, 24 Mar 2004 11:26:18 -0500 (EST) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 975041FF67 for ; Wed, 24 Mar 2004 11:26:16 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i2OGkDB27498 for ; Wed, 24 Mar 2004 08:46:13 -0800 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] Completion of EAP WG last call on draft-ietf-eap-statemachine-02 Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 24 Mar 2004 08:46:12 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) EAP WG last call on draft-ietf-eap-statemachine-02.txt has completed. Two comments were received, and are available for inspection here: http://www.drizzle.com/~aboba/EAP/eapissues.html As soon as these comments are incorporated into an -03 version (including addressing RFC-Editor requests relating to the state machine tables in the text version), the document will be forwarded to the IESG for IETF last call, IESG review and publication as an Informational RFC. To assure review by IEEE 802, the IETF Last Call notice will be posted to the IEEE 802.1 reflector. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Mar 24 11:42:38 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05481 for ; Wed, 24 Mar 2004 11:42:38 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 60E63205AD; Wed, 24 Mar 2004 11:31:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8C93220215; Wed, 24 Mar 2004 11:31:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2D1F620507 for ; Wed, 24 Mar 2004 11:30:19 -0500 (EST) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 4EAA71FF67 for ; Wed, 24 Mar 2004 11:30:17 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i2OGoEg27722 for ; Wed, 24 Mar 2004 08:50:14 -0800 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: IETF last call on draft-walker-ieee802-req-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, 24 Mar 2004 08:50:14 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a reminder that IETF last call on draft-walker-ieee802-req-00.txt will complete on March 28, 2004. The IETF Last Call notice is available here: http://www1.ietf.org/mail-archive/ietf-announce/Current/msg29002.html Please send comments relating to this document to the EAP WG mailing list (eap@frascone.com) in the format specified in the EAP issues list: http://www.drizzle.com/~aboba/EAP/eapissues.html _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Mar 24 11:54:43 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06049 for ; Wed, 24 Mar 2004 11:54:43 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B053620572; Wed, 24 Mar 2004 11:43:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9AAD61FF81; Wed, 24 Mar 2004 11:43:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E44AD20507 for ; Wed, 24 Mar 2004 11:42:41 -0500 (EST) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id 1348B1FF81 for ; Wed, 24 Mar 2004 11:42:39 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id i2OGs7JV001477; Wed, 24 Mar 2004 11:54:07 -0500 (EST) From: Nick Petroni To: Bernard Aboba Cc: Subject: Re: [eap] Completion of EAP WG last call on draft-ietf-eap-statemachine-02 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 24 Mar 2004 11:54:07 -0500 (EST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) AFAIK, these changes have been incorporated in -03b, available here: http://www.cs.umd.edu/~npetroni/EAP/ I would like to get some feedback on -03b (just to make sure I didn't screw something up), but I will submit -03b as -03 close of business friday if I don't receive such feedback (or earlier upon the request of the group). Note particularly Appendix A now contains the text versions of the state machine tables. Thanks, nick Nick L. Petroni, Jr. Graduate Student, Computer Science Maryland Information Systems Security Lab University of Maryland http://www.cs.umd.edu/~npetroni On Wed, 24 Mar 2004, Bernard Aboba wrote: > EAP WG last call on draft-ietf-eap-statemachine-02.txt has completed. Two > comments were received, and are available for inspection here: > > http://www.drizzle.com/~aboba/EAP/eapissues.html > > As soon as these comments are incorporated into an -03 version (including > addressing RFC-Editor requests relating to the state machine tables in the > text version), the document will be forwarded to the IESG for > IETF last call, IESG review and publication as an Informational RFC. > > To assure review by IEEE 802, the IETF Last Call notice will be posted to > the IEEE 802.1 reflector. > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Mar 25 08:00:51 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18870 for ; Thu, 25 Mar 2004 08:00:50 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C809E1FC70; Thu, 25 Mar 2004 07:49:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2AF1D202D5; Thu, 25 Mar 2004 07:49:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D2CCC202D5 for ; Thu, 25 Mar 2004 07:48:49 -0500 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by mail.frascone.com (Postfix) with ESMTP id 9D03E1FC70 for ; Thu, 25 Mar 2004 07:48:47 -0500 (EST) 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 i2PD0II09563 for ; Thu, 25 Mar 2004 15:00:18 +0200 (EET) X-Scanned: Thu, 25 Mar 2004 14:59:24 +0200 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i2PCxOwA027296 for ; Thu, 25 Mar 2004 14:59:24 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00cyUpCj; Thu, 25 Mar 2004 14:59:22 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2PCxMF10977 for ; Thu, 25 Mar 2004 14:59:22 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 25 Mar 2004 14:59:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <052E0C61B69C3741AFA5FE88ACC775A61223A8@esebe023.ntc.nokia.com> Thread-Topic: Comments about draft-walker-ieee802-req-00 Thread-Index: AcQSaPfOK++VSRF1SQOAR7XzpeANHA== From: To: X-OriginalArrivalTime: 25 Mar 2004 12:59:13.0807 (UTC) FILETIME=[F915C9F0:01C41268] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Comments about draft-walker-ieee802-req-00 Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-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, 25 Mar 2004 14:59:11 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Submitter name: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: 25.3.2004 Reference:=20 Document: draft-walker-ieee802-req-00 Comment type: T/E Priority: S/1 Section: various Rationale/Explanation of issue: 1) Security considerations The draft does not have a "security considerations" section. =20 I think this section should provide at least a brief rationale about why the requirements are what they are. In some cases, the reasons are fairly obvious; in other cases, it is not immediately clear why a system not meeting that requirement would be unacceptable. 2) Conditional compliance Section 1.1 defines the terms "unconditionally compliant" and "conditionally compliant". Since the draft includes only one SHOULD level requirement (about fragmentation), I do not think this distinction adds any value to the document. 3) Synchronization of state I agree with Joe Salowey's comment in issue 224 that protected result indications and synchronization of state don't have much to do with each other. Joe's proposed text looks basically OK, but I am not sure whether it is actually necessary. Much of it just attempts to capture what being a "not totally flawed" authentication method means. I also agree with 2284bis's conclusion that protected result indications do not add any significant value in 802.11 use, so IMHO they should not be required. 4) Cryptographic bindings A strict reading of the draft would suggest that, for instance, OTP-over-PEAPv1 would not be acceptable while OTP-over-PEAPv2 would be. This is because PEAPv1 does not have "cryptographic=20 bindings". However, both cases are actually equally secure since=20 OTP does not generate a key: so actually PEAPv2 does not have=20 "cryptographic binding" in this case either... IMHO this case does not have so severe security problems that it should be prohibited. As noted in 2284bis section 7.4, there are other valid approaches that prevent the MitM attack, including policies about when to use which methods. Also, 2284bis already requires that "tunneled methods MUST support protection against man-in-the-middle attacks" (section 2.1), presumably meaning that policy is one possible way to support this. How about "When a tunnel method is used with "inner" methods that support key derivation, the tunnel method SHOULD support the "cryptographic binding" claim."? Or perhaps no text is required here since 2284bis already has the MUST requirement relating to this? 5) Dictionary attacks There are good reasons to prohibit methods vulnerable to dictionary attacks, but IMHO those same reasons apply=20 equally to 802.11i PSK mode. Perhaps this apparent contradiction should be somehow justified, or maybe changed to a "SHOULD NOT"? Best regards, Pasi _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From bgqhk@agfa.com.pl Thu Mar 25 17:52:28 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29523 for ; Thu, 25 Mar 2004 17:52:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6diA-0001Z4-00 for eap-archive@ietf.org; Thu, 25 Mar 2004 17:52:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6dhJ-0001XN-00 for eap-archive@ietf.org; Thu, 25 Mar 2004 17:51:38 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B6dgX-0001V5-00 for eap-archive@ietf.org; Thu, 25 Mar 2004 17:50:49 -0500 Received: from user-10cm5be.cable.mindspring.com ([64.203.21.110]) by mx2.foretec.com with smtp (Exim 4.24) id 1B6dgW-0007Xg-UN for eap-archive@ietf.org; Thu, 25 Mar 2004 17:50:49 -0500 Received: from 46.192.48.32 by 64.203.21.110; Thu, 25 Mar 2004 17:46:48 -0500 Message-ID: From: "Lemuel Benitez" Reply-To: "Lemuel Benitez" To: eap-archive@ietf.org Subject: diplomas for sale from accredited universities Date: Thu, 25 Mar 2004 20:50:48 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--0135601906857059" X-Priority: 3 X-IP: 32.43.84.77 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=7.4 required=5.0 tests=BIZ_TLD,HTML_70_80, HTML_FONT_BIG,HTML_MESSAGE,HTML_TAG_EXISTS_TBODY,LINES_OF_YELLING, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,OBFUSCATING_COMMENT, PRIORITY_NO_NAME autolearn=no version=2.60 X-Spam-Report: * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 HTML_70_80 BODY: Message is 70% to 80% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 4.3 OBFUSCATING_COMMENT HTML comments which obfuscate text ----0135601906857059 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable GET

    GET YOUR UNIVERSITY DIPLOMA

    Do yo= u want a prosperou= s future, increased earning power
    more money and the respect of all?

    Ca<= !b>ll this number: 

    1-720-834-2989

    (24 hours)

     

  • There are no required tests, classes, books, or= interviews!
     
  • Get a Bachelors, Ma<= !d>sters, MBA, and Doctorate (PhD) diploma!
     
  • Receive the benefits and admiration that comes= with a diploma!
     
  • No one is turned= down!

     

    Call Today

    =

    1-720-834-2989

     (7 days a week)=

    Confidentiality a<= !r>ssured!
     

    W= e are located in USA  international= callers are very welcome

    • ----0135601906857059-- From JJEDLWJXFNQATN@nash.co.jp Thu Mar 25 18:24:27 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02440 for ; Thu, 25 Mar 2004 18:24:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6eD6-0003kP-00 for eap-archive@ietf.org; Thu, 25 Mar 2004 18:24:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6eCA-0003go-00 for eap-archive@ietf.org; Thu, 25 Mar 2004 18:23:31 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B6eBF-0003dn-00 for eap-archive@ietf.org; Thu, 25 Mar 2004 18:22:33 -0500 Received: from h24-78-63-15.tb.shawcable.net ([24.78.63.15]) by mx2.foretec.com with smtp (Exim 4.24) id 1B6eBF-0008B4-CH for eap-archive@ietf.org; Thu, 25 Mar 2004 18:22:34 -0500 Received: from 180.166.32.235 by web589.mail.yahoo.com; Fri, 26 Mar 2004 01:22:30 +0200 Message-ID: From: "Mae York" To: eap-archive@ietf.org Subject: Make profits from other people's businesses Date: Thu, 25 Mar 2004 17:13:30 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--870499390380989" X-CS-IP: 196.108.241.28 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.2 required=5.0 tests=BIZ_TLD,HTML_50_60, HTML_MESSAGE,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----870499390380989 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable 58.18.200.28

     

    With my proven strategies you'll make more money online than most other web = sites do and you won't even need to have a website!

    I don't want more emails

    ----870499390380989-- From ZRWISR@cti.gr Sun Mar 28 01:50:28 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20080 for ; Sun, 28 Mar 2004 01:50:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7U7o-00079L-00 for eap-archive@ietf.org; Sun, 28 Mar 2004 01:50:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7U6p-00073a-00 for eap-archive@ietf.org; Sun, 28 Mar 2004 01:49:28 -0500 Received: from alb-24-29-74-198.nycap.rr.com ([24.29.74.198]) by ietf-mx with smtp (Exim 4.12) id 1B7U6P-0006xH-00 for eap-archive@ietf.org; Sun, 28 Mar 2004 01:49:01 -0500 Received: from 204.172.60.129 by 24.29.74.198; Sun, 28 Mar 2004 12:46:01 +0600 Message-ID: From: "Ira Crane" Reply-To: "Ira Crane" To: eap-archive@ietf.org Subject: A real business online Date: Sun, 28 Mar 2004 05:40:01 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--3949132901946837587" X-Originating-IP: 132.151.6.1 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.5 required=5.0 tests=BIZ_TLD,HTML_40_50, HTML_MESSAGE,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----3949132901946837587 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable a 68.137.13.227

     

    Affiliate programs were never this easy in the past. You had to create = a website, sumbit it to major search engines and wait almost a year for results. Wi= th my program you won't have to worry about any of this.

    no more emails please

    ----3949132901946837587-- From emenews@mail.com Mon Mar 29 12:34:37 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13795 for ; Mon, 29 Mar 2004 12:34:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B80el-00068V-00 for eap-archive@ietf.org; Mon, 29 Mar 2004 12:34:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B80dq-0005xh-00 for eap-archive@ietf.org; Mon, 29 Mar 2004 12:33:43 -0500 Received: from proxy.gascom.ru ([217.17.160.5] helo=ietf.org) by ietf-mx with smtp (Exim 4.12) id 1B80cw-0005ep-00; Mon, 29 Mar 2004 12:32:48 -0500 From: "Atualidade Brasileira . sua" To: eap-archive@ietf.org Subject: "Trabalho escravo": novo instrumento da demagogia? . zsx User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Mon, 29 Mar 2004 12:32:48 -0500 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=8.8 required=5.0 tests=HTML_40_50,HTML_FONT_BIG, HTML_MESSAGE,MAILTO_SUBJ_REMOVE,MAILTO_TO_REMOVE,MAILTO_TO_SPAM_ADDR, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MSGID_FROM_MTA_SHORT, REMOVE_REMOVAL_2WORD,SUBJ_HAS_SPACES,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 X-Spam-Report: * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.5 REMOVE_REMOVAL_2WORD BODY: List removal information * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.3 MAILTO_SUBJ_REMOVE BODY: mailto URI includes removal text * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email * 0.0 MAILTO_TO_REMOVE URI: Includes a 'remove' email address * 0.2 SUBJ_HAS_UNIQ_ID Subject contains a unique ID * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay

    (ref.: cur) (utilize os links instantâneos para contacto, recebimento de informações, remoção ou subscrição)

     "Trabalho escravo": instrumento da demagogia contra a propriedade?

    A Proposta de Emenda Constitucional (PEC) 438/01 prevê a expropriação sumária de fazendas; amanhã, com a brecha constitucional aberta, chegará a hora da expropriação sumária de indústrias e até mesmo de lares, a partir de qualquer denúncia sobre "trabalho escravo"

    Caro amigo

    * Um novo golpe contra a propriedade privada paira sobre nossas cabeças e poderá ocorrer através de uma reforma à Constituição, com a introdução da ambígua expressão "trabalho escravo".

    * A Comissão de Constituição e Justiça da Câmara aprovou a admissibilidade da Proposta de Emenda Constitucional (PEC) 438/01, do Senado, que prevê a desapropriação sumária (sem indenização) da terra onde for constatada a prática do chamado "trabalho escravo" (clique aqui para maiores informações: MaisInformaçãoEmendaConstitucional).

    * Para acelerar os debates sobre o "trabalho escravo", o presidente da Câmara instalou Comissão Especial, que terá prazo de 40 sessões para votar a matéria antes de seguir para o Plenário. Os trabalhos da Comissão já começaram em março.

    * A simpática bandeira do combate ao "trabalho escravo" será utilizada demagogicamente para expropriações sumárias de fazendas para fins de Reforma Agrária.

    * A emenda constitucional poderá criar tal ambigüidade em torno do direito de propriedade, que ficará aberta mais uma fonte de conflitos no meio rural. O MST não espera outra coisa!

    * Hoje, a proposta é a expropriação sumária de fazendas. Amanhã, já com a brecha constitucional aberta, chegará a hora da expropriação sumária de indústrias e até mesmo de lares, a partir de uma denúncia sobre "trabalho escravo".

    * Levantar este tema "politicamente incorreto" não é agradável. Mas é o próprio futuro do Brasil que está em jogo.

    * Caro amigo, coloco-me à sua disposição,sem nenhum ônus de sua parte,um "pacote" de informações para que V.forme uma opinião objetiva a respeito do tema. E, eventualmente, se dirija de maneira respeitosa, mas firme, aos ilustres deputados membros da Comissão que trata do assunto, através de um link que lhe proporciono a seguir (para acessá-lo, basta clicar em: LinkParaEnviarMensagemADeputados).

    * Na verdade, o que o Brasil precisa é de uma reforma de suas leis trabalhistas, reforma que venha atender as múltiplas atividades econômicas, sobretudo às do campo, com suas peculiaridades; leis que facilitem a geração de empregos e a legalização de milhões de trabalhadores informais.

    * Gostaria, se possível, ouvir sugestões, receber ponderações e mesmo críticas de sua parte a respeito deste momentoso assunto. Temo ter interpretado mal informações da imprensa e do âmbito legislativo, áreas nas quais trabalho como jornalista há anos. Estaria sendo exagerado ou pessimista?

    * Finalmente, declaro que não possuo um palmo de terra e que faço esta divulgação exercendo meu direito e minha obrigação de informar, sem qualquer vantagem pessoal.

    Mais uma vez, ao seu inteiro dispor para qualquer esclarecimento.

    Atenciosamente,

    Nelson Barretto / Jornalista

    P.S.

    * No ano passado, após percorrer 20 mil quilômetros pelo Brasil e visitar 60 "assentamentos" de Reforma Agrária, inclusive aqueles tidos pelo governo como "modelos", constatei o desastre e o fracasso da Reforma Agrária que vem sendo feita. Com o material colhido, publiquei o livro "Reforma Agrária: o mito e a realidade", já com 4 edições. Os fatos ali narrados não foram desmentidos pelo INCRA, nem pelo MST nem ainda pelo ministério da Reforma Agrária.

    * Como gostaria, desta vez, de ver minhas apreensões dissipadas sobre a reforma constitucional que se prepara! O combate ao "trabalho escravo" é bandeira mais que simpática. Mas, ao meu ver, não nas mãos da demagogia agro-reformista.

    LINKS DISPONÍVEIS:

    Atualidade:Concordo-VisãoObjetiva

    Atualidade:EmTermos-VisãoExagerada

    Atualidade:Discordo-VisãoTendenciosa

    Atualidade:DesejoReceberGratuitamenteMaisInformações

    Atualidade:DesejoContatoTelefonico

    LinkParaEnviarMensagemADeputados

    Atualidade:DesejoReceberLivroBarrettoSobreReformaAgrária

    Atualidade:SubscreverAmigos

    Atualidade:RemoverImediatamente

    A retransmissão desta mensagem é de exclusiva responsabilidade de Ferreira-Passos, Atualidade Brasileira (RJ)

     From eap-admin@frascone.com Mon Mar 29 16:23:04 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27230 for ; Mon, 29 Mar 2004 16:23:03 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 17A1B1FF79; Mon, 29 Mar 2004 16:11:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D697120531; Mon, 29 Mar 2004 16:11:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EE45720533 for ; Mon, 29 Mar 2004 16:10:01 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 3370A20531 for ; Mon, 29 Mar 2004 16:10:00 -0500 (EST) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id CD1A7898C3 for ; Tue, 30 Mar 2004 00:21:36 +0300 (EEST) Message-ID: <406892C3.10602@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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Content-Type: multipart/mixed; boundary="------------090303090700090003050509" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] [Fwd: Last Call: 'Internet Key Exchange (IKEv2) Protocol' 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: Tue, 30 Mar 2004 00:18:59 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. --------------090303090700090003050509 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit This document concerns EAP issues as well. Please review and post comments to the IPsec mailing list. --Jari --------------090303090700090003050509 Content-Type: message/rfc822; name="Last Call: 'Internet Key Exchange (IKEv2) Protocol' to Proposed Standard" Content-Disposition: inline; filename="Last Call: 'Internet Key Exchange (IKEv2) Protocol' to Proposed Standard" MIME-Version: 1.0 --------------090303090700090003050509-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Mar 31 02:29:02 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29925 for ; Wed, 31 Mar 2004 02:29:01 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6CA46202C1; Wed, 31 Mar 2004 02:17:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 05D54203B3; Wed, 31 Mar 2004 02:17:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B2031203B3 for ; Wed, 31 Mar 2004 02:16:29 -0500 (EST) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id B139C202C1 for ; Wed, 31 Mar 2004 02:16:27 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i2V7ZuQ03501; Tue, 30 Mar 2004 23:35:57 -0800 From: Bernard Aboba To: eap@frascone.com, STDS-802-11@listserv.ieee.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] IETF Last Call on draft-walker-ieee802-req-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: Tue, 30 Mar 2004 23:35:56 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) draft-walker-ieee802-req-00.txt is a product of the IEEE 802.11i Task Group and was also approved by IEEE 802.11 at the January 2004 Plenary in Vancouver, Canada. In order to encourage review of this document by the IETF, a liaison letter was sent by Stuart Kerry, Chair of IEEE 802.11, to the IESG requesting publication of this document as an Informational RFC. In order to encourage thorough review by the IETF community, the document was sent to IETF Last Call. IETF Last Call on draft-walker-ieee802-req-00.txt has now concluded. 7 comments were received. These correspond to Issues 224, 225, 226, 227, 232, 233, and 234 on the EAP Issues list: http://www.drizzle.com/~aboba/EAP/eapissues.html Since draft-walker-ieee802-req-00.txt is a work item of IEEE 802.11i and not the EAP WG, strictly speaking, the IETF does not exercise change control over this document. Resolution of the IETF Last Call comments is therefore the sole responsibility of IEEE 802.11i and IEEE 802.11 and my understanding is that resolutions will be discussed during the July IEEE 802 Plenary in Portland, OR. However, since it is desirable for this document to be published as an IETF RFC and IETF last call comments need to be addressed in order to accomplish this, in practice the opinions of both IEEE 802.11 and IETF participants need to be taken into account. Given this, here is how I'd like to propose that we proceed to resolve the IETF Last Call comments: a. In my opinion, Issue 224 (State Synchronization) requires substantial discussion both in EAP WG and in IEEE 802.11i before consensus on a proposed resolution can be reached. I am therefore not prepared to make a recommendation at this time, but would like to encourage further discussion within both EAP WG and 802.11i. b. I've gone over Issues 225, 226, 227, 232, 233 and 234, in order to propose potential resolutions. In terms of the process, I would like to encourage review of these proposed resolutions by both IEEE 802.11i and EAP WG participants. In order to enable the discussion to be tracked, I'd like to request that comments contain the Issue # within the subject line, and be CC'd to the EAP WG mailing list at eap@frascone.com. An -01 "strawman" document incorporating the proposed resolutions to these issues issues will be available at: http://www.drizzle.com/~aboba/IEEE/draft-walker-ieee802-req-01.txt. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Mar 31 04:29:50 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08678 for ; Wed, 31 Mar 2004 04:29:50 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A471C2055A; Wed, 31 Mar 2004 04:18:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 14E6C2031E; Wed, 31 Mar 2004 04:18:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 078C92031E for ; Wed, 31 Mar 2004 04:17:07 -0500 (EST) Received: from rsys001a.roke.co.uk (unknown [193.118.192.110]) by mail.frascone.com (Postfix) with ESMTP id 2F1D81FF74 for ; Wed, 31 Mar 2004 04:17:05 -0500 (EST) Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGMVAMD>; Wed, 31 Mar 2004 10:28:25 +0100 Message-ID: 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] 3GPP identifiers in draft-haverinen-pppext-eap-sim-12.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, 31 Mar 2004 10:28:17 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Apologies if this is somewhat off topic. I've been asked to verify whether 3GPP MSISDNs can be supported by the EAP-SIM Authentication method, as this does not appear to be entirely clear from the draft-haverinen-pppext-eap-sim-12.txt document. I see that IMSIs are supported, but could the passed IMSI field be equivalent to the MSISDN of the terminal (UE) ? BTW : I know this has been discussed within 3GPP, but I've not been following that thread, so I apologise if this offends anyone. Kind regards Stephen McCann Siemens Roke Manor United Kingdom _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Mar 31 09:09:59 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23445 for ; Wed, 31 Mar 2004 09:09:58 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id ED6E120576; Wed, 31 Mar 2004 08:58:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 02DBB203C7; Wed, 31 Mar 2004 08:58:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1B98C203C7 for ; Wed, 31 Mar 2004 08:57:58 -0500 (EST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mail.frascone.com (Postfix) with ESMTP id A99721FF91 for ; Wed, 31 Mar 2004 08:57:55 -0500 (EST) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2VE9X809137; Wed, 31 Mar 2004 17:09:33 +0300 (EET DST) X-Scanned: Wed, 31 Mar 2004 17:08:56 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i2VE8uDY022628; Wed, 31 Mar 2004 17:08:56 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00DzyLkv; Wed, 31 Mar 2004 17:07:49 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 i2VE7mF16944; Wed, 31 Mar 2004 17:07:48 +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); Wed, 31 Mar 2004 17:07:03 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 31 Mar 2004 17:07:04 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] 3GPP identifiers in draft-haverinen-pppext-eap-sim-12.txt Message-ID: Thread-Topic: [eap] 3GPP identifiers in draft-haverinen-pppext-eap-sim-12.txt Thread-Index: AcQXA5M+idXG41uUQUq7OQr3HSuKDwAAByKQ From: To: , X-OriginalArrivalTime: 31 Mar 2004 14:07:04.0963 (UTC) FILETIME=[72296530:01C41729] 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, 31 Mar 2004 17:07:02 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hello Stephen, The format of the username portion of the permanent=20 identity is specified in section 4.2.1, and the=20 subsection "Format of the Permanent Username". If the permanent username is based on the IMSI, then the exact format given in the draft must be used, to ensure interoperability. In this case the username must be based on the IMSI rather than on the MSISDN. The same section also specifies: "Alternatively, an=20 implementation MAY choose a permanent username that is not=20 based on the IMSI. In this case the selection of the username,=20 its format, and its processing is out of the scope of this=20 document." So it would be OK to specify separately how to derive the permanent username from the MSISDN. In EAP-SIM terminology, that would be a permanent username that is not based on the IMSI. Obviously, both the peer and the server would have to support=20 this specification in order for them to interoperate. Best regards, Henry > -----Original Message----- > From: eap-admin@frascone.com=20 > [mailto:eap-admin@frascone.com]On Behalf Of > ext McCann, Stephen > Sent: 31 March, 2004 12:28 > To: 'eap@frascone.com' > Subject: [eap] 3GPP identifiers in=20 > draft-haverinen-pppext-eap-sim-12.txt >=20 >=20 >=20 > Apologies if this is somewhat off topic. >=20 > I've been asked to verify whether 3GPP MSISDNs can be supported > by the EAP-SIM Authentication method, as this does not appear > to be entirely clear from the draft-haverinen-pppext-eap-sim-12.txt > document. >=20 > I see that IMSIs are supported, but could the passed IMSI field be > equivalent to the MSISDN of the terminal (UE) ? >=20 > BTW : I know this has been discussed within 3GPP, but I've not been > following that thread, so I apologise if this offends anyone. >=20 > Kind regards >=20 > Stephen McCann > Siemens Roke Manor > United Kingdom > _______________________________________________ > 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 Mar 31 14:29:52 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08366 for ; Wed, 31 Mar 2004 14:29:52 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B511D20583; Wed, 31 Mar 2004 14:18:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5CC5A20586; Wed, 31 Mar 2004 14:18:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8423520587 for ; Wed, 31 Mar 2004 14:17:04 -0500 (EST) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 83C8720586 for ; Wed, 31 Mar 2004 14:17:02 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i2VJaTr16029; Wed, 31 Mar 2004 11:36:29 -0800 From: Bernard Aboba To: eap@frascone.com Cc: iesg-secretary@ietf.org, narten@us.ibm.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] Request to publish draft-ietf-eap-statemachine-03 as an Informational RFC Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 31 Mar 2004 11:36:29 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The EAP WG would like to request that the IESG consider publication of draft-ietf-eap-statemachine-03.txt, .pdf as an Informational RFC. As this document is related to the IEEE 802.1X-REV specification, we would like to request that the document be sent to IETF last call, so that we can request final review by IEEE 802, 3GPP, and 3GPP2. Technical Summary This document describes the state machine for the EAP protocol, defined in RFC 3748. It was developed in concert with RFC 3748 and the IEEE 802.1X-REV specification. The document is being published as an Informational RFC since it provides information useful to EAP and IEEE 802.1X implementers but is not normative. Although it is believed that the EAP state machine is consistent with both RFC 3748 and IEEE 802.1X-REV, if disagreements are found, the standards track specifications are considered definitive. EAP WG last call summary EAP WG last call concluded on draft-ietf-eap-statemachine-02.txt, .pdf on March 18, 2004. Two comments were received, both minor, and were addressed in the -03 version, which was submitted to the IETF archive today. The comments as well as other previously resolved issues are available for inspection here: http://www.drizzle.com/~aboba/EAP/eapissues.html Both chairs (Jari Arkko & Bernard Aboba) have reviewed the document for consistency with the revised EAP specification, RFC 3748. Since work on the document was relatively uncontentious, we believe that the chance of appeal is quite low. The major technical issues encountered since the document became an EAP WG work item have related to the interface of this specification with IEEE 802.1X-REV. This issue was discussed both within EAP WG and IEEE 802.1, and was resolved without changes to the EAP or IEEE 802.1X state machines (by changes to the EAP and IEEE 802.1X-REV specifications). The major editorial issue encountered in the -03 revision related to handling of the rather detailed state machine diagrams within the text version of the document, so that it would meet RFC Editor guidelines. This issue was resolved by the addition of an Appendix providing the state machine in text form. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap

    GET YOUR UNIVERSITY DIPLOMA

    Do yo= u want a prosperou= s future, increased earning power
    more money and the respect of all?

     
  • There are no required tests, classes, books, or= interviews!
     
  • Get a Bachelors, Ma<= !d>sters, MBA, and Doctorate (PhD) diploma!
     
  • Receive the benefits and admiration that comes= with a diploma!
     
  • No one is turned= down!

     

     



    Confidentiality assured!
     

    W= e are located in USA  international= callers are very welcome