5 General Description

5.1 MAF Interface

5.1.1 Introduction

The MAF Interface is a simple variant of the Mcc/Mca reference points specifying the interaction of MAF Clients with an M2M Authentication Function (MAF), acting on behalf of an administrating stakeholder such as an M2M SP or third party M2M Trust Enabler (MTE). The present document does not specify the operation and management of the MAF required to support these procedures.

A MAF Client interacts with the MAF on behalf of a Node (ADN, ASN, IN or MN), or a CSE or an AE.

Figure 5.1.1‑1 defines the reference point Mmaf between MAF clients and a MAF.

Figure 5.1.1‑1: Reference Architecture for MAF

The administrating stakeholder authorizes the MAF's services to MAF clients, and oversees authorizing the distribution of symmetric keys. A MAF may provide its services on behalf of multiple administrating stakeholders. A MAF Client may be associated with multiple administrating stakeholders, each administrating the use of the MAF within a different scope.

NOTE 1: The administrating stakeholder could be an M2M SP administrating the registration and distribution of credentials used for SAEFs and ESPrim within the M2M SP's Domain.

NOTE 2: The administrating stakeholder could be an MTE administrating the registration and distribution of credentials for ESPrim and ESData to MAF Clients belonging to a particular Application Service Provider, where the MAF Clients could be distributed over multiple M2M SP domains.

The present document has no impact on the specifications in oneM2M TS-0001 [1] and oneM2M TS-0004 [3]. However, the MAF Interface uses much of the specification in oneM2M TS-0004 [3] and in particular allows use of the HTTP binding in oneM2M TS-0008 [4], the CoAP binding in oneM2M TS-0009 [5] and the WebSocket binding in oneM2M TS0020 [8].

NOTE 3: The MQTT binding in oneM2M TS-0010 [6] is not suitable for the MAF Interface, because the MAF Interface assumes a TLS or DTLS connection from the MAF Client to the MAF - which is not possible using the MQTT binding.

The MAF Interface incorporates the following concepts from the Mcc/Mca reference points:

• The concept of operations acting on resources.
• The resource addressing from Mcc/Mca is used.
• The universal attributes and some common attributes of resources.

The MAF Interface differs from Mcc/Mca in the following ways:

• The MAF Client can only communicate directly with the MAF - there are no transited CSEs. Only Blocking Mode communication method is supported.
• None of the resource types applicable on Mcc/Mca are used:
  • Access control decisions use simple access control list for Retrieve access, and <accessControlPolicy> resources are not used for resources hosted by the MAF. A consequence of this is that the accessControlPolicyIDs attributes are not needed in the resources hosted by the MAF.
  • The <subscription> resource and NOTIFY operations are not supported.
  • There is no AE registration or CSE registration, but a similar process where a MAF Client creates a (MAF Client registration record) resource on the MAF.
  • There are no announced resources.

The hierarchy of resources hosted by a MAF shall be as follows:

• resource type is the structural root for all the resources that are residing on a MAF. This resource is implicitly created by the MAF and uses the fixed resource name "maf" and contains following child resources:
  • resource. It confirms the MAF Client's registration to an administrating stakeholder, and can contain configuration information to be returned to the MAF Client.
  • resources. It is created by the MAF Client, and contains symmetric keys for retrieval by another MAF Client.

5.1.2 MAF Interface Overview

This MAF Interface overview is based on the specification in clause 6 of oneM2M TS-0004 [3].

Identifiers such as M2M-SP-ID, AE-ID and CSE-ID as defined in 6.2.3 of [3] also apply to the MAF Interface. M2M Trust Enablers (MTEs) are identified using an M2M-SP-ID.

Resources are addressed as specified in clause 6.2.4 in [3].

Common data types applicable to the MAF Interface are inherited from clause 6.3 of [3]. However, for any parameters or elements which have assigned the enumerated data type m2m:resourceType, the applicable enumeration values are interpreted as specified in Table 5.1.2‑4. This applies to the Resource Type primitive parameter, the common resourceType attribute, and the _@type_ attribute of m2m:childResourceRef.

Tables 5.1.2‑1 and 5.1.2-2 list the request and response primitive parameters inherited from clauses6.4.1 and 6.4.2 in [3], respectively; the data types of these parameters are unchanged. The From parameter shall include the MAF client ID which can be a Node-ID, AE-ID or CSE-ID, depending on whether the client acts on behalf of a node, AE or CSE. Note that this is in contrast to primitives on the Mca and Mcc interface, where the From primitive parameter cannot include a Node-ID.

NOTE: All other optional request and response primitive parameters defined in clause 6.4.1 of [3] are not used on the MAF Interface.

Table 5.1.2‑1: MAF Interface request primitive parameters

Table 5.1.2‑2: MAF Interface response primitive parameters

Data types associated with resources applicable to the MAF Interface are defined in clause 7.

Table 5.1.2‑3 lists the response status codes from clause 6.6 of [3] which are supported by the MAF Interface.

Table 5.1.2‑3: Response status codes supported by the MAF Interface

Table 5.1.2‑4: Interpretation of enumeration values of m2m:resourceType

The MIME media types defined on clause 6.7 of [3] shall be supported on the MAF interface. The notification related Media types vnd.onem2m-ntfy+json, vnd.onem2m-ntfy+cbor, vnd.onem2m-ntfy+xml do not apply to the MAF interface.

Virtual resources (clause 6.8 of [3]) are not supported by the MAF Interface.

5.2 MEF Interface

5.2.1 Introduction

The M2M Enrolment Function (MEF) is an essential part of the oneM2M Remote Security Provisioning architecture.

Clause 6.1.2.1 of oneM2M TS-0003 [2] defines the following three variants of Remote Security Provisioning Framework (RSPF):

• Pre-Provisioned Symmetric Key RSPF,
• Certificate-Based RSPF,
• GBA-based RSPF.

The MEF interface defined in the present specification applies to Pre-Provisioned Symmetric Key RSPF and Certificate-Based RSPF only. For interfaces and procedures applicable to GBA-based RSPF, see clause 8.3.2.3 of oneM2M TS-0003 [2].

When using Pre-Provisioned Symmetric Enrolee Key RSPF or Certificate-Based RSPF, the MEF serves a number of different use cases which are summarized as follows:

1. The MEF provisions an Enrolee to perform MAF Security Framework procedures with a MAF as defined in clause 8.8.2 of oneM2M TS-0003 [2].
2. The MEF provisions an Entity A and an Entity B to perform Security Association Establishment as defined in clauses8.2.2.1 and 8.2.2.2 of oneM2M TS-0003 [2].
3. The MEF provisions an originator and a receiver of a primitive with credentials to enable End-to-End Security of Primitives (ESPRIM) with security credentials as specified in clause 8.4 of oneM2M TS-0003 [2].
4. The MEF provisions the source and target endpoints of End-to-End Security of Data (ESDATA) as specified in clause 8.5 of oneM2M TS-0003 [2].

The present document defines messages and procedures for the above listed MEF use cases.

NOTE 1: A MEF may also be implemented as a Device Management server using device management protocols such as OMA DM, OMA LwM2M and BBF TR-069. Such procedures are defined in oneM2M TS0003 [2] and oneM2M TS-0022 [9].

Like the Mmaf Interface, the Mmef Interface is a simple variant of the Mcc/Mca reference points specifying the interaction of MEF Clients with an M2M Enrolment Function (MEF), managing symmetric keys on behalf of an administrating stakeholder such as an M2M SP or third party M2M Trust Enabler (MTE). The present document does not specify the operation and management of the MEF required to support these procedures.

A MEF Client interacts with the MEF on behalf of a Node (ADN, ASN, IN or MN), or a CSE or an AE for use case 1 and 2 in the above list. Figure 5.2.1‑1 defines the reference point Mmef between MEF clients and a MEF, and between MEF and MAF.

Figure 5.2.1‑1: Reference Architecture for MEF

The administrating stakeholder authorizes the MEF's services to MEF clients. A MEF may provide its services on behalf of multiple administrating stakeholders. A MEF Client may be associated with multiple administrating stakeholders, each administrating the use of the MEF within a different scope.

NOTE 2: The administrating stakeholder could be an M2M SP administrating the registration and distribution of credentials used for SAEFs and ESPrim within the M2M SP's Domain.

NOTE 3: The administrating stakeholder could be an MTE administrating the registration and distribution of credentials for ESPrim and ESData to MEF Clients belonging to a particular Application Service Provider, where the MEF Clients could be distributed over multiple M2M SP domains.

The present document has no impact on the specifications in oneM2M TS-0001 [1] and oneM2M TS-0004 [3]. However, the MEF Interface uses much of the specification in oneM2M TS-0004 [3] and in particular allows use of the HTTP binding in oneM2M TS-0008 [4], the CoAP binding in oneM2M TS-0009 [5] and the WebSocket binding in oneM2M TS-0020 [8].

NOTE 4: The MQTT binding in oneM2M TS-0010 [6] is not suitable for the MEF Interface, because the MEF Interface assumes a TLS or DTLS connection from the MEF Client to the MEF - which is not possible using the MQTT binding

The MEF Interface incorporates the following concepts from the Mcc/Mca reference points:

1. The concept of operations acting on resources.
2. The resource addressing from Mcc/Mca is used.
3. The universal attributes and some common attributes of resources.

The MEF Interface differs from Mcc/Mca in the following ways:

4. The MEF Client can only communicate directly with the MEF - there are no transited CSEs. Only Blocking Mode communication method is supported.
5. None of the resource types applicable on Mcc/Mca are used:
   • Access control decisions use simple access control list for Retrieve access, and <accessControlPolicy> resources are not used for resources hosted by the MEF. A consequence of this is that the accessControlPolicyIDs attributes are not needed in the resources hosted by the MEF.
   • The <subscription> resource and NOTIFY operations are not supported.
   • There is no AE registration or CSE registration, but a similar process where a MEF Client creates a (MEF Client registration record) resource on the MEF.
   • There are no announced resources.

The hierarchy of resources hosted by a MEF shall be as follows:

6. resource type is the structural root for all the resources that are residing on a MEF. This resource is implicitly created by the MEF and uses the fixed resource name "mef" and contains following child resources:
   • resource. It confirms the MEF Client's registration to an administrating stakeholder, and can contain configuration information to be returned to the MEF Client.
   • resources. It is created by the MEF Client, and contains symmetric keys for retrieval by another MEF Client.

5.2.2 MEF Interface Overview

This MEF Interface overview is based on the specification in clause 6 of oneM2M TS-0004 [3].

Identifiers such as M2M-SP-ID, AE-ID and CSE-ID as defined in 6.2.3 of [3] also apply to the MEF Interface. M2M Trust Enablers (MTEs) are identified using an M2M-SP-ID.

Resources are addressed as specified in clause 6.2.4 in [3].

Common data types applicable to the MEF Interface are inherited from clause 6.3 of [3]. However, for any parameters or elements which have assigned the enumerated data type m2m:resourceType, the applicable enumeration values are interpreted as specified in Table 5.1.2‑4. This applies to the Resource Type primitive parameter, the common resourceType attribute, and the _@type_ attribute of m2m:childResourceRef.

Tables 5.2.2‑1 and 5.2.2-2 list the request and response primitive parameters inherited from clauses6.4.1 and 6.4.2 in [3], respectively; the data types of these parameters are unchanged. The From parameter shall include the MEF client ID which can be a Node-ID, AE-ID or CSE-ID, depending on whether the client acts on behalf of a node, AE or CSE. Note that this is in contrast to primitives on the Mca and Mcc interface, where the From primitive parameter cannot include a Node-ID.

NOTE: All other optional request and response primitive parameters defined in clause 6.4.1 of [3] are not used on the MEF Interface.

Table 5.2.2‑1: MEF Interface request primitive parameters

Table 5.2.2‑2: MEF Interface response primitive parameters

Data types associated with resources applicable to the MEF Interface are defined in clause 7.

The response status codes listed in table 5.1.2‑3 also apply to the MEF Interface.

The MIME media types defined on clause 6.7 of [3] shall be supported on the MEF interface. The notification related Media types vnd.onem2m-ntfy+json, vnd.onem2m-ntfy+cbor, vnd.onem2m-preq+xml do not apply to the MEF interface.

Virtual resources (clause 6.8 of [3]) are not supported by the MEF Interface.