RFC3580 日本語訳
3580 IEEE 802.1X Remote Authentication Dial In User Service (RADIUS)Usage Guidelines. P. Congdon, B. Aboba, A. Smith, G. Zorn, J. Roese. September 2003. (Format: TXT=66136 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループP.コングドンの要求をネットワークでつないでください: 3580年のヒューレットパッカード会社カテゴリ: 情報のB.AbobaマイクロソフトA.スミスぶらんこはシスコシステムズJ.Roese Enterasys2003年9月にG.ゾルンをネットワークでつなぎます。
IEEE 802.1X Remote Authentication Dial In User Service (RADIUS)
Usage Guidelines
ユーザサービス(半径)用法ガイドラインのIEEE 802.1Xのリモート認証ダイヤル
Status of this Memo
この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)インターネット協会(2003)。 All rights reserved。
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 AuthenticatorsによるRemote Authentication Dial In User Service(RADIUS)用法で提案を提供します。 材料をまた、IEEE 802.1X仕様の中の非標準のAppendixの中に本書では含んで、情報の目的のためのIETF RFCとして寄贈しています。
Congdon, et al. Informational [Page 1] RFC 3580 IEEE 802.1X RADIUS September 2003
コングドン、他 [1ページ]情報のRFC3580IEEE 802.1X半径2003年9月
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 用語。 . . . . . . . . . . . . . . . . . . . . . . 3 1.2. 要件言語。 . . . . . . . . . . . . . . . . . 4 2. 半径会計属性. . . . . . . . . . . . . . . . . 5 2.1。 Acctが原因を終えている.52.2。 Acct Multi-Sessionアイダホ州 . . . . . . . . . . . . . . . . . 6 2.3. Acctはカウントをリンクします。 . . . . . . . . . . . . . . . . . . . . 7 3. 半径認証。 . . . . . . . . . . . . . . . . . . . . 7 3.1. ユーザ名。 . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. ユーザパスワード、やつパスワードは.83.3にやつと同じくらい挑戦します。 NAS IPアドレス、NAS-IPv6-アドレス.83.4。 NAS-ポート.83.5。 .83.6をサービスしてタイプしてください。 縁どられたプロトコル。 . . . . . . . . . . . . . . . . . . . . 9 3.7. 縁どられたIPアドレス、縁どられたIPネットマスク.93.8。 縁どられたルート設定.93.9。 フィルタID。 . . . . . . . . . . . . . . . . . . . . . . . 9 3.10. 縁どられたMTU.93.11。 縁どられた圧縮.10 3.12。 Displayableメッセージ. . . . . . . . . . . . . . . . . . 10 3.13。 コールバック番号、Callback ID.10 3.14。 縁どられたルート、縁どられたIPv6ルート。 . . . . . . . . . . . . 11 3.15. 状態、クラス、プロキシ状態。 . . . . . . . . . . . . . . . 11 3.16. ベンダー特有です。 . . . . . . . . . . . . . . . . . . . . 11 3.17. セッションタイムアウト。 . . . . . . . . . . . . . . . . . . . . 11 3.18. アイドルタイムアウト. . . . . . . . . . . . . . . . . . . . . . 12 3.19。 終了動作.12 3.20。 呼ばれた駅のアイダホ州 . . . . . . . . . . . . . . . . . . . 12 3.21. 呼んでいる駅のイド.12 3.22。 NAS-識別子.12 3.23。 NASはタイプを移植します。 . . . . . . . . . . . . . . . . . . . . . 12 3.24. ポート限界.13 3.25。 パスワード再試行.13 3.26。 インフォメーションを接続している.13 3.27。 EAP-メッセージ。 . . . . . . . . . . . . . . . . . . . . . . 13 3.28. メッセージ固有識別文字。 . . . . . . . . . . . . . . . . . 13 3.29. NAS Portアイダホ州 . . . . . . . . . . . . . . . . . . . . . . 13 3.30. 縁どられたプールであり、縁どられたIPv6は水たまりになります。 . . . . . . . . . . . . . 14 3.31. 属性にトンネルを堀ってください。 . . . . . . . . . . . . . . . . . . . 14 4. RC4 EAPOL主要な記述子. . . . . . . . . . . . . . . . . . . 15 5。 セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 18 5.1. パケット変更か偽造. . . . . . . . . . . . . 18 5.2。 辞書攻撃. . . . . . . . . . . . . . . . . . . 19 5.3。 知られている平文は攻撃されます。 . . . . . . . . . . . . . . . . 19 5.4. .205.5を再演してください。 結果ミスマッチ. . . . . . . . . . . . . . . . . . . 20
Congdon, et al. Informational [Page 2] RFC 3580 IEEE 802.1X RADIUS September 2003
コングドン、他 [2ページ]情報のRFC3580IEEE 802.1X半径2003年9月
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
5.6. 802.11 統合. . . . . . . . . . . . . . . . . . . 20 5.7。 Key Management問題。 . . . . . . . . . . . . . . . . . 21 6. IANA問題。 . . . . . . . . . . . . . . . . . . . . . 22 7. 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 22 7.1。 引用規格. . . . . . . . . . . . . . . . . . 22 7.2。 有益な参照. . . . . . . . . . . . . . . . . 23 8。 属性のテーブル。 . . . . . . . . . . . . . . . . . . . . . 25 9. 知的所有権声明. . . . . . . . . . . . . . . 28 10。 承認. . . . . . . . . . . . . . . . . . . . . . . 28 11。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 29 12。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 30
1. Introduction
1. 序論
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はイーサネット、Token Ring、および802.11の無線LANを含むIEEE802メディアへの認証されたアクセスを可能にします。 Remote Authentication Dial In User Service(RADIUS)サポートはIEEE 802.1Xの中で任意ですが、多くのIEEE 802.1X Authenticatorsが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]はIEEE802[IEEE802]メディアに「ネットワークポート認証」を提供します、イーサネット[IEEE8023](Token Ringと802.11[IEEE80211]ワイヤレスLANS)を含んでいて
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はバックエンドAuthentication Serverの使用を必要としないで、その結果、スタンドアロンのブリッジかAccess Points、および中心で管理されたシナリオで配布することができます。
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.
IEEE802ネットワークのための認証、承認、および会計(AAA)が中心で管理されるのが、望ましい状況で、バックエンド認証と会計サーバの展開は望ましいです。 そのような状況で、IEEE 802.1X Authenticatorsが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 AuthenticatorsによるRADIUS用法で提案を提供します。 IEEE 802.1X Authenticatorsに、どんなAAAプロトコルのサポートも任意です、そして、したがって、IEEE 802.1X仕様の中で非標準のAppendixにこの仕様を組み入れてあります。
1.1. Terminology
1.1. 用語
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.
関連駅へのワイヤレスの媒体で配布サービスへのアクセスを提供するPoint(AP)A駅にアクセスしてください。
Congdon, et al. Informational [Page 3] RFC 3580 IEEE 802.1X RADIUS September 2003
コングドン、他 [3ページ]情報のRFC3580IEEE 802.1X半径2003年9月
Association
The service used to establish Access Point/Station mapping and
enable Station invocation of the distribution system services.
サービスがAccess Point/駅のマッピングを確立して、流通制度サービスの駅の実施を可能にするのに使用した協会。
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.
固有識別文字An AuthenticatorはSupplicantから認証を必要とする実体です。 Authenticatorは二地点間LANセグメントか802.11のワイヤレスのリンクのもう一方の端のSupplicantに接続されるかもしれません。
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.
認証Server An Authentication ServerはAuthentication ServiceをAuthenticatorに供給する実体です。 このサービスはSupplicantによって提供された資格証明書から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.
Access Entity(PAE)を移植してください。物理的であるか仮想の(802.11)ポートに関連しているプロトコル実体。 与えられたPAEは、プロトコルがAuthenticator、Supplicantまたは両方に関連している機能性であるとサポートするかもしれません。
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).
IEEE802.11conformant媒体アクセス制御(MAC)を含むどんなデバイスと物理的な層(PHY)もワイヤレスの媒体(WM)に連結する駅(STA)。
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.
哀願者A SupplicantはAuthenticatorによって認証されている実体です。 Supplicantは二地点間LANセグメントか802.11のワイヤレスのリンクの片端のAuthenticatorに接続されるかもしれません。
1.2. Requirements Language
1.2. 要件言語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Congdon, et al. Informational [Page 4] RFC 3580 IEEE 802.1X RADIUS September 2003
コングドン、他 [4ページ]情報のRFC3580IEEE 802.1X半径2003年9月
2. RADIUS Accounting Attributes
2. 半径会計属性
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が原因を終えているAcctマルチセッションイドAcctリンクカウント
2.1. Acct-Terminate-Cause
2.1. Acctは原因を終えます。
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
dot1xAuthSessionTerminateCause Acctが原因を終えているIEEE 802.1X半径値の価値------------- -------------------- SupplicantLogoff(1)ユーザ要求(1)portFailure(2)が(22) notTerminatedYet(999)であると行政上無効にされたキャリヤー(2)SupplicantRestart(3)哀願者再開(19)reauthFailed(4) Reauthentication失敗(20)authControlForceUnauth(5)アドミンリセット(6)portReInit(6)ポートReinitialized(21)portAdminDisabled(7)ポートをなくした、なし。
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.
この属性を使用するとき、User Request(1)終了原因はSupplicantから受けられたEAPOL-ログオフのためセッションが終わった状況に対応しています。 セッションがローミングのため動かされるとき、EAPOL州のマシンはSupplicant Logoffとしてこれを扱うでしょう。
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)終了原因はAccess Pointsの間を移動するのを除いた理由で物理的な接続性の損失によるセッション終了を示します。 例えば、Supplicantが二地点間LAN接続から切断するか、またはAccess Pointの範囲から引っ越すなら、この終了原因は使用されています。 したがって、無くなっているCarrier(2)はEAPOL州のマシンのPort Disabled状態に一致しています。
A Supplicant Restart (19) termination cause indicates re-initialization of the Supplicant state machines.
Supplicant Restart(19)終了原因はSupplicant州のマシンの再初期化を示します。
Congdon, et al. Informational [Page 5] RFC 3580 IEEE 802.1X RADIUS September 2003
コングドン、他 [5ページ]情報のRFC3580IEEE 802.1X半径2003年9月
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)終了原因は、以前に認証されたSupplicantが管理活動で再認証タイマか明白な再認証要求の首尾よく次の満期を再認証していないのを示します。
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。 セッションは再認証失敗のため終えられます。 この場合、Reauthentication Failure(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.
Admin Reset(6)終了原因は、Portが行政上権限のない状態に強制されたのを示します。
A Port Reinitialized (21) termination cause indicates that the Port's MAC has been reinitialized.
Port Reinitialized(21)終了原因は、PortのMACが再初期化されたのを示します。
A Port Administratively Disabled (22) termination cause indicates that the Port has been administratively disabled.
Port Administratively Disabled(22)終了原因は、Portが行政上無効にされたのを示します。
2.2. Acct-Multi-Session-Id
2.2. Acctマルチセッションイド
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]は集められたポートに影響しませんが、異なったAccess PointsがAccess Pointsの間のSupplicantローミングで複数の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,
Access Pointsによってサポートされるところでは、ローミングSupplicantの複数の関連するセッションを結びつけるのにAcctのマルチSessionのイド属性を使用できます。 そのような状況で、セッション文脈をAccess Pointsの間に移すなら、対応する認証と承認交換なしで会計パケットを送るかもしれません。
Congdon, et al. Informational [Page 6] RFC 3580 IEEE 802.1X RADIUS September 2003
コングドン、他 [6ページ]情報のRFC3580IEEE 802.1X半径2003年9月
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).
Associationが起こったならば。 しかしながら、そのような状況で、AcctのマルチSessionのイドがInter-アクセスPointプロトコル(IAPP)の一部としてAccess Pointsの間に移されると思われます。
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のマルチSessionのイドがAccess Pointsの間でユニークでないなら選ばれたAcctマルチSessionのイドがそのAccess Pointに割り当てる既存の値に重なるのが、可能であり、したがって、Accounting Serverはマルチリンクセッションとローミングセッションを区別できないでしょう。
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のマルチSessionのイド属性はすべてのブリッジかAccess Pointsと、Supplicantsとセッションのときにユニークです。 それがこのユニークさを提供するために示される、それ、Acct、-マルチSession-イドはフォームの以下の通りです。
Original AP MAC Address | Supplicant MAC Address | NTP Timestamp
オリジナルのAPマックーアドレス| 哀願者マックーアドレス| 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マックーアドレスがセッションが始まったブリッジかAccess PointのMACアドレスであり、64ビットのNTPタイムスタンプがオリジナルのセッションの始まりを示す、」 ローミングセッションの間のAcctのマルチSessionのイドの一貫性に備えるために、AcctのマルチSessionのイドはIAPPの一部か別の移管体系としてAccess Pointsの間に動かされるかもしれません。
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のマルチSessionのイドの使用はすべてのAccess Points、Supplicants、およびセッションのときにユニークさを保証します。 NTPタイムスタンプがリブートのときにどんな包装もしないので、リブートされたAccess Pointが前のセッションのものに混乱できたAcctのマルチSessionのイドを選ぶことができた可能性が全くありません。
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"
タイプStringにはAcctのマルチSessionのイドが[RFC2866]で定義されるようにあるので、IEEE 802.1Xとの使用において、それはHexケタのASCIIストリングとしてコード化されます。 例: 「00-10-A4-23-19-C0-00-12-B2、-、14-23 反-AF-23-83-C0-76-B8-44-E8"、」
2.3. Acct-Link-Count
2.3. Acctリンクカウント
The Acct-Link-Count attribute may be used to account for the number of ports that have been aggregated.
Acctリンクカウント属性は、集められたポートの数を説明するのに使用されるかもしれません。
3. RADIUS Authentication
3. 半径認証
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認証にどう使用されるかを説明します。
Congdon, et al. Informational [Page 7] RFC 3580 IEEE 802.1X RADIUS September 2003
コングドン、他 [7ページ]情報のRFC3580IEEE 802.1X半径2003年9月
3.1. User-Name
3.1. ユーザ名
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に、SupplicantはアイデンティティをEAP-応答/アイデンティティメッセージで通常供給します。 入手できるところでは、Supplicantのアイデンティティは、User-名前属性に含まれていて、[RFC2865]と[RFC3579]の指定されるとしてのRADIUS Access-要求とAccess-応答メッセージに含まれています。
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.
あるいはまた、User-名前属性は[RFC3579]セクション2.1.で議論するようにCalling駅のID値を含むかもしれません。(それは、Supplicant MACアドレスに設定されます)。
3.2. User-Password, CHAP-Password, CHAP-Challenge
3.2. ユーザパスワード、やつパスワード、やつ挑戦
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が認証、User-パスワード、CHAP-パスワードまたはCHAP-挑戦であるとサポートしないので、属性はRADIUSクライアントとして機能するIEEE 802.1X Authenticatorsによって使用されません。
3.3. NAS-IP-Address, NAS-IPv6-Address
3.3. NAS IPアドレス、NAS-IPv6-アドレス
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アドレスはAuthenticatorとしてブリッジかAccess Point芝居のIPv4アドレスを含んでいます、そして、NAS-IPv6-アドレスはIPv6アドレスを含んでいます。 IEEE 802.1X Authenticatorに1つ以上のインタフェースがあるなら、ループバックアドレスを使用するのは、このためにインタフェースの1つが失敗するつもりであってもさえAuthenticatorがまだ届いているくらい望ましいかもしれません。
3.4. NAS-Port
3.4. NAS-ポート
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-ポートはブリッジのポートナンバーを含むでしょう。 Access Pointには物理的なポートがない間、ユニークな「協会ID」はうまくいっている協会交換でのあらゆるモバイル駅に配属されます。 その結果、協会交換が認証の前に終了されたなら、Access Pointに関して、NAS-ポート属性は協会IDを含むでしょう。(それは、16ビットの符号のない整数です)。 IEEE 802.1X認証が協会の前に起こるところでは、ユニークなNAS-ポート値は利用可能でないかもしれません。
3.5. Service-Type
3.5. サービスタイプ
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
FramedのService-タイプは、適切な802縁どりが接続に使用されるべきであるのを示します。 Authenticate Only(8)のService-タイプは、返されたコネがAccess受け入れたならどんな承認情報も、必要でないのを示します。 説明されたコネ[RFC2865]、aとして
Congdon, et al. Informational [Page 8] RFC 3580 IEEE 802.1X RADIUS September 2003
コングドン、他 [8ページ]情報のRFC3580IEEE 802.1X半径2003年9月
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.
Call CheckのサービスタイプはRADIUSサーバが接続試みを受け入れるか、または拒絶するよう要求するためにAccess-リクエスト・パケットに含まれています、通常Called駅のID(ブリッジかAccess Point MACアドレスに設定する)かCalling駅のID属性(Supplicant MACアドレスに設定する)に基づいて。 [RFC2865]に述べられるように、この場合User-名前属性にCalling駅のアイダホ州の値を与えるのはお勧めです。
3.6. Framed-Protocol
3.6. 縁どられたプロトコル
Since there is no value for IEEE 802 media, the Framed-Protocol attribute is not used by IEEE 802.1X Authenticators.
IEEE802メディアのための値が全くないので、Framed-プロトコル属性はIEEE 802.1X Authenticatorsによって使用されません。
3.7. Framed-IP-Address, Framed-IP-Netmask
3.7. 縁どられたIPアドレス、縁どられたIPネットマスク
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アドレス課題にメカニズムを提供しません。 したがって、IPアドレスが割当機構であるとサポートするIEEE 802.1X AuthenticatorsはFramed IPアドレスとFramed IPネットマスク属性を使用できるだけです。通常、この能力は層の3デバイスによってサポートされます。
3.8. Framed-Routing
3.8. 縁どられたルート設定
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-ルート設定属性はSupplicantのためにルーティング方式を示します。 それを、したがって、層として3台のデバイスを機能させるIEEE 802.1X Authenticatorsだけにおいて関連していて、ブリッジかAccess Pointが使用できません。
3.9. Filter-ID
3.9. フィルタID
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.
この属性は、Supplicantのセッションに適用されるためにフィルタリストの名前を示します。 IEEE 802.1X Authenticatorとの使用において、それは、層2か層3のフィルタのどちらかを示すのに使用されるかもしれません。 層3のフィルタは層3のデバイスとして機能するIEEE 802.1X Authenticatorsで通常支えられるだけです。
3.10. Framed-MTU
3.10. 縁どられたMTU
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:
この属性はSupplicantとAuthenticatorの間のワイヤの上に伝えられるかもしれないIPパケットの最大サイズを示します。 IEEE 802.1X Authenticatorsは関連802媒体において、対応する値にこれを設定して、RADIUS Access-要求でそれを含めます。 RADIUSサーバは4(4)八重奏を引いてFramed-MTUと同じくらい大きいEAPパケットを送るかもしれません、IEEE 802.1Xバージョン(1)、Type(1)、およびBody Length(2)分野に追加オーバーヘッドを考慮に入れて。 IEEEの上のEAPに関しては、802のメディア、Framed-MTU値(LLC/SNAPオーバーヘッドを含んでいない)、および最大のフレーム長さの値(序文を含んでいない)は以下の通りです:
Congdon, et al. Informational [Page 9] RFC 3580 IEEE 802.1X RADIUS September 2003
コングドン、他 [9ページ]情報のRFC3580IEEE 802.1X半径2003年9月
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
最大のフレームメディア縁どられたMTUの長さ========= =============== ============== イーサネット1500 1522 802.3 1500 1522 802.4 8174 8193 802.5(4Mbps)4528 4550 802.5(16Mbps)18173 18200 802.5(100Mb/s)18173 18200 802.6 9191 9240 802.9a1500 1518 802.11 2304 2346 802.12(イーサネット)1500 1518 802.12(トークンリング)4502 4528FDDI4479 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.
注意--802.11のメディアがIEEE802.11作業部会で引き受けられる進行中の仕事の結果、変えるかもしれないIEEEのためのFramed-MTUサイズ。 およそ802.11のステーションが1500の八重奏より大きいMTUを扱うことができないので、802.11のNASポートタイプ値に遭遇するRADIUSサーバが1496の八重奏ほど大きくないパケットをEAPに送るのは、お勧めです。
3.11. Framed-Compression
3.11. 縁どられた圧縮
[IEEE8021X] does not include compression support. Therefore this attribute is not understood by [IEEE8021X] Authenticators.
[IEEE8021X]は圧縮サポートを含んでいません。 したがって、この属性は[IEEE8021X]固有識別文字に解釈されません。
3.12. Displayable Messages
3.12. Displayableメッセージ
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-メッセージ属性はユーザに表示されるかもしれないテキストを示します。 これは、概念でEAP Notification Typeと同様で、[RFC2284]で定義されています。 [IEEE8021X]固有識別文字に「ディスプレイ-可能」メッセージを送るとき、[RFC3579]、セクション2.6.5で注意されるように、Reply-メッセージ属性の中で送るのではなく、EAP EAP-メッセージ/要求/通知属性の中で「ディスプレイ-可能」メッセージを最もよく送ります。
3.13. Callback-Number, Callback-ID
3.13. コールバック番号、Callback ID
These attributes are not understood by IEEE 802.1X Authenticators.
これらの属性はIEEE 802.1X Authenticatorsに解釈されません。
Congdon, et al. Informational [Page 10] RFC 3580 IEEE 802.1X RADIUS September 2003
コングドン、他 [10ページ]情報のRFC3580IEEE 802.1X半径2003年9月
3.14. Framed-Route, Framed-IPv6-Route
3.14. 縁どられたルート、縁どられたIPv6ルート
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-ルートとFramed-IPv6-ルート属性はSupplicantのために構成されることになっているルートを提供します。 これらの属性は、したがって、層として3台のデバイスを機能させるIEEE 802.1X Authenticatorsだけにおいて関連していて、ブリッジかAccess Pointに解釈できません。
3.15. State, Class, Proxy-State
3.15. 状態、クラス、プロキシ状態
These attributes are used for the same purposes as described in [RFC2865].
これらの属性は[RFC2865]で説明されるのと同じ目的に使用されます。
3.16. Vendor-Specific
3.16. ベンダー特有です。
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]で説明されるのと同じ目的に使用されます。 MPPEがキーを送るさんと[RFC2548]のセクション2.4で説明されたMPPE-Recv Key属性さんは、RC4 EAPOL主要な記述子[IEEE8021X、セクション7.6]を暗号化して、認証するのに使用されるかもしれません。 MPPEがキーを送るさんとEAPメソッドで交渉されたマスターキーからのMPPE-Recv Key属性さんの派生に関する例は[RFC2716]で出されます。 EAPOL主要な記述子の詳細はセクション4に明らかにされます。
3.17. Session-Timeout
3.17. セッションタイムアウト
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-動作属性でTermination-動作属性なしでAccess受け入れているセットでDefaultに送ると、Session-タイムアウト属性はセッション終了の前に提供された秒のサービスの最大数を指定します。
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-要求、Session-タイムアウトのTermination-動作値と共にAccess受け入れている属性が再認証の前に提供された秒のサービスの最大数を指定するとき。 この場合、Session-タイムアウト属性は、802.1XのReauthentication Timer州のマシンの中にreAuthPeriod定数をロードするのに使用されます。 RADIUS-要求のTermination-動作値と共に送ると、ゼロのSession-タイムアウト値は首尾よく完成されていた状態で最初の認証がそうした直後別の認証(ことによると異なったタイプの)を実行する願望を示します。
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-挑戦で送ると、この属性はIEEE 802.1X Authenticatorが再送する前にEAP-応答を待つはずである秒の最大数を表します。 この場合、Session-タイムアウト属性は、IEEE 802.1Xのバックエンド州のマシンの中にsuppTimeout定数をロードするのに使用されます。
Congdon, et al. Informational [Page 11] RFC 3580 IEEE 802.1X RADIUS September 2003
コングドン、他 [11ページ]情報のRFC3580IEEE 802.1X半径2003年9月
3.18. Idle-Timeout
3.18. アイドルタイムアウト
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-タイムアウト属性は[RFC2865]で説明されます。 802.11以外のIEEE802メディアにおいて、メディアはいつもオンです。 その結果、Idle-タイムアウト属性はIEEE802.11などのワイヤレスのメディアで通常使用されるだけです。 ワイヤレス機器がすべてのAccess Pointsの範囲から離れているのは、可能です。 この場合、Idle-タイムアウト属性はワイヤレス機器が活動していないままで残るかもしれない最大の時間を示します。
3.19. Termination-Action
3.19. 終了動作
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-要求(1)は、再認証がSession-現代の満了のときに起こるべきであるのを示します。 値のDefault(0)は、セッションが終わるべきであるのを示します。
3.20. Called-Station-Id
3.20. 呼ばれた駅のイド
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 Authenticatorsに関しては、この属性はASCII書式(大文字専用)におけるブリッジかAccess Point MACアドレスを保存するのに使用されます、八重奏値が「-」によって切り離されている状態で。 例: 「00-10-A4-23-19-C0"。」 「IEEE802.11では、a」でMACアドレスと切り離されたAccess Point MACアドレスに追加してください。」(そこでは、SSIDが知られていて、それはSHOULDです)。 例の「00-10-A4-23-19-C0: AP1"。」
3.21. Calling-Station-Id
3.21. 呼んでいる駅のイド
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 Authenticatorsに関しては、この属性はASCII書式(大文字専用)におけるSupplicant MACアドレスを保存するのに使用されます、八重奏値が「-」によって切り離されている状態で。 例: 「00-10-A4-23-19-C0"。」
3.22. NAS-Identifier
3.22. NAS-識別子
This attribute contains a string identifying the IEEE 802.1X Authenticator originating the Access-Request.
この属性はAccess-要求を溯源するIEEE 802.1X Authenticatorを特定するストリングを含んでいます。
3.23. NAS-Port-Type
3.23. NASポートタイプ
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との使用のために、NASポートはタイプされます。イーサネット(15)ワイヤレスの値--IEEE802.11(19)、Token Ring(20)、およびFDDI(21)は使用されるかもしれません。
Congdon, et al. Informational [Page 12] RFC 3580 IEEE 802.1X RADIUS September 2003
コングドン、他 [12ページ]情報のRFC3580IEEE 802.1X半径2003年9月
3.24. Port-Limit
3.24. ポート限界
This attribute has no meaning when sent to an [IEEE8021X] Authenticator.
いいえが、[IEEE8021X]固有識別文字に送られることを意味して、この属性はそうしました。
3.25. Password-Retry
3.25. パスワード再試行
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では、Authenticatorは認証失敗の後にいつもHELD状態に移行します。 したがって、この属性はIEEE 802.1Xのために理解できません。
3.26. Connect-Info
3.26. インフォメーションを接続します。
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.
この属性は、Supplicantの接続の本質を示すためにブリッジかAccess Pointによって送られます。 Access要求で送ると、この属性がSupplicantの接続の速度の情報を含むのは、お勧めです。 802.11において、以下の形式はお勧めです: 「11Mbps 802.11bを接続してください。」 Accounting STOPで送るなら、セッション品質に関連する統計をまとめるのにこの属性を使用するかもしれません。 例えば、IEEE802.11では、Connect-インフォメーション属性はリンクレイヤ「再-トランスミッション」の数の情報を含むかもしれません。 この属性の正確な形式は実装特有です。
3.27. EAP-Message
3.27. EAP-メッセージ
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.
IEEE 802.1Xが[RFC2284]と[IEEE8021X]で説明されるようにEAPのカプセル化に備えるので、[RFC3579]で定義されたEAP-メッセージ属性はIEEE 802.1X AuthenticatorからAuthentication ServerまでのトランスミッションのためにパケットをEAPにカプセルに入れるのに使用されます。[RFC3579]セクション2.2はAuthentication ServerがどうAuthenticatorによってそれに通過された無効のEAPパケットを扱うかを説明します。
3.28. Message-Authenticator
3.28. メッセージ固有識別文字
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.に述べられるように、Message-固有識別文字属性はRADIUS/EAPの会話の中にパケットを保護するのにおいて使用されているに違いありません。
3.29. NAS-Port-Id
3.29. NASポートイド
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.
この属性は、Supplicantを認証するIEEE 802.1X Authenticatorポートを特定するのに使用されます。 NASポートイドはそれが可変長のストリングであるという点においてNAS-ポートと異なっていますが、NASポートは4八重奏価値です。
Congdon, et al. Informational [Page 13] RFC 3580 IEEE 802.1X RADIUS September 2003
コングドン、他 [13ページ]情報のRFC3580IEEE 802.1X半径2003年9月
3.30. Framed-Pool, Framed-IPv6-Pool
3.30. 縁どられたプールで、縁どられたIPv6は水たまりになります。
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アドレス課題にメカニズムを提供しません。 したがって、IPアドレスが割当機構であるとサポートするIEEE 802.1X AuthenticatorsはFramed-プールとFramed-IPv6-プール属性を使用できるだけです。通常、この能力は層の3デバイスによってサポートされます。
3.31. Tunnel Attributes
3.31. トンネル属性
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がトンネリングをサポートするところでは、強制的なトンネルは認証の結果、Supplicantに設定されるかもしれません。
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サーバは、トンネルを含んでいるのによる必要なVLANが、中でAccess受け入れるのを結果と考えるのを通常示します。 しかしながら、また、IEEE 802.1X Authenticatorは、Access要求の中にTunnel属性を含んでいることによってSupplicantに割り当てられるために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
トンネルタイプ=VLAN(13)トンネルミディアム・タイプ=802トンネル民間のグループの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が1と4094の間に値を取って、包括的に12ビットであることに注意してください。 タイプStringにはTunnelの個人的なグループIDがIEEE 802.1Xとの使用のために[RFC2868]で定義されるようにあるので、VLANID整数価値はストリングとしてコード化されます。
When Tunnel attributes are sent, it is necessary to fill in the Tag field. As noted in [RFC2868], section 3.1:
Tunnel属性を送るとき、Tag分野に記入するのが必要です。 [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).
Tag分野は、長さにおける1つの八重奏であり、同じトンネルについて言及する同じパケットで属性を分類する手段を提供することを意図します。 この分野への有効値は0x1Fを通した0×01です。包括的。 Tag分野が未使用であるなら、それはゼロであるに違いありません(0×00)。
Congdon, et al. Informational [Page 14] RFC 3580 IEEE 802.1X RADIUS September 2003
コングドン、他 [14ページ]情報のRFC3580IEEE 802.1X半径2003年9月
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クライアント終点、Tunnelサーバ終点、Tunnelの個人的なTunnelグループAssignment ID(ID)、TunnelクライアントAuth IDまたはTunnelサーバAuth ID属性がある使用(しかし、Tunnel-タイプでない、Tunnelの中くらいのタイプでない、Tunnel-パスワードでない、またはTunnel-好みでない)において、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.
代替手段がトンネルを堀らないならタイプを提供する、(例えば、VLANsではなく、トンネリングをサポートするかもしれないIEEE 802.1X Authenticatorsのための)、トンネル属性が単に単一のトンネルを指定するのが必要です。 その結果、VLANID、タグ・フィールドSHOULDを指定するために、それが必要であるだけであるところにすべてのトンネル属性で(0×00)のゼロを合わせるように設定されてください。 0×01と0x1F SHOULDの間のタグ値は代替のトンネルタイプがどこに提供されることになっているかが選ばれています。
4. RC4 EAPOL-Key Frame
4. RC4 EAPOL-キーフレーム
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主要なフレームは、特定の主要な情報をメディアに提供するためにAuthenticatorによって作成されて、伝えられます。 例えば、802.11の中では、マルチキャスト/放送(「デフォルト」)キー、またはユニキャスト(「主要なマッピング」)キーを分配するのにRC4 EAPOL主要なフレームを使用できます。 放送ドメインの中のすべての駅に、「デフォルト」キーは同じです。
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主要なフレームは認められません、そして、したがって、AuthenticatorはSupplicantがそれを受けたかどうかを知りません。 それが無くなると、SupplicantとAuthenticatorには、同じくらいが材料を合わせながら、ないでしょう、そして、コミュニケーションは失敗するでしょう。 これが起こるなら、問題は、認証を再放送することによって、通常扱われます。
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主要なフレームをAuthenticatorからSupplicantに送ります。 また、それは、キーを写像するキーをリフレッシュするのに使用されるかもしれません。 Rekeyが[IEEE80211]で定義されたWEPなどの弱いciphersuitesで通常必要であるだけです。
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メソッドは通常選択されます。 したがって、材料を合わせるEAPから初期の「主要なマッピング」キーを得ることができます、AuthenticatorがRC4 EAPOL主要なフレームをSupplicantに送る必要でない。 どう材料を合わせるEAPは引き出して、使用できるかに関する例は[RFC2716]に提示されます。
Congdon, et al. Informational [Page 15] RFC 3580 IEEE 802.1X RADIUS September 2003
コングドン、他 [15ページ]情報のRFC3580IEEE 802.1X半径2003年9月
While the RC4 EAPOL-Key frame is defined in [IEEE8021X], a more complete description is provided on the next page.
[IEEE8021X]でRC4 EAPOL主要なフレームを定義しますが、次のページで、より完全な記述を提供します。
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン| パケットタイプ| パケットボディーの長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| キー長|カウンタを再演してください… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | カウンタを再演してください… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 再生カウンタ| キーIV… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | キーIV… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | キーIV… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | キーIV… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | キーIV… |F| キー索引| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 調号… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 調号… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 調号… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 調号… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | キー… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Type Packet Typeがさばくパケットは、1つの八重奏であり、伝えられるパケットのタイプを決定します。 EAPOL主要なDescriptorに関しては、Packet Type分野は0×03を含んでいます。
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.
パケットBody Length Packet Body Lengthは2つの八重奏であり、八重奏における、EAPOL主要な記述子の長さを含んでいます、バージョン、Packet Type、およびPacket Body Length分野を含んでいなくて。
Congdon, et al. Informational [Page 16] RFC 3580 IEEE 802.1X RADIUS September 2003
コングドン、他 [16ページ]情報のRFC3580IEEE 802.1X半径2003年9月
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).
Typeがさばくタイプはただ一つの八重奏です。 Key記述子は各Typeのために異なって定義されます。 この仕様はRC4 Key Descriptorだけを記録します(=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.
Length Key Lengthがさばくキーは2つの八重奏です。 Packet Body Lengthが44+主要なLengthと等しいなら、Key Fieldは長さのKey Lengthの暗号化された形にキーを含んでいます。 これは、WEPのための5つの八重奏(40ビット)と、WEP-128のための13の八重奏(104ビット)です。 Packet Body Length=44であるなら、Key分野は欠けています、そして、Key Lengthは合わせることの材料として使用されるためにMPPEさんがキーを送っている属性[RFC2548]から最も重要でない八重奏の数を表します。 MPPEが主要な状態で発信しているMSとMPPE-Recv Key属性さんがAuthenticatorの観点から定義されることに注意してください。 参照のSupplicantポイントから、用語は逆にされます。 したがって、Supplicantの上のMPPE-Recv KeyさんはMPPEさんがキーをAuthenticatorに送ると対応します、そして、MPPEさんがキーをSupplicantに送るのはAuthenticatorの上の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.
Counter Replay Counterがさばく再生は8つの八重奏です。 それは材料がKey分野を暗号化して、Key Signature分野を計算するのに使用した合わせることの寿命の中で繰り返されません。 64ビットのNTPタイムスタンプはReplay Counterとして使用されるかもしれません。
Key IV
The Key IV field is 16 octets and includes a 128-bit
cryptographically random number.
Key IVがさばくキー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 Key旗の(F)は1ビットです、Key分野に含まれているキーのタイプについて説明して。 値は以下の通りです。
0 = for broadcast (default key)
1 = for unicast (key mapping key)
0 ユニキャストのための放送(デフォルトキー)1=のための=(主要なマッピングキー)
Key Index
The Key Index is 7 bits.
主要なIndex Key Indexは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.
Signature Key Signatureがさばくキーは16の八重奏です。 それはEAPOL主要な記述子に関して計算されたHMAC-MD5メッセージの保全チェックを含んでいます、存在しているなら記入されたKey分野にもかかわらず、ゼロに設定されたKey Signature分野でバージョン野原から始めて。 計算のために、MPPEさんがキーを送っている32八重奏(256ビット)[RFC2548]はHMAC-MD5キーとして使用されます。
Congdon, et al. Informational [Page 17] RFC 3580 IEEE 802.1X RADIUS September 2003
コングドン、他 [17ページ]情報のRFC3580IEEE 802.1X半径2003年9月
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).
主要なIf Packet Body Lengthは44+主要なLengthと等しく、次に、Key Fieldは長さのKey Lengthの暗号化された形にキーを含んでいます。 Packet Body Length=44であるなら、Key分野は欠けています、そして、MPPEさんがキーを送っている属性からの最も重要でないKey Length八重奏は合わせることの材料として使用されます。 Key分野がRC4を使用することで暗号化されているところでは、この分野を暗号化するのに使用されるRC4暗号化キーは、32八重奏MPPE-Recv Key属性さんで16八重奏(128ビット)主要なIV分野を連結することによって、形成されます。 これは48八重奏RC4キー(384ビット)をもたらします。
5. Security Considerations
5. セキュリティ問題
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
パケット変更か偽造DictionaryがReplay Outcomeミスマッチ802.11統合Key経営者側が発行するKnown平文攻撃を攻撃します。
5.1. Packet Modification or Forgery
5.1. パケット変更か偽造
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が、すべてのAccess-要求が認証されるのを必要としないか、または保全は保護されました。 しかしながら、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.
Access-要求、Access-挑戦がAccess受け入れるすべて、およびEAP-メッセージ属性を含むAccess-廃棄物パケットを保護するのにMessage-固有識別文字属性を使用しなければなりません。
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
セキュリティがRADIUS/EAPの脆弱性であると扱うために、この仕様SHOULDの実装はかぎ管理のために、IKE[RFC2409]に伴うIPsec[RFC2401]をサポートします。 IPsec、非ヌル変換SHOULDがサポートされている超能力[RFC2406]、IPsecの超能力のaによる非ヌルの暗号化変換、および認証
Congdon, et al. Informational [Page 18] RFC 3580 IEEE 802.1X RADIUS September 2003
コングドン、他 [18ページ]情報のRFC3580IEEE 802.1X半径2003年9月
support SHOULD be used to provide per-packet confidentiality,
authentication, integrity and replay protection. IKE SHOULD be
used for key management.
サポートSHOULDは1パケットあたりの秘密性、認証に保全を提供するのに使用されて、保護を再演します。 IKE SHOULD、かぎ管理には、使用されてください。
5.2. Dictionary Attacks
5.2. 辞書攻撃
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共有秘密キーはオフライン辞書攻撃に被害を受け易いです、Response AuthenticatorかMessage-固有識別文字属性の捕獲に基づいて。 脆弱性のレベル、[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.
さらに、オフライン辞書攻撃のリスクはIPsecを使うことによってさらに緩和されて、非ヌルがある超能力がRADIUSの会話を暗号化するために変形します、[RFC3579]で説明されるようにことであるかもしれません、セクション4.2。
5.3. Known Plaintext Attacks
5.3. 知られている平文攻撃
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がEAP(PAPをサポートしない)に基づいているので、RADIUS User-パスワード属性は隠されたユーザパスワードを運ぶのに使用されません。 隠れることメカニズムは、RADIUS共有秘密キーとRequest Authenticatorに基づく主要なストリームを生成するのに[RFC1321]で定義されたMD5を利用します。 PAPが使用中であるところでは、与えられたRequest Authenticator値に対応する主要なストリームを集めるのは可能です、RADIUSがPAP認証試みに対応する会話であると知られているパスワードを使用することでキャプチャすることによって。 Userパスワードが知られているので、与えられたRequest Authenticatorに対応する主要なストリームは、決定して、保存できます。
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 Authenticatorsは、PAPが認証であるとサポートしませんが、セキュリティの脆弱性は同じRADIUS共有秘密キーが他の属性と同様にUser-パスワードを隠すのに使用されるところにまだ存在できます。 例えば、同じRADIUSプロキシがIEEE 802.1X(Tunnel-パスワード、MPPEがキーを送るさん、およびMPPE-Recv Key属性さんを隠すかもしれない)とGPRS(User-パスワード属性を隠すかもしれない)の両方を求める認証要求を扱うなら、これは起こることができます。
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.
IPsecと非ヌルがある超能力が説明されるとして変形するRADIUS[RFC3579]を保護することによって、脅威を緩和できます、セクション4.2。 さらに、IEEE 802.1X認証とPAP認証の両方に同じRADIUS共有秘密キーを使用してはいけません。
Congdon, et al. Informational [Page 19] RFC 3580 IEEE 802.1X RADIUS September 2003
コングドン、他 [19ページ]情報のRFC3580IEEE 802.1X半径2003年9月
5.4. Replay
5.4. 再生
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プロトコルは反復操作による保護のための限定的なサポートだけを提供します。 IPsec反復操作による保護を可能にすることによって、RADIUS認証と会計のための反復操作による保護をRADIUSに提供できます、[RFC3579]で説明されるように、セクション4.2。
As with the Request Authenticator, for use with IEEE 802.1X Authenticators, the Acct-Session-Id SHOULD be globally and temporally unique.
AcctセッションイドSHOULDはグローバルで時間的にRequest Authenticator、IEEE 802.1X Authenticatorsとの使用のための、そうです。ユニーク。
5.5. Outcome Mismatches
5.5. 結果ミスマッチ
[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-メッセージ属性でカプセルに入れられたEAPパケットがRADIUS Packet Typeに同意しないと起こる問題について議論します。 例えば、EAP SuccessパケットはAccess-廃棄物の中にカプセルに入れられるかもしれません。 EAP Failureを送るかもしれない、Access受け入れてください。 または、Access-挑戦の中でEAP SuccessかFailureを送るかもしれません。
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が唯一認証結果(アクセスして受け入れるか、または拒絶する)に基づいていて、EAP-メッセージ属性のコンテンツに基づかない決定はするのに必要であって、存在しています。
5.6. 802.11 Integration
5.6. 802.11 統合
[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]は、イーサネットなどのワイヤードなIEEE802ネットワークにおける使用のために開発されて、したがって、使用のために802.11でしっかりとIEEE 802.1Xを適合させる方法を説明しません。 これはIEEE802.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]は、認証が協会の前か協会の後に起こるかどうかと、派生しているキーが様々なciphersuitesの中でどのように使用されるかを指定しません。 また、それは[バークレー]で説明されたWEP[Arbaugh]、[Fluhrer]、および[Stubbl]で発見された脆弱性を扱うciphersuitesを指定しません。 [RFC2716]などの他のドキュメントに認証方法の定義を残して、[IEEE8021X]は認証フレームワークを定義するだけです。
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
[IEEE8021X]が802.11統合冊をどんなアドレスにもしないので、作成者が追加IEEEに相談するように強くアドバイスされます。指導のための使用のために802.11でどうIEEE 802.1Xを適合させるかに関する802.11のセキュリティ仕様。 例えば、それがありそうである、それ、IEEE802.11
Congdon, et al. Informational [Page 20] RFC 3580 IEEE 802.1X RADIUS September 2003
コングドン、他 [20ページ]情報のRFC3580IEEE 802.1X半径2003年9月
enhanced security specification will define its own IEEE 802.11 key hierarchy as well as new EAPOL-Key descriptors.
警備の強化仕様は新しいEAPOL主要な記述子と同様にそれ自身のIEEE802.11の主要な階層構造を定義するでしょう。
5.7. Key Management Issues
5.7. Key Management問題
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主要な記述子は未来に推奨しない傾向があります。(その時、IEEE802.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]で知られている1駅あたりのユニキャストキーの派生を可能にします。 マルチキャスト/放送トラフィックを暗号化するのに使用されるキーは「デフォルトキー」として知られています。 そして、しかしながら、およそ802.11の実装に、EAP認証過程の一部として引き出されたユニキャストキーが唯一使用される、暗号化、認証、保全はEAPOL主要な記述子を保護します、セクション4で説明されるように。 これらの実装はすべてのトラフィック、ユニキャストまたはマルチキャスト/放送を保証するためにデフォルトキー(通常、マルチキャスト/放送トラフィックと共に使用されるだけである)の使用をサポートするだけです、固有のセキュリティ弱点をもたらして。
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].
1駅あたりのキーを写像するキー(例えば、ユニキャストキー)がサポートされないところでは、デフォルトキーを所有しているどんな駅も、他の駅からトラフィックを解読するか、またはそれらをまねることができます。 弱い暗号(例えば、WEP)と共に使用されると、唯一のデフォルトがキーであるとサポートする実装が[Fluhrer]と[Stubbl]で説明されたものなどの攻撃のための、より多くの材料を供給します。 デフォルトキーが定期的にさらに、リフレッシュされないなら、IEEE 802.1Xのダイナミックな主要な派生はまずセキュリティ利益を提供しません。 WEPの問題の理解に関しては、[バークレー]、[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] 合わせることの材料の再利用。 EAPOL主要な記述子は、EAPOL主要な記述子の中でともにKey分野を暗号化して、駅とAccess Pointの間で通過されたデータを暗号化するために、材料(MPPE-Recv Keyさん)を合わせながら、セクション4用途で同じように指定しました。 複数の用途が攻撃者にとって役立っていた状態で情報を漏らすことができるので、多目的の合わせることの材料は反対されます。
[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分野を暗号化するのに使用されるアルゴリズムは結果として同様であり、シェアは同じ弱点のいくつかです。 WEPのように、RC4ストリーム暗号は、キーを暗号化するのに使用されます。 RC4エンジンに入力されるように、IVとキーは混合機能の中で結合されるよりむしろ連結されます。 WEPのように、IVはカウンタではありません、そして、したがって、再利用に対する保護がほとんどありません。
Congdon, et al. Informational [Page 21] RFC 3580 IEEE 802.1X RADIUS September 2003
コングドン、他 [21ページ]情報のRFC3580IEEE 802.1X半径2003年9月
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.
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.
6. IANA Considerations
6. IANA Considerations
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:
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:
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)
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)
7. References
7. References
7.1. Normative References
7.1. Normative References
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC
1321, April 1992.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible
Authentication Protocol (EAP)", RFC 2284, March 1998.
[RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
[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. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2867] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting
Modifications for Tunnel Protocol Support", RFC 2867,
June 2000.
[RFC2867] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting Modifications for Tunnel Protocol Support", RFC 2867, June 2000.
Congdon, et al. Informational [Page 22] RFC 3580 IEEE 802.1X RADIUS September 2003
Congdon, et al. Informational [Page 22] RFC 3580 IEEE 802.1X RADIUS September 2003
[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. and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000.
[RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS
Extensions", RFC 2869, June 2000.
[RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000.
[RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6",
RFC 3162, August 2001.
[RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
[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. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
[IEEE8021X] IEEE Standards for Local and Metropolitan Area
Networks: Port based Network Access Control, IEEE Std
802.1X-2001, June 2001.
[IEEE8021X] IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE Std 802.1X-2001, June 2001.
7.2. Informative References
7.2. Informative References
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC
2434, October 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS
Attributes", RFC 2548, March 1999.
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999.
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and
Policy Implementation in Roaming", RFC 2607, June
1999.
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999.
[RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication
Protocol", RFC 2716, October 1999.
[RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", RFC 2716, October 1999.
Congdon, et al. Informational [Page 23] RFC 3580 IEEE 802.1X RADIUS September 2003
Congdon, et al. Informational [Page 23] RFC 3580 IEEE 802.1X RADIUS September 2003
[MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent
Attack." CryptoBytes Vol.2 No.2, Summer 1996.
[MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack." CryptoBytes Vol.2 No.2, Summer 1996.
[IEEE802] IEEE Standards for Local and Metropolitan Area
Networks: Overview and Architecture, ANSI/IEEE Std
802, 1990.
[IEEE802] IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture, 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 Standards for Local and Metropolitan Area Networks: Draft Standard for Virtual Bridged Local Area Networks, P802.1Q, January 1998.
[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 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.
[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] 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.
[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. 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.
[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. Wan, "Your 802.11 Wireless Network has No Clothes", Department of Computer Science, University of Maryland, College Park, March 2001.
[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. and A. Shamir, "Weaknesses in the Key Scheduling Algorithm of RC4", Eighth Annual Workshop on Selected Areas in Cryptography, Toronto, Canada, August 2001.
[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. and A. Rubin, "Using the Fluhrer, Mantin and Shamir Attack to Break WEP", 2002 NDSS Conference.
Congdon, et al. Informational [Page 24] RFC 3580 IEEE 802.1X RADIUS September 2003
Congdon, et al. Informational [Page 24] RFC 3580 IEEE 802.1X RADIUS September 2003
8. Table of Attributes
8. Table of Attributes
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.
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.
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 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
Congdon, et al. Informational [Page 25] RFC 3580 IEEE 802.1X RADIUS September 2003
Congdon, et al. Informational [Page 25] RFC 3580 IEEE 802.1X RADIUS September 2003
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 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
Congdon, et al. Informational [Page 26] RFC 3580 IEEE 802.1X RADIUS September 2003
Congdon, et al. Informational [Page 26] RFC 3580 IEEE 802.1X RADIUS September 2003
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
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
Key === X = May be used with IEEE 802.1X authentication L3 = Implemented only by Authenticators with Layer 3 capabilities
Congdon, et al. Informational [Page 27] RFC 3580 IEEE 802.1X RADIUS September 2003
Congdon, et al. Informational [Page 27] RFC 3580 IEEE 802.1X RADIUS September 2003
9. Intellectual Property Statement
9. Intellectual Property Statement
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.
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.
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.
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.
10. Acknowledgments
10. Acknowledgments
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.
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.
Congdon, et al. Informational [Page 28] RFC 3580 IEEE 802.1X RADIUS September 2003
Congdon, et al. Informational [Page 28] RFC 3580 IEEE 802.1X RADIUS September 2003
11. Authors' Addresses
11. Authors' Addresses
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
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
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
Phone: +1 425 706 6605 Fax: +1 425 936 7329 EMail: bernarda@microsoft.com
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. Pleasanton, CA 94588-4084
Fax: +1 415 345 1827 EMail: ah_smith@acm.org
Fax: +1 415 345 1827 EMail: ah_smith@acm.org
John Roese Enterasys
John Roese Enterasys
Phone: +1 603 337 1506 EMail: jjr@enterasys.com
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
Phone: +1 425 438 8218 Fax: +1 425 438 1848 EMail: gwz@cisco.com
Congdon, et al. Informational [Page 29] RFC 3580 IEEE 802.1X RADIUS September 2003
Congdon, et al. Informational [Page 29] RFC 3580 IEEE 802.1X RADIUS September 2003
12. Full Copyright Statement
12. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
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.
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.
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
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.
Funding for the RFC Editor function is currently provided by the Internet Society.
Congdon, et al. Informational [Page 30]
Congdon, et al. Informational [Page 30]
一覧
スポンサーリンク
