Internet DRAFT - draft-strbac-totp2
draft-strbac-totp2
ietf D. Strbac
Internet-Draft Mercata
Intended status: Informational 23 July 2023
Expires: 24 January 2024
TOTP2 Authentication Scheme
draft-strbac-totp2-00
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.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Strbac Expires 24 January 2024 [Page 1]
Internet-Draft TOTP2 Authentication Scheme July 2023
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Authentication Scheme Overview . . . . . . . . . . . . . . . 4
4. Detailed Scheme Description . . . . . . . . . . . . . . . . . 5
4.1. TOTP2 Registration . . . . . . . . . . . . . . . . . . . 5
4.1.1. Registration URI . . . . . . . . . . . . . . . . . . 5
4.2. Service OTC Generation . . . . . . . . . . . . . . . . . 7
4.3. Service OTC Verification . . . . . . . . . . . . . . . . 7
4.4. Client OTC Generation . . . . . . . . . . . . . . . . . . 8
4.5. Optional Password Entry . . . . . . . . . . . . . . . . . 8
4.6. TOTP2 Code Submission . . . . . . . . . . . . . . . . . . 9
4.7. Authentication . . . . . . . . . . . . . . . . . . . . . 9
5. Recovery Procedure . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
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.
Strbac Expires 24 January 2024 [Page 2]
Internet-Draft TOTP2 Authentication Scheme July 2023
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.
Strbac Expires 24 January 2024 [Page 3]
Internet-Draft TOTP2 Authentication Scheme July 2023
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].
* TOTP: Time-Based One-Time Password, an algorithm that generates
one-time passwords based on a shared secret and the current time.
* Service: The entity or application that requires TOTP codes for
authentication.
* TOTP2: The scheme that enables the secure transmission of TOTP
codes from a TOTP2 authenticator to a service, incorporating two
shared secrets.
* Authenticator: An application installed on a user's device that
verifies, generates, and submits TOTP2 one-time codes.
3. Authentication Scheme Overview
The TOTP2 scheme follows these steps:
* TOTP2 Registration: The user initiates the registration process on
the TOTP2 authenticator by providing the necessary information
provided by the service.
* Service OTC Generation: During authentication with the service,
the service generates an on-screen one-time TOTP code intended for
the user's TOTP2 authenticator.
Strbac Expires 24 January 2024 [Page 4]
Internet-Draft TOTP2 Authentication Scheme July 2023
* Service OTC Verification: The TOTP2 authenticator verifies the
received TOTP code. If the verification fails, the authentication
process is interrupted.
* Client OTC Generation: Using the registered service information
and the provided service one-time code, the TOTP2 authenticator
generates its own TOTP2 one-time code.
* TOTP2 Code Submission: The TOTP2 authenticator securely submits
the generated TOTP2 code to the service.
* Authentication: The service receives the TOTP2 code and verifies
it to complete the authentication flow.
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
Strbac Expires 24 January 2024 [Page 5]
Internet-Draft TOTP2 Authentication Scheme July 2023
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.
Strbac Expires 24 January 2024 [Page 6]
Internet-Draft TOTP2 Authentication Scheme July 2023
* 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:
Strbac Expires 24 January 2024 [Page 7]
Internet-Draft TOTP2 Authentication Scheme July 2023
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.
Strbac Expires 24 January 2024 [Page 8]
Internet-Draft TOTP2 Authentication Scheme July 2023
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:
Strbac Expires 24 January 2024 [Page 9]
Internet-Draft TOTP2 Authentication Scheme July 2023
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.
Strbac Expires 24 January 2024 [Page 10]
Internet-Draft TOTP2 Authentication Scheme July 2023
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:
* Strong Encryption: The side channel communication between the
TOTP2 authenticator and the service should utilize strong
encryption mechanisms. This protects the confidentiality and
integrity of the transmitted data, preventing unauthorized access
or tampering.
* Verification of Service-Generated Code: The service-generated code
provided to the user must be verified to prevent man-in-the-middle
and phishing attacks. Users should carefully validate the code to
ensure they are communicating with the authentic service and not
an imposter.
* Secure Storage of Secrets: Both the service secret and client
secret should be securely stored and protected. Unauthorized
access to these secrets could compromise the security of the TOTP2
authentication process. Measures such as encryption and access
controls should be implemented to safeguard the secrets.
* Validation of TLS Certificate: The TOTP2 client app should
validate the TLS certificate presented by the service. This
ensures that the communication is established with the legitimate
service and helps prevent potential phishing attacks.
* Separate Authenticator and Authenticated Devices: It is
recommended to use separate devices for the TOTP2 authenticator
and the device being authenticated. This reduces the risk of
exposing sensitive authentication information if the same device
is compromised.
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.
Strbac Expires 24 January 2024 [Page 11]
Internet-Draft TOTP2 Authentication Scheme July 2023
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, May 2011,
<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, June 2022,
<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, March 1997,
<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, January 2008,
<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
Email: dejan@mercata.com
Strbac Expires 24 January 2024 [Page 12]
