Network Working Group P. Hallam-Baker
Internet-Draft Comodo Group Inc.
Intended status: Informational May 10, 2017
Expires: November 11, 2017

Mesh Confirmation Protocol (Mesh/Confirm)
draft-hallambaker-mesh-confirm-00

Abstract

Mesh Confirmation Protocol (Mesh/Confirm) is a three-party Web Service that supports a transactional second factor confirmation mechanism that provides a superset of the capabilities of traditional second factor authentication schemes. The three parties in the protocol are Enquirer who posts a confirmation request, a Responder who may or may not respond to the request and the Broker where the requests and responses are posted.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on November 11, 2017.

Copyright Notice

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.


Table of Contents

1. Background

Authentication of end users is one of the biggest challenges for Internet and Web security today. Despite an abundance of technology that offers authentication mechanisms that are more robust, more secure and easier to use, the default mechanism for user authentication is the use of usernames and passwords.

Unlike traditional schemes, Mesh/Confirm is designed for implementation on a device that has at least the capabilities of a modern 'smartphone'. In particular, a Mesh/Confirm client device must support a display, a means of accepting text input from the user and a connection to the Internet.

While mobile devices offering this degree of functionality were rare in 2007, they have since become ubiquitous. It is thus now a practical proposition for a site requiring second factor authentication to support at least a part of its users using a technology that requires this level of capability. Software applications that emulate traditional second factor authentication protocols on such devices have been available for some time.

1.1. Second Factor Authentication

Second factor authentication mechanisms offer greater security over the use of passwords alone by combining a first factor (typically a password) with a second factor, typically a biometric or proof of possession of a physical token.

Traditional second factor authentication techniques have suffered from the need to distribute physical tokens and the difficulty of ensuring that a biometric authentication is presented to a trustworthy terminal.

The usability of traditional second factor authentication techniques has been poor or worse. Even the simplest scheme in which the user is required to read in a 'one time use' numeric code from the authentication token device and enter it into a password field. While such operations are relatively simple they require the user to engage in a sequence of operations that bears no necessary or natural relationship to the underlying task for which the authentication is required.

Nor does the act of engaging in a traditional second factor scheme offer proof of anything other than that the user was authenticated. Any correspondence between the act of authentication and the purpose for which the authentication was provided must be maintained separately.

1.2. Confirmation vs. Authentication

A second factor confirmation service addresses the limitations of traditional second factor authentication schemes.

A confirmation service allows the user experience to be precisely matched to the action that the user is attempted. This is simpler and more secure. Instead of being asked to read a random number from one device and enter it into another, the user is asked if they really want to perform the action for which authentication is requested.

A confirmation service offers better accountability for end users than a traditional authentication service. An authentication service only provides an assertion that the user was present. A confirmation service provides an assertion that the user was present and that they confirmed a specific transaction.

For example, Alice has been granted access to a machine storing classified data. If an authentication service is used for access control, the authentication service log will only record the dates and times that Alice accessed the system. to find out if Alice accessed a particular file on a particular day it is necessary to consult and correlate both the authentication log of the system and the activity log for the application.

If instead a confirmation service is used the confirmation log contains an authenticated record of both the authentication events and the transactions for which the authentication was requested.

1.3. Use Scenarios

A confirmation service complements rather than replaces a traditional authentication scheme. Providing a highly secure and convenient means of authenticating requests that carry a high degree of risk mitigates the risk of using convenient but intrinsically low security techniques for other actions.

1.4. Use in Financial Services

If an attacker is to profit from breaching an account with a financial service such as a bank or a brokerage they must find a way to move money out of the account. Thus, adding bill payment recipients, initiating wire transfers and trading in low volume 'penny stocks' represent high risk activities.

For example: Bank of Ethel might permit customers to use a simple username and password scheme to gain access to their account for the purpose of checking their balance or paying bills to existing recipients but require use of the second factor confirmation device for a high-risk transaction such as paying a bill.

1.5. Machine Binding

A second factor confirmation service may be combined with a machine level authentication scheme to permit a transparent form of authentication for low risk transactions.

For example: Alice stores her low risk authentication credentials (e.g. usernames and passwords) using a 'cloud' service. When she wishes to use those credentials an agent on her personal machine fetches credentials from the cloud service as necessary. When Alice wishes to access a site from a different machine she receives a confirmation request on her mobile device to grant access from that machine.

Use of such a mechanism is clearly more satisfactory when suitable cryptographic protocols such as SAML or Kerberos are employed to limit the disclosure and hence possible compromise of the credentials. The specification of such protocols is outside the scope of this document.

1.6. Tethered Use

Although Mesh/Confirm is designed for use in a three-party scenario, there are situations in which a two party mode may be preferred.

For example: Bob is a roadwarrior who requires access to confidential documents stored on his laptop device from anywhere in the world, including locations where Internet access is not possible. To permit access in such circumstances, Bob's Mesh/Confirm client supports use of a tethered mode in which the mobile device is plugged into his laptop via a USB port.

For example: Carol is a network manager of a large computing facility that uses Mesh/Confirm to authenticate and track all changes to critical resources. Since Mesh/Confirm is itself a network resource a bootstrap consideration arises: How can Carol confirm her network configuration requests using Mesh/Confirm when the network itself is down? Support for a tethered mode in which the Mesh/Confirm device communicates via USB or similar wired protocol allows this use case to be supported.

While availability of a tethered mode is clearly essential if Mesh/Confirm is to be used in certain applications, support for this feature outside the scope of this version of the specification.

1.7. Co-Browser

While Mesh/Confirm is designed for deployment on a secondary device, deployment on the same device as the one for which confirmation is being requested is also possible and can provide security benefits.

Modern Web browsers are large and complex with many features such as support for mobile code that are incompatible with a high security environment. Separating the confirmation protocol from the Web Browsing protocol permits implementation in a minimal client designed to permit detailed security analysis. Such a client might be embedded in or support means of secure interaction with a trustworthy operating system component.

While this means of deployment does not provide a true second factor confirmation, it is likely to provide a sufficient degree of authentication for many transactions.

2. Architecture

Mesh/Confirm is a Web Service that permits a Enquirer to request that a User confirm or reject a specified action. If the user responds, the response is signed with a digital signature under a key that is unique to the user account, the client and the device.

2.1. Parties

Each Mesh/Confirm protocol interaction takes place between a connection pair of the following parties:

Enquirer

A party that initiates a confirmation request.

User

The User is the person being asked to grant or refuse confirmation. A User MAY have multiple accounts with multiple Broker Services.

User Device

A device that the user has bound to their broker account.

Broker

A clearing house that stores and forwards requests from Initiators to Users Device and responses from Users to Initiators. The Broker is only trusted to perform routing filtering and recording of requests and responses. The Broker is not trusted with respect to the responses returned.

The communication between the parties is shown in Figure 1.

+-------------+         +------------+         +-------------+
|  Enquirer   | <-----> |   Broker   | <------ |   Device    |
+-------------+         +------------+         +-------------+
                                                      ^
                                                      |
                                                      V
                                               +-------------+
                                               |     User    |
                                               +-------------+

Figure 1. Mesh/Confirm Parties

2.2. Accounts

Users are identified by means of an account identifier. The display presentation of an account identifier is the form of an RFC2822 email address identifier without the enclosing angle braces, for example:

alice@example.com

The account identifier is used by the User when registering the use of the confirmation service with a Broker.

2.3. Open and Closed Services

An Mesh/Confirm service MAY be Open or Closed. An Open service provider provides Mesh/Confirm service to the general public. A Closed service provider only provides service to a specific community.

For example: An Internet Service Provider or DNS Registrar might provide an open Mesh/Confirm service as a part of their standard service offering to customers. An employer might operate a closed Mesh/Confirm service to be used for company business.

2.4. Check service connection

It is often useful to be able to verify that a service is ready and willing to perform transactions before attempting to perform one. Especially so when the transaction requires considerable amounts of data and may require the use of specific server determined authentication options.

The request message is 'HelloRequest' and has no parameters:

POST /.well-known/confirm/HTTP/1.1
Host: prismproof.org
Content-Length: 23

{
  "HelloRequest": {}}

The response message specifies the protocol version(s) supported, the corresponding encodings and bindings:

HTTP/1.1 200 OK
Date: Thu 11 May 2017 03:12:20
Content-Length: 157

{
  "HelloResponse": {
    "Status": 201,
    "StatusDescription": "Operation completed successfully",
    "Version": {
      "Major": 0,
      "Minor": 1}}}

2.5. Enquirer posts request.

Alice attempts to log into her computer system as administrator. The site policy requires that all administrative logins be confirmed via Mesh/Confirm. Alice's confirmation account is alice@example.com. In this exchange, the computer Alice is trying to access is the Enquirer, the device she uses to respond to the query (her watch) is the Responder and the Mesh/Confirm service at example.com is the broker.

The computer acting as Enquirer (example.net) creates a confirmation request as follows:

<?xml version="1.0" encoding="utf-8" ?>
<srml xmlns="http://hallambaker.com/Schemas/srml.xsd">
  <h1>Grant Administrator</h1>
  <p>Host: example.net</p>
  <button value="Access">Access</button>
</srml>

Note that it is not necessary to specify the reject option since this is implicit.

The request message is 'EnquireRequest' which contains an object signed by the Enquirer that specifies the account the request is directed to and the request text.

POST /.well-known/confirm/HTTP/1.1
Host: prismproof.org
Content-Length: 25

{
  "EnquireRequest": {}}

The request is accepted and a success response returned specifying the transaction ID.

HTTP/1.1 200 OK
Date: Thu 11 May 2017 03:12:20
Content-Length: 105

{
  "EnquireResponse": {
    "Status": 201,
    "StatusDescription": "Operation completed successfully"}}

Note that while the requirement that request messages be authenticated by means of a digital signature is within the scope of Mesh/Recrypt, the specification of the filtering rules is not.

2.6. Responder fetches pending requests.

At present, the only mechanism for determining if there are pending requests is by polling. Provision of a push notification mechanism is an obvious priority for future improvement of the protocol.

Alice's watch regularly polls the broker to determine if there are pending confirmation requests.

POST /.well-known/confirm/HTTP/1.1
Host: prismproof.org
Content-Length: 25

{
  "PendingRequest": {}}

The response message contains the number of pending requests meeting the selection criteria and the returned requests.

HTTP/1.1 200 OK
Date: Thu 11 May 2017 03:12:20
Content-Length: 105

{
  "PendingResponse": {
    "Status": 201,
    "StatusDescription": "Operation completed successfully"}}

Each request is signed by the Enquirer that originally generated it.

2.7. Responder replies to request.

Alice selects the pending access request and grants herself access to the machine she is attempting to log in to. Her watch creates a signed response message containing the digest of the original request and her response "Accept".

POST /.well-known/confirm/HTTP/1.1
Host: prismproof.org
Content-Length: 25

{
  "RespondRequest": {}}

The response message tells Alice that the transaction completed successfully and the broker has her acceptance message.

HTTP/1.1 200 OK
Date: Thu 11 May 2017 03:12:20
Content-Length: 105

{
  "RespondResponse": {
    "Status": 201,
    "StatusDescription": "Operation completed successfully"}}

Note that in future versions of the protocol it may be desirable to make use of additional affordances of the device such as the ability to perform biometric capture such as fingerprint or facial recognition.

Another possibility is that the user might be asked to enter a one time use PIN generated by the Enquirer, thus verifying that the user is indeed responding to the confirmation request they believe they are responding to.

2.8. Enquirer fetches result

The enquirer obtains the result of the confirmation request by polling using the Status transaction.

POST /.well-known/confirm/HTTP/1.1
Host: prismproof.org
Content-Length: 24

{
  "StatusRequest": {}}

Since Alice has responded, the response message contains the signed result:

HTTP/1.1 200 OK
Date: Thu 11 May 2017 03:12:20
Content-Length: 104

{
  "StatusResponse": {
    "Status": 201,
    "StatusDescription": "Operation completed successfully"}}

As with the use of polling on the user side, it is obviously desirable to eliminate the need for polling by introducing a callback registration mechanism.

3. Mesh/Confirm Service

The Mesh/Confirm confirmation service is a two party protocol. An Enquirer requests a response from the

SRV Prefix:

_Confirm._tcp

HTTP Well Known Service Prefix:

/.well-known/confirm

Every Confirm Service transaction consists of exactly one request followed by exactly one response.

There is no set sequence in which operations are required to be performed. It is not necessary to perform a Hello transaction prior to a CreateGroup, AddMember or any other transaction.

3.1. Request Messages

3.1.1. Message: ConfirmRequest

Base class for all request messages.

Portal: String (Optional)

Name of the Mesh/Recrypt administration Service to which the request is directed.

3.2. Response Messages

3.2.1. Message: ConfirmResponse

Base class for all response messages. Contains only the status code and status description fields.

A service MAY return either the response message specified for that transaction or any parent of that message. Thus the RecryptResponse message MAY be returned in response to any request.

Status: Integer (Optional)

Status return code. The SMTP/HTTP scheme of 2xx = Success, 3xx = incomplete, 4xx = failure is followed.

StatusDescription: String (Optional)

Text description of the status return code for debugging and log file use.

3.2.2. Successful Response Codes

The following response codes are returned when a transaction has completed successfully.

[201] SuccessOK

Operation completed successfully

[201] SuccessCreated

Operation completed successfully, new data item created

[202] SuccessUpdated

Operation completed successfully, data item was updated

3.2.3. Warning Response Codes

The following response codes are returned when a transaction did not complete because the target service has been redirected.

In the case that a redirect code is returned, the StatusDescription field contains the URI of the new service. Note however that the redirect location indicated in a status response might be incorrect or even malicious and cannot be considered trustworthy without appropriate authentication.

[303] RedirectPermanent

Service has been permanently moved

[307] RedirectTemporary

Service has been temporarily moved

3.2.4. Error Response Codes

A response code in the range 400-499 is returned when the service was able to process the transaction but the transaction resulted in an error.

[401] ClientUnauthorized

Client is not authorized to perform specified request

[404] NotFound

The requested object could not be found.

[409] AlreadyExists

The requested object already exists.

3.2.5. Failure Response Codes

A response code in the range 500-599 is returned when the service was unable to process the transaction but the transaction due to an internal failure.

[500] ServerInternal

An internal error occurred at the server

[503] ServerOverload

The server cannot handle the request as it is overloaded

3.3. Imported Objects

The Recrypt Administration Sercice makes use of JSON objects defined in the JOSE Signatgure and Encryption specifications.

3.4. Common classes

The following classes are referenced at multiple points in the protocol.

3.4.1. Structure: Version

Describes a protocol version.

Major: Integer (Optional)

Major version number of the service protocol. A higher

Minor: Integer (Optional)

Minor version number of the service protocol.

Encodings: Encoding [0..Many]

Enumerates alternative encodings (e.g. ASN.1, XML, JSON-B) supported by the service. If no encodings are specified, the JSON encoding is assumed.

URI: String [0..Many]

The preferred URI for this service. This MAY be used to effect a redirect in the case that a service moves.

3.4.2. Structure: Encoding

Describes a message content encoding.

ID: String [0..Many]

The IANA encoding name

Dictionary: String [0..Many]

For encodings that employ a named dictionary for tag or data compression, the name of the dictionary as defined by that encoding scheme.

3.5. Utility Transactions

3.6. Transaction: Hello

Request: HelloRequest

Response:HelloResponse

Report service and version information.

The Hello transaction provides a means of determining which protocol versions, message encodings and transport protocols are supported by the service.

3.6.1. Message: HelloRequest

Request service description.

[None]

3.6.2. Message: HelloResponse

Always reports success. Describes the configuration of the service.

Version: Version (Optional)

Enumerates the protocol versions supported

Alternates: Version [0..Many]

Enumerates alternate protocol version(s) supported

3.7. Enquirer Transactions

3.8. Transaction: Enquire

Request: EnquireRequest

Response:EnquireResponse

Post a confirmation request to the broker.

3.8.1. Message: EnquireRequest

Request: JoseWebEncryption (Optional)

Signed and optionally encrypted request message.

Responder: String (Optional)

The Responder account the request is directed to.

Expire: DateTime (Optional)

Date and time after which the Enquirer has no interest in the request value. Note that a Broker MAY cancel requests according to its own policy at any time.

EnquirerID: String (Optional)

A unique identifier for the transaction generated by the enquirer. This identifier MAY be used to reject duplicate transactions by a broker or Requestor.

3.8.2. Message: EnquireResponse

Reports the success or failure of an Enquire transaction.

BrokerID: String (Optional)

A unique identifier for the transaction generated by the broker.

3.9. Transaction: Status

Request: StatusRequest

Response:StatusResponse

Request status on a previously posted request

3.9.1. Message: StatusRequest

Reports the status or of an Enquire transaction.

Cancel: Boolean (Optional)

If true, the broker is abandoning the request and it should no longer be returned to the user as an active pending request. This flag would typically be set true on the last polling attempt made before the Enquirer abandonds the request. It is therefore entirely valid for a broker to return a Response value if the Cancel flag is true.

BrokerID: String (Optional)

The unique identifier for the transaction generated by the broker and returned in the corresponding Enquire transaction.

3.9.2. Message: StatusResponse

The result of a status request.

RequestStatus: String (Optional)

The status value. Valid values are PENDING, BCANCEL, ECANCEL, REPLY, REFUSED

Response: JoseWebEncryption (Optional)

Signed and optionally encrypted response message.

3.10. Responder Transactions

3.11. Transaction: Pending

Request: PendingRequest

Response:PendingResponse

Request a list of pending transactions meeting the specified selection criteria.

3.11.1. Message: PendingRequest

Request a list of pending requests for a specified account.

Responder: String (Optional)

The Responder account the the list of pending requests is requested for.

MaxResponse: Integer (Optional)

The maximum number of request entries to return.

BeforeId: String (Optional)

Only send request entries posted prior to the specified entry.

AfterId: String (Optional)

Only send request entries posted after the specified entry.

3.11.2. Message: PendingResponse

Contains a list of pending requests.

Entries: RequestEntry (Optional)

List of pending requests.

3.11.3. Structure: RequestEntry

Describes a pending request and associated information.

Request: JoseWebEncryption (Optional)

Signed and optionally encrypted request message.

Responder: String (Optional)

The Responder account the request is directed to.

Expire: DateTime (Optional)

Date and time after which the Enquirer has no interest in the request value. Note that a Broker MAY cancel requests according to its own policy at any time.

EnquirerID: String (Optional)

A unique identifier for the transaction generated by the enquirer. This identifier MAY be used to reject duplicate transactions by a broker or Requestor.

BrokerID: String (Optional)

The unique identifier for the transaction generated by the broker and returned in the corresponding Enquire transaction.

3.12. Transaction: Respond

Request: RespondRequest

Response:RespondResponse

Respond to a confirmation request.

3.12.1. Message: RespondRequest

Respond to a confirmation request.

Response: JoseWebEncryption (Optional)

Signed and optionally encrypted response message.

3.12.2. Message: RespondResponse

Reports the success or failure of a Respond transaction.

[None]

4. Simple Request Markup Language (SRMLv1)

Confirmation requests are posted in SRML, a deliberately limited subset of HTML. SRML is limited to four elements and one attribute. These are:

The top-level element for an SRML request

5. Heading Text</h1>

Heading

Running text

Paragraph

User option

Button specifying a value that the user can select.

While SRML is loosely based on the HTML forms markup, there are important differences. The HTML markup model supports multiple document types of which forms are only one and a single document may contain multiple forms with multiple different action values. In an SRML document is a single form and the form action to be performed is impicit in the presentation of the document to the user.

5.1. XML Schema and Content Type Identifier

The MIME Content Type and schema identifier for SRML are

Content-Type

text/xml

xmlns

http://hallambaker.com/Schemas/srml.xsd

The schema is

<?xml version="1.0" encoding="utf-8"?>
<xs:schema id="SRML"
    targetNamespace="http://hallambaker.com/Schemas/srml.xsd"
    elementFormDefault="qualified"
    xmlns="http://hallambaker.com/Schemas/srml.xsd"
    xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="srml" type="SrmlType"/>

  <xs:complexType name="SrmlType">
    <xs:sequence>
      <xs:element name="h1" type="xs:string" 
                    minOccurs="1" maxOccurs="1"/>
      <xs:element name="p" type="xs:string" />
      <xs:element name="button" type="ButtonType" 
                    minOccurs="1" maxOccurs="unbounded"/>      
    </xs:sequence>
  </xs:complexType>

  <xs:complexType name="ButtonType">
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="value" type="xs:string" />
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType> 

</xs:schema>

5.2. Design considerations and future options

The capabilities of SRML are intentionally limited to the bare minimum. It should be possible to make use of SRML to display options to the user on a smartwatch or other device with a highly constrained display.

The function of the confirmation service is to provide confirmation of an action that was initiated elsewhere. It is therefore inappropriate for this or any future version of SRML to offer extensive data entry or validation capabilities. SRML applications MUST NOT support any form of scripting or active code extensions to SRML content.

It might prove advantageous in the future to extend the input types to include simple form elements such as checkboxes, numeric fields, text choices and possibly free form text.

6. Security Considerations

Consider spam control, how do users prevent unwanted requests? (EV accreditatio, filtering at Broker)

People deploying Mesh/Confirm as a means of controlling access to networking infrastructure must consider the bootstrap issue. In particular since Mesh/Confirm requires Internet access the network administrator must ensure that it is possible to manage the network resources necessary to support an SXS service when that service is down.

7. Acknowledgements

Author's Address

Phillip Hallam-Baker Comodo Group Inc. EMail: philliph@comodo.com