OmniBroker Publication Protocol

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

OmniPublish is a Web Service that supports server configuration management. The supported transaction set allows a server to obtain and renew necessary cryptographic credentials, publish service discovery statements and obtain network configuration specifications. The services supported by OmniPublish are complimentary to the services provided by OmniBroker [I-D.hallambaker-omnibroker] and the protocols share the same transport binding (HTTP, UYFM) and encoding options (JSON).

In the traditional approach to server configuration the network administrator is required to anticipate and perform all the necessary configuration needs of the service. For an enterprise server these steps will typically include: Enter server parameters in the DNS. Configure firewall to permit external access. Generate Public/Private Keypair. Apply for digital certificate. Install digital certificate. While executing each individual step may be considered straightforward, any configuration task involving five non-trivial human mediated tasks is liable to be error prone. Moreover maintaining the configuration represents an ongoing maintenance effort as certificates expire, network configurations are changed, servers are updated, etc.

In the traditional administration model the human is required to anticipate the needs of the server. Yet the server itself knows its needs with great precision although not necessarily how they are to be realized. A server that is configured to use the TLS protocol knows that a certificate is required and the purposes for which it is to be used. It knows when the certificate is about to expire and requires replacement and when evidence of certificate status (e.g. an OCSP token) requires renewal. Network configuration raises similar considerations except that the information available to a server is typically insufficient to perform network configuration tasks. It is not guaranteed that the local network IP address of a server is the same as the IP address that is visible to the external network. A mechanism in which the server edits DNS entries directly is therefore less functional than one in which the DNS entries are generated by a mediated service that has access to the necessary additional data. Network configuration is an administration function and therefore requires administrative privileges. Accordingly, every OmniPublish request and response is authenticated using credentials established using the SXS-Connect protocol [I-D.hallambaker-wsconnect].

Cloud computing does not necessarily raise new management requirements but the requirements that are raised become more urgent. In the traditional model a service ran on a fixed number of hosts in a configuration that was static for months or years. In a cloud computing environment the number of hosts supporting a service might vary several times in an hour to respond to variations in load. An important consequence of the transient nature of cloud computing is that hosts which provide a service for a few hours or even minutes are issued cryptographic credentials that are valid for a year.

The OmniPublish service is designed to permit services to manage themselves to the greatest extent possible. The features that are most likely to make deployment attractive in the short term are the ability to manage cryptographic credentials including acquisition of public/private keypairs, certificates and certificate status assertions. An enterprise with a large in-house IT department would typically host the Omnipublish service locally. The local service would then be configured to forward publication data to any IT facitilities that happen to be outsourced such as CA services, DNS etc. A similar model may be applied in the home automation environment with devices under management publishing their service information to the local publication server which then forwards the information to external services as necessary. The chief difference between this case and the enterprise case being that the service operation cannot depend on the end user being aware that the device exists, let alone perform configuration. In a pure cloud computing environment the OmniPublish service would have to be outsourced since there is no internal IT system for it to run off.

Application establishes a service connection to the OmniPublish service.

One of the chief reasons given for not using cryptographic protocols such as IPSEC, S/MIME and TLS is the difficulty of obtaining or registering the necessary cryptographic credentials. In the case of an Internet protocol this is typically but not always a PKIX certificate bound to a private key held by the the certificate subject.

Alice is the owner of a small business that operates a Web site. To protect the privacy of the Web site users, Alice decides to enable TLS on the Web site. Accordingly, Alice selects a Certificate Authority Example CA Inc. that issues a certificate with an appropriate validation requirement for her intended use. Alice provides her contact details to the CA which returns an account identifier alice@example.net and a PIN value [TBS]. The credentials are immediately valid for creating a service connection using the PIN. The Service Connection Ticket is obtained by a Web Server administration tool:

The service responds with the challenge to be used to validate the PIN:

The administration tool completes the request by proving knowledge of the PIN:

The Connection service returns the OmniPublish connection parameters:

The administration tool enters the connection parameters into the server configuration data. At this point all the administrative tasks related to the server are complete and the remainder of the process can be performed automatically. The server begins the process by generating a public key pair and Certificate Signing Request [RFC2986] and requests issue of a certificate with a CredentialRequest:

The service accepts the request but the process cannot be completed until the validation process required for the class of certificate has been completed. Accordingly the service returns the status 'Pending' and gives an estimated completion time:

The validation process completes successfully and the CA issues the certificate. The server requests delivery of the certificate by repeating the CredentialRequest:

This time the certificate is ready and is returned to the server. For the convenience of the server software, the response message tells the Web server when the certificate will expire and the earliest and latest dates on which to request renewal:

Note that the certificate returned is a short lifetime certificate that is only valid for a 72 hour interval, 24 hours of which have already elapsed at issue time. Use of short lived certificates is generally accepted as being highly desirable as it eliminates the need for certificate status reporting. The certificates issued will expire at the same time that any static status report would. The chief objection to the use of short lived certificates has been the need for daily administrative intervention. Automating the process of updating the certificate eliminates this objection. In addition to eliminating the need to track revocation status separately, performing certificate updates on a daily basis is potentially more reliable than one that is only activated once a year. Network changes that prevent a an update completing successfully have immediate impact at a time the network administration is looking for potential problems rather than being discovered up to a year later when the personel who caused the change may have been reassigned or left the company. The server MAY apply for renewal of the certificate at any time after the earliest date specified in the issue statement. If no request is made by the time that the latest time has been reached, the issuing CA MAY begin attempting to contact their customer to determine the cause. To avoid unnecessary warning messages from the CA (and possibly additional invoices for unused services) the server may inform the CA that certificate updates will not be required for an extended period using the Notify method:

Since Alice only operates one Web server, the simplest management solution for her is for the Web server to establish a direct connection to the CA. In a large enterprise with several hundred servers, a centralized management approach which allows configurations to be applied to groups of servers as a unit is usually required. To support this configuration, Bob deploys a local OmniPublish service in his network. Every machine that Bob manages connects to his local OmniPublish service to obtain its cryptographic credentials. The local OmniPublish service connects to the OmniPublish service of the CA to these service requests:

| Local OP |---------->| CA OP | +----------+ | +----------+ +----------+ | +----------+ | | Machine 3|--+ +----------+]]>

Conventional wisdom holds that public/private key pairs should be generated on the host on which they are to be used and exist in no other location. In practice, this mode of operation is not always the most desirable. In the case of keypairs to be used for encryption of static data, the decryption key must be available to all the machines that need decryption capabilities. Key generation procedures for public key algorithms can be lengthy. While a delay of a few seconds or even a few minutes is acceptable in a one-time server configuration process, introducing such a delay into server startup is frequently unacceptable. Experience of operating cryptographic systems has proved that correct and secure implementation of key generation capabilities is beyond the capabilities of many programmers. Random seeds are frequently generated with insufficient entropy. In some cases entropy is leaked after the seed is used to generate the private key. For the above reasons, it is frequently but not always desirable to perform generation of public/private keypairs as a centralized service supported by a small number of machines that can be tightly controlled an audited.

Bob buys a new coffee pot for his office that supports the hypothetical 'Ready to Brew' Web Service that allows the machine to be instructed to brew a cup of fresh coffee. Since this is an important and security sensitive function, the coffee pot supports use of the TLS protocol but the control hardware does not have access to a suitible source of randomness for generating a public keypair. To meet this need the coffee pot simply requests that the OmniPublish service generate a keypair on its behalf and return the private key with the certificate. Note that since Bob has bound the coffee pot to his local omnibroker service rather than a service provided by a public CA, Bob still exercises full control over generation of public/private keypairs. He is simply choosing to generate the keypair in a different place. [TBS: provide a DH exchange to enable an application level guarantee that the private key is delivered under a sound encryption scheme]

The service accepts the request and returns the requested credentials:

Configuring a network server typically requires an administrator to perform several tasks: Assign an IP address to the server. Configure the firewall to accept incomming traffic and direct it to the server. Assign a DNS address to the server. Configure the server to accept connections at the chosen DNS address. Configure the relevant authoritative DNS server to publish the server records for the chosen DNS address. Update local LDAP directories. While each individual step is straightforward, any error or inconsistency introduced may cause the configuration to fail or worse, succeed unreliably. Diagnosing and correcting such errors is one of the principal challenges in network administration. Delegating responsibility for the network configuration to a service enables the configuration to be performed automatically and separates the configuration of the network from the configuration of the servers and services that use the network. This approach greatly simplifies deployment of complex network changes and makes major changes possible without interruption of service.

Having deployed an infrastructure to automate management of his PKI credentials, Bob can leverage the same infrastructure to automate network configuration tasks as well. The coffee pot establishes a service connection using the out of band authentication technique described in [I-D.hallambaker-wsconnect]. Having established the service connection, the coffee pot requests advertisement of the brew-coffee Web service as follows:

The advertisement request succeeds and the OmniPublish service reports the successful outcome:

In this instance the OmniPublish service has granted the coffee pot a 48 hour lease on the service advertisement which must be renewed before expiry. In this case the publication request requires updates to the DNS service which will take some time to propagate. An estimate of the time required to complete publication is returned.

The OmniPublish protocol is a Web service that a network service or peer calls as a client to advertise the availability of a service and to obtain necessary cryptographic credentials.

Request: AdvertiseRequest Response: AdvertiseResponse Advises a broker that one or more Internet services are being offered with particular attributes.

Request: CredentialRequest Response: CredentialResponse Request issue of a cryptographic credential and (optionally) generate a public keypair

Request: NotifyRequest Response: NotifyResponse Notify the publication service that a server state transition has occurred or is planned.

Every Query Response contains the following common elements: Integer [1..1] Status return code value String [0..1] Describes the status code (ignored by processors)

Specifies the connection(s) to be established. The attributes required depend on the infrastructure(s) that the broker is capable of registering the service with. OBPQuery.Service [0..Many] Describes a connection to be established.

Specifies the connection(s) Integer [1..1] Status return code value String [0..1] Describes the status code (ignored by processors) OBPQuery.Service [0..Many] Describes a connection that was established.

Request issue of a cryptographic credential and (optionally) generate a public keypair. String [0..1] The DNS domain or [!RFC2822] account for which the credential is requested. TaggedBinary [0..1] Data required by the credential issuer to authenticate the request. For example a Certificate Signing Request [!RFC2986]. Boolean [0..1] If true, requests that a private keypair be generated and the private component returned to the requestor. String [0..Many] Types of data requested in response.

Returns issued cryptographic credentials. Integer [1..1] Status return code value String [0..1] Describes the status code (ignored by processors) TaggedBinary [0..1] The requested credential type, typically a PKIX End Entity certificate. TaggedBinary [0..Many] Supporting data for the issued credential. For example one or more chains of certificate signing certificates, OCSP [!RFC6960] tokens etc. TaggedBinary [0..1] The secret key for the requested credential (if requested). DateTime [0..1] The time at which the credential will cease to be accepted by relying parties. DateTime [0..1] The earliest time at which the issuer will accept renewal. DateTime [0..1] The latest time at which the issuer suggests requesting renewal.

String [0..1] Current state of the requestor String [0..1] State that the Requestor plans to enter DateTime [0..1] Earliest time at which the transition is expected to complete DateTime [0..1] Latest time at which the transition is expected to complete

Integer [1..1] Status return code value String [0..1] Describes the status code (ignored by processors)

A sequence of values of the same type. String [0..1] MIME Content Type of Data Binary [0..1] Opaque binary data

The transport binding options for Omnibroker Publication are identical to those offered for Omnibroker Discovery [I-D.hallambaker-omnibroker].

The following content identifiers are defined elsewhere and repeated here for the convenience of implementers. OCSP Response token as specified in [!RFC6090]. A single DER encoded PKIX Certificate as specified in [!RFC5280]. A Certificate Transparency notary chain as specified in [~RFC6962]. A PKCS#12 encrypted private key.

Rob Stradling, Robin Alden...

[TBS list out all the code points that require an IANA registration]