Hi Alan, On Tue, December 1, 2009 2:03 am, Alan DeKok wrote: > 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?
Don't think of it as "which attacks are we preventing", we're modeling the protocol and ascribing a desired property to the modeled protocol. What is that property? "Not exposed" is not a property. > 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? If the world only consisted of EAP peers and servers then we would not have to worry. Sadly, that is not the case. The text says the method "MUST NOT expose" the username and password. The word "expose" is not defined and is very vague and open to interpretations that would result in an insecure protocol. I think there is a property in a properly modeled protocol that could replace that vague term. >> 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. I know it doesn't say that! I'm proposing that it does! > As peer, the attacker suggests a password, and the server either ACKs > it or NAKs it. That is a single bit of data. Yes. > 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. Yes. > 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. Let's assume TLS is secure. > 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. What I don't think you seem to realize is that the definition I proposed works for the 2 situations you came up with. I am offering a suggestion for a more accurate definition of what we want out of this protocol. I am not suggesting that TLS is insecure nor am I suggesting that the 2 apparent candidates for coronation as The New EMU-approved EAP Tunneling Method have flaws. I am saying that the current requirement is vague and may not be accurate for some reasonable definitions of "expose". I suggest a better, and more accurate description of this property. Is there a problem with my suggestion? Dan. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
