Certificate Enrolment STEs Group Name SEC17 2 Source

  • Slides: 18
Download presentation
Certificate Enrolment STEs Group Name: SEC#17. 2 Source: Phil Hawkes, Qualcomm Inc, phawkes@qti. qualcomm.

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

one. M 2 M Enrolment Requirements SER-020 The one. M 2 M System shall

one. M 2 M Enrolment Requirements SER-020 The one. M 2 M System shall enable legitimate M 2 M Service Providers to Implemented provision their own credentials into the M 2 M Devices/Gateways. in Rel-1 SER-021 The one. M 2 M System shall be able to remotely and securely provision M 2 M security credentials in M 2 M Devices and/or M 2 M Gateways. Implemented in Rel-1 • Rel 1 supports remote security provisioning of symmetric key credentials for the M 2 M SP’s domain – We have called this “enrolment” in some places • For Rel 2, we want to extend this to support remote security provisioning of public key credentials = public key certificates for the M 2 M 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 © 2015 one. M 2 M Partners <Document number> 2

Cert Enrolment: Intro (1) • What? A protocol for an End-Entity to obtain a

Cert Enrolment: Intro (1) • What? A protocol for an End-Entity to obtain a public key certificate for which the private key is known to the End-Entity, – and for configuring Certificate Authority (CA) certificates • Why? Enables mutual authentication between the end-entity and all other entities in that PKI. • Which Common Protocols should we consider 1. 2. 3. 4. 5. • • Certificate Management Protocol (CMP) RFC 4210, RFC 6712 Certificate Management over CMS (CMC) RFC 5272 Certificate Management over CMS (CMC): Transport Protocols RFC 5273 Enrolment over Secure transport (EST) RFC 7030 Uses CMC Simple Certificate Enrolment Protocol (SCEP) Not a standard. IETF draft-nourse-scep-23 – No standards exist for certificate management/enrolment over UDP © 2015 one. M 2 M Partners <Document number> 3

Cert Enrolment: Intro (2) • How do CA, RA and End-Entity interact? – Requests

Cert Enrolment: Intro (2) • How do CA, RA and End-Entity interact? – Requests EE [ RA x N] CA. Responses return on same path • How does CA/RA know that EE knows private key? Options – EE generated key pair • • EE generates the private/public key pair, EE Provides proof-of-possession by signing req, and sending with req CA/RA verifies the proof-of-possession CA generates the certificate, which is returned to the EE – CA or RA Generated • • CA/RA generates the private/public key pair, CA generates the certificate CA/RA encrypts private key (using secret/password known to EE) CA/RA sends private key to EE in encrypted form, along with cert © 2015 one. M 2 M Partners <Document number> 4

one. M 2 M Certificate Enrolment • What? – A CSE/AE = EE Interacting

one. M 2 M Certificate Enrolment • What? – A CSE/AE = EE Interacting with an RA or CA to obtain • CA certificates trusted by the M 2 M SP • End-Entity certificate containing the CSE-ID or AE-ID • Certificate chain from EE cert to one of above CA certs • Why? – Enables mutual authentication between CSE/AE and all other entities in M 2 M SP’s PKI. • Which entity would assume role of CA or RA? – M 2 M Enrolment Function (MEF) – Performs similar role in symmetric key enrolment – See later slide titled “Motivation for MEF as EST Server” © 2015 one. M 2 M Partners <Document number> 5

Transport • There may be multiple devices with Middle Node(s) on path between AE/CSE

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 & MEF 1. one. M 2 M reference points Mca+Mcc • • Advantage: utilize CDMH for efficient delivery Disadvantage: Requires CSE/AE to register first, and at that point in time CSE/AE may be unable to authenticate to Registrar! 2. 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 utilize CDMH 6

Option 1: one. M 2 M ref. points AE/CSE Cert. Enrol Client MN CSE

Option 1: one. M 2 M ref. points AE/CSE Cert. Enrol Client MN CSE IN CSE RA/CA Cert. Enrol Server one. M 2 M HTTP TLS TLS TCP TCP IP IP Link 7

Option 2: End-to-end TCP MN CSE IN CSE RA/CA Cert. Enrol Server TCP TCP

Option 2: End-to-end TCP MN CSE IN CSE RA/CA Cert. Enrol Server TCP TCP IP IP Link AE/CSE Cert. Enrol Client 8

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

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. • Removes advantage of using one. M 2 M reference points (Option 1) • Suggests using option 2: End-to-End TCP 9

EST • Enrolment over Secure Transport (EST) – Secures enrolment process using TLS (over

EST • Enrolment over Secure Transport (EST) – Secures enrolment process using TLS (over TCP) – EST Client = End-Entity – EST Server analogous to Registration Authority • RFC 7030 does not address EST Server ↔ CA interface • EST Requests/Responses use Certificate Management over CMS (CMC) RFC 5272 10

EST Layers 11

EST Layers 11

EST General Client/Server Interaction 1. 2. The client establishes TLS-secured HTTP session with an

EST General Client/Server Interaction 1. 2. The client establishes TLS-secured HTTP session with an EST server a. b. Client authenticates the Server may authenticates client (if not, then step 2. b is mandatory) a. Specific EST service is requested based on a portion of URI The client and server perform a set of EST request/responses interactions b. c. d. e. • /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 12

EST Authentication Options • Certificate TLS Mutual Authentication – RECOMMENDED option in RFC 7030

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 one. M 2 M, 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! 13

Plan • Introduce changes as two “Small Technical Enhancements” • STE 1: Introduce EST

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 it can be used EST • NOTE: aligns symmetric key & certificate enrolment • 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 14

Motivation as MEF for EST Server • As proposed on previous slide, the plan

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 one. M 2 M ecosystem if there is a single entity with multiple options 15

Anticipated STE 1 TS-0003 Changes Clause Update/ Clause title new Change Relative Work 6.

Anticipated STE 1 TS-0003 Changes Clause Update/ Clause title new 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. 18. 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 16

Anticipated STE 2 TS-0003 Changes Clause Update/ Clause title new Change Relative Work 6.

Anticipated STE 2 TS-0003 Changes Clause Update/ Clause title new 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 Medium here 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 17

Anticipated TS-0001 Changes • Clause 11 in TS-0001 will also need minor updates to

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 “M 2 M Initial Provisioning Procedures” 18