e2EKey Resource Group Name: SEC WG Source: Qualcomm Inc., Wolfgang Granzow & Phil Hawkes Meeting Date: SEC#20.3, Agenda Item: End-to-End Security and Group Authentication

Background For End-to-End security, we would like to be able to use certificates – E2E attribute security (e.g. AE-to-AE, signing tokens) – E2E message security (Originator-to-CSE) Object security protocols – JavaScript Object Signing and Encryption (JOSE) IETF WG: JSON Web Signature (JWS), JSON Web encryption (JWE) – XML Encryption and XML Signature. These protocols support multiple target end-points – Applicable to some E2E Attribute security scenarios – Not applicable in E2E Message security (always 1 source & 1 target) However, in many cases (including all E2E message security scenarios), there is 1 source and 1 target – This contribution targets only these use cases 2

JWE, XML ENC JWE and XML ENC support Authenticated Encryption with additional data (AEAD) – includes integrity protection AEAD between two parties 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 and XML ENC using certificates does not authenticate the sender – Can use additional layer of JWS or XML SIG, but this further bloats the size of messages – Estimate: 1400 bytes overhead + JOSE case: ~1.8x payload size expansion, XML Security: payload size expansion (not entirely sure) Suggestion: a cert-based mechanism establishing a symmetric key which can be used in both E2E attribute security and E2E message security. 3

Cert-based pairwiseE2EKey establishment Options for establishing pairwiseE2EKey using certificates – Devise our own handshake using JWE/JWS or XML ENC/SIG JWE/JWS and XML/ENC/SIG wasn’t really intended for this We are 100% guaranteed to do something wrong – Use something we are familiar with Certificate-based TLS handshake, from which pairwiseE2EKey is exported – pairwiseE2EPrimitiveKey and pairwiseE2EAttributeKey are derived from pairwiseE2EKey Challenge – How do we do a TLS handshake transported using oneM2M requests and responses? 4

Proposal Resource. – Used as an “inbox” for exchanging handshake messages Initially intended for TLS – allow extending to other handshakes if desired – Attributes: handshakeType: enum { TLS } handshakeMessageNumber: xs:int order of the current message in the handshake handshakeMessagePayload: the latest exchanged message Handshake initiator begins by creating an resource. – Parent resource depends on Terminating end-point, If Terminating End-point is a CSE, then parent resource is of that CSE If Terminating End-point is a AE, then parent resource is on Terminating End-Point’s Registrar CSE – CREATE triggers and exchange of TLS Handshake messages between the Initiating and Terminating End-points using the attributes of the resource – If handshake completes, then pairwiseE2EKey is exported. 5

TLS Messages (Background) MessagesTLS Handshake parameters (success case) Description 1 ClientHello List of supported ciphersuites, random value 2 ServerHello Selected ciphersuite, random value Certificate Terminating End-Point’s Certificate ServerKeyExchange Key exchange parameters generated by the Terminating End- Point. Dependent on selected ciphersuite CertificateRequest Request the Initiating End-Point to authenticate itself with a certificate ServerHelloDone End of message 3 Certificate Initiating End-Point’s Certificate ClientKeyExchange Key exchange parameters generated by the Terminating End- Point. Dependent on selected ciphersuite CertificateVerify Signature by Initiating End-Point (ChangeCipherSpec*) Signal to start using new keys Finished MIC on handshake messages using session secrets 4 (ChangeCipherSpec*) Signal to start using new keys Finished MIC on handshake messages using session secrets 6 * Not really part of the handshake protocol. Investigating if this is needed

Terminating End-Point = CSE: Flow 1 Parent of created resource is TLS Handshake messages denoted h1, h2, h3, h4 Flow: Colors show request/response pairs Non-block mode shown here. Blocking modes shown in Annex 7 Initiating End-PointMessage (Content)Terminating End-Point (CSE) Generate h1  CREATE request (TLS,1,h1)  Create resource Process h1 and generate h2, change attributes  CREATE response (TLS,2,h2)  Process h2 and generate h3  UPDATE request (TLS,3,h3)  Change attributes Process h3 and generate h4, change resource contents  UPDATE response (TLS,4,h4)  Process h4

Terminating End-Point = AE: Flow 1 Parent resource is on Terminating End-Point’s Registrar CSE. Colors show request/response pairs. Terminating End-Point is presumed to support NOTIFY 8 Initiating End- Point Message (Content)Registrar CSE Message (Content)Terminating End-Point (AE) Gen h1 Normal CRUDN behavior  CREATE request (TLS,1,h1)   NOTIFY 1 request (TLS,1,h1)   NOTIFY response (-)  Process h1, gen h2  UPDATE request (TLS,2,h2)   CREATE response (TLS,2,h2)  Process h2, gen h3  UPDATE request (TLS,3,h3)   UPDATE response (TLS,3,h3)  Process h3, gen h4  UPDATE request (TLS,4,h4)   UPDATE response (TLS,4,h4)  UPDATE response (-)  Process h4 Export pairwiseE2EKey 1. If notification is not supported by Terminating End-Point AE, then Terminating End-Point AE can periodically check if an has been created. This flow assumes that the Terminating End-Point AE subscribed to be notified when children of its resource are created.

Further comments pairwiseE2EKey identifier options 1.Identifier of the created resource 2.Random identifier exported with pairwiseE2EKey For ARC consideration: Behavior of CSE changes depending on whether the CSE is the Terminating end-point, or a registered AE is the Terminating end-point – Might make sense to have two distinct resource types for e2EKey functionality; One resource type for when CSE is the Terminating end-point, and One resource type for when a registered AE is the Terminating end-point. – This is an ARC specification detail – makes no difference to SEC specifications – For now assuming it is OK to have a single resource type 9

ARC Impact: TS-0001 Update to existing text – Table Resource Types – Clause Resource Type CSEBase Add an attribute to which indicates if the CSE can be a terminating end- point for an handshake. – Clause Resource Type AE Add an attribute to which indicates if the AE can be a terminating end- point for handshake. New clauses – Clause 9.6.x: Resource Type e2EKey – Clause 10.2.y: resource procedures – NOTE: For now assuming it is OK to have a single resource type. See discussion on previous slide. Suggested Authors: – Qualcomm 10

SEC Impact TS-0003 Stage 2 – Specify sequence of TLS handshake messages exchanged and processing at end-points. Stage 3 – TLS ciphersuites – Certificate profiles – Details for exporting pairwiseE2EKey Suggested Authors – Qualcomm 11

Annex: Some Non-Blocking call flows 12

Terminating CSE Case: Synchronous Non-Blocking Mode Parent of created resource is TLS Handshake messages denoted h1, h2, h3, h4 Flow: Colors show request/response pairs 13 Initiating End-PointMessage (Content)Terminating End-Point (CSE) Generate h1  CREATE request (TLS,1,h1)  Create resource  CREATE response (-)  Process h1 and generate h2, change attributes  NOTIFY 1 request (TLS,2,h2)   NOTIFY response (-)  Process h2 and generate h3  UPDATE request (TLS,3,h3)  Change attributes  UPDATE response (-)  Process h3 and generate h4, change attributes  NOTIFY response (TLS,4,h4)   NOTIFY response (-)  Process h4 1. AE are not required to support NOTIFY. This would only work for Initiating End-Points which are CSEs or AE supporting NOTIFY

Terminating CSE Case: Synchronous Non-Blocking Mode Parent of created resource is TLS Handshake messages denoted h1, h2, h3, h4 Flow: Colors show request/response pairs 14 Initiating End-PointMessage (Content)Terminating End-Point (CSE) Generate h1  CREATE request (TLS,1,h1)  Create resource 1 w/ id xyz  CREATE response ( w/ id xyz )  (Repeat while “not complete”)  RETRIEVE xyz request (-)   RETRIEVE xyz response (not complete )  Create w/ (TLS,1,h1) Process h1 and generate h2, change to (TLS,2,h2)  RETRIEVE xyz request(-)   RETRIEVE xyz response (complete )  Update resource 1  RETRIEVE request (-)   RETRIEVE response(TLS,2,h2)  Process h2 and generate h3  UPDATE request (TLS,3,h3)  Create resource 2 w/ id abc  UPDATE resp ( w/ id abc )  (Repeat while “not complete”)  RETRIEVE abc request (-)   RETRIEVE abc response (not complete )  change to (TLS,3,h3) Process h3 and generate h4, Change to (TLS,4,h4)  RETRIEVE abc request (-)   RETRIEVE abcresp (complete )  Update resource 2  RETRIEVE request resource 2 (-)   RETRIEVE response(TLS,4,h4)  Process h4

Terminating AE Case: Asychronous Non-Blocking Mode 15 Initiating End- Point Message (Content)Registrar CSE Message (Content)Terminating End- Point Gen h1 Normal CRUDN behavior  CREATE req (TLS,1,h1)   CREATE resp (-)  NOTIFY 1 req (TLS,1,h1)   NOTIFY resp (-)  Process h1, gen h2  UPDATE req (TLS,2,h2)   NOTIFY 2 req (TLS,2,h2)  UPDATE resp (-)   NOTIFY request (-)  Process h2, gen h3  UPDATE req (TLS,3,h3)   UPDATE resp (-)  NOTIFY req (TLS,3,h3)   NOTIFY resp (-)  Process h3, gen h4,  UPDATE req (TLS,4,h4)   NOTIFY req (TLS,4,h4)  UPDATE resp (-)   NOTIFY resp (-)  Process h4 Export pairwiseE2EKey 1: If notification is not supported by Terminating End-Point AE, then Terminating End-Point AE can periodically check if an has been created 2. AE are not required to support NOTIFY. This would only work for Initiating End-Points which are CSEs or AE supporting NOTIFY