Can AKE keys provide PFS Can the channel keys that are derived from an AKE (authenticated key exchange) protocol be used in a secure channel that wants to have perfect forward secrecy?

If the goal of AKE is to establish channel keys and provide authentication of the entities at the same time, then this implies that the long term key used for authentication is contributing to the shared channel key.

But if we want PFS, then the long term key should not be contributing to the channel key.

Meaning that if we want PFS you can not rely on AKE, but you should use a key establishment protocol that does not provide authentication and just authenticate the transcript afterwards.

So my question is: if we say that we use AKE to create our channel keys, does that mean that by definition of AKE we can no longer claim PFS of our secure channel?
In fact, if you use the first described password authenticated key exchange protocol (Encrypted Key Exchange, by Bellovin and Merrit, in 1992), it is quite clear that you get forward secrecy for free. Roughly put, this is a Diffie-Hellman key exchange with ephemeral keys, whose messages are then symmetrically encrypted, using the shared secret (the password) as key (this symmetric encryption must be such that decrypting with the wrong password still yields syntactically valid DH public keys). Even if an attacker learns the password, all he can do is to recover the inner DH exchange, that used ephemeral keys.

This is in fact a general property for all PAKE. The point of a PAKE is that both parties have only one long-term secret (the password), so everything else is ephemeral; moreover, since that secret has low entropy and is thus in range of exhaustive search (a "dictionary attack"), a strong PAKE must be such that whenever the attacker tries a potential password, he can never know whether he got the right one. This implies, in particular, that even if the password is revealed after the fact, the key exchange itself must remain impregnable. That password being the only non-ephemeral secret, the property of forward secrecy follows.

Or, said in the other direction: if a PAKE protocol is not forward-secure, and obtaining a copy of the shared password allows unraveling the subsequent data encryption, then that mechanism can be used to "test" passwords (run the break-the-encryption attack for each potential password, see if that yields a key which makes sense); in that case, the PAKE protocol does not fulfill its PAKE properties.

To sum up: contrary to what you fear, you will get forward secrecy because you use a PAKE protocol.

(Of course either party can still do something stupid and, for instance, save the secret key resulting from the PAKE into a file, which then breaks forward secrecy.)