| Internet-Draft | TOTP2 Authentication Scheme | July 2023 |
| Strbac | Expires 24 January 2024 | [Page] |
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.¶
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.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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.¶
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.¶
The usage of two codes in the TOTP2 authentication scheme offers distinct advantages over using a single TOTP code, as outlined below:¶
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.¶
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].¶
The TOTP2 scheme follows these steps:¶
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.¶
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:¶
We recommend using both an issuer label prefix and an issuer parameter, described below.¶
The PARAMETERS provided in the TOTP URI format include:¶
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:¶
These examples demonstrate how the label and one-time code can be combined within the TOTP2 request for inclusion in the QR code.¶
Upon scanning the QR TOTP2 request with the authenticator application, the authenticator decodes the information contained within.¶
The authenticator performs the following actions:¶
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.¶
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.¶
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.¶
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:¶
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.¶
Upon receiving the TOTP2 code from the user, the service performs the following steps to validate the code and authenticate the user:¶
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.¶
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.¶
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.¶
This document has no IANA actions.¶