For more information on Security, visit our Security Reference Guide or sign up for our Security Newsletter
Telecommuting is increasingly becoming a part of everyday life, and IPSec connectivity is arguably the most popular connection method that telecommuters use to connect to a VPN across the public Internet. Given that telecommuters can be anywhere in the Internet, the successful completion of authorization and authentication is critical for granting access to the VPN. This chapter explores authentication and authorization models for the IPSec telecommuter.
Extended Authentication (XAUTH) and Mode Configuration (MODE-CFG)
Authentication schemes such as Remote Authentication Dial-In User Service (RADIUS) and SecureID are commonly used for providing secure remote access. It is highly desirable to leverage these authentication mechanisms for IPSec remote access. But Internet Key Exchange (IKE) protocol, which you learned about in Chapter 2, "IPSec Overview," does not provide a method to leverage these unidirectional authentication schemes. Extended Authentication, commonly referred to as XAUTH, was developed to leverage these legacy authentication schemes with IKE.
XAUTH provides an additional level of authentication by allowing the IPSec gateway to request extended authentication from remote users, thus forcing remote users to respond with their credentials before being allowed access to the VPN. It should be noted that XAUTH functions by first forming an IKE phase 1 SA using conventional IKE, and then by extending the IKE exchange to include additional user authentication exchanges. Figure 4-1 shows an XAUTH exchange using a generic username and password authentication scheme.
)
Figure 4-1 Extended Authentication (XAUTH) Exchange
As shown in Figure 4-1, XAUTH uses a Request/Reply mechanism to provide the extended authentication. The XAUTH process is terminated, either when the gateway starts a SET/ACK exchange, which includes an XAUTH_STATUS attribute, or when the remote device sends a XAUTH_STATUS attribute in a REPLY message.
The XAUTH protocol defines four message types that are exchanged between the remote user and the IPSec gateway. These messages carry various attributes for the extended authentication process to work. The four XAUTH message types are:
- ISAKMP_CFG_REQUEST
- ISAKMP_CFG_REPLY
- ISAKMP_CFG_SET
- ISAKMP_CFG_ACK
A description of the XAUTH message types follows:
- ISAKMP_CFG_REQUEST— This message is sent from the IPSec gateway to the IPSec client requesting extended authentication of the client.
- ISAKMP_CFG_REPLY— This message must contain the filled-in authentication attributes that were requested by the gateway or, if the proper authentication attributes cannot be retrieved, this message must contain the XAUTH_STATUS attribute with a value of FAIL.
- ISAKMP_CFG_SET— This message is sent from the gateway and is used only to state the success or failure of the authentication.
- ISAKMP_CFG_ACK— This message is sent from the IPSec client, acknowledging receipt of the authentication result.
The XAUTH message types defined above carry various attributes. A brief description of the attributes is shown in Table 4-1.
Table 4-1. XAUTH Attributes
|
Attribute |
Description |
|
XAUTH_TYPE |
This attribute describes the type of extended authentication method requested. Four authentication methods are defined in the protocol: Generic, RADIUS_CHAP, One Time password (OTP), and Secure ID. This is an optional attribute for the ISAKMP_CFG_REQUEST and ISAKMP_CFG_REPLY messages. The XAUTH_TYPE in a REPLY must be identical to the XAUTH_TYPE in the REQUEST. However, an XAUTH transaction may have multiple REQUEST/REPLY pairs with different XAUTH_TYPE values in each pair. |
|
XAUTH_USER_NAME |
The username may be any unique identifier of the user, such as a login name, an email address, or a X.500 Distinguished Name. |
|
XAUTH_USER_PASSWORD |
The user's password. |
|
XAUTH_PASSCODE |
A token card's passcode. |
|
XAUTH_MESSAGE |
A textual message from the gateway to the IPSec client. The message may contain a textual challenge or instruction. |
|
XAUTH_CHALLENGE |
A challenge string sent from the gateway to the IPSec client to be included in its calculation of a password. This attribute should be sent only in an ISAKMP_CFG_REQUEST message. Typically, the XAUTH_TYPE attribute dictates how the receiving device should handle the challenge. For example, RADIUS-CHAP uses the challenge to hide the password. |
|
XAUTH_STATUS |
A variable that is used to denote authentication success (OK=1) or failure (FAIL=0). This attribute must be sent in the ISAKMP_CFG_SET message, in which case it may be set to either OK or FAIL, and may be sent in a REPLY message by a remote peer, in which case it must be set to FAIL. |
When a remote access user connects to an IPSec gateway and XAUTH is required by the gateway, configuration on the gateway initiates the XAUTH messages before IKE phase 2 negotiation begins. If the remote access client does not have support for the authentication method requested by the gateway, the client would send back a REPLY with the XAUTH_STATUS attribute set to FAIL, thus failing the authentication.
Example 4-1 shows the configuration of XAUTH using the RADIUS/AAA authentication method.
Example 4-1. Cisco IOS XAUTH Configuration on the IPSec Gateway
vpn-gw1-east# ! hostname vpn-gw1-east ! username ezvpn password 0 east username ezvpn1@vpngroup password 0 ezvpn1east username ezvpn2@vpngroup password 0 ezvpn2east aaa new-model ! aaa authentication login vpn local aaa authorization network vpn local aaa session-id common ip subnet-zero ! crypto isakmp policy 1 encr 3des authentication pre-share group 2 crypto isakmp keepalive 10 10 ! crypto ipsec transform-set vpn esp-3des esp-sha-hmac ! crypto dynamic-map dynamic 1 set transform-set vpn reverse-route remote-peer 9.1.1.33 ! ! crypto map vpn client authentication list vpn crypto map vpn isakmp authorization list vpn crypto map vpn client configuration address respond crypto map vpn 3 ipsec-isakmp dynamic dynamic
The addition of the following command on the crypto map enables XAUTH and triggers the XAUTH transaction after IKE phase 1 and before IKE phase 2:
crypto map map-name client authentication list list-name
As you learned in Chapter 2, "IPSec Overview," a very common deployment scenario for IPSec telecommuters is the use of IKE pre-shared key authentication with Aggressive Mode. The primary motivation for this scenario is that the IP address of an IPSec remote access user connecting to an IPSec gateway over the public Internet is typically not known in advance to the gateway. In most deployments using pre-shared keys, a single shared group key is used for all users of the VPN. What this means is that without employing some form of additional user authentication, there is no way to verify that the person connecting with that VPN client is indeed a valid user.
Imagine, for example, a situation where a laptop with a VPN client is stolen—because the VPN client is already configured with a valid group key, anyone with the laptop can connect to the VPN without any problems, as no further authentication is required! Extended Authentication (XAUTH) is widely employed to address this serious security gap. XAUTH forces users to identify themselves with a user id and a password after the group pre-shared key has been verified.
XAUTH is also referred to as "two factor authentication." The password could be a "one-time password" (for example, from a SecureID card) adding further security to such a deployment. Although the usage of XAUTH is very common and desired for the telecommuter scenario using pre-shared keys and Aggressive Mode, it can also be used with Main Mode and other authentication methods such as digital certificates. It is important to note that although XAUTH is deployed very commonly, it has not been established as a standard by the IPSec working group in the IETF, which means that it may present interoperability issues among different vendor implementations.