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

Slides:



Advertisements
Similar presentations
Policy Based Dynamic Negotiation for Grid Services Authorization Infolunch, L3S Research Center Hannover, 29 th Jun Ionut Constandache Daniel Olmedilla.
Advertisements

Chapter 14 – Authentication Applications
Authentication Applications. will consider authentication functions will consider authentication functions developed to support application-level authentication.
Cryptography and Network Security Third Edition by William Stallings Lecture slides by Lawrie Brown.
SEC Clarification Group Name: WG4 (SEC-2014-xxxx) Decision  Meeting Date: Discussion  Source: OBERTHUR Technologies Information  Contact:
Is a Node or not Node? ARC Node_resolution Group Name: ARC Source: Barbara Pareglio, NEC, Meeting Date: ARC#9.1 Agenda.
Cryptography and Network Security Third Edition by William Stallings Lecture slides by Lawrie Brown.
Grid Security Infrastructure Tutorial Von Welch Distributed Systems Laboratory U. Of Chicago and Argonne National Laboratory.
Network Security Essentials Chapter 4
CSCE 715: Network Systems Security Chin-Tser Huang University of South Carolina.
Chapter 4 Authentication Applications. Objectives: authentication functions developed to support application-level authentication & digital signatures.
DESIGNING A PUBLIC KEY INFRASTRUCTURE
Facing the Challenges of M2M Security and Privacy
Credential Identifiers Group Name: SEC#14.2 Source: Phil Hawkes, Qualcomm Inc, Meeting Date:
App-ID Ad-Hoc Technical Issues TP AppID R02 Group Name: App-ID Ad-Hoc Group Source: Darold Hemphill, iconectiv,
DNS-centric PKI Sean Turner Russ Housley Tim Polk.
14 May 2002© TrueTrust Ltd1 Privilege Management in X.509(2000) David W Chadwick BSc PhD.
Cisco Confidential © 2010 Cisco and/or its affiliates. All rights reserved. 1 SAN Certificate in Unity Connection Presenter Name: Bhawna Goel.
On Persistent AE Identifiers Group Name: SEC#12.2 Source: Phil Hawkes, Qualcomm Inc (TIA), Francois Ennesser,
Mechanism to support establishment of charging policies Group Name: WG2-ARC Source: InterDigital Meeting Date: TP8 Agenda Item:
Sanzi-1 CSE5 810 CSE5810: Intro to Biomedical Informatics Dynamically Generated Adaptive Credentials for Health Information Exchange Eugene Sanzi.
App-ID Use Cases, Syntax and Attributes SEC App-ID_Use_Cases,_Syntax_and_Attributes Group Name: Architecture Source: Darold Hemphill, iconectiv,
In-Band Access Control Framework Group Name: WG4 SEC Source: Qualcomm Meeting Date: Agenda Item:
Certificate Enrolment STEs Group Name: SEC#17.2 Source: Phil Hawkes, Qualcomm Inc, Meeting Date:
Chapter 23 Internet Authentication Applications Kerberos Overview Initially developed at MIT Software utility available in both the public domain and.
Authorization for IoT Group Name: oneM2M SEC WG Source: Francois Ennesser, Gemalto NV Meeting Date: Agenda Item:
July 16, Diameter EAP Application (draft-ietf-aaa-eap-02.txt) on behalf of...
In-Band Access Control Framework Group Name: WG4 SEC Source: Qualcomm Meeting Date: Agenda Item:
Management of CMDH Policies Group Name: WG5-MAS Source: Wolfgang Granzow, Qualcomm, Meeting Date: Agenda Item: Management.
TS0001 Identifiers way forward Group Name: WG2 Source: Elloumi, Foti, Scarrone, Lu (tbc), Jeong (tbc) Meeting Date: Agenda Item: ARC11/PRO11.
1 SeGW Certificate profile (Revised) 3GPP2 TSG-S WG4 /TSG-X WG5 (PDS) S X xx Source: QUALCOMM Incorporated Contact(s): Anand.
SEC Identity_of_registrar_CSE Identity of Registrar CSE Group Name: SEC, ARC and PRO Source:FUJITSU Meeting Date: Agenda Item: Authentication.
Certificate Enrolment STEs Group Name: SEC#17.3 Source: Phil Hawkes, Qualcomm Inc, Meeting Date:
Cryptography and Network Security Chapter 14 Fourth Edition by William Stallings Lecture slides by Lawrie Brown.
Certificate Enrolment STEs Group Name: SEC#18 Source: Phil Hawkes, Qualcomm Inc, Meeting Date:
OneM2M Challenges of M2M Security and Privacy
App-ID Use Cases, Syntax and Attributes ARC R01-App-ID_Use_Cases,_Syntax_and_Attributes Group Name: Architecture Source: Darold Hemphill, iconectiv,
Interworking with an External Dynamic Authorization System Group Name: SEC WG Source: Qualcomm Inc., Wolfgang Granzow & Phil Hawkes Meeting Date: SEC#20.2,
X.509 Proxy Certificates for Dynamic Delegation Ian Foster, Jarek Gawor, Carl Kesselman, Sam Meder, Olle Mulmo, Laura Perlman, Frank Siebenlist, Steven.
Proposed App-ID Format Group Name: Architecture, Security Source: Darold Hemphill, iconectiv, Meeting Date: Agenda Item:
E2EKey Resource Group Name: SEC WG Source: Qualcomm Inc., Wolfgang Granzow & Phil Hawkes Meeting Date: SEC#20.3, Agenda Item: End-to-End Security.
Routing Problem of the Current Architecture Group Name: ARC Source: Hongbeom Ahn, LG Electronics, Meeting Date: Agenda.
Introducing Event handler Group Name: SEC & ARC Source: FUJITSU Meeting Date: Agenda Item: Device Configuration.
Discussion about RESTful Admin API Group Name: SEC & ARC Source: FUJITSU Meeting Date: Agenda Item: Device Configuration.
Security API discussion Group Name: SEC Source: Shingo Fujimoto, FUJITSU Meeting Date: Agenda Item: Security API.
End-to-End Primitive Security: Challenges and Suggestions Group Name: SEC WG Source: Qualcomm Inc., Phil Hawkes, Wolfgang Granzow, Josef Blanz Meeting.
Issue regarding authentication at MN-CSE Group Name: ARC & SEC Source: FUJITSU Meeting Date: Agenda Item: Security Admin API.
M2M Service Session Management (SSM) CSF Group Name: WG2-ARC Source: IDCC, LGE, ZTE Meeting Date: TP8 Agenda Item:
Clarification of Access Control Mechanism on Rel-1 & Rel-2 Group Name: SEC ( ARC & PRO for information) Source: FUJITSU Meeting Date: Agenda.
Issues of Current Access Control Rule and New Proposal Introduction Group Name: ARC 21 Source: Wei Zhou, Datang, Meeting Date:
Issues about management Group Name: MAS9.2 Source: Jiaxin Yin, Huawei Technologies Co., Ltd., Meeting Date: Agenda Item:
On-Boarding and Enrolment Group Name: SEC WG Source: Qualcomm Inc., Phil Hawkes, Wolfgang Granzow, Josef Blanz Meeting Date: SEC#22, Agenda.
Specifying the Address of Management Client of Managed Entity Group Name: ARC Source: Hongbeom Ahn, SK Telecom, Meeting Date: TP#21 Agenda.
Interworking with an External Dynamic Authorization System Group Name: SEC WG Source: Qualcomm Inc., Wolfgang Granzow & Phil Hawkes Meeting Date: SEC#20.1,
Resource subscription using DDS in oneM2M
[authenticationProfile] <mgmtObj> specialization
Ian Deakin, iconectiv 3rd July 2017
App-ID Ad-Hoc Technical Issues TP AppID R02
Service Enabled AE (SAE)
End-to-End Security for Primitives
Group multicast fanOut Procedure
Cryptography and Network Security
Proposed design principles for modelling interworked devices
MAF&MEF Interface Specification discussion of the next steps
Authentication Applications
Considering issues regarding handling token
Overview of E2E Security CRs
Service Layer Dynamic Authorization [SLDA]
Digital Certificates and X.509
Summary of the MAF and MEF Interface Specification TS-0032
Presentation transcript:

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

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

Overview of call flow Clause (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

Steps 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

Step 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

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

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

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.

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

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

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

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

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

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

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

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

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

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 MAF4-MAF_ISSUED_ID