By now all of you must have heard about the formal release of W7 RC. In case you don’t have it already here is the link from where you can download the RC bits
In RC the RAS team has made some enhancements to the VPN Reconnect feature. Here are the details of the change and some recommendations on deployment.
1. Change in method used to calculate MSK
Details of Enhancement
In accordance with the IKEv2 RFC, in EAP authentication, the shared secret generated is used by the IKEv2 connection initiator and responder to generate AUTH payloads for EAP (see section 2.16 in RFC 4306 for more details). This shared secret is called the MSK.
In W7 RC we have changed the method used to calculate the MSK for EAP-MSCHAPv2 . The new method has been documented on MSDN and can be found at http://msdn.microsoft.com/en-us/library/cc224635(PROT.13).aspx
The MSK calculation method used in RC is different from that in Beta and implementation of the new method involved changes on both the client and server. Hence RC build is required on both client and server to successfully setup an IKEv2 connection using EAP-MSCHAPv2 authentication. IKEv2 connections between Beta client and RC server and vice versa will fail if EAP-MSCHAPv2 authentication is used
Vendors implementing EAP-MACHAPv2 for IKEv2 MUST derive the MSK as specified in http://msdn.microsoft.com/en-us/library/cc224635(PROT.13).aspx
2. Validation of VPN server machine certificate by client for better security
We have made a change to IKEv2 on the client side to start validating the machine certificate sent by the VPN server that it is connecting to. This change helps prevent possible MITM and dictionary attacks thereby strengthening IKEv2 security. It is not possible to disable these checks on the client
· Certificate installed on the server should have the following values for certain important fields in the certificate. Corresponding root certificates should be installed on the client
- Certificate Name (CN): This field should contain the name or IP address of the server (depending on which one is being used by the client) that is
being validated by the client.
- EKU: Should be a ‘Server Authentication’ certificate. If there are multiple certificates present in the machine store of the server then additionally
specifying ‘IP security IKE intermediate’ (OID: 22.214.171.124.126.96.36.199.2) in the EKU of the cert will ensure that the cert is picked over other certificates in the
store. The latter is highly recommended
· If you are running SSTP already in your setup then the same server machine certificate can be used for both SSTP and IKEv2 but the certificate should satisfy the criteria mentioned above. Since root certs required for SSTP are already present on the client no client side changes are needed in this case
If right certificate is not configured on IKEv2 server or if correct trusted root certificate is not present on the client then IKEv2 connections might fail. Error code seen
is 13801 which indicates that validation of the server certificate is failing. If multi-tunnel VPN strategy is used, then a fall back to the next tunnel will happen and the
VPN connection will go through. For e.g. for ‘Automatic’ tunnel type fall back will happen to SSTP