Is it safe to use single-block AES for mutual authentication? I read the question Symmetric mutual authentication with client using a derived secret and its answer which, if I'm not mistaken, assert that it should be safe to use the proposed protocol for mutual authentication between a client A and a server B as follows:


At commissioning, each client A gets a unique identifier $i_A$ and a derived key $k_A$ which is generated from the secret $s$ by HMAC($s$, $i_A$).
To authenticate B, A sends $i_A$ and a random nonce $c_A$ to B.
B calculates the expected derived key $k_A'$ = HMAC($s$, $i_A$) and replies with $r_B$ = HMAC($k_A'$, $c_A$) as well as a random nonce $c_B$.
A can now authenticate B by comparing $r_B$ to HMAC($k_A$, $c_A$).
To enable authentication of A with B, A sends $r_A$ = HMAC($k_A$, $c_B$) to B.
Now B can authenticate A by comparing $r_A$ to HMAC($k_A'$, $c_B$).


Now I would like to use a single-block AES128 for the HMAC calculation in this scheme such that every message item (namely, $i_A$, $c_A$, $r_B$, $c_B$, and $r_A$) between A and B is exactly 128 bits long and the AES128 is used in ECB mode.

Given this answer to a question about AES Message Authentication Vulnerability, I think this should be safe?
If we assume that AES is a pseudorandom permutation (which is a standard model for block ciphers), then AES can replace the HMAC in your construction. Be aware, this only works because you have a fixed message length, i.e. the protocol must not accept nonces $&gt; 128$bit. 

Besides, I guess you are aware of this but you have a shared secret key among all users. Hence, your protocol does not authenticate a specific user. Instead, the protocol only verifies that the other side is a user that knows the secret key.

The reason is that any user knowing $s$ can compute $k_A = \text{HMAC}(s, i_A)$. Even if $i_A$ is not made public explicitly. Everyone that communicated once with $A$ will know $i_A$. Besides, this would mean that you have to protect $i_A$ while being transmitted and finally this has the problem that the authenticity of $i_A$ must be verifiable. Otherwise, an attacker could use an arbitrary value as $i_A$. 

If you only want to get a proof of membership, this protocol works but is overly complicated as you can omit the key derivation step. You can simply use $\text{HMAC}(s,nonce)$... 

As you included the identifiers I guess you wanted something stronger than a proof of membership. In this case, you should switch to some standard mechanism like TLS with a PKI. You will not really be able to omit public key crypto in this setting. The only (impractical) solution in the symmetric setting would be the establishment of one key for each pair of users.