Classic challenge-response based EAP methods (and in particular those supported by strongSwan) require access to the plaintext password to verify the client's response (EAP-MSCHAPv2 is actually an exception, see below). There are password based challenge-response authentication schemes for IKEv2 that do not require storing the plaintext password (based on zero-knowledge password proofs), e.g. AugPAKE (RFC 6628) or PACE (RFC 6631), and some EAP methods, e.g. EAP-EKE (RFC 6124), allow that too, but strongSwan currently does not support any of them.
An alternative is to use EAP-GTC, which transmits a plaintext password that allows the server to verify the password against hashes (e.g. by using PAM). The problem with that is that most clients don't support the method.
For EAP-MSCHAPv2 it is actually possible to store the password as NT-Hash (an MD4 hash of the UTF16-encoded password), see the documentation of the NTLM keyword for ipsec.secrets. But that doesn't increase the security much.