Dan Harkins wrote:
> Yes, I can propose a specific modification. In fact, I did already.
It wasn't clear that the text was the suggested replacement.
> It just got truncated from the thread. What I suggest is that in
> section 3.1, in the middle of the first paragraph (the text that Joe
> was quoting originally), remove this:
>
> "The tunnel method MUST support transporting the username
> and password to the authentication server. However, it
> MUST NOT expose the username and password to parties in the
> communication path between the peer and the EAP server and
> it MUST provide protection against man-in-the-middle and
> dictionary attacks."
>
> and put this in its stead:
>
> "The advantage any attacker gains against the tunneled method
> when employing a username and password for authentication MUST
> be through interaction and not computation".
>
> I believe that captures the property we want the tunnel method to
> have and is not so vague.
Except it *removes* the requirement that the tunneled method transport
the username and password. Given the capabilities of widely deployed
systems, I think that this requirement should be kept.
> It applies to active attacks against the
> authenticator, active attacks against the client, passive attacks
> between them and between the authenticator and any authentication
> server that may exist, and all forms of man-in-the-middle and
> dictionary attack that could be launched against the legitimate
> participants in this tunnel method.
How about simply adding your text?:
"The tunnel method MUST support transporting the username
and password to the authentication server. However, it
MUST NOT expose the username and password to parties in the
communication path between the peer and the EAP server and
it MUST provide protection against man-in-the-middle and
dictionary attacks. That is, the advantage any attacker gains
against the tunneled method when employing a username and password
for authentication MUST be through interaction and not
computation".
I think this addresses your concerns, while simultaneously stating
clearly the specific requirements.
Alan DeKok.
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
