RFC3748

http://tools.ietf.org/html/rfc3748
Section 1、2、4、5、Appendix A

Network Working Group B. Aboba
Request for Comments: 3748 Microsoft
Obsoletes: 2284 L. Blunk
Category: Standards Track Merit Network, Inc
J. Vollbrecht
Vollbrecht Consulting LLC
J. Carlson
Sun
H. Levkowetz, Ed.
ipUnplugged
June 2004

Extensible Authentication Protocol (EAP)

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の最新版を参照してください。
このメモの配布には制限がない。

Abstract
概要

This document obsoletes RFC 2284. A summary of the changes between
this document and RFC 2284 is available in Appendix A.
RFC2284との変更の概要はAppendix Aにある。
RFC 2284を廃止する。

Aboba, et al. Standards Track [Page 1]

RFC 3748 EAP June 2004

Table of Contents

1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
導入
1.1. Specification of Requirements . . . . . . . . . . . . . 4
要求仕様
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . 4
用語
1.3. Applicability . . . . . . . . . . . . . . . . . . . . . 6
適用性
2. Extensible Authentication Protocol (EAP). . . . . . . . . . . 7
Extensible Authentication Protocol (EAP)
2.1. Support for Sequences . . . . . . . . . . . . . . . . . 9
サポートするシーケンス
2.2. EAP Multiplexing Model. . . . . . . . . . . . . . . . . 10
EAP Multiplexing Model.
2.3. Pass-Through Behavior . . . . . . . . . . . . . . . . . 12
Pass-Throughの動作
2.4. Peer-to-Peer Operation. . . . . . . . . . . . . . . . . 14
Peer-to-Peerの動作
3. Lower Layer Behavior. . . . . . . . . . . . . . . . . . . . . 15
低レイヤの動作
3.1. Lower Layer Requirements. . . . . . . . . . . . . . . . 15
低レイヤへの要求事項
3.2. EAP Usage Within PPP. . . . . . . . . . . . . . . . . . 18
PPPでのEAP
3.2.1. PPP Configuration Option Format. . . . . . . . . 18
PPP Configuration Option Format
3.3. EAP Usage Within IEEE 802 . . . . . . . . . . . . . . . 19
IEEE 802でのEAP
3.4. Lower Layer Indications . . . . . . . . . . . . . . . . 19
Lower Layer Indications
4. EAP Packet Format . . . . . . . . . . . . . . . . . . . . . . 20
EAPのパケットフォーマット
4.1. Request and Response. . . . . . . . . . . . . . . . . . 21
RequestとResponse
4.2. Success and Failure . . . . . . . . . . . . . . . . . . 23
SuccessとFailue
4.3. Retransmission Behavior . . . . . . . . . . . . . . . . 26
再送動作
5. Initial EAP Request/Response Types. . . . . . . . . . . . . . 27
5.1. Identity. . . . . . . . . . . . . . . . . . . . . . . . 28
5.2. Notification. . . . . . . . . . . . . . . . . . . . . . 29
5.3. Nak . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.3.1. Legacy Nak . . . . . . . . . . . . . . . . . . . 31
5.3.2. Expanded Nak . . . . . . . . . . . . . . . . . . 32
5.4. MD5-Challenge . . . . . . . . . . . . . . . . . . . . . 35
5.5. One-Time Password (OTP) . . . . . . . . . . . . . . . . 36
5.6. Generic Token Card (GTC). . . . . . . . . . . . . . . . 37
5.7. Expanded Types. . . . . . . . . . . . . . . . . . . . . 38
5.8. Experimental. . . . . . . . . . . . . . . . . . . . . . 40
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
6.1. Packet Codes. . . . . . . . . . . . . . . . . . . . . . 41
6.2. Method Types. . . . . . . . . . . . . . . . . . . . . . 41
7. Security Considerations . . . . . . . . . . . . . . . . . . . 42
7.1. Threat Model. . . . . . . . . . . . . . . . . . . . . . 42
7.2. Security Claims . . . . . . . . . . . . . . . . . . . . 43
7.2.1. Security Claims Terminology for EAP Methods. . . 44
7.3. Identity Protection . . . . . . . . . . . . . . . . . . 46
7.4. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . 47
7.5. Packet Modification Attacks . . . . . . . . . . . . . . 48
7.6. Dictionary Attacks. . . . . . . . . . . . . . . . . . . 49
7.7. Connection to an Untrusted Network. . . . . . . . . . . 49
7.8. Negotiation Attacks . . . . . . . . . . . . . . . . . . 50
7.9. Implementation Idiosyncrasies . . . . . . . . . . . . . 50
7.10. Key Derivation. . . . . . . . . . . . . . . . . . . . . 51
7.11. Weak Ciphersuites . . . . . . . . . . . . . . . . . . . 53

Aboba, et al. Standards Track [Page 2]

RFC 3748 EAP June 2004

7.12. Link Layer. . . . . . . . . . . . . . . . . . . . . . . 53
7.13. Separation of Authenticator and Backend Authentication
Server. . . . . . . . . . . . . . . . . . . . . . . . . 54
7.14. Cleartext Passwords . . . . . . . . . . . . . . . . . . 55
7.15. Channel Binding . . . . . . . . . . . . . . . . . . . . 55
7.16. Protected Result Indications. . . . . . . . . . . . . . 56
8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 58
9. References. . . . . . . . . . . . . . . . . . . . . . . . . . 59
9.1. Normative References. . . . . . . . . . . . . . . . . . 59
9.2. Informative References. . . . . . . . . . . . . . . . . 60
Appendix A. Changes from RFC 2284. . . . . . . . . . . . . . . . . 64
RFC2284からの変更履歴
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 67

1. Introduction
導入

This document defines the Extensible Authentication Protocol (EAP),
an authentication framework which supports multiple authentication
methods. EAP typically runs directly over data link layers such as
Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP
provides its own support for duplicate elimination and
retransmission, but is reliant on lower layer ordering guarantees.
Fragmentation is not supported within EAP itself; however, individual
EAP methods may support this.
複数の認証方式をサポートする認証のフレームワーク、Extensible Authentication Protocol(EAP)を定義する。
EAPはIPを必要とせず、PPPやIEEE 802のようなデータリンクレイヤで直接動作する。
EAPは重複排除、再送を提供するが、それは下位レイヤ保証に頼っている。
FragmentationはEAPではサポートされないが、個別のEAP methodではサポートしてもよい。

EAP may be used on dedicated links, as well as switched circuits, and
wired as well as wireless links. To date, EAP has been implemented
with hosts and routers that connect via switched circuits or dial-up
lines using PPP [RFC1661]. It has also been implemented with
switches and access points using IEEE 802 [IEEE-802]. EAP
encapsulation on IEEE 802 wired media is described in [IEEE-802.1X],
and encapsulation on IEEE wireless LANs in [IEEE-802.11i].
EAPは専用線、回線交換、有線、無線で使用してよい。
EAPは回線交換 or ダイヤルアップを経由してPPPを使用して接続したルーターとホストに実装されている。
IEEE802を使用したスイッチとAPにも実装されている。
IEE802有線でのEAPカプセル化は[IEEE-802.1X]、無線LANのカプセル化は[IEEE-802.11i]で説明されている。

One of the advantages of the EAP architecture is its flexibility.
EAP is used to select a specific authentication mechanism, typically
after the authenticator requests more information in order to
determine the specific authentication method to be used. Rather than
requiring the authenticator to be updated to support each new
authentication method, EAP permits the use of a backend
authentication server, which may implement some or all authentication
methods, with the authenticator acting as a pass-through for some or
all methods and peers.
EAPアーキテクチャの利点の一つは柔軟性である。
EAPは認証方式を選択するために使用され、EAP authenticatorは認証方式を決定するため情報を要求する。
新しい認証方式をサポートするたびに更新されるauthentiatorではなく、EAPでは各種認証方式をサポートしたバックエンド認証サーバとして使用を可能とし、authenticatorはmethonとpeerのpass-throughとして動作する。

Within this document, authenticator requirements apply regardless of
whether the authenticator is operating as a pass-through or not.
Where the requirement is meant to apply to either the authenticator
or backend authentication server, depending on where the EAP
authentication is terminated, the term "EAP server" will be used.
このドキュメントではauthenticatorの要求事項がauthenticatorがpass-throughとして動作しているかどうかに関わらず適用される。
要求事項がEAP認証の終端される場所によって、バックエンドのauthentication serverかauthenticatorに適用される意図の場合、EAP serverという用語が使用される。

Aboba, et al. Standards Track [Page 3]

RFC 3748 EAP June 2004

1.1. Specification of Requirements

In this document, several words are used to signify the requirements
of the specification. 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
[RFC2119].
このドキュメントのキーワード"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"はRFC2119で説明されるように解釈されること。

1.2. Terminology
用語
This document frequently uses the following terms:
下記の用語をよく使う。

authenticator
The end of the link initiating EAP authentication. The term
authenticator is used in [IEEE-802.1X], and has the same meaning
in this document.
EAP認証を開始するリンクの終端。[IEEE-802.1X]のauthentiatorと同じ意味。
SeGW、APの役割。（コメント※）

peer
The end of the link that responds to the authenticator. In
[IEEE-802.1X], this end is known as the Supplicant.
authenticatorに応答するリンクの終端。
[IEEE-802.1X]のサプリカント。

Supplicant
The end of the link that responds to the authenticator in [IEEE-
802.1X]. In this document, this end of the link is called the
peer.
[IEEE-802.1X]におけるauthenticatorへ応答するリンクの終端。
このドキュメントのpeer。

backend authentication server
A backend authentication server is an entity that provides an
authentication service to an authenticator. When used, this
server typically executes EAP methods for the authenticator. This
terminology is also used in [IEEE-802.1X].
バックエンド認証サーバはauthenticatorに認証サービスを提供するエンティティ。
authenticatorのためにEAPメソッドを実行する。[IEEE-802.1X]でも使用される。

AAA
Authentication, Authorization, and Accounting. AAA protocols with
EAP support include RADIUS [RFC3579] and Diameter [DIAM-EAP]. In
this document, the terms "AAA server" and "backend authentication
server" are used interchangeably.
認証、認可、課金。
EAPがサポートするAAAプロトコルはRADIUS、Diameterを含む。
RADIUS：半径、Diameter：直径でDiameterはRADIUSの進化版。SCTP、TCPにも対応している。

Displayable Message
This is interpreted to be a human readable string of characters.
The message encoding MUST follow the UTF-8 transformation format
[RFC2279].
人間が読める形式の文字列。
このメッセージはUTF-8形式であること。

Aboba, et al. Standards Track [Page 4]

RFC 3748 EAP June 2004

EAP server
The entity that terminates the EAP authentication method with the
peer. In the case where no backend authentication server is used,
the EAP server is part of the authenticator. In the case where
the authenticator operates in pass-through mode, the EAP server is
located on the backend authentication server.
peerとのEAP認証方式を終端するエンティティ。
バックエンド認証サーバを使用しない場合、EAP serverはauthenticatorの一部である。
authenticatorがpass-throughで動作する場合、EAP serverはバックエンド認証サーバである。

Silently Discard
This means the implementation discards the packet without further
processing. The implementation SHOULD provide the capability of
logging the event, including the contents of the silently
discarded packet, and SHOULD record the event in a statistics
counter.
後継処理をせずにパケットを破棄する実装を意味する。
実装はSilently Discard packetのイベントをログに記録する機能と統計情報(カウンタ)に記録する機能を提供すること。

Successful Authentication
In the context of this document, "successful authentication" is an
exchange of EAP messages, as a result of which the authenticator
decides to allow access by the peer, and the peer decides to use
this access. The authenticator's decision typically involves both
authentication and authorization aspects; the peer may
successfully authenticate to the authenticator, but access may be
denied by the authenticator due to policy reasons.
EAPメッセージの交換によりauthenticatorがpeerにアクセスを許可し、peerはアクセスを使用すること。
authenticatorの決定は、認証と認可の両方を含む。authenticatorはpeerに認証を成功させてもポリシー上の理由からアクセスを拒否してもよい。

Message Integrity Check (MIC)
A keyed hash function used for authentication and integrity
protection of data. This is usually called a Message
Authentication Code (MAC), but IEEE 802 specifications (and this
document) use the acronym MIC to avoid confusion with Medium
Access Control.
データの完全性保証と認証のために使用される鍵付きハッシュ関数。
Message Authentication Code(MAC)と呼ばれるが、Media Access Controlとの混同を避けるため、MICを使用する。
※鍵付きハッシュ関数：共通鍵を追加してハッシュ計算する。

Cryptographic Separation
Two keys (x and y) are "cryptographically separate" if an
adversary that knows all messages exchanged in the protocol cannot
compute x from y or y from x without "breaking" some cryptographic
assumption. In particular, this definition allows that the
adversary has the knowledge of all nonces sent in cleartext, as
well as all predictable counter values used in the protocol.
Breaking a cryptographic assumption would typically require
inverting a one-way function or predicting the outcome of a
cryptographic pseudo-random number generator without knowledge of
the secret state. In other words, if the keys are
cryptographically separate, there is no shortcut to compute x from
y or y from x, but the work an adversary must do to perform this
computation is equivalent to performing an exhaustive search for
the secret state value.
2つのキー(x and y)がすべてのメッセージを知っている攻撃者が暗号の仮定を破ることなくxからy、yからxを計算できない場合、暗号的に独立している。メッセージには平文で送られたnonce(ノンス)やすべてのカウンタも含まれる。暗号の仮定を破るとは、一方向関数を逆算出することや擬似乱数生成器の結果を予測することである。
Cryptographically separateを言い換えると、xからy、yからxを計算するショートカットはなく、攻撃者がかなりの量の計算を必要とすることである。

Aboba, et al. Standards Track [Page 5]

RFC 3748 EAP June 2004

Master Session Key (MSK)
Keying material that is derived between the EAP peer and server
and exported by the EAP method. The MSK is at least 64 octets in
length. In existing implementations, a AAA server acting as an
EAP server transports the MSK to the authenticator.
EAP peerとEAP serverとの間で導出され、EAP methodにより転送されるキー要素。
MSKは64オクテット以上である。
既存の実装では、EAP serverとして動作するAAA serverはauthenticatorにMSKを転送する。

Extended Master Session Key (EMSK)
Additional keying material derived between the EAP client and
server that is exported by the EAP method. The EMSK is at least
64 octets in length. The EMSK is not shared with the
authenticator or any other third party. The EMSK is reserved for
future uses that are not defined yet.
EAP clientとEAP serverとの間で導出され、EAP methodにより転送され追加のキー要素。
EMSKは64オクテット以上である。
EMSKはauthenticatorおよび第三者と共有されない。EMSKは今後の使用のためにreserveされていて、定義はまだされていない。

Result indications
A method provides result indications if after the method's last
message is sent and received:
methodの最後のメッセージが送受信された後、結果通知を提供するmethod。

1) The peer is aware of whether it has authenticated the server,
as well as whether the server has authenticated it.
peerがserverの認証を認識したかだけではなく、serverがpeerを認証したかどうか。

2) The server is aware of whether it has authenticated the peer,
as well as whether the peer has authenticated it.
serverがpeerの認証を認識したかだけではなく、peerがserverを認証したかどうか。

In the case where successful authentication is sufficient to
authorize access, then the peer and authenticator will also know if
the other party is willing to provide or accept access. This may not
always be the case. An authenticated peer may be denied access due
to lack of authorization (e.g., session limit) or other reasons.
Since the EAP exchange is run between the peer and the server, other
nodes (such as AAA proxies) may also affect the authorization
decision. This is discussed in more detail in Section 7.16.
認証に成功し、アクセス可能であることはpeerとauthenticatorがそれぞれ知っている。ただし、常にそうではない。認証されたpeerがアクセス権がない場合(セッション制限)などがある。
EAP認証がpeerとサーバ間で実施するため、他のノード(AAA proxies等)が認証の決定に影響を与える可能性がある。これについてはSection 7.16で述べる。

1.3. Applicability
適用性

EAP was designed for use in network access authentication, where IP
layer connectivity may not be available. Use of EAP for other
purposes, such as bulk data transport, is NOT RECOMMENDED.
EAPはIPレイヤ接続が利用不可の場合でもネットワークアクセス認証が使用できるように設計された。
EAPを大量のデータ転送のような目的に使用することは推奨しない。

Since EAP does not require IP connectivity, it provides just enough
support for the reliable transport of authentication protocols, and
no more.
EAPはIP接続を必要としないので認証プロトコルに必要なだけの信頼性転送を提供する。

EAP is a lock-step protocol which only supports a single packet in
flight. As a result, EAP cannot efficiently transport bulk data,
unlike transport protocols such as TCP [RFC793] or SCTP [RFC2960].
EAPは1パケット送信のみをサポートするロックステッププロトコルである。
1パケットずつ送信する。
そのためEAPはTCPやSCTPのようなトランスポートプロトコルと異なり、大量のデータ転送を効率的に転送することができない。

Aboba, et al. Standards Track [Page 6]

RFC 3748 EAP June 2004

While EAP provides support for retransmission, it assumes ordering
guarantees provided by the lower layer, so out of order reception is
not supported.
EAPは再送をサポートしているが、下位レイヤの順序保証を前提とする。そのため非順序の受信はサポートしない。

Since EAP does not support fragmentation and reassembly, EAP
authentication methods generating payloads larger than the minimum
EAP MTU need to provide fragmentation support.
EAPはfragmentationとreassemblyをサポートしないため、最小のEAP MTUより大きいペイロードを生成するEAP認証メソッドはfragmentationをサポートする必要がある。

While authentication methods such as EAP-TLS [RFC2716] provide
support for fragmentation and reassembly, the EAP methods defined in
this document do not. As a result, if the EAP packet size exceeds
the EAP MTU of the link, these methods will encounter difficulties.
EAP-TLSのような認証方式は、fragmentationとreassemblyをサポートするが、本ドキュメントで定義するEAPメソッドではサポートしない。
EAPパケットサイズがEAP MTUを超えた場合、難しいことになる。

EAP authentication is initiated by the server (authenticator),
whereas many authentication protocols are initiated by the client
(peer). As a result, it may be necessary for an authentication
algorithm to add one or two additional messages (at most one
roundtrip) in order to run over EAP.
多くの認証プロトコルがクライアント(peer)から開始されるのに対し、EAP認証はサーバー(authenticator)から開始される。結果、EAPでは1 or 2の追加メッセージが必要になる。(1回以上の往復が必要)

Where certificate-based authentication is supported, the number of
additional roundtrips may be much larger due to fragmentation of
certificate chains. In general, a fragmented EAP packet will require
as many round-trips to send as there are fragments. For example, a
certificate chain 14960 octets in size would require ten round-trips
to send with a 1496 octet EAP MTU.
証明書ベースの認証がサポートされる場合、証明書のfragmentationにより往復回数が多くなる。
fragmentationされたEAPパケットは多くの往復回数を要求する。
例えば、1,469オクテットのEAP MTUで14,960オクテットの証明書を送信するために10往復必要になる。

Where EAP runs over a lower layer in which significant packet loss is
experienced, or where the connection between the authenticator and
authentication server experiences significant packet loss, EAP
methods requiring many round-trips can experience difficulties. In
these situations, use of EAP methods with fewer roundtrips is
advisable.
パケロスが多い場合は往復回数の少ないEAPメソッドの使用を推奨する。

2. Extensible Authentication Protocol (EAP)

The EAP authentication exchange proceeds as follows:
以下のようにEAPプロトコルは実行する。

[1] The authenticator sends a Request to authenticate the peer. The
Request has a Type field to indicate what is being requested.
Examples of Request Types include Identity, MD5-challenge, etc.
The MD5-challenge Type corresponds closely to the CHAP
authentication protocol [RFC1994]. Typically, the authenticator
will send an initial Identity Request; however, an initial
Identity Request is not required, and MAY be bypassed. For
example, the identity may not be required where it is determined
by the port to which the peer has connected (leased lines,

Aboba, et al. Standards Track [Page 7]

RFC 3748 EAP June 2004

dedicated switch or dial-up ports), or where the identity is
obtained in another fashion (via calling station identity or MAC
address, in the Name field of the MD5-Challenge Response, etc.).
[1]
authenticatorはpeerを認証するためのRequestを送信する。
RequestはRequestを示すためのType filedをもつ。
Request Typeは例えばIdentity、MD5-challengeなどを含む。
MD5-challenge TypeはCHAP認証プロトコル[RC1994]に関係している。
一般的にauthenticatorはinitial Identity Requestを送信するが、initial Identity Requestは必要ではなく、無視(bypass)してよい。
例えば、Identityはpeerが接続したポート(専用線、ダイヤルアップポート)によって決定されたり、Identityが他の方法(MACアドレス、MD5-Challenge ResponseのName field等)で得られた場合は不要になる。

[2] The peer sends a Response packet in reply to a valid Request. As
with the Request packet, the Response packet contains a Type
field, which corresponds to the Type field of the Request.
peerはRequestに対してResponseパケットを送信する。
[2]
Requestパケットを同様に、ReponseパケットはRequestのType filedに対応するType filedを含む。

[3] The authenticator sends an additional Request packet, and the
peer replies with a Response. The sequence of Requests and
Responses continues as long as needed. EAP is a 'lock step'
protocol, so that other than the initial Request, a new Request
cannot be sent prior to receiving a valid Response. The
authenticator is responsible for retransmitting requests as
described in Section 4.1. After a suitable number of
retransmissions, the authenticator SHOULD end the EAP
conversation. The authenticator MUST NOT send a Success or
Failure packet when retransmitting or when it fails to get a
response from the peer.
[3]
authenticatorは追加のRequestパケットを送信し、peerはResponseで応答する。
Request-Responseのシーケンスは必要なだけ続く。
EAPはlock stepプロトコルなので、Initial Request以外には新しいRequestはRespose受信前に送信することができない。
authenticatorはSection 4.1のとおり、Requestを再送する責任がある。
適当な回数再送した後、authenticatorはEAPを終了すること。
authenticatorは再送した場合 or peerからResponseを取得できなかった場合にSuccess or Failure packetをpeerに送らないこと。

[4] The conversation continues until the authenticator cannot
authenticate the peer (unacceptable Responses to one or more
Requests), in which case the authenticator implementation MUST
transmit an EAP Failure (Code 4). Alternatively, the
authentication conversation can continue until the authenticator
determines that successful authentication has occurred, in which
case the authenticator MUST transmit an EAP Success (Code 3).
[4]
この処理はauthenticatorがpeerの認証に失敗(Requestに対する不適当なResponse)し、authenticatorがEAP Failure(Code 4)を送信するまで続く。
または、authenticatorが認証の成功と判断し、authenticatorがEAP Success(Code 3)を送信するまで続く。

Advantages:
利点

o The EAP protocol can support multiple authentication mechanisms
without having to pre-negotiate a particular one.
EAPは事前のネゴシエーション無しに複数の認証メカニズムをサポートできる。

o Network Access Server (NAS) devices (e.g., a switch or access
point) do not have to understand each authentication method and
MAY act as a pass-through agent for a backend authentication
server. Support for pass-through is optional. An authenticator
MAY authenticate local peers, while at the same time acting as a
pass-through for non-local peers and authentication methods it
does not implement locally.
Network Access Server(NAS)(スイッチ、アクセスポイント)は認証方式を認識する必要はなく、バックエンド認証サーバーのためのpass-throughエージェントそして機能してよい。pass-throughのサポートはオプションである。
authenticatorはローカル認証とpass-throghの認証を同時に実行できる。

o Separation of the authenticator from the backend authentication
server simplifies credentials management and policy decision
making.
authenticatorとバックエンド認証サーバーとの分離は認証情報の管理とポリシーの決定を簡素化できる。

Aboba, et al. Standards Track [Page 8]

RFC 3748 EAP June 2004

Disadvantages:
欠点

o For use in PPP, EAP requires the addition of a new authentication
Type to PPP 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. Similarly, switch or access point
implementations need to support [IEEE-802.1X] in order to use EAP.
PPPで使用するためにPPP LCPに新しい認証タイプの追加が必要となる。（PPP LCPはPPPのリンク制御用プロトコル、PPP NCPはレイヤ3設定用）。
スイッチ or アクセスポイントでEAPを使う場合、IEEE-802.1Xが必要になる。（MACフレームをRADIUSフレームに入れ替えたりする）

o Where the authenticator is separate from the backend
authentication server, this complicates the security analysis and,
if needed, key distribution.
authenticatorとバックエンド認証サーバとの分離はセキュリティ分析とキー管理が複雑になる。

2.1. Support for Sequences
サポートするシーケンス

An EAP conversation MAY utilize a sequence of methods. A common
example of this is an Identity request followed by a single EAP
authentication method such as an MD5-Challenge. However, the peer
and authenticator MUST utilize only one authentication method (Type 4
or greater) within an EAP conversation, after which the authenticator
MUST send a Success or Failure packet.
EAPではメソッドのシーケンスを使用する。
一般例はMD5-ChallnegeのようなEAP認証とIdentity Requestである。
peer と authenticatorはEAPでは一つだけ認証方式(Type 4以上)を使用すること。そして、authenticatorはSuccess or Failure パケットを送信すること。

Once a peer has sent a Response of the same Type as the initial
Request, an authenticator MUST NOT send a Request of a different Type
prior to completion of the final round of a given method (with the
exception of a Notification-Request) and MUST NOT send a Request for
an additional method of any Type after completion of the initial
authentication method; a peer receiving such Requests MUST treat them
as invalid, and silently discard them. As a result, Identity Requery
is not supported.
PeerがInitial Requestと同じTypeのResponseを送信した後、authenticatorはメソッドの完了前に異なるタイプのRequestを送ってはいけない（Notification Requestは除く）また、authenticatorはInitial 認証メソッドが完了した後に別のTypeの追加メソッドのRequestを送ってはいけない。
PeerがそのようなRequestを受信した場合、無効として扱い、破棄すること。結果、Identity Requeryはサポートされない。

A peer MUST NOT send a Nak (legacy or expanded) in reply to a Request
after an initial non-Nak Response has been sent. Since spoofed EAP
Request packets may be sent by an attacker, an authenticator
receiving an unexpected Nak SHOULD discard it and log the event.
peerはinitial non-Nak Responseを送信した後、Requestに対する応答としてNak(legacy or expanded)を送信しないこと。
authenticatorは予期しないNakを破棄し、ロギングすること。

Multiple authentication methods within an EAP conversation are not
supported due to their vulnerability to man-in-the-middle attacks
(see Section 7.4) and incompatibility with existing implementations.
EAPにおける複数認証方式は中間者攻撃(Section 7.4)に脆弱性があり、既存の実装と互換性がないため対応しない。

Where a single EAP authentication method is utilized, but other
methods are run within it (a "tunneled" method), the prohibition
against multiple authentication methods does not apply. Such
"tunneled" methods appear as a single authentication method to EAP.
Backward compatibility can be provided, since a peer not supporting a
"tunneled" method can reply to the initial EAP-Request with a Nak

Aboba, et al. Standards Track [Page 9]

RFC 3748 EAP June 2004

(legacy or expanded). To address security vulnerabilities,
"tunneled" methods MUST support protection against man-in-the-middle
attacks.
単一のEAP認証方式が他の方式(Tunneled method)を使って利用される場合、複数の認証方式を禁止する規定は適用されない。
TunneledメソッドはEAPの単一の認証方式とされる。
Tunneled方式をサポートしていないpeerがInitial EAP RequestでNakを応答できるように下位互換性を提供される。

2.2. EAP Multiplexing Model

Conceptually, EAP implementations consist of the following
components:
EAPの実装の概念は下記のコンポーネントで構成される。

[a] Lower layer. The lower layer is responsible for transmitting and
receiving EAP frames between the peer and authenticator. EAP has
been run over a variety of lower layers including PPP, wired IEEE
802 LANs [IEEE-802.1X], IEEE 802.11 wireless LANs [IEEE-802.11],
UDP (L2TP [RFC2661] and IKEv2 [IKEv2]), and TCP [PIC]. Lower
layer behavior is discussed in Section 3.
低レイヤはpeerとauthenticatorとの間でのEAPフレームの送受信をする。
EAPはPPP、IEEE802.1X、IEEE802.11、UDP、IKEv2、TCPなど様々な低レイヤで動作する。
低レイヤの動作はSection 3で説明する。

[b] EAP layer. The EAP layer receives and transmits EAP packets via
the lower layer, implements duplicate detection and
retransmission, and delivers and receives EAP messages to and
from the EAP peer and authenticator layers. 低レイヤを介してEAPパケットを送受信する。重複検知、再送を提供し、peerとauthenticatorでEAPメッセージを送受信する。

[c] EAP peer and authenticator layers. Based on the Code field, the
EAP layer demultiplexes incoming EAP packets to the EAP peer and
authenticator layers. Typically, an EAP implementation on a
given host will support either peer or authenticator
functionality, but it is possible for a host to act as both an
EAP peer and authenticator. In such an implementation both EAP
peer and authenticator layers will be present.
Code filedに基いて、EAPレイヤはEAP peerレイヤとauthenticatorレイヤへの着信パケットを逆多重する。
一般的、ホスト上ではpeer or authenticatorのいずれかをサポートするが、ホストがpeerとauthenticatorの両方をサポートすることも可能である。
そのような実装ではEAP peerレイヤとEAP authenticatorレイヤが存在する。

[d] EAP method layers. EAP methods implement the authentication
algorithms and receive and transmit EAP messages via the EAP peer
and authenticator layers. Since fragmentation support is not
provided by EAP itself, this is the responsibility of EAP
methods, which are discussed in Section 5.
EAPメソッドは認証アルゴリズムを実装し、EAP peerレイヤとEAP authenticatorレイヤを介してEAPメッセージを送受信する。
EAPではfragmentationをサポートしないため、Section 5で議論されるEAPメソッドの責任である。

The EAP multiplexing model is illustrated in Figure 1 below. Note
that there is no requirement that an implementation conform to this
model, as long as the on-the-wire behavior is consistent with it.
EAP多重モデルはFigure 1に示される。
実装はこのモデルへの準拠が要件にないことに注意してください。

Aboba, et al. Standards Track [Page 10]

RFC 3748 EAP June 2004

+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| EAP method| EAP method| | EAP method| EAP method|
| Type = X | Type = Y | | Type = X | Type = Y |
| V | | | ^ | |
+-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+
| ! | | ! |
| EAP ! Peer layer | | EAP ! Auth. layer |
| ! | | ! |
+-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+
| ! | | ! |
| EAP ! layer | | EAP ! layer |
| ! | | ! |
+-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+
| ! | | ! |
| Lower ! layer | | Lower ! layer |
| ! | | ! |
+-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+
! !
! Peer ! Authenticator
+------------>-------------+

Figure 1: EAP Multiplexing Model

Within EAP, the Code field functions much like a protocol number in
IP. It is assumed that the EAP layer demultiplexes incoming EAP
packets according to the Code field. Received EAP packets with
Code=1 (Request), 3 (Success), and 4 (Failure) are delivered by the
EAP layer to the EAP peer layer, if implemented. EAP packets with
Code=2 (Response) are delivered to the EAP authenticator layer, if
implemented.
EAPのCode filed functionはIPのprotocol numberのようなフィールドである。
EAPレイヤはCode filedに応じて着信EAPパケットを分離する。
Code=1 (Request), 3 (Success), and 4 (Failure) で受信したEAPパケットは実装していれば、EAPレイヤからEAP peerレイヤに転送される。
Code=2 (Response)で受信したEAPパケットは実装していればEAPレイヤからEAP authenticatorレイヤに転送される。

Within EAP, the Type field functions much like a port number in UDP
or TCP. It is assumed that the EAP peer and authenticator layers
demultiplex incoming EAP packets according to their Type, and deliver
them only to the EAP method corresponding to that Type. An EAP
method implementation on a host may register to receive packets from
the peer or authenticator layers, or both, depending on which role(s)
it supports.
EAPのType filed functionはUDPやTCPのポート番号のようなfieldである。
EAP peerレイヤ、EAP authentictorレイヤはTypeに応じて着信EAPパケットを逆多重し、Typeに対応したEAPメソッドで転送する。
ホスト上のEAPメソッドの実装はpeerレイヤ、authenticatorレイヤの役割によってそれらからパケットを受信できるように登録できる。

Since EAP authentication methods may wish to access the Identity,
implementations SHOULD make the Identity Request and Response
accessible to authentication methods (Types 4 or greater), in
addition to the Identity method. The Identity Type is discussed in
Section 5.1.
EAP認証方式はIdentityにアクセスできるため、実装ではIdentity methodに加え、認証方式(Type 4以上)へのIdentity RequestとIdentity Responseにアクセスできること。
Identity TypeはSection 5.1で議論する。

Aboba, et al. Standards Track [Page 11]

RFC 3748 EAP June 2004

A Notification Response is only used as confirmation that the peer
received the Notification Request, not that it has processed it, or
displayed the message to the user. It cannot be assumed that the
contents of the Notification Request or Response are available to
another method. The Notification Type is discussed in Section 5.2.
Notification ResponseはpeerがNotification Requestを受信したことの確認のためだけに使われる。
これはNotification RequestやNotification Responseのコンテンツは別のメソッドで利用可能であると仮定することはできない。
Notification TypeはSetion 5.2で議論する。

Nak (Type 3) or Expanded Nak (Type 254) are utilized for the purposes
of method negotiation. Peers respond to an initial EAP Request for
an unacceptable Type with a Nak Response (Type 3) or Expanded Nak
Response (Type 254). It cannot be assumed that the contents of the
Nak Response(s) are available to another method. The Nak Type(s) are
discussed in Section 5.3.

Nak(Type 3)やExpanded Nak（Type 254）はメソッドのネゴシエーションのために利用される。
peerはNak Reposen（Type3） or Expanded Nak Response(Type 254)で許容できないタイプのinitial EAP Requestに応答する。
Nak Responseのコンテンツが別のメソッドで利用可能であると仮定することはできない。
Nak TypeはSection 5.3で議論する。

EAP packets with Codes of Success or Failure do not include a Type
field, and are not delivered to an EAP method. Success and Failure
are discussed in Section 4.2.
EAPパケットのSuccess Code or Failure CodeはType filedが含まれていないとEAPメソッドに転送されない。
Success と FailureはSection 4.2で議論する。

Given these considerations, the Success, Failure, Nak Response(s),
and Notification Request/Response messages MUST NOT be used to carry
data destined for delivery to other EAP methods.
これらの考察より、Success、Failure、Nak Response、Notification Request/ResponseメッセージはEAPメソッドへデータを送信するために使用してはいけない。

2.3. Pass-Through Behavior

When operating as a "pass-through authenticator", an authenticator
performs checks on the Code, Identifier, and Length fields as
described in Section 4.1. It forwards EAP packets received from the
peer and destined to its authenticator layer to the backend
authentication server; packets received from the backend
authentication server destined to the peer are forwarded to it.
pass-through authenticatorとして動作する場合、authenticatorはSection 4.1で定義されるCode、Identifier、Lengthをチェックする。authenticatorはpeerから受信したEAPパケットをバックエンド認証サーバのauthenticatorレイヤに転送する。peer宛のバックエンド認証サーバからの受信パケットはpeerに転送される。

A host receiving an EAP packet may only do one of three things with
it: act on it, drop it, or forward it. The forwarding decision is
typically based only on examination of the Code, Identifier, and
Length fields. A pass-through authenticator implementation MUST be
capable of forwarding EAP packets received from the peer with Code=2
(Response) to the backend authentication server. It also MUST be
capable of receiving EAP packets from the backend authentication
server and forwarding EAP packets of Code=1 (Request), Code=3
(Success), and Code=4 (Failure) to the peer.
EAPパケットを受信したホストは3つのいずれかのみを実行してよい。ACT or DROP or FORWARD。
FORWARDINGの決定はCode、Identifier、Lengthのチェックに基づく。
Pass-through認証の実装ではバックエンド認証サーバにCode=2(Response)のpeerから受信したEAPパケットを転送できること。
同様に、バックエンド認証サーバはEAPパケットを受信でき、Code=1 (Request), Code=3 (Success), Code=4 (Failure)をpeerに転送できること。

Unless the authenticator implements one or more authentication
methods locally which support the authenticator role, the EAP method
layer header fields (Type, Type-Data) are not examined as part of the
forwarding decision. Where the authenticator supports local
authentication methods, it MAY examine the Type field to determine
whether to act on the packet itself or forward it. Compliant pass-
through authenticator implementations MUST by default forward EAP
packets of any Type.
Authenticatorが一つ以上のローカル認証方式を実装していない場合、EAPメソッドレイヤのheader filed(Type、Type-Data)はFORWARDINGの判断に使用されない。
authenticatorはローカル認証をサポートしている場合、自身で制御する(ACT)かFORWARDするか判断するためにType filedをチェックしてよい。
pass-throughに準拠したauthenticatorの実装では任意のTypeのEAPパケットをデフォルトで転送すること。

Aboba, et al. Standards Track [Page 12]

RFC 3748 EAP June 2004

EAP packets received with Code=1 (Request), Code=3 (Success), and
Code=4 (Failure) are demultiplexed by the EAP layer and delivered to
the peer layer. Therefore, unless a host implements an EAP peer
layer, these packets will be silently discarded. Similarly, EAP
packets received with Code=2 (Response) are demultiplexed by the EAP
layer and delivered to the authenticator layer. Therefore, unless a
host implements an EAP authenticator layer, these packets will be
silently discarded. The behavior of a "pass-through peer" is
undefined within this specification, and is unsupported by AAA
protocols such as RADIUS [RFC3579] and Diameter [DIAM-EAP].
Code=1 (Request), Code=3 (Success), Code=4 (Failure)のEAPパケットはEAPレイヤによって逆多重化されpeerレイヤに転送される。そのためホストがEAP peerレイヤを実装していない場合、パケットは破棄される。
同様に、Code=2 (Response) で受信したEAPパケットはEAPレイヤによって逆多重化されauthenticatorレイヤに転送される。そのためホストがEAP authenticatorレイヤを実装していない場合、パケットは破棄される。
pass-through peerの動作はこの仕様書では未定義でRADIUS、DameterのようなAAAプロトコルではサポートされない。

The forwarding model is illustrated in Figure 2.
Forwading modelはFigure2のように表現される。

Peer Pass-through Authenticator Authentication
Server

+-+-+-+-+-+-+ +-+-+-+-+-+-+
| | | |
|EAP method | |EAP method |
| V | | ^ |
+-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+
| ! | |EAP | EAP | | | ! |
| ! | |Peer | Auth.| EAP Auth. | | ! |
|EAP ! peer| | | +-----------+ | |EAP !Auth.|
| ! | | | ! | ! | | ! |
+-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+
| ! | | ! | ! | | ! |
|EAP !layer| | EAP !layer| EAP !layer | |EAP !layer|
| ! | | ! | ! | | ! |
+-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+
| ! | | ! | ! | | ! |
|Lower!layer| | Lower!layer| AAA ! /IP | | AAA ! /IP |
| ! | | ! | ! | | ! |
+-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+
! ! ! !
! ! ! !
+-------->--------+ +--------->-------+

Figure 2: Pass-through Authenticator

For sessions in which the authenticator acts as a pass-through, it
MUST determine the outcome of the authentication solely based on the
Accept/Reject indication sent by the backend authentication server;
the outcome MUST NOT be determined by the contents of an EAP packet
sent along with the Accept/Reject indication, or the absence of such
an encapsulated EAP packet.
Auuthenticatorがpass-throughとして機能するセッションでは、バックエンド認証サーバから送信されたAccept/Rejectの通知のみに基いて認証結果を決定すること。
結果はAccept/Reject通知と一緒に送られたEAPパケットのコンテンツやカプセル化されたEAPパケットの欠如によって決定されてはいけない。

Aboba, et al. Standards Track [Page 13]

RFC 3748 EAP June 2004

2.4. Peer-to-Peer Operation

Since EAP is a peer-to-peer protocol, an independent and simultaneous
authentication may take place in the reverse direction (depending on
the capabilities of the lower layer). Both ends of the link may act
as authenticators and peers at the same time. In this case, it is
necessary for both ends to implement EAP authenticator and peer
layers. In addition, the EAP method implementations on both peers
must support both authenticator and peer functionality.
EAPはpeer-to-peerプロトコルであるので、独立した認証は同時に実行できる(下位レイヤの機能に依存する。)。リンクの両端は同時にauthenticatorとpeerとして動作できる。その場合、両端はEAP authenticatorレイヤとEAP peerレイヤの実装が必要である。さらにpeerのEAPメソッドの実装はauthenticatorとpeerの両方の機能をサポートする必要がある。

Although EAP supports peer-to-peer operation, some EAP
implementations, methods, AAA protocols, and link layers may not
support this. Some EAP methods may support asymmetric
authentication, with one type of credential being required for the
peer and another type for the authenticator. Hosts supporting peer-
to-peer operation with such a method would need to be provisioned
with both types of credentials.
EAPはpeer-to-peerをサポートするが、EAPの実装では、メソッド、AAAプロトコル、linkレイヤをサポートしなくてもよい。EAPメソッドはpeerとauthenticarotで異なる認証をする非対称認証をサポートしてもよい。このようなメソッドでpeer-to-peer動作をするhostは認証情報を両方のタイプで準備する必要がある。
（EAP-TLSのようにクラサバ動作するもの）

For example, EAP-TLS [RFC2716] is a client-server protocol in which
distinct certificate profiles are typically utilized for the client
and server. This implies that a host supporting peer-to-peer
authentication with EAP-TLS would need to implement both the EAP peer
and authenticator layers, support both peer and authenticator roles
in the EAP-TLS implementation, and provision certificates appropriate
for each role.
例えば、EAP-TLS[RFC2716]はクライアントとサーバで異なる証明書を用いるクライアント-サーバプロトコルである。これはEAP-TLSでpeer-to-peerの認証をサポートするhostは、EAP peer/authenticationのレイヤ両方を実装し、peer/authenticaitonとしてEAP-TLSをサポートし、各役割の証明書を用いる必要があることを意味する。

AAA protocols such as RADIUS/EAP [RFC3579] and Diameter EAP [DIAM-
EAP] only support "pass-through authenticator" operation. As noted
in [RFC3579] Section 2.6.2, a RADIUS server responds to an Access-
Request encapsulating an EAP-Request, Success, or Failure packet with
an Access-Reject. There is therefore no support for "pass-through
peer" operation.
RADIUS/EAP[RFC3579]とDiameter EAP[DIAM-EAP]などのAAAプロトコルは"pass-through authenticator"の動作のみをサポートする。[RFC3579]Section 2.6.2で述べられるように、RADIUS serverはAccess-Requestにカプセル化したEAP-Request、Success、Access-RejectのFailureで応答する。"pass-through peer"はサポートされない。

Even where a method is used which supports mutual authentication and
result indications, several considerations may dictate that two EAP
authentications (one in each direction) are required. These include:
メソッドは双方向用に2つのEAP認証を要求できる。

[1] Support for bi-directional session key derivation in the lower
layer. Lower layers such as IEEE 802.11 may only support uni-
directional derivation and transport of transient session keys.
For example, the group-key handshake defined in [IEEE-802.11i] is
uni-directional, since in IEEE 802.11 infrastructure mode, only
the Access Point (AP) sends multicast/broadcast traffic. In IEEE
802.11 ad hoc mode, where either peer may send
multicast/broadcast traffic, two uni-directional group-key
exchanges are required. Due to limitations of the design, this
also implies the need for unicast key derivations and EAP method
exchanges to occur in each direction.
下位レイヤでの双方向のセッションキーのサポート。IEEE 802.11等の下位レイヤは単方向のセッションキーと転送をサポートする。IEEE802.11インフラストラクチャモードではAccess Point(AP)はmulticast/broadcastしか送信できないため、例えば[IEEE802.11i]で定義されたgroup-key handshakeは単方向である。アドホックモードではpeerの両方がmulticast/broadcastを送信できるため、両方向のgroup-key交換ができる。

[2] Support for tie-breaking in the lower layer. Lower layers such
as IEEE 802.11 ad hoc do not support "tie breaking" wherein two
hosts initiating authentication with each other will only go
forward with a single authentication. This implies that even if
802.11 were to support a bi-directional group-key handshake, then
two authentications, one in each direction, might still occur.

[3] Peer policy satisfaction. EAP methods may support result
indications, enabling the peer to indicate to the EAP server
within the method that it successfully authenticated the EAP
server, as well as for the server to indicate that it has
authenticated the peer. However, a pass-through authenticator
will not be aware that the peer has accepted the credentials
offered by the EAP server, unless this information is provided to
the authenticator via the AAA protocol. The authenticator SHOULD
interpret the receipt of a key attribute within an Accept packet
as an indication that the peer has successfully authenticated the
server.
Peer policy satisfaction
EAPメソッドはEAPサーバだけでなく、EAP peerにも認証結果を通知する。ただし、AAAプロトコルを経由してauthenticatorに提供されない場合、"pass-through"の認証システムではpeerがEAPサーバによって提供される認証情報を認識できない。
atuthenticatorが、peerがサーバを認証したことの確認は、Acceptパケット内のkey attributeの受信により確認する。

However, it is possible that the EAP peer's access policy was not
satisfied during the initial EAP exchange, even though mutual
authentication occurred. For example, the EAP authenticator may not
have demonstrated authorization to act in both peer and authenticator
roles. As a result, the peer may require an additional
authentication in the reverse direction, even if the peer provided an
indication that the EAP server had successfully authenticated to it.
EAP peerのアクセスポリシーは相互認証中にInitial EAP認証中に許可されない可能性がある。例えば、EAP authenticatorはpeerとauthenticatorの両方で動作する権限を持っていない可能性がある。その場合、peeは、peerがEAPサーバから認証を受けた後、逆方向の追加の認証を要求することができる。

4. EAP Packet Format

A summary of the EAP packet format is shown below. The fields are
transmitted from left to right.
EAPパケットの概要を以下に示す。 Fieldは左から右に送信される。

Code

The Code field is one octet and identifies the Type of EAP packet.
EAP Codes are assigned as follows:
Code fieldは1オクテットでEAPパケットのタイプを識別する。
EAP Codeは以下のように割り当てられる。

1 Request
2 Response
3 Success
4 Failure

Since EAP only defines Codes 1-4, EAP packets with other codes
MUST be silently discarded by both authenticators and peers.
EAPはCode 1-4のみを定義するため、他のCodeのEAPパケットはauthenticatorとpeerの両方で破棄されること。

Aboba, et al. Standards Track [Page 20]

RFC 3748 EAP June 2004

Identifier

The Identifier field is one octet and aids in matching Responses
with Requests.
Identifier fieldは1オクテットでRequestに一致するResponseの確認に使う。

Length

The Length field is two octets and indicates the length, in
octets, 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 MUST be ignored
upon reception. A message with the Length field set to a value
larger than the number of received octets MUST be silently
discarded.
Length filedは2オクテットで、オクテット単位でCode、Identifier, Length,and Data fieldsを含むEAPパケットの長さを示す。
Lengthフィールドの範囲外であるData Linkレイヤのパディングは受信側で無視されること。
受信オクテットよりもLengthに設定された値が大きい場合、メッセージは破棄されること。

Data

The Data field is zero or more octets. The format of the Data
field is determined by the Code field.
Data fieldは0以上のオクテットである。Data fieldのフォーマットはCode fieldによって決まる。

4.1. Request and Response

Description

The Request packet (Code field set to 1) is sent by the
authenticator to the peer. Each Request has a Type field which
serves to indicate what is being requested. Additional Request
packets MUST be sent until a valid Response packet is received, an
optional retry counter expires, or a lower layer failure
indication is received.
Requestパケット（Code=1）はauthenticatorによりpeerへ送信される。
Requestは要求に関するTypeフィールドをもつ。
追加のRequestパケットは有効なResponseパケットを受信するか、リトライカウンタが超過するか、下位レイヤから失敗通知(Failure indication)を受信するまで送信すること。
（⇒認証終わるか、失敗するまでに送る必要がある）

Retransmitted Requests MUST be sent with the same Identifier value
in order to distinguish them from new Requests. The content of
the data field is dependent on the Request Type. The peer MUST
send a Response packet in reply to a valid Request packet.
Responses MUST only be sent in reply to a valid Request and never
be retransmitted on a timer.
再送されるRequestは新しいRequestと区別するために同じIdentifier valueを送信すること。
Data fieldのコンテンツはRequest Typeに依存する。peerは有効なRequest パケットに対してResponseパケットを送信すること。Responseは有効なRequestに対する応答として送信され、タイマーで再送されることがないこと。

If a peer receives a valid duplicate Request for which it has
already sent a Response, it MUST resend its original Response
without reprocessing the Request. Requests MUST be processed in
the order that they are received, and MUST be processed to their
completion before inspecting the next Request.
PeerがすでにResponseを送信した有効な重複Requestを受信した場合、Requestを再処理することなく、もとのResponseを再送すること。
Requestは受信した順序に処理され、次のRequestをチェックする前に処理を完了すること。

A summary of the Request and Response packet format follows. The
fields are transmitted from left to right.
RequestとResponseのパケットフォーマットを下記に示す。フィールドは左から右に送信される。

Aboba, et al. Standards Track [Page 21]

RFC 3748 EAP June 2004

Code

1 for Request
2 for Response

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.
Identifier filedは1オクテット。Responseを待っている間にタイムアウトして再送される場合はIdentifierは同じであること。再送ではない新しいRequestはIdentifier filedを変更すること。

The Identifier field of the Response MUST match that of the
currently outstanding Request. An authenticator receiving a
Response whose Identifier value does not match that of the
currently outstanding Request MUST silently discard the Response.
ResponseのIndeitifir fieldは現在未処理のRequestと一致すること。
Authenticatorは現在未処理のRequestと一致しないIdentifierをもつResponseを受信したらResponseを破棄すること。

In order to avoid confusion between new Requests and
retransmissions, the Identifier value chosen for each new Request
need only be different from the previous Request, but need not be
unique within the conversation. One way to achieve this is to
start the Identifier at an initial value and increment it for each
new Request. Initializing the first Identifier with a random
number rather than starting from zero is recommended, since it
makes sequence attacks somewhat more difficult.
新しいRequestと再送との混同を避けるため、新しいRequestは前のRequestと異なる必要があるが、プロシージャで一意である必要はない。
実現方法の一つは新しいRequestのたびにIdentifierをインクリメントすることである。
最初のIdentifierは0ではなく乱数にした方がシーケンス攻撃が困難になるのでよい。

Since the Identifier space is unique to each session,
authenticators are not restricted to only 256 simultaneous
authentication conversations. Similarly, with re-authentication,
an EAP conversation might continue over a long period of time, and
is not limited to only 256 roundtrips.
Identifierが有限だが、authenticatorの同時認証プロシージャが256に制限されることはない。
再認証はEAPプロシージャが長期間になるので往復が256に制限されることはない。

Implementation Note: The authenticator is responsible for
retransmitting Request messages. If the Request message is obtained
from elsewhere (such as from a backend authentication server), then
the authenticator will need to save a copy of the Request in order to
accomplish this. The peer is responsible for detecting and handling
duplicate Request messages before processing them in any way,
including passing them on to an outside party. The authenticator is
also responsible for discarding Response messages with a non-matching
Identifier value before acting on them in any way, including passing
them on to the backend authentication server for verification. Since
the authenticator can retransmit before receiving a Response from the
peer, the authenticator can receive multiple Responses, each with a
matching Identifier. Until a new Request is received by the
authenticator, the Identifier value is not updated, so that the
authenticator forwards Responses to the backend authentication
server, one at a time.
AuthenticatorはRequestの再送を担当する。Requestがバックエンド認証サーバなど他の場所から取得された場合、authenticatorはRequestをコピーする必要がある。peerは処理前に重複したRequestメッセージを検出できること。
Authenticatorはバックエンド認証サーバーへの送信を含むRequestメッセージのIdentifierが予期しないものだった場合のメッセージ破棄をすること。AuthenticatorはpeerからResponseを受信する前に再送できるため、Identifierが同じ複数のResponseを受信する。
新たなRequestをauthenticatorが受信するまで、authenticatorはバックエンド認証サーバーに1つずつResponseを送信できるように、Identifierを変更しない。

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 MUST be ignored upon
reception. A message with the Length field set to a value larger
than the number of received octets MUST be silently discarded.
Length filedは2オクテットでCode, Identifier, Length, Type, and Type-Dataを含むEAPパケットのlengthを示す。Lengthフィールドの範囲外であるData Linkレイヤのパディングは受信側で無視されること。受信オクテットよりもLengthに設定された値が大きい場合、メッセージは破棄されること。

Type

The Type field is one octet. This field indicates the Type of
Request or Response. A single Type MUST be specified for each EAP
Request or Response. An initial specification of Types follows in
Section 5 of this document.
Type fieldは1オクテット。Request or ResponseのTypeを示す。各Request or Responseに一つのTypeが設定されること。
InitialのTypeはSection 5に示す。

The Type field of a Response MUST either match that of the
Request, or correspond to a legacy or Expanded Nak (see Section
5.3) indicating that a Request Type is unacceptable to the peer.
A peer MUST NOT send a Nak (legacy or expanded) in response to a
Request, after an initial non-Nak Response has been sent. An EAP
server receiving a Response not meeting these requirements MUST
silently discard it.
ResponseのTypeはRequestかRequest Typeがpeerに許可されなかったことを示すlegacy or Expanded Nak(Section 5.3)に対応している必要がある。
Initial non-Nak Responseが送信された後、peerはRequestの応答としてNak(legacy or expanded)を送信してはいけない。
EAPサーバはこれらの要求を満たさないResponseを受信したらそれを破棄すること。

Type-Data

The Type-Data field varies with the Type of Request and the
associated Response.
Type-DataはRequestとResponseによって異なる。

4.2. Success and Failure

The Success packet is sent by the authenticator to the peer after
completion of an EAP authentication method (Type 4 or greater) to
indicate that the peer has authenticated successfully to the
authenticator. The authenticator MUST transmit an EAP packet with
the Code field set to 3 (Success). If the authenticator cannot
authenticate the peer (unacceptable Responses to one or more
Requests), then after unsuccessful completion of the EAP method in
progress, the implementation MUST transmit an EAP packet with the

Aboba, et al. Standards Track [Page 23]

RFC 3748 EAP June 2004

Code field set to 4 (Failure). An authenticator MAY wish to issue
multiple Requests before sending a Failure response in order to allow
for human typing mistakes. Success and Failure packets MUST NOT
contain additional data.
Successパケットはpeerがauthenticatorに正常に認証したことを示すため、EAP認証(Type 4以上)が完了した後にauthenticatorからpeerに送信される。authenticatorは3(Success)をCode filedに設定したEAPパケットを送信すること。
authenticatorがpeerを認証できない(1つ以上のRequestを許容できない)場合、進行中のEAPメソッドが失敗した後に、実装は4(Failure)をCode filedにセットしたEAPパケットを送信すること。
authenticatorは人の入力ミスを許容するため、Failure応答する前に、複数回Requestしてもよい。SuccessとFailureは追加のデータを含んではいけない。

Success and Failure packets MUST NOT be sent by an EAP authenticator
if the specification of the given method does not explicitly permit
the method to finish at that point. A peer EAP implementation
receiving a Success or Failure packet where sending one is not
explicitly permitted MUST silently discard it. By default, an EAP
peer MUST silently discard a "canned" Success packet (a Success
packet sent immediately upon connection). This ensures that a rogue
authenticator will not be able to bypass mutual authentication by
sending a Success packet prior to conclusion of the EAP method
conversation.
指定されｔメソッドの仕様が明示的にその時点でのメソッドを終了することを許可しない場合、Success and FailureのパケットはEAP authenticatorにより送信されていはいけない。そのような送信では明示的に許可されていないSuccess and Failureのパケットを受信したpeer EAPの実装はパケットを破棄すること。デフォルトではEAP peerは古いSuccessパケットを破棄すること(Successパケットは接続後に即座に送信されること。)。
これにより、不正なauthenticatorが以前のEAPメソッド用のSuccessパケットを送信し、認証をバイパスすることがなくなる。

Implementation Note: Because the Success and Failure packets are not
acknowledged, they are not retransmitted by the authenticator, and
may be potentially lost. A peer MUST allow for this circumstance as
described in this note. See also Section 3.4 for guidance on the
processing of lower layer success and failure indications.
実装上の注意：Success、Failureはacknowledgeされないため、authenticatorにより再送されず、lostする可能性がある。peerはそのような状況を考慮する必要がある。下位レイヤの成功/失敗の処理についてはSection 3.4参照。

As described in Section 2.1, only a single EAP authentication method
is allowed within an EAP conversation. EAP methods may implement
result indications. After the authenticator sends a failure result
indication to the peer, regardless of the response from the peer, it
MUST subsequently send a Failure packet. After the authenticator
sends a success result indication to the peer and receives a success
result indication from the peer, it MUST subsequently send a Success
packet.
Section 2.1で述べたように、EAPでは一つだけEAP認証方式が許容される。EAPメソッドはResult indicationを実装してもよい。authenticatorがpeerにfailure resultを送信した後、peerからの応答に関わらず、その後にFailureパケットを送信すること。
authenticatorがpeerにsuccess result indicationを送信し、peerが受信した場合、その後にSuccessパケットを送信すること。

On the peer, once the method completes unsuccessfully (that is,
either the authenticator sends a failure result indication, or the
peer decides that it does not want to continue the conversation,
possibly after sending a failure result indication), the peer MUST
terminate the conversation and indicate failure to the lower layer.
The peer MUST silently discard Success packets and MAY silently
discard Failure packets. As a result, loss of a Failure packet need
not result in a timeout.
Peerでメソッドが正常に終了しなかった（すなわちauthenticatorがfailure result indicationを送信したか、peerがfailure result indicationを送信し、プロシージャを継続しないことを決定した）場合、peerはプロシージャを終了し、下位レイヤにfailureを通知すること。
PeerはSuccessパケットを破棄すること。またFailureパケットも破棄してよい。その結果、Failureパケットの損失によりタイムアウトが発生することはない。

On the peer, after success result indications have been exchanged by
both sides, a Failure packet MUST be silently discarded. The peer
MAY, in the event that an EAP Success is not received, conclude that
the EAP Success packet was lost and that authentication concluded
successfully.
Success result indicationが両側で交換された後、peerはFailureパケットを破棄すること。EAP Successは受信していないが、peerはEAP Successパケットを損失し、認証は成功したと判断する。（※ACKのような使い方）

Aboba, et al. Standards Track [Page 24]

RFC 3748 EAP June 2004

If the authenticator has not sent a result indication, and the peer
is willing to continue the conversation, the peer waits for a Success
or Failure packet once the method completes, and MUST NOT silently
discard either of them. In the event that neither a Success nor
Failure packet is received, the peer SHOULD terminate the
conversation to avoid lengthy timeouts in case the lost packet was an
EAP Failure.
authenticatorがresult indicationを送信していなくて、peerがプロシージャを継続する場合、peerはメソッド完了後のSuccess or Failureを待ち、それらを破棄してはいけない。（Success or Failure待ちで） SuccessでもFailureでもないパケットを受信した場合、peerは長いタイムアウトを避けるためプロシージャを終了すること。

If the peer attempts to authenticate to the authenticator and fails
to do so, the authenticator MUST send a Failure packet and MUST NOT
grant access by sending a Success packet. However, an authenticator
MAY omit having the peer authenticate to it in situations where
limited access is offered (e.g., guest access). In this case, the
authenticator MUST send a Success packet.
peerがauthenticatorに認証を思考し、それが失敗した場合、authenticatorはFailureパケットを送信すること。Successパケットでアクセス権を付与してはいけない。authenticatorは限定アクセス(例:guestアカウント)の場合、peer認証を省略してもよい。そのケースではauthenticatorはSuccessパケットを送信すること。

Where the peer authenticates successfully to the authenticator, but
the authenticator does not send a result indication, the
authenticator MAY deny access by sending a Failure packet where the
peer is not currently authorized for network access.
peerがauthenticatorに認証されたが、authenticatorがresult indicationを送信しない場合、authenticatorはFailureパケットを送信し、peerのアクセスを拒否してよい。

A summary of the Success and Failure packet format is shown below.
The fields are transmitted from left to right.
Success and Failureパケットフォーマットを下記に示す。fieldは左から右に送信される。

Code

3 for Success
4 for Failure

Identifier

The Identifier field is one octet and aids in matching replies to
Responses. The Identifier field MUST match the Identifier field
of the Response packet that it is sent in response to.
Identifier fieldはResponseとRequestを対応付ける1オクテットである。ResponseとRequestで一致すること。

Length

Aboba, et al. Standards Track [Page 25]

RFC 3748 EAP June 2004

4.3. Retransmission Behavior

Because the authentication process will often involve user input,
some care must be taken when deciding upon retransmission strategies
and authentication timeouts. By default, where EAP is run over an
unreliable lower layer, the EAP retransmission timer SHOULD be
dynamically estimated. A maximum of 3-5 retransmissions is
suggested.
認証プロセスはユーザの入力を伴うため、再送と認証タイムアウトを決定する際には注意が必要である。EAPが信頼性の低い下位レイヤで実行される場合、EAP再送タイマは動的に推定されること。最大で3～5回の再送が提案される。

When run over a reliable lower layer (e.g., EAP over ISAKMP/TCP, as
within [PIC]), the authenticator retransmission timer SHOULD be set
to an infinite value, so that retransmissions do not occur at the EAP
layer. The peer may still maintain a timeout value so as to avoid
waiting indefinitely for a Request.
信頼性のある下位レイヤ（例：EAP over ISAKAMP/TCP）ではEAPレイヤで再送が発生しないように、authenticatorの再送タイマは無限大に設定すること。peerはRequestの無限待機を回避するためにタイムアウト時間を調整してよい。

Where the authentication process requires user input, the measured
round trip times may be determined by user responsiveness rather than
network characteristics, so that dynamic RTO estimation may not be
helpful. Instead, the retransmission timer SHOULD be set so as to
provide sufficient time for the user to respond, with longer timeouts
required in certain cases, such as where Token Cards (see Section
5.6) are involved.
認証プロセスがユーザの入力を必要とする場合、ラウンドトリップタイムは動的なRTO推定は有効でない場合があるため、ユーザの応答により決定してよい。再送タイマはToken Cards(Section 5.6参照)が関係する場合のように長いタイムアウトが必要な場合、ユーザが応答するのに十分な再送タイマを設定すること。
RTO:Retransmission Time Out（再送タイムアウト）

In order to provide the EAP authenticator with guidance as to the
appropriate timeout value, a hint can be communicated to the
authenticator by the backend authentication server (such as via the
RADIUS Session-Timeout attribute).
適切なタイムアウト時間をEAP authenticatorに提供するため、バックエンド認証サーバによりauthenticatorに通知できる(RADIUSのSession-Timeout attributeなどによる)。

In order to dynamically estimate the EAP retransmission timer, the
algorithms for the estimation of SRTT, RTTVAR, and RTO described in
[RFC2988] are RECOMMENDED, including use of Karn's algorithm, with
the following potential modifications:
動的にEAP再送タイマを推定するために、SRTT、RTTVAR、RTOを推定するアルゴリズム[RFC2988]、下記のKarn's Algorithmが推奨される。
SRTT：RTTの平均(smooth)
RTTVAR：RTTの分散(variance)

[a] In order to avoid synchronization behaviors that can occur with
fixed timers among distributed systems, the retransmission timer
is calculated with a jitter by using the RTO value and randomly
adding a value drawn between -RTOmin/2 and RTOmin/2. Alternative
calculations to create jitter MAY be used. These MUST be
pseudo-random. For a discussion of pseudo-random number
generation, see [RFC1750].
固定タイマで発生する同期動作を回避するため、再送タイマはRTO値に-RTOmin/2とRTOmin/2の間の乱数を足してjitterを算出する。jitterの計算は別の式を使用してもよい。これは擬似乱数であること。擬似乱数生成の議論は[RFC1750]参照。

[b] When EAP is transported over a single link (as opposed to over
the Internet), smaller values of RTOinitial, RTOmin, and RTOmax
MAY be used. Recommended values are RTOinitial=1 second,
RTOmin=200ms, and RTOmax=20 seconds.
EAPが一つのリンク(Internetではない。LAN?)で転送される場合、RTOinitial、RTOmin、RTOmaxは小さい値を使用してよい。お勧めはRTOinitial=1 second, RTOmin=200m秒, and RTOmax=20秒

Aboba, et al. Standards Track [Page 26]

RFC 3748 EAP June 2004

[c] When EAP is transported over a single link (as opposed to over
the Internet), estimates MAY be done on a per-authenticator
basis, rather than a per-session basis. This enables the
retransmission estimate to make the most use of information on
link-layer behavior.
EAPが一つのリンク（Internetではない）で転送される場合、Session毎ではなくauthenticator毎に推定した方がよい。リンクレイヤの動作に関する情報を利用することで再送の推定を可能とする。

[d] An EAP implementation MAY clear SRTT and RTTVAR after backing off
the timer multiple times, as it is likely that the current SRTT
and RTTVAR are bogus in this situation. Once SRTT and RTTVAR are
cleared, they should be initialized with the next RTT sample
taken as described in [RFC2988] equation 2.2.
EAPの実装ではSRTTとRTTVARをクリアしてもよい。SRTTとRTTVARがクリアされると、SRTTとRTTVARは[RFC2988]の式2.2で次のRTTをサンプリングして初期化される。

5. Initial EAP Request/Response Types

This section defines the initial set of EAP Types used in Request/
Response exchanges. More Types may be defined in future 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.
このSectionではRequest/Responseの交換に使用されるEAP Typeを定義する。他のTypeは別のドキュメントで定義されてもよい。
Type fieldは1オクテットでEAP Request/Responseのパケット構造を識別する。
最初の3つは特殊なケースのTypeとして考慮される。

The remaining Types define authentication exchanges. Nak (Type 3) or
Expanded Nak (Type 254) are valid only for Response packets, they
MUST NOT be sent in a Request.
残りのTypeは認証の交換を定義する。
Nak(Type 3) or Expanded Nak(Type 254)はResponseパケットのみで、Requestには使用しないこと。

All EAP implementations MUST support Types 1-4, which are defined in
this document, and SHOULD support Type 254. Implementations MAY
support other Types defined here or in future RFCs.
EAPの実装はType 1-4をサポートすること。実装は他のTypeや他のRFCで定義されているTypeをサポートしてもよい。

1 Identity
2 Notification
3 Nak (Response only)
4 MD5-Challenge
5 One Time Password (OTP)
6 Generic Token Card (GTC)
254 Expanded Types
255 Experimental use

EAP methods MAY support authentication based on shared secrets. If
the shared secret is a passphrase entered by the user,
implementations MAY support entering passphrases with non-ASCII
characters. In this case, the input should be processed using an
appropriate stringprep [RFC3454] profile, and encoded in octets using
UTF-8 encoding [RFC2279]. A preliminary version of a possible
stringprep profile is described in [SASLPREP].
EAPメソッドは共通鍵に基づく認証をサポートしてよい。共通鍵がユーザの入力したパスフレーズである場合、実装は非ASCII文字を含むパスフレーズの入力をサポートしてよい。その場合、入力は適切な文字列処理[RFC3454]とUTF-8エンコーディング[RFC2279]で処理されること。文字列処理は[SASLPREP]で説明される。

Aboba, et al. Standards Track [Page 27]

RFC 3748 EAP June 2004

5.1. Identity

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 is an expectation of
interaction with a user. A Response of Type 1 (Identity) SHOULD
be sent in Response to a Request with a Type of 1 (Identity).
Identity TypeはpeerのIDを照会するために使用される。一般的にauthenticatorはInitial Requestでこれを発行する。peerに入力を要求するためのオプションの表示可能メッセージが含まれてもよい。Type 1(Identity)のRequestに対してType 1(Identity)のResponseが送信されること。

Some EAP implementations piggy-back various options into the
Identity Request after a NUL-character. By default, an EAP
implementation SHOULD NOT assume that an Identity Request or
Response can be larger than 1020 octets.
EAPの実装は複数のオプションをIdentity Requestのnull文字の後にpiggy-backしてよい。
デフォルトのEAPの実装では、Identity Request/Responseは1020オクテットより大きくならないこと。（※Fragmentの考慮。Fragmentが保証される他の認証方式の場合だったらよい。）

It is RECOMMENDED that the Identity Response be used primarily for
routing purposes and selecting which EAP method to use. EAP
Methods SHOULD include a method-specific mechanism for obtaining
the identity, so that they do not have to rely on the Identity
Response. Identity Requests and Responses are sent in cleartext,
so an attacker may snoop on the identity, or even modify or spoof
identity exchanges. To address these threats, it is preferable
for an EAP method to include an identity exchange that supports
per-packet authentication, integrity and replay protection, and
confidentiality. The Identity Response may not be the appropriate
identity for the method; it may have been truncated or obfuscated
so as to provide privacy, or it may have been decorated for
routing purposes. Where the peer is configured to only accept
authentication methods supporting protected identity exchanges,
the peer MAY provide an abbreviated Identity Response (such as
omitting the peer-name portion of the NAI [RFC2486]). For further
discussion of identity protection, see Section 7.3.
Identity ResponseはルーティングとEAPメソッドの選択に使用することを推奨する。EAPメソッドはIdentity Responseを必要としないように、EAPメソッドはIDを取得するためのメソッド固有のメカニズムを含む。Identity Request/Responseは平文で送信されるので、攻撃者はIDを盗聴したり、ID交換をなりすますことができる。これらの脅威に対抗するため、EAPメソッドはパケット毎の認証、完全性チェック、機密性を含むことが望ましい。Identity ResponseはメソッドのためのIDでなくてもよく、難読化されたり、切り詰められてもよい。Peerが保護されたID交換をサポートする認証方式のみ設定される場合、peerはNAIのpeer-name部を省略したようなIdentity Responseを提供してよい。
NAI(Network Access Identifier：nai = username / ( username "@" realm ))
Section 7.3でidentity protectionについて議論する。

Implementation Note: The peer MAY obtain the Identity via user input.
It is suggested that the authenticator retry the Identity 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. 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).
実装上の注意：Peerはユーザの入力からIdentityを得る可能性がある。authenticatorはタイプミスによる認証失敗や不正IDの場合はIdentity Requestを再試行することが推奨される。Identiry Requestは認証が終了する前に最低でも3回再試行されることが推奨される。
Notification Requestは新しいIdentity Request送信の前に、無効になった認証を通知するために使用してよい。(必要ならば、認証失敗は新しいIdentity Requestで通知してもよい。)

Aboba, et al. Standards Track [Page 28]

RFC 3748 EAP June 2004

Type

Type-Data

This field MAY contain a displayable message in the Request,
containing UTF-8 encoded ISO 10646 characters [RFC2279]. Where
the Request contains a null, only the portion of the field prior
to the null is displayed. If the Identity is unknown, the
Identity Response field should be zero bytes in length. The
Identity Response field MUST NOT be null terminated. In all
cases, the length of the Type-Data field is derived from the
Length field of the Request/Response packet.
このfieldはUTF-8、ISO 10646文字のRequest中の印字可能なメッセージが含まれる。Requestがnullを含む場合、nullの前のfieldが表示される。Identityが不明な場合、Identity Response fieldはlengthを0にすること。Identity Response filedはnull終端してはいけない。
Type-Data fieldの長さは、Request/Response パケットのLength filedから導出される。

Security Claims (see Section 7.2):

Auth. mechanism: None
Ciphersuite negotiation: No
Mutual authentication: No
Integrity protection: No
Replay protection: No
Confidentiality: No
Key derivation: No
Key strength: N/A
Dictionary attack prot.: N/A
Fast reconnect: No
Crypt. binding: N/A
Session independence: N/A
Fragmentation: No
Channel binding: No

5.2. Notification

Description

The Notification Type is optionally used to convey a displayable
message from the authenticator to the peer. An authenticator MAY
send a Notification Request to the peer at any time when there is
no outstanding Request, prior to completion of an EAP
authentication method. The peer MUST respond to a Notification
Request with a Notification Response unless the EAP authentication
method specification prohibits the use of Notification messages.
In any case, a Nak Response MUST NOT be sent in response to a
Notification Request. Note that the default maximum length of a
Notification Request is 1020 octets. By default, this leaves at
most 1015 octets for the human readable message.
Notification Typeは必要に応じてpeerにauthenticatorから表示可能なメッセージを通知するために使用される。EAP認証メソッドの完了前の未完了のRequestが存在しない場合、authenticatorはいつでもpeerにNotification Requestを送信してよい。（※EAP認証メソッドの手続き中じゃなかったらってこと）
EAP認証メソッドの仕様がNotificationメッセージの使用を禁止していなければ、peerはNotification ResponseでNotification Requestに応答すること。いずれのケースでもNotification Requestの応答にNak Responseを送信してはいけない。Notification Requestの最大長はデフォルトでは1020オクテットであることに注意すること。デフォルトでは、このとき表示可能なメッセージは1015オクテットとなる。

Aboba, et al. Standards Track [Page 29]

RFC 3748 EAP June 2004

An EAP method MAY indicate within its specification that
Notification messages must not be sent during that method. In
this case, the peer MUST silently discard Notification Requests
from the point where an initial Request for that Type is answered
with a Response of the same Type.
EAPメソッドはNotificationメッセージがメソッド中に送信しないように、仕様として示してもよい。その場合、peerはauthenticatorからのNotification Requestを破棄すること。

The peer SHOULD display this message to the user or log it if it
cannot be displayed. The Notification Type is intended to provide
an acknowledged notification of some imperative nature, but it is
not an error indication, and therefore does not change the state
of the peer. 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.
peerはユーザにメッセージを表示するか、表示できない場合はログに記録すること。Notificatio Typeは通知を提供することを目的としているが、エラー通知ではないためpeerの状態は変化しない。例えば、OTPのシーケンス番号が0に近づく、パスワードの有効期限切れ、認証の失敗の警告等である。できる限り、Notificationは要求されないこと。
OTP：One Time Password：ワンタイムパスワード

Type

Type-Data

The Type-Data field in the Request contains a displayable message
greater than zero octets in length, containing UTF-8 encoded ISO
10646 characters [RFC2279]. The length of the message is
determined by the 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-Data fieldはUTF-8、ISO 10646[RFC2279]の0オクテットより長い表示可能メッセージが含まれる。
メッセージ長はRequestパケットのLength filedによって決められる。このメッセージはnull終端してはいけない。Response(Type filed 2)をRequestの応答に送信すること。ResponseのType-Data filedは0オクテットであること。メッセージの表示やロギングとは無関係にResponseは即座に送信されること。

Security Claims (see Section 7.2):

Aboba, et al. Standards Track [Page 30]

RFC 3748 EAP June 2004

5.3. Nak

5.3.1. Legacy Nak

Description

The legacy 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 one or more authentication Types desired by
the Peer. Type zero (0) is used to indicate that the sender has
no viable alternatives, and therefore the authenticator SHOULD NOT
send another Request after receiving a Nak Response containing a
zero value.
legacy Nak TypeはResponseメッセージでのみ有効である。要求されたauthentication Typeが許容できないRequestに対する応答として送信される。Authentication Typeは4以上が設定される。Responseはpeerが要求する1つ以上のauthenticatio Typeが含まれている。Type 0は送信者(peer)が他の選択肢を持っていないことを示し、authenticatorは0のNak Responseを受信した後はRequestを送らないこと。

Since the legacy Nak Type is valid only in Responses and has very
limited functionality, it MUST NOT be used as a general purpose
error indication, such as for communication of error messages, or
negotiation of parameters specific to a particular EAP method.
legacy Nak TypeがResponseだけで有効であり、限られた機能を持っているため、EAPメソッド固有パラメータのネゴシエーションエラーやエラーメッセージのような汎用的なエラー通知としてしようしないこと。

Code

2 for Response.

Identifier

The Identifier field is one octet and aids in matching Responses
with Requests. The Identifier field of a legacy Nak Response MUST
match the Identifier field of the Request packet that it is sent
in response to.
Identifier fieldは1オクテットでRequestとResponseの照合するために使用される。
legacy Nak ResponseのIdentifier fieldは応答するRequestパケットのIdentifier filedと一致すること。

Length

>=6

Type

Type-Data

Where a peer receives a Request for an unacceptable authentication
Type (4-253,255), or a peer lacking support for Expanded Types
receives a Request for Type 254, a Nak Response (Type 3) MUST be
sent. The Type-Data field of the Nak Response (Type 3) MUST
contain one or more octets indicating the desired authentication
Type(s), one octet per Type, or the value zero (0) to indicate no
proposed alternative. A peer supporting Expanded Types that

Aboba, et al. Standards Track [Page 31]

RFC 3748 EAP June 2004

receives a Request for an unacceptable authentication Type (4-253,
255) MAY include the value 254 in the Nak Response (Type 3) to
indicate the desire for an Expanded authentication Type. If the
authenticator can accommodate this preference, it will respond
with an Expanded Type Request (Type 254).
peerが許容できない authentication Type(4～253, 255)のRequestを受信した場合 or Expanded TypeをサポートしていないpeerがType 254のRequestを受信した場合、Nak Response(Type 3)が送信されること。Nak Response(Type 3)のType-Data filedには1オクテット以上の要求するauthentication Type(s)が含まれること。1Type毎に1オクテットとし、0は選択肢がないことを示す。許容できないauthenticaiton Type(4-253, 255)のRequestを受信したExpanded TypeをサポートするpeerはExpanded authentication Typeを示すため、Nak Response(Type 3)に254を設定してもよい。
Authenticatorが設定に対応可能ならば、Expanded Type Request(Type 254)を応答する。

Security Claims (see Section 7.2):

5.3.2. Expanded Nak

Description

The Expanded Nak Type is valid only in Response messages. It MUST
be sent only in reply to a Request of Type 254 (Expanded Type)
where the authentication Type is unacceptable. The Expanded Nak
Type uses the Expanded Type format itself, and the Response
contains one or more authentication Types desired by the peer, all
in Expanded Type format. Type zero (0) is used to indicate that
the sender has no viable alternatives. The general format of the
Expanded Type is described in Section 5.7.
Expanded Nak TypeはResponseメッセージでのみ有効である。認証Typeが許容できないType 254(Expanded Type)のRequestの応答としてのみ送信すること。Expanded Nak TypeはExpanded Type formatを使用し、Responseはpeerが要求する1つ以上の認証TypeがすべてのExpanded Type formatに含まれる。Type 0は送信者(peer)が他の候補を持たない場合に使用される。Expanded TypeはSection 5.7で説明される。

Since the Expanded Nak Type is valid only in Responses and has
very limited functionality, it MUST NOT be used as a general
purpose error indication, such as for communication of error
messages, or negotiation of parameters specific to a particular
EAP method.
Expanded Nak TypeがResponseだけで有効であり、限られた機能を持っているため、EAPメソッド固有パラメータのネゴシエーションエラーやエラーメッセージのような汎用的なエラー通知としてしようしないこと。

Code

2 for Response.

Aboba, et al. Standards Track [Page 32]

RFC 3748 EAP June 2004

Identifier

The Identifier field is one octet and aids in matching Responses
with Requests. The Identifier field of an Expanded Nak Response
MUST match the Identifier field of the Request packet that it is
sent in response to.
Identifier fieldは1オクテットでRequestとResponseの照合するために使用される。
legacy Nak ResponseのIdentifier fieldは応答するRequestパケットのIdentifier filedと一致すること。

Length

>=20

Type

254

Vendor-Id

0 (IETF)

Vendor-Type

3 (Nak)

Vendor-Data

The Expanded Nak Type is only sent when the Request contains an
Expanded Type (254) as defined in Section 5.7. The Vendor-Data
field of the Nak Response MUST contain one or more authentication
Types (4 or greater), all in expanded format, 8 octets per Type,
or the value zero (0), also in Expanded Type format, to indicate
no proposed alternative. The desired authentication Types may
include a mixture of Vendor-Specific and IETF Types. For example,
an Expanded Nak Response indicating a preference for OTP (Type 5),
and an MIT (Vendor-Id=20) Expanded Type of 6 would appear as
follows:
Section 5.7で定義されたExpanded Type(254)を含むRequestのときのみ、Expanded Nak Typeが送信される。
Nak ResponseのVendor-Data filedには1つ以上の認証Type(4以上)、Typeごとの8オクテットのすべてのexpanded formatを含むこと。または、候補がない場合、0を設定し通知する。
要求する認証Typeはベンダー固有とIETF Typeを合わせてもよい。
例えば下記のように、OTP(One Type Password:Type 5)とMIT(Vendor-ID 20)を示すExpanded Nak Responseがある。

Aboba, et al. Standards Track [Page 33]

RFC 3748 EAP June 2004

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | Identifier | Length=28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=254 | 0 (IETF) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 (Nak) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=254 | 0 (IETF) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 (OTP) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=254 | 20 (MIT) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

An Expanded Nak Response indicating a no desired alternative would
appear as follows:
下記に他の候補のないExpanded Nak 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | Identifier | Length=20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=254 | 0 (IETF) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 (Nak) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=254 | 0 (IETF) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 (No alternative) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Security Claims (see Section 7.2):

Aboba, et al. Standards Track [Page 34]

RFC 3748 EAP June 2004

Session independence: N/A
Fragmentation: No
Channel binding: No

5.4. MD5-Challenge

Description

The MD5-Challenge Type is analogous to the PPP CHAP protocol
[RFC1994] (with MD5 as the specified algorithm). The Request
contains a "challenge" message to the peer. A Response MUST be
sent in reply to the Request. The Response MAY be either of Type
4 (MD5-Challenge), Nak (Type 3), or Expanded Nak (Type 254). The
Nak reply indicates the peer's desired authentication Type(s).
EAP peer and EAP server implementations MUST support the MD5-
Challenge mechanism. An authenticator that supports only pass-
through MUST allow communication with a backend authentication
server that is capable of supporting MD5-Challenge, although the
EAP authenticator implementation need not support MD5-Challenge
itself. However, if the EAP authenticator can be configured to
authenticate peers locally (e.g., not operate in pass-through),
then the requirement for support of the MD5-Challenge mechanism
applies.
MD5-Challenge TypeはPPP CHAPプロトコル[RFC1994]と類似している。
Requestはpeerへの"challenge"メッセージを含む。ResponseはRequestの応答として送信すること。Responseは4 (MD5-Challenge), Nak (Type 3), or Expanded Nak (Type 254)のいずれかであってよい。Nak応答ではpeerが要求する認証Typeを示す。EAP peerとEAP serverはMD5-Challengeメカニズムをサポートすること。EAP authenticatorはMD5-Challnegeをサポートする必要はないが、その場合、authenticatorはMD5-Challengeをサポートしたバックエンド認証サーバとの通信とpass-throughをサポートすること。ただし、EAP authenticatorがローカル認証(pass-throughを使用しない認証)を設定できるる場合、MD5-Challengeをサポートすること。

Note that the use of the Identifier field in the MD5-Challenge
Type is different from that described in [RFC1994]. EAP allows
for retransmission of MD5-Challenge Request packets, while
[RFC1994] states that both the Identifier and Challenge fields
MUST change each time a Challenge (the CHAP equivalent of the
MD5-Challenge Request packet) is sent.
MD5-Challenge TypeのIdentifier filedは[RFC 1994]のものとは異なる。[RFC1994]ではChallenge filedとIdentifierはChallengeの送信(MD5-Challenge Requestと同等)毎に変更する必要があるが、EAPではMD5-Challenge Requestパケットの再送をしてもよい。

Note: [RFC1994] treats the shared secret as an octet string, and
does not specify how it is entered into the system (or if it is
handled by the user at all). EAP MD5-Challenge implementations
MAY support entering passphrases with non-ASCII characters. See
Section 5 for instructions how the input should be processed and
encoded into octets.
[RFC1994]ではoctet stringとして共通鍵と扱い、システムに入力する方法を規定しない。
EAP MD5-Challengeの実装は、非ASCII文字をpassphraseとしないことをしてもよい。
Section 5でoctet stringにエンコードする方法を示す。

Type

Type-Data

The contents of the Type-Data field is summarized below. For
reference on the use of these fields, see the PPP Challenge
Handshake Authentication Protocol [RFC1994].
Type-Data fieldを下記に示す。
これらのフィールドの使用方法は、PPP Challenge Handshake Authentication Protocol[RFC1994]を参照。

Aboba, et al. Standards Track [Page 35]

RFC 3748 EAP June 2004

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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Security Claims (see Section 7.2):

Auth. mechanism: Password or pre-shared key.
Ciphersuite negotiation: No
Mutual authentication: No
Integrity protection: No
Replay protection: No
Confidentiality: No
Key derivation: No
Key strength: N/A
Dictionary attack prot.: No
Fast reconnect: No
Crypt. binding: N/A
Session independence: N/A
Fragmentation: No
Channel binding: No

5.5. One-Time Password (OTP)

Description

The One-Time Password system is defined in "A One-Time Password
System" [RFC2289] and "OTP Extended Responses" [RFC2243]. The
Request contains an OTP challenge in the format described in
[RFC2289]. A Response MUST be sent in reply to the Request. The
Response MUST be of Type 5 (OTP), Nak (Type 3), or Expanded Nak
(Type 254). The Nak Response indicates the peer's desired
authentication Type(s). The EAP OTP method is intended for use
with the One-Time Password system only, and MUST NOT be used to
provide support for cleartext passwords.
One-Time Password systemは"A One-Time Password System"[RFC2289]および"OTP Extended Responses"[RFC2243]で定義される。Requestは[RFC2289]で定義されたOTP challengeを含む。ResponseはRequestの応答として送信されること。ResponseはType 5 (OTP), Nak (Type 3), or Expanded Nak (Type 254)であること。Nak Responseではpeerの要求する認証Typeを示す。EAP OTPメソッドはOne-Time Passwordシステムにのみ使用され、平文パスワードをサポートするシステムでは使用しないこと。

Type

Aboba, et al. Standards Track [Page 36]

RFC 3748 EAP June 2004

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 [RFC2289]. The messages MUST
NOT be null terminated. The length of the field is derived from
the Length field of the Request/Reply packet.
Type-Data filedはRequestでは表示可能なOTP "challenge"を含む。ResponsehaこのフィールドをOTP dictionary[RFC2289]として6 wordを使用する。このメッセージはnull終端してはいけない。このfiledの長さはRequest/ResponseパケットのLength filedから導出される。

Note: [RFC2289] does not specify how the secret pass-phrase is
entered by the user, or how the pass-phrase is converted into
octets. EAP OTP implementations MAY support entering passphrases
with non-ASCII characters. See Section 5 for instructions on how
the input should be processed and encoded into octets.
[RFC2289]では秘密pass-phraseをユーザが入力する方法、pass-phraseをoctetに変換する方法を規定していない。EAP OTPでは非ASCII文字を含むpass-phraseをサポートしてもよい。Section 5に入力をoctetにエンコードする方法を示す。

Security Claims (see Section 7.2):

Auth. mechanism: One-Time Password
Ciphersuite negotiation: No
Mutual authentication: No
Integrity protection: No
Replay protection: Yes
Confidentiality: No
Key derivation: No
Key strength: N/A
Dictionary attack prot.: No
Fast reconnect: No
Crypt. binding: N/A
Session independence: N/A
Fragmentation: No
Channel binding: No

5.6. Generic Token Card (GTC)

Description

The Generic Token Card Type is defined for use with various Token
Card implementations which require user input. The Request
contains a displayable message and the Response 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. A Response MUST be sent in reply to the
Request. The Response MUST be of Type 6 (GTC), Nak (Type 3), or
Expanded Nak (Type 254). The Nak Response indicates the peer's
desired authentication Type(s). The EAP GTC method is intended
for use with the Token Cards supporting challenge/response

Aboba, et al. Standards Track [Page 37]

RFC 3748 EAP June 2004

authentication and MUST NOT be used to provide support for
cleartext passwords in the absence of a protected tunnel with
server authentication.
Generic Token Card Typeはユーザの入力を必要とするToken Cardの実装で使用するために定義される。
Requestは表示可能メッセージを含み、Responseは認証に必要なToken Card情報を含む。
典型的にはToken Card deviceから読み取られASCII文字として入力される。Requestに対してResponseを送信すること。ResponseはType 6 (GTC), Nak (Type 3), or Expanded Nak (Type 254)であること。Nak Responseの場合、peerが要求する認証Typeを通知すること。
Token CardによるEAP GTCメソッドはchallenge/response認証をサポートし、サーバ認証にトンネルが存在しない場合に平文テキストを送信する場合は使用してはいけない。

Type

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 the 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 of the data is determined by the
Length field of the Response packet.
RequestのType-Data filedは0以上の長さの表示可能なメッセージを含む。メッセージ長はRequestパケットのLength filedで決まる。メッセージはnull終端しないこと。6 (Generic Token Card)のRequestにはResponseを送信すること。Responseは認証に必要なToken Cardのデータが含まれる。データ長はResponseパケットのLength filedで決まる。

EAP GTC implementations MAY support entering a response with non-
ASCII characters. See Section 5 for instructions how the input
should be processed and encoded into octets.
EAP GTCの実装は非ASCII文字で応答することをサポートしなくてもよい。Section 5に入力をoctetにエンコードする方法を示す。

Security Claims (see Section 7.2):

Auth. mechanism: Hardware token.
Ciphersuite negotiation: No
Mutual authentication: No
Integrity protection: No
Replay protection: No
Confidentiality: No
Key derivation: No
Key strength: N/A
Dictionary attack prot.: No
Fast reconnect: No
Crypt. binding: N/A
Session independence: N/A
Fragmentation: No
Channel binding: No

5.7. Expanded Types

Description

Since many of the existing uses of EAP are vendor-specific, the
Expanded method Type is available to allow vendors to support
their own Expanded Types not suitable for general usage.
EAPの用途にはベンダー固有があるため、Expanded method Typeは独自のExpanded Typeをサポートできるように使用される。

Aboba, et al. Standards Track [Page 38]

RFC 3748 EAP June 2004

The Expanded Type is also used to expand the global Method Type
space beyond the original 255 values. A Vendor-Id of 0 maps the
original 255 possible Types onto a space of 2^32-1 possible Types.
(Type 0 is only used in a Nak Response to indicate no acceptable
alternative).
Expanded Typeは255以上にMethod Typeを拡張するために使用される。

An implementation that supports the Expanded attribute MUST treat
EAP Types that are less than 256 equivalently, whether they appear
as a single octet or as the 32-bit Vendor-Type within an Expanded
Type where Vendor-Id is 0. Peers not equipped to interpret the
Expanded Type MUST send a Nak as described in Section 5.3.1, and
negotiate a more suitable authentication method.
Expanded attributeをサポートする実装では、1オクテット or 0であるVendor-ID Expanded Typeの32bitのVendor-Typeとして示されるEAP Typeを256未満の場合と同等に扱うこと。
PeerがExpanded Typeをサポートしていない場合、Section 5.3.1に示すとおり、Nakを送信し、認証メソッドをネゴシエーションすること。

A summary of the Expanded Type format is shown below. The fields
are transmitted from left to right.
Expanded Type formatを下記に示す。filedは左から右に送信される。

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 | Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

254 for Expanded Type

Vendor-Id

The Vendor-Id is 3 octets and represents the SMI Network
Management Private Enterprise Code of the Vendor in network byte
order, as allocated by IANA. A Vendor-Id of zero is reserved for
use by the IETF in providing an expanded global EAP Type space.
Vendor-IDは3オクテットであり、IANAによって割り当てられたベンダーのSMI Network Management Private Enterprise Codeのネットワークバイトオーダーを示す。0のVendor-IDはIETFのために予約されている。

Vendor-Type

The Vendor-Type field is four octets and represents the vendor-
specific method Type.
Vendor-Typeは4オクテットでベンダー固有のメソッドTypeを表す。

If the Vendor-Id is zero, the Vendor-Type field is an extension
and superset of the existing namespace for EAP Types. The first
256 Types are reserved for compatibility with single-octet EAP
Types that have already been assigned or may be assigned in the
future. Thus, EAP Types from 0 through 255 are semantically
identical, whether they appear as single octet EAP Types or as

Aboba, et al. Standards Track [Page 39]

RFC 3748 EAP June 2004

Vendor-Types when Vendor-Id is zero. There is one exception to
this rule: Expanded Nak and Legacy Nak packets share the same
Type, but must be treated differently because they have a
different format.
Vendor-IDが0の場合、Vendor-Type fieldは既存のEAP Typeを拡張したものである。
256まではすでに割り当てられているか、将来のために予約されている。このため、0～255のEAP Typeは、1オクテットのEAP TypeとVendor-ID 0のときのVendor-Typeと同じである。ただし例外があり、Expanded NakとLegacy Nakパケットは同じTypeだが、異なるformatのため異なる処理をすること。

Vendor-Data

The Vendor-Data field is defined by the vendor. Where a Vendor-Id
of zero is present, the Vendor-Data field will be used for
transporting the contents of EAP methods of Types defined by the
IETF.
Vendor-Dataはベンダーによって定義される。Vendor-IDが0の場合、Vendor-DataはIETF
によって定義されるEAPメソッドのコンテンツを送信するために使用される。

5.8. Experimental

Description

The Experimental Type has no fixed format or content. It is
intended for use when experimenting with new EAP Types. This Type
is intended for experimental and testing purposes. No guarantee
is made for interoperability between peers using this Type, as
outlined in [RFC3692].
Experimental Typeは固定のフォーマットやコンテンツを持っていない。新しいEAP Typeを試すときに使用するものである。このタイプは試験を目的にしている。[RFC3692]に示されう保証はこのタイプを使用したpeer間の相互運用には適用されない。

Type

255

Type-Data

Undefined

Aboba, et al. Standards Track [Page 63]

RFC 3748 EAP June 2004

Appendix A. Changes from RFC 2284

This section lists the major changes between [RFC2284] and this
document. Minor changes, including style, grammar, spelling, and
editorial changes are not mentioned here.
このセクションでは[RFC2284]とこのドキュメントの主要な変更点を示す。文法やスペルなどの軽微な経脳は記載されない。

o The Terminology section (Section 1.2) has been expanded, defining
more concepts and giving more exact definitions.
用語Section(Section 1.2)がコンセプトと定義により拡張されれた。

o The concepts of Mutual Authentication, Key Derivation, and Result
Indications are introduced and discussed throughout the document
where appropriate.
Mutual Authentication(相互認証)、Key Derivation(鍵導出)、Result Indication(結果通知)のコンセプトがドキュメント全体に導入され、議論されている。

o In Section 2, it is explicitly specified that more than one
exchange of Request and Response packets may occur as part of the
EAP authentication exchange. How this may be used and how it may
not be used is specified in detail in Section 2.1.
Section 2で明示的にRequestとResponseの複数のやりとりがEAP認証で発生する可能性を規定した。

o Also in Section 2, some requirements have been made explicit for
the authenticator when acting in pass-through mode.
Section 2でpass-throughモードで動作する場合、authenticatorのための要件が明示的に示された。

o An EAP multiplexing model (Section 2.2) has been added to
illustrate a typical implementation of EAP. There is no
requirement that an implementation conform to this model, as long
as the on-the-wire behavior is consistent with it.
EAP多重化モデル(Section 2.2)がEAPの一般的な実装を示すために追加された。
実装がこのモデルに準拠している必要はない。

o As EAP is now in use with a variety of lower layers, not just PPP
for which it was first designed, Section 3 on lower layer behavior
has been added.
EAPは最初に設計されたPPPだけでなく様々な低レイヤで使用される。Section 3で低レイヤの動作が追加された。

o In the description of the EAP Request and Response interaction
(Section 4.1), both the behavior on receiving duplicate requests,
and when packets should be silently discarded has been more
exactly specified. The implementation notes in this section have
been substantially expanded.
RequestとResponseの動作の説明(Section 4.1)では、重複Request受信、パケットを破棄の動作が明確に仕様化された。実装の注意点が拡張された。

o In Section 4.2, it has been clarified that Success and Failure
packets must not contain additional data, and the implementation
note has been expanded. A subsection giving requirements on
processing of success and failure packets has been added.
Section 4.2ではSuccessパケットとFailureパケットが追加のデータを含んではいけないことが明記された。SuccessパケットとFailureパケットの要求事項が追加された。

o Section 5 on EAP Request/Response Types lists two new Type values:
the Expanded Type (Section 5.7), which is used to expand the Type
value number space, and the Experimental Type. In the Expanded
Type number space, the new Expanded Nak (Section 5.3.2) Type has
been added. Clarifications have been made in the description of
most of the existing Types. Security claims summaries have been
added for authentication methods.
Section 5のEAP Request/Response Typeのリストに2つのTypeが追加された。
Typeの値を拡張するために使用されるExpanded Type(Section 5.7)とExperimental Type。
Expanded Type number spaceでは、新しい Expanded Nak(Section 5.3.2) Typeが追加された。
既存の説明の明確化。認証方式のSecurity要求が追加された。

Aboba, et al. Standards Track [Page 64]

RFC 3748 EAP June 2004

o In Sections 5, 5.1, and 5.2, a requirement has been added such
that fields with displayable messages should contain UTF-8 encoded
ISO 10646 characters.
Section 5、5.1、5.2にfiledはUTF-8、ISO 10646文字の表示可能文字であるという要求事項が追加された。

o It is now required in Section 5.1 that if the Type-Data field of
an Identity Request contains a NUL-character, only the part before
the null is displayed. RFC 2284 prohibits the null termination of
the Type-Data field of Identity messages. This rule has been
relaxed for Identity Request messages and the Identity Request
Type-Data field may now be null terminated.
Section 5.1でIdentity RequestのType-Data filedがNULを含んでいる場合、nullの前の部分までが表示されることが要求される。
RFC2284ではIdentityメッセージのType-Data filedのnull終端を禁止している。
このルールはIdentity RequestメッセージとIdentity Request Type-Data filedで緩和されており、現在はnull終端できる。

o In Section 5.5, support for OTP Extended Responses [RFC2243] has
been added to EAP OTP.
Section 5.5では、OTP Extended Response[RFC2243]のサポートがEAP OTPに追加された。

o An IANA Considerations section (Section 6) has been added, giving
registration policies for the numbering spaces defined for EAP.
IANA Consideration section(Section 6)がEAPのために定義されたnumbering spaceの登録ポリシーのために追加された。

o The Security Considerations (Section 7) have been greatly
expanded, giving a much more comprehensive coverage of possible
threats and other security considerations.
Security Consideration(Section 7)が大幅に拡張され、脅威とセキュリティに関して総合的にカバーされた。

o In Section 7.5, text has been added on method-specific behavior,
providing guidance on how EAP method-specific integrity checks
should be processed. Where possible, it is desirable for a
method-specific MIC to be computed over the entire EAP packet,
including the EAP layer header (Code, Identifier, Length) and EAP
method layer header (Type, Type-Data).
Section 7.5では、EAPメソッド固有の完全性チェックが実施されるかについての方針をメソッド固有の動作に追加された。
可能な場合、EAPレイヤヘッダー(Code、Identifier、Length)とEAPメソッドレイヤのヘッダー(Type、Type-Data)を含む全体のEAPパケットで計算されることがメソッド固有のMICに関して望ましい。

o In Section 7.14 the security risks involved in use of cleartext
passwords with EAP are described.
Section 7.14ではEAPの平文のパスワードの使用に関するセキュリティリスクについて説明される。

o In Section 7.15 text has been added relating to detection of rogue
NAS behavior.
Section 7.15では、不正なNASの動作の検知に関して追加された。

Aboba, et al. Standards Track [Page 66]

RFC 3748 EAP June 2004

Full Copyright Statement

Copyright (C) The Internet Society (2004). 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.

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.

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.

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.

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.

Acknowledgement

Funding for the RFC Editor function is currently provided by the
Internet Society.

Aboba, et al. Standards Track [Page 67]

「RFC3748」をウィキ内検索

最終更新：2014年05月18日 02:06

今日	- 人
昨日	- 人
合計	- 人

Codeまとめby長谷川

メニュー

リンク

他のサービス

カウンター

更新履歴

RFC3748