[要約] RFC 4230は、RSVP（Resource Reservation Protocol）のセキュリティプロパティに関する要約です。このRFCの目的は、RSVPのセキュリティ上の脆弱性を特定し、それに対する対策を提案することです。
Network Working Group H. Tschofenig
Request for Comments: 4230 Siemens
Category: Informational R. Graveman
RFG Security
December 2005
RSVP Security Properties
RSVPセキュリティプロパティ
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).
Copyright（c）The Internet Society（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では、整合性オブジェクトを含むRSVPによって提供されるセキュリティメカニズムの概要、policy_dataオブジェクト内のID表現（すなわち、ユーザー認証）、および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のコンテキストで使用され、ラベルスイッチングパスのラベルを配布するために使用されますが、その使用はNSIで想定される使用シナリオとは異なります。したがって、このドキュメントは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]によってサポートされるセキュリティメカニズムは、組み込みの整合性オブジェクトを使用して、オプションのホップバイホップ保護に大きく依存しています。RSVPメッセージ内の整合性オブジェクトを使用したホップバイホップセキュリティは、それによってRSVPサポートネットワーク要素間の保護を指します。さらに、RSVPメッセージ内のpolicy_Data要素を理解するポリシーを認識するノードの概念があります。この要素には整合性オブジェクトも含まれているため、ポリシー認識ノード間のセキュリティを提供する追加のホップバイホップセキュリティメカニズムがあります。ポリシーに無知なノードは、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を介してルーターAによって送信され、ルーターCで受信されるシグナルメッセージがルーターAおよびBおよびルーターBおよび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つのルーターが悪意がある場合（たとえば、敵がこのルーターを制御しているため）、メッセージをarbitrarily意的に変更し、予期しない動作を引き起こし、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要素内の整合性オブジェクトを使用したユーザー認証のコンテキストで同じ用語が使用されています。残念ながら、この用語は詳細に説明されておらず、その背後にある仮定は明確に指定されていません。
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:
o キー管理：
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のサポートに関しては例外があります。Kerberosを使用して、エンティティはRSVPシグナリング保護に使用されるセッションキーを配布できます。
o RSVP INTEGRITY and POLICY_DATA INTEGRITY Objects:
o rsvp整合性とpolicy_data整合性オブジェクト：
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つの場所で整合性オブジェクトを使用します。1つ目はRSVPメッセージ自体にあり、[1]で定義されているRSVPメッセージ全体をカバーします。2番目はpolicy_dataオブジェクトに含まれ、[2]で定義されています。2つのオブジェクトを保護の範囲で区別するために、それぞれ2つの用語RSVP Integrityとpolicy_Data Integrityオブジェクトが使用されます。ただし、2つのオブジェクトのデータ構造は同じです。
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ホップとは異なる用語ホップを使用しています。互いに通信する2つの隣接する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整合性オブジェクトは、RSVPセキュリティ保護の主要なコンポーネントです。このオブジェクトは、2つのRSVP参加ルーター間、またはRSVPルーターとホスト間の信号メッセージのコンテンツの整合性とリプレイ保護を提供するために使用されます。さらに、RSVP Integrity Objectはデータ起源認証を提供します。オブジェクトの属性について簡単に説明します。
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.
握手フラグは、唯一の定義されたフラグです。通信が同期しなくなった場合にシーケンス番号を同期するために使用されます（たとえば、再起動するホストが最新のシーケンス番号を回復できるようにします）。このフラグを1つに設定すると、送信者が整合性チャレンジメッセージに喜んで応答することを示します。したがって、このフラグは、各整合性オブジェクト内に送信されるネゴシエーション能力と見なすことができます。
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.
キー識別子は、キー付きメッセージダイジェストフィールドの検証に使用されるキーを選択するため、送信者にとって一意でなければなりません。固定された48ビットの長さです。このキー識別子フィールドの生成は、主にローカルホストの決定です。[1]は、このフィールドをアドレス、送信インターフェイス、およびキー番号の組み合わせとして説明しています。キー識別子は、多くのフィールドで計算された（キー付き）ハッシュ値であり、2つのホスト間で複数のセキュリティアソシエーションが並行して使用されている場合、要件は一意であることを想定しています（たとえば、セキュリティ協会の場合のように寿命が重複している）。受信システムは、キー識別子と送信者のIPアドレスに基づいてセキュリティ協会を一意に識別します。送信者のIPアドレスは、RSVP_HOPオブジェクトが存在しない場合、RSVP_HOPオブジェクトまたはパケットのソースIPアドレスから取得できます。送信者は、発信インターフェイスを使用して、使用するセキュリティ協会を決定します。「発信インターフェイス」という用語は混乱している可能性があります。送信者は、受信者のIPアドレス（つまり、次のRSVP対応ルーターのアドレス）に基づいてセキュリティ協会を選択します。どのノードが次のRSVP対応ルーターであるかを決定するプロセスは、さらに指定されておらず、静的に構成される可能性があります。
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.
整合性オブジェクトで使用されるシーケンス番号の長さは64ビットで、開始値は任意に選択できます。[1]のセクション3に記載されているように、セキュリティ協会の寿命の間に疲労を避けるために、シーケンス番号フィールドの長さが選択されました。受信者が新しいメッセージと再生されたメッセージを区別するためには、各メッセージのシーケンス番号を単調に増加させる（Modulo 2^64）する必要があります。見られる最初のシーケンス番号（つまり、開始シーケンス番号）がどこかに保存されていると仮定します。開始シーケンス番号が任意の数字である可能性があるため、モジュロ操作が必要です。したがって、受信機は、前のパケットよりも大きいシーケンス番号（Modulo 2^64）のパケットのみを受け入れます。[1]で説明されているように、このプロセスは、ハンドシェイクと初期シーケンス番号について同意することによって開始されます。そのようなハンドシェイクが利用できない場合、初期シーケンス番号はセキュリティ協会の設立の一部でなければなりません。
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 = value受信して受け入れます。後続のメッセージが受信されると、そのシーケンス番号が厳密にラストシューとinit-seq（Modulo 2^64）の間で厳密に行われた場合、受信した値で最後の節を受け入れて更新します。init-seqとlast-seqの間にある場合、包括的、（Modulo 2^64）は、拒否し、最後の秒の値を変更しません。順番の配信は保証されていないため、上記のルールは、たとえば[3の付録Cで説明されているように、順序外配達のために最終段階の近傍に固定サイズのウィンドウを許可する方法と組み合わせる必要があります。]。
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.
キー付きメッセージダイジェストは、シグナリングメッセージの整合性保護を提供するために使用されるRSVPに組み込まれたセキュリティメカニズムです（そのシーケンス番号を含む）。キー付きメッセージダイジェストフィールドの値を計算する前に、キー付きメッセージダイジェストフィールド自体をゼロに設定し、RSVPパケット全体でキー付きハッシュを計算する必要があります。キー付きメッセージダイジェストフィールドの長さは可変ですが、4オクテットの倍数でなければなりません。HMAC-MD5を使用すると、出力値は16バイトの長さです。[1]のセクション1に記載されているように、キー付きハッシュ関数HMAC-MD5 [4]はRSVP実装に必要です。SHA-1 [15]のように、MD5 [5]以外のハッシュアルゴリズムもサポートされる場合があります。
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)
o 最後のnシーケンス番号のリスト（このキー識別子で受信）
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ファイルで十分かもしれません。異なる寿命との複数のセキュリティ関連を同時にサポートする必要がある場合、キーエンジンがより適切になります。[1]のセクション5.2にリストされているさらなるセキュリティ要件は次のとおりです。
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は、「ユーザーのアイデンティティまたはアプリケーションに基づいたポリシーベースの入場管理メカニズムを提供することが主要な要件の1つである」と述べています。ユーザーまたはアプリケーションを識別するために、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メッセージの抽象構造を示しています。RSVP Integrity Object（Outer Object）はRSVPメッセージ全体をカバーしますが、Policy_Data IntegrityオブジェクトはPolicy_Data要素内のオブジェクトのみをカバーします。
+--------------------------------------------------------+
| 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.
図1：RSVPメッセージ内のセキュリティ関連オブジェクトと要素。
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オブジェクトには、ユーザーとアプリケーションを識別するための情報とそれらのアイデンティティの資格情報が含まれています。これらのアイデンティティの主な目的は、認証と主要な管理ではなく、ポリシーに基づいたアジニングコントロールに使用することです。[7]のセクション6.1に記載されているように、RSVPメッセージには複数のpolicy_Dataオブジェクトが含まれている場合があり、それぞれが複数のauth_dataオブジェクトを含む場合があります。図1および[7]に示されているように、1つの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 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.
* unicode_dn_encryptポリシーロケーター文字列は、ユーザーまたはアプリケーション固有のポリシー情報を見つけるために使用されるX.500 Distinguished Name（DN）です。4種類のX.500 DNSを上記にリストします。最初の2つのタイプは、ASCIIとユーザーまたはアプリケーションDN IDのユニコード表現です。2つの「暗号化された」著名な名前のタイプは、Kerberosセッションキーで暗号化されているか、ユーザーのデジタル証明書の秘密鍵（つまり、デジタルで署名されています）のいずれかです。「デジタル署名と一緒に暗号化された」という用語は、誤解するのが簡単です。ユーザーIDの機密性が提供されている場合、ポリシーロケーターは受信者の公開鍵で暗号化する必要があります。この公開キーを取得する方法は、ドキュメントに記載されていません。この詳細は、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]:
現在、ユーザーに対して2つの暗号化資格情報が定義されています。KerberosV5[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 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.
最初の2つの資格情報には、プレーンテキスト文字列のみが含まれているため、暗号化ユーザー認証は提供されません。これらのプレーンテキスト文字列は、ポリシーベースの入場制御に含まれるアプリケーションを識別するために使用できます。ただし、これらのプレーンテキスト識別子は、rsvpの整合性またはpolicy_data要素の整合性オブジェクトのいずれかが存在する場合、保護される場合があることに注意してください。2つの整合性オブジェクトは、ネットワーク構造に応じて異なるエンティティで終了できることに注意してください。デジタル署名は、アプリケーション識別子の保護も提供する場合があります。保護されたアプリケーション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.
前述のように、Kerberosセッションのチケットは、認証者のないKerberos AP_REQメッセージ[8]のチケットです。通常、AP_REQメッセージは、クライアントがサーバーに認証するために使用されます。Integrityオブジェクト（Policy_Data要素など）は、Kerberos Authenticatorの機能を提供します。つまり、リプレイから保護し、ユーザーがKerberosプロトコルに続いてセッションキーを取得できることを示します。ただし、これは、整合性オブジェクトのキー付きメッセージダイジェストフィールドにKerberosセッションが使用された場合のみです。[1]のセクション7では、整合性オブジェクトのキーを確立するためのいくつかの問題について説明します。Auth_Data要素内にKerberosチケットを含めることにより、RSVP整合性オブジェクトのセキュリティ協会の確立は、チケットをノード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セッションチケットには、他の多くのフィールドの中でも、セッションキーが含まれています。ポリシーロケーターは、同じセッションキーで暗号化される場合もあります。このような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.
X.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].
ポリシーエラーオブジェクトは、ポリシーに基づく入場管理の失敗またはその他の資格検証の場合に使用されます。現在利用可能なエラーメッセージにより、資格情報の有効期限が切れている場合（有効期限が切れている）、認可プロセスがリソース要求（不十分な_Privileges）を許可した場合、または資格情報の特定のセットがサポートされていない場合（UNSUPPORTED_CREDENTIAL_TYPE）。ネットワークによって返された最後のエラーメッセージにより、ユーザーのホストはサポートされている資格情報の種類を発見できます。特にモバイル環境では、これは非常に非効率的かもしれません。さらに、ユーザーがさまざまなタイプの資格情報をサポートする可能性は低いです。エラーメッセージID_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.
Integrity Handshakeプロトコルは、クラッシュまたは再起動されたホストが受信ホストに保存されている最新の有効なチャレンジ値を取得できるように設計されています。キー管理がないため、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)
課題：=（キー識別子、チャレンジクッキー）
Integrity Challenge Message:=(Common Header, CHALLENGE)
整合性チャレンジメッセージ：=（一般的なヘッダー、チャレンジ）
Integrity Response Message:=(Common Header, INTEGRITY, CHALLENGE)
整合性応答メッセージ：=（一般的なヘッダー、整合性、課題）
The "Challenge Cookie" is suggested to be a MD5 hash of a local secret and a timestamp [1].
「Challenge Cookie」は、地元の秘密とタイムスタンプの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.
Integrity Challengeメッセージは、上記のプロトコルフローに示すように、整合性オブジェクトで保護されていません。[1]のセクション10で説明したように、これは、両方の通信当事者が有効な開始シーケンス番号を持っていない状況での問題を回避するために行われました。
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が提供するメカニズムの保護、ユーザーのIDの機密性、および信号メッセージの機密性について説明します。
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 Key Distribution Centerや、たとえば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での認証を検討する場合、ユーザーとシグナリングメッセージのホスト認証を区別することが重要です。ホストはRSVP Integrityオブジェクトを使用して認証されますが、auth_Dataオブジェクト内の資格情報を使用してユーザーを認証できます。このセクションでは、焦点はホスト認証にありますが、次のセクションではユーザー認証について説明します。
(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.
セキュリティ協会の選択は、セクション3.1およびセクション3.2に記載されているように、セキュリティ協会の選択がホストのIPアドレスに拘束されるため、「ホスト認証」という用語は上記で使用されます。このセキュリティ協会の作成に使用される主要な管理プロトコルと使用されるIDに応じて、ユーザーIDをこのセキュリティ協会に結合することも可能です。主要な管理プロトコルは指定されていないため、この部分を評価することは困難であるため、RSVP整合性オブジェクトのホストのIDに基づいたデータオリジン認証について話します。セキュリティ協会の選択にホストIDが使用されているという事実は、セクション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オブジェクトのKerberos
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で説明したように、Kerberosを使用してRSVP Integrityオブジェクトのキーを作成できます。他のノードの主名（およびレルム情報）を学習する方法[1]の範囲外です。[20]は、この目的に使用できるDNSを介して主要な情報を配布する方法を説明しています（この情報が望まれている他のノードのFQDNまたはIPアドレスがわかっていると仮定します）。必要なのは、ポリシー要素内の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.
Kerberosと組み合わせたRSVPマルチキャスト処理には、追加の考慮事項が含まれます。[1]のセクション7は、マルチキャストの場合、すべてのレシーバーがKerberos認証サーバー（つまり、すべてのレシーバーに使用される単一のプリンシパル）と単一のキーを共有する必要があると述べています。ロドニー・ヘスとの個人的な議論から、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.
1つのエンティティがクラッシュした場合、確立されたセキュリティ協会が失われるため、他のノードはサービスチケットを再送信する必要があります。クラッシュしたエンティティは、Integrity Challengeメッセージを使用して、新しい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.
ユーザーのホストと最初のホップルーター間の整合性保護は、RSVP整合性オブジェクトに基づいています。HMAC-MD5が推奨されますが、RSVP整合性オブジェクト内で他のキー付きハッシュ関数も使用できます。いずれにせよ、両方の通信エンティティには、使用するアルゴリズムを示すセキュリティ協会が必要です。ただし、特定のアルゴリズムに同意する交渉プロトコルが定義されていないため、これは難しい場合があります。したがって、RSVPがモバイル環境で使用されている場合、HMAC-MD5がRSVP整合性オブジェクトの唯一の使用可能なアルゴリズムである可能性があります。ローカル環境でのみ、別のキー付きハッシュアルゴリズムに切り替えることが役立つ場合があります。他の考えられる代替案は、すべての実装が最も重要なキー付きハッシュアルゴリズムをサポートすることです。たとえば、MD5、SHA-1、RIPEMD-160など。HMAC-MD5は、主にそのパフォーマンス特性のために選択されました。MD5 [21]の弱点は既知であり、最初は[22]で説明されていました。SHA-1 [15]やRipemd-160 [21]などの他のアルゴリズムには、セキュリティプロパティが強くなっています。
(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.
RSVPのリプレイ保護に使用される主なメカニズムは、シーケンス番号に基づいており、シーケンス番号がRSVP整合性オブジェクトに含まれています。このシーケンス番号メカニズムの特性は、[1]のセクション3.1で説明されています。受信機がシーケンス番号のリストを保存するという事実は、ウィンドウメカニズムのインジケーターです。これは、レシーバーが[1]のセクション3に与えられた最高の数のみを保存する必要があるという要件とどういうわけか競合します。これは監視であると仮定します。[1]のセクション4.2では、秩序外の配信とリプレイウィンドウを指定する実装の能力に関するいくつかのコメントを示します。[3]の付録Cは、アウトシーケンス配信を処理するためのウィンドウメカニズムについて説明しています。
(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.
整合性の握手のメカニズムは、セクション3.5で説明されています。Cookie値は、地元の秘密とタイムスタンプのハッシュであることが示唆されています。Cookie値は受信機によって検証されていません。整合性の握手で使用されるメカニズムは、単純な課題/応答メッセージであり、2人のホスト間で共有されるキーがクラッシュを生き延びたと仮定します。ただし、セキュリティ協会が動的に作成されている場合、この仮定は真実ではない場合があります。
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.
[1]のセクション10では、著者は、敵がチャレンジCookieを含む偽造された整合性の握手メッセージを作成できることに注目しています。その後、受信した応答を保存し、後でこれらの応答を再生しようとする可能性があります。この再生された整合性応答値が有効で、実際に使用されるよりも低いシーケンス番号がある場合、この値は回復ホストに保存されます。この攻撃が成功するためには、敵は多数の課題/応答値のペアを収集したか、Cookie生成メカニズムを「発見」した必要があります（たとえば、地元の秘密を知ることによって）。Cookie/Responseペアのコレクションは、Cookie値、応答メッセージに含まれるシーケンス番号、およびIntegrityオブジェクトで使用される共有キーに依存するため、さらに困難です。
(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.
機密性は、RSVPのセキュリティ要件とは見なされません。したがって、セクション4.3のパラグラフd）で説明されている場合を除き、RSVPによってサポートされていません。ただし、この仮定は、ユーザーのアイデンティティに加えて、盗難やトラフィック分析から、ユーザーのアイデンティティに加えて、請求データ、ネットワーク使用パターン、またはネットワーク構成を保護したい企業またはキャリアの場合は当てはまらない場合があります。機密性は、特定の攻撃をより困難にするのにも役立ちます。たとえば、セクション5.2で説明されているPatherr攻撃は、攻撃者がPatherrが対応するパスメッセージを観察できない場合に実行するのが困難です。
(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.
承認のタスクは、ネットワークアクセス認証とRSVP要求の認証の2つのサブカテゴリで構成されています。アクセス許可は、ノードがネットワークに認証されている場合、たとえばAAAプロトコル（たとえば、半径[24]または直径[9]）と組み合わせてEAP [23]を使用している場合に提供されます。ネットワークアクセス認証と認証に関連する問題は、RSVPの範囲外です。
The second authorization refers to RSVP itself. Depending on the network configuration:
2番目の承認は、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
* ルーターは、受信したRSVPリクエストをポリシー決定ポイントに転送し（例：COP [10]、[11]）、入学管理手順を実行するよう要求するか、または
* 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.
RSVP Integrityオブジェクトのキー付きメッセージダイジェストの計算は、パフォーマンスの問題を表すものではありません。これらのメッセージは低速度で送信されるため、信号メッセージの保護は通常問題ではありません。大量のメッセージでさえ、キー付きメッセージダイジェストルーチンの効率により、RSVPルーターのパフォーマンスの問題を引き起こしません。
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を使用して、ユーザーは、ネットワークドメインが提供するインフラストラクチャまたは使用したアーキテクチャによって提供されるインフラストラクチャに応じて、最初のホップルーターまたは[1]で指定されているPDPに認証することができます（たとえば、RSVPとKerberos V5のWindows 2000への統合オペレーティングシステム[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.
ユーザーがRSVPパスまたはRESVメッセージを送信すると、このメッセージにはユーザーを認証するための情報が含まれる場合があります。[7]は、ユーザーとアプリケーションの情報がRSVPメッセージ（auth_dataオブジェクト）にどのように埋め込まれているか、それを保護する方法について説明します。このようなメッセージを受信するルーターは、この情報を使用してクライアントを認証し、ユーザーまたはアプリケーション情報をポリシー決定ポイント（PDP）に転送できます。オプションで、PDP自体はユーザーを認証できます。これについては、次のセクションで説明します。ユーザーを認証し、整合性を確認し、リプレイを確認できるようにするには、policy_Data要素全体をルーターからPDPに転送する必要があります（たとえば、要素をCOPSメッセージに含めることにより）。[7]で明確に指定されていませんが、policy_Data要素内の整合性オブジェクトは、他のすべての属性とともにPDPに送信されると想定されています。
* 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を使用して、ファーストホップルーターの代わりにユーザーを認証します。[7]のセクション4.2.1では、ユーザーが次のホップルーターまたはPDPのいずれかのセッションチケットを取得するための選択肢が与えられます。同じセクションに記載されているように、PDPまたは次のホップルーターのIDは静的に構成または動的に取得されます。その後、PDPへのユーザー認証が考慮されます。
* Kerberos-based Authentication to the PDP
* KerberosベースのPDPへの認証
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によって返されるポリシー決定を実行するという受動的な役割を果たします。付録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メッセージがユーザーのホストに送信され、パブリックキーベースの認証が使用されない場合、メッセージには証明書とデジタル署名が含まれていません。したがって、相互認証は想定できません。Kerberosの場合、PDPまたはルーターがKerberosチケットから取得したセッションキーで計算された整合性オブジェクトを使用してポリシーオブジェクトを送信する場合、またはポリシー要素に含まれるKerberosチケットがポリシー要素にも使用されている場合、相互認証が達成される場合があります。セクション4.2で説明されているRSVP整合性オブジェクト。この手順は、以前のメッセージがエンドホストからネットワークに送信され、そのようなキーがすでに確立されている場合にのみ機能します。参照[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.
整合性保護は、図1に示すように、RSVPメッセージとpolicy_Data要素に個別に適用されます。パスに沿ったポリシー無視ノードの場合、RSVP整合性オブジェクトとポリシー要素内の整合性オブジェクトは、異なるノードで終了します。基本的に、最初のホップルーターの代わりにポリシー決定ポイントで検証されている場合、ユーザーの資格情報にも同じことが当てはまります。
* Kerberos
* 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チケットに含まれるセッションキーを使用して、ポリシー要素の整合性オブジェクトを計算できます。認証を提供するのは、キー付きメッセージダイジェストです。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要素内の整合性オブジェクトのキー付きハッシュ値によって提供されます。これは、ユーザーがKerberosプロトコルに積極的に参加し、セッションキーを取得してキー付きメッセージダイジェストを計算できることを示しています。Kerberos V5プロトコルで使用される認証器は同様の機能を提供しますが、リプレイ保護はタイムスタンプに基づいています（または、認証器内のオプションのSEQ番号フィールドが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.
Public-Keyベースの認証が提供されている場合、ユーザー認証はデジタル署名で達成されます。[7]のセクション3.3.3で説明したように、Digital_Signature属性はauth_dataオブジェクトの最後の属性でなければならず、デジタル署名はauth_dataオブジェクト全体をカバーしています。PGPの場合、ハッシュアルゴリズムと公開キーアルゴリズムがデジタル署名計算に使用される場合、[19]で説明されています。X.509資格情報の場合、CMS [29]やPKCS＃7 [30]などのさまざまなメカニズムをメッセージ要素にデジタル署名するために使用できるため、状況はより複雑です。X.509は、証明書レイアウトの標準のみを提供します。これは、この目的のために不十分な情報を提供しているようです。したがって、X.509証明書は、たとえばCMSまたはPKCS＃7によってサポートされています。[7]しかし、CMSまたはPKCS＃7の使用に関する声明はありません。現在、CMSまたはPKCS＃7 [7]のサポートはありません。これは、パブリックキーベースの認証（CRL分布、主要輸送、キー契約など）以上のものを提供します。さらに、RSVPでのPGPの使用は、PGP（OpenPGP [19]を含む）の異なるバージョンがあり、どの使用されるべきかについての兆候が与えられていないため、漠然と定義されています。
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:
整合性オブジェクトが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整合性オブジェクトの可用性に基づいていると仮定するかもしれません。
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セッションチケットのみを含めるには、新鮮さが提供されていないため（Kerberos Authenticatorが欠落しているため）。明らかに、ユーザーが実際にKerberosプロトコルに従い、受信したTGS_REPを復号化できたという保証はありません（または、まれに、最初のAS_REQでセッションチケットが要求された場合、AS_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.
図5は、より複雑なアーキテクチャでの信号メッセージのリプレイ保護に関連するインターフェイスを示しています。この場合、PEP1はポリシー認識ではないため、クライアントはPEP2でポリシーデータ要素を使用します。クライアントとPEP1の間、およびPEP1とPEP2の間のインターフェイスは、RSVP整合性オブジェクトで保護されています。たとえば、PEP2とPDPの間のリンクは、COPSビルトインインテグリティオブジェクトを使用することにより保護されています。クライアントとPDPの間の点線は、rsvp整合性オブジェクトが含まれていないauth_data要素によって提供される保護を示します。
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.
RSVP Integrityオブジェクトを使用したホスト認証とPolicy_Data要素内の整合性オブジェクトを使用したユーザー認証は、両方とも同じ反レプレイメカニズムを使用します。シーケンス番号フィールドの長さ、シーケンス番号ロールオーバー、および完全性の握手は、セクション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オブジェクトは、ユーザーID情報をセキュリティ（リプレイ）攻撃から含むポリシーオブジェクトを保護するために使用されます。」パブリックキーベースの認証を使用する場合、RSVPベースのリプレイ保護はサポートされていません。これは、デジタル署名がシーケンス番号フィールドでpolicy_Data Integrityオブジェクトをカバーしていないためです。デジタル署名は、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]で説明されています。Signed Message Digestに先行するデータ構造には、使用されたメッセージDigestアルゴリズムに関する情報と、署名が作成されたときの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で説明されているように、チケット内の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) （ユーザーID）機密性
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.
このセクションでは、ポリシー要素内で送信されるID情報のプライバシー保護について説明します。ユーザーIDの機密性は、Policy_DataオブジェクトまたはAUTH_DATA要素を暗号化するためのRSVPメカニズムが組み込まれていないため、特に興味深いものです。auth_data要素内の属性の1つであるPolicy_locator属性の暗号化について説明します。
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は、訪問されたネットワークプロバイダーのドメインの外側に送信されるべきではありません。つまり、ポリシーデータ要素内のユーザーID情報をPDPによって削除または変更する必要があります。（提供されたメカニズムを使用して）最初のポリシー対象のRSVPノード（または添付ネットワーク全般）に表示されないようにユーザーのIDを隠すことはできません。
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].
asciiまたはunicode retinguided unicodeは、[7]のセクション3.3.1で指定されているように、auth_data要素のpolicy_locator属性内のユーザーまたはアプリケーションの違いを暗号化できます。ユーザー（またはアプリケーション）IDは、パブリックキーベースの認証の場合、Kerberosセッションキーまたは秘密鍵のいずれかで暗号化されます。秘密鍵を使用すると、通常、公開キーを所有するすべての人が検証できるデジタル署名について話します。公開キーの証明書はメッセージ自体に含まれているため、復号化は障害ではありません。さらに、rsvpメッセージに追加の（暗号化されていない）情報と一緒に含まれている証明書は、盗聴者に十分なID情報を提供します。したがって、パブリックキーベースの認証の場合にポリシーロケーターを暗号化する可能性には問題があります。非対称暗号化を使用してIDを暗号化するには、ユーザーのホストは、ポリシー要素（つまり、最初のポリシー認識ルーターまたはPDP）を検証するエンティティの公開鍵を何らかの形で取得できる必要があります。次に、この公開キーを使用して対称キーを暗号化できます。これにより、PGPが行うように、ユーザーの身元と証明書が暗号化されます。現在、[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).
Kerberosセッションキーを使用してpolicy_locatorを暗号化するために使用されるアルゴリズムは、サービスチケットの暗号化に使用されたものと同じであると想定されます。使用されているアルゴリズムに関する情報は、暗号化されたASN.1エンコードされたメッセージパーツのETYPEフィールドで利用できます。[8]のセクション6.3には、サポートされているアルゴリズムを示します。[33]は、新しい暗号化アルゴリズム（Rijndael、Serpent、および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.
ユーザーIDの機密性を評価するには、RSVP以外で実行されたプロトコル（たとえば、Kerberosプロトコル）を調べる必要があります。資格情報属性に含まれるチケットは、チケットの暗号化されていない部分にオプションのCNAME属性を含めないことにより、ユーザーID保護を提供できます。AuthenticatorにはRSVPメッセージが送信されないため、Authenticatorの暗号化されていない部分のCNAMEとCREALMは明らかにされていません。ユーザーがクレデンシャル属性に含めるためにKerberosセッションチケットを要求するには、Kerberosプロトコル交換を実行する必要があります。次に、TGS_REQで送信された認証者がユーザーの身元を明らかにします。AS_REQには、ユーザーの秘密キーで暗号化されたAS_REPメッセージでKerberos認証サーバーが応答できるようにするために、ユーザーの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.
ホストからルーターへのインターフェイスの承認手順の説明に加えて、ユーザーベースの認証は、ユーザーの資格情報を提供するポリシー要素で実行されます。ユーザーおよびアプリケーション固有の情報を含めることで、専用のサーバーに保存される可能性のある特別なユーザーポリシーを使用したポリシーベースの入場制御が可能になります。したがって、ポリシーの決定ポイントは、たとえば、特定のユーザーが要求することが許可されているリソースの量を記載するサービスレベル契約のLDAPサーバーを照会できます。ユーザーのID情報に加えて、グループメンバーシップおよびその他の非セキュリティ関連情報が最終的なポリシー決定の評価に貢献する可能性があります。ユーザーが現在添付されているドメインに登録されていない場合、ユーザーのホームドメインがどのくらいの情報を交換しているかという問題があります。これは、ユーザーのプライバシーポリシーにも影響します。
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.
Kerberosがユーザー認証に使用される場合は、Kerberosチケットをauth_data要素の資格情報セクションに含める必要があります。Kerberosチケットのサイズは500バイトを超えていますが、[1]のセクション7.1に記載されているように、パフォーマンスの最適化によりセッションキーをキャッシュすることができるため、1回だけ送信する必要があります。その後のRSVPメッセージには、Kerberosセッションキーを使用するキー付きメッセージダイジェストを持つPolicy_Data Integrityオブジェクトのみが含まれると想定されています。ただし、これは、Policy_Data Integrityオブジェクトに必要なセキュリティ協会が、正しいキーの選択を可能にするために作成（または変更）されることを前提としています。それ以外の場合は、セキュリティ協会のインデックスに使用される識別子を使用することは困難です。
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が認証システムとして使用されている場合、パフォーマンスの観点から、セッションキーを取得するためのメッセージ交換を考慮する必要がありますが、セッションチケットの生涯で1回だけ行う必要があります。これは、速いローミングユーザーのホストを備えたモバイル環境で特に当てはまります。
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パスまたはRESVメッセージには、証明書とデジタル署名が含まれます。これは、膨大なパフォーマンスと帯域幅のペナルティです。低電力デバイス、高レイテンシ、チャネルノイズ、低帯域幅リンクを備えたモバイル環境の場合、これはあまり勇気づけられないようです。PDP（または最初のホップルーター）がデジタル署名と証明書を検証できるようにするには、公開キーインフラストラクチャが必要であることに注意してください。取り消された証明書を確認するには、オンライン証明書ステータスプロトコル[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.
RSVPシグナリングメッセージには、データ起源の認証があり、RSVP整合性オブジェクトでの変更とリプレイから保護されています。ルーター間のRSVPメッセージフローは、信頼のチェーンに基づいて保護されているため、各ルーターは隣接するルーターとのセキュリティ関連のみを必要とします。この仮定は、パフォーマンスの利点と、ユーザーホストが直接添付されていないコアネットワークの特別なセキュリティ特性のために行われました。コアネットワークでは、ネットワーク構造は頻繁に変更されず、RSVP整合性オブジェクトの共有秘密の手動分布は受け入れられる場合があります。共有された秘密は、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整合性オブジェクトのキー付きメッセージダイジェストを使用して達成されます。
(2) Integrity Protection
(2) 整合性保護
Integrity protection is accomplished with the RSVP INTEGRITY object with the variable length Keyed Message Digest field.
整合性保護は、可変長キー付きメッセージダイジェストフィールドを使用して、RSVP整合性オブジェクトで達成されます。
(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.
RSVP Integrityオブジェクトを使用したリプレイ保護は、前のセクションで広く説明されています。クラッシュしたホストが使用されている最新のシーケンス番号を学習できるようにするために、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.
RSVPネットワークに応じて、さまざまなルーターでのQoSリソース認証は、再度PDPに連絡する必要がある場合があります。PDPはポリシー要素を変更することが許可されているため、再承認手順の効率を高めるためにトークンをポリシー要素に追加することができます。このトークンは、既に計算されたポリシー決定を指すために使用されます。PEPからPDPへの通信インターフェイスは、適切に保護する必要があります。
(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.
RSVP整合性オブジェクトは、送信されたシグナル伝達メッセージのキー付きメッセージダイジェストの計算にのみ使用されるため、RSVPシグナリングメッセージの保護のためのパフォーマンス特性は、主要な交換プロトコルによって大部分が決定されます。
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：Next-Hopの問題。
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パスメッセージを受信すると、標準のRSVPメッセージ処理が行われます。ノードAは、信号メッセージを保護するために選択するキーを決定する必要があります。いくつかの不特定のメカニズムがこの決定を下すために使用されると仮定します。この例では、ノードAは、メッセージがRSVPノードCに移動することを前提としていますが、何らかの理由で（例えば、ルートの変更、パスに沿って次のRSVPホップを学習できないなど）、メッセージはノードBに移動します。メッセージの整合性を確認できない（またはKerberosサービスチケットを復号化できない）非RSVPサポートルーター。処理障害により、Patherrメッセージがパスメッセージの発信中の送信者に返されます。このエラーメッセージには、エラーを認識したノードに関する情報も含まれています。多くの場合、セキュリティ協会は利用できない可能性があります。Node A Patherrメッセージを受信すると、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は、エラーが発生したことを学習するのに役立つ動作を説明しています。ただし、[1]のセクション4.2の説明には、受信ホストがメッセージを適切に確認できない場合、[1]の信号メッセージが静かに破棄されると述べています。さらに処理することなく。」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).
したがって、RSVPパスメッセージは、パスの発見、ルートの変更の検出、ADSPECオブジェクトを使用したパスに沿ったQoS機能の検出（ある程度の解釈）、次のホップの発見、およびセキュリティ協会の設立など、多くの機能を提供します。Kerberosの場合）。
From a security point of view, there are conflicts between:
セキュリティの観点から、次の間に対立があります。
o Idempotent message delivery and efficiency
o iDempotentメッセージの配信と効率
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パスメッセージは、特に多くの関数を実行します。サポートされているメッセージの配信をサポートすることは、セキュリティ協会の確立、効率的なメッセージ配信、およびメッセージサイズと何らかの形で矛盾しています。たとえば、「実際の」等量の信号メッセージには、以前に実行されたメッセージ交換に依存せずにセキュリティ処理を実行するのに十分な情報が含まれます。ただし、すべての信号メッセージでKerberosチケットを追加することは非効率的です。パブリックキーベースのメカニズムを使用することは、すべての信号メッセージに含まれる場合、さらに非効率的です。iDempotentメッセージの公開キーベースの保護により、サービス拒否攻撃を導入するリスクが追加されます。
o RSVP Path message functionality and next-hop discovery
o RSVPパスメッセージ機能と次のホップの発見
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パスメッセージ）を保護するには、次のRSVP認識ノード（およびその他のパラメーター）のIDを知る必要があります。Next-Hop発見のメカニズムがなければ、RSVPパスメッセージもこのタスクに責任を負います。次のホップの身元を知らずに、Kerberosの主名も不明です。レシーバーが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のintserv、またはファイアウォールシグナリングなどのいくつかの新しいアプリケーションの場合、次のRSVP対応ノードは事前に知られていない場合があります。次のRSVPノードの数は、多数の非RSVP認識ノードによって分離されている場合、かなり大きい場合があります。したがって、RSVPパスメッセージを送信するノードは、次のRSVPノードの両方を検出するメカニズムとして機能する場合、メッセージを適切に保護するのが難しい場合があります（つまり、シグナリングメッセージに追加され、宛先アドレスにアドレス指定されます）とルートの変更を検出します。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ノードは、パスの変更が行われたと信じるでしょう。したがって、このノードは、別のセキュリティアソシエーションを選択しようとするか、指定されたノードでそれを作成しようとする場合があります。敵がパスに沿ってどこかに配置され、認証または承認が必要な強度と精度で実行されない場合、中間の男として行動することも可能かもしれません。この攻撃に対する感受性を低減する1つの方法は次のとおりです。セキュリティ協会が存在しないノードからPatherrメッセージが受信された場合、セキュリティ協会を確立しようとしてから、Patherrメッセージにつながるアクションを繰り返します。
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:
このセクションは、メッセージ処理に何らかの非対称性を示す2つのパーティプロトコルで認証と主要な確立が達成される場合の実際的な困難に対処しようとします。Kerberosはこのようなプロトコルであり、RSVPの動的セッションキーの確立を提供する唯一のサポートされているプロトコルでもあります。最初のホップ通信の場合、通常、ユーザーとルーター（たとえばアクセスルーター）の間で認証が行われます。特にモバイル環境では、IPまたはMacアドレスに基づいてエンドホストを認証することは不可能です。この問題を説明するために、最初のホップコミュニケーションのために、Kerberosの典型的な処理手順が示されています。
(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は、ネットワークドメインのチケット付与チケットを要求します。これは、ネットワークドメインのIDが既知であることを前提としています。
(3) Entity A then requests a service ticket for entity B, whose name was learned in step (1).
(3) エンティティAは、エンティティBのサービスチケットを要求します。エンティティBは、その名前がステップ（1）で学習されました。
(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シグナリングメッセージ（ポリシーオブジェクト内）を含むサービスチケットが含まれます。Kerberosセッションキーは、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シグナル伝達が2つの間に達成されるという仮定の下でエンドホストとアプリケーションサーバーの間ではなく、ホストを終了します）。ただし、ステップ（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]は、これらのIPSECの影響をRSVPに考慮し、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 Security Associationデータベース（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予約を行うことはできません。2つの同様の例は、VPNを使用したリモートアクセスと、ホームエージェント（またはホームネットワークのセキュリティゲートウェイ）とモバイルノード間のデータトラフィックの保護です。同じ問題は、IPSECのネストされたアプリケーションで発生します（たとえば、AとSGWの間、およびAとBの間でIPSEC）。
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].
IPSecトンネルのRSVPシグナリング交換を再帰的に適用することにより、シグナリングエンドポイントの1つ（たとえば2つのネットワーク間）で起動または終了しないIPSECトンネルは異なる方法で対処する必要があります。トンネル内の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) 確立された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.
セキュリティ協会に新しいSPIが割り当てられます。この変更を反映するには、新しい予約を確立する必要があるか、既存の予約のフロー識別子を更新する必要があります。IPSEC SASの寿命は長いため、これは大きな問題ではないようです。SCTPデータトラフィックのIPSEC保護により、SCTP Associationから追加および削除されたIPアドレスを反映するために、IPSEC SA（およびSPI）の変更が必要になる場合があります。
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つのエンドホスト間に送信される資格情報を指します。パスに沿ったルーターが、規定の処理手順に従ってシグナリングメッセージを処理および変更できるように注意する必要があることは明らかです。ただし、一部のオブジェクトまたはメカニズムは、エンドツーエンドの保護に使用できます。ただし、主な問題は、このようなエンドツーエンドのセキュリティの利点です。まず、必要なセキュリティ協会をどのように確立するかという問題があります。インターネット上の2人のarbitrary意的なホストの間では、これは非常に困難であることが判明するかもしれません。第二に、エンドツーエンドのセキュリティの有用性は、RSVPが展開されるアーキテクチャに依存します。rsvpがQoS情報をネットワークに信号に信号するためにのみ使用され、パラメーターを交渉し、QoS予約に対して請求されるエンティティを決定するために他のプロトコルを事前に実行する必要がある場合、エンドツーエンドのセキュリティは不要になる可能性があります。エンドツーエンドのセキュリティをRSVPに導入すると、RSVPプロキシ[37]、ローカライズされたRSVP [38]などの拡張機能に問題が発生し、宛先エンドホストに到達せずにパスに沿ってRSVPシグナル伝達を終了するその他の問題が発生します。そのような行動は、中間の攻撃として解釈される可能性があります。
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.
RSVPシグナル伝達メッセージは、2つの隣接するRSVPノードの間でホップバイホップファッションでIPSEC [3]によって保護されることも想定されています。ただし、RSVPは、IPSEC保護を複雑にするシグナリングメッセージの特別な処理を使用します。このセクションで説明したように、IPSECは、ポイントツーポイント通信環境でのRSVPシグナリングメッセージの保護にのみ使用する必要があります（つまり、RSVPメッセージは1つの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メッセージは、プロトコル番号46を持つ生のIPパケットとして送信されます。[6]の付録Cに記載されているように、UDPでそれらをカプセル化することが可能かもしれません。一部のRSVPメッセージ（PATH、PATHTEAR、およびRESVCONF）には、IPヘッダーにルーターアラートIPオプションを設定する必要があります。これらのメッセージは、パスに沿った次のRSVPノードではなく、（ユニキャストまたはマルチキャスト）宛先アドレスにアドレス指定されます。したがって、IPSECトラフィックセレクターは、これらのフィールドをIPSEC SA選択にのみ使用できます。単一のパスしか（そして、おそらくそれに沿ったすべてのトラフィックが保護されている）場合、シグナリングメッセージのIPSEC保護に問題はありません。このタイプの保護は一般的ではなく、エンドホストとその最初のホップルーター間のネットワークアクセスを保護するためにのみ使用される場合があります。説明されているRSVPメッセージは、次のRSVPノードの代わりに宛先アドレスにアドレス指定されるため、トンネルモードで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メッセージが複数の可能なパスをテケットにできる場合、IPSECエンジンはメッセージを保護するのが困難になります。RSVPデーモンが宛先IPアドレスを備えたトラフィックセレクターをインストールしている場合でも、際立った要素は、パスに沿って可能なRSVPノードの1つに対して正しいセキュリティアソシエーションの選択を許可していません。いくつかの追加情報を組み込むことにより、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.
RESVのようなRSVPメッセージは、IPSECによって保護できます。これは、さまざまな次のRSVPノードを区別できるIPSECトラフィックセレクターを作成するのに十分な情報が含まれているためです。トラフィックセレクターには、プロトコル番号と、通信RSVPノードの2つの電源と宛先アドレスペアが含まれます。
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 Parkwayモデルとチャネルごとの金融和解をある程度しかサポートしていません。ユーザー（またはエンドホスト）の認証は、ユーザーID表現メカニズムを備えて提供できますが、多くの場合、認証は許可には不十分な場合があります。ポリシーのために定義された通信手順
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は、データレシーバーによるQoS予約の許可を得て、受信機が開始する予約に焦点を当てており、これは[36]で説明されているように、モビリティ処理にかなりの複雑さをもたらします。
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で提供される公開キー認証とユーザーIDの機密性は、いくらかの改善が必要です。
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 データオリジン認証は、非RSVPノード（PDPなど）で提供されるべきではありません。このような手順は、認証段階とキー交換フェーズ中のエンティティ認証によって達成できます。
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.
ホルヘ・クエラー、ロバート・ハンコック、Xiaoming Fu、Guenther Schaefer、Marc de Vuyst、Bob Grillo、およびJukkaのコメントに感謝します。さらに、Hannesは、さまざまな問題について議論してくれたロバートとホルヘに感謝したいと思います。
Finally, we would like to thank Allison Mankin and John Loughney for their guidance and input.
最後に、アリソン・マンキンとジョン・ラウニーの指導と意見に感謝します。
[1] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[1] Baker、F.、Lindell、B。、およびM. Talwar、「RSVP暗号認証」、RFC 2747、2000年1月。
[2] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[2] Herzog、S。、「ポリシー管理のためのRSVP拡張」、RFC 2750、2000年1月。
[3] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[3] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、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.、Bellare、M。、およびR. Canetti、「HMAC：メッセージ認証のためのキードハッシング」、RFC 2104、1997年2月。
[5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[5] Rivest、R。、「The Md5 Message-Digest Algorithm」、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] Braden、B.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（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.、Ford、P.、Moore、T.、Herzog、S。、およびR. Hess、「RSVPのアイデンティティ表現」、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] Kohl、J。and C. Neuman、「The Kerberos Network Authentication Service（V5）」、RFC 1510、1993年9月。RFC4120により廃止。
[9] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[9] Calhoun、P.、Loughney、J.、Guttman、E.、Zorn、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] Durham、D.、Boyle、J.、Cohen、R.、Herzog、S.、Rajan、R。、およびA. Sastry、「The Cops（Common Open Policy Service）Protocol」、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] Herzog、S.、Boyle、J.、Cohen、R.、Durham、D.、Rajan、R.、およびA. Sastry、「Cops for RSVP」、RFC 2749、2000年1月。
[12] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997.
[12] Berger、L。およびT. O'Malley、「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. Zhang、「RSVP Operation over IP Tunnels」、RFC 2746、2000年1月。
[14] Hess, R. and S. Herzog, "RSVP Extensions for Policy Control", Work in Progress, June 2001.
[14] Hess、R。およびS. Herzog、「RSVP拡張のためのRSVP拡張」、2001年6月、進行中の作業。
[15] "Secure Hash Standard, NIST, FIPS PUB 180-1", Federal Information Processing Society, April 1995.
[15] 「Secure Hash Standard、Nist、Fips Pub 180-1」、連邦情報処理協会、1995年4月。
[16] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[16] Kent、S。およびR. Atkinson、「IP Authentication Header」、RFC 2402、1998年11月。
[17] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[17] Kent、S。およびR. Atkinson、「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] Fowler、D。、「DS1、E1、DS2、およびE2インターフェイスタイプの管理されたオブジェクトの定義」、RFC 2495、1999年1月。
[19] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
[19] Callas、J.、Donnerhacke、L.、Finney、H。、およびR. Thayer、「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. Altman、「Kerberos KDCおよびRealm Information with DNS」の配布」は、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 Vol。1039、pp。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 Laboratories Cryptobytes、Vol。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.、Blunk、L.、Vollbrecht、J.、Carlson、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.
[24] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[25] "Microsoft Authorization Data Specification v. 1.0 for Microsoft Windows 2000 Operating Systems", April 2000.
[25] 「Microsoft Windows 2000オペレーティングシステムのMicrosoft Authorization Data Specificationv。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] Cable Television Laboratories、Inc。、「Packetcableセキュリティ仕様、PKT-SP-SEC-I01-991201」、Webサイト：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] Myers、M.、Ankney、R.、Malpani、A.、Galperin、S。、およびC. Adams、「X.509インターネット公開キーインフラオンライン証明書ステータスプロトコル」、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. Freeman、「Simple証明書検証プロトコル（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] Davis、D。およびD. Geer、「時計を添えたKerberos：履歴、プロトコル、実装」、Usenix Computing Systems、Vol 9 no。1、1996年冬。
[33] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, February 2005.
[33] Raeburn、K。、「Kerberos 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.、van den Bosch、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.、van den Bosch、S.、Schulzrinne、H。、およびT. Chen、「Qos NSLP認証問題」、2003年6月、進行中の作業。
[36] Thomas, M., "Analysis of Mobile IP and RSVP Interactions", Work in Progress, October 2002.
[36] Thomas、M。、「モバイルIPおよびRSVP相互作用の分析」、2002年10月、進行中の作業。
[37] Gai, S., Gaitonde, S., Elfassy, N., and Y. Bernet, "RSVP Proxy", Work in Progress, March 2002.
[37] Gai、S.、Gaitonde、S.、Elfassy、N。、およびY. Bernet、「RSVP Proxy」、2002年3月、進行中。
[38] Manner, J., Suihko, T., Kojo, M., Liljeberg, M., and K. Raatikainen, "Localized RSVP", Work in Progress, September 2004.
[38] Mather、J.、Suihko、T.、Kojo、M.、Liljeberg、M。、およびK. Raatikainen、「ローカライズされたRSVP」、2004年9月、進行中の作業。
[39] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[39] Harkins、D。およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。
[40] Thomas, M., "Kerberized Internet Negotiation of Keys (KINK)", Work in Progress, October 2005.
[40] Thomas、M。、「Kerberized Internet negotiation of Keys（Kink）」、2005年10月の作業。
[41] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, November 2005.
[41] Kaufman、C。、「Internet Key Exchange（IKEV2）プロトコル」、RFC 4306、2005年11月。
[42] Herzog, S., "Accounting and Access Control in RSVP", PhD Dissertation, USC, Work in Progress, November 1995.
[42] Herzog、S。、「RSVPの会計およびアクセス制御」、PhD論文、USC、1995年11月、Work in Progress。
[43] Herzog, S., "Accounting and Access Control for Multicast Distributions: Models and Mechanisms", June 1996.
[43] Herzog、S。、「マルチキャスト分布の会計およびアクセス制御：モデルとメカニズム」、1996年6月。
[44] Pato, J., "Using Pre-Authentication to Avoid Password Guessing Attacks", Open Software Foundation DCE Request for Comments, December 1992.
[44] Pato、J。、「パスワード推測攻撃を避けるために事前認証を使用する」、1992年12月、コメントのオープンソフトウェア財団DCEリクエスト。
[45] Tung, B. and L. Zhu, "Public Key Cryptography for Initial Authentication in Kerberos", Work in Progress, November 2005.
[45] Tung、B。およびL. Zhu、「Kerberosの初期認証のための公開キー暗号」、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] Wu、T。、「Kerberosパスワードセキュリティの現実世界分析」、1999年2月、サンディエゴの1999年インターネットソサエティネットワークおよび分散システムセキュリティシンポジウムの議事録。
[47] Wu, T., Wu, F., and F. Gong, "Securing QoS: Threats to RSVP Messages and Their Countermeasures", IEEE IWQoS, pp. 62-64, 1999.
[47] Wu、T.、Wu、F。、およびF. Gong、「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. Gong、「マルチメディアアプリケーション用のRSVPの保護」、ProcM Multimedia 2000（Multimedia Security Workshop）、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. Nath、「RSVP-SQOS：A Secure RSVP Protocol」、International Conf on Multimedia and Exposition、東京、日本、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）、pp。5-26、1996年10月。
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で使用される場合があります。辞書攻撃はKerberosとの関係でしばしば言及されているため、ここでいくつかの問題について説明します。
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.
最初のkerberos as_reqリクエスト（事前認証なし、さまざまな拡張機能なし、pkinitなし）は保護されていません。応答メッセージAS_REPは、クライアントの長期キーで暗号化されています。敵は、AS_REPメッセージを要求してオフラインの辞書攻撃を取り付けることにより、この事実を利用できます。受託前（[44]）を使用して、この問題を軽減できます。ただし、承認前は、モバイルノードとKDCの間のパスに沿ってKerberosメッセージを盗むことができる敵による辞書攻撃を完全に防ぐものではありません。最初のリクエストに必須の事前認証により、敵は任意のユーザーのチケット付与チケットを要求することはできません。オンラインパスワードの推測攻撃は、パスワード（例：辞書から）を選択してから、認証前のデータフィールドを含む初期リクエストを送信することで依然として可能です。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）の使用は、そのような解決策の1つです。その他の提案は、最初のKerberos Exchangeでユーザーのパスワードを保護するために、強力なパスワードベースの認証された認証キー契約プロトコルを使用します。[46]は、Kerberosのセキュリティについて議論し、辞書攻撃を防ぐためのメカニズムについても議論しています。
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.
次のセクションでは、ユーザー間認証の例について説明します。以下の説明は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:
KerberosをRSVPに統合する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要素に埋め込まれ、パスまたはRESVメッセージのいずれかに含まれます。Microsoftの実装の場合、著名な名前としてエンコードされたユーザーIDは、Kerberosのチケットに付属のセッションキーで暗号化されます。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メッセージはPEPによって傍受され、PDPに転送されます。[25]は、RSVPメッセージをPDPに転送するために使用されるプロトコルを使用していません。
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
o 最終的にメッセージを受信し、受信したサービスチケットを復号化するPDP。チケットには、ユーザーのホストが使用するセッションキーが含まれています
* 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要素の整合性オブジェクトに整合性保護されたキー付きメッセージダイジェストフィールドを作成します。ここで説明する保護は、ユーザーのホストとPDPの間です。一方、RSVP整合性オブジェクトは、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ベースのディレクトリサービス）を照会する方法を説明しています。
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シグナリングメッセージを変更する悪意のある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パスメッセージに追加されます。さらに、レシーバーは、「署名された」履歴を含む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
Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich、Bavaria 81739ドイツ
EMail: Hannes.Tschofenig@siemens.com
Richard Graveman RFG Security 15 Park Avenue Morristown, NJ 07960 USA
リチャードグレイグマンRFGセキュリティ15パークアベニューモリスタウン、ニュージャージー07960アメリカ
EMail: rfg@acm.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供され、貢献者、インターネット社会とインターネットエンジニアリングタスクフォースが代表する、または後援する組織、またはインターネットエンジニアリングタスクフォースは、すべての保証を否認します。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the 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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果、http://ww.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エディター機能の資金は現在、インターネット協会によって提供されています。