End-to-End Primitive Security: Challenges and Suggestions Group Name: SEC WG Source: Qualcomm Inc., Phil Hawkes, Wolfgang Granzow, Josef Blanz Meeting Date: SEC#20.3, Agenda Item: End-to-End Security and Group Authentication

Background Strict deadline for stage 2 details At TP#20, it was agreed that securing oneM2M Primitives (e.g. Originator-to-Hosting CSE) is one of SEC’s priority – Unlike attribute security (see other contribution)… – …everything is within scope of oneM2M (except pre- provisioning) This presentation looks at what we need to do (challenges) in SEC & ARC – Overview first, then SEC impact, then ARC impact 2

E2E Primitive Protection Requirements What we want to provide – End-to-End Encryption and Integrity protection of entire Primitive exchanged between Originator and HCSE Encryption should never be used without integrity protection! Encryption does not increase Primitive size or computation by much – if integrity protecting, then may as well encrypt! – Similar options as for hop-by-hop security association establishment PSK, MAF, certificate – Reuse Remote Security Provisioning Framework specified for hop-by-hop – Freshness Prevent “really” old Primitives being cached and resent at a later time. – Would be nice to prevent transit CSEs from correlating secured requests against secured responses What we don’t need to provide – Replay protection: Replay detection can provided by requestId & managed at the Primitive level Discuss – are people happy with this? – Order: oneM2M allows Primitives to be delivered out of order – E.g later high priority Primitives can be delivered before older low-priority Primitives 3

Review: JOSE, XML SEC JSON Security: JOSE – JavaScript Object Signing and Encryption (JOSE) IETF WG – JSON Web Encryption (JWE) and JSON Web Signature (JWS) – Includes versions with JSON and compact (URI safe) representations. JSON version is more flexible, but not needed for E2E primitive security – Extended by IETF CBOR Object Signing and Encryption (cose) specifications in near future: XML Security: – XML Encryption and XML Signature – similar to JWE and JWS I use “XML SEC” for combined XML ENC specification and XML SIG specification – No compact representation 4

High Level View: Request 5 OriginatorHosting CSE 1. Form inner request primitive JSON/XML serialization 2. Apply JOSE/XML-SEC processing to inner request primitive, resulting in JOSE/XML-SEC object 3. Form outer request primitive To:, Op =to be determined, Content = JOSE/XML-SEC object, etc. 4. Send outer request primitive 5. Extract Content = JOSE/XML-SEC object. 6. Apply JOSE/XML-SEC processing to JOSE/XML-SEC object, resulting in JSON/XML serialization of inner request primitive 7. Process inner request primitive NOTE: Blocking mode shown.

High Level View: Response 6 8. Form inner response primitive JSON/XML serialization 9. Apply JOSE/XML-SEC processing to inner response primitive, resulting in JOSE/XML-SEC object 10. Form outer response primitive Content = JOSE/XML-SEC object, etc. 11. Send outer response primitive 12. Extract Content = JOSE/XML-SEC object. 13. Apply JOSE/XML-SEC processing to JOSE/XML-SEC 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 OriginatorHosting CSE

Overview of Challenges AspectSolution TransportContent param of primitive acting on RepresentationXML/JSON serialization of primitives as chosen by Originator Primitive protection Encryption + integrity protection using XML ENC or JSON Web Encryption (JWE) with symmetric sessionE2EPrimitiveKey FreshnessAdd optional latestE2ERand attribute to def’n for including latest random value provided by corresponding HCSE. Orig e2ERand provided in-band. sessionE2EPrimitiveKey derived from e2ERands + pairwiseE2EPrimitiveKey pairwise- E2EPrimitiveKey Establishment PSK Certificate: use resource (see SEC e2EKey_resource) MAFSlight variation on MAF SAEF ProvisioningUse Remote Security Provisioning Frameworks (RSPFs) as for SAEFs Rules for E2E primitive security 1.Orig or HCSE can insist on E2E Primitive security 2.Once initiated, both must use E2E primitive security 3. : “all” or list of specific end-points 7

Payload Protection Session Establishment 8 Remote Security Provisioning PPSKGBA Cert Key w/ MAF MAF pairwiseE2EKey* Key shared by entity & MEF Key shared by SIM/USIM & MNO Certificate *These credentials can also be configured directly pairwiseE2E- PrimitiveKey* e2ERand sessionE2EPrimitiveKey JWE/ XML ENC E2E Primitive Security pairwiseE2E- AttributeKey* JWE/XML ENC E2E Attribute Security None Key w/ TEF TEF

SEC Impact 9

(SEC Impact) JWE/XML-ENC JWE and XML-ENC v1.1 provides AEAD: Authenticated Encryption with Additional Data (AEAD) – Integrity protection is built in Using a symmetric key (e.g. pre-provisioned shared key or key supplied by MAF) provides mutual authentication – Very low overhead, only requires providing key identifier. – ~1.3 payload size expansion (mostly due to base64 encoding) JWE/XML-ENCv1.1 using certificates does not authenticate sender – Can use additional layer of JWS /XML SIG, but this further bloats size – Estimate: 1400 bytes overhead + ~1.8x payload size expansion – Too much for every Primitive or even once per req/resp exchange! Suggestion: Always use JWE with symmetric key. Provide mechanisms for generating this symmetric key – Generating the symmetric key will be addressed in later slides 10

(SEC Impact) Freshness JWE/XML-ENC “as is” provides no freshness guarantees. – MAF case provides freshness assurance that the primitive is no older than last time a key was established via MAF. This is sufficient “freshness” – For longer-lasting pairwiseE2EPrimitiveKey, better freshness guarantee required Typically random values are exchanged to guarantee freshness – This adds overhead – Issues if multiple device connect simultaneously (China Mobile ) High level proposal (More details on next two slides) – Define Parameter e2ERand := (e2ERandId, e2ERandExpiry, e2ERandValue) – Add optional latestE2ERand attribute to def’n. – Every CSE frequently generates a fresh e2ERand and uses this to update its latestE2ERand in its resources on CSEs with which it is registered Originators retrieve latest e2ERand for HCSE Based on China Mobile’s “Group Authentication” Proposal 11 AE (Originator) MN2 Has a for IN-CSE (Hosting CSE) IN-CSE (Hosting CSE) MN1 UPDATE latestE2ERand in on MN2 RETRIEVE latestE2ERand in on MN2

(SEC Impact) sessionE2EPrimitiveKey Generation In MAF case, establishment Originator, MAF and HCSE interact to establish Kc between Originator and HCSE – sessionE2EPrimitiveKey is then derived from Kc Other cases assume Originator & HCSE have pairwiseE2EPrimitiveKey: 1.HCSE regularly UPDATES latestE2ERand in HCSE’s resource on other CSEs with which it registers 2.Originator retrieves e2ERand from HCSE’s – HCSE’s latestE2ERand is identical for all Originators at any given time 3.Originator generates its own e2ERand 4.Originator’s e2ERand included in initial JWE/XML-ENC header 5.JWE/XML-ENC header includes HCSE e2ERandId, Orig e2ERandId 6.Orig & HCSE sessionE2EPrimitiveKey generated from pairwiseE2EPrimitiveKey, HCSE e2ERand and Originator e2ERand 7.HCSE or Originator can send new e2ERand in-band in JWE/XML-ENC header – New e2ERand comes into effect in primitives using that e2ERandId 12

IN-CSE MN-CSE3 MN-CSE2 MN-CSE1 e2eRand1 AE

IN-CSE MN-CSE3 MN-CSE2 MN-CSE1 e2eRand1 AE e2eRand2

(SEC Impact) Freshness TS-0003 Impact Integration to JWE/XML-ENC – Including Orig e2ERandId and HCSE e2ERandId – In-band communication of e2ERand parameter sessionE2EPrimitiveKey Generation description sessionE2EPrimitiveKey Generation Suggested Authors: – China Mobile and Qualcomm introduce text – Impact on TS-0003: Medium 15

(SEC) pairwiseE2EPrimitiveKey Establishment PSK: Variation on existing hop-by-hop mechanism – pairwiseE2EPrimitiveKey is provisioned, possibly using remote provisioningremote provisioning Certificate-Based: – Originator and HCSE perform one-off TLS handshake using certs to establish key from which pairwiseE2EPrimitiveKey is derived. – Allows establishing pairwiseE2EPrimitiveKey without relying on a trusted third party who knows the secret key (vs remote provisioning) – Details in SEC e2EKey_resource MAF is used to generate sessionE2EPrimtiveKey directly – See next slide 16

(SEC Impact) MAF Variation on flow in clause – Entity A = Originator, Entity B = HCSE Credential Configuration – as in Association Configuration – as in Association Security Handshake 1.MAF Handshake – as in » establishing Kc and KcId at MAF and Originator 2.Originator  HCSE: KcId » in JWE header “kid” element (in SAEF, this is passed in TLS psk_identity) 3.HCSE establishes TLS w/ MAF a.HCSE  MAF: KcId b.MAF  HCSE: Kc and either Originator’s CSE-ID/AE-ID or KmId 4.sessionE2EPrimitiveKey is derived from KcId Suggested Authors – Gemalto specified MAF SAEF. E2E Primitive security could largely copy this text. – Qualcomm suggests Gemalto and Qualcomm introduce MAF Primitive security text in TS

(SEC Impact) Remote Provisioning Same options as for hop-by-hop security Extend Remote Security Provisioning Frameworks to support provisioning for E2E Primitive security – Minor updates to RSPF – Not too much detailed specification required – IDCC has already introduces this to TR-0012 (clause 8.4) Qualcomm suggests this be merged with existing RSPF text in TS-0003 When provisioning symmetric keys, use key derivation for key separation between SAEF and various E2E security options – Rather than repeating provisioning each time Suggested Authors – Qualcomm suggests IDCC introduce changes merging clause 8.4 text in TR-0012 with existing RSPF text in TS-0003 – Qualcomm happy to assist. 18

ARC Impact 19

(ARC Impact) Transport resoruce: – Purpose: receiving for secured requests and returning secured responses request – Content contains the secured request – To: resource-ID of the default 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. response – Content contains the secured response – All usual parameters Suggested Authors – Qualcomm introduce text in TS-0001 & TS-0003, and later in TS

(ARC Impact) Options 1.Virtual Resource – No defined attribute – Single resource on HCSE. All Originators address this single resource – Supported Operations: UPDATE – only supports blocking block and asynchronous non-blocking mode 2.Non-Virtual resource – Attributes are defined: e.g. securedRequest and securedResponse attributes – A new resource is created for each secured request – Supported Operation: CREATE, RETRIEVE – Supports all blocking and non-blocking modes Recommendation: Option 2 - Non-Virtual resource 21

(ARC Impact) Freshness See (SEC Impact) slides on Freshness and sessionE2EPrimitiveKey Generation.Freshness sessionE2EPrimitiveKey Generation TS-0001 Impact – Provide a definition for e2ERand := (e2ERandId, e2ERandExpiry, e2ERandValue) – latestE2ERand attribute in to store e2ERand – In JWE/XML-ENC header Originator’s e2ERandId and HCSE e2ERandId e2ERand parameter (for in-band communication of e2ERand) Suggested Authors: – China Mobile and Qualcomm introduce TS-0001 text, and later in TS

(ARC Impact) Credential Management pairwiseE2EPrimitiveKey Establishment pairwiseE2EPrimitiveKey Establishment – PSK: No impact on TS-0001 – Certificate-Based: Uses resource Details in SEC e2EKey_resource. – NOTE: Impact - new resource and resource procedures MAF: No impact on TS-0001 MAF Remote Provisioning: No Impact on TS-0001 Remote Provisioning 23

(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 1.Either Originator or HCSE can initiate E2E primitive security 2.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. 3.CSEs configured with [e2ePrimitiveSecurityPolicy], specialization of, 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 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 24

AspectSolutionRelative Impact SECARC TransportContent param of primitive acting on MedHigh RepresentationXML/JSON serialization of primitives as chosen by Orig.-- Primitive protection Encryption + integrity protection using XML ENC or JWE with symmetric sessionE2EPrimitiveKey Low FreshnessAdd optional latestE2ERand attribute to def’n for including latest random value provided by corresponding HCSE. Orig e2ERand provided in-band. sessionE2EPrimitiveKey derived from e2ERands + pairwiseE2EPrimitiveKey Med pairwise- E2EPrimitiveKey Establishment PSKLow- Certificate: use resource (see SEC e2EKey_resource) High MAFSlight variation on MAF SAEF gives sessionE2EPrimitiveKeyMed- ProvisioningAs for SAEFsMed- Rules for E2E primitive security 1.Orig or HCSE can insist on E2E Primitive security 2.Once initiated, both must use E2E primitive security 3.e2ePrimitivePolicy: “all” or list of specific end-points LowMed 25