1. Issue regarding authentication at MN-CSE Group Name: ARC & SEC Source: FUJITSU Meeting Date: 2015-11-04 Agenda Item: Security Admin API

2. Introduction Mca and Mcc of Rel-1 specification does not distinguish between user and administrator There are several reasons for separating APIs for administrator from Mca/Mcc. One example is authentication at the MN-CSE which work as registrar.

3. Security procedure Figure 11.3-1. High Level Procedures on Mcc or Mca without MAF Figure 11.3-2. MAF assisted High Level Procedures on Mcc or Mca Since credential information is managed on IN-CSE, registrar MN-CSE has to communicate with IN-CSE or MAF to authenticate Registree node.

4. Bypassing topology may be needed MN-CSE (registrar) ADN-AE (registree) MN-CSE (registrar) IN-CSE Register ADN-AE (registree) Register MAF

5. API to authenticate Input from registree – AE-ID-Stem or CSE-ID – credential – App-ID (+ Role-ID ?) to request Output for registrar – Result of authentication (grant or reject) – Assigned App-ID and/or Role-ID – Access Token to attach on request(optional)

6. ServiceSubscriptionProfile has to collate with credential information for specific AE/CSE ID Authentication procedure for PSK based and public-key based mutual authentication between CSEs, must be specified as part of Rel-2 specification.