Presentation is loading. Please wait.

Presentation is loading. Please wait.

Credential Identifiers Group Name: SEC#14.2 Source: Phil Hawkes, Qualcomm Inc, Meeting Date: 2014-12-18.

Similar presentations


Presentation on theme: "Credential Identifiers Group Name: SEC#14.2 Source: Phil Hawkes, Qualcomm Inc, Meeting Date: 2014-12-18."— Presentation transcript:

1 Credential Identifiers Group Name: SEC#14.2 Source: Phil Hawkes, Qualcomm Inc, phawkes@qti.qualcomm.comphawkes@qti.qualcomm.com Meeting Date: 2014-12-18 Agenda Item: TS-0003

2 Presentation has four parts Background Information from TS-0001 Proposal Conclusion

3 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

4 AE-IDs in TS-0001 AE-ID has is used for – Addressing (e.g. notification, groups) – accessControlPolicies – cmdhPolicies ARC & SEC identified need for two types of AE-ID – Some AE need an AE-ID assigned by M2M SP: S-Type 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: C-Type Only guaranteed to be unique when AE is registered to that CSE Another Registrar CSE would (most likely) assign a different C-Type AE-ID Stem to that AE 4

5 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 – S-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 Precise format is currently defined in TS-0001 5

6 Overview of call flow Clause 10.1.1.2.2 1.(Optional) Security Association Establishment 2.AE submits CREATE Request optionally indicate type or value of AE-ID-Stem 3.Registrar CSE uses certificate or s to determine allowed AE-ID-Stem Type & optionally values 4.Registrar compares AE-ID-Stem (+ opt value) with those allowed by step 3 5-7: (for S-Type) Creation/update on IN-CSE & Creation of

7 Steps 1+2 1.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” 2.AE registration request options a)Indicates S-Type, but no value provided. Two sub-cases 1.Certificate includes AE-ID-Stem. 2.Other cases b)AE provides S-Type AE-ID-Stem value. Two sub-cases 1.Certificate includes AE-ID-Stem. 2.Other cases c)AE wants Registrar CSE to assign a C-Type AE-ID-Stem d)AE provides C-Type AE-ID-Stem value (which may have previously assigned by Registrar CSE 7

8 Step 3+4 3.Two cases – If authentication was via cert and App-ID value and/or AE-ID-Stem value are present in the certificate, then Registrar matches the to those in the registration – Else Registrar CSE obtains s linked from Registrar’s which matches Credential-ID s can be stored on the IN-CSE A Matched dictates allowed App-ID values and AE-ID-Stem values 8

9 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 for flexibility – E.g. allowing all S-Type IDs for a particular credential 9

10 Support for multi-AE TLS Clients TLS client can provide security for – Single AE – Multiple AE w/ same App-ID on a same Node – Multiple AE w/ multiple App-ID on a same Node 10

11 Proposal SEC needs to define structure of the Credential-ID Proposal: Credential-ID has format – CredentialID Type: indicating one of PSK, 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.

12 PSK CredentialId Type = 1. Kpsa, KpsaId KpsaId is a good candidate for credential ID, but there are challenges. I partition provisioning scenarios into the following – call this “PSK-Type” 1.Factory provisioned: (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 to Registrar CSE by an administrator (with special privileges not afforded other users) trusted not to have duplicate KpsaIds 3.MEF Provisioned: 4.User provisioned

13 PSK Challenges 1.Factory: M2M SP can assume that Factory avoid duplicate KpsaId within their “domains”, but we need to include an identifier for the Factory to distinguish “domains”. PROBLEM TO SOLVE 2.Admin: M2M SP can assume that Admin avoid duplicate KpsaId within their “domains”, but we need to include an identifier for the Admin to distinguish “domains”. PROBLEM TO SOLVE 3.MEF: M2M SP can assume that MEF avoid duplicate identifiers within its scope, and MEF-FQDN identifies MEF. NO PROBLEMS 4.User: We can’t be sure if the user (or an attacker) has provisioned a duplicate KpsaId. M2M SP should not trust KpsaId provisioned by User. KpsaId not provided in this case. NO PROBLEMS-don’t allow. We can’t provide a good solution until we need to solve the problem of identifying the Factory and Admin. Similar problem to identifying certificate issuer (see later slides) 13

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

15 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 – Applicable AE-ID (assigned by M2M SP) – Applicable App-ID (globally assigned or M2M SP assigned) – Node-ID (assigned by M2M SP) – Device identifiers defined elsewhere (e.g.IMEI) Policy Object Identifiers (OIDs) restrict which of the above identifiers are permitted in end-entity certificates – Also present in Trust anchor information & Intermediate CA certificates 15

16 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 16

17 Challenges Very complex to support all these types of identifiers as a Credential-ID – 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 which is mandatory in certificates used to authenticate AE 17

18 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 arc – otherName “value” set to remainder of oneM2M- Certificate-ID 18

19 OID and Name Constraints 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. 19

20 Challenges of oneM2M-Cert-ID OIDs are managed identifiers This would need at least one registry – Can use a hierarchy of registries Should this be considered with App-ID Registry Ad Hoc? Should this be coordinated with identifiers for PSK Issuers (see discussion on Factory/Admin)? Should we consider FQDNs or some other identifier (since already supported in certs) – Danger of unintended interactions with existing certs

21 MAF-Based Credential Identifiers During Security Association Establishment, the MAF provides the Registrar CSE with – Kc – MAF_ISSUED_ID NOTE: Not yet clarified in TS-0003 NOTE: unclear if this is part of KmId Credential-ID Value is – MAF_ISSUED_ID ‘@’ MAF_FQDN 21

22 Conclusion: Summary of Proposal Credential TypeTypeValue FormatExample PSK1-TBD RawPublicKey Certificate 2-publicKeyIdentifier (hash of subjectPublicKeyInfo) 2-aH6jK… Certificate Chain3-OID-based oneM2M-Certificate-ID 3-123.456.789 MAF4-MAF_ISSUED_ID ‘@’ MAF_FQDN4-123@maf.com


Download ppt "Credential Identifiers Group Name: SEC#14.2 Source: Phil Hawkes, Qualcomm Inc, Meeting Date: 2014-12-18."

Similar presentations


Ads by Google