E.7 Hiding identities within MIKEY messages

33.1803GPPRelease 17Security of the Mission Critical (MC) serviceTS

In some public-safety use cases there is a requirement to protect MC Service user IDs in transit. To protect these identifiers in MIKEY-SAKKE messages the following approach may be taken.

The sensitive MC Service user ID in the IDRr or IDRi field is replaced with the UID generated from the MC Service user ID as defined in clause F.2.1. In the former case, the ‘role’ of the IDRr field is replaced with a role of IDRuidr. In the latter case, the ‘role’ of the IDRi field is replaced with a role of IDRuidi.

The ID Role of Hashed Initiator (IDRuidi) takes on the IANA assigned value of ‘8’ while the ID Role of Hashed Responder (IDRuidr) takes on the IANA assigned value of ‘9’ [52].

The processing of the MIKEY-SAKKE I_MESSAGE at the initiator stays the same. If the initiator has hidden its own MC Service user ID, it shall ensure that the SIP message containing the I_MESSAGE contains the initiator’s MC Service user ID encrypted to the receiver.

As a consequence of identity hiding, the receiver of the MIKEY-SAKKE I_MESSAGE will be able to check the signature based on the initiator’s UID in the IDRuidi field, but initially will be unable to confirm the MC Service user ID that has been used to generate the UID. The receiver will recognize its own UID in the IDRuidr field, and be able to extract the encapsulated key.

Using the encapsulated key or otherwise, the receiver is able to extract associated metadata in the message, including the initiator’s MC Service user ID. On obtaining the initiator’s MC Service user ID, the receiver is able to compute the UID and ensure this matches the UID in the IDRuidi field. By performing this check, the receiver has authenticated the I_MESSAGE.

Annex F (normative):
Key derivation and hash functions