Credential Identifiers Group Name: SEC#14.2 Source: Phil Hawkes, Qualcomm Inc, Meeting Date: Agenda Item: TS-0003

Presentation has four parts Background Information from TS-0001 Aim of this ePresentation Proposal Conclusion

Background Information from TS-0001 S-Type and C-Type AE-ID Stems Authentication and Registration Validation AE-ID Stem & Registration Support for multi-AE TLS Clients

AE-IDs in TS-0001 AE-ID has two main uses – Addressing – accessControlPolicies ARC & SEC identified need for two types of AE-ID – Some AE need an AE-ID assigned by M2M SP Independent of who the Registrar CSE is. AE may re-register to another CSE and continue to use the same S-Type AE-ID Stem – Some AE only need an AE-ID assigned by Registrar Only valid when AE is registered to that CSE. Another Registrar CSE would (most likely) assign a different C-Type AE-ID Stem 4

S-Type and C-Type AE-ID Stems C-Type AE-ID Stem: Cxx..x – Assigned by the Registrar CSE – C-Type Identifiers for various scopes CSE-Relative: C-Type AE-ID Stem SP-Relative: Registrar CSE-ID + C-Type AE-ID Stem Absolute:M2M-SP FQDN + Registrar CSE-ID + C-Type AE-ID Stem S-Type AE-ID Stem : Sxx…x – Assigned by the M2M SP – C-Type Identifiers for various scopes CSE-Relative: S-Type AE-ID Stem SP-Relative: S-Type AE-ID Stem Absolute: M2M SP FQDN + S-Type AE-ID Stem 5

Authent’n and Reg’n Validation AE may authenticate using PSK, Certificate or MAF – If authenticated, then Registrar CSE notes Credential-ID (more details in later slides) – Else Credential-ID = “None”. Up to Registrar Policy if unauthenticated AE allowed. If authentication was via cert then Registrar matches the App-ID value and/or AE-ID-Stem value if present in the certificate to those in the registration Registrar CSE obtains linked from Registrar’s which matches Credential-ID – can be stored on the IN-CSE – Matched dictates allowed combinations of App-ID value and AE-ID-Stem value 6

comprises – applicableCredID: list of Credential Identifiers applicable for that rule – allowedAppIDs: list of App-IDs allowed by the rule – allowedAE: list of AE-IDs allowed by the rule for identified App-IDs. Wildcards allowed: to allow writing single rules to cover multiple devices 7

AE-ID-Stem & Registration AE registration request options (TS-0001 Clause ) a)AE wants Registrar to ask M2M SP to assign an S-Type AE-ID-stem to AE b)AE provides S-Type AE-ID-Stem value previously assigned by M2M SP c)AE wants Registrar CSE to assign a C-Type AE-ID-stem d)AE provides C-Type AE-ID-Stem value previously assigned by Registrar CSE Registrar CSE Response for each case… a)Registrar CSE forwards credential identifier to M2M SP for S-Type AE- ID-Stem assignment b)Registrar CSE forwards S-Type AE-ID-Stem value and credential identifier to M2M SP for verification c)Registrar CSE assigns a C-Type AE-ID-stem value d)Registrar CSE uses C-Type AE-ID-Stem value provided by AE 8

Support for multi-AE TLS Clients TLS client can provide security for – Single AE (executed by single App SW package on a single Node) – Multiple AE executed by single App SW package on a single Node – Multiple AE executed by multiple App SW package on a single Node 9

Goal of this presentation This presentation aims to describe this structure

Proposal SEC needs to define structure of the Credential-ID Proposal: Credential-ID has format – CredentialID Type, indicating one ofPSK, RawPublicKey certificate, certificate chain, or MAF – CredentialID Value, identifying a specific credential of the identified type. The format of value depends on the type of the credential.

PSK Kpsa, KpsaId: KpsaId = credential identifier We envisage three scenarios where the M2M SP would trust the (Kpsa, KpsaId) pair 1.Factory default: (Kpsa, KpsaId) pair was provisioned at the factory (e.g. if ADN and MN were sold as a single product with ADN and MN configured to work out of the box) 2.Admin provisioned: (Kpsa, KpsaId) pair was provisioned by an administrator with special privileges not afforded users. We assume that M2M SP trusts the administrators that could obtain this access. 3.MEF Provisioned The PSK Credential Identifier should be combination of – Identifier (1,2,3) for applicable provisioning scenario – KpsaId 12

Raw Public Key Certificate Credential Identifier Value corresponds to the publicKeyIdentifier (hash of the public key) as defined in TS

Certificate Chain Trust anchor information is configured to the Registrar CSE – E.g. using remote entity management. Certificate can include a variety of identifiers in subjectAltName – List of applicable AE-IDs (assigned by M2M SP) – List of applicable App-IDs (globally assigned) – Node-ID (assigned by M2M SP) – Device identifiers defined elsewhere (e.g.IMEI) Policy OIDs restrict indicate which of the above identifiers are permitted in end-entity certificates – Also present in Trust anchor information & Intermediate CA certificates 14

Trust Anchor Considerations The M2M SP must take care to configure the correct policy OIDs for trust anchors on Registrar CSE End-entity certificates containing an S-Type AE-ID need to be issued by (or on behalf of) M2M SP. – Typically, a Registrar CSE would be configured with only the M2M SP trust anchor (or one other third party trust anchor) for such certificates End-entity certificates containing other identifiers do not need to be issued by (or on behalf of) the M2M SP. – A Registrar CSE could be configured with many trust anchors for such certificates 15

Challenges Very complex to support all these types of identifiers. – E.g. Difficult to define rules constraining identifiers in end-entity certificates for such a variety of identifiers Propose using a common OID-based oneM2M-certificate-ID mandatory in certificates used to authenticate AE 16

oneM2M-Certificate-ID oneM2M-Certificate-ID is Object Identifier (OID) based, comprising – oneM2M-Certificate-ID-Indicator arc (to be assigned!!!) – One or more arcs assigned to CAs – End-Entity-ID arc Use “otherName” field in subjectAltName extension – otherName “Type-ID” set to oneM2M-Certificate-ID-Indicator – otherName “value” set to remainder of oneM2M-Certificate-ID CA Certificates use the name constraints extension (see clause “Name Constraints” of RFC 5280 [34]) to constrain the oneM2M-Certificate-ID to specific subtrees in subsequent end- entity certificates in a certification path. Subtrees are represented by an otherName field with – otherName “type-ID” set to oneM2M-Certificate-ID-Indicator – otherName “value” set to set to remainder of object identifier identifying the subtree. 17

MAF-Based Credential Identifiers MAF may be used to authenticate TLS client behind which is – A single AE executed by a single App SW Package on a single Node/Device – one or more AE executed by a single App SW Package on a single Node/Device – one or more AE executed by one or more App SW Packages on a single Node/Device During Security Association Establishment, the MAF provides the Registrar CSE with – Kmc – MAF-relative identifier for the TLS client, previously provisioned to the MAF Credential Identifier is a combination of – MAF FQDN – MAF-relative identifier 18

Conclusion: Summary of Proposal Credential TypeTypeValue FormatExample PSK1-KpsaIssuerTypeID ‘-’ KpsaId1-1-sensor1 1-2-adminIssuedPSK RawPublicKey Certificate 2-publicKeyIdentifier (hash of subjectPublicKeyInfo) 2-aH6jK… Certificate Chain3-OID-based oneM2M- Certificate-ID MAF4-KmId MAF_ISSUED_ID MAF_FQDN