App and Management End- to-End Security Requirements Group Name: SEC WG4 Source: Phil Hawkes, Qualcomm, Meeting Date: Agenda 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 – App/Mgmt end-points := entities producing and consuming the app/mgmt payloads – Trusted: App/mgmt end-points – Untrusted: Host CSE(s), Transit CSEs, everything not on delivery path – This is addressed in the present contribution 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 a separate 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 2

About the Adversaries The Host CSE(s) and Transit CSEs are assumed to be untrusted for this case – Otherwise can just use the existing hop-by-hop security Can assume that the Host CSE(s) will know – Resource path, type/structure of the resource, size of all attributes. Time of creation/update App/Mgmt end-points can only protect RW (Read/Write) attributes – Confidentiality of individual RW attributes – Integrity Detecting if individual RW attributes were altered Detecting if RW attributes were given the wrong name Detecting if the correct combination of RW attributes are in the same resource Detecting if the RW attributes are in the correct resource Detecting if the RW attributes are in the requested resource You can’t tell if Host CSE is lying about existence of resources 3

Primary target for this protection Application use cases –.content Management Use Cases –.[objectAttributes] (list) Consider firmware and software updates as a separate topic. –.execReqArgs Anything we specify to protect these attributes could also be applied to other attributes – But there does not seem to be a compelling use case Note that this case addresses protecting a resource (payload) and attributes - not protecting a primitive (message) 4

Application Case Characteristics (1) What is being protected? –.content Media Type – App protocol specific We are not even sure what protocols these will be! There could be many protocols Number of destinations? –.content supports “Multicast” behaviour: one sender, many receivers E.g. An AE CREATEs a resource which is RETRIEVEd by multiple Aes..content may be used with “Unicast” behavior: one sender and one receiver – Content producer might not know who the content consumer will be 5

Application Case Characteristics (2) Frequency – Frequency would depend on the specific scenario Some cases might have low frequency (e.g. emergency alerts). Other cases might have high frequency (home temperate sensor updates) – On average, content generally expect to created often Importance/Value of payload to the application stakeholders – Again, depends on the specific scenario Some cases might have high importance/value (e.g. emergency alerts). Most cases expected to have low importance/value (most home temperate sensor updates) – On average, content expected to have low importance/value 6

Management Case Characteristics (1) What is being protected? –.[objectAttributes] –.execReqArgs Media Type will be management protocol specific – We know what protocols are supported by oneM2M – There are only a few protocols, all support XML media type Number of destinations? – “Unicast” behaviour: one sender, one receiver Firmware and software updates and some other generic configuration may have same data sent to multiple destinations, but these can always use unicast if desired. Further, such data is likely to require data origin authentication and not protecting from Host CSE compromising confidentiality. This can be addressed with digital signatures. We are currently proposing to ignore these cases for Rel 2 – or at least discuss separately from other cases. – Content producer always knows who content consumer will be 7

Management Case Characteristics (2) Frequency – Mgmt use cases create resources with low frequency There may be occasionally scenarios creating resources with high frequency – but such cases would be expected to happened with very low frequency Importance/Value of payload to the management stakeholders layer – Generally, mgmt payloads have medium-high importance/value (when compared to app payloads) 8

Impact/Benefit Analysis.content System Impact: – many media types – multicast security – Provider doesn’t always know consumer – High frequency – Large system impact Benefit: – Low av. payload value Proposed Conclusion: – Generally* Large impact outweighs low benefit – Don’t consider general case in Rel 2.[objectAttributes] &.execReqArgs System Impact: – XML media type – unicast security – Provider always knows consumer – Low frequency – Small system impact Benefit: – Med-High payload value Proposed Conclusion: – Med-High Benefit outweighs small impact! – Consider for Rel 2 *In specific cases, benefit may be higher, and outweigh impact9

Analysis Conclusion Targeted – End-to-end security solution for.[objectAttributes] &.execReqArgs – Allow using to protect any resource Characteristics – XML media type – Unicast security – Content producer knows who the content consumer is – Infrequent transmission of high value resources Implies we can accept high overheads of using asymmetric (public key) crypto in every message “Sessionless” security (like S/MIME or OpenGPG) are viable 10

Recommended requirement The system shall support an end-to-end security mechanism protecting infrequent transmission of XML content to a single, known target entity 11