ietf D. Strbac
Internet-Draft Mercata
Intended status: Informational 23 July 2023
Expires: 24 January 2024
TOTP2 Authentication Scheme draft-strbac-totp2-00
TOTP2認証スキームドラフト-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.
フィッシング攻撃に対する優れた保護を提供するために、タイムベースのワンタイムパスワード（TOTP）メソッドを拡張する第2因子認証スキームを提示します。
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.
ユーザーをサービスで認証する従来のワンタイムパスワードフローとは異なり、当社のアプローチは、ユーザーとサービスの両方を相互にシームレスに認証する拡張フローを導入します。この強化されたプロセスにより、セカンダリおよびセキュアな通信チャネルを介したユーザーの第2因子認証の安全な提出が保証されます。
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.
このインターネットドラフトは、BCP 78および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/.
インターネットドラフトは、インターネットエンジニアリングタスクフォース（IETF）の作業文書です。他のグループは、作業文書をインターネットドラフトとして配布する場合もあることに注意してください。現在のインターネットドラフトのリストは、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."
インターネットドラフトは、最大6か月間有効なドラフトドキュメントであり、いつでも他のドキュメントに更新、交換、または廃止される場合があります。インターネットドラフトを参照資料として使用したり、「進行中の作業」以外に引用することは不適切です。
This Internet-Draft will expire on 24 January 2024.
このインターネットドラフトは、2024年1月24日に期限切れになります。
Copyright Notice
著作権表示
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 IETF Trustおよび文書著者として特定された人。全著作権所有。
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.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/ license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
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
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.
TOTP2認証スキームは、[RFC6238]で定義されている時間ベースのワンタイムパスワード（TOTP）アルゴリズムメソッドに基づいて構築されます。特定のサービスに厳密にリンクした2つのTOTP共有秘密を組み込むことによりセキュリティを強化し、HTTPを介してTOTPコードを安全に転送および検証するメカニズムを提供します。TOTP2は、ユーザーエクスペリエンスを罰することなく、フィッシング攻撃に対する保護の強化を提供します。
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.
TOTP2スキームは、手動コード入力を、TOTP2認証器から直接安全な提出プロセスに置き換えます。2つの1回限りのコードでXOR操作を実行することにより、認証スキームは、画面上の1回限りのコードが潜在的な攻撃者に対して無意味になることを保証します。
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.
認証プロセスは、QRコードの使用と認証器からの自動提出を通じてさらに合理化され、ユーザーエクスペリエンスが簡素化されます。TOTP2認証器は、生成されたコードの通信と提出を容易にするために、アクティブなインターネット接続を必要とします。
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.
「TOTP2」という名前は、TOTPバージョンスキームではなく、TOTP「デュオ」として理解されることを目的としています。この命名の選択は、認証スキームで2つの秘密キーとコードの使用を反映しており、認証プロセスの二重の性質を強調しています。
The usage of two codes in the TOTP2 authentication scheme offers distinct advantages over using a single TOTP code, as outlined below:
TOTP2認証スキームの2つのコードの使用は、以下に概説するように、単一のTOTPコードを使用して明確な利点を提供します。
* 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.
* セッション識別：1回限りのコードを使用して、複数のアクティブセッションを識別および管理できます。各セッションは、一意のワンタイムコードに関連付けられ、複数のセッションの同時認証を可能にすることができます。この機能により、特にユーザーが複数のデバイスまたは場所からサービスにアクセスする必要があるシナリオでは、柔軟性と利便性が向上します。
By incorporating two codes in TOTP2, the authentication process becomes more robust and versatile, providing enhanced security and improved user experience.
TOTP2に2つのコードを組み込むことにより、認証プロセスはより堅牢で汎用性が高くなり、セキュリティが強化され、ユーザーエクスペリエンスが向上します。
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.
攻撃者はその有効性ウィンドウ内でコードを再利用できるため、従来のワンタイムコード検証プロセスはフィッシング攻撃の影響を受けやすくなります。この脅威に対抗するために、TOTP2は、非対話チャネルを使用して1回限りのコードを送信することによりセキュリティを強化します。
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.
TOTP2 Authenticatorからサービスの検証エンドポイントに直接自動化された送信プロセスなどの非対話チャネルを使用することにより、ユーザーは1回限りのコードを手動で入力する必要はありません。これにより、提出プロセス中にコードを潜在的なフィッシング攻撃にさらすリスクが減ります。
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.
非対話チャネルは、1回限りのコードがサービスにしっかりと送信されることを保証し、攻撃者がコードを傍受して再利用する機会の窓を減らします。このアプローチは、TOTP2認証スキームのセキュリティを大幅に強化し、フィッシングの試みに対する保護の増加を提供します。
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].
「必須」、「必須」、「必須」、「「しなければ」、「そうしない」、「そうではない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されていると解釈されます。
* TOTP: Time-Based One-Time Password, an algorithm that generates one-time passwords based on a shared secret and the current time.
* TOTP：時間ベースのワンタイムパスワード。共有された秘密と現在の時刻に基づいて1回限りのパスワードを生成するアルゴリズム。
* Service: The entity or application that requires TOTP codes for authentication.
* サービス：認証にTOTPコードを必要とするエンティティまたはアプリケーション。
* TOTP2: The scheme that enables the secure transmission of TOTP codes from a TOTP2 authenticator to a service, incorporating two shared secrets.
* TOTP2：TOTP2認証器からサービスへのTOTPコードの安全な送信を可能にするスキーム。2つの共有秘密を組み込んでいます。
* Authenticator: An application installed on a user's device that verifies, generates, and submits TOTP2 one-time codes.
* Authenticator：TOTP2ワンタイムコードを検証、生成、および提出するユーザーのデバイスにインストールされたアプリケーション。
The TOTP2 scheme follows these steps:
TOTP2スキームは、これらの手順に従います。
* TOTP2 Registration: The user initiates the registration process on the TOTP2 authenticator by providing the necessary information provided by the service.
* TOTP2登録：ユーザーは、サービスが提供する必要な情報を提供することにより、TOTP2認証器の登録プロセスを開始します。
* 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.
* サービスOTC生成：サービスの認証中に、サービスはユーザーのTOTP2認証器専用の画面上の1回限りのTOTPコードを生成します。
* Service OTC Verification: The TOTP2 authenticator verifies the received TOTP code. If the verification fails, the authentication process is interrupted.
* Service OTC検証：TOTP2 Authenticatorは、受信したTOTPコードを検証します。検証が失敗した場合、認証プロセスが中断されます。
* 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.
* クライアントOTC生成：登録されたサービス情報と提供されたサービス1回限りのコードを使用して、TOTP2 Authenticatorは独自のTOTP2ワンタイムコードを生成します。
* TOTP2 Code Submission: The TOTP2 authenticator securely submits the generated TOTP2 code to the service.
* TOTP2コードの提出：TOTP2 Authenticatorは、生成されたTOTP2コードをサービスにしっかりと送信します。
* Authentication: The service receives the TOTP2 code and verifies it to complete the authentication flow.
* 認証：サービスはTOTP2コードを受信し、認証フローを完了するために検証します。
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.
TOTP2登録プロセスは、ユーザーがTOTP2認証器の登録を開始することから始まります。登録中、ユーザーは、TOTP2コードの提出に「Verification_Endpoint」URIとともに、2つの共有秘密「Service_Secret」と「Client_Secret」を含む、サービスが提供する必要な情報を認証者に提供します。
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.
登録が完了すると、共有された秘密や検証エンドポイントを含む提供された情報は、将来の使用のためにTOTP2認証器にローカルに安全に保存されます。
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.
登録プロセスを簡素化するために、QRコードは一般に情報を認証機に転送するために使用されます。サービス登録情報は、必要なすべてのサービスの詳細を含むQRコード内のOTP URIとしてエンコードされています。
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.
登録情報が提供されると、Authenticatorは共有された各シークレットに対してTOTP OTC（1回限りのコード）を生成します。これらのコードは、XOR操作を使用して組み合わされ、最終的なTOTP2コードになります。この最終コードは、提供されたエンドポイントに提出され、登録プロセスを終了します。
The OTP URI format for TOTP2 service registration is as follows:
TOTP2サービス登録のOTP URI形式は次のとおりです。
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.
otpauth：// totp/label？パラメーターラベルは、キーが関連付けられているアカウントを識別するために使用されます。これには、オプションでそのアカウントの管理を識別する発行者文字列がオプションで付けたアカウント名が含まれています。この発行者プレフィックスは、同じアカウント名、たとえばユーザーのメールアドレスを使用して識別される可能性のある異なるプロバイダーとの異なるアカウント間の衝突を防ぐために使用できます。
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:
発行者のプレフィックスとアカウント名は、文字通りまたはURLエンコードされたコロンで区切る必要があり、オプションのスペースがアカウント名の前に先行する場合があります。発行者もアカウント名もコロンを含むことはできません。[RFC5234]によるABNFの表現は次のとおりです。
label = accountname / issuer (":" / "%3A") *"%20" accountname
Valid values for LABEL might include examples like:
ラベルの有効な値には、次のような例が含まれる場合があります。
* "Example:alice@gmail.com"
* "Provider1:Alice%20Smith"
* 「Provider1：Alice％20smith」
* "Big%20Corporation%3A%20alice%40bigco.com"
* 「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:
TOTP URI形式で提供されるパラメーターには次のものがあります。
* password_entry: A 'yes' or 'no' (default) value, indicating whether the password entry should be made within the authenticator
* password_entry：a '' yes 'または' no '（default）value。
* service_secret: The shared secret used by the service to generate codes for verification in the TOTP client app.
* Service_Secret：TOTPクライアントアプリで検証のためのコードを生成するためにサービスが使用する共有秘密。
* client_secret: The shared secret used by the TOTP client app to generate TOTP codes for verification by the service.
* client_secret：TOTPクライアントアプリが使用する共有秘密は、サービスによる検証のためにTOTPコードを生成します。
* algorithm: The algorithm used for generating the TOTP codes (e.g., SHA1, SHA256).
* アルゴリズム：TOTPコードの生成に使用されるアルゴリズム（SHA1、SHA256など）。
* digits: The number of digits in the generated TOTP codes (e.g., 6, 8).
* 数字：生成されたTOTPコードの数字数（例：6、8）。
* counter: The initial counter value for the TOTP algorithm.
* カウンター：TOTPアルゴリズムの初期カウンター値。
* period: The time period (in seconds) for which a TOTP code is valid.
* 期間：TOTPコードが有効な期間（秒単位）。
* 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.
* 確認_ENDPOINT：TOTPクライアントアプリがクライアントTOTPコードを送信し、以前にサービスコードを受信するURL。「https：//」プロトコルプレフィックスから始める必要があります。
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:
認証リクエストに応じて、サービスはユーザーのアカウントに関連付けられたService Secret（Service_Secret）に基づいて1回限りのコードを生成します。このコードは、認証器のTOTP2要求を含むQRコードを構築するために使用されます。QRコードには、ABNF構文で表される次の値が含まれています。
REQUEST = LABEL (":" / "%3A") *"%20" OTC (":" / "%3A") *"%20" TIMESTAMP
The LABEL SHOULD BE the same as the one provided in the OTP registration URI.
ラベルは、OTP登録URIで提供されているものと同じでなければなりません。
OTC represents the generated TOTP one-time code using the service secret.
OTCは、Service Secretを使用して生成されたTOTPワンタイムコードを表します。
The TIMESTAMP represents a Unix timestamp identifying the time of otc generation.
タイムスタンプは、OTC生成の時間を識別するUNIXタイムスタンプを表しています。
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:
QRコードは、TOTP2リクエストの視覚的表現として機能し、コードをAuthenticatorアプリに簡単に転送できるようにします。有効なリクエストには、次のような例が含まれる場合があります。
* "Example:alice@gmail.com:1689694239"
* "Provider1:Alice%20Smith:1689694239"
* "Big%20Corporation%3A%20alice%40bigco.com: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.
これらの例は、QRコードに含めるためのTOTP2要求内でラベルとワンタイムコードをどのように組み合わせることができるかを示しています。
Upon scanning the QR TOTP2 request with the authenticator application, the authenticator decodes the information contained within.
Authenticatorアプリケーションを使用してQR TOTP2要求をスキャンすると、Authenticatorは内部に含まれる情報を解読します。
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.
認証機は次のアクションを実行します。1。時間同期チェック：認証器は、QRコードから得られたUNIXタイムスタンプを現地時間と比較します。時間差が特定のしきい値を超えて、重要な時間の矛盾を示している場合、認証は失敗します。そのような場合、ユーザーにはシンク外の警告が提示され、時間同期の必要性が示されます。
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.
2. アカウント識別：認証機が複数のアカウントをサポートする場合、TOTP2要求のラベル部分を使用して、対応する登録アカウントを識別します。ラベルは、認証機内のアカウントの一意の識別子として機能します。
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.
3. TOTPコード検証：識別されたアカウントに関連付けられたサービスシークレットを使用して、認証者は提供されたTOTPコードを検証します。TOTPコードは、クライアントの秘密と現在の時刻に基づいて生成されます。
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.
4. 認証結果：登録済みアカウントが正常に識別され、提供されたTOTPコードが検証された場合、認証プロセスは成功し、サービスへのアクセスが付与されます。ただし、ラベルを使用して登録済みアカウントを識別できない場合、または提供されたTOTPコードが確認できない場合、認証プロセスは失敗します。
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.
認証障害の場合、適切なフィードバックがユーザーに提示され、誤ったラベルや無効なTOTPコードなど、障害の理由を示します。
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.
サービスが提供するTOTPワンタイムコードを正常に確認した後、TOTP2認証器は「client_secret」を使用して新しいTOTPワンタイムコードを生成します。次に、Authenticatorは、サービスが提供する1回限りのコードと、新しく生成された1回限りのコードとの間で、ビットワイズXOR操作を実行します。このXOR操作により、新しいTOTP2コードが組み合わされているため、サービスに提出する準備が整いました。
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.
TOTP2スキームは、「オプションのパスワードエントリ」と呼ばれるオプションの機能を提供します。典型的なTOTP実装では、第2因子認証が開始されると、何らかの形の一次認証がすでに発生しています。ただし、フィッシングシナリオでは、TOTP認証が行われる前にユーザーの資格情報が盗まれた可能性があります。
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.
さらにセキュリティを強化するために、TOTP2登録プロセスには「password_entry」パラメーターが含まれています。このパラメーターが存在し、「はい」に設定されている場合、TOTP2認証の後までパスワードエントリが延期されます。
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.
TOTP2 AuthenticatorがTOTP2ワンタイムコードを生成すると、ユーザーにパスワードを入力するように求められます。次に、ユーザーはパスワードを提供し、TOTP2コードとパスワードの両方が最終認証のためにサービスに提出されます。
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.
TOTP2認証後までパスワードエントリを延期することにより、このオプションの機能はセキュリティの追加レイヤーを追加し、初期認証フェーズ中にパスワードを潜在的なフィッシングの試みに公開するリスクを減らします。
The verification URL for TOTP2 code submission follows the format:
TOTP2コードの送信の検証URLは、次の形式に従います。
VERIFICATION_ENDPOINT ("?" / "&") PARAMETERS
The VERIFICATION_ENDPOINT is provided during the TOTP2 registration process, which must begin with the 'https://' protocol prefix.
確認_Endpointは、TOTP2登録プロセス中に提供されます。これは、「https：//」プロトコルプレフィックスから始まる必要があります。
The PARAMETERS included in the verification URL are as follows:
検証URLに含まれるパラメーターは次のとおりです。
* "code": The TOTP2 one-time code generated by the TOTP2 authenticator application.
* 「コード」：TOTP2 Authenticatorアプリケーションによって生成されたTOTP2ワンタイムコード。
* "account": The account name provided during the TOTP2 authenticator registration, present in the TOTP2 OTP URI as label.
* 「アカウント」：TOTP2 Authenticator登録中に提供されたアカウント名、TOTP2 OTP URIにラベルとして存在します。
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.
TOTP2コードの安全な提出を確保するために、TOTP2認証アプリケーションは[RFC9110]で定義されたHTTPSプロトコルを使用してHTTP Getリクエストを行います。信頼されていないHTTPS接続が検出された場合、認証プロセスが失敗する必要があります。
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.
認証の成功は、HTTP 2XXステータスコードを受信することで示されます。メッセージの応答本体を破棄する必要があります。その他のステータスコードは、認証に失敗したことを示します。
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.
ユーザーからTOTP2コードを受信すると、サービスは次の手順を実行してコードを検証し、ユーザーを認証します。1。サービスは、TOTP2コードに関連付けられた対応するアカウントを調べます。
2. Using the shared secrets (service_secret and client_secret), the service calculates its own TOTP2 code.
2. Shared Secrets（service_secret and client_secret）を使用して、サービスは独自のTOTP2コードを計算します。
3. The service compares the calculated code with the received TOTP2 code.
3. このサービスは、計算されたコードを受信したTOTP2コードと比較します。
4. If the codes match, the validation is successful, and the user is considered authenticated.
4. コードが一致する場合、検証は成功し、ユーザーは認証されていると見なされます。
5. The service grants the user access to the requested service or resources.
5. このサービスは、ユーザーに要求されたサービスまたはリソースへのアクセスを許可します。
6. In response to the code submission request, the service sends an HTTP 2xx status code to indicate a successful authentication process.
6. コード送信要求に応じて、サービスはHTTP 2XXステータスコードを送信して、認証プロセスの成功を示します。
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.
TOTP2コードが検証に失敗した場合、ユーザーの画面上の認証フローは失敗を示し、ユーザーはサービスまたはリソースへのアクセスを許可されていません。
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.
認証者は紛失したり、アクセス不能になったりすることができ、サービスプロバイダーがユーザーに信頼できる回復手順を確立することが不可欠です。アカウントの回復プロセスの詳細はプロバイダー間で異なりますが、1つの一般的なアプローチは、TOTP2登録中の回復キーの使用です。
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.
回復キーは二次認証係数として機能し、ユーザーが安全に保存する必要があります。Authenticatorへのアクセスを失う場合、ユーザーはこれらのキーを利用してアカウントアクセスを取り戻すことができます。ただし、回復キーは信頼できるデバイスでのみ使用する必要があることを強調することが重要です。
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:
TOTP2スキームは、認証プロセスの機密性と整合性を確保するために、いくつかのセキュリティ上の考慮事項を導入します。
* 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.
* 強い暗号化：TOTP2認証器とサービスの間のサイドチャネル通信は、強力な暗号化メカニズムを利用する必要があります。これにより、送信されたデータの機密性と完全性が保護され、不正アクセスや改ざんが妨げられます。
* 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.
* 秘密の安全な保管：Service SecretとClient Secretの両方を安全に保存して保護する必要があります。これらの秘密への不正アクセスは、TOTP2認証プロセスのセキュリティを損なう可能性があります。暗号化やアクセス制御などの測定値を実装して、秘密を保護する必要があります。
* 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.
* TLS証明書の検証：TOTP2クライアントアプリは、サービスによって提示されたTLS証明書を検証する必要があります。これにより、コミュニケーションが正当なサービスとともに確立され、潜在的なフィッシング攻撃を防ぐことができます。
* 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.
* 個別の認証機と認証されたデバイス：TOTP2認証機と認証されているデバイスに個別のデバイスを使用することをお勧めします。これにより、同じデバイスが侵害された場合、機密認証情報を公開するリスクが減ります。
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.
これらのセキュリティに関する考慮事項に対処することにより、サービスプロバイダーはTOTP2認証プロセスの全体的なセキュリティを強化し、ユーザーアカウントを不正アクセスや攻撃から保護できます。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[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>.
[RFC6238] M'Raihi、D.、Machani、S.、Pei、M。、およびJ. Rydell、「TOTP：TIMEベースの1回限りのパスワードアルゴリズム」、RFC 6238、DOI 10.17487/RFC6238、2011年5月、<https://ww.rfc-editor.org/-rfc/-rfc/-rfc/.or
[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>.
[RFC9110] Fielding、R.、ed。、Nottingham、M.、ed。、およびJ. Reschke、ed。、 "HTTP Semantics"、Std 97、RFC 9110、doi 10.17487/RFC9110、2022年6月、<https://ww.rfc-editor.org/-rfc/-rfc/-rfc/
[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>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<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>.
[RFC5234] Crocker、D.、ed。P. Overell、「構文仕様のための拡張BNF：ABNF：STD 68、RFC 5234、DOI 10.17487/RFC5234、2008年1月、<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
Dejan Strbac Mercata Sagl経由のE. Bosia 5c。CH-6900 Paradiso Switzerland電話：41-78-6144568メール：dejan@mercata.com
Strbac Expires 24 January 2024 [Page 12]
STRBACは2024年1月24日に期限切れになります[12ページ]