Is strongSwan eap-mschapv2 authentication secure vs using certs?

Question

What level of encryption is used during the authentication part of the connection?

Here’s a sample /etc/ipsec.conf configuration.

config setup
    charondebug="ike 1, knl 1, cfg 0"
    uniqueids=no

conn ikev2
    auto=add
    compress=no
    type=tunnel
    keyexchange=ikev2
    fragmentation=yes
    forceencaps=yes
    ike=aes256gcm16-sha384-modp3072!
    esp=aes256gcm16-sha384-modp3072!
    dpdaction=clear
    dpddelay=300s
    rekey=no
    left=%any
    leftid=@example.com
    leftcert=/etc/ipsec.d/certs/vpn-server-cert.pem
    leftsendcert=always
    leftsubnet=0.0.0.0/0
    right=%any
    rightid=%any
    rightauth=eap-mschapv2
    rightdns=1.1.1.1,1.0.0.1
    rightsourceip=10.0.2.1/24
    rightsendcert=never
    eap_identity=%identity

The encryption of IKEv2 messages has nothing to do with the authentication method. What exactly is it you want to know?

I’m trying to understand how safe the credentials (and later shared secret) are while in transit to the server. In the case of HTTPS, this is very well documented. TLS uses Diffie-Hellman (an asymmetric key algorithm) to generate a shared secret that is then used to establish a channel protected by symmetric key cryptography derived from that shared secret. The encryption of that channel is usually publicly disclosed. For example, on YouTube.com, it’s TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (128 bit AES-GCM encryption with a 256 bit SHA2 integrity algorithm). I’m fairly new to cryptography so hopefully the above is accurate. Now, I can’t find an equivalent to the above spec in the context of eap-mschapv2 using openSwan. I expect something similar is going on, but I would love to make sure I fully understand the protocol.

Added some links in case others want to learn more about cryptography.

The encryption of IKEv2 messages has nothing to do with the authentication method. What exactly is it you want to know? — ecdsa, Mar 12 '19 at 07:39
Thanks for the follow up. Added more context to the question. — sunknudsen, Mar 12 '19 at 12:58

score 0 · Answer 1 · edited Oct 07 '21 at 08:14

The basics of IKEv2 are quite similar to TLS. In the first two messages (IKE_SA_INIT) the two peers negotiate a set of algorithms (one of them is a Diffie-Hellman group) and exchange DH public keys. They then derive a shared secret and the messages that follow (IKE_AUTH, INFORMATIONAL, CREATE_CHILD_SA) are exchanged encrypted and integrity protected. The IKE_AUTH messages contain authentication data (identities, signatures, certificates, EAP payloads) and information about the first IPsec/Child SA (such as algorithms and traffic selectors).

When using authentication methods like EAP-MSCHAPv2, which are potentially based on weak user passwords and prone to active attacks by a man-in-the-middle, it's important to use a strong authentication method for the responder (e.g. public key authentication) and to verify the responder's identity before any (hashed) secrets are transmitted. For example, a client could make sure the domain name or IP address is confirmed by the responder's certificate, which, of course, has to be valid and trusted.

Unlike TLS, IKEv2 does not use predefined cipher suites. Algorithms of different transform types (encryption, integrity, PRF, DH) can be combined relatively freely (there are some restrictions, e.g. proposals with AEAD algorithms, like AES-GCM, can't contain integrity algorithms). As mentioned above, these parameters for the IKE_SA are transmitted openly in the IKE_SA_INIT messages. However, the parameters for the CHILD_SAs are only transmitted encrypted (note that there is no separate DH exchange for the first CHILD_SA that's created with the IKE_SA, only keys for later CHILD_SAs can optionally be based on a DH exchange, otherwise, they are derived from the IKE keys).

The complete IKEv2 protocol description can be found in RFC 7296.

Is strongSwan eap-mschapv2 authentication secure vs using certs?

1 Answers1