5.5.9 Default miscellaneous messages and other information elements
36.579-13GPPMission Critical (MC) services over LTEPart 1: Common test environmentRelease 15TS
5.5.9.1 MIKEY-SAKKE I_MESSAGE
– CSK distribution (MIKEY-SAKKE sent by the UE)
Table 5.5.9.1-1: MIKEY-SAKKE I_MESSAGE (CSK distribution by the UE)
Derivation path: RFC 6509 [23], RFC 6043 [25], RFC 3830 [24] |
|||
---|---|---|---|
Field |
Value/remark |
Comment |
Condition |
MIKEY Common Header { |
Any |
||
version |
‘00000001’B |
||
Data Type |
‘00011010’B |
SAKKE msg (26) |
|
Next payload |
Identifier for the next payload (NOTE 1) |
||
V |
‘0’B |
||
PRF func |
‘0000001’B |
PRF-HMAC-SHA-256 |
|
CSB ID |
Any value but 4 most significant bits set to ‘0010’B |
32 bit CSK-ID: the 4 most significant bits indicate the purpose of the key, the other 28-bits shall be randomly generated (TS 33.180 [94] clause 5.2.2 and E.6.11) |
|
#CS |
‘00000001’B or ‘00000000’B |
Number of crypto sessions in the CS ID map info: if #CS is 0 the default security policies shall be applied (TS 33.180 [94] E.1.2) |
|
CS ID map type |
2 if #CS > 0 |
GENERIC-ID |
|
1 if #CS == 0 |
empty map |
||
CS ID map info { |
Present only if #CS > 0 |
||
CS ID |
‘00000110’B |
CS ID of the crypto session: ‘6’ for CSK use within MCPTT (TS 33.180 [94] E.4.2) |
|
Prot type |
0 |
SRTP the security protocol to be used for the crypto session |
|
S |
Any value |
S flag to indicate whether the ROC and SEQ fields are provided (‘1’) or if they are omitted (‘0’) |
|
#P |
1 |
the number of security policies provided for the crypto session |
|
Ps { |
lists the policies for the crypto session |
||
Policy_no_1 |
Any value |
a policy_no that corresponds to the policy_no of a SP payload |
|
} |
|||
Session Data Length |
Length of Session Data (in bytes) |
16 bits the length of Session Data (in bytes). For the Prot type SRTP, Session Data MAY be omitted in the initial message (length = 0), but it MUST be provided in the response message. |
|
Session Data { |
Present if Session Data Length > 0 |
session data for the crypto session |
|
SSRC |
Any value |
specifies the SSRC that MUST be used for the crypto session |
|
ROC |
Any value if S flag is set, not present otherwise |
current/initial rollover counter. If the session has not started, this field is set to ‘0’ |
|
SEQ |
Any value if S flag is set, not present otherwise |
current/initial sequence number |
|
} |
|||
SPI Length |
Length of the SPI |
SPI MAY be omitted in the initial message (length = 0), but it has to be provided in the response message |
|
SPI |
Any value if present |
the SPI (or MKI) corresponding to the session key to (initially) be used for the crypto session. Other keys can be used. |
|
} |
|||
} |
|||
Timestamp Payload (T) { |
Addressed by ‘00000101’B in the ‘Next payload’ field of the previous payload |
||
Next payload |
Identifier for the next payload (NOTE 1) |
||
TS Type |
‘00000000’B |
NTP-UTC (0): 64-bits |
|
TS Value |
Any value |
64bit UTC value representing the number of seconds since 0h on 1 January 1900 with respect to the Coordinated Universal Time (UTC) |
|
} |
|||
RAND Payload { |
Addressed by ‘00001011’B in the ‘Next payload’ field of the previous payload |
||
Next payload |
Identifier for the next payload (NOTE 1) |
||
RAND len |
‘00010000’B |
At least 16 Bytes |
|
RAND |
128-bit random number |
128-bit random number |
|
} |
|||
IDRi payload { |
Addressed by ‘00001110’B in the ‘Next payload’ field of the previous payload |
||
Next payload |
Identifier for the next payload (NOTE 1) |
||
ID Role |
1 |
Initiator (IDRi) |
|
ID Type |
1 |
URI |
|
ID len |
Length of ID Data |
||
ID data |
px_MCPTT_ID_User_A |
MCPTT ID See TS 33.180 [94] clause E.4.1 |
MCPTT |
px_MCVideo_ID_User_A |
MCVideo ID See TS 33.180 [94] clause E.4.1 |
MCVIDEO |
|
px_MCData_ID_User_A |
MCData ID See TS 33.180 [94] clause E.4.1 |
MCDATA |
|
} |
|||
IDRr payload { |
Addressed by ‘00001110’B in the ‘Next payload’ field of the previous payload |
||
Next payload |
Identifier for the next payload (NOTE 1) |
||
ID Role |
2 |
Responder (IDRr) |
|
ID Type |
1 |
URI |
|
ID len |
Length of ID Data |
||
ID data |
Same URI as used as request URI of the SIP message containing the MIKEY-SAKKE I_MESSAGE |
URI of the server to which the message is sent |
|
} |
|||
IDRkmsi payload { |
Addressed by ‘00001110’B in the ‘Next payload’ field of the previous payload |
||
Next payload |
Identifier for the next payload (NOTE 1) |
||
ID Role |
6 |
Initiator’s KMS (IDRkmsi) |
|
ID Type |
1 |
URI |
|
ID len |
Length of ID Data |
||
ID data |
tsc_MCX_KMS_Hostname |
KMS of the initiating user (UE) |
|
} |
|||
IDRkmsr payload { |
Addressed by ‘00001110’B in the ‘Next payload’ field of the previous payload |
||
Next payload |
Identifier for the next payload (NOTE 1) |
||
ID Role |
7 |
Responder’s KMS (IDRkmsr) |
|
ID Type |
1 |
URI |
|
ID len |
Length of ID Data |
||
ID data |
tsc_MCX_KMS_Hostname |
KMS of the responder (MCX domain) |
|
} |
Addressed by ‘00001010’B in the ‘Next payload’ field of the previous payload |
||
Security Properties payload { |
Present if #CS > 0 |
If not present (#CS == 0) then the default security profile defined in Annex E.4.2 of TS 33.180 [94] shall be used |
|
Next payload |
Identifier for the next payload (NOTE 1) |
||
Policy no |
same as Policy_no_1 in the CS ID map info of the header payload |
||
Prot type |
0 |
SRTP |
|
Policy param length |
|||
Policy param { |
|||
{ |
|||
Type |
0 |
Encryption Algorithm |
|
length |
|||
value |
6 |
AES-GCM |
|
} |
|||
{ |
|||
Type |
1 |
Session encryption key length |
|
length |
|||
value |
16 |
16 octets |
|
} |
|||
{ |
|||
Type |
4 |
Session salt key length |
|
length |
|||
value |
12 |
12 octets |
|
} |
|||
{ |
|||
Type |
5 |
SRTP PRF |
|
length |
|||
value |
0 |
AES-CM |
|
} |
|||
{ |
|||
Type |
6 |
Key derivation rate |
|
length |
|||
value |
0 |
No session key refresh. |
|
} |
|||
{ |
|||
Type |
20 |
AEAD authentication tag length |
|
length |
|||
value |
16 |
16 octets |
|
} |
|||
} |
|||
} |
|||
SAKKE payload { |
Addressed by ‘00011010’B in the ‘Next payload’ field of the previous payload |
||
Next payload |
Identifier for the next payload (NOTE 1) |
||
SAKKE params { |
1 |
Parameter Set 1 according to RFC 6509 [23], Appendix A |
|
ID scheme |
2 |
‘3GPP MCX hashed UID’ (33.180 [94] E.1.2) |
|
SAKKE data length |
Length of SAKKE data (in bytes) |
||
SAKKE data |
Encapsulated CSK |
The CSK is encapsulated by using the public key (PubEncKey in KMS Certificate) and the UID generated from the MDSI of the MCX Domain (provided in IDRr) |
|
} |
|||
SIGN (ECCSI) payload { |
Addressed by ‘00000100’B in the ‘Next payload’ field of the previous payload |
||
S type |
2 |
ECCSI signature |
|
S len |
Length of the signature field (in bytes) |
12 bits |
|
S data |
Signature: Shall be validated by the SS |
The signature shall be validated according to RFC 3830 [24] clause 5.3 using the algorithm according to RFC 6507 [98] clause 5.2.2 using the UID generated from the MC Service user ID associated with the initiating user (provided in IDRi payload). |
|
} |
|||
NOTE 1: MIKEY payloads may occur in any order apart from the header payload which is always the first payload and the signature payload which is always the last payload |
– CSK distribution (MIKEY-SAKKE sent by the SS)
Table 5.5.9.1-1A: MIKEY-SAKKE I_MESSAGE (CSK download sent by the SS)
Derivation path: RFC 6509 [23], RFC 6043 [25], RFC 3830 [24] |
|||
---|---|---|---|
Field |
Value/remark |
Comment |
Condition |
MIKEY Common Header { |
Any |
||
version |
‘00000001’B |
||
Data Type |
‘00011010’B |
SAKKE msg (26) |
|
Next payload |
‘00000101’B |
Timestamp, T |
|
V |
‘0’B |
||
PRF func |
‘0000001’B |
PRF-HMAC-SHA-256 |
|
CSB ID |
‘0001xxxx … xxxxxxxx’B |
32 bit CSK-ID: the 4 most significant bits indicate the purpose of the key, CSK = 0010, the other 28-bits are randomly generated (TS 33.180 [94] clause 5.2.2 and E.6.11) |
|
#CS |
‘00000000’B |
Number of crypto sessions in the CS ID map info: if #CS is 0 the default security policies shall be applied (TS 33.180 [94] E.1.2) |
|
CS ID map type |
1 |
See TS 33.180 [94] E.1.2 |
|
CS ID map info |
Not present |
Present only if #CS > 0 |
|
} |
|||
Timestamp Payload (T) { |
|||
Next payload |
‘00001011’B |
||
TS Type |
‘00000000’B |
NTP-UTC (0): 64-bits |
|
TS Value |
Current system time |
64bit UTC value representing the number of seconds since 1 January 1900 with respect to the Coordinated Universal Time (UTC) |
|
} |
|||
RAND Payload { |
Addressed by ‘00001011’B in the ‘Next payload’ field of the previous payload |
||
Next payload |
‘00001110’B |
||
RAND len |
‘00010000’B |
At least 16 Bytes |
|
RAND |
Random value arbitrarily selected by the SS |
128-bit random number |
|
} |
|||
IDRi payload { |
Addressed by ‘00001110’B in the ‘Next payload’ field of the previous payload |
||
Next payload |
‘00001110’B |
||
ID Role |
1 |
Initiator (IDRi) |
|
ID Type |
1 |
URI |
|
ID len |
Length of ID Data |
||
ID data |
tsc_MCPTT_PublicServiceId_A |
MCPTT |
|
tsc_MCVideo_PublicServiceId_A |
MCVIDEO |
||
tsc_MCData_PublicServiceId_A |
MCDATA |
||
} |
|||
IDRr payload { |
Addressed by ‘00001110’B in the ‘Next payload’ field of the previous payload |
||
Next payload |
‘00001110’B |
||
ID Role |
2 |
Responder (IDRr) |
|
ID Type |
1 |
URI |
|
ID len |
Length of ID Data |
||
ID data |
px_MCPTT_ID_User_A |
MCPTT ID See TS 33.180 [94] clause E.4.1 |
MCPTT |
px_MCVideo_ID_User_A |
MCVideo ID See TS 33.180 [94] clause E.4.1 |
MCVIDEO |
|
px_MCData_ID_User_A |
MCData ID See TS 33.180 [94] clause E.4.1 |
MCDATA |
|
} |
|||
IDRkmsi payload { |
Addressed by ‘00001110’B in the ‘Next payload’ field of the previous payload |
||
Next payload |
‘00001110’B |
||
ID Role |
6 |
Initiator’s KMS (IDRkmsi) |
|
ID Type |
1 |
URI |
|
ID len |
Length of ID Data |
||
ID data |
tsc_MCX_KMS_Hostname |
KMS of the initiating user (UE) |
|
} |
|||
IDRkmsr payload { |
Addressed by ‘00001110’B in the ‘Next payload’ field of the previous payload |
||
Next payload |
‘00011010’B |
||
ID Role |
7 |
Responder’s KMS (IDRkmsr) |
|
ID Type |
1 |
URI |
|
ID len |
Length of ID Data |
||
ID data |
tsc_MCX_KMS_Hostname |
KMS of the responder (MCX domain) |
|
} |
|||
Security Properties payload |
Not present |
If not present (#CS == 0) then the default security profile defined in Annex E.4.2 of TS 33.180 [94] shall be used |
|
SAKKE payload { |
Addressed by ‘00011010’B in the ‘Next payload’ field of the previous payload |
||
Next payload |
‘00000100’B |
||
SAKKE params { |
1 |
Parameter Set 1 according to RFC 6509 [23], Appendix A |
|
ID scheme |
2 |
‘3GPP MCX hashed UID’ (33.180 [94] E.1.2) |
|
SAKKE data length |
Length of SAKKE data (in bytes) |
||
SAKKE data |
Encapsulated CSK |
The CSK is encapsulated by using the public key (PubEncKey in KMS Certificate) and the UID generated from the MDSI of the MCX Domain (provided in IDRr) |
|
} |
|||
SIGN (ECCSI) payload { |
Addressed by ‘00000100’B in the ‘Next payload’ field of the previous payload |
||
S type |
2 |
ECCSI signature |
|
S len |
Length of the signature field (in bytes) |
12 bits |
|
S data |
Signature |
The signature shall be validated according to RFC 3830 [24] clause 5.3 using the algorithm according to RFC 6507 [98] clause 5.2.2 using the UID generated from the ID associated with the initiating user (provided in IDRi payload). |
|
} |
– Private call (MIKEY-SAKKE sent by the SS)
Table 5.5.9.1-2: MIKEY-SAKKE I_MESSAGE (Private call) by the SS
Derivation path: RFC 6509 [23], RFC 6043 [25], RFC 3830 [24] |
|||
---|---|---|---|
Field |
Value/remark |
Comment |
Condition |
MIKEY Common Header { |
|||
version |
‘00000001’B |
||
Data Type |
‘00011010’B |
SAKKE msg (26) |
|
Next payload |
‘00000101’B |
Next payload is timestamp |
|
V |
‘0’B |
||
PRF func |
‘0000001’B |
PRF-HMAC-SHA-256 |
|
CSB ID |
‘0001xxxx … xxxxxxxx’B |
32-bit PCK-ID The 4 most significant bits of the PCK-ID indicate the purpose of the PCK is to protect Private call communications, the other 28-bits are randomly generated |
|
#CS |
‘00000000’B |
the number of crypto sessions in the CS ID map info. |
|
CS ID map type |
1 |
empty map |
|
CS ID map Info |
not present |
||
} |
|||
Timestamp Payload (T) { |
|||
Next payload |
‘00001011’B |
Next payload is RAND |
|
TS Type |
‘00000000’B |
NTP-UTC (0): 64-bits |
|
TS Value |
Current system time |
64bit UTC value representing the number of seconds since 0h on 1 January 1900 with respect to the Coordinated Universal Time (UTC) |
|
} |
|||
RAND Payload { |
|||
Next payload |
‘00001110’B |
Next payload is IDRi |
|
RAND len |
‘00010000’B |
16 Bytes RAND |
|
RAND |
128-bit random number |
||
} |
|||
IDRi payload { |
|||
Next payload |
‘00001110’B |
Next payload is IDRi |
|
ID Role |
1 |
Initiator (IDRi) |
|
ID Type |
0 |
URI |
|
ID len |
Length of ID Data |
||
ID data |
px_MCPTT_ID_User_B |
MCPTT ID associated with the initiating user |
MCPTT |
px_MCVideo_ID_User_B |
MCVideo ID See TS 33.180 [94] clause E.4.1 |
MCVIDEO |
|
px_MCData_ID_User_B |
MCData ID See TS 33.180 [94] clause E.4.1 |
MCDATA |
|
} |
|||
IDRr payload { |
|||
Next payload |
‘00001110’B |
Next payload is IDRkmsi |
|
ID Role |
2 |
Responder (IDRr) |
|
ID Type |
0 |
||
ID len |
Length of ID Data |
||
ID data |
px_MCPTT_ID_User_A |
MCPTT ID associated to the receiving user |
MCPTT |
px_MCVideo_ID_User_A |
MDSI of the MCVideo Domain |
MCVIDEO |
|
px_MCData_ID_User_A |
MDSI of the MCData Domain |
MCDATA |
|
} |
|||
IDRkmsi payload { |
|||
Next payload |
‘00001110’B |
Next payload is IDRkmsr |
|
ID Role |
6 |
Initiator’s KMS (IDRkmsi) |
|
ID Type |
0 |
||
ID len |
Length of ID Data |
||
ID data |
tsc_MCX_KMS_Hostname |
KMS of the initiating user |
|
} |
|||
IDRkmsr payload { |
|||
Next payload |
‘00011010’B |
Next payload is SAKKE (26) |
|
ID Role |
7 |
Responder’s KMS (IDRkmsr) |
|
ID Type |
0 |
||
ID len |
Length of ID Data |
||
ID data |
tsc_MCX_KMS_Hostname |
KMS of the responding user (UE) |
|
} |
|||
SAKKE payload { |
|||
Next payload |
‘00000100’B |
Next payload is SIGN |
|
SAKKE params { |
1 |
Parameter Set 1 according to RFC 6509 [23], Appendix A |
|
ID Scheme |
2 |
‘3GPP MCX hashed UID’ (33.180 [94] E.1.2) |
|
SAKKE data length |
Length of SAKKE data (in bytes) |
16 bits |
|
SAKKE data |
Encapsulated PCK |
The PCK is encapsulated by using the public key (PubEncKey in KMS Certificate) and the UID generated from the MC Service user ID of the terminating user |
|
} |
|||
SIGN (ECCSI) payload { |
|||
S type |
2 |
ECCSI signature |
|
S len |
Length of the signature field (in bytes) |
12 bits |
|
S data |
Signature: In case of UL message the signature shall be validated by the SS |
Signature created according to RFC 3830 [24] clause 5.2 using the algorithm according to RFC 6507 [98] clause 5.2.1 using the UID generated from the MC Service user ID of the initiating user |
|
} |
– Private call (MIKEY-SAKKE sent by the UE)
Table 5.5.9.1-2A: MIKEY-SAKKE I_MESSAGE (Private call) by the UE
Derivation path: RFC 6509 [23], RFC 6043 [25], RFC 3830 [24] |
|||
---|---|---|---|
Field |
Value/remark |
Comment |
Condition |
MIKEY Common Header { |
|||
version |
‘00000001’B |
||
Data Type |
‘00011010’B |
SAKKE msg (26) |
|
Next payload |
Identifier for the next payload (NOTE 1) |
||
V |
‘0’B |
||
PRF func |
‘0000001’B |
PRF-HMAC-SHA-256 |
|
CSB ID |
‘0001xxxx … xxxxxxxx’B |
32-bit PCK-ID The 4 most significant bits of the PCK-ID indicate the purpose of the PCK is to protect Private call communications, the other 28-bits are randomly generated |
|
#CS |
‘00000001’B or ‘00000000’B |
Number of crypto sessions in the CS ID map info: if #CS is 0 the default security policies shall be applied (TS 33.180 [94] E.1.2) |
|
CS ID map type |
2 if #CS > 0 |
GENERIC-ID |
|
1 if #CS == 0 |
empty map |
||
CS ID map Info { |
Present only if #CS > 0 |
||
CS ID |
‘00000000’B or ‘00000001’B |
CS ID of the crypto session: ‘0’ for PCK use from initiatior or ‘1’ for PCK use from receiver within MCPTT (TS 33.180 [94] E.3.3) |
MCPTT |
‘00000010’B or ‘00000011’B |
CS ID of the crypto session: ‘2’ for PCK use from initiatior or ‘3’ for PCK use from receiver within MCVideo (TS 33.180 [94] E.3.3) |
MCVIDEO |
|
Prot type |
0 |
SRTP the security protocol to be used for the crypto session |
|
S |
Any value |
S flag to indicate whether the ROC and SEQ fields are provided (‘1’) or if they are omitted (‘0’) |
|
#P |
1 |
the number of security policies provided for the crypto session |
|
Ps { |
lists the policies for the crypto session |
||
Policy_no_1 |
Any value |
a policy_no that corresponds to the policy_no of a SP payload |
|
} |
|||
Session Data Length |
Length of Session Data (in bytes) |
16 bits the length of Session Data (in bytes). For the Prot type SRTP, Session Data MAY be omitted in the initial message (length = 0), but it MUST be provided in the response message. |
|
Session Data { |
Present if Session Data Length > 0 |
session data for the crypto session |
|
SSRC |
Any value |
specifies the SSRC that MUST be used for the crypto session |
|
ROC |
Any value if S flag is set, not present otherwise |
current/initial rollover counter. If the session has not started, this field is set to ‘0’ |
|
SEQ |
Any value if S flag is set, not present otherwise |
current/initial sequence number |
|
} |
|||
SPI Length |
Length of the SPI |
SPI MAY be omitted in the initial message (length = 0), but it MUST be provided in the response message |
|
SPI |
Any value if present |
the SPI (or MKI) corresponding to the session key to (initially) be used for the crypto session. Other keys can be used. |
|
} |
|||
} |
|||
Timestamp Payload (T) { |
Addressed by ‘00000101’B in the ‘Next payload’ field of the previous payload |
||
Next payload |
Identifier for the next payload (NOTE 1) |
||
TS Type |
‘00000000’B |
NTP-UTC (0): 64-bits |
|
TS Value |
Any value |
64bit UTC value representing the number of seconds since 0h on 1 January 1900 with respect to the Coordinated Universal Time (UTC) |
|
} |
|||
RAND Payload { |
Addressed by ‘00001011’B in the ‘Next payload’ field of the previous payload |
||
Next payload |
Identifier for the next payload (NOTE 1) |
||
RAND len |
‘00010000’B |
16 Bytes RAND |
|
RAND |
Any value |
128-bit random number |
|
} |
|||
IDRi payload { |
Addressed by ‘00001110’B in the ‘Next payload’ field of the previous payload |
||
Next payload |
Identifier for the next payload (NOTE 1) |
||
ID Role |
1 |
Initiator (IDRi) |
|
ID Type |
1 |
URI |
|
ID len |
Length of ID Data |
||
ID data |
px_MCPTT_ID_User_A |
MCPTT ID associated with the initiating user |
MCPTT |
px_MCVideo_ID_User_A |
MCVideo ID See TS 33.180 [94] clause E.4.1 |
MCVIDEO |
|
px_MCData_ID_User_A |
MCData ID See TS 33.180 [94] clause E.4.1 |
MCDATA |
|
} |
|||
IDRr payload { |
Addressed by ‘00001110’B in the ‘Next payload’ field of the previous payload |
||
Next payload |
Identifier for the next payload (NOTE 1) |
||
ID Role |
2 |
Responder (IDRr) |
|
ID Type |
1 |
URI |
|
ID len |
Length of ID Data |
||
ID data |
px_MCPTT_ID_User_B |
MCPTT ID associated to the receiving user |
MCPTT |
px_MCVideo_ID_User_B |
MDSI of the MCVideo Domain |
MCVIDEO |
|
px_MCData_ID_User_B |
MDSI of the MCData Domain |
MCDATA |
|
} |
|||
IDRkmsi payload { |
Addressed by ‘00001110’B in the ‘Next payload’ field of the previous payload |
||
Next payload |
Identifier for the next payload (NOTE 1) |
||
ID Role |
6 |
Initiator’s KMS (IDRkmsi) |
|
ID Type |
1 |
URI |
|
ID len |
Length of ID Data |
||
ID data |
tsc_MCX_KMS_Hostname |
KMS of the initiating user (UE) |
|
} |
|||
IDRkmsr payload { |
Addressed by ‘00001110’B in the ‘Next payload’ field of the previous payload |
||
Next payload |
Identifier for the next payload (NOTE 1) |
||
ID Role |
7 |
Responder’s KMS (IDRkmsr) |
|
ID Type |
1 |
URI |
|
ID len |
Length of ID Data |
||
ID data |
tsc_MCX_KMS_Hostname |
KMS of the responding user |
|
} |
Addressed by ‘00001010’B in the ‘Next payload’ field of the previous payload |
||
Security Properties payload { |
Present if #CS > 0 |
If not present (#CS == 0) then the default security profile defined in Annex E.4.2 of TS 33.180 [94] shall be used |
|
Next payload |
Identifier for the next payload (NOTE 1) |
||
Policy no |
same as Policy_no_1 in the CS ID map info of the header payload |
||
Prot type |
0 |
SRTP |
|
Policy param length |
|||
Policy param { |
|||
{ |
|||
Type |
0 |
Encryption Algorithm |
|
length |
|||
value |
6 |
AES-GCM |
|
} |
|||
{ |
|||
Type |
1 |
Session encryption key length |
|
length |
|||
value |
16 |
16 octets |
|
} |
|||
{ |
|||
Type |
4 |
Session salt key length |
|
length |
|||
value |
12 |
12 octets |
|
} |
|||
{ |
|||
Type |
5 |
SRTP PRF |
|
length |
|||
value |
0 |
AES-CM |
|
} |
|||
{ |
|||
Type |
6 |
Key derivation rate |
|
length |
|||
value |
0 |
No session key refresh. |
|
} |
|||
{ |
|||
Type |
20 |
AEAD authentication tag length |
|
length |
|||
value |
16 |
16 octets |
|
} |
|||
} |
|||
} |
|||
SAKKE payload { |
Addressed by ‘00011010’B in the ‘Next payload’ field of the previous payload |
||
Next payload |
Identifier for the next payload (NOTE 1) |
||
SAKKE params { |
1 |
Parameter Set 1 according to RFC 6509 [23], Appendix A |
|
ID Scheme |
2 |
‘3GPP MCX hashed UID’ (33.180 [94] E.1.2) |
|
SAKKE data length |
Length of SAKKE data (in bytes) |
16 bits |
|
SAKKE data |
Encapsulated PCK |
The PCK is encapsulated by using the public key (PubEncKey in KMS Certificate) and the UID generated from the MC Service user ID of the terminating user |
|
} |
|||
SIGN (ECCSI) payload { |
Addressed by ‘00000100’B in the ‘Next payload’ field of the previous payload |
||
S type |
2 |
ECCSI signature |
|
Signature len |
Length of the signature field (in bytes) |
12 bits |
|
S data |
Signature: In case of UL message the signature shall be validated by the SS |
Signature created according to RFC 3830 [24] clause 5.2 using the algorithm according to RFC 6507 [98] clause 5.2.1 using the UID generated from the MC Service user ID of the initiating user |
|
} |
|||
NOTE 1: MIKEY payloads may occur in any order apart from the header payload which is always the first payload and the signature payload which is always the last payload |
– GMK distribution (MIKEY-SAKKE sent by the SS)
Table 5.5.9.1-3: MIKEY-SAKKE I_MESSAGE (GMK distribution by the SS)
Derivation path: RFC 6509 [23], RFC 6043 [25], RFC 3830 [24] |
|||
---|---|---|---|
Field |
Value/remark |
Comment |
Condition |
MIKEY Common Header { |
Any |
||
version |
‘00000001’B |
||
Data Type |
‘00011010’B |
SAKKE msg (26) |
|
Next payload |
‘00000101’B |
Next payload is timestamp |
|
V |
‘0’B |
||
PRF func |
‘0000001’B |
PRF-HMAC-SHA-256 |
|
CSB ID |
GUK-ID: 4 bit purpose tag (‘0000’B for GMK) & 28 bit identifier |
Group User Key Identifier Derived from GMK-ID and User Salt according to TS 33.180 [94] clause 5,2,3 |
|
#CS |
‘00000000’B |
no crypto sessions in the CS ID map info. |
|
CS ID map type |
1 |
empty map |
|
CS ID map Info |
Not present |
||
} |
|||
Timestamp Payload (T) { |
|||
Next payload |
‘00001011’B |
Next payload is RAND |
|
TS Type |
‘00000000’B |
NTP-UTC (0): 64-bits |
|
TS Value |
Current system time |
64bit UTC value representing the number of seconds since 0h on 1 January 1900 with respect to the Coordinated Universal Time (UTC) |
|
} |
|||
RAND Payload { |
|||
Next payload |
‘00001110’B |
Next payload is IDRi |
|
RAND len |
‘00010000’B |
16 Bytes RAND |
|
RAND |
128-bit random number arbitrarily selected by the SS |
||
} |
|||
IDRi payload { |
|||
Next payload |
‘00001110’B |
Next payload is IDRr |
|
ID Role |
1 |
Initiator (IDRi) |
|
ID Type |
1 |
URI |
|
ID len |
Length of ID Data |
||
ID data |
tsc_MCX_GMS_Hostname |
URI of the group management server |
|
} |
|||
IDRr payload { |
|||
Next payload |
‘00001110’B |
Next payload is IDRkmsi |
|
ID Role |
2 |
Responder (IDRr) |
|
ID Type |
1 |
||
ID len |
Length of ID Data |
||
ID data |
px_MCPTT_ID_User_A |
MCPTT ID associated to the group management client |
MCPTT |
px_MCVideo_ID_User_A |
MCVideo ID associated to the group management client |
MCVIDEO |
|
px_MCData_ID_User_A |
MCData ID associated to the group management client |
MCDATA |
|
} |
|||
IDRkmsi payload { |
|||
Next payload |
‘00001110’B |
Next payload is IDRkmsr |
|
ID Role |
6 |
Initiator’s KMS (IDRkmsi) |
|
ID Type |
1 |
URI |
|
ID len |
Length of ID Data |
||
ID data |
tsc_MCX_KMS_Hostname |
||
} |
|||
IDRkmsr payload { |
|||
Next payload |
‘00011010’B |
Next payload is SAKKE (26) |
|
ID Role |
7 |
Responder’s KMS (IDRkmsr) |
|
ID Type |
1 |
||
ID len |
Length of ID Data |
||
ID data |
tsc_MCX_KMS_Hostname |
KMS of the UE |
|
} |
|||
SAKKE payload { |
|||
Next payload |
‘00010101’B |
Next payload is General Extension |
|
SAKKE params |
1 |
Parameter Set 1 according to RFC 6509 [23], Appendix A |
|
ID Scheme |
2 |
‘3GPP MCX hashed UID’ (33.180 [94] E.1.2) |
|
SAKKE data length |
Length of SAKKE data (in bytes) |
||
SAKKE data |
Encapsulated GMK |
The GMK is encapsulated by using the SAKKE public key and the UID generated from the MC Service user ID of the group management client (provided in IDRr) |
|
} |
|||
General Extension Payload { |
|||
Next payload |
‘00000100’B |
Next payload is SIGN |
|
Type |
7 |
‘3GPP key parameters’ |
|
..Length |
Length of the data (in bytes) |
||
Content { |
MCData Protected Payload message according to TS 33.180 [94] clause 8.5.4.1 |
||
Message Type |
‘C3’O |
protected and authenticated DATA PAYLOAD |
|
Date and Time |
Same number of seconds as in the Timestamp Payload |
UTC time in seconds since midnight UTC of January 1, 1970 |
|
Payload ID |
‘00000000’O |
value according to TS 33.180 [94] E.6.1 |
|
Payload sequence number |
’00’O |
value according to TS 33.180 [94] E.6.1 |
|
Payload algorithm |
’01’O |
AEAD_AES_128_GCM |
|
Signalling algorithm |
not present |
||
IV |
‘AAAAAAAAAAAAAAAA5555555555555555’O |
arbitrarily selected |
|
DPPK-ID |
Same as the CSB ID in the MIKEY Common Header |
||
Payload { |
‘Payload’ element according to TS 24.282 [87] clause 15.2.13 |
||
type |
’78’O |
Value as used in MCData messages in TS 24.282 [87] |
|
length |
length of the payload data |
||
content type |
’02’O |
BINARY |
|
Data { |
Protected Payload: encrypted with AEAD algorithms |
See TS 33.180 [94] clause E.6 and 8.5.4.2 |
|
Key Type |
‘00000000’B |
GMK |
|
….Status |
‘1’ |
Not-revoked |
|
Activation Time |
0 |
The time in UTC at which the associated GMK 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 |
|
Expiry Time |
0 |
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. |
|
Text |
"" |
no text: Text element shall contain Length sub-element with the value 0 (see TS 33.180 [94] E.6.5) |
|
Group IDs { |
|||
Number of Group IDs |
‘1’ |
||
Group ID |
px_MCPTT_Group_A_ID |
The ID for the group associated with the key. |
MCPTT |
px_MCVideo_Group_A_ID |
The ID for the group associated with the key. |
MCVIDEO |
|
px_MCData_Group_A_ID |
The ID for the group associated with the key. |
MCDATA |
|
} |
|||
} |
|||
} |
|||
MIKEY_SAKKE I-MESSAGE |
not present |
||
} |
|||
SIGN (ECCSI) payload { |
|||
S type |
2 |
ECCSI signature |
|
S len |
Length of the signature field (in bytes) |
12 bits |
|
S data |
Signature |
The signature shall be created according to RFC 3830 [24] clause 5.2 using the algorithm according to RFC 6507 [98] clause 5.2.1 using the UID generated from the identifier associated with the group management server |
|
} |
– MSCCK distribution (MIKEY-SAKKE sent by the SS)
Table 5.5.9.1-4: MIKEY-SAKKE I_MESSAGE (MSCCK distribution by the SS)
Derivation path: RFC 6509 [23], RFC 6043 [25], RFC 3830 [24] |
|||
---|---|---|---|
Field |
Value/remark |
Comment |
Condition |
MIKEY Common Header { |
Any |
||
version |
‘00000001’B |
||
Data Type |
‘00011010’B |
SAKKE msg (26) |
|
Next payload |
‘00000101’B |
Next payload is timestamp |
|
V |
‘0’B |
||
PRF func |
‘0000001’B |
PRF-HMAC-SHA-256 |
|
CSB ID |
‘0101xxxx … xxxxxxxx’B |
32-bit MSCCK-ID The 4 most significant bits of the MSCCK-ID indicate the purpose of the MSCCK is to protect general purpose subchannel control messages. The other 28-bits are randomly generated |
|
#CS |
‘00000000’B |
no crypto sessions in the CS ID map info. |
|
CS ID map type |
1 |
empty map |
|
CS ID map Info |
Not present |
||
} |
|||
Timestamp Payload (T) { |
|||
Next payload |
‘00001011’B |
Next payload is RAND |
|
TS Type |
‘00000000’B |
NTP-UTC (0): 64-bits |
|
TS Value |
Current system time |
64bit UTC value representing the number of seconds since 0h on 1 January 1900 with respect to the Coordinated Universal Time (UTC) |
|
} |
|||
RAND Payload { |
|||
Next payload |
‘00001110’B |
Next payload is IDRi |
|
RAND len |
‘00010000’B |
16 Bytes RAND |
|
RAND |
128-bit random number arbitrarily selected by the SS |
||
} |
|||
IDRi payload { |
|||
Next payload |
‘00001110’B |
Next payload is IDRr |
|
ID Role |
1 |
Initiator (IDRi) |
|
ID Type |
1 |
URI |
|
ID len |
Length of ID Data |
||
ID data |
tsc_MCPTT_PublicServiceId_A |
The public service identity identifying the participating MCPTT function |
|
} |
|||
IDRr payload { |
|||
Next payload |
‘00001110’B |
Next payload is IDRkmsi |
|
ID Role |
2 |
Responder (IDRr) |
|
ID Type |
1 |
URI |
|
ID len |
Length of ID Data |
||
ID data |
px_MCPTT_ID_User_A |
MCPTT ID associated to the terminating user |
|
} |
|||
IDRkmsi payload { |
|||
Next payload |
‘00001110’B |
Next payload is IDRkmsr |
|
ID Role |
6 |
Initiator’s KMS (IDRkmsi) |
|
ID Type |
1 |
URI |
|
ID len |
Length of ID Data |
||
ID data |
tsc_MCX_KMS_Hostname |
||
} |
|||
IDRkmsr payload { |
|||
Next payload |
‘00011010’B |
Next payload is SAKKE (26) |
|
ID Role |
7 |
Responder’s KMS (IDRkmsr) |
|
ID Type |
1 |
URI |
|
ID len |
Length of ID Data |
||
ID data |
tsc_MCX_KMS_Hostname |
KMS of the UE |
|
} |
|||
SAKKE payload { |
|||
Next payload |
‘00000100’B |
Next payload is SIGN |
|
SAKKE params |
1 |
Parameter Set 1 according to RFC 6509 [23], Appendix A |
|
ID Scheme |
2 |
‘3GPP MCX hashed UID’ (33.180 [94] E.1.2) |
|
SAKKE data length |
Length of SAKKE data (in bytes) |
||
SAKKE data |
Encapsulated MSCCK |
The MSCCK is encapsulated by using the SAKKE public key and the UID generated from the MC Service user ID of the terminating user |
|
} |
|||
SIGN (ECCSI) payload { |
|||
S type |
2 |
ECCSI signature |
|
S len |
Length of the signature field (in bytes) |
12 bits |
|
S data |
Signature |
The signature shall be created according to RFC 3830 [24] clause 5.2 using the algorithm according to RFC 6507 [98] clause 5.2.1 using the UID generated from the public service identity identifying the participating MCPTT function |
|
} |
– MuSiK distribution (MIKEY-SAKKE sent by the SS)
Table 5.5.9.1-5: MIKEY-SAKKE I_MESSAGE (MuSiK distribution by the SS)
Derivation path: RFC 6509 [23], RFC 6043 [25], RFC 3830 [24] |
|||
---|---|---|---|
Field |
Value/remark |
Comment |
Condition |
MIKEY Common Header { |
Any |
||
version |
‘00000001’B |
||
Data Type |
‘00011010’B |
SAKKE msg (26) |
|
Next payload |
‘00000101’B |
Next payload is timestamp |
|
V |
‘0’B |
||
PRF func |
‘0000001’B |
PRF-HMAC-SHA-256 |
|
CSB ID |
‘0110xxxx … xxxxxxxx’B |
32-bit MuSiK-ID The 4 most significant bits of the MuSiK-ID indicate the purpose of the MuSiK is to protect floor control messages sent over MBMS. The other 28-bits are randomly generated |
|
#CS |
‘00000000’B |
no crypto sessions in the CS ID map info. |
|
CS ID map type |
1 |
empty map |
|
CS ID map Info |
Not present |
||
} |
|||
Timestamp Payload (T) { |
|||
Next payload |
‘00001011’B |
Next payload is RAND |
|
TS Type |
‘00000000’B |
NTP-UTC (0): 64-bits |
|
TS Value |
Current system time |
64bit UTC value representing the number of seconds since 0h on 1 January 1900 with respect to the Coordinated Universal Time (UTC) |
|
} |
|||
RAND Payload { |
|||
Next payload |
‘00001110’B |
Next payload is IDRi |
|
RAND len |
‘00010000’B |
16 Bytes RAND |
|
RAND |
128-bit random number arbitrarily selected by the SS |
||
} |
|||
IDRi payload { |
|||
Next payload |
‘00001110’B |
Next payload is IDRr |
|
ID Role |
1 |
Initiator (IDRi) |
|
ID Type |
1 |
URI |
|
ID len |
Length of ID Data |
||
ID data |
tsc_MCPTT_PublicServiceId_A |
The public service identity identifying the participating MCPTT function |
|
} |
|||
IDRr payload { |
|||
Next payload |
‘00001110’B |
Next payload is IDRkmsi |
|
ID Role |
2 |
Responder (IDRr) |
|
ID Type |
1 |
URI |
|
ID len |
Length of ID Data |
||
ID data |
px_MCPTT_ID_User_A |
MCPTT ID associated to the terminating user |
|
} |
|||
IDRkmsi payload { |
|||
Next payload |
‘00001110’B |
Next payload is IDRkmsr |
|
ID Role |
6 |
Initiator’s KMS (IDRkmsi) |
|
ID Type |
1 |
URI |
|
ID len |
Length of ID Data |
||
ID data |
tsc_MCX_KMS_Hostname |
||
} |
|||
IDRkmsr payload { |
|||
Next payload |
‘00011010’B |
Next payload is SAKKE (26) |
|
ID Role |
7 |
Responder’s KMS (IDRkmsr) |
|
ID Type |
1 |
URI |
|
ID len |
Length of ID Data |
||
ID data |
tsc_MCX_KMS_Hostname |
KMS of the UE |
|
} |
|||
SAKKE payload { |
|||
Next payload |
‘00000100’B |
Next payload is SIGN |
|
SAKKE params |
1 |
Parameter Set 1 according to RFC 6509 [23], Appendix A |
|
ID Scheme |
2 |
‘3GPP MCX hashed UID’ (33.180 [94] E.1.2) |
|
SAKKE data length |
Length of SAKKE data (in bytes) |
||
SAKKE data |
Encapsulated MuSiK |
The MuSiK is encapsulated by using the SAKKE public key and the UID generated from the MC Service user ID of the terminating user |
|
} |
|||
SIGN (ECCSI) payload { |
|||
S type |
2 |
ECCSI signature |
|
S len |
Length of the signature field (in bytes) |
12 bits |
|
S data |
Signature |
The signature shall be created according to RFC 3830 [24] clause 5.2 using the algorithm according to RFC 6507 [98] clause 5.2.1 using the UID generated from the public service identity identifying the participating MCPTT function |
|
} |