کد:
http://www.carbonwind.net/blog/post/2009/05/30/VPN-Reconnect-in-Windows-7-RC-redux.aspx
Sometime ago we’ve taken a
quick look at the new VPN feature from Windows 7 Beta, Agile VPN aka today as VPN Reconnect or IKEv2.
Now Windows 7 is an RC, and some enhancements to the VPN Reconnect feature were made:
http://blogs.technet.com/rrasblog/ar...-in-w7-rc.aspx
To play with Windows 7 RC and Windows 2008 R2 RC I’ve quickly setup a lab:
- Windows 2008 R2 RC as the RRAS server and the NPS server, a domain member machine(in production it may not be advisable to install the NPS on the RRAS server, as it would require to make this server a domain member, but it’s fine in test lab).
- Windows 2008 R2 RC as the DC and enterprise CA(Active Directory Certificate Services role-the certification authority (CA)- and Certification Authority Web Enrollment-the service that enables the issuing of certificates through a Web browser- were installed, IIS was also installed as a required role service for Certification Authority Web Enrollment)
- and Windows 7 RC as the VPN client, non-domain member. Probably the most visible enhancement for the VPN user, is the validation of the VPN server’s machine certificate by the VPN client for better security. This not only makes the IKEv2 client in Windows 7 RC RFC compliant with section 2.16 of
RFC4306 when EAP authentication methods are used, but also prevents offline dictionary attacks against user credentials when EAP-MSCHAPv2 is used for user authentication, as this validation takes place before user credentials are sent. As has been
noted by Andreas Steffen from
strongSwan, the Windows 7 Beta IKEv2 VPN client, due to the violation of section 2.16 of
RFC4306, was susceptible to offline dictionary attacks against user credentials when EAP-MSCHAPv2 is used for user authentication.
So currently, with EAP methods for user authentication(EAP-MSCHAPv2, PEAP-EAP-MSCHAPv2, EAP-TLS, PEAP-EAP-TLS) or machine authentication with certificates, the IKEv2 VPN client in Windows 7 RC
always, by default, validates the VPN server’s machine certificate(checking the server’s name and the EKU field on that certificate too).
EAP-MSCHAPv2, PEAP-EAP-MSCHAPv2, EAP-TLS, PEAP-EAP-TLS are mutual and key derivation authentication methods.
There is a draft called
An Extension for EAP-Only Authentication in IKEv2(as writing version 06), which, if it passes the draft status, may allow the stronger EAP methods that establish a shared secret key(obviously not EAP-MSCHAPv2 –
) to be used without public key signature based responder authentication with IKEv2, as these stronger EAP methods can “take care” of themselves, being used on wireless LANs and offering mutual authentication and protection against offline dictionary attacks(for passive and active MITMs).
What this validation means ?
First basic stuff: the server’s certificate to be issued by a trusted CA(within the
Trusted Root Certification Authorities the
Computer Certificate Store), to be valid(not expired).
Next, similar with the validation introduced in Windows Vista for the L2TP/IPsec VPN client called
Verify the Name and Usage attributes of the server's certificate, the IKEv2 VPN client in Windows 7 RC checks the name on the VPN server’s certificate and the EKU field on that certificate. But the comparison stops here, as the L2TP/IPsec VPN client has a silly and potentially dangerous behavior in respect with the validation process in certain circumstances, and you cannot disable the new checks on the VPN connection itself for VPN Reconnect like it is possible for the L2TP/IPsec connection.
Note: You can disable the name and EKU checks for IKEv2 VPN connections within Windows 7 RC using the
DisableIKENameEkuCheck registry value, see
Microsoft’s KB 926182(although this is written for L2TP/IPsec and Vista, it works for IKEv2 and Windows 7 RC too). Not only is
highly recommended to
not do so, but if you do so, this appears to be a global value, so you will disable the extra checks for every L2TP/IPsec and IKEv2 VPN connections that are configured on the user’s machine(including installed CMAK profiles, CMAK profiles created on Windows Server 2008 R2 RC).
This reg value only disables the name and EKU checks, the CA that issued the certificate still have to be trusted, and the certificate valid(not expired).
Apparently when you use a CMAK profile and set the
DisableIKENameEkuCheck value to 0 on that profile, according to, as writing the linked Microsoft document, it should disable the EKU check on the server’s certificate. However, not only I could not make it work this setting when using the CMAK on Windows Server 2008 R2 RC and installed the created CMAK profile on Windows 7 RC, the check still applying for the IKEv2 CMAK profile, but instead I’ve successfully applied this value for a CMAK profile using L2TP/IPsec, which disabled both the name and EKU checks for this CMAK profile although that Microsoft document claims this value only applies to IKEv2 connections. The name and EKU checks are enabled by default on CMAK profiles created on Windows Server 2008 R2 RC for IKEv2 and L2TP/IPsec connections.
So what exactly these name and EKU validations mean ?
First, we expect the VPN server’s certificate to be issued by a trusted CA, so we add this CA’s cert within the
Trusted Root Certification Authorities the
Computer Certificate Store on the client(you need admin privileges for that):
Next, say we configure an IKEv2 VPN connection on the client’s machine:
And we specify the host name or IP address of the IKEv2 VPN server on this VPN connection:
If so, the IKEv2 VPN client in Windows 7 RC expects to “find” this host name or IP address on the IKEv2 VPN server’s certificate.
But where appears this name on the IKEv2 VPN server’s certificate ?
Let’s take a look at some certificates.
Name Check
This certificate for example, was issued to the host name we configured on our VPN connection:
If we take a look at the details of this certificate, at the
Subject, we can see the
CN is the same with the host name we configured on our VPN connection:
But this certificate also contains a
Subject Alternative Name, as can be seen the
DNS Name from there is the same host name we configured on our VPN connection:
Another certificate, this one was issued to the IP address configured on our VPN connection:
The
Subject of this certificate has the
CN the same with the IP address configured on our VPN connection(there isn’t a
Subject Alternative Name):
Another certificate:
The
Subject of this certificate has the
CN the same with the host name configured on our VPN connection:
But also there is a
Subject Alternative Name, containing a
DNS Name and an
IP address(both match our VPN server’s address):
Another certificate:
The
Subject of this certificate has the
CN the same with the IP address configured on our VPN connection:
But also there is a
Subject Alternative Name, containing a
DNS Name and an
IP address(both match our VPN server’s address):
So, as we seen, we may have some variations. Likely in practice, it’s not very practical to issue certificates to IP addresses, so probably host names will appear on the IKEv2 VPN server’s certificate.
In order to analyze these variations, as there is little information as currently writing about them versus the checks done by the Windows 7 RC IKEv2 client, I’ve setup in addition to a Windows Server 2008 Enterprise CA, two test OpenSSL CAs, issued over 100 certificates(part of other checks), and made tryouts.
To quickly work with the OpenSSL CAs, I’ve used pretty much the
same CA used
here, modifying a little bit the openssl.cfg this time, to contain the desired X.509 V3 extensions to be added when the CA signs the VPN server’s certificate request:
So to issue a certificate for the server, when I sign the server’s request, I specify the desired extensions to be added to the server’s certificate:
openssl req -config openssl.cfg -new -keyout keys/rras1.key -out reqs/rras1.csr
openssl ca -policy policy_anything -config openssl.cfg -extensions my_server_1 -cert newcerts/ca.pem -in reqs/rras1.csr -keyfile keys/ca.key -out newcerts/rras1.pem
openssl pkcs12 -export -in newcerts/rras1.pem -inkey keys/rras1.key -certfile newcerts/ca.pem -out export/rras1.p12
All of the certificates were issued having the Key Usage and Basic Constraints fields like so:
- Key Usage = Digital Signature, Key Encipherment
- Basic Constraints: Subject Type=End Entity
The results I currently obtained for the IKEv2 server’s name validation on the Windows 7 RC IKEv2 client:
- if the server’s certificate contains only the CN field, this can be either a host name or IP address. If it’s a host name, this host name should be configured as the VPN server’s address on the client’s VPN connection. If it’s an IP address, this IP address should be configured as the VPN server’s address on the client’s VPN connection. The same thing is true for the SSTP VPN connections and the validation of server’s certificate part of the SSL authentication.
- if the server’s certificate contains both CN(set to host name) and SAN(set to DNS Name) fields, then the client verifies the DNS Name from the SAN field. So this DNS name should be configured as the VPN server’s address on the client’s VPN connection. The same thing is true for the SSTP and for L2TP/IPsec VPN connections for the validation of server’s certificate part of the SSL authentication respectively part of the machine(IKE) authentication.
- if the server’s certificate contains both CN(set to host name) and SAN(set to IP address) fields, then the client verifies the host name from the CN field. So this host name should be configured as the VPN server’s address on the client’s VPN connection. The same thing is true for the SSTP and for L2TP/IPsec VPN connections for the validation of server’s certificate part of the SSL authentication respectively part of the machine(IKE) authentication.
- if the server’s certificate contains both CN(set to IP address) and SAN(set to IP address) fields, then the client verifies the IP address from the CN field. So this IP address should be configured as the VPN server’s address on the client’s VPN connection. The same thing is true for the SSTP VPN connections and the validation of server’s certificate part of the SSL authentication.
- if the server’s certificate contains both CN(set to IP address) and SAN(set DNS Name) fields, then the client verifies the DNS Name from the SAN field. So this DNS Name should be configured as the VPN server’s address on the client’s VPN connection. The same thing is true for the SSTP VPN connections and the validation of server’s certificate part of the SSL authentication.
- if the server’s certificate contains both CN(set to host name) and SAN(containing a DNS Name and an IP Address) fields, then the client verifies the DNS Name from the SAN field. So this DNS name should be configured as the VPN server’s address on the client’s VPN connection. The same thing is true for the SSTP and for L2TP/IPsec VPN connections for the validation of server’s certificate part of the SSL authentication respectively part of the machine(IKE) authentication.
- if the server’s certificate contains both CN(set to IP address) and SAN(containing a DNS Name and an IP Address) fields, then the client verifies the DNS Name from the SAN field. So this DNS name should be configured as the VPN server’s address on the client’s VPN connection. The same thing is true for the SSTP and for L2TP/IPsec VPN connections for the validation of server’s certificate part of the SSL authentication respectively part of the machine(IKE) authentication.
Note: The L2TP/IPsec validation process part of IKE(machine) authentication has a “special” behavior in a negative sense, that is, if you configure an IP address as the VPN server’s address on the client’s VPN connection, this, according to my tests, is equivalent to deselecting the
Verify the Name and Usage attributes of the server's certificate option, basically the L2TP/IPsec VPN Windows 7 RC VPN client stops checking the server’s name or the EKU field from the server’s certificate. This is also true for CMAK profiles created on Windows Server 2008 R2 RC.
Note: If the SAN contains multiple DNS Names, then the IKEv2, SSTP and L2TP/IPsec VPN clients from Windows 7 RC are able to “consume” all these entries, that is, any of these DNS names can be configured as the VPN server’s address on the client’s VPN connection(for example, for SSTP, the client's SSL Hello message contains the Extension: server_name with the name of the server configured on the VPN connection).
Note: In practice, if the server’s certificate contains a SAN DNS Name entry it is probable that the DNS Name to be the same with the CN(if the CN is a host name).
This table summarize the currently obtained results for the IKEv2 server’s name validation for the Windows 7 RC IKEv2 client:
Note: The above table also applies for SSTP and L2TP/IPsec VPN connections and the validation done by the Windows 7 RC VPN client over the name from the server’s certificate during the SSL authentication(for SSTP) and respectively IKE authentication(machine authentication for L2TP/IPsec). As an
extra note, remember the L2TP/IPsec VPN client’s behavior when you configure an IP address as the VPN server’s address on the client’s VPN connection.
EKU Field Check
Let’s take a look at some certificates and their EKU fields:
The results I currently obtained for the IKEv2 server’s certificate EKU field validation on the Windows 7 RC IKEv2 client:
Normally, “server” certificates contained certain EKU field values, so I’ve tried to mix these values to see what I will get.
As already said, all of the certificates were issued having the Key Usage and Basic Constraints fields like so:
- Key Usage = Digital Signature, Key Encipherment
- Basic Constraints: Subject Type=End Entity The table bellow summarize the accepted EKU field by the Windows 7 RC IKEv2 VPN client during tests
IP security IKE intermediate = OID: 1.3.6.1.5.5.8.2.2
Server Authentication = OID: 1.3.6.1.5.5.7.3.1
Client Authentication = OID: 1.3.6.1.5.5.7.3.2
No EKU = All Purposes EKU(sort of)
Note: The above table also applies for SSTP and L2TP/IPsec VPN connections and the validation done by the Windows 7 RC VPN client over the server’s certificate EKU field during the SSL authentication(for SSTP) and respectively IKE authentication(machine authentication for L2TP/IPsec), with one exception: the SSTP client accepts the server’s certificate if it contains no EKU field during the SSL authentication. As an
extra note, remember the L2TP/IPsec VPN client’s behavior when you configure an IP address as the VPN server’s address on the client’s VPN connection.
Note: If there are multiple certificates from the same CA, it is recommended that the server’s certificate to contain within the EKU field the
Server Authentication(OID: 1.3.6.1.5.5.7.3.1) +
IP security IKE intermediate(OID: 1.3.6.1.5.5.8.2.2). This will ensure that this certificate from the certificates issued by the same CA will be selected by the VPN server for IKEv2 and L2TP/IPsec connections. Such a certificate can be used for SSTP(SSL authentication), IKEv2 and L2TP/IPsec VPN connections(machine(IKE) authentication)-remember the default stringent CRL check done by SSTP clients, so make sure you have the needed URL for the CRL download on this certificate(the CRL distribution point)-.
As we did
here for the Windows 2003 Enterprise CA, we can have the Windows 2008 Enterprise CA to issue such a certificate, containing within the EKU field the
Server Authentication(OID: 1.3.6.1.5.5.7.3.1) +
IP security IKE intermediate(OID: 1.3.6.1.5.5.8.2.2), and since this certificate can be exportable, you don’t have to make the RRAS server a domain member to request such a certificate(obviously if you request this certificate from another machine, you should not do this from a PC). I won’t repeat the steps here, as they are similar to the ones I already described for the Windows 2003 Enterprise CA, instead I will put a few screen shots of such a certificate template on the Windows 2008 Enterprise CA:
To put the name and EKU checks pieces together
Say we configure an IKEv2 VPN connection on the client’s machine:
And we specify the host name of the IKEv2 VPN server on this VPN connection:
Then, for the IKEv2 VPN client from Windows 7 RC to validate the IKEv2 server’s certificate:
- this certificate has to be valid and issued by a trusted CA(this CA’s cert should be within the
Trusted Root Certification Authorities the
Computer Certificate Store:
- on the
Subject field of the VPN server’s certificate the
CN is the same with the host name we configured on our VPN connection, or if this certificate also contains a
Subject Alternative Name, the
DNS Name from there is the same with the host name we configured on our VPN connection(in practice, if the server’s certificate contains a SAN DNS Name entry it is probable that the DNS Name to be the same with the CN(if the CN is a host name)):
- the EKU field of the VPN server’s certificate should contain at a minimum the
Server Authentication (OID: 1.3.6.1.5.5.7.3.1) entry:
As already said, the certificate from above can be used for SSTP(SSL authentication), IKEv2 and L2TP/IPsec VPN connections(machine(IKE) authentication)-remember the default stringent CRL check done by SSTP clients, so make sure you have the needed URL for the CRL download on this certificate(CRL distribution point)-.
IKEv2 Authentication Methods on Windows 7 RC
- EAP methods for user authentication: EAP-MSCHAPv2, PEAP-EAP-MSCHAPv2, EAP-TLS, PEAP-EAP-TLS(all are mutual and key derivation authentication methods). We already took a quick look at some of these authentication methods
here, so I won’t discuss them again.
- machine authentication with certificates. I want to take a closer look at this authentication method, as currently it is special in a negative way.
Note: Remember that now, the IKEv2 VPN client in Windows 7 RC
always, by default, validates the VPN server’s machine certificate(checking the server’s name and the EKU field on that certificate too).
Machine authentication with certificates
On the Windows 7 RC IKEv2 VPN client:
On the Windows 2008 R2 RC RRAS server, enabling machine authentication with certificates for IKEv2:
We saw above the Windows 7 IKEv2 VPN clients’ requirements for the IKEv2 VPN server’s certificate, but what kind of certificates will accept the Windows 2008 R2 RC IKEv2 VPN server from the IKEv2 VPN clients for machine authentication with certificates ?
Let’s take a look.
The results I currently obtained for the IKEv2 client’s certificate EKU field “validation”(if any) on the Windows 2008 R2 RC IKEv2 server for machine authentication with certificates:
As I did for the IKEv2 VPN server’s certificates, to quickly work with the OpenSSL CAs, I’ve modified a little bit the openssl.cfg, to contain the desired X.509 V3 extensions to be added when the CA signs the VPN client’s certificate request:
So to issue a certificate for a client, when I sign the client’s request, I specify the desired extensions to be added to the client’s certificate:
openssl req -config openssl.cfg -new -keyout keys/client1.key -out reqs/client1.csr
openssl ca -policy policy_anything -config openssl.cfg -extensions my_client_1 -cert newcerts/ca.pem -in reqs/client1.csr -keyfile keys/ca.key -out newcerts/client1.pem
openssl pkcs12 -export -in newcerts/client1.pem -inkey keys/client1.key -certfile newcerts/ca.pem -out export/client1.p12
As already said, all of the certificates were issued having the Key Usage and Basic Constraints fields like so:
- Key Usage = Digital Signature, Key Encipherment
- Basic Constraints: Subject Type=End Entity Any EKU restrictions on the IKEv2 VPN client’s certificate in order to be accepted by the Windows Server 2003 RRAS IKEv2 VPN server ?
Not really. The bellow table presents what I’ve noticed so far:
IP security IKE intermediate = OID: 1.3.6.1.5.5.8.2.2
Server Authentication = OID: 1.3.6.1.5.5.7.3.1
Client Authentication = OID: 1.3.6.1.5.5.7.3.2
Secure Email = OID: 1.3.6.1.5.5.7.3.4
Encrypting File System = OID: 1.3.6.1.4.1.311.10.3.4
No EKU = All Purposes EKU(sort of)
Also various SAN entries(email address, UPN, DNS Name) did not have any effect either, so I won’t discuss them.
Note: For the moment it may be a
wise move to keep the option
Allow machine certificate authentication for IKEv2 deselected on the Windows 2008 R2 RC RRAS server for IKEv2 VPN connections.
Why ?
Because this option appears to put too much pressure on the
Trusted Root Certification Authorities the
Computer Certificate Store on the Windows 2008 R2 RC server.
For example, say we’ve installed on the Windows 2008 R2 RC server a certificate from this CA(Ikev2TestCA) for IKEv2 VPN connections:
And the
Trusted Root Certification Authorities the
Computer Certificate Store on this Windows 2008 R2 RC RRAS server looks like this:
As can be seen the needed CA is there, but also there are other CAs. For example the My Test CA.
During my tests, I was
able to establish an IKEv2 connection using machine authentication with certificates while on the client I had a valid certificate issued by a
different CA than the one that issued the server’s certificate(say Ikev2TestCA), a CA which certificates was within the
Trusted Root Certification Authorities the
Computer Certificate Store on the Windows 2008 R2 RC RRAS server, thus a CA that the RRAS server trusts, for example My Test CA. Therefore, currently, the strength on this authentication method may be based on the “aspect” of the
Trusted Root Certification Authorities the
Computer Certificate Store on the Windows 2008 R2 RC RRAS server, as other layer of authentication will not take place after the machine one, and the Windows 2008 R2 RC RRAS server, for now, apparently, cannot be configured(from the GUI) to perform extra checks over the IKEv2 clients certificate(like CN or SAN field).
The current IKEv2 client from the Windows 7 RC has a similar behavior, that is, it will accept from the server a valid certificate issued by a
different CA than the one that issued its certificate, if it trusts this CA(a CA which certificates was within its
Trusted Root Certification Authorities the
Computer Certificate Store). But the IKEv2 client from the Windows 7 RC, by default, checks the name from the server’s certificate, so even if an attacker manages to steal a valid certificate from a (web) server issued by the needed (public) CA or manages to obtain such a certificate from the needed (public) CA for apparently valid reasons, it is unlikely that this certificate will contained the needed name, so the attacker’s attempt against the Windows 7 IKEv2 client will fail.
So for the moment it may be reasonably safe to use the IKEv2 client from the Windows 7 RC with machine authentication with certificates, but on the Windows 2008 R2 RC RRAS IKEv2 VPN server if you really really want to allow machine authentication with certificates, you should keep an eye on the
Trusted Root Certification Authorities the
Computer Certificate Store on that server.
For example, as a comparison, for L2TP/IPsec connections, this kind of behavior does not appear to be possible: when the L2TP/IPsec “VPN client” presents a valid certificate issued by a different CA than the one that issued the server’s certificate, even if the server trusts that CA, the server will reject the “client’s” IKE credentials. The server will accept the connection if it also has a certificate from this CA within its
Computer Certificate Store/Personal store, certificate that can be used for IKE authentication(and so this certificate will be used by the server for IKE authentication). The Windows 2008 R2 RC RRAS IKEv2 VPN server behaves in a similar fashion for IKEv2 connections, with that possible dangerous exception: it will accept from the IKEv2 VPN client a valid certificate issued by a
different CA than the one that issued its certificate while it does not have a certificate from this different CA within its
Computer Certificate Store/Personal store, it just trusts this CA(this CA’s cert was within its
Trusted Root Certification Authorities the
Computer Certificate Store).
CRL check
The Windows 7 RC IKEv2 VPN client or the Windows 2008 RRAS R2 RC server(for IKEv2 machine authentication with certificates) appear to be able to verify the CRL if I manually import the CRL within the
Certificates Computer Store,
Intermediate Certificates Authorities(the L2TP/IPsec client does not do that).
The
netsh advfirewall set global ipsec strongcrlcheck with 0, 1 or 2 values seems to not have any impact or so.
It looks that by default, the Windows 7 RC IKEv2 VPN client or the Windows 2008 RRAS R2 RC server(for IKEv2 machine authentication with certificates) do not attempt to download and check the CRL.
Note: But, for example the SSTP client, by default does the CRL check, so I've published the CRL on a web site, and the SSTP client downloads it and it senses that the VPN's server certificate was revoked. Then, on the same Windows 7 RC machine, I can open without any problems an IKEv2 connection to the same VPN server, VPN server using the same revoked certificate, even if apparently, the default behavior is to have the downloaded CRL cached. If the same VPN server is used for IKEv2 and SSTP connections, with the same certificate, the default configuration in respect with CRL checking of the Windows 7 RC IKEv2 client may introduce a potential issue if a client is configured to use both, say to try IKEv2 and only fallback to SSTP if it cannot establish an IKEv2 connection, and vice-versa: to try SSTP first and fallback to IKEv2 if it cannot establish a SSTP connection. So, an attacker, that maybe somehow managed to compromise the server’s private key(and so the server’s certificate got revoked), may take advantage of this aspect, and trick the user into establishing an IKEv2 connection with him instead of the server, but this attack will fail if the EAP authentication methods are used, unless EAP-MSCHAPv2 is used and first the attacker mounts an active MITM to obtain the “data” that will allow him to mount an offline dictionary attack against the user’s credentials, and if he succeeds, he will have access to the user’s credentials. If machine authentication with certificates is used, the attacker will have the VPN client successfully connected to him instead of to the real VPN server. As said above, for SSTP connections, after the download, the CRL is cached until it
may be no longer valid, I’ve managed to
refresh the CRL cache using the
certutil -setreg chain\ChainCacheResyncFiletime @now command(requires admin credentials). In practice, the user may attempt to use IKEv2 first, due to the mobility feature, and if it does not work then use SSTP. If SSTP and IKEv2 are used on the same RRAS server, for convenience there is a chance that the same certificate to be used for IKEv2 and SSTP connection. In that case the default stringent CRL check of the SSTP client may be pretty much useless, so the IKEv2 client should, by default, at least attempt to download the CRL and verify the server’s certificate against it, especially when there are fallback methods from protocols that perform the CRL check by default(SSTP) to ones that do not perform the CRL check(IKEv2).