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’
See 33.180 [94] clause E.6.1

..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

}