On-Boarding and Enrolment Group Name: SEC WG Source: Qualcomm Inc., Phil Hawkes, Wolfgang Granzow, Josef Blanz Meeting Date: SEC#22, Agenda Item: End-to-End Security and Group Authentication

History R01 – Renamed “SP” with “M2M Trust Enabler” (MTE) – Added “Enrolee DB” – Added slide on “Proof of control” – Collapsed OBD and OBS to “OBF” for most of description – Now only 3 flows: no OBF, untrusted OBF, trusted OBF – Clarified purpose of enrolment token – Added server-auth TLS between Enrolee and MEF in untrusted case: Used to provide Enrolment Token and negotiate RSPF – Added slides commenting on untrusted OBF flow and trusted OBF flow. 2

Background Rel 2 security is more complex than Rel 1 Can involve more stakeholder interactions than just M2M-MTE-to-M2M-Service-Subscriber. – Various 3 rd party M2M Trust Enablers (MTE), independent of the M2M SP, might facilitate functionality needed for ESPrim, ESData, Dynamic Authorization, etc. 3 Feature classRelease 1Release 2 Communication Security*SAEFs ESPrim ESData AuthorizationRelease 1 ACPs Roles Dynamic Authorization Distributed Authorization

Ownership transfer problem Problem – To facilitate transfer of ownership, factory reset should typically result in removal of SAEF, ESPrim and ESData credentials. High Level Implication – Device certs and hard-coded secret keys should not be used directly in SAEF, ESPrim and ESData Solution/Options – Fresh SAEF, ESPrim and ESData credentials should typically be provisioned. – The M2M SP might not be the appropriate entity for provisioning E2E credentials (e.g. operating MEF) or managing authentication (e.g. operating MAF/TEF). Examples E2E between entities in distinct domains Liability issues – M2M SP might want no responsibility for smart meter data or health data – For now, we use “MTE” to refer to any stakeholder managing credentials on behalf of the subscribers etc. 4

MTE Model Internal operation of MTE does not need specifications. We model the MTE using the following functions, for explanation purposes. We expect to define some APIs,: MTE Enrolment Portal (Proprietary) – Web portal allowing Enrolling Stakeholders (e.g. subscribers) to request enrolment of Enrollees MTE Enrollee Database (Proprietary) – Where the MTE records information about which entities are enrolled with the MTE. MTE MEF (Optional) – Provided by, or on behalf of, MTE, for provisioning credentials to Enrollees MTE MAF (Optional) – Provides centralized authentication during the operation phase of a CSE/AE’s lifecycle. Stores provisioned credentials for authenticating Enrollees. 5

Clarifying Enrolment The Enrolment Phase achieves two outcomes A.Adding the Enrolee to the MTE’s Enrolee Database Defined on next slide B.Remote security provisioning: Issuing a MTE-specific credential for authenticating the Enrollee within set of entities served by that MTE either symmetric key or certificate (see SEC R02) C.(New?) Verifying that the Enrolling Stakeholder is in “control” of the Enrollee; could include Manufacturer, OEM, distributor, retailer M2M Service Subscriber (M2M SS) M2M SP who will later sell/lease the Enrollee to the M2M SS. Application Service Provider, or other 3 rd Party who will later on- sell/lease the entity to the M2M SS 6

MTE can verify “proof of control” Recall: Enrolment includes – Associating the Enrollee with the stakeholder in “control” of the entity In this case, Enrolling stakeholder provides “proof of control” directly to MTE Enrolment Portal via app/portal (Proof of control is discussed on the next slide). Enrolling stakeholder provides Enrolee Info for MTE’s Enrolee database (MTE-selected) MEF provisions credential. 7 Enrollee MEF (+ opt CA) Enrolling stakeholder 2.b Enrolee info for MTE Enrolee DB (o) Enrolling Stakeholder authentication App/Browser Enrolment Portal (Proprietary) 3. Associate Enrolee info w/ Enrolee 1. HTTPS MTE 2.a Proof of control to MTE Enrolment Portal 4. Credential provisioning via RSPF. 5. Provide Enrolee DB with credential-ID associated w/ Enrolee (o) Update MAF w/ credential (RSPF procedures) Enrollee DB (Proprietary) (o) MAF

Proof of Control Mechanism for “proof of control” could include – NFC interaction to prove proximity to the device – Scanning a QR-code on the device or provided with packaging. – Reading a PIN or passcode printed on the device or provided with packaging. – Reading a dynamic PIN, generated by the device, and displayed by the device. – Procedures at point of sale, like with purchasing a phone We propose that oneM2M does not specify “Proof of Control” mechanisms, – there are many options – the appropriate option will depend on many factors, and different verticals may have different requirements on the strength of the “proof of control” 8

On-Boarding & Enrolment Problem: MTE can’t always verify that a stakeholder in “control” of the entity An On-boarding Device or an On-Boarding Server can facilitate verifying that a stakeholder is in control of Enrollee – Expect only one of OBS or OBD verifies if stakeholder is in control of Enrollee On-boarding device (OBD): UI-rich device providing proximal sec config/provisioning – E.g. smart phone, tablet, dedicated technician’s device. – Can verify if stakeholder is in control of Enrollee, using interaction via app/browser on OBD [1,3] – Can establish mutually authenticated communication w/ Enrollee [2,3] – Authorized (at Enrollee) to perform security config and/or credential provisioning of Enrollee [3] On-boarding server (OBS): cloud server providing remote sec configuration/provisioning – Can verify if stakeholder is in control of Enrollee, using interaction via app/browser and web portal [1] – Pre-provisioned with credentials for establishing mutually authenticated comms w/ Enrollee [2] – Authorized (at Enrollee) to perform security config and/or credential provisioning of Enrollee When OBS/OBD performs credential provisioning, then also acting as MEF. 1.Details are not specified by oneM2M. 2.May use oneM2M-specified RPSF, other standards or proprietary mechanisms 3.May optionally using proximity-based mechanisms 9

On-Boarding Function OBS and OBD look identical from a system perspective, with following differences – OBD case: User Interface (app/browser) is integrated to other on-boarding functionality – OBS case: User Interface (app/browser) is separate from other on-boarding functionality, with TLS/DTLS securing interaction between on-boarding functionality and User Interface We do not differentiate between OBD and OBS for remainder of presentation – Descriptions specific to OBD and OBS are provided as “backup slides.” We use term “On-Boarding Functions (OBF)” to refer to both OBD and OBS 10

OBF and Trust MTE might trust OBFS to provision credentials, or MTE might prefer to use another MEF of MTE’s choosing Untrusted OBF case: – MTE does not trust the OBF to provision credentials – MTE-selected MEF is used 1.MTE provides MEF URI to OBF 2.OBF directs Enrollee to perform RSPF with MEF URI 3.Enrollee performs RSPF with MTE’s MEF Trusted OBF case: – MTE trusts the OBF to acts as MEF 1.MTE provides MTE’s OBF Portal URI for submitting provisioned credential 2.Enrollee performs RSPF with OBF 3.OBF submits provisioned credential to MTE’s OBF Portal URI Easiest to examine the two cases separately 11

Enrolment Flow w/ OBF & Enrolment Tokens A.App/Browser facilitates interaction between Enrolling Stakeholder, Enrollee, OBF and MTE Portal to authorize the Enrolment and establish parameters for Provisioning – MTE generates a single-use Enrolment-Token associated with Enrolee entry in database, and provides to OBF via App/Browser B.Interaction between Enrollee, OBF and MTE for provisioning and distributing credentials & IDs. – Details depend on if OBF is trusted or not: see previous slide – Enrolment-Token is provided to MTE so provisioned credential is associated with the correct Enrolee Untrusted case: Enrolee provides Enrolment Token w/ RSPF session Trusted case: OBF provides Enrolment Token w/ provisioned credential 12

OBF Untrusted OBF & MTE Enrolment 13 Enrollee MEF (+ opt CA) Enrolling stakeholder 3. Enrolee info for MTE Enrolee DB (o) Enrolling stakeholder authentication App/Browser Enrolment Portal (Proprietary) 4.ii Enrolment Token, Enrolee Info 2. HTTPS MTE 4.i MAF sends Enrolment Token, MAF URI, trust anchor to OBF via App/Browser 9. Credential provisioning via RSPF. RSPF TLS handshake inside Server Auth TLS 8. Trigger selected RSPF 10. Provide Enrolee DB with credential-ID & Enrolment Token (o) Update MAF with credential (see RSPF procedures) 5. OBF securely forwards Enrolment Token, MEF URI, trust anchor to Enrolee (proprietary mechanism) 1. Proof of control provided to OBF 6. Server Auth TLS 7. Enrolment Token, supported RSPFs Enrollee DB (Proprietary) (o) MAF 4.iii Enrolment Token

Comments on Un-trusted OBF case Enrollee establishes server authenticated TLS with MEF – Enrollee Presents Enrolment Token (for authorizing enrolment and for correlating credentials with Enrollee in Enrollee DB) Indicates supported RSPF (GBA, PSK, Cert). – MEF Selects an RSPF and sends Enrollee a message triggering RSPF – Enrollee & MEF perform TLS handshake for RSPF inside the server authenticated TLS session This hides identifying information like device certificate or KpmId from eavesdroppers Also “binds” Enrolment Token to the provisioned credential – Not a cryptographic binding, but good enough! NOTE: No impact on existing RSPF text – RSPFs can be used “as is” 14

MTE Trusted OBF & MTE Enrolment 15 Enrolment Portal (Proprietary) 7. Provisioned Credential, Enrolment Token 6. TLS (o) using OBF Cert Trusted OBF (inc MEF) App/Browser Enrolling stakeholder 3. Enrolee info for MTE Enrolee DB (o) Enrolling stakeholder authentication 2. HTTPS 4.i. Enrolment Token, OBF Portal URI, OBF Portal trust anchor 5. OBF securely provisions credential (RSPF or proprietary mechanism) Enrollee 1. Proof of control provided to OBF Enrollee DB (Proprietary) (o) MAF OBF Portal 8. Provide Enrolee DB with credential-ID & Enrolment Token (o) Update MAF with credential (see RSPF procedures) 4.ii Enrolment Token, Enrolee Info 4.iii Enrolment Token

Comments on Trusted OBF case OBF (acting as MEF) provision Enrolee using either – oneM2M RSPFs, or NOTE: No impact on existing RSPF text – RSPFs can be used “as is” – Proprietary mechanism NOTE: We can’t prevent proprietary mechanisms being used We would like to specify interaction between Trusted OBF and OBF Portal, but we don’t’ think there is enough time for Rel 2. – Authentication of Trusted OBF needs to be defined TLS Client Certificates? Symmetric keys (for TLS? HTTP-Digest authentication?) Do we address provisioning of these credentials? – The API needs to be specified for submitting the Enrolment-Token and credential to the OBF Portal Not difficult to define – but depends somewhat on whether HTTP-Digest authentication is used. Since there is so much that would be “unspecified” for the Trusted OBF case, we recommend not specifying this in Rel 2 – Could include an example flow in an informative annex. 16

Expected Normative Changes to TS-0003 Definitions – Update definition: Enrolment phase – New definitions: Enrolling Stakeholder, Enrolment Token, MTE, OBF It is probably un-necessary to formally define OBD and OBS Add new Clause 8.x Enrolment – 8.x.1: Introduction, including motivation for on-boarding. – 8.x.2 Enrolment without On-Boarding Function Call flow – 8.x.3 Enrolment with Untrusted On-Boarding Function Call flow – NOTE: The call flows reference RSPF procedures – the text will not replace or impact RSPF text 17