F.2 Hash functions
33.1803GPPRelease 17Security of the Mission Critical (MC) serviceTS
F.2.1 Generation of MIKEY-SAKKE UID
F.2.1.1 Overview
Section 3.2 of IETF RFC 6509 [11] defines an identifier for use in MIKEY SAKKE, referred to as the UID in the present document. This requires a Tel-URI as the user’s URI and monthly key periods. As MC Service user IDs may not be Tel-URIs, this UID format cannot be used within MC applications. This clause defines how the 256-bit MIKEY-SAKKE UID is generated using a generic identifier and generic key period.
The MIKEY-SAKKE UID is generated by hashing a fixed string, the identifier of the user, the identifier of the KMS, the key period length, the current key period number and their respective lengths. Key periods are a repeating sequence of fixed time periods, where the first key period commences at an offset in time following 0h on 1 January 1900.
The input to the hash function shall be encoded as specified in clause B.2 of 3GPP TS 33.220 [17]. The hash function shall be SHA-256 as specified in [18]. The full 256-bit output shall be used as the identifier within MIKEY-SAKKE (referred to as ‘ID’ in IETF RFC 6507 [9] and ‘a’ or ‘b’ within IETF RFC 6508 [10]. The resulting UID shall be base64 encoded.
FC = 0x00
P0 = The fixed string: ”MIKEY-SAKKE-UID”
L0 = Length of P0 value
P1 = Identifier (e.g. MCPTT ID, MCVideo ID or MCData ID)
L1 = Length of P1 value
P2 = KMS Identifier (e.g. secgroup1.kms.example.org)
L2 = Length of P2 value
P3 = Key Period length in seconds (e.g. 2592000)
L3 = Length of P3 value
P4 = Key Period offset in seconds (e.g. 0)
L4 = Length of P4 value
P5 = Current Key Period No. since 0h on 1 January 1900 (e.g. 553)
L5 = Length of P5 value
NOTE 1: The key derivation function defined in clause B.2 of 3GPP TS 33.220 [17] is not used, therefore the FC value should only be considered as a dummy value.
P0 is a fixed 15 character string encoded as described in annex B of 3GPP TS 33.220 [17]. P1 is the identifier, which for MCPTT would be the MCPTT ID. P2 is the identifier of the KMS, and uniquely identifies the public key used for encryption and signing. P3 is the integer representing the number of seconds in every key period. P4 is the offset of the start time of the first key period from 0h on 1 January 1900 and shall be less than P3. The combination of P4 and multiples of P3 set the time at which keys are changed over at the end of every key period. Both P3 and P4 are extracted from the KMS certificate (UserKeyPeriod and UserKeyOffset from table D.3.2.2-1, respectively) and encoded as integers as described in annex B of 3GPP TS 33.220 [17]. P5 is the integer representing the current key period number since 0h on 1 January 1900, which may be calculated as:
P5 = Floor ( ( TIME – P4 ) / P3 )
Where TIME is a NTP timestamp, i.e., a number in seconds relative to 0h on 1 January 1900. P4 is encoded as described in annex B of 3GPP TS 33.220 [17].
NOTE 2: When used to generate a UID for encrypting using a MIKEY payload, P1 will commonly be the ‘ID Data’ from the IDRr payload, P2 will be the encoded ‘ID Data’ from the IDRkmsr payload, and TIME will be the NTP timestamp within the MIKEY payload.
NOTE 3: When used to generate a UID for signing a MIKEY payload, P1 will commonly be the ‘ID Data’ from the IDRi payload, P2 will commonly be the ‘ID Data’ from the IDRkmsi payload, and TIME will be the NTP timestamp within the MIKEY payload.
F.2.1.2 Example UID
This clause calculates an example UID demonstrating the hash defined in clause F.2.1.1.
In this example:
– The identifier, P1, is sip:user@example.org.
– The KMS identifier, P2, is kms.example.org.
– The key period is 4 weeks, hence P3 is 2592000.
– The offset, P4, is 0.
– the calculation time is: <2014:01:26T10:07:14Z>, hence TIME is 3599719634.
Based on these details:
P5 = Floor ( (3599719634 – 0) / 2592000 ) = 1388.
Consequently, S is constructed from the concatenation of:
FC = 0x00
P0 = MIKEY-SAKKE-UID
L0 = 15
P1 = sip:user@example.org
L1 = 20
P2 = kms.example.org
L2 = 15
P3 = 2592000
L3 = 3
P4 = 0
L4 = 1
P5 = 1388
L5 = 2
Using the conversion in Clause B.2 of TS 33.220 [17]:
S = 0x00 ||
0x4d 0x49 0x4b 0x45 0x59 0x2d 0x53 0x41 0x4b 0x4b 0x45 0x2d 0x55 0x49 0x44 || 0x00 0x0f ||
0x73 0x69 0x70 0x3a 0x75 0x73 0x65 0x72 0x40 0x65 0x78 0x61 0x6d 0x70 0x6c 0x65 0x2e 0x6f 0x72 0x67 || 0x00 0x14 ||
0x6b 0x6d 0x73 0x2e 0x65 0x78 0x61 0x6d 0x70 0x6c 0x65 0x2e 0x6f 0x72 0x67 || 0x00 0x0f ||
0x27 0x8d 0x00 || 0x00 0x03 ||
0x00 || 0x00 0x01 ||
0x05 0x6c || 0x00 0x02
Consequently:
UID = SHA‑256 (004d494b45592d53414b4b452d554944000f7369703a75736572406578616d706c652e6f726700146b6d732e6578616d706c652e6f7267000f278d000003000001056c0002)
= OoH7FMOx0P5DycV3EE1VptgXiL/S8JdDxFV3RqWgNTs=
Annex G (normative):
Key identifiers
The ‘purpose tag’ within the key identifier (e.g. GMK-ID) shall be the most significant four bits of the key and shall be used to indicate the use of the key. The use of key and application of key diversity are specified in Table G-1.
Table G-1: Key usage according to purpose tag
|
Purpose tag value |
Key type |
Key usage |
Application of key diversity through UK-ID |
|
0 |
GMK |
Protection of group communications. |
Yes |
|
1 |
PCK |
Protection of Private Call communications. |
No |
|
2 |
CSK |
Protection of application signalling (XML and SRTCP) between the MC client and MC domain. |
No |
|
3 |
SPK |
Protection of application signalling (XML and SRTCP) between servers in MC domain(s). |
No |
|
4 |
MKFC |
Used as defined in Annex H. |
No |
|
5 |
MSCCK |
Used as defined in Annex H. |
No |
|
6 |
MuSiK |
Protection of multicast signalling between the MCX Server and the MC Client. |
No |
|
7-15 |
Not defined |
In this way, the MC UE is able to identify the purpose of the key.
Annex H (normative):
Support for legacy multicast key (MKFC) and for MSCCK
H.1 General
TS 33.179 [7] specified a different key distribution mechanism for the distribution of group multicast keys (MKFC). To allow MCPTT clients to operate with legacy MCPTT servers (as defined by the functionality in TS 33.179 [7]), MCPTT clients shall support the MKFC key distribution mechanisms defined in clause H.2 with the following constraints:
– The MCPTT client shall reject MKFCs received from other MC systems (based upon the GMS identity).
– The MCPTT client shall discard previously received MKFCs upon attaching to a new MC system.
MCPTT Servers shall not support MKFC distribution. The MCPTT Server shall only support transmission of signalling over a unicast bearer to a legacy MCPTT client (as defined by the functionality TS 33.179 [7]). This shall be detected by the MCPTT Server on the rejection of the MuSiK.
MCPTT Servers and MCPTT clients shall support distribution of the MSCCK. The mechanism for the distribution of the MSCCK is defined in clause H.3.
NOTE: Void.
MSCCK and MKFC are used as defined in clause H.4.
H.2 MKFC Receipt
MKFCs are distributed using the same procedures as for GMK distribution. The client receives an MKFC from the MCPTT server using the procedures in clause 7.3, with the exception that the MKFC and MKFC-ID is distributed in the place of the GMK and GMK-ID, and the user salt is zero (meaning that the GUK-ID is the MKFC-ID).
MKFCs are either distributed in their own group key distribution message (separate from the GMK distribution message), or in the same distribution message as the GMK. Distributing the MKFC in the same message as the GMK is achieved by embedding two MIKEY payloads in one distribution message.
H.3 MSCCK Distribution
MSCCK and MSCCK-ID are distributed within MBMS bearer announcement messages. The procedures are identical to those for distribution of the MuSiK, as defined in clause 5.9, with the exception that the MSCCK and MSCCK-ID are distributed instead of the MuSiK and MuSiK-ID.
H.4 Use of multicast signalling keys (MKFC and MSCCK)
For the protection of multicast floor and media control received from legacy MCPTT servers, the KFC shall be the MKFC and the KFC-ID shall be the MKFC-ID. KFC-RAND shall be the MIKEY RAND value transmitted in the MIKEY message used to distribute the KFC. The KFC is used as defined in clause 9.4.6 and 9.4.7.
For the protection of MBMS subchannel control messages, the KFC shall be the MSCCK and the KFC-ID shall be the MSCCK-ID. KFC-RAND shall be the MIKEY RAND value transmitted in the MIKEY message used to distribute the KFC. The KFC is used as defined in clause 9.4.6 and 9.4.7.
Annex I (normative):
Signalling Proxies
I.1 Overview
This solution defines the role of a Signalling Proxy within the Mission Critical System. Signalling Proxies are optional elements providing a deployment option to allow security enforcement at the edge of the MC Doman. Using the functionality defined in this document, Signalling Proxies can be used transparently to MC clients. When Signalling Proxies are used, the MCX Servers within the domain may not need to support security functionality.
The primary function of the signalling proxy is to perform key management of signalling keys, and encryption/decryption of application signalling transiting the edge of the mission critical domain.
This solution defines two types of signalling proxy:
– Client Signalling proxy (CS Proxy)
– Interconnection Signalling Proxy (IS Proxy)
The Client Signalling Proxy may perform security operations towards the client on behalf of the mission critical domain. This includes:
– Topology hiding
– Resilience against signalling storm
– CSK key management (per client);
– MuSiK key management (where protection of multicast signalling is required);
– Protection of application layer signalling (XML in SIP);
– Protection of floor control signalling, transmission control signalling and media signalling (SRTCP);
– Protection of MCData signalling payloads.
– Creation of KMS Redirect Responses (KRRs).
The Interconnection Signalling Proxy may perform security operations towards other mission critical domains. This includes:
– Topology hiding
– Resilience against signalling storm
– Storage of SPK(s);
– Protection of application layer signalling (XML in SIP);
– Protection of floor control signalling, transmission control signalling and media signalling (SRTCP);
– Protection of MCData signalling payloads.
– Creation of KMS Redirect Responses (KRRs).
Signalling proxies may present one or multiple identifiers externally. A CS proxy requires keying by the Key Management Server (KMS) to receive key material associated with the identifiers that it represents externally.
NOTE: Where signalling proxies are used, MCX Servers may not require keying by the KMS as they may not perform any security functionality.
I.2 Location of a signalling proxy
I.2.1 Overview
A signalling proxy should be located at the logical edge of the MC Domain. Signalling routed via the SIP Core should be routed via the signalling proxy on entry or exit of the MC Domain. This includes RTCP signalling such as transmission and floor control.
I.2.2 Deployment with an untrusted SIP Core
Where the SIP Core is not trusted by the Mission Critical provider, the Signalling Proxy should be located between Mission Critical Functions (MCX Server, GMS, etc.) and the external SIP Core. The use of Signalling Proxies within a MC System where the SIP Core is untrusted is shown in Figure I.2.2-1.
Figure I.2.2-1: Signalling proxies (with untrusted SIP Core)
Internal signalling within the MC Domain (between MCX Server(s) and GMS(s)) routes via the SIP Core. Consequently, in this scenario, the IS Proxy will route all internal signalling to/from itself via the SIP core. Each time it receives an internal signalling message, the IS Proxy should apply an SPK for protection and it should perform topology hiding towards the SIP Core.
NOTE: There may be a performance impact of locating the SIP Core outside of the MC Domain due to the increased load on the IS Proxy.
The use of the signalling proxy at the edge of the Mission Critical network does not remove the need to deploy a SIP Session Border Controller (as defined in RFC 5853 [24]), or IMS IBCF (as defined in Annex I of 3GPP TS 23.228 [23]), to protect the SIP core.
I.2.3 Deployment with a trusted SIP Core
Where the SIP Core is trusted by the Mission Critical provider, the Signalling Proxy should be located at the edge of the external SIP Core, allowing data transiting the SIP core to be unencrypted. The use of Signalling Proxies within a MC System where the SIP Core is trusted is shown in Figure I.2.3-1.
Figure I.2.3-1: Signalling proxies (with trusted SIP Core)
In this deployment scenario, the MC Signalling Proxy may be co-located with the SIP Core’s Session Border Controller (as defined in RFC 5853 [24]), or IMS IBCF (as defined in Annex I of 3GPP TS 23.228 [23]). This has the security benefit that the SIP identities and the Mission Critical identities can be correlated at the edge, increasing the system’s ability to detect misuse, associate signalling and media and apply system policies.
NOTE 1: In this deployment scenario, signalling security (e.g. XMLSec) and SIP security (e.g. TLS/IPSec) are performing the same function within the MC System. Consequently, the use of both signalling protection methods may not be necessary.
NOTE 2: In this deployment scenario, the IS Proxy is not involved in the routing of internal signalling.
I.3 Functions of a signalling proxy
I.3.1 Overview
A signalling proxy may perform the functions specified in this clause.
I.3.2 Identifier modification (topology hiding)
One function of a signalling proxy is to change the source and destination identifiers in signalling messages to prevent the network topology being exposed externally.
– Messages received on the external interface will be forwarded to an appropriate MC Server based on the type of message and consequently the destination identifier of the message will be changed by the proxy.
– Messages received on the internal interface will have their source identifier replaced with the proxy’s identifier.
Modification of identifiers applies to all signalling handled by the proxy. Specifically:
– SIP;
– Application layer signalling (XML in SIP);
– Floor control signalling, transmission control signalling and media signalling (SRTCP);
– MCData signalling payloads.
I.3.3 Resilience against signalling storm
The signalling proxy is able to monitor the quantity and type of signalling entering the MC Domain. Signalling Proxy should be resilient to receiving a large amount of signalling, such as a high number of MCX Server registrations. The Signalling Proxy should be able to block, throttle or prioritise the signalling routed into the MC Domain to prevent overload of application signalling at the MCX Server, while maintaining the most critical MC services. Applying limits to signalling could be performed at a service-level or to a specific user’s signalling.
I.3.4 Client connection to a CS Proxy
When an MC client first connects to a CS Proxy, it will provide an encapsulated CSK along with an access token as part of a SIP SUBSCRIBE or SIP PUBLISH message. The CS Proxy should extract and store the CSK and decrypt the access token. The CS Proxy may verify that the message is properly constructed and applicable to this MC Domain (e.g. verify that the access token is applicable to the current MC domain). Verification failure should cause the CS Proxy to drop the message.
The CS Proxy should then forward the SIP SUBSCRIBE or SIP PUBLISH message onto an appropriate MCX Server with an unencrypted access token and without the encapsulated CSK.
From this point onwards, signalling received from the client should be decrypted using the CSK, and signalling sent to the client should be encrypted using the CSK. This functionality is as currently defined for a MCX Server.
I.3.5 CSK key download from a CS Proxy
The CS Proxy is responsible for CSK key management. Hence, should the CSK require renewal, the CS Proxy should create and send a ‘key download’ message to the MC client containing the new CSK. This functionality is as currently defined for a MCX Server.
As signalling proxies may present the one or multiple SIP URIs externally, the same client may attempt to connect to the same CS Proxy twice, using different URIs and different CSKs each time. In this scenario, the CS Proxy may remove CSK ambiguity by using the ‘CSK key download’ procedure as follows:
1) The MC client connects to the CS Proxy using the URI ‘A’. The MC client provides CSKA.
2) The CS Proxy receives CSKA and the MC client and CS Proxy use CSKA to protect application signalling.
3) The MC client connects to the CS Proxy using the URI ‘B’. The MC client provides CSKB.
4) The CS Proxy observes that the same client has connected again using a different destination URI.
5) The CS Proxy performs a ‘CSK key download’ to update CSKB. The CS Proxy sets CSKB to CSKA.
6) The MC client and CS Proxy use CSKA to protect application signalling (regardless of source URI).
I.3.6 MuSiK and MSCCK key download from a CS Proxy
Should multicast signalling be required, the CS Proxy should perform MuSiK key download from the CS Proxy to the MC client. To support this, the CS Proxy should perform a MuSiK key download procedure toward the MC clients that will receive multicast signalling. This functionality is as currently defined for a MCX Server.
On receipt of signalling from the MC domain towards a multicast bearer, the CS Proxy should protect the signalling with a MuSiK and forwards the message externally. This functionality is as currently defined for a MCX Server.
NOTE: As multiple MCX Servers can use the same CS Proxy for multicast signalling, this allows multiple MCX Servers to share multicast bearers.
Similarly, the CS Proxy should attach a MSCCK to MBMS Bearer Annoucement messages, and encrypt MBMS subchannel control messages with the MSCCK.
I.3.7 Signalling protection by the IS Proxy
The IS Proxy is configured with one, or more, SPKs for protection of signalling and each SPK will be associated with specific interconnection end-point(s). On receipt of signalling from the MC domain towards an interconnection end-point, the IS Proxy should encrypt the signalling using the appropriate SPK and forward the message externally. On receipt of signalling from an interconnection end-point towards the MC Domain, the IS Proxy should decrypt the signalling and forward the message internally.
I.3.8 Creation of KMS Redirect Responses (KRRs)
The Signalling Proxy may create KRRs to enforce local policy around the use of KMSs within the MC Domain. For example, should a MIKEY message be sent through the domain using a KMS that is unacceptable within the domain, the CS or IS Proxy may drop the MIKEY message, create a KRR and return the KRR to the sender of the MIKEY message.
I.3.9 Policy enforcement
As gateways to the MC domain, signalling proxies may also be appropriate locations to enforce policy within the MC domain.
Editor’s Note: Defining the policies that could be enforced at the signalling proxy is FFS.
Annex J (normative):
Authentication and authorisation formats