idnits 2.17.1 draft-hallambaker-omnibroker-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 16, 2012) is 4301 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBS' is mentioned on line 885, but not defined == Missing Reference: 'Required' is mentioned on line 1063, but not defined == Missing Reference: 'Optional' is mentioned on line 1068, but not defined == Unused Reference: 'RFC1035' is defined on line 1218, but no explicit reference was found in the text == Unused Reference: 'RFC4366' is defined on line 1224, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4366 (Obsoleted by RFC 5246, RFC 6066) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Hallam-Baker 3 Internet-Draft Comodo Group Inc. 4 Intended status: Standards Track July 16, 2012 5 Expires: January 17, 2013 7 OmniBroker Protocol 8 draft-hallambaker-omnibroker-01 10 Abstract 12 An Omnibroker is an agent chosen and trusted by an Internet user to 13 provide information such as name and certificate status information 14 that are in general trusted even if they are not trustworthy. Rather 15 than acting as a mere conduit for information provided by existing 16 services, an Omnibroker is responsible for curating those sources to 17 protect the user. 19 The Omnibroker Protocol (OBP) provides an aggregated interface to 20 trusted Internet services including DNS, OCSP and various forms of 21 authentication service. Multiple transport bindings are supported to 22 permit efficient access in virtually every common deployment scenario 23 and ensure access in any deployment scenario in which access is not 24 being purposely denied. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 17, 2013. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 62 2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.1. A Curated Service . . . . . . . . . . . . . . . . . . . . 4 64 2.2. Connection Broker . . . . . . . . . . . . . . . . . . . . 6 65 2.2.1. Service Connection Broker . . . . . . . . . . . . . . 6 66 2.2.2. Peer Connection Broker . . . . . . . . . . . . . . . . 7 67 2.2.3. Connection Broker API . . . . . . . . . . . . . . . . 7 68 2.3. Service Advertisement . . . . . . . . . . . . . . . . . . 8 69 2.3.1. Connection Advertisement API . . . . . . . . . . . . . 8 70 2.4. Credential Validation Broker . . . . . . . . . . . . . . . 8 71 2.5. Authentication Gateway . . . . . . . . . . . . . . . . . . 8 72 2.6. Credential Announcement . . . . . . . . . . . . . . . . . 8 73 3. Omnibroker Connection Maintenance Service . . . . . . . . . . 9 74 3.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 9 75 3.1.1. Broker Authentication . . . . . . . . . . . . . . . . 9 76 3.1.2. Device Authentication . . . . . . . . . . . . . . . . 9 77 3.1.3. Illustrative example . . . . . . . . . . . . . . . . . 9 78 3.2. OBPConnection . . . . . . . . . . . . . . . . . . . . . . 13 79 3.2.1. Message: Request . . . . . . . . . . . . . . . . . . . 13 80 3.2.2. Structure: Cryptographic . . . . . . . . . . . . . . . 13 81 3.2.3. Structure: ImageLink . . . . . . . . . . . . . . . . . 14 82 3.2.4. Structure: Connection . . . . . . . . . . . . . . . . 14 83 3.2.5. Bind . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 3.2.6. Message: BindRequest . . . . . . . . . . . . . . . . . 15 85 3.2.7. Message: BindResponse . . . . . . . . . . . . . . . . 15 86 3.2.8. Message: OpenRequest . . . . . . . . . . . . . . . . . 16 87 3.2.9. Message: OpenResponse . . . . . . . . . . . . . . . . 17 88 3.2.10. Message: TicketRequest . . . . . . . . . . . . . . . . 17 89 3.2.11. Message: TicketResponse . . . . . . . . . . . . . . . 18 90 3.2.12. Unbind . . . . . . . . . . . . . . . . . . . . . . . . 18 91 3.2.13. Message: UnbindRequest . . . . . . . . . . . . . . . . 18 92 3.2.14. Message: UnbindResponse . . . . . . . . . . . . . . . 18 93 4. Omnibroker Query Service . . . . . . . . . . . . . . . . . . . 18 94 4.1. OBPQuery . . . . . . . . . . . . . . . . . . . . . . . . . 18 95 4.2. Message: Request . . . . . . . . . . . . . . . . . . . . . 18 96 4.3. Message: Response . . . . . . . . . . . . . . . . . . . . 18 97 4.4. Structure: Identifier . . . . . . . . . . . . . . . . . . 19 98 4.5. Structure: Connection . . . . . . . . . . . . . . . . . . 19 99 4.6. Structure: Advice . . . . . . . . . . . . . . . . . . . . 20 100 4.7. Structure: Service . . . . . . . . . . . . . . . . . . . . 21 101 4.8. QueryConnect . . . . . . . . . . . . . . . . . . . . . . . 21 102 4.9. Message: QueryConnectRequest . . . . . . . . . . . . . . . 21 103 4.10. Message: QueryConnectResponse . . . . . . . . . . . . . . 21 104 4.11. Advertise . . . . . . . . . . . . . . . . . . . . . . . . 22 105 4.12. Message: AdvertiseRequest . . . . . . . . . . . . . . . . 22 106 4.13. Message: AdvertiseResponse . . . . . . . . . . . . . . . . 22 107 4.14. Validate . . . . . . . . . . . . . . . . . . . . . . . . . 22 108 4.15. Message: ValidateRequest . . . . . . . . . . . . . . . . . 22 109 4.16. Message: ValidateResponse . . . . . . . . . . . . . . . . 23 110 4.17. QueryCredentialPassword . . . . . . . . . . . . . . . . . 23 111 4.18. Message: CredentialPasswordRequest . . . . . . . . . . . . 23 112 4.19. Message: CredentialPasswordResponse . . . . . . . . . . . 23 113 5. Transport Bindings . . . . . . . . . . . . . . . . . . . . . . 23 114 5.1. HTTP over TLS . . . . . . . . . . . . . . . . . . . . . . 24 115 5.1.1. Message Encapsulation . . . . . . . . . . . . . . . . 24 116 5.1.2. Example . . . . . . . . . . . . . . . . . . . . . . . 25 117 5.2. DNS Tunnel . . . . . . . . . . . . . . . . . . . . . . . . 25 118 5.2.1. Request . . . . . . . . . . . . . . . . . . . . . . . 25 119 5.2.2. Response . . . . . . . . . . . . . . . . . . . . . . . 25 120 5.2.3. Example . . . . . . . . . . . . . . . . . . . . . . . 25 121 5.3. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 122 5.3.1. Request . . . . . . . . . . . . . . . . . . . . . . . 25 123 5.3.2. Response . . . . . . . . . . . . . . . . . . . . . . . 26 124 5.3.3. Example . . . . . . . . . . . . . . . . . . . . . . . 26 125 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 126 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 127 7.1. Denial of Service . . . . . . . . . . . . . . . . . . . . 26 128 7.2. Breach of Trust . . . . . . . . . . . . . . . . . . . . . 26 129 7.3. Coercion . . . . . . . . . . . . . . . . . . . . . . . . . 26 130 8. To do . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 131 9. For discussion. . . . . . . . . . . . . . . . . . . . . . . . 27 132 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 133 11. Normative References . . . . . . . . . . . . . . . . . . . . . 27 134 Appendix A. Example Data. . . . . . . . . . . . . . . . . . . . . 28 135 A.1. Ticket A . . . . . . . . . . . . . . . . . . . . . . . . . 28 136 A.2. Ticket B . . . . . . . . . . . . . . . . . . . . . . . . . 28 137 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28 139 1. Definitions 141 1.1. Requirements Language 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in RFC 2119 [RFC2119]. 147 2. Purpose 149 An Omnibroker is an agent chosen and trusted by an Internet user to 150 provide information such as name and certificate status information 151 that are in general trusted even if they are not trustworthy. Rather 152 than acting as a mere conduit for information provided by existing 153 services, an Omnibroker is responsible for curating those sources and 154 providing autheticated, curated results to the endpoint client. 156 Unlike the traditional trusted information services that are expected 157 to deliver the same response to a query regardless of who asks the 158 question, OBP permits an Omnibroker to return a response that is 159 tailored to the specific party asking the question. This permits the 160 use of an authentication approach that has negligible impact on 161 performance and permits an Omnibroker to answer questions that a 162 traditional public Internet information service could not. In 163 particular, an Omnibroker can broker peer to peer connections 165 2.1. A Curated Service 167 In the traditional configuration, an Internet host accepts DNS 168 service from the IP address specified by the local network provider, 169 frequently the DNS server advertised by the local DHCP service. This 170 approach creates an obvious security risk as DNS is clearly a trusted 171 service and a random DNS service advertised by the local DNS is 172 clearly not trustworthy. 174 A policy of only using a chosen DNS service provides a reduction in 175 risk but only a modest one since the standard DNS service does not 176 provide authenticated results. Many local area networks intercept 177 all DNS traffic and process it through the local DNS server 178 regardless of the intended destination IP address. This practice is 179 highly desirable if it would prevent a client from accessing an 180 untrustworthy DNS service in place of a trustworthy local DNS service 181 and extreemly undesirable in the contrary case. 183 In addition to ensuring the authenticity of DNS resolution responses, 184 such services frequently provide filtering of Internet addresses the 185 network provider considers undesirable. Many workplaces block access 186 to Web sites that are considered detrimental to productivity. Many 187 parent subscribe to services that filter content they consider 188 undesirable. While the value of such services is debatable they are 189 services that those customers have chosen to deploy on their networks 190 to meet their perceived security requirements. New security 191 proposals that do not support such capabilities or seek to actually 192 circumvent them will not be acceptable to those constituencies. 194 While DNS filtering is a form of censorship, not all forms of DNS 195 filering are intrinsically undesirable censorship. Spam filtering is 196 also a form of censorship albeit one that is not normally regarded as 197 such because it most Internet users now consider it to be an 198 essential security control. Anti-Virus tools are also a form of 199 censorship. DNS filtering tools that block access to sites that 200 distribute malware are also a form of censorship and are rapidly 201 gaining popularity for the same reason. 203 While all forms of censorship raise civil liberties concerns, 204 censorship should not automatically raise civil liberties objections. 205 It is not the fact that filtering is taking place but the party that 206 is in control of the filtering that should raise civil liberties 207 concerns. In an Internet of 2 billion users, all users are obliged 208 to perform some filtering. OBP is designed to make the party that is 209 in control of the filtering process apparent and provide the end user 210 with the ability to select the Omnibroker of their choice. 212 DNSSEC provides a means of determining that a DNS record is the 213 authentic record published by the source but this capability alone 214 does not meet the security requirements for DNS resolution services 215 as they have come to be understood since the protocol was first 216 proposed. 218 Internet users want to be safe from all forms of attack, not just the 219 DNS resolver mani-in-the-middle attack that 'end-to-end' deployment 220 of DNSSEC is designed to address. An Internet user is far more 221 likely to be directed to a site with a DNS name controlled by a 222 criminal gang than be subject to a man-in-the-middle attack. 224 Most users would prefer to have an Internet connection that is 225 'curated' to remove at least some of the locations they consider to 226 be undesirable. The fact that an organised criminal gang has put a 227 host on the Internet does not mean that any other Internet user 228 should be obliged to allow it to connect to any of the machines that 229 they own. 231 The same argument for curating the raw results applies to other forms 232 of trusted information service. The fact that a Certificate 233 Authority has issued a digital certificate and considers it to be 234 valid should not mean that the end party is automatically considered 235 trustworthy by anyone and for any purpose. 237 The deployment of security policy capabilities presents another case 238 in which direct reliance on raw data is undesirable. While security 239 policies such as 'host always offers TLS' or 'mail server always 240 signs outgoing mail with DKIM' can provide considerable security 241 advantages, only some of the security policy information that is 242 published is accurate and kept up to date. Curating such data 243 sources typically proves essential if an unacceptable rate of false 244 positives is to be avoided. 246 Although a client is permitted to curate its own data sources it 247 rarely has a sufficient amount of data to make decisions as 248 accurately as a network service that can draw on a wide variety of 249 additional data including tracking of communication patterns, 250 historical data series and third party reputation services. 252 Curation in the network offers better asgility than the client 253 approach. Agility is an important consideration when an attacker 254 changes their strategy rapidly and repeatedly to counter new 255 defensive controls. 257 While curating trusted data sources is an established and proven 258 practice, current practice has been to curate each source 259 individually. This approach avoids the need to write a new protocol 260 but limits the information a curator can leverage to detect potential 261 danger. Leveraging multiple data sources simultaneously allows 262 better accuracy than applying each individually. 264 2.2. Connection Broker 266 The OBP service connection broker answers the query 'what connection 267 parameters should be used to establish the best connection to 268 interract with party X according to protocol Y. Where 'best' is 269 determined by the Omnibroker which MAY take into account parameters 270 specified by the relying party. 272 2.2.1. Service Connection Broker 274 The OBP service connection broker supports and extends the 275 traditional DNS resolution service that resolves a DNS name (e.g. 276 www.example.com) to return an IP address (e.g. 10.1.2.3). 278 When using an Omnibroker as a service connection broker, a client 279 specifies both the DNS name (e.g. www.example.com) and the Internet 280 protocol to be used (e.g. _http._tcp). The returned connection 281 parameters MAY include: 283 The IP protocol version, address and port number to establish a 284 connection to. 286 If appropriate, a security transport such as TLS or IPSEC. 288 If appropriate, a description of a service credential such as a 289 TLS certificate or a constraint on the type of certificates that 290 the client should consider acceptable. 292 If appropriate, application protocol details such as version and 293 protocol options. 295 If an attempt to connect with the parameters specified fails, a 296 client MAY report the failure and request a new set of parameters. 298 2.2.2. Peer Connection Broker 300 Each OBP request identifies both the account under which the request 301 is made and the device from which it is made. An OBP broker is thus 302 capable of acting as a peer connection broker service or providing a 303 gateway to such a service. 305 When using Omnibroker as a peer connection broker, a client specifies 306 the account name and DNS name of the party with which a connection is 307 to be established (e.g. alice@example.com) and the connection 308 protocol to be used (e.g. _xmpp-client._tcp) 310 The returned connection parameters are similar to those returned in 311 response to a service broker query. 313 2.2.3. Connection Broker API 315 In the traditional BSD sockets API a network client performs a series 316 of calls to resolve a network name to a list of IP addresses, selects 317 one and establishes an IP connection to a port specified by the 318 chosen application protocol. 320 OBP anticipates a higher level abstract API that encapsulates this 321 complexity, hiding it from the application code. 323 In the case that one (or more) OBP services are configured, the 324 library supporting the SHOULD obtain connection parameters from the 325 OBP service. Otherwise, it SHOULD establish a connection using the 326 traditional calling sequence of resolving a host name to obtain an IP 327 address, etc. 329 2.3. Service Advertisement 331 Service advertisement is the converse of service resolution. An 332 Internet application wishing to accept inbound connections specifies 333 one or more sets of connection parameters for the Omnibroker to 334 register with whatever naming, discovery or other services may be 335 appropriate. 337 2.3.1. Connection Advertisement API 339 OBP anticipates the use of a high level API for connection 340 advertisement that is the converse of the Connection broker API. 341 Instead of establishing a connection, the API is used to advertise 342 that a connection is offered either as a service or a peer. 344 An application MAY offer multiple types of connection with different 345 connection properties (e.g. IPv4/IPv6, with and without SSL, etc.). 346 This MAY be supported by marking certain properties as being optional 347 and/or by permitting the API to be called multiple times with 348 different properties specified. 350 2.4. Credential Validation Broker 352 A credential validation broker reports on the validity and 353 trustworthiness of credentials presented to a client by Internet 354 services and/or peers. 356 The service provided by OBP is similar to that provided by OCSP and 357 SCVP. Like SCVP, OBP is an agent selected by the relying party to 358 validate certificates and/or construct trust paths on its behalf. 360 2.5. Authentication Gateway 362 Every OBP request is strongly authenticated by means of a shared 363 secret that is unique to the account and the device. This may be 364 leveraged to permit use as an authentication gateway, providing 365 access to other credentials that the client has established the right 366 to use. 368 An Authentication Gateway MAY provide access to account names and 369 passwords that the account holder has chosen to store in the cloud 370 for access to sites that do not support a stronger, cryptographically 371 based form of authentication such as OAuth. 373 2.6. Credential Announcement 375 An Authentication Gateway can only provide access to credentials that 376 it has notice of. A client uses the Credential Announcement 377 transaction to advise the service of a new credential. 379 3. Omnibroker Connection Maintenance Service 381 3.1. Authentication 383 The principle function of the OBP Connection Maintenance Protocol is 384 to establish and maintain the cryptographic parameters used to 385 authenticate and encrypt 387 The user needs to authenticate the broker service regardless of any 388 authentication requirements of the broker. 390 3.1.1. Broker Authentication 392 The OBP connection maintenance protocol transport MUST provide a 393 trustworthy means of verifying the identity of the broker (e.g. an 394 Extended Validation SSL certificate). 396 If the device supports a display capability, authentication of the 397 device and user MAY be achieved by means of an authentication image. 398 Such an authentication image is generated by the broker and passed to 399 the client in the OpenResponse message. The user then verifies that 400 the image presented on the device display is the same as that 401 presented on the account maintenance console. 403 3.1.2. Device Authentication 405 If device authentication is required, the mechanism to be used 406 depends on the capabilities of the device, the requirements of the 407 broker and the existing relationship between the user and the broker. 409 If the device supports some means of data entry, authentication MAY 410 be achieved by entering a passcode into the device that was 411 previously delivered to the user out of band. 413 The passcode authentication mechanism allows the device to establish 414 a proof that it knows the passcode without disclosing the passcode. 415 This property provides protection against Man-In-The-Middle type 416 disclosure attacks. 418 3.1.3. Illustrative example 420 Alice is an employee of example.com which runs its own local 421 omnibroker service. To configure her machine for use with this 422 service, Alice contacts her network administrator who assigns her the 423 account identifier 'alice' and obtains a PIN number from the service 424 '1V0FH0-3KSF01-501M' 426 Alice enters the values 'alice@example.com' and '1V0FH0-3KSF01-501M' 427 into her Omnibroker-enabled Web browser. 429 The Web browser uses the local DNS to resolve 'example.com' and 430 establishes a HTTPS connection to the specified IP address. The 431 client verifies that the certificate presented has a valid 432 certificate chain to an embedded trust anchor under an appropriate 433 certificate policy (e.g. compliant with the Extended Validation 434 Criteria defined by CA-Browser Forum). 436 Having established an authenticated and encrypted TLS session to the 437 Omnibroker service, the client sends an OpenRequest message to begin 438 the process of mutual authentication. This message specifies the 439 cryptographic parameters supported by the client (Authentication, 440 Encryption) and a nonce value (Challenge), device identification 441 parameters (DeviceID, DeviceURI, DeviceName) and the name of the 442 account being requested. 444 The client does not specify the PIN code in the initial request, nor 445 is the request authenticated. Instead the client informs the server 446 that it has a PIN code that can be supplied if necessary. 448 Post / HTTP/1.0 449 [HTTP-Headers...] 451 {"OpenRequest": { "Encryption": ["HS256","HS384","HS512","HS256T128"], 452 "Authentication": ["A128CBC","A256CBC","A128GCM","A256GCM"], 453 "Account": "alice", 454 "Domain": "example.com", 455 "HavePasscode": true, 456 "HaveDisplay": true, 457 "Challenge": "aokb53UJRy3Y75350wo33A==", 458 "DeviceID": "Serial:0002212", 459 "DeviceURI": "http://comodo.com/dragon/v3.4", 460 "DeviceName": "Comodo Dragon"} 461 } 463 The service receives the request. If the request is consistent with 464 the access control policy for the server it returns a reply that 465 specifies the chosen cryptographic parameters (Cryptographic), 466 responds to the client issued by the client to establish server proof 467 of knowsledge of the PIN (ChallengeResponse) and issues a challenge 468 to the client (Challenge). 470 The cryptographic parameters specify algorithms to be used for 471 encryption and authentication, a shared secret and a ticket value. 473 Note that while the shared secret is exchanged in plaintext form in 474 the HTTP binding, the connection protocol MUST provide encryption. 476 HTTP/1.0 200 OK 478 {"OpenResponse": { "Status": 203, 479 "StatusDescription": "Passcode", 480 "Cryptographic": [{ "Protocol": "OBPConnection", 481 "Secret": "4Xd1YGY0FLAoricHMgnCUg==", 482 "Encryption": "A128CBC", 483 "Authentication": "HS256", 484 "Ticket": "AAAAAOF3dWBmNBSwKK4nBzIJ 485 wlIRYWxpY2VAZXhhbXBsZS5jb21qiRv 486 ndQlHLdjvnfnTCjfckws0cHInS6oZI 487 0K+OZs7XuaiEc0z/HlrYWRUa+uodUoA"}], 488 "Challenge": "kws0cHInS6oZI0K+OZs7Xg==", 489 "ChallengeResponse": "t5C+tJO/zuIV0uKOhizWTg=="}} 491 To complete the transaction, the client sends a TicketRequest message 492 to the serice containing a response to the PIN challenge sent by the 493 service (ChallengeResponse). The TicketRequest message is 494 authenticated under the shared secret specified in the OpenResponse 495 message. 497 Post / HTTP/1.0 498 [Content-Integrity: JNpUYCKibOcsHksTEJwUlA==; 499 ticket=AAAAAOF3dWB...] 501 {"TicketRequest": { "Ticket": "AAAAAOF3dWBmNBSwKK 502 4nBzIJwlIRYWxpY2VAZXhhbXBsZS5jb21qiRv 503 ndQlHLdjvnfnTCjfckws0cHInS6oZI0K+OZs7 504 XuaiEc0z/HlrYWRUa+uodUoA", 505 "ChallengeResponse": "XTjeS06vsPpYaZwmAV+J/Q=="} 506 } 508 If the response to the PIN challenge is correct, the service responds 509 with a message that specifies a set of cryptographic parameters to be 510 used to authenticate future interactions with the service 511 (Cryptographic) and a set of connection parameters for servers 512 supporting the Query Service (Service). 514 In this case the server returns three connections, each offering a 515 different transport protocol option. Each connection specifies its 516 own set of cryptographic parameters (or will when the code is written 517 for that). 519 HTTP/1.0 200 OK 521 {"TicketResponse": { "Status": 200, 522 "StatusDescription": "Complete", 523 "Cryptographic": [{ "Protocol": "OBPConnection", 524 "Secret": "p59UMqIwDd7lVGb5Zf8m7w==", 525 "Encryption": "A128CBC", 526 "Authentication": "HS256", 527 "Ticket": "AAAAAKefVDKiMA3e5VRm+WX/Ju8BQAzCLTmHk40SOUXQqtJdYgs="} 528 ], 529 "Service": [{ "Name": "obp1.example.com", 530 "Port": 443, 531 "Address": "10.1.2.3", 532 "Priority": 1, 533 "Weight": 100} 534 ,{ "Name": "dns1.example.com", 535 "Port": 53, 536 "Address": "10.1.2.2", 537 "Priority": 1, 538 "Weight": 100} 539 ,{ "Name": "udp.example.com", 540 "Port": 5000, 541 "Address": "10.1.2.2", 542 "Priority": 1, 543 "Weight": 100} 544 ]} 545 } 547 When Alice's machine is to be transfered to another employee, the 548 Unbind transaction is used. The only parameter required is the 549 Ticket identifying the device association (Ticket). 551 {"UnbindRequest": { "Ticket": "AAAAAKefVDKiMA3e5VRm+ 552 WX/Ju8BQAzCLTmHk40SOUXQqtJdYgs="} 553 } 555 Since the unbind response represents the termination of the 556 relationship with the Omnibroker, the response merely reports the 557 success or failure of the request. 559 HTTP/1.0 200 OK 561 {"UnbindResponse": {}} 562 The 'Ticket' value presented in the foregoing examples is a sequence 563 of binary data generated by the service that is opaque to the client. 564 Services MAY generate ticket values with a substructure that enable 565 the service to avoid the need to maintain server side state. 567 In the foregoing example, the ticket structures generated by the 568 service encode the cryptographic parameter data, the shared secret, 569 account identifier and an authentication value. The initial ticket 570 value generated additionally encodes the values of the client and 571 service challeng values for use in calculating the necessary 572 ChallengeResponse. 574 3.2. OBPConnection 576 3.2.1. Message: Request 578 Every query request contains the following common elements: 580 Index : Integer [0..1] 582 Index used to request a specific response when multiple 583 responses are available. 585 3.2.2. Structure: Cryptographic 587 Parameters describing a cryptographic context. 589 Protocol : Label [0..1] 591 OBP tickets MAY be restricted to use with either the management 592 protocol (Management) or the query protocol (Query). If so a 593 service would typically specify a ticket with a long expiry 594 time or no expiry for use with the management protocol and a 595 separate ticket for use with the query protocol. 597 Secret : Binary [1..1] 599 Shared secret 601 Encryption : Label [1..1] 603 Encryption Algorithm selected 605 Authentication : Label [1..1] 606 Authentication Algorithm selected 608 Ticket : Binary [1..1] 610 Opaque ticket issued by the server that identifies the 611 cryptographic parameters for encryption and authentication of 612 the message payload. 614 Expires : DateTime [0..1] 616 Date and time at which the context will expire 618 3.2.3. Structure: ImageLink 620 Algorithm : Label [0..1] 622 Image encoding algorithm (e.g. JPG, PNG) 624 Image : Binary [0..1] 626 Image data as specified by algorithm 628 3.2.4. Structure: Connection 630 Contains information describing a network connection. 632 Name : Name [0..1] 634 DNS Name. Since one of the functions of an OBP service is name 635 resolution, a DNS name is only used to establish a connection 636 if connection by means of the IP address fails. 638 Port : Integer [0..1] 640 TCP or UDP port number. 642 Address : Binary [0..1] 644 IPv4 (32 bit) or IPv6 (128 bit) service address 646 Priority : Integer [0..1] 648 Service priority. Services with lower priority numbers SHOULD 649 be attempted before those with higher numbers. 651 Weight : Integer [0..1] 653 Weight to be used to select between services of equal priority. 655 Transport : Label [0..1] 657 OBP Transport binding to be used valid values are HTTP, DNS and 658 UDP. 660 Expires : DateTime [0..1] 662 Date and time at which the specified connection context will 663 expire. 665 3.2.5. Bind 667 Binding a device is a two step protocol that begins with the Start 668 Query followed by a sequence of Ticket queries. 670 3.2.6. Message: BindRequest 672 The following parameters MAY occur in either a StartRequest or 673 TicketRequest: 675 Encryption : Label [0..Many] 677 Encryption Algorithm that the client accepts. A Client MAY 678 offer multiple algorithms. If no algorithms are specified then 679 support for the mandatory to implement algorithm is assumed. 680 Otherwise mandatory to implement algorithms MUST be specified 681 explicitly. 683 Authentication : Label [0..Many] 685 Authentication Algorithm that the client accepts. If no 686 algorithms are specified then support for the mandatory to 687 implement algorithm is assumed. Otherwise mandatory to 688 implement algorithms MUST be specified explicitly. 690 3.2.7. Message: BindResponse 692 The following parameters MAY occur in either a StartResponse or 693 TicketResponse: 695 Cryptographic : Cryptographic [0..Many] 697 Cryptographic Parameters. 699 Service : Connection [0..Many] 701 A Connection describing an OBP service point 703 3.2.8. Message: OpenRequest 705 The OpenRequest Message is used to begin a device binding 706 transaction. Depending on the authentication requirements of the 707 service the transaction may be completed in a single query or require 708 a further Ticket Query to complete. 710 If authentication is required, the mechanism to be used depends on 711 the capabilities of the device, the requirements of the broker and 712 the existing relationship between the user and the broker. 714 If the device supports some means of data entry, authentication MAY 715 be achieved by entering a passcode previously delivered out of band 716 into the device. 718 The OpenRequest specifies the properties of the service (Account, 719 Domain) and Device (ID, URI, Name) that will remain constant 720 throughout the period that the device binding is active and 721 parameters to be used for the mutual authentication protocol. 723 Account : String [0..1] 725 Account name of the user at the OBP service 727 Domain : Name [0..1] 729 Domain name of the OBP broker service 731 HavePasscode : Boolean [0..1] Default =False 733 If 'true', the user has entered a passcode value for use with 734 passcode authentication. 736 HaveDisplay : Boolean [0..1] Default =False 738 Specifies if the device is capable of displaying information to 739 the user or not. 741 Challenge : Binary [0..1] 743 Client challenge value to be used in authentication challenge 745 DeviceID : URI [0..1] 747 DeviceURI : URI [0..1] 749 DeviceName : String [0..1] 751 3.2.9. Message: OpenResponse 753 An Open request MAY be accepted immediately or be held pending 754 completion of an inband or out-of-band authentication process. 756 The OpenResponse returns a ticket and a set of cryptographic 757 connection parameters in either case. If the 759 Challenge : Binary [0..1] 761 Challenge value to be used by the client to respond to the 762 server authentication challenge. 764 ChallengeResponse : Binary [0..1] 766 Server response to authentication challenge by the client 768 VerificationImage : ImageLink [0..Many] 770 Link to an image to be used in an image verification mechanism. 772 3.2.10. Message: TicketRequest 774 The TicketRequest message is used to (1) complete a binding request 775 begun with an OpenRequest and (2) to refresh ticket or connection 776 parameters as necessary. 778 ChallengeResponse : Binary [0..1] 779 The response to a server authentication challenge. 781 3.2.11. Message: TicketResponse 783 The TicketResponse message returns cryptographic and/or connection 784 context information to a client. 786 3.2.12. Unbind 788 Requests that a previous device association be deleted. 790 3.2.13. Message: UnbindRequest 792 Since the ticket identifies the binding to be deleted, the only thing 793 that the unbind message need specify is that the device wishes to 794 cancel the binding. 796 3.2.14. Message: UnbindResponse 798 Reports on the success of the unbinding operation. 800 If the server reports success, the client SHOULD delete the ticket 801 and all information relating to the binding. 803 A service MAY continue to accept a ticket after an unbind request has 804 been granted but MUST NOT accept such a ticket for a bind request. 806 4. Omnibroker Query Service 808 4.1. OBPQuery 810 4.2. Message: Request 812 Every query request contains the following common elements: 814 Index : Integer [0..1] 816 Index used to request a specific response when multiple 817 responses are available. 819 4.3. Message: Response 821 Every Query Response contains the following common elements: 823 Status : Integer [1..1] 825 Status return code value 827 Index : Integer [0..1] 829 Index of the current response. 831 Count : Integer [0..1] 833 Number of responses available. 835 4.4. Structure: Identifier 837 Specifies an Internet service by means of a DNS address and either a 838 DNS service prefix, an IP port number or both. An Internet peer 839 connection MAY be specified by additionally specifying an account. 841 Name : Name [1..1] 843 The DNS name of the service to connect to. 845 Internationalized DNS names MUST be encoded in punycode 846 encoding. 848 Account : Label [0..1] 850 Identifies the account to connect to in the case that a peer 851 connection is to be established. 853 Service : Name [0..1] 855 The DNS service prefix defined for use with DNS records that 856 take a service prefix including SRV. 858 Port : Integer [0..1] 860 IP Port number. 862 A service identifier MUST specify either a service or a port or 863 both. 865 4.5. Structure: Connection 866 IPVersion : Integer [0..1] 868 Contains the IP version field. If absent, IPv4 is assumed. 870 IPProtocol : Integer [0..1] 872 Contains the IP protocol field. If absent, TCP is assumed. 874 IPAddress : Binary [0..1] 876 IP address in network byte order. This will normally be an 877 IPv4 (32 bit) or IPv6 (128 bit) address. 879 IPPort : Integer [0..1] 881 IP port. 1-65535 883 TransportPolicy : String [0..1] 885 Transport security policy as specified in [TBS] 887 ProtocolPolicy : String [0..1] 889 Application security policy specification as specified by the 890 application protocol. 892 Advice : Advice [0..1] 894 Additional information that a service MAY return to support a 895 service connection identification. 897 4.6. Structure: Advice 899 Additional information that a service MAY return to support a service 900 connection identification. For example, DNSSEC signatures chains, 901 SAML assertions, DANE records, Certificate Transparency proof chains, 902 etc. 904 Type : Label [0..1] 906 The IANA MIME type of the content type 908 Data : Binary [0..1] 910 The advice data. 912 4.7. Structure: Service 914 Describes a service connection 916 Identifier : Identifier [0..Many] 918 Internet addresses to which the service is to be bound. 920 Connection : Connection [0..1] 922 Service connection parameters. 924 4.8. QueryConnect 926 Requests a connection context to connect to a specified Internet 927 service or peer. 929 4.9. Message: QueryConnectRequest 931 Specifies the Internet service or peer that a connection is to be 932 established to and the acceptable security policies. 934 Identifier : Identifier [0..1] 936 Identifies the service or peer to which a connection is 937 requested. 939 Policy : Label [0..Many] 941 Acceptable credential validation policy. 943 ProveIt : Boolean [0..1] 945 If set the broker SHOULD send advice to permit the client to 946 validate the proposed connection context. 948 4.10. Message: QueryConnectResponse 950 Returns one or more connection contexts in response to a 951 QueryConnectRequest Message. 953 Connection : Connection [0..Many] 955 An ordered list of connection contexts with the preferred 956 connection context listed first. 958 Advice : Advice [0..1] 960 Proof information to support the proposed connection context. 962 Policy : Label [0..Many] 964 Policy under which the credentials have been verified. 966 4.11. Advertise 968 Advises a broker that one or more Internet services are being offered 969 with particular attributes. 971 4.12. Message: AdvertiseRequest 973 Specifies the connection(s) to be established. 975 The attributes required depend on the infrastructure(s) that the 976 broker is capable of registering the service with. 978 Service : Service [0..Many] 980 Describes a connection to be established. 982 4.13. Message: AdvertiseResponse 984 Specifies the connection(s) 986 Service : Service [0..Many] 988 Describes a connection that was established. 990 4.14. Validate 992 The Validate query requests validation of credentials presented to 993 establish a connection. For example credentials presented by a 994 server in the process of setting up a TLS session. 996 4.15. Message: ValidateRequest 998 Specifies the credentials to be validated and the purpose for which 999 they are to be used. 1001 Service : Service [0..1] 1002 Describes the service for which the credentials are presented 1003 for access. 1005 Credential : Credential [0..1] 1007 List of credentials for which validation is requested. 1009 Policy : Label [0..Many] 1011 Policy under which the credentials have been verified. 1013 4.16. Message: ValidateResponse 1015 Reports the status of the credential presented. 1017 Policy : Label [0..Many] 1019 Policy under which the credentials have been verified. 1021 4.17. QueryCredentialPassword 1023 The QueryCredentialPassword query is used to request a password 1024 credential that the user has previously chosen to store at the 1025 broker. 1027 4.18. Message: CredentialPasswordRequest 1029 Requests a password for the specified account. 1031 Account : String [0..1] 1033 The account for which a password is requested. 1035 4.19. Message: CredentialPasswordResponse 1037 Returns a password for the specified account. 1039 Password : String [0..1] 1041 The requested password. 1043 5. Transport Bindings 1045 To achieve an optimal balance of efficiency and availability, three 1046 transport bindings are defined: 1048 Supports all forms of OBP transaction in all network environments. 1050 Provides efficient support for a subset of OBP query transactions 1051 that is accessible in most network environments. 1053 Provides efficient support for all OBP query transactions and is 1054 accessible in most network environments. 1056 Support for the HTTP over TLS binding is REQUIRED. 1058 An OBP message consists of three parts: 1060 Ticket [As necessary] If specified, identifies the cryptographic key 1061 and algorithm parameters to be used to secure the message payload. 1063 Payload [Required] If the ticket context does not specify use of an 1064 encryption algorithm, contains the message data. Otherwise 1065 contains the message data encrypted under the encryption algorithm 1066 and key specified in the ticket context. 1068 Authenticator [Optional] If the ticket context specifies use of a 1069 Message Authentication Code (MAC), contains the MAC value 1070 calculated over the payload data using the authentication key 1071 bound to the ticket. 1073 Note that although each of the transport bindings defined in this 1074 specification entail the use of a JSON encoding for the message data, 1075 this is not a necessary requirement for a transport binding. 1077 5.1. HTTP over TLS 1079 OBP requests and responses are mapped to HTTP POST requests and 1080 responses respectively. Java Script Object Notation (JSON) encoding 1081 is used to encode requests and responses. 1083 5.1.1. Message Encapsulation 1085 Requests and responses are mapped to HTTP POST transactions. The 1086 content of the HTTP message is the message payload. The Content-Type 1087 MUST be specified as application/json. The Character set MUST be 1088 specified as UTF-8. 1090 The Ticket and Authenticator are specified using the Integrity header 1091 as follows: 1093 Integrity: ; ticket= 1095 5.1.2. Example 1097 [To be generated from spec] 1099 5.2. DNS Tunnel 1101 The DNS Tunnel mode of operation makes use of DNS TXT resource record 1102 requests and responses to tunnel OBP Query requests. Due to the 1103 constraints of this particular mode of operation, use of this 1104 transport is in practice limited to supporting transactions that can 1105 be expressed within 500 bytes. These include the QueryConnect and 1106 ValidateRequest interactions. 1108 5.2.1. Request 1110 Requests are mapped to DNS TXT queries. The request is mapped onto 1111 the DNS name portion of the query by encoding the Ticket, 1112 Authenticator and JSON encoded Payload using Base32 encoding and 1113 appending the result to the service prefix to create a DNS name as 1114 follows: 1116 ...Suffix 1118 The payload MAY be split across multiple DNS labels at any point. 1120 5.2.2. Response 1122 Responses are mapped to DNS TXT records by encoding the Authenticator 1123 and JSON encoded Payload using Base64 encoding and cocatenating the 1124 result with a periods as a separator as follows: 1126 . 1128 5.2.3. Example 1130 [To be generated from spec] 1132 5.3. UDP 1134 The UDP transport MAY be used for transactions where the request fits 1135 into a single UDP packet and the response can be accomadated in 16 1136 UDP packets. As with the Web Service Binding, Java Script Object 1137 Notation (JSON) encoding is used to encode requests and responses. 1139 5.3.1. Request 1141 The request consists of four message segments containing a Header, 1142 Ticket, Payload and Authenticator. Each message segment begins with 1143 a two byte field that specified the length of the following data 1144 segment in network byte order. The Payload is encoded in JSON 1145 encoding and the remaining fields as binary data without additional 1146 encoding. 1148 The header field for this version of the protocol (1.0) contains two 1149 bytes that specify the Major and Minor version number of the 1150 transport protocol being 1 and 0 respectively. Future versions of 1151 the transport protocol MAY specify additional data fields. 1153 [TBS diagram] 1155 5.3.2. Response 1157 The response consists of a sequence of packets. Each packet consists 1158 of a header section and a data section. 1160 The header section consists of a two byte length field followed by 1161 two bytes that speciofy the Major and Minor version number of the 1162 transport protocol (1 and 0), two bytes that specify the frame number 1163 and the total number of frames and two bytes that specify the message 1164 identifier. 1166 [TBS diagram] 1168 [Question, should the authenticator be over the whole message or 1169 should each packet have its own authenticator?] 1171 5.3.3. Example 1173 [To be generated from spec] 1175 6. Acknowledgements 1177 [List of contributors] 1179 7. Security Considerations 1181 7.1. Denial of Service 1183 7.2. Breach of Trust 1185 7.3. Coercion 1186 8. To do 1188 The specification should define and use a JSON security object. 1190 Formatting of the abstract data items needs to be improved 1192 Need to specify the UDP transport binding 1194 Should specify how each data item is represented in JSON format 1195 somewhere. This is obvious for some of the data types but needs 1196 to be fully specified for things like DateTime. 1198 Run the code to produce proper examples. 1200 Write a tool to transclude the example and other xml data into the 1201 document source. 1203 Fully document the API section. 1205 9. For discussion. 1207 Should the specification use the form urlencoded convention like 1208 OAUTH does? 1210 How should responses be cryptographically linked to requests? 1212 10. IANA Considerations 1214 [TBS list out all the code points that require an IANA registration] 1216 11. Normative References 1218 [RFC1035] Mockapetris, P., "Domain names - implementation and 1219 specification", STD 13, RFC 1035, November 1987. 1221 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1222 Requirement Levels", BCP 14, RFC 2119, March 1997. 1224 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 1225 and T. Wright, "Transport Layer Security (TLS) 1226 Extensions", RFC 4366, April 2006. 1228 [X.509] International Telecommunication Union, "ITU-T 1229 Recommendation X.509 (11/2008): Information technology - 1230 Open systems interconnection - The Directory: Public-key 1231 and attribute certificate frameworks", ITU-T 1232 Recommendation X.509, November 2008. 1234 [X.680] International Telecommunication Union, "ITU-T 1235 Recommendation X.680 (11/2008): Information technology - 1236 Abstract Syntax Notation One (ASN.1): Specification of 1237 basic notation", ITU-T Recommendation X.680, 1238 November 2008. 1240 Appendix A. Example Data. 1242 A.1. Ticket A 1244 A.2. Ticket B 1246 Author's Address 1248 Phillip Hallam-Baker 1249 Comodo Group Inc. 1251 Email: philliph@comodo.com