From emu-bounces@ietf.org Wed Feb 01 11:02:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4KQy-00088L-3a; Wed, 01 Feb 2006 11:02:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4KQv-00087X-Sl for emu@megatron.ietf.org; Wed, 01 Feb 2006 11:02:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10109 for ; Wed, 1 Feb 2006 11:00:28 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4Kbz-0002X9-JZ for emu@ietf.org; Wed, 01 Feb 2006 11:13:40 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 01 Feb 2006 11:01:56 -0500 X-IronPort-AV: i="4.01,245,1136178000"; d="scan'208"; a="81461277:sNHT29527840" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k11G1f6T016397 for ; Wed, 1 Feb 2006 11:01:54 -0500 (EST) Received: from xmb-rtp-212.amer.cisco.com ([64.102.31.111]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Feb 2006 11:01:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] EMU PSK Method work Item Date: Wed, 1 Feb 2006 11:01:51 -0500 Message-ID: <9958B444368E884DBB215F3FEF36F5B701A6800D@xmb-rtp-212.amer.cisco.com> Thread-Topic: [Emu] EMU PSK Method work Item Thread-Index: AcYlXDoZs2MvzSipTNCJ0jye+pJm3wB6ql2g From: "Hao Zhou \(hzhou\)" To: "Joseph Salowey \(jsalowey\)" , X-OriginalArrivalTime: 01 Feb 2006 16:01:51.0786 (UTC) FILETIME=[D09F30A0:01C62748] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org Joe: I wonder whether we should look at the strong shared secret method alone. It seems we might achieve this goal and the two other work group items, TLS-based EAP method and existing password database support, using a single EAP method, e.g., a TLS based EAP method supporting PSK. This would save us the work of trying to define two or three EAP methods. One thing might help us is to define what exactly is "strong shared secret", "compact", and "simple" in a requirement or problem statement. They might be expressed in turns of desired number of exchanges, computing power, cipher suites limitations, etc. The security requriements are already addressed by RFC 4017. I suggest we do the same for the other two items. Then we can evaluate whether it is feasible to achieve the three goals with a single EAP method and go from there. > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On=20 > Behalf Of Joseph Salowey (jsalowey) > Sent: Monday, January 30, 2006 12:22 AM > To: emu@ietf.org > Subject: [Emu] EMU PSK Method work Item >=20 > The first work item on the EMU charter is to start work on a=20 > shared secret EAP method. The item on the charter is: >=20 > "A mechanism based on strong shared secrets that meets RFC=20 > 3748 and RFC 4017 requirements. This mechanism should strive=20 > to be simple and compact for implementation in resource=20 > constrained environments." >=20 > The emphasis here is to create a simple, secure mechanism to=20 > support pre shared secret keys. Support for optional=20 > enhancements may be considered in the design as long as it=20 > does not bog down the progress of the work item. Current=20 > work in this area which should be considered in the design including: >=20 > EAP-PAX - draft-clancy-eap-pax-06.txt > EAP-PSK - draft-bersani-eap-psk-09.txt > EAP-SAKE - draft-vanderveen-eap-sake-00.txt > EAP-IKEv2 - draft-eronen-ipsec-ikev2-eap-auth-04.txt > TLS-PSK - RFC4279 >=20 > Please send email to the chairs if you are interested in=20 > participating as a contributor on the shared secret method=20 > design team along with a description of your experience. >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Feb 01 12:55:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4MCy-00058O-KF; Wed, 01 Feb 2006 12:55:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4MCw-00052s-Kw for emu@megatron.ietf.org; Wed, 01 Feb 2006 12:55:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18820 for ; Wed, 1 Feb 2006 12:54:13 -0500 (EST) Received: from bay106-f20.bay106.hotmail.com ([65.54.161.30] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4MO5-0006hM-6c for emu@ietf.org; Wed, 01 Feb 2006 13:07:25 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 1 Feb 2006 09:55:39 -0800 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Wed, 01 Feb 2006 17:55:39 GMT X-Originating-IP: [67.182.139.247] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <9958B444368E884DBB215F3FEF36F5B701A6800D@xmb-rtp-212.amer.cisco.com> From: "Bernard Aboba" To: hzhou@cisco.com, jsalowey@cisco.com, emu@ietf.org Subject: RE: [Emu] EMU PSK Method work Item Date: Wed, 01 Feb 2006 09:55:39 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 01 Feb 2006 17:55:39.0547 (UTC) FILETIME=[B648D6B0:01C62758] X-Spam-Score: 0.9 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org It seems we might achieve this goal and the two other work group >items, TLS-based EAP method and existing password database support, >using a single EAP method, e.g., a TLS based EAP method supporting PSK. One of the attractions of PSK is to implement it on an embedded device. So while it is possible to address the PSK work item using a TLS-derived protocol, attempting to glom this onto the EAP-TLS specification is a bad idea. Since EAP-TLS *requires* certificate support, adding PSK on to it would effectively require embedded devices to include certificate support just to support PSK, whether they needed to support certificates or not. This would greatly increase the required footprint. Of course, EMU WG could create a new protocol based on TLS that would *require* PSK support and allow optional certificate support. However, this would not be EAP-TLS but something new. >This would save us the work of trying to define two or three EAP >methods. One thing might help us is to define what exactly is "strong >shared secret", "compact", and "simple" in a requirement or problem >statement. They might be expressed in turns of desired number of >exchanges, computing power, cipher suites limitations, etc. The security >requriements are already addressed by RFC 4017. I suggest we do the same >for the other two items. Then we can evaluate whether it is feasible to >achieve the three goals with a single EAP method and go from there. > > > -----Original Message----- > > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On > > Behalf Of Joseph Salowey (jsalowey) > > Sent: Monday, January 30, 2006 12:22 AM > > To: emu@ietf.org > > Subject: [Emu] EMU PSK Method work Item > > > > The first work item on the EMU charter is to start work on a > > shared secret EAP method. The item on the charter is: > > > > "A mechanism based on strong shared secrets that meets RFC > > 3748 and RFC 4017 requirements. This mechanism should strive > > to be simple and compact for implementation in resource > > constrained environments." > > > > The emphasis here is to create a simple, secure mechanism to > > support pre shared secret keys. Support for optional > > enhancements may be considered in the design as long as it > > does not bog down the progress of the work item. Current > > work in this area which should be considered in the design including: > > > > EAP-PAX - draft-clancy-eap-pax-06.txt > > EAP-PSK - draft-bersani-eap-psk-09.txt > > EAP-SAKE - draft-vanderveen-eap-sake-00.txt > > EAP-IKEv2 - draft-eronen-ipsec-ikev2-eap-auth-04.txt > > TLS-PSK - RFC4279 > > > > Please send email to the chairs if you are interested in > > participating as a contributor on the shared secret method > > design team along with a description of your experience. > > > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www1.ietf.org/mailman/listinfo/emu > > > >_______________________________________________ >Emu mailing list >Emu@ietf.org >https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Feb 01 13:13:05 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4MTZ-0007mz-Aw; Wed, 01 Feb 2006 13:13:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4MTX-0007m0-HK for emu@megatron.ietf.org; Wed, 01 Feb 2006 13:13:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19735 for ; Wed, 1 Feb 2006 13:11:19 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4Mec-0007Bk-UO for emu@ietf.org; Wed, 01 Feb 2006 13:24:31 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 01 Feb 2006 10:12:47 -0800 X-IronPort-AV: i="4.01,245,1136188800"; d="scan'208"; a="1772446384:sNHT32237976" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k11IC0WN012965; Wed, 1 Feb 2006 10:12:45 -0800 (PST) Received: from xmb-rtp-212.amer.cisco.com ([64.102.31.111]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Feb 2006 13:12:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] EMU PSK Method work Item Date: Wed, 1 Feb 2006 13:12:34 -0500 Message-ID: <9958B444368E884DBB215F3FEF36F5B701A680CB@xmb-rtp-212.amer.cisco.com> Thread-Topic: [Emu] EMU PSK Method work Item Thread-Index: AcYnWLg8fOEUOQigRyuB8F6c40zhagAAb3Mw From: "Hao Zhou \(hzhou\)" To: "Bernard Aboba" , "Joseph Salowey \(jsalowey\)" , X-OriginalArrivalTime: 01 Feb 2006 18:12:35.0189 (UTC) FILETIME=[13A78250:01C6275B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org > Of course, EMU WG could create a new protocol based on TLS that would > *require* PSK support and allow optional certificate support.=20 > However, this would not be EAP-TLS but something new. Agreed. That's what I proposed. Notice I wrote TLS based EAP method, not EAP-TLS. Having a requirement statement on the "small footprint" of the PSK is the key to evaluate whether we can do it within a single EAP method or not. > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Wednesday, February 01, 2006 12:56 PM > To: Hao Zhou (hzhou); Joseph Salowey (jsalowey); emu@ietf.org > Subject: RE: [Emu] EMU PSK Method work Item >=20 > It seems we might achieve this goal and the two other work group > >items, TLS-based EAP method and existing password database support,=20 > >using a single EAP method, e.g., a TLS based EAP method=20 > supporting PSK. >=20 > One of the attractions of PSK is to implement it on an=20 > embedded device. So while it is possible to address the PSK=20 > work item using a TLS-derived protocol, attempting to glom=20 > this onto the EAP-TLS specification is a bad idea. Since=20 > EAP-TLS *requires* certificate support, adding PSK on to it=20 > would effectively require embedded devices to include=20 > certificate support just to support PSK, whether they needed=20 > to support certificates or not. =20 > This would greatly increase the required footprint. >=20 > Of course, EMU WG could create a new protocol based on TLS that would > *require* PSK support and allow optional certificate support.=20 > However, this would not be EAP-TLS but something new. >=20 >=20 >=20 > >This would save us the work of trying to define two or three EAP=20 > >methods. One thing might help us is to define what exactly=20 > is "strong=20 > >shared secret", "compact", and "simple" in a requirement or problem=20 > >statement. They might be expressed in turns of desired number of=20 > >exchanges, computing power, cipher suites limitations, etc. The=20 > >security requriements are already addressed by RFC 4017. I=20 > suggest we=20 > >do the same for the other two items. Then we can evaluate=20 > whether it is=20 > >feasible to achieve the three goals with a single EAP method=20 > and go from there. > > > > > -----Original Message----- > > > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org]=20 > On Behalf=20 > > > Of Joseph Salowey (jsalowey) > > > Sent: Monday, January 30, 2006 12:22 AM > > > To: emu@ietf.org > > > Subject: [Emu] EMU PSK Method work Item > > > > > > The first work item on the EMU charter is to start work=20 > on a shared=20 > > > secret EAP method. The item on the charter is: > > > > > > "A mechanism based on strong shared secrets that meets RFC > > > 3748 and RFC 4017 requirements. This mechanism should=20 > strive to be=20 > > > simple and compact for implementation in resource constrained=20 > > > environments." > > > > > > The emphasis here is to create a simple, secure mechanism=20 > to support=20 > > > pre shared secret keys. Support for optional enhancements may be=20 > > > considered in the design as long as it does not bog down the=20 > > > progress of the work item. Current work in this area=20 > which should=20 > > > be considered in the design including: > > > > > > EAP-PAX - draft-clancy-eap-pax-06.txt EAP-PSK -=20 > > > draft-bersani-eap-psk-09.txt EAP-SAKE -=20 > > > draft-vanderveen-eap-sake-00.txt > > > EAP-IKEv2 - draft-eronen-ipsec-ikev2-eap-auth-04.txt > > > TLS-PSK - RFC4279 > > > > > > Please send email to the chairs if you are interested in=20 > > > participating as a contributor on the shared secret method design=20 > > > team along with a description of your experience. > > > > > > _______________________________________________ > > > Emu mailing list > > > Emu@ietf.org > > > https://www1.ietf.org/mailman/listinfo/emu > > > > > > >_______________________________________________ > >Emu mailing list > >Emu@ietf.org > >https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Feb 01 16:18:00 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4PJC-0004n0-SN; Wed, 01 Feb 2006 16:14:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4PJA-0004mQ-Ny for emu@megatron.ietf.org; Wed, 01 Feb 2006 16:14:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09701 for ; Wed, 1 Feb 2006 16:12:55 -0500 (EST) Received: from uproxy.gmail.com ([66.249.92.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4PUH-0007b0-Nl for emu@ietf.org; Wed, 01 Feb 2006 16:26:10 -0500 Received: by uproxy.gmail.com with SMTP id c2so29194ugf for ; Wed, 01 Feb 2006 13:14:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=FqdZdeO/B0ehipmbxLYq4oG8pOXiDKXxAGhNfM/bqBmwVp1is0agRQPagL5XuGJ5f5PX9p8UqDmKp5VLGW56SQ6L07neyy2e3rgmcFT7Fy4f0jug7lxf8ttcNc1tTaJDuFyJqAUOwcacxItLVOb1ItnMOjv+vHxBLiBJNfyk+3Q= Received: by 10.48.225.3 with SMTP id x3mr1740911nfg; Wed, 01 Feb 2006 13:08:19 -0800 (PST) Received: from ?192.168.0.6? ( [213.54.85.73]) by mx.gmail.com with ESMTP id c1sm419615nfe.2006.02.01.13.08.18; Wed, 01 Feb 2006 13:08:19 -0800 (PST) From: Thomas Otto To: emu@ietf.org Subject: Re: [Emu] EMU PSK Method work Item Date: Wed, 1 Feb 2006 22:08:41 +0100 User-Agent: KMail/1.9.1 References: <9958B444368E884DBB215F3FEF36F5B701A6800D@xmb-rtp-212.amer.cisco.com> In-Reply-To: <9958B444368E884DBB215F3FEF36F5B701A6800D@xmb-rtp-212.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200602012208.42877.thomas.g.otto@googlemail.com> X-Spam-Score: 1.3 (+) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org Am Mittwoch, 1. Februar 2006 17:01 schrieb Hao Zhou (hzhou): > I wonder whether we should look at the strong shared secret method > alone. It seems we might achieve this goal and the two other work group > items, TLS-based EAP method and existing password database support, > using a single EAP method, e.g., a TLS based EAP method supporting PSK. > This would save us the work of trying to define two or three EAP > methods. One thing might help us is to define what exactly is "strong > shared secret", "compact", and "simple" in a requirement or problem > statement. They might be expressed in turns of desired number of > exchanges, computing power, cipher suites limitations, etc. The security > requriements are already addressed by RFC 4017. I do not think that the security requirements of RFC 4017 are comprehensive. We should re-think about the requirements. What about, for instance, * strong identity protection? * denial-of-service resistance? * non-repudiation? They are not covered by RFC 4017, but seem to be worth to be taken into account. My advise is to define a requirement catalogue apart from RFC 4017. Therefore, the current EAP deployments should be analyzed (e.g. EAP is used in 802.11, 802.16, IKEv2, TLS, 3G networks...) and the specific characteristics of these environments elaborated. Second, intended / future application scenarios should be taken into account (mesh networks, p2p, ...). And: We should define a metric, that is, each requirement should get a weight factor. One example: The assertion: "avoid TLS and public key cryptography with regard to shared secret methods, because public key cryptography is too expensive. There are a lot of ways to make TLS lightweight, e.g. by exploting the session resumption mode, or by using pre-shared key ciphersuites, or by variing the cryptographic key strength (e.g. do we really need 3072-modp DH or does it suffice to take 2048 bit group). To answer cryptographic-related functions, cryptographicexperts should be asked for their advise. So, the argument to avoid public key cryptography is weak and must be refined. Next to the categorization of mandatory, recommended and optional, one might refine the value of the security requirement by a weight factor. That's for now, bottom line and start point for further discussions: RFC 4017 is not comprehensive. Thomas _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Feb 01 17:54:39 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4Qs3-0006xJ-7S; Wed, 01 Feb 2006 17:54:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4Qs1-0006wQ-Ea for emu@megatron.ietf.org; Wed, 01 Feb 2006 17:54:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23254 for ; Wed, 1 Feb 2006 17:52:49 -0500 (EST) Received: from nproxy.gmail.com ([64.233.182.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4R33-0004M0-Ld for emu@ietf.org; Wed, 01 Feb 2006 18:06:02 -0500 Received: by nproxy.gmail.com with SMTP id y38so13476nfb for ; Wed, 01 Feb 2006 14:54:19 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:resent-from:resent-to:resent-date:resent-message-id:from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=q0oa5AKUmKuC3mHgfKr8ahhQz3sP2PaQKXTCBXnjP5EirmXp8gztSK6Iz5JRjCczmX8tqdNYfvOySXjzNACs+opdPFQ7B7pARUF/LHeqt5K8cNFGKoGEqOSq9kkY3oDHnK3U7OK12j04xwC9YLnTqFVh8+HIdZhBU73MTWRPL5I= Received: by 10.48.244.9 with SMTP id r9mr17707nfh; Wed, 01 Feb 2006 14:54:19 -0800 (PST) Received: from ?192.168.0.6? ( [213.54.85.73]) by mx.gmail.com with ESMTP id i1sm181573nfe.2006.02.01.14.54.17; Wed, 01 Feb 2006 14:54:18 -0800 (PST) Resent-From: Thomas Otto Resent-To: emu@ietf.org Resent-Date: Wed, 1 Feb 2006 23:54:41 +0100 Resent-Message-ID: <200602012354.41782.thomas.g.otto@googlemail.com> From: Thomas Otto To: emu@ietf.org Subject: Re: [Emu] EMU PSK Method work Item Date: Wed, 1 Feb 2006 22:08:41 +0100 User-Agent: KMail/1.9.1 References: <9958B444368E884DBB215F3FEF36F5B701A6800D@xmb-rtp-212.amer.cisco.com> In-Reply-To: <9958B444368E884DBB215F3FEF36F5B701A6800D@xmb-rtp-212.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200602012208.42877.thomas.g.otto@googlemail.com> X-Spam-Score: 1.3 (+) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org Am Mittwoch, 1. Februar 2006 17:01 schrieb Hao Zhou (hzhou): > I wonder whether we should look at the strong shared secret method > alone. It seems we might achieve this goal and the two other work group > items, TLS-based EAP method and existing password database support, > using a single EAP method, e.g., a TLS based EAP method supporting PSK. > This would save us the work of trying to define two or three EAP > methods. One thing might help us is to define what exactly is "strong > shared secret", "compact", and "simple" in a requirement or problem > statement. They might be expressed in turns of desired number of > exchanges, computing power, cipher suites limitations, etc. The security > requriements are already addressed by RFC 4017. I do not think that the security requirements of RFC 4017 are comprehensive. We should re-think about the requirements. What about, for instance, * strong identity protection? * denial-of-service resistance? * non-repudiation? They are not covered by RFC 4017, but seem to be worth to be taken into account. My advise is to define a requirement catalogue apart from RFC 4017. Therefore, the current EAP deployments should be analyzed (e.g. EAP is used in 802.11, 802.16, IKEv2, TLS, 3G networks...) and the specific characteristics of these environments elaborated. Second, intended / future application scenarios should be taken into account (mesh networks, p2p, ...). And: We should define a metric, that is, each requirement should get a weight factor. One example: The assertion: "avoid TLS and public key cryptography with regard to shared secret methods, because public key cryptography is too expensive. There are a lot of ways to make TLS lightweight, e.g. by exploting the session resumption mode, or by using pre-shared key ciphersuites, or by variing the cryptographic key strength (e.g. do we really need 3072-modp DH or does it suffice to take 2048 bit group). To answer cryptographic-related functions, cryptographicexperts should be asked for their advise. So, the argument to avoid public key cryptography is weak and must be refined. Next to the categorization of mandatory, recommended and optional, one might refine the value of the security requirement by a weight factor. That's for now, bottom line and start point for further discussions: RFC 4017 is not comprehensive. Thomas _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Feb 01 18:36:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4RWp-0002iG-VV; Wed, 01 Feb 2006 18:36:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4RWo-0002hc-DR for emu@megatron.ietf.org; Wed, 01 Feb 2006 18:36:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27025 for ; Wed, 1 Feb 2006 18:35:02 -0500 (EST) Received: from bay106-f4.bay106.hotmail.com ([65.54.161.14] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4Rhw-0005r5-4G for emu@ietf.org; Wed, 01 Feb 2006 18:48:17 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 1 Feb 2006 15:36:27 -0800 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Wed, 01 Feb 2006 23:36:27 GMT X-Originating-IP: [67.182.139.247] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <200602012208.42877.thomas.g.otto@googlemail.com> From: "Bernard Aboba" To: thomas.g.otto@googlemail.com, emu@ietf.org Subject: Re: [Emu] EMU PSK Method work Item Date: Wed, 01 Feb 2006 15:36:27 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 01 Feb 2006 23:36:27.0674 (UTC) FILETIME=[525167A0:01C62788] X-Spam-Score: 0.9 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org >the specific characteristics of these environments elaborated. Second, >intended / future >application scenarios should be taken into account (mesh networks, p2p, >...). Thomas is correct that RFC 4017 only expresses requirements for WLAN authentication in IEEE 802.11 infrastructure networks. However, the requirements for usage in other scenarios such as mesh may be different. We have seen interest in use of EAP in mesh network scenarios, but so far it has been difficult to see how existing methods can be applied to those scenarios. For example, TLS is a client/server protocol so that EAP-TLS is also client/server. That means that in a peer to peer situation a node may need two certificates - a TLS client cert and a TLS server certificate. It also must implement both the EAP TLS peer and EAP TLS server roles. That may be more than is reasonable in an embedded device. Other issues arise as well. For example, a method which focuses on verifying the client claim of identity, but does not allow the server to identify itself will not work well in a peer-to-peer environment, since two EAP authentications (one in each direction) would be required. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Feb 02 09:07:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4f7Y-0008RA-4e; Thu, 02 Feb 2006 09:07:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4f6r-0007rS-Ir for emu@megatron.ietf.org; Thu, 02 Feb 2006 09:06:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05479 for ; Thu, 2 Feb 2006 09:05:12 -0500 (EST) Received: from vulcan.rsasecurity.com ([216.162.240.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4f5E-00041Z-RL for emu@ietf.org; Thu, 02 Feb 2006 09:05:13 -0500 Received: from hyperion.na.rsa.net by vulcan.rsasecurity.com via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Thu, 2 Feb 2006 08:53:25 -0500 Received: from sdtihq24.securid.com by hyperion.na.rsa.net with ESMTP id BNL82228; Thu, 2 Feb 2006 08:53:06 -0500 (EST) Received: from rsana-ex-hq1.NA.RSA.NET (e2k.rsa.net [10.100.8.50]) by sdtihq24.securid.com (8.12.10/8.12.9) with ESMTP id k12Dr5Nt008768; Thu, 2 Feb 2006 08:53:06 -0500 (EST) Received: from rsana-ex-sm1.NA.RSA.NET ([10.80.211.17]) by rsana-ex-hq1.NA.RSA.NET with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Feb 2006 08:53:05 -0500 Received: from localhost ([10.133.240.22]) by rsana-ex-sm1.NA.RSA.NET with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Feb 2006 05:53:03 -0800 Date: Thu, 2 Feb 2006 14:53:27 +0100 (W. Europe Standard Time) From: =?iso-8859-1?Q?Magnus_Nystr=F6m?= To: Bernard Aboba Subject: RE: [Emu] EMU PSK Method work Item In-Reply-To: Message-ID: References: X-X-Sender: mnystrom@[10.80.211.17] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 02 Feb 2006 13:53:04.0151 (UTC) FILETIME=[FD016A70:01C627FF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: magnus@rsasecurity.com List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org But could not EAP-TLS be modified/updated to also allow "pure" TLS-PSK, without requiring use of server certificates? AFAICS this would still be TLS, not "TLS-derived" or "based on TLS". -- Magnus On Wed, 1 Feb 2006, Bernard Aboba wrote: >> It seems we might achieve this goal and the two other work group items, >> TLS-based EAP method and existing password database support, using a >> single EAP method, e.g., a TLS based EAP method supporting PSK. > > One of the attractions of PSK is to implement it on an embedded device. > So while it is possible to address the PSK work item using a TLS-derived > protocol, attempting to glom this onto the EAP-TLS specification is a > bad idea. Since EAP-TLS *requires* certificate support, adding PSK on to > it would effectively require embedded devices to include certificate > support just to support PSK, whether they needed to support certificates > or not. This would greatly increase the required footprint. > > Of course, EMU WG could create a new protocol based on TLS that would > *require* PSK support and allow optional certificate support. However, this > would not be EAP-TLS but something new. > > > >> This would save us the work of trying to define two or three EAP >> methods. One thing might help us is to define what exactly is "strong >> shared secret", "compact", and "simple" in a requirement or problem >> statement. They might be expressed in turns of desired number of >> exchanges, computing power, cipher suites limitations, etc. The security >> requriements are already addressed by RFC 4017. I suggest we do the same >> for the other two items. Then we can evaluate whether it is feasible to >> achieve the three goals with a single EAP method and go from there. >> >> > -----Original Message----- >> > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On >> > Behalf Of Joseph Salowey (jsalowey) >> > Sent: Monday, January 30, 2006 12:22 AM >> > To: emu@ietf.org >> > Subject: [Emu] EMU PSK Method work Item >> > >> > The first work item on the EMU charter is to start work on a >> > shared secret EAP method. The item on the charter is: >> > >> > "A mechanism based on strong shared secrets that meets RFC >> > 3748 and RFC 4017 requirements. This mechanism should strive >> > to be simple and compact for implementation in resource >> > constrained environments." >> > >> > The emphasis here is to create a simple, secure mechanism to >> > support pre shared secret keys. Support for optional >> > enhancements may be considered in the design as long as it >> > does not bog down the progress of the work item. Current >> > work in this area which should be considered in the design including: >> > >> > EAP-PAX - draft-clancy-eap-pax-06.txt >> > EAP-PSK - draft-bersani-eap-psk-09.txt >> > EAP-SAKE - draft-vanderveen-eap-sake-00.txt >> > EAP-IKEv2 - draft-eronen-ipsec-ikev2-eap-auth-04.txt >> > TLS-PSK - RFC4279 >> > >> > Please send email to the chairs if you are interested in >> > participating as a contributor on the shared secret method >> > design team along with a description of your experience. >> > >> > _______________________________________________ >> > Emu mailing list >> > Emu@ietf.org >> > https://www1.ietf.org/mailman/listinfo/emu >> > >> >> _______________________________________________ >> Emu mailing list >> Emu@ietf.org >> https://www1.ietf.org/mailman/listinfo/emu > > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Feb 02 11:38:33 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4hTd-0006Ep-1D; Thu, 02 Feb 2006 11:38:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4hTb-0006CD-3b for emu@megatron.ietf.org; Thu, 02 Feb 2006 11:38:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18852 for ; Thu, 2 Feb 2006 11:36:47 -0500 (EST) Received: from bay106-f33.bay106.hotmail.com ([65.54.161.43] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4her-0002ML-Q6 for emu@ietf.org; Thu, 02 Feb 2006 11:50:13 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 2 Feb 2006 08:38:11 -0800 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Thu, 02 Feb 2006 16:38:11 GMT X-Originating-IP: [67.182.139.247] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: magnus@rsasecurity.com Subject: RE: [Emu] EMU PSK Method work Item Date: Thu, 02 Feb 2006 08:38:11 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 02 Feb 2006 16:38:11.0847 (UTC) FILETIME=[0E73D970:01C62817] X-Spam-Score: 0.9 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org >But could not EAP-TLS be modified/updated to also allow "pure" TLS-PSK, >without requiring use of server certificates? AFAICS this would still be >TLS, not "TLS-derived" or "based on TLS". RFC 2716 requires support for certificate authentication. Making this optional would break backward compatibility of a protocol that has been widely deployed. Depending on the behavior of existing implementations it might be possible to add PSK as an optional feature -- but this would not satisfy the needs of embedded device developers, so you'd probably need a separate PSK-only method anyway. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Feb 02 14:03:24 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4jjo-0000Cq-34; Thu, 02 Feb 2006 14:03:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4jjk-0000B9-Jo for emu@megatron.ietf.org; Thu, 02 Feb 2006 14:03:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29812 for ; Thu, 2 Feb 2006 14:01:35 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4jv2-0007Ke-BR for emu@ietf.org; Thu, 02 Feb 2006 14:15:01 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 02 Feb 2006 11:03:01 -0800 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 k12J31jt017815; Thu, 2 Feb 2006 11:03:01 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] EMU PSK Method work Item Date: Thu, 2 Feb 2006 11:09:34 -0800 Message-ID: <7210B31550AC934A8637D6619739CE69068C269A@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: [Emu] EMU PSK Method work Item Thread-Index: AcYoGKP87QKC0RKDShyaNn6AGLpG4gAEhUVQ From: "Salowey, Joe" To: "Bernard Aboba" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org > RFC 2716 requires support for certificate authentication. =20 > Making this=20 > optional would break backward compatibility of a protocol=20 > that has been=20 > widely deployed. Depending on the behavior of existing=20 > implementations it=20 > might be possible to add PSK as an optional feature -- but=20 > this would not=20 > satisfy the needs of embedded device developers, so you'd=20 > probably need a=20 > separate PSK-only method anyway. [Joe] In addition when looking at producing an enhanced EAP-TLS we need to be aware that TLS has its own negotiation of authentication algorithms. Have an additional layer of negotiation behind the EAP method negotiation can be problematic. If a peer negotiates "TLS+" it may be under the impression that it will use PSK while the server may be thinking of certificates. =20 >=20 >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Feb 02 14:34:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4kDs-0005MC-RI; Thu, 02 Feb 2006 14:34:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4kDp-0005L2-TR for emu@megatron.ietf.org; Thu, 02 Feb 2006 14:34:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02430 for ; Thu, 2 Feb 2006 14:32:40 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4kP6-0008Us-3z for emu@ietf.org; Thu, 02 Feb 2006 14:46:06 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 02 Feb 2006 11:34:06 -0800 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 k12JY5jt012336; Thu, 2 Feb 2006 11:34:05 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] EMU PSK Method work Item Date: Thu, 2 Feb 2006 11:40:38 -0800 Message-ID: <7210B31550AC934A8637D6619739CE69068C26BD@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: [Emu] EMU PSK Method work Item Thread-Index: AcYndlSjzKNtSRONQtKoZW87deRG/wAtQPQA From: "Salowey, Joe" To: "Thomas Otto" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org The security requirements in 4017 are not comprehensive, however I don't think the security requirements for PSK need to be comprehensive. I would rather not open up the list of requirements for PSK too broadly. I believe 4017 and 3748 provide a decent set and expanding them would probably run against the goals of "compact" and "simple". If there are additional requirements that are not in 4017 or 3748 that are needed in the PSK mechanism then we need to bring these out now so the design team can consider them. =20 I think the investigation of requirements of for various future and current usages of EAP methods is good, but I think this will be an ongoing process and a full analyisis is not necessary to complete the PSK method work. =20 > -----Original Message----- > From: Thomas Otto [mailto:thomas.g.otto@googlemail.com]=20 > Sent: Wednesday, February 01, 2006 1:09 PM > To: emu@ietf.org > Subject: Re: [Emu] EMU PSK Method work Item >=20 > Am Mittwoch, 1. Februar 2006 17:01 schrieb Hao Zhou (hzhou): >=20 > > I wonder whether we should look at the strong shared secret method > > alone. It seems we might achieve this goal and the two=20 > other work group > > items, TLS-based EAP method and existing password database support, > > using a single EAP method, e.g., a TLS based EAP method=20 > supporting PSK. > > This would save us the work of trying to define two or three EAP > > methods. One thing might help us is to define what exactly=20 > is "strong > > shared secret", "compact", and "simple" in a requirement or problem > > statement. They might be expressed in turns of desired number of > > exchanges, computing power, cipher suites limitations, etc.=20 > The security > > requriements are already addressed by RFC 4017.=20 >=20 > I do not think that the security requirements of RFC 4017 are=20 > comprehensive. > We should re-think about the requirements. What about, for instance,=20 >=20 > * strong identity protection? > * denial-of-service resistance? > * non-repudiation? >=20 > They are not covered by RFC 4017, but seem to be worth to be=20 > taken into > account. >=20 > My advise is to define a requirement catalogue apart from RFC 4017. > Therefore, the current EAP deployments should be analyzed=20 > (e.g. EAP is used > in 802.11, 802.16, IKEv2, TLS, 3G networks...) and the specific=20 > characteristics of these environments elaborated. Second,=20 > intended / future=20 > application scenarios should be taken into account (mesh=20 > networks, p2p, ...).=20 >=20 > And: We should define a metric, that is, each requirement=20 > should get a weight > factor. One example: The assertion: "avoid TLS and public key=20 > cryptography > with regard to shared secret methods, because public key=20 > cryptography is=20 > too expensive.=20 > There are a lot of ways to make TLS lightweight, e.g. by=20 > exploting the session > resumption mode, or by using pre-shared key ciphersuites, or=20 > by variing the=20 > cryptographic key strength (e.g. do we really need 3072-modp=20 > DH or does it > suffice to take 2048 bit group). To answer=20 > cryptographic-related functions,=20 > cryptographicexperts should be asked for their advise. > So, the argument to avoid public key cryptography is weak and=20 > must be refined. > Next to the categorization of mandatory, recommended and=20 > optional, one might > refine the value of the security requirement by a weight factor. >=20 > That's for now, bottom line and start point for further=20 > discussions: RFC 4017 > is not comprehensive. >=20 > Thomas >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sat Feb 04 14:35:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5TBv-0006ou-VV; Sat, 04 Feb 2006 14:35:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5TBv-0006n8-8A for emu@megatron.ietf.org; Sat, 04 Feb 2006 14:35:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01777 for ; Sat, 4 Feb 2006 14:33:47 -0500 (EST) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F5TNk-00025m-Js for emu@ietf.org; Sat, 04 Feb 2006 14:47:41 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 5335AE006A; Sat, 4 Feb 2006 14:35:20 -0500 (EST) To: "Bernard Aboba" Subject: Re: [Emu] EMU PSK Method work Item References: From: Sam Hartman Date: Sat, 04 Feb 2006 14:35:20 -0500 In-Reply-To: (Bernard Aboba's message of "Thu, 02 Feb 2006 08:38:11 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org >>>>> "Bernard" == Bernard Aboba writes: >> But could not EAP-TLS be modified/updated to also allow "pure" >> TLS-PSK, without requiring use of server certificates? AFAICS >> this would still be TLS, not "TLS-derived" or "based on TLS". Bernard> RFC 2716 requires support for certificate authentication. Bernard> Making this optional would break backward compatibility Bernard> of a protocol that has been widely deployed. Depending Bernard> on the behavior of existing implementations it might be Bernard> possible to add PSK as an optional feature -- but this Bernard> would not satisfy the needs of embedded device Bernard> developers, so you'd probably need a separate PSK-only Bernard> method anyway. Bernard, I think a simpler and more constructive way of saying what you're trying to say here is that "yes, you could do that but you would need a new type code and you would need to separate it from the existing spec." _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sat Feb 04 14:42:05 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5TIL-0001Qn-QO; Sat, 04 Feb 2006 14:42:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5TII-0001Pm-9B for emu@megatron.ietf.org; Sat, 04 Feb 2006 14:42:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02169 for ; Sat, 4 Feb 2006 14:40:12 -0500 (EST) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F5TTy-0002Lt-NI for emu@ietf.org; Sat, 04 Feb 2006 14:54:06 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 26D65E0075; Sat, 4 Feb 2006 14:41:51 -0500 (EST) To: "Salowey, Joe" Subject: Re: [Emu] EMU PSK Method work Item References: <7210B31550AC934A8637D6619739CE69068C26BD@e2k-sea-xch2.sea-alpha.cisco.com> From: Sam Hartman Date: Sat, 04 Feb 2006 14:41:51 -0500 In-Reply-To: <7210B31550AC934A8637D6619739CE69068C26BD@e2k-sea-xch2.sea-alpha.cisco.com> (Joe Salowey's message of "Thu, 2 Feb 2006 11:40:38 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org >>>>> "Salowey," == Salowey, Joe writes: Salowey,> The security requirements in 4017 are not comprehensive, Salowey,> however I don't think the security requirements for PSK Salowey,> need to be comprehensive. I would rather not open up Salowey,> the list of requirements for PSK too broadly. I believe Salowey,> 4017 and 3748 provide a decent set and expanding them Salowey,> would probably run against the goals of "compact" and Salowey,> "simple". If there are additional requirements that are Salowey,> not in 4017 or 3748 that are needed in the PSK mechanism Salowey,> then we need to bring these out now so the design team Salowey,> can consider them. Salowey,> I think the investigation of requirements of for various Salowey,> future and current usages of EAP methods is good, but I Salowey,> think this will be an ongoing process and a full Salowey,> analyisis is not necessary to complete the PSK method Salowey,> work. Also, keep in mind that general requirement investigation is outside the charter of this working group. This working group is specifically chartered to meet requirements outlined in RFC 3748 and 4017. Avoiding getting side tracked in a long requirements phase is important if this group is going to be efficient and meet needs for standards-track EAP mechanisms. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sat Feb 04 19:51:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5Y7b-00018Y-TN; Sat, 04 Feb 2006 19:51:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5Y7a-00015s-Be for emu@megatron.ietf.org; Sat, 04 Feb 2006 19:51:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21804 for ; Sat, 4 Feb 2006 19:49:33 -0500 (EST) Received: from bay106-f1.bay106.hotmail.com ([65.54.161.11] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F5YJN-00063s-8E for emu@ietf.org; Sat, 04 Feb 2006 20:03:30 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 4 Feb 2006 16:51:02 -0800 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Sun, 05 Feb 2006 00:51:01 GMT X-Originating-IP: [71.37.13.64] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: emu@ietf.org Subject: Re: [Emu] EMU PSK Method work Item Date: Sat, 04 Feb 2006 16:51:01 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 05 Feb 2006 00:51:02.0071 (UTC) FILETIME=[3C817470:01C629EE] X-Spam-Score: 0.8 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org > >> But could not EAP-TLS be modified/updated to also allow "pure" > >> TLS-PSK, without requiring use of server certificates? AFAICS > >> this would still be TLS, not "TLS-derived" or "based on TLS". > >Bernard, I think a simpler and more constructive way of saying what >you're trying to say here is that "yes, you could do that but you >would need a new type code and you would need to separate it from the >existing spec." An EAP method with a new type code that is separated from the existing spec would not be EAP-TLS. It would be a new protocol. So as to avoid confusion, it would be best to use a different name, such as "EAP-TLS-PSK". _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Feb 07 08:34:59 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Szi-00043q-9a; Tue, 07 Feb 2006 08:34:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Szg-00040v-LR for emu@megatron.ietf.org; Tue, 07 Feb 2006 08:34:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25535 for ; Tue, 7 Feb 2006 08:33:11 -0500 (EST) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6TBz-0008Qa-Ei for emu@ietf.org; Tue, 07 Feb 2006 08:47:40 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id C0B8E8991B; Tue, 7 Feb 2006 15:34:34 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 8373F89919; Tue, 7 Feb 2006 15:34:34 +0200 (EET) Message-ID: <43E8A202.1030804@piuha.net> Date: Tue, 07 Feb 2006 15:34:58 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Salowey, Joe" Subject: Re: [Emu] EMU PSK Method work Item References: <7210B31550AC934A8637D6619739CE69068C26BD@e2k-sea-xch2.sea-alpha.cisco.com> In-Reply-To: <7210B31550AC934A8637D6619739CE69068C26BD@e2k-sea-xch2.sea-alpha.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org Salowey, Joe wrote: >The security requirements in 4017 are not comprehensive, however I don't >think the security requirements for PSK need to be comprehensive. I >would rather not open up the list of requirements for PSK too broadly. I >believe 4017 and 3748 provide a decent set and expanding them would >probably run against the goals of "compact" and "simple". If there are >additional requirements that are not in 4017 or 3748 that are needed in >the PSK mechanism then we need to bring these out now so the design team >can consider them. > >I think the investigation of requirements of for various future and >current usages of EAP methods is good, but I think this will be an >ongoing process and a full analyisis is not necessary to complete the >PSK method work. > > I am also afraid of a lengthy requirements collection phase. Focusing on an existing and practical use case is possible via RFC 4017. We should do that. --Jari _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Feb 07 08:34:59 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Szj-00044g-EI; Tue, 07 Feb 2006 08:34:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Szg-00041E-O9 for emu@megatron.ietf.org; Tue, 07 Feb 2006 08:34:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25534 for ; Tue, 7 Feb 2006 08:33:10 -0500 (EST) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6TBz-0008Qh-Ee for emu@ietf.org; Tue, 07 Feb 2006 08:47:40 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D663E8991D; Tue, 7 Feb 2006 15:34:38 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 9E8D989919; Tue, 7 Feb 2006 15:34:38 +0200 (EET) Message-ID: <43E8A206.9090002@piuha.net> Date: Tue, 07 Feb 2006 15:35:02 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Subject: Re: [Emu] EMU PSK Method work Item References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org Bernard Aboba wrote: > > An EAP method with a new type code that is separated from the existing > spec would not be EAP-TLS. It would be a new protocol. So as to > avoid confusion, it would be best to use a different name, such as > "EAP-TLS-PSK". Right. --Jari _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Feb 17 12:44:00 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA9eC-0001K7-CS; Fri, 17 Feb 2006 12:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA9eA-0001Jj-Ni for emu@megatron.ietf.org; Fri, 17 Feb 2006 12:43:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15663 for ; Fri, 17 Feb 2006 12:42:11 -0500 (EST) Received: from bay106-f31.bay106.hotmail.com ([65.54.161.41] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FA9sa-0007BE-Vl for emu@ietf.org; Fri, 17 Feb 2006 12:58:56 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 17 Feb 2006 09:43:45 -0800 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Fri, 17 Feb 2006 17:43:44 GMT X-Originating-IP: [67.182.139.247] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: emu@ietf.org Date: Fri, 17 Feb 2006 09:43:44 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 17 Feb 2006 17:43:45.0565 (UTC) FILETIME=[B353D4D0:01C633E9] X-Spam-Score: 0.9 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Emu] RFC 2716: request for implementations X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org We've made an initial start on RFC 2716bis which should be showing up on the archive soon: http://www.ietf.org/internet-drafts/draft-simon-emu-rfc2716bis-00.txt This first draft mostly focusses on cleaning up "PPP"isms, updating references and examples, etc. Next step is to identify EAP TLS implementations and interoperability issues encountered in bakeoffs and in customer deployments. So if you have implemented EAP TLS and encountered some problems, or if there are sections that didn't make sense to you, it would be helpful to post these to the list, along with text changes that might clarify the problem. The biggest issue that has come up in emails I have received over the years relates to certificate usage. I am curious what people think we should be doing in the document in this regard. For example, I'm curious as to whether any of the EAP-TLS implementers are also planning to implement RFC 4334, and if not, whether there might be some interoperability impact on your existing implementation. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Feb 20 03:17:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB6EF-00005y-1O; Mon, 20 Feb 2006 03:17:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB6ED-00005t-Ux for emu@ietf.org; Mon, 20 Feb 2006 03:17:05 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FB6EA-0006Cs-LF for emu@ietf.org; Mon, 20 Feb 2006 03:17:05 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 565998993C for ; Mon, 20 Feb 2006 10:17:01 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 1C10089940 for ; Mon, 20 Feb 2006 10:17:01 +0200 (EET) Message-ID: <43F97B11.5060800@piuha.net> Date: Mon, 20 Feb 2006 10:17:21 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: emu@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Emu] FW: EMU WG at IETF-65 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org This is the current EMU WG slot in the agenda for IETF-65: >TUESDAY, March 21, 2006 > ... >1850-1950 Afternoon Session IV >INT l3vpn Layer 3 Virtual Private Networks WG >RAI simple SIP for Instant Messaging and Presence Leveraging Extensions WG >RTG rpsec Routing Protocol Security Requirements WG >TSV dccp Datagram Congestion Control Protocol WG >SEC emu EAP Method Update WG > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Feb 23 07:34:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCFg4-0004ax-PH; Thu, 23 Feb 2006 07:34:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCFg2-0004OF-Os for emu@ietf.org; Thu, 23 Feb 2006 07:34:34 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCFg1-0007B5-AY for emu@ietf.org; Thu, 23 Feb 2006 07:34:34 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B727A89947; Thu, 23 Feb 2006 14:34:31 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 7EC6589946; Thu, 23 Feb 2006 14:34:31 +0200 (EET) Message-ID: <43FDABEA.3080104@piuha.net> Date: Thu, 23 Feb 2006 14:34:50 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Subject: Re: [Emu] RFC 2716: request for implementations References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Looks great, thank you Bernard! Here's a diff between the RFC and your draft for everyone's viewing pleasure: http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=http://www.ietf.org/rfc/rfc2716.txt&url2=http://www.ietf.org/internet-drafts/draft-simon-emu-rfc2716bis-00.txt A couple of quick comments: >5. Security Considerations > This needs more work, to fill in the descriptions required by RFC 3748. > However, in the case where the peer is initiating an intial PPP > s/intial/initial/ >[RFC2246] Dierks, T., Allen, C., "The TLS Protocol Version 1.0", RFC > 2246, November 1998. > Refer to 2246bis instead, as it is already in the RFC editor's queue. But I don't follow TLS WG, I hope there isn't some kind of a hash negotiation change waiting to happen for 2246bis... >[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA > Considerations Section in RFCs", BCP 26, RFC 2434, October > 1998. > This isn't referred to from anywhere. >[DES] National Bureau of Standards, "DES Modes of Operation", FIPS > PUB 81 (December 1980). > > Or this [sigh of relief]. --Jari _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Feb 24 09:14:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCdii-00043I-M3; Fri, 24 Feb 2006 09:14:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCdii-000437-31 for emu@ietf.org; Fri, 24 Feb 2006 09:14:56 -0500 Received: from revol1.enst.fr ([137.194.32.27] helo=smtp2.enst.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCdig-0004Aa-Fp for emu@ietf.org; Fri, 24 Feb 2006 09:14:56 -0500 Received: from localhost (localhost.enst.fr [127.0.0.1]) by smtp2.enst.fr (Postfix) with ESMTP id B7B79164BC9 for ; Fri, 24 Feb 2006 15:14:53 +0100 (CET) Received: from smtp2.enst.fr ([127.0.0.1]) by localhost (revol1.enst.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59127-05 for ; Fri, 24 Feb 2006 15:14:51 +0100 (CET) Received: from infres.enst.fr (infres.enst.fr [137.194.192.1]) by smtp2.enst.fr (Postfix) with ESMTP id 7E3361648EA for ; Fri, 24 Feb 2006 15:14:51 +0100 (CET) Received: from DELL.enst.fr (dhcp164-239.enst.fr [137.194.164.239]) by infres.enst.fr (Postfix) with ESMTP id DDF3213CBB; Fri, 24 Feb 2006 15:14:50 +0100 (MET) Message-Id: <5.2.1.1.0.20060224151355.05360ef0@pop.infres.enst.fr> X-Sender: urien@pop.infres.enst.fr X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 24 Feb 2006 15:14:26 +0100 To: emu@ietf.org From: Pascal Urien Mime-Version: 1.0 X-Virus-Scanned: amavisd-new at enst.fr X-Spam-Score: 0.1 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: Subject: [Emu] draft-urien-eap-smartcard-10.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1618870654==" Errors-To: emu-bounces@ietf.org --===============1618870654== Content-Type: multipart/alternative; boundary="=====================_79303071==.ALT" --=====================_79303071==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Everybody, A new version of the draft draft-urien-eap-smartcard has been posted to the IETF and is available at http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-10.txt In this new version we introduce two new services, the first (Get-Exported-Parameter, section 7.15) is used to collect exported parameters, the second securely computes AMKS keys (section 7.16) (see details below) Best Regards Pascal Urien http://www.infres.enst.fr/~urien/openeapsmartcard/ 7.15 Get-Exported-Parameter Status: Optional. Security: Secure(BEARER) According to [EAP-KEY], EAP methods export a set of parameters that MAY be used by other EAP layers. In this draft, each attribute is identified by an index, and is read thanks to the Get-Exported- Parameter(index) command. Six indexes are defined, that are associated to the following attributes, Index 1: Peer-ID. The peer identity authenticated by the EAP method. Index 2: Server-ID: It is the optional server identity, authenticated by the EAP method. Index 3: Method-ID. EAP method specifications deriving keys MUST specify a temporally unique method identifier known as the Method-ID. Index 4: Session-ID. The Session-ID uniquely identifies an EAP session between an EAP peer (as identified by the Peer-ID) and server (as identified by the Server-ID). Index 5: Key-Lifetime. While EAP itself does not support key lifetime negotiation, it is possible to specify methods that do. Index 6: Channel Bindings. Channel Bindings include lower layer parameters that are verified for consistency between the EAP peer and server. In order to avoid introducing media dependencies, EAP methods that transport Channel Binding data MUST treat this data as opaque octets. 7.16 Get-AMSK According to [RFC 4017] EMSK is an "additional keying material derived between the EAP client and server that is exported by the EAP method. The EMSK is at least 64 octets in length. The EMSK is not shared with the authenticator or any other third party. The EMSK is reserved for future uses that are not yet defined". It has been suggested in [EAP-EXT] to derive Application-specific Master Session Keys (AMSKs)from EMSK. As an illustration AMSK MAY be obtained by a Key Derivation Function (KDF), such as AMSK = KDF(EMSK, label, length) The Get-AMSK(index,label) command is used to compute AMSK key, identified by an index and optionally associated to a label, needed to its calculation. --=====================_79303071==.ALT Content-Type: text/html; charset="us-ascii"  Hi Everybody,

  A new version of the draft  draft-urien-eap-smartcard has been posted to the IETF
  and is available at

  http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-10.txt

 In this new version we introduce two new services, the first (Get-Exported-Parameter, section 7.15)
 is used to collect exported parameters, the second securely computes AMKS keys (section 7.16)
 (see details below)

Best Regards
Pascal Urien
 
http://www.infres.enst.fr/~urien/openeapsmartcard/

  


7.15 Get-Exported-Parameter 
    
   Status: Optional. 
   Security: Secure(BEARER) 
    
   According to [EAP-KEY], EAP methods export a set of parameters that 
   MAY be used by other EAP layers. In this draft, each attribute is 
   identified by an index, and is read thanks to the Get-Exported-
   Parameter(index) command. 
    
   Six indexes are defined, that are associated to the following 
   attributes, 
    
   Index 1: Peer-ID. 
   The peer identity authenticated by the EAP method. 
    
   Index 2: Server-ID:  
   It is the optional server identity, authenticated by the EAP method. 
    
   Index 3: Method-ID. 
   EAP method specifications deriving keys MUST specify a temporally 
   unique method identifier known as the Method-ID. 
    
   Index 4: Session-ID. 
   The Session-ID uniquely identifies an EAP session between an EAP 
   peer (as identified by the Peer-ID) and server (as identified by the 
   Server-ID). 
    
   Index 5: Key-Lifetime. 
   While EAP itself does not support key lifetime negotiation, it is 
   possible to specify methods that do. 
    
   Index 6: Channel Bindings.  
   Channel Bindings include lower layer parameters that are verified 
   for consistency between the EAP peer and server. In order to avoid 
   introducing media dependencies, EAP methods that transport Channel 
   Binding data MUST treat this data as opaque octets. 
  
7.16 Get-AMSK 
    
   According to [RFC 4017] EMSK is an "additional keying material 
   derived between the EAP client and server that is exported by the 
   EAP method. The EMSK is at least 64 octets in length. The EMSK is 
   not shared with the authenticator or any other third party. The EMSK 
   is reserved for future uses that are not yet defined". 
    
   It has been suggested in [EAP-EXT] to derive Application-specific 
   Master Session Keys (AMSKs)from EMSK. As an illustration AMSK MAY be 
   obtained by a Key Derivation Function (KDF), such as 
    
                        AMSK = KDF(EMSK, label, length) 
    
   The Get-AMSK(index,label) command is used to compute AMSK key, 
   identified by an index and optionally associated to a label, needed 
   to its calculation. 








--=====================_79303071==.ALT--



--===============1618870654==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

--===============1618870654==--





From emu-bounces@ietf.org Fri Feb 24 09:37:53 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FCe4v-00033z-Q6; Fri, 24 Feb 2006 09:37:53 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FCe4u-00033m-El
	for emu@ietf.org; Fri, 24 Feb 2006 09:37:52 -0500
Received: from revol2.enst.fr ([137.194.2.14] helo=smtp2.enst.fr)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCe4s-000511-RT
	for emu@ietf.org; Fri, 24 Feb 2006 09:37:52 -0500
Received: from localhost (localhost.enst.fr [127.0.0.1])
	by smtp2.enst.fr (Postfix) with ESMTP id 2D45354D
	for ; Fri, 24 Feb 2006 15:37:50 +0100 (CET)
Received: from smtp2.enst.fr ([127.0.0.1])
	by localhost (revol2.enst.fr [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 41840-01 for ;
	Fri, 24 Feb 2006 15:37:25 +0100 (CET)
Received: from infres.enst.fr (infres.enst.fr [137.194.192.1])
	by smtp2.enst.fr (Postfix) with ESMTP id 1EF29169F
	for ; Fri, 24 Feb 2006 15:37:19 +0100 (CET)
Received: from DELL.enst.fr (dhcp164-239.enst.fr [137.194.164.239])
	by infres.enst.fr (Postfix) with ESMTP
	id 6EA4C13CBB; Fri, 24 Feb 2006 15:37:18 +0100 (MET)
Message-Id: <5.2.1.1.0.20060224153640.039a7ed0@pop.infres.enst.fr>
X-Sender: urien@pop.infres.enst.fr
X-Mailer: QUALCOMM Windows Eudora Version 5.2.1
Date: Fri, 24 Feb 2006 15:36:53 +0100
To: emu@ietf.org
From: Pascal Urien 
Mime-Version: 1.0
X-Virus-Scanned: amavisd-new at enst.fr
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610
Cc: 
Subject: [Emu] draft-urien-eap-smartcard-10.txt
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0489507873=="
Errors-To: emu-bounces@ietf.org

--===============0489507873==
Content-Type: multipart/alternative;
	boundary="=====================_80650589==.ALT"

--=====================_80650589==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

  Hi Everybody,

   A new version of the draft  draft-urien-eap-smartcard has been posted to 
the IETF
   and is available at

   http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-10.txt

  In this new version we introduce two new services, the first 
(Get-Exported-Parameter, section 7.15)
  is used to collect exported parameters, the second securely computes AMKS 
keys (section 7.16)
  (see details below)

Best Regards
Pascal Urien

http://www.infres.enst.fr/~urien/openeapsmartcard/





7.15 Get-Exported-Parameter

    Status: Optional.
    Security: Secure(BEARER)

    According to [EAP-KEY], EAP methods export a set of parameters that
    MAY be used by other EAP layers. In this draft, each attribute is
    identified by an index, and is read thanks to the Get-Exported-
    Parameter(index) command.

    Six indexes are defined, that are associated to the following
    attributes,

    Index 1: Peer-ID.
    The peer identity authenticated by the EAP method.

    Index 2: Server-ID:
    It is the optional server identity, authenticated by the EAP method.

    Index 3: Method-ID.
    EAP method specifications deriving keys MUST specify a temporally
    unique method identifier known as the Method-ID.

    Index 4: Session-ID.
    The Session-ID uniquely identifies an EAP session between an EAP
    peer (as identified by the Peer-ID) and server (as identified by the
    Server-ID).

    Index 5: Key-Lifetime.
    While EAP itself does not support key lifetime negotiation, it is
    possible to specify methods that do.

    Index 6: Channel Bindings.
    Channel Bindings include lower layer parameters that are verified
    for consistency between the EAP peer and server. In order to avoid
    introducing media dependencies, EAP methods that transport Channel
    Binding data MUST treat this data as opaque octets.

7.16 Get-AMSK

    According to [RFC 4017] EMSK is an "additional keying material
    derived between the EAP client and server that is exported by the
    EAP method. The EMSK is at least 64 octets in length. The EMSK is
    not shared with the authenticator or any other third party. The EMSK
    is reserved for future uses that are not yet defined".

    It has been suggested in [EAP-EXT] to derive Application-specific
    Master Session Keys (AMSKs)from EMSK. As an illustration AMSK MAY be
    obtained by a Key Derivation Function (KDF), such as

                         AMSK = KDF(EMSK, label, length)

    The Get-AMSK(index,label) command is used to compute AMSK key,
    identified by an index and optionally associated to a label, needed
    to its calculation.








--=====================_80650589==.ALT
Content-Type: text/html; charset="us-ascii"



 Hi Everybody,


  A new version of the draft  draft-urien-eap-smartcard has
been posted to the IETF

  and is available at


 
http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-10.txt



 In this new version we introduce two new services, the first (Get-Exported-Parameter, section 7.15)

 is used to collect exported parameters, the second securely computes AMKS keys (section 7.16)

 (see details below)


Best Regards

Pascal Urien

  

http://www.infres.enst.fr/~urien/openeapsmartcard/


  






7.15 Get-Exported-Parameter 
    
   Status: Optional. 
   Security: Secure(BEARER) 
    
   According to [EAP-KEY], EAP methods export a set of parameters that 
   MAY be used by other EAP layers. In this draft, each attribute is 
   identified by an index, and is read thanks to the Get-Exported-
   Parameter(index) command. 
    
   Six indexes are defined, that are associated to the following 
   attributes, 
    
   Index 1: Peer-ID. 
   The peer identity authenticated by the EAP method. 
    
   Index 2: Server-ID:  
   It is the optional server identity, authenticated by the EAP method. 
    
   Index 3: Method-ID. 
   EAP method specifications deriving keys MUST specify a temporally 
   unique method identifier known as the Method-ID. 
    
   Index 4: Session-ID. 
   The Session-ID uniquely identifies an EAP session between an EAP 
   peer (as identified by the Peer-ID) and server (as identified by the 
   Server-ID). 
    
   Index 5: Key-Lifetime. 
   While EAP itself does not support key lifetime negotiation, it is 
   possible to specify methods that do. 
    
   Index 6: Channel Bindings.  
   Channel Bindings include lower layer parameters that are verified 
   for consistency between the EAP peer and server. In order to avoid 
   introducing media dependencies, EAP methods that transport Channel 
   Binding data MUST treat this data as opaque octets. 
  
7.16 Get-AMSK 
    
   According to [RFC 4017] EMSK is an "additional keying material 
   derived between the EAP client and server that is exported by the 
   EAP method. The EMSK is at least 64 octets in length. The EMSK is 
   not shared with the authenticator or any other third party. The EMSK 
   is reserved for future uses that are not yet defined". 
    
   It has been suggested in [EAP-EXT] to derive Application-specific 
   Master Session Keys (AMSKs)from EMSK. As an illustration AMSK MAY be 
   obtained by a Key Derivation Function (KDF), such as 
    
                        AMSK = KDF(EMSK, label, length) 
    
   The Get-AMSK(index,label) command is used to compute AMSK key, 
   identified by an index and optionally associated to a label, needed 
   to its calculation. 









--=====================_80650589==.ALT--



--===============0489507873==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

--===============0489507873==--





From emu-bounces@ietf.org Fri Feb 24 18:21:44 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FCmFs-0007R6-Kq; Fri, 24 Feb 2006 18:21:44 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FCmFr-0007Q4-Nv
	for emu@ietf.org; Fri, 24 Feb 2006 18:21:43 -0500
Received: from bay106-f11.bay106.hotmail.com ([65.54.161.21] helo=hotmail.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCmFp-00069y-Bj
	for emu@ietf.org; Fri, 24 Feb 2006 18:21:43 -0500
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	Fri, 24 Feb 2006 15:21:40 -0800
Message-ID: 
Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP;
	Fri, 24 Feb 2006 23:21:37 GMT
X-Originating-IP: [208.54.44.130]
X-Originating-Email: [bernard_aboba@hotmail.com]
X-Sender: bernard_aboba@hotmail.com
In-Reply-To: <43FDABEA.3080104@piuha.net>
From: "Bernard Aboba" 
To: jari.arkko@piuha.net
Bcc: 
Subject: Re: [Emu] RFC 2716: request for implementations
Date: Fri, 24 Feb 2006 15:21:37 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
X-OriginalArrivalTime: 24 Feb 2006 23:21:40.0410 (UTC)
	FILETIME=[10F7E9A0:01C63999]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4
Cc: emu@ietf.org, aboba@internaut.com
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: emu-bounces@ietf.org

>5.  Security Considerations
>
>This needs more work, to fill in the descriptions required by RFC 3748.

Right.  Here are the claims that I think can be made:

      Auth. mechanism:           Certifications
      Ciphersuite negotiation:   Yes
      Mutual authentication:     Yes
      Integrity protection:      Yes
      Replay protection:         Yes
      Confidentiality:           Depends
      Key derivation:            Yes
      Key strength:              (depends on ciphersuite negotiated)
      Dictionary attack prot.:   Yes
      Fast reconnect:            Yes
      Crypt. binding:            N/A
      Session independence:      Yes
      Fragmentation:             Yes
      Channel binding:           No

Most EAP-TLS implementations do not support Privacy, since they send the 
client cert in the clear.  However, in theory privacy support is possible if 
the implementation brings up a protected channel based on server 
authentication, then requests the client cert.  I'm curious if any existing 
implementations support TLS privacy.

In terms of key strength, this depends on the size of the public/private key 
pairs used in the certificate.     As noted in [RFC3766] Section 5, the 
level of attack resistance in bits is related to the
RSA or DH module and DSA subgroup size in bits:

       Attack Resistance  RSA or DH Modulus     DSA subgroup
          (bits)              size (bits)                      size (bits)
        -----------------     -----------------                 ------------
        70                          947                        128
        80                        1228                        145
        90                        1553                        153
        100                       1926                       184
        150                       4575                       279
        200                       8719                       373
        250                     14596                       475

So a 2048-bit RSA key is required to provide 128-bit equivalent strength.  
Typically the default is lower than this (e.g. 128 bits).

A formal analysis of EAP TLS has been done, that I am hoping we can refer to 
for some of the properties:

http://theory.stanford.edu/~changhua/f15-he.pdf
http://www.cis.upenn.edu/~spyce/may05/anupam.pdf

>From my reading of the paper, EAP-TLS is proven secure when utilized with 
802.11, as long as the TLS certificates are not reused for another purpose 
(e.g. private keys are  not shared or same cert used for both EAP and a Web 
server).   This raises some questions about whether certificates used for 
EAP TLS should be restricted, as proposed in this specification:

http://www.watersprings.org/pub/rfc/rfc4334.txt

However, as far as I know, RFC 4334 has not been implemented.

BTW, the major non-editorial changes from RFC 2716bis are the removal of 
several paragraphs:

RFC 2716, Section 3.4:

   Note that since the peer has made a claim of identity in the EAP-
   Response/Identity (MyID) packet, the EAP server SHOULD verify that
   the claimed identity corresponds to the certificate presented by the
   peer.  Typically this will be accomplished either by placing the
   userId within the peer certificate, or by providing a mapping between
   the peer certificate and the userId using a directory service.

Since RFC 3748 indicates that the EAP-Response/Identity is for routing and 
that it need not match the method-specific identities, this paragraph is not 
appropriate.

RFC 2716, Section 3.6:

   In order to ensure agreement between the EAP-TLS ciphersuite
    negotiation and the subsequent ECP negotiation (described in [6]),
    during ECP negotiation the PPP peer MUST offer only the ciphersuite
    negotiated inEAP-TLS.  This ensures that the PPP authenticator MUST
    accept the EAP-TLS negotiated ciphersuite in order for the
    onversation to proceed.  Should the authenticator not accept the
    EAP-TLS negotiated ciphersuite, then the peer MUST send an LCP
    terminate and disconnect.

    Please note that it cannot be assumed that the PPP authenticator and
    EAP server are located on the same machine or that the authenticator
    understands the EAP-TLS conversation that has passed through it. Thus
    if the peer offers a ciphersuite other than the one negotiated in
    EAP-TLS there is no way for the authenticator to know how to respond
    correctly.

As far as I know, implementations of EAP TLS do not utilize TLS ciphersuite 
negotiation for the purpose of negotiating link layer ciphersuites, since 
this would conflict with link layer ciphersuite negotiation (such as the 
4-way handshake in 11i).

RFC 2716 Section 3.5 (relating to key derivation) needs to be revised to use 
more modern terminology (MSK, EMSK, etc.), but hasn't been done yet.



_______________________________________________
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu



From emu-bounces@ietf.org Sat Feb 25 00:15:16 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FCrlz-0000S0-FM; Sat, 25 Feb 2006 00:15:15 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FCrlx-0000RK-IS
	for emu@ietf.org; Sat, 25 Feb 2006 00:15:13 -0500
Received: from p130.piuha.net ([193.234.218.130])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCrlu-0002SL-0n
	for emu@ietf.org; Sat, 25 Feb 2006 00:15:13 -0500
Received: from p130.piuha.net (localhost [127.0.0.1])
	by p130.piuha.net (Postfix) with ESMTP id DF0658994C;
	Sat, 25 Feb 2006 07:15:07 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130])
	by p130.piuha.net (Postfix) with ESMTP id 568C38994B;
	Sat, 25 Feb 2006 07:15:07 +0200 (EET)
Message-ID: <43FFE7ED.80909@piuha.net>
Date: Sat, 25 Feb 2006 07:15:25 +0200
From: Jari Arkko 
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Bernard Aboba 
Subject: Re: [Emu] RFC 2716: request for implementations
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433
Cc: emu@ietf.org, aboba@internaut.com
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: emu-bounces@ietf.org

Yes. All of this sounds very reasonable. I was
surprised to learn about the privacy part.

--Jari

Bernard Aboba wrote:

>> 5.  Security Considerations
>>
>> This needs more work, to fill in the descriptions required by RFC 3748.
>
>
> Right.  Here are the claims that I think can be made:
>
>      Auth. mechanism:           Certifications
>      Ciphersuite negotiation:   Yes
>      Mutual authentication:     Yes
>      Integrity protection:      Yes
>      Replay protection:         Yes
>      Confidentiality:           Depends
>      Key derivation:            Yes
>      Key strength:              (depends on ciphersuite negotiated)
>      Dictionary attack prot.:   Yes
>      Fast reconnect:            Yes
>      Crypt. binding:            N/A
>      Session independence:      Yes
>      Fragmentation:             Yes
>      Channel binding:           No
>
> Most EAP-TLS implementations do not support Privacy, since they send 
> the client cert in the clear.  However, in theory privacy support is 
> possible if the implementation brings up a protected channel based on 
> server authentication, then requests the client cert.  I'm curious if 
> any existing implementations support TLS privacy.
>
> In terms of key strength, this depends on the size of the 
> public/private key pairs used in the certificate.     As noted in 
> [RFC3766] Section 5, the level of attack resistance in bits is related 
> to the
> RSA or DH module and DSA subgroup size in bits:
>
>       Attack Resistance  RSA or DH Modulus     DSA subgroup
>          (bits)              size (bits)                      size (bits)
>        -----------------     -----------------                 
> ------------
>        70                          947                        128
>        80                        1228                        145
>        90                        1553                        153
>        100                       1926                       184
>        150                       4575                       279
>        200                       8719                       373
>        250                     14596                       475
>
> So a 2048-bit RSA key is required to provide 128-bit equivalent 
> strength.  Typically the default is lower than this (e.g. 128 bits).
>
> A formal analysis of EAP TLS has been done, that I am hoping we can 
> refer to for some of the properties:
>
> http://theory.stanford.edu/~changhua/f15-he.pdf
> http://www.cis.upenn.edu/~spyce/may05/anupam.pdf
>
>> From my reading of the paper, EAP-TLS is proven secure when utilized 
>> with 
>
> 802.11, as long as the TLS certificates are not reused for another 
> purpose (e.g. private keys are  not shared or same cert used for both 
> EAP and a Web server).   This raises some questions about whether 
> certificates used for EAP TLS should be restricted, as proposed in 
> this specification:
>
> http://www.watersprings.org/pub/rfc/rfc4334.txt
>
> However, as far as I know, RFC 4334 has not been implemented.
>
> BTW, the major non-editorial changes from RFC 2716bis are the removal 
> of several paragraphs:
>
> RFC 2716, Section 3.4:
>
>   Note that since the peer has made a claim of identity in the EAP-
>   Response/Identity (MyID) packet, the EAP server SHOULD verify that
>   the claimed identity corresponds to the certificate presented by the
>   peer.  Typically this will be accomplished either by placing the
>   userId within the peer certificate, or by providing a mapping between
>   the peer certificate and the userId using a directory service.
>
> Since RFC 3748 indicates that the EAP-Response/Identity is for routing 
> and that it need not match the method-specific identities, this 
> paragraph is not appropriate.
>
> RFC 2716, Section 3.6:
>
>   In order to ensure agreement between the EAP-TLS ciphersuite
>    negotiation and the subsequent ECP negotiation (described in [6]),
>    during ECP negotiation the PPP peer MUST offer only the ciphersuite
>    negotiated inEAP-TLS.  This ensures that the PPP authenticator MUST
>    accept the EAP-TLS negotiated ciphersuite in order for the
>    onversation to proceed.  Should the authenticator not accept the
>    EAP-TLS negotiated ciphersuite, then the peer MUST send an LCP
>    terminate and disconnect.
>
>    Please note that it cannot be assumed that the PPP authenticator and
>    EAP server are located on the same machine or that the authenticator
>    understands the EAP-TLS conversation that has passed through it. Thus
>    if the peer offers a ciphersuite other than the one negotiated in
>    EAP-TLS there is no way for the authenticator to know how to respond
>    correctly.
>
> As far as I know, implementations of EAP TLS do not utilize TLS 
> ciphersuite negotiation for the purpose of negotiating link layer 
> ciphersuites, since this would conflict with link layer ciphersuite 
> negotiation (such as the 4-way handshake in 11i).
>
> RFC 2716 Section 3.5 (relating to key derivation) needs to be revised 
> to use more modern terminology (MSK, EMSK, etc.), but hasn't been done 
> yet.
>
>
>
>


_______________________________________________
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu



From emu-bounces@ietf.org Sat Feb 25 11:41:14 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FD2Tq-0003ih-1C; Sat, 25 Feb 2006 11:41:14 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FD2To-0003i4-GT
	for emu@ietf.org; Sat, 25 Feb 2006 11:41:12 -0500
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FD2Tj-0005Xf-N5
	for emu@ietf.org; Sat, 25 Feb 2006 11:41:12 -0500
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150])
	by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id
	k1PGf5N7006232
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sat, 25 Feb 2006 08:41:05 -0800
Received: from LDONDETI.qualcomm.com (qconnect-10-50-77-22.qualcomm.com
	[10.50.77.22])
	by sabrina.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id
	k1PGf0Zg027553
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Sat, 25 Feb 2006 08:41:02 -0800 (PST)
Message-Id: <6.2.5.6.2.20060225083328.03d3a3a0@qualcomm.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Sat, 25 Feb 2006 08:41:00 -0800
To: eap@frascone.com, emu@ietf.org
From: Lakshminath Dondeti 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b22590c27682ace61775ee7b453b40d3
Cc: "Barany, Pete" , rrezaiifar@qualcomm.com
Subject: [Emu] Fwd: I-D ACTION:draft-barany-eap-gee-00.txt 
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: emu-bounces@ietf.org

Hi all,

Pete, Vidya, Ramin and I propose a new EAP encapsulation scheme to 
signal access or service authentication to support multiple parallel 
authentications (among other things, Please see below for the 
abstract and a link to the I-D) using EAP.  The plan is to use this 
in 3GPP2 and perhaps in 802 networks.

We requested Jari and Bernard for a slot for presentation at the EAP 
WG.  We realize that this work might not fit within the scope of 
either EAP or EMU, but we would like to get reviews from the EAP 
community before requesting publication.

Thanks in advance.

best regards,
Lakshminath


>To: i-d-announce@ietf.org
>Cc:
>From: Internet-Drafts@ietf.org
>Date: Fri, 24 Feb 2006 18:50:01 -0500
>X-Spam-Score: -5.9 (-----)
>X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87
>Subject: I-D ACTION:draft-barany-eap-gee-00.txt
>X-BeenThere: i-d-announce@ietf.org
>X-Mailman-Version: 2.1.5
>Reply-To: internet-drafts@ietf.org
>List-Id: i-d-announce.ietf.org
>List-Unsubscribe: ,
>         
>List-Post: 
>List-Help: 
>List-Subscribe: ,
>         
>X-PMX-Version: 4.7.0.111621
>X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, 
>Antispam-Data: 2006.01.13.142606
>X-OriginalArrivalTime: 25 Feb 2006 00:22:44.0299 (UTC) 
>FILETIME=[98D101B0:01C639A1]
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>
>         Title           : Generic EAP Encapsulation (GEE)
>
>         Author(s)       : P. Barany, et al.
>         Filename        : draft-barany-eap-gee-00.txt
>         Pages           : 22
>         Date            : 2006-2-24
>
>The Extensible Authentication Protocol (EAP) is a general
>authentication protocol that supports multiple authentication methods
>and typically runs directly over data link layers without requiring
>IP.  EAP can be used for both access and service authentication,
>where the access network provider may or may not be the same as the
>service network provider.  However, EAP itself does not have the
>ability to differentiate between access and service authentication.
>Furthermore, when the service network provider is a mobility service
>provider, Mobile IP-AAA signaling is/can be used for service
>authentication; thereby making EAP service authentication redundant.
>However, EAP itself does not have the ability to instruct the peer
>that it should use Mobile IP-AAA signaling for service authentication
>instead of EAP.  This document specifies a general encapsulation
>protocol, called Generic EAP Encapsulation (GEE), for differentiating
>between access and service authentication and for communicating to
>the peer that it should use Mobile IP-AAA signaling for service
>authentication instead of EAP.
>
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-barany-eap-gee-00.txt
>
>To remove yourself from the I-D Announcement list, send a message to
>i-d-announce-request@ietf.org with the word unsubscribe in the body 
>of the message.
>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>to change your subscription settings.
>
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>         "get draft-barany-eap-gee-00.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>         mailserv@ietf.org.
>In the body type:
>         "FILE /internet-drafts/draft-barany-eap-gee-00.txt".
>
>NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
>
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>
>Content-Type: text/plain
>Content-ID: <2006-2-24163119.I-D@ietf.org>
>
>ENCODING mime
>FILE /internet-drafts/draft-barany-eap-gee-00.txt
>
>
>
>_______________________________________________
>I-D-Announce mailing list
>I-D-Announce@ietf.org
>https://www1.ietf.org/mailman/listinfo/i-d-announce


_______________________________________________
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu



From emu-bounces@ietf.org Mon Feb 27 11:02:47 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FDkpj-0008P2-B4; Mon, 27 Feb 2006 11:02:47 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FDkph-0008Oj-23
	for emu@ietf.org; Mon, 27 Feb 2006 11:02:45 -0500
Received: from ns1.cpanel.btnaccess.com ([205.177.121.2])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDkpe-0008Re-HW
	for emu@ietf.org; Mon, 27 Feb 2006 11:02:45 -0500
Received: from [65.213.193.135] (helo=ISODELL001)
	by ns1.cpanel.btnaccess.com with esmtp (Exim 4.52)
	id 1FDkpc-0008JR-K2 for emu@ietf.org; Mon, 27 Feb 2006 11:02:41 -0500
From: "Robert Holliday" 
To: 
Date: Mon, 27 Feb 2006 11:02:41 -0500
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Thread-Index: AcY7tzwlVMZrPaTaSwWdeRQi0n0jaA==
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - ns1.cpanel.btnaccess.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - isocore.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129
Subject: [Emu] International Conference on Network Security 2006
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1609269289=="
Errors-To: emu-bounces@ietf.org
Message-Id: 

This is a multi-part message in MIME format.

--===============1609269289==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0028_01C63B8D.54C10040"

This is a multi-part message in MIME format.

------=_NextPart_000_0028_01C63B8D.54C10040
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Registration Open!!!

 

Reston Virginia, April 17-19

Early Registration Benefits Now Available

 

The conference offers cutting edge discussion and presentations on the
contemporary issues in network security and critical information
infrastructure.  

 

Technical Program: http://www.isocore.com/networksecurity2006/program.htm 

 

Discounts still available for early registration.

 

Registration:  
http://www.isocore.com/networksecurity2006/onlineregis.htm

 

Hotel space is limited but currently available and reservation can be made
on-line.

 

Hotel Reservations: http://www.isocore.com/networksecurity2006/hotel.htm

 

To obtain special rates for student or group please contact Robert Holliday
at rholliday@isocore.com.

 

www.networksecurity2006.com  

 

 

 


------=_NextPart_000_0028_01C63B8D.54C10040
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

















Registration =
Open!!!



 



Reston Virginia, April =
17-19



Early Registration Benefits =
Now
Available



 



The conference offers cutting edge discussion and
presentations on the contemporary issues in network security and =
critical
information infrastructure.  



 



Technical =
Program: http://ww=
w.isocore.com/networksecurity2006/program.htm




 



Discounts still available for early =
registration.



 



Registration: http://www.isocore.com/networksecurity2006/onlineregis.htm



 



Hotel space is limited but currently available and
reservation can be made on-line.



 



Hotel =
Reservations: http://www.=
isocore.com/networksecurity2006/hotel.htm



 



To obtain special rates for student or group please =
contact
Robert Holliday at rholliday@isocore.com.



 



www.networksecurity2006.com<=
/a>



 



 



 









------=_NextPart_000_0028_01C63B8D.54C10040--



--===============1609269289==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

--===============1609269289==--





From emu-bounces@ietf.org Mon Feb 27 11:14:56 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FDl1U-00071W-Cj; Mon, 27 Feb 2006 11:14:56 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FDl1T-00071L-20
	for emu@ietf.org; Mon, 27 Feb 2006 11:14:55 -0500
Received: from zproxy.gmail.com ([64.233.162.205])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDl1S-0000Tn-Np
	for emu@ietf.org; Mon, 27 Feb 2006 11:14:55 -0500
Received: by zproxy.gmail.com with SMTP id o1so1001208nzf
	for ; Mon, 27 Feb 2006 08:14:54 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references;
	b=MlELoc0tnMngj7DTCv1PnEveXH5JSjkEC318Ka962DBkGh/AXx7vcRwgMybzz9vO1Ps5m963sPPZgXcRxb4JWIzyZjcqKIzcAKS8K/m2W3/4YKP50rigB+B2XUcQkGnenlxMBjxABzvYEWHRcTmPPEeaKp48iJkoOYhHI4zJpEk=
Received: by 10.64.179.19 with SMTP id b19mr3543088qbf;
	Mon, 27 Feb 2006 08:14:52 -0800 (PST)
Received: by 10.65.186.6 with HTTP; Mon, 27 Feb 2006 08:14:52 -0800 (PST)
Message-ID: 
Date: Mon, 27 Feb 2006 17:14:52 +0100
From: Badra 
To: "Robert Holliday" 
Subject: Re: [Emu] International Conference on Network Security 2006
In-Reply-To: 
MIME-Version: 1.0
References: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48
Cc: emu@ietf.org
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0481103355=="
Errors-To: emu-bounces@ietf.org

--===============0481103355==
Content-Type: multipart/alternative; 
	boundary="----=_Part_5329_4515436.1141056892832"

------=_Part_5329_4515436.1141056892832
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I don't know if such mails are allowed to be posted at IETF-WG mailing
lists; especially in the case when he receives it many time because he is a=
m
member at many list



On 2/27/06, Robert Holliday  wrote:
>
>  Registration Open!!!
>
>
>
> Reston Virginia, April 17-19
>
> Early Registration Benefits Now Available
>
>
>
> The conference offers cutting edge discussion and presentations on the
> contemporary issues in network security and critical information
> infrastructure.
>
> * *
>
> *Technical Program:*
> http://www.isocore.com/networksecurity2006/program.htm
>
>
>
> Discounts still available for early registration.
>
>
>
> *Registration:* http://www.isocore.com/networksecurity2006/onlineregis.ht=
m
>
>
>
> Hotel space is limited but currently available and reservation can be mad=
e
> on-line.
>
>
>
> *Hotel Reservations:* http://www.isocore.com/networksecurity2006/hotel.ht=
m
>
>
>
> To obtain special rates for student or group please contact Robert
> Holliday at rholliday@isocore.com.
>
>
>
> www.networksecurity2006.com
>
>
>
>
>
>
>
> _______________________________________________
> Emu mailing list
> Emu@ietf.org
> https://www1.ietf.org/mailman/listinfo/emu
>
>
>

------=_Part_5329_4515436.1141056892832
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline


I don't kn=
ow if such mails are allowed to be posted at IETF-WG mailing lists; especia=
lly in the case when he receives it many time because he is am member at ma=
ny list





 


On 2/27/06, =
Robert Holliday <robholli=
day@isocore.com> wrote:





Registration Open!!!


 


Reston Virginia, April 17-19


Early Registration Benefits Now Available


 


The conference offers cutting edge discussion and presentations=
 on the contemporary issues in network security and critical information in=
frastructure. =20



 


Technical Program: 
http://www.isocore.com/networksecurity2006/program.htm 

 


Discounts still available for early registration.=



 


Registration: =


http://www.isocore.com/networksecurity2006/onlineregis=
.htm


 


Hotel space is limited but currently available and reservation =
can be made on-line.


 


Hotel Reservations: 
http://www.isocore.com/networksecurity2006/hotel.htm


 


To obtain special rates for student or group please contact Rob=
ert Holliday at 
rholliday@isocore.com.


 


www.networksecu=
rity2006.com



 


&n=
bsp;


 

_____________________________=
__________________
Emu mailing list

Emu@ietf.org
=
https://www1.ietf.org/mailman/listinfo/emu






------=_Part_5329_4515436.1141056892832--


--===============0481103355==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

--===============0481103355==--