Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 23.333  Word version:  18.1.0

Top   Top   Up   Prev   Next
1…   4   5…   5.8…   5.12…   5.14…   5.20…   5.24…   6…   6.1.8…   6.2…   6.2.3…   6.2.4…   6.2.5   6.2.6…   6.2.7…   6.2.8…   6.2.9…   6.2.10…   6.2.10.2.7   6.2.10.3…   6.2.11…   6.2.13…   6.2.13.2.6…   6.2.14…   6.2.15…   6.2.16…   6.2.18…   6.2.19…   6.2.19.3…   6.2.20…   6.2.21…   6.2.22…   6.2.23   6.2.24…   7   8…   8.11…   8.20   8.21   8.22   8.23…   8.30…   8.39…   8.45…   8.56… 
5.20 IMS Media Plane Security  5.20.1 General  5.20.2 End-to-end security for TCP-based media using TLS  5.20.3 Specific requirements for session based messaging (MSRP)  5.20.4 Specific requirements for conferencing (BFCP)  5.21 TCP bearer connection control  5.22 Support of Telepresence  5.22.1 General  5.22.2 Characteristics of the Telepresence support  5.22.3 CLUE data channel establishment  5.22.4 Release of CLUE data channel  5.22.5 CLUE transport between MRFC and MRFP  5.23 SDP Capability Negotiation (SDPCapNeg) 
...

 

5.20  IMS Media Plane Security |R12|  p. 63

5.20.1  General  p. 63

The MRFC and the MRFP may support IMS media plane security as specified in TS 33.328. They may support end-to-end security (e2e) for a TCP (see RFC 793) based media using TLS and the Key Management Service (KMS). The e2e media security of TCP is based on the session keys negotiated via the TLS handshake protocol between the served UE and the MRFP as specified in TS 33.328.
E2e security for TCP based media using TLS and KMS is applicable for MSRP (see RFC 4975; used in IMS session-based messaging conference) and BFCP (see RFC 4582; used in IMS conferencing). The MRFC and the MRFP may support e2e security for MSRP, BFCP, or both protocols.
E2e protection of the MSRP and BFCP sessions is achieved through the KMS and a "ticket" concept:
  • The session initiator requests keys and a ticket from the KMS. The ticket contains the keys in a protected format. The initiator then sends the ticket to the recipient.
  • The recipient presents the ticket to the KMS and the KMS returns the keys on which the media security shall be based.
Up

5.20.2  End-to-end security for TCP-based media using TLS  p. 63

The e2e protection of the TCP based media relies on the usage of TLS according to the TLS profiles specified in Annex E of TS 33.310 and Annex M of TS 33.328.
The end-to-end security protection of session based messaging (MSRP) and conferencing (BFCP) is based on the pre-shared key ciphersuites for TLS (specified in RFC 4279 and with the profile defined in Annex H of TS 33.328) and the MIKEY-TICKET mechanism (specified in RFC 6043 with the profiling of the tickets and procedures given in TS 33.328.
The Pre-Shared Key (PSK) is the Traffic-Encrypting Key (TEK) associated with the Crypto Session (CS) that shall be used in the TLS handshake.
If the MRFC and the MRFP support and are configured to use the e2e protection of the TCP based media using the pre-shared key ciphersuites for TLS and the MIKEY-TICKET mechanism, the following functional requirements apply.
The list of pre-shared key ciphersuites for TLS supported by the MRFP shall be preconfigured in the MRFC.
According to the TLS profile specified in Annex E of TS 33.310, the MRFP shall accept TLS renegotiation only if it is secured according to RFC 5746.
The MRFC acting as the session initiator shall:
  • prepare the media security offer in the SDP body of the SIP INVITE request;
  • include a single crypto session of type TLS in the TRANSFER_INIT message according to procedures specified in TS 33.328; and
  • insert in the SDP offer the SDP key management protocol attribute "a=key-mgmt" specified in RFC 4567 which indicates use of the MIKEY-TICKET ticket and contains the TRANSFER_INIT message.
    Upon receipt of the SIP response with the SDP answer the MRFC shall check that the responder is authorized before completing the media security setup. If the MRFC notices that the other endpoint is not as expected, the MRFC shall abort the session setup. Otherwise the MRFC shall derive the PSK and shall send it to the MRFP.
Upon receipt of the SIP INVITE request with the SDP offer containing the media security offer and the SDP key management protocol attribute "a=key-mgmt" specified in RFC 4567 which indicates use of the MIKEY-TICKET ticket and contains the TRANSFER_INIT message the MRFC shall:
  • check if it is authorized to resolve the ticket and if that is the case the MRFC interacts with the KMS to resolve the ticket and receive keys;
  • include the MIKEY-TICKET response in the generated TRANSFER_RESP message;
  • insert in the SDP answer the SDP key management protocol attribute "a=key-mgmt" specified in RFC 4567 which indicates use of the MIKEY-TICKET ticket and contains the TRANSFER_RESP message; and
  • shall derive the PSK and shall send it to the MRFP.
The MRFC acting as the session initiator or the session responder shall:
  • determine via SDP negotiation as specified in RFC 4145 if the MRFP needs to act as TCP client or server;
  • request the MRFP to start the TCP connection establishment if the MRFP needs to act as TCP client;
  • determine via SDP negotiation if the MRFP needs to act as TLS client or server as specified in the clauses below;
  • if the MRFP needs to act as TLS client, request the MRFP to start the TLS session setup once the TCP connection is established towards the served UE; and
  • apply additional specific procedures specified for the MSRP in clause 5.20.3 or for the BFCP in clause 5.20.4.
The MRFP shall:
  • upon request from the MRFC, start a TCP connection establishment by sending a TCP SYN;
  • release the underlying TCP bearer connection as soon as the TLS session is released;
  • be capable to support both the TLS server and TLS client roles;
  • when being instructed to start the TLS session setup, act as a TLS client and establish the TLS session as soon as the underlying TCP bearer connection is established;
  • uniquely associate the PSK received from the MRFC with the corresponding TCP based media stream;
  • use the received PSK in the TLS handshake; and
  • apply additional specific procedures specified for the MSRP in clause 5.20.3 or for the BFCP in clause 5.20.4.
Up

5.20.3  Specific requirements for session based messaging (MSRP)  p. 65

For the each MSRP media stream requiring e2e security, the MRFC shall:
  1. indicate "TCP/TLS/MSRP" as transport protocol when requesting resources from the MRFP; and
  2. determine via SDP negotiation if the MRFP needs to act as TLS client or TLS server as specified in RFC 8122 using the RFC 4145 "a=setup" SDP attribute as follows:
    • if the MRFC sends the "a=setup:active" SDP attribute in the SDP answer towards the UE, the MRFP shall act as TLS client;
    • if the MRFC sends the "a=setup:passive" SDP attribute in the SDP answer towards the UE, the MRFP shall act as TLS server;
    • if the MRFC receives the "a=setup:active" SDP attribute in the SDP answer from the UE, the MRFP shall act as TLS server; and
    • if the MRFC receives the "a=setup:passive" SDP attribute in the SDP answer from the UE, the MRFP shall act as TLS client.
The MRFP shall send the TLS protected MSRP packets to the served UE and shall accept the TLS protected MSRP packets from the served UE as requested by the MRFC.
Up

5.20.4  Specific requirements for conferencing (BFCP)  p. 65

For the each BFCP media stream requiring e2e security, the MRFC shall:
  1. indicate "TCP/TLS/BFCP" as transport protocol when requesting resources from the MRFP; and
  2. determine via SDP negotiation (see RFC 4583) if the MRFP needs to act as TLS client or TLS server as follows:
    • if the MRFC receives an initial SDP offer from the served UE, the MRFP shall act as TLS server; or
    • if the MRFC sends an initial SDP offer towards the served UE, the MRFP shall act as TLS client.
The MRFP shall send the TLS protected BFCP packets to the served UE and shall accept the TLS protected BFCP packets from the served UE as requested by the MRFC.
Up

5.21  TCP bearer connection control |R12|  p. 66

If an MRFC and an MRFP support TCP as transport protocol (see RFC 793 and RFC 4145), the following functional requirements apply.
Upon reception of an SDP offer or an SDP answer containing a media line for a new TCP based media stream, the MRFC shall for that TCP based media stream:
  • determine via SDP negotiation if the MRFP needs to act as TCP client or TCP server using the RFC 4145 "a=setup" SDP attribute as follows:
    1. if the MRFC sends the "a=setup:active" SDP attribute in the SDP answer towards the conference participant, the MRFP shall act as TCP client;
    2. if the MRFC sends the "a=setup:passive" SDP attribute in the SDP answer towards the conference participant, the MRFP shall act as TCP server;
    3. if the MRFC receives the "a=setup:active" SDP attribute in the SDP answer from the conference participant, the MRFP shall act as TCP server; and
    4. if the MRFC receives the "a=setup:passive" SDP attribute in the SDP answer from the conference participant, the MRFP shall act as TCP client;
  • if no media security is applied, indicate "TCP/MSRP" (for session based messaging) or "TCP/BFCP" (for conferencing) as transport protocol to the MRFP;
  • if media security is applied, indicate the transport protocol according to clause 5.20 to the MRFP;
  • request the MRFP to allocate a TCP port at the termination towards the SDP offerer/answerer;
  • indicate TCP port number from the received SDP offer/answer in the remote descriptor at the termination towards the SDP offerer/answerer;
  • request the MRFP to start a TCP connection establishment if the MRFP needs to act as TCP client; and
  • request the MRFP to report TCP connection establishment related failures.
Upon request from the MRFC to reserve and/or configure resources for TCP based media the MRFP shall:
  • if being instructed to start TCP connection establishment at a given termination, start TCP connection establishment at that TCP termination by sending a TCP SYN message;
  • if not being instructed to start TCP connection establishment at a given termination, answer any received TCP SYN message at a given termination with appropriate messages according to TCP procedures; and
  • report TCP connection establishment related failures to the MRFC.
Up

5.22  Support of Telepresence |R12|  p. 66

5.22.1  General  p. 66

If the MRFC and the MRFP support telepresence, as specified in TS 24.103 and if the CLUE data channel used for telepresence is terminated in the MRFP, the following requirements and procedure apply.

5.22.2  Characteristics of the Telepresence support  p. 67

The characteristics of the telepresence support by the MRFC and the MRFP are the following:
  1. Regarding usage of CLUE data channel with respect to H.248 context/termination/stream model:
    1. there is only one single H.248 termination for the telepresence bearer traffic of a single conference participant, which covers all telepresence media traffic flows and CLUE for control purposes;
    2. there is only one CLUE data channel per conference participant (i.e., per H.248 termination);
    3. the CLUE protocol including the underlying transport of a CLUE data channel, SCTP association, DTLS and lower layer protocols are modelled by a single H.248 stream; and
    4. there is only one single CLUE data channel per SCTP association, hence a single SCTP stream only;
  2. Regarding the transport protocol stack:
    1. the L4 protocol is always "UDP";
  3. For the protocol termination of SCTP in the MRFP:
    1. the protocol parameter configuration for the SCTP is done via configuration management or default value settings, apart from the information elements (specified in clause 5.22.3) which are signalled between the MRFC and the MRFP using the SDP for SCTP;
  4. Regarding the establishment procedures for DTLS and SCTP:
    1. the establishment of a SCTP association is tightly coupled to the successful establishment of the underlying DTLS session/connection;
    2. only an immediate SCTP establishment is supported;
    3. the MRFP will immediately send an outgoing SCTP establishment request (SCTP INIT) when DTLS layer connectivity is available, if the MRFP did not already receive an incoming SCTP establishment request;
  5. Regarding the procedure for closing the CLUE data channel:
    1. the MRFP will deny during the SCTP association establishment phase the negotiation of SCTP extensions (such as the SCTP stream reset capability) in order to prevent their later usage for a closure procedure; and
    2. a CLUE data channel is released by a removal of the H.248 stream endpoint or the subtraction of the H.248 termination, or a release procedure of the DTLS bearer session. All these triggers lead firstly to a SCTP shutdown procedure and then a subsequent DTLS bearer session release procedure;
  6. security aspects:
    1. incoming DTLS session/connection establishment request is not blocked; and
    2. incoming SCTP association establishment request is not blocked.
Up

5.22.3  CLUE data channel establishment  p. 67

For establishing a CLUE data channel an SDP-based "SCTP over DTLS" data channel negotiation mechanism is used. SDP offer/answer transactions between the MRFC and the served TP UE are based on the SDP offer/answer procedure specified in RFC 8841 and RFC 8842. The SDP describing an SCTP association over DTLS/UDP to be used to realize a CLUE data channel contains:
  • "m=" line with "UDP/DTLS/SCTP" as transport protocol and UDP port;
  • associated pair of "tls-id" SDP attribute values (the attribute values of the TP UE and the MRFC, see RFC 8842);
  • associated "sctp-port" and optional "max-message-size" attributes (see RFC 8841); and
  • associated "dcmap" attribute (specified in RFC 8864) with a "stream-id" parameter set to a value of the used SCTP stream and a subprotocol parameter set to "CLUE" as specified in RFC 8850.
For the media line with "UDP/DTLS/SCTP" as transport protocol to be set up for a CLUE data channel, the MRFC:
  • shall send the remote UDP port and SCTP port to the MRFP;
  • shall request the local UDP port and SCTP port from the MRFP;
  • shall indicate the MRFP to start a DTLS bearer session establishment at the termination towards the SDP offerer, if the received SDP offerer contains an "a=setup:passive" SDP attribute;
  • shall send the dcmap-stream-id parameter that is contained in the received SDP offer, indicating the actual SCTP stream identifier with the SCTP association (over DTLS/UDP) used to realize the CLUE data channel;
  • shall send the subprotocol value of "CLUE", indicating the protocol to be exchanged via the data channel;
  • if the max-message-size parameter is contained in the received SDP offer, may forward the received max-message-size parameter, indicating to the MRFP the maximum message size the served TP UE is willing to accept;
  • may request the maximum message size the MRFP is willing to accept;
  • shall send the received TP UE certificate fingerprint to the MRFP that is then able to correlate the fingerprint within the CLUE data channel uniquely; and
  • shall request the certificate fingerprint from the MRFP, for the "m=" line to be transported between the served TP UE and the MRFP using CLUE data channel.
For the media line with "UDP/DTLS/SCTP" as transport protocol to be set up for a CLUE data channel, the MRFP shall:
  • allocate the local UDP port and SCTP port, and send them to the MRFC;
  • when being instructed to start the DTLS bearer session setup, act as a DTLS client and establish the DTLS bearer session;
  • if it is requested from the MRFC, set the maximum message size that is acceptable for the CLUE data channel and send it to the MRFC;
  • upon request from the MRFC, select an own certificate for the CLUE data channel, and send the fingerprint of the own certificate to the MRFC;
  • uniquely associate the certificate fingerprint received from the MRFC with the corresponding CLUE data channel, and subsequently use the certificate fingerprint to verify the establishment of the DTLS bearer session;
  • if the verification of the remote certificate fingerprint during the DTLS bearer session establishment fails, regard the remote DTLS endpoint as not authenticated, terminate the DTLS bearer session and report the unsuccessful DTLS bearer session setup to the MRFC; and
  • indicate the support of the required SCTP extensions (i.e. RE-CONFIG) and other SCTP considerations as defined in Section 3.2 of RFC 8850 at the start of the SCTP association.
Up

5.22.4  Release of CLUE data channel  p. 69

To close the CLUE data channel, the MRFC may instruct the MRFP to release the underlying communication (i.e., protocol stack UDP/DTLS/SCTP) for the CLUE data channel, which may result in triggering the release of the DTLS bearer session (which then will implicitly lead to a SCTP association shutdown procedure).
Regarding the SCTP reset, the MRFP shall provide a pre-configured (i.e., autonomous) behaviour by preventing "SCTP Stream Reconfiguration" procedures as specified in RFC 6525, which results in:
  1. for an outgoing direction: the MRFP shall not initiate any "Sender-Side Procedures for the RE-CONFIG Chunk", as specified in RFC 6525; and
  2. for an incoming direction: the MRFP shall deny any SCTP re-configuration request (as part of "Receiver-Side Procedures for the RE-CONFIG Chunk", as specified in RFC 6525) in order to prevent possible later usage of SCTP stream reset requests.
Up

5.22.5  CLUE transport between MRFC and MRFP  p. 69

When the data channel is terminated in the MRFP for telepresence, CLUE messages (e.g. OPTIONS, ADVERTISEMENT, CONFIGURE etc.) are sent from the MRFC to the MRFP to be exchanged via the CLUE data channel between the MRFP and the TP UE.
When the MRFC requests the MRFP to establish a CLUE data channel the MRFC shall include a Notify CLUE Message Received Event information element to request the MRFP a reporting of the received CLUE message.
When a CLUE message needs to be sent to the TP UE the MRFC shall request the MRFP to send the CLUE message.
Upon reception of the request to send CLUE message from the MRFC containing the CLUE message content the MRFP shall send the CLUE message to the TP UE.
When a CLUE message is received from the TP UE, the MRFP shall send the content of the received CLUE message to the MRFC.
Up

5.23  SDP Capability Negotiation (SDPCapNeg) |R13|  p. 69

The SDP Capability Negotiation (SDPCapNeg) as specified in RFC 5939 is adopted as an optional functionality to negotiate capabilities and their associated configurations according to TS 24.229.
Upon receipt of an incoming SDP offer containing the attributes of SDP capability negotiation, e.g. offer AVPF and AVP together for the RTP profile negotiation using "a=tcap", "a=pcfg" and "a=acfg" attributes, the MRFC acting as the session responder shall make the decision on support of the alternative configurations based on the MRFC/MRFP capability as provision, and request the MRFP to reserve resources only for the configuration as selected. The MRFC then send the SDP answer indicating the selected configuration in the "a=acfg" attribute for actual configurations.
The MRFC acting as the session initiator may signal SDPCapNeg to the MRFP, e.g. the MRFC wildcards the supporting configurations from the MRFP in order to construct an SDP offer with the alternative configurations via SDPCapNeg attributes.
In case the MRFC decides to request the MRFP to reserve resources for all of those configurations, the MRFC shall:
  • use legacy SDP attributes as specified in RFC 4566 to do the mapping of actual and potential configurations with the H.248 ReserveGroup concept; or
  • use SDP extensions for SDP capability negotiation as specified in RFC 5939, if supported by the MRFP.
Before using SDP extensions for SDP capability negotiation as specified in RFC 5939 towards the MRFP, the MRFC shall perform the necessary checks (i.e. through auditing or via prior provisioning) to ensure that the MRFP supports the syntax and capabilities requested. For an auditing the procedure in clause 6.1.8.1 is used with the "SDPCapNeg Supported Capabilities" as the object.
When receiving a request from the MRFC with information element "SDPCapNeg configuration" indicating the potential use of multiple configurations, the MRFP shall reserve resources for all of those configurations that it supports and shall send indicate the configurations for which it reserved resources in an "SDPCapNeg configuration" information element in the response. The MRFC shall update the SDP offer with SDPCapNeg configurations in the response from the MRFP and shall forward the SDP offer to the next hop.
On receipt of an SDP answer with SDPCapNeg, the MRFC shall request the MRFP to configure the resources for the selected configuration. If the MRFP previously reserved any temporary resources for configurations that were not selected, the MRFC shall also request the MRFP to release those resources.
Up

Up   Top   ToC