Friday, January 2, 2015

Proposal selection for AES & fortigate

1st off , have a happy 2015 year.

This will be a interesting year for security vendors. It should be a great year to say the least. Mobility and Cloud security services will be the biggest thing watched for this year imho.


Within IPSEC vpn-tunnels & with the peers configured for multiple proposals, how can you really tell what proposal was used for the negotiated  ipsec-SAs? Will I will show demonstrate a simple means on how you can determine what was finally negotiated , by just looking at the   show vpn tunnel list output.

Take this vpn tunnel configured for aes 128/192/256 on a fortigate 100D.

So  this interface vpn has 3 possible choices configured for the remote-peer . The remote peer ( cisco ASA )  will be configure  for aes256 aes192 and finally aes128 and I will show how the diag cmd output will reflect what was  negotiated with this fortigate.  This helps you in determining what the remote-firewall administrator actually configured & without the need to bother the remote firewall administrator.

Take a look at the key length in the following snapshot for  the final ipsec-SAs.

( look at the red underlines and key-lengths )

 Yes it's that simple. Key-length  32/24/16 reflects AES256/192/128 respectively for AES encryption.

So now you can determine what was used between peers that have multiple proposal configured.  What I found out with cisco products. The strongest cipher is not always picked, the ordering of the proposals & first matched is what will determine what's  finally selected.

take a typical cisco ASA crypto map configuration;

crypto map EXTERNAL_map0 10 set ikev1 transform-set ESP-AES-128-SHA ESP-AES-256-SHA ESP-AES-192-SHA

AES128 will always be selected over aes256 or aes192, due to the ordering of the proposals. So if you wanted to ensure the  highest probability, arrange the ordering to match your requirements. The same goes for hash-authentication  method (  md5 vrs sha1 sha256 etc... ).

So if you run any debug and see you SAs failing remember the multi=proposals & always evaluate the pecking order.

Ken Felix
NSE ( Network Security Expert) and Route/Switching Engineer.
kfelix  -----a----t---- socpuppets ---dot---com

     ^      ^
=(  @  @ )=
        /  \

No comments:

Post a Comment