App End-to-End Security Requirements Group Name: SEC WG4 Source: Phil Hawkes, Qualcomm, Meeting Date: Agenda Item: WI-0016

History R01 – Removed mgmt use cases from discussion Mgmt is a special kind of application layer protocol Complicated! Need more time to synch with mgmt experts – Added proposal for “low-priority requirement” for special cases 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 – 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 – App end-points addressed in the presents contribution – Mgmt end-points to be addressed in a future 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 3

Primary target for this protection Application use cases –.content 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 attributes - not protecting a primitive (message) 4

About the Adversaries Host CSE(s) and Transit CSEs potential adversaries – Otherwise can just use the existing hop-by-hop security What can Host CSE(s) do that can’t be protected against. – Confidentilaity Host knows Resource path, type/structure of resource, size of all attributes. Time of creation/update. Can’t keep these confidential – Integrity: Host can change time of creation/update, reply with wrong resource – Availability : Host CSE can lie about existence of resources and lie about which is the latest or earliest 5

What can App protect? App can only protect RW (Read/Write) attributes Can protect confidentiality of attributes – Can encrypt individually if that is easier Integrity Protection – What aspects of integrity can be relevant to consumer? Detecting if individual RW attributes were altered. Detecting if RW attributes were given the wrong name Detecting if set of RW attributes are in single Detecting if is the child of expected – Last 3 aspect can be ignored if content consumer relies only on data within the RW attribute(s) Requires the producer to incorporate all relevant information in each RW attribute so that the consumer does not have to rely on HostCSE for last 3 aspects OK for Security (encryption+integrity protection) to cover single RW attribute 6

Application Case Characteristics (1) What is being protected? –.content Media/Data Type – App protocol specific We are not even sure what protocols these will be! There could be many protocols – Implies we should use a data-type independent mechanism E.g. Content treated as opaque binary – even at Host CSE Allow protecting any individual RW attribute – not just content attribute Number of destinations? –.content supports one content producer, potentially many content consumers E.g. An AE CREATEs a resource which is RETRIEVEd by multiple AEs. – Content producer might not know who the content consumer(s) will be 7

Application Case Characteristics (2) Importance/Value of payload to application stakeholders – Again, depends on the specific scenario Some cases have high importance/value (e.g. emergency alerts). Most cases expected to have low importance/value (most home temperate sensor updates) 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 temp sensor updates) On average, content expected have low importance/value and be created with high frequency – However,… in some special cases: content could have high importance/value and be created with low frequency We look at general (average) case and then special case 8

General case: Impact/Benefit Analysis Benefit: – Low av. payload value System Impact: – Support attributes of any data-type – Potentially many consumers, & provider doesn’t always know who consumer(s) will be Very difficult to encrypt a message for many consumers (requires key distribution mechanism), especially if set of consumers is not known in advance. Integrity protection for many consumers is best served using an asymmetric digital signature, which adds larger communication and processing overhead per message. – High frequency – Total system impact: High 9

General case: Conclusion For general case: – high impact outweighs low benefit Don’t solve general case in Rel 2 – But, it may make sense to consider a set of special cases with low impact and high benefit – so we look at this now. 10

Special case: Impact/Benefit Analysis Benefit (for the special case): – High av. payload value with System Impact (for the special case): – (Still) Support attributes of any data-type – Assume For decryption: At most a few consumers For data origin and integrity protection: Many consumers – Provider always knows who consumer(s) will be – Low relative frequency – Total system impact: low-to-medium Conclusion: – High benefit outweighs low-to-medium system impact 11

Special case: Conclusion In special cases, high benefit outweighs low-to- medium system impact – These cases accept high overheads of using asymmetric (public key) crypto in every message – “Sessionless” security schemes are viable OK for Security (encryption+integrity protection) to cover single RW attribute – See slide 6 “What can App protect” Special cases occur with low frequency, but could be important for adoption – Evaluate against use cases (TO DO) eHealth, smart energy? If these – What should relative priority be for Rel 2? Initial suggestion: Medium? 12

Recommended requirements The system shall support a data-type independent, end-to- end security mechanisms for protecting confidentiality and verifying data origin and integrity of individual resource attribute values The end-to-end security mechanism for securing individual resource attribute values shall support scenarios where a relatively small set of consuming entities can decrypt the resource attribute values. The end-to-end security mechanism for securing individual resource attribute values shall support scenarios where a relatively large set of consuming entities can verify the data origin and integrity of the resource attribute values. 13