[要約] RFC 3962は、Kerberos 5認証プロトコルにおけるAdvanced Encryption Standard (AES) 暗号化の使用を規定しています。この文書の目的は、Kerberos 5のセキュリティを強化するために、より強力な暗号化アルゴリズムであるAESを導入することです。AES暗号化は、ネットワークセキュリティが重要な企業や組織での認証プロセスにおいて利用されます。このRFCは、Kerberosプロトコルのセキュリティを向上させるために、関連するRFCとしてRFC 4120（Kerberosプロトコルの仕様）やRFC 3961（Kerberosの暗号化とチェックサムの仕様）と密接に関連しています。
Network Working Group K. Raeburn
Request for Comments: 3962 MIT
Category: Standards Track February 2005
Advanced Encryption Standard (AES) Encryption for Kerberos 5
Kerberos 5 の Advanced Encryption Standard (AES) 暗号化
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネット コミュニティ向けのインターネット標準追跡プロトコルを指定し、改善のための議論と提案を求めます。このプロトコルの標準化状況とステータスについては、最新版の「インターネット公式プロトコル標準」(STD 1) を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権 (C) インターネット協会 (2005)。
Abstract
概要
The United States National Institute of Standards and Technology (NIST) has chosen a new Advanced Encryption Standard (AES), which is significantly faster and (it is believed) more secure than the old Data Encryption Standard (DES) algorithm. This document is a specification for the addition of this algorithm to the Kerberos cryptosystem suite.
米国国立標準技術研究所 (NIST) は、古いデータ暗号化標準 (DES) アルゴリズムよりも大幅に高速で安全である (と考えられている) 新しい高度暗号化標準 (AES) を選択しました。この文書は、このアルゴリズムを Kerberos 暗号化システム スイートに追加するための仕様です。
This document defines encryption key and checksum types for Kerberos 5 using the AES algorithm recently chosen by NIST. These new types support 128-bit block encryption and key sizes of 128 or 256 bits.
この文書では、NIST によって最近選択された AES アルゴリズムを使用した Kerberos 5 の暗号化キーとチェックサムのタイプを定義します。これらの新しいタイプは、128 ビットのブロック暗号化と 128 ビットまたは 256 ビットのキー サイズをサポートします。
Using the "simplified profile" of [KCRYPTO], we can define a pair of encryption and checksum schemes. AES is used with ciphertext stealing to avoid message expansion, and SHA-1 [SHA1] is the associated checksum function.
[KCRYPTO] の「簡易プロファイル」を使用すると、暗号化スキームとチェックサムスキームのペアを定義できます。AES はメッセージの拡張を回避するために暗号文の窃取で使用され、SHA-1 [SHA1] は関連するチェックサム関数です。
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 BCP 14, RFC 2119 [KEYWORDS].
この文書のキーワード「しなければならない」、「してはならない」、「必須」、「しなければならない」、「してはならない」、「すべきである」、「すべきではない」、「推奨」、「してもよい」、「任意」は次のとおりです。BCP 14、RFC 2119 [キーワード] に記載されているように解釈されます。
The profile in [KCRYPTO] treats keys and random octet strings as conceptually different. But since the AES key space is dense, we can use any bit string of appropriate length as a key. We use the byte representation for the key described in [AES], where the first bit of the bit string is the high bit of the first byte of the byte string (octet string) representation.
[KCRYPTO] のプロファイルは、キーとランダムなオクテット文字列を概念的に異なるものとして扱います。ただし、AES キー空間は高密度であるため、適切な長さの任意のビット文字列をキーとして使用できます。[AES] で説明されているキーのバイト表現を使用します。ここで、ビット文字列の最初のビットは、バイト文字列 (オクテット文字列) 表現の最初のバイトの上位ビットです。
Given the above format for keys, we can generate keys from the appropriate amounts of random data (128 or 256 bits) by simply copying the input string.
上記のキーの形式を考慮すると、入力文字列をコピーするだけで、適切な量のランダム データ (128 ビットまたは 256 ビット) からキーを生成できます。
To generate an encryption key from a pass phrase and salt string, we use the PBKDF2 function from PKCS #5 v2.0 ([PKCS5]), with parameters indicated below, to generate an intermediate key (of the same length as the desired final key), which is then passed into the DK function with the 8-octet ASCII string "kerberos" as is done for des3-cbc-hmac-sha1-kd in [KCRYPTO]. (In [KCRYPTO] terms, the PBKDF2 function produces a "random octet string", hence the application of the random-to-key function even though it's effectively a simple identity operation.) The resulting key is the user's long-term key for use with the encryption algorithm in question.
パスフレーズとソルト文字列から暗号化キーを生成するには、PKCS #5 v2.0 ([PKCS5]) の PBKDF2 関数を以下に示すパラメーターとともに使用して、中間キー (目的の最終キーと同じ長さ) を生成します。key)、[KCRYPTO] の des3-cbc-hmac-sha1-kd と同様に、8 オクテットの ASCII 文字列「kerberos」を使用して DK 関数に渡されます。([KCRYPTO] の用語では、PBKDF2 関数は「ランダムなオクテット文字列」を生成するため、実質的には単純な ID 操作であるにもかかわらず、random-to-key 関数が適用されます。) 結果として得られる鍵は、ユーザーの長期鍵です。問題の暗号化アルゴリズムで使用してください。
tkey = random2key(PBKDF2(passphrase, salt, iter_count, keylength))
key = DK(tkey, "kerberos")
The pseudorandom function used by PBKDF2 will be a SHA-1 HMAC of the passphrase and salt, as described in Appendix B.1 to PKCS#5.
PBKDF2 で使用される擬似ランダム関数は、PKCS#5 の付録 B.1 で説明されているように、パスフレーズとソルトの SHA-1 HMAC になります。
The number of iterations is specified by the string-to-key parameters supplied. The parameter string is four octets indicating an unsigned number in big-endian order. This is the number of iterations to be performed. If the value is 00 00 00 00, the number of iterations to be performed is 4,294,967,296 (2**32). (Thus the minimum expressible iteration count is 1.)
反復回数は、指定された string-to-key パラメーターによって指定されます。パラメータ文字列は、ビッグエンディアン順の符号なし数値を示す 4 オクテットです。これは実行される反復の数です。値が 00 00 00 00 の場合、実行される反復回数は 4,294,967,296 (2**32) です。(したがって、表現可能な最小反復回数は 1 です。)
For environments where slower hardware is the norm, implementations of protocols such as Kerberos may wish to limit the number of iterations to prevent a spoofed response supplied by an attacker from consuming lots of client-side CPU time; if such a limit is implemented, it SHOULD be no less than 50,000. Even for environments with fast hardware, 4 billion iterations is likely to take a fairly long time; much larger bounds might still be enforced, and it might be wise for implementations to permit interruption of this operation by the user if the environment allows for it.
低速のハードウェアが標準である環境では、攻撃者が提供する偽装応答がクライアント側の CPU 時間を大量に消費するのを防ぐために、Kerberos などのプロトコルの実装で反復回数を制限する必要がある場合があります。このような制限が実装される場合、それは 50,000 未満であってはなりません (SHOULD)。高速なハードウェアを備えた環境であっても、40 億回の反復にはかなり長い時間がかかる可能性があります。はるかに大きな境界が依然として適用される可能性があり、環境が許可する場合は、ユーザーによるこの操作の中断を実装で許可することが賢明かもしれません。
If the string-to-key parameters are not supplied, the value used is 00 00 10 00 (decimal 4,096, indicating 4,096 iterations).
string-to-key パラメータが指定されていない場合、使用される値は 00 00 10 00 (10 進数 4,096、4,096 回の反復を示します) です。
Note that this is not a requirement, nor even a recommendation, for this value to be used in "optimistic preauthentication" (e.g., attempting timestamp-based preauthentication using the user's long-term key without having first communicated with the KDC) in the absence of additional information, or as a default value for sites to use for their principals' long-term keys in their Kerberos database. It is simply the interpretation of the absence of the string-to-key parameter field when the KDC has had an opportunity to provide it.
これは、この値が「楽観的な事前認証」（たとえば、最初に KDC と通信せずにユーザーの長期キーを使用してタイムスタンプベースの事前認証を試みる）で使用されるための要件ではなく、推奨でもないことに注意してください。追加情報として、またはサイトが Kerberos データベース内のプリンシパルの長期キーとして使用するデフォルト値として使用されます。これは、KDC がそれを提供する機会があった場合に、string-to-key パラメータ フィールドが存在しないことを単に解釈したものです。
Sample test vectors are given in Appendix B.
サンプル テスト ベクトルは付録 B に記載されています。
Cipher block chaining is used to encrypt messages, with the initial vector stored in the cipher state. Unlike previous Kerberos cryptosystems, we use ciphertext stealing to handle the possibly partial final block of the message.
暗号ブロック チェーンはメッセージの暗号化に使用され、初期ベクトルが暗号状態に格納されます。以前の Kerberos 暗号システムとは異なり、暗号文の盗用を使用して、メッセージの部分的な最終ブロックを処理します。
Ciphertext stealing is described on pages 195-196 of [AC], and section 8 of [RC5]; it has the advantage that no message expansion is done during encryption of messages of arbitrary sizes as is typically done in CBC mode with padding. Some errata for [RC5] are listed in Appendix A and are considered part of the ciphertext stealing technique as used here.
暗号文の盗用については、[AC] の 195 ～ 196 ページと [RC5] のセクション 8 で説明されています。これには、パディングを使用した CBC モードで通常行われるような、任意のサイズのメッセージの暗号化中にメッセージ拡張が行われないという利点があります。[RC5] の一部の正誤表は付録 A にリストされており、ここで使用されている暗号文窃取手法の一部と見なされます。
Ciphertext stealing, as defined in [RC5], assumes that more than one block of plain text is available. If exactly one block is to be encrypted, that block is simply encrypted with AES (also known as ECB mode). Input smaller than one block is padded at the end to one block; the values of the padding bits are unspecified. (Implementations MAY use all-zero padding, but protocols MUST NOT rely on the result being deterministic. Implementations MAY use random padding, but protocols MUST NOT rely on the result not being deterministic. Note that in most cases, the Kerberos encryption profile will add a random confounder independent of this padding.)
[RC5] で定義されている暗号文窃盗は、複数の平文ブロックが利用可能であることを前提としています。1 つのブロックだけを暗号化する場合、そのブロックは単純に AES (ECB モードとも呼ばれる) で暗号化されます。1 ブロックより小さい入力は、最後に 1 ブロックにパディングされます。パディングビットの値は未指定です。(実装ではオールゼロのパディングを使用してもよいですが、プロトコルは結果が決定的であることに依存してはなりません。実装ではランダムなパディングを使用してもよいですが、プロトコルは結果が決定的ではないことに依存してはなりません。ほとんどの場合、Kerberos 暗号化プロファイルは追加することに注意してください。このパディングとは独立したランダムな交絡因子。)
For consistency, ciphertext stealing is always used for the last two blocks of the data to be encrypted, as in [RC5]. If the data length is a multiple of the block size, this is equivalent to plain CBC mode with the last two ciphertext blocks swapped.
一貫性を保つために、[RC5] のように、暗号化されるデータの最後の 2 ブロックには常に暗号文の窃取が使用されます。データ長がブロック サイズの倍数である場合、これは、最後の 2 つの暗号文ブロックが交換されたプレーン CBC モードと同等です。
A test vector is given in Appendix B.
テスト ベクトルは付録 B に記載されています。
The initial vector carried out from one encryption for use in a subsequent encryption is the next-to-last block of the encryption output; this is the encrypted form of the last plaintext block. When decrypting, the next-to-last block of the supplied ciphertext is carried forward as the next initial vector. If only one ciphertext block is available (decrypting one block, or encrypting one block or less), then that one block is carried out instead.
後続の暗号化で使用するために 1 つの暗号化から実行される最初のベクトルは、暗号化出力の最後から 2 番目のブロックです。これは、最後の平文ブロックの暗号化された形式です。復号化するとき、提供された暗号文の最後から 2 番目のブロックが次の初期ベクトルとして引き継がれます。利用可能な暗号文ブロックが 1 つだけの場合 (1 つのブロックの復号化、または 1 つのブロック以下の暗号化)、代わりにその 1 つのブロックが実行されます。
This is a summary of the parameters to be used with the simplified algorithm profile described in [KCRYPTO]:
これは、[KCRYPTO] で説明されている簡略化されたアルゴリズム プロファイルで使用されるパラメータの概要です。
+--------------------------------------------------------------------+
| protocol key format 128- or 256-bit string |
| |
| string-to-key function PBKDF2+DK with variable |
| iteration count (see |
| above) |
| |
| default string-to-key parameters 00 00 10 00 |
| |
| key-generation seed length key size |
| |
| random-to-key function identity function |
| |
| hash function, H SHA-1 |
| |
| HMAC output size, h 12 octets (96 bits) |
| |
| message block size, m 1 octet |
| |
| encryption/decryption functions, AES in CBC-CTS mode |
| E and D (cipher block size 16 |
| octets), with next-to- |
| last block (last block |
| if only one) as CBC-style |
| ivec |
+--------------------------------------------------------------------+
Using this profile with each key size gives us two each of encryption and checksum algorithm definitions.
このプロファイルを各キー サイズで使用すると、暗号化アルゴリズムとチェックサム アルゴリズムの定義がそれぞれ 2 つずつ得られます。
The following encryption type numbers are assigned:
次の暗号化タイプ番号が割り当てられます。
+--------------------------------------------------------------------+
| encryption types |
+--------------------------------------------------------------------+
| type name etype value key size |
+--------------------------------------------------------------------+
| aes128-cts-hmac-sha1-96 17 128 |
| aes256-cts-hmac-sha1-96 18 256 |
+--------------------------------------------------------------------+
The following checksum type numbers are assigned:
次のチェックサム タイプ番号が割り当てられます。
+--------------------------------------------------------------------+
| checksum types |
+--------------------------------------------------------------------+
| type name sumtype value length |
+--------------------------------------------------------------------+
| hmac-sha1-96-aes128 15 96 |
| hmac-sha1-96-aes256 16 96 |
+--------------------------------------------------------------------+
These checksum types will be used with the corresponding encryption types defined above.
これらのチェックサム タイプは、上で定義した対応する暗号化タイプとともに使用されます。
This new algorithm has not been around long enough to receive the decades of intense analysis that DES has received. It is possible that some weakness exists that has not been found by the cryptographers analyzing these algorithms before and during the AES selection process.
この新しいアルゴリズムは、DES が受けてきた数十年にわたる集中的な分析を受け入れるほど長く存在していません。AES 選択プロセス前および AES 選択プロセス中にこれらのアルゴリズムを分析した暗号学者によって発見されていない何らかの弱点が存在する可能性があります。
The use of the HMAC function has drawbacks for certain pass phrase lengths. For example, a pass phrase longer than the hash function block size (64 bytes, for SHA-1) is hashed to a smaller size (20 bytes) before applying the main HMAC algorithm. However, entropy is generally sparse in pass phrases, especially in long ones, so this may not be a problem in the rare cases of users with long pass phrases.
HMAC 関数の使用には、特定のパスフレーズの長さに関して欠点があります。たとえば、ハッシュ関数のブロック サイズ (SHA-1 の場合は 64 バイト) より長いパス フレーズは、メインの HMAC アルゴリズムを適用する前に、より小さいサイズ (20 バイト) にハッシュされます。ただし、パス フレーズ、特に長いパス フレーズでは一般にエントロピーが少ないため、ユーザーが長いパス フレーズを使用するまれなケースでは、これは問題にならない可能性があります。
Also, generating a 256-bit key from a pass phrase of any length may be deceptive, as the effective entropy in pass-phrase-derived key cannot be nearly that large given the properties of the string-to-key function described here.
また、ここで説明する文字列からキーへの関数の特性を考慮すると、パスフレーズから派生したキーの実効エントロピーはそこまで大きくなり得ないため、任意の長さのパスフレーズから 256 ビットのキーを生成することは欺瞞的である可能性があります。
The iteration count in PBKDF2 appears to be useful primarily as a constant multiplier for the amount of work required for an attacker using brute-force methods. Unfortunately, it also multiplies, by the same amount, the work needed by a legitimate user with a valid password. Thus the work factor imposed on an attacker (who may have many powerful workstations at his disposal) must be balanced against the work factor imposed on the legitimate user (who may have a PDA or cell phone); the available computing power on either side increases as time goes on, as well. A better way to deal with the brute-force attack is through preauthentication mechanisms that provide better protection of the user's long-term key. Use of such mechanisms is out of the scope of this document.
PBKDF2 の反復回数は、主にブルート フォース手法を使用する攻撃者に必要な作業量の定数乗数として役立つようです。残念ながら、有効なパスワードを持つ正当なユーザーが必要とする作業も同じ量だけ増えてしまいます。したがって、攻撃者 (自由に使える強力なワークステーションを多数持っている可能性がある) に課せられる作業係数と、正規のユーザー (PDA または携帯電話を持っている可能性がある) に課される作業係数とのバランスをとらなければなりません。時間の経過とともに、どちらかの側で利用可能な計算能力も増加します。ブルート フォース攻撃に対処するより良い方法は、ユーザーの長期キーをより適切に保護する事前認証メカニズムを使用することです。このようなメカニズムの使用は、このドキュメントの範囲外です。
If a site does wish to use this means of protection against a brute-force attack, the iteration count should be chosen based on the facilities available to both attacker and legitimate user, and the amount of work the attacker should be required to perform to acquire the key or password.
サイトがブルート フォース攻撃に対するこの保護手段を使用したい場合は、攻撃者と正当なユーザーの両方が利用できる機能と、攻撃者がデータを取得するために必要な作業量に基づいて反復回数を選択する必要があります。キーまたはパスワード。
As an example:
例として:
The author's tests on a 2GHz Pentium 4 system indicated that in one second, nearly 90,000 iterations could be done, producing a 256-bit key. This was using the SHA-1 assembly implementation from OpenSSL, and a pre-release version of the PBKDF2 code for MIT's Kerberos package, on a single system. No attempt was made to do multiple hashes in parallel, so we assume an attacker doing so can probably do at least 100,000 iterations per second -- rounded up to 2**17, for ease of calculation. For simplicity, we also assume the final AES encryption step costs nothing.
2GHz Pentium 4 システムでの著者のテストでは、1 秒間にほぼ 90,000 回の反復を実行して、256 ビットのキーを生成できることが示されました。これは、OpenSSL の SHA-1 アセンブリ実装と、MIT の Kerberos パッケージ用のプレリリース バージョンの PBKDF2 コードを単一システム上で使用していました。複数のハッシュを並行して実行する試みは行われていないため、これを実行する攻撃者はおそらく 1 秒あたり少なくとも 100,000 回の反復を実行できると想定しています (計算を容易にするために 2**17 に切り上げられます)。話を簡単にするために、最後の AES 暗号化ステップには費用がかからないと仮定します。
Paul Leach estimates [LEACH] that a password-cracking dictionary may have on the order of 2**21 entries, with capitalization, punctuation, and other variations contributing perhaps a factor of 2**11, giving a ballpark estimate of 2**32.
Paul Leach は、パスワードクラッキング辞書には 2**21 程度のエントリが含まれる可能性があると推定しており、大文字の使用、句読点、その他のバリエーションがおそらく 2**11 倍寄与し、大まかに見積もると 2** になります。32.
Thus, for a known iteration count N and a known salt string, an attacker with some number of computers comparable to the author's would need roughly N*2**15 CPU seconds to convert the entire dictionary plus variations into keys.
したがって、既知の反復回数 N と既知のソルト文字列の場合、作成者と同等の数のコンピュータを備えた攻撃者は、辞書全体とバリエーションをキーに変換するのにおよそ N*2**15 CPU 秒を必要とします。
An attacker using a dozen such computers for a month would have roughly 2**25 CPU seconds available. So using 2**12 (4,096) iterations would mean an attacker with a dozen such computers dedicated to a brute-force attack against a single key (actually, any password-derived keys sharing the same salt and iteration count) would process all the variations of the dictionary entries in four months and, on average, would likely find the user's password in two months.
攻撃者が 12 台のそのようなコンピューターを 1 か月間使用すると、利用可能な CPU 秒数はおよそ 2**25 秒になります。したがって、2**12 (4,096) 回の反復を使用すると、単一のキー (実際には、同じソルトと反復回数を共有するパスワード派生キー) に対するブルート フォース攻撃専用の 12 台のコンピューターを備えた攻撃者が、すべてのキーを処理することになります。辞書エントリのバリエーションを見つけるには 4 か月かかり、平均すると、ユーザーのパスワードを見つけるのに 2 か月かかる可能性があります。
Thus, if this form of attack is of concern, users should be required to change their passwords every few months, and an iteration count a few orders of magnitude higher should be chosen. Perhaps several orders of magnitude, as many users will tend to use the shorter and simpler passwords (to the extent they can, given a site's password quality checks) that the attacker would likely try first.
したがって、この形式の攻撃が懸念される場合は、ユーザーは数か月ごとにパスワードを変更する必要があり、反復回数を数桁高い値を選択する必要があります。多くのユーザーは、攻撃者が最初に試行するであろう短くて単純なパスワードを (サイトのパスワード品質チェックを考慮して、可能な範囲で) 使用する傾向があるため、おそらく数桁大きくなります。
Since this estimate is based on currently available CPU power, the iteration counts used for this mode of defense should be increased over time, at perhaps 40%-60% each year or so.
この推定値は現在利用可能な CPU 能力に基づいているため、この防御モードに使用される反復回数は、おそらく毎年 40% ～ 60% 程度、時間の経過とともに増加するはずです。
Note that if the attacker has a large amount of storage available, intermediate results could be cached, saving a lot of work for the next attack with the same salt and a greater number of iterations than had been run at the point where the intermediate results were saved. Thus, it would be wise to generate a new random salt string when passwords are changed. The default salt string, derived from the principal name, only protects against the use of one dictionary of keys against multiple users.
攻撃者が利用可能な大量のストレージを持っている場合、中間結果がキャッシュされる可能性があることに注意してください。これにより、同じソルトを使用した次の攻撃のための多くの作業が節約され、中間結果が保存された時点で実行されていたよりも多くの反復回数が節約されます。保存されました。したがって、パスワードが変更された場合は、新しいランダムなソルト文字列を生成することが賢明です。プリンシパル名から派生したデフォルトのソルト文字列は、複数のユーザーに対する 1 つのキーの辞書の使用のみを保護します。
If the PBKDF2 iteration count can be spoofed by an intruder on the network, and the limit on the accepted iteration count is very high, the intruder may be able to introduce a form of denial of service attack against the client by sending a very high iteration count, causing the client to spend a great deal of CPU time computing an incorrect key.
PBKDF2 反復回数がネットワーク上の侵入者によってスプーフィングされる可能性があり、受け入れられる反復回数の制限が非常に高い場合、侵入者は非常に高い反復回数を送信することで、クライアントに対して一種のサービス拒否攻撃を導入できる可能性があります。その結果、クライアントは不正なキーの計算に大量の CPU 時間を費やすことになります。
An intruder spoofing the KDC reply, providing a low iteration count and reading the client's reply from the network, may be able to reduce the work needed in the brute-force attack outlined above. Thus, implementations may seek to enforce lower bounds on the number of iterations that will be used.
侵入者が KDC 応答をスプーフィングし、反復回数を少なくしてネットワークからクライアントの応答を読み取ることで、上で概説したブルート フォース攻撃に必要な作業を軽減できる可能性があります。したがって、実装では、使用される反復回数の下限を強制しようとする場合があります。
Since threat models and typical end-user equipment will vary widely from site to site, allowing site-specific configuration of such bounds is recommended.
脅威モデルと一般的なエンドユーザー機器はサイトごとに大きく異なるため、そのような境界をサイト固有の構成で許可することをお勧めします。
Any benefit against other attacks specific to the HMAC or SHA-1 algorithms is probably achieved with a fairly small number of iterations.
HMAC または SHA-1 アルゴリズムに特有の他の攻撃に対する利点は、おそらくかなり少ない反復回数で達成されます。
In the "optimistic preauthentication" case mentioned in section 3, the client may attempt to produce a key without first communicating with the KDC. If the client has no additional information, it can only guess as to the iteration count to be used. Even such heuristics as "iteration count X was used to acquire tickets for the same principal only N hours ago" can be wrong. Given the recommendation above for increasing the iteration counts used over time, it is impossible to recommend any specific default value for this case; allowing site-local configuration is recommended. (If the lower and upper bound checks described above are implemented, the default count for optimistic preauthentication should be between those bounds.)
セクション 3 で説明した「オプティミスティック事前認証」の場合、クライアントは最初に KDC と通信せずにキーの生成を試みる可能性があります。クライアントに追加情報がない場合は、使用される反復回数を推測することしかできません。「N 時間前に同じプリンシパルのチケットを取得するために反復回数 X が使用された」などのヒューリスティックですら、間違っている可能性があります。時間の経過とともに使用される反復回数を増やすための上記の推奨事項を考慮すると、この場合に特定のデフォルト値を推奨することは不可能です。サイトローカル構成を許可することをお勧めします。(上記の下限と上限のチェックが実装されている場合、オプティミスティック事前認証のデフォルトのカウントはこれらの境界の間にある必要があります。)
Ciphertext stealing mode, as it requires no additional padding in most cases, will reveal the exact length of each message being encrypted rather than merely bounding it to a small range of possible lengths as in CBC mode. Such obfuscation should not be relied upon at higher levels in any case; if the length must be obscured from an outside observer, this should be done by intentionally varying the length of the message to be encrypted.
暗号文窃取モードは、ほとんどの場合、追加のパディングを必要としないため、CBC モードのようにメッセージを可能な長さの狭い範囲に単に制限するのではなく、暗号化されている各メッセージの正確な長さを明らかにします。このような難読化は、いかなる場合でも、より高いレベルで依存すべきではありません。外部の観察者から長さを隠蔽する必要がある場合は、暗号化するメッセージの長さを意図的に変更することで行う必要があります。
Kerberos encryption and checksum type values used in section 7 were previously reserved in [KCRYPTO] for the mechanisms defined in this document. The registries have been updated to list this document as the reference.
セクション 7 で使用される Kerberos 暗号化とチェックサム タイプの値は、この文書で定義されるメカニズム用に [KCRYPTO] で以前に予約されていました。レジストリが更新され、このドキュメントが参照としてリストされるようになりました。
Thanks to John Brezak, Gerardo Diaz Cuellar, Ken Hornstein, Paul Leach, Marcus Watts, Larry Zhu, and others for feedback on earlier versions of this document.
このドキュメントの以前のバージョンに関するフィードバックを提供してくれた John Brezak、Gerardo Diaz Cuellar、Ken Hornstein、Paul Leach、Marcus Watts、Larry Zhu、その他に感謝します。
A. Errata for RFC 2040 Section 8
A. RFC 2040 セクション 8 の正誤表
(Copied from the RFC Editor's errata web site on July 8, 2004.)
(2004 年 7 月 8 日の RFC 編集者の正誤表 Web サイトからのコピー。)
Reported By: Bob Baldwin; baldwin@plusfive.com
Date: Fri, 26 Mar 2004 06:49:02 -0800
In Section 8, Description of RC5-CTS, of the encryption method, it says:
暗号化方式のセクション 8「RC5-CTS の説明」には、次のように記載されています。
1. Exclusive-or Pn-1 with the previous ciphertext block, Cn-2, to create Xn-1.
1. Pn-1 と前の暗号文ブロック Cn-2 の排他的論理和をとり、Xn-1 を作成します。
It should say:
次のように言うはずです:
1. Exclusive-or Pn-1 with the previous ciphertext block, Cn-2, to create Xn-1. For short messages where Cn-2 does not exist, use IV.
1. Pn-1 と前の暗号文ブロック Cn-2 の排他的論理和をとり、Xn-1 を作成します。Cn-2 が存在しないショートメッセージの場合は、IV を使用します。
Reported By: Bob Baldwin; baldwin@plusfive.com
Date: Mon, 22 Mar 2004 20:26:40 -0800
In Section 8, first paragraph, second sentence says:
セクション 8 の最初の段落の 2 番目の文には次のように書かれています。
This mode handles any length of plaintext and produces ciphertext whose length matches the plaintext length.
このモードは、任意の長さの平文を処理し、平文の長さと一致する長さの暗号文を生成します。
In Section 8, first paragraph, second sentence should read:
セクション 8 の最初の段落の 2 番目の文は次のようになります。
This mode handles any length of plaintext longer than one block and produces ciphertext whose length matches the plaintext length.
このモードは、1 ブロックより長い任意の長さの平文を処理し、平文の長さと一致する長さの暗号文を生成します。
In Section 8, step 6 of the decryption method says:
セクション 8 の復号化方法のステップ 6 では、次のように述べられています。
6. Decrypt En to create Pn-1.
6. En を復号化して Pn-1 を作成します。
In Section 8, step 6 of the decryption method should read:
セクション 8 の復号化方法のステップ 6 は次のようになります。
6. Decrypt En and exclusive-or with Cn-2 to create Pn-1. For short messages where Cn-2 does not exist, use the IV.
6. En を復号化し、Cn-2 と排他的論理和をとって Pn-1 を作成します。Cn-2 が存在しないショート メッセージの場合は、IV を使用します。
B. Sample Test Vectors
B. サンプル テスト ベクトル
Sample values for the PBKDF2 HMAC-SHA1 string-to-key function are included below.
PBKDF2 HMAC-SHA1 string-to-key 関数のサンプル値を以下に示します。
Iteration count = 1 Pass phrase = "password" Salt = "ATHENA.MIT.EDUraeburn" 128-bit PBKDF2 output: cd ed b5 28 1b b2 f8 01 56 5a 11 22 b2 56 35 15 128-bit AES key: 42 26 3c 6e 89 f4 fc 28 b8 df 68 ee 09 79 9f 15 256-bit PBKDF2 output: cd ed b5 28 1b b2 f8 01 56 5a 11 22 b2 56 35 15 0a d1 f7 a0 4b b9 f3 a3 33 ec c0 e2 e1 f7 08 37 256-bit AES key: fe 69 7b 52 bc 0d 3c e1 44 32 ba 03 6a 92 e6 5b bb 52 28 09 90 a2 fa 27 88 39 98 d7 2a f3 01 61
反復回数 = 1 パス フレーズ = "password" ソルト = "ATHENA.MIT.EDUraeburn" 128 ビット PBKDF2 出力: cd ed b5 28 1b b2 f8 01 56 5a 11 22 b2 56 35 15 128 ビット AES キー: 42 26 3c6e 89 f4 fc 28 b8 df 68 ee 09 79 9f 15 256 ビット PBKDF2 出力: cd ed b5 28 1b b2 f8 01 56 5a 11 22 b2 56 35 15 0a d1 f7 a0 4b b9 f3 a3 33 ec c0 e2 e1 f7 0837 256 ビット AES キー: fe 69 7b 52 bc 0d 3c e1 44 32 ba 03 6a 92 e6 5b bb 52 28 09 90 a2 fa 27 88 39 98 d7 2a f3 01 61
Iteration count = 2 Pass phrase = "password" Salt="ATHENA.MIT.EDUraeburn" 128-bit PBKDF2 output: 01 db ee 7f 4a 9e 24 3e 98 8b 62 c7 3c da 93 5d 128-bit AES key: c6 51 bf 29 e2 30 0a c2 7f a4 69 d6 93 bd da 13 256-bit PBKDF2 output: 01 db ee 7f 4a 9e 24 3e 98 8b 62 c7 3c da 93 5d a0 53 78 b9 32 44 ec 8f 48 a9 9e 61 ad 79 9d 86 256-bit AES key: a2 e1 6d 16 b3 60 69 c1 35 d5 e9 d2 e2 5f 89 61 02 68 56 18 b9 59 14 b4 67 c6 76 22 22 58 24 ff
反復回数 = 2 パス フレーズ = "password" Salt="ATHENA.MIT.EDUraeburn" 128 ビット PBKDF2 出力: 01 db ee 7f 4a 9e 24 3e 98 8b 62 c7 3c da 93 5d 128 ビット AES キー: c6 51 bf29 e2 30 0a c2 7f a4 69 d6 93 bd da 13 256 ビット PBKDF2 出力: 01 db ee 7f 4a 9e 24 3e 98 8b 62 c7 3c da 93 5d a0 53 78 b9 32 44 ec 8f 48 a9 9e 61 ad 79 9d86 256 ビット AES キー: a2 e1 6d 16 b3 60 69 c1 35 d5 e9 d2 e2 5f 89 61 02 68 56 18 b9 59 14 b4 67 c6 76 22 22 58 24 ff
Iteration count = 1200 Pass phrase = "password" Salt = "ATHENA.MIT.EDUraeburn" 128-bit PBKDF2 output: 5c 08 eb 61 fd f7 1e 4e 4e c3 cf 6b a1 f5 51 2b 128-bit AES key: 4c 01 cd 46 d6 32 d0 1e 6d be 23 0a 01 ed 64 2a 256-bit PBKDF2 output: 5c 08 eb 61 fd f7 1e 4e 4e c3 cf 6b a1 f5 51 2b a7 e5 2d db c5 e5 14 2f 70 8a 31 e2 e6 2b 1e 13 256-bit AES key: 55 a6 ac 74 0a d1 7b 48 46 94 10 51 e1 e8 b0 a7 54 8d 93 b0 ab 30 a8 bc 3f f1 62 80 38 2b 8c 2a
反復回数 = 1200 パス フレーズ = "password" ソルト = "ATHENA.MIT.EDUraeburn" 128 ビット PBKDF2 出力: 5c 08 eb 61 fd f7 1e 4e 4e c3 cf 6b a1 f5 51 2b 128 ビット AES キー: 4c 01 cd46 d6 32 d0 1e 6d be 23 0a 01 ed 64 2a 256 ビット PBKDF2 出力: 5c 08 eb 61 fd f7 1e 4e 4e c3 cf 6b a1 f5 51 2b a7 e5 2d db c5 e5 14 2f 70 8a 31 e2 e6 2b 1e13 256 ビット AES キー: 55 a6 ac 74 0a d1 7b 48 46 94 10 51 e1 e8 b0 a7 54 8d 93 b0 ab 30 a8 bc 3f f1 62 80 38 2b 8c 2a
Iteration count = 5 Pass phrase = "password" Salt=0x1234567878563412 128-bit PBKDF2 output: d1 da a7 86 15 f2 87 e6 a1 c8 b1 20 d7 06 2a 49 128-bit AES key: e9 b2 3d 52 27 37 47 dd 5c 35 cb 55 be 61 9d 8e 256-bit PBKDF2 output: d1 da a7 86 15 f2 87 e6 a1 c8 b1 20 d7 06 2a 49 3f 98 d2 03 e6 be 49 a6 ad f4 fa 57 4b 6e 64 ee 256-bit AES key: 97 a4 e7 86 be 20 d8 1a 38 2d 5e bc 96 d5 90 9c ab cd ad c8 7c a4 8f 57 45 04 15 9f 16 c3 6e 31 (This test is based on values given in [PECMS].)
反復回数 = 5 パス フレーズ = "パスワード" Salt=0x1234567878563412 128 ビット PBKDF2 出力: d1 da a7 86 15 f2 87 e6 a1 c8 b1 20 d7 06 2a 49 128 ビット AES キー: e9 b2 3d 52 27 37 47 dd 5c35 cb 55 be 61 9d 8e 256 ビット PBKDF2 出力: d1 da a7 86 15 f2 87 e6 a1 c8 b1 20 d7 06 2a 49 3f 98 d2 03 e6 be 49 a6 ad f4 fa 57 4b 6e 64 ee 256 ビット AES キー: 97 a4 e7 86 be 20 d8 1a 38 2d 5e bc 96 d5 90 9c ab cd ad c8 7c a4 8f 57 45 04 15 9f 16 c3 6e 31 (このテストは [PECMS] で指定された値に基づいています。)
Iteration count = 1200
Pass phrase = (64 characters)
"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
Salt="pass phrase equals block size"
128-bit PBKDF2 output:
13 9c 30 c0 96 6b c3 2b a5 5f db f2 12 53 0a c9
128-bit AES key:
59 d1 bb 78 9a 82 8b 1a a5 4e f9 c2 88 3f 69 ed
256-bit PBKDF2 output:
13 9c 30 c0 96 6b c3 2b a5 5f db f2 12 53 0a c9
c5 ec 59 f1 a4 52 f5 cc 9a d9 40 fe a0 59 8e d1
256-bit AES key:
89 ad ee 36 08 db 8b c7 1f 1b fb fe 45 94 86 b0
56 18 b7 0c ba e2 20 92 53 4e 56 c5 53 ba 4b 34
Iteration count = 1200
Pass phrase = (65 characters)
"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
Salt = "pass phrase exceeds block size"
128-bit PBKDF2 output:
9c ca d6 d4 68 77 0c d5 1b 10 e6 a6 87 21 be 61
128-bit AES key:
cb 80 05 dc 5f 90 17 9a 7f 02 10 4c 00 18 75 1d
256-bit PBKDF2 output:
9c ca d6 d4 68 77 0c d5 1b 10 e6 a6 87 21 be 61
1a 8b 4d 28 26 01 db 3b 36 be 92 46 91 5e c8 2a
256-bit AES key:
d7 8c 5c 9c b8 72 a8 c9 da d4 69 7f 0b b5 b2 d2
14 96 c8 2b eb 2c ae da 21 12 fc ee a0 57 40 1b
Iteration count = 50 Pass phrase = g-clef (0xf09d849e) Salt = "EXAMPLE.COMpianist" 128-bit PBKDF2 output: 6b 9c f2 6d 45 45 5a 43 a5 b8 bb 27 6a 40 3b 39 128-bit AES key: f1 49 c1 f2 e1 54 a7 34 52 d4 3e 7f e6 2a 56 e5 256-bit PBKDF2 output: 6b 9c f2 6d 45 45 5a 43 a5 b8 bb 27 6a 40 3b 39 e7 fe 37 a0 c4 1e 02 c2 81 ff 30 69 e1 e9 4f 52 256-bit AES key: 4b 6d 98 39 f8 44 06 df 1f 09 cc 16 6d b4 b8 3c 57 18 48 b7 84 a3 d6 bd c3 46 58 9a 3e 39 3f 9e
反復回数 = 50 パス フレーズ = ト音記号 (0xf09d849e) ソルト = "EXAMPLE.COMpianist" 128 ビット PBKDF2 出力: 6b 9c f2 6d 45 45 5a 43 a5 b8 bb 27 6a 40 3b 39 128 ビット AES キー: f1 49c1 f2 e1 54 a7 34 52 d4 3e 7f e6 2a 56 e5 256 ビット PBKDF2 出力: 6b 9c f2 6d 45 45 5a 43 a5 b8 bb 27 6a 40 3b 39 e7 fe 37 a0 c4 1e 02 c2 81 ff 30 69 e1 e 94f 52 256 ビット AES キー: 4b 6d 98 39 f8 44 06 df 1f 09 cc 16 6d b4 b8 3c 57 18 48 b7 84 a3 d6 bd c3 46 58 9a 3e 39 3f 9e
Some test vectors for CBC with ciphertext stealing, using an initial vector of all-zero.
一部の CBC テスト ベクトルは、すべて 0 の初期ベクトルを使用して、暗号文を盗用します。
AES 128-bit key: 0000: 63 68 69 63 6b 65 6e 20 74 65 72 69 79 61 6b 69
AES 128 ビット キー: 0000: 63 68 69 63 6b 65 6e 20 74 65 72 69 79 61 6b 69
IV: 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Input: 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 0010: 20 Output: 0000: c6 35 35 68 f2 bf 8c b4 d8 a5 80 36 2d a7 ff 7f 0010: 97 Next IV: 0000: c6 35 35 68 f2 bf 8c b4 d8 a5 80 36 2d a7 ff 7f
IV: 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 入力: 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 0010: 20出力: 0000: c6 35 3568 f2 bf 8c b4 d8 a5 80 36 2d a7 ff 7f 0010: 97 次の IV: 0000: c6 35 35 68 f2 bf 8c b4 d8 a5 80 36 2d a7 ff 7f
IV: 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Input: 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 0010: 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 Output: 0000: fc 00 78 3e 0e fd b2 c1 d4 45 d4 c8 ef f7 ed 22 0010: 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 Next IV: 0000: fc 00 78 3e 0e fd b2 c1 d4 45 d4 c8 ef f7 ed 22
IV: 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 入力: 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 0010: 20 47 65 6e 65 72 61 6c20 47 61 75 27 73 20出力：0000：FC 00 78 3E 0E FD B2 C1 D4 45 D4 C8 EF F7 ED 22 0010：97 68 72 68 D6 EC CC C0 C0 7B 25 E2 5E CF E5 NEXT IV：0000：FCC00 78 3e 0e fd b2 c1 d4 45 d4 c8 ef f7 ed 22
IV: 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Input: 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 0010: 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43 Output: 0000: 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8 0010: 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84 Next IV: 0000: 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8
IV: 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 入力: 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 0010: 20 47 65 6e 65 72 61 6c20 47 61 75 27 73 20 43 出力: 0000: 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8 0010: 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84 次の IV: 0000: 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8
IV: 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Input: 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 0010: 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43 0020: 68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c Output: 0000: 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84 0010: b3 ff fd 94 0c 16 a1 8c 1b 55 49 d2 f8 38 02 9e 0020: 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 Next IV: 0000: b3 ff fd 94 0c 16 a1 8c 1b 55 49 d2 f8 38 02 9e
IV: 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 入力: 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 0010: 20 47 65 6e 65 72 61 6c20 47 61 75 27 73 20 43 0020: 68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 出力: 0000: 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 8 4 0010: b3 ff fd94 0c 16 a1 8c 1b 55 49 d2 f8 38 02 9e 0020: 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 次の IV: 0000: b3 ff fd 94 0c 16 a1 8c 1b 55 49 d2 f8 38 029e
IV: 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Input: 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 0010: 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43 0020: 68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 20 Output: 0000: 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84 0010: 9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8 0020: 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8 Next IV: 0000: 9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8
IV: 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 入力: 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 0010: 20 47 65 6e 65 72 61 6c20 47 61 75 27 73 20 43 0020: 68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 20 出力: 0000: 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e 5 84 0010: 9D 広告8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8 0020: 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8 次の IV: 0000: 9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a194 bb d8
IV: 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Input: 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 0010: 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43 0020: 68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 20 0030: 61 6e 64 20 77 6f 6e 74 6f 6e 20 73 6f 75 70 2e Output: 0000: 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84 0010: 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8 0020: 48 07 ef e8 36 ee 89 a5 26 73 0d bc 2f 7b c8 40 0030: 9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8 Next IV: 0000: 48 07 ef e8 36 ee 89 a5 26 73 0d bc 2f 7b c8 40
IV: 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 入力: 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 0010: 20 47 65 6e 65 72 61 6c20 47 61 75 27 73 20 43 0020: 68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 20 0030: 61 6e 64 20 77 6f 6e 74 6f 6e 20 73 6 f 75 70 2e 出力: 0000: 97 6872 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84 0010: 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8 0020: 48 07 ef e8 36 ee 89 a5 26 73 0d bc 2f 7b c8 400030: 9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8 次の IV: 0000: 48 07 ef e8 36 ee 89 a5 26 73 0d bc 2f 7b c8 40
Normative References
引用文献
[AC] Schneier, B., "Applied Cryptography", second edition, John Wiley and Sons, New York, 1996.
[AC] Schneier, B.、「Applied Cryptography」、第 2 版、John Wiley and Sons、ニューヨーク、1996 年。
[AES] National Institute of Standards and Technology, U.S. Department of Commerce, "Advanced Encryption Standard", Federal Information Processing Standards Publication 197, Washington, DC, November 2001.
[AES] 米国商務省国立標準技術研究所、「Advanced Encryption Standard」、連邦情報処理標準出版物 197、ワシントン DC、2001 年 11 月。
[KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, February 2005.
[KCRYPTO] Raeburn, K.、「Kerberos 5 の暗号化とチェックサムの仕様」、RFC 3961、2005 年 2 月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner, S.、「要件レベルを示すために RFC で使用するキーワード」、BCP 14、RFC 2119、1997 年 3 月。
[PKCS5] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, September 2000.
[PKCS5] Kaliski, B.、「PKCS #5: パスワードベースの暗号化仕様バージョン 2.0」、RFC 2898、2000 年 9 月。
[RC5] Baldwin, R. and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms", RFC 2040, October 1996.
[RC5] Baldwin, R. および R. Rivest、「RC5、RC5-CBC、RC5-CBC-Pad、および RC5-CTS アルゴリズム」、RFC 2040、1996 年 10 月。
[SHA1] National Institute of Standards and Technology, U.S. Department of Commerce, "Secure Hash Standard", Federal Information Processing Standards Publication 180-1, Washington, DC, April 1995.
[SHA1] 米国商務省国立標準技術研究所、「セキュア ハッシュ標準」、連邦情報処理標準出版物 180-1、ワシントン DC、1995 年 4 月。
Informative References
参考引用
[LEACH] Leach, P., email to IETF Kerberos working group mailing list, 5 May 2003, ftp://ftp.ietf.org/ietf-mail-archive/krb-wg/2003-05.mail.
[LEACH] P. リーチ、IETF Kerberos ワーキング グループ メーリング リストへの電子メール、2003 年 5 月 5 日、ftp://ftp.ietf.org/ietf-mail-archive/krb-wg/2003-05.mail。
[PECMS] Gutmann, P., "Password-based Encryption for CMS", RFC 3211, December 2001.
[PECMS] Gutmann、P.、「CMS のパスワードベースの暗号化」、RFC 3211、2001 年 12 月。
Author's Address
著者の連絡先
Kenneth Raeburn Massachusetts Institute of Technology 77 Massachusetts Avenue Cambridge, MA 02139
Kenneth Raeburn マサチューセッツ工科大学 77 Massachusetts Avenue Cambridge, MA 02139
EMail: raeburn@mit.edu
Full Copyright Statement
完全な著作権に関する声明
Copyright (C) The Internet Society (2005).
著作権 (C) インターネット協会 (2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78 に含まれる権利、ライセンス、および制限の対象となり、そこに規定されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書およびここに含まれる情報は「現状のまま」で提供され、寄稿者、寄稿者が代表または後援する組織（存在する場合）、インターネット協会およびインターネット エンジニアリング タスク フォースは、明示的または明示的または明示的に、すべての保証を否認します。ここに記載された情報の使用がいかなる権利も侵害しないことの黙示的な保証、または商品性や特定の目的への適合性の黙示的な保証を含みますが、これに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF は、本書に記載されているテクノロジの実装または使用に関連すると主張される知的財産権またはその他の権利の有効性や範囲、あるいはそのような権利に基づくライセンスが適用されるかどうかの範囲に関して、いかなる立場も負いません。利用可能であること。また、そのような権利を特定するために独自の努力を行ったことを示すものでもありません。IETF 文書の権利に関する IETF の手順に関する情報は、BCP 78 および BCP 79 に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF 事務局に提出された IPR 開示のコピー、および利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような所有権の使用に対する一般ライセンスまたは許可を取得しようとする試みの結果を入手できます。IETF オンライン IPR リポジトリ (http://www.ietf.org/ipr) から入手してください。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF は、利害関係者に対し、この規格の実装に必要とされる可能性のある技術をカバーする著作権、特許、特許出願、またはその他の所有権について注意を喚起するよう呼びかけています。情報は IETF (ietf-ipr@ietf.org) に送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC エディター機能の資金は現在、インターネット協会によって提供されています。