OnBoarding and Enrolment Group Name SEC WG Source

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

• R 01 History – Renamed “SP” with “M 2 M 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 M 2 M-MTE-to-M 2 M-Service-Subscriber. – Various 3 rd party M 2 M Trust Enablers (MTE), independent of the M 2 M SP, might facilitate functionality needed for ESPrim, ESData, Dynamic Authorization, etc. Feature class Communication Security* Release 1 Release 2 SAEFs ESPrim ESData Authorization Release 1 ACPs Roles Dynamic Authorization Distributed Authorization 3

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 M 2 M SP might not be the appropriate entity for provisioning E 2 E credentials (e. g. operating MEF) or managing authentication (e. g. operating MAF/TEF). Examples • E 2 E between entities in distinct domains • Liability issues – M 2 M 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-2015 -00549 R 02) C. (New? ) Verifying that the Enrolling Stakeholder is in “control” of the Enrollee; could include • • Manufacturer, OEM, distributor, retailer M 2 M Service Subscriber (M 2 M SS) M 2 M SP who will later sell/lease the Enrollee to the M 2 M SS. Application Service Provider, or other 3 rd Party who will later onsell/lease the entity to the M 2 M 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. Enrollee App/Browser 4. Credential provisioning via RSPF. 5. Provide Enrolee DB with credential-ID associated w/ Enrolee (o) Update MAF w/ credential (RSPF procedures) MEF (+ opt CA) (o) MAF 1. HTTPS Enrolment Portal (Proprietary) 3. Associate Enrolee Enrollee DB info w/ Enrolee MTE (Proprietary) Enrolling stakeholder 2. a Proof of control to MTE Enrolment Portal 2. b Enrolee info for MTE Enrolee DB (o) Enrolling Stakeholder authentication 7

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 one. M 2 M 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. Details are not specified by one. M 2 M. May use one. M 2 M-specified RPSF, other standards or proprietary mechanisms 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 1. 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 A. B. Untrusted case: Enrolee provides Enrolment Token w/ RSPF session Trusted case: OBF provides Enrolment Token w/ provisioned credential 12

Untrusted OBF & MTE Enrolment 5. OBF securely forwards Enrolment Token, MEF URI, trust anchor to Enrolee (proprietary mechanism) OBF Enrollee 6. Server Auth TLS 7. Enrolment Token, supported RSPFs App/Browser 9. Credential provisioning via 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) 4. i MAF sends Enrolment Token, MAF URI, trust anchor to OBF via App/Browser 1. Proof of control provided to OBF MEF (+ opt CA) (o) MAF 4. iii Enrolment Token 2. HTTPS 3. Enrolee info for MTE Enrolee DB (o) Enrolling stakeholder authentication Enrolment Portal (Proprietary) 4. ii Enrolment Token, Enrollee DB Enrolee Info (Proprietary) Enrolling stakeholder MTE 13

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

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

Comments on Trusted OBF case • OBF (acting as MEF) provision Enrolee using either – • – • • 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. – • • • – • • one. M 2 M RSPFs, or 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