Skip to content

8.5 Resource Type <_symmKeyReg_>

8.5.1 Introduction

A <symmKeyReg> resource shall represent a symmetric key registered with a MAF or MEF and administrated by the identified administrating stakeholder. A <symmKeyReg> resource shall be a child resource of a <MAFBase> or a <MEFBase> resource.

Table 8.5.1-1: Data Type Definition of <symmKeyReg>

Data Type ID File Name Note
symmKeyReg SEC-symmKeyReg-v2_1_0.xsd

Table 8.5.1-2: Universal/Common Attributes of <symmKeyReg> resource

Attribute Name

Request Optionality

Create

Update

@resourceName

NP

NP

resourceType

NP

NP

resourceID

NP

NP

parentID

NP

NP

creationTime

NP

NP

labels

O

O

creator

NP

NP

expirationTime

M

M

Table 8.5.1-3: Resource Specific Attributes of <symmKeyReg> resource

Attribute Name

Request Optionality

Data Type

Default Value and Constraints

Create

Update

adminFQDN

M

NP

xs:anyURI

No default

SUID

M

NP

m2m:suid

No default

targetIDs

O

O

m2m:listOfM2MID

No default

keyValue

O

NP

xs:hexBinary

No default

The <symmKeyReg> resource shall contain no child resources.

8.5.2 <symmKeyReg> resource specific procedures on CRUD operations

8.5.2.1 Create

This procedure is denoted MAF Key Registration in clause 8.8.2.7 of oneM2M TS-0003 [2] and MEF Key Registration in clause 8.3.5.2.7 of oneM2M TS-0003. This procedure enables a Source MAF Client or a Source MEF Client to establish a symmetric key with the MAF or MEF, respectively, which can be retrieved for use by one or more Target MAF Clients or Target MEF Clients.

Originator:

No change from the generic procedures in clause 7.2.2.1 of [3] with clarifications discussed in clauses 5.1.2 and 6.2 for Mmaf and in clauses 5.2.2 and 6.3 for Mmef, respectively, and with following differences:

In step Orig-1.0: "Compose of a Request primitive", the:

  1. Originator shall select to either use a key derived from the TLS handshake or use another key provided by the Originator:
    • a) If the Originator selects to use a key derived from the TLS handshake, then the Originator shall not include the keyValue attribute in the <symmKeyReg> resource of the request.
    • b) If the Originator selects to provide a key other than a key derived from the TLS handshake, the Originator shall include the value of this key in the keyValue attribute in the <symmKeyReg> resource of the request.

In step Orig-6.0: "Process Response primitive", the following steps shall be performed:

  1. If the Originator selected to use a key derived from the TLS handshake (see difference to step Orig-1.0 above), then the Originator shall perform the following steps in order to generate the value for the keyValue attribute:
    • a) The Originator shall apply the TLS export mechanism described in clause 10.3.1 of [2] to generate a TLS-export-key. For MAF Key Registration the "TLS Key Export Details for M2M Secure Connection Key", for MEF Key Registration the "TLS Key Export Details for Enrolment Key" apply, respectively.
    • b) The Originator shall apply the usage-constrained key derivation algorithm in clause 10.3.7 of [2] to derive the keyValue from TLS-export-key, adminFQDN, SUID and the resourceName assigned by the Receiver to the created resource.
  2. The originator shall record the resourceName attribute of the created resource as the relative part of the key identifier for the symmetric key which is to be assigned to the value for the keyValue attribute.

Receiver:

Same as the generic procedures in clause 7.2.2.2 of [3] with clarifications discussed in clauses 5.2 and 6, and with following differences:

The Receiver shall perform the following steps in order in the place of Recv-6.3: "Check authorization of the Originator":

  1. The Receiver shall ensure that the following criteria are satisfied, with administrating stakeholder being the stakeholder matching the adminFQDN attribute of the <symmKeyReg> resource in the Create request:
    • a) The Originator is enrolled with the administrating stakeholder; that is, there is a non-expired <mafClientReg> resource whose creator attribute matches the Originator's AE-ID or CSE-ID or Node-ID, and whose adminFQDN attribute identifies the administrating stakeholder.
    • b) The Receiver determines that the administrating stakeholder allows the creation of the resource. The present document does not specify how the Receiver makes this determination.
  2. If these criteria are not met, then the Receiver shall execute the following steps in order:

    • a) "Create an unsuccessful Response primitive" with the Response Status Code indicating "ACCESS_DENIED" error.
    • b) "Send the Response primitive".
  3. Otherwise, then the Receiver shall allow the request.

The Receiver shall perform the following steps in order as part of "Create the resource" (clause 7.3.3.5 of [3] )" during Step Recv-6.5: "Create/Update/Retrieve/Delete/Notify operation is performed":

  1. If the keyValue attribute is not present in the <symmKeyReg> resource in the request, then the Receiver shall perform the following step to generate the value for the keyValue attribute:
    • a) The Receiver shall apply the TLS export mechanism described in clause 10.3.1 of [2] to generate a TLS-export-key.
    • b) The Receiver shall apply the usage-constrained key derivation algorithm in clause 10.3.7 of [2] to derive the value for the keyValue attribute from TLS-export-key, adminFQDN, SUID and the resourceName assigned by the Receiver to the created resource.

8.5.2.2 Retrieve

This procedure is denoted MAF Key Retrieval in clause 8.8.2.8 of oneM2M TS-0003 [2] and MEF Key Retrieval in clause 8.3.5.2.8 of oneM2M TS-0003. It enables a Target MAF Client to retrieve the Key Value from a MAF corresponding to a RelativeKeyID available to the Target MAF Client.

Originator:

No change from the generic procedures in clause 7.2.2.1 of [3] with clarifications discussed in clauses 5.1.2 and 6.2 for Mmaf and in clauses 5.2.2 and 6.3 for Mmef, respectively.

Receiver:

Same as the generic procedures in clause 7.2.2.2 of [3] with clarifications discussed in clauses 5.2 and 6, and with following differences:

The Receiver shall perform the following step in the place of Recv-6.3: "Check authorization of the Originator":

  1. The Receiver shall determine if the Originator is authorized by checking if the Originator is the creator of the resource or the Originator is identified in the targetIDs :
    • a) If the Originator is not authorized, then the Receiver shall execute the following steps in order:
      • i) "Create an unsuccessful Response primitive" with the Response Status Code indicating "ACCESS_DENIED" error.
      • ii) "Send the Response primitive".
    • b) If the Originator is authorized, then the Receiver shall allow the request.

8.5.2.3 Update

This procedure is denoted MAF Key Registration Update in clause 8.8.2.9 of oneM2M TS-0003 [2] and MEF Key Registration Update in clause 8.3.5.2.9 of oneM2M TS-0003. It enables a Source MAF Client or Source MEF Client to update the metadata associated with a registered key.

Originator:

No change from the generic procedures in clause 7.2.2.1 of [3] with clarifications discussed in clauses 5.1.2 and 6.2 for Mmaf and in clauses 5.2.2 and 6.3 for Mmef, respectively.

Receiver:

Same as the generic procedures in clause 7.2.2.2 of [3] with clarifications discussed in clauses 5.2 and 6, and performing the following step in the place of Recv-6.3: "Check authorization of the Originator":

  1. The Receiver shall determine if the Originator is authorized by checking if the Originator is the creator of the resource:
    • a) If the Originator is not authorized, then the Receiver shall execute the following steps in order:
      • i) "Create an unsuccessful Response primitive" with the Response Status Code indicating "ACCESS_DENIED" error.
      • ii) "Send the Response primitive".
    • b) If the Originator is authorized, then the Receiver shall allow the request.

8.5.2.4 Delete

This procedure is denoted MAF Key De-Registration in clause 8.8.2.10 of oneM2M TS-0003 [2] and MEF Key De-Registration in clause 8.3.5.2.10 of oneM2M TS-0003. It enables a Source MAF Client to request the MAF to stop distributing the registered key.

Originator:

No change from the generic procedures in clause 7.2.2.1 of [3] with clarifications discussed in clause 5.1.2 and 6.2 for Mmaf and in clauses 5.2.2 and 6.3 for Mmef, respectively.

Receiver:

Same as the generic procedures in clause 7.2.2.2 of [3] with clarifications discussed in clauses 5.2 and 6, and performing the following step in the place of Recv-6.3: "Check authorization of the Originator":

  1. The Receiver shall determine if the Originator is authorized by checking if the Originator is the creator of the resource:
    • a) If the Originator is not authorized, then the Receiver shall execute the following steps in order:
      • i) "Create an unsuccessful Response primitive" with the Response Status Code indicating "ACCESS_DENIED" error.
      • ii) "Send the Response primitive".
    • b) If the Originator is authorized, then the Receiver shall allow the request.