Extreme Networks Summit Series Switches Common Criteria Admin Guide

Transcription

1 Extreme Networks Summit Series Switches Common Criteria Admin Guide Published: December 2017 Extreme Networks, Inc. Phone / Toll-free / Extreme Networks, Inc. All rights reserved. Extreme Networks and the Extreme Networks logo are trademarks or registered trademarks of Extreme Networks, Inc. in the United States and/or other countries. All other names are the property of their respective owners. All other registered trademarks, trademarks, and service marks are property of their respective owners. For additional information on Extreme Networks trademarks, see P/N

2 1 Contents 2 Introduction Intended Audience About Common Criteria Related Documents Evaluated Configuration Assumptions and Operational Environment How to Access Your System Local Command Line Interface (CLI) Connecting to the Serial Console Port Configuring Remote Administrative Management Interface Logging Out Setting Up the Common Criteria Configuration Evaluated Configuration Enabling FIPS Mode Configuring cryptographic primitives Configuring Diffie-Hellman Group Configuring Data Encryption Algorithms and HMAC Algorithms Enabling RSA Authentication Enabling SSH Host Keys Applying Software Updates to the TOE Upgrading the Software Downloading Software Updates Changing the System Clock Manually Configuring the System Clock (data, time, time zone, etc.) Configuring System Clock Using NTP Server Configuring SNMP to Read-Only Community Strings Configuring Role-Based Access Control Creating Users and Configuring AAA Authentication Viewing Accounts Deleting an Account Configuring Hostname Password Management Configuring Password Attributes Changing User Passwords Configuring Management Session Timeouts Configuring the Local Console Session Timeout Extreme Networks, Inc. All rights reserved. 2

3 Configuring Remote Access Timeout Authentication Failure Handling Configuring Syslog Enabling and Disabling Logging to Syslog Clearing Log files Audit Event Log format Configuring Log levels Configuring Logging Filters: Configuring Logging Buffer size Configuring the Login Banner SSH Rekeying Configuring x509v3 Authentication Generating a Certificate Signing Request Installing Trusted Certificates Configuration of OCSP Responders (OCSP Server) Using OpenSSL to set up OCSP responders Self Tests Appendix Auditable Events Extreme Networks, Inc. All rights reserved. 3

4 2 Introduction This guide provides the information an administrator would need to set up and administer the Extreme Networks Summit Series switches in compliance with the Common Criteria evaluated configuration. Follow this guide in its entirety to ensure that the settings of each parameter match the specific configuration that was evaluated and certified as secure by the Common Criteria certification. Please refer to the Security Target document for details on what has been evaluated in the Common Criteria configuration. 3 Intended Audience This document is intended for use by administrators who are responsible for installing, configuring, and operating network security for their organization. To use this guide you must have knowledge of your organization s network infrastructure and standard networking technologies. For more detailed information on specific commands used in this document, refer to other user guidance provided by Extreme Networks Inc. 4 About Common Criteria The Common Criteria for Information Technology Security Evaluation (ISO/IEC 15408) is an international standard for certification of the security of computer systems, networks, and application software. The certification ensures that the claims about the security attributes of the evaluated product were independently verified in the evaluated configuration operated in the specific environment. 5 Related Documents For more information about Extreme Summit Series Switches, see the following documents: Table 1. Guidance Documentation Identifier Edition Title Security Target v2.4 Extreme Networks Summit Series Switches v2.4 6 Evaluated Configuration The TOE is the Extreme Networks Summit series switches running EXOS v patch1cc-2 and includes the following appliances. Summit X870 series Summit X690 series Summit X620 series Summit X440-G2 series Summit X450-G2 series Summit X460-G2 series Summit X670-G2 series 2017 Extreme Networks, Inc. All rights reserved. 4

5 The Common Criteria certification does not guarantee the product is secure in all circumstances and possible modes of operation. It is assumed that the system administrators install, manage, and use the Extreme ExtremeSwitching and Summit series switches in accordance with the instructions in this document. Note The use of other cryptographic engines were not evaluated nor tested during the CC evaluation of the TOE. 7 Assumptions and Operational Environment There are specific conditions that are assumed to exist in the TOE s Operational Environment. The following table lists assumptions about the Operational Environment as specified by the NDcPP: Table 2. Operational Environment Assumptions Name A.PHYSICAL_PROTECTION A.LIMITED_FUNCTIONALITY A.NO_THRU_TRAFFIC_PROTECTION A.TRUSTED_ADMINISTRATOR Assumption Definitions The network device is assumed to be physically protected in its operational environment and not subject to physical attacks that compromise the security and/or interfere with the device s physical interconnections and correct operation. This protection is assumed to be sufficient to protect the device and the data it contains. As a result, the cpp will not include any requirements on physical tamper protection or other physical attack mitigations. The cpp will not expect the product to defend against physical access to the device that allows unauthorized entities to extract data, bypass other controls, or otherwise manipulate the device. The device is assumed to provide networking functionality as its core function and not provide functionality/ services that could be deemed as general purpose computing. For example the device should not provide computing platform for general purpose applications (unrelated to networking functionality). A standard/generic network device does not provide any assurance regarding the protection of traffic that traverses it. The intent is for the network device to protect data that originates on or is destined to the device itself, to include administrative data and audit data. Traffic that is traversing the network device, destined for another network entity, is not covered by the NDcPP. It is assumed that this protection will be covered by cpps for particular types of network devices (e.g, firewall). The Security Administrator(s) for the network device are assumed to be trusted and to act in the best interest of security for the organization. This includes being appropriately trained, following policy, and adhering to guidance documentation. Administrators are trusted to ensure passwords/credentials have sufficient strength and entropy and to lack malicious intent when administering the device. The network device is not expected to be capable of defending against a malicious administrator that actively works to bypass or compromise the security of the device Extreme Networks, Inc. All rights reserved. 5

6 Assumptions Name A.REGULAR_UPDATES A.ADMIN_CREDENTIALS_SECURE A.RESIDUAL_INFORMATION Assumption Definitions The network device firmware and software is assumed to be updated by an administrator on a regular basis in response to the release of product updates due to known vulnerabilities. The administrator s credentials (private key) used to access the network device are protected by the platform on which they reside. The Administrator must ensure that there is no unauthorized access possible for sensitive residual information (e.g. cryptographic keys, keying material, PINs, passwords etc.) on networking equipment when the equipment is discarded or removed from its operational environment. The following table identifies the organizational security policies applicable to the TOE as specified by the NDcPP: Table 3. Organizational Security Policies Policy Name P.ACCESS_BANNER Policy Definition The TOE shall display an initial banner describing restrictions of use, legal agreements, or any other appropriate information to which users consent by accessing the TOE Extreme Networks, Inc. All rights reserved. 6

7 8 How to Access Your System 8.1 Local Command Line Interface (CLI) The CLI requires a physical connection to the TOE serial port, and is accessed directly via a terminal device that is physically connected to the TOE. This interface enforces user authentication Connecting to the Serial Console Port The CLI connection can be established using a compliant terminal emulator program using the following parameters: Terminal Type: VT100 Baud Rate: (for X870 and X690) 9600 (for all other switches) Parity: None Data bits: 8 Stop bits: 1 When successfully connected, the login screen appears. 1. Enter your login credentials. 2. You are asked if you want to disable MSTP. Type n for no. 3. You are then asked if you want to enable enhanced security mode. Type y for yes Configuring Remote Administrative Management Interface For remote administration of the device, (CLI over SSH) the device can be configured to authenticate using a public key mechanism (RSA), or a password-based mechanism. If a user attempts public key-based authentication and it succeeds, the authentication process is completed and the user is granted access. If the user fails to authenticate using a public key certificate, then the device falls back to password-based authentication and requires the to enter a valid username and password. When RSA authentication is used, the TOE checks the presented public key against its authorized keys database and verifies the user s possession of a private key by negotiating a secure channel using the public key associated with that private key. Initial configuration of the remote administrative interface, in the case of the Extreme Networks ExtremeSwitching and Summit series switches, is performed via the physical network connector on the front of the device marked Management (which is located directly above the Console interface). The remote management interface is part of the Virtual Router (VR) VR-Mgmt and has DHCP enabled by default. To manually configure this interface, statically assign an IP Address to the Management VLAN (Mgmt) and add a static route: 1. Specify the VLAN Mgmt IP Address 2017 Extreme Networks, Inc. All rights reserved. 7

8 # config vlan mgmt. ipaddress {address}/{net mask} 2. Define the static route # config iproute add / vr vr-mgmt (The above is an example. Use applicable route.) 3. Enable SSH # enable ssh2 vr vr-mgmt 4. Save the configuration # save config Remote administration via SSH should now be accessible via any SSH client that has connectivity to the network that the Summit Series switch is part of. Securing SSH connectivity will be covered in subsequent sections. The TOE requires that each user is successfully authenticated before allowing any other action on behalf of that user. The TOE requires any user to be identified and authenticated before any management action. 8.2 Logging Out Logging out of the switch is performed the same whether it be on the console or using SSH. To do so, type # exit at the command prompt Extreme Networks, Inc. All rights reserved. 8

9 9 Setting Up the Common Criteria Configuration 9.1 Evaluated Configuration When the TOE is zeroized/wiped, it clears the SSL and SSH private keys, the user database, requires setting up of the admin account, and loads the default configuration. The initial configuration wizard is presented, at which point enhanced security mode must be enabled. This feature disables telnet, the HTTP and SNMP servers, and other security features not essential for the TOE s operation as per the NDcPP. All unsupported algorithms must be disabled, one at a time. 9.2 Enabling FIPS Mode Enabling FIPS cryptographic mode in the system is done by performing the following operation and then rebooting the system. 1. Issue the following command: # configure security fips-mode on 2. Reboot the TOE by running reboot then entering yes at the prompt 3. Verify that FIPS mode is set by running the following command: # show security fips mode 9.3 Configuring cryptographic primitives Configuring Diffie-Hellman Group 14 Disable Diffie-hellman group 1 by issuing the following command: # configure ssh2 dh-group minimum 14 Diffie-Hellman groups others than group 14 are now disabled Configuring Data Encryption Algorithms and HMAC Algorithms SSH works on three security modes: default-mode, FIPS-mode, and Secure-Mode. In each mode, you can configure the required ciphers and MACs from a list using the CLI. Different modes support a different list of ciphers. By default, all available ciphers and MACs in the modes are configured. 1. Disable all unsupported algorithms by entering the following commands: # configure ssh2 disable cipher 3des # configure ssh2 disable cipher aes128-ctr 2017 Extreme Networks, Inc. All rights reserved. 9

10 # configure ssh2 disable cipher aes256-ctr # configure ssh2 disable cipher rijndael-cbc@lysator.liu.se # configure ssh2 disable cipher aes192-ctr # configure ssh2 disable cipher aes192-cbc The following data encryption algorithms are supported by default: aes-128-cbc aes-256-cbc 2. Verify that the data encryption algorithms required by the NDcPP are supported by running: # show ssh2 ciphers The following data integrity algorithms are supported by default in the evaluated configuration: hmac-sha1, hmac-sha2-256 and hmac-sha Enabling RSA Authentication RSA scheme using cryptographic key sizes of 2,048 bits or greater is supported utilizing SHA-1, SHA- 256, SHA-512 are used for authentication as part of SSHv2 protocol. To disable ssh-dss, x509v3-sign-rsa, and x509v3-sign-dss public key algorithms, use the following command: # configure ssh2 disable pk-alg x509v3-sign-dss # configure ssh2 disable pk-alg ssh-dss # configure ssh2 disable pk-alg x509v3-sign-rsa The following hashing algorithms are supported: SHA-1, SHA-256, and SHA-512 To view which public key-based algorithms are currently enabled, use the following command: # show ssh2 9.5 Enabling SSH Host Keys SSH host keys are used to authenticate the TOE. Enter the following command to generate the SSH Server keys. # config ssh2 key Log messages indicate the completion of the key generation process. 9.6 Applying Software Updates to the TOE Only Security Administrators can upgrade TOE software. The evaluated version of EXOS is v patch1cc-2. After connecting to the switch either with the serial console or by SSH remote management, execute the command # show version This command will indicate the current version of software installed on the TOE Extreme Networks, Inc. All rights reserved. 10

11 9.6.1 Upgrading the Software The device has two boot partitions primary and secondary. The # show switch command displays the versions of software that are loaded into the switch, the version the switch is currently running (Image Booted), and the version that will be loaded the next time the switch boots (Image Selected). Do not abort the system reboot that takes place as part of the software upgrade process as the software install only takes effect after a successful reboot. Always verify the software version after an upgrade. # show switch Prior to upgrading the image on the switch, the administrator needs the following information: the IP address of the TFTP server to which the new software package resides the full file name (case sensitive) for the software package the Virtual Router (VR) that the TFTP server is connected to To upgrade the switch software, use the command: # download image <ipaddress> <fielname> vr <vr-name> The following prompt appears: Do you want to install image after downloading? (y - yes, n - no, <cr> - cancel) Extreme Networks, Inc. All rights reserved. 11

12 Select Y at the prompt to confirm. The device will then reboot from the new image. Note The out-of-band management interface on the front face of the switch belongs to the Virtual Router VR-Mgmt, by default all other ports on the switch belong to the Virtual Router VR-Default Downloading Software Updates To download software updates, an authorized user must authenticate to the Extreme Portal website at where the software downloads (image files) are available. The downloaded image must be transferred to the device using a method such as TFTP. All image files are digitally signed by Extreme using a RSA mechanism. The device uses a public key to verify the digital signature; upon successful verification of this signature the device then applies the new image after rebooting. In cases, where one tries to download a corrupted image or an image with a bad signature the device will fail to download the image and a corresponding error message would be presented to the user. The digital certificate used by the update verification mechanism is contained on the device. 9.7 Changing the System Clock Manually Configuring the System Clock (data, time, time zone, etc.) Manually configure the system clock from the default configuration of the system date/time by entering the following command: # config time <month> <day> <year> <hour> <min><sec> Configure the time zone for the TOE by entering the following command: # config timezone name <unique name> <offset in minutes> autodst begins <every on> <first fourth last second third> <weekday> <month> <at ends name> <begin hour> <begin minute> ends <on every> <first second third last> <weekday> <month> <at name> <end hour> <end minute> name <unique name> Confirm the change to the system date/time by running the following command: # show switch grep "Current Time" Configuring System Clock Using NTP Server To configure the switch to use an external NTP server as a clock, use the command: # enable sntp-client # configure sntp-client primary vr "vr-mgmt 2017 Extreme Networks, Inc. All rights reserved. 12

13 9.8 Configuring SNMP to Read-Only Community Strings SNMP is disabled in the CC configuration of the device. Verify this by running the command: # show management If for some reason SNMP is not disabled, use the following command to disable it: # disable snmp access snmp-v1v2c 9.9 Configuring Role-Based Access Control The device supports two roles: Security Administrator and User. A user-level account can view all manageable parameters, and can change their own password. A person with an administrator-level account can view and change all switch parameters, add and delete users, and change the password associated with any account name (to erase a password, use the # unconfigure switch all command). All of the management functions are restricted to the Security Administrators of the device Creating Users and Configuring AAA Authentication 1. Log in to the switch as admin. 2. At the password prompt, press Enter, or enter the password that you have configured for the admin account. 3. Run # create account [admin user ] account-name {encrypted encrypted_password password} to add a new user. 4. If you do not specify a password or the keyword encrypted, you are prompted for one. Passwords are case-sensitive. Caution Using the encrypted option incorrectly can result in being locked out of your switch account. If you do not want a password associated with the specified account, press [Enter] twice. User-created account names are not case-sensitive. Note Although the TOE supports multiple accounts, the only accounts that were tested and evaluated were the following: admin (Security Administrator) and user Viewing Accounts Only a Security Administrator can view the accounts that have been created by using the show accounts command Extreme Networks, Inc. All rights reserved. 13

14 9.9.3 Deleting an Account Only a Security Administrator can remove accounts that should no longer exist, by using the delete account command. # delete account account-name 9.10 Configuring Hostname While the TOE itself does not have a hostname, the SNMP variable sysname becomes the prompt an Administrative user sees when logging into the switch and becomes the hostname of the switch or stack. Configuration must be performed by a Security Administrator. configure # snmp sysname {system name} Note If the prompt is to contain spaces, it will need to be in quotes. Example: Extreme x Password Management A password can be any combination of upper and lower case letters, numbers, and the following special #, $, %, ^, *, (, and ). The minimum password length is configurable by a Security Administrator, and can be configured for minimum password lengths of 15 characters. A user requesting a login is prompted to enter a user name and password after establishing a successful connection. The TOE then compares the credentials against the known user database. If the combinations matches, the TOE then attributes (binds) the administratively-assigned role and the user is granted access. Passwords are stored in the device in encrypted format and are obscured by asterisks Configuring Password Attributes Password policies are set through the Command Line Interface(CLI). Syntax for global configuration: # config account all Syntax for user: #config account {username} password-policy The global attributes that can be changed are: Attribute Char-validation Valid Range All-char-groups or none History Value between 1 & 10 or None Lockout-on-login-failures On or Off Lockout-time-period Until Cleared or 1-60 Minutes Max-age None or between 1 & 365 days Min-Length None or between 1 & 32 characters 2017 Extreme Networks, Inc. All rights reserved. 14

15 Changing User Passwords User passwords are changed through the CLI by a Security Administrator. To change a user s password, use the following command: # config account {username} 9.12 Configuring Management Session Timeouts Configuring the Local Console Session Timeout The device implements remote and local administrative access via the CLI. The TOE s minimum lockout value must be configured to a non-zero value to enforce an administrator-defined inactivity timeout, after which the inactive session is automatically terminated. The inactivity timeout value is between minutes, and the default value is 20 minutes. Once a session (local or remote) has been terminated, the TOE requires the user to re-authenticate. Configure the idle timeout, use the following commands: # enable idletimeout # configure idletimeout Configuring Remote Access Timeout Configure the SSH session timeout for the switch to disconnect a session left idle after a predetermined time interval. # configure ssh2 idletimeout Authentication Failure Handling A user account is locked after an administrator-configurable (1 to 10) number of unsuccessful authentication attempts. After a user is locked out, all further authentication attempts are reported as unsuccessful, even when correct information is provided. To regain access, the user has to wait an administrator-configurable time duration before being allowed to successfully authenticate. 1. Set the lockout upon login failure by running: # configure account admin password-policy lockout-on-login-failures on 2. Set the time period after which the admin account will be automatically unlocked by running: # configure account admin password-policy lockout-time-period 2 3. Set the number of login failures before the account admin is locked out by running: # configure cli max-failed-logins 3 A Security Administrator account can only be locked out if there is at least one other Security Administrator account that is available. This ensures that Security Administrators are never completely locked out from accessing the TOE Extreme Networks, Inc. All rights reserved. 15

16 9.14 Configuring Syslog The TOE supports communication with the external audit server by establishing a trusted channel between itself and the audit server. To implement this trusted channel, the TOE uses the TLS v1.2 protocol with mutual X.509v3 certificate-based authentication. For certificate-based authentication, the X.509v3 certificate presented by the external audit server is first validated and then compared to the authorized certificates database. The TOE supports the following ciphers by default in the evaluated configuration: TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_ SHA256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 To enable a TLS connection from the TOE to the external syslog server, run the following commands: # configure syslog add tls-port 6525 vr VR-Mgmt local6 # configure syslog tls-port 6525 vr VR-Mgmt local6 reference-identifier SYSLOG # enable log target syslog tls-port 6525 vr VR-Mgmt local6 # configure log target syslog tls-port 6525 vr VR-Mgmt local6 filter DefaultFilter severity Debug-Data # configure log target syslog tls-port 6525 vr VR-Mgmt local6 match Any # configure log target syslog tls-port 6525 vr VR-Mgmt local6 format timestamp seconds date Mmm-dd event-name none priority host-name tag-name # Enable syslog For more information about certificate based authentication, see Configuring x509v3. The TOE implements configurable audit filters, with a global filter called DefaultFilter that provides the defining default audit behavior for all targets. Authorized administrators can add, remove, or apply different filters for each target. The transmission of audit logs to the external audit server is done in real time, with each audit record transferred as it is generated. If the connection to the external audit server is lost, the TOE continues to save local audit logs so there is no loss of audit. There is automated log reconciliation process (syncing) between the locally stored records with the external audit server upon the re-establishment of the connection Enabling and Disabling Logging to Syslog Enable CLI logging 2 by running: # enable cli-config-logging Disable CLI logging by running: # disable cli-config-logging 1 The IP address indicated is an example only. Use one appropriate for your organization s network. 2 CLI logging is disabled by default Extreme Networks, Inc. All rights reserved. 16

17 Clearing Log files Clearing local audit trail is done per target and it wipes all audit records for that target. Clear audit logs from the memory buffer by running: # clear log static memory-buffer Audit Event Log format For each audit captured, the generated record contains: the date and time, the type of event, the subject identity (for example, IP address or User Name), the outcome and severity of the log message Configuring Log levels The TOE categorizes audit records by severity levels as follows: critical, error, warning, notice, and informational with three severity levels for extended debugging. In log messages, these three severity levels are each indicated by four letter abbreviations. By default, the memory-buffer and syslog targets are configured to capture log information at levels debug-data through critical In the Common Criteria evaluation, the following audit severity levels were tested: Audit Level Numerical Code Description Critical 2 A serious problem has been detected that is compromising the operation of the system; the system cannot function as expected unless the situation is remedied. The switch may need to be reset. Error 3 A problem has been detected that is interfering with the normal operation of the system; the system is not functioning as expected. Warning 4 An abnormal condition, not interfering with the normal operation of the system, has been detected that indicate that the system or the network in general may not be functioning as expected. Notice 5 A normal but significant condition has been detected, which signals that the system is functioning as expected. Info (Informational) 6 A normal but potentially interesting condition has been detected, which signals thatthe system is functioning as expected; this level simply provides potentially detailed. Debug-Verbose 7 A condition has been detected that may interest a developer analyzing some system behavior at a more verbose level than provided by the debug summary information. Configure log levels by running: # configure log filter name [add delete] {exclude} events [event-condition [all event-component] {severity severity {only}}] 2017 Extreme Networks, Inc. All rights reserved. 17

18 Configuring Logging Filters: The TOE implements configurable audit filters, with a global filter called DefaultFilter that provides the defining default audit behavior for all targets. Authorized administrators can add, remove, or apply different filters for each target. Some examples are: # enable log debug-mode # configure log messages privilege admin # configure log filter DefaultFilter add events thttpd severity info # configure log filter DefaultFilter add events exsshd severity debug-verbose # configure log filter DefaultFilter add events cm severity debug-verbose # configure log filter DefaultFilter add events AAA severity debug-verbose Configuring Logging Buffer size The local buffer size is configurable and it can range from records. All local audit records exist in a circular buffer, FIFO manner; when the buffer gets full, the oldest message is overwritten first. There is no access to audit data storage, CLI allows displaying of logs but there is no access to log files. Configure the memory buffer size as per the NDcPP by running: # config log target memory-buffer number-of-messages Configuring the Login Banner The TOE displays a customizable banner for local or remote login, with a before-login banner and an after-login banner. 1. Configure the pre-login banner by running: # configure banner before-login save-to-configuration Example: Enter Welcome to this shiny new switch!, and hit enter twice 2. Configure the after-login banner by running: # configure banner after-login save-to-configuration Example: Enter Welcome to this shiny new switch!, and hit enter twice, logout and login locally and remotely and verify the revised banner messaging SSH Rekeying The TOE automatically rekeys an SSH connection after administrator-configurable thresholds. By default, the rekey happens after 60 minutes or 1 GB of data transfer, whichever occurs first. 1. Run the following command to set the time-based threshold for 10 minutes: # configure ssh2 rekey data-limit 4096 # configure ssh2 rekey time-interval Run the following command to set the threshold for maximum data transmission to 1 megabyte: # configure ssh2 rekey time-interval none # configure ssh2 rekey data-limit Extreme Networks, Inc. All rights reserved. 18

19 9.16 Configuring x509v3 Authentication The TOE implements an X.509v3-based mutually-authenticated TLS secure connection with an external syslog server. When a X.509v3 certificate is presented for certificate-based authentication during a TLS handshake, the TOE validates the presented certificate, checking its chain of trust against the TOE s internal trusted store, and performs a certificate revocation check. Certificate validation includes path validation (including checking CA certificates) certificate processing (including validating the extendedkeyusage field), and extension processing (including checking the BasicConstraints extension). Verifying the chain of trust includes validating each certificate in the chain, verifying that certificate path consist of trusted CA certificates, and performing revocation checks on all certificates in the path. The TOE implements reference identifier matching according to RFC The reference identifier is specified during configuration of the TLS connection. Supported reference identifiers are DNS names for the SAN and CN. The TOE does not support certificate pinning or identifiers that include wildcards.. As part of negotiating the TLS connection, the TOE will verify that the peer certificate s Subject Alternative Name (SAN) or Common Name (CN) contains the expected reference identifier. The CN is checked only if the SAN is absent. The TOE only establishes a connection if the peer certificate is valid, trusted, has a matching reference identifier, and if the revocation check passed Generating a Certificate Signing Request Ensure that there is an active Certificate Authority setup before proceeding. ExtremeXOS generates a Certificate Signing Request (CSR), which generates private-key and CSR pair. Use the command: # configure ssl csr privkeylen <length> country <code> organization <org_name> common-name <name> 2017 Extreme Networks, Inc. All rights reserved. 19

20 This CSR appears on screen after generation or by using a separate command. The following command shows the CSR: # show ssl csr Sign the CSR with the intermediate CA s certificate using the following OpenSSL command: # openssl ca config openssl.intca1.cnf in csr/cert.csr.pem out certs/ cert.pem extentions toe-a Once the certificate is signed, it must be imported back into the TOE. Note For Common Criteria, the RSA key length is configurable, supporting both 2048-bit and 3076-bit keys. The key size is enforced in both private key/self-signed certificate pairs and private key/csr pairs Installing Trusted Certificates An active Certificate Authority must be present and operational before proceeding. The TOE supports multi-tier CA structure with intermediate CAs. A hierarchical CA structure is supported, where the Root CA signs the public certificate of a subordinate CA (intermediate CA), and that subordinate CA in turn could be used to sign other subordinate CA and leaf certificates. Each certificate in this chain, unless stated otherwise, is assumed to be trusted by all peers. To implement this, each CA s public key certificate MUST be loaded into the certificate store (aka trust store) of each peer. CA certificates must be added to the trust store individually, taking care that all chains terminate at the Root CA. Download the trusted CA certificates by running: # download ssl certificate trusted-ca rootca.cert.pem # download ssl certificate trusted-ca intca1.cert.pem 2017 Extreme Networks, Inc. All rights reserved. 20

21 View the trusted certificate store by running: # show ssl trusted-ca all Remove a CA from the trusted store by running: # unconfigure ssl certificate trusted-ca intca1.cert.pem Verify if a certificate was removed successfully by running: # show ssl trusted-ca all Configuration of OCSP Responders (OCSP Server) In order for the TOE to perform an OCSP check on a received peer certificate, the peer certificate has to have the Authority_information_Access extension set to an OCSP URI address. The TOE does not do an OCSP check for the OCSP certificate. Therefore, the OCSP responder certificate should satisfy any of the following criteria, failing which the OCSP response will be rejected: The OCSP responder certificate should be self-signed, in this case the TOE needs to have the OCSP certificate downloaded to its trust store using the command # download ssl <ip_address> trusted-ca <OCSP-selfsigned-certificate-file>, OR The OCSP responder certificate, already signed by a trusted CA, should contain the id_pkix_ocsp_nocheck extension. The OCSP self-signed certificate must have the OCSPSigning bit set in the extended key usage extension, and the KeyCertSign and digitalsignature bits set in the key usage extension, in order for the TOE to trust the OCSP self-signed certificate and for the OCSP responder to sign the OCSP responses sent to the requester Extreme Networks, Inc. All rights reserved. 21

22 Using OpenSSL to set up OCSP responders 1. As root, set up the OCSP responder for Intermediate CA1 by running: interca1 ] # openssl ocsp -port text -index index.txt -CA intermediatecadcert.pem -rkey private/intermediatecadkey.pem -rsigner intermediatecadcert.pem - nrequest 1 2. As root, set up the OCSP responder for RootCA by running: [root@server5 interca1 ] # openssl ocsp -port text -index ca.d/index.txt -CA ca.d/cacert.pem - rkey cakey/cakey.pem -rsigner ca.d/cacert.pem -nrequest Self Tests The TOE s cryptographic module performs self-tests during startup; messages from the module are displayed on the console and audit records are generated for both successful and failed tests. These selftests comply with FIPS requirements for self-testing. The module performs known-answer algorithm testing, and integrity testing. These self-tests cover all anticipated modes of failure, and therefore are sufficient such that the TSF operates correctly. Failure of any of the FIPS mode tests during the boot process will stop the start-up process and prompt the user to reload. Example Self-test pass audit log: 08/14/ :17:49.99 <Noti:SNMP.Master.EnblFIPSModeOK> Self-Test passed. FIPS mode enabled. Example Self-test failure audit log: 11/06/ :46:29.61 <Erro:exsshd.EnblFIPSModeFail> Failed to enable FIPS mode: error:2d080086:lib(45):func(128):reason(134) 2017 Extreme Networks, Inc. All rights reserved. 22

23 10 Appendix Auditable Events Requirement Auditable Events FAU_GEN.1 None None Additional Audit Record Contents Sample Audit Record FAU_GEN.2 None None FAU_STG_EXT.1 None None FCS_CKM.1 None None FCS_CKM.2 None None FCS_CKM.4 None None FCS_CKM_EXT.4 None None FCS_COP.1/DataEncryption None None FCS_COP.1/SigGen None None FCS_COP.1/Hash None None FCS_COP.1/KeyedHash None None FCS_RBG_EXT.1 None None FCS_SSHS_EXT.1 FCS_TLSC_EXT.2 FIA_AFL.1 Failure to establish an SSH session Failure to establish a TLS Session Unsuccessful login attempts limit is met or exceeded. Reason for failure Reason for failure Origin of the attempt (e.g., IP address). 06/20/ :39:00.59 <Warn:exsshd.KeyAuthFail> Key authentication failed for user ccadmin from Key invalid/not configured to the user. 08/01/ :51:06.60 <Erro:log.SyslogSSLCnctFail> Syslog SSL connection( :9011) failed: Can't connect to syslog server. connect() returned "Connection refused". 06/20/ :44:19.17 <Warn:AAA.accountLockedOut> Account for user 'ccadmin' locked out! FIA_PMG_EXT.1 None. None. FIA_UIA_EXT.1 FIA_UAU_EXT.2 All use of the identification and authentication mechanism. All use of the identification and authentication mechanism. FIA_UAU.7 None. None. FIA_X509_EXT.1/Rev Unsuccessful attempt to validate a certificate FIA_X509_EXT.2 None. None. Provided user identity, origin of the attempt (e.g., IP address). Origin of the attempt (e.g., IP address). Reason for failure Login Success: 17:55:08.54 <Info:AAA.authPass> Login passed for user admin through ssh ( ) Logout: 0/20/ :55:57.93 <Info:AAA.logout> Administrative account (admin) logout from ssh ( ) 17:55:08.54 <Info:AAA.authPass> Login passed for user admin through ssh ( ) 08/29/ :33:39.42 <Erro:log.SyslogSSLCnctFail> Syslog SSL connection( :6529) failed: Can't connect to syslog server with SSL. SSL_connect() returned "error: :ssl routines:ssl3_get_server_certificate:certific ate verify failed". FIA_X509_EXT.3 None. None. FMT_MOF.1/ManualUpdate Any attempt to initiate a manual update None. 06/20/ :48:01.58 <Noti:cli.CmdNotPmt> User user: This user does not have permissions for this command: download image onie xos 2017 Extreme Networks, Inc. All rights reserved. 23

24 Requirement Auditable Events Additional Audit Record Contents Sample Audit Record 06/20/ :50:13.11 <Noti:EPM.install_status> User admin: Image installation finished with status success. FMT_MTD.1/CoreData All management activities of TSF data. None. 06/20/ :49:57.87 <Noti:EPM.Upgrade.Strt> User admin: Image upgrade has started. 06/20/ :49:57.77 <Noti:EPM.DnldStatus> User admin: Download of image finished with status success; Image integrity check passed. FMT_SMF.1 None. None. FMT_SMR.2 None. None. FPT_SKP_EXT.1 None. None. FPT_APW_EXT.1 None. None. FPT_TST_EXT.1 None. None. FPT_TUD_EXT.1 Initiation of update; result of the update attempt (success or failure). None. 09/04/ :32:14.92 <Info:EPM.InstlImgInvSignCnclUser> Installing an image with an invalid signature was cancelled by user "admin" 09/04/ :32:11.95 <Noti:EPM.DnldStatus> User admin: Download of image finished with status warning - Image is not digitally signed. 09/04/ :31:25.31 <Noti:EPM.Upgrade.DnldImg> User admin: Download image from hostname ip address file name mpitchaiah/summitx NoSignature.xos VR VR-Mgmt 09/04/ :30:33.24 <Noti:EPM.install_status> User admin: Image installation finished with status succes FPT_STM_EXT.1 FTA_SSL_EXT.1 (if lock the session is selected) Discontinuous changes to time either Administrator actuated or changed via an automated process. (Note that no continuous changes to time need to be logged. See also application note on FPT_STM_EXT.1) Any attempts at unlocking of an interactive session. For discontinuous changes to time: The old and new values for the time. Origin of the attempt to change time for success and failure (e.g., IP address). None. 18:05:22.35 <Noti:DM.Notice> Setting time to Mon Nov 20 12:12: /20/ :12:12.21 <Info:AAA.authPass> Login passed for user admin through serial 06/20/ :12:08.80 <Info:AAA.logout> Administrative account (admin) logout from serial FTA_SSL_EXT.1 (if terminate the session is selected) The termination of a remote session by the session locking mechanism. None. 06/20/ :15:40.90 <Info:AAA.logout> Administrative account (admin) logout from telnet ( ) FTA_SSL.3 The termination of a remote session by the session locking mechanism. None. 06/20/ :20:31.98 <Info:AAA.logout> Administrative account (admin) logout from ssh ( ) 2017 Extreme Networks, Inc. All rights reserved. 24

25 Requirement FTA_SSL.4 Auditable Events The termination of an interactive session. Additional Audit Record Contents None. FTA_TAB.1 None. None. FTP_ITC.1 Initiation of the trusted channel. Termination of the trusted channel. Failure of the trusted channel functions. Initiation of the trusted channel. Identification of the initiator and target of failed trusted channels establishment attempt. Sample Audit Record 06/20/ :22:14.52 <Info:AAA.logout> Administrative account (admin) logout from ssh ( ) 08/30/ :20:59.42 <Noti:log.SyslogSSLCnctEstb> Syslog SSL connection( :6514) established. 08/01/ :51:43.57 <Noti:log.SyslogSSLCnctTerm> Syslog SSL connection( :6514) terminated. 08/30/ :33:37.90 <Erro:log.SyslogSSLOCSPFail> Syslog SSL connection( :6514) failed: OCSP revocation check failed at depth 0. OCSP_RevocationCheck() returned "No response from all available OCSP responders". 03/23/ :46:41.73 <Info:AAA.LogSsh> Msg from Master : Did key authentication for user ccadmin ( ) 03/23/ :46:41.73 <Info:AAA.LogSsh> Msg from Master : Login passed for user ccadmin through ssh ( ) FTP_TRP.1/Admin Termination of the trusted channel. Failures of the trusted path functions. None. 03/23/ :46:41.73 <Info:AAA.LogSsh> Msg from Master : Found valid key for user ccadmin 06/20/ :26:24.59 <Info:AAA.logout> Administrative account (admin) logout from ssh ( ) 07/14/ :36:34.30 <Warn:exsshd.KeyAuthFail> Key authentication failed for user ccadmin from Key invalid/not configured to the user Extreme Networks, Inc. All rights reserved. 25