Internet-Draft TOTP2 Authentication Scheme July 2023
Strbac Expires 24 January 2024 [Page]
Workgroup:
ietf
Internet-Draft:
draft-strbac-totp2-00
Published:
Intended Status:
Informational
Expires:
Author:
D. Strbac
Mercata

TOTP2 Authentication Scheme

Abstract

We present a second-factor authentication scheme that extends the Time-Based One-Time Password (TOTP) method to provide superior protection against phishing attacks.

Unlike traditional one-time password flows that solely authenticate the user with the service, our approach introduces an extended flow that seamlessly authenticates both the user and the service to each other. This enhanced process ensures a secure submission of the user's second-factor authentication via a secondary and secure communication channel.

By verifying the service's authenticity to the user, our scheme establishes a robust defence against potential phishing attempts, enhancing the overall security of the authentication process.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 24 January 2024.

▲

Table of Contents

1. Introduction

The TOTP2 authentication scheme builds on the Time-Based One-Time Password (TOTP) algorithm method defined in [RFC6238]. It enhances the security by incorporating two TOTP shared secrets, strictly linked to a specific service, and provides a mechanism for securely transferring and verifying TOTP codes via HTTPS. TOTP2 offers enhanced protection against phishing attacks without penalizing the user experience.

The TOTP2 scheme replaces manual code input with a secure submission process directly from the TOTP2 authenticator to a verification URL tied specifically to the service being authenticated. By performing an XOR operation on the two one-time codes, the authentication scheme ensures that the on-screen one-time code becomes meaningless to potential attackers.

The authentication process can be further streamlined through the use of QR codes and automatic submission from the authenticators, simplifying the user experience. The TOTP2 authenticator requires an active Internet connection to facilitate the communication and submission of generated codes.

1.1. Naming

The name "TOTP2" is intended to be understood as TOTP "duo" rather than a TOTP versioning scheme. This naming choice reflects the use of two secret keys and codes in the authentication scheme, emphasizing the dual nature of the authentication process.

1.2. Background

The usage of two codes in the TOTP2 authentication scheme offers distinct advantages over using a single TOTP code, as outlined below:

  • Authentication of the Service: The service-provided one-time code serves as a means of authenticating the service to the user. By presenting this code, the service demonstrates that it possesses the shared secret, thus assuring the user that they are interacting with the genuine service and not a phishing attempt. This additional layer of authentication enhances security and instills trust in the user.
  • Session Identification: The one-time code can be utilized to identify and manage multiple active sessions. Each session can be associated with a unique one-time code, allowing for the simultaneous authentication of multiple sessions. This capability enables greater flexibility and convenience, particularly in scenarios where users may need to access the service from multiple devices or locations concurrently.

By incorporating two codes in TOTP2, the authentication process becomes more robust and versatile, providing enhanced security and improved user experience.

The traditional one-time code verification process is susceptible to phishing attacks since attackers can reuse the code within its validity window. To counter this threat, TOTP2 enhances security by using a non-interactive channel to submit the one-time code.

By using a non-interactive channel, such as an automated submission process directly from the TOTP2 authenticator to the service's verification endpoint, the user is not required to manually input the one-time code. This reduces the risk of exposing the code to potential phishing attacks during the submission process.

The non-interactive channel ensures that the one-time code is securely transmitted to the service, reducing the window of opportunity for attackers to intercept and reuse the code. This approach significantly enhances the security of the TOTP2 authentication scheme and provides increased protection against phishing attempts.

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

3. Authentication Scheme Overview

The TOTP2 scheme follows these steps:

4. Detailed Scheme Description

4.1. TOTP2 Registration

The TOTP2 registration process starts with the user initiating the registration on the TOTP2 authenticator. During registration, the user provides the authenticator with the required information provided by the service, which includes the two shared secrets, "service_secret" and "client_secret," along with the "verification_endpoint" URI for TOTP2 code submission.

Once the registration is complete, the provided information, including the shared secrets and verification endpoint, is securely stored locally on the TOTP2 authenticator for future use.

To simplify the registration process, QR codes are commonly used to transfer the information to the authenticator. The service registration information is encoded as an OTP URI within the QR code, containing all the required service details.

Once the registration information is provided, the authenticator generates a TOTP OTC (One-Time Code) for each shared secret. These codes are then combined using an XOR operation, resulting in the final TOTP2 code. This final code is then submitted to the provided endpoint to conclude the registration process.

4.1.1. Registration URI

The OTP URI format for TOTP2 service registration is as follows:

otpauth://totp/LABEL?PARAMETERS

The LABEL is used to identify which account a key is associated with. It contains an account name, which is a URI-encoded string, optionally prefixed by an issuer string identifying the provider or service managing that account. This issuer prefix can be used to prevent collisions between different accounts with different providers that might be identified using the same account name, e.g., the user's email address.

The issuer prefix and account name should be separated by a literal or URL-encoded colon, and optional spaces may precede the account name. Neither the issuer nor the account name may contain a colon. The representation in ABNF according to [RFC5234] is as follows:

label = accountname / issuer (":" / "%3A") *"%20" accountname

Valid values for LABEL might include examples like:

  • "Example:alice@gmail.com"
  • "Provider1:Alice%20Smith"
  • "Big%20Corporation%3A%20alice%40bigco.com"

We recommend using both an issuer label prefix and an issuer parameter, described below.

The PARAMETERS provided in the TOTP URI format include:

  • password_entry: A 'yes' or 'no' (default) value, indicating whether the password entry should be made within the authenticator
  • service_secret: The shared secret used by the service to generate codes for verification in the TOTP client app.
  • client_secret: The shared secret used by the TOTP client app to generate TOTP codes for verification by the service.
  • algorithm: The algorithm used for generating the TOTP codes (e.g., SHA1, SHA256).
  • digits: The number of digits in the generated TOTP codes (e.g., 6, 8).
  • counter: The initial counter value for the TOTP algorithm.
  • period: The time period (in seconds) for which a TOTP code is valid.
  • verification_endpoint: The URL to which the TOTP client app should submit the client TOTP code and previously received service code. It must start with "https://" protocol prefix.

4.2. Service OTC Generation

Upon authentication request, the service generates a one-time code based on the service secret (service_secret) associated with the user's account. This code is then used to construct a QR code containing a TOTP2 request for the authenticator. The QR code includes the following value represented in ABNF syntax:

REQUEST = LABEL (":" / "%3A") *"%20" OTC (":" / "%3A") *"%20" TIMESTAMP

The LABEL SHOULD BE the same as the one provided in the OTP registration URI.

OTC represents the generated TOTP one-time code using the service secret.

The TIMESTAMP represents a Unix timestamp identifying the time of otc generation.

The QR code serves as a visual representation of the TOTP2 request, allowing for easy transfer of the code to the authenticator app. Valid request might include examples such as:

  • "Example:alice@gmail.com:1689694239"
  • "Provider1:Alice%20Smith:1689694239"
  • "Big%20Corporation%3A%20alice%40bigco.com:1689694239"

These examples demonstrate how the label and one-time code can be combined within the TOTP2 request for inclusion in the QR code.

4.3. Service OTC Verification

Upon scanning the QR TOTP2 request with the authenticator application, the authenticator decodes the information contained within.

The authenticator performs the following actions:

  1. Time Synchronization Check: The authenticator compares the Unix timestamp obtained from the QR code with the local time. If the time difference exceeds a certain threshold, indicating a significant time discrepancy, the authentication fails. In such cases, an out-of-sync warning is presented to the user, indicating the need for time synchronization.
  2. Account Identification: If the authenticator supports multiple accounts, it uses the label part of the TOTP2 request to identify the corresponding registered account. The label acts as a unique identifier for the account within the authenticator.
  3. TOTP Code Verification: Using the service secret associated with the identified account, the authenticator verifies the provided TOTP code. The TOTP code is generated based on the client secret and the current time.
  4. Authentication Result: If the registered account is successfully identified and the provided TOTP code is verified, the authentication process is considered successful, granting access to the service. However, if no registered account can be identified using the label or the provided TOTP code fails to verify, the authentication process fails.

In case of authentication failure, appropriate feedback is presented to the user, indicating the reason for the failure, such as an incorrect label or an invalid TOTP code.

4.4. Client OTC Generation

After successfully verifying the service-provided TOTP one-time code, the TOTP2 authenticator generates a new TOTP one-time code using the "client_secret." The authenticator then performs a bitwise XOR operation between the service-provided one-time code and the newly generated one-time code. This XOR operation results in a new combined TOTP2 code, which is now ready for submission to the service.

4.5. Optional Password Entry

The TOTP2 scheme provides an optional feature known as "Optional Password Entry." In typical TOTP implementations, when the second-factor authentication is initiated, some form of primary authentication has already occurred. However, in phishing scenarios, the user's credentials might have been stolen before the TOTP authentication takes place.

To enhance security further, the TOTP2 registration process includes a "password_entry" parameter. When this parameter is present and set to "yes," the password entry is deferred until after the TOTP2 authentication.

Once the TOTP2 authenticator generates the TOTP2 one-time code, it prompts the user to enter their password. The user then provides the password, and both the TOTP2 code and the password are submitted together to the service for final authentication.

By deferring the password entry until after TOTP2 authentication, this optional feature adds an extra layer of security, reducing the risk of exposing the password to potential phishing attempts during the initial authentication phase.

4.6. TOTP2 Code Submission

The verification URL for TOTP2 code submission follows the format:

VERIFICATION_ENDPOINT ("?" / "&") PARAMETERS

The VERIFICATION_ENDPOINT is provided during the TOTP2 registration process, which must begin with the 'https://' protocol prefix.

The PARAMETERS included in the verification URL are as follows:

  • "code": The TOTP2 one-time code generated by the TOTP2 authenticator application.
  • "account": The account name provided during the TOTP2 authenticator registration, present in the TOTP2 OTP URI as label.

If the verification endpoint already includes query parameters, the new parameters SHOULD be correctly appended.

To ensure secure submission of the TOTP2 code, the TOTP2 authenticator application makes an HTTP GET request using the HTTPS protocol defined in [RFC9110]. If an untrusted HTTPS connection is detected, the authentication process MUST fail.

A successful authentication is indicated by receiving a HTTP 2xx status code. The response body of the message should be discarded. Any other status code indicates a failed authentication.

4.7. Authentication

Upon receiving the TOTP2 code from the user, the service performs the following steps to validate the code and authenticate the user:

  1. The service looks up the corresponding account associated with the TOTP2 code.
  2. Using the shared secrets (service_secret and client_secret), the service calculates its own TOTP2 code.
  3. The service compares the calculated code with the received TOTP2 code.
  4. If the codes match, the validation is successful, and the user is considered authenticated.
  5. The service grants the user access to the requested service or resources.
  6. In response to the code submission request, the service sends an HTTP 2xx status code to indicate a successful authentication process.

If the TOTP2 code fails to validate, the authentication flow on the user's screen indicates a failure, and the user is not granted access to the service or resources.

5. Recovery Procedure

Authenticators can be lost or become inaccessible, making it essential for service providers to establish a reliable recovery procedure for users. While the specifics of the account recovery process vary between providers, one common approach is the use of recovery keys during TOTP2 registration.

Recovery keys serve as a secondary authentication factor and should be securely stored by users. In case of losing access to the authenticator, users can utilize these keys to regain account access. However, it is crucial to emphasize that recovery keys should only be used on trusted devices.

By limiting the usage of recovery keys to trusted devices, service providers can mitigate the risk of unauthorized account access. Trusted devices are previously authorized and meet security criteria such as device registration or multi-factor authentication.

Service providers should validate the trustworthiness of devices during the recovery process, ensuring their identity and adherence to security measures. This helps maintain the overall security of the account recovery process and protects user accounts from unauthorized access.

Clear documentation and instructions on using recovery keys should be provided to users, making the recovery procedure easily accessible. Service providers should also consider security implications and implement appropriate measures to safeguard user accounts during the recovery process.

6. Security Considerations

The TOTP2 scheme introduces several security considerations to ensure the confidentiality and integrity of the authentication process:

By addressing these security considerations, service providers can enhance the overall security of the TOTP2 authentication process and protect user accounts from unauthorized access and attacks.

7. IANA Considerations

This document has no IANA actions.

8. References

8.1. Normative References

[RFC6238]
M'Raihi, D., Machani, S., Pei, M., and J. Rydell, "TOTP: Time-Based One-Time Password Algorithm", RFC 6238, DOI 10.17487/RFC6238, , <https://www.rfc-editor.org/rfc/rfc6238>.
[RFC9110]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, , <https://www.rfc-editor.org/rfc/rfc9110>.

8.2. Informative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC5234]
Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, , <https://www.rfc-editor.org/rfc/rfc5234>.

Author's Address

Dejan Strbac
Mercata SagL
via E. Bosia 5c.
CH-6900 Paradiso
Switzerland
Phone: +41-78-6144568