Presentation is loading. Please wait.

Presentation is loading. Please wait.

E2EKey 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.

Published byCleopatra Ward Modified over 9 years ago

Similar presentations

Presentation on theme: "E2EKey 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."— Presentation transcript:

1 e2EKey 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

2 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

3 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: 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 E2E attribute security and E2E message security. 3

4 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

5 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

6 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

7 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

8 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.

9 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

10 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 end- point for an handshake. – Clause 9.6.5 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

11 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

12 Annex: Some Non-Blocking call flows 12

13 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

14 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

15 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

Download ppt "E2EKey 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."

Similar presentations

SSL/TLS Protocol Network Security Gene Itkis. Basic paradigmatic application: on-line purchase Client contacts Server (possibly for the first time) Spontaneity.

SSL/TLS Protocol Network Security Gene Itkis. Basic paradigmatic application: on-line purchase Client contacts Server (possibly for the first time) Spontaneity.
CMDH Refinement Contribution: oneM2M-ARC-0397

CMDH Refinement Contribution: oneM2M-ARC-0397
1 Lecture 12 SSL/TLS (Secure Sockets Layer / Transport Layer Security) CIS 4362 - CIS 5357 Network Security.

1 Lecture 12 SSL/TLS (Secure Sockets Layer / Transport Layer Security) CIS CIS 5357 Network Security.
TLS. 14.1 Introduction 14.2 TLS Record Protocol 14.3 TLS Handshake Protocol 14.4 Summary.

TLS Introduction 14.2 TLS Record Protocol 14.3 TLS Handshake Protocol 14.4 Summary.
Secure Socket Layer.

Secure Socket Layer.
SSL CS772 Fall 2011. Secure Socket layer Design Goals: SSLv2) SSL should work well with the main web protocols such as HTTP. Confidentiality is the top.

SSL CS772 Fall Secure Socket layer Design Goals: SSLv2) SSL should work well with the main web protocols such as HTTP. Confidentiality is the top.
17.1 Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. Chapter 17 Security at the Transport Layer: SSL and TLS.

17.1 Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. Chapter 17 Security at the Transport Layer: SSL and TLS.
Working Connection Computer and Network Security - SSL, IPsec, Firewalls – (Chapter 17, 18, 19, and 23)

Working Connection Computer and Network Security - SSL, IPsec, Firewalls – (Chapter 17, 18, 19, and 23)
1 SSL/TLS 2 Web security Security requirements Secrecy to prevent eavesdroppers to learn sensitive information Entity authentication Message authentication.

1 SSL/TLS 2 Web security Security requirements Secrecy to prevent eavesdroppers to learn sensitive information Entity authentication Message authentication.
Transport Layer Security (TLS) Protocol Introduction to networks and communications(CS555) Prof : Dr Kurt maly Student:Abhinav y.

Transport Layer Security (TLS) Protocol Introduction to networks and communications(CS555) Prof : Dr Kurt maly Student:Abhinav y.
December 2006Prof. Reuven Aviv, SSL1 Web Security with SSL Prof. Reuven Aviv Dept. of Computer Science Tel Hai Academic College.

December 2006Prof. Reuven Aviv, SSL1 Web Security with SSL Prof. Reuven Aviv Dept. of Computer Science Tel Hai Academic College.
Problem of non-Blocking Synchronous mode Group Name: ARC WG Source: Yuan Tao, Mitch Tseng, Huawei Technologies Meeting Date: ARC 15.0 Agenda Item: TBD.

Problem of non-Blocking Synchronous mode Group Name: ARC WG Source: Yuan Tao, Mitch Tseng, Huawei Technologies Meeting Date: ARC 15.0 Agenda Item: TBD.
Mar 19, 2002Mårten Trolin1 This lecture On the assignment Certificates and key management SSL/TLS –Introduction –Phases –Commands.

Mar 19, 2002Mårten Trolin1 This lecture On the assignment Certificates and key management SSL/TLS –Introduction –Phases –Commands.
Apr 2, 2002Mårten Trolin1 Previous lecture On the assignment Certificates and key management –Obtaining a certificate –Verifying a certificate –Certificate.

Apr 2, 2002Mårten Trolin1 Previous lecture On the assignment Certificates and key management –Obtaining a certificate –Verifying a certificate –Certificate.
EECC694 - Shaaban #1 lec #16 Spring2000 5-4-2000 Properties of Secure Network Communication Secrecy: Only the sender and intended receiver should be able.

EECC694 - Shaaban #1 lec #16 Spring Properties of Secure Network Communication Secrecy: Only the sender and intended receiver should be able.
Secure password-based cipher suite for TLS: The importance of end-to-end security Marie L.S. Dumont CS 265.

Secure password-based cipher suite for TLS: The importance of end-to-end security Marie L.S. Dumont CS 265.
Diameter End-to-End Security: Keyed Message Digests, Digital Signatures, and Encryption draft-korhonen-dime-e2e-security-00 Jouni Korhonen, Hannes Tschofenig.

Diameter End-to-End Security: Keyed Message Digests, Digital Signatures, and Encryption draft-korhonen-dime-e2e-security-00 Jouni Korhonen, Hannes Tschofenig.
Announcement Final exam: Wed, June 9, 9:30-11:18 Scope: materials after RSA (but you need to know RSA) Open books, open notes. Calculators allowed. 1.

Announcement Final exam: Wed, June 9, 9:30-11:18 Scope: materials after RSA (but you need to know RSA) Open books, open notes. Calculators allowed. 1.
On Persistent AE Identifiers Group Name: SEC#12.2 Source: Phil Hawkes, Qualcomm Inc (TIA), Francois Ennesser,

On Persistent AE Identifiers Group Name: SEC#12.2 Source: Phil Hawkes, Qualcomm Inc (TIA), Francois Ennesser,
11 Secure Sockets Layer (SSL) Protocol (SSL) Protocol Saturday, 08.05. 2010 University of Palestine Applied and Urban Engineering College Information Security.

11 Secure Sockets Layer (SSL) Protocol (SSL) Protocol Saturday, University of Palestine Applied and Urban Engineering College Information Security.

Similar presentations

Ads by Google