On Persistent AE Identifiers

Group Name: SEC#12.2Source: Phil Hawkes, Qualcomm Inc (TIA), phawkes@qti.qualcomm.comFrancois Ennesser, Gemalto NV, Francois.Ennesser@gemalto.com Meeting Date: 2014-09-10Agenda 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 Bwhat 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:– <accessControlPolicy>– <subscription> (for notifications)– <group> (e.g. for fan-out)– <m2mServiceSubscription>

• 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 <m2mServiceSubscription> resource– Interaction with registration

• <m2mServiceSubscription> 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 <m2mServiceSubscription> 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 <m2mServiceSubscription> to

determine mapping between AE-ID and persistent AE identifiers

• In addition to <m2mServiceSubscription>,the following resources can use persistent identifiers– <accessControlPolicy>– <subscription> (for notifications)– <group> (e.g. for fan-out)

• More details in back-up slides9

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 <m2mServiceSubscription> at IN-CSE– Challenge: How does Registrar CSE tell IN-CSE which

<m2mServiceSubscription> and which AE in that <m2mServiceSubscription> 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.

• Presume M2M Service Subscriber knows which AE has these credential identifiers

• More discussion on credential identifiers here in backup slides

12

Proposal• Allow persistent AE Identifiers– <m2mService Subscription> resource and processing

needs updating– Process for other CSE & AE to obtain mapping between AE-

ID and persistent AE Identifiers– <accessControlPolicy>, <subscription>, <group> updated to

allow persistent AEs.• Allow credential IDs– <m2mService Subscription> 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 <m2mServiceSubscription> 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 <subscription> (for notification) and <group>

resources for (fan-out and fan-in).– <subscription> and <group> 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• <accessControlPolicy> (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 <accessControlPolicy> 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 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 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