Certificate Enrolment STEs Group Name SEC18 Source Phil

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

Certificate Enrolment STEs Group Name: SEC#18 Source: Phil Hawkes, Qualcomm Inc, phawkes@qti. qualcomm. com Meeting Date: 2015 -07 -20 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 – 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 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 (at least for the time being) • We can change the terminology later if we like. © 2015 one. M 2 M Partners SEC-2015 -0549 R 01 -Certificate_Enrolment_STEs 2

Basic Cert Enrolment Terminology • End-Entity (EE): the entity that owns a key pair

Basic Cert Enrolment Terminology • End-Entity (EE): the entity that owns a key pair and for whom a certificate is issued [1] • Certification Authority (CA): – the entity that issues certificates. [1] – the trusted third party/Organization responsible for validating the identity of a person or organization & issuing a certificate [2] References 1. “Certificate Management over CMS (CMC)” RFC 5272 2. http: //www. techotopia. com/index. php/An_Overview _of_Public_Key_Infrastructures_(PKI) © 2015 one. M 2 M Partners <Document number> 3

Cert Enrolment: Intro • What? A protocol for an EE to obtain or update

Cert Enrolment: Intro • 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 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 / HTTPS / TLS typically used for client authentication 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> 4

Registration Authorities • Registration Authority (RA) … – …the component of a PKI which

Registration Authorities • Registration Authority (RA) … – …the component of a PKI which is responsible for accepting requests for digital certificates and authenticating the person or organization [or entity] making the request. … Once the validation process is complete the RA transmits the request to the CA [2] – …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. [1] • RAs. . [ may] …participate in the protocol by taking PKI Requests, wrapping them in a second layer of PKI Request with additional requirements or statements from the RA and then passing this new expanded PKI Request on to the CA. [1] • In a certification request scenario that involves an RA, the CA may allow (or require) that the RA perform the POP protocol with the entity that generated the certification request. [1] – NOTE: Sometimes, a CA integrates an RA, and no distinction is made between CA and this RA Client: an entity that creates a PKI Request… both RAs and EEs can be clients. [1] Server: entities that process PKI Requests and create PKI Responses… both CAs and RAs can be servers. [1] References • “Certificate Management over CMS (CMC)” RFC 5272 • http: //www. techotopia. com/index. php/An_Overview_of_Public_Key_Infrastruct ures_(PKI) • • © 2015 one. M 2 M Partners <Document number> 5

Example 1 EE RA Creates PKI request client server PKI Request In this example,

Example 1 EE RA Creates PKI request client server PKI Request In this example, the CA organization separates the RA functions from the CA (certificate generation) functions Internal to CA organization CA RA Authentication (o) Modifies PKI request client PKI Request server Processes PKI request: Creates certificate, Creates PKI Response, server PKI Response client PKI Response server © 2015 one. M 2 M Partners <Document number> 6

Example 2 EE Internal to CA organization Creates PKI request client server PKI Request

Example 2 EE Internal to CA organization Creates PKI request client server PKI Request In this example, the CA organization has no separation of RA functions and CA functions. Externally indistinguishable from Example 1 client CA RA Authentication (o) Modifies PKI request Processes PKI request: Creates certificate, Creates PKI Response, server PKI Response © 2015 one. M 2 M Partners <Document number> 7

Example 3 Local RA EE RA Creates PKI request client Internal to CA organization

Example 3 Local RA EE RA Creates PKI request client Internal to CA organization CA server PKI Request EE Authentication (o) Modifies PKI request client RA Authentication (o) Modifies PKI request In this example, Local RA can authenticate EE, but not CA Organization. CA Org trusts Local RA to verify EE client PKI Response server PKI Request client PKI Request server Processes PKI request: Creates certificate, Creates PKI Response, client PKI Response server © 2015 one. M 2 M Partners <Document number> 8

Example 4 Local RA EE Internal to CA organization Creates PKI request client CA

Example 4 Local RA EE Internal to CA organization Creates PKI request client CA server PKI Request EE Authentication (o) Modifies PKI request client PKI Request In this example, the CA organization has no separation of RA functions and CA functions. Externally indistinguishable from Example 3 client PKI Response server RA Authentication (o) Modifies PKI request Processes PKI request: Creates certificate, Creates PKI Response, server © 2015 one. M 2 M Partners <Document number> 9

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

Cert Enrolment: Intro continued • 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? Options A. B. EE generated key pair 1. 2. 3. EE generates the private/public key pair, EE Provides proof-of-possession (POP): by signing req, sending w/ req CA/RA verifies the POP 4. CA generates the certificate, which is returned to the EE – CA may rely on RA to verify POP (Examples 1, 3, 4) CA or RA generated key pair 1. 2. 3. 4. 5. RA Authenticates EE 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> 10

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 (opt RAs &) a CA to obtain • CA certificates that the M 2 M 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 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> 11

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, mutual authentication of CSE/AE & Registrar might not be possible 2. End-to-end TCP session: • • • Note: TCP packets may pass through multiple gateways (NAT, Firewall, TCP proxy) Advantage: No need for CSE/AE to register first. Simpler. Disadvantage: Can’t benefit from CDMH 12

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 13

Option 2: End-to-end TCP RA/CA Cert. Enrol Server AE/CSE Cert. Enrol Client Gateway TCP

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

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

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 Server analogous to Registration Authority • RFC 7030 does not address EST Server ↔ CA interface – EST Client can be • End-Entity, or • 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 16

EST Protocol Layers 17

EST Protocol Layers 17

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 authenticate 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 authentication 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 18

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 – Server is authenticated via certificate in TLS – Client authenticated using HTTP Basic/Digest Auth with username/ password – Currently, no similar one. M 2 M RSPF • We are considering proposing adding support for this, but we are still evaluating the justification. 19

When EST Client is an RA • EST allows the EST Client (which we

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) – By including the id-kp-cmc. RA [RFC 6402] extended key usage extension • This could be very helpful. . . – Examples in following slides • …and the functionality is already in EST! 20

Example: User device as Subscriber’s RA • Subscriber requests RA certificate for her user

Example: User device as Subscriber’s RA • Subscriber requests RA certificate for her user device (laptop/smartphone/tablet) – Includes the id-kp-cmc. RA extended key usage extension – The EST Server (MF) updates its database to authorizes this certificate to request enrolling entities to Subscriber’s subscription • User device may assist enrolling Subscriber’s CSE/AEs to M 2 M SP via MEF 1. 2. 3. 4. 5. 6. Subscriber connects the CSE/AE to the user device using some secure, authenticated channel (e. g. over USB, authenticated Bluetooth). Subscriber triggers the CSE/AE to pass a certificate signing request to the user device The user device verifies the Proof-of-possession presented by the CSE/AE The user device may add some extensions to the certificate signing request, including identifying the Subscriber’s subscription to which the entity is to be added The user device and MEF perform EST • MEF determines that user device is authorized to act as RA to add entities to Subscriber’s subscription • MEF returns a certificate to the CSE/AE • MEF informs that M 2 M SP, that this CSE/AE is to be added to the The user device returns the certificate to the CSE/AE • The user device doesn’t get to know the private key 21

Example: User device as M 2 M SP’s RA • M 2 M SP

Example: User device as M 2 M SP’s RA • M 2 M SP technician requests RA certificate for user device (laptop/smartphone/tablet) – To be used to assist subscribers in enrolling their devices. – Includes the id-kp-cmc. RA extended key usage extension – The EST Server (MF) updates its database to authorizes this certificate to request enrolling entities to ANY of the M 2 M SP’s subscription • User device may assist enrolling ANY Subscriber’s CSE/AEs to M 2 M SP via MEF 1. 2. 3. 4. 5. – Technician connects the CSE/AE to the user device using some secure, authenticated channel (e. g. over USB, authenticated Bluetooth). Technician triggers the CSE/AE to pass a certificate signing request to user device User device verifies the Proof-of-possession presented by CSE/AE User device may add some extensions to the certificate signing request, including identifying the subscription to which the entity is to be added • The technician may need to enter the identifier for the appropriate subscription User device and MEF perform EST • MEF determines that user device is authorized to act as RA to add entities to any of M 2 M SP’s subscription • MEF returns a certificate to the CSE/AE • MEF informs that M 2 M SP, that this CSE/AE is to be added to the The user device returns the certificate to the CSE/AE • The user device doesn’t get to know the private key 22

Plan • Introduce changes as one (or possibly two)“Small Technical Enhancements” • STE 1:

Plan • Introduce changes as one (or possibly 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) • (Possible) STE 2: Add username/password client authentication – HTTP Basic/Digest Authentication w/ Username/passwd – Supported for both symmetric key & certificate enrolment – Still evaluating the justification for this. 23

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

Motivation for MEF as 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 24

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 25

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 26

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