Access Security Settings

This appendix contains the following sections:

Introduction

Using call information

Password-protecting Telnet access

Password protecting terminal-server connections

PPP authentication

Token card authentication

Introduction
Using call information
Password-protecting Telnet access
Password protecting terminal-server connections
PPP authentication
Token card authentication

Introduction

Access security is the first line of defense against unauthorized access to your network. It uses an exchange of information to verify the identity of a user. The information is usually encrypted at both ends.

This appendix describes the kinds of access security supported in the MAX TNT. For information about controlling who can access the MAX TNT itself, and about limiting what users can do once they have accessed your network, see Appendix B, Network Security Settings.

What are your options?

The MAX TNT supports a variety of access security options. You can:

Use Calling-Line ID (CLID), which might be provided by the Telco as part of the call, to verify that the call is being placed from a trusted telephone number.
Use Dial Number Information Service (DNIS), which might be provided by the Telco as part of an ISDN message, to verify the called number.
Use Callback security. After authentication is complete, the MAX TNT can hang up and call back, thus ensuring that the connection is made only with a trusted number.
Use Expect-Send scripts to authenticate logins to the terminal server.
Use authentication protocols to authenticate PPP, MP, or MP+ calls during session negotiation. Following are the supported protocols:
- Password Authentication Protocol (PAP).
- Challenge Handshake Authentication Protocol (CHAP), which includes encryption.
- Microsoft's extension of CHAP (MS-CHAP).
Use token cards to overcome the limitations of static passwords.

Using call information

To have the MAX TNT extract CLID or DNIS information that the Telco includes with each call, and use the information to authenticate the call, you only have to set one parameter in the Answer-Defaults profile and a few parameters in each affected Connection profile. Following are the basic parameters, with examples of their settings:

ANSWER-DEFAULTS
      clid-auth-mode = clid-prefer

CONNECTION station
      clid = 555-1212
      calledNumber = 1234

First, set the Answer-Defaults profile's CLID-Auth-Mode parameter to specify what the MAX TNT should do with the Telco information. For example, the Clid-Prefer setting specifies that the system authenticates the call using the CLID, if it is available. If the CLID is not available, the system uses the type of authentication specified in the Answer-Defaults profile. The setting you select applies to both CLID and DNIS.

Next, specify the Calling-Line ID (CLID) or DNIS number (CalledNumber) in a Connection profile. The MAX TNT compares the call information to the number in the profile, and can reject the call if the numbers don't match.

If you are using Callback, specify the dial number, which the MAX TNT will call back to establish the authenticated session. Also set the Callback parameter to Yes, and make sure the Answer-Originate parameter allows the MAX TNT to both place and receive calls. Following are the related parameters with examples of their settings:

CONNECTION station
      dial-number = 1212
      telco-options
            answer-originate = ans-and-orig
            callback = yes

Considerations

The MAX TNT matches CLID and DNIS numbers before password authentication. Callback, in which the MAX TNT hangs up on the caller and uses the dial number to call back, occurs after password authentication.

CLID

You can use CLID for access security only where the call information is available end-to-end and ANI (Automatic Number Identification) applies to the call. In some areas, the WAN provider might not be able to deliver CLIDs, or a caller might keep a CLID private.

CLID verification occurs before the MAX TNT accepts a call and begins the process of authenticating a password. Typically, people use CLID to protect against the situation where an unauthorized user obtains the name, password, and IP address of an authorized user, and calls in from another location.

Note: In systems using E1-Chinese-Signaling, the Caller-ID parameter in the E1 line profile must be set to Get-Caller-ID for CLID authentication to work.

DNIS or called number

An ISDN message presents the called number (which typically is the number dialed by the far end) as part of the call when DNIS is in use. The phone company might present a modified called number for DNIS, in which case the CalledNumber parameter in a Connection profile must specify the modified number.

The MAX TNT can use the called number for authentication, but more often it uses the called number to direct the inbound calls to a particular device.

Configuring the MAX TNT to use call information

By default, the MAX TNT ignores CLID and DNIS information, even if the caller presents it. To use the information, set the CLID-Auth-Mode parameter in the Answer-Defaults profile, as shown in the following example:

admin> read answer
ANSWER-DEFAULTS read

admin> set clid-auth-mode = clid-prefer

admin> write
ANSWER-DEFAULTS written

Ignore is the default setting, which means the MAX TNT doesn't require a matching ID in the call and doesn't use an ID even if the call contains one.

Note: RADIUS profiles have special requirements for CLID authentication. For details, see the MAX TNT RADIUS Guide.

Using the CLID information

When you set CLID-Auth-Mode to CLID-Require, the MAX TNT must receive a CLID from the call, or it refuses the call. When it receives a CLID, it tries to match the CLID to the CLID parameter in a Connection profile or to a RADIUS user profile set up to verify the CLID. If the MAX TNT doesn't receive a CLID or doesn't find a matching profile, it refuses the call.

When you set CLID-Auth-Mode to CLID-Prefer and the MAX TNT receives a CLID from the call, it tries to match the CLID to the CLID parameter in a Connection profile or to a RADIUS user profile set up for to verify the CLID. (See the MAX TNT RADIUS Guide.) If the MAX TNT doesn't receive a CLID or doesn't find a matching profile, it uses whatever authentication is configured in the Answer-Defaults profile.

The CLID-Fallback setting applies only when a RADIUS server authenticates the connection. The MAX TNT must receive a CLID from the call, or it refuses the call. However, it attempts to match the CLID only if the RADIUS server is available. If the MAX TNT doesn't receive a response from the RADIUS server, it uses whatever authentication is configured in the Answer-Defaults profile.

Using the called number

When you set CLID-Auth-Mode to DNIS-Require, the MAX TNT must receive a called number with the call, or it refuses the call. When it receives a called number, it tries to match the number to the CalledNumber parameter in a Connection profile or to a RADIUS user profile set up for called-number authentication. If the MAX TNT doesn't receive a called number or doesn't find a matching profile, it refuses the call.

When you set CLID-Auth-Mode to DNIS-Prefer and the MAX TNT receives a called number from the call, it tries to match the number to the CalledNumber parameter in a Connection profile or to a RADIUS user profile set up for called-number authentication. If the MAX TNT doesn't receive a called number or doesn't find a matching profile, it uses whatever authentication is configured in the Answer-Defaults profile.

Specifying the CLID in a Connection profile

After you have set the CLID-Auth-Mode parameter in the Answer-Defaults profile, specify the number to be matched in a Connection profile. For example:

admin> read conn tommy
CONNECTION/tommy read

admin> set clid = 555-1212

admin> write
CONNECTION/tommy written

Note: In systems using E1-Chinese-Signaling, the Caller-ID parameter in the E1 line profile must be set to Get-Caller-ID for CLID authentication to work.

Specifying the called number in a Connection profile

After you have set the CLID-Auth-Mode parameter in the Answer-Defaults profile, specify the number to be matched in a Connection profile. For example:

admin> read conn tommy
CONNECTION/tommy read

admin> set calledNumber = 1234

admin> write
CONNECTION/tommy written

Using callback for added security

Companies use Callback for a variety of reasons, such as savings on phone charges, but the primary use is for security: to ensure that the connection is made with a known phone number. Hanging up and calling back adds a level of certainty that the connection is with a trusted user, especially because the MAX TNT does so immediately after verifying the user's name and password. For the MAX TNT to use Callback, it must be able to both receive and initiate calls. Following is an example of configuring the Answer-Originate and Callback parameters:

admin> read conn tommy
CONNECTION/tommy read

admin> set dial-number = 1212

admin> set telco answer-originate = ans-and-orig

admin> set telco callback = yes

admin> write
CONNECTION/tommy written

Password-protecting Telnet access

Once you have set up a basic IP configuration in the MAX TNT system, as described in Chapter 4, IP Routing, users can Telnet into the MAX TNT command line. A user can initiate a Telnet session to the MAX TNT from a local workstation or from a WAN connection. In both cases, the MAX TNT authenticates the session by means of a User profile, which defines a permission level for the user logging in. (For details of User profiles, see the MAX TNT Reference Guide.)

In addition to the password required by a User profile, you can specify that Telnet requires its own password authentication, which occurs before any User profile authentication. Following is the parameter for setting a system-wide Telnet password (the value shown is the default):

IP-GLOBAL
      telnet-password = ""

By default, the system has the null password for Telnet access, which means the MAX TNT does not prompt users for a password. The following set of commands specifies a Telnet password:

admin> read ip-global
IP-GLOBAL read

admin> set telnet-password = secret

admin> write
IP-GLOBAL written

The specified password can be up to 20 characters. After you set the Telnet password, users are prompted for that password first. If they specify the correct Telnet password, the MAX TNT prompts again for a user name and password to authenticate a User profile. In the following example, a user starts a Telnet session to a MAX TNT unit named TNT01, which has a configured Telnet password.

% telnet tnt01
<tnt01> Enter Password:

Trying 10.1.2.3 ...
Connected to tnt01.abc.com.
Escape character is `^]'.
User:

After specifying the correct Telnet password, the user is prompted for a user name and password to authenticate a User profile.

Password protecting terminal-server connections

Terminal-server connections are asynchronous calls that are usually initiated by a dial-in user. Depending on the dial-in client software, the call may initiate a login session or an asynchronous Point-to-Point Protocol (PPP) connection.

When the terminal server receives an asynchronous call, it waits briefly to receive a PPP packet. If it times out waiting for the packet, the terminal server sends its Login prompt. When it receives a name and password from the caller, it authenticates them against a Connection profile or by means of an external authentication server, and then performs one of the following actions:

Displays the terminal-server command-line prompt
Displays a menu of up to four hosts the user can log into
Immediately logs the user into a designated host
Proceeds to initiate a PPP or SLIP session with the user

For information about authorizing one of these actions for incoming login sessions, see Appendix B, Network Security Settings.

When the terminal server receives an asynchronous call and immediately detects a PPP packet, it does not send a Login prompt. Instead, it responds with a PPP packet, and Link Control Protocol (LCP) negotiation begins, including negotiation for PAP or CHAP authentication. Establishment of the connection then proceeds as for a regular (synchronous) PPP session. (See PPP authentication for the details of how names and passwords are exchanged in PPP sessions.)

Recommended settings for modem and terminal-adapter calls

When the MAX TNT receives a call from a modem or a V.120 terminal adapter (TA), it passes the call to the terminal-server software. Depending on the dial-in client software, the call may initiate a login session or an asynchronous PPP connection. Table A-1 shows some recommended settings for the dial-in client software used with modems or terminal adapters:

Table A-1. Recommended authentication settings for terminal-server calls

Setup

Recommendation

Analog modem with PPP software

The caller's PPP dial-in software immediately begins sending PPP packets, so its configuration should not include an Expect-Send script. The password in the caller's Connection profile is authenticated during LCP negotiation. (See PPP authentication.)

Analog modem with a communications package

If the dial-in software does not use PPP, it waits for a prompt and then either executes an Expect-Send script or waits for the user to manually log in. Here is a sample script:

expect "Login:" send $username expect "Password:" send $password

V.120 TA dialing a PPP connection

If the TA is configured to run PPP, it can handle PAP or CHAP authentication as well as other PPP or MP features the TA supports. The TA immediately begins sending PPP packets, so its configuration should not include an Expect-Send script. The password in the caller's Connection profile is authenticated during LCP negotiation.

V.120 TA with PPP turned off

If the V.120 TA is configured to run without PPP, it does not support PAP or CHAP authentication. It waits for a prompt and then either executes an Expect-Send script or waits for the user to manually log in. Here is a sample script:

expect "Login:" send $username expect "Password:" send $password

Table A-1. Recommended authentication settings for terminal-server calls
Setup	Recommendation
Analog modem with PPP software	The caller's PPP dial-in software immediately begins sending PPP packets, so its configuration should not include an Expect-Send script. The password in the caller's Connection profile is authenticated during LCP negotiation. (See PPP authentication.)
Analog modem with a communications package	If the dial-in software does not use PPP, it waits for a prompt and then either executes an Expect-Send script or waits for the user to manually log in. Here is a sample script: expect "Login:" send $username expect "Password:" send $password
V.120 TA dialing a PPP connection	If the TA is configured to run PPP, it can handle PAP or CHAP authentication as well as other PPP or MP features the TA supports. The TA immediately begins sending PPP packets, so its configuration should not include an Expect-Send script. The password in the caller's Connection profile is authenticated during LCP negotiation.
V.120 TA with PPP turned off	If the V.120 TA is configured to run without PPP, it does not support PAP or CHAP authentication. It waits for a prompt and then either executes an Expect-Send script or waits for the user to manually log in. Here is a sample script: expect "Login:" send $username expect "Password:" send $password

How security mode affects terminal-server authentication

You may choose to assign the terminal server its own password, to protect the command line from unauthorized access. If you assign a terminal-server password, you must also set the Security-Mode parameter to specify how to use the password. Following are the relevant parameters with their default settings:

TERMINAL-SERVER
      security-mode = none
      terminal-mode-configuration
            system-password = ""

The meaning of the Security-Mode setting depends partly on whether users log into menu mode or terminal mode. Table A-2 shows your choices:

Table A-2. Security modes in the terminal server

Setting

Effect

None

Users are not prompted for a login name and password when accessing the terminal server.

Partial

Users must supply a name and password to enter the terminal server except when entering menu mode.

Full

Users must always supply a name and password to enter the terminal server.

Table A-2. Security modes in the terminal server
Setting	Effect
None	Users are not prompted for a login name and password when accessing the terminal server.
Partial	Users must supply a name and password to enter the terminal server except when entering menu mode.
Full	Users must always supply a name and password to enter the terminal server.

The System-Password may include up to 15 characters. In the following example, the administrator configures full password security in the terminal server and specifies the system password:

admin> read terminal-server
TERMINAL-SERVER read

admin> set security-mode = full

admin> set terminal system-password = secret

admin> write
TERMINAL-SERVER written

Specifying terminal-server password settings

A dial-in user logging into the terminal server typically receives the following sequence of prompts:

** Ascend TNT Terminal Server **

System Password:

Login:
Password:

Following are the parameters that define which strings are sent to and expected from a dial-in user during the login process:

TERMINAL-SERVER
      terminal-mode-configuration
            system-password = *******
            banner = "** Ascend TNT Terminal Server **"
            login-prompt = "Login: "
            password-prompt = "Password: "
            prompt = "ascend% "
            login-timeout = 300

The Banner parameter defines the first line sent to the dial-in user. Alternatively, RADIUS can set a multi-line banner.

The System-Password parameter specifies a password required to gain access to the terminal server. If the password is null or the Security-Mode parameter is set to None, the MAX TNT does not prompt for the system password. (For a discussion of the Security-Mode parameter, see How security mode affects terminal-server authentication.)

The Login-Prompt and Password-Prompt parameters specify the next two lines sent to the dial-in user. The MAX TNT uses the name and password supplied by the user to authenticate a Connection profile or a profile on an external authentication server.

The Login-Timeout parameter specifies how long the login prompt will be displayed before a connection is terminated. When a user logs into the terminal server in terminal mode, a login prompt appears. If the user does not proceed any further than the login prompt within 300 seconds, the login times out. If you set the Login-Timeout parameter to zero, the login never times out.

If you change the login and command-line prompt default settings, make sure that the users' Expect-Send scripts are written to expect the strings you specify.

Following is an example of configuring the banner, login prompts, command-line prompt, and login timeout:

admin> read terminal-server
TERMINAL-SERVER read

admin> set terminal banner = "ABC Corp. Terminal Server"

admin> set terminal login-prompt = "Name:"

admin> set terminal password-prompt = "Password:"

admin> set terminal prompt = "ABC: "

admin> set terminal login-timeout = 60

admin> write
TERMINAL-SERVER written

The Expect-Send script on the other side must expect compatible strings. For example:

expect "Name:" send username expect "Password:" send password expect "ABC Corp. Terminal Server" send "" expect "ABC: " send "SLIP"

How immediate mode affects terminal-server authentication

If the terminal server is set up for immediate mode, it uses the specified service (TCP, Rlogin, or Telnet) to send the data stream of a call directly to a host for login. (For information about immediate mode, see Authorizing immediate mode access of Appendix B, Network Security Settings. )

If the incoming call is TCP-clear (unencapsulated) or V.120, the call is authenticated in the terminal server as usual and then directed to the Telnet host, where the user logs in according to the login sequence on that host. In this case, immediate mode does not affect terminal-server authentication.

However, if the call uses PPP encapsulation, the normal course of events for the MAX TNT is to authenticate the call by means of PAP or CHAP and then use the router software to establish an async PPP session. To avoid redirection of the call and enable the user to log into the Telnet host instead, you must set the Telnet-Host-Auth parameter to Yes. Following is the parameter that you have to change:

TERMINAL-SERVER
      immediate-mode-options
            telnet-host-auth = no

The Telnet-Host-Auth parameter is related only to asynchronous PPP calls in immediate mode. If it is set to No, the calls fail. If it is set to Yes, the MAX TNT terminal server processes the calls and directs them to the Telnet host rather than to the unit's router software.

When to use the third prompt

Some RADIUS servers require an additional (third) login prompt, defined by the Ascend-Third-Prompt attribute (213). If the call is authenticated by RADIUS, and the profile specifies a value for this attribute, you should configure the terminal server to display the required prompt. If RADIUS expects a third prompt, it always expects it last, after the regular login sequence.

Some ISPs use a terminal server that follows a login sequence different from that used by Ascend (for example, one that includes a menu selection before login). If that is the case at your site, you should configure the terminal server to display the required prompt and specify that it should be displayed first, to mimic the other terminal server and retain compatibility with client software in use by subscribers.

Following are the relevant parameters (with their default values):

TERMINAL-SERVER
      terminal-mode-configuration
            third-login-prompt = ""
            third-prompt-sequence = last

The following example shows how to configure these parameters for a RADIUS server that expects a third prompt:

admin> read terminal-server
TERMINAL-SERVER read

admin> set terminal third-login-prompt = Third-Prompt>

admin> set terminal third-prompt-sequence = last

admin> write
TERMINAL-SERVER written

The next example shows how to configure these parameters to mimic another terminal server that expects users to select a service prior to login:

admin> read terminal-server
TERMINAL-SERVER read

admin> set terminal third-login-prompt = Service?

admin> set terminal third-prompt-sequence = first

admin> write
TERMINAL-SERVER written

PPP authentication

During establishment of a PPP data link, the dialing and answering units exchange Link Control Protocol (LCP) packets to establish communications and configure the link. When the link is established, PPP provides for an optional authentication exchange before exchanging Network Control Protocols (NCPs) to set up the link's network-layer protocols.

If a PPP link is configured to require authentication, the units at each end negotiate an authentication protocol. A multilink connection begins with authentication of a base channel. Subsequent channels are authenticated separately when the additional connections are dialed.

PPP authentication in the Answer-Defaults profile

The Answer-Defaults profile specifies whether the MAX TNT rejects incoming PPP calls that do not offer any authentication protocol. You can also use the profile to restrict which authentication protocols the MAX TNT accepts. Following is the relevant parameter (shown with a sample setting):

ANSWER-DEFAULTS
      ppp-answer
            receive-auth-mode = pap-ppp-auth

The Receive-Auth-Mode parameter typically specifies a general setting to support the widest range of authentication protocols. For example:

admin> read answer
ANSWER-DEFAULTS read

admin> set ppp receive-auth-mode = any-ppp-auth

admin> write
ANSWER-DEFAULTS written

When you specify Any-PPP-Auth as the method of PPP authentication, the MAX TNT accepts incoming PPP calls that support any of the authentication methods, but it drops connections that do not offer any authentication protocols during LCP negotiation.

If you set a specific authentication method, such as PAP or CHAP, the MAX TNT drops connections that do not support that protocol.

If you leave the default No-PPP-Auth setting, the MAX TNT accepts any incoming PPP call, including those that do not offer any authentication protocols during LCP negotiation.

PPP authentication in Connection profiles

A Connection profile contains the password expected from the caller, and can also specify the authentication protocol and password used to send reciprocal authentication information back to the far end. Following are the related parameters (shown with examples of their settings):

CONNECTION station
      ppp-options 
            send-auth-mode = any-ppp-auth
            send-password = remote-password
            recv-password = local-password

The Send-Password setting is the password the MAX TNT sends to the far end as part of the initial handshake, and Recv-Password specifies the password the MAX TNT expects from the far end. For some connections, the Send-Password might not be required.

The Send-Auth-Mode parameter sets the authentication method the MAX TNT specifies for this PPP connection. The far end of the connection must support the protocol, or the MAX TNT drops the call. The parameter supports the following settings:

No-PPP-Auth (No authentication)
Any-PPP-Auth (Any of the supported methods)
PAP-PPP-Auth (PAP)
CHAP-PPP-Auth (CHAP)
MS-CHAP-PPP-Auth (MS-CHAP)

If set to Any-PPP-Auth, the MAX TNT starts with the strongest authentication method and negotiates down to the strongest one that the far end supports.

PAP authentication

Simple PAP is a two-way handshake method of establishing a caller's identity. Used only once, during the initial establishment of the data link, it is not a strong authentication method. Passwords are sent as plain text, so they are subject to eavesdroppers using software that monitors information sent across a network.

PAP authentication is typically used only when the dial-in device does not support a stronger authentication method, such as CHAP, or when the remote device requires a plain text password.

The following commands configure a connection named Robin for PAP authentication:

admin> read conn robin
CONNECTION/robin read

admin> set ppp send-auth-mode = pap-ppp-auth

admin> set ppp send-password = remote-password

admin> set ppp recv-password = local-password

admin> write
CONNECTION/robin written

CHAP authentication

CHAP authentication verifies the caller's identity by using a three-way handshake upon initial link establishment and possibly repeating the handshake any number of times. The authenticator sends a challenge to the caller, which responds with an MD5 digest calculated from the password. The authenticator then checks the digest against its own calculation of the expected hash value to authenticate the call. A new challenge may be sent at random intervals.

CHAP is a stronger authentication method than PAP, because the password is not sent as plain text. In addition, the use of repeated challenges limits the time of exposure to any single attempt to break the encryption code, and the authenticator is in control of how often and when challenges are sent.

The following commands configure a connection named Matt for CHAP authentication:

admin> read conn matt
CONNECTION/matt read

admin> set ppp send-auth-mode = chap-ppp-auth

admin> set ppp send-password = remote-password

admin> set ppp recv-password = local-password

admin> write
CONNECTION/matt written

MS-CHAP authentication

Microsoft CHAP (MS-CHAP) is a close derivative of CHAP. However, CHAP is designed to authenticate WAN-aware secure software. It is not widely used to support remote workstations, where an insecure plain text login might be required. MS-CHAP addresses this issue, and also integrates the encryption and hashing algorithms used on Windows networks. Microsoft Windows NT and LAN Manager platforms implement MS-CHAP.

The following commands configure a connection named Ted for MS-CHAP authentication:

admin> read conn ted
CONNECTION/ted read

admin> set ppp send-auth-mode = ms-chap-ppp-auth

admin> set ppp send-password = remote-password

admin> set ppp recv-password = local-password

admin> write
CONNECTION/ted written

Token card authentication

The MAX TNT supports token-card authentication by using a RADIUS server as the intermediary between the MAX TNT unit answering the call and an External Authentication Server (EAS) such as a Security Dynamics ACE/Server or an Enigma Logic SafeWord server. For the details of configuring the RADIUS server to communicate with the EAS, see the MAX TNT RADIUS Guide.

Token cards are hardware devices, typically shaped liked credit-card calculators, with an LCD display that informs users about the current, one-time-only token (password) that will enable access to a secure network. The current token changes many times a day. Token cards keep the changing authentication information continuously up-to-date by maintaining a synchronized clock with an EAS such as an ACE/Server or SafeWord server. Authorized users must have the token card in their possession to gain access to a secure network.

If the EAS is ACE/Server, the user has a SecurID token card that displays a randomly generated access code, which changes every 60 seconds.

If the EAS is SafeWord, the user can have one of the following types of token cards:

ActivCard
CryptoCard
DES Gold
DES Silver
SafeWord SofToken
SafeWord MultiSync
DigiPass
SecureNet Key
WatchWord

The MAX TNT supports the use of token cards only through RADIUS. The RADIUS server must be configured to interact with the EAS modules, which typically run on the same physical system as the RADIUS server.

Note: When simple RADIUS authentication is in use, the RADIUS server itself acts as the EAS. When token-card authentication is in use, the RADIUS server passes the authentication request on to an ACE/Server or SafeWord server, and that system is referred to as the EAS. This does not affect the MAX TNT External-Auth profile configuration, which must still specify RADIUS as the external server.

Authenticating dial-in connections by means of tokens

Figure A-1 shows a dial-in connection to the MAX TNT. The remote user must use a token card to gain access to the secure network.

Figure A-1. Token card authentication for dial-in connections

A user with a token card initiates a connection to the MAX TNT, usually from terminal-server password mode in another Ascend unit. By dialing up the MAX TNT (the Network Access Server, or NAS), the user becomes a client of the NAS.

The MAX TNT sends an Access-Request packet to the RADIUS server to authenticate the incoming call, becoming a client of the RADIUS server. (For details of Access-Request packets, see the MAX TNT RADIUS Guide.)

The RADIUS server forwards the connection request to the EAS (ACE/Server or SafeWord server), becoming a client of the EAS.

The EAS sends an Access-Challenge packet back through the RADIUS server and the MAX TNT to the user dialing in. The user sees the challenge message, obtains the current password from his or her token card, and enters that password in response to the challenge message. The password travels back through the NAS and the RADIUS server to the EAS.

The EAS sends a response to the RADIUS server, specifying whether the user has entered the proper user name and password. If the user enters an incorrect password, the EAS returns another challenge and the user can try again, for a total of up to three attempts.

As the last step in authentication, the RADIUS server sends an authentication response to the MAX TNT. If authentication is unsuccessful, the MAX TNT receives an Access-Reject packet and terminates the call. If authentication is successful, the MAX TNT receives an Access-Accept packet containing a list of Attribute-Value pairs from the user profile in the RADIUS server's database. The MAX TNT uses the Attribute-Value pairs to create the connection.

Configuring the MAX TNT as the NAS

To configure the MAX TNT to function as the NAS as shown in Figure A-1, you must set up the Answer-Defaults profile to allow the appropriate authentication method. For example, you might set the Receive-Auth-Mode parameter to Any-PPP-Auth, as described in PPP authentication in the Answer-Defaults profile.

You must also set up the External-Auth profile to authenticate the connections via RADIUS. For details, see the MAX TNT RADIUS Guide.

techpubs@eng.ascend.com

First-tier access security

Considerations

Using callback for added security

Setup

Recommendation

Setting

Effect

Specifying terminal-server password settings

How immediate mode affects terminal-server authentication

CHAP authentication

MS-CHAP authentication