e2EKey Resource

Group Name: SEC WGSource: Qualcomm Inc., Wolfgang Granzow & Phil HawkesMeeting Date: SEC#20.3, 2015-12-17Agenda 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: 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

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• <e2EKey> 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 <e2EKey> resource. – Parent resource depends on Terminating end-point,

• If Terminating End-point is a CSE, then parent resource is <CSEBase> of that CSE

• If Terminating End-point is a AE, then parent resource is <AE> 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 <e2EKey> resource

– If handshake completes, then pairwiseE2EKey is exported.

5

TLS Messages (Background)Messages TLS 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 secrets6

* Not really part of the handshake protocol. Investigating if this is needed

Terminating End-Point = CSE: Flow 1• Parent of created resource is <CSEBase>• 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-Point Message (Content) Terminating End-Point (CSE)Generate h1

CREATE request (TLS,1,h1)

Create <e2EKey> resource

Process h1 and generate h2, change <e2EKey> attributes

CREATE response (TLS,2,h2)

Process h2 and generate h3

UPDATE request (TLS,3,h3)

Change <e2EKey> 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 <AE> 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)

NOTIFY1 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

Export pairwiseE2EKey

1. If notification is not supported by Terminating End-Point AE, then Terminating End-Point AE can periodically check if an <e2EKey> has been created. This flow assumes that the Terminating End-Point AE subscribed to be notified when children of its <AE> resource are created.

Further comments• pairwiseE2EKey identifier options

1. Identifier of the created resource2. 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 <e2EKey>

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 <CSE> which indicates if the CSE can be a terminating end-point for an <e2EKey> handshake.

– Clause 9.6.5 Resource Type AE• Add an attribute to <AE> which indicates if the AE can be a terminating end-

point for <e2EKey> handshake.• New clauses

– Clause 9.6.x: Resource Type e2EKey– Clause 10.2.y: <e2EKey> resource procedures – NOTE: For now assuming it is OK to have a single resource type

<e2EKey>. 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 <e2EKey> call flows

12

Terminating CSE Case: Synchronous Non-Blocking Mode

• Parent of created resource is <cseBase>• TLS Handshake messages denoted h1, h2, h3, h4 • Flow: Colors show request/response pairs

13

Initiating End-Point Message (Content) Terminating End-Point (CSE)Generate h1

CREATE request (TLS,1,h1)

Create <e2EKey> resource

CREATE response (-)

Process h1 and generate h2, change <e2EKey> attributes

NOTIFY1 request (TLS,2,h2)

NOTIFY response (-)

Process h2 and generate h3

UPDATE request (TLS,3,h3)

Change <e2EKey> attributes

UPDATE response (-)

Process h3 and generate h4, change <e2EKey> 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 <cseBase>• TLS Handshake messages denoted h1, h2, h3, h4 • Flow: Colors show request/response pairs

14

Initiating End-Point Message (Content) Terminating End-Point (CSE)Generate h1

CREATE <e2EKey> request (TLS,1,h1)

Create <request> resource 1 w/ id xyz

CREATE response ( <request> w/ id xyz )

(Repeat while “not complete”) RETRIEVE xyz request (-)

RETRIEVE xyz response (not complete )

Create <e2EKey> w/ (TLS,1,h1)

Process h1 and generate h2, change <e2EKey> to (TLS,2,h2)

RETRIEVE xyz request(-) RETRIEVE xyz response (complete )

Update <request> resource 1

RETRIEVE <e2EKey> request (-)

RETRIEVE <e2EKey> response(TLS,2,h2)

Process h2 and generate h3

UPDATE <e2EKey> request (TLS,3,h3)

Create <request> resource 2 w/ id abc

UPDATE <e2EKey> resp ( <request> w/ id abc )

(Repeat while “not complete”) RETRIEVE abc request (-)

RETRIEVE abc response (not complete )

change <e2EKey> to (TLS,3,h3)

Process h3 and generate h4,Change <e2EKey> to (TLS,4,h4)

RETRIEVE abc request (-) RETRIEVE abcresp (complete )

Update <request> resource 2

RETRIEVE request <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 <e2EKey> req (TLS,1,h1)

CREATE <e2EKey> resp (-) NOTIFY1 <e2EKey> req (TLS,1,h1)

NOTIFY <e2EKey> resp (-)

Process h1, gen h2

UPDATE <e2EKey> req (TLS,2,h2)

NOTIFY2 <e2EKey> req (TLS,2,h2) UPDATE <e2EKey> resp (-)

NOTIFY <e2EKey> request (-)

Process h2, gen h3

UPDATE <e2EKey> req (TLS,3,h3)

UPDATE <e2EKey> resp (-) NOTIFY <e2EKey> req (TLS,3,h3)

NOTIFY <e2EKey> resp (-)

Process h3, gen h4,

UPDATE <e2EKey> req (TLS,4,h4)

NOTIFY <e2EKey> req (TLS,4,h4) UPDATE <e2EKey> resp (-)

NOTIFY <e2EKey> resp (-)

Process h4

Export pairwiseE2EKey Export pairwiseE2EKey1: If notification is not supported by Terminating End-Point AE, then Terminating End-Point AE can periodically check if an <e2EKey> has been created2. AE are not required to support NOTIFY. This would only work for Initiating End-Points which are CSEs or AE supporting NOTIFY