However some distributed components will find its “Gatekeeper” based on messaged exchanged in a ‘discovery’ process. Based on attributes returned in those messages it selects a “Gatekeeper” to begin the authentication and join process. This means the “joiner” doesn’t independently build a reference identifier, nor is it possible to configure one. Therefore it’s not accurate to apply RFC 6125 in FCS_TLSC_EXT.1.2 for these distributed TOEs. FCO_CPC_EXT.1 which requires the administrator to enable communications between the pair of TOE components is acceptable/sufficient for distributed TOEs. from the current FCS_TLS_EXT.1 component. This would permit an ST author to select TLS in FPT_ITT.1 (and in FTP_TRP.1/Admin) without the issue as identified in the comment column. The requirement to verify that the presented identifier matches the reference identifier would remain in the FCS_TLS_EXT.2 component, which is required to be selected for TLS connections to external IT entities. NDcPP, A.5.2 FPT_ITT.1 needs to allow use of DTLS as a protocol. For a component to manage another component as described in use case 3, some distributed TOEs may use a different protocol. DTLS is similar to TLS but uses UDP instead of TCP. Due to space limitations see attached document “Suggested Change-Add DTLS” for details. 1 Requestor has been asked to supply a more comprehensive set of DTLS SFR(s) and EAs for consideration by the iTC. This is work in progress now within the iTC.
IPsec in Appendix C is defined as: FCS_IPSEC_EXT.1.11 The TSF shall ensure that all IKE protocols implement DH Groups 14 (2048-bit MODP), and [selection: 14 MODP), 19 (256-bit Random ECP), 5 (1536-bit MODP), 24 (2048-bit MODP with 256-bit POS), 20 (384-bit Random ECP), [assignment: other DH groups that are implemented by the TOE], no other DH groups]. NDcPP, Footnote Page 17 Broken link to the definition Fix the broken link to Exact Conformance definition 3 Broken link has been Section 3, page 19 The term component is used throughout the description of distributed TOEs, with the exception at the end of the first paragraph where ‘elements’ is used. Use the same terminology throughout for clearer understanding and consistency. Change ‘element’ to ‘component’. 3 Language modified to retain consistency. NDcPP, Section 3, page 20 as: “…fulfil the cPP a Management Component may also be offered for use with the product. However…” Change to read: “…fulfil the cPP a Management Component may also be offered for use with the TOE. However…” 3 Language updated in line with suggested change. NDcPP, Page 28, Table 1 FAU_STG.3/LocSpace description reads as “Display wanring for local storage space” Change to read as “Display warning for local storage space” 3 Typo corrected.
NDcPP, Page 29, Table 1 FCS_RBG_EXT.1 is required to be met by all components. If hardware entropy source is defined, such as a chip, how does a management component that is software package (JRE file) that can be loaded on any management workstation meet this requirement? Change to “Feature Dependent” 1 No action taken. A software only TOE component e.g. management component is not support by version 2 of the cPP. Irrespective, FCS_RBG_EXT.1 may be iterated if the product has multiple entropy sources. NDcPP, Page 29, Table 1 FIA_UIA_EXT.1 description reads as “User Identificiation and Authentication” Change to read as “User Identification and Authentication” 3 Typo corrected. NDcPP, Page 44, Section 6, added second paragraph Reads as “…by at least one TOE component or whether they are dependent upon the feature being implemented by the TOE component.” Change to read as “…by at one TOE component or whether they are dependent upon the feature being implemented by one component or the TOE as a whole.” 2 No action as suggested change does not represent the intention of the original language. NDcPP, Page 44, Section 6.1, Iteration The definition for ‘Iterations’ is simply defined as “…a string starting with “/”. “ The format is not well defined and no example is provided, so is the format as follows: FCS_COP.1 /FCS_COP.1 efgh Recommend adding an example of the format. 1 Example added to section 6.1.
/FCS_COP.1 jikl Or as follows: FCS_COP.1/abcde FCS_COP.1/efgh FCS_COP.1/ijkl NDcPP, Page 53, Section 6.3.1.2 Application Note 5 reads as: an auditable event is instigated by another component, the component that records the event must associate the event with the identity of the instigator (applies to distributed TOEs only). Not sure ‘instigated’ and ‘instigator’ are the correct term to use. Recommend the application note be changed to read as: Where an auditable event is triggered by another component, the component that records the event must associate the event with the identity of the user that caused the event (applies to distributed TOEs only). 3 Suggested change not implemented since the intention of the original language was not to imply that the user identity associated with a given event should be captured, rather it was that the initiating component identity should be captured. Language updated to reflect and clarify the original intention. Page 54, Section 6.3.2.1, Fix the spacing in the application note 6, from “….external(FTP_ITC.1) or intercomponent(FPT_ITT.1)….” To: “….external (FTP_ITC.1) or intercomponent (FPT_ITT.1 or FTP_ITC.1)….” 3 Spacing fixed. NDcPP, AppNote 6 “In case the transmission would not be done in real-time the TSS has to provide details Change “the possible” to “that possibility” 3 Application note 6 and 101 updated with new language to clarify intent
Therefore, this RFC should be selectable (i.e., optional) for consistency purpose. a Section 6.5.5.2 Page 65 “FIA_X509_EXT.2.2 When the TSF cannot establish a connection to determine the validity of a certificate, the TSF [selection: allow the administrator to choose whether to accept the certificate in these cases, accept the certificate, not accept the certificate].” We should make it explicitly clear this is only applicable for HTTPS only. For TLS and IPsec, if the peer certificate is invalid for any reason, the connection cannot be established period (See FCS_IPSEC_EXT.1.14 and FCS_TLSC_EXT.1/2.3). 3 Application Note 22 updated to reflect that the selection within FIA_X509_EXT.2.2 should be consistent with FCS_IPSEC_EXT.1.14 and FCS_TLSC_EXT.1/2.3 NDcPP, Section 6.6.3.1 Page 67 Ability to configure the interaction between TOE components; Since distributed TOE is optional, we should make that clear. Ability to configure the interaction between TOE components, if applicable; 3 Suggested change implemented. NDcPP, Section 7.3.2 Page 80 “highlight any situation in which a secret value may be transmitted over a channel that uses a shorter key than the transmitted key” We should use “comparable strengths” from NIST 800-57 asymmetric and symmetric algorithms have different key length. “highlight any situation in which a secret value/key may be transmitted over a channel that uses less comparable strength than the transmitted key” 2 Added reference to comparable strength with high level definition. Reference NIST 800-57 for further guidance. NDcPP, Section C.2.1.1 “FCS_HTTPS_EXT.1.3 The TSF shall [selection: not establish the connection, request authorization to establish the We should make it explicitly clear that the first two options are only applicable if we are claiming a 2 Selection updated to remove the assignment ‘no other action’ option.
Page 97 connection, no other action] if the peer certificate is deemed invalid.” HTTPS client or a HTTPS server that supports mutual authentication. The third option (‘no other action’) is only applicable for HTTPS server that don’t support mutual authentication as there is no peer certificate to verify. NDcPP, AppNote 75 Page 104 “The list of trusted certification authorities can only be selected if or x509v3-ecdsa-sha2-nistp384 are selected in FCS_SSHC_EXT.1.5.” Need to add as well to be consistent with FCS_SSHC_EXT.1.5. 2 Suggested change implemented. Section C.2.1.5/.6 Page 106/108 TLS_RSA_WITH_AES_128_CBC_SHA is removed from mandatory ciphersuite but not added to the optional ciphersuite. Add ciphersuite to the mandatory list. This like an oversight. 2 added in to selection for FCS_TLSC_EXT.1.1 and FCS_TLSC_EXT.2.1 NDcPP, Section 6.4.1.3, page 57 NDcPP SD The cryptographic key destruction methods specified in FCS_CKM.4.1 does not cover all storage types (including SSDs) and are in conflict with some FIPS 140-2 requirements. If a FIPS 140-2 module goes into an error state with keys stored in memory, the module is not permitted to perform any cryptographic operations while an error state (AS09.05) and this would include requesting output from the RBG. Recommended update to FCS_CKM.4: FCS_CKM.4.1 The TSF destroy plaintext cryptographic keys in accordance with a specified cryptographic key destruction method [selection: • For volatile memory the destruction shall be executed by 1 FCS_CKM.4 (and its Evaluation Activities) has been rewritten for this version, and is subject to ongoing discussions for future versions of the cPP. The commenter is requested to review the updated FCS_CKM.4 language during the public review and provide feedback accordingly. nistp521
of TSF Data Protection Profile v1.0.3, Section 6.7.3 TSF testing Application Note 30 states: “For distributed TOEs all TOE components have to perform self-tests.” This language (“have to”) mandates performing of self-tests for “all TOE components”. This is does not align with actual SFR wording or how it is applied to non-distributed TOEs. Clarify Application Note language to better align it with SFR. If mandatory component testing is intended new requirement, consider changing SFR wording to make this clearer. 1 Added additional explanatory paragraph to Application Note 30 which provides additional clarity over the requirement. Protection Profile v1.0.3, Section 6.7.5, Time Stamps Application Note 38 states: “For distributed TOEs it is expected that the administrator ensures synchronization between the time settings of different TOE components.” This application note would likely be misinterpreted to argue that MANUAL time settings is acceptable. Revise application note to clarify that automatic synchronization between components is necessary. 2 Application note 38 reworded to clarify the requirement. Protection Profile v1.0.3, Section 6.5.1 Authentication Failure Management is much needed addition to NDcPP. Unfortunately, FIA_AFL.1.2 as written will lead to usability issues. Administrative Usernames are not presently treated as sensitive and often follow organization-mandated conventions (e.g. FirstLastname). Consequently, for many FIA_AFL I believe IP blocking must be allowed in addition to account blocking or end-users will simply turn off such feature to prevent frequent administrative lockouts. 1 No change. The addition of IP blocking with FIA_AFL requires further discussion by the wider iTC and the commenter is advised to raise this for discussion as part of a future version.
NDcPP: Note 60 Application Note 60 currently make forward looking statements regarding IKEv2 Concurred with the proposed removal of “IKEv2 will be required for those TOEs entering evaluation after Quarter 3, 2016.” 2 Forward looking statement removed from App note 60 NDcPP: Note 68 Application Note 68 currently make forward looking statements regarding ECDSA Concurred with the proposed removal of “Peer authentication using ECDSA X.509v3 certificates will be required for TOEs entering evaluation after Quarter 3, 2015.” 2 Forward looking statement removed from App note 68 NDcPP: Note 73 & 79 There is a forward looking statement in Application Notes 73 and 79 (Relating to FCS_SSHC_EXT.1.5 and FCS_SSHS_EXT.1.5). These applications notes both contained the following statement "Future versions of this profile may remove ssh-rsa as a selection". Concurred with the proposed removal of “Future versions of this profile may remove ssh-rsa as a selection” 2 Forward looking statement removed from App notes 73 and 79 & FCS_SSHS_EXT.1.5 and FCS_SSHC_EXT.1.5 both seemed to be missing selections for curves Concurred with the proposed additional of “-nistp521” curves 2 Nistp521 curves added on on on
must be a hardware appliance. NDcPP: 3.1 Case3, 3rd paragraph It is unclear the word “similar” Network Devices as appose to identical Network Devices. Need to elaborate or define the word “similar” 2 Repeat of #37. The term ‘similar’ has been removed from the description. NDcPP: Table 1 - column “warning” is misspelled in “Display wanring for local storage space” Replace with “warning” 3 Typo corrected NDcPP: Table 1 - column “Identification” is misspelled. “User Identificiation and Authentication” Replace with “Identification” 3 Typo corrected NDcPP: A.1 Audit Events for Optional SFRs – “Management of of cryptographic keys. Remove the extra “of” 3 word removed