[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08

Internet Engineering Task Force                          P. Hallam-Baker
Internet-Draft                                         Comodo Group Inc.
Intended status: Standards Track                           July 16, 2012
Expires: January 17, 2013


                          OmniBroker Protocol
                    draft-hallambaker-omnibroker-01

Abstract

   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.

   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.

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."

   This Internet-Draft will expire on January 17, 2013.

Copyright Notice

   Copyright (c) 2012 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



Hallam-Baker            Expires January 17, 2013                [Page 1]

Internet-Draft             OmniBroker Protocol                 July 2012


   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.


Table of Contents

   1.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
   2.  Purpose  . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  A Curated Service  . . . . . . . . . . . . . . . . . . . .  4
     2.2.  Connection Broker  . . . . . . . . . . . . . . . . . . . .  6
       2.2.1.  Service Connection Broker  . . . . . . . . . . . . . .  6
       2.2.2.  Peer Connection Broker . . . . . . . . . . . . . . . .  7
       2.2.3.  Connection Broker API  . . . . . . . . . . . . . . . .  7
     2.3.  Service Advertisement  . . . . . . . . . . . . . . . . . .  8
       2.3.1.  Connection Advertisement API . . . . . . . . . . . . .  8
     2.4.  Credential Validation Broker . . . . . . . . . . . . . . .  8
     2.5.  Authentication Gateway . . . . . . . . . . . . . . . . . .  8
     2.6.  Credential Announcement  . . . . . . . . . . . . . . . . .  8
   3.  Omnibroker Connection Maintenance Service  . . . . . . . . . .  9
     3.1.  Authentication . . . . . . . . . . . . . . . . . . . . . .  9
       3.1.1.  Broker Authentication  . . . . . . . . . . . . . . . .  9
       3.1.2.  Device Authentication  . . . . . . . . . . . . . . . .  9
       3.1.3.  Illustrative example . . . . . . . . . . . . . . . . .  9
     3.2.  OBPConnection  . . . . . . . . . . . . . . . . . . . . . . 13
       3.2.1.  Message: Request . . . . . . . . . . . . . . . . . . . 13
       3.2.2.  Structure: Cryptographic . . . . . . . . . . . . . . . 13
       3.2.3.  Structure: ImageLink . . . . . . . . . . . . . . . . . 14
       3.2.4.  Structure: Connection  . . . . . . . . . . . . . . . . 14
       3.2.5.  Bind . . . . . . . . . . . . . . . . . . . . . . . . . 15
       3.2.6.  Message: BindRequest . . . . . . . . . . . . . . . . . 15
       3.2.7.  Message: BindResponse  . . . . . . . . . . . . . . . . 15
       3.2.8.  Message: OpenRequest . . . . . . . . . . . . . . . . . 16
       3.2.9.  Message: OpenResponse  . . . . . . . . . . . . . . . . 17
       3.2.10. Message: TicketRequest . . . . . . . . . . . . . . . . 17
       3.2.11. Message: TicketResponse  . . . . . . . . . . . . . . . 18
       3.2.12. Unbind . . . . . . . . . . . . . . . . . . . . . . . . 18
       3.2.13. Message: UnbindRequest . . . . . . . . . . . . . . . . 18
       3.2.14. Message: UnbindResponse  . . . . . . . . . . . . . . . 18
   4.  Omnibroker Query Service . . . . . . . . . . . . . . . . . . . 18
     4.1.  OBPQuery . . . . . . . . . . . . . . . . . . . . . . . . . 18
     4.2.  Message: Request . . . . . . . . . . . . . . . . . . . . . 18



Hallam-Baker            Expires January 17, 2013                [Page 2]

Internet-Draft             OmniBroker Protocol                 July 2012


     4.3.  Message: Response  . . . . . . . . . . . . . . . . . . . . 18
     4.4.  Structure: Identifier  . . . . . . . . . . . . . . . . . . 19
     4.5.  Structure: Connection  . . . . . . . . . . . . . . . . . . 19
     4.6.  Structure: Advice  . . . . . . . . . . . . . . . . . . . . 20
     4.7.  Structure: Service . . . . . . . . . . . . . . . . . . . . 21
     4.8.  QueryConnect . . . . . . . . . . . . . . . . . . . . . . . 21
     4.9.  Message: QueryConnectRequest . . . . . . . . . . . . . . . 21
     4.10. Message: QueryConnectResponse  . . . . . . . . . . . . . . 21
     4.11. Advertise  . . . . . . . . . . . . . . . . . . . . . . . . 22
     4.12. Message: AdvertiseRequest  . . . . . . . . . . . . . . . . 22
     4.13. Message: AdvertiseResponse . . . . . . . . . . . . . . . . 22
     4.14. Validate . . . . . . . . . . . . . . . . . . . . . . . . . 22
     4.15. Message: ValidateRequest . . . . . . . . . . . . . . . . . 22
     4.16. Message: ValidateResponse  . . . . . . . . . . . . . . . . 23
     4.17. QueryCredentialPassword  . . . . . . . . . . . . . . . . . 23
     4.18. Message: CredentialPasswordRequest . . . . . . . . . . . . 23
     4.19. Message: CredentialPasswordResponse  . . . . . . . . . . . 23
   5.  Transport Bindings . . . . . . . . . . . . . . . . . . . . . . 23
     5.1.  HTTP over TLS  . . . . . . . . . . . . . . . . . . . . . . 24
       5.1.1.  Message Encapsulation  . . . . . . . . . . . . . . . . 24
       5.1.2.  Example  . . . . . . . . . . . . . . . . . . . . . . . 25
     5.2.  DNS Tunnel . . . . . . . . . . . . . . . . . . . . . . . . 25
       5.2.1.  Request  . . . . . . . . . . . . . . . . . . . . . . . 25
       5.2.2.  Response . . . . . . . . . . . . . . . . . . . . . . . 25
       5.2.3.  Example  . . . . . . . . . . . . . . . . . . . . . . . 25
     5.3.  UDP  . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
       5.3.1.  Request  . . . . . . . . . . . . . . . . . . . . . . . 25
       5.3.2.  Response . . . . . . . . . . . . . . . . . . . . . . . 26
       5.3.3.  Example  . . . . . . . . . . . . . . . . . . . . . . . 26
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 26
     7.1.  Denial of Service  . . . . . . . . . . . . . . . . . . . . 26
     7.2.  Breach of Trust  . . . . . . . . . . . . . . . . . . . . . 26
     7.3.  Coercion . . . . . . . . . . . . . . . . . . . . . . . . . 26
   8.  To do  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
   9.  For discussion.  . . . . . . . . . . . . . . . . . . . . . . . 27
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 27
   11. Normative References . . . . . . . . . . . . . . . . . . . . . 27
   Appendix A.  Example Data. . . . . . . . . . . . . . . . . . . . . 28
     A.1.  Ticket A . . . . . . . . . . . . . . . . . . . . . . . . . 28
     A.2.  Ticket B . . . . . . . . . . . . . . . . . . . . . . . . . 28
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28









Hallam-Baker            Expires January 17, 2013                [Page 3]

Internet-Draft             OmniBroker Protocol                 July 2012


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 RFC 2119 [RFC2119].


2.  Purpose

   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 and
   providing autheticated, curated results to the endpoint client.

   Unlike the traditional trusted information services that are expected
   to deliver the same response to a query regardless of who asks the
   question, OBP permits an Omnibroker to return a response that is
   tailored to the specific party asking the question.  This permits the
   use of an authentication approach that has negligible impact on
   performance and permits an Omnibroker to answer questions that a
   traditional public Internet information service could not.  In
   particular, an Omnibroker can broker peer to peer connections

2.1.  A Curated Service

   In the traditional configuration, an Internet host accepts DNS
   service from the IP address specified by the local network provider,
   frequently the DNS server advertised by the local DHCP service.  This
   approach creates an obvious security risk as DNS is clearly a trusted
   service and a random DNS service advertised by the local DNS is
   clearly not trustworthy.

   A policy of only using a chosen DNS service provides a reduction in
   risk but only a modest one since the standard DNS service does not
   provide authenticated results.  Many local area networks intercept
   all DNS traffic and process it through the local DNS server
   regardless of the intended destination IP address.  This practice is
   highly desirable if it would prevent a client from accessing an
   untrustworthy DNS service in place of a trustworthy local DNS service
   and extreemly undesirable in the contrary case.

   In addition to ensuring the authenticity of DNS resolution responses,
   such services frequently provide filtering of Internet addresses the
   network provider considers undesirable.  Many workplaces block access



Hallam-Baker            Expires January 17, 2013                [Page 4]

Internet-Draft             OmniBroker Protocol                 July 2012


   to Web sites that are considered detrimental to productivity.  Many
   parent subscribe to services that filter content they consider
   undesirable.  While the value of such services is debatable they are
   services that those customers have chosen to deploy on their networks
   to meet their perceived security requirements.  New security
   proposals that do not support such capabilities or seek to actually
   circumvent them will not be acceptable to those constituencies.

   While DNS filtering is a form of censorship, not all forms of DNS
   filering are intrinsically undesirable censorship.  Spam filtering is
   also a form of censorship albeit one that is not normally regarded as
   such because it most Internet users now consider it to be an
   essential security control.  Anti-Virus tools are also a form of
   censorship.  DNS filtering tools that block access to sites that
   distribute malware are also a form of censorship and are rapidly
   gaining popularity for the same reason.

   While all forms of censorship raise civil liberties concerns,
   censorship should not automatically raise civil liberties objections.
   It is not the fact that filtering is taking place but the party that
   is in control of the filtering that should raise civil liberties
   concerns.  In an Internet of 2 billion users, all users are obliged
   to perform some filtering.  OBP is designed to make the party that is
   in control of the filtering process apparent and provide the end user
   with the ability to select the Omnibroker of their choice.

   DNSSEC provides a means of determining that a DNS record is the
   authentic record published by the source but this capability alone
   does not meet the security requirements for DNS resolution services
   as they have come to be understood since the protocol was first
   proposed.

   Internet users want to be safe from all forms of attack, not just the
   DNS resolver mani-in-the-middle attack that 'end-to-end' deployment
   of DNSSEC is designed to address.  An Internet user is far more
   likely to be directed to a site with a DNS name controlled by a
   criminal gang than be subject to a man-in-the-middle attack.

   Most users would prefer to have an Internet connection that is
   'curated' to remove at least some of the locations they consider to
   be undesirable.  The fact that an organised criminal gang has put a
   host on the Internet does not mean that any other Internet user
   should be obliged to allow it to connect to any of the machines that
   they own.

   The same argument for curating the raw results applies to other forms
   of trusted information service.  The fact that a Certificate
   Authority has issued a digital certificate and considers it to be



Hallam-Baker            Expires January 17, 2013                [Page 5]

Internet-Draft             OmniBroker Protocol                 July 2012


   valid should not mean that the end party is automatically considered
   trustworthy by anyone and for any purpose.

   The deployment of security policy capabilities presents another case
   in which direct reliance on raw data is undesirable.  While security
   policies such as 'host always offers TLS' or 'mail server always
   signs outgoing mail with DKIM' can provide considerable security
   advantages, only some of the security policy information that is
   published is accurate and kept up to date.  Curating such data
   sources typically proves essential if an unacceptable rate of false
   positives is to be avoided.

   Although a client is permitted to curate its own data sources it
   rarely has a sufficient amount of data to make decisions as
   accurately as a network service that can draw on a wide variety of
   additional data including tracking of communication patterns,
   historical data series and third party reputation services.

   Curation in the network offers better asgility than the client
   approach.  Agility is an important consideration when an attacker
   changes their strategy rapidly and repeatedly to counter new
   defensive controls.

   While curating trusted data sources is an established and proven
   practice, current practice has been to curate each source
   individually.  This approach avoids the need to write a new protocol
   but limits the information a curator can leverage to detect potential
   danger.  Leveraging multiple data sources simultaneously allows
   better accuracy than applying each individually.

2.2.  Connection Broker

   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.

2.2.1.  Service Connection Broker

   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).

   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:



Hallam-Baker            Expires January 17, 2013                [Page 6]

Internet-Draft             OmniBroker Protocol                 July 2012


      The IP protocol version, address and port number to establish a
      connection to.

      If appropriate, a security transport such as TLS or IPSEC.

      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.

      If appropriate, application protocol details such as version and
      protocol options.

   If an attempt to connect with the parameters specified fails, a
   client MAY report the failure and request a new set of parameters.

2.2.2.  Peer Connection Broker

   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.

   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)

   The returned connection parameters are similar to those returned in
   response to a service broker query.

2.2.3.  Connection Broker API

   In the traditional BSD sockets API a network client performs a series
   of calls to resolve a network name to a list of IP addresses, selects
   one and establishes an IP connection to a port specified by the
   chosen application protocol.

   OBP anticipates a higher level abstract API that encapsulates this
   complexity, hiding it from the application code.

   In the case that one (or more) OBP services are configured, the
   library supporting the SHOULD obtain connection parameters from the
   OBP service.  Otherwise, it SHOULD establish a connection using the
   traditional calling sequence of resolving a host name to obtain an IP
   address, etc.






Hallam-Baker            Expires January 17, 2013                [Page 7]

Internet-Draft             OmniBroker Protocol                 July 2012


2.3.  Service Advertisement

   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.

2.3.1.  Connection Advertisement API

   OBP anticipates the use of a high level API for connection
   advertisement that is the converse of the Connection broker API.
   Instead of establishing a connection, the API is used to advertise
   that a connection is offered either as a service or a peer.

   An application MAY offer multiple types of connection with different
   connection properties (e.g.  IPv4/IPv6, with and without SSL, etc.).
   This MAY be supported by marking certain properties as being optional
   and/or by permitting the API to be called multiple times with
   different properties specified.

2.4.  Credential Validation Broker

   A credential validation broker reports on the validity and
   trustworthiness of credentials presented to a client by Internet
   services and/or peers.

   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.

2.5.  Authentication Gateway

   Every OBP request is strongly authenticated by means of a shared
   secret that is unique to the account and the device.  This may be
   leveraged to permit use as an authentication gateway, providing
   access to other credentials that the client has established the right
   to use.

   An Authentication Gateway MAY provide access to account names and
   passwords that the account holder has chosen to store in the cloud
   for access to sites that do not support a stronger, cryptographically
   based form of authentication such as OAuth.

2.6.  Credential Announcement

   An Authentication Gateway can only provide access to credentials that
   it has notice of.  A client uses the Credential Announcement



Hallam-Baker            Expires January 17, 2013                [Page 8]

Internet-Draft             OmniBroker Protocol                 July 2012


   transaction to advise the service of a new credential.


3.  Omnibroker Connection Maintenance Service

3.1.  Authentication

   The principle function of the OBP Connection Maintenance Protocol is
   to establish and maintain the cryptographic parameters used to
   authenticate and encrypt

   The user needs to authenticate the broker service regardless of any
   authentication requirements of the broker.

3.1.1.  Broker Authentication

   The OBP connection maintenance protocol transport MUST provide a
   trustworthy means of verifying the identity of the broker (e.g. an
   Extended Validation SSL certificate).

   If the device supports a display capability, authentication of the
   device and user MAY be achieved by means of an authentication image.
   Such an authentication image is generated by the broker and passed to
   the client in the OpenResponse message.  The user then verifies that
   the image presented on the device display is the same as that
   presented on the account maintenance console.

3.1.2.  Device Authentication

   If device authentication is required, the mechanism to be used
   depends on the capabilities of the device, the requirements of the
   broker and the existing relationship between the user and the broker.

   If the device supports some means of data entry, authentication MAY
   be achieved by entering a passcode into the device that was
   previously delivered to the user out of band.

   The passcode authentication mechanism allows the device to establish
   a proof that it knows the passcode without disclosing the passcode.
   This property provides protection against Man-In-The-Middle type
   disclosure attacks.

3.1.3.  Illustrative example

   Alice is an employee of example.com which runs its own local
   omnibroker service.  To configure her machine for use with this
   service, Alice contacts her network administrator who assigns her the
   account identifier 'alice' and obtains a PIN number from the service



Hallam-Baker            Expires January 17, 2013                [Page 9]

Internet-Draft             OmniBroker Protocol                 July 2012


   '1V0FH0-3KSF01-501M'

   Alice enters the values 'alice@example.com' and '1V0FH0-3KSF01-501M'
   into her Omnibroker-enabled Web browser.

   The Web browser uses the local DNS to resolve 'example.com' and
   establishes a HTTPS connection to the specified IP address.  The
   client verifies that the certificate presented has a valid
   certificate chain to an embedded trust anchor under an appropriate
   certificate policy (e.g. compliant with the Extended Validation
   Criteria defined by CA-Browser Forum).

   Having established an authenticated and encrypted TLS session to the
   Omnibroker service, the client sends an OpenRequest message to begin
   the process of mutual authentication.  This message specifies the
   cryptographic parameters supported by the client (Authentication,
   Encryption) and a nonce value (Challenge), device identification
   parameters (DeviceID, DeviceURI, DeviceName) and the name of the
   account being requested.

   The client does not specify the PIN code in the initial request, nor
   is the request authenticated.  Instead the client informs the server
   that it has a PIN code that can be supplied if necessary.

 Post / HTTP/1.0
 [HTTP-Headers...]

 {"OpenRequest": {  "Encryption": ["HS256","HS384","HS512","HS256T128"],
   "Authentication": ["A128CBC","A256CBC","A128GCM","A256GCM"],
   "Account": "alice",
   "Domain": "example.com",
   "HavePasscode": true,
   "HaveDisplay": true,
   "Challenge": "aokb53UJRy3Y75350wo33A==",
   "DeviceID": "Serial:0002212",
   "DeviceURI": "http://comodo.com/dragon/v3.4",
   "DeviceName": "Comodo Dragon"}
 }

   The service receives the request.  If the request is consistent with
   the access control policy for the server it returns a reply that
   specifies the chosen cryptographic parameters (Cryptographic),
   responds to the client issued by the client to establish server proof
   of knowsledge of the PIN (ChallengeResponse) and issues a challenge
   to the client (Challenge).

   The cryptographic parameters specify algorithms to be used for
   encryption and authentication, a shared secret and a ticket value.



Hallam-Baker            Expires January 17, 2013               [Page 10]

Internet-Draft             OmniBroker Protocol                 July 2012


   Note that while the shared secret is exchanged in plaintext form in
   the HTTP binding, the connection protocol MUST provide encryption.

   HTTP/1.0 200 OK

   {"OpenResponse": {  "Status": 203,
     "StatusDescription": "Passcode",
     "Cryptographic": [{  "Protocol": "OBPConnection",
     "Secret": "4Xd1YGY0FLAoricHMgnCUg==",
     "Encryption": "A128CBC",
     "Authentication": "HS256",
     "Ticket": "AAAAAOF3dWBmNBSwKK4nBzIJ
         wlIRYWxpY2VAZXhhbXBsZS5jb21qiRv
         ndQlHLdjvnfnTCjfckws0cHInS6oZI
         0K+OZs7XuaiEc0z/HlrYWRUa+uodUoA"}],
     "Challenge": "kws0cHInS6oZI0K+OZs7Xg==",
     "ChallengeResponse": "t5C+tJO/zuIV0uKOhizWTg=="}}

   To complete the transaction, the client sends a TicketRequest message
   to the serice containing a response to the PIN challenge sent by the
   service (ChallengeResponse).  The TicketRequest message is
   authenticated under the shared secret specified in the OpenResponse
   message.

   Post / HTTP/1.0
   [Content-Integrity: JNpUYCKibOcsHksTEJwUlA==;
       ticket=AAAAAOF3dWB...]

   {"TicketRequest": {  "Ticket": "AAAAAOF3dWBmNBSwKK
        4nBzIJwlIRYWxpY2VAZXhhbXBsZS5jb21qiRv
        ndQlHLdjvnfnTCjfckws0cHInS6oZI0K+OZs7
        XuaiEc0z/HlrYWRUa+uodUoA",
     "ChallengeResponse": "XTjeS06vsPpYaZwmAV+J/Q=="}
   }


   If the response to the PIN challenge is correct, the service responds
   with a message that specifies a set of cryptographic parameters to be
   used to authenticate future interactions with the service
   (Cryptographic) and a set of connection parameters for servers
   supporting the Query Service (Service).

   In this case the server returns three connections, each offering a
   different transport protocol option.  Each connection specifies its
   own set of cryptographic parameters (or will when the code is written
   for that).





Hallam-Baker            Expires January 17, 2013               [Page 11]

Internet-Draft             OmniBroker Protocol                 July 2012


   HTTP/1.0 200 OK

   {"TicketResponse": {  "Status": 200,
     "StatusDescription": "Complete",
     "Cryptographic": [{  "Protocol": "OBPConnection",
     "Secret": "p59UMqIwDd7lVGb5Zf8m7w==",
     "Encryption": "A128CBC",
     "Authentication": "HS256",
     "Ticket": "AAAAAKefVDKiMA3e5VRm+WX/Ju8BQAzCLTmHk40SOUXQqtJdYgs="}
   ],
     "Service": [{  "Name": "obp1.example.com",
     "Port": 443,
     "Address": "10.1.2.3",
     "Priority": 1,
     "Weight": 100}
   ,{  "Name": "dns1.example.com",
     "Port": 53,
     "Address": "10.1.2.2",
     "Priority": 1,
     "Weight": 100}
   ,{  "Name": "udp.example.com",
     "Port": 5000,
     "Address": "10.1.2.2",
     "Priority": 1,
     "Weight": 100}
   ]}
   }


   When Alice's machine is to be transfered to another employee, the
   Unbind transaction is used.  The only parameter required is the
   Ticket identifying the device association (Ticket).


   {"UnbindRequest": {  "Ticket": "AAAAAKefVDKiMA3e5VRm+
   WX/Ju8BQAzCLTmHk40SOUXQqtJdYgs="}
   }


   Since the unbind response represents the termination of the
   relationship with the Omnibroker, the response merely reports the
   success or failure of the request.

                 HTTP/1.0 200 OK

   {"UnbindResponse": {}}





Hallam-Baker            Expires January 17, 2013               [Page 12]

Internet-Draft             OmniBroker Protocol                 July 2012


   The 'Ticket' value presented in the foregoing examples is a sequence
   of binary data generated by the service that is opaque to the client.
   Services MAY generate ticket values with a substructure that enable
   the service to avoid the need to maintain server side state.

   In the foregoing example, the ticket structures generated by the
   service encode the cryptographic parameter data, the shared secret,
   account identifier and an authentication value.  The initial ticket
   value generated additionally encodes the values of the client and
   service challeng values for use in calculating the necessary
   ChallengeResponse.

3.2.  OBPConnection

3.2.1.  Message: Request

   Every query request contains the following common elements:

   Index : Integer [0..1]

         Index used to request a specific response when multiple
         responses are available.

3.2.2.  Structure: Cryptographic

   Parameters describing a cryptographic context.

   Protocol : Label [0..1]

         OBP tickets MAY be restricted to use with either the management
         protocol (Management) or the query protocol (Query).  If so a
         service would typically specify a ticket with a long expiry
         time or no expiry for use with the management protocol and a
         separate ticket for use with the query protocol.

   Secret : Binary [1..1]

         Shared secret

   Encryption : Label [1..1]

         Encryption Algorithm selected

   Authentication : Label [1..1]







Hallam-Baker            Expires January 17, 2013               [Page 13]

Internet-Draft             OmniBroker Protocol                 July 2012


         Authentication Algorithm selected

   Ticket : Binary [1..1]

         Opaque ticket issued by the server that identifies the
         cryptographic parameters for encryption and authentication of
         the message payload.

   Expires : DateTime [0..1]

         Date and time at which the context will expire

3.2.3.  Structure: ImageLink

   Algorithm : Label [0..1]

         Image encoding algorithm (e.g.  JPG, PNG)

   Image : Binary [0..1]

         Image data as specified by algorithm

3.2.4.  Structure: Connection

   Contains information describing a network connection.

   Name : Name [0..1]

         DNS Name.  Since one of the functions of an OBP service is name
         resolution, a DNS name is only used to establish a connection
         if connection by means of the IP address fails.

   Port : Integer [0..1]

         TCP or UDP port number.

   Address : Binary [0..1]

         IPv4 (32 bit) or IPv6 (128 bit) service address

   Priority : Integer [0..1]

         Service priority.  Services with lower priority numbers SHOULD
         be attempted before those with higher numbers.







Hallam-Baker            Expires January 17, 2013               [Page 14]

Internet-Draft             OmniBroker Protocol                 July 2012


   Weight : Integer [0..1]

         Weight to be used to select between services of equal priority.

   Transport : Label [0..1]

         OBP Transport binding to be used valid values are HTTP, DNS and
         UDP.

   Expires : DateTime [0..1]

         Date and time at which the specified connection context will
         expire.

3.2.5.  Bind

   Binding a device is a two step protocol that begins with the Start
   Query followed by a sequence of Ticket queries.

3.2.6.  Message: BindRequest

   The following parameters MAY occur in either a StartRequest or
   TicketRequest:

   Encryption : Label [0..Many]

         Encryption Algorithm that the client accepts.  A Client MAY
         offer multiple algorithms.  If no algorithms are specified then
         support for the mandatory to implement algorithm is assumed.
         Otherwise mandatory to implement algorithms MUST be specified
         explicitly.

   Authentication : Label [0..Many]

         Authentication Algorithm that the client accepts.  If no
         algorithms are specified then support for the mandatory to
         implement algorithm is assumed.  Otherwise mandatory to
         implement algorithms MUST be specified explicitly.

3.2.7.  Message: BindResponse

   The following parameters MAY occur in either a StartResponse or
   TicketResponse:








Hallam-Baker            Expires January 17, 2013               [Page 15]

Internet-Draft             OmniBroker Protocol                 July 2012


   Cryptographic : Cryptographic [0..Many]

         Cryptographic Parameters.

   Service : Connection [0..Many]

         A Connection describing an OBP service point

3.2.8.  Message: OpenRequest

   The OpenRequest Message is used to begin a device binding
   transaction.  Depending on the authentication requirements of the
   service the transaction may be completed in a single query or require
   a further Ticket Query to complete.

   If authentication is required, the mechanism to be used depends on
   the capabilities of the device, the requirements of the broker and
   the existing relationship between the user and the broker.

   If the device supports some means of data entry, authentication MAY
   be achieved by entering a passcode previously delivered out of band
   into the device.

   The OpenRequest specifies the properties of the service (Account,
   Domain) and Device (ID, URI, Name) that will remain constant
   throughout the period that the device binding is active and
   parameters to be used for the mutual authentication protocol.

   Account : String  [0..1]

         Account name of the user at the OBP service

   Domain : Name [0..1]

         Domain name of the OBP broker service

   HavePasscode : Boolean [0..1]  Default =False

         If 'true', the user has entered a passcode value for use with
         passcode authentication.

   HaveDisplay : Boolean [0..1]  Default =False

         Specifies if the device is capable of displaying information to
         the user or not.






Hallam-Baker            Expires January 17, 2013               [Page 16]

Internet-Draft             OmniBroker Protocol                 July 2012


   Challenge : Binary [0..1]

         Client challenge value to be used in authentication challenge

   DeviceID : URI [0..1]



   DeviceURI : URI [0..1]



   DeviceName : String  [0..1]



3.2.9.  Message: OpenResponse

   An Open request MAY be accepted immediately or be held pending
   completion of an inband or out-of-band authentication process.

   The OpenResponse returns a ticket and a set of cryptographic
   connection parameters in either case.  If the

   Challenge : Binary [0..1]

         Challenge value to be used by the client to respond to the
         server authentication challenge.

   ChallengeResponse : Binary [0..1]

         Server response to authentication challenge by the client

   VerificationImage : ImageLink [0..Many]

         Link to an image to be used in an image verification mechanism.

3.2.10.  Message: TicketRequest

   The TicketRequest message is used to (1) complete a binding request
   begun with an OpenRequest and (2) to refresh ticket or connection
   parameters as necessary.

   ChallengeResponse : Binary [0..1]







Hallam-Baker            Expires January 17, 2013               [Page 17]

Internet-Draft             OmniBroker Protocol                 July 2012


         The response to a server authentication challenge.

3.2.11.  Message: TicketResponse

   The TicketResponse message returns cryptographic and/or connection
   context information to a client.

3.2.12.  Unbind

   Requests that a previous device association be deleted.

3.2.13.  Message: UnbindRequest

   Since the ticket identifies the binding to be deleted, the only thing
   that the unbind message need specify is that the device wishes to
   cancel the binding.

3.2.14.  Message: UnbindResponse

   Reports on the success of the unbinding operation.

   If the server reports success, the client SHOULD delete the ticket
   and all information relating to the binding.

   A service MAY continue to accept a ticket after an unbind request has
   been granted but MUST NOT accept such a ticket for a bind request.


4.  Omnibroker Query Service

4.1.  OBPQuery

4.2.  Message: Request

   Every query request contains the following common elements:

   Index : Integer [0..1]

         Index used to request a specific response when multiple
         responses are available.

4.3.  Message: Response

   Every Query Response contains the following common elements:







Hallam-Baker            Expires January 17, 2013               [Page 18]

Internet-Draft             OmniBroker Protocol                 July 2012


   Status : Integer [1..1]

         Status return code value

   Index : Integer [0..1]

         Index of the current response.

   Count : Integer [0..1]

         Number of responses available.

4.4.  Structure: Identifier

   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.

   Name : Name [1..1]

         The DNS name of the service to connect to.

         Internationalized DNS names MUST be encoded in punycode
         encoding.

   Account : Label [0..1]

         Identifies the account to connect to in the case that a peer
         connection is to be established.

   Service : Name [0..1]

         The DNS service prefix defined for use with DNS records that
         take a service prefix including SRV.

   Port : Integer [0..1]

         IP Port number.

         A service identifier MUST specify either a service or a port or
         both.

4.5.  Structure: Connection








Hallam-Baker            Expires January 17, 2013               [Page 19]

Internet-Draft             OmniBroker Protocol                 July 2012


   IPVersion : Integer [0..1]

         Contains the IP version field.  If absent, IPv4 is assumed.

   IPProtocol : Integer [0..1]

         Contains the IP protocol field.  If absent, TCP is assumed.

   IPAddress : Binary [0..1]

         IP address in network byte order.  This will normally be an
         IPv4 (32 bit) or IPv6 (128 bit) address.

   IPPort : Integer [0..1]

         IP port. 1-65535

   TransportPolicy : String  [0..1]

         Transport security policy as specified in [TBS]

   ProtocolPolicy : String  [0..1]

         Application security policy specification as specified by the
         application protocol.

   Advice : Advice [0..1]

         Additional information that a service MAY return to support a
         service connection identification.

4.6.  Structure: Advice

   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.

   Type : Label [0..1]

         The IANA MIME type of the content type

   Data : Binary [0..1]

         The advice data.






Hallam-Baker            Expires January 17, 2013               [Page 20]

Internet-Draft             OmniBroker Protocol                 July 2012


4.7.  Structure: Service

   Describes a service connection

   Identifier : Identifier [0..Many]

         Internet addresses to which the service is to be bound.

   Connection : Connection [0..1]

         Service connection parameters.

4.8.  QueryConnect

   Requests a connection context to connect to a specified Internet
   service or peer.

4.9.  Message: QueryConnectRequest

   Specifies the Internet service or peer that a connection is to be
   established to and the acceptable security policies.

   Identifier : Identifier [0..1]

         Identifies the service or peer to which a connection is
         requested.

   Policy : Label [0..Many]

         Acceptable credential validation policy.

   ProveIt : Boolean [0..1]

         If set the broker SHOULD send advice to permit the client to
         validate the proposed connection context.

4.10.  Message: QueryConnectResponse

   Returns one or more connection contexts in response to a
   QueryConnectRequest Message.

   Connection : Connection [0..Many]

         An ordered list of connection contexts with the preferred
         connection context listed first.






Hallam-Baker            Expires January 17, 2013               [Page 21]

Internet-Draft             OmniBroker Protocol                 July 2012


   Advice : Advice [0..1]

         Proof information to support the proposed connection context.

   Policy : Label [0..Many]

         Policy under which the credentials have been verified.

4.11.  Advertise

   Advises a broker that one or more Internet services are being offered
   with particular attributes.

4.12.  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 : Service [0..Many]

         Describes a connection to be established.

4.13.  Message: AdvertiseResponse

   Specifies the connection(s)

   Service : Service [0..Many]

         Describes a connection that was established.

4.14.  Validate

   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.

4.15.  Message: ValidateRequest

   Specifies the credentials to be validated and the purpose for which
   they are to be used.

   Service : Service [0..1]







Hallam-Baker            Expires January 17, 2013               [Page 22]

Internet-Draft             OmniBroker Protocol                 July 2012


         Describes the service for which the credentials are presented
         for access.

   Credential : Credential [0..1]

         List of credentials for which validation is requested.

   Policy : Label [0..Many]

         Policy under which the credentials have been verified.

4.16.  Message: ValidateResponse

   Reports the status of the credential presented.

   Policy : Label [0..Many]

         Policy under which the credentials have been verified.

4.17.  QueryCredentialPassword

   The QueryCredentialPassword query is used to request a password
   credential that the user has previously chosen to store at the
   broker.

4.18.  Message: CredentialPasswordRequest

   Requests a password for the specified account.

   Account : String  [0..1]

         The account for which a password is requested.

4.19.  Message: CredentialPasswordResponse

   Returns a password for the specified account.

   Password : String  [0..1]

         The requested password.


5.  Transport Bindings

   To achieve an optimal balance of efficiency and availability, three
   transport bindings are defined:





Hallam-Baker            Expires January 17, 2013               [Page 23]

Internet-Draft             OmniBroker Protocol                 July 2012


      Supports all forms of OBP transaction in all network environments.

      Provides efficient support for a subset of OBP query transactions
      that is accessible in most network environments.

      Provides efficient support for all OBP query transactions and is
      accessible in most network environments.

   Support for the HTTP over TLS binding is REQUIRED.

   An OBP message consists of three parts:

   Ticket [As necessary]  If specified, identifies the cryptographic key
      and algorithm parameters to be used to secure the message payload.

   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.

   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.

   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.

5.1.  HTTP over TLS

   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.

5.1.1.  Message Encapsulation

   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.

   The Ticket and Authenticator are specified using the Integrity header
   as follows:

   Integrity: <base64 (authenticator)> ; ticket=<base64 (ticket)>





Hallam-Baker            Expires January 17, 2013               [Page 24]

Internet-Draft             OmniBroker Protocol                 July 2012


5.1.2.  Example

   [To be generated from spec]

5.2.  DNS Tunnel

   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.

5.2.1.  Request

   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:

   <base32(payload)>.<base32(authenticator)>.<base32(ticket)>.Suffix

   The payload MAY be split across multiple DNS labels at any point.

5.2.2.  Response

   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:

   <base32(payload)>.<base32(authenticator)>

5.2.3.  Example

   [To be generated from spec]

5.3.  UDP

   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.

5.3.1.  Request

   The request consists of four message segments containing a Header,
   Ticket, Payload and Authenticator.  Each message segment begins with



Hallam-Baker            Expires January 17, 2013               [Page 25]

Internet-Draft             OmniBroker Protocol                 July 2012


   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.

   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.

   [TBS diagram]

5.3.2.  Response

   The response consists of a sequence of packets.  Each packet consists
   of a header section and a data section.

   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.

   [TBS diagram]

   [Question, should the authenticator be over the whole message or
   should each packet have its own authenticator?]

5.3.3.  Example

   [To be generated from spec]


6.  Acknowledgements

   [List of contributors]


7.  Security Considerations

7.1.  Denial of Service

7.2.  Breach of Trust

7.3.  Coercion






Hallam-Baker            Expires January 17, 2013               [Page 26]

Internet-Draft             OmniBroker Protocol                 July 2012


8.  To do

      The specification should define and use a JSON security object.

      Formatting of the abstract data items needs to be improved

      Need to specify the UDP transport binding

      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.

      Run the code to produce proper examples.

      Write a tool to transclude the example and other xml data into the
      document source.

      Fully document the API section.


9.  For discussion.

      Should the specification use the form urlencoded convention like
      OAUTH does?

      How should responses be cryptographically linked to requests?




10.  IANA Considerations

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


11.  Normative References

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4366]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
              and T. Wright, "Transport Layer Security (TLS)
              Extensions", RFC 4366, April 2006.

   [X.509]    International Telecommunication Union, "ITU-T



Hallam-Baker            Expires January 17, 2013               [Page 27]

Internet-Draft             OmniBroker Protocol                 July 2012


              Recommendation X.509 (11/2008): Information technology -
              Open systems interconnection - The Directory: Public-key
              and attribute certificate frameworks", ITU-T
              Recommendation X.509, November 2008.

   [X.680]    International Telecommunication Union, "ITU-T
              Recommendation X.680 (11/2008): Information technology -
              Abstract Syntax Notation One (ASN.1): Specification of
              basic notation", ITU-T Recommendation X.680,
              November 2008.


Appendix A.  Example Data.

A.1.  Ticket A

A.2.  Ticket B


Author's Address

   Phillip Hallam-Baker
   Comodo Group Inc.

   Email: philliph@comodo.com


























Hallam-Baker            Expires January 17, 2013               [Page 28]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/