Re: WG Review: EAP Method Update (emu)
Jari Arkko <jari.arkko@piuha.net> Tue, 03 January 2006 14:31 UTC
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 1EtnCc-0003dd-34; Tue, 03 Jan 2006 09:31:54 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtnCZ-0003dM-Em; Tue, 03 Jan 2006 09:31:51 -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 JAA29873; Tue, 3 Jan 2006 09:30:38 -0500 (EST)
Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtnHq-0004to-NL; Tue, 03 Jan 2006 09:37:20 -0500
Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id C21C0898CE; Tue, 3 Jan 2006 16:31:35 +0200 (EET)
Message-ID: <43BA8AE7.8070908@piuha.net>
Date: Tue, 03 Jan 2006 16:32:07 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Pekka Savola <pekkas@netcore.fi>
References: <E1Ep42T-0007jW-5w@newodin.ietf.org> <Pine.LNX.4.64.0512221038080.10785@netcore.fi>
In-Reply-To: <Pine.LNX.4.64.0512221038080.10785@netcore.fi>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Content-Transfer-Encoding: 7bit
Cc: iesg@ietf.org, ietf@ietf.org
Subject: Re: WG Review: EAP Method Update (emu)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
Pekka, > Is there a particular reason why the proposed charter does not mention > EAP-TTLS? > > I know very little about different EAP types, but as a potential > operator and user of EAP, I'd definitely want to see focus on > something like EAP-TTLS. > > Given that EAP-TTLS seems to be becoming an industry standard in > certain scenarios, it would be useful to clarify the relation of the > work of this proposed WG wrt EAP-TTLS in the charter. The relation > may already be obvious to those who've been working on that space > more, but as an EAP user, I'd like to make it explicit to ensure folks > are on the same page.. First, some background on the difference of EAP TLS vs. EAP-TTLS. EAP TLS uses TLS mutual authentication (typically with certs). In contrast, tunneled EAP methods, such as EAP-TTLS or PEAP employ TLS and an inner method. Typically, the outer TLS authentication is for the server only, and used to protect an inner authentication that may happen, for instance, with passwords. Tunneled EAP methods typically have also additional built-in functionality, for instance, to exchange various parameters for configuration and verification purposes. EAP-TLS is an existing Experimental RFC that the EMU WG is chartered to update and extend. Tunneled EAP methods have been described in drafts, and there are a few different ones and they have a few different versions. There has been some discussion previously about working on tunnel methods in EMU. Assuming there'd be willing contributors & change control would be given to IETF, this would be a useful area to work, since, as you point out, these are widely used methods. Drawbacks include a lot of existing deployment with sometimes incompletely documented and proprietary methods. I also worry about doing too many things in EMU at the same time; we are already on the limit. But once work items get completed, new things can be worked on. The EAP TLS update should be fairly easy and non-controversial task, for instance, so hopefully it is completed soon. In any case, the charter does include work on "password-based methods". The specific arrangement for how passwords are to be used is TBD, but tunneled TLS- like methods are one possibility. While password-based client/cert-based server authentication is a special case of what existing tunnel methods can do, it may be the most important case. If we succeed in defining these methods, one can hope that the new method would start to take over some existing TTLS et al usage. --Jari _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
- Re: WG Review: EAP Method Update (emu) Pekka Savola
- Re: WG Review: EAP Method Update (emu) Clint Chaplin
- Re: WG Review: EAP Method Update (emu) Jari Arkko
- Re: WG Review: EAP Method Update (emu) Jari Arkko
- Re: WG Review: EAP Method Update (emu) Sam Hartman