Internet DRAFT - draft-hallambaker-omnipublish
draft-hallambaker-omnipublish
Internet Engineering Task Force (IETF) Phillip Hallam-Baker
Internet-Draft Comodo Group Inc.
Intended Status: Standards Track May 21, 2014
Expires: November 22, 2014
OmniBroker Publication Protocol
draft-hallambaker-omnipublish-00
Abstract
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Hallam-Baker November 22, 2014 [Page 1]
Internet-Draft OmniBroker Publication Protocol May 2014
Table of Contents
1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Traditional Server Configuration Approach . . . . . . . 3
2.2. Automating network management. . . . . . . . . . . . . . 3
2.2.1. Cloud Computing Requirements. . . . . . . . . . . . 4
3. Omnibroker Publication Service . . . . . . . . . . . . . . . 4
3.1. Service Binding . . . . . . . . . . . . . . . . . . . . 5
3.2. Acquiring Cryptographic Credentials . . . . . . . . . . 5
3.2.1. Example: Small Web Site Operator . . . . . . . . . . 5
3.2.2. Example: Large Enterprise . . . . . . . . . . . . . 10
3.3. Generating or Obtaining a Public/Private KeyPair. . . . 11
3.3.1. Example: Internet Coffee Pot . . . . . . . . . . . 11
3.4. Request Network Configuration . . . . . . . . . . . . . 14
3.4.1. Example: Coffe Pot Service Registration. . . . . . . 14
4. OBPPublish . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. OBPPublish Transactions . . . . . . . . . . . . . . . . . 16
4.1.1. Advertise . . . . . . . . . . . . . . . . . . . . . 16
4.1.2. Credential . . . . . . . . . . . . . . . . . . . . . 16
4.1.3. Notify . . . . . . . . . . . . . . . . . . . . . . . 16
4.2. OBPPublish Messages . . . . . . . . . . . . . . . . . . . 16
4.2.1. Message: AdvertiseRequest . . . . . . . . . . . . . 16
4.2.2. Message: AdvertiseResponse . . . . . . . . . . . . . 17
4.2.3. Message: CredentialRequest . . . . . . . . . . . . . 17
4.2.4. Message: CredentialResponse . . . . . . . . . . . . 17
4.2.5. Message: NotifyRequest . . . . . . . . . . . . . . . 18
4.2.6. Message: NotifyResponse . . . . . . . . . . . . . . 18
4.3. OBPPublish Structures . . . . . . . . . . . . . . . . . . 18
4.3.1. Structure: TaggedBinary . . . . . . . . . . . . . . 18
5. Transport Bindings and Identifiers . . . . . . . . . . . . . . 19
5.1. Content-Type Identifiers . . . . . . . . . . . . . . . . 19
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7.1. Denial of Service . . . . . . . . . . . . . . . . . . . . 19
7.2. Breach of Trust . . . . . . . . . . . . . . . . . . . . . 19
7.3. Coercion . . . . . . . . . . . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
Hallam-Baker November 22, 2014 [Page 2]
Internet-Draft OmniBroker Publication Protocol May 2014
1. Definitions
1.1. Requirements Language
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].
2. Introduction
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).
2.1. Traditional Server Configuration Approach
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.
2.2. Automating network management.
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.
Hallam-Baker November 22, 2014 [Page 3]
Internet-Draft OmniBroker Publication Protocol May 2014
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].
2.2.1. Cloud Computing Requirements.
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.
3. Omnibroker Publication Service
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
Hallam-Baker November 22, 2014 [Page 4]
Internet-Draft OmniBroker Publication Protocol May 2014
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.
3.1. Service Binding
Application establishes a service connection to the OmniPublish
service.
3.2. Acquiring Cryptographic Credentials
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.
3.2.1. Example: Small Web Site Operator
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:
POST /.well-known/sxs-connect/ HTTP/1.1
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Host: localhost:8080
Content-Length: 344
Expect: 100-continue
{
"OpenPINRequest": {
"Encryption": ["A128CBC",
"A256CBC",
"A128GCM",
"A256GCM"],
Hallam-Baker November 22, 2014 [Page 5]
Internet-Draft OmniBroker Publication Protocol May 2014
"Authentication": ["HS256",
"HS384",
"HS512",
"HS256T128"],
"Account": "alice",
"Service": ["omni-publish"],
"Domain": "example.net",
"HaveDisplay": false,
"Challenge": "
4m7Lzr7g2FzllXcVGeDIOw"}}
The service responds with the challenge to be used to validate the
PIN:
HTTP/1.1 281 Pin code required
Content-Length: 511
Date: Wed, 21 May 2014 20:05:54 GMT
Server: Microsoft-HTTPAPI/2.0
{
"OpenPINResponse": {
"Status": 281,
"StatusDescription": "Pin code required",
"Challenge": "
cHbxV3Uwkb-CYezJhKj-wA",
"ChallengeResponse": "
98RV4Se7VQIP3FbqcrLKyUth5u6F48dbCGpzrHpkGfQ",
"Cryptographic": {
"Secret": "
e6oSWl3dFfNkpYXvSTvY1w",
"Encryption": "A128CBC",
"Authentication": "HS256",
"Ticket": "
V8ae-8uQMtt_uyKJQLbx4umJEpsz--OXVriEHRoq5sw5uq6u1_4tWv8ro7DyD5Su
hSpOibX2cOnd0OHSOJpcA1Gs9WjRArqzz0WrD0Inl39d89zbcWoMKYKhlOFFV_LF
V8kPPoK8BmaQOxCo3kBrxg"}}}
The administration tool completes the request by proving knowledge of
the PIN:
POST /.well-known/sxs-connect/ HTTP/1.1
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Session: Value=J5wXEchUbr7k2A0mvaOEPnr3KGFagzg1vH_MX6W1R14;
Id=V8ae-8uQMtt_uyKJQLbx4umJEpsz--OXVriEHRoq5sw5uq6u1_4tWv8ro7Dy
D5SuhSpOibX2cOnd0OHSOJpcA1Gs9WjRArqzz0WrD0Inl39d89zbcWoMKYKhlOF
FV_LFV8kPPoK8BmaQOxCo3kBrxg
Host: localhost:8080
Content-Length: 129
Expect: 100-continue
Hallam-Baker November 22, 2014 [Page 6]
Internet-Draft OmniBroker Publication Protocol May 2014
{
"TicketRequest": {
"Service": ["omni-publish"],
"ChallengeResponse": "
49GCx5HUvU2SNE6M3GuKcxgFfvZKDLpTfpqXUOAGXVE"}}
The Connection service returns the OmniPublish connection parameters:
HTTP/1.1 OK Success
Content-Length: 1306
Date: Wed, 21 May 2014 20:05:54 GMT
Server: Microsoft-HTTPAPI/2.0
{
"TicketResponse": {
"Status": 200,
"StatusDescription": "Success",
"Cryptographic": [{
"Protocol": "sxs-connect",
"Secret": "
DOdZw6ynGANAjqnR-1gL0A",
"Encryption": "A128CBC",
"Authentication": "HS256",
"Ticket": "
Ay9sUcNcC0GH9cY5NiRFcrqjFL0wTgTn69uO9SUPvP_XqB05yJ_fLqeI622H-bBu
klDhb1TpUGwQMAgNNwRkgsu97Dc38WBfUiyetM0TwYY"}],
"Service": [{
"Service": "omni-publish",
"Name": "localhost",
"Port": 8080,
"Priority": 100,
"Weight": 100,
"Transport": "HTTP",
"Cryptographic": {
"Secret": "
LfRHVDFWVkVQu81lI2wT8w",
"Encryption": "A128CBC",
"Authentication": "HS256T128",
"Ticket": "
OufJWkZCHmCLVeSuS4Nth4ozUrRfyDa4v8Dd5FIrkIWPQrGnHLgG_6ZmoHQGqIRg
7BL7Gm9Jq7LQihkCLhgQjp1LJqpDmDuDFbH5ZRDl7_g"}},
{
"Service": "omni-publish",
"Name": "localhost",
"Port": 9090,
"Priority": 100,
"Weight": 100,
"Transport": "UDP",
"Cryptographic": {
"Secret": "
elODZJePf2UDWW1hHw2-3A",
Hallam-Baker November 22, 2014 [Page 7]
Internet-Draft OmniBroker Publication Protocol May 2014
"Encryption": "A128CBC",
"Authentication": "HS256T128",
"Ticket": "
xMn4JDCQIg9WSHTVh1HwdJQq1iBoIHNk-BRHdhq_WGGeWv6cgfDgLYo2-U4BX2IH
_SRzZ1fDf5dHzfE67wuPawutwOkemJNH4mOK0XYeNPc"}}]}}
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:
POST /.well-known/omni-publish/ HTTP/1.1
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Session: Value=ArwY9yiAOaMjxTx4jE_BzNTNJ5z4Nn-I6gjdZPC5ejI;
Id=OufJWkZCHmCLVeSuS4Nth4ozUrRfyDa4v8Dd5FIrkIWPQrGnHLgG_6ZmoHQG
qIRg7BL7Gm9Jq7LQihkCLhgQjp1LJqpDmDuDFbH5ZRDl7_g
Host: localhost:8080
Content-Length: 148
Expect: 100-continue
{
"CredentialRequest": {
"Authentication": {
"ContentType": "application/pkcs-10",
"Data": "
AQID"},
"MakePrivateKey": false}}
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:
HTTP/1.1 282 Transaction Incomplete
Content-Length: 98
Date: Wed, 21 May 2014 20:05:55 GMT
Server: Microsoft-HTTPAPI/2.0
{
"CredentialResponse": {
"Status": 282,
"StatusDescription": "Transaction Incomplete"}}
The validation process completes successfully and the CA issues the
certificate. The server requests delivery of the certificate by
repeating the CredentialRequest:
Hallam-Baker November 22, 2014 [Page 8]
Internet-Draft OmniBroker Publication Protocol May 2014
POST /.well-known/omni-publish/ HTTP/1.1
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Session: Value=ArwY9yiAOaMjxTx4jE_BzNTNJ5z4Nn-I6gjdZPC5ejI;
Id=OufJWkZCHmCLVeSuS4Nth4ozUrRfyDa4v8Dd5FIrkIWPQrGnHLgG_6ZmoHQG
qIRg7BL7Gm9Jq7LQihkCLhgQjp1LJqpDmDuDFbH5ZRDl7_g
Host: localhost:8080
Content-Length: 148
Expect: 100-continue
{
"CredentialRequest": {
"Authentication": {
"ContentType": "application/pkcs-10",
"Data": "
AQID"},
"MakePrivateKey": false}}
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:
HTTP/1.1 282 Transaction Incomplete
Content-Length: 98
Date: Wed, 21 May 2014 20:05:55 GMT
Server: Microsoft-HTTPAPI/2.0
{
"CredentialResponse": {
"Status": 282,
"StatusDescription": "Transaction Incomplete"}}
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
Hallam-Baker November 22, 2014 [Page 9]
Internet-Draft OmniBroker Publication Protocol May 2014
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:
POST /.well-known/omni-publish/ HTTP/1.1
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Session: Value=wFsqI6wkH-TuCyGkIOjL3TJsbkvJCXxdHGohugk0hx0;
Id=vVuUnw2Pi0xlHB2OFnbOBTDmLn9qC1HhEjUkJMHfCtBZRCPXc1GzPw8TLm1b
8asS-GCtD8H681WvoGW0DcEgNMDUc0UZu-ZPo_wA9f8f-bk
Host: localhost:8080
Content-Length: 129
Expect: 100-continue
{
"NotifyRequest": {
"NextState": "Offline",
"Earliest": "2014-05-21T20:05:56Z",
"Latest": "2014-05-21T20:06:56Z"}}
3.2.2. Example: Large Enterprise
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:
Hallam-Baker November 22, 2014 [Page 10]
Internet-Draft OmniBroker Publication Protocol May 2014
+----------+
| Machine 1|--+
+----------+ |
|
+----------+ | +----------+ +----------+
| Machine 2|--+-->| Local OP |---------->| CA OP |
+----------+ | +----------+ +----------+
|
+----------+ |
| Machine 3|--+
+----------+
3.3. Generating or Obtaining a Public/Private KeyPair.
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.
3.3.1. Example: Internet Coffee Pot
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
Hallam-Baker November 22, 2014 [Page 11]
Internet-Draft OmniBroker Publication Protocol May 2014
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]
POST /.well-known/omni-publish/ HTTP/1.1
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Session: Value=tKs0Y7AGoqfFtZDIUh395TlbIU2E6ciO2beA4lnBtgs;
Id=vVuUnw2Pi0xlHB2OFnbOBTDmLn9qC1HhEjUkJMHfCtBZRCPXc1GzPw8TLm1b
8asS-GCtD8H681WvoGW0DcEgNMDUc0UZu-ZPo_wA9f8f-bk
Host: localhost:8080
Content-Length: 147
Expect: 100-continue
{
"CredentialRequest": {
"Authentication": {
"ContentType": "application/pkcs-10",
"Data": "
AQID"},
"MakePrivateKey": true}}
The service accepts the request and returns the requested
credentials:
HTTP/1.1 OK Success
Content-Length: 3426
Date: Wed, 21 May 2014 20:05:55 GMT
Server: Microsoft-HTTPAPI/2.0
{
"CredentialResponse": {
"Status": 200,
"StatusDescription": "Success",
"Credential": {
"ContentType": "application/pkix-cert",
"Data": "
eA0QIvK3hMNUo3d8IxEchavHUltR5O1LUmEnLCcpGL3XROcD_3GtNpvEWgexojbi
By4SynEEzCGpRzyFoioPB1Fk2yrA_c74YxRYc4OuFryF9CgrbshEMHi-I9Szip1i
Lr6_NDwifiMAUH4KZEwj6TyVCh0zMHWtYY6T_itwdbZhOdxsSxITn4xBEUEzQs3w
mSJ5pRbhguaotJ_Vexv87eYlmn-nKrh9w99hVsNFWm2pVmWMgMF__Q_xGWpf4y_Z
S4Bko6jpHqY6MA_JjSBxrKXP2FG1JNCe-10I1Oohdtt7z3i1pi9nYb0opPL1pmj2
6uXHRYO8hy0oewXEdHP_zg"},
"Support": [{
"ContentType": "application/pkix-cert",
"Data": "
4IvLI64hE-6_UxpMD_GUkyJLjGlq3Hz9i7G8kOJkn6kSjqyWmy_MGLN57dDGnK7D
Hallam-Baker November 22, 2014 [Page 12]
Internet-Draft OmniBroker Publication Protocol May 2014
z9DJYjSHbPk6SaX3r6_ye5YSxyuVF2duQACtH4Bd3icq_QpfiuXB-l8c5QTJe60u
ZZgVsGhzpagNpIUEb4VlPVIuQ4ZdV-yxLWhYM28ibzhHMfxNo6YOw-Xa7ySujry4
kr-ojsARBcS6jys6-k0_KUH8WPkIeiBisNQI7c4IwhgCE1DJqZRfIEB4fTjLWV3-
frOuuY6Y1cz_whODCgn68phD2D6eFuPyiJncU6WrFxF_aQibTQ9C7C61SWtloM5r
ASUBjY-bD9_iCppEtHxzoA"},
{
"ContentType": "application/pkix-cert",
"Data": "
LP9gFTTrsaeA_y9GqH_3eNiIbVR6H3HPhEIgu0UlWIKQoy_PeQB3JsOCd5O2Ra2S
HnPBMG4aRCVBU8MOTk27L9t4jvHbIy0kC0Ja4hm5yedkcG8sPhFZkHIOmhLhuaNT
bdLWFIUkvus420fl6gw1DU9n1H9vCbxG21SXet7iEhXQ9e8tA_i_9046NuS1CwTG
kpX0JJqrHHiZ6GQ3kKcn5PAdZkWiMAHReSATeD8GblAwXCkvguvVodMRV84n7gp4
JMuUnpKbtpZ_x0ycbG6LhwjmXyT_GzAYtjmSFXsS1shzNkmTYLbus1QFDVWaVPFk
AFwfthWawhaYBj0JWiAA0A"},
{
"ContentType": "application/pkix-cert",
"Data": "
DInUnJXe53hXiwrrWEyZPOlKsjzEYnhN_eVIGkArTjR9L7WQ32jY1Mt6sfnQsYiM
cRfqANQd3tVLRKnyNQYJaU1MkNmOC7OLSLbWW4XBFxQaCk__T0IoDMxTP4Ol0uUW
EVo47OkUMnteOQ21qhBBW415fB2S_WN-UdB3ILzW8jfdNPVy1ctn5XjcaV_WfTPY
goUCtuJbULrB17LzmAYkNTdIny2uQs6vO8kogQH1jTw0WYb24NB_iO0tIw8gwRXb
iVb3cKH46ywNq4B2BjVcQw5UE_-Q-FMfArKTGg7Z0Oobg3VeOuX_3tC1_wRmnZjy
lGLHTGi5yU5nOVranbCuIQ"},
{
"ContentType": "application/ocsp-response",
"Data": "
iyqwOV3TFQE7e0KIPgtDZ0_rMPZSB0rnSBjII_07JwuJjPYpBv6R8U6uK4vJwHOy
mxCBQLwa8ZQf9wLUAXwaz1H0bN7vKRZgIoZsTrT96KHRVj1i867zS70ZZg0nH9X9
1dwuv_n7KUEmwoUqFX4x9B2Ug3z1TPv-iLjkpPyWz4g"},
{
"ContentType": "application/ocsp-response",
"Data": "
BYAKOKAi9fD3tni3pUKZxHfiBv0ICo9ULKBMiwPOGpGRVomwuawD-D-P4uDnEvXS
3mSa3fQ_fz2tw7fOCMrG3n16Yj0NCc4X8GHn49hRRTfzywsgybTxMitgSrXGh4us
Qao5gsnlR-Zo4oT2I1wWP1P9CrJY3KcGrSPpu40HD-4"},
{
"ContentType": "application/ocsp-response",
"Data": "
MqSNwx7iFJomrYmB6bo600I5rbEchtbQrkzyBZt7ZW79RI1NRZMN9tkYif4b_Gby
QNLNk3eY6WhooU7Yl9boIoQYas-SY7s8Njp4gQmIjk2nPNKNNn2qtrVbfYRtxEIg
Nm3zJy9CtdyU87zQxXG-oG29FBG-hAQjmNtEes4xgtU"},
{
"ContentType": "application/ocsp-response",
"Data": "
J5vbsOlkSk4S7CasMzjQOW5C4QXJXjztHP_MaGMvWF0C4CQxZkn_6lmIENuro2gv
ew3LTTvAv4ljESkcBP1iT7fGcQBE621ZO_8_RLn8XtDFmUyWvayguhvuhp4mwuL4
fFYXvwdWWVt_15X1HL1uCaOyXA88SQpjpxGN8ZuAtBc"},
{
"ContentType": "application/pkcs-12",
"Data": "
PUu_AzFikCBEYq1jB4d5pxCEsnvhq9iW4sXwf--3E8n-qr7HPEWXU2HWqtTjXA0E
Hallam-Baker November 22, 2014 [Page 13]
Internet-Draft OmniBroker Publication Protocol May 2014
1NQDWhJrxFM-o-EK1_gVGXKuSaGjndRVUm1p0ec-Vb5C5EBD4a0509ky0JaT1iMT
O-sCgBWkfHd-SOjSCbZxpTVZX_na3M0D12uoKCRDJcc39bDWebKrw3IEoJPFbuEn
PzGMmoYcs6cVpSl18BCj6t6-rZTSyIVk11NBuhZZ8CotbmdcqKs4_ORaufBgzNzd
o9rE-84MCBh-H3IkNZTuuakWOngdgSPkiOUuDd7k7YK-JNXwpDFWJeTiNxJiLOKE
vzPo8alcstgdnnb9dVu6uIz_-SXNMj7L5N3iuNRx8ZgWIaCVRDes6HuLqnEZXL-a
B1ZxUUvTPs-DUoNndpjsy5k5T1lwLuw7zCevqEBkxb1WpX4T8QBlDpLq1xjxW7tC
LUJyrCTRNrAP2t0OMo8z32_V3UZ5Qd5dwTELCfMqUAbDj9dZsKK4mhcdE6hArkr0
_XkzrIcL"}]}}
3.4. Request Network Configuration
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.
3.4.1. Example: Coffe Pot Service Registration.
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:
Hallam-Baker November 22, 2014 [Page 14]
Internet-Draft OmniBroker Publication Protocol May 2014
POST /.well-known/omni-publish/ HTTP/1.1
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Session: Value=cWUCjw6DTbyS8o1jkKSfLsJWb_8icI_HTb1Tpb80FJo;
Id=vVuUnw2Pi0xlHB2OFnbOBTDmLn9qC1HhEjUkJMHfCtBZRCPXc1GzPw8TLm1b
8asS-GCtD8H681WvoGW0DcEgNMDUc0UZu-ZPo_wA9f8f-bk
Host: localhost:8080
Content-Length: 313
Expect: 100-continue
{
"AdvertiseRequest": {
"Service": [{
"Identifier": [{
"Name": "Example.com",
"Service": "_make_coffee._wks."}],
"Connection": {
"IPAddress": "10.1.2.3",
"IPPort": 666,
"Transport": "TLS",
"TransportPolicy": "TLS=Required"}}]}}
The advertisement request succeeds and the OmniPublish service
reports the successful outcome:
POST /.well-known/omni-publish/ HTTP/1.1
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Session: Value=cWUCjw6DTbyS8o1jkKSfLsJWb_8icI_HTb1Tpb80FJo;
Id=vVuUnw2Pi0xlHB2OFnbOBTDmLn9qC1HhEjUkJMHfCtBZRCPXc1GzPw8TLm1b
8asS-GCtD8H681WvoGW0DcEgNMDUc0UZu-ZPo_wA9f8f-bk
Host: localhost:8080
Content-Length: 313
Expect: 100-continue
{
"AdvertiseRequest": {
"Service": [{
"Identifier": [{
"Name": "Example.com",
"Service": "_make_coffee._wks."}],
"Connection": {
"IPAddress": "10.1.2.3",
"IPPort": 666,
"Transport": "TLS",
"TransportPolicy": "TLS=Required"}}]}}
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
Hallam-Baker November 22, 2014 [Page 15]
Internet-Draft OmniBroker Publication Protocol May 2014
to the DNS service which will take some time to propagate. An
estimate of the time required to complete publication is returned.
4. OBPPublish
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.
4.1. OBPPublish Transactions
4.1.1. Advertise
* Request: AdvertiseRequest
* Response: AdvertiseResponse
Advises a broker that one or more Internet services are being offered
with particular attributes.
4.1.2. Credential
* Request: CredentialRequest
* Response: CredentialResponse
Request issue of a cryptographic credential and (optionally) generate
a public keypair
4.1.3. Notify
* Request: NotifyRequest
* Response: NotifyResponse
Notify the publication service that a server state transition has
occurred or is planned.
4.2. OBPPublish Messages
4.2.1. Message: AdvertiseRequest
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.
Service :
OBPQuery.Service [0..Many] Describes a connection to be
established.
Hallam-Baker November 22, 2014 [Page 16]
Internet-Draft OmniBroker Publication Protocol May 2014
4.2.2. Message: AdvertiseResponse
Specifies the connection(s)
Status :
Integer [1..1] Status return code value
StatusDescription :
String [0..1] Describes the status code (ignored by processors)
Service :
OBPQuery.Service [0..Many] Describes a connection that was
established.
4.2.3. Message: CredentialRequest
Request issue of a cryptographic credential and (optionally) generate
a public keypair.
SubjectIdentifier :
String [0..1] The DNS domain or [!RFC2822] account for which
the credential is requested.
Authentication :
TaggedBinary [0..1] Data required by the credential issuer to
authenticate the request. For example a Certificate Signing
Request [!RFC2986].
MakePrivateKey :
Boolean [0..1] If true, requests that a private keypair be
generated and the private component returned to the requestor.
ResponseTypes :
String [0..Many] Types of data requested in response.
4.2.4. Message: CredentialResponse
Returns issued cryptographic credentials.
Status :
Integer [1..1] Status return code value
StatusDescription :
String [0..1] Describes the status code (ignored by processors)
Credential :
TaggedBinary [0..1] The requested credential type, typically a
PKIX End Entity certificate.
Hallam-Baker November 22, 2014 [Page 17]
Internet-Draft OmniBroker Publication Protocol May 2014
Support :
TaggedBinary [0..Many] Supporting data for the issued
credential. For example one or more chains of certificate
signing certificates, OCSP [!RFC6960] tokens etc.
SecretKey :
TaggedBinary [0..1] The secret key for the requested credential
(if requested).
Expires :
DateTime [0..1] The time at which the credential will cease to
be accepted by relying parties.
EarliestRenewal :
DateTime [0..1] The earliest time at which the issuer will
accept renewal.
LatestRenewal :
DateTime [0..1] The latest time at which the issuer suggests
requesting renewal.
4.2.5. Message: NotifyRequest
CurrentState :
String [0..1] Current state of the requestor
NextState :
String [0..1] State that the Requestor plans to enter
Earliest :
DateTime [0..1] Earliest time at which the transition is
expected to complete
Latest :
DateTime [0..1] Latest time at which the transition is expected
to complete
4.2.6. Message: NotifyResponse
Status :
Integer [1..1] Status return code value
StatusDescription :
String [0..1] Describes the status code (ignored by processors)
Hallam-Baker November 22, 2014 [Page 18]
Internet-Draft OmniBroker Publication Protocol May 2014
4.3. OBPPublish Structures
4.3.1. Structure: TaggedBinary
A sequence of values of the same type.
ContentType :
String [0..1] MIME Content Type of Data
Data :
Binary [0..1] Opaque binary data
5. Transport Bindings and Identifiers
The transport binding options for Omnibroker Publication are
identical to those offered for Omnibroker Discovery [I-D.hallambaker-
omnibroker].
5.1. Content-Type Identifiers
The following content identifiers are defined elsewhere and repeated
here for the convenience of implementers.
application/ocsp-response
OCSP Response token as specified in [!RFC6090].
application/pkix-cert
A single DER encoded PKIX Certificate as specified in
[!RFC5280].
TBS
A Certificate Transparency notary chain as specified in
[~RFC6962].
application/pkcs-12
A PKCS#12 encrypted private key.
6. Acknowledgements
Rob Stradling, Robin Alden...
7. Security Considerations
7.1. Denial of Service
7.2. Breach of Trust
7.3. Coercion
Hallam-Baker November 22, 2014 [Page 19]
Internet-Draft OmniBroker Publication Protocol May 2014
8. IANA Considerations
[TBS list out all the code points that require an IANA registration]
9. References
9.1. Normative References
[RFC6960] Santesson, S.,Myers, M.,Ankney, R.,Malpani, A.,Galperin,
S.,Adams, C., "X.509 Internet Public Key Infrastructure
Online Certificate Status Protocol - OCSP", RFC 6960, June
2013.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April
2001.
[RFC5280] Cooper, D.,Santesson, S.,Farrell, S.,Boeyen, S.,Housley,
R.,Polk, W., "Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL)
Profile", RFC 5280, May 2008.
[RFC6090] McGrew, D.,Igoe, K.,Salter, M., "Fundamental Elliptic
Curve Cryptography Algorithms", RFC 6090, February 2011.
[I-D.hallambaker-omnibroker] Hallam-Baker, P, "OmniBroker Protocol",
Internet-Draft draft-hallambaker-omnibroker-07, 21 January
2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2986] Nystrom, M.,Kaliski, B., "PKCS #10: Certification Request
Syntax Specification Version 1.7", RFC 2986, November
2000.
[I-D.hallambaker-wsconnect] Hallam-Baker, P, "JSON Service Connect
(JCX) Protocol", Internet-Draft draft-hallambaker-
wsconnect-05, 21 January 2014.
9.2. Informative References
[RFC6962] Laurie, B.,Langley, A.,Kasper, E., "Certificate
Transparency", RFC 6962, June 2013.
Author's Address
Phillip Hallam-Baker
Comodo Group Inc.
philliph@comodo.com
Hallam-Baker November 22, 2014 [Page 20]
