Operational Considerations for BRSKI Registrar

1.1. Terminology

Although this document is not an IETF Standards Track publication, it adopts the conventions for normative language to provide clarity of instructions to the implementer. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

1.2. Reference Network and Diagrams

In order to deal with the full complexity and generality of operations, the reference network described herein is a bit more complicated than many networks actually are.¶

XXX-some of these diagrams as more complex than the document currently justifies.¶

               .---------.   .------.
               | Denver  |   | NYC  |
          .----|---------|---|router|-.   .-----------.
         /     | NOC/JRC |   '------'   \ | Frankfurt |
        '      '---------'               '|-----------|
   .---------.                            | NOC/JRC   |
   | SanJose |                            '-----------'
   | router  |                                  .
   '---------'                                 /
       |                                      /
       |                                     /
.-----------.                               /
|   Perth   |              .-------.       /
|-----------|              | Tokyo |      /
| NOC/EST   |--------------|router |-----'
|           |              '-------'
'-----------'

                      .-------------.
                      | Data Center |
                 .----|-------------|------.
                /     | NOC/JRC     |       \
               /      '-------------'        \
              /                               \
             /                                 \
            /                                   \
   .--------------.                      .-------------.
   | Office Staff |                      |   building  |
   |   routers    |                      |  automation |
   |   switches   |                      |     IoT     |
   |   servers    |                      |   sensors   |
   '--------------'                      '-------------'

1.3. Internal architectural view

A Registrar will have four major interfaces, connected together by a common database.¶

                  .------------.
                  |    MASA    |
                  |  Interface |
                  | BRSKI-MASA |
                  '------------'
                         ^
                         |
 .------------.          |           .---------------.
 | management |    .----------.      | certification |
 | interface  |<---| database |----->|   authority   |
 '------------'    '----------'      '---------------'
                         |
                         |
                         v
.------------.     .-----------.       .------------.
| Join Proxy |     |  Pledge   |--.    | EST/BRSKI  |
|------------|     | Interface |  |    |------------|
| GRASP      |     | BRSKI-EST |e |    |    GRASP   |
| (DULL)     |     '-----------'T |    '------------'
'------------'        '-----------'

3.1. PKI recommendations for Tier-1/ISP Networks

A three-tier PKI infrastructure is appropriate for an ISP. This entails having a root CA created with the key kept offline, and a number of intermediate CAs that have online keys that issue "day-to-day" certificates.¶

Whether the root private key is secured by applying secret-splitting, and then storing the results on multiple USBs key kept in multiple safes, or via Hardware Security Module is a local decision informed by best current practices.¶

The root CA is then used to sign a number of intermediate entities: this will include an intermediate CA for the Registrar that is deployed into each redundant NOC location. Multiple intermediate CAs with a common root provides significantly more security and operational flexibility than attempts to share a private key among locations.¶

While the root CA should have a longevity of at least 5 years, after which it can be re-signed rather than re-generated. (Resigning an existing key might not require replacement of trust anchors on all devices)¶

The intermediate CA keys need only have a 1-2 year duration, and before the end of their lifetime, a new private key should be generated and replace the old one.¶

Shorter periods are possible, but until there is more experience with them, not recommended. The intermediate CA key should be regenerated because the intermediate CA private key will need to be online, available to the Registrar CA system. There are many more opportunities for the key to leak, such as into backups.¶

The intermediate CA is then used to sign End-Entity certificates which are returned as part of the BRSKI-EST mechanism.¶

The Registrar needs both of client and server certificates for it's BRSKI-EST and BRSKI-MASA connections. It is recommended that an additional intermediate CA can be created for manually issued certificates such as these. This intermediate CA could be called the NOC Infrastructure CA, and could be used to issue certificates for all manner of infrastructure such as web-based monitoring tools. The private root CA certificate should be installed into the browsers of NOC personnel.¶

The document [I-D.moskowitz-ecdsa-pki] provides some practical instructions on setting up this kind of system. This document recommends the use of ECDSA keys for the root and intermediate CAs, but there may be operational reasons why an RSA intermediate CA will be required for some legacy equipment.¶

3.2. Enterprise Network

Enterprises that have multiple Network Operations Center should consider the recommendations above for an ISP.¶

This section applies to Enterprises that have all NOC operations/personel into a single location, which is probably on-premise data center. This is not a hard rule for scaling, but the intent is that physical security for the ACP Connect network is rather easy, that only a single legal jurisdiction will apply, and that it is possible to get people together easily to do things like resign keys.¶

A three-tier PKI infrastructure is still recommended for the reason that it provides operational continuity options not available with a two-level system. The recommendation is to have a root CA mechanism installed on a Virtual Machine which is not connected to a network. The root CA private key is kept offline, secret split among a number of USB keys, kept in the possession of key personnel.¶

The secret split should have at least five components, of which at least three are required to reconstruct the key. See [I-D.hallambaker-mesh-udf] section 4.5 for one such mechanism, there are many others, and there are no interoperability requirements for the secret split.¶

The essential point is that the Enterprise is able to recover the root CA key even without some number of personnel and is able to continue operating it's network.¶

As in the ISP case, the intermediate CA is then used to sign End-Entity certificates which are returned as part of the BRSKI-EST mechanism. One intermediate CA key suffices as there is only one NOC location with a Registrar. Incidental certificates for internal operations (such as internal web servers, email servers, etc.), and for the BRSKI-EST server certificate can be done with this single intermediate CA.¶

The BRSKI-MASA TLS Client Certificate key for an enterprise may not be needed; it depends upon the policies of the manufacturers which are involved. It may be simpler to use a certificate produced by a public CA (such as LetsEncrypt), as this makes it easier for manufacturers to validate the provided certificate.¶

The document [I-D.moskowitz-ecdsa-pki] provides some practical instructions on setting up this kind of system. This document recommends the use of ECDSA keys for the root and intermediate CAs. In an Enterprise, there are likely many more legacy devices that might need to become involved in the secure domain. It is recommended that an RSA root and intermediate CA be more strongly considered.¶

3.3. Home Network

Home networks and small offices that use residential class equipment are the most challenging situation. The three-tier PKI architecture is not justified because the ability to keep the root CA offline has no operational value.¶

The home network registrar should be initialized with a single key pair used as the certification authority.¶

Secret splitting is useful in order to save the generated key with a few neighbours. It is recommended that the entire PKI system database (including CA private key) be encrypted with a symmetric key and the results made available regularly for download to a variety of devices. The symmetric key is split among the neighbours.¶

The most difficult part of the Home Network PKI and Registrar is where to locate it. Generally it should be located on a device that is fully owned by the home user. This is sometimes the Home Router, but in a lot of situations the Home Router is the ISP's CPE router. If the home has a Network Attached Storage (NAS) system, then running it there is probably better.¶

A compromise for CPE devices owned by the ISP that can run containers is for the Registrar to be located on detachable storage that is inserted into the CPE. The detachable storage is owned by the home owner, and can be removed from the CPE device if it is replaced. More experience will be necessary in order to determine if this is a workable solution.¶

4.1. Completely Synchronous Registrar

In this simplest version the Registrar operates as a single thread, processing the voucher-request from the Pledge, and then starting a BRSKI-MASA client session, while the connection from the Pledge waits.¶

This flow is very simple to implement, but requires an entire processing thread to block while the BRSKI-MASA protocol executes. The Pledge may timeout on this request, disconnect and retry. Experience so far is that typical default timeouts work fine.¶

It is recommended that the voucher-request be recorded in a database, and if a corresponding fresh voucher is also found in the database, that it be returned rather than fetching a new voucher from the MASA. This accomodates the situation where the Pledge did timeout, but the BRSKI-MASA protocol did complete. This results in the Pledge receiving the voucher upon retrying without having to go through the process of getting a new voucher. This only works if the Pledge retries with the same Nonce each time.¶

4.2. Partially Synchronous Registrar

A slightly more complicated version is for the Registrar to look in a database for a matching voucher-request, and if none is found, to return a 202 code upon the voucher-request, asking the Pledge to retry.¶

In the meantime the BRSKI-MASA connection can be performed, and the resulting voucher stored in a database. The connection can be done in the same thread that just deferred the connection, or in another thread kicked off for this purpose.¶

4.3. Asynchronous Registrar

In the completely asynchronous architecture, things work as with the Partially Synchronous version. The voucher request is placed into a database as before.¶

A completely separate system, probably with different network connectivity, but connected to the same database, performs the BRSKI-MASA processing, then fills the database with the answer.¶

This version may have a noticeably higher latency as it requires a database operation and a database trigger to invoke the process. This architecture has the advantage, however, that the internal facing Registrar never connects to the Internet. Furthermore, the number of internal facing Registrar instances can be tuned independently from the number of outward facing clients. This may be an advantage for networks that need to deal with a high number of malicious or lost internal clients.¶

5.1. TLS Server Certificate for BRSKI-EST

A certificate to be used to answer TLS connections from new devices (pledges). This must be of a type that expected pledges can understand. Returning an RSA key to a client that can validate only ECDSA chains is a problem. The constrained IoT ecosystem prefers ECDSA, and often does not have code that can verify RSA. Meanwhile, older FIPS-140 validated libraries present in many router operating systems support only RSA!¶

The recommendation is to use ECDSA keys, with a sensitiviity to when a majority of systems might support EdDSA. There are well established mechanisms in most TLS server libraries to permit multiple certificates to be loaded and to return an appropriate key based upon the client capabilities. This should be used.¶

The certificate used for the BRSKI-EST end point is not validated by the BRSKI pledge using public trust anchors, but rather it is pinned by the [RFC8366] voucher. As such it can come from the private CA, as recommended above: either signed by a specific intermediate CA or via a root CA as appropriate for the environment.¶

5.2. TLS Client Certificate for BRSKI-MASA

A certificate may optionally be used for authentication of the Registrar to the MASA. It is recommended to always include one.¶

It can be the same certificate used by TLS Server Certificate above, and this is most appropriate in small Registrars which are not distributed, such as ones aimed as Residential/Home networks.¶

In larger, distributed Registrars, cryptographic hygiene dictates that the private key not be distributed, so a unique certificate per Registrar client is appropriate. They should all be signed by the same intermediate CA, with the intermediate and root CA certificates being supplied in the TLS connection.¶

5.3. Certificate for signing of Voucher-Requests

As part of the BRSKI voucher-request process the Pledge's Voucher-Request is wrapped by the Registrar in another voucher-request and signed. It is this certificate which pinned by MASA to validate the connection.¶

The certificate used to sign the (parboiled) voucher-request MUST be the same as the one that is used for the TLS Server Connection. This implies that the signed voucher-request MUST be constructed on the same machine that terminates the BRSKI-EST connection.¶

8.1. Denial of Service Attacks against the Registrar

However, there are some exposures which need to be taken into account, particular in the Enterprise or Institutional Campus network: typically these networks have large number of access ports, one for each desktop system. Those systems can be infected with Malware, or may be located in student computer labs physically accessible with minimal authorization. While an attack on the Registrar might be part of some kind of student protest, an attack by malware seems more likely.¶

The different architectures proposed in Section 4 of this document provides some recommendations on differing scales. The use of a fully asynchronous design is recommended for Enterprise uses of BRSKI where there may be a large number of IoT devices that are expected to onboard. The ability to scale the BRSKI-EST Pledge Interface without having the scale the rest of the system provides for resiliency of the Registrary.¶

It bears repeating that the use of of a stateless technology in the Join Proxy moves the load due to attacking systems from the Join Proxy into the Registrar. This increases the network bandwidth required from the Join Proxy to the Registrar with the benefit of simplifying the Join Proxy.¶

This is an intentional design decision to centralize the impact into the purpose built Registrar system(s).¶

8.2. Loss of Keys/Corruption of Infrastructure

In Home/Residential Network ("homenet") uses of [RFC8995] the biggest risk is likely that of loss of the Registrar's key pairs. That is, accidental loss of the private key is more likely than loss to a malicious entity that steals them with intent to cause damage.¶

This can be due to failure to backup the database followed by a CPE device failure, but the case where a CPE device is simply thrown away to be replaced by an uninformed technician or household member is probably the most likely situation.¶

This situation results in loss of control for all devices in the home, and much frustration from the home owner who has to go through an onboarding process for all the devices. The use of a standardized onboarding protocol significantly mitigates the hassle; the current "state of the art" proccess involves a series of appliance-specific smartphone applications, which may or not not actually work on more recent devices.¶

This is why the focus on saving of the database along with a secret splitting process to secure it. At present there is no cross-vendor format for this database, so the saved data is only useable with a Registrar from the same vendor. So this protects against device failure, where it is replaced by an identical device or an upward compatible device from the same manufacturer, but not against changes of vendor.¶