One document matched: draft-hallambaker-omnibroker-07.xml
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[
<!ENTITY rfc2629 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml'>
<!ENTITY RFC1035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC5280 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC3642 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3642.xml">
<!ENTITY RFC4033 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY RFC4055 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4055.xml">
<!ENTITY RFC4648 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml">
<!ENTITY RFC5395 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5395.xml">
<!ENTITY RFC4366 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4366.xml">
<!ENTITY RFC4627 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4627.xml">
<!ENTITY RFC2616 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
<!ENTITY RFC5055 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5055.xml">
<!ENTITY RFC6698 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6698.xml">
<!ENTITY RFC6962 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6962.xml">
<!ENTITY RFC4648 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml">
<!ENTITY RFC3339 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3339.xml">
<!ENTITY draft-hallambaker-httpsession SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-hallambaker-httpsession-01.xml">
<!ENTITY draft-hallambaker-wsconnect SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-hallambaker-wsconnect-02.xml">
<!ENTITY draft-hallambaker-jsonbcd SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-hallambaker-jsonbcd-00.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-hallambaker-omnibroker-07" ipr="trust200902">
<front>
<title abbrev="OmniBroker Protocol">OmniBroker Protocol</title>
<author fullname="Phillip Hallam-Baker" initials="P. M." surname="Hallam-Baker">
<organization>Comodo Group Inc.</organization>
<address>
<email>philliph@comodo.com</email>
</address>
</author>
<date day="21" month="January" year="2014" />
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<abstract>
<t>
An Omnibroker is an agent chosen and trusted by an Internet user to
provide information such as name and certificate status information
that are in general trusted even if they are not trustworthy.
Rather than acting as a mere conduit for information provided by
existing services, an Omnibroker is responsible for curating those
sources to protect the user.
</t>
<t>
The Omnibroker Protocol (OBP) provides an aggregated interface to
trusted Internet services including DNS, OCSP and various forms
of authentication service. Multiple transport bindings are
supported to permit efficient access in virtually every common
deployment scenario and ensure access in any deployment
scenario in which access is not being purposely denied.
</t>
</abstract>
</front>
<middle>
<section title="Definitions">
<section title="Requirements Language">
<t>
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 <xref target="RFC2119">RFC 2119</xref>.
</t>
</section>
</section>
<section title="Purpose">
<t>
Today, a network client is required to make queries against multiple
information sources to establish a secure connection to a network
resource. A DNS query is required to translate network names to
Internet addresses. If TLS transport is used, an OSCP query may
be required to validate the server certificate. Support for client
authentication may require interaction with another service.
</t>
<t>
Servers require similar support when accepting Internet connections.
Even though most networking infrastructure supports some form
of network administration, it is left to the network administrator
to fill in the gap between server applications and network
infrastructure. Making use of such facilities is rarely cost effective
except at the very largest installations.
</t>
<t>
An Omnibroker is a trusted agent that acts as a single point of
service for client queries requesting a connection to a named network
resource and server advertisements accepting connections to a named
network resource.
</t>
<section title="Omnibroker Implementation">
<t>
Omnibroker is implemented as a JSON/REST Web service using Jason Connect
(JCX) to establish and manage the long term trust relationship with the Omnibroker
provider.
</t>
<section title="Establishing service">
<t>
In normal use, an omnibroker client receives service from a single
Omnibroker service provider. For performance and reliability reasons,
an Omnibroker service provider is expected to provide multiple
Omnibroker service instances.
</t>
<t>
An Omnibroker client acquires the network address information
and credentials necessary to access an omnibroker service using
the JCX Web Service to establish a connection binding. To ensure
reliabilty and the ability to access the service in all circumstances,
an Omnibroker connection binding SHOULD specify multiple service
instances.
</t>
</section>
<section title="Protocol Bindings">
<t>
Due to the need for low latency and the need to function in
a compromised network environment, three protocol bindings are defined:
<list>
<t>
A HTTP binding using HTTP <xref target="RFC2616" /> for session layer framing and
HTTP Session Continuation
<xref target="I-D.hallambaker-httpsession" /> for message authentication
and JSON encoding <xref target="RFC4627" /> of protocol messages.
</t>
<t>
A UDP Binding using JSON-B <xref target="I-D.hallambaker-jsonbcd" />for
framing and encoding of protocol messages.
</t>
<t>
A DNS Binding using DNS <xref target="RFC4627" /> TXT record queries with
Base32 and Base64 encoding for transport and framing and JSON-B for
encoding of protocol messages.
</t>
</list>
</t>
<t>
The implementation overhead of support for three different protocol
bindings is reduced by the choice of a binary encoding for JSON (JSON-B)
that is very close in structure to JSON encoding allowing encoders
and decoders to support both encodings with minimal additional code.
</t>
<t>
Regardless of the protocol binding used, all Omnibroker messages are
authenticated with protection against replay attack under the cryptographic
credentials established in the connection binding service instance.
</t>
</section>
</section>
<section title="Omnibroker Query Service">
<t>
Directing queries through a single point of contact has performance,
relability and security advantages. Directing queries to multiple
network information sources degrades performance and may cause a
connection request to fail if an information resource is not available.
This has led many application providers to limit the information
sources they consult. Directing queries through an Omnibroker allows
as many information sources to be brought to bear as the broker has
local cached data for without loss of performance or reliability.
</t>
<t>
Making use of additional data sources allows the broker to 'curate'
the response. If the broker knows that a Web site always returns a
redirect to a TLS secured version of the same site, it can tell a
Web Browser to go straight to the secure version.
If a Web Server is hosted on a known botnet, the Omnibroker
can tell the client that it really does not want to visit that
location.
</t>
<t>
Unlike the traditional DNS configuration, an Ombinbroker client
decides which source(s) of trusted information to use rather than
relying on whatever happens to be the nearest source to hand.
</t>
<t>
The traditional DNS approach
creates an obvious security risk as DNS is a trusted service
and deciding to choose a random DNS service advertised by the
local DHCP service is clearly a poor decision process for a trusted
service.
</t>
</section>
<section title="Omnibroker Advertisement Service">
<t>
Directing service advertisements to a single point of contact has
similar benefits. The single point of contact can take responsibility
for managing load balancing. Firewall and router configurations
can be set automatically.
Anti-abuse technologies such as
IP address filters and rate limiting devices can be switched in
as required.
</t>
<t>
In simple network configurations such as a residential
</t>
</section>
<section title="Walled Gardens">
<t>
IETF culture has traditionally resisted attempts to establish
partitions within the open Internet with restricted access to
network resources or compromised security. Such 'Walled Gardens'
models typically exist for the benefits of those who own the walls
rather than those forced to live inside them.
</t>
<t>
While virtually all residential Internet users reject such controls,
most find them acceptable, if not desirable in workplaces and schools.
</t>
<t>
Omnibroker simplifies the process of establishing such a walled
garden but does not make the walls any easier to defend.
</t>
<section title="Censorship">
<t>
From a censorship point of view, the censorship concerns of running
an Omnibroker are essentially the same as those of running a DNS
service. The party who decides which discovery service to use can
determine which content is visible to the users.
</t>
</section>
<section title="Trust Substitution">
<t>
Like SCVP <xref target="RFC5055" /> and XKMS [TBS]
<!--<xref target="I-D.hallambaker-httpsession" />-->, Omnibroker permits an Internet client to
delegate some or all aspects of PKIX <xref target="RFC5280" />
certificate path chain discovery
and validation.
</t>
<t>
In the normal mode of operation, the Omnibroker service performs
only path chain discovery, leaving the client to re-check the
PKIX certificate path before relying on it. This gives the Omnibroker
the power to veto a client connection to a server that it considers to be
unsafe but not the power to tell the client to trust a site of its
own choosing.
</t>
<t>
This ability to veto but not assert trust is appropriate and sufficient
for the vast majority of network applications. It allows the broker
to make use of additional path validation checks that are not supported
in the client such as DANE <xref target="RFC6698" /> or Certificate
Transparency <xref target="RFC6962" />.
</t>
<t>
There are however some workplace environments where the ability
to access external network resources with strong encryption is
not permissible by enterprise policy or in some cases by law.
An intelligence analyst working at the NSA may have a need to
access external Web sites that contain important information
but must on no account have access to a covert channel that
could be used to exfiltrate information. Certain Financial
institutions with access to valuable commercial information are
required to monitor and record all communications into and out
of the company to deter insider trading.
</t>
<t>
The traditional response to such needs has been to tell the
parties affected to look elsewhere for support. As a consequence
the techniques used to satisfy such requirements are generally
unfriendly to network applications in general and have in some
cases put the public Web PKI trust infratructure at risk.
</t>
<t>
There is an argument to be made that rather than attempting to
prohibit such activities entirely, it would be better to provide
a principled method of achieving those ends and for mainstream
software providers to support it in such a fashion that ensures that
network applications configured for that mode of use can be readilly
identified as such by end users.
</t>
</section>
<section title="Censorship Bypass">
<t>
As the preceeding examples demonstrate, a party with control over
the Omnibroker service chosen by a user has full control over the
network activities of that user. An important corrolary of this
fact is that all a user need do to achieve full control over
their network activities is to run their own Omnibroker service
and connect to that.
</t>
<t>
For example such an Omnibroker service might be configured to
return connection data for permitted domestic Web sites as normal
but direct attempts to connect to forbidden foreign news or
social media through a privacy network such as TOR.
</t>
</section>
</section>
</section>
<section title="Use">
<t>
[For illustrative purposes, all the examples in this section
are shown using the Web Services Transport binding.
Examples of other transport bindgins are shown in
section [TBS].]
</t>
<t>
[Alice establishes her connection binding to an omnibroker
service provider]
</t>
<section title="Connection Broker">
<t>
The OBP service connection broker answers the query 'what connection
parameters should be used to establish the best connection
to interract with party X according to protocol Y. Where 'best'
is determined by the Omnibroker which MAY take into account
parameters specified by the relying party.
</t>
<section title="Service Connection Broker">
<t>
The OBP service connection broker supports and extends the traditional
DNS resolution service that resolves a DNS name (e.g. www.example.com) to
return an IP address (e.g. 10.1.2.3).
</t>
<t>
When using an Omnibroker as a service connection broker, a client
specifies both the DNS name (e.g. www.example.com) and the
Internet protocol to be used (e.g. _http._tcp). The returned
connection parameters MAY include:
</t>
<t>
<list>
<t>
The IP protocol version, address and port number to
establish a connection to.
</t>
<t>
If appropriate, a security transport such as TLS or IPSEC.
</t>
<t>
If appropriate, a description of a service credential such
as a TLS certificate or a constraint on the type of certificates
that the client should consider acceptable.
</t>
<t>
If appropriate, application protocol details such as
version and protocol options.
</t>
</list>
</t>
<t>
If an attempt to connect with the parameters specified fails, a
client MAY report the failure and request a new set of parameters.
</t>
<section title="Service Connection Broker Example">
<t>
Alice uses her Web browser to
access the URL http://www.example.com/. The Web browser sends a
QueryConnectRequest
request to obtain the best connection parameters for the
http protocol at
www.example.com:
</t>
<figure>
<artwork>
<![CDATA[POST /.well-known/OmniQuery/ HTTP/1.1
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Session: Value=GXt4UiDbHMO0q39e1N-0MEKKurfw-yAgIPMJ5IgZmSE;
Id=Jg3BJ086IutOvyLpYAbJZg7CHg2s7MoL81sRM15RUI7Tk0U2Hh9j7UpjdGIj
hcqVodbik_kq1zOK1nXqgBcfSxZRE9wJyTDr3ll6Yf7A_Pk
Host: localhost
Content-Length: 123
Expect: 100-continue
{
"QueryConnectRequest": {
"Identifier": {
"Name": "Example.com",
"Service": "_http",
"Port": 80}}}
]]>
</artwork>
</figure>
<t>
The service responds with an ordered list of possible connections.
In this case the site is accessible via plain TCP transport or with
TLS. Since TLS is the preferred protocol, that connection is
listed first.
</t>
<figure>
<artwork>
<![CDATA[HTTP/1.1 OK
Content-Length: 335
Date: Tue, 09 Jul 2013 21:38:18 GMT
Server: Microsoft-HTTPAPI/2.0
{
"QueryConnectResponse": {
"Status": 200,
"Connection": [{
"IPAddress": "10.3.2.1",
"IPPort": 443,
"Transport": "TLS",
"TransportPolicy": "TLS=Optional",
"ProtocolPolicy": "Strict"},
{
"IPAddress": "10.3.2.1",
"IPPort": 80,
"ProtocolPolicy": "Strict"}]}}
]]>
</artwork>
</figure>
</section>
</section>
<section title="Peer Connection Broker">
<t>
Each OBP request identifies both the account under which the
request is made and the device from which it is made. An OBP broker
is thus capable of acting as a peer connection broker service
or providing a gateway to such a service.
</t>
<t>
When using Omnibroker as a peer connection broker, a client
specifies the account name and DNS name of the party with which
a connection is to be established (e.g. alice@example.com)
and the connection protocol to be used (e.g. _xmpp-client._tcp)
</t>
<t>
The returned
connection parameters are similar to those returned in response to a
service broker query.
</t>
<section title="Service Connection Broker Example">
<t>
Although the QueryConnectResponse returned the hash of a PKIX
certificate considered valid for that connection, the server
returns a different certificate which the client verifies using
the ValidateRequest query.
</t>
<figure>
<artwork>
<![CDATA[POST /.well-known/OmniQuery/ HTTP/1.1
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Session: Value=HzGgeCNwxHcyvrkr-7Y4NvHINT7VVB9zvLEYKGjg6q4;
Id=Jg3BJ086IutOvyLpYAbJZg7CHg2s7MoL81sRM15RUI7Tk0U2Hh9j7UpjdGIj
hcqVodbik_kq1zOK1nXqgBcfSxZRE9wJyTDr3ll6Yf7A_Pk
Host: localhost
Content-Length: 1110
Expect: 100-continue
{
"ValidateRequest": {
"Service": {
"Identifier": [{
"Name": "example.com"}]},
"Credential": [{
"Data":
"MIIC0DCCAbigAwIBAgIQQut6m1F0PodIjIzop_d1uDANBgkqhkiG9w0B
AQUFADARMQ8wDQYDVQQDEwZWb29kb28wHhcNMTMwNjI2MTczOTQyWhcNM
TQwNjI2MDAwMDAwWjARMQ8wDQYDVQQDEwZWb29kb28wggEiMA0GCSqGSI
b3DQEBAQUAA4IBDwAwggEKAoIBAQCdc7Qgx71o6Tq5dFUUhcCn8Nt-2Y9
SGhm3WvsMYIqOIcHq3gjIKN9FWvXzpBbTjz4lCwx-CJT82RBLNDFtsysf
c0G7K_RsNKosYaM-L-DshO6R_314tptn9gnT9tjTPXuiiICQlAP83BuTI
148iEJWL36vbmv5AG6vrtk3T6ah5r2hBXQjt46sLQYweiM-peYIhPTIy9
OYugogfqdzPvaJpDfAukqJBXqMxfscagKPYAGPaICKhobKr11aPam1Tch
k2cBbtuYgSDz6ZGttsKE2omDbcmhbF7gBpRug-E2OH79Q4EVlSSoO9gZ6
AF4Km1A9uK9W_Pg8EPugY3Mgns6lAgMBAAGjJDAiMAsGA1UdDwQEAwIEM
DATBgNVHSUEDDAKBggrBgEFBQcDATANBgkqhkiG9w0BAQUFAAOCAQEACK
9LQNkewOOugaYhs4LfE3xdrRzrcaR0w5cf3wVcgR0ZZo98rDOtu3FAexp
dh6vNaIdU4zAzNJPKKSso3XF2LpQZovKIpUuN9pkZqslqZ0TLXqlyXMbh
eShcqIP1-m6qjZOp95N7jwgxBlEmi_ne-rg1DicXFtAu90LpAZludaQGA
yrj-LC37gzeMo2AG7BAuyFURXJFfxjpGmnueuYfzZIMIQY-lNl6qm_vSM
Iz4uUKqq4lWndahnkJAwI2p5zUM0z3O6OMr_zr8eyrdAL__H4NnG3gVyB
bNoSbvbkxUt_C3oBwFFTupzRMQqJVjzbApyw5H0OzJPJKKkxxhmIYTg"}
]}}
]]>
</artwork>
</figure>
<t>
The service validates the certificate according to the
Omnibroker service policy.
</t>
<figure>
<artwork>
<![CDATA[HTTP/1.1 OK
Content-Length: 45
Date: Tue, 09 Jul 2013 21:38:18 GMT
Server: Microsoft-HTTPAPI/2.0
{
"ValidateResponse": {
"Status": 200}}
]]>
</artwork>
</figure>
</section>
</section>
<section title="Credential Validation">
<t>
The credential validation query provides certificate path
validation and status checking.
</t>
<t>
The service provided by OBP is similar to that provided by
OCSP and SCVP. Like SCVP, OBP is an agent selected by the
relying party to validate certificates and/or construct
trust paths on its behalf.
</t>
</section>
</section>
<section title="Service Advertisement">
<t>
Service advertisement is the converse of service resolution. An
Internet application wishing to accept inbound connections specifies
one or more sets of connection parameters for the Omnibroker to
register with whatever naming, discovery or other services may
be appropriate.
</t>
<t>
[Examples TBS]
</t>
</section>
</section>
<section title="OBPQuery">
<section title="Message: QMessage">
<!-- No parameters -->
</section>
<section title="Message: QRequest">
<t>
Every query request contains the following common elements:
</t>
<t> <list style="hanging" hangIndent="6">
<t hangText="Index : Integer [0..1] "><vspace />
Index used to request a specific response when multiple
responses are available.
</t>
</list></t>
</section>
<section title="Message: QResponse">
<t>
Every Query Response contains the following common elements:
</t>
<t> <list style="hanging" hangIndent="6">
<t hangText="Status : Integer [1..1] "><vspace />
Status return code value
</t>
<t hangText="Index : Integer [0..1] "><vspace />
Index of the current response.
</t>
<t hangText="Count : Integer [0..1] "><vspace />
Number of responses available.
</t>
</list></t>
</section>
<section title="Structure: Identifier">
<t>
Specifies an Internet service by means of a DNS address and either a
DNS service prefix, an IP port number or both. An Internet peer
connection MAY be specified by additionally specifying an account.
</t>
<t> <list style="hanging" hangIndent="6">
<t hangText="Name : Name [1..1] "><vspace />
The DNS name of the service to connect to.
</t>
<t>
Internationalized DNS names MUST be encoded in punycode
encoding.
</t>
<t hangText="Account : Label [0..1] "><vspace />
Identifies the account to connect to in the case that a peer connection
is to be established.
</t>
<t hangText="Service : Name [0..1] "><vspace />
The DNS service prefix defined for use with DNS records that
take a service prefix including SRV.
</t>
<t hangText="Port : Integer [0..1] "><vspace />
IP Port number.
</t>
<t>
A service identifier MUST specify either a service or a port or both.
</t>
</list></t>
</section>
<section title="Structure: Connection">
<t> <list style="hanging" hangIndent="6">
<t hangText="IPAddress : String [0..1] "><vspace />
IP address in string representation
</t>
<t hangText="IPPort : Integer [0..1] "><vspace />
IP port. 1-65535
</t>
<t hangText="Transport : String [0..1] "><vspace />
Transport (RAW, TLS, IPSEC)
</t>
<t hangText="TransportPolicy : String [0..1] "><vspace />
Transport security policy as specified in [TBS]
</t>
<t hangText="ProtocolPolicy : String [0..1] "><vspace />
Application security policy specification as specified by
the application protocol.
</t>
<t hangText="Advice : Advice [0..1] "><vspace />
Additional information that a service MAY return to support
a service connection identification.
</t>
</list></t>
</section>
<section title="Structure: Credential">
<t> <list style="hanging" hangIndent="6">
<t hangText="Type : String [0..1] "><vspace />
[TBS]</t>
<t hangText="Data : Binary [0..1] "><vspace />
[TBS]</t>
</list></t>
</section>
<section title="Structure: CertificateID">
<t> <list style="hanging" hangIndent="6">
<t hangText="Type : String [0..1] "><vspace />
[TBS]</t>
<t hangText="Data : Binary [0..1] "><vspace />
[TBS]</t>
</list></t>
</section>
<section title="Structure: Advice">
<t>
Additional information that a service MAY return to support
a service connection identification. For example, DNSSEC
signatures chains, SAML assertions, DANE records,
Certificate Transparency proof chains, etc.
</t>
<t> <list style="hanging" hangIndent="6">
<t hangText="Type : Label [0..1] "><vspace />
The IANA MIME type of the content type
</t>
<t hangText="Data : Binary [0..1] "><vspace />
The advice data.
</t>
</list></t>
</section>
<section title="Structure: Service">
<t>
Describes a service connection
</t>
<t> <list style="hanging" hangIndent="6">
<t hangText="Identifier : Identifier [0..Many] "><vspace />
Internet addresses to which the service is to be bound.
</t>
<t hangText="Connection : Connection [0..1] "><vspace />
Service connection parameters.
</t>
</list></t>
</section>
<section title="QueryConnect">
<t>
Requests a connection context to connect to a specified Internet service
or peer.
</t>
</section>
<section title="Message: QueryConnectRequest">
<t>
Specifies the Internet
service or peer that a connection is to be established to and the
acceptable security policies.
</t>
<t> <list style="hanging" hangIndent="6">
<t hangText="Identifier : Identifier [0..1] "><vspace />
Identifies the service or peer to which a connection is
requested.
</t>
<t hangText="Policy : Label [0..Many] "><vspace />
Acceptable credential validation policy.
</t>
<t hangText="ProveIt : Boolean [0..1] "><vspace />
If set the broker SHOULD send advice to permit the client to
validate the proposed connection context.
</t>
</list></t>
</section>
<section title="Message: QueryConnectResponse">
<t>
Returns one or more connection contexts in response to a
QueryConnectRequest Message.
</t>
<t> <list style="hanging" hangIndent="6">
<t hangText="Connection : Connection [0..Many] "><vspace />
An ordered list of connection contexts with the preferred
connection context listed first.
</t>
<t hangText="Advice : Advice [0..1] "><vspace />
Proof information to support the proposed connection context.
</t>
<t hangText="Policy : Label [0..Many] "><vspace />
Policy under which the credentials have been verified.
</t>
</list></t>
</section>
<section title="Advertise">
<t>
Advises a broker that one or more Internet services are
being offered with particular attributes.
</t>
</section>
<section title="Message: AdvertiseRequest">
<t>
Specifies the connection(s) to be established.
</t>
<t>
The attributes required depend on the infrastructure(s) that the
broker is capable of registering the service with.
</t>
<t> <list style="hanging" hangIndent="6">
<t hangText="Service : Service [0..Many] "><vspace />
Describes a connection to be established.
</t>
</list></t>
</section>
<section title="Message: AdvertiseResponse">
<t>
Specifies the connection(s)
</t>
<t> <list style="hanging" hangIndent="6">
<t hangText="Service : Service [0..Many] "><vspace />
Describes a connection that was established.
</t>
</list></t>
</section>
<section title="Validate">
<t>
The Validate query requests validation of credentials
presented to establish a connection. For example credentials
presented by a server in the process of setting up a
TLS session.
</t>
</section>
<section title="Message: ValidateRequest">
<t>
Specifies the credentials to be validated and the purpose
for which they are to be used.
</t>
<t> <list style="hanging" hangIndent="6">
<t hangText="Service : Service [0..1] "><vspace />
Describes the service for which the credentials
are presented for access.
</t>
<t hangText="Credential : Credential [0..Many] "><vspace />
Credentials for which validation is requested.
</t>
<t hangText="CertificateID : CertificateID [0..Many] "><vspace />
OCSP Certificate Identifiers for which validation
is requested.
</t>
<t hangText="Policy : Label [0..Many] "><vspace />
Policy under which the credentials have been verified.
</t>
</list></t>
</section>
<section title="Message: ValidateResponse">
<t>
Reports the status of the credential presented.
</t>
<t> <list style="hanging" hangIndent="6">
<t hangText="Policy : Label [0..Many] "><vspace />
Policy under which the credentials have been verified.
</t>
</list></t>
</section>
</section>
<section title="Transport Bindings">
<t>
To achieve an optimal balance of efficiency and availability,
three transport bindings are defined:
</t>
<t>
<list>
<t hangText="HTTP over TLS">Supports all forms of OBP
transaction in all network environments.</t>
<t hangText="DNS Tunnelling">Provides efficient support for a subset
of OBP query transactions that is accessible in most network
environments.</t>
<t hangText="UDP">
Provides efficient support for all OBP query transactions
and is accessible in most network environments.
</t>
</list>
</t>
<t>
Support for the HTTP over TLS binding is REQUIRED.
</t>
<t>
An OBP message consists of three parts:
<list style="hanging">
<t hangText="Ticket [As necessary]">
If specified, identifies the cryptographic key and algorithm parameters to be used
to secure the message payload.
</t>
<t hangText="Payload [Required]">
If the ticket context does not specify use of an encryption algorithm,
contains the message data. Otherwise contains the
message data encrypted under the
encryption algorithm and key specified in the ticket context.
</t>
<t hangText="Authenticator [Optional]">
If the ticket context specifies use of a Message Authentication
Code (MAC), contains the MAC value calculated over the payload data
using the authentication key bound to the ticket.
</t>
</list>
</t>
<t>
Note that although each of the transport bindings defined in this specification
entail the use of a JSON encoding for the message data, this is not a
necessary requirement for a transport binding.
</t>
<section title="JSON Payload Binding">
<t>
Protocol schema types are mapped to JSON encoding as follows:
<list style="hanging">
<t hangText="Integer">
Data of type Integer is encoded using the JSON number
encoding.</t>
<t hangText="Name">Data of type Name is encoded using the JSON string
encoding.</t>
<t hangText="String">Data of type String is encoded using the JSON string
encoding.</t>
<t hangText="Binary">Data of type Binary is converted to strings using
the Base64url encoding specified in <xref target="RFC4648" />
and encoded using the JSON string type.</t>
<t hangText="DateTime">Data of type DateTime is converted to string using the
UTC time conversion specified in <xref target="RFC3339" /> with a UTC
offset of 00:00.
</t>
</list>
</t>
</section>
<section title="HTTP over TLS">
<t>
OBP requests and responses are mapped to HTTP POST requests
and responses respectively. Java Script Object Notation (JSON)
encoding is used to encode requests and responses.
</t>
<section title="Message Encapsulation">
<t>
Requests and responses are mapped to HTTP POST transactions.
The content of the HTTP message is the message payload.
The Content-Type
MUST be specified as application/json. The Character set MUST
be specified as UTF-8.
</t>
<t>
The Ticket and Authenticator are specified using the Integrity
header as follows:
</t>
<t>
Session: <base64url (authenticator)> ; ticket=<base64url (ticket)>
</t>
</section>
<section title="Example">
<t>
[To be generated from spec]
</t>
</section>
</section>
<section title="DNS Tunnel">
<t>
The DNS Tunnel mode of operation makes use of DNS TXT resource record
requests and responses to tunnel OBP Query requests. Due to the constraints
of this particular mode of operation, use of this transport is in
practice limited to supporting transactions that can be
expressed within 500 bytes. These include the QueryConnect
and ValidateRequest interactions.
</t>
<section title="Request">
<t>Requests are mapped to DNS TXT queries. The request is mapped onto
the DNS name portion of the query by encoding the Ticket, Authenticator
and JSON encoded Payload using Base32 encoding and appending the result to the
service prefix to create a DNS name as follows:
</t>
<t>
<base32(payload)>.<base32(authenticator)>.<base32(ticket)>.Suffix
</t>
<t>
The payload MAY be split across multiple DNS labels at any point.
</t>
</section>
<section title="Response">
<t>
Responses are mapped to DNS TXT records by encoding the Authenticator
and JSON encoded Payload using Base64 encoding and cocatenating the result
with a periods as a separator as follows:
</t>
<t>
<base32(payload)>.<base32(authenticator)>
</t>
</section>
<section title="Example">
<t>
[To be generated from spec]
</t>
</section>
</section>
<section title="UDP">
<t>
The UDP transport MAY be used for transactions where the request
fits into a single UDP packet and the response can be accomadated in
16 UDP packets.
As with the Web Service Binding, Java Script Object Notation (JSON)
encoding is used to encode requests and responses.
</t>
<section title="Request">
<t>The request consists of four message segments containing a Header,
Ticket, Payload and Authenticator. Each message segment begins with a
two byte field that specified the length of the following data segment
in network byte order. The Payload is encoded in JSON encoding and the
remaining fields as binary data without additional encoding.
</t>
<t>
The header field for this version of the protocol (1.0) contains two
bytes that specify the Major and Minor version number of the transport
protocol being 1 and 0 respectively. Future versions of the transport
protocol MAY specify additional data fields.
</t>
<t>
[TBS diagram]
</t>
</section>
<section title="Response">
<t>The response consists of a sequence of packets. Each packet consists
of a header section and a data section.</t>
<t>
The header section consists of a two byte length field followed by two
bytes that speciofy the Major and Minor version number of the transport
protocol (1 and 0), two bytes that specify the frame number
and the total number of frames and two bytes that specify the message
identifier.
</t>
<t>
[TBS diagram]
</t>
<t>
[Question, should the authenticator be over the whole message
or should each packet have its own authenticator?]
</t>
</section>
<section title="Example">
<t>
[To be generated from spec]
</t>
</section>
</section>
</section>
<section title="Acknowledgements">
<t>
[List of contributors]
</t>
</section>
<section title="Security Considerations">
<section title="Denial of Service">
</section>
<section title="Breach of Trust">
</section>
<section title="Coercion">
</section>
</section>
<section title="To do">
<t>
<list>
<t>
The specification should define and use a JSON security object.
</t>
<t>Formatting of the abstract data items needs to be improved</t>
<t>
Need to specify the UDP transport binding
</t>
<t>
Should specify how each data item is represented in JSON format
somewhere. This is obvious for some of the data types but needs
to be fully specified for things like DateTime.
</t>
<t>
Run the code to produce proper examples.
</t>
<t>
Write an API document
</t>
</list>
</t>
</section>
<section title="IANA Considerations">
<t>
[TBS list out all the code points that require an IANA
registration]
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC1035;
&RFC2119;
&RFC2616;
&RFC4627;
&RFC4648;
&RFC3339;
&RFC4366;
&RFC5055;
&RFC5280;
&draft-hallambaker-wsconnect;
&draft-hallambaker-httpsession;
&draft-hallambaker-jsonbcd;
<reference anchor="X.509">
<front>
<title>
ITU-T Recommendation X.509 (11/2008): Information
technology - Open systems interconnection - The
Directory: Public-key and attribute certificate
frameworks
</title>
<author>
<organization>
International Telecommunication Union
</organization>
</author>
<date month="November" year="2008" />
</front>
<seriesInfo name="ITU-T Recommendation" value="X.509" />
<format type="HTML" target="http://www.itu.int/itu-t/recommendations/rec.aspx?rec=X.509" />
</reference>
<reference anchor="X.680">
<front>
<title>
ITU-T Recommendation X.680 (11/2008): Information
technology - Abstract Syntax Notation One (ASN.1):
Specification of basic notation
</title>
<author>
<organization>
International Telecommunication Union
</organization>
</author>
<date month="November" year="2008" />
</front>
<seriesInfo name="ITU-T Recommendation" value="X.680" />
<format type="HTML" target="http://www.itu.int/itu-t/recommendations/rec.aspx?rec=X.680" />
</reference>
</references>
<references title="Non Normative References">
&RFC6698;
&RFC6962;
</references>
<section title="Example Data.">
<t>
</t>
<section title="Ticket A">
<t>
</t>
</section>
<section title="Ticket B">
<t>
</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 04:58:14 |