RFC4030 日本語訳
4030 The Authentication Suboption for the Dynamic Host ConfigurationProtocol (DHCP) Relay Agent Option. M. Stapp, T. Lemon. March 2005. (Format: TXT=34332 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Stapp
Request for Comments: 4030 Cisco Systems, Inc.
Category: Standards Track T. Lemon
Nominum, Inc.
March 2005
コメントを求めるワーキンググループM.スタップ要求をネットワークでつないでください: 4030年のシスコシステムズInc.カテゴリ: 2005年の標準化過程T.レモンNominum Inc.行進
The Authentication Suboption for the
Dynamic Host Configuration Protocol (DHCP) Relay Agent Option
Dynamic Host Configuration Protocol(DHCP)中継エージェントオプションのための認証Suboption
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
The Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option (RFC 3046) conveys information between a DHCP Relay Agent and a DHCP server. This specification defines an authentication suboption for that option, containing a keyed hash in its payload. The suboption supports data integrity and replay protection for relayed DHCP messages.
Dynamic Host Configuration Protocol(DHCP)リレーエージェント情報Option(RFC3046)はDHCP RelayエージェントとDHCPサーバの間で情報を伝達します。この仕様はそのオプションのために認証「副-オプション」を定義します、ペイロードの合わせられたハッシュを含んでいて。 「副-オプション」はリレーされたDHCPメッセージのためのデータ保全と反復操作による保護をサポートします。
Stapp & Lemon Standards Track [Page 1] RFC 4030 Authentication Suboption March 2005
スタップとレモン規格は2005年の認証Suboption行進のときにRFC4030を追跡します[1ページ]。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Terminology . . . . . . . . . . . . . . . . . . 3
3. DHCP Terminology . . . . . . . . . . . . . . . . . . . . . . 4
4. Suboption Format . . . . . . . . . . . . . . . . . . . . . . 4
5. Replay Detection . . . . . . . . . . . . . . . . . . . . . . 5
6. The Relay Identifier Field . . . . . . . . . . . . . . . . . 5
7. Computing Authentication Information . . . . . . . . . . . . 6
7.1. The HMAC-SHA1 Algorithm . . . . . . . . . . . . . . . 6
8. Procedures for Sending Messages . . . . . . . . . . . . . . 7
8.1. Replay Detection . . . . . . . . . . . . . . . . . . . 7
8.2. Packet Preparation . . . . . . . . . . . . . . . . . . 8
8.3. Checksum Computation . . . . . . . . . . . . . . . . . 8
8.4. Sending the Message . . . . . . . . . . . . . . . . . 8
9. Procedures for Processing Incoming Messages . . . . . . . . 8
9.1. Initial Examination . . . . . . . . . . . . . . . . . 8
9.2. Replay Detection Check . . . . . . . . . . . . . . . . 9
9.3. Testing the Checksum . . . . . . . . . . . . . . . . . 9
10. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . 9
10.1. Receiving Messages from Other Relay Agents . . . . . . 10
10.2. Sending Messages to Servers . . . . . . . . . . . . . 10
10.3. Receiving Messages from Servers . . . . . . . . . . . 10
11. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . 10
11.1. Receiving Messages from Relay Agents . . . . . . . . . 10
11.2. Sending Reply Messages to Relay Agents . . . . . . . . 11
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11
13. Security Considerations . . . . . . . . . . . . . . . . . . 11
13.1. The Key ID Field . . . . . . . . . . . . . . . . . . . 12
13.2. Protocol Vulnerabilities . . . . . . . . . . . . . . . 12
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
15.1. Normative References . . . . . . . . . . . . . . . . . 13
15.2. Informative References . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 15
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . 2 2。 要件用語. . . . . . . . . . . . . . . . . . 3 3 DHCP用語. . . . . . . . . . . . . . . . . . . . . . 4 4。 Suboptionは.4 5をフォーマットします。 検出. . . . . . . . . . . . . . . . . . . . . . 5 6を再演してください。 リレー識別子分野. . . . . . . . . . . . . . . . . 5 7。 認証情報. . . . . . . . . . . . 6 7.1を計算します。 HMAC-SHA1アルゴリズム. . . . . . . . . . . . . . . 6 8。 送付メッセージ. . . . . . . . . . . . . . 7 8.1のための手順。 検出. . . . . . . . . . . . . . . . . . . 7 8.2を再演してください。 パケット準備. . . . . . . . . . . . . . . . . . 8 8.3。 チェックサム計算. . . . . . . . . . . . . . . . . 8 8.4。 メッセージ. . . . . . . . . . . . . . . . . 8 9を送ります。 処理入力メッセージ. . . . . . . . 8 9.1のための手順。 試験. . . . . . . . . . . . . . . . . 8 9.2に頭文字をつけてください。 検出チェック. . . . . . . . . . . . . . . . 9 9.3を再演してください。 チェックサム. . . . . . . . . . . . . . . . . 9 10をテストします。 エージェントの振舞い. . . . . . . . . . . . . . . . . . . . 9 10.1をリレーしてください。 他の中継エージェント. . . . . . 10 10.2からメッセージを受け取ります。 サーバ. . . . . . . . . . . . . 10 10.3にメッセージを送ります。 サーバ. . . . . . . . . . . 10 11からメッセージを受け取ります。 DHCPサーバの振舞い. . . . . . . . . . . . . . . . . . . . 10 11.1。 中継エージェント. . . . . . . . . 10 11.2からメッセージを受け取ります。 エージェント. . . . . . . . 11 12をリレーする応答メッセージを送ります。 IANA問題. . . . . . . . . . . . . . . . . . . . 11 13。 セキュリティ問題. . . . . . . . . . . . . . . . . . 11 13.1。 主要なID分野. . . . . . . . . . . . . . . . . . . 12 13.2。 脆弱性. . . . . . . . . . . . . . . 12 14について議定書の中で述べてください。 承認. . . . . . . . . . . . . . . . . . . . . . 13 15。 参照. . . . . . . . . . . . . . . . . . . . . . . . . 13 15.1。 引用規格. . . . . . . . . . . . . . . . . 13 15.2。 有益な参照. . . . . . . . . . . . . . . . 13作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . 14の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . 15
1. Introduction
1. 序論
DHCP (RFC 2131 [6]) provides IP addresses and configuration information for IPv4 clients. It includes a relay-agent capability (RFC 951 [7], RFC 1542 [8]) in which processes within the network infrastructure receive broadcast messages from clients and forward them to servers as unicast messages. In network environments such as DOCSIS data-over-cable and xDSL, for example, it has proven useful for the relay agent to add information to the DHCP message before forwarding it, by using the relay-agent information option (RFC 3046 [1]). The kind of information that relays add is often used in the
DHCP、(RFC2131[6])はIPアドレスと設定情報をIPv4クライアントに提供します。 それは中継エージェント能力を含んでいます。(RFC951[7]、ネットワークインフラの中のプロセスが受信されるRFC1542[8])はクライアントからメッセージを放送して、ユニキャストメッセージとして彼らをサーバに送ります。 例えば、DOCSISなどのネットワーク環境データ過剰ケーブルとxDSLでは、それを進める前に中継エージェントがDHCPメッセージに情報を追加するのが役に立つと判明しました、中継エージェント情報オプションを使用することによって。(RFC3046[1])。 リレーが加えるという情報の種類は中でしばしば使用されます。
Stapp & Lemon Standards Track [Page 2] RFC 4030 Authentication Suboption March 2005
スタップとレモン規格は2005年の認証Suboption行進のときにRFC4030を追跡します[2ページ]。
server's decision-making about the addresses and configuration parameters that the client should receive. The way that the relay-agent data is used in server decision-making tends to make that data very important, and it highlights the importance of the trust relationship between the relay agent and the server.
クライアントが受け取るべきであるアドレスと設定パラメータに関するサーバの意志決定。 中継エージェントデータがサーバ意志決定に使用される方法は、そのデータを非常に重要にする傾向があります、そして、それは中継エージェントとサーバとの信頼関係の重要性を強調します。
The existing DHCP Authentication specification (RFC 3118) [9] only covers communication between the DHCP client and server. Because relay-agent information is added after the client has sent its message, the DHCP Authentication specification explicitly excludes relay-agent data from that authentication.
既存のDHCP Authentication仕様(RFC3118)[9]はDHCPクライアントとサーバとのコミュニケーションをカバーするだけです。クライアントがメッセージを送った後に中継エージェント情報が加えられるので、DHCP Authentication仕様は明らかにその認証に中継エージェントデータを入れないようにします。
The goal of this specification is to define methods that a relay agent can use to
仕様が中継エージェントが使用できるメソッドを定義することになっているこの目標
1. protect the integrity of relayed DHCP messages,
2. provide replay protection for those messages, and
3. leverage existing mechanisms, such as DHCP Authentication.
1. リレーされたDHCPメッセージの保全を保護してください、と2はそれらのメッセージ、および3のための反復操作による保護を前提とします。DHCP Authenticationなどの既存のメカニズムを利用してください。
In order to meet these goals, we specify a new relay-agent suboption, the Authentication suboption. The format of this suboption is very similar to the format of the DHCP Authentication option, and the specification of its cryptographic methods and hash computation is also similar.
これらの目標を達成して、私たちは新しい中継エージェントのために「副-オプション」、Authentication suboptionを指定します。 この「副-オプション」の形式はDHCP Authenticationオプションの形式と非常に同様です、そして、また、その暗号のメソッドとハッシュ計算の仕様も同様です。
The Authentication suboption is included by relay agents that seek to ensure the integrity of the data they include in the Relay Agent option. These relay agents are configured with the parameters necessary for generating cryptographic checksums of the data in the DHCP messages that they forward to DHCP servers. A DHCP server configured to process the Authentication suboption uses the information in the suboption to verify the checksum in the suboption and continues processing the relay agent information option only if the checksum is valid. If the DHCP server sends a response, it includes an Authentication suboption in its response message. Relay agents test the checksums in DHCP server responses to decide whether to forward the responses.
Authentication suboptionはそれらがRelayエージェントオプションに含むデータの保全を確実にしようとする中継エージェントによって入れられています。 これらの中継エージェントはサーバをDHCPに送るというDHCPメッセージのデータの暗号のチェックサムを生成するのに必要なパラメタによって構成されます。 Authentication suboptionを処理するために構成されたDHCPサーバは、「副-オプション」でチェックサムについて確かめるのに「副-オプション」の情報を使用して、チェックサムが有効である場合にだけ、中継エージェント情報オプションを処理し続けています。 DHCPサーバが応答を送るなら、それは応答メッセージにAuthentication suboptionを含んでいます。 中継エージェントは、応答を進めるかどうか決めるためにDHCPサーバ応答におけるチェックサムをテストします。
2. Requirements Terminology
2. 要件用語
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [2].
本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[2]で説明されるように解釈されることであるべきですか?
Stapp & Lemon Standards Track [Page 3] RFC 4030 Authentication Suboption March 2005
スタップとレモン規格は2005年の認証Suboption行進のときにRFC4030を追跡します[3ページ]。
3. DHCP Terminology
3. DHCP用語
This document uses the terms "DHCP server" (or "server") and "DHCP client" (or "client") as defined in RFC 2131 [6]. The term "DHCP relay agent" refers to a "BOOTP relay agent" as defined in RFC 2131.
このドキュメントはRFC2131[6]で定義されるように用語「DHCPサーバ」(または、「サーバ」)と「DHCPクライアント」(または、「クライアント」)を使用します。 「DHCP中継エージェント」という用語はRFC2131で定義される「BOOTP中継エージェント」について言及します。
4. Suboption Format
4. Suboption形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length | Algorithm | MBZ | RDM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay Detection (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay Detection cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Relay Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Authentication Information |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 長さ| アルゴリズム| MBZ| RDM| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 再生Detection(64ビット)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Detection contを再演してください。 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | リレー識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | 認証情報| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The code for the suboption is 8. The length field includes the lengths of the algorithm, the RDM, and all subsequent suboption fields in octets.
「副-オプション」のためのコードは8です。 長さの分野は八重奏にアルゴリズム、RDM、およびすべてのその後の「副-オプション」分野の長さを含んでいます。
The Algorithm field defines the algorithm used to generate the authentication information.
Algorithm分野は認証が情報であると生成するのに使用されるアルゴリズムを定義します。
Four bits are reserved for future use. These bits SHOULD be set to zero and MUST NOT be used when the suboption is processed.
4ビットは今後の使用のために予約されます。 「副-オプション」が処理されるとき、これらのビットSHOULDはゼロに用意ができて、使用されてはいけません。
The Replay Detection Method (RDM) field defines the method used to generate the Replay Detection Data.
Replay Detection Method(RDM)分野はReplay Detection Dataを生成するのに使用されるメソッドを定義します。
The Replay Detection field contains a value used to detect replayed messages, which are interpreted according to the RDM.
Replay Detection分野はRDMによると、解釈される再演されたメッセージを検出するのに使用される値を含んでいます。
The Relay Identifier field is used by relay agents that do not set giaddr, as described in RFC 3046 [1], section 2.1.
Relay Identifier分野はgiaddrを設定しない中継エージェントによって使用されます、RFC3046[1]で説明されるように、セクション2.1。
Stapp & Lemon Standards Track [Page 4] RFC 4030 Authentication Suboption March 2005
スタップとレモン規格は2005年の認証Suboption行進のときにRFC4030を追跡します[4ページ]。
The Authentication Information field contains the data required to communicate algorithm-specific parameters, as well as the checksum. The checksum is usually a digest of the data in the DHCP packet computed by using the method specified by the Algorithm field.
Authentication情報分野はアルゴリズム特有のパラメタを伝えるのに必要であるデータ、およびチェックサムを含んでいます。 通常、チェックサムはAlgorithm分野によって指定されたメソッドを使用することによって計算されたDHCPパケットのデータのダイジェストです。
5. Replay Detection
5. 再生検出
The replay-detection mechanism is designed on the notion that a receiver can determine whether a message has a valid replay token value. The default RDM, with value 1, specifies that the Replay Detection field contains an increasing counter value. The receiver associates a replay counter with each sender and rejects any message containing an authentication suboption with a Replay Detection counter value less than or equal to the last valid value. DHCP servers MAY identify relay agents by giaddr value or by other data in the message (e.g., data in other relay agent suboptions). Relay agents identify DHCP servers by source IP address. If the message's replay detection value, and the checksum are valid, the receiver updates its notion of the last valid replay counter value associated with the sender.
再生検出メカニズムは受信機が、メッセージには有効な再生トークン価値があるかどうか決定できるという概念で設計されています。 値1で、デフォルトRDMは、Replay Detection分野が増加する対価を含むと指定します。 受信機は、再生カウンタを各送付者に関連づけて、認証を含んでいて、Replay Detectionカウンタがある「副-オプション」が最後の、より有効値を評価するというどんなメッセージも拒絶します。 DHCPサーバはメッセージ(例えば、他の中継エージェント「副-オプション」のデータ)でgiaddr値か他のデータで中継エージェントを特定するかもしれません。 中継エージェントはソースIPアドレスでDHCPサーバを特定します。 メッセージのものが検出値を再演して、チェックサムが有効であるなら、受信機は送付者に関連している最後の有効な再生カウンタ価値の概念をアップデートします。
All implementations MUST support the default RDM. Additional methods may be defined in the future, following the process described in section 12.
すべての実装が、デフォルトがRDMであるとサポートしなければなりません。 セクション12で説明されたプロセスに続いて、追加メソッドは将来、定義されるかもしれません。
Receivers SHOULD perform the replay-detection check before testing the checksum. The keyed hash calculation is likely to be much more expensive than the replay-detection value check.
チェックサムをテストする前に、受信機SHOULDは再生検出チェックを実行します。 合わせられたハッシュ計算は再生検出値のチェックよりはるかに高価である傾向があります。
DISCUSSION:
This places a burden on the receiver to maintain some run-time
state (the most-recent valid counter value) for each sender,
but the number of members in a DHCP agent-server system is
unlikely to be unmanageably large.
議論: これは各送付者のために、いつかのランタイムの間、状態(最も多くの最近の有効な対価)を維持するために受信機に負担をかけますが、DHCPエージェントサーバシステムの会員数はunmanageablyに大きそうにはありません。
6. The Relay Identifier Field
6. リレー識別子分野
The Relay Agent Information Option [1] specification permits a relay agent to add a relay agent option to relayed messages without setting the giaddr field. In this case, the eventual receiver of the message needs a stable identifier to use in order to associate per-sender state such as Key ID and replay-detection counters.
Relayエージェント情報Option[1]仕様は、中継エージェントがgiaddr分野を設定しないで中継エージェントオプションをリレーされたメッセージに追加することを許可します。 この場合、メッセージの最後の受信機は、Key IDや再生検出カウンタなどの1送付者あたりの状態を関連づけるために使用への安定した識別子を必要とします。
A relay agent that adds a relay agent information option and sets giaddr MUST NOT set the Relay ID field. A relay agent that does not set giaddr MAY be configured to place a value in the Relay ID field. If the relay agent is configured to use the Relay ID field, it MAY be configured with a value to use, or it MAY be configured to generate a
中継エージェント情報オプションを加えて、giaddrを設定する中継エージェントはRelay ID分野を設定してはいけません。 giaddrを設定しない中継エージェントは、Relay ID分野に値を置くために構成されるかもしれません。 中継エージェントがRelay ID分野を使用するために構成されるか、それが使用する値によって構成されるかもしれないか、またはaを生成するのが構成されているかもしれないなら
Stapp & Lemon Standards Track [Page 5] RFC 4030 Authentication Suboption March 2005
スタップとレモン規格は2005年の認証Suboption行進のときにRFC4030を追跡します[5ページ]。
value based on some other data, such as its MAC or IP addresses. If a relay generates a Relay ID value, it SHOULD select a value that it can regenerate reliably; e.g., across reboots.
MACかIPアドレスなどのある他のデータに基づく値。 aであるなら、リレーは、Relay IDが値であると生成して、それが確かに作り直すことができるSHOULDの選んだa価値です。 例えば、リブートの向こう側に。
Servers that process an Authentication Suboption SHOULD use the giaddr value to identify the sender if the giaddr field is set. Servers MAY be configured to use some other data in the message to identify the sender. If giaddr is not set, the server SHOULD use the Relay ID field if it is nonzero. If neither the giaddr nor the Relay ID field is set, the server MAY be configured to use some other data in the message, or it MAY increment an error counter.
giaddr分野が設定されるなら、Authentication Suboption SHOULDを処理するサーバは、送付者を特定するのにgiaddr値を使用します。 サーバは、送付者を特定するメッセージのある他のデータを使用するために構成されるかもしれません。 それが非零であり、giaddrが用意ができていないなら、サーバSHOULDはRelay ID分野を使用します。 giaddrもRelay ID分野も用意ができていないなら、サーバはメッセージのある他のデータを使用するために構成されるかもしれません、または、それが誤りカウンタを増加するかもしれません。
7. Computing Authentication Information
7. 認証情報を計算します。
The Authentication Information field contains a keyed hash generated by the sender. All algorithms are defined to process the data in the DHCP messages in the same way. The sender and receiver compute a hash across a buffer containing all of the bytes in the DHCP message, including the fixed DHCP message header, the DHCP options, and the relay agent suboptions, with the following exceptions. The value of the 'hops' field MUST be set to zero for the computation because its value may be changed in transmission. The value of the 'giaddr' field MUST also be set to zero for the computation because it may be modified in networks where one relay agent adds the relay agent option but another relay agent sets 'giaddr' (see RFC 3046, section 2.1). In addition, because the relay agent option is itself included in the computation, the 'authentication information' field in the Authentication suboption is set to all zeros. The relay agent option length, the Authentication suboption length and other Authentication suboption fields are all included in the computation.
Authentication情報分野は送付者によって生成された合わせられたハッシュを含んでいます。 すべてのアルゴリズムが、同様に、DHCPメッセージのデータを処理するために定義されます。 優にDHCPメッセージのバイトを含んでいて、送付者と受信機はバッファの向こう側にハッシュを計算します、固定DHCPメッセージヘッダー、DHCPオプション、および中継エージェント「副-オプション」を含んでいて、以下の例外で。 トランスミッションで値を変えるかもしれないので、計算のために'ホップ'分野の値をゼロに設定しなければなりません。 また、それが1人の中継エージェントが中継エージェントオプションを加えるネットワークで変更されるかもしれないので、計算のために'giaddr'分野の値をゼロに設定しなければなりませんが、別の中継エージェントは'giaddr'を設定します(RFC3046を見てください、セクション2.1)。 さらに、中継エージェントオプションが計算に含まれているので、Authentication suboptionの'認証情報'分野はすべてのゼロに設定されます。 中継エージェントオプションの長さ、Authentication suboptionの長さ、および他のAuthentication suboption分野は計算にすべて含まれています。
All implementations MUST support Algorithm 1, the HMAC-SHA1 algorithm. Additional algorithms may be defined in the future, following the process described in section 12.
すべての実装がAlgorithm1、HMAC-SHA1アルゴリズムをサポートしなければなりません。 セクション12で説明されたプロセスに続いて、追加アルゴリズムは将来、定義されるかもしれません。
7.1. The HMAC-SHA1 Algorithm
7.1. HMAC-SHA1アルゴリズム
Algorithm 1 is assigned to the HMAC [3] protocol by using the SHA-1 [4] hash function. This algorithm requires that a shared secret key be configured at the relay agent and the DHCP server. A 32-bit Key Identifier is associated with each shared key, and this identifier is carried in the first 4 bytes of the Authentication Information field of the Authentication suboption. The HMAC-SHA1 computation generates a 20-byte hash value, which is placed in the Authentication Information field after the Key ID.
アルゴリズム1は、SHA-1[4]ハッシュ関数を使用することによって、HMAC[3]プロトコルに割り当てられます。 このアルゴリズムは、共有された秘密鍵が中継エージェントとDHCPサーバで構成されるのを必要とします。32ビットのKey Identifierはそれぞれの共有されたキーに関連しています、そして、この識別子はAuthentication suboptionのAuthentication情報分野の最初の4バイトで運ばれます。 HMAC-SHA1計算は20バイトのハッシュ値を生成します。(それは、Key IDの後にAuthentication情報分野に置かれます)。
Stapp & Lemon Standards Track [Page 6] RFC 4030 Authentication Suboption March 2005
スタップとレモン規格は2005年の認証Suboption行進のときにRFC4030を追跡します[6ページ]。
When Algorithm 1 is used, the format of the Authentication suboption is as follows:
Algorithm1が使用されているとき、Authentication suboptionの形式は以下の通りです:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | 38 |0 0 0 0 0 0 0 1| MBZ | RDM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay Detection (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay Detection cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Relay Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC-SHA1 (160 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 38 |0 0 0 0 0 0 0 1| MBZ| RDM| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 再生Detection(64ビット)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Detection contを再演してください。 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | リレー識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 主要なID(32ビット)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | HMAC-SHA1(160ビット)| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The suboption length is 38. The RDM and Replay Detection fields are as specified in section 5. The Relay ID field is set as specified in section 6. The Key ID is set by the sender to the ID of the key used in computing the checksum, as an integer value in network byte order. The HMAC result follows the Key ID.
「副-オプション」の長さは38です。 RDMとReplay Detection分野がセクション5で指定されるようにあります。 Relay ID分野はセクション6で指定されるように設定されます。 Key IDは送付者によってチェックサムを計算する際に使用されるキーのIDに設定されます、ネットワークバイトオーダーにおける整数値として。 HMAC結果はKey IDに続きます。
The Key ID exists only to allow the sender and receiver to specify a shared secret in cases where more than one secret is in use among a network's relays and DHCP servers. The Key ID values are entirely a matter of local configuration; they only have to be unique locally. This specification does not define any semantics or impose any requirements on this algorithm's Key ID values.
Key IDは存在していますが、送付者と受信機がケースの中1つ以上の秘密がネットワークのリレーとDHCPサーバの中で使用中である共有秘密キーを指定するのを許容します。 Key ID値は完全に地方の構成の問題です。 彼らは局所的に特有であるだけでよいです。 この仕様は、どんな意味論も定義もしませんし、このアルゴリズムのKey ID値にどんな要件も課しもしません。
8. Procedures for Sending Messages
8. 送付メッセージのための手順
8.1. Replay Detection
8.1. 再生検出
The sender obtains a replay-detection counter value to use based on the RDM it is using. If the sender is using RDM 1, the default RDM, the value MUST be greater than any previously sent value.
送付者はそれが使用しているRDMに基づいて使用する再生検出対価を得ます。 送付者がRDM1、デフォルトRDMを使用しているなら、値はいずれも以前に値を送ったより大きいに違いありません。
Stapp & Lemon Standards Track [Page 7] RFC 4030 Authentication Suboption March 2005
スタップとレモン規格は2005年の認証Suboption行進のときにRFC4030を追跡します[7ページ]。
8.2. Packet Preparation
8.2. パケット準備
The sender sets the 'giaddr' field and the 'hops' field to all zeros. The sender appends the relay agent information option to the client's packet, including the Authentication suboption. The sender selects an appropriate Replay Detection value. The sender places its identifier into the Relay ID field, if necessary, or sets the field to all zeros. The sender sets the suboption length, places the Replay Detection value into the Replay Detection field of the suboption, and sets the algorithm to the algorithm number that it is using. If the sender is using HMAC-SHA1, it sets the Key ID field to the appropriate value. The sender sets the field that will contain the checksum to all zeros. Other algorithms may specify additional preparation steps.
送付者は'giaddr'分野と'ホップ'分野をすべてのゼロに設定します。 送付者はAuthentication suboptionを含むクライアントのパケットに中継エージェント情報オプションを追加します。 送付者は適切なReplay Detection値を選択します。 送付者は、必要なら、Relay ID分野に識別子を置くか、またはすべてのゼロに分野を設定します。 送付者は、「副-オプション」の長さを設定して、「副-オプション」のReplay Detection分野にReplay Detection値を置いて、それが使用しているアルゴリズム番号にアルゴリズムを設定します。 送付者がHMAC-SHA1を使用しているなら、それはKey ID分野を適切な値に設定します。 送付者はすべてのゼロにチェックサムを含む分野を設定します。 他のアルゴリズムは追加準備ステップを指定するかもしれません。
8.3. Checksum Computation
8.3. チェックサム計算
The sender computes the checksum across the entire DHCP message, using the algorithm it has selected. The sender places the result of the computation into the Authentication Information field of the Authentication suboption.
それが選択したアルゴリズムを使用して、送付者は全体のDHCPメッセージの向こう側にチェックサムを計算します。 送付者はAuthentication suboptionのAuthentication情報分野に計算の結果を置きます。
8.4. Sending the Message
8.4. メッセージを送ります。
The sender restores the values of the 'hops' and 'giaddr' fields and sends the message.
送付者は、'ホップ'と'giaddr'分野の値を回復して、メッセージを送ります。
9. Procedures for Processing Incoming Messages
9. 処理入力メッセージのための手順
9.1. Initial Examination
9.1. 初期の試験
The receiver examines the message for the value of the giaddr field and determines whether the packet includes the relay agent information option. The receiver uses its configuration to determine whether it should expect an Authentication suboption. The receiver MUST support a configuration that allows it to drop incoming messages that do not contain a valid relay agent information option and Authentication suboption.
受信機は、giaddr分野の値へのメッセージを調べて、パケットが中継エージェント情報オプションを含んでいるかどうか決定します。 受信機は、それがAuthentication suboptionを予想するべきであるかどうか決定するのに構成を使用します。 受信機はそれが有効な中継エージェント情報オプションとAuthentication suboptionを含まない入力メッセージを下げることができる構成をサポートしなければなりません。
If the receiver determines that the Authentication suboption is present and that it should process the suboption, it uses the data in the message to determine which algorithm, key, and RDM to use in validating the message. If the receiver cannot determine which algorithm, key, and RDM to use, or if it does not support the value indicated in the message, it SHOULD drop the message. Because this situation could indicate a misconfiguration that could deny service to clients, receivers MAY attempt to notify their administrators or to log an error message.
受信機がAuthentication suboptionが存在していて、「副-オプション」を処理するべきであることを決定するなら、それはメッセージを有効にする際にどのアルゴリズム、キー、およびRDMを使用したらよいかを決定するメッセージのデータを使用します。 受信機がそうすることができないなら、どのアルゴリズム、キー、およびRDMを使用するか、そして、またはそれがメッセージで示された値をサポートしないかどうか決定してください、それ。SHOULDはメッセージを下げます。 この状況がクライアントに対するサービスを否定する場合があったmisconfigurationを示すかもしれないので、受信機は、彼らの管理者に通知するか、またはエラーメッセージを登録するのを試みるかもしれません。
Stapp & Lemon Standards Track [Page 8] RFC 4030 Authentication Suboption March 2005
スタップとレモン規格は2005年の認証Suboption行進のときにRFC4030を追跡します[8ページ]。
9.2. Replay Detection Check
9.2. 再生検出チェック
The receiver examines the RDM field. Receivers MUST discard messages containing RDM values that they do not support. Because this may indicate a misconfiguration at the sender, an attempt SHOULD be made to indicate this condition to the administrator by incrementing an error counter or writing a log message. If the receiver supports the RDM, it examines the value in the Replay Detection field by using the procedures in the RDM and in section 5. If the Replay value is not valid, the receiver MUST drop the message.
受信機はRDM分野を調べます。 受信機はそれらがサポートしないRDM値を含むメッセージを捨てなければなりません。 これが送付者でmisconfigurationを示すかもしれないので、試みSHOULDですこの状態が管理者に誤りカウンタを増加することによって示さされるか、またはログメッセージを書く。 受信機がRDMをサポートするなら、それは、Replay Detection分野でRDMとセクション5で手順を用いることによって、値を調べます。 Replay値が有効でないなら、受信機はメッセージを下げなければなりません。
Note that at this point the receiver MUST NOT update its notion of the last valid Replay Detection value for the sender. Until the checksum has been tested, the Replay Detection field cannot be trusted. If the receiver trusts the Replay Detection value without testing the checksum, a malicious host could send a replayed message with a Replay Detection value that was very high, tricking the receiver into rejecting legitimate values from the sender.
ここに受信機が送付者のために最後の有効なReplay Detection価値の概念をアップデートしてはいけないことに注意してください。 チェックサムがテストされるまで、Replay Detection分野を信じることができません。 Replay Detectionがチェックサム、悪意があるホストをテストしないで評価する受信機受託がReplay Detection値がある再演されたメッセージを送ることができるなら、それは非常に高かったです、受信機が送付者から正統の値を拒絶するようにだまして。
9.3. Testing the Checksum
9.3. チェックサムをテストします。
The receiver prepares the packet in order to test the checksum by setting the 'giaddr' and 'hops' fields to zero, and by setting the Authentication Information field of the suboption to all zeros. Using the algorithm and key associated with the sender, the receiver computes a hash of the message. The receiver compares the result of its computation with the value sent. If the checksums do not match, the receiver MUST drop the message. Otherwise, the receiver updates its notion of the last valid Replay Detection value associated with the sender and processes the message.
受信機は、'giaddr'を設定することによってチェックサムをテストするためにパケットを準備して、ゼロと、「副-オプション」のAuthentication情報分野をすべてのゼロに設定することによって、分野を'飛び越します'。 送付者に関連しているアルゴリズムとキーを使用して、受信機はメッセージのハッシュを計算します。 受信機は計算の結果を送る値にたとえます。 チェックサムが合っていないなら、受信機はメッセージを下げなければなりません。 さもなければ、受信機は、送付者に関連している最後の有効なReplay Detection価値の概念をアップデートして、メッセージを処理します。
10. Relay Agent Behavior
10. 中継エージェントの振舞い
DHCP Relay agents are typically configured with the addresses of one or more DHCP servers. A relay agent that implements this suboption requires an algorithm number for each server, as well as appropriate credentials (i.e., keys). Relay implementations SHOULD support a configuration that indicates that all relayed messages should include the authentication suboption. Use of the authentication suboption SHOULD be disabled by default. Relay agents MAY support configuration that indicates that certain destination servers support the authentication suboption and that other servers do not. Relay agents MAY support configuration of a single algorithm number and key to be used with all DHCP servers, or they MAY support configuration of different algorithms and keys for each server.
DHCP Relayエージェントは1つ以上のDHCPサーバのアドレスによって通常構成されます。 この「副-オプション」を実装する中継エージェントはそれぞれのサーバのアルゴリズム番号を必要とします、適切な資格証明書(すなわち、キー)と同様に。 リレー実装SHOULDはすべてのリレーされたメッセージが認証「副-オプション」を含むべきであるのを示す構成をサポートします。 使用、認証suboption SHOULDでは、デフォルトで無効にされてください。 中継エージェントはある目的地サーバが、認証が「副-オプション」であるとサポートして、他のサーバがそうしないのを示す構成をサポートするかもしれません。 中継エージェントがすべてのDHCPサーバと共に使用されるためにただ一つのアルゴリズム番号とキーの構成をサポートするかもしれませんか、またはそれらは各サーバのために異なったアルゴリズムとキーの構成をサポートするかもしれません。
Stapp & Lemon Standards Track [Page 9] RFC 4030 Authentication Suboption March 2005
スタップとレモン規格は2005年の認証Suboption行進のときにRFC4030を追跡します[9ページ]。
10.1. Receiving Messages from Other Relay Agents
10.1. 他の中継エージェントからメッセージを受け取ります。
There are network configurations in which one relay agent adds the relay agent option and then forwards the DHCP message to another relay agent. For example, a layer-2 switch might be directly connected to a client, and it might forward messages to an aggregating router, which sets giaddr and then forwards the message to a DHCP server. When a DHCP relay that implements the Authentication suboption receives a message, it MAY use the procedures in section 9 to verify the source of the message before forwarding it.
中継エージェントが中継エージェントオプションを加えて、次にDHCPメッセージを別の中継エージェントに転送するネットワーク・コンフィギュレーションがあります。 (ルータはgiaddrを設定します)。例えば、層-2スイッチが直接クライアントに接続されるかもしれなくて、それは、集合ルータにメッセージを転送するかもしれなくて、次に、DHCPサーバにメッセージを転送します。Authentication suboptionを実装するDHCPリレーがメッセージを受け取るとき、それを進める前にメッセージの源について確かめるのにセクション9で手順を用いるかもしれません。
10.2. Sending Messages to Servers
10.2. メッセージをサーバに送ります。
When the relay agent receives a broadcast packet from a client, it determines which DHCP servers (or other relay agents) should receive copies of the message. If the relay agent is configured to include the Authentication suboption, it determines which Algorithm and RDM to use, and then it performs the steps in section 8.
中継エージェントがクライアントから放送パケットを受けるとき、それは、どのDHCPサーバ(または、他の中継エージェント)がメッセージのコピーを受けるべきであるかを決定します。 中継エージェントがAuthentication suboptionを含むように構成されるなら、どのAlgorithmとRDMを使用したらよいかを決定します、そして、次に、セクション8でステップを実行します。
10.3. Receiving Messages from Servers
10.3. サーバからメッセージを受け取ります。
When the relay agent receives a message, it determines from its configuration whether it expects the message to contain a relay agent information option and an Authentication suboption. The relay agent MAY be configured to drop response messages that do not contain the Authentication suboption. The relay agent then follows the procedures in section 9.
中継エージェントがメッセージを受け取るとき、それは、構成から中継エージェント情報オプションとAuthentication suboptionを含むメッセージを予想するかどうか決定します。 中継エージェントは、Authentication suboptionを含まない応答メッセージを下げるために構成されるかもしれません。 そして、中継エージェントはセクション9で手順に従います。
11. DHCP Server Behavior
11. DHCPサーバの振舞い
DHCP servers may interact with multiple relay agents. Server implementations MAY support a configuration that associates the same algorithm and key with all relay agents. Servers MAY support a configuration that specifies the algorithm and key to use with each relay agent individually.
DHCPサーバは複数の中継エージェントと対話するかもしれません。 サーバ実装は同じアルゴリズムとキーをすべての中継エージェントに関連づける構成をサポートするかもしれません。 サーバは各中継エージェントと共に個別に使用するアルゴリズムとキーを指定する構成をサポートするかもしれません。
11.1. Receiving Messages from Relay Agents
11.1. 中継エージェントからメッセージを受け取ります。
When a DHCP server that implements the Authentication suboption receives a message, it performs the steps in section 9.
Authentication suboptionを実装するDHCPサーバがメッセージを受け取るとき、それはセクション9でステップを実行します。
Stapp & Lemon Standards Track [Page 10] RFC 4030 Authentication Suboption March 2005
スタップとレモン規格は2005年の認証Suboption行進のときにRFC4030を追跡します[10ページ]。
11.2. Sending Reply Messages to Relay Agents
11.2. エージェントをリレーする送付応答メッセージ
When the server has prepared a reply message, it uses the incoming request message and its configuration to determine whether it should include a relay agent information option and an Authentication suboption. If the server is configured to include the Authentication suboption, it determines which Algorithm and RDM to use and then performs the steps in section 8.
サーバが応答メッセージを準備したとき、それは、それが中継エージェント情報オプションとAuthentication suboptionを含むべきであるかどうか決定するのに入って来る要求メッセージとその構成を使用します。 サーバがAuthentication suboptionを含むように構成されるなら、それは、どのAlgorithmとRDMを使用したらよいかを決定して、セクション8でステップを実行します。
DISCUSSION:
This server behavior represents a slight variance from RFC 3046
[1], section 2.2. The Authentication suboption is not echoed
back from the server to the relay; the server generates its own
suboption.
議論: このサーバの振舞いはRFC3046[1]、セクション2.2からわずかな変化を代表します。 Authentication suboptionはサーバからリレーまでecho backではありません。 サーバはそれ自身の「副-オプション」を生成します。
12. IANA Considerations
12. IANA問題
Section 4 defines a new suboption for the DHCP relay agent option called the Authentication Suboption. IANA has allocated a new suboption code from the relay agent option suboption number space.
セクション4はAuthentication Suboptionと呼ばれるDHCP中継エージェントオプションのために新しい「副-オプション」を定義します。 IANAは中継エージェントオプション「副-オプション」数のスペースから新しい「副-オプション」コードを割り当てました。
This specification introduces two new number spaces for the Authentication suboption's 'Algorithm' and 'Replay Detection Method' fields. These number spaces have been created and will be maintained by IANA.
この仕様はAuthentication suboptionの'アルゴリズム'と'再生Detection Method'分野に2つの新しい数の空間を取り入れます。 これらの数の空間は、作成されて、IANAによって維持されるでしょう。
The Algorithm identifier is a one-byte value. The Algorithm value 0 is reserved. The Algorithm value 1 is assigned to the HMAC-SHA1 keyed hash, as defined in section 7.1. Additional algorithm values will be allocated and assigned through IETF consensus, as defined in RFC 2434 [5].
Algorithm識別子は1バイトの値です。 Algorithm値0は予約されています。 値1が割り当てられるAlgorithmはセクション7.1で定義されるようにハッシュをHMAC-SHA1に合わせました。 追加アルゴリズム値は、RFC2434[5]で定義されるようにIETFコンセンサスを通して割り当てられて、割り当てられるでしょう。
The RDM identifier is a four-bit value. The RDM value 0 is reserved. The RDM value 1 is assigned to the use of a monotonically increasing counter value, as defined in section 5. Additional RDM values will be allocated and assigned through IETF consensus, as defined in RFC 2434 [5].
RDM識別子は4ビットの値です。 RDM値0は予約されています。 RDM値1はセクション5で定義されるように単調に増加する対価の使用に割り当てられます。 追加RDM値は、RFC2434[5]で定義されるようにIETFコンセンサスを通して割り当てられて、割り当てられるでしょう。
13. Security Considerations
13. セキュリティ問題
This specification describes a protocol that adds source authentication and message integrity protection to the messages between DHCP relay agents and DHCP servers.
この仕様はDHCP中継エージェントとDHCPサーバの間のメッセージにソース認証とメッセージの保全保護を追加するプロトコルについて説明します。
The use of this protocol imposes a new computational burden on relay agents and servers, because they must perform cryptographic hash calculations when they send and receive messages. This burden may add latency to DHCP message exchanges. Because relay agents are
このプロトコルの使用は新しいコンピュータの負担を中継エージェントとサーバに課します、彼らがメッセージを送って、受け取るとき、暗号のハッシュ計算を実行しなければならないので。 この負担はDHCP交換処理への潜在を加えるかもしれません。 中継エージェントがそうであるので
Stapp & Lemon Standards Track [Page 11] RFC 4030 Authentication Suboption March 2005
スタップとレモン規格は2005年の認証Suboption行進のときにRFC4030を追跡します[11ページ]。
involved when clients reboot, periods of very high reboot activity will result in the largest number of messages that have to be processed. During a cable MSO head-end reboot event, for example, the time required for all clients to be served may increase.
クライアントがリブートするとき、かかわって、非常に高いリブート活動の一区切りは処理されなければならないメッセージの最多数をもたらすでしょう。 ケーブルMSOギヤエンドのリブートイベントの間、例えば、すべてのクライアントに役立たれるのに必要である時間は増加するかもしれません。
13.1. The Key ID Field
13.1. 主要なID分野
The Authentication suboption contains a four-byte Key ID, following the example of the DHCP Authentication RFC. Other authentication protocols, such as DNS TSIG [10], use a key name. A key name is more flexible and potentially more human readable than a key id. DHCP servers may well be configured to use key names for DNS updates using TSIG, so it might simplify DHCP server configuration if some of the key management for both protocols could be shared.
DHCP Authentication RFCに関する例に倣っていて、Authentication suboptionは4バイトのKey IDを含んでいます。 DNS TSIG[10]などの他の認証プロトコルは主要な名前を使用します。 主要な名前は、主要なイドより読み込み可能な状態でさらにフレキシブルであって、潜在的に人間です。 DHCPサーバはDNSアップデートにTSIGを使用することで主要な名前を使用するためにたぶん構成されるでしょう、したがって、両方のプロトコルのための何らかのかぎ管理を共有できるなら、それがDHCPサーバ構成を簡素化するでしょうに。
On the other hand, it is crucial to minimize the size expansion caused by the introduction of the relay agent information option. Named keys would require more physical space and would entail more complex suboption encoding and parsing implementations. These considerations have led us to specify a fixed-length Key ID instead of a variable-length key name.
他方では、中継エージェント情報オプションの導入で引き起こされたサイズ拡張を最小にするのは重要です。 命名されたキーは、より物理的なスペースを必要として、実装をコード化して、分析するより複雑な「副-オプション」を伴うでしょう。 これらの問題は、私たちが可変長の主要な名前の代わりに固定長Key IDを指定するように導きました。
13.2. Protocol Vulnerabilities
13.2. プロトコル脆弱性
Because DHCP is a UDP protocol, messages between relays and servers may be delivered in an order different from that in which they were generated. The replay-detection mechanism will cause receivers to drop packets that are delivered 'late', leading to client retries. The retry mechanisms that most clients implement should not cause this to be an enormous issue, but it will cause senders to do computational work which will be wasted if their messages are re-ordered.
DHCPがUDPプロトコルであるので、リレーとサーバの間のメッセージはそれらが生成されたそれと異なったオーダーで提供されるかもしれません。 再生検出メカニズムで、受信機はクライアント再試行に通じて、'遅く'のときに提供されるパケットを下げるでしょう。 ほとんどのクライアントが実装する再試行メカニズムは、これが莫大な問題であることを引き起こすはずがありませんが、それで、送付者は彼らのメッセージが再規則正しいなら浪費されるコンピュータの仕事をするでしょう。
The DHC WG has developed two documents describing authentication of DHCP relay agent options to accommodate the requirements of different deployment scenarios: this document and "Authentication of Relay Agent Options Using IPsec" [11]. As we note in section 11, the Authentication suboption can be used without pairwise keys between each relay and each DHCP server. In deployments where IPsec is readily available and pairwise keys can be managed efficiently, the use of IPsec as described in that document may be appropriate. If IPsec is not available or there are multiple relay agents for which multiple keys must be managed, the protocol described in this document may be appropriate. As is the case whenever two alternatives are available, local network administration can choose whichever is more appropriate. Because the relay agents and the DHCP
DHC WGは異なった展開シナリオの要件を収容するためにDHCP中継エージェントオプションの認証について説明する2通のドキュメントを開発しました: このドキュメントと「IPsecを使用する中継エージェントオプションの認証」[11]。 私たちがセクション11で注意するように、各リレーとそれぞれのDHCPサーバの間の対状キーなしでAuthentication suboptionを使用できます。展開では、そのドキュメントの説明されるとしてのIPsecの使用はIPsecが容易に利用可能であり、効率的に対状キーに対処できるところで適切であるかもしれません。 IPsecが利用可能でないか、または複数のキーを管理しなければならない複数の中継エージェントがいれば、本書では説明されたプロトコルは適切であるかもしれません。 ときはいつの場合もそうだが、どれがさらに適切であるかなら、企業内情報通信網運営は、2つの選択肢が利用可能であることを選ぶことができます。 中継エージェントとDHCP
Stapp & Lemon Standards Track [Page 12] RFC 4030 Authentication Suboption March 2005
スタップとレモン規格は2005年の認証Suboption行進のときにRFC4030を追跡します[12ページ]。
server are all in the same administrative domain, the appropriate mechanism can be configured on all interoperating DHCP server elements.
サーバがすべて同じ管理ドメインにあって、DHCPサーバ要素を共同利用しながら、すべてで適切な手段は構成できます。
14. Acknowledgements
14. 承認
The need for this specification was made clear by comments made by Thomas Narten and John Schnizlein, and the use of the DHCP Authentication option format was suggested by Josh Littlefield, at IETF 53.
この仕様の必要性はトーマスNartenとジョンSchnizleinによってされたコメントで明らかにされました、そして、DHCP Authenticationオプション形式の使用はジョッシュ・リトルフィールドによって提案されました、IETF53で。
15. References
15. 参照
15.1. Normative References
15.1. 引用規格
[1] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046,
January 2001.
[1] パトリック、M.、「DHCP中継エージェント情報オプション」、RFC3046、2001年1月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[3] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997.
[3]Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[4] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, September 2001.
[4] イーストレーク3番目とD.とP.ジョーンズ、「米国安全なハッシュアルゴリズム1(SHA1)」、RFC3174 2001年9月。
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[5]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
15.2. Informative References
15.2. 有益な参照
[6] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[6]Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
[7] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951,
September 1985.
[7] 耕地とW.とJ.ギルモア、「プロトコルを独力で進んでください」、RFC951、1985年9月。
[8] Wimer, W., "Clarifications and Extensions for the Bootstrap
Protocol", RFC 1542, October 1993.
[8]Wimer、W.、「明確化と拡大、プロトコルを独力で進んでください、」、RFC1542、10月1993日
[9] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",
RFC 3118, June 2001.
[9]DromsとR.とW.Arbaugh、「DHCPメッセージのための認証」、RFC3118、2001年6月。
[10] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)", RFC
2845, May 2000.
[10] Vixie(P.、グドムンソン、O.、イーストレーク3番目、D.、およびB.ウェリントン、「DNS(TSIG)のための秘密鍵トランザクション認証」、RFC2845)は2000がそうするかもしれません。
Stapp & Lemon Standards Track [Page 13] RFC 4030 Authentication Suboption March 2005
スタップとレモン規格は2005年の認証Suboption行進のときにRFC4030を追跡します[13ページ]。
[11] Droms, R., "Authentication of Relay Agent Options Using IPsec",
Work in Progress, February 2004.
[11] R.、「IPsecを使用する中継エージェントオプションの認証」というDromsは進歩、2004年2月に働いています。
Authors' Addresses
作者のアドレス
Mark Stapp Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA
スタップシスコシステムズInc.1414マサチューセッツAveをマークしてください。 Boxborough、MA01719米国
Phone: 978.936.0000 EMail: mjs@cisco.com
以下に電話をしてください。 978.936.0000 メールしてください: mjs@cisco.com
Ted Lemon Nominum, Inc. 950 Charter St. Redwood City, CA 94063 USA
テッドレモンNominum Inc.950憲章聖カリフォルニア94063レッドウッドシティー(米国)
EMail: Ted.Lemon@nominum.com
メール: Ted.Lemon@nominum.com
Stapp & Lemon Standards Track [Page 14] RFC 4030 Authentication Suboption March 2005
スタップとレモン規格は2005年の認証Suboption行進のときにRFC4030を追跡します[14ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Stapp & Lemon Standards Track [Page 15]
スタップとレモン標準化過程[15ページ]
一覧
スポンサーリンク
