[要約] RFC 3580は、IEEE 802.1XのRADIUSの使用ガイドラインを提供しています。このRFCの目的は、リモート認証ダイヤルインユーザーサービス（RADIUS）を使用してIEEE 802.1X認証を実装するための指針を提供することです。
Network Working Group P. Congdon
Request for Comments: 3580 Hewlett Packard Company
Category: Informational B. Aboba
Microsoft
A. Smith
Trapeze Networks
G. Zorn
Cisco Systems
J. Roese
Enterasys
September 2003
IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines
IEEE 802.1Xリモート認証ダイヤルインユーザーサービス（RADIUS）の使用ガイドライン
Status of this Memo
本文書の状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準も規定していません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（C）The Internet Society（2003）。全著作権所有。
Abstract
概要
This document provides suggestions on Remote Authentication Dial In User Service (RADIUS) usage by IEEE 802.1X Authenticators. The material in this document is also included within a non-normative Appendix within the IEEE 802.1X specification, and is being presented as an IETF RFC for informational purposes.
このドキュメントでは、IEEE 802.1Xオーセンティケーターによるリモート認証ダイヤルインユーザーサービス（RADIUS）の使用に関する提案を提供します。このドキュメントの内容は、IEEE 802.1X仕様内の非規範的な付録にも含まれており、情報目的でIETF RFCとして提示されています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology. . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language. . . . . . . . . . . . . . . . . . 4
2. RADIUS Accounting Attributes . . . . . . . . . . . . . . . . . 5
2.1. Acct-Terminate-Cause . . . . . . . . . . . . . . . . . . 5
2.2. Acct-Multi-Session-Id. . . . . . . . . . . . . . . . . . 6
2.3. Acct-Link-Count. . . . . . . . . . . . . . . . . . . . . 7
3. RADIUS Authentication. . . . . . . . . . . . . . . . . . . . . 7
3.1. User-Name. . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. User-Password, CHAP-Password, CHAP-Challenge . . . . . . 8
3.3. NAS-IP-Address, NAS-IPv6-Address . . . . . . . . . . . . 8
3.4. NAS-Port . . . . . . . . . . . . . . . . . . . . . . . . 8
3.5. Service-Type . . . . . . . . . . . . . . . . . . . . . . 8
3.6. Framed-Protocol. . . . . . . . . . . . . . . . . . . . . 9
3.7. Framed-IP-Address, Framed-IP-Netmask . . . . . . . . . . 9
3.8. Framed-Routing . . . . . . . . . . . . . . . . . . . . . 9
3.9. Filter-ID. . . . . . . . . . . . . . . . . . . . . . . . 9
3.10. Framed-MTU . . . . . . . . . . . . . . . . . . . . . . . 9
3.11. Framed-Compression . . . . . . . . . . . . . . . . . . . 10
3.12. Displayable Messages . . . . . . . . . . . . . . . . . . 10
3.13. Callback-Number, Callback-ID . . . . . . . . . . . . . . 10
3.14. Framed-Route, Framed-IPv6-Route. . . . . . . . . . . . . 11
3.15. State, Class, Proxy-State. . . . . . . . . . . . . . . . 11
3.16. Vendor-Specific. . . . . . . . . . . . . . . . . . . . . 11
3.17. Session-Timeout. . . . . . . . . . . . . . . . . . . . . 11
3.18. Idle-Timeout . . . . . . . . . . . . . . . . . . . . . . 12
3.19. Termination-Action . . . . . . . . . . . . . . . . . . . 12
3.20. Called-Station-Id. . . . . . . . . . . . . . . . . . . . 12
3.21. Calling-Station-Id . . . . . . . . . . . . . . . . . . . 12
3.22. NAS-Identifier . . . . . . . . . . . . . . . . . . . . . 12
3.23. NAS-Port-Type. . . . . . . . . . . . . . . . . . . . . . 12
3.24. Port-Limit . . . . . . . . . . . . . . . . . . . . . . . 13
3.25. Password-Retry . . . . . . . . . . . . . . . . . . . . . 13
3.26. Connect-Info . . . . . . . . . . . . . . . . . . . . . . 13
3.27. EAP-Message. . . . . . . . . . . . . . . . . . . . . . . 13
3.28. Message-Authenticator. . . . . . . . . . . . . . . . . . 13
3.29. NAS-Port-Id. . . . . . . . . . . . . . . . . . . . . . . 13
3.30. Framed-Pool, Framed-IPv6-Pool. . . . . . . . . . . . . . 14
3.31. Tunnel Attributes. . . . . . . . . . . . . . . . . . . . 14
4. RC4 EAPOL-Key Descriptor . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 18
5.1. Packet Modification or Forgery . . . . . . . . . . . . . 18
5.2. Dictionary Attacks . . . . . . . . . . . . . . . . . . . 19
5.3. Known Plaintext Attacks. . . . . . . . . . . . . . . . . 19
5.4. Replay . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.5. Outcome Mismatches . . . . . . . . . . . . . . . . . . . 20
5.6. 802.11 Integration . . . . . . . . . . . . . . . . . . . 20
5.7. Key Management Issues. . . . . . . . . . . . . . . . . . 21
6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 22
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Normative References . . . . . . . . . . . . . . . . . . 22
7.2. Informative References . . . . . . . . . . . . . . . . . 23
8. Table of Attributes. . . . . . . . . . . . . . . . . . . . . . 25
9. Intellectual Property Statement . . . . . . . . . . . . . . . 28
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 30
IEEE 802.1X enables authenticated access to IEEE 802 media, including Ethernet, Token Ring, and 802.11 wireless LANs. Although Remote Authentication Dial In User Service (RADIUS) support is optional within IEEE 802.1X, it is expected that many IEEE 802.1X Authenticators will function as RADIUS clients.
IEEE 802.1Xは、イーサネット、トークンリング、802.11ワイヤレスLANなどのIEEE 802メディアへの認証されたアクセスを可能にします。 IEEE 802.1Xでは、リモート認証ダイヤルインユーザーサービス（RADIUS）のサポートはオプションですが、多くのIEEE 802.1XオーセンティケーターがRADIUSクライアントとして機能することが期待されています。
IEEE 802.1X [IEEE8021X] provides "network port authentication" for IEEE 802 [IEEE802] media, including Ethernet [IEEE8023], Token Ring and 802.11 [IEEE80211] wireless LANS.
IEEE 802.1X [IEEE8021X]は、イーサネット[IEEE8023]、トークンリング、802.11 [IEEE80211]ワイヤレスLANなどのIEEE 802 [IEEE802]メディアに「ネットワークポート認証」を提供します。
IEEE 802.1X does not require use of a backend Authentication Server, and thus can be deployed with stand-alone bridges or Access Points, as well as in centrally managed scenarios.
IEEE 802.1Xではバックエンド認証サーバーを使用する必要がないため、スタンドアロンブリッジやアクセスポイント、および集中管理シナリオで展開できます。
In situations where it is desirable to centrally manage authentication, authorization and accounting (AAA) for IEEE 802 networks, deployment of a backend authentication and accounting server is desirable. In such situations, it is expected that IEEE 802.1X Authenticators will function as AAA clients.
IEEE 802ネットワークの認証、承認、およびアカウンティング（AAA）を集中管理することが望ましい状況では、バックエンドの認証およびアカウンティングサーバーの展開が望ましいです。このような状況では、IEEE 802.1XオーセンティケーターがAAAクライアントとして機能することが期待されます。
This document provides suggestions on RADIUS usage by IEEE 802.1X Authenticators. Support for any AAA protocol is optional for IEEE 802.1X Authenticators, and therefore this specification has been incorporated into a non-normative Appendix within the IEEE 802.1X specification.
このドキュメントでは、IEEE 802.1XオーセンティケーターによるRADIUSの使用に関する提案を提供します。 IEEE 802.1XオーセンティケーターのAAAプロトコルのサポートはオプションであるため、この仕様はIEEE 802.1X仕様内の非規範的な付録に組み込まれています。
This document uses the following terms:
このドキュメントでは、次の用語を使用します。
Access Point (AP) A Station that provides access to the distribution services via the wireless medium for associated Stations.
アクセスポイント（AP）関連付けられたステーションにワイヤレスメディアを介して配信サービスへのアクセスを提供するステーション。
Association The service used to establish Access Point/Station mapping and enable Station invocation of the distribution system services.
アソシエーションアクセスポイント/ステーションのマッピングを確立し、ステーションによる配信システムサービスの呼び出しを可能にするために使用されるサービス。
Authenticator An Authenticator is an entity that requires authentication from the Supplicant. The Authenticator may be connected to the Supplicant at the other end of a point-to-point LAN segment or 802.11 wireless link.
オーセンティケータオーセンティケータは、サプリカントからの認証を必要とするエンティティです。オーセンティケータは、ポイントツーポイントLANセグメントまたは802.11ワイヤレスリンクのもう一方の端でサプリカントに接続できます。
Authentication Server An Authentication Server is an entity that provides an Authentication Service to an Authenticator. This service verifies, from the credentials provided by the Supplicant, the claim of identity made by the Supplicant.
認証サーバー認証サーバーは、オーセンティケーターに認証サービスを提供するエンティティです。このサービスは、サプリカントによって提供された資格情報から、サプリカントによって作成されたアイデンティティの主張を検証します。
Port Access Entity (PAE) The protocol entity associated with a physical or virtual (802.11) Port. A given PAE may support the protocol functionality associated with the Authenticator, Supplicant or both.
Port Access Entity（PAE）物理または仮想（802.11）ポートに関連付けられたプロトコルエンティティ。特定のPAEは、オーセンティケータ、サプリカント、またはその両方に関連するプロトコル機能をサポートする場合があります。
Station (STA) Any device that contains an IEEE 802.11 conformant medium access control (MAC) and physical layer (PHY) interface to the wireless medium (WM).
ステーション（STA）ワイヤレスメディア（WM）へのIEEE 802.11準拠のメディアアクセス制御（MAC）および物理層（PHY）インターフェイスを含むデバイス。
Supplicant A Supplicant is an entity that is being authenticated by an Authenticator. The Supplicant may be connected to the Authenticator at one end of a point-to-point LAN segment or 802.11 wireless link.
サプリカントサプリカントは、オーセンティケータによって認証されているエンティティです。サプリカントは、ポイントツーポイントLANセグメントまたは802.11ワイヤレスリンクの一端でオーセンティケータに接続できます。
In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントでは、仕様の要件を示すためにいくつかの単語が使用されています。これらの単語は、多くの場合大文字です。このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
With a few exceptions, the RADIUS accounting attributes defined in [RFC2866], [RFC2867], and [RFC2869] have the same meaning within IEEE 802.1X sessions as they do in dialup sessions and therefore no additional commentary is needed.
いくつかの例外はありますが、[RFC2866]、[RFC2867]、および[RFC2869]で定義されているRADIUSアカウンティング属性は、IEEE 802.1Xセッション内ではダイヤルアップセッションと同じ意味を持つため、追加の説明は必要ありません。
Attributes requiring more discussion include:
さらに議論が必要な属性は次のとおりです。
Acct-Terminate-Cause Acct-Multi-Session-Id Acct-Link-Count
Acct-Terminate-Cause Acct-Multi-Session-Id Acct-Link-Count
This attribute indicates how the session was terminated, as described in [RFC2866]. [IEEE8021X] defines the following termination cause values, which are shown with their RADIUS equivalents in the table on the next page.
この属性は、[RFC2866]で説明されているように、セッションがどのように終了したかを示します。 [IEEE8021X]は、次の終了原因の値を定義しています。これらの値は、次のページの表に同等のRADIUS値とともに示されています。
IEEE 802.1X RADIUS
dot1xAuthSessionTerminateCause Acct-Terminate-Cause
Value Value
------------- --------------------
SupplicantLogoff(1) User Request (1)
portFailure(2) Lost Carrier (2)
SupplicantRestart(3) Supplicant Restart (19)
reauthFailed(4) Reauthentication Failure (20)
authControlForceUnauth(5) Admin Reset (6)
portReInit(6) Port Reinitialized (21)
portAdminDisabled(7) Port Administratively Disabled (22)
notTerminatedYet(999) N/A
When using this attribute, the User Request (1) termination cause corresponds to the situation in which the session terminated due to an EAPOL-Logoff received from the Supplicant. When a session is moved due to roaming, the EAPOL state machines will treat this as a Supplicant Logoff.
この属性を使用する場合、ユーザー要求（1）の終了原因は、サプリカントから受信したEAPOL-Logoffが原因でセッションが終了した状況に対応します。ローミングのためにセッションが移動すると、EAPOLステートマシンはこれをサプリカントログオフとして扱います。
A Lost Carrier (2) termination cause indicates session termination due to loss of physical connectivity for reasons other than roaming between Access Points. For example, if the Supplicant disconnects a point-to-point LAN connection, or moves out of range of an Access Point, this termination cause is used. Lost Carrier (2) therefore equates to a Port Disabled condition in the EAPOL state machines.
Lost Carrier（2）終了原因は、アクセスポイント間のローミング以外の理由で物理接続が失われたためにセッションが終了したことを示します。たとえば、サプリカントがポイントツーポイントLAN接続を切断した場合、またはアクセスポイントの範囲外に移動した場合、この終了原因が使用されます。したがって、Lost Carrier（2）は、EAPOLステートマシンのポート無効状態に相当します。
A Supplicant Restart (19) termination cause indicates re-initialization of the Supplicant state machines.
サプリカントの再起動（19）終了原因は、サプリカントステートマシンの再初期化を示します。
A Reauthentication Failure (20) termination cause indicates that a previously authenticated Supplicant has failed to re-authenticate successfully following expiry of the re-authentication timer or explicit re-authentication request by management action.
Reauthentication Failure（20）終了原因は、以前に認証されたサプリカントが、管理アクションによる再認証タイマーまたは明示的な再認証要求の期限切れの後に、正常に再認証できなかったことを示します。
Within [IEEE80211], periodic re-authentication may be useful in preventing reuse of an initialization vector with a given key. Since successful re-authentication does not result in termination of the session, accounting packets are not sent as a result of re-authentication unless the status of the session changes. For example:
[IEEE80211]内では、定期的な再認証は、指定されたキーを持つ初期化ベクトルの再利用を防ぐのに役立ちます。再認証が成功してもセッションは終了しないため、セッションのステータスが変化しない限り、再認証の結果としてアカウンティングパケットは送信されません。例えば：
a. The session is terminated due to re-authentication failure. In this case the Reauthentication Failure (20) termination cause is used.
a. 再認証の失敗により、セッションが終了しました。この場合、再認証失敗（20）終了原因が使用されます。
b. The authorizations are changed as a result of a successful re-authentication. In this case, the Service Unavailable (15) termination cause is used. For accounting purposes, the portion of the session after the authorization change is treated as a separate session.
b. 再認証が成功した結果、認証が変更されます。この場合、Service Unavailable（15）終了原因が使用されます。アカウンティングのために、許可変更後のセッションの部分は、別個のセッションとして扱われます。
Where IEEE 802.1X authentication occurs prior to association, accounting packets are not sent until an association occurs.
アソシエーションの前にIEEE 802.1X認証が発生する場合、アソシエーションが発生するまでアカウンティングパケットは送信されません。
An Admin Reset (6) termination cause indicates that the Port has been administratively forced into the unauthorized state.
管理リセット（6）終了原因は、ポートが管理上無許可の状態に強制されたことを示します。
A Port Reinitialized (21) termination cause indicates that the Port's MAC has been reinitialized.
ポートの再初期化（21）終了原因は、ポートのMACが再初期化されたことを示します。
A Port Administratively Disabled (22) termination cause indicates that the Port has been administratively disabled.
ポートが管理上無効（22）の終了原因は、ポートが管理上無効になっていることを示します。
The purpose of this attribute is to make it possible to link together multiple related sessions. While [IEEE8021X] does not act on aggregated ports, it is possible for a Supplicant roaming between Access Points to cause multiple RADIUS accounting packets to be sent by different Access Points.
この属性の目的は、関連する複数のセッションをリンクできるようにすることです。 [IEEE8021X]は集約ポートでは機能しませんが、アクセスポイント間でローミングするサプリカントが、複数のRADIUSアカウンティングパケットを異なるアクセスポイントから送信させる可能性があります。
Where supported by the Access Points, the Acct-Multi-Session-Id attribute can be used to link together the multiple related sessions of a roaming Supplicant. In such a situation, if the session context is transferred between Access Points, accounting packets MAY be sent without a corresponding authentication and authorization exchange, provided that Association has occurred. However, in such a situation it is assumed that the Acct-Multi-Session-Id is transferred between the Access Points as part of the Inter-Access Point Protocol (IAPP).
アクセスポイントでサポートされている場合、Acct-Multi-Session-Id属性を使用して、ローミングサプリカントの複数の関連セッションをリンクできます。そのような状況で、セッションコンテキストがアクセスポイント間で転送される場合、アソシエーションが発生していれば、対応する認証と承認の交換なしにアカウンティングパケットを送信できます。ただし、このような状況では、Acct-Multi-Session-Idがアクセスポイント間プロトコル（IAPP）の一部としてアクセスポイント間で転送されることが想定されています。
If the Acct-Multi-Session-Id were not unique between Access Points, then it is possible that the chosen Acct-Multi-Session-Id will overlap with an existing value allocated on that Access Point, and the Accounting Server would therefore be unable to distinguish a roaming session from a multi-link session.
Acct-Multi-Session-Idがアクセスポイント間で一意でなかった場合、選択したAcct-Multi-Session-Idがそのアクセスポイントに割り当てられた既存の値と重複する可能性があるため、アカウンティングサーバーはローミングセッションとマルチリンクセッションを区別します。
As a result, the Acct-Multi-Session-Id attribute is unique among all the bridges or Access Points, Supplicants and sessions. In order to provide this uniqueness, it is suggested that the Acct-Multi-Session-Id be of the form:
その結果、Acct-Multi-Session-Id属性は、すべてのブリッジまたはアクセスポイント、サプリカント、およびセッション間で一意です。この一意性を提供するには、Acct-Multi-Session-Idを次の形式にすることをお勧めします。
Original AP MAC Address | Supplicant MAC Address | NTP Timestamp
元のAP MACアドレス|サプリカントMACアドレス| NTPタイムスタンプ
Here "|" represents concatenation, the original AP MAC Address is the MAC address of the bridge or Access Point at which the session started, and the 64-bit NTP timestamp indicates the beginning of the original session. In order to provide for consistency of the Acct-Multi-Session-Id between roaming sessions, the Acct-Multi-Session-Id may be moved between Access Points as part of IAPP or another handoff scheme.
ここに「|」連結を表します。元のAP MACアドレスは、セッションが開始したブリッジまたはアクセスポイントのMACアドレスです。64ビットのNTPタイムスタンプは、元のセッションの開始を示します。ローミングセッション間でAcct-Multi-Session-Idの一貫性を提供するために、IAPPまたは別のハンドオフ方式の一部としてAcct-Multi-Session-Idをアクセスポイント間で移動できます。
The use of an Acct-Multi-Session-Id of this form guarantees uniqueness among all Access Points, Supplicants and sessions. Since the NTP timestamp does not wrap on reboot, there is no possibility that a rebooted Access Point could choose an Acct-Multi-Session-Id that could be confused with that of a previous session.
この形式のAcct-Multi-Session-Idを使用すると、すべてのアクセスポイント、サプリカント、およびセッション間の一意性が保証されます。 NTPタイムスタンプは再起動時に折り返されないため、再起動されたアクセスポイントが前のセッションのものと混同される可能性のあるAcct-Multi-Session-Idを選択する可能性はありません。
Since the Acct-Multi-Session-Id is of type String as defined in [RFC2866], for use with IEEE 802.1X, it is encoded as an ASCII string of Hex digits. Example: "00-10-A4-23-19-C0-00-12-B2- 14-23-DE-AF-23-83-C0-76-B8-44-E8"
Acct-Multi-Session-Idは、[RFC2866]で定義されているString型であるため、IEEE 802.1Xで使用するために、16進数のASCII文字列としてエンコードされます。例：「00-10-A4-23-19-C0-00-12-B2- 14-23-DE-AF-23-83-C0-76-B8-44-E8」
The Acct-Link-Count attribute may be used to account for the number of ports that have been aggregated.
Account-Link-Count属性を使用して、集約されたポートの数を明らかにすることができます。
This section describes how attributes defined in [RFC2865], [RFC2867], [RFC2868], [RFC2869], [RFC3162] and [RFC3579] are used in IEEE 802.1X authentication.
このセクションでは、[RFC2865]、[RFC2867]、[RFC2868]、[RFC2869]、[RFC3162]、および[RFC3579]で定義された属性がIEEE 802.1X認証でどのように使用されるかについて説明します。
In IEEE 802.1X, the Supplicant typically provides its identity via an EAP-Response/Identity message. Where available, the Supplicant identity is included in the User-Name attribute, and included in the RADIUS Access-Request and Access-Reply messages as specified in [RFC2865] and [RFC3579].
IEEE 802.1Xでは、サプリカントは通常、EAP-Response / Identityメッセージを介してIDを提供します。利用可能な場合、サプリカントIDはユーザー名属性に含まれ、[RFC2865]および[RFC3579]で指定されているように、RADIUS Access-RequestおよびAccess-Replyメッセージに含まれます。
Alternatively, as discussed in [RFC3579] Section 2.1., the User-Name attribute may contain the Calling-Station-ID value, which is set to the Supplicant MAC address.
あるいは、[RFC3579]セクション2.1で説明されているように、User-Name属性には、サプリカントMACアドレスに設定されたCalling-Station-ID値が含まれる場合があります。
Since IEEE 802.1X does not support PAP or CHAP authentication, the User-Password, CHAP-Password or CHAP-Challenge attributes are not used by IEEE 802.1X Authenticators acting as RADIUS clients.
IEEE 802.1XはPAPまたはCHAP認証をサポートしていないため、RADIUSクライアントとして機能するIEEE 802.1Xオーセンティケーターでは、ユーザーパスワード、CHAPパスワード、またはCHAPチャレンジ属性は使用されません。
For use with IEEE 802.1X, the NAS-IP-Address contains the IPv4 address of the bridge or Access Point acting as an Authenticator, and the NAS-IPv6-Address contains the IPv6 address. If the IEEE 802.1X Authenticator has more than one interface, it may be desirable to use a loopback address for this purpose so that the Authenticator will still be reachable even if one of the interfaces were to fail.
IEEE 802.1Xで使用する場合、NAS-IP-Addressにはオーセンティケーターとして機能するブリッジまたはアクセスポイントのIPv4アドレスが含まれ、NAS-IPv6-AddressにはIPv6アドレスが含まれます。 IEEE 802.1X Authenticatorに複数のインターフェイスがある場合は、この目的でループバックアドレスを使用して、インターフェイスの1つに障害が発生した場合でも、Authenticatorに到達できるようにすることが望ましい場合があります。
For use with IEEE 802.1X the NAS-Port will contain the port number of the bridge, if this is available. While an Access Point does not have physical ports, a unique "association ID" is assigned to every mobile Station upon a successful association exchange. As a result, for an Access Point, if the association exchange has been completed prior to authentication, the NAS-Port attribute will contain the association ID, which is a 16-bit unsigned integer. Where IEEE 802.1X authentication occurs prior to association, a unique NAS-Port value may not be available.
IEEE 802.1Xで使用する場合、使用可能な場合、NASポートにはブリッジのポート番号が含まれます。アクセスポイントには物理ポートがありませんが、関連付けの交換が成功すると、すべてのモバイルステーションに一意の「関連付けID」が割り当てられます。その結果、アクセスポイントの場合、認証の前にアソシエーションの交換が完了していると、NAS-Port属性には、16ビットの符号なし整数であるアソシエーションIDが含まれます。アソシエーションの前にIEEE 802.1X認証が行われる場合、一意のNAS-Port値を使用できない場合があります。
For use with IEEE 802.1X, the Framed (2), Authenticate Only (8), and Call Check (10) values are most commonly used.
IEEE 802.1Xで使用するには、Framed（2）、Authenticate Only（8）、およびCall Check（10）の値が最も一般的に使用されます。
A Service-Type of Framed indicates that appropriate 802 framing should be used for the connection. A Service-Type of Authenticate Only (8) indicates that no authorization information needs to be returned in the Access-Accept. As described in [RFC2865], a Service-Type of Call Check is included in an Access-Request packet to request that the RADIUS server accept or reject the connection attempt, typically based on the Called-Station-ID (set to the bridge or Access Point MAC address) or Calling-Station-ID attributes (set to the Supplicant MAC address). As noted in [RFC2865], it is recommended that in this case, the User-Name attribute be given the value of Calling-Station-Id.
Service-Type of Framedは、接続に適切な802フレーミングを使用する必要があることを示します。 Authenticate Only（8）のService-Typeは、Access-Acceptで認証情報を返す必要がないことを示します。 [RFC2865]で説明されているように、Service-Type of Call CheckはAccess-Requestパケットに含まれており、通常はCalled-Station-ID（ブリッジまたはアクセスポイントMACアドレス）またはCalling-Station-ID属性（サプリカントMACアドレスに設定）。 [RFC2865]に記載されているように、この場合、User-Name属性にCalling-Station-Idの値を指定することをお勧めします。
Since there is no value for IEEE 802 media, the Framed-Protocol attribute is not used by IEEE 802.1X Authenticators.
IEEE 802メディアには値がないため、Framed-Protocol属性はIEEE 802.1Xオーセンティケーターでは使用されません。
IEEE 802.1X does not provide a mechanism for IP address assignment. Therefore the Framed-IP-Address and Framed-IP-Netmask attributes can only be used by IEEE 802.1X Authenticators that support IP address assignment mechanisms. Typically this capability is supported by layer 3 devices.
IEEE 802.1Xは、IPアドレス割り当てのメカニズムを提供しません。したがって、Framed-IP-AddressおよびFramed-IP-Netmask属性は、IPアドレス割り当てメカニズムをサポートするIEEE 802.1Xオーセンティケーターのみが使用できます。通常、この機能はレイヤー3デバイスでサポートされています。
The Framed-Routing attribute indicates the routing method for the Supplicant. It is therefore only relevant for IEEE 802.1X Authenticators that act as layer 3 devices, and cannot be used by a bridge or Access Point.
Framed-Routing属性は、サプリカントのルーティング方法を示します。したがって、これはレイヤー3デバイスとして機能するIEEE 802.1Xオーセンティケーターにのみ関連し、ブリッジまたはアクセスポイントでは使用できません。
This attribute indicates the name of the filter list to be applied to the Supplicant's session. For use with an IEEE 802.1X Authenticator, it may be used to indicate either layer 2 or layer 3 filters. Layer 3 filters are typically only supported on IEEE 802.1X Authenticators that act as layer 3 devices.
この属性は、サプリカントのセッションに適用されるフィルターリストの名前を示します。 IEEE 802.1X Authenticatorで使用する場合、レイヤー2またはレイヤー3フィルターを示すために使用できます。レイヤー3フィルターは、通常、レイヤー3デバイスとして機能するIEEE 802.1Xオーセンティケーターでのみサポートされます。
This attribute indicates the maximum size of an IP packet that may be transmitted over the wire between the Supplicant and the Authenticator. IEEE 802.1X Authenticators set this to the value corresponding to the relevant 802 medium, and include it in the RADIUS Access-Request. The RADIUS server may send an EAP packet as large as Framed-MTU minus four (4) octets, taking into account the additional overhead for the IEEE 802.1X Version (1), Type (1) and Body Length (2) fields. For EAP over IEEE 802 media, the Framed-MTU values (which do not include LLC/SNAP overhead) and maximum frame length values (not including the preamble) are as follows:
この属性は、サプリカントとオーセンティケータの間のワイヤを介して送信できるIPパケットの最大サイズを示します。 IEEE 802.1X Authenticatorsは、これを関連する802メディアに対応する値に設定し、RADIUS Access-Requestに含めます。 RADIUSサーバーは、IEEE 802.1Xバージョン（1）、タイプ（1）、およびボディ長（2）フィールドの追加のオーバーヘッドを考慮して、Framed-MTUから4オクテットを差し引いた大きさのEAPパケットを送信できます。 EAP over IEEE 802メディアの場合、Framed-MTU値（LLC / SNAPオーバーヘッドを含まない）と最大フレーム長値（プリアンブルを含まない）は次のとおりです。
Maximum Frame
Media Framed-MTU Length
========= =============== ==============
Ethernet 1500 1522
802.3 1500 1522
802.4 8174 8193
802.5 (4 Mbps) 4528 4550
802.5 (16 Mbps) 18173 18200
802.5 (100 Mb/s) 18173 18200
802.6 9191 9240
802.9a 1500 1518
802.11 2304 2346
802.12 (Ethernet) 1500 1518
802.12 (Token Ring) 4502 4528
FDDI 4479 4500
NOTE - the Framed-MTU size for IEEE 802.11 media may change as a result of ongoing work being undertaken in the IEEE 802.11 Working Group. Since some 802.11 stations cannot handle an MTU larger than 1500 octets, it is recommended that RADIUS servers encountering a NAS-Port-Type value of 802.11 send EAP packets no larger than 1496 octets.
注-IEEE 802.11メディアのFramed-MTUサイズは、IEEE 802.11ワーキンググループで進行中の作業の結果として変更される場合があります。一部の802.11ステーションは1500オクテットを超えるMTUを処理できないため、802.11のNAS-Port-Type値に遭遇するRADIUSサーバーは、1496オクテット以下のEAPパケットを送信することをお勧めします。
[IEEE8021X] does not include compression support. Therefore this attribute is not understood by [IEEE8021X] Authenticators.
[IEEE8021X]は圧縮サポートを含みません。したがって、この属性は[IEEE8021X]オーセンティケーターでは理解されません。
The Reply-Message attribute, defined in section 5.18 of [RFC2865], indicates text which may be displayed to the user. This is similar in concept to the EAP Notification Type, defined in [RFC2284]. As noted in [RFC3579], Section 2.6.5, when sending a displayable message to an [IEEE8021X] Authenticator, displayable messages are best sent within EAP-Message/EAP-Request/Notification attribute(s), and not within Reply-Message attribute(s).
[RFC2865]のセクション5.18で定義されているReply-Message属性は、ユーザーに表示されるテキストを示します。これは、[RFC2284]で定義されているEAP通知タイプと概念が似ています。 [RFC3579]のセクション2.6.5に記載されているように、表示可能なメッセージを[IEEE8021X]オーセンティケーターに送信する場合、表示可能なメッセージはEAP-Message / EAP-Request / Notification属性内で送信され、Reply-Message内では送信されないのが最適です。属性。
These attributes are not understood by IEEE 802.1X Authenticators.
これらの属性は、IEEE 802.1Xオーセンティケーターでは認識されません。
The Framed-Route and Framed-IPv6-Route attributes provide routes that are to be configured for the Supplicant. These attributes are therefore only relevant for IEEE 802.1X Authenticators that act as layer 3 devices, and cannot be understood by a bridge or Access Point.
Framed-RouteおよびFramed-IPv6-Route属性は、サプリカントに設定されるルートを提供します。したがって、これらの属性は、レイヤー3デバイスとして機能するIEEE 802.1Xオーセンティケーターにのみ関連し、ブリッジまたはアクセスポイントでは理解できません。
These attributes are used for the same purposes as described in [RFC2865].
これらの属性は、[RFC2865]で説明されているのと同じ目的で使用されます。
Vendor-specific attributes are used for the same purposes as described in [RFC2865]. The MS-MPPE-Send-Key and MS-MPPE-Recv-Key attributes, described in section 2.4 of [RFC2548], MAY be used to encrypt and authenticate the RC4 EAPOL-Key descriptor [IEEE8021X, Section 7.6]. Examples of the derivation of the MS-MPPE-Send-Key and MS-MPPE-Recv-Key attributes from the master key negotiated by an EAP method are given in [RFC2716]. Details of the EAPOL-Key descriptor are provided in Section 4.
ベンダー固有の属性は、[RFC2865]で説明されているのと同じ目的で使用されます。 [RFC2548]のセクション2.4で説明されているMS-MPPE-Send-KeyおよびMS-MPPE-Recv-Key属性は、RC4 EAPOL-Key記述子の暗号化と認証に使用できます[IEEE8021X、セクション7.6]。 EAPメソッドによってネゴシエートされたマスターキーからのMS-MPPE-Send-KeyおよびMS-MPPE-Recv-Key属性の派生の例は、[RFC2716]で提供されています。 EAPOL-Key記述子の詳細については、セクション4で説明します。
When sent along in an Access-Accept without a Termination-Action attribute or with a Termination-Action attribute set to Default, the Session-Timeout attribute specifies the maximum number of seconds of service provided prior to session termination.
Termination-Action属性なしで、またはTermination-Action属性がDefaultに設定されてAccess-Acceptで送信される場合、Session-Timeout属性は、セッション終了前に提供されるサービスの最大秒数を指定します。
When sent in an Access-Accept along with a Termination-Action value of RADIUS-Request, the Session-Timeout attribute specifies the maximum number of seconds of service provided prior to re-authentication. In this case, the Session-Timeout attribute is used to load the reAuthPeriod constant within the Reauthentication Timer state machine of 802.1X. When sent with a Termination-Action value of RADIUS-Request, a Session-Timeout value of zero indicates the desire to perform another authentication (possibly of a different type) immediately after the first authentication has successfully completed.
RADIUS-RequestのTermination-Action値とともにAccess-Acceptで送信される場合、Session-Timeout属性は、再認証の前に提供されるサービスの最大秒数を指定します。この場合、Session-Timeout属性を使用して、802.1Xの再認証タイマーステートマシン内にreAuthPeriod定数をロードします。 Termination-Action値がRADIUS-Requestで送信された場合、Session-Timeout値がゼロの場合、最初の認証が正常に完了した直後に別の認証（おそらく別のタイプ）を実行したいことを示します。
When sent in an Access-Challenge, this attribute represents the maximum number of seconds that an IEEE 802.1X Authenticator should wait for an EAP-Response before retransmitting. In this case, the Session-Timeout attribute is used to load the suppTimeout constant within the backend state machine of IEEE 802.1X.
Access-Challengeで送信される場合、この属性は、IEEE 802.1XオーセンティケーターがEAP-Responseを待ってから再送信するまでの最大秒数を表します。この場合、Session-Timeout属性を使用して、IEEE 802.1Xのバックエンドステートマシン内にsuppTimeout定数を読み込みます。
The Idle-Timeout attribute is described in [RFC2865]. For IEEE 802 media other than 802.11 the media are always on. As a result the Idle-Timeout attribute is typically only used with wireless media such as IEEE 802.11. It is possible for a wireless device to wander out of range of all Access Points. In this case, the Idle-Timeout attribute indicates the maximum time that a wireless device may remain idle.
Idle-Timeout属性は[RFC2865]で説明されています。 802.11以外のIEEE 802メディアの場合、メディアは常にオンです。その結果、Idle-Timeout属性は通常、IEEE 802.11などのワイヤレスメディアでのみ使用されます。ワイヤレスデバイスがすべてのアクセスポイントの範囲外に移動する可能性があります。この場合、Idle-Timeout属性は、ワイヤレスデバイスがアイドル状態を維持できる最大時間を示します。
This attribute indicates what action should be taken when the service is completed. The value RADIUS-Request (1) indicates that re-authentication should occur on expiration of the Session-Time. The value Default (0) indicates that the session should terminate.
この属性は、サービスが完了したときに実行する必要があるアクションを示します。値RADIUS-Request（1）は、Session-Timeの満了時に再認証が発生することを示します。値Default（0）は、セッションを終了する必要があることを示します。
For IEEE 802.1X Authenticators, this attribute is used to store the bridge or Access Point MAC address in ASCII format (upper case only), with octet values separated by a "-". Example: "00-10-A4-23-19-C0". In IEEE 802.11, where the SSID is known, it SHOULD be appended to the Access Point MAC address, separated from the MAC address with a ":". Example "00-10-A4-23-19-C0:AP1".
IEEE 802.1Xオーセンティケーターの場合、この属性は、「-」で区切られたオクテット値を持つASCII形式（大文字のみ）でブリッジまたはアクセスポイントのMACアドレスを格納するために使用されます。例：「00-10-A4-23-19-C0」。 SSIDがわかっているIEEE 802.11では、アクセスポイントのMACアドレスに「：」で区切って追加する必要があります（SHOULD）。例 "00-10-A4-23-19-C0：AP1"。
For IEEE 802.1X Authenticators, this attribute is used to store the Supplicant MAC address in ASCII format (upper case only), with octet values separated by a "-". Example: "00-10-A4-23-19-C0".
IEEE 802.1Xオーセンティケーターの場合、この属性はサプリカントMACアドレスをASCII形式（大文字のみ）で格納するために使用され、オクテット値は「-」で区切られます。例：「00-10-A4-23-19-C0」。
This attribute contains a string identifying the IEEE 802.1X Authenticator originating the Access-Request.
この属性には、Access-Requestを発信するIEEE 802.1Xオーセンティケーターを識別する文字列が含まれています。
For use with IEEE 802.1X, NAS-Port-Type values of Ethernet (15) Wireless - IEEE 802.11 (19), Token Ring (20) and FDDI (21) may be used.
IEEE 802.1Xで使用する場合、Ethernet（15）ワイヤレス-IEEE 802.11（19）、トークンリング（20）、およびFDDI（21）のNAS-Port-Type値を使用できます。
This attribute has no meaning when sent to an [IEEE8021X] Authenticator.
この属性は、[IEEE8021X]オーセンティケーターに送信される場合は意味がありません。
In IEEE 802.1X, the Authenticator always transitions to the HELD state after an authentication failure. Thus this attribute does not make sense for IEEE 802.1X.
IEEE 802.1Xでは、オーセンティケーターは、認証の失敗後に常にHELD状態に移行します。したがって、この属性はIEEE 802.1Xでは意味がありません。
This attribute is sent by a bridge or Access Point to indicate the nature of the Supplicant's connection. When sent in the Access-Request it is recommended that this attribute contain information on the speed of the Supplicant's connection. For 802.11, the following format is recommended: "CONNECT 11Mbps 802.11b". If sent in the Accounting STOP, this attribute may be used to summarize statistics relating to session quality. For example, in IEEE 802.11, the Connect-Info attribute may contain information on the number of link layer retransmissions. The exact format of this attribute is implementation specific.
この属性は、サプリカントの接続の性質を示すためにブリッジまたはアクセスポイントによって送信されます。 Access-Requestで送信する場合、この属性にサプリカントの接続の速度に関する情報を含めることをお勧めします。 802.11の場合、「CONNECT 11Mbps 802.11b」の形式をお勧めします。アカウンティングSTOPで送信された場合、この属性を使用して、セッションの品質に関する統計を要約できます。たとえば、IEEE 802.11では、Connect-Info属性にリンク層の再送信数に関する情報が含まれている場合があります。この属性の正確な形式は実装固有です。
Since IEEE 802.1X provides for encapsulation of EAP as described in [RFC2284] and [IEEE8021X], the EAP-Message attribute defined in [RFC3579] is used to encapsulate EAP packets for transmission from the IEEE 802.1X Authenticator to the Authentication Server. [RFC3579] Section 2.2. describes how the Authentication Server handles invalid EAP packets passed to it by the Authenticator.
[RFC2284]と[IEEE8021X]で説明されているように、IEEE 802.1XはEAPのカプセル化を提供するため、[RFC3579]で定義されているEAP-Message属性を使用して、IEEE 802.1X認証システムから認証サーバーへの送信用のEAPパケットをカプセル化します。 [RFC3579]セクション2.2。では、認証サーバーが認証サーバーから渡された無効なEAPパケットを処理する方法について説明します。
As noted in [RFC3579] Section 3.1., the Message-Authenticator attribute MUST be used to protect packets within a RADIUS/EAP conversation.
[RFC3579]セクション3.1。で述べたように、RADIUS / EAP会話内のパケットを保護するには、メッセージ認証属性を使用する必要があります。
This attribute is used to identify the IEEE 802.1X Authenticator port which authenticates the Supplicant. The NAS-Port-Id differs from the NAS-Port in that it is a string of variable length whereas the NAS-Port is a 4 octet value.
この属性は、サプリカントを認証するIEEE 802.1Xオーセンティケーターポートを識別するために使用されます。 NAS-Port-Idは、可変長の文字列であるという点でNAS-Portとは異なりますが、NAS-Portは4オクテットの値です。
IEEE 802.1X does not provide a mechanism for IP address assignment. Therefore the Framed-Pool and Framed-IPv6-Pool attributes can only be used by IEEE 802.1X Authenticators that support IP address assignment mechanisms. Typically this capability is supported by layer 3 devices.
IEEE 802.1Xは、IPアドレス割り当てのメカニズムを提供しません。したがって、Framed-PoolおよびFramed-IPv6-Pool属性は、IPアドレス割り当てメカニズムをサポートするIEEE 802.1Xオーセンティケーターのみが使用できます。通常、この機能はレイヤー3デバイスでサポートされています。
Reference [RFC2868] defines RADIUS tunnel attributes used for authentication and authorization, and [RFC2867] defines tunnel attributes used for accounting. Where the IEEE 802.1X Authenticator supports tunneling, a compulsory tunnel may be set up for the Supplicant as a result of the authentication.
リファレンス[RFC2868]は認証と承認に使用されるRADIUSトンネル属性を定義し、[RFC2867]はアカウンティングに使用されるトンネル属性を定義します。 IEEE 802.1X Authenticatorがトンネリングをサポートしている場合、認証の結果として、強制的なトンネルがサプリカントに設定されます。
In particular, it may be desirable to allow a port to be placed into a particular Virtual LAN (VLAN), defined in [IEEE8021Q], based on the result of the authentication. This can be used, for example, to allow a wireless host to remain on the same VLAN as it moves within a campus network.
特に、認証の結果に基づいて、[IEEE8021Q]で定義されている特定の仮想LAN（VLAN）にポートを配置できるようにすることが望ましい場合があります。これは、たとえば、ワイヤレスホストがキャンパスネットワーク内を移動するときに同じVLANに留まることを可能にするために使用できます。
The RADIUS server typically indicates the desired VLAN by including tunnel attributes within the Access-Accept. However, the IEEE 802.1X Authenticator may also provide a hint as to the VLAN to be assigned to the Supplicant by including Tunnel attributes within the Access-Request.
RADIUSサーバーは通常、Access-Accept内にトンネル属性を含めることにより、目的のVLANを示します。ただし、IEEE 802.1X Authenticatorは、Access-Requestにトンネル属性を含めることにより、サプリカントに割り当てられるVLANに関するヒントも提供します。
For use in VLAN assignment, the following tunnel attributes are used:
VLAN割り当てで使用するために、次のトンネル属性が使用されます。
Tunnel-Type=VLAN (13) Tunnel-Medium-Type=802 Tunnel-Private-Group-ID=VLANID
Tunnel-Type = VLAN（13）Tunnel-Medium-Type = 802 Tunnel-Private-Group-ID = VLANID
Note that the VLANID is 12-bits, taking a value between 1 and 4094, inclusive. Since the Tunnel-Private-Group-ID is of type String as defined in [RFC2868], for use with IEEE 802.1X, the VLANID integer value is encoded as a string.
VLANIDは12ビットであり、1〜4094の値を取ります。 [RFC2868]で定義されているように、Tunnel-Private-Group-IDは文字列型であるため、IEEE 802.1Xで使用するために、VLANID整数値は文字列としてエンコードされます。
When Tunnel attributes are sent, it is necessary to fill in the Tag field. As noted in [RFC2868], section 3.1:
トンネル属性を送信するときは、[タグ]フィールドに入力する必要があります。 [RFC2868]のセクション3.1に記載されているとおり：
The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. Valid values for this field are 0x01 through 0x1F, inclusive. If the Tag field is unused, it MUST be zero (0x00).
タグフィールドの長さは1オクテットであり、同じトンネルを参照する同じパケット内の属性をグループ化する手段を提供することを目的としています。このフィールドの有効な値は、0x01〜0x1Fです。 Tagフィールドが使用されていない場合は、ゼロ（0x00）でなければなりません。
For use with Tunnel-Client-Endpoint, Tunnel-Server-Endpoint, Tunnel-Private-Group-ID, Tunnel-Assignment-ID, Tunnel-Client-Auth-ID or Tunnel-Server-Auth-ID attributes (but not Tunnel-Type, Tunnel-Medium-Type, Tunnel-Password, or Tunnel-Preference), a tag field of greater than 0x1F is interpreted as the first octet of the following field.
Tunnel-Client-Endpoint、Tunnel-Server-Endpoint、Tunnel-Private-Group-ID、Tunnel-Assignment-ID、Tunnel-Client-Auth-IDまたはTunnel-Server-Auth-ID属性（Tunnel- Type、Tunnel-Medium-Type、Tunnel-Password、またはTunnel-Preference）、0x1Fより大きいタグフィールドは、次のフィールドの最初のオクテットとして解釈されます。
Unless alternative tunnel types are provided, (e.g. for IEEE 802.1X Authenticators that may support tunneling but not VLANs), it is only necessary for tunnel attributes to specify a single tunnel. As a result, where it is only desired to specify the VLANID, the tag field SHOULD be set to zero (0x00) in all tunnel attributes. Where alternative tunnel types are to be provided, tag values between 0x01 and 0x1F SHOULD be chosen.
代替トンネルタイプが提供されていない限り（たとえば、VLANではなくトンネリングをサポートしている可能性のあるIEEE 802.1Xオーセンティケーターの場合）、トンネル属性が単一のトンネルを指定する必要があるだけです。その結果、VLANIDのみを指定する必要がある場合、すべてのトンネル属性でタグフィールドをゼロ（0x00）に設定する必要があります（SHOULD）。代替トンネルタイプが提供される場合、0x01と0x1Fの間のタグ値を選択する必要があります（SHOULD）。
The RC4 EAPOL-Key frame is created and transmitted by the Authenticator in order to provide media specific key information. For example, within 802.11 the RC4 EAPOL-Key frame can be used to distribute multicast/broadcast ("default") keys, or unicast ("key mapping") keys. The "default" key is the same for all Stations within a broadcast domain.
メディア固有のキー情報を提供するために、オーセンティケーターによってRC4 EAPOL-Keyフレームが作成および送信されます。たとえば、802.11内では、RC4 EAPOL-Keyフレームを使用して、マルチキャスト/ブロードキャスト（「デフォルト」）キー、またはユニキャスト（「キーマッピング」）キーを配布できます。 「デフォルト」キーは、ブロードキャストドメイン内のすべてのステーションで同じです。
The RC4 EAPOL-Key frame is not acknowledged and therefore the Authenticator does not know whether the Supplicant has received it. If it is lost, then the Supplicant and Authenticator will not have the same keying material, and communication will fail. If this occurs, the problem is typically addressed by re-running the authentication.
RC4 EAPOL-Keyフレームは確認されないため、オーセンティケータはサプリカントがフレームを受信したかどうかを認識しません。それが失われると、サプリカントとオーセンティケーターは同じキー情報を持たなくなり、通信は失敗します。これが発生した場合、問題は通常、認証を再実行することで解決されます。
The RC4 EAPOL-Key frame is sent from the Authenticator to the Supplicant in order to provision the "default" key, and subsequently in order to refresh the "default" key. It may also be used to refresh the key-mapping key. Rekey is typically only required with weak ciphersuites such as WEP, defined in [IEEE80211].
RC4 EAPOL-Keyフレームは、「デフォルト」キーをプロビジョニングするためにオーセンティケータからサプリカントに送信され、その後「デフォルト」キーを更新するために送信されます。また、キーマッピングキーの更新にも使用できます。鍵の再生成は通常、[IEEE80211]で定義されているWEPなどの弱い暗号スイートでのみ必要です。
Where keys are required, an EAP method that derives keys is typically selected. Therefore the initial "key mapping" keys can be derived from EAP keying material, without requiring the Authenticator to send an RC4 EAPOL-Key frame to the Supplicant. An example of how EAP keying material can be derived and used is presented in [RFC2716].
キーが必要な場合は、通常、キーを取得するEAPメソッドが選択されます。したがって、オーセンティケータがRC4 EAPOL-Keyフレームをサプリカントに送信することを必要とせずに、最初の「キーマッピング」キーをEAPキー情報から取得できます。 EAPキーイングマテリアルをどのように導出して使用できるかの例は、[RFC2716]に示されています。
While the RC4 EAPOL-Key frame is defined in [IEEE8021X], a more complete description is provided on the next page.
RC4 EAPOL-Keyフレームは[IEEE8021X]で定義されていますが、より完全な説明は次のページにあります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Packet Type | Packet Body Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Key Length |Replay Counter...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay Counter...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay Counter | Key IV...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key IV...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key IV...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key IV...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key IV... |F| Key Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Signature...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Signature...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Signature...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Signature...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version The Version field is one octet. For IEEE 802.1X, it contains the value 0x01.
バージョンバージョンフィールドは1オクテットです。 IEEE 802.1Xの場合、値は0x01です。
Packet Type The Packet Type field is one octet, and determines the type of packet being transmitted. For an EAPOL-Key Descriptor, the Packet Type field contains 0x03.
パケットタイプパケットタイプフィールドは1オクテットで、送信されるパケットのタイプを決定します。 EAPOLキー記述子の場合、「パケットタイプ」フィールドには0x03が含まれます。
Packet Body Length The Packet Body Length is two octets, and contains the length of the EAPOL-Key descriptor in octets, not including the Version, Packet Type and Packet Body Length fields.
パケット本体の長さパケット本体の長さは2オクテットで、EAPOLキー記述子の長さをオクテット単位で含みます。バージョン、パケットタイプ、パケット本体の長さのフィールドは含まれません。
Type The Type field is a single octet. The Key descriptor is defined differently for each Type; this specification documents only the RC4 Key Descriptor (Type = 0x01).
タイプタイプフィールドは単一のオクテットです。キー記述子は、タイプごとに異なる方法で定義されます。この仕様は、RC4キー記述子（Type = 0x01）のみを文書化しています。
Key Length The Key Length field is two octets. If Packet Body Length = 44 + Key Length, then the Key Field contains the key in encrypted form, of length Key Length. This is 5 octets (40 bits) for WEP, and 13 octets (104 bits) for WEP-128. If Packet Body Length = 44, then the Key field is absent, and Key Length represents the number of least significant octets from the MS-MPPE-Send-Key attribute [RFC2548] to be used as the keying material. Note that the MS-MPPE-Send-Key and MS-MPPE-Recv-Key attributes are defined from the point of view of the Authenticator. From the Supplicant point of reference, the terms are reversed. Thus the MS-MPPE-Recv-Key on the Supplicant corresponds to the MS-MPPE-Send-Key on the Authenticator, and the MS-MPPE-Send-Key on the Supplicant corresponds to the MS-MPPE-Recv-Key on the Authenticator.
キーの長さキーの長さフィールドは2オクテットです。パケット本体の長さ= 44 +キーの長さの場合、キーフィールドには、キーの長さの暗号化された形式のキーが含まれます。これは、WEPでは5オクテット（40ビット）、WEP-128では13オクテット（104ビット）です。 Packet Body Length = 44の場合、Keyフィールドは存在せず、Key Lengthは、MS-MPPE-Send-Key属性[RFC2548]からの最下位オクテットの数を表し、キー情報として使用されます。 MS-MPPE-Send-Key属性とMS-MPPE-Recv-Key属性は、認証システムの観点から定義されていることに注意してください。サプリカントの参照ポイントから、用語は逆になります。したがって、サプリカントのMS-MPPE-Recv-KeyはオーセンティケータのMS-MPPE-Send-Keyに対応し、サプリカントのMS-MPPE-Send-KeyはオーセンティケータのMS-MPPE-Recv-Keyに対応します。オーセンティケーター。
Replay Counter The Replay Counter field is 8 octets. It does not repeat within the life of the keying material used to encrypt the Key field and compute the Key Signature field. A 64-bit NTP timestamp MAY be used as the Replay Counter.
Replay Counter Replay Counterフィールドは8オクテットです。鍵フィールドの暗号化と鍵署名フィールドの計算に使用される鍵情報の有効期間内には繰り返されません。 64ビットのNTPタイムスタンプをリプレイカウンターとして使用できます。
Key IV The Key IV field is 16 octets and includes a 128-bit cryptographically random number.
Key IV Key IVフィールドは16オクテットで、128ビットの暗号化乱数が含まれています。
F The Key flag (F) is a single bit, describing the type of key that is included in the Key field. Values are:
Fキーフラグ（F）は1ビットで、キーフィールドに含まれるキーのタイプを示します。値は次のとおりです。
0 = for broadcast (default key) 1 = for unicast (key mapping key)
0 =ブロードキャスト用（デフォルトキー）1 =ユニキャスト用（キーマッピングキー）
Key Index The Key Index is 7 bits.
キーインデックスキーインデックスは7ビットです。
Key Signature The Key Signature field is 16 octets. It contains an HMAC-MD5 message integrity check computed over the EAPOL-Key descriptor, starting from the Version field, with the Key field filled in if present, but with the Key Signature field set to zero. For the computation, the 32 octet (256 bit) MS-MPPE-Send-Key [RFC2548] is used as the HMAC-MD5 key.
調号調号フィールドは16オクテットです。これには、EAPOL-Key記述子で計算されたHMAC-MD5メッセージ整合性チェックが含まれます。Versionフィールドから始まり、Keyフィールドが存在する場合は入力されますが、Key Signatureフィールドはゼロに設定されています。計算では、32オクテット（256ビット）MS-MPPE-Send-Key [RFC2548]がHMAC-MD5キーとして使用されます。
Key If Packet Body Length = 44 + Key Length, then the Key Field contains the key in encrypted form, of length Key Length. If Packet Body Length = 44, then the Key field is absent, and the least significant Key Length octets from the MS-MPPE-Send-Key attribute is used as the keying material. Where the Key field is encrypted using RC4, the RC4 encryption key used to encrypt this field is formed by concatenating the 16 octet (128 bit) Key-IV field with the 32 octet MS-MPPE-Recv-Key attribute. This yields a 48 octet RC4 key (384 bits).
キーパケットボディ長= 44 +キー長の場合、キーフィールドにはキー長が暗号化された形式でキーが含まれます。パケットボディ長= 44の場合、キーフィールドは存在せず、MS-MPPE-Send-Key属性の最下位のキー長オクテットがキー素材として使用されます。 KeyフィールドがRC4を使用して暗号化される場合、このフィールドの暗号化に使用されるRC4暗号化キーは、16オクテット（128ビット）のKey-IVフィールドと32オクテットのMS-MPPE-Recv-Key属性を連結することによって形成されます。これにより、48オクテットのRC4キー（384ビット）が生成されます。
Since this document describes the use of RADIUS for purposes of authentication, authorization, and accounting in IEEE 802.1X-enabled networks, it is vulnerable to all of the threats that are present in other RADIUS applications. For a discussion of these threats, see [RFC2607], [RFC2865], [RFC3162], [RFC3579], and [RFC3576].
このドキュメントでは、IEEE 802.1X対応ネットワークでの認証、承認、およびアカウンティングを目的としたRADIUSの使用について説明しているため、他のRADIUSアプリケーションに存在するすべての脅威に対して脆弱です。これらの脅威の説明については、[RFC2607]、[RFC2865]、[RFC3162]、[RFC3579]、および[RFC3576]を参照してください。
Vulnerabilities include:
脆弱性は次のとおりです。
Packet modification or forgery Dictionary attacks Known plaintext attacks Replay Outcome mismatches 802.11 integration Key management issues
パケット変更または偽造辞書攻撃既知の平文攻撃再生結果の不一致802.11統合キー管理の問題
RADIUS, defined in [RFC2865], does not require all Access-Requests to be authenticated or integrity protected. However, IEEE 802.1X is based on EAP. As described in [3579], Section 3.1.:
[RFC2865]で定義されているRADIUSでは、すべてのアクセス要求を認証したり、整合性を保護したりする必要はありません。ただし、IEEE 802.1XはEAPに基づいています。 [3579]のセクション3.1で説明されているように：
The Message-Authenticator attribute MUST be used to protect all Access-Request, Access-Challenge, Access-Accept, and Access-Reject packets containing an EAP-Message attribute.
Message-Authenticator属性は、EAP-Message属性を含むすべてのAccess-Request、Access-Challenge、Access-Accept、およびAccess-Rejectパケットを保護するために使用する必要があります。
As a result, when used with IEEE 802.1X, all RADIUS packets MUST be authenticated and integrity protected. In addition, as described in [3579], Section 4.2.:
その結果、IEEE 802.1Xで使用する場合、すべてのRADIUSパケットは認証され、整合性が保護されている必要があります。さらに、[3579]、セクション4.2で説明されているように：
To address the security vulnerabilities of RADIUS/EAP, implementations of this specification SHOULD support IPsec [RFC2401] along with IKE [RFC2409] for key management. IPsec ESP [RFC2406] with non-null transform SHOULD be supported, and IPsec ESP with a non-null encryption transform and authentication support SHOULD be used to provide per-packet confidentiality, authentication, integrity and replay protection. IKE SHOULD be used for key management.
RADIUS / EAPのセキュリティの脆弱性に対処するために、この仕様の実装は、キー管理のためにIKE [RFC2409]とともにIPsec [RFC2401]をサポートする必要があります（SHOULD）。非ヌル変換を伴うIPsec ESP [RFC2406]はサポートされるべきであり（SHOULD）、非ヌル暗号化変換および認証サポートを伴うIPsec ESPは、パケットごとの機密性、認証、完全性、および再生保護を提供するために使用されるべきです（SHOULD）。 IKEは、キー管理に使用する必要があります（SHOULD）。
As discussed in [RFC3579] Section 4.3.3., the RADIUS shared secret is vulnerable to offline dictionary attack, based on capture of the Response Authenticator or Message-Authenticator attribute. In order to decrease the level of vulnerability, [RFC2865], Section 3 recommends:
[RFC3579]セクション4.3.3。で説明したように、RADIUS共有シークレットは、応答認証子またはメッセージ認証子属性のキャプチャに基づいて、オフライン辞書攻撃に対して脆弱です。脆弱性のレベル[RFC2865]を下げるために、セクション3では次のことを推奨しています。
The secret (password shared between the client and the RADIUS server) SHOULD be at least as large and unguessable as a well-chosen password. It is preferred that the secret be at least 16 octets.
シークレット（クライアントとRADIUSサーバー間で共有されるパスワード）は、適切に選択されたパスワードと同じかそれ以上の大きさで、推測できないものにする必要があります（SHOULD）。シークレットは少なくとも16オクテットであることが望ましい。
In addition, the risk of an offline dictionary attack can be further mitigated by employing IPsec ESP with a non-null transform in order to encrypt the RADIUS conversation, as described in [RFC3579], Section 4.2.
さらに、[RFC3579]のセクション4.2で説明されているように、RADIUS会話を暗号化するためにnull以外の変換でIPsec ESPを使用することにより、オフライン辞書攻撃のリスクをさらに軽減できます。
Since IEEE 802.1X is based on EAP, which does not support PAP, the RADIUS User-Password attribute is not used to carry hidden user passwords. The hiding mechanism utilizes MD5, defined in [RFC1321], in order to generate a key stream based on the RADIUS shared secret and the Request Authenticator. Where PAP is in use, it is possible to collect key streams corresponding to a given Request Authenticator value, by capturing RADIUS conversations corresponding to a PAP authentication attempt using a known password. Since the User-Password is known, the key stream corresponding to a given Request Authenticator can be determined and stored.
IEEE 802.1XはPAPをサポートしないEAPに基づいているため、RADIUS User-Password属性は非表示のユーザーパスワードの伝達には使用されません。非表示メカニズムは、[RFC1321]で定義されているMD5を利用して、RADIUS共有シークレットと要求認証プロバイダに基づいてキーストリームを生成します。 PAPが使用されている場合、既知のパスワードを使用してPAP認証の試行に対応するRADIUS会話をキャプチャすることにより、指定された要求オーセンティケーター値に対応するキーストリームを収集できます。 User-Passwordがわかっているため、特定のリクエスト認証に対応するキーストリームを特定して保存できます。
The vulnerability is described in detail in [RFC3579], Section 4.3.4. Even though IEEE 802.1X Authenticators do not support PAP authentication, a security vulnerability can still exist where the same RADIUS shared secret is used for hiding User-Password as well as other attributes. This can occur, for example, if the same RADIUS proxy handles authentication requests for both IEEE 802.1X (which may hide the Tunnel-Password, MS-MPPE-Send-Key and MS-MPPE-Recv-Key attributes) and GPRS (which may hide the User-Password attribute).
この脆弱性は、[RFC3579]のセクション4.3.4で詳しく説明されています。 IEEE 802.1XオーセンティケーターはPAP認証をサポートしていませんが、同じRADIUS共有シークレットを使用してユーザーパスワードやその他の属性を非表示にするセキュリティの脆弱性が存在する可能性があります。これは、たとえば、同じRADIUSプロキシがIEEE 802.1X（トンネルパスワード、MS-MPPE-Send-KeyおよびMS-MPPE-Recv-Key属性を非表示にする可能性がある）とGPRS（これはUser-Password属性を非表示にする場合があります）。
The threat can be mitigated by protecting RADIUS with IPsec ESP with a non-null transform, as described in [RFC3579], Section 4.2. In addition, the same RADIUS shared secret MUST NOT be used for both IEEE 802.1X authentication and PAP authentication.
[RFC3579]のセクション4.2で説明されているように、非ヌル変換を使用してIPsec ESPでRADIUSを保護することにより、脅威を緩和できます。さらに、同じRADIUS共有シークレットをIEEE 802.1X認証とPAP認証の両方に使用してはなりません（MUST NOT）。
As noted in [RFC3579] Section 4.3.5., the RADIUS protocol provides only limited support for replay protection. Replay protection for RADIUS authentication and accounting can be provided by enabling IPsec replay protection with RADIUS, as described in [RFC3579], Section 4.2.
[RFC3579]セクション4.3.5。で述べたように、RADIUSプロトコルはリプレイ保護に対して限定的なサポートのみを提供します。 [RFC3579]のセクション4.2で説明されているように、RADIUSによるIPsecリプレイ保護を有効にすることで、RADIUS認証とアカウンティングのリプレイ保護を提供できます。
As with the Request Authenticator, for use with IEEE 802.1X Authenticators, the Acct-Session-Id SHOULD be globally and temporally unique.
リクエスト認証システムと同様に、IEEE 802.1X認証システムで使用するには、Acct-Session-Idはグローバルかつ時間的に一意である必要があります。
[RFC3579] Section 2.6.3. discusses the issues that arise when the EAP packet encapsulated in an EAP-Message attribute does not agree with the RADIUS Packet Type. For example, an EAP Success packet might be encapsulated within an Access-Reject; an EAP Failure might be sent within an Access-Accept; or an EAP Success or Failure might be sent within an Access-Challenge.
[RFC3579]セクション2.6.3。では、EAP-Message属性にカプセル化されたEAPパケットがRADIUSパケットタイプと一致しない場合に発生する問題について説明します。たとえば、EAP SuccessパケットはAccess-Reject内にカプセル化される場合があります。 EAP障害がAccess-Accept内で送信される可能性があります。または、EAP成功または失敗がAccess-Challenge内で送信される場合があります。
As described in [RFC3579] Section 2.6.3., these conflicting messages are likely to cause confusion. To ensure that access decisions made by IEEE 802.1X Authenticators conform to the wishes of the RADIUS server, it is necessary for the Authenticator to make the decision solely based on the authentication result (Access-Accept/Reject) and not based on the contents of EAP-Message attributes, if present.
[RFC3579]セクション2.6.3で説明されているように、これらの競合するメッセージは混乱を引き起こす可能性があります。 IEEE 802.1X Authenticatorsによって行われるアクセス決定がRADIUSサーバーの希望に確実に準拠するようにするには、Authenticatorが認証結果（Access-Accept / Reject）のみに基づいて決定を行う必要があります。 EAP-Message属性（存在する場合）。
[IEEE8021X] was developed for use on wired IEEE 802 networks such as Ethernet, and therefore does not describe how to securely adapt IEEE 802.1X for use with 802.11. This is left to an enhanced security specification under development within IEEE 802.11.
[IEEE8021X]は、イーサネットなどの有線IEEE 802ネットワークで使用するために開発されたため、IEEE 802.1Xを802.11で使用するために安全に適合させる方法については説明していません。これは、IEEE 802.11内で開発中の拡張セキュリティ仕様に任されています。
For example, [IEEE8021X] does not specify whether authentication occurs prior to, or after association, nor how the derived keys are used within various ciphersuites. It also does not specify ciphersuites addressing the vulnerabilities discovered in WEP, described in [Berkeley], [Arbaugh], [Fluhrer], and [Stubbl]. [IEEE8021X] only defines an authentication framework, leaving the definition of the authentication methods to other documents, such as [RFC2716].
たとえば、[IEEE8021X]は、認証がアソシエーションの前または後のどちらで行われるか、また派生鍵がさまざまな暗号スイート内でどのように使用されるかを指定していません。また、[Berkeley]、[Arbaugh]、[Fluhrer]、および[Stubbl]で説明されている、WEPで発見された脆弱性に対処する暗号スイートも指定していません。 [IEEE8021X]は認証フレームワークのみを定義し、認証方法の定義は[RFC2716]などの他のドキュメントに委ねています。
Since [IEEE8021X] does not address 802.11 integration issues, implementors are strongly advised to consult additional IEEE 802.11 security specifications for guidance on how to adapt IEEE 802.1X for use with 802.11. For example, it is likely that the IEEE 802.11 enhanced security specification will define its own IEEE 802.11 key hierarchy as well as new EAPOL-Key descriptors.
[IEEE8021X]は802.11統合の問題に対応していないため、実装者は、IEEE 802.1Xを802.11での使用に適合させる方法のガイダンスについて、追加のIEEE 802.11セキュリティ仕様を参照することを強くお勧めします。たとえば、IEEE 802.11拡張セキュリティ仕様では、独自のIEEE 802.11キー階層と新しいEAPOLキー記述子が定義される可能性があります。
The EAPOL-Key descriptor described in Section 4. is likely to be deprecated in the future, when the IEEE 802.11 enhanced security group completes its work. Known security issues include:
セクション4で説明されているEAPOL-Key記述子は、IEEE 802.11拡張セキュリティグループがその作業を完了するときに、将来は非推奨になる可能性があります。既知のセキュリティ問題は次のとおりです。
[1] Default key-only support. IEEE 802.1X enables the derivation of per-Station unicast keys, known in [IEEE80211] as "key mapping keys." Keys used to encrypt multicast/broadcast traffic are known as "default keys". However, in some 802.11 implementations, the unicast keys, derived as part of the EAP authentication process, are used solely in order to encrypt, authenticate and integrity protect the EAPOL-Key descriptor, as described in Section 4. These implementations only support use of default keys (ordinarily only used with multicast/broadcast traffic) to secure all traffic, unicast or multicast/broadcast, resulting in inherent security weaknesses.
[1] デフォルトのキーのみのサポート。 IEEE 802.1Xは、[IEEE80211]で「キーマッピングキー」と呼ばれる、ステーションごとのユニキャストキーの導出を可能にします。マルチキャスト/ブロードキャストトラフィックの暗号化に使用されるキーは、「デフォルトキー」と呼ばれます。ただし、一部の802.11実装では、EAP認証プロセスの一部として導出されるユニキャストキーは、セクション4で説明されているように、EAPOL-Key記述子を暗号化、認証、および完全性保護するためにのみ使用されます。これらの実装は、デフォルトのキー（通常はマルチキャスト/ブロードキャストトラフィックでのみ使用）、すべてのトラフィック、ユニキャストまたはマルチキャスト/ブロードキャストを保護するため、固有のセキュリティ上の弱点が生じます。
Where per-Station key-mapping keys (e.g. unicast keys) are unsupported, any Station possessing the default key can decrypt traffic from other Stations or impersonate them. When used along with a weak cipher (e.g. WEP), implementations supporting only default keys provide more material for attacks such as those described in [Fluhrer] and [Stubbl]. If in addition, the default key is not refreshed periodically, IEEE 802.1X dynamic key derivation provides little or no security benefit. For an understanding of the issues with WEP, see [Berkeley], [Arbaugh], [Fluhrer], and [Stubbl].
ステーションごとのキーマッピングキー（ユニキャストキーなど）がサポートされていない場合、デフォルトのキーを持つステーションは、他のステーションからのトラフィックを復号化したり、偽装したりできます。弱い暗号（WEPなど）と共に使用すると、デフォルトキーのみをサポートする実装は、[Fluhrer]や[Stubbl]で説明されているような攻撃に対してより多くの資料を提供します。さらに、デフォルトのキーが定期的に更新されない場合、IEEE 802.1X動的キーの派生によるセキュリティ上の利点はほとんどまたはまったくありません。 WEPの問題については、[Berkeley]、[Arbaugh]、[Fluhrer]、および[Stubbl]を参照してください。
[2] Reuse of keying material. The EAPOL-Key descriptor specified in section 4 uses the same keying material (MS-MPPE-Recv-Key) both to encrypt the Key field within the EAPOL-Key descriptor, and to encrypt data passed between the Station and Access Point. Multi-purpose keying material is frowned upon, since multiple uses can leak information helpful to an attacker.
[2] キー素材の再利用。セクション4で指定されたEAPOL-Key記述子は、同じ鍵情報（MS-MPPE-Recv-Key）を使用して、EAPOL-Key記述子内のKeyフィールドを暗号化し、ステーションとアクセスポイント間で渡されるデータを暗号化します。複数の用途で攻撃者に役立つ情報が漏えいする可能性があるため、多目的キーイング資料には不満があります。
[3] Weak algorithms. The algorithm used to encrypt the Key field within the EAPOL-Key descriptor is similar to the algorithm used in WEP, and as a result, shares some of the same weaknesses. As with WEP, the RC4 stream cipher is used to encrypt the key. As input to the RC4 engine, the IV and key are concatenated rather than being combined within a mixing function. As with WEP, the IV is not a counter, and therefore there is little protection against reuse.
[3] 弱いアルゴリズム。 EAPOL-Key記述子内のKeyフィールドを暗号化するために使用されるアルゴリズムは、WEPで使用されるアルゴリズムと同様であり、その結果、同じ弱点のいくつかを共有しています。 WEPと同様に、RC4ストリーム暗号を使用してキーを暗号化します。 RC4エンジンへの入力として、IVとキーはミキシング機能内で結合されるのではなく連結されます。 WEPと同様に、IVはカウンターではないため、再利用に対する保護はほとんどありません。
As a result of these vulnerabilities, implementors intending to use the EAPOL-Key descriptor described in this document are urged to consult the 802.11 enhanced security specification for a more secure alternative. It is also advisable to consult the evolving literature on WEP vulnerabilities, in order to better understand the risks, as well as to obtain guidance on setting an appropriate re-keying interval.
これらの脆弱性の結果、このドキュメントで説明されているEAPOL-Key記述子を使用する予定の実装者は、より安全な代替策について802.11拡張セキュリティ仕様を参照することを強くお勧めします。また、リスクをよりよく理解するために、また適切な鍵更新間隔の設定に関するガイダンスを取得するために、WEP脆弱性に関する進化する文献を参照することをお勧めします。
This specification does not create any RADIUS attributes nor any new number spaces for IANA administration. However, it does require assignment of new values to existing RADIUS attributes. These include:
この仕様では、IANA管理用のRADIUS属性や新しい番号スペースは作成されません。ただし、既存のRADIUS属性に新しい値を割り当てる必要があります。これらには以下が含まれます：
Attribute Values Required
========= ===============
NAS-Port-Type Token-Ring (20), FDDI (21)
Tunnel-Type VLAN (13)
Acct-Terminate-Cause Supplicant Restart (19)
Reauthentication Failure (20)
Port Reinitialized (21)
Port Administratively Disabled (22)
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321] Rivest、R。、「MD5メッセージダイジェストアルゴリズム」、RFC 1321、1992年4月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
[RFC2284] Blunk、L.およびJ. Vollbrecht、「PPP Extensible Authentication Protocol（EAP）」、RFC 2284、1998年3月。
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。およびW. Simpson、「Remote Authentication Dial In User Service（RADIUS）」、RFC 2865、2000年6月。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866]リグニー、C。、「RADIUSアカウンティング」、RFC 2866、2000年6月。
[RFC2867] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting Modifications for Tunnel Protocol Support", RFC 2867, June 2000.
[RFC2867] Zorn、G.、Aboba、B。およびD. Mitton、「RADIUS Accounting Modifications for Tunnel Protocol Support」、RFC 2867、2000年6月。
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000.
[RFC2868] Zorn、G.、Leifer、D.、Rubens、A.、Shriver、J.、Holdrege、M。およびI. Goyret、「トンネルプロトコルサポートのRADIUS属性」、RFC 2868、2000年6月。
[RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000.
[RFC2869]リグニー、C。、ウィラッツ、W。およびP.カルホーン、「RADIUS Extensions」、RFC 2869、2000年6月。
[RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
[RFC3162] Aboba、B.、Zorn、G。およびD. Mitton、「RADIUS and IPv6」、RFC 3162、2001年8月。
[RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC3280] Housley、R.、Polk、W.、Ford、W. and D. Solo、 "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile"、RFC 3280、April 2002。
[RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 3576, July 2003.
[RFC3576] Chiba、M.、Dommety、G.、Eklund、M.、Mitton、D. and B. Aboba、 "Dynamic Authorization Extensions to Remote Authentication Dial In User Service（RADIUS）"、RFC 3576、July 2003。
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3579] Aboba、B。およびP. Calhoun、「RADIUS（Remote Authentication Dial In User Service）Support For Extensible Authentication Protocol（EAP）」、RFC 3579、2003年9月。
[IEEE8021X] IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE Std 802.1X-2001, June 2001.
[IEEE8021X]ローカルおよびメトロポリタンエリアネットワークのIEEE標準：ポートベースのネットワークアクセスコントロール、IEEE Std 802.1X-2001、2001年6月。
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、1997年2月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999.
[RFC2548] Zorn、G。、「Microsoft Vendor-specific RADIUS Attributes」、RFC 2548、1999年3月。
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999.
[RFC2607] Aboba、B。およびJ. Vollbrecht、「Proxy Chaining and Policy Implementation in Roaming」、RFC 2607、1999年6月。
[RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", RFC 2716, October 1999.
[RFC2716] Aboba、B。およびD. Simon、「PPP EAP TLS Authentication Protocol」、RFC 2716、1999年10月。
[MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack." CryptoBytes Vol.2 No.2, Summer 1996.
[MD5Attack] Dobbertin、H.、「最近の攻撃後のMD5のステータス」。 CryptoBytes Vol.2 No.2、1996年夏。
[IEEE802] IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture, ANSI/IEEE Std 802, 1990.
[IEEE802]ローカルおよびメトロポリタンエリアネットワークのIEEE標準：概要とアーキテクチャ、ANSI / IEEE Std 802、1990。
[IEEE8021Q] IEEE Standards for Local and Metropolitan Area Networks: Draft Standard for Virtual Bridged Local Area Networks, P802.1Q, January 1998.
[IEEE8021Q]ローカルおよびメトロポリタンエリアネットワークのIEEE標準：仮想ブリッジローカルエリアネットワークのドラフト標準、P802.1Q、1998年1月。
[IEEE8023] ISO/IEC 8802-3 Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications, (also ANSI/IEEE Std 802.3- 1996), 1996.
[IEEE8023] ISO / IEC 8802-3情報技術-システム間のテレコミュニケーションおよび情報交換-ローカルおよびメトロポリタンエリアネットワーク-共通仕様-パート3：衝突検出（CSMA / CD）アクセス方式のキャリアセンスマルチアクセスおよび物理層の仕様（ANSI / IEEE Std 802.3- 1996）、1996。
[IEEE80211] Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, IEEE Std. 802.11-1999, 1999.
[IEEE80211]情報技術-システム間のテレコミュニケーションおよび情報交換-ローカルおよびメトロポリタンエリアネットワーク-特定の要件パート11：ワイヤレスLAN媒体アクセス制御（MAC）および物理層（PHY）仕様、IEEE標準802.11-1999、1999。
[Berkeley] Borisov, N., Goldberg, I. and D. Wagner, "Intercepting Mobile Communications: The Insecurity of 802.11", ACM SIGMOBILE, Seventh Annual International Conference on Mobile Computing and Networking, July 2001, Rome, Italy.
[Berkeley] Borisov、N.、Goldberg、I。およびD. Wagner、「Intercepting Mobile Communications：The Insecurity of 802.11」、ACM SIGMOBILE、第7回年次国際モバイルコンピューティングおよびネットワーキング会議、2001年7月、ローマ、イタリア。
[Arbaugh] Arbaugh, W., Shankar, N. and J.Y.C. Wan, "Your 802.11 Wireless Network has No Clothes", Department of Computer Science, University of Maryland, College Park, March 2001.
[Arbaugh] Arbaugh、W.、Shankar、N. and J.Y.C.ワン、「802.11ワイヤレスネットワークには衣服がない」、メリーランド大学コンピュータサイエンス学部、カレッジパーク、2001年3月。
[Fluhrer] Fluhrer, S., Mantin, I. and A. Shamir, "Weaknesses in the Key Scheduling Algorithm of RC4", Eighth Annual Workshop on Selected Areas in Cryptography, Toronto, Canada, August 2001.
[Fluhrer] Fluhrer、S.、Mantin、I。およびA. Shamir、「RC4のキースケジューリングアルゴリズムの弱点」、暗号化の選択された領域に関する第8回年次ワークショップ、カナダ、トロント、2001年8月。
[Stubbl] Stubblefield, A., Ioannidis, J. and A. Rubin, "Using the Fluhrer, Mantin and Shamir Attack to Break WEP", 2002 NDSS Conference.
[Stubbl] Stubblefield、A.、Ioannidis、J。およびA. Rubin、「Fluhrer、MantinおよびShamir攻撃を使用してWEPを破る」、2002年NDSS会議。
The following table provides a guide to which attributes MAY be sent and received as part of IEEE 802.1X authentication. L3 denotes attributes that require layer 3 capabilities, and thus may not be supported by all Authenticators. For each attribute, the reference provides the definitive information on usage.
次の表は、IEEE 802.1X認証の一部として送受信できる属性のガイドです。 L3は、レイヤー3機能を必要とする属性を示します。したがって、すべてのオーセンティケーターによってサポートされるとは限りません。このリファレンスでは、各属性について、使用法に関する明確な情報を提供しています。
802.1X # Attribute
X 1 User-Name [RFC2865]
2 User-Password [RFC2865]
3 CHAP-Password [RFC2865]
X 4 NAS-IP-Address [RFC2865]
X 5 NAS-Port [RFC2865]
X 6 Service-Type [RFC2865]
7 Framed-Protocol [RFC2865]
L3 8 Framed-IP-Address [RFC2865]
L3 9 Framed-IP-Netmask [RFC2865]
L3 10 Framed-Routing [RFC2865]
X 11 Filter-Id [RFC2865]
X 12 Framed-MTU [RFC2865]
13 Framed-Compression [RFC2865]
L3 14 Login-IP-Host [RFC2865]
L3 15 Login-Service [RFC2865]
L3 16 Login-TCP-Port [RFC2865]
18 Reply-Message [RFC2865]
19 Callback-Number [RFC2865]
20 Callback-Id [RFC2865]
L3 22 Framed-Route [RFC2865]
L3 23 Framed-IPX-Network [RFC2865]
X 24 State [RFC2865]
X 25 Class [RFC2865]
X 26 Vendor-Specific [RFC2865]
X 27 Session-Timeout [RFC2865]
X 28 Idle-Timeout [RFC2865]
X 29 Termination-Action [RFC2865]
X 30 Called-Station-Id [RFC2865]
X 31 Calling-Station-Id [RFC2865]
X 32 NAS-Identifier [RFC2865]
X 33 Proxy-State [RFC2865]
34 Login-LAT-Service [RFC2865]
35 Login-LAT-Node [RFC2865]
36 Login-LAT-Group [RFC2865]
802.1X # Attribute
802.1X # Attribute
L3 37 Framed-AppleTalk-Link [RFC2865]
L3 38 Framed-AppleTalk-Network [RFC2865]
L3 39 Framed-AppleTalk-Zone [RFC2865]
X 40 Acct-Status-Type [RFC2866]
X 41 Acct-Delay-Time [RFC2866]
X 42 Acct-Input-Octets [RFC2866]
X 43 Acct-Output-Octets [RFC2866]
X 44 Acct-Session-Id [RFC2866]
X 45 Acct-Authentic [RFC2866]
X 46 Acct-Session-Time [RFC2866]
X 47 Acct-Input-Packets [RFC2866]
X 48 Acct-Output-Packets [RFC2866]
X 49 Acct-Terminate-Cause [RFC2866]
X 50 Acct-Multi-Session-Id [RFC2866]
X 51 Acct-Link-Count [RFC2866]
X 52 Acct-Input-Gigawords [RFC2869]
X 53 Acct-Output-Gigawords [RFC2869]
X 55 Event-Timestamp [RFC2869]
60 CHAP-Challenge [RFC2865]
X 61 NAS-Port-Type [RFC2865]
62 Port-Limit [RFC2865]
63 Login-LAT-Port [RFC2865]
X 64 Tunnel-Type [RFC2868]
X 65 Tunnel-Medium-Type [RFC2868]
L3 66 Tunnel-Client-Endpoint [RFC2868]
L3 67 Tunnel-Server-Endpoint [RFC2868]
L3 68 Acct-Tunnel-Connection [RFC2867]
L3 69 Tunnel-Password [RFC2868]
70 ARAP-Password [RFC2869]
71 ARAP-Features [RFC2869]
72 ARAP-Zone-Access [RFC2869]
73 ARAP-Security [RFC2869]
74 ARAP-Security-Data [RFC2869]
75 Password-Retry [RFC2869]
76 Prompt [RFC2869]
X 77 Connect-Info [RFC2869]
X 78 Configuration-Token [RFC2869]
X 79 EAP-Message [RFC3579]
X 80 Message-Authenticator [RFC3579]
X 81 Tunnel-Private-Group-ID [RFC2868]
L3 82 Tunnel-Assignment-ID [RFC2868]
X 83 Tunnel-Preference [RFC2868]
84 ARAP-Challenge-Response [RFC2869]
802.1X # Attribute
802.1X # Attribute
X 85 Acct-Interim-Interval [RFC2869]
X 86 Acct-Tunnel-Packets-Lost [RFC2867]
X 87 NAS-Port-Id [RFC2869]
L3 88 Framed-Pool [RFC2869]
L3 90 Tunnel-Client-Auth-ID [RFC2868]
L3 91 Tunnel-Server-Auth-ID [RFC2868]
X 95 NAS-IPv6-Address [RFC3162]
96 Framed-Interface-Id [RFC3162]
L3 97 Framed-IPv6-Prefix [RFC3162]
L3 98 Login-IPv6-Host [RFC3162]
L3 99 Framed-IPv6-Route [RFC3162]
L3 100 Framed-IPv6-Pool [RFC3162]
X 101 Error-Cause [RFC3576]
802.1X # Attribute
Key === X = May be used with IEEE 802.1X authentication L3 = Implemented only by Authenticators with Layer 3 capabilities
キー=== X = IEEE 802.1X認証で使用可能L3 =レイヤー3機能を持つオーセンティケーターによってのみ実装されます
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるまたは適用されない範囲に関して、いかなる立場も取らない。利用可能。また、そのような権利を特定するために何らかの努力をしたことも表していません。標準化過程および標準化関連文書の権利に関するIETFの手順に関する情報は、BCP-11にあります。公開のために利用可能にされた権利の主張および利用可能にされるライセンスの保証のコピー、またはこの仕様の実装者またはユーザーによる一般的なライセンスまたはそのような所有権の使用の許可を得ようとした試みの結果を入手できます。 IETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、この規格を実践するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、関係者に呼びかけます。 IETF Executive Directorに情報を送信してください。
The authors would like to acknowledge Bob O'Hara of Airespace, David Halasz of Cisco, Tim Moore, Sachin Seth and Ashwin Palekar of Microsoft, Andrea Li, Albert Young and Dave Bagby of 3Com for contributions to this document.
このドキュメントへの寄稿者として、AirespaceのBob O'Hara、CiscoのDavid Halasz、MicrosoftのTim Moore、Sachin Seth、MicrosoftのAshwin Palekar、3ComのAndrea Li、Albert Young、Dave Bagbyに感謝します。
Paul Congdon Hewlett Packard Company HP ProCurve Networking 8000 Foothills Blvd, M/S 5662 Roseville, CA 95747
Paul Congdon Hewlett Packard Company HP ProCurve Networking 8000 Foothills Blvd、M / S 5662 Roseville、CA 95747
Phone: +1 916 785 5753
Fax: +1 916 785 8478
EMail: paul_congdon@hp.com
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
バーナードアボバマイクロソフトコーポレーションワンマイクロソフトウェイレドモンド、ワシントン州98052
Phone: +1 425 706 6605
Fax: +1 425 936 7329
EMail: bernarda@microsoft.com
Andrew Smith Trapeze Networks 5753 W. Las Positas Blvd. Pleasanton, CA 94588-4084
Andrew Smith Trapeze Networks 5753 W. Las Positas Blvd.プレザントン、カリフォルニア州94588-4084
Fax: +1 415 345 1827
EMail: ah_smith@acm.org
John Roese Enterasys
ジョン・ローゼ・エンタシス
Phone: +1 603 337 1506
EMail: jjr@enterasys.com
Glen Zorn Cisco Systems, Inc. 500 108th Avenue N.E., Suite 500 Bellevue, WA 98004
Glen Zorn Cisco Systems、Inc. 500 108th Avenue N.E.、Suite 500 Bellevue、WA 98004
Phone: +1 425 438 8218
Fax: +1 425 438 1848
EMail: gwz@cisco.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（C）The Internet Society（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその継承者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。