Proposal for a new on-boarding procedure

I believe there is room for improvements to the existing on-boarding procedure, which you can read about here (look at page 111107, or 13, to see its sequence diagram). In particular, I propose that we adopt the following messaging procedure:

sequenceDiagram
    participant D as Device
    participant O as Onboarder
    participant CA as Certificate Authority
    participant DevR as Device Registry
    participant SysR as System Registry
    participant SrvR as Service Registry

    Note left of D: Onboarding Procedure

    D->>+O : Onboard(OnboardingRequest)
    O->>+CA : SignAll(Array<SigningRequest>)
    CA-->>O : Array<SigningAcceptance>
    O-->>-D : OnboardingAcceptance

    Note left of D: Registration Procedure

    par
        D->>+DevR : Register(DeviceRegistration)
        DevR-->>-D : DeviceRegistrationAcceptance
    and
        D->>+SysR : RegisterAll(Array<SystemRegistration>)
        SysR-->>-D : SystemRegistrationAcceptance
    and
        D->>+SrvR : RegisterAll(Array<ServiceRegistration>)
        SrvR-->>-D : ServiceRegistrationAcceptance
    end

This new procedure is an improvement over the existing in the following ways:

Only the onboarding Device and Onboarder (formerly Onboarding Controller) are aware of an onboarding taking place, which means that we acheive a better separation of concerns (i.e. the other involved systems have no special provisions for onboarding). The Onboarder becomes responsible only for validating OnboardingRequests and turn them into valid SigningRequests it passes on to the Certificate Authority. In essence, the Onboarder is a mediator between not-yet-onboarded devices and the Certificate Authority, which would otherwise not know how to trust those devices.
In the common case, much fewer messages must be sent compared to the current procedure. In the worst case, only a few more messages must be sent (one extra request-response exchange per system onboarded and registered after the initial onboarding and registration). This is primarily accomplished by allowing for onboarding and registration requests to be batched.

I now describe the message exchanges of the new procedure, after which I discuss other key differences and the messaging complexity of the current and proposed procedures.

1. Message Exchanges

1.1 The Onboarding Request and Acceptance

The messages sent and received by the onboarding Device are defined as follows:

classDiagram
    class OnboardingRequest {
        device: Optional~DeviceOnboardingRequest~
        systems: Array~SystemOnboardingRequest~
    }
    OnboardingRequest o-- DeviceOnboardingRequest
    OnboardingRequest o-- SystemOnboardingRequest

    class DeviceOnboardingRequest {
        kind: DeviceOnboardingRequestKind
        data: Array~byte~
    }
    DeviceOnboardingRequest o-- DeviceOnboardingRequestKind

    class DeviceOnboardingRequestKind {
        <<enumerator>>
        OTP
        PKCS10
    }

    class SystemOnboardingRequest {
        name: String
    }

    class OnboardingAcceptance {
        device: Optional~DeviceOnboardingAcceptance~
        systems: Array~SystemOnboardingAcceptance~
    }
    OnboardingAcceptance o-- DeviceOnboardingAcceptance
    OnboardingAcceptance o-- SystemOnboardingAcceptance

    class DeviceOnboardingAcceptance {
        certificate: Certificate
        renewalRequest: DeviceOnboardingRequest
        serviceCatalogue: Array~ServiceRegistration~
    }
    DeviceOnboardingAcceptance o-- Certificate

    class SystemOnboardingAcceptance {
        certificate: Certificate
    }
    SystemOnboardingAcceptance o-- Certificate

    class Certificate {
        kind: CertificateKind
        data: Array~byte~
    }
    Certificate o-- CertificateKind

    class CertificateKind {
        <<enumerator>>
        X509CertificateChainInPKCS7
    }

A single OnboardingRequest can be used to (A) only onboard a single device, (B) only onboard one or more systems, or (C) onboard both a device and a number of systems it plans to provide. In other words, the OnboardingRequest merges the current device and system onboarding messages. The acceptance contains all the requested certificates, as well as a renewal request, which replaces the current Onboarding Certificate, and a service catalogue. The service catalogue simply describes the interface details of an arbitrary collection of services it is believed that every onboarded device should be aware of.

1.2 The Signing Request and Acceptance

The messages sent and received by the Onboarder to the Certificate Authority are defined as follows:

classDiagram
    class SigningRequest {
        kind: SigningKind
        data: Array~byte~
    }
    SigningRequest o-- SigningKind

    class SigningKind {
        <<enumerator>>
        PKCS10
    }

    class SigningAcceptance {
        certificate: Certificate
    }

Certificate is defined in the diagram of Section 1. Note that in the sequence diagram above, arrays of SigningRequest and SigningAcceptance instances are exchanged.

1.3 The Registration Requests and Acceptances

The Device, System and Service registries are to receive the following modifications:

The Device and System registries do no longer need to handle certificate signing requests, which means that those provisions can be removed.
The System and Service registries need to accept batches of system and service registrations.

2. Other Key Differences

2.1 No Onboarding Certificate

One key to accomplishing these improvements is to replace the current Onboarding Certificate with a Renewal Request. The former lets a Device (1) request and then (2) renew its Device Certificate. The latter only allows for the Device Certificate to be renewed. Instead of the Device having to first get an Onboarding Certificate and then get a Device Certificate, I instead provide the Device with its Device Certificate and a Renewal Request at the same time.

2.2 One-Time Passwords Instead of Shared Secrets

The current Onboarding Controller can accept Devices that either present (A) a PKCS#10 Certificate Signing Request (CSR) signed by a manufacturer's certificate in the trust chain of the Onboarding Controller, as well as (B) a shared secret, known both to the Onboarding Controller and the onboarded Device. I propose that (B) shared secrets be replaced with One-Time Passwords (OTPs). Shared secrets are only secure until they are leaked, while OTPs can only be used once and are, as a consequence, safe to leak as soon as they have been used. This would require that a management service be added to the Onboarder that lets such OTPs be added or generated.

3. Messaging Complexity

The current procedure requires a Device to send 2 + m + n messages to complete an onboarding, where m is the number of onboarded and registered systems, and n is the number of registered services, or for 8 + 4m + 2n mesages to be sent in total (not counting the interactions with the Orchestrator, which I do not cover here, and assuming that the using chain of trust procedure can be used, which reduces the number of interactions with the Certificate Authority).

For example, an onboarding device with two system and five services must send 2 + 2 + 5 = 8 messages, while 8 + 4(2) + 2(5) = 26 messages must be sent in total.

In the procedure I propose, the onboarding Device needs to send 2 + p + 2q + r messages, while 6 + 2p + 6q + 2r messages are sent in total. To understand if this new situation is better or not, we must understand that in my procedure, the onboarding and registration messages are batched as far as is possible, which means that multiple things can be onboarded or registered with each message. p = 1 if we onboarded any systems together with our device, otherwise p = 0. q is the number of times we onboard and register systems after those we handled together with the device onboarding and registration. r is the number of times we register zero or more services.

Taking the same example as above and assuming that we know of the two systems and their five services from the start, our onboarding device must send 2 + (1) + 2(0) + (1) = 4 messages and 6 + 2(1) + 6(0) + 2(1) = 10 messages must be sent in total. If, on the other hand, we do not know of any of the systems or services initially, and we onboard and register them all in as many messages as possible (assuming they all arrive and no messages are rejected), our onboarding device ends up sending 2 + (0) + 2(2) + (5) = 9 messages, and 6 + 2(0) + 6(2) + 2(5) = 28 messages must be sent in total. In other words, my procedure is likely to always be better than the current and is only marginally worse in the worst case.

eclipse-arrowhead / roadmap