PAKEs ("password authenticated key exchanges") are a kind of public-key algorithm.
When two people use public key crypto to exchange a key in public, they need a way to "break the tie" in case of a MITM attacker. The conventional way to do this is with a certificate; that's how TLS works.
A PAKE uses instead a password; it does that by baking the password into the public/ephemeral key generation process. Alice & Bob can't agree on a MITM'd key if the MITM doesn't know the password; they just won't come up with the same numbers.
Dragonfly is a PAKE designed by Dan Harkins a bunch of years ago. Harkins got Dragonfly added to LEAP, the extensible authentication framework for 802.11 networks. He would very much like it added to TLS as well.
The trouble with that is, nobody knows why we would want to add Dragonfly to TLS. TLS already has a PAKE option, SRP. SRP is better than Dragonfly; it's designed to make it hard for an attacker who seizes a server to collect a database of passwords. SRP is also well-studied and well-understood; if it isn't particularly beloved of academic cryptographers, well, Dragonfly doesn't score any better. But more importantly, nobody uses TLS-SRP. No browser implements it. The demand for PAKE authentication in TLS is not strong.
It gets worse for Dragonfly. The protocol has problems. I'm going to get myself into a little bit of trouble summarizing, but here goes: Dragonfly can be made to work with elliptic curve key exchange. The process for mixing a password into an ECC key exchange involves a trial-and-error process for finding a valid curve point; a loop runs conducting these trials. A passive attacker could, in an earlier version of the Dragonfly protocol, discern how many iterations through the loop had happened to find a valid point given a password. Dragonfly is randomized: a nonce is mixed into every exchange. As a result, the same password might take a different number of loop iterations on every login attempt.
Net result: given a corpus of 232 passwords, 32-and-change passive observations of the key exchange might uniquely identify the password used!
Modifications to the protocol were proposed, some in the CFRG process, but they in turn resulted in a protocol with a side-channel weakness: the process of computing parameters for the key exchange leaks timing information.
Dragonfly has one sponsor that we know of: Kevin Igoe on the CFRG.
Trevor Perrin broke this down in amazing detail, mining posts out of several IETF mailing lists. Probably nobody is ever going to use Dragonfly in the real world, but watching people pick apart a new crypto protocol in public is amazing and hugely educational. I highly recommend reading this post:
http://www.ietf.org/mail-archive/web/tls/current/msg10962.ht...