Alan,
You are misrepresenting my concerns with this draft and (intentionally)
misunderstanding my post.
On Thu, December 3, 2009 1:20 pm, Alan DeKok wrote:
> The document states a clear requirement: the tunneled method MUST be
> capable of sending clear-text passwords in the tunnel.
A "clear-text" password will have to be sent "in the tunnel" because
otherwise authentication would not be possible! I am not against a
requirement to have an authentication protocol that is capable of
authentication. In fact, I am very much opposed to an authentication
protocol that would be incapable of authenticating. OK? Is this clear
enough?
My issue is with the text saying "[the tunnel method] MUST NOT expose
the username and password to parties in the communication path between
the peer and the EAP server...." As I have repeatedly stated, that is
vague and a reasonable interpretation of that statement could end up
with an insecure protocol by exposing password-derived data but not
the password.
I happen to think that this can be reworded to not be vague and in
a way that concisely expresses the desired property we want the tunnel
method to have.
I later mentioned a side issue ("heartburn") in that requiring the
password to be sent to an authentication server seems to be requiring a
particular implementation and that is not appropriate for a protocol
requirements draft since whether you have an authentication server or
not is a deployment optimization. Now particular implementations may
solve real-world deployment issues and that's great. That's a fine
reason to implement a protocol in such a fashion. It's not a requirement
of the protocol though, it's an implementation optimization.
> You agree that the attacks against this requirement are adequately
> covered by existing text in the document:
>
> http://www.ietf.org/mail-archive/web/emu/current/msg01327.html
No, that is not what I said. You provided "two attack scenarios"
and all I did was say that my suggested text covered them both. That
was an effort on my part to demonstrate that we were not losing anything
by going with my text.
> However, you then suggest your text as a "more accurate" definition of
> the requirements. I have asked for clarification as to why your text is
> better, and received (a) repetitions of the same text, and (b)
> suggestions to go read your previous messages.
Your chronology is a bit off. I suggested my text was more accurate
in my first post of this lamentable thread. You should: (b) go read my
previous message.
My first email on this topic, to Joe, explains why my text is better.
Apparently you did not read that post very closely before slicing it up
and responding to bits and pieces. That belief in confirmed by your
subsequent statements: like how my suggested text is not in the draft--
no kidding, that's why it's suggested text, or asking what text it is
replacing-- the text you removed from the post you obviously didn't
fully read, that's what.
So when you ask me why my text is more accurate when you obviously have
failed to fully read a post I made where I explain why it's more accurate
I tell you to go back and read the post. And I am telling you again: go
back and read the post. Here it is:
http://www.ietf.org/mail-archive/web/emu/current/msg01325.html
> Your text removes the requirement to send a clear-text password in a
> tunnel. I am therefore opposed to it, for reasons I have outlined
> earlier. I understand that you find your text more specific than the
> current text in the document. I do not.
My text does not remove a requirement to send a clear-text password
in a tunnel! You're opposed to a straw man of your own creation.
Dan.
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
