|
|
Double Authentication provides additional authentication for Point-to-Point Protocol (PPP) sessions. Previously, PPP session authentication was limited to Challenge Handshake Authentication Protocol (CHAP) or Password Authentication Protocol (PAP). With Double Authentication, you essentially require remote users to pass a second stage of user authentication--after CHAP or PAP authentication--before they can gain network access.
When a remote user dials in to a local host (NAS or router) over PPP, CHAP (or PAP) can be used to authenticate the user. However, both of these authentication methods rely on a secret password (the "secret") that must be stored on the remote user host and on the local host. If either host ever comes under the control of a network attacker, the secret password is compromised.
For example, Bob often uses his laptop computer to log into his company's enterprise network, which uses only CHAP for authentication. If Bob's laptop computer is ever stolen, the computer's CHAP password becomes known to the thief. This password (with or without Bob's laptop computer) can now be used to gain access to the company network.
Also, with CHAP or PAP authentication you cannot assign different network access privileges to different remote users who use the same remote host. Because one set of privileges is assigned to a specific host, everybody who uses that host will have the same set of privileges.
If you configure your local host (NAS or router) for Double Authentication, remote users will be required to complete a second stage of authentication to gain network access. This second ("double") authentication requires a password that is known to the user but not stored on the user's remote host. Therefore, the second authentication is specific to a user, not to a host. This provides an additional level of security that will be effective even if the remote host is stolen.
This also provides greater flexibility by allowing customized network privileges for each user.
Moreover, the second stage authentication can use one-time passwords such as token card passwords, which are not supported by CHAP. If one-time passwords are used, a stolen user password is of no use to the perpetrator.
With Double Authentication, there are two authentication/authorization stages. These two stages occur after a remote user dials in and a PPP session is initiated.
In the first stage, CHAP (or PAP) authenticates the remote host, and then PPP negotiates with AAA to authorize the remote host (this assigns network access privileges). When this stage is complete, the remote user has limited network access, restricted to allow only Telnetting to the local host.
In the second stage, the remote user must Telnet to the local host (NAS) to be user-authenticated. When the remote user logs in, they are authenticated with AAA login authentication. The user then must enter the access-profile command to be reauthorized using AAA. When this authorization is complete, the user has been double authenticated, and can access the network according to their per-user network privileges.
You (as system administrator) determine what network privileges remote users will have after each stage of authentication by configuring appropriate parameters on an AAA server. You configure two sets of AAA parameters: one for the CHAP (or PAP) authentication/authorization stage, and another for the second user authentication/authorization stage. (You define these parameters using appropriate attribute value (AV) pairs on the AAA server.)
AAA--Authentication, authorization, and accounting: A facility that provides an interface between Cisco devices and security servers such as RADIUS or TACACS+. AAA provides the Cisco device with information that is used to authenticate hosts or users (authentication), to assign network privileges (authorization), and to record user network activity (accounting).
authentication--The process of confirming that a person or device is who they claim to be. For example, to authenticate a remote host or person, a local host requests a username and password (from the other host or person) and then verifies that the username and password are valid by comparing them to values stored on an AAA server.
authorization--The process of negotiating network access privileges and assigning the privileges to an interface. When assigned to an interface, these privileges apply to any person or device using the interface to gain access to the network. In the context of Double Authentication, first stage authorization is triggered by the PPP session, and second stage authorization is triggered by execution of the access-profile command. The specific network access privileges are stored on an AAA server as AV pairs.
authorization profile--The network access privileges defined for a user on an AAA server. With Double Authentication, separate authorization profiles must be created for the remote host and for the remote user. The appropriate authorization profile is applied to the local host interface after each stage of authentication.
attribute value pairs (AV pairs)--Configuration parameters ("statements") defined on an AAA server. AV pairs are used in Double Authentication to provide the authorization information (authorization profile) for a host or user. Also referred to as "authorization statements" or "authorization attributes."
Challenge Handshake Authentication Protocol (CHAP)--A PPP authentication protocol. When a PPP session initiates, the local device can request remote device CHAP authentication before establishing the PPP session. CHAP uses a secret password stored at both the remote and local device.
Network Access Server (NAS)--A network device that is the entry point into an enterprise network, used by remote users to gain network access. A NAS can be configured as a client network device that makes AAA requests. The NAS can enforce user network privileges.
Password Authentication Protocol (PAP)--A PPP authentication protocol. When a PPP session initiates, the local device can request remote device PAP authentication before establishing the PPP session. PAP uses a secret password stored at both the remote and local device. PAP is considered to be less secure than CHAP.
Point-to-Point Protocol (PPP)--A network-layer encapsulation protocol designed for point-to-point wide area network (WAN) serial connections.
local host--In the context of Double Authentication, and as used in this feature chapter, "local host" refers to the local NAS or router that is used as the entry point into the local enterprise network.
remote host--In the context of Double Authentication, and as used in this feature chapter, "remote host" refers to a remote device (such as a PC or a router) that is used to establish a PPP connection to the local host, to gain access to the enterprise network.
Double Authentication is supported on all Cisco platforms.
You must have a local device (NAS or router) and an AAA server accessible to the local device. The local device and AAA server should be appropriately configured and keyed to communicate with each other.
You should also have a basic understanding of AAA, PPP, and CHAP (or PAP). You should have a basic understanding of how to configure your AAA server.
For more information about AAA, refer to the "Configuring Network Access Security" chapter in the Cisco IOS Release 11.2 Security Configuration Guide. You can also see the feature chapter "Per-User Configuration" in this feature guide.
For specific information about PPP, refer to RFC 1661, "The Point-to-Point Protocol (PPP)."
For specific information about CHAP, refer to RFC 1994, "PPP Challenge Handshake Authentication Protocol (CHAP)."
This section describes the tasks used to configure and activate Double Authentication.
The first section, "Configure Double Authentication," describes tasks that you as a system administrator must accomplish at the local host before Double Authentication can be used.
The second section, "Activate Double Authentication," describes tasks that a remote user must perform in order to activate Double Authentication, so that they can gain appropriate network access privileges.
To configure Double Authentication, you must complete the steps in this section. If you have already completed some of the configuration tasks described, your job will be easier.
Step 1 Configure your local host (NAS or router) to use AAA authentication (for PPP and login) and AAA authorization (network) at login.
Optionally, if you want the access-profile command to be executed as an autocommand (so remote users will not have to manually enter the command to activate Double Authentication), you should also configure your local host to use AAA EXEC authorization.
To learn about configuring AAA authentication and authorization, refer to the "Configuring Network Access Security" chapter in the Cisco IOS Release 11.2 Security Configuration Guide.
Example configurations are found later in this feature chapter. Under "Configuration Examples," see the section "Configuring the Local Host for AAA with Double Authentication Examples."
Step 2 Configure your AAA server (for example, RADIUS or TACACS+) with appropriate authentication and authorization statements to be used with PPP authentication/authorization.
The statements defined in this step will be used during the first authentication/authorization stage of Double Authentication.
Use access control list AV pairs that will limit the user to Telnet to the local host.
To learn about configuring AAA servers, refer to the "Configuring Network Access Security" chapter in the Cisco IOS Release 11.2 Security Configuration Guide.
Example configurations are found later in this feature chapter. Under "Configuration Examples," see the sections "Configuring the AAA Server for First-Stage (PPP) Authentication/Authorization Example" and "Complete Sample Configuration with TACACS+."
Step 3 Configure your AAA server with appropriate authentication and authorization statements to be used with the second stage, per-user authentication/authorization.
The authorization statements defined in this step will be applied in the second stage of Double Authentication. This authorization information is specific to the remote user (not the remote host).
Follow these rules when creating the user-specific authorization statements:
To learn about configuring AAA servers, refer to the "Configuring Network Access Security" chapter in the Cisco IOS Release 11.2 Security Configuration Guide.
To learn about per-user configurations, see the feature chapter "Per-User Configuration" in this feature guide.
Example configurations are found later in this feature chapter. Under "Configuration Examples," see the sections "Configuring the AAA Server for Second-Stage (Per-User) Authentication/Authorization Examples" and "Complete Sample Configuration with TACACS+."
Step 4 If you will be using ISDN or MultiLink PPP, you must also configure virtual templates at the local host.
To learn about configuring virtual templates, see the feature chapters "Virtual Template Interface Service" and "Virtual Profiles" in this feature guide.
Step 5 (Optional) Configure the autocommand access-profile. If you configure the autocommand, the remote user will not have to manually enter the access-profile command to activate Double Authentication. (They will still have to Telnet to the local host and log in.)
To learn about configuring autocommands, refer to the autocommand command in the Cisco IOS Release 11.2 Access Services Command Reference.
After you complete these steps, remote users are able to use (activate) Double Authentication.
If you need to troubleshoot Double Authentication, the debug aaa per-user debug command might be useful. This command is documented in the Cisco IOS Release 11.2 Debug Command Reference.
When a remote user establishes a PPP link to the local host, the remote host is CHAP authenticated (or PAP authenticated). After CHAP (or PAP) authentication, PPP negotiates with AAA to assign network privileges that restrict the user to Telnet to the local host.
To gain additional network privileges, the remote user must activate Double Authentication by Telnetting to the local host and entering the access-profile command.
Note that if you completed Step 5 in the previous section, the access-profile command is executed automatically after the remote user logs in. They do not have to manually enter the command. When the command has completed, the remote user is automatically logged out.
When the remote user Telnets to the local host to activate Double Authentication, they enter a personal username and password (different from the CHAP or PAP username and password). This action causes AAA reauthentication to occur according to their personal username/password.
When the access-profile command is executed, AAA reauthorization occurs. When the remote user is reauthorized, they are granted new, per-user network privileges. (These privileges are per the user's authorization profile defined on the AAA server.)
See the "Command Reference" section in this feature chapter to learn what each form of the access-profile command specifically accomplishes.
The examples in this section illustrate possible configurations to be used with Double Authentication. Your configurations could differ significantly, depending on your network and security requirements.
These examples are included:
An example of a remote user activating Double Authentication is in the "Command Reference" section.
This example configures a local host to use AAA for PPP and login authentication, and for network and EXEC authorization. An example is shown for RADIUS, and another example for TACACS+.
In both examples, the first three lines configure AAA, with a specific server as the AAA server. The next two lines configure AAA for PPP and login authentication, and the last two lines configure network and EXEC authorization. The last line is necessary only if the access-profile command will be executed as an autocommand.
aaa new-model radius-server host secureserver radius-server key myradiuskey aaa authentication ppp default radius aaa authentication login default radius aaa authorization network radius aaa authorization exec radius
aaa new-model tacacs-server host security tacacs-server key mytacacskey aaa authentication ppp default tacacs+ aaa authentication login default tacacs+ aaa authorization network tacacs+ aaa authorization exec tacacs+
This example shows a configuration on the AAA server. A partial sample AAA configuration is shown for RADIUS.
TACACS+ servers can be configured similarly. (See the "Complete Sample Configuration with TACACS+" section later in this document.)
This example defines authentication/authorization for a remote host named "hostx" that will be authenticated by CHAP in the first stage of Double Authentication. Note that the access control list (ACL) AV pair limits the remote host to Telnetting to the local host. The local host has the ip address 10.0.0.2.
hostx Password = "welcome" User-Service-Type = Framed-User, Framed-Protocol = PPP, cisco-avpair = "lcp:interface-config=ip unnumbered ethernet 0", cisco-avpair = "ip:inacl#3=permit tcp any 172.21.114.0 0.0.0.255 eq telnet", cisco-avpair = "ip:inacl#4=deny icmp any any", cisco-avpair = "ip:route#5=55.0.0.0 255.0.0.0", cisco-avpair = "ip:route#6=66.0.0.0 255.0.0.0", cisco-avpair = "ipx:inacl#3=deny any"
This section contains partial sample AAA configurations on a RADIUS server. These configurations define authentication/authorization for a user (Bob) with the username "bobuser," who will be user authenticated in the second stage of Double Authentication.
TACACS+ servers can be configured similarly. (See the "Complete Sample Configuration with TACACS+" section later in this document.)
Three examples show sample RADIUS AAA configurations that could be used with each of the three forms of the access-profile command.
The first example shows a partial sample AAA configuration that works with the default form (no keywords) of the access-profile command. Note that only ACL AV pairs are defined. This example also sets up the access-profile command as an autocommand.
bobuser Password = "welcome" User-Service-Type = Shell-User, cisco-avpair = "shell:autocmd=access-profile" User-Service-Type = Framed-User, Framed-Protocol = PPP, cisco-avpair = "ip:inacl#3=permit tcp any host 10.0.0.2 eq telnet", cisco-avpair = "ip:inacl#4=deny icmp any any"
The second example shows a partial sample AAA configuration that works with the access-profile merge form of the access-profile command. This example also sets up the access-profile merge command as an autocommand.
bobuser Password = "welcome" User-Service-Type = Shell-User, cisco-avpair = "shell:autocmd=access-profile merge" User-Service-Type = Framed-User, Framed-Protocol = PPP, cisco-avpair = "ip:inacl#3=permit tcp any any" cisco-avpair = "ip:route=10.0.0.0 255.255.0.0", cisco-avpair = "ip:route=10.1.0.0 255.255.0.0", cisco-avpair = "ip:route=10.2.0.0 255.255.0.0"
The third example shows a partial sample AAA configuration that works with the access-profile replace form of the access-profile command. This example also sets up the access-profile replace command as an autocommand.
bobuser Password = "welcome" User-Service-Type = Shell-User, cisco-avpair = "shell:autocmd=access-profile replace" User-Service-Type = Framed-User, Framed-Protocol = PPP, cisco-avpair = "ip:inacl#3=permit tcp any any", cisco-avpair = "ip:inacl#4=permit icmp any any", cisco-avpair = "ip:route=10.10.0.0 255.255.0.0", cisco-avpair = "ip:route=10.11.0.0 255.255.0.0", cisco-avpair = "ip:route=10.12.0.0 255.255.0.0"
This example causes Double Authentication to fail; the PPP session will drop the IP protocol. This example is invalid because it configures the default form of the access-profile command as an autocommand, and the default form of the command fails if there are any non-ACL AV pairs defined. This example has a route AV pair in the last line.
bobuser Password = "welcome" User-Service-Type = Shell-User, cisco-avpair = "shell:autocmd=access-profile" User-Service-Type = Framed-User, Framed-Protocol = PPP, cisco-avpair = "ip:inacl#3=permit tcp any host 10.0.0.2 eq telnet", cisco-avpair = "ip:inacl#4=deny icmp any any", cisco-avpair = "ip:route=172.16.0.0 255.255.0.0"
This example shows a TACACS+ configuration file. Figure 7 shows the topology.
This example shows TACACS+ authorization profile configurations both for the remote host (used in the first stage of Double Authentication) and for specific users (used in the second stage of Double Authentication). This TACACS+ example contains approximately the same configuration information as shown in the previous RADIUS examples.
This sample configuration shows authentication/authorization profiles on the TACACS+ server for the remote host "hostx" and for three users, with the usernames "bob_default," "bob_merge," and "bob_replace." The configurations for these three usernames illustrate different configurations that correspond to the three different forms of the access-profile command. The three user configurations also illustrate setting up the autocommand for each form of the access-profile command.
key = "mytacacskey"
default authorization = permit
#-----------------------------Remote Host (BRI)-------------------------
#
# This allows the remote host to be authenticated by the local host
# during fist-stage authentication, and provides the remote host
# authorization profile.
#
#-----------------------------------------------------------------------
user = hostx
{
login = cleartext "welcome"
chap = cleartext "welcome"
service = ppp protocol = lcp {
interface-config="ip unnumbered ethernet 0"
}
service = ppp protocol = ip {
# It is important to have the hash sign and some string after
# it. This indicates to the NAS that you have a per-user
# config.
inacl#3="permit tcp any 172.21.114.0 0.0.0.255 eq telnet"
inacl#4="deny icmp any any"
route#5="55.0.0.0 255.0.0.0"
route#6="66.0.0.0 255.0.0.0"
}
service = ppp protocol = ipx {
# see previous comment about the hash sign and string, in protocol = ip
inacl#3="deny any"
}
}
#------------------- "access-profile" default user "only acls" ----------------
#
# - Without arguments, access-profile removes any access-lists it can find
# in the old configuration (both per-user and per-interface), and makes sure
# that the new profile contains ONLY access-list definitions.
#
#--------------------------------------------------------------------------------
user = bob_default
{
login = cleartext "welcome"
chap = cleartext "welcome"
service = exec
{
# this is the autocommand that executes when bob_default logs in
autocmd = "access-profile"
}
service = ppp protocol = ip {
# Put whatever access-lists, static routes, whatever
# here.
# If you leave this blank, the user will have NO IP
# access-lists (not even the ones installed prior to
# this)!
inacl#3="permit tcp any host 10.0.0.2 eq telnet"
inacl#4="deny icmp any any"
}
service = ppp protocol = ipx {
# Put whatever access-lists, static routes, whatever
# here.
# If you leave this blank, the user will have NO IPX
# access-lists (not even the ones installed prior to
# this)!
}
}
#--------------------- "access-profile merge" user ----------------------
#
# With the 'merge' option, first all old access-lists are removed (as before),
# but then (almost) all AV pairs are uploaded and installed. This
# will allow for uploading any custom static routes, sap-filters, and so on,
# that the user may need in his or her profile. This needs to be used with
# care, as it leaves open the possibility of conflicting configurations.
#
#-----------------------------------------------------------------------------
user = bob_merge
{
login = cleartext "welcome"
chap = cleartext "welcome"
service = exec
{
# this is the autocommand that executes when bob_merge logs in
autocmd = "access-profile merge"
}
service = ppp protocol = ip
{
# Put whatever access-lists, static routes, whatever
# here.
# If you leave this blank, the user will have NO IP
# access-lists (not even the ones installed prior to
# this)!
inacl#3="permit tcp any any"
route#2="10.0.0.0 255.255.0.0"
route#3="10.1.0.0 255.255.0.0"
route#4="10.2.0.0 255.255.0.0"
}
service = ppp protocol = ipx
{
# Put whatever access-lists, static routes, whatever
# here.
# If you leave this blank, the user will have NO IPX
# access-lists (not even the ones installed prior to
# this)!
}
}
#--------------------- "access-profile replace" user -----------------------
#
#- With the 'replace' option,
# ALL old configuration is removed and ALL new configuration is installed.
#
# One caveat: access-profile checks the new configuration for address-pool and
# address AV pairs. As addresses cannot be renegotiated at this point, the
# command will fail (and complain) when it encounters such an AV pair.
# Such AV pairs are considered to be "invalid" for this context.
#-------------------------------------------------------------------------------
user = bob_replace
{
login = cleartext "welcome"
This section documents the new access-profile command used to activate Double Authentication.
To apply your per-user authorization attributes to an interface during a PPP session, use the access-profile EXEC command. Use the default form of the command (no keywords) to cause existing access control lists (ACLs) to be removed, and ACLs defined in your per-user configuration to be installed. Refer to the "Usage Guidelines" section that follows to learn what each form of the command specifically accomplishes.
access-profile [merge | replace]| merge | (Optional) Like the default form of the command, this option removes existing access control lists (ACLs) while retaining other existing authorization attributes for the interface.
However, using this option also installs per-user authorization attributes in addition to the existing attributes. (The default form of the command installs only new ACLs.) The per-user authorization attributes come from all AV pairs defined in the AAA per-user configuration (the user's authorization profile). The interface's resulting authorization attributes are a combination of the previous and new configurations. |
| replace | (Optional) This option removes existing access control lists (ACLs) and all other existing authorization attributes for the interface.
A complete new authorization configuration is then installed, using all AV pairs defined in the AAA per-user configuration. This option is not normally recommended because it initially deletes all existing configuration, including static routes. This could be detrimental if the new user profile does not reinstall appropriate static routes and other critical information. |
User EXEC
This command first appeared in Cisco IOS Release 11.2 F.
Remote users can use this command to activate Double Authentication for a PPP session. Double Authentication must be correctly configured for this command to have the desired effect.
You should use this command when you are a remote user and are establishing a PPP link to gain local network access.
After you have been authenticated with CHAP (or PAP), you will have limited authorization. To activate Double Authentication and gain your appropriate user network authorization, you must Telnet to the NAS and execute the access-profile command. (This command could also be set up as an autocommand, which would eliminate the need to manually enter the command.)
This command causes all subsequent network authorizations to be made in your username, instead of in the remote host's username.
Any changes to the interface caused by this command will stay in effect for as long as the interface stays up. These changes will be removed when the interface goes down. This command does not affect the normal operation of the router or the interface.
The default form of the command, access-profile, causes existing access control lists (ACLs) to be unconfigured (removed), and new ACLs to be installed. The new ACLs come from your per-user configuration on an AAA server (such as a TACACS+ server). The ACL replacement constitutes a reauthorization of your network privileges.
The default form of the command can fail if your per-user configuration contains statements other than ACL AV pairs. Any protocols with non-ACL statements will be deconfigured, and no traffic for that protocol can pass over the PPP link.
The access-profile merge form of the command causes existing ACLs to be unconfigured (removed) and new authorization information (including new ACLs) to be added to the interface. This new authorization information consists of your complete per-user configuration on an AAA server. If any of the new authorization statements conflict with existing statements, the new statements could "override" the old statements or be ignored, depending on the statement and applicable parser rules. The resulting interface configuration is a combination of the original configuration and the newly installed per-user configuration.
 | Caution The new user authorization profile (per-user configuration) must not contain any invalid mandatory AV pairs, otherwise the command will fail and the PPP protocol (containing the invalid pair) will be dropped. If invalid AV pairs are included as optional in the user profile, the command will succeed, but the invalid AV pair will be ignored. Invalid AV pair types are listed later in this section. |
The access-profile replace form of the command causes the entire existing authorization configuration to be removed from the interface, and the complete per-user authorization configuration to be added. This per-user authorization consists of your complete per-user configuration on an AAA server. The caution of the previous paragraph applies.
| Caution Use extreme caution when using the access-profile replace form of the command. It might have detrimental and unexpected results, because this option deletes all authorization configuration information (including static routes) before reinstalling the new authorization configuration. |
Invalid AV pair types:
| Caution You should think carefully about using Double Authentication if you have a network topology similar to the one shown in Figure 8. Certain events can occur with this topology that cause possibly undesirable conditions, as described in the next two paragraphs. First, if Bob initiates a PPP session and activates Double Authentication at the local host (per Figure 8), Jane will automatically have the same network privileges as Bob, until Bob's PPP session expires. This happens because Bob's authorization profile is applied to the local host's interface during his PPP session, and any PPP traffic from Jane will use the PPP session established by Bob. Second, if Bob initiates a PPP session and activates Double Authentication, and then--before Bob's PPP session has expired--Jane executes the access-profile command (or, if she Telnets to the local host and autocommand access-profile is executed), a reauthorization will occur and Jane's authorization profile will be applied to the interface...replacing Bob's profile. This can disrupt or halt Bob's PPP traffic, or grant Bob additional authorization privileges he should not have. |
This example activates Double Authentication for a remote user. This example assumes that the access-profile command was not configured as an autocommand.
The remote user connects to the corporate headquarters network per Figure 9.
The remote user runs a terminal emulation application to Telnet to the corporate NAS, an AS5200 local host named "hqnas." The remote user, named Bob, has the username "BobUser."
This example replaces access control lists (ACLs) on the local host PPP interface. The ACLs previously applied to the interface during PPP authorization are replaced with ACLs defined in the per-user configuration AV pairs.
The remote user Telnets to the local host and logs in:
login:BobUserPassword:<welcome>hqnas>access-profile
Bob is reauthenticated when he logs in to hqnas, because hqnas is configured for login AAA authentication using the corporate RADIUS server. When Bob enters the access-profile command, he is reauthorized with his per-user configuration privileges. This causes the access lists and filters in his per-user configuration to be applied to the NAS interface.
After the reauthorization is complete, Bob is automatically logged out of the AS5200 local host.
connect
telnet
|
|