E 2 E Attribute Parameter Security Group

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

Background • • Strict deadline for stage 2 details At TP#20, it was agreed that securing application data (e. g. AE-to-AE) is one of SEC’s priority Security would also be needed for signing self-contained access tokens in tokenbased dynamic authorization proposals Requires securing all or part of an attribute (e. g. content in <content. Instance>) or a primitive parameter (e. g. a signed access token) so CSEs do not need to be trusted with the data in that attribute/parameter – AE-to-AE E 2 E security can be done without impacting one. M 2 M…but a standard can help – Secured parameters/attributes which are processed by CSEs (such as self-contained access tokens) need standardization • • For simplicity we call this “E 2 E Attribute and Parameter Security” This presentation looks at what we need to do (challenges) in SEC & ARC – Overview first, then SEC impact, then ARC impact • R 01: – New slides have NEW in top left corner. – Changed/New text in existing slides are shown in green font 2

Overview of Challenges Aspect Solution Payload Protection Options based on PSK, TEF, Certificates Credential Management Extend existing Remote Security Provisioning Framework (RSPFs) Interactions with a TEF Options for using Certificates in non-RSPF scenarios: 1. Used directly in JOSE or XML ENC/SIG 2. Using <e 2 EKey> resource to establish symmetric key (see SEC-2015 -0677 -e 2 EKey_resource). More efficient than (1). Changes to resource descriptions Obtaining other AE’s certificates Which attributes and primitive parameters may have secured data? Security Info to associate w/ secured data in attributes 3

On Group Authentication? • Group Authentication is for protecting from Originator to Hosting CSE: – This is primitive security, not AE-AE security – Addressed in “E 2 E primitive security” contribution 4

SEC Impact 5

NEW (SEC) JOSE, XML SEC • JSON Security: JOSE – Java. Script 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 – Extended by IETF CBOR Object Signing and Encryption (cose) specifications in near future: https: //datatracker. ietf. org/wg/cose/charter/ • 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 • Stage 2 = working out which type of security we want – Next Slide • Stage 3 = crypto profiles 6

(SEC) Options Class ID Description Target Key mgmt Source Verification JWE / E. 1 XML E. 2 ENC options E. 3 AEAD w/ PSK* PSK Symmetric - CM/QCOM AEAD w/ TEF Symmetric - IDCC AEAD w/ Target Cert - QCOM JWS / S. 1 XML SIG S. 2 options S. 3 MIC using PSK* - Symmetric - CM/QCOM MIC using TEF - Symmetric - IDCC Cert QCOM E. 1 + AEAD w/ PSK S. 2 Dig. Sig w/ Source Cert E. 2 + AEAD w/ TEF S. 2 Dig. Sig w/ Source Cert QCOM (mostly referring to above text) E. 1 + AEAD w/ Target Cert S. 2 Dig. Sig w/ Source Cert Sensible C. 1 JOSE/ XML SEC C. 2 combinations C. 3 Dig. Sig w/ Source Cert - Non- Qualcomm Repudi suggested -ation text authors - * PSK could be established via remote provisioning or <e 2 EKey> using certs 7

(SEC) Remote Security Provisioning • Extend Remote Security Provisioning Frameworks to support provisioning for AE-AE security – Minor updates to RSPF – Not too much detailed specification required – IDCC has already introduced this to TR-0012 (clause 8. 4) • Qualcomm suggests this be merged with existing RSPF text • When provisioning symmetric keys, use key derivation for key separation between SAEF and various E 2 E security options – Rather than repeating provisioning each time • Suggested Authors – Qualcomm suggests IDCC produce contributions to incorporate that text into TS-0003 – Qualcomm happy to assist. 8

(SEC) Interactions w/ TEF • IDCC has already introduced this to TR-0012 (clause 8. 3) • Suggested Authors – Qualcomm suggests IDCC produce contributions to incorporate that text into TS-0003 • Qualcomm happy to assist. 9

NEW (SEC) Certificate Details • Certificate can be used in a variety of ways – Remote Provisioning of PSK (See TS-0003 8. 3. 2. 2). Already discussed – <e 2 EKey> exchange to establish PSK. • “Remote provisioning without MEF” • See SEC-2015 -0677 -e 2 EKey_resource – Use directly with JOSE or XML SEC • Signature only – no confidentiality: (JWS/XML SIG only) • Encryption only – no source authentication: (JWE / XML ENC only) • Nested Sign-then-Encrypt (JWS then JWE or XML SIG then XML ENC) • Specified in the JOSE and XML SEC specifications. Minimal text needed in text in TR-0003. Suggested Authors: Qualcomm 10

ARC Impact 11

(ARC) Obtaining other AE Certs (1) • Background – When certificates used directly in JOSE or XML SEC, then there is no handshake • Source AE needs Target AE’s cert prior to securing data • Including Source AE cert in each message increases message size. – Best to allow AEs to retrieve each other’s certificates • Problem: How do AEs retrieve other AEs' certificates? • Options: to consider A. Stored at a standard location at M 2 M SP’s IN-CSE. • • B. C. • • Good for “non-local” AEs and IN-AEs. Good for centralized systems, not so good otherwise Stored in <AE> resource at Registrar CSE Good for “local” AEs Good for less-centralized systems Support both! 12

(ARC) Obtaining other AE Certs (2) • Proposal – ARC TS-0001 Detail • <AE> resource at Registrar CSE includes an optionally attribute which contains either – Certificates OR – Resource ID where Certificates can be retrieved – SEC TS-0003 Detail • Within secured attributes/parameters being exchanged, include certificate hash and resource ID where Certificate and chain can be retrieved • Doesn’t require much text • Qualcomm is happy to introduce changes to TS-0001 & TS-0003 13

(ARC) Which attributes can contain secured data? • Which attributes can contain secured data? – Attributes that are not processed by the Hosting CSE. – If one. M 2 M wants an attribute to be securable, then the attribute needs to support "xs: string“ • This may require changing the data type of the attribute • Current plan is to allow securing the current attributes – – content in <content. Instance>. content. Already meets constraints object. Attribute in <mgmt. Obj> specializations. Provided constraints met custom. Attribute in <flex. Container> specializations, provided constraints met Dynamic authorization may require authorizations (e. g. <token. Value> in Datang’s <token> resources) to be signed and optionally encrypted • These resources are still be discussed – resource and attribute names may change • Qualcomm is happy to introduce changes to TS-0001 14

NEW (ARC) Which primitive parameters can contain secured data? • Which primitive parameters can contain secured data? – If one. M 2 M wants an primitive parameter to be securable, then the attribute needs to support "xs: string“ • This may require changing the data type of the parameter • Dynamic authorization support self-contained access tokens containing authorization descriptions, and which are signed and optionally encrypted – These could be transported from the Originator to HCSE in a primitive parameter with the request being authorized • Qualcomm is happy to introduce changes to TS-0001 15

(ARC) Security Info to associate w/ secured attributes • Providing useful information about attributes w/ secured data – SEC action: what information would be useful? • Unclear if Security Protocol can be indicated using media type (e. g. in content. Info) – see question to ARC below. So security Protocol may, or may not, need to be indicated. • Information intended recipient AEs can use to work out if they will be able to decrypt – Details would be application specific and out of scope – Series of “hints”…. Could “labels” be used for this? • Anything else? – ARC action: best way to include this information in a resource • Should content. Info refer to media type of encapsulating object (e. g. application/jose or application/xenc+xml) or the content inside? Is a new attribute needed to describe this? • Extend content. Info? New attribute(s)? • If seen as worthwhile by SEC, Qualcomm is happy to introduce discussion in ARC (not quite ready for text yet) 16

Specification Impact and Suggested Authors Challenge Impact Suggested text authors ARC Payload Protection Options based on PSK, TEF, Certificates Credential Remote Credential Provisioning Management Interactions with a TEF SEC - High See this slide - Med IDCC [QC] - High Options for using Certificates in non-RSPF High QC scenarios: 1. Used directly in JOSE or XML ENC/SIG 2. Using <e 2 EKey> resource to establish symmetric key (see SEC-2015 -0677 e 2 EKey_resource). More efficient than (1). Changes to resource descriptions Obtaining other AE’s certificates Low - Which attr/param may have secured data? Low - Security Info to associate w/ secured data - Low QC 17