PC3PC8 Flows Tab
Click here to see this page in full context

Landslide Performance Test System – Release 24.3 September 2024

PC3PC8 Flows Tab

In MME Nodal testing, the PC3 Pc8 Flows tab on the PC3/PC8/Ub Interface allows for support of supplementary services : In the Proximity-based Services (ProSe) network, PC3 is the reference point between the UE and ProSe Function. PC8 is the reference point between the UE and ProSe Key Management Function. The SUT is ProSe Fn/BSF. The purpose of the Ub (Bootstrapping interface) is to create a security association between UE and BSF.

In the Proximity-based Services (ProSe) network, PC3 is the reference point between the UE and ProSe Function. PC8 is the reference point between the UE and ProSe Key Management Function. The following diagram is from TS 33.303.

 

The following diagram in 3GPP TS 23.303 shows that the Prose Function is a logic function in the ProSe network used for network related action.

 

 

 

Bootstrapping procedure is embedded in the PSk-TLS handshaking process:

 

HTTPS and MIKEY Based Procedures on PC3:

After PSK-TLS connection is set up successfully, various of procedures can be performed over PC3 and PC8 interfaces. The following diagram is from TS 33.303.

HTTPS and MIKEY Based Procedures on PC3/PC8

After PSK-TLS connection is set up successfully, various of procedures can be performed over PC3 and PC8 interfaces.

The above procedures include some messages over HTTP, and some massages over MIKEY (which is a protocol based on udp, and may be on SIP/SDP).

This is part of the ProSe service authorization procedures over PC3 interface as specified in TS 24.334 Sub-clause 5.1, TS 24.333, and OMA-TS-DM_Protocol-V1_2. 

OMA Device Management (OMA DM) protocol and SyncML protocol are used.

List of applicable documents referenced by this topic: 

Document Number

Title

3GPP TS 23.305 Release 15

Proximity-based (ProSe); Stage 2

3GPP TS 24.109 Release 14

Bootstrapping interface (Ub) and network application function interface (Ua); Protocol details

3GPP TS 24.333 Release 16

Proximity-based (ProSe) Management Objects (MO)

3GPP TS 24.334 Release 15

Proximity-based (ProSe) User Equipment (UE) to ProSe function protocol aspects

3GPP TS 24.623 Release 14

Extensible Markup Language (XML)Configuration Access Protocol (XCAP) over the Ut interface for Manipulating Supplementary Services

3GPP TS 23.003 Release 14

Numbering, addressing and identification

3GPP TS 33.804 Release 12

Single Sign On (SSO) application security for Common IP Multimedia Subsystem (IMS) based on Session Initiation Protocol (SIP) Digest

3GPP TS 33.210 Release 14

Network Domain (NDS); IP network layer security

3GPP TS 33.220 Release 14

Generic Authentication Architecture (GAA); Generic Bootstrapping Architecture (GBA)

3GPP TS 33.222 Release 15

Generic Authentication Architecture (GAA); Access to network application functions using Hypertext Transfer Protocol over Transport Layer Security (HTTPS)

3GPP TS 33.303 Release 15

Proximity-based (ProSe); Security aspects

3GPP TS 33.310 Release 16

Network Domain Security (NDS); Authentication Framework (AF)

RFC 7230

Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing

RFC 7231

Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content

RFC 7234

Hypertext Transfer Protocol (HTTP/1.1): Caching

RFC 7235

Hypertext Transfer Protocol (HTTP/1.1): Authentication

RFC 7616

HTTP Digest Access Authentication

RFC 4279

Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)

RFC 3380

MIKEY; Multimedia Internet KEYing

RFC 3310

Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)

 

HTTP Messages

HTTP Flow:

HTTP Messages

 

 

 

HTTP SCRIPT:

HTTP Supplementary Script  - Create HTTP tests using Scripts and Actions

HTTP Message Editor (Right pane)

  • HTTP Flow Editor (Left Pane)

  • HTTP Message Editor (Right Pane)

  • Actions (Right Pane) - select from a list of  actions

  • Built-ins (right pane) - Select from a list of pre-built scripts

 

 

Pc3Pc8 Http Messages

The HTTP tab | HTTP Messages pane displays two columns/panes. The left pane displays HTTP message flows line diagram and the right column/pane displays the relevant message header and message body content. When you click on a message (of a flow) in the left pane, the message is highlighted and on the right column/pane, displays the HTTP message headers and Body (HTTP message body, where applicable) for the highlighted message.

A default configuration is displayed as a template and allows you to modify HTTP headers and body (XML Body), where applicable. (A template is displayed for every HTTP message available to be modified).

Open a HTTP Flow Template

Click to open the HTTP Flow Template window and select a HTTP Flow from the available libraries.   

NOTE: The Save Template Dialog automatically uses the last opened/saved template name and you may edit it as required.

Save as Data Profile Template

Click to save the elected HTTP Flow as a template.

NOTE: Copy of Data Profile and HTTP Flow Templates prevent copy/move of system owned dependent items, e.g. {Basic}, {Scenario…} library items.

Pop-up HTTP Flow

Click to open the HTTP Flow in a larger re-sizable window.

HTTP Flow Line Diagram

Click on any HTTP Flow Message (left column) to enable HTTP Message editor (right column):

 

NOTE: If a HTTP message is not available for editing, the right column remains blank. (Headers and Body tab remain blank).

 

Pc3Pc8 HTTP Call Flow (Left Pane)

The HTTP Call Flow (Left Pane) shows a flow of messages expected for a current test configuration.  When you select a message in the flow control area, default HTTP templates are shown in the editing windows (Right Pane).

The line diagram illustrates standard representation of the selected message. Each message (represented by a horizontal line) includes a text string (Field) or a combination of a text string and predefined parameter type (Filler; shown in blue on the right pane).

Use Default

Selected by default. When selected, default content of HTTP headers and HTTP body are used in the test case.

When not selected, the template will be used to replace the default message content.

HTTP Flow Line Diagram

Click on any HTTP Flow Message (left column) to enable HTTP Message editor (right column)

NOTE: If a HTTP message is not available for editing, the right column remains blank. (Headers and Body tab remain blank).

 

HTTP Messages Editor (Right Pane)

Use Default

When selected, for all messages in the test case, Use Default is disabled for individual message (on the Right Pane).

When not selected, individual message editor will be enabled for configuration.

Reset, Field+ (list), and Filler+ (list)

Available when Use Default is not selected. The Reset, Field+ , and Filler+ buttons help you with the editing process. You may replace the original Fields and Fillers in the message Header/Body by any text.

Reset

Click to reset the modified content back to the default configuration

Field+

Click to display a list of text string. Select a text string to insert within your SIP message.  You may also right-click at the insertion point, select the Insert HTTP Field option from the context menu.

Options: Authorization, Content-Length, Content-Type, Host, MME-Version, User-Agent, X-3GPP-Intended-Identity

Filler+

Click to display a list of parameters/variables. Select a parameter to insert within your HTTP message, which is shown in blue.  You may also right-click at the insertion point and select the Insert Auto-Fill option from the context menu.

  • See Fillers:

 

  • "XML Body” is present exclusively for the XML data that will be carried in a message. This will be applicable only for PUT Message operations which will be part of actions that have “Update Service Info”. For “Custom Service” Action for “Updating Service Info”, the XML Body tab will be enabled for editing but will be blank.

XML Body:

<?xml version="1.0" encoding="UTF-8"?>{CR}

{LF}

<SyncML xmlns="SYNCML:SYNCML1.2">{CR}

{LF}

<SyncHdr>{CR}

{LF}

<VerDTD>1.2</VerDTD>{CR}

{LF}

<VerProto>DM/1.2</VerProto>{CR}

{LF}

<SessionID>1</SessionID>{CR}

{LF}

<MsgID>1</MsgID>{CR}

{LF}

<Target>{CR}

{LF}

<LocURI>http://prosefn.Spirent.com:8080/prose/dm</LocURI>{CR}

{LF}

</Target>{CR}

{LF}

<Source>{CR}

{LF}

<LocURI>urn:oma:mo:ext-3gpp-prose-direct-provisioning:1.0:provision</LocURI>{CR}

{LF}

</Source>{CR}

{LF}

</SyncHdr>{CR}

{LF}

<SyncBody>{CR}

{LF}

<Alert>{CR}

{LF}

<CmdID>1</CmdID>{CR}

{LF}

<Data>1226</Data>{CR}

{LF}

<Item>{CR}

{LF}

<Source><LocURI>urn:oma:mo:ext-3gpp-prose-direct-provisioning:1.0:provision</LocURI></Source>{CR}

{LF}

</Item>{CR}

{LF}

</Alert>{CR}

{LF}

<Replace>{CR}

{LF}

<CmdID>2</CmdID>{CR}

{LF}

<Item>{CR}

{LF}

<Source>{CR}

{LF}

<LocURI>IMSI:{imsi}</LocURI>{CR}

{LF}

<LocName>MCPTT-ID:{public-username}</LocName>{CR}

{LF}

</Source>{CR}

{LF}

</Item>{CR}

{LF}

</Replace>{CR}

{LF}

<Final />{CR}

{LF}

</SyncBody>{CR}

{LF}

</SyncML>{CR}

{LF}

 

CRLF/CR/LF

Click to insert carriage return (CR) or line feed (LF) characters or both (CRLF) at the selected byte/offset or right-click at the insertion point and select the New Line Mode option from the context menu.

Right-Click context menu

You may also right-click at the insertion point and select the required option from the context menu: Insert Field, Insert Auto-Fill, or New Line Mode (CRLF, CR, LF).

 

Editing HTTP Message
  • Clear Use Default selected (both in the Left and the Right panes).
  • Select the required flow (represented by a line in the left pane), a pre configured template displays (where applicable) on the right pane.
  • Click the Header/Body tab to edit, insert, modify, delete information by using the Field + (list) or the Filler + (list) as required.

Example of what happens when editing
  • Text string (field) that is not followed by a parameter (filler):

User-Agent: Spirent-Ut-Client{CR}{LF}

Text string User-Agent: Spirent-Ut-Client will always be included in the final message.

• Text string followed by a variable/parameter/filler:

  • Content-Type: <{Content-type}>{CR}{LF}

  • If {Content-type} exists in the original message then the final message will include string.

Content-type: <sip:[email protected];transport=udp>

  • If {Content-type} does not exist in the original message then the whole string will not be in the final message.

Conditional Parameters (used when parameters used in your template do not exist in the original message)

Since a configurable HTTP message is generated from an existing message, some parameters used in your template may not exist in the original message. You may use “…-if” parameter to take care of such cases.

-if

Parameters with -if at the end are applied to the text string that starts from the previous parameter (Filler). Parameter with –if be inserted to indicate that this text string should be skipped if it does not exist in the message.

Examples:

Content-Length:{content-length-if}{CR}{LF}

Text string Content-Length  will be included in the final message only if it exists in the original message.

Content-Length:{CR}{LF}

Attribute Content-Length will be always included into the final message regardless of whether it exists in the original message.

Example HTTP Header and Template

PC3_PC8_DOWNLOAD_MO_REQ

 

POST . /prose/dm HTTP/1.1{CR}{LF}

Host: {host-ip}{host-port}{CR}{LF}

Content-Type: {content-type}{CR}{LF}

Content-Type: {content-length}{CR}{LF}

{CR}{LF}

Example XML Body

PC3_PC8_DOWNLOAD_MO_INIT_REQ:

<?xml version="1.0" encoding="UTF-8"?>{CR}

{LF}

<SyncML xmlns="SYNCML:SYNCML1.2">{CR}

{LF}

<SyncHdr>{CR}

{LF}

<VerDTD>1.2</VerDTD>{CR}

{LF}

<VerProto>DM/1.2</VerProto>{CR}

{LF}

<SessionID>1</SessionID>{CR}

{LF}

<MsgID>1</MsgID>{CR}

{LF}

<Target>{CR}

{LF}

<LocURI>http://prosefn.Spirent.com:8080/prose/dm</LocURI>{CR}

{LF}

</Target>{CR}

{LF}

<Source>{CR}

{LF}

<LocURI>urn:oma:mo:ext-3gpp-prose-direct-provisioning:1.0:provision</LocURI>{CR}

{LF}

</Source>{CR}

{LF}

</SyncHdr>{CR}

{LF}

<SyncBody>{CR}

{LF}

<Alert>{CR}

{LF}

<CmdID>1</CmdID>{CR}

{LF}

<Data>1226</Data>{CR}

{LF}

<Item>{CR}

{LF}

<Source><LocURI>urn:oma:mo:ext-3gpp-prose-direct-provisioning:1.0:provision</LocURI></Source>{CR}

{LF}

</Item>{CR}

{LF}

</Alert>{CR}

{LF}

<Replace>{CR}

{LF}

<CmdID>2</CmdID>{CR}

{LF}

<Item>{CR}

{LF}

<Source>{CR}

{LF}

<LocURI>IMSI:{imsi}</LocURI>{CR}

{LF}

<LocName>MCPTT-ID:{public-username}</LocName>{CR}

{LF}

</Source>{CR}

{LF}

</Item>{CR}

{LF}

</Replace>{CR}

{LF}

<Final />{CR}

{LF}

</SyncBody>{CR}

{LF}

</SyncML>{CR}

{LF}

HTTP Supplementary Script

The HTTP Supplementary option provides users with a way for creating HTTP tests using scripts and actions.

The main advantage of using scripts and actions;  is to allow users creating different HTTP message flows tailored to their particular test environments.

A script (a sample is shown below) consists of one of more actions.

An action performs a particular small common task in HTTP tests such as BootStrapping With BSF.  Actions are fixed and predefined by Landslide software; they cannot be created by users.  

      

Message

Example UE Starts ProSe Public Safety Direct Services Provisioning MO (success, no auth) script:

 

 

 

PC3 PC8 Actions

See Complete list of Actions - PC3 PC8 Actions

PC3 PC8 Built-ins

See Complete list of Built-in Scripts - Currently there are no Built-in Scripts available for PC3 PC8 Flows.

^ Back to Top

XCAP HTTP 1.1 Methods  

XCAP HTTP 1.1 Methods for Ub Client:

GET METHOD

HTTP GET method can be used to fetch the xml data for a particular supplementary service. GET method can be challenged by the XCAP server.

PUT METHOD

HTTP PUT method can be used to update the xml data for a particular supplementary service. PUT method can be challenged by the XCAP server.

DELETE METHOD

HTTP DELETE method can be used to remove the xml data for a particular supplementary service or the entire document. DELETE method can be challenged by the XCAP server.

Message flows for PC3 PC8 Supplementary services:

The following message flows will be available for each supplementary service.

User can select the supplementary service as shown in the table below.

PC3 PC8 Actions

ProSe Public Safety Direct Services Provisioning MO (Success, no auth)

Downloading and Updating MO - ProSe Public Safety Direct Services Provisioning MO

These procedures include some messages over HTTP, and some massages over MIKEY (which is a protocol based on udp, and may be on SIP/SDP).

This is part of the ProSe service authorization procedures over PC3 interface as specified in TS 24.334 Sub-clause 5.1, TS 24.333, and OMA-TS-DM_Protocol-V1_2. 

OMA Device Management (OMA DM) protocol and SyncML protocol are used.

 

 

UE Sends out multiple HTTP POST messages in this procedure. The first one includes Alert command to set URI and MO ID of the ProSe safety direct provisioning MO, and a Replace command to provide IMSI and MCPTT-ID of the UE.

Script a template of the message as below:

Download/Update MO Initial Request

POST ./prose/dm HTTP/1.1

Host: prosefn.Spirent.com:8080

Content-Type: application/vnd.syncml-xml; charset="utf-8"

Content-Length: {content-length}

Accept: application/vnd.syncml-xml

 

<?xml version="1.0" encoding="utf-8" ?>

<SyncML xmlns="SYNCML:SYNCML1.2"> 

   <SyncHdr>

     <VerDTD>1.2</VerDTD>

     <VerProto>DM/1.2</VerProto>

     <SessionID>1</SessionID>

     <MsgID>1</MsgID>

     <Target>

       <LocURI>http://prosefn.Spirent.com:8080/prose/dm</LocURI>

     </Target>

     <Source>

       <LocURI>urn:oma:mo:ext-3gpp-prose-direct-provisioning:1.0:provision</LocURI>

     </Source>

   </SyncHdr> 

   <SyncBody>

     <Alert>

       <CmdID>1</CmdID>

       <Data>1226</Data>

       <Item>

          <Source><LocURI>urn:oma:mo:ext-3gpp-prose-direct-provisioning:1.0:provision</LocURI></Source>

       </Item>

     </Alert> 

     <Replace>

       <CmdID>2</CmdID>

       <Item>

         <Source>

           <LocURI>IMSI:{imsi}</LocURI>

           <LocName>MCPTT-ID:{public-username}</LocName>

         </Source>

       </Item>

     </Replace>

     <Final />

   </SyncBody>

 </SyncML>

 

 

The second HTTP POST message includes Status for each of the commands in the HTTP Response message it received.

Script template of the message as below:

Download/Update MO Request

POST ./prose/dm HTTP/1.1

Host: prosefn.Spirent.com:8080

Content-Type: application/vnd.syncml-xml; charset="utf-8"

Content-Length: {content-length}

Accept: application/vnd.syncml-xml

 

<?xml version="1.0" encoding="utf-8" ?>

<SyncML xmlns="SYNCML:SYNCML1.2">

   <SyncHdr>

     <VerDTD>1.2</VerDTD>

     <VerProto>DM/1.2</VerProto>

     <SessionID>1</SessionID>

     <MsgID>2</MsgID>

     <Target>

       <LocURI>http://prosefn.Spirent.com:8080/prose/dm</LocURI>

     </Target>

     <Source>

       <LocURI>urn:oma:mo:ext-3gpp-prose-direct-provisioning:1.0:provision</LocURI>

     </Source>

   </SyncHdr>

   <SyncBody>

     <Status>

       <CmdID>1</CmdID>

       <MsgRef>1</MsgRef>

       <CmdRef>0</CmdRef>

       <Cmd>SyncHdr</Cmd>

       <Data>200</Data>

     </Status>

     <Status>

       <CmdID>2</CmdID>

       <MsgRef>1</MsgRef>

       <CmdRef>4</CmdRef>

       <Cmd>Delete</Cmd>

       <Data>200</Data>

     </Status>

     <Status>

       <CmdID>3</CmdID>

       <MsgRef>1</MsgRef>

       <CmdRef>5</CmdRef>

       <Cmd>Add</Cmd>

       <Data>200</Data>

     </Status>

     <Final />

   </SyncBody>

 </SyncML>

 

Fillers are available in the HTTP message templates, so each UE will be able to put dynamic information element into the HTTP POST messages.

Some of the available fillers are:

  • imsi
  • public-username (this can be used as MCPTT-ID)
  • group-id
  • discovery-group-id

ProSe Downloading/Updating PGK (success, no auth)

Select ProSe Downloading/Updating PGK (success, no auth).

 

This is part of the key management procedures over PC8 interface as specified in TS 33.303 Sub-clause 6.2.3

The following Diagram is from TS 33.303.

 

 

There are two types of messages. One is Key Request and Response messages carried on HTTPS. The other is MIKEY messages used to transmit the keys. The port number on PKMF for MIKEY is 2269.

Key Request/Response Transaction (3GPP TS 33.303 [34])

As specified in TS 33.303 Annex E1, E2, E3, and E4, Key Request and Key Response messages between UE and ProSe KMF are based on HTTP 1.1, and the messages are contained in the HTTP message body as XML format.

Landslide has provided Key Management Action in the HTTP script to perform this procedure.

There will be one HTTP POST message from UE to PKMF and one HTTP 200 OK message from PKMF to UE.

Key Request

When sending a Key Request message to request the ProSe Key Management Function to send PGKs or to change the groups for which it wants to receive keys, the UE shall include the following information:

  • The indication of security algorithms that the UE supports for one-to-many communications.
  • List of Group Identities for which the UE would like to receive keys.
    • Group Identities obtained from ProSe Public Safety Direct Services Provisioning MO transaction.
  • For each Group Identity, the PGK IDs of any keys for that group (NOTE: PKG IDs are from MIKEY transaction (1.2.1)).
    • If the UE holds no keys for this group, then it sends an all zero PGK ID.
  • List of Group Identities for which the UE would like to STOP receiving keys.

The ProSe Key Management Function shall check that the UE is authorised to receive keys for the requested groups. This is done by using the UE identity that is bound to the keys that established the TLS tunnel in which the message is sent. It also checks that the UE supports the confidentiality algorithm required for each group. If the UE doesn’t then the ProSe Key Management Function responds with the appropriate error for that group. The ProSe Key Management Function shall update the stored set of the groups for which the UE will be sent keys.

Key Request XML

POST ./servlet/syncit HTTP/1.1

Host: www.datasync.org

Content-Type: application/xml; charset="utf-8"

Content-Length: {content-length}

Accept: application/vnd.syncml-xml

 

<?xml version="1.0" encoding="utf-8" ?>

<prose-key-management-message>

    <KeyReq-info>

        <transaction-ID>1</transaction-ID>

        <AlgorithmAvailable>0f</AlgorithmAvailable>

        <GroupKeyRequest>

            <GroupId>0</GroupId>

            <PGKId>0</PGKId>

        </GroupKeyRequest>

    </KeyReq-info>

</prose-key-management-message>

Key Response

The ProSe Key Management Function responds to the UE with a Key Response message that includes the following parameters:

  • List of the Group Identities that were included in the Key Request message.
  • For each group that keys will be supplied for, the group member identity and the security algorithm that should be used to protect the data.
  • For each of the other groups, a status code to indicate why keys will not be supplied for that group.
  • An optional PMK and PMK Identity.

For the groups that the UE will get keys for, the UE shall store the received information associated with that group identity. If a PMK and PMK identity are included, the UE shall store these and delete any previously stored ones for this ProSe Key Management Function.

Key Response XML

POST ./servlet/syncit HTTP/1.1

Host: www.datasync.org

Content-Type: application/xml; charset="utf-8"

Content-Length: {content-length}

Accept: application/vnd.syncml-xml

 

<?xml version="1.0" encoding="utf-8" ?>

<prose-key-management-message>

    <KeyRsp-info>

        <transaction-ID>1</transaction-ID>

        <GroupNotSupported>

            <GroupId>0</GroupId>

            <Error-Code>0</Error-Code>

        </GroupNotSupported>

        <GroupResponse>

            <GroupId>0</GroupId>

            <GroupMemberID>0</GroupMemberID>

            <AlgorithmInfo>0f</AlgorithmInfo>

        </GroupResponse>

        <Key-info>

            <PMK-ID>0</PMK-ID>

            <PMK>65d9c191ae4377487427b28163dfaadf9c93b7abeae34f248d6c4616afd1670c</PMK>

        </Key-info>

    </KeyRsp-info>

</prose-key-management-message>

MIKEY Messages (3GPP TS 33.303 [35])

 

MIKEY is used to transport the PGKs from the ProSe Key Management Function to the UE.

MIKEY is used with pre-shared keys as described in RFC 3830 [13].

The PMK (1.1.2) shared by the ProSe Key Management Function and the UE will be used as the pre-shared secret.

The UDP port for MIKEY is 2269.

ProSe Key Management Function may use the initial MIKEY message (by setting the PGK_ ID to all zeros) to trigger a Key Request message from the UE.

Initial MIKEY Message (ProSe Key Management Function → UE)

Initial MIKEY Payload:

  • MIKEY common header: The CSB ID field of the MIKEY common header id shall be set to a random number.
    • If the ProSe Key Management Function requires an acknowledgement of the PGK delivery message, then, it sets the V-Bit to 1.
    • The #CS field shall be set to zero.
    • The CS ID map type subfield shall be set to "Empty map" as defined in RFC 4563 [35].
  • Timestamp payload: The timestamp field shall be of type 2 and contain the value of the replay counter that is associated with this message.
  • MIKEY-RAND field: The MIKEY-RAND field shall contain a 128-bit random number that is chosen by the ProSe Key Management Function.
  • IDi payload: The ID Type shall be set to the value 0 to indicate an NAI with the identity formed from the Group Identity || PGK ID @ FQDN of the ProSe Key Management Function.
  • IDr payload: The ID Type shall be set to the value 0 to indicate an NAI with the identity formed of the PMK identity of the PMK used to protect the MIKEY message @ the FQDN of the ProSe Key Management Function.
  • KEMAC Payload: The Type Subfield shall be set to value 2.
    • The use of the NULL algorithm in MAC field is not allowed.
    • The use of the NULL alg in the Encr field is not allowed.
    • The KV (Key Validity) subfield shall be set to the value 2.
    • The lower and upper limits of the validity period of the PGK are expressed in unit of seconds and coded in binary format as the 40 least significant bits of the Coordinated Universal Time as defined in 3GPP TS 36.331 [40].
    • In order to get the UE to delete a PGK, the ProSe Management Function shall set the lower and upper limits to be the same.

Process Initial MIKEY Message (UE)

When receiving the MIKEY message from ProSe Key Management Function, UE will process:

  • MIKEY common header
    • If V-bit is set to 1, ProSe Key Management Function expect MIKEY Verification Response Message
  • Timestamp payload
    • UE checked and compared against the stored Counter for the PMK, and the message is rejected if that counter is not larger then the current Counter.
    • UE will set the Counter to the new value of Timestamp payload
  • MIKEY-RAND field
  • IDi payload
    • UE will extract the Group ID and PGK ID. If PGK id is all zeros, the UE shall stop processing the message and send a Key Request message (6.3.2.2.3.3).
  • IDr payload
    • UE will extract PMK @ FQDN of the ProSe Key Management Function to establish which PMK was used to protect the MIKEY message
  • KEMAC payload
    • UE will extract the PGK and Key Validity data RFC 3830 [5]. If the lower and upper limits are the same, the the UE shall delete any key with the Group ID and PGK ID contained the MIKEY message. Otherwise the UE shall store the PGK along PGK ID and the validity limits.

MIKEY Verification Message (UE → ProSe Key Management Function)

  • MIKEY common header: The CSB ID field of the MIKEY common header id shall be set to a random number.
    • If the ProSe Key Management Function requires an acknowledgement of the PGK delivery message, then, it sets the V-Bit to 1.
    • The #CS field shall be set to zero.
    • The CS ID map type subfield shall be set to "Empty map" as defined in RFC 4563 [35].
  • Timestamp payload: The timestamp field shall be of type 2 and contain the value of the replay counter that is associated with this message.
  • IDr payload: The ID Type shall be set to the value 0 to indicate an NAI with the identity formed of the PMK identity of the PMK used to protect the MIKEY message @ the FQDN of the ProSe Key Management Function.
  • Verification payload: The use of the NULL algorithm in the MAC field is not allowed. The MAC included in the verification payload shall be calculated over both the initiator’s and the responder’s identities as well as the timestamp in addition to over the response message as defined in RFC 3830 [13].

 

ProSe Downloading/Updating PSDK (success, no auth)

Select ProSe Downloading/Updating PSDK (success, no auth).

 

Downloading/Updating PSDK - This is part of the key management procedures over PC8 interface as specified in TS 33.303 Sub-clause 6.6.3.

The following diagram is from TS 33.303.

Key Request/Response Transaction - See above section for PGK

Key Request

Key Request XML

<?xml version="1.0" encoding="utf-8" ?>

<prose-key-management-message>

    <KeyReq-info>

        <transaction-ID>1</transaction-ID>

        <AlgorithmAvailable>0f</AlgorithmAvailable>

        <GroupMemberDiscoveryKeyRequest>

            <DiscoveryGroupID>8888</DiscoveryGroupID>

            <PSDKId>0</PSDKId>

        </GroupMemberDiscoveryKeyRequest>

    </KeyReq-info>

</prose-key-management-message>

2.1.2. Key Response

Key Response XML

<?xml version="1.0" encoding="utf-8" ?>

<prose-key-management-message>

    <KeyRsp-info>

        <transaction-ID>1</transaction-ID>

        <GroupNotSupported>

            <GroupId>0</GroupId>

            <Error-Code>0</Error-Code>

        </GroupNotSupported>

        <GroupResponse>

            <GroupId>888</GroupId>

            <GroupMemberID>12345</GroupMemberID>

            <AlgorithmInfo>0f</AlgorithmInfo>

        </GroupResponse>

        <Key-info>

            <PMK-ID>8877665544332211</PMK-ID>

            <PMK>102a2062713681c5816cb70337778c9065db900a10d01376f62803379a785fe2</PMK>

        </Key-info>

    </KeyRsp-info>

</prose-key-management-message>

MIKEY Messages

Same as PGK Section listed above, except for :

  • IDi payload is formed from the Key Type ID || PSDK ID @ FQDN of the ProSe Key Management Function at the PKMF.
  • The UE recognizes that it is receiving a PSDK rather than PGK based on the Key Type ID in the IDi payload.
  • An all zero PSDK ID is used to trigger the UE to send a Key Request message.

ProSE MIKEY Transaction

Select for ProSE MIKEY Transaction.

See MIKEY Message Payload below.

Wait For Time

Halt a script for a specified amount of time.

 

XML Key Parameters

1. Transaction ID (<transaction-ID>)

This parameter is used to uniquely identify a ProSe Key management transaction. The UE shall set this parameter to a new number for each outgoing new discovery request. The transaction ID is an integer in the 0-255 range.

2. Supported Algorithm (<AlgorithmAvailable>).

This parameter is used to indicate which encryption algorithm the UE supports for one-to-many communications. It is a 1 octet long binary parameter encoded as shown:

EPS encryption algorithms supported (octet 1)

  • EPS encryption algorithm EEA0 supported (octet 1, bit 8)
    • 0 EPS encryption algorithm EEA0 not supported
    • 1 EPS encryption algorithm EEA0 supported
  • EPS encryption algorithm 128-EEA1 supported (octet 1, bit 7)
    • 0 EPS encryption algorithm 128-EEA1 not supported
    • 1 EPS encryption algorithm 128-EEA1 supported
  • EPS encryption algorithm 128-EEA2 supported (octet 1, bit 6)
    • 0 EPS encryption algorithm 128-EEA2 not supported
    • 1 EPS encryption algorithm 128-EEA2 supported
  • EPS encryption algorithm 128-EEA3 supported (octet 1, bit 5)
    • 0 EPS encryption algorithm 128-EEA3 not supported
    • 1 EPS encryption algorithm 128-EEA3 supported
  • EPS encryption algorithm EEA4 supported (octet 1, bit 4)
    • 0 EPS encryption algorithm EEA4 not supported
    • 1 EPS encryption algorithm EEA4 supported
  • EPS encryption algorithm EEA5 supported (octet 1, bit 3)
    • 0 EPS encryption algorithm EEA5 not supported
    • 1 EPS encryption algorithm EEA5 supported
  • EPS encryption algorithm EEA6 supported (octet 1, bit 2)
    • 0 EPS encryption algorithm EEA6 not supported
    • 1 EPS encryption algorithm EEA6 supported
  • EPS encryption algorithm EEA7 supported (octet 1, bit 1)
    • 0 EPS encryption algorithm EEA7 not supported
    • 1 EPS encryption algorithm EEA7 supported

3. Group ID (<GroupID>)

This parameter is used to indicate the Group that the UE is requesting keys for. It is an integer in the 0-167777215 range.

4. PGK ID (<PGKId>)

This parameter is used to indicate the PGK IDs for a particular group. It is an integer in the 0-255 range.

5. Error Code (<Error-Code>)

This parameter is used to indicate the particular reason why the UE will not be receiving keys for a requested group. It is an integer in the 0-255 range encoded as follows:

  • 0 Reserved
  • 1 UE does not support the required security algorithms for this one-to-many communication group or discovery (relay or group member).
  • 2 The ProSe Key Management Function does not supply keys for this one-to-many communication group or discovery (relay or group member).
  • 3 UE is not authorised to receive keys for this one-to-many communication group or discovery (relay or group member).
  • 4 UE requested to stop receiving PGKs for this group or PSDKs for this discovery (relay or group member).
  • 5 UE not authorised to receive PRUKs from this PKMF.
  • 6 PRUK ID or IMSI not recognized.
  • 7 UE-to-network relay not authorised to serve this UE.
  • 8-255 Unused

6. Group Member ID (<GroupMemberID>

This parameter is used as the identity of the UE within a Group. It is an integer in the 0-167777215 range.

7. Algorithm Info (<AlgorithmInfo>)

The purpose of the Algorithm info is to indicate the confidentiality algorithms to be used for ciphering protection of the particular group traffic. It is a binary parameter of length 1 octet that is encoded as shown in table E.5.2.2.7-1.

Type of ciphering algorithm (octet 1, bit 5 to 7)
Bits
7 6 5
0 0 0 EPS encryption algorithm EEA0 (null ciphering algorithm)
0 0 1 EPS encryption algorithm 128-EEA1
0 1 0 EPS encryption algorithm 128-EEA2
0 1 1 EPS encryption algorithm 128-EEA3
1 0 0 EPS encryption algorithm EEA4
1 0 1 EPS encryption algorithm EEA5
1 1 0 EPS encryption algorithm EEA6
1 1 1 EPS encryption algorithm EEA7
Bits 1- 4 and bit 8 of octet 1 are spare and shall be coded as zero.

8. PMK ID (<PMK-ID>)

This parameter is used to identify a PMK. It is an 8 octet long binary parameter.

9. PMK (<PMK>)

This parameter is a key that is used to protect MIKEY messages. It is a 32 octet long binary parameter.

10. Discovery Group ID (<DiscoveryGroupID>)

This parameter is used to indicate the Discovery Group ID for which the UE is requesting keys. It is a 24-bit long string.

11. Relay Service Code (<RelayServiceCode>)

This parameter is used to indicate the Relay Service Code for which the UE is requesting keys. It is a 24-bit long string.

12. PSDK ID (<PSDKId>)

This parameter is used to indicate the PSDK IDs for a particular Relay Service Code or Discovery Group ID. It is an integer in the 0-255 range.

13. PGK

A 256-bit binary number.

14. PSDK

A 256-bit binary number.

 

 

MIKEY Message Payload

Payload Encoding

1.1. Overall

 

    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
		
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		
   !  version      !  data type    ! next payload  !               !
		
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...            +
		
   ~                   Common Header...                            ~
		
   !                                                               !
		
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		
   ! next payload  !   Payload 1 ...                               !
		
   +-+-+-+-+-+-+-+-+                                               +
		
   ~                                                               ~
		
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		
   :                             :                                 :
		
   :                             :                                 :
		
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		
   ! next payload  !   Payload x ...                               !
		
   +-+-+-+-+-+-+-+-+                                               +
		
   ~                                                               ~
		
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		
   !                   MAC/Signature                               ~
		
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		
 
   MIKEY payload message example.  Note that the payloads
		
   are byte aligned and not 32-bit aligned.

1.2. Common Header Payload (HDR)

                        1                   2                   3
		
    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
		
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		
   !  version      !  data type    ! next payload  !V! PRF func    !
		
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		
   !                         CSB ID                                !
		
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		
   ! #CS           ! CS ID map type! CS ID map info                ~
		
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		
 
   *  version (8 bits): the version number of MIKEY.
		
 
      version = 0x01 refers to MIKEY as defined in this document.
		
 
   *  data type (8 bits): describes the type of message (e.g., public-
		
      key transport message, verification message, error message)
		
      Data type     | Value | Comment
		
      --------------------------------------
		
      Pre-shared    |     0 | Initiator's pre-shared key message
		
      PSK ver msg   |     1 | Verification message of a Pre-shared
		
                    |       | key message
		
      Public key    |     2 | Initiator's public-key transport message
		
      PK ver msg    |     3 | Verification message of a public-key
		
                    |       | message
		
      D-H init      |     4 | Initiator's DH exchange message
		
      D-H resp      |     5 | Responder's DH exchange message
		
      Error         |     6 | Error message
		
 
      Table 6.1.a
		
 
   *  next payload (8 bits): identifies the payload that is added after
		
      this payload.
		
 
      Next payload  | Value | Section
		
      ------------------------------
		
      Last payload  |     0 | -
		
      KEMAC         |     1 | 6.2
		
      PKE           |     2 | 6.3
		
      DH            |     3 | 6.4
		
      SIGN          |     4 | 6.5
		
      T             |     5 | 6.6
		
      ID            |     6 | 6.7
		
      CERT          |     7 | 6.7
		
      CHASH         |     8 | 6.8
		
      V             |     9 | 6.9
		
      SP            |    10 | 6.10
		
      RAND          |    11 | 6.11
		
      ERR           |    12 | 6.12
		
      Key data      |    20 | 6.13
		
      General Ext.  |    21 | 6.15
		
 
      Table 6.1.b
		
 
      Note that some of the payloads cannot directly follow the header
		
      (such as "Last payload", "Signature").  However, the Next payload
		
      field is generic for all payloads.  Therefore, a value is
		
      allocated for each payload.  The Next payload field is set to zero
		
      (Last payload) if the current payload is the last payload.
		
 
   *  V (1 bit): flag to indicate whether a verification message is
		
      expected or not (this only has meaning when it is set by the
		
      Initiator).  The V flag SHALL be ignored by the receiver in the DH
		
      method (as the response is MANDATORY).
		
      V = 0  ==> no response expected
		
      V = 1  ==> response expected
		
 
   *  PRF func (7 bits): indicates the PRF function that has been/will
		
      be used for key derivation.
		
 
      PRF func      | Value | Comments
		
      --------------------------------------------------------
		
      MIKEY-1       |     0 | Mandatory (see Section 4.1.2)
		
 
      Table 6.1.c
		
 
   *  CSB ID (32 bits): identifies the CSB.  It is RECOMMENDED that the
		
      CSB ID be chosen at random by the Initiator.  This ID MUST be
		
      unique between each Initiator-Responder pair, i.e., not globally
		
      unique.  An Initiator MUST check for collisions when choosing the
		
      ID (if the Initiator already has one or more established CSBs with
		
      the Responder).  The Responder uses the same CSB ID in the
		
      response.
		
 
   *  #CS (8 bits): indicates the number of Crypto Sessions that will be
		
      handled within the CBS.  Note that even though it is possible to
		
      use 255 CSs, it is not likely that a CSB will include this many
		
      CSs.  The integer 0 is interpreted as no CS included.  This may be
		
      the case in an initial setup message.
		
 
   *  CS ID map type (8 bits): specifies the method of uniquely mapping
		
      Crypto Sessions to the security protocol sessions.
		
 
      CS ID map type | Value
		
      -----------------------
		
      SRTP-ID        |     0
		
 
      Table 6.1.d
		
 
   *  CS ID map info (16 bits): identifies the crypto session(s) for
		
      which the SA should be created.  The currently defined map type is
		
      the SRTP-ID (defined in Section 6.1.1).

1.3. Timestamp Payload (T)

The timestamp payload carries the timestamp information.
 
                        1                   2                   3
		
    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  !   TS type     ! TS value                      ~
		
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		
 
   *  Next payload (8 bits): identifies the payload that is added after
		
      this payload.  See Section 6.1 for values.
		
 
   *  TS type (8 bits): specifies the timestamp type used.
		
      TS type       | Value | Comments     | length of TS value
		
      -------------------------------------|-------------------
		
      NTP-UTC       |     0 | Mandatory    |   64-bits
		
      NTP           |     1 | Mandatory    |   64-bits
		
      COUNTER       |     2 | Optional     |   32-bits
		
 
      Table 6.6
		
 
      Note: COUNTER SHALL be padded (with leading zeros) to a 64-bit
		
      value when used as input for the default PRF.
		
 
   *  TS-value (variable length): The timestamp value of the specified
		
      TS type

1.4. RAND

   The RAND payload consists of a (pseudo-)random bit-string.  The RAND
		
   MUST be independently generated per CSB (note that if the CSB has
		
   several members, the Initiator MUST use the same RAND for all the
		
   members).  For randomness recommendations for security, see [RAND].
		
 
                        1                   2                   3
		
    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  ! RAND len      ! RAND                          ~
		
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		
 
   *  Next payload (8 bits): identifies the payload that is added after
		
      this payload.  See Section 6.1 for values.
		
 
   *  RAND len (8 bits): length of the RAND (in bytes).  It SHOULD be at
		
      least 16.
		
 
   *  RAND (variable length): a (pseudo-)randomly chosen bit-string.

1.5. IDi /IDr

Note that the ID payload and the Certificate payload are two
   completely different payloads (having different payload identifiers).
		
   However, as they share the same payload structure, they are described
		
   in the same section.
		
 
   The ID payload carries a uniquely defined identifier.
		
 
   The certificate payload contains an indicator of the certificate
		
   provided as well as the certificate data.  If a certificate chain is
		
   to be provided, each certificate in the chain should be included in a
		
   separate CERT payload.
		
 
                        1                   2                   3
		
    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 ! ID/Cert Type  ! ID/Cert len                   !
		
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		
   !                       ID/Certificate Data                     ~
		
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		
 
   *  Next payload (8 bits): identifies the payload that is added after
		
      this payload.  See Section 6.1 for values.
		
 
   If the payload is an ID payload, the following values apply for the
		
   ID type field:
		
 
   *  ID Type (8 bits): specifies the identifier type used.
		
      ID Type       | Value | Comments
		
      ----------------------------------------------
		
      NAI           |     0 | Mandatory (see [NAI])
		
      URI           |     1 | Mandatory (see [URI])
		
 
      Table 6.7.a
		
 
   If the payload is a Certificate payload, the following values applies
		
   for the Cert type field:
		
 
   *  Cert Type (8 bits): specifies the certificate type used.
		
 
     Cert Type     | Value | Comments
		
     ----------------------------------------------
		
     X.509v3       |     0 | Mandatory
		
     X.509v3 URL   |     1 | plain ASCII URL to the location of the Cert
		
     X.509v3 Sign  |     2 | Mandatory (used for signatures only)
		
     X.509v3 Encr  |     3 | Mandatory (used for encryption only)
		
 
     Table 6.7.b
		
 
   *  ID/Cert len (16 bits): the length of the ID or Certificate field
		
      (in bytes).
		
 
   *  ID/Certificate (variable length): The ID or Certificate data.  The
		
      X.509 [X.509] certificates are included as a bytes string using
		
      DER encoding as specified in X.509.

1.6. KEYMAC

The Key data transport payload contains encrypted Key data sub-
   payloads (see Section 6.13 for the definition of the Key data sub-
		
   payload).  It may contain one or more Key data payloads, each
		
   including, for example, a TGK.  The last Key data payload has its
		
   Next payload field set to Last payload.  For an update message (see
		
   also Section 4.5), it is allowed to skip the Key data sub-payloads
		
   (which will result in the Encr data len being equal to 0).
		
 
   Note that the MAC coverage depends on the method used, i.e., pre-
		
   shared vs public key, see below.
		
 
   If the transport method used is the pre-shared key method, this Key
		
   data transport payload is the last payload in the message (note that
		
   the Next payload field is set to Last payload).  The MAC is then
		
   calculated over the entire MIKEY message following the directives in
		
   Section 5.2.
		
 
   If the transport method used is the public-key method, the
		
   Initiator's identity is added in the encrypted data.  This is done by
		
   adding the ID payload as the first payload, which is then followed by
		
   the Key data sub-payloads.  Note that for an update message, the ID
		
   is still sent encrypted to the Responder (this is to avoid certain
		
   re-direction attacks) even though no Key data sub-payload is added
		
   after.
		
 
   In the public-key case, the coverage of the MAC field is over the Key
		
   data transport payload only, instead of the complete MIKEY message,
		
   as in the pre-shared case.  The MAC is therefore calculated over the
		
   Key data transport payload, except for the MAC field and where the
		
   Next payload field has been set to zero (see also Section 5.2).
		
 
                        1                   2                   3
		
    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  ! Encr alg      ! Encr data len                 !
		
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		
   !                        Encr data                              ~
		
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		
   ! Mac alg       !        MAC                                    ~
		
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		
 
   *  Next payload (8 bits): identifies the payload that is added after
		
      this payload.  See Section 6.1 for defined values.
		
 
   *  Encr alg (8 bits): the encryption algorithm used to encrypt the
		
      Encr data field.
		
      Encr alg      | Value | Comment
		
      -------------------------------------------
		
      NULL          |     0 | Very restricted usage, see Section 4.2.3!
		
      AES-CM-128    |     1 | Mandatory; AES-CM using a 128-bit key, see
		
                               Section 4.2.3)
		
      AES-KW-128    |     2 | AES Key Wrap using a 128-bit key, see
		
                               Section 4.2.3
		
 
      Table 6.2.a
		
 
   *  Encr data len (16 bits): length of Encr data (in bytes).
		
 
   *  Encr data (variable length): the encrypted key sub-payloads (see
		
      Section 6.13).
		
 
   *  MAC alg (8 bits): specifies the authentication algorithm used.
		
 
      MAC alg        | Value | Comments          | Length (bits)
		
      ----------------------------------------------------------
		
      NULL           |     0 | restricted usage  | 0
		
                     |       | Section 4.2.4     |
		
      HMAC-SHA-1-160 |     1 | Mandatory,        | 160
		
                     |       | Section 4.2.4     |
		
 
      Table 6.2.b
		
 
   *  MAC (variable length): the message authentication code of the
		
      entire message.

1.7. Verification Message Payload (V)

   The Ver msg payload contains the calculated verification message in
		
   the pre-shared key and the public-key transport methods.  Note that
		
   the MAC is calculated over the entire MIKEY message, as well as the
		
   IDs and Timestamp (see also Section 5.2).
		
 
                        1                   2                   3
		
    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  ! Auth alg      ! Ver data                      ~
		
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		
 
   *  Next payload (8 bits): identifies the payload that is added after
		
      this payload.  See Section 6.1 for values.
		
 
   *  Auth alg (8 bits): specifies the MAC algorithm used for the
		
      verification message.  See Section 6.2 for defined values.
		
 
   *  Ver data (variable length): the verification message data.  The
		
      length is implicit from the authentication algorithm used

 

^ Back to Top

 

© 2024 Spirent Communications Inc. All Rights Reserved.