Dan,
I am not sure I am able to clearly understand the end result you seek.
It seems there is a clear consensus for a tunneled method. Are you
pushing for the addition of a tunneled method?
Ok... I am easily baited. What would you like to see to achieve more
than a snail race? I am assuming we bo
Gene Chang said:
Dan,
I am not sure I am able to clearly understand the end result you seek.
It seems there is a clear consensus for a tunneled method. Are you
pushing for the addition of a tunneled method?
Ok... I am easily baited. What would you like to see to achieve more
than a snail race?
Yoav,
I ask for some latitude in my choice of words to describe some of the
use cases that interest me. It feels to me (possibly its must me being
naive) that we are tip-toeing around the dual use of some EAP methods to
support some interesting use cases. These use cases are out of scope for
EMU.
Yoav:
I thought we had clear consensus in IETF 71 WG meeting and instructed by
the AD that while Dan's proposal is an interesting one, but it doesn't
work with the legacy password databases and thus out-of the scope of the
charter. Until we have the proof of security analysis and clear of IPR
iss
Hi Gene,
I'm not pushing a tunneled method. We have enough of those and their
differences are not so great.
Yes, I was using "snail race" as a pejorative. As I said at the last
IETF we should have a cage-match-cum-beauty-contest between TTLS and
FAST, turn the last RFC text of the winner i
Hold on a second there Hao. A security proof was never a requirement.
I'm not aware of any other IETF protocols that required security proofs
or even have security proofs. There is no formal proof required of the
tunneled methods and I think it would be very difficult to do one.
One of the pr
Dan:
Now you have changed to argue that tunnel method is not the right
solution for the use case EMU is targeted on, instead of arguing your
proposed password should be included as addition to the tunnel method. I
thought working on and standardizing the tunnel method is the WG
consensus for few I
Dan,
I think we can all appreciate the entertainment value of bringing a
reality show to the IETF. Imagine replacing the IETF social with an
arena full of hyped up Internet engineers enjoying a night fellowship
with beer and trash talk.
Unfortunately, all we are doing is dressing up a down select
Hao,
On Mon, April 28, 2008 10:32 am, Hao Zhou (hzhou) wrote:
> Dan:
>
> Now you have changed to argue that tunnel method is not the right
> solution for the use case EMU is targeted on, instead of arguing your
> proposed password should be included as addition to the tunnel method. I
> thought
Hi Yoav,
You bring up an interesting point in discussing the need for EAP
password based authentication within other protected protocols. If this
is targeted at working with legacy databases then I think it can be
accommodated under the current charter. An EAP protected tunnel is
required for so
Gene,
I don't think anyone would find an EMU reality show entertaining. The
only comic relief would be one crazy guy who, once every 4 months, pokes
his head in the window and says "I do not approve" to people sitting
around watching paint dry.
You are restating Stephen's comment from Phil
Dan,
Great, we are not back to lets get those requirements done. It's the
gate to the next steps.
Gene
Eugene Chang (genchang)
Cisco Systems
Office: 603-559-2978
Mobile: 781-799-0233
Skype: gene02421
> -O
Oops... a key typo in the earlier version...
Dan,
Great, we are now back to let's get those requirements done. It's the
gate to the next steps.
Gene
Eugene Chang (genchang)
Cisco Systems
Office: 603-559-2978
Mobile:
You are welcome on the chairs and big congratulations while anticipating
your able leadership.
Thank you,
^^Gogwim,Joel.
On Fri, April 25, 2008 3:19 pm, Tim Polk said:
> Folks,
>
> Pasi and I are very pleased to announce that two of our co-chair
> vacancies have been filled.
>
> Alan Dekok has ag
14 matches
Mail list logo
