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 either
a) 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 against the match identity statements of the ISAKMP profiles configured in the system and associate the connection with the configuration group specified by client configuration group. In the second case, either group name is derived from the OU field of the subject’s DN or certificate 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 EZVPN_GROUP external server-group RADIUS 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 of attributes. The most important attribute 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 server should define at the very least the following IETF RADIUS attributes:
Service-Type=”Outbound” to define the type of service.
Tunnel-Type=”IP ESP” to define the IPSec tunnel.
Tunnel-Password=”” defines the pre-shared key for the group, if PSK authentication is used. You don’t need this attribute for digital signatures authentication.
In addition to the above IETF RADIUS attributes, the following two Cisco AV-Pairs must be defined for the group:
ipsec:tunnel-type=ESP
ipsec:key-exchange=IKE
All other optional ezVPN attribute are defined by means of Cisco AV-Pair using the syntax “ipsec:”, for example “ipsec:addr-pool=ADDRESS_POOL”, “ipsec:default-domain=INE.com” and so on. This is in contrary with the ASA firewall, which uses specific RADIUS attributes (Altiga set).
Step 2:
If the respective option is configured under ISAKMP profile, the router starts Xauth for the remote user. If the user should be authenticated against the RADIUS server, the router will use the name and password provided for authentication. As a result, the RADIUS server will return a number of attributes associated with the user. At this step the router compares the av-pair ipsec:user-vpn-group attribute value (if present) with the IKE group name and aborts the connection if they don’t match. This is the newer implementation of the well-known Group Lock feature.
Step 3:
The router once again authenticates with the RADIUS server using the group name and the password value of “cisco”. This is needed as the attributes learned on Step 1 may have been lost during the previous steps, and we need them now to authorize ISAKMP configuration mode requests. The router combines all attributes learned from the RADIUS server in the following order of preference:
a) User attributes
b) Group attributes
That is, any attribute missing from User attributes is filled with Group attributes, and the user attributes override the group attributes
To summarize: IOS router downloads the group policy from the AAA server using the group name and the password of “cisco”. The profile is retrieved to perform group authentication process as to perform group authorization. All policy settings are stored using Cisco AV-Pairs “ipsec:*”.
Debugging Output for IOS RADIUS Policy Download
The following is the output of the command debug crypto isakmp for the remote ezVPN client connecting to an IOS router configured for RADIUS authorization. The process starts with the remote client (IP 136.1.100.200) starting IKE AM exchange with the server.
RADIUS Authorization with ASA
The steps below are shown in the logical sequence and we’ll discuss the actual flow of RADIUS requests after the outline. Unlike the IOS router, the firewall stores the group profile using a custom password. You specify this password when configuring the group-policy as external. The policy attributes are specified using a special set of Altiga RADIUS attributes. ASA firewall extended this set by adding new names and deprecating some older configuration options.
Step 1:
The firewall accepts incoming connection and maps it to a local tunnel-group.. Once the tunnel-group is found, the group-policy name associated with this tunnel-group is extracted. If the policy is locally configured, the firewall already has all authorization attributes on hand. If the policy is external, the firewall uses the policy name and the policy authentication password to contact the remote server, i.e. the RADIUS host. If the authentication was successful, the server returns authorization attributes and the firewall stores them locally.
Step 2:
If the tunnel-group requires user authentication, it prompts the use for Xauth credentials. Once the user enters them, the firewall authenticates the user using the configured server group (local or remote).
2.1) If user authentication is performed locally, the firewall obtains the authorization attributes from user settings (username … attributes). Additionally, there could be a group-policy associated with the user (user-specific group-policy). If the policy is local, attributes are immediately available. If the policy is external, the firewall again authenticates with the remote AAA server, using the policy name and configured password. In case of successful authentication, the remote server will return authorization attributes.
2.2) If user authentication is performed externally, the firewall queries the remote AAA server. If the authentication was successful, a number of authorization attributes is returned. Among them, there could be an IETF RADIUS attribute number 25 named “Class”. This attribute value must be in format “OU=Policy_Name;” (OU in upper case, string terminated by semicolon). The firewall parses this RADIUS attribute value (if any) and uses the “Policy_Name” to find a group-policy. This group-policy is user-specific, and in turn may be either local or external. If the policy is external, it’s in turn downloaded from the remote server.
Step 3:
Now the firewall combines all attributes learned at Step 1 and Step 2. User-specific attributes (values associated with the user locally or in the AAA server) take preference over user group-policy (group-policy associated with the user either locally or via RADIUS “Class” attribute). The user-specific group-policy settings take precedence over the group-policy associated with the tunnel-group. Lastly, the attributes defined in the default system group-policy (DfltGrpPolicy) are used to “fill in the gaps”.
As usual, the group profiles stored in the RADIUS server are regular users. However, unlike the IOS case, you may set any password you want for these users, and specify the same password in the ASA configuration. Keep in mind that ASA firewall uses the same set of RADIUS attributes as VPN 3000 appliance did (there are some incompatibilities though). You may find the full listing of the attributes in the ASA firewall VPN configuration guide appendix here Configuring an External Server for Security Appliance User Authorization
Now, the actual order used by the firewall to authorize the settings is a bit different. First, the RADIUS server is not queried until the client returns Xauth credentials. At this point, the firewall authenticates the Xauth user, possibly querying the external server. If the user attributes contain the Class attribute among them, the firewall may query the AAA server for the group-policy attributes (if the policy is not local). Only after this, the appliance will ultimately authorize the group-policy defined in the tunnel-group with the RADIUS server. This sequence is different from the one used in IOS routers, because IOS may need RADIUS attributes for ISAKMP authentication, i.e. download the group pre-shared key. This is why IOS queries AAA server in the very beginning of IKE exchange.
A few words about Group Lock feature in the ASA firewall. The ASA firewall uses special Altiga RADIUS attribute called Tunnel-Group-Lock. This attribute specifies the name of the tunnel group that the user is allowed to log into. The attribute is similar to User-VPN-Group attribute used in IOS routers. Notice that this differs from the Group Lock feature used previously in VPN 3000 appliances.
Debugging Output for IOS RADIUS Policy Download
Now let’s have a look at the RADIUS debugging output for the remote user connecting to the ASA firewall configured as an ezVPN server. The following output is the result of tw debugging commands: debug radius all and debug crypto isakmp 10. The first packet from the client starts IKE AM exchange as usual. The connection lands on the tunnel-group EZVPN and the firewall finds a matching policy entry. Everything else proceeds as usual, until the moment of Phase 1.5
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 either
a) 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 against the match identity statements of the ISAKMP profiles configured in the system and associate the connection with the configuration group specified by client configuration group. In the second case, either group name is derived from the OU field of the subject’s DN or certificate 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 EZVPN_GROUP external server-group RADIUS 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 of attributes. The most important attribute 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 server should define at the very least the following IETF RADIUS attributes:
Service-Type=”Outbound” to define the type of service.
Tunnel-Type=”IP ESP” to define the IPSec tunnel.
Tunnel-Password=”” defines the pre-shared key for the group, if PSK authentication is used. You don’t need this attribute for digital signatures authentication.
In addition to the above IETF RADIUS attributes, the following two Cisco AV-Pairs must be defined for the group:
ipsec:tunnel-type=ESP
ipsec:key-exchange=IKE
All other optional ezVPN attribute are defined by means of Cisco AV-Pair using the syntax “ipsec:”, for example “ipsec:addr-pool=ADDRESS_POOL”, “ipsec:default-domain=INE.com” and so on. This is in contrary with the ASA firewall, which uses specific RADIUS attributes (Altiga set).
Step 2:
If the respective option is configured under ISAKMP profile, the router starts Xauth for the remote user. If the user should be authenticated against the RADIUS server, the router will use the name and password provided for authentication. As a result, the RADIUS server will return a number of attributes associated with the user. At this step the router compares the av-pair ipsec:user-vpn-group attribute value (if present) with the IKE group name and aborts the connection if they don’t match. This is the newer implementation of the well-known Group Lock feature.
Step 3:
The router once again authenticates with the RADIUS server using the group name and the password value of “cisco”. This is needed as the attributes learned on Step 1 may have been lost during the previous steps, and we need them now to authorize ISAKMP configuration mode requests. The router combines all attributes learned from the RADIUS server in the following order of preference:
a) User attributes
b) Group attributes
That is, any attribute missing from User attributes is filled with Group attributes, and the user attributes override the group attributes
To summarize: IOS router downloads the group policy from the AAA server using the group name and the password of “cisco”. The profile is retrieved to perform group authentication process as to perform group authorization. All policy settings are stored using Cisco AV-Pairs “ipsec:*”.
Debugging Output for IOS RADIUS Policy Download
The following is the output of the command debug crypto isakmp for the remote ezVPN client connecting to an IOS router configured for RADIUS authorization. The process starts with the remote client (IP 136.1.100.200) starting IKE AM exchange with the server.
ISAKMP (0:0): received packet from 136.1.100.200 dport 500 sport 1419 Global (N) NEW SA ISAKMP: Created a peer struct for 136.1.100.200, peer port 1419 ISAKMP: New peer created peer = 0x83F035D4 peer_handle = 0x8000000B ISAKMP: Locking peer struct 0x83F035D4, refcount 1 for crypto_isakmp_process_block ISAKMP: local port 500, remote port 1419 insert sa successfully sa = 82F100E8 ISAKMP:(0): processing SA payload. message ID = 0 ISAKMP:(0): processing ID payload. message ID = 0 ISAKMP (0:0): ID payload next-payload : 13 type : 11 group id : EZVPN protocol : 17 port : 500 length : 13The peer advertises group name EZVPN as it’s ID. The router find a matching ezVPN profile for this connection.
ISAKMP:(0):: peer matches EZVPN profile
ISAKMP:(0):Setting client config settings 83C36734
ISAKMP:(0):(Re)Setting client xauth list and state
ISAKMP/xauth: initializing AAA request
AAA/BIND(00000015): Bind i/f
ISAKMP:(0): processing vendor id payload
ISAKMP:(0): vendor ID seems Unity/DPD but major 215 mismatch
ISAKMP:(0): vendor ID is XAUTH
ISAKMP:(0): processing vendor id payload
ISAKMP:(0): vendor ID is DPD
ISAKMP:(0): processing vendor id payload
ISAKMP:(0): processing IKE frag vendor id payload
ISAKMP:(0): Support for IKE Fragmentation not enabled
ISAKMP:(0): processing vendor id payload
ISAKMP:(0): vendor ID seems Unity/DPD but major 123 mismatch
ISAKMP:(0): vendor ID is NAT-T v2
ISAKMP:(0): processing vendor id payload
ISAKMP:(0): vendor ID is Unity
ISAKMP:(0): Authentication by xauth preshared
ISAKMP:(0):Checking ISAKMP transform 1 against priority 10 policy
ISAKMP: encryption AES-CBC
ISAKMP: hash SHA
ISAKMP: default group 2
ISAKMP: auth XAUTHInitPreShared
ISAKMP: life type in seconds
ISAKMP: life duration (VPI) of 0x0 0x20 0xC4 0x9B
ISAKMP: keylength of 256
...
ISAKMP:(0):Checking ISAKMP transform 10 against priority 10 policy
ISAKMP: encryption 3DES-CBC
ISAKMP: hash MD5
ISAKMP: default group 2
ISAKMP: auth XAUTHInitPreShared
ISAKMP: life type in seconds
ISAKMP: life duration (VPI) of 0x0 0x20 0xC4 0x9B
ISAKMP:(0):atts are acceptable. Next payload is 3
ISAKMP:(0):Acceptable atts:actual life: 86400
ISAKMP:(0):Acceptable atts:life: 0
ISAKMP:(0):Fill atts in sa vpi_length:4
ISAKMP:(0):Fill atts in sa life_in_seconds:2147483
ISAKMP:(0):Returning Actual lifetime: 86400
ISAKMP:(0)::Started lifetime timer: 86400.SA policy has been selected, performing DH key-exchange now. At this moment the router attempts to pull down the group attributes to perform peer authentication, using the pre-shared key stored in the RADIUS database. Notice the username used for authentication – it matches the group name.ISAKMP:(0): processing KE payload. message ID = 0 ISAKMP:(0): processing NONCE payload. message ID = 0 ISAKMP:(0): vendor ID is NAT-T v2 AAA/AUTHOR (0x15): Pick method list 'AUTHOR_RADIUS' ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_AM_EXCH ISAKMP:(0):Old State = IKE_READY New State = IKE_R_AM_AAA_AWAIT RADIUS/ENCODE(0000002F):Orig. component type = VPN_IPSEC RADIUS: AAA Unsupported Attr: interface [174] 11 RADIUS: 31 33 36 2E 31 2E 31 30 30 [136.1.100] RADIUS(0000002F): Config NAS IP: 150.1.3.3 RADIUS/ENCODE(0000002F): acct_session_id: 45 RADIUS(0000002F): sending RADIUS(0000002F): Send Access-Request to 10.0.0.100:1645 id 1645/50, len 97 RADIUS: authenticator 58 56 FD AE 5B DF 91 24 - 9D C5 51 CC 7B F0 60 05 RADIUS: User-Name [1] 7 "EZVPN" RADIUS: User-Password [2] 18 * RADIUS: Calling-Station-Id [31] 15 "136.1.100.200" RADIUS: NAS-Port-Type [61] 6 Virtual [5] RADIUS: NAS-Port [5] 6 0 RADIUS: NAS-Port-Id [87] 13 "136.1.100.3" RADIUS: Service-Type [6] 6 Outbound [5] RADIUS: NAS-IP-Address [4] 6 150.1.3.3The server returns ACCESS-ACCEPT message along with the authorization attributes. Notice the AV pair values.
RADIUS: Received from id 1645/50 10.0.0.100:1645, Access-Accept, len 145 RADIUS: authenticator 29 27 57 5D AF 05 4A C2 - B4 DE F0 05 4A 78 52 51 RADIUS: Vendor, Cisco [26] 29 RADIUS: Cisco AVpair [1] 23 "ipsec:addr-pool=EZVPN" RADIUS: Vendor, Cisco [26] 32 RADIUS: Cisco AVpair [1] 26 "ipsec:inacl=SPLIT_TUNNEL" RADIUS: Service-Type [6] 6 Outbound [5] RADIUS: Tunnel-Type [64] 6 01:ESP [9] RADIUS: Tunnel-Password [69] 21 01:* RADIUS: Framed-IP-Address [8] 6 255.255.255.255 RADIUS: Class [25] 25 RADIUS: 43 41 43 53 3A 30 2F 31 38 37 35 65 2F 39 36 30 [CACS:0/1875e/960] RADIUS: 31 30 33 30 33 2F 30 [10303/0] RADIUS(0000002F): Received from id 1645/50 ISAKMP:(1023): constructed NAT-T vendor-02 IDThe server finally authenticates the group and sends a response packet.
ISAKMP:(1023):SA is doing pre-shared key authentication plus XAUTH using id type ID_IPV4_ADDR
ISAKMP (0:1023): ID payload
next-payload : 10
type : 1
address : 136.1.100.3
protocol : 0
port : 0
length : 12
ISAKMP:(1023):Total payload length: 12
ISAKMP:(1023): sending packet to 136.1.100.200 my_port 500 peer_port 1604 (R) AG_INIT_EXCH
ISAKMP:(1023):Sending an IKE IPv4 Packet.
ISAKMP:(1023):Input = IKE_MESG_FROM_AAA, PRESHARED_KEY_REPLY
ISAKMP:(1023):Old State = IKE_R_AM_AAA_AWAIT New State = IKE_R_AM2Now the server requests Xuath credentials from the remote peer.ISAKMP:(1023):Need XAUTH ISAKMP: set new node 1195294443 to CONF_XAUTH ISAKMP/xauth: request attribute XAUTH_USER_NAME_V2 ISAKMP/xauth: request attribute XAUTH_USER_PASSWORD_V2 ISAKMP:(1023): initiating peer config to 136.1.100.200. ID = 1195294443 ISAKMP:(1023): sending packet to 136.1.100.200 my_port 500 peer_port 1604 (R) CONF_XAUTH ISAKMP:(1023):Sending an IKE IPv4 Packet. ISAKMP:(1023):Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE ISAKMP:(1023):Old State = IKE_P1_COMPLETE New State = IKE_XAUTH_REQ_SENT ISAKMP (0:1023): received packet from 136.1.100.200 dport 500 sport 1604 Global (R) CONF_XAUTH ISAKMP:(1023):processing transaction payload from 136.1.100.200. message ID = 1195294443 ISAKMP: Config payload REPLY ISAKMP/xauth: reply attribute XAUTH_USER_NAME_V2 ISAKMP/xauth: reply attribute XAUTH_USER_PASSWORD_V2The credentials are sent to the RADIUS server for authentication.
AAA/AUTHEN/LOGIN (00000030): Pick method list 'AUTH_RADIUS' ISAKMP:(1023):deleting node 1195294443 error FALSE reason "Done with xauth request/reply exchange" ISAKMP:(1023):Input = IKE_MESG_FROM_PEER, IKE_CFG_REPLY ISAKMP:(1023):Old State = IKE_XAUTH_REQ_SENT New State = IKE_XAUTH_AAA_CONT_LOGIN_AWAIT RADIUS/ENCODE(00000030):Orig. component type = VPN_IPSEC RADIUS: AAA Unsupported Attr: interface [174] 11 RADIUS: 31 33 36 2E 31 2E 31 30 30 [136.1.100] RADIUS/ENCODE(00000030): dropping service type, "radius-server attribute 6 on-for-login-auth" is off RADIUS(00000030): Config NAS IP: 150.1.3.3 RADIUS/ENCODE(00000030): acct_session_id: 46 RADIUS(00000030): sending RADIUS(00000030): Send Access-Request to 10.0.0.100:1645 id 1645/51, len 91 RADIUS: authenticator 45 51 AD B1 9F 57 60 0E - 6D 75 24 37 CD 23 DC 9D RADIUS: User-Name [1] 7 "CISCO" RADIUS: User-Password [2] 18 * RADIUS: Calling-Station-Id [31] 15 "136.1.100.200" RADIUS: NAS-Port-Type [61] 6 Virtual [5] RADIUS: NAS-Port [5] 6 0 RADIUS: NAS-Port-Id [87] 13 "136.1.100.3" RADIUS: NAS-IP-Address [4] 6 150.1.3.3The response contains the user-vpn-group attribute value of “EZVPN”.
RADIUS: Received from id 1645/51 10.0.0.100:1645, Access-Accept, len 85
RADIUS: authenticator 48 5E 75 29 58 1D DC 53 - 42 FB 1F 5C 35 12 24 22
RADIUS: Framed-IP-Address [8] 6 255.255.255.255
RADIUS: Vendor, Cisco [26] 34
RADIUS: Cisco AVpair [1] 28 "ipsec:user-vpn-group=EZVPN"
RADIUS: Class [25] 25
RADIUS: 43 41 43 53 3A 30 2F 31 38 37 35 66 2F 39 36 30 [CACS:0/1875f/960]
RADIUS: 31 30 33 30 33 2F 30 [10303/0]
RADIUS(00000030): Received from id 1645/51
ISAKMP: set new node 1673765102 to CONF_XAUTH
ISAKMP:(1023): initiating peer config to 136.1.100.200. ID = 1673765102
ISAKMP:(1023): sending packet to 136.1.100.200 my_port 500 peer_port 1604 (R) CONF_XAUTH
ISAKMP:(1023):Sending an IKE IPv4 Packet.
ISAKMP:(1023):Input = IKE_MESG_FROM_AAA, IKE_AAA_CONT_LOGIN
ISAKMP:(1023):Old State = IKE_XAUTH_AAA_CONT_LOGIN_AWAIT New State = IKE_XAUTH_SET_SENTThe client request configuration attributes now and configuration mode proceeds as usual.ISAKMP: Config payload REQUEST
ISAKMP:(1023):checking request:
ISAKMP: IP4_ADDRESS
ISAKMP: IP4_NETMASK
ISAKMP: IP4_DNS
ISAKMP: IP4_NBNS
ISAKMP: ADDRESS_EXPIRY
ISAKMP: MODECFG_BANNER
ISAKMP: MODECFG_SAVEPWD
ISAKMP: DEFAULT_DOMAIN
ISAKMP: SPLIT_INCLUDE
ISAKMP: SPLIT_DNS
ISAKMP: PFS
ISAKMP: MODECFG_BROWSER_PROXY
ISAKMP: BACKUP_SERVER
ISAKMP: APPLICATION_VERSION
ISAKMP: FW_RECORD
ISAKMP: MODECFG_HOSTNAME
ISAKMP: CONFIG_MODE_UNKNOWN Unknown Attr: 0x7005
AAA/AUTHOR (0x30): Pick method list 'AUTHOR_RADIUS'
ISAKMP/author: Author request for group EZVPNsuccessfully sent to AAA
ISAKMP:(1023):Input = IKE_MESG_FROM_PEER, IKE_CFG_REQUEST
ISAKMP:(1023):Old State = IKE_P1_COMPLETE New State = IKE_CONFIG_AUTHOR_AAA_AWAIT
RADIUS/ENCODE(00000030):Orig. component type = VPN_IPSEC
RADIUS: AAA Unsupported Attr: interface [174] 11
RADIUS: 31 33 36 2E 31 2E 31 30 30 [136.1.100]
RADIUS(00000030): Config NAS IP: 150.1.3.3
RADIUS/ENCODE(00000030): acct_session_id: 46
RADIUS(00000030): sending
ISAKMP:(1023):Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE
ISAKMP:(1023):Old State = IKE_CONFIG_AUTHOR_AAA_AWAIT New State = IKE_CONFIG_AUTHOR_AAA_AWAITThe router once again authenticates the group name with the RADIUS server. This time, it looks for authorization attributes to prepare a response to the client.RADIUS(00000030): Send Access-Request to 10.0.0.100:1645 id 1645/52, len 103 RADIUS: authenticator D5 03 85 B5 36 F4 30 D5 - 1A 12 E3 DE DA A5 5E 10 RADIUS: User-Name [1] 7 "EZVPN" RADIUS: User-Password [2] 18 * RADIUS: Calling-Station-Id [31] 15 "136.1.100.200" RADIUS: NAS-Port-Type [61] 6 Virtual [5] RADIUS: NAS-Port-Type [61] 6 Virtual [5] RADIUS: NAS-Port [5] 6 0 RADIUS: NAS-Port-Id [87] 13 "136.1.100.3" RADIUS: Service-Type [6] 6 Outbound [5] RADIUS: NAS-IP-Address [4] 6 150.1.3.3 RADIUS: Received from id 1645/52 10.0.0.100:1645, Access-Accept, len 145 RADIUS: authenticator 0B 8B BA 22 EB DF BF 31 - 56 5A 30 EB C0 7B 77 FA RADIUS: Vendor, Cisco [26] 29 RADIUS: Cisco AVpair [1] 23 "ipsec:addr-pool=EZVPN" RADIUS: Vendor, Cisco [26] 32 RADIUS: Cisco AVpair [1] 26 "ipsec:inacl=SPLIT_TUNNEL" RADIUS: Service-Type [6] 6 Outbound [5] RADIUS: Tunnel-Type [64] 6 01:ESP [9] RADIUS: Tunnel-Password [69] 21 01:* RADIUS: Framed-IP-Address [8] 6 255.255.255.255 RADIUS: Class [25] 25 RADIUS: 43 41 43 53 3A 30 2F 31 38 37 36 30 2F 39 36 30 [CACS:0/18760/960] RADIUS: 31 30 33 30 33 2F 30 [10303/0] RADIUS(00000030): Received from id 1645/52 ISAKMP:(1023):attributes sent in message: Address: 0.2.0.0After this, the negotiations proceed as usual, finishing with establishment of IPSec SA.
RADIUS Authorization with ASA
The steps below are shown in the logical sequence and we’ll discuss the actual flow of RADIUS requests after the outline. Unlike the IOS router, the firewall stores the group profile using a custom password. You specify this password when configuring the group-policy as external. The policy attributes are specified using a special set of Altiga RADIUS attributes. ASA firewall extended this set by adding new names and deprecating some older configuration options.
Step 1:
The firewall accepts incoming connection and maps it to a local tunnel-group.. Once the tunnel-group is found, the group-policy name associated with this tunnel-group is extracted. If the policy is locally configured, the firewall already has all authorization attributes on hand. If the policy is external, the firewall uses the policy name and the policy authentication password to contact the remote server, i.e. the RADIUS host. If the authentication was successful, the server returns authorization attributes and the firewall stores them locally.
Step 2:
If the tunnel-group requires user authentication, it prompts the use for Xauth credentials. Once the user enters them, the firewall authenticates the user using the configured server group (local or remote).
2.1) If user authentication is performed locally, the firewall obtains the authorization attributes from user settings (username … attributes). Additionally, there could be a group-policy associated with the user (user-specific group-policy). If the policy is local, attributes are immediately available. If the policy is external, the firewall again authenticates with the remote AAA server, using the policy name and configured password. In case of successful authentication, the remote server will return authorization attributes.
2.2) If user authentication is performed externally, the firewall queries the remote AAA server. If the authentication was successful, a number of authorization attributes is returned. Among them, there could be an IETF RADIUS attribute number 25 named “Class”. This attribute value must be in format “OU=Policy_Name;” (OU in upper case, string terminated by semicolon). The firewall parses this RADIUS attribute value (if any) and uses the “Policy_Name” to find a group-policy. This group-policy is user-specific, and in turn may be either local or external. If the policy is external, it’s in turn downloaded from the remote server.
Step 3:
Now the firewall combines all attributes learned at Step 1 and Step 2. User-specific attributes (values associated with the user locally or in the AAA server) take preference over user group-policy (group-policy associated with the user either locally or via RADIUS “Class” attribute). The user-specific group-policy settings take precedence over the group-policy associated with the tunnel-group. Lastly, the attributes defined in the default system group-policy (DfltGrpPolicy) are used to “fill in the gaps”.
As usual, the group profiles stored in the RADIUS server are regular users. However, unlike the IOS case, you may set any password you want for these users, and specify the same password in the ASA configuration. Keep in mind that ASA firewall uses the same set of RADIUS attributes as VPN 3000 appliance did (there are some incompatibilities though). You may find the full listing of the attributes in the ASA firewall VPN configuration guide appendix here Configuring an External Server for Security Appliance User Authorization
Now, the actual order used by the firewall to authorize the settings is a bit different. First, the RADIUS server is not queried until the client returns Xauth credentials. At this point, the firewall authenticates the Xauth user, possibly querying the external server. If the user attributes contain the Class attribute among them, the firewall may query the AAA server for the group-policy attributes (if the policy is not local). Only after this, the appliance will ultimately authorize the group-policy defined in the tunnel-group with the RADIUS server. This sequence is different from the one used in IOS routers, because IOS may need RADIUS attributes for ISAKMP authentication, i.e. download the group pre-shared key. This is why IOS queries AAA server in the very beginning of IKE exchange.
A few words about Group Lock feature in the ASA firewall. The ASA firewall uses special Altiga RADIUS attribute called Tunnel-Group-Lock. This attribute specifies the name of the tunnel group that the user is allowed to log into. The attribute is similar to User-VPN-Group attribute used in IOS routers. Notice that this differs from the Group Lock feature used previously in VPN 3000 appliances.
Debugging Output for IOS RADIUS Policy Download
Now let’s have a look at the RADIUS debugging output for the remote user connecting to the ASA firewall configured as an ezVPN server. The following output is the result of tw debugging commands: debug radius all and debug crypto isakmp 10. The first packet from the client starts IKE AM exchange as usual. The connection lands on the tunnel-group EZVPN and the firewall finds a matching policy entry. Everything else proceeds as usual, until the moment of Phase 1.5
[IKEv1]: IP = 136.1.100.200, IKE_DECODE RECEIVED Message (msgid=0) with payloads : HDR + SA (1) + KE (4) + NONCE (10) + ID (5) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 849 [IKEv1 DEBUG]: IP = 136.1.100.200, processing SA payload [IKEv1 DEBUG]: IP = 136.1.100.200, processing ke payload [IKEv1 DEBUG]: IP = 136.1.100.200, processing ISA_KE payload [IKEv1 DEBUG]: IP = 136.1.100.200, processing nonce payload [IKEv1 DEBUG]: IP = 136.1.100.200, processing ID payload [IKEv1 DEBUG]: IP = 136.1.100.200, processing VID payload [IKEv1 DEBUG]: IP = 136.1.100.200, Received xauth V6 VID [IKEv1 DEBUG]: IP = 136.1.100.200, processing VID payload [IKEv1 DEBUG]: IP = 136.1.100.200, Received DPD VID [IKEv1 DEBUG]: IP = 136.1.100.200, processing VID payload [IKEv1 DEBUG]: IP = 136.1.100.200, Received Fragmentation VID [IKEv1 DEBUG]: IP = 136.1.100.200, IKE Peer included IKE fragmentation capability flags: Main Mode: True Aggressive Mode: False [IKEv1 DEBUG]: IP = 136.1.100.200, processing VID payload [IKEv1 DEBUG]: IP = 136.1.100.200, Received NAT-Traversal ver 02 VID [IKEv1 DEBUG]: IP = 136.1.100.200, processing VID payload [IKEv1 DEBUG]: IP = 136.1.100.200, Received Cisco Unity client VID [IKEv1]: IP = 136.1.100.200, Connection landed on tunnel_group EZVPN [IKEv1 DEBUG]: Group = EZVPN, IP = 136.1.100.200, processing IKE SA payload [IKEv1 DEBUG]: Group = EZVPN, IP = 136.1.100.200, IKE SA Proposal # 1, Transform # 10 acceptable Matches global IKE entry # 1Now the firewall starts Xauth transactions. The client responds with credentials, and the firewall attempts authentication with the RADIUS server. The firewall sends the name “XAUTH_USER” along with the password of “CISCO”.
[IKEv1]: IP = 136.1.100.200, IKE_DECODE SENDING Message (msgid=cdc0c17f) with payloads : HDR + HASH (8) + ATTR (14) + NONE (0) total length : 68
[IKEv1]: IP = 136.1.100.200, IKE_DECODE RECEIVED Message (msgid=cdc0c17f) with payloads : HDR + HASH (8) + ATTR (14) + NONE (0) total length : 87
RADIUS packet decode (authentication request)
--------------------------------------
Raw packet data (length = 160).....
01 00 00 a0 df 2c f5 8a fb 18 71 56 d7 c4 ad e2 | .....,....qV....
73 30 a9 2e 01 0c 58 41 55 54 48 5f 55 53 45 52 | s0....XAUTH_USER
02 12 a7 99 79 db cb 12 41 fb bc 53 30 b2 60 b7 | ....y...A..S0.`.
ae bb 05 06 00 00 f0 00 06 06 00 00 00 02 07 06 | ................
00 00 00 01 1e 0e 31 33 36 2e 31 2e 31 32 33 2e | ......136.1.123.
31 32 1f 0f 31 33 36 2e 31 2e 31 30 30 2e 32 30 | 12..136.1.100.20
30 3d 06 00 00 00 05 42 0f 31 33 36 2e 31 2e 31 | 0=.....B.136.1.1
30 30 2e 32 30 30 04 06 88 01 7b 0c 1a 24 00 00 | 00.200....{..$..
00 09 01 1e 69 70 3a 73 6f 75 72 63 65 2d 69 70 | ....ip:source-ip
3d 31 33 36 2e 31 2e 31 30 30 2e 32 30 30 0d a2 | =136.1.100.200..The server responds and you can see the RADIUS Class attribute in the response. Notice that the response also contains the IP address 20.0.0.100 to be assigned to the client. RADIUS packet decode (response) -------------------------------------- Raw packet data (length = 71)..... 02 00 00 47 2e 49 12 20 d5 49 31 ca 26 b5 a8 68 | ...G.I. .I1.&..h 8a f6 c7 2e 08 06 14 00 00 64 19 10 4f 55 3d 45 | .........d.. OU=E 5a 56 50 4e 5f 55 53 45 52 3b 19 1d 43 41 43 53 | ZVPN_USER;..CACS 3a 30 2f 31 38 63 37 36 2f 38 38 30 31 37 62 30 | :0/18c76/88017b0 63 2f 36 31 34 34 30 | c/61440 Parsed packet data..... Radius: Code = 2 (0x02) Radius: Identifier = 0 (0x00) Radius: Length = 71 (0x0047) Radius: Vector: 2E491220D54931CA26B5A8688AF6C72E Radius: Type = 8 (0x08) Framed-IP-Address Radius: Length = 6 (0x06) Radius: Value (IP Address) = 20.0.0.100 (0x14000064) Radius: Type = 25 (0x19) Class Radius: Length = 16 (0x10) Radius: Value (String) = 4f 55 3d 45 5a 56 50 4e 5f 55 53 45 52 3b | OU=EZVPN_USER; Radius: Type = 25 (0x19) Class Radius: Length = 29 (0x1D) Radius: Value (String) = 43 41 43 53 3a 30 2f 31 38 63 37 36 2f 38 38 30 | CACS:0/18c76/880 31 37 62 30 63 2f 36 31 34 34 30 | 17b0c/61440 rad_procpkt: ACCEPTNow the firewall parses the class attribute and extract the group policy name “EZVPN_USER”. Since this policy is defined as external, another request is made to the AAA server. The server responds with the attributes corresponding to this group policy.
RADIUS packet decode (authentication request)
--------------------------------------
Raw packet data (length = 160).....
01 01 00 a0 cf 5c 65 3a eb 48 e1 06 c7 f4 1d 92 | .....e:.H......
63 60 19 de 01 0c 45 5a 56 50 4e 5f 55 53 45 52 | c`....EZVPN_USER
02 12 31 26 3f 4c 0c 58 cb 9b 20 ab 48 76 d8 70 | ..1&?L.X.. .Hv.p
a3 03 05 06 00 00 00 00 06 06 00 00 00 02 07 06 | ................
00 00 00 01 1e 0e 31 33 36 2e 31 2e 31 32 33 2e | ......136.1.123.
31 32 1f 0f 31 33 36 2e 31 2e 31 30 30 2e 32 30 | 12..136.1.100.20
30 3d 06 00 00 00 05 42 0f 31 33 36 2e 31 2e 31 | 0=.....B.136.1.1
30 30 2e 32 30 30 04 06 88 01 7b 0c 1a 24 00 00 | 00.200....{..$..
00 09 01 1e 69 70 3a 73 6f 75 72 63 65 2d 69 70 | ....ip:source-ip
3d 31 33 36 2e 31 2e 31 30 30 2e 32 30 30 a7 a0 | =136.1.100.200..
RADIUS packet decode (response)
--------------------------------------
Raw packet data (length = 101).....
02 01 00 65 b7 d9 60 2d 8f a5 a4 cd 1c bb 76 1e | ...e..`-......v.
d3 44 00 ba 1a 19 00 00 0c 04 1b 13 53 50 4c 49 | .D..........SPLI
54 5f 54 55 4e 4e 45 4c 5f 55 53 45 52 1a 0c 00 | T_TUNNEL_USER...
00 0c 04 37 06 00 00 00 01 1a 0d 00 00 0c 04 55 | ...7...........U
07 45 5a 56 50 4e 08 06 ff ff ff ff 19 19 43 41 | .EZVPN........CA
43 53 3a 30 2f 31 38 63 37 37 2f 38 38 30 31 37 | CS:0/18c77/88017
62 30 63 2f 30 | b0c/0The attributes contain split-tunnel policy definition and the Tunnel-Group-Lock attribute with the value of “EZVPN”.Parsed packet data..... Radius: Code = 2 (0x02) Radius: Identifier = 1 (0x01) Radius: Length = 101 (0x0065) Radius: Vector: B7D9602D8FA5A4CD1CBB761ED34400BA Radius: Type = 26 (0x1A) Vendor-Specific Radius: Length = 25 (0x19) Radius: Vendor ID = 3076 (0x00000C04) Radius: Type = 27 (0x1B) Split-Tunnel-Inclusion-List Radius: Length = 19 (0x13) Radius: Value (String) = 53 50 4c 49 54 5f 54 55 4e 4e 45 4c 5f 55 53 45 | SPLIT_TUNNEL_USE 52 | R Radius: Type = 26 (0x1A) Vendor-Specific Radius: Length = 12 (0x0C) Radius: Vendor ID = 3076 (0x00000C04) Radius: Type = 55 (0x37) Split-Tunneling-Policy Radius: Length = 6 (0x06) Radius: Value (Integer) = 1 (0x0001) Radius: Type = 26 (0x1A) Vendor-Specific Radius: Length = 13 (0x0D) Radius: Vendor ID = 3076 (0x00000C04) Radius: Type = 85 (0x55) The tunnel group that tunnel must be associated with Radius: Length = 7 (0x07) Radius: Value (String) = 45 5a 56 50 4e | EZVPN Radius: Type = 8 (0x08) Framed-IP-Address Radius: Length = 6 (0x06) Radius: Value (IP Address) = 255.255.255.255 (0xFFFFFFFF) Radius: Type = 25 (0x19) Class Radius: Length = 25 (0x19) Radius: Value (String) = 43 41 43 53 3a 30 2f 31 38 63 37 37 2f 38 38 30 | CACS:0/18c77/880 31 37 62 30 63 2f 30 | 17b0c/0 rad_procpkt: ACCEPTNow the firewall requests AAA attributes associated with the tunnel-group group-policy. This group-policy is defined as external in the firewall, and thus the appliance sends the respective name to the AAA server.
RADIUS packet decode (authentication request)
--------------------------------------
Raw packet data (length = 161).....
01 02 00 a1 bf 8c d5 ea db 78 51 b6 b7 24 8d 42 | .........xQ..$.B
53 90 89 8e 01 0d 45 5a 56 50 4e 5f 47 52 4f 55 | S.....EZVPN_GROU
50 02 12 59 a6 eb 66 f7 79 8b 26 16 cb 0e cd ab | P..Y..f.y.&.....
23 9b b7 05 06 00 00 00 00 06 06 00 00 00 02 07 | #...............
06 00 00 00 01 1e 0e 31 33 36 2e 31 2e 31 32 33 | .......136.1.123
2e 31 32 1f 0f 31 33 36 2e 31 2e 31 30 30 2e 32 | .12..136.1.100.2
30 30 3d 06 00 00 00 05 42 0f 31 33 36 2e 31 2e | 00=.....B.136.1.
31 30 30 2e 32 30 30 04 06 88 01 7b 0c 1a 24 00 | 100.200....{..$.
00 00 09 01 1e 69 70 3a 73 6f 75 72 63 65 2d 69 | .....ip:source-i
70 3d 31 33 36 2e 31 2e 31 30 30 2e 32 30 30 da | p=136.1.100.200.
a1 | .The serve responds with the tunnel group policy attributes. The attributes are decoded in the output below. You can see the split tunnel access-list, which is overridden by the user group-policy setting though.RADIUS packet decode (response) -------------------------------------- Raw packet data (length = 131)..... 02 02 00 83 b8 c5 22 ec c6 29 37 c0 6d c1 cd ae | ......"..)7.m... 23 4f 36 bc 1a 0c 00 00 0c 04 0b 06 00 00 00 04 | #O6............. 1a 0c 00 00 0c 04 0d 06 00 00 00 01 1a 14 00 00 | ................ 0c 04 1b 0e 53 50 4c 49 54 5f 54 55 4e 4e 45 4c | ....SPLIT_TUNNEL 1a 0c 00 00 0c 04 05 06 0a 00 00 64 1a 0c 00 00 | ...........d.... 0c 04 37 06 00 00 00 01 1a 0c 00 00 0c 04 3d 06 | ..7...........=. 14 00 00 0c 08 06 ff ff ff ff 19 19 43 41 43 53 | ............CACS 3a 30 2f 31 38 63 37 38 2f 38 38 30 31 37 62 30 | :0/18c78/88017b0 63 2f 30 | c/0 Parsed packet data..... Radius: Code = 2 (0x02) Radius: Identifier = 2 (0x02) Radius: Length = 131 (0x0083) Radius: Vector: B8C522ECC62937C06DC1CDAE234F36BC Radius: Type = 26 (0x1A) Vendor-Specific Radius: Length = 12 (0x0C) Radius: Vendor ID = 3076 (0x00000C04) Radius: Type = 11 (0x0B) Tunnelling-Protocol Radius: Length = 6 (0x06) Radius: Value (Integer) = 4 (0x0004) Radius: Type = 26 (0x1A) Vendor-Specific Radius: Length = 12 (0x0C) Radius: Vendor ID = 3076 (0x00000C04) Radius: Type = 13 (0x0D) IPSec-Authentication Radius: Length = 6 (0x06) Radius: Value (Integer) = 1 (0x0001) Radius: Type = 26 (0x1A) Vendor-Specific Radius: Length = 20 (0x14) Radius: Vendor ID = 3076 (0x00000C04) Radius: Type = 27 (0x1B) Split-Tunnel-Inclusion-List Radius: Length = 14 (0x0E) Radius: Value (String) = 53 50 4c 49 54 5f 54 55 4e 4e 45 4c | SPLIT_TUNNEL Radius: Type = 26 (0x1A) Vendor-Specific Radius: Length = 12 (0x0C) Radius: Vendor ID = 3076 (0x00000C04) Radius: Type = 5 (0x05) Primary-DNS Radius: Length = 6 (0x06) Radius: Value (IP Address) = 10.0.0.100 (0x0A000064) Radius: Type = 26 (0x1A) Vendor-Specific Radius: Length = 12 (0x0C) Radius: Vendor ID = 3076 (0x00000C04) Radius: Type = 55 (0x37) Split-Tunneling-Policy Radius: Length = 6 (0x06) Radius: Value (Integer) = 1 (0x0001) Radius: Type = 26 (0x1A) Vendor-Specific Radius: Length = 12 (0x0C) Radius: Vendor ID = 3076 (0x00000C04) Radius: Type = 61 (0x3D) Group-giaddr Radius: Length = 6 (0x06) Radius: Value (IP Address) = 20.0.0.12 (0x1400000C) Radius: Type = 8 (0x08) Framed-IP-Address Radius: Length = 6 (0x06) Radius: Value (IP Address) = 255.255.255.255 (0xFFFFFFFF) Radius: Type = 25 (0x19) Class Radius: Length = 25 (0x19) Radius: Value (String) = 43 41 43 53 3a 30 2f 31 38 63 37 38 2f 38 38 30 | CACS:0/18c78/880 31 37 62 30 63 2f 30 | 17b0c/0 rad_procpkt: ACCEPT
0 comments:
Post a Comment