[要約] RFC 3961は、Kerberos 5認証プロトコルにおける暗号化とチェックサムの仕様を定義しています。この文書の目的は、Kerberos認証フレームワーク内で使用される暗号化技術とチェックサムアルゴリズムの標準化を提供することにあります。これにより、セキュリティの強化と互換性の保証が図られます。Kerberosは主に認証サービスにおいて利用され、ネットワーク上でのユーザー認証情報の安全な伝送を可能にします。関連するRFCにはRFC 4120（Kerberosプロトコルの仕様）やRFC 3962（AES暗号化の使用に関する拡張）などがあります。
Network Working Group K. Raeburn
Request for Comments: 3961 MIT
Category: Standards Track February 2005
Encryption and Checksum Specifications for Kerberos 5
Kerberos 5の暗号化とチェックサムの仕様
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
概要
This document describes a framework for defining encryption and checksum mechanisms for use with the Kerberos protocol, defining an abstraction layer between the Kerberos protocol and related protocols, and the actual mechanisms themselves. The document also defines several mechanisms. Some are taken from RFC 1510, modified in form to fit this new framework and occasionally modified in content when the old specification was incorrect. New mechanisms are presented here as well. This document does NOT indicate which mechanisms may be considered "required to implement".
このドキュメントでは、Kerberos プロトコルで使用する暗号化およびチェックサム メカニズムを定義するためのフレームワーク、Kerberos プロトコルと関連プロトコル間の抽象化レイヤー、および実際のメカニズム自体について説明します。この文書では、いくつかのメカニズムも定義されています。一部は RFC 1510 から引用され、この新しいフレームワークに合わせて形式が変更され、古い仕様が間違っていた場合には内容が変更される場合もあります。ここでも新しいメカニズムが紹介されています。この文書は、どのメカニズムが「実装が必要」とみなされるかについては示しません。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Encryption Algorithm Profile . . . . . . . . . . . . . . . . 4
4. Checksum Algorithm Profile . . . . . . . . . . . . . . . . . 9
5. Simplified Profile for CBC Ciphers with Key Derivation . . . 10
5.1. A Key Derivation Function . . . . . . . . . . . . . . . 10
5.2. Simplified Profile Parameters . . . . . . . . . . . . . 12
5.3. Cryptosystem Profile Based on Simplified Profile . . . 13
5.4. Checksum Profiles Based on Simplified Profile . . . . . 16
6. Profiles for Kerberos Encryption and Checksum Algorithms . . 16
6.1. Unkeyed Checksums . . . . . . . . . . . . . . . . . . . 17
6.2. DES-based Encryption and Checksum Types . . . . . . . . 18
6.3. Triple-DES Based Encryption and Checksum Types . . . . 28
7. Use of Kerberos Encryption Outside This Specification . . . . 30
8. Assigned Numbers . . . . . . . . . . . . . . . . . . . . . . 31
9. Implementation Notes . . . . . . . . . . . . . . . . . . . . 32
10. Security Considerations . . . . . . . . . . . . . . . . . . . 33
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
12. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 36
A. Test vectors . . . . . . . . . . . . . . . . . . . . . . . . 38
A.1. n-fold . . . . . . . . . . . . . . . . . . . . . . . . 38
A.2. mit_des_string_to_key . . . . . . . . . . . . . . . . . 39
A.3. DES3 DR and DK . . . . . . . . . . . . . . . . . . . . 43
A.4. DES3string_to_key . . . . . . . . . . . . . . . . . . . 44
A.5. Modified CRC-32 . . . . . . . . . . . . . . . . . . . . 44
B. Significant Changes from RFC 1510 . . . . . . . . . . . . . . 45
Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Normative References. . . . . . . . . . . . . . . . . . . . . . . 47
Informative References. . . . . . . . . . . . . . . . . . . . . . 48
Editor's Address. . . . . . . . . . . . . . . . . . . . . . . . . 49
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 50
The Kerberos protocols [Kerb] are designed to encrypt messages of arbitrary sizes, using block encryption ciphers or, less commonly, stream encryption ciphers. Encryption is used to prove the identities of the network entities participating in message exchanges. However, nothing in the Kerberos protocol requires that any specific encryption algorithm be used, as long as the algorithm includes certain operations.
Kerberos プロトコル [Kerb] は、ブロック暗号化暗号、またはあまり一般的ではありませんがストリーム暗号化暗号を使用して、任意のサイズのメッセージを暗号化するように設計されています。暗号化は、メッセージ交換に参加しているネットワーク エンティティの身元を証明するために使用されます。ただし、Kerberos プロトコルでは、アルゴリズムに特定の操作が含まれている限り、特定の暗号化アルゴリズムを使用する必要はありません。
The following sections specify the encryption and checksum mechanisms currently defined for Kerberos, as well as a framework for defining future mechanisms. The encoding, chaining, padding, and other requirements for each are described. Appendix A gives test vectors for several functions.
次のセクションでは、Kerberos に対して現在定義されている暗号化およびチェックサムのメカニズムと、将来のメカニズムを定義するためのフレームワークについて説明します。それぞれのエンコーディング、チェーン、パディング、およびその他の要件について説明します。付録 A には、いくつかの関数のテスト ベクトルが記載されています。
Both encryption and checksum mechanisms are profiled in later sections. Each profile specifies a collection of operations and attributes that must be defined for a mechanism. A Kerberos encryption or checksum mechanism specification is not complete if it does not define all of these operations and attributes.
暗号化とチェックサムの両方のメカニズムについては、後のセクションで説明します。各プロファイルは、メカニズムに対して定義する必要がある操作と属性のコレクションを指定します。Kerberos 暗号化またはチェックサム メカニズムの仕様は、これらの操作と属性をすべて定義しないと完全ではありません。
An encryption mechanism must provide for confidentiality and integrity of the original plaintext. (Incorporating a checksum may permit integrity checking, if the encryption mode does not provide an integrity check itself.) It must also provide non-malleability
暗号化メカニズムは、元の平文の機密性と完全性を提供する必要があります。(暗号化モード自体が整合性チェックを提供しない場合、チェックサムを組み込むと整合性チェックが可能になる場合があります。) また、非展性も提供する必要があります。
[Bellare98] [Dolev91]. Use of a random confounder prepended to the plaintext is recommended. It should not be possible to determine if two ciphertexts correspond to the same plaintext without the key.
[ベラーレ98] [ドレフ91]。平文の前にランダムな交絡因子を追加して使用することをお勧めします。キーがなければ 2 つの暗号文が同じ平文に対応するかどうかを判断できないはずです。
A checksum mechanism [1] must provide proof of the integrity of the associated message and must preserve the confidentiality of the message in case it is not sent in the clear. Finding two plaintexts with the same checksum should be infeasible. It is NOT required that an eavesdropper be unable to determine whether two checksums are for the same message, as the messages themselves would presumably be visible to any such eavesdropper.
チェックサム メカニズム [1] は、関連するメッセージの完全性の証明を提供する必要があり、平文で送信されない場合に備えてメッセージの機密性を保持する必要があります。同じチェックサムを持つ 2 つの平文を見つけることは不可能なはずです。メッセージ自体はおそらくそのような盗聴者に見えるため、盗聴者が 2 つのチェックサムが同じメッセージのものであるかどうかを判断できない必要はありません。
Due to advances in cryptography, some cryptographers consider using the same key for multiple purposes unwise. Since keys are used in performing a number of different functions in Kerberos, it is desirable to use different keys for each of these purposes, even though we start with a single long-term or session key.
暗号技術の進歩により、暗号学者の中には、同じキーを複数の目的に使用するのは賢明ではないと考える人もいます。Kerberos ではさまざまな機能を実行するためにキーが使用されるため、単一の長期キーまたはセッション キーから開始する場合でも、これらの目的ごとに異なるキーを使用することが望ましいです。
We do this by enumerating the different uses of keys within Kerberos and by making the "usage number" an input to the encryption or checksum mechanisms; such enumeration is outside the scope of this document. Later sections define simplified profile templates for encryption and checksum mechanisms that use a key derivation function applied to a CBC mode (or similar) cipher and a checksum or hash algorithm.
これは、Kerberos 内のキーのさまざまな使用法を列挙し、「使用法番号」を暗号化またはチェックサム メカニズムへの入力にすることによって行われます。このような列挙は、このドキュメントの範囲外です。後のセクションでは、CBC モード (または同様の) 暗号とチェックサムまたはハッシュ アルゴリズムに適用されるキー導出関数を使用する、暗号化およびチェックサム メカニズム用の簡略化されたプロファイル テンプレートを定義します。
We distinguish the "base key" specified by other documents from the "specific key" for a specific encryption or checksum operation. It is expected but not required that the specific key be one or more separate keys derived from the original protocol key and the key usage number. The specific key should not be explicitly referenced outside of this document. The typical language used in other documents should be something like, "encrypt this octet string using this key and this usage number"; generation of the specific key and cipher state (described in the next section) are implicit. The creation of a new cipher-state object, or the re-use of one from a previous encryption operation, may also be explicit.
当社では、他の文書で指定されている「ベース キー」と、特定の暗号化またはチェックサム操作の「特定のキー」を区別します。特定のキーは、元のプロトコル キーとキー使用番号から派生した 1 つ以上の別個のキーであることが期待されますが、必須ではありません。特定のキーは、このドキュメントの外で明示的に参照しないでください。他の文書で使用される典型的な言語は、「このキーとこの使用番号を使用してこのオクテット文字列を暗号化する」のようなものでなければなりません。特定のキーと暗号状態 (次のセクションで説明) の生成は暗黙的です。新しい暗号状態オブジェクトの作成、または以前の暗号化操作からの暗号状態オブジェクトの再利用も明示的である場合があります。
New protocols defined in terms of the Kerberos encryption and checksum types should use their own key usage values. Key usages are unsigned 32-bit integers; zero is not permitted.
Kerberos 暗号化およびチェックサム タイプに関して定義された新しいプロトコルは、独自のキー使用値を使用する必要があります。主な用途は符号なし 32 ビット整数です。ゼロは許可されません。
All data is assumed to be in the form of strings of octets or eight-bit bytes. Environments with other byte sizes will have to emulate this behavior in order to get correct results.
すべてのデータは、オクテットまたは 8 ビット バイトの文字列の形式であると想定されます。他のバイト サイズの環境では、正しい結果を得るためにこの動作をエミュレートする必要があります。
Each algorithm is assigned an encryption type (or "etype") or checksum type number, for algorithm identification within the Kerberos protocol. The full list of current type number assignments is given in section 8.
各アルゴリズムには、Kerberos プロトコル内でアルゴリズムを識別するために、暗号化タイプ (または「etype」) またはチェックサム タイプ番号が割り当てられます。現在のタイプ番号割り当ての完全なリストはセクション 8 に記載されています。
An encryption mechanism profile must define the following attributes and operations. The operations must be defined as functions in the mathematical sense. No additional or implicit inputs (such as Kerberos principal names or message sequence numbers) are permitted.
暗号化メカニズムのプロファイルでは、次の属性と操作を定義する必要があります。演算は数学的な意味で関数として定義する必要があります。追加入力または暗黙的な入力 (Kerberos プリンシパル名やメッセージ シーケンス番号など) は許可されません。
protocol key format This describes which octet string values represent valid keys. For encryption mechanisms that don't have perfectly dense key spaces, this will describe the representation used for encoding keys. It need not describe invalid specific values; all key generation routines should avoid such values.
プロトコル キー形式 これは、どのオクテット文字列値が有効なキーを表すかを記述します。完全に密なキー空間を持たない暗号化メカニズムの場合、これはキーのエンコードに使用される表現を記述します。無効な特定の値を記述する必要はありません。すべての鍵生成ルーチンはそのような値を避ける必要があります。
specific key structure This is not a protocol format at all, but a description of the keying material derived from the chosen key and used to encrypt or decrypt data or compute or verify a checksum. It may, for example, be a single key, a set of keys, or a combination of the original key with additional data. The authors recommend using one or more keys derived from the original key via one-way key derivation functions.
特定のキー構造 これはプロトコル形式ではありませんが、選択されたキーから派生し、データの暗号化または復号化、またはチェックサムの計算または検証に使用されるキーマテリアルの記述です。たとえば、単一のキー、キーのセット、または元のキーと追加データの組み合わせなどです。著者らは、一方向キー導出関数を介して元のキーから導出された 1 つ以上のキーを使用することを推奨しています。
required checksum mechanism This indicates a checksum mechanism that must be available when this encryption mechanism is used. Since Kerberos has no built in mechanism for negotiating checksum mechanisms, once an encryption mechanism is decided, the corresponding checksum mechanism can be used.
必須のチェックサム メカニズム これは、この暗号化メカニズムが使用される場合に使用可能でなければならないチェックサム メカニズムを示します。Kerberos にはチェックサム メカニズムをネゴシエートするためのメカニズムが組み込まれていないため、暗号化メカニズムが決定されると、対応するチェックサム メカニズムを使用できます。
key-generation seed length, K This is the length of the random bitstring needed to generate a key with the encryption scheme's random-to-key function (described below). This must be a fixed value so that various techniques for producing a random bitstring of a given length may be used with key generation functions.
キー生成シード長、K これは、暗号化スキームのランダムからキーへの関数 (後述) を使用してキーを生成するために必要なランダム ビット文字列の長さです。指定された長さのランダムなビット文字列を生成するためのさまざまな技術をキー生成関数で使用できるように、これは固定値である必要があります。
key generation functions Keys must be generated in a number of cases, from different types of inputs. All function specifications must indicate how to generate keys in the proper wire format and must avoid generating keys that significantly compromise the confidentiality of encrypted data, if the cryptosystem has such. Entropy from each source should be preserved as much as possible. Many of the inputs, although unknown, may be at least partly predictable (e.g., a password string is likely to be entirely in the ASCII subset and of fairly short length in many environments; a semi-random string may include time stamps). The benefit of such predictability to an attacker must be minimized.
キー生成関数 キーは、さまざまな種類の入力からさまざまな場合に生成する必要があります。すべての機能仕様は、適切なワイヤ形式でキーを生成する方法を示す必要があり、暗号化データの機密性を著しく損なうキーの生成を回避する必要があります (暗号システムにそのようなものがある場合)。各ソースからのエントロピーは可能な限り保存される必要があります。入力の多くは未知であっても、少なくとも部分的には予測可能である可能性があります (たとえば、パスワード文字列は、多くの環境では完全に ASCII サブセット内にあり、かなり短い長さである可能性が高く、半ランダムな文字列にはタイムスタンプが含まれる可能性があります)。このような予測可能性による攻撃者への利益は最小限に抑える必要があります。
string-to-key (UTF-8 string, UTF-8 string, opaque)->(protocol-key) This function generates a key from two UTF-8 strings and an opaque octet string. One of the strings is usually the principal's pass phrase, but generally it is merely a secret string. The other string is a "salt" string intended to produce different keys from the same password for different users or realms. Although the strings provided will use UTF-8 encoding, no specific version of Unicode should be assumed; all valid UTF-8 strings should be allowed. Strings provided in other encodings MUST first be converted to UTF-8 before applying this function.
string-to-key (UTF-8 文字列、UTF-8 文字列、不透明)->(プロトコル キー) この関数は、2 つの UTF-8 文字列と不透明なオクテット文字列からキーを生成します。文字列の 1 つは通常、プリンシパルのパスフレーズですが、一般的には単なる秘密の文字列です。もう 1 つの文字列は、異なるユーザーまたはレルムに対して同じパスワードから異なるキーを生成することを目的とした「ソルト」文字列です。提供される文字列は UTF-8 エンコーディングを使用しますが、Unicode の特定のバージョンを想定する必要はありません。有効な UTF-8 文字列はすべて許可される必要があります。他のエンコーディングで提供される文字列は、この関数を適用する前に、まず UTF-8 に変換する必要があります。
The third argument, the octet string, may be used to pass mechanism-specific parameters into this function. Since doing so implies knowledge of the specific encryption system, generating non-default parameter values should be an uncommon operation, and normal Kerberos applications should be able to treat this parameter block as an opaque object supplied by the Key Distribution Center or defaulted to some mechanism-specific constant value.
3 番目の引数であるオクテット文字列は、メカニズム固有のパラメーターをこの関数に渡すために使用できます。そうすることは特定の暗号化システムの知識を意味するため、デフォルト以外のパラメータ値を生成することは一般的ではない操作である必要があり、通常の Kerberos アプリケーションはこのパラメータ ブロックをキー配布センターによって提供される不透明なオブジェクトまたは何らかのメカニズムのデフォルトとして扱うことができる必要があります。- 固有の定数値。
The string-to-key function should be a one-way function so that compromising a user's key in one realm does not compromise it in another, even if the same password (but a different salt) is used.
文字列からキーへの関数は、同じパスワード (ただし異なるソルト) が使用されている場合でも、あるレルムでユーザーのキーが侵害されても別のレルムでは侵害されないように、一方向関数である必要があります。
random-to-key (bitstring[K])->(protocol-key) This function generates a key from a random bitstring of a specific size. All the bits of the input string are assumed to be equally random, even though the entropy present in the random source may be limited.
random-to-key (bitstring[K])->(protocol-key) この関数は、特定のサイズのランダムなビット文字列からキーを生成します。ランダム ソースに存在するエントロピーが制限されている場合でも、入力文字列のすべてのビットは同様にランダムであると想定されます。
key-derivation (protocol-key, integer)->(specific-key) In this function, the integer input is the key usage value, as described above. An attacker is assumed to know the usage values. The specific-key output value was described in section 2.
key-derivation (protocol-key, integer)->( specific-key) この関数では、上で説明したように、整数入力はキー使用値です。攻撃者は使用量の値を知っていると想定されます。特定のキーの出力値についてはセクション 2 で説明しました。
string-to-key parameter format This describes the format of the block of data that can be passed to the string-to-key function above to configure additional parameters for that function. Along with the mechanism of encoding parameter values, bounds on the allowed parameters should also be described to avoid allowing a spoofed KDC to compromise the user's password. If practical it may be desirable to construct the encoding so that values unacceptably weakening the resulting key cannot be encoded.
string-to-key パラメータ形式 これは、その関数の追加パラメータを設定するために上記の string-to-key 関数に渡すことができるデータ ブロックの形式を記述します。パラメータ値をエンコードするメカニズムに加えて、なりすましされた KDC によるユーザーのパスワードの侵害を防ぐために、許可されるパラメータの制限も記述する必要があります。実際的であれば、結果のキーを許容できないほど弱める値がエンコードできないようにエンコードを構築することが望ましい場合があります。
Local security policy might permit tighter bounds to avoid excess resource consumption. If so, the specification should recommended defaults for these bounds. The description should also outline possible weaknesses if bounds checks or other validations are not applied to a parameter string received from the network.
ローカル セキュリティ ポリシーでは、過剰なリソースの消費を避けるために、より厳しい制限が許可される場合があります。その場合、仕様ではこれらの境界のデフォルトを推奨する必要があります。説明では、ネットワークから受信したパラメータ文字列に境界チェックやその他の検証が適用されない場合に考えられる弱点についても概説する必要があります。
As mentioned above, this should be considered opaque to most normal applications.
上で述べたように、これはほとんどの通常のアプリケーションに対して不透明であると考えるべきです。
default string-to-key parameters (octet string) This default value for the "params" argument to the string-to-key function should be used when the application protocol (Kerberos or other) does not explicitly set the parameter value. As indicated above, in most cases this parameter block should be treated as an opaque object.
デフォルトの string-to-key パラメータ (オクテット文字列) string-to-key 関数の「params」引数のこのデフォルト値は、アプリケーション プロトコル (Kerberos など) がパラメータ値を明示的に設定しない場合に使用する必要があります。上で示したように、ほとんどの場合、このパラメータ ブロックは不透明なオブジェクトとして扱う必要があります。
cipher state This describes any information that can be carried over from one encryption or decryption operation to the next, for use with a given specific key. For example, a block cipher used in CBC mode may put an initial vector of one block in the cipher state. Other encryption modes may track nonces or other data.
暗号状態 これは、特定のキーで使用するために、ある暗号化または復号化操作から次の操作に引き継がれる情報を記述します。たとえば、CBC モードで使用されるブロック暗号では、1 つのブロックの初期ベクトルが暗号状態に置かれる場合があります。他の暗号化モードでは、ノンスまたはその他のデータが追跡される場合があります。
This state must be non-empty and must influence encryption so that messages are decrypted in the same order they were a encrypted, if the cipher state is carried over from one encryption to the next. Distinguishing out-of-order or missing messages from corrupted messages is not required. If desired, this can be done at a higher level by including sequence numbers and not "chaining" the cipher state between encryption operations.
この状態は空であってはならず、暗号状態が暗号化間で引き継がれる場合、暗号化されたときと同じ順序でメッセージが復号化されるように暗号化に影響を与える必要があります。順序が乱れているメッセージや欠落しているメッセージと破損したメッセージを区別する必要はありません。必要に応じて、暗号化操作間で暗号状態を「連鎖」させずに、シーケンス番号を含めることにより、これをより高いレベルで実行できます。
The cipher state may not be reused in multiple encryption or decryption operations. These operations all generate a new cipher state that may be used for following operations using the same key and operation.
暗号状態は、複数の暗号化または復号化操作で再利用することはできません。これらの操作はすべて、同じキーと操作を使用する次の操作に使用できる新しい暗号状態を生成します。
The contents of the cipher state must be treated as opaque outside of encryption system specifications.
暗号状態の内容は、暗号化システム仕様の範囲外では不透明として扱われなければなりません。
initial cipher state (specific-key, direction)->(state) This describes the generation of the initial value for the cipher state if it is not being carried over from a previous encryption or decryption operation.
初期暗号状態 (特定のキー、方向)->(状態) これは、以前の暗号化または復号化操作から引き継がれていない場合の暗号状態の初期値の生成を記述します。
This describes any initial state setup needed before encrypting arbitrary amounts of data with a given specific key. The specific key and the direction of operations to be performed (encrypt versus decrypt) must be the only input needed for this initialization.
これは、特定のキーを使用して任意の量のデータを暗号化する前に必要な初期状態のセットアップについて説明します。この初期化に必要な入力は、特定のキーと実行される操作の方向 (暗号化と復号化) のみである必要があります。
This state should be treated as opaque in any uses outside of an encryption algorithm definition.
この状態は、暗号化アルゴリズムの定義以外で使用する場合には不透明として扱う必要があります。
IMPLEMENTATION NOTE: [Kerb1510] was vague on whether and to what degree an application protocol could exercise control over the initial vector used in DES CBC operations. Some existing implementations permit setting the initial vector. This framework does not provide for application control of the cipher state (beyond "initialize" and "carry over from previous encryption"), as the form and content of the initial cipher state can vary between encryption systems and may not always be a single block of random data.
実装メモ: [Kerb1510] は、DES CBC 操作で使用される初期ベクトルをアプリケーション プロトコルが制御できるかどうか、またどの程度制御できるかについて曖昧でした。一部の既存の実装では、初期ベクトルを設定できます。初期暗号状態の形式と内容は暗号化システムによって異なり、必ずしも単一のブロックであるとは限らないため、このフレームワークでは、アプリケーションによる暗号状態の制御 (「初期化」や「前の暗号化からの引き継ぎ」を超える) は提供されません。ランダムデータの。
New Kerberos application protocols should not assume control over the initial vector, or that one even exists. However, a general-purpose implementation may wish to provide the capability, in case applications explicitly setting it are encountered.
新しい Kerberos アプリケーション プロトコルは、初期ベクトルの制御を想定すべきではなく、初期ベクトルが存在することさえ想定すべきではありません。ただし、アプリケーションが明示的に設定する場合に備えて、汎用実装でその機能を提供したい場合があります。
encrypt (specific-key, state, octet string)->(state, octet string) This function takes the specific key, cipher state, and a non-empty plaintext string as input and generates ciphertext and a new cipher state as outputs. If the basic encryption algorithm itself does not provide for integrity protection (e.g., DES in CBC mode), then some form of verifiable MAC or checksum must be included. Some random factor such as a confounder should be included so that an observer cannot know if two messages contain the same plaintext, even if the cipher state and specific keys are the same. The exact length of the plaintext need not be encoded, but if it is not and if padding is required, the padding must be added at the end of the string so that the decrypted version may be parsed from the beginning.
encrypt (特定のキー、状態、オクテット文字列)->(状態、オクテット文字列) この関数は、特定のキー、暗号状態、および空ではない平文文字列を入力として受け取り、暗号文と新しい暗号状態を出力として生成します。基本的な暗号化アルゴリズム自体が完全性保護を提供しない場合 (CBC モードの DES など)、何らかの形式の検証可能な MAC またはチェックサムを含める必要があります。暗号状態と特定のキーが同じであっても、2 つのメッセージに同じ平文が含まれているかどうかを観察者が知ることができないように、交絡因子などのランダムな要素を含める必要があります。平文の正確な長さをエンコードする必要はありませんが、エンコードする必要がなく、パディングが必要な場合は、復号化されたバージョンを最初から解析できるように、文字列の最後にパディングを追加する必要があります。
The specification of the encryption function must indicate not only the precise contents of the output octet string, but also the output cipher state. The application protocol may carry the output cipher state forward from one encryption with a given specific key to another; the effect of this "chaining" must be defined [2].
暗号化関数の仕様では、出力オクテット文字列の正確な内容だけでなく、出力暗号状態も指定する必要があります。アプリケーション プロトコルは、出力暗号状態を、特定の特定のキーを使用したある暗号化から別の暗号化に転送できます。この「連鎖」の効果を定義する必要があります [2]。
Assuming that values for the specific key and cipher state are correctly-produced, no input octet string may result in an error indication.
特定のキーと暗号状態の値が正しく生成されていると仮定すると、入力オクテット文字列によってエラーが表示される可能性があります。
decrypt (specific-key, state, octet string)->(state, octet string) This function takes the specific key, cipher state, and ciphertext as inputs and verifies the integrity of the supplied ciphertext. If the ciphertext's integrity is intact, this function produces the plaintext and a new cipher state as outputs; otherwise, an error indication must be returned, and the data discarded.
decrypt (特定のキー、状態、オクテット文字列)->(状態、オクテット文字列) この関数は、特定のキー、暗号状態、および暗号文を入力として受け取り、指定された暗号文の整合性を検証します。暗号文の整合性が損なわれていない場合、この関数は平文と新しい暗号状態を出力として生成します。それ以外の場合は、エラー表示を返し、データを破棄する必要があります。
The result of the decryption may be longer than the original plaintext, as, for example, when the encryption mode adds padding to reach a multiple of a block size. If this is the case, any extra octets must come after the decoded plaintext. An application protocol that needs to know the exact length of the message must encode a length or recognizable "end of message" marker within the plaintext [3].
たとえば、暗号化モードでパディングが追加されてブロック サイズの倍数に達する場合など、復号化の結果は元の平文より長くなる可能性があります。この場合、余分なオクテットはデコードされた平文の後に来る必要があります。メッセージの正確な長さを知る必要があるアプリケーション プロトコルは、平文内に長さまたは認識可能な「メッセージの終わり」マーカーをエンコードする必要があります [3]。
As with the encryption function, a correct specification for this function must indicate not only the contents of the output octet string, but also the resulting cipher state.
暗号化関数と同様に、この関数の正しい仕様では、出力オクテット文字列の内容だけでなく、結果の暗号状態も示す必要があります。
pseudo-random (protocol-key, octet-string)->(octet-string) This pseudo-random function should generate an octet string of some size that is independent of the octet string input. The PRF output string should be suitable for use in key generation, even if the octet string input is public. It should not reveal the input key, even if the output is made public.
pseudo-random (protocol-key, octet-string)->(octet-string) この擬似ランダム関数は、オクテット文字列入力とは独立した、あるサイズのオクテット文字列を生成する必要があります。PRF 出力文字列は、オクテット文字列入力がパブリックであっても、キー生成での使用に適している必要があります。たとえ出力が公開されたとしても、入力キーを明らかにすべきではありません。
These operations and attributes are all that is required to support Kerberos and various proposed preauthentication schemes.
これらの操作と属性は、Kerberos および提案されているさまざまな事前認証スキームをサポートするために必要なすべてです。
For convenience of certain application protocols that may wish to use the encryption profile, we add the constraint that, for any given plaintext input size, a message size must exist between that given size and that size plus 65,535 such that the length of the decrypted version of the ciphertext will never have extra octets at the end.
暗号化プロファイルの使用を希望する特定のアプリケーション プロトコルの便宜を図るため、任意の平文入力サイズに対して、メッセージ サイズがその指定サイズとそのサイズ + 65,535 の間に存在する必要があるという制約を追加します。暗号文の末尾に余分なオクテットが存在することはありません。
Expressed mathematically, for every message length L1, there exists a message size L2 such that
数学的に表現すると、メッセージ長 L1 ごとに、次のようなメッセージ サイズ L2 が存在します。
L2 >= L1
L2 < L1 + 65,536
for every message M with |M| = L2, decrypt(encrypt(M)) = M
A document defining a new encryption type should also describe known weaknesses or attacks, so that its security may be fairly assessed, and should include test vectors or other validation procedures for the operations defined. Specific references to information that is readily available elsewhere are sufficient.
新しい暗号化タイプを定義する文書には、そのセキュリティが公正に評価されるように、既知の弱点や攻撃についても説明する必要があり、定義された操作のテスト ベクトルやその他の検証手順を含める必要があります。他の場所ですぐに入手できる情報への具体的な参照で十分です。
A checksum mechanism profile must define the following attributes and operations:
チェックサム メカニズム プロファイルでは、次の属性と操作を定義する必要があります。
associated encryption algorithm(s) This indicates the types of encryption keys this checksum mechanism can be used with.
関連する暗号化アルゴリズム これは、このチェックサム メカニズムで使用できる暗号化キーのタイプを示します。
A keyed checksum mechanism may have more than one associated encryption algorithm if they share the same wire-key format, string-to-key function, default string-to-key-parameters, and key derivation function. (This combination means that, for example, a checksum type, key usage value, and password are adequate to get the specific key used to compute a checksum.)
キー付きチェックサム メカニズムは、同じワイヤ キー形式、文字列からキーへの関数、デフォルトの文字列からキーへのパラメータ、およびキー導出関数を共有する場合、複数の関連付けられた暗号化アルゴリズムを持つことができます。(この組み合わせは、たとえば、チェックサムの計算に使用される特定のキーを取得するには、チェックサム タイプ、キー使用値、およびパスワードが適切であることを意味します。)
An unkeyed checksum mechanism can be used with any encryption type, as the key is ignored, but its use must be limited to cases where the checksum itself is protected, to avoid trivial attacks.
キーなしのチェックサム メカニズムは、キーが無視されるため、どの暗号化タイプでも使用できますが、軽微な攻撃を避けるために、その使用はチェックサム自体が保護されている場合に限定する必要があります。
get_mic function This function generates a MIC token for a given specific key (see section 3) and message (represented as an octet string) that may be used to verify the integrity of the associated message. This function is not required to return the same deterministic result for each use; it need only generate a token that the verify_mic routine can check.
get_mic 関数 この関数は、指定された特定のキー (セクション 3 を参照) およびメッセージ (オクテット文字列として表される) の MIC トークンを生成します。これらのトークンは、関連付けられたメッセージの整合性を検証するために使用されます。この関数は、使用するたびに同じ決定的な結果を返す必要はありません。verify_mic ルーチンがチェックできるトークンを生成するだけで済みます。
The output of this function will also dictate the size of the checksum. It must be no larger than 65,535 octets.
この関数の出力によって、チェックサムのサイズも決まります。65,535 オクテット以下である必要があります。
verify_mic function Given a specific key, message, and MIC token, this function ascertains whether the message integrity has been compromised. For a deterministic get_mic routine, the corresponding verify_mic may simply generate another checksum and compare the two.
verify_mic 関数 特定のキー、メッセージ、および MIC トークンを指定して、この関数はメッセージの整合性が侵害されているかどうかを確認します。決定論的な get_mic ルーチンの場合、対応する verify_mic は単に別のチェックサムを生成し、その 2 つを比較するだけで済みます。
The get_mic and verify_mic operations must allow inputs of arbitrary length; if any padding is needed, the padding scheme must be specified as part of these functions.
get_mic および verify_mic オペレーションでは、任意の長さの入力を許可する必要があります。パディングが必要な場合は、これらの関数の一部としてパディング スキームを指定する必要があります。
These operations and attributes are all that should be required to support Kerberos and various proposed preauthentication schemes.
これらの操作と属性は、Kerberos および提案されているさまざまな事前認証スキームをサポートするために必要なすべてです。
As with encryption mechanism definition documents, documents defining new checksum mechanisms should indicate validation processes and known weaknesses.
暗号化メカニズム定義ドキュメントと同様に、新しいチェックサム メカニズムを定義するドキュメントには、検証プロセスと既知の弱点を示す必要があります。
The profile outlined in sections 3 and 4 describes a large number of operations that must be defined for encryption and checksum algorithms to be used with Kerberos. Here we describe a simpler profile that can generate both encryption and checksum mechanism definitions, filling in uses of key derivation in appropriate places, providing integrity protection, and defining multiple operations for the cryptosystem profile based on a smaller set of operations. Not all of the existing cryptosystems for Kerberos fit into this simplified profile, but we recommend that future cryptosystems use it or something based on it [4].
セクション 3 と 4 で説明したプロファイルでは、Kerberos で使用する暗号化およびチェックサム アルゴリズムに対して定義する必要がある多数の操作について説明します。ここでは、暗号化とチェックサムの両方のメカニズム定義を生成し、適切な場所でキー導出の使用を埋め、整合性保護を提供し、より小規模な操作セットに基づいて暗号システム プロファイルの複数の操作を定義できる、より単純なプロファイルについて説明します。Kerberos の既存の暗号システムのすべてがこの簡素化されたプロファイルに適合するわけではありませんが、将来の暗号システムではこれまたはそれに基づくものを使用することをお勧めします [4]。
Not all the operations in the complete profiles are defined through this mechanism; several must still be defined for each new algorithm pair.
完全なプロファイル内のすべての操作がこのメカニズムを通じて定義されるわけではありません。新しいアルゴリズムのペアごとにいくつかを定義する必要があります。
Rather than define some scheme by which a "protocol key" is composed of a large number of encryption keys, we use keys derived from a base key to perform cryptographic operations. The base key must be used only for generating the derived keys, and this derivation must be non-invertible and entropy preserving. Given these restrictions, compromise of one derived key does not compromise others. Attack of the base key is limited, as it is only used for derivation and is not exposed to any user data.
「プロトコル キー」が多数の暗号化キーで構成される何らかのスキームを定義するのではなく、ベース キーから派生したキーを使用して暗号化操作を実行します。基本キーは派生キーの生成にのみ使用する必要があり、この派生は非可逆であり、エントロピーが保存される必要があります。これらの制限を考慮すると、1 つの派生キーが侵害されても、他の派生キーが侵害されることはありません。ベースキーは導出のみに使用され、ユーザーデータにはさらされないため、ベースキーの攻撃は限定的です。
To generate a derived key from a base key, we generate a pseudorandom octet string by using an algorithm DR, described below, and generate a key from that octet string by using a function dependent on the encryption algorithm. The input length needed for that function, which is also dependent on the encryption algorithm, dictates the length of the string to be generated by the DR algorithm (the value "k" below). These procedures are based on the key derivation in [Blumenthal96].
基本キーから派生キーを生成するには、後述するアルゴリズム DR を使用して擬似ランダム オクテット文字列を生成し、暗号化アルゴリズムに依存する関数を使用してそのオクテット文字列からキーを生成します。その関数に必要な入力長は、暗号化アルゴリズムにも依存し、DR アルゴリズムによって生成される文字列の長さを決定します (以下の値「k」)。これらの手順は、[Blumenthal96] の鍵導出に基づいています。
Derived Key = DK(Base Key, Well-Known Constant)
派生キー = DK(ベースキー、既知の定数)
DK(Key, Constant) = random-to-key(DR(Key, Constant))
DR(Key, Constant) = k-truncate(E(Key, Constant,
initial-cipher-state))
Here DR is the random-octet generation function described below, and DK is the key-derivation function produced from it. In this construction, E(Key, Plaintext, CipherState) is a cipher, Constant is a well-known constant determined by the specific usage of this function, and k-truncate truncates its argument by taking the first k bits. Here, k is the key generation seed length needed for the encryption system.
ここで、DR は後述のランダム オクテット生成関数、DK はそれから生成される鍵導出関数です。この構造では、E(Key, Plaintext, CipherState) は暗号、Constant はこの関数の特定の使用法によって決定される既知の定数、k-truncate は最初の k ビットを取得して引数を切り捨てます。ここで、k は暗号化システムに必要なキー生成シード長です。
The output of the DR function is a string of bits; the actual key is produced by applying the cryptosystem's random-to-key operation on this bitstring.
DR 関数の出力はビット列です。実際のキーは、このビット文字列に暗号システムのランダムからキーへの操作を適用することによって生成されます。
If the Constant is smaller than the cipher block size of E, then it must be expanded with n-fold() so it can be encrypted. If the output of E is shorter than k bits, it is fed back into the encryption as many times as necessary. The construct is as follows (where | indicates concatentation):
定数が E の暗号ブロック サイズより小さい場合は、暗号化できるように n-fold() で展開する必要があります。E の出力が k ビットより短い場合、必要なだけ何度でも暗号化にフィードバックされます。構成は次のとおりです (| は連結を示します)。
K1 = E(Key, n-fold(Constant), initial-cipher-state)
K2 = E(Key, K1, initial-cipher-state)
K3 = E(Key, K2, initial-cipher-state)
K4 = ...
DR(Key, Constant) = k-truncate(K1 | K2 | K3 | K4 ...)
n-fold is an algorithm that takes m input bits and "stretches" them to form n output bits with equal contribution from each input bit to the output, as described in [Blumenthal96]:
n-fold は、[Blumenthal96] で説明されているように、m 個の入力ビットを受け取り、各入力ビットから出力への寄与が等しい n 個の出力ビットを形成するようにそれらを「拡張」するアルゴリズムです。
We first define a primitive called n-folding, which takes a variable-length input block and produces a fixed-length output sequence. The intent is to give each input bit approximately equal weight in determining the value of each output bit. Note that whenever we need to treat a string of octets as a number, the assumed representation is Big-Endian -- Most Significant Byte first.
まず、n-folding と呼ばれるプリミティブを定義します。これは、可変長の入力ブロックを受け取り、固定長の出力シーケンスを生成します。その目的は、各出力ビットの値を決定する際に、各入力ビットにほぼ等しい重みを与えることです。オクテットの文字列を数値として扱う必要がある場合は常に、想定される表現はビッグエンディアン、つまり最上位バイトが最初であることに注意してください。
To n-fold a number X, replicate the input value to a length that
is the least common multiple of n and the length of X. Before
each repetition, the input is rotated to the right by 13 bit
positions. The successive n-bit chunks are added together using
1's-complement addition (that is, with end-around carry) to yield
a n-bit result....
Test vectors for n-fold are supplied in appendix A [5].
n 倍のテスト ベクトルは付録 A [5] で提供されます。
In this section, n-fold is always used to produce c bits of output, where c is the cipher block size of E.
このセクションでは、n 倍は常に c ビットの出力を生成するために使用されます。ここで、c は E の暗号ブロック サイズです。
The size of the Constant must not be larger than c, because reducing the length of the Constant by n-folding can cause collisions.
定数の長さを n 倍にして短くすると衝突が発生する可能性があるため、定数のサイズは c より大きくてはなりません。
If the size of the Constant is smaller than c, then the Constant must be n-folded to length c. This string is used as input to E. If the block size of E is less than the random-to-key input size, then the output from E is taken as input to a second invocation of E. This process is repeated until the number of bits accumulated is greater than or equal to the random-to-key input size. When enough bits have been computed, the first k are taken as the random data used to create the key with the algorithm-dependent random-to-key function.
定数のサイズが c より小さい場合、定数は長さ c になるように n 倍にする必要があります。この文字列は E への入力として使用されます。E のブロック サイズがランダムからキーへの入力サイズより小さい場合、E からの出力は E の 2 回目の呼び出しへの入力として取得されます。このプロセスは、数値が達するまで繰り返されます。蓄積されたビット数がランダムからキーへの入力サイズ以上である。十分なビットが計算されると、最初の k が、アルゴリズムに依存するランダムからキーへの関数でキーを作成するために使用されるランダム データとして取得されます。
As the derived key is the result of one or more encryptions in the base key, deriving the base key from the derived key is equivalent to determining the key from a very small number of plaintext/ciphertext pairs. Thus, this construction is as strong as the cryptosystem itself.
派生キーはベース キー内の 1 つ以上の暗号化の結果であるため、派生キーからベース キーを派生することは、非常に少数の平文/暗号文のペアからキーを決定することと同じです。したがって、この構造は暗号システム自体と同じくらい強力です。
These are the operations and attributes that must be defined:
定義する必要がある操作と属性は次のとおりです。
protocol key format string-to-key function default string-to-key parameters key-generation seed length, k random-to-key function As above for the normal encryption mechanism profile.
プロトコル キー形式 文字列からキーへの関数 デフォルトの文字列からキーへのパラメーター キー生成シード長、k ランダムからキーへの関数 通常の暗号化メカニズム プロファイルの場合と同様。
unkeyed hash algorithm, H This should be a collision-resistant hash algorithm with fixed-size output, suitable for use in an HMAC [HMAC]. It must support inputs of arbitrary length. Its output must be at least the message block size (below).
キーなしハッシュ アルゴリズム、H これは、HMAC [HMAC] での使用に適した、固定サイズの出力を持つ衝突耐性のあるハッシュ アルゴリズムである必要があります。任意の長さの入力をサポートする必要があります。その出力は、少なくともメッセージ ブロック サイズ (下記) である必要があります。
HMAC output size, h This indicates the size of the leading substring output by the HMAC function that should be used in transmitted messages. It should be at least half the output size of the hash function H, and at least 80 bits; it need not match the output size.
HMAC 出力サイズ、h これは、送信メッセージで使用する必要がある、HMAC 関数によって出力される先頭の部分文字列のサイズを示します。これは、ハッシュ関数 H の出力サイズの少なくとも半分、少なくとも 80 ビットである必要があります。出力サイズと一致する必要はありません。
message block size, m This is the size of the smallest units the cipher can handle in the mode in which it is being used. Messages will be padded to a multiple of this size. If a block cipher is used in a mode that can handle messages that are not multiples of the cipher block size, such as CBC mode with cipher text stealing (CTS, see [RC5]), this value would be one octet. For traditional CBC mode with padding, it would be the underlying cipher's block size.
メッセージ ブロック サイズ、m これは、暗号が使用されているモードで処理できる最小単位のサイズです。メッセージはこのサイズの倍数に埋め込まれます。ブロック暗号が、暗号文盗用を備えた CBC モード (CTS、[RC5] を参照) など、暗号ブロック サイズの倍数ではないメッセージを処理できるモードで使用される場合、この値は 1 オクテットになります。パディングを伴う従来の CBC モードの場合、これは基礎となる暗号のブロック サイズになります。
This value must be a multiple of eight bits (one octet).
この値は 8 ビット (1 オクテット) の倍数でなければなりません。
encryption/decryption functions, E and D These are basic encryption and decryption functions for messages of sizes that are multiples of the message block size. No integrity checking or confounder should be included here. For inputs these functions take the IV or similar data, a protocol-format key, and an octet string, returning a new IV and octet string.
暗号化/復号化関数、E および D これらは、メッセージ ブロック サイズの倍数のサイズのメッセージに対する基本的な暗号化および復号化関数です。ここには整合性チェックや交絡要素を含めるべきではありません。入力として、これらの関数は IV または同様のデータ、プロトコル形式のキー、およびオクテット文字列を受け取り、新しい IV とオクテット文字列を返します。
The encryption function is not required to use CBC mode but is assumed to be using something with similar properties. In particular, prepending a cipher block-size confounder to the plaintext should alter the entire ciphertext (comparable to choosing and including a random initial vector for CBC mode).
暗号化機能は CBC モードを使用する必要はありませんが、同様の特性を持つものを使用することが想定されます。特に、暗号ブロックサイズの交絡因子を平文の前に付加すると、暗号文全体が変更されるはずです (CBC モードのランダムな初期ベクトルを選択して含めることに相当します)。
The result of encrypting one cipher block (of size c, above) must be deterministic for the random octet generation function DR in the previous section to work. For best security, it should also be no larger than c.
前のセクションのランダム オクテット生成関数 DR が機能するには、1 つの暗号ブロック (上記のサイズ c) の暗号化結果が決定的である必要があります。最高のセキュリティを実現するには、この値も c 以下である必要があります。
cipher block size, c This is the block size of the block cipher underlying the encryption and decryption functions indicated above, used for key derivation and for the size of the message confounder and initial vector. (If a block cipher is not in use, some comparable parameter should be determined.) It must be at least 5 octets.
暗号ブロック サイズ、c これは、上で示した暗号化および復号化関数の基礎となるブロック暗号のブロック サイズであり、キーの導出と、メッセージ交絡因子および初期ベクトルのサイズに使用されます。(ブロック暗号が使用されていない場合は、同等のパラメータを決定する必要があります。) 少なくとも 5 オクテットでなければなりません。
This is not actually an independent parameter; rather, it is a property of the functions E and D. It is listed here to clarify the distinction between it and the message block size, m.
これは実際には独立したパラメータではありません。むしろ、これは関数 E および D のプロパティです。ここでは、それとメッセージ ブロック サイズ m の区別を明確にするためにリストされています。
Although there are still a number of properties to specify, they are fewer and simpler than in the full profile.
指定するプロパティはまだ多数ありますが、完全なプロファイルよりも数が少なく、簡単です。
The above key derivation function is used to produce three intermediate keys. One is used for computing checksums of unencrypted data. The other two are used for encrypting and checksumming plaintext to be sent encrypted.
上記のキー導出関数は、3 つの中間キーを生成するために使用されます。1 つは、暗号化されていないデータのチェックサムを計算するために使用されます。他の 2 つは、暗号化して送信される平文の暗号化とチェックサムに使用されます。
The ciphertext output is the concatenation of the output of the basic encryption function E and a (possibly truncated) HMAC using the specified hash function H, both applied to the plaintext with a random confounder prefix and sufficient padding to bring it to a multiple of the message block size. When the HMAC is computed, the key is used in the protocol key form.
暗号文出力は、基本暗号化関数 E の出力と、指定されたハッシュ関数 H を使用した (おそらく切り詰められた) HMAC の出力を連結したもので、どちらもランダムな交絡因子プレフィックスと、暗号化関数の倍数にするのに十分なパディングを使用して平文に適用されます。メッセージブロックのサイズ。HMAC が計算されるとき、キーはプロトコル キー形式で使用されます。
Decryption is performed by removing the (partial) HMAC, decrypting the remainder, and verifying the HMAC. The cipher state is an initial vector, initialized to zero.
復号化は、(部分的な) HMAC を削除し、残りを復号化し、HMAC を検証することによって実行されます。暗号状態は初期ベクトルであり、ゼロに初期化されます。
The substring notation "[1..h]" in the following table should be read as using 1-based indexing; leading substrings are used.
次の表の部分文字列表記「[1..h]」は、1 から始まるインデックスを使用していると解釈する必要があります。先頭の部分文字列が使用されます。
Cryptosystem from Simplified Profile
------------------------------------------------------------------------
protocol key format As given.
specific key structure Three protocol-format keys: { Kc, Ke, Ki }.
特定のキー構造 3 つのプロトコル形式のキー: { Kc、Ke、Ki }。
key-generation seed As given. length
キー生成シード 指定どおり。長さ
required checksum As defined below in section 5.4. mechanism
必須チェックサム 以下のセクション 5.4 で定義されています。機構
cipher state Initial vector (usually of length c)
暗号状態 初期ベクトル (通常は長さ c)
initial cipher state All bits zero
初期暗号状態 すべてのビットがゼロ
encryption function conf = Random string of length c pad = Shortest string to bring confounder and plaintext to a length that's a multiple of m. (C1, newIV) = E(Ke, conf | plaintext | pad, oldstate.ivec) H1 = HMAC(Ki, conf | plaintext | pad) ciphertext = C1 | H1[1..h] newstate.ivec = newIV
暗号化関数 conf = 長さのランダムな文字列 c Pad = 交絡因子と平文を m の倍数の長さにする最短の文字列。(C1, newIV) = E(Ke, conf | 平文 | パッド, oldstate.ivec) H1 = HMAC(Ki, conf | 平文 | パッド) 暗号文 = C1 | 平文 | パッドH1[1..h] newstate.ivec = newIV
decryption function (C1,H1) = ciphertext
(P1, newIV) = D(Ke, C1, oldstate.ivec)
if (H1 != HMAC(Ki, P1)[1..h])
report error
newstate.ivec = newIV
default string-to-key As given. params
デフォルトの文字列からキーへの変換 指定どおり。パラメータ
pseudo-random function tmp1 = H(octet-string)
tmp2 = truncate tmp1 to multiple of m
PRF = E(DK(protocol-key, prfconstant),
tmp2, initial-cipher-state)
The "prfconstant" used in the PRF operation is the three-octet string "prf".
PRF 操作で使用される「prfconstant」は、3 オクテットの文字列「prf」です。
Cryptosystem from Simplified Profile
------------------------------------------------------------------------
key generation functions:
string-to-key function As given.
string-to-key 関数 指定どおり。
random-to-key function As given.
ランダムからキーへの関数 指定どおり。
key-derivation function The "well-known constant" used for the DK function is the key usage number, expressed as four octets in big-endian order, followed by one octet indicated below.
キー導出関数 DK 関数に使用される「既知の定数」は、ビッグエンディアン順の 4 オクテットとそれに続く以下に示す 1 オクテットで表されるキー使用番号です。
Kc = DK(base-key, usage | 0x99);
Ke = DK(base-key, usage | 0xAA);
Ki = DK(base-key, usage | 0x55);
When an encryption system is defined with the simplified profile given in section 5.2, a checksum algorithm may be defined for it as follows:
暗号化システムがセクション 5.2 で与えられた簡素化されたプロファイルで定義されている場合、チェックサム アルゴリズムは次のように定義できます。
Checksum Mechanism from Simplified Profile
--------------------------------------------------
associated cryptosystem As defined above.
get_mic HMAC(Kc, message)[1..h]
get_mic HMAC(Kc, メッセージ)[1..h]
verify_mic get_mic and compare
verify_mic get_mic と比較
The HMAC function and key Kc are as described in section 5.3.
HMAC 関数とキー Kc はセクション 5.3 で説明したとおりです。
These profiles describe the encryption and checksum systems defined for Kerberos. The astute reader will notice that some of them do not fulfill all the requirements outlined in previous sections. These systems are defined for backward compatibility; newer implementations should (whenever possible) attempt to utilize encryption systems that satisfy all the profile requirements.
これらのプロファイルは、Kerberos 用に定義された暗号化システムとチェックサム システムを記述します。賢明な読者は、それらの中には、前のセクションで概説したすべての要件を満たしていないものがあることに気づくでしょう。これらのシステムは下位互換性のために定義されています。新しい実装では、(可能な限り) すべてのプロファイル要件を満たす暗号化システムの利用を試みる必要があります。
The full list of current encryption and checksum type number assignments, including values currently reserved but not defined in this document, is given in section 8.
現在予約されているがこの文書で定義されていない値を含む、現在の暗号化とチェックサムのタイプ番号割り当ての完全なリストは、セクション 8 に記載されています。
These checksum types use no encryption keys and thus can be used in combination with any encryption type, but they may only be used with caution, in limited circumstances where the lack of a key does not provide a window for an attack, preferably as part of an encrypted message [6]. Keyed checksum algorithms are recommended.
これらのチェックサム タイプは暗号化キーを使用しないため、あらゆる暗号化タイプと組み合わせて使用できますが、キーの欠如によって攻撃の余地が得られない限られた状況で、できれば攻撃の一部として使用する場合にのみ注意して使用できます。暗号化されたメッセージ[6]。キー付きチェックサム アルゴリズムが推奨されます。
The RSA-MD5 checksum calculates a checksum by using the RSA MD5 algorithm [MD5-92]. The algorithm takes as input an input message of arbitrary length and produces as output a 128-bit (sixteen octet) checksum.
RSA-MD5 チェックサムは、RSA MD5 アルゴリズム [MD5-92] を使用してチェックサムを計算します。このアルゴリズムは、任意の長さの入力メッセージを入力として受け取り、出力として 128 ビット (16 オクテット) のチェックサムを生成します。
rsa-md5
----------------------------------------------
associated cryptosystem any
get_mic rsa-md5(msg)
get_mic rsa-md5(msg)
verify_mic get_mic and compare
verify_mic get_mic と比較
The rsa-md5 checksum algorithm is assigned a checksum type number of seven (7).
rsa-md5 チェックサム アルゴリズムには、チェックサム タイプ番号 7 が割り当てられます。
The RSA-MD4 checksum calculates a checksum using the RSA MD4 algorithm [MD4-92]. The algorithm takes as input an input message of arbitrary length and produces as output a 128-bit (sixteen octet) checksum.
RSA-MD4 チェックサムは、RSA MD4 アルゴリズム [MD4-92] を使用してチェックサムを計算します。このアルゴリズムは、任意の長さの入力メッセージを入力として受け取り、出力として 128 ビット (16 オクテット) のチェックサムを生成します。
rsa-md4
----------------------------------------------
associated cryptosystem any
get_mic md4(msg)
get_mic md4(msg)
verify_mic get_mic and compare
verify_mic get_mic と比較
The rsa-md4 checksum algorithm is assigned a checksum type number of two (2).
rsa-md4 チェックサム アルゴリズムには、チェックサム タイプ番号 2 が割り当てられます。
This CRC-32 checksum calculates a checksum based on a cyclic redundancy check as described in ISO 3309 [CRC] but modified as described below. The resulting checksum is four (4) octets in length. The CRC-32 is neither keyed nor collision-proof; thus, the use of this checksum is not recommended. An attacker using a probabilistic chosen-plaintext attack as described in [SG92] might be able to generate an alternative message that satisfies the checksum.
この CRC-32 チェックサムは、ISO 3309 [CRC] で説明されている巡回冗長検査に基づいてチェックサムを計算しますが、以下で説明するように変更されています。結果のチェックサムの長さは 4 オクテットです。CRC-32 はキー付きでも衝突防止機能もありません。したがって、このチェックサムの使用はお勧めできません。[SG92] で説明されているような確率的選択平文攻撃を使用する攻撃者は、チェックサムを満たす代替メッセージを生成できる可能性があります。
The CRC-32 checksum used in the des-cbc-crc encryption mode is identical to the 32-bit FCS described in ISO 3309 with two exceptions: The sum with the all-ones polynomial times x**k is omitted, and the final remainder is not ones-complemented. ISO 3309 describes the FCS in terms of bits, whereas this document describes the Kerberos protocol in terms of octets. To clarify the ISO 3309 definition for the purpose of computing the CRC-32 in the des-cbc-crc encryption mode, the ordering of bits in each octet shall be assumed to be LSB first. Given this assumed ordering of bits within an octet, the mapping of bits to polynomial coefficients shall be identical to that specified in ISO 3309.
des-cbc-crc 暗号化モードで使用される CRC-32 チェックサムは、ISO 3309 で説明されている 32 ビット FCS と同じですが、次の 2 つの例外があります。全 1 多項式 x**k 倍の合計は省略され、最後の剰余は 1 の補数ではありません。ISO 3309 では FCS をビット単位で説明していますが、このドキュメントでは Kerberos プロトコルをオクテット単位で説明しています。des-cbc-crc 暗号化モードで CRC-32 を計算する目的の ISO 3309 定義を明確にするために、各オクテットのビットの順序は LSB ファーストであると想定されます。オクテット内のビットのこの想定された順序を考慮すると、ビットの多項式係数へのマッピングは ISO 3309 で指定されているものと同一である必要があります。
Test values for this modified CRC function are included in appendix A.5.
この修正された CRC 関数のテスト値は付録 A.5 に含まれています。
crc32
----------------------------------------------
associated cryptosystem any
get_mic crc32(msg)
get_mic crc32(msg)
verify_mic get_mic and compare
verify_mic get_mic と比較
The crc32 checksum algorithm is assigned a checksum type number of one (1).
crc32 チェックサム アルゴリズムには、チェックサム タイプ番号 1 が割り当てられます。
These encryption systems encrypt information under the Data Encryption Standard [DES77] by using the cipher block chaining mode [DESM80]. A checksum is computed as described below and placed in the cksum field. DES blocks are eight bytes. As a result, the data to be encrypted (the concatenation of confounder, checksum, and message) must be padded to an eight byte boundary before encryption. The values of the padding bytes are unspecified.
これらの暗号化システムは、暗号ブロック連鎖モード [DESM80] を使用して、データ暗号化標準 [DES77] に基づいて情報を暗号化します。チェックサムは以下で説明するように計算され、cksum フィールドに配置されます。DES ブロックは 8 バイトです。その結果、暗号化されるデータ (交絡因子、チェックサム、メッセージの連結) は、暗号化前に 8 バイト境界までパディングする必要があります。パディングバイトの値は未指定です。
Plaintext and DES ciphertext are encoded as blocks of eight octets, which are concatenated to make the 64-bit inputs for the DES algorithms. The first octet supplies the eight most significant bits (with the octet's MSB used as the DES input block's MSB, etc.), the second octet the next eight bits, and so on. The eighth octet supplies the 8 least significant bits.
平文と DES 暗号文は 8 オクテットのブロックとしてエンコードされ、DES アルゴリズムの 64 ビット入力を作成するために連結されます。最初のオクテットは最上位 8 ビットを供給し (オクテットの MSB は DES 入力ブロックの MSB として使用されるなど)、2 番目のオクテットは次の 8 ビットを供給します。8 番目のオクテットは、8 つの最下位ビットを提供します。
Encryption under DES using cipher block chaining requires an additional input in the form of an initialization vector; this vector is specified below for each encryption system.
暗号ブロック チェーンを使用した DES での暗号化には、初期化ベクトルの形式で追加の入力が必要です。このベクトルは、暗号化システムごとに以下で指定されます。
The DES specifications [DESI81] identify four 'weak' and twelve 'semi-weak' keys; these keys SHALL NOT be used for encrypting messages for use in Kerberos. The "variant keys" generated for the RSA-MD5-DES, RSA-MD4-DES, and DES-MAC checksum types by an eXclusive-OR of a DES key with a constant are not checked for this property.
DES 仕様 [DESI81] では、4 つの「弱」キーと 12 の「半弱」キーが識別されています。これらの鍵は、Kerberos で使用するメッセージの暗号化には使用しないでください。DES キーと定数の排他的論理和によって RSA-MD5-DES、RSA-MD4-DES、および DES-MAC チェックサム タイプに対して生成される「バリアント キー」は、このプロパティに関してチェックされません。
A DES key is eight octets of data. This consists of 56 bits of actual key data, and eight parity bits, one per octet. The key is encoded as a series of eight octets written in MSB-first order. The bits within the key are also encoded in MSB order. For example, if the encryption key is (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8), where B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8 are the parity bits, the first octet of the key would be B1,B2,...,B7,P1 (with B1 as the most significant bit). See the [DESM80] introduction for reference.
DES キーは 8 オクテットのデータです。これは、56 ビットの実際のキー データと、オクテットごとに 1 つずつの 8 つのパリティ ビットで構成されます。キーは、MSB ファーストの順序で書かれた一連の 8 オクテットとしてエンコードされます。キー内のビットも MSB 順にエンコードされます。たとえば、暗号化キーが (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8 の場合))、B1、B2、...、B56 が MSB 順のキー ビット、P1、P2、...、P8 がパリティ ビットである場合、キーの最初のオクテットは B1、B2、... になります。、B7、P1 (B1 が最上位ビット)。参考として [DESM80] の概要を参照してください。
Encryption Data Format
暗号化データ形式
The format for the data to be encrypted includes a one-block confounder, a checksum, the encoded plaintext, and any necessary padding, as described in the following diagram. The msg-seq field contains the part of the protocol message to be encrypted.
次の図で説明するように、暗号化されるデータの形式には、1 ブロックの交絡子、チェックサム、エンコードされた平文、および必要なパディングが含まれます。msg-seq フィールドには、暗号化されるプロトコル メッセージの部分が含まれます。
+-----------+----------+---------+-----+
|confounder | checksum | msg-seq | pad |
+-----------+----------+---------+-----+
One generates a random confounder of one block, placing it in 'confounder'; zeros out the 'checksum' field (of length appropriate to exactly hold the checksum to be computed); adds the necessary padding; calculates the appropriate checksum over the whole sequence, placing the result in 'checksum'; and then encrypts using the specified encryption type and the appropriate key.
1 つは、1 つのブロックのランダムな交絡子を生成し、それを「交絡子」に配置します。「チェックサム」フィールド (計算されるチェックサムを正確に保持するのに適切な長さ) をゼロにします。必要なパディングを追加します。シーケンス全体にわたって適切なチェックサムを計算し、結果を「チェックサム」に置きます。次に、指定された暗号化タイプと適切なキーを使用して暗号化します。
String or Random-Data to Key Transformation
文字列またはランダムデータからキーへの変換
To generate a DES key from two UTF-8 text strings (password and salt), the two strings are concatenated, password first, and the result is then padded with zero-valued octets to a multiple of eight octets.
2 つの UTF-8 テキスト文字列 (パスワードとソルト) から DES キーを生成するには、パスワードを最初に 2 つの文字列が連結され、その結果が 8 オクテットの倍数になるまでゼロ値のオクテットで埋められます。
The top bit of each octet (always zero if the password is plain ASCII, as was assumed when the original specification was written) is discarded, and the remaining seven bits of each octet form a bitstring. This is then fan-folded and eXclusive-ORed with itself to produce a 56-bit string. An eight-octet key is formed from this string, each octet using seven bits from the bitstring, leaving the least significant bit unassigned. The key is then "corrected" by correcting the parity on the key, and if the key matches a 'weak' or 'semi-weak' key as described in the DES specification, it is eXclusive-ORed with the constant 0x00000000000000F0. This key is then used to generate a DES CBC checksum on the initial string with the salt appended. The result of the CBC checksum is then "corrected" as described above to form the result, which is returned as the key.
各オクテットの先頭ビット (元の仕様が作成されたときに想定されていたように、パスワードがプレーン ASCII の場合は常に 0) が破棄され、各オクテットの残りの 7 ビットがビット文字列を形成します。次に、これがファンフォールドされ、それ自体と排他的論理和が計算されて、56 ビット文字列が生成されます。この文字列から 8 オクテットのキーが形成され、各オクテットはビット文字列の 7 ビットを使用し、最下位ビットは割り当てられないままになります。次に、キーのパリティを修正することによってキーが「修正」され、キーが DES 仕様で説明されている「弱い」キーまたは「半弱い」キーと一致する場合は、定数 0x00000000000000F0 と排他的論理和が演算されます。このキーは、ソルトが追加された最初の文字列の DES CBC チェックサムを生成するために使用されます。CBC チェックサムの結果は、上で説明したように「修正」されて結果が形成され、キーとして返されます。
For purposes of the string-to-key function, the DES CBC checksum is calculated by CBC encrypting a string using the key as IV and the final eight byte block as the checksum.
string-to-key 関数の目的で、DES CBC チェックサムは、IV としてキーを使用し、チェックサムとして最後の 8 バイト ブロックを使用して文字列を CBC 暗号化することによって計算されます。
Pseudocode follows:
疑似コードは次のとおりです。
removeMSBits(8byteblock) {
/* Treats a 64 bit block as 8 octets and removes the MSB in
each octet (in big endian mode) and concatenates the
result. E.g., the input octet string:
01110000 01100001 11110011 01110011 11110111 01101111
11110010 01100100
results in the output bitstring:
1110000 1100001 1110011 1110011 1110111 1101111
1110010 1100100 */
}
reverse(56bitblock) {
/* Treats a 56-bit block as a binary string and reverses it.
E.g., the input string:
1000001 1010100 1001000 1000101 1001110 1000001
0101110 1001101
results in the output string:
1011001 0111010 1000001 0111001 1010001 0001001
0010101 1000001 */
}
add_parity_bits(56bitblock) {
/* Copies a 56-bit block into a 64-bit block, left shifts
content in each octet, and add DES parity bit.
E.g., the input string:
1100000 0001111 0011100 0110100 1000101 1100100
0110110 0010111
results in the output string:
11000001 00011111 00111000 01101000 10001010 11001000
01101101 00101111 */
}
key_correction(key) {
fixparity(key);
if (is_weak_key(key))
key = key XOR 0xF0;
return(key);
}
mit_des_string_to_key(string,salt) {
odd = 1;
s = string | salt;
tempstring = 0; /* 56-bit string */
pad(s); /* with nulls to 8 byte boundary */
for (8byteblock in s) {
56bitstring = removeMSBits(8byteblock);
if (odd == 0) reverse(56bitstring);
odd = ! odd;
tempstring = tempstring XOR 56bitstring;
}
tempkey = key_correction(add_parity_bits(tempstring));
key = key_correction(DES-CBC-check(s,tempkey));
return(key);
}
des_string_to_key(string,salt,params) {
if (length(params) == 0)
type = 0;
else if (length(params) == 1)
type = params[0];
else
error("invalid params");
if (type == 0)
mit_des_string_to_key(string,salt);
else
error("invalid params");
}
One common extension is to support the "AFS string-to-key" algorithm, which is not defined here, if the type value above is one (1).
一般的な拡張機能の 1 つは、上記の type 値が 1 の場合、「AFS string-to-key」アルゴリズムをサポートすることですが、このアルゴリズムはここでは定義されていません。
For generation of a key from a random bitstring, we start with a 56- bit string and, as with the string-to-key operation above, insert parity bits. If the result is a weak or semi-weak key, we modify it by eXclusive-OR with the constant 0x00000000000000F0:
ランダムなビット文字列からキーを生成するには、56 ビット文字列から開始し、上記の文字列からキーへの操作と同様に、パリティ ビットを挿入します。結果が弱キーまたは半弱キーの場合は、定数 0x00000000000000F0 を使用した排他的論理和によってキーを変更します。
des_random_to_key(bitstring) {
return key_correction(add_parity_bits(bitstring));
}
The des-cbc-md5 encryption mode encrypts information under DES in CBC mode with an all-zero initial vector and with an MD5 checksum (described in [MD5-92]) computed and placed in the checksum field.
des-cbc-md5 暗号化モードは、すべてゼロの初期ベクトルと、計算されてチェックサム フィールドに配置される MD5 チェックサム ([MD5-92] で説明されている) を使用して、CBC モードの DES に基づいて情報を暗号化します。
The encryption system parameters for des-cbc-md5 are as follows:
des-cbc-md5 の暗号化システム パラメータは次のとおりです。
des-cbc-md5
--------------------------------------------------------------------
protocol key format 8 bytes, parity in low bit of each
specific key structure copy of original key
特定のキー構造の元のキーのコピー
required checksum rsa-md5-des mechanism
必要なチェックサム rsa-md5-des メカニズム
key-generation seed 8 bytes length
キー生成シードの長さは 8 バイト
cipher state 8 bytes (CBC initial vector)
暗号状態 8 バイト (CBC 初期ベクトル)
initial cipher state all-zero
初期暗号状態はすべてゼロ
encryption function des-cbc(confounder | checksum | msg | pad, ivec=oldstate) where checksum = md5(confounder | 0000... | msg | pad)
暗号化関数 des-cbc(confounder | checksum | msg |pad, ivec=oldstate) where checksum = md5(confounder | 0000... | msg | Pad)
newstate = last block of des-cbc output
decryption function decrypt encrypted text and verify checksum
復号化関数 暗号化されたテキストを復号化し、チェックサムを検証する
newstate = last block of ciphertext
des-cbc-md5
--------------------------------------------------------------------
default string-to-key empty string
params
pseudo-random function des-cbc(md5(input-string), ivec=0)
key generation functions:
鍵生成関数:
string-to-key des_string_to_key
文字列からキーへ des_string_to_key
random-to-key des_random_to_key
ランダムからキー des_random_to_key
key-derivation identity
鍵派生アイデンティティ
The des-cbc-md5 encryption type is assigned the etype value three (3).
des-cbc-md5 暗号化タイプには、etype 値 3 が割り当てられます。
The des-cbc-md4 encryption mode also encrypts information under DES in CBC mode, with an all-zero initial vector. An MD4 checksum (described in [MD4-92]) is computed and placed in the checksum field.
des-cbc-md4 暗号化モードは、CBC モードの DES に基づいて情報をすべてゼロの初期ベクトルで暗号化します。MD4 チェックサム ([MD4-92] で説明) が計算され、チェックサム フィールドに配置されます。
des-cbc-md4
--------------------------------------------------------------------
protocol key format 8 bytes, parity in low bit of each
specific key structure copy of original key
特定のキー構造の元のキーのコピー
required checksum rsa-md4-des mechanism
必要なチェックサム rsa-md4-des メカニズム
key-generation seed 8 bytes length
キー生成シードの長さは 8 バイト
cipher state 8 bytes (CBC initial vector)
暗号状態 8 バイト (CBC 初期ベクトル)
initial cipher state all-zero
初期暗号状態はすべてゼロ
encryption function des-cbc(confounder | checksum | msg | pad, ivec=oldstate) where checksum = md4(confounder | 0000... | msg | pad)
暗号化関数 des-cbc(confounder | checksum | msg | Pad, ivec=oldstate) ここで、checksum = md4(confounder | 0000... | msg | Pad)
newstate = last block of des-cbc output
des-cbc-md4
--------------------------------------------------------------------
decryption function decrypt encrypted text and verify checksum
復号化関数 暗号化されたテキストを復号化し、チェックサムを検証する
newstate = last block of ciphertext
default string-to-key empty string params
デフォルトの文字列からキーへの空の文字列パラメータ
pseudo-random function des-cbc(md5(input-string), ivec=0)
key generation functions:
鍵生成関数:
string-to-key des_string_to_key
文字列からキーへ des_string_to_key
random-to-key copy input, then fix parity bits
入力をランダムからキーにコピーし、パリティ ビットを修正する
key-derivation identity
鍵派生アイデンティティ
Note that des-cbc-md4 uses md5, not md4, in the PRF definition.
des-cbc-md4 は PRF 定義で md4 ではなく md5 を使用することに注意してください。
The des-cbc-md4 encryption algorithm is assigned the etype value two (2).
des-cbc-md4 暗号化アルゴリズムには、etype 値 2 が割り当てられます。
The des-cbc-crc encryption type uses DES in CBC mode with the key used as the initialization vector, with a four-octet CRC-based checksum computed as described in section 6.1.3. Note that this is not a standard CRC-32 checksum, but a slightly modified one.
des-cbc-crc 暗号化タイプは、初期化ベクトルとしてキーを使用して CBC モードで DES を使用し、セクション 6.1.3 で説明されているように計算された 4 オクテットの CRC ベースのチェックサムを使用します。これは標準の CRC-32 チェックサムではなく、わずかに変更されたものであることに注意してください。
des-cbc-crc
--------------------------------------------------------------------
protocol key format 8 bytes, parity in low bit of each
specific key structure copy of original key
特定のキー構造の元のキーのコピー
required checksum rsa-md5-des mechanism
必要なチェックサム rsa-md5-des メカニズム
key-generation seed 8 bytes length
キー生成シードの長さは 8 バイト
cipher state 8 bytes (CBC initial vector)
暗号状態 8 バイト (CBC 初期ベクトル)
des-cbc-crc
--------------------------------------------------------------------
initial cipher state copy of original key
encryption function des-cbc(confounder | checksum | msg | pad, ivec=oldstate) where checksum = crc(confounder | 00000000 | msg | pad)
暗号化関数 des-cbc(confounder | checksum | msg | Pad, ivec=oldstate) where checksum = crc(confounder | 00000000 | msg | Pad)
newstate = last block of des-cbc output
decryption function decrypt encrypted text and verify checksum
復号化関数 暗号化されたテキストを復号化し、チェックサムを検証する
newstate = last block of ciphertext
default string-to-key empty string params
デフォルトの文字列からキーへの空の文字列パラメータ
pseudo-random function des-cbc(md5(input-string), ivec=0)
key generation functions:
鍵生成関数:
string-to-key des_string_to_key
文字列からキーへ des_string_to_key
random-to-key copy input, then fix parity bits
入力をランダムからキーにコピーし、パリティ ビットを修正する
key-derivation identity
鍵派生アイデンティティ
The des-cbc-crc encryption algorithm is assigned the etype value one (1).
des-cbc-crc 暗号化アルゴリズムには、etype 値 1 が割り当てられます。
The RSA-MD5-DES checksum calculates a keyed collision-proof checksum by prepending an eight octet confounder before the text, applying the RSA MD5 checksum algorithm, and encrypting the confounder and the checksum by using DES in cipher-block-chaining (CBC) mode with a variant of the key, where the variant is computed by eXclusive-ORing the key with the hexadecimal constant 0xF0F0F0F0F0F0F0F0. The initialization vector should be zero. The resulting checksum is 24 octets long.
RSA-MD5-DES チェックサムは、テキストの前に 8 オクテットの交絡子を付加し、RSA MD5 チェックサム アルゴリズムを適用し、暗号ブロック チェーン (CBC) で DES を使用して交絡子とチェックサムを暗号化することにより、キー付き衝突防止チェックサムを計算します。キーのバリアントを使用するモード。バリアントは、キーと 16 進定数 0xF0F0F0F0F0F0F0F0 の排他的論理和演算によって計算されます。初期化ベクトルはゼロである必要があります。結果のチェックサムは 24 オクテットの長さになります。
rsa-md5-des
----------------------------------------------------------------
associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc
get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0, conf | rsa-md5(conf | msg))
get_mic des-cbc(キー XOR 0xF0F0F0F0F0F0F0F0, conf | rsa-md5(conf | msg))
verify_mic decrypt and verify rsa-md5 checksum
verify_mic 復号化して rsa-md5 チェックサムを検証する
The rsa-md5-des checksum algorithm is assigned a checksum type number of eight (8).
rsa-md5-des チェックサム アルゴリズムには、チェックサム タイプ番号 8 が割り当てられます。
The RSA-MD4-DES checksum calculates a keyed collision-proof checksum by prepending an eight octet confounder before the text, applying the RSA MD4 checksum algorithm [MD4-92], and encrypting the confounder and the checksum using DES in cipher-block-chaining (CBC) mode with a variant of the key, where the variant is computed by eXclusive-ORing the key with the constant 0xF0F0F0F0F0F0F0F0 [7]. The initialization vector should be zero. The resulting checksum is 24 octets long.
RSA-MD4-DES チェックサムは、テキストの前に 8 オクテットの交絡子を付加し、RSA MD4 チェックサム アルゴリズム [MD4-92] を適用し、暗号ブロック内の DES を使用して交絡子とチェックサムを暗号化することにより、キー付き衝突防止チェックサムを計算します。キーのバリアントを使用したチェーン (CBC) モード。バリアントはキーと定数 0xF0F0F0F0F0F0F0F0 [7] の排他的論理和によって計算されます。初期化ベクトルはゼロである必要があります。結果のチェックサムは 24 オクテットの長さになります。
rsa-md4-des
----------------------------------------------------------------
associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc
get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0, conf | rsa-md4(conf | msg), ivec=0)
get_mic des-cbc(キー XOR 0xF0F0F0F0F0F0F0F0, conf | rsa-md4(conf | msg), ivec=0)
verify_mic decrypt and verify rsa-md4 checksum
verify_mic 復号化して rsa-md4 チェックサムを検証する
The rsa-md4-des checksum algorithm is assigned a checksum type number of three (3).
rsa-md4-des チェックサム アルゴリズムには、チェックサム タイプ番号 3 が割り当てられます。
The RSA-MD4-DES-K checksum calculates a keyed collision-proof checksum by applying the RSA MD4 checksum algorithm and encrypting the results by using DES in cipher block chaining (CBC) mode with a DES key as both key and initialization vector. The resulting checksum is 16 octets long. This checksum is tamper-proof and believed to be collision-proof. Note that this checksum type is the old method for encoding the RSA-MD4-DES checksum; it is no longer recommended.
RSA-MD4-DES-K チェックサムは、RSA MD4 チェックサム アルゴリズムを適用し、DES キーをキーと初期化ベクトルの両方として使用する暗号ブロック チェーン (CBC) モードで DES を使用して結果を暗号化することにより、キー付き衝突防止チェックサムを計算します。結果のチェックサムは 16 オクテットの長さになります。このチェックサムは改ざん防止機能があり、衝突防止機能があると考えられています。このチェックサム タイプは、RSA-MD4-DES チェックサムをエンコードするための古い方法であることに注意してください。それはもう推奨されません。
rsa-md4-des-k
----------------------------------------------------------------
associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc
get_mic des-cbc(key, md4(msg), ivec=key)
verify_mic decrypt, compute checksum and compare
verify_mic 復号化、チェックサムを計算して比較する
The rsa-md4-des-k checksum algorithm is assigned a checksum type number of six (6).
rsa-md4-des-k チェックサム アルゴリズムには、チェックサム タイプ番号 6 が割り当てられます。
The DES-MAC checksum is computed by prepending an eight octet confounder to the plaintext, padding with zero-valued octets if necessary to bring the length to a multiple of eight octets, performing a DES CBC-mode encryption on the result by using the key and an initialization vector of zero, taking the last block of the ciphertext, prepending the same confounder, and encrypting the pair by using DES in cipher-block-chaining (CBC) mode with a variant of the key, where the variant is computed by eXclusive-ORing the key with the constant 0xF0F0F0F0F0F0F0F0. The initialization vector should be zero. The resulting checksum is 128 bits (sixteen octets) long, 64 bits of which are redundant. This checksum is tamper-proof and collision-proof.
DES-MAC チェックサムは、平文の前に 8 オクテットの交絡子を付加し、必要に応じて値 0 のオクテットをパディングして長さを 8 オクテットの倍数にし、キーを使用して結果に対して DES CBC モード暗号化を実行することによって計算されます。ゼロの初期化ベクトル、暗号文の最後のブロックを取得し、同じ交絡因子を先頭に追加し、キーのバリアントを使用して暗号ブロックチェーン (CBC) モードで DES を使用してペアを暗号化します。バリアントは次のように計算されます。キーと定数 0xF0F0F0F0F0F0F0F0 の排他的論理和を演算します。初期化ベクトルはゼロである必要があります。結果のチェックサムは 128 ビット (16 オクテット) の長さで、そのうち 64 ビットは冗長です。このチェックサムは改ざん防止および衝突防止機能を備えています。
des-mac
---------------------------------------------------------------------
associated des-cbc-md5, des-cbc-md4, des-cbc-crc
cryptosystem
get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0, conf | des-mac(key, conf | msg | pad, ivec=0), ivec=0)
get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0, conf | des-mac(key, conf | msg | Pad, ivec=0), ivec=0)
verify_mic decrypt, compute DES MAC using confounder, compare
verify_mic 復号化、交絡関数を使用して DES MAC を計算、比較
The des-mac checksum algorithm is assigned a checksum type number of four (4).
des-mac チェックサム アルゴリズムには、チェックサム タイプ番号 4 が割り当てられます。
The DES-MAC-K checksum is computed by performing a DES CBC-mode encryption of the plaintext, with zero-valued padding bytes if necessary to bring the length to a multiple of eight octets, and by using the last block of the ciphertext as the checksum value. It is keyed with an encryption key that is also used as the initialization vector. The resulting checksum is 64 bits (eight octets) long. This checksum is tamper-proof and collision-proof. Note that this checksum type is the old method for encoding the DESMAC checksum; it is no longer recommended.
DES-MAC-K チェックサムは、平文の DES CBC モード暗号化を実行し、必要に応じて長さを 8 オクテットの倍数にするためにゼロ値のパディング バイトを使用し、暗号文の最後のブロックを使用して計算されます。チェックサム値。これは、初期化ベクトルとしても使用される暗号化キーでキー化されます。結果のチェックサムは 64 ビット (8 オクテット) の長さになります。このチェックサムは改ざん防止および衝突防止機能を備えています。このチェックサム タイプは、DESMAC チェックサムをエンコードするための古い方法であることに注意してください。それはもう推奨されません。
des-mac-k
----------------------------------------------------------------
associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc
get_mic des-mac(key, msg | pad, ivec=key)
get_mic des-mac(キー, メッセージ | パッド, ivec=キー)
verify_mic compute MAC and compare
verify_mic MAC を計算して比較します
The des-mac-k checksum algorithm is assigned a checksum type number of five (5).
des-mac-k チェックサム アルゴリズムには、チェックサム タイプ番号 5 が割り当てられます。
This encryption and checksum type pair is based on the Triple DES cryptosystem in Outer-CBC mode and on the HMAC-SHA1 message authentication algorithm.
この暗号化とチェックサム タイプのペアは、Outer-CBC モードの Triple DES 暗号化システムと HMAC-SHA1 メッセージ認証アルゴリズムに基づいています。
A Triple DES key is the concatenation of three DES keys as described above for des-cbc-md5. A Triple DES key is generated from random data by creating three DES keys from separate sequences of random data.
トリプル DES キーは、des-cbc-md5 について上で説明したように、3 つの DES キーを連結したものです。トリプル DES キーは、ランダム データの別々のシーケンスから 3 つの DES キーを作成することによって、ランダム データから生成されます。
Encrypted data using this type must be generated as described in section 5.3. If the length of the input data is not a multiple of the block size, zero-valued octets must be used to pad the plaintext to the next eight-octet boundary. The confounder must be eight random octets (one block).
このタイプを使用する暗号化データは、セクション 5.3 の説明に従って生成する必要があります。入力データの長さがブロック サイズの倍数でない場合は、値 0 のオクテットを使用して、平文を次の 8 オクテット境界までパディングする必要があります。交絡因子は 8 つのランダムなオクテット (1 ブロック) でなければなりません。
The simplified profile for Triple DES, with key derivation as defined in section 5, is as follows:
セクション 5 で定義されているキー導出を使用した Triple DES の簡略化されたプロファイルは次のとおりです。
des3-cbc-hmac-sha1-kd, hmac-sha1-des3-kd
------------------------------------------------
protocol key format 24 bytes, parity in low
bit of each
key-generation seed 21 bytes length
キー生成シードの長さは 21 バイト
des3-cbc-hmac-sha1-kd, hmac-sha1-des3-kd
------------------------------------------------
hash function SHA-1
HMAC output size 160 bits
HMAC 出力サイズ 160 ビット
message block size 8 bytes
メッセージ ブロック サイズ 8 バイト
default string-to-key empty string params
デフォルトの文字列からキーへの空の文字列パラメータ
encryption and triple-DES encrypt and decryption functions decrypt, in outer-CBC mode (cipher block size 8 octets)
暗号化およびトリプル DES 暗号化および復号化機能 外部 CBC モードで復号化 (暗号ブロック サイズ 8 オクテット)
key generation functions:
鍵生成関数:
random-to-key DES3random-to-key (see below)
ランダムからキー DES3ランダムからキー (以下を参照)
string-to-key DES3string-to-key (see below)
文字列からキーへ DES3文字列からキーへ (以下を参照)
The des3-cbc-hmac-sha1-kd encryption type is assigned the value sixteen (16). The hmac-sha1-des3-kd checksum algorithm is assigned a checksum type number of twelve (12).
des3-cbc-hmac-sha1-kd 暗号化タイプには値 16 が割り当てられます。hmac-sha1-des3-kd チェックサム アルゴリズムには、チェックサム タイプ番号 12 が割り当てられます。
The 168 bits of random key data are converted to a protocol key value as follows. First, the 168 bits are divided into three groups of 56 bits, which are expanded individually into 64 bits as follows:
168 ビットのランダム キー データは、次のようにプロトコル キー値に変換されます。まず、168 ビットが 56 ビットの 3 つのグループに分割され、次のように個別に 64 ビットに拡張されます。
DES3random-to-key: 1 2 3 4 5 6 7 p 9 10 11 12 13 14 15 p 17 18 19 20 21 22 23 p 25 26 27 28 29 30 31 p 33 34 35 36 37 38 39 p 41 42 43 44 45 46 47 p 49 50 51 52 53 54 55 p 56 48 40 32 24 16 8 p
DES3ランダム対キー: 1 2 3 4 5 6 7 p 9 10 11 12 13 14 15 p 17 18 19 20 21 22 23 p 25 26 27 28 29 30 31 p 33 34 35 36 37 38 39 p 41 42 43 4445 46 47 p 49 50 51 52 53 54 55 p 56 48 40 32 24 16 8 p
The "p" bits are parity bits computed over the data bits. The output of the three expansions, each corrected to avoid "weak" and "semi-weak" keys as in section 6.2, are concatenated to form the protocol key value.
「p」ビットは、データ ビットに対して計算されたパリティ ビットです。セクション 6.2 のように「弱い」キーと「半弱い」キーを避けるためにそれぞれ修正された 3 つの拡張の出力は、連結されてプロトコル キー値を形成します。
The string-to-key function is used to transform UTF-8 passwords into DES3 keys. The DES3 string-to-key function relies on the "N-fold" algorithm and DK function, described in section 5.
string-to-key 関数は、UTF-8 パスワードを DES3 キーに変換するために使用されます。DES3 の string-to-key 関数は、セクション 5 で説明されている「N-fold」アルゴリズムと DK 関数に依存しています。
The n-fold algorithm is applied to the password string concatenated with a salt value. For 3-key triple DES, the operation will involve a 168-fold of the input password string, to generate an intermediate key, from which the user's long-term key will be derived with the DK function. The DES3 string-to-key function is shown here in pseudocode:
n-fold アルゴリズムは、ソルト値と連結されたパスワード文字列に適用されます。3 キー トリプル DES の場合、操作には入力パスワード文字列を 168 倍して中間キーを生成し、そこからユーザーの長期キーが DK 関数で導出されます。DES3 の string-to-key 関数を疑似コードで示します。
DES3string-to-key(passwordString, salt, params)
if (params != emptyString)
error("invalid params");
s = passwordString + salt
tmpKey = random-to-key(168-fold(s))
key = DK (tmpKey, KerberosConstant)
Weak key checking is performed in the random-to-key and DK operations. The KerberosConstant value is the byte string {0x6b 0x65 0x72 0x62 0x65 0x72 0x6f 0x73}. These values correspond to the ASCII encoding for the string "kerberos".
弱い鍵のチェックは、random-to-key および DK 操作で実行されます。KerberosConstant 値はバイト文字列 {0x6b 0x65 0x72 0x62 0x65 0x72 0x6f 0x73} です。これらの値は、文字列「kerberos」の ASCII エンコードに対応します。
Several Kerberos-based application protocols and preauthentication systems have been designed and deployed that perform encryption and message integrity checks in various ways. Although in some cases there may be good reason for specifying these protocols in terms of specific encryption or checksum algorithms, we anticipate that in many cases this will not be true, and more generic approaches independent of particular algorithms will be desirable. Rather than have each protocol designer reinvent schemes for protecting data, using multiple keys, etc., we have attempted to present in this section a general framework that should be sufficient not only for the Kerberos protocol itself but also for many preauthentication systems and application protocols, while trying to avoid some of the assumptions that can work their way into such protocol designs.
さまざまな方法で暗号化とメッセージの整合性チェックを実行する、いくつかの Kerberos ベースのアプリケーション プロトコルと事前認証システムが設計および展開されています。場合によっては、特定の暗号化またはチェックサム アルゴリズムに関してこれらのプロトコルを指定する十分な理由がある場合もありますが、多くの場合これは当てはまらず、特定のアルゴリズムに依存しないより一般的なアプローチが望ましいと予想されます。各プロトコル設計者に複数のキーの使用などのデータ保護スキームを再発明させるのではなく、このセクションでは、Kerberos プロトコル自体だけでなく、多くの事前認証システムやアプリケーション プロトコルにも十分な一般的なフレームワークを提示することを試みました。一方で、そのようなプロトコル設計に影響を与える可能性のあるいくつかの仮定を回避しようとします。
Some problematic assumptions we've seen (and sometimes made) include the following: a random bitstring is always valid as a key (not true for DES keys with parity); the basic block encryption chaining mode provides no integrity checking, or can easily be separated from such checking (not true for many modes in development that do both simultaneously); a checksum for a message always results in the same value (not true if a confounder is incorporated); an initial vector is used (may not be true if a block cipher in CBC mode is not in use).
私たちがこれまでに目にした (そして時々行った) 問題のある仮定には次のようなものがあります。ランダムなビット文字列は常にキーとして有効です (パリティのある DES キーには当てはまりません)。基本的なブロック暗号化チェーン モードでは整合性チェックが提供されないか、そのようなチェックから簡単に分離できます (両方を同時に実行する開発中の多くのモードには当てはまりません)。メッセージのチェックサムは常に同じ値になります (交絡因子が組み込まれている場合は当てはまりません)。初期ベクトルが使用されます (CBC モードのブロック暗号が使用されていない場合は当てはまらない可能性があります)。
Although such assumptions the may hold for any given set of encryption and checksum algorithms, they may not be true of the next algorithms to be defined, leaving the application protocol unable to make use of those algorithms without updates to its specification.
このような仮定は、暗号化アルゴリズムとチェックサム アルゴリズムの任意のセットに当てはまりますが、次に定義されるアルゴリズムには当てはまらない可能性があり、仕様を更新しない限りアプリケーション プロトコルはこれらのアルゴリズムを利用できなくなります。
The Kerberos protocol uses only the attributes and operations described in sections 3 and 4. Preauthentication systems and application protocols making use of Kerberos are encouraged to use them as well. The specific key and string-to-key parameters should generally be treated as opaque. Although the string-to-key parameters are manipulated as an octet string, the representation for the specific key structure is implementation defined; it may not even be a single object.
Kerberos プロトコルは、セクション 3 と 4 で説明されている属性と操作のみを使用します。Kerberos を利用する事前認証システムとアプリケーション プロトコルも同様に使用することが推奨されます。特定のキーおよび文字列からキーへのパラメーターは、通常、不透明として扱う必要があります。文字列からキーへのパラメータはオクテット文字列として操作されますが、特定のキー構造の表現は実装によって定義されます。単一のオブジェクトではない場合もあります。
We don't recommend doing so, but some application protocols will undoubtedly continue to use the key data directly, even if only in some of the currently existing protocol specifications. An implementation intended to support general Kerberos applications may therefore need to make the key data available, as well as the attributes and operations described in sections 3 and 4 [8].
そうすることはお勧めしませんが、一部のアプリケーション プロトコルは、たとえ現在存在するプロトコル仕様の一部のみであっても、間違いなくキー データを直接使用し続けるでしょう。したがって、一般的な Kerberos アプリケーションをサポートすることを目的とした実装では、セクション 3 と 4 で説明されている属性と操作だけでなく、キー データも利用可能にする必要がある場合があります [8]。
The following encryption-type numbers are already assigned or reserved for use in Kerberos and related protocols.
次の暗号化タイプの番号は、Kerberos および関連プロトコルで使用するためにすでに割り当てられているか、予約されています。
encryption type etype section or comment
-----------------------------------------------------------------
des-cbc-crc 1 6.2.3
des-cbc-md4 2 6.2.2
des-cbc-md5 3 6.2.1
[reserved] 4
des3-cbc-md5 5
[reserved] 6
des3-cbc-sha1 7
dsaWithSHA1-CmsOID 9 (pkinit)
md5WithRSAEncryption-CmsOID 10 (pkinit)
sha1WithRSAEncryption-CmsOID 11 (pkinit)
rc2CBC-EnvOID 12 (pkinit)
rsaEncryption-EnvOID 13 (pkinit from PKCS#1 v1.5)
rsaES-OAEP-ENV-OID 14 (pkinit from PKCS#1 v2.0)
des-ede3-cbc-Env-OID 15 (pkinit)
des3-cbc-sha1-kd 16 6.3
aes128-cts-hmac-sha1-96 17 [KRB5-AES]
aes256-cts-hmac-sha1-96 18 [KRB5-AES]
rc4-hmac 23 (Microsoft)
rc4-hmac-exp 24 (Microsoft)
subkey-keymaterial 65 (opaque; PacketCable)
(The "des3-cbc-sha1" assignment is a deprecated version using no key derivation. It should not be confused with des3-cbc-sha1-kd.)
(「des3-cbc-sha1」割り当ては、キー導出を使用しない非推奨のバージョンです。des3-cbc-sha1-kd と混同しないでください。)
Several numbers have been reserved for use in encryption systems not defined here. Encryption-type numbers have unfortunately been overloaded on occasion in Kerberos-related protocols, so some of the reserved numbers do not and will not correspond to encryption systems fitting the profile presented here.
いくつかの番号は、ここで定義されていない暗号化システムで使用するために予約されています。残念ながら、暗号化タイプの番号は Kerberos 関連のプロトコルで過負荷になることが時々あるため、予約されている番号の一部は、ここで説明するプロファイルに適合する暗号化システムに対応しません。また、今後も対応しません。
The following checksum-type numbers are assigned or reserved. As with encryption-type numbers, some overloading of checksum numbers has occurred.
次のチェックサム タイプの番号が割り当てられているか、予約されています。暗号化タイプの数値と同様に、チェックサム数値の一部の過負荷が発生しています。
Checksum type sumtype checksum section or
value size reference
---------------------------------------------------------------------
CRC32 1 4 6.1.3
rsa-md4 2 16 6.1.2
rsa-md4-des 3 24 6.2.5
des-mac 4 16 6.2.7
des-mac-k 5 8 6.2.8
rsa-md4-des-k 6 16 6.2.6
rsa-md5 7 16 6.1.1
rsa-md5-des 8 24 6.2.4
rsa-md5-des3 9 24 ??
sha1 (unkeyed) 10 20 ??
hmac-sha1-des3-kd 12 20 6.3
hmac-sha1-des3 13 20 ??
sha1 (unkeyed) 14 20 ??
hmac-sha1-96-aes128 15 20 [KRB5-AES]
hmac-sha1-96-aes256 16 20 [KRB5-AES]
[reserved] 0x8003 ? [GSS-KRB5]
Encryption and checksum-type numbers are signed 32-bit values. Zero is invalid, and negative numbers are reserved for local use. All standardized values must be positive.
暗号化およびチェックサム タイプの数値は、符号付きの 32 ビット値です。ゼロは無効であり、負の数値はローカル使用のために予約されています。すべての標準化された値は正でなければなりません。
The "interface" described here is the minimal information that must be defined to make a cryptosystem useful within Kerberos in an interoperable fashion. The use of functional notation used in some places is not an attempt to define an API for cryptographic functionality within Kerberos. Actual implementations providing clean APIs will probably make additional information available, that could be derived from a specification written to the framework given here. For example, an application designer may wish to determine the largest number of bytes that can be encrypted without overflowing a certain size output buffer or conversely, the maximum number of bytes that might be obtained by decrypting a ciphertext message of a given size. (In fact, an implementation of the GSS-API Kerberos mechanism [GSS-KRB5] will require some of these.)
ここで説明する「インターフェイス」は、Kerberos 内で相互運用可能な方法で暗号システムを使用できるようにするために定義する必要がある最小限の情報です。一部の場所で使用されている関数表記の使用は、Kerberos 内の暗号化機能の API を定義しようとするものではありません。クリーンな API を提供する実際の実装では、ここで示したフレームワークに記述された仕様から得られる追加情報が利用可能になる可能性があります。たとえば、アプリケーション設計者は、特定のサイズの出力バッファをオーバーフローさせることなく暗号化できる最大バイト数、または逆に、特定のサイズの暗号文メッセージを復号化することで取得できる最大バイト数を決定したい場合があります。(実際、GSS-API Kerberos メカニズム [GSS-KRB5] の実装には、これらのいくつかが必要になります。)
The presence of a mechanism in this document should not be taken to indicate that it must be implemented for compliance with any specification; required mechanisms will be specified elsewhere. Indeed, some of the mechanisms described here for backward compatibility are now considered rather weak for protecting critical data.
この文書内のメカニズムの存在は、仕様に準拠するために実装する必要があることを示すものとして解釈されるべきではありません。必要なメカニズムは別の場所で指定されます。実際、下位互換性のためにここで説明したメカニズムの一部は、重要なデータを保護するにはかなり弱いと現在考えられています。
Recent years have brought so many advancements in large-scale attacks capability against DES that it is no longer considered a strong encryption mechanism. Triple-DES is generally preferred in its place, despite its poorer performance. See [ESP-DES] for a summary of some of the potential attacks and [EFF-DES] for a detailed discussion of the implementation of particular attacks. However, most Kerberos implementations still have DES as their primary interoperable encryption type.
近年、DES に対する大規模な攻撃能力が大幅に進歩したため、DES はもはや強力な暗号化メカニズムとは見なされなくなりました。パフォーマンスは劣りますが、一般的に Triple-DES が代わりに好まれます。潜在的な攻撃の概要については [ESP-DES] を、特定の攻撃の実装の詳細については [EFF-DES] を参照してください。ただし、ほとんどの Kerberos 実装では、依然として相互運用可能なプライマリ暗号化タイプとして DES が使用されています。
DES has four 'weak' keys and twelve 'semi-weak' keys, and the use of single-DES here avoids them. However, DES also has 48 'possibly-weak' keys [Schneier96] (note that the tables in many editions of the reference contains errors) that are not avoided.
DES には 4 つの「弱い」キーと 12 つの「準弱い」キーがあり、ここで単一 DES を使用することでそれらを回避できます。ただし、DES には回避できない 48 個の「おそらく弱い」キー [Schneier96] もあります (リファレンスの多くの版の表にはエラーが含まれていることに注意してください)。
DES weak keys have the property that E1(E1(P)) = P (where E1 denotes encryption of a single block with key 1). DES semi-weak keys, or "dual" keys, are pairs of keys with the property that E1(P) = D2(P), and thus E2(E1(P)) = P. Because of the use of CBC mode and the leading random confounder, however, these properties are unlikely to present a security problem.
DES の弱い鍵には、E1(E1(P)) = P という特性があります (ここで、E1 は鍵 1 による単一ブロックの暗号化を示します)。DES の半弱いキー、つまり「デュアル」キーは、E1(P) = D2(P)、つまり E2(E1(P)) = P という特性を持つキーのペアです。CBC モードとただし、これらのプロパティがセキュリティ上の問題を引き起こす可能性はほとんどありません。
Many of the choices concerning when to perform weak-key corrections relate more to compatibility with existing implementations than to any risk analysis.
弱キー修正をいつ実行するかに関する選択の多くは、リスク分析よりも既存の実装との互換性に関係しています。
Although checks are also done for the component DES keys in a triple-DES key, the nature of the weak keys make it extremely unlikely that they will weaken the triple-DES encryption. It is only slightly more likely than having the middle of the three sub-keys match one of the other two, which effectively converts the encryption to single-DES - a case we make no effort to avoid.
チェックはトリプル DES キー内のコンポーネント DES キーに対しても行われますが、弱いキーの性質上、トリプル DES 暗号化が弱くなる可能性は非常に低いです。3 つのサブキーの中央が他の 2 つのサブキーのいずれかに一致する可能性よりもわずかに高いだけで、暗号化が単一 DES に効果的に変換されます。このケースは、私たちが避けるように努めています。
The true CRC-32 checksum is not collision-proof; an attacker could use a probabilistic chosen-plaintext attack to generate a valid message even if a confounder is used [SG92]. The use of collision-proof checksums is of course recommended for environments where such attacks represent a significant threat. The "simplifications" (read: bugs) introduced when CRC-32 was implemented for Kerberos cause leading zeros effectively to be ignored, so messages differing only in leading zero bits will have the same checksum.
真の CRC-32 チェックサムは衝突防止機能を備えていません。攻撃者は、交絡因子が使用された場合でも、確率的選択平文攻撃を使用して有効なメッセージを生成する可能性があります [SG92]。もちろん、そのような攻撃が重大な脅威となる環境では、衝突防止チェックサムの使用が推奨されます。CRC-32 が Kerberos に実装されたときに導入された「簡略化」 (バグと読みます) により、先行ゼロが事実上無視されるため、先行ゼロ ビットのみが異なるメッセージは同じチェックサムを持つことになります。
[HMAC] and [IPSEC-HMAC] discuss weaknesses of the HMAC algorithm. Unlike [IPSEC-HMAC], the triple-DES specification here does not use the suggested truncation of the HMAC output. As pointed out in [IPSEC-HMAC], SHA-1 was not developed for use as a keyed hash function, which is a criterion of HMAC. [HMAC-TEST] contains test vectors for HMAC-SHA-1.
[HMAC] および [IPSEC-HMAC] では、HMAC アルゴリズムの弱点について説明しています。[IPSEC-HMAC] とは異なり、ここでの Triple-DES 仕様では、提案されている HMAC 出力の切り捨てが使用されません。[IPSEC-HMAC] で指摘されているように、SHA-1 は、HMAC の基準であるキー付きハッシュ関数として使用するために開発されたものではありません。[HMAC-TEST] には、HMAC-SHA-1 のテスト ベクターが含まれています。
The mit_des_string_to_key function was originally constructed with the assumption that all input would be ASCII; it ignores the top bit of each input byte. Folding with XOR is also not an especially good mixing mechanism for preserving randomness.
mit_des_string_to_key 関数は当初、すべての入力が ASCII であることを前提として構築されました。各入力バイトの先頭ビットは無視されます。XOR を使用したフォールディングも、ランダム性を維持するための特に優れた混合メカニズムではありません。
The n-fold function used in the string-to-key operation for des3- cbc-hmac-sha1-kd was designed to cause each bit of input to contribute equally to the output. It was not designed to maximize or equally distribute randomness in the input, and conceivably randomness may be lost in cases of partially structured input. This should only be an issue for highly structured passwords, however.
des3-cbc-hmac-sha1-kd の string-to-key 操作で使用される n-fold 関数は、入力の各ビットが出力に均等に寄与するように設計されています。入力のランダム性を最大化または均等に分散するように設計されていないため、部分的に構造化された入力の場合にはランダム性が失われる可能性があります。ただし、これは高度に構造化されたパスワードの場合にのみ問題となるはずです。
[RFC1851] discusses the relative strength of triple-DES encryption. The relatively slow speed of triple-DES encryption may also be an issue for some applications.
[RFC1851] では、トリプル DES 暗号化の相対的な強度について説明しています。Triple-DES 暗号化の速度が比較的遅いことも、一部のアプリケーションでは問題になる可能性があります。
[Bellovin91] suggests that analyses of encryption schemes include a model of an attacker capable of submitting known plaintexts to be encrypted with an unknown key, as well as be able to perform many types of operations on known protocol messages. Recent experiences with the chosen-plaintext attacks on Kerberos version 4 bear out the value of this suggestion.
[Bellovin91] は、暗号化スキームの分析には、既知の平文を送信して未知の鍵で暗号化することができ、また既知のプロトコル メッセージに対してさまざまなタイプの操作を実行できる攻撃者のモデルが含まれていることを示唆しています。Kerberos バージョン 4 に対する選択平文攻撃に関する最近の経験は、この提案の価値を裏付けています。
The use of unkeyed encrypted checksums, such as those used in the single-DES cryptosystems specified in [Kerb1510], allows for cut-and-paste attacks, especially if a confounder is not used. In addition, unkeyed encrypted checksums are vulnerable to chosen-plaintext attacks: An attacker with access to an encryption oracle can easily encrypt the required unkeyed checksum along with the chosen plaintext. [Bellovin99] These weaknesses, combined with a common implementation design choice described below, allow for a cross-protocol attack from version 4 to version 5.
[Kerb1510] で指定されているシングル DES 暗号システムで使用されているような、キーなしの暗号化チェックサムを使用すると、特に交絡因子が使用されていない場合、カット アンド ペースト攻撃が可能になります。さらに、キーなしの暗号化チェックサムは選択平文攻撃に対して脆弱です。暗号化オラクルにアクセスできる攻撃者は、必要なキーなしチェックサムを選択した平文とともに簡単に暗号化できます。[Bellovin99] これらの弱点は、以下で説明する一般的な実装設計の選択と組み合わせることで、バージョン 4 からバージョン 5 へのクロスプロトコル攻撃を可能にします。
The use of a random confounder is an important means to prevent an attacker from making effective use of protocol exchanges as an encryption oracle. In Kerberos version 4, the encryption of constant plaintext to constant ciphertext makes an effective encryption oracle for an attacker. The use of random confounders in [Kerb1510] frustrates this sort of chosen-plaintext attack.
ランダム交絡因子の使用は、攻撃者がプロトコル交換を暗号化の神託として効果的に利用することを防ぐ重要な手段です。Kerberos バージョン 4 では、一定の平文から一定の暗号文への暗号化により、攻撃者にとって効果的な暗号化のオラクルとなります。[Kerb1510] でのランダム交絡因子の使用は、この種の選択平文攻撃を挫折させます。
Using the same key for multiple purposes can enable or increase the scope of chosen-plaintext attacks. Some software that implements both versions 4 and 5 of the Kerberos protocol uses the same keys for both versions. This enables the encryption oracle of version 4 to be used to attack version 5. Vulnerabilities to attacks such as this cross-protocol attack make it unwise to use a key for multiple purposes.
同じキーを複数の目的で使用すると、選択平文攻撃が有効になったり、範囲が拡大したりする可能性があります。Kerberos プロトコルのバージョン 4 と 5 の両方を実装する一部のソフトウェアは、両方のバージョンで同じキーを使用します。これにより、バージョン 4 の暗号化オラクルを使用してバージョン 5 を攻撃できるようになります。このクロスプロトコル攻撃のような攻撃に対する脆弱性により、キーを複数の目的に使用することは賢明ではありません。
This document, like the Kerberos protocol, does not address limiting the amount of data a key may be used with to a quantity based on the robustness of the algorithm or size of the key. It is assumed that any defined algorithms and key sizes will be strong enough to support very large amounts of data, or they will be deprecated once significant attacks are known.
この文書は、Kerberos プロトコルと同様に、キーで使用できるデータの量を、アルゴリズムの堅牢性やキーのサイズに基づいた量に制限することについては扱っていません。定義されたアルゴリズムとキー サイズは、非常に大量のデータをサポートできるほど強力であるか、重大な攻撃が判明した時点で非推奨になることが想定されています。
This document also places no bounds on the amount of data that can be handled in various operations. To avoid denial of service attacks, implementations will probably seek to restrict message sizes at some higher level.
また、このドキュメントでは、さまざまな操作で処理できるデータの量に制限を設けません。サービス拒否攻撃を回避するために、実装ではおそらく、より高いレベルでメッセージ サイズを制限しようとするでしょう。
Two registries for numeric values have been created: Kerberos Encryption Type Numbers and Kerberos Checksum Type Numbers. These are signed values ranging from -2147483648 to 2147483647. Positive values should be assigned only for algorithms specified in accordance with this specification for use with Kerberos or related protocols. Negative values are for private use; local and experimental algorithms should use these values. Zero is reserved and may not be assigned.
数値用の 2 つのレジストリ、Kerberos 暗号化タイプ番号と Kerberos チェックサム タイプ番号が作成されました。これらは、-2147483648 ～ 2147483647 の範囲の符号付き値です。Kerberos または関連プロトコルで使用するために、この仕様に従って指定されたアルゴリズムにのみ正の値を割り当てる必要があります。負の値は私用です。ローカルおよび実験的なアルゴリズムでは、これらの値を使用する必要があります。ゼロは予約されているため、割り当てることはできません。
Positive encryption- and checksum-type numbers may be assigned following either of two policies described in [BCP26].
[BCP26] で説明されている 2 つのポリシーのいずれかに従って、正の暗号化タイプ番号とチェックサム タイプ番号を割り当てることができます。
Standards-track specifications may be assigned values under the Standards Action policy.
標準化トラックの仕様には、標準化活動ポリシーに基づいて値が割り当てられる場合があります。
Specifications in non-standards track RFCs may be assigned values after Expert Review. A non-IETF specification may be assigned values by publishing an Informational or standards-track RFC referencing the external specification; that specification must be public and published in some permanent record, much like the IETF RFCs. It is highly desirable, though not required, that the full specification be published as an IETF RFC.
非標準トラック RFC の仕様には、専門家のレビュー後に値が割り当てられる場合があります。非 IETF 仕様には、外部仕様を参照する情報 RFC または標準化トラック RFC を発行することによって値が割り当てられる場合があります。その仕様は公開され、IETF RFC と同様に、何らかの永続的な記録として公開される必要があります。必須ではありませんが、完全な仕様が IETF RFC として公開されることが非常に望ましいです。
Smaller encryption type values should be used for IETF standards-track mechanisms, and much higher values (16777216 and above) for other mechanisms. (Rationale: In the Kerberos ASN.1 encoding, smaller numbers encode to smaller octet sequences, so this favors standards-track mechanisms with slightly smaller messages.) Aside from that guideline, IANA may choose numbers as it sees fit.
IETF 標準トラック メカニズムにはより小さい暗号化タイプの値を使用し、他のメカニズムにはより大きな値 (16777216 以上) を使用する必要があります。(理論的根拠: Kerberos ASN.1 エンコーディングでは、小さい数値はより小さいオクテット シーケンスにエンコードされるため、これにより、わずかに小さいメッセージを含む標準トラック メカニズムが優先されます。) このガイドラインとは別に、IANA は適切と判断した数値を選択する場合があります。
Internet-Draft specifications should not include values for encryption- and checksum-type numbers. Instead, they should indicate that values would be assigned by IANA when the document is approved as an RFC. For development and interoperability testing, values in the private-use range (negative values) may be used but should not be included in the draft specification.
インターネット ドラフト仕様には、暗号化タイプおよびチェックサム タイプの数値を含めるべきではありません。代わりに、文書が RFC として承認されたときに IANA によって値が割り当てられることを示す必要があります。開発および相互運用性テストでは、私的使用範囲の値 (負の値) を使用することはできますが、仕様草案には含めるべきではありません。
Each registered value should have an associated unique reference name. The lists given in section 8 were used to create the initial registry; they include reservations for specifications in progress in parallel with this document, and certain other values believed to already be in use.
登録された各値には、一意の参照名が関連付けられている必要があります。セクション 8 で示されたリストは、初期レジストリの作成に使用されました。これらには、この文書と並行して進行中の仕様に対する予約や、すでに使用されていると考えられる他の特定の値が含まれます。
This document is an extension of the encryption specification included in [Kerb1510] by B. Clifford Neuman and John Kohl, and much of the text of the background, concepts, and DES specifications is drawn directly from that document.
この文書は、B. Clifford Neuman と John Kohl による [Kerb1510] に含まれる暗号化仕様の拡張であり、背景、概念、および DES 仕様のテキストの多くはその文書から直接引用されています。
The abstract framework presented in this document was put together by Jeff Altman, Sam Hartman, Jeff Hutzelman, Cliff Neuman, Ken Raeburn, and Tom Yu, and the details were refined several times based on comments from John Brezak and others.
この文書で示されている抽象的な枠組みは、Jeff Altman、Sam Hartman、Jeff Hutzelman、Cliff Neuman、Ken Raeburn、Tom Yu によってまとめられ、詳細は John Brezak などからのコメントに基づいて数回改良されました。
Marc Horowitz wrote the original specification of triple-DES and key derivation in a pair of Internet-Drafts (under the names draft-horowitz-key-derivation and draft-horowitz-kerb-key-derivation) that were later folded into a draft revision of [Kerb1510], from which this document was later split off.
Marc Horowitz は、トリプル DES とキー導出の元の仕様を 1 対のインターネット ドラフト (draft-horowitz-key-derivation およびdraft-horowitz-kerb-key-derivation という名前) で作成し、後に草案改訂版に組み込まれました。[Kerb1510] の文書であり、この文書は後に分割されました。
Tom Yu provided the text describing the modifications to the standard CRC algorithm as Kerberos implementations actually use it, and some of the text in the Security Considerations section.
Tom Yu は、Kerberos 実装で実際に使用される標準 CRC アルゴリズムの変更を説明するテキストと、「セキュリティに関する考慮事項」セクションのテキストの一部を提供しました。
Miroslav Jurisic provided information for one of the UTF-8 test cases for the string-to-key functions.
Miroslav Jurisic は、文字列からキーへの関数の UTF-8 テスト ケースの 1 つに関する情報を提供しました。
Marcus Watts noticed some errors in earlier versions and pointed out that the simplified profile could easily be modified to support cipher text stealing modes.
Marcus Watts 氏は、以前のバージョンのいくつかのエラーに気づき、暗号文窃取モードをサポートするために簡素化されたプロファイルを簡単に変更できると指摘しました。
Simon Josefsson contributed some clarifications to the DES "CBC checksum" and string-to-key and weak key descriptions, and some test vectors.
Simon Josefsson は、DES の「CBC チェックサム」、文字列からキーと弱いキーの説明、およびいくつかのテスト ベクトルについていくつかの説明を提供しました。
Simon Josefsson, Louis LeVay, and others also caught some errors in earlier versions of this document.
Simon Josefsson、Louis LeVay らも、このドキュメントの以前のバージョンでいくつかの誤りを発見しました。
A. Test Vectors
A. テストベクトル
This section provides test vectors for various functions defined or described in this document. For convenience, most inputs are ASCII strings, though some UTF-8 samples are provided for string-to-key functions. Keys and other binary data are specified as hexadecimal strings.
このセクションでは、このドキュメントで定義または説明されているさまざまな関数のテスト ベクトルを提供します。便宜上、ほとんどの入力は ASCII 文字列ですが、文字列からキーへの関数用にいくつかの UTF-8 サンプルが提供されています。キーおよびその他のバイナリ データは 16 進文字列として指定されます。
The n-fold function is defined in section 5.1. As noted there, the sample vector in the original paper defining the algorithm appears to be incorrect. Here are some test cases provided by Marc Horowitz and Simon Josefsson:
n 倍関数はセクション 5.1 で定義されています。そこに記載されているように、アルゴリズムを定義している元の論文のサンプル ベクトルは間違っているようです。以下は、Marc Horowitz と Simon Josefsson によって提供されたテスト ケースの一部です。
64-fold("012345") =
64-fold(303132333435) = be072631276b1955
56-fold("password") =
56-fold(70617373776f7264) = 78a07b6caf85fa
64-fold("Rough Consensus, and Running Code") = 64-fold(526f75676820436f6e73656e7375732c20616e642052756e 6e696e6720436f6465) = bb6ed30870b7f0e0
64-fold("大まかなコンセンサスと実行コード") = 64-fold(526f75676820436f6e73656e7375732c20616e642052756e 6e696e6720436f6465) = bb6ed30870b7f0e0
168-fold("password") =
168-fold(70617373776f7264) =
59e4a8ca7c0385c3c37b3f6d2000247cb6e6bd5b3e
192-fold("MASSACHVSETTS INSTITVTE OF TECHNOLOGY")
192-fold(4d41535341434856534554545320494e5354495456544520
4f4620544543484e4f4c4f4759) =
db3b0d8f0b061e603282b308a50841229ad798fab9540c1b
168-fold("Q") = 168-fold(51) = 518a54a2 15a8452a 518a54a2 15a8452a 518a54a2 15
168 倍("Q") = 168 倍(51) = 518a54a2 15a8452a 518a54a2 15a8452a 518a54a2 15
168-fold("ba") = 168-fold(6261) = fb25d531 ae897449 9f52fd92 ea9857c4 ba24cf29 7e
168 倍 ("ba") = 168 倍 (6261) = fb25d531 ae897449 9f52fd92 ea9857c4 ba24cf29 7e
Here are some additional values corresponding to folded values of the string "kerberos"; the 64-bit form is used in the des3 string-to-key (section 6.3.1).
以下に、文字列「kerberos」の折り畳まれた値に対応する追加の値をいくつか示します。64 ビット形式は des3 string-to-key (セクション 6.3.1) で使用されます。
64-fold("kerberos") = 6b657262 65726f73 128-fold("kerberos") = 6b657262 65726f73 7b9b5b2b 93132b93 168-fold("kerberos") = 8372c236 344e5f15 50cd0747 e15d62ca 7a5a3bce a4 256-fold("kerberos") = 6b657262 65726f73 7b9b5b2b 93132b93 5c9bdcda d95c9899 c4cae4de e6d6cae4
64 倍 ("ケルベロス") = 6b657262 65726f73 128 倍 ("ケルベロス") = 6b657262 65726f73 7b9b5b2b 93132b93 168 倍 ("ケルベロス") = 8372c236 344e5f15 50cd0747 e 15d62ca 7a5a3bce a4 256-fold("kerberos") = 6b657262 65726f737b9b5b2b 93132b93 5c9bdcda d95c9899 c4cae4de e6d6cae4
Note that the initial octets exactly match the input string when the output length is a multiple of the input length.
出力長が入力長の倍数である場合、最初のオクテットは入力文字列と正確に一致することに注意してください。
The function mit_des_string_to_key is defined in section 6.2. We present here several test values, with some of the intermediate results. The fourth test demonstrates the use of UTF-8 with three characters. The last two tests are specifically constructed so as to trigger the weak-key fixups for the intermediate key produced by fan-folding; we have no test cases that cause such fixups for the final key.
関数 mit_des_string_to_key はセクション 6.2 で定義されています。ここでは、いくつかのテスト値といくつかの中間結果を示します。4 番目のテストでは、3 文字を使用した UTF-8 の使用を示します。最後の 2 つのテストは、ファンフォールディングによって生成された中間キーの弱いキーの修正をトリガーするように特別に構築されています。最終キーに対してそのような修正を引き起こすテスト ケースはありません。
UTF-8 encodings used in test vector:
eszett U+00DF C3 9F s-caron U+0161 C5 A1
c-acute U+0107 C4 87 g-clef U+1011E F0 9D 84 9E
Test vector:
テストベクトル:
salt: "ATHENA.MIT.EDUraeburn" 415448454e412e4d49542e4544557261656275726e password: "password" 70617373776f7264 fan-fold result: c01e38688ac86c2e intermediate key: c11f38688ac86d2f DES key: cbc22fae235298e3
ソルト: "ATHENA.MIT.EDUraeburn" 415448454e412e4d49542e4544557261656275726e パスワード: "password" 70617373776f7264 ファンフォールド結果: c01e38688ac86c2e 中間キー: c11f38688ac86d2f DESキー: cbc22fae235298e3
salt: "WHITEHOUSE.GOVdanny" 5748495445484f5553452e474f5664616e6e79 password: "potatoe" 706f7461746f65 fan-fold result: a028944ee63c0416 intermediate key: a129944fe63d0416 DES key: df3d32a74fd92a01
ソルト: "WHITEHOUSE.GOVdanny" 5748495445484f5553452e474f5664616e6e79 パスワード: "potatoe" 706f7461746f65 ファンフォールド結果: a028944ee63c0416 中間キー: a129944fe63d0416 DES キー: df3d32a 74fd92a01
salt: "EXAMPLE.COMpianist" 4558414D504C452E434F4D7069616E697374
password: g-clef (U+1011E) f09d849e
fan-fold result: 3c4a262c18fab090
intermediate key: 3d4a262c19fbb091
DES key: 4ffb26bab0cd9413
salt: "ATHENA.MIT.EDUJuri" + s-caron(U+0161) + "i" + c-acute(U+0107)
415448454e412e4d49542e4544554a757269c5a169c487
password: eszett(U+00DF)
c39f
fan-fold result:b8f6c40e305afc9e
intermediate key: b9f7c40e315bfd9e
DES key: 62c81a5232b5e69d
salt: "AAAAAAAA" 4141414141414141 password: "11119999" 3131313139393939 fan-fold result: e0e0e0e0f0f0f0f0 intermediate key: e0e0e0e0f1f1f101 DES key: 984054d0f1a73e31
ソルト: "AAAAAAAA" 4141414141414141 パスワード: "11119999" 3131313139393939 ファンフォールド結果: e0e0e0e0f0f0f0f0 中間キー: e0e0e0e0f1f1f101 DES キー: 984054d0f1a73e31
salt: "FFFFAAAA" 4646464641414141 password: "NNNN6666" 4e4e4e4e36363636 fan-fold result: 1e1e1e1e0e0e0e0e intermediate key: 1f1f1f1f0e0e0efe DES key: c4bf6b25adf7a4f8
ソルト: "FFFFAAAA" 4646464641414141 パスワード: "NNNN6666" 4e4e4e4e36363636 ファンフォールド結果: 1e1e1e1e0e0e0e0e 中間キー: 1f1f1f1f0e0e0efe DES キー: c4bf6b25adf7a4f8
This trace provided by Simon Josefsson shows the intermediate processing stages of one of the test inputs:
Simon Josefsson によって提供されたこのトレースは、テスト入力の 1 つの中間処理段階を示しています。
string_to_key (des-cbc-md5, string, salt)
;; string:
;; `password' (length 8 bytes)
;; 70 61 73 73 77 6f 72 64
;; salt:
;; `ATHENA.MIT.EDUraeburn' (length 21 bytes)
;; 41 54 48 45 4e 41 2e 4d 49 54 2e 45 44 55 72 61
;; 65 62 75 72 6e
des_string_to_key (string, salt)
;; String:
;; `password' (length 8 bytes)
;; 70 61 73 73 77 6f 72 64
;; Salt:
;; `ATHENA.MIT.EDUraeburn' (length 21 bytes)
;; 41 54 48 45 4e 41 2e 4d 49 54 2e 45 44 55 72 61
;; 65 62 75 72 6e
odd = 1;
s = string | salt;
tempstring = 0; /* 56-bit string */
pad(s); /* with nulls to 8 byte boundary */
;; s = pad(string|salt):
;; `passwordATHENA.MIT.EDUraeburn\x00\x00\x00'
;; (length 32 bytes)
;; 70 61 73 73 77 6f 72 64 41 54 48 45 4e 41 2e 4d
;; 49 54 2e 45 44 55 72 61 65 62 75 72 6e 00 00 00
for (8byteblock in s) {
;; loop iteration 0
;; 8byteblock:
;; `password' (length 8 bytes)
;; 70 61 73 73 77 6f 72 64
;; 01110000 01100001 01110011 01110011 01110111 01101111
;; 01110010 01100100
56bitstring = removeMSBits(8byteblock);
;; 56bitstring:
;; 1110000 1100001 1110011 1110011 1110111 1101111
;; 1110010 1100100
if (odd == 0) reverse(56bitstring); ;; odd=1
odd = ! odd
tempstring = tempstring XOR 56bitstring;
;; tempstring
;; 1110000 1100001 1110011 1110011 1110111 1101111
;; 1110010 1100100
for (8byteblock in s) {
;; loop iteration 1
;; 8byteblock:
;; `ATHENA.M' (length 8 bytes)
;; 41 54 48 45 4e 41 2e 4d
;; 01000001 01010100 01001000 01000101 01001110 01000001
;; 00101110 01001101
56bitstring = removeMSBits(8byteblock);
;; 56bitstring:
;; 1000001 1010100 1001000 1000101 1001110 1000001
;; 0101110 1001101
if (odd == 0) reverse(56bitstring); ;; odd=0
reverse(56bitstring)
;; 56bitstring after reverse
;; 1011001 0111010 1000001 0111001 1010001 0001001
;; 0010101 1000001
odd = ! odd
tempstring = tempstring XOR 56bitstring;
;; tempstring
;; 0101001 1011011 0110010 1001010 0100110 1100110
;; 1100111 0100101
for (8byteblock in s) {
;; loop iteration 2
;; 8byteblock:
;; `IT.EDUra' (length 8 bytes)
;; 49 54 2e 45 44 55 72 61
;; 01001001 01010100 00101110 01000101 01000100 01010101
;; 01110010 01100001
56bitstring = removeMSBits(8byteblock);
;; 56bitstring:
;; 1001001 1010100 0101110 1000101 1000100 1010101
;; 1110010 1100001
if (odd == 0) reverse(56bitstring); ;; odd=1
odd = ! odd
tempstring = tempstring XOR 56bitstring;
;; tempstring
;; 1100000 0001111 0011100 0001111 1100010 0110011
;; 0010101 1000100
for (8byteblock in s) {
;; loop iteration 3
;; 8byteblock:
;; `eburn\x00\x00\x00' (length 8 bytes)
;; 65 62 75 72 6e 00 00 00
;; 01100101 01100010 01110101 01110010 01101110 00000000
;; 00000000 00000000
56bitstring = removeMSBits(8byteblock);
;; 56bitstring:
;; 1100101 1100010 1110101 1110010 1101110 0000000
;; 0000000 0000000
if (odd == 0) reverse(56bitstring); ;; odd=0
reverse(56bitstring)
;; 56bitstring after reverse
;; 0000000 0000000 0000000 0111011 0100111 1010111
;; 0100011 1010011
odd = ! odd
tempstring = tempstring XOR 56bitstring;
;; tempstring
;; 1100000 0001111 0011100 0110100 1000101 1100100
;; 0110110 0010111
for (8byteblock in s) {
}
;; for loop terminated
tempkey = key_correction(add_parity_bits(tempstring));
;; tempkey
;; `\xc1\x1f8h\x8a\xc8m\x2f' (length 8 bytes)
;; c1 1f 38 68 8a c8 6d 2f
;; 11000001 00011111 00111000 01101000 10001010 11001000
;; 01101101 00101111
key = key_correction(DES-CBC-check(s,tempkey));
;; key
;; `\xcb\xc2\x2f\xae\x23R\x98\xe3' (length 8 bytes)
;; cb c2 2f ae 23 52 98 e3
;; 11001011 11000010 00101111 10101110 00100011 01010010
;; 10011000 11100011
;; string_to_key key:
;; `\xcb\xc2\x2f\xae\x23R\x98\xe3' (length 8 bytes)
;; cb c2 2f ae 23 52 98 e3
These tests show the derived-random and derived-key values for the des3-hmac-sha1-kd encryption scheme, using the DR and DK functions defined in section 6.3.1. The input keys were randomly generated; the usage values are from this specification.
これらのテストは、セクション 6.3.1 で定義された DR および DK 関数を使用した、des3-hmac-sha1-kd 暗号化スキームの導出ランダム値と導出キーの値を示します。入力キーはランダムに生成されました。使用値はこの仕様からのものです。
key: dce06b1f64c857a11c3db57c51899b2cc1791008ce973b92
usage: 0000000155
DR: 935079d14490a75c3093c4a6e8c3b049c71e6ee705
DK: 925179d04591a79b5d3192c4a7e9c289b049c71f6ee604cd
key: 5e13d31c70ef765746578531cb51c15bf11ca82c97cee9f2
usage: 00000001aa
DR: 9f58e5a047d894101c469845d67ae3c5249ed812f2
DK: 9e58e5a146d9942a101c469845d67a20e3c4259ed913f207
key: 98e6fd8a04a4b6859b75a176540b9752bad3ecd610a252bc
usage: 0000000155
DR: 12fff90c773f956d13fc2ca0d0840349dbd39908eb
DK: 13fef80d763e94ec6d13fd2ca1d085070249dad39808eabf
key: 622aec25a2fe2cad7094680b7c64940280084c1a7cec92b5
usage: 00000001aa
DR: f8debf05b097e7dc0603686aca35d91fd9a5516a70
DK: f8dfbf04b097e6d9dc0702686bcb3489d91fd9a4516b703e
key: d3f8298ccb166438dcb9b93ee5a7629286a491f838f802fb
usage: 6b65726265726f73 ("kerberos")
DR: 2270db565d2a3d64cfbfdc5305d4f778a6de42d9da
DK: 2370da575d2a3da864cebfdc5204d56df779a7df43d9da43
key: c1081649ada74362e6a1459d01dfd30d67c2234c940704da
usage: 0000000155
DR: 348056ec98fcc517171d2b4d7a9493af482d999175
DK: 348057ec98fdc48016161c2a4c7a943e92ae492c989175f7
key: 5d154af238f46713155719d55e2f1f790dd661f279a7917c
usage: 00000001aa
DR: a8818bc367dadacbe9a6c84627fb60c294b01215e5
DK: a8808ac267dada3dcbe9a7c84626fbc761c294b01315e5c1
key: 798562e049852f57dc8c343ba17f2ca1d97394efc8adc443
usage: 0000000155
DR: c813f88b3be2b2f75424ce9175fbc8483b88c8713a
DK: c813f88a3be3b334f75425ce9175fbe3c8493b89c8703b49
key: 26dce334b545292f2feab9a8701a89a4b99eb9942cecd016
usage: 00000001aa
DR: f58efc6f83f93e55e695fd252cf8fe59f7d5ba37ec
DK: f48ffd6e83f83e7354e694fd252cf83bfe58f7d5ba37ec5d
These are the keys generated for some of the above input strings for triple-DES with key derivation as defined in section 6.3.1.
これらは、セクション 6.3.1 で定義されているキー導出を使用して、トリプル DES 用の上記の入力文字列の一部に対して生成されたキーです。
salt: "ATHENA.MIT.EDUraeburn"
passwd: "password"
key: 850bb51358548cd05e86768c313e3bfef7511937dcf72c3e
salt: "WHITEHOUSE.GOVdanny"
passwd: "potatoe"
key: dfcd233dd0a43204ea6dc437fb15e061b02979c1f74f377a
salt: "EXAMPLE.COMbuckaroo"
passwd: "penny"
key: 6d2fcdf2d6fbbc3ddcadb5da5710a23489b0d3b69d5d9d4a
salt: "ATHENA.MIT.EDUJuri" + s-caron(U+0161) + "i"
+ c-acute(U+0107)
passwd: eszett(U+00DF)
key: 16d5a40e1ce3bacb61b9dce00470324c831973a7b952feb0
salt: "EXAMPLE.COMpianist"
passwd: g-clef(U+1011E)
key: 85763726585dbc1cce6ec43e1f751f07f1c4cbb098f40b19
Below are modified-CRC32 values for various ASCII and octet strings. Only the printable ASCII characters are checksummed, without a C-style trailing zero-valued octet. The 32-bit modified CRC and the sequence of output bytes as used in Kerberos are shown. (The octet values are separated here to emphasize that they are octet values and not 32-bit numbers, which will be the most convenient form for manipulation in some implementations. The bit and byte order used internally for such a number is irrelevant; the octet sequence generated is what is important.)
以下は、さまざまな ASCII 文字列およびオクテット文字列の Modified-CRC32 値です。印刷可能な ASCII 文字のみがチェックサムされ、C スタイルの末尾にゼロ値のオクテットは付きません。Kerberos で使用される 32 ビット修正 CRC と出力バイトのシーケンスが示されています。(ここでは、オクテット値が 32 ビット数値ではなくオクテット値であることを強調するために区切られています。これは、実装によっては操作に最も便利な形式になります。このような数値に対して内部的に使用されるビット順序とバイト順序は無関係です。オクテット値は、オクテット値です。生成されるシーケンスが重要です。)
mod-crc-32("foo") = 33 bc 32 73
mod-crc-32("test0123456789") = d6 88 3e b8
mod-crc-32("MASSACHVSETTS INSTITVTE OF TECHNOLOGY") = f7 80 41 e3
mod-crc-32(8000) = 4b 98 83 3b
mod-crc-32(0008) = 32 88 db 0e
mod-crc-32(0080) = 20 83 b8 ed
mod-crc-32(80) = 20 83 b8 ed
mod-crc-32(80000000) = 3b b6 59 ed
mod-crc-32(00000001) = 96 30 07 77
B. Significant Changes from RFC 1510
B. RFC 1510 からの重要な変更
The encryption and checksum mechanism profiles are new. The old specification defined a few operations for various mechanisms but didn't outline what abstract properties should be required of new mechanisms, or how to ensure that a mechanism specification is complete enough for interoperability between implementations. The new profiles differ from the old specification in a few ways:
暗号化およびチェックサム メカニズムのプロファイルは新しいものです。古い仕様では、さまざまなメカニズムに対していくつかの操作が定義されていましたが、新しいメカニズムにどのような抽象プロパティが必要であるか、実装間の相互運用性のためにメカニズムの仕様が十分に完全であることを確認する方法については概説されていませんでした。新しいプロファイルは、いくつかの点で古い仕様と異なります。
Some message definitions in [Kerb1510] could be read as permitting the initial vector to be specified by the application; the text was too vague. It is explicitly not permitted in this specification. Some encryption algorithms may not use initialization vectors, so relying on chosen, secret initialization vectors for security is unwise. Also, the prepended confounder in the existing algorithms is roughly equivalent to a per-message initialization vector that is revealed in encrypted form. However, carrying state across from one encryption to another is explicitly permitted through the opaque "cipher state" object.
[Kerb1510] の一部のメッセージ定義は、アプリケーションによる初期ベクトルの指定を許可していると解釈される可能性があります。文章が曖昧すぎた。この仕様では明示的に許可されていません。一部の暗号化アルゴリズムは初期化ベクトルを使用しない場合があるため、セキュリティのために選択された秘密の初期化ベクトルに依存するのは賢明ではありません。また、既存のアルゴリズムの先頭に追加された交絡因子は、暗号化された形式で公開されるメッセージごとの初期化ベクトルとほぼ同等です。ただし、ある暗号化から別の暗号化に状態を引き継ぐことは、不透明な「暗号状態」オブジェクトを通じて明示的に許可されています。
The use of key derivation is new.
キー導出の使用は新しいものです。
Several new methods are introduced, including generation of a key in wire-protocol format from random input data.
ランダムな入力データからワイヤ プロトコル形式でキーを生成するなど、いくつかの新しい方法が導入されています。
The means for influencing the string-to-key algorithm are laid out more clearly.
文字列からキーへのアルゴリズムに影響を与える手段がより明確にレイアウトされています。
Triple-DES support is new.
Triple-DES のサポートは新しいものです。
The pseudo-random function is new.
擬似ランダム機能は新しい機能です。
The des-cbc-crc, DES string-to-key and CRC descriptions have been updated to align them with existing implementations.
des-cbc-crc、DES string-to-key、および CRC の説明は、既存の実装に合わせて更新されました。
[Kerb1510] did not indicate what character set or encoding might be used for pass phrases and salts.
[Kerb1510] は、パスフレーズとソルトにどのような文字セットまたはエンコーディングが使用されるかを示していません。
In [Kerb1510], key types, encryption algorithms, and checksum algorithms were only loosely associated, and the association was not well described. In this specification, key types and encryption algorithms have a one-to-one correspondence, and associations between encryption and checksum algorithms are described so that checksums can be computed given negotiated keys, without requiring further negotiation for checksum types.
[Kerb1510] では、鍵タイプ、暗号化アルゴリズム、およびチェックサム アルゴリズムは大まかに関連付けられているだけであり、その関連付けは十分に記述されていませんでした。この仕様では、キーのタイプと暗号化アルゴリズムは 1 対 1 の対応関係にあり、チェックサムのタイプについてさらにネゴシエーションする必要なく、ネゴシエートされたキーを指定してチェックサムを計算できるように、暗号化アルゴリズムとチェックサム アルゴリズムの間の関連付けが説明されています。
Notes
ノート
[1] Although Message Authentication Code (MAC) or Message Integrity Check (MIC) would be more appropriate terms for many of the uses in this document, we continue to use the term checksum for historical reasons.
[1] このドキュメントで使用される多くの場合、メッセージ認証コード (MAC) またはメッセージ整合性チェック (MIC) の方が適切な用語ですが、歴史的な理由から、チェックサムという用語を引き続き使用します。
[2] Extending CBC mode across messages would be one obvious example of this chaining. Another might be the use of counter mode, with a counter randomly initialized and attached to the ciphertext; a second message could continue incrementing the counter when chaining the cipher state, thus avoiding having to transmit another counter value. However, this chaining is only useful for uninterrupted, ordered sequences of messages.
[2] CBC モードをメッセージ全体に拡張することは、この連鎖の明らかな例の 1 つです。もう 1 つは、カウンターをランダムに初期化し、暗号文に付加するカウンター モードの使用です。2 番目のメッセージは、暗号状態を連鎖するときにカウンタをインクリメントし続けることができるため、別のカウンタ値を送信する必要がなくなります。ただし、この連鎖は、中断のない、順序付けられたメッセージのシーケンスにのみ役立ちます。
[3] In the case of Kerberos, the encrypted objects will generally be ASN.1 DER encodings, which contain indications of their length in the first few octets.
[3] Kerberos の場合、暗号化されたオブジェクトは通常 ASN.1 DER エンコーディングであり、最初の数オクテットにオブジェクトの長さの指示が含まれます。
[4] As of the time of this writing, new modes of operation have been proposed, some of which may permit encryption and integrity protection simultaneously. After some of these proposals have been subjected to adequate analysis, we may wish to formulate a new simplified profile based on one of them.
[4] この記事の執筆時点では、新しい動作モードが提案されており、その中には暗号化と完全性保護を同時に許可するものもあります。これらの提案のいくつかが適切な分析を受けた後、そのうちの 1 つに基づいて新しい簡略化されたプロファイルを策定したい場合があります。
[5] It should be noted that the sample vector in appendix B.2 of the original paper appears to be incorrect. Two independent implementations from the specification (one in C by Marc Horowitz, and another in Scheme by Bill Sommerfeld) agree on a value different from that in [Blumenthal96].
[5] 元の論文の付録 B.2 のサンプル ベクトルが間違っているように見えることに注意してください。仕様からの 2 つの独立した実装 (1 つは Marc Horowitz による C で、もう 1 つは Bill Sommerfeld による Scheme) は、[Blumenthal96] の値とは異なる値で一致しています。
[6] For example, in MIT's implementation of [Kerb1510], the rsa-md5 unkeyed checksum of application data may be included in an authenticator encrypted in a service's key.
[6] たとえば、MIT の [Kerb1510] の実装では、アプリケーション データの rsa-md5 鍵なしチェックサムが、サービスの鍵で暗号化された認証子に含まれる可能性があります。
[7] Using a variant of the key limits the use of a key to a particular function, separating the functions of generating a checksum from other encryption performed using the session key. The constant 0xF0F0F0F0F0F0F0F0 was chosen because it maintains key parity. The properties of DES precluded the use of the complement. The same constant is used for similar purpose in the Message Integrity Check in the Privacy Enhanced Mail standard.
[7] キーのバリアントを使用すると、キーの使用が特定の機能に制限され、チェックサムを生成する機能がセッション キーを使用して実行される他の暗号化から分離されます。定数 0xF0F0F0F0F0F0F0F0 が選択されたのは、キー パリティを維持するためです。DES の特性により、補体の使用は不可能でした。同じ定数が、Privacy Enhanced Mail 標準のメッセージ整合性チェックでも同様の目的で使用されます。
[8] Perhaps one of the more common reasons for directly performing encryption is direct control over the negotiation and to select a "sufficiently strong" encryption algorithm (whatever that means in the context of a given application). Although Kerberos directly provides no direct facility for negotiating encryption types between the application client and server, there are other means to accomplish similar goals (for example, requesting only "strong" session key types from the KDC, and assuming that the type actually returned by the KDC will be understood and supported by the application server).
[8] おそらく、暗号化を直接実行する最も一般的な理由の 1 つは、ネゴシエーションを直接制御し、「十分に強力な」暗号化アルゴリズム (特定のアプリケーションのコンテキストで意味するものは何でも) を選択するためです。Kerberos には、アプリケーションのクライアントとサーバーの間で暗号化タイプをネゴシエートするための直接的な機能はありませんが、同様の目的を達成する他の手段があります (たとえば、「強力な」セッション キー タイプのみを KDC から要求し、そのタイプが実際に KDC によって返されたものと想定するなど)。KDC はアプリケーション サーバーによって理解され、サポートされます)。
Normative References
引用文献
[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[BCP26] Narten, T. および H. Alvestruct、「RFC で IANA 考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998 年 10 月。
[Bellare98] Bellare, M., Desai, A., Pointcheval, D., and P. Rogaway, "Relations Among Notions of Security for Public-Key Encryption Schemes". Extended abstract published in Advances in Cryptology-Crypto 98 Proceedings, Lecture Notes in Computer Science Vol. 1462, H. Krawcyzk ed., Springer-Verlag, 1998.
[Bellare98] Bellare, M.、Desai, A.、Pointcheval, D.、および P. Rogaiy、「公開鍵暗号化スキームのセキュリティ概念間の関係」。Advances in Cryptology-Crypto 98 Proceedings、Lecture Notes in Computer Science Vol. 2 に掲載された拡張要約。1462、H. Krawcyzk 編、Springer-Verlag、1998 年。
[Blumenthal96] Blumenthal, U. and S. Bellovin, "A Better Key Schedule for DES-Like Ciphers", Proceedings of PRAGOCRYPT '96, 1996.
[Blumenthal96] Blumenthal、U. および S. Bellovin、「DES のような暗号のためのより良い鍵スケジュール」、PRAGOCRYPT '96 の議事録、1996 年。
[CRC] International Organization for Standardization, "ISO Information Processing Systems - Data Communication - High-Level Data Link Control Procedure - Frame Structure," IS 3309, 3rd Edition, October 1984.
[CRC] 国際標準化機構、「ISO 情報処理システム - データ通信 - 高レベル データ リンク制御手順 - フレーム構造」、IS 3309、第 3 版、1984 年 10 月。
[DES77] National Bureau of Standards, U.S. Department of Commerce, "Data Encryption Standard," Federal Information Processing Standards Publication 46, Washington, DC, 1977.
[DES77] 米国商務省国家標準局、「データ暗号化標準」、連邦情報処理標準出版物 46、ワシントン DC、1977 年。
[DESI81] National Bureau of Standards, U.S. Department of Commerce, "Guidelines for implementing and using NBS Data Encryption Standard," Federal Information Processing Standards Publication 74, Washington, DC, 1981.
[DESI81] 米国商務省国家標準局、「NBS データ暗号化標準の実装と使用に関するガイドライン」、連邦情報処理標準出版物 74、ワシントン DC、1981 年。
[DESM80] National Bureau of Standards, U.S. Department of Commerce, "DES Modes of Operation," Federal Information Processing Standards Publication 81, Springfield, VA, December 1980.
[DESM80] 米国商務省国家標準局、「DES Modes of Operation」、連邦情報処理標準出版物 81、バージニア州スプリングフィールド、1980 年 12 月。
[Dolev91] Dolev, D., Dwork, C., and M. Naor, "Non-malleable cryptography", Proceedings of the 23rd Annual Symposium on Theory of Computing, ACM, 1991.
[Dolev91] Dolev, D.、Dwork, C.、および M. Naor、「Non-malleable cryptography」、第 23 回コンピューティング理論に関する年次シンポジウム議事録、ACM、1991 年。
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HMAC] Krawczyk, H.、Bellare, M.、および R. Canetti、「HMAC: Keyed-Hashing for Message Authentication」、RFC 2104、1997 年 2 月。
[KRB5-AES] Raeburn, K., "Advanced Encryption Standard (AES) Encryption for Kerberos 5", RFC 3962, February 2005.
[KRB5-AES] Raeburn, K.、「Kerberos 5 の Advanced Encryption Standard (AES) 暗号化」、RFC 3962、2005 年 2 月。
[MD4-92] Rivest, R., "The MD4 Message-Digest Algorithm", RFC 1320, April 1992.
[MD4-92] Rivest、R.、「MD4 メッセージ ダイジェスト アルゴリズム」、RFC 1320、1992 年 4 月。
[MD5-92] Rivest, R., "The MD5 Message-Digest Algorithm ", RFC 1321, April 1992.
[MD5-92] Rivest、R.、「MD5 メッセージ ダイジェスト アルゴリズム」、RFC 1321、1992 年 4 月。
[SG92] Stubblebine, S. and V. D. Gligor, "On Message Integrity in Cryptographic Protocols," in Proceedings of the IEEE Symposium on Research in Security and Privacy, Oakland, California, May 1992.
[SG92] Stubblebine, S. および V. D. Gligor、「暗号プロトコルにおけるメッセージの整合性について」、セキュリティとプライバシーの研究に関する IEEE シンポジウム議事録、カリフォルニア州オークランド、1992 年 5 月。
Informative References
参考引用
[Bellovin91] Bellovin, S. M. and M. Merrit, "Limitations of the Kerberos Authentication System", in Proceedings of the Winter 1991 Usenix Security Conference, January, 1991.
[Bellovin91] Bellovin、S.M. および M. Merrit、「Kerberos 認証システムの制限」、1991 年冬季 Usenix セキュリティ カンファレンスの議事録、1991 年 1 月。
[Bellovin99] Bellovin, S. M. and D. Atkins, private communications, 1999.
[Bellovin99] Bellovin、S.M. および D. Atkins、私信、1999 年。
[EFF-DES] Electronic Frontier Foundation, "Cracking DES: Secrets of Encryption Research, Wiretap Politics, and Chip Design", O'Reilly & Associates, Inc., May 1998.
[EFF-DES] 電子フロンティア財団、「DES のクラッキング: 暗号化研究、盗聴政治、チップ設計の秘密」、O'Reilly & Associates, Inc.、1998 年 5 月。
[ESP-DES] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998.
[ESP-DES] Madson, C. および N. Doraswamy、「明示的 IV を使用した ESP DES-CBC 暗号アルゴリズム」、RFC 2405、1998 年 11 月。
[GSS-KRB5] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996.
[GSS-KRB5] Linn, J.、「Kerberos バージョン 5 GSS-API メカニズム」、RFC 1964、1996 年 6 月。
[HMAC-TEST] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1", RFC 2202, September 1997.
[HMAC-TEST] Cheng、P.、および R. Glenn、「HMAC-MD5 および HMAC-SHA-1 のテスト ケース」、RFC 2202、1997 年 9 月。
[IPSEC-HMAC] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[IPSEC-HMAC] Madson, C. および R. Glenn、「ESP および AH 内での HMAC-SHA-1-96 の使用」、RFC 2404、1998 年 11 月。
[Kerb] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", Work in Progress, September 2004.
[Kerb] Neuman, C.、Yu, T.、Hartman, S.、および K. Raeburn、「The Kerberos Network Authentication Service (V5)」、進行中の作業、2004 年 9 月。
[Kerb1510] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[Kerb1510] Kohl、J.、および C. Neuman、「Kerberos ネットワーク認証サービス (V5)」、RFC 1510、1993 年 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 月。
[RFC1851] Karn, P., Metzger, P., and W. Simpson, "The ESP Triple DES Transform", RFC 1851, September 1995.
[RFC1851] Karn, P.、Metzger, P.、および W. Simpson、「ESP Triple DES Transform」、RFC 1851、1995 年 9 月。
[Schneier96] Schneier, B., "Applied Cryptography Second Edition", John Wiley & Sons, New York, NY, 1996. ISBN 0-471- 12845-7.
[Schneier96] Schneier, B.、『応用暗号第 2 版』、John Wiley & Sons、ニューヨーク州ニューヨーク、1996 年。ISBN 0-471-12845-7。
Editor'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 エディター機能の資金は現在、インターネット協会によって提供されています。