End-to-End Security for Primitives Group Name: ARCWG Source: Qualcomm Inc., Wolfgang Granzow & Phil Hawkes Meeting Date: ARC20.4 (joint with SEC), 2016-01-06 Agenda Item: End-to-End Security and Group Authentication

Introduction This presentation is a based on SEC-2015-0678-E2E_Primitive_Security, Tailored for an ARC audience Some changes in details based on Qualcomm internal discussions SEC-2015-0678 has not been treated by SEC yet. Purpose of End-to End Security for Primitives Securing oneM2M primitives (e.g. Originator-to-Hosting CSE) High Level View/Requirements End-to-End Encryption and Integrity protection of entire Primitive Similar options as for hop-by-hop security association establishment PSK, MAF, certificate Reuse Remote Security Provisioning Framework specified for hop-by-hop

High Level View: Request Originator Hosting CSE 1. Form inner request primitive JSON/XML serialization 2. Apply JWE/XML-ENC processing to inner request primitive, resulting in JWE/XML-ENC object 3. Form outer request primitive To: <e2ESecurityExchange>, Op =to be determined, Content = JWE/XML-ENC object, etc. 4. Send outer request primitive <e2ESecurityExchange> 5. Extract Content = JWE/XML-ENC object. 6. Apply JWE/XML-ENC processing to JWE/XML-ENC object, resulting in JSON/XML serialization of inner request primitive 7. Process inner request primitive NOTE: Blocking mode shown.

High Level View: Response Originator Hosting CSE 8. Form inner response primitive JSON/XML serialization 9. Apply JWE/XML-ENC processing to inner response primitive, resulting in JWE/XML-ENC object 10. Form outer response primitive Content = JWE/XML-ENC object, etc. 11. Send outer response primitive 12. Extract Content = JWE/XML-ENC object. 13. Apply JWE/XML-ENC processing to JWE/XML-ENC object, resulting in JSON/XML serialization of inner response primitive 14. Process inner response primitive NOTE: Blocking mode shown. In non-blocking mode, step 11 looks a little different

Aspect Solution ARC Impact Transport Content param of primitive acting on <e2ESecuredExchange> High Primitive protection Encryption + integrity protection using XML Enecryption or JSON Web Encryption (JWE) with symmetric key1 Low Freshness See slides 11-14 in SEC-2015-0678. Requires adding optional latestE2ERand attribute to <remoteCSE> def’n for including latest random value provided by corresponding HCSE. 1 Med <e2EKey> resource Enables two end-points (CSE+CSE, AE+AE, CSE+AE) to establish symmetric key using certificates (see ARC-2016-0003-e2EKey_resource). Efficiency advantages.1 Rules for E2E primitive security Orig or HCSE can insist on E2E Primitive security Once initiated, both must use E2E primitive security e2ePrimitivePolicy: “all” or list of specific end-points 1. Not discussed further in this presentation

Transport <e2ESecuredExchange> resource: Purpose: receiving for secured requests and returning secured responses <e2ESecuredExchange> request Content contains the secured request To: resource-ID of the default <e2ESecuredExchange> resource on HCSE All other usual parameters. RequestId seems to serve no purpose in the outer primitive, since the requestId in the inner primitive will be correlated. One suggestion is to use a reserved requestId – to increase the difficulty of correlating requests and responses. <e2ESecuredExchange> response Content contains the secured response All usual parameters

<e2ESecuredExchange> Options Resource “nature” Virtual (no defined attributes): Recommended Non-Virtual (defined attributes) Multiplicity Single <e2ESecuredExchange> resource on HCSE. All Originators address this single resource. Only allow one of CREATE or UPDATE This option recommended since no need for multiple A new <e2ESecuredExchange> resource is created for each secured request. Use <CSEBase> as parent? Only allow CREATE only Single option recommended since no need for reference to the exchange instance outside the request/response exchange.

(ARC Impact) Rules for E2E primitive security Originators and HCSE need to know whether (in a multi-hop communication) E2E Primitive security to be applied. For Release 2, keep things as simple as possible Principles Either Originator or HCSE can initiate E2E primitive security Once E2E primitive security initiated, both ends must apply E2E primitive security until “session” expires – that is, unsecured primitives in either direction will be rejected. CSEs configured with [e2ePrimitiveSecurityPolicy], specialization of <mgmtObj>, that says when CSE must insist on E2E primitive security [e2ePrimitiveSecurityPolicy] contains either “all”: indicating, for all other entities, the entity (Originator/HCSE) must insist on e2e primitive security for multi-hop communication A list of CSE-IDs, AE-IDs or links to <group> resources for which the entity (Originator/HCSE) must insist on e2e primitive security for multi-hop communication Impact on TS-0001: Defining [e2EPrimitiveSecurityPolicy] resource Suggested Authors: Qualcomm introduce TS-0001 text, and later corresponding TS-0004 text