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

2. Introduction
This presentation is a based on SEC E2E_Primitive_Security,
Tailored for an ARC audience
Some changes in details based on Qualcomm internal discussions
SEC 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

3. 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.

4. 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

5. 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 in SEC 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 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

6. 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

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

8. (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