E.7 Hiding identities within MIKEY messages

33.1793GPPRelease 13Security of Mission Critical Push To Talk (MCPTT) over LTETS

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

The sensitive MCPTT ID in the IDRr or IDRi field is replaced with the UID generated from the MCPTT 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 hashed initiator (IDRuidi) ID Role has an IANA assigned value of ‘8’ while the Hashed Responder (IDRuidr) ID Role has an IANA assigned value of ‘9’ [41].

The processing of the MIKEY-SAKKE I_MESSAGE at the initiator stays the same. If the initiator has hidden its own MCPTT ID, it shall ensure that the SIP message containing the I_MESSAGE contains the initiator’s MCPTT 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 MCPTT 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 MCPTT ID. On obtaining the initiator’s MCPTT 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