The following diagram provides a high-level overview of the sequence of events that occur during a successful execution of the authentication protocol:
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:
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.
The sign-on validator:
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).
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.
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.
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.
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]
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.
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? - - -
The major commercial off-the-shelf parts are:
Continued in Part 5.
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.