A sign-on approver is a web service that is invoked by a system interface immediately after a user has authenticated (so the user's identity has been established) but before the sign-on procedure completes. Unlike the sign-on validator, an approver must always be Internet accessible, and whereas a validator generally acts in a user's interests, depending on who is permitted to configure an approver, it may act for a user, a third party, or both. The functionality provided by an approver is unspecified, except that it must return an indication of whether the sign-on procedure is allowed to complete successfully. It could also be used to return configuration information to the system interface, on behalf of a third party (e.g., constraints on the user's session, such as its maximum duration) or on behalf of the user (e.g., environment variables). Use of an approver is optional. (The shared encryption key could be passed as an argument.)

An approver can consult a set of rules to decide whether to grant or deny user access. Rules might restrict a particular user's access based on the current date, day of the week, or time.

An approver is specified by a URL configured on the server for a user's account. Communication is secure and the system interface authenticates itself.

For children, regardless of the underlying system, there are several applications:

• Sign-on approval could be performed by, or directed to, a parent or teacher;^[1]
• account access can be actively monitored;
• Approval requests can be passed through a set of rules to enable or disable sign-on very flexibly; rules can permit or deny sign-on based on context such as:
  • the current day, date, or time;
  • cumulative sign-on count, frequency, or elapsed time;
  • system interface type or its physical location,
  • the user's physical location (if provided by the validator);
  • IP address
  • system load
• Sign-ons across all systems and interfaces can be monitored and logged from one location, in real time.

Administration of the rules and monitoring/logging can be done remotely, in contrast to Parental Controls such as those provided by Mac OS X, and others.

The sign-on validator might be able to provide some of the same features as an approver, except that it is unnecessary for a validator to always have Internet access. Since an approver may be any web service, it has considerable flexibility.^[2]

It would be useful to be able to automatically invoke a configurable callback when a user signs off. This would enable accurate session lengths to be determined, so that cumulative sign-on time could be computed and tested by an approver rule. Unfortunately, a reliable automatic sign-off callback is not possible in general. Sign off is sometimes implicit, as is often the case in web-based activities or when a system crashes. It may be possible for a system interface to provide an estimate, however, which could be made available to approver rules. As mentioned earlier, an approver could provide a system interface with a constraint on the maximum session duration, which could be used to terminate a session if there is adequate server-side support. An explicit sign-off operation through TGMA is possible and could be useful in some contexts.

Because it is interposed between a server and user agent, a sign-on validator can manage a user's authentication-related state information within a generic single sign-on (SSO) facility. Whereas many single sign-on systems are tied tightly to a particular kind of system interface (e.g., a web browser that supports HTTP), this capability can be independent of user agents (web browser, FTP agent, remote shell) and the protocol used between a user agent and system interface.

In a common situation where a user is allowed to sign on to any of several closely related systems, such as when they are all within the same organization, a single sign-on capability can simplify authentication both for users and system administrators.

To add single sign-on to Use Case A, immediately after Sam successfully signs on, s1.example.com sends a message to the validator that contains an arbitrary token and a new encryption key. The message is encrypted using the shared session key. The validator stores the token and key in a list, associating it with the server, username, and service:

The format of the token might be an extension of the HTTP Cookie Specification (RFC 6265), describing where the validator is allowed to forward the token (server-spec), a lifetime/expiry date for the token (expiry), and opaque data (opaque-data):

When Sam later initiates sign-on at s2.example.com, which has no account information for sam but which is within the same federation as s1.example.com, Sam selects an identity within the SSO federation example.com on his validator. The validator determines that the previously stored token's server-spec allows it to be forwarded. Sam allows single sign-on authentication at s2.example.com to proceed. The validator sends the token to the system interface, which has been configured to provide single sign-on for federation example.com and that interacts with s2.example.com to sign-on sam in the normal way. The validator uses the encryption key it stored with the token to identity the user. Additional context can be encapsulated within the token and passed to s2.example.com.

Unlike the HTTP cookie mechanism, an arbitrary server/service matching method can be used so that hosts participating in single sign-on need not share a domain suffix. For example, if the token's server-spec also matches rick.fedroot.com, Sam could subsequently initiate sign-on with that server similarly.

Instead of functioning solely as an authentication component, a validator could serve as a more general-purpose security tool, such as for storing and managing encryption keys. TGMA could be integrated with specially-written client/server applications. An output of a suitable M-AUTH protocol is a secret, random key, that is known only by the validator and system interface. The key can be used for encryption, digital signatures, etc., but can also be used to securely transmit keys in either direction.

Neither PAM nor applications that use it have a facility to return arbitrary information to the application that might be generated during authentication, such as an encryption key.

The main issue is that post-authentication, the shared encryption key resides on the server and validator, not on the client. But following authentication, it is operations between the client and server that require the encryption key.

It seems that the only practical way to leverage this is using a two-step operation. Post-authentication, the validator and server share an ephemeral key. In the first step, the server uses the encryption key in a transaction. The validator stores the key and associates it with the transaction. In the second step, the validator retrieves the key associated with the transaction and sends it to an authenticated server so that it can validate a signature or decrypt using the key.

A satisfactory, practical way to securely transmit the key to the client has not yet been developed:

• If the validator is built-in to the client
  The client initiates an authentication operation with the server, conducts TGMA, then performs application functions. This is problematic because separation between client and validator is lost.
• The validator transfers the key to the client
  After normal M-AUTH, the server holds the key and waits for the client:
  • Simplest: validator displays a passcode (derived from the shared key and encoded as six characters from a subset of easily-read alphanumerics, yielding a sufficiently large space of possibilities). The user reads the passcode from the validator and enters it into the client. Problem: to be practical, the effective length of the encryption key is shortened.
  • Alternatively: after successful M-AUTH, the validator connects to the client (but how?) using pre-configured account information (but client does not have any), and sends the key (encrypted). How is the key secured during transmission?

As a simple example, imagine TGMA integrated with an FTP server (ftpd) and an FTP client (ftp):^[3]

1. The user starts a TGMA-enhanced FTP client normally, specifying a remote identity and resource to be fetched.

   % ftp alice@example.com:/home/alice/myfile
   

2. Through a suitable FTP protocol message, the FTP server sends a TGMA passcode to the FTP client, which in turn shows it to the user (here, as text rather than a QR code). The FTP client then waits for the user to enter the FTP key.

   TGMA passcode: DJLYE
   FTP Key?

3. On her validator, the user selects the appropriate FTP server identity (e.g., example.com: FTP alice) and enters the TGMA passcode (DJLYE).
4. If M-AUTH succeeds, the validator displays an FTP Key:

   FTP Key: Nzb2a7

5. The user enters the FTP Key displayed by the validator into the client.
6. The file transfer begins, with the data stream encrypted by the server using the shared key Nzb2a7 and decrypted by the client using the FTP Key entered by the user.^[4]

But this may be too clunky to be practical. It might be streamlined by omitting the TGMA passcode, which is safe because the FTP passcode is known only by the legitimate user. Anyone else will not have the key to give to her FTP client to decipher the file that is fetched.

When an SSL-based service starts, such as a web server, it must load one or more private encryption keys. These keys are typically stored in regular files, ideally in encrypted form. A password is obtained to decrypt the keys at runtime, each time the server starts (e.g., for Apache, using the SSLPassPhraseDialog directive). Because this is inconvenient, requiring constant monitoring of the server or risking web site down time, many system administrators choose not to encrypt the private key, leaving the web site and its users vulnerable to attack if the system is compromised and the private key stolen. A second reason is that after a successful attack is detected, a system administrator might reasonably assume that the private key has been compromised even if it had been encrypted. A solution that stores the decryption key on another system may only serve to complicate the problem and introduce new security issues.

In one solution, the private key might be encrypted and stored in a regular file, but the encryption key would be generated by and stored within the validator. After authentication, the validator would pass the decryption key to the web server over a secure connection. Alternatively, instead of storing the private key with the web server, store it in the validator; after authentication, the validator passes the (unencrypted) private key to the web server.

Note that if a server is compromised by an attacker that has obtained superuser privileges, its system administrator must assume that all unencrypted keys, even those that might be in a memory image (core dump, running process), could have been copied. If the private key is stored on the validator, it would be much more difficult for an attacker to obtain a copy of it.

Client app requests a server to sign a document (username provided, e.g., on command line), server waits for user's validator to complete M-AUTH, server uses resulting key to sign document and return to client, key stored in server and validator (?) to validate signature later. Client never sees the key because crypto operations are done on the server and key is never returned to client.

Digital co-signing is similar, but like the two-man rule, employs more than one signature.

The OpenSSL library is widely used for its cryptographic functionality, including its implementation of the SSL/TLS protocols, by both open source licensed and proprietary software. OpenSSL uses a permissive BSD-like open source license. Integrating TGMA support into OpenSSL would help to make it accessible.

One possible (rough) design might add functionality to the openssl(1) utility Given a command line flag, the utility initializes, acts as TGMA server, and waits for a validator connection. After successful M-AUTH, the validator sends a (symmetric) encryption key to the utility to perform the requested encrypt/decrypt/sign operation. The user of the validator manages the keys (create, delete, etc.).

TGMA can be used in a hybrid architecture that uses the protocol for higher-level mutual authentication and a user-level password at the system interface. As part of account initialization at the validator, the user's normal password is provided and stored in the validator's (encrypted) database. The TGMA keys for the account may authenticate the user or the validator. TGMA authentication is conducted as usual, except that following M-AUTH the validator sends the password to the system interface, encrypted using the session key. The system interface validates the username and password normally.

This architecture is a cross between TGMA and a password management application. It retains many of the features and characteristics of a password manager, but also some of the drawbacks. It offers some advantages, such as:

• passwords are always transmitted securely without the need for SSL/TLS,
• passwords are sent over a separate communication channel (out-of-band), and
• mutual authentication is provided.

Its main drawbacks are that user-level passwords are stored in the validator and must be kept synchronized with the system interface, and a server-side TGMA component is still needed (unlike a password manager).

It is not clear that the hybrid architecture is superior to standard TGMA.

Account creation is done through a typical enrollment/provisioning procedure. A username, unique to the server, is associated with one or more system interfaces and metadata, including authentication parameters. The user can optionally provide a device identifier (such as its hardware serial number) and a password (for use when the corresponding menu item is selected on the validator). Account information is maintained on both the server and the user's validator.

Once a server-side account has been configured, account information on the validator can be registered in any of several ways, largely automatically, depending on the degree of security required. For example, account information encoded in a text message or email message might be sent to the device and processed by the validator, a QR code image might be displayed or supplied as a hardcopy and scanned by the validator, or the validator might upload the account information over a secure connection with a preconfigured central server. So that it cannot be reused, the encoded account information expires immediately after the account has been enabled or if it has not been used within a validity period. Configuration shared by the server and validator might be transmitted over an SSL/TLS connection or using an ad hoc key-agreement protocol (such as Diffie-Hellman) and encrypted communication channel. To avoid SSL certificates, procedural precautions must be taken to ensure the legitimacy of the two parties; to prevent phishing, a paper copy of codewords might be provided to the user out-of-band, facilitating mutual authentication for provisioning.

Additional validators for an account can be registered in the same way. Once imported, the validator connects to the server to enable the account. Since only a registered validator can act on behalf of its user, any authentication attempt by an unregistered validator can be flagged as an attack (and its IP address could be blacklisted, for instance); while guessing attacks are impractical, attackers may not know it.

This account information can later be updated at any time, provided information on the server and validator are always synchronized and appropriate security precautions are observed.

Since a shared encryption key is available after every successful mutual authentication procedure, a server can update its account information securely at that time by defining a post-authentication protocol.

A server can unilaterally revoke a user's access simply by deleting account information. If a new account is created with the same user name, it will almost certainly be assigned different key material, rendering invalid any old account information that may be stored on validators.

A user can easily revoke the ability to sign on by deleting an account on the validator. A parent can disable a child's access to an account in this way, for example. Or, access can be suspended by placing (or changing) a password on the account. In both cases the account continues to exist on the server.