In authentication you often come accross zero-knowledge password proof (ZKPP). EAP itself is a rather generic framework and it might involve revealing the identity of the client for instance to transfer it to the next layer of authentication such as RADIUS.
PACE (BSI TR-03110) is one example of ZKPP protocols used for authentication. EAP-SPEKE is another.
The security of the key relies on the use of only parts of the key in the exchange between the client and the server. The client offers a nonce encrypted with the key to the server. Therefore a rogue server receives a encrypted nonce and holds its plaintext version. This is not zero-knowledge, since in a finite time a rogue server might accumulate enough information to break the AES-128 encryption.
Hence EAP-PSK may not be considered an example of zero-knowledge password proof, though other proposed authentication schemes based on EAP such as EAP-SPEKE have this property.
To illustrate the problematic part of the EAP-PSK protocol consider the message flow as presented in RFC 4764.
The first message is sent by the server to the peer to:
* Send a 16-byte random challenge (RAND_S). RAND_S was called RA
in Section 3.2
* State its identity (ID_S). ID_S was denoted by A in
Section 3.2.
o The second message is sent by the peer to the server to:
* Send another 16-byte random challenge (RAND_P). RAND_P was
called RB in Section 3.2
* State its identity (ID_P). ID_P was denoted by B in
Section 3.2.
* Authenticate to the server by proving that it is able to
compute a particular MAC (MAC_P), which is a function of the
two challenges and AK:
MAC_P = CMAC-AES-128(AK, ID_P||ID_S||RAND_S||RAND_P)
o The third message is sent by the server to the peer to:
* Authenticate to the peer by proving that it is able to compute
another MAC (MAC_S), which is a function of the peer's
challenge and AK:
MAC_S = CMAC-AES-128(AK, ID_S||RAND_P)
Here AK is a part of the secret key that is used at this stage and may be revealed to the rogue server that is able to decrypt AES-128.