Network Working Group P. Karn
Request for Comments: 2523 Qualcomm
Category: Experimental W. Simpson
DayDreamer
March 1999
Photuris: Extended Schemes and Attributes
Status of this Memo
このメモの位置付け
This document defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). Copyright (C) Philip Karn and William Allen Simpson (1994-1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。著作権（C）フィリップ・カーンとウィリアムアレンシンプソン（1994年から1999年）。全著作権所有。
Abstract
抽象
Photuris is a session-key management protocol. Extensible Exchange-Schemes are provided to enable future implementation changes without affecting the basic protocol.
Photurisは、セッション鍵管理プロトコルです。拡張可能な交換・スキームは、基本的なプロトコルに影響を与えることなく、将来の実装の変更を可能にするために提供されています。
Additional authentication attributes are included for use with the IP Authentication Header (AH) or the IP Encapsulating Security Protocol (ESP).
追加の認証属性は、IP認証ヘッダ（AH）またはIPカプセル化セキュリティプロトコル（ESP）で使用するために含まれています。
Additional confidentiality attributes are included for use with ESP.
追加の機密性の属性は、ESPで使用するために含まれています。
Table of Contents
目次
1. Additional Exchange-Schemes ........................... 1
2. Additional Key-Generation-Function .................... 5
2.1 SHA1 Hash ....................................... 5
3. Additional Privacy-Methods ............................ 5
3.1 DES-CBC over Mask ............................... 5
3.2 DES-EDE3-CBC over Mask .......................... 6
4. Additional Validity-Method ............................ 6
4.1 SHA1-IPMAC Check ................................ 6
5. Additional Attributes ................................. 7
5.1 SHA1-IPMAC ...................................... 7
5.1.1 Symmetric Identification ........................ 8
5.1.2 Authentication .................................. 9
5.2 RIPEMD-160-IPMAC ................................ 9
5.2.1 Symmetric Identification ........................ 10
5.2.2 Authentication .................................. 11
5.3 DES-CBC ......................................... 11
5.4 Invert (Decryption/Encryption) .................. 12
5.5 XOR Whitening ................................... 13
APPENDICES ................................................... 15
A. Exchange-Scheme Selection ............................. 15
A.1 Responder ....................................... 15
A.2 Initiator ....................................... 15
SECURITY CONSIDERATIONS ...................................... 16
ACKNOWLEDGEMENTS ............................................. 16
REFERENCES ................................................... 17
CONTACTS ..................................................... 18
COPYRIGHT .................................................... 19
The packet format and basic facilities are already defined for Photuris [RFC-2522].
パケットフォーマットと基本施設は既にPhoturis [RFC-2522]のために定義されています。
These optional Exchange-Schemes are specified separately, and no single implementation is expected to support all of them.
これらのオプションの取引所・スキームは、個別に指定され、単一の実装はそれらのすべてをサポートすることが期待されていません。
This document defines the following values:
このドキュメントでは、次の値を定義します。
(3) Implementation Optional. Any modulus (p) with a recommended generator (g) of 3. When the Exchange-Scheme Size is non-zero, the modulus is contained in the Exchange-Scheme Value field in the list of Offered-Schemes.
（3）実装オプション。交換-スキームサイズがゼロで3の推奨発電機（G）を有する任意の弾性率（P）は、弾性率は、提供・スキームのリストでExchange-スキーム値フィールドに含まれています。
An Exchange-Scheme Size of zero is invalid.
ゼロの交換・スキームサイズが無効です。
Key-Generation-Function "MD5 Hash" Privacy-Method "Simple Masking" Validity-Method "MD5-IPMAC Check"
鍵生成・機能「MD5ハッシュ」プライバシー・メソッド「シンプルマスキング」妥当性-方法「MD5-IPMACチェック」
This combination of features requires a modulus with at least 64-bits of cryptographic strength.
特徴のこの組合せは、暗号強度の少なくとも64ビットの係数を必要とします。
(4) Implementation Optional. Any modulus (p) with a recommended generator (g) of 2. When the Exchange-Scheme Size is non-zero, the modulus is contained in the Exchange-Scheme Value field in the list of Offered-Schemes.
（4）実装オプション。交換-スキームサイズがゼロでない2の推奨発電機（G）を有する任意の弾性率（P）は、弾性率は、提供・スキームのリストでExchange-スキーム値フィールドに含まれています。
When the Exchange-Scheme Size field is zero, includes by
reference all of the moduli specified in the list of Offered-
Schemes for Scheme #2.
Key-Generation-Function "MD5 Hash" Privacy-Method "DES-CBC over Mask" Validity-Method "MD5-IPMAC Check"
鍵生成・機能「MD5ハッシュ」プライバシー・メソッド「DES-CBCマスクの上に」妥当性-方法「MD5-IPMACチェック」
This combination of features requires a modulus with at least 64-bits of cryptographic strength.
特徴のこの組合せは、暗号強度の少なくとも64ビットの係数を必要とします。
(5) Implementation Optional. Any modulus (p) with a recommended generator (g) of 5. When the Exchange-Scheme Size is non-zero, the modulus is contained in the Exchange-Scheme Value field in the list of Offered-Schemes.
（5）実装オプション。交換-スキームサイズがゼロで5推奨ジェネレータ（G）を有する任意の弾性率（P）は、弾性率は、提供・スキームのリストでExchange-スキーム値フィールドに含まれています。
An Exchange-Scheme Size of zero is invalid.
ゼロの交換・スキームサイズが無効です。
Key-Generation-Function "MD5 Hash" Privacy-Method "Simple Masking" Validity-Method "MD5-IPMAC Check"
鍵生成・機能「MD5ハッシュ」プライバシー・メソッド「シンプルマスキング」妥当性-方法「MD5-IPMACチェック」
This combination of features requires a modulus with at least 64-bits of cryptographic strength.
特徴のこの組合せは、暗号強度の少なくとも64ビットの係数を必要とします。
(6) Implementation Optional. Any modulus (p) with a recommended generator (g) of 3. When the Exchange-Scheme Size is non-zero, the modulus is contained in the Exchange-Scheme Value field in the list of Offered-Schemes.
（6）実装オプション。交換-スキームサイズがゼロで3の推奨発電機（G）を有する任意の弾性率（P）は、弾性率は、提供・スキームのリストでExchange-スキーム値フィールドに含まれています。
When the Exchange-Scheme Size field is zero, includes by
reference all of the moduli specified in the list of Offered-
Schemes for Scheme #3.
Key-Generation-Function "MD5 Hash" Privacy-Method "DES-CBC over Mask" Validity-Method "MD5-IPMAC Check"
鍵生成・機能「MD5ハッシュ」プライバシー・メソッド「DES-CBCマスクの上に」妥当性-方法「MD5-IPMACチェック」
This combination of features requires a modulus with at least 64-bits of cryptographic strength.
特徴のこの組合せは、暗号強度の少なくとも64ビットの係数を必要とします。
(7) Implementation Optional. Any modulus (p) with a variable generator (g). When the Exchange-Scheme Size is non-zero, the pair [g,p] is contained in the Exchange-Scheme Value field in the list of Offered-Schemes. Each is encoded in a separate Variable Precision Integer (VPI). The generator VPI is followed by (concatenated to) the modulus VPI, and the result is nested inside the Exchange-Scheme Value field.
（7）実装オプション。可変ジェネレータ（G）を有する任意の弾性率（P）。交換-スキームサイズがゼロである場合、ペア[G、P]は提供さ-スキームのリストでExchange-スキーム値フィールドに含まれています。それぞれが別々の可変精度整数（VPI）で符号化されます。ジェネレータVPIはモジュラスVPI（に連結）が続き、その結果は、Exchange-スキームValueフィールド内にネストされています。
An Exchange-Scheme Size of zero is invalid.
ゼロの交換・スキームサイズが無効です。
Key-Generation-Function "MD5 Hash" Privacy-Method "Simple Masking" Validity-Method "MD5-IPMAC Check"
鍵生成・機能「MD5ハッシュ」プライバシー・メソッド「シンプルマスキング」妥当性-方法「MD5-IPMACチェック」
This combination of features requires a modulus with at least 64-bits of cryptographic strength.
特徴のこの組合せは、暗号強度の少なくとも64ビットの係数を必要とします。
When more than one modulus is specified for a given kind of Scheme, the Size of the modulus MUST be unique, independent of the Size of the generator.
複数の弾性係数は、スキームの特定の種類を指定した場合、モジュラスのサイズは、発電機のサイズとは無関係に、ユニークでなければなりません。
(8) Implementation Optional. Any modulus (p) with a recommended generator (g) of 2. When the Exchange-Scheme Size is non-zero, the modulus is contained in the Exchange-Scheme Value field in the list of Offered-Schemes.
（8）実装オプション。交換-スキームサイズがゼロでない2の推奨発電機（G）を有する任意の弾性率（P）は、弾性率は、提供・スキームのリストでExchange-スキーム値フィールドに含まれています。
When the Exchange-Scheme Size field is zero, includes by
reference all of the moduli specified in the list of Offered-
Schemes for Schemes #2 and #4.
Key-Generation-Function "SHA1 Hash" Privacy-Method "DES-EDE3-CBC over Mask" Validity-Method "SHA1-IPMAC Check"
鍵生成・機能 "SHA1ハッシュ" プライバシー・メソッド "DES-EDE3-CBCマスクの上に" 妥当性-方法 "SHA1-IPMACチェック"
This combination of features requires a modulus with at least 112-bits of cryptographic strength.
特徴のこの組合せは、暗号強度の少なくとも112ビットの係数を必要とします。
(10) Implementation Optional. Any modulus (p) with a recommended generator (g) of 5. When the Exchange-Scheme Size is non-zero, the modulus is contained in the Exchange-Scheme Value field in the list of Offered-Schemes.
オプション（10）実装。交換-スキームサイズがゼロで5推奨ジェネレータ（G）を有する任意の弾性率（P）は、弾性率は、提供・スキームのリストでExchange-スキーム値フィールドに含まれています。
When the Exchange-Scheme Size field is zero, includes by
reference all of the moduli specified in the list of Offered-
Schemes for Scheme #5.
Key-Generation-Function "MD5 Hash" Privacy-Method "DES-CBC over Mask" Validity-Method "MD5-IPMAC Check"
鍵生成・機能「MD5ハッシュ」プライバシー・メソッド「DES-CBCマスクの上に」妥当性-方法「MD5-IPMACチェック」
This combination of features requires a modulus with at least 64-bits of cryptographic strength.
特徴のこの組合せは、暗号強度の少なくとも64ビットの係数を必要とします。
(12) Implementation Optional. Any modulus (p) with a recommended generator (g) of 3. When the Exchange-Scheme Size is non-zero, the modulus is contained in the Exchange-Scheme Value field in the list of Offered-Schemes.
オプション（12）実装。交換-スキームサイズがゼロで3の推奨発電機（G）を有する任意の弾性率（P）は、弾性率は、提供・スキームのリストでExchange-スキーム値フィールドに含まれています。
When the Exchange-Scheme Size field is zero, includes by
reference all of the moduli specified in the list of Offered-
Schemes for Schemes #3 and #6.
Key-Generation-Function "SHA1 Hash" Privacy-Method "DES-EDE3-CBC over Mask" Validity-Method "SHA1-IPMAC Check"
鍵生成・機能 "SHA1ハッシュ" プライバシー・メソッド "DES-EDE3-CBCマスクの上に" 妥当性-方法 "SHA1-IPMACチェック"
This combination of features requires a modulus with at least 112-bits of cryptographic strength.
特徴のこの組合せは、暗号強度の少なくとも112ビットの係数を必要とします。
(14) Implementation Optional. Any modulus (p) with a variable generator (g). When the Exchange-Scheme Size is non-zero, the pair [g,p] is contained in the Exchange-Scheme Value field in the list of Offered-Schemes. Each is encoded in a separate Variable Precision Integer (VPI). The generator VPI is followed by (concatenated to) the modulus VPI, and the result is nested inside the Exchange-Scheme Value field.
オプション（14）実装。可変ジェネレータ（G）を有する任意の弾性率（P）。交換-スキームサイズがゼロである場合、ペア[G、P]は提供さ-スキームのリストでExchange-スキーム値フィールドに含まれています。それぞれが別々の可変精度整数（VPI）で符号化されます。ジェネレータVPIはモジュラスVPI（に連結）が続き、その結果は、Exchange-スキームValueフィールド内にネストされています。
When the Exchange-Scheme Size field is zero, includes by
reference all of the moduli specified in the list of Offered-
Schemes for Scheme #7.
Key-Generation-Function "MD5 Hash" Privacy-Method "DES-CBC over Mask" Validity-Method "MD5-IPMAC Check"
鍵生成・機能「MD5ハッシュ」プライバシー・メソッド「DES-CBCマスクの上に」妥当性-方法「MD5-IPMACチェック」
This combination of features requires a modulus with at least 64-bits of cryptographic strength.
特徴のこの組合せは、暗号強度の少なくとも64ビットの係数を必要とします。
When more than one modulus is specified for a given kind of Scheme, the Size of the modulus MUST be unique, independent of the Size of the generator.
複数の弾性係数は、スキームの特定の種類を指定した場合、モジュラスのサイズは、発電機のサイズとは無関係に、ユニークでなければなりません。
(20) Implementation Optional. Any modulus (p) with a recommended generator (g) of 5. When the Exchange-Scheme Size is non-zero, the modulus is contained in the Exchange-Scheme Value field in the list of Offered-Schemes.
オプション（20）実装。交換-スキームサイズがゼロで5推奨ジェネレータ（G）を有する任意の弾性率（P）は、弾性率は、提供・スキームのリストでExchange-スキーム値フィールドに含まれています。
When the Exchange-Scheme Size field is zero, includes by
reference all of the moduli specified in the list of Offered-
Schemes for Schemes #5 and #10.
Key-Generation-Function "SHA1 Hash" Privacy-Method "DES-EDE3-CBC over Mask" Validity-Method "SHA1-IPMAC Check"
鍵生成・機能 "SHA1ハッシュ" プライバシー・メソッド "DES-EDE3-CBCマスクの上に" 妥当性-方法 "SHA1-IPMACチェック"
This combination of features requires a modulus with at least 112-bits of cryptographic strength.
特徴のこの組合せは、暗号強度の少なくとも112ビットの係数を必要とします。
(28) Implementation Optional. Any modulus (p) with a variable generator (g). When the Exchange-Scheme Size is non-zero, the pair [g,p] is contained in the Exchange-Scheme Value field in the list of Offered-Schemes. Each is encoded in a separate Variable Precision Integer (VPI). The generator VPI is followed by (concatenated to) the modulus VPI, and the result is nested inside the Exchange-Scheme Value field.
オプション（28）実装。可変ジェネレータ（G）を有する任意の弾性率（P）。交換-スキームサイズがゼロである場合、ペア[G、P]は提供さ-スキームのリストでExchange-スキーム値フィールドに含まれています。それぞれが別々の可変精度整数（VPI）で符号化されます。ジェネレータVPIはモジュラスVPI（に連結）が続き、その結果は、Exchange-スキームValueフィールド内にネストされています。
When the Exchange-Scheme Size field is zero, includes by
reference all of the moduli specified in the list of Offered-
Schemes for Schemes #7 and #14.
Key-Generation-Function "SHA1 Hash" Privacy-Method "DES-EDE3-CBC over Mask" Validity-Method "SHA1-IPMAC Check"
鍵生成・機能 "SHA1ハッシュ" プライバシー・メソッド "DES-EDE3-CBCマスクの上に" 妥当性-方法 "SHA1-IPMACチェック"
This combination of features requires a modulus with at least 112-bits of cryptographic strength.
特徴のこの組合せは、暗号強度の少なくとも112ビットの係数を必要とします。
When more than one modulus is specified for a given kind of Scheme, the Size of the modulus MUST be unique, independent of the Size of the generator.
複数の弾性係数は、スキームの特定の種類を指定した場合、モジュラスのサイズは、発電機のサイズとは無関係に、ユニークでなければなりません。
2. Additional Key-Generation-Function 2.1. SHA1 Hash
2.追加の鍵生成・機能2.1。 SHA1ハッシュ
SHA1 [FIPS-180-1] is used as a pseudo-random-function for generating the key(s). The key(s) begin with the most significant bits of the hash. SHA1 is iterated as needed to generate the requisite length of key material.
SHA1 [FIPS-180-1]キー（S）を生成する擬似ランダム関数として使用されます。キー（複数可）、ハッシュの最上位ビットで始まります。キーマテリアルの必要な長さを生成するために、必要に応じてSHA1が繰り返されます。
When an individual key does not use all 160-bits of the last hash, any remaining unused (least significant) bits of the last hash are discarded. When combined with other uses of key generation for the same purpose, the next key will begin with a new hash iteration.
個々のキーが最後のハッシュの全160ビットを使用しない場合、最後のハッシュの任意の残りの未使用の（最下位）ビットが破棄されます。同じ目的のために鍵生成の他の用途と組み合わせると、次のキーは、新しいハッシュの繰り返しで始まります。
3. Additional Privacy-Methods 3.1. DES-CBC over Mask
3.追加のプライバシー・メソッド3.1。マスク上DES-CBC
As described in [RFC-2522] "Privacy-Key Computation", sufficient privacy-key material is generated to match the message length, beginning with the next field after the SPI, and including the Padding. The message is masked by XOR with the privacy-key.
[RFC-2522]「プライバシーキー計算」で説明したように、十分なプライバシーキー材料はSPIの後に次のフィールドで始まり、およびパディングを含む、メッセージの長さに一致するように生成されます。メッセージはプライバシーキーでXORによってマスクされます。
Then, the Key-Generation-Function is iterated to generate a DES key. The most significant 64-bits (8 bytes) of the generated hash are used for the privacy-key, and the remainder are discarded. Although extremely rare, the 64 weak, semi-weak, and possibly weak keys [Schneier95, pages 280-282] are discarded. The Key-Generation-Function is iterated until a valid key is obtained.
その後、鍵生成-機能は、DES鍵を生成するために繰り返されます。生成されたハッシュの最上位64ビット（8バイト）プライバシーキーのために使用され、残りは破棄されます。非常に稀が、64、弱半弱、およびおそらく弱いキー[Schneier95、ページ280~282]は廃棄されます。有効なキーが得られるまで、鍵生成・機能が繰り返されます。
The least significant bit of each key byte is ignored (or set to parity when the implementation requires).
各キーのバイトの最下位ビットは無視（または実装が必要とする時、パリティに設定）されます。
The 64-bit CBC IV is zero. Message encryption begins with the next field after the SPI, and continues to the end of the data indicated by the UDP Length.
64ビットのCBC IVはゼロです。メッセージの暗号化は、SPIの後に次のフィールドで始まり、およびUDPの長さによって示されたデータの最後まで続きます。
This is "Triple DES" outer-CBC EDE encryption (and DED decryption) with three 56-bit keys [KR96].
これは、3つの56ビットキー[KR96]と「トリプルDES」外CBC EDE暗号化（および復号DED）です。
As described in [RFC-2522] "Privacy-Key Computation", sufficient privacy-key material is generated to match the message length, beginning with the next field after the SPI, and including the Padding. The message is masked by XOR with the privacy-key.
[RFC-2522]「プライバシーキー計算」で説明したように、十分なプライバシーキー材料はSPIの後に次のフィールドで始まり、およびパディングを含む、メッセージの長さに一致するように生成されます。メッセージはプライバシーキーでXORによってマスクされます。
Then, the Key-Generation-Function is iterated (at least) three times to generate the three DES keys. The most significant 64-bits (8 bytes) of each generated hash are used for each successive privacy-key, and the remainder are discarded. Each key is examined sequentially, in the order used for encryption. A key that is identical to a previous key MUST be discarded. Although extremely rare, the 64 weak, semi-weak, and possibly weak keys [Schneier95, pages 280-282] MUST be discarded. The Key-Generation-Function is iterated until a valid key is obtained before generating the next key.
その後、鍵生成-機能は3つのDES鍵を生成するために、（少なくとも）3回繰り返されます。各生成されたハッシュの最上位64ビット（8バイト）は、各連続プライバシーキーのために使用され、残りは破棄されます。各キーは暗号化に使用されるためには、順次検討しています。前のキーと同じです鍵は捨てなければなりません。非常に稀が、64、弱半弱、およびおそらく弱いキー[Schneier95、ページ280~282]は捨てなければなりません。有効なキーは次のキーを生成する前に得られるまで、鍵生成・機能が繰り返されます。
In all three keys, the least significant bit of each key byte is ignored (or set to parity when the implementation requires).
すべての3つのキーでは、各キーのバイトの最下位ビットは無視されます（または、実装が必要とする時、パリティに設定します）。
The 64-bit CBC IV is zero. Message encryption begins with the next field after the SPI, and continues to the end of the data indicated by the UDP Length.
64ビットのCBC IVはゼロです。メッセージの暗号化は、SPIの後に次のフィールドで始まり、およびUDPの長さによって示されたデータの最後まで続きます。
4. Additional Validity-Method 4.1. SHA1-IPMAC Check
4.追加の妥当性 - 方法4.1。 SHA1-IPMACチェック
As described in [RFC-2522] "Validity Verification", the Verification field value is the SHA1 [FIPS-180-1] hash over the concatenation of
[RFC-2522]「妥当性検証」に記載されているように、検証フィールドの値は、連結上SHA1 [FIPS-180-1]ハッシュであります
SHA1( key, keyfill, data, datafill, key, mdfill )
SHA1（キー、keyfill、データ、datafill、キー、mdfill）
where the key is the computed verification-key.
どこキーは、計算された検証鍵です。
The keyfill and datafill use the same pad-with-length technique defined for mdfill. This padding and length is implicit, and does not appear in the datagram.
keyfillとmdfillに対して定義された同じパッドを有する長技法を使用datafill。このパディングと長さは暗黙的で、かつデータグラムには表示されません。
The resulting Verification field is a 160-bit Variable Precision Integer (22 bytes including Size). When used in calculations, the
得られた検証フィールド160ビットの可変精度整数型（サイズを含む22バイト）です。計算に使用する場合、
Verification data includes both the Size and Value fields.
検証データはサイズと値フィールドの両方を含んでいます。
The attribute format and basic facilities are already defined for Photuris [RFC-2522].
属性形式と基本施設はすでにPhoturis [RFC-2522]のために定義されています。
These optional attributes are specified separately, and no single implementation is expected to support all of them.
これらのオプションの属性は、個別に指定され、単一の実装はそれらのすべてをサポートすることが期待されていません。
This document defines the following values:
このドキュメントでは、次の値を定義します。
Use Type AEI 6 SHA1-IPMAC AEI 7 RIPEMD-160-IPMAC E 8 DES-CBC E 9 Invert (Decryption/Encryption) E 10 XOR
使用タイプAEI 6 SHA1-IPMAC AEI 7 RIPEMD-160-IPMAC E 8 DES-CBC E 9反転（復号化/暗号化）E 10 XOR
A AH Attribute-Choice E ESP Attribute-Choice I Identity-Choice X dependent on list location
AH属性-選択肢E ESP属性-ChoiceのIアイデンティティ-ChoiceのXリストの位置に依存
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute 6
属性6
Length 0
長さが0
When selected as an Identity-Choice, the immediately following Identification field contains an unstructured Variable Precision Integer. Valid Identifications and symmetric secret-keys are preconfigured by the parties.
アイデンティティ選択肢として選択した場合は、すぐに次の識別フィールドは、非構造化可変精度整数が含まれています。有効な識別と対称秘密鍵は、当事者によって事前設定されています。
There is no required format or content for the Identification value. The value may be a number or string of any kind. See [RFC-2522] "Use of Identification and Secrets" for details.
識別値のための必要な形式や内容はありません。値は、任意の種類の数またはストリングであり得ます。詳細については、[RFC-2522]「の同定と秘密の使用」を参照してください。
The symmetric secret-key (as specified) is selected based on the contents of the Identification field. All implementations MUST support at least 62 bytes. The selected symmetric secret-key SHOULD provide at least 80-bits of cryptographic strength.
対称秘密鍵は、（指定された）識別フィールドの内容に基づいて選択されます。すべての実装は、少なくとも62のバイトをサポートしなければなりません。選択された対称秘密鍵は、暗号強度の少なくとも80ビットを提供すべきです。
As described in [RFC-2522] "Identity Verification", the Verification field value is the SHA1 [FIPS-180-1] hash over the concatenation of:
[RFC-2522]「識別情報の検証」に記載されているように、検証フィールドの値は、連結上SHA1 [FIPS-180-1]ハッシュです。
SHA1( key, keyfill, data, datafill, key, mdfill )
SHA1（キー、keyfill、データ、datafill、キー、mdfill）
where the key is the computed verification-key.
どこキーは、計算された検証鍵です。
The keyfill and datafill use the same pad-with-length technique defined for mdfill. This padding and length is implicit, and does not appear in the datagram.
keyfillとmdfillに対して定義された同じパッドを有する長技法を使用datafill。このパディングと長さは暗黙的で、かつデータグラムには表示されません。
The resulting Verification field is a 160-bit Variable Precision Integer (22 bytes including Size). When used in calculations, the Verification data includes both the Size and Value fields.
得られた検証フィールド160ビットの可変精度整数型（サイズを含む22バイト）です。計算に使用する場合、検証データはサイズと値フィールドの両方を含んでいます。
For both [RFC-2522] "Identity Verification" and "Validity Verification", the verification-key is the SHA1 [FIPS-180-1] hash of the following concatenated values:
[RFC-2522]「識別情報の検証」と「妥当性検証」の両方について、検証鍵は、以下の連結された値のSHA1 [FIPS-180-1]ハッシュです。
+ the symmetric secret-key, + the computed shared-secret.
+左右対称秘密鍵、+計算された共有秘密。
For [RFC-2522] "Session-Key Computation", the symmetric secret-key is used directly as the generation-key.
[RFC-2522]「セッション・キー計算」について、対称秘密鍵は、世代の鍵として直接使用されます。
The symmetric secret-key is used in calculations in the same fashion as [RFC-2522] "MD5-IPMAC Symmetric Identification".
対称秘密鍵は、[RFC-2522]「MD5-IPMAC対称識別」と同じやり方で計算に使用されます。
May be selected as an AH or ESP Attribute-Choice, pursuant to [RFC-1852] et sequitur. The selected Exchange-Scheme SHOULD provide at least 80-bits of cryptographic strength.
[RFC-1852]に基づき、AHまたはESP項目の選択肢として選択することができるらsequitur。選択されたExchange-スキームは、暗号強度の少なくとも80ビットを提供すべきです。
As described in [RFC-2522] "Session-Key Computation", the most significant 384-bits (48 bytes) of the Key-Generation-Function iterations are used for the key.
[RFC-2522]「セッションキー計算」に記載されているように、鍵生成機能反復の最上位384ビット（48バイト）がキーのために使用されます。
Profile:
プロフィール：
When negotiated with Photuris, the transform differs slightly from [RFC-1852].
Photurisと交渉すると、変換[RFC-1852]とは若干異なります。
The form of the authenticated message is:
認証されたメッセージの形式は次のとおりです。
SHA1( key, keyfill, datagram, datafill, key, mdfill )
SHA1（キー、keyfill、データグラム、datafill、キー、mdfill）
where the key is the SPI session-key.
どこキーはSPIセッションキーです。
The additional datafill protects against the attack described in [PO96]. The keyfill and datafill use the same pad-with-length technique defined for mdfill. This padding and length is implicit, and does not appear in the datagram.
追加datafillは[PO96]で説明した攻撃から保護します。 keyfillとmdfillに対して定義された同じパッドを有する長技法を使用datafill。このパディングと長さは暗黙的で、かつデータグラムには表示されません。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute 7
属性7
Length 0
長さが0
When selected as an Identity-Choice, the immediately following Identification field contains an unstructured Variable Precision Integer. Valid Identifications and symmetric secret-keys are preconfigured by the parties.
アイデンティティ選択肢として選択した場合は、すぐに次の識別フィールドは、非構造化可変精度整数が含まれています。有効な識別と対称秘密鍵は、当事者によって事前設定されています。
There is no required format or content for the Identification value. The value may be a number or string of any kind. See [RFC-2522] "Use of Identification and Secrets" for details.
識別値のための必要な形式や内容はありません。値は、任意の種類の数またはストリングであり得ます。詳細については、[RFC-2522]「の同定と秘密の使用」を参照してください。
The symmetric secret-key (as specified) is selected based on the contents of the Identification field. All implementations MUST support at least 62 bytes. The selected symmetric secret-key SHOULD provide at least 80-bits of cryptographic strength.
対称秘密鍵は、（指定された）識別フィールドの内容に基づいて選択されます。すべての実装は、少なくとも62のバイトをサポートしなければなりません。選択された対称秘密鍵は、暗号強度の少なくとも80ビットを提供すべきです。
As described in [RFC-2522] "Identity Verification", the Verification field value is the RIPEMD-160 [DBP96] hash over the concatenation of:
[RFC-2522]「識別情報の検証」に記載されているように、検証フィールドの値は、連結上RIPEMD-160 [DBP96]ハッシュです。
RIPEMD160( key, keyfill, data, datafill, key, mdfill )
RIPEMD160（キー、keyfill、データ、datafill、キー、mdfill）
where the key is the computed verification-key.
どこキーは、計算された検証鍵です。
The keyfill and datafill use the same pad-with-length technique defined for mdfill. This padding and length is implicit, and does not appear in the datagram.
keyfillとmdfillに対して定義された同じパッドを有する長技法を使用datafill。このパディングと長さは暗黙的で、かつデータグラムには表示されません。
The resulting Verification field is a 160-bit Variable Precision Integer (22 bytes including Size). When used in calculations, the Verification data includes both the Size and Value fields.
得られた検証フィールド160ビットの可変精度整数型（サイズを含む22バイト）です。計算に使用する場合、検証データはサイズと値フィールドの両方を含んでいます。
For both [RFC-2522] "Identity Verification" and "Validity Verification", the verification-key is the RIPEMD-160 [DBP96] hash of the following concatenated values:
[RFC-2522]「識別情報の検証」と「妥当性検証」の両方について、検証鍵は、以下の連結された値のRIPEMD-160 [DBP96]ハッシュです。
+ the symmetric secret-key, + the computed shared-secret.
+左右対称秘密鍵、+計算された共有秘密。
For [RFC-2522] "Session-Key Computation", the symmetric secret-key is used directly as the generation-key.
[RFC-2522]「セッション・キー計算」について、対称秘密鍵は、世代の鍵として直接使用されます。
The symmetric secret-key is used in calculations in the same fashion as [RFC-2522] "MD5-IPMAC Symmetric Identification".
対称秘密鍵は、[RFC-2522]「MD5-IPMAC対称識別」と同じやり方で計算に使用されます。
May be selected as an AH or ESP Attribute-Choice. The selected Exchange-Scheme SHOULD provide at least 80-bits of cryptographic strength.
AHまたはESP属性、選択肢として選択することができます。選択されたExchange-スキームは、暗号強度の少なくとも80ビットを提供すべきです。
As described in [RFC-2522] "Session-Key Computation", the most significant 384-bits (48 bytes) of the Key-Generation-Function iterations are used for the key.
[RFC-2522]「セッションキー計算」に記載されているように、鍵生成機能反復の最上位384ビット（48バイト）がキーのために使用されます。
Profile:
プロフィール：
When negotiated with Photuris, the form of the authenticated message is:
Photurisと交渉するとき、認証されたメッセージの形式は次のとおりです。
RIPEMD160( key, keyfill, datagram, datafill, key, mdfill )
RIPEMD160（キー、keyfill、データグラム、datafill、キー、mdfill）
where the key is the SPI session-key.
どこキーはSPIセッションキーです。
The additional datafill protects against the attack described in [PO96]. The keyfill and datafill use the same pad-with-length technique defined for mdfill. This padding and length is implicit, and does not appear in the datagram.
追加datafillは[PO96]で説明した攻撃から保護します。 keyfillとmdfillに対して定義された同じパッドを有する長技法を使用datafill。このパディングと長さは暗黙的で、かつデータグラムには表示されません。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute 8
属性8
Length 0
長さが0
May be selected as an ESP Attribute-Choice, pursuant to [RFC-1829] et sequitur. The selected Exchange-Scheme SHOULD provide at least 56- bits of cryptographic strength.
[RFC-1829]らsequiturに基づき、ESP属性-選択肢として選択することができます。選択されたExchange-スキームは、暗号強度の少なくとも56ビットのビットを提供する必要があります。
As described in [RFC-2522] "Session-Key Computation", the most significant 64-bits (8 bytes) of the Key-Generation iteration are used for the key, and the remainder are discarded. Although extremely rare, the 64 weak, semi-weak, and possibly weak keys [Schneier95, pages 280-282] MUST be discarded. The Key-Generation-Function is iterated until a valid key is obtained.
[RFC-2522]「セッションキー計算」に記載されているように、鍵生成の反復の最上位64ビット（8バイト）をキーに使用され、残りは破棄されます。非常に稀が、64、弱半弱、およびおそらく弱いキー[Schneier95、ページ280~282]は捨てなければなりません。有効なキーが得られるまで、鍵生成・機能が繰り返されます。
The least significant bit of each key byte is ignored (or set to parity when the implementation requires).
各キーのバイトの最下位ビットは無視（または実装が必要とする時、パリティに設定）されます。
Profile:
プロフィール：
When negotiated with Photuris, the transform differs slightly from [RFC-1829].
Photurisと交渉すると、変換[RFC-1829]とは若干異なります。
The 32-bit Security Parameters Index (SPI) field is followed by a 32-bit Sequence Number (SN).
32ビットのセキュリティパラメータインデックス（SPI）フィールドは、32ビットのシーケンス番号（SN）が続いています。
The 64-bit CBC IV is generated from the 32-bit Security Parameters Index (SPI) field followed by (concatenated with) the 32-bit Sequence Number (SN) field. Then, the bit-wise complement of the 32-bit Sequence Number (SN) value is XOR'd with the first 32-bits (SPI):
64ビットのCBC IVは、32ビットのシーケンス番号（SN）フィールド（と連結）、続いて32ビットのセキュリティパラメータインデックス（SPI）フィールドから生成されます。その後、32ビットのシーケンス番号（SN）の値のビット単位の補数は、最初の32ビット（SPI）とのXORをとります。
(SPI ^ -SN) || SN
（SPI ^-SN）|| SN
The Padding values begin with the value 1, and count up to the number of padding bytes. For example, if the plaintext length is 41, the padding values are 1, 2, 3, 4, 5, 6 and 7, plus any additional obscuring padding.
パディング値は、値が1で始まり、パディングバイトの数をカウントアップ。平文の長さが41である場合、例えば、パディング値は1、2、3、4、5、6及び7、プラス任意の追加の隠蔽パディングです。
The PadLength and PayloadType are not appended. Instead, the PayloadType is indicated by the SPI, as specified by the ESP-Attributes attribute (#2).
PadLengthとPayloadTypeは添付されていません。指定された属性（＃2）ESPは、属性としてその代わりに、PayloadTypeは、SPIによって示されています。
After decryption, if the padding bytes are not the correct sequential values, then the payload is discarded, and a "Decryption Failed" error is indicated, as described in [RFC-2521].
復号後のパディングバイトが正しい連続した値がない場合、その後、ペイロードが廃棄され、[RFC-2521]に記載されているように、エラーが、示されている「復号化に失敗しました」。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute 9
属性9
Length 0
長さが0
May be selected as an ESP Attribute-Choice, immediately preceding an encryption choice. This indicates that the following attribute is inverted from encryption to decryption (or decryption to encryption) as the attributes are processed.
すぐに暗号化の選択の前に、ESP属性-選択肢として選択することができます。これは、属性が処理されるよう、以下の属性は、（暗号化または復号化）復号するための暗号化から反転していることを示しています。
For example, the combination
例えば、組み合わせ
"DES-CBC", "Invert", "DES-CBC", "DES-CBC",
"DES-CBC"、 "反転"、 "DES-CBC"、 "DES-CBC"
indicates "Triple DES" outer-CBC EDE encryption (and DED decryption) with three keys [KR96] pursuant to [RFC-1851] et sequitur. The selected Exchange-Scheme SHOULD provide at least 112-bits of cryptographic strength.
3つのキーによる[KR96] [RFC-1851]他sequiturで "トリプルDES" 外CBC EDE暗号化（および復号DED）を示しています。選択されたExchange-スキームは、暗号の強さの少なくとも112ビットを提供すべきです。
As described in [RFC-2522] "Session-Key Computation", the Key-Generation-Function is iterated (at least) three times to generate the three independent keys, in the order used for encryption. The most significant 64-bits (8 bytes) of each iteration are used for each successive key, and the remainder are discarded.
[RFC-2522]「セッションキー計算」に記載されているように、鍵生成関数が暗号化に使用されるために、三つの独立した鍵を生成するために（少なくとも）を3回繰り返します。各反復の最上位64ビット（8バイト）は、各連続するキーのために使用され、残りは破棄されます。
Each key is examined sequentially, in the order used for encryption. A key that is identical to any previous key MUST be discarded. Any weak keys indicated for the algorithm MUST be discarded. The Key-Generation-Function is iterated until a valid key is obtained before generating the next key.
各キーは暗号化に使用されるためには、順次検討しています。以前のキーと同じです鍵は捨てなければなりません。アルゴリズムのために示され、任意の弱いキーは破棄されなければなりません。有効なキーは次のキーを生成する前に得られるまで、鍵生成・機能が繰り返されます。
Profile:
プロフィール：
When negotiated with Photuris, the "DES-EDE3-CBC" transform differs slightly from [RFC-1851], in the same fashion as "DES-CBC" (described earlier).
Photurisと交渉するとき、 "DES-EDE3-CBC" は（先に説明した） "DES-CBC" と同じ方法で、[RFC-1851]から若干異なり変換します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute 10
属性10
Length 0
長さが0
May be selected as an ESP Attribute-Choice, pursuant to [XEX3] et sequitur. The combination
らsequitur [XEX3]に基づき、ESP属性-選択肢として選択することができます。組み合わせ
"XOR", "DES-CBC", "XOR",
"XOR"、 "DES-CBC"、 "XOR"
indicates "DESX" encryption with three keys [KR96]. The selected Exchange-Scheme SHOULD provide at least 104-bits of cryptographic strength.
3つのキー[KR96]で「DESX」暗号化を示しています。選択されたExchange-スキームは、暗号の強さの少なくとも104ビットを提供すべきです。
As described in [RFC-2522] "Session-Key Computation", the Key-Generation-Function is iterated (at least) three times to generate the three independent keys, in the order used for encryption. The most significant bytes of each iteration are used for each successive key, and the remainder are discarded.
[RFC-2522]「セッションキー計算」に記載されているように、鍵生成関数が暗号化に使用されるために、三つの独立した鍵を生成するために（少なくとも）を3回繰り返します。各反復の最上位バイトは、連続する各キーのために使用され、残りは破棄されます。
Note that this attribute may appear multiple times in the same ESP attribute list, both before and after an encryption transform. For example,
この属性は、暗号化変換の前と後の両方、同じESPの属性リストに複数回表示されることがあります。例えば、
"XOR", "DES-CBC", "XOR", "Invert", "DES-CBC", "XOR", "DES-CBC", "XOR",
"XOR"、 "DES-CBC"、 "XOR"、 "反転"、 "DES-CBC"、 "XOR"、 "DES-CBC"、 "XOR"、
would be one possible combination with Triple DES.
トリプルDESとの一つの可能な組み合わせになります。
A. Exchange-Scheme Selection
A.取引所、スキームの選択
At first glance, there appear to be a large number of exchange-schemes. In practice, the selection is simple to automate.
一見すると、交換スキームの多数があるように思われます。実際には、選択は自動化するのは簡単です。
Each scheme indicates a needed strength. This strength is based upon the functions used in protecting the Photuris Exchanges themselves.
各スキームは、必要な強度を示しています。この強度はPhoturis取引所自身を保護するのに使用される機能に基づいています。
Each keyed attribute also indicates a needed strength. This strength is based upon its cryptographic functions.
各キー付き属性も必要な強さを示します。この強さは、その暗号化機能に基づいています。
Because the usage of these functions is orthogonal, the same strength value can select an appropriate scheme that meets the needs of both features.
これらの機能の使用が直交しているので、同じ強度値は、両方の機能のニーズを満たす適切なスキームを選択することができます。
A.1. Responder
A.1。答え
The attributes to be offered to the particular Initiator are examined. For each level of strength specified, a scheme that meets or exceeds the requirements is offered.
特定のイニシエータに提供するための属性を調べています。指定された強さのレベルごとに、要件を満たすまたは超える方式が提供されます。
For example, a Responder offering MD5-IPMAC and SHA1-IPMAC might offer scheme #2 with a 512-bit modulus and a 1024-bit modulus, and scheme #4 with a zero Size (indicating moduli of #2).
例えば、MD5-IPMACとSHA1-IPMACを提供レスポンダは（＃2の弾性率を示す）ゼロサイズの512ビットモジュラス及び1024ビットモジュラスを有するスキーム＃2、スキーム＃4を提供するかもしれません。
A.2. Initiator
A.2。イニシエータ
The strength indicated by the application for the Security Association, together with the party privacy policy of the system operator, is used to select from the offered schemes. The strength indicates the minimal level to be chosen, while the party privacy policy indicates whether to choose the minimal or maximal level of available protection.
セキュリティアソシエーションのためのアプリケーションで示される強度は、一緒にシステムオペレータのパーティのプライバシーポリシーに、提案手法から選択するために使用されます。パーティのプライバシーポリシーは、利用可能な保護の最小または最大レベルを選択するかどうかを示しながら強度は、最低限のレベルを選択することを示しています。
For example, an application might indicate that it desires 80-bits of strength. In that case, only the 1024-bit modulus would be appropriate. The party privacy policy of the system operator would indicate whether to choose scheme #2 with "Simple Masking" or scheme #4 with "DES-CBC over Mask".
例えば、アプリケーションは、それが強度の80ビットを希望することを示すかもしれません。その場合には、唯一の1024ビットモジュラスが適切であろう。システムオペレーターのパーティーのプライバシーポリシーは、「マスクの上にDES-CBC」と「シンプルマスキング」またはスキーム＃4でスキーム＃2を選択するかどうかを示すことになります。
Alternatively, an application might indicate that it desires 64-bits of strength. The party privacy policy of the system operator would indicate whether to choose scheme #2 with the 512-bit modulus, or scheme #4 with the 1024-bit modulus.
あるいは、アプリケーションは、それが強度の64ビットを希望することを示すかもしれません。システムオペレータのパーティのプライバシーポリシーは、1024ビットモジュラスを有する512ビットモジュラス、又はスキーム＃4を用いてスキーム＃2を選択するかどうかを示すであろう。
Security Considerations
セキュリティの考慮事項
Provision for multiple generators does not enhance the security of the Photuris protocol exchange itself. Rather, it provides an opportunity for novelty of moduli, by allowing more forms of moduli to be used. An abundance of moduli inhibits a determined attacker from pre-calculating moduli exchange values, and discourages dedication of resources for analysis of any particular modulus. That is, this protects the community of Photuris users.
複数の発電機のための引当金は、Photurisプロトコル交換自体のセキュリティを強化しません。むしろ、それは弾性率のより多くのフォームが使用できるようにすることで、弾性係数の新規性のための機会を提供します。モジュラスの存在量は、予め計算モジュラス交換値から決定攻撃を阻害、任意の特定の弾性率の分析のためのリソースの献身を阻止します。つまり、これはPhoturisユーザーのコミュニティを保護します。
In addition to preventing various attacks by protecting verification fields, the masking of the message plaintext before encryption is intended to obscure the relation of the number of parties and SPIs active between two IP nodes. The privacy mask dependency on the SPI and SPILT generates a different initial encrypted block for every SPI creation message.
検証フィールドを保護することにより、様々な攻撃を防ぐことに加えて、暗号化前の平文メッセージのマスキングは、2つのIPノード間の活性の当事者とのSPIの数の関係を不明瞭にすることを意図しています。プライバシーマスクSPIへの依存とこぼしたが、すべてのSPIの作成、メッセージの異なる初期暗号化されたブロックを生成します。
This obscurement would be less effective when the SPI and SPILT are invariant or are not created for a particular exchange direction. The number of parties could be revealed by the number of exchanges with differences in the initial encrypted blocks.
SPIとこぼれが不変であるか、または特定の交換の方向のために作成されていない場合、このobscurementはあまり有効であろう。関係者の数は、最初の暗号化されたブロックの違いとの交流の数によって明らかにすることができます。
Acknowledgements
謝辞
Phil Karn was principally responsible for the design of party privacy protection, and provided much of the design rationale text (now removed to a separate document).
フィル・カーンは、パーティのプライバシー保護の設計のために主に責任があった、と（今別のドキュメントに削除）、設計根拠のテキストの多くを提供します。
William Simpson was responsible for the packet formats, and additional Exchange-Schemes, editing and formatting. All such mistakes are his responsibity.
ウィリアム・シンプソンは、パケットフォーマット、および追加のExchangeスキーム、編集および書式設定を担当していました。そのようなすべてのミスは彼の応答性能です。
Use of encryption for privacy protection is also found in the Station-To-Station authentication protocol [DOW92].
プライバシー保護のための暗号化の使用は、ステーション間の認証プロトコル[DOW92]で発見されました。
Bart Preneel and Paul C van Oorschot in [PO96] recommended padding between the data and trailing key when hashing for authentication.
認証のためのハッシュ場合バート・プレニール及び[PO96]ポール・C・ヴァン・Oorschotデータと末尾のキーの間にパディングを推奨しました。
Niels Provos developed the first implementation with multiple schemes and multiple moduli per scheme (circa July 1997).
ニールス・プロボスは、複数のスキームおよび（1997年7月頃）方式ごとに複数のモジュラスを持つ最初の実装を開発しました。
Special thanks to the Center for Information Technology Integration (CITI) for providing computing resources.
コンピューティングリソースを提供するための情報基盤の統合のためのセンター（CITI）に感謝します。
References
リファレンス
[DBP96] Dobbertin, H., Bosselaers, A., and Preneel, B., "RIPEMD-160: a strengthened version of RIPEMD", Fast Software Encryption, Third International Workshop, Lecture Notes in Computer Science 1039 (1996), Springer-Verlag, pages 71-82.
[DBP96] Dobbertin、H.、Bosselaers、A.、およびPreneel、B.、 "RIPEMD-160：RIPEMDの強化版" 1039（1996）コンピュータサイエンス、高速ソフトウェア暗号化、第3回国際ワークショップ、講義ノート、スプリンガー-Verlag、ページ71-82。
See also corrections at
ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/bosselae/ripemd/.
[DOW92] Whitfield Diffie, Paul C van Oorshot, and Michael J Wiener, "Authentication and Authenticated Key Exchanges", Designs, Codes and Cryptography, v 2 pp 107-125, Kluwer Academic Publishers, 1992.
[DOW92]ホイットフィールドディフィー、ポールCバンOorshot、そしてマイケル・Jウィーン、「認証および認証鍵交換」、デザイン、コード、および暗号化、V 2頁107から125、Kluwerの学術出版社、1992。
[FIPS-180-1] "Secure Hash Standard", National Institute of Standards and Technology, U.S. Department Of Commerce, April 1995.
[FIPS-180-1]、国立標準技術研究所、米国商務省が、1995年4月「ハッシュ標準セキュア」。
Also known as: 59 Fed Reg 35317 (1994).
59連銀のReg 35317（1994）：としても知られています。
[KR96] Kaliski, B., and Robshaw, M., "Multiple Encryption: Weighing Security and Performance", Dr. Dobbs Journal, January 1996.
[KR96] Kaliski、B.、およびRobshaw、M.、 "複数の暗号化：セキュリティとパフォーマンスを計量"、博士ドブスジャーナル、1996年1月。
[PO96] Bart Preneel, and Paul C van Oorshot, "On the security of two MAC algorithms", Advances in Cryptology -- Eurocrypt '96, Lecture Notes in Computer Science 1070 (May 1996), Springer-Verlag, pages 19-32.
「2つのMACアルゴリズムのセキュリティについて」[PO96]バート・プレニール、およびポールCバンOorshotは、暗号学における進歩 - コンピュータサイエンス1070（1996年5月）、シュプリンガー・フェアラーク、ページ19-32でEUROCRYPT '96、講義ノートを。
[RFC-1829] Karn, P., Metzger, P., Simpson, W., "The ESP DES-CBC Transform", July 1995.
[RFC-1829]カーン、P.、メッツガー、P.、シンプソン、W.は、 "ESP DES-CBC変換を"、1995年7月。
[RFC-1850] Karn, P., Metzger, P., Simpson, W., "The ESP Triple DES Transform", September 1995.
[RFC-1850]カーン、P.、メッツガー、P.、シンプソン、W.、 "ESPトリプルDESは、トランスフォーム"、1995年9月。
[RFC-1851] Metzger, P., Simpson, W., "IP Authentication using Keyed SHA", September 1995.
[RFC-1851]メッツガー、P.、シンプソン、W.、 "キー付きSHAを使用してIP認証"、1995年9月。
[RFC-2521] Karn, P., and Simpson, W., "ICMP Security Failures Messages", March 1999.
[RFC-2521]カーン、P.、およびシンプソン、W.、 "ICMPセキュリティの失敗メッセージ"、1999年3月。
[RFC-2522] Karn, P., and Simpson, W., "Photuris: Session-Key Management Protocol", March 1999.
[RFC-2522]カーン、P.、およびシンプソン、W.、 "Photuris：セッション鍵管理プロトコル"、1999年3月。
[XEX3] Simpson, W., Baldwin, R., "The ESP DES-XEX3-CBC Transform", Work In Progress, June 1997.
[XEX3]シンプソン、W.、ボールドウィン、R.は、 "ESP DES-XEX3-CBC変換を"、進歩、1997年6月で働いています。
Contacts
コンタクト
Comments about this document should be discussed on the photuris@adk.gr mailing list.
この文書についてのコメントはphoturis@adk.grメーリングリストで議論されるべきです。
Questions about this document can also be directed to:
このドキュメントに関する質問も対象とすることができます。
Phil Karn Qualcomm, Inc. 6455 Lusk Blvd. San Diego, California 92121-2779
フィル・カーンクアルコム社6455ラスクブルバードサンディエゴ、カリフォルニア92121-2779
karn@qualcomm.com
karn@unix.ka9q.ampr.org (preferred)
William Allen Simpson DayDreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071
ウィリアムアレンシンプソン空想家コンピュータシステムズコンサルティングサービス1384フォンテーヌマディソンハイツ、ミシガン州48071
wsimpson@UMich.edu
wsimpson@GreenDragon.com (preferred)
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). Copyright (C) Philip Karn and William Allen Simpson (1994-1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。著作権（C）フィリップ・カーンとウィリアムアレンシンプソン（1994年から1999年）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards (in which case the procedures for copyrights defined in the Internet Standards process must be followed), or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手続きが規定されている場合には（インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化過程で）続く、またはとしては、英語以外の言語に翻訳するために必要とされなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and 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.
基礎とインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または黙示、（に限らず）を含めた情報の使用は、本明細書に一切の保証「そのまま」本明細書中に含まれるこの文書や情報を上に設けられています特定の目的に対する権利または商品性または適合性の黙示の保証を侵害することはありません。