RFC2522 日本語訳
2522 Photuris: Session-Key Management Protocol. P. Karn, W. Simpson. March 1999. (Format: TXT=157224 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group P. Karn
Request for Comments: 2522 Qualcomm
Category: Experimental W. Simpson
DayDreamer
March 1999
Karnがコメントのために要求するワーキンググループP.をネットワークでつないでください: 2522年のクアルコムカテゴリ: 1999年の実験的なW.シンプソン空想家行進
Photuris: Session-Key Management Protocol
Photuris: セッションKey Managementプロトコル
Status of this Memo
この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.
Copyright(C)インターネット協会(1999)。 Copyright(C)フィリップKarnとウィリアム・アレン・シンプソン(1994-1999)。 All rights reserved。
Abstract
要約
Photuris is a session-key management protocol intended for use with the IP Security Protocols (AH and ESP). This document defines the basic protocol mechanisms.
PhoturisはIPセキュリティー・プロトコル(AHと超能力)との使用のために意図するセッションかぎ管理プロトコルです。 このドキュメントは基本プロトコルメカニズムを定義します。
Karn & Simpson Experimental [Page i] RFC 2522 Photuris Protocol March 1999
KarnとシンプソンExperimental[ページi]RFC2522Photurisプロトコル行進1999
Table of Contents
目次
1. Introduction .......................................... 1
1.1 Terminology ..................................... 1
1.2 Protocol Overview ............................... 3
1.3 Security Parameters ............................. 5
1.4 LifeTimes ....................................... 6
1.4.1 Exchange LifeTimes .............................. 6
1.4.2 SPI LifeTimes ................................... 7
1.5 Random Number Generation ........................ 8
1. 序論… 1 1.1用語… 1 1.2 概観について議定書の中で述べてください… 3 1.3 セキュリティパラメタ… 5 1.4の生涯… 6 1.4 .1 生涯を交換してください… 6 1.4 .2 SPI生涯… 7 1.5乱数発生… 8
2. Protocol Details ...................................... 9
2.1 UDP ............................................. 9
2.2 Header Format ................................... 10
2.3 Variable Precision Integers ..................... 11
2.4 Exchange-Schemes ................................ 13
2.5 Attributes ...................................... 13
2. 詳細について議定書の中で述べてください… 9 2.1UDP… 9 2.2 ヘッダー形式… 10 2.3 可変精度整数… 11 2.4 交換計画… 13 2.5の属性… 13
3. Cookie Exchange ....................................... 14
3.0.1 Send Cookie_Request ............................. 14
3.0.2 Receive Cookie_Request .......................... 15
3.0.3 Send Cookie_Response ............................ 15
3.0.4 Receive Cookie_Response ......................... 16
3.1 Cookie_Request .................................. 17
3.2 Cookie_Response ................................. 18
3.3 Cookie Generation ............................... 19
3.3.1 Initiator Cookie ................................ 19
3.3.2 Responder Cookie ................................ 20
3. クッキー交換… 14 3.0 .1 クッキー_要求を送ってください… 14 3.0 .2 クッキー_要求を受け取ってください… 15 3.0 .3 クッキー_応答を送ってください… 15 3.0 .4 クッキー_応答を受けてください… 16 3.1クッキー_要求… 17 3.2 クッキー_応答… 18 3.3クッキー世代… 19 3.3 .1創始者クッキー… 19 3.3 .2応答者クッキー… 20
4. Value Exchange ........................................ 21
4.0.1 Send Value_Request .............................. 21
4.0.2 Receive Value_Request ........................... 22
4.0.3 Send Value_Response ............................. 22
4.0.4 Receive Value_Response .......................... 23
4.1 Value_Request ................................... 24
4.2 Value_Response .................................. 25
4.3 Offered Attribute List .......................... 26
4. 交換を評価してください… 21 4.0 .1 値_要求を送ってください… 21 4.0 .2 値_要求を受け取ってください… 22 4.0 .3 値_応答を送ってください… 22 4.0 .4 値_応答を受けてください… 23 4.1 _要求を評価してください… 24 4.2 _応答を評価してください… 25 4.3は属性リストを提供しました… 26
5. Identification Exchange ............................... 28
5.0.1 Send Identity_Request ........................... 29
5.0.2 Receive Identity_Request ........................ 29
5.0.3 Send Identity_Response .......................... 30
5.0.4 Receive Identity_Response ....................... 30
5.1 Identity_Messages ............................... 31
5.2 Attribute Choices List .......................... 33
5.3 Shared-Secret ................................... 34
5.4 Identity Verification ........................... 34
5. 識別交換… 28 5.0 .1 アイデンティティ_要求を送ってください… 29 5.0 .2 アイデンティティ_要求を受け取ってください… 29 5.0 .3 アイデンティティ_応答を送ってください… 30 5.0 .4 アイデンティティ_応答を受けてください… 30 5.1 アイデンティティ_メッセージ… 31 5.2 属性選択は記載します… 33 5.3 共有された秘密… 34 5.4 アイデンティティ検証… 34
Karn & Simpson Experimental [Page ii] RFC 2522 Photuris Protocol March 1999
KarnとシンプソンExperimental[ページii]RFC2522Photurisプロトコル行進1999
5.5 Privacy-Key Computation ......................... 36
5.6 Session-Key Computation ......................... 37
5.5のプライバシー主要な計算… 36 5.6のセッション主要な計算… 37
6. SPI Messages .......................................... 38
6.0.1 Send SPI_Needed ................................. 38
6.0.2 Receive SPI_Needed .............................. 39
6.0.3 Send SPI_Update ................................. 39
6.0.4 Receive SPI_Update .............................. 39
6.0.5 Automated SPI_Updates ........................... 40
6.1 SPI_Needed ...................................... 41
6.2 SPI_Update ...................................... 43
6.2.1 Creation ........................................ 44
6.2.2 Deletion ........................................ 45
6.2.3 Modification .................................... 45
6.3 Validity Verification ........................... 45
6. SPIメッセージ… 38 6.0 .1 必要であるSPI_を送ってください… 38 6.0 .2 必要であるSPI_を受けてください… 39 6.0 .3 SPI_アップデートを送ってください… 39 6.0 .4 SPI_アップデートを受けてください… 39 6.0 .5 自動化されたSPI_アップデート… 40 6.1 必要であるSPI_… 41 6.2SPI_アップデート… 43 6.2 .1創造… 44 6.2 .2削除… 45 6.2 .3変更… 45 6.3 正当性検証… 45
7. Error Messages ........................................ 46
7.1 Bad_Cookie ...................................... 47
7.2 Resource_Limit .................................. 47
7.3 Verification_Failure ............................ 48
7.4 Message_Reject .................................. 49
7. エラーメッセージ… 46 7.1の腐っている_クッキー… 47 7.2リソース_限界… 47 7.3 検証_の故障… 48 7.4メッセージ_廃棄物… 49
8. Public Value Exchanges ................................ 50
8.1 Modular Exponentiation Groups ................... 50
8.2 Moduli Selection ................................ 50
8.2.1 Bootstrap Moduli ................................ 51
8.2.2 Learning Moduli ................................. 51
8.3 Generator Selection ............................. 51
8.4 Exponent Selection .............................. 52
8.5 Defective Exchange Values ....................... 53
8. 公衆は交換を評価します… 50 8.1のモジュールの羃法は分類されます… 50 8.2 係数選択… 50 8.2 .1 係数を独力で進んでください… 51 8.2 .2学習係数… 51 8.3 ジェネレータ選択… 51 8.4 解説者選択… 52 8.5 欠陥がある交換価値… 53
9. Basic Exchange-Schemes ................................ 54
9. 基本的な交換計画… 54
10. Basic Key-Generation-Function ......................... 55
10.1 MD5 Hash ........................................ 55
10. 基本的な主要な世代機能… 55 10.1 MD5細切れ肉料理… 55
11. Basic Privacy-Method .................................. 55
11.1 Simple Masking .................................. 55
11. 基本的なプライバシー方法… 55 11.1の簡単なマスキング… 55
12. Basic Validity-Method ................................. 55
12.1 MD5-IPMAC Check ................................. 55
12. 基本的な正当性方法… 55 12.1 MD5-IPMACはチェックします… 55
13. Basic Attributes ...................................... 56
13.1 Padding ......................................... 56
13.2 AH-Attributes ................................... 57
13.3 ESP-Attributes .................................. 57
13.4 MD5-IPMAC ....................................... 58
13.4.1 Symmetric Identification ........................ 58
13. 基本的な属性… 56 13.1 そっと歩きます… 56 13.2、ああ、-、属性、… 57 13.3の超能力属性… 57 13.4MD5-IPMAC… 58 13.4.1 左右対称の識別… 58
Karn & Simpson Experimental [Page iii] RFC 2522 Photuris Protocol March 1999
KarnとシンプソンExperimental[ページiii]RFC2522Photurisプロトコル行進1999
13.4.2 Authentication .................................. 59
13.5 Organizational .................................. 60
13.4.2 認証… 59 13.5 組織的… 60
APPENDICES ................................................... 61
付録… 61
A. Automaton ............................................. 61
A.1 State Transition Table .......................... 62
A.2 States .......................................... 65
A.2.1 Initial ......................................... 65
A.2.2 Cookie .......................................... 66
A.2.3 Value ........................................... 66
A.2.4 Identity ........................................ 66
A.2.5 Ready ........................................... 66
A.2.6 Update .......................................... 66
A.オートマトン… 61 A.1は変遷テーブルを述べます… 62 A.2州… 65 A.2.1初期… 65A.2.2クッキー… 66 A.2.3値… 66 A.2.4のアイデンティティ… 66 A.2.5準備ができる… 66A.2.6アップデート… 66
B. Use of Identification and Secrets ..................... 67
B.1 Identification .................................. 67
B.2 Group Identity With Group Secret ................ 67
B.3 Multiple Identities With Group Secrets .......... 68
B.4 Multiple Identities With Multiple Secrets ....... 69
識別とシークレットのB.使用… 67 B.1識別… 67 B.2はグループ秘密でアイデンティティを分類します… グループシークレットがある67B.3複数のアイデンティティ… 複数のシークレットがある68B.4複数のアイデンティティ… 69
OPERATIONAL CONSIDERATIONS ................................... 70
操作上の問題… 70
SECURITY CONSIDERATIONS ...................................... 70
セキュリティ問題… 70
HISTORY ...................................................... 71
歴史… 71
ACKNOWLEDGEMENTS ............................................. 72
承認… 72
REFERENCES ................................................... 73
参照… 73
CONTACTS ..................................................... 75
連絡します。 75
COPYRIGHT .................................................... 76
著作権… 76
Karn & Simpson Experimental [Page iv] RFC 2522 Photuris Protocol March 1999
KarnとシンプソンExperimental[ページiv]RFC2522Photurisプロトコル行進1999
1. Introduction
1. 序論
Photuris [Firefly] establishes short-lived session-keys between two parties, without passing the session-keys across the Internet. These session-keys directly replace the long-lived secret-keys (such as passwords and passphrases) that have been historically configured for security purposes.
インターネットの向こう側にセッションキーを渡さないで、Photuris[ファイヤーフライ]は2回のパーティーの間の短命なセッションキーを設立します。 これらのセッションキーは直接セキュリティ目的のために歴史的に構成された長命の秘密鍵(パスワードやパスフレーズなどの)を取り替えます。
The basic Photuris protocol utilizes these existing previously configured secret-keys for identification of the parties. This is intended to speed deployment and reduce administrative configuration changes.
基本的なPhoturisプロトコルはパーティーの識別のためのこれらの既存の以前に構成された秘密鍵を利用します。 これは、展開を促進して、管理構成変更を減少させることを意図します。
This document is primarily intended for implementing the Photuris protocol. It does not detail service and application interface definitions, although it does mention some basic policy areas required for the proper implementation and operation of the protocol mechanisms.
このドキュメントは、Photurisプロトコルを実行するために主として意図します。 それはサービスとアプリケーションインターフェース定義を詳しく述べません、いくつかの基本方針領域がプロトコルメカニズムの適切な履行と操作に必要であると言及しますが。
Since the basic Photuris protocol is extensible, new data types and protocol behaviour should be expected. The implementor is especially cautioned not to depend on values that appear in examples to be current or complete, since their purpose is primarily pedagogical.
基本的なPhoturisプロトコルが広げることができるので、新しいデータ型とプロトコルのふるまいは予想されるべきです。 現在である、または完全になるように作成者が例に現れる値に依存しないと特に警告されます、それらの目的が主として教育学であるので。
1.1. Terminology
1.1. 用語
In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC-2119].
そして、このドキュメント、「5月」というキーワードで「必須、「必須NOT」、「任意」の、そして、「お勧め」の“SHOULD"、「」、[RFC-2119]で説明されるように解釈されることになっていてください、」であるべきです
byte An 8-bit quantity; also known as "octet" in
standardese.
バイトのAnの8ビットの量。 また、「八重奏」として、standardeseでは、知られています。
exchange-value The publically distributable value used to calculate
a shared-secret. As used in this document, refers
to a Diffie-Hellman exchange, not the public part of
a public/private key-pair.
publicallyに配置可能な値が共有秘密キーについて計算するのに使用した交換価値。 本書では使用されるように、公衆の公共の部分ではなく、ディフィー-ヘルマンの交換を参照するか、または秘密鍵で対にしてください。
private-key A value that is kept secret, and is part of an
asymmetric public/private key-pair.
秘密にされて、非対称の公立の/秘密鍵組の一部である秘密鍵A価値。
public-key A publically distributable value that is part of an
asymmetric public/private key-pair.
非対称の公立の/秘密鍵組の一部であるA公開カギのpublicallyの配置可能な価値。
secret-key A symmetric key that is not publically
distributable. As used in this document, this is
distinguished from an asymmetric public/private
publicallyに配置可能でない秘密鍵A対称鍵。 本書では使用されるように、これは非対称の公衆/と個人的に区別されます。
Karn & Simpson Experimental [Page 1] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[1ページ]RFC2522Photurisは1999年3月に議定書を作ります。
key-pair. An example is a user password.
主要な組です。 例はユーザパスワードです。
Security Association (SA)
A collection of parameters describing the security
relationship between two nodes. These parameters
include the identities of the parties, the transform
(including algorithm and algorithm mode), the key(s)
(such as a session-key, secret-key, or appropriate
public/private key-pair), and possibly other
information such as sensitivity labelling.
2つのノードの間の安全保障関係について説明するパラメタのセキュリティAssociation(SA)A収集。 これらのパラメタは感度ラベルなどのパーティーのアイデンティティ、変換(アルゴリズムとアルゴリズムモードを含んでいる)、キー(セッション主要であるか、内心主要であるか、適切な公立の/秘密鍵組などの)、およびことによると他の情報を含んでいます。
Security Parameters Index (SPI)
A number that indicates a particular set of uni-
directional attributes used under a Security
Association, such as transform(s) and session-
key(s). The number is relative to the IP
Destination, which is the SPI Owner, and is unique
per IP (Next Header) Protocol. That is, the same
value MAY be used by multiple protocols to
concurrently indicate different Security Association
parameters.
変換(s)とセッションなどのSecurity Associationの下で使用される特定のセットのuniの方向の属性を示すセキュリティParameters Index(SPI)A番号が(s)を合わせます。 数はIP Destinationに比例しています。DestinationはSPI Ownerであり、ユニークな(次のHeader)1IPあたりプロトコルです。 すなわち、同じ値は複数のプロトコルによって使用されて、同時に異なったSecurity Associationパラメタを示すかもしれません。
session-key A key that is independently derived from a shared-
secret by the parties, and used for keying one
direction of traffic. This key is changed
frequently.
パーティーによって共有された秘密から独自に得られて、交通の一方向を合わせるのに使用されるセッション主要なAキー。 頻繁にこのキーを変えます。
shared-secret As used in this document, the calculated result of
the Photuris exchange.
共有秘密キーAsは本書ではPhoturis交換の計算された結果を使用しました。
SPI Owner The party that corresponds to the IP Destination;
the intended recipient of a protected datagram.
IP Destinationに文通するパーティーのSPI Owner。 保護されたデータグラムの意図している受取人。
SPI User The party that corresponds to the IP Source; the
sender of a protected datagram.
IP Sourceに文通するパーティーのSPI User。 保護されたデータグラムの送付者。
transform A cryptographic manipulation of a particular set of
data. As used in this document, refers to certain
well-specified methods (defined elsewhere). For
example, AH-MD5 [RFC-1828] transforms an IP datagram
into a cryptographic hash, and ESP-DES-CBC [RFC-
1829] transforms plaintext to ciphertext and back
again.
特定のデータのA暗号の操作を変えてください。 これでドキュメントを使用して、あるよく指定された方法(ほかの場所では、定義される)を示すので。 例えば、AH-MD5[RFC-1828]はIPデータグラムを暗号の細切れ肉料理に変えます、そして、超能力-DES-CBC[RFC1829]は行き帰り平文を暗号文に変えます。
Karn & Simpson Experimental [Page 2] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[2ページ]RFC2522Photurisは1999年3月に議定書を作ります。
Many of these terms are hierarchically related:
これらの用語の多くが階層的に話されます:
Security Association (bi-directional)
- one or more lists of Security Parameters (uni-directional)
-- one or more Attributes
--- may have a key
--- may indicate a transform
セキュリティAssociation(双方向の)--Security Parameters(uni方向の)の1つ以上のリスト--1Attributes--- キーを持っているかもしれません。--- 変換を示すかもしれません。
Implementors will find details of cryptographic hashing (such as MD5), encryption algorithms and modes (such as DES), digital signatures (such as DSS), and other algorithms in [Schneier95].
作成者は[Schneier95]で暗号の論じ尽くすことの詳細(MD5などの)、暗号化アルゴリズム、モード(DESなどの)、デジタル署名(DSSなどの)、および他のアルゴリズムを見つけるでしょう。
1.2. Protocol Overview
1.2. プロトコル概観
The Photuris protocol consists of several simple phases:
Photurisプロトコルはいくつかの簡単なフェーズから成ります:
1. A "Cookie" Exchange guards against simple flooding attacks sent
with bogus IP Sources or UDP Ports. Each party passes a "cookie"
to the other.
1. 「クッキー」ExchangeはにせのIPのSourcesかUDP Portsと共に送られた簡単なフラッディング攻撃に用心します。 各当事者は「クッキー」をもう片方に通過します。
In return, a list of supported Exchange-Schemes are offered by the
Responder for calculating a shared-secret.
代わりに、サポートしているExchange-体系のリストは、共有秘密キーについて計算するためにResponderによって提供されます。
2. A Value Exchange establishes a shared-secret between the parties.
Each party passes an Exchange-Value to the other. These values
are used to calculate a shared-secret. The Responder remains
stateless until a shared-secret has been created.
2. Value Exchangeはパーティーの間の共有秘密キーを確立します。 各当事者はExchange-値をもう片方に通過します。 これらの値は、共有秘密キーについて計算するのに使用されます。 共有秘密キーが作成されるまで、Responderは状態がないままで残っています。
In addition, supported attributes are offered by each party for
use in establishing new Security Parameters.
さらに、サポートしている属性は新しいSecurity Parametersを設立することにおける使用のために各当事者によって提供されます。
3. An Identification Exchange identifies the parties to each other,
and verifies the integrity of values sent in phases 1 and 2.
3. Identification Exchangeは互いにパーティーを特定して、フェーズ1と2で送られた値の保全について確かめます。
In addition, the shared-secret provides a basis to generate
separate session-keys in each direction, which are in turn used
for conventional authentication or encryption. Additional
security attributes are also exchanged as needed.
さらに、共有秘密キーは各方向への従来の認証か暗号化に順番に使用される別々のセッションキーを生成する基礎を提供します。 また、必要に応じて追加担保属性を交換します。
This exchange is masked for party privacy protection using a
message privacy-key based on the shared-secret. This protects the
identities of the parties, hides the Security Parameter attribute
values, and improves security for the exchange protocol and
security transforms.
共有秘密キーに基づいてプライバシー主要なメッセージを使用することでこの交換はパーティープライバシー保護のためにマスクをかけられます。 これは、パーティーのアイデンティティを保護して、Security Parameter属性値を隠して、交換プロトコルのためにセキュリティを向上させます、そして、セキュリティは変形します。
4. Additional messages may be exchanged to periodically change the
session-keys, and to establish new or revised Security Parameters.
4. 定期的にセッションキーを変えて、新しいか改訂されたSecurity Parametersを証明するために追加メッセージを交換するかもしれません。
Karn & Simpson Experimental [Page 3] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[3ページ]RFC2522Photurisは1999年3月に議定書を作ります。
These exchanges are also masked for party privacy protection in
the same fashion as above.
また、これらの交換は上の同じファッションにおけるパーティープライバシー保護のためにマスクをかけられます。
The sequence of message types and their purposes are summarized in the diagram below. The first three phases (cookie, exchange, and identification) must be carried out in their entirety before any Security Association can be used.
メッセージタイプの系列と彼らの目的は以下のダイヤグラムでまとめられます。 どんなSecurity Associationも使用できる前に最初の三相(クッキー、交換、および識別)を全体として行わなければなりません。
Initiator Responder
========= =========
Cookie_Request ->
<- Cookie_Response
offer schemes
Value_Request ->
pick scheme
offer value
offer attributes
<- Value_Response
offer value
offer attributes
創始者応答者========= ========= クッキー_Request-><クッキー_Response申し出体系Value_Request->は値_Responseが提供する体系申し出値の申し出属性<に値の申し出属性を選びます。
[generate shared-secret from exchanged values]
[交換された値からの共有秘密キーを生成します]
Identity_Request ->
make SPI
pick SPI attribute(s)
identify self
authenticate
make privacy key(s)
mask/encrypt message
<- Identity_Response
make SPI
pick SPI attribute(s)
identify self
authenticate
make privacy key(s)
mask/encrypt message
アイデンティティ_Request->造のSPI選択SPI属性が自己を特定する、認証、プライバシーキーがアイデンティティ_ResponseがSPI選択SPI属性に特定させる<自己がプライバシーキーがマスクをかけるか、または暗号化する造を認証するというメッセージをマスクをかけるか、または暗号化するのを作ってください、メッセージ
[make SPI session-keys in each direction]
[SPIをそれぞれのセッションキー方向にします]
Karn & Simpson Experimental [Page 4] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[4ページ]RFC2522Photurisは1999年3月に議定書を作ります。
SPI User SPI Owner
======== =========
SPI_Needed ->
list SPI attribute(s)
make validity key
authenticate
make privacy key(s)
mask/encrypt message
<- SPI_Update
make SPI
pick SPI attribute(s)
make SPI session-key(s)
make validity key
authenticate
make privacy key(s)
mask/encrypt message
SPIユーザSPI所有者======== ========= 正当性キーが必要な->リストSPI属性で認証するSPI_はプライバシーキーがUpdateがSPIにSPIセッション主要な(s)が正当性キーに認証させる(s)SPI属性を選ばせるSPI_がプライバシーキーがメッセージをマスクをかけるか、または暗号化するのをさせるというメッセージ<をマスクをかけるか、または暗号化するのをさせます。
Either party may initiate an exchange at any time. For example, the Initiator need not be a "caller" in a telephony link.
何れの当事者はいつでも、交換を起こすかもしれません。 例えば、Initiatorは電話リンクの「訪問者」である必要はありません。
The Initiator is responsible for recovering from all message losses by retransmission.
Initiatorは「再-トランスミッション」によるすべてのメッセージの損失から回復するのに責任があります。
1.3. Security Parameters
1.3. セキュリティパラメタ
A Photuris exchange between two parties results in a pair of SPI values (one in each direction). Each SPI is used in creating separate session-key(s) in each direction.
2回のパーティーの間のPhoturis交換は1組のSPI値(各方向への1)をもたらします。 各SPIは別々のセッション主要な(s)を各方向に作成する際に使用されます。
The SPI is assigned by the entity controlling the IP Destination: the SPI Owner (receiver). The parties use the combination of IP Destination, IP (Next Header) Protocol, and SPI to distinguish the correct Security Association.
SPIはIP Destinationを制御する実体によって割り当てられます: SPI所有者(受信機)。 パーティーは、正しいSecurity Associationを区別するのにIP Destinationの組み合わせ、IP(次のHeader)プロトコル、およびSPIを使用します。
When both parties initiate Photuris exchanges concurrently, or one party initiates more than one Photuris exchange, the Initiator Cookies (and UDP Ports) keep the exchanges separate. This results in more than one initial SPI for each Destination.
双方が同時にPhoturis交換を起こすか、または1回のパーティーが1回以上のPhoturis交換を起こすとき、Initiator Cookies(そして、UDP Ports)は交換を別々に保ちます。 これは各Destinationあたり1初期のSPIをもたらします。
To create multiple SPIs with different parameters, the parties may also send SPI_Updates.
また、異なったパラメタがある複数のSPIsを作成するために、パーティーはSPI_Updatesを送るかもしれません。
There is no requirement that all such outstanding SPIs be used. The SPI User (sender) selects an appropriate SPI for each datagram transmission.
そのようなすべての傑出しているSPIsが使用されるという要件が全くありません。 SPI User(送付者)はそれぞれのデータグラムトランスミッションのために適切なSPIを選択します。
Karn & Simpson Experimental [Page 5] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[5ページ]RFC2522Photurisは1999年3月に議定書を作ります。
Implementation Notes:
実装注意:
The method used for SPI assignment is implementation dependent.
The only requirement is that the SPI be unique for the IP
Destination and IP (Next Header) Protocol.
SPI課題に使用されるメソッドは実装に依存しています。 唯一の要件はIP DestinationとIP(次のHeader)プロトコルに、SPIがユニークであるということです。
However, selection of a cryptographically random SPI value can
help prevent attacks that depend on a predicatable sequence of
values. The implementor MUST NOT expect SPI values to have a
particular order or range.
しかしながら、選択、暗号で、無作為のSPIが評価する、値の叙述可能系列に依存する攻撃を防ぐのを助けることができます。 作成者は、SPI値が特定のオーダーを持っているか、または及ぶと予想してはいけません。
1.4. LifeTimes
1.4. 生涯
The Photuris exchange results in two kinds of state, each with separate LifeTimes.
Photuris交換はそれぞれ別々のLifeTimesと共に2種類の状態をもたらします。
1) The Exchange LifeTime of the small amount of state associated with
the Photuris exchange itself. This state may be viewed as between
Internet nodes.
1) 少量の状態のExchange LifeTimeはPhoturis交換自体と交際しました。 この状態はインターネット接続装置のように見られるかもしれません。
2) The SPI LifeTimes of the individual SPIs that are established.
This state may be viewed as between users and nodes.
2) 設立される個々のSPIsのSPI LifeTimes。 この状態はユーザとノードのように見られるかもしれません。
The SPI LifeTimes may be shorter or longer than the Exchange LifeTime. These LifeTimes are not required to be related to each other.
SPI LifeTimesはExchange LifeTimeよりさらに短いか、または長いかもしれません。 これらのLifeTimesによって互いに関連される必要はありません。
When an Exchange-Value expires (or is replaced by a newer value), any unexpired derived SPIs are not affected. This is important to allow traffic to continue without interruption during new Photuris exchanges.
Exchange-値が期限が切れるとき(または、より新しい値に取り替えます)、どんな満期になっていない派生しているSPIsも影響を受けません。 これは、トラフィックが新しいPhoturis交換の間、間断ない続けているのを許容するために重要です。
1.4.1. Exchange LifeTimes
1.4.1. 生涯を交換してください。
All retained exchange state of both parties has an associated Exchange LifeTime (ELT), and is subject to periodic expiration. This depends on the physical and logistical security of the machine, and is typically in the range of 10 minutes to one day (default 30 minutes).
双方のすべての保有された交換状態が、関連Exchange LifeTime(ELT)を持って、周期的な満了を受けることがあります。 これは、マシンの物理的でロジスティクスのセキュリティによって、通常10分から1日(30分間のデフォルト)の範囲にあります。
In addition, during a Photuris exchange, an Exchange TimeOut (ETO) limits the wait for the exchange to complete. This timeout includes the packet round trips, and the time for completing the Identification Exchange calculations. The time is bounded by both the maximum amount of calculation delay expected for the processing power of an unknown peer, and the minimum user expectation for
さらに、Photuris交換の間、Exchange TimeOut(ETO)は交換が終了する待ちを制限します。 このタイムアウトはパケット周遊旅行、およびIdentification Exchange計算を終了するための時間を含んでいます。 時間は最大が処理能力のために未知の同輩に予想された計算遅れ、および最小のユーザ期待を達させる両方で境界があります。
Karn & Simpson Experimental [Page 6] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[6ページ]RFC2522Photurisは1999年3月に議定書を作ります。
results (default 30 seconds).
結果(30秒のデフォルト)。
These Exchange LifeTimes and TimeOuts are implementation dependent and are not disclosed in any Photuris message. The paranoid operator will have a fairly short Exchange LifeTime, but it MUST NOT be less than twice the ETO.
これらのExchange LifeTimesとTimeOutsは実装に依存していて、どんなPhoturisメッセージでも明らかにされません。 パラノイアのオペレータはかなり短いExchange LifeTimeを持つでしょうが、それはETOの2倍未満であるはずがありません。
To prevent synchronization between Photuris exchanges, the implementation SHOULD randomly vary each Exchange LifeTime within twice the range of seconds that are required to calculate a new Exchange-Value. For example, when the Responder uses a base ELT of 30 minutes, and takes 10 seconds to calculate the new Exchange-Value, the equation might be (in milliseconds):
Photuris交換の間の同期を防ぐために、実装SHOULDは手当たりしだいに新しいExchange-値について計算するのに必要である秒の範囲の2倍の中の各Exchange LifeTimeを変えます。 Responderが30分のベースELTを使用して、新しいExchange-値について計算するために10秒取るとき、例えば、方程式は取るかもしれません(ミリセカンドで):
1790000 + urandom(20000)
1790000 + urandom(20000)
The Exchange-Scheme, Exchange-Values, and resulting shared-secret MAY be cached in short-term storage for the Exchange LifeTime. When repetitive Photuris exchanges occur between the same parties, and the Exchange-Values are discovered to be unchanged, the previously calculated shared-secret can be used to rapidly generate new session-keys.
Exchange-体系、Exchange-値、および結果として起こる共有秘密キーはExchange LifeTimeのために短期的なストレージでキャッシュされるかもしれません。 反復性のPhoturis交換が同じパーティーの間に起こって、Exchange-値が変わりがないと発見されるとき、急速に新しいセッションキーを生成するのに以前に計算された共有秘密キーは使用できます。
1.4.2. SPI LifeTimes
1.4.2. SPI生涯
Each SPI has an associated LifeTime, specified by the SPI owner (receiver). This SPI LifeTime (SPILT) is usually related to the speed of the link (typically 2 to 30 minutes), but it MUST NOT be less than thrice the ETO.
各SPIはSPI所有者(受信機)によって指定された関連LifeTimeを持っています。 通常、このSPI LifeTime(SPILT)にリンクの速度に関連しますが(通常2〜30分)、それはETOの3倍より少ないはずがありません。
The SPI can also be deleted by the SPI Owner using the SPI_Update. Once the SPI has expired or been deleted, the parties cease using the SPI.
また、SPI Ownerは、SPI_Updateを使用することでSPIを削除できます。 SPIがいったん吐き出されるか、または削除されると、パーティーは、SPIを使用するのをやめます。
To prevent synchronization between multiple Photuris exchanges, the implementation SHOULD randomly vary each SPI LifeTime. For example, when the Responder uses a base SPILT of 5 minutes, and 30 seconds for the ETO, the equation might be (in milliseconds):
複数のPhoturis交換の間の同期を防ぐために、実装SHOULDは手当たりしだいに各SPI LifeTimeを変えます。 例えば、ResponderがETOに5分、および30秒のベースSPILTを使用すると、方程式は使用するかもしれません(ミリセカンドで):
285000 + urandom(30000)
285000 + urandom(30000)
There is no requirement that a long LifeTime be accepted by the SPI User. The SPI User might never use an established SPI, or cease using the SPI at any time.
長いLifeTimeがSPI Userによって受け入れられるという要件が全くありません。 SPI Userは、確立したSPIを使用しないか、いつでもSPIを使用するのを決してやめないかもしれません。
When more than one unexpired SPI is available to the SPI User for the same function, a common implementation technique is to select the SPI
同じ機能に、1満期になっていないSPIがSPI Userに利用可能であるときに、一般的な実装のテクニックはSPIを選択することです。
Karn & Simpson Experimental [Page 7] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[7ページ]RFC2522Photurisは1999年3月に議定書を作ります。
with the greatest remaining LifeTime. However, selecting randomly among a large number of SPIs might provide some defense against traffic analysis.
最もすばらしい残っているLifeTimeと共に。 しかしながら、多くのSPIsの中で手当たりしだいに選択するのはトラヒック分析に対して何らかのディフェンスを提供するかもしれません。
To prevent resurrection of deleted or expired SPIs, SPI Owners SHOULD remember those SPIs, but mark them as unusable until the Photuris exchange shared-secret used to create them also expires and purges the associated state.
削除されたか満期のSPIsの復活を防ぐために、SPI Owners SHOULDはそれらのSPIsを覚えていますが、また、共有秘密キーが彼らを作成するのに使用したPhoturis交換が準国家を吐き出して、掃除するまで、使用不可能であるとして彼らをマークします。
When the SPI Owner detects an incoming SPI that has recently expired, but the associated exchange state has not yet been purged, the implementation MAY accept the SPI. The length of time allowed is highly dependent on clock drift and variable packet round trip time, and is therefore implementation dependent.
SPI Ownerが最近期限が切れた入って来るSPIを検出しますが、関連交換状態がまだ掃除されていないとき、実装はSPIを受け入れるかもしれません。 日限の長さは、時計ドリフトと可変パケット周遊旅行時間に非常に依存していて、したがって、実装に依存しています。
1.5. Random Number Generation
1.5. 乱数発生
The security of Photuris critically depends on the quality of the secret random numbers generated by each party. A poor random number generator at either party will compromise the shared-secret produced by the algorithm.
Photurisのセキュリティは批判的に各当事者によって生成された秘密の乱数の品質に依存します。 何れの当事者の不十分な乱数発生器はアルゴリズムで作り出された共有秘密キーに感染するでしょう。
Generating cryptographic quality random numbers on a general purpose computer without hardware assistance is a very tricky problem. In general, this requires using a cryptographic hashing function to "distill" the entropy from a large number of semi-random external events, such as the timing of key strokes. An excellent discussion can be found in [RFC-1750].
汎用計算機の上でハードウェア支援なしで暗号の品質が無作為の数であると生成するのは、非常に扱いにくい問題です。 一般に、これは、多くの準無作為の外部のイベントからエントロピーを「蒸留すること」に暗号の論じ尽くす機能を使用するのを必要とします、キーストロークのタイミングなどのように。 [RFC-1750]で素晴らしい議論を見つけることができます。
Karn & Simpson Experimental [Page 8] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[8ページ]RFC2522Photurisは1999年3月に議定書を作ります。
2. Protocol Details
2. プロトコルの詳細
The Initiator begins a Photuris exchange under several circumstances:
Initiatorはいくつかの状況の下でのPhoturis交換を始めます:
- The Initiator has a datagram that it wishes to send with
confidentiality, and has no current Photuris exchange state with
the IP Destination. This datagram is discarded, and a
Cookie_Request is sent instead.
- Initiatorはそれが秘密性と共に送りたがっているデータグラムを持っていて、IP Destinationがあるどんな現在のPhoturis交換状態も持っていません。 このデータグラムは捨てます、そして、代わりにCookie_Requestを送ります。
- The Initiator has received the ICMP message [RFC-1812] Destination
Unreachable: Communication Administratively Prohibited (Type 3,
Code 13), and has no current Photuris exchange state with the ICMP
Source.
- InitiatorはICMPメッセージ[RFC-1812]目的地Unreachableを受けました: コミュニケーションAdministratively Prohibited、(3、Code13)をタイプして、ICMP Sourceがあるどんな現在のPhoturis交換状態も持っていません。
- The Initiator has received the ICMP message [RFC-2521] Security
Failures: Bad SPI (Type 40, Code 0), that matches current Photuris
exchange state with the ICMP Source.
- InitiatorはICMPメッセージ[RFC-2521]セキュリティFailuresを受けました: 悪いSPI(Code0、40をタイプする)、それは現在のPhoturis交換状態をICMP Sourceに合わせます。
- The Initiator has received the ICMP message [RFC-2521] Security
Failures: Need Authentication (Type 40, Code 4), and has no
current Photuris exchange state with the ICMP Source.
- InitiatorはICMPメッセージ[RFC-2521]セキュリティFailuresを受けました: Authentication(Code4、40をタイプする)を必要として、ICMP Sourceがあるどんな現在のPhoturis交換状態も持っていません。
- The Initiator has received the ICMP message [RFC-2521] Security
Failures: Need Authorization (Type 40, Code 5), that matches
current Photuris exchange state with the ICMP Source.
- InitiatorはICMPメッセージ[RFC-2521]セキュリティFailuresを受けました: 認可を要してください、そして、(Code5、40をタイプしてください)それは現在のPhoturis交換状態をICMP Sourceに合わせます。
When the event is an ICMP message, special care MUST be taken that the ICMP message actually includes information that matches a previously sent IP datagram. Otherwise, this could provide an opportunity for a clogging attack, by stimulating a new Photuris Exchange.
イベントがICMPメッセージ、特別な注意を払わなければならないということであるときに、ICMPが通信するのが実際に以前に送られたIPデータグラムに合っている情報を含んでいます。 さもなければ、これは、新しいPhoturis Exchangeを刺激することによって、目詰まり攻撃に機会を与えるかもしれません。
2.1. UDP
2.1. UDP
All Photuris messages use the User Datagram Protocol header [RFC- 768]. The Initiator sends to UDP Destination Port 468.
すべてのPhoturisメッセージがユーザー・データグラム・プロトコルヘッダー[RFC768]を使用します。 InitiatorはUDP Destination Port468に発信します。
When replying to the Initiator, the Responder swaps the IP Source and Destination, and the UDP Source and Destination Ports.
Initiatorに答えるとき、ResponderはIPのSource、Destination、UDP Source、およびDestination Portsを交換します。
The UDP checksum MUST be correctly calculated when sent. When a message is received with an incorrect UDP checksum, it is silently discarded.
送ると、正しくUDPチェックサムについて計算しなければなりません。 不正確なUDPチェックサムでメッセージを受け取るとき、静かにそれを捨てます。
Karn & Simpson Experimental [Page 9] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[9ページ]RFC2522Photurisは1999年3月に議定書を作ります。
Implementation Notes:
実装注意:
It is expected that installation of Photuris will ensure that UDP
checksum calculations are enabled for the computer operating
system and later disabling by operators is prevented.
Photurisのインストールが、計算がコンピュータオペレーティングシステムのために可能にされて、後でオペレータで無効にするUDPチェックサムが防がれるのを確実にすると予想されます。
Internet Protocol version 4 [RFC-791] restricts the maximum
reassembled datagram to 576 bytes.
インターネットプロトコルバージョン4[RFC-791]は最大の組み立て直されたデータグラムを576バイトに制限します。
When processing datagrams containing variable size values, the
length must be checked against the overall datagram length. An
invalid size (too long or short) that causes a poorly coded
receiver to abort could be used as a denial of service attack.
可変サイズ値を含むデータグラムを処理するとき、総合的なデータグラムの長さに対して長さをチェックしなければなりません。 サービス不能攻撃として不十分にコード化された受信機が中止になる無効のサイズ(長過ぎるか短い)は使用できました。
2.2. Header Format
2.2. ヘッダー形式
All of the messages have a format similar to the following, as transmitted left to right in network order (most significant to least significant):
メッセージのすべてが左に伝えられるようにネットワークオーダー(最も重要でなく最も重要な)における右に以下と同様の形式を持っています:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Initiator-Cookie ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Responder-Cookie ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message | +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 創始者クッキー~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 応答者クッキー~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージ| +-+-+-+-+-+-+-+-+
Initiator-Cookie 16 bytes.
創始者クッキー16バイト。
Responder-Cookie 16 bytes.
応答者クッキー16バイト。
Message 1 byte. Each message type has a unique value.
Initial values are assigned as follows:
メッセージ1バイト。 それぞれのメッセージタイプには、ユニークな値があります。 初期の値は以下の通り割り当てられます:
Karn & Simpson Experimental [Page 10] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[10ページ]RFC2522Photurisは1999年3月に議定書を作ります。
0 Cookie_Request
1 Cookie_Response
2 Value_Request
3 Value_Response
4 Identity_Request
5 Secret_Response (optional)
6 Secret_Request (optional)
7 Identity_Response
8 SPI_Needed
9 SPI_Update
10 Bad_Cookie
11 Resource_Limit
12 Verification_Failure
13 Message_Reject
0 クッキー_要求1クッキー_応答2値_要求3値_応答4アイデンティティ_要求5秘密の(任意)の_の秘密の_要求(任意)の7応答6アイデンティティ_応答8SPI_は腐っている_クッキー11リソース_限界12検証_失敗13メッセージ_が拒絶する9SPI_アップデート10を必要としました。
Further details and differences are elaborated in the individual messages.
詳細と違いは個々のメッセージに詳しく説明されます。
2.3. Variable Precision Integers
2.3. 可変精度整数
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Size | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サイズ| 値… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Size 2, 4, or 8 bytes. The number of significant bits
used in the Value field. Always transmitted most
significant byte first.
サイズ2、4、または8バイト。 Value分野で使用される重要なビットの数。 最初に、ほとんどの重要なバイトいつも伝えられます。
When the Size is zero, no Value field is present;
there are no significant bits. This means "missing"
or "null". It should not be confused with the value
zero, which includes an indication of the number of
significant bits.
Sizeがゼロであるときに、どんなValue分野も存在していません。 どんな重要なビットもありません。 これは「なくなるかヌルであること」を意味します。 それは値ゼロに混乱するべきではありません。(それは、重要なビットの数のしるしを含んでいます)。
When the most significant byte is in the range 0
through 254 (0xfe), the field is 2 bytes. Both
bytes are used to indicate the size of the Value
field, which ranges from 1 to 65,279 significant
bits (in 1 to 8,160 bytes).
最も重要なバイトが範囲に0〜254(0xfe)にあるとき、分野は2バイトです。 両方のバイトは、重要な1〜6万5279ビット(1〜8,160バイトにおける)まで変化するValue分野のサイズを示すのに使用されます。
When the most significant byte is 255 (0xff), the
field is 4 bytes. The remaining 3 bytes are added
to 65,280 to indicate the size of the Value field,
which is limited to 16,776,959 significant bits (in
最も重要なバイトが255(0xff)であるときに、分野は4バイトです。 中残っている3バイトが重要な1677万6959ビットに制限されるValue分野のサイズを示すために6万5280に加えられる、(。
Karn & Simpson Experimental [Page 11] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[11ページ]RFC2522Photurisは1999年3月に議定書を作ります。
2,097,120 bytes).
209万7120バイト)
When the most significant 2 bytes are 65,535
(0xffff), the field is 8 bytes. The remaining 6
bytes are added to 16,776,960 to indicate the size
of the Value field.
最も重要な2バイトが6万5535(0xffff)であるときに、分野は8バイトです。 残っている6バイトは、Value分野のサイズを示すために1677万6960に加えられます。
Value 0 or more bytes. Always transmitted most
significant byte first.
0バイト以上を評価してください。 最初に、ほとんどの重要なバイトいつも伝えられます。
The bits used are right justified within byte
boundaries; that is, any unused bits are in the most
significant byte. When there are no unused bits, or
unused bits are zero filled, the value is assumed to
be an unsigned positive integer.
使用されるビットはバイト境界の中でまさしく正当です。 最も重要なバイトにはすなわちどんな未使用のビットもあります。 どんな未使用のビットもないか、未使用のビットがいっぱいにされたゼロであるときに、値は無記名の正の整数であると思われます。
When the leading unused bits are ones filled, the
number is assumed to be a two's-complement negative
integer. A negative integer will always have at
least one unused leading sign bit in the most
significant byte.
主な未使用のビットがいっぱいにされたものであるときに、数は2補数の負の整数であると思われます。 負の整数には、最も重要なバイトにおける少なくとも1つの未使用の主な符号ビットがいつもあるでしょう。
Shortened forms SHOULD NOT be used when the Value includes a number of leading zero significant bits. The Size SHOULD indicate the correct number of significant bits.
短縮形SHOULD NOT、Valueが多くの先行ゼロ重要なビットを含んでいたら、使用されてください。 Size SHOULDは重要なビットの適度の数を示します。
Implementation Notes:
実現注意:
Negative integers are not required to be supported, but are
included for completeness.
負の整数は、支持されるのが必要ではありませんが、完全性のために含まれています。
No more than 65,279 significant bits are required to be supported.
Other ranges are vastly too long for these UDP messages, but are
included for completeness.
重要な6万5279ビット未満が、支持されるのに必要です。 他の範囲は、これらのUDPメッセージには広大に長過ぎますが、完全性のために含まれています。
Karn & Simpson Experimental [Page 12] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[12ページ]RFC2522Photurisは1999年3月に議定書を作ります。
2.4. Exchange-Schemes
2.4. 交換計画
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scheme | Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 計画| サイズ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 値… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Scheme 2 bytes. A unique value indicating the Exchange-
Scheme. See the "Basic Exchange-Schemes" for
details.
2バイトを計画してください。 Exchange計画について簡単に述べるユニークな値。 詳細の「基本的な交換計画」を見てください。
Size 2 bytes, ranging from 0 to 65,279. See "Variable
Precision Integer".
0〜6万5279まで及ぶ2バイトのサイズ。 「可変精度整数」を見てください。
Value 0 or more bytes. See "Variable Precision Integer".
0バイト以上を評価してください。 「可変精度整数」を見てください。
The Size MUST NOT be assumed to be constant for a particular Scheme. Multiple kinds of the same Scheme with varying Sizes MAY be present in any list of schemes.
Sizeが特定のSchemeに一定であると思われてはいけません。 異なったSizesと同じ複数の種類のSchemeは計画のどんなリストにも存在しているかもしれません。
However, only one of each Scheme and Size combination will be present in any list of schemes.
しかしながら、それぞれのSchemeとSize組み合わせの1つだけが計画のどんなリストにも存在するでしょう。
2.5. Attributes
2.5. 属性
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute | Length | Value(s) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 属性| 長さ| 値… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute 1 byte. A unique value indicating the kind of
attribute. See the "Basic Attributes" for details.
1バイトを結果と考えてください。 属性の種類を示すユニークな値。 詳細に関して「基本的な属性」を見てください。
When the value is zero (padding), no Length field is
present (always zero).
値がゼロ(そっと歩く)であるときに、どんなLength分野も存在していません(いつもゼロ)。
Length 1 byte. The size of the Value(s) field in bytes.
1バイトの長さ。 バイトで表現されるValue(s)分野のサイズ。
When the Length is zero, no Value(s) field is
present.
Lengthがゼロであるときに、どんなValue(s)分野も存在していません。
Value(s) 0 or more bytes. See the "Basic Attributes" for
details.
(s) 0バイト以上を評価してください。 詳細に関して「基本的な属性」を見てください。
The Length MUST NOT be assumed to be constant for a particular
Lengthが事項に一定であると思われてはいけません。
Karn & Simpson Experimental [Page 13] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[13ページ]RFC2522Photurisは1999年3月に議定書を作ります。
Attribute. Multiple kinds of the same Attribute with varying Lengths MAY be present in any list of attributes.
結果と考えます。 異なったLengthsと同じ複数の種類のAttributeは属性のどんなリストにも存在しているかもしれません。
3. Cookie Exchange
3. クッキー交換
Initiator Responder
========= =========
Cookie_Request ->
<- Cookie_Response
offer schemes
創始者応答者========= ========= クッキー_Request-><クッキー_Responseは計画を提供します。
3.0.1. Send Cookie_Request
3.0.1. クッキー_要求を送ってください。
The Initiator initializes local state, and generates a unique "cookie". The Initiator-Cookie MUST be different in each new Cookie_Request between the same parties. See "Cookie Generation" for details.
Initiatorは地方の状態を初期化して、ユニークな「クッキー」を発生させます。 Initiator-クッキーは同じパーティーの間のそれぞれの新しいCookie_Requestで異なっているに違いありません。 詳細のための「クッキー世代」を見てください。
- If any previous exchange between the peer IP nodes has not expired
in which this party was the Initiator, this Responder-Cookie is
set to the most recent Responder-Cookie, and this Counter is set
to the corresponding Counter.
- 同輩IPノードの間のこのパーティーがInitiatorであった前の交換が少しの期限が切れていないなら、このResponder-クッキーは最新のResponder-クッキーに設定されます、そして、このCounterは対応するCounterに用意ができています。
For example, a new Virtual Private Network (VPN) tunnel is about
to be established to an existing partner. The Counter is the same
value received in the prior Cookie_Response, the Responder-Cookie
remains the same, and a new Initiator-Cookie is generated.
例えば、新しいVirtual兵士のNetwork(VPN)トンネルは既存のパートナーに確立されようとしています。 Counterは先のCookie_Responseの同じ対価領収です、そして、Responder-クッキーは同じままで残っています、そして、新しいInitiator-クッキーは発生します。
- If the new Cookie_Request is in response to a message of a
previous exchange in which this party was the Responder, this
Responder-Cookie is set to the previous Initiator-Cookie, and this
Counter is set to zero.
- 新しいCookie_RequestがこのパーティーがResponderであった前の交換に関するメッセージに対応しているなら、このResponder-クッキーは前のInitiator-クッキーに設定されます、そして、このCounterはゼロに用意ができています。
For example, a Bad_Cookie message was received from the previous
Initiator in response to SPI_Needed. The Responder-Cookie is
replaced with the Initiator-Cookie, and a new Initiator-Cookie is
generated. This provides bookkeeping to detect bogus Bad_Cookie
messages.
例えば、必要であるSPI_に対応して前のInitiatorからBad_Cookieメッセージを受け取りました。 Responder-クッキーをInitiator-クッキーに取り替えます、そして、新しいInitiator-クッキーを発生させます。 これは、にせのBad_Cookieメッセージを検出するために簿記を提供します。
Also, can be used for bi-directional User, Transport, and Process
oriented keying. Such mechanisms are outside the scope of this
document.
また、双方向のUser、Transport、Processの指向のおよび合わせるのに使用できます。 このドキュメントの範囲の外にそのようなメカニズムがあります。
- Otherwise, this Responder-Cookie and Counter are both set to zero.
- さもなければ、このResponder-クッキーとCounterはともにゼロに用意ができています。
Karn & Simpson Experimental [Page 14] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[14ページ]RFC2522Photurisは1999年3月に議定書を作ります。
By default, the Initiator operates in the same manner as when all
of its previous exchange state has expired. The Responder will
send a Resource_Limit when its own exchange state has not expired.
デフォルトで、Initiatorは前の交換状態のすべてが期限が切れた時と同じ方法で作動します。 それ自身の交換状態が期限が切れていないとき、ResponderはResource_Limitを送るでしょう。
The Initiator also starts a retransmission timer. If no valid Cookie_Response arrives within the time limit, the same Cookie_Request is retransmitted for the remaining number of Retransmissions. The Initiator-Cookie value MUST be the same in each such retransmission to the same IP Destination and UDP Port.
また、Initiatorは再送信タイマーを始動します。 どんな有効なCookie_Responseもタイムリミットの中で到着しないなら、同じCookie_RequestはRetransmissionsの残っている数のために再送されます。 Initiator-クッキー値はそのような各「再-トランスミッション」で同じIPのDestinationとUDP Portと同じであるに違いありません。
When Retransmissions have been exceeded, if a Resource_Limit message has been received during the exchange, the Initiator SHOULD begin the Photuris exchange again by sending a new Cookie_Request with updated values.
交換の間、Resource_Limitメッセージを受け取っているならRetransmissionsを超えていたとき、Initiator SHOULDは、再びアップデートされた値で新しいCookie_Requestを送ることによって、Photuris交換を始めます。
3.0.2. Receive Cookie_Request
3.0.2. クッキー_要求を受け取ってください。
On receipt of a Cookie_Request, the Responder determines whether there are sufficient resources to begin another Photuris exchange.
Cookie_Requestを受け取り次第、Responderは、別のPhoturis交換を始まることができるくらいのリソースがあるかどうか決定します。
- When too many SPI values are already in use for this particular
peer, or too many concurrent exchanges are in progress, or some
other resource limit is reached, a Resource_Limit message is sent.
- この特定の同輩には、あまりに多くのSPI値が既に使用中であるか、あまりに多くの同時発生の交換が進行しているか、またはある他のリソース限界に達しているとき、Resource_Limitメッセージを送ります。
- When any previous exchange initiated by this particular peer has
not exceeded the Exchange TimeOut, and the Responder-Cookie does
not specify one of these previous exchanges, a Resource_Limit
message is sent.
- いずれでもあるときに、この特定の同輩によって起こされた前の交換はExchange TimeOutを超えていません、そして、Responder-クッキーはこれらの前の交換の1つを指定しません、そして、Resource_Limitメッセージを送ります。
Otherwise, the Responder returns a Cookie_Response.
さもなければ、ResponderはCookie_Responseを返します。
Note that the Responder creates no additional state at this time.
Responderがこのときどんな追加状態も創設しないことに注意してください。
3.0.3. Send Cookie_Response
3.0.3. クッキー_応答を送ってください。
The IP Source for the Initiator is examined. If any previous exchange between the peer IP nodes has not expired, the response Counter is set to the most recent exchange Counter plus one (allowing for out of order retransmissions). Otherwise, the response Counter is set to the request Counter plus one.
InitiatorのためのIP Sourceは調べられます。 同輩IPノードの間の前の交換が少しの期限が切れていないなら、応答Counterは最新の交換Counterと1つに用意ができています(故障している「再-トランスミッション」を考慮します)。 さもなければ、応答Counterは要求Counterと1つに用意ができています。
If (through rollover of the Counter) the new Counter value is zero (modulo 256), the value is set to one.
(Counterのロールオーバーを通した)新しいCounter価値がゼロ(法256)であるなら、値は1つに設定されます。
If this new Counter value matches some previous exchange initiated by this particular peer that has not yet exceeded the Exchange TimeOut,
この新しいCounter値がこの特定の同輩によって起こされた前の何らかの交換に合っているなら、それはまだExchange TimeOutを超えていません。
Karn & Simpson Experimental [Page 15] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[15ページ]RFC2522Photurisは1999年3月に議定書を作ります。
the Counter is incremented again, until a unique Counter value is reached.
ユニークなCounter値に達するまで、Counterは再び増加されます。
Nota Bene:
No more than 254 concurrent exchanges between the same two peers
are supported.
背板嘆願: 同じ2人の同輩の間の254回未満の同時発生の交換が支持されます。
The Responder generates a unique cookie. The Responder-Cookie value in each successive response SHOULD be different. See "Cookie Generation" for details.
Responderはユニークなクッキーを発生させます。 Responder-クッキーはそれぞれの連続した応答でSHOULDを評価します。異なってください。 詳細のための「クッキー世代」を見てください。
The Exchange-Schemes available between the peers are listed in the Offered-Schemes.
同輩の間で利用可能なExchange-計画はOffered-計画で記載されています。
3.0.4. Receive Cookie_Response
3.0.4. クッキー_応答を受けてください。
The Initiator validates the Initiator-Cookie, and the Offered- Schemes.
InitiatorはInitiator-クッキー、およびOffered計画を有効にします。
- When an invalid/expired Initiator-Cookie is detected, the message
is silently discarded.
- 無効の、または、満期のInitiator-クッキーが検出されるとき、メッセージは静かに捨てられます。
- When the variable length Offered-Schemes do not match the UDP
Length, or all Offered-Schemes are obviously defective and/or
insufficient for the purposes intended, the message is silently
discarded; the implementation SHOULD log the occurance, and notify
an operator as appropriate.
- すべてのOffered-計画が意図する目的のために可変長Offered-計画がUDP Lengthに合っていないか、明らかに欠陥がある、そして/または、不十分であるときに、メッセージは静かに捨てられます。 実現SHOULDはoccuranceを登録して、適宜オペレータに通知します。
- Once a valid message has been received, later Cookie_Responses
with matching Initiator-Cookies are also silently discarded, until
a new Cookie_Request is sent.
- 一度、有効なメッセージを受け取ったことがあります、また、静かに合っているInitiator-クッキーがある後のCookie_Responsesを捨てます、新しいCookie_Requestを送るまで。
When the message is valid, an Exchange-Scheme is chosen from the list of Offered-Schemes.
メッセージが有効であるときに、Exchange-計画はOffered-計画のリストから選ばれています。
This Scheme-Choice may affect the next Photuris message sent. By default, the next Photuris message is a Value_Request.
このScheme-選択はメッセージが送った次のPhoturisに影響するかもしれません。 デフォルトで、次のPhoturisメッセージはValue_Requestです。
Implementation Notes:
実現注意:
Only the Initiator-Cookie is used to identify the exchange. The
Counter and Responder-Cookie will both be different from the
Cookie_Request.
Initiator-クッキーだけが、交換を特定するのに使用されます。 CounterとResponder-クッキーはCookie_Requestとともに異なるでしょう。
Various proposals for extensions utilize the Scheme-Choice to
indicate a different message sequence. Such mechanisms are
outside the scope of this document.
拡大のための様々な提案は、異なったメッセージ系列を示すのにScheme-選択を利用します。 このドキュメントの範囲の外にそのようなメカニズムがあります。
Karn & Simpson Experimental [Page 16] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[16ページ]RFC2522Photurisは1999年3月に議定書を作ります。
3.1. Cookie_Request
3.1. クッキー_要求
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Initiator-Cookie ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Responder-Cookie ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message | Counter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 創始者クッキー~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 応答者クッキー~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージ| カウンタ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Initiator-Cookie 16 bytes. A randomized value that identifies the
exchange. The value MUST NOT be zero. See "Cookie
Generation" for details.
創始者クッキー16バイト。 交換を特定するランダマイズされた値。 値はゼロであるはずがありません。 詳細のための「クッキー世代」を見てください。
Responder-Cookie 16 bytes. Identifies a specific previous exchange.
Copied from a previous Cookie_Response.
応答者クッキー16バイト。 前の特定の交換を特定します。 前のCookie_Responseから、コピーされます。
When zero, no previous exchange is specified.
ゼロであるときに、前の交換は全く指定されません。
When non-zero, and the Counter is zero, contains the
Initiator-Cookie of a previous exchange. The
specified party is requested to be the Responder in
this exchange, to retain previous party pairings.
非ゼロである、Counterはゼロであり、前の交換のInitiator-クッキーを含んでいます。 この交換におけるResponderであり、指定されたパーティーが前のパーティー組み合わせを保有するよう要求されています。
When non-zero, and the Counter is also non-zero,
contains the Responder-Cookie of a previous
exchange. The specified party is requested to be
the Responder in this exchange, to retain previous
party pairings.
非ゼロである、Counterはまた、非ゼロに合わせて、前の交換のResponder-クッキーを含んでいます。 この交換におけるResponderであり、指定されたパーティーが前のパーティー組み合わせを保有するよう要求されています。
Message 0
メッセージ0
Counter 1 byte. Indicates the number of previous exchanges.
1バイトを打ち返してください。 前の交換の数を示します。
When zero, the Responder-Cookie indicates the
Initiator of a previous exchange, or no previous
exchange is specified.
ゼロであるときに、Responder-クッキーは、前の交換にもかかわらず、前の交換がないInitiatorが指定されるのを示します。
When non-zero, the Responder-Cookie indicates the
Responder to a previous exchange. This value is set
to the Counter from the corresponding
Cookie_Response or from a Resource_Limit.
非ゼロであるときに、Responder-クッキーは前の交換にResponderを示します。 この値は対応するCookie_ResponseかResource_LimitからのCounterに設定されます。
Karn & Simpson Experimental [Page 17] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[17ページ]RFC2522Photurisは1999年3月に議定書を作ります。
3.2. Cookie_Response
3.2. クッキー_応答
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Initiator-Cookie ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Responder-Cookie ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message | Counter | Offered-Schemes ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 創始者クッキー~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 応答者クッキー~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージ| カウンタ| 提供された計画… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Initiator-Cookie 16 bytes. Copied from the Cookie_Request.
創始者クッキー16バイト。 クッキー_要求から、コピーされます。
Responder-Cookie 16 bytes. A randomized value that identifies the
exchange. The value MUST NOT be zero. See "Cookie
Generation" for details.
応答者クッキー16バイト。 交換を特定するランダマイズされた値。 値はゼロであるはずがありません。 詳細のための「クッキー世代」を見てください。
Message 1
メッセージ1
Counter 1 byte. Indicates the number of the current
exchange. Must be greater than zero.
1バイトを打ち返してください。 現在の交換の数を示します。 ゼロ以上にならなければならなくなってください。
Offered-Schemes 4 or more bytes. A list of one or more Exchange-
Schemes supported by the Responder, ordered from
most to least preferable. See the "Basic Exchange-
Schemes" for details.
提供された計画4バイト以上。 大部分から最も望ましくならないまで注文されたResponderによって支持された1つ以上のExchange計画のリスト。 詳細の「基本的な交換計画」を見てください。
Only one Scheme (#2) is required to be supported,
and SHOULD be present in every Offered-Schemes list.
1Scheme(#2)だけが支持されるのに必要である、SHOULD、あらゆるOffered-計画リストに存在してください。
More than one of each kind of Scheme may be offered,
but each is distinguished by its Size. The end of
the list is indicated by the UDP Length.
各種類のSchemeの1つ以上を提供するかもしれませんが、Sizeはそれぞれを区別します。 リストの終わりはUDP Lengthによって示されます。
Karn & Simpson Experimental [Page 18] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[18ページ]RFC2522Photurisは1999年3月に議定書を作ります。
3.3. Cookie Generation
3.3. クッキー世代
The exact technique by which a Photuris party generates a cookie is implementation dependent. The method chosen must satisfy some basic requirements:
Photurisパーティーがクッキーを発生させる正確なテクニックは実現に依存しています。 選ばれた方法はいくつかの基本的な要件を満たさなければなりません:
1. The cookie MUST depend on the specific parties. This prevents an
attacker from obtaining a cookie using a real IP address and UDP
port, and then using it to swamp the victim with requests from
randomly chosen IP addresses or ports.
1. クッキーは特定のパーティーに頼らなければなりません。 これによって、攻撃者は本当のIPアドレスとUDPポートを使用して、次に、手当たりしだいに選ばれたIPアドレスかポートからの要求で犠牲者を圧倒するのにそれを使用することでクッキーを入手できません。
2. It MUST NOT be possible for anyone other than the issuing entity
to generate cookies that will be accepted by that entity. This
implies that the issuing entity will use local secret information
in the generation and subsequent verification of a cookie. It
must not be possible to deduce this secret information from any
particular cookie.
2. 発行実体以外のだれでもその実体によって受け入れられるクッキーを発生させるのは、可能であるはずがありません。 これは、発行実体がクッキーの世代とその後の検証にローカルの秘密の情報を使用するのを含意します。 どんな特定のクッキーからのこの秘密の情報も推論するのは可能であるはずがありません。
3. The cookie generation and verification methods MUST be fast to
thwart attacks intended to sabotage CPU resources.
3. クッキー世代と検証方法はCPUリソースを故意に妨害することを意図する攻撃を阻むのにおいて速いに違いありません。
A recommended technique is to use a cryptographic hashing function (such as MD5).
お勧めのテクニックは暗号の論じ尽くす機能(MD5などの)を使用することです。
An incoming cookie can be verified at any time by regenerating it locally from values contained in the incoming datagram and the local secret random value.
いつでも、受信データグラムに含まれた値と地方の秘密の無作為の値からそれを局所的に作り直すことによって、入って来るクッキーについて確かめることができます。
3.3.1. Initiator Cookie
3.3.1. 創始者クッキー
The Initiator secret value that affects its cookie SHOULD change for each new Photuris exchange, and is thereafter internally cached on a per Responder basis. This provides improved synchronization and protection against replay attacks.
新しいPhoturis交換毎にクッキーSHOULD変化に影響して、その後Responder基礎あたりのaで内部的にキャッシュされるInitiatorの秘密の値。 これは反射攻撃に対する改良された同期と保護を提供します。
An alternative is to cache the cookie instead of the secret value. Incoming cookies can be compared directly without the computational cost of regeneration.
代替手段は秘密の値の代わりにクッキーをキャッシュすることです。 直接再生のコンピュータの費用なしで入って来るクッキーを比較できます。
It is recommended that the cookie be calculated over the secret value, the IP Source and Destination addresses, and the UDP Source and Destination ports.
クッキーが秘密の値、IP Source、Destinationアドレス、UDP Source、およびDestinationポートの上で計算されるのは、お勧めです。
Karn & Simpson Experimental [Page 19] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[19ページ]RFC2522Photurisは1999年3月に議定書を作ります。
Implementation Notes:
実現注意:
Although the recommendation includes the UDP Source port, this is
very implementation specific. For example, it might not be
included when the value is constant.
推薦はUDP Sourceポートを含んでいますが、これは実現非常に特有です。 値が一定であるときに、例えば、それは含まれないかもしれません。
However, it is important that the implementation protect mutually
suspicious users of the same machine from generating the same
cookie.
しかしながら、実現が同じクッキーを発生させるのから同じマシンの互いに疑わしげなユーザを保護するのは、重要です。
3.3.2. Responder Cookie
3.3.2. 応答者クッキー
The Responder secret value that affects its cookies MAY remain the same for many different Initiators. However, this secret SHOULD be changed periodically to limit the time for use of its cookies (typically each 60 seconds).
クッキーに影響するResponderの秘密の値は多くの異なったInitiatorsに同じままで残るかもしれません。 しかしながらこれほど秘密のSHOULD、定期的に変えて、クッキー(通常各60秒)の使用のための時間を制限してください。
The Responder-Cookie SHOULD include the Initiator-Cookie. The Responder-Cookie MUST include the Counter (that is returned in the Cookie_Response). This provides improved synchronization and protection against replay attacks.
Responder-クッキーSHOULDはInitiator-クッキーを含んでいます。 Responder-クッキーはCounter(すなわち、Cookie_Responseでは、返す)を含まなければなりません。 これは反射攻撃に対する改良された同期と保護を提供します。
It is recommended that the cookie be calculated over the secret value, the IP Source and Destination addresses, its own UDP Destination port, the Counter, the Initiator-Cookie, and the currently Offered-Schemes.
そして、クッキーが秘密の値、IP Source、およびDestinationアドレスに関して計算されるのは、お勧めです、それ自身のUDP Destinationポート、Counter、Initiator-クッキー、現在のOffered-計画。
The cookie is not cached per Initiator to avoid saving state during the initial Cookie Exchange. On receipt of a Value_Request (described later), the Responder regenerates its cookie for validation.
クッキーは、初期のCookie Exchangeの間、状態を節約するのを避けるためにInitiator単位でキャッシュされません。 Value_Request(後で説明される)を受け取り次第、Responderは合法化のためにクッキーを作り直します。
Once the Value_Response is sent (also described later), both Initiator and Responder cookies are cached to identify the exchange.
いったんValue_Responseを送ると(また、後で説明されます)、交換を特定するためにInitiatorとResponderクッキーの両方をキャッシュします。
Implementation Notes:
実現注意:
Although the recommendation does not include the UDP Source port,
this is very implementation specific. It might be successfully
included in some variants.
推薦はUDP Sourceポートを含んでいませんが、これは実現非常に特有です。 それはいくつかの異形に首尾よく含まれるかもしれません。
However, it is important that the UDP Source port not be included
when matching existing Photuris exchanges for determining the
appropriate Counter.
しかしながら、Photurisが適切なCounterを決定すると交換する存在に合っているとき、UDP Sourceポートが含まれていないのは、重要です。
The recommendation includes the Offered-Schemes to detect a
dynamic change of scheme value between the Cookie_Response and
そして推薦がCookie_Responseの間の計画価値のaダイナミックな変化を検出するためにOffered-計画を含んでいる。
Karn & Simpson Experimental [Page 20] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[20ページ]RFC2522Photurisは1999年3月に議定書を作ります。
Value_Response.
_応答を評価してください。
Some mechanism MAY be needed to detect a dynamic change of pre-
calculated Responder Exchange-Value between the Value_Response and
Identity_Response. For example, change the secret value to render
the cookie invalid, or explicitly mark the Photuris exchange state
as expired.
何らかのメカニズムが、Value_ResponseとIdentity_Responseの間のあらかじめ計算されたResponder Exchange-価値のダイナミックな変化を検出するのに必要であるかもしれません。 例えば、クッキーを無効にするために秘密の値を変えるか、または吐き出されるようにPhoturis交換が状態であると明らかにマークしてください。
4. Value Exchange
4. 値の交換
Initiator Responder
========= =========
Value_Request ->
pick scheme
offer value
offer attributes
<- Value_Response
offer value
offer attributes
創始者応答者========= ========= 値の_Request->は値_Responseが提供する計画申し出値の申し出属性<に値の申し出属性を選びます。
[generate shared-secret from exchanged values]
[交換された値から共有秘密キーを発生させます]
4.0.1. Send Value_Request
4.0.1. 値_要求を送ってください。
The Initiator generates an appropriate Exchange-Value for the Scheme-Choice. This Exchange-Value may be pre-calculated and used for multiple Responders.
InitiatorはScheme-選択のために適切なExchange-値を発生させます。 このExchange-値は、あらかじめ計算されて、複数のRespondersに使用されるかもしれません。
The IP Destination for the Responder is examined, and the attributes available between the parties are listed in the Offered-Attributes.
ResponderのためのIP Destinationは調べられます、そして、パーティーの間で利用可能な属性はOffered-属性で記載されています。
The Initiator also starts a retransmission timer. If no valid Value_Response arrives within the time limit, the same Value_Request is retransmitted for the remaining number of Retransmissions.
また、Initiatorは再送信タイマーを始動します。 どんな有効なValue_Responseもタイムリミットの中で到着しないなら、同じValue_RequestはRetransmissionsの残っている数のために再送されます。
When Retransmissions have been exceeded, if a Bad_Cookie or Resource_Limit message has been received during the exchange, the Initiator SHOULD begin the Photuris exchange again by sending a new Cookie_Request.
交換の間、Bad_CookieかResource_Limitメッセージを受け取っているならRetransmissionsを超えていたとき、Initiator SHOULDは、再び新しいCookie_Requestを送ることによって、Photuris交換を始めます。
Karn & Simpson Experimental [Page 21] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[21ページ]RFC2522Photurisは1999年3月に議定書を作ります。
4.0.2. Receive Value_Request
4.0.2. 値_要求を受け取ってください。
The Responder validates the Responder-Cookie, the Counter, the Scheme-Choice, the Exchange-Value, and the Offered-Attributes.
ResponderはResponder-クッキー、Counter、Scheme-選択、Exchange-値、およびOffered-属性を有効にします。
- When an invalid/expired Responder-Cookie is detected, a Bad_Cookie
message is sent.
- 無効の、または、満期のResponder-クッキーを検出するとき、Bad_Cookieメッセージを送ります。
- When too many SPI values are already in use for this particular
peer, or too many concurrent exchanges are in progress, or some
other resource limit is reached, a Resource_Limit message is sent.
- この特定の同輩には、あまりに多くのSPI値が既に使用中であるか、あまりに多くの同時発生の交換が進行しているか、またはある他のリソース限界に達しているとき、Resource_Limitメッセージを送ります。
- When an invalid Scheme-Choice is detected, or the Exchange-Value
is obviously defective, or the variable length Offered-Attributes
do not match the UDP Length, the message is silently discarded;
the implementation SHOULD log the occurance, and notify an
operator as appropriate.
- 無効のScheme-選択が検出されるか、Exchange-値は明らかに欠陥があるか、または可変長Offered-属性がUDP Lengthに合っていないと、メッセージは静かに捨てられます。 実現SHOULDはoccuranceを登録して、適宜オペレータに通知します。
When the message is valid, the Responder sets its Exchange timer to the Exchange TimeOut, and returns a Value_Response.
メッセージが有効であるときに、ResponderはExchangeタイマをExchange TimeOutに設定して、Value_Responseを返します。
The Responder keeps a copy of the incoming Value_Request cookie pair, and its Value_Response. If a duplicate Value_Request is received, it merely resends its previous Value_Response, and takes no further action.
Responderは入って来るValue_Requestクッキー組のコピー、およびそのValue_Responseを取っておきます。 写しValue_Requestが受け取られているなら、それは、単に前のValue_Responseを再送して、さらなる行動を全く取りません。
4.0.3. Send Value_Response
4.0.3. 値_応答を送ってください。
The Responder generates an appropriate Exchange-Value for the Scheme-Choice. This Exchange-Value may be pre-calculated and used for multiple Initiators.
ResponderはScheme-選択のために適切なExchange-値を発生させます。 このExchange-値は、あらかじめ計算されて、複数のInitiatorsに使用されるかもしれません。
The IP Source for the Initiator is examined, and the attributes available between the parties are listed in the Offered-Attributes.
InitiatorのためのIP Sourceは調べられます、そして、パーティーの間で利用可能な属性はOffered-属性で記載されています。
Implementation Notes:
実現注意:
At this time, the Responder begins calculation of the shared-
secret. Calculation of the shared-secret is executed in parallel
to minimize delay.
このとき、Responderは共有された秘密の計算を始めます。 共有秘密キーの計算は、遅れを最小にするために平行で執行されます。
This may take a substantial amount of time. The implementor
should ensure that retransmission is not blocked by this
calculation. This is not usually a problem, as retransmission
timeouts typically exceed calculation time.
これはかなりの時かかるかもしれません。 作成者は、「再-トランスミッション」がこの計算で妨げられないのを保証するべきです。 再送タイムアウトが計算時間を通常超えているとき、通常、これは問題ではありません。
Karn & Simpson Experimental [Page 22] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[22ページ]RFC2522Photurisは1999年3月に議定書を作ります。
4.0.4. Receive Value_Response
4.0.4. 値_応答を受けてください。
The Initiator validates the pair of Cookies, the Exchange-Value, and the Offered-Attributes.
InitiatorはCookiesの組、Exchange-値、およびOffered-属性を有効にします。
- When an invalid/expired cookie is detected, the message is
silently discarded.
- 無効の、または、満期のクッキーが検出されるとき、メッセージは静かに捨てられます。
- When the Exchange-Value is obviously defective, or the variable
length Offered-Attributes do not match the UDP Length, the message
is silently discarded; the implementation SHOULD log the
occurance, and notify an operator as appropriate.
- Exchange-値は明らかに欠陥があるか、または可変長Offered-属性がUDP Lengthに合っていないと、メッセージは静かに捨てられます。 実現SHOULDはoccuranceを登録して、適宜オペレータに通知します。
- Once a valid message has been received, later Value_Responses with
both matching cookies are also silently discarded, until a new
Cookie_Request is sent.
- 一度、有効なメッセージを受け取ったことがあります、また、静かに両方がクッキーに合っている後のValue_Responsesを捨てます、新しいCookie_Requestを送るまで。
When the message is valid, the Initiator begins its parallel computation of the shared-secret.
メッセージが有効であるときに、Initiatorは共有秘密キーの並列計算を始めます。
When the Initiator completes computation, it sends an Identity_Request to the Responder.
Initiatorが計算を終了すると、それはIdentity_RequestをResponderに送ります。
Karn & Simpson Experimental [Page 23] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[23ページ]RFC2522Photurisは1999年3月に議定書を作ります。
4.1. Value_Request
4.1. 値の_要求
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Initiator-Cookie ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Responder-Cookie ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message | Counter | Scheme-Choice | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Initiator-Exchange-Value ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initiator-Offered-Attributes ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 創始者クッキー~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 応答者クッキー~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージ| カウンタ| 計画選択| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 創始者交換価値~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 創始者は属性を提供しました… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Initiator-Cookie 16 bytes. Copied from the Cookie_Response.
創始者クッキー16バイト。 クッキー_応答から、コピーされます。
Responder-Cookie 16 bytes. Copied from the Cookie_Response.
応答者クッキー16バイト。 クッキー_応答から、コピーされます。
Message 2
メッセージ2
Counter 1 byte. Copied from the Cookie_Response.
1バイトを打ち返してください。 クッキー_応答から、コピーされます。
Scheme-Choice 2 bytes. A value selected by the Initiator from the
list of Offered-Schemes in the Cookie_Response.
計画選択2バイト。 Cookie_ResponseでInitiatorによってOffered-計画のリストから選択された値。
Only the Scheme is specified; the Size will match
the Initiator-Exchange-Value, and the Value(s) are
implicit.
Schemeだけが指定されます。 SizeはInitiator交換価値に合うでしょう、そして、Value(s)は内在しています。
Initiator-Exchange-Value
Variable Precision Integer. Provided by the
Initiator for calculating a shared-secret between
the parties. The Value format is indicated by the
Scheme-Choice.
創始者交換価値の可変精度整数。 Initiatorによってパーティーの間で共有秘密キーについて計算するのに提供されます。 Value書式はScheme-選択で示されます。
The field may be any integral number of bytes in
length, as indicated by its Size field. It does not
require any particular alignment. The 32-bit
alignment shown is for convenience in the
illustration.
長さはSize分野によって示されるように分野がどんな整数のバイトであるかもしれません。 それは少しの特定の整列も必要としません。 示された32ビットの整列はイラストにおける便宜のためのものです。
Karn & Simpson Experimental [Page 24] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[24ページ]RFC2522Photurisは1999年3月に議定書を作ります。
Initiator-Offered-Attributes
4 or more bytes. A list of Security Parameter
attributes supported by the Initiator.
創始者の提供された属性4バイト以上。 Initiatorによって支持されたSecurity Parameter属性のリスト。
The contents and usage of this list are further
described in "Offered Attributes List". The end of
the list is indicated by the UDP Length.
このリストのコンテンツと使用法は「提供された属性は記載するところ」でさらに説明されます。 リストの終わりはUDP Lengthによって示されます。
4.2. Value_Response
4.2. 値_応答
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Initiator-Cookie ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Responder-Cookie ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Responder-Exchange-Value ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Responder-Offered-Attributes ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 創始者クッキー~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 応答者クッキー~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージ| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 応答者交換価値~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 応答者は属性を提供しました… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Initiator-Cookie 16 bytes. Copied from the Value_Request.
創始者クッキー16バイト。 値_要求から、コピーされます。
Responder-Cookie 16 bytes. Copied from the Value_Request.
応答者クッキー16バイト。 値_要求から、コピーされます。
Message 3
メッセージ3
Reserved 3 bytes. For future use; MUST be set to zero when
transmitted, and MUST be ignored when received.
予約された3バイト。 今後の使用のために。 伝えるとゼロに設定しなければならなくて、受け取ると、無視しなければなりません。
Responder-Exchange-Value
Variable Precision Integer. Provided by the
Responder for calculating a shared-secret between
the parties. The Value format is indicated by the
current Scheme-Choice specified in the
Value_Request.
応答者交換価値の可変精度整数。 Responderによってパーティーの間で共有秘密キーについて計算するのに提供されます。 Value書式はValue_Requestで指定された現在のScheme-選択で示されます。
The field may be any integral number of bytes in
分野は中のどんな不可欠のバイト数であるかもしれません。
Karn & Simpson Experimental [Page 25] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[25ページ]RFC2522Photurisは1999年3月に議定書を作ります。
length, as indicated by its Size field. It does not
require any particular alignment. The 32-bit
alignment shown is for convenience in the
illustration.
Size分野によって示されるような長さ。 それは少しの特定の整列も必要としません。 示された32ビットの整列はイラストにおける便宜のためのものです。
Responder-Offered-Attributes
4 or more bytes. A list of Security Parameter
attributes supported by the Responder.
応答者の提供された属性4バイト以上。 Responderによって支持されたSecurity Parameter属性のリスト。
The contents and usage of this list are further
described in "Offered Attributes List". The end of
the list is indicated by the UDP Length.
このリストのコンテンツと使用法は「提供された属性は記載するところ」でさらに説明されます。 リストの終わりはUDP Lengthによって示されます。
4.3. Offered Attribute List
4.3. 提供された属性リスト
This list includes those attributes supported by the party that are available to the other party. The attribute formats are specified in the "Basic Attributes".
このリストは相手にとって、手があいているパーティーによって支持されたそれらの属性を含んでいます。 属性形式は「基本的な属性」で指定されます。
The list is composed of two or three sections: Identification- Attributes, Authentication-Attributes, and (optional) Encapsulation- Attributes. Within each section, the attributes are ordered from most to least preferable.
リストは2つのセクションか3つのセクションで構成されます: 識別属性、認証属性、および(任意)のカプセル化属性。 各セクションの中では、属性は大部分から最も望ましくならないまで命令されます。
The first section of the list includes methods of identification. An Identity-Choice is selected from this list.
リストの最初のセクションは識別の方法を含んでいます。 Identity-選択はこのリストから選択されます。
The second section of the list begins with "AH-Attributes" (#1). It includes methods of authentication, and other operational types.
リストの第2セクションが始まる、「ああ、-、属性、」 (#1。) それは認証の方法、および他の操作上のタイプを含んでいます。
The third section of the list begins with "ESP-Attributes" (#2). It includes methods of authentication, compression, encryption, and other operational types. When no Encapsulation-Attributes are offered, the "ESP-Attributes" attribute itself is omitted from the list.
リストの第3セクションは「超能力属性」(#2)で始まります。 それは認証、圧縮、暗号化、および他の操作上のタイプの方法を含んでいます。 Encapsulation-属性を全く提供しないとき、リストから「超能力属性」属性自体を省略します。
Attribute-Choices are selected from the latter two sections of the list.
属性選択はリストの後者の2つのセクションから選択されます。
Support is required for the "MD5-IPMAC" (#5) attribute for both "Symmetric Identification" and "Authentication" and they SHOULD be present in every Offered-Attributes list.
サポートが「左右対称の識別」と「認証」の両方のための"MD5-IPMAC"(#5)属性に必要です、そして、それらはあらゆる提供された属性リストに存在しているべきです。
Karn & Simpson Experimental [Page 26] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[26ページ]RFC2522Photurisは1999年3月に議定書を作ります。
Implementation Notes:
実現注意:
For example,
例えば
"MD5-IPMAC" (Symmetric Identification),
"AH-Attributes",
"MD5-IPMAC" (Authentication).
"MD5-IPMAC"(左右対称の識別)、「ああ、-、属性、」、"MD5-IPMAC"(認証)。
Since the offer is made by the prospective SPI User (sender),
order of preference likely reflects the capabilities and
engineering tradeoffs of a particular implementation.
申し出が将来のSPI User(送付者)によってされるので、よく使われる順はおそらく特定の実現の能力と工学見返りを反映します。
However, the critical processing bottlenecks are frequently in the
receiver. The SPI Owner (receiver) may express its needs by
choosing a less preferable attribute.
しかしながら、批判的な処理ボトルネックが頻繁に受信機にあります。SPI Owner(受信機)は、それほど望ましくない属性を選ぶことによって、必要性を述べるかもしれません。
The order may also be affected by operational policy and requested
services for an application. Such considerations are outside the
scope of this document.
また、オーダーはアプリケーションのための運用政策と要求されたサービスで影響を受けるかもしれません。 このドキュメントの範囲の外にそのような問題があります。
The list may be divided into additional sections. These sections
will always follow the ESP-Attributes section, and are
indistinguishable from unrecognized attributes.
リストは追加セクションに分割されるかもしれません。 これらのセクションは、いつも超能力属性部に続いて、認識されていない属性から区別がつきません。
The authentication, compression, encryption and identification
mechanisms chosen, as well as the encapsulation modes (if any),
need not be the same in both directions.
カプセル化モード(もしあれば)と同様に選ばれた認証、圧縮、暗号化、および識別メカニズムは両方の方向と同じである必要はありません。
Karn & Simpson Experimental [Page 27] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[27ページ]RFC2522Photurisは1999年3月に議定書を作ります。
5. Identification Exchange
5. 識別交換
Initiator Responder
========= =========
Identity_Request ->
make SPI
pick SPI attribute(s)
identify self
authenticate
make privacy key(s)
mask/encrypt message
<- Identity_Response
make SPI
pick SPI attribute(s)
identify self
authenticate
make privacy key(s)
mask/encrypt message
創始者応答者========= ========= アイデンティティ_Request->造のSPI選択SPI属性が自己を特定する、認証、プライバシーキーがアイデンティティ_ResponseがSPI選択SPI属性に特定させる<自己がプライバシーキーがマスクをかけるか、またはコード化する造を認証するというメッセージをマスクをかけるか、またはコード化するのを作ってください、メッセージ
[make SPI session-keys in each direction]
[SPIをそれぞれのセッション重要方向にします]
The exchange of messages is ordered, although the formats and meanings of the messages are identical in each direction. The messages are easily distinguished by the parties themselves, by examining the Message and Identification fields.
メッセージの形式と意味は各方向と同じですが、メッセージの交換は命令されます。 メッセージは、パーティー自体、MessageとIdentification分野を調べることによって、容易に区別されます。
Implementation Notes:
実現注意:
The amount of time for the calculation may be dependent on the
value of particular bits in secret values used in generating the
shared-secret or identity verification. To prevent analysis of
these secret bits by recording the time for calculation, sending
of the Identity_Messages SHOULD be delayed until the time expected
for the longest calculation. This will be different for different
processor speeds, different algorithms, and different length
variables. Therefore, the method for estimating time is
implementation dependent.
計算のための時間は共有秘密キーかアイデンティティ検証を発生させる際に使用される秘密の値における、特定のビットの価値に依存しているかもしれません。 Identity_Messages SHOULDを発信させて、計算のための時間を記録することによってこれらの秘密のビットの分析を防ぐには、最も長い計算のために予想された時間まで遅れてください。 これは異なったプロセッサ速度、異なったアルゴリズム、および異なった長さの変数において異なるようになるでしょう。 したがって、推計時間の方法は実現に依存しています。
Any authenticated and/or encrypted user datagrams received before
the completion of identity verification can be placed on a queue
pending completion of this step. If verification succeeds, the
queue is processed as though the datagrams had arrived subsequent
to the verification. If verification fails, the queue is
discarded.
いずれも、このステップの完成までアイデンティティ検証の完成を待ち行列に置くことができる前に受け取られたユーザデータグラムを、認証する、そして/または、コード化しました。 検証が成功するなら、まるでデータグラムが検証にその後で届いたかのように待ち行列は処理されます。 検証が失敗するなら、待ち行列は捨てられます。
Karn & Simpson Experimental [Page 28] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[28ページ]RFC2522Photurisは1999年3月に議定書を作ります。
5.0.1. Send Identity_Request
5.0.1. アイデンティティ_要求を送ってください。
The Initiator chooses an appropriate Identification, the SPI and SPILT, a set of Attributes for the SPI, calculates the Verification, and masks the message using the Privacy-Method indicated by the current Scheme-Choice.
Initiatorが適切なIdentification、SPIを選んで、SPILT(SPIのためのAttributesの1セット)は、Verificationについて計算して、現在のScheme-選択で示されたPrivacy-方法を使用することでメッセージにマスクをかけます。
The Initiator also starts a retransmission timer. If no valid Identity_Response arrives within the time limit, its previous Identity_Request is retransmitted for the remaining number of Retransmissions.
また、Initiatorは再送信タイマーを始動します。 どんな有効なIdentity_Responseもタイムリミットの中で到着しないなら、前のIdentity_RequestはRetransmissionsの残っている数のために再送されます。
When Retransmissions have been exceeded, if a Bad_Cookie message has been received during the exchange, the Initiator SHOULD begin the Photuris exchange again by sending a new Cookie_Request.
交換の間、Bad_Cookieメッセージを受け取っているならRetransmissionsを超えていたとき、Initiator SHOULDは、再び新しいCookie_Requestを送ることによって、Photuris交換を始めます。
5.0.2. Receive Identity_Request
5.0.2. アイデンティティ_要求を受け取ってください。
The Responder validates the pair of Cookies, the Padding, the Identification, the Verification, and the Attribute-Choices.
ResponderはCookies、Padding、Identification、Verification、およびAttribute-選択の組を有効にします。
- When an invalid/expired cookie is detected, a Bad_Cookie message
is sent.
- 無効の、または、満期のクッキーを検出するとき、Bad_Cookieメッセージを送ります。
- After unmasking, when invalid Padding is detected, the variable
length Attribute-Choices do not match the UDP Length, or an
attribute was not in the Offered-Attributes, the message is
silently discarded.
- 無効のPaddingが検出されたか、可変長Attribute-選択がUDP Lengthに合っていないか、または属性がOffered-属性になかったとき暴露した後に、メッセージは静かに捨てられます。
- When an invalid Identification is detected, or the message
verification fails, a Verification_Failure message is sent.
- 無効のIdentificationが検出されるか、またはメッセージ検証が失敗すると、Verification_Failureメッセージを送ります。
- Whenever such a problem is detected, the Security Association is
not established; the implementation SHOULD log the occurance, and
notify an operator as appropriate.
- そのような問題が検出されるときはいつも、Security Associationは設立されません。 実現SHOULDはoccuranceを登録して、適宜オペレータに通知します。
When the message is valid, the Responder sets its Exchange timer to the Exchange LifeTime (if this has not already been done for a previous exchange). When its parallel computation of the shared- secret is complete, the Responder returns an Identity_Response.
メッセージが有効であるときに、ResponderはExchangeタイマをExchange LifeTimeに設定します(前の交換のために既にこれをしていないなら)。 共有された秘密の並列計算が完全であるときに、ResponderはIdentity_Responseを返します。
The Responder keeps a copy of the incoming Identity_Request values, and its Identity_Response. If a duplicate Identity_Request is received, it merely resends its previous Identity_Response, and takes no further action.
Responderは、入って来るIdentityのコピーが_Request値と、そのIdentity_Responseであることを保ちます。 写しIdentity_Requestが受け取られているなら、それは、単に前のIdentity_Responseを再送して、さらなる行動を全く取りません。
Karn & Simpson Experimental [Page 29] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[29ページ]RFC2522Photurisは1999年3月に議定書を作ります。
5.0.3. Send Identity_Response
5.0.3. アイデンティティ_応答を送ってください。
The Responder chooses an appropriate Identification, the SPI and SPILT, a set of Attributes for the SPI, calculates the Verification, and masks the message using the Privacy-Method indicated by the current Scheme-Choice.
Responderが適切なIdentification、SPIを選んで、SPILT(SPIのためのAttributesの1セット)は、Verificationについて計算して、現在のScheme-選択で示されたPrivacy-方法を使用することでメッセージにマスクをかけます。
The Responder calculates the SPI session-keys in both directions.
ResponderはSPIセッションキーについて両方の方向に計算します。
At this time, the Responder begins the authentication and/or encryption of user datagrams.
このとき、Responderはユーザデータグラムの認証、そして/または、暗号化を始めます。
5.0.4. Receive Identity_Response
5.0.4. アイデンティティ_応答を受けてください。
The Initiator validates the pair of Cookies, the Padding, the Identification, the Verification, and the Attribute-Choices.
InitiatorはCookies、Padding、Identification、Verification、およびAttribute-選択の組を有効にします。
- When an invalid/expired cookie is detected, the message is
silently discarded.
- 無効の、または、満期のクッキーが検出されるとき、メッセージは静かに捨てられます。
- After unmasking, when invalid Padding is detected, the variable
length Attribute-Choices do not match the UDP Length, or an
attribute was not in the Offered-Attributes, the message is
silently discarded.
- 無効のPaddingが検出されたか、可変長Attribute-選択がUDP Lengthに合っていないか、または属性がOffered-属性になかったとき暴露した後に、メッセージは静かに捨てられます。
- When an invalid Identification is detected, or the message
verification fails, a Verification_Failure message is sent.
- 無効のIdentificationが検出されるか、またはメッセージ検証が失敗すると、Verification_Failureメッセージを送ります。
- Whenever such a problem is detected, the Security Association is
not established; the implementation SHOULD log the occurance, and
notify an operator as appropriate.
- そのような問題が検出されるときはいつも、Security Associationは設立されません。 実現SHOULDはoccuranceを登録して、適宜オペレータに通知します。
- Once a valid message has been received, later Identity_Responses
with both matching cookies are also silently discarded, until a
new Cookie_Request is sent.
- 一度、有効なメッセージを受け取ったことがあります、また、静かに両方がクッキーに合っている後のIdentity_Responsesを捨てます、新しいCookie_Requestを送るまで。
When the message is valid, the Initiator sets its Exchange timer to the Exchange LifeTime (if this has not already been done for a previous exchange).
メッセージが有効であるときに、InitiatorはExchangeタイマをExchange LifeTimeに設定します(前の交換のために既にこれをしていないなら)。
The Initiator calculates the SPI session-keys in both directions.
InitiatorはSPIセッションキーについて両方の方向に計算します。
At this time, the Initiator begins the authentication and/or encryption of user datagrams.
このとき、Initiatorはユーザデータグラムの認証、そして/または、暗号化を始めます。
Karn & Simpson Experimental [Page 30] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[30ページ]RFC2522Photurisは1999年3月に議定書を作ります。
5.1. Identity_Messages
5.1. アイデンティティ_メッセージ
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Initiator-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Responder-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message | LifeTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security-Parameters-Index |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Identity-Choice | |
+ + + + + + + + + + + + + + + + + +
| |
~ Identification ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Verification ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute-Choices ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 創始者クッキー~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 応答者クッキー~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージ| 生涯| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | セキュリティパラメタインデックス| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | アイデンティティ選択| | + + + + + + + + + + + + + + + + + + | | ~ 識別~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 検証~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 属性選択… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Initiator-Cookie 16 bytes. Copied from the Value_Request.
創始者クッキー16バイト。 値_要求から、コピーされます。
Responder-Cookie 16 bytes. Copied from the Value_Request.
応答者クッキー16バイト。 値_要求から、コピーされます。
Message 4 (Request) or 7 (Response)
メッセージ4(要求します)か7(応答)
LifeTime 3 bytes. The number of seconds remaining before the
indicated SPI expires.
LifeTime3バイト。 示されたSPIの前に残っている秒数は期限が切れます。
When the SPI is zero, this field MUST be filled with
a random non-zero value.
SPIがゼロであるときに、無作為の非ゼロ値でこの分野を満たさなければなりません。
Security-Parameters-Index (SPI)
4 bytes. The SPI to be used for incoming
communications.
セキュリティパラメタインデックス(SPI)4バイト。 入ってくる通信について使用されるべきSPI。
When zero, indicates that no SPI is created in this
ゼロである、SPIが全くこれで作成されないのを示します。
Karn & Simpson Experimental [Page 31] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[31ページ]RFC2522Photurisは1999年3月に議定書を作ります。
direction.
指示。
Identity-Choice 2 or more bytes. An identity attribute is selected
from the list of Offered-Attributes sent by the
peer, and is used to calculate the Verification.
アイデンティティ選択2バイト以上。 アイデンティティ属性は、同輩によって送られたOffered-属性のリストから選択されて、Verificationについて計算するのに使用されます。
The field may be any integral number of bytes in
length, as indicated by its Length field. It does
not require any particular alignment. The 16-bit
alignment shown is for convenience in the
illustration.
長さはLength分野によって示されるように分野がどんな整数のバイトであるかもしれません。 それは少しの特定の整列も必要としません。 示された16ビットの整列はイラストにおける便宜のためのものです。
Identification Variable Precision Integer, or alternative format
indicated by the Identity-Choice. See the "Basic
Attributes" for details.
識別Variable Precision Integer、またはIdentity-選択で示された代替の書式。 詳細に関して「基本的な属性」を見てください。
The field may be any integral number of bytes in
length. It does not require any particular
alignment. The 32-bit alignment shown is for
convenience in the illustration.
分野は長さがどんな不可欠のバイト数であるかもしれません。 それは少しの特定の整列も必要としません。 示された32ビットの整列はイラストにおける便宜のためのものです。
Verification Variable Precision Integer, or alternative format
indicated by the Identity-Choice. The calculation
of the value is described in "Identity
Verification".
検証Variable Precision Integer、またはIdentity-選択で示された代替の書式。 価値の計算は「アイデンティティ検証」で説明されます。
The field may be any integral number of bytes in
length. It does not require any particular
alignment. The 32-bit alignment shown is for
convenience in the illustration.
分野は長さがどんな不可欠のバイト数であるかもしれません。 それは少しの特定の整列も必要としません。 示された32ビットの整列はイラストにおける便宜のためのものです。
Attribute-Choices
0 or more bytes. When the SPI is non-zero, a list
of attributes selected from the list of Offered-
Attributes supported by the peer.
属性選択0バイト以上。 属性のリストは、同輩によって支持されたOffered属性のリストからいつSPIが非ゼロであるかを選択しました。
The contents and usage of this list are further
described in "Attribute Choices List". The end of
the list is indicated by the UDP Length after
removing the Padding (UDP Length - last Padding
value).
このリストのコンテンツと使用法は「属性選択は記載するところ」でさらに説明されます。 Padding(UDP Length--最後のPadding値)を取り外した後に、リストの終わりはUDP Lengthによって示されます。
Padding 8 to 255 bytes. This field is filled up to at least
a 128 byte boundary, measured from the beginning of
the message. The number of pad bytes are chosen
randomly.
8〜255バイトを水増しします。 この分野は少なくともメールの文頭から測定された128バイト境界までいっぱいにされます。 パッドバイトの数は手当たりしだいに選ばれています。
In addition, when a Privacy-Method indicated by the
中、添加、Privacy-方法が示したいつか
Karn & Simpson Experimental [Page 32] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[32ページ]RFC2522Photurisは1999年3月に議定書を作ります。
current Scheme-Choice requires the plaintext to be a
multiple of some number of bytes (the block size of
a block cipher), this field is adjusted as necessary
to the size required by the algorithm.
現在のScheme-選択は、平文が何らかのバイト数の倍数(ブロック暗号のブロック・サイズ)であることを必要として、この分野はアルゴリズムによって必要とされたサイズに必要に応じて調整されます。
Self-Describing-Padding begins with the value 1.
Each byte contains the index of that byte. Thus,
the final pad byte indicates the number of pad bytes
to remove. For example, when the unpadded message
length is 120 bytes, the padding values might be 1,
2, 3, 4, 5, 6, 7, and 8.
そっと歩くと説明する自己が値1で始めます。 各バイトはそのバイトのインデックスを含んでいます。 したがって、最終的なパッドバイトは、取り外すためにパッドバイトの数を示します。 非水増しメッセージ長が120バイトであるときに、例えば、詰め物値は、1と、2と、3と、4と、5と、6と、7と、8であるかもしれません。
The portion of the message after the SPI field is masked using the Privacy-Method indicated by the current Scheme-Choice.
SPI分野の後のメッセージの部分は現在のScheme-選択で示されたPrivacy-方法を使用することにおいて仮面です。
The fields following the SPI are opaque. That is, the values are set prior to masking (and optional encryption), and examined only after unmasking (and optional decryption).
SPIに続く分野は不透明です。 すなわち、値は、マスキング(そして、任意の暗号化)の前に設定されて、暴露した(そして、任意の復号化)後にだけ、調べられます。
5.2. Attribute Choices List
5.2. 属性選択リスト
This list specifies the attributes of the SPI. The attribute formats are specified in the "Basic Attributes".
このリストはSPIの属性を指定します。 属性形式は「基本的な属性」で指定されます。
The list is composed of one or two sections: Authentication- Attributes, and/or Encapsulation-Attributes.
リストは1つのセクションか2つのセクションで構成されます: 認証属性、そして/または、カプセル化属性。
When sending from the SPI User to the SPI Owner, the attributes are processed in the order listed. For example,
SPI UserからSPI Ownerまで発信するとき、属性はリストアップされたオーダーで処理されます。 例えば
"ESP-Attributes",
"Deflate" (Compression),
"XOR" (Encryption),
"DES-CBC" (Encryption),
"XOR" (Encryption),
"AH-Attributes",
"AH-Sequence",
"MD5-IPMAC" (Authentication),
「超能力属性」が(圧縮)、"XOR"(暗号化)、"DES-CBC"(暗号化)"XOR"(暗号化)に「空気を抜かせる」、「ああ、-、属性、」、「ああ、-、系列、」、"MD5-IPMAC"(認証)
would result in ESP with compression and triple encryption (inside), and then AH authentication with sequence numbers (outside) of the ESP payload.
一連番号で圧縮がある超能力と三重の暗号化(inside)をもたらして、次に、(外で超能力ペイロードの)AH認証をもたらすでしょう。
The SPI Owner will naturally process the datagram in the reverse order.
SPI Ownerは自然に逆順でデータグラムを処理するでしょう。
This ordering also affects the order of key generation. Both SPI
また、この注文はキー生成の注文に影響します。 両方、SPI
Karn & Simpson Experimental [Page 33] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[33ページ]RFC2522Photurisは1999年3月に議定書を作ります。
Owner and SPI User generate the keys in the order listed.
所有者とSPI Userはリストアップされたオーダーでキーを発生させます。
Implementation Notes:
実現注意:
When choices are made from the list of Offered-Attributes, it is
not required that any Security Association include every kind of
offered attribute in any single SPI, or that a separate SPI be
created for every offered attribute.
Offered-属性のリストから選択をするとき、どんなSecurity Associationもどんな独身のSPIのあらゆるちょっと提供された属性も含んでいるか、または別々のSPIがあらゆる提供された属性のために作成されるのが必要ではありません。
Some kinds of attributes may be included more than once in a
single SPI. The set of allowable combinations of attributes are
dependent on implementation and operational policy. Such
considerations are outside the scope of this document.
数種類の属性は独身のSPIの一度より含まれるかもしれません。 属性の許容できる組み合わせのセットは実現と運用政策に依存しています。 このドキュメントの範囲の外にそのような問題があります。
The list may be divided into additional sections. This can occur
only when both parties recognize the affected attributes.
リストは追加セクションに分割されるかもしれません。 双方が影響を受ける属性を認識するときだけ、これは起こることができます。
The authentication, compression, encryption and identification
mechanisms chosen, as well as the encapsulation modes (if any),
need not be the same in both directions.
カプセル化モード(もしあれば)と同様に選ばれた認証、圧縮、暗号化、および識別メカニズムは両方の方向と同じである必要はありません。
5.3. Shared-Secret
5.3. 共有秘密キー
A shared-secret is used in a number of calculations. Regardless of the internal representation of the shared-secret, when used in calculations it is in the same form as the Value part of a Variable Precision Integer:
共有秘密キーは多くの計算に使用されます。 共有秘密キーの内部の表現にかかわらず、計算に使用されると、それはVariable Precision IntegerのValue部分と同じフォームにあります:
- most significant byte first.
- bits used are right justified within byte boundaries.
- any unused bits are in the most significant byte.
- unused bits are zero filled.
- 最も重要なバイト、1番目。 - 中古であるビットはバイト境界の中でまさしく正当です。 - 最も重要なバイトにはどんな未使用のビットもあります。 - 未使用のビットはいっぱいにされたゼロです。
The shared-secret does not include a Size field.
共有秘密キーはSize分野を含んでいません。
5.4. Identity Verification
5.4. アイデンティティ検証
These messages are authenticated using the Identity-Choice. The Verification value is calculated prior to masking (and optional encryption), and verified after unmasking (and optional decryption).
これらのメッセージは、Identity-選択を使用することで認証されます。 Verification値は、マスキング(そして、任意の暗号化)の前に計算されて、暴露した(そして、任意の復号化)後に、確かめられます。
The Identity-Choice authentication function is supplied with two input values:
Identity-選択認証機能に2つの入力値を供給します:
- the sender (SPI Owner) verification-key,
- the data to be verified (as a concatenated sequence of bytes).
- 送付者(SPI Owner)検証キー--確かめられるべき(バイトの連結された系列として)データ。
Karn & Simpson Experimental [Page 34] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[34ページ]RFC2522Photurisは1999年3月に議定書を作ります。
The resulting output value is stored in the Verification field.
結果として起こる出力値はVerification分野に格納されます。
The Identity-Choice verification data consists of the following concatenated values:
Identity-選択検証データは以下の連結された値から成ります:
+ the Initiator Cookie,
+ the Responder Cookie,
+ the Message, LifeTime and SPI fields,
+ the Identity-Choice and Identification,
+ the SPI User Identity Verification (response only),
+ the Attribute-Choices following the Verification field,
+ the Padding,
+ the SPI Owner TBV,
+ the SPI Owner Exchange-Value,
+ the SPI Owner Offered-Attributes,
+ the SPI User TBV,
+ the SPI User Exchange-Value,
+ the SPI User Offered-Attributes,
+ the Responder Offered-Schemes.
+ + + Initiator Cookieと+ Responder Cookieと+ Message、LifeTimeと+ + SPI Owner Exchange-値、+ SPI Owner Offered-属性、+ SPI分野、Identity-選択と+ + + Verification野原に続くAttribute-選択、+ Identification、SPI User Identity Verification(応答専用)Padding、SPI Owner TBV SPI User TBV SPI User Exchange-値、SPI User Offered-属性+ (Responder Offered-計画)。
The TBV (Three Byte Value) consists of the Counter and Scheme-Choice fields from the Value_Request, or the Reserved field from the Value_Response, immediately preceding the associated Exchange-Value.
TBV(3Byte Value)はValue_RequestからのCounterとScheme-選択分野、またはValue_ResponseからのReserved分野から成ります、すぐに関連Exchange-値に先行して。
Note that the order of the Exchange-Value and Offered-Attributes fields is different in each direction, and the Identification and SPI fields are also likely to be different in each direction. Note also that the SPI User Identity Verification (from the Identity_Request) is present only in the Identity_Response.
Exchange-値とOffered-属性分野の注文が各方向に異なっていて、また、IdentificationとSPI分野も各方向に異なる傾向があることに注意してください。 また、SPI User Identity Verification(Identity_Requestからの)がIdentity_Responseだけに存在していることに注意してください。
If the verification fails, the users are notified, and a Verification_Failure message is sent, without adding any SPI. On success, normal operation begins with the authentication and/or encryption of user datagrams.
検証が失敗するなら、ユーザに通知します、そして、どんなSPIも加えないで、Verification_Failureメッセージを送ります。 成功では、通常の操作はユーザデータグラムの認証、そして/または、暗号化で始まります。
Implementation Notes:
実現注意:
This is distinct from any authentication method specified for the
SPI.
これはSPIに指定されたどんな認証方法とも異なっています。
The exact details of the Identification and verification-key
included in the Verification calculation are dependent on the
Identity-Choice, as described in the "Basic Attributes".
Verification計算にIdentificationと検証キーを含む正確な詳細はIdentity-選択に依存しています、「基本的な属性」で説明されるように。
Each party may wish to keep their own trusted databases, such as
the Pretty Good Privacy (PGP) web of trust, and accept only those
identities found there. Failure to find the Identification in
either an internal or external database results in the same
各当事者は、信用のプリティ・グッド・プライバシ(PGP)ウェブなどのそれら自身の信じられたデータベースを保って、そこで見つけられたそれらのアイデンティティだけを受け入れたがっているかもしれません。 内部の、または、外部のデータベースが同じようにもたらさないどちらもIdentificationを見つけないこと
Karn & Simpson Experimental [Page 35] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[35ページ]RFC2522Photurisは1999年3月に議定書を作ります。
Verification_Failure message as failure of the verification
computation.
検証計算の失敗としての検証_Failureメッセージ。
The Exchange-Value data includes both the Size and Value fields.
The Offered-Attributes and Attribute-Choices data includes the
Attribute, Length and Value fields.
Exchange-値のデータはSizeとValue分野の両方を含んでいます。 Offered-属性とAttribute-選択データはAttribute、Length、およびValue分野を含んでいます。
5.5. Privacy-Key Computation
5.5. プライバシー主要な計算
Identification Exchange messages are masked using the Privacy-Method indicated by the current Scheme-Choice. Masking begins with the next field after the SPI, and continues to the end of the data indicated by the UDP Length, including the Padding.
識別Exchangeメッセージは現在のScheme-選択で示されたPrivacy-方法を使用することにおいて仮面です。 マスキングは、SPIの後の次の分野で始まって、UDP Lengthによって示されたデータの終わりまで続きます、Paddingを含んでいて。
The Scheme-Choice specified Key-Generation-Function is used to create a special privacy-key for each message. This function is calculated over the following concatenated values:
Scheme-選択の指定されたKey世代機能は、各メッセージのために特別なプライバシーキーを作成するのに使用されます。 この機能は以下の連結された値に関して計算されます:
+ the SPI Owner Exchange-Value,
+ the SPI User Exchange-Value,
+ the Initiator Cookie,
+ the Responder Cookie,
+ the Message, LifeTime and SPI (or Reserved) fields,
+ the computed shared-secret.
+ + SPI Owner Exchange-値と+ SPI User Exchange-値と+ Initiator Cookieと+ Responder CookieとMessageとLifeTimeとSPI(または、Reserved)分野+ (計算された共有秘密キー)。
Since the order of the Exchange-Value fields is different in each direction, and the Message, LifeTime and SPI fields are also different in each direction, the resulting privacy-key will usually be different in each direction.
Exchange-値の分野の注文が各方向に異なっていて、また、Message、LifeTime、およびSPI分野も各方向に異なっているので、通常、結果として起こるプライバシーキーは各方向に異なるようになるでしょう。
When a larger number of keying-bits are needed than are available from one iteration of the specified Key-Generation-Function, more keying-bits are generated by duplicating the trailing shared-secret, and recalculating the function. That is, the first iteration will have one trailing copy of the shared-secret, the second iteration will have two trailing copies of the shared-secret, and so forth.
より多くの合わせているビットが必要であるときに、より多くの合わせているビットが、指定されたKey世代機能の1つの繰り返しによって利用可能であるというよりも引きずっている共有秘密キーをコピーして、機能について再計算することによって、発生します。 すなわち、最初の繰り返しには、共有秘密キーの引きずっているコピー1部があるでしょう、繰り返しに共有秘密キーの引きずっているコピー2部などがある秒に。
Implementation Notes:
実現注意:
This is distinct from any encryption method specified for the SPI.
これはSPIに指定されたどんな暗号化方法とも異なっています。
The length of the Padding, and other details, are dependent on the
Privacy-Method. See the "Basic Privacy-Method" list for details.
Paddingの長さ、および他の詳細はPrivacy-方法に依存しています。 詳細のための「基本的なプライバシー方法」リストを見てください。
To avoid keeping the Exchange-Values in memory after the initial
verification, it is often possible to pre-compute the function
over the initial bytes of the concatenated data values for each
初期の検証の後にメモリのExchange-値を保つのを避けるために、それぞれのために機能をあらかじめ連結されたデータ値の初期のバイトの上計算するのはしばしば可能です。
Karn & Simpson Experimental [Page 36] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[36ページ]RFC2522Photurisは1999年3月に議定書を作ります。
direction, and append the trailing copies of the shared-secret.
指示、共有秘密キーの引きずっているコピーを追加してください。
The Exchange-Value data includes both the Size and Value fields.
Exchange-値のデータはSizeとValue分野の両方を含んでいます。
5.6. Session-Key Computation
5.6. セッション主要な計算
Each SPI has one or more session-keys. These keys are generated based on the attributes of the SPI. See the "Basic Attributes" for details.
各SPIには、1個以上のセッションキーがあります。 これらのキーはSPIの属性に基づいて発生します。 詳細に関して「基本的な属性」を見てください。
The Scheme-Choice specified Key-Generation-Function is used to create the SPI session-key for that particular attribute. This function is calculated over the following concatenated values:
Scheme-選択の指定されたKey世代機能は、その特定の属性に、セッション主要なSPIを作成するのに使用されます。 この機能は以下の連結された値に関して計算されます:
+ the Initiator Cookie,
+ the Responder Cookie,
+ the SPI Owner generation-key,
+ the SPI User generation-key,
+ the message Verification field,
+ the computed shared-secret.
+ + Initiator Cookie、+ Responder Cookie、+ SPI Owner世代キー、+ SPI User世代キー、メッセージVerification分野+ (計算された共有秘密キー)。
Since the order of the generation-keys is different in each direction, and the Verification field is also likely to be different in each direction, the resulting session-key will usually be different in each direction.
世代キーの注文が各方向に異なっていて、また、Verification分野も各方向に異なる傾向があるので、通常、結果として起こるセッションキーは各方向に異なるようになるでしょう。
When a larger number of keying-bits are needed than are available from one iteration of the specified Key-Generation-Function, more keying-bits are generated by duplicating the trailing shared-secret, and recalculating the function. That is, the first iteration will have one trailing copy of the shared-secret, the second iteration will have two trailing copies of the shared-secret, and so forth.
より多くの合わせているビットが必要であるときに、より多くの合わせているビットが、指定されたKey世代機能の1つの繰り返しによって利用可能であるというよりも引きずっている共有秘密キーをコピーして、機能について再計算することによって、発生します。 すなわち、最初の繰り返しには、共有秘密キーの引きずっているコピー1部があるでしょう、繰り返しに共有秘密キーの引きずっているコピー2部などがある秒に。
Implementation Notes:
実現注意:
This is distinct from any privacy-key generated for the Photuris
exchange. Different initialization data is used, and iterations
are maintained separately.
これはPhoturis交換のために発生するどんなプライバシーキーとも異なっています。 異なった初期化データは使用されています、そして、繰り返しは別々に維持されます。
The exact details of the Verification field and generation-keys
that are included in the session-key calculation are dependent on
the Identity-Choices, as described in the "Basic Attributes".
セッション主要な計算に含まれているVerification分野と世代キーの正確な細部はIdentity-選択に依存しています、「基本的な属性」で説明されるように。
To avoid keeping the generation-keys in memory after the initial
verification, it is often possible to pre-compute the function
over the initial bytes of the concatenated data values for each
direction, and append the trailing copies of the shared-secret.
初期の検証の後にメモリに世代キーを保つのを避けるために、各指示のために機能をあらかじめ連結されたデータ値の初期のバイトの上計算して、共有秘密キーの引きずっているコピーを追加するのはしばしば可能です。
Karn & Simpson Experimental [Page 37] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[37ページ]RFC2522Photurisは1999年3月に議定書を作ります。
When both authentication and encryption attributes are used for
the same SPI, there may be multiple session-keys associated with
the same SPI. These session-keys are generated in the order of
the Attribute-Choices list.
認証と暗号化属性の両方が同じSPIに使用されるとき、同じSPIに関連している複数のセッションキーがあるかもしれません。 これらのセッションキーはAttribute-選択リストの注文で発生します。
6. SPI Messages
6. SPIメッセージ
SPI User SPI Owner
======== =========
SPI_Needed ->
list SPI attribute(s)
make validity key
authenticate
make privacy key(s)
mask/encrypt message
<- SPI_Update
make SPI
pick SPI attribute(s)
make SPI session-key(s)
make validity key
authenticate
make privacy key(s)
mask/encrypt message
SPIユーザSPI所有者======== ========= 正当性キーが必要な->リストSPI属性で認証するSPI_はプライバシーキーがUpdateがSPIにSPIセッション主要な(s)が正当性キーに認証させる(s)SPI属性を選ばせるSPI_がプライバシーキーがメッセージをマスクをかけるか、またはコード化するのをさせるというメッセージ<をマスクをかけるか、またはコード化するのをさせます。
The exchange of messages is not related to the Initiator and Responder. Instead, either party may send one of these messages at any time. The messages are easily distinguished by the parties.
メッセージの交換はInitiatorとResponderに関連しません。 代わりに、何れの当事者はいつでも、これらのメッセージの1つを送るかもしれません。 メッセージはパーティーによって容易に区別されます。
6.0.1. Send SPI_Needed
6.0.1. 必要であるSPI_を送ってください。
At any time after completion of the Identification Exchange, either party can send SPI_Needed. This message is sent when a prospective SPI User needs particular attributes for a datagram (such as confidentiality), and no current SPI has those attributes.
Identification Exchangeの完成の後にいつでも、何れの当事者は必要であるSPI_を送ることができます。 将来のSPI Userがデータグラム(秘密性などの)に特定の属性を必要とするとき、このメッセージを送ります、そして、どんな現在のSPIにも、それらの属性がありません。
The prospective SPI User selects from the intersection of attributes that both parties have previously offered, calculates the Verification, and masks the message using the Privacy-Method indicated by the current Scheme-Choice.
現在のScheme-選択で示されたPrivacy-方法を使用することで、将来のSPI Userは双方が以前に提供した属性の交差点から選び抜いて、Verificationについて計算して、メッセージにマスクをかけます。
Karn & Simpson Experimental [Page 38] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[38ページ]RFC2522Photurisは1999年3月に議定書を作ります。
6.0.2. Receive SPI_Needed
6.0.2. 必要であるSPI_を受けてください。
The potential SPI Owner validates the pair of Cookies, the Padding, the Verification, and the Attributes-Needed.
潜在的SPI OwnerはCookiesであり、Paddingであり、Verificationであり、およびAttributesによる必要の組を有効にします。
- When an invalid/expired cookie is detected, a Bad_Cookie message
is sent.
- 無効の、または、満期のクッキーを検出するとき、Bad_Cookieメッセージを送ります。
- When too many SPI values are already in use for this particular
peer, or some other resource limit is reached, a Resource_Limit
message is sent.
- この特定の同輩には、あまりに多くのSPI値が既に使用中であるか、またはある他のリソース限界に達しているとき、Resource_Limitメッセージを送ります。
- After unmasking, when invalid Padding is detected, the variable
length Attributes-Needed do not match the UDP Length, or an
attribute was not in the Offered-Attributes, the message is
silently discarded.
- 無効のPaddingが検出されるときの可変長を暴露した後Attributesによって必要である、UDP Lengthを合わせないか、または属性がOffered-属性になくて、メッセージは静かに捨てられます。
- When the message verification fails, a Verification_Failure
message is sent.
- メッセージ検証が失敗すると、Verification_Failureメッセージを送ります。
- Whenever such a problem is detected, the SPI is not established;
the implementation SHOULD log the occurance, and notify an
operator as appropriate.
- そのような問題が検出されるときはいつも、SPIは設立されません。 実現SHOULDはoccuranceを登録して、適宜オペレータに通知します。
When the message is valid, the party SHOULD send SPI_Update with the necessary attributes.
メッセージが有効であるときに、パーティーSHOULDは必要な属性があるSPI_Updateを送ります。
If an existing SPI has those attributes, that SPI is returned in the SPI_Update with the remaining SPILT.
既存のSPIにそれらの属性があるなら、残っているSPILTとSPI_UpdateでそのSPIを返します。
6.0.3. Send SPI_Update
6.0.3. SPI_アップデートを送ってください。
At any time after completion of the Identification Exchange, either party can send SPI_Update. This message has effect in only one direction, from the SPI Owner to the SPI User.
Identification Exchangeの完成の後にいつでも、何れの当事者はSPI_Updateを送ることができます。 このメッセージはSPI OwnerからSPI Userまで一方向だけに手答えがあります。
The SPI Owner chooses the SPI and SPILT, a set of Attributes for the SPI, calculates the Verification, and masks the message using the Privacy-Method indicated by the current Scheme-Choice.
SPI OwnerがSPIを選んで、SPILT(SPIのためのAttributesの1セット)は、Verificationについて計算して、現在のScheme-選択で示されたPrivacy-方法を使用することでメッセージにマスクをかけます。
6.0.4. Receive SPI_Update
6.0.4. SPI_アップデートを受けてください。
The prospective SPI User validates the pair of Cookies, the Padding, the Verification, and the Attributes-Needed.
将来のSPI UserはCookiesであり、Paddingであり、Verificationであり、およびAttributesによる必要の組を有効にします。
- When an invalid/expired cookie is detected, a Bad_Cookie message
- 病人/が呼吸が絶えたとき、クッキーは検出されて、Bad_Cookieはメッセージです。
Karn & Simpson Experimental [Page 39] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[39ページ]RFC2522Photurisは1999年3月に議定書を作ります。
is sent.
送ります。
- After unmasking, when invalid Padding is detected, the variable
length Attribute-Choices do not match the UDP Length, an attribute
was not in the Offered-Attributes, or the message modifies an
existing SPI, the message is silently discarded.
- 無効のPaddingが検出されるとき暴露した後に、可変長Attribute-選択はUDP Lengthに合わないか、属性がOffered-属性になかったか、メッセージが既存のSPIを変更して、またはメッセージは静かに捨てられます。
- When the message verification fails, a Verification_Failure
message is sent.
- メッセージ検証が失敗すると、Verification_Failureメッセージを送ります。
- Whenever such a problem is detected, the SPI is not established;
the implementation SHOULD log the occurance, and notify an
operator as appropriate.
- そのような問題が検出されるときはいつも、SPIは設立されません。 実現SHOULDはoccuranceを登録して、適宜オペレータに通知します。
When the message is valid, further actions are dependent on the value of the LifeTime field, as described later.
メッセージが有効であるときに、さらなる動作は後で説明されるようにLifeTime分野の値に依存しています。
6.0.5. Automated SPI_Updates
6.0.5. 自動化されたSPI_アップデート
Each SPI requires replacement under several circumstances:
各SPIはいくつかの状況の下での交換を必要とします:
- the volume of data processed (inhibiting probability
cryptanalysis),
- データ量は処理されました(確率暗号文解読術を禁止して)。
- exhaustion of available anti-replay Sequence Numbers,
- 利用可能な反再生Sequence民数記の疲労困憊
- and expiration of the LifeTime.
- そして、LifeTimeの満了。
In general, a determination is made upon receipt of a datagram. If the transform specific processing finds that refreshment is needed, an automated SPI_Update is triggered.
一般に、データグラムを受け取り次第決断をします。 特定の処理がその軽い飲食物に当たる変換が必要であるなら、自動化されたSPI_Updateは引き起こされます。
In addition, automated SPI_Updates allow rapid SPI refreshment for high bandwidth applications in a high delay environment. The update messages flow in the opposite direction from the primary traffic, conserving bandwidth and avoiding service interruption.
さらに、自動化されたSPI_Updatesは高い遅れ環境における高帯域幅アプリケーションに関する急速なSPI軽い飲食物を許容します。 帯域幅を保存して、停電を避けて、アップデートメッセージは第一の交通から逆方向に流れます。
When creating each SPI, the implementation MAY optionally set an Update TimeOut (UTO); by default, to half the value of the LifeTime (SPILT/2). This time is highly dynamic, and adjustable to provide an automated SPI_Update long before transform specific processing. If no new Photuris exchange occurs within the time limit, and the current exchange state has not expired, an automated SPI_Update is sent.
各SPIを作成するとき、実現は任意に、Update TimeOut(UTO)を設定するかもしれません。 デフォルトで、LifeTime(SPILT/2)の値の半分に。 今回は、Updateがずっと前に変える自動化されたSPI_に特定の処理を供給するのにおいて非常にダイナミックであって、調整可能です。 どんな新しいPhoturis交換もタイムリミットの中に起こらないで、また現在の交換状態が期限が切れていないなら、自動化されたSPI_Updateを送ります。
Karn & Simpson Experimental [Page 40] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[40ページ]RFC2522Photurisは1999年3月に議定書を作ります。
6.1. SPI_Needed
6.1. 必要であるSPI_
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Initiator-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Responder-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message | Reserved-LT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved-SPI |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
~ Verification ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes-Needed ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 創始者クッキー~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 応答者クッキー~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージ| 予約されたLT| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されたSPI| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | ~ 検証~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 属性に必要… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Initiator-Cookie 16 bytes. Copied from the Value_Request.
創始者クッキー16バイト。 値_要求から、コピーされます。
Responder-Cookie 16 bytes. Copied from the Value_Request.
応答者クッキー16バイト。 値_要求から、コピーされます。
Message 8
メッセージ8
Reserved-LT 3 bytes. For future use; MUST be filled with a
random non-zero value when transmitted, and MUST be
ignored when received.
予約されたLT3バイト。 今後の使用のために。 伝えると無作為の非ゼロ値で満たさなければならなくて、受け取ると、無視しなければなりません。
Reserved-SPI 4 bytes. For future use; MUST be set to zero when
transmitted, and MUST be ignored when received.
予約されたSPI4バイト。 今後の使用のために。 伝えるとゼロに設定しなければならなくて、受け取ると、無視しなければなりません。
Verification Variable Precision Integer, or other format
indicated by the current Scheme-Choice. The
calculation of the value is described in "Validity
Verification".
検証Variable Precision Integer、または現在のScheme-選択で示された他の書式。 価値の計算は「正当性検証」で説明されます。
The field may be any integral number of bytes in
length. It does not require any particular
alignment. The 32-bit alignment shown is for
convenience in the illustration.
分野は長さがどんな不可欠のバイト数であるかもしれません。 それは少しの特定の整列も必要としません。 示された32ビットの整列はイラストにおける便宜のためのものです。
Karn & Simpson Experimental [Page 41] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[41ページ]RFC2522Photurisは1999年3月に議定書を作ります。
Attributes-Needed
4 or more bytes. A list of two or more attributes,
selected from the list of Offered-Attributes
supported by the peer.
属性に必要な4バイト以上。 同輩によって支持されたOffered-属性のリストから選択された2つ以上の属性のリスト。
The contents and usage of this list are as
previously described in "Attribute Choices List".
The end of the list is indicated by the UDP Length
after removing the Padding (UDP Length - last
Padding value).
このリストのコンテンツと使用法は同じくらい以前に、「属性選択は記載するところ」で説明されます。 Padding(UDP Length--最後のPadding値)を取り外した後に、リストの終わりはUDP Lengthによって示されます。
Padding 8 or more bytes. The message is padded in the same
fashion specified for Identification Exchange
messages.
8バイト以上を水増しします。 メッセージはIdentification Exchangeメッセージに指定された同じファッションで水増しされます。
The portion of the message after the SPI field is masked using the Privacy-Method indicated by the current Scheme-Choice.
SPI分野の後のメッセージの部分は現在のScheme-選択で示されたPrivacy-方法を使用することにおいて仮面です。
The fields following the SPI are opaque. That is, the values are set prior to masking (and optional encryption), and examined only after unmasking (and optional decryption).
SPIに続く分野は不透明です。 すなわち、値は、マスキング(そして、任意の暗号化)の前に設定されて、暴露した(そして、任意の復号化)後にだけ、調べられます。
Karn & Simpson Experimental [Page 42] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[42ページ]RFC2522Photurisは1999年3月に議定書を作ります。
6.2. SPI_Update
6.2. SPI_アップデート
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Initiator-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Responder-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message | LifeTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security-Parameters-Index |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
~ Verification ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute-Choices ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 創始者クッキー~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 応答者クッキー~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージ| 生涯| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | セキュリティパラメタインデックス| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | ~ 検証~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 属性選択… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Initiator-Cookie 16 bytes. Copied from the Value_Request.
創始者クッキー16バイト。 値_要求から、コピーされます。
Responder-Cookie 16 bytes. Copied from the Value_Request.
応答者クッキー16バイト。 値_要求から、コピーされます。
Message 9
メッセージ9
LifeTime 3 bytes. The number of seconds remaining before the
indicated SPI expires. The value zero indicates
deletion of the indicated SPI.
LifeTime3バイト。 示されたSPIの前に残っている秒数は期限が切れます。 値ゼロは示されたSPIの削除を示します。
Security-Parameters-Index (SPI)
4 bytes. The SPI to be used for incoming
communications.
セキュリティパラメタインデックス(SPI)4バイト。 入ってくる通信について使用されるべきSPI。
This may be a new SPI value (for creation), or an
existing SPI value (for deletion). The value zero
indicates special processing.
これは、新しいSPI値(創造のための)、または既存のSPI値であるかもしれません(削除のための)。 値ゼロは特別な処理を示します。
Verification Variable Precision Integer, or other format
indicated by the current Scheme-Choice. The
calculation of the value is described in "Validity
Verification".
検証Variable Precision Integer、または現在のScheme-選択で示された他の書式。 価値の計算は「正当性検証」で説明されます。
Karn & Simpson Experimental [Page 43] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[43ページ]RFC2522Photurisは1999年3月に議定書を作ります。
The field may be any integral number of bytes in
length. It does not require any particular
alignment. The 32-bit alignment shown is for
convenience in the illustration.
分野は長さがどんな不可欠のバイト数であるかもしれません。 それは少しの特定の整列も必要としません。 示された32ビットの整列はイラストにおける便宜のためのものです。
Attribute-Choices
0 or more bytes. When the SPI and SPILT are non-
zero, a list of attributes selected from the list of
Offered-Attributes supported by the peer.
属性選択0バイト以上。 属性のリストは、同輩によって支持されたOffered-属性のリストからいつSPIとSPILTが非ゼロであるかを選択しました。
The contents and usage of this list are as
previously described in "Attribute Choices List".
The end of the list is indicated by the UDP Length
after removing the Padding (UDP Length - last
Padding value).
このリストのコンテンツと使用法は同じくらい以前に、「属性選択は記載するところ」で説明されます。 Padding(UDP Length--最後のPadding値)を取り外した後に、リストの終わりはUDP Lengthによって示されます。
Padding 8 or more bytes. The message is padded in the same
fashion specified for Identification Exchange
messages.
8バイト以上を水増しします。 メッセージはIdentification Exchangeメッセージに指定された同じファッションで水増しされます。
The portion of the message after the SPI field is masked using the Privacy-Method indicated by the current Scheme-Choice.
SPI分野の後のメッセージの部分は現在のScheme-選択で示されたPrivacy-方法を使用することにおいて仮面です。
The fields following the SPI are opaque. That is, the values are set prior to masking (and optional encryption), and examined only after unmasking (and optional decryption).
SPIに続く分野は不透明です。 すなわち、値は、マスキング(そして、任意の暗号化)の前に設定されて、暴露した(そして、任意の復号化)後にだけ、調べられます。
6.2.1. Creation
6.2.1. 創造
When the LifeTime is non-zero, and the SPI is also non-zero, the SPI_Update can be used to create a new SPI. When the SPI is zero, the SPI_Update is silently discarded.
LifeTimeが非ゼロであり、また、SPIが非ゼロに合わせるとき、新しいSPIを作成するのにSPI_Updateを使用できます。 SPIがゼロであるときに、SPI_Updateは静かに捨てられます。
The new session-keys are calculated in the same fashion as the Identity_Messages. Since the SPI value is always different than any previous SPI during the Exchange LifeTime of the shared-secret, the resulting session-keys will necessarily be different from all others used in the same direction.
新しいセッションキーはIdentity_Messagesと同じファッションで計算されます。 SPI値が共有秘密キーのExchange LifeTimeの間、どんな前のSPIともいつも異なっているので、結果として起こるセッションキーは必ず同じ方向に使用されるすべての他のものと異なるでしょう。
No retransmission timer is necessary. Success is indicated by the peer use of the new SPI.
どんな再送信タイマーも必要ではありません。 成功は新しいSPIの同輩使用で示されます。
Should all creation attempts fail, eventually the peer will find that all existing SPIs have expired, and will begin the Photuris exchange again by sending a new Cookie_Request. When appropriate, this Cookie_Request MAY include a Responder-Cookie to retain previous party pairings.
万物試みが失敗すると、結局、同輩は、すべての既存のSPIsが期限が切れて、再び新しいCookie_Requestを送ることによってPhoturis交換を始めるのがわかるでしょう。 適切であるときに、このCookie_Requestは、前のパーティー組み合わせを保有するためにResponder-クッキーを含むかもしれません。
Karn & Simpson Experimental [Page 44] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[44ページ]RFC2522Photurisは1999年3月に議定書を作ります。
6.2.2. Deletion
6.2.2. 削除
When the LifeTime is zero, the SPI_Update can be used to delete a single existing SPI. When the SPI is also zero, the SPI_Update will delete all existing SPIs related to this Security Association, and mark the Photuris exchange state as expired. This is especially useful when the application that needed them terminates.
LifeTimeがゼロであるときに、独身の既存のSPIを削除するのにSPI_Updateを使用できます。 また、SPIがゼロであるときに、SPI_Updateは、吐き出されるようにこのSecurity Associationに関連するすべての既存のSPIsを削除して、Photuris交換が状態であるとマークするでしょう。 それらを必要としたアプリケーションが終わるとき、これは特に役に立ちます。
No retransmission timer is necessary. This message is advisory, to reduce the number of ICMP Security Failures messages.
どんな再送信タイマーも必要ではありません。 このメッセージは、ICMP Security Failuresメッセージの数を減少させるために顧問です。
Should any deletion attempts fail, the peer will learn that the deleted SPIs are invalid through the normal ICMP Security Failures messages, and will initiate a Photuris exchange by sending a new Cookie_Request.
何か削除試みが失敗すると、同輩は、削除されたSPIsが正常なICMP Security Failuresメッセージを通して無効であり、新しいCookie_Requestを送ることによってPhoturis交換を起こすことを学ぶでしょう。
6.2.3. Modification
6.2.3. 変更
The SPI_Update cannot be used to modify existing SPIs, such as lengthen an existing SPI LifeTime, resurrect an expired SPI, or add/remove an Attribute-Choice.
既存のSPIsを変更するのにSPI_Updateを使用できません。(SPIsはAttribute-選択を既存のSPI LifeTimeを伸すか、満期のSPIを復活させるか、加えるか、または取り除きます)。
On receipt, such an otherwise valid message is silently discarded.
領収書の上では、そのようなそうでなければ、有効なメッセージは静かに捨てられます。
6.3. Validity Verification
6.3. 正当性検証
These messages are authenticated using the Validity-Method indicated by the current Scheme-Choice. The Verification value is calculated prior to masking (and optional encryption), and verified after unmasking (and optional decryption).
これらのメッセージは、現在のScheme-選択で示されたValidity-方法を使用することで認証されます。 Verification値は、マスキング(そして、任意の暗号化)の前に計算されて、暴露した(そして、任意の復号化)後に、確かめられます。
The Validity-Method authentication function is supplied with two input values:
Validity-方法認証機能に2つの入力値を供給します:
- the sender (SPI Owner) verification-key,
- the data to be verified (as a concatenated sequence of bytes).
- 送付者(SPI Owner)検証キー--確かめられるべき(バイトの連結された系列として)データ。
The resulting output value is stored in the Verification field.
結果として起こる出力値はVerification分野に格納されます。
The Validity-Method verification data consists of the following concatenated values:
Validity-方法検証データは以下の連結された値から成ります:
Karn & Simpson Experimental [Page 45] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[45ページ]RFC2522Photurisは1999年3月に議定書を作ります。
+ the Initiator Cookie,
+ the Responder Cookie,
+ the Message, LifeTime and SPI (or Reserved) fields,
+ the SPI Owner Identity Verification,
+ the SPI User Identity Verification,
+ the Attribute-Choices following the Verification field,
+ the Padding.
+ Verification野原+ (Padding)に続く+ + + Initiator Cookie、Responder Cookie+ + MessageとLifeTimeとSPI(または、Reserved)分野、SPI Owner Identity Verification、SPI User Identity Verification Attribute-選択。
Note that the order of the Identity Verification fields (from the Identity_Messages) is different in each direction, and the Message, LifeTime and SPI fields are also likely to be different in each direction.
Identity Verification分野(Identity_Messagesからの)の注文が各方向に異なっていて、また、Message、LifeTime、およびSPI分野も各方向に異なる傾向があることに注意してください。
If the verification fails, the users are notified, and a Verification_Failure message is sent, without adding or deleting any SPIs. On success, normal operation begins with the authentication and/or encryption of user datagrams.
どんなSPIsも加えるか、または削除しないで、検証が失敗するなら、ユーザに通知して、Verification_Failureメッセージを送ります。 成功では、通常の操作はユーザデータグラムの認証、そして/または、暗号化で始まります。
Implementation Notes:
実現注意:
This is distinct from any authentication method specified for the
SPI.
これはSPIに指定されたどんな認証方法とも異なっています。
The Identity Verification data includes both the Size and Value
fields. The Attribute-Choices data includes the Attribute, Length
and Value fields.
Identity VerificationデータはSizeとValue分野の両方を含んでいます。 Attribute-選択データはAttribute、Length、およびValue分野を含んでいます。
7. Error Messages
7. エラーメッセージ
These messages are issued in response to Photuris state loss or other problems. A message has effect in only one direction. No retransmission timer is necessary.
Photuris州の損失か他の問題に対応してこれらのメッセージを発行します。メッセージは一方向だけに手答えがあります。 どんな再送信タイマーも必要ではありません。
These messages are not masked.
これらのメッセージは仮面ではありません。
The receiver checks the Cookies for validity. Special care MUST be taken that the Cookie pair in the Error Message actually match a pair currently in use, and that the protocol is currently in a state where such an Error Message might be expected. Otherwise, these messages could provide an opportunity for a denial of service attack. Invalid messages are silently discarded.
受信機は正当性がないかどうかCookiesをチェックします。 特別な注意を払わなければなりません。Error MessageのCookie組は実際に現在使用中の1組に合っています、そして、プロトコルが現在、そのようなError Messageが予想されるかもしれない状態にあります。 さもなければ、これらのメッセージはサービス不能攻撃に機会を与えるかもしれません。 無効のメッセージは静かに捨てられます。
Karn & Simpson Experimental [Page 46] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[46ページ]RFC2522Photurisは1999年3月に議定書を作ります。
7.1. Bad_Cookie
7.1. 腐っている_クッキー
For the format of the 33 byte message, see "Header Format". There are no additional fields.
33バイトのメッセージの形式に関しては、「ヘッダー形式」を見てください。 どんな追加分野もありません。
Initiator-Cookie 16 bytes. Copied from the offending message.
創始者クッキー16バイト。 腹立たしいメッセージから、コピーされます。
Responder-Cookie 16 bytes. Copied from the offending message.
応答者クッキー16バイト。 腹立たしいメッセージから、コピーされます。
Message 10
メッセージ10
This error message is sent when a Value_Request, Identity_Request, SPI_Needed, or SPI_Update is received, and the receiver specific Cookie is invalid or the associated exchange state has expired.
Value_Request、Identity_Request、必要であるSPI_、またはSPI_Updateが受け取られていて、受信機の特定のCookieが無効であるか、または関連交換状態が期限が切れたとき、このエラーメッセージを送ります。
During the Photuris exchange, when this error message is received, it has no immediate effect on the operation of the protocol phases. Later, when Retransmissions have been exceeded, and this error message has been received, the Initiator SHOULD begin the Photuris exchange again by sending a new Cookie_Request with the Responder- Cookie and Counter updated appropriately.
このエラーメッセージが受信されているとき、Photuris交換の間、それはプロトコルフェーズの操作にどんな即座の影響も与えません。 Retransmissionsを超えて、その後このエラーメッセージを受け取ったとき、Initiator SHOULDは、再び適切にResponderクッキーとCounterをアップデートしている状態で新しいCookie_Requestを送ることによって、Photuris交換を始めます。
When this error message is received in response to SPI_Needed, the exchange state SHOULD NOT be marked as expired, but the party SHOULD initiate a Photuris exchange by sending a new Cookie_Request.
必要であるSPI_に対応してこのエラーメッセージを受け取るとき、交換州のSHOULD NOTが吐き出されるようにマークされて、パーティーSHOULDだけが、新しいCookie_Requestを送ることによって、Photuris交換を起こします。
When this error message is received in response to SPI_Update, the exchange state SHOULD NOT be marked as expired, and no further action is taken. A new exchange will be initiated later when needed by the peer to send authenticated and/or encrypted data.
SPI_に対応してこのエラーメッセージを受け取るとき、Update、交換は、吐き出されるようにSHOULD NOTがマークされると述べます、そして、さらなる行動を全く取りません。 後で同輩によって認証されたそして/または、コード化されたデータを送る必要があるとき、新しい交換は起こされるでしょう。
Existing SPIs are not deleted. They expire normally, and are purged sometime later.
既存のSPIsは削除されません。 それらは、通常、期限が切れて、後でいつか、掃除されます。
7.2. Resource_Limit
7.2. リソース_限界
For the format of the 34 byte message, see "Cookie_Request". There are no additional fields.
34バイトのメッセージの形式に関しては、「クッキー_要求」を見てください。 どんな追加分野もありません。
Initiator-Cookie 16 bytes. Copied from the offending message.
創始者クッキー16バイト。 腹立たしいメッセージから、コピーされます。
Responder-Cookie 16 bytes. Copied from the offending message.
応答者クッキー16バイト。 腹立たしいメッセージから、コピーされます。
Special processing is applied to a Cookie_Request.
When the offending message Responder-Cookie and
Counter were both zero, and an existing exchange has
not yet been purged, this field is replaced with the
特別な処理はCookie_Requestに適用されます。 いつにまだ、Responder-クッキーとCounterがゼロと既存の交換の両方であったという怒っているメッセージを掃除していなくて、この野原を取り替えるか。
Karn & Simpson Experimental [Page 47] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[47ページ]RFC2522Photurisは1999年3月に議定書を作ります。
Responder-Cookie from the existing exchange.
既存の交換からの応答者クッキー。
Message 11
メッセージ11
Counter 1 byte. Copied from the offending message.
1バイトを打ち返してください。 腹立たしいメッセージから、コピーされます。
When zero, the Responder-Cookie indicates the
Initiator of a previous exchange, or no previous
exchange is specified.
ゼロであるときに、Responder-クッキーは、前の交換にもかかわらず、前の交換がないInitiatorが指定されるのを示します。
When non-zero, the Responder-Cookie indicates the
Responder to a previous exchange. This value is set
to the Counter from the corresponding
Cookie_Response.
非ゼロであるときに、Responder-クッキーは前の交換にResponderを示します。 この値は対応するCookie_ResponseからCounterに設定されます。
This error message is sent when a Cookie_Request, Value_Request or SPI_Needed is received, and too many SPI values are already in use for that peer, or some other Photuris resource is unavailable.
Cookie_Request、RequestかSPI_が必要としたValue_が受け取られていて、その同輩には、あまりに多くのSPI値が既に使用中であるか、またはある他のPhoturisリソースが入手できないときに、このエラーメッセージを送ります。
During the Photuris exchange, when this error message is received in response to a Cookie_Request or Value_Request, the implementation SHOULD double the retransmission timeout (as usual) for sending another Cookie_Request or Value_Request. Otherwise, it has no immediate effect on the operation of the protocol phases. Later, when Retransmissions have been exceeded, and this error message has been received, the Initiator SHOULD begin the Photuris exchange again by sending a new Cookie_Request with the Responder-Cookie and Counter updated appropriately.
Cookie_RequestかValue_Requestに対応してこのエラーメッセージを受け取るときのPhoturis交換の間、実現SHOULDは、別のCookie_RequestかValue_Requestを送りながら、(いつものように)再送タイムアウトの代わりをします。 さもなければ、それはプロトコルフェーズの操作にどんな即座の影響も与えません。 Retransmissionsを超えて、その後このエラーメッセージを受け取ったとき、Initiator SHOULDは、再び適切にResponder-クッキーとCounterをアップデートしている状態で新しいCookie_Requestを送ることによって、Photuris交換を始めます。
When this error message is received in response to SPI_Needed, the implementation SHOULD NOT send another SPI_Needed until one of the existing SPIs associated with this exchange is deleted or has expired.
必要であるSPI_に対応してこのエラーメッセージを受け取るとき、実現SHOULD NOTはSPIsがこの交換に関連づける存在のものが削除されるか、または期限が切れるまで必要である別のSPI_を送ります。
7.3. Verification_Failure
7.3. 検証_失敗
For the format of the 33 byte message, see "Header Format". There are no additional fields.
33バイトのメッセージの形式に関しては、「ヘッダー形式」を見てください。 どんな追加分野もありません。
Initiator-Cookie 16 bytes. Copied from the offending message.
創始者クッキー16バイト。 腹立たしいメッセージから、コピーされます。
Responder-Cookie 16 bytes. Copied from the offending message.
応答者クッキー16バイト。 腹立たしいメッセージから、コピーされます。
Message 12
メッセージ12
This error message is sent when an Identity_Message, SPI_Needed or SPI_Update is received, and verification fails.
Identity_Message、必要であるSPI_またはSPI_Updateが受け取られていて、検証が失敗すると、このエラーメッセージを送ります。
Karn & Simpson Experimental [Page 48] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[48ページ]RFC2522Photurisは1999年3月に議定書を作ります。
When this error message is received, the implementation SHOULD log the occurance, and notify an operator as appropriate. However, receipt has no effect on the operation of the protocol.
このエラーメッセージが受信されているとき、実現SHOULDはoccuranceを登録して、適宜オペレータに通知します。 しかしながら、領収書はプロトコルの操作のときに効き目がありません。
7.4. Message_Reject
7.4. メッセージ_廃棄物
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Initiator-Cookie ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Responder-Cookie ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message | Bad-Message | Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 創始者クッキー~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 応答者クッキー~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージ| 悪いメッセージ| 相殺されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Initiator-Cookie 16 bytes. Copied from the offending message.
創始者クッキー16バイト。 腹立たしいメッセージから、コピーされます。
Responder-Cookie 16 bytes. Copied from the offending message.
応答者クッキー16バイト。 腹立たしいメッセージから、コピーされます。
Message 13
メッセージ13
Bad-Message 1 byte. Indicates the Message number of the
offending message.
悪いメッセージ1バイト。 腹立たしいメッセージのMessage番号を示します。
Offset 2 bytes. The number of bytes from the beginning of
the offending message where the unrecognized field
starts. The minimum value is 32.
2バイトを相殺してください。 認識されていない野原が始まる腹立たしいメッセージの始まりからのバイト数。 最小値は32です。
This error message is sent when an optional Message type is received that is not supported, or an optional format of a supported Message is not recognized.
このエラーメッセージは任意のMessageタイプが受け取られているとき、送って、それが支持されないか、または支持されたMessageの任意の形式が認識されないということです。
When this error message is received, the implementation SHOULD log the occurance, and notify an operator as appropriate. However, receipt has no effect on the operation of the protocol.
このエラーメッセージが受信されているとき、実現SHOULDはoccuranceを登録して、適宜オペレータに通知します。 しかしながら、領収書はプロトコルの操作のときに効き目がありません。
Karn & Simpson Experimental [Page 49] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[49ページ]RFC2522Photurisは1999年3月に議定書を作ります。
8. Public Value Exchanges
8. 公共の値の交換
Photuris is based in principle on public-key cryptography, specifically Diffie-Hellman key exchange. Exchange of public D-H Exchange-Values based on private-secret values results in a mutual shared-secret between the parties. This shared-secret can be used on its own, or to generate a series of session-keys for authentication and encryption of subsequent traffic.
Photurisは原則として公開カギ暗号、明確にディフィー-ヘルマンの主要な交換に基づいています。 公共のD-H Exchange-値の交換はパーティーの間の互いの共有秘密キーの結果を個人的に秘密の値に基礎づけました。 それ自身のところでこの共有秘密キーを使用できる、その後の交通の認証と暗号化のための一連のセッションキーを発生させます。
This document assumes familiarity with the Diffie-Hellman public-key algorithm. A good description can be found in [Schneier95].
このドキュメントはディフィー-ヘルマン公開カギアルゴリズムへの親しみを仮定します。 [Schneier95]で良い記述を見つけることができます。
8.1. Modular Exponentiation Groups
8.1. モジュールの羃法グループ
The original Diffie-Hellman technique [DH76] specified modular exponentiation. A public-value is generated using a generator (g), raised to a private-secret exponent (x), modulo a prime (p):
オリジナルのディフィー-ヘルマンのテクニック[DH76]はモジュールの羃法を指定しました。 公共の値は個人的に秘密の解説者(x)まで上げられたジェネレータ(g)を使用することで発生して、法は主要な(p)です:
(g**x) mod p.
(g**x) モッズp。
When these public-values are exchanged between parties, the parties can calculate a shared-secret value between themselves:
パーティーの間でこれらの公共の値を交換するとき、パーティーは自分たちの間で共有秘密キー値について計算できます:
(g**xy) mod p.
(g**xy) モッズp。
The generator (g) and modulus (p) are established by the Scheme- Choice (see the "Basic Exchange-Schemes" for details). They are offered in the Cookie_Response, and one pair is chosen in the Value_Request.
ジェネレータ(g)と係数(p)はScheme選択で確立されます(詳細の「基本的な交換計画」を見てください)。 Cookie_Responseでそれらを提供します、そして、Value_Requestで1組を選びます。
The private exponents (x) and (y) are kept secret by the parties. Only the public-value result of the modular exponentiation with (x) or (y) is sent as the Initiator and Responder Exchange-Value.
個人的な解説者(x)と(y)はパーティーによって秘密にされます。 InitiatorとResponder Exchange-値として(x)か(y)があるモジュールの羃法の公共の値の結果だけを送ります。
These public-values are represented in single Variable Precision Integers. The Size of these Exchange-Values will match the Size of the modulus (p).
これらの公共の値は独身のVariable Precision Integersに表されます。 これらのExchange-値のSizeは係数(p)のSizeに合うでしょう。
8.2. Moduli Selection
8.2. 係数選択
Each implementation proposes one or more moduli in its Offered- Schemes. Every implementation MUST support up to 1024-bit moduli.
各実現はOffered計画における1つ以上の係数を提案します。 あらゆる実現が係数を1024ビットまで支持しなければなりません。
For any particular Photuris node, these moduli need not change for significant periods of time; likely days or weeks. A background process can periodically generate new moduli.
どんな特定のPhoturisノードに関してはも、これらの係数は重要な期間に変化する必要はありません。 ありそうな日か何週間も。 バックグラウンドで実行中のプロセスは新しい係数を定期的に発生させることができます。
Karn & Simpson Experimental [Page 50] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[50ページ]RFC2522Photurisは1999年3月に議定書を作ります。
For 512-bit moduli, current estimates would provide 64
(pessimistic) bit-equivalents of cryptographic strength.
512ビットの係数のために、現状見積金額は暗号の強さの64の(悲観的)のビット同等物を提供するでしょう。
For 1024-bit moduli, current estimates would range from 80
(pessimistic) through 98 (optimistic) bit-equivalents of
cryptographic strength.
1024年のビットの係数のために、現状見積金額は80(悲観的な)〜(楽観的)の暗号の強さの98のビット同等物まで及ぶでしょう。
These estimates are used when choosing moduli that are appropriate for the desired Security Parameter attributes.
必要なSecurity Parameter属性に、適切な係数を選ぶとき、これらの見積りは使用されています。
8.2.1. Bootstrap Moduli
8.2.1. 係数を独力で進んでください。
Each implementation is likely to use a fixed modulus during its bootstrap, until it can generate another modulus in the background. As the bootstrap modulus will be widely distributed, and reused whenever the machine reinitializes, it SHOULD be a "safe" prime (p = 2q+1) to provide the greatest long-term protection.
それぞれの実現が固定係数を使用しそうである、それ、独力で進んでください、バックグラウンドで別の係数を発生させることができるまで。 「金庫」が最も大きい長期保護を提供するために主要であったなら(pは2q+1と等しいです)、マシンが再初期化されて、それがSHOULDであるときはいつも、広く分配されて、再利用された係数を独力で進んでください。
Implementors are encouraged to generate their own bootstrap moduli, and to change bootstrap moduli in successive implementation releases.
作成者は、奨励されて、それら自身のを発生させるのが係数を独力で進むということであり、連続した実現リリースにおける係数を変化に独力で進みます。
8.2.2. Learning Moduli
8.2.2. 学習係数
As Photuris exchanges are initiated, new moduli will be learned from the Responder Offered-Schemes. The Initiator MAY cache these moduli for its own use.
Photuris交換が起こされるように、新しい係数はResponder Offered-計画から学習されるでしょう。 Initiatorはそれ自身の使用のためにこれらの係数をキャッシュするかもしれません。
Before offering any learned modulus, the implementation MUST perform at least one iteration of probable primality verification. In this fashion, many processors will perform verification in parallel as moduli are passed around.
どんな学術的係数も提供する前に、実現はありえそうなprimality検証の少なくとも1つの繰り返しを実行しなければなりません。 こんなやり方で、係数は平行ですが、多くのプロセッサが検証を実行するでしょう。
When primality verification failures are found, the failed moduli SHOULD be retained for some (implementation dependent) period of time, to avoid re-learning and re-testing after subsequent exchanges.
失敗した係数SHOULDが再学習を避けるためにいつかの(実現に依存する)の期間の間、保有されて、再テストして、primality検証の故障がその後の交換の後に見つけられるとき。
8.3. Generator Selection
8.3. ジェネレータ選択
The generator (g) should be chosen such that the private-secret exponents will generate all possible public-values, evenly distributed throughout the range of the modulus (p), without cycling through a smaller subset. Such a generator is called a "primitive root" (which is trivial to find when p is "safe").
ジェネレータ(g)は、個人的に秘密の解説者が、より小さい部分集合を通して循環しないで係数(p)の範囲中で均等に分配されたすべての可能な公共の値を発生させるように、選ばれるべきです。 そのようなジェネレータは「原始根」(pがいつ「安全であるか」わかるために些細である)と呼ばれます。
Only one generator (2) is required to be supported.
1個のジェネレータ(2)だけが、支持されるのに必要です。
Karn & Simpson Experimental [Page 51] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[51ページ]RFC2522Photurisは1999年3月に議定書を作ります。
Implementation Notes:
実現注意:
One useful technique is to select the generator, and then limit
the modulus selection sieve to primes with that generator:
1つの役に立つテクニックは、ジェネレータを選択して、次に、係数選択ふるいをそのジェネレータがある盛りに制限することです:
2 when p (mod 24) = 11.
3 when p (mod 12) = 5.
5 when p (mod 10) = 3 or 7.
2 p(モッズ風の24)=11であるときに。 3 p(モッズ風の12)=5であるときに。 5 p(モッズ風の10)=3か7であるときに。
The required generator (2) improves efficiency in multiplication
performance. It is usable even when it is not a primitive root,
as it still covers half of the space of possible residues.
必要なジェネレータ(2)は乗法性能で能率を増進します。 原始根でさえないときに、それは使用可能です、まだ半分の可能な残りのスペースをカバーしているとき。
8.4. Exponent Selection
8.4. 解説者選択
Each implementation generates a separate random private-secret exponent for each different modulus. Then, a D-H Exchange-Value is calculated for the given modulus, generator, and exponent.
各実現はそれぞれの異なった係数のために別々の無作為の個人的に秘密の解説者を発生させます。 そして、D-H Exchange-値は与えられた係数、ジェネレータ、および解説者のために計算されます。
This specification recommends that the exponent length be at least twice the desired cryptographic strength of the longest session-key needed by the strongest offered-attribute.
この仕様は、解説者の長さが少なくとも最も強い提供された属性が必要であった中で最も長いセッションキーの必要な暗号の強さの2倍であることを推薦します。
Based on the estimates in "Moduli Selection" (above):
「係数選択」(above)の見積りに基づいて:
For 512-bit moduli, exponent lengths of 128 bits (or more) are
recommended.
512ビットの係数において、128ビット(さらに)の解説者の長さはお勧めです。
For 1024-bit moduli, exponent lengths of 160 to 256 bits (or more)
are recommended.
1024年のビットの係数において、160〜256ビット(さらに)の解説者の長さはお勧めです。
Although the same exponent and Exchange-Value may be used with several parties whenever the same modulus and generator are used, the exponent SHOULD be changed at random intervals. A background process can periodically destroy the old values, generate a new random private-secret exponent, and recalculate the Exchange-Value.
数人のパーティーと共に同じ解説者とExchange-値を使用するかもしれませんが、同じ係数とジェネレータが使用されていて、解説者がSHOULDであるときはいつも、無作為に変えてください。間隔。 バックグラウンドで実行中のプロセスは、新しい無作為の個人的に秘密の解説者を発生させて、定期的に古い値を破壊できます、そして、recalculateはExchange-値を発生させます。
Implementation Notes:
実現注意:
The size of the exponent is entirely implementation dependent, is
unknown to the other party, and can be easily changed.
解説者のサイズに実現に完全に依存していて、相手にとって未知であり、容易に変えることができます。
Since these operations involve several time-consuming modular
exponentiations, moving them to the "background" substantially
improves the apparent execution speed of the Photuris protocol.
It also reduces CPU loading sufficiently to allow a single
public/private key-pair to be used in several closely spaced
これらの操作がいくつかの手間がかかったモジュールの羃法にかかわるので、それらを「バックグラウンド」に動かすと、Photurisプロトコルの見かけの実行速度は実質的に改良されます。 また、公立の1/秘密鍵組が密接に区切られた数個で使用されるのを許容できるくらいそれはCPU荷重を抑えます。
Karn & Simpson Experimental [Page 52] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[52ページ]RFC2522Photurisは1999年3月に議定書を作ります。
Photuris executions, when creating Security Associations with
several different nodes over a short period of time.
短期間の間いくつかの異なったノードでSecurity Associationsを作成するときのPhoturis実行。
Other pre-computation suggestions are described in [BGMW93, LL94,
Rooij94].
他のプレ計算提案は[BGMW93、LL94、Rooij94]で説明されます。
8.5. Defective Exchange Values
8.5. 欠陥がある交換価値
Some exponents do not qualify as secret. The exponent 0 will generate the Exchange-Value 1, and the exponent 1 will generate the Exchange-Value g. Small exponents will be easily visible and SHOULD be avoided where:
秘密の資格を得ない解説者もいます。 解説者0は1、および解説者1が発生させるExchange-値を発生させるでしょう。Exchange-値のgを発生させてください。 小さい解説者が容易に目に見える、SHOULD、避けられてください、どこ:
g**x < p.
g**x<p。
Depending on the structure of the moduli, certain exponents can be used for sub-group confinement attacks. For "safe" primes (p = 2q+1), these exponents are p-1 and (p-1)/2, which will generate the Exchange-Values 1 and p-1 respectively.
係数の構造によって、サブグループ監禁攻撃に確信している解説者を使用できます。 「安全な」盛り(pは2q+1と等しい)のために、これらの解説者は、p-1と2(p-1)/歳です。(その歳はExchange-値の1とp-1をそれぞれ発生させるでしょう)。
When an implementation chooses a random exponent, the resulting Exchange-Value is examined. If the Exchange-Value is represented in less than half the number of significant bits in the modulus, then a new random exponent MUST be chosen.
実現が無作為の解説者を選ぶとき、結果として起こるExchange-値は調べられます。 Exchange-値が係数の重要なビットの半数以下に表されるなら、新しい無作為の解説者を選ばなければなりません。
For 512-bit moduli, Exchange-Values of 2**256 or greater are
required.
512ビットの係数において、2**の、よりExchange-値の256以上が必要です。
For 1024-bit moduli, Exchange-Values of 2**512 or greater are
required.
1024年のビットの係数において、2**の、よりExchange-値の512以上が必要です。
In addition, if the resulting Exchange-Value is p-1, then a new random exponent MUST be chosen.
さらに、結果として起こるExchange-値がp-1であるなら、新しい無作為の解説者を選ばなければなりません。
Upon receipt of an Exchange-Value that fails to meet the requirements, the Value Exchange message is silently discarded.
条件を満たさないExchange-値を受け取り次第、Value Exchangeメッセージは静かに捨てられます。
Implementation Notes:
実現注意:
Avoidance of small exponents can be assured by setting at least
one bit in the most significant half of the exponent.
半分の最もかなりの解説者に少なくとも1ビットをはめ込むことによって、小さい解説者の回避を保証できます。
Karn & Simpson Experimental [Page 53] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[53ページ]RFC2522Photurisは1999年3月に議定書を作ります。
9. Basic Exchange-Schemes
9. 基本的な交換計画
Initial values are assigned as follows:
初期の値は以下の通り割り当てられます:
(0) Reserved.
(0) 予約されました。
(1) Reserved.
(1) 予約されました。
(2) Implementation Required. 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.
(2) 実現が必要です。 2のお勧めのジェネレータ(g)があるどんな係数(p)。 Exchange-計画Sizeが非ゼロであるときに、係数はOffered-計画のリストのExchange-計画Value分野に保管されています。
An Exchange-Scheme Size of zero is invalid.
ゼロのExchange-計画Sizeは無効です。
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ビットの暗号の強さがある係数を必要とします。
(3) Exchange-Schemes 3 to 255 are intended for future well-known
published schemes.
(3) 交換計画の3〜255は将来の周知の発行された計画のために意図します。
(256) Exchange-Schemes 256 to 32767 are intended for vendor-specific
unpublished schemes. Implementors wishing a number MUST
request the number from the authors.
(256) 交換計画の256〜32767は業者特有の未発表の計画のために意図します。 数を願っている作成者は作者から数を要求しなければなりません。
(32768)
Exchange-Schemes 32768 to 65535 are available for cooperating
parties to indicate private schemes, regardless of vendor
implementation. These numbers are not reserved, and are
subject to duplication. Other criteria, such as the IP Source
and Destination of the Cookie_Request, are used to
differentiate the particular Exchange-Schemes available.
(32768) 協力パーティーが業者実現にかかわらず個人的な計画について簡単に述べるように、交換計画の32768〜65535は利用可能です。 これらの数は、予約されていなくて、複製を受けることがあります。 Cookie_RequestのIP SourceやDestinationなどの他の評価基準は、利用可能な特定のExchange-計画を微分するのに使用されます。
Karn & Simpson Experimental [Page 54] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[54ページ]RFC2522Photurisは1999年3月に議定書を作ります。
10. Basic Key-Generation-Function 10.1. MD5 Hash
10. 基本的な主要な世代機能10.1。 MD5細切れ肉料理
MD5 [RFC-1321] is used as a pseudo-random-function for generating the key(s). The key(s) begin with the most significant bits of the hash. MD5 is iterated as needed to generate the requisite length of key material.
MD5[RFC-1321]は、キーを発生させるのに疑似確率関数として使用されます。 キーは細切れ肉料理の最も重要なビットで始まります。 MD5は、必要な長さの主要な材料を発生させるように必要に応じて繰り返されます。
When an individual key does not use all 128-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.
個々のキーが最後の細切れ肉料理のすべての128ビットを使用するというわけではないなら、最後の細切れ肉料理のどんな残っている未使用(最も重要でない)のビットも捨てられます。 同じ目的のためのキー生成の他の用途に結合されると、次のキーは新しい細切れ肉料理繰り返しで始まるでしょう。
11. Basic Privacy-Method 11.1. Simple Masking
11. 基本的なプライバシー方法11.1。 簡単なマスキング
As described in "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.
「プライバシー主要な計算」で説明されるように、十分なプライバシー主要な材料はメッセージ長を合わせるために発生します、SPIの後の次の分野で始まって、Paddingを含んでいて。 メッセージはプライバシーキーでXORによってマスクをかけられます。
12. Basic Validity-Method 12.1. MD5-IPMAC Check
12. 基本的な正当性方法12.1。 MD5-IPMACはチェックします。
As described in "Validity Verification", the Verification field value is the MD5 [RFC-1321] hash over the concatenation of
「正当性検証」で説明されるように、Verification分野価値は連結の上のMD5[RFC-1321]細切れ肉料理です。
MD5( key, keyfill, data, datafill, key, md5fill )
MD5(キー、keyfill、データ、datafill、キー、md5fill)
where the key is the computed verification-key.
キーが計算された検証キーであるところ。
The keyfill and datafill use the same pad-with-length technique defined for md5fill. This padding and length is implicit, and does not appear in the datagram.
keyfillとdatafillはmd5fillのために定義された同じ長さがあるパッドのテクニックを使用します。 この詰め物と長さは、暗黙であり、データグラムに現れません。
The resulting Verification field is a 128-bit Variable Precision Integer (18 bytes including Size). When used in calculations, the Verification data includes both the Size and Value fields.
結果として起こるVerification分野は128ビットのVariable Precision Integer(Sizeを含む18バイト)です。 計算に使用されると、VerificationデータはSizeとValue分野の両方を含んでいます。
Karn & Simpson Experimental [Page 55] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[55ページ]RFC2522Photurisは1999年3月に議定書を作ります。
13. Basic Attributes
13. 基本的な属性
Implementors wishing a number MUST request the number from the authors. Initial values are assigned as follows:
数を願っている作成者は作者から数を要求しなければなりません。 初期の値は以下の通り割り当てられます:
Use Type
- 0* padding
- 1* AH-Attributes
- 2+ ESP-Attributes
AEI 5* MD5-IPMAC
AEIX 255+ Organizational
MD5-IPMAC AEIX255+組織的な状態でType--1*AH0*詰め物--属性--超能力2+属性AEI5*を使用してください。
A AH Attribute-Choice
E ESP Attribute-Choice
I Identity-Choice
X dependent on list location
+ feature must be recognized even when not supported
* feature must be supported (mandatory)
どんな支持された*特徴も支持さえしてはいけないとき、リスト位置+機能のAH Attribute-選択E超能力Attribute-選択I Identity-選択X扶養家族を見分けなければなりません。(義務的)です。
Other attributes are specified in companion documents.
他の属性は仲間ドキュメントで指定されます。
13.1. Padding
13.1. 詰め物
+-+-+-+-+-+-+-+-+ | Attribute | +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+ | 属性| +-+-+-+-+-+-+-+-+
Attribute 0
属性0
Each attribute may have value fields that are multiple bytes. To facilitate processing efficiency, these fields are aligned on integral modulo 8 byte (64-bit) boundaries.
各属性に、複数のバイトである値の分野があるかもしれません。 効率を処理するのを容易にするために、これらの分野は法の8バイト(64ビット)の不可欠の限界で並べられます。
Padding is accomplished by insertion of 1 to 7 Attribute 0 padding bytes before the attribute that needs alignment.
詰め物は整列を必要とする属性のバイト前にそっと歩く1〜7Attribute0の挿入で実行されます。
No padding is used after the final attribute in a list.
水増しは最終的な属性の後にリストで使用されません。
Karn & Simpson Experimental [Page 56] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[56ページ]RFC2522Photurisは1999年3月に議定書を作ります。
13.2. AH-Attributes
13.2. ああ、-、属性
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 属性| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute 1
属性1
Length 0
長さ0
When a list of Attributes is specified, this Attribute begins the section of the list which applies to the Authentication Header (AH).
Attributesのリストが指定されるとき、このAttributeはAuthentication Header(AH)に適用されるリストのセクションを始めます。
13.3. ESP-Attributes
13.3. 超能力属性
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute | Length | PayloadType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 属性| 長さ| PayloadType| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute 2
属性2
Length 1
長さ1
PayloadType 1 byte. Indicates the contents of the ESP Transform
Data field, using the IP Next Header (Protocol)
value. Up-to-date values of the IP Next Header
(Protocol) are specified in the most recent
"Assigned Numbers" [RFC-1700].
PayloadType1バイト。 IP Next Header(プロトコル)値を使用して、超能力Transform Data分野のコンテンツを示します。 最新の「規定番号」[RFC-1700]でIP Next Header(プロトコル)の最新の値は指定されます。
For example, when encrypting an entire IP datagram,
this field will contain the value 4, indicating IP-
in-IP encapsulation.
全体のIPデータグラムをコード化するとき、例えば、IPにおけるIPカプセル化を示して、この分野は値4を含むでしょう。
When a list of Attributes is specified, this Attribute begins the section of the list which applies to the Encapsulating Security Payload (ESP).
Attributesのリストが指定されるとき、このAttributeはEncapsulating Security有効搭載量(超能力)に適用されるリストのセクションを始めます。
When listed as an Offered-Attribute, the PayloadType is set to 255.
Offered-属性として記載されると、PayloadTypeは255に用意ができています。
When selected as an Attribute-Choice, the PayloadType is set to the actual value to be used.
Attribute-選択として選択されると、PayloadTypeは使用されるべき実価へのセットです。
Karn & Simpson Experimental [Page 57] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[57ページ]RFC2522Photurisは1999年3月に議定書を作ります。
13.4. MD5-IPMAC
13.4. MD5-IPMAC
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 属性| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute 5
属性5
Length 0
長さ0
13.4.1. Symmetric Identification
13.4.1. 左右対称の識別
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.
Identity-選択として選択されると、すぐに次のIdentification分野は不統一なVariable Precision Integerを含んでいます。 有効なIdentificationsと左右対称の秘密鍵はパーティーによってあらかじめ設定されます。
There is no required format or content for the Identification value. The value may be a number or string of any kind. See "Use of Identification and Secrets" for details.
Identification値のためのどんな必要な形式も内容もありません。 値は、どんな種類の数かストリングであるかもしれません。 詳細の「識別とシークレットの使用」を見てください。
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 64-bits of cryptographic strength.
左右対称の秘密鍵(指定されるとしての)はIdentification分野のコンテンツに基づいて選択されます。 すべての実現が少なくとも62バイトを支持しなければなりません。 選択された左右対称の秘密鍵SHOULDは少なくとも64ビットの暗号の強さを提供します。
As described in "Identity Verification", the Verification field value is the MD5 [RFC-1321] hash over the concatenation of:
「アイデンティティ検証」で説明されるように、Verification分野価値は以下の連結の上のMD5[RFC-1321]細切れ肉料理です。
MD5( key, keyfill, data, datafill, key, md5fill )
MD5(キー、keyfill、データ、datafill、キー、md5fill)
where the key is the computed verification-key.
キーが計算された検証キーであるところ。
The keyfill and datafill use the same pad-with-length technique defined for md5fill. This padding and length is implicit, and does not appear in the datagram.
keyfillとdatafillはmd5fillのために定義された同じ長さがあるパッドのテクニックを使用します。 この詰め物と長さは、暗黙であり、データグラムに現れません。
The resulting Verification field is a 128-bit Variable Precision Integer (18 bytes including Size). When used in calculations, the Verification data includes both the Size and Value fields.
結果として起こるVerification分野は128ビットのVariable Precision Integer(Sizeを含む18バイト)です。 計算に使用されると、VerificationデータはSizeとValue分野の両方を含んでいます。
For both "Identity Verification" and "Validity Verification", the verification-key is the MD5 [RFC-1321] hash of the following concatenated values:
「アイデンティティ検証」と「正当性検証」の両方に関しては、検証キーは以下の連結された値のMD5[RFC-1321]細切れ肉料理です:
Karn & Simpson Experimental [Page 58] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[58ページ]RFC2522Photurisは1999年3月に議定書を作ります。
+ the symmetric secret-key,
+ the computed shared-secret.
+ + 左右対称の秘密鍵、計算された共有秘密キー。
For "Session-Key Computation", the symmetric secret-key is used directly as the generation-key.
「セッション主要な計算」のために、左右対称の秘密鍵は直接世代キーとして使用されます。
Regardless of the internal representation of the symmetric secret- key, when used in calculations it is in the same form as the Value part of a Variable Precision Integer:
左右対称の秘密のキーの内部の表現にかかわらず、計算に使用されると、それはVariable Precision IntegerのValue部分と同じフォームにあります:
- most significant byte first.
- bits used are right justified within byte boundaries.
- any unused bits are in the most significant byte.
- unused bits are zero filled.
- 最も重要なバイト、1番目。 - 中古であるビットはバイト境界の中でまさしく正当です。 - 最も重要なバイトにはどんな未使用のビットもあります。 - 未使用のビットはいっぱいにされたゼロです。
The symmetric secret-key does not include a Size field.
左右対称の秘密鍵はSize分野を含んでいません。
13.4.2. Authentication
13.4.2. 認証
May be selected as an AH or ESP Attribute-Choice, pursuant to [RFC- 1828] et sequitur. The selected Exchange-Scheme SHOULD provide at least 64-bits of cryptographic strength.
AHか超能力のAttribute特選している[RFC1828]に従ってet sequiturとして選択されるかもしれません。 選択されたExchange-計画SHOULDは少なくとも64ビットの暗号の強さを提供します。
As described in "Session-Key Computation", the most significant 384- bits (48 bytes) of the Key-Generation-Function iterations are used for the key.
「セッション主要な計算」で説明されるように、Key世代機能繰り返しの最も重要な384ビット(48バイト)はキーに使用されます。
Profile:
以下の輪郭を描いてください。
When negotiated with Photuris, the transform differs slightly from
[RFC-1828].
Photurisと交渉されると、変換は[RFC-1828]と若干異なります。
The form of the authenticated message is:
認証されたメッセージのフォームは以下の通りです。
MD5( key, keyfill, datagram, datafill, key, md5fill )
MD5(キー、keyfill、データグラム、datafill、キー、md5fill)
where the key is the SPI session-key.
キーがSPIセッションキーであるところ。
The additional datafill protects against the (impractical) attack
described in [PO96]. The keyfill and datafill use the same pad-
with-length technique defined for md5fill. This padding and
length is implicit, and does not appear in the datagram.
追加datafillは[PO96]で説明された(非実用的)の攻撃から守ります。 keyfillとdatafillは長さがあるmd5fillのために定義された同じパッドのテクニックを使用します。 この詰め物と長さは、暗黙であり、データグラムに現れません。
Karn & Simpson Experimental [Page 59] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[59ページ]RFC2522Photurisは1999年3月に議定書を作ります。
13.5. Organizational
13.5. 組織的
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute | Length | OUI
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | Kind | Value(s) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 属性| 長さ| OUI+++++++++++++++++++++++++++++++++… | 種類| 値… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute 255
属性255
Length >= 4
長さの>=4
When the Length is four, no Value(s) field is
present.
Lengthが4歳であるときに、どんなValue(s)分野も存在していません。
OUI 3 bytes. The vendor's Organizationally Unique
Identifier, assigned by IEEE 802 or IANA (see [RFC-
1700] for contact details). The bits within the
byte are in canonical order, and the most
significant byte is transmitted first.
OUI3バイト。 IEEE802かIANA(詳細な連絡先に関して[RFC1700]を見る)によって割り当てられた業者のOrganizationally Unique Identifier。 バイトの中のビットが正準なオーダーにあります、そして、最も重要なバイトは最初に、伝えられます。
Kind 1 byte. Indicates a sub-type for the OUI. There is
no standardization for this field. Each OUI
implements its own values.
親切な1バイト。 OUIのためにサブタイプを示します。 この分野のための標準化が全くありません。 各OUIはそれ自身の値を実行します。
Value(s) 0 or more bytes. The details are implementation
specific.
(s) 0バイト以上を評価してください。 詳細は実現特有です。
Some implementors might not need nor want to publish their proprietary algorithms and attributes. This OUI mechanism is available to specify these without encumbering the authors with proprietary number requests.
何人かの作成者は、必要があって、彼らの独占アルゴリズムと属性を発行したがっていないかもしれません。 このOUIメカニズムは、独占数の要求で作者を苦しめないでこれらを指定するために利用可能です。
Karn & Simpson Experimental [Page 60] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[60ページ]RFC2522Photurisは1999年3月に議定書を作ります。
A. Automaton
A。 オートマトン
An example automaton is provided to illustrate the operation of the protocol. It is incomplete and non-deterministic; many of the Good/Bad semantic decisions are policy-based or too difficult to represent in tabular form. Where conflicts appear between this example and the text, the text takes precedence.
プロトコルの操作を例証するために例のオートマトンを提供します。 それは、不完全であって、非決定論的です。 Good/悪い意味決定の多くが、方針ベースである、または表にして表すことができないくらい難しいです。 闘争がこの例とテキストの間に載っているところに、テキストは優先します。
The finite-state automaton is defined by events, actions and state transitions. Events include reception of external commands such as expiration of a timer, and reception of datagrams from a peer. Actions include the starting of timers and transmission of datagrams to the peer.
有限状態オートマトンは出来事、動作、および状態遷移で定義されます。 出来事はタイマの満了などの外部のコマンドのレセプション、および同輩からのデータグラムのレセプションを含んでいます。 動作はタイマの始めとデータグラムのトランスミッションを同輩に含んでいます。
Events
出来事
DU13 = Communication Administratively Prohibited SF0 = Bad SPI SF4 = Need Authentication SF5 = Need Authorization WC = Want Confidentiality
必要性認可必要性認証悪い行政上禁止されたDU13=コミュニケーションSF0=SPI SF4=SF5=トイレ=は秘密性を必要とします。
RCQ+ = Receive Cookie_Request (Good) RCQ- = Receive Cookie_Request (Bad) RCR+ = Receive Cookie_Response (Good) RCR- = Receive Cookie_Response (Bad)
RCQ+=がRCQ=が(悪い)のRCR+=が(良い)のRCR=が受けるクッキー_応答を受けるというクッキー_要求を受け取るというクッキー_要求(利益)を受け取る、クッキー_応答(悪い)です。
RVQ+ = Receive Value_Request (Good) RVQ- = Receive Value_Request (Bad) RVR+ = Receive Value_Response (Good) RVR- = Receive Value_Response (Bad)
RVQ+=がRVQ=が(悪い)のRVR+=が(良い)のRVR=が受ける値_応答を受けるという値_要求を受け取るという値_要求(利益)を受け取る、_応答を評価してください。(悪い)です。
RIQ+ = Receive Identity_Request (Good) RIQ- = Receive Identity_Request (Bad) RIR+ = Receive Identity_Response (Good) RIR- = Receive Identity_Response (Bad)
RIQ+=がRIQ=が(悪い)のRIR+=が(良い)のRIR=が受けるアイデンティティ_応答を受けるというアイデンティティ_要求を受け取るというアイデンティティ_要求(利益)を受け取る、アイデンティティ_応答(悪い)です。
RUN+ = Receive SPI_Needed (Good) RUN- = Receive SPI_Needed (Bad) RUM+ = Receive SPI_Update (Good) RUM- = Receive SPI_Update (Bad)
走行+=がSPIを受ける、_必要な=が受ける走行の(良い)のSPI_(ひどい)必要なラム+=は=が受けるラムSPI_がアップデートするSPI_アップデート(利益)を受けます。(悪い)です。
RBC = Receive Bad Cookie RRL = Receive Resource Limit RVF = Receive Verification Failure RMR = Receive Message Reject
RBC=がRRL=が受ける腐っているクッキーを受ける、リソース限界RVF=がRMR=が受ける検証失敗を受ける、メッセージ廃棄物
TO+ = Timeout with counter > 0
カウンタ>0があるTO+=タイムアウト
Karn & Simpson Experimental [Page 61] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[61ページ]RFC2522Photurisは1999年3月に議定書を作ります。
TO- = Timeout with counter expired UTO = Update TimeOut XTO = Exchange TimeOut
TO= カウンタがあるタイムアウトは交換アップデートUTO=TimeOut XTO=TimeOutを吐き出しました。
Actions
動作
scq = Send Cookie_Request scr = Send Cookie_Response
scq=はRequest scr=がCookie_Responseを送るCookie_を送ります。
svq = Send Value_Request svr = Send Value_Response
svq=はRequest svr=がValue_Responseを送るValue_を送ります。
siq = Send Identity_Request sir = Send Identity_Response
siq=は=がIdentity_Responseを送るIdentity_Requestサーを送ります。
sum = Send SPI_Update
合計=はSPI_Updateを送ります。
se* = Send error message (see text) sbc = Send Bad Cookie srl = Send Resource Limit svf = Send Verification Failure
送信エラーメッセージ(テキストを見る)sbc=がBad Cookie srl=を送るse*=は=がVerification Failureを送るResource Limit svfを送ります。
brto = Backoff Retransmission TimeOut buto = Backoff Update TimeOut rto = Set Retransmission TimeOut uto = Set Update TimeOut xto = Set Exchange TimeOut
セットセットbrto=Backoff Retransmission TimeOut buto=Backoff Update TimeOut rto=Retransmission TimeOut uto=Update TimeOut xtoはセットExchange TimeOutと等しいです。
log = log operator message
ログ=ログオペレータメッセージ
A.1. State Transition Table
A.1。 状態遷移テーブル
States are indicated horizontally, and events are read vertically.
State transitions and actions are represented in the form
action/new-state. Multiple actions are separated by commas, and may
continue on succeeding lines as space requires; multiple actions may
be implemented in any convenient order. The state may be followed by
a letter, which indicates an explanatory footnote. The dash ('-')
indicates an illegal transition.
州は水平に示されます、そして、出来事は垂直に読まれます。 状態遷移と動作はフォームに新しい動作/状態で表されます。 複数の動作が、コンマによって切り離されて、スペースが必要であるように続く線の上で続くかもしれません。 複数の動作がどんな便利なオーダーでも実行されるかもしれません。 手紙は状態を支えるかもしれません。(それは、脚注を示します)。 ダッシュ('--')は不法な変遷を示します。
Karn & Simpson Experimental [Page 62] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[62ページ]RFC2522Photurisは1999年3月に議定書を作ります。
Initiator
創始者
| 0 1 2 3 4
| Initial Cookie CookieBad Value ValueBad
------+--------------------------------------------------
DU13 |rto,scq/1 rto,scq/1 rto,scq/1 3 4
SF0 |rto,scq/1 1 2 3 4
SF4 |rto,scq/1 1 2 3 4
SF5 |rto,scq/1 1 2 3 4
WC |rto,scq/1 1 2 3 4
|
RCR+ | - rto,svq/3 rto,svq/3 3 4
RCR- | 0 1 2 3 4
RVR+ | - - - rto,siq/5 rto,siq/5
RVR- | 0 1 2 3 4
RIR+ | - - - - -
RIR- | 0 1 2 3 4
|
RUN+ | - - - - -
RUN- | sbc/0 sbc/1 sbc/2 sbc/3 sbc/4
RUM+ | - - - - -
RUM- | sbc/0 sbc/1 sbc/2 sbc/3 sbc/4
|
RBC | - - - 4 4
RRL | - brto/2 brto/2 brto/4 brto/4
RVF | - - - - -
RMR | - - - - -
|
TO+ | - scq/1 scq/2 svq/3 svq/4
TO- | - 0 scq/1 0 scq/1
UTO | - - - - -
XTO | - 0 0 0 0
| 0 1 2 3 4 | 初期のクッキーCookieBad値のValueBad------+-------------------------------------------------- DU13|rto、scq/1rto、scq/1rto、scq/1 3 4SF0|rto、scq/1 1 2 3 4SF4|rto、scq/1 1 2 3 4SF5|rto、scq/1 1 2 3 4トイレ|rto、scq/1 1 2 3 4| RCR+| - rto、svq/3rto、svq/3 3 4RCR| 0 1 2 3 4RVR+| - - - rto、siq/5rto、siq/5RVR| 0 1 2 3 4RIR+| - - - - - RIR| 0 1 2 3 4 | 走行+| - - - - - 走ってください。| sbc/0sbc/1sbc/2sbc/3sbc/4RUM+| - - - - - ラム| sbc/0sbc/1sbc/2sbc/3sbc/4| RBC| - - - 4 4RRL| - brto/2brto/2brto/4brto/4RVF| - - - - - RMR| - - - - - | +に| - scq/1scq/2svq/3svq/4TO| - 0 scq/1 0scq/1UTO| - - - - - XTO| - 0 0 0 0
Karn & Simpson Experimental [Page 63] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[63ページ]RFC2522Photurisは1999年3月に議定書を作ります。
Initiator
創始者
| 5 6 8
|Identity IdentityBad Update
------+-----------------------------
DU13 | 5 6 8
SF0 | 5 6 rto,scq/1
SF4 | 5 6 rto,scq/1
SF5 | 5 6 rto,scq/1
WC | 5 6 sun/8
|
RCR+ | 5 6 8
RCR- | 5 6 8
RVR+ | 5 6 8
RVR- | 5 6 8
RIR+ | uto/8 uto/8 8
RIR- | svf/5 svf/6 8
|
RUN+ | - - sum/8
RUN- | sbc/5 sbc/6 se*/8
RUM+ | - - 8
RUM- | sbc/5 sbc/6 se*/8
|
RBC | 6 6 rto,scq/1
RRL | 5 6 buto/8
RVF | log/5 log/6 log/8
RMR | log/5 log/6 log/8
|
TO+ | sim/5 sim/6 -
TO- | 0 scq/1 -
UTO | - - sum/8
XTO | 0 0 0
| 5 6 8 |アイデンティティIdentityBadアップデート------+----------------------------- DU13| 5 6 8SF0| 5 6rto、scq/1SF4| 5 6rto、scq/1SF5| 5 6rto、scq/1トイレ| 5 6太陽/8| RCR+| 5 6 8RCR| 5 6 8RVR+| 5 6 8RVR| 5 6 8RIR+| uto/8uto/8 8RIR| svf/5svf/6 8| 走行+| - - 合計/8RUN| sbc/5sbc/6se*/8RUM+| - - 8 ラム| sbc/5sbc/6se*/8| RBC| 6 6rto、scq/1RRL| 5 6buto/8RVF| ログ/5ログ/6ログ/8RMR| ログ/5ログ/6ログ/8| +に| sim/5sim/6--TO| 0 scq/1--UTO| - - 合計/8XTO| 0 0 0
Karn & Simpson Experimental [Page 64] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[64ページ]RFC2522Photurisは1999年3月に議定書を作ります。
Responder
応答者
| 0 7 8
| Initial Ready Update
------+-----------------------------
WC | - 7 sun/8
|
RCQ+ | scr/0 scr/7 scr/8
RCQ- | srl/0 srl/7 srl/8
RVQ+ |xto,svr/7 svr/7 svr/8
RVQ- | sbc/0 sbc/7 sbc/8
RIQ+ | - uto,sir/8 sir/8
RIQ- | sbc/0 se*/7 se*/8
|
RUN+ | - - sum/8
RUN- | sbc/0 sbc/7 se*/8
RUM+ | - - 8
RUM- | sbc/0 sbc/7 se*/8
|
RBC | - 7 rto,scq/1
RRL | - - buto/8
RVF | - - log/8
RMR | - - log/8
|
UTO | - - sum/8
XTO | - 0 0
| 0 7 8 | 初期の持ち合わせのアップデート------+----------------------------- トイレ| - 7 太陽/8| RCQ+| scr/0scr/7scr/8RCQ| srl/0srl/7srl/8RVQ+|xto、svr/7svr/7svr/8RVQ| sbc/0sbc/7sbc/8RIQ+| - uto、旦那/8旦那/8RIQ| sbc/0se*/7se*/8| 走行+| - - 合計/8RUN| sbc/0sbc/7se*/8RUM+| - - 8 ラム| sbc/0sbc/7se*/8| RBC| - 7 rto、scq/1RRL| - - buto/8RVF| - - ログ/8RMR| - - ログ/8| 宇土| - - 合計/8XTO| - 0 0
A.2. States
A.2。 状態
Following is a more detailed description of each automaton state.
以下に、それぞれのオートマトン状態の、より詳細な記述があります。
The "Bad" version of a state is to indicate that the Bad_Cookie or Resource_Limit message has been received.
状態の「悪い」バージョンはBad_CookieかResource_Limitメッセージが受け取られたのを示すことです。
A.2.1. Initial
A.2.1。 初期
The Initial state is fictional, in that there is no state between the parties.
パーティーの間には、状態が全くないので、Initial状態は作り事です。
Karn & Simpson Experimental [Page 65] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[65ページ]RFC2522Photurisは1999年3月に議定書を作ります。
A.2.2. Cookie
A.2.2。 クッキー
In the Cookie state, the Initiator has sent a Cookie_Request, and is waiting for a Cookie_Response. Both the Restart and Exchange timers are running.
Cookie状態では、InitiatorはCookie_Requestを送って、Cookie_Responseを待っています。 RestartとExchangeタイマの両方が動いています。
Note that the Responder has no Cookie state.
ResponderにはCookie状態が全くないことに注意してください。
A.2.3. Value
A.2.3。 値
In the Value state, the Initiator has sent its Exchange-Value, and is waiting for an Identity_Message. Both the Restart and Exchange timers are running.
Value状態では、InitiatorはExchange-値を送って、Identity_Messageを待っています。 RestartとExchangeタイマの両方が動いています。
A.2.4. Identity
A.2.4。 アイデンティティ
In the Identity state, the Initiator has sent an Identity_Request, and is waiting for an Identity_Response in reply. Both the Restart and Exchange timers are running.
Identity状態では、InitiatorはIdentity_Requestを送って、回答でIdentity_Responseを待っています。 RestartとExchangeタイマの両方が動いています。
A.2.5. Ready
A.2.5。 準備ができる
In the Ready state, the Responder has sent its Exchange-Value, and is waiting for an Identity_Message. The Exchange timer is running.
Ready状態では、ResponderはExchange-値を送って、Identity_Messageを待っています。 Exchangeタイマは動いています。
A.2.6. Update
A.2.6。 アップデート
In the Update state, each party has concluded the Photuris exchange, and is unilaterally updating expiring SPIs until the Exchange LifeTime expires. Both the Update and Exchange timers are running.
Update状態では、各当事者は、Photuris交換を結論づけて、Exchange LifeTimeが期限が切れるまで、一方的に期限が切れているSPIsをアップデートしています。 UpdateとExchangeタイマの両方が動いています。
Karn & Simpson Experimental [Page 66] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[66ページ]RFC2522Photurisは1999年3月に議定書を作ります。
B. Use of Identification and Secrets
B。 識別とシークレットの使用
Implementation of the base protocol requires support for operator configuration of participant identities and associated symmetric secret-keys.
ベースプロトコルの実装は関与しているアイデンティティと関連左右対称の秘密鍵のオペレータ構成に支持を要します。
The form of the Identification and Secret fields is not constrained to be a readable string. In addition to a simpler quoted string configuration, an implementation MUST allow configuration of an arbitrary stream of bytes.
IdentificationとSecret分野のフォームは読み込み可能なストリングであることが抑制されません。 より簡単な引用文字列構成に加えて、実装はバイトの任意のストリームの構成を許さなければなりません。
B.1. Identification
B.1。 識別
Typically, the Identification is a user name, a site name, a Fully Qualified Domain Name, or an email address which contains a user name and a domain name. Examples include:
Identificationは通常、ユーザ名、サイト名、Fully Qualified Domain Name、またはユーザ名とドメイン名を含むEメールアドレスです。 例は:
user
node.site.
user@node.site.
rcmd@node.site.
"Mundane Name" <user@node.site>
ユーザnode.site user@node.site rcmd@node.site。 「世俗的な名前、「 <user@node.site 、gt;、」
There is no requirement that the domain name match any of the particular IP addresses in use by the parties.
ドメイン名がパーティーで特定のIPアドレスのどれかに使用中に合っているという要件が全くありません。
B.2. Group Identity With Group Secret
B.2。 グループ秘密があるグループのアイデンティティ
A simple configuration approach could use a single Identity and Secret, distributed to all the participants in the trusted group. This might be appropriate between routers under a single administration comprising a Virtual Private Network over the Internet.
簡単な構成アプローチは独身のIdentityと信じられたグループで参加者各位に分配されたSecretを使用するかもしれません。 これはルータの間でインターネットの上でVirtual兵士のNetworkを包括するただ一つの管理の下で適切であるかもしれません。
Nota Bene:
The passwords used in these examples do not meet the "MD5-IPMAC
Symmetric Identification" recommendation for at least 64-bits of
cryptographic strength.
背板嘆願: これらの例で使用されるパスワードは少なくとも64ビットの暗号の強さのための「MD5-IPMACの左右対称の識別」推薦を満たしません。
The administrator configures each router with the same username and password:
管理者は同じユーザ名とパスワードで各ルータを構成します:
identity local "Tiny VPN 1995 November" "abracadabra"
identity remote "Tiny VPN 1995 November" "abracadabra"
アイデンティティの地方の「VPN1995の小さい11月」「アブラカダブラ」アイデンティティのリモート「VPN1995の小さい11月」「アブラカダブラ」
When the Initiator sends its Identity_Request, the SPI Owner
InitiatorがIdentity_Request、SPI Ownerを送るとき
Karn & Simpson Experimental [Page 67] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[67ページ]RFC2522Photurisは1999年3月に議定書を作ります。
Identification field is "Tiny VPN 1995 November" and the SPI Owner secret-key is "abracadabra".
識別分野は「VPN1995の小さい11月」です、そして、SPI Owner秘密鍵は「アブラカダブラ」です。
When the Responder sends its Identity_Response, the SPI Owner Identification field is "Tiny VPN 1995 November" and the SPI Owner secret-key is "abracadabra". The SPI User Identification is "Tiny VPN 1995 November" (taken from the request), and the SPI User secret-key is "abracadabra".
ResponderがIdentity_Responseを送るとき、SPI Owner Identification分野は「VPN1995の小さい11月」です、そして、SPI Owner秘密鍵は「アブラカダブラ」です。 SPI User Identificationは「VPN1995の小さい11月」(要求から、取る)です、そして、SPI User秘密鍵は「アブラカダブラ」です。
Note that even in the face of implementations with very poor random number generation yielding the same random numbers for both parties at every step, and with this completely identical configuration, the addition of the SPI User Verification field in the response calculation is highly likely to produce a different Verification value (see "Identity Verification"). In turn, the different Verification values affect the calculation of SPI session-keys that are highly likely to be different in each direction (see "Session-Key Computation").
至る所に双方のための同じ乱数をもたらす非常に貧しい乱数発生、およびこの完全に同じ構成がある実装に直面してさえ応答計算におけるSPI User Verification分野の追加が異なったVerification値を非常に生産しそうに注意してください(「アイデンティティ検証」を見てください)。 順番に、異なったVerification値は非常に各方向に異なる傾向があるSPIセッションキーの計算に影響します(「セッション主要な計算」を見てください)。
B.3. Multiple Identities With Group Secrets
B.3。 グループシークレットがある複数のアイデンティティ
A more robust configuration approach could use a separate Identity and Secret for each party, distributed to the participants in the trusted group. This might be appropriate for authenticated firewall traversal.
より体力を要している構成アプローチは信じられたグループの関係者に分配された各当事者に別々のIdentityとSecretを使用するかもしれません。 認証されたファイアウォール縦断に、これは適切であるかもしれません。
An administrator has one or more networks, and a number of mobile users. It is desirable to restrict access to authorized external users. The example boundary router is 10.0.0.1.
管理者には、1つ以上のネットワーク、および多くのモバイルユーザがいます。 アクセスを認可された社外利用者に制限するのは望ましいです。 例の境界ルータはそうです。10.0 .0 .1。
The administrator gives each user a different username and password, together with a group username and password for the router.
管理者はルータのためのグループユーザ名とパスワードと共に異なったユーザ名とパスワードを各ユーザに与えます。
The administrator configures (in part):
管理者は以下を構成します(一部)。
identity local "199511@router.site" "FalDaRah"
identity remote "Happy_Wanderer@router.site" "FalDaRee"
アイデンティティの地方の" 199511@router.site ""FalDaRah"のアイデンティティリモートな" Happy_Wanderer@router.site ""FalDaRee"
Each mobile user adds commands to tunnel and authenticate.
それぞれのモバイルユーザはトンネルを堀って、認証するコマンドを加えます。
route addprivate 10.0.0.0/8 tunnel 10.0.0.1
secure 10.0.0.1 authenticate-only
identity local "Happy_Wanderer@router.site" "FalDaRee"
identity remote "199511@router.site" "FalDaRah"
identity remote "199512@router.site" "FalDaHaHaHaHaHaHa"
.1が10.0に.0を保証するaddprivate10.0.0.0/8トンネル10.0.0を発送してください、.1、認証、-単に、地方のアイデンティティの"FalDaRee"アイデンティティリモート" 199511@router.site ""FalDaRah"の" Happy_Wanderer@router.site "アイデンティティリモートな" 199512@router.site ""FalDaHaHaHaHaHaHa"
When the mobile Initiator sends its Identity_Request, the SPI Owner
モバイルInitiatorがIdentity_Request、SPI Ownerを送るとき
Karn & Simpson Experimental [Page 68] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[68ページ]RFC2522Photurisは1999年3月に議定書を作ります。
Identification field is "Happy_Wanderer@router.site" and the SPI Owner secret-key is "FalDaRee".
識別分野は" Happy_Wanderer@router.site "です、そして、SPI所有者秘密鍵は"FalDaRee"です。
When the firewall Responder sends its Identity_Response, the SPI Owner Identification field is "199511@router.site" and the SPI Owner secret-key is "FalDaRah". The SPI User Identification field is "Happy_Wanderer@router.site" (taken from the request), and the SPI User secret-key is "FalDaRee".
ファイアウォールResponderがIdentity_Responseを送るとき、SPI Owner Identification分野は" 199511@router.site "です、そして、SPI所有者秘密鍵は"FalDaRah"です。 SPI User Identification分野は" Happy_Wanderer@router.site "(要求から、取る)です、そして、SPIユーザ秘密鍵は"FalDaRee"です。
In this example, the mobile user is already prepared for a monthly password changeover, where the router might identify itself as "199512@router.site".
この例では、モバイルユーザは毎月のパスワード転換のために既に用意ができています、ルータが、それ自体が" 199512@router.site "であると認識するかもしれないところで。
B.4. Multiple Identities With Multiple Secrets
B.4。 複数のシークレットがある複数のアイデンティティ
Greater security might be achieved through configuration of a pair of secrets between each party. As before, one secret is used for initial contact to any member of the group, but another secret is used between specific parties. Compromise of one secret or pair of secrets does not affect any other member of the group. This might be appropriate between the routers forming a boundary between cooperating Virtual Private Networks that establish local policy for each VPN member access.
大セキュリティは各当事者の間の1組の秘密の構成を通して達成されるかもしれません。 従来と同様、1つの秘密がグループのどんなメンバーへの初期接触にも使用されますが、別の秘密は特定のパーティーの間で使用されます。 1秘密か組の秘密の感染はグループのいかなる他のメンバーにも影響しません。 これはルータの間でそれぞれのVPNメンバーアクセサリーのためにローカルの方針を確立する協力関係を持っているVirtual兵士のNetworksの間の境界を形成するのにおいて適切であるかもしれません。
One administrator configures:
1人の管理者が以下を構成します。
identity local "Apple" "all for one"
identity local "Apple-Baker" "Apple to Baker" "Baker"
identity remote "Baker" "one for all"
identity remote "Baker-Apple" "Baker to Apple"
「すべて個人的には」という地方の地方のアイデンティティの「アップル-ベイカー」「ベイカーへのアップル」「ベイカー」アイデンティティリモート「ベイカー」「アップル」アイデンティティ「すべてのためのもの」アイデンティティリモートな「ベイカー-アップル」「アップルへのベイカー」
Another configures:
別のものは以下を構成します。
identity local "Baker" "one for all"
identity local "Baker-Apple" "Baker to Apple" "Apple"
identity remote "Apple" "all for one"
identity remote "Apple-Baker" "Apple to Baker"
「すべて個人的には」という地方の地方のアイデンティティのアイデンティティリモート「アップル」アイデンティティリモート「ベイカー」「すべてのためのもの」アイデンティティ「ベイカー-アップル」「アップルへのベイカー」「アップル」「アップル-パン屋」「ベイカーへのアップル」
When the Initiator sends its Identity_Request, the SPI Owner Identification field is "Apple" and the SPI Owner secret-key is "all for one".
InitiatorがIdentity_Requestを送るとき、SPI Owner Identification分野は「アップル」です、そして、SPI Owner秘密鍵は「すべて個人的には」アップルです。
When the Responder sends its Identity_Response, finding that the special pairing exists for "Apple" (in this example, indicated by a third field), the SPI Owner Identification field is "Baker-Apple" and the SPI Owner secret-key is "Baker to Apple". The SPI User Identification is "Apple" (taken from the request), and the SPI User
特別な組み合わせが「アップル」のために存在するのがわかって、ResponderがIdentity_Responseを送るとき(3番目の分野によって示されたこの例で)、SPI Owner Identification分野は「ベイカー-アップル」です、そして、SPI Owner秘密鍵は「アップルへのベイカー」です。 SPI User Identificationは「アップル」(要求から、取る)と、SPI Userです。
Karn & Simpson Experimental [Page 69] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[69ページ]RFC2522Photurisは1999年3月に議定書を作ります。
secret-key is "all for one".
秘密鍵は「すべて個人的には」そうです。
Operational Considerations
操作上の問題
The specification provides only a few configurable parameters, with defaults that should satisfy most situations.
仕様はほとんどの状況を満たすべきであるデフォルトにほんのいくつかの構成可能なパラメタを提供します。
Retransmissions
Default: 3.
Retransmissionsはデフォルトとします: 3.
Initial Retransmission TimeOut (IRTO)
Default: 5 seconds.
初期の再送タイムアウト(IRTO)はデフォルトとします: 5秒。
Exchange TimeOut (ETO)
Default: 30 seconds. Minimum: Retransmissions * IRTO.
交換タイムアウト(ETO)はデフォルトとします: 30秒。 最小限: Retransmissions*IRTO。
Exchange LifeTime (ELT)
Default: 30 minutes. Minimum: 2 * ETO.
生涯(ELT)デフォルトを交換してください: 30 書き留めます。 最小限: 2*江藤。
SPI LifeTime (SPILT)
Default: 5 minutes. Minimum: 3 * ETO.
SPI生涯(こぼされる)デフォルト: 5 書き留めます。 最小限: 3*江藤。
Each party configures a list of known identities and symmetric secret-keys.
各当事者は知られているアイデンティティと左右対称の秘密鍵のリストを構成します。
In addition, each party configures local policy that determines what access (if any) is granted to the holder of a particular identity. For example, the party might allow anonymous FTP, but prohibit Telnet. Such considerations are outside the scope of this document.
さらに、各当事者は特定のアイデンティティの所有者のどんなアクセス(もしあれば)が承諾されるかを決定するローカルの方針を構成します。 例えば、パーティーは公開FTPを許容するかもしれませんが、Telnetを禁止してください。 このドキュメントの範囲の外にそのような問題があります。
Security Considerations
セキュリティ問題
Photuris was based on currently available tools, by experienced network protocol designers with an interest in cryptography, rather than by cryptographers with an interest in network protocols. This specification is intended to be readily implementable without requiring an extensive background in cryptology.
Photurisは現在利用可能なツールに基づきました、ネットワーク・プロトコルへの関心をもっている暗号使用者でというよりむしろ暗号への関心をもっている経験豊富なネットワーク・プロトコルデザイナーで。 この仕様が容易に暗号理論の大規模なバックグラウンドを必要としないで実装可能であることを意図します。
Therefore, only minimal background cryptologic discussion and rationale is included in this document. Although some review has been provided by the general cryptologic community, it is anticipated that design decisions and tradeoffs will be thoroughly analysed in subsequent dissertations and debated for many years to come.
バックグラウンドの最小量のcryptologic議論と原理だけが本書では含まれています。 何らかのレビューが一般的なcryptologic共同体によって提供されましたが、デザイン決定と見返りがその後の論文で徹底的に分析されて、これから何年も討論されると予期されます。
Cryptologic details are reserved for separate documents that may be more readily and timely updated with new analysis.
Cryptologicの詳細は、より容易とタイムリーに新しい分析でアップデートされるかもしれない別々のドキュメントのために予約されます。
Karn & Simpson Experimental [Page 70] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[70ページ]RFC2522Photurisは1999年3月に議定書を作ります。
History
歴史
The initial specification of Photuris, now called version 1 (December 1994 to March 1995), was based on a short list of design requirements, and simple experimental code by Phil Karn. Only one modular exponentiation form was used, with a single byte index of pre-specified group parameters. The transform attributes were selected during the public value exchange. Party privacy was protected in the identification signature exchange with standard ESP transforms.
Photurisの初期の現在バージョン1(1994年12月から1995年3月までの)と呼ばれた仕様は設計の品質の短いリスト、およびフィルKarnによる簡単な実験コードに基づきました。 1つのモジュールの羃法フォームだけがあらかじめ指定されたグループパラメタのただ一つのバイト・インデックスと共に使用されました。 変換属性は公共の値の交換の間、選択されました。 パーティプライバシーは標準の超能力変換による識別署名交換で保護されました。
Upon submission for review by the IP Security Working Group, a large number of features were demanded. A mere 254 future group choices were not deemed enough; it was expanded to two bytes (and renamed schemes), and was expanded again to carry variable parameters. The transform attributes were made variable length to accomodate optional parameters. Every other possible parameter was made negotiable. Some participants were unable to switch modes on the UDP sockets to use standard ESP transforms for only some messages, and party privacy was integrated into the protocol. The message headers were reorganized, and selection of transform attributes was delayed until the identification exchange. An additional update message phase was added.
IP Security作業部会によるレビューのために提出のときに、多くの特徴が要求されました。 254の単なる将来のグループ選択は十分考えられませんでした。 それは、2バイト(そして、体系に改名される)に広げられて、可変パラメタを運ぶために再び広げられました。 変換属性はaccomodateの任意のパラメタへの人工の可変長でした。 他のあらゆる可能なパラメタを交渉可能にしました。 何人かの関係者はいくつかだけのメッセージに標準の超能力変換を使用するためにUDPソケットでモードを切り換えることができませんでした、そして、パーティープライバシーはプロトコルと統合されました。 メッセージヘッダーは再編成されました、そして、変換属性の品揃えは識別交換まで遅れました。 追加アップデートメッセージフェーズは加えられました。
Version 2 (July 1995 to December 1995) specification stability was achieved in November 1995 by moving most parameters into separate documents for later discussion, and leaving only a few mandatory features in the base specification. Within a month, multiple interoperable implementations were produced.
バージョン2(1995年7月から1995年12月までの)仕様の安定性は、1995年11月にほとんどのパラメタを後の議論のための別々のドキュメントに動かして、基礎仕様にほんのいくつかの義務的な特徴を残すことによって、達成されました。 1カ月以内に、複数の共同利用できる実装が生産されました。
Unfortunately, in a fit of demagoguery, the IP Security Working Group decided in a straw poll to remove party privacy protection, and the Working Group chair terminated the meeting without allowing further discussion. Because the identification exchange messages required privacy to function correctly, the messages were reorganized again. Party privacy and other optional schemes were split into a separate document.
残念ながら、デマの発作では、IP Security作業部会は、非公式世論調査でパーティープライバシー保護を取り除くと決めました、そして、さらなる議論を許容しないで、作業部会いすはミーティングを終えました。 識別交換メッセージが、プライバシーが正しく機能するのを必要としたので、メッセージは再び再編成されました。 パーティプライバシーと他の任意の体系は別々のドキュメントに分けられました。
The implementors established a separate discussion group. Version 3 (April 1996 to June 1997) enjoyed a long period of specification stability and multiple implementations on half a dozen platforms.
作成者は別々のディスカッション・グループを設立しました。 バージョン3(1996年4月から1997年6月までの)は半ダース個のプラットホームの仕様の安定性と複数の実装の長期を楽しみました。
Meanwhile, the IP Security Working Group has developed a competing specification with large numbers of negotiable parameters. Also, the PPP Extensions Working Group has deployed link security transforms.
その間、IP Security作業部会は多くの交渉可能なパラメタで競争している仕様を開発しました。 また、PPP Extensions作業部会は、リンクセキュリティが変換であると配布しました。
Version 4 (July 1997 onward) attempts to maintain a semblance of interface compatibility with these other efforts. Minor changes are
バージョン4、(7月、1997 前方へ)、これらの他の努力とのインタフェースの互換性の類似を維持する試み。 マイナーチェンジはそうです。
Karn & Simpson Experimental [Page 71] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[71ページ]RFC2522Photurisは1999年3月に議定書を作ります。
specified in transform padding format and key generation. More than one value is permitted per scheme, giving greater latitude in choice for future extensions. The opportunity is taken to return party privacy to the base document, and make small semantic changes in automated updates and error recovery. All ESP transform attributes are moved to separate documents, to (hopefully) avoid future incompatible changes to the base document.
形式とキー生成を水増しする変換では、指定されています。 今後の拡大のための選択における、より大きい緯度を与えて、1つ以上の値が計画単位で受入れられます。 機会は元にした文書へのリターンパーティープライバシーに始めて、自動化されたアップデートとエラー回復における小さい意味変化を作ることです。 すべての超能力変換属性が、(希望をいだいて)元にした文書への将来の非互換な変化を避けるので、別々のドキュメントに動かされます。
Acknowledgements
承認
Thou shalt make no law restricting the size of integers that may
be multiplied together, nor the number of times that an integer
may be multiplied by itself, nor the modulus by which an integer
may be reduced. [Prime Commandment]
なんじは一緒に掛けられるかもしれない整数のサイズ、およびそれ自体、および整数は減少させられるかもしれない係数が整数に掛けられるかもしれないという回の数を制限する法を全く作ってはいけません。 [主要な命令]
Phil Karn was principally responsible for the design of the protocol phases, particularly the "cookie" anti-clogging defense, developed the initial testing implementation, and provided much of the design rationale text (now removed to a separate document).
フィルKarnは主にプロトコルフェーズのデザイン、特に「クッキー」反目詰まりディフェンスに責任があって、初期のテスト実現を開発して、デザイン原理テキストの多くを提供しました(現在、別々のドキュメントに取り外します)。
William Simpson was responsible for the packet formats and attributes, additional message types, editing and formatting. All such mistakes are his responsibility.
ウィリアム・シンプソンはパケット・フォーマット、属性、追加メッセージタイプ、編集、および形式に責任がありました。 そのようなすべての誤りが彼の責任です。
This protocol was later discovered to have many elements in common with the Station-To-Station authentication protocol [DOW92].
後でステーション・トゥー・ステーション認証プロトコル[DOW92]と共用してこのプロトコルには多くの要素があると発見されました。
Angelos Keromytis developed the first completely independent implementation (circa October 1995). Also, he suggested the cookie exchange rate limitation counter.
Angelos Keromytisは最初の完全に独立している実現(1995年10月頃の)を開発しました。 また、彼はクッキー為替レート制限カウンタを勧めました。
Paul C van Oorschot suggested signing both the public exponents and the shared-secret, to provide an authentication-only version of identity verification. Also, he provided text regarding moduli, generator, and exponent selection (now removed to a separate document).
ポールCバンOorschotは、アイデンティティ検証の認証だけバージョンを提供するために公共の解説者と共有秘密キーの両方にサインするのを示しました。 また、彼は係数、ジェネレータ、および解説者選択(現在、別々のドキュメントに取り外す)に関するテキストを提供しました。
Hilarie Orman suggested adding secret "nonces" to session-key generation for asymmetric public/private-key identity methods (now removed to a separate document), and provided extensive review of the protocol details.
Hilarie Ormanは非対称の公衆/秘密鍵アイデンティティ方法(現在、別々のドキュメントに取り外す)のためのセッションキー生成に秘密の「一回だけ」を追加するのを示して、プロトコルの詳細の大量のレビューを前提としました。
Bart Preneel and Paul C van Oorschot in [PO96] recommended padding between the data and trailing key when hashing for authentication.
認証のために論じ尽くすとき、[PO96]のバードPreneelとポールCバンOorschotは、データと引きずっているキーの間でそっと歩くことを勧めました。
Niels Provos developed another independent implementation (circa May 1997), ported to AIX, Linux, OpenBSD, and Solaris. Also, he made
ニールズProvosはAIX、リナックス、OpenBSD、およびSolarisに移植された別の独立している実現(1997年5月頃の)を開発しました。 また、彼は作りました。
Karn & Simpson Experimental [Page 72] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[72ページ]RFC2522Photurisは1999年3月に議定書を作ります。
suggestions regarding automated update, and listing multiple moduli per scheme.
自動化されたアップデートに関する提案と、計画単位で複数の係数を記載すること。
Bill Sommerfeld suggested including the authentication symmetric secret-keys in the session-key generation, and using the Cookie values on successive exchanges to provide bi-directional user- oriented keying (now removed to a separate document).
ビル・ゾンマーフェルトは、セッションキー生成で認証の左右対称の秘密鍵を含んでいることを提案しました、そして、双方向のユーザを提供するのに連続した交換のCookie値を使用すると、合わせること(現在、別々のドキュメントに取り外す)は適応しました。
Oliver Spatscheck developed the second independent implementation (circa December 1995) for the Xkernel.
オリバーSpatscheckはXkernelのために、2番目の独立している実現(1995年12月頃の)を開発しました。
International interoperability testing between early implementors provided the impetus for many of the implementation notes herein, and numerous refinements in the semantics of the protocol messages.
初期の作成者の間のテストがここに実現注意の多くの起動力を提供した国際相互運用性、およびプロトコルメッセージの意味論における頻繁な気品。
Randall Atkinson, Steven Bellovin, Wataru Hamada, James Hughes, Brian LaMacchia, Cheryl Madson, Lewis McCarthy, Perry Metzger, Bob Quinn, Ron Rivest, Rich Schroeppel, and Norman Shulman provided useful critiques of earlier versions of this document.
ランドル・アトキンソン、スティーブンBellovin、Wataru浜田、ジェームス・ヒューズ、ブライアンLaMacchia、シェリル・マドソン、ルイス・マッカーシー、ペリーメッツガー、ボブ・クイン、ロンRivest、リッシュSchroeppel、およびノーマン・シュルマンはこのドキュメントの以前のバージョンの役に立つ批評を提供しました。
Special thanks to the Center for Information Technology Integration (CITI) for providing computing resources.
情報Technology Integration(シティ)のためのセンターおかげでは、コンピューティング資源を提供するのにおいて、特別です。
References
参照
[BGMW93] E. Brickell, D. Gordon, K. McCurley, and D. Wilson, "Fast
Exponentiation with Precomputation (Extended Abstract)",
Advances in Cryptology -- Eurocrypt '92, Lecture Notes in
Computer Science 658 (1993), Springer-Verlag, 200-207.
D.ゴードン、K.McCurley、およびD.ウィルソン、「Precomputation(拡張要約)がある速い羃法」という[BGMW93]E.Brickellは暗号理論で進みます--Eurocrypt92年、コンピュータサイエンス658(1993)、追出石-Verlag(200-207)での講演注意。
Also U.S. Patent #5,299,262, E.F. Brickell, D.M. Gordon,
K.S. McCurley, "Method for exponentiating in
cryptographic systems", 29 Mar 1994.
米国Patent#529万9262も、E.F.Brickell、D.M.ゴードン、K.S.McCurley、「暗号のシステムにおけるべき乗のための方法」、1994年3月29日。
[DH76] Diffie, W., and Hellman, H.E., "New Directions in
Cryptography", IEEE Transactions on Information Theory, v
IT-22 n 6 pp 644-654, November 1976.
[DH76] ディフィー、W.とヘルマン、H.E.、「暗号に関する新傾向」、情報Theoryの上のIEEE Transactions対IT-22n6pp644-654(1976年11月)
[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 Wiener、「認証と認証されたキー交換」、Designs CodesとCryptography、v2pp107-125、Kluwer Academic Publishers、1992
[Firefly] "Photuris" is the latin name for the firefly. "Firefly"
is in turn the name for the USA National Security
Administration's (classified) key exchange protocol for
the STU-III secure telephone. Informed speculation has
[ファイヤーフライ]「Photuris」はホタルのためのラテン名です。 「ファイヤーフライ」は順番に、米国国家安全保障政権のための名前がSTU-III盗聴防止機能付き電話のための(分類される)の主要な交換プロトコルであるということです。 知識がある思索はそうしました。
Karn & Simpson Experimental [Page 73] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[73ページ]RFC2522Photurisは1999年3月に議定書を作ります。
it that Firefly is based on very similar design
principles.
ファイヤーフライをあるそれが非常に同様の設計原理を基礎づけました。
[LL94] Lim, C.H., Lee, P.J., "More flexible exponentiation with
precomputation", Advances in Cryptology -- Crypto '94,
Lecture Notes in Computer Science 839 (1994), Springer-
Verlag, pages 95-107.
[LL94]リム、C.H.、リー、P.J.、「前計算がある、よりフレキシブルな羃法」、CryptologyのAdvances--暗号94年、コンピュータScience839(1994)、Springer- Verlag(95-107ページ)のLecture Notes。
[Prime Commandment]
A derivation of an apocryphal quote from the usenet list
sci.crypt.
[主要なCommandment] usenetリストsci.cryptからのにせの引用文の派生。
[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] ふしだらな娘Preneel、およびポールCはOorshotをバンに積みます、「2つのMACアルゴリズムのセキュリティ」で、CryptologyのAdvances--Eurocrypt96年、コンピュータScience1070(1996年5月)、Springer-Verlag(19-32ページ)のLecture Notes。
[RFC-768] Postel, J., "User Datagram Protocol", STD 6,
USC/Information Sciences Institute, August 1980.
[RFC-768] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、科学が1980年8月に設けるUSC/情報。
[RFC-791] Postel, J., "Internet Protocol", STD 5, USC/Information
Sciences Institute, September 1981.
[RFC-791] ポステル、J.、「インターネットプロトコル」、STD5、科学が1981年9月に設けるUSC/情報。
[RFC-1321] Rivest, R., "The MD5 Message-Digest Algorithm", MIT
Laboratory for Computer Science, April 1992.
[RFC-1321] 1992年4月のRivest、R.、「MD5メッセージダイジェストアルゴリズム」MITコンピュータサイエンス研究所。
[RFC-1700] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2,
USC/Information Sciences Institute, October 1994.
[RFC-1700] USC/情報科学が1994年10月に設けるレイノルズ、J.、およびポステル、J.、「規定番号」、STD2。
[RFC-1812] Baker, F., Editor, "Requirements for IP Version 4
Routers", Cisco Systems, June 1995.
[RFC-1812] ベイカー、F.、エディタ、「IPバージョン4ルータのための要件」、シスコシステムズ、1995年6月。
[RFC-1828] Metzger, P., Simpson, W., "IP Authentication using Keyed
MD5", July 1995.
[RFC-1828] w.メッツガー、P.、シンプソン、「IP認証使用はMD5"、1995年7月を合わせました」。
[RFC-1829] Karn, P., Metzger, P., Simpson, W., "The ESP DES-CBC
Transform", July 1995.
[RFC-1829]Karn、P.、メッツガー、P.、シンプソン、w.、「超能力DES-CBCは変形する」1995年7月。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, Harvard University, March
1997.
[RFC-2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、ハーバード大学、1997年3月。
[RFC-2521] Karn, P., and Simpson, W., "ICMP Security Failures
Messages", March 1999.
[RFC-2521] Karn、P.とシンプソン、W.、「ICMPセキュリティ失敗メッセージ」、1999年3月。
[Rooij94] P. de Rooij, "Efficient exponentiation using
precomputation and vector addition chains", Advances in
Cryptology -- Eurocrypt '94, Lecture Notes in Computer
[Rooij94]P.de Rooij、「前計算とベクトル加法チェーンを使用する効率的な羃法」、CryptologyのAdvances--Eurocrypt94年、コンピュータのLecture Notes
Karn & Simpson Experimental [Page 74] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[74ページ]RFC2522Photurisは1999年3月に議定書を作ります。
Science, Springer-Verlag, pages 403-415.
科学、Springer-Verlag、403-415ページ。
[Schneier95]
Schneier, B., "Applied Cryptography Second Edition", John
Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7.
[Schneier95]シュナイアー、B.、「適用された暗号第2版」、ジョン・ワイリー、および息子、ニューヨーク(ニューヨーク)1995。 ISBN0-471-12845-7。
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
フィルKarnクアルコムInc.6455ラスク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(都合のよい)です。
Karn & Simpson Experimental [Page 75] RFC 2522 Photuris Protocol March 1999
Karnとシンプソン実験的な[75ページ]RFC2522Photurisは1999年3月に議定書を作ります。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1999). Copyright (C) Philip Karn and William Allen Simpson (1994-1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 Copyright(C)フィリップKarnとウィリアム・アレン・シンプソン(1994-1999)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は、それを英語以外の言語に翻訳するようにインターネット協会の版権情報か参照かインターネット標準を開発する目的に必要である以外の他のインターネット組織(その場合、インターネットStandardsの過程で定義された著作権のための手順に従わなければならない)を取り除くことなどのどんな方法、または必要に応じても変更されないかもしれません。
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.
このドキュメントとここに含まれた情報はそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄するかどうかということです、急行であるか、または含意されて、情報の使用がここに侵害しないどんな保証も含むのは(他)、市場性か特定目的への適合性のどんな権利かあらゆる黙示的な保証です。
Karn & Simpson Experimental [Page 76]
KarnとシンプソンExperimentalです。[76ページ]
一覧
スポンサーリンク
