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

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

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 MCPTT service via more than one MCPTT UE, the other MCPTT 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 MCPTT 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’ has an IANA assigned type value of ‘6’ [41].

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.