Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bootstrapping gNOI/gNMI using the gNOI cert service #18

Merged
merged 3 commits into from
Aug 29, 2019
Merged
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Binary file added docs/img/bootstrapping_state.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
112 changes: 112 additions & 0 deletions docs/simplified_bootstrapping.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,112 @@
# Simplified Bootstrapping for gNOI and gNMI

Updated: April 1st, 2019

Version: 0.1.0

### Definitions

* Client is the same as defined in gNMI
* Target is the same as defined in gNMI
* gNOI [Certificate Management service](../cert/cert.proto)
* Secure connection - Encrypted and authenticated connection

### Bootstrapping

The gNOI Certificate Management service has the methods to install certificates
in the Target. But how does a Client use gNMI and gNOI to configure or operate a
Target, when the Target has not been given the state and trust to be able to
establish a secure connection in the first place?

## Bootstrapping with the gNOI Certificate Management service

When having a Target with no pre existing certificates, this method allows
installing certificates by using the gNOI Certificate Management service.
Following this installation the Target is then capable of establishing secure
gNOI/gNMI connections. This process assumes a pre-existing secure environment.
It is therefore more applicable to be used in build rooms, labs or properly
secured management networks.

### Bootstrapping conditions

Because the Target is not trusted, it is assumed that this bootstrapping process
happens in a secure environment. This implies that there is negligible chance of
man-in-the-middle attacks between the Client and the Target during this process.
In addition, it is assumed that the Target is not already compromised.

### Target state

A Target is defined as being in either the **default state** or the
**provisioned state**:

![Target states](img/bootstrapping_state.png)

#### Target in default state

As in factory reset or unprovisioned state. When in this state, the Target must
provide a method for enabling the gNOI Certificate Management service if not
already enabled. In addition, the gNOI Certificate service must allow
unauthenticated connections. However, encryption should always be used, for this
a default certificate is employed. It is during this state the Client installs
the Target certificate and CA certificates bundle in the Target.

##### Enable gNOI Certificate Management service

The gNOI Certificate Management service must be enabled via one of the following
options:

1. Already enabled by default;
2. Triggered to run via DHCP third party attribute;
3. Triggered to run via a compressed configuration downloaded from a location
passed by a DHCP attribute;

The definition of such ZTP mechanisms are out of the scope of this document.

##### Unauthenticated session

Unauthenticated gRPC sessions are allowed in the default state. This is required
as the Target would have no way to validate the Client’s certificate as it has
no CA certificates.

##### Encryption

Encryption is always required as it raises the bar for potential attackers. As
such, in the default state, the Target should have and use a default
certificate. This certificate should be used only in the default state.
Resetting the Target to the default state always generates a new default
certificate or reuses a default one.

##### Certificate ID

The first installed certificate and CA certificate pool is used for the gNOI and
gNMI services. No other certificates should be installed during the default
stage. If the certificate ID is specified, then that becomes the associated

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This association is implicit. Why not do an explicit association by using the certificate-id leaf of openconfig-system-management.yang? I thought that was the intent (based on previous discussions).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reshad, that is a very good point. The guiding reason here is security. The gNOI/gNMI endpoint is at this stage accepting any connection, so it is at a securely fragile stage. The expectation here is to make sure that the only gNOI/gNMI action available is to install a certificate. This reduces the number of vectors an attacker has for meddling with the Target otherwise.

Please let me know what concerns you have with this approach and if you suggest an alternative.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sam, I now understand the motivation for doing this. The concern I had was because there's a well-defined explicit way, I prefer to avoid multiple ways of doing the same operation. But I get it now, and no I don't have an alternative.

certificate ID for the gNMI/gNOI service. If none is specified then one is
assigned by the Target.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sam, what is the motivation for not providing a certificate-id? If the target assigns one, how will the client know which one got assigned by the target? And if the client does not know the certificate-id, how can the client do Rotate or Revoke.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The motivation was to allow the platform to use its own default CertID string for this. The Client could then identify the certificate ID by performing a GetCertificatesRequest.
However, I am now realizing that this is adding complexity, it is in addition breaking the cert Install spec where a CertID is required. This is therefore unnecessary. Thank you for pointing it out. I am updating this PR to correct this.


##### Target behaviour

The Target must restart its gNOI/gNMI service and exclusively perform secure
connections as soon as the certificate and CA certificates have been
successfully installed, thus transitioning from the default state to the
provisioned state. The previously used default certificate must not be used once
in the provisioned state.

##### Client behavior

The Client, when bootstrapping a Target must not attempt to authenticate the
Target when establishing a connection. However it should still encrypt that
connection.

#### Target in provisioned state

When the Target is in provisioned state, the standard gNMI/gNOI authentication &
encryption rules apply.

#### Target reset

It must be possible to reset a Target to its default state. For a Network
Element this would be a factory reset triggered via gNOI. When executed, all
certificates and CA certificates should be cleared. A default certificate must
be generated if it does not already exist. The entire bootstrapping process
should be applicable again.