[Cfrg] comments on draft-irtf-cfrg-pake-reqs-05

[Feng Hao <[e-mail]>]

Hi Joern-Marc (and others who are interested in PAKE),

I have a few comments on the latest draft on "Requirements for PAKE schemes" (draft-irtf-cfrg-pake-reqs-05), and hope they may help. 

1. In Introduction, "In other words, they are horrible credentials to use for authentication". I don't think "horrible" is a scientific word that should be used here. The key question is what are the alternatives? Passwords are just one of the three authentication factors. The other two, including biometrics and token (which may store a public key certificate), also have various drawbacks. I suggest to remove this sentence as it doesn't look adding any value.

2. In introduction, it may be worth mentioning that there are two main approaches to realise "Authenticated" Key Exchange: based on PKI and passwords. The current TLS protocol is largely based on PKI. However, PKI has many problems (which everyone knows and you don't need to repeat in this draft). Hence, for applications where it's not feasible or possible to setup/maintain PKI, PAKE can be a suitable alternative. Of course, for those who believe PKI (or the use of public key certificates) works on solving all their problems, they don't need PAKE. I see that you mention later in the sentence that "PAKEs ... without requiring any Public Key Infrastructure (PKI)." I suggest you can elaborate this more, since PKI-based AKE and PAKE are two different protocols, which can be complementary. It's not the case that one replaces another.

3. In Sec 3.1, "When one side maintains an uninvertable transform of the password and ...". The word "uninvertable" is technically not correct as it's actually invertable for all augmented PAKEs with a certain doable effort. I suggest simply to remove the word "uninvertable". I don't know if there is a better way to rephrase this.

4. In Sec 3.1, "The benefit of an augmented PAKE is that the server's password database is protected in a way that is not possible with a balanced PAKE." The meaning is vague (to me). I suggest you to illustrate this more explicitly. 

5. In sec 3.1, "Augmented PAKEs are resistant to Key Compromise Impersonation (KCI) where an adversary who has successfully attacked Bob can impersonate Bob to everyone, but it is not possible to impersonate everyone back to Bob." This sentence is a bit problematic. I think you borrow the definition of KCI from PKI-based AKE, but it is mixed up in PAKE as the contexts are different. For example, assume Bob is the client: then this sentence is obviously wrong; now assume Bob is the server, then the sentence is still arguably incorrect, since the attacker can still break your security by doing an offline search. I don't know how to address this other than removing this sentence.

6. Actually, the above comments (3-5) are all related. The best is perhaps to rewrite that paragraph. There are a couple of points that are worth mentioning: 1) in balanced PAKE, the password doesn't have to be stored in plaintext form (I'm glad that you've covered that in the previous paragraph); 2) when the server is compromised, the stolen credential can be used directly to authenticate to the (compromised) server in the balanced PAKE case; but requires some offline brute-force effort in the augmented PAKE. That's the only advantage of augmented PAKE over balanced PAKE. However, saying that augmented PAKEs provide resistance to "server compromise" may provide a false sense of security, as once the server is compromised, all passwords must be updated anyway. No augmented PAKEs can provide any real security assurance in that case.

7. In Sec 3.2, " A variant of this method, as it is e.g. used in international travel documents by PACE [BFK09] ". The PACE protocol has two main stages: in the first stage, it uses the password to encrypt nonces, and in the second stage, it combines the nonces and other data to derive a secret base generator (like in SPEKE). So, saying PACE is a variant of EKE is not very correct; PACE is a protocol that combines the ideas of EKE and SPEKE.

8. In Sec 3.2, " These public keys may be blinded by some function of the shared password, but the public key that is transmitted across the unsecured medium is an element in a finite field, not a random blob". This seems to be more like how J-PAKE works rather than SPEKE. In SPEKE, what the party sends is a field element; I wouldn't call it a public key, as the generator in SPEKE must be kept secret. If you want to classify PAKEs, in my knowledge there are three: 1) using the password to encrypt key exchange items (e.g., EKE-style); 2) using the password to derive a secret generator (e.g., SPEKE-style); 3) the using the password to juggle the ephemeral public keys by encrypting items (and achieving a cancellation of random factors when the two passwords match) on the exponent (e.g., J-PAKE-style). 

9. In Sec 4, " All PAKEs have a flaw: if Eve guesses the password she can subvert the exchange". I would suggest changing "flaw" to "limitation". A flaw is more a design error that should have been addressed. But what you describe is one inherent limitation with PAKE. As an example, suppose one says that all PKI-based AKE schemes have a flaw: all parties need to trust CA - That's stating a factual limitation, not really a design flaw. 

10. " In addition, proofs sometimes rely on idealized versions of hash functions and/or block ciphers, called random oracles and ideal ciphers. " But "ideal ciphers", you probably refer to the assumption made in the EKE proofs. But they are not really idealized "block ciphers" - if you use any secure block cipher, say AES, you end up with an EKE that trivially leaks info about the password. There is a tricky interplay with the theoretical proofs (or "provable security") and the practical security; e.g., for more details, see Sec 2.2 in https://eprint.iacr.org/2010/190.pdf. I don't know how you can address this. You may want to explain the "ideal ciphers" more concretely and explicitly, but that is not easy to do without causing even more confusion. My suggestion is to remove this sentence.

Best regards,
Feng