Bug 12005

Summary:	Windows Roadwarrior Connections Cannot use ECP due to Certificate Type
Product:	IPFire	Reporter:	Tom Rymes <tomvend>
Component:	---	Assignee:	Assigned to nobody - feel free to grab it and work on it <nobody>
Status:	NEW ---	QA Contact:
Severity:	- Unknown -
Priority:	- Unknown -	CC:	michael.tremer, peter.mueller
Version:	2
Hardware:	unspecified
OS:	Unspecified
Bug Depends on:
Bug Blocks:	11618

Description Tom Rymes 2019-02-18 17:26:02 UTC

Windows Roadwarrior IPSec connections can be made to work if you use the default Windows encryption settings, but those are weak (SHA1 and MODP1024). So, I was trying to use PowerShell to enable stronger encryption, including AES-GCM and ECP. These are the two commands I was using, first to add the connection, and then to modify the encryption settings:

Add-VpnConnection -name "Rymes - Concord IKEv2" -ServerAddress "rymes.com" -TunnelType IKEv2 -AuthenticationMethod MachineCertificate -EncryptionLevel Required
  Set-VpnConnectionIPsecConfiguration -ConnectionName "Rymes - Concord IKEv2" -AuthenticationTransformConstants GCMAES128 -CipherTransformConstants GCMAES128 -EncryptionMethod AES128 -IntegrityCheckMethod SHA384 -DHGroup ECP256 -PfsGroup ECP256  -Force

Unfortunately, each and every time I ran the command to enable the stronger encryption, Windows complained that "IKE failed to find a valid machine certificate." Some sleuthing around brought me to this link, which indicates that Windows requires an ECDSA certificate for use with ECP (see the last comment):

https://social.technet.microsoft.com/Forums/ie/en-US/b1d8b473-b05d-413b-8afe-2eeab00d263a/ike-failed-to-find-valid-machine-certificate?forum=win10itprosecurity

Based on this, I then re-ran the second command from above, but modified to swap from ECP256 to MODP2048:

Set-VpnConnectionIPsecConfiguration -ConnectionName "Rymes - Concord IKEv2" -AuthenticationTransformConstants GCMAES128 -CipherTransformConstants GCMAES128 -EncryptionMethod AES128 -IntegrityCheckMethod SHA384 -DHGroup Group14 -PfsGroup PFS2048  -Force

With those settings, the tunnel works quite well. I am not certain if Windows allows an ECDSA cert to be used with non-ECP encryption, but if it does, perhaps it makes sense to change the certificates to work with ECP? Unfortunately, I am not really certain where to start testing this.

Comment 1 Michael Tremer 2019-02-19 16:30:31 UTC

Interesting, but actually the algorithm of the certificate does not have anything to do with the IKE handshake. It would make sense to use the modern EC cryptography throughout the whole system, but I do not see any technical reason why this would be a requirement.

However, I am not sure what you are asking for right now. I would say, keep using MODP4096 or higher if possible. This won't have any disadvantage for the performance of the tunnel.

Comment 2 Tom Rymes 2019-02-19 18:43:04 UTC

Michael, while the RFC does not require it, the Windows implementation does require it. This is actually a big deal, as the only group types that the built-in Windows IKE client supports at present are:

Group1
Group2
Group14
ECP256
ECP384
Group24

Of those, only Group14, ECP256, and ECP384 are considered secure, and since it is not currently possible to use ECP256 or ECP384 with IPFire due to the certificate algorithm, that means IPFire users on Windows are currently limited to MODP2048 (Group14).

I do not know if the actual IPFire Host and root certs need modifying, or just the certificate for the connection itself.

Comment 3 Tom Rymes 2021-04-14 13:09:49 UTC

Rereading the linked comment, it appears that this may be more complex than initially acknowledged: "The ECDSA key length of the certificate used has to match the DH group length."

I'm thinking that this means that the connection parameters need to be specified before the key is generated, and that it will only work with one specific DH Group.