Network Working Group H. Tschofenig
Request for Comments: 4230 Siemens
Category: Informational R. Graveman
RFG Security
December 2005
RSVP Security Properties
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document summarizes the security properties of RSVP. The goal of this analysis is to benefit from previous work done on RSVP and to capture knowledge about past activities.
このドキュメントは、RSVPのセキュリティプロパティをまとめたもの。この分析の目的は、RSVPで行わ前作から利益を得ると、過去の活動についての知識を取得することです。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Architectural Assumptions . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. The RSVP INTEGRITY Object . . . . . . . . . . . . . . 5
3.2. Security Associations . . . . . . . . . . . . . . . . 8
3.3. RSVP Key Management Assumptions . . . . . . . . . . . 8
3.4. Identity Representation . . . . . . . . . . . . . . . 9
3.5. RSVP Integrity Handshake . . . . . . . . . . . . . . 13
4. Detailed Security Property Discussion . . . . . . . . . . . 15
4.1. Network Topology . . . . . . . . . . . . . . . . . . 15
4.2. Host/Router . . . . . . . . . . . . . . . . . . . . . 15
4.3. User to PEP/PDP . . . . . . . . . . . . . . . . . . . 19
4.4. Communication between RSVP-Aware Routers . . . . . . . 28
5. Miscellaneous Issues . . . . . . . . . . . . . . . . . . . . 29
5.1. First-Hop Issue . . . . . . . . . . . . . . . . . . . 30
5.2. Next-Hop Problem . . . . . . . . . . . . . . . . . . . 30
5.3. Last-Hop Issue . . . . . . . . . . . . . . . . . . . 33
5.4. RSVP- and IPsec-protected data traffic . . . . . . . . 34
5.5. End-to-End Security Issues and RSVP . . . . . . . . . 36
5.6. IPsec protection of RSVP signaling messages . . . . . 36
5.7. Authorization . . . . . . . . . . . . . . . . . . . . 37
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 38
7. Security Considerations . . . . . . . . . . . . . . . . . . 40
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
9.1. Normative References . . . . . . . . . . . . . . . . . 40
9.2. Informative References . . . . . . . . . . . . . . . . 41
A. Dictionary Attacks and Kerberos . . . . . . . . . . . . . . 45
B. Example of User-to-PDP Authentication . . . . . . . . . . . 45
C. Literature on RSVP Security . . . . . . . . . . . . . . . . 46
As the work of the NSIS working group began, concerns about security and its implications for the design of a signaling protocol were raised. In order to understand the security properties and available options of RSVP, a number of documents have to be read. This document summarizes the security properties of RSVP and is part of the overall process of analyzing other signaling protocols and learning from their design considerations. This document should also provide a starting point for further discussions.
NSISワーキンググループの作業が始まったとして、セキュリティおよびシグナリングプロトコルの設計のためにその影響について懸念が提起されました。セキュリティプロパティとRSVPの利用可能なオプションを理解するために、文書の数を読み取ることがあります。このドキュメントは、RSVPのセキュリティプロパティを要約し、他のシグナリングプロトコルを分析し、その設計上の配慮から、学習の全体的なプロセスの一部です。この文書はまた、さらなる議論の出発点を提供する必要があります。
The content of this document is organized as follows. Section 2 introduces the terminology used throughout the document. Section 3 provides an overview of the security mechanisms provided by RSVP including the INTEGRITY object, a description of the identity representation within the POLICY_DATA object (i.e., user authentication), and the RSVP Integrity Handshake mechanism. Section 4 provides a more detailed discussion of the mechanisms used and tries to describe in detail the mechanisms provided. Several miscellaneous issues are covered in Section 5.
次のように、この文書の内容は組織化されています。第2節では、文書全体で使用される用語を紹介します。セクション3はINTEGRITYオブジェクト、POLICY_DATAオブジェクト（すなわち、ユーザ認証）、およびRSVP完全性ハンドシェーク機構内アイデンティティ表現の記述を含むRSVPによって提供されるセキュリティメカニズムの概要を提供します。セクション4は、使用されるメカニズムのより詳細な議論を提供し、詳細に提供されるメカニズムを説明しよう。いくつかのその他の問題は、第5節で覆われています。
RSVP also supports multicast, but this document does not address security aspects for supporting multicast QoS signaling. Multicast is currently outside the scope of the NSIS working group.
RSVPは、マルチキャストをサポートしていますが、この文書では、マルチキャストのQoSシグナリングをサポートするためのセキュリティの側面に対応していません。マルチキャストはNSISワーキンググループの範囲外で、現在あります。
Although a variation of RSVP, namely RSVP-TE, is used in the context of MPLS to distribute labels for a label switched path, its usage is different from the usage scenarios envisioned for NSIS. Hence, this document does not address RSVP-TE or its security properties.
RSVPの変化、すなわち、RSVP-TEは、ラベルのラベルを配布するMPLSの文脈で使用されるパスを切り替えているが、その使用はNSISのために想定される使用シナリオとは異なります。したがって、このドキュメントはRSVP-TEまたはそのセキュリティプロパティに対応していません。
This section describes some important terms and explains some architectural assumptions.
このセクションでは、いくつかの重要な用語について説明し、いくつかの建築の仮定を説明しています。
o Chain-of-Trust:
チェーン・オブ・トラストO：
The security mechanisms supported by RSVP [1] heavily rely on optional hop-by-hop protection, using the built-in INTEGRITY object. Hop-by-hop security with the INTEGRITY object inside the RSVP message thereby refers to the protection between RSVP-supporting network elements. Additionally, there is the notion of policy-aware nodes that understand the POLICY_DATA element within the RSVP message. Because this element also includes an INTEGRITY object, there is an additional hop-by-hop security mechanism that provides security between policy-aware nodes. Policy-ignorant nodes are not affected by the inclusion of this object in the POLICY_DATA element, because they do not try to interpret it.
RSVPによってサポートされるセキュリティメカニズム[1]重く内蔵のINTEGRITYオブジェクトを使用して、オプションのホップバイホップの保護に頼っています。 RSVPメッセージ内のINTEGRITYオブジェクトとホップバイホップセキュリティこれによりRSVP-サポートするネットワーク要素との間の保護を意味します。また、RSVPメッセージ内POLICY_DATA要素を理解してポリシーを意識したノードの概念があります。この要素はまたINTEGRITYオブジェクトを含むため、ポリシー対応ノード間のセキュリティを提供する付加的なホップバイホップセキュリティメカニズムが存在します。彼らはそれを解釈しようとしないため、ポリシー無知なノードは、POLICY_DATA要素で、このオブジェクトを含めることによって影響を受けません。
To protect signaling messages that are possibly modified by each RSVP router along the path, it must be assumed that each incoming request is authenticated, integrity protected, and replay protected. This provides protection against bogus messages injected by unauthorized nodes. Furthermore, each RSVP-aware router is assumed to behave in the expected manner. Outgoing messages transmitted to the next-hop network element receive new protection according to RSVP security processing.
おそらくパスに沿った各RSVPルータによって修正されるシグナリングメッセージを保護するために、完全性が保護され、各着信要求が認証されると仮定しなければならず、再生が保護します。これは、不正なノードによって注入された偽のメッセージに対する保護を提供します。さらに、各RSVP対応ルータは、予想されるように動作することが想定されます。ネクストホップネットワーク要素に送信し、送信メッセージは、RSVPのセキュリティ処理に応じて、新たな保護を受けます。
Using the mechanisms described above, a chain-of-trust is created whereby a signaling message that is transmitted by router A via router B and received by router C is supposed to be secure if routers A and B and routers B and C share security associations and all routers behave as expected. Hence, router C trusts router A although router C does not have a direct security association with router A. We can therefore conclude that the protection achieved with this hop-by-hop security for the chain-of-trust is no better than the weakest link in the chain.
ルータAとBとルータBとC共有セキュリティアソシエーション場合ルータBを介してルータAによって送信され、ルータCによって受信されるシグナリングメッセージが安全であると想定されるチェーンの信頼が作成され、上述したメカニズムを使用して予想通り、すべてのルータが動作します。ルータCがルータAとの直接のセキュリティアソシエーションを持っていないが故に、ルータC信託ルータA従って、我々は、チェーン・オブ・信頼のために、このホップバイホップセキュリティで達成保護が最も弱いよりも良いではないと結論することができますチェーン内のリンク。
If one router is malicious (for example, because an adversary has control over this router), then it can arbitrarily modify messages, cause unexpected behavior, and mount a number of attacks that are not limited to QoS signaling. Additionally, it must be mentioned that some protocols demand more protection than others (which depends, in part, on which nodes are executing these protocols). For example, edge devices, where end-users are attached, may be more likely to be attacked in comparison with the more secure core network of a service provider. In some cases, a network service provider may choose not to use the RSVP-provided security mechanisms inside the core network because a different security protection is deployed.
（敵対者がこのルータを制御しているので、例えば）1つのルータが悪質な場合には、それは任意に、メッセージを変更する予期しない動作を引き起こす、およびQoSシグナリングに限定されるものではなく、攻撃の数をマウントすることができます。 （ノードは、これらのプロトコルを実行されている、部分的に依存する）さらに、いくつかのプロトコルが他よりも多くの保護を求めていることを言及しなければなりません。例えば、エンドユーザが接続されているエッジデバイスは、サービスプロバイダのより安全なコアネットワークと比較して攻撃されやすいかもしれません。いくつかのケースでは、ネットワークサービスプロバイダは、さまざまなセキュリティ保護が展開されているため、コアネットワーク内にRSVP-提供するセキュリティ・メカニズムを使用しないことも選択できます。
Section 6 of [2] mentions the term chain-of-trust in the context of RSVP integrity protection. In Section 6 of [14] the same term is used in the context of user authentication with the INTEGRITY object inside the POLICY_DATA element. Unfortunately, the term is not explained in detail and the assumptions behind it are not clearly specified.
[2]のセクション6は、用語チェーン・オブ・信頼RSVPの完全性保護の文脈で言及しています。 [14]のセクション6で同じ用語はPOLICY_DATA要素内INTEGRITYオブジェクトとユーザ認証の文脈で使用されます。残念ながら、この用語は詳細に説明されていないと、その背後にある仮定は明確に指定されていません。
o Host and User Authentication:
Oホストとユーザー認証：
The presence of RSVP protection and a separate user identity representation leads to the fact that both user-identity and host-identity are used for RSVP protection. Therefore, user-based security and host-based security are covered separately, because of the different authentication mechanisms provided. To avoid confusion about the different concepts, Section 3.4 describes the concept of user authentication in more detail.
RSVP保護と、別のユーザーID表現の存在は、ユーザーのアイデンティティとホスト・アイデンティティの両方がRSVPの保護のために使用されているという事実につながります。したがって、ユーザベースのセキュリティとホストベースのセキュリティが提供されるため、異なる認証メカニズム、別々に覆われています。異なる概念について混乱を避けるために、3.4節では、より詳細にユーザ認証の概念を説明します。
o Key Management:
キー管理○：
It is assumed that most of the security associations required for the protection of RSVP signaling messages are already available, and hence key management was done in advance. There is, however, an exception with respect to support for Kerberos. Using Kerberos, an entity is able to distribute a session key used for RSVP signaling protection.
RSVPシグナリングメッセージの保護のために必要なセキュリティアソシエーションのほとんどはすでに利用可能であると想定されるため、鍵の管理は、事前に行われました。ケルベロスのサポートに関しては例外は、しかし、があります。 Kerberosを使用して、エンティティは、RSVPシグナリングの保護のために使用されるセッション鍵を配布することができます。
o RSVP INTEGRITY and POLICY_DATA INTEGRITY Objects:
O RSVPの整合性とPOLICY_DATA INTEGRITYオブジェクト：
RSVP uses an INTEGRITY object in two places in a message. The first is in the RSVP message itself and covers the entire RSVP message as defined in [1]. The second is included in the POLICY_DATA object and defined in [2]. To differentiate the two objects by their scope of protection, the two terms RSVP INTEGRITY and POLICY_DATA INTEGRITY object are used, respectively. The data structure of the two objects, however, is the same.
RSVPは、メッセージ中の2つの場所でINTEGRITYオブジェクトを使用しています。最初は、RSVPメッセージ自体であり、[1]で定義されるように全体のRSVPメッセージをカバーします。第二は、POLICY_DATAオブジェクトに含ま及び[2]で定義されています。保護の彼らの範囲によって2つのオブジェクトを区別するために、2つの用語はINTEGRITYとPOLICY_DATA INTEGRITYオブジェクトをRSVPそれぞれ、使用されています。二つのオブジェクトのデータ構造は、しかしながら、同じです。
o Hop versus Peer:
Oピア対ホップ：
In the past, the terminology for nodes addressed by RSVP has been discussed considerably. In particular, two favorite terms have been used: hop and peer. This document uses the term hop, which is different from an IP hop. Two neighboring RSVP nodes communicating with each other are not necessarily neighboring IP nodes (i.e., they may be more than one IP hop away).
過去には、RSVPによって対処ノードのための専門用語はかなり議論されてきました。特に、2つの好きな用語が使用されている：ホップとピアを。この文書では、IPホップと異なる用語のホップを使用しています。互いに連通する二つの隣接RSVPノードは、必ずしも（即ち、それらは離れホップ複数のIPであってもよい）IPノードに隣接されていません。
This section describes the security mechanisms provided by RSVP. Although use of IPsec is mentioned in Section 10 of [1], the other security mechanisms primarily envisioned for RSVP are described.
このセクションでは、RSVPによって提供されるセキュリティメカニズムについて説明します。 IPsecの使用は、[1]のセクション10に記載されているが、主にRSVPのために想定される他のセキュリティ機構が記載されています。
The RSVP INTEGRITY object is the major component of RSVP security protection. This object is used to provide integrity and replay protection for the content of the signaling message between two RSVP participating routers or between an RSVP router and host. Furthermore, the RSVP INTEGRITY object provides data origin authentication. The attributes of the object are briefly described:
RSVPのINTEGRITYオブジェクトは、RSVPのセキュリティ保護の主要な構成要素です。このオブジェクトは2つのRSVP参加ルータ間またはRSVPルータとホスト間のシグナリングメッセージのコンテンツの完全性および再生保護を提供するために使用されます。また、RSVPのINTEGRITYオブジェクトは、データ発信元認証を提供します。オブジェクトの属性を簡単に説明します。
o Flags field:
Oフラグフィールド：
The Handshake Flag is the only defined flag. It is used to
synchronize sequence numbers if the communication gets out of
sync (e.g., it allows a restarting host to recover the most recent sequence number). Setting this flag to one indicates that
the sender is willing to respond to an Integrity Challenge
message. This flag can therefore be seen as a negotiation
capability transmitted within each INTEGRITY object.
o Key Identifier:
Oキー識別子：
The Key Identifier selects the key used for verification of the
Keyed Message Digest field and, hence, must be unique for the
sender. It has a fixed 48-bit length. The generation of this
Key Identifier field is mostly a decision of the local host. [1]
describes this field as a combination of an address, sending
interface, and key number. We assume that the Key Identifier is
simply a (keyed) hash value computed over a number of fields,
with the requirement to be unique if more than one security
association is used in parallel between two hosts (e.g., as is
the case with security associations having overlapping
lifetimes). A receiving system uniquely identifies a security
association based on the Key Identifier and the sender's IP
address. The sender's IP address may be obtained from the
RSVP_HOP object or from the source IP address of the packet if
the RSVP_HOP object is not present. The sender uses the outgoing
interface to determine which security association to use. The
term "outgoing interface" may be confusing. The sender selects
the security association based on the receiver's IP address
(i.e., the address of the next RSVP-capable router). The process
of determining which node is the next RSVP-capable router is not
further specified and is likely to be statically configured.
o Sequence Number:
Oシーケンス番号：
The sequence number used by the INTEGRITY object is 64 bits in
length, and the starting value can be selected arbitrarily. The
length of the sequence number field was chosen to avoid
exhaustion during the lifetime of a security association as
stated in Section 3 of [1]. In order for the receiver to
distinguish between a new and a replayed message, the sequence
number must be monotonically incremented (modulo 2^64) for each
message. We assume that the first sequence number seen (i.e.,
the starting sequence number) is stored somewhere. The modulo-
operation is required because the starting sequence number may be
an arbitrary number. The receiver therefore only accepts packets
with a sequence number larger (modulo 2^64) than the previous
packet. As explained in [1] this process is started by
handshaking and agreeing on an initial sequence number. If no
such handshaking is available then the initial sequence number
must be part of the establishment of the security association.
The generation and storage of sequence numbers is an important step in preventing replay attacks and is largely determined by the capabilities of the system in the presence of system crashes, failures, and restarts. Section 3 of [1] explains some of the most important considerations. However, the description of how the receiver distinguishes proper from improper sequence numbers is incomplete: it implicitly assumes that gaps large enough to cause the sequence number to wrap around cannot occur.
シーケンス番号の生成と貯蔵は、リプレイ攻撃を防止するのに重要なステップであり、主にシステムがクラッシュした、障害、および再起動の存在下でのシステムの能力によって決定されます。 [1]の第3節では、最も重要な検討事項のいくつかを説明します。しかし、受信機が不適切なシーケンス番号から適切な区別方法の説明が不完全である：それは暗黙的にラップアラウンドするシーケンス番号を起こすのに十分な大きさのギャップが生じないことを前提としています。
If delivery in order were guaranteed, the following procedure would work: the receiver keeps track of the first sequence number received, INIT-SEQ, and the most recent sequence number received, LAST-SEQ, for each key identifier in a security association. When the first message is received, set INIT-SEQ = LAST-SEQ = value received and accept. When a subsequent message is received, if its sequence number is strictly between LAST-SEQ and INIT-SEQ, (modulo 2^64), accept and update LAST-SEQ with the value just received. If it is between INIT-SEQ and LAST-SEQ, inclusive, (modulo 2^64), reject and leave the value of LAST-SEQ unchanged. Because delivery in order is not guaranteed, the above rules need to be combined with a method of allowing a fixed sized window in the neighborhood of LAST-SEQ for out-of-order delivery, for example, as described in Appendix C of [3].
受信機は、最初のシーケンス番号のトラック受け、INIT-SEQを保持し、最新のシーケンス番号は、セキュリティアソシエーションの各キー識別子のために、LAST-SEQを受けた：順序で配信が保証された場合は、以下の手順が動作します。最初のメッセージを受信したとき、INIT-SEQ = LAST-SEQ =値が受信され受け入れセット。後続のメッセージが受信されると、そのシーケンス番号は厳密LAST-SEQとINIT-配列、（モジュロ2 ^ 64）の間にある場合、受信したばかりの値とLAST-配列を受け入れ、更新。それが（モジュロ2 ^ 64）、包括的、INIT-SEQとLAST-配列の間にある場合、拒否し不変LAST-SEQの値を残します。順番に配信が保証されないので、上記の規則は、[3付録Cに記載されているように、例えば、アウトオブオーダ送達のためLAST-配列の近傍に固定されたサイズのウィンドウを可能にする方法と組み合わせることが必要]。
o Keyed Message Digest:
キー付きメッセージダイジェストO：
The Keyed Message Digest is a security mechanism built into RSVP
that used to provide integrity protection of a signaling message
(including its sequence number). Prior to computing the value
for the Keyed Message Digest field, the Keyed Message Digest
field itself must be set to zero and a keyed hash computed over
the entire RSVP packet. The Keyed Message Digest field is
variable in length but must be a multiple of four octets. If
HMAC-MD5 is used, then the output value is 16 bytes long. The
keyed hash function HMAC-MD5 [4] is required for an RSVP
implementation, as noted in Section 1 of [1]. Hash algorithms
other than MD5 [5], like SHA-1 [15], may also be supported.
The key used for computing this Keyed Message Digest may be obtained from the pre-shared secret, which is either manually distributed or the result of a key management protocol. No key management protocol, however, is specified to create the desired security associations. Also, no guidelines for key length are given. It should be recommended that HMAC-MD5 keys be 128 bits and SHA-1 keys 160 bits, as in IPsec AH [16] and ESP [17].
このキー付きメッセージダイジェストを計算するために使用されるキーは、手動で分散されるか、事前共有秘密、または鍵管理プロトコルの結果から得ることができます。いいえ鍵管理プロトコルは、しかし、必要なセキュリティ関連付けを作成するために指定されていません。また、キーの長さのためのガイドラインが示されていません。 IPsec AH [16]およびESP [17]のように、HMAC-MD5キーは128ビット、SHA-1鍵160ビットであることが推奨されるべきです。
Different attributes are stored for security associations of sending and receiving systems (i.e., unidirectional security associations). The sending system needs to maintain the following attributes in such a security association [1]:
異なる属性は、システム（すなわち、一方向セキュリティアソシエーション）を送信および受信のセキュリティアソシエーションのために記憶されます。送信システムは、セキュリティアソシエーション[1]に以下の属性を維持する必要があります。
o Authentication algorithm and algorithm mode
O認証アルゴリズムとアルゴリズムモード
o Key
Oキー
o Key Lifetime
Oキーの有効期間
o Sending Interface
送信インターフェイスO
o Latest sequence number (received with this key identifier)
（このキーの識別子と受信）O最新のシーケンス番号
The receiving system has to store the following fields:
受信システムは、次のフィールドを保存するためにあります。
o Authentication algorithm and algorithm mode
O認証アルゴリズムとアルゴリズムモード
o Key
Oキー
o Key Lifetime
Oキーの有効期間
o Source address of the sending system
送信側システムのOソースアドレス
o List of last n sequence numbers (received with this key identifier)
（このキーの識別子と受信した）最後のn個のシーケンス番号のO一覧
Note that the security associations need to have additional fields to indicate their state. It is necessary to have overlapping lifetimes of security associations to avoid interrupting an ongoing communication because of expired security associations. During such a period of overlapping lifetime it is necessary to authenticate with either one or both active keys. As mentioned in [1], a sender and a receiver may have multiple active keys simultaneously. If more than one algorithm is supported, then the algorithm used must be specified for a security association.
セキュリティアソシエーションは、自分の状態を示すために追加のフィールドを持っている必要があることに注意してください。これは、有効期限が切れているため、セキュリティアソシエーションの進行中の通信を中断を避けるためにセキュリティアソシエーションのライフタイムをオーバーラップしていることが必要です。寿命を重複ような期間には、一方または両方の活性のキーのいずれかを使用して認証する必要があります。 [1]で述べたように、送信側と受信側は、同時に複数のアクティブなキーを有していてもよいです。複数のアルゴリズムがサポートされている場合、使用されるアルゴリズムは、セキュリティアソシエーションを指定する必要があります。
RFC 2205 [6] assumes that security associations are already available. An implementation must support manual key distribution as noted in Section 5.2 of [1]. Manual key distribution, however, has different requirements for key storage; a simple plaintext ASCII file may be sufficient in some cases. If multiple security associations with different lifetimes need to be supported at the same time, then a key engine would be more appropriate. Further security requirements listed in Section 5.2 of [1] are the following:
RFC 2205 [6]セキュリティアソシエーションがすでに利用可能であることを前提としています。 [1]のセクション5.2で述べたように、実装は、手動鍵配布をサポートしなければなりません。手動鍵配布は、しかし、鍵保管のためのさまざまな要件があります。シンプルなプレーンテキストASCIIファイルには、いくつかのケースで十分かもしれません。異なる寿命を持つ複数のセキュリティアソシエーションを同時にサポートする必要がある場合には、キーエンジンは、より適切であろう。 5.2節に記載されているさらなるセキュリティ要件[1]次のとおりです。
o The manual deletion of security associations must be supported.
Oセキュリティアソシエーションの手動削除がサポートされている必要があります。
o The key storage should persist during a system restart.
Oキーストレージは、システムの再起動時に持続すべきです。
o Each key must be assigned a specific lifetime and a specific Key Identifier.
O各キーは、特定の寿命と特定のキー識別子を割り当てる必要があります。
In addition to host-based authentication with the INTEGRITY object inside the RSVP message, user-based authentication is available as introduced in [2]. Section 2 of [7] states that "Providing policy based admission control mechanism based on user identities or application is one of the prime requirements." To identify the user or the application, a policy element called AUTH_DATA, which is contained in the POLICY_DATA object, is created by the RSVP daemon at the user's host and transmitted inside the RSVP message. The structure of the POLICY_DATA element is described in [2]. Network nodes acting as policy decision points (PDPs) then use the information contained in the AUTH_DATA element to authenticate the user and to allow policy-based admission control to be executed. As mentioned in [7], the policy element is processed and the PDP replaces the old element with a new one for forwarding to the next hop router.
導入されるように加えてRSVPメッセージ内のINTEGRITYオブジェクトと認証をホストベース、ユーザベースの認証が利用可能である[2]。 [7]の第2節では、「ユーザーIDまたはアプリケーションに基づいて提供するポリシーベースのアドミッション制御メカニズムが素数要件の一つである。」と述べていますユーザまたはPOLICY_DATAオブジェクトに含まれるアプリケーション、AUTH_DATAというポリシーの要素を識別するために、ユーザのホストでRSVPデーモンによって作成され、RSVPメッセージ内で伝送されます。 POLICY_DATA素子の構造は、[2]に記載されています。ポリシー決定ポイント（PDPの）として働くネットワークノードは、ユーザを認証するために、ポリシーベースのアドミッション制御を実行できるようにAUTH_DATA要素に含まれる情報を使用します。で述べたように、[7]、ポリシー要素が処理され、PDPは、ネクストホップルータに転送するために新しいものと古い要素を置き換えています。
A detailed description of the POLICY_DATA element can be found in [2]. The attributes contained in the authentication data policy element AUTH_DATA, which is defined in [7], are briefly explained in this Section. Figure 1 shows the abstract structure of the RSVP message with its security-relevant objects and the scope of protection. The RSVP INTEGRITY object (outer object) covers the entire RSVP message, whereas the POLICY_DATA INTEGRITY object only covers objects within the POLICY_DATA element.
POLICY_DATA要素の詳細な説明は、[2]に見出すことができます。 [7]で定義されている認証データポリシーエレメントAUTH_DATAに含まれる属性は、簡単に、このセクションで説明されています。図1は、セキュリティ関連オブジェクトとRSVPメッセージ及び保護の範囲の抽象的構造を示しています。 POLICY_DATA INTEGRITYオブジェクトのみPOLICY_DATA要素内のオブジェクトを覆う一方、RSVPのINTEGRITYオブジェクト（外部オブジェクト）は、全体のRSVPメッセージをカバーします。
+--------------------------------------------------------+
| RSVP Message |
+--------------------------------------------------------+
| Object |POLICY_DATA Object ||
| +-------------------------------------------+|
| | INTEGRITY +------------------------------+||
| | Object | AUTH_DATA Object |||
| | +------------------------------+||
| | | Various Authentication |||
| | | Attributes |||
| | +------------------------------+||
| +-------------------------------------------+|
+--------------------------------------------------------+
Figure 1: Security Relevant Objects and Elements
within the RSVP Message.
The AUTH_DATA object contains information for identifying users and applications together with credentials for those identities. The main purpose of these identities seems to be usage for policy-based admission control and not authentication and key management. As noted in Section 6.1 of [7], an RSVP message may contain more than one POLICY_DATA object and each of them may contain more than one AUTH_DATA object. As indicated in Figure 1 and in [7], one AUTH_DATA object may contain more than one authentication attribute. A typical configuration for Kerberos-based user authentication includes at least the Policy Locator and an attribute containing the Kerberos session ticket.
AUTH_DATAオブジェクトは、それらのアイデンティティの資格情報と一緒に、ユーザーとアプリケーションを識別するための情報が含まれています。これらのIDの主な目的は、ポリシーベースのアドミッション制御ではなく、認証およびキー管理の使用方法のようです。セクション6.1で述べたように[7]、RSVPメッセージは、複数のPOLICY_DATAオブジェクトを含んでいてもよく、それらの各々は、複数のAUTH_DATAオブジェクトを含んでいてもよいです。図1及び[7]に示されているように、一個のAUTH_DATAオブジェクトが複数の認証属性を含んでいてもよいです。 Kerberosベースのユーザ認証のための代表的な構成は、少なくともポリシーロケータとKerberosセッションチケットを含む属性を含んでいます。
Successful user authentication is the basis for executing policy-based admission control. Additionally, other information such as time-of-day, application type, location information, group membership, etc. may be relevant to the implementation of an access control policy.
ユーザ認証の成功は、ポリシーベースのアドミッション制御を実行するための基礎です。また、そのような時間帯、アプリケーションタイプ、位置情報、グループメンバーシップ、等のような他の情報は、アクセス制御ポリシーの実装に関連し得ます。
The following attributes are defined for use in the AUTH_DATA object:
以下の属性は、AUTH_DATAオブジェクトで使用するために定義されています。
o Policy Locator
Oポリシーロケータ
* ASCII_DN
* ASCII_DN
* UNICODE_DN
* UNICODE_DN
* ASCII_DN_ENCRYPT
* ASCII_DN_ENCRYPT
* UNICODE_DN_ENCRYPT
* UNICODE_DN_ENCRYPT
The policy locator string is an X.500 distinguished name (DN) used to locate user or application-specific policy information. The four types of X.500 DNs are listed above. The first two types are the ASCII and the Unicode representation of the user or application DN identity. The two "encrypted" distinguished name types are either encrypted with the Kerberos session key or with the private key of the user's digital certificate (i.e., digitally signed). The term "encrypted together with a digital signature" is easy to misconceive. If user identity confidentiality is provided, then the policy locator has to be encrypted with the public key of the recipient. How to obtain this public key is not described in the document. This detail may be specified in a concrete architecture in which RSVP is used.
ポリシーロケータ文字列が識別名（DN）は、ユーザーまたはアプリケーション固有のポリシー情報を検索するために使用されるX.500です。 X.500 DNの4種類が、上に列挙されています。最初の2つのタイプは、ASCII、ユーザまたはアプリケーションDN同一のUnicode表現です。 2「暗号化された」識別名のタイプは、どちらかのKerberosセッションキーでか（すなわち、デジタル署名された）ユーザーのデジタル証明書の秘密鍵で暗号化されています。 「デジタル署名と一緒に暗号化された」という用語は、誤解しやすいです。ユーザ識別情報の機密性が提供されている場合、ポリシーロケータは、受信者の公開鍵で暗号化する必要があります。この公開鍵は、文書に記述されていない入手する方法。この詳細は、RSVPが使用される具体的なアーキテクチャで指定されてもよいです。
o Credentials
O資格情報
Two cryptographic credentials are currently defined for a user: authentication with Kerberos V5 [8], and authentication with the help of digital signatures based on X.509 [18] and PGP [19]. The following list contains all defined credential types currently available and defined in [7]:
二つの暗号資格情報は、現在のユーザのために定義されている：認証ケルベロスV5 [8]、および認証とX.509 [18]およびPGP [19]に基づいて、デジタル署名の助けを借りて。以下のリストは、現在利用可能と[7]で定義されたすべての定義されたクレデンシャルタイプが含まれています。
+--------------+--------------------------------+
| Credential | Description |
| Type | |
+===============================================|
| ASCII_ID | User or application identity |
| | encoded as an ASCII string |
+--------------+--------------------------------+
| UNICODE_ID | User or application identity |
| | encoded as a Unicode string |
+--------------+--------------------------------+
| KERBEROS_TKT | Kerberos V5 session ticket |
+--------------+--------------------------------+
| X509_V3_CERT | X.509 V3 certificate |
+--------------+--------------------------------+
| PGP_CERT | PGP certificate |
+--------------+--------------------------------+
Figure 2: Credentials Supported in RSVP.
図2：RSVPでサポートされている資格情報。
The first two credentials contain only a plaintext string, and therefore they do not provide cryptographic user authentication. These plaintext strings may be used to identify applications, that are included for policy-based admission control. Note that these plain-text identifiers may, however, be protected if either the RSVP INTEGRITY or the
最初の二つの資格情報はプレーンテキスト文字列を含むので、彼らは、暗号化、ユーザー認証を提供しません。これら平文文字列は、ポリシーベースのアドミッション制御のために含まれているアプリケーションを識別するために使用されてもよいです。 RSVPのINTEGRITYかのいずれか場合は、これらのプレーンテキスト識別子が、しかし、保護されていてもよいことに注意してください
INTEGRITY object of the POLICY_DATA element is present. Note that the two INTEGRITY objects can terminate at different entities depending on the network structure. The digital signature may also provide protection of application identifiers. A protected application identity (and the entire content of the POLICY_DATA element) cannot be modified as long as no policy-ignorant nodes are encountered in between.
POLICY_DATA要素のINTEGRITYオブジェクトが存在しています。 2つのINTEGRITYオブジェクトは、ネットワーク構成に応じて、異なるエンティティで終端することができることに留意されたいです。デジタル署名は、アプリケーション識別子の保護を提供することができます。保護されたアプリケーションID（及びPOLICY_DATA素子の全体の内容は）限りないポリシー無知ノードが間に遭遇されないように変更することができません。
A Kerberos session ticket, as previously mentioned, is the ticket of a Kerberos AP_REQ message [8] without the Authenticator. Normally, the AP_REQ message is used by a client to authenticate to a server. The INTEGRITY object (e.g., of the POLICY_DATA element) provides the functionality of the Kerberos Authenticator, namely protecting against replay and showing that the user was able to retrieve the session key following the Kerberos protocol. This is, however, only the case if the Kerberos session was used for the keyed message digest field of the INTEGRITY object. Section 7 of [1] discusses some issues for establishment of keys for the INTEGRITY object. The establishment of the security association for the RSVP INTEGRITY object with the inclusion of the Kerberos Ticket within the AUTH_DATA element may be complicated by the fact that the ticket can be decrypted by node B, whereas the RSVP INTEGRITY object terminates at a different host C.
ケルベロスセッションチケットは、前述したように、認証なしのケルベロスAP_REQメッセージ[8]のチケットです。通常、AP_REQメッセージがサーバーに認証するためにクライアントによって使用されます。 INTEGRITYオブジェクトは（例えば、POLICY_DATA素子）すなわちリプレイに対する保護とユーザがKerberosプロトコルに従ってセッションキーを取得することができたことを示し、ケルベロス認証の機能を提供します。ケルベロスセッションがINTEGRITYオブジェクトの鍵付きメッセージダイジェストフィールドに使用された場合、これは、しかし、唯一の場合です。 [1] INTEGRITYオブジェクトのキーの確立のためにいくつかの問題について説明するセクション7。 RSVPのINTEGRITYオブジェクトは異なるホスト℃で終端する一方、AUTH_DATA要素内のKerberosチケットを含めてRSVPのINTEGRITYオブジェクトのセキュリティ・アソシエーションの確立は、チケットがノードBによって復号化することができるという事実によって複雑にされてもよいです
The Kerberos session ticket contains, among many other fields, the session key. The Policy Locator may also be encrypted with the same session key. The protocol steps that need to be executed to obtain such a Kerberos service ticket are not described in [7] and may involve several roundtrips, depending on many Kerberos-related factors. As an optimization, the Kerberos ticket does not need to be included in every RSVP message, as described in Section 7.1 of [1]. Thus, the receiver must store the received service ticket. If the lifetime of the ticket has expired, then a new service ticket must be sent. If the receiver lost its state information (because of a crash or restart) then it may transmit an Integrity Challenge message to force the sender to re-transmit a new service ticket.
ケルベロスセッションチケットは、他の多くの分野、セッションキーの間で、含まれています。ポリシーロケータは、同じセッション鍵で暗号化することができます。そのようなKerberosのサービスチケットを取得するために実行する必要のあるプロトコルのステップが[7]に記載されておらず、多くのKerberos関連要因に応じて、いくつかのラウンドトリップを含むことができます。 [1]のセクション7.1で説明したように最適化として、Kerberosチケットは、すべてのRSVPメッセージに含まれている必要はありません。このように、受信機は、受信したサービスチケットを格納する必要があります。チケットの有効期間が満了している場合、新しいサービスチケットを送信する必要があります。受信機は、（理由はクラッシュまたは再起動の）その状態情報を失った場合、それは新しいサービスチケットを再送信するために送信者を強制的に整合性チャレンジメッセージを送信してもよいです。
If either the X.509 V3 or the PGP certificate is included in the policy element, then a digital signature must be added. The digital signature computed over the entire AUTH_DATA object provides authentication and integrity protection. The SubType of the digital signature authentication attribute is set to zero before computing the digital signature. Whether or not a guarantee of freshness with replay protection (either timestamps or sequence numbers) is provided by the digital signature is an open issue as discussed in Section 4.3.
509 V3またはPGP証明書のいずれかがポリシー要素に含まれている場合、デジタル署名が追加されなければなりません。全体AUTH_DATAオブジェクト上に計算されたデジタル署名は、認証と完全性保護を提供します。デジタル署名の認証属性のサブタイプは、デジタル署名を計算する前にゼロに設定されています。 4.3節で述べたように、デジタル署名によって提供されるリプレイ保護（いずれかのタイムスタンプやシーケンス番号）と新鮮さを保証するかどうかは、未解決の問題です。
o Digital Signature
Oデジタル署名
The digital signature computed over the contents of the AUTH_DATA object must be the last attribute. The algorithm used to compute the digital signature depends on the authentication mode listed in the credential. This is only partially true, because, for example, PGP again allows different algorithms to be used for computing a digital signature. The algorithm identifier used for computing the digital signature is not included in the certificate itself. The algorithm identifier included in the certificate only serves the purpose of allowing the verification of the signature computed by the certificate authority (except for the case of self-signed certificates).
AUTH_DATAオブジェクトの内容にわたって計算されたデジタル署名は、最後の属性でなければなりません。デジタル署名を計算するために使用されるアルゴリズムは、資格情報にリストされた認証モードに依存します。例えば、PGPは、再び異なるアルゴリズムは、デジタル署名を計算するために使用することができ、これは、部分的にのみ真です。デジタル署名を計算するために使用されるアルゴリズム識別子は証明書自体に含まれていません。証明書に含まれるアルゴリズム識別子は、（自己署名証明書の場合を除く）認証局によって計算署名の検証を可能にする目的を果たします。
o Policy Error Object
Oポリシー・エラー・オブジェクト
The Policy Error Object is used in the case of a failure of policy-based admission control or other credential verification. Currently available error messages allow notification if the credentials are expired (EXPIRED_CREDENTIALS), if the authorization process disallowed the resource request (INSUFFICIENT_PRIVILEGES), or if the given set of credentials is not supported (UNSUPPORTED_CREDENTIAL_TYPE). The last error message returned by the network allows the user's host to discover the type of credentials supported. Particularly for mobile environments this might be quite inefficient. Furthermore, it is unlikely that a user supports different types of credentials. The purpose of the error message IDENTITY_CHANGED is unclear. Also, the protection of the error message is not discussed in [7].
ポリシー・エラー・オブジェクトは、ポリシーベースのアドミッション制御または他の資格情報の検証の障害が発生した場合に使用されています。資格証明書の有効期限が切れている場合、認証プロセスは、資源要求（INSUFFICIENT_PRIVILEGESを）禁止場合、または資格情報の与えられたセットは（UNSUPPORTED_CREDENTIAL_TYPE）サポートされていない場合は、現在入手可能なエラーメッセージは、（EXPIRED_CREDENTIALS）の通知を可能にします。ネットワークによって返された最後のエラーメッセージは、ユーザーのホストがサポートされた資格情報の種類を発見することができます。特にモバイル環境のためにこれは非常に非効率的であるかもしれません。また、ユーザーは資格情報の種類をサポートしていることはほとんどありません。エラーメッセージIDENTITY_CHANGEDの目的は不明です。また、エラーメッセージの保護は、[7]で議論されていません。
The Integrity Handshake protocol was designed to allow a crashed or restarted host to obtain the latest valid challenge value stored at the receiving host. Due to the absence of key management, it must be guaranteed that two messages do not use the same sequence number with the same key. A host stores the latest sequence number of a cryptographically verified message. An adversary can replay eavesdropped packets if the crashed host has lost its sequence numbers. A signaling message from the real sender with a new sequence number would therefore allow the crashed host to update the sequence number field and prevent further replays. Hence, if there is a steady flow of RSVP-protected messages between the two hosts, an attacker may find it difficult to inject old messages, because new, authenticated messages with higher sequence numbers arrive and get stored immediately.
完全性ハンドシェークプロトコルがクラッシュしたり再起動し、ホストが受信ホストに格納された最新の有効なチャレンジ値を得ることができるように設計されました。鍵管理の欠如に起因する、2つのメッセージが同じキーで同じシーケンス番号を使用しないことを保証しなければなりません。ホストは、暗号検証メッセージの最新のシーケンス番号を格納します。クラッシュしたホストは、そのシーケンス番号を失った場合、敵は盗聴パケットを再生することができます。新しいシーケンス番号と実際の送信者からのシグナリングメッセージは、したがって、クラッシュしたホストがシーケンス番号フィールドを更新し、さらにリプレイを防ぐことができるようになります。 2つのホスト間のRSVP-保護されたメッセージの安定した流れがある場合はそのため、攻撃者は、より高いシーケンス番号を持つ新しい、認証済みのメッセージが到着し、すぐに格納されますので、それは難しい、古いメッセージを注入するかもしれません。
The following description explains the details of an RSVP Integrity Handshake that is started by Node A after recovering from a synchronization failure:
以下の説明では、同期障害から回復した後、ノードAによって開始されたRSVP完全性ハンドシェイクの詳細を説明します。
Integrity Challenge
整合性の挑戦
(1) Message (including
+----------+ a Cookie) +----------+
| |-------------------------->| |
| Node A | | Node B |
| |<--------------------------| |
+----------+ Integrity Response +----------+
(2) Message (including
the Cookie and the
INTEGRITY object)
Figure 3: RSVP Integrity Handshake.
図3：整合性のハンドシェイクをRSVP。
The details of the messages are as follows:
次のようにメッセージの詳細は以下のとおりです。
CHALLENGE:=(Key Identifier, Challenge Cookie)
CHALLENGE：=（鍵識別子、チャレンジクッキー）
Integrity Challenge Message:=(Common Header, CHALLENGE)
整合性チャレンジメッセージ：=（共通ヘッダ、CHALLENGE）
Integrity Response Message:=(Common Header, INTEGRITY, CHALLENGE)
整合性の応答メッセージ：=（共通ヘッダ、INTEGRITY、CHALLENGE）
The "Challenge Cookie" is suggested to be a MD5 hash of a local secret and a timestamp [1].
「チャレンジクッキーは、」ローカル秘密のMD5ハッシュとタイムスタンプであることが示唆された[1]。
The Integrity Challenge message is not protected with an INTEGRITY object as shown in the protocol flow above. As explained in Section 10 of [1] this was done to avoid problems in situations where both communicating parties do not have a valid starting sequence number.
上記プロトコルフローに示すように、整合性チャレンジメッセージは、完全性の目的で保護されていません。第10項で説明したように、[1]これは、両方の通信当事者が有効な開始シーケンス番号を持っていない状態で問題を避けるために行われました。
Using the RSVP Integrity Handshake protocol is recommended although it is not mandatory (because it may not be needed in all network environments).
それは必須ではないが（それは、すべてのネットワーク環境で必要とされない可能性があるので）RSVP完全性ハンドシェークプロトコルを使用することが推奨されます。
This section describes the protection of the RSVP-provided mechanisms for authentication, authorization, integrity and replay protection individually, user identity confidentiality, and confidentiality of the signaling messages,
このセクションでは、RSVP-提供、個別認証、許可、完全性および再生保護のためのメカニズム、ユーザ識別情報の機密性、およびシグナリングメッセージの機密性の保護を説明します
This paragraph shows the basic interfaces in a simple RSVP network architecture. The architecture below assumes that there is only a single domain and that the two routers are RSVP- and policy-aware. These assumptions are relaxed in the individual paragraphs, as necessary. Layer 2 devices between the clients and their corresponding first-hop routers are not shown. Other network elements like a Kerberos Key Distribution Center and, for example, an LDAP server from which the PDP retrieves its policies are also omitted. The security of various interfaces to the individual servers (KDC, PDP, etc.) depends very much on the security policy of a specific network service provider.
この段落は、単純なRSVPネットワークアーキテクチャの基本的なインタフェースを示しています。アーキテクチャは、以下の単一のドメインのみが存在することを前提とし、2つのルータにRSVP-とポリシー認識していること。これらの仮定は、必要に応じて、個々の段落に緩和されています。クライアントとそれに対応する最初のホップルータの間にレイヤ2つのデバイスが図示されていません。例えば、他のネットワークKerberosキー配布センターのような要素とは、PDPは、そのポリシーを取得し、そこからLDAPサーバも省略されています。個々のサーバ（KDC、PDPなど）への様々なインタフェースのセキュリティは、特定のネットワークサービスプロバイダのセキュリティポリシーに非常に多くを依存しています。
+--------+
| Policy |
+----|Decision|
| | Point +---+
| +--------+ |
| |
| |
+------+ +-+----+ +---+--+ +------+
|Client| |Router| |Router| |Client|
| A +-------+ 1 +--------+ 2 +----------+ B |
+------+ +------+ +------+ +------+
Figure 4: Simple RSVP Architecture.
図4：単純なRSVPアーキテクチャ。
When considering authentication in RSVP, it is important to make a distinction between user and host authentication of the signaling messages. The host is authenticated using the RSVP INTEGRITY object, whereas credentials inside the AUTH_DATA object can be used to authenticate the user. In this section, the focus is on host authentication, whereas the next section covers user authentication.
RSVPでの認証を考えるとき、シグナリングメッセージのユーザーとホスト認証を区別することが重要です。 AUTH_DATAオブジェクト内の証明書がユーザを認証するために使用することができる一方、ホストは、RSVPのINTEGRITYオブジェクトを使用して認証されます。次のセクションでは、ユーザ認証を覆う一方、このセクションでは、焦点は、ホスト認証です。
(1) Authentication
（1）認証
The term "host authentication" is used above, because the
selection of the security association is bound to the host's IP address, as mentioned in Section 3.1 and Section 3.2. Depending
on the key management protocol used to create this security
association and the identity used, it is also possible to bind a
user identity to this security association. Because the key
management protocol is not specified, it is difficult to evaluate
this part, and hence we speak about data-origin authentication
based on the host's identity for RSVP INTEGRITY objects. The
fact that the host identity is used for selecting the security
association has already been described in Section 3.1.
Data-origin authentication is provided with a keyed hash value computed over the entire RSVP message, excluding the keyed message digest field itself. The security association used between the user's host and the first-hop router is, as previously mentioned, not established by RSVP, and it must therefore be available before signaling is started.
データ発信元認証は、鍵付きメッセージは、フィールド自体を消化除く、全体RSVPメッセージに対して計算鍵付きハッシュ値が設けられています。先に述べたように、ユーザのホストと最初のホップルータの間で使用されるセキュリティ・アソシエーションは、RSVPによって確立されておらず、シグナリングが開始される前に、それゆえ利用可能でなければなりません。
* Kerberos for the RSVP INTEGRITY object
RSVP INTEGRITYオブジェクトの*ケルベロス
As described in Section 7 of [1], Kerberos may be used to create the key for the RSVP INTEGRITY object. How to learn the principal name (and realm information) of the other node is outside the scope of [1]. [20] describes a way to distribute principal and realm information via DNS, which can be used for this purpose (assuming that the FQDN or the IP address of the other node for which this information is desired is known). All that is required is to encapsulate the Kerberos ticket inside the policy element. It is furthermore mentioned that Kerberos tickets with expired lifetime must not be used, and the initiator is responsible for requesting and exchanging a new service ticket before expiration.
[1]のセクション7で説明したように、ケルベロスは、RSVP INTEGRITYオブジェクトのキーを作成するために使用されてもよいです。他のノードのプリンシパル名（およびレルム情報）を学習する方法[1]の範囲外です。 [20]（この情報が所望される他のノードのFQDNまたはIPアドレスが既知であると仮定して）は、この目的のために使用することができるDNSを介して、プリンシパルとレルム情報を配布する方法を記載しています。必要とされるすべてのポリシー要素内のKerberosチケットをカプセル化することです。さらに、期限切れの寿命のKerberosチケットを使用してはならないと述べられている、とイニシエータは要求し、満了前に新しいサービスチケットを交換するための責任があります。
RSVP multicast processing in combination with Kerberos involves additional considerations. Section 7 of [1] states that in the multicast case all receivers must share a single key with the Kerberos Authentication Server (i.e., a single principal used for all receivers). From a personal discussion with Rodney Hess, it seems that there is currently no other solution available in the context of Kerberos. Multicast handling therefore leaves some open questions in this context.
ケルベロスとの組み合わせでRSVPマルチキャスト処理は、追加の考慮事項が含まれます。 [1]のセクション7は、マルチキャストの場合にすべての受信機は、Kerberos認証サーバー（すなわち、すべての受信機に使用される単一の主）を有する単一の鍵を共有しなければならないと述べています。ロドニー・ヘスとの個人的な議論から、ケルベロスのコンテキストで使用可能な他のソリューションが現在存在しないようです。したがって、取り扱いマルチキャストは、この文脈では、いくつかの未解決の問題を残します。
In the case where one entity crashed, the established security association is lost and therefore the other node must retransmit the service ticket. The crashed entity can use an Integrity Challenge message to request a new Kerberos ticket to be retransmitted by the other node. If a node receives such a request, then a reply message must be returned.
一方のエンティティがクラッシュした場合には、確立されたセキュリティ関連付けが失われるので、他のノードがサービスチケットを再送信しなければなりません。墜落したエンティティは、他のノードによって再送信される新しいKerberosチケットを要求するために整合性チャレンジメッセージを使用することができます。ノードがそのような要求を受信した場合、その後、応答メッセージが返されなければなりません。
(2) Integrity protection
（2）完全性保護
Integrity protection between the user's host and the first-hop
router is based on the RSVP INTEGRITY object. HMAC-MD5 is
preferred, although other keyed hash functions may also be used
within the RSVP INTEGRITY object. In any case, both
communicating entities must have a security association that
indicates the algorithm to use. This may, however, be difficult,
because no negotiation protocol is defined to agree on a specific
algorithm. Hence, if RSVP is used in a mobile environment, it is
likely that HMAC-MD5 is the only usable algorithm for the RSVP
INTEGRITY object. Only in local environments may it be useful to
switch to a different keyed hash algorithm. The other possible
alternative is that every implementation support the most
important keyed hash algorithms. e.g., MD5, SHA-1, RIPEMD-160,
etc. HMAC-MD5 was chosen mainly because of its performance
characteristics. The weaknesses of MD5 [21] are known and were
initially described in [22]. Other algorithms like SHA-1 [15]
and RIPEMD-160 [21] have stronger security properties.
(3) Replay Protection
（3）リプレイ保護
The main mechanism used for replay protection in RSVP is based on
sequence numbers, whereby the sequence number is included in the
RSVP INTEGRITY object. The properties of this sequence number
mechanism are described in Section 3.1 of [1]. The fact that the
receiver stores a list of sequence numbers is an indicator for a
window mechanism. This somehow conflicts with the requirement
that the receiver only has to store the highest number given in
Section 3 of [1]. We assume that this is an oversight. Section
4.2 of [1] gives a few comments about the out-of-order delivery
and the ability of an implementation to specify the replay
window. Appendix C of [3] describes a window mechanism for
handling out-of-sequence delivery.
(4) Integrity Handshake
（4）完全性ハンドシェーク
The mechanism of the Integrity Handshake is explained in Section
3.5. The Cookie value is suggested to be a hash of a local
secret and a timestamp. The Cookie value is not verified by the
receiver. The mechanism used by the Integrity Handshake is a
simple Challenge/Response message, which assumes that the key
shared between the two hosts survives the crash. If, however,
the security association is dynamically created, then this
assumption may not be true.
In Section 10 of [1], the authors note that an adversary can create a faked Integrity Handshake message that includes challenge cookies. Subsequently, it could store the received response and later try to replay these responses while a responder recovers from a crash or restart. If this replayed Integrity Response value is valid and has a lower sequence number than actually used, then this value is stored at the recovering host. In order for this attack to be successful, the adversary must either have collected a large number of challenge/response value pairs or have "discovered" the cookie generation mechanism (for example by knowing the local secret). The collection of Challenge/Response pairs is even more difficult, because they depend on the Cookie value, the sequence number included in the response message, and the shared key used by the INTEGRITY object.
第10節では、[1]、作者は敵が挑戦クッキーを含んで偽造整合性ハンドシェイクメッセージを作成することができることに注意してください。続いて、受信した応答を格納することができ、後にレスポンダがクラッシュまたは再起動から回復しながら、これらの応答を再生してみてください。このリプレイ完全性応答値が有効であり、実際に使用されるよりも小さいシーケンス番号を持っている場合、この値は回復ホストに格納されています。この攻撃が成功するためには、敵は、いずれかのチャレンジ/レスポンス値のペアを大量に収集している必要がありますか（ローカル秘密を知ることにより、例えば）クッキーの生成メカニズムを「発見」しています。それらはクッキー値、応答メッセージに含まれるシーケンス番号、および完全性オブジェクトによって使用される共有鍵に依存するので、チャレンジ/レスポンスペアのコレクションは、さらに困難です。
(5) Confidentiality
（5）機密
Confidentiality is not considered to be a security requirement
for RSVP. Hence, it is not supported by RSVP, except as
described in paragraph d) of Section 4.3. This assumption may
not hold, however, for enterprises or carriers who want to
protect billing data, network usage patterns, or network
configurations, in addition to users' identities, from
eavesdropping and traffic analysis. Confidentiality may also
help make certain other attacks more difficult. For example, the
PathErr attack described in Section 5.2 is harder to carry out if
the attacker cannot observe the Path message to which the PathErr
corresponds.
(6) Authorization
（6）認証
The task of authorization consists of two subcategories: network
access authorization and RSVP request authorization. Access
authorization is provided when a node is authenticated to the
network, e.g., using EAP [23] in combination with AAA protocols
(for example, RADIUS [24] or DIAMETER [9]). Issues related to
network access authentication and authorization are outside the
scope of RSVP.
The second authorization refers to RSVP itself. Depending on the network configuration:
第二の権限は、それ自体をRSVPに言及します。ネットワーク構成に応じて：
* the router either forwards the received RSVP request to the policy decision point (e.g., using COPS [10] and [11]) to request that an admission control procedure be executed, or
*ルータは、アドミッション制御手順を実行することを要求する（COPSを使用して、例えば[10]及び[11]）ポリシー決定ポイントに受信されたRSVP要求を転送するか、あるいは
* the router supports the functionality of a PDP and, therefore, there is no need to forward the request, or
*ルータは、PDPの機能をサポートし、そのため、要求を転送する必要がない、または
* the router may already be configured with the appropriate policy information to decide locally whether to grant this request.
*ルータは、すでにこの要求を許可するかどうかをローカルに決定するために、適切なポリシー情報を用いて構成することができます。
Based on the result of the admission control, the request may be granted or rejected. Information about the resource-requesting entity must be available to provide policy-based admission control.
アドミッション制御の結果に基づいて、要求が許可または拒否することができます。リソース要求エンティティに関する情報は、ポリシーベースのアドミッション制御を提供するために使用可能でなければなりません。
(7) Performance
（7）パフォーマンス
The computation of the keyed message digest for an RSVP INTEGRITY
object does not represent a performance problem. The protection
of signaling messages is usually not a problem, because these
messages are transmitted at a low rate. Even a high volume of
messages does not cause performance problems for an RSVP router
due to the efficiency of the keyed message digest routine.
Dynamic key management, which is computationally more demanding, is more important for scalability. Because RSVP does not specify a particular key exchange protocol, it is difficult to estimate the effort needed to create the required security associations. Furthermore, the number of key exchanges to be triggered depends on security policy issues like lifetime of a security association, required security properties of the key exchange protocol, authentication mode used by the key exchange protocol, etc. In a stationary environment with a single administrative domain, manual security association establishment may be acceptable and may provide the best performance characteristics. In a mobile environment, asymmetric authentication methods are likely to be used with a key exchange protocol, and some sort of public key or certificate verification needs to be supported.
計算がより要求される動的な鍵管理は、スケーラビリティのためのより重要です。 RSVPは、特定の鍵交換プロトコルを指定していないので、必要なセキュリティアソシエーションを作成するために必要な労力を推定することは困難です。さらに、トリガされる鍵交換の数は、セキュリティアソシエーションの寿命のようなセキュリティポリシーの問題に依存して、鍵交換プロトコル、単一の管理静止環境において等鍵交換プロトコルによって使用される認証方式のセキュリティプロパティを必要ドメインは、手動セキュリティアソシエーションの確立には許容することができ、最高の性能特性を提供することができます。モバイル環境では、非対称認証方法は、鍵交換プロトコルで使用される可能性があり、公開鍵や証明書の検証のいくつかの並べ替えをサポートする必要があります。
As noted in the previous section, RSVP supports both user-based and host-based authentication. Using RSVP, a user may authenticate to the first hop router or to the PDP as specified in [1], depending on the infrastructure provided by the network domain or the architecture used (e.g., the integration of RSVP and Kerberos V5 into the Windows 2000 Operating System [25]). Another architecture in which RSVP is tightly integrated is the one specified by the PacketCable organization. The interested reader is referred to [26] for a discussion of their security architecture.
前のセクションで述べたように、RSVPは、ユーザベースおよびホスト・ベースの認証の両方をサポートします。で指定されるようにRSVPを使用して、ユーザは、PDP最初のホップルータにまたはに認証することができる[1]、ネットワークドメインまたは使用されるアーキテクチャによって提供されるインフラストラクチャに依存して（例えば、Windows 2000の中へのRSVPとKerberos V5の統合オペレーティングシステム[25]）。 RSVPが緊密に統合されているもう一つのアーキテクチャでは、PacketCableの組織によって指定されたものです。興味のある読者は、それらのセキュリティアーキテクチャの議論については[26]と呼ばれます。
(1) Authentication
（1）認証
When a user sends an RSVP PATH or RESV message, this message may
include some information to authenticate the user. [7] describes
how user and application information is embedded into the RSVP
message (AUTH_DATA object) and how to protect it. A router
receiving such a message can use this information to authenticate
the client and forward the user or application information to the
policy decision point (PDP). Optionally, the PDP itself can
authenticate the user, which is described in the next section.
To be able to authenticate the user, to verify the integrity, and
to check for replays, the entire POLICY_DATA element has to be
forwarded from the router to the PDP (e.g., by including the
element into a COPS message). It is assumed, although not
clearly specified in [7], that the INTEGRITY object within the
POLICY_DATA element is sent to the PDP along with all other
attributes.
* Certificate Verification
*証明書の検証
Using the policy element as described in [7], it is not possible to provide a certificate revocation list or other information to prove the validity of the certificate inside the policy element. A specific mechanism for certificate verification is not discussed in [7] and hence a number of them can be used for this purpose. For certificate verification, the network element (a router or the policy decision point) that has to authenticate the user could frequently download certificate revocation lists or use a protocol like the Online Certificate Status Protocol (OCSP) [27] and the Simple Certificate Validation Protocol (SCVP) [28] to determine the current status of a digital certificate.
[7]で説明されるように、ポリシー要素を使用して、証明書失効リストまたはポリシー要素内の証明書の有効性を証明する他の情報を提供することは不可能です。証明書検証のための特定の機構で議論されていない[7]、したがって、それらの数は、この目的のために使用することができます。証明書の検証のために、ユーザーを認証するために持っているネットワーク要素（ルータまたはポリシー決定ポイント）が頻繁に証明書失効リストをダウンロードするか、オンライン証明書状態プロトコル（OCSP）のようなプロトコルを使用して、[27]とシンプルな証明書の検証議定書ができデジタル証明書の現在の状態を決定する（SCVP）[28]。
* User Authentication to the PDP
PDPへ*ユーザー認証
This alternative authentication procedure uses the PDP to authenticate the user instead of the first-hop router. In Section 4.2.1 of [7], the choice is given for the user to obtain a session ticket either for the next hop router or for the PDP. As noted in the same section, the identity of the PDP or the next hop router is statically configured or dynamically retrieved. Subsequently, user authentication to the PDP is considered.
この代替認証手続きではなく、最初のホップルータのユーザーを認証するためにPDPを使用しています。セクション4.2.1に[7]、選択は、ネクストホップルータまたはPDPのためのいずれかのセッションチケットを取得するためにユーザのために与えられています。同じセクションで述べたように、PDPまたはネクストホップルータのアイデンティティは、静的に設定または動的に取り出されます。その後、PDPへのユーザ認証が考慮されます。
* Kerberos-based Authentication to the PDP
PDPへ* Kerberosベースの認証
If Kerberos is used to authenticate the user, then a session ticket for the PDP must be requested first. A user who roams between different routers in the same administrative domain does not need to request a new service ticket, because the same PDP is likely to be used by most or all first-hop routers within the same administrative domain. This is different from the case in which a session ticket for a router has to be obtained and authentication to a router is required. The router therefore plays a passive role of simply forwarding the request to the PDP and executing the policy decision returned by the PDP. Appendix B describes one example of user-to-PDP authentication.
Kerberosは、ユーザーを認証するために使用されている場合は、PDP用のセッションチケットが最初に要求しなければなりません。同じPDPは、同じ管理ドメイン内のほとんどまたは全てのファーストホップルータによって使用される可能性があるので、同じ管理ドメイン内の別のルータ間でローミングするユーザーは、新しいサービスチケットを要求する必要はありません。これは、ルータのセッションチケットを取得する必要があり、ルータへの認証が必要とされている場合は異なっています。ルータは、したがって、単にPDPに要求を転送し、PDPによって返された政策決定を実行する受動的な役割を果たしています。付録Bは、ユーザへのPDP認証の一例について説明します。
User authentication with the policy element provides only unilateral authentication, whereby the client authenticates to the router or to the PDP. If an RSVP message is sent to the user's host and public-key-based authentication is not used, then the message does not contain a certificate and digital signature. Hence, no mutual authentication can be assumed. In case of Kerberos, mutual authentication may be accomplished if the PDP or the router transmits a policy element with an INTEGRITY object computed with the session key retrieved from the Kerberos ticket, or if the Kerberos ticket included in the policy element is also used for the RSVP INTEGRITY object as described in Section 4.2. This procedure only works if a previous message was transmitted from the end host to the network and such key is already established. Reference [7] does not discuss this issue, and therefore there is no particular requirement for transmitting network-specific credentials back to the end-user's host.
ポリシー要素を持つユーザー認証は、クライアントがルータやPDPに認証することにより、唯一の一方的な認証を提供します。 RSVPメッセージは、ユーザのホストに送信され、公開鍵ベースの認証を使用しない場合、メッセージは、証明書とデジタル署名が含まれていません。したがって、何の相互認証を仮定することはできません。 PDPやルータがKerberosチケットから取り出されたセッション鍵を用いて計算INTEGRITYオブジェクトとポリシー要素を送信する場合のKerberosの場合には、相互認証が達成されてもよい、Kerberosチケットは、他にも使用されているポリシー要素または含まれている場合セクション4.2で説明したようにRSVP INTEGRITYオブジェクト。前のメッセージは、ネットワークへのエンドホストから送信されたと、そのようなキーが既に確立されている場合は、この手順はのみ動作します。参考文献[7]、この問題を議論していないので、バックエンド・ユーザーのホストへのネットワーク固有の資格情報を送信するための特別な要件はありません。
(2) Integrity Protection
（2）完全性保護
Integrity protection is applied separately to the RSVP message
and the POLICY_DATA element, as shown in Figure 1. In case of
a policy-ignorant node along the path, the RSVP INTEGRITY
object and the INTEGRITY object inside the policy element
terminate at different nodes. Basically, the same is true for
the user credentials if they are verified at the policy
decision point instead of the first hop router.
* Kerberos
*ケルベロス
If Kerberos is used to authenticate the user to the first hop router, then the session key included in the Kerberos ticket may be used to compute the INTEGRITY object of the policy element. It is the keyed message digest that provides the authentication. The existence of the Kerberos service ticket inside the AUTH_DATA object does not provide authentication or a guarantee of freshness for the receiving host.
Kerberosが最初のホップルータにユーザを認証するために使用されている場合は、Kerberosチケットに含まれたセッションキーは、ポリシー要素のINTEGRITYオブジェクトを計算するために使用することができます。これは、認証を提供するキー付きメッセージダイジェストです。 AUTH_DATAオブジェクト内のKerberosサービスチケットの存在は、認証または受信ホストの新鮮さの保証を提供していません。
Authentication and guarantee of freshness are provided by the keyed hash value of the INTEGRITY object inside the POLICY_DATA element. This shows that the user actively participated in the Kerberos protocol and was able to obtain the session key to compute the keyed message digest. The Authenticator used in the Kerberos V5 protocol provides similar functionality, but replay protection is based on timestamps (or on a sequence number if the optional seq-number field inside the Authenticator is used for KRB_PRIV/KRB_SAFE messages as described in Section 5.3.2 of [8]).
鮮度の認証及び保証はPOLICY_DATA要素内INTEGRITYオブジェクトの鍵付きハッシュ値によって提供されます。これは、ユーザが積極的にKerberosプロトコルに参加し、キー付きメッセージダイジェストを計算するためのセッション鍵を得ることができたことを示しています。 Kerberos V5プロトコルで使用されるオーセンティケータは、同様の機能を提供するが、セクション5.3.2で説明したように認証内部オプション配列番号フィールドはKRB_PRIV / KRB_SAFEメッセージのために使用された場合、リプレイ保護はタイムスタンプ（またはシーケンス番号に基づいています[8]）。
* Digital Signature
* デジタル署名
If public-key-based authentication is provided, then user authentication is accomplished with a digital signature. As explained in Section 3.3.3 of [7], the DIGITAL_SIGNATURE attribute must be the last attribute in the AUTH_DATA object, and the digital signature covers the entire AUTH_DATA object. In the case of PGP, which hash algorithm and public key algorithm are used for the digital signature computation is described in [19]. In the case of X.509 credentials, the situation is more complex because different mechanisms like CMS [29] or PKCS#7 [30] may be used for digitally signing the message element. X.509 only provides the standard for the certificate layout, which seems to provide insufficient information for this purpose. Therefore, X.509 certificates are supported, for example, by CMS or PKCS#7. [7], however, does not make any statements about the usage of CMS or PKCS#7. Currently, there is no support for CMS or for PKCS#7 [7], which provides more than just public-key-based authentication (e.g., CRL distribution, key transport, key agreement, etc.). Furthermore, the use of PGP in RSVP is vaguely defined, because there are different versions of PGP (including OpenPGP [19]), and no indication is given as to which should be used.
公開鍵ベースの認証が提供されている場合、ユーザ認証は、デジタル署名を用いて達成されます。 [7]のセクション3.3.3で説明したように、DIGITAL_SIGNATURE属性はAUTH_DATAオブジェクト内の最後の属性でなければならず、デジタル署名全体AUTH_DATAオブジェクトを覆っています。ハッシュアルゴリズム及び公開鍵アルゴリズムは、デジタル署名の計算に使用されているPGPの場合、[19]に記載されています。 CMS [29]またはPKCS＃7 [30]のような異なる機構がデジタルメッセージ要素に署名するために使用することができるので、X.509認証情報の場合には、状況はより複雑です。 X.509は、この目的のために十分な情報を提供するように思われ、証明書のレイアウトのための標準を提供します。したがって、X.509証明書は、CMSまたはPKCS＃7によって、例えば、サポートされています。 [7]、しかし、CMSまたはPKCS＃7の使用状況に関するすべてのステートメントを作成しません。現在、CMSまたは単に公開鍵ベースの認証（例えば、CRL分布、主要な輸送、鍵合意等）以上を提供するPKCS＃7 [7]のためのサポートはありません。さらに、（OpenPGPの[19]を含む）PGPの異なるバージョンが存在するため、RSVPにPGPを使用することは漠然と定義され、かつ使用されるべきであるよう兆候が与えられていません。
Supporting public-key-based mechanisms in RSVP might increase the risks of denial-of-service attacks. The large processing, memory, and bandwidth requirements should also be considered. Fragmentation might also be an issue here.
RSVPに公開鍵ベースのメカニズムをサポートするサービス拒否攻撃のリスクが増加する可能性があります。大規模な処理、メモリ、および帯域幅の要件も考慮しなければなりません。断片化もここで問題になる可能性があります。
If the INTEGRITY object is not included in the POLICY_DATA element or not sent to the PDP, then we have to make the following observations:
INTEGRITYオブジェクトがPOLICY_DATA要素に含まれていないか、PDPに送信されていない場合、我々は以下の観察を行う必要があります。
For the digital signature case, only the replay protection provided by the digital signature algorithm can be used. It is not clear, however, whether this usage was anticipated or not. Hence, we might assume that replay protection is based on the availability of the RSVP INTEGRITY object used with a security association that is established by other means.
デジタル署名の場合は、デジタル署名アルゴリズムによって提供されるのみ再生保護を使用することができます。これは、この使用が予想されたかどうかは明らかではありません。そこで、私たちはそのリプレイ保護が他の手段によって確立されたセキュリティアソシエーションで使用RSVPのINTEGRITYオブジェクトの可用性に基づいていると仮定することがあります。
Including only the Kerberos session ticket is insufficient, because freshness is not provided (because the Kerberos Authenticator is missing). Obviously there is no guarantee that the user actually followed the Kerberos protocol and was able to decrypt the received TGS_REP (or, in rare cases, the AS_REP if a session ticket is requested with the initial AS_REQ).
（ケルベロス認証がないため）、鮮度が提供されていないため、含めのみケルベロスセッションチケットは、不十分です。もちろん、ユーザーが実際にKerberosプロトコルに従い、（セッションチケットは、初期AS_REQで要求された場合や、まれに、AS_REP）受信TGS_REPを解読することができたという保証はありません。
(3) Replay Protection
（3）リプレイ保護
Figure 5 shows the interfaces relevant for replay protection of
signaling messages in a more complicated architecture. In this
case, the client uses the policy data element with PEP2, because
PEP1 is not policy-aware. The interfaces between the client and
PEP1 and between PEP1 and PEP2 are protected with the RSVP
INTEGRITY object. The link between the PEP2 and the PDP is
protected, for example, by using the COPS built-in INTEGRITY
object. The dotted line between the Client and the PDP indicates
the protection provided by the AUTH_DATA element, which has no
RSVP INTEGRITY object included.
AUTH_DATA +----+
+---------------------------------------------------+PDP +-+
| +----+ |
| |
| |
| COPS |
| INTEGRITY|
| |
| |
| |
+--+---+ RSVP INTEGRITY +----+ RSVP INTEGRITY +----+ |
|Client+-------------------+PEP1+----------------------+PEP2+-+
+--+---+ +----+ +-+--+
| |
+-----------------------------------------------------+
POLICY_DATA INTEGRITY
Figure 5: Replay Protection.
図5：リプレイ保護。
Host authentication with the RSVP INTEGRITY object and user authentication with the INTEGRITY object inside the POLICY_DATA element both use the same anti-replay mechanism. The length of the Sequence Number field, sequence number rollover, and the Integrity Handshake have already been explained in Section 3.1.
POLICY_DATA要素内INTEGRITYオブジェクトとRSVPのINTEGRITYオブジェクトとユーザ認証で認証をホストの両方同じアンチリプレイ機構を使用します。シーケンス番号フィールド、シーケンス番号のロールオーバー、および整合性のハンドシェイクの長さは、すでに3.1節で説明されています。
Section 9 of [7] states: "RSVP INTEGRITY object is used to protect the policy object containing user identity information from security (replay) attacks." When using public-key-based authentication, RSVP-based replay protection is not supported, because the digital signature does not cover the POLICY_DATA INTEGRITY object with its Sequence Number field. The digital signature covers only the entire AUTH_DATA object.
[7]のセクション9の状態：「RSVPのINTEGRITYオブジェクトがセキュリティ（リプレイ）攻撃からユーザ識別情報を含むポリシー・オブジェクトを保護するために使用されます。」公開鍵ベースの認証を使用する場合は、デジタル署名は、そのシーケンス番号フィールドとPOLICY_DATA INTEGRITYオブジェクトをカバーしていないので、RSVPベースのリプレイ保護は、サポートされていません。デジタル署名は、全体AUTH_DATAオブジェクトを覆っています。
The use of public key cryptography within the AUTH_DATA object complicates replay protection. Digital signature computation with PGP is described in [31] and in [19]. The data structure preceding the signed message digest includes information about the message digest algorithm used and a 32-bit timestamp of when the signature was created ("Signature creation time"). The timestamp is included in the computation of the message digest. The IETF standardized version of OpenPGP [19] contains more information and describes the different hash algorithms (MD2, MD5, SHA-1, RIPEMD-160) supported. [7] does not make any statements as to whether the "Signature creation time" field is used for replay protection. Using timestamps for replay protection requires different synchronization mechanisms in the case of clock-skew. Traditionally, these cases assume "loosely synchronized" clocks but also require specifying a replay window.
AUTH_DATAオブジェクト内の公開鍵暗号の使用は、再生保護を複雑にします。 PGPでデジタル署名の計算は、[31]および[19]に記載されています。署名されたメッセージダイジェストを先行するデータ構造が使用されるアルゴリズム及び署名が作成されたときの32ビットのタイムスタンプ（「署名作成時間」）メッセージダイジェストに関する情報を含みます。タイムスタンプは、メッセージダイジェストの計算に含まれます。 OpenPGPの[19]のIETF標準化されたバージョンは、より多くの情報が含まれており、異なるハッシュアルゴリズム（MD2、MD5、SHA-1、RIPEMD-160）サポートを記述する。 [7]「署名の作成時間」フィールドはリプレイ保護のために使用されているかどうかのいずれかの書類を作成しません。リプレイ保護のためのタイムスタンプを使用してクロック・スキューの場合には、異なる同期メカニズムを必要とします。伝統的に、これらの例は、「緩やかに同期化」クロックを前提ともリプレイウィンドウを指定する必要があります。
If the "Signature creation time" is not used for replay protection, then a malicious, policy-ignorant node can use this weakness to replace the AUTH_DATA object without destroying the digital signature. If this was not simply an oversight, it is therefore assumed that replay protection of the user credentials was not considered an important security requirement, because the hop-by-hop processing of the RSVP message protects the message against modification by an adversary between two communicating nodes.
「署名の作成時間は、」リプレイ保護のために使用されていない場合は、悪質な、政策無知なノードは、デジタル署名を破壊することなくAUTH_DATAオブジェクトを置き換えるために、この弱点を使用することができます。これは単に見落としなかった場合RSVPメッセージのホップバイホップ処理は、2つの通信の間に敵によって変形に対してメッセージを保護するため、したがって、重要なセキュリティ要件と考えられていなかったユーザーの資格情報の再生保護を想定していますノード。
The lifetime of the Kerberos ticket is based on the fields starttime and endtime of the EncTicketPart structure in the ticket, as described in Section 5.3.1 of [8]. Because the ticket is created by the KDC located at the network of the verifying entity, it is not difficult to have the clocks roughly synchronized for the purpose of lifetime verification. Additional information about clock-synchronization and Kerberos can be found in [32].
Kerberosチケットの有効期間は、フィールドに基づいている[8]のセクション5.3.1に記載したように、チケットにSTARTTIMEとEncTicketPart構造の終了時刻。チケットは検証エンティティのネットワークに位置KDCによって作成されているので、大体寿命の確認のために同期したクロックを持つことは難しいことではありません。クロック同期とKerberosに関する追加情報は、[32]に記載されています。
If the lifetime of the Kerberos ticket expires, then a new ticket must be requested and used. Rekeying is implemented with this procedure.
Kerberosチケットの有効期間が満了した場合、新しいチケットを要求して使用する必要があります。鍵の変更は、この手順で実装されています。
(4) (User Identity) Confidentiality
（4）（ユーザー識別）機密性
This section discusses privacy protection of identity information
transmitted inside the policy element. User identity
confidentiality is of particular interest because there is no
built-in RSVP mechanism for encrypting the POLICY_DATA object or
the AUTH_DATA elements. Encryption of one of the attributes
inside the AUTH_DATA element, the POLICY_LOCATOR attribute, is
discussed.
To protect the user's privacy, it is important not to reveal the user's identity to an adversary located between the user's host and the first-hop router (e.g., on a wireless link). Furthermore, user identities should not be transmitted outside the domain of the visited network provider. That is, the user identity information inside the policy data element should be removed or modified by the PDP to prevent revealing its contents to other (unauthorized) entities along the signaling path. It is not possible (with the offered mechanisms) to hide the user's identity in such a way that it is not visible to the first policy-aware RSVP node (or to the attached network in general).
ユーザーのプライバシーを保護するために、（無線リンク上で、例えば）ユーザのホストと最初のホップルータの間に位置し、敵対する者の身元を明らかにしないことが重要です。さらに、ユーザーIDは、訪問先ネットワークプロバイダのドメイン外に送信すべきではありません。すなわち、ポリシーデータ要素内のユーザ識別情報がシグナリングパスに沿って他の（不正な）エンティティに、その内容を明らかに防止するために、PDPによって削除または変更されるべきであるています。それは最初のポリシー対応RSVPノードへ（又は一般的に接続されたネットワークに）表示されないような方法でユーザの身元を隠すために（提供機構を有する）ことは不可能です。
The ASCII or Unicode distinguished name of the user or application inside the POLICY_LOCATOR attribute of the AUTH_DATA element may be encrypted as specified in Section 3.3.1 of [7]. The user (or application) identity is then encrypted with either the Kerberos session key or with the private key in case of public-key-based authentication. When the private key is used, we usually speak of a digital signature that can be verified by everyone possessing the public key. Because the certificate with the public key is included in the message itself, decryption is no obstacle. Furthermore, the included certificate together with the additional (unencrypted) information in the RSVP message provides enough identity information for an eavesdropper. Hence, the possibility of encrypting the policy locator in case of public-key-based authentication is problematic. To encrypt the identities using asymmetric cryptography, the user's host must be able somehow to retrieve the public key of the entity verifying the policy element (i.e., the first policy-aware router or the PDP). Then, this public key could be used to encrypt a symmetric key, which in turn encrypts the user's identity and certificate, as is done, e.g., by PGP. Currently, no such mechanism is defined in [7].
[7]のセクション3.3.1で指定されるようにAUTH_DATA素子のPOLICY_LOCATOR属性内のユーザまたはアプリケーションのASCIIまたはUnicode識別名が暗号化されてもよいです。ユーザー（またはアプリケーション）のアイデンティティは、いずれかのKerberosセッションキーまたは公開キーベースの認証の場合、秘密鍵で暗号化されています。秘密鍵を使用する場合、我々は通常、公開鍵を持つ誰もが検証できるデジタル署名の話します。公開鍵と証明書がメッセージ自体に含まれているため、解読は支障はありません。また、一緒にRSVPメッセージ内の追加の（暗号化されていない）情報に含まれている証明書は、盗聴者のための十分な識別情報を提供します。したがって、公開鍵ベースの認証の場合、ポリシー・ロケータを暗号化する可能性が問題となります。非対称暗号を使用してIDを暗号化するには、ユーザのホストは、ポリシー要素（すなわち、最初のポリシー認識ルータまたはPDP）を検証するエンティティの公開鍵を取得何とかできなければなりません。次に、この公開鍵はPGPにより、例えば、行われているように、今度はユーザーのIDと証明書を暗号化対称鍵を暗号化するために使用することができます。現在、そのような機構は、[7]で定義されていません。
The algorithm used to encrypt the POLICY_LOCATOR with the Kerberos session key is assumed to be the same as the one used for encrypting the service ticket. The information about the algorithm used is available in the etype field of the EncryptedData ASN.1 encoded message part. Section 6.3 of [8] lists the supported algorithms. [33] defines newer encryption algorithms (Rijndael, Serpent, and Twofish).
ケルベロスセッションキーとPOLICY_LOCATORを暗号化するために使用されるアルゴリズムは、サービスチケットの暗号化に使用したものと同じであると仮定されます。使用されるアルゴリズムについての情報は、はEncryptedData ASN.1符号化されたメッセージ部分のETYPE分野で利用可能です。 [8]サポートされているアルゴリズムを示していますのセクション6.3。 [33]新しい暗号化アルゴリズム（ラインダール、蛇、およびTwofishは）を定義します。
Evaluating user identity confidentiality also requires looking at protocols executed outside of RSVP (for example, the Kerberos protocol). The ticket included in the CREDENTIAL attribute may provide user identity protection by not including the optional cname attribute inside the unencrypted part of the Ticket. Because the Authenticator is not transmitted with the RSVP message, the cname and the crealm of the unencrypted part of the Authenticator are not revealed. In order for the user to request the Kerberos session ticket for inclusion in the CREDENTIAL attribute, the Kerberos protocol exchange must be executed. Then the Authenticator sent with the TGS_REQ reveals the identity of the user. The AS_REQ must also include the user's identity to allow the Kerberos Authentication Server to respond with an AS_REP message that is encrypted with the user's secret key. Using Kerberos, it is therefore only possible to hide the content of the encrypted policy locator, which is only useful if this value differs from the Kerberos principal name. Hence, using Kerberos it is not "entirely" possible to provide user identity confidentiality.
ユーザ識別情報の機密性を評価することもRSVP（例えば、Kerberosプロトコル）の外で実行プロトコルを見て必要とします。 CREDENTIAL属性に含まれたチケットは、チケットの暗号化されていない部分内のオプションCNAME属性を含めないことで、ユーザのアイデンティティ保護を提供することができます。認証がRSVPメッセージで送信されないため、CNAMEと認証の暗号化されていない部分のcrealmが明らかにされていません。 CREDENTIAL属性に含めるためにケルベロスセッションチケットを要求するユーザーのために、Kerberosプロトコル交換が実行されなければなりません。そして、TGS_REQに送られた認証は、ユーザーの身元を明らかにする。 AS_REQはまた、Kerberos認証サーバーがユーザーの秘密鍵で暗号化されたAS_REPメッセージで応答することを可能にするユーザーのIDを含める必要があります。 Kerberosを使用して、この値は、Kerberosプリンシパル名と異なる場合にのみ有用である暗号化されたポリシーロケータの内容を非表示にするため、のみ可能です。したがって、Kerberosを使用すると、ユーザーIDの機密性を提供するために、「完全に」ことはできません。
It is important to note that information stored in the policy element may be changed by a policy-aware router or by the policy decision point. Which parts are changed depends upon whether multicast or unicast is used, how the policy server reacts, where the user is authenticated, whether the user needs to be re-authenticated in other network nodes, etc. Hence, user-specific and application-specific information can leak after the messages leave the first hop within the network where the user's host is attached. As mentioned at the beginning of this section, this information leakage is assumed to be intentional.
ポリシー要素に格納されている情報は、政策対応のルーターまたはポリシー決定ポイントによって変更することができることに留意することが重要です。どの部分が変更され、マルチキャストまたはユニキャスト、ポリシーサーバは、ユーザが他のネットワークノード、等したがって、ユーザ固有およびアプリケーション固有で再認証する必要があるかどうか、ユーザが認証された場合、どのように反応するか、使用されているかどうかに依存しますメッセージは、ユーザのホストが接続されているネットワーク内の最初のホップを離れた後に情報が漏洩することができます。このセクションの冒頭で述べたように、この情報漏洩は、意図的であると仮定されます。
(5) Authorization
（5）認証
In addition to the description of the authorization steps of the
Host-to-Router interface, user-based authorization is performed
with the policy element providing user credentials. The
inclusion of user and application specific information enables
policy-based admission control with special user policies that
are likely to be stored at a dedicated server. Hence, a Policy
Decision Point can query, for example, an LDAP server for a service level agreement that states the amount of resources a
certain user is allowed to request. In addition to the user
identity information, group membership and other non-security-
related information may contribute to the evaluation of the final
policy decision. If the user is not registered to the currently
attached domain, then there is the question of how much
information the home domain of the user is willing to exchange.
This also impacts the user's privacy policy.
In general, the user may not want to distribute much of this policy information. Furthermore, the lack of a standardized authorization data format may create interoperability problems when exchanging policy information. Hence, we can assume that the policy decision point may use information from an initial authentication and key agreement protocol (which may have already required cross-realm communication with the user's home domain, if only to show that the home domain knows the user and that the user is entitled to roam), to forward accounting messages to this domain. This represents the traditional subscriber-based accounting scenario. Non-traditional or alternative means of access might be deployed in the near future that do not require any type of inter-domain communication.
一般に、ユーザーがこのポリシー情報の多くを配布したくないかもしれません。ポリシー情報を交換する際にさらに、標準化された認証データフォーマットの欠如は、相互運用性の問題を作成することがあります。したがって、我々はホームドメインは、ユーザーを知っているし、そのことを示すために、場合にのみ、ポリシー決定ポイントは、最初の認証済みユーザーのホームドメインにクロスレルム通信を必要としている可能性があり、キー合意プロトコル（からの情報を使用することができると仮定することができますユーザーは、このドメインにアカウンティングメッセージを転送するために、）をローミングする権利があります。これは、従来の加入者ベースの会計シナリオを表します。アクセスの非伝統的または代替手段は、ドメイン間通信のいずれかのタイプを必要としない、近い将来に配備される可能性があります。
Additional discussions are required to determine the expected authorization procedures. [34] and [35] discuss authorization issues for QoS signaling protocols. Furthermore, a number of mobility implications for policy handling in RSVP are described in [36].
追加の議論が予想されるの認可手続きを決定するために必要とされます。 [34]と[35]のQoSシグナリングプロトコルの認可の問題を議論します。また、RSVPのポリシー処理のためのモビリティの影響の数は[36]に記載されています。
(6) Performance
（6）パフォーマンス
If Kerberos is used for user authentication, then a Kerberos
ticket must be included in the CREDENTIAL Section of the
AUTH_DATA element. The Kerberos ticket has a size larger than
500 bytes, but it only needs to be sent once because a
performance optimization allows the session key to be cached as
noted in Section 7.1 of [1]. It is assumed that subsequent RSVP
messages only include the POLICY_DATA INTEGRITY object with a
keyed message digest that uses the Kerberos session key.
However, this assumes that the security association required for
the POLICY_DATA INTEGRITY object is created (or modified) to
allow the selection of the correct key. Otherwise, it difficult
to say which identifier is used to index the security
association.
If Kerberos is used as an authentication system then, from a performance perspective, the message exchange to obtain the session key needs to be considered, although the exchange only needs to be done once in the lifetime of the session ticket. This is particularly true in a mobile environment with a fast roaming user's host.
Kerberosは、認証システムとして使用されている場合は交換のみセッションチケットの有効期間中に一度実行する必要があるが、性能の観点から、メッセージ交換は、セッション鍵を考慮する必要があり得ます。これは、高速ローミングユーザーのホストとモバイル環境では特にそうです。
Public-key-based authentication usually provides the best scalability characteristics for key distribution, but the protocols are performance demanding. A major disadvantage of the public-key-based user authentication in RSVP is the lack of a method to derive a session key. Hence, every RSVP PATH or RESV message includes the certificate and a digital signature, which is a huge performance and bandwidth penalty. For a mobile environment with low power devices, high latency, channel noise, and low-bandwidth links, this seems to be less encouraging. Note that a public key infrastructure is required to allow the PDP (or the first-hop router) to verify the digital signature and the certificate. To check for revoked certificates, certificate revocation lists or protocols like the Online Certificate Status Protocol [27] and the Simple Certificate Validation Protocol [28] are needed. Then the integrity of the AUTH_DATA object can be verified via the digital signature.
公開鍵ベースの認証は、通常、鍵の配布のための最高のスケーラビリティ特性を提供しますが、プロトコルは、性能要求されています。 RSVPにおける公開鍵ベースのユーザー認証の主な欠点は、セッション鍵を導出する方法の欠如です。したがって、すべてのRSVP PATHまたはRESVメッセージは、証明書と巨大なパフォーマンスと帯域幅ペナルティであるデジタル署名を含みます。低電力デバイス、高遅延、チャネルノイズ、低帯域幅リンクでのモバイル環境では、これはあまり有望であると思われます。公開鍵インフラストラクチャがPDP（又は第1のホップ・ルータ）は、デジタル署名と証明書を検証できるようにするために必要であることに留意されたいです。失効した証明書、オンライン証明書状態プロトコルのような証明書失効リストまたはプロトコル[27]とシンプルな証明書の検証議定書[28]をチェックするために必要とされています。次いで、AUTH_DATAオブジェクトの整合性は、デジタル署名を介して確認することができます。
(1) Authentication
（1）認証
RSVP signaling messages have data origin authentication and are
protected against modification and replay with the RSVP INTEGRITY
object. The RSVP message flow between routers is protected based
on the chain of trust, and hence each router needs only a
security association with its neighboring routers. This
assumption was made because of performance advantages and because
of special security characteristics of the core network to which
no user hosts are directly attached. In the core network the
network structure does not change frequently and the manual
distribution of shared secrets for the RSVP INTEGRITY object may
be acceptable. The shared secrets may be either manually
configured or distributed by using appropriately secured network
management protocols like SNMPv3.
Independent of the key distribution mechanism, host authentication with built-in RSVP mechanisms is accomplished using the keyed message digest in the RSVP INTEGRITY object, computed using the previously exchanged symmetric key.
鍵配布機構から独立し、内蔵RSVPメカニズムとホストの認証はキー付きメッセージはRSVPのINTEGRITYオブジェクトにダイジェストを使用して達成され、以前に交換された対称鍵を使用して計算。
(2) Integrity Protection
（2）完全性保護
Integrity protection is accomplished with the RSVP INTEGRITY
object with the variable length Keyed Message Digest field.
(3) Replay Protection
（3）リプレイ保護
Replay protection with the RSVP INTEGRITY object is extensively
described in previous sections. To enable crashed hosts to learn
the latest sequence number used, the Integrity Handshake
mechanism is provided in RSVP.
(4) Confidentiality
（4）機密
Confidentiality is not provided by RSVP.
機密性は、RSVPによって提供されていません。
(5) Authorization
（5）認証
Depending on the RSVP network, QoS resource authorization at
different routers may need to contact the PDP again. Because the
PDP is allowed to modify the policy element, a token may be added
to the policy element to increase the efficiency of the re-
authorization procedure. This token is used to refer to an
already computed policy decision. The communications interface
from the PEP to the PDP must be properly secured.
(6) Performance
（6）パフォーマンス
The performance characteristics for the protection of the RSVP
signaling messages is largely determined by the key exchange
protocol, because the RSVP INTEGRITY object is only used to
compute a keyed message digest of the transmitted signaling
messages.
The security associations within the core network, that is, between individual routers (in comparison with the security association between the user's host and the first-hop router or with the attached network in general), can be established more easily because of the normally strong trust assumptions. Furthermore, it is possible to use security associations with an increased lifetime to avoid frequent rekeying. Hence, there is less impact on the performance compared with the user-to-network interface. The security association storage requirements are also less problematic.
（ユーザのホストと一般的に接続されたネットワークとの最初のホップルータ又は間のセキュリティアソシエーションと比較して）個々のルータの間に、あるコアネットワーク内のセキュリティアソシエーションは、なぜなら通常強力でより容易に確立することができます仮定を信頼しています。さらに、頻繁に再入力を避けるために、長寿命でセキュリティアソシエーションを使用することが可能です。したがって、ユーザ対ネットワークインターフェースと比べて性能にあまり影響があります。セキュリティ関連のストレージ要件もそれほど問題があります。
This section describes a number of issues that illustrate some of the shortcomings of RSVP with respect to security.
このセクションでは、セキュリティに対するRSVPの欠点のいくつかを説明する多くの問題を説明します。
In case of end-to-end signaling, an end host starts signaling to its attached network. The first-hop communication is often more difficult to secure because of the different requirements and a missing trust relationship. An end host must therefore obtain some information to start RSVP signaling:
エンドツーエンド・シグナリングの場合に、エンドホストは、接続されたネットワークにシグナリングを開始します。最初のホップ通信が異なるための要件と不足している信頼関係をしばしば確保することがより困難です。エンドホストは、したがって、RSVPシグナリングを開始するには、いくつかの情報を取得する必要があります。
o Does this network support RSVP signaling?
oがこのネットワークサポートRSVPシグナリングをしていますか？
o Which node supports RSVP signaling?
OどのノードがRSVPシグナリングをサポートしていますか？
o To which node is authentication required?
oはどのノード認証が必要になるために？
o Which security mechanisms are used for authentication?
Oセキュリティメカニズムは、認証のために使用されていますか？
o Which algorithms are required?
Oアルゴリズムが必要とされていますか？
o Where should the keys and security associations come from?
Oキーおよびセキュリティアソシエーションはどこから来る必要がありますか？
o Should a security association be established?
Oセキュリティアソシエーションが確立されるべきか？
RSVP, as specified today, is used as a building block. Hence, these questions have to be answered as part of overall architectural considerations. Without answers to these questions, ad hoc RSVP communication by an end host roaming to an unknown network is not possible. A negotiation of security mechanisms and algorithms is not supported for RSVP.
RSVPは、今日指定されているように、ビルディングブロックとして使用されています。したがって、これらの質問は、全体的なアーキテクチャの考慮事項の一部として回答する必要があります。これらの質問に対する答えがなければ、未知のネットワークにローミングエンドホストによってアドホックRSVP通信ができません。セキュリティ・メカニズムとアルゴリズムのネゴシエーションはRSVPのためにサポートされていません。
Throughout the document it was assumed that the next RSVP node along the path is always known. Knowing the next hop is important to be able to select the correct key for the RSVP Integrity object and to apply the proper protection. In the case in which an RSVP node assumes it knows which node is the next hop, the following protocol exchange can occur:
文書全体それは経路に沿った次のRSVPノードが常に既知であると仮定しました。ネクストホップを知ることは、RSVPのIntegrityオブジェクトのための正しいキーを選択できるように、適切な保護を適用することが重要です。 RSVPノードは、それが次のホップであるノードを知っている前提としていた場合には、以下のプロトコル交換が発生する可能性があります。
Integrity
(A<->C) +------+
(3) | RSVP |
+------------->+ Node |
| | B |
Integrity | +--+---+
(A<->C) | |
+------+ (2) +--+----+ |
(1) | RSVP +----------->+Router | | Error
----->| Node | | or +<-----------+ (I am B)
| A +<-----------+Network| (4)
+------+ (5) +--+----+
Error .
(I am B) . +------+
. | RSVP |
...............+ Node |
| C |
+------+
Figure 6: Next-Hop Issue.
図6：次のホップの問題。
When RSVP node A in Figure 6 receives an incoming RSVP Path message, standard RSVP message processing takes place. Node A then has to decide which key to select to protect the signaling message. We assume that some unspecified mechanism is used to make this decision. In this example, node A assumes that the message will travel to RSVP node C. However, for some reasons (e.g., a route change, inability to learn the next RSVP hop along the path, etc.) the message travels to node B via a non-RSVP supporting router that cannot verify the integrity of the message (or cannot decrypt the Kerberos service ticket). The processing failure causes a PathErr message to be returned to the originating sender of the Path message. This error message also contains information about the node that recognized the error. In many cases, a security association might not be available. Node A receiving the PathErr message might use the information returned with the PathErr message to select a different security association (or to establish one).
図6のRSVPノードAが着信RSVP Pathメッセージを受信した場合、標準のRSVPメッセージの処理が行われます。ノードAは、シグナリングメッセージを保護するために、選択するキーを決定する必要があります。我々はいくつかの不特定のメカニズムは、この決定を行うために使用されていることを前提としています。この例では、ノードAは、メッセージがいくつかの理由で、しかしノードCをRSVPに移動すると仮定（例えば、経路変更等の経路に沿って次のRSVPホップを学習することができない）メッセージを介してノードBに移動しますメッセージの整合性を検証することはできません（またはKerberosサービスチケットを解読することはできません）非RSVPサポートするルータ。処理の失敗はのPathErrメッセージは、Pathメッセージの元の送信者に返されるようにします。このエラーメッセージは、エラーを認識したノードに関する情報が含まれています。多くの場合、セキュリティアソシエーションが使用できない場合があります。たPathErrメッセージを受信したノードAは、異なるセキュリティアソシエーションを選択する（または1つを確立する）のPathErrメッセージで返された情報を使用することがあります。
Figure 6 describes a behavior that might help node A learn that an error occurred. However, the description in Section 4.2 of [1] states in step (5) that a signaling message is silently discarded if the receiving host cannot properly verify the message: "If the calculated digest does not match the received digest, the message is discarded without further processing." For RSVP Path and similar messages, this functionality is not really helpful.
図6は、ノードAは、エラーが発生したことを学ぶのを助けるかもしれない動作について説明します。しかし、[1]ステップにおける状態のセクション4.2で説明が（5）受信ホストが正しくメッセージを確認できない場合、シグナリングメッセージは黙って破棄されること：「計算されたダイジェストは、受信したダイジェストと一致しない場合、メッセージは破棄されますさらに処理せずに。」 RSVPのパスと類似したメッセージの場合、この機能は本当に便利ではありません。
The RSVP Path message therefore provides a number of functions: path discovery, detecting route changes, discovery of QoS capabilities along the path using the Adspec object (with some interpretation), next-hop discovery, and possibly security association establishment (for example, in the case of Kerberos).
で、ルート変更、（いくつかの解釈を伴う）ADSPECオブジェクトを使用して、パスに沿ってQoS機能の発見、次ホップの発見、例えば、おそらくセキュリティ・アソシエーションの確立を（検出、パス検出：RSVP Pathメッセージは、したがって、多くの機能を提供しますケルベロスの場合）。
From a security point of view, there are conflicts between:
セキュリティの観点から、間の競合があります。
o Idempotent message delivery and efficiency
Oべき等メッセージ配信と効率
The RSVP Path message especially performs a number of functions. Supporting idempotent message delivery somehow contradicts with security association establishment, efficient message delivery, and message size. For example, a "real" idempotent signaling message would contain enough information to perform security processing without depending on a previously executed message exchange. Adding a Kerberos ticket with every signaling message is, however, inefficient. Using public-key-based mechanisms is even more inefficient when included in every signaling message. With public-key-based protection for idempotent messages, there is the additional risk of introducing denial-of-service attacks.
RSVP Pathメッセージは、特に、多数の機能を実行します。何とか冪等メッセージの配信をサポートするセキュリティ・アソシエーションの確立、効率的なメッセージ配信、およびメッセージサイズと矛盾します。例えば、「真の」冪等のシグナリングメッセージは、以前に実行されたメッセージ交換に依存せずにセキュリティ処理を実行するための十分な情報を含むであろう。すべてのシグナリングメッセージでKerberosチケットを追加すると、しかし、非効率的です。すべてのシグナリングメッセージに含まれる公開鍵ベースのメカニズムを使用することも、より非効率的です。冪等メッセージのための公開鍵ベースの保護を使用すると、サービス拒否攻撃を導入する追加的なリスクがあります。
o RSVP Path message functionality and next-hop discovery
O RSVP Pathメッセージ機能およびネクストホップ発見
To protect an RSVP signaling message (and an RSVP Path message in particular) it is necessary to know the identity of the next RSVP-aware node (and some other parameters). Without a mechanism for next-hop discovery, an RSVP Path message is also responsible for this task. Without knowing the identity of the next hop, the Kerberos principal name is also unknown. The so-called Kerberos user-to-user authentication mechanism, which would allow the receiver to trigger the process of establishing Kerberos authentication, is not supported. This issue will again be discussed in relationship with the last-hop problem.
RSVPシグナリングメッセージ（特に、RSVP Pathメッセージ）を保護するためには、次のRSVPアウェアノードの識別（およびいくつかの他のパラメータ）を知る必要があります。ネクストホップ発見のためのメカニズムがなければ、RSVP Pathメッセージも、この作業を担当しています。次のホップのアイデンティティを知らずに、Kerberosプリンシパル名も不明です。受信機は、Kerberos認証を確立するプロセスをトリガすることを可能にするいわゆるケルベロスユーザ対ユーザ認証メカニズムは、サポートされていません。この問題は、再び最終ホップ問題との関係で議論されます。
It is fair to assume that an RSVP-supporting node might not have security associations with all immediately neighboring RSVP nodes. Especially for inter-domain signaling, IntServ over DiffServ, or some new applications such as firewall signaling, the next RSVP-aware node might not be known in advance. The number of next RSVP nodes might be considerably large if they are separated by a large number of non-RSVP aware nodes. Hence, a node transmitting an RSVP Path message might experience difficulties in properly protecting the message if it serves as a mechanism to detect both the next RSVP node (i.e., Router Alert Option added to the signaling message and addressed to the destination address) and to detect route changes. It is fair to note that, in the intra- domain case with a dense distribution of RSVP nodes, protection might be possible with manual configuration.
RSVP-サポートするノードはすべて、すぐ隣のRSVPノードとのセキュリティアソシエーションを持っていない可能性がありますと仮定することが公正です。特に、ドメイン間のシグナリング、DiffServのオーバーイントサーブ、または、ファイアウォールのシグナル伝達など、いくつかの新しいアプリケーションでは、次のRSVP対応ノードは、事前に知られていない可能性があります。彼らは非RSVP意識し、多数のノードで分離されている場合は、次のRSVPノードの数がかなり大きくなる可能性があります。したがって、それは次のRSVPノードの両方を検出するための機構としての場合は、RSVP Pathメッセージを送信するノードが適切にメッセージを保護する上で問題が発生する可能性がある（すなわち、ルータ警告オプションがシグナリングメッセージに追加され、宛先アドレス宛て）とのルート変更を検出します。 RSVPノードの密な分布とイントラドメインケースには、保護が手動設定で可能であるかもしれない、ということに注意することは公平です。
Nothing prevents an adversary from continuously flooding an RSVP node with bogus PathErr messages, although it might be possible to protect the PathErr message with an existing, available security association. A legitimate RSVP node would believe that a change in the path took place. Hence, this node might try to select a different security association or try to create one with the indicated node. If an adversary is located somewhere along the path, and either authentication or authorization is not performed with the necessary strength and accuracy, then it might also be possible to act as a man-in-the-middle. One method of reducing susceptibility to this attack is as follows: when a PathErr message is received from a node with which no security association exists, attempt to establish a security association and then repeat the action that led to the PathErr message.
既存の、利用可能なセキュリティ協会とのPathErrメッセージを保護することができるかもしれませんが、何も、継続的に偽のPathErrメッセージをRSVPノードをフラッディングから敵を防ぎません。正当なRSVPノードは、パスの変更が行われたと信じています。したがって、このノードは、異なるセキュリティアソシエーションを選択するか、示されたノードを持つものを作成しようとしてみてください。敵がパスに沿ってどこかに配置され、認証または許可のいずれかが必要な強度と精度で行われていない場合、またのman-in-the-middleとして機能することは可能かもしれません。たPathErrメッセージがないセキュリティアソシエーションが存在しないとノードから受信した場合、セキュリティアソシエーションを確立した後のPathErrメッセージにつながった行動を繰り返すことを試みる：この攻撃に対する感受性を低減する1つの方法は、以下の通りです。
This section tries to address practical difficulties when authentication and key establishment are accomplished with a two-party protocol that shows some asymmetry in message processing. Kerberos is such a protocol and also the only supported protocol that provides dynamic session key establishment for RSVP. For first-hop communication, authentication is typically done between a user and some router (for example the access router). Especially in a mobile environment, it is not feasible to authenticate end hosts based on their IP or MAC address. To illustrate this problem, the typical processing steps for Kerberos are shown for first-hop communication:
このセクションでは、認証及び鍵確立は、メッセージ処理中にいくつかの非対称性を示す二者のプロトコルを用いて達成されたときに実用的な問題に対処しようとします。 Kerberosは、このようなプロトコルともRSVPの動的セッション鍵確立を提供する唯一のサポートされているプロトコルです。最初のホップ通信のために、認証は通常、ユーザと、いくつかのルータ（例えばアクセスルータ）との間で行われます。特にモバイル環境では、彼らのIPまたはMACアドレスに基づいて、エンドホストを認証することは不可能です。この問題を示すために、ケルベロスのための典型的な処理工程は、第1ホップ通信のために示されています。
(1) The end host A learns the identity (i.e., Kerberos principal name) of some entity B. This entity B is either the next RSVP node, a PDP, or the next policy-aware RSVP node.
（1）エンドホストAは、いくつかのエンティティBの識別（すなわち、Kerberosプリンシパル名）を学習し、このエンティティは、Bは次のRSVPノード、PDP、又は次ポリシー認識RSVPノードのいずれかです。
(2) Entity A then requests a ticket granting ticket for the network domain. This assumes that the identity of the network domain is known.
（2）エンティティAは、ネットワークドメインのチケット許可チケットを要求します。これは、ネットワークドメインの身元が知られていることを前提としています。
(3) Entity A then requests a service ticket for entity B, whose name was learned in step (1).
（3）エンティティAは、名前のステップ（1）で学習されたエンティティB、のためのサービスチケットを要求します。
(4) Entity A includes the service ticket with the RSVP signaling message (inside the policy object). The Kerberos session key is used to protect the integrity of the entire RSVP signaling message.
（4）エンティティAは、（ポリシーオブジェクト内の）RSVPシグナリングメッセージとサービスチケットを含みます。ケルベロスセッションキーは、全体のRSVPシグナリングメッセージの完全性を保護するために使用されます。
For last-hop communication, this processing theoretically has to be reversed: entity A is then a node in the network (for example, the access router) and entity B is the other end host (under the assumption that RSVP signaling is accomplished between two end hosts and not between an end host and an application server). However, the access router in step (1) might not be able to learn the user's principal name because this information might not be available. Entity A could reverse the process by triggering an IAKERB exchange. This would cause entity B to request a service ticket for A as described above. However, IAKERB is not supported in RSVP.
ラストホップ通信のために、この処理は、理論的に反転されなければならない：エンティティAは、次いで、（例えば、アクセス・ルータ）は、ネットワーク内のノードであり、エンティティBは、（RSVPシグナリングが両者の間に達成されるという仮定の下で他のエンドホストでありますホストではなく、エンドホストとアプリケーションサーバ間のエンド）。しかし、ステップにおけるアクセスルータは、（1）この情報が利用できない場合がありますので、ユーザーのプリンシパル名を知ることができない場合があります。エンティティAはIAKERB交換をトリガすることによって、プロセスを逆転できます。これは、前述したように、エンティティBがAのためのサービスチケットを要求する原因となります。しかし、IAKERBはRSVPではサポートされていません。
QoS signaling requires flow information to be established at routers along a path. This flow identifier installed at each device tells the router which data packets should receive QoS treatment. RSVP typically establishes a flow identifier based on the 5-tuple (source IP address, destination IP address, transport protocol type, source port, and destination port). If this 5-tuple information is not available, then other identifiers have to be used. ESP-encrypted data traffic is such an example where the transport protocol and the port numbers are not accessible. Hence, the IPsec SPI is used as a substitute for them. [12] considers these IPsec implications for RSVP and is based on three assumptions:
QoSのシグナリングは、経路に沿ってルータで確立されるフロー情報を必要とします。各デバイスに設置このフロー識別子は、データパケットがQoS処理を受信するルータに伝えます。 RSVPは、典型的には、5タプル（送信元IPアドレス、宛先IPアドレス、トランスポートプロトコルタイプ、送信元ポート、および宛先ポート）に基づいて、フロー識別子を確立します。この5タプル情報が利用できない場合は、他の識別子を使用しなければなりません。 ESP暗号化データトラフィックは、トランスポートプロトコルとポート番号にアクセスできないような例です。したがって、IPsecのSPIは、それらの代替として使用されています。 [12] RSVPのためにこれらのIPsecの影響を考慮し、3つの仮定に基づいています。
(1) An end host that initiates the RSVP signaling message exchange has to be able to retrieve the SPI for a given flow. This requires some interaction with the IPsec security association database (SAD) and security policy database (SPD) [3]. An application usually does not know the SPI of the protected flow and cannot provide the desired values. It can provide the signaling protocol daemon with flow identifiers. The signaling daemon would then need to query the SAD by providing the flow identifiers as input parameters and receiving the SPI as an output parameter.
（1）RSVPシグナリングメッセージの交換を開始するエンドホストは、指定されたフローのためのSPIを取得することができなければなりません。これは、IPsecのセキュリティアソシエーションデータベースとの何らかの相互作用を必要とする（SAD）とセキュリティ・ポリシー・データベース（SPD）[3]。アプリケーションは通常、保護された流れのSPIを知らないと所望の値を提供することはできません。これは、フロー識別子とシグナリングプロトコルデーモンを提供することができます。シグナリング・デーモンは、入力パラメータとしてフロー識別子を提供し、出力パラメータとしてSPIを受信してSADを照会する必要があります。
(2) [12] assumes end-to-end IPsec protection of the data traffic. If IPsec is applied in a nested fashion, then parts of the path do not experience QoS treatment. This can be treated as a problem of tunneling that is initiated by the end host. The following figure better illustrates the problem in the case of enforcing secure network access:
（2）[12]は、データトラフィックのエンドツーエンドのIPsec保護を想定しています。 IPsecは、ネストされた方式で適用されている場合は、パスの部分は、QoS処理は発生しません。これは、エンドホストによって開始されたトンネルの問題として扱うことができます。より良い次の図は、セキュアなネットワークアクセスを施行した場合の問題を示しています。
+------+ +---------------+ +--------+ +-----+
| Host | | Security | | Router | | Host|
| A | | Gateway (SGW) | | Rx | | B |
+--+---+ +-------+-------+ +----+---+ +--+--+
| | | |
|IPsec-Data( | | |
| OuterSrc=A, | | |
| OuterDst=SGW, | | |
| SPI=SPI1, | | |
| InnerSrc=A, | | |
| InnerDst=B, | | |
| Protocol=X, |IPsec-Data( | |
| SrcPort=Y, | SrcIP=A, | |
| DstPort=Z) | DstIP=B, | |
|=====================>| Protocol=X, |IPsec-Data( |
| | SrcPort=Y, | SrcIP=A, |
| --IPsec protected-> | DstPort=Z) | DstIP=B, |
| data traffic |------------------>| Protocol=X, |
| | | SrcPort=Y, |
| | | DstPort=Z) |
| | |---------------->|
| | | |
| | --Unprotected data traffic---> |
| | | |
Figure 7: RSVP and IPsec protected data traffic.
図7：RSVPおよびIPsec保護されたデータトラフィック。
Host A, transmitting data traffic, would either indicate a 3- tuple <A, SGW, SPI1> or a 5-tuple <A, B, X, Y, Z>. In any case, it is not possible to make a QoS reservation for the entire path. Two similar examples are remote access using a VPN and protection of data traffic between a home agent (or a security gateway in the home network) and a mobile node. The same problem occurs with a nested application of IPsec (for example, IPsec between A and SGW and between A and B).
Aホスト、データトラフィックを送信する、のいずれか3-タプル<A、SGW、SPI1>または5タプル<A、B、X、Y、Z>を示すであろう。いずれにせよ、パス全体のQoS予約をすることはできません。二つの同様の例は、ホームエージェント（又はホームネットワーク内のセキュリティゲートウェイ）とモバイルノードとの間のVPNおよびデータトラフィックの保護を使用してリモートアクセスされています。同じ問題は、IPSecのネストされたアプリケーションで発生する（例えば、IPsecのA及びSGW間及びAとBの間）。
One possible solution to this problem is to change the flow identifier along the path to capture the new flow identifier after an IPsec endpoint.
この問題に対する1つの可能な解決策は、IPsecエンドポイントの後に、新たなフロー識別子をキャプチャするために、パスに沿ってフロー識別子を変更することです。
IPsec tunnels that neither start nor terminate at one of the signaling end points (for example between two networks) should be addressed differently by recursively applying an RSVP signaling exchange for the IPsec tunnel. RSVP signaling within tunnels is addressed in [13].
（2つのネットワーク間など）のシグナリングエンドポイントの一つで終端も開始もIPsecトンネルは、再帰的にIPsecトンネルのためのRSVPシグナリング交換を適用することによって、異なるアドレス指定されるべきです。トンネル内のRSVPシグナリングが[13]でアドレス指定されます。
(3) It is assumed that SPIs do not change during the lifetime of the established QoS reservation. If a new IPsec SA is created, then
（3）SPIのは、設定されたQoS予約の有効期間中に変化しないと仮定されます。新しいIPsecのSAが作成されている場合は、
a new SPI is allocated for the security association. To reflect
this change, either a new reservation has to be established or
the flow identifier of the existing reservation has to be
updated. Because IPsec SAs usually have a longer lifetime, this
does not seem to be a major issue. IPsec protection of SCTP data
traffic might more often require an IPsec SA (and SPI) change to
reflect added and removed IP addresses from an SCTP association.
End-to-end security for RSVP has not been discussed throughout the document. In this context, end-to-end security refers to credentials transmitted between the two end hosts using RSVP. It is obvious that care must be taken to ensure that routers along the path are able to process and modify the signaling messages according to prescribed processing procedures. However, some objects or mechanisms could be used for end-to-end protection. The main question, however, is the benefit of such end-to-end security. First, there is the question of how to establish the required security association. Between two arbitrary hosts on the Internet, this might turn out to be quite difficult. Second, the usefulness of end-to-end security depends on the architecture in which RSVP is deployed. If RSVP is used only to signal QoS information into the network, and other protocols have to be executed beforehand to negotiate the parameters and to decide which entity is charged for the QoS reservation, then no end-to-end security is likely to be required. Introducing end-to-end security to RSVP would then cause problems with extensions like RSVP proxy [37], Localized RSVP [38], and others that terminate RSVP signaling somewhere along the path without reaching the destination end host. Such a behavior could then be interpreted as a man-in-the-middle attack.
RSVPのためのエンドツーエンドのセキュリティは、文書を通して議論されていません。この文脈では、エンドツーエンドのセキュリティは、RSVPを使用して、2台のエンドホストとの間で送信資格情報を指します。ケア経路に沿ったルータは、所定の処理手順に従って処理し、シグナリングメッセージを修正することが可能であることを保証するために注意しなければならないことは明らかです。しかし、いくつかのオブジェクトまたは機構は、エンドツーエンドの保護のために使用することができます。主な問題は、しかし、そのようなエンドツーエンドのセキュリティの利点です。まず、必要なセキュリティアソシエーションを確立する方法についての質問があります。インターネット上の任意の二つのホスト間で、これは非常に困難であることが判明するかもしれません。第二に、エンドツーエンドのセキュリティの有用性は、RSVPが展開されているアーキテクチャに依存します。 RSVPは、ネットワークにQoS情報を通知するためにのみ使用され、他のプロトコルパラメータをネゴシエートし、QoS予約のために充電されるエンティティを決定するように事前に実行されなければならない場合は、何のエンドツーエンドのセキュリティを必要とする可能性がありません。 RSVPへのエンドツーエンドのセキュリティを導入し、次いでRSVPプロキシ[37]、ローカライズされたRSVP [38]、および宛先エンドホストに到達することなく経路に沿ってどこかにRSVPシグナリングを終了などのような拡張機能の問題を引き起こします。このような行動は、man-in-the-middle攻撃と解釈できます。
It is assumed throughout that RSVP signaling messages can also be protected by IPsec [3] in a hop-by-hop fashion between two adjacent RSVP nodes. RSVP, however, uses special processing of signaling messages, which complicates IPsec protection. As explained in this section, IPsec should only be used for protection of RSVP signaling messages in a point-to-point communication environment (i.e., an RSVP message can only reach one RSVP router and not possibly more than one). This restriction is caused by the combination of signaling message delivery and discovery into a single message. Furthermore, end-to-end addressing complicates IPsec handling considerably. This section describes at least some of these complications.
それは、2つの隣接するRSVPノード間のホップバイホップ方式でのIPsec [3]によっても保護することができるシグナリングメッセージをそのRSVPを通して想定されます。 RSVPは、しかし、IPsec保護を複雑にシグナリングメッセージの特殊な処理を、使用しています。このセクションで説明したように、IPsecは唯一のポイント・ツー・ポイント通信環境でRSVPシグナリングメッセージを保護するために使用されるべきである（すなわち、RSVPメッセージは、唯一のRSVPルータとしない可能性が1つ以下に達することができます）。この制限は、単一のメッセージにメッセージ配信および発見シグナリングの組合せによって引き起こされます。さらに、エンド・ツー・エンドのアドレッシング複雑にIPsecはかなり扱い。このセクションでは、これらの合併症の少なくともいくつかを説明します。
RSVP messages are transmitted as raw IP packets with protocol number 46. It might be possible to encapsulate them in UDP as described in Appendix C of [6]. Some RSVP messages (Path, PathTear, and ResvConf) must have the Router Alert IP Option set in the IP header. These messages are addressed to the (unicast or multicast) destination address and not to the next RSVP node along the path. Hence, an IPsec traffic selector can only use these fields for IPsec SA selection. If there is only a single path (and possibly all traffic along it is protected) then there is no problem for IPsec protection of signaling messages. This type of protection is not common and might only be used to secure network access between an end host and its first-hop router. Because the described RSVP messages are addressed to the destination address instead of the next RSVP node, it is not possible to use IPsec ESP [17] or AH [16] in transport mode--only IPsec in tunnel mode is possible.
RSVPメッセージは、付録Cに記載されているようにUDPでそれらをカプセル化することが可能であるかもしれないプロトコル番号46と生のIPパケットとして送信される[6]。いくつかのRSVPメッセージ（パス、PathTear、およびResvConf）は、IPヘッダに設定ルータアラートIPオプションを持っている必要があります。これらのメッセージは、（ユニキャストまたはマルチキャスト）宛先アドレスとしないパスに沿って次のRSVPノードにアドレス指定されます。したがって、IPsecトラフィックセレクタは、IPsec SAの選択のためにこれらのフィールドを使用することができます。単一パスのみ（そしておそらく、それに沿ってすべてのトラフィックが保護されています）がある場合は、シグナリングメッセージのIPsec保護のためには問題ありません。このタイプの保護は一般的ではありませんとだけエンドホストとその最初のホップルータ間のネットワークアクセスを保護するために使用される可能性があります。説明RSVPメッセージは代わりに、次のRSVPノードの宛先アドレスにアドレス指定されるので、それはトランスポート・モードのIPsec ESP [17]またはAH [16]を使用することはできません - のみのIPsecトンネルモードにすることが可能です。
If an RSVP message can taket more than one possible path, then the IPsec engine will experience difficulties protecting the message. Even if the RSVP daemon installs a traffic selector with the destination IP address, still, no distinguishing element allows selection of the correct security association for one of the possible RSVP nodes along the path. Even if it possible to apply IPsec protection (in tunnel mode) for RSVP signaling messages by incorporating some additional information, there is still the possibility that the tunneled messages do not recognize a path change in a non-RSVP router. In this case the signaling messages would simply follow a different path than the data.
RSVPメッセージは複数の可能なパスをTAKETことができた場合は、IPsecのエンジンは、メッセージを保護する難しさを経験します。 RSVPデーモンは宛先IPアドレスを持つトラフィックセレクタをインストールした場合でも、依然として、全く区別要素が経路に沿って可能なRSVPノードのいずれかの適切なセキュリティアソシエーションを選択することができません。でも、いくつかの追加情報を組み込むことによって、RSVPシグナリングメッセージのために（トンネルモードで）IPsec保護を適用することが可能な場合は、トンネリングされたメッセージが非RSVPルータにパスの変更を認識しない可能性がまだあります。この場合、シグナリングメッセージは、単にデータとは別の道をたどるだろう。
RSVP messages like RESV can be protected by IPsec, because they contain enough information to create IPsec traffic selectors that allow differentiation between various next RSVP nodes. The traffic selector would then contain the protocol number and the source and destination address pair of the two communicating RSVP nodes.
彼らは様々な次のRSVPノード間の区別を可能IPsecトラフィックセレクタを作成するのに十分な情報が含まれているためRESVのようなRSVPメッセージは、IPSecで保護することができます。トラフィックセレクタは、プロトコル番号、2つの通信RSVPノードの送信元および宛先アドレスペアを含むであろう。
One benefit of using IPsec is the availability of key management using either IKE [39], KINK [40] or IKEv2 [41].
IPsecを使用することの1つの利点は、IKE [39]、KINK [40]またはIKEv2の[41]のいずれかを使用して鍵管理の利用可能性です。
[34] describes two trust models (NJ Turnpike and NJ Parkway) and two authorization models (per-session and per-channel financial settlement). The NJ Turnpike model gives a justification for hop-by-hop security protection. RSVP focuses on the NJ Turnpike model, although the different trust models are not described in detail. RSVP supports the NJ Parkway model and per-channel financial settlement only to a certain extent. Authentication of the user (or end host) can be provided with the user identity representation mechanism, but authentication might, in many cases, be insufficient for authorization. The communication procedures defined for policy
[34]（セッションごとのチャンネルごとの金融決済）2つの信頼モデル（NJターンパイクとNJパークウェイ）と2つの認証モデルについて簡単に説明します。 NJターンパイクモデルは、ホップバイホップのセキュリティ保護のための正当化を提供します。異なる信頼モデルが詳細に記載されていないが、RSVPは、NJターンパイクモデルに焦点を当てています。 RSVPは、ある程度までしかNJパークウェイモデルとチャンネルごとの決算をサポートしています。ユーザー（またはエンドホスト）の認証は、ユーザーのアイデンティティの表現機構を備えることができますが、認証は、多くの場合、認証には不十分かもしれません。ポリシーに定義された通信手順
objects [42] can be improved to support the more efficient per-channel financial settlement model by avoiding policy handling between inter-domain networks at a signaling message granularity. Additional information about expected behavior of policy handling in RSVP can also be obtained from [43].
オブジェクト[42]は、シグナリングメッセージの単位でドメイン間のネットワーク間のポリシーの取り扱いを避けることによって、より効率的なチャネルごとの金融決済モデルをサポートするように改善することができます。 RSVPの取り扱いポリシーの予想される動作についての追加情報は、[43]から得ることができます。
[35] and [36] provide additional information on authorization. No good and agreed mechanism for dealing with authorization of QoS reservations in roaming environments is provided. Price distribution mechanisms are only described in papers and never made their way through standardization. RSVP focuses on receiver-initiated reservations with authorization for the QoS reservation by the data receiver, which introduces a fair amount of complexity for mobility handling as described, for example, in [36].
[35]及び[36]認可に関する追加情報を提供します。ローミング環境でのQoS予約の承認を扱うには良いと合意されたメカニズムが提供されていません。価格配布メカニズムはのみの論文に記載されており、標準化を介して自分の道を作ったことはありません。 RSVPは、[36]において、例えば、記載されているようにモビリティ処理のための複雑さのかなりの量を導入し、データ受信機によってQoS予約のために許可して受信器で開始予約に焦点を当てています。
RSVP was the first QoS signaling protocol that provided some security protection. Whether RSVP provides appropriate security protection heavily depends on the environment where it is deployed. RSVP as specified today should be viewed as a building block that has to be adapted to a given architecture.
RSVPは、いくつかのセキュリティ保護を提供するシグナリングプロトコル最初のQoSでした。 RSVPは、適切なセキュリティ保護を提供するかどうかを頻繁にそれが展開されている環境に依存します。今日指定されたRSVPは、与えられたアーキテクチャに適合させなければならないビルディングブロックとして表示する必要があります。
This document aims to provide more insight into the security of RSVP. It cannot be interpreted as a pass or fail evaluation of the security provided by RSVP.
このドキュメントは、RSVPのセキュリティに多くの洞察を提供することを目的とします。これは、パスとして解釈又はRSVPによって提供されるセキュリティの評価に失敗することはできません。
Certainly this document is not a complete description of all security issues related to RSVP. Some issues that require further consideration are RSVP extensions (for example [12]), multicast issues, and other security properties like traffic analysis. Additionally, the interaction with mobility protocols (micro- and macro-mobility) demands further investigation from a security point of view.
確かにこの文書ではRSVPに関連するすべてのセキュリティ問題の完全な説明ではありません。さらなる検討を要するいくつかの問題は、RSVP（例えば[12]）の拡張機能、マルチキャストの問題、およびトラフィック分析のような他のセキュリティプロパティです。また、モビリティプロトコル（ミクロおよびマクロモビリティ）との相互作用は、セキュリティの観点から、さらなる調査を必要とします。
What can be learned from practical protocol experience and from the increased awareness regarding security is that some of the available credential types have received more acceptance than others. Kerberos is a system that is integrated into many IETF protocols today. Public-key-based authentication techniques are, however, still considered to be too heavy-weight (computationally and from a bandwidth perspective) to be used for per-flow signaling. The increased focus on denial of service attacks puts additional demands on the design of public-key-based authentication.
どのような実用的なプロトコルの経験からして、セキュリティに関する意識向上から学ぶことができると、使用可能なクレデンシャルタイプのいくつかは他のものより承認を受けているということです。 Kerberosは、今日、多くのIETFプロトコルに統合されたシステムです。公開鍵ベースの認証技術は、しかしながら、依然としてあまりにも重い（計算及び帯域幅の観点から）あたりフローシグナリングのために使用することがあると考えられます。サービス拒否攻撃の増加焦点は、公開鍵ベースの認証の設計上の追加の要求を置きます。
The following list briefly summarizes a few security or architectural issues that deserve improvement:
以下のリストは、簡単に改善に値するいくつかのセキュリティやアーキテクチャの問題を要約したものです。
o Discovery and signaling message delivery should be separated.
ディスカバリおよびシグナリングメッセージ配信oは分離されるべきです。
o For some applications and scenarios, it cannot be assumed that neighboring RSVP-aware nodes know each other. Hence, some in-path discovery mechanism should be provided.
いくつかのアプリケーションおよびシナリオについてoは、隣接RSVPアウェアノードが互いを知っていると仮定することはできません。したがって、一部において、パス発見メカニズムが提供されるべきです。
o Addressing for signaling messages should be done in a hop-by-hop fashion.
ホップバイホップ方式で行われるべきメッセージをシグナリングするためのアドレッシングO。
o Standard security protocols (IPsec, TLS, or CMS) should be used whenever possible. Authentication and key exchange should be separated from signaling message protection. In general, it is necessary to provide key management to establish security associations dynamically for signaling message protection. Relying on manually configured keys between neighboring RSVP nodes is insufficient. A separate, less frequently executed key management and security association establishment protocol is a good place to perform entity authentication, security service negotiation and selection, and agreement on mechanisms, transforms, and options.
O標準セキュリティ・プロトコル（IPsecの、TLS、またはCMS）が可能な限り使用すべきです。認証・鍵交換は、メッセージ保護シグナリングから分離されなければなりません。一般的には、メッセージ保護をシグナリングのために動的にセキュリティアソシエーションを確立するためのキー管理を提供することが必要です。隣接RSVPノード間で手動で設定キーに依存することは不十分です。別の、あまり頻繁に実行キー管理とセキュリティアソシエーション確立プロトコルは、メカニズムにエンティティ認証、セキュリティサービスのネゴシエーションと選択し、合意を実行するには良い場所で変換し、オプション。
o The use of public key cryptography in authorization tokens, identity representations, selective object protection, etc. is likely to cause fragmentation, the need to protect against denial of service attacks, and other problems.
などの認証トークン、アイデンティティの表現では、公開鍵暗号方式、選択オブジェクト保護の使用oを断片化、サービス拒否攻撃から保護する必要性、および他の問題を引き起こす可能性があります。
o Public key authentication and user identity confidentiality provided with RSVP require some improvement.
O RSVPを提供する公開鍵認証とユーザー識別情報の機密性は、いくつかの改善が必要です。
o Public-key-based user authentication only provides entity authentication. An additional security association is required to protect signaling messages.
O公開鍵ベースのユーザー認証は、唯一のエンティティ認証を提供します。追加のセキュリティアソシエーションは、シグナリングメッセージを保護する必要があります。
o Data origin authentication should not be provided by non-RSVP nodes (such as the PDP). Such a procedure could be accomplished by entity authentication during the authentication and key exchange phase.
Oデータ発信元認証は、（例えば、PDPのような）非RSVPノードによって提供されるべきではありません。そのような手順は、認証・鍵交換段階の間エンティティ認証することによって達成することができます。
o Authorization and charging should be better integrated into the base protocol.
O認可および課金は基本プロトコルへのより良い統合されるべきです。
o Selective message protection should be provided. A protected message should be recognizable from a flag in the header.
O選択メッセージ保護が提供されるべきです。保護されたメッセージは、ヘッダ内のフラグから認識可能であるべきです。
o Confidentiality protection is missing and should therefore be added to the protocol. The general principle is that protocol designers can seldom foresee all of the environments in which protocols will be run, so they should allow users to select from a full range of security services, as the needs of different user communities vary.
O機密保護が不足しているため、プロトコルに追加する必要があります。一般的な原則は、プロトコル設計者はめったに異なるユーザーコミュニティの必要性は異なるとして、プロトコルが実行されるので、彼らは、ユーザーがセキュリティサービスの全範囲から選択できるようにする必要がありますする環境のすべてを予見することはできないということです。
o Parameter and mechanism negotiation should be provided.
Oパラメータおよびメカニズム交渉が提供されるべきです。
This document discusses security properties of RSVP and, as such, it is concerned entirely with security.
この文書は、それが完全にセキュリティに関係する、などの、RSVPのセキュリティプロパティを説明します。
We would like to thank Jorge Cuellar, Robert Hancock, Xiaoming Fu, Guenther Schaefer, Marc De Vuyst, Bob Grillo, and Jukka Manner for their comments. Additionally, Hannes would like to thank Robert and Jorge for their time discussing various issues.
私たちは、彼らのコメントのためにホルヘクエリャル、ロバート・ハンコック、暁明フー、ギュンター・シェーファー、マルク・デ・Vuyst、ボブ・グリロ、およびユッカのマナーに感謝したいと思います。さらに、ハンネスは様々な問題を議論する彼らの時間のためにロバートとホルヘに感謝したいと思います。
Finally, we would like to thank Allison Mankin and John Loughney for their guidance and input.
最後に、我々は彼らの指導や入力のためのアリソンマンキンとジョンLoughneyに感謝したいと思います。
[1] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[1]ベーカー、F.、リンデル、B.、およびM. Talwar、 "RSVP暗号化認証"、RFC 2747、2000年1月。
[2] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[2]ヘルツォーク、S.、 "ポリシー制御のためのRSVP拡張機能"、RFC 2750、2000年1月。
[3] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[3]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[4] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[4] Krawczyk、H.、ベラー、M.、およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。
[5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[5]のRivest、R.、 "MD5メッセージダイジェストアルゴリズム"、RFC 1321、1992年4月。
[6] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[6]ブレーデン、B.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1機能仕様"、RFC 2205、1997年9月。
[7] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., Herzog, S., and R. Hess, "Identity Representation for RSVP", RFC 3182, October 2001.
[7] Yadavが、S.、Yavatkar、R.、Pabbati、R.、フォード、P.、ムーア、T.、ヘルツォーク、S.、およびR.ヘス、 "RSVPのID表現"、RFC 3182、2001年10月。
[8] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993. Obsoleted by RFC 4120.
[8]コールズ、J.及びC.ノイマン、 "ケルベロスネットワーク認証サービス（V5）"、RFC 1510、1993年9月は、RFC 4120によって時代遅れ。
[9] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[9]カルフーン、P.、Loughney、J.、ガットマン、E.、ゾルン、G.、およびJ. Arkko、 "直径ベースプロトコル"、RFC 3588、2003年9月。
[10] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R., and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000.
[10]ダラム、D.、ボイル、J.、コーエン、R.、ヘルツォーク、S.、ラジャン、R.、およびA. Sastry、 "COPS（共通オープンポリシーサービス）プロトコル"、RFC 2748、2000年1月。
[11] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R., and A. Sastry, "COPS usage for RSVP", RFC 2749, January 2000.
[11]ヘルツォーク、S.、ボイル、J.、コーエン、R.、ダラム、D.、ラジャン、R.、およびA. Sastry、RFC 2749、2000年1月 "RSVPの使用は、COPS"。
[12] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997.
[12]バーガー、L.とT.オマリー、 "IPSECデータフローのためのRSVP拡張機能"、RFC 2207、1997年9月。
[13] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000.
[13] Terzis、A.、Krawczyk、J.、Wroclawski、J.、およびL.チャン、 "RSVP操作オーバーIPトンネル"、RFC 2746、2000年1月。
[14] Hess, R. and S. Herzog, "RSVP Extensions for Policy Control", Work in Progress, June 2001.
[14]ヘス、R.とS.ヘルツォーク、 "ポリシー制御のためのRSVP拡張機能"、進歩、2001年6月での作業。
[15] "Secure Hash Standard, NIST, FIPS PUB 180-1", Federal Information Processing Society, April 1995.
[15] "セキュアハッシュ標準、NIST、FIPS PUB 180-1の"、連邦情報処理学会、1995年4月。
[16] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[16]ケント、S.とR.アトキンソン、 "IP認証ヘッダー"、RFC 2402、1998年11月。
[17] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[17]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、1998年11月。
[18] Fowler, D., "Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types", RFC 2495, January 1999.
[18]ファウラー、D.、RFC 2495、1999年1月 "DS1、E1、DS2およびE2インターフェイスのタイプのための管理オブジェクトの定義"。
[19] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
[19]カラス、J.、Donnerhacke、L.、フィニー、H.、およびR.セイヤー、 "OpenPGPのメッセージフォーマット"、RFC 2440、1998年11月。
[20] Hornstein, K. and J. Altman, "Distributing Kerberos KDC and Realm Information with DNS", Work in Progress, July 2002.
[20] Hornstein、K.とJ.アルトマン、 "DNSと配布のKerberos KDCとレルム情報"、進歩、2002年7月の作業。
[21] Dobbertin, H., Bosselaers, A., and B. Preneel, "RIPEMD-160: A strengthened version of RIPEMD in Fast Software Encryption", LNCS vol. 1039, pp. 71-82, 1996.
[21] Dobbertin、H.、Bosselaers、A.およびB. Preneel、 "RIPEMD-160：高速ソフトウェア暗号化にRIPEMDの強化バージョン"、LNCS体積。 1039年、頁71-82、1996。
[22] Dobbertin, H., "The Status of MD5 After a Recent Attack", RSA Laboratories CryptoBytes, vol. 2, no. 2, 1996.
[22] Dobbertin、H.、 "最近の攻撃の後MD5の状況"、RSA研究所CryptoBytes、巻。 2、ありません。 2、1996。
[23] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[23] Aboba、B.、ブルンク、L.、Vollbrecht、J.、カールソン、J.、およびH. Levkowetz、 "拡張認証プロトコル（EAP）"、RFC 3748、2004年6月。
[24] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）においてリモート認証ダイヤルイン" [24] Rigney、C.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン。
[25] "Microsoft Authorization Data Specification v. 1.0 for Microsoft Windows 2000 Operating Systems", April 2000.
[25]の "Microsoft Windows 2000オペレーティングシステム用のMicrosoft認証データ仕様V 1.0"、2000年4月。
[26] Cable Television Laboratories, Inc., "PacketCable Security Specification, PKT-SP-SEC-I01-991201", website: http://www.PacketCable.com/, June 2003.
[26]ケーブルテレビラボラトリーズ社、 "PacketCableのセキュリティ仕様、PKT-SP-SEC-I01-991201"、ウェブサイト：http://www.PacketCable.com/、2003年6月。
[27] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[27]マイヤーズ、M.、Ankney、R.、Malpani、A.、Galperin、S.、およびC.アダムス、 "X.509のインターネット公開鍵暗号基盤のオンライン証明書状態プロトコル - OCSP"、RFC 2560、1999年6月。
[28] Malpani, A., Housley, R., and T. Freeman, "Simple Certificate Validation Protocol (SCVP)", Work in Progress, October 2005.
[28] Malpani、A.、Housley氏、R.、およびT.フリーマン、 "簡単な証明書の検証プロトコル（SCVP）"、進歩、2005年10月に作業。
[29] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369, August 2002.
[29] Housley氏、R.、 "暗号メッセージ構文（CMS）"、RFC 3369、2002年8月。
[30] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, March 1998.
[30] Kaliski、B.、 "PKCS＃7：暗号メッセージ構文バージョン1.5"、RFC 2315、1998年3月。
[31] "Specifications and standard documents", website: http://www.PacketCable.com/, March 2002.
[31] "仕様と標準文書"、ウェブサイト：http://www.PacketCable.com/、2002年3月。
[32] Davis, D. and D. Geer, "Kerberos With Clocks Adrift: History, Protocols and Implementation", USENIX Computing Systems, vol 9 no. 1, Winter 1996.
[32]デイビス、D.およびD.ギヤー、「ケルベロスとクロック漂流：歴史、プロトコル及び実装」、USENIXコンピューティングシステム、巻9ありません。 1、冬1996。
[33] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, February 2005.
[33]レイバーン、K.、 "暗号化とケルベロス5チェックサムの仕様"、RFC 3961、2005年2月。
[34] Tschofenig, H., Buechli, M., Van den Bosch, S., and H. Schulzrinne, "NSIS Authentication, Authorization and Accounting Issues", Work in Progress, March 2003.
[34] Tschofenig、H.、Buechli、M.、ヴァン・デン・ボッシュ、S.、およびH. Schulzrinneと、 "NSIS認証、認可および会計問題"、進歩、2003年3月での作業。
[35] Tschofenig, H., Buechli, M., Van den Bosch, S., Schulzrinne, H., and T. Chen, "QoS NSLP Authorization Issues", Work in Progress, June 2003.
[35] Tschofenig、H.、Buechli、M.、ヴァン・デン・ボッシュ、S.、Schulzrinneと、H.、およびT.チェン、 "QoSのNSLP認可の問題"、進歩、2003年6月に作業。
[36] Thomas, M., "Analysis of Mobile IP and RSVP Interactions", Work in Progress, October 2002.
、進歩、2002年10月に作業[36]トーマス、M.、 "モバイルIPおよびRSVP相互作用の分析"。
[37] Gai, S., Gaitonde, S., Elfassy, N., and Y. Bernet, "RSVP Proxy", Work in Progress, March 2002.
[37]ガイ、S.、Gaitonde、S.、Elfassy、N.、およびY. Bernet、 "プロキシをRSVP"、進歩、2002年3月での作業。
[38] Manner, J., Suihko, T., Kojo, M., Liljeberg, M., and K. Raatikainen, "Localized RSVP", Work in Progress, September 2004.
[38]ようにして、J.、Suihko、T.、古城、M.、Liljeberg、M.、およびK. Raatikainen、 "ローカライズRSVP"、進歩、2004年9月ワーク。
[39] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[39]ハーキンズ、D.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[40] Thomas, M., "Kerberized Internet Negotiation of Keys (KINK)", Work in Progress, October 2005.
[40]トーマス、M.、 "キーのKerberos対応インターネット交渉（KINK）"、進歩、2005年10月に作業。
[41] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, November 2005.
[41]カウフマン、C.、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年11月。
[42] Herzog, S., "Accounting and Access Control in RSVP", PhD Dissertation, USC, Work in Progress, November 1995.
[42]ヘルツォーク、S.、 "会計とRSVPでのアクセス制御"、博士論文、USC、進歩、1995年11月での作業。
[43] Herzog, S., "Accounting and Access Control for Multicast Distributions: Models and Mechanisms", June 1996.
[43]ヘルツォーク、S.、「マルチキャスト配布のための会計とアクセス制御：モデルとメカニズム」、1996年6月。
[44] Pato, J., "Using Pre-Authentication to Avoid Password Guessing Attacks", Open Software Foundation DCE Request for Comments, December 1992.
「パスワード推測攻撃を避けるために事前認証を使用する」[44]パト、J.、コメントのためのオープンソフトウェア財団DCE要求、1992年12月。
[45] Tung, B. and L. Zhu, "Public Key Cryptography for Initial Authentication in Kerberos", Work in Progress, November 2005.
[45]桐、B.およびL.朱、「ケルベロスにおける初期認証のための公開鍵暗号」、進歩、2005年11月に作業。
[46] Wu, T., "A Real-World Analysis of Kerberos Password Security", in Proceedings of the 1999 Internet Society Network and Distributed System Security Symposium, San Diego, February 1999.
[46] 1999インターネット協会ネットワークと分散システムセキュリティシンポジウム、サンディエゴ、1999年2月の議事録では呉、T.、「ケルベロスパスワードセキュリティの実世界の解析」、。
[47] Wu, T., Wu, F., and F. Gong, "Securing QoS: Threats to RSVP Messages and Their Countermeasures", IEEE IWQoS, pp. 62-64, 1999.
[47]呉、T.、ウー、F.、及びF.ゴング、 "QoSの確保：メッセージのRSVPへの脅威とその対策"、IEEE IWQoS、PPの62-64、1999。
[48] Talwar, V., Nahrstedt, K., and F. Gong, "Securing RSVP For Multimedia Applications", Proc ACM Multimedia 2000 (Multimedia Security Workshop), November 2000.
[48] Talwar、V.、Nahrstedt、K.、およびF.ゴング、 "マルチメディアアプリケーションのために確保RSVP"、PROC ACMマルチメディア2000（マルチメディアセキュリティワークショップ）、2000年11月。
[49] Talwar, V., Nahrstedt, K., and S. Nath, "RSVP-SQoS: A Secure RSVP Protocol", International Conf on Multimedia and Exposition, Tokyo, Japan, August 2001.
[49] Talwar、V.、Nahrstedt、K.、およびS.ナス、 "RSVP-SQoS：セキュアRSVPプロトコル"、マルチメディアおよび博覧会、東京、日本、2001年8月に国際コンファレンス。
[50] Jablon, D., "Strong Password-only Authenticated Key Exchange", ACM Computer Communication Review, 26(5), pp. 5-26, October 1996.
[50] Jablon、D.、 "強力なパスワードのみの認証鍵交換"、ACMコンピュータコミュニケーションレビュー、26（5）、頁5-26、1996年10月。
Appendix A. Dictionary Attacks and Kerberos
付録A.辞書攻撃とKerberos
Kerberos might be used with RSVP as described in this document. Because dictionary attacks are often mentioned in relationship with Kerberos, a few issues are addressed here.
この文書で説明するようにKerberosは、RSVPで使用される可能性があります。辞書攻撃は、多くの場合、ケルベロスとの関係に言及されているので、いくつかの問題が記載されています。
The initial Kerberos AS_REQ request (without pre-authentication, without various extensions, and without PKINIT) is unprotected. The response message AS_REP is encrypted with the client's long-term key. An adversary can take advantage of this fact by requesting AS_REP messages to mount an off-line dictionary attack. Pre-authentication ([44]) can be used to reduce this problem. However, pre-authentication does not entirely prevent dictionary attacks by an adversary who can still eavesdrop on Kerberos messages along the path between a mobile node and a KDC. With mandatory pre-authentication for the initial request, an adversary cannot request a Ticket Granting Ticket for an arbitrary user. On-line password guessing attacks are still possible by choosing a password (e.g., from a dictionary) and then transmitting an initial request that includes a pre-authentication data field. An unsuccessful authentication by the KDC results in an error message and thus gives the adversary a hint to restart the protocol and try a new password.
（事前認証なし、様々な拡張せず、そしてPKINITなし）初期のKerberos AS_REQ要求が保護されていません。応答メッセージAS_REPは、クライアントの長期的な鍵で暗号化されています。敵はオフライン辞書攻撃を仕掛けるためにAS_REPメッセージを要求することで、この事実を利用することができます。事前認証（[44]）は、この問題を軽減するために使用することができます。しかし、事前認証は完全にまだ移動ノードとKDCとの間の経路に沿ってケルベロスメッセージを盗聴することができます敵で辞書攻撃を防ぐことはできません。最初の要求のための必須事前認証では、敵対者は、任意のユーザーのチケット許可チケットを要求することはできません。オンラインでパスワード推測攻撃が（辞書から、例えば）パスワードを選択した後、事前認証データフィールドを含む最初の要求を送信することは可能です。 KDCによって認証失敗は、エラーメッセージになり、したがって、敵にプロトコルを再起動し、新しいパスワードをしようとするヒントを提供します。
There are, however, some proposals that prevent dictionary attacks. The use of Public Key Cryptography for initial authentication [45] (PKINIT) is one such solution. Other proposals use strong-password-based authenticated key agreement protocols to protect the user's password during the initial Kerberos exchange. [46] discusses the security of Kerberos and also discusses mechanisms to prevent dictionary attacks.
辞書攻撃を防ぐため、いくつかの提案は、しかし、があります。初期認証[45]（PKINIT）の公開鍵暗号の使用は、そのような解決策です。他の提案は、最初のKerberos交換中にユーザーのパスワードを保護するために、強力なパスワードベースの認証済み鍵合意プロトコルを使用します。 [46]ケルベロスのセキュリティについて説明し、また、辞書攻撃を防止するための機構を議論します。
Appendix B. Example of User-to-PDP Authentication
付録B.例のユーザ対PDP認証
The following Section describes an example of user-to-PDP authentication. Note that the description below is not fully covered by the RSVP specification and hence it should only be viewed as an example.
次のセクションでは、ユーザ対PDP認証の例について説明します。以下の説明は、完全RSVP仕様で覆われていない、したがって、それは単なる例として見なされるべきであることに留意されたいです。
Windows 2000, which integrates Kerberos into RSVP, uses a configuration with the user authentication to the PDP as described in [25]. The steps for authenticating the user to the PDP in an intra-realm scenario are the following:
RSVPにKerberosを統合Windows 2000は、[25]に記載のようにPDPにユーザー認証とコンフィギュレーションを使用します。イントラ領域シナリオでPDPにユーザを認証するための手順は以下の通りであります：
o Windows 2000 requires the user to contact the KDC and to request a Kerberos service ticket for the PDP account AcsService in the local realm.
O Windows 2000はKDCに連絡し、地元の分野におけるPDPアカウントAcsServiceのKerberosサービスチケットを要求するユーザーが必要です。
o This ticket is then embedded into the AUTH_DATA element and included in either the PATH or the RESV message. In the case of Microsoft's implementation, the user identity encoded as a distinguished name is encrypted with the session key provided with the Kerberos ticket. The Kerberos ticket is sent without the Kerberos authdata element that contains authorization information, as explained in [25].
Oこのチケットは次に、AUTH_DATA要素に埋め込まれ、PATHまたはRESVメッセージのいずれかに含まれています。 Microsoftの実装の場合は、識別名として符号化されたユーザーIDは、Kerberosチケットを提供したセッション鍵で暗号化されています。 [25]で説明したように、Kerberosチケットは、認証情報が含まれているケルベロスauthdata要素なしで送信されます。
o The RSVP message is then intercepted by the PEP, which forwards it to the PDP. [25] does not state which protocol is used to forward the RSVP message to the PDP.
O RSVPメッセージは、次いでPDPに転送PEPによってインターセプトされます。 [25] PDPにRSVPメッセージを転送するために使用されるプロトコルステートありません。
o The PDP that finally receives the message and decrypts the received service ticket. The ticket contains the session key used by the user's host to
最後にメッセージを受信し、受信したサービスチケットを復号化PDP O。チケットは、ユーザへのホストによって使用されるセッションキーが含まれています
* Encrypt the principal name inside the policy locator field of the AUTH_DATA object and to
* AUTH_DATAオブジェクトのポリシーロケータフィールド内とするプリンシパル名を暗号化
* Create the integrity-protected Keyed Message Digest field in the INTEGRITY object of the POLICY_DATA element. The protection described here is between the user's host and the PDP. The RSVP INTEGRITY object on the other hand is used to protect the path between the user's host and the first-hop router, because the two message parts terminate at different nodes, and different security associations must be used. The interface between the message-intercepting, first-hop router and the PDP must be protected as well.
* POLICY_DATA要素のINTEGRITYオブジェクトに整合性が保護キー付きメッセージダイジェストフィールドを作成します。ここで説明した保護は、ユーザーのホストとPDPの間です。一方、RSVPのINTEGRITYオブジェクトは、2つのメッセージ部分は異なるノードで終端しているため、ユーザのホストと第一ホップルータとの間のパスを保護するために使用され、異なるセキュリティアソシエーションを使用しなければなりません。メッセージインターセプト、最初のホップルータとPDPとの間のインターフェースは、同様に保護されなければなりません。
* The PDP does not maintain a user database, and [25] describes how the PDP may query the Active Directory (a LDAP based directory service) for user policy information.
* PDPは、ユーザーのデータベースを維持しないと、[25]はPDPがユーザーポリシー情報をActive Directory（LDAPベースのディレクトリサービス）を照会することができる方法を説明します。
Appendix C. Literature on RSVP Security
RSVPセキュリティ上の付録C.文学
Few documents address the security of RSVP signaling. This section briefly describes some important documents.
いくつかの文書は、RSVPシグナリングのセキュリティに取り組みます。このセクションでは、簡単にいくつかの重要な文書を記述しています。
Improvements to RSVP are proposed in [47] to deal with insider attacks. Insider attacks are caused by malicious RSVP routers that modify RSVP signaling messages in such a way that they cause harm to the nodes participating in the signaling message exchange.
RSVPの改善は、インサイダー攻撃に対処するために、[47]で提案されています。インサイダー攻撃は、それらがシグナリングメッセージ交換に参加しているノードへの害を引き起こすような方法でRSVPシグナリングメッセージを変更する悪意のあるRSVPルータによって引き起こされます。
As a solution, non-mutable RSVP objects are digitally signed by the sender. This digital signature is added to the RSVP PATH message. Additionally, the receiver attaches an object to the RSVP RESV message containing a "signed" history. This value allows intermediate RSVP routers (by examining the previously signed value) to detect a malicious RSVP node.
解決策として、非可変のRSVPオブジェクトは、デジタル送信者によって署名されています。このデジタル署名は、RSVP PATHメッセージに付加されます。また、受信機は、「署名済み」履歴を含むRSVP RESVメッセージにオブジェクトを添付する。この値は、悪意のあるRSVPノードを検出するために（以前に符号付きの値を調べることによって）、中間RSVPルータを可能にします。
A few issues are, however, left open in this document. Replay attacks are not covered, and it is therefore assumed that timestamp-based replay protection is used. To identify a malicious node, it is necessary that all routers along the path are able to verify the digital signature. This may require a global public key infrastructure and also client-side certificates. Furthermore, the bandwidth and computational requirements to compute, transmit, and verify digital signatures for each signaling message might place a burden on a real-world deployment.
いくつかの問題は、しかし、この文書で開いたままになっています。リプレイ攻撃はカバーされていない、そしてそれゆえ、タイムスタンプベースのリプレイ保護が使用されているものとします。悪意のあるノードを識別するためには、経路に沿った全てのルータは、デジタル署名を検証することが可能であることが必要です。これはグローバルな公開鍵基盤ともクライアント側の証明書が必要な場合があります。さらに、計算送信し、各シグナリングメッセージのためのデジタル署名を検証するために、帯域幅および計算要件は、実世界での展開に負担をかけるかもしれません。
Authorization is not considered in the document, which might have an influence on the implications of signaling message modification. Hence, the chain-of-trust relationship (or this step in a different direction) should be considered in relationship with authorization.
認証は、メッセージの変更をシグナルの意味に影響を与える可能性がある文書、では考慮されていません。したがって、チェーンの信頼関係（または異なる方向に、この工程）権限を持つ関係で考慮されるべきです。
In [48], the above-described idea of detecting malicious RSVP nodes is improved by addressing performance aspects. The proposed solution is somewhere between hop-by-hop security and the approach in [47], insofar as it separates the end-to-end path into individual networks. Furthermore, some additional RSVP messages (e.g., feedback messages) are introduced to implement a mechanism called "delayed integrity checking." In [49], the approach presented in [48] is enhanced.
[48]において、悪意のあるRSVPノードを検出する上述の考え方は、性能面をアドレス指定することによって改善されます。提案された解決策は、それが個々のネットワークへのエンドツーエンドパスを分離する限り、ホップバイホップセキュリティおよび[47]におけるアプローチの間のどこかです。さらに、いくつかの追加のRSVPメッセージが（例えば、フィードバックメッセージ）と呼ばれるメカニズムを実装するために導入されている「遅延の整合性チェックを。」 [49]では、[48]に提示アプローチが強化されています。
Authors' Addresses
著者のアドレス
Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
ハンネスTschofenigシーメンスオットー・ハーンリング6ミュンヘン、バイエルン81739ドイツ
EMail: Hannes.Tschofenig@siemens.com
メールアドレス：Hannes.Tschofenig@siemens.com
Richard Graveman RFG Security 15 Park Avenue Morristown, NJ 07960 USA
リチャードGraveman RFGセキュリティ15パークアベニューモリスタウン、NJ 07960 USA
EMail: rfg@acm.org
メールアドレス：rfg@acm.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。