Internet Engineering Task Force P. Hallam-Baker Internet-Draft Comodo Group Inc. Intended status: Standards Track June 27, 2012 Expires: December 29, 2012 OmniBroker Protocol draft-hallambaker-omnibroker-00 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 December 29, 2012. 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 December 29, 2012 [Page 1] Internet-Draft OmniBroker Protocol June 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.2. OBPConnection . . . . . . . . . . . . . . . . . . . . . . 9 3.2.1. Top . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2.2. Message: Request . . . . . . . . . . . . . . . . . . . 10 3.2.3. Message: Response . . . . . . . . . . . . . . . . . . 10 3.2.4. Structure: Cryptographic . . . . . . . . . . . . . . . 10 3.2.5. Structure: ImageLink . . . . . . . . . . . . . . . . . 11 3.2.6. Structure: Connection . . . . . . . . . . . . . . . . 11 3.2.7. Bind . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.8. Message: BindRequest . . . . . . . . . . . . . . . . . 12 3.2.9. Message: BindResponse . . . . . . . . . . . . . . . . 12 3.2.10. Message: OpenRequest . . . . . . . . . . . . . . . . . 12 3.2.11. Message: OpenResponse . . . . . . . . . . . . . . . . 13 3.2.12. Message: TicketRequest . . . . . . . . . . . . . . . . 14 3.2.13. Message: TicketResponse . . . . . . . . . . . . . . . 14 3.2.14. Unbind . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2.15. Message: UnbindRequest . . . . . . . . . . . . . . . . 14 3.2.16. Message: UnbindResponse . . . . . . . . . . . . . . . 14 4. Omnibroker Connection Query Service . . . . . . . . . . . . . 15 4.1. OBPQuery . . . . . . . . . . . . . . . . . . . . . . . . . 15 Hallam-Baker Expires December 29, 2012 [Page 2] Internet-Draft OmniBroker Protocol June 2012 4.1.1. Top . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1.2. Structure: Identifier . . . . . . . . . . . . . . . . 15 4.1.3. Structure: Connection . . . . . . . . . . . . . . . . 15 4.1.4. Structure: Advice . . . . . . . . . . . . . . . . . . 16 4.1.5. Structure: Service . . . . . . . . . . . . . . . . . . 16 4.1.6. Message: Request . . . . . . . . . . . . . . . . . . . 17 4.1.7. Message: Response . . . . . . . . . . . . . . . . . . 17 4.1.8. QueryConnect . . . . . . . . . . . . . . . . . . . . . 17 4.1.9. Message: QueryConnectRequest . . . . . . . . . . . . . 18 4.1.10. Message: QueryConnectResponse . . . . . . . . . . . . 18 4.1.11. Advertise . . . . . . . . . . . . . . . . . . . . . . 18 4.1.12. Message: AdvertiseRequest . . . . . . . . . . . . . . 18 4.1.13. Message: AdvertiseResponse . . . . . . . . . . . . . . 19 4.1.14. Validate . . . . . . . . . . . . . . . . . . . . . . . 19 4.1.15. Message: ValidateRequest . . . . . . . . . . . . . . . 19 4.1.16. Message: ValidateResponse . . . . . . . . . . . . . . 19 4.1.17. QueryCredentialPassword . . . . . . . . . . . . . . . 19 4.1.18. Message: CredentialPasswordRequest . . . . . . . . . . 20 4.1.19. Message: CredentialPasswordResponse . . . . . . . . . 20 5. Transport Bindings . . . . . . . . . . . . . . . . . . . . . . 20 5.1. HTTP over TLS . . . . . . . . . . . . . . . . . . . . . . 20 5.1.1. Message Encapsulation . . . . . . . . . . . . . . . . 20 5.1.2. Request . . . . . . . . . . . . . . . . . . . . . . . 21 5.1.3. Response . . . . . . . . . . . . . . . . . . . . . . . 21 5.1.4. Example . . . . . . . . . . . . . . . . . . . . . . . 21 5.2. DNS Tunnel . . . . . . . . . . . . . . . . . . . . . . . . 21 5.2.1. Request . . . . . . . . . . . . . . . . . . . . . . . 21 5.2.2. Response . . . . . . . . . . . . . . . . . . . . . . . 22 5.2.3. Example . . . . . . . . . . . . . . . . . . . . . . . 22 5.3. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.3.1. Request . . . . . . . . . . . . . . . . . . . . . . . 22 5.3.2. Response . . . . . . . . . . . . . . . . . . . . . . . 22 5.3.3. Example . . . . . . . . . . . . . . . . . . . . . . . 22 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 7.1. Denial of Service . . . . . . . . . . . . . . . . . . . . 23 7.2. Breach of Trust . . . . . . . . . . . . . . . . . . . . . 23 7.3. Coercion . . . . . . . . . . . . . . . . . . . . . . . . . 23 8. To do . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 9. For discussion. . . . . . . . . . . . . . . . . . . . . . . . 23 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 11. Normative References . . . . . . . . . . . . . . . . . . . . . 23 Appendix A. Example Data. . . . . . . . . . . . . . . . . . . . . 24 A.1. Ticket A . . . . . . . . . . . . . . . . . . . . . . . . . 24 A.2. Ticket B . . . . . . . . . . . . . . . . . . . . . . . . . 24 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 Hallam-Baker Expires December 29, 2012 [Page 3] Internet-Draft OmniBroker Protocol June 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 December 29, 2012 [Page 4] Internet-Draft OmniBroker Protocol June 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 December 29, 2012 [Page 5] Internet-Draft OmniBroker Protocol June 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 December 29, 2012 [Page 6] Internet-Draft OmniBroker Protocol June 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 December 29, 2012 [Page 7] Internet-Draft OmniBroker Protocol June 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 December 29, 2012 [Page 8] Internet-Draft OmniBroker Protocol June 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.2. OBPConnection 3.2.1. Top OBP Connection Management Query requests and responses contain the following common elements: Hallam-Baker Expires December 29, 2012 [Page 9] Internet-Draft OmniBroker Protocol June 2012 3.2.2. Message: Request The following parameters MAY be specified in any request: Ticket : Binary [0..1] Opaque ticket issued by the server that identifies the cryptographic parameters for encryption and authentication of the message payload. MAC : Binary [1..1] Message Authentication Code formed over the canonical form of the message payload. 3.2.3. Message: Response The following parameters MAY be specified in any response: MAC : Binary [1..1] Message Authentication Code formed over the canonical form of the message payload. 3.2.4. 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] Authentication Algorithm selected Ticket : Binary [1..1] Hallam-Baker Expires December 29, 2012 [Page 10] Internet-Draft OmniBroker Protocol June 2012 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.5. 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.6. 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. 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. Hallam-Baker Expires December 29, 2012 [Page 11] Internet-Draft OmniBroker Protocol June 2012 Expires : DateTime [0..1] Date and time at which the specified connection context will expire. 3.2.7. Bind Binding a device is a two step protocol that begins with the Start Query followed by a sequence of Ticket queries. 3.2.8. 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.9. Message: BindResponse The following parameters MAY occur in either a StartResponse or TicketResponse: Cryptographic : Cryptographic [0..Many] Cryptographic Parameters. Service : Connection [0..Many] A Connection describing an OBP service point 3.2.10. 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. Hallam-Baker Expires December 29, 2012 [Page 12] Internet-Draft OmniBroker Protocol June 2012 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. 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.11. 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 Hallam-Baker Expires December 29, 2012 [Page 13] Internet-Draft OmniBroker Protocol June 2012 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.12. 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] The response to a server authentication challenge. 3.2.13. Message: TicketResponse The TicketResponse message returns cryptographic and/or connection context information to a client. 3.2.14. Unbind Requests that a previous device association be deleted. 3.2.15. 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.16. 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. Hallam-Baker Expires December 29, 2012 [Page 14] Internet-Draft OmniBroker Protocol June 2012 4. Omnibroker Connection Query Service 4.1. OBPQuery 4.1.1. Top 4.1.2. 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.1.3. Structure: Connection 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. Hallam-Baker Expires December 29, 2012 [Page 15] Internet-Draft OmniBroker Protocol June 2012 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.1.4. 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. 4.1.5. 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. Hallam-Baker Expires December 29, 2012 [Page 16] Internet-Draft OmniBroker Protocol June 2012 4.1.6. 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. Ticket : Binary [0..1] OBP ticket previously returned by the broker protocol that identifies the cryptographic parameters used to authenticate and encrypt the request and response data. MAC : Binary [0..1] Authentication value formed over the canonical form of the OBP request (JSON syntax). 4.1.7. Message: Response Every Query Response contains the following common elements: 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. MAC : Binary [0..1] Authentication value formed over the canonical form of the OBP request (JSON syntax). 4.1.8. QueryConnect Requests a connection context to connect to a specified Internet service or peer. Hallam-Baker Expires December 29, 2012 [Page 17] Internet-Draft OmniBroker Protocol June 2012 4.1.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.1.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. 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.1.11. Advertise Advises a broker that one or more Internet services are being offered with particular attributes. 4.1.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. Hallam-Baker Expires December 29, 2012 [Page 18] Internet-Draft OmniBroker Protocol June 2012 Service : Service [0..Many] Describes a connection to be established. 4.1.13. Message: AdvertiseResponse Specifies the connection(s) Service : Service [0..Many] Describes a connection that was established. 4.1.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.1.15. Message: ValidateRequest Specifies the credentials to be validated and the purpose for which they are to be used. Service : Service [0..1] 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.1.16. Message: ValidateResponse Reports the status of the credential presented. Policy : Label [0..Many] Policy under which the credentials have been verified. 4.1.17. QueryCredentialPassword The QueryCredentialPassword query is used to request a password credential that the user has previously chosen to store at the Hallam-Baker Expires December 29, 2012 [Page 19] Internet-Draft OmniBroker Protocol June 2012 broker. 4.1.18. Message: CredentialPasswordRequest Requests a password for the specified account. Account : String [0..1] The account for which a password is requested. 4.1.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, OBP supports three transport bindings: 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 broker SHOULD offer multiple connections 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-Type MUST be specified as application/json. The Character set MUST be specified as UTF-8. Hallam-Baker Expires December 29, 2012 [Page 20] Internet-Draft OmniBroker Protocol June 2012 Request and response messages are encoded using JSON notation [TBS] to produce a payload. The payload is in turn encoded using JSON Signature and Encryption encoding [TBS]: [The Security Object being defined contains three slots: headers, payload and signatures. Since this is not specified in the JSON signatures spec it will be added as a separate section here in the next itteration.] 5.1.2. Request Requests are mapped to HTTP POST Requests. The URL value is ignored. Note that even though the specification permits the OpenRequest message to be presented without authentication, the message MUST be presented as a security object payload even if both the headers and Signatures elements are empty. An OpenRequest message MUST NOT be presented directly without an enclosing security object. 5.1.3. Response Requests are mapped to HTTP Responses. The Content-Type MUST be specified as application/json. The Character set MUST be specified as UTF-8. Since the response content is not cacheable, the response SHOULD specify Pragma: no-cache. 5.1.4. 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 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 concatenating the following data items: Hallam-Baker Expires December 29, 2012 [Page 21] Internet-Draft OmniBroker Protocol June 2012 A single DNS label containing the BASE32 encoding of the Message Authentication Code of the Payload data One or more DNS labels containing the JSON request message in BASE32 encoding. If more than one label is specified, the labels are concatenated before base32 decoding takes place. Concatentation observes the normal DNS convention that the least significant data is presented first but without added periods A single DNS label containing the BASE32 encoding of the ticket. The DNS name of the service to which the request is directed. 5.2.2. Response Requests are mapped to DNS TXT records. The TXT record contains a JSON encoded response as defined in the HTTP transport binding. 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 TBS 5.3.2. Response TBS 5.3.3. Example [To be generated from spec] 6. Acknowledgements [List of contributors] Hallam-Baker Expires December 29, 2012 [Page 22] Internet-Draft OmniBroker Protocol June 2012 7. Security Considerations 7.1. Denial of Service 7.2. Breach of Trust 7.3. Coercion 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. Hallam-Baker Expires December 29, 2012 [Page 23] Internet-Draft OmniBroker Protocol June 2012 [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 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 December 29, 2012 [Page 24]