Secure Channel Clause Samples

Secure Channel. Optionally, the media channel may be secured (encrypted and authenticated) via SRTP/SRTCP. The channel is considered to be secure when the two communicating devices have negotiated secure media and the security association parameters. How the security associations are accomplished is outside the scope of this document; however the following are generally relevant considerations to a TIP device implementation: First, the security establishment process occurs before any media related activity occurs on the UDP channel. Second, with a secure media channel, Datagram Transport Layer Security (DTLS) [13, 14] packets may also occur within the media channel. These packets can be de- multiplexed from RTP traffic by examination of the first byte of the packet. The details are described in section 5.1.2 of [14]. Third, once security association is established, secure TIP negotiation can start For a message flow of a secure TIP control channel setup using DTLS, refer to section 7.2. The following are specific TIP protocol items used to facilitate multipoint encryption: TIP devices MAY use Encrypted Key Transport (EKT) extension to SRTP [12] to coordinate SRTP contexts between transmitters and receivers in a multipoint session where the MCU does not decrypt and re-encrypt packets. Note that a TIP endpoint MUST NOT encrypt the Audio Activity Metric (see section 4.2.5.2) or the Video Refresh Flag (see section 4.2.5.4), so that entities such as MCU do not need to perform crypto operations to read the relevant information. A TIP MCU device that sets the TIP multipoint focus parameter (see section 4.2.1) has negotiated EKT capability if it is communicating with an endpoint that has indicated in TIP its ability to receive EKT security parameters (see section 4.2.5). A TIP endpoint has negotiated EKT capability if it is communicating with a TIP MCU that has indicated in TIP its ability to transmit EKT security parameters (see section 4.2.5). A TIP MCU that has negotiated EKT capability MUST send an SPIMAP (see section 4.2.6) packet every 250 msec until one or more of the following conditions are met: a- MCU receives an ACK packet for its SPIMAP packet. b- MCU receives an SRTP or SRTCP packet with an EKT extension that has the SPI value that was specified in the SPIMAP packet c- After recommended interval of 5 seconds have passed In the above (a) & (b) conditions, the MCU should consider EKT negotiated. In condition (c), the MCU MUST consider EKT negotiation to have failed. An...

Secure Channel. All internet-facing connections established under a Framework Agreement shall utilize the Internet Engineering Task Force (IETF) Transport Layer Security (TLS) protocol,10 version 1.2 with BCP-195,11 or a later version of TLS, as further specified in the Secure Channel requirements of the QTF. 12 This will help enable the TLS-protected communication channel to operate with appropriate levels of protection and prohibit less secure methods. Timeline to adopt: This requirement shall be implemented within six (6) months of the SOP publication date.