Dan Harkins wrote: > I guess it depends on what you mean by "expose". If it means a kind > of flashing-- here's the username and password!-- then no this is not > sufficient. Such an exposure is certainly a problem but popular ways to > get around this exposure are not satisfactory. What I'm saying is that > Jeff Schiller's old maxim of "NO PLAINTEXT PASSWORDS!" is necessary but > not sufficient. Password-derived data-- "I'll hash in the password and > a couple of nonces so it's not a plaintext password anymore"-- also poses > a problem. So to answer your question of whether any modification is > needed, yes it is.
OK, but which attacks are we preventing? The current text says that the only parties who can see the plain-text password are EAP peer and server. i.e. the ones at either end of the TLS connection. Do you think that this is OK, or insecure? > Password-based authentication methods are flawed by definition because > the attacker can always be wildly lucky and guess the password at any > time-- whether the attack is on-line or off-line. Therefore the definition > should say _exactly_ what kind of property is desired in a tunneled method > that employs username and password for authentication. OK. > What needs to be said is that when using password-based authentication, > each attack MUST NOT leak more than a single bit of information-- that > single bit being whether a singular guess is correct or not. I suggest > using the canonical definition of "dictionary attack" from the > cryptographic literature: > > "The advantage any attacker gains against the tunneled method > when employing a username and password for authentication MUST > be through interaction and not computation". The current text doesn't say that, but it is a property of the authentication method. We have two attack scenarios: peer and server. As peer, the attacker suggests a password, and the server either ACKs it or NAKs it. That is a single bit of data. As a server, the attacker must set up a TLS connection to the peer. Since the attacker is presumed to *not* be able to spoof the certificates, the peer will never send a password, and the attacker gains nothing. If we presume that the attacker can successfully attack TLS, then we have issues larger than exposing user passwords. If the peer does not properly validate TLS certificates (via user intervention or programmer error), then yes... the complete password can leak. Preventing attacks due to user error is hard. The only thing we can safely do here is suggest ways to minimize the attacks. e.g. The peer can request authentication for a realm (@example.com), and validate that the server certificate is "owned" by that realm. This practice is in wide-spread use today. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
