Blog Ine Com 2009-05-18 Understanding External Easy VPN Auth
21
May 18 8 Comments Understanding External Easy VPN Authorization Posted by Petr Lapukhov, 4xCCIE/CCDE in VPN In this blog post we are going to review and compare the ways in which IOS and ASA Easy VPN servers perform ezVPN attribute authorization via RADIUS. The information on these procedure is scattered among the documentation and technology examples, so I thought it would be helpful to put the things together. To begin with, let’s establish some sort of equivalence between the IOS and ASA terminology. Even though ASA inherited most of it’s VPN configuration concepts from the VPN3000 platform it is still possible to find similarities between the IOS and the ASA configurations. Recall that IOS ezVPN configuration defines local ezVPN group policy by means of the crypto isakmp client configuration group command. This could be viewed as a rough equivalent to the ASA’s group-policy type internal command, though the ASA’s command scope is much broader. IOS ISAKMP profiles could be viewed as an equivalent to the ASA’s tunnel-group command defining a connection profile. ”Landing” an Incoming Connection Both IOS and ASA platforms attempt to match an incoming IPSec connection against ISAKMP profile/tunnel-groups (we do not consider the “legacy” IOS scenarios without ISAKMP profiles defined) defined in the system. You may find the description of the procedure used by the ASA firewalls here Understanding how ASA Firewall Matching tunnel-group Names . IOS router use similar procedure, which is somewhat simplified when using just ezVPN clients. As you know, a typical ezVPN client will eithera) Use IKE Aggressive Mode with ID_KEY_ID identity type, which specifies the ezVPN group name b) Or use IKE Main Mode with digital certificates and ID_DER_ASN1_DN identity type, which specifies the user’s Distinguished Name. In the first case, the IOS router will match the group name agains t the match identity statements of the ISAKMP profil es configured in the system and associate the connection with the configuration group specified by client configurati on group. In the second case, either group name is derived from the OU field of the subject’s DN orcertificate maps are used to map the names in the certificate to an ISAKMP profile. Additionally, you may use certificate maps associated with ISAKMP profiles by means of the command match certificate to map the incoming identity to an ISAKMP profile. Enabling External Authorization In IOS, you define ISAKMP authorization type by assigning an appropriate AAA authorization list to the group using the command isakmp authorization list. In the ASA, if you want the group to be authorized externally, you need to define the group-policy as external, associating it with an AAA server group and assigning a password, e.g. group -policy EZ VPN_GROUP exte rnal se rv er -group RA DIUS password CISCO. The IOS routers allow you to pull the group pre-shared key from the RADIUS server when the client uses PSK authentication. This is not possible with the ASA firewall, as the key is statically defined under the respective tunnel-group. In addition to external group authorization, both IOS and ASA firewall may enable external Xauth authentication/authorization. In the IOS router, this is done by using the ISAKMP profile command client authentication list referencing the AAA list that points to an AAA server. In the ASA firewall you enable external Xauth authentication by means of the tunnel-group ipsec-attributes command authentication-server-group referencing to the AAA server group linked to an external server. In is important to notice that both group authorization and Xauth authentication may pull down groups of RADIUS attributes from the AAA server. The attributes are then merged and conflicts resolved to form the final authorization set. RADIUS Authorization with IOS Here is a step-by-step description of the RADIUS authorization process in the IOS routers. Firs of all, notice that the group profile stored in the RADIUS server is a regular user with the name matching the ezVPN group name and the password value of “cisco”. All the policy attributes are stored as Cisco AV pairs associated with the user. Step 1: This step is needed for pre-shared keys authentication. The router extracts the group name from IKE message. This could be simply a group name (ID_KEY_ID) or the OU field value from a digital certificate. Using this name and the password value of “cisco” the router authenticates with the RADIUS server and pulls down a number ofattributes. The most important attribut e is the pre-shared key used by the router to authentication the remote peer. Naturally, digital signatures authentication process does not use this value. The profile stored in the RADIUS Search Search Submit Categories Select Category CCIE Bloggers Brian Dennis CCIE #2210 Rout ing & Sw itching ISP Dial Security Service ProviderVoice Brian McGahan CCIE #8593 Rout ing & Sw itching Security Service ProviderPetr Lapukhov CCIE #16379 Rout ing & Sw itching Security Service ProviderVoice Mark Snow CCIE #14073 Voice Security Popular Posts New Upcoming Classes forBlog Home | INE Home | Members | Contact Us | SubscribeFree Resources View Archives All Access Pass CCIE Bloggers
