[SERVER-1305] Securing SSL Extensions Created: 2016/04/12  Updated: 2017/08/11  Resolved: 2016/07/21

Status: Closed
Project: Puppet Server
Component/s: None
Affects Version/s: None
Fix Version/s: SERVER 2.5.0

Type: Epic Priority: Normal
Reporter: Reid Vandewiele Assignee: Nathaniel Smith
Resolution: Done Votes: 1
Labels: AWS1, product-priority
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Blocks
Epic Name: Securing SSL Extensions
Template:
Sub-team: Jade, jade
Epic Status: Done
Release Notes: New Feature
Release Notes Summary: In this release we allow the signing of CSR that contain a new custom OID arc to represent secured extensions for use with trapperkeeper-authorization (the system that underpins the newer auth.conf routing).

Signing CSRs wth the new OID arc is done via the command line via `puppet cert sign --allow-authorization-extensions`, a workflow similar to signing DNS alt names.

The new OID arc is "puppetlabs.1.3", long name: "Puppet Authorization Certificate Extension", short name: "ppAuthCertExt" (where "puppetlabs" is our registered arc 1.3.6.1.4.1.34380). The extension "puppetlabs.1.3.1" (pp_authorization) should be set for CSRs that need to be authenticated via the new workflow. We've also include an default alias of "pp_auth_role" at extension "puppetlabs.1.3.13" for common workflows.

We've also improved the CLI output of `puppet cert list` and `puppet cert sign` to be more user friendly with `--human-readable` and `--machine-readable` flags as well as allowing admins to force a prompt when signing certificates with a `--interactive` flag.

We hope this allows easier automated fail over to authorized nodes within a puppet infrastructure and will hopefully open up possibilities for additional security workflows in the future. See https://docs.puppet.com/puppet/4.5/reference/ssl_attributes_extensions.html for additional infromation on Custom SSL Extensions in Puppet.
QA Contact: Erik Dasher

 Description   

Provide a clean mechanism for setting certificate extensions to be used for cert-based authorizations (e.g. in TK-293). This mechanism needs to be different from our existing certificate extensions due to the need to prevent authorization-granting certificates from being accidentally signed.

The logical way to do this is to create a new OID arc specifically for authorization-granting extensions.

Our root OID is 1.3.6.1.4.1.34380 for "puppetlabs". We then have:

puppetlabs.1:   "Puppet Certificate Extension"
puppetlabs.1.1: "Puppet Registered Certificate Extension" (ppRegCertExt)
puppetlabs.1.2: "Puppet Private Certificate Extension"    (ppPrivCertExt)

See details here.

Our CA will currently ONLY accept extension requests if they are under one of the existing ppRegCertExt or ppPrivCertExt OIDs. See the ruby code and the clojure code.

To implement "authorization" certificate extensions, we could define another OID arc under puppetlabs.1. For example, we could define:

puppetlabs.1.3: "Puppet Authorization Certificate Extension" (ppAuthCertExt)

Because any extensions under this OID are flatline rejected today, we have full control over how we implement the methodology for accepting them. We could require on the command line something like:

puppet cert sign --allow-authorization-extensions



 Comments   
Comment by Eric Sorenson [ 2016/04/13 ]

This mechanism needs to be different from our existing certificate extensions due to the need to prevent authorization-granting certificates from being accidentally signed.

I don't understand this, or at least to the extent that I understand what you're saying I disagree with it.

Comment by Chris Barker [ 2016/04/13 ]

The concern is that currently there is no way to warn or notify a user they are signing certificates with ssl extensions. Which means in the instance of TK-293, someone could request what appears to be an agent certificate, but contains ssl extensions that conform to the whitelist access policies for PuppetDB.

By adding a new set of extensions (authorization extensions), we don't have to change the autosigning behavior or configuration for the previous extensions to prevent that above issue - Puppet already flags and wont autosign certificates that contain extensions outside of the predefined space. This also prevents collisions for users who may already be using ssl extensions heavily in their environment, since this is a new subset of extensions in a new namespace (puppetlabs.1.3) vs the ones that were used before.

Comment by Eric Sorenson [ 2016/04/13 ]

OK that makes more sense, I read through the whole conversation on TK-293 and understand why everyone landed here. The ticket description just presents it as axiomatic and my brain bounced off the statement

Comment by Nathaniel Smith [ 2016/05/05 ]

We should at least have a conversation about how we're not planning to support any of this in the GUI (or plan that work if we do want to support it)

Comment by Kevin Corcoran [ 2016/05/05 ]

My understanding is that there is no GUI work in-scope for this epic (not to say that it doesn't make sense to do that in the future).

Comment by Nathaniel Smith [ 2016/05/05 ]

Kevin Corcoran that's also my understanding. Seems like such a thing should be follow up work, especially because it might mean updating the CA API.

Comment by Nathaniel Smith [ 2016/06/13 ]

Confirmed with both HA folks and MEEP folks that no one is blocked on this work / waiting on it.

The completion of this work allows both HA and MEEP to do desirable work, but they are able to meet all of their davis deliverables without this.

Comment by Kevin Corcoran [ 2016/06/15 ]

Nathaniel Smith - Thank you very much for looking into that. Is any of that "desirable" work captured in JIRA or anywhere else, or is it just long-term / "pie in the sky" stuff for now?

Generated at Sat Dec 07 21:08:57 PST 2019 using JIRA 7.7.1#77002-sha1:e75ca93d5574d9409c0630b81c894d9065296414.