SEC2016 0165 TEF interface Specification discussion of the

SEC-2016 -0165 TEF interface Specification discussion of the next steps Group Name: SEC WG Source: Qualcomm Inc. , Phil Hawkes, Wolfgang Granzow Meeting Date: SEC#25, 2016 -10 -17 Agenda Item: WI-0057 -TEF_interface

Objective • At TP#24 the WI-0057 “TEF Interface” was agreed • From this WI, the stage-3 details of the interface between AEs and CSEs with M 2 M Authentication Function (MAF) and M 2 M Enrolment Function (MEF) shall result – Trust Enabling Function (TEF) is a generic term used for MAF and MEF • This presentation recaps the issues related to the TEF interface and proposes a way forward for WI-0057 • Revision R 01: – proposes a new option 3 for modelling of the TEF, see new slides 11 – 14, – slide 18 updated with message flow shown in SEC-2016 -0137 – Proposed way forward when going with option 3 (new slide 22) 2

MAF and MEF Procedures defined in TS-0003 • Remote Security Provisioning Frameworks (RSPF) – Clause 8. 3 in TS-0003 – Certificate Enrolment currently part of this functionality but only partly specified right now • MAF-based security frameworks – – Clause 8. 8 in TS-0003 Clause 8. 2. 2. 3 for MAF-based SAEF Clause 8. 4. 2 for MAF-based ESPrim Currently no text for MAF-based ESData • Remote security frameworks for E 2 E security – Clause 8. 6 in TS-0003 – Referenced on Clause 8. 5. 2. 2. 3 for ESData 3

Entities involved in Remote Security Provisioning Figure 6. 1. 2. 1 -1 in. TS-0003: Field Domain UN-SP Domain GBA BSF (=MEF) 3 rd Party Domain or M 2 M-SP Infrastructure Domain Field or Infrastructure Domain MEF MAF M 2 M Entity A SAEF after RSPF M 2 M Entity B 4

Entities involved in SAEF Figure 6. 1. 2. 2 -1 in. TS-0003: required for “MAF-based SAEF” 5

Entities involved in E 2 E Security Provisioning Figure 8. 6. 1. 23 -1 in. TS-0003: 6

Entities involved in E 2 E Security Provisioning Field Domain 3 rd Party Domain or M 2 M-SP Infrastructure Domain Field or Infrastructure Domain MEF M 2 M Entity A E 2 E secured communication M 2 M Entity B 7

Reference Point Definition Option 1: separate reference points for MAF and MEF Mmef MAF M 2 M Entity A Mmaf M 2 M Entity B 8

Reference Point Definition (option 2) MAF and MEF can be interpreted as two “roles” of the Trust Enabler Function (TEF) node Option 2: single new reference point for TEF Mtef “TEF Client” (AE or CSE) M 2 M Entity A “TEF Server” Mtef M 2 M Entity B “TEF Client” (AE or CSE) 9

Reference Point Definition (Option 2) Option 2 is preferred as it requires definition of a single new reference point only TEF (MEF) Proprietary i/f or Mtef TEF (MAF) M 2 M Entity A Mtef MN(s) Mca or Mcc M 2 M Entity Mca or Mcc B 10

TEF based on CSF approach (option 3) • Define “stand-alone TEF Entity” as a CSE, that supports either i. ii. a new sub-function of the existing SEC CSF, TE sub. CSF a new “Trust Enabling” CSF (TE CSF) CSE i. ) “stand-alone TEF Entity” (MAF or MEF) = other required CSFs CSE ii. ) other CSFs SEC CSF other SEC CSF functions TE sub. CSF For standalone TEF Entity, CSE needs to provide only the minimal set of functionality required by MAF or MEFsupport SEC CSF TE CSF 11

TEF based on CSF approach (option 3) • TEF can also be integral part of a CSE which provides any other services, e. g. IN-CSE SEC CSF CSE with integrated TEF (MAF or MEF) i. ) All other applicable CSFs = CSE ii. ) All other applicable CSFs other SEC CSF functions TE sub. CSF CSE provides any targeted set of functionality, including TEF SEC CSF TE CSF 12

Interface Aspects of option 3 • No need to define any new reference points Example use cases: “stand-alone” TEF Entity (MAF or MEF) Mca Mcc M 2 M Entity A field domain AE field domain CSE Mcc’ Mcc M 2 M Entity field domain CSE IN-CSE B B M 2 M Entity B IN-CSE in different SP’s domain 13

Interface Aspects of option 3 • This approach enables the possibility to use external DM “stand-alone” TEF Entity (MAF or MEF) M. Adapter DM server Mca, Mcc or Mcc’ mc DM client TEF client M 2 M Entity A or B M. Adapter TEF client M 2 M Entity A or B 14

General communication scheme on Mtef • Reusing one. M 2 M RESTful protocol as applied on Mca and Mcc reference points – same communication protocol – Still clarifying if there are different procedures depending on whether TEF takes role of MAF or MEF • Reusing existing request and response primitives – many optional Mcc/Mca primitive parameters/features not required on Mtef (not eliminating future extensions) • Blocking-mode access to server only (non-blocking may be defined in future release) 15

Request Primitive parameters Multiplicity Presence on Mtef m 2 m: operation xs: any. URI m 2 m: ID 1 1 0. . 1 M M O m 2 m: request. ID m 2 m: resource. Type m 2 m: primitive. Content List of m 2 m: role. ID m 2 m: timestamp m 2 m: abs. Rel. Timestamp 1 0. . 1 M O O NA NA NA m 2 m: abs. Rel. Timestamp 0. . 1 NA m 2 m: response. Type. Info m 2 m: abs. Rel. Timestamp 0. . 1 NA NA Default: Use 'blocking. Request' Result Content Event Category Delivery Aggregation m 2 m: result. Content m 2 m: event. Cat xs: boolean 0. . 1 O NA NA New enumeration values tbd Group Request Identifier Filter Criteria Discovery Result Type Tokens Token IDs Local. Token. IDs Token Request Indicator xs: string 0. . 1 NA m 2 m: filter. Criteria m 2 m: disc. Res. Type List of m 2 m: dyn. Auth. JWT 0. . 1 O NA NA List of m 2 m: token. ID List of xs: NCName xs: boolean 0. . 1 NA NA NA Primitive Parameter Operation To From Request Identifier Resource Type Content Role IDs Originating Timestamp Request Expiration Timestamp Result Expiration Timestamp Operation Execution Time Response Type Result Persistence Data Type Notes AE-ID or CSE-ID, if available New resource types on Mtef tbd. NA New filter criteria tbd. 16

Response Primitive parameters Primitive Parameter Response Status Code Data Type m 2 m: response. Status. Code Request Identifier Content To From Originating Timestamp Result Expiration Timestamp Event Category Assigned Token Identifiers Token Request Information m 2 m: request. ID m 2 m: primitive. Content m 2 m: ID m 2 m: timestamp m 2 m: abs. Rel. Timestamp m 2 m: event. Cat m 2 m: dyn. Auth. Local. Token. Id. Assignments m 2 m: dyn. Auth. Token. Req. Info Multiplicity 1 Presence on Mtef 1 0. . 1 M O NA NA M Notes Possibly additional response status codes required tbd 17

Use of MAF Interface 18

TEF Interface Stage 3 Details • Use similar approach as currently applied for separation of Mcc/Mca stage 3 details – Request and response primitives with parameters applicable on Mtef to TEF operations – New resource types hosted by the TEF, structure and data types TS-0004 (Core) • Specification of generic processing at TEF client and server • Specification of procedures specific for new resource types – Reuse bindings to Application layer transport protocols • TS-0008/9/10/20 (HTTP/1. 1, Co. AP, Web. Socket) • Specify “delta” relative to TS-0008/9/20 (if there is any) 19

Documents already presented at TP#24 • SEC-2016 -0131 R 02: TEF interface – Was proposed as new main section of TS-0003 – Not agreed – Triggered the discussion which lead to the creation of the new WI 0057 • SEC-2016 -0138: data types used on TEF i/f – Agreed partially (0138 R 02) as new clause 12 of TS-0003 – Short names related to TEF resource types have been dropped • SEC-2016 -0136: MAF procedures cleanup – agreed • SEC-2016 -0137: MAF stage-3 i/f specification – Not agreed. Text dependent on agreement of 0131 20

Proposed way forward when deciding for option 3 • Add definition of TE sub. CSF to TS-0001, and “stand-alone TEF entity” – Proposed CR in ARC-2016 -0448 R 01 • Define TEF interface in a separate specification – This simplifies the discussion across the involved WGs (SEC, ARC, PRO and MAS) – Proposed skeleton: SEC-2016 -0166 to be revised R 01 – Proposed scope: SEC-2016 -0167 to be revised R 01 – Proposed main body: SEC-2016 -0168 based on SEC-2016 -0131 • to be revised (R 01) <TEF> <CSEBase> • Add parts which were dropped from SEC-2016 -0138 (short names) into new TEF specification • More details on procedures need to be added in TS-0003 – Mapping between MAF/MEF procedures to CRUD procedures defined in the new TEF interface specification (i. e. follow-up on SEC-2016 -0137) 21

Proposed way forward when deciding for option 1 or 2 • Add definition of reference point Mtef to TS-0001 – Proposed CR in ARC-2016 -0448 • Define TEF interface in a separate specification – – This simplifies the discussion across the involved WGs (SEC, ARC and PRO) Proposed skeleton: SEC-2016 -0166 Proposed scope: SEC-2016 -0167 Proposed main body: SEC-2016 -0168 based on SEC-2016 -0131 • Add parts which were dropped from SEC-2016 -0138 (short names) into new TEF specification • More details on procedures need to be added in TS-0003 – Mapping between MAF/MEF procedures to CRUD procedures defined in the new TEF interface specification (i. e. follow-up on SEC-2016 -0137) 22