RFC2747 日本語訳
2747 RSVP Cryptographic Authentication. F. Baker, B. Lindell, M.Talwar. January 2000. (Format: TXT=49477 bytes) (Updated by RFC3097) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group F. Baker
Request for Comments: 2747 Cisco
Category: Standards Track B. Lindell
USC/ISI
M. Talwar
Microsoft
January 2000
コメントを求めるワーキンググループF.ベイカー要求をネットワークでつないでください: 2747年のコクチマスカテゴリ: 標準化過程B.リンデルUSC/ISI M.Talwarマイクロソフト2000年1月
RSVP Cryptographic Authentication
RSVPの暗号の認証
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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オブジェクトの形式と使用について説明します。
1. Introduction
1. 序論
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プロトコル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
この入場制御機構の保全を確実にするために、RSVPは不正とスプーフィングに対してメッセージを保護する能力を必要とします。 このドキュメントは、RSVPメッセージの保全ホップごとに保護するためにメカニズムを定義します。 提案された体系は秘密のAuthentication Keyを使用することで計算されたメッセージの認証ダイジェストと合わせられたハッシュアルゴリズムを伝えます。 この体系は偽造に対する保護かメッセージ変更を提供します。 それぞれのRSVPメッセージのINTEGRITYオブジェクトは1回の使用系列でタグ付けをされます。
Baker, et al. Standards Track [Page 1] RFC 2747 RSVP Cryptographic Authentication January 2000
ベイカー、他 認証2000年1月の暗号の標準化過程[1ページ]RFC2747RSVP
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.
数。 これで、メッセージ受信機は、再生を特定して、したがって、反射攻撃を阻みます。 メッセージが明確に残っているので、提案されたメカニズムは秘密性を都合しません。 しかしながら、また、メカニズムもほとんどの国から輸出向きです。(プライバシーアルゴリズムが使用されることになっているなら、国は不可能でしょうに)。 以下に注意してください。 このドキュメントは用語「送付者」と「受信機」を[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]を使用することでKeyed-論じ尽くすことのMessage Authenticationの使用について説明します。 [7]に述べられるように、HMAC-SHA1などの、より強いハッシュは存在しています。 保証されるところでは、実装は、それらを利用可能にするように順調でしょう。 しかしながら、一般的な場合では、[7]は、HMAC-MD5が手元の目的に適切であり、望ましい性能の特性を持っているのを示します。 また、[7]はソースコードとこのアルゴリズム、恩恵のためのテストベクトルを相互運用性がないかどうかテストする人に提供します。 基線として暗号の認証を提供するRSVP実装にHMAC-MD5によって一般に含まれなければなりません、他の提案が任意の状態で(Conformance Requirementsの上のセクション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チェックサムは無効にされるかもしれません(ゼロに設定します)、メッセージダイジェストがはるかに強い保全チェックであるので。
1.1. Conventions used in this document
1.1. 本書では使用されるコンベンション
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[8]で説明されるように本書では解釈されることであるべきですか?
1.2. Why not use the Standard IPSEC Authentication Header?
1.2. なぜStandard IPSEC Authentication Headerを使用しませんか?
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の使用は以下の理由で拒絶されました。
Baker, et al. Standards Track [Page 2] RFC 2747 RSVP Cryptographic Authentication January 2000
ベイカー、他 認証2000年1月の暗号の標準化過程[2ページ]RFC2747RSVP
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のセキュリティ協会は送付先アドレスに基づいています。 RSVPメッセージがどちらのソースともよく定義されたか、または目的地がセキュリティ協会を基礎づけたのが、明確ではありません、ルータが同じソースアドレスを使用することでPATHとPATH TEARにメッセージを転送しなければならないとき送付者がSENDER TEMPLATEに記載したように。 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関係は必ず送付システムに目に見えるというわけではありません。 これらの議論はRSVPルータに基づくかぎ管理戦略の使用をIPSECの代わりにRSVPルータ協会に示します。
2. Data Structures
2. データ構造
2.1. INTEGRITY Object Format
2.1. 保全オブジェクト形式
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オブジェクトで運ばれます。 同じINTEGRITYオブジェクト・タイプはIPv4とIPv6の両方に使用されます。
The INTEGRITY object has the following format:
INTEGRITYオブジェクトには、以下の形式があります:
Keyed Message Digest INTEGRITY Object: Class = 4, C-Type = 1
合わせられたメッセージダイジェスト保全オブジェクト: クラスは4、C-タイプ=1と等しいです。
+-------------+-------------+-------------+-------------+
| Flags | 0 (Reserved)| |
+-------------+-------------+ +
| Key Identifier |
+-------------+-------------+-------------+-------------+
| Sequence Number |
| |
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ Keyed Message Digest |
| |
+ +
| |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+ | 旗| 0(予約されます)| | +-------------+-------------+ + | 主要な識別子| +-------------+-------------+-------------+-------------+ | 一連番号| | | +-------------+-------------+-------------+-------------+ | | + + | | + 合わせられたメッセージダイジェスト| | | + + | | +-------------+-------------+-------------+-------------+
Baker, et al. Standards Track [Page 3] RFC 2747 RSVP Cryptographic Authentication January 2000
ベイカー、他 認証2000年1月の暗号の標準化過程[3ページ]RFC2747RSVP
o Flags: An 8-bit field with the following format:
o 旗: 以下の形式がある8ビットの分野:
Flags
旗
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| H | |
| F | 0 |
+---+---+---+---+---+---+---+---+
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: 握手Flag(HF)は保全握手メカニズム(セクション4.3)に関係があります。 保全握手メッセージSHOULDに応じても構わないと思っているメッセージ送付者がこの旗を1に設定しますが、保全握手メッセージSHOULDを拒絶する人が0にこれを設定します。
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)の何らかの組み合わせを使用することで局所的にユニークなKey Identifiersを生成することができます。 Key Identifierと送付システムの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.
系列Number値はINTEGRITYオブジェクト[それぞれのRSVPメッセージの]を関連キーの生涯ユニークなタグに供給するどんな単調に増加する系列であるかもしれません。 一連番号世代に関する詳細はセクション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バイト長になるでしょう。
2.2. Security Association
2.2. セキュリティ協会
The sending and receiving systems maintain a security association for each authentication key that they share. This security association includes the following parameters:
発信と受電方式はそれらが共有するそれぞれの認証キーのためにセキュリティ協会を維持します。 このセキュリティ協会は以下のパラメタを含めます:
Baker, et al. Standards Track [Page 4] RFC 2747 RSVP Cryptographic Authentication January 2000
ベイカー、他 認証2000年1月の暗号の標準化過程[4ページ]RFC2747RSVP
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 関連送付インタフェースと他のセキュリティ協会選択評価基準[Sending SystemのREQUIRED]。
o Source Address of the sending system [REQUIRED at Receiving
System].
o 送付システム[Receiving SystemのREQUIRED]のソースAddress。
o Latest sending sequence number used with this key identifier
[REQUIRED at Sending System].
o 最新の送付一連番号はこの主要な識別子と共に[Sending SystemのREQUIRED]を使用しました。
o List of last N sequence numbers received with this key
identifier [REQUIRED at Receiving System].
o 最後のN一連番号のリストはこの主要な識別子[Receiving SystemのREQUIRED]で受信されました。
3. Generating Sequence Numbers
3. 一連番号を生成します。
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回であり、保全キーの生涯、それが現在、使用中です。 受信機は、明白に新しいメッセージか再演されたメッセージを見分けるのにこの特性を使用できます。 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年と定義されるなら、1秒あたりおよそ585gigaMessagesの平均相場でメッセージをRSVPに送ることができるくらいの一連番号値があるでしょうに。 32ビットの一連番号はこの平均相場を1秒あたりおよそ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つの一連番号世代手順が以下で説明されます。
Baker, et al. Standards Track [Page 5] RFC 2747 RSVP Cryptographic Authentication January 2000
ベイカー、他 認証2000年1月の暗号の標準化過程[5ページ]RFC2747RSVP
3.1. Simple Sequence Numbers
3.1. 簡単な一連番号
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.
最も簡単なアプローチはユニーク配列が数であるとメッセージカウンタを使用することで生成することです。 メッセージが与えられたキーのために送られるたびに一連番号カウンタは増加されています。 このカウンタの現行価値は絶えずか定期的に安定貯蔵に節約されます。 再開の後に、カウンタは、この安定貯蔵を使用することで回復されます。 カウンタが定期的に安定貯蔵に保存されるなら、カウントは、失敗時点でカウンタのどんな可能な値よりも大きくなるように保存している値を増強することによって、回復されるでしょうに。 これを計算できます、カウンタが安定貯蔵に保存された間隔を知って、その量に従って保存された値を増加して。
3.2. Sequence Numbers Based on a Real Time Clock
3.2. リアルタイムクロックに基づく一連番号
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より長いカチカチする音を取った後に回復時間にそれを仮定する場合、再開の後に安全に下位のビット単位でメッセージカウンタをゼロにリセットできます。
3.3. Sequence Numbers Based on a Network Recovered Clock
3.3. ネットワークの回復している時計に基づく一連番号
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を使用することでリアルタイムクロックをネットワークから取り戻すかもしれません。 再開に続いて、時計がいったん回収されると、一連番号世代手順は上で説明された手順と同じでしょう。
Baker, et al. Standards Track [Page 6] RFC 2747 RSVP Cryptographic Authentication January 2000
ベイカー、他 認証2000年1月の暗号の標準化過程[6ページ]RFC2747RSVP
4. Message Processing
4. メッセージ処理
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メッセージが適切なKeyを使用することで生成されたINTEGRITYオブジェクトをインタフェースが含む発信に固定したのを保証しなければなりません。 受信機は、インタフェースを受けるタイプ「保全挑戦」(セクション4.3)を除いて、aでの到着が保証した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.
それぞれの送付者SHOULDは機密保護している発信あたりの異なったセキュリティ協会(そして、キー)を連結させます(または、LIH)。 管理者がサブネット(またはさらに言えば彼らのネットワークで)で単一のセキュリティ協会を使用することですべてのルータとホストを構成しているかもしれない間、実装は、各送付者がそれぞれの機密保護しているインタフェースで異なったセキュリティ協会を使用することで発信するかもしれないと仮定しなければなりません。 送付者では、セキュリティ協会選択はメッセージが送られるインタフェースに基づいています。 この選択は追加評価基準を含むかもしれません、送付者か受信機[2]の送付先アドレス(多くのホストがいる放送LANの上にメッセージユニキャストを送るとき)やユーザアイデンティティのように。 最終的に、すべての意図しているメッセージ受取人がこのセキュリティ協会に参加するべきです。 非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.
受信機はKey Identifierに基づくキーと送付システムのIPアドレスを選択します。 Key IdentifierはINTEGRITYオブジェクトに含まれています。 RSVP_HOPオブジェクトかそれともそれがIPソースアドレスから存在しないかどうかから(PathErrとResvConfメッセージに関してそうであるように)送付システムのアドレスを得ることができます。 送付者にとって、Key Identifierがユニークであるので、このメソッドは唯一キーを特定します。
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.
保全メカニズムはRSVPメッセージのために処理規則をわずかに変更します、ともに、メッセージにINTEGRITYオブジェクトを含んでいると機密保護している送付インタフェースが移動して、受け入れるときメッセージが機密保護している受信インタフェースで受信されたとき。 これらの変更は以下で詳細です。
Baker, et al. Standards Track [Page 7] RFC 2747 RSVP Cryptographic Authentication January 2000
ベイカー、他 認証2000年1月の暗号の標準化過程[7ページ]RFC2747RSVP
4.1. Message Generation
4.1. メッセージ世代
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) 送付インタフェースと他の適切な評価基準(以上のように)は、Authentication Keyとハッシュアルゴリズムが使用されることを決定するのに使用されます。
(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に設定しなければなりません。 セクション2.1で指定された規則に従って、Handshake Flag(HF)は用意ができるべきです。
(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オブジェクトのSequence Number分野に置かれます。
(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) Key Identifierは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) メッセージの認証ダイジェストは、合わせられたハッシュアルゴリズムに関連してAuthentication Keyを使用することで計算されます。 HMAC-MD5アルゴリズムが使用されているとき、ハッシュ計算は[7]で説明されます。
(9) The digest is written into the Cryptographic Digest field of
the INTEGRITY object.
(9) ダイジェストはINTEGRITYオブジェクトのCryptographic Digest分野に書かれています。
4.2. Message Reception
4.2. メッセージレセプション
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分野は節約されます、そして、分野は次にゼロへのセットです。
Baker, et al. Standards Track [Page 8] RFC 2747 RSVP Cryptographic Authentication January 2000
ベイカー、他 認証2000年1月の暗号の標準化過程[8ページ]RFC2747RSVP
(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) Key Identifier分野と送付システムアドレスは、Authentication Keyとハッシュアルゴリズムが使用されることを唯一決定するのに使用されます。 Key Management System(付録1)がこの情報のために質問されるとき、このパケットの処理は遅れるかもしれません。
(4) A new keyed-digest is calculated using the indicated algorithm
and the Authentication Key.
(4) 新しい合わせられたダイジェストは、示されたアルゴリズムとAuthentication Keyを使用することで計算されます。
(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) メッセージがタイプ「保全応答」のものであるなら、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 Messagesに関して、一連番号は反射攻撃を防ぐために有効にされます、そして、無効の一連番号があるメッセージは受信機によって無視されます。
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)一連番号がなければなりません。 この簡単な処理規則はメッセージ反射攻撃を防ぎますが、限られた不適切なメッセージ配送を許容するのは変更していなければなりません。 例えば、炸裂でいくつかのメッセージを送るなら(a周期的では、ルータ、または機能の下側への裂け目の結果、発生していた状態でリフレッシュしてください)、それらを再命令するでしょうに、そして、次に、増加するオーダーに一連番号を受け取らないでしょう。
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が不適切なメッセージ配送に受信機の寛容を設定する管理構成を許す実装。 簡潔な解決法で、管理者は振舞いを再命令する最悪の場合に対応するメッセージウィンドウを指定できるでしょう。 例えば、1つは、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) それが(b) 受け取られた最大の一連番号かそれが再命令の窓に属す過去の一連番号であるより優れていてリストに記録されていないなら、容認された一連番号は有効です。 承認
Baker, et al. Standards Track [Page 9] RFC 2747 RSVP Cryptographic Authentication January 2000
ベイカー、他 認証2000年1月の暗号の標準化過程[9ページ]RFC2747RSVP
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.
一連番号は、リストについてそれをリストに追加して、下側から数を移すのが終わるのを含意します。 リストの下側の端の下に一連番号がある状態で受け取ったか、またはリストで見られるとマークしたメッセージは捨てられます。
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) 「保全応答」メッセージは、挑戦メッセージに受け取られたChallengeオブジェクトを使用することで形成されます。
(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アドレスに基づいて、上に概説された「メッセージ世代」ステップを使用して。 使用されるべきAuthentication Keyとハッシュアルゴリズムの選択は挑戦メッセージで提供された主要な識別子で決定します。
4.3. Integrity Handshake at Restart or Initialization of the Receiver
4.3. 受信機の再開か初期設定における保全握手
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.
始めの一連番号をライブAuthentication Keyに得るために、受信機は送付者と共に保全握手を開始するかもしれません。 そのキーで署名されたメッセージが到着するまで、この握手は、受信機のChallengeと送付者のResponseから成って、再開の間、開始されるか、または延期されるかもしれません。
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).
受信機が、特定のAuthentication Keyのために保全握手を開始するといったん決めると、それは、対応するセキュリティ協会で構成された送付システムのアドレスを使用することで送付者を特定します。 そして、受信機はRSVP Integrity Challengeメッセージを送付者に送ります。 このメッセージは、送付者のキーを特定するKey Identifierを含んでいて、推測するのを防ぐためにローカルの秘密に基づいているユニークな挑戦クッキーを食べなければなりません。[4])についてセクション2.5.3を見てください。 クッキーがローカルの秘密とユニークさを提供するタイムスタンプの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>
<保全Challengeメッセージ>:、:= <の一般的なヘッダー><挑戦>。
Baker, et al. Standards Track [Page 10] RFC 2747 RSVP Cryptographic Authentication January 2000
ベイカー、他 認証2000年1月の暗号の標準化過程[10ページ]RFC2747RSVP
he CHALLENGE object has the following format:
彼には、以下の形式がありますCHALLENGEが、反対する:
CHALLENGE Object: Class = 64, C-Type = 1
オブジェクトに挑戦してください: クラスは64、C-タイプ=1と等しいです。
+-------------+-------------+-------------+-------------+
| 0 (Reserved) | |
+-------------+-------------+ +
| Key Identifier |
+-------------+-------------+-------------+-------------+
| Challenge Cookie |
| |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+ | 0(予約されます)| | +-------------+-------------+ + | 主要な識別子| +-------------+-------------+-------------+-------------+ | 挑戦クッキー| | | +-------------+-------------+-------------+-------------+
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「保全応答」メッセージを返します。 また、それは「保全挑戦」にKey Identifierを含んでいることによって指定されたキーで署名された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>
<保全Responseメッセージ>:、:= 一般的な<の><保全><ヘッダー挑戦>。
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.
返されたCHALLENGEオブジェクトが「保全挑戦」メッセージで送られたものに合っている場合にだけ、受信機(挑戦者)は「保全応答」メッセージを受け入れます。 これは古い「保全応答」メッセージの再生を防ぎます。 マッチがうまくいくなら、受信機は主要な識別子がCHALLENGEに含まれている状態で受け取られた最新の一連番号としてINTEGRITYオブジェクトからSequence Numberを取っておきます。
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.
Handshake Flag(HF)は、保全握手メカニズムを含まない柔軟性を実装に許容するのに使用されます。 この旗を1に設定することによって、保全握手を実装するメッセージ送付者がそうしないそれらと自分たちを区別します。 INTEGRITYが反対する送付者との握手への受信機SHOULD NOT試みには、HF=0があります。
Baker, et al. Standards Track [Page 11] RFC 2747 RSVP Cryptographic Authentication January 2000
ベイカー、他 認証2000年1月の暗号の標準化過程[11ページ]RFC2747RSVP
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.
他方では、そこであるなら握手が暴露を許容できた保全を反射攻撃に使用しないで、受信機が送付者と共に保全握手を実行するかどうかという管理的意思決定が、「保全挑戦」メッセージに応じても構わないと思っていて、それがそうするのを拒否する送付者からどんなメッセージも受け入れるか否かに関係なく、a受信機したがって、それの再開の後をつける当然のことの送付者からの長期の沈黙はSHOULDですか? これらの決定は特定のネットワーク環境に関連する仮定に基づくでしょう。
5. Key Management
5. Key Management
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 Authenticationキーズを分配するために議定書を作るのは、使用するのにおいて強く望ましいです。 そのようなプロトコルは、スケーラビリティを提供して、人間の管理負担をかなり減少させるでしょう。 RSVPとそのような将来のプロトコルの間のフックとしてKey Identifierを使用できます。 かぎ管理プロトコルには、プロトコルが最初に公然と説明されたずっと後にしばしば発見される微妙な欠点の長い歴史があります。 そのような欠点が発見されるならすべてのRSVP実装を変えなければならないのを避けるために、統合かぎ管理プロトコルのテクニックは故意にこの仕様から省略されました。
5.1. Key Management Procedures
5.1. Key Management手順
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)時間がシステムが分かる方法でプログラマブルであることを単に必要とします。 ケルベロスかいくつかの公開鍵体系などのあるキー生成メカニズムは直接はかないキーを生産するかもしれません。 この場合、キーの寿命はそれとなくキーの一部と定義されます。
Baker, et al. Standards Track [Page 12] RFC 2747 RSVP Cryptographic Authentication January 2000
ベイカー、他 認証2000年1月の暗号の標準化過程[12ページ]RFC2747RSVP
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を見てください)。 主要な生涯を管理するための可能なメカニズムはNetwork Timeプロトコルとハードウェア時刻時計を含んでいます。
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 Authentication Keyを変えるのは賢明です。 RSVP状態の損失か予約サービスの否定なしで人々がすぐにすべてのキーを変えるのが必要であるなしでRSVP Authentication Keyを切り換えるのは可能であるべきです。 これは、同時に1アクティブなRSVP Authentication Keyのストレージと使用をサポートするために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.
オーバー主要なスイッチの間、送付者が新しいキーを使用している状態で、それは握手への各受信機に必要になるでしょう。 以前述べられるように、受信機には転換の間、握手を開始するか、またはそのキーを使用することでメッセージの領収書まで握手を延期することの選択があります。
5.2. Key Management Requirements
5.2. Key Management要件
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つのインターネットプロトコルにおける仮定している機密保護違反が、他のインターネットがプロトコルであると自動的に感染しないのは、強く望ましいです。 Authentication Key、この仕様SHOULD NOTにおいて、保存された使用プロトコルか欠点を知っていたアルゴリズムがそうです。
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 実装は同時に1個以上のキーのストレージと使用をサポートしなければなりません、発信と受電方式の両方のために。
Baker, et al. Standards Track [Page 13] RFC 2747 RSVP Cryptographic Authentication January 2000
ベイカー、他 認証2000年1月の暗号の標準化過程[13ページ]RFC2747RSVP
o An implementation MUST associate a specific lifetime (i.e.,
KeyStartValid and KeyEndValid) with each key and the
corresponding Key Identifier.
o 実装は特定の生涯(すなわち、KeyStartValidとKeyEndValid)をそれぞれの主要なKey Identifierと対応するKey Identifierに関連づけなければなりません。
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 1つ以上のアルゴリズムがサポートされるなら、実装は、もう片方の主要な情報が入力されるときアルゴリズムが各キーに指定されるのを必要としなければなりません。
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 主要なストレージSHOULDは、操作上の用法を緩和するために暖かいか冷たいシステムリスタートの向こう側に固執しています。
5.3. Pathological Case
5.3. 病理学的なケース
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.
与えられたセキュリティ協会のための最後のキーが期限が切れたのは、可能です。 これが起こるとき、現在の予約を中断するのは、非認証された状態に振り向けるのにおいて容認できなくて、賢明ではありません。 したがって、システムが、「最後の認証の主要な満了」通知をネットワークマネージャに送って、寿命が拡張されるまで無限の生涯を持っているとしてキーを扱うはずですか、キーがネットワークマネージメントで削除されるか、または新しいキーは構成されます。
6. Conformance Requirements
6. 順応要件
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認証アルゴリズムを実装しなければなりません。 また、従う実装は、他の認証がNISTのSecure Hash Algorithm(SHA)などのアルゴリズムであるとサポートするかもしれません。 実装を従わせて、上で説明される手動の主要な分配はすべてで後押しされていなければなりません。 実装が滑らかなキーを支えなければならないすべてが「Key Management手順」の下で説明されていた状態でひっくり返ります。
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によっていったん標準化されると、実装SHOULDはRSVP Authenticationキーズの安全な分配のために標準のかぎ管理プロトコルをサポートします。
Baker, et al. Standards Track [Page 14] RFC 2747 RSVP Cryptographic Authentication January 2000
ベイカー、他 認証2000年1月の暗号の標準化過程[14ページ]RFC2747RSVP
7. Kerberos generation of RSVP Authentication Keys
7. RSVP認証キーのケルベロス世代
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).
ケルベロス[10]は、RSVP送付者から受信機に送られたIntegrity Objectで署名を生成する際に使用されるRSVP Authenticationキーを生成するのに使用されるかもしれません。ケルベロスキー生成はホストやルータなどのRSVP送付者と受信機の間の共有されたキーの使用を避けます。 ケルベロスは信頼できる第三者機関のセキュリティ主体(RSVP送付者と受信機)の間のケルベロスの主要な配送センター(KDC)が次にRSVP送付者と受信機の間で共有されるはかないセッションキーを設立する関係を合わせる使用を考慮します。 マルチキャスト場合では、マルチキャストRSVPメッセージのすべての受信機が単一のキーをKDCと共有しなければなりません(事実上、例えば、受信機はケルベロスに関する同じセキュリティ主体です)。
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.
送付者で決定しているKey情報は送付者と受信機の間のキーを設立するためのメカニズムとしての構成された共有されたキーに代わってケルベロスの使用を指定するかもしれません。受信機のケルベロスのアイデンティティは他のメカニズムを通して送付者のインタフェース構成かそれの一部を確立できるように確立されます; 特定の主要な識別子への最初のRSVPメッセージを生成するとき、送付者は、KDCからケルベロスサービスチケットを要求して、はかないセッションキーとケルベロスチケットを取り戻します。 送付者はIdentity Policy Object[2]の送付者のチケットとアイデンティティをカプセルに入れります。 送付者はRSVPメッセージでPolicy Objectを入れます。 セッションキーは、次に、セクション4.1で主要なRSVP Authenticationが(3)を踏むとき送付者が使用されて、主要な識別子に関連しているKey情報として保存されます。
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 Messageレセプションでは、受信機は、Identity Policy ObjectからケルベロスTicketを検索して、チケットを解読して、チケットから主要なセッションを検索します。 セッションキーは、送付者による中古の同じ同じくらいキーであり、キーとしてセクション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.
ケルベロスチケットには、寿命があります、そして、送付者は期限が切れたチケットを使用してはいけません。 送付者は、チケットの期限が切れることの前に受信機に新しいチケットを要求されていて、使用しなければなりません。
7.1. Optimization when using Kerberos Based Authentication
7.1. ケルベロスBased Authenticationを使用するときの最適化
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
ケルベロスチケットは比較的長いです、そして、(>500バイト)あらゆるRSVPメッセージでチケットを送るのは必要ではありません。 はかないセッションキーを送付者と受信機でキャッシュできて、ケルベロスチケットの生涯に使用できます。 この場合、送付者は、Messageが生成した1番目にケルベロスチケットを含む必要があるだけです。 その後のRSVPメッセージは主要な識別子を使用します。
Baker, et al. Standards Track [Page 15] RFC 2747 RSVP Cryptographic Authentication January 2000
ベイカー、他 認証2000年1月の暗号の標準化過程[15ページ]RFC2747RSVP
retrieve the cached key (and optionally other identity information) instead of passing tickets from sender to receiver in each RSVP message.
キャッシュされた各RSVPで送付者から受信機までチケットを渡すことの代わりに主要な(そして、任意に他のアイデンティティ情報)メッセージを検索してください。
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.
受信機はリブートするのにおいて当然の関連Key Identifierかルート変化に伴う主要な状態をキャッシュしていないかもしれません。 受信機の方針がケルベロスキーの保全の照合の使用を示すなら、受信機は保全Challengeメッセージを送付者に送り返すことができます。 保全Challengeメッセージを受け取ると、送付者は保全Responseメッセージにケルベロスチケットを含んでいるIdentityオブジェクトを送らなければなりません、その結果、受信機がその後のIntegrityのケルベロスチケットから主要なセッションを検索して、保存するのを許容するのがチェックして。
8. Acknowledgments
8. 承認
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.
このドキュメントはRanアトキンソンとフレッド・ベイカーによって直接OSPFのために行われた同様の仕事とRIPバージョンIIから共同で引き出されます。 増強された明快をもたらして、重要な編集がボブ・ブレーデンによって行われました。 重要なコメントはスティーブBellovinによって提出されました。(実際に、Bellovinはこのものを理解しています)。 マット・クロフォードとダン・ハーキンズは、ドキュメントを改訂するのを助けました。
9. References
9. 参照
[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] ブレーデン、R.、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
[2] Yadav, S., et al., "Identity Representation for RSVP", RFC 2752,
January 2000.
[2]Yadav、S.、他、「RSVPのアイデンティティ表現」、RFC2752、2000年1月。
[3] Atkinson, R. and S. Kent, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[3] アトキンソンとR.とS.ケント、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、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.、シュナイダー、M.、およびJ.ターナー、「インターネットセキュリティ協会とKey Managementは(ISAKMP)について議定書の中で述べます」、RFC2408、1998年11月。
[5] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
[5] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。
[6] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[6] ケントとS.とR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。
[7] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, March 1996.
[7]Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1996年3月。
Baker, et al. Standards Track [Page 16] RFC 2747 RSVP Cryptographic Authentication January 2000
ベイカー、他 認証2000年1月の暗号の標準化過程[16ページ]RFC2747RSVP
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[8] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[9] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[9] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[10] Kohl, J. and C. Neuman, "The Kerberos Network Authentication
Service (V5)", RFC 1510, September 1993.
[10] コールとJ.とC.ヌーマン、「ケルベロスネットワーク認証サービス(V5)」、RFC1510 1993年9月。
10. Security Considerations
10. セキュリティ問題
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 Authenticationキーズによります。 これらの仮定のどれかが不正確であるか、または手順が不十分に安全であるなら、このメカニズムのユーザに物上担保を全く提供しないでしょう。
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.
しかしながら、これで、侵入者は、ある挑戦クッキーでにせのハンドシェイクが挑戦であると生成することができます。 それは、次に、応答を保存して、回復にはある受信機に対してそれをプレーするのを試みるかもしれません。 それが回復時間に受信機によって使用された挑戦クッキーを推測するほど幸運であるなら、保存している応答を使用するかもしれないでしょうに。 この応答を受け入れるでしょう、適切に署名されて、古いメッセージであったので送付者のための、よりわずかな一連番号を持っているでしょう、したがって。 これは受信機を再生まで開けます。 それでも、それは利用するのが非常に難しく見えます。 捕らえられるのではなく、適切なIPアドレスで握手が「保全挑戦」であると生成するために受信機のふりをするのが、あらかじめ挑戦クッキー(局所的に知られている秘密に基づいている)を推測するだけではなく、できもするのを必要とします。
Baker, et al. Standards Track [Page 17] RFC 2747 RSVP Cryptographic Authentication January 2000
ベイカー、他 認証2000年1月の暗号の標準化過程[17ページ]RFC2747RSVP
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 Authenticationと同じ批評を受けることがあって、したがって、特定の環境だけで適切でしょう。 また、トラヒック分析に対する保護は提供されません。 トラヒック分析に対する保護が必要であるときに、大量のリンク暗号化などのメカニズムは使用されるかもしれません。
11. Authors' Addresses
11. 作者のアドレス
Fred Baker Cisco Systems 519 Lado Drive Santa Barbara, CA 93111
フレッドベイカーシスコシステムズ519のLado Driveサンタバーバラ、カリフォルニア 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情報Sciences Institute4676海軍本部Wayマリナデルレイ、カリフォルニア 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
Mohit Talwarマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン 98052
Phone: +1 425 705 3131 EMail: mohitt@microsoft.com
以下に電話をしてください。 +1 3131年の425 705メール: mohitt@microsoft.com
Baker, et al. Standards Track [Page 18] RFC 2747 RSVP Cryptographic Authentication January 2000
ベイカー、他 認証2000年1月の暗号の標準化過程[18ページ]RFC2747RSVP
12. Appendix 1: Key Management Interface
12. 付録1: Key Managementインタフェース
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.
この付録はジェネリックインタフェースについてKey Managementに説明します。 この記述が実装が、実際のインタフェースに小さい変化を紹介する必要であるかもしれないとわかる抽象的なレベルにあります。
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は、メッセージの送受信のための現在のセットの関連キーを入手するのにこのインタフェースを使用するでしょう。 実行の間、Key IdentifierとSource Addressを考えて、RSVPは特定のキーのために質問できます、そして、新たに作成されたキーを発見してください、そして、削除されたそれらのキーにおいて知識があってください。 インタフェースは、より広い適用性のための世論調査と非同期なupcallスタイルの両方を提供します。
12.1. Data Structures
12.1. データ構造
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)
}
KeyInfo主要なType、(発信、Receive) KeyIdentifier Key Authentication Algorithm TypeとMode KeyStartValid KeyEndValid Status(能動態かDeleted)の出発しているInterface(Sendだけのための)他のOutgoing Security Association Selection Criteria(Sendに、唯一の、そして、任意の)送付System Address(Receive Onlyのための)
12.2. Default Key Table
12.2. デフォルトキーテーブル
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メッセージのために構成されて、Active Statusを持っているキーのすべてに対応するKeyInfoデータ構造のリストを返します。 この機能は実行の始めに通常呼ばれますが、限界が全くそれが呼ばれるかもしれないという回の数にありません。
KM_DefaultKeyTable() -> KeyInfoList
km_DefaultKeyTable()->KeyInfoList
Baker, et al. Standards Track [Page 19] RFC 2747 RSVP Cryptographic Authentication January 2000
ベイカー、他 認証2000年1月の暗号の標準化過程[19ページ]RFC2747RSVP
12.3. Querying for Unknown Receive Keys
12.3. 未知のために質問して、キーを受けてください。
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.
メッセージが未知のKey IdentifierとSending System Address組と共に到着するとき、RSVPは、適切なキーのためにKey Management Systemについて質問するのにこの機能を使用できます。 もしあれば返された要素の状態はActiveであるに違いありません。
KM_GetRecvKey( INTEGRITY Object, SrcAddress ) -> KeyInfo
km_GetRecvKey(保全オブジェクト、SrcAddress)->KeyInfo
12.4. Polling for Updates
12.4. アップデートのための世論調査
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.
この機能がデフォルトキーテーブルにされたどんな漸進的変化にも対応するKeyInfoデータ構造のリストを返すか、または最終以来の要求されたキーはKM_KeyTablePoll、KM_DefaultKeyTableかKM_GetRecvKeyのどちらかに呼びかけます。 返されたリストのいくつかの要素の状態はDeletedに設定されるかもしれません。
KM_KeyTablePoll() -> KeyInfoList
km_KeyTablePoll()->KeyInfoList
12.5. Asynchronous Upcall Interface
12.5. 非同期なUpcallインタフェース
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()と呼ぶよりむしろ、実装は、非同期的なイベントモデルを使用するのを選ぶかもしれません。 Key Identifierが全く指定されないなら、この機能は与えられたKey Identifierかすべてのキーのためにキーチェンジへの関心を示します。 upcall機能は変更をキーにするたびに呼ばれます。
KM_KeyUpdate ( Function [, KeyIdentifier ] )
km_KeyUpdate(機能[KeyIdentifier])
where the upcall function is parameterized as follows:
upcall機能が以下の通りparameterizedされるところ:
Function ( KeyInfo )
機能(KeyInfo)
Baker, et al. Standards Track [Page 20] RFC 2747 RSVP Cryptographic Authentication January 2000
ベイカー、他 認証2000年1月の暗号の標準化過程[20ページ]RFC2747RSVP
13. Full Copyright Statement
13. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 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機能のための基金は現在、インターネット協会によって提供されます。
Baker, et al. Standards Track [Page 21]
ベイカー、他 標準化過程[21ページ]
一覧
スポンサーリンク
