Lucent Technologies TAOS Guide and Reference

PDF

Hati

Tangazo

TAOS

RADIUS Guide and Reference

Part Number: 7820-0729-002

For software version 8.0

May 2000

This material is protected by the copyright laws of the United States and other countries. It may not be reproduced, distributed, or altered in any fashion by any entity (either internal or external to Lucent Technologies), except in accordance with applicable agreements, contracts, or licensing, without the express written consent of Lucent Technologies. For permission to reproduce or distribute, please email your request to [email protected]

Notice

Every effort was made to ensure that the information in this document was complete and accurate at the time of printing, but information is subject to change.

Safety, Compliance, and Warranty Information

Before handling any Lucent Access Networks hardware product, read the Access Networks Safety and Compliance Guide included in your product package.

See that guide also to determine how products comply with the electromagnetic interference (EMI) and network compatibility requirements of your country.

See the warranty card included in your product package for the limited warranty that Lucent Technologies provides for its products.

Security Statement

In rare instances, unauthorized individuals make connections to the telecommunications network through the use of access features.

Trademarks

4ESS, 5ESS, A Network of Expertise, AnyMedia, AqueView, AUDIX, B-STDX 8000, B-STDX 9000, ...Beyond Compare, CaseView, Cajun, CajunDocs,

CAJUNVIEW, Callmaster, CallVisor, CBX 500, CellPipe, ChoiceNet, ClearReach, ComOS, cvMAX, DACScan, Dacsmate, Datakit, DEFINITY,

Definity One, DSLMAX, DSL Terminator, DSLPipe, DSLTNT, Elemedia, Elemedia Enhanced, EMMI, End to End Solutions, EPAC, ESS, EVEREST,

Gigabit-scaled campus networking, Globalview, GRF, GX 250, GX 550, HyperPATH, Inferno, InfernoSpaces, Intragy, IntragyAccess, IntragyCentral,

Intuity, IP Navigator, IPWorX, LineReach, LinkReach, MAX, MAXENT, MAX TNT, Multiband, Multiband PLUS, Multiband RPM, MultiDSL, Multi-

Voice, MultiVPN, Navis, NavisAccess, NavisConnect, NavisCore, NavisRadius, NavisXtend, NetCare, NetLight, NetPartner, OneVision,

Open Systems Innovations, OpenTrunk, P550, PacketStar, PathStar, Pinnacle, Pipeline, PMVision, PortMaster, SecureConnect, Selectools, Series56,

SmoothConnect, Stinger, SYSTIMAX, True Access, WaveLAN, WaveMANAGER, WaveMODEM, WebXtend, and Where Network Solutions Never End are trademarks of Lucent Technologies. Advantage Pak, Advantage Services, AnyMedia, ...Beyond Compare, End to End Solutions, Inter.NetWorking,

MAXENT, and NetWork Knowledge Solutions are service marks of Lucent Technologies. Other trademarks, service marks, and trade names mentioned in this publication belong to their respective owners.

Copyrights for Third-Party Software Included in Lucent Access Networks Software Products

C++ Standard Template Library software copyright© 1994 Hewlett-Packard Company and copyright© 1997 Silicon Graphics. Permission to use, copy, modify, distribute, and sell this software and its documentation for any purpose is hereby granted without fee, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation. Neither Hewlett-Packard nor Silicon Graphics makes any representations about the suitability of this software for any purpose. It is provided “as is” without express or implied warranty.

Berkeley Software Distribution (BSD) UNIX software copyright© 1982, 1986, 1988, 1993 The Regents of California. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions, and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions, and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the University of California, Berkeley, and its contributors. 4. Neither the name of the University nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES,

INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE

ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,

SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS

OR SERVICES; LOSS OF USE, DATA OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF

LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY

OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Ordering Information

You can order the most up-to-date product information and computer-based training online at http://www.lucent.com/ins/bookstore

Feedback

Lucent Technologies appreciates your comments, either positive or negative, about this manual. Please send them to [email protected]

Lucent Technologies

Customer Service

Customer Service provides a variety of options for obtaining information about Lucent products and services, software upgrades, and technical assistance.

Finding information and software on the Internet

Visit the Web site at http://www.lucent.com/ins for technical information, product information, and descriptions of available services.

Visit the FTP site at ftp://ftp.ascend.com

for software upgrades, release notes, and addenda.

Obtaining technical assistance

You can obtain technical assistance by telephone, email, fax, modem, or regular mail, as well as over the Internet.

Gathering information you will need

If you need to contact Lucent for help with a problem, make sure that you have the following information when you call or that you include it in your correspondence:

• Product name and model

• Software and hardware options

• Software version

• If supplied by your carrier, Service Profile Identifiers (SPIDs) associated with your line

• Your local telephone company’s switch type and operating mode, such as AT&T 5ESS

Custom or Northern Telecom National ISDN-1

• Whether you are routing or bridging with your Lucent product

• Type of computer you are using

• Description of the problem

Calling Lucent from within the United States

In the U.S., you can take advantage of Priority Technical Assistance or an Advantage service contract, or you can call to request assistance.

Priority Technical Assistance

If you need to talk to an engineer right away, call (900) 555-2763 to reach the Priority Call queue. The charge of $2.95 per minute does not begin to accrue until you are connected to an engineer. Average wait times are less than 3 minutes.

Advantage Services

Advantage Services is a comprehensive selection of services. Installation services help get your Lucent Wide Area Network (WAN) off to the right start. Ongoing maintenance and

TAOS RADIUS Guide and Reference iii

support services provide hardware and software solutions to keep your network operating at peak performance. For more information, call (800) 272-3634.

Other telephone numbers

For a menu of Lucent’s services, call (800) 272-3634. Or call (510) 769-6001 for an operator.

Calling Lucent from outside the United States

You can contact Lucent by telephone from outside the United States at one of the following numbers:

Telephone outside the United States

Austria/Germany/Switzerland

Benelux

France

Italy

Japan

Middle East/Africa

Scandinavia

Spain/Portugal

(510) 769-8027

(+33) 492 96 5672

(+33) 492 96 5674

(+33) 492 96 5673

(+33) 492 96 5676

(+81) 3 5325 7397

(+33) 492 96 5679

(+33) 492 96 5677

(+33) 492 96 5675

(+33) 492 96 5671

For the Asia-Pacific region, you can find additional support resources at http://www.lucent.com/ins/international/apac/

Obtaining assistance through correspondence

Send your technical support questions to one of the following email addresses, or correspond by fax, BBS, or regular mail with Customer Service in Lucent’s U.S. offices in Alameda, CA:

• Email from within the U.S.— [email protected]

• Email from Europe, the Middle East, or Africa—

[email protected]

• Email from the Asia-Pacific region— [email protected]

• Fax—(510) 814-2312

• Customer Support BBS (by modem)—(510) 814-2302

• Write to Lucent at the following address:

Attn: Customer Service

Lucent Technologies

1701 Harbor Bay Parkway

Alameda, CA 94502-3002

USA iv TAOS RADIUS Guide and Reference

Chapter 1

Customer Service ..................................................................................................................... iii

About This Manual.......................................................................... xiii

What is in this manual............................................................................................................ xiii

What you should know .......................................................................................................... xiii

Documentation conventions.................................................................................................... xiv

Setting Up the TAOS Unit for RADIUS .......................................... 1-1

Overview of configuration tasks ............................................................................................ 1-1

Setting up the TAOS unit to communicate with RADIUS .................................................... 1-1

Required steps for configuring the unit to communicate with RADIUS........................ 1-2

Required configuration tasks at the CLI.................................................................. 1-2

Required configuration tasks at the VT100 interface .............................................. 1-2

Optional steps for configuring the unit to communicate with RADIUS ........................ 1-3

Specifying the duration of a RADIUS timeout ....................................................... 1-4

Specifying the message resulting from a RADIUS timeout.................................... 1-4

Specifying whether the unit must return to using the primary RADIUS server...... 1-5

Specifying whether remote users are dropped with no host for immediate login ... 1-5

Specifying whether the unit sends values for attributes 6 and 7 to RADIUS ......... 1-6

Specifying how the system behaves when Service-Type (6) is not received .......... 1-6

Specifying the manner in which the unit handles the User-Name attribute ............ 1-7

Configuring Vendor-Specific Attribute (VSA) support .......................................... 1-8

Limiting excess RADIUS traffic ............................................................................. 1-9

Fine-tuning the interaction between the TAOS unit and RADIUS ......................... 1-9

Specifying whether to customize the User-Name string (CLI only) ..................... 1-10

Configuring distinct ID sequences for packet IDs (CLI only) .............................. 1-10

Specifying whether RADIUS authenticates a Telnet session (VT100 only)......... 1-11

Specifying console port security (VT100 only) .................................................... 1-11

Specifying information about the host running the APP Server (VT100 only) .... 1-11

Configuring the unit to recognize a security-card server (VT100 only) ............... 1-11

Specifying a RADIUS bootup server (VT100 only) ............................................. 1-11

Example of configuring the unit to communicate with RADIUS ................................ 1-12

Sample CLI configuration ..................................................................................... 1-13

Sample VT100 configuration ................................................................................ 1-14

Setting up system-wide RADIUS accounting...................................................................... 1-14

Required system-wide accounting configuration tasks ................................................ 1-14

Required system-wide accounting configuration tasks at the CLI ........................ 1-15

Required system-wide accounting configuration tasks at the VT100 interface .... 1-15

Optional system-wide accounting tasks........................................................................ 1-15

Specifying the source for RADIUS accounting requests ...................................... 1-16

Specifying a timeout value .................................................................................... 1-16

Specifying a retry limit .......................................................................................... 1-16

TAOS RADIUS Guide and Reference v

Contents

Chapter 2

Specifying the interval for sending session reports ............................................... 1-17

Specifying the numeric base for the session ID .................................................... 1-17

Specifying the reset time ....................................................................................... 1-18

Specifying whether to send Stop packets with no username................................. 1-18

Specifying whether to send a second RADIUS Accounting Start record ............. 1-19

Specifying whether to send Stop packets when authentication fails (CLI only)... 1-19

Generating accounting IDs on the basis of the source port number (CLI only).... 1-19

Specifying the interval for sending checkpoint records (VT100 only) ................. 1-19

Example of setting up system-wide RADIUS accounting............................................ 1-20

Sample CLI configuration ..................................................................................... 1-20

Sample VT100 configuration ................................................................................ 1-21

Setting up accounting on a per-user basis ............................................................................ 1-22

Overview of per-user accounting attributes.................................................................. 1-22

Specifying per-user accounting attributes..................................................................... 1-23

Example of setting up per-user accounting................................................................... 1-24

Setting up accounting with dynamic IP addressing ............................................................. 1-25

CLI configuration ......................................................................................................... 1-25

VT100 configuration..................................................................................................... 1-25

Classifying user sessions in RADIUS.................................................................................. 1-26

Using the Class attribute ............................................................................................... 1-26

Using the Ascend-Number-Sessions attribute .............................................................. 1-26

Generating periodic accounting requests ...................................................................... 1-27

CLI configuration .................................................................................................. 1-27

VT100 configuration ............................................................................................. 1-27

Example of classifying user sessions............................................................................ 1-27

Understanding pseudo-user profiles..................................................................................... 1-27

Understanding RADIUS Authentication........................................ 2-1

What is RADIUS authentication? .......................................................................................... 2-1

RADIUS profile formats ........................................................................................................ 2-2

Preauthentication.................................................................................................................... 2-2

RADIUS password handling.................................................................................................. 2-3

Reserved RADIUS passwords ........................................................................................ 2-3

Password expiration ........................................................................................................ 2-4

DEFAULT user profile ................................................................................................... 2-5

Shared secrets and secure exchanges.............................................................................. 2-5

Authenticating framed protocol sessions ............................................................................... 2-6

Specifying an authentication protocol required for dial-in calls..................................... 2-6

How PAP works ...................................................................................................... 2-6

How CHAP and MS-CHAP work ........................................................................... 2-7

Requesting a protocol for use in dial-out calls ............................................................... 2-8

Token-card authentication...................................................................................................... 2-8

Enhanced security with token cards................................................................................ 2-9

Simple method of authenticating token-card calls.......................................................... 2-9

Authenticating token-card connections from TAOS units ........................................... 2-10

Using PAP-TOKEN authentication ....................................................................... 2-11

Using PAP-TOKEN-CHAP authentication ........................................................... 2-12

Using CACHE-TOKEN authentication................................................................. 2-13

Using ACE authentication for network users ........................................................ 2-14

Tunnel authentication........................................................................................................... 2-15

Authenticating ATMP tunnels ...................................................................................... 2-15

Authenticating L2TP tunnels ........................................................................................ 2-16

TAOS RADIUS Guide and Reference

Contents

Chapter 3

Chapter 4

Tunnel attribute sets with tags and preferences ............................................................ 2-16

Overview of attribute sets and tags........................................................................ 2-17

Supported tunnel protocols .................................................................................... 2-17

Tunnel attributes used with tags ............................................................................ 2-18

Example of reordering sets using Tunnel-Preference............................................ 2-19

Callback after authentication ............................................................................................... 2-20

Understanding RADIUS Accounting ............................................. 3-1

What is RADIUS accounting? ............................................................................................... 3-1

What kinds of packets does RADIUS accounting use? ......................................................... 3-2

Accounting Start packets ................................................................................................ 3-2

Accounting Stop packets ................................................................................................ 3-2

RADIUS attributes in Start records ................................................................................ 3-2

RADIUS attributes in Stop records ................................................................................ 3-5

RADIUS attributes in Failure-to-start records.............................................................. 3-10

Proxy RADIUS accounting.................................................................................................. 3-11

How proxy RADIUS accounting works ....................................................................... 3-11

Contents of the Stop record sent by proxy.................................................................... 3-12

Sample accounting records .................................................................................................. 3-13

Pipeline unit dialing into a MAX TNT unit.................................................................. 3-14

Modem calling into a MAX unit................................................................................... 3-15

Immediate-modem dialout connection ......................................................................... 3-16

Stop record sent by proxy ............................................................................................. 3-17

Reference to RADIUS Attributes ................................................... 4-1

RADIUS attribute descriptions listed alphabetically ............................................................. 4-1

Free-RADIUS attributes and their RFC equivalents.......................................................... 4-180

RFC-standard attributes not supported by TAOS .............................................................. 4-181

Unused attributes................................................................................................................ 4-182

Outdated attributes ............................................................................................................. 4-182

Appendix A Non-Accounting RADIUS Packets................................................. A-1

Overview of RADIUS packet formats .................................................................................. A-2

Access-Request (1) ............................................................................................................... A-5

Access-Accept (2) ................................................................................................................. A-6

Access-Reject (3) ................................................................................................................ A-12

Access-Password-Request (7)............................................................................................. A-12

Access-Password-Ack (8) ................................................................................................... A-12

Access-Password-Reject (9) ............................................................................................... A-12

Access-Challenge (11) ........................................................................................................ A-12

Access-Password-Expired (32) ........................................................................................... A-12

Ascend-Access-Event-Request (33) ................................................................................... A-13

Ascend-Access-Event-Response (34) ................................................................................. A-13

Ascend-Disconnect-Request (40) ....................................................................................... A-13

Ascend-Disconnect-Ack (41).............................................................................................. A-13

Ascend-Disconnect-Nak (42).............................................................................................. A-13

Ascend-Change-Filters-Request (43).................................................................................. A-14

Ascend-Change-Filters-Ack (44) ........................................................................................ A-14

Ascend-Change-Filters-Nak (45) ........................................................................................ A-14

TAOS RADIUS Guide and Reference vii

Contents

Appendix B Sample RADIUS Users File ............................................................ B-1

Appendix C Disconnect/Progress Code Combinations ................................... C-1

Index.......................................................................................... Index-1

viii TAOS RADIUS Guide and Reference

Figures

Figure 1-1 Sample topology for setting up the TAOS unit to use the RADIUS server .... 1-12

Figure 1-2 Sample network topology for setting up system-wide RADIUS accounting .. 1-20

Figure 1-3 Sample network topology for setting up accounting on a per-user basis ........ 1-24

Figure 2-1 Shared secret used between the TAOS unit and a RADIUS server................... 2-5

Figure 2-2 Token card authentication for dial-in connections........................................... 2-10

Figure 2-3 PAP-TOKEN with an ACE server................................................................... 2-11

Figure 2-4 PAP-TOKEN-CHAP with a Safeword server ................................................. 2-12

Figure 2-5 CACHE-TOKEN with a SafeWord server ...................................................... 2-14

Figure 2-6 ACE authentication for remote router users .................................................... 2-14

Figure 3-1 Normal RADIUS accounting (no proxy necessary) ........................................ 3-11

Figure 3-2 Proxy accounting (host card goes down) ......................................................... 3-11

TAOS RADIUS Guide and Reference ix

Tables

Table 1-1 Per-user accounting attributes.......................................................................... 1-22

Table 1-2 First-line configuration of pseudo-user profiles .............................................. 1-28

Table 3-1 RADIUS attributes in Start records ................................................................... 3-2

Table 3-2 RADIUS attributes in Stop records ................................................................... 3-5

Table 3-3 RADIUS attributes included in proxy Stop records ........................................ 3-12

Table 4-1 Ascend-Appletalk-Route arguments .................................................................. 4-8

Table 4-2 Ascend-Bridge-Address arguments ................................................................. 4-23

Table 4-3 Ascend-Call-By-Call settings .......................................................................... 4-28

Table 4-4 IP call filter syntax elements............................................................................ 4-30

Table 4-5 Generic call filter syntax elements................................................................... 4-31

Table 4-6 Ascend-Call-Type settings............................................................................... 4-36

Table 4-7 Progress codes.................................................................................................. 4-44

Table 4-8 IP data filter syntax elements........................................................................... 4-47

Table 4-9 Generic data filter syntax elements.................................................................. 4-49

Table 4-10 Ascend-Data-Svc settings ................................................................................ 4-51

Table 4-11 Disconnect codes ............................................................................................. 4-59

Table 4-12 Ascend-Filter arguments .................................................................................. 4-74

Table 4-13 Ascend-IP-Pool-Definition arguments............................................................. 4-97

Table 4-14 Ascend-IPX-Route arguments ....................................................................... 4-103

Table 4-15 Ascend-Menu-Item arguments....................................................................... 4-106

Table 4-16 Ascend-PRI-Number-Type settings............................................................... 4-123

Table 4-17 Ascend-PW-Expiration arguments ................................................................ 4-126

Table 4-18 Route preferences........................................................................................... 4-134

Table 4-19 Ascend-Secondary-Home-Agent syntax........................................................ 4-135

Table 4-20 IP address classes and default subnet masks.................................................. 4-156

Table 4-21 Framed-Protocol settings ............................................................................... 4-158

Table 4-22 Framed-Route arguments............................................................................... 4-160

Table 4-23 Tunnel-Server-Endpoint syntax ..................................................................... 4-175

Table 4-24 Free-RADIUS attributes and their RFC 2138 equivalents ............................ 4-180

Table 4-25 User-Service settings and their Service-Type equivalents............................. 4-181

Table 4-26 RFC-standard attributes not supported by TAOS.......................................... 4-181

Table 4-27 Outdated RADIUS attributes ......................................................................... 4-182

Table A-1 RADIUS packet fields ...................................................................................... A-2

Table A-2 Code field packet types..................................................................................... A-3

Table C-1 Disconnect/Progress code combinations............................................................ C-1

TAOS RADIUS Guide and Reference xi

About This Manual

What is in this manual

This manual provides detailed information about how to set up the True Access™ Operating

System (TAOS) unit to use the Remote Authentication Dial-In User Service (RADIUS) server.

It also contains a complete reference to RADIUS attributes.

Note:

This manual describes the full set of features for TAOS units running TAOS software version 8.0.2 or later. Some features might not be available with earlier versions or specialty loads of the software. Free RADIUS, the Ascend RADIUS server, is not supported after release 7.0.0 and is not recommended for use with an APX 8000™ unit. The free-RADIUS dictionary is not RFC compliant, nor does it provide Vendor-Specific Attribute (VSA) support.

Warning:

Before installing your TAOS unit, be sure to read the safety instructions in the

Access Networks Safety and Compliance Guide. For information specific to your unit, see the

“Safety-Related Electrical, Physical, and Environmental Information” appendix in your unit’s hardware installation guide.

What you should know

This manual is intended for the person who will configure and maintain RADIUS and the

TAOS unit. To use this manual effectively, you must have a basic understanding of TAOS security and configuration, and be familiar with authentication servers and networking concepts.

While this manual attempts to provide enough conceptual framework to enable an administrator who is not an expert in a particular network technology to configure RADIUS accurately, it does not start from the beginning with any network management topic. Following are the general areas in which it is helpful have some existing knowledge when configuring

RADIUS:

• Dial-in LAN connections

• Connection cost management and accounting

• Modems

• Frame Relay

• NetWare and IPX routing

• IP routing

• Domain Name System (DNS)

• Open Shortest Path First (OSPF) routing

• Multicast

TAOS RADIUS Guide and Reference xiii

About This Manual

Documentation conventions

• Packet structure and formats (for defining filters)

• Network security

Documentation conventions

Following are all the special characters and typographical conventions used in this manual:

Convention Meaning

Monospace text

Represents text that appears on your computer’s screen, or that could appear on your computer’s screen.

Boldface monospace text

Represents characters that you enter exactly as shown (unless the characters are also in

italics

—see Italics, below). If you could enter the characters but are not specifically instructed to, they do not appear in boldface.

Italics

[ ]

Key1-Key2

Press Enter

Note:

Represent variable information. Do not enter the words themselves in the command. Enter the information they represent. In ordinary text, italics are used for titles of publications, for some terms that would otherwise be in quotation marks, and to show emphasis.

Square brackets indicate an optional argument you might add to a command. To include such an argument, type only the information inside the brackets. Do not type the brackets unless they appear in bold type.

Separates command choices that are mutually exclusive.

Points to the next level in the path to a parameter or menu item. The item that follows the angle bracket is one of the options that appears when you select the item that precedes the angle bracket.

Represents a combination keystroke. To enter a combination keystroke, press the first key and hold it down while you press one or more other keys. Release all the keys at the same time. (For example,

Ctrl-H means hold down the Control key and press the H key.)

Means press the Enter, or Return, key or its equivalent on your computer.

Introduces important additional information.

Caution:

Warning:

Warns that a failure to follow the recommended procedure could result in loss of data or damage to equipment.

Warns that a failure to take appropriate safety precautions could result in physical injury.

Warns of danger of electric shock.

Warning:

xiv TAOS RADIUS Guide and Reference

Setting Up the TAOS Unit for RADIUS

Overview of configuration tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

Setting up the TAOS unit to communicate with RADIUS . . . . . . . . . . . . . . . . . . . . . . 1-1

Setting up system-wide RADIUS accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-14

Setting up accounting on a per-user basis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-22

Setting up accounting with dynamic IP addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-25

Classifying user sessions in RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-26

Understanding pseudo-user profiles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-27

Overview of configuration tasks

In this chapter, you will learn how to set up the TAOS unit to communicate with the RADIUS server, and how to configure RADIUS accounting.

For information about setting up the TAOS unit for RADIUS, see “Setting up the TAOS unit to communicate with RADIUS” on page 1-1. For information about setting up RADIUS accounting, see one or more of the following sections:

•

“Setting up system-wide RADIUS accounting” on page 1-14

•

“Setting up accounting on a per-user basis” on page 1-22

•

“Setting up accounting with dynamic IP addressing” on page 1-25

•

“Classifying user sessions in RADIUS” on page 1-26

You can perform each configuration task at the Command-Line Interface (CLI) or at the

VT100 interface, depending on the type of TAOS unit you are configuring.

Note:

Free RADIUS is not recommended for use with an APX 8000 unit.

Setting up the TAOS unit to communicate with RADIUS

The following sections describe how to set up the TAOS unit to communicate with the

RADIUS server. Some of the steps are required. Other settings are optional.

•

For a list of required steps, see “Required steps for configuring the unit to communicate with RADIUS” on page 1-2.

•

For a list of optional steps, see “Optional steps for configuring the unit to communicate with RADIUS” on page 1-3.

TAOS RADIUS Guide and Reference 1-1

Setting Up the TAOS Unit for RADIUS

Setting up the TAOS unit to communicate with RADIUS

Required steps for configuring the unit to communicate with RADIUS

When configuring the TAOS unit to use RADIUS, you must specify the following:

• Type of authentication in use

• IP address of at least one RADIUS server

• UDP port number for the daemon

• RADIUS client password

You can have up to three RADIUS servers on your network. One is the primary server. Two additional servers can function as backups. If the primary RADIUS server fails, the TAOS unit automatically contacts the secondary RADIUS server to authenticate a user. When it successfully connects to an authentication server, the TAOS unit uses that machine until it fails to serve requests. By default, the TAOS unit does not revert to using the first host until the second machine fails, even if the first host has come online while the second host is still servicing requests.

Required configuration tasks at the CLI

To use the CLI to specify settings required for RADIUS operation, proceed as follows:

In the External-Auth profile, set the Auth-Type parameter to RADIUS.

Open the Rad-Auth-Client subprofile.

For each Auth-Server parameter, specify the IP address of a RADIUS server.

The TAOS unit first tries to connect to the server specified by Auth-Server-1. If it receives no response within the time specified by the Auth-Timeout parameter, it tries to connect to

Auth-Server-2. If it again receives no response within the time specified by

Auth-Timeout, it tries to connect to Auth-Server-3. If the TAOS unit’s request again times out, it reinitiates the process with Auth-Server-1. The TAOS unit can execute this cycle of requests a maximum of 10 times.

If you specify the same address for all three Auth-Server parameters, the TAOS unit keeps trying to create a connection to the same server.

Set the Auth-Port parameter to the destination UDP port number on which the RADIUS daemon receives client requests.

Set the Auth-Key parameter to the RADIUS client password. The password is case sensitive.

Required configuration tasks at the VT100 interface

To use the VT100 interface to specify settings required for RADIUS operation, proceed as follows:

Open the Ethernet menu.

Open the Mod Config menu.

Open the Auth menu.

Set the Auth parameter to RADIUS.

1-2 TAOS RADIUS Guide and Reference

Setting Up the TAOS Unit for RADIUS

Setting up the TAOS unit to communicate with RADIUS

For each Auth Host parameter, specify the IP address of a RADIUS server.

The TAOS unit first tries to connect to the server specified by Auth Host #1. If it receives no response within the time specified by the Auth Timeout parameter, it tries to connect to

Auth Host #2. If it again receives no response within the time specified by Auth Timeout, it tries to connect to Auth Host #3. If the TAOS unit’s request again times out, it reinitiates the process with Auth Host #1. The TAOS unit can execute this cycle of requests a maximum of 10 times.

If you specify the same address for all three Auth Host parameters, the TAOS unit keeps trying to create a connection to the same server.

Set the Auth Port parameter to the destination UDP port number on which the RADIUS daemon receives client requests.

Set the Auth Key parameter to the RADIUS client password. The password is case sensitive.

Optional steps for configuring the unit to communicate with RADIUS

Depending on your needs, you can set parameters to do any of the following:

• Specify the duration of a RADIUS timeout.

• Specify the message resulting from a RADIUS timeout.

• Specify whether the TAOS unit must return to using the primary RADIUS server after a timeout.

• Specify whether the TAOS unit drops remote users when no host is specified for immediate login service.

• Specify whether the TAOS unit sends values for the Service-Type (6) and

Framed-Protocol (7) attributes to RADIUS.

• Specify how the system behaves when the Service-Type (6) attribute is not received.

• Specify the manner in which the TAOS unit handles the User-Name attribute.

• Configure Vendor-Specific Attribute (VSA) support.

• Limit excess RADIUS traffic.

• Fine-tune the interaction between the TAOS unit and RADIUS.

• Specify whether to customize the User-Name string (CLI only).

• Configure distinct ID sequence spaces for packet IDs (CLI only).

• Specify whether the TAOS unit uses RADIUS to authenticate a Telnet session (VT100 only).

• Specify console port security (VT100 only).

• Specify information about the host running the APP Server utility (VT100 only).

• Configure the unit to recognize a security-card authentication server (VT100 only)

• Specify a RADIUS bootup server (VT100 only).

TAOS RADIUS Guide and Reference 1-3

Setting Up the TAOS Unit for RADIUS

Setting up the TAOS unit to communicate with RADIUS

Specifying the duration of a RADIUS timeout

You can specify the number of seconds during which the TAOS unit waits for a response to a

RADIUS authentication request. If you have a high volume of calls, consider specifying a low value. A high timeout value combined with a high call volume can significantly slow the process of authenticating calls. However, if RADIUS is running on a busy shared UNIX host, or if the RADIUS server is on the remote end of a slow link, consider increasing the timeout value above the default of 1 second.

CLI configuration

In the Rad-Auth-Client subprofile of the External-Auth profile, set the Auth-Timeout parameter to the number of seconds the TAOS unit waits for a response to a RADIUS authentication request. If the TAOS unit does not receive a response within the time you specify, it sends the authentication request to the next server specified by the Auth-Server parameter.

VT100 configuration

In Ethernet > Mod Config > Auth menu, set the Auth Timeout parameter to the number of seconds the TAOS unit waits for a response to a RADIUS authentication request. If the TAOS unit does not receive a response within the time you specify, it sends the authentication request to the next server specified by the Auth Host parameter.

Specifying the message resulting from a RADIUS timeout

By default, if authentication fails on a PPP connection because of an invalid password or an authentication server timeout, the Lucent unit gracefully shuts down the PPP connection by sending an LCP-CLOSE request to the dial-up user. If Microsoft Windows 95 (MSN) receives the LCP-CLOSE during authentication, it displays an invalid-password message. This message is misleading if the failure resulted from a RADIUS timeout. Using the CLI or VT100 interface, you can specify that the message resulting from a RADIUS timeout states that the network failed.

CLI configuration

To specify that the message resulting from a RADIUS timeout states that the network failed, set Disconnect-On-Auth-Timeout to Yes in the Answer-Defaults profile’s PPP-Answer subprofile.

VT100 configuration

To specify that the message resulting from a RADIUS timeout states that the network failed, set Disc On Auth Timeout to Yes in the Ethernet > Answer > PPP-Options menu.

1-4 TAOS RADIUS Guide and Reference

Setting Up the TAOS Unit for RADIUS

Setting up the TAOS unit to communicate with RADIUS

Specifying whether the unit must return to using the primary RADIUS server

If a timeout occurs while the TAOS unit waits for a reply to an authentication request directed to the primary RADIUS server, the TAOS unit sends the authentication request to the secondary RADIUS server. If that fails, the TAOS unit sends the authentication request to the next RADIUS server. By default, if either of the secondary servers acknowledges the request, the TAOS unit continues to use that server instead of the primary one, even if the primary server has come back up. The TAOS unit uses the secondary server until it is no longer available. However, you can specify a limit on the period of time the TAOS unit uses the secondary RADIUS server. At the end of this time period, the TAOS unit sends the next authentication request to the primary RADIUS server.

CLI configuration

To specify the number of seconds during which the TAOS unit uses the secondary RADIUS server before it sends an authentication request to the primary RADIUS server, set the

Auth-Reset-Time parameter in the External-Auth > Rad-Auth-Client subprofile.

VT100 configuration

To specify the number of seconds during which the TAOS unit uses the secondary RADIUS server before it sends an authentication request to the primary RADIUS server, set the Auth

Reset Timeout parameter in the Ethernet > Mod Config > Auth menu.

Specifying whether remote users are dropped with no host for immediate login

If the immediate login service is TCP-Clear or Telnet, and no value is specified for

Login-IP-Host in the RADIUS user profile, you can specify whether the TAOS unit drops the connection, or gives the caller access to the terminal-server interface instead. By default, the

TAOS unit prevents access to the terminal-server interface when the Login-IP-Host value is not specified, and drops the call.

CLI configuration

To specify that the terminal-server must be secure, accept the default value of Yes for

Auth-TS-Secure in the External-Auth > Rad-Auth-Client subprofile. To specify that the dial-in client can have access to the terminal-server interface if no Login-IP-Host value is specified, set Auth-TS-Secure to No.

VT100 configuration

To specify that the terminal-server must be secure, accept the default value of Yes for Auth TS

Secure in the Ethernet > Mod Config > Auth menu. To specify that the dial-in client can have access to the terminal-server interface if no Login-IP-Host value is specified, set Auth TS

Secure to No.

TAOS RADIUS Guide and Reference 1-5

Setting Up the TAOS Unit for RADIUS

Setting up the TAOS unit to communicate with RADIUS

Specifying whether the unit sends values for attributes 6 and 7 to RADIUS

You can specify whether the TAOS unit sends values for the Service-Type (6) and

Framed-Protocol (7) attributes in Access-Request packets to the RADIUS server. While some

RADIUS servers require these attributes in authentication requests, other RADIUS servers should not receive them.

If you accept the default, which specifies that the TAOS unit sends Service-Type and

Framed-Protocol values, you can restrict the type of user and protocol for each connection. For example, when the TAOS unit sends Service Type and Framed-Protocol for a PPP session, the unit sets Service-Type to Framed-User and Framed-Protocol to PPP for incoming PPP calls.

However, if your RADIUS user profiles enable both framed and unframed users to access PPP, specify that the TAOS unit does not send values for Service-Type and Framed-Protocol. When you do so, a framed user dials in using a protocol such as SLIP or MP+. An unframed user makes an asynchronous connection to the terminal server, and can start Telnet, Rlogin, or raw

TCP sessions.

CLI configuration

To specify that the TAOS unit sends values for attributes 6 and 7 to RADIUS, set Auth-Send67 to Yes in the External-Auth > Rad-Auth-Client subprofile. To specify that the TAOS unit does not values for attributes 6 and 7 to RADIUS, set Auth-Send67 to No.

VT100 configuration

To specify that the TAOS unit sends values for attributes 6 and 7 to RADIUS, set Auth Send

Attr 6, 7 to Yes in the Ethernet > Mod Config > Auth menu. To specify that the TAOS unit does not values for attributes 6 and 7 to RADIUS, set Auth Send Attr 6, 7 to No.

Specifying how the system behaves when Service-Type (6) is not received

You can specify how the system behaves when it does not receive the Service-Type value from the RADIUS server.

CLI configuration

To use the CLI to specify how the system behaves when it does not receive the Service-Type attribute, set the NoAttr6-Use-Termsrv parameter in the External-Auth profile:

• Yes specifies that the TAOS unit initiates a terminal-server login if Service-Type is not received, regardless of whether a Framed-Protocol (7) value is received or not.

• No specifies that if Service-Type is not received, but Framed-Protocol is received, a framed-protocol login is initiated. If neither Service-Type nor Framed-Protocol is received, a terminal-server login is initiated.

1-6 TAOS RADIUS Guide and Reference

Setting Up the TAOS Unit for RADIUS

Setting up the TAOS unit to communicate with RADIUS

VT100 configuration

To use the VT100 interface to specify how the system behaves when it does not receive the

Service-Type attribute, set the No Attr. 6, Use Termsrv parameter in the Ethernet > Mod

Config >Auth menu:

• Yes specifies that the TAOS unit initiates a terminal-server login if Service-Type is not received, regardless of whether a Framed-Protocol (7) value is received or not.

Specifying the manner in which the unit handles the User-Name attribute

The RADIUS server typically returns the User-Name attribute in each Access-Accept packet.

When the proxy RADIUS server responds for several RADIUS servers that belong to different organizations, including a User-Name attribute can result in the loss of realm information. You can therefore specify the manner in which the TAOS unit handles the User-Name attribute.

CLI configuration

To use the CLI to specify the manner in which the TAOS unit handles the User-Name attribute, proceed as follows:

Make External-Auth > Rad-Auth-Client the working profile.

To specify that the User-Name value provided by the server is used for the status display and for RADIUS accounting purposes, accept the default of Change-Name for the

Auth-Keep-User-Name parameter. Then, proceed to step 5.

To specify that the TAOS unit does not use the User-Name value returned by the server, set Auth-Keep-User-Name to Keep-Name. If a name has been specified, the system uses it. Otherwise, it uses the User-Name sent to the server for authentication. A user authenticated by CLID or DNIS will appear to have the CLID or DNIS number as his or her username.

When the username sent to the server is a realm, you can specify that the system behaves as though the setting were Keep-Name. To do so, set Auth-Keep-User-Name to

Keep-Realm-Name. (If the username sent to the server is not a realm, the system behaves as though the setting were Change-Name.)

To specify the characters that delimit a realm from the username, set the

Auth-Realm-Delimiters parameter. You can specify up to seven characters in any order. If no characters are listed, the system behaves as though Auth-Keep-User-Name were set to

Change-Name. The default is

@/\%

VT100 configuration

To use the VT100 interface to specify the manner in which the TAOS unit handles the

User-Name attribute, proceed as follows:

Navigate to the Ethernet > Mod Config > Auth submenu.

To specify that the User-Name value provided by the server is used for the status display and for RADIUS accounting purposes, accept the default of Change Name for the Keep

User Name parameter. Then, proceed to step 5.

TAOS RADIUS Guide and Reference 1-7

Setting Up the TAOS Unit for RADIUS

Setting up the TAOS unit to communicate with RADIUS

To specify that the TAOS unit does not use the User-Name value returned by the server, set Keep User Name to Keep Name. If a name has been specified, the system uses it.

Otherwise, it uses the User-Name sent to the server for authentication. A user authenticated by CLID or DNIS will appear to have the CLID or DNIS number as his or her username.

When the username sent to the server is a realm, you can specify that the system behaves as though the setting were Keep Name. To do so, set Keep User Name to Keep Realm. (If the username sent to the server is not a realm, the system behaves as though the setting were Change Name.)

To specify the characters that delimit a realm from the username, set the Realm Delimiters parameter. You can specify up to seven characters in any order. If no characters are listed, the system behaves as though Keep User Name were set to Change Name. The default is

@/\% .

Configuring Vendor-Specific Attribute (VSA) support

In VSA compatibility mode, the TAOS unit uses the Vendor-Specific attribute to encapsulate

Lucent vendor attributes and uses the RFC-defined User-Password encryption algorithm.

In the Old compatibility mode (the default), the TAOS unit does not send the Vendor-Specific attribute to the RADIUS server and does not recognize it if the server sends it. In this mode, the system uses the Lucent algorithm of encrypting and decrypting the User-Password attribute, which differs from the RFC-defined algorithm in that it does not null fill the password string to a multiple of 16 bytes before encryption, and it does not use the previous segment’s hash to calculate the next intermediate value when the password is longer than

16 bytes.

Because administrators can configure RADIUS for four different purposes, with each function operating independently of the others and possibly interacting with different RADIUS servers

(or clients), three separate parameters are provided for specifying whether to operate in the older Ascend compatibility mode or in VSA compatibility mode.

CLI configuration

To use the CLI to configure VSA support, proceed as follows:

To enable VSA compatibility mode when the TAOS unit is using RADIUS for authentication and authorization purposes, set Auth-RADIUS-Compat to Vendor-Specific in the Rad-Auth-Client subprofile of the External-Auth profile.

To enable VSA compatibility mode when the TAOS unit is acting as a RADIUS server that is able to accept some requests for certain limited purposes (such as to change filters or disconnect a user), set RADIUS-Server-Compat to Vendor-Specific in the

Rad-Auth-Client subprofile of the External-Auth profile.

To enable VSA compatibility mode when the TAOS unit is using RADIUS for accounting purposes, set Acct-RADIUS-Compat to Vendor-Specific in the Rad-Acct-Client subprofile of the External-Auth profile.

1-8 TAOS RADIUS Guide and Reference

Setting Up the TAOS Unit for RADIUS

Setting up the TAOS unit to communicate with RADIUS

VT100 configuration

To use the VT100 interface to configure VSA support, proceed as follows:

To enable VSA compatibility mode when the TAOS unit is using RADIUS for authentication and authorization purposes, set Auth Compat Mode to VSA in the

Ethernet > Mod Config > Auth menu.

RADIUS Server menu.

To enable VSA compatibility mode when the TAOS unit is using RADIUS for accounting purposes, set Acct Compat Mode to VSA in the Ethernet > Mod Config > Accounting menu.

Limiting excess RADIUS traffic

If you do not use RADIUS pseudo-user profiles, you can direct the TAOS unit to not send requests for pseudo-user information.

CLI configuration

To prevent the TAOS unit from sending requests for the configuration information stored in pseudo-user profiles, set Allow-Extern-Config-Rqsts to No in the Rad-Auth-Client subprofile of the External-Auth profile.

VT100 configuration

To prevent the TAOS unit from sending requests for the configuration information stored in pseudo-user profiles, set Allow-Extern-Config-Rqsts to No in the Ethernet > Mod Config >

Auth menu.

Fine-tuning the interaction between the TAOS unit and RADIUS

This section describes various settings you can make to fine-tune communication between the

TAOS unit and the RADIUS server.

CLI configuration

All the steps that follow set parameters in the External-Auth profile’s Rad-Auth-Client subprofile. To fine-tune the interaction between the TAOS unit and RADIUS, proceed as follows:

Set the Auth-Pool parameter to specify whether the TAOS unit sends the IP address derived from pool #1 to the RADIUS server during an authentication request.

Set Auth-Rsp-Required to Yes to enforce Calling-Line ID (CLID) authentication for connections that require it.

Set the Local-Profiles-First parameter to specify whether the TAOS unit first checks for a local Connection profile when attempting to authenticate a connection.

Set the Auth-Sess-Interval parameter to specify the interval in seconds at which the TAOS unit sends session reports.

TAOS RADIUS Guide and Reference 1-9

Setting Up the TAOS Unit for RADIUS

Setting up the TAOS unit to communicate with RADIUS

Set the Auth-Src-Port parameter to a value representing the TAOS unit’s UDP source port for sending RADIUS authentication requests. (You can specify the same value for authentication and accounting requests.)

Set the Auth-ID-Max-Retry-Time parameter to specify a maximum time limit for

RADIUS CLID or Dialed Number Information Service (DNIS) authentication retries.

VT100 configuration

All the steps that follow set parameters in the Ethernet > Mod Config > Auth menu. To fine-tune the interaction between the TAOS unit and RADIUS, proceed as follows:

Set the Auth Pool parameter to specify whether the TAOS unit sends the IP address from pool #1 to the RADIUS server during an authentication request.

Set Auth Req to Yes to enforce Calling-Line ID (CLID) authentication for connections that require it.

Set the Local Profiles First parameter to specify whether the TAOS unit first checks for a local Connection profile when attempting to authenticate a connection.

Set the Sess Timer parameter to specify the interval in seconds at which the TAOS unit sends session reports.

Set the Auth Src Port parameter to a value representing the TAOS unit’s UDP source port for sending RADIUS authentication requests. (You can specify the same value for authentication and accounting requests.)

Set the Auth Id Max Retry Time parameter to specify a maximum time limit for RADIUS

CLID or Dialed Number Information Service (DNIS) authentication retries.

Specifying whether to customize the User-Name string (CLI only)

To enable a proxy RADIUS server that does not have the shared secret to distinguish between pseudo-user and real user authentication requests, you can customize the User-Name string presented to the RADIUS server during CLID or DNIS authentication. To do so, specify up to

16 characters for the ID-Auth-Prefix setting in the Rad-Auth-Client subprofile. The specified string is inserted as a prefix to the telephone number in CLID or DNIS authentication requests to the RADIUS server. The RADIUS server can then forward different types of requests to different servers.

Configuring distinct ID sequences for packet IDs (CLI only)

RADIUS uses an ID value to aid in Request-Response matching. By default, the TAOS unit uses a single sequence space for the RADIUS ID number in all RADIUS messages, which limits the number of IDs available for assignment to 256. A combined total of 256 authentication and accounting packets are sent before the ID sequence rolls over. However, you can configure distinct ID sequence spaces for RADIUS accounting and authentication packets.

When you configure the TAOS unit to use distinct ID sequence spaces, the RADIUS server must perform additional checks for duplicate detection. The server checks the RADIUS ID value as well as the service type and destination UDP port in each packet. The service type can be determined by sorting all values of the code field into two classes—Auth and Acct—and then comparing the received code value to determine to which class it belongs. The destination

UDP port can be the same for both services when a single RADIUS server performs them.

1-10 TAOS RADIUS Guide and Reference

Setting Up the TAOS Unit for RADIUS

Setting up the TAOS unit to communicate with RADIUS

To configure distinct ID sequence spaces for RADIUS accounting and authentication packets, set Rad-ID-Space to Distinct in the External-Auth profile. When you set Rad-ID-Space to

Distinct, RADIUS authentication and accounting packets do not share the same ID sequence space. The TAOS unit can send a total of 256 authentication packets before the authentication

ID sequence rolls over, and 256 accounting packets before the accounting ID sequence rolls over.

Specifying whether RADIUS authenticates a Telnet session (VT100 only)

To enable the TAOS unit to use a RADIUS server to authenticate a Telnet session, set Telnet

Security to Auth in the Ethernet > Mod Config menu. The TAOS unit first attempts authentication with a RADIUS profile. If that fails, the TAOS unit tries to match a Security profile to the login name and password. The TAOS unit allows the user three login attempts before it closes the Telnet session.

Specifying console port security (VT100 only)

To enable the TAOS unit to use a RADIUS server to authenticate a console port user, set

Console Security to Auth Setting in the System > Sys Config menu. The TAOS unit first attempts authentication with a RADIUS profile. If that fails, the TAOS unit tries to match a

Security profile to the login name and password.The Ascend-Telnet-Profile RADIUS attribute must be set to Full Access or to the name of a valid Security profile.

Specifying information about the host running the APP Server (VT100 only)

To specify information about the host running the APP Server utility, set the APP Server, APP

Host, and APP Port parameters in the Ethernet > Mod Config > Auth menu.

Configuring the unit to recognize a security-card server (VT100 only)

To configure the TAOS unit to recognize a security-card authentication server, set the

Password Server and Password Port parameters in the Ethernet > Mod Config > Auth menu.

Specifying a RADIUS bootup server (VT100 only)

The TAOS unit can obtain pseudo-user configuration information from a RADIUS server other than the one used for authentication. The RADIUS server containing the pseudo-user information is called a bootup server. To configure the TAOS unit to obtain pseudo-user configuration information from a bootup server, proceed as follows:

Open the Ethernet menu.

Open the Mod Config menu.

Open the Auth menu.

For the Auth Boot Host #1 parameter, enter an IP address for the primary bootup server.

To specify a backup server that can service requests should the primary server go offline, enter an IP address for the Auth Boot Host #2 parameter.

To specify the port number the TAOS unit uses when it contacts the bootup server, set the

Auth Boot Port parameter. You can specify a number from 1 to 65535.

Save your changes.

TAOS RADIUS Guide and Reference 1-11

Setting Up the TAOS Unit for RADIUS

Setting up the TAOS unit to communicate with RADIUS

Example of configuring the unit to communicate with RADIUS

The configuration illustrated in Figure 1-1 uses three RADIUS servers. Clients dialing in across the WAN use both framed and unframed protocols on analog and digital lines. The

RADIUS daemon for each server receives client requests on UDP port 512, and the client password is mypass

Figure 1-1. Sample topology for setting up the TAOS unit to use the RADIUS server

Remote framed user

Pipeline™ unit

ISDN

Client password=mypass

LAN

WAN

TAOS unit Analog

Modem

Remote unframed user

RADIUS server #1

10.1.2.1

RADIUS server #2

10.1.2.2

RADIUS server #3

10.1.2.3

In addition to specifying the required parameter values, the configuration indicates that the

TAOS unit must do the following:

• Enforce CLID authentication for all remote users.

• Check for a RADIUS profile before a local Connection profile.

• Send session reports every 60 seconds.

• Use UDP source port 500 for sending authentication requests.

• Allow both framed and unframed users to access PPP.

• Increase the timeout value to 10 seconds.

1-12 TAOS RADIUS Guide and Reference

Setting Up the TAOS Unit for RADIUS

Setting up the TAOS unit to communicate with RADIUS

Sample CLI configuration

To set the values at the CLI for the sample configuration, you would proceed as follows: admin> read external-auth

EXTERNAL-AUTH read admin> set auth-type=radius admin> list rad-auth-client

[in EXTERNAL-AUTH:rad-auth-client] auth-server-1=0.0.0.0

auth-server-2=0.0.0.0

auth-server-3=0.0.0.0

auth-port=0 auth-src-port=0 auth-key="" auth-pool=no auth-timeout=0 auth-rsp-required=no auth-id-fail-return-busy=no auth-id-timeout-return-busy=no auth-sess-interval=0 auth-TS-secure=yes auth-Send67=yes auth-frm-adr-start=no auth-boot-host=0.0.0.0

auth-boot-host-2=0.0.0.0

auth-boot-port=0 auth-reset-time=0 auth-id-max-retry-time=0 auth-radius-compat=old-ascend auth-keep-user-name=change-name auth-realm-delimiters=/\@% id-auth-prefix=”” admin> set auth-server-1=10.1.2.1 admin> set auth-server-2=10.1.2.2 admin> set auth-server-3=10.1.2.3 admin> set auth-port=512 admin> set auth-key=mypass admin> set auth-rsp-required=yes admin> set local-profiles-first=lpf-no admin> set auth-sess-interval=60 admin> set auth-src-port=500 admin> set auth-send67=no admin> set auth-timeout=10 admin> write external-auth

EXTERNAL-AUTH written

TAOS RADIUS Guide and Reference 1-13

Setting Up the TAOS Unit for RADIUS

Setting up system-wide RADIUS accounting

Sample VT100 configuration

To set the values at the VT100 interface for the sample configuration, you would proceed as follows:

Open the Ethernet menu.

Open the Mod Config menu.

Open the Auth menu.

Set Auth to RADIUS.

To specify the address of the primary RADIUS server, set Auth Host #1 to 10.1.2.1.

To specify the address of the secondary RADIUS server, set Auth Host #2 to 10.1.2.2.

To specify the address of the tertiary RADIUS server, set Auth Host #3 to 10.1.2.3.

To specify the UDP port on which the RADIUS daemon accepts client requests, set Auth

Port to 512.

To specify the client password, set Auth Key to mypass

10 To enforce CLID authentication for all remote users, set Auth Req to Yes.

11 To specify that the unit checks for a RADIUS user profile before a local Connection profile, set Local Profiles First to No.

12 To send session reports every 60 seconds, set Sess Timer to 60.

13 To specify the UDP source port for sending authentication requests, set Auth Src Port to

500.

14 To allow both framed and unframed users to access PPP, set Auth Send Attr 6, 7 to No.

15 To increase the timeout values to 10 seconds, set Auth Timeout to 10.

16 Save your changes.

Setting up system-wide RADIUS accounting

The following sections describe how to set up the TAOS unit for system-wide RADIUS accounting. Some of the steps are required. Other settings are optional.

• For a list of required steps, see “Required system-wide accounting configuration tasks” on page 1-14.

•

For a list of optional steps, see “Optional system-wide accounting tasks” on page 1-15.

Required system-wide accounting configuration tasks

When you set up system-wide RADIUS accounting, you must perform the following tasks:

• Specify RADIUS accounting.

• Specify the IP address of a RADIUS host.

• Specify a UDP port number.

• Specify the RADIUS client password.

1-14 TAOS RADIUS Guide and Reference

Setting Up the TAOS Unit for RADIUS

Setting up system-wide RADIUS accounting

Required system-wide accounting configuration tasks at the CLI

To set accounting parameters that affect all users on a system-wide basis, perform the following steps at the CLI:

In the External-Auth profile, set Acct-Type to RADIUS.

Open the Rad-Acct-Client subprofile.

For each Acct-Server parameter, specify the IP address of a RADIUS host.

For the Acct-Port parameter, enter the UDP port number you specified for the authentication process of the daemon.

For the Acct-Key parameter, enter the RADIUS client password.

Required system-wide accounting configuration tasks at the VT100 interface

Open the Ethernet menu.

Open the Mod Config menu.

Open the Accounting menu.

Set Acct to RADIUS.

For each Acct Host parameter, specify the IP address of a RADIUS accounting server.

For the Acct Port parameter, enter the UDP port number you specified for the authentication process of the daemon.

For the Acct Key parameter, enter the RADIUS client password.

Optional system-wide accounting tasks

Depending on your needs, you can set parameters to do the following:

• Specify the source for RADIUS accounting requests.

• Specify a timeout value.

• Set a retry limit.

• Specify a session-report interval.

• Specify a numeric base for the session ID.

• Specify a reset time.

• Specify whether the TAOS unit sends Accounting Stop packets that do not contain a username.

• Specify whether the TAOS unit generates a second Accounting Start packet when the

RADIUS Framed-IP-Address value is assigned.

• Specify whether the TAOS unit sends Accounting Stop packets when a connection fails authentication (CLI only).

• Generate unique accounting IDs on the basis of the source UDP port number of accounting packets (CLI only).

• Specify the interval at which the TAOS unit sends checkpoint records for an active user session (VT100 only).

TAOS RADIUS Guide and Reference 1-15

Setting Up the TAOS Unit for RADIUS

Setting up system-wide RADIUS accounting

Specifying the source for RADIUS accounting requests

You can specify the UDP source port for sending RADIUS accounting requests. If you wish, you can specify the same value for authentication and accounting requests.

CLI configuration

In the Rad-Acct-Client subprofile of the External-Auth profile, set the Acct-Src-Port parameter to a value representing the TAOS unit’s UDP source port for sending RADIUS accounting requests.

VT100 configuration

In the Ethernet > Mod Config > Accounting menu, set the Acct Src Port parameter to a value representing the TAOS unit’s UDP source port for sending RADIUS accounting requests.

Specifying a timeout value

You can specify the number of seconds the TAOS unit waits for a response to a RADIUS accounting request.

CLI configuration

In the Rad-Acct-Client subprofile of the External-Auth profile, set the Acct-Timeout parameter to a number from 1 to 10. The default value is 1.

VT100 configuration

In the Ethernet > Mod Config > Accounting menu, set the Acct Timeout parameter to a number from 1 to 10. The default value is 1.

Specifying a retry limit

When the TAOS unit is configured for RADIUS accounting, it sends Accounting Start and

Stop packets to the RADIUS server to record connections. If the server does not acknowledge a packet within the number of seconds you specify, the TAOS unit tries again, resending the packet until the server responds, or dropping the packet because the queue is full.

You can specify the maximum number of retries for Accounting packets. The TAOS unit always attempts at least one retry. For example, if you set the number of retries to 10, the

TAOS unit makes 11 attempts: the original attempt plus 10 retries.

CLI configuration

In the Rad-Acct-Client subprofile of the External-Auth profile, set the Acct-Limit-Retry parameter to a value greater than 0 (zero). A value of 0 (the default) indicates an unlimited number of retries.

1-16 TAOS RADIUS Guide and Reference

Setting Up the TAOS Unit for RADIUS

Setting up system-wide RADIUS accounting

VT100 configuration

In the Ethernet > Mod Config > Accounting menu, set the Acct Max Retry parameter to a value greater than 0 (zero). A value of 0 (the default) indicates an unlimited number of retries.

Specifying the interval for sending session reports

The TAOS unit can report the number of sessions by class to a RADIUS accounting server.

You can specify the interval, in seconds, at which the TAOS unit sends session reports. (For

complete information about setting up the TAOS unit for session reports, see “Classifying user sessions in RADIUS” on page 1-26.)

CLI configuration

In the Rad-Acct-Client subprofile of the External-Auth profile, set the Acct-Sess-Interval parameter to a number from 0 to 65535.The default value is 0 (zero), which specifies that the

TAOS unit does not send reports on session events.

VT100 configuration

In the Ethernet > Mod Config > Accounting menu, set the Sess Timer parameter to a number from 0 to 65535. The default value is 0 (zero), which specifies that the TAOS unit does not send reports on session events.

Specifying the numeric base for the session ID

The Acct-Session-ID attribute is a unique numeric string identified with the session reported in an Accounting packet. You can control whether the TAOS unit presents Acct-Session-ID to the accounting server in base 10 or base 16. For example, when you specify base 10, the TAOS unit presents a typical session ID to the accounting server in the following format:

"1234567890"

When you specify base 16, the TAOS unit presents the same session ID in the following format:

"499602D2"

Note:

Changing the value of the numeric base while sessions are active creates inconsistencies between the Start and Stop records.

CLI configuration

Specify one of the following settings:

• Acct-Base-10 (decimal) specifies that the numeric base is 10. The default value is

Acct-Base-10.

• Acct-Base-16 (hexadecimal) specifies that the numeric base is 16.

TAOS RADIUS Guide and Reference 1-17

Setting Up the TAOS Unit for RADIUS

Setting up system-wide RADIUS accounting

VT100 configuration

Specify one of the following settings:

• 10 (decimal) specifies that the numeric base is 10. The default value is 10.

• 16 (hexadecimal) specifies that the numeric base is 16.

Specifying the reset time

You can specify the number of seconds that must elapse before the TAOS unit returns to using the primary RADIUS accounting server. The default is 0 (zero), which specifies that the TAOS unit does not return to using the primary RADIUS accounting server.

CLI configuration

In the Rad-Acct-Client subprofile of the External-Auth profile, set the Acct-Reset-Time parameter to the number of seconds that must elapse before the TAOS unit returns to using the primary RADIUS accounting server.

VT100 configuration

In Ethernet > Mod Config > Accounting menu, set the Acct Reset Timeout parameter to the number of seconds that must elapse before the TAOS unit returns to using the primary

RADIUS accounting server.

Specifying whether to send Stop packets with no username

At times, the TAOS unit can send an Accounting Stop packet to the RADIUS server without having sent an Accounting Start packet. Such Stop packets have no username. You can specify that the TAOS unit does not send an Accounting Stop packet that does not contain a username.

CLI configuration

To specify that the TAOS unit does not send an Accounting Stop packet that does not contain a username, set Acct-Stop-Only to No in the Rad-Acct-Client subprofile of the External-Auth profile.

VT100 configuration

To specify that the TAOS unit does not send an Accounting Stop packet that does not contain a username, set Allow Stop Only in the Ethernet > Mod Config > Accounting menu.

1-18 TAOS RADIUS Guide and Reference

Setting Up the TAOS Unit for RADIUS

Setting up system-wide RADIUS accounting

Specifying whether to send a second RADIUS Accounting Start record

You can specify that the TAOS unit sends a second RADIUS Accounting Start record when the RADIUS Framed-IP-Address value is assigned.

CLI configuration

To specify that the TAOS unit sends a second RADIUS Accounting Start record when the

RADIUS Framed-IP-Address value is assigned, set Auth-Frm-Adr-Start to Yes in the

Rad-Acct-Client subprofile of the External-Auth profile.

VT100 configuration

To specify that the TAOS unit sends a second RADIUS Accounting Start record when the

RADIUS Framed-IP-Address value is assigned, set Framed Addr Start to Yes in the

Ethernet > Mod Config > Auth menu.

Specifying whether to send Stop packets when authentication fails (CLI only)

By default, RADIUS Accounting Stop packets are sent for authenticated connections, connections that are dropped before authenticating, and connections that fail authentication. To configure the TAOS unit not to send Stop packets for connections that fail authentication, set

Acct-Drop-Stop-On-Auth-Fail to Yes in the External-Auth > Rad-Acct-Client subprofile.

Generating accounting IDs on the basis of the source port number (CLI only)

RADIUS uses ID values in Request-Response matching. For each unique accounting request

(including retries, if a response is not received within the configured timeout period), RADIUS assigns an 8-bit ID value. The assigned value is freed when the request is no longer pending

(due to the fact that RADIUS matches a request with a response or the request times out).

When the TAOS unit runs at high capacity, RADIUS can run out of unique IDs. To overcome this limitation, you can specify that each request be identified by the UDP source port as well as by the RADIUS ID value.

To specify that the TAOS unit sends the source UDP port number in RADIUS

Request-Response matching, accept the default of Rad-ID-Source-Unique=Port-Unique in the

External-Auth profile. If you want each request to be identified only by the RADIUS ID value, set Rad-ID-Source-Unique to System-Unique.

Specifying the interval for sending checkpoint records (VT100 only)

To specify the interval in minutes at which the TAOS sends checkpoint records for an active user session, set the Acct Checkpoint parameter to a number from 0 to 60. The default is 0

(zero), which specifies that the TAOS unit send no checkpoint records.

TAOS RADIUS Guide and Reference 1-19

Setting Up the TAOS Unit for RADIUS

Setting up system-wide RADIUS accounting

Example of setting up system-wide RADIUS accounting

The configuration illustrated in Figure 1-2 uses three RADIUS accounting servers. Clients dialing in across the WAN use both framed and unframed protocols on analog and digital lines.

The RADIUS daemon for each server receives client requests on UDP port 512, and the client password is mypass

Figure 1-2. Sample network topology for setting up system-wide RADIUS accounting

Remote framed user

Pipeline unit

ISDN

Client password=mypass

LAN

WAN

TAOS unit Analog

Modem

Remote unframed user

RADIUS server #1

10.1.2.1

RADIUS server #2

10.1.2.2

RADIUS server #3

10.1.2.3

In addition to specifying the required parameter values, the configuration also indicates that the TAOS unit must do the following:

• Use UDP source port 500 for sending accounting requests.

• Increase the timeout value to 10 seconds.

• Increase the retry limit to 6.

Sample CLI configuration

To set the values at the CLI for the sample configuration, you would proceed as follows: admin> read external-auth

EXTERNAL-AUTH read admin> set acct-type=radius

1-20 TAOS RADIUS Guide and Reference

Setting Up the TAOS Unit for RADIUS

Setting up system-wide RADIUS accounting

admin> list rad-acct-client

[in EXTERNAL-AUTH:rad-acct-client (changed)] acct-server-1=0.0.0.0

acct-server-2=0.0.0.0

acct-server-3=0.0.0.0

acct-port=0 acct-src-port=0 acct-key="" acct-timeout=0 acct-sess-interval=0 acct-id-base=acct-base-10 acct-reset-time=0 acct-stop-only=yes acct-limit-retry=0 acct-drop-stop-on-auth-fail=no admin> set acct-server-1=10.1.2.1 admin> set acct-server-2=10.1.2.2 admin> set acct-server-3=10.1.2.3 admin> set acct-port=512 admin> set acct-src-port=500 admin> set acct-key=mypass admin> set acct-timeout=10 admin> set acct-limit-retry=6 admin> write external-auth

EXTERNAL-AUTH written

Sample VT100 configuration

To set the values at the VT100 interface for the sample configuration, you would proceed as follows:

Open the Ethernet menu.

Open the Mod Config menu.

Open the Accounting menu.

To specify RADIUS accounting, set Acct to RADIUS.

To specify the address of the primary accounting server, set Acct Host #1 to 10.1.2.1.

To specify the address of the secondary accounting server, set Acct Host #2 to 10.1.2.2.

To specify the address of the tertiary accounting server, set Acct Host #3 to 10.1.2.3.

To specify the UDP port for receiving client requests, set Acct Port to 512.

To specify the UDP source port for sending accounting requests, set Acct Src Port to 500.

10 To specify the client password, set Acct Key to mypass

11 To increase the timeout value to 10 seconds, set Acct Timeout to 10

12 To increase the retry limit to 6, set Acct Max Retry to 6.

13 Save your changes.

TAOS RADIUS Guide and Reference 1-21

Setting Up the TAOS Unit for RADIUS

Setting up accounting on a per-user basis

A network reseller can serve many different ISPs, each with a different access policy. The reseller carries traffic for individual users, and must bill for usage according to the policies of the appropriate ISP. With per-user accounting, a network reseller can direct accounting information about specific users to a RADIUS server belonging to a particular ISP. Each

RADIUS user profile can specify that accounting data goes to one or both of the following locations:

• The server specified at the local interface on the TAOS unit. This server is known as the

default server.

At the CLI, the default server is specified by the Acct-Server parameter in the

External-Auth profile’s Rad-Acct-Client subprofile. At the VT100 interface, the default server is specified by the Acct Host parameter in the Ethernet > Mod Config > Accounting menu.

• The RADIUS accounting server specified by the Ascend-User-Acct-Host attribute in the

RADIUS user profile.

When an accounting event occurs, the TAOS unit sends an accounting message to the specified server. The TAOS unit places each accounting message on a list and waits for an acknowledgment from the RADIUS server. If an acknowledgment does not arrive within the time limit you specify, the TAOS unit resends the accounting message. RADIUS discards the oldest entry on the list when the total number of entries exceeds the maximum.

Overview of per-user accounting attributes

When you set up accounting on a per-user basis, you use the attributes described in Table 1-1.

Table 1-1. Per-user accounting attributes

Attribute

Ascend-User-Acct-Base

(142)

Ascend-User-Acct-Host

(139)

Description Possible values

Specifies whether the numeric base of the RADIUS Acct-Session-ID attribute is 10 or 16.

Specifies the IP address of the RADIUS server to use for the link.

Ascend-User-Acct-Base-10 (0)

Ascend-User-Acct-Base-16 (1)

Ascend-User-Acct-Base-10 is the default.

IP address in dotted decimal notation

n.n.n.n, where n is an integer between

0 and 255.

The default value is 0.0.0.0.

Specifies the RADIUS client password.

Text string. The default value is null.

Ascend-User-Acct-Key

(141)

Ascend-User-Acct-Port

(140)

Specifies a destination UDP port number for the connection.

The UDP port number for the authentication process of the daemon.

1-22 TAOS RADIUS Guide and Reference

Setting Up the TAOS Unit for RADIUS

Setting up accounting on a per-user basis

Table 1-1. Per-user accounting attributes (continued)

Attribute

Ascend-User-Acct-Time

(143)

Ascend-User-Acct-Type

(138)

Description Possible values

Specifies the number of seconds the

TAOS unit waits for a response to a

RADIUS accounting request. If the

TAOS unit does not receive a response within the time specified by

Ascend-User-Acct-Time, it sends the accounting request to the next accounting server specified locally on the TAOS unit, to the server specified by

Ascend-User-Acct-Host in RADIUS, or both.

Integer from 1 to 10. The default is 1.

Specifies the RADIUS accounting server to use for the connection.

Ascend-User-Acct-None (0) specifies that the TAOS unit sends accounting information to the default server.

Ascend-User-Acct-User (1) specifies that the TAOS unit sends accounting information to the RADIUS server specified by the

Ascend-User-Acct-Host attribute in the

RADIUS user profile.

Ascend-User-Acct-User-Default (2) specifies that the TAOS unit sends accounting information both to the

RADIUS server specified by the

Ascend-User-Acct-Host attribute, and to the default server.

Ascend-User-Acct-None is the default.

Specifying per-user accounting attributes

To specify a RADIUS accounting server in a RADIUS user profile:

Set up the RADIUS user profile.

Set the Ascend-User-Acct-Type attribute to specify the RADIUS accounting server for the connection.

Set the Ascend-User-Acct-Host attribute to the IP address of the RADIUS accounting server for the connection.

Set the Ascend-User-Acct-Port attribute to the UDP port number you specified for the authentication process.

Set the Ascend-User-Acct-Key attribute to the value of the RADIUS client password.

Set the Ascend-User-Acct-Base attribute to specify whether the numeric base of the

RADIUS Acct-Session-ID attribute is 10 or 16 (optional).

TAOS RADIUS Guide and Reference 1-23

Setting Up the TAOS Unit for RADIUS

Setting up accounting on a per-user basis

Set the Ascend-User-Acct-Time attribute to the number of seconds the TAOS unit waits for a response to a RADIUS accounting request (optional).

If Ascend-User-Acct-Type is set to Ascend-User-Acct-User-Default, the TAOS unit sends two different packets: one to the server specified in the user profile, and one to the default server.

Example of setting up per-user accounting

In Figure 1-3, the TAOS unit sends accounting information to the RADIUS server at

200.250.56.10 for the user Emma. The destination UDP port is 1645, and the RADIUS client password is mypassword

Figure 1-3. Sample network topology for setting up accounting on a per-user basis

Emma

200.250.55.9

WAN

Client password=mypassword

LAN

Pipeline unit

TAOS unit

RADIUS server

200.250.56.10

RADIUS server

200.250.56.11

RADIUS server

200.250.56.12

To set up per-user accounting for the user Emma, you would configure her user profile as follows:

Emma User-Password="m2dan", Service-Type=Framed-User

Framed-Protocol=PPP,

Framed-IP-Address=200.250.55.9,

Ascend-Link-Compression=Link-Comp-Stac,

Framed-Compression=Van-Jacobson-TCP-IP,

Ascend-Route-IP=Route-IP-Yes,

Ascend-Metric=2,

Ascend-User-Acct-Type=Ascend-User-Acct-User,

Ascend-User-Acct-Host=200.250.56.10,

Ascend-User-Acct-Port=1645,

Ascend-User-Acct-Key="mypassword"

1-24 TAOS RADIUS Guide and Reference

Setting Up the TAOS Unit for RADIUS

Setting up accounting with dynamic IP addressing

In some networks, the RADIUS accounting server requires an IP address for all callers. For callers that receive an IP address from a pool, this requirement presents a problem. During PPP authentication, RADIUS verifies the name and password, but not the caller’s IP address. To track calls during the authentication period, you must set up one or more IP address pools.

Then, you must specify whether the TAOS unit includes the caller’s assigned IP address as the value of the Framed-Address attribute. The TAOS unit allocates this address from pool #1. (If you do not define pool #1, the call does not have an IP address during authentication.) Because an IP assignment is not usually part of an Access-Request, you must modify the RADIUS daemon.

CLI configuration

In the Rad-Auth-Client subprofile of the External-Auth profile, set Auth-Pool to Yes. When

Auth-Pool is set to Yes, the TAOS unit includes the caller's assigned IP address as the value of the Framed-Address attribute. The assigned IP address might not last the duration of the connection, or it might not be meaningful. Here are five possibilities:

• If Assign-Address is set to No in the IP-Answer subprofile of the Answer-Defaults profile, and the caller’s RADIUS user profile does not supply an IP address for the caller, the

TAOS unit returns the IP address to pool #1. However, the address continues to appear in

RADIUS accounting entries.

• If Assign-Address is set to No and the caller’s RADIUS user profile supplies an IP address for the caller, the TAOS unit returns the IP address to pool #1. The IP address from the user profile appears in RADIUS accounting entries.

• If Assign-Address is set to Yes, and Ascend-Assign-IP-Pool in the RADIUS user profile points to a pool that has no valid IP address, the IP address from pool #1 appears in accounting entries. The TAOS unit returns the address to the pool when the call disconnects.

• If Assign-Address is set to Yes and Must-Accept-Address-Assign is set to Yes on the

TAOS unit, and Ascend-Assign-IP-Pool points to a pool that has a valid IP address, the IP address from that pool appears in RADIUS accounting entries for the duration of the call.

The TAOS unit returns the address to the pool when the call disconnects.

• If Assign-Address is set to Yes, Must-Accept-Address-Assign is set to No,

Ascend-Assign-IP-Pool points to a pool that has a valid IP address, and the caller does not specify an address, the IP address from the pool appears in RADIUS accounting entries. If the caller does specify an IP address, that address appears in RADIUS accounting entries.

VT100 configuration

Open the Ethernet menu.

Open the Mod Config menu.

Open the Auth menu.

Set Auth Pool to Yes.

Save your changes.

TAOS RADIUS Guide and Reference 1-25

Setting Up the TAOS Unit for RADIUS

Classifying user sessions in RADIUS

The assigned IP address might not last the duration of the connection or might not be meaningful. Here are five possibilities:

• If Assign Adrs is set to No and the caller’s RADIUS user profile does not supply an IP address for the caller, the TAOS unit returns the IP address to pool #1, but the address continues to appear in RADIUS accounting entries.

• If Assign Adrs is set to No and the caller’s RADIUS user profile does supply an IP address for the caller, the IP address from pool #1 returns to the pool, and the IP address from the user profile appears in RADIUS accounting entries.

• If Assign Adrs is set to Yes and Ascend-Assign-IP-Pool in the RADIUS user profile points to a pool that has no valid IP address, the IP address from pool #1 appears in

RADIUS accounting entries, and returns to the pool only when the call disconnects.

• If Assign Adrs is set to Yes, Assign Only is set to Yes, and Ascend-Assign-IP-Pool points to a pool that has a valid IP address, the IP address from that pool appears in RADIUS accounting entries for the duration of the call, and returns to the pool when the call disconnects.

• If Assign Adrs is set to Yes, Assign Only is set to No, and Ascend-Assign-IP-Pool points to a pool that has a valid IP address, the IP address from that pool appears in RADIUS accounting entries, unless the caller specifies an address. If the caller specifies an IP address, it appears in RADIUS accounting entries and the IP address derived from the pool is returned.

Classifying user sessions in RADIUS

The Class and Ascend-Number-Sessions attributes enable access providers to classify their user sessions for purposes such as billing clients on the basis of the service option they choose.

If you customize RADIUS properly, you can set up the TAOS unit to periodically issue accounting requests.

Using the Class attribute

If you include the Class attribute in the RADIUS user profile, the RADIUS server sends it to the TAOS unit in the Access-Accept packet when the session begins. Class then appears in

Accounting-Request packets the TAOS unit sends to the RADIUS accounting server whenever a session starts and whenever a session stops. The accounting entries specify the class on a per-user and per-session basis.

Using the Ascend-Number-Sessions attribute

The Ascend-Number-Sessions attribute reports information about all user sessions. The attribute has a compound value. The first part indicates a user-session class. The second part reports the number of active sessions in that class. In the case of multichannel calls, such as

MP+ calls, each separate connection counts as a session.

1-26 TAOS RADIUS Guide and Reference

Setting Up the TAOS Unit for RADIUS

Understanding pseudo-user profiles

Generating periodic accounting requests

You can configure the TAOS unit to send accounting requests at regular intervals. At the specified interval, the TAOS unit reports the number of open sessions by sending an

Ascend-Access-Event-Request packet (code 33). The packet contains the NAS-IP-Address attribute, followed by a list of Ascend-Number-Sessions attributes.

Only RADIUS daemons that you customize to recognize packet code 33 respond to

Ascend-Access-Event-Request packets from the TAOS unit. Other accounting daemons ignore it. When modifying the daemon, make sure that it recognizes the following format for an

Ascend-Access-Event-Request packet:

Code (8-bit)=33

Identifier (8-bit)

Length (16-bit)

Authenticator (48-bit for an accounting server, 64-bit for an authentication server)

List of attributes

CLI configuration

To generate periodic accounting requests, set the Acct-Sess-Interval parameter in the

External-Auth profile’s Rad-Acct-Client subprofile.

VT100 configuration

To generate periodic accounting requests, set the Sess Timer parameter in the Ethernet > Mod

Config > Accounting menu,

Example of classifying user sessions

Suppose that the TAOS unit has three classes of clients: Class-1, Class-2, and Class-3. At the time of the sessions report, there are eight active sessions: three Class-1 sessions, four Class-2 sessions, and one Class-3 session. The accounting packet that the TAOS unit sends to the

RADIUS accounting server has three Ascend-Number-Session attributes, one for each of the class-session pairs.

Understanding pseudo-user profiles

A pseudo-user profile contains information that the TAOS unit can query. It does not exist for the purpose of authenticating a user. Rather, it enables you to specify static route configurations, Frame Relay profile information, and other types of data.

Along with other attributes on the first line, the values you specify for User-Name and

User-Password in a pseudo-user profile determine how the TAOS unit uses the profile.

Table 1-2 describes how to set up the first line of different types of pseudo-user profile for

various purposes.

TAOS RADIUS Guide and Reference 1-27

Setting Up the TAOS Unit for RADIUS

Understanding pseudo-user profiles

Some profiles use the following arguments:

• The name argument is the system name of the TAOS unit.

• The num argument is a number in a sequential series, starting at 1.

Note:

The first line of a pseudo-user profile cannot use newlines. The specifications appear on multiple lines here for printing purposes only.

Table 1-2. First-line configuration of pseudo-user profiles

Element configured

First-line specification

Outgoing calls For the User-Name attribute, specify the name of the remote device that will receive outgoing calls, appending

-Out

to the user name. Then, set

User-Password="ascend"

and

Service-Type=

Outbound-User

. The Service-Type setting ensures that no one can use the profile for authentication of an incoming call.

Nailed/MPP connection

Nailed-up connection permconn-

Service-Type=Outbound-User permconnname num User-Password="ascend", name-num User-Password="ascend",

Service-Type=Outbound-User

Message text and list of hosts

For a configuration specific to a single TAOS unit: initial-bannername

User-Password="ascend",

Service-Type=Outbound-User

For a configuration used by several TAOS units: initial-banner User-Password="ascend",

Service-Type=Outbound-User

Frame Relay profile

Frame Relay user profile

IP address pools

Pool chaining frdlinkname-num User-Password="ascend",

Service-Type=Outbound-User permconnname

num

User-Password="ascend",

Service-Type=Outbound-User poolsname

User-Password="ascend",

Service-Type=Outbound-User poolsname User-Password="ascend",

Service-Type=Outbound-User

Static IP routes For an IP dialout route specific to a single TAOS unit: routename-num User-Password="ascend",

Service-Type=Outbound-User

For an IP dialout route used by several TAOS units: routenum User-Password="ascend",

Service-Type=Outbound-User

1-28 TAOS RADIUS Guide and Reference

Setting Up the TAOS Unit for RADIUS

Understanding pseudo-user profiles

Table 1-2. First-line configuration of pseudo-user profiles (continued)

First-line specification Element configured

Static IPX routes

Private route tables

Filters

For an IPX dialout route specific to a single TAOS unit: ipxroute-namenum

User-Password="ascend",

Service-Type=Outbound-User

For an IPX dialout route used by several TAOS units: ipxroutenum

User-Password="ascend",

Service-Type=Outbound-User profilename User-Password="ascend",

Service-Type=Outbound-User filtername

User-Password="ascend",

Service-Type=Outbound-User

The following pseudo-user profile defines five address pools, which form two pool chains: pools-JFAN-TNT Password = "ascend", Service-Type = Outbound-User,

Ascend-IP-Pool-Chaining = IP-Pool-Chaining-Yes,

Ascend-IP-Pool-Definition = "1 10.1.1.1 50",

Ascend-IP-Pool-Definition = "2 11.1.1.1 50",

Ascend-IP-Pool-Definition = "3 12.1.1.1 50"

Ascend-IP-Pool-Definition = "7 13.1.1.1 50",

Ascend-IP-Pool-Definition = "8 14.1.1.1 50"

TAOS RADIUS Guide and Reference 1-29

Understanding RADIUS Authentication

What is RADIUS authentication? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

RADIUS profile formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2

Preauthentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2

RADIUS password handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3

Authenticating framed protocol sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6

Token-card authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8

Tunnel authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15

Callback after authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20

What is RADIUS authentication?

Authentication 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. In determining which type of authentication to use, consider whether the call is between two machines or between a human being and a machine, and then decide how strong the authentication mechanism must be.

For example, if the connection is negotiated between two machines, consider whether the other location is trusted, whether that machine protects its own networks against security attacks, and whether it is physically accessible to many users. If the connection is negotiated with a user who must type in a token or password, consider how secure the password is and how frequently you want it to change. Once the user’s connection is authenticated, you can use authorization restrictions to prevent the caller from accessing systems or networks you want to protect.

TAOS RADIUS Guide and Reference 2-1

Understanding RADIUS Authentication

RADIUS profile formats

RADIUS user entries are composed of three parts:

User-Name Check-Items

Reply-Items

Each element is described below.

• User-Name

The User-Name must be left justified. It is typically the name of the caller (or calling device), but it can also be a telephone number, a special string indicating a pseudo-user profile, or the string DEFAULT (for the default user profile).

• Check-Items

Check-Items must be on the same line as the User-Name, and must be separated by white space from the User-Name. For the user to be authenticated, Check-Items must include attribute-value pairs that match the attributes present in an Access-Request packet.

Check-Items typically include the password for the entry.

• Reply-Items

Reply-Items must be indented and separated from the User-Name and Check-Items by a newline. (If a Reply-Item is not indented, it is interpreted as the User-Name of a new entry.) If a user profile contains one or more Reply-Items, each one appears on a new indented line and, except for the final Reply-Item, ends in a comma. Each Reply-Item consists of an attribute-value pair returned in Access-Accept messages. These attribute-value pairs specify the services authorized for the user.

Preauthentication

Calling Line ID (CLID) or Dialed Number Information Service (DNIS) verification occurs before the TAOS unit accepts a call and begins the process of authenticating a password.

• A CLID is the telephone number of a calling device. You can use CLID for authentication only where the call information is available end-to-end and Automatic Number

Identification (ANI) 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. Typically, people use CLID to protect against a situation in which an unauthorized user obtains the name, password, and IP address of an authorized user, and calls in from another location.

• A DNIS number is the telephone number the remote device calls to connect to the TAOS unit, but without a trunk group or dialing prefix specification. When the profile requires

DNIS authentication, the number called must match a telephone number in a local

Connection profile or RADIUS user profile.

When a caller’s profile specifies a CLID, the TAOS unit can compare that number to the one presented by the telco switch, and can therefore verify that the call is coming from a known location.

2-2 TAOS RADIUS Guide and Reference

Understanding RADIUS Authentication

RADIUS password handling

RADIUS uses the following attribute-value pairs for specifying CLID and DNIS numbers:

Attribute Value

Calling-Station-Id (31)

Specifies the CLID—the telephone number of the calling device.

When a user dials in using MP or MP+, the calling device might have more than one telephone number associated with it. In that case, the CLID is the telephone number associated with the channel in use.

Called-Station-Id (30) Specifies the DNIS number—the called-party number, an

Information Element of the Q.931 ISDN signaling protocol.

Ascend-Require-Auth

(201)

Specifies whether the profile requires additional authentication after called-number authentication. Valid values are

Not-Require-Auth (0), which is the default, and Require-Auth (1).

For RADIUS-authenticated connections, if the Calling-Station-Id or Called-Station-Id value is known, it is included in the Access-Request to the RADIUS server. If the Calling-Station-Id is specified on the first line of the profile, and the Calling-Station-Id presented to the server does not match the value of the Calling-Station-Id attribute, the Access-Request is rejected. The following user profile specifies a CLID: emma User-Password="test", Calling-Station-Id="5551213"

Service-Type=Framed-User,

Framed-Protocol=PPP,

Ascend-Assign-IP-Pool=1,

Ascend-Route-IP=Route-IP-Yes

The user is limited to a specific telephone number. This profile could be used to prevent multiple user connections. Unless the user owns a PBX or other service that always gives out the same number for multiple phone lines, only one user will be able to connect. CLID authentication is normally used for security—to prevent a system admin or other important account from be abused.

RADIUS password handling

RADIUS supports connection-specific passwords and reserved passwords. You can set up password aging and expiration, specify a default profile, and use shared secrets.

Reserved RADIUS passwords

In addition to the connection-specific password typically assigned to a specific user profile, the

RADIUS recognizes the following reserved values for the User-Password (2) attribute:

Password values

UNIX

SAFEWORD

Description

Instructs the RADIUS server use UNIX authentication. This password does not work with the CHAP protocol.

Instructs the RADIUS server to request validation from an Enigma

Logic SafeWord server. (For details, see “Token-card authentication” on page 2-8.)

TAOS RADIUS Guide and Reference 2-3

Understanding RADIUS Authentication

RADIUS password handling

Password values

ACE ascend

Ascend-CLID or

Ascend-DNIS

Description

Instructs the RADIUS server to request validation from a Security

Dynamics ACE server. (For details, see “Token-card authentication” on page 2-8.)

Used for pseudo-user and other system profiles. When this password is in use, the Service-Type attribute must always specify

Outbound-User. This setting prevents callers from accessing the network using a well-known password. Although the system does

not reject the profile without the Outbound-User setting, omitting it introduces a serious security risk.

Used for pre-authenticating calls using CLID or DNIS information

When these passwords are in use, the Service-Type attribute must always specify Outbound-User. This setting prevent callers from accessing the network using a well-known password. Although the

system does not reject the profile without the Outbound-User setting, omitting it introduces a serious security risk.

Password expiration

Some RADIUS daemons support password aging and expiration, and provide a method for enabling users who dial into the terminal server to replace expired passwords. Password expiration does not work for passwords that are not stored in the RADIUS database

(UNIX-authenticated or token-card passwords), or reserved passwords (such as ascend

The following attribute-value pairs support password aging and expiration.

2-4

Attribute

Ascend-PW-Expiration

(21)

Ascend-PW-Lifetime

(208)

Ascend-PW-Warntime

(207)

Value

Expiration date for the user’s password (consisting of a month, day, and year specification.) Its value can be updated automatically when a user renews a password. You must specify

Ascend-PW-Expiration as a Check-Item.

Number of days a password can be valid. You can specify an integer from 0 (the default) to 65535. The default disables password expiration. If the attribute is set to a nonzero value, and the user changes the password, the TAOS unit adds the value to the current date and updates the Ascend-PW-Expiration date. This method provides a way of specifying new expiration dates automatically rather than hard-coding a date.

Number of days a user will be warned that his or her password is about to expire (an integer from 0 to 65535).

Following is a portion of a sample profile for a user whose password expires on December 31,

1999: brian User-Password="localpw", Ascend-PW-Expiration="Dec 31, 1999"

Ascend-PW-Lifetime=30,

Ascend-PW-Warntime=2,

...

TAOS RADIUS Guide and Reference

Understanding RADIUS Authentication

RADIUS password handling

When the user dials in on December 29, 1999, he receives a message that his password will expire in two days. If he changes the password at that time (by using the Password command in the terminal server), the RADIUS server updates the password, adds 30 days to the current date, and updates the Ascend-PW-Expiration date to January 30, 2000.

If the user dials in on December 31, 1999, he receives a message that his password has expired, and he is prompted to enter both the expired password and a new one. The system prompts twice for the new password to verify the entry. If the user enters the information incorrectly, the system displays another prompt and the user can try again, for a total of up to three attempts.

If the update is successful, the system sends the new password to the RADIUS server and displays the following message, immediately followed by the terminal-server prompt:

Password Updated

If the update fails for any reason, the following message appears:

Password NOT Changed

DEFAULT user profile

A special user profile named DEFAULT can be placed at the end of the users file to specify what to do with users who do not have a profile. Only one DEFAULT entry is allowed, and it must be the last entry in the file. For example, the following entry allows terminal-server users to log in using their UNIX account names and passwords:

DEFAULT User-Password="UNIX"

Service-Type=Login-User,

Shared secrets and secure exchanges

A shared secret is used to authenticate packets exchanged between the TAOS unit and the

RADIUS server, and to encrypt passwords from dial-in callers before sending them across the local network. A shared secret is a single value known to both systems.

Figure 2-1 shows a basic example of how passwords presented by incoming calls are handled between the systems:

Figure 2-1. Shared secret used between the TAOS unit and a RADIUS server

1. Clear-text password

(sent via PAP)

2. Encryption using shared secret

3. Decryption using shared secret

WAN

4. Access-Accept or

Access-Reject

The shared secret is used to encrypt the password from the dial-in call before sending it across the local network to a RADIUS server. The encryption makes use of the shared secret, the

Authenticator field, and an encoding method, such as MD5, CHAP, or DES.

TAOS RADIUS Guide and Reference 2-5

Understanding RADIUS Authentication

Authenticating framed protocol sessions

For dial-out calls, the RADIUS server sends the remote-end password to the Network Access

Server (NAS). RADIUS encrypts passwords before sending them to the NAS if the dial-out profile uses the Ascend-Send-Secret (214) attribute to specify the password. If the profile specifies Ascend-Send-Secret and the RADIUS daemon does not encrypt the password, authentication will fail.

If the dial-out profile uses the Ascend-Send-Passwd (232) attribute to specify the password instead, the RADIUS daemon performs no encryption before sending the password to the

NAS. This configuration might be required if you are using a RADIUS server that does not support outbound password encryption.

Unless you are using a RADIUS daemon that does not support Ascend-Send-Secret, its use is recommended in place of Ascend-Send-Passwd. Using Ascend-Send-Secret protects against local sniffers detecting dial-out passwords.

Authenticating framed protocol sessions

During establishment of a PPP data link, the dialing and answering units use Link Control

Protocol (LCP) packets to negotiate the authentication protocol. After completing LCP negotiations, the TAOS unit authenticates the user by means of the agreed-upon authentication protocol. It then negotiates the upper layer Network Control Protocols (NCPs) to set up the link’s network-layer protocols.

If the link is configured to require authentication, the units at each end negotiate an authentication protocol. The answering unit always determines which authentication method to use for the call. A multilink connection begins with authentication of a base channel, and subsequent channels are authenticated separately when they are added to the call.

Specifying an authentication protocol required for dial-in calls

To require an authentication protocol for name and password authentication of framed sessions, you must configure the TAOS unit locally. You can specify any of the following protocols:

• Password Authentication Protocol (PAP), which provides a simple method for the TAOS unit to establish its identity in a two-way handshake. The remote device must support

PAP.

• Challenge Handshake Authentication Protocol (CHAP), which is more secure than PAP.

When the TAOS unit is using CHAP to authenticate the remote device, the system can periodically verify the identity of the remote device by means of a three-way handshake and encryption. The remote device must support CHAP.

• Microsoft CHAP (MS-CHAP), which uses DES and MD4 encryption. It is used primarily by Windows NT and LAN Manager systems.

How PAP works

PAP is a two-way handshake method of establishing a caller’s identity. Used only once, during the initial establishment of the data link, PAP is not a strong authentication method. Passwords are sent as plain text across the WAN, so eavesdroppers with the proper equipment and software can potentially detect and reuse correct passwords.

2-6 TAOS RADIUS Guide and Reference

Understanding RADIUS Authentication

Authenticating framed protocol sessions

PAP authentication is typically used because the available password method or database requires it. For example, if the UNIX password file is used to authenticate calls (by means of

RADIUS), the TAOS unit forces the peer to use PAP.

When PAP is used with RADIUS authentication, the TAOS unit uses the shared secret to encrypt the text password it receives from the caller before sending the password across the network to the server. The RADIUS server decrypts the password using the same shared secret before performing authentication or passing it to another authentication server, such as a UNIX host or token-card server.

How CHAP and MS-CHAP work

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. The caller 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 can 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.

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.

When CHAP or MS-CHAP is used with RADIUS authentication, the following events occur:

The TAOS unit sends a random, 128-bit challenge to the calling unit.

The calling unit calculates an MD5 digest by means of its password, the challenge, and the

PPP packet ID.

The calling unit sends the MD5 digest, the challenge, and the PPP packet ID (but not the password) to the TAOS unit. The TAOS unit never has the caller’s password.

The TAOS unit forwards the digest, along with the original challenge and PPP packet ID, to the RADIUS server. No encryption is necessary, because MD5 creates a one-way code that cannot be decoded.

The RADIUS server looks up the caller’s password in a local database, and calculates an

MD5 digest with the local version of the remote secret, along with the challenge and PPP packet ID received from the TAOS unit.

The RADIUS server compares the calculated MD5 digest with the digest it received from the TAOS unit. If the digests are the same, the passwords matched, and the call is accepted.

TAOS RADIUS Guide and Reference 2-7

Understanding RADIUS Authentication

Token-card authentication

Requesting a protocol for use in dial-out calls

Dial-out RADIUS profiles can specify the authentication protocol and password used to send authentication information to the remote end. RADIUS uses the following attribute-value pairs to request an authentication protocol in a dial-out profile.

Attribute Value

Ascend-Authen-Alias

(203)

Ascend-Send-Secret

(214)

Ascend-Send-Auth (231) Authentication protocol requested for a dial-out call. With the default Send-Auth-None (0) value, no authentication is negotiated.

Other values are Send-Auth-PAP (1) and Send-Auth-CHAP (2).

Password sent to the remote end during authentication of the dial-out call. If the server does not support this attribute, use

Ascend-Send-Passwd (232) instead. For details, see “Shared secrets and secure exchanges” on page 2-5.

The following profiles request CHAP when the device dials out to the remote end: hanif User-Password="localpw"

Service-Type=Framed-User,

Framed-Protocol=PPP,

Framed-IP-Address=10.1.2.3,

Framed-IP-Netmask=255.255.255.248

route-tnt-1 User-Password="ascend", Service-Type=Outbound-User

Framed-Route="10.1.2.3/29 10.1.2.3 1 n hanif-out" hanif-out User-Password="localpw", Service-Type=Outbound-User

User-Name="hanif",

Ascend-Dial-Number="555-1212",

Framed-Protocol=PPP,

Framed-IP-Address=10.1.2.3

Framed-IP-Netmask=255.255.255.248,

Ascend-Send-Auth=Send-Auth-CHAP,

Ascend-Send-Secret="remotepw"

Token-card authentication

In token-card authentication, the RADIUS server is the intermediary between the TAOS unit answering the call and an External Authentication Server (EAS), such as a Security Dynamics

ACE/Server or an Enigma Logic SafeWord server. In RADIUS, you can specify the following token-card authentication modes:

• PAP-TOKEN

• PAP-TOKEN-CHAP

• CACHE-TOKEN

2-8 TAOS RADIUS Guide and Reference

Understanding RADIUS Authentication

Token-card authentication

Enhanced security with token cards

Token cards protect against both passive attacks and replay attacks. In a replay attack, an unauthorized user records valid authentication information exchanged between systems and then replays it later to gain entry. Because token cards provide one-time-only passwords, the password changes many times a day, making replay impossible.

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 TAOS unit 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 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 local profile configuration, which must still specify RADIUS as the external server.

Simple method of authenticating token-card calls

The TAOS unit can support token-card authentication from non-TAOS units by authenticating the calls in the terminal-server software. The unit uses normal PAP authentication to do the challenge-response token exchanges. For example, the following RADIUS profile specifies authentication from an ACE server: carlos User-Password="ACE"

Service-Type=Framed-User,

Framed-Protocol=PPP,

Framed-IP-Address=10.2.3.78,

Framed-IP-Netmask=255.255.255.255

TAOS RADIUS Guide and Reference 2-9

Understanding RADIUS Authentication

Token-card authentication

The RADIUS server discards the user’s response to the initial terminal-server Password prompt, so the user can enter any value. The RADIUS server generates an Access-Challenge with a challenge prompt (typically a Passcode prompt for ACE authentication), and uses the response to that challenge to actually authenticate the user with the EAS.

If the caller's profile specifies the following attribute-value pair, the system does not require a challenge-response exchange:

Attribute

Ascend-Token-Immediate

(200)

Value

Bypasses the challenge-response procedure required by some token-card authentication methods. Valid values are

Tok-Imm-No (0), which is the default, and Tok-Imm-Yes (1). If used, Ascend-Token-Immediate must be a Check-Item in the

RADIUS profile.

Note:

Setting this attribute to Tok-Imm-Yes makes the profile incompatible with PAP-TOKEN, PAP-TOKEN-CHAP, and

CACHE-TOKEN authentication.

When users have a token card that not require a challenge-response exchange (such as ACE), you can use Ascend-Token-Immediate to simplify the authentication process. Users respond to the initial Password prompt with the current token. The RADIUS server does not discard this initial response, but uses it to authenticate the call via the EAS.

Following is a sample RADIUS profile using Ascend-Token-Immediate: robin User-Password="ACE", Ascend-Token-Immediate=Tok-Imm-Yes

Service-Type=Framed-User,

Framed-Protocol=PPP,

Framed-IP-Address=10.3.4.5,

Framed-IP-Netmask=255.255.255.255

Authenticating token-card connections from TAOS units

Figure 2-2 shows a dial-in connection to a TAOS unit on a secure network. The remote user must use a token card to gain access to the secure network.

Figure 2-2. Token card authentication for dial-in connections

EAS

NAS

WAN

Pipeline unit

User with token card

RADIUS

2-10 TAOS RADIUS Guide and Reference

Understanding RADIUS Authentication

Token-card authentication

The following events take place:

A user with a token card initiates a connection to the TAOS unit (the NAS).

The NAS sends an Access-Request packet to the RADIUS server to authenticate the incoming call, and the RADIUS server forwards the connection request to the EAS (an

ACE/Server or SafeWord server).

The EAS sends an Access-Challenge packet back through the RADIUS server and the

TAOS unit 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 token. If the user enters an incorrect token, 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 TAOS unit. If authentication is unsuccessful, the TAOS unit receives an

Access-Reject packet and terminates the call. If authentication is successful, the TAOS unit receives an Access-Accept packet containing a list of Attribute-Value pairs from the user profile in the RADIUS server’s database. The TAOS unit uses the Attribute-Value pairs to create the connection.

Using PAP-TOKEN authentication

PAP-TOKEN is an extension of PAP authentication. It is not practical for multichannel calls, because if bandwidth requirements cause another channel to come up, the TAOS unit must interrupt the session to challenge the user for another token.

With PAP-TOKEN, the caller’s send-password is sent as part of the initial session negotiation, which triggers a challenge from the EAS. The EAS returns a challenge, and the user types in the current token obtained from the token card. The token is sent in the clear (by means of

PAP), but because it is used only once, sending the token in the clear might not considered a serious security risk. The response to the initial challenge authenticates the base channel of the call. If bandwidth requirements cause another channel to come up, the user is challenged for a password.

Figure 2-3 shows a PC user with a SecurID token card dialing into a MAX TNT® unit through a Pipeline unit. The EAS is a UNIX host running RADIUS and Security Dynamics ACE software.

Figure 2-3. PAP-TOKEN with an ACE server

EAS

MAX TNT unit

WAN

Pipeline unit

10.1.2.3/30

TAOS RADIUS Guide and Reference 2-11

Understanding RADIUS Authentication

Token-card authentication

When the EAS sends an Access-Challenge packet back through the RADIUS server and the

MAX TNT unit to the user dialing in, the user sees the challenge message, obtains the current token, and enters that password in response to the challenge message. The password travels back through the MAX TNT and the RADIUS server to the EAS, where it is authenticated.

Following is a RADIUS profile for the PC user:

Connor User-Password="ACE"

Service-Type=Framed-User,

Framed-Protocol=PPP,

Framed-IP-Address=10.1.2.3,

Framed-IP-Netmask=255.255.255.252

Using PAP-TOKEN-CHAP authentication

PAP-TOKEN-CHAP is appropriate for token-authenticating multilink calls. The base channel is authenticated by means of PAP-TOKEN. If channels are added to the call, they are authenticated by means of CHAP. When the initial call is authenticated, the RADIUS server informs the NAS of the password to expect for subsequent channels by sending the value as

Ascend-Receive-Secret.

In addition to the requirement that the User-Password attribute must specify ACE or

SAFEWORD, PAP-TOKEN-CHAP authentication requires the following attribute-value pair:

Attribute

Ascend-Receive-Secret

(215)

Value

Text string of up to 20 characters, which must match the password sent by the remote end to authenticate added channels. The

RADIUS server delivers the receive-secret to the NAS when the initial call is authenticated. The NAS stores the receive-secret for the caller, and uses it to create the digest sent to the RADIUS server by means of CHAP.

Figure 2-4 shows a user with a token card dialing into a MAX TNT unit through a Pipeline unit. The EAS is a UNIX host running RADIUS and Enigma Logic SafeWord server software.

After authentication, the user can open a multilink session.

Figure 2-4. PAP-TOKEN-CHAP with a Safeword server

EAS

MAX TNT unit

WAN

Pipeline unit

10.2.3.4/30

2-12 TAOS RADIUS Guide and Reference

Understanding RADIUS Authentication

Token-card authentication

Following is a RADIUS user profile for the dial-in user:

Raoul User-Password="SAFEWORD"

Service-Type=Framed-User,

Framed-Protocol=MPP,

Framed-IP-Address=10.2.3.4,

Framed-IP-Netmask=255.255.255.252,

Ascend-Receive-Secret="aux-send",

Ascend-Base-Channel-Count=2,

Ascend-Maximum-Channels=2

Using CACHE-TOKEN authentication

CACHE-TOKEN is another way of token-authenticating multilink calls. The RADIUS server caches an encrypted version of the token for a specified number of minutes. If the caller dials additional channels, the RADIUS server receives the request from the NAS, verifies that the token has not expired, and uses the cached token to authenticate the channels. If the token has expired, the request must be authenticated through the EAS with another challenge token.

In addition to the requirement that the User-Password attribute must specify ACE or

SAFEWORD, CACHE-TOKEN authentication uses the following attribute-value pairs:

Attribute

Ascend-Receive-Secret

(215)

Ascend-Token-Expiry

(204)

Value

Text string of up to 20 characters, which must match the password sent by the remote end to authenticate the initial call. The

RADIUS server uses this value to decrypt the hashed digest sent by the NAS. The hashed digest is derived from the token sent by the caller and the normal password in the remote-end profile.

Number of minutes a cached token remains valid. The default of 0

(zero) means that token caching is not allowed.

Ascend-Token-Expiry must be a Check-Item.

Token expiration is done solely in the RADIUS server. The NAS forwards authentication requests, and if the token has expired, the

RADIUS server forwards the request to the EAS, which returns another challenge to the remote end.

Ascend-Token-Idle (199) Number of minutes a cached token remains valid if a call is idle.

By default, the token remains alive until the value of

Ascend-Token-Expiry is reached. Ascend-Token-Idle must be a

Check-Item.

Ascend-Token-Idle is useful for enforcing authentication when a connection comes up again after an idle period. If you do not specify this attribute, the cached token remains valid until the value of the Ascend-Token-Expiry attribute causes it to expire.

Typically, the value of Ascend-Token-Idle is lower than the value of Ascend-Token-Expiry.

TAOS RADIUS Guide and Reference 2-13

Understanding RADIUS Authentication

Token-card authentication

Figure 2-5 shows a user who dials in using a Pipeline unit and is authenticated by an EAS, which is a UNIX host running RADIUS and Enigma Logic SafeWord server software.

Figure 2-5. CACHE-TOKEN with a SafeWord server

EAS

NAS

WAN

Pipeline unit

10.3.4.5/30

Following is a RADIUS user profile for the dial-in user:

Aydin User-Password="SAFEWORD", Ascend-Token-Expiry=30,

Ascend-Token-Idle=10

Service-Type=Framed-User,

Framed-Protocol=MPP,

Framed-IP-Address=10.3.4.5,

Framed-IP-Netmask=255.255.255.252,

Ascend-Receive-Secret="chap-val",

Ascend-Base-Channel-Count=2,

Ascend-Maximum-Channels=2

Using ACE authentication for network users

If the EAS is a Secure Dynamics ACE server, multiple users on a remote network can dial in using a single profile that specifies the remote router name. To dial in, a user must enter the token in the following format: token.username

The RADIUS server presents the username

argument, rather than the name of the router, to the ACE server. Token caching still functions normally. All users share the same RADIUS profile, and RADIUS accounting uses the router name, not the real username.

In Figure 2-6, multiple remote users are connected to a Pipeline unit named Alameda.

Figure 2-6. ACE authentication for remote router users

EAS

NAS

WAN

Alameda

2-14 TAOS RADIUS Guide and Reference

Understanding RADIUS Authentication

Tunnel authentication

The following user profile specifies the system name of the Pipeline unit and the password for

ACE authentication:

Alameda User-Password="ACE"

Service-Type=Framed-User,

Framed-Protocol=PPP,

Framed-IP-Address=10.72.138.1,

Framed-IP-Netmask=255.255.255.0

A network user named John responds as follows to a password challenge:

From: hostname

0-Challenge: challenge

Enter next password:

newtoken.John

Tunnel authentication

ATMP and L2TP support tunnel authentication. When tunnel authentication is required, the

Foreign Agent or L2TP Access Controller (LAC) initiating a tunnel request must supply a password before the Home Agent or L2TP Network Server (LNS) allows registration of the tunnel.

Authenticating ATMP tunnels

The Home Agent ATMP profile specifies a password. If it is not null, Mobile Client profiles must supply the password to initiate a tunnel. If the Foreign Agent supplies the proper password when requesting a tunnel, the Home Agent returns a RegisterReply with a number that identifies the tunnel, and the Mobile Client’s tunnel is established. If the password does not match, the Home Agent rejects the tunnel, and the Foreign Agent logs a message and disconnects the Mobile Client.

The Mobile Client’s RADIUS profile must include the same value as the password specified in the local ATMP profile. In the following example, the password is tunnel-password

: mobile-client User-Password="my-password"

Service-Type=Framed-User,

Tunnel-Type=ATMP,

Tunnel-Server-Endpoint="3.3.3.3:8877",

Tunnel-Password="tunnel-password"

If the profile specifies Tunnel-Password and the RADIUS daemon does not encrypt the password, tunnel authentication will fail. If the Mobile Client’s profile uses the

Ascend-Home-Agent-Password (184) attribute to specify the password instead, the RADIUS daemon performs no encryption before sending the password to the Home Agent. This configuration might be required if you are using a RADIUS server that does not encrypt

Tunnel-Password.

Note:

Unless you are using a RADIUS daemon that does not support Tunnel-Password encryption (or encryption is not required), using the Tunnel-Password attribute is recommended, because it protects your system against local sniffers attempting to detect tunnel passwords.

TAOS RADIUS Guide and Reference 2-15

Understanding RADIUS Authentication

Tunnel authentication

Authenticating L2TP tunnels

L2TP tunnels can be authenticated using the same secret value in use at both ends of the connection (a shared secret). If Mobile Clients are authenticated by the LAC using RADIUS, the clients’ RADIUS profiles can specify a shared secret by means of the Tunnel-Password

(69) attribute.

Note:

Tunnel-Password must be encrypted by the RADIUS daemon, or tunnel authentication will fail.

The following profile specifies the Tunnel-Password attribute: l2tp-client User-Password="my-password"

Service-Type=Framed-User,

Framed-Protocol=PPP,

Framed-IP-Address=10.50.1.1,

Framed-IP-Netmask=255.255.0.0,

Tunnel-Type=L2TP,

Tunnel-Medium-Type=IP,

Tunnel-Server-Endpoint="lns-sys.domain.org",

Tunnel-Password="tunnel-secret"

If you prefer, you can remove the Tunnel-Password attribute from calling clients’ profiles and create a profile whose sole purpose is to authenticate L2TP tunnels. This configuration causes an extra RADIUS lookup the first time the tunnel is created, but it simplifies administration when shared secrets change. The RADIUS profile for tunnel authentication must specify the

L2TP peer’s name, a null password, and the Outbound-User setting for Service-Type. When an

L2TP tunnel is initially established, both the LNS and the LAC issue a RADIUS lookup based on the peer’s name. If the system finds a profile such as the following, it uses the

Tunnel-Password value to authenticate the tunnel: lns-sys.domain.org User-Password="", Service-Type=Outbound-User

Tunnel-Password="tunnel-secret"

Note:

The password in the pseudo-user profile must be null. Because this represents a security risk, the profile must set the Outbound-User setting.

Tunnel attribute sets with tags and preferences

The RADIUS Attributes for Tunnel Protocol Support Internet-Draft defines a set of RADIUS attributes designed to support transparent tunneling to dial-in networks, where a tunnel is created automatically without any explicit action by the user. To support this type of tunneling, the user’s profile specifies a primary attribute set, which specifies all of the values required to set up the tunnel, as well as additional attribute sets that can be used to establish a tunnel if the primary server is unavailable.

Note:

Use of tunneling attribute tags and preferences requires a RADIUS server that supports them. The NavisRadius product is one such server.

2-16 TAOS RADIUS Guide and Reference

Understanding RADIUS Authentication

Tunnel authentication

Overview of attribute sets and tags

A tag is a number from 1 to 31 that you can add to one or more of the RADIUS attributes listed

in “Tunnel attributes used with tags” on page 2-18. Attributes that share the same tag number

form an attribute set. Attribute sets in the same user profile are processed in numeric order (the set with tag 1 is processed before the set with tag 2, and so forth), unless the sets are reordered by means of the Tunnel-Preference attribute.

A tag value of 0 (zero) is considered untagged. Untagged attribute sets are processed before tagged attribute sets, unless a Tunnel-Preference setting specifies otherwise.

A tag is separated from an attribute-value pair by a colon. Following is a sample profile that specifies three attribute sets, tagged 1, 2, and 3: joe User-Password="murphy"

Tunnel-Type=L2TP : 1,

Tunnel-Server-Endpoint="1.1.1.1" : 1,

Tunnel-Password="loloaqic" : 1,

Tunnel-Type=L2TP : 3,

Tunnel-Server-Endpoint="3.3.3.3" : 3,

Tunnel-Password="i82qb4ip" : 3,

Tunnel-Type=L2F : 2,

Tunnel-Server-Endpoint="2.2.2.2" : 2,

Tunnel-Password="itsAsecret" : 2

This profile specifies that the NAS (the TAOS unit) first attempts to establish an L2TP tunnel to the LNS at 1.1.1.1. If that attempt fails, the system attempts to bring up an L2F tunnel to a server at 2.2.2.2. If that attempt also fails, the system tries an L2TP tunnel to 3.3.3.3.

In this release, a user profile can specify up to 32 tunnel attribute sets. However, for each attempt to initiate a tunnel, the system waits for a certain interval before retrying, and retries a certain number of times (for example, as configured in the L2-Tunnel-Global profile). So, in practice, the client’s PPP connection would typically time out long before 32 tunnel attempts were actually made.

Supported tunnel protocols

In this release, RADIUS attribute tags can be used for all supported tunnel protocols. The number of attribute sets used is limited for some protocols, as shown in the following table:

Tunnel protocol

L2TP

L2F

PPTP

ATMP

Attribute sets used

All specified attribute sets are used.

Only the attribute set with the highest priority is used. Priority is defined by the Tunnel-Preference (83) value or by tag order.

Only the two sets with the highest priority are used. (From the second attribute set, only the Tunnel-Server-Endpoint (67) value is used. Other values can be omitted.) Priority is defined by the

Tunnel-Preference (83) value or by tag order.

TAOS RADIUS Guide and Reference 2-17

Understanding RADIUS Authentication

Tunnel authentication

In the case of L2TP and L2F, you can use the DNS list attempt feature in conjunction with the tagging feature.

All the attribute sets in a profile must specify similar tunnel protocols, either all Layer 3 tunnels (such as ATMP) or layer 2 tunnels (such as L2TP or L2F). You can mix L2TP and

L2F, but not with ATMP. The following examples show two valid cases:

JL2 User-Password="example"

Tunnel-Type=L2TP :1,

Tunnel-Server-Endpoint=LNS-a.example.com :1,

Tunnel-Type=L2F :2,

Tunnel-Server-Endpoint=L2FGW.example.com :2

UL3 User-Password="example"

Tunnel-Type=ATMP :1,

Tunnel-Server-Endpoint=HA-a.example.com :1,

Tunnel-Server-Endpoint=HA-b.example.com :2,

Tunnel-Password=HApassword :1,

Tunnel-Private-Group-ID=MyHomeNet :1

Tunnel attributes used with tags

Following are the relevant tunnel attribute-value pairs:

Attribute Value

Tunnel-Type (64)

Tunnel-Medium-Type

(65)

Tunnel-Server-Endpoint

(67)

Tunneling protocol(s) to be used. In this release, only L2TP (3) and L2F (2) currently operate with full tunnel attribute and tag support.

Medium for establishing the tunnel. Currently, IP (1) is the only supported value.

IP address or hostname of the tunnel endpoint. If a DNS lookup returns several IP addresses, the system attempts to establish a tunnel to each address in turn.

Shared secret for authenticating the tunnel.

Tunnel-Password (69)

Tunnel-Preference (83) Numeric preference value for an attribute set. If more than one set of tunneling attributes is returned by the RADIUS server to the

TAOS unit, the Tunnel-Preference attribute can be included in a set to indicate its relative preference, with the lowest preference value designating the most preferred set.

If no Tunnel-Preference is included in any of the attribute sets, the sets will be processed in the order of their respective tag numbers.

Tunnel-Client-Auth-ID

(90)

If some but not all attribute sets contain a Tunnel-Preference value, the attribute sets without a Tunnel-Preference are designated as the least preferred sets.

Attribute sets with identical preferences are processed in random order.

Name of the Layer 2 Forwarding (L2F) tunnel initiator. This value is sent to the tunnel endpoint during tunnel authentication.

2-18 TAOS RADIUS Guide and Reference

Understanding RADIUS Authentication

Tunnel authentication

Attribute Value

Ascend-Tunnel-VRouter-

Name (31)

Name of a Virtual Router (VRouter) to use for establishing the

L2TP or L2F tunnel. The specified VRouter must exist on the

LAC.

Tunnel-Private-Group-ID

(81)

Name of the Connection profile that defines the link on which the

ATMP Home Agent transmits packets it receives from the Mobile

Client. This attribute is supported only for ATMP tunnels. The value is used only if the Home Agent is in gateway mode. See

Ascend-Home-Network-Name (185) for an alternate.

The TAOS unit currently ignores the following attributes if it receives them in a RADIUS response:

• Tunnel-Assignment-ID (82)

• Tunnel-Client-Endpoint (66)

Example of reordering sets using Tunnel-Preference

Following is a sample profile that specifies three attribute sets, tagged 1, 2, and 3, with a

Tunnel-Preference value that changes the order in which the tunnels are attempted: joe User-Password="murphy"

Tunnel-Type=L2TP : 1,

Tunnel-Server-Endpoint="1.1.1.1" : 1,

Tunnel-Password="loloaqic" : 1,

Tunnel-Type=L2TP : 3,

Tunnel-Server-Endpoint="3.3.3.3" : 3,

Tunnel-Password="i82qb4ip" : 3,

Tunnel-Type=L2F : 2,

Tunnel-Server-Endpoint="2.2.2.2" : 2,

Tunnel-Password="itsAsecret" : 2,

Tunnel-Preference=100 : 2,

Tunnel-Preference=200 : 1

With these preference values, the NAS makes the attribute set tagged 2 the primary attribute set, and first attempts to establish an L2F tunnel to a server at 2.2.2.2. It tries an L2TP tunnel to the LNS at 1.1.1.1 only if the initial tunnel attempt fails. If that attempt also fails, the system attempts to establish an L2TP tunnel to 3.3.3.3.

TAOS RADIUS Guide and Reference 2-19

Understanding RADIUS Authentication

Callback after authentication

Organizations use callback for a variety of reasons, such as saving on phone charges, but the primary use is for security. Using callback ensures that the connection is made with a known telephone number. Hanging up and calling back adds a level of certainty that the connection is with a trusted user, especially because the TAOS unit calls back the user immediately after authentication (or CLID pre-authentication).

Because the connection is initiated by the caller, the system does not need an explicit dial-out profile or a method of locating the dial-out profile (such as an IP route). All the necessary information for dialing back to the caller is present in the user profile. The following attributes must be specified for callback:

Attribute Value

Ascend-Callback (246) Enables/disables callback. Callback-No (0) is the default. The other value is Callback-Yes (1).

Ascend-Dial-Number

(227) telephone number the TAOS unit dials to reach the remote end.

Ascend-Send-Secret

(214)

Password sent to the remote end for authenticating a dial-out call.

If the RADIUS server does not support Ascend-Send-Secret, use

Ascend-Send-Passwd (232). For details, see “Shared secrets and secure exchanges” on page 2-5.

The following RADIUS profile specifies pre-authentication using CLID and callback to the remote end:

5105551234 User-Password="Ascend-CLID"

User-Name="clara-w95",

Service-Type=Framed-User,

Framed-Protocol=PPP,

Framed-IP-Address=10.10.11.12,

Ascend-Dial-Number="95551212",

Ascend-Send-Auth=Send-Auth-PAP,

Ascend-Send-Secret="test",

Ascend-Callback=Callback-Yes

The following RADIUS profile specifies PPP authentication and callback to the remote end: clara-w95 User-Password="test"

Service-Type=Framed-User,

Framed-Protocol=PPP,

Framed-IP-Address=10.10.11.12,

Ascend-Dial-Number="95551212",

Ascend-Send-Auth=Send-Auth-PAP,

Ascend-Send-Secret="test",

Ascend-Callback=Callback-Yes

2-20 TAOS RADIUS Guide and Reference

Understanding RADIUS Accounting

What is RADIUS accounting? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

What kinds of packets does RADIUS accounting use? . . . . . . . . . . . . . . . . . . . . . . . . . 3-2

Proxy RADIUS accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11

Sample accounting records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13

What is RADIUS accounting?

RADIUS accounting records information about WAN sessions only. Specifically, RADIUS logs information about three types of events:

• Start session. Denotes the beginning of a session with the TAOS unit. Information about this event appears in an accounting Start record.

• Stop session. Denotes the end of a session with the TAOS unit. Information about this event appears in an accounting Stop record.

• Failure-to-start session. Denotes that a login attempt has failed. Information about this event appears in an accounting Failure-to-start record.

When the TAOS unit recognizes one of these events, it sends an accounting request to

RADIUS. When the accounting server receives the request, it combines the information into a record and timestamps it. Each type of accounting record contains attributes associated with an event type, and can show the number of packets the TAOS unit transmitted and received, the protocol in use, the username and IP address of the client, and other information about the connection. All counters are session based, and reset to 0 (zero) when the session starts. At the end of the session, the interfaces are reported as Down and show 0 (zero).

You can use RADIUS accounting to perform the following tasks:

• Gather billing information, including who called, how long the session lasted, and how much traffic occurred during the session.

• Troubleshoot RADIUS and TAOS operations. Accounting records can contain information about how many login failures occurred, and can describe the characteristics of the failed attempts.

TAOS RADIUS Guide and Reference 3-1

Understanding RADIUS Accounting

What kinds of packets does RADIUS accounting use?

RADIUS accounting uses two kinds of packets: Accounting Start and Accounting Stop.

Accounting Start packets

Accounting Start packets signal a Start session event. When a terminal-server call passes authentication, or the user logs in for a routing session, the TAOS unit sends an Accounting

Start packet to the RADIUS accounting server. The packet describes the type of session in use and the name of the user opening the session.

The TAOS unit does not send an Accounting Start packet if a call fails authentication or otherwise fails to log in. In some cases, a session begins with a user login and then authentication follows, such as when a terminal-server user chooses PPP or SLIP after login. If

Service-Type is set to Login-User, or if Service-Type is unspecified, the TAOS unit sends an

Accounting Start packet after login. Information from an Accounting Start packet appears in a

Start record.

Accounting Stop packets

Accounting Stop packets signal a Stop session or Failure-to-start session event. By default, the

TAOS unit always sends an Accounting Stop packet at the end of a session, including cases in which a user fails authentication. Information from an Accounting Stop packet appears in a

Stop record or Failure-to-start record.

RADIUS attributes in Start records

Table 3-1 lists the RADIUS attributes that can appear in a Start record.

Table 3-1. RADIUS attributes in Start records

Attribute

Acct-Authentic (45)

Acct-Delay-Time (41)

Description

Indicates the method the TAOS unit used to authenticate an incoming call:

• RADIUS (1) indicates that RADIUS authenticated the incoming call.

• Local (2) indicates that the TAOS unit used a local

Connection profile, TACACS profile, or TACACS+ profile, or that the TAOS unit accepted the call without authentication.

Indicates the number of seconds the TAOS unit has been trying to send the Accounting packet. In an Accounting

Start packet, this value is 0 (zero).

3-2 TAOS RADIUS Guide and Reference

Understanding RADIUS Accounting

What kinds of packets does RADIUS accounting use?

Table 3-1. RADIUS attributes in Start records (continued)

Attribute Description

Acct-Session-Id (44)

Acct-Status-Type (40)

Consists of a unique numeric string identified with the routing or terminal-server session reported in the Accounting packet. The string is a random number. RADIUS correlates the Accounting Start packet and Accounting Stop packet with Acct-Session-Id. Its value can range from 1 to

2,137,383,647.

Requests that have Acct-Status-Type set to Start are

Accounting Start packets. The information in these packets appears in Start records. Requests that have Acct-Status-Type set to Stop are Accounting Stop packets. The information in these packets appears in Stop or Failure-to-start records.

Ascend-Calling-Subaddress

(107)

Ascend-Dial-Number (227)

Specifies the ISDN subaddress that the TAOS unit sends to

RADIUS during CLID authentication.

Indicates the telephone number of the device that originated the connection.

Ascend-Modem-PortNo (120) Specifies the number of the port on the specified slot that terminates the call.

Ascend-Modem-ShelfNo

(122)

Specifies the number of the shelf that terminates the call.

Ascend-Modem-SlotNo (121) Specifies the number of the slot on the specified shelf that terminates the call.

Ascend-NAS-Port-Format

(13)

Specifies the format of the NAS-Port attribute.

Ascend-Owner-IP-Addr (86)

Ascend-Redirect-Number

(93)

Ascend-Session-Svr-Key

(151)

Specifies the IP address of the owner of the Multilink bundle.

Indicates the redirected number extracted from the Redirect Number Information Element (IE) in an ISDN frame.

Identifies the user session in which a client sends a disconnect or filter-change request to the RADIUS server.

Ascend-User-Acct-Base (142) Indicates whether the numeric base of the RADIUS

Acct-Session-ID attribute is 10 or 16.

Ascend-User-Acct-Host (139) Indicates the IP address of the RADIUS server to use for the link.

Ascend-User-Acct-Key (141) Indicates the RADIUS client password.

TAOS RADIUS Guide and Reference 3-3

Understanding RADIUS Accounting

What kinds of packets does RADIUS accounting use?

Table 3-1. RADIUS attributes in Start records (continued)

Attribute Description

Ascend-User-Acct-Port (140) Indicates a destination UDP port number for the connection.

Ascend-User-Acct-Time

(143)

Indicates the number of seconds the TAOS unit waits for a response to a RADIUS accounting request.

Ascend-User-Acct-Type

(138)

Called-Station-Id (30)

Indicates the RADIUS accounting server(s) to use for the connection.

Indicates the called-party number, which is the telephone number the user dials to connect to the TAOS unit.

Calling-Station-Id (31)

Class (25)

Framed-IP-Address (8)

Framed-Protocol (7)

NAS-IP-Address (4)

NAS-Port (5)

NAS-Port-Type (61)

User-Name (1)

Indicates the calling-party number, which is the telephone number of the user that has connected to the unit.

Enables access providers to classify their user sessions.

The default value for the Class attribute is null.

Indicates the IP address of the user starting the session. The default value is 0.0.0.0.

Indicates the kind of protocol the connection uses.

Indicates the IP address of the TAOS unit.

Indicates the port on which the TAOS unit received the call.

Specifies the type of service in use for the established session:

• NAS_Port_Type_Async (0) indicates a call the TAOS unit routes to a digital modem.

• NAS_Port_Type_Sync (1) indicates a synchronous

ISDN connection.

Indicates the name of the user starting the session.

3-4 TAOS RADIUS Guide and Reference

Understanding RADIUS Accounting

What kinds of packets does RADIUS accounting use?

RADIUS attributes in Stop records

Table 3-2 lists the RADIUS attributes that can appear in a Stop record.

Table 3-2. RADIUS attributes in Stop records

Attribute

Acct-Authentic (45)

Acct-Delay-Time (41)

Acct-Input-Octets (42)

Acct-Input-Packets (47)

Acct-Link-Count (51)

Acct-Multi-Session-Id (50)

Description Conditions for inclusion

Indicates the method the TAOS unit used to authenticate an incoming call:

• RADIUS (1) indicates that

RADIUS authenticated the incoming call.

• Local (2) indicates that the TAOS unit used a local Connection profile,

TACACS profile, or TACACS+ profile, or that the TAOS unit accepted the call without authentication.

Session must be authenticated.

Indicates the number of seconds between the time an event occurred and the time the TAOS unit sent the packet. If

RADIUS does not acknowledge the packet, the TAOS unit resends it. The value of Acct-Delay-Time changes to reflect the proper event time.

None.

Indicates the number of octets the TAOS unit received during the session. The value reflects only the data delivered by

PPP or other encapsulation. It does not include the header or other protocol-dependent components of the packet.

Session must be authenticated.

An asynchronous connection must be in use. That is, the data must be unframed.

Indicates the number of packets the

TAOS unit received during the session.

The packets are counted before the encapsulation is removed. The attribute’s value does not include maintenance packets, such as keepalive or management packets.

Session must be authenticated.

A framed protocol must be in use.

Indicates the highest number of channels connected.

Session must be authenticated.

Reports the ID number of the Multilink bundle when the session closes.

Session must be authenticated.

TAOS RADIUS Guide and Reference 3-5

Understanding RADIUS Accounting

What kinds of packets does RADIUS accounting use?

Table 3-2. RADIUS attributes in Stop records (continued)

Attribute Description Conditions for inclusion

Acct-Output-Octets (43)

Acct-Output-Packets (48)

Acct-Session-Id (44)

Acct-Session-Time (46)

Indicates the number of octets the TAOS unit sent during the session. The value reflects only the data delivered by PPP or other encapsulation. It does not include the header or other protocol-dependent components of the packet.

Session must be authenticated.

An asynchronous connection must be in use. That is, the data must be unframed.

Indicates the number of packets the

TAOS unit sent during the session. The packets are counted before the encapsulation is removed. The attribute’s value does not include maintenance packets, such as keepalive or management packets.

Session must be authenticated.

A framed protocol must be in use.

Consists of a unique numeric string identified with the routing or terminal-server session reported in the Accounting packet. The string is a random number of up to 7 digits. RADIUS correlates the

Accounting Start packet and Accounting

Stop packet with Acct-Session-Id. Its value can range from 1 to 2,137,383,647.

None.

Indicates the number of seconds the session has been logged in.

Session must be authenticated.

Acct-Status-Type (40)

Ascend-Calling-Subaddress

(107)

Requests that have Acct-Status-Type set to Start are Accounting Start packets.

The information in these packets appears in Start records.

Requests that have Acct-Status-Type set to Stop are Accounting Stop packets.

The information in these packets appears in Stop or Failure-to-start records.

None.

Specifies the ISDN subaddress that the

TAOS unit sends to RADIUS during

CLID authentication.

None.

Ascend-Connect-Progress (196) Indicates the state of the connection before it disconnects.

Ascend-Data-Rate (197) Indicates the rate of data received on the connection in bits per second.

None.

Ascend-Dial-Number (227) Indicates the telephone number of the device that originated the connection.

None.

3-6 TAOS RADIUS Guide and Reference

Understanding RADIUS Accounting

What kinds of packets does RADIUS accounting use?

Table 3-2. RADIUS attributes in Stop records (continued)

Attribute Description Conditions for inclusion

Ascend-Disconnect-Cause (195) Indicates the reason a connection was taken offline.

Ascend-Event-Type (150)

None.

Indicates a cold-start notification, informing the accounting server that the

TAOS unit has started up.

For a cold-start notification, the

TAOS unit sends values for

NAS-IP-Address and

Ascend-Event-Type in an

Ascend-Access-Event-Request packet (code 33). The RADIUS accounting server must send an

Ascend-Access-Event-Response packet (code 34), with the correct identifier, to the TAOS unit.

Ascend-First-Dest (189)

Ascend-Home-Agent-IP-Addr

(183)

Records the destination IP address of the first packet the TAOS unit received on a connection after authentication.

Session must be authenticated.

Indicates the IP address of the Home

Agent associated with the Mobile Client.

Session was authenticated and encapsulated by means of Ascend

Tunnel Management Protocol

(ATMP).

Ascend-Home-Agent-UDP-Port

(186)

Indicates the UDP port number to use when the Foreign Agent sends ATMP packets to the Home Agent.

Ascend-Home-Network-Name

(185)—Gateway mode only

Indicates the name of the Connection profile through which the Home Agent sends all packets it receives from the

Mobile Client during ATMP operation.

Ascend-Modem-PortNo (120) Specifies the number of the port on the specified slot that terminates the call.

Ascend-Modem-ShelfNo (122) Specifies the number of the shelf that terminates the call.

Ascend-Modem-SlotNo (121) Specifies the number of the slot on the specified shelf that terminates the call.

Session was authenticated and encapsulated by means of Ascend

Tunnel Management Protocol

(ATMP).

Session was authenticated and encapsulated by means of Ascend

Tunnel Management Protocol

(ATMP).

None.

Ascend-Multilink-ID (187) Reports the ID number of the Multilink bundle when the session closes.

Ascend-Num-In-Multilink (188) Records the number of sessions remaining in a Multilink bundle when the session closes.

Session must be authenticated.

TAOS RADIUS Guide and Reference 3-7

Understanding RADIUS Accounting

What kinds of packets does RADIUS accounting use?

Table 3-2. RADIUS attributes in Stop records (continued)

Attribute Description Conditions for inclusion

Ascend-Number-Sessions (202) Indicates the number of active user sessions of a given class (as specified by the

Class attribute). In the case of multichannel calls, such as MP+ calls, each separate connection counts as a session.

The TAOS unit sends

Ascend-Number-Sessions in

Ascend-Access-Event-Request packets. Only RADIUS daemons you customize to recognize packet code 33 respond to these request packets.

Ascend-Owner-IP-Addr (86) Specifies the IP address of the owner of the Multilink bundle.

Session must be authenticated.

Ascend-Pre-Input-Octets (190) Reports the number of octets the TAOS unit received before authentication. The value reflects only the data delivered by

PPP or other encapsulation. It does not include the header or other protocol-dependent components of the packet.

Session must be authenticated.

An asynchronous connection must be in use. That is, the data must be unframed.

Ascend-Pre-Input-Packets (192) Reports the number of packets the

TAOS unit received before authentication. The packets are counted before the encapsulation is removed. The attribute’s value does not include maintenance packets, such as keepalive or management packets.

Session must be authenticated.

Ascend-Pre-Output-Octets (191) Reports the number of octets the TAOS unit sent before authentication. The value reflects only the data delivered by

PPP or other encapsulation. It does not include the header or other protocol-dependent components of the packet.

Session must be authenticated.

An asynchronous connection must be in use. That is, the data must be unframed.

Ascend-Pre-Output-Packets

(193)

Reports the number of packets the

TAOS unit sent before authentication.

The packets are counted before the encapsulation is removed. The attribute’s value does not include maintenance packets, such as keepalive or management packets.

Session must be authenticated.

Ascend-PreSession-Time (198)

Ascend-Redirect-Number (93)

Indicates the number of seconds from the time a call connected to the time it completed authentication.

Indicates the redirected number extracted from the Redirect Number

Information Element (IE) in an ISDN frame.

None.

3-8 TAOS RADIUS Guide and Reference

Understanding RADIUS Accounting

What kinds of packets does RADIUS accounting use?

Table 3-2. RADIUS attributes in Stop records (continued)

Attribute

Ascend-User-Acct-Base (142)

Ascend-User-Acct-Host (139)

Ascend-User-Acct-Key (141)

Ascend-User-Acct-Port (140)

Ascend-User-Acct-Time (143)

Ascend-User-Acct-Type (138)

Ascend-Xmit-Rate (255)

Called-Station-Id (30)

Calling-Station-Id (31)

Class (25)

Framed-IP-Address (8)

Framed-Protocol (7)

NAS-IP-Address (4)

Description Conditions for inclusion

Indicates whether the numeric base of the RADIUS Acct-Session-ID attribute is 10 or 16.

None.

Indicates the IP address of the RADIUS server to use for the connection.

None.

Indicates the RADIUS client password.

None.

Indicates a destination UDP port number for the connection.

None.

Indicates the number of seconds the

TAOS unit waits for a response to a

RADIUS accounting request.

Indicates the RADIUS accounting server(s) to use for the connection.

None.

Indicates the rate of data transmitted on the connection in bits per second. For

ISDN calls, Ascend-Xmit-Rate indicates the transmit data rate. For analog calls, it indicates the modem baud rate at the time of the initial connection.

None.

Indicates the called-party number, which is the telephone number the user dials to connect to the TAOS unit.

None.

Indicates the calling-party number, which is the telephone number of the user that has connected to the unit.

None.

Enables access providers to classify their user sessions. The default value for the

Class attribute is null.

None.

Indicates the IP address of the user starting the session. The default value is

0.0.0.0.

None.

Indicates the kind of protocol the connection uses.

None.

Indicates the IP address of the TAOS unit. This attribute does not appear in an

Accounting-Stop packet for a Failure-start-session event.

None.

TAOS RADIUS Guide and Reference 3-9

Understanding RADIUS Accounting

What kinds of packets does RADIUS accounting use?

Table 3-2. RADIUS attributes in Stop records (continued)

Attribute

NAS-Port (5)

NAS-Port-Type (61)

Tunnel-Assignment-ID (82)

Tunnel-Client-Endpoint (66)

Tunnel-Server-Auth-ID (91)

Tunnel-Type (64)

User-Name (1)

Description Conditions for inclusion

Indicates the port on which the TAOS unit received the call. NAS-Port does not appear in an Accounting-Stop packet for a Failure-start-session event.

None.

Specifies the type of service in use for the established session:

NAS_Port_Type_Async (0) indicates a call the TAOS unit routes to a digital modem.

NAS_Port_Type_Sync (1) indicates a synchronous ISDN connection.

None.

Specifies a string that enables the system to group user sessions into different

Layer 2 Tunneling Protocol (L2TP) tunnels.

None.

Specifies a string assigned by RADIUS that specifies the name for the unit placing the call.

None.

Specifies the name used by the L2TP tunnel endpoint during authentication.

Specifies whether a session used the

ATMP tunneling protocol.

Indicates the name of the user starting the session.

None.

RADIUS attributes in Failure-to-start records

Failure-to-start records can contain only a subset of the information found in Stop records. The following attributes can appear:

Acct-Delay-Time (41)

Acct-Session-Id (44)

Acct-Status-Type (40)

Ascend-Connect-Progress (196)

Ascend-Data-Rate (197)

Ascend-Disconnect-Cause (195)

Ascend-PreSession-Time (198)

NAS-IP-Address (4)

For a brief description of each of these attributes, see Table 3-2 on page 3-5.

3-10 TAOS RADIUS Guide and Reference

Understanding RADIUS Accounting

Proxy RADIUS accounting

The master shelf controller keeps track of all accounting Start records sent by host cards. If the shelf controller determines that a host card has gone down for any reason, it acts as proxy for the card and sends the accounting server a fail-safe Stop record for each of the card’s open sessions. The host card might be brought down administratively, might be removed from the system, or might go down due to an error condition.

How proxy RADIUS accounting works

In general, when RADIUS accounting is in use, the situation shown in Figure 3-1 occurs.

Figure 3-1. Normal RADIUS accounting (no proxy necessary)

Call comes in...

Shelf controller Host card Acct-Server

Call clears...

Shelf controller Host card Acct-Server

Start

Shelf saves

AFS.

Start

Start ACK

Stop

Shelf deletes AFS.

Stop

Stop ACK

When a call comes in, the host card first sends a Start record to the shelf controller, which stores it as an Accounting Fail-Safe (AFS) record. The host card then sends one or more Start records to the RADIUS accounting server, repeating until it receives an ACK from the server.

Similarly, when the call clears, the host card sends a Stop record to the shelf controller, which causes it to delete the AFS record for that session. The host card then sends the accounting server Stop records until it receives an ACK from the server.

When RADIUS accounting is in use and the host card goes down for any reason, proxy accounting occurs, as shown in Figure 3-2.

Figure 3-2. Proxy accounting (host card goes down)

Call comes in...

Shelf controller Host card Acct-Server

Host card goes down...

Shelf controller Acct-Server

Start

Shelf saves

AFS.

Start

Start ACK

Stop

Stop ACK

Shelf deletes

AFS.

In this case, when the shelf controller notes that the host card is down, it uses its own information about the host card and the stored AFS record to send a Stop record directly to the

RADIUS accounting server, repeating until it receives a Stop ACK from the server. The shelf controller then deletes the AFS record for that session. However, if the accounting server is accessible only by means of the host card that goes down, Stop records cannot be delivered successfully.

TAOS RADIUS Guide and Reference 3-11

Understanding RADIUS Accounting

Proxy RADIUS accounting

Contents of the Stop record sent by proxy

The AFS Stop record does not contain all the information that appears in a record sent by a host card. In particular, it does not contain the input/output octet count fields or any other dynamic information related to the session. In Table 3-3, Yes indicates that the attribute is included in the Stop record. No indicates that the attribute is not included in the record or is set to null.

Table 3-3. RADIUS attributes included in proxy Stop records

Attribute in regular Stop record

Acct-Authentic

Acct-Delay-Time

Acct-Input-Octets

Acct-Input-Packets

Acct-Multi-Session-Id

Acct-Output-Octets

Acct-Output-Packets

Acct-Session-Id

Acct-Status-Type

Acct-Session-Time

Ascend-Connect-Progress

Ascend-Data-Rate

Ascend-Disconnect-Cause

Ascend-First-Dest

Ascend-Home-Agent-IP-Addr

Ascend-Home-Agent-UDP-Port

Ascend-Multilink-ID

Ascend-Num-In-Multilink

Ascend-Owner-IP-Addr

Ascend-Pre-Input-Octets

Ascend-Pre-Input-Packets

In proxy Stop record

Yes

Yes. (The session time is accurate to within a few seconds.)

Yes

Yes. (The Disconnect reason is always 210, slot card down.)

3-12 TAOS RADIUS Guide and Reference

Understanding RADIUS Accounting

Sample accounting records

Table 3-3. RADIUS attributes included in proxy Stop records (continued)

Attribute in regular Stop record

Ascend-Pre-Output-Octets

Ascend-Pre-Output-Packets

Ascend-PreSession-Time

Calling-Station-Id

Class

Framed-IP-Address

Framed-Protocol

NAS-IP-Address

NAS-Port

NAS-Port-Type

Tunnel-Type

User-Name

In proxy Stop record

Yes

Sample accounting records

This section provides sample Start and Stop records for the following configurations:

• A Pipeline unit dialing into a MAX TNT unit

• A modem calling into a MAX™ unit

• An immediate-modem dialout connection

The section also illustrates a Stop record sent by proxy.

TAOS RADIUS Guide and Reference 3-13

Understanding RADIUS Accounting

Sample accounting records

Pipeline unit dialing into a MAX TNT unit

When a Pipeline unit dials into a MAX TNT unit, the Start record might look like the following:

Tue Feb 18 12:00:41 1999 /* Session startup time */

User-Name="ht-net" /* The name of the Pipeline unit */

NAS-IP-Address=206.65.212.46 /* The IP address of the MAX TNT unit*/

NAS-Port=1057 /* Call on channel 2, line 2, slot 2, shelf 1 */

Acct-Status-Type=Start /* Start record. */

Acct-Delay-Time=0 /* Always zero for a Start record */

Acct-Session-Id="1234567" /* Session identification number */

Acct-Authentic=RADIUS /* RADIUS authentication in use */

Called-Station-Id="3142" /* Called-party number */

Framed-Protocol=PPP /* PPP call */

Framed-IP-Address=11.0.0.1 /* IP address of the Pipeline unit */

The Stop record might look like the following:

Tue Feb 18 12:02:48 1999 /* Session hangup time */

User-Name="ht-net" /* The name of the Pipeline unit */

NAS-IP-Address=206.65.212.46 /* The IP address of the MAX TNT unit*/

NAS-Port=1057 /* Call on channel 2, line 2, slot 2, shelf 1 */

Ascend-Owner-IP-Addr=206.65.212.46 /* Owner of Multilink bundle */

Acct-Status-Type=Stop /* Stop record */

Acct-Delay-Time=18 /* Unit tried to send packet for 18 seconds */

Acct-Session-Id="1234567" /* Session identification number */

Acct-Authentic=RADIUS /* RADIUS authentication used */

Acct-Session-Time=128 /* Number of seconds in session */

Acct-Input-Octets=2421 /* Bytes received from the Pipeline unit */

Acct-Output-Octets=1517 /* Bytes sent to the Pipeline unit */

Acct-Input-Packets=79 /* Packets received from the Pipeline unit */

Acct-Output-Packets=47 /* Packets sent to the Pipeline unit */

Ascend-Disconnect-Cause=100 /* Session timeout */

Ascend-Connect-Progress=60 /* LAN session up */

Ascend-Data-Rate=31200 /* Receive data rate in bits per second */

Ascend-Xmit-Rate=48000 /* Transmit data rate in bits per seconds */

Ascend-PreSession-Time=0 /*Secs from connection to authentication*/

Ascend-Pre-Input-Octets=174 /* Input octets pre-authentication */

Ascend-Pre-Output-Octets=204 /* Output octets pre-authentication */

Ascend-Pre-Input-Packets=7 /* Input packets pre-authentication */

Ascend-Pre-Output-Packets=8 /* Output packets pre-authentication */

Ascend-First-Dest=10.81.44.111 /* Dest IP address of 1st packet */

Ascend-Multilink-ID=64 /* ID number of Multilink bundle */.

Ascend-Num-In-Multilink=0 /* # of sessions in Multilink bundle */

Called-Station-Id="3142" /* Called-party number */

Framed-Protocol=PPP /* PPP call */

Framed-IP-Address=11.0.0.1 /* IP address of the Pipeline unit */

3-14 TAOS RADIUS Guide and Reference

Understanding RADIUS Accounting

Sample accounting records

Modem calling into a MAX unit

If a modem dials into a MAX unit to reach its terminal server, the call can only be an unframed call. It cannot be a PPP, MP, or MP+ call. Therefore, the attributes Framed-Protocol and

Framed-IP-Address do not appear in the sample records, and Login-Service is set to

Unframed-User.

A Start record might look like the following:

Tue Feb 18 12:00:00 1999 /* Session startup time */

User-Name="Berkeley" /* The name of the modem caller */

NAS-IP-Address=200.65.212.46 /* The IP address of the MAX unit */

NAS-Port=1057 /* Call on channel 2, line 2, slot 2, shelf 1 */

Acct-Status-Type=Start /* Start record. */

Acct-Delay-Time=0 /* Always zero for a Start record */

Acct-Session-Id="3456789" /* Session identification number */

Acct-Authentic=RADIUS /* RADIUS authentication in use */

Called-Station-Id="3143" /* Called-party number */

The Stop record might look like the following:

Tue Feb 18 12:03:00 1999 /* Session hangup time */

User-Name="Berkeley" /* The name of the modem caller */

NAS-IP-Address=200.65.212.46 /* The IP address of the MAX unit */

NAS-Port=1057 /* Call on channel 2, line 2, slot 2, shelf 1 */

Ascend-Owner-IP-Addr=206.65.212.46 /* Owner of Multilink bundle */

Acct-Status-Type=Stop /* Stop record */

Acct-Delay-Time=18 /* Unit tried to send packet for 18 seconds */

Acct-Session-Id="3456789" /* Session identification number */

Acct-Authentic=RADIUS /* RADIUS authentication used */

Acct-Session-Time=128 /* Number of seconds in session */

Acct-Input-Octets=2421 /* Bytes received from the Pipeline unit*/