E.6 MIKEY general extension payload to encapsulate parameters associated with a key

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

E.6.1 General

The parameters associated with the key shall be contained in the ‘General extension payload’ specified in IETF RFC 3830 [22] using the ‘3GPP key parameters ‘ Type value and contained within the signed envelope of the MIKEY-SAKKE I_MESSAGE specified in clause E.2. The format and cryptography of the payload are specified in this subclause.

The General Extensions Field Name ‘3GPP key parameters’ type takes on the IANA assigned value of ‘7’ [52].

The payload consist of a series of information elements. The standard format and encoding rules for the information elements follow that defined for the MCPTT Off-Network Protocol (MONP) as documented in Annex I of 3GPP TS 24.379 [10].

The four octets consisting of the header of the ‘General extension payload’ shall be formatted according to IETF RFC 3830 [22].

The contents of the ‘General extension payload’ shall be an MCData Protected Payload message as defined in Clause 8.5.4 with the ‘Payload’ element consisting of the ‘Key Parameters’ payload defined in this clause. The ‘Payload ID’ and the ‘Payload sequence number’ of the Protected Payload shall be set to ‘0’ by the sender and ignored by the receiver. The DPPK-ID of the Protected Payload shall be the same as the CSB-ID of the encapsulating MIKEY payload. The key encapsulated by the MIKEY payload (e.g. GMK, MuSiK, etc) shall be used to protect the Protected Payload (the Key Parameters payload).

The ‘Key Parameters’ payload is a type 6 information element composing a 1 byte Key Parameters IEI, a 2 byte length of the Key Parameters payload contents, and the Key Parameters payload content itself. The Key Parameters payload content shall be of the format specified in Table E.6.1-1.

Table E.6.1-1: Key Parameters Payload content

Information Element	Type/Reference	Presence	Format	Length
Key Type	The type of key. Clause E.6.11.	M	V	1
Status	The current status of the key. Clause E.6.9.	M	V	4
Activation Time	Date and Time when the key may start to be used. Clause E.6.4.	M	V	5
Expiry Time	Date and Time when the key may no longer be used. Clause E.6.10.	M	V	5
Text	A human-readable name for the key Clause E.6.5.	M	LV-E	2-x
MC Group IDs	The MC Group IDs associated with the key (if any) Clause E.6.3.	C	LV-E	2-x
Reserved	Additional information associated with the key (if any) Clause E.6.6.	O	TLV-E	x

NOTE: The ‘MC group IDs’ IE is only present in the Key Parameters payload if the key type is ‘GMK’, ‘MKFC’ or ‘MuSiK’.

The IEs in the Key Parameters Payload are described in the following subclauses.

E.6.2 Void

E.6.3 MC group IDs

The ‘MC group IDs’ IE is only present in the Key Parameters payload if the key type is ‘GMK’, ‘MKFC’ or ‘MuSiK’.

The ‘MC group IDs’ IE shall be of the format specified in Table E.6.3-1.

Table E.6.3-1: MC Group IDs IE content

Information Element	Type/Reference	Presence	Format	Length
Number of Group IDs	The number of Group IDs in the payload, at most 255.	M	V	1
Group ID	The ID for the group associated with the key. Clause 15.2.14 of TS 24.282	O	TLV-E	3-x

NOTE: The Number of Group IDs dictates the number of Group ID information elements that are included in the payload. If the number of group IDs is zero, there will be no Group ID IEs in the payload.

The Group ID payload has the same format as the ‘MCData Group ID’ payload defined in clause 15.2.14 of TS 24.282.

Where the key does not correspond to a group ID, the ‘MC group ID’ IE shall contain a two octet ‘Length’ sub-element with the value ‘1’, followed by a ‘Number of Group IDs’ element of value ‘0’. .

This field allows distribution of MC Group IDs that are associated with the current key carried in the MIKEY-SAKKE I_MESSAGE. This means that each specified MC Group ID shall use this key for group communications. Assigned MC Group IDs may include any combination of MCPTT Group IDs, MCData Group IDs or MCVideo Group IDs.

E.6.4 Activation time

The ‘Activation time’ element shall define the time in UTC at which the associated key is to be made active for transmission in seconds since midnight UTC of January 1, 1970 (not counting leap seconds). It shall be 5 octets in length.

A value of 0 shall imply the activation time is the timestamp of the received MIKEY I_MESSAGE.

E.6.5 Text

The ‘Text’ sub-element shall contain the user-readable name associated with the key.

Where there is no text, the ‘Text’ element shall contain a two octet ‘Length’ sub-element with the value 0 .

E.6.6 Reserved

The definition and encoding of the Reserved IE is outside of scope of the present document.

E.6.7 Void

E.6.8 Void

E.6.9 Status

The ‘Status’ element shall determine the current status of the key. It shall be 4 octets in length. The following values are defined in Table E.6.9-1.:

Table E.6.9-1: Key status bit field

Bit (LSB first)	Bit purpose	‘0′ meaning	‘1′ meaning
0	Key Revokation	Key is revoked (may not be used)	Not revoked.
1	Security Gateway	Key has not been shared with a Security Gateway	Key shared with a Security Gateway

Undefined bits shall be ignored.

E.6.10 Expiry time

The ‘Expiry time’ element shall define the time in UTC at which the associated key shall no longer be used in seconds since midnight UTC of January 1, 1970 (not counting leap seconds). It shall be 5 octets in length.

A value of 0 shall imply the key shall not expire.

E.6.11 Key Type

The purpose of Key Type IE is to specify the type and purpose of the key.

The value part of the Key type information element is coded as shown in Table E.6.11-1.

Table E.6.11-1: Key type

Bits
8	7	6	5	4	3	2	1
0	0	0	0	0	0	0	0		GMK
0	0	0	0	0	0	0	1		PCK
0	0	0	0	0	0	1	0		CSK
0	0	0	0	0	0	1	1		SPK
0	0	0	0	0	1	0	0		MKFC
0	0	0	0	0	1	0	1		MSCCK
0	0	0	0	0	1	1	0		MuSiK
All other values are reserved.