On Persistent AE Identifiers Group Name SEC 12 2

On Persistent AE Identifiers Group Name: SEC#12. 2 Source: Phil Hawkes, Qualcomm Inc (TIA), phawkes@qti. qualcomm. com Francois Ennesser, Gemalto NV, Francois. Ennesser@gemalto. com Meeting Date: 2014 -09 -10 Agenda Item: TBD

Overview • Background: What information matters when an AE/CSE asks “which AE will receive this data” or “which AE sent this data”? • Problem: CSE-relative AE-ID might change even though (from perspective of other AEs/CSEs) this is still “the same AE” • Proposal: – Persistent AE Identifiers, – Mapping from AE-ID to persistent AE Identifiers stored in m 2 m. Service. Subscription. – Credential Ids are a special type of persistent AE Identifier 2

Interactions with an AE • Interaction Mechanisms (aside from Registration) – AE initiates CRUD Ops on resources on various CSE – CSEs send notifications to AE • Other AEs and CSEs use these mechanisms to exchange data with an AE • An AE/CSE may need to know – Which AE will receive data sent by the AE/CSE – Which AE provided the data received by the AE/CSE • A CSE also needs to know which AE originated a CRUD request - for access. Control. Policy processing 3

What information matters? • When an AE/CSE asks “Which AE will receive this data”, what information does it really care about? • Alternatively, if – At time T 1, the AE receiving the data fits description A – At time T 2, the AE receiving the data fits description B what changes between descriptions A and B are important to the AE/CSE asking the question? • The answer probably changes from one deployment to another!!! – Even worse – two AE/CSEs in a single deployment might care about different information about the AE!!!!! • Note: same for “Which AE provided data…? ” 4

Examples of information that matters • Topological description: e. g. who is Registrar CSE? MN? • AE Implementation/execution description – Machine within which AE SW is executing (real, virtual, cloud) – SW implementing the AE functionality – AE-specific state context where single SW instance is used for multiple AEs • Deployment-specific description e. g. purpose, room location • GPS coordinates of device hosting AE or Registrar CSE • Other? • Combinations of above! • Note: Description could mean an ID and/or human-readable description and/or machine readable description 5

Currently Defined AE-IDs • AE registers with Registrar CSE to obtain an CSE-relative-AEID that lasts for multiple primitive exchanges. Registrations expire if not renewed – SP-relative AE-ID is concatenation of CSE-relative-AE-ID and CSEIDs on path • SP-relative AE-ID might change even though (from perspective of other AEs/CSEs) this is still “the same AE”. – CSE-relative-AE-ID may change • Registration may expire, new CSE-relative AE-ID assigned on newregistration. • Registrar CSE may be replaced. • AE is replaced. – CSE-ID of Registrar CSE may change • Existing Registrar may have its CSE-ID changed. • Registrar CSE may be replaced. – Combinations of above 6

Inconvenience when AE-ID changes but this is “the same AE” • Following resources require updating with new AE-ID if they included old AE-ID: – – (for notifications) (e. g. for fan-out) • The Registrar CSE’s security “database” needs to be updated so that credential associated with old AE-ID is associated with new AE-ID – This would be required anyway when replacing AE. But this is an inconvenience if registration had simply expired. 7

Persistent AE Identifiers • Suppose AE could be assigned one or more persistent identifier unique within scope of M 2 M SP • Mapping persistent identifiers current AE-ID of AEs could be provided in resource – Interaction with registration • resource is updated with current AE-ID following registration of AE • Subscriber may be contacted to verify which persistent identifiers should be associated with the AE-ID. • Persistent identifier may have been pre-assigned or generated as needed. Managed by M 2 M SP. • Registrar CSE is provided with appropriate service subscription info (e. g. persistent AE identifiers and roles) – Authorized CSEs/AEs can query resource to find this mapping 8

How would persistent AE Identifiers be used? • Where primitives (e. g. to/fr) and common resource attributes of resources currently use AE-ID, they can continue to use AE-ID – AE/CSE can query to determine mapping between AE-ID and persistent AE identifiers • In addition to , the following resources can use persistent identifiers – – (for notifications) – (e. g. for fan-out) • More details in back-up slides 9

Aside: Does AE have to authenticate? • Eventually, we need to choose one of the following positions 1. “AE shall have credentials. AEs that do not have credentials will be granted no access to a one. M 2 M system” 2. “It is acceptable for AE to not have credentials. It is up to deployments to decide what access is granted to un-authenticated AE”. • It is probably OK to defer that discussion to another meeting. Following discussion considers only those AEs with credentials. 10

Authentication & Identification • When Registrar CSE establishes an authenticated TLS session with an AE using a credential and issues an AE-ID, … • …then Registrar CSE needs to update the AE-ID in the appropriate at INCSE – Challenge: How does Registrar CSE tell IN-CSE which and which AE in that should be associated with this AE-ID? • Authentication mechanisms include credential IDs which are a special kind of persistent AE Identifier 11

Authentication and Credential IDs • Provisioned Key (Kpsa): – Registrar provisioned with Kpsa and Kpsa. ID = xyz. – During auth’n, AE Registrar: Kpsa. ID = xyz • MAF-based – During auth’n, MAF Registrar: key, Km. ID = xyz. • GBA-based – During auth’n, BSF Registrar: key, HLR/HSS =abc, persistent id =xyz (previously configured to HLR/HSS by 3 GPP/3 GPP 2 subscriber • Raw. Public. Key certificate – During auth’n AE Registrar: Raw. Public. Key • Other Certificate: – Certificate contains somw identifier = xyz, and chains to trust anchor = abc. More discussion here in backup slides. • Presume M 2 M Service Subscriber knows which AE has these credential identifiers • More discussion on credential identifiers here in backup slides 12

Proposal • Allow persistent AE Identifiers – resource and processing needs updating – Process for other CSE & AE to obtain mapping between AEID and persistent AE Identifiers – , , updated to allow persistent AEs. • Allow credential IDs – resource and processing needs updating • There are probably open issues – but this seems a good step forward! 13

BACKUP SLIDES 14

Using AE-ID & Persistent AE-ID (1) • Update AE-ID in at IN-CSE – Registrar CSE updates IN-CSE with AE-ID • Identification of AE in AE-originated CRUD requests, so other entities know who generated data. – CRUD Requests use AE-ID – Registrar verifies AE-ID before forwarding/processing CRUD Requests – Other entities synch w/ IN-CSE for mapping AE-ID persistent IDs • Identification of AE in CRUD responses, so other entities know that their data was sent to the correct AE – CRUD Responses use AE-ID – Other entities synch w/ IN-CSE for mapping persistent IDs AE-ID – All entities deliver according to AE-ID , Delivery fails if AE-ID expired 15

Using AE-ID & Persistent AE-ID (2) • With (for notification) and resources for (fan-out and fan-in). – and can include persistent IDs and/or AE-IDs – Host CSE synch w/ IN-CSE for mapping persistent IDs AE-ID – CRUD(N) Requests/responses use AE-ID. – All entities deliver according to AE-ID. Delivery fails if AE-ID expired • (ACP) processing – ACP resource may use a persistent ID and/or AE-ID – ACP host CSE receives CRUDN Requests using AE-ID – ACP host CSE synch w/ IN-CSE for mapping AE-ID persistent IDs , – ACP host CSE apply processing using AEID and persistent IDs 16

Certificate Chain Examples • Device Certificate: – Certificate contains hardware instance identifier = xyz, and chains to trust anchor = abc. • Whether used for single AE or multiple AE is for another discussion. – Registrar may provide the entire certificate chain or just summary • Presume Subscriber knows which device has hardware instance identifier = xyz • (FFS) Persistent AE Identifier Certificate (issued by M 2 M SP) – Certificate contains persistent AE identifier = xyz and chains to trust anchor = M 2 M SP • Presume Subscriber knows which AE has persistent AE identifier = xyz – Note: currently defined AE-ID Certificate with non-persistent AE-ID won’t work 17

Credential Identifiers • A credential identifiers in last two slides are persistent AE ID associated with execution context that knows credential secret: e. g – a machine or – a combination of machine + AE SW or – a combination of machine, AE SW and AE-specific state context. • Other Persistent IDs associated with a specific machine etc. would typically have a permanent “binding” to the credential ID. • Some other Persistent IDs might be associated with more temporary aspects of the AE (e. g. “the AE in a device closest to my car”). – These persistent IDs will have a temporary “bindings” to a sequence of credential IDs (assuming those AEs have credentials) • Other information associated with the AE (e. g. see information that matters ) are obtained through other channels – Some info might be configured by the Subscriber – Some info (e. g. location) might be provided via Mcn – Some info might be synchronized with remote entity management 18

Pre- and Post- authorization • Registrar CSE might know credential identifier and associated service subscription information before authentication – E. g. credentials were pre-provisioned to Registrar CSE or configured manually or configured using remote entity management – Registrar allows registration and passes credential ID and assigned CSErelative AE-ID to IN-CSE. – AE has rights associated with service subscription info (e. g. rights associated with persistent AE IDs and roles) • Also OK for Registrar to obtain credential identifier during authentication and service subscription info after authentication – Registrar receives credential identifier during authentication (e. g. using GBA, MAF or a certificate) – Registrar allows registration and passes credential ID and assigned CSErelative AE-ID to IN-CSE. – AE has only minimal rights until IN-CSE responds with service Subscription Information for that credential ID. – When service subscription info is received by Registrar, then AE receives associated rights (see above) 19