1. Authorization for IoT Group Name: oneM2M SEC WG Source: Francois Ennesser, Gemalto NV (francois.ennesser@gemalto.com) Meeting Date: 2014-09-03 Agenda Item:

2. Current M2M Authorization “Resources” (R) are accessed by “Apps” (A= AE/CSE) – Need Publish/Subscribe (e.g. MQTT) to avoid polling – ACP represent Resources/Apps relationships Works well when R/A relationships are predictable – E.g. “centralized” M2M deployment scenarios A central entity (“Server” App) overviews authorized relationships with “Client” Apps Typical model in today’s “one-to-many” Client/Server M2M – Assumes any PEP (as PDP) has access to ACP database Access to ACP DataBase (DB) becomes a critical bottleneck! Level of risk increases as more entities can access ACP DB © 2014 oneM2M Partners SEC-2014-0396 2

3. Notion of “Role” Imagine “n” Resources, “p” apps, “x” operations. – ACP size/complexity becomes exponential Flaws in ACP become unavoidable With “role”, “n” and “p” become manageable – “Role” encompass all Apps handling similar Resources – E.g. 1 million Smart Meters have same R/A relationship Roles avoid risk of flaws in ACPs when adding/removing meter E.g. 1 Role for Smart Meter, 1 role for Head End, no more! – Roles may be defined for Applications in the M2M Service Subscription – Not just a “group” of Apps, emulated through ACPs

4. What is new in IoT from M2M? IoT deployments are “Many-to-many” – “Devices” (may be a PC) act as both Clients and Servers – No central actor has a view on existing R/A relationships R/A relationships may change dynamically – User X grants access to its Resources to User Y Apps For a specific purpose, or reduced duration – Implies highly dynamic ACP management Fine granularity needed to capture specific scope PDP (ACP database) access bottleneck becomes a nightmare!

5. Involved parameters Different Resources have different sensitivity – E.g. Vending Machine content vs. power switch-off order Different Apps have different Trust levels – Apps belonging to an Infrastructure – Apps belonging to different kind of customers Authorization of App on Resource – Depends on the trust relationship between owners of App and Resource (e.g. same owner, contract, etc.)

6. Trust and End-to-End security Multiple M2M SPs will typically be involved – All need to be trusted, or App data must be encrypted Hop-by-hop security assumes M2M SP Circle of Trust Not realistic as small specialized M2M SPs may be involved – Need End-to-End security solution Trust management in IoT becomes complex – Dynamic credentials management with multiple actors – Authentication granularity not enough for Authorization Separation of Trust services facilitates resolution – “M2M Trust Enabler” already defined in TR-0005

7. A new paradigm for IoT? Current Model = Theme park – “PDP” (establishing ACP) = Cashier at the entrance – “Resources” (PEP)= Attractions inside the park In current model, when you access an attraction, they (PEP) call the cashier (PDP) to ensure you paid the proper fare!!! Efficient Model: – Cashier (PDP) at entrance gives you a ticket = “token” – Ticket validity can be verified by attraction (PEP) No need to call the cashier (PDP) to check its validity! Can “token” provide the above ticket features?

8. Self-Descriptive Token concept A token that is verifiable without referring to issuer – Generated for Apps by a PDP (Trust Enabler: TE) – Transmitted by Apps to a PEP (M2M SP) Requires 2 parts: – Public part, e.g. Scope of Authorization granted by the token Proof of authenticity (e.g. Signature of Trust Enabler) for PEP – Private (secretly encrypted) part for App Encrypted with Authentication key between App and TE E.g. information to retrieve relevant credentials

9. Trust Enabler / Service Provider split M2M Trust Enabler tasks: – Grants authorization to registered Apps – Aware of Resources exposed by authorized Apps – Enables Apps to control Access to their Resources E.g. by sharing Resource encryption key when authorization is granted M2M Service Provider tasks: – Handles Apps requests, checks tokens validity and grant access accordingly – Manage and publish Resources to subscribed Apps

10. Trust Enabler APIs Secure communication between M2M SP and supported Trust Enabler(s) (TE) is assumed – Trust Enabler API enables Apps enrolled to TE Possessing Credential = ID + TE secret + SP secret to define which of their Resources – published by M2M SP to Trust Enabler can be accessed by which other Apps – which obtain an Authorization token to access the Resource – Tokens are delivered to authenticated Apps And presented by Apps to M2M SP s – To access their services and exposed resources