Hi all,
before we spend more time considering EAP tunneling methods like PEAP
and TTLS I would like to hear the opinion of our ADs on this subject.
So far, the working assumption was that EAP methods that tunnel EAP are
outside the scope of the working group. These statements were also
I see it a bit differently since I was at many EAP meetings where EAP
method authors wanted to work on standards track EAP methods.
Ciao
Hannes
Bernard Aboba wrote:
Part of the problem with EAP methods is that people should have
started to standardize them within the IETF several years ago.
I also need to say that at the IETF#68 EMU WG meeting the discussions in
the room where pretty positive for moving forward with a simple
password-based EAP method using TLS without another EAP encapsulation on
top of TLS. I also got the impression after the session that the people
in the room
Hannes == Hannes Tschofenig [EMAIL PROTECTED] 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
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
I can easily see how crypto-binding could be added to the protocol
without breaking backwards compatibility, eg how negotiation via
TTLSv0's extensibility model could add this in as a optional operation
that the client and server agree upon.
In general I think having a standards based,
Bernard Aboba mailto:[EMAIL PROTECTED] allegedly scribbled on
Monday, April 02, 2007 3:42 PM:
Part of the problem with EAP methods is that people should have
started to standardize them within the IETF several years ago.
Unfortunately, there was no interest by some of the EAP method
authors
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.
FWIW, EAP-TTLSv0 does support non-EAP
Jouni Malinen wrote:
I'm aware of at least one, though maybe partial, implementation of
TTLSv1. Anyway, I don't think it has been deployed anywhere.
I talked to Paul Funk about this. He hasn't implemented EAP-TTLSv1,
is not planning to do so, and is not aware of any implementations
or
Also, Pascal asked about a patent application. I asked Paul about
that and he said it isn't about EAP-TTLS.
Searching the IETF IPR page, I found the following disclosure, which relates
to TLS-IA, and therefore is only relevant to EAP-TTLSv1:
I would recommend that the design team put together a draft that can be
evaluated against other options if they are generated. The draft should
strive to meet the requirements and be simple. I think we already have a
good start.
Joe
___
Emu mailing
11 matches
Mail list logo
