Subject: Re: WG Review: EAP Method Update (emu)

From: Clint Chaplin <[email-masked]>
Date: Mon, 2 Jan 2006 11:22:18 -0800

Has an email list been set up for this effort yet?

On 12/22/05, Pekka Savola <[email-masked]> wrote:
> On Wed, 21 Dec 2005, The IESG wrote:
> > - An update to RFC 2716 to bring EAP-TLS into standards track, clarify
> > specification, interoperability, and implementation issues gathered over the
> > years, and update the document to meet the requirements of RFC 3748, RFC 4017,
> > and EAP keying framework documents.
> > Backwards compatibility with RFC 2716 is a requirement.
>
> 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..
>
> --
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf
>

--
Clint (JOATMON) Chaplin
Wireless Security Technologist
Wireless Standards Manager

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Jari Arkko <[email-masked]>
Date: Tue, 03 Jan 2006 14:24:00 +0200

>Has an email list been set up for this effort yet?
We are currently operating under the "secmech" list:

      General Discussion: [email-masked]
      To Subscribe:       https://www1.ietf.org/mailman/listinfo/secmech
      Archive:            http://www.ietf.org/mail-archive/web/secmech/index.html

But a new list "[email-masked]" will be created upon
WG approval. Stay tuned for subscription instructions.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 03 Jan 2006 16:32:07 +0200

Pekka,

> more, but as an EAP user, I'd like to make it explicit to ensure folks 

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

---

From: Sam Hartman <[email-masked]>
Date: Wed, 04 Jan 2006 10:58:23 -0500

>>>>> "Clint" == Clint Chaplin <[email-masked]> writes:

    Clint> Has an email list been set up for this effort yet?
    Clint> On 12/22/05, Pekka Savola <[email-masked]> wrote:

So, pre-wg this is being discussed on [email-masked].

However the WG will get its own mailing list if approved.