Certificate Enrolment STEs

Group Name: SEC#17.3Source: Phil Hawkes, Qualcomm Inc, phawkes@qti.qualcomm.com Meeting Date: 2015-07-15Agenda Item: TS-0003 – Release 2 Small Technical Enhancements

oneM2M Enrolment Requirements

• Rel 1 supports remote security provisioning of symmetric key credentials for the M2M SP’s domain– There is currently little consistence in use of “remote security provisioning”,

“enrolment” and “bootstrap” in TS-0001 & TS-0003. This needs to be addressed, but we do not attempt to address this here

• For Rel 2, we want to extend this to support remote security provisioning of public key credentials = public key certificates for the M2M SP’s domain– This type of process is sometimes called “Certificate Enrolment” and sometimes

called “Certificate Management”– Given existing use of the term “enrolment”, it would seem that “Certificate

Enrolment” would be appropriate terminology for us (at least for the time being)• We can change the terminology later if we like.

© 2015 oneM2M PartnersSEC-2015-0549R01-Certificate_Enrolment_STEs

2

SER-020 The oneM2M System shall enable legitimate M2M Service Providers to provision their own credentials into the M2M Devices/Gateways.

Implemented in Rel-1

SER-021 The oneM2M System shall be able to remotely and securely provision M2M security credentials in M2M Devices and/or M2M Gateways.

Implemented in Rel-1

Terminology (RFC 5272)

• End-Entity (EE) refers to the entity that owns a key pair and for whom a certificate is issued

• Certification Authority (CA) refers to the entity that issues certificates.

• Registration Authority (RA) … refers to an entity that acts as an intermediary between the EE and the CA. Multiple RAs can exist between the end-entity and the Certification Authority. RAs may perform additional services such as key generation or key archival.

© 2015 oneM2M Partners<Document number>

3

Cert Enrolment: Intro (1)• What? A protocol for an EE to obtain or update a public key

certificate for which the private key is known to the EE, – Also used for configuring CA certificates to EE

• Why? Enables mutual authentication between the EE and all other entities in that PKI.

• Which Common Protocols should we consider1. Certificate Management Protocol (CMP) RFC 4210, RFC 6712 2. Certificate Management over CMS (CMC) RFC 52723. Certificate Management over CMS (CMC): Transport Protocols RFC

52734. Enrolment over Secure transport (EST) RFC 7030

• Uses CMC / HTTPS / TLS. TLS typically used for client authentication5. Simple Certificate Enrolment Protocol (SCEP)

• Not a standard. IETF draft-nourse-scep-23– No standards exist for certificate management/enrolment over UDP

© 2015 oneM2M Partners<Document number>

4

Cert Enrolment: Intro (2)• How do CA, Registration Authority (RA) and EE interact?

– Requests EE [ RA x N] CA. Responses return on same path– RA applies some processing to requests and responses, e.g. signing

• How does CA/RA know that EE knows private key? OptionsA. EE generated key pair

1. EE generates the private/public key pair,2. EE Provides proof-of-possession (POP):by signing req, sending w/ req3. CA/RA verifies the POP4. CA generates the certificate, which is returned to the EE

B. CA or RA generated key pair1. CA/RA generates the private/public key pair, 2. CA generates the certificate3. CA/RA encrypts private key (using secret/password known to EE) 4. CA/RA sends private key to EE in encrypted form, along with cert

© 2015 oneM2M Partners<Document number>

5

oneM2M Certificate Enrolment• What? – A CSE/AE = EE Interacting with (opt RAs &) a CA to obtain

• CA certificates that the M2M SP wants the EE to trust• EE certificate w/ chain to one of above CA certs• Certificate may contain the CSE-ID or AE-ID

• Why? – Enables mutual authentication between CSE/AE and all

other entities using the M2M SP’s PKI.• Which entity would assume role of CA or RA? – M2M Enrolment Function (MEF) – Performs similar role in “symmetric key” enrolment– See later slide titled “Motivation for MEF as EST Server”

© 2015 oneM2M Partners<Document number>

6

Transport• There may be multiple devices with Middle Node(s) on

path between AE/CSE & the infrastructure domain• Options for transporting certificate enrolment msgs

between AE/CSE & MEF1. oneM2M reference points Mca+Mcc

• Advantage: utilize CDMH for efficient delivery• Disadvantage: Requires CSE/AE to register first, and at that point

in time, mutual authentication of CSE/AE & Registrar might not be possible

– End-to-end TCP session: • Note: TCP packets pass through multiple devices containing MNs• Advantage: No need for CSE/AE to register first. Simpler.• Disadvantage: Can’t benefit from CDMH

7

Option 1:oneM2M ref. points

8

AE/CSE

Link

IP

TCP

TLS

HTTP

oneM2M

MN CSE

Link

IP

TCP

TLS

HTTP

oneM2M

IN CSE

Link

IP

TCP

TLS

HTTP

oneM2M

RA/CA

Link

IP

TCP

TLS

HTTP

oneM2M

CertEnrolClient

CertEnrolServer

Option 2: End-to-end TCP

9

AE/CSE

Link

IP

TCP

MN CSE

Link

IP

TCP

IN CSE

Link

IP

TCP

RA/CA

Link

IP

TCP

CertEnrolClient

CertEnrolServer

Event Frequency & CMDH Benefit• Certificate Enrolment is an infrequent event

for each AE/CSE– e.g. once every N years • The efficiency gains, of using CMDH for

infrequent events, will be negligible when considering all the other frequent events over that period of time.

• Removes advantage of using oneM2M reference points (Option 1)

• Suggests using option 2: End-to-End TCP

10

EST• Enrolment over Secure Transport (EST) – Secures enrolment process using TLS (over TCP)– EST Server analogous to Registration Authority

• RFC 7030 does not address EST Server ↔ CA interface– EST Client can be

• End-Entity or an • An RA passing messages between EE and EST Server

• EST Requests/Responses use Certificate Management over CMS (CMC) RFC 5272– EST is a profile for CMC

11

EST ProtocolLayers

12

EST General Client/Server Interaction1. The client establishes TLS-secured HTTP session with an EST server

a. Client authenticates the Serverb. Server may authenticate client (if not, then step 2.b is mandatory)

2. The client and server perform a set of EST request/responses interactions

a. Specific EST service is requested based on a portion of URI 1. /cacerts, /simpleenroll, /simplereenroll, /fullcmc, /serverkeygen, /csrattrs

– Client/user may provide HTTP Basic/Digest username/ password authenticat’n for proof-of-identity. Required if client not authenticated in Step 1.b

– The client verifies that the server is authorized to serve this client – The server verifies that the client is authorized to make use of this

server and the request that the client has made– The server acts upon the client request

13

EST Authentication Options• Certificate TLS Mutual Authentication

– RECOMMENDED option in RFC 7030– Could use TLS authentication defined for Certificate-based Remote

Security Provisioning Framework (RSPF) –TS-0003 Clause 8.3.2.2• Certificate-less TLS Mutual Authentication

– EST text seems to expect that this would use weak secrets (e.g. Passwords) and recommends using SRP or similar

– Could use TLS-PSK with strong secrets, • TLS authentication defined for PSK & GBA RSPFs –TS-0003 Clause 8.3.2.1, 8.3.2.3

• Server-Only TLS– Client authenticated using HTTP Basic/Digest Auth with username/

password– For oneM2M, this would be a good way to enrol user devices e.g.

smartphones, tablets and laptops– Suggestion: allow as new option for symmetric key enrolment!

14

When EST Client is an RA

• EST allows the EST Client (which we normally consider to be the CSE/AE) to be a Registration Authority (RA)

• This RA could be a laptop/smartphone/tablet acting on your behalf to assist enrolling your CSE/AEs to MEF– E.g. enrolling CSE/AE while the device is plugged in to your laptop

via USB– The certificate is issued to the CSE/AE

• The laptop/etc. doesn’t get to know the private key– Advantage: the RA is verifying, to the MEF, that this is your

CSE/AE to be associated with your M2M service subscription• This could be very helpful... and the functionality is already

in EST!

15

Plan• Introduce changes as two “Small Technical

Enhancements”• STE 1: Introduce EST for certificate enrolment– Update TLS mutual authentication text for Certificate, GBA

and PSK RSPFs in TS-0003 (for symmetric key enrolment) so they can be used w/ EST • NOTE: aligns symmetric key & certificate enrolment

– Support scenarios where EST Client is an RA (e.g. laptop)• STE 2: Add username/password client authentication – TLS Server-only authentication of MEF, followed by– HTTP Basic/Digest Authentication w/ Username/passwd– Supported for both symmetric key & certificate enrolment

16

Motivation as MEF for EST Server

• As proposed on previous slide, the plan is to align symmetric key & certificate enrolment

• MEF could choose to support symmetric key enrolment and/or certificate enrolment!

• Simpler for oneM2M ecosystem if there is a single entity with multiple options

17

Anticipated STE 1 TS-0003 ChangesClause Update/

newClause title Change Relative

Work

6.1.3.1 Update Enrolment Phase High level overview of cert enrolment

Low

6.2.6 Update Trust Enabler Security Functions

Support for cert enrolment

Low

8.3.1 Update General Overview to RSPFs overview certificate enrolment

High

8.3.2.1-8.3.2.3

Update PSK, Certificate and GBA RSPF Details

support use for certificate enrolment

Medium

9.2.2 Update Bootstrap Instruction Configuration Procedure

AE-ID/CSE-ID to put in certificate

Low

18

Anticipated STE 2 TS-0003 ChangesClause Update/

newClause title Change Relative

Work

6.1.3.1 Update Enrolment Phase Include Username/Password RSPF

Low

8.1.4 New Username/Password Security Framework

Any details useful to include here

Medium

8.3.1 Update General Overview to RSPFs

Include Username/Password RSPF

Low

8.3.2.4 New Username/Password RSPF

Full specification High

9.2.1 Update Bootstrap Credential Configuration Procedure

Adding credential configuration for username/password RSPF

Low

10.2.4 New TLS ciphersuite details for Username/Password RSPF

Medium

19

Anticipated TS-0001 Changes

• Clause 11 in TS-0001 will also need minor updates to extend “enrolment” concept to include certificate enrolment– Mostly confined to clause 11.2 “M2M Initial

Provisioning Procedures”

20