E.5 MIKEY general extension payload to support ‘SAKKE-to-self’

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

In some circumstances it is useful for the initiator to be able to decrypt a MIKEY-SAKKE payload and recover the key (as well as the receiver). For example, where the initiating user is attached to the MCX service via more than one MC UE, the other MC UEs associated with the initiating user will also need the key material to be able to join the communication.

To support this scenario, an optional MIKEY General Extension Payload may be added to the MIKEY-SAKKE message. This general extension payload has type ‘SAKKE-to-self’. The contents of the payload will be a full SAKKE payload as defined in IETF RFC 6509 [11]. Within the second SAKKE payload the key (GMK or PCK) shall be encapsulated to the UID generated from the MC identifier associated with the initiating user (either group management server or private call initiator). The ID Scheme in the SAKKE payload shall be ‘3GPP MCX hashed UID ‘ to reflect the generation scheme defined in clause F.2.1.

The General Extensions Field Name ‘SAKKE-to-self’ type takes on the IANA assigned value of ‘6’ [52].

EXAMPLE SAKKE-to-self payload:

* 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

* ! Next payload ! Type ! Length !

* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

* ! Next payload ! SAKKE params ! ID scheme ! SAKKE data ~

* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

* ~ length (cont) ! SAKKE data ~

* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The SAKKE-to-self payload encapsulates a SAKKE payload. Consequently, the SAKKE-to-self payload will contain two ‘next payload’ fields. The second ‘next payload’ field, which corresponds to the encapsulated SAKKE payload, shall be set to zero and ignored.