Weaknesses of RFC6628 In RFC6628 section 2.2, they say:


  w = The password remembered by the user.
  W = The password verifier registered in the server. W = g^w mod p, where g and p are agreed upon in advance.


They claim resistance against server compromise. But if an attacker gains access to the password verifier W, how much work is the attacker required to do per password guess, in order to conduct an offline brute force dictionary attack?

If I'm not mistaken, the answer to this question is: The work required for each password guess is to raise a single large exponent, and compute a single large modulo-division. This is not comparable to pbkdf2, bcrypt, scrypt, or similar, and probably should not be considered a strong enough rate-limiter to protect a low entropy password against server compromise.
Yes, the protocol in RFC6628 (and SRP) is vulnerable to brute force password search in the event of server compromise. 
As Thomas Pornin puts it: for all password-based authentication protocols, what the server knows must allow for offline dictionary attacks, since an attacker who could get a complete snapshot of the server could simulate a client and a server on his own machines, and see when the simulated server accepts the password provided by the simulated client. This is rather unavoidable; thus, it is not a vulnerability of RFC6628/SRP specifically, but rather a vulnerability of authenticating clients with passwords.

That fact is acknowledged by a creative definition of resistance to server compromise:


  An augmented PAKE protocol is said to provide resistance to server compromise in the sense that the attacker cannot impersonate the user without performing off-line dictionary attacks on the password verifier.


The only thing I can think of to improve on that is replacing the password on the server side by a conventional entropy-stretched (purposely slow) hash (such as scrypt) of the password, with salt set to username and serverid, computed on client side at each use. So we have that entropy-stretching hash as the last line of defense in case of server compromise. That would require trusted and reasonably efficient code implemented on the client side, which is hard to get with the current browser architecture.

Update: There's room to add such entropy-stretching in RFC6628. As an option, RFC6628 allows for use of a so-called effective password which is $w'=H'(\text{0x00}\|U\|S\|w)$ (where $H'$ is a hash function; $U$ is the user's identity; $S$ is the server's identity; $w$ is the password remembered by the user, after normalization per RFC4013), then used to compute $W=g^{w'}\bmod p$. So if we use that effective password option, and use an entropy-stretching hash for $H'$ (that is: a slow one, at least for input starting in $\text{0x00}$), we have some serious protection. A brute force password search would require one evaluation of $H'$ per $U\|S\|w$ tested, and some extra work involving modular arithmetic to test against $W$.

Without the effective password option, the amount of work to test a password in an off-line password search attack following server compromise can be down to near one modular multiplication: we can express most passwords $w_j$ that we want to test as $w_i+\delta$ with $\delta$ in a small set, implying that $W_j=W_i\cdot\Delta\bmod p$, with $\Delta=g^\delta\bmod p$ precomputed.