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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf