Authentication and Authorization

Authentication is the process of confirming the alleged identity of a service requester. Authorization, a process performed after authentication, determines the access or privilege level granted to an authenticated requester.

Local Authentication and Authorization

This section describes user authentication and authorization performed locally by a Oracle SBC that has either the Admin Security or JITC feature set provisioned.

The SBC provides two default factory accounts:

  • user
  • admin

Each of the two factory accounts is associated with an eponymous authorization class which defines the access level for all local accounts within that class.

user (authorization class)
  • provides read-only access to non-security configurations
  • provides read access to visible files
  • login to user mode
  • cannot switch to admin mode
admin (authorization class)
  • provides read-write access to all configuration
  • provides read/write access to a sub-set of file system elements
  • login to admin mode
  • cannot switch to user mode

When local accounts are created, you specify the authorization class using the syntax:

local-accounts add <username> [ user | admin ]

Console Login

The following table summarizes the authorization classes for local accounts.

User Name Login prompt Authorization class
user user mode

>

user
admin admin mode

#

admin

Serial Port Control

With the addition of the Admin Security feature, you may enable or disable access to the serial (console) port. In the absence of this feature, access to the serial is generally available. The ACLI command console-io functions as a switch that you set to enabled to allow serial port access and to disabled to keep the serial port from being used.

If you remove the administrative management feature after disabling the serial port, the SBC reverts to its default behavior by providing serial port access.

To turn off access to the serial port:

  1. At the system prompt, type console-io followed by a Space. Then type disabled and press Enter. 
    ORACLE# console-io disabled

    If you want to re-enable the serial port, use the same command with the enabled argument.

Initial Login

Upon initial login, user and admin are required to change the respective password. Initial login is completed only after password change and acknowledgment of the login banner.

Note:

With each release, the default ciphers of the SBC may be upgraded to their latest secure versions. If a verbose connection log of an SSH or SFTP client shows that it cannot agree on a cipher with the SBC, upgrade your client.

To complete initial login:

  1. SSH to the SBC using one of the two factory default accounts (user or admin).
    ssh admin@<IP address>
  2. Enter the initial password.

    The initial password for the default user account is acme; the initial password for the default admin account is packet.

  3. Enter a new password in response to the Enter New Password: prompt.

    Passwords must meet the following length/strength requirements.

    • user password must contain at least 9 characters
    • admin password must contain at least 15 characters
    • passwords must contain at least 2 lower case alphabetic characters
    • passwords must contain at least 2 upper case alphabetic characters
    • passwords must contain at least 2 numeric characters
    • passwords must contain at least 2 special characters
    • passwords must differ from the prior password by at least 4 characters
    • characters in password must differ from the prior password in at least 8 positions
    • passwords cannot contain, repeat, or reverse the user name
    • passwords cannot contain three consecutive identical characters
  4. Re-enter the new password in response to the Confirm New Password: prompt.
  5. Enter y to acknowledge reading the login banner to complete initial login.

Remote SSH Login with Password

The following shows logging in as the factory default admin account.

[bob@linuxbox ~]$ ssh admin@10.1.1.2
Password: 
--------------------------------------------------------------------------------
   Last login : 2020-11-09 14:10:03 
   System last accessed by "admin", 2020-11-09 14:10:03

   WARNING: Unsuccessful login attempts were made for 'admin' on
        2020-09-14 15:14:08
        2020-11-03 16:53:57
        2020-11-06 14:15:53
        2020-11-06 14:16:09
        2020-11-06 14:16:21

--------------------------------------------------------------------------------
Confirm reading the above message [y/n]?: y
ADMINSEC#

Remote SSH Login with Public Key

As an alternative to password-based authentication, you can authenticate using SSH public keys. To set up public-key authentication, import a copy of the public key of each user who will authenticate using this method. The public key identifies the user as a trusted entity when the Oracle SBC performs authentication.

During the SSH login, the user presents its public key to the SBC, which validates the offered public key against the previously obtained trusted copy of the key to identify and authenticate the user.

  1. On the SSH client, export your public key to RFC 4716 format.
    [user@host ~]$ ssh-keygen -ef .ssh/id_rsa.pub
---- BEGIN SSH2 PUBLIC KEY ----
Comment: "1024-bit RSA, converted from OpenSSH by user@host" 
AAAAB3NzaC1yc2EAAAABIwAAV595VmIZBlpAIEAxcYTeOZx9sX/mSqdHy12P+AFihDJYdL
qJIWdiZuSmIC6na62iDny8HZIxT25mlYBCU7UsLwEdyLhlYOuknkmxDyHTbrQ4dLHz3b1q
3Tb8auz97/J39PT42Co1p4pwRODzPBrXJV0SSJ8BjC9+OglNE/83C1yLEwE= 
---- END SSH2 PUBLIC KEY ----
[user@host ~]$
  2. Use the ssh-key command to import the public key to the SBC.

    Syntax: 

    ssh-key authorized-key import <name> <authorizationClass>
    • where name is an alias or handle assigned to the imported public key, often the user’s name.
    • where authorizationClass is either user (the default) or admin.

    To import a public key for Dwight in the user class:

    ORACLE# ssh-key authorized-key import Dwight
ORACLE#

    To import a public key for Matilda in the admin class: 

    ORACLE# ssh-key authorized-key import Matilda admin
ORACLE#
  3. Paste the public key with the bracketing Begin and End markers at the cursor point.
  4. Enter a semi-colon (;) to signal the end of the imported host key.

    The entire import sequence is shown below. 

    ORACLE# ssh-key authorized-key import Matilda admin 

IMPORTANT: 
    Please paste ssh public key in the format defined in RFC 4716.
    Terminate the key with ";" to exit....... 

---- BEGIN SSH2 PUBLIC KEY ---- 
Comment: "1024-bit RSA, converted from OpenSSH by user@host" 
AAAAB3NzaC1yc2EAAAABIwAAV595VmIZBlpAIEAxcYTeOZx9sX/mSqdHy12P+AFihDJYdL
qJIWdiZuSmIC6na62iDny8HZIxT25mlYBCU7UsLwEdyLhlYOuknkmxDyHTbrQ4dLHz3b1q
3Tb8auz97/J39PT42Co1p4pwRODzPBrXJV0SSJ8BjC9+OglNE/83C1yLEwE= 
---- END SSH2 PUBLIC KEY ----; 
SSH public key imported successfully.... 
WARNING: Configuration changed, run "save-config" command to save it 
and run "activate-config" to activate the changes 
ORACLE#
  5. Save and activate the configuration.
  6. If necessary, repeat the above procedure to import additional user-specific public keys.

    Note:

    Imported SSH public keys are subject to the same expiration policies and procedures as passwords. An SSH public key’s lifetime is the same as a password, and it is subject to the same notifications and grace intervals. If an SSH public key expires, the admin user must import a new SSH public key for the user. To ensure continuity of access, the admin should import a new SSH public key prior to the key expiration.

    The following figure shows the successful public-key authentication of Matilda, who has logged in with admin privileges.

    [user@host ~]$ ssh Matilda@10.1.1.2
--------------------------------------------------------------------------------
   Last login : 2020-11-09 14:13:59 
   System last accessed by "Matilda", 2020-11-09 14:13:59

   WARNING: Unsuccessful login attempts were made for 'admin' on
        2020-09-14 15:14:08
        2020-11-03 16:53:57
        2020-11-06 14:15:53
        2020-11-06 14:16:09
        2020-11-06 14:16:21

--------------------------------------------------------------------------------
Confirm reading the above message [y/n]?: y
ORACLE#

    Note that the login banner refers to the admin and user login by the aliases used when the trusted copies of their SSH public keys were imported. In all respects, however, Matilda is a admin instance.

Two-Factor Authentication

Two-factor authentication (2FA) adds an extra layer of security when authenticating to the SBC by requiring a key, such as an SSH public key or X.509 certificate, as well as a username and password. 2FA can be enabled on either the web interface, the SSH interface, or both.

Prerequisites

The Admin Security entitlement must be installed.

Two-factor Authentication for the Web GUI

To enable 2FA on the web interface, add the Common Name of the X.509 client certificate to the common-name-list attribute and set the value of two-factor-auth-access-method-list to GUI. When enabled, 2FA to the GUI requires the browser to send an X.509 client certificate to the SBC. The SBC then verifies:
  • The client certificate key length is at least 1024 bytes (2048 bytes if the Data Integrity (FIPS) entitlement is also installed).
  • The client certificate was signed by a previously installed root CA certificate.
  • The client certificate is not revoked.
  • The Common Name in the certificate is found in the list configured in the common-name-list attribute.

    Note:

    2FA will fail if the Common Name associated with the client certificate that the web browser sends to the SBC is not found in the common-name-list attribute.
If all of these conditions are true, the SBC proceeds to authenticate the user based on the existing methods like username, certificate-based login, RADIUS, or TACACS+.

To use 2FA on the web interface, the client browser must be configured to send the appropriate certificate to the SBC. Check your browser's documentation for how to add a client certificate to your browser's certificate manager.

Two-factor Authentication for the SSH Interface

2FA on the SSH interface can use either local authentication (to login as the local admin account or the local user account) or RADIUS/TACACS+ authentication. In either case, at least one of the following is required:

  • Import the authorized-key of an SSH client; or
  • Import the ca-key that will sign the public keys of SSH clients.
For example, if the type attribute in the authentication element is set to local, you can import the public key of the SSH client that will log in as the local admin account. 
ssh-key authorized-key import admin admin
Alternatively, if the type attribute in the authentication element is set to tacacs or radius, you can import the public key of a RADIUS or TACACS+ user who will administer the SBC.
ssh-key authorized-key import alice admin

Note:

For instructions on signing certificates, see "Add a Certificate Authority Key" in the Configuration Guide.

After certificates are configured, set the two-factor-auth-access-method-list to SSH. When enabled, the SBC requires a user to authenticate with both a pubic key and a password.

2FA Lockout

To prevent getting locked out of an SBC with 2FA enabled, never delete the last authorized-key or the last ca-key.

Caution:

Removing the last authorized-key or the last ca-key will make it impossible to SSH to the management port if 2FA is enabled on the SSH interface.

Enable Two-Factor Authentication

  1. Access the two-factor-authentication configuration element. 
    ORACLE# configure terminal
ORACLE(configure)# security 
ORACLE(security)# authentication
ORACLE(authentication)# two-factor-authentication 
ORACLE(two-factor-authentication)#
  2. two-factor-auth-access-method-list—Select the interface that will require 2FA.
    You may enable 2FA on either the SSH interface, the web interface, or both.
  3. common-name-list—Enter the Common Name (CN) found in the certificate that the client sends.
  4. Type done to save the configuration.

Certificate-based Authentication

As an alternative to local authentication, when two-factor authentication is enabled for FIPS and JITC-compliant installations, the SBC supports client certificate-based authentication for the web interface.

Prerequisites

Certificate-based authentication depends on the following prerequisites:
  • The following entitlements are installed:
    • Admin Security
    • Data Integrity (FIPS)
  • HTTPS access to the web GUI is enabled. See the Enable the Web GUI for Access chapter of Enterprise SBC Web GUI Guide for more information.
  • Two-factor authentication using certificates is configured in the two-factor-authentication configuration element:
    • The CN of the client certificate has been added to the common-name-list attribute
    • The two-factor-auth-access-method-list is set to GUI
    See Enable Two-Factor Authentication in this guide for more information.
  • Online Certificate Status Protocol (OCSP) is configured. See Online Certificate Status Protocol in the Security chapter of SBC Configuration Guide.

Note:

The SSH interface does not support certificate-based authentication.

Configuring Certificate-based Authentication

You configure certificate-based authentication by enabling the multi-factor-functionality-enhancement configuration element and creating local accounts with the MFFE authentication type.

Certificate-based Authentication Flow

When certificate-based authentication is enabled, after 2FA successfully validates a client certificate, the login screen automatically loads the common name (CN) extracted from the certificate in a read-only username field, and there is no password field. When the user selects Sign In, the SBC matches the CN to a configured local user account, authenticates the user using the certificate, establishes a session, and directs the user to the Dashboard tab. The SBC uses the same CN-derived username for the duration of the session, and session detail queries return this same CN-derived username.

Note:

Unlike for standard SBC 2FA, for certificate-based authentication, the CN extraction is not dependent on the CN position in the subject DN.

When a user logs out, the current MFFE Web GUI session is terminated and the login screen reloads. The SBC re-evaluates the criteria for MFFE, two-factor authentication, OCSP, and client certificate eligibility. If the user remains eligible, the MFFE login screen appears, with the read-only extracted CN username and no password field. If the user is no longer eligible for MFFE, the standard login screen appears.

Failed Certificate-based Authentication

In the following failure scenarios, the criteria for certificate-based authentication are not met, and the standard HTTPS or 2FA failure flow applies:
  • No client certificate is sent.
  • The client certificate fails OCSP validation.
  • The CN could not be extracted from the DN.
  • The extracted CN is rejected by an SBC configuration policy.
If the certificate-based authentication criteria are met, the authentication may still fail for the following reasons:
  • The extracted CN matched a local account, but the authentication type is passwd. Only accounts with MFFE authentication type can authenticate with certificates.
  • The extracted CN does not match the username of any existing local account with the MFFE authentication type
  • The SBC was unable to create the session in the backend.

In these failure scenarios, the SBC displays the certificate-based authentication-specific failure screen. It does not fall back to a username and password-based login.

Enable Certificate-based Authentication

You can enable certificate-based authentication by enabling multi-factor-functionality-enhancement and creating local accounts with the MFFE authentication type.

  1. Access the multi-factor-functionality-enhancement configuration element. 
    ORACLE# configure terminal
ORACLE(configure)# security 
ORACLE(security)# authentication
ORACLE(authentication)# multi-factor-functionality-enhancement 
ORACLE(multi-factor-functionality-enhancement)#
  2. Set MFFE to enabled. The default is disabled
  3. Type done to save the configuration.
  4. Type exit until you return to the top-level superuser prompt.
  5. Create local accounts with the MFFE authentication type:
    ORACLE# local-accounts add <user> <class> MFFE

    where:

    • <user> is the username
    • <class> is the class of user, either user or admin
    • MFFE enables the account for certificate-based authentication. By default, local accounts do not use certificate-based authentication.

    Note:

    You can set the authentication type for an account at creation time only. You cannot switch between authentication types later. To switch types for an existing account, you must delete and recreate the account.

Secure Radius Connection

The SBC can connect to a Radius server over a secure IPSec/IKEv2 connection over a media interface.

Note:

You must have the IPSec license installed to enable Radius over a secure IPSec/IKEv2 connection.
To properly configure a secure Radius connection, the following config elements and parameters must be configured:
  • security, authentication
    • type (set to radius)
    • server-assigned-privilege (set to enabled)
    • management-servers
  • security, authentication, radius-server
    • address (the Radius server IP)
    • secret
    • nas-id
    • realm-id
  • security, ike, ike-config
    • log-level
    • phase1-dh-mode
    • phase2-exchange-mode
    • red-port-options
  • security, ike, ike-interface
    • ike-version (set to 2)
    • address
    • realm-id
    • ike-mode
    • esnSupport (set to enabled)
    • shared-password
    • eap-protocol
  • security, ike, ike-sainfo
    • name
    • tunnel-local-addr
    • tunnel-remote-addr
  • security, ipsec, security-policy
    • name
    • network-interface
    • priority
    • local-ip-addr-match
    • remote-ip-addr-match
    • ike-sainfo-name

RADIUS Authentication and Authorization

As an alternative to local authentication, users may use a RADIUS server to authenticate.

For information on configuring between RADIUS servers and the SBC refer to RADIUS Authentication section in the ACLI Configuration Guide.

A RADIUS users file (shown below), stored on the RADIUS server, provides the basis for server authentication and authorization decisions. 

user1   Cleartext-Password := "user1"
        Acme-User-Class = user,
        Acme-User-Privilege = sftpForAll
			
user2   Cleartext-Password := "user2"
        Acme-User-Class = user,
        Acme-User-Privilege = sftpForAll
			
admin1  Cleartext-Password := "admin1"
        Acme-User-Class = admin,
        Acme-User-Privilege = sftpForAll
			
admin2  Cleartext-Password := "admin2"
        Acme-User-Class = admin,
        Acme-User-Privilege = sftpForAll

Upon receiving a login request, the SBC sends a RADIUS Access Request message to the RADIUS server. The request message contains, among other things, the username:password requesting access to SBC resources. Upon receiving the request, the RADIUS server checks its user file for the username:password pair. If its finds a congruent match, the requestor is authenticated.

Successful authentication generates a Access Accept message to the SBC; the message also contains the contents of two Oracle Vendor Specific Attributes (VSAs). Acme-User-Class specifies the configuration privileges accorded the authenticated user. Acme-User-Privilege specifies the log file access accorded to the authenticated user. Together these two VSAs provide the authorization function. Consequently, the RADIUS server functions as an authentication and authorization decision point, while the SBC functions as an enforcement point.

RADIUS Authorization Classes

The RADIUS authorization classes, as specified by the Acme-User-Class VSA, coincides with the two default admin and user authorization classes.

Note:

The value of Acme-User-Class must be lowercase.

user

  • provides read-only for all system configuration
  • The login prompt for this user is ORACLE> 
Acme-User-Class = user

admin

  • provides read-write access for all system configuration
  • The login prompt for this user is ORACLE# 
Acme-User-Class = admin

RADIUS and SSH

When the SBC uses a RADIUS server for authentication, you cannot log in over SSH using the two factory defined accounts (user and admin). Attempts to login via SSH are rejected. 

[user@host ~]$ ssh user@10.1.1.2
Password: 
% Error: Cannot login as local user when AAA Server is enabled

       Use console to login as local user

RADIUS and Password Policies

With RADIUS enabled, passwords are stored and controlled on the remote RADIUS server or servers. Consequently, none of the length/strength, re-use, history, or expiration requirements mandated by the local password policy are applicable to RADIUS passwords. Most RADIUS servers, however, do enforce password policies of their own.

TACACS+ Support

As an alternative to the local authentication/authorization described in previous sections, the SBC supports TACACS+ in both Admin Security mode and JITC. The SBC allows HTTPS, SSH, and SFTP logins with TACACS+ credentials, honoring the privilege level returned by the TACACS+ server and, if tacacs-authorization is enabled, validates commands via TACACS+ when the user has privileges.

Note:

For SFTP, only TACACS+ users with admin privileges have permission to login.

When TACACS+ is configured and a Public Key Infrastructure (PKI) user logs into the SBC, the SBC performs the authentication locally against the locally stored public RSA key, but performs authorization and accounting with TACACS+. This means that, instead of adhering to the permissions configured when importing the public key, the SBC queries the TACACS+ server and generates start/stop accounting records using TACACS+ settings.

TACACS+ over IPSec

To run TACACS+ over IPsec on an SBC with the Admin Security entitlement set, you must complete the following steps:

  1. Configure a phy-interface for wancom0.
    For example:
    ADMINSEC# conf term
ADMINSEC(configure)# system phy-interface 
ADMINSEC(phy-interface)# name wancom0
ADMINSEC(phy-interface)# operation-type Control 
ADMINSEC(phy-interface)# done
  2. Configure a network-interface for wancom0.
    For example:
    ADMINSEC# conf term
ADMINSEC(configure)# system network-interface 
ADMINSEC(network-interface)# name wancom0
ADMINSEC(network-interface)# ip-address 10.1.1.5
ADMINSEC(network-interface)# netmask 255.255.255.0
ADMINSEC(network-interface)# gateway 10.1.1.1
ADMINSEC(network-interface)# done
  3. Configure a security-policy for wancom0.
    For example:
    ADMINSEC# conf term
ADMINSEC(configure)# security ipsec security-policy 
ADMINSEC(security-policy)# name secureTacacs
ADMINSEC(security-policy)# network-interface wancom0:0
ADMINSEC(security-policy)# remote-ip-addr-match 10.1.1.42
ADMINSEC(security-policy)# remote-ip-mask 255.255.255.0
ADMINSEC(security-policy)# done
  4. Configure the ikev2-ipsec-wancom0-params configuration element.
    For example:
    ADMINSEC# conf term
ADMINSEC(configure)# security ikev2-ipsec-wancom0-params 
ADMINSEC(ikev2-ipsec-wancom0-params)# name TacPlusIPsec
ADMINSEC(ikev2-ipsec-wancom0-params)# remoteip 10.1.1.42
ADMINSEC(ikev2-ipsec-wancom0-params)# remotesubnet 10.1.1.42/32
ADMINSEC(ikev2-ipsec-wancom0-params)# localip 10.1.1.5
ADMINSEC(ikev2-ipsec-wancom0-params)# localsubnet 10.1.1.5/32
ADMINSEC(ikev2-ipsec-wancom0-params)# authby secret 
ADMINSEC(ikev2-ipsec-wancom0-params)# shared-password 
Enter password: 
Retype password: 
Password updated
ADMINSEC(ikev2-ipsec-wancom0-params)# done
  5. Save and activate your configuration.
If no security-policy is configured, the SBC displays this verify-config error.
WARNING: Admin-security enabled. 10.1.1.42 tacacs server does not match any of the configured security-policy's remote-ip-addr-match/remote-ip-mask subnet. So communication from SBC to this server over media ports will not be secured by IPsec.

System Access Based on Server Availability

When delegated authentication methods like RADIUS and TACACS+ are used with the Admin Security entitlement, the SBC behaves differently depending on whether it can access the authentication server.

When the RADIUS or TACACS+ server is available, password-based SSH authentication using the factory account or a local account is blocked. When the RADIUS or TACACS+ server is unavailable, password-based SSH authentication using either the factory account or a local account is allowed.

  Server is accessible Server is not accessible
Factory accounts No SSH or SFTP access SSH and SFTP access
Local accounts No SSH or SFTP access SSH and SFTP access

Console access is always permitted using either the factory accounts or a local account.

To understand how key-based SSH authentication interacts with other accounts (local accounts, RADIUS, TACACS+), see the User Accounts section in the Configuration Guide.