1. Primitive End-to-End Security Requirements Group Name: SEC WG4 Source: Phil Hawkes, Qualcomm, phawkes@qti.qualcomm.comphawkes@qti.qualcomm.com Meeting Date: 2015-05-18 Agenda Item: WI-0016

2. Classifying scenarios Classify scenarios according who is trusted and who is untrusted (i.e. potential adversaries) Case 1: Only App/Mgmt End-points trusted – Trusted: App/mgmt end-points – Untrusted: Host CSE(s), Transit CSEs, everything not on delivery path – This is addressed in SEC-2015-0513 “App and Mgmt End-to-End security requirements” Case 2: Host CSE also trusted – Trusted: App/mgmt end-points, Host CSE’s – Untrusted: Transit CSEs, everything not on delivery path – This is addressed in the present contribution Case 3: Transit CSE’s also trusted – Trusted: everything on the delivery path – Untrusted: everyone not on the delivery path – Hop-by-hop security: TLS/DTLS already covers this case. – No need to discuss this case further

3. About the Adversaries The Host CSE(s) are trusted – Host CSE of the resource, plus host CSEs for any announced copies of the resource All or some of the Transit CSEs are assumed to be untrusted for this case – Otherwise can just use the existing hop-by-hop security Protection is at the primitives level Can assume that the Transit CSE will know – The originator of the request in the From attribute – The receiver of the request in the To attribute (e.g. Host CSE in request) What protection can be provided – Confidentiality of primitive – Integrity of primitive – Detecting if messages are replayed received out of order Protocol core specification should say what to do in the event of replayed or out of order primitive – This is out of scope of the current discussion. 3

4. Primary target for this protection Primitives traversing more than one Mca or Mcc reference point. Note that this case addresses protecting a primitive (message) – in addition to protecting the resource (payload) in the primitive – Can’t protect the resource from the Host CSE – For those cases, see SEC-2015-0513 “App and Mgmt End-to-End Security Requirements”

5. Use Case Characteristics What is being protected? – All Primitives traversing multiple Mca/Mcc hops MediaType – oneM2M Primitive media types defined in. TS-0004 (Core Protocol specification) clause 6.7 – All use XML or JSON representation Number of destinations? – Primitive have “Unicast” behavior: one sender, one receivers – Primitive producer always knows who the primitive consumer

6. Use Case Characteristics Transmission characteristics – Depends on the specific scenario – Should be support a range from one-off exchanges to very frequent exchanges Importance/Value of primitive to stakeholders – Depends on the specific scenario and payload – Should support a range from low to high Importance/Value

7. Analysis Conclusion Target – End-to-end security for primitives traversing multiple Mca/Mcc hops Characteristics – XML or JSON media type – Unicast security – Content producer knows who the content consumer is – Transmission of primitive exchange: range - “one-off” to frequent – Importance/Value of primitive: range – low to high Comments – A solution providing security for “one-off” primitive exchange with high overheads will be acceptable for high importance/value payloads These will probably need asymmetric (public key) crypto in every message – A need a solution providing security for larger numbers of primitive exchanges with low overheads

8. Recommended requirements The system shall support end-to-end primitive security mechanisms protecting primitive passed via untrusted entities. The system shall support an end-to-end primitive security mechanism for one-off primitive exchanges. The system shall support end-to-end primitive security mechanism establishing an end-to-end secure session for exchanging a large number of primitive exchanges.