[要約] RFC 2747は、RSVP（Resource Reservation Protocol）の暗号認証に関する仕様です。このRFCの目的は、RSVPメッセージの送信元の認証とデータの完全性を確保することです。
Network Working Group F. Baker
Request for Comments: 2747 Cisco
Category: Standards Track B. Lindell
USC/ISI
M. Talwar
Microsoft
January 2000
RSVP Cryptographic Authentication
RSVP暗号化認証
Status of this Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（C）The Internet Society（2000）。全著作権所有。
Abstract
概要
This document describes the format and use of RSVP's INTEGRITY object to provide hop-by-hop integrity and authentication of RSVP messages.
このドキュメントでは、RSVPメッセージのホップバイホップの整合性と認証を提供するためのRSVPのINTEGRITYオブジェクトの形式と使用法について説明します。
The Resource ReSerVation Protocol RSVP [1] is a protocol for setting up distributed state in routers and hosts, and in particular for reserving resources to implement integrated service. RSVP allows particular users to obtain preferential access to network resources, under the control of an admission control mechanism. Permission to make a reservation will depend both upon the availability of the requested resources along the path of the data, and upon satisfaction of policy rules.
Resource ReSerVation Protocol RSVP [1]は、ルーターとホストで分散状態を設定するためのプロトコルで、特に統合サービスを実装するためにリソースを予約するためのプロトコルです。 RSVPを使用すると、アドミッションコントロールメカニズムの制御下で、特定のユーザーがネットワークリソースに優先的にアクセスできます。予約を行う許可は、データのパスに沿った要求されたリソースの可用性と、ポリシールールの満足度の両方に依存します。
To ensure the integrity of this admission control mechanism, RSVP requires the ability to protect its messages against corruption and spoofing. This document defines a mechanism to protect RSVP message integrity hop-by-hop. The proposed scheme transmits an authenticating digest of the message, computed using a secret Authentication Key and a keyed-hash algorithm. This scheme provides protection against forgery or message modification. The INTEGRITY object of each RSVP message is tagged with a one-time-use sequence number. This allows the message receiver to identify playbacks and hence to thwart replay attacks. The proposed mechanism does not afford confidentiality, since messages stay in the clear; however, the mechanism is also exportable from most countries, which would be impossible were a privacy algorithm to be used. Note: this document uses the terms "sender" and "receiver" differently from [1]. They are used here to refer to systems that face each other across an RSVP hop, the "sender" being the system generating RSVP messages.
このアドミッションコントロールメカニズムの整合性を確保するために、RSVPは、メッセージを破損やスプーフィングから保護する機能を必要とします。このドキュメントでは、RSVPメッセージの整合性をホップバイホップで保護するメカニズムを定義しています。提案されたスキームは、秘密の認証キーとキー付きハッシュアルゴリズムを使用して計算された、メッセージの認証ダイジェストを送信します。このスキームは、偽造またはメッセージの変更に対する保護を提供します。各RSVPメッセージのINTEGRITYオブジェクトには、1回限りのシーケンス番号がタグ付けされます。これにより、メッセージレシーバーは再生を識別し、それによりリプレイアタックを阻止できます。メッセージが明確に保たれるため、提案されたメカニズムは機密性を提供しません。ただし、このメカニズムはほとんどの国からもエクスポート可能であり、プライバシーアルゴリズムを使用する場合は不可能です。注：このドキュメントでは、「送信者」および「受信者」という用語を[1]とは異なる方法で使用しています。ここでは、RSVPホップを介して互いに向き合うシステムを指すために使用されます。「送信者」は、RSVPメッセージを生成するシステムです。
The message replay prevention algorithm is quite simple. The sender generates packets with monotonically increasing sequence numbers. In turn, the receiver only accepts packets that have a larger sequence number than the previous packet. To start this process, a receiver handshakes with the sender to get an initial sequence number. This memo discusses ways to relax the strictness of the in-order delivery of messages as well as techniques to generate monotonically increasing sequence numbers that are robust across sender failures and restarts.
メッセージ再生防止アルゴリズムは非常に単純です。送信者は、単調に増加するシーケンス番号を持つパケットを生成します。次に、受信側は、前のパケットよりもシーケンス番号が大きいパケットのみを受け入れます。このプロセスを開始するには、受信者が送信者とハンドシェイクして初期シーケンス番号を取得します。このメモでは、メッセージの順序どおりの配信の厳格さを緩和する方法と、送信者の障害や再起動に対して堅牢な単調に増加するシーケンス番号を生成する手法について説明します。
The proposed mechanism is independent of a specific cryptographic algorithm, but the document describes the use of Keyed-Hashing for Message Authentication using HMAC-MD5 [7]. As noted in [7], there exist stronger hashes, such as HMAC-SHA1; where warranted, implementations will do well to make them available. However, in the general case, [7] suggests that HMAC-MD5 is adequate to the purpose at hand and has preferable performance characteristics. [7] also offers source code and test vectors for this algorithm, a boon to those who would test for interoperability. HMAC-MD5 is required as a baseline to be universally included in RSVP implementations providing cryptographic authentication, with other proposals optional (see Section 6 on Conformance Requirements).
提案されたメカニズムは特定の暗号化アルゴリズムから独立していますが、このドキュメントでは、HMAC-MD5を使用したメッセージ認証のためのキー付きハッシュの使用について説明しています[7]。 [7]で述べたように、HMAC-SHA1などのより強力なハッシュが存在します。正当な理由がある場合、実装はそれらを使用可能にするためにうまく機能します。ただし、一般的なケースでは、[7]はHMAC-MD5が目下の目的に適し、好ましいパフォーマンス特性を持っていることを示唆しています。 [7]は、このアルゴリズムのソースコードとテストベクトルも提供します。これは、相互運用性をテストする人に恩恵をもたらします。 HMAC-MD5は、暗号化認証を提供するRSVP実装に普遍的に含まれるベースラインとして必要であり、他の提案はオプションです（適合要件のセクション6を参照）。
The RSVP checksum MAY be disabled (set to zero) when the INTEGRITY object is included in the message, as the message digest is a much stronger integrity check.
メッセージダイジェストはより強力な整合性チェックであるため、INTEGRITYオブジェクトがメッセージに含まれている場合は、RSVPチェックサムを無効（ゼロに設定）にすることができます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [8].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [8]で説明されているように解釈されます。
One obvious question is why, since there exists a standard authentication mechanism, IPSEC [3,5], we would choose not to use it. This was discussed at length in the working group, and the use of IPSEC was rejected for the following reasons.
明白な質問の1つは、標準認証メカニズムであるIPSEC [3,5]が存在するため、使用しないことを選択する理由です。これはワーキンググループで詳細に議論され、IPSECの使用は以下の理由で拒否されました。
The security associations in IPSEC are based on destination address. It is not clear that RSVP messages are well defined for either source or destination based security associations, as a router must forward PATH and PATH TEAR messages using the same source address as the sender listed in the SENDER TEMPLATE. RSVP traffic may otherwise not follow exactly the same path as data traffic. Using either source or destination based associations would require opening a new security association among the routers for which a reservation traverses.
IPSECのセキュリティアソシエーションは、宛先アドレスに基づいています。ルータはSENDER TEMPLATEにリストされている送信者と同じ送信元アドレスを使用してPATHおよびPATH TEARメッセージを転送する必要があるため、RSVPメッセージが送信元または宛先ベースのセキュリティアソシエーションに対して適切に定義されているかどうかは明らかではありません。それ以外の場合、RSVPトラフィックは、データトラフィックとまったく同じパスをたどらない場合があります。送信元または宛先ベースの関連付けを使用するには、予約が通過するルーター間で新しいセキュリティアソシエーションを開く必要があります。
In addition, it was noted that neighbor relationships between RSVP systems are not limited to those that face one another across a communication channel. RSVP relationships across non-RSVP clouds, such as those described in Section 2.9 of [1], are not necessarily visible to the sending system. These arguments suggest the use of a key management strategy based on RSVP router to RSVP router associations instead of IPSEC.
さらに、RSVPシステム間のネイバー関係は、通信チャネルを介して互いに向き合うものに限定されないことに注意してください。 [1]のセクション2.9で説明されているような非RSVPクラウド全体のRSVP関係は、送信側システムには必ずしも表示されません。これらの議論は、IPSECの代わりにRSVPルーターとRSVPルーターの関連付けに基づくキー管理戦略の使用を示唆しています。
An RSVP message consists of a sequence of "objects," which are type-length-value encoded fields having specific purposes. The information required for hop-by-hop integrity checking is carried in an INTEGRITY object. The same INTEGRITY object type is used for both IPv4 and IPv6.
RSVPメッセージは、一連の「オブジェクト」から構成されます。これは、特定の目的を持つタイプ長さ値エンコードフィールドです。ホップバイホップの整合性チェックに必要な情報は、INTEGRITYオブジェクトで伝達されます。 IPv4とIPv6の両方で同じINTEGRITYオブジェクトタイプが使用されます。
The INTEGRITY object has the following format:
INTEGRITYオブジェクトの形式は次のとおりです。
Keyed Message Digest INTEGRITY Object: Class = 4, C-Type = 1
+-------------+-------------+-------------+-------------+
| Flags | 0 (Reserved)| |
+-------------+-------------+ +
| Key Identifier |
+-------------+-------------+-------------+-------------+
| Sequence Number |
| |
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ Keyed Message Digest |
| |
+ +
| |
+-------------+-------------+-------------+-------------+
o Flags: An 8-bit field with the following format:
o フラグ：次の形式の8ビットフィールド：
Flags
旗
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| H | |
| F | 0 |
+---+---+---+---+---+---+---+---+
Currently only one flag (HF) is defined. The remaining flags are reserved for future use and MUST be set to 0.
現在、1つのフラグ（HF）のみが定義されています。残りのフラグは将来の使用のために予約されており、0に設定する必要があります。
o Bit 0: Handshake Flag (HF) concerns the integrity handshake mechanism (Section 4.3). Message senders willing to respond to integrity handshake messages SHOULD set this flag to 1 whereas those that will reject integrity handshake messages SHOULD set this to 0.
o ビット0：ハンドシェイクフラグ（HF）は、整合性ハンドシェイクメカニズムに関係しています（セクション4.3）。整合性ハンドシェイクメッセージに応答するメッセージ送信者は、このフラグを1に設定する必要があります（SHOULD）一方で、整合性ハンドシェイクメッセージを拒否するメッセージ送信者は、これを0に設定する必要があります（SHOULD）。
o Key Identifier: An unsigned 48-bit number that MUST be unique for a given sender. Locally unique Key Identifiers can be generated using some combination of the address (IP or MAC or LIH) of the sending interface and the key number. The combination of the Key Identifier and the sending system's IP address uniquely identifies the security association (Section 2.2).
o キー識別子：署名されていない48ビットの番号で、特定の送信者に対して一意である必要があります。ローカルで一意のキー識別子は、送信インターフェイスのアドレス（IPまたはMACまたはLIH）とキー番号の組み合わせを使用して生成できます。キー識別子と送信側システムのIPアドレスの組み合わせは、セキュリティアソシエーションを一意に識別します（セクション2.2）。
o Sequence Number: An unsigned 64-bit monotonically increasing, unique sequence number.
o シーケンス番号：符号なし64ビットの単調増加する一意のシーケンス番号。
Sequence Number values may be any monotonically increasing sequence that provides the INTEGRITY object [of each RSVP message] with a tag that is unique for the associated key's lifetime. Details on sequence number generation are presented in Section 3.
シーケンス番号の値は、[各RSVPメッセージの] INTEGRITYオブジェクトに、関連するキーの有効期間で一意のタグを提供する、単調に増加するシーケンスです。シーケンス番号生成の詳細については、セクション3で説明します。
o Keyed Message Digest: The digest MUST be a multiple of 4 octets long. For HMAC-MD5, it will be 16 bytes long.
o キー付きメッセージダイジェスト：ダイジェストは4オクテットの倍数である必要があります。 HMAC-MD5の場合、長さは16バイトです。
The sending and receiving systems maintain a security association for each authentication key that they share. This security association includes the following parameters:
送信システムと受信システムは、共有する各認証キーのセキュリティアソシエーションを維持します。このセキュリティアソシエーションには、次のパラメータが含まれています。
o Authentication algorithm and algorithm mode being used.
o 使用されている認証アルゴリズムとアルゴリズムモード。
o Key used with the authentication algorithm.
o 認証アルゴリズムで使用されるキー。
o Lifetime of the key.
o キーの寿命。
o Associated sending interface and other security association selection criteria [REQUIRED at Sending System].
o 関連付けられた送信インターフェイスおよびその他のセキュリティアソシエーション選択基準[送信システムで必須]。
o Source Address of the sending system [REQUIRED at Receiving System].
o 送信システムの送信元アドレス[受信システムで必須]。
o Latest sending sequence number used with this key identifier [REQUIRED at Sending System].
o このキー識別子で使用される最新の送信シーケンス番号[送信システムで必須]。
o List of last N sequence numbers received with this key identifier [REQUIRED at Receiving System].
o このキー識別子で受信された最後のNシーケンス番号のリスト[受信システムで必須]。
In this section we describe methods that could be chosen to generate the sequence numbers used in the INTEGRITY object of an RSVP message. As previous stated, there are two important properties that MUST be satisfied by the generation procedure. The first property is that the sequence numbers are unique, or one-time, for the lifetime of the integrity key that is in current use. A receiver can use this property to unambiguously distinguish between a new or a replayed message. The second property is that the sequence numbers are generated in monotonically increasing order, modulo 2^64. This is required to greatly reduce the amount of saved state, since a receiver only needs to save the value of the highest sequence number seen to avoid a replay attack. Since the starting sequence number might be arbitrarily large, the modulo operation is required to accommodate sequence number roll-over within some key's lifetime. This solution draws from TCP's approach [9].
このセクションでは、RSVPメッセージのINTEGRITYオブジェクトで使用されるシーケンス番号を生成するために選択できるメソッドについて説明します。前述のように、生成手順で満たす必要がある2つの重要なプロパティがあります。 1つ目の特性は、現在使用されている整合性キーの有効期間中、シーケンス番号が一意、つまり1回限りであることです。受信者はこのプロパティを使用して、新しいメッセージと再生されたメッセージを明確に区別できます。 2番目の特性は、シーケンス番号が2 ^ 64を法とする単調増加の順序で生成されることです。これは、保存された状態の量を大幅に削減するために必要です。レシーバーは、再生攻撃を回避するために、見られる最も大きいシーケンス番号の値を保存するだけでよいからです。開始シーケンス番号は任意に大きくなる可能性があるため、あるキーの有効期間内にシーケンス番号のロールオーバーに対応するには、モジュロ演算が必要です。このソリューションは、TCPのアプローチ[9]を利用しています。
The sequence number field is chosen to be a 64-bit unsigned quantity. This is large enough to avoid exhaustion over the key lifetime. For example, if a key lifetime was conservatively defined as one year, there would be enough sequence number values to send RSVP messages at an average rate of about 585 gigaMessages per second. A 32-bit sequence number would limit this average rate to about 136 messages per second.
シーケンス番号フィールドは、64ビットの符号なし数量になるように選択されています。これは、キーの有効期間が尽きることを避けるのに十分な大きさです。たとえば、キーの有効期間が1年と保守的に定義されている場合、RSVPメッセージを1秒あたり約585ギガメッセージの平均レートで送信するのに十分なシーケンス番号値があります。 32ビットのシーケンス番号は、この平均レートを毎秒約136メッセージに制限します。
The ability to generate unique monotonically increasing sequence numbers across a failure and restart implies some form of stable storage, either local to the device or remotely over the network. Three sequence number generation procedures are described below.
障害および再起動のたびに単調に増加する一意のシーケンス番号を生成する機能は、デバイスのローカルまたはネットワークを介してリモートで、何らかの形の安定したストレージを意味します。 3つのシーケンス番号生成手順を以下に示します。
The most straightforward approach is to generate a unique sequence number using a message counter. Each time a message is transmitted for a given key, the sequence number counter is incremented. The current value of this counter is continually or periodically saved to stable storage. After a restart, the counter is recovered using this stable storage. If the counter was saved periodically to stable storage, the count should be recovered by increasing the saved value to be larger than any possible value of the counter at the time of the failure. This can be computed, knowing the interval at which the counter was saved to stable storage and incrementing the stored value by that amount.
最も簡単な方法は、メッセージカウンターを使用して一意のシーケンス番号を生成することです。所定のキーに対してメッセージが送信されるたびに、シーケンス番号カウンタが増分されます。このカウンターの現在の値は、継続的または定期的に安定したストレージに保存されます。再起動後、この安定したストレージを使用してカウンターが復元されます。カウンタが定期的に安定したストレージに保存された場合、保存された値を、障害発生時の可能なカウンタの値よりも大きくして、カウントを回復する必要があります。これは、カウンタが安定したストレージに保存された間隔を把握し、保存された値をその量だけインクリメントして計算できます。
Most devices will probably not have the capability to save sequence number counters to stable storage for each key. A more universal solution is to base sequence numbers on the stable storage of a real time clock. Many computing devices have a real time clock module that includes stable storage of the clock. These modules generally include some form of nonvolatile memory to retain clock information in the event of a power failure.
ほとんどのデバイスには、シーケンス番号カウンターを各キーの安定したストレージに保存する機能がない可能性があります。より普遍的な解決策は、リアルタイムクロックの安定したストレージに基づいてシーケンス番号を作成することです。多くのコンピューティングデバイスには、クロックの安定したストレージを含むリアルタイムクロックモジュールがあります。これらのモジュールには、通常、停電時にクロック情報を保持するための何らかの形式の不揮発性メモリが含まれています。
In this approach, we could use an NTP based timestamp value as the sequence number. The roll-over period of an NTP timestamp is about 136 years, much longer than any reasonable lifetime of a key. In addition, the granularity of the NTP timestamp is fine enough to allow the generation of an RSVP message every 200 picoseconds for a given key. Many real time clock modules do not have the resolution of an NTP timestamp. In these cases, the least significant bits of the timestamp can be generated using a message counter, which is reset every clock tick. For example, when the real time clock provides a resolution of 1 second, the 32 least significant bits of the sequence number can be generated using a message counter. The remaining 32 bits are filled with the 32 least significant bits of the timestamp. Assuming that the recovery time after failure takes longer than one tick of the real time clock, the message counter for the low order bits can be safely reset to zero after a restart.
このアプローチでは、シーケンス番号としてNTPベースのタイムスタンプ値を使用できます。 NTPタイムスタンプのロールオーバー期間は約136年で、キーの妥当な有効期間よりもはるかに長くなります。さらに、NTPタイムスタンプの細かさは、指定されたキーに対して200ピコ秒ごとにRSVPメッセージを生成できるほど細かいです。多くのリアルタイムクロックモジュールには、NTPタイムスタンプの解決機能がありません。これらの場合、タイムスタンプの最下位ビットは、クロックティックごとにリセットされるメッセージカウンターを使用して生成できます。たとえば、リアルタイムクロックが1秒の分解能を提供する場合、シーケンス番号の最下位32ビットをメッセージカウンターを使用して生成できます。残りの32ビットは、タイムスタンプの最下位32ビットで埋められます。障害後の回復時間がリアルタイムクロックの1ティックよりも長いと想定すると、再起動後に下位ビットのメッセージカウンターを安全にゼロにリセットできます。
If the device does not contain any stable storage of sequence number counters or of a real time clock, it could recover the real time clock from the network using NTP. Once the clock has been recovered following a restart, the sequence number generation procedure would be identical to the procedure described above.
デバイスにシーケンス番号カウンターまたはリアルタイムクロックの安定したストレージが含まれていない場合、NTPを使用してネットワークからリアルタイムクロックを回復できます。再起動後にクロックが回復すると、シーケンス番号の生成手順は上記の手順と同じになります。
Implementations SHOULD allow specification of interfaces that are to be secured, for either sending messages, or receiving them, or both. The sender must ensure that all RSVP messages sent on secured sending interfaces include an INTEGRITY object, generated using the appropriate Key. Receivers verify whether RSVP messages, except of the type "Integrity Challenge" (Section 4.3), arriving on a secured receiving interface contain the INTEGRITY object. If the INTEGRITY object is absent, the receiver discards the message.
実装では、メッセージを送信するため、またはメッセージを受信するため、あるいはその両方のために、保護されるインターフェースの仕様を許可する必要があります（SHOULD）。送信者は、安全な送信インターフェイスで送信されるすべてのRSVPメッセージに、適切なキーを使用して生成されたINTEGRITYオブジェクトが含まれていることを確認する必要があります。受信者は、 "Integrity Challenge"タイプ（4.3節）を除き、安全な受信インターフェースに到着するRSVPメッセージにINTEGRITYオブジェクトが含まれているかどうかを確認します。 INTEGRITYオブジェクトが存在しない場合、受信者はメッセージを破棄します。
Security associations are simplex - the keys that a sending system uses to sign its messages may be different from the keys that its receivers use to sign theirs. Hence, each association is associated with a unique sending system and (possibly) multiple receiving systems.
セキュリティアソシエーションはシンプレックスです。送信側システムがメッセージの署名に使用するキーは、受信側がメッセージの署名に使用するキーとは異なる場合があります。したがって、各関連付けは、一意の送信システムと（場合によっては）複数の受信システムに関連付けられます。
Each sender SHOULD have distinct security associations (and keys) per secured sending interface (or LIH). While administrators may configure all the routers and hosts on a subnet (or for that matter, in their network) using a single security association, implementations MUST assume that each sender may send using a distinct security association on each secured interface. At the sender, security association selection is based on the interface through which the message is sent. This selection MAY include additional criteria, such as the destination address (when sending the message unicast, over a broadcast LAN with a large number of hosts) or user identities at the sender or receivers [2]. Finally, all intended message recipients should participate in this security association. Route flaps in a non RSVP cloud might cause messages for the same receiver to be sent on different interfaces at different times. In such cases, the receivers should participate in all possible security associations that may be selected for the interfaces through which the message might be sent.
各送信者は、セキュリティで保護された送信インターフェイス（またはLIH）ごとに異なるセキュリティアソシエーション（およびキー）を持つ必要があります（SHOULD）。管理者は、単一のセキュリティアソシエーションを使用して、サブネット上の（または、さらに言えば、ネットワーク内の）すべてのルーターとホストを構成できますが、実装では、各送信者が、セキュリティで保護された各インターフェイスで異なるセキュリティアソシエーションを使用して送信できると想定する必要があります。送信者では、セキュリティアソシエーションの選択は、メッセージの送信に使用されるインターフェイスに基づいています。この選択には、宛先アドレス（メッセージユニキャストを送信する場合、多数のホストを持つブロードキャストLANを介して）または送信者または受信者のユーザーIDなどの追加の基準が含まれる場合があります[2]。最後に、対象となるすべてのメッセージ受信者がこのセキュリティアソシエーションに参加する必要があります。非RSVPクラウドのルートフラップにより、同じ受信者へのメッセージが異なるインターフェイスで異なるタイミングで送信される場合があります。このような場合、受信者は、メッセージが送信される可能性のあるインターフェイスに対して選択される可能性のあるすべてのセキュリティアソシエーションに参加する必要があります。
Receivers select keys based on the Key Identifier and the sending system's IP address. The Key Identifier is included in the INTEGRITY object. The sending system's address can be obtained either from the RSVP_HOP object, or if that's not present (as is the case with PathErr and ResvConf messages) from the IP source address. Since the Key Identifier is unique for a sender, this method uniquely identifies the key.
受信者は、キー識別子と送信システムのIPアドレスに基づいてキーを選択します。キー識別子はINTEGRITYオブジェクトに含まれています。送信側システムのアドレスは、RSVP_HOPオブジェクトから取得するか、それが存在しない場合（PathErrおよびResvConfメッセージの場合のように）IP送信元アドレスから取得できます。キー識別子は送信者に対して一意であるため、このメソッドはキーを一意に識別します。
The integrity mechanism slightly modifies the processing rules for RSVP messages, both when including the INTEGRITY object in a message sent over a secured sending interface and when accepting a message received on a secured receiving interface. These modifications are detailed below.
保全性メカニズムは、セキュアな送信インターフェースを介して送信されるメッセージにINTEGRITYオブジェクトを含める場合と、セキュアな受信インターフェースで受信されるメッセージを受け入れる場合の両方で、RSVPメッセージの処理規則を少し変更します。これらの変更の詳細を以下に示します。
For an RSVP message sent over a secured sending interface, the message is created as described in [1], with these exceptions:
安全な送信インターフェイスを介して送信されたRSVPメッセージの場合、メッセージは[1]で説明されているように作成されますが、次の例外があります。
(1) The RSVP checksum field is set to zero. If required, an RSVP checksum can be calculated when the processing of the INTEGRITY object is complete.
（1）RSVPチェックサムフィールドはゼロに設定されます。必要に応じて、INTEGRITYオブジェクトの処理が完了したときにRSVPチェックサムを計算できます。
(2) The INTEGRITY object is inserted in the appropriate place, and its location in the message is remembered for later use.
（2）INTEGRITYオブジェクトが適切な場所に挿入され、メッセージ内のその場所が後で使用できるように記憶されます。
(3) The sending interface and other appropriate criteria (as mentioned above) are used to determine the Authentication Key and the hash algorithm to be used.
（3）送信インターフェースと他の適切な基準（上記のとおり）を使用して、使用する認証キーとハッシュアルゴリズムを決定します。
(4) The unused flags and the reserved field in the INTEGRITY object MUST be set to 0. The Handshake Flag (HF) should be set according to rules specified in Section 2.1.
（4）INTEGRITYオブジェクトの未使用のフラグと予約済みフィールドは0に設定する必要があります。ハンドシェイクフラグ（HF）は、セクション2.1で指定された規則に従って設定する必要があります。
(5) The sending sequence number MUST be updated to ensure a unique, monotonically increasing number. It is then placed in the Sequence Number field of the INTEGRITY object.
（5）送信シーケンス番号を更新して、一意で単調に増加する番号を確保する必要があります。次に、INTEGRITYオブジェクトのシーケンス番号フィールドに配置されます。
(6) The Keyed Message Digest field is set to zero.
（6）Keyed Message Digestフィールドはゼロに設定されます。
(7) The Key Identifier is placed into the INTEGRITY object.
（7）キー識別子はINTEGRITYオブジェクトに配置されます。
(8) An authenticating digest of the message is computed using the Authentication Key in conjunction with the keyed-hash algorithm. When the HMAC-MD5 algorithm is used, the hash calculation is described in [7].
（8）メッセージの認証ダイジェストは、認証キーをキー付きハッシュアルゴリズムと組み合わせて使用して計算されます。 HMAC-MD5アルゴリズムが使用される場合、ハッシュ計算は[7]で説明されています。
(9) The digest is written into the Cryptographic Digest field of the INTEGRITY object.
（9）ダイジェストはINTEGRITYオブジェクトのCryptographic Digestフィールドに書き込まれます。
When the message is received on a secured receiving interface, and is not of the type "Integrity Challenge", it is processed in the following manner:
メッセージが安全な受信インターフェースで受信され、タイプが「整合性チャレンジ」ではない場合、メッセージは次のように処理されます。
(1) The RSVP checksum field is saved and the field is subsequently set to zero.
（1）RSVPチェックサムフィールドが保存され、その後フィールドがゼロに設定されます。
(2) The Cryptographic Digest field of the INTEGRITY object is saved and the field is subsequently set to zero.
（2）INTEGRITYオブジェクトのCryptographic Digestフィールドが保存され、その後フィールドはゼロに設定されます。
(3) The Key Identifier field and the sending system address are used to uniquely determine the Authentication Key and the hash algorithm to be used. Processing of this packet might be delayed when the Key Management System (Appendix 1) is queried for this information.
（3）キー識別子フィールドと送信システムアドレスは、使用する認証キーとハッシュアルゴリズムを一意に決定するために使用されます。キー管理システム（付録1）にこの情報を照会すると、このパケットの処理が遅れる場合があります。
(4) A new keyed-digest is calculated using the indicated algorithm and the Authentication Key.
（4）新しいキー付きダイジェストは、指定されたアルゴリズムと認証キーを使用して計算されます。
(5) If the calculated digest does not match the received digest, the message is discarded without further processing.
（5）計算されたダイジェストが受信したダイジェストと一致しない場合、メッセージはそれ以上処理されずに破棄されます。
(6) If the message is of type "Integrity Response", verify that the CHALLENGE object identically matches the originated challenge. If it matches, save the sequence number in the INTEGRITY object as the largest sequence number received to date.
（6）メッセージのタイプが「Integrity Response」の場合は、CHALLENGEオブジェクトが元のチャレンジと完全に一致することを確認します。一致する場合は、これまでに受信した最大のシーケンス番号としてINTEGRITYオブジェクトにシーケンス番号を保存します。
Otherwise, for all other RSVP Messages, the sequence number is validated to prevent replay attacks, and messages with invalid sequence numbers are ignored by the receiver.
それ以外の場合、他のすべてのRSVPメッセージでは、シーケンス番号が検証されてリプレイアタックが防止され、無効なシーケンス番号を持つメッセージは受信者によって無視されます。
When a message is accepted, the sequence number of that message could update a stored value corresponding to the largest sequence number received to date. Each subsequent message must then have a larger (modulo 2^64) sequence number to be accepted. This simple processing rule prevents message replay attacks, but it must be modified to tolerate limited out-of-order message delivery. For example, if several messages were sent in a burst (in a periodic refresh generated by a router, or as a result of a tear down function), they might get reordered and then the sequence numbers would not be received in an increasing order.
メッセージが受け入れられると、そのメッセージのシーケンス番号は、現在までに受信した最大のシーケンス番号に対応する格納された値を更新できます。後続の各メッセージは、受け入れられるように、より大きな（2 ^ 64を法とする）シーケンス番号を持つ必要があります。この単純な処理ルールはメッセージリプレイアタックを防ぎますが、限られた順序の乱れたメッセージ配信を許容するように変更する必要があります。たとえば、複数のメッセージがバーストで送信された場合（ルーターによって生成された定期的な更新で、または破棄機能の結果として）、それらのメッセージは並べ替えられ、シーケンス番号は昇順で受信されません。
An implementation SHOULD allow administrative configuration that sets the receiver's tolerance to out-of-order message delivery. A simple approach would allow administrators to specify a message window corresponding to the worst case reordering behavior. For example, one might specify that packets reordered within a 32 message window would be accepted. If no reordering can occur, the window is set to one.
実装では、順不同のメッセージ配信に対する受信者の許容度を設定する管理構成を許可する必要があります（SHOULD）。単純なアプローチでは、管理者は最悪の場合の並べ替え動作に対応するメッセージウィンドウを指定できます。たとえば、32メッセージウィンドウ内で並べ替えられたパケットを受け入れるように指定できます。並べ替えが発生しない場合、ウィンドウは1に設定されます。
The receiver must store a list of all sequence numbers seen within the reordering window. A received sequence number is valid if (a) it is greater than the maximum sequence number received or (b) it is a past sequence number lying within the reordering window and not recorded in the list. Acceptance of a sequence number implies adding it to the list and removing a number from the lower end of the list. Messages received with sequence numbers lying below the lower end of the list or marked seen in the list are discarded.
受信者は、並べ替えウィンドウ内に表示されるすべてのシーケンス番号のリストを保存する必要があります。受信したシーケンス番号は、（a）受信した最大シーケンス番号よりも大きい場合、または（b）並べ替えウィンドウ内にあり、リストに記録されていない過去のシーケンス番号である場合に有効です。シーケンス番号を受け入れると、シーケンス番号がリストに追加され、リストの下端から番号が削除されます。リストの下端より下にある、またはリストで見られるとマークされたシーケンス番号で受信されたメッセージは破棄されます。
When an "Integrity Challenge" message is received on a secured sending interface it is processed in the following manner:
保護された送信インターフェイスで「整合性チャレンジ」メッセージを受信すると、次の方法で処理されます。
(1) An "Integrity Response" message is formed using the Challenge object received in the challenge message.
（1）「整合性応答」メッセージは、チャレンジメッセージで受信したチャレンジオブジェクトを使用して形成されます。
(2) The message is sent back to the receiver, based on the source IP address of the challenge message, using the "Message Generation" steps outlined above. The selection of the Authentication Key and the hash algorithm to be used is determined by the key identifier supplied in the challenge message.
（2）上記の「メッセージ生成」の手順を使用して、チャレンジメッセージの送信元IPアドレスに基づいて、メッセージが受信者に送り返されます。使用する認証キーとハッシュアルゴリズムの選択は、チャレンジメッセージで提供されるキー識別子によって決まります。
To obtain the starting sequence number for a live Authentication Key, the receiver MAY initiate an integrity handshake with the sender. This handshake consists of a receiver's Challenge and the sender's Response, and may be either initiated during restart or postponed until a message signed with that key arrives.
ライブ認証キーの開始シーケンス番号を取得するために、受信者は送信者との完全性ハンドシェイクを開始してもよい（MAY）。このハンドシェイクは、受信者のチャレンジと送信者の応答で構成され、再起動中に開始されるか、そのキーで署名されたメッセージが到着するまで延期されます。
Once the receiver has decided to initiate an integrity handshake for a particular Authentication Key, it identifies the sender using the sending system's address configured in the corresponding security association. The receiver then sends an RSVP Integrity Challenge message to the sender. This message contains the Key Identifier to identify the sender's key and MUST have a unique challenge cookie that is based on a local secret to prevent guessing. see Section 2.5.3 of [4]). It is suggested that the cookie be an MD5 hash of a local secret and a timestamp to provide uniqueness (see Section 9).
受信者が特定の認証キーの完全性ハンドシェイクを開始することを決定すると、対応するセキュリティアソシエーションで構成された送信システムのアドレスを使用して送信者を識別します。次に、受信者はRSVP整合性チャレンジメッセージを送信者に送信します。このメッセージには、送信者の鍵を識別するための鍵識別子が含まれており、推測を防ぐためにローカルシークレットに基づく一意のチャレンジCookieが必要です。 [4]のセクション2.5.3を参照してください）。一意性を提供するために、CookieはローカルシークレットのMD5ハッシュとタイムスタンプにすることをお勧めします（セクション9を参照）。
An RSVP Integrity Challenge message will carry a message type of 11. The message format is as follows:
RSVP Integrity Challengeメッセージには、メッセージタイプ11が含まれます。メッセージの形式は次のとおりです。
<Integrity Challenge message> ::= <Common Header> <CHALLENGE>
he CHALLENGE object has the following format:
CHALLENGEオブジェクトの形式は次のとおりです。
CHALLENGE Object: Class = 64, C-Type = 1
+-------------+-------------+-------------+-------------+
| 0 (Reserved) | |
+-------------+-------------+ +
| Key Identifier |
+-------------+-------------+-------------+-------------+
| Challenge Cookie |
| |
+-------------+-------------+-------------+-------------+
The sender accepts the "Integrity Challenge" without doing an integrity check. It returns an RSVP "Integrity Response" message that contains the original CHALLENGE object. It also includes an INTEGRITY object, signed with the key specified by the Key Identifier included in the "Integrity Challenge".
送信者は、整合性チェックを行わずに「整合性チャレンジ」を受け入れます。元のCHALLENGEオブジェクトを含むRSVP "Integrity Response"メッセージを返します。また、「整合性チャレンジ」に含まれるキー識別子で指定されたキーで署名されたINTEGRITYオブジェクトも含まれます。
An RSVP Integrity Response message will carry a message type of 12. The message format is as follows:
RSVP Integrity Responseメッセージには、メッセージタイプ12が含まれます。メッセージフォーマットは次のとおりです。
<Integrity Response message> ::= <Common Header> <INTEGRITY>
<CHALLENGE>
The "Integrity Response" message is accepted by the receiver (challenger) only if the returned CHALLENGE object matches the one sent in the "Integrity Challenge" message. This prevents replay of old "Integrity Response" messages. If the match is successful, the receiver saves the Sequence Number from the INTEGRITY object as the latest sequence number received with the key identifier included in the CHALLENGE.
「Integrity Response」メッセージは、返されたCHALLENGEオブジェクトが「Integrity Challenge」メッセージで送信されたオブジェクトと一致する場合にのみ、受信者（チャレンジャー）によって受け入れられます。これにより、古い「整合性応答」メッセージの再生が防止されます。一致が成功した場合、受信者はINTEGRITYオブジェクトのシーケンス番号を、CHALLENGEに含まれるキー識別子とともに受信した最新のシーケンス番号として保存します。
If a response is not received within a given period of time, the challenge is repeated. When the integrity handshake successfully completes, the receiver begins accepting normal RSVP signaling messages from that sender and ignores any other "Integrity Response" messages.
一定時間内に応答がない場合は、チャレンジが繰り返されます。整合性ハンドシェイクが正常に完了すると、受信者はその送信者からの通常のRSVPシグナリングメッセージの受け入れを開始し、他の「整合性応答」メッセージを無視します。
The Handshake Flag (HF) is used to allow implementations the flexibility of not including the integrity handshake mechanism. By setting this flag to 1, message senders that implement the integrity handshake distinguish themselves from those that do not. Receivers SHOULD NOT attempt to handshake with senders whose INTEGRITY object has HF = 0.
ハンドシェイクフラグ（HF）を使用すると、インテグリティハンドシェイクメカニズムを含めない柔軟性を実装できます。このフラグを1に設定することにより、整合性ハンドシェイクを実装するメッセージ送信者は、そうでないメッセージ送信者と区別されます。受信者は、INTEGRITYオブジェクトがHF = 0である送信者とのハンドシェイクを試みるべきではありません（SHOULD NOT）。
An integrity handshake may not be necessary in all environments. A common use of RSVP integrity will be between peering domain routers, which are likely to be processing a steady stream of RSVP messages due to aggregation effects. When a router restarts after a crash, valid RSVP messages from peering senders will probably arrive within a short time. Assuming that replay messages are injected into the stream of valid RSVP messages, there may be only a small window of opportunity for a replay attack before a valid message is processed. This valid message will set the largest sequence number seen to a value greater than any number that had been stored prior to the crash, preventing any further replays.
整合性ハンドシェイクは、すべての環境で必要なわけではありません。 RSVP整合性の一般的な用途は、ピアリングドメインルーター間です。ピアリングドメインルーターは、集約効果により、RSVPメッセージの安定したストリームを処理する可能性があります。クラッシュ後にルーターが再起動すると、ピアリング送信者からの有効なRSVPメッセージがおそらく短時間で到着します。有効なRSVPメッセージのストリームにリプレイメッセージが挿入されていると仮定すると、有効なメッセージが処理される前に、リプレイ攻撃の機会はごくわずかしかない可能性があります。この有効なメッセージは、見られる最大のシーケンス番号を、クラッシュ前に保存されていたどの番号よりも大きい値に設定し、それ以上の再生を防ぎます。
On the other hand, not using an integrity handshake could allow exposure to replay attacks if there is a long period of silence from a given sender following a restart of a receiver. Hence, it SHOULD be an administrative decision whether or not the receiver performs an integrity handshake with senders that are willing to respond to "Integrity Challenge" messages, and whether it accepts any messages from senders that refuse to do so. These decisions will be based on assumptions related to a particular network environment.
一方、整合性ハンドシェイクを使用しないと、受信者の再起動後に特定の送信者から長期間の無音状態が続く場合、リプレイ攻撃にさらされる可能性があります。したがって、それは、受信者が「整合性チャレンジ」メッセージに応答してよい送信者との整合性ハンドシェイクを実行するかどうか、およびそうすることを拒否する送信者からのメッセージを受け入れるかどうかの管理上の決定です。これらの決定は、特定のネットワーク環境に関連する仮定に基づいています。
It is likely that the IETF will define a standard key management protocol. It is strongly desirable to use that key management protocol to distribute RSVP Authentication Keys among communicating RSVP implementations. Such a protocol would provide scalability and significantly reduce the human administrative burden. The Key Identifier can be used as a hook between RSVP and such a future protocol. Key management protocols have a long history of subtle flaws that are often discovered long after the protocol was first described in public. To avoid having to change all RSVP implementations should such a flaw be discovered, integrated key management protocol techniques were deliberately omitted from this specification.
IETFが標準の鍵管理プロトコルを定義する可能性があります。通信中のRSVP実装間でRSVP認証キーを配布するには、そのキー管理プロトコルを使用することが強く望まれます。このようなプロトコルはスケーラビリティを提供し、人間の管理負担を大幅に軽減します。キー識別子は、RSVPとそのような将来のプロトコルとの間のフックとして使用できます。鍵管理プロトコルには微妙な欠陥の長い歴史があり、プロトコルが最初に公開されてからかなり後に発見されることがよくあります。そのような欠陥が発見された場合にすべてのRSVP実装を変更する必要がないように、統合されたキー管理プロトコル技術はこの仕様から意図的に省略されました。
Each key has a lifetime associated with it that is recorded in all systems (sender and receivers) configured with that key. The concept of a "key lifetime" merely requires that the earliest (KeyStartValid) and latest (KeyEndValid) times that the key is valid be programmable in a way the system understands. Certain key generation mechanisms, such as Kerberos or some public key schemes, may directly produce ephemeral keys. In this case, the lifetime of the key is implicitly defined as part of the key.
各キーには、そのキーで構成されたすべてのシステム（送信者と受信者）に記録されているライフタイムが関連付けられています。 「キーの有効期間」の概念は、キーが有効である最も早い（KeyStartValid）と最も遅い（KeyEndValid）の時間が、システムが理解する方法でプログラム可能であることを必要とするだけです。 Kerberosや一部の公開鍵スキームなどの特定の鍵生成メカニズムは、一時鍵を直接生成する場合があります。この場合、キーの有効期間はキーの一部として暗黙的に定義されます。
In general, no key is ever used outside its lifetime (but see Section 5.3). Possible mechanisms for managing key lifetime include the Network Time Protocol and hardware time-of-day clocks.
一般に、有効期間外にキーが使用されることはありません（ただし、セクション5.3を参照）。キーの有効期間を管理するための考えられるメカニズムには、ネットワークタイムプロトコルとハードウェア時刻クロックがあります。
To maintain security, it is advisable to change the RSVP Authentication Key on a regular basis. It should be possible to switch the RSVP Authentication Key without loss of RSVP state or denial of reservation service, and without requiring people to change all the keys at once. This requires an RSVP implementation to support the storage and use of more than one active RSVP Authentication Key at the same time. Hence both the sender and receivers might have multiple active keys for a given security association.
セキュリティを維持するために、RSVP認証キーを定期的に変更することをお勧めします。 RSVP状態を失うことなく、または予約サービスを拒否することなく、またすべてのキーを一度に変更する必要なしに、RSVP認証キーを切り替えることができるはずです。これには、同時に複数のアクティブなRSVP認証キーの保存と使用をサポートするRSVP実装が必要です。したがって、送信者と受信者の両方が、特定のセキュリティアソシエーションに対して複数のアクティブなキーを持っている可能性があります。
Since keys are shared between a sender and (possibly) multiple receivers, there is a region of uncertainty around the time of key switch-over during which some systems may still be using the old key and others might have switched to the new key. The size of this uncertainty region is related to clock synchrony of the systems. Administrators should configure the overlap between the expiration time of the old key (KeyEndValid) and the validity of the new key (KeyStartValid) to be at least twice the size of this uncertainty interval. This will allow the sender to make the key switch-over at the midpoint of this interval and be confident that all receivers are now accepting the new key. For the duration of the overlap in key lifetimes, a receiver must be prepared to authenticate messages using either key.
キーは送信者と（場合によっては）複数の受信者の間で共有されるため、一部のシステムがまだ古いキーを使用していて、他のシステムが新しいキーに切り替えた可能性のあるキー切り替えの前後に不確実な領域があります。この不確実性領域のサイズは、システムのクロック同期に関連しています。管理者は、古いキーの有効期限（KeyEndValid）と新しいキーの有効期間（KeyStartValid）のオーバーラップを、この不確実性間隔のサイズの少なくとも2倍になるように構成する必要があります。これにより、送信者はこの間隔の中間点でキーを切り替えることができ、すべての受信者が新しいキーを受け入れるようになります。キーの有効期間が重複している間は、どちらかのキーを使用してメッセージを認証するようにレシーバーを準備する必要があります。
During a key switch-over, it will be necessary for each receiver to handshake with the sender using the new key. As stated before, a receiver has the choice of initiating a handshake during the switchover or postponing the handshake until the receipt of a message using that key.
キーの切り替え中は、各受信者が新しいキーを使用して送信者とハンドシェイクする必要があります。前述のように、受信者はスイッチオーバー中にハンドシェイクを開始するか、そのキーを使用するメッセージの受信までハンドシェイクを延期するかを選択できます。
Requirements on an implementation are as follows:
実装の要件は次のとおりです。
o It is strongly desirable that a hypothetical security breach in one Internet protocol not automatically compromise other Internet protocols. The Authentication Key of this specification SHOULD NOT be stored using protocols or algorithms that have known flaws.
o 1つのインターネットプロトコルの仮想セキュリティ違反が他のインターネットプロトコルを自動的に侵害しないことが強く望まれます。この仕様の認証キーは、既知の欠陥があるプロトコルまたはアルゴリズムを使用して保存してはなりません。
o An implementation MUST support the storage and use of more than one key at the same time, for both sending and receiving systems.
o 実装は、送信システムと受信システムの両方で、同時に複数のキーの保存と使用をサポートする必要があります。
o An implementation MUST associate a specific lifetime (i.e., KeyStartValid and KeyEndValid) with each key and the corresponding Key Identifier.
o 実装は、特定の有効期間（つまり、KeyStartValidとKeyEndValid）を各キーと対応するキー識別子に関連付ける必要があります。
o An implementation MUST support manual key distribution (e.g., the privileged user manually typing in the key, key lifetime, and key identifier on the console). The lifetime may be infinite.
o 実装は手動のキー配布をサポートする必要があります（たとえば、特権ユーザーが手動でキー、キーの有効期間、およびコンソールでのキー識別子を入力する）。寿命は無限かもしれません。
o If more than one algorithm is supported, then the implementation MUST require that the algorithm be specified for each key at the time the other key information is entered.
o 複数のアルゴリズムがサポートされている場合、実装では、他のキー情報が入力されるときに各キーに対してアルゴリズムを指定する必要があります。
o Keys that are out of date MAY be automatically deleted by the implementation.
o 古いキーは実装によって自動的に削除される場合があります。
o Manual deletion of active keys MUST also be supported.
o アクティブなキーの手動削除もサポートする必要があります。
o Key storage SHOULD persist across a system restart, warm or cold, to ease operational usage.
o キーストレージは、運用の使用を容易にするために、システムの再起動（ウォームまたはコールド）全体にわたって維持する必要があります。
It is possible that the last key for a given security association has expired. When this happens, it is unacceptable to revert to an unauthenticated condition, and not advisable to disrupt current reservations. Therefore, the system should send a "last authentication key expiration" notification to the network manager and treat the key as having an infinite lifetime until the lifetime is extended, the key is deleted by network management, or a new key is configured.
特定のセキュリティアソシエーションの最後のキーが期限切れになっている可能性があります。これが発生した場合、認証されていない状態に戻すことは受け入れられず、現在の予約を中断することはお勧めできません。したがって、システムは「最後の認証キーの有効期限」通知をネットワークマネージャーに送信し、ライフタイムが延長されるか、ネットワーク管理によってキーが削除されるか、新しいキーが構成されるまで、キーを無期限のライフタイムとして扱う必要があります。
To conform to this specification, an implementation MUST support all of its aspects. The HMAC-MD5 authentication algorithm defined in [7] MUST be implemented by all conforming implementations. A conforming implementation MAY also support other authentication algorithms such as NIST's Secure Hash Algorithm (SHA). Manual key distribution as described above MUST be supported by all conforming implementations. All implementations MUST support the smooth key roll over described under "Key Management Procedures."
この仕様に準拠するには、実装はそのすべての側面をサポートする必要があります。 [7]で定義されているHMAC-MD5認証アルゴリズムは、すべての適合実装によって実装されなければなりません（MUST）。適合実装は、NISTのセキュアハッシュアルゴリズム（SHA）などの他の認証アルゴリズムもサポートする場合があります。上記の手動による鍵配布は、すべての準拠する実装でサポートされている必要があります。すべての実装は、「キー管理手順」で説明されているスムーズなキーロールオーバーをサポートする必要があります。
Implementations SHOULD support a standard key management protocol for secure distribution of RSVP Authentication Keys once such a key management protocol is standardized by the IETF.
実装は、そのようなキー管理プロトコルがIETFによって標準化されると、RSVP認証キーの安全な配布のための標準キー管理プロトコルをサポートする必要があります（SHOULD）。
Kerberos[10] MAY be used to generate the RSVP Authentication key used in generating a signature in the Integrity Object sent from a RSVP sender to a receiver. Kerberos key generation avoids the use of shared keys between RSVP senders and receivers such as hosts and routers. Kerberos allows for the use of trusted third party keying relationships between security principals (RSVP sender and receivers) where the Kerberos key distribution center(KDC) establishes an ephemeral session key that is subsequently shared between RSVP sender and receivers. In the multicast case all receivers of a multicast RSVP message MUST share a single key with the KDC (e.g. the receivers are in effect the same security principal with respect to Kerberos).
Kerberos [10]を使用して、RSVP送信者から受信者に送信されるIntegrityオブジェクトで署名を生成するときに使用されるRSVP認証キーを生成できます。 Kerberosキーの生成により、RSVP送信者と受信者（ホストやルーターなど）間での共有キーの使用が回避されます。 Kerberosでは、セキュリティプリンシパル（RSVP送信者と受信者）間の信頼できるサードパーティのキーイング関係を使用できます。Kerberosキー配布センター（KDC）は、その後RSVP送信者と受信者の間で共有される一時的なセッションキーを確立します。マルチキャストの場合、マルチキャストRSVPメッセージのすべての受信者はKDCと単一の鍵を共有する必要があります（たとえば、受信者はKerberosに関して事実上同じセキュリティプリンシパルです）。
The Key information determined by the sender MAY specify the use of Kerberos in place of configured shared keys as the mechanism for establishing a key between the sender and receiver. The Kerberos identity of the receiver is established as part of the sender's interface configuration or it can be established through other mechanisms. When generating the first RSVP message for a specific key identifier the sender requests a Kerberos service ticket and gets back an ephemeral session key and a Kerberos ticket from the KDC. The sender encapsulates the ticket and the identity of the sender in an Identity Policy Object[2]. The sender includes the Policy Object in the RSVP message. The session key is then used by the sender as the RSVP Authentication key in section 4.1 step (3) and is stored as Key information associated with the key identifier.
送信者によって決定されたキー情報は、送信者と受信者の間のキーを確立するためのメカニズムとして、構成された共有キーの代わりにKerberosの使用を指定してもよい（MAY）。受信者のKerberos IDは、送信者のインターフェース構成の一部として確立されるか、他のメカニズムを通じて確立することができます。特定のキー識別子の最初のRSVPメッセージを生成するとき、送信者はKerberosサービスチケットを要求し、KDCから一時セッションキーとKerberosチケットを取得します。送信者は、チケットと送信者のIDを識別ポリシーオブジェクト[2]にカプセル化します。送信者は、RSVPメッセージにポリシーオブジェクトを含めます。その後、セッションキーはセクション4.1のステップ（3）でRSVP認証キーとして送信者によって使用され、キー識別子に関連付けられたキー情報として保存されます。
Upon RSVP Message reception, the receiver retrieves the Kerberos Ticket from the Identity Policy Object, decrypts the ticket and retrieves the session key from the ticket. The session key is the same key as used by the sender and is used as the key in section 4.2 step (3). The receiver stores the key for use in processing subsequent RSVP messages.
RSVPメッセージの受信時に、受信者はアイデンティティポリシーオブジェクトからKerberosチケットを取得し、チケットを復号化して、チケットからセッションキーを取得します。セッションキーは、送信者が使用するものと同じキーであり、セクション4.2のステップ（3）でキーとして使用されます。受信者は、後続のRSVPメッセージの処理に使用するキーを保存します。
Kerberos tickets have lifetimes and the sender MUST NOT use tickets that have expired. A new ticket MUST be requested and used by the sender for the receiver prior to the ticket expiring.
Kerberosチケットには有効期限があり、送信者は有効期限が切れたチケットを使用してはなりません（MUST NOT）。新しいチケットは、チケットが期限切れになる前に、送信者が受信者に要求して使用する必要があります。
Kerberos tickets are relatively long (> 500 bytes) and it is not necessary to send a ticket in every RSVP message. The ephemeral session key can be cached by the sender and receiver and can be used for the lifetime of the Kerberos ticket. In this case, the sender only needs to include the Kerberos ticket in the first Message generated. Subsequent RSVP messages use the key identifier to retrieve the cached key (and optionally other identity information) instead of passing tickets from sender to receiver in each RSVP message.
Kerberosチケットは比較的長く（> 500バイト）、すべてのRSVPメッセージでチケットを送信する必要はありません。エフェメラルセッションキーは、送信者と受信者によってキャッシュされ、Kerberosチケットの有効期間中使用できます。この場合、送信者は最初に生成されるメッセージにKerberosチケットを含めるだけで済みます。後続のRSVPメッセージは、各RSVPメッセージで送信者から受信者にチケットを渡す代わりに、キー識別子を使用して、キャッシュされたキー（およびオプションで他のID情報）を取得します。
A receiver may not have cached key state with an associated Key Identifier due to reboot or route changes. If the receiver's policy indicates the use of Kerberos keys for integrity checking, the receiver can send an integrity Challenge message back to the sender. Upon receiving an integrity Challenge message a sender MUST send an Identity object that includes the Kerberos ticket in the integrity Response message, thereby allowing the receiver to retrieve and store the session key from the Kerberos ticket for subsequent Integrity checking.
レシーバーは、リブートまたはルート変更のために、関連付けられたキー識別子を持つキー状態をキャッシュしていない可能性があります。受信者のポリシーが整合性チェックにKerberosキーの使用を示している場合、受信者は整合性チャレンジメッセージを送信者に送り返すことができます。完全性チャレンジメッセージを受信すると、送信者は、完全性応答メッセージにKerberosチケットを含むIdentityオブジェクトを送信する必要があります。
This document is derived directly from similar work done for OSPF and RIP Version II, jointly by Ran Atkinson and Fred Baker. Significant editing was done by Bob Braden, resulting in increased clarity. Significant comments were submitted by Steve Bellovin, who actually understands this stuff. Matt Crawford and Dan Harkins helped revise the document.
このドキュメントは、ランアトキンソンとフレッドベイカーが共同でOSPFおよびRIPバージョンIIに対して行った同様の作業から直接派生しています。重要な編集はボブ・ブレーデンによって行われ、結果がより明確になりました。重要なコメントは、実際にこのことを理解しているSteve Bellovinによって提出されました。 Matt CrawfordとDan Harkinsが文書の改訂を手伝った。
[1] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[1] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「Resource ReSerVation Protocol（RSVP）-Version 1 Functional Specification」、RFC 2205、1997年9月。
[2] Yadav, S., et al., "Identity Representation for RSVP", RFC 2752, January 2000.
[2] Yadav、S。、他、「RSVPのID表現」、RFC 2752、2000年1月。
[3] Atkinson, R. and S. Kent, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[3] Atkinson、R。およびS. Kent、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[4] Maughan, D., Schertler, M., Schneider, M. and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
[4] Maughan、D.、Schertler、M.、Schneider、M. and J. Turner、 "Internet Security Association and Key Management Protocol（ISAKMP）"、RFC 2408、November 1998。
[5] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[5] ケント、S.、R。アトキンソン、「IP認証ヘッダー」、RFC 2402、1998年11月。
[6] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[6] Kent、S。およびR. Atkinson、「IP Encapsulating Security Payload（ESP）」、RFC 2406、1998年11月。
[7] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, March 1996.
[7] Krawczyk、H.、Bellere、M。、およびR. Canetti、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、1996年3月。
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[8] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[9] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[9] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、1981年9月。
[10] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[10] コールJ.およびC.ノイマン、「Kerberosネットワーク認証サービス（V5）」、RFC 1510、1993年9月。
This entire memo describes and specifies an authentication mechanism for RSVP that is believed to be secure against active and passive attacks.
このメモ全体は、アクティブおよびパッシブ攻撃に対して安全であると考えられているRSVPの認証メカニズムを説明および指定しています。
The quality of the security provided by this mechanism depends on the strength of the implemented authentication algorithms, the strength of the key being used, and the correct implementation of the security mechanism in all communicating RSVP implementations. This mechanism also depends on the RSVP Authentication Keys being kept confidential by all parties. If any of these assumptions are incorrect or procedures are insufficiently secure, then no real security will be provided to the users of this mechanism.
このメカニズムによって提供されるセキュリティの品質は、実装されている認証アルゴリズムの強度、使用されているキーの強度、およびすべての通信RSVP実装でのセキュリティメカニズムの正しい実装に依存します。このメカニズムは、RSVP認証キーがすべての関係者によって機密に保たれていることにも依存します。これらの仮定のいずれかが正しくない場合、または手順の安全性が不十分である場合、このメカニズムのユーザーには実際のセキュリティは提供されません。
While the handshake "Integrity Response" message is integrity-checked, the handshake "Integrity Challenge" message is not. This was done intentionally to avoid the case when both peering routers do not have a starting sequence number for each other's key. Consequently, they will each keep sending handshake "Integrity Challenge" messages that will be dropped by the other end. Moreover, requiring only the response to be integrity-checked eliminates a dependency on an security association in the opposite direction.
ハンドシェイクの「整合性応答」メッセージは整合性チェックされますが、ハンドシェイクの「整合性チャレンジ」メッセージはチェックされません。これは、両方のピアリングルーターが互いのキーの開始シーケンス番号を持たない場合を避けるために意図的に行われました。その結果、それぞれが相手側によってドロップされるハンドシェイクの「整合性チャレンジ」メッセージを送信し続けます。さらに、整合性チェックの応答のみを要求することで、反対方向のセキュリティアソシエーションへの依存を排除できます。
This, however, lets an intruder generate fake handshaking challenges with a certain challenge cookie. It could then save the response and attempt to play it against a receiver that is in recovery. If it was lucky enough to have guessed the challenge cookie used by the receiver at recovery time it could use the saved response. This response would be accepted, since it is properly signed, and would have a smaller sequence number for the sender because it was an old message. This opens the receiver up to replays. Still, it seems very difficult to exploit. It requires not only guessing the challenge cookie (which is based on a locally known secret) in advance, but also being able to masquerade as the receiver to generate a handshake "Integrity Challenge" with the proper IP address and not being caught.
ただし、これにより、侵入者は特定のチャレンジCookieを使用して偽のハンドシェイクチャレンジを生成できます。その後、応答を保存し、回復中のレシーバーに対して再生しようとする可能性があります。回復時に受信者が使用するチャレンジCookieを推測できたのが幸運だった場合、保存された応答を使用できます。この応答は適切に署名されているため受け入れられ、古いメッセージであるため送信者のシーケンス番号は小さくなります。これにより、レシーバーがリプレイできるようになります。それでも、悪用するのは非常に難しいようです。チャレンジCookie（ローカルで既知のシークレットに基づく）を事前に推測するだけでなく、適切なIPアドレスを使用してハンドシェイク「整合性チャレンジ」を生成し、キャッチされないように、レシーバーになりすますことも必要です。
Confidentiality is not provided by this mechanism. If confidentiality is required, IPSEC ESP [6] may be the best approach, although it is subject to the same criticisms as IPSEC Authentication, and therefore would be applicable only in specific environments. Protection against traffic analysis is also not provided. Mechanisms such as bulk link encryption might be used when protection against traffic analysis is required.
このメカニズムでは機密性は提供されません。機密性が必要な場合は、IPSEC ESP [6]が最善のアプローチである可能性がありますが、IPSEC認証と同じ批判の対象となるため、特定の環境でのみ適用されます。トラフィック分析に対する保護も提供されていません。トラフィック分析に対する保護が必要な場合は、バルクリンク暗号化などのメカニズムを使用できます。
Fred Baker Cisco Systems 519 Lado Drive Santa Barbara, CA 93111
Fred Baker Cisco Systems 519 Lado Drive Santa Barbara、CA 93111
Phone: (408) 526-4257 EMail: fred@cisco.com
電話：（408）526-4257メール：fred@cisco.com
Bob Lindell USC Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292
ボブリンデルUSC情報科学研究所4676アドミラルティウェイマリーナデルレイ、カリフォルニア90292
Phone: (310) 822-1511 EMail: lindell@ISI.EDU
電話：（310）822-1511メール：lindell@ISI.EDU
Mohit Talwar Microsoft Corporation One Microsoft Way Redmond, WA 98052
もひｔ たゎｒ みｃろそｆｔ こｒぽらちおん おね みｃろそｆｔ わｙ れｄもんｄ、 わ ９８０５２
Phone: +1 425 705 3131
EMail: mohitt@microsoft.com
This appendix describes a generic interface to Key Management. This description is at an abstract level realizing that implementations may need to introduce small variations to the actual interface.
この付録では、キー管理の一般的なインターフェイスについて説明します。この説明は、実装が実際のインターフェースに小さなバリエーションを導入する必要がある場合があることを理解する抽象的なレベルです。
At the start of execution, RSVP would use this interface to obtain the current set of relevant keys for sending and receiving messages. During execution, RSVP can query for specific keys given a Key Identifier and Source Address, discover newly created keys, and be informed of those keys that have been deleted. The interface provides both a polling and asynchronous upcall style for wider applicability.
実行の開始時に、RSVPはこのインターフェイスを使用して、メッセージの送受信に関連するキーの現在のセットを取得します。実行中、RSVPは、キー識別子と送信元アドレスを指定して特定のキーを照会し、新しく作成されたキーを検出して、削除されたこれらのキーについて通知を受けることができます。このインターフェースは、ポーリングと非同期アップコールの両方のスタイルを提供して、より広い適用性を実現します。
Information about keys is returned using the following KeyInfo data structure:
キーに関する情報は、次のKeyInfoデータ構造を使用して返されます。
KeyInfo {
Key Type (Send or Receive)
KeyIdentifier
Key
Authentication Algorithm Type and Mode
KeyStartValid
KeyEndValid
Status (Active or Deleted)
Outgoing Interface (for Send only)
Other Outgoing Security Association Selection Criteria
(for Send only, optional)
Sending System Address (for Receive Only)
}
This function returns a list of KeyInfo data structures corresponding to all of the keys that are configured for sending and receiving RSVP messages and have an Active Status. This function is usually called at the start of execution but there is no limit on the number of times that it may be called.
この関数は、RSVPメッセージの送受信用に構成され、アクティブステータスを持つすべてのキーに対応するKeyInfoデータ構造のリストを返します。この関数は通常、実行の開始時に呼び出されますが、呼び出される回数に制限はありません。
KM_DefaultKeyTable() -> KeyInfoList
When a message arrives with an unknown Key Identifier and Sending System Address pair, RSVP can use this function to query the Key Management System for the appropriate key. The status of the element returned, if any, must be Active.
不明なキー識別子と送信システムアドレスのペアを含むメッセージが到着すると、RSVPはこの関数を使用して、キー管理システムに適切なキーを照会できます。返される要素のステータスは、もしあれば、アクティブでなければなりません。
KM_GetRecvKey( INTEGRITY Object, SrcAddress ) -> KeyInfo
This function returns a list of KeyInfo data structures corresponding to any incremental changes that have been made to the default key table or requested keys since the last call to either KM_KeyTablePoll, KM_DefaultKeyTable, or KM_GetRecvKey. The status of some elements in the returned list may be set to Deleted.
この関数は、KM_KeyTablePoll、KM_DefaultKeyTable、またはKM_GetRecvKeyのいずれかの最後の呼び出し以降に、デフォルトのキーテーブルまたは要求されたキーに対して行われた増分変更に対応するKeyInfoデータ構造のリストを返します。返されたリストの一部の要素のステータスは、削除済みに設定されている場合があります。
KM_KeyTablePoll() -> KeyInfoList
Rather than repeatedly calling the KM_KeyTablePoll(), an implementation may choose to use an asynchronous event model. This function registers interest to key changes for a given Key Identifier or for all keys if no Key Identifier is specified. The upcall function is called each time a change is made to a key.
KM_KeyTablePoll()を繰り返し呼び出すのではなく、実装は非同期イベントモデルの使用を選択できます。この関数は、指定されたキー識別子、またはキー識別子が指定されていない場合はすべてのキーのキー変更に対する関心を登録します。 upcall関数は、キーが変更されるたびに呼び出されます。
KM_KeyUpdate ( Function [, KeyIdentifier ] )
KM_KeyUpdate（関数[、KeyIdentifier]）
where the upcall function is parameterized as follows:
upcall関数は次のようにパラメーター化されています。
Function ( KeyInfo )
関数（KeyInfo）
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（C）The Internet Society（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する派生物を、全体または一部を問わず、準備、コピー、公開、配布することができます。ただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。