On Persistent AE Identifiers Group Name: SEC#12.2 Source: Phil Hawkes, Qualcomm Inc (TIA), Francois Ennesser, Gemalto NV, Meeting Date: 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 m2mServiceSubscription. – 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 accessControlPolicy 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 T1, the AE receiving the data fits description A – At time T2, 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-AE- ID that lasts for multiple primitive exchanges. Registrations expire if not renewed – SP-relative AE-ID is concatenation of CSE-relative-AE-ID and CSE- IDs 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 new- registration. 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 M2M 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 M2M 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 oneM2M 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 IN- CSE – 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 KpsaID = xyz. – During auth’n, AE  Registrar: KpsaID = xyz MAF-based – During auth’n, MAF  Registrar: key, KmID = xyz. GBA-based – During auth’n, BSF  Registrar: key, HLR/HSS =abc, persistent id =xyz (previously configured to HLR/HSS by 3GPP/3GPP2 subscriber RawPublicKey certificate – During auth’n AE  Registrar: RawPublicKey Other Certificate: – Certificate contains somw identifier = xyz, and chains to trust anchor = abc. More discussion here in backup slides.here Presume M2M Service Subscriber knows which AE has these credential identifiers More discussion on credential identifiers here in backup slideshere 12

Proposal Allow persistent AE Identifiers – resource and processing needs updating – Process for other CSE & AE to obtain mapping between AE- ID 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 AE- ID 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 M2M SP) – Certificate contains persistent AE identifier = xyz and chains to trust anchor = M2M 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 channelsinformation that matters – 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 CSE- relative 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 CSE- relative 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