idnits 2.17.1 draft-hallambaker-mesh-confirm-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 IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (August 16, 2017) is 2416 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'None' is mentioned on line 965, but not defined -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hallam-Baker 3 Internet-Draft Comodo Group Inc. 4 Intended status: Informational August 16, 2017 5 Expires: February 17, 2018 7 Mesh Confirmation Protocol (Mesh/Confirm) 8 draft-hallambaker-mesh-confirm-01 10 Abstract 12 Mesh Confirmation Protocol (Mesh/Confirm) is a three-party Web 13 Service that supports a transactional second factor confirmation 14 mechanism that provides a superset of the capabilities of traditional 15 second factor authentication schemes. The three parties in the 16 protocol are Enquirer who posts a confirmation request, a Responder 17 who may or may not respond to the request and the Broker which 18 provides a repository to which requests and responses are posted. 20 This document is also available online at 21 http://prismproof.org/Documents/draft-hallambaker-mesh-confirm.html . 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on February 17, 2018. 40 Copyright Notice 42 Copyright (c) 2017 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1. Related Specifications . . . . . . . . . . . . . . . . . 4 60 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 4 61 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 62 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.1. Confirmation vs. Authentication . . . . . . . . . . . . . 5 64 3.2. Use Scenarios . . . . . . . . . . . . . . . . . . . . . . 6 65 3.3. Use in Financial Services . . . . . . . . . . . . . . . . 6 66 3.4. Machine Binding . . . . . . . . . . . . . . . . . . . . . 6 67 3.5. Tethered Use . . . . . . . . . . . . . . . . . . . . . . 7 68 3.6. Co-Browser . . . . . . . . . . . . . . . . . . . . . . . 7 69 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 8 70 4.1. Parties . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 4.2. Accounts . . . . . . . . . . . . . . . . . . . . . . . . 8 72 4.3. Open and Closed Services . . . . . . . . . . . . . . . . 9 73 5. Confirmation Protocol . . . . . . . . . . . . . . . . . . . . 9 74 5.1. Creating a confirmation profile . . . . . . . . . . . . . 9 75 5.2. Posting a request . . . . . . . . . . . . . . . . . . . . 9 76 5.3. Obtaining request status. . . . . . . . . . . . . . . . . 12 77 5.4. List pending requests. . . . . . . . . . . . . . . . . . 13 78 5.5. Post a response . . . . . . . . . . . . . . . . . . . . . 14 79 6. Mesh/Confirm Service . . . . . . . . . . . . . . . . . . . . 16 80 6.1. Request Messages . . . . . . . . . . . . . . . . . . . . 16 81 6.1.1. Message: ConfirmRequest . . . . . . . . . . . . . . . 16 82 6.2. Response Messages . . . . . . . . . . . . . . . . . . . . 16 83 6.2.1. Message: ConfirmResponse . . . . . . . . . . . . . . 16 84 6.3. Imported Objects . . . . . . . . . . . . . . . . . . . . 17 85 6.4. Common classes . . . . . . . . . . . . . . . . . . . . . 17 86 6.4.1. Structure: AccountEntry . . . . . . . . . . . . . . . 17 87 6.4.2. Structure: EntryBase . . . . . . . . . . . . . . . . 17 88 6.4.3. Structure: RequestEntry . . . . . . . . . . . . . . . 18 89 6.4.4. Structure: ResponseEntry . . . . . . . . . . . . . . 18 90 6.4.5. Structure: TBSRequest . . . . . . . . . . . . . . . . 18 91 6.4.6. Structure: TBSResponse . . . . . . . . . . . . . . . 19 92 6.5. Utility Transactions . . . . . . . . . . . . . . . . . . 19 93 6.6. Transaction: Hello . . . . . . . . . . . . . . . . . . . 19 94 6.7. Enquirer Transactions . . . . . . . . . . . . . . . . . . 19 95 6.8. Transaction: Enquire . . . . . . . . . . . . . . . . . . 19 96 6.8.1. Message: EnquireRequest . . . . . . . . . . . . . . . 19 97 6.8.2. Message: EnquireResponse . . . . . . . . . . . . . . 19 98 6.9. Transaction: Status . . . . . . . . . . . . . . . . . . . 20 99 6.9.1. Message: StatusRequest . . . . . . . . . . . . . . . 20 100 6.9.2. Message: StatusResponse . . . . . . . . . . . . . . . 20 101 6.10. Responder Transactions . . . . . . . . . . . . . . . . . 20 102 6.11. Transaction: Pending . . . . . . . . . . . . . . . . . . 20 103 6.11.1. Message: PendingRequest . . . . . . . . . . . . . . 21 104 6.11.2. Message: PendingResponse . . . . . . . . . . . . . . 21 105 6.12. Transaction: Respond . . . . . . . . . . . . . . . . . . 21 106 6.12.1. Message: RespondRequest . . . . . . . . . . . . . . 22 107 6.12.2. Message: RespondResponse . . . . . . . . . . . . . . 22 108 7. Simple Request Markup Language (SRMLv1) . . . . . . . . . . . 22 109 7.1. XML Schema and Content Type Identifier . . . . . . . . . 22 110 7.2. Design considerations and future options . . . . . . . . 23 111 8. Request Authentication and Authorization . . . . . . . . . . 23 112 8.1. Service Authentication . . . . . . . . . . . . . . . . . 23 113 8.2. Responder Authentication . . . . . . . . . . . . . . . . 24 114 8.3. Enquirer Authentication . . . . . . . . . . . . . . . . . 24 115 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 24 116 9.1. Reference Implementation . . . . . . . . . . . . . . . . 25 117 9.1.1. Coverage: . . . . . . . . . . . . . . . . . . . . . . 25 118 9.1.2. Licensing . . . . . . . . . . . . . . . . . . . . . . 26 119 9.1.3. Implementation Experience . . . . . . . . . . . . . . 26 120 9.1.4. Contact Info . . . . . . . . . . . . . . . . . . . . 26 121 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 122 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 123 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 124 12.1. Normative References . . . . . . . . . . . . . . . . . . 26 125 12.2. Informative References . . . . . . . . . . . . . . . . . 27 126 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27 128 1. Introduction 130 Authentication of end users is one of the biggest challenges for 131 Internet and Web security today. Despite an abundance of technology 132 that offers authentication mechanisms that are more robust, more 133 secure and easier to use, the default mechanism for user 134 authentication is the use of usernames and passwords. 136 Mesh/Confirm is a second factor authentication mechanism that binds 137 the user's response to the decision asked of the user. If the user 138 is attempting to log in to a network host, they receive a 139 confirmation message on a device they habitually carry such as a 140 watch or a smart phone asking if that is what they want to do and 141 they respond by accepting or rejecting the request. 143 [[This figure is not viewable in this format. The figure is 144 available at http://prismproof.org/Documents/draft-hallambaker-mesh- 145 confirm.html.]] 147 Confirmation User Experience 149 Unlike traditional second factor authentication schemes, Mesh/Confirm 150 does not require the user to carry a special purpose 'smart' token or 151 to enter randomly changing PIN codes. 153 Mesh/Confirm is designed to make full use of the features afforded by 154 a modern smartphone. In particular, a Mesh/Confirm client device 155 MUST support a means of presenting text output to and accepting text 156 input from the user and a network connection. While mobile devices 157 offering this degree of functionality were rare in 2007, they have 158 since become ubiquitous. In addition to smartphones, many users now 159 carry smart watches and the class of wearable electronics is expected 160 to expand further in years to come. It is thus now a practical 161 proposition for a site requiring second factor authentication to 162 support at least a part of its users using a technology that requires 163 such affordances. 165 2. Definitions 167 This section presents the related specifications and standards on 168 which Mesh/Recrypt is built, the terms that are used as terms of art 169 within the documents and the terms used as requirements language. 171 2.1. Related Specifications 173 The related specifications used in the Mesh/Recrypt protocol are 174 described in the Mesh Architecture specification [draft-hallambaker- 175 mesh-architecture] [draft-hallambaker-mesh-architecture] 177 2.2. Defined Terms 179 TBS 181 2.3. Requirements Language 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 185 document are to be interpreted as described in [RFC2119] [RFC2119] . 187 3. Overview 189 Second factor authentication mechanisms offer greater security over 190 the use of passwords alone by combining a first factor (typically a 191 password) with a second factor, typically a biometric or proof of 192 possession of a physical token. 194 Traditional second factor authentication techniques have suffered 195 from the need to distribute physical tokens and the difficulty of 196 ensuring that a biometric authentication is presented to a 197 trustworthy terminal. 199 The usability of traditional second factor authentication techniques 200 has been poor or worse. Even the simplest scheme in which the user 201 is required to read in a 'one time use' numeric code from the 202 authentication token device and enter it into a password field. 203 While such operations are relatively simple they require the user to 204 engage in a sequence of operations that bears no necessary or natural 205 relationship to the underlying task for which the authentication is 206 required. 208 Nor does the act of engaging in a traditional second factor scheme 209 offer proof of anything other than that the user was authenticated. 210 Any correspondence between the act of authentication and the purpose 211 for which the authentication was provided must be maintained 212 separately. 214 3.1. Confirmation vs. Authentication 216 A confirmation service addresses by cryptographically binding 217 responses to the request that they reply to. 219 A confirmation service allows the user experience to be precisely 220 matched to the action that the user is attempted. This is simpler 221 and more secure than a traditional second factor authentication 222 scheme. Instead of being asked to read a random number from one 223 device and enter it into another, the user is asked if they really 224 want to perform the action for which authentication is requested. 226 A confirmation service offers better accountability for end users 227 than a traditional second factor authentication scheme. An 228 authentication service only provides an assertion that the user was 229 present. A confirmation service provides an assertion that the user 230 was present and that they confirmed (or refused) a specific request. 232 For example, Alice has been granted access to a machine storing 233 classified data. If an authentication service is used for access 234 control, the authentication service log will only record the dates 235 and times that Alice accessed the system. to find out if Alice 236 accessed a particular file on a particular day it is necessary to 237 consult and correlate both the authentication log of the system and 238 the activity log for the application. 240 If instead a confirmation service is used the confirmation log 241 contains an authenticated record of both the authentication events 242 and the transactions for which the authentication was requested. 244 3.2. Use Scenarios 246 A confirmation service complements rather than replaces a traditional 247 authentication scheme. Providing a highly secure and convenient 248 means of authenticating requests that carry a high degree of risk 249 mitigates the risk of using convenient but intrinsically low security 250 techniques for other actions. 252 3.3. Use in Financial Services 254 If an attacker is to profit from breaching an account with a 255 financial service such as a bank or a brokerage they must find a way 256 to move money out of the account. Thus, adding bill payment 257 recipients, initiating wire transfers and trading in low volume 258 'penny stocks' represent high risk activities. 260 For example: Bank of Ethel might permit customers to use a simple 261 username and password scheme to gain access to their account to check 262 their balance or to send payments to existing recipients but require 263 use of the second factor confirmation device for a high-risk 264 transaction such as adding a new payee or making a substantially 265 higher payment than normal. 267 3.4. Machine Binding 269 A second factor confirmation service may be combined with a machine 270 level authentication scheme to permit a transparent form of 271 authentication for low risk transactions. 273 For example: Alice stores her low risk authentication credentials 274 (e.g. usernames and passwords) using a 'cloud' service. When she 275 wishes to use those credentials an agent on her personal machine 276 fetches credentials from the cloud service as necessary. When Alice 277 wishes to access a site from a different machine she receives a 278 confirmation request on her mobile device to grant access from that 279 machine. 281 Use of such a mechanism is clearly more satisfactory when suitable 282 cryptographic protocols such as SAML or Kerberos are employed to 283 limit the disclosure and hence possible compromise of the 284 credentials. The specification of such protocols is outside the 285 scope of this document. 287 3.5. Tethered Use 289 Although Mesh/Confirm is designed for use in a three-party scenario, 290 there are situations in which a two party mode may be preferred. 292 For example: Bob is a roadwarrior who requires access to confidential 293 documents stored on his laptop device from anywhere in the world, 294 including locations where Internet access is not possible. To permit 295 access in such circumstances, Bob's Mesh/Confirm client supports use 296 of a tethered mode in which the mobile device is connected via 297 Bluetooth or plugged into his laptop via a USB port. 299 For example: Carol is a network manager of a large computing facility 300 that uses Mesh/Confirm to authenticate and track all changes to 301 critical resources. Since Mesh/Confirm is itself a network resource 302 a bootstrap consideration arises: How can Carol confirm her network 303 configuration requests using Mesh/Confirm when the network itself is 304 down? Support for a tethered mode in which the Mesh/Confirm device 305 communicates via USB or similar wired protocol allows this use case 306 to be supported. 308 While availability of a tethered mode is clearly essential if Mesh/ 309 Confirm is to be used in certain applications, support for this 310 feature outside the scope of this version of the specification. 312 3.6. Co-Browser 314 While Mesh/Confirm is designed for deployment on a secondary device, 315 deployment on the same device as the one for which confirmation is 316 being requested is also possible and can provide security benefits. 318 Modern Web browsers are large and complex with many features such as 319 support for mobile code that are incompatible with a high security 320 environment. Separating the confirmation protocol from the Web 321 Browsing protocol permits implementation in a minimal client designed 322 to permit detailed security analysis. Such a client might be 323 embedded in or support means of secure interaction with a trustworthy 324 operating system component. 326 While this means of deployment does not provide a true second factor 327 confirmation, it is likely to provide a sufficient degree of 328 authentication for many transactions. 330 4. Architecture 332 Mesh/Confirm is a Web Service that permits an Enquirer to request 333 that a User confirm or reject a specified action. If the user 334 responds, the response is signed with a digital signature under a key 335 that is unique to the user account, the client and the device. 337 4.1. Parties 339 Each Mesh/Confirm protocol interaction takes place between a 340 connection pair of the following parties: 342 A party that initiates a confirmation request. 344 The User is the person being asked to grant or refuse 345 confirmation. A User MAY have multiple accounts with multiple 346 Broker Services. 348 A device that the user has bound to their broker account. 350 A clearing house that stores and forwards requests from Initiators 351 to Users Device and responses from Users to Initiators. The 352 Broker is only trusted to perform routing filtering and recording 353 of requests and responses. The Broker is not trusted with respect 354 to the responses returned. 356 The communication between the parties is shown in Figure 1. 358 [[This figure is not viewable in this format. The figure is 359 available at http://prismproof.org/Documents/draft-hallambaker-mesh- 360 confirm.html.]] 362 Mesh/Confirm Parties 364 4.2. Accounts 366 Users are identified by means of an account identifier. The display 367 presentation of an account identifier is the form of an RFC2822 email 368 address identifier without the enclosing angle braces, for example: 370 alice@example.com 372 The account identifier is used by the User when registering the use 373 of the confirmation service with a Broker. 375 4.3. Open and Closed Services 377 A Mesh/Confirm service MAY be Open or Closed. An Open service 378 provider provides Mesh/Confirm service to the general public. A 379 Closed service provider only provides service to a specific 380 community. 382 For example: An Internet Service Provider or DNS Registrar might 383 provide an open Mesh/Confirm service as a part of their standard 384 service offering to customers. An employer might operate a closed 385 Mesh/Confirm service to be used for company business. 387 5. Confirmation Protocol 389 (Configuration). 391 5.1. Creating a confirmation profile 393 [First step is to create a mesh profile and add a confirmation 394 profile. This is not currently supported by the reference code, the 395 implementation uses the device profile instead.] 397 5.2. Posting a request 399 An Enquirer initiates a confirmation request using the EnquireRequest 400 message. This specifies the request to be posted, the account to 401 which it is posted and (optionally) the time at which the enquirer 402 has no further interest in receiving a response. 404 The signed request is a JsonWebSignature object that contains a 405 payload of type TBSRequest that specifies the confirmation text to be 406 presented to the user in SRML format, the account identifier of the 407 requestor and the account identifier as the responder. The 408 TBSRequest object MAY be encrypted. 410 The Responder identifier is thus specified in two separate places, in 411 the signed TBSRequest and in the enclosing EnquireRequest message. 412 Following the terminology introduced to describe the SMTP protocol, 413 these correspond to the 'Message to' and 'Envelope to' addresses 414 respectively. Separating these two functions is useful because it 415 allows the unsigned envelope to address to be modified to support 416 request routing capabilities such as aliases and group addresses 417 while maintaining the ability to authenticate the message to address. 419 For example, a party claiming to be 'Bob' calls Alice asking her to 420 open the pod bay doors. Following procedure, Alice requires Bob to 421 provide a non-repudiable confirmation of this request. Accordingly, 422 she uses her confirmation account alice@example.com to post a request 423 to Bob's confirmation account bob@example.com asking him to confirm 424 the action. 426 Alice uses the client supplied by the reference implementation to 427 post this request. This client does not form part of the normative 428 Mesh/Confirm specification and is used here purely to illustrate the 429 information that a user or script needs to pass to request a 430 transaction. 432 The console command is: 434 confirm post bob@example.com "Open pod bay doors" 436 The TBSRequest is: 438 $$$$ extract TBS part here. 440 The HTTP request message is: 442 POST /.well-known/confirm/HTTP/1.1 443 Host: example.com 444 Content-Length: 1095 446 { 447 "EnquireRequest": { 448 "Request": { 449 "Request": { 450 "unprotected": { 451 "dig": "S512"}, 452 "payload": " 453 ewogICJUQlNSZXF1ZXN0IjogewogICAgIlRleHQiOiAiPHNybWw-PGgxPk9wZW4g 454 cG9kIGJheSBkb29yczwvaDE-PC9zcm1sPiIsCiAgICAiRnJvbUlEIjogImFsaWNl 455 QGV4YW1wbGUubmV0IiwKICAgICJUb0lEIjogImJvYkBleGFtcGxlLmNvbSJ9fQ", 456 "signatures": [{ 457 "header": { 458 "kid": "MDQY6-SNGTN-KUOHT-ULDZW-RGD5G-ZFMMD"}, 459 "protected": " 460 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCmpHWmlYMU5EeGxLMmtfUm1H 461 dUV4NEtWSTMybkxMUmZYVnJZbXVUMDQwR1VIa3p6dEVtWG43eW1pQXh3dVl0cEUK 462 ZXBpUGNNNEhWMFRZbTM4TlFRdjlodyJ9", 463 "signature": " 464 VMc4Q6Ulp_BaInclyf-7rvhWISAU-MfXbvxTkfjr8vgw1iAZ5NnTPoPI85LbUChr 465 Eu1SR9bbkyLiIdrRcxV7ZWRH6fncpRRTiVEosI4qbxBDtFYxyjrDZlpFtfMOIkLx 466 RPU7fh93DSTO3NjlMs7G0C5ki_6mIDjxzylkKfBzKhV1OnqCmTp5KWVLGlW91DnH 467 -ci7GuE6qN2rQdDfCThiAmumGJdxtSuXbYSq1cR3WZF2uPmRMp2T0QuS3hikyDiu 468 -8yFGoV1keiyKPJWnrscXOVGMJmxNPSFLZkcYlR9TK-rmMNr6NnXvZ8nJsZmSxb7 469 5ztWbnM67mYfqQ0FdA3wDg"}]}, 470 "ResponderAccount": "bob@example.com", 471 "Expire": "2017-08-17T01:15:59Z"}}} 473 Figure 1 475 A confirmation service SHOULD perform some form of request filtering 476 to prevent abuse (e.g. spam, denial of service). In this case the 477 request comes from a user with a local account which is implictly 478 authorized to post request messages without limit. 480 The confirmation service verifies the signature on the request and 481 returns a response message specifying the broker identifier. 483 HTTP/1.1 200 OK 484 Date: Wed 16 Aug 2017 09:15:59 485 Content-Length: 162 487 { 488 "EnquireResponse": { 489 "Status": 201, 490 "StatusDescription": "Operation completed successfully", 491 "BrokerID": "MBMQF-2G2XH-RCEXI-YISIK-GYGB6-A2JU3-A"}} 493 Figure 2 495 [Note that for the sake of concise presentation, the HTTP binding 496 information is omitted from future examples.] 498 5.3. Obtaining request status. 500 Having posted a request, the enquirer needs to discover the result. 501 Since the protocol assumes that the response will be posted by a 502 person rather than a machine, it is likely that there will be a delay 503 of several seconds at least and possibly many minutes. For certain 504 types of confirmation, the responder might take hours or even days. 506 A status request is posted using the StatusRequest message. The 507 enquirer specifies the BrokerID of the request being enquired of. 509 { 510 "StatusRequest": { 511 "Cancel": false, 512 "BrokerID": "MBMQF-2G2XH-RCEXI-YISIK-GYGB6-A2JU3-A"}} 514 Figure 3 516 The service responds with the status of the request and the 517 Responder's response if they have replied. The first time the 518 enquirer asks, the request is still pending: 520 { 521 "StatusResponse": { 522 "Status": 201, 523 "StatusDescription": "Operation completed successfully", 524 "Response": { 525 "BrokerID": "MBMQF-2G2XH-RCEXI-YISIK-GYGB6-A2JU3-A", 526 "RequestStatus": "PENDING"}}} 528 Figure 4 530 When the enquirer repeats the status request a short time later, the 531 responder has posted a response. The service returns the response 532 message returned: 534 { 535 "StatusResponse": { 536 "Status": 201, 537 "StatusDescription": "Operation completed successfully", 538 "Response": { 539 "BrokerID": "MBMQF-2G2XH-RCEXI-YISIK-GYGB6-A2JU3-A", 540 "RequestStatus": "Reply", 541 "Response": { 542 "unprotected": { 543 "dig": "S512"}, 544 "payload": " 545 ewogICJUQlNSZXNwb25zZSI6IHsKICAgICJTaWduZWRSZXF1ZXN0IjogewogICAg 546 ICAidW5wcm90ZWN0ZWQiOiB7CiAgICAgICAgImRpZyI6ICJTNTEyIn0sCiAgICAg 547 ... 548 ZnFRMEZkQTN3RGcifV19LAogICAgIlZhbHVlIjogdHJ1ZX19" 549 , 550 "signatures": [{ 551 "header": { 552 "kid": "MD725-EFAK3-VICWN-62ZWA-53F23-UIZED"}, 553 "protected": " 554 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCkhBS1dpNzFYZy13ZHpaYkxS 555 TVlHb00xSHNDS3lFdl9hX3JyTzFCVjNyeUtBaUoxd1VhNmFVei1zWjRpajJiWnoK 556 NUNuclFQcmlyam1idDBRRThtd093USJ9" 557 , 558 "signature": " 559 LlVM3kprGKbZSIFcrCu55zNIibpzot3M0akJlJurbJE1qHrHHveKT6kb1v95VMUC 560 BaeIPaeHCDCeqTml4eqmm2tk9GyAfCzGpFpFD2L2gGPzAWaU0Xww3HBdoUxq04lx 561 z5A9--KT-fb96eAiNI2ha6GhNT6xacY4mpDp9X2dKrjBqBntg_psRO6kVDmt5A8w 562 Zi9SS_tRsp7dRgTXXj2AOCuJKPgu9B1kthQFfbvxYxY-xSNNmmFimn86xB8lwcxg 563 y9qsXX-sOG_o9FslGBcRf1aUi2Uq7D-0-nvYcRt-LWb4wFzjCLhSuxhZ3tGsHkd9 564 a_hmWtuifMu8Fs-NpNHo3w" 565 }]}}}} 567 Figure 5 569 5.4. List pending requests. 571 From the enquirer's point of view, the confirmation protocol is like 572 a very limited version of email. 574 The enquirer periodically polls the confirmation service to retrieve 575 a list of pending messages using ther PendingRequest message. 577 { 578 "PendingRequest": { 579 "Responder": "bob@example.com"}} 581 Figure 6 583 The response contains a list of pending responses: 585 { 586 "PendingResponse": { 587 "Status": 201, 588 "StatusDescription": "Operation completed successfully", 589 "Entries": [{ 590 "BrokerID": "MBMQF-2G2XH-RCEXI-YISIK-GYGB6-A2JU3-A", 591 "Request": { 592 "unprotected": { 593 "dig": "S512"}, 594 "payload": " 595 ewogICJUQlNSZXF1ZXN0IjogewogICAgIlRleHQiOiAiPHNybWw-PGgxPk9wZW4g 596 cG9kIGJheSBkb29yczwvaDE-PC9zcm1sPiIsCiAgICAiRnJvbUlEIjogImFsaWNl 597 QGV4YW1wbGUubmV0IiwKICAgICJUb0lEIjogImJvYkBleGFtcGxlLmNvbSJ9fQ" 598 , 599 "signatures": [{ 600 "header": { 601 "kid": "MDQY6-SNGTN-KUOHT-ULDZW-RGD5G-ZFMMD"}, 602 "protected": " 603 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCmpHWmlYMU5EeGxLMmtfUm1H 604 dUV4NEtWSTMybkxMUmZYVnJZbXVUMDQwR1VIa3p6dEVtWG43eW1pQXh3dVl0cEUK 605 ZXBpUGNNNEhWMFRZbTM4TlFRdjlodyJ9" 606 , 607 "signature": " 608 VMc4Q6Ulp_BaInclyf-7rvhWISAU-MfXbvxTkfjr8vgw1iAZ5NnTPoPI85LbUChr 609 Eu1SR9bbkyLiIdrRcxV7ZWRH6fncpRRTiVEosI4qbxBDtFYxyjrDZlpFtfMOIkLx 610 RPU7fh93DSTO3NjlMs7G0C5ki_6mIDjxzylkKfBzKhV1OnqCmTp5KWVLGlW91DnH 611 -ci7GuE6qN2rQdDfCThiAmumGJdxtSuXbYSq1cR3WZF2uPmRMp2T0QuS3hikyDiu 612 -8yFGoV1keiyKPJWnrscXOVGMJmxNPSFLZkcYlR9TK-rmMNr6NnXvZ8nJsZmSxb7 613 5ztWbnM67mYfqQ0FdA3wDg" 614 }]}, 615 "ResponderAccount": "bob@example.com", 616 "Expire": "2017-08-17T01:15:59Z"}]}} 618 Figure 7 620 5.5. Post a response 622 The responder posts their response using the RespondRequest message. 623 This contains a ResponseEntry object which contains the response 624 status and the signed response. 626 The payload of the signed response is a TBSResponse message which 627 contains the signed request and the response value. Currently only 628 Accept/Reject confirmations are supported and the response value is 629 returnes as a boolean. 631 The TBSResponse object is: 633 $$$$$ TBS extract 635 The request message is: 637 { 638 "RespondRequest": { 639 "Response": { 640 "BrokerID": "MBMQF-2G2XH-RCEXI-YISIK-GYGB6-A2JU3-A", 641 "RequestStatus": "Reply", 642 "Response": { 643 "unprotected": { 644 "dig": "S512"}, 645 "payload": " 646 ewogICJUQlNSZXNwb25zZSI6IHsKICAgICJTaWduZWRSZXF1ZXN0IjogewogICAg 647 ICAidW5wcm90ZWN0ZWQiOiB7CiAgICAgICAgImRpZyI6ICJTNTEyIn0sCiAgICAg 648 ... 649 ZnFRMEZkQTN3RGcifV19LAogICAgIlZhbHVlIjogdHJ1ZX19" 650 , 651 "signatures": [{ 652 "header": { 653 "kid": "MD725-EFAK3-VICWN-62ZWA-53F23-UIZED"}, 654 "protected": " 655 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCkhBS1dpNzFYZy13ZHpaYkxS 656 TVlHb00xSHNDS3lFdl9hX3JyTzFCVjNyeUtBaUoxd1VhNmFVei1zWjRpajJiWnoK 657 NUNuclFQcmlyam1idDBRRThtd093USJ9" 658 , 659 "signature": " 660 LlVM3kprGKbZSIFcrCu55zNIibpzot3M0akJlJurbJE1qHrHHveKT6kb1v95VMUC 661 BaeIPaeHCDCeqTml4eqmm2tk9GyAfCzGpFpFD2L2gGPzAWaU0Xww3HBdoUxq04lx 662 z5A9--KT-fb96eAiNI2ha6GhNT6xacY4mpDp9X2dKrjBqBntg_psRO6kVDmt5A8w 663 Zi9SS_tRsp7dRgTXXj2AOCuJKPgu9B1kthQFfbvxYxY-xSNNmmFimn86xB8lwcxg 664 y9qsXX-sOG_o9FslGBcRf1aUi2Uq7D-0-nvYcRt-LWb4wFzjCLhSuxhZ3tGsHkd9 665 a_hmWtuifMu8Fs-NpNHo3w" 666 }]}}}} 668 Figure 8 670 The response value contains only the status code and description 671 showing the success or failure of the request. 673 { 674 "RespondResponse": { 675 "Status": 201, 676 "StatusDescription": "Operation completed successfully"}} 678 Figure 9 680 6. Mesh/Confirm Service 682 The Mesh/Confirm confirmation service is a two party protocol. An 683 Enquirer requests a response from the 685 _Confirm._tcp 687 /.well-known/confirm 689 Every Confirm Service transaction consists of exactly one request 690 followed by exactly one response. 692 There is no set sequence in which operations are required to be 693 performed. It is not necessary to perform a Hello transaction prior 694 to a CreateGroup, AddMember or any other transaction. 696 6.1. Request Messages 698 6.1.1. Message: ConfirmRequest 700 Base class for all request messages. 702 [None] 704 6.2. Response Messages 706 6.2.1. Message: ConfirmResponse 708 Base class for all response messages. Contains only the status code 709 and status description fields. 711 A service MAY return either the response message specified for that 712 transaction or any parent of that message. Thus the RecryptResponse 713 message MAY be returned in response to any request. 715 [None] 717 6.3. Imported Objects 719 The Recrypt Administration Sercice makes use of JSON objects defined 720 in the JOSE Signatgure and Encryption specifications. 722 6.4. Common classes 724 The following classes are referenced at multiple points in the 725 protocol. 727 6.4.1. Structure: AccountEntry 729 Represents the collection of data associated with an account. This 730 structure is not used in the protocol itself and does not appear in 731 the on-the-wire format. It is included here so that it can be used 732 as a reference point for describing the semantics of the protocol 733 transaction. It is possible that this record format may prove of use 734 in specifying archive and interchange protocols. 736 String (Optional) 738 The Responder account the request is directed to. 740 String [0..Many] 742 List of BrokerIDs of pending requests 744 String [0..Many] 746 List of BrokerIDs of responses 748 String [0..Many] 750 List of expired requests, now archived. 752 6.4.2. Structure: EntryBase 754 String (Optional) 756 A unique identifier for the transaction generated by the enquirer. 757 This identifier MAY be used to reject duplicate transactions by a 758 broker or Requestor. 760 String (Optional) 762 The unique identifier for the transaction generated by the broker and 763 returned in the corresponding Enquire transaction. 765 6.4.3. Structure: RequestEntry 767 o Inherits: EntryBase 769 Describes a pending request and associated information. 771 JoseWebSignature (Optional) 773 Signed and optionally encrypted request message. 775 String (Optional) 777 The Responder account the request is directed to. 779 DateTime (Optional) 781 Date and time after which the Enquirer has no interest in the request 782 value. Note that a Broker MAY cancel requests according to its own 783 policy at any time. 785 6.4.4. Structure: ResponseEntry 787 o Inherits: EntryBase 789 Describes response to a pending request 791 String (Optional) 793 The status value. Valid values are PENDING, BCANCEL, ECANCEL, REPLY, 794 REFUSED, EXPIRED 796 JoseWebSignature (Optional) 798 Signed and optionally encrypted response message. 800 6.4.5. Structure: TBSRequest 802 String (Optional) 804 Text of the request 806 String (Optional) 808 String (Optional) 810 6.4.6. Structure: TBSResponse 812 JoseWebSignature (Optional) 814 Boolean (Optional) 816 6.5. Utility Transactions 818 6.6. Transaction: Hello 820 Request: HelloRequest 822 Response: HelloResponse 824 Report service and version information. 826 The Hello transaction provides a means of determining which protocol 827 versions, message encodings and transport protocols are supported by 828 the service. 830 6.7. Enquirer Transactions 832 6.8. Transaction: Enquire 834 Request: EnquireRequest 836 Response: EnquireResponse 838 Post a confirmation request to the broker. 840 6.8.1. Message: EnquireRequest 842 o Inherits: ConfirmRequest 844 RequestEntry (Optional) 846 The request 848 6.8.2. Message: EnquireResponse 850 o Inherits: ConfirmResponse 852 Reports the success or failure of an Enquire transaction. 854 String (Optional) 856 A unique identifier for the transaction generated by the broker. 858 6.9. Transaction: Status 860 Request: StatusRequest 862 Response: StatusResponse 864 Request status on a previously posted request 866 6.9.1. Message: StatusRequest 868 o Inherits: ConfirmRequest 870 Reports the status or of an Enquire transaction. 872 Boolean (Optional) 874 If true, the broker is abandoning the request and it should no longer 875 be returned to the user as an active pending request. This flag 876 would typically be set true on the last polling attempt made before 877 the Enquirer abandonds the request. It is therefore entirely valid 878 for a broker to return a Response value if the Cancel flag is true. 880 String (Optional) 882 The unique identifier for the transaction generated by the broker and 883 returned in the corresponding Enquire transaction. 885 6.9.2. Message: StatusResponse 887 o Inherits: ConfirmResponse 889 The result of a status request. 891 ResponseEntry (Optional) 893 6.10. Responder Transactions 895 6.11. Transaction: Pending 897 Request: PendingRequest 899 Response: PendingResponse 901 Request a list of pending transactions meeting the specified 902 selection criteria. 904 6.11.1. Message: PendingRequest 906 o Inherits: ConfirmRequest 908 Request a list of pending requests for a specified account. 910 String (Optional) 912 The Responder account the the list of pending requests is requested 913 for. 915 String (Optional) 917 The BrokerID of the pending request to return. 919 Integer (Optional) 921 The maximum number of request entries to return. 923 Integer (Optional) 925 Only send request entries posted prior to the specified entry. 927 Integer (Optional) 929 Only send request entries posted after the specified entry. 931 6.11.2. Message: PendingResponse 933 o Inherits: ConfirmResponse 935 Contains a list of pending requests. 937 RequestEntry [0..Many] 939 List of pending requests. 941 6.12. Transaction: Respond 943 Request: RespondRequest 945 Response: RespondResponse 947 Respond to a confirmation request. 949 6.12.1. Message: RespondRequest 951 o Inherits: ConfirmRequest 953 Respond to a confirmation request. 955 ResponseEntry (Optional) 957 Signed and optionally encrypted response message. 959 6.12.2. Message: RespondResponse 961 o Inherits: ConfirmResponse 963 Reports the success or failure of a Respond transaction. 965 [None] 967 7. Simple Request Markup Language (SRMLv1) 969 Confirmation requests are posted in SRML, a deliberately limited 970 subset of HTML. SRML is limited to four elements and one attribute. 971 These are: 973 The top-level element for an SRML request 975 Heading 977 Paragraph 979 Button specifying a value that the user can select. 981 While SRML is loosely based on the HTML forms markup, there are 982 important differences. The HTML markup model supports multiple 983 document types of which forms are only one and a single document may 984 contain multiple forms with multiple different action values. In an 985 SRML document is a single form and the form action to be performed is 986 impicit in the presentation of the document to the user. 988 7.1. XML Schema and Content Type Identifier 990 The MIME Content Type and schema identifier for SRML are 992 text/xml 994 http://hallambaker.com/Schemas/srml.xsd 996 include=Schemas\srml.md 998 7.2. Design considerations and future options 1000 The capabilities of SRML are intentionally limited to the bare 1001 minimum. It should be possible to make use of SRML to display 1002 options to the user on a smartwatch or other device with a highly 1003 constrained display. 1005 The function of the confirmation service is to provide confirmation 1006 of an action that was initiated elsewhere. It is therefore 1007 inappropriate for this or any future version of SRML to offer 1008 extensive data entry or validation capabilities. SRML applications 1009 MUST NOT support any form of scripting or active code extensions to 1010 SRML content. 1012 It might prove advantageous in the future to extend the input types 1013 to include simple form elements such as checkboxes, numeric fields, 1014 text choices and possibly free form text. 1016 8. Request Authentication and Authorization 1018 The current version of the protocol does not address the question of 1019 how service requests are to be authorized or authenticated. 1021 A triple lock security approach is anticipated in which cryptographic 1022 enhancements are applied at three separate levels to provide 1023 different security controls: 1025 Basic confidentiality and integrity controls are provided using 1026 TLS with a server-side certificate. It is necessary to provide 1027 encryption at this layer to protect confidentiality of meta-data. 1029 Mutual authentication of the client and service is provided at the 1030 presentation layer. In the default JWB binding, this is provided 1031 within the HTTP content payload. The use of encryption at the 1032 presentation is optional. 1034 Confirmation requests and responses are signed by the Enquirer and 1035 Responder respectively. This provides for non-repudiation of 1036 messages. 1038 8.1. Service Authentication 1040 Since the responder is identified by the responder?s account, Minimal 1041 Validation is sufficient but Domain Validation is preferred. These 1042 credentials MAY be bound using a strong DNS name. 1044 8.2. Responder Authentication 1046 The responder is authenticated by means of the user?s Mesh profile. 1048 The ability to delegate access to a confirmation account might be 1049 useful in certain circumstances. 1051 8.3. Enquirer Authentication 1053 Authentication of the Enquirer presents very different challenges to 1054 authentication of the Service or the Responder as it is the only part 1055 of the service that is ?open?. It is thus likely to be the target of 1056 abuse (i.e. spam). It is therefore important that the authentication 1057 mechanism enable appropriate authorization and accountability 1058 strategies. 1060 For example, one strategy to control abuse might be to permit 1061 enquirers to post requests if they were signed with a key 1062 authenticated by an Extended Validation certificate or were sent by 1063 an enquirer approved by the responder to whom the request was 1064 directed. In the first case, abuse is mitigated by an accountability 1065 control, in the second by explicit authorization of the sender. 1067 While it is possible to implement such a strategy in the responder 1068 application, this approach is clearly limiting. Filtering of 1069 messages in the service avoids the need to synchronize policy across 1070 the user?s confirmation devices and protects possibly limited 1071 wireless bandwidth by performing policy enforcement in the service 1072 rather than the responder?s device. 1074 Mesh/Confirm does not provide a mechanism for specifying such a 1075 security policy. Leaving this requirement to a separate service 1076 allows for a protocol that can specify policy for multiple modes of 1077 communication. For instance, a customer of a bank might permit the 1078 bank to send confirmation messages and to deliver statements by email 1079 but not to make contact by voice or video calls. 1081 9. Implementation Status 1083 This section records the status of known implementations of the 1084 protocol defined by this specification at the time of posting of this 1085 Internet-Draft, and is based on a proposal described in [RFC6982] 1086 [RFC6982] . The description of implementations in this section is 1087 intended to assist the IETF in its decision processes in progressing 1088 drafts to RFCs. Please note that the listing of any individual 1089 implementation here does not imply endorsement by the IETF. 1090 Furthermore, no effort has been spent to verify the information 1091 presented here that was supplied by IETF contributors. This is not 1092 intended as, and must not be construed to be, a catalog of available 1093 implementations or their features. Readers are advised to note that 1094 other implementations may exist. 1096 According to [RFC6982] [RFC6982] , "this will allow reviewers and 1097 working groups to assign due consideration to documents that have the 1098 benefit of running code, which may serve as evidence of valuable 1099 experimentation and feedback that have made the implemented protocols 1100 more mature. It is up to the individual working groups to use this 1101 information as they see fit". 1103 9.1. Reference Implementation 1105 Organization: Comodo Group Inc. 1107 Implementer: Phillip Hallam-Baker 1109 Maturity: Experimental Prototype 1111 This implementation was used to produce the reference section and all 1112 the examples in this document. Since the conversion of specification 1113 to code is automatic, there is a high degree of assurance that the 1114 reference implementation is consistent with this document. 1116 9.1.1. Coverage: 1118 The draft-xx branch describes the code used to create version xx of 1119 this document. 1121 The main current limitations are that the code only supports RSA key 1122 pairs and for ease of development the server does not persist keys 1123 across sessions. Nor does the implementation currently support the 1124 HTTP payload authentication and encryption layer or make use of TLS. 1125 These could be easily fixed. 1127 The client and server are implemented as libraries that may be called 1128 from a multi-protocol server. A standalone server will be provided 1129 in a future release. 1131 Only the JSON encoding is currently implemented. The JSON-B, JSON-C, 1132 ASN.1 and TLS Schema implementations are all supported by the code 1133 generation tool but not currently implemented as the build tool 1134 bindings for those encodings have not yet been finalized or 1135 documented. 1137 The key restrictions for TLS key exchange have not yet been 1138 implemented. 1140 The code has only been tested on Windows 10 but passed compatibility 1141 testing for both Mono and dotNetCore 10 run times which should in 1142 theory permit use on Linux and OSX platforms. 1144 9.1.2. Licensing 1146 The code is released under an MIT License 1148 Source code is available from GitHub at 1149 https://github.com/hallambaker/Mathematical-Mesh 1151 9.1.3. Implementation Experience 1153 The implementation and specification documentation were developed in 1154 Visual Studio using the PHB Build Tools suite. 1156 9.1.4. Contact Info 1158 Contact Phillip Hallam-Baker phill@hallambaker.com 1160 10. Security Considerations 1162 Consider spam control, how do users prevent unwanted requests? (EV 1163 accreditation, filtering at Broker) 1165 People deploying Mesh/Confirm as a means of controlling access to 1166 networking infrastructure must consider the bootstrap issue. In 1167 particular since Mesh/Confirm requires Internet access the network 1168 administrator must ensure that it is possible to manage the network 1169 resources necessary to support an SXS service when that service is 1170 down. 1172 11. Acknowledgements 1174 12. References 1176 12.1. Normative References 1178 [draft-hallambaker-mesh-architecture] 1179 Hallam-Baker, P., "Mathematical Mesh: Architecture", 1180 draft-hallambaker-mesh-architecture-03 (work in progress), 1181 May 2017. 1183 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1184 Requirement Levels", BCP 14, RFC 2119, 1185 DOI 10.17487/RFC2119, March 1997. 1187 12.2. Informative References 1189 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1190 Code: The Implementation Status Section", RFC 6982, 1191 DOI 10.17487/RFC6982, July 2013. 1193 Author's Address 1195 Phillip Hallam-BakerPhillip Hallam-Baker 1196 Comodo Group Inc. 1198 Email: philliph@comodo.com