Credential Identifiers

Group Name: SEC#14.2Source: Phil Hawkes, Qualcomm Inc, phawkes@qti.qualcomm.com Meeting Date: 2014-12-18Agenda 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• <serviceSubscribedAppRule>• 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 <serviceSubscribedAppRule> linked from Registrar’s <m2MServiceSusbcribedNode> which matches Credential-ID– <serviceSubscribedAppRule> can be stored on the IN-CSE– Matched <serviceSubscribedAppRule> dictates allowed

combinations of App-ID value and AE-ID-Stem value

6

<serviceSubscribedAppRule>

• <serviceSubscribedAppRule> 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 10.1.1.2.2)

– AE wants Registrar to ask M2M SP to assign an S-Type AE-ID-stem to AE – AE provides S-Type AE-ID-Stem value previously assigned by M2M SP– AE wants Registrar CSE to assign a C-Type AE-ID-stem – 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 valued) 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) pair1. 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-0003

13

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 4.2.1.10 “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 ProposalCredential Type Type Value Format Example

PSK 1- KpsaIssuerTypeID ‘-’ KpsaId 1-1-sensor11-2-adminIssuedPSK1-3-567@mef.com

RawPublicKey Certificate

2- publicKeyIdentifier (hash of subjectPublicKeyInfo)

2-aH6jK…

Certificate Chain 3- OID-based oneM2M-Certificate-ID

3-123.456.789

MAF 4- KmId MAF_ISSUED_ID ‘@’ MAF_FQDN

4-123@maf.com