Every authentication system makes trade-offs between security and practicality. TGMA aims to maximize^[10] both characteristics by combining strong cryptographic methods with separate communication channels. A successful attacker must breach multiple components of the system simultaneously.

TGMA is intended to meet the following requirements:

• Eliminate user-level passwords for authentication. If a password is not used for authentication, users cannot be tricked or coerced into giving up a password. If account information stored on a server is difficult for an attacker to successfully leverage, the consequences of a successful attack are less likely to be catastrophic, and the server may be a less attractive target for attackers. Intentionally computationally- and memory-intensive password hashing algorithms (such as bcrypt or scrypt) are unnecessary with TGMA;
• Provide a sign-on procedure that is much more secure than one using password-based authentication;
• Be acceptably quick for users to perform, compared to entering a "sufficiently secure" password,^[1] and simple for them to learn to use;
• Replace password-based authentication in virtually every context where it is currently used and also be applicable in new contexts;
• Be no more difficult or expensive for sites to deploy and administer than password-based authentication methods;
• Not have to rely on a vendor or central service, which may be subject to foreign control or law;
• Allow the level of security to easily be increased in response to improvements in computation speed or weaknesses in cryptographic algorithms without requiring any user action (while occasional client software updates may be necessary, no "password reset" operation needs to be done in contrast to systems that must change their password hashing algorithm to increase security);
• Accommodate optional value-added functionality, such as: third-party sign-on approval, rule-based access control (e.g., parental controls, user location), and centralized functionality, including event logging, attack detection, and disabling sign-on;
• Not depend on methods that may incur unexpected usage charges (e.g., long distance, roaming, or SMS fees);
• Support the secure and private exchange of messages between a validator and the system interface after successful M-AUTH;
• Not require any mobile operating system features beyond the basics required by the protocol specification and normal security measures;
• Minimize the number of system components that have access to secrets (such as encryption keys) during authentication; in particular, use of a web browser as a validator is forbidden since we consider most to be inherently untrustworthy for this purpose because of the many well-known attack vectors and routine discovery of new ones;
• Not rely on any special-purpose hardware (e.g., password-generating tokens, biometric scanners);
• Not depend on the availability or trustworthiness of a central authority (e.g., as might be required to validate a certificate), be easily revocable on a per-system interface level (e.g., a user is not identified globally, so each of a user's accounts is independent of all his other accounts);^[2]
• Support accessibility features for ease of use by children and those with certain disabilities (therefore does not require a virtual keyboard); strong authentication is provided without the need to remember, record, or enter a lengthy password for each system interface;
• With respect to children, a child without access to a validator (or someone operating one for her) cannot sign on. It does not matter much if a child changes her normal password (although often the old password is required to do this and a child is unlikely to have it when the validator is used), whereas on a normal password-based system a password change might cause problems until the password can be reset; and

A fundamental requirement of the TGMA design is to maintain security while assuming that an attacker:

• understands the well-documented system,
• knows or can easily guess valid usernames,
• has access to the implementation source code, and
• can freely monitor, modify, or inject network traffic.

It is assumed that best security practices are observed in implementations and by system administrators on servers, and that users take reasonable precautions. The security of a given account depends on protection of the software on a secondary computer against unauthorized access or theft. General attacks against a server, such as denial of service attacks (DoS), are outside of the scope of the protocol but may be addressed by common techniques (e.g., inserting delays between sign-on attempts, locking out accounts after unsuccessful sign-on attempts, using appropriate firewall rules). A denial of service attack may prevent legitimate users from authenticating.

TGMA is not intended to supplant every authentication method in all cases. In situations where a user has already been authenticated, single sign-on methods can be used to provide secure sign-on with no additional user interaction (e.g., sshd(8)). Also, TGMA is not designed for non-interactive use cases. When it is warranted, however, it can be be combined with other types of authentication to improve security.

Definitions

The following concepts referenced in this paper are now more fully defined:

• User: a person performing an interactive sign-on. A user is identified by a username, relative to a given system interface and a given server. Each such username is associated with an account for which various meta information is maintained, such as information used for authentication, preferences, identity-related information, billing information, and so on. A username associated with a particular web site account can be unrelated to a desktop account with the same username on the same workstation, for example.
• System interface: any interactive mechanism by which a user may authenticate himself (as a specified username) to a particular service accessible through a user agent, such as a browser presenting an HTML form to sign-on to a web-based account,^[3] a login shell that supports command-line or GUI-based access to an account, the su command to switch to another user identity, or an FTP client. If a system interface supports concurrent authentication requests, there can be multiple instances of the system interface (i.e., more than one active process). A system interface is required to have network access through which it can directly or indirectly accept a connection from a sign-on validator. A network-capable device that requires authentication, such as a router, modem, or deadbolt ("smart lock") can be a system interface.^[4]
• Authentication, Mutual authentication, and Sign-on: Authentication is successful when a system interface is satisfied that a user can be associated with the username and account that it has asserted. After successful authentication, a user initiates a session with the system interface. Mutual authentication succeeds when, in addition, a system interface proves its identity to its user. Although "authentication" and "sign-on" are often synonymous, we will define them slightly differently. Sign-on is successful if the authentication function succeeds (i.e., the user has proved his identity to the system interface) and all post-authentication requirements are also met. Sign-on may fail even when authentication succeeds. For example, if Sam provides a correct username and password he will be authenticated by his desktop, but if he is not allowed to use his computer after 6pm, he may not be allowed to sign on.

  We do not restrict how accounts are used. At any instant a user may be signed on to the same account multiple times (e.g., Bob may be signed on as "bob" using two different browsers) or different accounts (e.g., Bob is signed on as both "bob" and "robert"), and different users may be signed on to the same account (e.g., Bob and Alice are both signed on as "guest").

• Secondary computer: a programmable computer system that is trusted by a user and is separate from all systems on which the user may sign-on using TGMA. The secondary computer must be able to run the sign-on validator software and periodically update it. It must have network access (not necessarily continuously), the ability to scan a barcode, or both. It is assumed that access to the secondary computer requires authentication and appropriate security measures are observed. The secondary computer's method of communication with the system interface should be independent of the communication path between the user agent and the system interface, making it necessary for some kinds of attack to infiltrate two separate networks simultaneously.
• Server: a server provides one or more services, each of which requires user authentication and is accessed via a system interface. A system interface may be physically attached to the server (e.g., the console device) or provided over a public or private network. A service provider can be a server or system interface, or a business or organization that offers services to users.
• Attacker: a person or software that attempts to gain unauthorized access to a system by circumventing security measures or taking advantage of a design or implementation deficiency in violation of the system's policies or terms of service, or applicable law. A system is considered to be compromised and untrustworthy if it is possible that an attacker has been able to copy information from it or modify it in any way.
• Federation: a dynamic group of hosts or services that coordinate information sharing through administrative and business practices. The hosts may share a common domain name suffix, but need not.
• Sign-on validator or validator: a tool to help a user authenticate and manage security-related information. A validator is secure software, running on a secondary computer or special device, that acts on behalf of the user or a delegated third party to 1) validate the identity of the system interface with which a user is interacting and to 2) prove the identity of the user to the system interface. A sign-on validator can manage one or more accounts (system interfaces) for a user. A user may have multiple instances of his validator, each on a different secondary computer (e.g., one copy on a phone, another on a tablet, and a third on a laptop).^[5] Instances of a user's validator can share configuration information, although each instance is uniquely identified (e.g., using the device's hardware serial number, IMEI, MEID, an SSL client certificate, or some combination). It is assumed that access to the validator requires separate authentication using a password, thumb print, etc.^[6] Appropriate practices to maintain security are assumed, such as having an inactivity timeout and maintaining all authentication-related data in a secure manner.^[7] It is assumed that, in general, although a validator can initiate a network session with an arbitrary server, it is not possible for it to accept incoming network connections.
• Authentication context: any available information related to a particular instance of authentication, such as the time and date, IP addresses, the username and server's hostname, type of service, secret keys or values obtained from them, software versions, applicable rules and configuration, etc.
• Sign-on approver or approver: The sign-on approver is a tool to help a third party monitor and override authentication. Immediately after authentication and prior to termination of the sign-on procedure, the system interface can invoke an optional, client-specified callback (via a URL) that is passed authentication context. The callback may unilaterally abort authentication.^[8]
• Communication channel: a network connection over which a system interface and validator exchange messages. This will typically be a TCP/IP connection over the Internet/LAN and Wi-Fi, but alternative networking configurations that can provide reliable, flow-controlled, bidirectional data transmission are possible (Bluetooth). Communication is not assumed to be private or tamper-proof. A network connection may pass through a firewall, proxy server, or other system component.

A TGMA system comprises the following active components:

• Server
  A server provides one or more services.
• System Interfaces
  A user interacts with a service through a system interface.
• Communication Network
  Communication between active components may be carried out over public or private networks, using cell phone or Wi-Fi TCP/IP service.
• Network Demultiplexor
  Communication from validators to a given server must be demultiplexed from a single reserved port to a particular instance of authentication. Moreover, data from a validator to a given server may arrive over an external network (e.g., a cellular data network). It may therefore be necessary to accept Internet traffic from a validator on a firewall/DMZ server and relay it to the internal server where the user's instance of authentication is running.^[11] Communication need not be connection-oriented (TCP/IP). In some contexts, UDP may be preferable to TCP/IP.

  Each authentication instance at a given server is uniquely identified by a tuple, for instance:

  (tgma-account-name, username, system-interface[, passcode])
  

  And for example:

  ("alice", "alice", "https://example.com", "g0OgE")
  

  The tgma-account-name is the name of the owner of the account on this server. A passcode, described below, is used to match a validator's connection to the corresponding authentication instance. Additionally, an interface-identifier, assigned by the system interface and associated with the sign-on instance may be included, such as a device name (e.g., tty17), client socket address (10.0.0.130:28717), or memory address (&usertab[4]). The name may be local to the system interface and therefore difficult for a user to determine.

• Authentication Component
  The authentication component interacts with the system interface and account information on the server to verify the identity of a user. Like the file or database used to maintain user account and password information, access to the private elements of the TGMA account information must be carefully administered.
• Sign-on Validator
  The validator is software that runs on a device separate from the system interface. It interacts with the user and the system interface to verify the user's identity with the system interface and confirm the identity of the system interface to the user. It is possible to create a custom validator that includes application-specific functionality (or, equivalently, a custom application that includes validator functionality).
• Sign-on Approver
  Optionally, after successful authentication but before sign-on, the sign-on approver component interacts with the system interface to perform custom actions, which may be on behalf of a third-party.^[9]

Continued in Part 4.