ads

Style6

Style3[OneLeft]

Style3[OneRight]

Style4

Style5[ImagesOnly]

Style2

WIN 10 Secure IKEv2 VPN

How To:

Secure Windows 10 IKEv2 VPNs.  Improve IKEv2 security strength  -the easy way.  Enable hidden support for advanced cryptographic algorithms on Windows clients.

Problem:

The default Windows implementation of IPsec is highly vulnerable to Man-in-the-Middle (MITM) attacks.  It uses depreciated security algorithms and should not be trusted.  DO NOT use IKEv2 or L2TP/IPsec with Windows clients unless it negotiates secure cryptographic algorithms.

Solution:

A simple registry change enables secure IPsec.  This easy fix provides a respectable DH14-AES256-SHA256 negotiation.  Alternately, use PowerShell to enable even stronger security.  Both solutions provide a cryptographic baseline that ensures secure communications.

Background:

The VPN server confirms vulnerable  security:  3DES, SHA1, and DH2 -all bad.  Confirm active MM cryptographic algorithms with PowerShell:


PS C:\Users\stevenuwm> Get-NetIPsecMainMode
 
 Name                                : 51
 LocalEndpoint                       : x.x.x.x
 RemoteEndpoint                      : x.x.x.x
 LocalFirstId.AuthenticationMethod   : Certificate
 CipherAlgorithm                     : AES256
 HashAlgorithm                       : SHA1
 KeyModule                           : IkeV2
 CipherAlgorithm                     : DES3
 HashAlgorithm                       : SHA1
 GroupId                             : DH2
 KeyModule                           : IkeV1

3DES?  SHA1?  DH2?  Good thing we checked!

Security Guidelines:

The Internet Engineering Task Force (IETF) provides guidelines for securing IKEv2. (RFC4307 BIS-13).  These standards are based on key management security strength.  Do not use any cryptographic algorithm with less than 103-bits of security:  http://www.stevenjordan.net/2016/09/ipsec-security-levels.html.

Key Management Tips:

  • DH Group-2 SHOULD NOT be used.
  • Use DH Group-14.    
  • Use RSA-3096 certificates.
  • Use AES128 encryption.
  • SHA1 (Main-Mode) can be used.  SHA256 is a better alternative.
  • Use HMAC-SHA1.  It is not the same thing as SHA1
Theses tips serve as baseline security -a starting point.

Registry Solution:  

Create a registry key that enforces modern cipher and transform sets.

STEP 1:  Edit Registry or create GPO:

HKLM\SYSTEM\CurrentControlSet\Services\RasMan\Parameters\
STEP 2: Create new DWORD value:
NegotiateDH2048_AES256
STEP 3:  Modify DWORD value:

Table 2:  NegotiateDH2048_AES256 Values.
Value IKEv2 Security L2TP\IPsec (i.e., IKEv1)
None MM: IKE-DH2-3DES-SHA1
QM: ESP-3DES-SHA1(HMAC)
MM: IKE-DH2-3DES-SHA1
QM: ESP-3DES-SHA1(HMAC)
0 MM: IKE-DH2-3DES-SHA1
QM: ESP-3DES-SHA1(HMAC)
MM: IKE-DH2-3DES-SHA1
QM: ESP-3DES-SHA1(HMAC)
1 MM: IKE-DH14-AES256- SHA1
QM: AES256-SHA1(HMAC)
MM: DH14-SHA1-AES128
QM: AES128-SHA1
2 M: IKE-DH14-AES256- SHA256
QM: AES256-SHA1(HMAC)
MM: DH14-SHA1-AES128
QM: AES128-SHA1
   Note:  This security target assumes the VPN server supports DH14-AES256-SHA256.
   No value, or value of 0 uses client defaults -weak encryption and hash! 
   VPN client security MUST be set to maximum strength encryption in it property settings. 

   Example:

   Registry sub-key:
  HKLM\SYSTEM\CurrentControlSet\Services\RasMan\Parameters\
   Registry entry:
  NegotiateDH2048_AES256 Data Type:  Reg_DWORD
  
Value:  2

Windows VPN Server:

IPsec requires common cryptographic algorithms.  Windows 2012 IPsec is every bit as insecure as Windows 10.  Therefore we'll need to make adjustments to the server as well.

The above registry fix is recommended for Windows clients.  However it can work with Windows 2012 RRAS VPN server -with one catch.  It does improve security strength for DH and encryption, It does not improve the security strength for the hashing:

     DH14-AES128-SHA1.

This registry change meets the bare-minimum IETF recommendations for IKEv2.  It's better than before -but we can do better.

Should we trust SHA1?  It's probably OK for now.  On the other hand, Google Chrome and Microsoft IE no longer support certificates that use SHA1.  Weak hashes (e.g., SHA1) are vulnerable to sophisticated off-line attacks  In other words, an attacker can steal your identity! (Entrust 2014).

We're not talking about credit scores.  We're talking about digital identity and authentication.  Fake RSA signatures that authenticate to the VPN, email, etc.  Yikes!

Why risk SHA1 when we can easily implement SHA256?  There are other simple (yet hard to find) methods that improve IKEv2 security strength  on Windows servers.  We can do better:  http://www.stevenjordan.net/2016/09/harden-rras-ikev2.html

PowerShell

The Windows 10 registry fix is the path of least resistance.   However, PowerShell supports a wider range of cryptography algorithms.  N.B., These IPsec configurations are not available from the Windows GUI or registry.

Step 1:  Configure new IKEv2 VPN.

Create the new VPN connection with PowerShell.  Do not create the VPN connection with the GUI.
However, it's OK to use the GUI to edit authentication attributes after PowerShell creates the connection .

Add-VpnConnection -Name "IKEv2-VPN" -ServerAddress "vpn.stevenjordan.net" -TunnelType IKEv2 -AuthenticationMethod MachineCertificate

Step 2:  Configure an acceptable level of cryptography.

Set-VpnConnectionIPsecConfiguration -ConnectionName "IKE-SMJ" -AuthenticationTransformConstants None -CipherTransformConstants AES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -DHGroup Group14 -PfsGroup None -PassThru -AllUserConnection

AuthenticationTransformConstants : None

CipherTransformConstants         : AES256

DHGroup                          : Group14

IntegrityCheckMethod             : SHA256

PfsGroup                         : None

EncryptionMethod                 : AES256

PfsGroup                         : None

Additional Thoughts:

Why does Microsoft cripple IPsec VPN security by default?  Is it support for legacy devices?  Are there more nefarious reasons (e.g., Eric Snowden)?  Does it nudge folks away from IPsec toward SSTP?  If so it's as good of a reason as any!  In fact, I recommend SSTP for most situations.  The only problem with SSTP is that it's limited to Windows and Android clients.  Direct Access is another great VPN solution (that incorporates Windows IPsec).  

Conclusion:

In the end, NegotiateDH20148_AES256, is a Band-Aid for its default (i.e., broken) Windows IKEv2 VPN.   It provides bare-minimum IPsec security strength that should already be enabled by default. The registry fix may not be the best option but it's quick and it's easy.

On the other hand, Windows 10 supports stronger IKEv2 security strength via PowerShell commands.  By default, Windows IPsec VPN is not secure -it should not be trusted.  However, these VPNs can provide excellent security with a few simple changes.

That's it!

References:

http://www.stevenjordan.net/2016/09/harden-rras-ikev2.html
http://www.stevenjordan.net/2016/09/harden-rras-ikev2.html
Microsoft Windows 8 Windows Server 2-12 Supplemental Admin Guidance IPsec VPN Clien.docx. https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis-00
http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-3
https://technet.microsoft.com/en-us/library/jj613766(v=ws.11).aspx
https://technet.microsoft.com/library/9e500d0b-ad09-463e-a5b7-e2986476bc58(v=wps.630).aspx
https://technet.microsoft.com/en-us/library/dn262642(v=wps.630).aspx

IPsec Security Levels

What are security bits?

VPN Problem:  

What is the most secure VPN cryptographic algorithm?   What is the best-practice for choosing IPsec security strength?

Solution:

Use Key Management methodology to determine IPsec security strength.

Key Management

The National Institute of Standards and Technology (NIST) publishes up-to-date guidance for choosing appropriate VPN ciphers.  It uses Key Management methodology to rate the effectiveness of different cryptographic algorithms.

Security Strength 

Security strength is a Key Management assessment that estimates the effectiveness of cryptographic algorithms against known attacks over time.  New or improved attacks may affect these equivalencies in the future.

Security strength uses bits-of-security to represent cipher strength.  Security-bits are not the same thing as key-length bits.  For example, a 1024-bit RSA certificate provides 80-bits of security.

In addition, different security algorithms may share common security strength levels (Table 1).  It's best practice to match similar security strength when working with different sets of cryptography algorithms (e.g., transfer-sets and cipher-sets).  Consider, one depreciated algorithm can compromise the entire security target.

IPsec Cipher Assessment

Use Key Management security strength assessments to implement secure IKEv2 and L2TP/IPsec VPN.  Consider how security-bits represents cipher strength:

  • 89 security-bits are vulnerable to known attacks.
  • 103 security-bits are not vulnerable to known attacks -for now.  Status forecast to depreciate in the near-future (may be months or years).
  • 128 security-bits are not vulnerable to known attacks.  Status forecast remains secure for near-future.
  • 192 security-bits are not vulnerable to known attacks.  Status forecast remains secure for long-term future (years).
Cisco dubs 192-bit security as Next Generation (NG).  NG security strength includes DH-19 that uses 256-bit key with elliptic-curve algorithms.  It provides a 1024-bit key exchange and does not require intensive hardware resources -wow!




Table 1
VPN Security Strength 

Security Strength DH RSA IKE Encryption IKE Hash ESP Encryption ESP HMAC Hash Assessment***
80-bit 5 1024 AES-128 SHA1 AES-128 SHA1 Bad
89-bit 5 2048 AES-128 SHA1
SHA256
AES-128 SHA1
SHA256
Bad
103-bit 14 2048 AES-128 SHA1
SHA256
AES-128 SHA1
SHA256
Good
128-bit 15 3072 AES-128 SHA256
SHA384
AES-128 SHA1
SHA256
Better
192-bit* 16 4096** AES-256 SHA256**
SHA384
AES-256 SHA1
SHA256**
Best

Note:  DH-EC not included in this table -for simplicity.  DH-EC provides for a 1024 or 7068 security bit key exchange.
*192-bit security level requires 7680-bit RSA. Some systems do not support 7680-bit RSA.
 **Security level mismatch. 4096-RSA security-strength is 140-bit (i.e., not 192-bit). This mismatch impacts all security levels.
***The assessment column is not official NIST Key Management.  It is this author's independent qualitative interpretation derived from NIST Key Management.


Table 2
Diffie-Hellmand (DH) Security Strength Levels.

DH Group DH Key Security Strength
(i.e., Bits of Security)
DH5 1536 bits 89 bits
DH14 2048 bits 103 bits
DH15 3072-bit 128 bits
DH16 4096 bit 192 bits
DH19 (ECP) 256-bit (ECP) 1024
DH20 (ECP) 384-bit ECP 7680




Table 3
Encryption Security Strength Levels

AES AES Key Security Strength
(i.e., Bits of Security)
AES-128 128 128
AES-256 256 256


Table 4
RSA Security Strength

Certificate RSA Key Symmetric Key
RSA 1024-bit 80-bit
RSA 2048-bit 112-bit
RSA 3072-bit 128-bit
RSA 4096-bit 140-bits*
RSA 15360 -bit* 256-bit**

 *No formal recommendation for Symmetric key.
RSA 4096 offers marginal 28bit increase for symmetric key.
**15360 is not usable. Therefore, use RSA 3072-bit key.


Table 5
Hash Security Strength

Hash Hash-only HMAC Security Strength
(i.e., Bits of Security)
SHA SHA-1
SHA-256
SHA-512
SHA-1
SHA-256
SHA-512
80
SHA SHA256
SHA384
SHA256
SHA-1
SHA-256
SHA-512
112
SHA SHA256
SHA384
SHA256
SHA-1
SHA256
SHA-512
128
SHA SHA-384
SHA-512
SHA-256
SHA-384
SHA-512
192
SHA SHA512 SHA-256
SHA-384
SHA-512
SHA256

Note: Hash security level determined by algorithm,
scheme or application and by the minimum security-strength provided.


That's it!


References:
https://www.nist.gov/
http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf
http://infosecurity.ch/20100926/not-every-elliptic-curve-is-the-same-trough-on-ecc-security/
http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf





NLA Default Location

How to set the default location for NLA.

Problem: 

 Users do not have Internet access after connecting to wireless networks. Network Location Awareness (NLA) appears to hang on identifying network.

Additionally, defining the default location is important because it directly impacts firewall rules. It’s not prudent policy to open client ports on an untrusted hotspot.

 Solution: 

 Use Group Policy to pre-define the default network location for unidentified AND identifying networks.
GPO: Computer Configuration → Policies →Windows Settings → Security Settings →Network List Manager Policies → (a) Unidentified Networks and (b) Identifying Networks.


Network Name:  

Choose either the Private or Public network: 



  • Outbound:  Most outbound traffic permitted.
  • Inbound:  Unsolicited SMB (e.g., file and print sharing). 



  • Outbound:  Most outbound traffic permitted.  No SMB traffic permitted.
  • Inbound:  No unsolicited traffic permitted.
N.B., Err on the side of caution.  Consider, do we really want unidentified networks to permit unsolicited traffic?  The Private network location invites common SMB replay attacks that steal credentials.  Further adjust client firewall rules to align with your organization’s security policies.

That’s It!