AW: AW: [Emu] Re: Next Steps on Passwd-based EAP Methods
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AW: AW: [Emu] Re: Next Steps on Passwd-based EAP Methods
During the meeting the group said that they want to have a password-based only approach (no tunneled EAP support). Even CHAP etc. was left for future work, if ever done. For this purpose PAP over TLS + room for extensibility is just good enough.
Ciao
Hannes
> -----Ursprüngliche Nachricht-----
> Von: ext Sam Hartman [mailto:hartmans-ietf at mit.edu]
> Gesendet: Dienstag, 3. April 2007 17:40
> An: Tschofenig, Hannes
> Cc: Hannes Tschofenig; wpolk at nist.gov; emu at ietf.org
> Betreff: Re: AW: [Emu] Re: Next Steps on Passwd-based EAP Methods
>
> >>>>> "Tschofenig," == Tschofenig, Hannes
> <hannes.tschofenig at nsn.com> writes:
>
> Tschofenig,> Hi Sam,
> >> >>>>> "Hannes" == Hannes Tschofenig <Hannes.Tschofenig at gmx.net>
> >> writes:
> >>
> Hannes> Hi all, before we spend more time considering EAP
> Hannes> tunneling methods like PEAP and TTLS I would like to hear
> Hannes> the opinion of our ADs on this subject. So far, the
> Hannes> working assumption was that EAP methods that tunnel EAP
> Hannes> are outside the scope of the working group. These
> Hannes> statements were also repeated during the IETF#68 EMU WG
> Hannes> meeting by our ADs.
> >> I at least don't recall objecting to a tunnel method. If
> >> you're going to do a tunnel method you do need cryptographic
> >> binding when tunneling something that generates a key.
>
> Tschofenig,> I recall that you rejected the TTLS approach where we
> Tschofenig,> would have to add EAP support into TLS. I am also
> Tschofenig,> happy to hear that you like providing EAP support in
> Tschofenig,> TLS.
>
> Yes, I reject that approach to tunnelsing. But you could for example
> use the TLS application record protocol to tunnel EAP.
>
_______________________________________________
Emu mailing list
Emu at ietf.org
https://www1.ietf.org/mailman/listinfo/emu
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.