idnits 2.17.1 draft-hallambaker-wsconnect-08.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 : ---------------------------------------------------------------------------- ** There are 4 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 19, 2014) is 3628 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: 'ChallengeResponse' is mentioned on line 824, but not defined == Missing Reference: 'RFC1035' is mentioned on line 1372, but not defined == Unused Reference: 'RFC3339' is defined on line 1552, but no explicit reference was found in the text == Unused Reference: 'RFC4648' is defined on line 1555, but no explicit reference was found in the text == Unused Reference: 'I-D.hallambaker-jsonbcd' is defined on line 1562, but no explicit reference was found in the text == Unused Reference: 'I-D.hallambaker-httpsession' is defined on line 1584, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3709 (Obsoleted by RFC 9399) == Outdated reference: A later version (-24) exists of draft-hallambaker-jsonbcd-01 -- Possible downref: Normative reference to a draft: ref. 'I-D.hallambaker-jsonbcd' ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-01) exists of draft-hallambaker-privatedns-00 == Outdated reference: A later version (-03) exists of draft-hallambaker-httpsession-02 Summary: 5 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force (IETF) Phillip Hallam-Baker 2 Internet-Draft Comodo Group Inc. 3 Intended Status: Standards Track May 19, 2014 4 Expires: November 20, 2014 6 Service Connection Service (SXS) 7 draft-hallambaker-wsconnect-08 9 Abstract 11 Service Connection Service (SXS) is a JSON/REST Web Service that may 12 be used to establish and maintain a 'connection binding' of a device 13 to an account held with a Web Service Provider. Multiple connection 14 bindings may be established under the same account to support 15 multiple devices and/or multiple users of a single device. A 16 connection binding permits a device to securely connect to one or 17 more services offered by the Web Service Provider with support for 18 protocol and protocol version agilty and fault tollerance. 20 The protocol is presented as a HTTP/JSON Web Service and uses the 21 HTTP session continuation mechanism for authentication of transaction 22 messages and supports negotiation of a HTTP session continuation 23 mechanism context for the established endpoint connections. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 59 2. Introduction and Purpose . . . . . . . . . . . . . . . . . . . 5 60 2.1. Establishing a Web Service Provider Account . . . . . . . 5 61 2.2. Establishing a Connection Binding . . . . . . . . . . . . 6 62 2.2.1. Anonymous. . . . . . . . . . . . . . . . . . . . . . 7 63 2.2.2. PIN Code Establishement. . . . . . . . . . . . . . . 8 64 2.2.3. Out of Band Completion. . . . . . . . . . . . . . . 8 65 2.2.4. QR Code Preauthorization. . . . . . . . . . . . . . 9 66 3. Example Uses . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 3.1. PIN code establishment . . . . . . . . . . . . . . . . . 9 68 3.2. Unbinding . . . . . . . . . . . . . . . . . . . . . . . . 14 69 3.3. Out of Band Completion . . . . . . . . . . . . . . . . . 15 70 3.3.1. Message: Message . . . . . . . . . . . . . . . . . . 17 71 3.3.2. Message: Response . . . . . . . . . . . . . . . . . 17 72 3.3.3. Message: ConnectionRequest . . . . . . . . . . . . . 17 73 3.3.4. Structure: Cryptographic . . . . . . . . . . . . . . 17 74 3.3.5. Structure: ImageLink . . . . . . . . . . . . . . . . 18 75 3.3.6. Structure: Connection . . . . . . . . . . . . . . . 18 76 4. OBPConnection . . . . . . . . . . . . . . . . . . . . . . . . 18 77 4.1. Bind . . . . . . . . . . . . . . . . . . . . . . . . . . 19 78 4.1.1. Message: BindRequest . . . . . . . . . . . . . . . . 19 79 4.2. BindPIN . . . . . . . . . . . . . . . . . . . . . . . . . 19 80 4.2.1. Message: OpenPINRequest . . . . . . . . . . . . . . 19 81 4.2.2. Message: OpenPINResponse . . . . . . . . . . . . . . 20 82 4.3. Poll . . . . . . . . . . . . . . . . . . . . . . . . . . 21 83 4.3.1. Message: PollRequest . . . . . . . . . . . . . . . . 21 84 4.4. Ticket . . . . . . . . . . . . . . . . . . . . . . . . . 21 85 4.4.1. Message: TicketRequest . . . . . . . . . . . . . . . 21 86 4.4.2. Message: TicketResponse . . . . . . . . . . . . . . 21 87 4.5. Unbind . . . . . . . . . . . . . . . . . . . . . . . . . 22 88 4.5.1. Message: UnbindRequest . . . . . . . . . . . . . . . 22 89 4.5.2. Message: UnbindResponse . . . . . . . . . . . . . . 22 90 5. Mutual Authentication . . . . . . . . . . . . . . . . . . . . 22 91 5.1. PIN Authentication . . . . . . . . . . . . . . . . . . . 22 92 5.1.1. Example: Latin PIN Code . . . . . . . . . . . . . . 25 93 5.1.2. Example: Cyrillic PIN Code . . . . . . . . . . . . . 25 94 5.2. Out of Band Confirmation . . . . . . . . . . . . . . . . 26 95 6. Protocol Binding . . . . . . . . . . . . . . . . . . . . . . . 27 96 6.1. JSON encoding . . . . . . . . . . . . . . . . . . . . . . 27 97 6.1.1. HTTP Session Layer . . . . . . . . . . . . . . . . . 27 98 6.1.2. TLS transport . . . . . . . . . . . . . . . . . . . 28 99 7. Service Identification and Discovery . . . . . . . . . . . . . 28 100 8. UDP Binding (UYFM) . . . . . . . . . . . . . . . . . . . . . . 29 101 8.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 29 102 8.2. Response . . . . . . . . . . . . . . . . . . . . . . . . 30 103 8.3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . 31 104 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 105 10. Security Considerations . . . . . . . . . . . . . . . . . . . 32 106 10.1. Denial of Service . . . . . . . . . . . . . . . . . . . 32 107 10.2. Breach of Trust . . . . . . . . . . . . . . . . . . . . 32 108 10.3. Coercion . . . . . . . . . . . . . . . . . . . . . . . . 32 109 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 110 12. Stateless server . . . . . . . . . . . . . . . . . . . . . . 32 111 12.1. Temporary ID . . . . . . . . . . . . . . . . . . . . . . 33 112 12.2. Connection Binding ID . . . . . . . . . . . . . . . . . 34 113 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 114 13.1. Normative References . . . . . . . . . . . . . . . . . . 35 115 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 36 117 1. Definitions 119 1.1. Requirements Language 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 2. Introduction and Purpose 127 Service Connection Service (SXS) is a Web Service that may be used to 128 establish and maintain a 'connection binding' of a device to an 129 account held with a Web Service Provider (WSP). 131 SXS is presented in JSON encoding [RFC4627] over a HTTP Session 132 [RFC2616] using HTTP Session Continuation [I-D.hallambaker- 133 httpsession] for message layer authentication and TLS transport for 134 confidentiality and server authentication [RFC4627]. 136 A Connection Binding comprises a set of long term credentials used to 137 authenticate interactions with the SXS service itself and a set of 138 'Service Connections' to specific services offered by the Web Service 139 Provider. 141 Each service connection in turn comprises a collection of 'Instance 142 Connections' which describe a specific instances of the Web Service. 144 For example Alice is a consumer and example.com a provider of a range 145 of Web Services including anti-malware protection and management of 146 home automation devices. Alice has 42 devices of different types that 147 each make use of one or more of the Web Services proviced by 148 example.com. All the devices are enrolled in the same SXS account 149 'alice@example.com' but each device has a unique connection binding 150 and different devices make use of different Web Services. 152 The centralized account provides Alice with a single point of control 153 from which she can authorize the addition of new devices to the 154 account or the removal of devices that are deactivated. This allows 155 Alice to avoid the need to manage a device such as a network-enabled 156 lightswitch through the lightswitch itself. 158 To ensure continuity of service in case of network failure or 159 administration work, example.com provides multiple instances of its 160 Web Services hosted on different machines. Different users MAY be 161 granted access to a different collection of service instances 162 according to their needs and the service tier they are subscribed to. 164 2.1. Establishing a Web Service Provider Account 166 The means by which the Web Service Provider Account is established is 167 outside the scope of this document. 169 In a typical case the user would establish an account with their 170 chosen Web Service Provider through the normal process of using a Web 171 Browser to access the Web Service Provider's site and entering such 172 data as the Web Service Provider requires into a HTML form. 174 Depending on the circumstances, the data provided by the applicant 175 may require verification before the account is created. 177 [Default accounts for appliances that are going to be implicitly 178 authenticated by reference to the network they are on.] 180 2.2. Establishing a Connection Binding 182 A connection binding represents a long term association between a 183 device and an account at the Web Service Provider. The association 184 includes the establishment of an authentication context between the 185 device and the SXS service. 187 An authentication context consists of: A Context Identifier. An 188 authentication algorithm. A secret key. 190 The context identifier is an opaque string assigned by the SXS 191 service. Following the approach introduced in Kerberos, a SXS service 192 MAY eliminate the need to store authentication context information by 193 encoding the authentication algorithm and encrypted secret key in the 194 context identifier. 196 The authentication context can ensure that future communications are 197 secured against impersonation if and only if the original process of 198 establishing a connection binding was secured against communication. 199 Mutual authentication is therefore an essential requirement. 201 The means by which the connection binding is established depend on 202 the affordances of the device in question. Establishing a connection 203 binding to a device with a keyboard is easily accomplished through 204 use of a one-time PIN code. But many embedded devices do not provide 205 a keyboard or similar affordance. 207 The following modes of session establishement are supported: 209 * Anonymous. 211 * PIN Code Establishement. 213 * Out of Band Completion. 215 * QR Code Establishement. 217 2.2.1. Anonymous. 219 Private-DNS [I-D.hallambaker-privatedns] provides a means of making 220 DNS queries over a UYFM transport providing integrity and 221 confidentiality protections. 223 To establish a Private-DNS connection, a client first establishes a 224 SXS connection binding to the service. A Private-DNS service MAY 225 offer such services without requiring presentation or authentication 226 of credentials. The BindRequest transaction is used as follows: 228 POST /.well-known/sxs-connect/ HTTP/1.1 229 Content-Type: application/json;charset=UTF-8 230 Cache-Control: no-store 231 Host: localhost:8080 232 Content-Length: 226 233 Expect: 100-continue 235 { 236 "BindRequest": { 237 "Service": ["private-dns-resolver"], 238 "Encryption": ["A128CBC", 239 "A256CBC", 240 "A128GCM", 241 "A256GCM"], 242 "Authentication": ["HS256", 243 "HS384", 244 "HS512", 245 "HS256T128"]}} 247 Since the service does not require authentication, the request is 248 granted immediately and the necessary host connection parameters 249 returned immediately: 251 HTTP/1.1 OK Success 252 Content-Length: 578 253 Date: Mon, 19 May 2014 17:17:44 GMT 254 Server: Microsoft-HTTPAPI/2.0 256 { 257 "TicketResponse": { 258 "Status": 200, 259 "StatusDescription": "Success", 260 "Cryptographic": [], 261 "Service": [{ 262 "Service": "private-dns-resolver", 263 "Name": "localhost", 264 "Port": 9090, 265 "Priority": 100, 266 "Weight": 100, 267 "Transport": "UDP", 268 "Cryptographic": { 269 "Secret": " 270 WAX8Zj_oNmf7zI7uBlupQA", 271 "Encryption": "A128CBC", 272 "Authentication": "HS256T128", 273 "Ticket": " 274 Samh8lKlrNRaNZ6wQLMDGfqiUpc8dIBnYRutTu5g4RifL4CgwjMiGmCbHc4ZUiMd 275 -Yf_oUGRDnU05LwW0_8GyU_1X7dTyPPqNwvQyyZ_IoM"}}]}} 277 2.2.2. PIN Code Establishement. 279 To establish a connection binding for a new mobile phone, Alice logs 280 into her SXS account manager and requests a new PIN code. She then 281 starts the application that makes use of a SXS account and selects 282 'create new binding'. She is prompted for and enters her account name 283 (alice@example.com) and PIN. 285 The client connects to the SXS service and verifies that the TLS 286 certificate presented is correct for example.com and has been issued 287 in accordance with issue practices that ensure an appropriately high 288 degree of trust (e.g. the CABForum Extended Validation requirements). 290 2.2.3. Out of Band Completion. 292 To establish a connection binding for her new toaster oven, Alice 293 plugs the appliance into her local network and enters her account 294 name into the device. Since she has not obtained a PIN code in 295 advance, she leaves the entry blank. 297 To complete the process, Alice logs into her SXS account where she 298 sees that a new device is available to add to the account. To help 299 identify the correct device, there is a picture of the toaster oven, 300 the model name and serial number. 302 2.2.4. QR Code Preauthorization. 304 Alice decides to remodel the kitchen completely and plans to install 305 a dozen new network enabled LED light fixtures. Using an application 306 on the mobile phone she enabled earlier, Alice scans a QR code 307 attached to each fixture before the devices are installed. When the 308 fixtures are installed and powered, the connection binding is 309 preauthorized. 311 3. Example Uses 313 3.1. PIN code establishment 315 Alice buys a new laptop computer which she wishes to use with the 316 malware protection service provided by example.com. Alice has an 317 existing account 'alice' with this Web Service Provider and obtains a 318 pin code Q80370-1RA606-F04B from the Web Service Provider Web site. 320 Alice enters the values alice@example.com and Q80370-1RA606-F04B into 321 the Web Service client she wishes to use with the Web Service 322 Provider on the new laptop. 324 The client obtains the SXS service for example.com using DNS SRV 325 discovery. The client establishes a TLS connection to the service and 326 verifies that the certificate provided has a valid certificate path, 327 has not been revoked and meets the validation criteria of the client. 328 Since the purpose of this particular Web Service client is to provide 329 security, the client requires that an Extended Validation certificate 330 be presented. 332 Having established a TLS connection to the SXS Service, the client 333 sends the following HTTP request: 335 POST /.well-known/sxs-connect/ HTTP/1.1 336 Content-Type: application/json;charset=UTF-8 337 Cache-Control: no-store 338 Host: localhost:8080 339 Content-Length: 368 340 Expect: 100-continue 341 Connection: Keep-Alive 343 { 344 "OpenPINRequest": { 345 "Encryption": ["A128CBC", 346 "A256CBC", 347 "A128GCM", 348 "A256GCM"], 349 "Authentication": ["HS256", 350 "HS384", 351 "HS512", 352 "HS256T128"], 353 "Account": "alice", 354 "Service": ["sxs-confirm-user", 355 "omni-query"], 356 "Domain": "example.com", 357 "HaveDisplay": false, 358 "Challenge": " 359 BOen_kEze3TJi7nW6zO73A"}} 361 To prevent man in the middle attack, the client does not send the PIN 362 code in the initial request. The PIN code is only sent after the 363 service responds with a challenge nonce to be used to prevent replay 364 attack. 366 The service receives the request, determines that is meets its access 367 control policy and selects a set of cryptographic parameters from the 368 set proposed by the client. In this case the service prefers the use 369 of AES128CBC for encryption and the HS256 Message Authentication Code 370 for authentication. 372 The service determines that a PIN code has been issued for the 373 account and uses the value of that PIN to generate a response to the 374 challenge presented by the client. A new challenge is generated to 375 test the client knowledge of the PIN. 377 [TBS: Is there a need for the service to be able to support multiple 378 outstanding PIN codes for the same account? This could be supported 379 by providing the last 2 significant characters of the PIN code to the 380 service which could use it as an index. This would enable several 381 hundred simultaneous outstanding requests which should be enough for 382 most applications. Large volume applications would need to use a 383 different scheme.] 384 The service sends the following response to the client: 386 HTTP/1.1 281 Pin code required 387 Content-Length: 511 388 Date: Mon, 19 May 2014 17:17:43 GMT 389 Server: Microsoft-HTTPAPI/2.0 391 { 392 "OpenPINResponse": { 393 "Status": 281, 394 "StatusDescription": "Pin code required", 395 "Challenge": " 396 o9UKSBtH1MjO7SzYwtKIIw", 397 "ChallengeResponse": " 398 C35fTms7ps80RbS1hwSt7XgqRJlkttukb-frruN_hvw", 399 "Cryptographic": { 400 "Secret": " 401 p8eVWYPS0YrOVr0dILrcTg", 402 "Encryption": "A128CBC", 403 "Authentication": "HS256", 404 "Ticket": " 405 9EccpNHXKaU9wfmMsktFai9K_RC-4VGbiKgvAQWDaRzIjgw7SYa5NDxSpVUomkNv 406 auCbw8wc_EdZ-Rsc6mwDXrkpl-9GevKpywNYkgReNgz4PgSJWnVh9h-lPhFBd_0h 407 l8f1CuZ9FakXpeD5QCp8Eg"}}} 409 To complete the transaction, the client sends a TicketRequest message 410 to the service containing a response to the PIN challenge sent by the 411 service (ChallengeResponse). 413 The TicketRequest message is authenticated using HTTP Session 414 authentication under the shared secret specified in the OpenResponse 415 message: 417 POST /.well-known/sxs-connect/ HTTP/1.1 418 Content-Type: application/json;charset=UTF-8 419 Cache-Control: no-store 420 Session: Value=oNHs-K49eAGTa6JFgAP0_fBiV3OPIHah4eqoMYGkIeo; 421 Id=9EccpNHXKaU9wfmMsktFai9K_RC-4VGbiKgvAQWDaRzIjgw7SYa5NDxSpVUo 422 mkNvauCbw8wc_EdZ-Rsc6mwDXrkpl-9GevKpywNYkgReNgz4PgSJWnVh9h-lPhF 423 Bd_0hl8f1CuZ9FakXpeD5QCp8Eg 424 Host: localhost:8080 425 Content-Length: 153 426 Expect: 100-continue 428 { 429 "TicketRequest": { 430 "Service": ["sxs-confirm-user", 431 "omni-query"], 432 "ChallengeResponse": " 433 2s-hdGucN7DBgYsSlbP3YCt9XfNAJxmeiaFgU8zxprk"}} 435 The service checks the value of ChallengeResponse against the known 436 PIN and if the result is correct establishes parameters for the 437 Connection Binding for the device. 439 In this case the server uses the Session Id parameter to encode 440 permissions associated with the request as described in [Appendix 441 TBS]. Accordingly the server must replace the Session Id whenever the 442 associated permissions change. Accordingly, the server replaces the 443 cryptographic parameters specified in the OpenResponse request for 444 use in future SXS service requests. In this case the server returns 445 three connections, each offering a different transport protocol 446 option. Each connection specifies its own set of cryptographic 447 parameters (or will when the code is written for that). 449 The service also returns a service connection the malware protection 450 service the client requested access to. This service connection 451 specifies three different service instances. Each service instance 452 has its own set of cryptographic parameters for use with HTTP session 453 authentication. In this case the three different service instances 454 offer different means of accessing the same service: as a JSON Web 455 Service over HTTP, using a binary encoding over a UDP transport and 456 tunnelling via DNS. 458 HTTP/1.1 OK Success 459 Content-Length: 1762 460 Date: Mon, 19 May 2014 17:17:43 GMT 461 Server: Microsoft-HTTPAPI/2.0 463 { 464 "TicketResponse": { 465 "Status": 200, 466 "StatusDescription": "Success", 467 "Cryptographic": [{ 468 "Protocol": "sxs-connect", 469 "Secret": " 470 emwwtk9hgo--u6tE-mJ-uA", 471 "Encryption": "A128CBC", 472 "Authentication": "HS256", 473 "Ticket": " 474 On8L9OSNh1q4o2fMgSmahY3AYMwHY7cdt4jdp8bT9p1iAqgk18MXj3U_NdtrUxWG 475 nDyPfh2px3ZqTkjzPiiunzjOl-ye3mAmKTxGzXOgOvg"}], 476 "Service": [{ 477 "Service": "sxs-confirm-user", 478 "Name": "localhost", 479 "Port": 8080, 480 "Priority": 100, 481 "Weight": 100, 482 "Transport": "HTTP", 483 "Cryptographic": { 484 "Secret": " 485 2tFPA7RVgbcAv7WZC0hl0w", 486 "Encryption": "A128CBC", 487 "Authentication": "HS256T128", 488 "Ticket": " 489 o7znkpTHfrqcwsI1eHkPghCj7YsGUCp0KV2DcV1qXGlCt9wzmr2T6UcO_0YIAcEq 490 VdTsqRsYBtVNGs9SJyTCnMvjIlU1xQ9ZzoUtqtJsT4A"}}, 491 { 492 "Service": "omni-query", 493 "Name": "localhost", 494 "Port": 8080, 495 "Priority": 100, 496 "Weight": 100, 497 "Transport": "HTTP", 498 "Cryptographic": { 499 "Secret": " 500 GCBBcZPMs8Bz_c7Yb-F06Q", 501 "Encryption": "A128CBC", 502 "Authentication": "HS256T128", 503 "Ticket": " 504 ce2u2PZ3X1izYpCNUl3zrq-LBcRBiSdOfRSknOm33854OMnRKIZTWtbpiZIBvbmW 505 A23FlzDxp60SB18FTgbmh5ejJKxz9xVYvnmCUm8KhY0"}}, 506 { 507 "Service": "omni-query", 508 "Name": "localhost", 509 "Port": 9090, 510 "Priority": 100, 511 "Weight": 100, 512 "Transport": "UDP", 513 "Cryptographic": { 514 "Secret": " 515 eBt0w7YrK7tdCLAALLO3pg", 516 "Encryption": "A128CBC", 517 "Authentication": "HS256T128", 518 "Ticket": " 519 TDVD0DeoWdlU-RIWB0I5BV8Xgp3L5TZD8uqQP6v9PJwdIG6DQufqLsKjhu1wtV2p 520 jF8R37P9MJfhBWK-g4Yb4p7U3kBrUYgScOIxNbx31gQ"}}]}} 522 3.2. Unbinding 524 After a year of use, Alice decides to replace the laptop with a new 525 one. Before selling the old laptop on EBay, she tells the Web Service 526 client to cancel the connection to the Web Service Provider. 528 The client sends the following mesasage to the provider: 530 POST /.well-known/sxs-connect/ HTTP/1.1 531 Content-Type: application/json;charset=UTF-8 532 Cache-Control: no-store 533 Session: Value=RplcOyyQc_E4PcbNmL1vpt9xLOIdAXHNxqeBD_RHaJY; 534 Id=9EccpNHXKaU9wfmMsktFai9K_RC-4VGbiKgvAQWDaRzIjgw7SYa5NDxSpVUo 535 mkNvauCbw8wc_EdZ-Rsc6mwDXrkpl-9GevKpywNYkgReNgz4PgSJWnVh9h-lPhF 536 Bd_0hl8f1CuZ9FakXpeD5QCp8Eg 537 Host: localhost:8080 538 Content-Length: 24 539 Expect: 100-continue 541 { 542 "UnbindRequest": {}} 544 The Session ID specifies the connection binding. Since the Unbind 545 Request is only valid for that connection binding, there is no need 546 to specify the connection binding further in the request. 548 The server verifies that the request was authenticated and returns a 549 successful response: 551 HTTP/1.1 OK Success 552 Content-Length: 79 553 Date: Mon, 19 May 2014 17:17:43 GMT 554 Server: Microsoft-HTTPAPI/2.0 556 { 557 "UnbindResponse": { 558 "Status": 200, 559 "StatusDescription": "Success"}} 561 3.3. Out of Band Completion 563 Alice purchases an Internet enabled coffee pot. The installer 564 configures the coffee pot in her kitchen but does not have access to 565 Alice's SXS account or a PIN code to configure it. 567 The installer configures the coffee pot to use the SXS account 568 specified by Alice. The coffee pot does not have a pssscode to enter 569 but does have a link to an image of the coffee pot. 571 The client sends the following request: 573 POST /.well-known/sxs-connect/ HTTP/1.1 574 Content-Type: application/json;charset=UTF-8 575 Cache-Control: no-store 576 Host: localhost:8080 577 Content-Length: 224 578 Expect: 100-continue 580 { 581 "BindRequest": { 582 "Service": ["coffee-pot-control"], 583 "Encryption": ["A128CBC", 584 "A256CBC", 585 "A128GCM", 586 "A256GCM"], 587 "Authentication": ["HS256", 588 "HS384", 589 "HS512", 590 "HS256T128"]}} 592 Since the client does not have a PIN code, there is no need to return 593 a challenge. Instead the service returns the status "OOB" to indicate 594 that the transaction will be completed out of band. 596 HTTP/1.1 282 Transaction Incomplete 597 Content-Length: 162 598 Date: Mon, 19 May 2014 17:17:43 GMT 599 Server: Microsoft-HTTPAPI/2.0 601 { 602 "TicketResponse": { 603 "Status": 282, 604 "StatusDescription": "Transaction Incomplete", 605 "TransactionID": " 606 psqoiqY_7mPWIZM3uqDm2g", 607 "MinRetry": 10}} 609 By default the coffee pot attempts to complete the SXS connection at 610 ten second intervals for the first ten minutes, every thirty seconds 611 for the next hour, every five minutes for the following 24 hours and 612 once an hour thereafter. 614 The client sends the following request to check the status of the 615 request: 617 POST /.well-known/sxs-connect/ HTTP/1.1 618 Content-Type: application/json;charset=UTF-8 619 Cache-Control: no-store 620 Host: localhost:8080 621 Content-Length: 22 622 Expect: 100-continue 624 { 625 "PollRequest": {}} 627 The first service response tells the coffee pot not to ask again 628 until five minutes have elapsed: 630 HTTP/1.1 282 Transaction Incomplete 631 Content-Length: 162 632 Date: Mon, 19 May 2014 17:17:43 GMT 633 Server: Microsoft-HTTPAPI/2.0 635 { 636 "TicketResponse": { 637 "Status": 282, 638 "StatusDescription": "Transaction Incomplete", 639 "TransactionID": " 640 Gup4C1t8v7MKvUwsmT-ffA", 641 "MinRetry": 10}} 643 The installer calls Alice to tell her that the coffee pot is ready to 644 connect. Alice authorizes the connection remotely via the Web Service 645 Provider's Web site. Alice identifies the request to connect the 646 coffee pot by means of the image provided. She can also use the same 647 image to help determine which connection to cancel when the coffee 648 pot is replaced. 650 The next time the coffee pot requests a status update, the service 651 responds with the connection binding parameters: 653 HTTP/1.1 282 Transaction Incomplete 654 Content-Length: 162 655 Date: Mon, 19 May 2014 17:17:44 GMT 656 Server: Microsoft-HTTPAPI/2.0 658 { 659 "TicketResponse": { 660 "Status": 282, 661 "StatusDescription": "Transaction Incomplete", 662 "TransactionID": " 663 blwpd6lDr7_a9tDviLvmGA", 664 "MinRetry": 10}} 666 3.3.1. Message: Message 668 3.3.2. Message: Response 670 Status : 671 Integer [0..1] Application layer server status code 673 StatusDescription : 674 String [0..1] Describes the status code (ignored by processors) 676 3.3.3. Message: ConnectionRequest 678 3.3.4. Structure: Cryptographic 680 Parameters describing a cryptographic context. 682 Protocol : 683 Label [0..1] OBP tickets MAY be restricted to use with either 684 the management protocol (Management) or the query protocol 685 (Query). If so a service would typically specify a ticket with 686 a long expiry time or no expiry for use with the management 687 protocol and a separate ticket for use with the query protocol. 689 Secret : 690 Binary [1..1] Shared secret 692 Encryption : 693 Label [1..1] Encryption Algorithm selected 695 Authentication : 696 Label [1..1] Authentication Algorithm selected 698 Ticket : 699 Binary [1..1] Opaque ticket issued by the server that 700 identifies the cryptographic parameters for encryption and 701 authentication of the message payload. 703 Expires : 704 DateTime [0..1] Date and time at which the context will expire 706 3.3.5. Structure: ImageLink 708 Algorithm : 709 Label [0..1] Image encoding algorithm (e.g. JPG, PNG) 711 Image : 712 Binary [0..1] Image data as specified by algorithm 714 3.3.6. Structure: Connection 716 Contains information describing a network connection. 718 Service : 719 Label [0..1] The service identifier 721 Name : 722 Name [0..1] DNS Name. Since one of the functions of an OBP 723 service is name resolution, a DNS name is only used to 724 establish a connection if connection by means of the IP address 725 fails. 727 Port : 728 Integer [0..1] TCP or UDP port number. 730 Address : 731 String [0..1] IPv4 (32 bit) or IPv6 (128 bit) service address 733 Priority : 734 Integer [0..1] Service priority. Services with lower priority 735 numbers SHOULD be attempted before those with higher numbers. 737 Weight : 738 Integer [0..1] Weight to be used to select between services of 739 equal priority. 741 Transport : 742 Label [0..1] OBP Transport binding to be used valid values are 743 HTTP, DNS and UDP. 745 Expires : 746 DateTime [0..1] Date and time at which the specified connection 747 context will expire. 749 Cryptographic : 750 Cryptographic [0..1] Cryptographic Parameters. 752 4. OBPConnection 754 4.1. Bind 756 4.1.1. Message: BindRequest 758 The following parameters MAY occur in either a StartRequest or 759 TicketRequest: 761 Service : 762 Label [0..Many] The service identifier for the protocol for 763 which a connection is being established. 765 Encryption : 766 Label [0..Many] Encryption Algorithm that the client accepts. A 767 Client MAY offer multiple algorithms. If no algorithms are 768 specified then support for the mandatory to implement algorithm 769 is assumed. Otherwise mandatory to implement algorithms MUST be 770 specified explicitly. 772 Authentication : 773 Label [0..Many] Authentication Algorithm that the client 774 accepts. If no algorithms are specified then support for the 775 mandatory to implement algorithm is assumed. Otherwise 776 mandatory to implement algorithms MUST be specified explicitly. 778 4.2. BindPIN 780 Binding a device with mutual authentication is a two step protocol 781 that begins with the OpenPINRequest followed by the Ticket Request. 783 4.2.1. Message: OpenPINRequest 785 The OpenRequest Message is used to begin a device binding 786 transaction. Depending on the authentication requirements of the 787 service the transaction may be completed in a single query or require 788 a further Ticket Query to complete. 790 If authentication is required, the mechanism to be used depends on 791 the capabilities of the device, the requirements of the broker and 792 the existing relationship between the user and the broker. 794 If the device supports some means of data entry, authentication MAY 795 be achieved by entering a passcode previously delivered out of band 796 into the device. 798 The OpenRequest specifies the properties of the service (Account, 799 Domain) and Device (ID, URI, Name) that will remain constant 800 throughout the period that the device binding is active and 801 parameters to be used for the mutual authentication protocol. 803 Account : 804 String [0..1] Account name of the user at the OBP service 806 Service : 807 Label [0..Many] The service identifier for the protocol for 808 which a connection is being established. 810 Domain : 811 Name [0..1] Domain name of the OBP broker service 813 HavePasscode : 814 Boolean [0..1] Default =False If 'true', the user has entered a 815 passcode value for use with passcode authentication. 817 HaveDisplay : 818 Boolean [0..1] Default =False Specifies if the device is 819 capable of displaying information to the user or not. 821 Challenge : 822 Binary [0..1] Client challenge value to be used in 823 authentication challenge mechanism as described in section 824 [ChallengeResponse] 826 DeviceID : 827 URI [0..1] Device identifier unique for a particular instance 828 of a device such as a MAC or EUI-64 address expressed as a URI 830 DeviceURI : 831 URI [0..1] Device identifier specifying the type of device, 832 e.g. an xPhone. 834 DeviceImage : 835 ImageLink [0..1] An image identifying the physical appearance 836 of the device. 838 DeviceName : 839 String [0..1] Descriptive name for the device that would 840 distinguish it from other similar devices, e.g. 'Alice's 841 xPhone". 843 4.2.2. Message: OpenPINResponse 845 An Open request MAY be accepted immediately or be held pending 846 completion of an inband or out-of-band authentication process. 848 The OpenResponse returns a ticket and a set of cryptographic 849 connection parameters in either case. If the 850 Challenge : 851 Binary [0..1] Challenge value to be used by the client to 852 respond to the server authentication challenge. 854 ChallengeResponse : 855 Binary [0..1] Server response to authentication challenge by 856 the client as described in section 858 Cryptographic : 859 Cryptographic [0..1] Cryptographic Parameters. 861 VerificationImage : 862 ImageLink [0..Many] Link to an image to be used in an image 863 verification mechanism. 865 4.3. Poll 867 4.3.1. Message: PollRequest 869 The TicketRequest message is used to complete a binding request that 870 returned an incomplete status (350 code) 872 TransactionID : 873 Binary [0..1] Opaque transaction identifier returned when 874 transaction could not complete 876 4.4. Ticket 878 4.4.1. Message: TicketRequest 880 The TicketRequest message is used to (1) complete a binding request 881 begun with an PINRequest and (2) to refresh ticket or connection 882 parameters as necessary. 884 Service : 885 Label [0..Many] The service identifier for the protocol for 886 which a connection is being established. 888 ChallengeResponse : 889 Binary [0..1] The response to a serer authentication challenge 890 as described in section 892 4.4.2. Message: TicketResponse 894 The TicketResponse message returns cryptographic and/or connection 895 context information to a client. 897 Cryptographic : 898 Cryptographic [0..Many] Cryptographic Parameters. 900 Service : 901 Connection [0..Many] A Connection describing an OBP service 902 point 904 TransactionID : 905 Binary [0..1] Opaque transaction identifier returned when 906 transaction could not complete. 908 MinRetry : 909 Integer [0..1] Minimum time to elapse before a status polling 910 request will be responded to. 912 4.5. Unbind 914 Requests that a previous device association be deleted. 916 4.5.1. Message: UnbindRequest 918 Since the ticket identifies the binding to be deleted, the only thing 919 that the unbind message need specify is that the device wishes to 920 cancel the binding. 922 4.5.2. Message: UnbindResponse 924 Reports on the success of the unbinding operation. 926 If the server reports success, the client SHOULD delete the ticket 927 and all information relating to the binding. 929 A service MAY continue to accept a ticket after an unbind request has 930 been granted but MUST NOT accept such a ticket for a bind request. 932 5. Mutual Authentication 934 A Connection Service MAY require that a connection request be 935 authenticated. Two authentication mechanisms are defined. 937 PIN Code 938 The client and server demonstrate mutual knowledge of a PIN 939 code previously exchanged out of band. 941 Out of Band Confirmation 942 The request for access is confirmed out of band. 944 In addition, services MAY accept the use of any message or transport 945 layer authentication scheme. For example HTTP Session Continuation or 946 Transport Layer Security with client authentication. 948 5.1. PIN Authentication 950 PIN code authentication provides users with a simple and often 951 familiar mechanism for authenticating the connection request. The 952 means by which the user obtains the PIN code is outside the scope of 953 this document. Possible methods for distributing the PIN code include 954 obtaining the code from an account management Web site provided by 955 the Web Service Provider, letter post, email and in person. 957 Although the PIN value is never exposed on the wire in any form, the 958 protcol considers the PIN value to be text encoded in UTF8 encoding. 960 To encourage readability, the use of space (0x20) and hyphen (0x2D) 961 characters to arrange PIN characters into groups of four to seven 962 characters is encouraged. To avoid the risk of this practice 963 introducing user error, space and hyphen characters are ignored when 964 processing the PIN value. 966 Support for the full UNICODE character set in PIN codes is intended 967 to facilitate provision of PIN codes in the user's native language. 968 Web Service Providers MAY make use of any UNICODE characters they 969 choose but capricious choices are likely to cause users difficulty. 970 For example a PIN code MAY contain the ZAPF Dingbats thick tick mark 971 (U+2704) but users would almost certainly find it difficult to enter 972 and may confuse it with the similar thin tick mark (U+2703). 974 Servers that support PIN Authorization SHOULD offer the choice of a 975 PIN that only uses numeric digits ('0', '1', '2', '3', '4', '5', '6', 976 '7', '8', '9'). Clients that support PIN Authorization MUST allow 977 entry of PINS that only contain numeric digits. 979 The PIN Mechanism is a three step process: 981 The client sends an OpenRequest message to the Service containing a 982 challenge value CC. 983 The service returns an OpenResponse message containing to the client a 984 server challenge value SV and a server response value SR. 985 The client sends a TicketRequest message to the service containing a 986 client response value CR. 988 Since no prior authentication key has been established the 989 OpenRequest and OpenResponse messages are sent without message 990 authentication. 992 The Challenge values CC, and SC are cryptographic nonces. The nonces 993 SHOULD be generated using an appropriate cryptographic random source. 994 The nonces MUST be at least as long as 128 bits, MUST be at least the 995 minimum key size of the authentication algorithm used and MUST NOT 996 more than 640 bits in length (640 bits should be enough for anybody). 998 The server response and client response values are generated using an 999 authentication algorithm selected by the server from the choices 1000 proposed by the client in the OpenRequest message. 1002 The algorithn chosen may be a MAC algorithm or an encrypt-with- 1003 authentication (EWA) algorithm. If an EWA is specified, the encrypted 1004 data is discarded and only the authentication value is used in its 1005 place. 1007 Let A(d,k) be the authentication value obtained by applying the 1008 authentication algorithm with key k to data d. 1010 To create the Server Response value, the UTF8 encoding of the PIN 1011 value 'P' is first pre-processed to remove space and hyphen 1012 characters, then converted into a symmetric key KPC by using the 1013 Client challenge value as the key truncating if necessary and then 1014 applied to the of the OpenRequest message: 1016 [ 1017 KPC = A (PIN, CC) 1018 SR = A (Secret + OpenRequest, KPC) 1020 In the Web Service Binding, the Payload of the message is the HTTP 1021 Body as presented on the wire. The Secret and Server Challenge are 1022 presented in their binary format and the '+' operator stands for 1023 simple concatenation of the binary sequences. 1025 This protocol construction ensures that the party constructing SR: 1027 Knows the PIN code value (through the construction of KPC). Is 1028 responding to the Open Request Message (SR depends on OpenRequest). 1029 Has knowlege of the secret key which MUST be used to authenticate the 1030 following TicketRequest/TicketResponse interaction that will 1031 establish the actual connection. Does not provide an oracle the PIN 1032 value. That is, the protocol does not provide a service that reveals 1033 the (since the value SR includes the value SC which is a random nonce 1034 generated by the server and cannot be predicted by the client). 1036 To create the Client Response value, secret key is applied to the PIN 1037 value and server Challenge: 1039 CR = A (PIN + SC + OpenResponse, Secret) 1041 Note that the server can calculate the value of the Client Response 1042 token at the time that it generates the Server Challenge. This 1043 minimizes the amount of state that needs to be carried from one 1044 request to the next in the Ticket value when using the stateless 1045 server implementation described in section 1046 This protocol construction ensures that the generator of CR 1048 Knows the PIN value. Is respoding to the OpenResponse generated by 1049 the server. 1051 Note that while disclosure of an oracle for the PIN value is a 1052 concern in the construction of CR, this is not the case in the 1053 construction of SR since the client has already demonstrated 1054 knowledge of the PIN value. 1056 5.1.1. Example: Latin PIN Code 1058 The Connection Request example of section demonstrates the use of an 1059 alphanumeric PIN code using the Latin alphabet. 1061 The PIN code is [[Q80370-1RA606-F04B] and the authentication 1062 algorithm is [[HS256]. The value KPC is calculated thus: 1064 PIN: 51 38 30 33 37 30 2d 31 52 41 36 30 36 2d 46 30 34 42 1066 Client Challenge: 04 e7 a7 fe 41 33 7b 74 c9 8b b9 d6 eb 33 bb dc 1068 KPC: 10 c9 32 db 58 77 16 d6 cb 07 21 d9 36 b0 1c dd 25 9e af 75 ba 1069 28 24 96 38 67 ac 7c 7f dd 6f 38 1071 For the sake of example, we take the OpenRequest message payload to 1072 be {...}. The data over which the hash value is calulated is Secret + 1073 OpenRequest: 1075 Secret: a7 c7 95 59 83 d2 d1 8a ce 56 bd 1d 20 ba dc 4e 1077 Request Payload: 7b 2e 2e 2e 7d 1079 Server Response: fe fc 5b 76 4a d4 e2 e5 bc 17 02 3f a9 58 15 92 cd 1080 1e 7d ae c5 a1 c4 cb 71 d8 ea 94 33 cd ed f2 1082 The data for the client response is PIN + Server Challenge + Payload: 1084 PIN: 51 38 30 33 37 30 2d 31 52 41 36 30 36 2d 46 30 34 42 1086 Server Challenge: a3 d5 0a 48 1b 47 d4 c8 ce ed 2c d8 c2 d2 88 23 1088 Request Payload: 7b 2e 2e 2e 7d 1090 Applying the key Secret to the data produces the client response: 1092 Client Response: 0a 48 14 35 3a bd 5c fb 55 5f 05 24 0b 94 a0 a0 a0 1093 1c 00 07 d4 ea 6c 1f 2a 50 b2 25 a7 7c ef bd 1095 5.1.2. Example: Cyrillic PIN Code 1097 If the PIN code in the earlier example was 'parol1' (the Russian for 1098 'password1') in Cyrilic script the value KP would be calculated as 1099 follows 1101 PIN: d0 bf d0 b0 d1 80 d0 be d0 bb d1 8c 31 1103 KPC: 10 c9 32 db 58 77 16 d6 cb 07 21 d9 36 b0 1c dd 25 9e af 75 ba 1104 28 24 96 38 67 ac 7c 7f dd 6f 38 1106 The rest of the protocol would then continue as before. 1108 5.2. Out of Band Confirmation 1110 The Out Of Band Confirmation mechanism is a three step process in 1111 which: 1113 * The client makes an OpenRequest message to the service and 1114 obtains an OpenResponse message. 1116 * The connection binding is authorized through an out of band 1117 process. 1119 * The client makes a TicketRequest to the service and obtains a 1120 TicketResponse message to complete the exchange. 1122 Since no prior authentication key has been established the 1123 OpenRequest and OpenResponse messages are sent without 1124 authentication. 1126 The principal concern in the Out Of Band Confirmation mechanism is 1127 ensuring that the party authorizing the request is able to identify 1128 which party originated the request they are attempting to identify. 1130 If a device has the ability to display an image it MAY set the 1131 HasDisplay=true in the OpenRequest message. If the broker recieves an 1132 OpenRequest with the HasDisplay value set to true, the OpenResponse 1133 MAY contain one or more VerificationImage entries specifying image 1134 data that is to be displayed to the user by both the client and the 1135 confirmation interface. 1137 Before confirming the request, the user SHOULD verify that the two 1138 images are the same and reject the request in the case that they are 1139 not. 1141 Many devices do not have a display capability, in particular an 1142 embedded device such as a network switch or a thermostat. In this 1143 case the device MAY be identified by means of the information 1144 provided in DeviceID, DeviceURI, DeviceImage and DeviceName. 1146 6. Protocol Binding 1148 A single protocol binding is defined: 1150 * JSON encoding is used to express SXS messages. 1152 * A HTTP session layer with HTTP session continuation is used for 1153 message authentication. 1155 * TLS transport is required for confidentiality and service 1156 authentication. 1158 Implementations MAY support use of alternative encodings, session 1159 layers or transports provided that the necessary confidentiality and 1160 authentication criteria described below are met. The means by which 1161 negotiation of the use of such encodings is achieved is outside the 1162 scop of this document. 1164 6.1. JSON encoding 1166 Messages are expressed in JSON encoding [RFC4627]. 1168 Protocol schema types are mapped to JSON encoding as follows: 1170 Integer 1171 Data of type Integer is encoded using the JSON number encoding. 1173 Name 1174 Data of type Name is encoded using the JSON string encoding. 1176 String 1177 Data of type String is encoded using the JSON string encoding. 1179 Binary 1180 Data of type Binary is converted to strings using the Base64url 1181 encoding specified in [!RFC4648] /> and encoded using the JSON 1182 string type. 1184 DateTime 1185 Data of type DateTime is converted to string using the UTC time 1186 conversion specified in [!RFC3339] /> with a UTC offset of 1187 00:00. 1189 6.1.1. HTTP Session Layer 1191 Messages are presented over a HTTP session layer [RFC2616]. The use 1192 of HTTP as a session layer permits multiple Web Services on the same 1193 host to share the same DNS name, IP address and port number and 1194 enables use of HTTP Session Continuation [I-D.hallambaker- 1195 httpsession] for message authentication. 1197 Use of HTTP Session Continuation mechanism allows message 1198 authentication data to be presented in the HTTP message header rather 1199 than the message content provides a clean separation of the message 1200 authentication data from the data being authenticated. The scope of 1201 the authentication data is simply the message content after transport 1202 encoding (e.g. chunked) has been removed. 1204 The use of HTTP session continuation is necessary to achieve mutual 1205 authentication even though TLS transport is required. 1207 Only the HTTP Session header is used. The negotiation of the Session 1208 parameters is performed within SXS. 1210 [TO-DO: Specify TLS binding options?] 1212 [TO-DO: Switch back from using JOSE algorithm names to HTTP Session 1213 algorithm names] 1215 6.1.2. TLS transport 1217 TLS transport [RFC4627] is used 1219 Support for the PKIX logotype extension [RFC3709] is highly 1220 recommended 1222 Use of an enhanced assurance certificate (e.g. CABForum EV) is likely 1223 to be required in most applications and is strongly recommended if 1224 Lotypes are used. 1226 7. Service Identification and Discovery 1228 The prefix '[PREFIX-TBD]' has been registered for use as a protocol 1229 identifier for SXS in the URI, SRV and Well Known Location 1230 registries. 1232 The URI form identifying a SXS account identifier is: 1234 PREFIX-TBD:::< or PREFIX- 1235 TBD:::<:subaccount> 1237 Where is the DNS name of the Web Service Provider, 1238 is the name of the account at the service provider and 1239 is an optional sub-account specifier. 1241 Use of the URI form is only needed in cases where the purpose of the 1242 identifier is not clear from the context, in a HTML anchor for 1243 example. A SXS client requesting entry of the service account 1244 identifier MUST support entry of the short form identifier: 1246 @ or <:subaccount>/@ 1248 DNS Service (SRV) record discovery is the preferred method of host 1249 discovery as this provides for fault tollerance and load balancing. 1251 SXS clients SHOULD support use of DNS SRV records for host discovery 1252 and MUST support use of DNS A/AAAA records for host discovery. 1254 A compliant SXS service MUST be offered at the .well-known location 1255 /.well-known/PREFIX-TBD. Use of SXS protocol at other service 1256 locations is permissible for testing and protocol development 1257 purposes but such configurations are not compliant and clients are 1258 not required to support them. The URL for the SXS service is 1259 therefore: 1261 https:///.well-known/PREFIX-TBD 1263 8. UDP Binding (UYFM) 1265 The UDP Binding (UYFM) allows a transaction to be transmitted as a 1266 single UDP packet request followed by up to 16 UDP response packets. 1267 The message encapsulation is described using the format desribed in 1268 [RFC5246]. Note that in this notation the size of a length specifier 1269 is defined by the maximum number of octets permitted in the 1270 corresponding data field. For convenience these sizes are given as 1271 255 or 65335 to specify 1 and 2 byte length specifiers respectively. 1272 The actual length of the data fields that can be used in practice 1273 will depend on the maximum size of UDP packet that can be reliably 1274 transmitted. 1276 opaque TransactionID<16..255> 1277 opaque SecurityContextID<1..255> 1279 8.1. Request 1281 If the UDP transport is in use, a request consists of exactly one 1282 packet. 1284 A request has the following structure: 1286 struct { 1287 TransactionID transactionID; 1288 SecurityContextID securityContextID; 1289 opaque encryptedPayload<1..65535> 1290 opaque authenticationCode<1..255> 1291 } Request; 1293 Where: 1295 transactionID 1296 Is a unquie identifier for the transaction and an input to the 1297 function used to derrive the initialization vector (IV) for the 1298 encryption algorithm 1300 securityContextID 1301 Is the opaque security context identifier returned by the 1302 Service Connect Service. 1304 encryptedPayload 1305 Is the encrypted message payload. 1307 8.2. Response 1309 A response MAY consist of 1 or up to 16 packets, each formatted as 1310 follows: 1312 struct { 1313 TransactionID transactionID; 1314 uint8 index; 1315 uint8 maxIndex; 1316 uint16 clearResponse; 1317 opaque encryptedPayloadSegment<0..65535> 1318 opaque authenticationCode<1..255> 1319 } Response; 1321 Where: 1323 transactionID 1324 Is a unquie identifier for the transaction and an input to the 1325 function used to derrive the initialization vector (IV) for the 1326 encryption algorithm 1328 index 1329 Is the index number of this response packet. 1331 maxIndex 1332 Is the index number of the last packet. The value of maxIndex 1333 MUST be the same for every packet. Receivers MUST reject 1334 packets 1336 clearResponse 1337 Is a response code sent enclair. The value 0 indicates a 1338 successful response. Error codes TBS. It might be expedient to 1339 merge these with index and maxIndex to shave some bytes. 1341 encryptedPayloadSegment 1342 Is the encrypted message payload segment. 1344 To obtain the encryptedPayload of the response, the receiver: 1346 * Waits for all the response packets to arrive 1348 * Sorts the response packets by the value of index. 1350 * Extracts the value of encryptedPayloadSegment from each 1351 response 1353 * Concatenate the values of encryptedPayloadSegment to obtain the 1354 encryptedPayload value 1356 UDP packets MAY be sent out of order and the order in which they were 1357 received MAY not match the order in which they were sent. A receiver 1358 MUST accept response packets recieved in any order. 1360 8.3. Payload 1362 The payload is a sequence of the following types of data: 1364 JSONData 1365 Payload data in JSON encoding 1367 JSONCData 1368 Payload data in JSON-C encoding as described in [!I- 1369 D.hallambaker-jsonbcd] 1371 DNSMessageEntry 1372 A DNS Message as specified in [RFC1035] 1374 PaddingEntry 1375 The Payload MAY contain padding. 1377 LastMAC 1378 MAC value from the previous message in the transaction. 1380 SecurityContextIDEntry 1381 A replacement security context identifier. 1383 KeyEntry 1384 A secret key for use with the immediately preceeding 1385 SecurityContextID. 1387 Future use 1388 The Payload may contain additional options (To be defined) 1390 The payload data is encoded according to the following schema: 1392 enum {PaddingEntry (0), SecurityContextIDEntry (2), 1393 KeyEntry (3), LastMac (4), JSONData (16), JSONCData (17), 1394 DNSMessageEntry (18), (255)} PayloadEntryType; 1396 struct { 1397 PayloadEntryType entryType; 1398 opaque data<0..65535> 1399 } Response; 1401 The SecurityContextIDEntry and KeyEntry data types are used by the 1402 server to issue a new security context and key to the client. 1403 Changing the security context identifier prevents linkage of 1404 transactions across network configurations. 1406 One consequence of putting the LastMAC value inside the Payload data 1407 is that this provides an attacker with a sequence of known plaintext 1408 and ciphertext. 1410 9. Acknowledgements 1412 Rob Stradling, Robin Alden... 1414 10. Security Considerations 1416 10.1. Denial of Service 1418 10.2. Breach of Trust 1420 10.3. Coercion 1422 11. IANA Considerations 1424 [TBS list out all the code points that require an IANA registration] 1426 12. Stateless server 1428 The protocol is designed to permit but not require the server to 1429 store connection binding state in the Session ID of the HTTP Session 1430 Continuation authentication mechanism. 1432 The Session IDs are opaque as far as the client is concerned. The 1433 client receives the Session ID from the service and returns it with 1434 each request. The internal structure of the Session ID is therefore 1435 outside the scope of this specification but is provided here to 1436 assist implementers. 1438 In the PIN Authentication example, two SessionIDs are issued by the 1439 server: 1441 * A temporary ID in response to the initial client OpenRequest. 1443 * A connection binding ID when the client PIN confirmation is 1444 accepted and the connection binding is created. 1446 Both tickets have the same common wrapper structure: 1448 IV + Encrypt ( Ticket + Mac ( Ticket, Key) Key) 1450 Where: 1452 IV 1453 The Initialization vector for the encryption scheme 1455 Encrypt 1456 The Encryption algorithm (AES in CBC Mode) 1458 Ticket 1459 The ticket data 1461 MAC 1462 The Message Authentication algorithm (HMAC-SHA2-256) 1464 12.1. Temporary ID 1466 The temporary ticket returned in the OpenRequest example above is 1467 represented in Base64URL encoding as follows: 1469 9EccpNHXKaU9wfmMsktFai9K_RC-4VGbiKgvAQWDaRzIjgw7SYa5NDxSpVUomkNv 1470 auCbw8wc_EdZ-Rsc6mwDXrkpl-9GevKpywNYkgReNgz4PgSJWnVh9h-lPhFBd_0h 1471 l8f1CuZ9FakXpeD5QCp8Eg 1473 The format of the ticket is 16 1475 IV: f4 47 1c a4 d1 d7 29 a5 3d c1 f9 8c b2 4b 45 6a 1477 Encrypted Data: 2f 4a fd 10 be e1 51 9b 88 a8 2f 01 05 83 69 1c c8 8e 1478 0c 3b 49 86 b9 34 3c 52 a5 55 28 9a 43 6f 6a e0 9b c3 cc 1c fc 47 59 1479 f9 1b 1c ea 6c 03 5e b9 29 97 ef 46 7a f2 a9 cb 03 58 92 04 5e 36 0c 1480 f8 3e 04 89 5a 75 61 f6 1f a5 3e 11 41 77 fd 21 97 c7 f5 0a e6 7d 15 1481 a9 17 a5 e0 f9 40 2a 7c 12 1482 The encrypted data is decrypted under the master key of the server. 1483 In this example the server has a single fixed key that does not 1484 change over time. There should really be a key index prefixing it to 1485 identify the key number. 1487 The Master Key is: 55 e1 0a 1a 8e 68 8a bd 5a 15 d8 cb b2 63 38 ef 9d 1488 3d 78 bf 62 62 f9 eb 52 ed af ee a5 55 67 0d 1490 The decrypted data contains the algorithm identifiers, shared secret 1491 and message authentication code: 1493 Version Number: 00 1495 Key Identifier: 01 1497 Authentication Algorithm: 00 1499 Encryption Algorithm: 00 1501 Key Data: a7 c7 95 59 83 d2 d1 8a ce 56 bd 1d 20 ba dc 4e 1503 User Name Length: 11 1505 User Name: 61 6c 69 63 65 40 65 78 61 6d 70 6c 65 2e 63 6f 6d 1507 Client Challenge Length: 10 1509 Client Challenge: 04 e7 a7 fe 41 33 7b 74 c9 8b b9 d6 eb 33 bb dc 1511 Server Challenge Length: 10 1513 Server Challenge: a3 d5 0a 48 1b 47 d4 c8 ce ed 2c d8 c2 d2 88 23 1515 Message Authentication Code: aa e3 19 72 c3 bc 6c 1f 48 35 0f 47 5a 1516 3a 78 5e 34 b1 9e 92 32 42 10 a0 b2 d7 90 94 e6 8c 82 7e 1518 12.2. Connection Binding ID 1520 The format of the Connection binding ticket is similar to that of the 1521 Temporary ticket except that it does not contain the Client or Server 1522 challenge nonces. 1524 IV: 3a 7f 0b f4 e4 8d 87 5a b8 a3 67 cc 81 29 9a 85 1526 Encrypted Data: 8d c0 60 cc 07 63 b7 1d b7 88 dd a7 c6 d3 f6 9d 62 02 1527 a8 24 d7 c3 17 8f 75 3f 35 db 6b 53 15 86 9c 3c 8f 7e 1d a9 c7 76 6a 1528 4e 48 f3 3e 28 ae 9f 38 ce 97 ec 9e de 60 26 29 3c 46 cd 73 a0 3a f8 1529 The decrypted data is: 1531 Version Number: 00 1533 Key Identifier: 00 1535 Authentication Algorithm: 00 1537 Encryption Algorithm: 00 1539 Key Data: 7a 6c 30 b6 4f 61 82 8f be bb ab 44 fa 62 7e b8 1541 User Name Length: 0c 1543 User Name: 65 40 65 78 61 6d 70 6c 65 2e 63 40 1545 Message Authentication Code: 90 c2 4b 03 17 47 31 19 60 85 96 23 8f 1546 4b 9c 53 b6 1a b2 9a 75 01 3a 76 19 38 11 63 66 f3 b8 7b 1548 13. References 1550 13.1. Normative References 1552 [RFC3339] Klyne, G.,Newman, C., "Date and Time on the Internet: 1553 Timestamps", RFC 3339, July 2002. 1555 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1556 Encodings", RFC 4648, October 2006. 1558 [RFC3709] Santesson, S.,Housley, R.,Freeman, T., "Internet X.509 1559 Public Key Infrastructure: Logotypes in X.509 1560 Certificates", RFC 3709, February 2004. 1562 [I-D.hallambaker-jsonbcd] Hallam-Baker, P, "Binary Encodings for 1563 JavaScript Object Notation: JSON-B, JSON-C, JSON-D", 1564 Internet-Draft draft-hallambaker-jsonbcd-01, 21 January 1565 2014. 1567 [RFC5246] Dierks, T.,Rescorla, E., "The Transport Layer Security 1568 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1570 [RFC4627] Crockford, D., "The application/json Media Type for 1571 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 1573 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1574 Requirement Levels", BCP 14, RFC 2119, March 1997. 1576 [RFC2616] Fielding, R.,Gettys, J.,Mogul, J.,Frystyk, H.,Masinter, 1577 L.,Leach, P.,Berners-Lee, T., "Hypertext Transfer Protocol 1578 -- HTTP/1.1", RFC 2616, June 1999. 1580 [I-D.hallambaker-privatedns] Hallam-Baker, P, "Private-DNS", 1581 Internet-Draft draft-hallambaker-privatedns-00, 9 May 1582 2014. 1584 [I-D.hallambaker-httpsession] Hallam-Baker, P, "HTTP Session 1585 Management", Internet-Draft draft-hallambaker-httpsession- 1586 02, 21 January 2014. 1588 Author's Address 1590 Phillip Hallam-Baker 1591 Comodo Group Inc. 1593 philliph@comodo.com