Copyright (c) 2005 Philippe Sultan, INRIA.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
Texts. A copy of the license is included in the section entitled "GNU
Free Documentation License".
In this document, we will describe a way to circumvent the VPN PSK
(Pre-Shared-Key) + XAUTH vulnerability when using a Cisco IOS router
as a VPN server (eg. without Hybrid Authentication). The vulnerability
is described in detail here :
http://www.cisco.com/en/US/tech/tk583/tk372/technologies_security_notice09186a0080215981.html
The XAUTH authentication system is very useful for end users and
flexible for administrators.
However,
When the XAUTH authentication method relies on PSK for an ISAKMP
phase I authentication, only the VPN client is asked
for his credentials, which are eventually checked against some
RADIUS database for example.
Thus, the authentication of the server side only relies on the PSK,
eg. if one fake server is able to present the PSK, and to spoof the
network address of the real VPN server, the VPN client will wrongly
trust the connection.
An example of such an attack is given here :
http://www-rocq.inria.fr/who/Philippe.Sultan/vpn/spoofed_vpn_server.html
In order to strengthen the authentication of the server, we will use
certificates. This implies the need for a CA (Certification Authority),
able to sign and distribute certificates, as well as private keys.
The first part of this document is dedicated to the setup of such CA,
using the openssl commands.
For more information regarding these commands, please refer to :
Please notice that setting up a whole PKI (Public Key Infrastructure)
would have been far too expensive in time and money for us.
Moreover, considering the fact that any VPN client can authenticate
through a RADIUS database giving his usename/password, a simple
'generic' certificate has been linked to any VPN client.
The CA is run on a Linux 2.4.22 system. A few modifications have been
made to the original openssl.cnf file, and copied in
our example to /local/openssl/conf/openssl.cnf.
Here are the modifications made to the openssl.cnf file :
# diff -aurN openssl.cnf.orig openssl.cnf
--- openssl.cnf.orig 2005-02-11 18:55:03.000000000 +0100
+++ openssl.cnf 2005-02-11 20:58:18.000000000 +0100
@@ -5,7 +5,7 @@
# This definition stops the following lines choking if HOME isn't
# defined.
-HOME = .
+HOME = /local/openssl
RANDFILE = $ENV::HOME/.rnd
# Extra OBJECT IDENTIFIER info:
@@ -34,7 +34,7 @@
####################################################################
[ CA_default ]
-dir = ./CA # Where everything is kept
+dir = $HOME/CA # Where everything is kept
certs = $dir/certs # Where the issued certs are kept
crl_dir = $dir/crl # Where the issued crl are kept
database = $dir/index.txt # database index file.
Other fields in the [ req_distinguished_name ] can be
modified in order to speed up the certificate handling process.
Use the following procedure to create the CA certificate
(cacert.pem) and private key (cakey.pem):
# cd /local/openssl
# mkdir CA
# cp /dev/null CA/index.txt
# echo 01 > CA/serial
# mkdir CA/certs CA/crl CA/private CA/newcerts
# openssl req -config /local/openssl/conf/openssl.cnf -new -x509 -days 365 -keyout CA/private/cakey.pem -out CA/cacert.pem
# chmod 600 CA/private/cakey.pem
The private key is passphrase protected. This passphrase will be necessary to deliver and sign any certificate request that will come to this CA.
In this section, we describe how to build a CSR (Certificate Signing Request) as well as a private key for the Cisco IOS VPN router.
Building the CSR for the router :
# cd /local/openssl
# openssl req -config /local/openssl/conf/openssl.cnf -new -out CA/vpn-server-req.pem -keyout CA/private/vpn-server-key.pem -days 365
Note : do not forget the passphrase for the generated private key.
The actual request that will be processed by the CA is stored in the
vpn-server-req.pem file. The CN for the request has been
set to VPN-SERVER.
A particular attention must be given to the CSR for the clients, as
the OU field in the DN must match the group parameter in the router's
configuration.
We chose 'INTRANET-ACCESS' as both the OU field in the DN of the CSR
and the group parameter in the router's configuration.
Note : depending on the router's configuration, the group parameter 'INTRANET-ACCESS' can be stored in the router's configuration or in a RADIUS/TACACS external database. We show an example of a router's configuration that allows for a RADIUS storage of the group parameter further in this document.
Building the CSR for the INTRANET-ACCESS group :
# cd /local/openssl
# openssl req -config /local/openssl/conf/openssl.cnf -new -out CA/client-intranet-access-req.pem -keyout CA/private/client-intranet-access-key.pem -days 365
Note : do not forget the passphrase for the generated private key.
The actual request that will be processed by the CA is stored in the
client-intranet-access-req.pem file. The CN for the request
has been set to 'CLIENT-INTRANET-ACCESS'.
In this section, we describe how to build the certificates for both the Cisco IOS VPN router and the CLIENT-INTRANET-ACCESS VPN client group.
Signing the CSR (you need the passphrase that protects the CA's private
key to be able to proceed) :
# cd /local/openssl
# openssl ca -config /local/openssl/conf/openssl.cnf -out CA/certs/vpn-server-cert.pem -days 365 -infiles CA/vpn-server-req.pem
Building the PKCS#12 package :
# cd /local/openssl
# openssl pkcs12 -inkey CA/private/vpn-server-key.pem -in CA/certs/vpn-server-cert.pem -certfile CA/cacert.pem -export -out CA/vpn-server.p12
The generated package contains both the certificate (signed by the CA)
and the private key of the Cisco IOS VPN router, as well as the CA
certificate.
Note : the generated package must be protected with a passphrase. This
passphrase will be asked when importing the package into the Cisco IOS
VPN router.
Signing the CSR (you need the passphrase that protects the CA's private
key to be able to proceed) :
# cd /local/openssl
# openssl ca -config /local/openssl/conf/openssl.cnf -out CA/certs/client-intranet-access-cert.pem -days 365 -infiles CA/client-intranet-access-req.pem
Building the PKCS#12 package :
# cd /local/openssl
# openssl pkcs12 -inkey CA/private/client-intranet-access-key.pem -in CA/certs/client-intranet-acess-cert.pem -certfile CA/cacert.pem -export -out CA/client-intranet-access.p12
In this section, we describe how to transfer the previously generated
packages to the Cisco IOS VPN router and the VPN clients.
We used some very basic means to transfer the packages, and
an enrollment process using SCEP (Simple Certificate Enrollment
Protocol) should be prefered to the process described here.
Free products like OpenCA or IDX-PKI may help you if you want
to setup an SCEP capable CA.
I might add a few words about SCEP in this doc in the future.
The transfer is processed through TFTP (any file transfer protocol can be used though, just check the capability of the router).
router>enable
Note : we set up a minimal CA, hence no CDP (CRL Distribution Point)
is available for our router
router#conf t
router(config)#crypto ca trustpoint vpn-tp
router(ca-trustpoint)#usage ike
router(ca-trustpoint)#revocation-check none
router(ca-trustpoint)#^Z
router#copy tftp://10.0.0.1/vpn-server.p12 flash:
Note : the
vpn-server.p12 file must be copied to the
main TFTP directory.
router(config)#crypto ca import vpn-tp pkcs12 flash:vpn-server.p12
passphrase
Note : the passphrase is the one that protects the PKCS#12
vpn-server.p12 file
At this point, the router has its own signed certificate, its private key, and the certificate of the CA.
Just make the client-intranet-access.p12 file accessible
through the Windows Explorer, and import it using the Cisco VPN client
certificate importation utility (avalaible in the client itself).
You will be asked for the passphrase that protects the PKCS#12 file,
and you will also be asked to enter a new password to protect the
imported private key. Remember this password, as it will be asked
each time you want to connect using the certificate, or even when you
want to delete the certificate from the client.
The configurations for two authentication method are exposed here.
Note on RADIUS : the OU field in the DN of the client certificate must
be appear as a registered in the RADIUS database. Most of the
attributes of this user must be of the Cisco-AVPair type.
Here is an example of what the record for this particular user should
be (Livingston RADIUS server) :
INTRANET-ACCESS Auth-Type = Local, Password = "cisco", NAS-IP-Address = 10.0.0.2, Expiration = "Dec 31 2010"
Service-Type = Outbound-User,
Cisco-AVPair = "ipsec:key-exchange=ike",
Cisco-AVPair = "ipsec:addr-pool=vpnpool",
Cisco-AVPair = "ipsec:dns-servers=10.1.1.5 10.1.1.6",
Cisco-AVPair = "ipsec:inacl=101",
Cisco-AVPair = "ipsec:include-local-lan=1",
Cisco-AVPair = "ipsec:save-password=1",
Tunnel-Type = 16777225
In this record, the split-tunneling is defined according to the ACL 101,
and the Tunnel-Type value indicates an IPSEC tunnel.
Here are the elements that should be checked for the configuration of the router, in the case of a local authentication/authorization method:
!--- Define local authentication as the authentication method
!--- for Internet Key Exchange (IKE) XAUTH.
!--- Note that "ClientAuth" is the tag associated with the crypto
!--- map.
aaa new-model
aaa authentication login ClientAuth local
aaa authorization network ClientAuth local
[...]
crypto ca trustpoint vpn-tp
usage ike
revocation-check none
rsakeypair vpn-tp
!
!
crypto ca certificate chain vpn-tp
certificate 01
[...]CERT DATA[...]
certificate ca 00
[...]CA CERT DATA[...]
!
!
!--- RSA signatures is the default authentication method
crypto isakmp policy 1
group 2
!--- This has corrected some FDQN ID issue we had
crypto isakmp identity dn
!--- Define the VPN group for Cisco VPN Client.
!--- The VPN group name "INTRANET-ACCESS" matches
!--- the Organizational Unit (OU) name of the client's certificate.
!--- Access list "acl 101" defines the split-tunneling traffic, and
!--- "vpnpool" defines the IP pool from which the VPN Client
!--- receives its IP address during the IKE negotiation.
crypto isakmp client configuration group INTRANET-ACCESS
dns 10.1.1.5
pool vpnpool
acl 101
!
crypto ipsec transform-set aes256-md5-comp esp-aes 256 esp-md5-hmac comp-lzs
!
crypto dynamic-map dynmap 5
set transform-set aes256-md5-comp
reverse-route
!
!
crypto map ras_vpn client authentication list ClientAuth
crypto map ras_vpn isakmp authorization list ClientAuth
crypto map ras_vpn client configuration address respond
crypto map ras_vpn 10 ipsec-isakmp dynamic dynmap
[...]
!
!--- Apply the map on a network interface
interface Ethernet0/1
ip address 10.0.0.2 255.0.0.0
crypto map ras_vpn
[...]
ip local pool vpnpool 10.1.1.10 10.1.1.50
[...]
!
access-list 101 permit ip 10.1.0.0 0.0.255.255 10.1.1.0 0.0.0.255
[...]
!
!
end
Here are the elements that should be checked for the configuration of the router, in the case of a RADIUS authentication/authorization method:
!--- Define RADIUS as the authentication method
!--- for Internet Key Exchange (IKE) XAUTH.
!--- Note that "ClientAuth" is the tag associated with the crypto
!--- map.
!--- Define RADIUS as the authorization method : the group parameter
!--- acts as a connection profile, and is stored as a user in our
!--- RADIUS database
aaa new-model
aaa authentication login ClientAuth group radius
aaa authorization network ClientAuth group radius
[...]
crypto ca trustpoint vpn-tp
usage ike
revocation-check none
rsakeypair vpn-tp
!
!
crypto ca certificate chain vpn-tp
certificate 01
[...]CERT DATA[...]
certificate ca 00
[...]CA CERT DATA[...]
!
!
!--- RSA signatures is the default authentication method
crypto isakmp policy 1
group 2
!--- This has corrected some FDQN ID issue we had
crypto isakmp identity dn
!
!
crypto ipsec transform-set aes256-md5-comp esp-aes 256 esp-md5-hmac comp-lzs
!
crypto dynamic-map dynmap 5
set transform-set aes256-md5-comp
reverse-route
!
!
crypto map ras_vpn client authentication list ClientAuth
crypto map ras_vpn isakmp authorization list ClientAuth
crypto map ras_vpn client configuration address respond
crypto map ras_vpn 10 ipsec-isakmp dynamic dynmap
[...]
!
!--- Apply the map on a network interface
interface Ethernet0/1
ip address 10.0.0.2 255.0.0.0
crypto map ras_vpn
[...]
!--- IMPORTANT :The address pool must be present in the RADIUS
!--- attributes of the INTRANET-ACCESS registered user, as a
!--- Cisco-AV-Pair VSA (Vendor Specific Attribute).
!--- Moreover, the ACL defining the split tunneling for the
!--- connection must also be configured as a Cisco-AV-Pair VSA
!--- for the registered user INTRANET-ACCESS if needed
ip local pool vpnpool 10.1.1.10 10.1.1.50
[...]
!
access-list 101 permit ip 10.1.0.0 0.0.255.255 10.1.1.0 0.0.0.255
[...]
!
radius-server host 10.0.0.4 auth-port 1645 acct-port 1646 retransmit 1 key 7 *******************
[...]
!
!
end
Please refer to the documentation available on Cisco's website :
http://www.cisco.com/en/US/products/sw/secursw/ps2308/prod_configuration_examples_list.html
A copy of the GNU FDL is available here :
GNU Free Documentation License
Created: 2005/02/15 10:15:01
Updated: $Revision: 1.2 $ $Date: 2005/02/16 10:56:14 $ $Author: sultan $