TR 33.926 [4], clause 5.3.6.3, Weak cryptographic algorithms

Protection at the transport layer

TS 33.501 [10], clause 5.9.2.1, clause 13.1, clause 13.3.2

NF Service Request and Response procedure supports mutual authentication between NF consumer and NF producer as specified in TS 33.501 [10], clause 5.9.2.1 .

All network functions supports TLS. Network functions support both server-side and client-side certificates. The TLS profile follows the profile given in Annex E of TS 33.310 [9] with the restriction to be compliant with the profile given by HTTP/2 as defined in RFC 7540 [11] as specified in TS 33.501 [10], clause 13.1.

Authentication between network functions within one PLMN uses one of the following methods:

• If the PLMN uses protection at the transport layer as described in clause 13.1, authentication provided by the transport layer protection solution is used for authentication between NFs as specified in TS 33.501 [10], clause 13.3.2.

Verify that TLS protocol for NF mutual authentication and NF transport layer protection is implemented in the network products based on the profile required.

Network product documentation containing information about supported TLS protocol and certificates is provided by the vendor.

A peer implementing the TLS protocol configured by the vendor shall be available.

The tester shall base the tests on the profile defined by 3GPP in Annex E of TS 33.310 [9] with the restriction that it shall be compliant with the profile given by HTTP/2 as defined in RFC 7540 [11].

1. The tester shall check that compliance with the TLS profile can be inferred from detailed provisions in the network product documentation.

2. The tester shall establish a secure connection between the network product under test and the peer and verify that all TLS protocol versions and combinations of cryptographic algorithms that are mandated by the TLS profile are supported by the network product under test.

3. The tester shall try to establish a secure connection between the network product under test and the peer and verify that this is not possible when the peer only offers a feature, including protocol version and combination of cryptographic algorithms, that is forbidden by the TLS profile.

Expected can Results:

• The network product under test and the peer establish TLS if the TLS profiles used by the peer are compliant with the profile requirements in TS 33.310 [9] Annex E and RFC 7540 [11].

• The network product under test and the peer fail to establish TLS if the TLS profiles used by the peer are forbidden in TS 33.310 [9] Annex E or RFC 7540 [11].

Provide evidence of the check of the product documentation in plain text. Save the logs and the communication flow in a .pcap file.

TR 33.926 [4], clause 5.3.6.3, Weak cryptographic algorithms

Protection at the transport layer

TS 33.501 [10], clause 5.9.2.1, clause 13.1, clause 13.3.2

If the PLMN uses protection at the transport layer as described in clause 13.1, authentication provided by the transport layer protection solution shall be used for authentication between NFs."

Verify that TLS protocol for NF mutual authentication and NF transport layer protection is implemented in the network products based on the profile required.

Network product documentation containing information about supported TLS protocol and certificates is provided by the vendor.

A peer implementing the TLS protocol configured by the vendor shall be available.

The tester shall base the tests on the profile defined by 3GPP in Annex E of TS 33.310 [9] with the restriction that it shall be compliant with the profile given by HTTP/2 as defined in RFC 7540 [11].

1. The tester shall check that compliance with the TLS profile can be inferred from detailed provisions in the network product documentation.

2. The tester shall establish a secure connection between the network product under test and the peer and verify that all TLS protocol versions and combinations of cryptographic algorithms that are mandated by the TLS profile are supported by the network product under test.

3. The tester shall try to establish a secure connection between the network product under test and the peer and verify that this is not possible when the peer only offers a feature, including protocol version and combination of cryptographic algorithms, that is forbidden by the TLS profile.

Provide evidence of the check of the product documentation in plain text. Save the logs and the communication flow in a .pcap file.

TR 33.926 [4], clause 6.3.3.1, Incorrect Verification of Access Tokens

Authorization token verification failure handling within one PLMN

TS 33.501 [10], clause 13.4.1.1

According to TS 33.501 [10], clause 13.4.1.1, the NF Service producer verifies the access token as follows:

• The NF Service producer ensures the integrity of the access token by verifying the signature using NRF's public key or checking the MAC value using the shared secret. If integrity check is successful, the NF Service producer verifies the claims in the access token as follows:

NOTE: Void.

• It checks that the audience claim in the access token matches its own identity or the type of NF service producer. If a list of NSSAIs or list of NSI IDs is present, the NF service producer checks that it serves the corresponding slice(s).

• If an NF Set ID present, the NF Service Producer checks the NF Set ID in the claim matches its own NF Set ID.

• If the access token contains "additional scope" information (i.e. allowed resources and allowed actions (service operations) on the resources), it checks that the additional scope matches the requested service operation.

• If scope is present, it checks that the scope matches the requested service operation.

• It checks that the access token has not expired by verifying the expiration time in the access token against the current data/time.

• If the verification is successful, the NF Service producer executes the requested service and responds back to the NF Service consumer. Otherwise it replies based on Oauth 2.0 error response defined in RFC 6749 [12]. The NF service consumer optionally stores the received token(s). Stored tokens may be re-used for accessing service(s) from producer NF type listed in claims (scope, audience) during their validity time.

Verify that the NF service producer does not grant service access if the verification of authorization token from a NF service consumer in the same PLMN fails.

• Test environment with a NF service consumer.

• The NF service consumer may be simulated.

• The network product under test has already mutually authenticated with the NF service consumer.

• The tester shall have access to the interface between the NF service consumer and the network product under test.

• The tester has the NRF's private key or the shared key.

• The network product under test is preconfigured with the NRF's public key or the shared key.

The network product under test receives the access token sent from the NF service consumer, verifies the access token based on Oauth 2.0.

Test Cases 1~4 are tests on failure handling by the network product under test when the mandatory claims in access token failed verification.

Test Case 1: Verification failure of the access token integrity

1. The tester computes an access token correctly, except that the signature or the MAC is incorrect, e.g., the signature or the MAC is randomly selected, and then includes the access token in the NF Service Request sent from the NF service consumer to the network product under test.

2. The integrity verification of the access token by the network product under test fails.

Test Case 2: Incorrect audience claim in the access token

1. The tester computes an access token correctly, except that the audience claim is incorrect, i.e., the audience claim in the access token does not match the identity or the type of the network product under test, and then includes the access token in the NF Service Request sent from NF service consumer to the network product under test.

2. The network product under test verifies that the integrity of the access token is valid. However, the audience claim in the access token does not match its identity or type.

Test Case 3: Incorrect scope claim in the access token

1. The tester computes an access token correctly, except that the scope is incorrect, i.e., the scope does not match the requested service operation, and then includes the access token in the NF Service Request sent from the NF service consumer to the network product under test.

2. The network product under test verifies that the integrity of the access token and the audience claim are valid. However, the scope does not match the requested service operation.

Test Case 4: Expired access token

1. The tester computes an access token correctly, except that the expiration time has expired against the current data/time, and then includes the access token in the NF Service Request sent from the NF service consumer to the network product under test.

2. The network product under test verifies that the integrity of the access token, the audience and scope claims are all valid. However, the expiration time in the access token has expired against the current data/time.

Test Cases 5~8 are tests on failure handling by the network product under test when the optional claims in access token failed verification.

NOTE: The test cases below only apply to the NFs which support identifying and understanding the optioanl claims in the received access token.

Test Case 5: Incorrect list of S-NSSAIs in the access token

1. The tester computes an access token correctly, except that the list of S-NSSAIs is incorrect, i.e., the network product under test does not serve the slices indicated in the list of S-NSSAIs, and then includes the access token in the NF Service Request sent from NF service consumer to the network product under test.

2. The network product under test verifies that the integrity of the access token, the audience, scope and expiration time claims are all valid. Then it further checks the list of S--NSSAIs included in the access token.

Test Case 6: Incorrect list of NSIs in the access token

1. The tester computes an access token correctly, except that the list of NSIs is incorrect, i.e., the network product under test does not serve the slices indicated in the list of NSIs, and then includes the access token in the NF Service Request sent from NF service consumer to the network product under test.

2. The network product under test verifies that the integrity of the access token, the audience, scope and expiration time claims are all valid. Then it further checks the list of NSIs included in the access token.

Test Case 7: Incorrect NF Set ID in the access token

1. The tester computes an access token correctly, except that the NF Set ID is incorrect, i.e. the NF Set ID in the claim does not match the NF Set ID of the network product under test, and then includes the access token in the NF Service Request sent from NF service consumer to the network product under test.

2. The network product under test verifies that the integrity of the access token, the audience, scope and expiration time claims are all valid. Then it further checks the NF Set ID included in the access token.

Test Case 8: Incorrect additional scope in the access token

1. The tester computes an access token correctly, except that the additional scope information is incorrect, i.e. the allowed resources and allowed actions on the resources do not match the requested service operations, and then includes the access token in the NF Service Request sent from the NF service consumer to the network product under test.

2. The network product under test verifies that the integrity of the access token, the audience, scope and expiration time claims are all valid. Then it further checks the additional scope included in the access token.

For test cases 1~4 on verification failure of mandatory claims in the access token, the network product under test rejects the NF service consumer's service request based on Oauth 2.0 error response defined in RFC 6749 [12].

For test cases 5~8 on verification failure of optional claims in the access token, if the network product under test understands these optional claims (list of S-NSSAIs, list of NSIs, NF Set ID, additional scope), it rejects the NF service consumer's service request based on Oauth 2.0 error response defined in RFC 6749 [12].

Evidence suitable for the interface, e.g., Screenshot containing the operational results.

TR 33.926 [4], clause 6.3.3.1, Incorrect Verification of Access Tokens

NOTE: Void.

• It checks that the audience claim in the access token matches its own identity or the type of NF service producer. If a list of NSSAIs or list of NSI IDs is present, the NF service producer shall check that it serves the corresponding slice(s).

• If an NF Set ID present, the NF Service Producer shall check the NF Set ID in the claim matches its own NF Set ID.

• If the access token contains "additional scope" information (i.e. allowed resources and allowed actions (service operations) on the resources), it checks that the additional scope matches the requested service operation.

• If scope is present, it checks that the scope matches the requested service operation.

• It checks that the access token has not expired by verifying the expiration time in the access token against the current data/time.

• If the verification is successful, the NF Service producer shall execute the requested service and responds back to the NF Service consumer. Otherwise it shall reply based on Oauth 2.0 error response defined in RFC 6749 [43]. The NF service consumer may store the received token(s). Stored tokens may be re-used for accessing service(s) from producer NF type listed in claims (scope, audience) during their validity time.

Verify that the NF service producer does not grant service access if the verification of authorization token from a NF service consumer in the same PLMN fails.

• Test environment with a NF service consumer.

• The NF service consumer may be simulated.

• The network product under test has already mutually authenticated with the NF service consumer.

• The tester shall have access to the interface between the NF service consumer and the network product under test.

• The tester has the NRF's private key or the shared key.

• The network product under test is preconfigured with the NRF's public key or the shared key.

The network product under test receives the access token sent from the NF service consumer, verifies the access token based on Oauth 2.0.

Test Cases 1~4 are tests on failure handling by the network product under test when the mandatory claims in access token failed verification.

Test Case 1: Verification failure of the access token integrity

1. The tester computes an access token correctly, except that the signature or the MAC is incorrect, e.g., the signature or the MAC is randomly selected, and then includes the access token in the NF Service Request sent from the NF service consumer to the network product under test.

2. The integrity verification of the access token by the network product under test fails.

Test Case 2: Incorrect audience claim in the access token

1. The tester computes an access token correctly, except that the audience claim is incorrect, i.e., the audience claim in the access token does not match the identity or the type of the network product under test, and then includes the access token in the NF Service Request sent from NF service consumer to the network product under test.

2. The network product under test verifies that the integrity of the access token is valid. However, the audience claim in the access token does not match its identity or type.

Test Case 3: Incorrect scope claim in the access token

1. The tester computes an access token correctly, except that the scope is incorrect, i.e., the scope does not match the requested service operation, and then includes the access token in the NF Service Request sent from the NF service consumer to the network product under test.

2. The network product under test verifies that the integrity of the access token and the audience claim are valid. However, the scope does not match the requested service operation.

Test Case 4: Expired access token

1. The tester computes an access token correctly, except that the expiration time has expired against the current data/time, and then includes the access token in the NF Service Request sent from the NF service consumer to the network product under test.

2. The network product under test verifies that the integrity of the access token, the audience and scope claims are all valid. However, the expiration time in the access token has expired against the current data/time.

Test Cases 5~8 are tests on failure handling by the network product under test when the optional claims in access token failed verification.

NOTE: The test cases below only apply to the NFs which support identifying and understanding the optioanl claims in the received access token.

Test Case 5: Incorrect list of S-NSSAIs in the access token

1. The tester computes an access token correctly, except that the list of S-NSSAIs is incorrect, i.e., the network product under test does not serve the slices indicated in the list of S-NSSAIs, and then includes the access token in the NF Service Request sent from NF service consumer to the network product under test.

2. The network product under test verifies that the integrity of the access token, the audience, scope and expiration time claims are all valid. Then it further checks the list of S--NSSAIs included in the access token.

Test Case 6: Incorrect list of NSIs in the access token

1. The tester computes an access token correctly, except that the list of NSIs is incorrect, i.e., the network product under test does not serve the slices indicated in the list of NSIs, and then includes the access token in the NF Service Request sent from NF service consumer to the network product under test.

2. The network product under test verifies that the integrity of the access token, the audience, scope and expiration time claims are all valid. Then it further checks the list of NSIs included in the access token.

Test Case 7: Incorrect NF Set ID in the access token

1. The tester computes an access token correctly, except that the NF Set ID is incorrect, i.e. the NF Set ID in the claim does not match the NF Set ID of the network product under test, and then includes the access token in the NF Service Request sent from NF service consumer to the network product under test.

2. The network product under test verifies that the integrity of the access token, the audience, scope and expiration time claims are all valid. Then it further checks the NF Set ID included in the access token.

Test Case 8: Incorrect additional scope in the access token

1. The tester computes an access token correctly, except that the additional scope information is incorrect, i.e. the allowed resources and allowed actions on the resources do not match the requested service operations, and then includes the access token in the NF Service Request sent from the NF service consumer to the network product under test.

2. The network product under test verifies that the integrity of the access token, the audience, scope and expiration time claims are all valid. Then it further checks the additional scope included in the access token.

For test cases 1~4 on verification failure of mandatory claims in the access token, the network product under test rejects the NF service consumer's service request based on Oauth 2.0 error response defined in RFC 6749 [12].

For test cases 5~8 on verification failure of optional claims in the access token, if the network product under test understands these optional claims (list of S-NSSAIs, list of NSIs, NF Set ID, additional scope), it rejects the NF service consumer's service request based on Oauth 2.0 error response defined in RFC 6749 [12].

Evidence suitable for the interface, e.g., Screenshot containing the operational results.

TR 33.926 [4], clause 6.3.3.1, Incorrect Verification of Access Tokens

NOTE: The test case below only applies to the NFs which support identifying and understanding the producerPlmnId claim.

Authorization token verification failure handling in different PLMNs

TS 33.501 [10], clause 13.4.1.2

The NF service producer checks that the home PLMN ID of audience claim in the access token matches its own PLMN identity.

Verify that the NF service producer does not grant service access if the verification of authorization token from a NF service consumer in a different PLMN fails.

• Test environment with a NF service consumer and two SEPPs (one cSEPP, one pSEPP).

• The NF service consumer and SEPPs may be simulated.

• The network product under test has already mutually authenticated with the NF service consumer in a different PLMN via the SEPPs.

• The tester has the NRF's private key or the shared key.

• The network product under test is preconfigured with the NRF's public key or the shared key.

• The tester shall have access to the interfaces of the NF service consumer and the network product under test.

The network product under test receives the access token sent from the NF service consumer, verifies the access token in accordance with the execution steps in 4.2.2.2.3.1, with the following additional test cases:

Test Case 1: incorrect PLMN ID of the NF service producer in the access token

1. The test computes an access token correctly, except that the PLMN ID in the producerPlmnId claim of the access token is empty or different from the home PLMN ID of the network product under test, and then includes the access token in the NF Service Request sent from the NF service consumer to the network product under test through the SEPPs.

2. The network product under test receives the access token sent from the NF service consumer through the SEPPs, verifies that the PLMN ID in the producerPlmnId claim of the access token is different from its own home PLMN identity.

Test Case 2: absent PLMN ID of the NF service producer in the access token

1. The test computes an access token correctly, except that no producerPlmnId claim is included in the access token, and then includes the access token in the NF Service Request sent from the NF service consumer to the network product under test through the SEPPs.

2. The network product under test receives the access token sent from the NF service consumer through the SEPPs, verifies that the access token is not a token to be used by the NF service consumer in a different PLMN, based on the absence of PLMN ID of the NF service producer in the access token.

For both test cases 1 and 2, the network product under test rejects the NF service consumer's service request based on Oauth 2.0 error response defined in RFC 6749 [12].

Evidence suitable for the interface, e.g., Screenshot containing the operational results.

TR 33.926 [4], clause 6.3.3.1, Incorrect Verification of Access Tokens

NOTE: The test case below only applies to the NFs which support identifying and understanding the producerPlmnId claim.

Authorization token verification failure handling in different PLMNs

TS 33.501 [10], clause 13.4.1.2

Verify that the NF service producer does not grant service access if the verification of authorization token from a NF service consumer in a different PLMN fails.

• Test environment with a NF service consumer and two SEPPs (one cSEPP, one pSEPP).

• The NF service consumer and SEPPs may be simulated.

• The network product under test has already mutually authenticated with the NF service consumer in a different PLMN via the SEPPs.

• The tester has the NRF's private key or the shared key.

• The network product under test is preconfigured with the NRF's public key or the shared key.

• The tester shall have access to the interfaces of the NF service consumer and the network product under test.

Test Case 1: incorrect PLMN ID of the NF service producer in the access token

1. The test computes an access token correctly, except that the PLMN ID in the producerPlmnId claim of the access token is empty or different from the home PLMN ID of the network product under test, and then includes the access token in the NF Service Request sent from the NF service consumer to the network product under test through the SEPPs.

2. The network product under test receives the access token sent from the NF service consumer through the SEPPs, verifies that the PLMN ID in the producerPlmnId claim of the access token is different from its own home PLMN identity.

Test Case 2: absent PLMN ID of the NF service producer in the access token

1. The test computes an access token correctly, except that no producerPlmnId claim is included in the access token, and then includes the access token in the NF Service Request sent from the NF service consumer to the network product under test through the SEPPs.

2. The network product under test receives the access token sent from the NF service consumer through the SEPPs, verifies that the access token is not a token to be used by the NF service consumer in a different PLMN, based on the absence of PLMN ID of the NF service producer in the access token.

For both test cases 1 and 2, the network product under test rejects the NF service consumer's service request based on Oauth 2.0 error response defined in RFC 6749 [12].

Evidence suitable for the interface, e.g., Screenshot containing the operational results.

TR 33.926 [4], clause 6.3.x.1, Incorrect validation of client credentials assertion

Note: The following test case only applies if the NF under test implements verification of client credentials assertions.

Correct handling of client credentials assertion validation failure

TS 33.501 [10], clause 13.3.8.3

The verification of the Client credentials assertion is performed by the receiving node, i.e., NRF or NF Service Producer in the following way:

• It validates the signature of the JWS as described in RFC 7515 [16].

• If validates the timestamp (iat) and/or the expiration time (exp) as specified in RFC 7519 [17].

If the receiving node is the NR F, the NRF validates the timestamp (iat) and the expiration time (exp).

If the receiving node is the NF Service Producer, the NF service Producer validates the expiration time and it may validate the timestamp.

• It checks that the audience claim in the the client credentials assertion matches its own type.

It verifies that the NF instance ID in the client credentials assertion matches the NF instance ID in the public key certificate used for signing the assertion.

Verify that the NF under test correctly handles client credentials assertion validation failure.

Editor's Note: This test case applies for Rel-16 NFs. The formulation for indicating the applicable release may need to be updated.

• Test environment with a consumer NF and a SCP, which may be simulated. (Potentially simulated) consumer NF and (potentially simulated) SCP can be combined for the testing purpose.

• The NF under test is preconfigured with the certificate of the consumer NF.

• The NF under test is configured to require assertions for NF consumer authentication for at least one of its services.

• The NF under test has implemented the client credentials assertion (CCA) authentication method as specified in TS 33.501 [10], clause 13.3.8.3.

• The tester has the private key of the consumer NF.

• The tester has access to the interface between the consumer NF and the NF under test.

Test Case 1: Failed verification of the client credentials assertion integrity

1. The tester computes a client credentials assertion correctly, except that the signature is incorrect, and then includes the client credentials assertion in the service request sent from the consumer NF to the NF under test via the SCP.

2. The integrity verification of the client credentials assertion by the NF under test fails.

Test Case 2: Incorrect audience claim in the client credentials assertion

1. The tester computes a client credentials assertion correctly, except that the audience claim is incorrect, i.e., the audience claim in the client credentials assertion does not match the type of the NF under test, and then includes the signed client credentials assertion in the service request sent from the consumer NF to the NF under test via the SCP.

2. The NF under test verifies that the audience claim in the client credentials assertion does not match its type.

Test Case 3: Expired client credentials assertion

1. The tester computes an access token correctly, except that the expiration time (exp) has expired against the current time, and then includes the signed client credentials assertion in the service request sent from the consumer NF to the NF under test via the SCP.

2. The NF under test verifies that the expiration time in the client credentials assertion has expired against the current time.

For test cases 1~3, the NF under test rejects the consumer NF's service request and sends back an error message.

Editor's Note: the result needs to be aligned with the relevant error handling description to be added in TS 29.500.

Evidence suitable for the interface, e.g. screenshot containing the operational results.

TR 33.926 [4], clause 6.3.x.1, Incorrect validation of client credentials assertion

Note: The following test case only applies if the NF under test implements verification of client credentials assertions.

Correct handling of client credentials assertion validation failure

• It validates the signature of the JWS as described in RFC 7515 [45].

• If validates the timestamp (iat) and/or the expiration time (exp) as specified in RFC 7519 [44].

If the receiving node is the NR F, the NRF validates the timestamp (iat) and the expiration time (exp).

If the receiving node is the NF Service Producer, the NF service Producer validates the expiration time and it may validate the timestamp.

• It checks that the audience claim in the the client credentials assertion matches its own type.

Verify that the NF under test correctly handles client credentials assertion validation failure.

Editor's Note: This test case applies for Rel-16 NFs. The formulation for indicating the applicable release may need to be updated.

• Test environment with a consumer NF and a SCP, which may be simulated. (Potentially simulated) consumer NF and (potentially simulated) SCP can be combined for the testing purpose.

• The NF under test is preconfigured with the certificate of the consumer NF.

• The NF under test is configured to require assertions for NF consumer authentication for at least one of its services.

• The NF under test has implemented the client credentials assertion (CCA) authentication method as specified in TS 33.501 [10], clause 13.3.8.3.

• The tester has the private key of the consumer NF.

• The tester has access to the interface between the consumer NF and the NF under test.

Test Case 1: Failed verification of the client credentials assertion integrity

1. The tester computes a client credentials assertion correctly, except that the signature is incorrect, and then includes the client credentials assertion in the service request sent from the consumer NF to the NF under test via the SCP.

2. The integrity verification of the client credentials assertion by the NF under test fails.

Test Case 2: Incorrect audience claim in the client credentials assertion

1. The tester computes a client credentials assertion correctly, except that the audience claim is incorrect, i.e., the audience claim in the client credentials assertion does not match the type of the NF under test, and then includes the signed client credentials assertion in the service request sent from the consumer NF to the NF under test via the SCP.

2. The NF under test verifies that the audience claim in the client credentials assertion does not match its type.

Test Case 3: Expired client credentials assertion

1. The tester computes an access token correctly, except that the expiration time (exp) has expired against the current time, and then includes the signed client credentials assertion in the service request sent from the consumer NF to the NF under test via the SCP.

2. The NF under test verifies that the expiration time in the client credentials assertion has expired against the current time.

For test cases 1~3, the NF under test rejects the consumer NF's service request and sends back an error message.

Editor's Note: the result needs to be aligned with the relevant error handling description to be added in TS 29.500.

Evidence suitable for the interface, e.g. screenshot containing the operational results.

TR 33.926 [4]

Unauthorized Viewing

In accordance with industry best practice.

When the system is not under maintenance, there shall be no system function that reveals confidential system internal data in the clear to users and administrators. Such functions could be, for example, local or remote O&M CLI or GUI, logging messages, alarms, configuration file exports etc. Confidential system internal data contains authentication data (i.e. PINs, cryptographic keys, passwords, cookies) as well as system internal data that is not required for systems administration and could be of advantage to attackers (i.e. stack traces in error messages).

Verify that no system function reveals sensitive data in the clear

The vendor shall provide documentation describing how confidential system internal information that could possibly be revealed in clear-text is handled by system functions.

A list of all system functions in the network product, information on how to enable and execute them should be provided as a part of the vendor's documentation. A system function is every function implemented in the network product needed by the services/functionalities provided by the network product itself.

Execute the following steps:

1. Review the documentation provided by the vendor describing how confidential system internal information is handled by system functions.

2. The tester checks whether any system functions as described in the product documentation (e.g. local or remote O&M CLI or GUI, logging messages, alarms, error messages, configuration file exports, stack traces) reveal any confidential system internal data in the clear (for example, passphrases).

There should be no confidential system internal data revealed in the clear by any system function.

Evidence suitable for the interface, e.g. screenshot containing the operational results.

Unauthorized Viewing

Verify that no system function reveals sensitive data in the clear

The vendor shall provide documentation describing how confidential system internal information that could possibly be revealed in clear-text is handled by system functions.

A list of all system functions in the network product, information on how to enable and execute them should be provided as a part of the vendor's documentation. A system function is every function implemented in the network product needed by the services/functionalities provided by the network product itself.

Execute the following steps:

1. Review the documentation provided by the vendor describing how confidential system internal information is handled by system functions.

2. The tester checks whether any system functions as described in the product documentation (e.g. local or remote OAM CLI or GUI, logging messages, alarms, error messages, configuration file exports, stack traces) reveal any confidential system internal data in the clear (for example, passphrases).

There should be no confidential system internal data revealed in the clear by any system function.

Evidence suitable for the interface, e.g. screenshot containing the operational results.

TR 33.926 [4]

Protecting data and information in storage

In accordance with industry best practice

For sensitive data in (persistent or temporary) storage read access rights shall be restricted. Files of a system that are needed for the functionality shall be protected against manipulation.

In addition, the following rules apply for:

• Systems that need access to identification and authentication data in the clear, e.g. in order to perform an authentication. Such systems shall not store this data in the clear, but scramble or encrypt it by implementation-specific means.

• Systems that do not need access to sensitive data (e.g. user passwords) in the clear. Such systems shall hash this sensitive data with a non-broken cryptographic hash algorithm and use mechanisms to make dictionary attacks more difficult and prevent hash collisions when using identical sensitive data. A common mechanism is e.g., using a unique, random salt per record.

NOTE 1: A "non-broken" cryptographic hash algorithm is a cryptographic hash algorithm without publicly available/published vulnerabilities.

• Stored files on the network product: examples for protection against manipulation are the use of checksum or cryptographic methods.

Verify that Password storage uses a non-broken one-way cryptographic hash algorithm.

• The tester can access the storage of own user account password.

• The tester has privileges to change the password.

• The original password is P1.

• New passwords are represented by the variable P2.

1. The tester accesses the storage where the result of P1 is, and the corresponding hash value is recorded as A

2. The tester changes the password with P2, then the tester records the storage hash value of the new password as B

3. The tester repeats the step 2 to get other records with the following requirements for password P2:

4. at least one new password P2 differs from P1 by exactly one bit

5. at least one new password P2 shall be the same as P1

6. at least one new password P2 shall have a different length compared to P1

7. The tester verifies whether all the records comply with the characteristic of one-way cryptographic hash result.

a. All collected records contain different hash values, even if the corresponding passwords were identical.

NOTE 2: Even if P1 and P2 only differ by one bit, the resulting hash values should differ substantially. (Bit independence criterion)

b. The bit length of the hash values is fixed and independent from the password length.

c. The hash value does not contain any information that could be used for password disclosure. (e.g. contains part of the password in plain text or some sort of password length indicator)

NOTE 3: Depending on the implementation the recorded hash values A and B could be stored with their salt combined in some way (e.g. salt is prefix or suffix of hash value). The tester needs to exclude the salt when comparing records

All records comply with the characteristic of one-way cryptographic hash result.

Evidence suitable for the interface, e.g. screenshot containing the operation results.

Protecting data and information in storage

For sensitive data in (persistent or temporary) storage read access rights shall be restricted. Files of a system that are needed for the functionality shall be protected against manipulation.

In addition, the following rules apply for:

• Systems that need access to identification and authentication data in the clear, e.g. in order to perform an authentication. Such systems shall not store this data in the clear, but scramble or encrypt it by implementation-specific means.

• Systems that do not need access to sensitive data (e.g. user passwords) in the clear. Such systems shall hash this sensitive data .

• Stored files on the network product: examples for protection against manipulation are the use of checksum or cryptographic methods.

• The tester can access the storage of own user account password.

• The tester has privileges to change the password.

• The original password is P1.

New passwords are represented by the variable P2.

1. The tester accesses the storage where the result of P1 is, and the corresponding hash value is recorded as A

2. The tester changes the password with P2, then the tester records the storage hash value of the new password as B

3. The tester repeats the step 2 to get other records.

4. The tester verifies whether all the records comply with the characteristic of one-way hash result.

Evidence suitable for the interface, e.g. screenshot containing the operation results.

TR 33.926 [4]

Protecting data and information in transfer

In accordance with industry best practice

• Usage of cryptographically protected network protocols is required.

• The transmission of data with a need of protection shall use industry standard network protocols with sufficient security measures and industry accepted algorithms. In particular, a protocol version without known vulnerabilities or a secure alternative shall be used.

Verify the mechanisms implemented to protect data and information in transfer to and from the Network Product's O&M interface.

NOTE: The test is limited to the O&M interface although the requirement does not have this limitation because the protection of standardised interfaces will be covered by regular interoperability testing and the proprietary use of HTTPS is covered in clause 4.2.5.1.

Network product documentation containing information about supported O&M protocols is provided by the vendor,

A peer implementing the security protocol configured by the vendor (e.g SSH client supporting SSHv2 or HTTPS client) shall be available.

Network product documentation stating which security protocols for protection of data in transit are implemented and which profiles in TS 33.310 [9] and TS 33.210 [15] are applicable is provided by the vendor

For TLS/DTLS, the tester shall base the tests on the profile defined by 3GPP in TS 33.310 [9] and TS 33.210 [15]. For IKE and IPsec, the tester shall base the tests on the profile defined by 3GPP in TS 33.210 [15]. For protocols, for which 3GPP did not define a security profile, e.g. SSH, the tester shall base the tests on a widely recognised and publicly available security profile.

1. The tester shall check that compliance with the selected security profile can be inferred from detailed provisions in the product documentation.

2. The tester shall check that the default security parameters are the same as those stated in the product documentation.

3. The tester shall establish a secure connection between the network product and the peer and verify that all protocol versions and combinations of cryptographic algorithms that are mandated by the security profile are supported by the network product and the network product does not use the deprecated or unsecure protocol versions and algorithms.

4. The tester shall try to establish a secure connection between the network product and the peer and verify that this is not possible when the peer only offers a feature, including protocol version and combination of cryptographic algorithms, that is forbidden by the security profile.

The traffic is properly protected, and insecure options are not accepted by the Network Product.

Provide evidence of the check of the product documentation in plain text. Save the logs and the communication flow in a .pcap file.

• Usage of cryptographically protected network protocols is required.

• The transmission of data with a need of protection shall use industry standard network protocols with sufficient security measures and industry accepted algorithms. In particular, a protocol version without known vulnerabilities or a secure alternative shall be used.

NOTE: The test is limited to the OAM interface although the requirement does not have this limitation because the protection of standardised interfaces will be covered by regular interoperability testing and the proprietary use of HTTPS is covered in clause 4.2.5.1.

A peer implementing the security protocol configured by the vendor (e.g SSH client supporting SSHv2 or HTTPS client) shall be available.

Network product documentation stating which security protocols for protection of data in transit are implemented and which profiles in TS 33.310 [9] and TS 33.210 [15] are applicable is provided by the vendor

For TLS/DTLS, the tester shall base the tests on the profile defined by 3GPP in TS 33.310 [9] and TS 33.210 [15]. For IKE and IPsec, the tester shall base the tests on the profile defined by 3GPP in TS 33.210 [15]. For protocols, for which 3GPP did not define a security profile, e.g. SSH, the tester shall base the tests on a widely recognised and publicly available security profile.

1. The tester shall check that compliance with the selected security profile can be inferred from detailed provisions in the product documentation.

2. The tester shall establish a secure connection between the network product and the peer and verify that all protocol versions and combinations of cryptographic algorithms that are mandated by the security profile are supported by the network product.

3. The tester shall try to establish a secure connection between the network product and the peer and verify that this is not possible when the peer only offers a feature, including protocol version and combination of cryptographic algorithms, that is forbidden by the security profile.

The traffic is properly protected, and insecure options are not accepted by the Network Product.

Provide evidence of the check of the product documentation in plain text. Save the logs and the communication flow in a .pcap file.

TR 33.926 [4]

Logging access to personal data

In accordance with industry best practice

In some cases access to personal data in clear text might be required. If such access is required, access to this data shall be logged, and the log shall contain who accessed what data without revealing personal data in clear text. When for practical purposes such logging is not available, a coarser grain logging is allowed.

In some cases, the personal data stored in the log files may allow the direct identification of a subscriber. In such cases, the revealed personal information shall not expose the subscriber to any kind of privacy violation.

Verify that in cases where a network product presents personal data in clear text, access attempts to such data are logged and the log information includes the user identity that has accessed the data. The test case also verifies that the personal data itself is not included in clear text in the log.

A document which provides a description of where personal data in clear text is accessible on the network product, how it can be accessed, and details of where such access attempts are logged and how to view these logs.

• The tester verifies, for cases where personal data is accessible in clear text, that attempts to access it are recorded in a log, that the log includes the identity of the user that has attempted to access the data, and that the log does not include the actual personal data in clear-text.

• The tester repeats the check for each case where personal data is accessible.

All access attempts to personal data (in clear text) are recorded in the described logs, with the user identity included and no personal data visible in the log.

Sample copies of the log files.

Logging access to personal data

In some cases access to personal data in clear text might be required. If such access is required, access to this data shall be logged, and the log shall contain who accessed what data without revealing personal data in clear text. When for practical purposes such logging is not available, a coarser grain logging is allowed.

Verify that in cases where a network product presents personal data in clear text, access attempts to such data are logged and the log information includes the user identity that has accessed the data. The test case also verifies that the personal data itself is not included in clear text in the log.

A document which provides a description of where personal data in clear text is accessible on the network product, how it can be accessed, and details of where such access attempts are logged and how to view these logs.

• The tester verifies, for cases where personal data is accessible in clear text, that attempts to access it are recorded in a log, that the log includes the identity of the user that has attempted to access the data, and that the log does not include the actual personal data in clear-text.

• The tester repeats the check for each case where personal data is accessible.

All access attempts to personal data (in clear text) are recorded in the described logs, with the user identity included and no personal data visible in the log.

Sample copies of the log files.

Boot from intended memory devices only

In accordance with industry best practice

The network product can boot only from the memory devices intended for this purpose.

Verify that the network product can only boot from memory devices intended for this purpose (e.g. not from external memory like USB key).

A document which contains information regarding the firmware access mechanism supported by the product and about the memory devices from which the network product can boot.

1. The tester verifies that the network product is configured to boot from memory devices declared in the network product document only.

2. The tester verifies that there is no possibility to access and modify the firmware of the network product without successful authentication and the authenticated subject (e.g., person or process) has no possibility to access and modify the firmware without privileged access rights.

The network product cannot boot from a memory device that is not configured in its firmware, and access to the firmware is only possible with the correct authentication.

NA

Boot from intended memory devices only

The network product can boot only from the memory devices intended for this purpose.

Verify that the network product can only boot from memory devices intended for this purpose (e.g. not from external memory like USB key).

A document which contains information regarding the firmware access mechanism supported by the product and about the memory devices from which the network product can boot.

1. The tester verifies that the network product is configured to boot from memory devices declared in the network product document only.

2. The tester verifies that there is no possibility to access and modify the firmware of the network product without successful authentication.

The network product cannot boot from a memory device that is not configured in its firmware, and access to the firmware is only possible with the correct authentication.

NA

TR 33.926 [4].

System handling during excessive overload situations.

In accordance with industry best practice.

The system shall act in a predictable way if an overload situation cannot be prevented. A system shall be built in this way that it can react on an overload situation in a controlled way. However it is possible that a situation happens where the security measures are no longer sufficient.

In such case it shall be ensured that the system cannot reach an undefined and thus potentially insecure state. In an extreme case this means that a controlled system shutdown is preferable to uncontrolled failure of the security functions and thus loss of system protection.

The vendor shall provide a technical description of the network product's Over Load Control mechanisms (especially whether these mechanisms rely on cooperation of other network elements e.g. eNode B) and the accompanying test case for this requirement checks that the description provides sufficient detail in order for an evaluator to understand how the mechanism is designed.

Verify that the network product:

• has a detailed technical description of the overload control mechanisms used to deal with overload scenarios;

• has test results verifying the operation of the overload control mechanisms.

• A document which provide a detailed technical description of the overload control mechanisms.

• Test results from a test execution phase of overload control mechanism testing.

• The tester verifies that there is:

• A technical description providing a high-level overview of the overload control design:

• An overview of the types of overload scenarios that the network product overload control mechanisms are expected to handle.

• An overview of the overload control thresholds that the network product uses to trigger overload control mechanisms.

• Description of the types of attacks that can cause an overload to the network product and how these are handled.

• A description of how the network product discards or handles input during various overload situations including excessive overloads. i.e. where the overload is significantly greater than the thresholds where overload detection is triggered.

• A description of how the network product security functions operate and perform during overload.

• A description of how the network product shuts down or performs or takes other abatement or corrective actions during excessive overload conditions.

• The tester verifies that the test results:

• Contain details of the overload conditions used in the test execution that are consistent with the technical description document.

• Describe test procedures used to verify the overload control mechanisms.

• Contain data which demonstrates/indicates that the overload control mechanisms described in the technical description document have been implemented.

• Contain details of the test set-up including the mechanisms for creating the overload. Where simulators and/or scripts are used to artificially create a load then details of these should also be included.

• A technical description provides a high-level overview of the overload control design.

• A overview of the types of overload scenarios and overload control thresholds that are considered.

• Description on the types of attacks that may cause an overload to the system and how these are handled.

• A description of how the network product discards or handles input during various overload situations.

• Describes if or how the network product security functions operate and perform during overload.

• If parts of the system shutdown or take other abatement or corrective actions these should be described.

Note: If some of the items listed above are not applicable to a network product then, in those cases, it should be clarified by the vendor why these items are not applicable.

The test results should:

• Contain details of the overload conditions used in the test execution that are consistent with the technical description document.

• Describe the test procedures used to verify the overload control mechanisms.

• Contain data which demonstrates/indicates that the overload control mechanisms described in the technical description document have been implemented.

• Contain details of the test set-up including the mechanisms for creating the overload.

Documentation showing each of the points in the results sections.

The system shall act in a predictable way if an overload situation cannot be prevented. A system shall be built in this way that it can react on an overload situation in a controlled way. However it is possible that a situation happens where the security measures are no longer sufficient.

In such case it shall be ensured that the system cannot reach an undefined and thus potentially insecure state. In an extreme case this means that a controlled system shutdown is preferable to uncontrolled failure of the security functions and thus loss of system protection.

Verify that the network product:

• has a detailed technical description of the overload control mechanisms used to deal with overload scenarios;

• has test results verifying the operation of the overload control mechanisms.

• A document which provide a detailed technical description of the overload control mechanisms.

• Test results from a test execution phase of overload control mechanism testing.

• The tester verifies that there is:

• A technical description providing a high-level overview of the overload control design:

• An overview of the types of overload scenarios that the network product overload control mechanisms are expected to handle.

• An overview of the overload control thresholds that the network product uses to trigger overload control mechanisms.

• Description of the types of attacks that may cause an overload to the network product and how these are handled.

• A description of how the network product discards or handles input during various overload situations including excessive overloads. i.e. where the overload is significantly greater than the thresholds where overload detection is triggered.

• A description of how the network product security functions operate and perform during overload.

• A description of how the network product shuts down or performs or takes other abatement or corrective actions during excessive overload conditions.

• The tester verifies that the test results:

• Contain details of the overload conditions used in the test execution that are consistent with the technical description document.

• Describe test procedures used to verify the overload control mechanisms.

• Contain data which demonstrates/indicates that the overload control mechanisms described in the technical description document have been implemented.

• Contain details of the test set-up including the mechanisms for creating the overload. Where simulators and/or scripts are used to artificially create a load then details of these should also be included.

• A technical description provides a high-level overview of the overload control design.

• A overview of the types of overload scenarios and overload control thresholds that are considered.

• Description on the types of attacks that may cause an overload to the system and how these are handled.

• A description of how the network product discards or handles input during various overload situations.

• Describes if or how the network product security functions operate and perform during overload.

• If parts of the system shutdown or take other abatement or corrective actions these should be described.

Note: If some of the items listed above are not applicable to a network product then, in those cases, it should be clarified by the vendor why these items are not applicable.

The test results should:

• Contain details of the overload conditions used in the test execution that are consistent with the technical description document.

• Describe the test procedures used to verify the overload control mechanisms.

• Contain data which demonstrates/indicates that the overload control mechanisms described in the technical description document have been implemented.

• Contain details of the test set-up including the mechanisms for creating the overload.

Documentation showing each of the points in the results sections.

TR 33.926 [4]

Network product Software integrity validation

In accordance with industry best practice

1. Software package integrity shall be validated in the installation/upgrade stage.

2. Network product shall support software package integrity validation via cryptographic means, e.g. digital signature. To this end, the network product has a list of public keys or certificates of authorised software sources, and uses the keys to verify that the software update is originated from only these sources.

3. Tampered software shall not be executed or installed if integrity check fails.

4. A security mechanism is required to guarantee that only authorized individuals can initiate and deploy a software update, and modify the list mentioned in bullet 2.

Verify that:

1. The Network Product validates the software package integrity during the installation/upgrade stage.

2. The software package integrity validation mechanism is performed using cryptographic mechanisms, e.g. digital signature using the public keys or certificates configured in the network product.

3. Software that fails an integrity check is rejected by the network product.

4. Only authorized users are allowed to install software.

• A network product document containing information regarding software package integrity checks, including details of how the integrity check is carried out, where public keys or certificates of sources authorised to sign software packages are stored on the network product and who these sources are, and what evidence is created to prove that the integrity check has been executed and what the result of the check was. Documentation which describes the installation procedure including how a user is authorized and authenticated to perform installation process.

• A valid network product software load/package and one that is not-valid (or could be deemed to have been tampered with) are available.

The tester checks the permissions required to install software on the network product ensuring that a user is properly authenticated by the network product and that they have the required access privileges to perform the installation activity.

The tester checks, when a software package is attempted to be installed on the network product, that the software package integrity check is executed (check for evidence of execution as described in network product documentation) and that valid software is allowed to be installed but invalid software is rejected.

The tester checks the access control permissions for the software package integrity checking process, the list of public keys of authorised software sources, and any related credentials or keys for the process, to ensure that the process cannot be controlled by persons that are not authorized to do so.

• Evidence that the software package integrity check has been executed for both cases of software installation (valid and invalid software packages).

• Authentication and access control mechanisms are in operation for software package installation and around the software package integrity checking mechanism.

• The installation/upgrade operation fails when using an invalid software package.

• The installation/upgrade operation is successful when using a valid software package.

Snapshots containing the result of the installation of package A and B.

Network product Software integrity validation

1. Software package integrity shall be validated in the installation/upgrade stage.

2. Network product shall support software package integrity validation via cryptographic means, e.g. digital signature. To this end, the network product has a list of public keys or certificates of authorised software sources, and uses the keys to verify that the software update is originated from only these sources.

3. Tampered software shall not be executed or installed if integrity check fails.

4. A security mechanism is required to guarantee that only authorized individuals can initiate and deploy a software update, and modify the list mentioned in bullet 2.

Verify that:

1. The Network Product validates the software package integrity during the installation/upgrade stage.

2. The software package integrity validation mechanism is performed using cryptographic mechanisms, e.g. digital signature using the public keys or certificates configured in the network product.

3. Software that fails an integrity check is rejected by the network product.

4. Only authorized users are allowed to install software.

• A network product document containing information regarding software package integrity checks, including details of how the integrity check is carried out, where public keys or certificates of sources authorised to sign software packages are stored on the network product and who these sources are, and what evidence is created to prove that the integrity check has been executed and what the result of the check was. Documentation which describes the installation procedure including how a user is authorized and authenticated to perform installation process.

• A valid network product software load/package and one that is not-valid (or could be deemed to have been tampered with) are available.

The tester checks the permissions required to install software on the network product ensuring that a user is properly authenticated by the network product and that they have the required access privileges to perform the installation activity.

The tester checks, when a software package is attempted to be installed on the network product, that the software package integrity check is executed (check for evidence of execution as described in network product documentation) and that valid software is allowed to be installed but invalid software is rejected.

The tester checks the access control permissions for the software package integrity checking process, the list of public keys of authorised software sources, and any related credentials or keys for the process, to ensure that the process cannot be controlled by persons that are not authorized to do so.

• Evidence that the software package integrity check has been executed for both cases of software installation (valid and invalid software packages).

• Authentication and access control mechanisms are in operation for software package installation and around the software package integrity checking mechanism.

• The installation/upgrade operation fails when using an invalid software package.

• The installation/upgrade operation is successful when using a valid software package.

Snapshots containing the result of the installation of package A and B.

TR 33.926 [4]

Authentication and authorization for System functions

In accordance with industry best practice

The usage of a system function without successful authentication on basis of the user identity and at least one authentication attribute (e.g. password, certificate) shall be prevented. System functions comprise, for example network services (like SSH, SFTP, Web services), local access via a management console, local usage of operating system and applications. This requirement shall also be applied to accounts that are only used for communication between systems. An exception to the authentication and authorization requirement are functions for public use such as those for a Web server on the Internet, via which information is made available to the public.

To ensure that system functions shall not be used without successful authentication and authorization.

1. The vendor shall supply the list of system functions which include network services, local access via a management console, local usage of operating system and applications.

2. The vendor shall supply the list of access entries for system functions.

The tester is required to execute the following steps:

1. The tester verifies, based on his/her own experience, that the list is adequate.

2. The tester verifies that the access entries to use system functions, which are listed by the vendor, require successful authentication on basis of the user name and at least one authentication attribute. The tester also verifies that the access entries to use system functions require authorization via an access control mechanism (e.g. Discretionary access control/Ownership/Capabilities or Mandatory access control). This applies to both system functions that are locally accessible and those that are remotely accessible via a network interface.

1. The network product does not allow access to any system function provided by the vendor without a successful user authentication and authorization.

A testing report provided by the testing agency which will consist of the following information:

• Description of executed tests and commands

• Relevant output (e.g. Screenshot)

• Test result (Passed or not)

The usage of a system function without successful authentication on basis of the user identity and at least one authentication attribute (e.g. password, certificate) shall be prevented. System functions comprise, for example network services (like SSH, SFTP, Web services), local access via a management console, local usage of operating system and applications. This requirement shall also be applied to accounts that are only used for communication between systems. An exception to the authentication and authorization requirement are functions for public use such as those for a Web server on the Internet, via which information is made available to the public.

To ensure that system functions shall not be used without successful authentication and authorization.

1. The manufacturer shall supply the list of system functions which include network services, local access via a management console, local usage of operating system and applications.

2. The manufacturer shall supply the list of access entries for system functions.

1. The tester verifies, based on his/her own experience, that the list is adequate.

2. The tester verifies that the access entries to use system functions, which are listed by the manufacturer, require successful authentication on basis of the user name and at least one authentication attribute. This applies to both system functions that are locally accessible and those that are remotely accessible via a network interface.

The network product does not allow access to any system function provided by the manufacturer without a successful user authentication.

A testing report provided by the testing agency which will consist of the following information:

• Description of executed tests and commands

• Relevant output (e.g. Screenshot)

• Test result (Passed or not)

TR 33.926 [4]

NOTE 3: Some typical default accounts suggest that they are shared amongst several persons (e.g. vendor_xy, support), or do not allow identification of individual users (e.g. guest, ftp, anonymous). In order to avoid overlap of this test case with clause 4.2.3.4.2.2, it is assumed for this test case that such accounts have been deleted or disabled in line with clause 4.2.3.4.2.2.

Unambiguous identification of the user.

In accordance with industry best practice.

Users shall be identified unambiguously by the network product. The network product shall support assignment of individual accounts per user, where a user could be a person, or, for Machine Accounts, an application, or a system. The network product shall not enable the use of group accounts or group credentials, or sharing of the same account between several users, by default. The network product shall support a minimum number of 50 individual accounts per user data base if not explicitly specified in a SCAS of a particular network product, so that accountability for each user is ensured even in large network operator networks. The network product shall not support user access credentials unrelated to an account.

NOTE 1: The network product can support independent user data bases for different access methods, e.g. one data base for command shell access on OS level and another data base for GUI access. User data bases can be stored locally on the network product or on a central AAA system that the network product accesses for user authentication.

NOTE 2: This requirement does not preclude user group concepts for access control.

To ensure that documentation of the network product does not encourage or require the use of group accounts, group credentials, or sharing of the same account between several users. To ensure that the network product does not support credentials unrelated to an account.

1. All user and group data bases for names and credentials supported by the network product are identified in the documentation accompanying the network product.

2. All predefined accounts and groups are identified in the documentation accompanying the Network Product.

3. Instructions of how administrator users can add accounts, groups, and credentials to the database(s) are provided in the documentation accompanying the Network Product.

4. The operations manual describes O&M user and group concepts supported by the network product.

The tester is required to execute the following steps:

1. Review the system documentation (in particular operations manual) whether it encourages or requires the use of group accounts, group credentials, or sharing of the same account between several users.

2. Review the system documentation whether the network product requires or supports entering credentials unrelated to an account, in order to perform specific actions, e.g. to enter a "master password" for access to privileged functions.

1. The reviewed documentation is in line with the requirement.

Test report that lists the reviewed documentation (incl. release dates and versions) and the findings.

NOTE 1: The network product may support independent user data bases for different access methods, e.g. one data base for command shell access on OS level and another data base for GUI access. User data bases may be stored locally on the network product or on a central AAA system that the network product accesses for user authentication.

NOTE 2: This requirement does not preclude user group concepts for access control.

To ensure that documentation of the network product does not encourage or require the use of group accounts, group credentials, or sharing of the same account between several users. To ensure that the network product does not support credentials unrelated to an account.

1. All user and group data bases for names and credentials supported by the network product are identified in the documentation accompanying the network product.

2. All predefined accounts and groups are identified in the documentation accompanying the Network Product.

3. Instructions of how administrator users can add accounts, groups, and credentials to the database(s) are provided in the documentation accompanying the Network Product.

4. The operations manual describes OAM user and group concepts supported by the network product.

1. Review the system documentation (in particular operations manual) whether it encourages or requires the use of group accounts, group credentials, or sharing of the same account between several users.

2. Review the system documentation whether the network product requires or supports entering credentials unrelated to an account, in order to perform specific actions, e.g. to enter a "master password" for access to privileged functions.

1. The reviewed documentation is in line with the requirement.

Test report that lists the reviewed documentation (incl. release dates and versions) and the findings.

TR 33.926 [4]

NOTE 3: Some typical default accounts suggest that they are shared amongst several persons (e.g. vendor_xy, support), or do not allow identification of individual users (e.g. guest, ftp, anonymous). In order to avoid overlap of this test case with clause 4.2.3.4.2.2, it is assumed for this test case that such accounts have been deleted or disabled in line with clause 4.2.3.4.2.2.

Unambiguous identification of the user.

In accordance with industry best practice.

Users shall be identified unambiguously by the network product. The network product shall support assignment of individual accounts per user, where a user could be a person, or, for Machine Accounts, an application, or a system. The network product shall not enable the use of group accounts or group credentials, or sharing of the same account between several users, by default. The network product shall support a minimum number of 50 individual accounts per user data base if not explicitly specified in a SCAS of a particular network product, so that accountability for each user is ensured even in large network operator networks. The network product shall not support user access credentials unrelated to an account.

NOTE 1: The network product can support independent user data bases for different access methods, e.g. one data base for command shell access on OS level and another data base for GUI access. User data bases can be stored locally on the network product or on a central AAA system that the network product accesses for user authentication.

NOTE 2: This requirement does not preclude user group concepts for access control.

To ensure that the default setup of the network product does not enable the use of group accounts or group credentials.

1. All user and group data bases for names and credentials supported by the network product are identified in the documentation accompanying the network product.

2. Instructions of how administrator users can view all existing accounts, groups, and protected credentials in the databases are provided in the documentation accompanying the Network Product.

The tester is required to execute the following steps:

1. After login via an account with necessary access rights (e.g. Admin) search in the databases for any group credentials. Example for Linux®: /etc/gshadow

1. No group credentials are defined.

Test report that lists the reviewed documentation, reviewed user and group databases, and the findings.

NOTE 1: The network product may support independent user data bases for different access methods, e.g. one data base for command shell access on OS level and another data base for GUI access. User data bases may be stored locally on the network product or on a central AAA system that the network product accesses for user authentication.

NOTE 2: This requirement does not preclude user group concepts for access control.

To ensure that the default setup of the network product does not enable the use of group accounts or group credentials.

1. All user and group data bases for names and credentials supported by the network product are identified in the documentation accompanying the network product.

2. Instructions of how administrator users can view all existing accounts, groups, and protected credentials in the databases are provided in the documentation accompanying the Network Product.

1. After login via an account with necessary access rights (e.g. Admin) search in the databases for any group credentials. Example for Linux®: /etc/gshadow

1. No group credentials are defined.

Test report that lists the reviewed documentation, reviewed user and group databases, and the findings.

TR 33.926 [4]

NOTE 3: Some typical default accounts suggest that they are shared amongst several persons (e.g. vendor_xy, support), or do not allow identification of individual users (e.g. guest, ftp, anonymous). In order to avoid overlap of this test case with clause 4.2.3.4.2.2, it is assumed for this test case that such accounts have been deleted or disabled in line with clause 4.2.3.4.2.2.

Unambiguous identification of the user.

In accordance with industry best practice.

Users shall be identified unambiguously by the network product. The network product shall support assignment of individual accounts per user, where a user could be a person, or, for Machine Accounts, an application, or a system. The network product shall not enable the use of group accounts or group credentials, or sharing of the same account between several users, by default. The network product shall support a minimum number of 50 individual accounts per user data base if not explicitly specified in a SCAS of a particular network product, so that accountability for each user is ensured even in large network operator networks. The network product shall not support user access credentials unrelated to an account.

NOTE 1: The network product can support independent user data bases for different access methods, e.g. one data base for command shell access on OS level and another data base for GUI access. User data bases can be stored locally on the network product or on a central AAA system that the network product accesses for user authentication.

NOTE 2: This requirement does not preclude user group concepts for access control.

To ensure that a minimum number of individual accounts per user data base is supported. The minimum number is defined in the requirement description of this clause.

All user data bases for names and credentials supported by the network product are identified in the documentation accompanying the network product.

The tester is required to execute the following steps:

Create accounts until the minimum number of accounts is reached.

Successful creation of the minimum number of accounts.

Test report that lists the reviewed documentation, reviewed user databases, and the findings.

NOTE 1: The network product may support independent user data bases for different access methods, e.g. one data base for command shell access on OS level and another data base for GUI access. User data bases may be stored locally on the network product or on a central AAA system that the network product accesses for user authentication.

NOTE 2: This requirement does not preclude user group concepts for access control.

To ensure that a minimum number of individual accounts per user data base is supported. The minimum number is defined in the requirement description of this clause.

All user data bases for names and credentials supported by the network product are identified in the documentation accompanying the network product.

Create accounts until the minimum number of accounts is reached.

Successful creation of the minimum number of accounts.

Test report that lists the reviewed documentation, reviewed user databases, and the findings.

TR 33.926 [4]

Account protection by at least one authentication attribute.

In accordance with industry best practice.

The various user and machine accounts on a system shall be protected from misuse. To this end, an authentication attribute is typically used, which, when combined with the user name, enables unambiguous authentication and identification of the authorized user.

Authentication attributes include:

• Cryptographic keys

• Token

• Passwords

This means that authentication based on a parameter that can be spoofed (e.g. phone numbers, public IP addresses or VPN membership) is not permitted. Exceptions are attributes that cannot be faked or spoofed by an attacker.

NOTE: Several of the above options can be combined (dual-factor authentication) to achieve a higher level of security. Whether or not this is suitable and necessary depends on the protection needs of the individual system and its data and is evaluated for individual cases.

To ensure that all accounts are protected by at least one authentication attribute.

1. All predefined accounts are identified in the documentation accompanying the Network Product.

2. Instructions of how to create new accounts are provided in the documentation accompanying the Network Product.

3. Instructions of how administrator user can view all existing accounts in the database are provided in the documentation accompanying the Network Product.

NOTE: No test is provided here for finding undocumented hard coded accounts as such tests be impossible to define in a general way.

The tester is required to execute the following steps:

1. After login via account with necessary access rights (e.g. Admin) search in the database for any undocumented account.

2. Attempt login to all predefined accounts identified (either documented or not) with and without using the respective authentication attribute.

3. Create a new account by following instructions in documentation.

4. Attempt login to the newly created account.

1. It is not possible to login to any predefined account without using at least one authentication attribute that satisfies the conditions in the requirement.

2. It is not possible to login to any newly created account without usage of at least one authentication attribute that satisfies the conditions in the requirement.

Evidence containing the results of all login attempts, e.g. screenshots, log files, error messages.

Account protection by at least one authentication attribute.

The various user and machine accounts on a system shall be protected from misuse. To this end, an authentication attribute is typically used, which, when combined with the user name, enables unambiguous authentication and identification of the authorized user.

Authentication attributes include:

• Cryptographic keys

• Token

• Passwords

This means that authentication based on a parameter that can be spoofed (e.g. phone numbers, public IP addresses or VPN membership) is not permitted. Exceptions are attributes that cannot be faked or spoofed by an attacker.

NOTE: Several of the above options can be combined (dual-factor authentication) to achieve a higher level of security. Whether or not this is suitable and necessary depends on the protection needs of the individual system and its data and is evaluated for individual cases.

To ensure that all accounts are protected by at least one authentication attribute.

1. All predefined accounts are identified in the documentation accompanying the Network Product.

2. Instructions of how to create new accounts are provided in the documentation accompanying the Network Product.

3. Instructions of how administrator user can view all existing accounts in the database are provided in the documentation accompanying the Network Product.

NOTE: No test is provided here for finding undocumented hard coded accounts as such tests may be impossible to define in a general way.

1. After login via account with necessary access rights (e.g. Admin) search in the database for any undocumented account.

2. Attempt login to all predefined accounts identified (either documented or not) with and without using the respective authentication attribute.

3. Create a new account by following instructions in documentation.

4. Attempt login to the newly created account.

1. It is not possible to login to any predefined account without using at least one authentication attribute that satisfies the conditions in the requirement.

2. It is not possible to login to any newly created account without usage of at least one authentication attribute that satisfies the conditions in the requirement.

TR 33.926 [4]

Deletion or disablement of predefined accounts .

In accordance with industry best practice.

All predefined or default accounts shall be deleted or disabled. Many systems have default accounts (e.g. guest, ctxsys), some of which are preconfigured with or without known passwords. These standard users shall be deleted or disabled. Should this measure not be possible the accounts shall be locked for remote login. In any case disabled or locked accounts shall be configured with a complex password as specified in clause 4.2.3.4.3.1 Password Structure. This is necessary to prevent unauthorized use of such an account in case of misconfiguration.

Exceptions to this requirement to delete or disable accounts are accounts that are used only internally on the system involved and that are required for one or more applications on the system to function. Also for these accounts remote access or local login shall be forbidden to prevent abusive use by users of the system.

To ensure that predefined accounts are deleted or disabled unless there is specific exception as defined in the requirement 4.2.3.4.2.2.

1. All predefined accounts are identified in the documentation accompanying the Network Product.

2. Instructions of how administrator user can view all existing accounts in the database are provided in the documentation accompanying the Network Product.

NOTE: No test is provided here for finding undocumented hard coded accounts as such tests can be impossible to define in a general way.

1. Check in documentation of the existence of any documented predefined account and what is the reason for existence.

2. After login via account with necessary access rights (e.g. Admin) search in the database for any undocumented account.

3. Check the password complexity of such existing predefined accounts according to the test provided in clause 4.2.3.4.3.1.

4. Attempt remote login to such predefined accounts.

1. Predefined accounts are either deleted/ disabled or, if existing, the reason is in accordance with the requirement exception.

2. If there are active predefined accounts in accordance with the requirement exception then there is no remote login possibility.

3. If predefined account is either disabled or locked then it shall anyway fulfil the complex password requirements as specified in clause 4.2.3.4.3.1 after enabling or unlocking it.

Evidence can be presented in the form of screenshot/screen-capture on showing for example a remote login failure or complexity of a password of e.g. locked or disabled accounts.

All predefined or default accounts shall be deleted or disabled. Many systems have default accounts (e.g. guest, ctxsys), some of which are preconfigured with or without known passwords. These standard users shall be deleted or disabled. Should this measure not be possible the accounts shall be locked for remote login. In any case disabled or locked accounts shall be configured with a complex password as specified in clause 4.2.3.4.3.1 Password Structure. This is necessary to prevent unauthorized use of such an account in case of misconfiguration.

Exceptions to this requirement to delete or disable accounts are accounts that are used only internally on the system involved and that are required for one or more applications on the system to function. Also for these accounts remote access or local login shall be forbidden to prevent abusive use by users of the system.

To ensure that predefined accounts are deleted or disabled unless there is specific exception as defined in the requirement 4.2.3.4.2.2.

1. All predefined accounts are identified in the documentation accompanying the Network Product.

2. Instructions of how administrator user can view all existing accounts in the database are provided in the documentation accompanying the Network Product.

NOTE: No test is provided here for finding undocumented hard coded accounts as such tests may be impossible to define in a general way.

1. Check in documentation of the existence of any documented predefined account and what is the reason for existence.

2. After login via account with necessary access rights (e.g. Admin) search in the database for any undocumented account.

3. Check the password complexity of such existing predefined accounts according to the test provided in clause 4.2.3.4.3.1.

4. Attempt remote login to such predefined accounts.

1. Predefined accounts are either deleted/ disabled or, if existing, the reason is in accordance with the requirement exception.

2. If there are active predefined accounts in accordance with the requirement exception then there is no remote login possibility.

3. If predefined account is either disabled or locked then it shall anyway fulfil the complex password requirements as specified in clause 4.2.3.4.3.1 after enabling or unlocking it.

Evidence can be presented in the form of screenshot/screen-capture on showing for example a remote login failure or complexity of a password of e.g. locked or disabled accounts.

TR 33.926 [4]

Deletion or disablement of predefined or default authentication attributes

In accordance with industry best practice

Predefined or default authentication attributes shall be deleted or disabled.

Normally, authentication attributes such as password or cryptographic keys will be preconfigured from vendor, manufacturer, or developer of a system. Such authentication attributes shall be changed by automatically forcing a user to change it on 1^st^ time login to the system or the vendor provides instructions on how to manually change it.

To ensure that predefined or default authentication attributes are deleted or disabled as defined in the requirement 4.2.3.4.2.3.

1. Instructions of how administrator user can view all existing accounts in the database are provided in the documentation accompanying the Network Product.

2. All predefined accounts and their respective predefined or default passwords are identified in the documentation accompanying the Network Product.

NOTE: No test is provided here for finding undocumented hard coded accounts as such tests can be impossible to define in a general way.

1. Check in documentation of the existence of any documented predefined account and what is the login password or if any cryptographic key for such accounts is preinstalled.

2. After login via account with necessary access rights (e.g. Admin) search in the database for any undocumented account.

3. Attempt login to such predefined accounts if existing.

1. When login is attempted to any predefined account the user is automatically forced to change login password at first time login to the system.

2. If there is no automatic password change enforced then recommendation and clear instructions of how to manually change the password or how to create and reinstall a new cryptographic key exist in the documentation.

Evidence can be presented in the form of screenshot/screen-capture on how the network product prompts for password change at first login. Also extracts from product documentation with clear instructions of how to change any default password or cryptographic key.

Predefined or default authentication attributes shall be deleted or disabled.

To ensure that predefined or default authentication attributes are deleted or disabled as defined in the requirement 4.2.3.4.2.3.

1. Instructions of how administrator user can view all existing accounts in the database are provided in the documentation accompanying the Network Product.

2. All predefined accounts and their respective predefined or default passwords are identified in the documentation accompanying the Network Product.

NOTE: No test is provided here for finding undocumented hard coded accounts as such tests may be impossible to define in a general way.

1. Check in documentation of the existence of any documented predefined account and what is the login password or if any cryptographic key for such accounts is preinstalled.

2. After login via account with necessary access rights (e.g. Admin) search in the database for any undocumented account.

3. Attempt login to such predefined accounts if existing.

1. When login is attempted to any predefined account the user is automatically forced to change login password at first time login to the system.

2. If there is no automatic password change enforced then recommendation and clear instructions of how to manually change the password or how to create and reinstall a new cryptographic key exist in the documentation.

Evidence can be presented in the form of screenshot/screen-capture on how the network product prompts for password change at first login. Also extracts from product documentation with clear instructions of how to change any default password or cryptographic key.

TR 33.926 [4]

Password Complexity rule

In accordance with industry best practice

The setting by the vendor shall be such that a network product shall only accept passwords that comply with the following complexity criteria:

1. Absolute minimum length of 8 characters (shorter lengths shall be rejected by the network product). It shall not be possible setting this absolute minimum length to a lower value by configuration.

2. Comprising at least three of the following categories:

3. at least 1 uppercase character (A-Z)

4. at least 1 lowercase character (a-z)

5. at least 1 digit (0-9)

6. at least 1 special character (e.g. @;!\$.)

The network product shall use a default minimum length of 10 characters. The minimum length of characters in the passwords shall be configurable by the network operator. The default minimum length is the value configured by the vendor before any network operator-specific configuration has been applied. The special characters can be categorized in sets according to their Unicode category.

The network product shall at least support passwords of a length of 64 characters or a length greater than 64 characters.

If a central system is used for user authentication, password policy is performed on the central system and additional assurance shall be provided that the central system enforces the same password complexity rules as laid down for the local system in this subclause. If a central system is not used for user authentication, the assurance on password complexity rules shall be performed on the Network Product.

When a user is changing a password or entering a new password, the system checks and ensures that it meets the password requirements. Above requirements shall be applicable for all passwords used (e.g. application-level, OS-level, etc.).

To verify that password structure adheres to the password complexity criteria.

To verify that password structure is configurable as per the complexity criteria.

1. Tester has rights to create user account.

Execute the following steps:

A. Test Case 1

1. The tester logs into Network Product application using admin account.

2. The tester creates user A following the password complexity criteria.

3. The tester logs in as user A and attempts to change their password which contains characters from all four categories mentioned in the password complexity criteria.

B. Test Case 2

1. The tester logins with privileged account.

2. The tester modifies password structure policy on the network product by strengthening the policy (e.g. changing the minimum password length to 8+x, changing the minimum number of character Unicode categories to 4).

3. The tester logs in as user A and attempts to change their password to a password with a strength of less than that permitted by the policy strengthened in step 2 above.

Tester can change password only if new password fulfil the password complexity criteria

Evidence suitable for the interface, e.g. screenshot containing the operation result or report in text form.

Password Complexity rule

The setting by the vendor shall be such that a network product shall only accept passwords that comply with the following complexity criteria:

1. Absolute minimum length of 8 characters (shorter lengths shall be rejected by the network product). It shall not be possible setting this absolute minimum length to a lower value by configuration.

2. Comprising at least three of the following categories:

3. at least 1 uppercase character (A-Z)

4. at least 1 lowercase character (a-z)

5. at least 1 digit (0-9)

6. at least 1 special character (e.g. @;!\$.)

The network product shall at least support passwords of a length of 64 characters or a length greater than 64 characters.

If a central system is used for user authentication, password policy is performed on the central system and additional assurance shall be provided that the central system enforces the same password complexity rules as laid down for the local system in this subclause. If a central system is not used for user authentication, the assurance on password complexity rules shall be performed on the Network Product.

When a user is changing a password or entering a new password, the system checks and ensures that it meets the password requirements. Above requirements shall be applicable for all passwords used (e.g. application-level, OS-level, etc.).

To verify that password structure adheres to the password complexity criteria.

To verify that password structure is configurable as per the complexity criteria.

1. Tester has rights to create user account.

Execute the following steps:

A. Test Case 1

1. The tester logs into Network Product application using admin account.

2. The tester creates user A following the password complexity criteria.

3. The tester logs in as user A and attempts to change their password which contains characters from all four categories mentioned in the password complexity criteria.

B. Test Case 2

1. The tester logins with privileged account.

2. The tester modifies password structure policy on the network product by strengthening the policy (e.g. changing the minimum password length to 8+x, changing the minimum number of character Unicode categories to 4).

3. The tester logs in as user A and attempts to change their password to a password with a strength of less than that permitted by the policy strengthened in step 2 above.

Tester can change password only if new password fulfil the password complexity criteria

Evidence suitable for the interface, e.g. screenshot containing the operation result or report in text form.

TR 33.926 [4]

Password changes

In accordance with industry best practice

If a password is used as an authentication attribute, then the system shall offer a function that enables a user to change his password at any time. When an external centralized system for user authentication is used it is possible to redirect or implement this function on this system.

Password change shall be enforced after initial login.

The system shall enforce password change based on password management policy. In particular, the system shall enforce password expiry.

Previously used passwords shall not be allowed up to a certain number (Password History).\ The number of disallowed previously used passwords shall be:

• Configurable;

• Greater than 0;

• And its default value shall be 3. This means that the network product shall store at least the three previously set passwords. The maximum number of passwords that the network product can store for each user is up to the vendor.

When a password is about to expire a password expiry notification shall be provided to the user.

Above requirements shall be applicable for all passwords used(e.g. application-level, OS-level, etc.). An exception to this requirement is machine accounts.

• To check whether the network product is provisioned with the functionality that enables its user to change the password at any time.

• The network product enforces password change after initial login.

• To verify the new password adheres to the password management policy and also to verify whether it has password expiry rule.

• The network product is configured to disallow specified number of previously used passwords (Password History).

1. Tester has account with username and password in the network product.

2. Network product vendor will provide documentation for password management policy which should include details on how to change the password, configure password expiry rule and disallowing specified number of previously used passwords.

3. The network product vendor shall supply information on how many passwords the network product can store for each user in the password history.

4. The tester has privilege to modify the number of disallowed previously used password.

Execute the following steps:

A. Positive Test

Case 1:

Test case to enforce password change after initial login is covered in clause 4.2.3.4.2.3.

Case 2:

1 The tester logs into network product application using a privileged account .

2 The network product application generates password expiry notification for user Y to force user Y to change the password.

3 The tester logs out as a privileged user and logs on as user Y.

1. The tester is prompted to change his password and creates a new password by following the password policy management.

5 The network product application confirms change in password by, for example, displaying "Password Changed Successfully".

6 The tester successfully logs-in the network product application as user Y using the new password.

Case 3:

1. The tester logs into network product application using a privileged account.

2. Tester configures the network product application for number of disallowed previously used passwords to x

3. The tester requests for a password change for user Y.

4. The tester logs out of the privileged account and logs on as user Y

5. The tester creates a new password by following the password policy management.

6. If the password is not equal to any of the x previously used passwords, the network product application still accepts the new password and displays "Password Changed Successfully".

B. Negative Test

Case 1:

Test case to enforce password change after initial login is covered in clause 4.2.3.4.2.3.

Case 2:

No negative test case for this scenario.

Case 3:

1. The tester logs into network product application using privileged account.

2. Tester configures the network product application for number of disallowed previously used passwords to x for user Y.

3. The tester logs out of the privileged account and logs in as user Y

4. The tester requests for a password change.

5. The tester sets the new password to a value that is among the last x passwords used previously x times.

A. Positive Test

Case 1:

Expected result for enforcing password change after initial login is covered in clause 4.2.3.4.2.3.

Case 2:

Tester can successfully change the password.

Case 3:

Tester can successfully change the password.

B. Negative Test

If the negative test case passes, this shows that network product application does not work properly and it violates the requirement.

Case 1:

Expected result for enforcing password change after initial login is covered in clause 4.2.3.4.2.3.

Case 2:

No negative test case for this scenario.

Case 3:

The tester cannot successfully change the password.

Evidence suitable for the interface, e.g. screenshot contains the operation result.

If a password is used as an authentication attribute, then the system shall offer a function that enables a user to change his password at any time. When an external centralized system for user authentication is used it is possible to redirect or implement this function on this system.

Password change shall be enforced after initial login.

The system shall enforce password change based on password management policy. In particular, the system shall enforce password expiry.

Previously used passwords shall not be allowed up to a certain number (Password History).\ The number of disallowed previously used passwords shall be:

• Configurable;

• Greater than 0;

• And its default value shall be 3. This means that the network product shall store at least the three previously set passwords. The maximum number of passwords that the network product can store for each user is up to the manufacturer.

When a password is about to expire a password expiry notification shall be provided to the user.

Above requirements shall be applicable for all passwords used(e.g. application-level, OS-level, etc.). An exception to this requirement is machine accounts.

• To check whether the network product is provisioned with the functionality that enables its user to change the password at any time.

• The network product enforces password change after initial login.

• To verify the new password adheres to the password management policy and also to verify whether it has password expiry rule.

• The network product is configured to disallow specified number of previously used passwords (Password History).

1. Tester has account with username and password in the network product.

2. Network product vendor will provide documentation for password management policy which should include details on how to change the password, configure password expiry rule and disallowing specified number of previously used passwords.

3. The network product vendor shall supply information on how many passwords the network product can store for each user in the password history.

4. The tester has privilege to modify the number of disallowed previously used password.

Execute the following steps:

A. Positive Test

Case 1:

Test case to enforce password change after initial login is covered in clause 4.2.3.4.2.3.

Case 2:

1 The tester logs into network product application using a privileged account .

2 The network product application generates password expiry notification for user Y to force user Y to change the password.

3 The tester logs out as a privileged user and logs on as user Y.

1. The tester is prompted to change his password and creates a new password by following the password policy management.

5 The network product application confirms change in password by, for example, displaying "Password Changed Successfully".

6 The tester successfully logs-in the network product application as user Y using the new password.

Case 3:

1. The tester logs into network product application using a privileged account.

2. Tester configures the network product application for number of disallowed previously used passwords to x

3. The tester requests for a password change for user Y.

4. The tester logs out of the privileged account and logs on as user Y

5. The tester creates a new password by following the password policy management.

6. If the password is not equal to any of the x previously used passwords, the network product application still accepts the new password and displays "Password Changed Successfully".

B. Negative Test

Case 1:

Test case to enforce password change after initial login is covered in clause 4.2.3.4.2.3.

Case 2:

No negative test case for this scenario.

Case 3:

1. The tester logs into network product application using privileged account.

2. Tester configures the network product application for number of disallowed previously used passwords to x for user Y.

3. The tester logs out of the privileged account and logs in as user Y

4. The tester requests for a password change.

5. The tester sets the new password to a value that is among the last x passwords used previously x times.

A. Positive Test

Case 1:

Expected result for enforcing password change after initial login is covered in clause 4.2.3.4.2.3.

Case 2:

Tester can successfully change the password.

Case 3:

Tester can successfully change the password.

B. Negative Test

If the negative test case passes, this shows that network product application does not work properly and it violates the requirement.

Case 1:

Expected result for enforcing password change after initial login is covered in clause 4.2.3.4.2.3.

Case 2:

No negative test case for this scenario.

Case 3:

The tester cannot successfully change the password.

Evidence suitable for the interface, e.g. screenshot contains the operation result.

TR 33.926 [4]

Protection against brute force and dictionary attacks

In accordance with industry best practice

If a password is used as an authentication attribute, a protection against brute force and dictionary attacks that hinder password guessing shall be implemented.

Brute force and dictionary attacks aim to use automated guessing to ascertain passwords for user and machine accounts. Various measures or a combination of these measures can be taken to prevent this.

The most commonly used protection measures are:

1. Using the timer delay (this delay could be the same or increased depending the network operator's policy for each attempt, e.g. double the delay, or 5 minutes delay, or 10 minutes delay) for each newly entered password input following an incorrect entry ("tar pit").

2. Blocking an account following a specified number of incorrect attempts, refer to 4.2.3.4.5. However it has to be taken into account that this solution needs a process for unlocking and an attacker can force this to deactivate accounts and make them unusable.

3. Using CAPTCHA to prevent automated attempts (often used for Web applications).

4. Using a password disallow list to prevent vulnerable passwords.

NOTE 1: Password management and disallow list configuration can be done in a separate node that is different to the node under test, e.g. a SSO server or any other central credential manager.

In order to achieve higher security, it is often meaningful to combine two or more of the measures named here. It is left to the vendor to select appropriate measures.

Above requirements shall be applicable for all passwords used (e.g. application-level, OS-level, etc.). An exception to this requirement is machine accounts.

To ensure that the system uses a mechanism with adequate protection against brute force and dictionary attacks

To check whether system follows commonly used preventive measures which are mentioned below.

1. Using the timer delay (e.g. doubling wait times after every incorrect attempt, or 5 minutes delay, or 10 minutes delay) after each incorrect password input ("tar pit").

2. Blocking an account following a specified number of incorrect attempts (typically 5). However administrator has to keep in account that this solution needs a process for unlocking and an attacker can utilize this process to deactivate the accounts and make them unusable.

3. Using CAPTCHA to prevent automated attempts (often used for Web interface).

4. Using a password disallow list to prevent vulnerable passwords.

This test applies only when the most commonly used protection measures used in the requirement are implemented. If they are not implemented, then the vendor documentation needs to provide alternative measures and the tester needs to develop suitable tests for these alternative measures. Since a vendor is free to select appropriate measures, only the vendor selected measures are to be tested.

1. The password policy management of the network product is configured to use the timer delay after each incorrect password input.

2. The password policy management is configured to block an account following a specified number of incorrect password attempts (typically 5).

3. The web interface should be configured with CAPTCHA feature to prevent automated attempts.

4. CAPTCHA feature is optional and test is done only if implemented.

5. A password disallow list is configured by the tester. At least one disallow list password (a password that meets the complexity criteria but is disallow listed) is documented.

NOTE 2: Password management and disallow list configuration may be done in a separate node that is different to the node under test, e.g. a SSO server or any other central credential manager.

1. Tester has valid credentials as an authorized user.

2. If the recommended protection measures mentioned in the Requirement Description are not implemented in the Network Product, the vendor provides a documentation describing the alternative measures that are implemented instead.

Execute the following steps:

A. Positive Test

Case 1:

Test case to use the timer delay after each incorrect password input is covered in clause 4.2.3.4.5.

Case 2:

Test case to block an account following a specified number of incorrect attempts is covered in clause 4.2.3.4.5.

Case 3:

If the network product's login web interface is configured with a CAPTCHA feature, the tester enters the valid password and correct CAPTCHA.

Case 4:

If the recommended protection measures mentioned in the Requirement Description are not implemented in the Network Product, the tester checks if the alternative measures described in the vendor provided documentation are meaningful and develops suitable test cases to verify their correct implementation.

In some cases the network product class can have two or more of the attack prevention methods available, which are a combination of Cases 1-3. In such cases the tester will need to run a combination of these test cases.

B. Negative Test

Case 1:

Test case to use the timer delay after each incorrect password input is covered in clause 4.2.3.4.5.

Case 2:

Test case to block an account following a specified number of incorrect attempts is covered in clause 4.2.3.4.5.

Case 3:

If the network product's login web interface is configured with a CAPTCHA feature, the tester enters the valid password without and with incorrect CAPTCHA.

Case 4:

1. The tester tries to change the password to the disallow listed password.

A. Positive Test

Case 1:

Expected result for the test case to use the timer delay after each incorrect password input is covered in clause 4.2.3.4.5.

Case 2:

Expected result for the test case to block an account following a specified number of incorrect attempts is covered in clause 4.2.3.4.5.

Case 3:

Tester can login only after entering the correct password and CAPTCHA.

Case 4:

The tester assesses the alternative measures for brute force and dictionary attack mitigation as meaningful and all developed test cases can be completed successfully.

B. Negative Test

Case 1:

Expected result for the use the timer delay after each incorrect password input is covered in clause 4.2.3.4.5.

Case 2:

Expected result for the test case to block an account following a specified number of incorrect attempts is covered in clause 4.2.3.4.5.

Case 3:

Tester cannot successfully log in to the network product.

Case 4:

Tester cannot successfully change the password to the disallow listed password.

Evidence suitable for the interface, e.g. screenshot containing the operation result.

Protection against brute force and dictionary attacks

If a password is used as an authentication attribute, a protection against brute force and dictionary attacks that hinder password guessing shall be implemented.

Brute force and dictionary attacks aim to use automated guessing to ascertain passwords for user and machine accounts. Various measures or a combination of these measures can be taken to prevent this.

The most commonly used protection measures are:

1. Using the timer delay (this delay could be the same or increased depending the operator's policy for each attempt, e.g. double the delay, or 5 minutes delay, or 10 minutes delay) for each newly entered password input following an incorrect entry ("tar pit").

2. Blocking an account following a specified number of incorrect attempts, refer to 4.2.3.4.5. However it has to be taken into account that this solution needs a process for unlocking and an attacker can force this to deactivate accounts and make them unusable.

3. Using CAPTCHA to prevent automated attempts (often used for Web applications).

4. Using a password blacklist to prevent vulnerable passwords.

NOTE 1: Password management and blacklist configuration may be done in a separate node that is different to the node under test, e.g. a SSO server or any other central credential manager.

In order to achieve higher security, it is often meaningful to combine two or more of the measures named here. It is left to the vendor to select appropriate measures.

Above requirements shall be applicable for all passwords used (e.g. application-level, OS-level, etc.). An exception to this requirement is machine accounts.

To ensure that the system uses a mechanism with adequate protection against brute force and dictionary attacks

To check whether system follows commonly used preventive measures which are mentioned below.

1. Using the timer delay (e.g. doubling wait times after every incorrect attempt, or 5 minutes delay, or 10 minutes delay) after each incorrect password input ("tar pit").

2. Blocking an account following a specified number of incorrect attempts (typically 5). However administrator has to keep in account that this solution needs a process for unlocking and an attacker can utilize this process to deactivate the accounts and make them unusable.

3. Using CAPTCHA to prevent automated attempts (often used for Web interface).

4. Using a password blacklist to prevent vulnerable passwords.

1. The password policy management of the network product is configured to use the timer delay after each incorrect password input.

2. The password policy management is configured to block an account following a specified number of incorrect password attempts (typically 5).

3. The web interface should be configured with CAPTCHA feature to prevent automated attempts.

4. CAPTCHA feature is optional and test is done only if implemented.

5. A password blacklist is configured by the tester. At least one blacklisted password (a password that meets the complexity criteria but is blacklisted) is documented.

NOTE 2: Password management and blacklist configuration may be done in a separate node that is different to the node under test, e.g. a SSO server or any other central credential manager.

Tester has valid credentials as an authorized user.

Execute the following steps:

A. Positive Test

Case 1:

Test case to use the timer delay after each incorrect password input is covered in clause 4.2.3.4.5.

Case 2:

Test case to block an account following a specified number of incorrect attempts is covered in clause 4.2.3.4.5.

Case 3:

In some cases the network product class can have two or more of the attack prevention methods available, which are a combination of Cases 1-3. In such cases the tester will need to run a combination of these test cases.

B. Negative Test

Case 1:

Test case to use the timer delay after each incorrect password input is covered in clause 4.2.3.4.5.

Case 2:

Test case to block an account following a specified number of incorrect attempts is covered in clause 4.2.3.4.5.

Case 3:

Case 4:

The tester tries to change the password to the blacklisted password.

A. Positive Test

Case 1:

Expected result for the test case to use the timer delay after each incorrect password input is covered in clause 4.2.3.4.5.

Case 2:

Expected result for the test case to block an account following a specified number of incorrect attempts is covered in clause 4.2.3.4.5.

Case 3:

Tester can login only after entering the correct password and CAPTCHA.

B. Negative Test

Case 1:

Expected result for the use the timer delay after each incorrect password input is covered in clause 4.2.3.4.5.

Case 2:

Expected result for the test case to block an account following a specified number of incorrect attempts is covered in clause 4.2.3.4.5.

Case 3:

Tester cannot successfully log in to the network product.

Case 4:

Evidence suitable for the interface, e.g. screenshot containing the operation result.

TR 33.926 [4]

Hiding password display

In accordance with industry best practice

The password shall not be displayed in such a way that it could be seen and misused by a casual local observer. Typically, the individual characters of the password are replaced by a character such as "*". Under certain circumstances an individual character may be displayed briefly during input. Such a function is used, for example, on smartphones to make input easier. However, the entire password is never output to the display in plaintext.

Above requirements shall be applicable for all passwords used (e.g. application-level, OS-level, etc.). An exception to this requirement is machine accounts.

Verify that the given password is not visible to the casual local observer.

Tester has account with username and password in the network product.

Execute the following steps:

1. The network product will display the login screen.

2. The tester enters the username.

3. The tester enters the password.

The password shall not be displayed in such a way that it could be seen and misused by a casual local observer. Typically, the individual characters of the password are replaced by a character such as "*". Under certain circumstances an individual character may be displayed briefly during input. Such a function is used, for ex ample, on smartphones to make input easier. However, the entire password is never output to the display in plaintext.

Evidence suitable for the interface, e.g. screenshot contains the operation results.

Verify that the given password is not visible to the casual local observer.

Tester has account with username and password in the network product.

Execute the following steps:

1. The network product will display the login screen.

2. The tester enters the username.

3. The tester enters the password.

Evidence suitable for the interface, e.g. screenshot contains the operation results.

TR 33.926 [4]

Network Product Management and Maintenance interfaces

In accordance with industry best practice

The network product management shall support mutual authentication mechanisms, the mutual authentication mechanism can rely on the protocol used for the interface itself or other means.

Verify that:

There is mutual authentication of entities for management interfaces on the network product.

Documentation that lists each of the management protocols and describes the authentication mechanism used for each one.

1. The tester checks that the authentication mechanisms have been configured on the network product.

2. The tester triggers communication between network product and a test entity that has a legitimate authentication credential.

3. Then, the tester triggers communication between network product and a test entity that doesn't have a legitimate authentication credential.

• Mutual authentication is successful and communication between network product and the entity with correct credentials can be established.

• Mutual authentication fails and communication between the network product and the entity with incorrect credentials cannot be established.

Test result pass/fail recorded by tester.

Network Product Management and Maintenance interfaces

The network product management shall support mutual authentication mechanisms, the mutual authentication mechanism can rely on the protocol used for the interface itself or other means.

Verify that:

There is mutual authentication of entities for management interfaces on the network product.

Documentation that lists each of the management protocols and describes the authentication mechanism used for each one.

1. The tester checks that the authentication mechanisms have been configured on the network product.

2. The tester triggers communication between network product and a test entity that has a legitimate authentication credential.

3. Then, the tester triggers communication between network product and a test entity that doesn't have a legitimate authentication credential.

• Mutual authentication is successful and communication between network product and the entity with correct credentials can be established.

• Mutual authentication fails and communication between the network product and the entity with incorrect credentials cannot be established.

Test result pass/fail recorded by tester.

TR 33.926 [4]

Policy regarding consecutive failed login attempts

In accordance with industry best practice

a. The maximum permissible number of consecutive failed user account login attempts should be configurable by the network operator. The definition of the default value set at manufacturing time for maximum number of failed user account login attempts shall be less than or equal to 8, typically 5. After the maximum permissible number of consecutive failed user account login attempts is exceeded by a user there shall be a block delay in allowing the user to attempt login again. This block delay and also the capability to set period of the block delay, e.g. double the delay, or 5 minutes delay, or 10 minutes delay, after each login failure should be configurable by the network operator. The default value set at manufacturing time for this delay shall be greater than or equal to 5 sec.

b. If supported, infinite (permanent) locking of an account that has exceeded maximum permissible number of consecutive failed user account login attempts should also be possible via configuration, with the exception of administrative accounts which shall get only temporarily locked.

To ensure that the policy regarding failed login attempts is adhered to.

Case 1: Testing for requirement 4.2.3.4.5 a)

1. At least one user account has been created as per vendor instructions.

2. Directions of how to configure the maximum permissible number of consecutive failed user account login attempts and the default value of this number are identified in the documentation accompanying the Network Product. Default value shall be stated as well.

3. Directions of how to configure the block delay in allowing a user attempt to login again when the number of failed login attempts has exceeded the maximum number are identified in the documentation accompanying the Network Product. Default value of the delay shall be stated as well.

The tester is required to execute the following steps:

1. Check default values from precondition 2 and 3.

2. Perform consecutive failed login attempts for the user account until the default maximum number of precondition 2 is reached.

3. Attempt again one extra login, which fails again.

4. Attempt one extra login in less time than the default for the delay of precondition 3, using the correct credentials.

5. Attempt one extra login in more time than the default for the delay of precondition 3, using the correct credentials.

1. Default values from precondition 2 and 3 are in accordance with the requirement.

2. In execution step 2, 3 and 4, the login attempt shall be rejected in all cases.

3. In execution step 5, it is verified that the user can login only at the last login attempt.

Evidence containing the results of all login attempts, e.g. screenshots, log files, configurations, error messages.

Case 2: Testing for requirement 4.2.3.4.5 b)

b. If supported, infinite (permanent) locking of an account that has exceeded maximum permissible number of consecutive failed user account login attempts should also be possible via configuration, with the exception of administrative accounts which shall get only temporarily locked.

To ensure that the policy regarding failed login attempts is adhered to.

Case 1: Testing for requirement 4.2.3.4.5 a)

1. At least one user account has been created as per manufacturer's instructions.

2. Directions of how to configure the maximum permissible number of consecutive failed user account login attempts and the default value of this number are identified in the documentation accompanying the Network Product. Default value shall be stated as well.

3. Directions of how to configure the block delay in allowing a user attempt to login again when the number of failed login attempts has exceeded the maximum number are identified in the documentation accompanying the Network Product. Default value of the delay shall be stated as well.

1. Check default values from precondition 2 and 3.

2. Perform consecutive failed login attempts for the user account until the default maximum number of precondition 2 is reached.

3. Attempt again one extra login, which fails again.

4. Attempt one extra login in less time than the default for the delay of precondition 3, using the correct credentials.

5. Attempt one extra login in more time than the default for the delay of precondition 3, using the correct credentials.

1. Default values from precondition 2 and 3 are in accordance with the requirement.

2. In execution step 4, the login attempt shall be rejected in all cases.

3. In execution step 5, the login attempt shall be accepted.

4. In execution step 6, it is verified that the user can login only at the last login attempt.

Case 2: Testing for requirement 4.2.3.4.5 b)

TR 33.926 [4]

Policy regarding consecutive failed login attempts

In accordance with industry best practice

a. The maximum permissible number of consecutive failed user account login attempts should be configurable by the network operator. The definition of the default value set at manufacturing time for maximum number of failed user account login attempts shall be less than or equal to 8, typically 5. After the maximum permissible number of consecutive failed user account login attempts is exceeded by a user there shall be a block delay in allowing the user to attempt login again. This block delay and also the capability to set period of the block delay, e.g. double the delay, or 5 minutes delay, or 10 minutes delay, after each login failure should be configurable by the network operator. The default value set at manufacturing time for this delay shall be greater than or equal to 5 sec.

b. If supported, infinite (permanent) locking of an account that has exceeded maximum permissible number of consecutive failed user account login attempts should also be possible via configuration, with the exception of administrative accounts which shall get only temporarily locked.

To ensure that the policy regarding failed login attempts is adhered to.

Case 1: Testing for requirement 4.2.3.4.5 a)

1. At least one user account has been created as pervendor 's instructions.

2. Directions of how to configure the maximum permissible number of consecutive failed user account login attempts and the default value of this number are identified in the documentation accompanying the Network Product. Default value shall be stated as well.

3. Directions of how to optionally configure permanent locking for non-administrative accounts shall be stated as well.

The accredited evaluator's test lab is required to execute the following steps:

1. Check default values from precondition 2.

2. Perform consecutive failed login attempts for the user account until the default maximum number of precondition 2 is reached.

3. Attempt again one extra login, which fails again.

4. Attempt one extra login in more time than the default for the delay of precondition 3, using the correct credentials.

5a. If supported enable permanent locking of accounts exceeding the maximum permissible number of consecutive failed user account login attempts and repeat steps 1-4 for an unprivileged user.

5b. If supported enable permanent locking of accounts exceeding the maximum permissible number of consecutive failed user account login attempts and repeat steps 1-4 for a user with administrative access rights.

In execution step 5a it is verified that the user cannot login at any execution step.

In execution step 5b it is verified that an administrator user can successfully login only at execution step 5b.

Evidence containing the results of all login attempts, e.g. screenshots, log files, configurations, error messages.

b. If supported, infinite (permanent) locking of an account that has exceeded maximum permissible number of consecutive failed user account login attempts should also be possible via configuration, with the exception of administrative accounts which shall get only temporarily locked.

To ensure that the policy regarding failed login attempts is adhered to.

Case 1: Testing for requirement 4.2.3.4.5 a)

1. At least one user account has been created as per manufacturer's instructions.

2. Directions of how to configure the maximum permissible number of consecutive failed user account login attempts and the default value of this number are identified in the documentation accompanying the Network Product. Default value shall be stated as well.

3. Directions of how to optionally configure permanent locking for non-administrative accounts shall be stated as well.

The accredited evaluator's test lab is required to execute the following steps:

1. Check default values from precondition 2.

2. Perform consecutive failed login attempts for the user account until the default maximum number of precondition 2 is reached.

3. Attempt again one extra login, which fails again.

4. Attempt one extra login in more time than the default for the delay of precondition 3, using the correct credentials.

5b. If supported enable permanent locking of accounts exceeding the maximum permissible number of consecutive failed user account login attempts and repeat steps 1-4 for a user with administrative access rights.

In execution step 5a it is verified that the user cannot login at any execution step.

In execution step 5b it is verified that an administrator user can successfully login only at execution step 5b.

TR 33.926 [4]

verify authorization policy is in place and that user access and data access in the system are according to the authorization policy.

Authorization policy

In accordance with industry best practice

The authorizations for accounts and applications shall be reduced to the minimum required for the tasks they have to perform.

Authorizations to a system shall be restricted to a level in which a user can only access data and use functions that he needs in the course of his work. Suitable authorizations shall also be assigned for access to files that are components of the operating system or of applications or that are generated by the same (e.g. configuration and logging files).

Alongside access to data, execution of applications and components shall also take place with rights that are as low as possible. Applications should not be executed with administrator or system rights.

Documentation describing the authorization policy defined for the system including details on the lowest access rights assigned to user accounts, access to data, application execution and components.

1. Assign access rights (e.g. read only) to user accounts, data files, and applications.

2. Operations, that are allowed as per authorization policy (as defined in the network product documentation), are attempted via the different user accounts, data files, and applications.

1. User accounts, data files, and applications are allowed to be accessed (e.g. able to read but not write to a file, able to execute an application as a user account without administrator rights, etc.) according to the access rights assigned.

2. User accounts, data files, and applications are not allowed to be accessed above the access rights assigned (e.g. able to write to a read only file, able to execute an application as an administrator, etc.).

Pass/fail results as recorded by the tester.

The authorizations for accounts and applications shall be reduced to the minimum required for the tasks they have to perform.

Authorizations to a system shall be restricted to a level in which a user can only access data and use functions that he needs in the course of his work. Suitable authorizations shall also be assigned for access to files that are components of the operating system or of applications or that are generated by the same (e.g. configuration and logging files).

Alongside access to data, execution of applications and components shall also take place with rights that are as low as possible. Applications should not be executed with administrator or system rights.

Documentation describing the authorization policy defined for the system including details on the lowest access rights assigned to user accounts, access to data, application execution and components.

1. Assign access rights (e.g. read only) to user accounts, data files, and applications.

2. Operations, that are allowed as per authorization policy (as defined in the network product documentation), are attempted via the different user accounts, data files, and applications.

1. User accounts, data files, and applications are allowed to be accessed (e.g. able to read but not write to a file, able to execute an application as a user account without administrator rights, etc.) according to the access rights assigned.

2. User accounts, data files, and applications are not allowed to be accessed above the access rights assigned (e.g. able to write to a read only file, able to execute an application as an administrator, etc.).

Pass/fail results as recorded by the tester.

TR 33.926 [4]

Role-based access control

In accordance with industry best practice

The network product shall support Role Based Access Control (RBAC). A role-based access control system uses a set of controls which determines how users interact with domains and resources. The domains could be Fault Management (FM), Performance Management (PM), System Admin, etc. The RBAC system controls how users or groups of users are allowed access to the various domains and what type of operation they can perform, i.e. the specific operation command or command group (e.g. View, Modify, Execute).

The network product supports RBAC, in particular, for O&M privilege management for network product Management and Maintenance, including authorization of the operation for configuration data and software via the network product console interface.

Verify that users are granted access with role-based privileges.

Documentation describing the role based access control system including details on which user roles are defined.

1. User accounts which are assigned to different access roles are created.

2. Operations, that are allowed by different roles (as defined in the network product documentation), are attempted via the different user accounts.

1. Users that are assigned to a role that is not allowed to execute an operation are prevented from executing the operation.

2. Users that are assigned to a role that is allowed to execute an operation can successfully execute the operation.

Pass/fail results as recorded by the tester.