Time-Gated Mutual Authentication
System Architecture: Part 6

DRAFT (15-November-2016)

Distributed Systems Software
Victoria, BC

Part 6

The Sign-On Approver

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:

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.

Single Sign-On

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:

sso-item ::= (s1.example.com, sam, http, token, key)

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):

token ::= (server-spec, expiry, 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.

Cryptographic Applications

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:

FTP Example

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.

Web server start

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.

Digital signature

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.

Integration with OpenSSL

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.).

Hybrid Architecture

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:

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 and Management

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.

Continued in Part 7.


  1. For a school computer lab, children would not likely be allowed to have their personal device at hand. But a teacher's device, or a shared tablet, could be used to sign on students.
  2. There is some question about whether the sign-on approver should be invoked by the validator or the system interface. The main issue is that a sign-on validator may not always have Internet access, so either approval may be unavailable at times or the functionality must be integrated with the validator, which would increase its complexity greatly and make the sharing of approval functionality amongst related validators problematic since each could be updated independently. Updating rules outside of the device(s) would involve a "pull" model that could be overridden by altering a device's Internet functionality. In support of using the system interface, which is assumed to always have Internet access, implementation is simpler and sharing amongst related validators is easy since they can use the same rules. System interface providers may not in general be happy about invoking arbitrary approver web services, although it could be a value-added capability and it is optional. This is not an issue when the approver is run by the same party that provides the system interface (e.g., an employer is providing authentication and specifying rules, or a parent is providing authentication and specifying rules for children).
  3. RFC 2228: FTP Security Extensions
  4. The key is possibly stretched, and used with a cipher such as AES. This is sufficient for US TOP SECRET designated information when used with a 192- or 256-bit key.