RFC2284 日本語訳
2284 PPP Extensible Authentication Protocol (EAP). L. Blunk, J.Vollbrecht. March 1998. (Format: TXT=29452 bytes) (Obsoleted by RFC3748) (Updated by RFC2484) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group L. Blunk
Request for Comments: 2284 J. Vollbrecht
Category: Standards Track Merit Network, Inc.
March 1998
Blunkがコメントのために要求するワーキンググループL.をネットワークでつないでください: 2284年のJ.Vollbrechtカテゴリ: 1998年の標準化過程長所ネットワークInc.行進
PPP Extensible Authentication Protocol (EAP)
ppp拡張認証プロトコル(EAP)
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 (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Abstract
要約
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
Pointからポイントへのプロトコル(PPP)[1]はポイントツーポイント接続の上でマルチプロトコルデータグラムを輸送するための標準方法を提供します。
PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link.
また、PPPは広げることができるLink Controlプロトコルを定義します。(それは、Network Layerプロトコルがリンクの上に伝わるのを許容する前に同輩を認証するためのAuthenticationプロトコルの交渉を許します)。
This document defines the PPP Extensible Authentication Protocol.
このドキュメントはPPP拡張認証プロトコルを定義します。
Table of Contents
目次
1. Introduction .......................................... 2
1.1 Specification of Requirements ................... 2
1.2 Terminology ..................................... 2
2. PPP Extensible Authentication Protocol (EAP) .......... 3
2.1 Configuration Option Format ..................... 4
2.2 Packet Format ................................... 6
2.2.1 Request and Response ............................ 6
2.2.2 Success and Failure ............................. 7
3. Initial EAP Request/Response Types .................... 8
3.1 Identity ........................................ 9
3.2 Notification .................................... 10
3.3 Nak ............................................. 10
1. 序論… 2 1.1 要件の仕様… 2 1.2用語… 2 2. ppp拡張認証プロトコル(EAP)… 3 2.1 設定オプション形式… 4 2.2 パケット形式… 6 2.2 .1の要求と応答… 6 2.2 .2の成功と失敗… 7 3. EAP要求/応答タイプに頭文字をつけてください… 8 3.1のアイデンティティ… 9 3.2通知… 10 3.3Nak… 10
Blunk & Vollbrecht Standards Track [Page 1] RFC 2284 EAP March 1998
Blunk&Vollbrecht規格は1998年のEAP行進のときにRFC2284を追跡します[1ページ]。
3.4 MD5-Challenge ................................... 11
3.5 One-Time Password (OTP) ......................... 11
3.6 Generic Token Card .............................. 12
REFERENCES ................................................... 13
ACKNOWLEDGEMENTS ............................................. 14
CHAIR'S ADDRESS .............................................. 14
AUTHORS' ADDRESSES ........................................... 14
Full Copyright Statement ..................................... 15
3.4 MD5-挑戦… 11 3.5 ワンタイムパスワード(OTP)… 11 3.6 ジェネリックトークン・カード… 12の参照箇所… 13の承認… 14 議長のアドレス… 14人の作者のアドレス… 14 完全な著作権宣言文… 15
1. Introduction
1. 序論
In order to establish communications over a point-to-point link, each end of the PPP link must first send LCP packets to configure the data link during Link Establishment phase. After the link has been established, PPP provides for an optional Authentication phase before proceeding to the Network-Layer Protocol phase.
ポイントツーポイント接続の上でコミュニケーションを確立して、PPPリンクの各端は、最初に、Link特権階級段階の間、データ・リンクを構成するためにパケットをLCPに送らなければなりません。 リンクが設立された後に、PPPはNetwork-層のプロトコルフェーズに続く前に、任意のAuthenticationフェーズに備えます。
By default, authentication is not mandatory. If authentication of the link is desired, an implementation MUST specify the Authentication-Protocol Configuration Option during Link Establishment phase.
デフォルトで、認証は義務的ではありません。 リンクの認証が望まれているなら、実装はLink特権階級段階の間、Authentication-プロトコルConfiguration Optionを指定しなければなりません。
These authentication protocols are intended for use primarily by hosts and routers that connect to a PPP network server via switched circuits or dial-up lines, but might be applied to dedicated links as well. The server can use the identification of the connecting host or router in the selection of options for network layer negotiations.
これらの認証プロトコルは、使用のために主として交換回線網かダイヤルアップ系列でPPPネットワークサーバに接続するホストとルータで意図しますが、また、専用リンクに付けられるかもしれません。 サーバはネットワーク層交渉にオプションの品揃えにおける、接続ホストかルータの識別を使用できます。
This document defines the PPP Extensible Authentication Protocol (EAP). The Link Establishment and Authentication phases, and the Authentication-Protocol Configuration Option, are defined in The Point-to-Point Protocol (PPP) [1].
このドキュメントはPPP拡張認証プロトコル(EAP)を定義します。 Link特権階級、Authenticationフェーズ、およびAuthentication-プロトコルConfiguration OptionはPointからポイントへのプロトコル(PPP)[1]で定義されます。
1.1. Specification of Requirements
1.1. 要件の仕様
In this document, several words are used to signify the requirements of the specification. These words are often capitalized. 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 RFC 2119 [6].
本書では、いくつかの単語が、仕様の要件を意味するのに使用されます。 これらの単語はしばしば大文字で書かれます。 キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[6]で説明されるように本書では解釈されることであるべきですか?
1.2. Terminology
1.2. 用語
This document frequently uses the following terms:
このドキュメントは頻繁に次の用語を使用します:
Blunk & Vollbrecht Standards Track [Page 2] RFC 2284 EAP March 1998
Blunk&Vollbrecht規格は1998年のEAP行進のときにRFC2284を追跡します[2ページ]。
authenticator
The end of the link requiring the authentication. The
authenticator specifies the authentication protocol to be
used in the Configure-Request during Link Establishment
phase.
固有識別文字、認証を必要とするリンクの端。 固有識別文字は、Link特権階級段階の間、Configure-要求で使用されるために認証プロトコルを指定します。
peer
The other end of the point-to-point link; the end which is
being authenticated by the authenticator.
他が終わらせるポイントツーポイント接続の同輩。 固有識別文字によって認証されている終わり。
silently discard
This means the implementation discards the packet without
further processing. The implementation SHOULD provide the
capability of logging the error, including the contents of
the silently discarded packet, and SHOULD record the event
in a statistics counter.
さらに処理しながら、静かにThis手段を実装がパケットを捨てる捨ててください。 実装SHOULDは静かに捨てられたパケットのコンテンツを含む誤りを登録する能力を提供します、そして、SHOULDは統計カウンタに出来事を記録に残します。
displayable message
This is interpreted to be a human readable string of
characters, and MUST NOT affect operation of the protocol.
The message encoding MUST follow the UTF-8 transformation
format [5].
「ディスプレイ-可能」メッセージThisはキャラクタの人間の読み込み可能なストリングになるように解釈されて、プロトコルの操作に影響してはいけません。 メッセージコード化はUTF-8変換形式[5]に続かなければなりません。
2. PPP Extensible Authentication Protocol (EAP)
2. ppp拡張認証プロトコル(EAP)
The PPP Extensible Authentication Protocol (EAP) is a general protocol for PPP authentication which supports multiple authentication mechanisms. EAP does not select a specific authentication mechanism at Link Control Phase, but rather postpones this until the Authentication Phase. This allows the authenticator to request more information before determining the specific authentication mechanism. This also permits the use of a "back-end" server which actually implements the various mechanisms while the PPP authenticator merely passes through the authentication exchange.
PPP拡張認証プロトコル(EAP)は複数の認証がメカニズムであるとサポートするPPP認証のための一般的なプロトコルです。EAPはLink Control Phaseで特定の認証機構を選択しませんが、Authentication Phaseまでむしろこれを延期します。 これで、特定の認証機構を決定する前に、固有識別文字は詳しい情報を要求できます。 また、これはPPP固有識別文字が単に認証交換を通り抜けますが、実際に様々なメカニズムを実装する「バックエンド」サーバの使用を可能にします。
1. After the Link Establishment phase is complete, the authenticator
sends one or more Requests to authenticate the peer. The Request
has a type field to indicate what is being requested. Examples of
Request types include Identity, MD5-challenge, One-Time
Passwords, Generic Token Card, etc. The MD5-challenge type
corresponds closely to the CHAP authentication protocol.
Typically, the authenticator will send an initial Identity Request
followed by one or more Requests for authentication information.
However, an initial Identity Request is not required, and MAY be
bypassed in cases where the identity is presumed (leased lines,
dedicated dial-ups, etc.).
1. Link特権階級フェーズが完全になった後に、固有識別文字は、同輩を認証するために1Requestsを送ります。 Requestには、要求されていることを示すタイプ分野があります。 Requestタイプに関する例はIdentity、MD5-挑戦、One-時間Passwords、Generic Token Cardなどを含んでいます。 MD5-挑戦タイプは密接にCHAP認証プロトコルに文通しています。 通常、固有識別文字は認証情報のために1Requestsによって続かれた初期のIdentity Requestを送るでしょう。 しかしながら、初期のIdentity Requestは必要でなく、アイデンティティが(専用線、ひたむきなダイヤルアップなど)であると推定される場合で迂回するかもしれません。
Blunk & Vollbrecht Standards Track [Page 3] RFC 2284 EAP March 1998
Blunk&Vollbrecht規格は1998年のEAP行進のときにRFC2284を追跡します[3ページ]。
2. The peer sends a Response packet in reply to each Request. As
with the Request packet, the Response packet contains a type field
which corresponds to the type field of the Request.
2. 同輩は各Requestに対してResponseパケットを送ります。 Requestパケットのように、ResponseパケットはRequestのタイプ分野に対応するタイプ分野を含んでいます。
3. The authenticator ends the authentication phase with a Success or
Failure packet.
3. 固有識別文字はSuccessかFailureパケットとの認証フェーズを終わらせます。
Advantages
利点
The EAP protocol can support multiple authentication mechanisms without having to pre-negotiate a particular one during LCP Phase.
LCP Phaseの間、特定のものをあらかじめ交渉する必要はなくて、EAPプロトコルは、複数の認証がメカニズムであるとサポートすることができます。
Certain devices (e.g. a NAS) do not necessarily have to understand each request type and may be able to simply act as a passthrough agent for a "back-end" server on a host. The device only need look for the success/failure code to terminate the authentication phase.
各要求を理解するために(例えば、NAS)には必ずあるというわけではないあるデバイスは、ホストの上の「バックエンド」サーバにおいてタイプして、passthroughエージェントとして単に務めることができるかもしれません。 デバイスだけが、認証フェーズを終えるために成功/失敗コードを探さなければなりません。
Disadvantages
不都合
EAP does require the addition of a new authentication type to LCP and thus PPP implementations will need to be modified to use it. It also strays from the previous PPP authentication model of negotiating a specific authentication mechanism during LCP.
EAPは新しい認証タイプの追加をLCPに必要とします、そして、その結果、PPP実装はそれを使用するように変更される必要があるでしょう。 また、それはLCPの間、特定の認証機構を交渉する前のPPP認証モデルから外れています。
2.1. Configuration Option Format
2.1. 設定オプション形式
A summary of the Authentication-Protocol Configuration Option format to negotiate the EAP Authentication Protocol is shown below. The fields are transmitted from left to right.
Configuration OptionがEAP Authenticationプロトコルを交渉するためにフォーマットするAuthentication-プロトコルの概要は以下に示されます。 野原は左から右まで伝えられます。
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 | Authentication-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
タイプ
3
3
Length
長さ
4
4
Authentication-Protocol
認証プロトコル
C227 (Hex) for PPP Extensible Authentication Protocol (EAP)
ppp拡張認証プロトコルのためのC227(十六進法)(EAP)
Blunk & Vollbrecht Standards Track [Page 4] RFC 2284 EAP March 1998
Blunk&Vollbrecht規格は1998年のEAP行進のときにRFC2284を追跡します[4ページ]。
2.2. Packet Format
2.2. パケット・フォーマット
Exactly one PPP EAP packet is encapsulated in the Information field of a PPP Data Link Layer frame where the protocol field indicates type hex C227 (PPP EAP). A summary of the EAP packet format is shown below. The fields are transmitted from left to right.
ちょうど1つのPPP EAPパケットがプロトコル分野がタイプ十六進法C227(PPP EAP)を示すPPP Data Link Layerフレームの情報分野でカプセルに入れられます。 EAPパケット・フォーマットの概要は以下に示されます。 野原は左から右まで伝えられます。
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 | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
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
コード
The Code field is one octet and identifies the type of EAP packet.
EAP Codes are assigned as follows:
Code分野は、1つの八重奏であり、EAPパケットのタイプを特定します。 EAP Codesは以下の通り割り当てられます:
1 Request
2 Response
3 Success
4 Failure
1 要求2応答3成功4失敗
Identifier
識別子
The Identifier field is one octet and aids in matching
responses with requests.
Identifier分野は、要求に応答に合うことにおいて1つの八重奏と援助です。
Length
長さ
The Length field is two octets and indicates the length of the
EAP packet including the Code, Identifier, Length and Data
fields. Octets outside the range of the Length field should
be treated as Data Link Layer padding and should be ignored on
reception.
Length分野は、2つの八重奏であり、Code、Identifier、Length、およびData分野を含むEAPパケットの長さを示します。 Data Link Layerがそっと歩いて、レセプションで無視されるべきであるとき、Length分野の範囲の外での八重奏は扱われるべきです。
Data
データ
The Data field is zero or more octets. The format of the Data
field is determined by the Code field.
Data分野はゼロであるか以上が八重奏です。 Data分野の形式はCode分野のそばで決定しています。
Blunk & Vollbrecht Standards Track [Page 5] RFC 2284 EAP March 1998
Blunk&Vollbrecht規格は1998年のEAP行進のときにRFC2284を追跡します[5ページ]。
2.2.1. Request and Response
2.2.1. 要求と応答
Description
記述
The Request packet is sent by the authenticator to the peer. Each
Request has a type field which serves to indicate what is being
requested. The authenticator MUST transmit an EAP packet with the
Code field set to 1 (Request). Additional Request packets MUST be
sent until a valid Response packet is received, or an optional
retry counter expires. Retransmitted Requests MUST be sent with
the same Identifier value in order to distinguish them from new
Requests. The contents of the data field is dependent on the
Request type. The peer MUST send a Response packet in reply to a
Request packet. Responses MUST only be sent in reply to a
received Request and never retransmitted on a timer. The
Identifier field of the Response MUST match that of the Request.
固有識別文字はRequestパケットを同輩に送ります。 各Requestには、要求されていることを示すのに役立つタイプ分野があります。 固有識別文字はCode分野セットで1(要求する)にEAPパケットを伝えなければなりません。 有効なResponseパケットが受け取られているまで追加Requestパケットを送らなければならない、さもなければ、任意の再試行カウンタは期限が切れます。 新しいRequestsと彼らを区別するために同じIdentifier値と共に再送されたRequestsを送らなければなりません。 データ・フィールドのコンテンツはRequestタイプに依存しています。 同輩はRequestパケットに対してResponseパケットを送らなければなりません。 応答を容認されたRequestに対して送られて、タイマの上に決して再送するだけでよくはありません。 ResponseのIdentifier分野はRequestのものに合わなければなりません。
Implementation Note: Because the authentication process will
often involve user input, some care must be taken when deciding
upon retransmission strategies and authentication timeouts. It
is suggested a retransmission timer of 6 seconds with a maximum
of 10 retransmissions be used as default. One may wish to make
these timeouts longer in certain cases (e.g. where Token Cards
are involved). Additionally, the peer must be prepared to
silently discard received retransmissions while waiting for
user input.
実装注意: 認証過程がしばしばユーザ入力にかかわるので、「再-トランスミッション」戦略と認証タイムアウトについて決めるとき、何らかの注意を払わなければなりません。 それは最大10「再-トランスミッション」がデフォルトとして使用されている6秒の提案されたa再送信タイマーです。 これらのタイムアウトをある場合には、より長く(例えば、どこで、Token Cardsはかかわりますか)したがっているかもしれません。 さらに、同輩はユーザ入力を待っている間、静かに容認された「再-トランスミッション」を捨てる用意ができていなければなりません。
A summary of the Request and Response packet format is shown below. The fields are transmitted from left to right.
RequestとResponseパケット・フォーマットの概要は以下に示されます。 野原は左から右まで伝えられます。
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 | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Type-Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
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
コード
1 for Request;
1 要求のために。
2 for Response.
2 応答のために。
Blunk & Vollbrecht Standards Track [Page 6] RFC 2284 EAP March 1998
Blunk&Vollbrecht規格は1998年のEAP行進のときにRFC2284を追跡します[6ページ]。
Identifier
識別子
The Identifier field is one octet. The Identifier field MUST be
the same if a Request packet is retransmitted due to a timeout
while waiting for a Response. Any new (non-retransmission)
Requests MUST modify the Identifier field. If a peer recieves a
duplicate Request for which it has already sent a Response, it
MUST resend it's Response. If a peer receives a duplicate Request
before it has sent a Response to the initial Request (i.e. it's
waiting for user input), it MUST silently discard the duplicate
Request.
Identifier分野は1つの八重奏です。 RequestパケットがタイムアウトのためResponseを待っている間、再送されるなら、Identifier分野は同じであるに違いありません。 どんな新しい(非「再-トランスミッション」の)要求もIdentifier分野を変更しなければなりません。 同輩recievesであるなら、それがそうした写しRequestは既にResponseを送って、それはResponseを再送しなければなりません。 初期のRequestにResponseを送る(すなわち、それはユーザ入力を待っています)前に同輩が写しRequestを受け取るなら、それは静かに写しRequestを捨てなければなりません。
Length
長さ
The Length field is two octets and indicates the length of the EAP
packet including the Code, Identifier, Length, Type, and Type-Data
fields. Octets outside the range of the Length field should be
treated as Data Link Layer padding and should be ignored on
reception.
Length分野は、2つの八重奏であり、Code、Identifier、Length、Type、およびType-データ・フィールドを含むEAPパケットの長さを示します。 Data Link Layerがそっと歩いて、レセプションで無視されるべきであるとき、Length分野の範囲の外での八重奏は扱われるべきです。
Type
タイプ
The Type field is one octet. This field indicates the Type of
Request or Response. Only one Type MUST be specified per EAP
Request or Response. Normally, the Type field of the Response
will be the same as the Type of the Request. However, there is
also a Nak Response Type for indicating that a Request type is
unacceptable to the peer. When sending a Nak in response to a
Request, the peer MAY indicate an alternative desired
authentication Type which it supports. An initial specification of
Types follows in a later section of this document.
Type分野は1つの八重奏です。 この分野はRequestかResponseのTypeを示します。 EAP RequestかResponse単位で1Typeだけを指定しなければなりません。 通常、ResponseのType分野はRequestのTypeと同じになるでしょう。 しかしながら、また、同輩にとって、Requestタイプが容認できないのを示すためのNak Response Typeがあります。 Requestに対応してNakを送るとき、同輩はそれがサポートする代替の必要な認証Typeを示すかもしれません。 Typesの初期の仕様はこのドキュメントの後のセクションで従います。
Type-Data
タイプデータ
The Type-Data field varies with the Type of Request and the
associated Response.
Type-データ・フィールドはRequestのTypeと関連Responseと共に異なります。
2.2.2. Success and Failure
2.2.2. 成功と失敗
Description
記述
The Success packet is sent by the authenticator to the peer to
acknowledge successful authentication. The authenticator MUST
transmit an EAP packet with the Code field set to 3 (Success).
固有識別文字でSuccessパケットを同輩に送って、うまくいっている認証を承諾します。 固有識別文字はCode分野セットで3(成功)にEAPパケットを伝えなければなりません。
If the authenticator cannot authenticate the peer (unacceptable
Responses to one or more Requests) then the implementation MUST
transmit an EAP packet with the Code field set to 4 (Failure). An
固有識別文字が同輩(1Requestsへの容認できないResponses)を認証できないなら、実装はCode分野セットで4(失敗)にEAPパケットを伝えなければなりません。 1
Blunk & Vollbrecht Standards Track [Page 7] RFC 2284 EAP March 1998
Blunk&Vollbrecht規格は1998年のEAP行進のときにRFC2284を追跡します[7ページ]。
authenticator MAY wish to issue multiple Requests before sending a
Failure response in order to allow for human typing mistakes.
人間のミスタイプを考慮するためにFailure応答を送る前に、固有識別文字は複数のRequestsを発行したがっているかもしれません。
Implementation Note: Because the Success and Failure packets
are not acknowledged, they may be potentially lost. A peer
MUST allow for this circumstance. The peer can use a Network
Protocol packet as an alternative indication of Success.
Likewise, the receipt of a LCP Terminate-Request can be taken
as a Failure.
実装注意: SuccessとFailureパケットが承認されないので、それらは潜在的に失われるかもしれません。 同輩はこの状況を考慮しなければなりません。 同輩はSuccessの代替のしるしとしてNetworkプロトコルパケットを使用できます。 同様に、FailureとしてLCP Terminate-要求の領収書をみなすことができます。
A summary of the Success and Failure packet format is shown below. The fields are transmitted from left to right.
SuccessとFailureパケット・フォーマットの概要は以下に示されます。 野原は左から右まで伝えられます。
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 | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
コード
3 for Success;
3 成功のために。
4 for Failure.
4 失敗のために。
Identifier
識別子
The Identifier field is one octet and aids in matching replies to
Responses. The Identifier field MUST match the Indentifier field
of the Response packet that it is sent in response to.
Identifier分野は、Responsesに回答に合うことにおいて1つの八重奏と援助です。 に対応してIdentifier分野がそれが送られるResponseパケットのIndentifier分野を合わせなければならない。
Length
長さ
4
4
3. Initial EAP Request/Response Types
3. 初期のEAP要求/応答タイプ
This section defines the initial set of EAP Types used in Request/Response exchanges. More Types may be defined in follow-on documents. The Type field is one octet and identifies the structure of an EAP Request or Response packet. The first 3 Types are considered special case Types. The remaining Types define authentication exchanges. The Nak Type is valid only for Response packets, it MUST NOT be sent in a Request. The Nak Type MUST only be
このセクションはRequest/応答交換に使用されるEAP Typesの始発を定義します。 より多くのTypesがフォローオンドキュメントで定義されるかもしれません。 Type分野は、1つの八重奏であり、EAP RequestかResponseパケットの構造を特定します。 最初の3Typesが特別なケースTypesであると考えられます。 残っているTypesは認証交換を定義します。 Responseパケットだけに、Nak Typeが有効である、Requestでそれを送ってはいけません。 Nak Typeがあるだけであるに違いありません。
Blunk & Vollbrecht Standards Track [Page 8] RFC 2284 EAP March 1998
Blunk&Vollbrecht規格は1998年のEAP行進のときにRFC2284を追跡します[8ページ]。
sent in repsonse to a Request which uses an authentication Type code. All EAP implementatins MUST support Types 1-4. These Types, as well as types 5 and 6, are defined in this document. Follow-on RFCs will define additional EAP Types.
認証Typeコードを使用するRequestにrepsonseを送りました。 すべてのEAP implementatinsが、Typesが1-4であるとサポートしなければなりません。 これらのTypes、およびタイプ5と6は本書では定義されます。 フォローオンRFCsは追加EAP Typesを定義するでしょう。
1 Identity
2 Notification
3 Nak (Response only)
4 MD5-Challenge
5 One-Time Password (OTP) (RFC 1938)
6 Generic Token Card
1 アイデンティティ2Notification3Nak(応答専用)4MD5-挑戦5One-時間Password(OTP)(RFC1938)6Generic Token Card
3.1. Identity
3.1. アイデンティティ
Description
記述
The Identity Type is used to query the identity of the peer.
Generally, the authenticator will issue this as the initial
Request. An optional displayable message MAY be included to
prompt the peer in the case where there expectation of interaction
with a user. A Response MUST be sent to this Request with a Type
of 1 (Identity).
Identity Typeは、同輩のアイデンティティについて質問するのに使用されます。 一般に、固有識別文字は初期のRequestとしてこれを発行するでしょう。 任意の「ディスプレイ-可能」メッセージは、場合における同輩のためにそこでどこをうながすかために含められるかもしれません。ユーザとの相互作用への期待。 1(アイデンティティ)のTypeと共にこのRequestにResponseを送らなければなりません。
Implementation Note: The peer MAY obtain the Identity via user
input. It is suggested that the authenticator retry the
Indentity Request in the case of an invalid Identity or
authentication failure to allow for potential typos on the part
of the user. It is suggested that the Identity Request be
retried a minimum of 3 times before terminating the
authentication phase with a Failure reply. The Notification
Request MAY be used to indicate an invalid authentication
attempt prior to transmitting a new Identity Request
(optionally, the failure MAY be indicated within the message of
the new Identity Request itself).
実装注意: 同輩はユーザ入力でIdentityを入手するかもしれません。 固有識別文字が無効のIdentityかユーザ側の潜在的誤植を考慮しない認証のことの場合でIndentity Requestを再試行することが提案されます。 Failure回答との認証フェーズを終える最低3回前にIdentity Requestが再試行されることが提案されます。 Notification Requestは、新しいIdentity Requestを伝える前に無効の認証試みを示すのに使用されるかもしれません(任意に、失敗は新しいIdentity Request自身に関するメッセージの中に示されるかもしれません)。
Type
タイプ
1
1
Type-Data
タイプデータ
This field MAY contain a displayable message in the Request. The
Response uses this field to return the Identity. If the Identity
is unknown, this field should be zero bytes in length. The field
MUST NOT be null terminated. The length of this field is derived
from the Length field of the Request/Response packet and hence a
null is not required.
この分野はRequestに「ディスプレイ-可能」メッセージを含むかもしれません。 Responseは、Identityを返すのにこの分野を使用します。 Identityが未知であるなら、長さはこの分野がバイトであるべきではありません。 分野は終えられた状態でヌルであるはずがありません。 Request/応答パケットのLength分野からこの分野の長さを得ます、そして、したがって、ヌルを必要としません。
Blunk & Vollbrecht Standards Track [Page 9] RFC 2284 EAP March 1998
Blunk&Vollbrecht規格は1998年のEAP行進のときにRFC2284を追跡します[9ページ]。
3.2. Notification
3.2. 通知
Description
記述
The Notification Type is optionally used to convey a displayable
message from the authenticator to the peer. The peer SHOULD
display this message to the user or log it if it cannot be
displayed. It is intended to provide an acknowledged notification
of some imperative nature. Examples include a password with an
expiration time that is about to expire, an OTP sequence integer
which is nearing 0, an authentication failure warning, etc. In
most circumstances, notification should not be required.
Notification Typeは、固有識別文字から同輩まで「ディスプレイ-可能」メッセージを伝えるのに任意に使用されます。 同輩SHOULDはこのメッセージをユーザに表示するか、またはそれを表示できないなら、それを登録します。 何らかの必須の自然の承認された通知を提供するのは意図しています。 例は期限が切れようとしている満了時間、0に近づいているOTP系列整数、認証失敗警告などがあるパスワードを含んでいます。 ほとんどの事情では、通知を必要とするべきではありません。
Type
タイプ
2
2
Type-Data
タイプデータ
The Type-Data field in the Request contains a displayable message
greater than zero octets in length. The length of the message is
determined by Length field of the Request packet. The message
MUST not be null terminated. A Response MUST be sent in reply to
the Request with a Type field of 2 (Notification). The Type-Data
field of the Response is zero octets in length. The Response
should be sent immediately (independent of how the message is
displayed or logged).
RequestのType-データ・フィールドは長さにおける八重奏がないよりすばらしい「ディスプレイ-可能」メッセージを含んでいます。 メッセージの長さはRequestパケットのLength分野のそばで決定しています。 メッセージは終えられた状態でヌルであるはずがありません。 2(通知)のType分野があるRequestに対してResponseを送らなければなりません。 ResponseのType-データ・フィールドは長さが八重奏ではありません。 すぐに(メッセージを表示するか、またはどう登録するかの如何にかかわらず)、Responseを送るべきです。
3.3. Nak
3.3. Nak
Description
記述
The Nak Type is valid only in Response messages. It is sent in
reply to a Request where the desired authentication Type is
unacceptable. Authentication Types are numbered 4 and above.
The Response contains the authentication Type desired by the peer.
Nak TypeはResponseメッセージだけで有効です。 必要な認証Typeが容認できないRequestに対してそれを送ります。 認証Typesは番号付の4以上です。 Responseは同輩によって望まれていた認証Typeを含んでいます。
Type
タイプ
3
3
Type-Data
タイプデータ
This field MUST contain a single octet indicating the desired
authentication type.
この分野は必要な認証タイプを示すただ一つの八重奏を含まなければなりません。
Blunk & Vollbrecht Standards Track [Page 10] RFC 2284 EAP March 1998
Blunk&Vollbrecht規格は1998年のEAP行進のときにRFC2284を追跡します[10ページ]。
3.4. MD5-Challenge
3.4. MD5-挑戦
Description
記述
The MD5-Challenge Type is analagous to the PPP CHAP protocol [3]
(with MD5 as the specified algorithm). The PPP Challenge
Handshake Authentication Protocol RFC [3] should be referred to
for further implementation specifics. The Request contains a
"challenge" message to the peer. A Repsonse MUST be sent in reply
to the Request. The Response MAY be either of Type 4 (MD5-
Challenge) or Type 3 (Nak). The Nak reply indicates the peer's
desired authentication mechanism Type. All EAP implementations
MUST support the MD5-Challenge mechanism.
MD5-挑戦TypeはPPP CHAPプロトコル[3](指定されたアルゴリズムとしてのMD5と)へのanalagousです。 PPPチャレンジハンドシェイク式認証プロトコルRFC[3]はさらなる実装詳細について言及されるべきです。 Requestは「挑戦」メッセージを同輩に含んでいます。 Requestに対してRepsonseを送らなければなりません。 ResponseはType4(MD5挑戦)かType3(Nak)のものであるかもしれません。 Nak回答は同輩の必要な認証機構Typeを示します。 すべてのEAP実装がMD5-挑戦メカニズムをサポートしなければなりません。
Type
タイプ
4
4
Type-Data
タイプデータ
The contents of the Type-Data field is summarized below. For
reference on the use of this fields see the PPP Challenge
Handshake Authentication Protocol [3].
Type-データ・フィールドのコンテンツは以下へまとめられます。 この分野の使用に関する参照に関しては、PPPチャレンジハンドシェイク式認証プロトコル[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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value-Size | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 値サイズ| 値… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 命名します。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.5. One-Time Password (OTP)
3.5. ワンタイムパスワード(OTP)
Description
記述
The One-Time Password system is defined in "A One-Time Password
System" [4]. The Request contains a displayable message
containing an OTP challenge. A Repsonse MUST be sent in reply to
the Request. The Response MUST be of Type 5 (OTP) or Type 3
(Nak). The Nak reply indicates the peer's desired authentication
mechanism Type.
One-時間Passwordシステムは「A One-時間パスワードシステム」[4]で定義されます。 RequestはOTP挑戦を含む「ディスプレイ-可能」メッセージを含んでいます。 Requestに対してRepsonseを送らなければなりません。 ResponseはType5(OTP)かType3(Nak)のものであるに違いありません。 Nak回答は同輩の必要な認証機構Typeを示します。
Type
タイプ
5
5
Blunk & Vollbrecht Standards Track [Page 11] RFC 2284 EAP March 1998
Blunk&Vollbrecht規格は1998年のEAP行進のときにRFC2284を追跡します[11ページ]。
Type-Data
タイプデータ
The Type-Data field contains the OTP "challenge" as a displayable
message in the Request. In the Response, this field is used for
the 6 words from the OTP dictionary [4]. The messages MUST not be
null terminated. The length of the field is derived from the
Length field of the Request/Reply packet.
Type-データ・フィールドはRequestの「ディスプレイ-可能」メッセージとしてOTP「挑戦」を含んでいます。 Responseでは、この分野はOTP辞書[4]からの6つの単語に使用されます。 メッセージは終えられた状態でヌルであるはずがありません。 Request/回答パケットのLength分野から分野の長さを得ます。
3.6. Generic Token Card
3.6. ジェネリックトークン・カード
Description
記述
The Generic Token Card Type is defined for use with various Token
Card implementations which require user input. The Request
contains an ASCII text message and the Reply contains the Token
Card information necessary for authentication. Typically, this
would be information read by a user from the Token card device and
entered as ASCII text.
Generic Token Card Typeは使用のためにユーザ入力を必要とする様々なToken Card実装で定義されます。 RequestはASCIIテキストメッセージを含んでいます、そして、Replyは認証に必要なToken Card情報を含んでいます。 これは通常、ユーザによってTokenカードデバイスから読まれて、ASCIIテキストとして入力された情報でしょう。
Type
タイプ
6
6
Type-Data
タイプデータ
The Type-Data field in the Request contains a displayable message
greater than zero octets in length. The length of the message is
determined by Length field of the Request packet. The message
MUST not be null terminated. A Response MUST be sent in reply to
the Request with a Type field of 6 (Generic Token Card). The
Response contains data from the Token Card required for
authentication. The length is of the data is determined by the
Length field of the Response packet.
RequestのType-データ・フィールドは長さにおける八重奏がないよりすばらしい「ディスプレイ-可能」メッセージを含んでいます。 メッセージの長さはRequestパケットのLength分野のそばで決定しています。 メッセージは終えられた状態でヌルであるはずがありません。 6(ジェネリックToken Card)のType分野があるRequestに対してResponseを送らなければなりません。 Responseは認証に必要であるToken Cardからのデータを含んでいます。 長さはデータのそうです。ResponseパケットのLength分野で、決定します。
Security Considerations
セキュリティ問題
Security issues are the primary topic of this RFC.
安全保障問題はこのRFCのプライマリ話題です。
The interaction of the authentication protocols within PPP are highly implementation dependent.
PPPの中の認証プロトコルの相互作用は実装に非常に依存しています。
For example, upon failure of authentication, some implementations do not terminate the link. Instead, the implementation limits the kind of traffic in the Network-Layer Protocols to a filtered subset, which in turn allows the user opportunity to update secrets or send mail to the network administrator indicating a problem.
例えば、認証の失敗では、いくつかの実装はリンクを終えません。 代わりに、実装はNetwork-層のプロトコルのトラフィックの種類をフィルターにかけることの部分集合に制限します。(順番に、それは、問題を示すネットワーク管理者に秘密をアップデートするか、またはメールを送るユーザの機会を許容します)。
Blunk & Vollbrecht Standards Track [Page 12] RFC 2284 EAP March 1998
Blunk&Vollbrecht規格は1998年のEAP行進のときにRFC2284を追跡します[12ページ]。
There is no provision for retries of failed authentication. However, the LCP state machine can renegotiate the authentication protocol at any time, thus allowing a new attempt. It is recommended that any counters used for authentication failure not be reset until after successful authentication, or subsequent termination of the failed link.
失敗した認証の再試行への支給が全くありません。 しかしながら、LCP州のマシンはいつでも、認証プロトコルを再交渉して、その結果、新しい試みを許すことができます。 認証失敗に使用されるどんなカウンタもうまくいっている認証の後のリセット、または失敗したリンクのその後の終了でないことがお勧めです。
There is no requirement that authentication be full duplex or that the same protocol be used in both directions. It is perfectly acceptable for different protocols to be used in each direction. This will, of course, depend on the specific protocols negotiated.
認証が全二重であるか同じプロトコルが両方の方向に使用されるという要件が全くありません。 異なったプロトコルが各方向に使用されるのは、完全に許容できます。 これはもちろん交渉された特定のプロトコルによるでしょう。
In practice, within or associated with each PPP server, it is not anticipated that a particular named user would be authenticated by multiple methods. This would make the user vulnerable to attacks which negotiate the least secure method from among a set (such as PAP rather than EAP). Instead, for each named user there should be an indication of exactly one method used to authenticate that user name. If a user needs to make use of different authentication methods under different circumstances, then distinct identities SHOULD be employed, each of which identifies exactly one authentication method.
中では、中で練習してください。さもないと、それぞれのPPPサーバに関連していて、特定の名前付のユーザが複数のメソッドで認証されると予期されません。 これで、ユーザはセット(EAPよりむしろPAPなどの)から最も安全でないメソッドを交渉する攻撃に被害を受け易くなるでしょう。 代わりに、それぞれの命名されたユーザのために、まさにそのユーザ名を認証するのに使用される1つのメソッドのしるしがあるべきです。 ユーザが、異なった認証方法を利用する必要があるなら、どれがまさに1つの認証方法を特定するかについて異なった事情の、そして、次に、異なったアイデンティティSHOULDの下でそれぞれ使われてください。
References
参照
[1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[1] シンプソン、W.、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月。
[2] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, October 1994.
[2] レイノルズとJ.とJ.ポステル、「規定番号」、STD2、RFC1700、1994年10月。
[3] Simpson, W., "PPP Challenge Handshake Authentication Protocol
(CHAP)", RFC 1994, August 1996.
[3] シンプソン、W.、「pppチャレンジハンドシェイク式認証プロトコル(やつ)」、RFC1994、1996年8月。
[4] Haller, N. and C. Metz, "A One-Time Password System", RFC 1938,
May 1996.
[4] ハラー、N.、およびC.メス(「A One-時間パスワードシステム」、RFC1938)は1996がそうするかもしれません。
[5] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO
10646", RFC 2044, October 1996.
[5]Yergeau、1996年10月のF.、「UTF-8、ユニコードとISO10646の変換形式」RFC2044。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[6] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、RFC2119、1997年3月。
Blunk & Vollbrecht Standards Track [Page 13] RFC 2284 EAP March 1998
Blunk&Vollbrecht規格は1998年のEAP行進のときにRFC2284を追跡します[13ページ]。
Acknowledgments
承認
This protocol derives much of its inspiration from Dave Carrel's AHA draft as well as the PPP CHAP protocol [3]. Bill Simpson provided much of the boilerplate used throughout this document. Al Rubens (Merit) also provided valuable feedback.
このプロトコルがインスピレーションの多くにPPP CHAPプロトコル[3]と同様にデーヴCarrelのAHA草稿に由来しています。 ビル・シンプソンはこのドキュメント中で使用される決まり文句の多くを提供しました。 また、アル・ルーベン(長所)は有益なフィードバックを提供しました。
Chair's Address
議長のアドレス
The working group can be contacted via the current chair:
現在のいすを通してワーキンググループに連絡できます:
Karl F. Fox Ascend Communications, Inc. 655 Metro Place South, Suite 370 Dublin, Ohio 43017
カールF.フォックスは南部のInc.655地下鉄場所、ダブリン、コミュニケーションSuite370オハイオ 43017を昇ります。
EMail: karl@ascend.com Phone: +1 614 760 4041 Fax: +1 614 760 4050
メール: karl@ascend.com 電話: +1 614 760、4041Fax: +1 614 760 4050
Authors' Addresses
作者のアドレス
Larry J. Blunk Merit Network, Inc. 4251 Plymouth Rd., Suite C Ann Arbor, MI 48105
ラリーJ.Blunk長所ネットワークInc.4251プリマス通り、スイートCアナーバー、MI 48105
EMail: ljb@merit.edu Phone: 734-763-6056 FAX: 734-647-3185
メール: ljb@merit.edu 電話: 734-763-6056 Fax: 734-647-3185
John R. Vollbrecht Merit Network, Inc. 4251 Plymouth Rd., Suite C Ann Arbor, MI 48105
ジョンR.Vollbrecht長所ネットワークInc.4251プリマス通り、スイートCアナーバー、MI 48105
EMail: jrv@merit.edu Phone: +1-313-763-1206 FAX: +1-734-647-3185
メール: jrv@merit.edu 電話: +1-313-763-1206 Fax: +1-734-647-3185
Blunk & Vollbrecht Standards Track [Page 14] RFC 2284 EAP March 1998
Blunk&Vollbrecht規格は1998年のEAP行進のときにRFC2284を追跡します[14ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Blunk & Vollbrecht Standards Track [Page 15]
Blunk&Vollbrecht標準化過程[15ページ]
一覧
スポンサーリンク
