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

Background • Rel 2 security is more complex than Rel 1 • Can involve more stakeholder interactions than just M 2 M-SP-to-M 2 M-Service-Subscriber. – Various 3 rd party stakeholders (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 2

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 health data – For now, we use “SP” to refer to any stakeholder managing credentials on behalf of the subscribers etc. 3

Clarifying Enrolment • Enrolment is A. Remote security provisioning: Issuing a SP-specific credential for authenticating the Enrollee within set of entities served by that SP • either shared key or certificate, as discussed in SEC-2015 -00549 R 02 B. Establishing an unique identity (if any) for the Enrollee C. Associating the Enrollee with the stakeholder in “control” of the Enrollee – we call this the Enrolling Stakeholder, could include • • Manufacturer, OEM, distributer, retailer M 2 M Service Subscriber (M 2 M SS) M 2 M SP who will later on-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 4

SP can verify “proof of control” • Recall: Enrolment includes – Associating the Enrollee with the stakeholder in “control” of the entity • • In some cases, Enrolling stakeholder provides “proof of control” directly to SP SP-selected MEF provisions credential one. M 2 M Remote Security Provisioning Enrollee Browser 5. Provision SP-issued credential, confirm assigned ID (o) MAF 1. HTTPS 4. TLS MEF (+ opt CA) 6. (O) Update MAF with ID and SP-Issued credential SP Enrolling stakeholder 2. a Proof of control Portal 2. b Add to database, (o) Enrolling Stakeholder authentication 3. assigned ID 5

On-Boarding & Enrolment • • Problem: SP 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 Enrolee • 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 Enrolee, using interaction via browser on OBD[1, 3] Can establish mutually authenticated communication w/ Enrollee[2, 3] Authorized (at Enrolee) to perform security config and/or credential provisioning of Enrollee[3] On-boarding server (OBS): provides remote sec configuration/provisioning – Can verify if stakeholder is in control of Enrolee, using interaction via browser and web portal [1] – Pre-provisioned with credentials for establishing mutually authenticated comms w/ Enrollee[2] – Authorized (at Enrolee) 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 6

OBD/OBS and Trust • SP might trust OBD/OBS to provision credentials, or SP might prefer to use another MEF of SP’s choosing • Untrusted OBD/OBS case: – SP does not trust the OBD/OBS to provision credentials – SP-selected MEF is used 1. SP provides MEF URI to OBD/OBS 2. OBD/OBS directs Enrollee to perform RSPF with MEF URI 3. Enrollee performs RSPF with SP’s MEF • Trusted OBD/OBS case: – SP trusts the OBD/OBS to acts as MEF 1. SP provides URI to forward provisioned credential to 2. Enrollee performs RSPF with OBD/OBS 3. OBD/OBS forwards provisioned credential to URI provided by SP 7

Enrolment Flow w/ OBD/OBS A. Browser facilitates interaction between Enrolling Stakeholder, Enrollee, OBD/OBS and SP Portal to authorize the Enrolment and establish parameters for Enrolment B. Interaction between Enrolee, OBD/OBS and SP for provisioning and distributing credentials & IDs. – The details depend on whether the OBD/OBS is trusted or not • We provide details for 4 Cases – Untrusted OBD, Untrusted OBS – Trusted OBD, Trusted OBS • These end up very similar – see end of presentation 8

Untrusted OBD case (steps 1 -5) • On-Boarding-Device (OBD) is not trusted with configuring credentials • OBD only forwards configuration & enrolment token • SP-selected MEF configures credential Proprietary 2. Proof of control 1. secure channel Enrollee OBD 5. a. Enrolment Token, MEF URI, trust anchor (o) MAF SP MEF (+ opt CA) Browser 3. HTTPS Enrolling stakeholder 4. a. Add to database (o) Subscriber log in Portal 5. b. Enrolment Token, assigned ID, (opt) identity from existing cert 4. b (opt) identity from existing Enrollee cert. (e. g. device ID) 9

Untrusted OBD case (steps 6 -9) one. M 2 M Remote Security Provisioning Enrollee OBD Browser 6. TLS (opt using sign-up credential) 8. Provision SP-issued credential, confirm assigned ID (o) MAF MEF (+ opt CA) Enrolling stakeholder 7. Enrolment Token Portal 9. (O) Update MAF with ID and SP-Issued credential SP 10

Untrusted OBS case (steps 1 -5) • OBS is not trusted with configuring credentials • OBS only forwards configuration & enrolment token • SP indicated MEF provisions credential 1. a HTTPS OBS Enrollee 2. Proof of control Browser 3. HTTPS 5. a Enrolment Token, MEF URI, trust anchor (o) MAF SP MEF (+ opt CA) Portal Enrolling stakeholder 4. a Add to database, (o) Subscriber log in 4. b. (opt) identity from existing Enrollee cert. (e. g. device ID) 5. b Enrolment Token, assigned ID, (opt) identity from existing cert 11

Untrusted OBS case (steps 6 -11) Proprietary 7. Enrolment Token, MEF URI, trust anchor 6. secure channel, e. g. TLS OBD Enrollee Browser one. M 2 M Remote Security Provisioning 10. Provision SP-issued credential, confirm assigned ID (o) MAF Enrolling stakeholder 8. TLS (opt device cert) 9. Enrolment Token MEF (+ opt CA) Portal 11. (o) Update MAF with ID and SP-Issued credential SP 12

Trusted OBD case (steps 1 -5) • On-Boarding Device (OBS) is trusted with configuring credentials • OBD acts as MEF, provides provisioned credential to MAF • SP does not provision credential 1. Proof of control Enrollee OBD (inc MEF) 3. b. (opt) OBD ID from OBD cert. 5. Enrolment Token, assigned-ID (o) MAF SP Browser 2. HTTPS Enrolling stakeholder 3. a Add to database, (o) Subscriber log in Portal 13

Trusted OBD case (steps 6 -10) 6. Secure communication e. g. TLS/DTLS Enrollee one. M 2 M RSPF or Proprietary OBS (inc MEF) 7. Provision credential + assigned ID Browser 8. HTTPS Enrolling stakeholder 9. a Enrolment Token 9. b Credential (o) MAF Portal 10. (O) Update MAF with ID and SP-Issued credential SP 14

Trusted OBS case (steps 1 -5) • On-Boarding Server (OBS) is trusted with configuring credentials • OBS acts as MEF, provides provisioned credential to MAF • Service Provider does not provision credential 1. a HTTPS Enrollee 2. Proof of control OBS (inc MEF) 4. b. (opt) OBS ID from OBS cert. 5. Enrolment Token, assigned-ID (o) MAF SP Browser 4. HTTPS Enrolling stakeholder 4. a Add to database, (o) Subscriber log in Portal 15

Trusted OBS case (steps 6 -10) 6. Secure communication e. g. TLS/DTLS one. M 2 M RSPF or Proprietary OBS (inc MEF) Enrollee 7. Provision credential + assigned ID 8. HTTPS Browser Enrolling stakeholder 9. a Enrolment Token 9. b Credential (o) MAF Portal 10. (O) Update MAF with ID and SP-Issued credential SP 16

Observations on four cases • Similarities – Interactions with SP are identical for both Trusted OBD and Trusted OBS – Interactions with SP are identical for both Untrusted OBD and Untrusted OBS too • We can refer to “On-Boarding Functions (OBF)” for both OBD and OBS • Next slides show interactions with SP in untrusted OBF case and trusted OBF case. 17

Untrusted OBF & SP Enrolment • Focus on interactions with SP • Note: no interaction between SP & OBF d. OBF forwards params to Enrolee c. i Enrolment Token, MAF URI, trust anchor sent to OBF OBS Enrollee one. M 2 M RSPF a. HTTPS f. Provision SP-issued credential, assigned ID, Enrolment Token (o) MAF e. TLS (opt device cert) MEF (+ opt CA) g. (o) Update MAF with ID and SP-Issued credential SP Browser Portal Enrolling stakeholder b. i Add to database, (o) Subscriber log in b. ii. (opt) identity from existing Enrollee cert (e. g. device ID) c. ii Enrolment Token, assigned ID, (opt ID from existing Enrollee Cert) 18

Trusted OBF & SP Enrolment • Focus on interactions with SP • Note: no interaction between SP & Enrollee d. Not shown: OBF provisions credential and assigned ID to Enrolee Enrollee c. Enrolment Token, assigned-ID Trusted OBF (inc MEF) e. HTTPS (o) using OBF Cert a. HTTPS f. Provisioned Credential , Enrolment Token (o) MAF Browser Portal Enrolling stakeholder b. i Add to database, (o) Subscriber log in b. ii (opt) OBF ID from OBF cert. g. (O) Update MAF with ID and SP-Issued credential SP 19

Summary of SP Enrolment • Focus on interactions with SP d. Not shown: OBF either Forwarding credentials forwards parameters or provisioned to Enrolee by OBF provisions Enrollee c. Enrolment Token one. M 2 M RSPF Enrollee Trusted OBF (inc MEF) Browser e. TLS (opt existing Enrollee/OBF cert) f. Provision (or forward) Credential & assigned ID, Enrolment Token MEF (+ opt CA) SP a. HTTPS c. ii Enrolment Token, assigned Portal ID, (opt ID) from existing Enrollee cert g. (Opt) Update MAF (o) MAF w/ ID & provisioned credential f. Provision SP-issue credential, confirm assigned ID Enrolling stakeholder b. i Add to database, (o) Subscriber log in b. ii (opt) identity from existing cert of Enrollee or Trusted OBF. 20

Summary of OBF-based SP Enrolment A. Browser facilitates interaction between Enrolling Stakeholder, Enrolee, OBD/OBS and SP Portal to authorize the Enrolment and establish parameters for Enrolment – Enrolling Stakeholder Provides OBF with “Proof of control” over Enrollee – Enrolling Stakeholder Authenticates to SP Portal – (Opt) Enrollee/OBF identity (from existing certificate) may be provided to SP for subsequent TLS authentication – SP provides OBF with enrolment-token for correlating with provisioned credential – (Trusted cases) SP provides assigned ID to OBF for provisioning to Enrollee B. Interaction between Enrolee, OBD/OBS and SP for provisioning credential & IDs in Enrollee and (in trusted OBF case) forwarding credential to SP. – The details depend mostly on whether the OBD/OBS is trusted or not 21