The FPT_STM_EXT.1 SFR currently mandates support for Autokey per RFC 5906 when using Network Time Protocol (NTP). However, several well publicized weaknesses exist in Autokey such that timestamps could be modified without any indication.

15 July 2019: This TD has been archived and superseded by TD0429.

FTP_STM.1.1 is modified as follows:

FPT_STM.1.1 The TSF shall be able to provide reliable time stamps.

Application Note            

Reliable time stamps are expected to be used with other TSF, e.g. for the generation of audit data to allow the Security Administrator to investigate incidents by checking the order of events and to determine the actual local time when events occurred. The decision about the required level of accuracy of that information is up to the administrator. The TOE depends on external time and date information, either provided manually by the Security Administrator or through the use of an NTP server. The use of a local real-time clock and the automatic synchronization with an NTP server is recommended but not mandated. The ST Author specifies the means which are used to update system time in FMT_MTD.1/SystemTime Management of TSF Data. The ST author describes in the TSS how the external time and date information is received by the TOE and how this information is maintained. 

FMT_MTD.1 is added as follows:

FMT_MTD.1/SystemTime Management of TSF Data

FMT_MTD.1.1/SystemTime The TSF shall restrict the ability to modify the System Time to Security Administrators (locally or remotely), and by [selection: an NTP Server authorized by the Security Administrator, no other means].

 Application Note

If a Security Administrator is modifying the system time remotely, they will, of course, have to use a protected communication path as specified in FPT_TRP.1/Admin. If the ST Author selects the NTP Server option, then the ST Author must select the FPT_STM_EXT.1 in Appendix B, or they must include “NTP Server” in the open assignment in FTP_ITC.1.1.

FTP_ITC.1.1 SFR is replaced as follows:

FTP_ITC.1.1 Refinement: The TSF shall be capable of using TLS, and [selection: NTPv3 (RFC 1305), NTPv4 (RFC5905)], Ipsec, SSH, HTTPS, SNMPv3, no other protocol] to provide a trusted communication channel between itself and authorized IT entities supporting the following capabilities: audit server, NTP server, [selection: authentication server, [assignment: other capabilities]] that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from disclosure and detection of modification of the channel data.

Application Note:

The ST Author may need to iterate this requirement for clarity if multiple protocols are used for multiple purposes (e.g., IPSec is used to protect the communication path with the NTP server, and TLS is used to protect the path to the audit server).  TLS is mandated for SIP trunking as required in FIA_SIPT_EXT.1.4. The NTPv3 and NTPv4 selections are available to protect the channel between the TOE and an NTP Server.  However, if an NTP server is used, but it's protected by a means other than NTPv3 or NTPv4, it still must protect the channel between the TOE and the NTP server using TLS or one of the other selections.

FPT_STM_EXT.1 is added to Appendix B as follows:

FPT_STM_EXT.1: Protection of System Time updates

FPT_STM_EXT.1.1 The TSF shall implement [selection: NTP v3 (RFC 1305), NTP v4 (RFC 5905)] NTP versions.

FPT_STM_EXT.1.2 The TSF shall update its system time using [selection:

·         Authentication of the NTP Time Source using [selection: SHA1, SHA256, SHA384, SHA512, AES-128-CBC, AES-256-CBC] as the message diget algorithm(s);

·         [selection: IPsec, DTLS] to provide trusted communication between itself and an NTP time source.]

FPT_STM_EXT.1.3 The TSF shall not update NTP timestamp from broadcast addresses.

Application note: The broadcast and multicast addresses are deems as any addressing scheme designed to be one-to-many.

FPT_STM_EXT.1.4 The TSF shall support configuration of at least three (3) NTP time sources.

Application note:  The TOE has to support configuration of at least 3 time sources though it is not mandated that the TOE is configured to always use at least 3 time sources.

Assurance Activities

TSS

The evaluator shall examine the TSS to ensure it describes what approach the TOE uses to ensure the timestamp it receives from an NTP time server (or NTP peer) is from an authenticated source and the integrity of the time has been maintained.

The TOE must support at least one of the methods or may use multiple methods, as specified in the SFR element 1.2. The evaluator determines that each method selected in the ST is described in the TSS, including the version of NTP supported in element 1.1, the message digest algorithms used to verity the authenticity of the timestamp and the protocols used to insure integrity of the timestamp.

Guidance Documentation

The evaluator shall examine the guidance documentation to ensure it provides the administrator instructions on how to configure the version of NTP supported in element 1.1 and how to configure the TOE to use the method(s) as specified in the SFR element 1.2 that are selected in the ST. The evaluator shall also examine the guidance documentation to ensure it provides the administrator instructions on how to configure support for multiple NTP servers for the TOE's time source.

For each of the SFR element 1.2 method selections made in the ST, the evaluator shall examine the guidance documentation to ensure it instructs the administrator how to configure the TOE to use the messge digest algorithms that support the authenticity of the timestamp and/or how to configure the TOE to use the protocols that ensure the integrity of the timestamp.

The evaluator shall examine the guidance documentation to ensure it provides the administrator instructions on how to configure the TOE to not accept broadcast and multicast NTP packets that would result in the timestamp being updated.

Test

The version of NTP specified in the element 1.1 shall be verified by observing establishment of a connection to an external NTP server known to be using the specificed version(s) of NTP. This may be combined with test of other aspects of FPT_STM_EXT.1 as described below. The cryptographic algorithms selected in element 1.2 and specified in the ST will have been specified in an FCS_COP SFR and tested in the accompanying Evaluation Activity for that SFR. Likewise the cryptographic protocol selected in element 1.2 and specified in the ST will have been specified in an FCS SFR and tested in the accompanying Evaluation Activity for that SFR.

The evaluator shall use a packet sniffer to capture the network traffic between the TOE and the NTP server. The evaluator uses the captured network traffic, to verify the NTP version, to observe time change of the TOE and uses the TOE’s audit log to determine that the TOE accepted the NTP server’s timestamp update. 

The captured traffic is also used to verify that the appropriate message digest algorithm was used to authenticate the time source and/or the appropriate protocol was used to ensure integrity of the timestamp that was transmitted in the NTP packets.

The evaluator will perform the following test(s) to verify the TOE implements the selected option(s) correctly:

Test 1: The evaluator shall configure an NTP server to use the NTP version selected in element 1.1 and the method(s) selected in element 1.2 by the ST Author to communicate with the NTP client, the TOE.  The evaluator then changes either the NTP server’s clock or the TOE’s clock such that the TOE will update its time when it receives a packet from the NTP server.  The difference in time must be enough to force a step in time on the TOE and to be observable by examining the TOE’s system time before and after the event.

Test 2:  [Conditional] If the message digest algorithm is claimed in element 1.2, the evaluator will change the message digest algorithm used by the NTP server in such a way that new value does not match the configuration on the TOE and confirms that the TOE does not synchronize to this time source. 

Test 3:  The evaluator shall configure NTP server(s) to support periodic time updates to broadcast and multicast addresses.  The evaluator shall confirm the TOE is configured to not accept broadcast and multicast NTP packets that would result in the timestamp being updated.  The evaluator shall check that the time stamp is not updated after receipt of the broadcast and multicast packets.

Test 4:  The evaluator shall confirm the TOE supports configuration of at least three (3) NTP time sources.  The evaluator shall configure at least three NTP servers to support periodic time updates to the TOE.  The evaluator shall confirm the TOE is configured to accept NTP packets that would result in the timestamp being updated from each of the NTP servers. The evaluator shall check that the time stamp is updated after receipt of the NTP packets.

Test 5:  The evaluator shall also confirm that the TOE does not synchronize to any other time sources by configuring another NTP source operating in the server mode and inducing (e.g. send synch request with a forged source IP address) it to send timestamp updates to the TOE. The evaluator shall check that the TSF does not act on the received NTP updates and does not update system time.  The evaluator shall confirm that the time stamp is not updated for a valid reason (e.g. failure to recognize NTP authentication key or rejection of unrequested NTP synchronization).

Section 5.1.1.5 FMT_SMF.1 Specification of Management Functions is modified as follows:

5.1.1.5 FMT_SMF.1 Specification of Management Functions

Additional management functions extend the FMT_SMF.1 SFR found in the NDcPP. The following functions shall be combined with those of the NDcPP in the context of a conforming Security Target. Ability of a Security Administrator to:

·         Change a user’s password

·         Require a user’s password to be changed upon next login

·         Configure the auditable events that will result in the generation of an alarm

·         Configure the back-to-back user agent policy

·         Configure traffic filtering rules

·         Configure NAT

·         Configure SIP communications

·         [selection: configure NTP].

Application Note: The selection “configure NTP” shall be included in the ST if the TOE uses NTP for timestamp configuration.  If selected, FPT_STM_EXT.1 shall be included in the ST as well.