Primitive End-to-End Security Requirements

Group Name: SEC WG4Source: Phil Hawkes, Qualcomm, phawkes@qti.qualcomm.com Meeting Date: 2015-05-18Agenda Item: WI-0016

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

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

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”

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

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

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

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.