[要約] RFC 3012は、Mobile IPv4のChallenge/Response拡張に関する仕様です。このRFCの目的は、モバイルデバイスの認証とセキュリティを強化するために、Challenge/Responseメカニズムを導入することです。
Network Working Group C. Perkins
Request for Comments: 3012 Nokia Research Center
Category: Standards Track P. Calhoun
Sun Microsystems Laboratories
November 2000
Mobile IPv4 Challenge/Response Extensions
モバイルIPv4チャレンジ/応答拡張機能
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
Abstract
概要
Mobile IP, as originally specified, defines an authentication extension (the Mobile-Foreign Authentication extension) by which a mobile node can authenticate itself to a foreign agent. Unfortunately, this extension does not provide ironclad replay protection for the foreign agent, and does not allow for the use of existing techniques (such as CHAP) for authenticating portable computer devices. In this specification, we define extensions for the Mobile IP Agent Advertisements and the Registration Request that allow a foreign agent to use a challenge/response mechanism to authenticate the mobile node.
元々指定されたモバイルIPは、モバイルノードが外国人エージェントに認証できる認証拡張機能（モバイル外定認証拡張機能）を定義します。残念ながら、この拡張機能は、外国人エージェントに鉄の鎖骨のリプレイ保護を提供せず、ポータブルコンピューターデバイスを認証するために既存の手法（CHAPなど）を使用することを許可していません。この仕様では、モバイルIPエージェント広告の拡張機能と、外国人エージェントがチャレンジ/応答メカニズムを使用してモバイルノードを認証できるようにする登録要求を定義します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Mobile IP Agent Advertisement Challenge Extension . . . . . 3
3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Mobile Node Processing for Registration Requests . . . 3
3.2. Foreign Agent Processing for Registration Requests . . 5
3.3. Foreign Agent Processing for Registration Replies . . 7
3.4. Home Agent Processing for the Challenge Extensions . . 7
4. MN-FA Challenge Extension . . . . . . . . . . . . . . . . . 7
5. Generalized Mobile IP Authentication Extension . . . . . . . 8
6. MN-AAA Authentication subtype. . . . . . . . . . . . . . . . 9
7. Reserved SPIs for Mobile IP. . . . . . . . . . . . . . . . . 9
8. SPI For RADIUS AAA Servers . . . . . . . . . . . . . . . . . 10
9. Configurable Parameters. . . . . . . . . . . . . . . . . . . 10
10. Error Values . . . . . . . . . . . . . . . . .. . . . . . . 10
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11
12. Security Considerations . . . . . . . . . . . . . . . . . . 12
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
A. Verification Infrastructure . . . . . . . . . . . . . . . . 14
Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 17
Mobile IP, as originally specified, defines an authentication extension (the Mobile-Foreign Authentication extension) by which a mobile node can authenticate itself to a foreign agent.
元々指定されたモバイルIPは、モバイルノードが外国人エージェントに認証できる認証拡張機能（モバイル外定認証拡張機能）を定義します。
Unfortunately, this extension does not provide ironclad replay protection, from the point of view of the foreign agent, and does not allow for the use of existing techniques (such as CHAP [12]) for authenticating portable computer devices. In this specification, we define extensions for the Mobile IP Agent Advertisements and the Registration Request that allow a foreign agent to a use challenge/response mechanism to authenticate the mobile node.
残念ながら、この拡張機能は、外国のエージェントの観点から鉄の鎖骨のリプレイ保護を提供せず、ポータブルコンピューターデバイスを認証するための既存の手法（Chap [12]など）の使用を許可していません。この仕様では、モバイルIPエージェント広告の拡張機能と、外国人エージェントがモバイルノードを認証するために課題/応答メカニズムを使用できるようにする登録要求を定義します。
All SPI values defined in this document refer to values for the Security Parameter Index, as defined in RFC 2002 [8]. 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 [1].
このドキュメントで定義されているすべてのSPI値は、RFC 2002 [8]で定義されているように、セキュリティパラメーターインデックスの値を指します。「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[1]に記載されているとおりに解釈される。
This section defines a new extension to the Router Discovery Protocol [3] for use by foreign agents that need to issue a challenge for authenticating mobile nodes.
このセクションでは、モバイルノードを認証するために課題を発行する必要がある外国人エージェントが使用するためのルーターディスカバリープロトコル[3]の新しい拡張機能を定義します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Challenge ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The Challenge Extension
図1：チャレンジ拡張
Type 24
タイプ24
Length The length of the Challenge value in bytes; SHOULD be at least 4
長さバイトのチャレンジ値の長さ。少なくとも4である必要があります
Challenge A random value that SHOULD be at least 32 bits.
少なくとも32ビットになるはずのランダムな値に挑戦します。
The Challenge extension, illustrated in figure 1, is inserted in the Agent Advertisements by the Foreign Agent, in order to communicate the latest challenge value that can be used by the mobile node to compute an authentication for its registration request message. The challenge is selected by the foreign agent to provide local assurance that the mobile node is not replaying any earlier registration request. Eastlake, et al. [4] provides more information on generating pseudo-random numbers suitable for use as values for the challenge.
図1に示すチャレンジエクステンションは、モバイルノードで使用できる最新のチャレンジ値を登録リクエストメッセージの認証を計算することができる最新のチャレンジ値を伝えるために、外国人エージェントによってエージェント広告に挿入されています。この課題は、モバイルノードが以前の登録要求を再生していないというローカル保証を提供するために、外国人エージェントによって選択されます。イーストレイク他[4]は、チャレンジの値として使用するのに適した擬似ランダム数の生成に関する詳細情報を提供します。
This section describes modifications to the Mobile IP registration process which may occur after the Foreign Agent issues a Mobile IP Agent Advertisement containing the Challenge on its local link.
このセクションでは、外国人エージェントがローカルリンクに課題を含むモバイルIPエージェント広告を発行した後に発生する可能性のあるモバイルIP登録プロセスの変更について説明します。
Whenever the Agent Advertisement contains the Challenge extension, if the mobile node does not have a security association with the Foreign Agent, then it MUST include the Challenge value in a MN-FA Challenge extension to the Registration Request message. If, on the other hand, the mobile node does have a security association with the foreign agent, it SHOULD include the Challenge value in its Registration Request message.
エージェント広告にチャレンジ拡張機能が含まれている場合はいつでも、モバイルノードに外国人エージェントとセキュリティ関連がない場合、登録リクエストメッセージのMN-FAチャレンジ拡張機能にチャレンジ値を含める必要があります。一方、モバイルノードに外国人エージェントとセキュリティ関連がある場合、登録要求メッセージにチャレンジ値を含める必要があります。
If the Mobile Node has a security association with the Foreign Agent, it MUST include a Mobile-Foreign Authentication extension in its Registration Request message, according to the base Mobile IP specification [8]. When the Registration Request contains the MN-FA Challenge extension specified in section 4, the Mobile-Foreign Authentication MUST follow the Challenge extension in the Registration Request.
モバイルノードに外国エージェントとセキュリティ関連がある場合、ベースモバイルIP仕様[8]に従って、登録要求メッセージにモバイル外定認証拡張機能を含める必要があります。登録要求にセクション4で指定されたMN-FAチャレンジ拡張機能が含まれている場合、モバイル外定認証は登録リクエストのチャレンジ拡張機能に従う必要があります。
If the Mobile Node does not have a security association with the Foreign Agent, the Mobile Node MUST include the MN-AAA Authentication extension as defined in section 6. In addition, the Mobile Node SHOULD include the NAI extension [2], to enable the foreign agent to make use of any available verification infrastructure. The SPI field of the MN-AAA Authentication extension specifies the particular secret and algorithm (shared between the Mobile Node and the verification infrastructure) that must be used to perform the authentication. If the SPI value is chosen as CHAP_SPI (see section 9), then the mobile node specifies CHAP-style authentication [12] using MD5 [11].
モバイルノードに外部エージェントとのセキュリティ関連がない場合、モバイルノードにはセクション6で定義されているMN-AAA認証拡張機能を含める必要があります。さらに、モバイルノードにはNAI拡張機能[2]を含める必要があります。利用可能な検証インフラストラクチャを利用する外国人エージェント。MN-AAA認証拡張機能のSPIフィールドは、認証を実行するために使用する必要がある特定の秘密とアルゴリズム（モバイルノードと検証インフラストラクチャ間で共有）を指定します。SPI値がCHAP_SPIとして選択されている場合（セクション9を参照）、モバイルノードはMD5 [11]を使用してCHAPスタイルの認証[12]を指定します。
In either case, the MN-FA Challenge extension and one of the above specified authentication extensions MUST follow the Mobile-Home Authentication extension, if present.
いずれの場合も、MN-FAチャレンジ拡張機能と上記の指定された認証拡張の1つは、存在する場合はモバイルホーム認証拡張機能に従う必要があります。
A successful Registration Reply from the Foreign Agent MAY include a new Challenge value (see section 3.3). The Mobile Node MAY use either the value found in the latest Advertisement, or the one found in the last Registration Reply from the Foreign Agent. This approach enables the Mobile Node to make use of the challenge without having to wait for advertisements.
外国人エージェントからの登録の成功した返信には、新しいチャレンジ値が含まれる場合があります（セクション3.3を参照）。モバイルノードは、最新の広告で見つかった値、または外国人エージェントからの最後の登録返信で見つかった値を使用する場合があります。このアプローチにより、モバイルノードは広告を待つことなくチャレンジを利用できます。
A Mobile Node might receive an UNKNOWN_CHALLENGE error (see section 9) if it moves to a new Foreign Agent that cannot validate the challenge provided in the Registration Request. In such instances, the Mobile Node MUST use a new Challenge value in any new registration, obtained either from an Agent Advertisement, or from a Challenge extension to the Registration Reply containing the error.
モバイルノードは、登録リクエストで提供される課題を検証できない新しい外国人エージェントに移動する場合、不明な_Challengeエラー（セクション9を参照）を受信する場合があります。そのような場合、モバイルノードは、エージェント広告のいずれかから、またはエラーを含む登録返信までのチャレンジ拡張から取得された新しい登録で、新しいチャレンジ値を使用する必要があります。
A Mobile Node that does not include a Challenge when the Mobile-Foreign Authentication extension is present may receive a MISSING_CHALLENGE (see section 10) error. In this case, the foreign agent will not process the request from the mobile node unless the request contains a valid Challenge.
モバイル外定認証拡張機能が存在する場合の課題を含めないモバイルノードは、Missing_Challenge（セクション10を参照）エラーを受信する場合があります。この場合、リクエストに有効な課題が含まれていない限り、外国人エージェントはモバイルノードからの要求を処理しません。
A Mobile Node that receives a BAD_AUTHENTICATION error code (see section 10) SHOULD include the MN-AAA Authentication Extension in the next Registration Request. This will make it possible for the Foreign Agent to use its AAA infrastructure in order to authenticate the Mobile Node.
bad_authenticationエラーコード（セクション10を参照）を受信するモバイルノードには、次の登録リクエストにMN-AAA認証拡張機能を含める必要があります。これにより、外国人エージェントがモバイルノードを認証するためにAAAインフラストラクチャを使用できるようになります。
Upon receipt of the Registration Request, if the Foreign Agent has issued a Challenge as part of its Agent Advertisements, and it does not have a security association with the mobile node, then the Foreign Agent MUST check that the MN-FA Challenge extension exists, and that it contains a challenge value previously unused by the Mobile Node. This ensures that the mobile node is not attempting to replay a previous advertisement and authentication. If the challenge extension is needed and does not exist, the Foreign Agent MUST send a Registration Reply to the mobile node with the error code MISSING_CHALLENGE.
登録要求を受け取ったとき、外国人エージェントがエージェント広告の一部としてチャレンジを発行し、モバイルノードとのセキュリティ関連がない場合、外国人エージェントはMN-FAチャレンジ拡張が存在することを確認する必要があります。また、モバイルノードで使用されていないチャレンジ値が含まれていること。これにより、モバイルノードが以前の広告と認証を再生しようとしていないことが保証されます。チャレンジ拡張機能が必要であり、存在しない場合、外国人エージェントは、エラーコードがMissing_Challengeを使用してモバイルノードに登録返信を送信する必要があります。
A foreign agent that sends Agent Advertisements containing a Challenge value MAY send a Registration Reply message with a MISSING_CHALLENGE error if the mobile node sends a Registration Request with a Mobile-Foreign Authentication extension without including a Challenge. In other words, such a foreign agent MAY refuse to process a Registration Request request from the mobile node unless the request contains a valid Challenge.
チャレンジ値を含むエージェント広告を送信する外国人エージェントは、モバイルノードがチャレンジを含めることなくモバイル外定認証拡張機能を備えた登録要求を送信した場合、Missing_Challengeエラーで登録返信メッセージを送信する場合があります。言い換えれば、そのような外国人エージェントは、リクエストに有効な課題が含まれていない限り、モバイルノードからの登録要求の処理を拒否する場合があります。
If a mobile node retransmits a Registration Request with the same Identification field and the same Challenge extension, and the Foreign Agent still has a pending Registration Request record in effect for the mobile node, then the Foreign Agent forwards the Registration Request to the Home Agent again. In all other circumstances, if the Foreign Agent receives a Registration Request with a Challenge extension containing a Challenge value previously used by that mobile node, the Foreign Agent SHOULD send a Registration Reply to the mobile node containing the Code value STALE_CHALLENGE.
モバイルノードが同じ識別フィールドと同じチャレンジエクステンションを備えた登録要求を再送信し、外国人エージェントがモバイルノードに有効な保留中の登録要求レコードを持っている場合、外国人エージェントは再び登録要求をホームエージェントに転送します。他のすべての状況で、外国人エージェントがそのモバイルノードで以前に使用されていたチャレンジ値を含むチャレンジ拡張機能を備えた登録要求を受け取った場合、外国人エージェントはコード値Stale_Challengeを含むモバイルノードに登録返信を送信する必要があります。
The Foreign Agent MUST NOT accept any Challenge in the Registration Request unless it was offered in last successful Registration Reply issued to the Mobile Node, or else advertised as one of the last CHALLENGE_WINDOW (see section 9) Challenge values inserted into the immediately preceding Agent advertisements. If the Challenge is not one of the recently advertised values, the foreign Agent SHOULD send a Registration Reply with Code UNKNOWN_CHALLENGE (see section 10).
外国人エージェントは、モバイルノードに発行された最後の成功した登録返信で提供されない場合、または最後の課題_Window（セクション9を参照）の1つとして宣伝されていない場合を除き、登録要求に課題を受け入れてはなりません。。課題が最近宣伝された値の1つではない場合、外国人エージェントはコード不明_Challenge（セクション10を参照）で登録返信を送信する必要があります。
Furthermore, the Foreign Agent MUST check that there is either a Mobile-Foreign, or a MN-AAA Authentication extension after the Challenge extension. Any registration message containing the Challenge extension without either of these authentication extensions MUST be silently discarded. If the registration message contains a Mobile-Foreign Authentication extension with an incorrect authenticator that fails verification, the Foreign Agent MAY send a Registration Reply to the mobile node with Code value BAD_AUTHENTICATION (see Section 10).
さらに、外国のエージェントは、チャレンジ拡張後にモバイル外定またはMN-AAA認証拡張機能があることを確認する必要があります。これらの認証拡張機能のいずれかなしでチャレンジ拡張機能を含む登録メッセージは、静かに破棄する必要があります。登録メッセージに、検証に失敗した誤った認証器を使用したモバイル外定認証拡張機能が含まれている場合、外国人エージェントはコード値BAD_AUTHENTICATIONでモバイルノードに登録返信を送信できます（セクション10を参照）。
If the MN-AAA Authentication extension (see Section 6) is present in the message, or if an NAI extension is included indicating that the mobile node belongs to a different administrative domain, the foreign agent may take actions outside the scope of this protocol specification to carry out the authentication of the mobile node. The Foreign Agent MUST NOT remove the MN-AAA Authentication Extension from the Registration Request prior to the completion of the authentication performed by the AAA infrastructure. The appendix provides an example of an action that could be taken by a foreign agent.
MN-AAA認証拡張機能（セクション6を参照）がメッセージに存在する場合、またはモバイルノードが異なる管理ドメインに属していることを示すNAI拡張機能が含まれている場合、外国人エージェントはこのプロトコル仕様の範囲外でアクションを実行することができますモバイルノードの認証を実行します。外国人エージェントは、AAAインフラストラクチャによって実行される認証が完了する前に、登録要求からMN-AAA認証拡張機能を削除してはなりません。付録には、外国人エージェントが取ることができるアクションの例を示しています。
In the event that the Challenge extension is authenticated through the Mobile-Foreign Authentication Extension, the Foreign Agent MAY remove the Challenge Extension from the Registration Request without disturbing the authentication value computed by the Mobile Node for use by the AAA or the Home Agent. If the Challenge extension is not removed, it MUST precede the Foreign-Home Authentication extension.
モバイル外定認証拡張機能を通じてチャレンジ拡張機能が認証された場合、外国人エージェントは、AAAまたはホームエージェントが使用するためにモバイルノードによって計算された認証値を妨害することなく、登録要求からチャレンジ拡張機能を削除することができます。チャレンジ拡張機能が削除されない場合、外国の在宅認証拡張に先行する必要があります。
If the Foreign Agent does not remove the Challenge extension, then the Foreign Agent SHOULD store the Challenge value as part of the pending registration request list [8]. Also in this case, the Foreign Agent MUST reject any Registration Reply message coming from the Home Agent that does not also include the Challenge Extension with the same Challenge Value that was included in the Registration Request. The Foreign Agent MUST send the rejected Registration message to the mobile node, and change the status in the Registration Reply to the value MISSING_CHALLENGE (see section 10).
外国人エージェントがチャレンジ延長を削除しない場合、外国人エージェントは、保留中の登録要求リストの一部としてチャレンジ値を保存する必要があります[8]。また、この場合、外国人エージェントは、登録要求に含まれている同じチャレンジ値を持つチャレンジ拡張機能も含まれていないホームエージェントからの登録返信メッセージを拒否する必要があります。外国人エージェントは、拒否された登録メッセージをモバイルノードに送信し、登録の返信のステータスをMissing_Challengeの値に変更する必要があります（セクション10を参照）。
If the Foreign Agent does remove the Challenge extension and applicable authentication from the Registration Request message, then it SHOULD insert the Identification field from the Registration Request message along with its record-keeping information about the particular Mobile Node in order to protect against replays.
外国人エージェントが登録要求メッセージからチャレンジ拡張機能と該当する認証を削除する場合、リプレイから保護するために、特定のモバイルノードに関する記録維持情報とともに登録要求メッセージから識別フィールドを挿入する必要があります。
The Foreign Agent MAY include a new Challenge extension in any Registration Reply, successful or not. If the foreign agent includes this extension in a successful Registration Reply, the extension SHOULD precede a MN-FA authentication extension.
外国人エージェントには、登録返信に新しいチャレンジ拡張機能が含まれる場合があります。外国人が登録返信を成功させてこの拡張機能を含めた場合、拡張機能はMN-FA認証拡張機能の前に行われるはずです。
Suppose the Registration Reply includes a Challenge extension from the Home Agent, and the foreign agent wishes to include another Challenge extension with the Registration Reply for use by the mobile node. In that case, the foreign agent MUST delete the Challenge extension from the Home Agent from the Registration Reply, along with any FA-HA authentication extension, before appending the new Challenge extension to the Registration Reply.
登録返信にホームエージェントからのチャレンジ延長が含まれており、外国人エージェントがモバイルノードで使用するための登録返信に別のチャレンジ拡張機能を含めることを望んでいるとします。その場合、外国人エージェントは、登録返信に新しいチャレンジ拡張機能を追加する前に、FA-HA認証拡張機能とともに、登録返信からホームエージェントからのチャレンジ拡張機能を削除する必要があります。
If the Home Agent receives a Registration Request with the MN-FA Challenge extension, and recognizes the extension, the Home Agent MUST include the Challenge extension in the Registration Reply. The Challenge Extension MUST be placed after the Mobile-Home authentication extension, and the extension SHOULD be authenticated by a Foreign-Home Authentication extension.
ホームエージェントがMN-FAチャレンジ拡張機能を備えた登録要求を受け取り、拡張機能を認識した場合、ホームエージェントは登録返信にチャレンジ拡張機能を含める必要があります。チャレンジ拡張機能は、モバイルホーム認証拡張機能の後に配置する必要があり、拡張機能は外国在宅認証拡張機能によって認証される必要があります。
Since the extension type for the Challenge extension is within the range 128-255, the Home Agent MUST process such a Registration Request even if it does not recognize the Challenge extension [8]. In this case, the Home Agent will send a Registration Reply to the Foreign Agent that does not include the Challenge extension.
チャレンジ拡張の拡張タイプは範囲128-255内であるため、ホームエージェントは、チャレンジ拡張を認識していなくても、そのような登録要求を処理する必要があります[8]。この場合、ホームエージェントは、チャレンジエクステンションを含まない外国人エージェントに登録返信を送信します。
This section specifies a new Mobile IP Registration extension that is used to satisfy a Challenge in an Agent Advertisement. The Challenge extension to the Registration Request message is used to indicate the challenge that the mobile node is attempting to satisfy.
このセクションでは、エージェント広告の課題を満たすために使用される新しいモバイルIP登録拡張機能を指定します。登録要求メッセージへの課題の拡張は、モバイルノードが満たそうとしている課題を示すために使用されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Challenge...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The MN-FA Challenge Extension
図2：MN-FAチャレンジ拡張
Type 132 (skippable) (see [8])
タイプ132（スキップ可能）（[8]を参照）
Length Length of the Challenge value Challenge The Challenge field is copied from the Challenge field found in the Agent Advertisement Challenge extension (see section 2).
チャレンジバリューチャレンジの長さの長さチャレンジフィールドは、エージェント広告チャレンジ拡張に見られるチャレンジフィールドからコピーされます（セクション2を参照）。
Several new authentication extensions have been designed for various control messages proposed for extensions to Mobile IP (see, for example, [9]). A new authentication extension is required for a mobile node to present its credentials to any other entity other than the ones already defined; the only entities defined in the base Mobile IP specification [8] are the home agent and the foreign agent. It is the purpose of the generalized authentication extension defined here to collect together data for all such new authentication applications into a single extension type with subtypes.
モバイルIPへの拡張用に提案されているさまざまな制御メッセージ用にいくつかの新しい認証拡張機能が設計されています（たとえば[9]を参照）。モバイルノードがすでに定義されているエンティティ以外のエンティティに資格情報を提示するには、新しい認証拡張機能が必要です。ベースモバイルIP仕様[8]で定義されている唯一のエンティティは、ホームエージェントと外国人エージェントです。これは、このようなすべての新しい認証アプリケーションのデータを収集して、サブタイプを備えた単一の拡張型タイプにまとめるために、一般化された認証拡張機能の目的です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authenticator ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The Generalized Mobile IP Authentication Extension
図3：一般化されたモバイルIP認証拡張機能
Type 36 (not skippable) (see [8])
タイプ36（スキップできない）（[8]を参照）
Subtype a number assigned to identify the kind of endpoints or characteristics of the particular authentication strategy
サブタイプ特定の認証戦略のエンドポイントまたは特性の種類を識別するために割り当てられた数字
Length 4 plus the number of bytes in the Authenticator; MUST be at least 20.
長さ4と、認証器のバイト数。少なくとも20でなければなりません。
SPI Security Parameters Index
SPIセキュリティパラメーターインデックス
Authenticator The variable length Authenticator field
Authenticator可変長さ認証器フィールド
In this document, only one subtype is defined:
このドキュメントでは、1つのサブタイプのみが定義されています。
1 MN-AAA Authentication subtype (see section 6)
1 MN-AAA認証サブタイプ（セクション6を参照）
The Generalized Authentication extension with subtype 1 will be referred to as a MN-AAA Authentication extension. If the mobile node does not include a Mobile-Foreign Authentication [8] extension, then it MUST include the MN-AAA Authentication extension whenever the Challenge extension is present. If the MN-AAA Authentication extension is present, then the Registration Message sent by the mobile node MUST contain the Mobile-HA Authentication extension [8] if it shares a security association with the Home Agent. If present, the Mobile-HA Authentication Extension MUST appear prior to the MN-AAA Authentication extension. The mobile node MAY include a MN-AAA Authentication extension in any Registration Request. The corresponding response MUST include the MN-HA Authentication Extension, and MUST NOT include the MN-AAA Authentication Extension.
サブタイプ1を使用した一般化された認証拡張機能は、MN-AAA認証拡張機能と呼ばれます。モバイルノードにモバイル外定認証[8]拡張機能が含まれていない場合、チャレンジ拡張機能が存在する場合はいつでもMN-AAA認証拡張機能を含める必要があります。MN-AAA認証拡張機能が存在する場合、モバイルノードから送信された登録メッセージには、ホームエージェントとセキュリティ関連を共有する場合、モバイルHA認証拡張機能[8]を含める必要があります。存在する場合、MN-AAA認証拡張の前にモバイルHA認証拡張機能が表示される必要があります。モバイルノードには、登録リクエストにMN-AAA認証拡張機能を含めることができます。対応する応答には、MN-HA認証拡張機能を含める必要があり、MN-AAA認証拡張機能を含めてはなりません。
The default algorithm for computation of the authenticator is HMAC-MD5 [5] computed on the following data, in the order shown:
Authenticatorの計算のデフォルトアルゴリズムは、次のデータで計算されたHMAC-MD5 [5]です。
Preceding Mobile IP data || Type, Subtype, Length, SPI
前のモバイルIPデータ||タイプ、サブタイプ、長さ、SPI
where the Type, Length, Subtype, and SPI are as shown in section 5. The resulting function call, as described in [5], would be:
セクション5に示すように、タイプ、長さ、サブタイプ、およびSPIが示すとおりです。[5]で説明されているように、結果の関数呼び出しは次のとおりです。
hmac_md5(data, datalen, Key, KeyLength, authenticator);
HMAC_MD5（データ、Datalen、Key、KeyLength、Authenticator）;
Each mobile node MUST support the ability to produce the authenticator by using HMAC-MD5 as shown. Just as with Mobile IP, this default algorithm MUST be able to be configured for selection at any arbitrary 32-bit SPI outside of the SPIs in the reserved range 0-255.
各モバイルノードは、図のようにHMAC-MD5を使用して認証器を生成する機能をサポートする必要があります。モバイルIPと同様に、このデフォルトのアルゴリズムは、予約範囲0〜255のSPIの外側の任意の32ビットSPIで選択するために構成できる必要があります。
Mobile IP defines several authentication extensions for use in Registration Requests and Replies. Each authentication extension carries a Security Parameters Index (SPI) which should be used to index a table of security associations. Values in the range 0 - 255 are reserved for special use. A list of reserved SPI numbers is to be maintained by IANA at the following URL:
モバイルIPは、登録リクエストと返信で使用するためのいくつかの認証拡張機能を定義します。各認証拡張機能には、セキュリティアソシエーションのテーブルのインデックスを作成するために使用する必要があるセキュリティパラメータインデックス（SPI）が搭載されています。範囲0〜255の値は、特別な使用のために予約されています。予約されたSPI番号のリストは、次のURLでIANAによって維持されます。
http://www.iana.org/numbers.html
http://www.iana.org/numbers.html
Some AAA servers only admit a single security association, and thus do not use the SPI numbers for Mobile IP authentication extensions for use when determining the security association that would be necessary for verifying the authentication information included with the Authentication extension.
一部のAAAサーバーは、単一のセキュリティアソシエーションのみを認めているため、認証拡張に含まれる認証情報を確認するために必要なセキュリティ協会を決定する際に使用するために、モバイルIP認証拡張機能にSPI番号を使用しません。
SPI number CHAP_SPI (see section 9) is reserved (see section 7) for indicating the following procedure for computing authentication data (called the "authenticator"), which is used by many RADIUS servers [10] today.
SPI番号CHAP_SPI（セクション9を参照）は、認証データを計算するための以下の手順を示すために予約されています（セクション7を参照）。
To compute the authenticator, apply MD5 [11] computed on the following data, in the order shown:
Authenticatorを計算するには、次のデータに計算されたMD5 [11]を示します。
High-order byte from Challenge || Key || MD5(Preceding Mobile IP data || Type, Subtype (if present), Length, SPI) || Least-order 237 bytes from Challenge
チャレンジ||からの高次バイトキー||MD5（前のモバイルIPデータ||タイプ、サブタイプ（存在する場合）、長さ、SPI）||チャレンジから最小注文237バイト
where the Type, Length, SPI, and possibly Subtype, are the fields of the authentication extension in use. For instance, all four of these fields would be in use when SPI == CHAP_SPI is used with the Generalized Authentication extension. Since the RADIUS protocol cannot carry attributes greater than 253 in size, the preceding Mobile IP data, type, subtype (if present), length and SPI are hashed using MD5. Finally, the least significant 237 bytes of the challenge are concatenated.
このタイプ、長さ、SPI、および場合によってはサブタイプが、使用中の認証拡張のフィールドです。たとえば、これらの4つのフィールドはすべて、SPI == CHAP_SPIが一般化された認証拡張機能で使用される場合に使用されます。RADIUSプロトコルのサイズは253を超える属性を運ぶことができないため、前のモバイルIPデータ、タイプ、サブタイプ（存在する場合）、長さ、およびSPIはMD5を使用してハッシュされます。最後に、課題の最も重要ではない237バイトが連結されます。
Every Mobile IP agent supporting the extensions defined in this document SHOULD be able to configure each parameter in the following table. Each table entry contains the name of the parameter, the default value, and the section of the document in which the parameter first appears.
このドキュメントで定義されている拡張機能をサポートするすべてのモバイルIPエージェントは、次の表に各パラメーターを構成できるはずです。各テーブルエントリには、パラメーターの名前、デフォルト値、およびパラメーターが最初に表示されるドキュメントのセクションが含まれます。
Parameter Name Default Value Section(s) of Document
-------------- ------------- ----------------------
CHALLENGE_WINDOW 2 3.2
CHAP_SPI 2 8
Each entry in the following table contains the name of Code [8] to be returned in a Registration Reply, the value for the Code, and the section in which the error is first mentioned in this specification.
次の表の各エントリには、登録返信で返されるコード[8]の名前、コードの値、およびこの仕様でエラーが最初に言及されているセクションが含まれています。
Error Name Value Section of Document
---------------------- ----- -------------------
UNKNOWN_CHALLENGE 104 3.2
BAD_AUTHENTICATION 67 3.2 - also see [8]
MISSING_CHALLENGE 105 3.1,3.2
STALE_CHALLENGE 106 3.2
The Generalized Mobile IP Authentication extension defined in Section 5 is a Mobile IP registration extension as defined in RFC 2002 [8] and extended in RFC 2356 [7]. IANA should assign a value of 36 for this extension.
セクション5で定義されている一般化されたモバイルIP認証拡張機能は、RFC 2002 [8]で定義され、RFC 2356 [7]で定義されているモバイルIP登録拡張拡張機能です。IANAは、この拡張機能に36の値を割り当てる必要があります。
A new number space is to be created for enumerating subtypes of the Generalized Authentication extension (see section 5). New subtypes of the Generalized Authentication extension, other than the number (1) for the MN-AAA authentication extension specified in section 6, must be specified and approved by a designated expert.
一般化された認証拡張のサブタイプを列挙するために、新しい数値スペースを作成します（セクション5を参照）。セクション6で指定されたMN-AAA認証拡張機能の数（1）以外の一般化認証拡張機能の新しいサブタイプは、指定された専門家によって指定および承認される必要があります。
The MN-FA Challenge Extension defined in Section 4 is a router advertisement extension as defined in RFC 1256 [3] and extended in RFC 2002 [8]. IANA should assign a value of 132 for this purpose.
セクション4で定義されているMN-FAチャレンジ拡張は、RFC 1256 [3]で定義され、RFC 2002 [8]で拡張されたルーター広告拡張機能です。IANAは、この目的のために132の値を割り当てる必要があります。
The Code values defined in Section 10 are error codes as defined in RFC 2002 [8] and extended in RFC 2344 [6] and RFC 2356 [7]. They correspond to error values conventionally associated with rejection by the foreign agent (i.e., values from the range 64-127). The Code value 67 is a pre-existing value which is to be used in some cases with the extension defined in this specification. IANA should record the values as defined in Section 10.
セクション10で定義されているコード値は、RFC 2002 [8]で定義されており、RFC 2344 [6]およびRFC 2356 [7]で拡張されたエラーコードです。それらは、外国のエージェントによる拒絶に従来関連するエラー値（つまり、範囲64-127の値）に対応しています。コード値67は既存の値であり、この仕様で定義されている拡張機能を伴う場合によっては使用される場合があります。IANAは、セクション10で定義されている値を記録する必要があります。
A new section for enumerating algorithms identified by specific SPIs within the range 0-255 is to be added to
範囲0〜255内の特定のSPIによって識別される列挙アルゴリズムのための新しいセクションは、に追加されます
http://www.isi.edu/in-notes/iana/assignments/mobileip-numbers.
http://www.isi.edu/in-notes/iana/assignments/mobileip-numbers.
The CHAP_SPI number (2) discussed in section 8 is to be assigned from this range of reserved SPI numbers. New assignments from this reserved range must be specified and approved by the Mobile IP working group. SPI number 1 should not be assigned unless in the future the Mobile IP working group decides that SKIP is not important for enumeration in the list of reserved numbers. SPI number 0 should not be assigned.
セクション8で説明したchap_spi番号（2）は、この範囲の予約されたSPI番号から割り当てられます。この予約範囲からの新しい割り当ては、モバイルIPワーキンググループによって指定および承認されなければなりません。SPI番号1は、将来、モバイルIPワーキンググループが予約数のリストの列挙にスキップが重要ではないと判断しない限り、割り当てられないでください。SPI番号0を割り当てないでください。
In the event that a malicious mobile node attempts to replay the authenticator for an old MN-FA Challenge, the Foreign Agent would detect it since the agent always checks whether it has recently advertised the Challenge (see section 3.2). Allowing mobile nodes with different IP addresses or NAIs to use the same Challenge value does not represent a security vulnerability, because the authentication data provided by the mobile node will be computed over data that is different (at least by the bytes of the mobile nodes' IP addresses).
悪意のあるモバイルノードがAuthenticatorを古いMN-FAチャレンジのために再生しようとした場合、外国人エージェントは、エージェントが最近課題を宣伝したかどうかを常にチェックしているため、それを検出します（セクション3.2を参照）。モバイルノードによって提供される認証データは、異なるデータに対して（少なくともモバイルノードのバイトによって」と計算されるため、異なるIPアドレスまたはNAISのモバイルノードが同じチャレンジ値を使用してもセキュリティの脆弱性を表していません。IPアドレス）。
Whenever a Foreign Agent updates a field of the Registration Reply (as suggested in section 3.2), it invalidates the authentication data supplied by the Home Agent in the MN-HA Authentication extension to the Registration Reply. Thus, this opens up a security exposure whereby a node might try to supply a bogus Registration Reply to a mobile node that causes the mobile node to act as if its Registration Reply were rejected. This might happen when, in fact, a Registration Reply showing acceptance of the registration might soon be received by the mobile node.
外国人エージェントが登録返信のフィールドを更新するたびに（セクション3.2で提案されているように）、MN-HA認証拡張でホームエージェントが提供する認証データを登録返信に無効にします。したがって、これにより、ノードがモバイルノードへの偽の登録返信を供給しようとするセキュリティ露出が開き、モバイルノードが登録応答が拒否されたかのように動作します。これは、実際、登録の受け入れを示す登録返信がモバイルノードによってすぐに受信される可能性がある場合に発生する可能性があります。
If the foreign agent chooses a Challenge value (see section 2) with fewer than 4 bytes, the foreign agent SHOULD maintain records that also the Identification field for the mobile node. The foreign agent can then find assurance that the Registration messages using the short Challenge value are in fact unique, and thus assuredly not replayed from any earlier registration.
外国人エージェントが4バイト未満のチャレンジ値（セクション2を参照）を選択した場合、外国人エージェントはモバイルノードの識別フィールドも記録を維持する必要があります。外国人エージェントは、短いチャレンジ値を使用して登録メッセージが実際に一意であるという保証を見つけることができ、したがって、以前の登録から再生されないことは間違いありません。
Section 8 (SPI For RADIUS AAA Servers) defines a method of computing the Generalized Mobile IP Authentication Extension's authenticator field using MD5 in a manner that is consistent with RADIUS [10]. The use of MD5 in the method described in Section 8 is less secure than HMAC-MD5 [5], and should be avoided whenever possible.
セクション8（RADIUS AAAサーバーのSPI）は、RADIUSと一致する方法でMD5を使用して、一般化されたモバイルIP認証拡張子の認証器フィールドを計算する方法を定義しています[10]。セクション8で説明した方法でのMD5の使用は、HMAC-MD5 [5]よりも安全性が低く、可能な限り避ける必要があります。
The authors would like to thank Tom Hiller, Mark Munson, the TIA TR45-6 WG, Gabriel Montenegro, Vipul Gupta, and Pete McCann for their useful discussions. A recent draft by Mohamed Khalil, Raja Narayanan, Emad Qaddoura, and Haseeb Akhtar has also suggested the definition of a generalized authentication extension similar to the specification contained in section 5.
著者は、トム・ヒラー、マーク・マンソン、TIA TR45-6 WG、ガブリエル・モンテネグロ、ヴィプル・グプタ、ピート・マッキャンの有用な議論に感謝したいと思います。Mohamed Khalil、Raja Narayanan、Emad Qaddoura、およびHaseeb Akhtarによる最近のドラフトは、セクション5に含まれる仕様と同様の一般化された認証拡張の定義も示唆しています。
References
参考文献
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Calhoun, P. and C. Perkins. "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, January 2000.
[2] Calhoun、P。およびC. Perkins。「IPv4のモバイルIPネットワークアクセス識別子拡張機能」、RFC 2794、2000年1月。
[3] Deering, S., "ICMP Router Discovery Messages", RFC 1256, September 1991.
[3] Deering、S。、「ICMPルーター発見メッセージ」、RFC 1256、1991年9月。
[4] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[4] Eastlake、D.、Crocker、S。、およびJ. Schiller、「セキュリティのためのランダム性の推奨」、RFC 1750、1994年12月。
[5] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[5] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：メッセージ認証のためのキードハッシング」、RFC 2104、1997年2月。
[6] Montenegro, G., "Reverse Tunneling for Mobile IP", RFC 2344, May 1998.
[6] モンテネグロ、G。、「モバイルIPの逆トンネル」、RFC 2344、1998年5月。
[7] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for Mobile IP", RFC 2356, June 1998.
[7] モンテネグロ、G。およびV.グプタ、「モバイルIPのSun's Skip Firewalversal」、RFC 2356、1998年6月。
[8] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[8] Perkins、C。、「IP Mobility Support」、RFC 2002、1996年10月。
[9] Perkins, C. and D. Johnson, "Route Optimization in Mobile IP", Work in Progress.
[9] Perkins、C。およびD. Johnson、「モバイルIPのルート最適化」は、進行中の作業です。
[10] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.
[10] Rigney、C.、Rubens、A.、Simpson、W。and S. Willens、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2138、1997年4月。
[11] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[11] Rivest、R。、「The Md5 Message-Digest Algorithm」、RFC 1321、1992年4月。
[12] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[12] シンプソン、W。、「PPPチャレンジハンドシェイク認証プロトコル（CHAP）」、RFC 1994、1996年8月。
A. Verification Infrastructure
A.検証インフラストラクチャ
The Challenge extensions in this protocol specification are expected to be useful to help the Foreign Agent manage connectivity for visiting mobile nodes, even in situations where the foreign agent does not have any security association with the mobile node or the mobile node's home agent. In order to carry out the necessary authentication, it is expected that the foreign agent will need the assistance of external administrative systems, which have come to be called AAA systems. For the purposes of this document, we call the external administrative support the "verification infrastructure". The verification infrastructure is described to motivate the design of the protocol elements defined in this document, and is not strictly needed for the protocol to work. The foreign agent is free to use any means at its disposal to verify the credentials of the mobile node. This could, for instance, rely on a separate protocol between the foreign agent and the Mobile IP home agent, and still be completely invisible to the mobile node.
このプロトコル仕様の課題拡張は、外国のエージェントがモバイルノードまたはモバイルノードのホームエージェントとセキュリティ関連がない状況であっても、外国人エージェントがモバイルノードにアクセスするための接続を管理するのに役立つと予想されます。必要な認証を実行するためには、AAAシステムと呼ばれるようになった外部管理システムの支援が必要になると予想されます。このドキュメントの目的のために、外部管理サポートを「検証インフラストラクチャ」と呼びます。検証インフラストラクチャは、このドキュメントで定義されているプロトコル要素の設計を動機付けるために説明されており、プロトコルが機能するためには厳密に必要ではありません。外国人エージェントは、モバイルノードの資格情報を検証するために、あらゆる手段を自由に使用できます。これは、たとえば、外国人エージェントとモバイルIPホームエージェントの間の別のプロトコルに依存している可能性があり、モバイルノードには完全に見えません。
In order to verify the credentials of the mobile node, we imagine that the foreign agent has access to a verification infrastructure that can return a secure notification to the foreign agent that the authentication has been performed, along with the results of that authentication. This infrastructure may be visualized as shown in figure 4.
モバイルノードの資格情報を検証するために、外国人エージェントは、その認証の結果とともに、認証が実行されたことを外部エージェントに安全な通知を返すことができる検証インフラストラクチャにアクセスできると想像します。このインフラストラクチャは、図4に示すように視覚化できます。
+----------------------------------------------------+
| |
| Verification and Key Management Infrastructure |
| |
+----------------------------------------------------+
^ | ^ |
| | | |
| v | v
+---------------+ +---------------+
| | | |
| Foreign Agent | | Home Agent |
| | | |
+---------------+ +---------------+
Figure 4: The Verification Infrastructure
図4：検証インフラストラクチャ
After the foreign agent gets the Challenge authentication, it MAY pass the authentication to the (here unspecified) infrastructure, and await a Registration Reply. If the Reply has a positive status (indicating that the registration was accepted), the foreign agent accepts the registration. If the Reply contains the Code value BAD_AUTHENTICATION (see Section 10), the foreign agent takes actions indicated for rejected registrations.
外国人エージェントがチャレンジ認証を取得した後、認証を（ここでは不特定の）インフラストラクチャに渡し、登録返信を待つことができます。返信が正のステータスを持っている場合（登録が受け入れられたことを示します）、外国人エージェントは登録を受け入れます。返信にコード値が含まれている場合（セクション10を参照）、外国人エージェントは拒否された登録に示されている措置を講じます。
Implicit in this picture, is the important observation that the Foreign Agent and the Home Agent have to be equipped to make use of whatever protocol is made available to them by the challenge verification and key management infrastructure shown in the figure.
この写真に暗黙的には、外国人エージェントとホームエージェントが、図に示されているチャレンジ検証と主要な管理インフラストラクチャによって利用可能になるプロトコルを利用できるように装備する必要があるという重要な観察です。
The protocol messages for handling the authentication within the verification infrastructure, and identity of the agent performing the verification of the Foreign Agent challenge, are not specified in this document, because those operations do not have to be performed by any Mobile IP entity.
検証インフラストラクチャ内で認証を処理するためのプロトコルメッセージ、および外国エージェントチャレンジの検証を実行するエージェントのIDは、このドキュメントでは指定されていません。これらの操作は、モバイルIPエンティティで実行する必要がないためです。
Addresses
アドレス
The working group can be contacted via the current chairs:
ワーキンググループは、現在の椅子から連絡できます。
Basavaraj Patil Nokia Corporation 6000 Connection Drive M/S M8-540 Irving, Texas 75039 USA
Basavaraj Patil Nokia Corporation 6000 Connection Drive M/S M8-540 Irving、Texas 75039 USA
Phone: +1 972-894-6709
Fax : +1 972-894-5349
EMail: Basavaraj.Patil@nokia.com
Phil Roberts Motorola 1501 West Shure Drive Arlington Heights, IL 60004 USA
フィルロバーツモトローラ1501ウェストシュアードライブアーリントンハイツ、イリノイ60004 USA
Phone:+1 847-632-3148 EMail: QA3445@email.mot.com Questions about this memo can also be directed to the authors:
電話：1 847-632-3148メール：QA3445@email.mot.comこのメモに関する質問は、著者にも送信できます。
Charles E. Perkins Communications Systems Lab Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA
チャールズE.パーキンスコミュニケーションシステムラボノキアリサーチセンター313フェアチャイルドドライブマウンテンビュー、カリフォルニア94043 USA
Phone: +1-650 625-2986
Fax: +1 650 625-2502
EMail: charliep@iprg.nokia.com
Pat R. Calhoun Network & Security Center Sun Microsystems Laboratories 15 Network Circle Menlo Park, California 94025 USA
PAT R. Calhoun Network＆Security Center Sun Microsystems Laboratories 15 Network Circle Menlo Park、California 94025 USA
Phone: +1 650-786-7733
Fax: +1 650-786-6445
EMail: pcalhoun@eng.sun.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。