e 2 EKey Resource Group Name SEC WG

e 2 EKey Resource Group Name: SEC WG Source: Qualcomm Inc. , Wolfgang Granzow & Phil Hawkes Meeting Date: SEC#20. 3, 2015 -12 -17 Agenda Item: End-to-End Security and Group Authentication

Background • For End-to-End security, we would like to be able to use certificates – E 2 E attribute security (e. g. AE-to-AE, signing tokens) – E 2 E message security (Originator-to-CSE) • Object security protocols – Java. Script 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 E 2 E Attribute security scenarios – Not applicable in E 2 E Message security (always 1 source & 1 target) • However, in many cases (including all E 2 E 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 • – Very low overhead, only requires providing key identifier. – ~1. 3 payload size expansion (mostly due to base 64 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 + (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 • JOSE case: ~1. 8 x payload size expansion, • XML Security: 1. 3 -1. 8 payload size expansion (not entirely sure) • Suggestion: a cert-based mechanism establishing a symmetric key which can be used in both E 2 E attribute security and E 2 E message security. 3

Cert-based pairwise. E 2 EKey establishment • Options for establishing pairwise. E 2 EKey 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 pairwise. E 2 EKey is exported – pairwise. E 2 EPrimitive. Key and pairwise. E 2 EAttribute. Key are derived from pairwise. E 2 EKey • Challenge – How do we do a TLS handshake transported using one. M 2 M 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: • handshake. Type: enum { TLS } • handshake. Message. Number: xs: int order of the current message in the handshake • handshake. Message. Payload: 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 pairwise. E 2 EKey is exported. 5

TLS Messages (Background) Messages TLS Handshake parameters (success case) Description 1 Client. Hello List of supported ciphersuites, random value 2 Server. Hello Selected ciphersuite, random value Certificate Terminating End-Point’s Certificate Server. Key. Exchange Key exchange parameters generated by the Terminating End -Point. Dependent on selected ciphersuite Certificate. Request the Initiating End-Point to authenticate itself with a certificate Server. Hello. Done End of message Certificate Initiating End-Point’s Certificate Client. Key. Exchange Key exchange parameters generated by the Terminating End -Point. Dependent on selected ciphersuite Certificate. Verify Signature by Initiating End-Point (Change. Cipher. Spec*) Signal to start using new keys Finished MIC on handshake messages using session secrets 3 4 * Not really part of the handshake protocol. Investigating if this is needed 6

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

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

Further comments • pairwise. E 2 EKey identifier options 1. 2. Identifier of the created resource Random identifier exported with pairwise. E 2 EKey • 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 e 2 EKey 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 9. 6. 1. 1 -1 Resource Types – Clause 9. 6. 3 Resource Type CSEBase • Add an attribute to which indicates if the CSE can be a terminating endpoint for an handshake. – Clause 9. 6. 5 Resource Type AE • Add an attribute to which indicates if the AE can be a terminating endpoint for handshake. • New clauses – Clause 9. 6. x: Resource Type e 2 EKey – 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 pairwise. E 2 EKey • Suggested Authors – Qualcomm 11

Annex: Some Non-Blocking call flows 12

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

Terminating CSE Case: Synchronous Non-Blocking Mode Initiating End-Point Message (Content) Terminating End-Point (CSE) Generate h 1 • • • CREATE request (TLS, 1, h 1) Parent of created resource is TLS Handshake messages denoted( w/ id xyz ) CREATE response h 1, h 2, h 3, h 4 Flow: Colors show request/response pairs (Repeat while “not complete”) RETRIEVE xyz request (-) RETRIEVE xyz response (not complete ) RETRIEVE xyz request(-) RETRIEVE xyz response (complete ) Create resource 1 w/ id xyz Create w/ (TLS, 1, h 1) Process h 1 and generate h 2, change to (TLS, 2, h 2) Update resource 1 RETRIEVE request (-) RETRIEVE response(TLS, 2, h 2) Process h 2 and generate h 3 UPDATE request (TLS, 3, h 3) 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, h 3) RETRIEVE abc request (-) RETRIEVE abcresp (complete ) Update resource 2 Process h 3 and generate h 4, Change to (TLS, 4, h 4) RETRIEVE request resource 2 (-) RETRIEVE response(TLS, 4, h 4) Process h 4 14

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