NIAP: View Technical Decision Details
NIAP/CCEVS
  NIAP  »»  Protection Profiles  »»  Technical Decisions  »»  View Details  
Archived TD0159:  FPT_STM.1.1 - Reliable Time Stamps

Publication Date
2017.04.11

Protection Profiles
EP_ESC_V1.0

Other References
FPT_STM.1.1; FMT_MTD.1; FTP_ITC.1

Issue Description

The autokey session keys are formed in a non-FIPS/CC compliant manner “The four values are hashed using the MD5 algorithm to produce the 128-bit autokey value, which in the reference implementation is stored along with the key ID in a cache used for symmetric keys as well as autokeys.  Keys are retrieved from the cache by key ID using hash tables and a fast lookup algorithm." Typically, session keys for a protocol rely on secure cryptographic input such as the SP 800-135rev1 KDFs used for TLS/SSH/IPsec etc, however MD5 provides no strength for the derivation of the values into an autokey session key.  Therefore, the X509v3 certificate exchange in the protocol would be considered secure, but without strong autokey session keys any security provided by the use of strong certificates would be irrelevant.

Resolution

May 22, 2019: This TD has been archived and replaced by TD0418

Revision:

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

Application Note 1            

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/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 X, or they must include “NTP Server” in the open assignment in FTP_ITC.1.1.

[The following is a selection-based SFR]

FPT_STM_EXT.1 Protection of System Time updates

FPT_STM_EXT.1 The TSF shall use Network Time Protocol version 4 (NTPv4) as specified in RFC 5905, configuring the optional message authentication code (MAC) for symmetric key authentication scheme and Autokey as specified in RFC 5906 using the following identity schemes: [selection: private certificate (PC), trusted certificate  (TC), a modified Schnorr algorithm (IFF - Identify Friend or  Foe), a modified Guillou-Quisquater (GQ) algorithm, a  modified Mu-Varadharajan (MV) algorithm].

 Application Note

Use of this SFR indicates the TOE provides an NTP client that implements NTPv4 and complies with the corresponding standard. From RFC 5906 “There are five schemes now implemented in the NTPv4 reference implementation to prove identity: (1) private certificate (PC), (2)  trusted certificate (TC), (3) a modified Schnorr algorithm (IFF aka  Identify Friendly or Foe), (4) a modified Guillou-Quisquater (GQ)  algorithm, and (5) a modified Mu-Varadharajan (MV) algorithm. Not  all of these provide the same level of protection and one, TC,  provides no protection but is included for comparison.”

 [If in FMT_MTD.1.1/SystemTime NTP is selected, either the above SFR, FPT_STM_EXT.1, is used, or this version of FTP_ITC.1 is used]

FTP_ITC.1                           Inter-TSF trusted channel

FTP_ITC.1.1 The TSF shall be capable of using [selection: IPsec, SSH, TLS, HTTPS] 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.

FTP_ITC.1.2 The TSF shall permit the TSF, or the authorized IT entities to initiate communication via the trusted channel.

FTP_ITC.1.3 The TSF shall initiate communication via the trusted channel for updating system time (NTP)  [assignment: list of services for which the TSF is able to initiate communications].

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).

 

Justification

The following revision is consistent with the NIAP proposal to the ND iTC.

 
 
Site Map              Contact Us              Home