RFC4072 日本語訳
4072 Diameter Extensible Authentication Protocol (EAP) Application. P.Eronen, Ed., T. Hiller, G. Zorn. August 2005. (Format: TXT=79965 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Eronen, Ed.
Request for Comments: 4072 Nokia
Category: Standards Track T. Hiller
Lucent Technologies
G. Zorn
Cisco Systems
August 2005
ワーキンググループP.Eronen、エドをネットワークでつないでください。コメントのために以下を要求してください。 4072年のノキアカテゴリ: 標準化過程T.培土板ルーセントテクノロジーズG.ゾルンシスコシステムズ2005年8月
Diameter Extensible Authentication Protocol (EAP) Application
直径拡張認証プロトコル(EAP)アプリケーション
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
The Extensible Authentication Protocol (EAP) provides a standard mechanism for support of various authentication methods. This document defines the Command-Codes and AVPs necessary to carry EAP packets between a Network Access Server (NAS) and a back-end authentication server.
拡張認証プロトコル(EAP)は様々な認証方法のサポートに標準のメカニズムを提供します。 このドキュメントはCommand-コードとNetwork Access Server(NAS)とバックエンド認証サーバの間までEAPパケットを運ぶのに必要なAVPsを定義します。
Table of Contents
目次
1. Introduction ...................................................2
1.1. Conventions Used in This Document ........................3
2. Extensible Authentication Protocol Support in Diameter .........3
2.1. Advertising Application Support ..........................3
2.2. Protocol Overview ........................................4
2.3. Sessions and NASREQ Interaction ..........................6
2.3.1. Scenario 1: Direct Connection .....................7
2.3.2. Scenario 2: Direct Connection with Redirects ......8
2.3.3. Scenario 3: Direct EAP, Authorization via Agents ..9
2.3.4. Scenario 4: Proxy Agents .........................10
2.4. Invalid Packets .........................................10
2.5. Retransmission ..........................................11
2.6. Fragmentation ...........................................12
2.7. Accounting ..............................................12
2.8. Usage Guidelines ........................................13
1. 序論…2 1.1. このドキュメントで中古のコンベンション…3 2. 直径における拡張認証プロトコルサポート…3 2.1. 広告アプリケーションサポート…3 2.2. 概要について議定書の中で述べてください…4 2.3. セッションとNASREQ相互作用…6 2.3.1. シナリオ1: 接続を指示してください…7 2.3.2. シナリオ2: 接続を指示する、向け直します。8 2.3.3. シナリオ3: エージェントを通してEAP、Authorizationを指示してください。9 2.3.4. シナリオ4: プロキシエージェント…10 2.4. 無効のパケット…10 2.5. Retransmission…11 2.6. 断片化…12 2.7. 会計…12 2.8. 用法ガイドライン…13
Eronen, et al. Standards Track [Page 1] RFC 4072 Diameter EAP Application August 2005
Eronen、他 規格は直径EAPアプリケーション2005年8月にRFC4072を追跡します[1ページ]。
2.8.1. User-Name AVP ....................................13
2.8.2. Conflicting AVPs .................................13
2.8.3. Displayable Messages .............................14
2.8.4. Role Reversal ....................................14
2.8.5. Identifier Space .................................14
3. Command-Codes .................................................14
3.1. Diameter-EAP-Request (DER) Command ......................15
3.2. Diameter-EAP-Answer (DEA) Command .......................16
4. Attribute-Value Pairs .........................................18
4.1. New AVPs ................................................18
4.1.1. EAP-Payload AVP ..................................18
4.1.2. EAP-Reissued-Payload AVP .........................18
4.1.3. EAP-Master-Session-Key AVP .......................19
4.1.4. EAP-Key-Name AVP .................................19
4.1.5. Accounting-EAP-Auth-Method AVP ...................19
5. AVP Occurrence Tables .........................................19
5.1. EAP Command AVP Table ...................................20
5.2. Accounting AVP Table ....................................21
6. RADIUS/Diameter Interactions ..................................22
6.1. RADIUS Request Forwarded as Diameter Request ............22
6.2. Diameter Request Forwarded as RADIUS Request ............23
6.3. Accounting Requests .....................................24
7. IANA Considerations ...........................................24
8. Security Considerations .......................................24
8.1. Overview ................................................24
8.2. AVP Editing .............................................26
8.3. Negotiation Attacks .....................................27
8.4. Session Key Distribution ................................28
8.5. Privacy Issues ..........................................28
8.6. Note about EAP and Impersonation ........................29
9. Acknowledgements ..............................................29
10. References ....................................................30
10.1. Normative References ....................................30
10.2. Informative References ..................................30
2.8.1. ユーザ名AVP…13 2.8.2. 闘争しているAVPs…13 2.8.3. Displayableメッセージ…14 2.8.4. 役割の反転…14 2.8.5. 識別子スペース…14 3. コマンドコード…14 3.1. 直径EAP要求(DER)は命令します…15 3.2. 直径EAP答え(DEA)命令…16 4. 属性値ペア…18 4.1. 新しいAVPs…18 4.1.1. EAP-有効搭載量AVP…18 4.1.2. EAPが有効搭載量を再発行しているAVP…18 4.1.3. EAPマスターセッションキーAVP…19 4.1.4. EAPの主要な名のAVP…19 4.1.5. 会計EAP-AuthメソッドAVP…19 5. AVP発生テーブル…19 5.1. EAPはAVPテーブルを命令します…20 5.2. AVPが見送る会計…21 6. 半径/直径相互作用…22 6.1. 直径要求として転送された半径要求…22 6.2. 半径要求として転送された直径要求…23 6.3. 会計要求…24 7. IANA問題…24 8. セキュリティ問題…24 8.1. 概要…24 8.2. AVP編集…26 8.3. 交渉は攻撃されます…27 8.4. セッションの主要な分配…28 8.5. プライバシー問題…28 8.6. EAPとものまねに関して、注意します。29 9. 承認…29 10. 参照…30 10.1. 標準の参照…30 10.2. 有益な参照…30
1. Introduction
1. 序論
The Extensible Authentication Protocol (EAP), defined in [EAP], is an authentication framework which supports multiple authentication mechanisms. EAP may be used on dedicated links, switched circuits, and wired as well as wireless links.
[EAP]で定義された拡張認証プロトコル(EAP)は複数の認証がメカニズムであるとサポートする認証フレームワークです。EAPは専用リンク、交換回線網、およびワイヤードでワイヤレスのリンクの上に使用されるかもしれません。
To date, EAP has been implemented with hosts and routers that connect via switched circuits or dial-up lines using PPP [RFC1661], IEEE 802 wired switches [IEEE-802.1X], and IEEE 802.11 wireless access points [IEEE-802.11i]. EAP has also been adopted for IPsec remote access in IKEv2 [IKEv2].
これまで、EAPはPPP[RFC1661]を使用することで交換回線網かダイヤルアップ系列で接するホストとルータで実装されて、IEEE802はスイッチ[IEEE-802.1X]、およびIEEE802.11のワイヤレスのアクセスポイント[IEEE-802.11i]を配線しました。 また、EAPはIKEv2[IKEv2]のIPsec遠隔アクセスのために採用されました。
Eronen, et al. Standards Track [Page 2] RFC 4072 Diameter EAP Application August 2005
Eronen、他 規格は直径EAPアプリケーション2005年8月にRFC4072を追跡します[2ページ]。
This document specifies the Diameter EAP application that carries EAP packets between a Network Access Server (NAS) working as an EAP Authenticator and a back-end authentication server. The Diameter EAP application is based on the Diameter Network Access Server Application [NASREQ] and is intended for environments similar to NASREQ.
このドキュメントはEAP Authenticatorとして働きながらNetwork Access Server(NAS)の間にEAPパケットを載せるDiameter EAPアプリケーションとバックエンド認証サーバを指定します。Diameter EAPアプリケーションは、Diameter Network Accessサーバーアプリケーション[NASREQ]に基づいていて、NASREQと同様の環境のために意図します。
In the Diameter EAP application, authentication occurs between the EAP client and its home Diameter server. This end-to-end authentication reduces the possibility for fraudulent authentication, such as replay and man-in-the-middle attacks. End-to-end authentication also provides a possibility for mutual authentication, which is not possible with PAP and CHAP in a roaming PPP environment.
Diameter EAPアプリケーションでは、認証はEAPクライアントとそのホームDiameterサーバの間に起こります。終わりから終わりへのこの認証は詐欺的な認証のために可能性を減少させます、再生と中央の男性攻撃などのように。 また、終わりから終わりへの認証は互いの認証に可能性を提供します。(それは、ローミングPPP環境でPAPとCHAPで可能ではありません)。
The Diameter EAP application relies heavily on [NASREQ], and in earlier versions was part of the Diameter NASREQ application. It can also be used in conjunction with NASREQ, selecting the application based on the user authentication mechanism (EAP or PAP/CHAP). The Diameter EAP application defines new Command-Codes and Attribute- Value Pairs (AVPs), and can work together with RADIUS EAP support [RFC3579].
Diameter EAPアプリケーションは、大いに[NASREQ]を当てにして、以前のバージョンのDiameter NASREQアプリケーションの一部でした。 また、NASREQに関連してそれを使用できます、ユーザー認証メカニズム(EAPかPAP/CHAP)に基づくアプリケーションを選択して。 Diameter EAPアプリケーションは、新しいCommand-コードとAttribute値のペア(AVPs)を定義して、RADIUS EAPサポート[RFC3579]と共に動作できます。
1.1. Conventions Used in This Document
1.1. 本書では使用されるコンベンション
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]で説明されるように本書では解釈されることであるべきですか?
2. Extensible Authentication Protocol Support in Diameter
2. 直径における拡張認証プロトコルサポート
2.1. Advertising Application Support
2.1. 広告アプリケーションサポート
Diameter nodes conforming to this specification MUST advertise support by including the Diameter EAP Application ID value of 5 in the Auth-Application-Id AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer command [BASE].
この仕様に従う直径ノードは、Capabilities交換要求とCapabilities交換答え命令[基地]のAuthアプリケーションイドAVPの5のDiameter EAP Application ID価値を含んでいることによって、サポートの広告を出さなければなりません。
If the NAS receives a response with the Result-Code set to DIAMETER_APPLICATION_UNSUPPORTED [BASE], it indicates that the Diameter server in the home realm does not support EAP. If possible, the access device MAY attempt to negotiate another authentication protocol, such as PAP or CHAP. An access device SHOULD be cautious when determining whether a less secure authentication protocol will be used, since this could result from a downgrade attack (see Section 8.3).
NASがDIAMETER_APPLICATION_UNSUPPORTED[基地]にResult-コードセットとの応答を受けるなら、それは、ホーム分野のDiameterサーバがEAPをサポートしないのを示します。 できれば、アクセスデバイスは、PAPかCHAPなどの別の認証プロトコルを交渉するのを試みるかもしれません。 デバイスSHOULDにアクセスしてください。それほど安全でない認証プロトコルが使用されるかどうか決定するときには用心深くいてください、これがダウングレード攻撃から生じるかもしれないので(セクション8.3を見てください)。
Eronen, et al. Standards Track [Page 3] RFC 4072 Diameter EAP Application August 2005
Eronen、他 規格は直径EAPアプリケーション2005年8月にRFC4072を追跡します[3ページ]。
2.2. Protocol Overview
2.2. プロトコル概要
The EAP conversation between the authenticating peer and the access device begins with the initiation of EAP within a link layer, such as PPP [RFC1661] or IEEE 802.11i [IEEE-802.11i]. Once EAP has been initiated, the access device will typically send a Diameter-EAP- Request message with an empty EAP-Payload AVP to the Diameter server, signifying an EAP-Start.
認証している同輩とアクセスデバイスとのEAPの会話はEAPの開始と共にリンクレイヤの中で始まります、PPP[RFC1661]やIEEE 802.11i[IEEE-802.11i]のように。 EAPがいったん開始されると、アクセスデバイスは空のEAP-有効搭載量AVPがあるDiameter-EAP要求メッセージをDiameterサーバに通常送るでしょう、EAP-始めを意味して。
If the Diameter home server is willing to do EAP authentication, it responds with a Diameter-EAP-Answer message containing an EAP-Payload AVP that includes an encapsulated EAP packet. The Result-Code AVP in the message will be set to DIAMETER_MULTI_ROUND_AUTH, signifying that a subsequent request is expected. The EAP payload is forwarded by the access device to the EAP client. This is illustrated in the diagram below.
Diameterホームサーバが、EAPに認証しても構わないと思っているなら、Diameter-EAP-答えメッセージがカプセル化されたEAPパケットを含んでいるEAP-有効搭載量AVPを含んでいて、それは応じます。 その後の要求が予想されるのを意味して、メッセージのResult-コードAVPはDIAMETER_MULTI_ROUND_AUTHに用意ができるでしょう。 アクセスデバイスはEAPペイロードをEAPクライアントに送ります。 これは以下のダイヤグラムで例証されます。
User NAS Server
| | |
| (initiate EAP) | |
|<------------------------------>| |
| | Diameter-EAP-Request |
| | EAP-Payload(EAP Start) |
| |------------------------------->|
| | |
| | Diameter-EAP-Answer |
| Result-Code=DIAMETER_MULTI_ROUND_AUTH |
| | EAP-Payload(EAP Request #1) |
| |<-------------------------------|
| EAP Request #1 | |
|<-------------------------------| |
: : :
: ...continues... :
ユーザNASサーバ| | | | (開始EAP) | | |<------------------------------>| | | | 直径EAP要求| | | EAP-有効搭載量(EAPは始まります)| | |------------------------------->| | | | | | 直径EAP答え| | 結果コードは_AUTHの周りで直径_マルチ_と等しいです。| | | EAP-有効搭載量(EAP要求#1)| | |<-------------------------------| | EAP要求#1| | |<-------------------------------| | : : : : ...続きます… :
The initial Diameter-EAP-Answer in a multi-round exchange normally includes an EAP-Request/Identity, requesting the EAP client to identify itself. Upon receipt of the EAP client's EAP-Response, the access device will then issue a second Diameter-EAP-Request message, with the client's EAP payload encapsulated within the EAP-Payload AVP.
それ自体を特定するようEAPクライアントに要求して、通常、マルチラウンド交換における初期のDiameter-EAP-答えはEAP-要求/アイデンティティを含んでいます。 EAPクライアントのEAP-応答を受け取り次第、アクセスデバイスは次に、第2のDiameter-EAP-要求メッセージを発行するでしょう、クライアントのEAPペイロードがEAP-有効搭載量AVPの中でカプセル化されている状態で。
A preferred approach is for the access device to issue the EAP-Request/Identity message to the EAP client, and forward the EAP-Response/Identity packet, encapsulated within the EAP-Payload AVP, as a Diameter-EAP-Request to the Diameter server (see the diagram below). This alternative reduces the number of Diameter message round trips. When the EAP-Request/Identity message is issued by the access device, it SHOULD interpret the EAP-Response/Identity
好ましい方法は、アクセスデバイスがDiameter-EAP-要求としてDiameterサーバにEAP-要求/アイデンティティメッセージをEAPクライアントに発行して、EAP-有効搭載量AVPの中でカプセルに入れられたEAP-応答/アイデンティティパケットを送る(以下のダイヤグラムを見てください)ことです。 この代替手段はDiameterメッセージ周遊旅行の数を減少させます。 アクセスデバイスでEAP-要求/アイデンティティメッセージを発行して、それがSHOULDである、EAP-応答/アイデンティティを解釈してください。
Eronen, et al. Standards Track [Page 4] RFC 4072 Diameter EAP Application August 2005
Eronen、他 規格は直径EAPアプリケーション2005年8月にRFC4072を追跡します[4ページ]。
packet returned by the authenticating peer, and copy its value to a User-Name AVP in Diameter-EAP-Request. This is useful in roaming environments, since the Destination-Realm is needed for routing purposes. Note that this alternative cannot be universally employed, as there are circumstances in which a user's identity is not needed (such as when authorization occurs based on a calling or called phone number).
パケットは認証している同輩で戻りました、そして、Diameter-EAP-要求におけるUser-名前AVPに値をコピーしてください。 Destination-分野がルーティング目的に必要であるので、これはローミング環境で役に立ちます。 一般にこの代替手段を使うことができないことに注意してください、ユーザのアイデンティティは必要でない事情(承認が呼ぶか呼ばれた電話番号に基づいて起こる時などの)があるとき。
User NAS Server
| | |
| (initiate EAP) | |
|<------------------------------>| |
| | |
| EAP Request(Identity) | |
|<-------------------------------| |
| | |
| EAP Response(Identity) | |
|------------------------------->| |
| | Diameter-EAP-Request |
| | EAP-Payload(EAP Response) |
| |------------------------------->|
: : :
: ...continues... :
ユーザNASサーバ| | | | (開始EAP) | | |<------------------------------>| | | | | | EAPは(アイデンティティ)を要求します。| | |<-------------------------------| | | | | | EAP応答(アイデンティティ)| | |------------------------------->| | | | 直径EAP要求| | | EAP-有効搭載量(EAP応答)| | |------------------------------->| : : : : ...続きます… :
The conversation continues until the Diameter server sends a Diameter-EAP-Answer with a Result-Code AVP indicating success or failure, and an optional EAP-Payload. The Result-Code AVP is used by the access device to determine whether service is to be provided to the EAP client. The access device MUST NOT rely on the contents of the optional EAP-Payload to determine whether service is to be provided.
DiameterサーバがResult-コードAVPが成否を示しているDiameter-EAP-答え、および任意のEAP-有効搭載量を送るまで、会話は続きます。 Result-コードAVPはアクセスデバイスによって使用されて、サービスがEAPクライアントに提供されるかどうかことであることを決定します。 アクセスデバイスは、サービスが提供されるかどうかことであることを決定するために任意のEAP-有効搭載量のコンテンツを当てにしてはいけません。
Eronen, et al. Standards Track [Page 5] RFC 4072 Diameter EAP Application August 2005
Eronen、他 規格は直径EAPアプリケーション2005年8月にRFC4072を追跡します[5ページ]。
: ...continued... :
: : :
| EAP Response #N | |
|------------------------------->| |
| | Diameter-EAP-Request |
| | EAP-Payload(EAP Response #N) |
| |------------------------------->|
| | |
| | Diameter-EAP-Answer |
| | Result-Code=DIAMETER_SUCCESS |
| | EAP-Payload(EAP Success) |
| | [EAP-Master-Session-Key] |
| | (authorization AVPs) |
| |<-------------------------------|
| | |
| EAP Success | |
|<-------------------------------| |
: ...続けられる… : : : : | EAP応答#N| | |------------------------------->| | | | 直径EAP要求| | | EAP-有効搭載量(EAP応答#N)| | |------------------------------->| | | | | | 直径EAP答え| | | 結果コードは直径_成功と等しいです。| | | EAP-有効搭載量(EAP成功)| | | [EAPマスターセッションキー]| | | (承認AVPs) | | |<-------------------------------| | | | | EAP成功| | |<-------------------------------| |
If authorization was requested, a Diameter-EAP-Answer with Result-Code set to DIAMETER_SUCCESS SHOULD also include the appropriate authorization AVPs required for the service requested (see Section 5 and [NASREQ]). In some cases, the home server may not be able to provide all necessary authorization AVPs; in this case, a separate authorization step MAY be used as described in Section 2.3.3. Diameter-EAP-Answer messages whose Result-Code AVP is set to DIAMETER_MULTI_ROUND_AUTH MAY include authorization AVPs.
また、承認が要求されたなら、DIAMETER_SUCCESS SHOULDへのResult-コードセットとのDiameter-EAP-答えは要求されたサービスに必要である適切な承認AVPsを含んでいます(セクション5と[NASREQ]を見てください)。 いくつかの場合、ホームサーバはすべての必要な承認AVPsを提供できないかもしれません。 この場合、別々の承認ステップはセクション2.3.3で説明されるように使用されているかもしれません。 Result-コードAVPがDIAMETER_MULTI_ROUND_AUTH MAYに用意ができている直径EAP答えメッセージは承認AVPsを含んでいます。
A Diameter-EAP-Answer with successful Result-Code MAY also include an EAP-Master-Session-Key AVP that contains keying material for protecting the communication between the user and the NAS. Exactly how this keying material is used depends on the link layer in question, and is beyond the scope of this document.
また、うまくいっているResult-コードとのDiameter-EAP-答えはユーザとNASとのコミュニケーションを保護するために合わせることの材料を含むEAPマスターセッションキーAVPを含むかもしれません。 この合わせることの材料がちょうどどう使用されているかは、問題のリンクレイヤによって、このドキュメントの範囲を超えています。
A home Diameter server MAY request EAP re-authentication by issuing the Re-Auth-Request [BASE] message to the Diameter client.
ホームDiameterサーバは、Re-Auth-要求[基地]メッセージをDiameterクライアントに発行することによって、EAP再認証を要求するかもしれません。
Should an EAP authentication session be interrupted due to a home server failure, the session MAY be directed to an alternate server, but the authentication session will have to be restarted from the beginning.
EAP認証セッションはホームサーバ失敗のため中断されるべきですが、セッションは代替のサーバに向けられるかもしれませんが、認証セッションは始めから再開されなければならないでしょう。
2.3. Sessions and NASREQ Interaction
2.3. セッションとNASREQ相互作用
The previous section introduced the basic protocol between the NAS and the home server. Since the Diameter-EAP-Answer message may include a Master Session Key (MSK) for protecting the communication between the user and the NAS, one must ensure that this key does not fall into wrong hands.
前項はNASとホームサーバに基本プロトコルを取り入れました。Diameter-EAP-答えメッセージがユーザとNASとのコミュニケーションを保護するためのMaster Session Key(MSK)を含むかもしれないので、このキーが間違った手にならないのを確実にしなければなりません。
Eronen, et al. Standards Track [Page 6] RFC 4072 Diameter EAP Application August 2005
Eronen、他 規格は直径EAPアプリケーション2005年8月にRFC4072を追跡します[6ページ]。
Basic Diameter security mechanisms (IPsec and TLS) protect Diameter messages hop-by-hop. Since there are currently no end-to-end (NAS-to-home server) security mechanisms defined for Diameter, this section describes possible scenarios on how the messages could be transport protected using these hop-by-hop mechanisms.
基本的なDiameterセキュリティー対策(IPsecとTLS)はホップごとにDiameterメッセージを保護します。 現在の終わりから終わりがないこと(NASからホームサーバ)に、Diameterのために定義されたセキュリティー対策がないので、このセクションはメッセージがどうホップごとのこれらのメカニズムを使用することで保護された輸送であるかもしれないかに関する可能なシナリオについて説明します。
This list of scenarios is not intended to be exhaustive, and it is possible to combine them. For instance, the first proxy agent after the NAS could use redirects as in Scenario 2 to bypass any additional proxy agents.
シナリオのこのリストが徹底的であることを意図しないで、それらを結合するのは可能です。 例えば、第1代NASの後のエージェントが使用できたプロキシは、どんな追加プロキシエージェントも迂回させるために同じくらい中でScenario2を向け直します。
2.3.1. Scenario 1: Direct Connection
2.3.1. シナリオ1: ダイレクト接続
The simplest case is when the NAS contacts the home server directly. All authorization AVPs and EAP keying material are delivered by the home server.
最も簡単なケースはNASが直接ホームサーバに連絡する時です。 すべての承認AVPsと材料を合わせるEAPがホームサーバによって提供されます。
NAS home server
| |
| Diameter-EAP-Request |
| Auth-Request-Type=AUTHORIZE_AUTHENTICATE |
| EAP-Payload(EAP Start) |
|---------------------------------------------------------------->|
| |
| Diameter-EAP-Answer |
| Result-Code=DIAMETER_MULTI_ROUND_AUTH |
| EAP-Payload(EAP Request) |
|<----------------------------------------------------------------|
| |
: ...more EAP Request/Response pairs... :
| |
| Diameter-EAP-Request |
| EAP-Payload(EAP Response) |
|---------------------------------------------------------------->|
| |
| Diameter-EAP-Answer |
| Result-Code=DIAMETER_SUCCESS |
| EAP-Payload(EAP Success) |
| EAP-Master-Session-Key |
| (authorization AVPs) |
|<----------------------------------------------------------------|
NASホームサーバ| | | 直径EAP要求| | =が権限を与える要求タイプをAuthしている_は認証します。| | EAP-有効搭載量(EAPは始まります)| |---------------------------------------------------------------->| | | | 直径EAP答え| | 結果コードは_AUTHの周りで直径_マルチ_と等しいです。| | EAP-有効搭載量(EAP要求)| |<----------------------------------------------------------------| | | : ...より多くのEAP Request/応答が対にされます… : | | | 直径EAP要求| | EAP-有効搭載量(EAP応答)| |---------------------------------------------------------------->| | | | 直径EAP答え| | 結果コードは直径_成功と等しいです。| | EAP-有効搭載量(EAP成功)| | EAPマスターセッションキー| | (承認AVPs) | |<----------------------------------------------------------------|
This scenario is the most likely to be used in small networks, or in cases where Diameter agents are not needed to provide routing or additional authorization AVPs.
このシナリオは小さいネットワーク、ルーティングがDiameterエージェントが提供される必要はないケースまたは追加承認AVPsで最も使用されそうです。
Eronen, et al. Standards Track [Page 7] RFC 4072 Diameter EAP Application August 2005
Eronen、他 規格は直径EAPアプリケーション2005年8月にRFC4072を追跡します[7ページ]。
2.3.2. Scenario 2: Direct Connection with Redirects
2.3.2. シナリオ2: 接続を指示する、向け直す。
In this scenario the NAS uses a redirect agent to locate the home server. The rest of the session proceeds as before.
このシナリオでは、NASは、ホームサーバの場所を見つけるのに再直接のエージェントを使用します。セッションの残りは従来と同様続きます。
NAS Local redirect agent Home server
| | |
| Diameter-EAP-Request | |
| Auth-Request-Type=AUTHORIZE_AUTHENTICATE |
| EAP-Payload(EAP Start) | |
|------------------------------->| |
| | |
| Diameter-EAP-Answer |
| Redirect-Host=homeserver.example.com |
| Redirect-Host-Usage=REALM_AND_APPLICATION |
|<-------------------------------| |
| : |
| Diameter-EAP-Request : |
| Auth-Request-Type=AUTHORIZE_AUTHENTICATE |
| EAP-Payload(EAP Start) : |
|---------------------------------------------------------------->|
| : |
: ...rest of the session continues as in first case... :
: : :
NAS Localの再直接のエージェントホームサーバ| | | | 直径EAP要求| | | =が権限を与える要求タイプをAuthしている_は認証します。| | EAP-有効搭載量(EAPは始まります)| | |------------------------------->| | | | | | 直径EAP答え| | 再直接のホスト=homeserver.example.com| | 分野_AND_再直接のホスト用法=アプリケーション| |<-------------------------------| | | : | | 直径EAP要求: | | =が権限を与える要求タイプをAuthしている_は認証します。| | EAP-有効搭載量(EAPは始まります): | |---------------------------------------------------------------->| | : | : ...セッションの残りは最初のケースのように続きます… : : : :
The advantage of this scenario is that knowledge of realms and home servers is centralized to a redirect agent, and it is not necessary to modify the NAS configuration when, for example, a new roaming agreement is made.
このシナリオの利点は分野とホームサーバに関する知識が再直接のエージェントに集結されて、例えば、新しいローミング協定をするときNAS構成を変更するのは必要でないということです。
Eronen, et al. Standards Track [Page 8] RFC 4072 Diameter EAP Application August 2005
Eronen、他 規格は直径EAPアプリケーション2005年8月にRFC4072を追跡します[8ページ]。
2.3.3. Scenario 3: Direct EAP, Authorization via Agents
2.3.3. シナリオ3: ダイレクトEAP、エージェントを通したAuthorization
In this scenario the EAP authentication is done directly with the home server (with Auth-Request-Type set to AUTHENTICATE_ONLY), and authorization AVPs are retrieved from local proxy agents. This scenario is intended for environments in which the home server cannot provide all the necessary authorization AVPs to the NAS.
このシナリオでは、直接ホームサーバでEAP認証をします、そして、(AUTHENTICATEだけに用意ができているAuth要求タイプで)地元のプロキシエージェントから承認AVPsを検索します。 このシナリオはホームサーバがすべての必要な承認AVPsをNASに供給できない環境のために意図します。
NAS Local proxy agent Home server
| : |
| Diameter-EAP-Request : |
| Auth-Request-Type=AUTHENTICATE_ONLY |
| EAP-Payload(EAP Start) : |
|---------------------------------------------------------------->|
| : |
| : Diameter-EAP-Answer |
| Result-Code=DIAMETER_MULTI_ROUND_AUTH |
| : EAP-Payload(EAP Request) |
|<----------------------------------------------------------------|
| : |
: ...more EAP Request/Response pairs... :
| : |
| Diameter-EAP-Request : |
| EAP-Payload(EAP Response) : |
|---------------------------------------------------------------->|
| : |
| : Diameter-EAP-Answer |
| : Result-Code=DIAMETER_SUCCESS |
| : EAP-Payload(EAP Success) |
| : EAP-Master-Session-Key |
| : (authorization AVPs) |
|<----------------------------------------------------------------|
| | |
| AA-Request | |
| Auth-Request-Type=AUTHORIZE_ONLY |
| (some AVPs from first session) | |
|------------------------------->| |
| | |
| AA-Answer | |
| Result-Code=DIAMETER_SUCCESS | |
| (authorization AVPs) | |
|<-------------------------------| |
NAS Localプロキシエージェントホームサーバ| : | | 直径EAP要求: | | Auth-要求タイプ=は_だけを認証します。| | EAP-有効搭載量(EAPは始まります): | |---------------------------------------------------------------->| | : | | : 直径EAP答え| | 結果コードは_AUTHの周りで直径_マルチ_と等しいです。| | : EAP-有効搭載量(EAP要求)| |<----------------------------------------------------------------| | : | : ...より多くのEAP Request/応答が対にされます… : | : | | 直径EAP要求: | | EAP-有効搭載量(EAP応答): | |---------------------------------------------------------------->| | : | | : 直径EAP答え| | : 結果コードは直径_成功と等しいです。| | : EAP-有効搭載量(EAP成功)| | : EAPマスターセッションキー| | : (承認AVPs) | |<----------------------------------------------------------------| | | | | AA-要求| | | Auth-要求タイプ=は_だけを認可します。| | (最初のセッションからのいくつかのAVPs) | | |------------------------------->| | | | | | AA-答え| | | 結果コードは直径_成功と等しいです。| | | (承認AVPs) | | |<-------------------------------| |
The NASREQ application is used here for authorization because the realm-specific routing table supports routing based on application, not on Diameter commands.
分野特有の経路指定テーブルがDiameterコマンドではなく、アプリケーションに基づいてルーティングをサポートするので、NASREQアプリケーションは承認にここで使用されます。
Eronen, et al. Standards Track [Page 9] RFC 4072 Diameter EAP Application August 2005
Eronen、他 規格は直径EAPアプリケーション2005年8月にRFC4072を追跡します[9ページ]。
2.3.4. Scenario 4: Proxy Agents
2.3.4. シナリオ4: プロキシエージェント
This scenario is the same as Scenario 1, but the NAS contacts the home server through proxies. Note that the proxies can see the EAP session keys, thus it is not suitable for environments where proxies cannot be trusted.
このシナリオはScenario1と同じですが、NASはプロキシを通してホームサーバに連絡します。 プロキシがEAPセッションキーを見ることができて、その結果、それがプロキシを信じることができない環境に適していないことに注意してください。
NAS Local proxy/relay agent Home server
| | |
| Diameter-EAP-Request | |
| Auth-Request-Type=AUTHORIZE_AUTHENTICATE |
| EAP-Payload(EAP Start) | |
|------------------------------->|------------------------------->|
| | |
| | Diameter-EAP-Answer |
| Result-Code=DIAMETER_MULTI_ROUND_AUTH |
| | EAP-Payload(EAP Request) |
|<-------------------------------|<-------------------------------|
| : |
: ...more EAP Request/Response pairs... :
| : |
| Diameter-EAP-Request | |
| EAP-Payload(EAP Response) | |
|------------------------------->|------------------------------->|
| | |
| | Diameter-EAP-Answer |
| | Result-Code=DIAMETER_SUCCESS |
| | EAP-Payload(EAP Success) |
| | EAP-Master-Session-Key |
| | (authorization AVPs) |
|<-------------------------------|<-------------------------------|
NAS Localプロキシ/中継エージェントホームサーバ| | | | 直径EAP要求| | | =が権限を与える要求タイプをAuthしている_は認証します。| | EAP-有効搭載量(EAPは始まります)| | |------------------------------->|------------------------------->| | | | | | 直径EAP答え| | 結果コードは_AUTHの周りで直径_マルチ_と等しいです。| | | EAP-有効搭載量(EAP要求)| |<-------------------------------|<-------------------------------| | : | : ...より多くのEAP Request/応答が対にされます… : | : | | 直径EAP要求| | | EAP-有効搭載量(EAP応答)| | |------------------------------->|------------------------------->| | | | | | 直径EAP答え| | | 結果コードは直径_成功と等しいです。| | | EAP-有効搭載量(EAP成功)| | | EAPマスターセッションキー| | | (承認AVPs) | |<-------------------------------|<-------------------------------|
2.4. Invalid Packets
2.4. 無効のパケット
While acting as a pass-through, the NAS MUST validate the EAP header fields (Code, Identifier, Length) prior to forwarding an EAP packet to or from the Diameter server. On receiving an EAP packet from the peer, the NAS checks the Code (Code 2=Response) and Length fields, and matches the Identifier value against the current Identifier, supplied by the Diameter server in the most recently validated EAP Request. On receiving an EAP packet from the Diameter server (encapsulated within a Diameter-EAP-Answer), the NAS checks the Code (Code 1=Request) and Length fields, then updates the current Identifier value. Pending EAP Responses that do not match the current Identifier value are silently discarded by the NAS.
通じて通るとして機能している間、サーバかDiameterサーバからEAPパケットを進める前に、NAS MUSTはEAPヘッダーフィールド(コード、Identifier、Length)を有効にします。同輩からEAPパケットを受けるとき、NASはCode(コード2は応答と等しい)とLength分野をチェックして、最も最近有効にされたEAP RequestのDiameterサーバによって供給された現在のIdentifierに対してIdentifier値に合っています。 Diameterサーバ(Diameter-EAP-答えの中で要約する)からEAPパケットを受けると、NASはCode(コード1=要求)とLength分野をチェックして、次に、現在のIdentifier値をアップデートします。 現在のIdentifier値に合っていない未定のEAP ResponsesがNASによって静かに捨てられます。
Eronen, et al. Standards Track [Page 10] RFC 4072 Diameter EAP Application August 2005
Eronen、他 規格は直径EAPアプリケーション2005年8月にRFC4072を追跡します[10ページ]。
Since EAP method fields (Type, Type-Data) are typically not validated by a NAS operating as a pass-through, despite these checks it is possible for a NAS to forward an invalid EAP packet to or from the Diameter server.
EAPメソッド分野(タイプ、Type-データ)が通じて通るとして作動するNASによって通常有効にされないので、これらのチェックにもかかわらず、NASがサーバかDiameterサーバから無効のEAPパケットを進めるのは、可能です。
A Diameter server receiving an EAP-Payload AVP that it does not understand SHOULD determine whether the error is fatal or non-fatal based on the EAP Type. A Diameter server determining that a fatal error has occurred MUST send a Diameter-EAP-Answer with a failure Result-Code and an EAP-Payload AVP encapsulating an EAP Failure packet. A Diameter server determining that a non-fatal error has occurred MUST send a Diameter-EAP-Answer with DIAMETER_MULTI_ROUND_AUTH Result-Code, but no EAP-Payload AVP. To simplify RADIUS translation, this message MUST also include an EAP-Reissued-Payload AVP encapsulating the previous EAP Request sent by the server.
誤りが致命的であるか、または非致命的であることにかかわらずそれが、SHOULDが決定するのを理解していないEAP-有効搭載量AVPを受けるDiameterサーバはEAP Typeを基礎づけました。 致命的な誤りが発生したことを決定するDiameterサーバは失敗Result-コードとEAP-有効搭載量AVPがEAP Failureパケットをカプセルに入れっているDiameter-EAP-答えを送らなければなりません。 非致命的な誤りが発生したことを決定するDiameterサーバはDIAMETER_MULTI_ROUND_AUTH Result-コードにもかかわらず、EAP-有効搭載量がないAVPとのDiameter-EAP-答えを送らなければなりません。 また、RADIUS翻訳を簡素化するために、このメッセージはサーバによって送られた前のEAP Requestをカプセル化するEAPが有効搭載量を再発行しているAVPを含まなければなりません。
When receiving a Diameter-EAP-Answer without an EAP-Payload AVP (and DIAMETER_MULTI_ROUND_AUTH Result-Code), the NAS SHOULD discard the EAP-Response packet most recently transmitted to the Diameter server and check whether additional EAP Response packets that match the current Identifier value have been received. If so, a new EAP Response packet, if available, MUST be sent to the Diameter server within an Diameter-EAP-Request. If no EAP Response packet is available, then the previous EAP Request is resent to the peer, and the retransmission timer is reset.
EAP-有効搭載量AVP(そして、DIAMETER_MULTI_ROUND_AUTH Result-コード)なしでDiameter-EAP-答えを受けるとき、NAS SHOULDは、ごく最近Diameterサーバに伝えられたEAP-応答パケットを捨てて、現在のIdentifier値に合っている追加EAP Responseパケットが受け取られたかどうかチェックします。 そうだとすれば、利用可能であるなら、Diameter-EAP-要求の中のDiameterサーバに新しいEAP Responseパケットを送らなければなりません。 どんなEAP Responseパケットも利用可能でないなら、前のEAP Requestを同輩に再送します、そして、再送信タイマーをリセットします。
In order to provide protection against Denial of Service (DoS) attacks, it is advisable for the NAS to allocate a finite buffer for EAP packets received from the peer, and to discard packets according to an appropriate policy once that buffer has been exceeded. Also, the Diameter server is advised to permit only a modest number of invalid EAP packets within a single session, prior to terminating the session with DIAMETER_AUTHENTICATION_REJECTED Result-Code. By default, a value of 5 invalid EAP packets is recommended.
サービス妨害(DoS)攻撃に対する保護を提供するために、そのバッファがいったん超えられていると、NASが同輩から受け取られたEAPパケットのための有限バッファを割り当てて、適切な方針によると、パケットを捨てるのは賢明です。 また、Diameterサーバがただ一つのセッション以内に穏やかな数の無効のEAPパケットだけを可能にするように教えられます、DIAMETER_AUTHENTICATION_REJECTED Result-コードとのセッションを終える前に。 デフォルトで、5つの無効のEAPパケットの値はお勧めです。
2.5. Retransmission
2.5. Retransmission
As noted in [EAP], if an EAP packet is lost in transit between the authenticating peer and the NAS (or vice versa), the NAS will retransmit.
[EAP]に述べられるように、EAPパケットが認証している同輩とNAS(逆もまた同様である)の間のトランジットで失われていると、NASは再送するでしょう。
It may be necessary to adjust retransmission strategies and authentication time-outs in certain cases. For example, when a token card is used, additional time may be required to allow the user to find the card and enter the token. Since the NAS will typically not have knowledge of the required parameters, these need to be provided by the Diameter server.
ある場合には「再-トランスミッション」戦略と認証タイムアウトを調整するのが必要であるかもしれません。 トークン・カードが使用されているとき、例えば、追加時間が、ユーザがカードを見つけて、トークンに入るのを許可するのに必要であるかもしれません。 以来、NASには、必要なパラメタ(これらのDiameterサーバによって提供されるべき必要性)に関する知識が通常ないでしょう。
Eronen, et al. Standards Track [Page 11] RFC 4072 Diameter EAP Application August 2005
Eronen、他 規格は直径EAPアプリケーション2005年8月にRFC4072を追跡します[11ページ]。
If a Multi-Round-Time-Out AVP [BASE] is present in a Diameter-EAP- Answer message that also contains an EAP-Payload AVP, that value is used to set the EAP retransmission timer for that EAP Request and that Request alone.
Multiが時間を仕上げているAVP[基地]がまた、EAP-有効搭載量AVPを含むDiameter-EAP答えメッセージに存在しているなら、その値は、単独でそのEAP RequestとそのRequestにEAP再送信タイマーを設定するのに使用されます。
2.6. Fragmentation
2.6. 断片化
Using the EAP-Payload AVP, it is possible for the Diameter server to encapsulate an EAP packet that is larger than the MTU on the link between the NAS and the peer. Since it is not possible for the Diameter server to use MTU discovery to ascertain the link MTU, a Framed-MTU AVP may be included in a Diameter-EAP-Request message in order to provide the Diameter server with this information.
EAP-有効搭載量AVPを使用して、Diameterサーバが、EAPパケットがそれであるとカプセル化するのが、NASの間のリンクの上のMTUと同輩より大きいのは、可能です。 DiameterサーバがリンクMTUを確かめるのにMTU発見を使用するのが、可能でないので、Framed-MTU AVPはこの情報をDiameterサーバに提供するためにDiameter-EAP-要求メッセージに含まれるかもしれません。
A Diameter server having received a Framed-MTU AVP in a Diameter-EAP-Request message MUST NOT send any subsequent packet in this EAP conversation containing EAP-Payload AVP whose length exceeds that specified by the Framed-MTU value, taking the link type (specified by the NAS-Port-Type AVP) into account. For example, as noted in [RFC3580] Section 3.10, for a NAS-Port-Type value of IEEE 802.11, 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 octet), Type (1 octet) and Body Length (2 octets) fields.
Diameter-EAP-要求メッセージでFramed-MTU AVPを受けたならどんなその後のパケットも長さのEAP-有効搭載量AVPを含むこのEAPの会話で送られてはいけないDiameterサーバはFramed-MTU値によって指定されたそれを超えています、リンク型(NASポートタイプAVPによって指定される)をアカウントに連れて行って。 例えば、RADIUSサーバはIEEE802.11のNASポートタイプ値のために[RFC3580]セクション3.10に述べられるように4(4)八重奏を引いてFramed-MTUと同じくらい大きいEAPパケットを送るかもしれません、IEEE 802.1Xバージョン(1つの八重奏)(Type(1つの八重奏)とBody Length(2つの八重奏)分野)のために追加オーバーヘッドを考慮に入れて
2.7. Accounting
2.7. 会計
When a user is authenticated using EAP, the NAS MAY include an Accounting-Auth-Method AVP [NASREQ] with value 5 (EAP) in Accounting-Request messages. This document specifies one additional AVP for accounting messages. One or more Accounting-EAP-Auth-Method AVPs (see Section 4.1.5) MAY be included in Accounting-Request messages to indicate the EAP method(s) used to authenticate the user.
ユーザがEAPを使用することで認証されるとき、NAS MAYはAccounting-要求メッセージに値5があるAccounting-Auth-メソッドAVP[NASREQ](EAP)を含んでいます。 このドキュメントは1追加AVPを会計メッセージに指定します。 1Accounting-EAP-Auth-メソッドAVPs(セクション4.1.5を見る)がEAPメソッドが以前はよくユーザを認証していたのを示すAccounting-要求メッセージに含まれるかもしれません。
If the NAS has authenticated the user with a locally implemented EAP method, it knows the method used and SHOULD include it in an Accounting-EAP-Auth-Method AVP.
NASが局所的に実装しているEAPメソッドをもっているユーザを認証したなら、メソッドが使用したのを知っています、そして、SHOULDはAccounting-EAP-Auth-メソッドAVPにそれを含んでいます。
If the authentication was done using Diameter-EAP-Request/Answer messages, the Diameter server SHOULD include one or more Accounting-EAP-Auth-Method AVPs in Diameter-EAP-Answer packets with a successful result code. In this case, the NAS SHOULD include these AVPs in Accounting-Request messages.
認証がDiameter-EAP-要求/答えメッセージを使用し終わっていたなら、DiameterサーバSHOULDはDiameter-EAP-答えパケットに好成績コードで1つ以上のAccounting-EAP-Auth-メソッドのAVPsを含んでいます。 この場合、NAS SHOULDはAccounting-要求メッセージにこれらのAVPsを含んでいます。
Eronen, et al. Standards Track [Page 12] RFC 4072 Diameter EAP Application August 2005
Eronen、他 規格は直径EAPアプリケーション2005年8月にRFC4072を追跡します[12ページ]。
2.8. Usage Guidelines
2.8. 用法ガイドライン
2.8.1. User-Name AVP
2.8.1. ユーザ名AVP
Unless the access device interprets the EAP-Response/Identity packet returned by the authenticating peer, it will not have access to the user's identity. Furthermore, some EAP methods support identity protection where the user's real identity is not included in EAP-Response/Identity. Therefore, the Diameter Server SHOULD return the user's identity by inserting a User-Name AVP to Diameter-EAP-Answer messages that have a Result-Code of DIAMETER_SUCCESS. A separate billing identifier or pseudonym MAY be used for privacy reasons (see Section 8.5). If the user's identity is not available to the NAS, the Session-Id AVP MAY be used for accounting and billing; however operationally this could be very difficult to manage.
アクセスデバイスが認証している同輩によって返されたEAP-応答/アイデンティティパケットを解釈しないと、それはユーザのアイデンティティに近づく手段を持たないでしょう。 その上、ユーザの正体がEAP-応答/アイデンティティに含まれていないところでいくつかのEAPメソッドが、アイデンティティが保護であるとサポートします。 したがって、Diameter Server SHOULDは、DIAMETER_SUCCESSのResult-コードを持っているDiameter-EAP-答えメッセージにUser-名前AVPを挿入することによって、ユーザのアイデンティティを返します。 別々の支払い識別子か匿名がプライバシー理由に使用されるかもしれません(セクション8.5を見てください)。 ユーザのアイデンティティがNASに利用可能でないなら、Session-イドAVP MAYです中古の、そして、会計で請求している。 しかしながら、操作上、これは管理するのが非常に難しいかもしれません。
2.8.2. Conflicting AVPs
2.8.2. 闘争AVPs
A Diameter-EAP-Answer message containing an EAP-Payload of type EAP-Success or EAP-Failure MUST NOT have the Result-Code AVP set to DIAMETER_MULTI_ROUND_AUTH.
タイプEAP-成功かEAP-失敗のEAP-有効搭載量を含むDiameter-EAP-答えメッセージで、DIAMETER_MULTI_ROUND_AUTHにResult-コードAVPを用意ができさせてはいけません。
Some lower layers assume that the authorization decision is made by the EAP server, and thus the peer considers EAP Success as an indication that access was granted. In this case, the Result-Code SHOULD match the contained EAP packet: a successful Result-Code for EAP-Success, and a failure Result-Code for EAP-Failure. If the encapsulated EAP packet does not match the result implied by the Result-Code AVP, the combination is likely to cause confusion, because the NAS and peer will conclude the outcome of the authentication differently. For example, if the NAS receives a failure Result-Code with an encapsulated EAP Success, it will not grant access to the peer. However, on receiving the EAP Success, the peer will be led to believe that access was granted.
いくつかの下層が、EAPサーバで承認決定をすると仮定します、そして、その結果、同輩はEAP Successがアクセスが承諾されたという指示であるとみなします。 この場合、Result-コードSHOULDは含まれたEAPパケットに合っています: EAP-成功のためのうまくいっているResult-コード、およびEAP-失敗のための失敗Result-コード。 カプセル化されたEAPパケットがResult-コードAVPによって含意された結果に合っていないなら、組み合わせは混乱を引き起こしそうです、NASと同輩が認証の結果を異なって結論づけるので。 例えば、NASがカプセル化されたEAP Successと共に失敗Result-コードを受け取ると、それは同輩へのアクセスを承諾しないでしょう。 しかしながら、EAP Successを受けるとき、同輩が、アクセスが承諾されたと信じているように導かれるでしょう。
This situation can be difficult to avoid when Diameter proxy agents make authorization decisions (that is, proxies can change the Result-Code AVP sent by the home server). Because it is the responsibility of the Diameter server to avoid conflicts, the NAS MUST NOT "manufacture" EAP result packets in order to correct the contradictory messages that it receives. This behavior, originally mandated within [IEEE-802.1X], is now deprecated.
Diameterプロキシエージェントが承認決定をするとき(すなわち、プロキシはAVPがホームサーバで送ったResult-コードを変えることができます)、この状況は避けるのが難しい場合があります。 摩擦を避けるのが、Diameterサーバの責任であるので、NAS MUST NOTは受信するという相容れないメッセージを修正するためにEAP結果パケットを「製造しています」。 この元々[IEEE-802.1X]の中で強制された振舞いは現在、推奨しないです。
Eronen, et al. Standards Track [Page 13] RFC 4072 Diameter EAP Application August 2005
Eronen、他 規格は直径EAPアプリケーション2005年8月にRFC4072を追跡します[13ページ]。
2.8.3. Displayable Messages
2.8.3. Displayableメッセージ
The Reply-Message AVP [NASREQ] MUST NOT be included in any Diameter message containing an EAP-Payload AVP.
EAP-有効搭載量AVPを含むどんなDiameterメッセージにもReply-メッセージAVP[NASREQ]を含んではいけません。
2.8.4. Role Reversal
2.8.4. 役割交替
Some environments in which EAP is used, such as PPP, support peer-to-peer operation. Both parties act as authenticators and authenticatees at the same time, in two simultaneous and independent EAP conversations.
EAPがPPPなどのように使用されるいくつかの環境が、ピアツーピアが操作であるとサポートします。 双方は同時に、固有識別文字とauthenticateesとして2つの同時の、そして、独立しているEAPの会話で機能します。
This specification is intended for communication between EAP (passthrough) authenticator and backend authentication server. A Diameter client MUST NOT send a Diameter-EAP-Request encapsulating an EAP Request packet, and a Diameter server receiving such a packet MUST respond with a failure Result-Code.
この仕様はEAP(passthrough)固有識別文字とバックエンド認証サーバとのコミュニケーションのために意図します。DiameterクライアントはDiameter-EAP-要求にEAP Requestパケットをカプセルに入れらせてはいけません、そして、そのようなパケットを受けるDiameterサーバは失敗Result-コードで反応しなければなりません。
2.8.5. Identifier Space
2.8.5. 識別子スペース
In EAP, each session has its own unique Identifier space. Diameter server implementations MUST be able to distinguish between EAP packets with the same Identifier existing within distinct EAP sessions and originating on the same NAS. This is done by using the Session-Id AVP.
EAPでは、各セッションはそれ自身のユニークなIdentifierスペースを持っています。 直径サーバ実装は同じIdentifierが異なったEAPセッション以内に存在して、同じNASで起因しているEAPパケットを見分けることができなければなりません。 Session-イドAVPを使用することによって、これをします。
If a Diameter NAS is in the middle of a multi-round authentication exchange, and it detects that the EAP session between the client and the NAS has been terminated, it MUST select a new Diameter Session-Id for any subsequent EAP sessions. This is necessary in order to distinguish a restarted EAP authentication process from the continuation of an ongoing process (by the same user on the same NAS and port).
Diameter NASがaであるならマルチラウンド認証交換の途中にあります、そして、それはそれを検出します。クライアントとNASとのEAPセッションは終えられます、どんなその後のEAPセッションのためにも新しいDiameter Session-イドを選択しなければならないということです。 これが、進行中の過程(同じNASとポートの上の同じユーザによる)の継続と再開しているEAP認証過程を区別するのに必要です。
In RADIUS, the same functionality can be achieved through the inclusion or omission of the State attribute. Translation rules in [NASREQ] ensure that an Access-Request without the State attribute maps to a new Diameter Session-Id AVP value. Furthermore, a translation agent will always include a State attribute in Access-Challenge messages, making sure that the State attribute is available for a RADIUS NAS.
RADIUSでは、州属性の包含か省略で同じ機能性を達成できます。 [NASREQ]の翻訳規則はその新しいDiameter Session-イドAVPへの州属性地図のないAccess-要求値を確実にします。 その上、翻訳エージェントはAccess-挑戦メッセージでいつも州属性を入れるでしょう、州属性がRADIUS NASに利用可能であることを確実にして。
3. Command-Codes
3. コマンドコード
This section defines new Command-Code values that MUST be supported by all Diameter implementations conforming to this specification. The following commands are defined in this section:
このセクションはこの仕様に従うすべてのDiameter実装でサポートしなければならない新しいCommand-コード値を定義します。 以下のコマンドはこのセクションで定義されます:
Eronen, et al. Standards Track [Page 14] RFC 4072 Diameter EAP Application August 2005
Eronen、他 規格は直径EAPアプリケーション2005年8月にRFC4072を追跡します[14ページ]。
Command-Name Abbrev. Code Reference
--------------------------------------------------------
Diameter-EAP-Request DER 268 3.1
Diameter-EAP-Answer DEA 268 3.2
コマンド名Abbrev。 コード参照-------------------------------------------------------- 直径EAP要求DER268 3.1直径EAP答えDEA268 3.2
When the NASREQ AA-Request (AAR) or AA-Answer (AAA) commands are used for AUTHORIZE_ONLY messages in conjunction with EAP (see Section 2.3.3), an Application Identifier value of 1 (NASREQ) is used, and the commands follow the rules and ABNF defined in [NASREQ].
EAP(セクション2.3.3を見る)に関連した(AAR)かAA-答え(AAA)命令がAUTHORIZEだけに使用されるというNASREQ AA-要求メッセージ、1(NASREQ)のApplication Identifier値が使用されていて、コマンドが[NASREQ]で定義された規則とABNFに従うと。
When the Re-Auth-Request (RAR), Re-Auth-Answer (RAA), Session-Termination-Request (STR), Session-Termination-Answer (STA), Abort-Session-Request (ASR), Abort-Session-Answer (ASA), Accounting-Request (ACR), and Accounting-Answer (ACA) commands are used together with the Diameter EAP application, they follow the rules in [NASREQ] and [BASE]. The accounting commands use Application Identifier value of 3 (Diameter Base Accounting); the others use 0 (Diameter Common Messages).
Re-Auth-要求(RAR)、Re-Auth-答え(RAA)、Session終了要求(STR)、Session終了答え(STA)、Abortセッション要求(ASR)、Abortセッション答え(ASA)、Accounting-要求(ACR)、およびAccounting-答え(ACA)命令がDiameter EAPアプリケーションと共に使用されるとき、それらは[NASREQ]と[基地]で約束を守ります。 会計命令は3(直径基地のAccounting)のApplication Identifier値を使用します。 他のものは0(直径Common Messages)を使用します。
3.1. Diameter-EAP-Request (DER) Command
3.1. 直径EAP要求(DER)命令
The Diameter-EAP-Request (DER) command, indicated by the Command-Code field set to 268 and the 'R' bit set in the Command Flags field, is sent by a Diameter client to a Diameter server, and conveys an EAP-Response from the EAP client. The Diameter-EAP-Request MUST contain one EAP-Payload AVP containing the actual EAP payload. An EAP-Payload AVP with no data MAY be sent to the Diameter server to initiate an EAP authentication session.
268に設定されたCommand-コード分野とCommand Flags分野に設定された'R'ビットによって示されたDiameter-EAP-要求(DER)命令は、DiameterクライアントによってDiameterサーバに送られて、EAPクライアントからEAP-応答を伝えます。 Diameter-EAP-要求は実際のEAPペイロードを含む1EAP-有効搭載量AVPを含まなければなりません。 EAP認証セッションを開始するためにデータのないEAP-有効搭載量AVPをDiameterサーバに送るかもしれません。
The DER message MAY be the result of a multi-round authentication exchange that occurs when the DEA is received with the Result-Code AVP set to DIAMETER_MULTI_ROUND_AUTH [BASE]. A subsequent DER message MUST include any State AVPs [NASREQ] that were present in the DEA. For re-authentication, it is recommended that the Identity request be skipped in order to reduce the number of authentication round trips. This is only possible when the user's identity is already known by the home Diameter server.
DERメッセージはAVPがDIAMETER_MULTI_ROUND_AUTH[基地]に設定するResult-コードでDEAを受け取るとき起こるマルチラウンド認証交換の結果であるかもしれません。 その後のDERメッセージはDEAにどんな存在している州AVPs[NASREQ]も含まなければなりません。 再認証において、Identity要求が認証周遊旅行の数を減少させるためにサボられるのは、お勧めです。 ユーザのアイデンティティがホームDiameterサーバによって既に知られているときだけ、これは可能です。
Message format
メッセージ・フォーマット
<Diameter-EAP-Request> ::= < Diameter Header: 268, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Request-Type }
[ Destination-Host ]
<直径EAP-要求>:、:= <直径ヘッダー: 268 REQ、PXY><セッションイド>Authアプリケーションイド発生源ホスト発生源分野目的地分野Auth要求タイプ[あて先ホスト]
Eronen, et al. Standards Track [Page 15] RFC 4072 Diameter EAP Application August 2005
Eronen、他 規格は直径EAPアプリケーション2005年8月にRFC4072を追跡します[15ページ]。
[ NAS-Identifier ]
[ NAS-IP-Address ]
[ NAS-IPv6-Address ]
[ NAS-Port ]
[ NAS-Port-Id ]
[ NAS-Port-Type ]
[ Origin-State-Id ]
[ Port-Limit ]
[ User-Name ]
{ EAP-Payload }
[ EAP-Key-Name ]
[ Service-Type ]
[ State ]
[ Authorization-Lifetime ]
[ Auth-Grace-Period ]
[ Auth-Session-State ]
[ Callback-Number ]
[ Called-Station-Id ]
[ Calling-Station-Id ]
[ Originating-Line-Info ]
[ Connect-Info ]
* [ Framed-Compression ]
[ Framed-Interface-Id ]
[ Framed-IP-Address ]
* [ Framed-IPv6-Prefix ]
[ Framed-IP-Netmask ]
[ Framed-MTU ]
[ Framed-Protocol ]
* [ Tunneling ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
NAS-識別子NAS IPアドレスNAS-IPv6-アドレスNAS-ポートNASポートイドNASポートタイプ発生源州のイドポート限界ユーザ名EAP-有効搭載量EAPの主要な名のサービスタイプ州の承認生涯Auth-据置期間のAuthセッション州のコールバック番号; インフォメーションを接続している呼ばれた駅のイドトンネリング*プロキシインフォメーション*ルート記録呼んでいる駅のイド起因している線インフォメーション*縁どられた圧縮縁どられたインタフェースイド縁どられたIPアドレス*縁どられたIPv6接頭語縁どられたIPネットマスク縁どられたMTU縁どられたプロトコル**[AVP]
3.2. Diameter-EAP-Answer (DEA) Command
3.2. 直径EAP答え(DEA)命令
The Diameter-EAP-Answer (DEA) message, indicated by the Command-Code field set to 268 and the 'R' bit cleared in the Command Flags field, is sent by the Diameter server to the client for one of the following reasons:
Diameterサーバは以下の理由の1つによって268に設定されたCommand-コード分野とCommand Flags分野できれいにされた'R'ビットによって示されたDiameter-EAP-答え(DEA)メッセージをクライアントに送ります:
1. The message is part of a multi-round authentication exchange, and
the server is expecting a subsequent Diameter-EAP-Request. This
is indicated by setting the Result-Code to
DIAMETER_MULTI_ROUND_AUTH, and MAY include zero or more State
AVPs.
1. メッセージはマルチラウンド認証交換の一部です、そして、サーバはその後のDiameter-EAP-要求を予想しています。 これは、DIAMETER_MULTI_ROUND_AUTHにResult-コードを設定することによって示されて、ゼロか、より多くの州AVPsを含むかもしれません。
Eronen, et al. Standards Track [Page 16] RFC 4072 Diameter EAP Application August 2005
Eronen、他 規格は直径EAPアプリケーション2005年8月にRFC4072を追跡します[16ページ]。
2. The EAP client has been successfully authenticated and
authorized, in which case the message MUST include the
Result-Code AVP indicating success, and SHOULD include an
EAP-Payload of type EAP-Success. This event MUST cause the
access device to provide service to the EAP client.
2. EAPクライアントは、首尾よく認証されて、権限を与えられました、そして、その場合、メッセージは成功を示すResult-コードAVPを含まなければなりません、そして、SHOULDはタイプEAP-成功のEAP-有効搭載量を含んでいます。 このイベントで、アクセスデバイスはEAPクライアントに対するサービスを提供しなければなりません。
3. The EAP client has not been successfully authenticated and/or
authorized, and the Result-Code AVP is set to indicate failure.
This message SHOULD include an EAP-Payload, but this AVP is not
used to determine whether service is to be provided.
3. EAPクライアントは、首尾よく認証される、そして/または、権限を与えられていません、そして、Result-コードAVPは失敗を示すように用意ができています。 このメッセージSHOULDはEAP-有効搭載量を含んでいますが、このAVPは、サービスが提供されるかどうかことであることを決定するのに使用されません。
If the message from the Diameter client included a request for authorization, a successful response MUST include the authorization AVPs that are relevant to the service being provided.
Diameterクライアントからのメッセージが承認を求める要求を含んでいたなら、うまくいっている応答は提供されるサービスに関連している承認AVPsを含まなければなりません。
Message format
メッセージ・フォーマット
<Diameter-EAP-Answer> ::= < Diameter Header: 268, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Request-Type }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
[ EAP-Payload ]
[ EAP-Reissued-Payload ]
[ EAP-Master-Session-Key ]
[ EAP-Key-Name ]
[ Multi-Round-Time-Out ]
[ Accounting-EAP-Auth-Method ]
[ Service-Type ]
* [ Class ]
* [ Configuration-Token ]
[ Acct-Interim-Interval ]
[ Error-Message ]
[ Error-Reporting-Host ]
* [ Failed-AVP ]
[ Idle-Timeout ]
[ Authorization-Lifetime ]
[ Auth-Grace-Period ]
[ Auth-Session-State ]
[ Re-Auth-Request-Type ]
[ Session-Timeout ]
[ State ]
* [ Reply-Message ]
[ Origin-State-Id ]
* [ Filter-Id ]
<直径EAP-答え>:、:= <直径ヘッダー: 268,; PXY><セッションイド>AuthアプリケーションイドAuth要求タイプはEAPが有効搭載量を再発行している発生源ホストのEAPマスターセッションキーEAPの主要な名のマルチラウンドタイムアウト会計EAP-Authメソッドサービス発生源分野ユーザ名EAP-有効搭載量タイプを結果でコード化します; 再Authがタイプを要求している*Authセッション州セッションタイムアウト状態*応答メッセージ発生源州のイドクラス*構成トークンAcctの当座の間隔エラーメッセージエラー報告ホスト*失敗したAVPアイドルタイムアウト承認生涯Auth-据置期間の*[フィルタイド]
Eronen, et al. Standards Track [Page 17] RFC 4072 Diameter EAP Application August 2005
Eronen、他 規格は直径EAPアプリケーション2005年8月にRFC4072を追跡します[17ページ]。
[ Port-Limit ]
[ Callback-Id ]
[ Callback-Number ]
[ Framed-Appletalk-Link ]
* [ Framed-Appletalk-Network ]
[ Framed-Appletalk-Zone ]
* [ Framed-Compression ]
[ Framed-Interface-Id ]
[ Framed-IP-Address ]
* [ Framed-IPv6-Prefix ]
[ Framed-IPv6-Pool ]
* [ Framed-IPv6-Route ]
[ Framed-IP-Netmask ]
* [ Framed-Route ]
[ Framed-Pool ]
[ Framed-IPX-Network ]
[ Framed-MTU ]
[ Framed-Protocol ]
[ Framed-Routing ]
* [ NAS-Filter-Rule ]
* [ QoS-Filter-Rule ]
* [ Tunneling ]
* [ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
* [ Proxy-Info ]
* [ AVP ]
ポート限界縁どられたIPv6接頭語縁どられたIPv6プール*縁どられたIPv6コールバックイドコールバック番号縁どられたAppletalkリンク*縁どられたAppletalkネットワーク縁どられたAppletalkゾーン*縁どられた圧縮縁どられたインタフェースイド縁どられたIPアドレス*ルート; 縁どられたIPネットマスク*縁どられたルート縁どられたプール縁どられたIPXネットワーク縁どられたMTU縁どられたプロトコル縁どられたルート設定*NASフィルタ規則*QoSフィルタ規則*トンネリング*再直接のホスト再直接のホスト用法再直接のマックスキャッシュ時間*プロキシインフォメーション*[AVP]
4. Attribute-Value Pairs
4. 属性値ペア
This section both defines new AVPs, unique to the EAP Diameter application and describes the usage of AVPs defined elsewhere (if that usage in the EAP application is noteworthy).
このセクションは、EAP Diameterアプリケーションにユニークな新しいAVPsを定義して、ほかの場所で定義されたAVPsの使用法を説明します(EAPアプリケーションにおけるその用法が注目に値するなら)。
4.1. New AVPs
4.1. 新しいAVPs
4.1.1. EAP-Payload AVP
4.1.1. EAP-有効搭載量AVP
The EAP-Payload AVP (AVP Code 462) is of type OctetString and is used to encapsulate the actual EAP packet that is being exchanged between the EAP client and the home Diameter server.
EAP-有効搭載量AVP(AVP Code462)は、タイプOctetStringにはあって、EAPクライアントとホームDiameterサーバの間で交換されている実際のEAPパケットをカプセルに入れるのに使用されます。
4.1.2. EAP-Reissued-Payload AVP
4.1.2. EAPが有効搭載量を再発行しているAVP
The EAP-Reissued-Payload AVP (AVP Code 463) is of type OctetString. The use of this AVP is described in Section 2.4.
タイプOctetStringにはEAPが有効搭載量を再発行しているAVP(AVP Code463)があります。 このAVPの使用はセクション2.4で説明されます。
Eronen, et al. Standards Track [Page 18] RFC 4072 Diameter EAP Application August 2005
Eronen、他 規格は直径EAPアプリケーション2005年8月にRFC4072を追跡します[18ページ]。
4.1.3. EAP-Master-Session-Key AVP
4.1.3. EAPマスターセッションキーAVP
The EAP-Master-Session-Key AVP (AVP Code 464) is of type OctetString. It contains keying material for protecting the communications between the user and the NAS. Exactly how this keying material is used depends on the link layer in question, and is beyond the scope of this document.
タイプOctetStringにはEAPマスターセッションキーAVP(AVP Code464)があります。 それは、ユーザとNASとのコミュニケーションを保護するために合わせることの材料を含んでいます。 この合わせることの材料がちょうどどう使用されているかは、問題のリンクレイヤによって、このドキュメントの範囲を超えています。
4.1.4. EAP-Key-Name AVP
4.1.4. EAPの主要な名のAVP
The EAP-Key-Name AVP (Radius Attribute Type 102) is of type OctetString. It contains an opaque key identifier (name) generated by the EAP method. Exactly how this name is used depends on the link layer in question, and is beyond the scope of this document (see [EAPKey] for more discussion).
タイプOctetStringにはEAPの主要な名のAVP(半径Attribute Type102)があります。 それはEAPメソッドで生成された不明瞭な主要な識別子(名前)を含んでいます。 この名前がちょうどどう使用されているかは、問題のリンクレイヤによって、このドキュメントの範囲を超えています(より多くの議論に関して[EAPKey]を見てください)。
Note that not all link layers use this name, and currently most EAP methods do not generate it. Since the NAS operates in pass-through mode, it cannot know the Key-Name before receiving it from the AAA server. As a result, a Key-Name AVP sent in a Diameter-EAP-Request MUST NOT contain any data. A home Diameter server receiving a Diameter-EAP-Request with a Key-Name AVP with non-empty data MUST silently discard the AVP. In addition, the home Diameter server SHOULD include this AVP in Diameter-EAP-Response only if an empty EAP-Key-Name AVP was present in Diameter-EAP-Request.
すべてのリンクレイヤがこの名前を使用するというわけではないことに注意してください。そうすれば、現在のほとんどのEAPメソッドはそれを生成しません。 NASが通じて通りモードで作動するので、AAAサーバからそれを受ける前に、それはKey-名前を知ることができません。その結果、Key-名前AVPは、Diameter-EAP-要求が少しのデータも含んではいけないのを送りました。 非空のデータでKey-名前AVPとのDiameter-EAP-要求を受け取るホームDiameterサーバは静かにAVPを捨てなければなりません。 さらに、空のEAPの主要な名のAVPがDiameter-EAP-要求に存在していた場合にだけ、ホームDiameterサーバSHOULDはDiameter-EAP-応答にこのAVPを含んでいます。
4.1.5. Accounting-EAP-Auth-Method AVP
4.1.5. 会計EAP-AuthメソッドAVP
The Accounting-EAP-Auth-Method AVP (AVP Code 465) is of type Unsigned64. In case of expanded types [EAP, Section 5.7], this AVP contains the value ((Vendor-Id * 2^32) + Vendor-Type).
タイプUnsigned64にはAccounting-EAP-Auth-メソッドAVP(AVP Code465)があります。 拡張タイプ[EAP、セクション5.7]の場合には、このAVPは値(+ (ベンダーイド*2^32)ベンダータイプ)を含んでいます。
The use of this AVP is described in Section 2.7.
このAVPの使用はセクション2.7で説明されます。
5. AVP Occurrence Tables
5. AVP発生テーブル
The following tables use these symbols:
以下のテーブルはこれらのシンボルを使用します:
0 The AVP MUST NOT be present in the message
0+ Zero or more instances of the AVP MAY be present in the message
0-1 Zero or one instance of the AVP MAY be present in the message
1 One instance of the AVP MUST be present in the message
0、AVP MUST NOT、AVP MAYのより多くのメッセージ0+ゼロインスタンスでは、メッセージ0-1でのプレゼントがAVP MAYのZeroかあるインスタンスであったならメッセージでのプレゼントがAVP MUSTの1つのOneインスタンスであったなら現在のコネがメッセージであったなら存在してください。
Note that AVPs that can only be present within a Grouped AVP are not represented in these tables.
Grouped AVPの中に存在するだけである場合があるAVPsがこれらのテーブルに表されないことに注意してください。
Eronen, et al. Standards Track [Page 19] RFC 4072 Diameter EAP Application August 2005
Eronen、他 規格は直径EAPアプリケーション2005年8月にRFC4072を追跡します[19ページ]。
5.1. EAP Command AVP Table
5.1. EAPコマンドAVPテーブル
The following table lists the AVPs that may be present in the DER and DEA Commands, as defined in this document; the AVPs listed are defined both here and in [NASREQ].
以下のテーブルはDERとDEA Commandsに存在するかもしれないAVPsを記載します、本書では定義されるように。 記載されたAVPsはここと[NASREQ]で定義されます。
+---------------+
| Command-Code |
|-------+-------+
Attribute Name | DER | DEA |
------------------------------------|-------+-------|
Accounting-EAP-Auth-Method | 0 | 0+ |
Acct-Interim-Interval [BASE] | 0 | 0-1 |
Auth-Application-Id [BASE] | 1 | 1 |
Auth-Grace-Period [BASE] | 0-1 | 0-1 |
Auth-Request-Type [BASE] | 1 | 1 |
Auth-Session-State [BASE] | 0-1 | 0-1 |
Authorization-Lifetime [BASE] | 0-1 | 0-1 |
Callback-Id [NASREQ] | 0 | 0-1 |
Callback-Number [NASREQ] | 0-1 | 0-1 |
Called-Station-Id [NASREQ] | 0-1 | 0 |
Calling-Station-Id [NASREQ] | 0-1 | 0 |
Class [BASE] | 0 | 0+ |
Configuration-Token [NASREQ] | 0 | 0+ |
Connect-Info [NASREQ] | 0-1 | 0 |
Destination-Host [BASE] | 0-1 | 0 |
Destination-Realm [BASE] | 1 | 0 |
EAP-Master-Session-Key | 0 | 0-1 |
EAP-Key-Name | 0-1 | 0-1 |
EAP-Payload | 1 | 0-1 |
EAP-Reissued-Payload | 0 | 0-1 |
Error-Message [BASE] | 0 | 0-1 |
Error-Reporting-Host [BASE] | 0 | 0-1 |
Failed-AVP [BASE] | 0 | 0+ |
Filter-Id [NASREQ] | 0 | 0+ |
Framed-Appletalk-Link [NASREQ] | 0 | 0-1 |
Framed-Appletalk-Network [NASREQ] | 0 | 0+ |
Framed-Appletalk-Zone [NASREQ] | 0 | 0-1 |
Framed-Compression [NASREQ] | 0+ | 0+ |
Framed-Interface-Id [NASREQ] | 0-1 | 0-1 |
Framed-IP-Address [NASREQ] | 0-1 | 0-1 |
Framed-IP-Netmask [NASREQ] | 0-1 | 0-1 |
Framed-IPv6-Prefix [NASREQ] | 0+ | 0+ |
Framed-IPv6-Pool [NASREQ] | 0 | 0-1 |
Framed-IPv6-Route [NASREQ] | 0 | 0+ |
Framed-IPX-Network [NASREQ] | 0 | 0-1 |
Framed-MTU [NASREQ] | 0-1 | 0-1 |
Framed-Pool [NASREQ] | 0 | 0-1 |
+---------------+ | コマンドコード| |-------+-------+ 属性名| DER| DEA| ------------------------------------|-------+-------| 会計EAP-Authメソッド| 0 | 0+ | Acctの当座の間隔[ベース]| 0 | 0-1 | Authアプリケーションイド[ベース]| 1 | 1 | Auth-据置期間の[ベース]| 0-1 | 0-1 | Auth要求タイプ[ベース]| 1 | 1 | Authセッション州の[ベース]| 0-1 | 0-1 | 承認生涯[ベース]| 0-1 | 0-1 | コールバックイド[NASREQ]| 0 | 0-1 | コールバック番号[NASREQ]| 0-1 | 0-1 | 呼ばれた駅のイド[NASREQ]| 0-1 | 0 | 呼んでいる駅のイド[NASREQ]| 0-1 | 0 | クラス[ベース]| 0 | 0+ | 構成トークン[NASREQ]| 0 | 0+ | インフォメーションを接続している[NASREQ]| 0-1 | 0 | あて先ホスト[ベース]| 0-1 | 0 | 目的地分野[ベース]| 1 | 0 | EAPマスターセッションキー| 0 | 0-1 | EAPの主要な名| 0-1 | 0-1 | EAP-有効搭載量| 1 | 0-1 | EAPは有効搭載量を再発行しました。| 0 | 0-1 | エラーメッセージ[ベース]| 0 | 0-1 | エラー報告ホスト[ベース]| 0 | 0-1 | 失敗したAVP[ベース]| 0 | 0+ | フィルタイド[NASREQ]| 0 | 0+ | 縁どられたAppletalkリンク[NASREQ]| 0 | 0-1 | 縁どられたAppletalkネットワーク[NASREQ]| 0 | 0+ | 縁どられたAppletalkゾーン[NASREQ]| 0 | 0-1 | 縁どられた圧縮[NASREQ]| 0+ | 0+ | 縁どられたインタフェースイド[NASREQ]| 0-1 | 0-1 | 縁どられたIPアドレス[NASREQ]| 0-1 | 0-1 | 縁どられたIPネットマスク[NASREQ]| 0-1 | 0-1 | 縁どられたIPv6接頭語[NASREQ]| 0+ | 0+ | 縁どられたIPv6プール[NASREQ]| 0 | 0-1 | 縁どられたIPv6ルート[NASREQ]| 0 | 0+ | 縁どられたIPXネットワーク[NASREQ]| 0 | 0-1 | 縁どられたMTU[NASREQ]| 0-1 | 0-1 | 縁どられたプール[NASREQ]| 0 | 0-1 |
Eronen, et al. Standards Track [Page 20] RFC 4072 Diameter EAP Application August 2005
Eronen、他 規格は直径EAPアプリケーション2005年8月にRFC4072を追跡します[20ページ]。
Framed-Protocol [NASREQ] | 0-1 | 0-1 | Framed-Route [NASREQ] | 0 | 0+ | Framed-Routing [NASREQ] | 0 | 0-1 | Idle-Timeout [NASREQ] | 0 | 0-1 | Multi-Round-Time-Out [BASE] | 0 | 0-1 | NAS-Filter-Rule [NASREQ] | 0 | 0+ | NAS-Identifier [NASREQ] | 0-1 | 0 | NAS-IP-Address [NASREQ] | 0-1 | 0 | NAS-IPv6-Address [NASREQ] | 0-1 | 0 | NAS-Port [NASREQ] | 0-1 | 0 | NAS-Port-Id [NASREQ] | 0-1 | 0 | NAS-Port-Type [NASREQ] | 0-1 | 0 | Originating-Line-Info [NASREQ] | 0-1 | 0 | Origin-Host [BASE] | 1 | 1 | Origin-Realm [BASE] | 1 | 1 | Origin-State-Id [BASE] | 0-1 | 0-1 | Port-Limit [NASREQ] | 0-1 | 0-1 | Proxy-Info [BASE] | 0+ | 0+ | QoS-Filter-Rule [NASREQ] | 0 | 0+ | Re-Auth-Request-Type [BASE] | 0 | 0-1 | Redirect-Host [BASE] | 0 | 0+ | Redirect-Host-Usage [BASE] | 0 | 0-1 | Redirect-Max-Cache-Time [BASE] | 0 | 0-1 | Reply-Message [NASREQ] | 0 | 0+ | Result-Code [BASE] | 0 | 1 | Route-Record [BASE] | 0+ | 0+ | Service-Type [NASREQ] | 0-1 | 0-1 | Session-Id [BASE] | 1 | 1 | Session-Timeout [BASE] | 0 | 0-1 | State [NASREQ] | 0-1 | 0-1 | Tunneling [NASREQ] | 0+ | 0+ | User-Name [BASE] | 0-1 | 0-1 |
縁どられたプロトコル[NASREQ]| 0-1 | 0-1 | 縁どられたルート[NASREQ]| 0 | 0+ | 縁どられたルート設定[NASREQ]| 0 | 0-1 | アイドルタイムアウト[NASREQ]| 0 | 0-1 | マルチラウンドタイムアウト[ベース]| 0 | 0-1 | NASフィルタ規則[NASREQ]| 0 | 0+ | NAS-識別子[NASREQ]| 0-1 | 0 | NAS IPアドレス[NASREQ]| 0-1 | 0 | NAS-IPv6-アドレス[NASREQ]| 0-1 | 0 | NAS-ポート[NASREQ]| 0-1 | 0 | NASポートイド[NASREQ]| 0-1 | 0 | NASポートタイプ[NASREQ]| 0-1 | 0 | 起因している線インフォメーション[NASREQ]| 0-1 | 0 | 発生源ホスト[ベース]| 1 | 1 | 発生源分野[ベース]| 1 | 1 | 発生源州のイド[ベース]| 0-1 | 0-1 | ポート限界[NASREQ]| 0-1 | 0-1 | プロキシインフォメーション[ベース]| 0+ | 0+ | QoSフィルタ規則[NASREQ]| 0 | 0+ | Authの要求の再タイプ[ベース]| 0 | 0-1 | 再直接のホスト[ベース]| 0 | 0+ | 再直接のホスト用法[ベース]| 0 | 0-1 | 再直接のマックスキャッシュ時間[ベース]| 0 | 0-1 | 応答メッセージ[NASREQ]| 0 | 0+ | 結果コード[ベース]| 0 | 1 | ルート記録[ベース]| 0+ | 0+ | サービスタイプ[NASREQ]| 0-1 | 0-1 | セッションイド[ベース]| 1 | 1 | セッションタイムアウト[ベース]| 0 | 0-1 | 状態[NASREQ]| 0-1 | 0-1 | トンネリング[NASREQ]| 0+ | 0+ | ユーザ名[ベース]| 0-1 | 0-1 |
5.2. Accounting AVP Table
5.2. 会計AVPテーブル
The table in this section is used to represent which AVPs defined in this document are to be present in the Accounting messages, as defined in [BASE].
このセクションのテーブルによる本書では定義されたどのAVPsを表すかに使用されているのは、Accountingメッセージに存在していることです、[基地]で定義されるようにことです。
+-----------+
| Command |
| Code |
|-----+-----+
Attribute Name | ACR | ACA |
---------------------------------------|-----+-----+
Accounting-EAP-Auth-Method | 0+ | 0 |
+-----------+ | コマンド| | コード| |-----+-----+ 属性名| ACR| ACA| ---------------------------------------|-----+-----+ 会計EAP-Authメソッド| 0+ | 0 |
Eronen, et al. Standards Track [Page 21] RFC 4072 Diameter EAP Application August 2005
Eronen、他 規格は直径EAPアプリケーション2005年8月にRFC4072を追跡します[21ページ]。
6. RADIUS/Diameter Interactions
6. 半径/直径相互作用
Section 9 of [NASREQ] describes basic guidelines for translation agents that translate between RADIUS and Diameter protocols. These guidelines SHOULD be followed for Diameter EAP application as well, with some additional guidelines given in this section. Note that this document does not restrict implementations from creating additional methods, as long as the translation function does not violate the RADIUS or the Diameter protocols.
[NASREQ]のセクション9はRADIUSとDiameterプロトコルの間で翻訳する翻訳エージェントのために基本指針について説明します。 これらのガイドラインSHOULD、また、Diameter EAPアプリケーションには、このセクションでいくつかの別途ガイドラインを与えていて続かれてください。 このドキュメントが追加メソッドを作成するので実装を制限しないことに注意してください、翻訳機能がRADIUSかDiameterプロトコルに違反しない限り。
6.1. RADIUS Request Forwarded as Diameter Request
6.1. 直径要求として転送された半径要求
RADIUS Access-Request to Diameter-EAP-Request:
EAPが要求する直径への半径アクセス要求:
o RADIUS EAP-Message attribute(s) are translated to a Diameter
EAP-Payload AVP. If multiple RADIUS EAP-Message attributes are
present, they are concatenated and translated to a single Diameter
EAP-Payload AVP.
o RADIUS EAP-メッセージ属性はDiameter EAP-有効搭載量AVPに翻訳されます。 複数のRADIUS EAP-メッセージ属性が存在しているなら、それらは、独身のDiameter EAP-有効搭載量AVPに連結されて、翻訳されます。
o An empty RADIUS EAP-Message attribute (with length 2) signifies
EAP-Start, and it is translated to an empty EAP-Payload AVP.
o 空のRADIUS EAP-メッセージ属性(長さ2がある)はEAP-始めを意味します、そして、それは空のEAP-有効搭載量AVPに翻訳されます。
Diameter-EAP-Answer to RADIUS Access-Accept/Reject/Challenge:
半径の直径EAP答えは、アクセスして受け入れるか、拒絶する、または挑戦します:
o Diameter EAP-Payload AVP is translated to RADIUS EAP-Message
attribute(s). If necessary, the value is split into multiple
RADIUS EAP-Message attributes.
o 直径EAP-有効搭載量AVPはRADIUS EAP-メッセージ属性に翻訳されます。 必要なら、値は複数のRADIUS EAP-メッセージ属性に分けられます。
o Diameter EAP-Reissued-Payload AVP is translated to a message that
contains RADIUS EAP-Message attribute(s), and a RADIUS Error-Cause
attribute [RFC3576] with value 202 (decimal), "Invalid EAP Packet
(Ignored)" [RFC3579].
o 値202の(小数)「無効のEAPパケット(無視される)」[RFC3579]でEAPが有効搭載量を再発行している直径AVPはRADIUS EAP-メッセージ属性を含むメッセージ、およびRADIUS Error-原因属性[RFC3576]に翻訳されます。
o As described in [NASREQ], if the Result-Code AVP set to
DIAMETER_MULTI_ROUND_AUTH and the Multi-Round-Time-Out AVP is
present, it is translated to the RADIUS Session-Timeout attribute.
o [NASREQ]で説明されるように、Result-コードAVPがDIAMETER_MULTI_ROUND_AUTHにセットして、Multiが時間を仕上げているAVPが存在しているなら、それはRADIUS Session-タイムアウト属性に翻訳されます。
o Diameter EAP-Master-Session-Key AVP can be translated to the
vendor-specific RADIUS MS-MPPE-Recv-Key and MS-MPPE-Send-Key
attributes [RFC2548]. The first up to 32 octets of the key is
stored into MS-MPPE-Recv-Key, and the next up to 32 octets (if
present) are stored into MS-MPPE-Send-Key. The encryption of this
attribute is described in [RFC2548].
o ベンダー特有のRADIUS MS MPPE-RecvキーとMPPEさんがキーを送っている属性[RFC2548]に直径EAPマスターセッションキーAVPを翻訳できます。 キーの最大最初の32の八重奏がMPPE-Recv Keyさんとして保存されます、そして、次の最大32の八重奏(存在しているなら)がMPPEがキーを送るさんとして保存されます。 この属性の暗号化は[RFC2548]で説明されます。
o Diameter Accounting-EAP-Auth-Method AVPs, if present, are
discarded.
o 存在しているなら、直径Accounting-EAP-Auth-メソッドAVPsは捨てられます。
Eronen, et al. Standards Track [Page 22] RFC 4072 Diameter EAP Application August 2005
Eronen、他 規格は直径EAPアプリケーション2005年8月にRFC4072を追跡します[22ページ]。
6.2. Diameter Request Forwarded as RADIUS Request
6.2. 半径要求として転送された直径要求
Diameter-EAP-Request to RADIUS Access-Request:
半径アクセス要求への直径EAP要求:
o The Diameter EAP-Payload AVP is translated to RADIUS EAP-Message
attribute(s).
o Diameter EAP-有効搭載量AVPはRADIUS EAP-メッセージ属性に翻訳されます。
o An empty Diameter EAP-Payload AVP signifies EAP-Start, and is
translated to an empty RADIUS EAP-Message attribute.
o 空のDiameter EAP-有効搭載量AVPはEAP-始めを意味して、空のRADIUS EAP-メッセージ属性に翻訳されます。
o The type (or expanded type) field from the EAP-Payload AVP can be
saved either in a local state table, or encoded in a RADIUS
Proxy-State attribute. This information is needed to construct an
Accounting-EAP-Auth-Method AVP for the answer message (see below).
o EAP-有効搭載量AVPからのタイプ(または、タイプを膨張させる)分野を地方のステートテーブルで節約するか、またはRADIUS Proxy-州の属性でコード化できます。 この情報が、答えメッセージのためにAccounting-EAP-Auth-メソッドAVPを組み立てるのに必要です(以下を見てください)。
RADIUS Access-Accept/Reject/Challenge to Diameter-EAP-Answer:
半径は、直径EAP答えにアクセスして受け入れるか、拒絶する、または挑戦します:
o If the RADIUS Access-Challenge message does not contain an
Error-Cause attribute [RFC3576] with value 202 (decimal), "Invalid
EAP Packet (Ignored)" [RFC3579], any RADIUS EAP-Message attributes
are translated to a Diameter EAP-Payload AVP, concatenating them
if multiple attributes are present.
o RADIUS Access-挑戦メッセージが値202の(小数)があるError-原因属性[RFC3576]、「無効のEAPパケット(無視される)」を含んでいないなら[RFC3579]、どんなRADIUS EAP-メッセージ属性もDiameter EAP-有効搭載量AVPに翻訳されます、複数の属性が存在しているならそれらを連結して。
o If the Error-Cause attribute with value 202 is present, any RADIUS
EAP-Message attributes are translated to a Diameter
EAP-Reissued-Payload AVP, concatenating them if multiple
attributes are present.
o 値202があるError-原因属性が存在しているなら、どんなRADIUS EAP-メッセージ属性もDiameter EAPが有効搭載量を再発行しているAVPに翻訳されます、複数の属性が存在しているならそれらを連結して。
o As described in [NASREQ], if the Session-Timeout attribute is
present in a RADIUS Access-Challenge message, it is translated to
the Diameter Multi-Round-Time-Out AVP.
o [NASREQ]で説明されるように、Session-タイムアウト属性がRADIUS Access-挑戦メッセージに存在しているなら、それはDiameter Multiが時間を仕上げているAVPに翻訳されます。
o If the vendor-specific RADIUS MS-MPPE-Recv-Key and/or
MS-MPPE-Send-Key attributes [RFC2548] are present, they can be
translated to a Diameter EAP-Master-Session-Key AVP. The
attributes have to be decrypted before conversion, and the Salt,
Key-Length and Padding sub-fields are discarded. The Key
sub-fields are concatenated (MS-MPPE-Recv-Key first,
MS-MPPE-Send-Key next), and the concatenated value is stored into
a Diameter EAP-Master-Session-Key AVP.
o ベンダー特有のRADIUS MS MPPE-Recvキー、そして/または、MPPEさんがキーを送っている属性[RFC2548]が存在しているなら、Diameter EAPマスターセッションキーAVPにそれらを翻訳できます。 変換、Salt、Key-長さ、およびPaddingサブ分野が捨てられる前に属性は解読されなければなりません。 Keyサブ分野は連結されます、そして、(MPPE-Recv Key1第さん、MPPEさんがキーを送っている次)連結された値はDiameter EAPマスターセッションキーAVPとして保存されます。
o If the Diameter-EAP-Answer will have a successful result code, the
saved state (see above) can be used to construct an
Accounting-EAP-Auth-Method AVP.
o Diameter-EAP-答えに好成績コードがあるなら、Accounting-EAP-Auth-メソッドAVPを組み立てるのに、保存している状態(上を見る)を使用できます。
Eronen, et al. Standards Track [Page 23] RFC 4072 Diameter EAP Application August 2005
Eronen、他 規格は直径EAPアプリケーション2005年8月にRFC4072を追跡します[23ページ]。
6.3. Accounting Requests
6.3. 会計要求
In Accounting-Requests, the vendor-specific RADIUS MS-Acct-EAP-Type attribute [RFC2548] can be translated to a Diameter Accounting-EAP-Auth-Method AVP, and vice versa.
Accounting-要求では、ベンダー特有のRADIUS MS Acct-EAPがタイプしている属性[RFC2548]はDiameter Accounting-EAP-Auth-メソッドAVPに翻訳できます、そして、逆もまた同様です。
When translating from Diameter to RADIUS, note that the MS-Acct-EAP-Type attribute does not support expanded EAP types. Type values greater than 255 should be translated to type 254.
DiameterからRADIUSまで翻訳するときには、MS Acct-EAPがタイプしている属性が拡張EAPタイプをサポートしないことに注意してください。 255が254をタイプするために翻訳されるべきであるより大きい値をタイプしてください。
7. IANA Considerations
7. IANA問題
This document does not create any new namespaces to be maintained by IANA, but it requires new values in namespaces that have been defined in the Diameter Base protocol and RADIUS specifications.
このドキュメントはIANAによって維持されるどんな新しい名前空間も作成しませんが、それはDiameter基地のプロトコルで定義された名前空間とRADIUS仕様で新しい値を必要とします。
o This document defines one new Diameter command (in Section 3)
whose Command Code is allocated from the Command Code namespace
defined in [BASE]. The Command Code for DER / DEA is 268.
o このドキュメントはCommand Codeが[基地]で定義されたCommand Code名前空間から割り当てられる1つの新しいDiameterコマンド(セクション3における)を定義します。 DER/DEAのためのCommand Codeは268歳です。
o This document defines four new AVPs whose AVP Codes are allocated
from the AVP Code namespace defined in [BASE] as follows:
o このドキュメントはAVP Codesが以下の[基地]で定義されたAVP Code名前空間から割り当てられる4新しいAVPsを定義します:
462 for EAP-Payload (defined in Section 4.1.1),
463 for EAP-Reissued-Payload (defined in Section 4.1.2),
464 for EAP-Master-Session-Key (defined in Section 4.1.3), and
465 for Accounting-EAP-Auth-Method (defined in Section 4.1.5).
中で定義されて、EAPが有効搭載量を再発行したので、4.1に.1、)463を区分してください。EAP-有効搭載量のための462、((.2、)464はEAPマスターセッションキー(セクション4.1.3では、定義される)のためにセクション4.1で定義されて、465は会計EAP-Authメソッド(セクション4.1.5では、定義される)のために定義されました。
o This document defines one new AVP (attribute) whose AVP Code
(Attribute Type) is to be allocated from the Attribute Type
namespace defined in [RFC2865] and [RFC3575]. The Radius
Attribute Type for EAP-Key-Name (defined in Section 4.1.4) is 102.
o このドキュメントはAVP Code(属性Type)が[RFC2865]と[RFC3575]で定義されたAttribute Type名前空間から割り当てられることになっている1新しいAVP(属性)を定義します。 EAPの主要な名(セクション4.1.4では、定義される)のためのRadius Attribute Typeは102歳です。
o This document defines one new Diameter application (in
Section 2.1) whose Application ID is to be allocated from the
Application Identifier namespace defined in [BASE]. The
Application ID for Diameter EAP is 5.
o このドキュメントはIDが[基地]で定義されたApplication Identifier名前空間からApplicationに割り当てられることになっている1つの新しいDiameterアプリケーション(セクション2.1における)を定義します。 Diameter EAPのためのApplication IDは5です。
8. Security Considerations
8. セキュリティ問題
8.1. Overview
8.1. 概要
Diameter peer-to-peer connections can be protected with IPsec or TLS. These mechanisms are believed to provide sufficient protection under the normal Internet threat model, that is, assuming the authorized nodes engaging in the protocol have not been compromised, but the attacker has complete control over the communication channels between them. This includes eavesdropping, message modification, insertion,
IPsecかTLSと共に直径ピアツーピア接続を保護できます。 これらのメカニズムがすなわち、普通のインターネットの脅威モデル、プロトコルで魅力的な認可されたノードが感染されていない仮定の下に十分な保護を提供すると信じられていますが、攻撃者はそれらの間に通信チャネルの完全なコントロールを持っています。 これは盗聴、メッセージ変更、挿入を含んでいます。
Eronen, et al. Standards Track [Page 24] RFC 4072 Diameter EAP Application August 2005
Eronen、他 規格は直径EAPアプリケーション2005年8月にRFC4072を追跡します[24ページ]。
man-in-the-middle and replay attacks. The details and related security considerations are discussed in [BASE].
中央の人と反射攻撃。 [基地]で詳細と関連するセキュリティ問題について議論します。
In addition to authentication provided by IPsec or TLS, authorization is also required. Here, authorization means determining if a Diameter message received from an authenticated Diameter peer should be accepted (and not authorization of users requesting network access from a NAS). In other words, when a Diameter server receives a Diameter-EAP-Request, it has to decide if the client is authorized to act as a NAS for the specific user, service type, and so on. Correspondingly, when a NAS contacts a server to send a Diameter-EAP-Request, it has to determine whether the server is authorized to act as home server for the realm in question.
また、IPsecかTLSによって提供された認証に加えて、承認が必要です。 ここで、Diameterメッセージが認証されたDiameter同輩から受信されたかどうか決定する承認手段を受け入れるべきです(そして、NASからネットワークアクセスを要求するユーザの承認でない)。 言い換えれば、DiameterサーバがDiameter-EAP-要求を受け取るとき、それは、クライアントが特定のユーザ、サービスタイプなどのためのNASとして機能するのに権限を与えられるかどうか決めなければなりません。 NASがDiameter-EAP-要求を送るためにサーバに連絡するとき、それは、サーバが分野へのホームサーバとして問題に機能するのが認可されるかどうか対応する、決定しなければなりません。
Authorization can involve local Access Control Lists (ACLs), information contained in certificates, or some other means. See [BASE] for more discussion and related security considerations. Note that authorization issues are particularly relevant when Diameter redirects are used. While redirection reduces the number of nodes which have access to the contents of Diameter messages, a compromised Diameter agent may not supply the right home server's address. If the Diameter client is unable to tell whether this particular server is authorized to act as the home server for this particular user, the security of the communications rests on the redirect agent.
承認は地方のAccess Control Lists(ACLs)、証明書に含まれた情報、またはある他の手段にかかわることができます。 より多くの議論と関連するセキュリティ問題に関して[基地]を見てください。 Diameterであるときに、承認問題が特に関連していることに注意してください、向け直す、使用されます。 リダイレクションがDiameterメッセージのコンテンツに近づく手段を持っているノードの数を減少させている間、感染しているDiameterエージェントは正しいホームサーバのアドレスを供給しないかもしれません。 Diameterクライアントが、この特定のサーバがこの特定のユーザのためのホームサーバとして機能するのが認可されるかどうかわからないなら、コミュニケーションのセキュリティは再直接のエージェントで休息しています。
The hop-by-hop security mechanisms (IPsec and TLS) combined with proper authorization provide good protection against "outside" attackers, except for denial-of-service attacks. The remaining part of this section deals with attacks by nodes that have been properly authorized (to function as a NAS, Diameter agent, or Diameter server), but abuse their authorization or have been compromised. In general, it is not possible to completely protect against attacks by compromised nodes, but this section offers advice on limiting the extent of the damage.
ホップごとの適切な承認に結合されたセキュリティー対策(IPsecとTLS)は「外」の攻撃者に対する良い保護を提供します、サービス不能攻撃を除いて。 このセクションの残存部分は適切に認可された(NAS、Diameterエージェント、またはDiameterサーバとして機能する)ノードで攻撃に対処します、彼らの承認を乱用するか、または感染されたのを除いて。 一般に、感染しているノードで攻撃から完全に守るのが可能ではありませんが、損害の程度を制限するとき、このセクションはアドバイスします。
Attacks involving eavesdropping or modification of EAP messages are beyond the scope of these document. See [EAP] for discussion of these security considerations (including method negotiation, dictionary attacks, and privacy issues). While these attacks can be carried out by an attacker between the client and the NAS, compromised NASes and Diameter agents are naturally also in a good position to modify and eavesdrop on the EAP messages.
EAPメッセージの盗聴か変更にかかわる攻撃がこれらのドキュメントの範囲を超えています。 これらのセキュリティ問題の議論に関して[EAP]を見てください(メソッド交渉、辞書攻撃、およびプライバシーの問題を含んでいて)。 クライアントとNASの間の攻撃者はこれらの攻撃を行うことができますが、感染しているNASesとDiameterエージェントはEAPメッセージを変更して、立ち聞きする良い立場にもいます。
Similarly, attacks involving the link layer protocol used between the client and the NAS, such as PPP or IEEE 802.11, are beyond the scope of this document.
同様に、PPPかIEEE802.11などのクライアントとNASの間で使用されるリンクレイヤプロトコルにかかわる攻撃がこのドキュメントの範囲を超えています。
Eronen, et al. Standards Track [Page 25] RFC 4072 Diameter EAP Application August 2005
Eronen、他 規格は直径EAPアプリケーション2005年8月にRFC4072を追跡します[25ページ]。
8.2. AVP Editing
8.2. AVP編集
Diameter agents can modify, insert, and delete AVPs. Diameter agents are usually meant to modify AVPs, and the protocol cannot distinguish well-intentioned and malicious modifications (see [RFC2607] for more discussion). Similarly, a compromised NAS or server can naturally include a different set of AVPs than expected.
直径エージェントは、AVPsを変更して、挿入して、削除できます。 通常、直径エージェントはAVPsを変更することになっています、そして、プロトコルは善意の、そして、悪意がある変更を区別できません(より多くの議論に関して[RFC2607]を見てください)。 同様に、感染しているNASかサーバが自然にAVPsの予想と異なったセットを含むことができます。
Therefore, the question is what an attacker who compromises an authorized NAS, agent, or server can do using Diameter EAP messages. Some of the consequences are rather obvious. For instance, a Diameter agent can give access to unauthorized users by changing the Result-Code to DIAMETER_SUCCESS. Other consequences are less obvious and are discussed below and authentication method negotiation attacks are discussed in the next section.
したがって、質問は認可されたNAS、エージェント、またはサーバがDiameter EAPメッセージを使用することで妥協するどんな攻撃者ができるかということです。 結果のいくつかがかなり明白です。 例えば、Diameterエージェントは、Result-コードをDIAMETER_SUCCESSに変えることによって、権限のないユーザへのアクセスを与えることができます。 他の結果について、それほど明白でなく、以下で議論します、そして、次のセクションで認証方法交渉攻撃について議論します。
By including suitable AVPs in an AA-Answer/Diameter-EAP-Answer messages, an attacker may be able (depending on implementation and configuration details) to:
直径EAP AA-答え/答えに適当なAVPsを含んでいることによって、メッセージであり攻撃者は以下のことのためにできるかもしれません(実装と構成の詳細によります)。
o Give unauthorized users access, or deny access to authorized users
(Result-Code).
o 権限のないユーザアクセスをお願いしますか認定ユーザ(結果コード)へのアクセスを拒絶してください。
o Give an attacker a login session to a host otherwise protected by
firewalls, or redirect an authorized user's login session to a
host controlled by the attacker (Login-Host).
o 別の方法でファイアウォールによって保護されたホストへのログインセッションを攻撃者に与えるか、または攻撃者(ログインホスト)によって監督されたホストに認定ユーザのログインセッションを向け直してください。
o Route an authorized user's traffic through a host controlled by
the attacker (various tunneling AVPs).
o 攻撃者(様々なトンネリングAVPs)によって監督されたホストを通して認定ユーザのトラフィックを発送してください。
o Redirect an authorized user's DNS requests to a malicious DNS
server (various vendor-specific AVPs).
o 悪意があるDNSサーバ(様々なベンダー特有のAVPs)に認定ユーザのDNS要求を向け直してください。
o Modify routing tables at the NAS and thus redirect packets
destined for someone else (Framed-Route, Framed-Routing).
o NASとその結果他の誰か(縁どられたルートであって、Framedを発送している)のために運命づけられた再直接のパケットで経路指定テーブルを変更してください。
o Remove packet filters and other restrictions for user (Filter,
Callback, various vendor-specific AVPs).
o ユーザ(フィルタ、Callback、様々なベンダー特有のAVPs)にパケットフィルタと他の制限を取り外してください。
o Cause the NAS to call some number, possibly an expensive toll
number controlled by the attacker (callback AVPs).
o NASが何らかの数、ことによると攻撃者(コールバックAVPs)によって制御された高価な市外局番を呼ぶことを引き起こしてください。
o Execute Command Line Interface (CLI) commands on the NAS (various
vendor-specific attributes).
o NAS(様々なベンダー特有の属性)でCommand線Interface(CLI)コマンドを実行してください。
Eronen, et al. Standards Track [Page 26] RFC 4072 Diameter EAP Application August 2005
Eronen、他 規格は直径EAPアプリケーション2005年8月にRFC4072を追跡します[26ページ]。
By modifying an AA-Request/Diameter-EAP-Request, an attacker may be able to:
直径EAP AA-要求/要求を変更することによって、攻撃者は以下にできるかもしれません。
o Change NAS-Identifier/NAS-Port/Origin-Host (or another attribute)
so that a valid user appears to be accessing the network from a
different NAS than in reality.
o 正規ユーザーが、異なったNASからネットワークにアクセスしているように見えるように、発生源NAS NAS-識別子/ポート/ホスト(または、別の属性)を変えてください、ほんとうは。
o Modify Calling-Station-ID (either to hide the true value, gain
access, or frame someone else).
o Calling駅のID(真の値を隠すか、アクセスを得るか、または他の誰かを縁どる)を変更してください。
o Modify password change messages (some vendor-specific attributes).
o パスワード変化メッセージ(いくつかのベンダー特有の属性)を変更してください。
o Modify usage information in accounting messages.
o 会計メッセージの用法情報を変更してください。
o Modify contents of Class and State AVPs.
o Classと州AVPsのコンテンツを変更してください。
Some of these attacks can be prevented if the NAS or server is configured to not accept some particular AVPs, or accepts them only from some nodes.
NASかサーバがいくつかの特定のAVPsを受け入れないように構成されるか、または単にいくつかのノードから彼らを受け入れるなら、これらの攻撃のいくつかを防ぐことができます。
8.3. Negotiation Attacks
8.3. 交渉攻撃
This section deals with attacks where the NAS, any Diameter agents, or Diameter server attempt to cause the authenticating user to choose some authentication method other than EAP, such as PAP or CHAP (negotiation attacks within EAP are discussed in [EAP], Section 7.8).
NAS、どんなDiameterエージェント、またはDiameterサーバも、認証しているユーザがEAP以外の何らかの認証方法を選ぶことを引き起こすのを試みるところでこのセクションは攻撃に対処します、PAPやCHAPのように([EAP]でEAPの中の交渉攻撃について議論します、セクション7.8)。
The vulnerability can be mitigated via implementation of a per- connection policy by the authenticating peer, and a per-user policy by the Diameter server. For the authenticating peer, the authentication policy should be set on a per-connection basis.
aの実装で脆弱性を緩和できる、-、認証している同輩による接続方針、およびDiameterサーバによる1ユーザあたり1つの方針. 認証している同輩にとって、認証方針は1接続あたり1個のベースに設定しているべきです。
With a per-connection policy, an authenticating peer will only attempt to negotiate EAP for a session in which EAP support is expected. As a result, it is presumed that an authenticating peer selecting EAP requires that level of security. If it cannot be provided, there is likely a misconfiguration, or the authenticating peer may be contacting the wrong server. In this case, the authenticating peer simply disconnects.
1接続あたり1つの方針で、認証している同輩は、EAPサポートが予想されるセッションのためにEAPを交渉するのを試みるだけでしょう。 その結果、EAPを選択する認証している同輩がそのレベルのセキュリティを必要とすると推定されます。 それを提供できないなら、misconfigurationがおそらくあるか、または認証している同輩は間違ったサーバに連絡しているかもしれません。この場合、認証している同輩は単に切断します。
Similarly, with a per-user policy, the home server will not accept authentication methods other than EAP for users for which EAP support is expected.
同様に、1ユーザあたり1つの方針で、ホームサーバはEAPサポートが予想されるユーザのためのEAP以外の認証方法を受け入れないでしょう。
For a NAS, it may not be possible to determine whether a peer is required to authenticate with EAP until the peer's identity is known. For example, for shared-uses NASes one reseller may implement EAP while another does not. Alternatively, some peer might be
NASに関しては、同輩のアイデンティティが知られるまで同輩がEAPと共に認証するのに必要であるかどうか決定するのは可能でないかもしれません。 例えば、共有された用途のために、NASes1再販業者は別のものが実装していない間、EAPを実装するかもしれません。 あるいはまた、同輩はそうです。
Eronen, et al. Standards Track [Page 27] RFC 4072 Diameter EAP Application August 2005
Eronen、他 規格は直径EAPアプリケーション2005年8月にRFC4072を追跡します[27ページ]。
authenticated locally by the NAS while other peers are authenticated via Diameter. In such cases, if any peers of the NAS MUST do EAP, then the NAS MUST attempt to negotiate EAP for every session. This avoids forcing a peer to support more than one authentication type, which could weaken security.
他の同輩はDiameterを通して認証されますが、NASによって局所的に認証されます。 そのような場合、NAS MUSTのどれか同輩がEAPをするなら、NAS MUSTは、あらゆるセッションのためにEAPを交渉するのを試みます。 これは、同輩に1つ以上の認証タイプをサポートさせるのを避けます。(タイプはセキュリティを弱めることができました)。
8.4. Session Key Distribution
8.4. セッションの主要な分配
Since there are currently no end-to-end (NAS-to-home server) security mechanisms specified for Diameter, any agents that process Diameter-EAP-Answer messages can see the contents of the EAP-Master-Session-Key AVP. For this reason, this specification strongly recommends avoiding Diameter agents when they cannot be trusted to keep the keys secret.
以来、現在の終わりからDiameterに指定されたセキュリティー対策、処理するどんなエージェントもEAPマスターセッションキーのコンテンツを見ることができないとメッセージにDiameter-EAP答えるどんな終わり(NASからホームサーバ)にも、AVPがありません。 この理由で、この仕様は、彼らがキーを秘密にすると信じることができないとき、Diameterエージェントを避けることを強く勧めます。
In environments where agents are present, several factors should be considered when deciding whether the agents that are authorized (and considered "trustworthy enough") to grant access to users and specify various authorization and tunneling AVPs are also "trustworthy enough" to handle the session keys. These factors include (but are not limited to) the type of access provided (e.g., public Internet or corporate internet), security level of the agents, and the possibilities for attacking user's traffic after it has been decrypted by the NAS.
エージェントが出席している環境で、また、ユーザへのアクセスを承諾して、様々な承認とトンネリングAVPsを指定するのに権限を与えられる(そして、「十分信頼できる」と考えられます)エージェントもセッションキーを扱うために「十分信頼できるかどうか」決めるとき、いくつかの要素が考えられるべきです。 しかし、これらの要素が含んでいる、(制限されない、)、それがNASによって解読された後にアクセスのタイプは(例えば、公共のインターネットの、または、法人のインターネット)、エージェントのセキュリティー・レベル、およびユーザのトラフィックを攻撃するための可能性を提供しました。
Note that the keys communicated in Diameter messages are usually short-term session keys (or short-term master keys that are used to derive session keys). To actually cause any damage, those session keys must end up with some malicious party that must be able to eavesdrop, modify, or insert traffic between the user and the NAS during the lifetime of those keys (for example, in 802.11i the attacker must also eavesdrop the "four-way handshake").
Diameterメッセージで伝えられたキーが通常短期的なセッションキー(または、セッションキーを引き出すのに使用される短期的なマスターキー)であることに注意してください。 実際にどんな損害ももたらすために、それらのセッションキーはそれらのキーの生涯ユーザとNASの間にトラフィックを盗み聞かなければならないか、変更しなければならないか、または挿入できなければならないいくつかの悪意があるパーティーで、終わらなければなりません(例えば、また、802.11iでは、攻撃者は「4方法の握手」を盗み聞かなければなりません)。
8.5. Privacy Issues
8.5. プライバシーの問題
Diameter messages can contain AVPs that can be used to identify the user (e.g., User-Name) and approximate location of the user (e.g., Origin-Host for WLAN access points, Calling-Station-Id for fixed phone lines). Thus, any Diameter nodes that process the messages may be able to determine the geographic location of users.
直径メッセージはユーザのユーザ(例えば、User-名前)と大体の位置を特定するのに使用できるAVPsを含むことができます(例えば、WLANアクセスポイントへのOrigin-ホスト、固定電話のためのCalling駅のイドは立ち並んでいます)。 したがって、メッセージを処理するどんなDiameterノードもユーザの地理的な位置を決定できるかもしれません。
Note that in many cases, the user identity is also sent in clear inside EAP-Payload AVPs, and it may be possible to eavesdrop this between the user and the NAS.
また、多くの場合、ユーザアイデンティティが明確な内部のEAP-有効搭載量AVPsで送られることに注意してください。そうすれば、ユーザとNASの間でこれを盗み聞くのは可能であってもよいです。
This can be mitigated somewhat by using EAP methods that provide identity protection (see [EAP], Section 7.3), and using Session-Id or pseudonyms for accounting.
いくらか、アイデンティティ保護([EAP]を見てください、セクション7.3)を提供するEAPメソッドを使用して、会計にSession-イドか匿名を使用することによって、これを緩和できます。
Eronen, et al. Standards Track [Page 28] RFC 4072 Diameter EAP Application August 2005
Eronen、他 規格は直径EAPアプリケーション2005年8月にRFC4072を追跡します[28ページ]。
8.6. Note about EAP and Impersonation
8.6. EAPとものまねに関する注
If the EAP method used does not provide mutual authentication, obviously anyone can impersonate the network to the user. Even when EAP mutual authentication is used, it occurs between the user and the Diameter home server. See [EAPKey] for an extensive discussion about the details and their implications.
メソッドが使用したEAPが互いの認証を提供しないなら、明らかに、だれでもユーザにネットワークをまねることができます。 EAPの互いの認証が使用されてさえいるとき、それはユーザとDiameterホームサーバの間に起こります。詳細とそれらの含意についての大規模な議論に関して[EAPKey]を見てください。
One issue is worth pointing out here. As described in [EAPKey], the current EAP architecture does not allow the home server to restrict what service parameters or identities (such as SSID or BSSID in 802.11 wireless LANs) are advertised by the NAS to the client. That is, a compromised NAS can change its BSSID or SSID, and thus appear to offer a different service than intended. Even if these parameters are included in Diameter-EAP-Answer messages, the NAS can tell different values to the client.
1冊はここで指摘する価値があります。 [EAPKey]で説明されるように、ホームサーバは、現在のEAPアーキテクチャでサービスパラメタかアイデンティティ(802.11の無線LANによるSSIDかBSSIDなどの)がNASによってクライアントに広告を出されたものであることを制限できません。 すなわち、感染しているNASは、意図するよりそのBSSIDかSSIDを変えて、その結果、異なったサービスを提供するように見えることができます。 これらのパラメタがDiameter-EAP-答えメッセージに含まれても、NASは異価をクライアントに言うことができます。
Therefore, the NAS's possession of the session keys proves that the user is talking to an authorized NAS, but a compromised NAS can lie about its exact identity. See [EAPKey] for discussion on how individual EAP methods can provide authentication of NAS service parameters and identities.
したがって、NASのセッションキーの所持は、ユーザが認可されたNASと話していると立証しますが、正確なアイデンティティに関して感染しているNASがいることができます。 独特のEAPメソッドがどうNASサービスパラメタとアイデンティティの認証を提供できるかについての議論に関して[EAPKey]を見てください。
Note that the usefulness of this authentication may be rather limited in many environments. For instance, in wireless LANs the user does not usually securely know the identity (such as BSSID) of the "right" access point; it is simply picked from a beacon message that has the correct SSID and good signal strength (something that is easy to spoof). Thus, simply authenticating the identity may not allow the user to distinguish the "right" access point from all others.
この認証の有用性が多くの環境がかなり限られるかもしれないことに注意してください。 例えば、無線LANで、通常、ユーザはしっかりと、「正しい」アクセスポイントのアイデンティティ(BSSIDなどの)を知りません。 それは正しいSSIDと良い信号強度(何か偽造しやすいもの)を持っている標識メッセージから単に選ばれます。 ユーザはしたがって、単にアイデンティティを認証するのにすべての他のものと「正しい」アクセスポイントを区別できないかもしれません。
9. Acknowledgements
9. 承認
This Diameter application relies heavily on earlier work on Diameter NASREQ application [NASREQ] and RADIUS EAP support [RFC3579]. Much of the material in this specification has been copied from these documents.
このDiameterアプリケーションは大いにDiameter NASREQアプリケーション[NASREQ]とRADIUS EAPサポート[RFC3579]に対する以前の仕事に依存します。 これらのドキュメントからこの仕様による材料の多くをコピーしてあります。
The authors would also like to acknowledge the following people for their contributions to this document: Bernard Aboba, Jari Arkko, Julien Bournelle, Pat Calhoun, Henry Haverinen, John Loughney, Yoshihiro Ohba, and Joseph Salowey.
また、作者はこのドキュメントへの彼らの貢献のために以下の人々を承認したがっています: バーナードAboba(ヤリArkko、ジュリアンBournelle)はカルフーン、ヘンリーHaverinen、ジョンLoughney、芳広オオバ、およびジョゼフSaloweyを軽くたたきます。
Eronen, et al. Standards Track [Page 29] RFC 4072 Diameter EAP Application August 2005
Eronen、他 規格は直径EAPアプリケーション2005年8月にRFC4072を追跡します[29ページ]。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[BASE] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and
J. Arkko, "Diameter Base Protocol", RFC 3588,
September 2003.
[ベース]カルフーンとP.とLoughneyとJ.とGuttmanとE.とゾルン、G.とJ.Arkko、「直径基地のプロトコル」、RFC3588、2003年9月。
[EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
H. Levkowetz, "Extensible Authentication Protocol
(EAP)", RFC 3748, June 2004.
[EAP]Aboba、B.、Blunk、L.、Vollbrecht、J.、カールソン、J.とH.Levkowetz、「拡張認証プロトコル(EAP)」RFC3748、2004年6月。
[NASREQ] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
"Diameter Network Access Server Application", RFC
4005, August 2005.
[NASREQ] カルフーンとP.とゾルンとG.とスペンス、D.とD.ミットン、「直径ネットワークアクセス・サーバーアプリケーション」、RFC4005、2005年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
10.2. Informative References
10.2. 有益な参照
[EAPKey] Aboba, B., Simon, D., Arkko, J., Eronen, P., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)
Key Management Framework", Work in Progress, July
2004.
B.、サイモン、D.、Arkko、J.、Eronen、P.、およびH.Levkowetz、「拡張認証プロトコル(EAP)Key Managementフレームワーク」という[EAPKey]Abobaは進行中(2004年7月)で働いています。
[IEEE-802.1X] Institute of Electrical and Electronics Engineers,
"Local and Metropolitan Area Networks: Port-Based
Network Access Control", IEEE Standard 802.1X,
September 2001.
[IEEE-802.1X]米国電気電子技術者学会、「地方とメトロポリタンエリアネットワーク:」 「ポートベースのネットワークアクセスコントロール」、IEEEの標準の802.1X、2001年9月。
[IEEE-802.11i] Institute of Electrical and Electronics Engineers,
"IEEE Standard for Information technology -
Telecommunications and information exchange between
systems - Local and metropolitan area networks -
Specific requirements - Part 11: Wireless Medium
Access Control (MAC) and Physical Layer (PHY)
Specifications: Amendment 6: Medium Access Control
(MAC) Security Enhancements", IEEE Standard
802.11i-2004, July 2004.
[IEEE-802.11i]米国電気電子技術者学会、「情報技術(システムの間のテレコミュニケーションと情報交換)における、地方のIEEE Standardとメトロポリタンエリアネットワーク(決められた一定の要求)は11を分けます」。 ワイヤレスの媒体アクセス制御(MAC)と物理的な層(PHY)の仕様: 修正6: 「媒体アクセス制御(MAC)セキュリティ増進」、IEEEの標準の802.11i-2004、2004年7月。
[IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Protocol", Work in Progress, June 2004.
[IKEv2] コーフマン、C.、エド、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、処理中の作業、6月2004
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)",
STD 51, RFC 1661, July 1994.
[RFC1661] シンプソン、W.、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月。
Eronen, et al. Standards Track [Page 30] RFC 4072 Diameter EAP Application August 2005
Eronen、他 規格は直径EAPアプリケーション2005年8月にRFC4072を追跡します[30ページ]。
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS
Attributes", RFC 2548, March 1999.
[RFC2548] ゾルン、G.、「マイクロソフトのベンダー特有の半径属性」、RFC2548、1999年3月。
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and
Policy Implementation in Roaming", RFC 2607,
June 1999.
[RFC2607] Aboba、B.、J.Vollbrecht、および「ローミングにおけるプロキシ推論と政策の実施」、RFC2607、6月1999日
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC2865] Rigney、C.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、「ユーザサービス(半径)におけるリモート認証ダイヤル」、RFC2865(2000年6月)。
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote
Authentication Dial In User Service)", RFC 3575,
July 2003.
[RFC3575] Aboba、B.、「半径(ユーザサービスにおけるリモート認証ダイヤル)のためのIANA問題」、RFC3575、2003年7月。
[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] 千葉、M.、Dommety、G.、エクルンド、M.、ミットン、D.、およびB.Aboba、「リモート認証へのダイナミックな承認拡大はユーザでサービス(半径)にダイヤルします」、RFC3576、2003年7月。
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote
Authentication Dial In User Service) Support For
Extensible Authentication Protocol (EAP)", RFC 3579,
September 2003.
[RFC3579]Aboba、B.とP.カルフーン、「拡張認証プロトコル(EAP)の半径(ユーザサービスにおけるリモート認証ダイヤル)サポート」RFC3579(2003年9月)。
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J.
Roese, "IEEE 802.1X Remote Authentication Dial In User
Service (RADIUS) Usage Guidelines", RFC 3580,
September 2003.
[RFC3580] コングドン、P.、Aboba、B.、スミス、A.、ゾルン、G.、およびJ.Roese、「ユーザサービス(半径)用法ガイドラインのIEEE 802.1Xのリモート認証ダイヤル」、RFC3580(2003年9月)。
Eronen, et al. Standards Track [Page 31] RFC 4072 Diameter EAP Application August 2005
Eronen、他 規格は直径EAPアプリケーション2005年8月にRFC4072を追跡します[31ページ]。
Authors' Addresses
作者のアドレス
Pasi Eronen (editor) Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland
パシEronen(エディタ)ノキアリサーチセンター私書箱407フィン-00045Nokia Groupフィンランド
EMail: pasi.eronen@nokia.com
メール: pasi.eronen@nokia.com
Tom Hiller Lucent Technologies 1960 Lucent Lane Naperville, IL 60566 USA
トムヒラールーセントテクノロジーズ1960の透明なLane IL60566ナパービル(米国)
Phone: +1 630 979 7673 EMail: tomhiller@lucent.com
以下に電話をしてください。 +1 7673年の630 979メール: tomhiller@lucent.com
Glen Zorn Cisco Systems 500 108th Avenue N.E., Suite 500 Bellevue, WA 98004 USA
谷間ゾルンシスコシステムズ500第108アベニューの東北、Suite500ベルビュー、ワシントン98004米国
Phone: +1 425 344 8113 EMail: gwz@cisco.com
以下に電話をしてください。 +1 8113年の425 344メール: gwz@cisco.com
Eronen, et al. Standards Track [Page 32] RFC 4072 Diameter EAP Application August 2005
Eronen、他 規格は直径EAPアプリケーション2005年8月にRFC4072を追跡します[32ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Eronen, et al. Standards Track [Page 33]
Eronen、他 標準化過程[33ページ]
一覧
スポンサーリンク
