RFC4230 日本語訳
4230 RSVP Security Properties. H. Tschofenig, R. Graveman. December 2005. (Format: TXT=121030 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group H. Tschofenig
Request for Comments: 4230 Siemens
Category: Informational R. Graveman
RFG Security
December 2005
Tschofenigがコメントのために要求するワーキンググループH.をネットワークでつないでください: 4230年のジーメンスカテゴリ: 情報のR.Graveman RFGセキュリティ2005年12月
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)インターネット協会(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で行われた前の仕事の利益を得て、過去の活動に関する知識を得ることです。
Tschofenig & Graveman Informational [Page 1] RFC 4230 RSVP Security Properties December 2005
[1ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . 3 2。 用語と建築仮定. . . . . . . . . 3 3。 概要. . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1。 RSVP保全オブジェクト. . . . . . . . . . . . . . 5 3.2。 セキュリティ協会. . . . . . . . . . . . . . . . 8 3.3。 RSVP Key Management仮定. . . . . . . . . . . 8 3.4。 アイデンティティ表現. . . . . . . . . . . . . . . 9 3.5。 RSVP保全握手. . . . . . . . . . . . . . 13 4。 詳細なセキュリティ特性の議論. . . . . . . . . . . 15 4.1。 ネットワーク形態. . . . . . . . . . . . . . . . . . 15 4.2。 ホスト/ルータ.154.3。 気力/PDP. . . . . . . . . . . . . . . . . . . 19 4.4へのユーザ。 RSVP意識しているルータ. . . . . . . 28 5のコミュニケーション。 その他は.295.1を発行します。 最初に、問題. . . . . . . . . . . . . . . . . . . 30 5.2を飛び越してください。 次のホップ問題. . . . . . . . . . . . . . . . . . . 30 5.3。 最後に問題. . . . . . . . . . . . . . . . . . . 33 5.4を飛び越してください。 RSVPとIPsecによって保護されたデータ通信量. . . . . . . . 34 5.5。 終わりから終わりへの安全保障問題とRSVP. . . . . . . . . 36 5.6。 RSVPシグナリングメッセージ. . . . . 36 5.7のIPsec保護。 承認. . . . . . . . . . . . . . . . . . . . 37 6。 結論. . . . . . . . . . . . . . . . . . . . . . . . 38 7。 セキュリティ問題. . . . . . . . . . . . . . . . . . 40 8。 承認. . . . . . . . . . . . . . . . . . . . . . 40 9。 参照. . . . . . . . . . . . . . . . . . . . . . . . . 40 9.1。 引用規格. . . . . . . . . . . . . . . . . 40 9.2。 RSVPセキュリティ. . . . . . . . . . . . . . . . 46に関するユーザからPDPへの認証. . . . . . . . . . . 45C.文学に関する有益な参照. . . . . . . . . . . . . . . . 41A.辞書攻撃とケルベロス. . . . . . . . . . . . . . 45B.の例
Tschofenig & Graveman Informational [Page 2] RFC 4230 RSVP Security Properties December 2005
[2ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
1. Introduction
1. 序論
As the work of the NSIS working group began, concerns about security and its implications for the design of a signaling protocol were raised. In order to understand the security properties and available options of RSVP, a number of documents have to be read. This document summarizes the security properties of RSVP and is part of the overall process of analyzing other signaling protocols and learning from their design considerations. This document should also provide a starting point for further discussions.
NSISワーキンググループの仕事が始まったとき、シグナリングプロトコルのデザインのためのセキュリティに関する心配とその含意は高められました。 RSVPのセキュリティの特性と利用可能なオプションを理解するために、多くのドキュメントが読まれなければなりません。 このドキュメントは、RSVPのセキュリティの特性をまとめて、他のシグナリングプロトコルを分析して、それらのデザイン問題から知る総合的なプロセスの一部です。 また、このドキュメントはさらなる議論のための出発点を提供するはずです。
The content of this document is organized as follows. Section 2 introduces the terminology used throughout the document. Section 3 provides an overview of the security mechanisms provided by RSVP including the INTEGRITY object, a description of the identity representation within the POLICY_DATA object (i.e., user authentication), and the RSVP Integrity Handshake mechanism. Section 4 provides a more detailed discussion of the mechanisms used and tries to describe in detail the mechanisms provided. Several miscellaneous issues are covered in Section 5.
このドキュメントの中身は以下の通り組織化されます。 セクション2はドキュメント中で使用される用語を紹介します。 セクション3はINTEGRITYオブジェクトを含むRSVPによって提供されたセキュリティー対策の概要、POLICY_DATAオブジェクト(すなわち、ユーザー認証)の中のアイデンティティ表現の記述、およびRSVP Integrity Handshakeメカニズムを提供します。 セクション4は、使用されるメカニズムの、より詳細な議論を前提として、詳細に提供されたメカニズムについて説明しようとします。 いくつかの種々雑多な問題がセクション5でカバーされています。
RSVP also supports multicast, but this document does not address security aspects for supporting multicast QoS signaling. Multicast is currently outside the scope of the NSIS working group.
また、RSVPはマルチキャストをサポートしますが、このドキュメントは、マルチキャストQoSシグナリングをサポートするためにセキュリティが局面であると扱いません。 NSISワーキンググループの範囲の外にマルチキャストが現在、あります。
Although a variation of RSVP, namely RSVP-TE, is used in the context of MPLS to distribute labels for a label switched path, its usage is different from the usage scenarios envisioned for NSIS. Hence, this document does not address RSVP-TE or its security properties.
RSVPの変化(すなわち、RSVP-TE)は分配するMPLSの文脈で使用されましたが、ラベルのためのラベルは経路を切り換えて、用法はNSISのために思い描かれた用法シナリオと異なっています。 したがって、このドキュメントは、RSVP-TEかそのセキュリティが特性であると扱いません。
2. Terminology and Architectural Assumptions
2. 用語と建築仮定
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.
内蔵のINTEGRITYオブジェクトを使用して、RSVPによって[1] 大いにサポートされたセキュリティー対策はホップごとの任意の保護に依存します。 その結果、ホップごとのRSVPメッセージにおけるINTEGRITYオブジェクトがあるセキュリティは、ネットワーク要素を支えながら、RSVPの間の保護について言及します。 さらに、RSVPメッセージの中でPOLICY_DATA要素を理解している方針意識しているノードの概念があります。 また、この要素がINTEGRITYオブジェクトを含んでいるので、ホップごとの方針意識しているノードの間にセキュリティを提供する追加セキュリティー対策があります。 方針無知なノードはPOLICY_DATA要素でのこのオブジェクトの包含で影響を受けません、彼らがそれを解釈しようとしないので。
Tschofenig & Graveman Informational [Page 3] RFC 4230 RSVP Security Properties December 2005
[3ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
To protect signaling messages that are possibly modified by each
RSVP router along the path, it must be assumed that each incoming
request is authenticated, integrity protected, and replay
protected. This provides protection against bogus messages
injected by unauthorized nodes. Furthermore, each RSVP-aware
router is assumed to behave in the expected manner. Outgoing
messages transmitted to the next-hop network element receive new
protection according to RSVP security processing.
保全は保護されました、そして、ことによると経路に沿ったそれぞれのRSVPルータによって変更されるシグナリングメッセージを保護するために、それぞれの入って来る要求が認証されると思わなければならなくて、再生は保護されました。 これは権限のないノードによって注入されたにせのメッセージに対する保護を提供します。 その上、それぞれのRSVP意識しているルータが予想された態度で振る舞うと思われます。 RSVPセキュリティ処理に応じて、次のホップネットワーク要素に伝えられた送信されるメッセージは新しい保護を受けます。
Using the mechanisms described above, a chain-of-trust is created
whereby a signaling message that is transmitted by router A via
router B and received by router C is supposed to be secure if
routers A and B and routers B and C share security associations
and all routers behave as expected. Hence, router C trusts router
A although router C does not have a direct security association
with router A. We can therefore conclude that the protection
achieved with this hop-by-hop security for the chain-of-trust is
no better than the weakest link in the chain.
上で説明されたメカニズムを使用して、ルータAとBとルータBとCがセキュリティ協会を共有して、すべてのルータが予想されるように振る舞うならルータAによってルータBで送られて、ルータCによって受け取られるシグナリングメッセージが安全であるべきである信頼のチェーンは創設されます。 したがって、ルータCには、ルータA.Weとのダイレクトセキュリティ協会がありませんが、したがって、ルータC受託ルータAは、信頼のチェーンのためにホップごとのこのセキュリティで達成された保護がチェーンで最も弱いリンクより良いというわけではないと結論を下すことができます。
If one router is malicious (for example, because an adversary has
control over this router), then it can arbitrarily modify
messages, cause unexpected behavior, and mount a number of attacks
that are not limited to QoS signaling. Additionally, it must be
mentioned that some protocols demand more protection than others
(which depends, in part, on which nodes are executing these
protocols). For example, edge devices, where end-users are
attached, may be more likely to be attacked in comparison with the
more secure core network of a service provider. In some cases, a
network service provider may choose not to use the RSVP-provided
security mechanisms inside the core network because a different
security protection is deployed.
1つのルータが悪意があるなら(敵が例えばこのルータを管理するので)、それは、任意にメッセージを変更して、予期していなかった振舞いを引き起こして、QoSシグナリングに制限されない多くの攻撃を仕掛けることができます。 さらに、いくつかのプロトコルが他のものより多くの保護(どのノードがこれらのプロトコルを実行しているかに一部よる)を要求すると言及しなければなりません。 例えば、エンドユーザが付属しているところでは、サービスプロバイダーの、より安全なコアネットワークとの比較ではエッジデバイスが、より攻撃されるかもしれなそうです。 いくつかの場合、ネットワークサービスプロバイダーは、異なった機密保持が配布されるのでコアネットワークの中でRSVPによって提供されたセキュリティー対策を使用しないのを選ぶかもしれません。
Section 6 of [2] mentions the term chain-of-trust in the context
of RSVP integrity protection. In Section 6 of [14] the same term
is used in the context of user authentication with the INTEGRITY
object inside the POLICY_DATA element. Unfortunately, the term is
not explained in detail and the assumptions behind it are not
clearly specified.
[2]のセクション6はRSVP保全保護の文脈で信頼の用語チェーンについて言及します。 [14]のセクション6では、同じ用語はユーザー認証の文脈でPOLICY_DATA要素におけるINTEGRITYオブジェクトで使用されます。 残念ながら、用語は詳細に説明されません、そして、それの後ろの仮定は明確に指定されません。
o Host and User Authentication:
o ホストとユーザー認証:
The presence of RSVP protection and a separate user identity
representation leads to the fact that both user-identity and host-
identity are used for RSVP protection. Therefore, user-based
security and host-based security are covered separately, because
of the different authentication mechanisms provided. To avoid
confusion about the different concepts, Section 3.4 describes the
concept of user authentication in more detail.
RSVP保護の存在と別々のユーザアイデンティティ表現はユーザアイデンティティとホストのアイデンティティの両方がRSVP保護に使用されるという事実につながります。 したがって、ユーザベースのセキュリティとホストベースのセキュリティは提供された異なった認証機構のために別々に含まれています。 異なった概念に関して混乱を避けるために、セクション3.4はさらに詳細にユーザー認証の概念について説明します。
Tschofenig & Graveman Informational [Page 4] RFC 4230 RSVP Security Properties December 2005
[4ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
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シグナリングメッセージの保護に必要であるセキュリティ協会の大部分が既に利用可能であると思われて、したがって、かぎ管理はあらかじめ、終わっていました。 しかしながら、ケルベロスのサポートに関して例外があります。 ケルベロスを使用して、実体はRSVPシグナリング保護に使用されるセッションキーを分配できます。
o RSVP INTEGRITY and POLICY_DATA INTEGRITY Objects:
o RSVP保全と方針_データ保全オブジェクト:
RSVP uses an INTEGRITY object in two places in a message. The
first is in the RSVP message itself and covers the entire RSVP
message as defined in [1]. The second is included in the
POLICY_DATA object and defined in [2]. To differentiate the two
objects by their scope of protection, the two terms RSVP INTEGRITY
and POLICY_DATA INTEGRITY object are used, respectively. The data
structure of the two objects, however, is the same.
RSVPはメッセージの2つの場所にINTEGRITYオブジェクトを使用します。 1番目はRSVPメッセージ自体のそうであり、カバーは[1]で定義される全体のRSVPメッセージです。 2番目は、POLICY_DATAオブジェクトに含まれていて、[2]で定義されます。 それらの保護の範囲のそばで2個のオブジェクトを差別化するために、2の用語RSVP INTEGRITYとPOLICY_データの保全オブジェクトはそれぞれ使用されます。 しかしながら、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ノードを近所付き合いさせているというわけではありません(すなわち、それらは遠くの1つ以上のIPホップであるかもしれません)。
3. Overview
3. 概要
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のために主として思い描かれた他のセキュリティー対策は説明されます。
3.1. The RSVP INTEGRITY Object
3.1. RSVP保全オブジェクト
The RSVP INTEGRITY object is the major component of RSVP security protection. This object is used to provide integrity and replay protection for the content of the signaling message between two RSVP participating routers or between an RSVP router and host. Furthermore, the RSVP INTEGRITY object provides data origin authentication. The attributes of the object are briefly described:
RSVP INTEGRITYオブジェクトはRSVP機密保持の主要なコンポーネントです。 このオブジェクトは、2つのRSVP参加ルータの間、または、RSVPルータとホストの間にシグナリングメッセージの内容のための保全と反復操作による保護を提供するのに使用されます。 その上、RSVP INTEGRITYオブジェクトはデータ発生源認証を提供します。 オブジェクトの属性は簡潔に説明されます:
o Flags field:
o 旗は以下をさばきます。
The Handshake Flag is the only defined flag. It is used to
synchronize sequence numbers if the communication gets out of
sync (e.g., it allows a restarting host to recover the most
Handshake Flagは唯一の定義された旗です。 コミュニケーションが同期するようにならないならそれが一連番号を同期させるのに使用される、(例えば、それで、再開しているホストは最も回復できます。
Tschofenig & Graveman Informational [Page 5] RFC 4230 RSVP Security Properties December 2005
[5ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
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つに設定するのは、送付者が、Integrity Challengeメッセージに応じても構わないと思っているのを示します。 したがって、交渉能力がそれぞれのINTEGRITYオブジェクトの中に伝わったようにこの旗を見ることができます。
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.
Key IdentifierはKeyed Message Digest分野の検証に使用されるキーを選択して、送付者にとって、したがって、ユニークであるに違いありません。 それには、固定48ビットの長さがあります。 このKey Identifier分野の世代はほとんどローカル・ホストの決定です。 [1]はアドレス、送付インタフェース、およびキー番号の組み合わせとしてこの野原を記述します。 私たちは、Key Identifierが単に1つ以上のセキュリティ協会が2人のホストの間で平行で使用されるなら(例えば、重なっている生涯を持っているセキュリティ関係に関してそうであるように)値が特有であるという要件で多くの分野に関して計算した(合わせられる)のハッシュであると思います。 受電方式は唯一Key Identifierに基づくセキュリティ協会と送付者のIPアドレスを特定します。 RSVP_HOPオブジェクトが存在していないなら、RSVP_HOPオブジェクトかパケットのソースIPアドレスから送付者の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.
長さはINTEGRITYオブジェクトによって使用される一連番号が64ビットです、そして、任意に始めの値は選択できます。 一連番号分野の長さは、セキュリティ協会の生涯疲労困憊を避けるために[1]のセクション3に述べられているように選ばれました。 新しいメッセージと再演されたメッセージの間で区別する受信機において整然とします、各メッセージのために一連番号を単調に増加しなければなりません(法2^64)。 私たちは、見られた最初の一連番号(すなわち、始めの一連番号)がどこかに保存されると思います。 始めの一連番号が特殊活字の数字であるかもしれないので、法操作が必要です。 したがって、一連番号が前のパケットより大きい状態で(法2^64)受信機はパケットを受け入れるだけです。 [1]で説明されるように、このプロセスは、ハンドシェイクで始められて、初期シーケンス番号に同意しています。 そのような何かハンドシェイクが利用可能でないなら、初期シーケンス番号はセキュリティ協会の設立の一部であるに違いありません。
Tschofenig & Graveman Informational [Page 6] RFC 4230 RSVP Security Properties December 2005
[6ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
The generation and storage of sequence numbers is an important
step in preventing replay attacks and is largely determined by
the capabilities of the system in the presence of system crashes,
failures, and restarts. Section 3 of [1] explains some of the
most important considerations. However, the description of how
the receiver distinguishes proper from improper sequence numbers
is incomplete: it implicitly assumes that gaps large enough to
cause the sequence number to wrap around cannot occur.
一連番号の世代とストレージは、反射攻撃を防ぐことにおける重要なステップであり、システムクラッシュ、失敗があるときシステムの能力で主に断固として、再開します。 [1]のセクション3は最も重要な問題のいくつかについて説明します。 しかしながら、受信機がどう不適当な一連番号から適切な状態で区別されるかに関する記述は不完全です: それは、一連番号が巻きつけられることを引き起こすことができるくらい大きいギャップが起こることができないとそれとなく仮定します。
If delivery in order were guaranteed, the following procedure
would work: the receiver keeps track of the first sequence number
received, INIT-SEQ, and the most recent sequence number received,
LAST-SEQ, for each key identifier in a security association.
When the first message is received, set INIT-SEQ = LAST-SEQ =
value received and accept. When a subsequent message is
received, if its sequence number is strictly between LAST-SEQ and
INIT-SEQ, (modulo 2^64), accept and update LAST-SEQ with the
value just received. If it is between INIT-SEQ and LAST-SEQ,
inclusive, (modulo 2^64), reject and leave the value of LAST-SEQ
unchanged. Because delivery in order is not guaranteed, the
above rules need to be combined with a method of allowing a fixed
sized window in the neighborhood of LAST-SEQ for out-of-order
delivery, for example, as described in Appendix C of [3].
オーダーにおける配送が保証されるなら、以下の手順は利くでしょうに: 受信機は受け取られていていて、INIT-SEQの、そして、最新の一連番号が受けた最初の一連番号の動向をおさえます、LAST-SEQ、セキュリティ協会でのそれぞれの主要な識別子のために。 最初のメッセージが受信されているとき、セットINIT-SEQ=LAST-SEQは対価領収と等しく、受け入れます。 厳密にLAST-SEQとINIT-SEQの間には、一連番号があるならその後のメッセージが受信されている(法2^64)ときには、LAST-SEQを受け入れて、ただ値を受け取っていてアップデートしてください。 包括的なINIT-SEQとLAST-SEQ(法2^64)の間には、それがあるなら、LAST-SEQの値を変わりがない拒絶して、ままにしてください。 オーダーにおける配送が保証されないので、上の規則は、例えば、不適切な配送のために[3]のAppendix Cで説明されるようにLAST-SEQの近所の固定大きさで分けられた窓を許容するメソッドに結合される必要があります。
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.
Keyed Message Digestは以前はよくシグナリングメッセージの保全保護を提供していたRSVPが組み込まれたセキュリティー対策(一連番号を含んでいて)です。 Keyed Message Digest分野に値を計算する前に、ゼロと全体のRSVPパケットの上で計算された合わせられたハッシュにKeyed Message Digest分野自体を設定しなければなりません。 Keyed Message Digest分野は、長さで可変ですが、4つの八重奏の倍数であるに違いありません。 HMAC-MD5が使用されているなら、出力値は16バイト長です。 合わせられたハッシュ関数HMAC-MD5[4]がRSVP実装に[1]のセクション1に述べられるように必要です。 また、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].
プレ共有秘密キー、どれが手動で分配されるか、そして、またはかぎ管理プロトコルの結果からこのKeyed Message Digestを計算するのに使用されるキーを入手するかもしれません。 しかしながら、かぎ管理プロトコルは、全く必要なセキュリティ協会を創設するために指定されません。 また、キー長のためのガイドラインを全く与えません。 HMAC-MD5キーが160ビット128ビットとSHA-1キーであることはお勧めであるべきです、IPsec AH[16]と超能力[17]のように。
Tschofenig & Graveman Informational [Page 7] RFC 4230 RSVP Security Properties December 2005
[7ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
3.2. Security Associations
3.2. セキュリティ協会
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]で言及されるように、同時に、送付者と受信機には複数のアクティブなキーがあるかもしれません。 1つ以上のアルゴリズムがサポートされるなら、セキュリティ協会に使用されるアルゴリズムを指定しなければなりません。
3.3. RSVP Key Management Assumptions
3.3. RSVP Key Management仮定
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
RFC2205[6]は、セキュリティ協会が既に利用可能であると仮定します。 実装は[1]のセクション5.2に述べられるように手動の主要な分配をサポートしなければなりません。 しかしながら、手動の主要な分配には、主要なストレージのための異なった要件があります。 いくつかの場合、簡単な平文ASCIIファイルは十分であるかもしれません。 異なった生涯との複数のセキュリティ協会が、次に、同時にサポートされる必要があるなら
Tschofenig & Graveman Informational [Page 8] RFC 4230 RSVP Security Properties December 2005
[8ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
a key engine would be more appropriate. Further security requirements listed in Section 5.2 of [1] are the following:
主要なエンジンは、より適切でしょう。 [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 特定の生涯、特定のKey Identifierを各キーに割り当てなければなりません。
3.4. Identity Representation
3.4. アイデンティティ表現
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]で導入するように利用可能です。 「提供方針はユーザアイデンティティに基づく入場制御機構を基礎づけたか、アプリケーションは主要な要件の1つです。」と、[7]のセクション2は述べます。 POLICY_DATAオブジェクトに含まれているAUTH_DATAと呼ばれる方針要素は、ユーザかアプリケーションを特定するために、ユーザのホストでRSVPデーモンによって作成されて、RSVPメッセージで伝えられます。 POLICY_DATA要素の構造は[2]で説明されます。 そして、政策決定が指すので行動するネットワーク・ノード(PDPs)がユーザを認証して、方針ベースの入場コントロールが実行されるのを許容するために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.
[2]でPOLICY_DATA要素の詳述を見つけることができます。 [7]で定義される認証データ方針要素AUTH_DATAに含まれた属性はこのセクションで簡潔に説明されます。 図1はセキュリティ関連しているオブジェクトと保護の範囲でRSVPメッセージの抽象的な構造を示しています。 RSVP INTEGRITYオブジェクト(外側のオブジェクト)は全体のRSVPメッセージをカバーしていますが、POLICY_データの保全オブジェクトはPOLICY_DATA要素の中でオブジェクトをカバーするだけです。
Tschofenig & Graveman Informational [Page 9] RFC 4230 RSVP Security Properties December 2005
[9ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
+--------------------------------------------------------+ | RSVP Message | +--------------------------------------------------------+ | Object |POLICY_DATA Object || | +-------------------------------------------+| | | INTEGRITY +------------------------------+|| | | Object | AUTH_DATA Object ||| | | +------------------------------+|| | | | Various Authentication ||| | | | Attributes ||| | | +------------------------------+|| | +-------------------------------------------+| +--------------------------------------------------------+
+--------------------------------------------------------+ | RSVPメッセージ| +--------------------------------------------------------+ | オブジェクト|方針_データ・オブジェクト|| | +-------------------------------------------+| | | 保全+------------------------------+|| | | オブジェクト| AUTH_データ・オブジェクト||| | | +------------------------------+|| | | | 様々な認証||| | | | 属性||| | | +------------------------------+|| | +-------------------------------------------+| +--------------------------------------------------------+
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メッセージは1個以上のPOLICY_DATAオブジェクトを含むかもしれません、そして、それぞれのそれらは1個以上のAUTH_DATAオブジェクトを含むかもしれません。 図1にみられるように[7]では、1個のAUTH_DATAオブジェクトが1つ以上の認証属性を含むかもしれません。 ケルベロスベースのユーザー認証のための典型的な構成はケルベロスセッションチケットを含む少なくともPolicy Locatorと属性を含んでいます。
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
* ユニコード_DN
* ASCII_DN_ENCRYPT
* DN_が暗号化するASCII_
* UNICODE_DN_ENCRYPT
* DN_が暗号化するユニコード_
Tschofenig & Graveman Informational [Page 10] RFC 4230 RSVP Security Properties December 2005
[10ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
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.
方針ロケータストリングはユーザかアプリケーション特有の方針情報の場所を見つけるのに使用されるX.500分類名(DN)です。 X.500 DNsの4つのタイプが上に記載されています。 最初の2つのタイプが、ユーザかアプリケーションDNのアイデンティティのASCIIとユニコード表現です。 2つの「暗号化された」分類名タイプがケルベロスセッションキーで暗号化されるか、ユーザのデジタル証明書(すなわち、デジタルに署名される)の秘密鍵のどちらかと共にあります。 「デジタル署名と共に暗号化された」用語は誤認しやすいです。 ユーザアイデンティティ秘密性を提供するなら、受取人の公開鍵で方針ロケータを暗号化しなければなりません。 どうこの公開鍵を得るかはドキュメントで説明されません。 この詳細は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つの暗号の資格証明書が現在、ユーザのために定義されます: ケルベロスV5[8]との認証、およびX.509[18]とPGP[19]に基づくデジタル署名の助けによる認証。 以下のリストは現在、手があいていて[7]で定義されたすべての定義された資格証明タイプを含んでいます:
+--------------+--------------------------------+
| Credential | Description |
| Type | |
+===============================================|
| ASCII_ID | User or application identity |
| | encoded as an ASCII string |
+--------------+--------------------------------+
| UNICODE_ID | User or application identity |
| | encoded as a Unicode string |
+--------------+--------------------------------+
| KERBEROS_TKT | Kerberos V5 session ticket |
+--------------+--------------------------------+
| X509_V3_CERT | X.509 V3 certificate |
+--------------+--------------------------------+
| PGP_CERT | PGP certificate |
+--------------+--------------------------------+
+--------------+--------------------------------+ | 資格証明書| 記述| | タイプ| | +===============================================| | ASCII_ID| ユーザかアプリケーションのアイデンティティ| | | ASCIIストリングとして、コード化されます。| +--------------+--------------------------------+ | ユニコード_ID| ユーザかアプリケーションのアイデンティティ| | | ユニコードストリングとして、コード化されます。| +--------------+--------------------------------+ | ケルベロス_TKT| ケルベロスV5セッションチケット| +--------------+--------------------------------+ | X509_V3_本命| X.509 V3証明書| +--------------+--------------------------------+ | PGP_本命| PGP証明書| +--------------+--------------------------------+
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
最初の2つの資格証明書が平文ストリングだけを含んでいます、そして、したがって、それらは暗号のユーザー認証を提供しません。 これらの平文ストリングはアプリケーションを特定するのに使用されるかもしれなくて、それは方針ベースの入場コントロールのために含まれています。 またはしかしながら、これらのプレーンテキスト識別子がRSVP INTEGRITYであるなら保護されるかもしれないことに注意してください。
Tschofenig & Graveman Informational [Page 11] RFC 4230 RSVP Security Properties December 2005
[11ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
INTEGRITY object of the POLICY_DATA element is present. Note
that the two INTEGRITY objects can terminate at different
entities depending on the network structure. The digital
signature may also provide protection of application
identifiers. A protected application identity (and the entire
content of the POLICY_DATA element) cannot be modified as long
as no policy-ignorant nodes are encountered in between.
POLICY_DATA要素のINTEGRITYオブジェクトは存在しています。 2個のINTEGRITYオブジェクトがネットワーク構造による異なった実体で終わることができることに注意してください。 また、デジタル署名はアプリケーション識別子の保護を提供するかもしれません。 どんな方針無知なノードも中間で遭遇しない限り、保護されたアプリケーションのアイデンティティ(そして、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.
以前に言及されているとして、ケルベロスセッションチケットはAuthenticatorのないケルベロスAP_REQメッセージ[8]のチケットです。 通常、AP_REQメッセージはサーバに認証するクライアントによって使用されます。INTEGRITYオブジェクト(例えば、POLICY_DATA要素の)はケルベロスAuthenticatorの機能性を提供します、すなわち、再生から守って、ケルベロスプロトコルに従って、ユーザがセッションキーを検索できたのを示して。 しかしながら、ケルベロスセッションがINTEGRITYオブジェクトの合わせられたメッセージダイジェスト分野に使用されたなら、唯一のこれはそうです。 [1]のセクション7はINTEGRITYオブジェクトのためのキーの設立のためにいくつかの問題について論じます。 ノードBでチケットを解読することができますが、RSVP INTEGRITYオブジェクトが異なったホストCで終わるという事実によってAUTH_DATA要素の中のケルベロスTicketの包含によるRSVP INTEGRITYオブジェクトのためのセキュリティ協会の設立は複雑にされるかもしれません。
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.
ケルベロスセッションチケットは他の多くの分野の中にセッションキーを保管しています。 また、Policy Locatorは同じセッションキーで暗号化されるかもしれません。 そのようなケルベロスサービスチケットを得るために実行される必要があるプロトコルステップは、[7]で説明されないで、いくつかの往復旅行を伴うかもしれません、多くのケルベロス関連の要素によって。 最適化として、あらゆるRSVPメッセージにケルベロスチケットは含まれる必要はありません、[1]のセクション7.1で説明されるように。 したがって、受信機は容認されたサービスチケットを保存しなければなりません。 チケットの寿命が期限が切れたなら、新しいサービスチケットを送らなければなりません。 受信機が州の情報(クラッシュか再開による)を失ったなら、それは送付者に新しいサービスチケットを再送させるIntegrity Challengeメッセージを送るかもしれません。
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
X.509 V3かPGP証明書のどちらかが方針要素に含まれているなら、デジタル署名を加えなければなりません。 全体のAUTH_DATAオブジェクトの上に計算されたデジタル署名は認証と保全保護を提供します。 デジタル署名認証属性のSubTypeはデジタル署名を計算する前のゼロに用意ができています。 反復操作による保護による新しさの保証、(どちらか
Tschofenig & Graveman Informational [Page 12] RFC 4230 RSVP Security Properties December 2005
[12ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
timestamps or sequence numbers) is provided by the digital
signature is an open issue as discussed in Section 4.3.
タイムスタンプか一連番号)、署名がセクション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].
Policy Error Objectは方針ベースの入場コントロールか他の資格証明検証の失敗の場合に使用されます。 資格証明書が満期であるなら(EXPIRED_CREDENTIALS)、現在利用可能なエラーメッセージは通知を許容します、承認プロセスが資源要求(INSUFFICIENT_PRIVILEGES)を禁じたか、または与えられたセットの資格証明書が(UNSUPPORTED_CREDENTIAL_TYPE)であることはサポートされないなら。 ネットワークによって返された最後のエラーメッセージで、ユーザのホストはサポートされた資格証明書のタイプを発見できます。 特にモバイル環境において、これは全く効率が悪いかもしれません。 その上、ユーザが異なったタイプの資格証明書をサポートするのは、ありそうもないです。 エラーメッセージIDENTITY_CHANGEDの目的は不明瞭です。 また、[7]でエラーメッセージの保護について議論しません。
3.5. RSVP Integrity Handshake
3.5. RSVP保全握手
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
Integrity Handshakeプロトコルは、墜落したか再開しているホストが受信ホストに保存された最新の有効な挑戦値を得るのを許容するように設計されました。 かぎ管理の欠如のため、2つのメッセージが同じキーがある同じ一連番号を使用しないのを保証しなければなりません。 ホストは暗号で確かめられたメッセージの最新の一連番号を保存します。 墜落しているホストが一連番号を失ったなら、敵は盗み聞かれたパケットを再演できます。 新しい一連番号をもっている本当の送付者からのシグナリングメッセージで、墜落しているホストは、一連番号分野をアップデートして、したがって、さらなる再生を防ぐでしょう。 したがって、そこです。
Tschofenig & Graveman Informational [Page 13] RFC 4230 RSVP Security Properties December 2005
[13ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
is a steady flow of RSVP-protected messages between the two hosts, an attacker may find it difficult to inject old messages, because new, authenticated messages with higher sequence numbers arrive and get stored immediately.
2人のホストの間では、攻撃者が、すぐにより高い一連番号がある新しくて、認証されたメッセージが到着して、保存されるので古いメッセージを注入するのが難しいのがわかるかもしれないというRSVPによって保護されたメッセージが定流がありますか?
The following description explains the details of an RSVP Integrity Handshake that is started by Node A after recovering from a synchronization failure:
以下の記述で、同期失敗から回復した後にNode Aによって始動されるRSVP Integrity Handshakeの細部がわかります:
Integrity Challenge
保全挑戦
(1) Message (including
+----------+ a Cookie) +----------+
| |-------------------------->| |
| Node A | | Node B |
| |<--------------------------| |
+----------+ Integrity Response +----------+
(2) Message (including
the Cookie and the
INTEGRITY object)
(1)メッセージ、(+を含んでいる、-、-、-、-、-、-、-、-、--、+ クッキー) +----------+ | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| ノードA| | ノードB| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| +----------+ 保全応答+----------+ (2) メッセージ(CookieとINTEGRITYオブジェクトを含んでいます)
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].
「挑戦クッキー」は、ローカルの秘密とタイムスタンプ[1]のMD5ハッシュになるように示されます。
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オブジェクトがプロトコル流動で見せられている状態で、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 Integrity Handshakeプロトコルを使用するのはお勧めです。
Tschofenig & Graveman Informational [Page 14] RFC 4230 RSVP Security Properties December 2005
[14ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
4. Detailed Security Property Discussion
4. 詳細なセキュリティ特性の議論
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によって提供されたメカニズムの保護について説明します、ユーザアイデンティティ秘密性、そして、シグナリングメッセージの秘密性
4.1. Network Topology
4.1. ネットワーク形態
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のデバイスは見せられません。 また、PDPが方針を検索するケルベロスKey Distributionセンターと例えば、LDAPサーバのような他のネットワーク要素は省略されます。 個々のサーバ(KDC、PDPなど)への様々なインタフェースのセキュリティは特定のネットワークサービスプロバイダーの安全保障政策にたいへんよります。
+--------+
| Policy |
+----|Decision|
| | Point +---+
| +--------+ |
| |
| |
+------+ +-+----+ +---+--+ +------+
|Client| |Router| |Router| |Client|
| A +-------+ 1 +--------+ 2 +----------+ B |
+------+ +------+ +------+ +------+
+--------+ | 方針| +----|決定| | | ポイント+---+ | +--------+ | | | | | +------+ +-+----+ +---+--+ +------+ |クライアント| |ルータ| |ルータ| |クライアント| | +-------+ 1 +--------+ 2 +----------+ B| +------+ +------+ +------+ +------+
Figure 4: Simple RSVP Architecture.
図4: 簡単なRSVPアーキテクチャ。
4.2. Host/Router
4.2. ホスト/ルータ
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
セキュリティ協会の選択がホストのIPに縛られるので、「ホスト認証」という用語は上で使用されます。
Tschofenig & Graveman Informational [Page 15] RFC 4230 RSVP Security Properties December 2005
[15ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
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で言及されるように、扱います。 かぎ管理プロトコルによるのは以前はよくこのセキュリティ協会と使用されるアイデンティティを創設していました、また、このセキュリティ協会にユーザアイデンティティを縛るのも可能です。 かぎ管理プロトコルが指定されないので、この部分を評価するのが難しく、したがって、私たちはRSVP INTEGRITYオブジェクトのためにホストのアイデンティティに基づくデータ発生源認証について話します。 ホストのアイデンティティがセキュリティ協会を選択するのに使用されるという事実はセクション3.1で既に説明されます。
Data-origin authentication is provided with a keyed hash value
computed over the entire RSVP message, excluding the keyed
message digest field itself. The security association used
between the user's host and the first-hop router is, as
previously mentioned, not established by RSVP, and it must
therefore be available before signaling is started.
全体のRSVPメッセージに関して計算された合わせられたハッシュ値をデータ発生源認証に提供します、合わせられたメッセージダイジェスト分野自体を除いて。 ユーザのホストと最初に、ホップルータの間で使用されるセキュリティ協会は以前に言及されているとRSVPによって書き立てられません、そして、したがって、シグナリングが始められる前にそれは利用可能であるに違いありません。
* Kerberos for the RSVP INTEGRITY object
* RSVP INTEGRITYオブジェクトのためのケルベロス
As described in Section 7 of [1], Kerberos may be used to
create the key for the RSVP INTEGRITY object. How to learn
the principal name (and realm information) of the other node
is outside the scope of [1]. [20] describes a way to
distribute principal and realm information via DNS, which can
be used for this purpose (assuming that the FQDN or the IP
address of the other node for which this information is
desired is known). All that is required is to encapsulate the
Kerberos ticket inside the policy element. It is furthermore
mentioned that Kerberos tickets with expired lifetime must not
be used, and the initiator is responsible for requesting and
exchanging a new service ticket before expiration.
[1]のセクション7で説明されるように、ケルベロスはRSVP INTEGRITYオブジェクトのためにキーを作成するのに使用されるかもしれません。 [1]の範囲の外にどう、もう片方のノードの主要な名前(そして、分野情報)を学ぶかがあります。 [20]はDNSを通して主体と分野情報を分配する方法を述べます。このために(この情報が望まれているもう片方のノードのFQDNかIPアドレスが知られていると仮定する)DNSを使用できます。 必要であるすべては方針要素の中でケルベロスチケットをカプセルに入れることです。 その上、満期の生涯があるケルベロスチケットを使用してはいけなくて、創始者は満了の前に新しいサービスチケットを要求して、交換するのに責任があると言及されます。
RSVP multicast processing in combination with Kerberos
involves additional considerations. Section 7 of [1] states
that in the multicast case all receivers must share a single
key with the Kerberos Authentication Server (i.e., a single
principal used for all receivers). From a personal discussion
with Rodney Hess, it seems that there is currently no other
solution available in the context of Kerberos. Multicast
handling therefore leaves some open questions in this context.
ケルベロスと組み合わせたRSVPマルチキャスト処理は追加問題にかかわります。 [1]のセクション7は、マルチキャスト場合では、すべての受信機がケルベロスAuthentication Server(すなわち、すべての受信機に使用されるただ一つの元本)と単一のキーを共有しなければならないと述べます。 ロドニー・ヘスとの個人的な議論から、ケルベロスの文脈で利用可能な他のどんなソリューションも現在ないように思えます。 したがって、マルチキャスト取り扱いはこのような関係においてはいくつかの未決問題を残します。
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メッセージを使用できます。 ノードがそのような要求を受け取るなら、応答メッセージを返さなければなりません。
Tschofenig & Graveman Informational [Page 16] RFC 4230 RSVP Security Properties December 2005
[16ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
(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 INTEGRITYオブジェクトに基づいています。 また、他の合わせられたハッシュ関数はRSVP INTEGRITYオブジェクトの中に使用されるかもしれませんが、HMAC-MD5は好まれます。 どのような場合でも、ともに交信している実体には、使用するアルゴリズムを示すセキュリティ協会がなければなりません。 交渉プロトコルが全く特定のアルゴリズムに同意するために定義されないので、しかしながら、これは難しいかもしれません。 したがって、RSVPがモバイル環境で使用されるなら、HMAC-MD5がRSVP INTEGRITYオブジェクトのための唯一の使用可能なアルゴリズムであることがありそうです。 地方の環境だけで、それは、異なった合わせられたハッシュアルゴリズムに切り替わるように役に立ちますように。 もう片方の可能な代替手段はあらゆる実装が、アルゴリズム最も重要な合わせられたハッシュが例えば、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 INTEGRITYオブジェクトに一連番号によって含まれています)。 この一連番号メカニズムの特性は[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.
Integrity Handshakeのメカニズムはセクション3.5で説明されます。 Cookie値は、ローカルの秘密とタイムスタンプのハッシュになるように示されます。 Cookie値は受信機によって確かめられません。Integrity Handshakeによって使用されたメカニズムは簡単なChallenge/応答メッセージです。(その応答メッセージは、2人のホストの間で共有されたキーがクラッシュを乗り切ると仮定します)。 しかしながら、セキュリティ協会がダイナミックに創設されるなら、この仮定は本当でないかもしれません。
Tschofenig & Graveman Informational [Page 17] RFC 4230 RSVP Security Properties December 2005
[17ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
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では、作者は、敵が挑戦クッキーを含んでいる見せかけられたIntegrity Handshakeメッセージを作成できることに注意します。 次に、それは、容認された応答を保存して、応答者がクラッシュから回復している間、これらの応答を再演しようとするか、または後で再開しようとするかもしれません。 この再演されたIntegrity Response値が有効であり、実際に使用されるより低一連番号を持っているなら、この値は回復しているホストに保存されます。 この攻撃がうまくいっているために、敵は、多くの挑戦/応答値の組を集めたか、またはクッキー世代メカニズム(例えば、ローカルの秘密を知っているのによる)を「発見したに違いありません」。 Challenge/応答組の収集はさらに難しいです、彼らが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によってサポートされません。 しかしながら、この仮定は課金データ、ネットワーク用法パターン、またはネットワーク・コンフィギュレーションを保護したがっている企業かキャリヤーのために成立しないかもしれません、ユーザのアイデンティティに加えて、盗聴とトラヒック分析から。 また、秘密性は、他のある攻撃をより難しくするのを助けるかもしれません。 例えば、攻撃者がPathErrが相当するPathメッセージを観測できないなら、セクション5.2で説明された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.
承認に関するタスクは2つの副カテゴリから成ります: ネットワークアクセス認可とRSVPは承認を要求します。 ネットワークにノードを認証するとき、アクセス認可を提供します、例えば、AAAプロトコルと組み合わせた使用しているEAP[23]。(例えば、RADIUS[24]かDIAMETER[9])。 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要求を政策決定ポイントに転送する、(例えば、入場コントロール手順が実行されるよう要求するのにCOPS[10]と[11])を使用する。
Tschofenig & Graveman Informational [Page 18] RFC 4230 RSVP Security Properties December 2005
[18ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
* 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が特定の主要な交換プロトコルを指定しないので、取り組みが、必要なセキュリティ協会を創設する必要だったと見積もっているのは難しいです。 その上、引き起こされるべき主要な交換の数はセキュリティ協会の生涯のような安全保障政策問題、主要な交換プロトコルの必要なセキュリティの特性、主要な交換プロトコルによって使用される認証モードなどに依存します。 ただ一つの管理ドメインがある静止した環境に、手動のセキュリティ協会設立は、許容できるかもしれなくて、最も良い性能の特性を提供するかもしれません。 モバイル環境で、非対称の認証方法は主要な交換プロトコルと共に使用されそうです、そして、ある種の公開鍵か証明書検証がサポートされる必要があります。
4.3. User to PEP/PDP
4.3. 気力/PDPへのユーザ
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に認証するかもしれません、ネットワークドメインか使用されるアーキテクチャによって提供されたインフラストラクチャによって。(例えば、Windows2000Operating System[25])へのRSVPとケルベロスV5の統合。 RSVPがしっかり統合している別のアーキテクチャはPacketCable組織によって指定されたものです。 興味のある読者はそれらのセキュリティー体系の議論のための[26]を参照されます。
Tschofenig & Graveman Informational [Page 19] RFC 4230 RSVP Security Properties December 2005
[19ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
(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 PATHかRESVメッセージを送るとき、このメッセージは、ユーザを認証するために何らかの情報を含むかもしれません。 [7]はユーザとアプリケーション情報がどのようにRSVPメッセージに埋め込まれているか、そして、(AUTH_DATAは反対します)どのようにそれを保護するかを説明します。 そのようなメッセージを受け取るルータは、政策決定ポイント(PDP)にクライアントを認証して、ユーザかアプリケーション情報を転送するのにこの情報を使用できます。 任意に、PDP自身はユーザを認証できます。(そのユーザは、次のセクションで説明されます)。 ユーザを認証して、保全について確かめて、再生がないかどうかチェックできるように、ルータからPDP(例えば、COPSメッセージに要素を含めるのによる)まで全体のPOLICY_DATA要素を進めなければなりません。 [7]で明確に指定されませんが、POLICY_DATA要素の中のINTEGRITYオブジェクトが他のすべての属性に伴う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]で証明書検証のための特定のメカニズムについて議論しません、そして、したがって、このためにそれらの数を使用できます。 証明書検証には、ユーザを認証しなければならないネットワーク要素(ルータか政策決定ポイント)が頻繁に証明書失効リストをダウンロードするかもしれませんか、またはOnline Certificate Statusプロトコル(OCSP)[27]とSimple Certificate Validationプロトコル(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のアイデンティティか次のホップルータが、静的に構成されるか、またはダイナミックに検索されます。 次に、PDPへのユーザー認証は考えられます。
* Kerberos-based Authentication to the PDP
* PDPへのケルベロスベースの認証
If Kerberos is used to authenticate the user, then a session
ticket for the PDP must be requested first. A user who roams
ケルベロスがユーザを認証するのに使用されるなら、最初に、PDPのセッションチケットを要求しなければなりません。 歩き回るユーザ
Tschofenig & Graveman Informational [Page 20] RFC 4230 RSVP Security Properties December 2005
[20ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
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.
同じPDPが大部分か同じ管理ドメインの中のすべての最初に、ホップルータによって使用されそうであるので、同じ管理ドメインの異なったルータの間で新しいサービスチケットを要求する必要はありません。 これはルータのセッションチケットを得なければならなくて、ルータへの認証を必要とする場合と異なっています。 したがって、ルータは単に要求をPDPに転送して、PDPによって返された政策決定を実行する受け身の役割を果たします。 付録BはユーザからPDPへの認証に関する1つの例について説明します。
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メッセージをユーザのホストに送って、公開鍵ベースの認証が使用されていないなら、メッセージは証明書とデジタル署名を含んでいません。 したがって、どんな互いの認証も想定できません。 ケルベロスの場合には、セッションキーがケルベロスチケットから検索されている状態でINTEGRITYオブジェクトが計算されている状態でPDPかルータが方針要素を伝えるか、またはまた、方針要素に含まれていたケルベロスチケットがRSVP INTEGRITYオブジェクトにセクション4.2で説明されるように使用されるなら、互いの認証は実行されるかもしれません。 前のメッセージが終わりのホストからネットワークまで送られて、そのようなキーが既に設立される場合にだけ、この手順は利きます。 参照[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 INTEGRITYオブジェクトとINTEGRITYオブジェクトは異なったノードで終わります。 基本的に、それらが最初のホップルータの代わりに政策決定ポイントで確かめられるなら、ユーザ資格証明書には、同じくらいは本当です。
* 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.
ケルベロスが最初のホップルータにユーザを認証するのに使用されるなら、ケルベロスチケットにセッションキーを含んでいるのは、方針要素のINTEGRITYオブジェクトを計算するのに使用されるかもしれません。 それは認証を提供する合わせられたメッセージダイジェストです。 AUTH_DATAオブジェクトの中のケルベロスサービスチケットの存在は新しさの認証か保証を受信ホストに提供しません。
Tschofenig & Graveman Informational [Page 21] RFC 4230 RSVP Security Properties December 2005
[21ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
Authentication and guarantee of freshness are provided by the
keyed hash value of the INTEGRITY object inside the
POLICY_DATA element. This shows that the user actively
participated in the Kerberos protocol and was able to obtain
the session key to compute the keyed message digest. The
Authenticator used in the Kerberos V5 protocol provides
similar functionality, but replay protection is based on
timestamps (or on a sequence number if the optional seq-number
field inside the Authenticator is used for KRB_PRIV/KRB_SAFE
messages as described in Section 5.3.2 of [8]).
POLICY_DATA要素の中でINTEGRITYオブジェクトの合わせられたハッシュ値で新しさの認証と保証を提供します。 これは、ユーザが活発にケルベロスプロトコルに参加して、合わせられたメッセージダイジェストを計算するために主要なセッションを得ることができたのを示します。 または、ケルベロスV5プロトコルに使用されるAuthenticatorが同様の機能性を提供しますが、反復操作による保護がタイムスタンプに基づいている、(一連番号では、Authenticatorの中の任意のseq-ナンバーフィールドがKRB_PRIV/KRBに使用されるなら、SAFEが通信する_は[8])のコネセクション5.3.2について説明しました。
* Digital Signature
* デジタル署名
If public-key-based authentication is provided, then user
authentication is accomplished with a digital signature. As
explained in Section 3.3.3 of [7], the DIGITAL_SIGNATURE
attribute must be the last attribute in the AUTH_DATA object,
and the digital signature covers the entire AUTH_DATA object.
In the case of PGP, which hash algorithm and public key
algorithm are used for the digital signature computation is
described in [19]. In the case of X.509 credentials, the
situation is more complex because different mechanisms like
CMS [29] or PKCS#7 [30] may be used for digitally signing the
message element. X.509 only provides the standard for the
certificate layout, which seems to provide insufficient
information for this purpose. Therefore, X.509 certificates
are supported, for example, by CMS or PKCS#7. [7], however,
does not make any statements about the usage of CMS or PKCS#7.
Currently, there is no support for CMS or for PKCS#7 [7],
which provides more than just public-key-based authentication
(e.g., CRL distribution, key transport, key agreement, etc.).
Furthermore, the use of PGP in RSVP is vaguely defined,
because there are different versions of PGP (including OpenPGP
[19]), and no indication is given as to which should be used.
公開鍵ベースの認証を提供するなら、デジタル署名でユーザー認証を達成します。 説明されるように、[7]、SIGNATUREがAUTH_DATAにおける最後の属性がオブジェクトであったに違いないなら結果と考えるDigital_、および.3のセクション3.3デジタルでは、署名は全体の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:
INTEGRITYオブジェクトがPOLICY_DATA要素で含められていないか、またはPDPに送られないなら、私たちは以下の観測をしなければなりません:
For the digital signature case, only the replay protection
provided by the digital signature algorithm can be used.
It is not clear, however, whether this usage was
anticipated or not. Hence, we might assume that replay
デジタル署名ケースのために、デジタル署名アルゴリズムで提供された反復操作による保護だけは使用できます。 しかしながら、この用法が予期されたかどうかは、明確ではありません。 したがって、私たちはその再生を仮定するかもしれません。
Tschofenig & Graveman Informational [Page 22] RFC 4230 RSVP Security Properties December 2005
[22ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
protection is based on the availability of the RSVP
INTEGRITY object used with a security association that is
established by other means.
保護は他の手段で設立されるセキュリティ関係と共に使用されるRSVP INTEGRITYオブジェクトの有用性に基づいています。
Including only the Kerberos session ticket is insufficient,
because freshness is not provided (because the Kerberos
Authenticator is missing). Obviously there is no guarantee
that the user actually followed the Kerberos protocol and
was able to decrypt the received TGS_REP (or, in rare
cases, the AS_REP if a session ticket is requested with the
initial AS_REQ).
新しさが提供されないので(ケルベロスAuthenticatorがなくなるので)、ケルベロスセッションチケットだけを含んでいるのは不十分です。 明らかに、ユーザが、実際にケルベロスプロトコルに従って、容認されたTGS_がREPであると解読することができたという(たまには、AS_REPはセッションチケットであるなら初期のAS_REQと共に要求されます)保証が全くありません。
(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 INTEGRITYオブジェクトで保護されます。 例えば、PEP2とPDPとのリンクは、COPSの内蔵のINTEGRITYオブジェクトを使用することによって、保護されます。 ClientとPDPの間の点線はAUTH_DATA要素によって提供された保護を示します。要素でRSVP INTEGRITYオブジェクトを全く含んでいません。
AUTH_DATA +----+
+---------------------------------------------------+PDP +-+
| +----+ |
| |
| |
| COPS |
| INTEGRITY|
| |
| |
| |
+--+---+ RSVP INTEGRITY +----+ RSVP INTEGRITY +----+ |
|Client+-------------------+PEP1+----------------------+PEP2+-+
+--+---+ +----+ +-+--+
| |
+-----------------------------------------------------+
POLICY_DATA INTEGRITY
AUTH_データ+----+ +---------------------------------------------------+ PDP++| +----+ | | | | | | 巡査| | 保全| | | | | | | +--+---+ RSVP保全+----+ RSVP保全+----+ | |クライアント+-------------------+ PEP1+----------------------+ PEP2+++--+---+ +----+ +-+--+ | | +-----------------------------------------------------+ 方針_データ保全
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
RSVP INTEGRITYオブジェクトによるホスト認証とPOLICY_DATA要素におけるINTEGRITYオブジェクトがあるユーザー認証はともに同じ反再生メカニズムを使用します。 長さ
Tschofenig & Graveman Informational [Page 23] RFC 4230 RSVP Security Properties December 2005
[23ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
the Sequence Number field, sequence number rollover, and the
Integrity Handshake have already been explained in Section 3.1.
Sequence Number分野、一連番号ロールオーバー、およびIntegrity Handshakeはセクション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オブジェクトはセキュリティ(再生)攻撃からユーザアイデンティティ情報を含む政策目的を保護するのに使用されます。」 公開鍵ベースの認証を使用するとき、RSVPベースの反復操作による保護はサポートされません、デジタル署名がSequence Number分野でPOLICY_データの保全オブジェクトをカバーしていないので。 デジタル署名は全体のAUTH_DATAオブジェクトだけをカバーしています。
The use of public key cryptography within the AUTH_DATA object
complicates replay protection. Digital signature computation
with PGP is described in [31] and in [19]. The data structure
preceding the signed message digest includes information about
the message digest algorithm used and a 32-bit timestamp of when
the signature was created ("Signature creation time"). The
timestamp is included in the computation of the message digest.
The IETF standardized version of OpenPGP [19] contains more
information and describes the different hash algorithms (MD2,
MD5, SHA-1, RIPEMD-160) supported. [7] does not make any
statements as to whether the "Signature creation time" field is
used for replay protection. Using timestamps for replay
protection requires different synchronization mechanisms in the
case of clock-skew. Traditionally, these cases assume "loosely
synchronized" clocks but also require specifying a replay window.
AUTH_DATAオブジェクトの中の公開鍵暗号の使用は反復操作による保護を複雑にします。 PGPとのデジタル署名計算は[31]と[19]で説明されます。 署名しているメッセージダイジェストに先行するデータ構造は使用されるメッセージダイジェストアルゴリズムと署名が作成された時に関する32ビットのタイムスタンプ(「署名作成時間」)に関して情報を含んでいます。 タイムスタンプはメッセージダイジェストの計算に含まれています。 IETFはOpenPGP[19]のバージョンを標準化しました。詳しい情報を含んでいて、アルゴリズム(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].
ケルベロスチケットの寿命はチケットの中にEncTicketPart構造の分野のstarttimeとendtimeに基づいています、[8]についてセクション5.3.1で説明されるように。 チケットが検証実体のネットワークに位置するKDCによって作成されるので、生涯検証の目的のために時計をおよそ連動させるのは難しくはありません。 [32]で時計同期に関する追加情報とケルベロスを見つけることができます。
Tschofenig & Graveman Informational [Page 24] RFC 4230 RSVP Security Properties December 2005
[24ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
If the lifetime of the Kerberos ticket expires, then a new ticket
must be requested and used. Rekeying is implemented with this
procedure.
ケルベロスチケットの寿命が期限が切れるなら、新しいチケットを要求されていて、使用しなければなりません。 Rekeyingはこの手順で実装されます。
(4) (User Identity) Confidentiality
(4) (ユーザアイデンティティ)秘密性
This section discusses privacy protection of identity information
transmitted inside the policy element. User identity
confidentiality is of particular interest because there is no
built-in RSVP mechanism for encrypting the POLICY_DATA object or
the AUTH_DATA elements. Encryption of one of the attributes
inside the AUTH_DATA element, the POLICY_LOCATOR attribute, is
discussed.
このセクションは方針要素の中で伝えられたアイデンティティ情報のプライバシー保護について論じます。 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).
ユーザのプライバシーを保護するために、敵へのユーザのアイデンティティがユーザのホストと最初に、ホップルータ(例えば、ワイヤレスのリンクの)の間で場所を見つけられたのを明らかにしないのは重要です。 その上、訪問されたネットワーク内の提供者のドメインの外でユーザアイデンティティを伝えるべきではありません。 すなわち、方針データ要素におけるユーザアイデンティティ情報は、シグナリング経路に沿った他の(権限のない)の実体にコンテンツを明らかにするのを防ぐようにPDPによって取り除かれるはずであるか、または変更されるはずです。 それが最初の方針意識しているRSVPノード(または一般に、付属ネットワークに)に目に見えないような方法でユーザのアイデンティティを隠すのは可能ではありません(提供されたメカニズムがある)。
The ASCII or Unicode distinguished name of the user or
application inside the POLICY_LOCATOR attribute of the AUTH_DATA
element may be encrypted as specified in Section 3.3.1 of [7].
The user (or application) identity is then encrypted with either
the Kerberos session key or with the private key in case of
public-key-based authentication. When the private key is used,
we usually speak of a digital signature that can be verified by
everyone possessing the public key. Because the certificate with
the public key is included in the message itself, decryption is
no obstacle. Furthermore, the included certificate together with
the additional (unencrypted) information in the RSVP message
provides enough identity information for an eavesdropper. Hence,
the possibility of encrypting the policy locator in case of
public-key-based authentication is problematic. To encrypt the
identities using asymmetric cryptography, the user's host must be
able somehow to retrieve the public key of the entity verifying
the policy element (i.e., the first policy-aware router or the
PDP). Then, this public key could be used to encrypt a symmetric
key, which in turn encrypts the user's identity and certificate,
as is done, e.g., by PGP. Currently, no such mechanism is
defined in [7].
ユーザのASCIIかユニコード分類名かセクション3.3.1で指定されるように暗号化されていて、AUTH_DATA要素のPOLICY_LOCATOR属性がそうするかもしれない[7]のアプリケーション内部。 そして、ユーザ(または、アプリケーション)のアイデンティティはケルベロスセッションキーか公開鍵ベースの認証の場合の秘密鍵で暗号化されます。 秘密鍵が使用されているとき、通常、私たちは皆が公開鍵を持ちながら確かめることができるデジタル署名について話します。 公開鍵がある証明書がメッセージ自体に含まれているので、復号化は障害ではありません。 その上、RSVPメッセージの追加している(非暗号化される)情報に伴う含まれている証明書は十分なアイデンティティ情報を立ち聞きする者に提供します。 したがって、公開鍵ベースの認証の場合に方針ロケータを暗号化する可能性は問題が多いです。 非対称の暗号、ユーザのホストを使用することでアイデンティティを暗号化するのは、方針要素(すなわち、最初の方針意識しているルータかPDP)について確かめる実体の公開鍵を検索するためにどうにかできなければなりません。 次に、順番にしていた状態でユーザのそのままなアイデンティティと証明書を暗号化する対称鍵を暗号化するのにこの公開鍵を使用できました、例えば、PGP。 現在、どんなそのようなメカニズムも[7]で定義されません。
Tschofenig & Graveman Informational [Page 25] RFC 4230 RSVP Security Properties December 2005
[25ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
The algorithm used to encrypt the POLICY_LOCATOR with the
Kerberos session key is assumed to be the same as the one used
for encrypting the service ticket. The information about the
algorithm used is available in the etype field of the
EncryptedData ASN.1 encoded message part. Section 6.3 of [8]
lists the supported algorithms. [33] defines newer encryption
algorithms (Rijndael, Serpent, and Twofish).
ケルベロスセッションキーでPOLICY_LOCATORを暗号化するのに使用されるアルゴリズムがサービスチケットを暗号化するのに使用されるものと同じであると思われます。 使用されるアルゴリズムの情報はEncryptedData ASN.1のコード化されたメッセージ部分のetype分野で利用可能です。 [8]のセクション6.3はサポートしているアルゴリズムを記載します。[33]は、より新しい暗号化アルゴリズム(ラインダール、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.
また、ユーザアイデンティティ秘密性を評価するのは、RSVPの外で実行されたプロトコルを見るのを必要とします(例えば、ケルベロスは議定書を作ります)。 CREDENTIAL属性にチケットを含んでいると、ユーザアイデンティティ保護は、Ticketの非暗号化された部分の中に任意のcname属性を含んでいないことによって、提供されるかもしれません。 AuthenticatorがRSVPメッセージで伝えられないので、Authenticatorの非暗号化された部分のcnameとcrealmは明らかにされません。 ユーザがCREDENTIAL属性での包含のケルベロスセッションチケットを要求するように、ケルベロスプロトコル交換を実行しなければなりません。 そして、TGS_REQと共に送られたAuthenticatorはユーザのアイデンティティを明らかにします。 また、AS_REQはケルベロスAuthentication Serverがユーザの秘密鍵で暗号化されるAS_REPメッセージで反応するのを許容するユーザのアイデンティティを含まなければなりません。 ケルベロスを使用して、したがって、単にこの値がケルベロス主体名と異なっている場合にだけ役に立つ暗号化された方針ロケータの内容を隠すのは可能です。 したがって、ケルベロスを使用して、ユーザアイデンティティ秘密性を提供するのは「完全に」可能ではありません。
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
Hostからルータへのインタフェースの承認ステップの記述に加えて、ユーザベースの承認はユーザ資格証明書であるなら方針要素で実行されます。 ユーザとアプリケーション特殊情報の包含は専用サーバに保存されそうな特別なユーザ方針で方針ベースの入場コントロールを可能にします。したがって、Policy Decision Pointはaのために例えばLDAPサーバについて質問できます。
Tschofenig & Graveman Informational [Page 26] RFC 4230 RSVP Security Properties December 2005
[26ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
service level agreement that states the amount of resources a
certain user is allowed to request. In addition to the user
identity information, group membership and other non-security-
related information may contribute to the evaluation of the final
policy decision. If the user is not registered to the currently
attached domain, then there is the question of how much
information the home domain of the user is willing to exchange.
This also impacts the user's privacy policy.
確信しているユーザが要求できるリソースの量を述べる平らな協定を修理してください。 グループ会員資格の、そして、他のユーザアイデンティティ情報に加えた非、-セキュリティに関連する情報は最終的な政策決定の評価に貢献するかもしれません。 ユーザが現在付属しているドメインに登録されないなら、どのくらいの情報を交換するかに関する構わないユーザのホームドメインが、思っている質問があります。 また、これはユーザのプライバシーに関する方針に影響を与えます。
In general, the user may not want to distribute much of this
policy information. Furthermore, the lack of a standardized
authorization data format may create interoperability problems
when exchanging policy information. Hence, we can assume that
the policy decision point may use information from an initial
authentication and key agreement protocol (which may have already
required cross-realm communication with the user's home domain,
if only to show that the home domain knows the user and that the
user is entitled to roam), to forward accounting messages to this
domain. This represents the traditional subscriber-based
accounting scenario. Non-traditional or alternative means of
access might be deployed in the near future that do not require
any type of inter-domain communication.
一般に、ユーザはこの方針情報の多くを分配したがっていないかもしれません。 方針情報を交換するとき、その上、標準化された承認データの形式の不足は相互運用性問題を生じさせるかもしれません。 したがって、私たちは、政策決定ポイントが会計メッセージをこのドメインに転送するのに初期の認証と主要な協定プロトコル(ユーザが知って、ユーザが権利を与えられるホームドメインが移動するのを示すために唯一なら、ユーザのホームドメインとの既に必要な交差している分野コミュニケーションを持っているかもしれない)からの情報を使用するかもしれないと思うことができます。 これは伝統的な加入者ベースの会計シナリオを表します。 アクセスの非伝統的であるか代替の手段は相互ドメインコミュニケーションをどんなタイプにも要求しない近い将来、配布されるかもしれません。
Additional discussions are required to determine the expected
authorization procedures. [34] and [35] discuss authorization
issues for QoS signaling protocols. Furthermore, a number of
mobility implications for policy handling in RSVP are described
in [36].
追加議論が、予想された承認手順を決定するのに必要です。 [34]と[35]はQoSシグナリングプロトコルのために承認問題について議論します。 その上、RSVPの方針取り扱いのための多くの移動性含意が[36]で説明されます。
(6) Performance
(6) パフォーマンス
If Kerberos is used for user authentication, then a Kerberos
ticket must be included in the CREDENTIAL Section of the
AUTH_DATA element. The Kerberos ticket has a size larger than
500 bytes, but it only needs to be sent once because a
performance optimization allows the session key to be cached as
noted in Section 7.1 of [1]. It is assumed that subsequent RSVP
messages only include the POLICY_DATA INTEGRITY object with a
keyed message digest that uses the Kerberos session key.
However, this assumes that the security association required for
the POLICY_DATA INTEGRITY object is created (or modified) to
allow the selection of the correct key. Otherwise, it difficult
to say which identifier is used to index the security
association.
ケルベロスがユーザー認証に使用されるなら、AUTH_DATA要素のCREDENTIALセクションにケルベロスチケットを含まなければなりません。 ケルベロスチケットでサイズは500バイトより大きくなりますが、それは、パフォーマンスの最適化が、[1]のセクション7.1に述べられるようにセッションキーがキャッシュされるのを許容するので一度送られる必要があるだけです。 その後のRSVPメッセージがケルベロスセッションキーを使用する合わせられたメッセージダイジェストがあるPOLICY_データの保全オブジェクトを含んでいるだけであると思われます。 しかしながら、これは、POLICY_データの保全オブジェクトに必要であるセキュリティ協会が正しいキーの選択を許すために創設される(または、変更される)と仮定します。 そうでなければ、それ、どの識別子がセキュリティ協会に索引をつけるのに使用されるかを言うのは難しいです。
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
ケルベロスがその時認証システムとして使用されるなら、性能見解から、セッションキーを入手する交換処理は、考えられる必要があります、交換専用ですが
Tschofenig & Graveman Informational [Page 27] RFC 4230 RSVP Security Properties December 2005
[27ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
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.
セッションチケットの生涯一度するのが必要です。 これは速いローミングユーザのホストに特にモバイル環境で当てはまります。
Public-key-based authentication usually provides the best
scalability characteristics for key distribution, but the
protocols are performance demanding. A major disadvantage of the
public-key-based user authentication in RSVP is the lack of a
method to derive a session key. Hence, every RSVP PATH or RESV
message includes the certificate and a digital signature, which
is a huge performance and bandwidth penalty. For a mobile
environment with low power devices, high latency, channel noise,
and low-bandwidth links, this seems to be less encouraging. Note
that a public key infrastructure is required to allow the PDP (or
the first-hop router) to verify the digital signature and the
certificate. To check for revoked certificates, certificate
revocation lists or protocols like the Online Certificate Status
Protocol [27] and the Simple Certificate Validation Protocol [28]
are needed. Then the integrity of the AUTH_DATA object can be
verified via the digital signature.
公開鍵ベースの認証は通常最も良いスケーラビリティの特性を主要な分配に提供しますが、プロトコルは性能要求です。 RSVPの公開鍵ベースのユーザー認証の主要な不都合はセッションキーを引き出すメソッドの不足です。 したがって、あらゆるRSVP PATHかRESVメッセージが証明書とデジタル署名を含んでいます。(それは、膨大な性能と帯域幅刑罰です)。 低いパワーデバイス、高い潜在、チャンネル雑音、および低バンド幅リンクがあるモバイル環境に関しては、これはそれほど励みにならないように思えます。 公開鍵認証基盤がPDP(または、最初に、ホップルータ)がデジタル署名と証明書について確かめるのを許容するのに必要であることに注意してください。 取り消された証明書がないかどうかチェックするために、Online Certificate Statusプロトコル[27]とSimple Certificate Validationプロトコル[28]のような証明書失効リストかプロトコルが必要です。 そして、デジタル署名でAUTH_DATAオブジェクトの保全について確かめることができます。
4.4. Communication between RSVP-Aware Routers
4.4. RSVP意識しているルータのコミュニケーション
(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 INTEGRITYオブジェクトで再演されます。 ルータの間のRSVPメッセージ流動は信頼のチェーンに基づいて保護されます、そして、したがって、各ルータは隣接しているルータとのセキュリティ協会だけを必要とします。 この仮定は性能利点のためユーザー・ホストが全く直接配属されないコアネットワークの特別担保の特性のでされました。 コアネットワークでは、ネットワーク構造は頻繁に変化しません、そして、RSVP INTEGRITYオブジェクトのための共有秘密キーの手動の分配は許容できるかもしれません。 共有秘密キーは、SNMPv3のような適切に機密保護しているネットワーク管理プロトコルを使用することによって、手動で構成されるか、または分配されるかもしれません。
Independent of the key distribution mechanism, host
authentication with built-in RSVP mechanisms is accomplished
using the keyed message digest in the RSVP INTEGRITY object,
computed using the previously exchanged symmetric key.
主要な分配メカニズムから独立しています、RSVPメカニズム内蔵ホスト認証は以前に交換された対称鍵を使用することで計算されたRSVP INTEGRITYオブジェクトで合わせられたメッセージダイジェストを使用するのに優れています。
(2) Integrity Protection
(2) 保全保護
Integrity protection is accomplished with the RSVP INTEGRITY
object with the variable length Keyed Message Digest field.
保全保護は可変長Keyed Message Digest分野があるRSVP INTEGRITYオブジェクトで実行されます。
Tschofenig & Graveman Informational [Page 28] RFC 4230 RSVP Security Properties December 2005
[28ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
(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オブジェクトによる反復操作による保護は前項で手広く説明されます。 墜落しているホストが使用される最新の一連番号を学ぶのを可能にするために、Integrity Handshakeメカニズムを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 INTEGRITYオブジェクトが伝えられたシグナリングメッセージの合わせられたメッセージダイジェストを計算するのに使用されるだけであるので。
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.
より容易にすなわち、コアネットワーク、個々のルータ(ユーザのホストと最初に、ホップルータとのセキュリティ仲間か一般に、付属ネットワークとの比較における)の間のセキュリティ協会を設立できる、通常強いのは仮定を信じます。 その上、頻繁な「再-合わせ」ることを避けるのに増強された生涯とのセキュリティ協会を使用するのは可能です。 したがって、ユーザからネットワーク・インターフェースと比べて、性能には、より少ない影響があります。 また、セキュリティ協会ストレージ要件もそれほど問題が多くはありません。
5. Miscellaneous Issues
5. 種々雑多な問題
This section describes a number of issues that illustrate some of the shortcomings of RSVP with respect to security.
このセクションはセキュリティに関してRSVPの短所のいくつかを例証する多くの問題について説明します。
Tschofenig & Graveman Informational [Page 29] RFC 4230 RSVP Security Properties December 2005
[29ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
5.1. First-Hop Issue
5.1. 最初に、ホップ問題
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のためにサポートされません。
5.2. Next-Hop Problem
5.2. 次のホップ問題
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ノードがどのノードが次のホップであるかを知っていると仮定する場合では、以下のプロトコル交換は起こることができます:
Tschofenig & Graveman Informational [Page 30] RFC 4230 RSVP Security Properties December 2005
[30ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
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 |
+------+
保全(<>C)+------+ (3) | RSVP| +------------->+ノード| | | B| 保全| +--+---+ (<>C)| | +------+ (2) +--+----+ | (1) | RSVP+----------->+ルータ| | 誤り----->| ノード| | + または、<。-----------+(私はBです)| +<。-----------+ ネットワーク| (4) +------+ (5) +--+----+ 誤り. (私はBです)+------+ . | RSVP| ...............+ ノード| | C| +------+
Figure 6: Next-Hop Issue.
図6: 次のホップ問題。
When RSVP node A in Figure 6 receives an incoming RSVP Path message, standard RSVP message processing takes place. Node A then has to decide which key to select to protect the signaling message. We assume that some unspecified mechanism is used to make this decision. In this example, node A assumes that the message will travel to RSVP node C. However, for some reasons (e.g., a route change, inability to learn the next RSVP hop along the path, etc.) the message travels to node B via a non-RSVP supporting router that cannot verify the integrity of the message (or cannot decrypt the Kerberos service ticket). The processing failure causes a PathErr message to be returned to the originating sender of the Path message. This error message also contains information about the node that recognized the error. In many cases, a security association might not be available. Node A receiving the PathErr message might use the information returned with the PathErr message to select a different security association (or to establish one).
図6のRSVPノードAが入って来るRSVP Pathメッセージを受け取るとき、標準のRSVPメッセージ処理は行われます。 そして、ノードAは、シグナリングメッセージを保護するのをどのキーを選択したらよいかを決めなければなりません。 私たちは、何らかの不特定のメカニズムがこの決定をするのに使用されると思います。 この例では、ノードAは、メッセージがRSVPノードC.Howeverに移動すると仮定します、メッセージがメッセージ(または、ケルベロスサービスチケットを解読することができない)の保全について確かめることができないルータをサポートしながら非RSVPを通ってノードBに移動するいくつかの理由(例えば、ルート変化、経路に沿って次のRSVPホップを学ぶことができないことなど)で。 処理失敗はPathメッセージの起因している送付者に返されるべきPathErrメッセージを引き起こします。 また、このエラーメッセージは誤りを認識したノードの情報を含んでいます。 多くの場合、セキュリティ協会は利用可能でないかもしれません。 PathErrメッセージを受け取るノードAは異なったセキュリティ協会を選択する(1つを証明するために)PathErrメッセージと共に返された情報を使用するかもしれません。
Figure 6 describes a behavior that might help node A learn that an error occurred. However, the description in Section 4.2 of [1] states in step (5) that a signaling message is silently discarded if the receiving host cannot properly verify the message: "If the calculated digest does not match the received digest, the message is discarded without further processing." For RSVP Path and similar messages, this functionality is not really helpful.
図6はノードAが、誤りが発生したことを学ぶのを助けるかもしれない振舞いについて説明します。 しかしながら、[1]のセクション4.2における記述は、ステップ(5)に受信ホストが適切にメッセージについて確かめることができないならシグナリングメッセージが静かに捨てられると述べます: 「計算されたダイジェストが受け取られていているダイジェストに合っていないなら、メッセージはさらなる処理なしで捨てられます。」 RSVP Pathと同様のメッセージに関しては、この機能性は本当に有用ではありません。
Tschofenig & Graveman Informational [Page 31] RFC 4230 RSVP Security Properties December 2005
[31ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
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 Pathメッセージは多くの機能を提供します: 経路発見、ルートを検出するのは変化します、経路に沿ったQoS能力の発見がAdspecオブジェクト(何らかの解釈がある)、次のホップ発見、およびことによるとセキュリティ協会設立(例えばケルベロスの場合で)を使用して。
From a security point of view, there are conflicts between:
セキュリティ観点から、闘争は以下の間で来ています。
o Idempotent message delivery and efficiency
o ベキ等元メッセージ配送と効率
The RSVP Path message especially performs a number of functions.
Supporting idempotent message delivery somehow contradicts with
security association establishment, efficient message delivery,
and message size. For example, a "real" idempotent signaling
message would contain enough information to perform security
processing without depending on a previously executed message
exchange. Adding a Kerberos ticket with every signaling message
is, however, inefficient. Using public-key-based mechanisms is
even more inefficient when included in every signaling message.
With public-key-based protection for idempotent messages, there is
the additional risk of introducing denial-of-service attacks.
RSVP Pathメッセージは多くの機能を特に実行します。 どうにかベキ等元メッセージ配送をサポートするのはセキュリティ協会設立、効率的なメッセージ配送、およびメッセージサイズで反駁します。 例えば、「本当」のベキ等元シグナリングメッセージは以前に実行された交換処理によらないでセキュリティ処理を実行できるくらいの情報を含んでいるでしょう。 しかしながら、あらゆるシグナリングメッセージでケルベロスチケットを加えるのは効率が悪いです。 あらゆるシグナリングメッセージに含まれていると、公開鍵ベースのメカニズムを使用するのはさらに効率が悪いです。 ベキ等元メッセージのための公開鍵ベースの保護と共に、導入サービス不能攻撃の追加リスクがあります。
o RSVP Path message functionality and next-hop discovery
o RSVP Pathメッセージの機能性と次のホップ発見
To protect an RSVP signaling message (and an RSVP Path message in
particular) it is necessary to know the identity of the next
RSVP-aware node (and some other parameters). Without a mechanism
for next-hop discovery, an RSVP Path message is also responsible
for this task. Without knowing the identity of the next hop, the
Kerberos principal name is also unknown. The so-called Kerberos
user-to-user authentication mechanism, which would allow the
receiver to trigger the process of establishing Kerberos
authentication, is not supported. This issue will again be
discussed in relationship with the last-hop problem.
RSVPシグナリングメッセージ(そして、特にRSVP Pathメッセージ)を保護するために、次のRSVP意識しているノード(そして、ある他のパラメタ)のアイデンティティを知るのが必要です。 また、次のホップ発見のためのメカニズムがなければ、RSVP Pathメッセージもこのタスクに原因となります。 また、次のホップのアイデンティティを知らないで、ケルベロス主体名も未知です。 ケルベロスユーザからユーザー認証へのいわゆるメカニズム(受信機はケルベロス認証を確立するプロセスの引き金となることができる)はサポートされません。 再び最後のホップ問題との関係でこの問題について議論するでしょう。
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-
RSVPをサポートしているノードにはすべてのすぐに隣接しているRSVPノードとのセキュリティ協会がないかもしれないと仮定するのは公正です。 特にファイアウォールシグナリングなどの相互ドメインシグナリング、DiffServの上のIntServ、または新しいいくつかのアプリケーションにおいて、次のRSVPの意識しているノードはあらかじめ、知られていないかもしれません。 それらが多くの非RSVPの意識しているノードによって切り離されるなら、次のRSVPノードの数はかなり大きいかもしれません。 したがって、RSVP Pathメッセージを送るノードは、両方の次のRSVPノード(すなわち、シグナリングメッセージに追加されて、送付先アドレスに扱われたRouter Alert Option)を検出して、ルート変化を検出するためにメカニズムとして機能するなら適切にメッセージを保護することにおける苦境に陥るかもしれません。 イントラでそれに注意するのは公正です。
Tschofenig & Graveman Informational [Page 32] RFC 4230 RSVP Security Properties December 2005
[32ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
domain case with a dense distribution of RSVP nodes, protection
might be possible with manual configuration.
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メッセージでRSVPノードを絶え間なくあふれさせるのを防ぎません、既存の、そして、利用可能なセキュリティ関係と共にPathErrメッセージを保護するのが可能であるかもしれませんが。 正統のRSVPノードは、経路の変化が起こったと信じているでしょう。 したがって、このノードは、異なったセキュリティ協会を選択しようとするか、または示されたノードで1つを作成しようとするかもしれません。 また、敵が経路に沿ったどこかに位置していて、認証か承認のどちらかが必要な強さと精度で実行されないなら、中央の男性として機能するのも可能であるかもしれません。 この攻撃に敏感さを減少させる1つのメソッドは以下の通りです: セキュリティ協会が全く存在しないノードからPathErrメッセージを受け取るときには、セキュリティ協会を設立して、次に、PathErrメッセージにつながった動作を繰り返すのを試みてください。
5.3. Last-Hop Issue
5.3. 最後のホップ問題
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パーティープロトコルで実行されるとき、このセクションは実用的な困難を扱おうとします。 ケルベロスは、そのようなプロトコルとまた、ダイナミックなセッション主要な設立をRSVPに供給する唯一のサポートしているプロトコルです。 最初に、ホップコミュニケーションに関しては、ユーザと何らかのルータ(例えば、アクセスルータ)の間で通常認証します。 特にモバイル環境で、彼らのIPに基づく終わりのホストかMACアドレスを認証するのは可能ではありません。 この問題を例証するために、ケルベロスのための典型的な処理ステップは最初に、ホップコミュニケーションのために示されます:
(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.This実体Bのアイデンティティ(すなわち、ケルベロス主体名)が次のRSVPノード、PDPか方針意識しているRSVPノードのどちらかであることを次の学びます。
(2) Entity A then requests a ticket granting ticket for the network
domain. This assumes that the identity of the network domain is
known.
(2) そして、実体Aはネットワークドメインのチケットを与えるチケットを要求します。 これは、ネットワークドメインのアイデンティティが知られていると仮定します。
(3) Entity A then requests a service ticket for entity B, whose name
was learned in step (1).
(3) そして、実体Aは実体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シグナリングメッセージ(政策目的の中の)があるサービスチケットを含んでいます。 ケルベロスセッションキーは、全体のRSVPシグナリングメッセージの保全を保護するのに使用されます。
Tschofenig & Graveman Informational [Page 33] RFC 4230 RSVP Security Properties December 2005
[33ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
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でサポートされません。
5.4. RSVP- and IPsec-Protected Data Traffic
5.4. RSVPとIPsecによって保護されたデータ通信量
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-tuple(ソースIPアドレス、送付先IPアドレス、トランスポート・プロトコルタイプ、ソースポート、および仕向港)に基づく流れ識別子を通常確立します。 この5-tuple情報が利用可能でないなら、他の識別子は使用されなければなりません。 超能力で暗号化されたデータ通信量はトランスポート・プロトコルとポートナンバーがアクセスしやすくないそのような例です。 したがって、IPsec SPIはそれらの代用品として使用されます。 [12]によってRSVPのためにこれらのIPsec含意を考えて、3つの仮定に基礎づけられています:
(1) An end host that initiates the RSVP signaling message exchange
has to be able to retrieve the SPI for a given flow. This
requires some interaction with the IPsec security association
database (SAD) and security policy database (SPD) [3]. An
application usually does not know the SPI of the protected flow
and cannot provide the desired values. It can provide the
signaling protocol daemon with flow identifiers. The signaling
daemon would then need to query the SAD by providing the flow
identifiers as input parameters and receiving the SPI as an
output parameter.
(1) RSVPシグナリング交換処理に着手する終わりのホストは与えられた流れのためにSPIを検索できなければなりません。 これはIPsecセキュリティ協会データベース(SAD)と安全保障政策データベース(SPD)[3]とのいくつかの相互作用を必要とします。 アプリケーションは、通常、保護された流れについてSPIを知らないで、目標値を提供できません。 それはシグナリングプロトコルデーモンに流れ識別子を提供できます。 そして、シグナリングデーモンは、入力パラメタとして流れ識別子を提供して、出力パラメタとしてSPIを受けることによってSADについて質問する必要があるでしょう。
(2) [12] assumes end-to-end IPsec protection of the data traffic. If
IPsec is applied in a nested fashion, then parts of the path do
not experience QoS treatment. This can be treated as a problem
of tunneling that is initiated by the end host. The following
figure better illustrates the problem in the case of enforcing
secure network access:
(2) [12]は、終わりから終わりへのIPsecがデータ通信量の防護物であると仮定します。 IPsecが入れ子にされたファッションで適用されるなら、経路の地域はQoS処理になりません。 終わりのホストによって開始されるトンネリングの問題としてこれを扱うことができます。 以下の図は安全なネットワークアクセスを実施する場合で問題を例証するほうがよいです:
Tschofenig & Graveman Informational [Page 34] RFC 4230 RSVP Security Properties December 2005
[34ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
+------+ +---------------+ +--------+ +-----+
| 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---> |
| | | |
+------+ +---------------+ +--------+ +-----+ | ホスト| | セキュリティ| | ルータ| | ホスト| | A| | ゲートウェイ(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) | | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|、|、| --保護のないデータ通信量--->|、|、|、|、|
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は3tuple<A、SGW、SPI1>または5-tuple<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].
シグナリングの1つでエンドポイント(例えば、2つのネットワークの間の)を始めでない、また終えないIPsecトンネルは、IPsecトンネルへのRSVPシグナリング交換を再帰的に適用することによって、異なって扱われるべきです。 トンネルの中で合図するRSVPが[13]で扱われます。
Tschofenig & Graveman Informational [Page 35] RFC 4230 RSVP Security Properties December 2005
[35ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
(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) SPIsが確立した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には、より長い寿命が通常あるので、これは主要な問題であるように思えません。 トラフィックが、IPsec SA(そして、SPI)変化が反映するのをよりしばしば必要とするかもしれないSCTPデータのIPsec保護は、SCTP協会からIPアドレスを加えて、取り除きました。
5.5. End-to-End Security Issues and RSVP
5.5. 終わりから終わりへの安全保障問題とRSVP
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人の任意のホストの間では、これはかなり難しいと判明するかもしれません。 2番目に、終わりから終わりへのセキュリティの有用性はRSVPが配布されるアーキテクチャに依存します。 RSVPが使用されて、QoS情報にネットワークに合図する他のプロトコルがあらかじめパラメタを交渉して、どの実体がQoSの予約のために請求されるかを決めるために実行されなければならないなら、終わりから終わりへのどんなセキュリティも必要でありそうにはありません。 終わりから終わりへのセキュリティをRSVPに紹介するのは次に、RSVPプロキシ[37](Localized RSVP[38])のような拡大に関する原因問題と経路に沿ったどこかで目的地終わりのホストに届かないでRSVPシグナリングを終える他のものがそうするでしょう。 そして、介入者攻撃としてそのような振舞いを解釈できました。
5.6. IPsec Protection of RSVP Signaling Messages
5.6. RSVPシグナリングメッセージのIPsec保護
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.
それ中でまた、IPsec[3]がホップごとの2つの隣接しているRSVPノードの間のファッションでRSVPシグナリングメッセージを保護できると思われます。 しかしながら、RSVPはシグナリングメッセージの特別な処理を使用します。(それは、IPsec保護を複雑にします)。 このセクションで説明されるように、IPsecは二地点間通信環境における、RSVPシグナリングメッセージの保護に使用されるだけであるべきです(すなわち、RSVPメッセージはことによると1以上ではなく、1つのRSVPルータしか達することができません)。 この制限はメッセージ配送と発見にただ一つのメッセージに合図する組み合わせでもたらされます。 その上、終わりから終わりへのアドレシングはIPsec取り扱いをかなり複雑にします。 このセクションはこれらの少なくともいくつかの複雑さについて説明します。
Tschofenig & Graveman Informational [Page 36] RFC 4230 RSVP Security Properties December 2005
[36ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
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メッセージは生のIPパケットとしてプロトコル番号46で送られます。 [6]のAppendix Cで説明されるUDPでそれらをカプセル化するのは可能であるかもしれません。 いくつかのRSVPメッセージ(経路、PathTear、およびResvConf)で、IPヘッダーでRouter Alert IP Optionを用意ができさせなければなりません。 これらのメッセージは経路に沿った次のRSVPノードではなく、(ユニキャストかマルチキャスト)送付先アドレスに扱われます。 したがって、IPsecトラフィックセレクタはIPsec SA選択にこれらの分野を使用できるだけです。 ただ一つの経路しかなければ(それに沿ったことによるとすべてのトラフィックが保護されます)、シグナリングメッセージのIPsec保護のための問題が全くありません。 このタイプの保護は、一般的でなく、終わりのホストとその最初に、ホップルータの間のネットワークアクセスを保証するのに使用されるだけであるかもしれません。 説明されたRSVPメッセージが次のRSVPノードの代わりに送付先アドレスに扱われるので、交通機関でIPsec超能力[17]かAH[16]を使用するのは可能ではありません--トンネルモードによる唯一のIPsecが可能です。
If an RSVP message can taket more than one possible path, then the IPsec engine will experience difficulties protecting the message. Even if the RSVP daemon installs a traffic selector with the destination IP address, still, no distinguishing element allows selection of the correct security association for one of the possible RSVP nodes along the path. Even if it possible to apply IPsec protection (in tunnel mode) for RSVP signaling messages by incorporating some additional information, there is still the possibility that the tunneled messages do not recognize a path change in a non-RSVP router. In this case the signaling messages would simply follow a different path than the data.
1つの可能な経路より多くのtaket、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.
IPsecはRESVのようなRSVPメッセージを保護できます、次の様々な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つの利益がイケ[39]、KINK[40]かIKEv2[41]のどちらかを使用するかぎ管理の有用性です。
5.7. Authorization
5.7. 承認
[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
[34]は2つの信頼モデル(ニュージャージーTurnpikeとニュージャージーパークウェイ)と2つの承認モデル(セッションとチャンネルあたりの金銭的解決)について説明します。 ニュージャージーTurnpikeモデルは近く跳びホップのための正当化に機密保持を与えます。 異なった信頼モデルは詳細に説明されませんが、RSVPはニュージャージーTurnpikeモデルに焦点を合わせます。 RSVPは、ニュージャージーパークウェイモデルとチャンネルが金銭的解決であるとある程度だけサポートします。 ユーザ(または、終わりのホスト)の認証にユーザアイデンティティ表現を提供できます。
Tschofenig & Graveman Informational [Page 37] RFC 4230 RSVP Security Properties December 2005
[37ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
mechanism, but authentication might, in many cases, be insufficient for authorization. The communication procedures defined for policy
多くの場合、承認に、しかし、メカニズム、認証は不十分であるかもしれません。 方針のために定義された通信規定
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]を改良できる、-、相互ドメインネットワークの間でシグナリングメッセージ粒状で方針取り扱いを避けるチャンネル金銭的解決モデル。 また、[43]からRSVPの方針取り扱いの予想された振舞いに関する追加情報を得ることができます。
[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]で。
6. Conclusions
6. 結論
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.
実用的なプロトコル経験と、そして、セキュリティに関する増強された認識から学習できることは何人かの手があいている資格証明タイプが他のものより多くの承認を受けたということです。 ケルベロスは今日多くのIETFプロトコルと統合されるシステムです。 しかしながら、公開鍵ベースの認証のテクニックが1流れあたりのシグナリングに使用できないくらいヘビー級であると(計算上、そして、帯域幅見解からの)まだ考えられています。 サービス不能攻撃での増強された焦点は公開鍵ベースの認証のデザインに追加需要を置きます。
Tschofenig & Graveman Informational [Page 38] RFC 4230 RSVP Security Properties December 2005
[38ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
The following list briefly summarizes a few security or architectural issues that deserve improvement:
以下のリストは簡潔に改良に値するいくつかのセキュリティか構造的な問題をまとめます:
o Discovery and signaling message delivery should be separated.
o 発見とシグナリングメッセージ配送は切り離されるべきです。
o For some applications and scenarios, it cannot be assumed that
neighboring RSVP-aware nodes know each other. Hence, some in-path
discovery mechanism should be provided.
o いくつかのアプリケーションとシナリオにおいて、隣接しているRSVP意識しているノードが互いを知っていると思うことができません。 したがって、経路の何らかの発見メカニズムを提供するべきです。
o Addressing for signaling messages should be done in a hop-by-hop
fashion.
o メッセージはシグナリングのためにホップごとのファッションで扱われるべきです。
o Standard security protocols (IPsec, TLS, or CMS) should be used
whenever possible. Authentication and key exchange should be
separated from signaling message protection. In general, it is
necessary to provide key management to establish security
associations dynamically for signaling message protection.
Relying on manually configured keys between neighboring RSVP nodes
is insufficient. A separate, less frequently executed key
management and security association establishment protocol is a
good place to perform entity authentication, security service
negotiation and selection, and agreement on mechanisms,
transforms, and options.
o 可能であるときはいつも、標準のセキュリティプロトコル(IPsec、TLS、またはCMS)は使用されるべきです。 認証と主要な交換はシグナリングメッセージ保護と切り離されるべきです。 一般に、シグナリングメッセージ保護のためにダイナミックにセキュリティ協会を証明するためにかぎ管理を提供するのが必要です。 隣接しているRSVPノードの間の手動で構成されたキーを当てにするのは不十分です。 別々の、そして、どんなより頻繁にも実行されなかったかぎ管理とセキュリティ協会設立プロトコルは、働くメカニズムの実体認証、セキュリティー・サービス交渉、選択、および協定が変形する良い場所と、オプションです。
o The use of public key cryptography in authorization tokens,
identity representations, selective object protection, etc. is
likely to cause fragmentation, the need to protect against denial
of service attacks, and other problems.
o 承認トークン、アイデンティティ表現、選択しているオブジェクト保護などにおける公開鍵暗号の使用は断片化を引き起こしそうです、サービス不能攻撃、および他の問題から守る必要性。
o Public key authentication and user identity confidentiality
provided with RSVP require some improvement.
o RSVPが提供された公開鍵認証とユーザアイデンティティ秘密性は何らかの改良を必要とします。
o Public-key-based user authentication only provides entity
authentication. An additional security association is required to
protect signaling messages.
o 公開鍵ベースのユーザー認証は実体認証を提供するだけです。 追加担保協会が、保護するのにメッセージに合図しながら、必要です。
o Data origin authentication should not be provided by non-RSVP
nodes (such as the PDP). Such a procedure could be accomplished
by entity authentication during the authentication and key
exchange phase.
o 非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 選択しているメッセージ保護を提供するべきです。 保護されたメッセージはヘッダーで旗から認識可能であるべきです。
Tschofenig & Graveman Informational [Page 39] RFC 4230 RSVP Security Properties December 2005
[39ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
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 パラメタとメカニズム交渉を提供するべきです。
7. Security Considerations
7. セキュリティ問題
This document discusses security properties of RSVP and, as such, it is concerned entirely with security.
このドキュメントはRSVPのセキュリティの特性について議論します、そして、そういうものとして、それは完全にセキュリティに関係があります。
8. Acknowledgements
8. 承認
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フー、グンサーSchaefer、マークDe Vuyst、ボブ・グリロ、およびユッカMannerに感謝申し上げます。 さらに、ハンネスは彼らの時の様々な問題について議論するロバートとホルヘに感謝したがっています。
Finally, we would like to thank Allison Mankin and John Loughney for their guidance and input.
最終的に、彼らの指導と入力についてアリソン・マンキンとジョンLoughneyに感謝申し上げます。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[1] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, January 2000.
[1] ベイカーとF.とリンデル、B.とM.Talwar、「RSVPの暗号の認証」、RFC2747、2000年1月。
[2] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750,
January 2000.
[2] ハーツォグ、S.、「方針コントロールのためのRSVP拡張子」、RFC2750、2000年1月。
[3] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[3] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、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.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992.
[5] 1992年4月、最もRivestなR.、「MD5メッセージダイジェストアルゴリズム」RFC1321。
[6] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.
[6] ブレーデン、B.、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
Tschofenig & Graveman Informational [Page 40] RFC 4230 RSVP Security Properties December 2005
[40ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
[7] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T.,
Herzog, S., and R. Hess, "Identity Representation for RSVP",
RFC 3182, October 2001.
[7]YadavとS.とYavatkarとR.とPabbatiとR.とフォードとP.とムーアとT.とハーツォグ、S.とR.ヘス、「RSVPのアイデンティティ表現」RFC3182(2001年10月)。
[8] Kohl, J. and C. Neuman, "The Kerberos Network Authentication
Service (V5)", RFC 1510, September 1993. Obsoleted by RFC
4120.
[8] コールとJ.とC.ヌーマン、「ケルベロスネットワーク認証サービス(V5)」、RFC1510 1993年9月。 RFC4120によって時代遅れにされます。
[9] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 3588, September 2003.
[9] カルフーンとP.とLoughneyとJ.とGuttmanとE.とゾルン、G.とJ.Arkko、「直径基地のプロトコル」、RFC3588、2003年9月。
[10] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R., and A.
Sastry, "The COPS (Common Open Policy Service) Protocol", RFC
2748, January 2000.
[10] ダラム、D.、ボイル、J.、コーエン、R.、ハーツォグ、S.、Rajan、R.、およびA.Sastry、「巡査(一般的なオープンポリシーサービス)は議定書を作ります」、RFC2748、2000年1月。
[11] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R., and A.
Sastry, "COPS usage for RSVP", RFC 2749, January 2000.
[11] ハーツォグとS.とボイルとJ.とコーエンとR.とダラムとD.とRajan、R.とA.Sastry、「RSVPのためのCOPS用法」RFC2749(2000年1月)。
[12] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data
Flows", RFC 2207, September 1997.
[12] バーガーとL.とT.オマリー、「IPSECデータフローのためのRSVP拡張子」、RFC2207、1997年9月。
[13] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP
Operation Over IP Tunnels", RFC 2746, January 2000.
2000年1月の[13]TerzisとA.とKrawczykとJ.とWroclawski、J.とL.チャン、「IP Tunnelsの上のRSVP操作」RFC2746。
9.2. Informative References
9.2. 有益な参照
[14] Hess, R. and S. Herzog, "RSVP Extensions for Policy Control",
Work in Progress, June 2001.
[14] 「方針コントロールのためのRSVP拡張子」というヘス、R.、およびS.ハーツォグは進歩、2001年6月に働いています。
[15] "Secure Hash Standard, NIST, FIPS PUB 180-1", Federal
Information Processing Society, April 1995.
[15]、「ハッシュ規格、NISTにFIPSパブを固定してください、1801インチ、1995インチ年4月の連邦政府の情報処理学会。
[16] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
[16] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。
[17] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[17] ケントとS.とR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。
[18] Fowler, D., "Definitions of Managed Objects for the DS1, E1,
DS2 and E2 Interface Types", RFC 2495, January 1999.
[18] 野鳥捕獲者、D.、「DS1、1E、DS2、および2Eのインターフェース型のための管理オブジェクトの定義」、RFC2495、1999年1月。
[19] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
"OpenPGP Message Format", RFC 2440, November 1998.
[19] カラスとJ.とDonnerhackeとL.とフィニー、H.とR.セイヤー、「OpenPGPメッセージ・フォーマット」、RFC2440、1998年11月。
[20] Hornstein, K. and J. Altman, "Distributing Kerberos KDC and
Realm Information with DNS", Work in Progress, July 2002.
[20] 「DNSと共にケルベロスKDCと分野情報を分配し」て、ホーンスタイン、K.、およびJ.アルトマンは進歩、2002年7月に働いています。
Tschofenig & Graveman Informational [Page 41] RFC 4230 RSVP Security Properties December 2005
[41ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
[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:」 「Fast Software EncryptionのRIPEMDの強まっているバージョン」、LNCS vol.1039、ページ 71-82, 1996.
[22] Dobbertin, H., "The Status of MD5 After a Recent Attack", RSA
Laboratories CryptoBytes, vol. 2, no. 2, 1996.
[22]Dobbertin、H.、「最近の攻撃の後のMD5の状態」、RSA研究所CryptoBytes、vol.2、No.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.、カールソン、J.とH.Levkowetz、「拡張認証プロトコル(EAP)」RFC3748、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.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、「ユーザサービス(半径)におけるリモート認証ダイヤル」、RFC2865(2000年6月)。
[25] "Microsoft Authorization Data Specification v. 1.0 for
Microsoft Windows 2000 Operating Systems", April 2000.
[25] 「マイクロソフトAuthorization Data Specification v。」 2000年4月の「マイクロソフトWindows2000オペレーティングシステムのための1.0。」
[26] Cable Television Laboratories, Inc., "PacketCable Security
Specification, PKT-SP-SEC-I01-991201", website:
http://www.PacketCable.com/, June 2003.
[26] Television研究所Inc.、「PacketCableセキュリティ仕様、PKT-SP SEC I01-991201」というウェブサイトに電報を打ってください: 2003年6月の http://www.PacketCable.com/ 。
[27] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams,
"X.509 Internet Public Key Infrastructure Online Certificate
Status Protocol - OCSP", RFC 2560, June 1999.
[27] マイアーズ、M.、Ankney、R.、Malpani、A.、ガリペリン、S.、およびC.アダムス、「X.509のインターネットの公開鍵暗号基盤のオンライン証明書状態は議定書を作ります--OCSP」、RFC2560、1999年6月。
[28] Malpani, A., Housley, R., and T. Freeman, "Simple Certificate
Validation Protocol (SCVP)", Work in Progress, October 2005.
[28] A.、Housley、R.、およびT.フリーマン、「簡単な証明書合法化プロトコル(SCVP)」というMalpaniは進歩、2005年10月に働いています。
[29] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369,
August 2002.
[29]Housley、R.、「暗号のメッセージ構文(cm)」、RFC3369、2002年8月。
[30] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version
1.5", RFC 2315, March 1998.
[30]Kaliski、B.、「PKCS#7:」 暗号のメッセージ構文バージョン1.5インチ、RFC2315、1998年3月。
[31] "Specifications and standard documents", website:
http://www.PacketCable.com/, March 2002.
[31] 「仕様と規格ドキュメント」、ウェブサイト: 2002年3月の http://www.PacketCable.com/ 。
[32] Davis, D. and D. Geer, "Kerberos With Clocks Adrift: History,
Protocols and Implementation", USENIX Computing Systems, vol 9
no. 1, Winter 1996.
[32] デイヴィス、D.、およびD.イェール、「時計が定まらないケルベロス:」 「歴史、プロトコル、およびImplementation」(USENIX Computing Systems)はvolします。9 No.1、Winter1996。
[33] Raeburn, K., "Encryption and Checksum Specifications for
Kerberos 5", RFC 3961, February 2005.
[33] レイバーンとK.と「暗号化とケルベロス5インチチェックサム仕様、RFC3961、2005年2月。」
[34] Tschofenig, H., Buechli, M., Van den Bosch, S., and H.
Schulzrinne, "NSIS Authentication, Authorization and Accounting
Issues", Work in Progress, March 2003.
[34]TschofenigとH.とBuechliとM.とバンデンボッシュ、S.とH.Schulzrinne、「認証、承認、および会計が発行するNSIS」、Progress(2003年3月)のWork。
Tschofenig & Graveman Informational [Page 42] RFC 4230 RSVP Security Properties December 2005
[42ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
[35] Tschofenig, H., Buechli, M., Van den Bosch, S., Schulzrinne,
H., and T. Chen, "QoS NSLP Authorization Issues", Work in
Progress, June 2003.
[35]TschofenigとH.とBuechliとM.とバンデンボッシュとS.とSchulzrinne、H.とT.チェン、「QoS NSLP承認問題」、Progress(2003年6月)のWork。
[36] Thomas, M., "Analysis of Mobile IP and RSVP Interactions", Work
in Progress, October 2002.
[36] トーマス、M.、「モバイルIPとRSVP相互作用の分析」が進歩、2002年10月に働いています。
[37] Gai, S., Gaitonde, S., Elfassy, N., and Y. Bernet, "RSVP
Proxy", Work in Progress, March 2002.
[37] ガイとS.とGaitondeとS.とElfassy、N.とY.Bernet、「RSVPプロキシ」、進歩、2002年3月に、働いてください。
[38] Manner, J., Suihko, T., Kojo, M., Liljeberg, M., and K.
Raatikainen, "Localized RSVP", Work in Progress, September
2004.
[38] 方法とJ.とSuihkoとT.とKojoとM.とLiljeberg、M.と「RSVPであるとローカライズされた」Raatikainenが進行中で扱うK.、2004年9月。
[39] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[39] ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[40] Thomas, M., "Kerberized Internet Negotiation of Keys (KINK)",
Work in Progress, October 2005.
[40] トーマス、M.、「キー(もつれ)のKerberizedインターネット交渉」が進歩、2005年10月に働いています。
[41] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, November 2005.
[41] コーフマン、C.、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、2005年11月。
[42] Herzog, S., "Accounting and Access Control in RSVP", PhD
Dissertation, USC, Work in Progress, November 1995.
[42] ハーツォグ、S.、「会計とアクセスはRSVPで制御する」博士号Dissertation、USCが進歩、1995年11月に働いています。
[43] Herzog, S., "Accounting and Access Control for Multicast
Distributions: Models and Mechanisms", June 1996.
[43] ハーツォグ、S.、「会計とアクセスはマルチキャスト配のために以下を制御します」。 1996年6月の「モデルとメカニズム」
[44] Pato, J., "Using Pre-Authentication to Avoid Password Guessing
Attacks", Open Software Foundation DCE Request for Comments,
December 1992.
[44] オープンソフトウェア協会DCEは、コメント、1992年12月にパト、J.、「パスワード推測を避けるのにプレ認証を使用するのは攻撃する」よう要求します。
[45] Tung, B. and L. Zhu, "Public Key Cryptography for Initial
Authentication in Kerberos", Work in Progress, November 2005.
[45] 「ケルベロスにおける初期の認証のための公開鍵暗号」というタン、B.、およびL.朱は進歩、2005年11月に働いています。
[46] Wu, T., "A Real-World Analysis of Kerberos Password Security",
in Proceedings of the 1999 Internet Society Network and
Distributed System Security Symposium, San Diego, February
1999.
[46] ウー、T.、1999年のインターネット協会ネットワークと分散システムセキュリティシンポジウムの議事、サンディエゴ、1999年2月の「ケルベロスパスワードセキュリティの本当の世界分析。」
[47] Wu, T., Wu, F., and F. Gong, "Securing QoS: Threats to RSVP
Messages and Their Countermeasures", IEEE IWQoS, pp. 62-64,
1999.
[47] ウー、T.、ウー、F.、およびF.ゴング、「QoSを固定します:」 「RSVP MessagesとTheir Countermeasuresへの脅威」、IEEE IWQoS、ページ 62-64, 1999.
[48] Talwar, V., Nahrstedt, K., and F. Gong, "Securing RSVP For
Multimedia Applications", Proc ACM Multimedia 2000 (Multimedia
Security Workshop), November 2000.
[48]Talwar、V.、Nahrstedt、K.、およびF.ゴング、「マルチメディア応用のためにRSVPを固定します」、Proc ACMマルチメディア2000(マルチメディアセキュリティワークショップ)(2000年11月)。
Tschofenig & Graveman Informational [Page 43] RFC 4230 RSVP Security Properties December 2005
[43ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
[49] Talwar, V., Nahrstedt, K., and S. Nath, "RSVP-SQoS: A Secure
RSVP Protocol", International Conf on Multimedia and
Exposition, Tokyo, Japan, August 2001.
[49]Talwar、V.、Nahrstedt、K.、およびS.ナッツ、「RSVP-SQoS:」 「安全なRSVPプロトコル」とマルチメディアの国際Confとエキスポ、東京(日本)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コンピュータCommunication Review、26(5)、ページ 5-26と、1996年10月。
Tschofenig & Graveman Informational [Page 44] RFC 4230 RSVP Security Properties December 2005
[44ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
Appendix A. Dictionary Attacks and Kerberos
付録A.辞書攻撃とケルベロス
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.
ケルベロスはRSVPと共に本書では説明されるように使用されるかもしれません。 ケルベロスとの関係で辞書攻撃についてしばしば言及するので、いくつかの問題がここで扱われます。
The initial Kerberos AS_REQ request (without pre-authentication, without various extensions, and without PKINIT) is unprotected. The response message AS_REP is encrypted with the client's long-term key. An adversary can take advantage of this fact by requesting AS_REP messages to mount an off-line dictionary attack. Pre-authentication ([44]) can be used to reduce this problem. However, pre- authentication does not entirely prevent dictionary attacks by an adversary who can still eavesdrop on Kerberos messages along the path between a mobile node and a KDC. With mandatory pre-authentication for the initial request, an adversary cannot request a Ticket Granting Ticket for an arbitrary user. On-line password guessing attacks are still possible by choosing a password (e.g., from a dictionary) and then transmitting an initial request that includes a pre-authentication data field. An unsuccessful authentication by the KDC results in an error message and thus gives the adversary a hint to restart the protocol and try a new password.
初期のケルベロスAS_REQ要求(プレ認証のはない様々な拡大のはないPKINITのない)は保護がありません。 応答メッセージAS_REPはクライアントの長期のキーで暗号化されます。 敵は、オフライン辞書攻撃を仕掛けるAS_REPメッセージを要求することによって、この事実を利用できます。 この問題を減少させるのにプレ認証([44])を使用できます。 しかしながら、プレ認証はモバイルノードとKDCの間の経路に沿ってまだケルベロスメッセージを立ち聞きできる敵による辞書攻撃を完全に防ぎません。 初期の要求のための義務的なプレ認証で、敵は任意のユーザのためにTicket Granting Ticketを要求できません。 オンラインパスワード推測攻撃はパスワードを選んで(例えば、辞書から)、次に、プレ認証データ分野を含んでいる初期の要求を伝えることによって、まだ可能です。 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.
しかしながら、辞書攻撃を防ぐいくつかの提案があります。 Public Key Cryptographyの初期の認証[45](PKINIT)の使用はそのようなソリューションの1つです。 強いパスワードによるベースの他の提案使用は、初期のケルベロス交換の間、ユーザのパスワードを保護するために主要な協定プロトコルを認証しました。 [46]は、ケルベロスのセキュリティについて議論して、また、辞書攻撃を防ぐためにメカニズムについて議論します。
Appendix B. Example of User-to-PDP Authentication
ユーザからPDPへの認証に関する付録B.の例
The following Section describes an example of user-to-PDP authentication. Note that the description below is not fully covered by the RSVP specification and hence it should only be viewed as an example.
以下のセクションはユーザからPDPへの認証に関する例について説明します。 以下での記述がRSVP仕様で完全にカバーされているというわけではなくて、したがって、それが例として見なされるだけであるべきであることに注意してください。
Windows 2000, which integrates Kerberos into RSVP, uses a configuration with the user authentication to the PDP as described in [25]. The steps for authenticating the user to the PDP in an intra- realm scenario are the following:
Windows2000(ケルベロスをRSVPと統合する)は[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 Windows2000は、ユーザがKDCに連絡して、地方の分野でPDPアカウントAcsServiceのケルベロスサービスチケットを要求するのを必要とします。
Tschofenig & Graveman Informational [Page 45] RFC 4230 RSVP Security Properties December 2005
[45ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
o This ticket is then embedded into the AUTH_DATA element and
included in either the PATH or the RESV message. In the case of
Microsoft's implementation, the user identity encoded as a
distinguished name is encrypted with the session key provided with
the Kerberos ticket. The Kerberos ticket is sent without the
Kerberos authdata element that contains authorization information,
as explained in [25].
o このチケットは、次に、AUTH_DATA要素に埋め込まれていて、PATHかRESVメッセージのどちらかで含められています。 マイクロソフトの実装の場合では、分類名がセッションキーで暗号化されるのでコード化されたユーザアイデンティティはケルベロスチケットに供給されました。 [25]で説明されるように承認情報を含むケルベロス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によって傍受されます。(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要素のINTEGRITYオブジェクトの保全で保護されたKeyed Message Digest分野を作成してください。 ユーザのホストとPDPの間には、ここで説明された保護があります。 他方では、RSVP INTEGRITYオブジェクトはユーザのホストと最初に、ホップルータの間の経路を保護するのに使用されます、2つのメッセージの部品が異なったノードで終わって、異なったセキュリティ協会を使用しなければならないので。 また、メッセージを傍受する最初に、ホップルータとPDPとのインタフェースを保護しなければなりません。
* The PDP does not maintain a user database, and [25] describes
how the PDP may query the Active Directory (a LDAP based
directory service) for user policy information.
* PDPはユーザデータベースを維持しません、そして、[25]はPDPがユーザ方針情報のために、どう、Active Directory(LDAPのベースのディレクトリサービス)について質問するかもしれないかを説明します。
Appendix C. Literature on RSVP Security
RSVPセキュリティに関する付録C.文学
Few documents address the security of RSVP signaling. This section briefly describes some important documents.
わずかなドキュメントしかRSVPシグナリングのセキュリティを扱いません。 このセクションは簡潔にいくつかの重要書類について説明します。
Improvements to RSVP are proposed in [47] to deal with insider attacks. Insider attacks are caused by malicious RSVP routers that modify RSVP signaling messages in such a way that they cause harm to the nodes participating in the signaling message exchange.
RSVPへの改良は、インサイダー攻撃に対処するために[47]で提案されます。 インサイダー攻撃はシグナリング交換処理に参加するノードに害を引き起こすとそのような方法でメッセージに合図するRSVPを変更する悪意があるRSVPルータによって引き起こされます。
As a solution, non-mutable RSVP objects are digitally signed by the sender. This digital signature is added to the RSVP PATH message. Additionally, the receiver attaches an object to the RSVP RESV message containing a "signed" history. This value allows
ソリューションとして、非無常のRSVPオブジェクトは送付者によってデジタルに署名されます。 このデジタル署名はRSVP PATHメッセージに追加されます。 さらに、受信機は「署名している」歴史を含むRSVP RESVメッセージにオブジェクトを取り付けます。 値が許容するこれ
Tschofenig & Graveman Informational [Page 46] RFC 4230 RSVP Security Properties December 2005
[46ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
intermediate RSVP routers (by examining the previously signed value) to detect a malicious RSVP node.
悪意があるRSVPノードを検出する中間的RSVPルータ(以前に署名している値を調べるのによる)。
A few issues are, however, left open in this document. Replay attacks are not covered, and it is therefore assumed that timestamp- based replay protection is used. To identify a malicious node, it is necessary that all routers along the path are able to verify the digital signature. This may require a global public key infrastructure and also client-side certificates. Furthermore, the bandwidth and computational requirements to compute, transmit, and verify digital signatures for each signaling message might place a burden on a real-world deployment.
しかしながら、いくつかの問題が本書では開くままにされます。 反射攻撃はカバーされていません、そして、したがって、タイムスタンプベースの反復操作による保護が使用されていると思われます。 悪意があるノードを特定するために、経路に沿ったすべてのルータがデジタル署名について確かめることができるのが必要です。 これはグローバルな公開鍵認証基盤とクライアントサイド証明書も必要とするかもしれません。 その上、帯域幅とそれぞれのシグナリングメッセージのためのデジタル署名を計算して、伝えて、確かめるというコンピュータの要件は本当の世界展開に負担をかけるかもしれません。
Authorization is not considered in the document, which might have an influence on the implications of signaling message modification. Hence, the chain-of-trust relationship (or this step in a different direction) should be considered in relationship with authorization.
承認はドキュメントで考えられません。(それは、シグナリングメッセージ変更の含意で影響するかもしれません)。 したがって、信頼のチェーン関係(または、異なった方向へのこのステップ)は承認との関係で考えられるべきです。
In [48], the above-described idea of detecting malicious RSVP nodes is improved by addressing performance aspects. The proposed solution is somewhere between hop-by-hop security and the approach in [47], insofar as it separates the end-to-end path into individual networks. Furthermore, some additional RSVP messages (e.g., feedback messages) are introduced to implement a mechanism called "delayed integrity checking." In [49], the approach presented in [48] is enhanced.
[48]では、性能が局面であると扱うことによって、悪意があるRSVPノードを検出するという上で説明された考えは改良されます。 提案されたソリューションがホップごとのセキュリティと[47]でのアプローチの間のどこかにあります、終わりから端への経路を個々のネットワークに切り離す限り。 その上、いくつかの追加RSVPメッセージ(例えば、フィードバックメッセージ)が、「遅れた保全の照合」と呼ばれるメカニズムを実装するために紹介されます。 [49]では、[48]に提示されたアプローチは機能アップされます。
Authors' Addresses
作者のアドレス
Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
ミュンヘン、ハンネスTschofenigシーメンスオットーハーン一味6バイエルン81739ドイツ
EMail: Hannes.Tschofenig@siemens.com
メール: Hannes.Tschofenig@siemens.com
Richard Graveman RFG Security 15 Park Avenue Morristown, NJ 07960 USA
リチャードGraveman RFG Security15パーク・アベニューニュージャージー07960モリスタウン(米国)
EMail: rfg@acm.org
メール: rfg@acm.org
Tschofenig & Graveman Informational [Page 47] RFC 4230 RSVP Security Properties December 2005
[47ページ]RFC4230RSVPセキュリティ特性の2005年12月の情報のTschofenig&Graveman
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Tschofenig & Graveman Informational [Page 48]
Tschofenig&Graveman情報です。[48ページ]
一覧
スポンサーリンク
