NIAP: View Technical Decision Details
NIAP/CCEVS
  NIAP  »»  Protection Profiles  »»  Technical Decisions  »»  View Details  
Archived TD0128:  Updates to FTP_ITC.1 in ND cPP SBC EP v1.0

Publication Date
2016.12.22

Protection Profiles
CPP_ND_SBC_EP_V1.0

Other References
CPP_ND_SBC_EP_V1.0; FTP_ITC.1

Issue Description
  1. FTP_ITC.1 mandates both SRTP and SNMP for communications with external entities such as audit or NTP servers.  SRTP is not used for these communications and while SBCs are capable of sending SNMP traps to receivers, such as audit servers, this should be a selection-based functionality.
  2. The Application Note for FTP_ITC.1 contains a typo in which it references MACSEC. The entirety of the Application Note can be removed.
  3. FTP_ITC.1(2) mandates DTLS. However, DTLS is not typically used for VoIP signaling and should be removed. SRTP will be mandated, the other protocols moved into the selection.
  4. FTP_ITC.1(4) mandates the TOE provide H.323 communications, however, this is only necessary if H.323 is supported by the TOE, through selection in FFW_ACL_EXT and/or FFW_DPI_EXT.1.
Resolution

Change FTP_ITC.1.1, Section 4.2.1.9, as follows:

FTP_ITC.1.1 Refinement: The TSF shall be capable of using TLS, and [selection: 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.

Change FTP_ITC.1(2), Section 4.2.2.15, as follows:

FTP_ITC.1.1(2) Refinement: The TSF shall be capable of using SRTP, [selection: SIP-TLS, IPsec, H.235, [assignment: other protocols]] to provide a trusted communication channel between itself and authorized IT entities supporting the following capabilities: VVoIP signaling and media channels that are logically distinct from other communication channels and provide assured identification of its end points and protection of the channel data from disclosure and detection of modification of the channel data.

Remove Section 4.2.2.17 (FTP_ITC.1(4)) and insert it into Appendix C -- Selection-Based Requirements as follows:

C.2 FTP_ITC.1(4) Inter-TSF Trusted Channel

Application Note: FTP_ITC.1 is not iterated in the NDcPP. The ST author shall identify the SFR defined in the NDcPP (as refined in section 4.2.1.9 of this EP) as FTP_ITC.1(1) so that the correct iteration convention is followed. This SFR is claimed if H.323 is specified as being supported by the TOE in FFW_ACL_EXT and/or FFW_DPI_EXT.

FTP_ITC.1.1(4) Refinement: The TSF shall provide an H.323 communication channel in accordance with ITU-REC H.235.0 between itself and a gatekeeper using TLS as specified in FCS_TLSC_EXT.2 and [selection: IPsec as specified in FCS_IPSEC_EXT.1, no other protocol] that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from modification or disclosure.

FTP_ITC.1.2(4) The TSF shall permit the TSF to initiate communication via the trusted channel.

FTP_ITC.1.3(4) The TSF shall initiate communication via the trusted channel for [all communications with the gatekeeper].

Assurance Activity

This SFR is an iteration of FTP_ITC.1 as defined in the NDcPP. The evaluator shall repeat the assurance activities defined for FTP_ITC.1 in the NDcPP for this iteration of the SFR.

Justification

See issue description above.

 
 
Site Map              Contact Us              Home