[要約] RFC 2523は、Photurisプロトコルの拡張スキームと属性に関する情報を提供しています。このRFCの目的は、Photurisプロトコルの機能を拡張し、より柔軟なセキュリティメカニズムを提供することです。
Network Working Group P. Karn
Request for Comments: 2523 Qualcomm
Category: Experimental W. Simpson
DayDreamer
March 1999
Photuris: Extended Schemes and Attributes
Photuris：拡張スキームと属性
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.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). Copyright (C) Philip Karn and William Allen Simpson (1994-1999). All Rights Reserved.
Copyright（c）The Internet Society（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) オプションの実装。推奨ジェネレーター（g）を備えたモジュラス（p）は3の推奨発電機（g）を使用しています。交換場のサイズがゼロではない場合、モジュラスは提供されたスキームのリストの交換シーム値フィールドに含まれています。
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) オプションの実装。推奨ジェネレーター（g）が2の推奨ジェネレーター（g）を備えたモジュラス（p）は、交換シームサイズがゼロではない場合、モジュラスは提供されたスキームのリストの交換シーム値フィールドに含まれています。
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.
Exchange-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) オプションの実装。推奨ジェネレーター（g）が5のモジュラス（p）は、交換スキームサイズがゼロではない場合、モジュラスは提供されたスキームのリストの交換シーム値フィールドに含まれています。
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) オプションの実装。推奨ジェネレーター（g）を備えたモジュラス（p）は3の推奨発電機（g）を使用しています。交換場のサイズがゼロではない場合、モジュラスは提供されたスキームのリストの交換シーム値フィールドに含まれています。
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.
Exchange-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）。Exchange-Schemeサイズがゼロではない場合、ペア[G、P]は、提供されたシェムのリストのExchange-Scheme値フィールドに含まれています。それぞれが別の可変精度整数（VPI）でエンコードされます。ジェネレーターVPIの後に、モジュラスVPIが（連結）され、結果はExchange-Scheme値フィールド内にネストされます。
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
(8) オプションの実装。推奨ジェネレーター（g）が2の推奨ジェネレーター（g）を持つ任意のモジュラス（p）は、交換シームサイズがゼロではない場合、弾性率は交換シーム値フィールドに含まれています。
the list of Offered-Schemes.
提供されたシェムのリスト。
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.
Exchange-Schemeサイズのフィールドがゼロの場合、スキーム＃2および＃4の提供されたシームのリストに指定されたすべてのモジュリを参照することで含まれます。
Key-Generation-Function "SHA1 Hash" Privacy-Method "DES-EDE3-CBC over Mask" Validity-Method "SHA1-IPMAC Check"
キージェネレーション機能「SHA1ハッシュ「プライバシー - メソッド」des-ede3-cbc上のマスク「有効性 - method」 "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）オプションの実装。推奨ジェネレーター（g）が5のモジュラス（p）は、交換スキームサイズがゼロではない場合、モジュラスは提供されたスキームのリストの交換シーム値フィールドに含まれています。
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.
Exchange-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）オプションの実装。推奨ジェネレーター（g）を備えたモジュラス（p）は3の推奨発電機（g）を使用しています。交換場のサイズがゼロではない場合、モジュラスは提供されたスキームのリストの交換シーム値フィールドに含まれています。
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.
Exchange-Schemeサイズのフィールドがゼロの場合、スキーム＃3および＃6の提供されたシームのリストに指定されたすべてのモジュリを参照することで含まれます。
Key-Generation-Function "SHA1 Hash" Privacy-Method "DES-EDE3-CBC over Mask" Validity-Method "SHA1-IPMAC Check"
キージェネレーション機能「SHA1ハッシュ「プライバシー - メソッド」des-ede3-cbc上のマスク「有効性 - method」 "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
（14）オプションの実装。可変ジェネレーター（g）を備えたモジュラス（P）。Exchange-Schemeサイズがゼロではない場合、ペア[G、P]は、
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.
提供されたシェムのリスト。それぞれが別の可変精度整数（VPI）でエンコードされます。ジェネレーターVPIの後に、モジュラスVPIが（連結）され、結果はExchange-Scheme値フィールド内にネストされます。
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.
Exchange-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）オプションの実装。推奨ジェネレーター（g）が5のモジュラス（p）は、交換スキームサイズがゼロではない場合、モジュラスは提供されたスキームのリストの交換シーム値フィールドに含まれています。
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.
Exchange-Schemeサイズのフィールドがゼロの場合、スキーム＃5および＃10の提供されたシームのリストに指定されたすべてのモジュリを参照することで含まれます。
Key-Generation-Function "SHA1 Hash" Privacy-Method "DES-EDE3-CBC over Mask" Validity-Method "SHA1-IPMAC Check"
キージェネレーション機能「SHA1ハッシュ「プライバシー - メソッド」des-ede3-cbc上のマスク「有効性 - method」 "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）。Exchange-Schemeサイズがゼロではない場合、ペア[G、P]は、提供されたシェムのリストのExchange-Scheme値フィールドに含まれています。それぞれが別の可変精度整数（VPI）でエンコードされます。ジェネレーターVPIの後に、モジュラスVPIが（連結）され、結果はExchange-Scheme値フィールド内にネストされます。
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.
Exchange-Schemeサイズのフィールドがゼロの場合、スキーム＃7および＃14の提供されたシームのリストに指定されたすべてのモジュリを参照することで含まれます。
Key-Generation-Function "SHA1 Hash" Privacy-Method "DES-EDE3-CBC over Mask" Validity-Method "SHA1-IPMAC Check"
キージェネレーション機能「SHA1ハッシュ「プライバシー - メソッド」des-ede3-cbc上のマスク「有効性 - method」 "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]は、キーを生成するための擬似ランダム機能として使用されます。キーは、ハッシュの最も重要なビットから始まります。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
64ビットCBC IVはゼロです。メッセージ暗号化は、SPIの後の次のフィールドから始まり、示されたデータの終わりまで続きます
by the UDP Length.
UDPの長さによって。
This is "Triple DES" outer-CBC EDE encryption (and DED decryption) with three 56-bit keys [KR96].
これは、3つの56ビットキー[KR96]を備えた「トリプルデス」アウターCBC EDE暗号化（およびDED Decryption）です。
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（key、keyfill、data、datafill、key、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.
キーフィルとDataFillは、MDFILL用に定義された同じ長さの手法を使用しています。このパディングと長さは暗黙的であり、データグラムには表示されません。
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 INVERT（DECRYPTING/暗号化）E 10 XOR
A AH Attribute-Choice E ESP Attribute-Choice I Identity-Choice X dependent on list location
ah属性 - 選択e esp属性選択iアイデンティティ選択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.
ID選択として選択されると、直後の識別フィールドには、非構造化変数精度整数が含まれています。有効な識別と対称的なシークレットキーは、当事者によって事前に設定されています。
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（key、keyfill、data、datafill、key、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.
キーフィルとDataFillは、MDFILL用に定義された同じ長さの手法を使用しています。このパディングと長さは暗黙的であり、データグラムには表示されません。
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]「Session-Key Computation」の場合、対称的なシークレットキーはGeneration-Keyとして直接使用されます。
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] et Schequiturに従って、AHまたはESP属性選択として選択できます。選択した交換シェームは、少なくとも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（key、keyfill、datagram、datafill、key、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.
追加のデータフィルは、[PO96]に記載されている攻撃から保護します。キーフィルとDataFillは、MDFILL用に定義された同じ長さの手法を使用しています。このパディングと長さは暗黙的であり、データグラムには表示されません。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
ID選択として選択されると、直後の識別フィールドには、非構造化変数精度整数が含まれています。有効な識別と対称的なシークレットキーは、当事者によって事前に設定されています。
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（key、keyfill、data、datafill、key、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.
キーフィルとDataFillは、MDFILL用に定義された同じ長さの手法を使用しています。このパディングと長さは暗黙的であり、データグラムには表示されません。
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]「Session-Key Computation」の場合、対称的なシークレットキーはGeneration-Keyとして直接使用されます。
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属性選択として選択できます。選択した交換シェームは、少なくとも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（key、keyfill、datagram、datafill、key、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.
追加のデータフィルは、[PO96]に記載されている攻撃から保護します。キーフィルとDataFillは、MDFILL用に定義された同じ長さの手法を使用しています。このパディングと長さは暗黙的であり、データグラムには表示されません。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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] ET SquiTurに従って、ESP属性選択として選択できます。選択された交換シェームは、少なくとも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]「Session-Key Computation」で説明されているように、キージェネレーション反復の最も重要な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ビットセキュリティパラメーターインデックス（SPI）フィールドから生成され、その後に32ビットシーケンス番号（SN）フィールドが続きます。次に、32ビットシーケンス数（SN）値のビットごとの補数は、最初の32ビット（SPI）でXor'dです。
(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は追加されていません。代わりに、PayLoadTypeは、ESP-Attributes属性（＃2）で指定されている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」、 "invert"、 "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.
[RFC-1851] ET Schequiturに従って、3つのキー[KR96]を使用した「トリプルデス」アウターCBC EDE暗号化（およびded Ded Decryption）を示します。選択された交換シェームは、少なくとも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つの独立したキーを生成するために（少なくとも）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」変換は[RFC-1851]と同じように「DES-CBC」と同じように異なります（前述）。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute 10
属性10
Length 0
長さ0
May be selected as an ESP Attribute-Choice, pursuant to [XEX3] et sequitur. The combination
[xex3] et schietiTurに従って、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つのキーを使用した「desx」暗号化を示します[Kr96]。選択された交換シェームは、少なくとも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つの独立したキーを生成するために（少なくとも）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"、 "invert"、 "des-cbc"、 "xor"、 "des-cbc"、 "xor"、
would be one possible combination with Triple DES.
トリプルデスとの1つの可能な組み合わせです。
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.
各スキームは、必要な強度を示します。この強度は、光虫の交換自体を保護するために使用される機能に基づいています。
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.
これらの機能の使用は直交であるため、同じ強度値は両方の機能のニーズを満たす適切なスキームを選択できます。
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を提供するレスポンダーは、512ビットモジュラスと1024ビットモジュラスを備えたスキーム＃2、およびゼロサイズのスキーム＃4を提供する場合があります（＃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ビットモジュラスのみが適切です。システムオペレーターの当事者プライバシーポリシーは、「単純なマスキング」でスキーム＃2を選択するか、「MASK上のDES-CBC」を使用したスキーム＃4を選択するかを示します。
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ビットの強度を必要とすることを示している場合があります。システムオペレーターの当事者プライバシーポリシーは、512ビットモジュラスでスキーム＃2を選択するか、1024ビットモジュラスでスキーム＃4を選択するかを示します。
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とこぼれが不変であるか、特定の交換方向に対して作成されない場合、あまり効果的ではありません。当事者の数は、最初の暗号化されたブロックに違いがある交換数によって明らかにされる可能性があります。
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).
Phil Karnは、主に当事者のプライバシー保護の設計を担当し、デザインの根拠のテキストの多くを提供しました（現在は別の文書に削除されています）。
William Simpson was responsible for the packet formats, and additional Exchange-Schemes, editing and formatting. All such mistakes are his responsibity.
William Simpsonは、パケット形式、および追加の交換スキーム、編集、フォーマットを担当しました。そのような間違いはすべて彼の責任です。
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]のBart PreneelとPaul C van Oorschotは、認証のためにハッシュするときにデータとトレーリングキーの間のパディングを推奨しました。
Niels Provos developed the first implementation with multiple schemes and multiple moduli per scheme (circa July 1997).
Niels Provosは、スキームごとに複数のスキームと複数のモジュリ（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の強化バージョン」、高速ソフトウェア暗号化、第3国際ワークショップ、コンピューターサイエンス1039（1996）、Springer-verlag、71〜82ページ。
See also corrections at ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/bosselae/ripemd/.
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] Whitfield Diffie、Paul C Van Oorshot、およびMichael J Wiener、「認証と認証されたキー交換」、デザイン、コード、暗号化、v 2 pp 107-125、Kluwer Academic Publishers、1992。
[FIPS-180-1] "Secure Hash Standard", National Institute of Standards and Technology, U.S. Department Of Commerce, April 1995.
[FIPS-180-1]「Secure Hash Standard」、国立標準技術研究所、米国商務省、1995年4月。
Also known as: 59 Fed Reg 35317 (1994).
また、59 Fed 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。、「複数の暗号化：セキュリティとパフォーマンスの計量」、Dr。DobbsJournal、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.
[PO96] Bart Preneel、およびPaul C van Oorshot、「2つのMACアルゴリズムのセキュリティについて」、暗号化の進歩 - EuroCrypt '96、コンピューターサイエンス1070（1996年5月）、Springer-Verlag、19-32ページの講義ノート。
[RFC-1829] Karn, P., Metzger, P., Simpson, W., "The ESP DES-CBC Transform", July 1995.
[RFC-1829] Karn、P.、Metzger、P.、Simpson、W。、「ESP Des-CBC Transform」、1995年7月。
[RFC-1850] Karn, P., Metzger, P., Simpson, W., "The ESP Triple DES Transform", September 1995.
[RFC-1850] Karn、P.、Metzger、P.、Simpson、W。、「The Esp Triple des Transform」、1995年9月。
[RFC-1851] Metzger, P., Simpson, W., "IP Authentication using Keyed SHA", September 1995.
[RFC-1851] Metzger、P.、Simpson、W。、「Keyed Shaを使用したIP認証」、1995年9月。
[RFC-2521] Karn, P., and Simpson, W., "ICMP Security Failures Messages", March 1999.
[RFC-2521] Karn、P。、およびSimpson、W。、「ICMPセキュリティ障害メッセージ」、1999年3月。
[RFC-2522] Karn, P., and Simpson, W., "Photuris: Session-Key Management Protocol", March 1999.
[RFC-2522] Karn、P。、およびSimpson、W。、「Phyuris：Session-Key Management Protocol」、1999年3月。
[XEX3] Simpson, W., Baldwin, R., "The ESP DES-XEX3-CBC Transform", Work In Progress, June 1997.
[Xex3] Simpson、W.、Baldwin、R。、「ESP Des-Xex3-CBC Transform」、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
Phil Karn Qualcomm、Inc。6455 Lusk Blvd.カリフォルニア州サンディエゴ92121-2779
karn@qualcomm.com karn@unix.ka9q.ampr.org (preferred)
karn@qualcomm.com karn@unix.ka9q.ampr.org（優先）
William Allen Simpson DayDreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071
ウィリアム・アレン・シンプソン・デイドレーマー・コンピューター・システムコンサルティングサービス1384フォンテーヌ・マディソン・ハイツ、ミシガン州48071
wsimpson@UMich.edu wsimpson@GreenDragon.com (preferred)
wsimpson@umich.edu wsimpson@greendragon.com（優先）
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). Copyright (C) Philip Karn and William Allen Simpson (1994-1999). All Rights Reserved.
Copyright（c）The Internet Society（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.
本書に含まれるこの文書と情報は、「現状のまま」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、本書の情報の使用が保証を含む（ただし、これらに限定されない）すべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害しません。