Time-Gated Mutual Authentication
System Architecture: Part 4

DRAFT (10-July-2017)

Distributed Systems Software
Victoria, BC

Part 4

The Protocol, in Brief

The following diagram provides a high-level overview of the sequence of events that occur during a successful execution of the authentication protocol:

TGMA Protocol Overview

The sign-on protocol is performed in four phases. In brief, these phases are:
  1. A user initiates TGMA sign-on at the system interface

    1. The user asserts his username in any supported way, such as by typing it, selecting it from a menu or set of icons, or scanning a badge. The user has previously created the username (an account) for the system interface and it has been enabled for TGMA sign-on (see Account Creation and Management). Selecting the username starts a timer or "opens a gate". Sign-on must be completed during a server-configured time period during which the gate is open (the validation interval), which will typically be on the order of 10 or 20 seconds. The user is never asked to provide a password through the system interface.
    2. A short passcode is displayed by the system interface (described below).[1]
    3. The system interface waits, up to a configured maximum length of time, to receive a new connection from the user's validator.
    4. The user starts his validator. The validator software was previously installed on the user's device and configured for the user to sign-on to this account.[14]
    5. The user selects the system interface that he is signing-on to (e.g., from a menu organized by business/organization/department name, hostname, logo),[2] enters the passcode that was shown by the system interface, and waits for a response from the validator. A server never prompts for or initiates this selection. Although this might appear to be an unimportant design decision, it helps to protect against various spoofing attacks, in part by whitelisting trusted system interfaces, and prevents a malicious server from engaging the user in an authentication transaction that might benefit an attacker.

      This interaction is similar to that of a customer's with a point-of-sale credit card terminal (also called a credit card scanner, credit/debit card machine, etc.). In that context, a user is presented with some information about a purchase, asked to approve the transaction, and then enters a secret PIN to complete the transaction.[3] A signature may also be required. Web-based and phone-based transactions often require the user to supply the credit verification value (CVV) printed on the back of a credit card.

      A passcode is a short, randomly generated string that is used to:

      1. Associate a validator connection with a system interface instance (e.g., a login in progress).[4] [5]
      2. Add an element of security (an incorrect passcode causes authentication to fail, as will a passcode sent by the "wrong" validator); the passcode makes some simple attacks impractical. A system interface can set the length of its passcodes at will to extend them or make them easier for users to enter. A passcode consisting of as few as four characters from a carefully chosen alphabet yields millions of possibilities.
      3. Guarantee that either the user and validator are co-located, or the user is providing a third-party who is operating the validator with the passcode.

      The role of the passcode in TGMA is akin to Bluetooth device pairing mechanisms and the PIN method in Wi-Fi Protected Setup.

      A passcode is only valid during the validation interval of the authentication instance with which it is associated. If an authentication procedure fails and is retried, a new passcode will be produced.

  2. The system interface awaits a connection from the user's validator

    The sign-on validator:

    1. Connects to the hostname:port preconfigured for the system interface. The port number must be a reserved system port from which only a privileged system component may receive incoming network connections.[6] Therefore, only a privileged authentication component will be able to receive connections from sign-on validators. System interfaces that interact with the authentication component must likewise be privileged. System components that manage authentication normally run with protected and enhanced capabilities.

      The connection must be established within the connection interval, after which the system interface will time out.[7] The server to which the validator connects need not be the host to which the user is signing on. It could be any server delegated by the host for this purpose. A single server might perform functionality on behalf of all of the users in a domain, for instance, provided it has access to the necessary account information (including cryptographic keys and the username).

    2. Conducts a secure M-AUTH protocol with the system interface.[8] The validator displays contextual information to the user and prompts for a passcode, if necessary:
      User sam is attempting to sign on to server example.com.
      Enter passcode to proceed: ___________
      Or abort sign-on

      The validator sends the selected username and identifies the system interface that was selected by the user. A large (160-bit or larger), randomly-generated binary key shared by the validator and system interface, associated with the user's account, is used by the mutual authentication protocol.[9] When provided, the passcode is also included in the cryptographic operation performed by the validator to authenticate itself to the system interface.[10]

      If M-AUTH is successful, the user has proven his identity to the system interface and vice versa, and the user has proven knowledge of the passcode. It is important that the selected protocol be secure over public networking, such as free Wi-Fi, which is likely to be used by a mobile device. Another important characteristic of the selected M-AUTH protocol is that it be immune to a man-in-the-middle (MITM) attack, even in the presence of proxy servers and intermediate networking devices. It is desirable for the protocol to produce a shared encryption key as a byproduct, so that a symmetric encryption algorithm can be applied to messages subsequently sent over the connection.

    3. Waits for the system interface to send a description of the authentication context to the validator, which presents the information to the user. This message, and all subsequent messages sent over the connection, can be formally specified using a MIME body type.
  3. The validator sends a response to the system interface

    If the sign-on validator's reply to the server indicates that sign-on may not proceed, sign-on fails. If no sign-on approver has been configured, sign-on completes successfully, otherwise sign-on proceeds to the next step.

  4. The configured sign-on approver is called by the system interface

    A sign-on approver is invoked by the system interface, using previously configured parameters and parameters from the authentication context. The value returned by the sign-on approver is authoritative and indicates to the system interface whether sign-on is successful.[11]

An account may continue to use a password (or other form of authentication), in case TGMA is disabled or to gain access to administrative functions, such as if the user loses his device. But if a password is required at all, it will be needed infrequently, allowing a strong, unique password to be required with the expectation that the user will record it and store it in a secure place. Alternatively, a strong though less convenient authentication method such as a two-factor authentication scheme could be employed.

It is possible to extend the protocol with a cookie-like mechanism, where an authenticated server could store a token (opaque data) in the validator which would later be accessible by other (authenticated) servers during their sign-on procedures. This can be used to construct a single sign-on system (SSO) when the validator has Internet access. Suppose, for example, that Alice mutually authenticates with a.example.com. The server at a.example.com asks Alice's validator to store a token. Later, Alice wants to sign-on at b.example.com. During normal M-AUTH, after the identity of b.example.com has been established, the validator sends the stored token to b.example.com. No account information regarding Alice is needed at b.example.com, provided it is able to validate and extract information from the token. This is discussed in more detail below.

To accommodate other authentication architectures, several variants of the protocol can be used, each of which still requires a validator.

QR Code Variant

When a system interface is able to display an image to the user, the passcode can be encoded and presented as a QR code. Instead of the user having to manually copy the passcode into the validator, after selection of the system interface the validator prompts the user to scan the QR code using the secondary computer's digital camera. When emitted as an automatically-sized image (e.g., in the PNG file format), the maximum QR code capacity of between about 2,953 and 4,296 bytes can be obtained, depending on the character set being encoded. A clear advantage of a QR code over a manual method is that more information can be communicated between the system interface and the validator quickly and easily, and at a much lower error rate.

Output of a QR code to a fairly generic text-based window (e.g., xterm, Terminal.app) is possible, although the capacity can be limited by the window size and font size that has been configured for the text window.

A variety of free apps and open source licensed QR code software is available.[12]

As the rest of the protocol is unchanged, this variant adds an element of convenience and accessibility. It also makes longer and more secure passcodes practical.

Alternative means of providing a validator with a passcode are possible.[13]

Off-Line Validation Variant

When a validator and system interface cannot establish a connection, because it is undesirable or impossible, and both the system interface and the user's account allow it, an alternative is possible if the system interface is able to display an image. Rather than print a textual passcode, the system interface displays a secure QR code that encodes a passcode and authentication context. After selection of the system interface by the user, the validator:
  1. Prompts the user to use the secondary computer's digital camera to scan the QR code,
  2. Validates the encoded data against the user-selected identity and account information (thereby authenticating the system interface),
  3. Displays information about the sign-on to the user, and
  4. Asks for user confirmation.
If the user allows authentication, the validator displays a one-time password. The user enters the one-time password into the system interface (recall that in this scenario real-time communication between the validator and system interface is not possible). If the server validates the one-time password, the user is successfully authenticated.

This mode of operation makes it likely that the user and secondary computer are physically co-located, since the validator must scan and validate the QR code.

Third-Party and Push Variants

Because physical co-location of the user and validator is not central to the design, provided Internet access is available, the validator could be run by a third-party or using some automated means. In these cases the third-party assumes responsibility for identifying the user. This requires the user to coordinate with the operation of the validator, however, so that the validator participates at the right moment (during the validation interval, explained below) and can be given the passcode. The user and third-party might coordinate by phone, instant messaging or using a custom app. In this arrangement, the third-party is essentially vouching for the user, and it therefore relies on a trust relationship between the user and third-party. This lets an account owner give someone else access to his account without having to reveal his password.

For some use cases, primarily those with lower security considerations or where an additional means of identifying users is available, another variation of the protocol is possible to make a third-party more integral. In this mode of operation, presumably access to the system interface is protected physically, or the third-party is sent a real-time photo or video of the user (or perhaps a screenshot of the user's display that includes a passcode duplicated in the notification). Here, a third-party is expected to operate the validator instead of the user that is signing-on, and a passcode is not used.

When the username is provided, the system interface contacts the validator (which was configured for the username and system interface), which notifies the third-party, providing authentication context. After the validator and system interface mutually authenticate, the third-party is prompted:

User sam is attempting to sign on to server example.com.
Allow sign-on? - - -
Abort sign-on? - - -

Custom Devices

While using a mobile device to function as a validator has many advantages, it is possible to create a small device with the necessary functionality. Hardware and software tools are available to create relatively inexpensive networking-capable devices (such as Particle). Repurposing a device is also possible (How to disassemble an Amazon Dash button and reprogram its STM32 processor!).

The major commercial off-the-shelf parts are:

Continued in Part 5.

Footnotes

  1. Exactly how the system interface handles an invalid username is an implementation decision. It could abort the procedure immediately or, to discourage attacks, it could allow it to continue but eventually fail.
  2. For ease of use, a corporate logo provided during account creation could be associated with a system interface and displayed with the validator's menu item. Or, the user might be able to assign a label or icon of his choosing to a menu item, which might be a particularly good alternative for children. A computer in a lab might be identified by a red sign and the corresponding validator menu item displayed with red. It is not necessary for the icon or label to identify the system interface in an obvious way; should a usable validator be stolen, its value would not be immediately obvious. Two or more system interfaces can be combined; for instance, the distinct but closely related login and screensaver system interfaces can be combined into one validator menu item (console) that works in both contexts.
  3. It should be noted that this procedure is somewhat less convenient than the procedure that it replaced, in which the card was swiped and neither an approval nor a PIN needed. It was imposed by credit card companies and banks nevertheless.
  4. In contexts where concurrent sign ons to the same account and system interface are not a concern, such as when there is only one instance of a system interface and the user must be physically present (e.g., from a workstation's console), or if physical access to the system interface is secure, the passcode can be optional or omitted. On the validator, any suitable alternative to entering the passcode using a virtual keyboard can be used. For accessibility reasons, or for children, an image or some other visually-specified item could be substituted for a passcode. It is only necessary to identify the instance of the system interface through the validator. In some cases a descriptive system-level name, such as a source IP address, port number, or terminal interface identifier may suffice.
  5. A problem can occur if one or more legitimate users and one or more attackers are allowed to sign on to the same account, at the same server and system interface, at approximately the same time. In the absence of appropriate measures, this can result in an attacker gaining unauthorized access to an account. The basic requirement is that there must be a means of pairing a validator connection with the correct authentication request.

    Consider what might happen if a passcode were not used and Alice and Bob both attempted to sign on as "alice" at the same web site at approximately the same time. Alice begins to sign on using Browser A first, selecting username "alice", and then Bob begins to sign on using Browser B, also selecting username "alice". Before Alice can use her validator, Bob uses a custom validator he has written and it tries to authenticate himself as "alice". The connection to the authentication service from Bob's validator arrives before Alice's and happens to be associated with the instance of the system interface servicing Browser A. It fails, correctly, because Bob does not have the correct credentials. The connection from Alice's validator arrives soon afterwards, and happens to be associated with the instance of the system interface that is servicing Browser B. It succeeds, because it came from a correctly configured validator, and now Bob is signed on as "alice". Alice sees a sign-on failure and tries again, this time successfully.

    This illustrates why a validator connection must be carefully correlated with the correct authentication instance, which is the purpose of the passcode.

    The simplest solution is to disallow more than one authentication transaction at a time at a particular interface for a particular username. This results in a one-to-one correspondence between an authentication transaction and the validator connection. In situations where it is unlikely that more than one sign on to an account should occur at the same time, this is a reasonable restriction.

    By adding a passcode to the protocol, the restriction can be avoided. The system interface (via the demultiplexor component) checks that the validator authenticates correctly for the given username. The passcode is sent by the validator as part of its initial message and also incorporated in the validator's proof of identity sent to the system interface during the M-AUTH protocol. If the proof is accepted, the system interface knows that the expected passcode was entered into the validator and that the validator has the identity information required for the user. This prevents the scenario above from succeeding, if Bob were to spy on Alice to steal her passcode, because Bob's authentication protocol will fail while Alice's succeeds. An attacker's ability to capture or guess a passcode does not therefore weaken TGMA.

  6. Traditionally, only processes running as root may bind to port numbers less than 1024. Recent Unix-type operating systems allow the privileged port range to be adjusted or use some other mechanism to allocate or control access to reserved ports (see sysctl(8), setcap(8), or bindresvport(3)).
  7. The connection interval is a period of time less than the validation interval.
  8. We would like to avoid using SSL/TLS for this connection because a) the messages we need to send are short, b) we don't want to rely on, or manage, SSL certificates, c) the additional code size and complexity that SSL/TLS adds is unnecessary, d) it is more heavy-weight (cpu-intensive, particularly server-side) than what is needed, and e) implementations have recently been the subject of many security advisories. The TGMA design uses a particular password-authenticated key exchange (PAKE) protocol, producing an ephemeral key that is shared by both parties. This key can be used to encrypt and sign messages that are subsequently exchanged on the connection, and can be used for TLS authentication (RFC 5054).
  9. Because security is built on a cryptographically strong pseudo-random (or truly random) key, a key strengthening function is not needed. This saves CPU cycles and possibly memory requirements that might otherwise be needed for each authentication attempt.
  10. This prevents an attacker that is somehow able to copy (or correctly guess) a passcode during a legitimate user's sign on from taking advantage of the passcode.
  11. After successful sign-on the system interface could conceivably assign a (different) username to the user's session. Depending on information obtained by the system interface from the validator, the username originally provided by the user could be changed. For instance, if Bob gives the username staff to the system interface but authentication establishes that Bob's validator is being used, the system interface might associate the username bob with his session rather than staff.
  12. Free or open source licensed scanner apps: "Generating QR Codes in Linux" [] Quick Scan [] QR Reader for iPhone [] ZBar Barcode Reader.
  13. There are alternatives to manually copying a passcode into a validator from a system interface or using a validator's camera to scan a QR code displayed by a system interface. An image of the passcode could be captured by the validator and sent to the system interface for analysis. It may be possible for the system interface and validator to communicate using a short-range transmission method, such as Wi-Fi, Near field communication, Bluetooth, or an RF transmitter, such as used by a wireless mouse. An audio encoding or alternative visual representation of the passcode may be workable in some contexts. Also: "Google Tone broadcasts URLs to any device within earshot", "Use AirDrop to transfer files from iPhone to a Mac and Mac to iPhone". There may be an opportunity to develop and sell a sufficiently secure, low-cost, short-range transmitter device to facilitate this communication with validator devices. Sending the passcode to a registered phone number or address via SMS may also be possible, although a fee might be levied or the mechanism abused to send spam.
  14. The means by which account information in a validator is initialized from a server and managed must obviously be secure. Offline methods (e.g., via email or text message) or methods built on secure web services are possible. As a validator is capable of scanning QR codes, this information might be sent as a QR code that must subsequently be destroyed by the user. For each account that it manages, a validator must at minimum store: Other administrative information, such as the creation and last modification times of the account, might also be stored.
Copyright © 2015-2017 Distributed Systems Software
All rights reserved.
Permission is granted to make and distribute verbatim copies of this document provided the copyright notice and this permission notice are preserved on all copies. Elements of the system described in this document may have patents pending.