Authentication

Authentication validates a user name and password combination when a user attempts to log in.

When a user attempts to log in through the console, Telnet, SSH, SCP, or FTP, the 7705 SAR client sends an access request to a RADIUS, TACACS+, or local database.

Transactions between the client and a RADIUS server are authenticated through the use of a shared secret. The secret is never transmitted over the network. User passwords are sent encrypted between the client and RADIUS server, which prevents someone snooping on an insecure network to learn password information.

If the RADIUS server does not respond within a specified time, the router issues the access request to the next configured servers. Each RADIUS server must be configured identically to guarantee consistent results. Up to five RADIUS servers can be configured.

If a server is unreachable, it will not be used again by the RADIUS application until 30 seconds have elapsed, to give the server time to recover from its unreachable state. After 30 seconds, the unreachable server becomes available again for the RADIUS application.

If, within the 30 seconds, the RADIUS server receives a valid response to a previously sent RADIUS packet on that unreachable server, the server immediately becomes available again.

If any RADIUS server rejects the authentication request, it sends an access reject message to the router. In this case, no access request is issued to any other RADIUS servers. However, if other authentication methods such as TACACS+ and/or local are configured, then these methods are attempted. If no other authentication methods are configured, or all methods reject the authentication request, then access is denied.

The user login is successful when the RADIUS server accepts the authentication request and responds to the router with an access accept message.

Implementing authentication without authorization for the 7705 SAR does not require the configuration of VSAs (Vendor Specific Attributes) on the RADIUS server. However, users, user access permissions, and command authorization profiles must be configured on each router.

Any combination of these authentication methods can be configured to control network access from a 7705 SAR router:

Authorization

The 7705 SAR supports local, RADIUS, and TACACS+ authorization to control the actions of specific users by applying a profile based on user name and password configurations once network access is granted. The profiles are configured locally as well as on the RADIUS server as VSAs. See Vendor-Specific Attributes (VSAs).

Once a user has been authenticated using RADIUS (or another method), the 7705 SAR router can be configured to perform authorization. The RADIUS server can be used to:

Profiles consist of a suite of commands that the user is allowed or not allowed to execute. When a user issues a command, the authorization server looks at the command and the user information and compares it with the commands in the profile. If the user is authorized to issue the command, the command is executed. If the user is not authorized to issue the command, then the command is not executed.

Profiles must be created on each 7705 SAR router and should be identical for consistent results. If the profile is not present, then access is denied.

Table 2 displays the following scenarios.

When authorization is configured and profiles are downloaded to the router from the RADIUS server, the profiles are considered temporary configurations and are not saved when the user session terminates.

When using authorization, maintaining a user database on the router is not required. User names can be configured on the RADIUS server. User names and their associated passwords are temporary and are not saved in the configuration database when the user session terminates.

Accounting

Accounting tracks user activity to a specific host. The 7705 SAR supports RADIUS and TACACS+ accounting.

When a Server Does Not Respond

A trap is issued if a RADIUS server is unresponsive. An alarm is raised if RADIUS is enabled with at least one RADIUS server and no response is received to either accounting or user access requests from any server.

Periodic checks to determine if the primary server is responsive again are performed. If a server is down, it will not be contacted for 5 minutes. If a login is attempted after 5 minutes, then the server is contacted again. If a server has the health check feature enabled and is unresponsive, the server’s status is checked every 30 seconds. Health check is enabled by default. When a service response is restored from at least one server, the alarm condition is cleared. Alarms are raised and cleared on the Alcatel-Lucent Fault Manager or other third party fault management servers.

The servers are accessed in order from lowest to highest specified index (from 1 to 5) for authentication requests until a response from a server is received. A higher indexed server is only queried if no response is received from a lower indexed server. If a response from the server is received, no other server is queried.

Access Request Flow

In Figure 2, the authentication process is defined in the config>system>security> password context. The authentication order is determined by specifying the sequence in which password authentication is attempted among RADIUS, TACACS+, and local servers.

This example uses the authentication order of RADIUS, then TACACS+, and finally, local. An access request is sent to RADIUS server 1. One of two scenarios can occur. If there is no response from the server, the request is passed to the next RADIUS server with the next lowest index (RADIUS server 2) and so on, until the last RADIUS server is attempted (RADIUS server 5). If server 5 does not respond, the request is passed to the TACACS+ server 1. If there is no response from that server, the request is passed to the next TACACS+ server with the next lowest index (TACACS+ server 2) and so on.

If a request is sent to an active RADIUS server and the user name and password are not recognized, access is denied and passed on to the next authentication option, in this case, the TACACS+ server. The process continues until the request is either accepted, denied, or each server is queried. Finally, if the request is denied by the active TACACS+ server, the local parameters are checked for user name and password verification. This is the last chance for the access request to be accepted.

Figure 2:  Security Flow 

Sample User (VSA) Configuration

The following example displays a user-specific VSA configuration. This configuration shows attributes for users named ruser1 and ruser2.

The following example shows that user ruser1 is granted console access. ruser1’s home directory is in compact flash slot 3 and is limited to the home directory. The default action permits all packets when matching conditions are not met. The timetra-cmd parameters allow the user to use the tools;telnet;configure system security commands. Matching strings specified in the timetra-action command are denied for this user.

The user ruser2 is granted FTP access. The default action denies all packets when matching conditions are not met. The timetra-cmd parameters allow the user to use the configure, show, and debug commands. Matching strings specified in the timetra-action command are permitted for this user.

Secure Shell (SSH)

Secure Shell Version 1 (SSH1) is a protocol that provides a secure, encrypted Telnet-like connection to a router. A connection is always initiated by the client (the user). Authentication takes place by one of the configured authentication methods (local, RADIUS, or TACACS+). With authentication and encryption, SSH allows for a secure connection over an insecure network.

The 7705 SAR allows you to configure SSH1 or Secure Shell Version 2 (SSH2). SSH1 and SSH2 are different protocols and encrypt at different parts of the packets. SSH1 uses the server as well as host keys to authenticate systems, whereas SSH2 only uses host keys. SSH2 does not use the same networking implementation that SSH1 does and is considered a more secure, efficient, and portable version of SSH. Rather than validating identities via passwords, SSH2 can also use public key encryption to authenticate remote hosts. For example, if you were to connect to a remote host also running SSH2, the secure shell would use this system to verify that the remote system is the host and not a computer set up to imitate it.

SSH runs on top of a transport layer (like TCP or IP), and provides authentication and encryption capabilities. SSH supports remote login to another computer over a network, remote command execution, and file relocation from one host to another.

The 7705 SAR has a global SSH server process to support inbound SSH and SCP sessions initiated by external SSH or SCP client applications. The SSH server supports SSH1. Note that this server process is separate from the SSH and SCP client commands on the 7705 SAR, which initiate outbound SSH and SCP sessions.

Inbound SSH sessions are counted as inbound Telnet sessions for the purposes of the maximum number of inbound sessions specified by Login Control. Inbound SCP sessions are counted as inbound FTP sessions by Login Control.

When the SSH server is enabled, an SSH security key is generated. The key is only valid until either the node is restarted or the SSH server is stopped and restarted. The key size is non-configurable and set at 1024 bits. When the server is enabled, both inbound SSH and SCP sessions will be accepted provided the session is properly authenticated.

When the global SSH server process is disabled, no inbound SSH or SCP sessions will be accepted.

When using SCP to copy files from an external device to the file system, the 7705 SAR SCP server will accept either forward slash (“/”) or backslash (“\”) characters to delimit directory and/or filenames. Similarly, the 7705 SAR SCP client application can use either slash or backslash characters, but not all SCP clients treat backslash characters as equivalent to slash characters. In particular, UNIX systems will often interpret the backslash character as an “escape” character, which does not get transmitted to the 7705 SAR SCP server. For example, a destination directory specified as “cf3:\dir1\file1” will be transmitted to the 7705 SAR SCP server as “cf3:dir1file1”, where the backslash escape characters are stripped by the SCP client system before transmission. On systems where the client treats the backslash like an “escape” character, a double backslash “\\” or the forward slash “/” can typically be used to properly delimit directories and the filename.

The 7705 SAR support for SSH and SCP is the same for both IPv4 and IPv6 addressing, including support for:

CSM Filters and CSM Security

IP forwarding supports CSM filters that are applied to IP packets extracted to the control plane. CSM filters are used to protect the control plane from DoS attacks, unauthorized access to the node, and similar security breaches.

IP filters scan all traffic and take the appropriate (configured) action against matching packets. Packets that are not filtered by the IP filters and are destined for the 7705 SAR are scanned by the configured CSM filter.

For information on IP filters, refer to the 7705 SAR OS Router Configuration Guide.

Note: Although the Control and Switching module on the 7705 SAR is called a CSM, the CSM filters are referred to as CPM filters in the CLI in order to maintain consistency with other SR routers.

Both IPv4 and IPv6 CSM filters are supported.

IPv4 CSM filters drop or accept incoming packets based on the following match criteria:

IPv6 CSM filters drop or accept incoming packets based on the following match criteria:

To avoid DoS-like attacks overwhelming the control plane while ensuring that critical control traffic such as signaling is always serviced in a timely manner, the 7705 SAR has three queues (High, Low, and Ftp) for handling packets addressed to the CSM:

These queues are fixed use (each queue handles a certain type of traffic, which is not user-configurable) and fixed configuration (each queue is configured for particular rates and buffering capacity and is not user-configurable).

Exponential Login Backoff

A malicious user can gain CLI access via a dictionary attack: using a script to try “admin” with any password.

The 7705 SAR increases the delay between login attempts exponentially to mitigate attacks. It is applied to the console login. SSH and Telnet sessions terminate after four attempts.

Encryption

Data Encryption Standard (DES) and Triple DES (3DES) are supported for encryption.

802.1x Network Access Control

The 7705 SAR supports network access control of client devices (PCs, STBs, and so on) on an Ethernet network using the IEEE 802.1x standard. 802.1x is known as Extensible Authentication Protocol (EAP) over a LAN network or EAPOL.

Refer to the 7705 SAR OS Interface Configuration Guide for more information about IEEE 802.1x.

Reference Sources

For information on supported IEEE standards, IETF drafts and standards as well as standard and proprietary MIBs, refer to Standards and Protocol Support.