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