[要約] RFC 6560は、ワンタイムパスワード（OTP）の事前認証に関する標準仕様です。その目的は、OTPを使用してユーザーの認証を強化し、セキュリティを向上させることです。
Internet Engineering Task Force (IETF) G. Richards
Request for Comments: 6560 RSA, The Security Division of EMC
Category: Standards Track April 2012
ISSN: 2070-1721
One-Time Password (OTP) Pre-Authentication
ワンタイムパスワード（OTP）事前認証
Abstract
概要
The Kerberos protocol provides a framework authenticating a client using the exchange of pre-authentication data. This document describes the use of this framework to carry out One-Time Password (OTP) authentication.
Kerberosプロトコルは、事前認証データの交換を使用してクライアントを認証するフレームワークを提供します。このドキュメントでは、このフレームワークを使用してワンタイムパスワード（OTP）認証を実行する方法について説明します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6560.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6560で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。この素材の一部の著作権を管理する人は、IETFトラストにそのような素材の変更を許可する権利を付与していない可能性がありますIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得しない限り、このドキュメントはIETF標準プロセス外で変更できません。また、その派生物は、IETF標準プロセス外で作成できません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Scope ......................................................3
1.2. Overall Design .............................................3
1.3. Conventions Used in This Document ..........................4
2. Usage Overview ..................................................4
2.1. OTP Mechanism Support ......................................4
2.2. Pre-Authentication .........................................4
2.3. PIN Change .................................................5
2.4. Resynchronization ..........................................6
3. Pre-Authentication Protocol Details .............................6
3.1. Initial Client Request .....................................6
3.2. KDC Challenge ..............................................7
3.3. Client Response ............................................9
3.4. Verifying the Pre-Authentication Data .....................13
3.5. Confirming the Reply Key Change ...........................15
3.6. Reply Key Generation ......................................15
4. OTP Kerberos Message Types .....................................17
4.1. PA-OTP-CHALLENGE ..........................................17
4.2. PA-OTP-REQUEST ............................................21
4.3. PA-OTP-PIN-CHANGE .........................................25
5. IANA Considerations ............................................26
6. Security Considerations ........................................27
6.1. Man-in-the-Middle Attacks .................................27
6.2. Reflection ................................................28
6.3. Denial-of-Service Attacks .................................28
6.4. Replay ....................................................29
6.5. Brute-Force Attack ........................................29
6.6. FAST Facilities ...........................................30
8. Acknowledgments ................................................30
8. References .....................................................31
8.1. Normative References ......................................31
8.2. Informative References ....................................32
Appendix A. ASN.1 Module ....................................... 33
Appendix B. Examples of OTP Pre-Authentication Exchanges ........ 36
B.1. Four-Pass Authentication ................................. 36
B.2. Two-Pass Authentication ................................. 38
B.3. PIN Change ............................................... 40
B.4. Resynchronization ....................................... 41
This document describes a Flexible Authentication Secure Tunneling (FAST) [RFC6113] factor that allows One-Time Password (OTP) values to be used in the Kerberos V5 [RFC4120] pre-authentication in a manner that does not require use of the user's Kerberos password. The system is designed to work with different types of OTP algorithms such as time-based OTPs [RFC2808], counter-based tokens [RFC4226] and challenge-response systems such as [RFC2289]. It is also designed to work with tokens that are electronically connected to the user's computer via means such as a USB interface.
このドキュメントでは、ユーザーのKerberosの使用を必要としない方法でKerberos V5 [RFC4120]事前認証でワンタイムパスワード（OTP）値を使用できるようにする柔軟な認証セキュアトンネリング（FAST）[RFC6113]要素について説明しますパスワード。このシステムは、時間ベースのOTP [RFC2808]、カウンターベースのトークン[RFC4226]、[RFC2289]などのチャレンジ/レスポンスシステムなど、さまざまなタイプのOTPアルゴリズムで機能するように設計されています。また、USBインターフェイスなどの手段を介してユーザーのコンピューターに電子的に接続されているトークンを使用するように設計されています。
This FAST factor provides the following facilities (as defined in [RFC6113]): client-authentication, replacing-reply-key, and KDC-authentication. It does not provide the strengthening-reply-key facility.
このFAST要素は、（[RFC6113]で定義されている）次の機能を提供します：クライアント認証、置換応答キー、およびKDC認証。それは強化応答キー機能を提供しません。
This proposal is partially based upon previous work on integrating single-use authentication mechanisms into Kerberos [HORENEZ004].
この提案は、使い捨て認証メカニズムをKerberos [HORENEZ004]に統合する以前の作業に部分的に基づいています。
This proposal supports four- and two-pass variants. In the four-pass system, the client sends the Key Distribution Center (KDC) an initial AS-REQ, and the KDC responds with a KRB-ERROR containing pre-authentication data that includes a random nonce. The client then encrypts the nonce and returns it to the KDC in a second AS-REQ. Finally, the KDC returns the AS-REP. In the two-pass variant, the client encrypts a timestamp rather than a nonce from the KDC, and the encrypted data is sent to the KDC in the initial AS-REQ. The two-pass system can be used in cases where the client can determine in advance that OTP pre-authentication is supported by the KDC, which OTP key should be used and the encryption parameters required by the KDC.
この提案は、4パスと2パスのバリアントをサポートしています。 4パスシステムでは、クライアントはキー配布センター（KDC）に最初のAS-REQを送信し、KDCはランダムなナンスを含む事前認証データを含むKRB-ERRORで応答します。次に、クライアントはノンスを暗号化し、2番目のAS-REQでKDCに返します。最後に、KDCはAS-REPを返します。 2パスバリアントでは、クライアントはKDCからのナンスではなくタイムスタンプを暗号化し、暗号化されたデータは最初のAS-REQでKDCに送信されます。 2パスシステムは、クライアントがODC事前認証がKDCによってサポートされていることを事前に判別できる場合に使用できます。どのOTPキーを使用するか、およびKDCが必要とする暗号化パラメーターを使用できます。
In both systems, in order to create the message sent to the KDC, the client must generate the OTP value and two keys: the classic Reply Key used to decrypt the KDC's reply and a key to encrypt the data sent to the KDC. In most cases, the OTP value will be used in the key generation, but in order to support algorithms where the KDC cannot obtain the value (e.g., [RFC2289]), the system supports the option of including the OTP value in the request along with the encrypted nonce. In addition, in order to support situations where the KDC is unable to obtain the plaintext OTP value, the system also supports the use of hashed OTP values in the key derivation.
どちらのシステムでも、KDCに送信されるメッセージを作成するために、クライアントはOTP値と2つのキーを生成する必要があります。KDCの応答の復号化に使用される従来の応答キーと、KDCに送信されるデータを暗号化するためのキーです。ほとんどの場合、OTP値はキー生成で使用されますが、KDCが値を取得できないアルゴリズム（たとえば、[RFC2289]）をサポートするために、システムはOTP値をリクエストに含めるオプションをサポートします。暗号化されたナンスで。さらに、KDCが平文OTP値を取得できない状況をサポートするために、システムは、キーの導出でのハッシュOTP値の使用もサポートしています。
The pre-authentication data sent from the client to the KDC is sent within the encrypted data provided by the FAST pre-authentication data type of the AS-REQ. The KDC then obtains the OTP value, generates the same keys, and verifies the pre-authentication data by decrypting the nonce. If the verification succeeds, then it confirms knowledge of the Reply Key by using it to encrypt data in the AS-REP.
クライアントからKDCに送信される事前認証データは、AS-REQのFAST事前認証データタイプによって提供される暗号化されたデータ内で送信されます。次に、KDCはOTP値を取得し、同じ鍵を生成し、ナンスを復号化して事前認証データを検証します。検証が成功した場合、AS-REPでデータを暗号化するために使用して、返信キーの知識を確認します。
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This document assumes familiarity with the Kerberos pre-authentication framework [RFC6113] and so freely uses terminology and notation from that document.
このドキュメントは、Kerberos事前認証フレームワーク[RFC6113]に精通していることを前提としているため、そのドキュメントの用語と表記を自由に使用します。
The word padata is used as shorthand for pre-authentication data.
padataという単語は、事前認証データの省略形として使用されます。
As described above, this document describes a generic system for supporting different OTP mechanisms in Kerberos pre-authentication. To ensure interoperability, all implementations of this specification SHOULD provide a mechanism (e.g., a provider interface) to add or remove support for a particular OTP mechanism.
上記のように、このドキュメントでは、Kerberos事前認証でさまざまなOTPメカニズムをサポートするための一般的なシステムについて説明します。相互運用性を確保するために、この仕様のすべての実装は、特定のOTPメカニズムのサポートを追加または削除するメカニズム（プロバイダーインターフェースなど）を提供する必要があります（SHOULD）。
The approach uses pre-authentication data in AS-REQ, AS-REP, and KRB-ERROR messages.
このアプローチでは、AS-REQ、AS-REP、およびKRB-ERRORメッセージで事前認証データを使用します。
In the four-pass system, the client begins by sending an initial AS-REQ to the KDC that may contain pre-authentication data such as the standard Kerberos password data. The KDC will then determine, in an implementation dependent fashion, whether OTP authentication is required and if it is, it will respond with a KRB-ERROR message containing a PA-OTP-CHALLENGE (see Section 4.1) in the PA-DATA.
4パスシステムでは、クライアントは、最初のAS-REQをKDCに送信することから始めます。これには、標準のKerberosパスワードデータなどの事前認証データが含まれている場合があります。次に、KDCは実装依存の方法でOTP認証が必要かどうかを判断し、必要な場合は、PA-DATAにPA-OTP-CHALLENGE（セクション4.1を参照）を含むKRB-ERRORメッセージで応答します。
The PA-OTP-CHALLENGE will contain a KDC-generated nonce, a list of hash algorithm identifiers, and an iteration count if hashed OTP values are used (see Section 3.6) and OPTIONAL information on how the OTP should be generated by the client. The client will then generate the OTP value and two keys: a Client Key to encrypt the KDC's nonce and a Reply Key used to decrypt the KDC's reply.
PA-OTP-CHALLENGEには、KDCで生成されたナンス、ハッシュアルゴリズム識別子のリスト、ハッシュされたOTP値が使用されている場合の反復回数（セクション3.6を参照）、およびクライアントによるOTPの生成方法に関するオプション情報が含まれます。次に、クライアントはOTP値と2つのキーを生成します。KDCのナンスを暗号化するクライアントキーと、KDCの応答を復号化するために使用される応答キーです。
As described in Section 5.4.1 of [RFC6113], the FAST system uses an Armor Key to set up an encrypted tunnel for use by FAST factors. As described in Section 3.6 of this document, the Client Key and Reply Key will be generated from the Armor Key and the OTP value, unless the OTP algorithm does not allow the KDC to obtain the OTP value. If hash algorithm identifiers were included in the PA-OTP-CHALLENGE, then the client will use the hash of the OTP value rather than the plaintext value in the key generation. Both keys will have the same encryption type as the Armor Key.
[RFC6113]のセクション5.4.1で説明されているように、FASTシステムはアーマーキーを使用して、FASTファクターが使用する暗号化されたトンネルをセットアップします。このドキュメントのセクション3.6で説明されているように、OTPアルゴリズムでKDCがOTP値を取得できない場合を除き、クライアントキーと応答キーはアーマーキーとOTP値から生成されます。ハッシュアルゴリズム識別子がPA-OTP-CHALLENGEに含まれている場合、クライアントは、キー生成でプレーンテキスト値ではなくOTP値のハッシュを使用します。両方のキーは、アーマーキーと同じ暗号化タイプになります。
The generated Client Key will be used to encrypt the nonce received from the KDC. The encrypted value along with optional information on how the OTP was generated are then sent to the KDC in a PA-OTP-REQUEST (see Section 4.2) encrypted within the armored-data of a PA-FX-FAST-REQUEST PA-DATA element of a second AS-REQ.
生成されたクライアントキーは、KDCから受信したナンスを暗号化するために使用されます。暗号化された値は、OTPの生成方法に関するオプション情報とともに、PA-FX-FAST-REQUEST PA-DATA要素のarmored-data内で暗号化されたPA-OTP-REQUEST（セクション4.2を参照）でKDCに送信されます。 2番目のAS-REQの。
In the two-pass system, the client sends the PA-OTP-REQUEST in the initial AS-REQ instead of sending it in response to a PA-OTP-CHALLENGE returned by the KDC. Since no challenge is received from the KDC, the client includes an encrypted timestamp in the request rather than the encrypted KDC nonce.
2パスシステムでは、クライアントは、KDCから返されたPA-OTP-CHALLENGEに応答して送信する代わりに、初期AS-REQでPA-OTP-REQUESTを送信します。チャレンジはKDCから受信されないため、クライアントは、暗号化されたKDCナンスではなく、暗号化されたタイムスタンプを要求に含めます。
In both cases, on receipt of a PA-OTP-REQUEST, the KDC generates the keys in the same way as the client, and uses the generated Client Key to verify the pre-authentication by decrypting the encrypted data sent by the client (either nonce or timestamp). If the validation succeeds, then the KDC will authenticate itself to the client and confirm that the Reply Key has been updated by using the generated Reply Key in the AS-REP response.
どちらの場合も、PA-OTP-REQUESTを受信すると、KDCはクライアントと同じ方法でキーを生成し、生成されたクライアントキーを使用して、クライアントから送信された暗号化データを復号化して事前認証を確認します（いずれか）ナンスまたはタイムスタンプ）。検証が成功すると、KDCはクライアントに対して自身を認証し、AS-REP応答で生成された返信キーを使用して返信キーが更新されたことを確認します。
Most OTP tokens involve the use of a Personal Identification Number (PIN) in the generation of the OTP value. This PIN value will be combined with the value generated by the token to produce the final OTP value that will be used in this protocol.
ほとんどのOTPトークンでは、OTP値の生成に個人識別番号（PIN）を使用します。このPIN値は、トークンによって生成された値と組み合わされて、このプロトコルで使用される最終的なOTP値を生成します。
If, following successful validation of a PA-OTP-REQUEST in an AS-REQ, the KDC determines that the user's PIN has expired and needs to change, then it SHOULD respond with a KRB-ERROR of type KDC_ERR_PIN_EXPIRED. It MAY include formatting information on the PIN in a PA-OTP-PIN-CHANGE (see Section 4.3) encrypted within the armored-data of the PA-FX-FAST-REPLY PA-DATA element.
AS-REQ内のPA-OTP-REQUESTの検証が成功した後、KDCがユーザーのPINの有効期限が切れて変更する必要があると判断した場合、KDCはタイプKDC_ERR_PIN_EXPIREDのKRB-ERRORで応答する必要があります。 PA-FX-FAST-REPLY PA-DATA要素のarmored-data内で暗号化されたPA-OTP-PIN-CHANGE（セクション4.3を参照）のPINに関するフォーマット情報を含めることができます（MAY）。
KDC_ERR_PIN_EXPIRED 96
KDC_ERR_PIN_EXPIRED 96
If the PIN change is to be handled by a PIN-change service, then it is assumed that authentication to that service will succeed if the PIN has expired.
PINの変更がPIN変更サービスによって処理される場合、PINの有効期限が切れていれば、そのサービスに対する認証が成功すると見なされます。
If the user's PIN has not expired but has been changed, then the KDC MAY return the new value to the client in a PA-OTP-PIN-CHANGE encrypted within the armored-data of the PA-FX-FAST-REPLY PA-DATA element of the AS-REP. Similarly, if a PIN change is not required, then the KDC MAY return a PA-OTP-PIN-CHANGE to inform the client of the current PIN's expiration time.
ユーザーのPINの有効期限が切れていないが変更されている場合、KDCは、PA-FX-FAST-REPLY PA-DATAのarmored-data内で暗号化されたPA-OTP-PIN-CHANGEでクライアントに新しい値を返す場合があります。 AS-REPの要素。同様に、PINの変更が不要な場合、KDCはPA-OTP-PIN-CHANGEを返して、現在のPINの有効期限をクライアントに通知できます（MAY）。
It is possible with time- and event-based tokens that the OTP server will lose synchronization with the current token state. For example, event-based tokens may drift since the counter on the token is incremented every time the token is used, but the counter on the server is only incremented on an authentication. Similarly, the clocks on time-based tokens may drift.
時間ベースおよびイベントベースのトークンでは、OTPサーバーが現在のトークンの状態との同期を失う可能性があります。たとえば、トークンが使用されるたびにトークンのカウンターが増分されるため、イベントベースのトークンはドリフトする可能性がありますが、サーバーのカウンターは認証時にのみ増分されます。同様に、時間ベースのトークンのクロックはずれている可能性があります。
Methods to recover from this type of situation are OTP algorithm-specific but may involve the client sending a sequence of OTP values to allow the server to further validate the correct position in its search window (see Section 7.4 of [RFC4226] for an example).
このタイプの状況から回復する方法はOTPアルゴリズム固有ですが、クライアントが一連のOTP値を送信して、サーバーが検索ウィンドウ内の正しい位置をさらに検証できるようにする場合があります（[RFC4226]のセクション7.4の例を参照）。 。
If, when processing a PA-OTP-REQUEST, the pre-authentication validation fails for this reason, then the KDC MAY return a KRB-ERROR message. The KRB-ERROR message MAY contain a PA-OTP-CHALLENGE in the PA-DATA with a single otp-tokenInfo representing the token used in the initial authentication attempt but with the "nextOTP" flag set. If this flag is set, then the client SHOULD re-try the authentication using an OTP value generated using the token in the "state" after that used in the failed authentication attempt, for example, using the next time interval or counter value.
PA-OTP-REQUESTを処理するときに、この理由で事前認証の検証が失敗した場合、KDCはKRB-ERRORメッセージを返す場合があります。 KRB-ERRORメッセージには、PA-DATAにPA-OTP-CHALLENGEが含まれている場合があり、最初の認証試行で使用されたトークンを表す単一のotp-tokenInfoが "nextOTP"フラグが設定されています。このフラグが設定されている場合、クライアントは、「状態」のトークンを使用して生成されたOTP値を使用して認証を再試行する必要があります（SHOULD）。
In the four-pass mode, the client begins by sending an initial AS-REQ, possibly containing other pre-authentication data. If the KDC determines that OTP-based pre-authentication is required and the request does not contain a PA-OTP-REQUEST, then it will respond as described in Section 3.2.
4パスモードでは、クライアントは最初にAS-REQを送信することから始めます。おそらく、他の事前認証データが含まれています。 KDCがOTPベースの事前認証が必要であると判断し、リクエストにPA-OTP-REQUESTが含まれていない場合、セクション3.2で説明されているように応答します。
If the client has all the necessary information, it MAY use the two-pass system by constructing a PA-OTP-REQUEST as described in Section 3.3 and including it in the initial request.
クライアントが必要な情報をすべて持っている場合は、セクション3.3で説明されているようにPA-OTP-REQUESTを作成し、それを最初のリクエストに含めることにより、2パスシステムを使用できます。
If the user is required to authenticate using an OTP, then the KDC SHALL respond to the initial AS-REQ with a KRB-ERROR (as described in Section 2.2 of [RFC6113]), with a PA-OTP-CHALLENGE contained within the enc-fast-rep of the armored-data of a PA-FX-FAST-REPLY encrypted under the current Armor Key as described in [RFC6113].
ユーザーがOTPを使用して認証する必要がある場合、KDCは初期AS-REQにKRB-ERRORで応答する必要があります（[RFC6113]のセクション2.2に記載）。enc内にPA-OTP-CHALLENGEが含まれています。 [RFC6113]で説明されているように、現在のアーマーキーで暗号化されたPA-FX-FAST-REPLYのアーマードデータの-fast-rep。
If the OTP mechanism is to be carried out as an individual mechanism, then the PA-OTP-CHALLENGE SHALL be carried within the padata of the KrbFastResponse. Alternatively, if the OTP mechanism is required as part of an authentication set, then the PA-OTP-CHALLENGE SHALL be carried within a PA-AUTHENTICATION-SET-ELEM as described in Section 5.3 of [RFC6113].
OTPメカニズムが個別のメカニズムとして実行される場合、PA-OTP-CHALLENGEはKrbFastResponseのpadata内で実行される必要があります。あるいは、OTPメカニズムが認証セットの一部として必要な場合、PA-OTP-CHALLENGEは、[RFC6113]のセクション5.3で説明されているように、PA-AUTHENTICATION-SET-ELEM内で実行される必要があります。
The PA-OTP-CHALLENGE SHALL contain a nonce value to be returned encrypted in the client's PA-OTP-REQUEST. This nonce string MUST contain a randomly chosen component at least as long as the Armor Key length (see [RFC4086] for an in-depth discussion of randomness). In order to allow it to maintain any state necessary to verify the returned nonce, the KDC SHOULD use the mechanism described in Section 5.2 of [RFC6113].
PA-OTP-CHALLENGEには、クライアントのPA-OTP-REQUESTで暗号化されて返されるnonce値が含まれている必要があります（SHALL）。このノンス文字列には、少なくともアーマーキーの長さと同じくらいランダムに選択されたコンポーネントが含まれている必要があります（ランダム性の詳細については、[RFC4086]を参照してください）。返されたナンスを検証するために必要な状態を維持できるようにするために、KDCは[RFC6113]のセクション5.2で説明されているメカニズムを使用する必要があります（SHOULD）。
The KDC MAY use the otp-service field to assist the client in locating the OTP token to be used by identifying the purpose of the authentication. For example, the otp-service field could assist a user in identifying the token to be used when a user has multiple OTP tokens that are used for different purposes. If the token is a connected device, then these values SHOULD be an exact octet-level match for the values present on the target token.
KDCは、otp-serviceフィールドを使用して、クライアントが認証の目的を識別することによって使用されるOTPトークンを見つけるのを支援することができます。たとえば、otp-serviceフィールドは、ユーザーがさまざまな目的で使用される複数のOTPトークンを持っている場合に、使用されるトークンをユーザーが識別するのを支援します。トークンが接続されたデバイスである場合、これらの値は、ターゲットトークンに存在する値と正確にオクテットレベルで一致する必要があります（SHOULD）。
The KDC SHALL include a sequence of one or more otp-tokenInfo elements containing information on the token or tokens that the user can use for the authentication and how the OTP value is to be generated using those tokens. If a single otp-tokenInfo element is included, then only a single token is acceptable by the KDC, and any OTP value generated by the client MUST be generated according to the information contained within that element. If more than one otp-tokenInfo element is included, then the OTP value MUST be generated according to the information contained within one of those elements.
KDCは、ユーザーが認証に使用できる1つまたは複数のトークンに関する情報と、それらのトークンを使用してOTP値を生成する方法を含む1つ以上のotp-tokenInfo要素のシーケンスを含む必要があります（SHALL）。単一のotp-tokenInfo要素が含まれている場合、単一のトークンのみがKDCによって受け入れられ、クライアントによって生成されるOTP値は、その要素内に含まれる情報に従って生成される必要があります。複数のotp-tokenInfo要素が含まれている場合、OTP値は、それらの要素の1つに含まれる情報に従って生成される必要があります。
The KDC MAY include the otp-vendor field in an otp-tokenInfo to identify the vendor of the token that can be used in the authentication request in order to assist the client in locating that token.
KDCは、otp-tokenInfoにotp-vendorフィールドを含めて、クライアントがそのトークンを見つけるのを支援するために認証要求で使用できるトークンのベンダーを識別してもよい（MAY）。
If the KDC is able to obtain the OTP values for the token, then the OTP value SHOULD be used in the key generation as described in Section 3.6; therefore, the KDC SHOULD set the "must-encrypt-nonce" flag in the otp-tokenInfo. If the KDC is unable to obtain the OTP values for the token, then the "must-encrypt-nonce" flag MUST NOT be set. If the flag is not set, then the OTP value will be returned by the client in the otp-value field of the PA-OTP-REQUEST and so, if returning of OTP values in this way does not conform to KDC policy, then the KDC SHOULD NOT include the otp-tokenInfo for that token in the PA-OTP-CHALLENGE.
KDCがトークンのOTP値を取得できる場合は、セクション3.6で説明されているように、OTP値をキー生成で使用する必要があります（SHOULD）。したがって、KDCはotp-tokenInfoに「must-encrypt-nonce」フラグを設定する必要があります（SHOULD）。 KDCがトークンのOTP値を取得できない場合、「must-encrypt-nonce」フラグを設定してはなりません（MUST NOT）。フラグが設定されていない場合、OTP値はクライアントによってPA-OTP-REQUESTのotp-valueフィールドに返されるため、この方法でOTP値を返すことがKDCポリシーに準拠していない場合、 KDCは、そのトークンのotp-tokenInfoをPA-OTP-CHALLENGEに含めないでください。
If the KDC requires that hashed OTPs be used in the key generation as described in Section 3.6 (for example, it is only able to obtain hashed OTP values for the token), then it MUST include the supported hash algorithms in order of preference in the supportedHashAlg of the otp-KeyInfo and the minimum value of the iteration count in the iterationCount element.
KDCがセクション3.6で説明されているようにキー生成でハッシュOTPを使用する必要がある場合（たとえば、トークンのハッシュOTP値しか取得できない場合）、サポートされているハッシュアルゴリズムを優先順に含める必要があります。 otp-KeyInfoのsupportedHashAlgおよびiterationCount要素の反復回数の最小値。
Since the OTP mechanism described in this document is replacing the Reply Key, the classic shared-key system cannot be relied upon to allow the client to verify the KDC. Therefore, as described in Section 3.4 of [RFC6113], some other mechanism must be provided to support this. If the OTP value is used in the Reply Key generation, then the client and KDC have a shared key and KDC-authentication is provided by the KDC using the Reply Key generated from the OTP value. However, if the OTP value is sent in the otp-value element of the PA-OTP-REQUEST, then there is no such shared key and the OTP mechanism does not provide KDC-authentication. Therefore, if the OTP mechanism is not being used in an environment where KDC-authentication is being provided by other means (e.g., by the use of a host-key-based Armor Key), then the KDC MUST NOT include any otp-tokenInfo elements in the PA-OTP-CHALLENGE that do not have the "must-encrypt-nonce" flag set.
このドキュメントで説明されているOTPメカニズムは返信キーに代わるものであるため、クライアントがKDCを検証できるようにするために、従来の共有キーシステムに依存することはできません。したがって、[RFC6113]のセクション3.4で説明されているように、これをサポートするには他のメカニズムを提供する必要があります。返信キーの生成でOTP値が使用される場合、クライアントとKDCは共有キーを持ち、OTC値から生成された返信キーを使用してKDCによってKDC認証が提供されます。ただし、PA-OTP-REQUESTのotp-value要素でOTP値が送信される場合、そのような共有キーはなく、OTPメカニズムはKDC認証を提供しません。したがって、OTCメカニズムがKDC認証が他の手段（たとえば、ホストキーベースのアーマーキーの使用）によって提供されている環境で使用されていない場合、KDCはotp-tokenInfoを含めてはなりません（MUST NOT） 「must-encrypt-nonce」フラグが設定されていないPA-OTP-CHALLENGEの要素。
If the OTP for a token is to be generated using a server-generated challenge, then the value of the challenge SHALL be included in the otp-challenge field of the otp-tokenInfo for that token. If the token is a connected device and the OTP is to be generated by combining the challenge with the token's current state (e.g., time), then the "combine" flag SHALL be set within the otp-tokenInfo containing the challenge.
トークンのOTPがサーバー生成チャレンジを使用して生成される場合、チャレンジの値は、そのトークンのotp-tokenInfoのotp-challengeフィールドに含まれる必要があります（SHALL）。トークンが接続されたデバイスであり、OTPがチャレンジとトークンの現在の状態（たとえば、時間）を組み合わせて生成される場合、チャレンジを含むotp-tokenInfo内に「結合」フラグを設定する必要があります（SHALL）。
If the KDC can determine which OTP token key (the seed value on the token used to generate the OTP) is to be used, then the otp-tokenID field MAY be included in the otp-tokenInfo to pass that value to the client.
KDCが使用するOTPトークンキー（OTPの生成に使用されるトークンのシード値）を決定できる場合は、otp-tokenIDフィールドをotp-tokenInfoに含めて、その値をクライアントに渡すことができます（MAY）。
The otp-algID field MAY be included in an otp-tokenInfo to identify the algorithm that should be used in the OTP calculation for that token. For example, it could be used when a user has been issued with multiple tokens that support different algorithms.
otp-algIDフィールドをotp-tokenInfoに含めて、そのトークンのOTP計算で使用する必要があるアルゴリズムを識別してもよい（MAY）。たとえば、ユーザーが異なるアルゴリズムをサポートする複数のトークンで発行された場合に使用できます。
If the KDC can determine that an OTP token that can be used by the user does not require the client to collect a PIN, then it SHOULD set the "do-not-collect-pin" flag in the otp-tokenInfo representing that token. If the KDC can determine that the token requires the client to collect a PIN, then it SHOULD set the "collect-pin" flag. If the KDC is unable to determine whether or not the client should collect a PIN, then the "collect-pin" and "do-not-collect-pin" flags MUST NOT be set.
KDCが、ユーザーが使用できるOTPトークンでクライアントがPINを収集する必要がないと判断できる場合、そのトークンを表すotp-tokenInfoに「do-not-collect-pin」フラグを設定する必要があります。トークンがクライアントにPINを収集する必要があるとKDCが判断できる場合は、「collect-pin」フラグを設定する必要があります（SHOULD）。 KDCがクライアントがPINを収集する必要があるかどうかを判断できない場合、「collect-pin」および「do-not-collect-pin」フラグを設定してはなりません（MUST NOT）。
If the KDC requires the PIN of an OTP token to be returned to it separately, then it SHOULD set the "separate-pin-required" flag in the otp-KeyInfo representing that token.
KDCがOTPトークンのPINを個別に返す必要がある場合は、そのトークンを表すotp-KeyInfoに「separate-pin-required」フラグを設定する必要があります（SHOULD）。
If the KDC requires that the OTPs generated by the token have a Luhn check digit appended, as defined in [ISOIEC7812], then it MUST set the "check-digit" flag. This flag only applies if the format of the OTP is decimal; therefore, the otp-format field, if present, MUST have the value of "decimal".
[ISOIEC7812]で定義されているように、KDCがトークンによって生成されたOTPにLuhnチェックディジットを追加する必要がある場合、「チェックディジット」フラグを設定する必要があります。このフラグは、OTPの形式が10進数の場合にのみ適用されます。したがって、otp-formatフィールドが存在する場合、「decimal」の値が必要です。
Finally, in order to support connected tokens that can generate OTP values of varying lengths or formats, the KDC MAY include the desired otp-length and format of the OTP in the otp-length and otp-format fields of an otp-tokenInfo.
最後に、さまざまな長さまたは形式のOTP値を生成できる接続されたトークンをサポートするために、KDCは、otp-tokenInfoのotp-lengthおよびotp-formatフィールドにOTPの望ましいotp-lengthおよび形式を含めることができます（MAY）。
The client response SHALL be sent to the KDC as a PA-OTP-REQUEST included within the enc-fast-req of the armored-data within a PA-FX-FAST-REQUEST encrypted under the current Armor Key as described in [RFC6113].
[RFC6113]で説明されているように、現在のアーマーキーで暗号化されたPA-FX-FAST-REQUEST内のアーマードデータのenc-fast-reqに含まれるPA-OTP-REQUESTとしてクライアント応答をKDCに送信する必要があります（SHALL）。 。
In order to generate its response, the client MUST generate an OTP value. If the PA-OTP-CHALLENGE contained one or more otp-tokenInfo elements, then the OTP value MUST be based on the information contained within one of those elements.
その応答を生成するために、クライアントはOTP値を生成する必要があります。 PA-OTP-CHALLENGEに1つ以上のotp-tokenInfo要素が含まれる場合、OTP値はこれらの要素の1つに含まれる情報に基づいている必要があります。
The otp-service, otp-vendor, otp-tokenID, otp-length, otp-format, and otp-algID elements of the PA-OTP-CHALLENGE are provided by the KDC to assist the client in locating the correct token to use, but the use of the above fields will depend on the type of token.
PA-OTP-CHALLENGEのotp-service、otp-vendor、otp-tokenID、otp-length、otp-format、およびotp-algID要素は、クライアントが使用する正しいトークンを見つけるのを支援するためにKDCによって提供されます。ただし、上記のフィールドの使用は、トークンのタイプによって異なります。
If the token is a disconnected device, then the values of otp-service and otp-vendor MAY be displayed to the user in order to help the user select the correct token, and the values of otp-algID, otp-tokenID, otp-length, and otp-format MAY be ignored.
トークンが切断されたデバイスである場合、ユーザーが正しいトークンを選択できるようにotp-serviceとotp-vendorの値を表示できます（otp-algID、otp-tokenID、otp-の値）。長さ、およびotp-formatは無視される場合があります。
If the token is a connected device, then these values, if present, SHOULD be used by the client to locate the correct token. When the token is connected, clients MUST support matching based on a binary comparison of the otp-vendor and otp-service strings when comparing the values against those present on the token. Clients MAY have other comparisons including normalization insensitive comparisons to try and find the right token. The values of otp-vendor and otp-service MAY be displayed to prompt the user if the correct token is not found.
トークンが接続されたデバイスである場合、これらの値が存在する場合は、正しいトークンを見つけるためにクライアントが使用する必要があります（SHOULD）。トークンが接続されている場合、クライアントは、値をトークンに存在するものと比較するときに、otp-vendorとotp-service文字列のバイナリ比較に基づくマッチングをサポートする必要があります。クライアントは、正規化に依存しない比較を含む他の比較を行って、正しいトークンを見つけようとする場合があります。 otp-vendorとotp-serviceの値を表示して、正しいトークンが見つからない場合にユーザーにプロンプトを表示することができます。
If the "nextOTP" flag is set in the otp-tokenInfo from the PA-OTP-CHALLENGE, then the OTP value MUST be generated from the next token state rather than that used in the previous PA-OTP-REQUEST for that token. The "nextOTP" flag MUST also be set in the new PA-OTP-REQUEST.
PA-OTP-CHALLENGEからのotp-tokenInfoで「nextOTP」フラグが設定されている場合、OTP値は、そのトークンの以前のPA-OTP-REQUESTで使用されたものではなく、次のトークン状態から生成される必要があります。 「nextOTP」フラグは、新しいPA-OTP-REQUESTでも設定する必要があります。
If the "collect-pin" flag is set, then the token requires a PIN to be collected by the client. If the "do-not-collect-pin" flag is set in the otp-tokenInfo from the PA-OTP-CHALLENGE, then the token represented by the otp-tokenInfo does not require a PIN to be collected by the client as part of the OTP value. If neither of the "collect-pin" nor "do-not-collect-pin" flags are set, then PIN requirements of the token are unspecified. If both flags are set, then the client SHALL regard the request as invalid.
「collect-pin」フラグが設定されている場合、トークンにはクライアントがPINを収集する必要があります。 「do-not-collect-pin」フラグがPA-OTP-CHALLENGEからのotp-tokenInfoで設定されている場合、otp-tokenInfoで表されるトークンは、クライアントが一部としてPINを収集する必要はありません。 OTP値。 「collect-pin」フラグも「do-not-collect-pin」フラグも設定されていない場合、トークンのPIN要件は指定されていません。両方のフラグが設定されている場合、クライアントは要求を無効と見なすものとします（SHALL）。
If the "separate-pin-required" flag is set, then any PIN collected by the client MUST be included as a UTF-8 string in the otp-pin of the PA-OTP-REQUEST.
「separate-pin-required」フラグが設定されている場合、クライアントによって収集されたPINはすべて、PA-OTP-REQUESTのotp-pinにUTF-8文字列として含まれている必要があります。
If the token is a connected device, then how the PIN is used to generate the OTP value will depend on the type of device. However, if the token is a disconnected device, then it will depend on the "separate-pin-required" flag. If the flag is not set, then the OTP value MUST be generated by appending the PIN with the value from the token entered by the user and, if the flag is set, then the OTP value MUST be the value from the token.
トークンが接続されたデバイスである場合、OTP値を生成するためにPINがどのように使用されるかは、デバイスのタイプによって異なります。ただし、トークンが切断されたデバイスである場合は、「個別のピンが必要」フラグに依存します。フラグが設定されていない場合、OTP値は、ユーザーが入力したトークンからの値をPINに追加することにより生成する必要があり、フラグが設定されている場合、OTP値はトークンからの値でなければなりません。
The clients SHOULD NOT normalize the PIN value or any OTP value collected from the user or returned by a connected token in any way.
クライアントは、ユーザーから収集された、または接続されたトークンによって返されたPIN値またはOTP値を何らかの方法で正規化するべきではありません（SHOULD NOT）。
If the "check-digit" flag is set, then any OTP values SHOULD be decimal and have a Luhn check digit appended [ISOIEC7812]. If the token is disconnected, then the Client MAY ignore this flag; if the token is connected, then the Client MUST enforce it. The Client MUST regard the request as invalid, if otp-format is present and set to any value other than "decimal".
「check-digit」フラグが設定されている場合、OTP値は10進数であり、Luhnチェックディジットが付加されている必要があります[ISOIEC7812]。トークンが切断されている場合、クライアントはこのフラグを無視できます。トークンが接続されている場合、クライアントはそれを強制する必要があります。 otp-formatが存在し、「decimal」以外の値に設定されている場合、クライアントはリクエストを無効と見なす必要があります。
If an otp-challenge is present in the otp-tokenInfo selected by the client from the PA-OTP-CHALLENGE, then the OTP value for the token MUST be generated based on a challenge, if the token is capable of accepting a challenge. The client MAY ignore the provided challenge if and only if the token is not capable of including a challenge in the OTP calculation.
クライアントがPA-OTP-CHALLENGEから選択したotp-tokenInfoにotp-challengeが存在する場合、トークンがチャレンジを受け入れることができる場合、トークンのOTP値はチャレンジに基づいて生成される必要があります。トークンがOTP計算にチャレンジを含めることができない場合にのみ、クライアントは提供されたチャレンジを無視してもよい（MAY）。
If the "combine" flag is not set in the otp-tokenInfo of the PA-OTP-CHALLENGE, then the OTP SHALL be calculated based only the challenge and not the internal state (e.g., time or counter) of the token. If the "combine" flag is set, then the OTP SHALL be calculated using both the internal state and the provided challenge, if that value is obtainable by the client. If the flag is set but otp-challenge is not present, then the client SHALL regard the request as invalid.
PA-OTP-CHALLENGEのotp-tokenInfoに「結合」フラグが設定されていない場合、OTPは、トークンの内部状態（時間やカウンタなど）ではなく、チャレンジのみに基づいて計算される必要があります（SHALL）。 "combine"フラグが設定されている場合、OTPは、クライアントがその値を取得できる場合、内部状態と提供されたチャレンジの両方を使用して計算する必要があります（SHALL）。フラグは設定されているがotp-challengeが存在しない場合、クライアントはリクエストを無効と見なすものとします（SHALL）。
If token is a connected device, then the use of the challenge will depend on the type of device but will involve passing the challenge and the value of the "combine" flag in a token-specific manner to the token, along with a PIN if collected and the values of otp-length and otp-format if specified, in order to obtain the OTP value. If the token is disconnected, then the challenge MUST be displayed to the user and the value of the "combine" flag MAY be ignored by the client.
トークンが接続されているデバイスの場合、チャレンジの使用はデバイスのタイプによって異なりますが、チャレンジとトークンに「結合」フラグの値をトークン固有の方法でトークンに渡すことと、 OTP値を取得するために、収集され、otp-lengthおよびotp-formatの値（指定されている場合）。トークンが切断されている場合、チャレンジをユーザーに表示する必要があり、「結合」フラグの値はクライアントによって無視される場合があります。
If the OTP value was generated using a challenge that was not sent by the KDC, then the challenge SHALL be included in the otp-challenge of the PA-OTP-REQUEST. If the OTP was generated by combining a challenge (either received from the KDC or generated by the client) with the token state, then the "combine" flag SHALL be set in the PA-OTP-REQUEST.
KDCによって送信されなかったチャレンジを使用してOTP値が生成された場合、チャレンジはPA-OTP-REQUESTのotp-challengeに含まれる必要があります（SHALL）。チャレンジを（KDCから受信したか、クライアントによって生成された）トークンの状態と組み合わせることによってOTPが生成された場合、PA-OTP-REQUESTで「結合」フラグを設定する必要があります（SHALL）。
If the "must-encrypt-nonce" flag is set in the otp-tokenInfo, then the OTP value MUST be used to generate the Client Key and Reply Key as described in Section 3.6 and MUST NOT be included in the otp-value field of the PA-OTP-REQUEST. If the flag is not set, then the OTP value MUST be included in the otp-value field of the PA-OTP-REQUEST and MUST NOT be used in the key derivation. In this case, the Client Key and Reply Key SHALL be the same as the Armor Key as described in Section 3.6; so, if the returning of OTP values in this way does not conform to local policy on the client (for example, if KDC-Authentication is required and is not being provided by other means), then it SHOULD NOT use the token for authentication.
「must-encrypt-nonce」フラグがotp-tokenInfoに設定されている場合、セクション3.6で説明されているように、OTP値を使用してクライアントキーと応答キーを生成する必要があり、OTP値をPA-OTP-REQUEST。フラグが設定されていない場合、OTP値はPA-OTP-REQUESTのotp-valueフィールドに含まれていなければならず（MUST）、鍵の派生では使用してはなりません（MUST NOT）。この場合、セクション3.6で説明されているように、クライアントキーと応答キーはアーマーキーと同じである必要があります。そのため、この方法でOTP値を返すことがクライアントのローカルポリシーに準拠していない場合（たとえば、KDC-Authenticationが必要であり、他の手段で提供されていない場合）、トークンを認証に使用しないでください。
If the supportedHashAlg and iterationCount elements are included in the otp-tokenInfo, then the client MUST use hashed OTP values in the generation of the Reply Key and Client Key as described in Section 3.6. The client MUST select the first algorithm from the list that it supports and the AlgorithmIdentifer [RFC5280] selected MUST be placed in the hashAlg element of the PA-OTP-REQUEST. However, if none of the algorithm identifiers conform to local policy restrictions, then the authentication attempt MUST NOT proceed using that token. If the value of iterationCount does not conform to local policy on the client, then the client MAY use a larger value, but MUST NOT use a lower value. The value of the iteration count used by the client MUST be returned in the PA-OTP-REQUEST sent to the KDC.
supportedHashAlg要素とiterationCount要素がotp-tokenInfoに含まれている場合、クライアントは、セクション3.6で説明されているように、返信キーとクライアントキーの生成にハッシュされたOTP値を使用する必要があります。クライアントは、サポートするリストから最初のアルゴリズムを選択する必要があり、選択したAlgorithmIdentifer [RFC5280]は、PA-OTP-REQUESTのhashAlg要素に配置する必要があります。ただし、どのアルゴリズム識別子もローカルポリシーの制限に準拠していない場合、認証の試行はそのトークンを使用して続行してはなりません（MUST NOT）。 iterationCountの値がクライアントのローカルポリシーに準拠していない場合、クライアントはより大きい値を使用できますが、低い値を使用してはなりません（MUST NOT）。クライアントが使用する反復カウントの値は、KDCに送信されるPA-OTP-REQUESTで返される必要があります。
If hashed OTP values are used, then the nonce generated by the client MUST be as long as the longest key length of the symmetric key types that it supports and MUST be chosen randomly (see [RFC4086]). The nonce MUST be included in the PA-OTP-REQUEST, along with the hash algorithm and iteration count used in the nonce, hashAlg, and iterationCount fields of the PA-OTP-REQUEST. These fields MUST NOT be included if hashed OTP values were not used. It is RECOMMENDED that the iteration count used by the client be chosen in such a way that it is computationally infeasible/unattractive for an attacker to brute-force search for the given OTP.
ハッシュされたOTP値が使用される場合、クライアントによって生成されるnonceは、サポートする対称鍵タイプの最長の鍵長と同じ長さでなければならず、ランダムに選択されなければなりません（[RFC4086]を参照）。 nonceは、PA-OTP-REQUESTのnonce、hashAlg、およびiterationCountフィールドで使用されるハッシュアルゴリズムと反復カウントとともに、PA-OTP-REQUESTに含める必要があります。ハッシュされたOTP値が使用されなかった場合、これらのフィールドを含めることはできません。クライアントが使用する反復回数は、攻撃者が指定されたOTPをブルートフォースで検索するのが計算上実行不可能/魅力的でないように選択することをお勧めします。
The PA-OTP-REQUEST returned by the client SHOULD include information on the generated OTP value reported by the OTP token when available to the client. The otp-time and otp-counter fields of the PA-OTP-REQUEST SHOULD be used to return the time and counter values used by the token if available to the client. The otp-format field MAY be used to report the format of the generated OTP. This field SHOULD be used if a token can generate OTP values in multiple formats. The otp-algID field SHOULD be used by the client to report the algorithm used in the OTP calculation, and the otp-tokenID SHOULD be used to report the identifier of the OTP token key used if the information is known to the client.
クライアントから返されるPA-OTP-REQUESTには、クライアントが利用できる場合にOTPトークンによって報告される生成されたOTP値に関する情報が含まれている必要があります（SHOULD）。 PA-OTP-REQUESTのotp-timeフィールドとotp-counterフィールドを使用して、クライアントが利用できる場合にトークンが使用する時間とカウンタの値を返す必要があります（SHOULD）。 otp-formatフィールドは、生成されたOTPのフォーマットを報告するために使用される場合があります。このフィールドは、トークンが複数の形式でOTP値を生成できる場合に使用してください。 otp-algIDフィールドは、クライアントがOTP計算で使用されるアルゴリズムを報告するために使用する必要があり（SHOULD）、otp-tokenIDは、情報がクライアントに知られている場合に使用されるOTPトークンキーの識別子を報告するために使用する必要があります（SHOULD）。
If the PA-OTP-REQUEST is being sent in response to a PA-OTP-CHALLENGE that contained an otp-vendor field in the selected otp-tokenInfo, then the otp-vendor field of the PA-OTP-REQUEST MUST be set to the same value. If no otp-vendor field was provided by the KDC, then the field SHOULD be set to the vendor identifier of the token if known to the client.
選択したotp-tokenInfoにotp-vendorフィールドが含まれているPA-OTP-CHALLENGEへの応答としてPA-OTP-REQUESTが送信されている場合、PA-OTP-REQUESTのotp-vendorフィールドを次のように設定する必要があります。同じ値。 KDCによってotp-vendorフィールドが提供されなかった場合、フィールドは、クライアントに知られている場合、トークンのベンダー識別子に設定されるべきです（SHOULD）。
The generated Client Key is used by the client to encrypt data to be included in the encData of the PA-OTP-REQUEST to allow the KDC to authenticate the user. The key usage for this encryption is KEY_USAGE_OTP_REQUEST.
生成されたクライアントキーはクライアントによって使用され、PA-OTP-REQUESTのencDataに含まれるデータを暗号化して、KDCがユーザーを認証できるようにします。この暗号化のキー使用法は、KEY_USAGE_OTP_REQUESTです。
o If the PA-OTP-REQUEST is being generated in response to a PA-OTP-CHALLENGE returned by the KDC, then the client SHALL encrypt a PA-OTP-ENC-REQUEST containing the value of nonce from the PA-OTP-CHALLENGE using the same encryption type as the Armor Key.
o KDCから返されたPA-OTP-CHALLENGEに応答してPA-OTP-REQUESTが生成されている場合、クライアントは、PA-OTP-CHALLENGEからのnonceの値を含むPA-OTP-ENC-REQUESTを暗号化する必要があります。アーマーキーと同じ暗号化タイプ。
o If the PA-OTP-REQUEST is not in response to a PA-OTP-CHALLENGE, then the client SHALL encrypt a PA-ENC-TS-ENC containing the current time as in the encrypted timestamp pre-authentication mechanism [RFC4120].
o PA-OTP-REQUESTがPA-OTP-CHALLENGEに応答しない場合、クライアントは、暗号化されたタイムスタンプ事前認証メカニズム[RFC4120]のように、現在時刻を含むPA-ENC-TS-ENCを暗号化する必要があります（SHALL）。
If the client is working in two-pass mode and so, is not responding to an initial KDC challenge, then the values of the iteration count and hash algorithms cannot be obtained from that challenge. The client SHOULD use any values obtained from a previous PA-OTP-CHALLENGE or, if no values are available, it MAY use initial configured values.
クライアントが2パスモードで動作しており、初期のKDCチャレンジに応答していない場合、そのチャレンジから反復カウントとハッシュアルゴリズムの値を取得できません。クライアントは、以前のPA-OTP-CHALLENGEから取得した値を使用する必要があります（SHOULD）。使用できる値がない場合は、初期構成値を使用できます（MAY）。
The KDC validates the pre-authentication data by generating the Client Key and Reply Key in the same way as the client and using the generated Client Key to decrypt the value of encData from the PA-OTP-REQUEST. The generated Reply Key is used to encrypt data in the AS-REP.
KDCは、クライアントと同じ方法でクライアントキーと応答キーを生成し、生成されたクライアントキーを使用してPA-OTP-REQUESTからのencDataの値を復号化することにより、事前認証データを検証します。生成された返信キーは、AS-REPのデータを暗号化するために使用されます。
If the otp-value field is included in the PA-OTP-REQUEST, then the KDC MUST use that value unless the OTP method is required to support KDC-authentication (see Section 3.2). If the otp-value is not included in the PA-OTP-REQUEST, then the KDC will need to generate or obtain the OTP value.
otp-valueフィールドがPA-OTP-REQUESTに含まれている場合、OTCメソッドがKDC認証をサポートする必要がない限り、KDCはその値を使用する必要があります（セクション3.2を参照）。 otp-valueがPA-OTP-REQUESTに含まれていない場合、KDCはOTP値を生成または取得する必要があります。
If the otp-pin field is present in the PA-OTP-REQUEST, then the PIN value has to be value provided by the client. The KDC SHOULD SASLPrep (Stringprep Profile for User Names and Passwords) [RFC4013] the value in lookup mode before comparison.
otp-pinフィールドがPA-OTP-REQUESTに存在する場合、PIN値はクライアントによって提供された値でなければなりません。 KDC SHOULD SASLPrep（ユーザー名とパスワードのStringprepプロファイル）[RFC4013]比較前のルックアップモードの値。
It should be noted that it is anticipated that, as improved string comparison technologies are standardized, the processing done by the KDC will change, but efforts will be made to maintain as much compatibility with SASLprep as possible.
改善された文字列比較テクノロジが標準化されると、KDCによって実行される処理が変更されることが予想されますが、SASLprepとの互換性をできる限り維持するように努力します。
If the otp-challenge field is present, then the OTP was calculated using that challenge. If the "combine" flag is also set, then the OTP was calculated using the challenge and the token's current state.
otp-challengeフィールドが存在する場合、OTPはそのチャレンジを使用して計算されました。 「結合」フラグも設定されている場合、OTPはチャレンジとトークンの現在の状態を使用して計算されました。
It is RECOMMENDED that the KDC act upon the values of otp-time, otp-counter, otp-format, otp-algID, and otp-tokenID if they are present in the PA-OTP-REQUEST. If the KDC receives a request containing these values, but cannot act upon them, then they MAY be ignored.
PA-OTP-REQUESTに存在する場合、KDCがotp-time、otp-counter、otp-format、otp-algID、およびotp-tokenIDの値に基づいて動作することをお勧めします。 KDCがこれらの値を含む要求を受信しても、それらに作用できない場合、それらは無視される場合があります。
The KDC generates the Client Key and Reply Key as described in Section 3.6 from the OTP value using the nonce, hash algorithm, and iteration count if present in the PA-OTP-REQUEST. The KDC MUST fail the request with KDC_ERR_INVALID_HASH_ALG, if the KDC requires hashed OTP values and the hashAlg field was not present in the PA-OTP-REQUEST or if the value of this field does not conform to local KDC policy. Similarly, the KDC MUST fail the request with KDC_ERR_INVALID_ITERATION_COUNT, if the value of the iterationCount included in the PA-OTP-REQUEST does not conform to local KDC policy or is less than that specified in the PA-OTP-CHALLENGE. In addition, the KDC MUST fail the authentication request with KDC_ERR_PIN_REQUIRED, if it requires a separate PIN to the OTP value and an otp-pin was not included in the PA-OTP-REQUEST. The above error codes are defined as follows:
KDCは、3.6で説明されているように、PA-OTP-REQUESTに存在する場合は、ナンス、ハッシュアルゴリズム、反復回数を使用して、OTP値からクライアントキーと応答キーを生成します。 KDCがハッシュOTP値を必要とし、hashAlgフィールドがPA-OTP-REQUESTに存在しない場合、またはこのフィールドの値がローカルKDCポリシーに準拠していない場合、KDCはKDC_ERR_INVALID_HASH_ALGで要求を失敗させる必要があります。同様に、PA-OTP-REQUESTに含まれるiterationCountの値がローカルKDCポリシーに準拠していないか、PA-OTP-CHALLENGEで指定されている値よりも小さい場合、KDCはKDC_ERR_INVALID_ITERATION_COUNTで要求を失敗させる必要があります。さらに、OTP値に個別のPINが必要であり、OTPピンがPA-OTP-REQUESTに含まれていない場合、KDCはKDC_ERR_PIN_REQUIREDで認証要求を失敗させる必要があります。上記のエラーコードは次のように定義されています。
KDC_ERR_INVALID_HASH_ALG 94 KDC_ERR_INVALID_ITERATION_COUNT 95 KDC_ERR_PIN_REQUIRED 97
KDC_ERR_INVALID_HASH_ALG 94 KDC_ERR_INVALID_ITERATION_COUNT 95 KDC_ERR_PIN_REQUIRED 97
The generated Client Key is then used to decrypt the encData from the PA-OTP-REQUEST. If the client response was sent as a result of a PA-OTP-CHALLENGE, then the decrypted data will be a PA-OTP-ENC-REQUEST and the client authentication MUST fail with KDC_ERR_PREAUTH_FAILED if the nonce value from the PA-OTP-ENC-REQUEST is not the same as the nonce value sent in the PA-OTP-CHALLENGE. If the response was not sent as a result of a PA-OTP-CHALLENGE, then the decrypted value will be a PA-ENC-TS-ENC, and the authentication process will be the same as with classic encrypted timestamp pre-authentication [RFC4120].
生成されたクライアントキーは、PA-OTP-REQUESTからのencDataを復号化するために使用されます。 PA-OTP-CHALLENGEの結果としてクライアント応答が送信された場合、復号化されたデータはPA-OTP-ENC-REQUESTであり、PA-OTP-ENCからのナンス値の場合、クライアント認証はKDC_ERR_PREAUTH_FAILEDで失敗する必要があります。 -REQUESTは、PA-OTP-CHALLENGEで送信されるnonce値と同じではありません。 PA-OTP-CHALLENGEの結果として応答が送信されなかった場合、復号化された値はPA-ENC-TS-ENCとなり、認証プロセスは従来の暗号化されたタイムスタンプの事前認証と同じになります[RFC4120 ]。
The KDC MUST fail the request with KDC_ERR_ETYPE_NOSUPP, if the encryption type used by the client in the encData does not conform to KDC policy.
クライアントがencDataで使用する暗号化タイプがKDCポリシーに準拠していない場合、KDCは要求をKDC_ERR_ETYPE_NOSUPPで失敗させる必要があります。
If authentication fails due to the hash algorithm, iteration count, or encryption type used by the client, then the KDC SHOULD return a PA-OTP-CHALLENGE with the required values in the error response. If the authentication fails due to the token state on the server is no longer being synchronized with the token used, then the KDC MAY return a PA-OTP-CHALLENGE with the "nextOTP" flag set as described in Section 2.4.
クライアントが使用するハッシュアルゴリズム、反復回数、または暗号化タイプが原因で認証が失敗した場合、KDCはエラー応答で必要な値を含むPA-OTP-CHALLENGEを返す必要があります（SHOULD）。サーバー上のトークンの状態が使用中のトークンと同期されなくなったために認証が失敗した場合、KDCは、2.4で説明されているように、「nextOTP」フラグが設定されたPA-OTP-CHALLENGEを返す場合があります。
If, during the authentication process, the KDC determines that the user's PIN has been changed, then it SHOULD include a PA-OTP-PIN-CHANGE in the response, as described in Section 2.3, containing the new PIN value. The KDC MAY also include the new PIN's expiration time and the expiration time of the OTP account within the last-req field of the PA-OTP-PIN-CHANGE. (These fields can be used by the KDC to handle cases where the account related to the user's OTP token has a different expiration time to the user's Kerberos account.) If the KDC determines that the user's PIN or OTP account are about to expire, it MAY return a PA-OTP-PIN-CHANGE with that information. Finally, if the KDC determines that the user's PIN has expired, then it SHOULD return a KRB-ERROR of type KDC_ERR_PIN_EXPIRED as described in Section 2.3
認証プロセス中に、ユーザーのPINが変更されたとKDCが判断した場合、セクション2.3で説明されているように、新しいPIN値を含むPA-OTP-PIN-CHANGEを応答に含める必要があります。 KDCは、PA-OTP-PIN-CHANGEのlast-reqフィールド内に新しいPINの有効期限とOTPアカウントの有効期限も含めることができます（MAY）。 （これらのフィールドは、KDCがユーザーのOTPトークンに関連するアカウントの有効期限がユーザーのKerberosアカウントと異なる場合に対処するために使用できます。）ユーザーのPINまたはOTPアカウントがまもなく期限切れになるとKDCが判断した場合、その情報とともにPA-OTP-PIN-CHANGEを返す場合があります。最後に、KDCがユーザーのPINの有効期限が切れていると判断した場合、セクション2.3で説明されているように、KDC_ERR_PIN_EXPIREDタイプのKRB-ERRORを返す必要があります（SHOULD）。
If the pre-authentication data was successfully verified, then, in order to support mutual authentication, the KDC SHALL respond to the client's PA-OTP-REQUEST by using the generated Reply Key to encrypt the data in the AS-REP. The client then uses its generated Reply Key to decrypt the encrypted data and MUST NOT continue with the authentication process, if decryption is not successful.
事前認証データが正常に検証された場合、相互認証をサポートするために、KDCは、生成された応答キーを使用してクライアントのPA-OTP-REQUESTに応答し、AS-REPのデータを暗号化する必要があります。次にクライアントは、生成された返信キーを使用して暗号化されたデータを復号化します。復号化が成功しない場合は、認証プロセスを続行してはなりません。
In order to authenticate the user, the client and KDC need to generate two encryption keys:
ユーザーを認証するために、クライアントとKDCは2つの暗号化キーを生成する必要があります。
o The Client Key to be used by the client to encrypt and by the KDC to decrypt the encData in the PA-OTP-REQUEST.
o クライアントが暗号化するために、およびKDCがPA-OTP-REQUESTのencDataを復号化するために使用するクライアントキー。
o The Reply Key to be used in the standard manner by the KDC to encrypt data in the AS-REP.
o AS-REPのデータを暗号化するためにKDCが標準的な方法で使用する返信キー。
The method used to generate the two keys will depend on the OTP algorithm.
2つのキーの生成に使用される方法は、OTPアルゴリズムによって異なります。
o If the OTP value is included in the otp-value of the PA-OTP-REQUEST, then the two keys SHALL be the same as the Armor Key (defined in [RFC6113]).
o OTP値がPA-OTP-REQUESTのotp-valueに含まれている場合、2つのキーはアーマーキー（[RFC6113]で定義）と同じである必要があります。
o If the OTP value is not included in the otp-value of the PA-OTP-REQUEST, then the two keys SHALL be derived from the Armor Key and the OTP value as described below.
o OTP値がPA-OTP-REQUESTのotp-valueに含まれていない場合、2つのキーは、以下に説明するように、アーマーキーとOTP値から派生する必要があります。
If the OTP value is not included in the PA-OTP-REQUEST, then the Reply Key and Client Key SHALL be generated using the KRB-FX-CF2 algorithm from [RFC6113] as follows:
OTP値がPA-OTP-REQUESTに含まれていない場合、[RFC6113]のKRB-FX-CF2アルゴリズムを使用して、応答キーとクライアントキーを次のように生成する必要があります。
Client Key = KRB-FX-CF2(K1, K2, O1, O2)
Reply Key = KRB-FX-CF2(K1, K2, O3, O4)
The octet string parameters, O1, O2, O3, and O4 shall be the ASCII string "OTPComb1", "OTPComb2", "OTPComb3", and "OTPComb4" as shown below:
オクテット文字列パラメータO1、O2、O3、およびO4は、次に示すように、ASCII文字列「OTPComb1」、「OTPComb2」、「OTPComb3」、および「OTPComb4」になります。
{0x4f, 0x54, 0x50, 0x43, 0x6f, 0x6d, 0x62, 0x31}
{0x4f, 0x54, 0x50, 0x43, 0x6f, 0x6d, 0x62, 0x32}
{0x4f, 0x54, 0x50, 0x43, 0x6f, 0x6d, 0x62, 0x33}
{0x4f, 0x54, 0x50, 0x43, 0x6f, 0x6d, 0x62, 0x34}
The first input key, K1, SHALL be the Armor Key and so, as described in Section 5.1 of [RFC6113], the enctypes of the generated Client Key and Reply Key will be the same as the enctype of Armor Key. The second input key, K2, shall be derived from the OTP value using string-to-key (defined in [RFC3961]) as described below.
最初の入力キーK1はアーマーキーである必要があります。したがって、[RFC6113]のセクション5.1で説明されているように、生成されるクライアントキーと応答キーのenctypeはアーマーキーのenctypeと同じになります。 2番目の入力キーK2は、以下で説明するようにstring-to-key（[RFC3961]で定義）を使用してOTP値から派生します。
If the hash of the OTP value is to be used, then K2 SHALL be derived as follows:
OTP値のハッシュが使用される場合、K2は次のように導出される必要があります。
o An initial hash value, H, is generated:
o 初期ハッシュ値Hが生成されます。
H = hash(realm|nonce|OTP)
H = hash（realm | nonce | OTP）
Where:
ただし：
* "|" denotes concatenation. * hash is the hash algorithm selected by the client. * realm is the name of the server's realm as carried in the realm field of the AS-REQ (not including the tag and length from the DER encoding). * nonce is the value of the random nonce value generated by the client and carried in the nonce field of the PA-OTP-REQUEST (not including the tag and length from the DER encoding). * If the OTP format is decimal, hexadecimal, or alphanumeric, then OTP is the value of the OTP generated as described in Section 3.3 with SASLprep [RFC4013] applied in lookup mode; otherwise, it is the unnormalized OTP value.
* 「|」連結を示します。 * hashは、クライアントが選択したハッシュアルゴリズムです。 * realmは、AS-REQのレルムフィールドに含まれるサーバーのレルムの名前です（DERエンコーディングのタグと長さは含まれません）。 * nonceは、クライアントによって生成され、PA-OTP-REQUESTのnonceフィールドに含まれるランダムなnonce値の値です（DERエンコーディングのタグと長さは含まれません）。 * OTPフォーマットが10進数、16進数、または英数字の場合、OTPは、セクション3.3で説明されているように生成されたOTPの値であり、ルックアップモードでSASLprep [RFC4013]が適用されます。それ以外の場合は、正規化されていないOTP値です。
o The initial hash value is then hashed iterationCount-1 times to produce a final hash value, H' (where iterationCount is the value from the PA-OTP-REQUEST).
o 次に、初期ハッシュ値が反復カウント-1回ハッシュされ、最終ハッシュ値H 'が生成されます（ここで、反復カウントはPA-OTP-REQUESTからの値です）。
H' = hash(hash(...(iterationCount-1 times)...(H)))
o The value of K2 is then derived from the Base64 [RFC2045] encoding of this final hash value.
o 次に、K2の値は、この最終ハッシュ値のBase64 [RFC2045]エンコーディングから導出されます。
K2 = string-to-key(Base64(H')|"Krb-preAuth")
If the hash value is not used, then K2 SHALL be derived from the base64 encoding of the OTP value.
ハッシュ値が使用されない場合、K2はOTP値のbase64エンコーディングから派生する必要があります（SHALL）。
K2 = string-to-key(Base64(OTP)|"Krb-preAuth")
The enctype used for string-to-key SHALL be that of the Armor Key and the salt and any additional parameters for string-to-key MAY be provided by the KDC in the PA-OTP-CHALLENGE. If the salt and string-to-key parameters are not provided, then the default values defined for the particular enctype SHALL be used.
string-to-keyに使用されるenctypeは、Armor Keyのenctypeである必要があり、saltとstring-to-keyの追加パラメーターは、PA-OTP-CHALLENGEのKDCによって提供される場合があります。 saltおよびstring-to-keyパラメータが指定されていない場合は、特定のenctypeに定義されているデフォルト値を使用する必要があります（SHALL）。
If the strengthen-key is present in KrbFastResponse, then it is combined with the Reply Key to generate the final AS-REQ as described in [RFC6113]. The strengthen-key does not influence the Client Key.
強化キーがKrbFastResponseに存在する場合、[RFC6113]で説明されているように、それが応答キーと組み合わされて最終的なAS-REQが生成されます。強化キーはクライアントキーには影響しません。
The padata-type PA-OTP-CHALLENGE is returned by the KDC to the client in the enc-fast-rep of a PA-FX-FAST-REPLY in the PA-DATA of a KRB-ERROR when OTP pre-authentication is required. The corresponding padata-value field contains the Distinguished Encoding Rules (DER) [X.680] and [X.690] encoding of a PA-OTP-CHALLENGE containing a server-generated nonce and information for the client on how to generate the OTP.
OTP事前認証が必要な場合、KDCからpadata-type PA-OTP-CHALLENGEがKRB-ERRORのPA-DATAのPA-FX-FAST-REPLYのenc-fast-repでクライアントに返されます。 。対応するpadata-valueフィールドには、サーバー生成ノンスとOTPの生成方法に関するクライアントの情報を含むPA-OTP-CHALLENGEのDistinguished Encoding Rules（DER）[X.680]および[X.690]エンコーディングが含まれています。 。
PA-OTP-CHALLENGE 141
PA-OTPチャレンジ141
PA-OTP-CHALLENGE ::= SEQUENCE {
nonce [0] OCTET STRING,
otp-service [1] UTF8String OPTIONAL,
otp-tokenInfo [2] SEQUENCE (SIZE(1..MAX)) OF
OTP-TOKENINFO,
salt [3] KerberosString OPTIONAL,
s2kparams [4] OCTET STRING OPTIONAL,
...
}
｝
OTP-TOKENINFO ::= SEQUENCE {
flags [0] OTPFlags,
otp-vendor [1] UTF8String OPTIONAL,
otp-challenge [2] OCTET STRING (SIZE(1..MAX))
OPTIONAL,
otp-length [3] Int32 OPTIONAL,
otp-format [4] OTPFormat OPTIONAL,
otp-tokenID [5] OCTET STRING OPTIONAL,
otp-algID [6] AnyURI OPTIONAL,
supportedHashAlg [7] SEQUENCE OF AlgorithmIdentifier
OPTIONAL,
iterationCount [8] Int32 OPTIONAL,
...
}
OTPFormat ::= INTEGER {
decimal(0),
hexadecimal(1),
alphanumeric(2),
binary(3),
base64(4)
}
OTPFlags ::= KerberosFlags
-- reserved(0),
-- nextOTP(1),
-- combine(2),
-- collect-pin(3),
-- do-not-collect-pin(4),
-- must-encrypt-nonce (5),
-- separate-pin-required (6),
-- check-digit (7)
nonce A KDC-supplied nonce value to be encrypted by the client in the PA-OTP-REQUEST. This nonce string MUST contain a randomly chosen component at least as long as the Armor Key length.
nonce PA-OTP-REQUESTでクライアントによって暗号化されるKDC提供のnonce値。このノンス文字列には、少なくともアーマーキーの長さと同じくらいランダムに選択されたコンポーネントが含まれている必要があります。
otp-service Use of this field is OPTIONAL, but MAY be used by the KDC to assist the client to locate the appropriate OTP tokens to be used. For example, this field could be used when a user has multiple OTP tokens for different purposes.
otp-serviceこのフィールドの使用はオプションですが、クライアントが使用する適切なOTPトークンを見つけるのを支援するためにKDCによって使用される場合があります。たとえば、このフィールドは、ユーザーがさまざまな目的で複数のOTPトークンを持っている場合に使用できます。
otp-tokenInfo This element MUST be included, and it is a sequence of one or more OTP-TOKENINFO objects containing information on the token or tokens that the user can use for the authentication and how the OTP value is to be generated using those tokens. If a single OTP-TOKENINFO object is included, then only a single token is acceptable by the KDC and any OTP value generated by the client MUST be generated according to the information contained within that element. If more than one OTP-TOKENINFO object is included, then the OTP value MUST be generated according to the information contained within one of those objects.
otp-tokenInfoこの要素は含める必要があります。これは、ユーザーが認証に使用できる1つまたは複数のトークンに関する情報を含む1つ以上のOTP-TOKENINFOオブジェクトのシーケンスであり、OTP値がこれらのトークンを使用して生成される方法です。単一のOTP-TOKENINFOオブジェクトが含まれている場合、KDCは単一のトークンのみを受け入れ、その要素内に含まれている情報に従って、クライアントが生成したOTP値を生成する必要があります。複数のOTP-TOKENINFOオブジェクトが含まれている場合、OTP値は、それらのオブジェクトの1つに含まれる情報に従って生成する必要があります。
flags If the "nextOTP" flag is set, then the OTP SHALL be based on the next token "state" rather than the one used in the previous authentication. As an example, for a time-based token, this means the next time slot and for an event-based token, this could mean the next counter value. If the "nextOTP" flag is set, then there MUST only be a single otp-tokenInfo element in the PA-OTP-CHALLENGE.
フラグ「nextOTP」フラグが設定されている場合、OTPは、前の認証で使用されたトークンではなく、次のトークンの「状態」に基づいている必要があります（SHALL）。例として、時間ベースのトークンの場合、これは次のタイムスロットを意味し、イベントベースのトークンの場合、これは次のカウンター値を意味する可能性があります。 「nextOTP」フラグが設定されている場合、PA-OTP-CHALLENGEには単一のotp-tokenInfo要素のみが存在する必要があります。
The "combine" flag controls how the challenge included in otp-challenge shall be used. If the flag is set, then OTP SHALL be calculated using the challenge from otp-challenge and the internal token state (e.g., time or counter). If the "combine" flag is not set, then the OTP SHALL be calculated based only on the challenge. If the flag is set and otp-challenge is not present, then the request SHALL be regarded as invalid.
「combine」フラグは、otp-challengeに含まれるチャレンジをどのように使用するかを制御します。フラグが設定されている場合、OTPチャレンジは、otp-challengeからのチャレンジと内部トークンの状態（時間やカウンターなど）を使用して計算する必要があります（SHALL）。 「結合」フラグが設定されていない場合、OTPはチャレンジのみに基づいて計算される必要があります。フラグが設定されていて、otp-challengeが存在しない場合、要求は無効と見なされます（SHALL）。
If the "do-not-collect-pin" flag is set, then the token represented by the current otp-tokenInfo does not require a PIN to be collected as part of the OTP. If the "collect-pin" flag is set, then the token requires a PIN. If neither flag is set, then whether or not a PIN is required is unspecified. The flags are mutually exclusive and so both flags MUST NOT be set, or the client MUST regard the request as invalid.
「do-not-collect-pin」フラグが設定されている場合、現在のotp-tokenInfoで表されるトークンでは、OTPの一部としてPINを収集する必要はありません。 「collect-pin」フラグが設定されている場合、トークンにはPINが必要です。どちらのフラグも設定されていない場合、PINが必要かどうかは指定されていません。フラグは相互に排他的であるため、両方のフラグを設定することはできません。または、クライアントは要求を無効と見なす必要があります。
If the "must-encrypt-nonce" flag is set, then the OTP value MUST NOT be included in the otp-value field of the PA-OTP-REQUEST, but instead the OTP value MUST be used in the generation of the Reply Key and Client Key as described in Section 3.6.
「must-encrypt-nonce」フラグが設定されている場合、OTP値をPA-OTP-REQUESTのotp-valueフィールドに含めることはできませんが、代わりにOTP値を応答キーの生成に使用する必要があります。セクション3.6で説明されているクライアントキー。
If the "separate-pin-required" flag is set, then the PIN collected by the client SHOULD NOT be used in the generation of the OTP value and SHOULD be returned in the otp-pin field of the PA-OTP-REQUEST.
「separate-pin-required」フラグが設定されている場合、クライアントによって収集されたPINはOTP値の生成に使用してはならず（SHOULD NOT）、PA-OTP-REQUESTのotp-pinフィールドに返すべきです（SHOULD）。
The "check-digit" flag controls whether or not the OTP values generated by the token need to include a Luhn check digit [ISOIEC7812]. If the token is disconnected, then the Client MAY ignore this flag; if this flag is set and the token is connected, then the OTP MUST be a decimal with a check digit appended.
「チェックディジット」フラグは、トークンによって生成されたOTP値にLuhnチェックディジットを含める必要があるかどうかを制御します[ISOIEC7812]。トークンが切断されている場合、クライアントはこのフラグを無視できます。このフラグが設定され、トークンが接続されている場合、OTPはチェックディジットが付加された10進数でなければなりません。
otp-vendor Use of this field is OPTIONAL, but MAY be used by the KDC to identify the vendor of the OTP token to be used.
otp-vendorこのフィールドの使用はオプションですが、使用されるOTPトークンのベンダーを識別するためにKDCによって使用される場合があります。
otp-challenge The otp-challenge is used by the KDC to send a challenge value for use in the OTP calculation. The challenge is an OPTIONAL octet string that SHOULD be uniquely generated for each request in which it is present. When the challenge is not present, the OTP will be calculated on the current token state only. The client MAY ignore a provided challenge if and only if the OTP token the client is interacting with is not capable of including a challenge in the OTP calculation. In this case, KDC policies will determine whether or not to accept a provided OTP value.
otp-challenge otp-challengeは、OTC計算で使用するチャレンジ値を送信するためにKDCによって使用されます。チャレンジはオプションのオクテット文字列であり、それが存在するリクエストごとに一意に生成する必要があります。チャレンジが存在しない場合、OTPは現在のトークンの状態でのみ計算されます。クライアントが対話しているOTPトークンがOTP計算にチャレンジを含めることができない場合に限り、クライアントは提供されたチャレンジを無視してもよい（MAY）。この場合、KDCポリシーは、提供されたOTP値を受け入れるかどうかを決定します。
otp-length Use of this field is OPTIONAL, but MAY be used by the KDC to specify the desired length of the generated OTP. For example, this field could be used when a token is capable of producing OTP values of different lengths. If the format of the OTP is 'decimal', 'hexidecimal', or 'alphanumeric', then this value indicates the desired length in digits/characters; if the OTP format is 'binary', then this value indicates the desired length in octets; and if the OTP format is 'base64', then this value indicates the desired length of the unencoded OTP value in octets.
otp-lengthこのフィールドの使用はオプションですが、生成されたOTPの必要な長さを指定するためにKDCによって使用される場合があります。たとえば、このフィールドは、トークンがさまざまな長さのOTP値を生成できる場合に使用できます。 OTPのフォーマットが「10進数」、「16進数」、または「英数字」の場合、この値は数字/文字での希望の長さを示します。 OTPフォーマットが「バイナリ」の場合、この値はオクテット単位で希望の長さを示します。 OTP形式が「base64」の場合、この値は、エンコードされていないOTP値のオクテット単位での必要な長さを示します。
otp-format Use of this field is OPTIONAL, but MAY be used by the KDC to specify the desired format of the generated OTP value. For example, this field could be used when a token is capable of producing OTP values of different formats.
otp-formatこのフィールドの使用はオプションですが、生成されたOTP値の目的のフォーマットを指定するためにKDCによって使用される場合があります。たとえば、このフィールドは、トークンがさまざまな形式のOTP値を生成できる場合に使用できます。
otp-tokenID Use of this field is OPTIONAL, but MAY be used by the KDC to identify which token key should be used for the authentication. For example, this field could be used when a user has been issued multiple token keys by the same server.
otp-tokenIDこのフィールドの使用はオプションですが、認証に使用する必要があるトークンキーを識別するためにKDCで使用できます（MAY）。たとえば、このフィールドは、ユーザーが同じサーバーから複数のトークンキーを発行された場合に使用できます。
otp-algID Use of this field is OPTIONAL, but MAY be used by the KDC to identify the algorithm to use when generating the OTP. The value of this field MUST be a URI [RFC3986] and SHOULD be obtained from the Portable Symmetric Key Container (PSKC) algorithm registry [RFC6030].
otp-algIDこのフィールドの使用はオプションですが、OTPを生成するときに使用するアルゴリズムを識別するためにKDCによって使用される場合があります。このフィールドの値はURI [RFC3986]でなければならず（MUST）、Portable Symmetric Key Container（PSKC）アルゴリズムレジストリ[RFC6030]から取得する必要があります（SHOULD）。
supportedHashAlg If present, then a hash of the OTP value MUST be used in the key derivation rather than the plain text value. Each AlgorithmIdentifier identifies a hash algorithm that is supported by the KDC in decreasing order of preference. The client MUST select the first algorithm from the list that it supports. Support for SHA-256 by both the client and KDC is REQUIRED. The AlgorithmIdentifier selected by the client MUST be placed in the hashAlg element of the PA-OTP-REQUEST.
supportedHashAlg存在する場合、OTP値のハッシュをプレーンテキスト値ではなくキーの派生で使用する必要があります。各AlgorithmIdentifierは、優先順位の降順でKDCによってサポートされるハッシュアルゴリズムを識別します。クライアントは、サポートするリストから最初のアルゴリズムを選択する必要があります。クライアントとKDCの両方によるSHA-256のサポートが必要です。クライアントが選択したAlgorithmIdentifierは、PA-OTP-REQUESTのhashAlg要素に配置する必要があります。
iterationCount The minimum value of the iteration count to be used by the client when hashing the OTP value. This value MUST be present if supportedHashAlg is present and otherwise MUST NOT be present. If the value of this element does not conform to local policy on the client, then the client MAY use a larger value but MUST NOT use a lower value. The value of the iteration count used by the client MUST be returned in the PA-OTP-REQUEST sent to the KDC.
iterationCount OTP値をハッシュするときにクライアントが使用する反復回数の最小値。この値は、supportedHashAlgが存在する場合は存在する必要があり、そうでない場合は存在してはなりません。この要素の値がクライアントのローカルポリシーに準拠していない場合、クライアントはより大きい値を使用できますが、低い値を使用してはなりません（MUST NOT）。クライアントが使用する反復カウントの値は、KDCに送信されるPA-OTP-REQUESTで返される必要があります。
salt The salt value to be used in string-to-key when used to calculate the keys as described in Section 3.6.
saltセクション3.6で説明されているようにキーを計算するために使用されるときにstring-to-keyで使用されるソルト値。
s2kparams Any additional parameters required by string-to-key as described in Section 3.6.
s2kparamsセクション3.6で説明されているstring-to-keyに必要な追加のパラメータ。
The padata-type PA-OTP-REQUEST is sent by the client to the KDC in the KrbFastReq padata of a PA-FX-FAST-REQUEST that is included in the PA-DATA of an AS-REQ. The corresponding padata-value field contains the DER encoding of a PA-OTP-REQUEST.
padata-type PA-OTP-REQUESTは、AS-REQのPA-DATAに含まれているPA-FX-FAST-REQUESTのKrbFastReq padataでクライアントによってKDCに送信されます。対応するpadata-valueフィールドには、PA-OTP-REQUESTのDERエンコーディングが含まれています。
The message contains pre-authentication data encrypted by the client using the generated Client Key and optional information on how the OTP was generated. It may also, optionally, contain the generated OTP value.
メッセージには、生成されたクライアントキーを使用してクライアントによって暗号化された事前認証データと、OTPの生成方法に関するオプションの情報が含まれています。また、オプションで、生成されたOTP値を含めることもできます。
PA-OTP-REQUEST 142
PA-OTP-REQUEST 142
PA-OTP-REQUEST ::= SEQUENCE {
flags [0] OTPFlags,
nonce [1] OCTET STRING OPTIONAL,
encData [2] EncryptedData,
-- PA-OTP-ENC-REQUEST or PA-ENC-TS-ENC
-- Key usage of KEY_USAGE_OTP_REQUEST
hashAlg [3] AlgorithmIdentifier OPTIONAL,
iterationCount [4] Int32 OPTIONAL,
otp-value [5] OCTET STRING OPTIONAL,
otp-pin [6] UTF8String OPTIONAL,
otp-challenge [7] OCTET STRING (SIZE(1..MAX)) OPTIONAL,
otp-time [8] KerberosTime OPTIONAL,
otp-counter [9] OCTET STRING OPTIONAL,
otp-format [10] OTPFormat OPTIONAL,
otp-tokenID [11] OCTET STRING OPTIONAL,
otp-algID [12] AnyURI OPTIONAL,
otp-vendor [13] UTF8String OPTIONAL,
...
}
KEY_USAGE_OTP_REQUEST 45
KEY_USAGE_OTP_REQUEST 45
PA-OTP-ENC-REQUEST ::= SEQUENCE {
nonce [0] OCTET STRING,
...
}
flags This field MUST be present.
flagsこのフィールドは存在しなければなりません。
If the "nextOTP" flag is set, then the OTP was calculated based on the next token "state" rather than the current one. This flag MUST be set if and only if it was set in a corresponding PA-OTP-CHALLENGE.
「nextOTP」フラグが設定されている場合、OTPは現在のトークンではなく次のトークンの「状態」に基づいて計算されました。このフラグは、対応するPA-OTP-CHALLENGEで設定された場合にのみ設定する必要があります。
If the "combine" flag is set, then the OTP was calculated based on a challenge and the token state.
「結合」フラグが設定されている場合、OTPはチャレンジとトークンの状態に基づいて計算されました。
No other OTPFlag bits are applicable and MUST be ignored by the KDC.
他のOTPFlagビットは適用されず、KDCによって無視される必要があります。
nonce This field MUST be present if a hashed OTP value was used as input to string-to-key (see Section 3.6) and MUST NOT be present otherwise. If present, it MUST contain the nonce value generated by the client and used in the generation of hashed OTP values as described in Section 3.6. This nonce string MUST be as long as the longest key length of the symmetric key types that the client supports and MUST be chosen randomly.
nonceこのフィールドは、ハッシュされたOTP値がstring-to-key（セクション3.6を参照）への入力として使用された場合に存在する必要があり、そうでない場合は存在してはなりません（MUST NOT）。存在する場合、セクション3.6で説明されているように、クライアントによって生成され、ハッシュされたOTP値の生成に使用されるnonce値が含まれている必要があります。このノンス文字列は、クライアントがサポートする対称鍵タイプの最長の鍵の長さと同じである必要があり、ランダムに選択する必要があります。
encData This field MUST be present and MUST contain the pre-authentication data encrypted under the Client Key with a key usage of KEY_USAGE_OTP_REQUEST. If the PA-OTP-REQUEST is sent as a result of a PA-OTP-CHALLENGE, then this MUST contain a PA-OTP-ENC-REQUEST with the nonce from the PA-OTP-CHALLENGE. If no challenge was received, then this MUST contain a PA-ENC-TS-ENC.
encDataこのフィールドは存在しなければならず、KEY_USAGE_OTP_REQUESTのキー使用法でクライアントキーの下で暗号化された事前認証データを含んでいる必要があります。 PA-OTP-REQUESTがPA-OTP-CHALLENGEの結果として送信される場合、これにはPA-OTP-CHALLENGEからのナンスを持つPA-OTP-ENC-REQUESTが含まれている必要があります。チャレンジが受信されなかった場合、これにはPA-ENC-TS-ENCが含まれている必要があります。
hashAlg This field MUST be present if a hashed OTP value was used as input to string-to-key (see Section 3.6) and MUST NOT be present otherwise. If present, it MUST contain the AlgorithmIdentifier of the hash algorithm used. If the PA-OTP-REQUEST is sent as a result of a PA-OTP-CHALLENGE, then the AlgorithmIdentifer MUST be the first one supported by the client from the supportedHashAlg of the PA-OTP-CHALLENGE.
hashAlgこのフィールドは、ハッシュされたOTP値がstring-to-key（セクション3.6を参照）への入力として使用された場合に存在する必要があり、そうでない場合は存在してはなりません（MUST NOT）。存在する場合は、使用するハッシュアルゴリズムのAlgorithmIdentifierを含める必要があります。 PA-OTP-REQUESTがPA-OTP-CHALLENGEの結果として送信される場合、AlgorithmIdentiferは、PA-OTP-CHALLENGEのsupportedHashAlgからクライアントによってサポートされる最初のものでなければなりません（MUST）。
iterationCount This field MUST be present if a hashed OTP value was used as input to string-to-key (see Section 3.6) and MUST NOT be present otherwise. If present, it MUST contain the iteration count used when hashing the OTP value. If the PA-OTP-REQUEST is sent as a result of a PA-OTP-CHALLENGE, then the value MUST NOT be less that specified in the PA-OTP-CHALLENGE.
iterationCountこのフィールドは、ハッシュされたOTP値がstring-to-key（セクション3.6を参照）への入力として使用された場合に存在する必要があり、そうでない場合は存在してはなりません（MUST NOT）。存在する場合、OTP値をハッシュするときに使用される反復カウントを含める必要があります。 PA-OTP-REQUESTがPA-OTP-CHALLENGEの結果として送信される場合、値はPA-OTP-CHALLENGEで指定された値よりも小さくてはなりません。
otp-value The generated OTP value. This value MUST NOT be present if the "must-encrypt-nonce" flag was set in the PA-OTP-CHALLENGE.
otp-value生成されたOTP値。 PA-OTP-CHALLENGEで「must-encrypt-nonce」フラグが設定されている場合、この値は存在してはなりません（MUST NOT）。
otp-pin The OTP PIN value entered by the user. This value MUST NOT be present unless the "separate-pin-required" flag was set in the PA-OTP-CHALLENGE.
otp-pinユーザーが入力したOTP PIN値。 「separate-pin-required」フラグがPA-OTP-CHALLENGEで設定されていない限り、この値は存在してはなりません（MUST NOT）。
otp-challenge Value used by the client in the OTP calculation. It MUST be sent to the KDC if and only if the value would otherwise be unknown to the KDC (for example, the token- or client-modified or generated challenge).
otp-challenge OTP計算でクライアントが使用する値。値がKDCに知られていない場合にのみ、KDCに送信する必要があります（たとえば、トークン、クライアント、または生成されたチャレンジ）。
otp-time This field MAY be included by the client to carry the time value as reported by the OTP token. Use of this element is OPTIONAL, but it MAY be used by a client to simplify the OTP calculations carried out by the KDC. It is RECOMMENDED that the KDC act upon this value if it is present in the request and it is capable of using it in the generation of the OTP value.
otp-timeこのフィールドは、OTPトークンによって報告された時間値を伝えるためにクライアントによって含まれる場合があります。この要素の使用はオプションですが、KDCによって実行されるOTP計算を簡略化するためにクライアントが使用する場合があります。 KDCがリクエストに存在し、OTP値の生成に使用できる場合は、KDCがこの値に基づいて動作することをお勧めします。
otp-counter This field MAY be included by the client to carry the token counter value, as reported by the OTP token. Use of this element is OPTIONAL, but it MAY be used by a client to simplify the OTP calculations carried out by the KDC. It is RECOMMENDED that the KDC act upon this value if it is present in the request and it is capable of using it in the generation of the OTP value.
otp-counterこのフィールドは、OTPトークンによって報告されるように、トークンカウンター値を運ぶためにクライアントによって含まれる場合があります。この要素の使用はオプションですが、KDCによって実行されるOTP計算を簡略化するためにクライアントが使用する場合があります。 KDCがリクエストに存在し、OTP値の生成に使用できる場合は、KDCがこの値に基づいて動作することをお勧めします。
otp-format This field MAY be used by the client to send the format of the generated OTP as reported by the OTP token. Use of this element is OPTIONAL, but it MAY be used by the client to simplify the OTP calculations carried out by the KDC. It is RECOMMENDED that the KDC act upon this value, if it is present in the request and it is capable of using it in the generation of the OTP value.
otp-formatこのフィールドは、OTPトークンによって報告された生成されたOTPのフォーマットを送信するためにクライアントによって使用される場合があります。この要素の使用はオプションですが、KDCによって実行されるOTP計算を簡略化するためにクライアントが使用する場合があります。 KDCが要求に存在し、OTP値の生成に使用できる場合は、KDCがこの値に基づいて動作することをお勧めします。
otp-tokenID This field MAY be used by the client to send the identifier of the token key used, as reported by the OTP token. Use of this field is OPTIONAL, but MAY be used by the client to simplify the authentication process by identifying a particular token key associated with the user. It is RECOMMENDED that the KDC act upon this value, if it is present in the request and it is capable of using it in the generation of the OTP value.
otp-tokenIDこのフィールドは、OTPトークンによって報告されるように、使用されるトークンキーの識別子を送信するためにクライアントによって使用される場合があります。このフィールドの使用はオプションですが、ユーザーに関連付けられた特定のトークンキーを識別することにより、認証プロセスを簡略化するためにクライアントで使用される場合があります。 KDCが要求に存在し、OTP値の生成に使用できる場合は、KDCがこの値に基づいて動作することをお勧めします。
otp-algID This field MAY be used by the client to send the identifier of the OTP algorithm used, as reported by the OTP token. Use of this element is OPTIONAL, but it MAY be used by the client to simplify the OTP calculations carried out by the KDC. It is RECOMMENDED that the KDC act upon this value, if it is present in the request and it is capable of using it in the generation of the OTP value. The value of this field MUST be a URI [RFC3986] and SHOULD be obtained from the PSKC algorithm registry [RFC6030].
otp-algIDこのフィールドは、OTPトークンによって報告されるように、クライアントが使用するOTPアルゴリズムの識別子を送信するために使用できます。この要素の使用はオプションですが、KDCによって実行されるOTP計算を簡略化するためにクライアントが使用する場合があります。 KDCが要求に存在し、OTP値の生成に使用できる場合は、KDCがこの値に基づいて動作することをお勧めします。このフィールドの値はURI [RFC3986]である必要があり、PSKCアルゴリズムレジストリ[RFC6030]から取得する必要があります（SHOULD）。
otp-vendor If the PA-OTP-REQUEST is being sent in response to a PA-OTP-CHALLENGE that contained an otp-vendor field in the selected otp-tokenInfo, then this field MUST be set to the same value; otherwise, this field SHOULD be set to the vendor identifier of the token, if known to the client. It is RECOMMENDED that the KDC act upon this value if it is present in the request and it is capable of using it in the generation of the OTP value.
otp-vendor選択したotp-tokenInfoにotp-vendorフィールドを含むPA-OTP-CHALLENGEへの応答としてPA-OTP-REQUESTが送信されている場合、このフィールドは同じ値に設定する必要があります。それ以外の場合、このフィールドは、クライアントが知っている場合は、トークンのベンダーIDに設定する必要があります（SHOULD）。 KDCがリクエストに存在し、OTP値の生成に使用できる場合は、KDCがこの値に基づいて動作することをお勧めします。
The padata-type PA-OTP-PIN-CHANGE is returned by the KDC in the enc-fast-rep of a PA-FX-FAST-REPLY in the AS-REP if the user must change their PIN, if the user's PIN has been changed, or to notify the user of the PIN's expiry time.
ユーザーのPINを変更する必要がある場合、ユーザーのPINを変更する必要がある場合、padata-type PA-OTP-PIN-CHANGEは、KDCによってAS-REPのPA-FX-FAST-REPLYのenc-fast-repで返されます。変更されたか、PINの有効期限をユーザーに通知します。
The corresponding padata-value field contains the DER encoding of a PA-OTP-PIN-CHANGE.
対応するpadata-valueフィールドには、PA-OTP-PIN-CHANGEのDERエンコードが含まれています。
PA-OTP-PIN-CHANGE 144
PA-OTP-PIN-CHANGE 144
PA-OTP-PIN-CHANGE ::= SEQUENCE {
flags [0] PinFlags,
pin [1] UTF8String OPTIONAL,
minLength [2] INTEGER OPTIONAL,
maxLength [3] INTEGER OPTIONAL,
last-req [4] LastReq OPTIONAL,
format [5] OTPFormat OPTIONAL,
...
}
PinFlags ::= KerberosFlags
-- reserved(0),
-- systemSetPin(1),
-- mandatory(2)
flags The "systemSetPin" flag is used to indicate the type of PIN change that is taking place. If the flag is set, then the user's PIN has been changed for the user by the system. If the flag is not set, then the user's PIN needs to be changed by the user.
フラグ「systemSetPin」フラグは、行われているPIN変更のタイプを示すために使用されます。フラグが設定されている場合、ユーザーのPINはシステムによってユーザーに対して変更されています。フラグが設定されていない場合、ユーザーのPINをユーザーが変更する必要があります。
If the "systemSetPin" flag is not set and the "mandatory" flag is set, then user PIN change is required before the next authentication using the current OTP token. If the "mandatory" flag is not set, then the user PIN change is optional. If the
「systemSetPin」フラグが設定されておらず、「必須」フラグが設定されている場合、現在のOTPトークンを使用する次の認証の前にユーザーPINの変更が必要です。 「必須」フラグが設定されていない場合、ユーザーPINの変更はオプションです。もし
"systemSetPin" flag is set, then the "mandatory" flag has no meaning and SHOULD be ignored by the client.
「systemSetPin」フラグが設定されている場合、「必須」フラグは意味がなく、クライアントによって無視されるべきです（SHOULD）。
pin The pin field is used to carry a new PIN value. If the "systemSetPin" flag is set, then the pin field is used to carry the new PIN value set for the user and MUST be present. If the "systemSetPin" flag is not set, then use of this field is OPTIONAL and MAY be used to carry a system-generated PIN that MAY be used by the user when changing the PIN.
pin pinフィールドは、新しいPIN値を伝えるために使用されます。 「systemSetPin」フラグが設定されている場合、ピンフィールドはユーザーに設定された新しいPIN値を伝えるために使用され、存在しなければなりません。 「systemSetPin」フラグが設定されていない場合、このフィールドの使用はオプションであり、ユーザーがPINを変更するときに使用できるシステム生成のPINを運ぶために使用できます。
minLength and maxLength Use of the minLength and maxLength fields is OPTIONAL. If the "systemSetPin" flag is not set, then these fields MAY be included to pass restrictions on the size of the user-selected PIN.
minLengthおよびmaxLength minLengthおよびmaxLengthフィールドの使用はオプションです。 「systemSetPin」フラグが設定されていない場合は、これらのフィールドを含めて、ユーザーが選択したPINのサイズの制限を渡すことができます。
last-req Use of the last-req field (as defined in Section 5.4.2 of [RFC4120])) is OPTIONAL, but MAY be included with an lr-type of 6 to carry PIN expiration information.
last-req（[RFC4120]のセクション5.4.2で定義されている）last-reqフィールドの使用はオプションですが、PINの有効期限情報を伝えるために、lrタイプ6に含めることができます（MAY）。
* If the "systemSetPin" flag is set, then the expiration time MUST be that of the new system-set PIN.
* 「systemSetPin」フラグが設定されている場合、有効期限は新しいシステム設定のPINの有効期限でなければなりません。
* If the "systemSetPin" flag is not set, then the expiration time MUST be that of the current PIN of the token used in the authentication.
* 「systemSetPin」フラグが設定されていない場合、有効期限は、認証で使用されるトークンの現在のPINの有効期限でなければなりません。
The element MAY also be included with an lr-type of 7 to indicate when the OTP account will expire.
要素は、OTPアカウントの有効期限が切れるときを示すために、lr-type 7とともに含めることもできます（MAY）。
format The format element MAY be included by the KDC to carry format restrictions on the new PIN.
format format要素は、新しいPINのフォーマット制限を伝えるためにKDCによって含まれる場合があります。
* If the "systemSetPin" flag is set, then the element MUST describe the format of the new system-generated PIN.
* 「systemSetPin」フラグが設定されている場合、要素はシステムで生成された新しいPINの形式を記述しなければなりません（MUST）。
* If the "systemSetPin" flag is not set, then the element MUST describe restrictions on any new user-generated PIN.
* 「systemSetPin」フラグが設定されていない場合、要素は新しいユーザー生成のPINの制限を記述しなければなりません（MUST）。
The OTP algorithm identifier URIs used as otp-algID values in the PA-OTP-CHALLENGE described in Section 4.1 and the PA-OTP-REQUEST described in Section 4.2 have been registered in the "Algorithm URI Registry and Related PSKC Profiles" registry [RFC6030].
セクション4.1で説明されているPA-OTP-CHALLENGEおよびセクション4.2で説明されているPA-OTP-REQUESTでotp-algID値として使用されるOTPアルゴリズム識別子URIは、「アルゴリズムURIレジストリと関連PSKCプロファイル」レジストリ[RFC6030に登録されています。 ]。
The following pre-authentication types are defined in this document:
このドキュメントでは、次の事前認証タイプが定義されています。
PA-OTP-CHALLENGE 141 PA-OTP-REQUEST 142 PA-OTP-PIN-CHANGE 144
PA-OTP-CHALLENGE 141 PA-OTP-REQUEST 142 PA-OTP-PIN-CHANGE 144
Note that PA-OTP-CONFIRM (143) has been marked as OBSOLETE per this document.
このドキュメントでは、PA-OTP-CONFIRM（143）がOBSOLETEとしてマークされていることに注意してください。
These values are currently registered in a registry created by [RFC6113], but the entries have been updated to refer to this document.
これらの値は現在[RFC6113]によって作成されたレジストリに登録されていますが、このドキュメントを参照するようにエントリが更新されています。
The following error codes and key usage values are defined in this document:
このドキュメントでは、次のエラーコードとキー使用法の値が定義されています。
KDC_ERR_INVALID_HASH_ALG 94 KDC_ERR_INVALID_ITERATION_COUNT 95 KDC_ERR_PIN_EXPIRED 96 KDC_ERR_PIN_REQUIRED 97 KEY_USAGE_OTP_REQUEST 45
KDC_ERR_INVALID_HASH_ALG 94 KDC_ERR_INVALID_ITERATION_COUNT 95 KDC_ERR_PIN_EXPIRED 96 KDC_ERR_PIN_REQUIRED 97 KEY_USAGE_OTP_REQUEST 45
These values are currently not managed by IANA and have not been accounted for. There is currently work in progress [LHA10] to define IANA registries and a registration process for these values.
これらの値は現在IANAによって管理されておらず、考慮されていません。 IANAレジストリとこれらの値の登録プロセスを定義するための作業が現在進行中[LHA10]です。
In the system described in this document, the OTP pre-authentication protocol is tunneled within the FAST Armor channel provided by the pre-authentication framework. As described in [ASNINY02], tunneled protocols are potentially vulnerable to man-in-the-middle (MITM) attacks if the outer tunnel is compromised, and it is generally considered good practice in such cases to bind the inner encryption to the outer tunnel.
このドキュメントで説明するシステムでは、OTP事前認証プロトコルは、事前認証フレームワークによって提供されるFAST Armorチャネル内でトンネリングされます。 [ASNINY02]で説明されているように、トンネル化されたプロトコルは、外部トンネルが危険にさらされている場合、中間者攻撃（MITM）攻撃に対して潜在的に脆弱であり、そのような場合、内部暗号化を外部トンネルにバインドすることは、一般的に良い習慣と考えられています。 。
In order to mitigate against such attacks, the proposed system uses the outer Armor Key in the derivation of the inner Client and Reply keys and so achieves crypto-binding to the outer channel.
このような攻撃を軽減するために、提案されたシステムは、内部クライアントおよび返信キーの派生に外部アーマーキーを使用し、外部チャネルへの暗号化バインディングを実現します。
As described in Section 5.4 of [RFC6113], FAST can use an anonymous Ticket-Granting Ticket (TGT) obtained using anonymous Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) [RFC6112] [RFC4556] as the Armor Key. However, the current anonymous PKINIT proposal is open to MITM attacks since the attacker can choose a session key such that the session key between the MITM and the real KDC is the same as the session key between the client and the MITM.
[RFC6113]のセクション5.4で説明されているように、FASTは、Kerberosの初期認証に匿名公開キー暗号化を使用して取得した匿名チケット許可チケット（TGT）（PKINIT）[RFC6112] [RFC4556]を鎧キーとして使用できます。ただし、攻撃者はMITMと実際のKDC間のセッションキーがクライアントとMITM間のセッションキーと同じになるようにセッションキーを選択できるため、現在の匿名PKINITプロポーザルはMITM攻撃に対してオープンです。
As described in Section 3.6, if the OTP value is not being sent to the KDC, then the Armor Key is used along with the OTP value in the generation of the Client Key and Reply Key. If the Armor Key is known, then the only entropy remaining in the key generation is provided by the OTP value. If the OTP algorithm requires that the OTP value be sent to the KDC, then it is sent encrypted within the tunnel provided by the FAST Armor and so, is exposed to the attacker if the attacker has the Armor Key.
セクション3.6で説明されているように、OTP値がKDCに送信されていない場合、クライアントキーと応答キーの生成では、OTP値とともにアーマーキーが使用されます。アーマーキーがわかっている場合、キー生成に残っている唯一のエントロピーはOTP値によって提供されます。 OTPアルゴリズムでODC値をKDCに送信する必要がある場合、その値はFASTアーマーによって提供されるトンネル内で暗号化されて送信されるため、攻撃者がアーマーキーを持っている場合は攻撃者に公開されます。
Therefore, unless the identity of the KDC has been verified, anonymous PKINIT SHALL NOT be used with OTP algorithms that require the OTP value to be sent to the KDC. In addition, the security considerations should be carefully considered before anonymous PKINIT is used with other algorithms such as those with short OTP values.
したがって、KDCのIDが検証されていない限り、OTP値をKDCに送信する必要があるOTPアルゴリズムでは、匿名のPKINITを使用しないでください。さらに、匿名のPKINITが短いOTP値のアルゴリズムなどの他のアルゴリズムで使用される前に、セキュリティの考慮事項を慎重に検討する必要があります。
Careful consideration should also be made if host key armor is used to provide the KDC-authentication facility with OTP algorithms where the OTP value is sent within the otp-value field of the PA-OTP-REQUEST since compromised host keys would allow an attacker to impersonate the KDC.
ホストキーアーマーを使用してKDC認証機能にOTPアルゴリズムを提供する場合も注意深く検討する必要があります。この場合、OTP値はPA-OTP-REQUESTのotp-valueフィールド内で送信され、攻撃者はホストキーを悪用して攻撃者に許可を与えます。 KDCを偽装します。
The four-pass system described above is a challenge-response protocol, and such protocols are potentially vulnerable to reflection attacks. No such attacks are known at this point, but to help mitigate against such attacks, the system uses different keys to encrypt the client and server nonces.
上記の4パスシステムはチャレンジ/レスポンスプロトコルであり、そのようなプロトコルはリフレクション攻撃に対して潜在的に脆弱です。このような攻撃は現時点では判明していませんが、このような攻撃を軽減するために、システムは異なるキーを使用してクライアントとサーバーのナンスを暗号化します。
The protocol supports the use of an iteration count in the generation of the Client and Reply keys, and the client can send the number of iterations used as part of the PA-OTP-REQUEST. This could open the KDC up to a denial-of-service attack if a large value for the iteration count was specified by the attacker. It is therefore, particularly important that, as described in Section 3.4, the KDC reject any authentication requests where the iteration count is above a maximum value specified by local policy.
このプロトコルは、クライアントキーと返信キーの生成における反復回数の使用をサポートしており、クライアントはPA-OTP-REQUESTの一部として使用される反復回数を送信できます。これにより、攻撃者が反復回数に大きな値を指定した場合、KDCがサービス拒否攻撃を受ける可能性があります。したがって、特に重要なのは、3.4で説明したように、KDCが、反復回数がローカルポリシーで指定された最大値を超えている認証要求を拒否することです。
In the four-pass version of this protocol, the client encrypts a KDC-generated nonce, so replay can be detected by the KDC. The two-pass version of the protocol does not involve a server nonce; the client instead encrypts a timestamp, and therefore is not protected from replay in this way, but it will instead require some other mechanism, such as an OTP-server-based system or a timestamp-based replay cache on the KDC.
このプロトコルの4パスバージョンでは、クライアントはKDCで生成されたナンスを暗号化するため、KDCでリプレイを検出できます。プロトコルの2パスバージョンにはサーバーナンスは含まれません。代わりに、クライアントはタイムスタンプを暗号化するため、この方法での再生から保護されませんが、代わりに、OTPサーバーベースのシステムやKDC上のタイムスタンプベースの再生キャッシュなど、他のメカニズムが必要になります。
As described in Section 5.2 of [RFC6113], a client cannot be certain that it will use the same KDC for all messages in a conversation. Therefore, the client cannot assume that the PA-OTP-REQUEST will be sent to the same KDC that issued the PA-OTP-CHALLENGE. In order to support this, a KDC implementing this protocol requires a means of sharing session state. However, doing this does introduce the possibility of a replay attack where the same response is sent to multiple KDCs.
[RFC6113]のセクション5.2で説明されているように、クライアントは、会話内のすべてのメッセージに同じKDCを使用することを確信できません。したがって、クライアントは、PA-OTP-REQUESTが、PA-OTP-CHALLENGEを発行した同じKDCに送信されると想定することはできません。これをサポートするために、このプロトコルを実装するKDCはセッション状態を共有する手段を必要とします。ただし、これを行うと、同じ応答が複数のKDCに送信されるリプレイ攻撃の可能性が生じます。
In the case of time- or event-based tokens or server-generated challenges, protection against replay may be provided by the OTP server being used if that server is capable of keeping track of the last used value. This protection therefore relies upon the assumption that the OTP server being used in this protocol is either not redundant or involves a commit protocol to synchronize between replicas. If this does not hold for an OTP server being used, then the system may be vulnerable to replay attacks.
時間ベースまたはイベントベースのトークンまたはサーバー生成のチャレンジの場合、OTPサーバーが最後に使用された値を追跡できる場合、使用されているOTPサーバーによって再生に対する保護が提供される場合があります。したがって、この保護は、このプロトコルで使用されているOTPサーバーが冗長ではないか、レプリカ間で同期するためのコミットプロトコルを含むという想定に依存しています。これが使用されているOTPサーバーに当てはまらない場合、システムはリプレイ攻撃に対して脆弱である可能性があります。
However, OTP servers may not be able to detect replay of OTPs generated using only a client-generated challenge; since, the KDC would not be able to detect replay in two-pass mode, it is recommended that the use of OTPs generated from only a client-generated challenge (that is, not in combination with some other factor such as time) should not be supported in two-pass mode.
ただし、OTPサーバーは、クライアントが生成したチャレンジのみを使用して生成されたOTPのリプレイを検出できない場合があります。 KDCは2パスモードでのリプレイを検出できないため、クライアントが生成したチャレンジのみから生成された（つまり、時間などの他の要因と組み合わせていない）OTPを使用しないことをお勧めします。 2パスモードでサポートされます。
A compromised or hostile KDC may be able to obtain the OTP value used by the client via a brute-force attack. If the OTP value is short, then the KDC could iterate over the possible OTP values until a Client Key is generated that can decrypt the encData sent in the PA-OTP-REQUEST.
侵害された、または敵意のあるKDCは、ブルートフォース攻撃を介してクライアントが使用するOTP値を取得できる可能性があります。 OTP値が短い場合、KDCは、PA-OTP-REQUESTで送信されたencDataを復号化できるクライアントキーが生成されるまで、可能なOTP値を繰り返します。
As described in Section 3.6, an iteration count can be used in the generation of the Client Key and the value of the iteration count can be controlled by local client policy. Use of this iteration count can make it computationally infeasible/unattractive for an attacker to brute-force search for the given OTP within the lifetime of that OTP.
セクション3.6で説明されているように、クライアントキーの生成に反復回数を使用でき、反復回数の値はローカルクライアントポリシーによって制御できます。この反復回数を使用すると、攻撃者がそのOTPの存続期間内に特定のOTPをブルートフォース検索することを計算上実行不可能/魅力的でなくすることができます。
If PINs contain international characters, similar looking or similar functioning characters may be mapped together. For example, the combined and decomposed forms of accented characters will typically be treated the same. Users who attempt to exploit artifacts of international characters to improve the strength of their PINs may experience false positives in the sense that PINs they intended to be distinct are not actually distinct. This decision was made in order to improve usability across the widest variety of input methods. Users can choose other methods to add strength to PINs.
PINに国際的な文字が含まれている場合、似たような文字や機能している文字が一緒にマッピングされることがあります。たとえば、アクセント付き文字の結合形式と分解形式は、通常同じように扱われます。国際文字のアーティファクトを悪用してPINの強度を向上させようとするユーザーは、区別するつもりのPINは実際には区別されないという意味で誤検知を経験する可能性があります。この決定は、さまざまな入力方法の使いやすさを向上させるために行われました。ユーザーは他の方法を選択してPINに強度を追加できます。
The secret used to generate the OTP is known only to the client and the KDC, so successful decryption of the encrypted nonce by the KDC authenticates the user. If the OTP value is used in the Reply Key generation, then successful decryption of the encrypted nonce by the client proves that the expected KDC replied. The Reply Key is replaced by either a key generated from the OTP and Armor Key or by the Armor Key. This FAST factor therefore, provides the following facilities: client-authentication, replacing-reply-key, and, depending on the OTP algorithm, KDC-authentication.
OTPの生成に使用されるシークレットはクライアントとKDCだけが知っているため、KDCによる暗号化されたナンスの復号化が成功すると、ユーザーが認証されます。返信キーの生成にOTP値が使用されている場合、クライアントによる暗号化されたナンスの正常な復号化は、予期されたKDCが応答したことを証明します。返信キーは、OTPとアーマーキーから生成されたキー、またはアーマーキーに置き換えられます。したがって、このFAST要素は、クライアント認証、置換応答キー、およびOTPアルゴリズムに応じてKDC認証という機能を提供します。
Many significant contributions were made to this document by RSA employees, but special thanks go to Magnus Nystrom, John Linn, Richard Zhang, Piers Bowness, Robert Philpott, Robert Polansky, and Boris Khoutorski.
RSAの従業員はこのドキュメントに多くの重要な貢献をしてくれましたが、マグナスニストロム、ジョンリン、リチャードチャン、ピアスボウネス、ロバートフィルポット、ロバートポランスキー、ボリスクトールスキーに感謝します。
Many valuable suggestions were also made by members of the Kerberos Working Group, but special thanks go to Larry Zhu, Jeffrey Hutzelman, Tim Alsop, Henry Hotz, Nicolas Williams, Sam Hartman, Frank Cusak, Simon Josefsson, Greg Hudson, and Linus Nordberg.
Kerberosワーキンググループのメンバーからも多くの貴重な提案がありましたが、ラリーチュー、ジェフリーハッツェルマン、ティムアルソップ、ヘンリーホッツ、ニコラスウィリアムズ、サムハートマン、フランククサック、サイモンジョセフソン、グレッグハドソン、およびライナスノードバーグに特に感謝します。
I would also like to thank Tim Alsop and Srinivas Cheruku of CyberSafe for many valuable review comments.
また、CyberSafeのTim Alsop氏とSrinivas Cheruku氏にも多くの貴重なレビューコメントをいただきました。
[ISOIEC7812] ISO, "ISO/IEC 7812-1:2006 Identification cards -- Identification of issuers -- Part 1: Numbering system", October 2006, <http://www.iso.org/iso/iso_catalogue/ catalogue_tc/catalogue_detail.htm?csnumber=39698>.
[ISOIEC7812] ISO、「ISO / IEC 7812-1：2006識別カード-発行者の識別-パート1：ナンバリングシステム」、2006年10月、<http://www.iso.org/iso/iso_catalogue/ catalogue_tc / catalogue_detail.htm？csnumber = 39698>。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、RFC 2045、1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, February 2005.
[RFC3961] Raeburn、K。、「Kerberos 5の暗号化とチェックサムの仕様」、RFC 3961、2005年2月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[RFC4013] Zeilenga、K。、「SASLprep：Stringprep Profile for User Names and Passwords」、RFC 4013、2005年2月。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086] Eastlake 3rd、D.、Schiller、J.、and S. Crocker、 "Randomness Requirements for Security"、BCP 106、RFC 4086、June 2005。
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[RFC4120] Neuman、C.、Yu、T.、Hartman、S。、およびK. Raeburn、「The Kerberos Network Authentication Service（V5）」、RFC 4120、2005年7月。
[RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
[RFC4556] Zhu、L。、およびB. Tung、「Kerberosでの初期認証のための公開鍵暗号化（PKINIT）」、RFC 4556、2006年6月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、2008年5月。
[RFC6112] Zhu, L., Leach, P., and S. Hartman, "Anonymity Support for Kerberos", RFC 6112, April 2011.
[RFC6112] Zhu、L.、Leach、P。、およびS. Hartman、「Kerberosの匿名サポート」、RFC 6112、2011年4月。
[RFC6113] Hartman, S. and L. Zhu, "A Generalized Framework for Kerberos Pre-Authentication", RFC 6113, April 2011.
[RFC6113] Hartman、S。およびL. Zhu、「Kerberos事前認証の一般化されたフレームワーク」、RFC 6113、2011年4月。
[X.680] ITU-T, "Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation.", July 2002.
[X.680] ITU-T、「Recommendation X.680（2002）| ISO / IEC 8824-1：2002、Information technology-Abstract Syntax Notation One（ASN.1）：Specification of basic notation。」、2002年7月。
[X.690] ITU-T, "Recommendation X.690 (2008) | ISO/IEC 8825-1:2008, X.690 : Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", December 2008.
[X.690] ITU-T、「Recommendation X.690（2008）| ISO / IEC 8825-1：2008、X.690：Information technology-ASN.1 encoding rules：Specification of Basic Encoding Rules（BER）、Canonicalエンコーディングルール（CER）およびDistinguished Encoding Rules（DER）」、2008年12月。
[ASNINY02] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle in Tunneled Authentication Protocols", Cryptology ePrint Archive Report 2002/163, November 2002.
[ASNINY02] Asokan、N.、Niemi、V。、およびK. Nyberg、「トンネル認証プロトコルの中間者」、Cryptology ePrint Archive Report 2002 / 163、2002年11月。
[HORENEZ004] Horstein, K., Renard, K., Neuman, C., and G. Zorn, "Integrating Single-use Authentication Mechanisms with Kerberos", Work in Progress, July 2004.
[HORENEZ004] Horstein、K.、Renard、K.、Neuman、C。、およびG. Zorn、「シングルユース認証メカニズムとKerberosの統合」、作業中、2004年7月。
[LHA10] Hornquist Astrand, L., "Kerberos number registry to IANA", Work in Progress, March 2010.
[LHA10] Hornquist Astrand、L。、「IANAへのKerberos番号レジストリ」、Work in Progress、2010年3月。
[RFC2289] Haller, N., Metz, C., Nesser, P., and M. Straw, "A One-Time Password System", STD 61, RFC 2289, February 1998.
[RFC2289] Haller、N.、Metz、C.、Nesser、P。、およびM. Straw、「A One-Time Password System」、STD 61、RFC 2289、1998年2月。
[RFC2808] Nystrom, M., "The SecurID(r) SASL Mechanism", RFC 2808, April 2000.
[RFC2808] Nystrom、M。、「The SecurID（r）SASLメカニズム」、RFC 2808、2000年4月。
[RFC4226] M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and O. Ranen, "HOTP: An HMAC-Based One-Time Password Algorithm", RFC 4226, December 2005.
[RFC4226] M'Raihi、D.、Bellare、M.、Hoornaert、F.、Naccache、D。、およびO. Ranen、「HOTP：An HMAC-Based One-Time Password Algorithm」、RFC 4226、2005年12月。
[RFC6030] Hoyer, P., Pei, M., and S. Machani, "Portable Symmetric Key Container (PSKC)", RFC 6030, October 2010.
[RFC6030] Hoyer、P.、Pei、M。、およびS. Machani、「Portable Symmetric Key Container（PSKC）」、RFC 6030、2010年10月。
OTPKerberos
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
輸入
KerberosTime, KerberosFlags, EncryptionKey, Int32,
EncryptedData, LastReq, KerberosString
FROM KerberosV5Spec2 {iso(1) identified-organization(3)
dod(6) internet(1) security(5)
kerberosV5(2) modules(4) krb5spec2(2)}
-- as defined in RFC 4120.
AlgorithmIdentifier
FROM PKIX1Explicit88 { iso (1) identified-organization (3)
dod (6) internet (1)
security (5) mechanisms (5) pkix (7)
id-mod (0) id-pkix1-explicit (18) };
-- As defined in RFC 5280.
PA-OTP-CHALLENGE ::= SEQUENCE {
nonce [0] OCTET STRING,
otp-service [1] UTF8String OPTIONAL,
otp-tokenInfo [2] SEQUENCE (SIZE(1..MAX)) OF
OTP-TOKENINFO,
salt [3] KerberosString OPTIONAL,
s2kparams [4] OCTET STRING OPTIONAL,
...
}
OTP-TOKENINFO ::= SEQUENCE {
flags [0] OTPFlags,
otp-vendor [1] UTF8String OPTIONAL,
otp-challenge [2] OCTET STRING (SIZE(1..MAX))
OPTIONAL,
otp-length [3] Int32 OPTIONAL,
otp-format [4] OTPFormat OPTIONAL,
otp-tokenID [5] OCTET STRING OPTIONAL,
otp-algID [6] AnyURI OPTIONAL,
supportedHashAlg [7] SEQUENCE OF AlgorithmIdentifier
OPTIONAL,
iterationCount [8] Int32 OPTIONAL,
...
}
OTPFormat ::= INTEGER {
decimal(0),
hexadecimal(1),
alphanumeric(2),
binary(3),
base64(4)
}
OTPFlags ::= KerberosFlags
-- reserved(0),
-- nextOTP(1),
-- combine(2),
-- collect-pin(3),
-- do-not-collect-pin(4),
-- must-encrypt-nonce (5),
-- separate-pin-required (6),
-- check-digit (7)
PA-OTP-REQUEST ::= SEQUENCE {
flags [0] OTPFlags,
nonce [1] OCTET STRING OPTIONAL,
encData [2] EncryptedData,
-- PA-OTP-ENC-REQUEST or PA-ENC-TS-ENC
-- Key usage of KEY_USAGE_OTP_REQUEST
hashAlg [3] AlgorithmIdentifier OPTIONAL,
iterationCount [4] Int32 OPTIONAL,
otp-value [5] OCTET STRING OPTIONAL,
otp-pin [6] UTF8String OPTIONAL,
otp-challenge [7] OCTET STRING (SIZE(1..MAX)) OPTIONAL,
otp-time [8] KerberosTime OPTIONAL,
otp-counter [9] OCTET STRING OPTIONAL,
otp-format [10] OTPFormat OPTIONAL,
otp-tokenID [11] OCTET STRING OPTIONAL,
otp-algID [12] AnyURI OPTIONAL,
otp-vendor [13] UTF8String OPTIONAL,
...
}
PA-OTP-ENC-REQUEST ::= SEQUENCE {
nonce [0] OCTET STRING,
...
}
PA-OTP-PIN-CHANGE ::= SEQUENCE {
flags [0] PinFlags,
pin [1] UTF8String OPTIONAL,
minLength [2] INTEGER OPTIONAL,
maxLength [3] INTEGER OPTIONAL,
last-req [4] LastReq OPTIONAL,
format [5] OTPFormat OPTIONAL,
... }
。。。 ｝
PinFlags ::= KerberosFlags
-- reserved(0),
-- systemSetPin(1),
-- mandatory(2)
AnyURI ::= UTF8String
(CONSTRAINED BY {
-- MUST be a valid URI in accordance with IETF RFC 2396
})
END
終わり
This section is non-normative.
このセクションは非規範的です。
In this mode, the client sends an initial AS-REQ to the KDC that does not contain a PA-OTP-REQUEST and the KDC responds with a KRB-ERROR containing a PA-OTP-CHALLENGE.
このモードでは、クライアントはPA-OTP-REQUESTを含まないKDCに初期AS-REQを送信し、KDCはPA-OTP-CHALLENGEを含むKRB-ERRORで応答します。
In this example, the user has been issued with a connected, time-based token, and the KDC requires hashed OTP values in the key generation with SHA-384 as the preferred hash algorithm and a minimum of 1024 iterations. The local policy on the client supports SHA-256 and requires 100,000 iterations of the hash of the OTP value.
この例では、ユーザーは接続された時間ベースのトークンを使用して発行されており、KDCは、優先されるハッシュアルゴリズムとしてSHA-384と最小1024回の反復を使用して、キー生成でハッシュされたOTP値を必要とします。クライアントのローカルポリシーはSHA-256をサポートし、OTP値のハッシュを100,000回繰り返す必要があります。
The basic sequence of steps involved is as follows:
関連するステップの基本的なシーケンスは次のとおりです。
1. The client obtains the user name of the user.
1. クライアントはユーザーのユーザー名を取得します。
2. The client sends an initial AS-REQ to the KDC that does not contain a PA-OTP-REQUEST.
2. クライアントは、PA-OTP-REQUESTを含まないKDCに初期AS-REQを送信します。
3. The KDC determines that the user identified by the AS-REQ requires OTP authentication.
3. KDCは、AS-REQによって識別されたユーザーがOTP認証を必要とすることを決定します。
4. The KDC constructs a PA-OTP-CHALLENGE as follows:
4. KDCは、PA-OTP-CHALLENGEを次のように構築します。
nonce A randomly generated value.
nonceランダムに生成された値。
otp-service A string that can be used by the client to assist the user in locating the correct token.
otp-serviceユーザーが正しいトークンを見つけるのを支援するためにクライアントが使用できる文字列。
otp-tokenInfo Information about how the OTP should be generated from the token.
otp-tokenInfoトークンからOTPを生成する方法に関する情報。
flags must-encrypt-nonce and collect-pin bits set
フラグmust-encrypt-nonceおよびcollect-pinビットセット
supportedHashAlg AlgorithmIdentifiers for SHA-384, SHA-256, and SHA-1
SHA-384、SHA-256、およびSHA-1のsupportedHashAlg AlgorithmIdentifiers
iterationCount 1024
iterationCount 1024
5. The KDC returns a KRB-ERROR with an error code of KDC_ERR_PREAUTH_REQUIRED and the PA-OTP-CHALLENGE in the e-data.
5. KDCは、KDC_ERR_PREAUTH_REQUIREDのエラーコードとPA-OTP-CHALLENGEを含むKRB-ERRORを電子データで返します。
6. The client displays the value of otp-service and prompts the user to connect the token.
6. クライアントはotp-serviceの値を表示し、ユーザーにトークンを接続するように求めます。
7. The client collects a PIN from the user.
7. クライアントはユーザーからPINを収集します。
8. The client obtains the current OTP value from the token using the PIN and records the time as reported by the token.
8. クライアントはPINを使用してトークンから現在のOTP値を取得し、トークンによって報告された時間を記録します。
9. The client generates the Client Key and Reply Key as described in Section 3.6 using SHA-256 from the list of algorithms sent by the KDC, the iteration count of 100,000 as required by local policy, and a randomly generated nonce.
9. クライアントは、KDCによって送信されたアルゴリズムのリストからSHA-256を使用して、セクション3.6で説明されているようにクライアントキーと応答キー、ローカルポリシーで必要な100,000の反復回数、およびランダムに生成されたナンスを生成します。
10. The client constructs a PA-OTP-REQUEST as follows:
10. クライアントは、PA-OTP-REQUESTを次のように作成します。
flags 0
フラグ0
nonce The randomly generated value.
nonceランダムに生成された値。
encData An EncryptedData containing a PA-OTP-ENC-REQUEST encrypted under the Client Key with a key usage of KEY_USAGE_OTP_REQUEST and the encryption type of the Armor Key. The PA-OTP-ENC-REQUEST contains the nonce from the PA-OTP-CHALLENGE.
encData KEY_USAGE_OTP_REQUESTのキー使用法とアーマーキーの暗号化タイプでクライアントキーの下で暗号化されたPA-OTP-ENC-REQUESTを含むEncryptedData。 PA-OTP-ENC-REQUESTには、PA-OTP-CHALLENGEからのノンスが含まれています。
hashAlg SHA-256
ハッシュラグSh-256
iterationCount 100,000
iterationCount 100,000
otp-time The time used in the OTP calculation as reported by the OTP token.
otp-time OTPトークンによって報告されるOTP計算で使用される時間。
11. The client encrypts the PA-OTP-REQUEST within the enc-fast-req of a PA-FX-FAST-REQUEST.
11. クライアントは、PA-FX-FAST-REQUESTのenc-fast-req内でPA-OTP-REQUESTを暗号化します。
12. The client sends an AS-REQ to the KDC containing the PA-FX-FAST-REQUEST within the padata.
12. クライアントは、padata内にPA-FX-FAST-REQUESTを含むAS-REQをKDCに送信します。
13. The KDC validates the padata in the PA-OTP-REQUEST by performing the following steps:
13. KDCは、次の手順を実行して、PA-OTP-REQUESTのpadataを検証します。
* Generates the Client Key and Reply Key from the OTP value for the user identified in the AS-REQ, using an iteration count of 100,000, a hash algorithm of SHA-256, and the nonce as specified in the PA-OTP-REQUEST.
* AS-REQで識別されたユーザーのOTP値から、100,000の反復回数、SHA-256のハッシュアルゴリズム、およびPA-OTP-REQUESTで指定されたナンスを使用して、クライアントキーと応答キーを生成します。
* Uses the generated Client Key to decrypt the PA-OTP-ENC-REQUEST in the encData of the PA-OTP-REQUEST.
* 生成されたクライアントキーを使用して、PA-OTP-REQUESTのencDataにあるPA-OTP-ENC-REQUESTを復号化します。
* Authenticates the user by comparing the nonce value from the decrypted PA-OTP-ENC-REQUEST to that sent in the corresponding PA-OTP-CHALLENGE.
* 復号化されたPA-OTP-ENC-REQUESTからのnonce値を、対応するPA-OTP-CHALLENGEで送信された値と比較することにより、ユーザーを認証します。
14. The KDC constructs a TGT for the user.
14. KDCはユーザーのTGTを作成します。
15. The KDC returns an AS-REP to the client, encrypted using the Reply Key, containing the TGT and padata with the PA-FX-FAST-REPLY.
15. KDCはAS-REPをクライアントに返し、返信キーを使用して暗号化され、PA-FX-FAST-REPLYでTGTおよびpadataが含まれています。
16.
１６。
The client authenticates the KDC and verifies the Reply Key change. The client uses the generated Reply Key to decrypt the encrypted data in the AS-REP.
クライアントはKDCを認証し、返信キーの変更を確認します。クライアントは、生成された返信キーを使用して、AS-REPの暗号化されたデータを復号化します。
In this mode, the client includes a PA-OTP-REQUEST within a PA-FX-FAST-REQUEST padata of the initial AS-REQ sent to the KDC.
このモードでは、クライアントは、KDCに送信された最初のAS-REQのPA-FX-FAST-REQUESTパデータ内にPA-OTP-REQUESTを含めます。
In this example, the user has been issued a hand-held token, so, none of the OTP generation parameters (otp-length, etc.) are included in the PA-OTP-REQUEST. The KDC does not require hashed OTP values in the key generation.
この例では、ユーザーにハンドヘルドトークンが発行されているため、OTP生成パラメーター（otp-lengthなど）はPA-OTP-REQUESTに含まれていません。 KDCは、キー生成でハッシュされたOTP値を必要としません。
It is assumed that the client has been configured with the following information or has obtained it from a previous PA-OTP-CHALLENGE.
クライアントは、以下の情報で構成されているか、以前のPA-OTP-CHALLENGEからそれを取得していると想定されています。
o The OTP value must not be carried in the otp-value.
o OTP値をotp-valueに含めないでください。
o The hashed OTP values are not required.
o ハッシュされたOTP値は必要ありません。
The basic sequence of steps involved is as follows:
関連するステップの基本的なシーケンスは次のとおりです。
1. The client obtains the user name and OTP value from the user.
1. クライアントは、ユーザーからユーザー名とOTP値を取得します。
2. The client generates the Client Key and Reply Key using unhashed OTP values as described in Section 3.6.
2. セクション3.6で説明するように、クライアントはハッシュされていないOTP値を使用してクライアントキーと応答キーを生成します。
3. The client constructs a PA-OTP-REQUEST as follows:
3. クライアントは、PA-OTP-REQUESTを次のように作成します。
flags 0
フラグ0
encData An EncryptedData containing a PA-ENC-TS-ENC encrypted under the Client Key with a key usage of KEY_USAGE_OTP_REQUEST and an encryption type of the Armor Key. The PA-ENC-TS-ENC contains the current client time.
encDataキーの使用法がKEY_USAGE_OTP_REQUESTで、暗号化タイプがアーマーキーであるクライアントキーで暗号化されたPA-ENC-TS-ENCを含むEncryptedData。 PA-ENC-TS-ENCには、現在のクライアント時刻が含まれています。
4. The client encrypts the PA-OTP-REQUEST within the enc-fast-req of a PA-FX-FAST-REQUEST.
4. クライアントは、PA-FX-FAST-REQUESTのenc-fast-req内でPA-OTP-REQUESTを暗号化します。
5. The client sends an AS-REQ to the KDC containing the PA-FX-FAST-REQUEST within the padata.
5. クライアントは、padata内にPA-FX-FAST-REQUESTを含むAS-REQをKDCに送信します。
6. The KDC validates the padata by performing the following steps:
6. KDCは、次の手順を実行してpadataを検証します。
* Generates the Client Key and Reply Key from the unhashed OTP value for the user identified in the AS-REQ.
* AS-REQで識別されたユーザーのハッシュされていないOTP値からクライアントキーと応答キーを生成します。
* Uses the generated Client Key to decrypt the PA-ENC-TS-ENC in the encData of the PA-OTP-REQUEST.
* 生成されたクライアントキーを使用して、PA-OTP-REQUESTのencDataにあるPA-ENC-TS-ENCを復号化します。
* Authenticates the user using the timestamp in the standard manner.
* 標準的な方法でタイムスタンプを使用してユーザーを認証します。
7. The KDC constructs a TGT for the user.
7. KDCはユーザーのTGTを作成します。
8. The KDC returns an AS-REP to the client, encrypted using the Reply Key, containing the TGT and padata with the PA-FX-FAST-REPLY.
8. KDCはAS-REPをクライアントに返し、返信キーを使用して暗号化され、PA-FX-FAST-REPLYでTGTおよびpadataが含まれています。
9. The client authenticates the KDC and verifies the key change. The client uses the generated Reply Key to decrypt the encrypted data in the AS-REP.
9. クライアントはKDCを認証し、キーの変更を確認します。クライアントは、生成された返信キーを使用して、AS-REPの暗号化されたデータを復号化します。
This exchange follows from the point where the KDC receives the PA-OTP-REQUEST from the client in the examples in Appendix B.1 and Appendix B.2. During the validation of the pre-authentication data (whether encrypted nonce or encrypted timestamp), the KDC determines that the user's PIN has expired and so, must be changed. The KDC therefore, includes a PA-OTP-PIN-CHANGE in the AS-REP.
この交換は、付録B.1および付録B.2の例で、KDCがクライアントからPA-OTP-REQUESTを受信した時点から続きます。事前認証データ（暗号化されたナンスまたは暗号化されたタイムスタンプ）の検証中に、KDCはユーザーのPINの有効期限が切れていると判断し、変更する必要があります。したがって、KDCにはAS-REPにPA-OTP-PIN-CHANGEが含まれています。
In this example, the KDC does not generate PIN values for the user but requires that the user generate a new PIN that is between 4 and 8 characters in length. The actual PIN change is handled by a PIN change service.
この例では、KDCはユーザーのPIN値を生成しませんが、ユーザーは4〜8文字の長さの新しいPINを生成する必要があります。実際のPINの変更は、PIN変更サービスによって処理されます。
The basic sequence of steps involved is as follows:
関連するステップの基本的なシーケンスは次のとおりです。
1. The client constructs and sends a PA-OTP-REQUEST to the KDC as described in the previous examples.
1. 前の例で説明したように、クライアントはPA-OTP-REQUESTを作成してKDCに送信します。
2. The KDC validates the pre-authentication data and authenticates the user as in the previous examples but determines that the user's PIN has expired.
2. KDCは事前認証データを検証し、前の例のようにユーザーを認証しますが、ユーザーのPINの有効期限が切れていると判断します。
3. The KDC constructs a PA-OTP-PIN-CHANGE as follows:
3. KDCは、PA-OTP-PIN-CHANGEを次のように構築します。
flags 0 minLength 4 maxLength 8
フラグ0 minLength 4 maxLength 8
4. The KDC encrypts the PA-OTP-PIN-CHANGE within the enc-fast-rep of a PA-FX-FAST-REPLY.
4. KDCは、PA-FX-FAST-REPLYのenc-fast-rep内でPA-OTP-PIN-CHANGEを暗号化します。
5. The KDC returns a KRB-ERROR to the client of type KDC_ERR_PIN_EXPIRED with padata containing the PA-FX-FAST-REPLY.
5. KDCは、PA-FX-FAST-REPLYを含むpadataを使用して、タイプKDC_ERR_PIN_EXPIREDのクライアントにKRB-ERRORを返します。
6. The client authenticates to the PIN change service and changes the user's PIN.
6. クライアントはPIN変更サービスに対して認証を行い、ユーザーのPINを変更します。
7. The client sends a second AS-REQ to the KDC containing a PA-OTP-REQUEST constructed using the new PIN.
7. クライアントは、新しいPINを使用して構築されたPA-OTP-REQUESTを含む2番目のAS-REQをKDCに送信します。
8. The KDC responds with an AS-REP containing a TGT.
8. KDCはTGTを含むAS-REPで応答します。
This exchange follows from the point where the KDC receives the PA-OTP-REQUEST from the client. During the validation of the pre-authentication data (whether encrypted nonce or encrypted timestamp), the KDC determines that the local record of the token's state needs to be resynchronized with the token. The KDC therefore, includes a KRB-ERROR containing a PA-OTP-CHALLENGE with the "nextOTP" flag set.
この交換は、KDCがクライアントからPA-OTP-REQUESTを受信した時点から続きます。事前認証データ（暗号化されたナンスまたは暗号化されたタイムスタンプのいずれか）の検証中に、KDCは、トークンの状態のローカルレコードをトークンと再同期する必要があると判断します。したがって、KDCには、「nextOTP」フラグが設定されたPA-OTP-CHALLENGEを含むKRB-ERRORが含まれています。
The sequence of steps below follows is a variation of the four pass examples shown in Appendix B.1 but the same process would also work in the two-pass case.
以下の一連のステップは、付録B.1に示す4つのパスの例のバリエーションですが、同じプロセスが2つのパスの場合にも機能します。
1. The client constructs and sends a PA-OTP-REQUEST to the KDC as described in the previous examples.
1. 前の例で説明したように、クライアントはPA-OTP-REQUESTを作成してKDCに送信します。
2. The KDC validates the pre-authentication data and authenticates the user as in the previous examples, but determines that user's token requires resynchronizing.
2. KDCは、前の例のように事前認証データを検証し、ユーザーを認証しますが、ユーザーのトークンの再同期が必要であると判断します。
3. KDC constructs a PA-OTP-CHALLENGE as follows:
3. KDCは、PA-OTP-CHALLENGEを次のように構築します。
nonce A randomly generated value.
nonceランダムに生成された値。
otp-service Set to a string that can be used by the client to assist the user in locating the correct token.
otp-serviceユーザーが正しいトークンを見つけやすくするためにクライアントが使用できる文字列に設定します。
otp-tokenInfo Information about how the OTP should be generated from the token.
otp-tokenInfoトークンからOTPを生成する方法に関する情報。
flags must-encrypt-nonce, collect-pin, and nextOTP bits set
フラグmust-encrypt-nonce、collect-pin、nextOTPビットセット
supportedHashAlg AlgorithmIdentifiers for SHA-256 and SHA-1
SHA-256およびSHA-1のsupportedHashAlg AlgorithmIdentifiers
iterationCount 1024
iterationCount 1024
4. KDC returns a KRB-ERROR with an error code of KDC_ERR_PREAUTH_REQUIRED and the PA-OTP-CHALLENGE in the e-data.
4. KDCは、KDC_ERR_PREAUTH_REQUIREDのエラーコードとe-dataのPA-OTP-CHALLENGEを含むKRB-ERRORを返します。
5. The client obtains the next OTP value from the token and records the time as reported by the token.
5. クライアントはトークンから次のOTP値を取得し、トークンによって報告された時間を記録します。
6. The client generates the Client Key and Reply Key as described in Section 3.6 using SHA-256 from the list of algorithms sent by the KDC, the iteration count of 100,000 as required by local policy, and a randomly generated nonce.
6. クライアントは、KDCによって送信されたアルゴリズムのリストからSHA-256を使用して、セクション3.6で説明されているようにクライアントキーと応答キー、ローカルポリシーで必要な100,000の反復回数、およびランダムに生成されたナンスを生成します。
7. The client constructs a PA-OTP-REQUEST as follows:
7. クライアントは、PA-OTP-REQUESTを次のように作成します。
flags nextOTP bit set
フラグnextOTPビットセット
nonce The randomly generated value.
nonceランダムに生成された値。
encData An EncryptedData containing a PA-OTP-ENC-REQUEST encrypted under the Client Key with a key usage of KEY_USAGE_OTP_REQUEST and the encryption type of the Armor Key. The PA-OTP-ENC-REQUEST contains the nonce from the PA-OTP-CHALLENGE.
encData KEY_USAGE_OTP_REQUESTのキー使用法とアーマーキーの暗号化タイプでクライアントキーの下で暗号化されたPA-OTP-ENC-REQUESTを含むEncryptedData。 PA-OTP-ENC-REQUESTには、PA-OTP-CHALLENGEからのノンスが含まれています。
hashAlg SHA-256
ハッシュラグSh-256
iterationCount 100,000
iterationCount 100,000
otp-time The time used in the OTP calculation as reported by the OTP token.
otp-time OTPトークンによって報告されるOTP計算で使用される時間。
8. The client encrypts the PA-OTP-REQUEST within the enc-fast-req of a PA-FX-FAST-REQUEST.
8. クライアントは、PA-FX-FAST-REQUESTのenc-fast-req内でPA-OTP-REQUESTを暗号化します。
9. The client sends an AS-REQ to the KDC containing the PA-FX-FAST-REQUEST within the padata.
9. クライアントは、padata内にPA-FX-FAST-REQUESTを含むAS-REQをKDCに送信します。
10. The authentication process now proceeds as with the classic sequence.
10. これで、認証プロセスは従来のシーケンスと同様に進行します。
Author's Address
著者のアドレス
Gareth Richards RSA, The Security Division of EMC RSA House Western Road Bracknell, Berkshire RG12 1RT UK
Gareth Richards RSA、EMC RSA Houseのセキュリティ部門Western Roadブラックネル、バークシャーRG12 1RT英国
EMail: gareth.richards@rsa.com