RFC3576 日本語訳
3576 Dynamic Authorization Extensions to Remote Authentication Dial InUser Service (RADIUS). M. Chiba, G. Dommety, M. Eklund, D. Mitton, B.Aboba. July 2003. (Format: TXT=70027 bytes) (Obsoleted by RFC5176) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Chiba
Request for Comments: 3576 G. Dommety
Category: Informational M. Eklund
Cisco Systems, Inc.
D. Mitton
Circular Logic, UnLtd.
B. Aboba
Microsoft Corporation
July 2003
コメントを求めるワーキンググループM.千葉の要求をネットワークでつないでください: 3576年のG.Dommetyカテゴリ: UnLtd情報のM.エクルンド・シスコシステムズのInc.D.ミットンCircularの論理、B.Abobaマイクロソフト社2003年7月
Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)
リモート認証へのダイナミックな承認拡大はユーザでサービスにダイヤルします。(半径)
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
This document describes a currently deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, allowing dynamic changes to a user session, as implemented by network access server products. This includes support for disconnecting users and changing authorizations applicable to a user session.
このドキュメントはRemote Authentication Dial In User Service(RADIUS)プロトコルに現在配布している拡大について説明します、ユーザセッションへのダイナミックな変化を許容して、ネットワークアクセス・サーバー製品によって実装されるように。 これはユーザから切断して、ユーザセッションに適切な承認を変えるサポートを含んでいます。
Chiba, et al. Informational [Page 1] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
千葉、他 半径2003年7月への情報[1ページ]のRFC3576のダイナミックな承認拡張子
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Applicability. . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . 5
1.3. Terminology. . . . . . . . . . . . . . . . . . . . . . . 5
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Disconnect Messages (DM) . . . . . . . . . . . . . . . . 5
2.2. Change-of-Authorization Messages (CoA) . . . . . . . . . 6
2.3. Packet Format. . . . . . . . . . . . . . . . . . . . . . 7
3. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Error-Cause. . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Table of Attributes. . . . . . . . . . . . . . . . . . . 16
4. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 20
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 21
5.1. Authorization Issues . . . . . . . . . . . . . . . . . . 21
5.2. Impersonation. . . . . . . . . . . . . . . . . . . . . . 22
5.3. IPsec Usage Guidelines . . . . . . . . . . . . . . . . . 22
5.4. Replay Protection. . . . . . . . . . . . . . . . . . . . 25
6. Example Traces . . . . . . . . . . . . . . . . . . . . . . . . 26
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.1. Normative References . . . . . . . . . . . . . . . . . . 26
7.2. Informative References . . . . . . . . . . . . . . . . . 27
8. Intellectual Property Statement. . . . . . . . . . . . . . . . 28
9. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 28
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 30
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 適用性。 . . . . . . . . . . . . . . . . . . . . . 3 1.2. 要件言語. . . . . . . . . . . . . . . . . 5 1.3 用語。 . . . . . . . . . . . . . . . . . . . . . . 5 2. 概要. . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1。 メッセージ(DM)が.52.2であると切断してください。 承認の変化メッセージ(CoA).62.3。 パケット・フォーマット。 . . . . . . . . . . . . . . . . . . . . . 7 3. 属性. . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1。 誤り原因。 . . . . . . . . . . . . . . . . . . . . . . 13 3.2. 属性のテーブル。 . . . . . . . . . . . . . . . . . . 16 4. IANA問題。 . . . . . . . . . . . . . . . . . . . . . 20 5. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 21 5.1. 承認問題. . . . . . . . . . . . . . . . . . 21 5.2。 ものまね。 . . . . . . . . . . . . . . . . . . . . . 22 5.3. IPsec用法ガイドライン. . . . . . . . . . . . . . . . . 22 5.4。 保護を再演してください。 . . . . . . . . . . . . . . . . . . . 25 6. 例は.267をたどります。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.1。 引用規格. . . . . . . . . . . . . . . . . . 26 7.2。 有益な参照. . . . . . . . . . . . . . . . . 27 8。 知的所有権声明。 . . . . . . . . . . . . . . . 28 9. 承認。 . . . . . . . . . . . . . . . . . . . . . . 28 10. 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 29 11。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 30
Chiba, et al. Informational [Page 2] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
千葉、他 半径2003年7月への情報[2ページ]のRFC3576のダイナミックな承認拡張子
1. Introduction
1. 序論
The RADIUS protocol, defined in [RFC2865], does not support unsolicited messages sent from the RADIUS server to the Network Access Server (NAS).
[RFC2865]で定義されたRADIUSプロトコルはRADIUSサーバからNetwork Access Server(NAS)に送られたお節介なメッセージをサポートしません。
However, there are many instances in which it is desirable for changes to be made to session characteristics, without requiring the NAS to initiate the exchange. For example, it may be desirable for administrators to be able to terminate a user session in progress. Alternatively, if the user changes authorization level, this may require that authorization attributes be added/deleted from a user session.
しかしながら、変更をセッションの特性にするのが望ましい多くのインスタンスがあります、NASが交換を起こす必要でない。 例えば、管理者が進行中のユーザセッションを終えることができるのは、望ましいかもしれません。 あるいはまた、ユーザが承認レベルを変えるなら、これは、承認属性がユーザセッションから加えられるか、または削除されるのを必要とするかもしれません。
To overcome these limitations, several vendors have implemented additional RADIUS commands in order to be able to support unsolicited messages sent from the RADIUS server to the NAS. These extended commands provide support for Disconnect and Change-of-Authorization (CoA) messages. Disconnect messages cause a user session to be terminated immediately, whereas CoA messages modify session authorization attributes such as data filters.
これらの限界を克服するために、いくつかのベンダーが、追加RADIUSがコマンドであると実装しました。できるために、お節介なメッセージをサポートするのはRADIUSサーバからNASまで発信しました。 これらの拡張コマンドはDisconnectと承認のChange(CoA)メッセージのサポートを提供します。 すぐに、分離メッセージでユーザセッションを終えますが、CoAメッセージはデータフィルタなどのセッション承認属性を変更します。
1.1. Applicability
1.1. 適用性
This protocol is being recommended for publication as an Informational RFC rather than as a standards-track RFC because of problems that cannot be fixed without creating incompatibilities with deployed implementations. This includes security vulnerabilities, as well as semantic ambiguities resulting from the design of the Change-of-Authorization (CoA) commands. While fixes are recommended, they cannot be made mandatory since this would be incompatible with existing implementations.
このプロトコルは配布している実装で非互換性を作成しないで修正できない問題で公表のために標準化過程RFCとしてというよりむしろInformational RFCとして推薦されています。 これはセキュリティの脆弱性、および承認のChange(CoA)コマンドのデザインから生じる意味的あいまい性を含んでいます。 これは既存の実装と非互換でしょう、フィックスがお勧めである間、したがって、それらを義務的にすることができません。
Existing implementations of this protocol do not support authorization checks, so that an ISP sharing a NAS with another ISP could disconnect or change authorizations for another ISP's users. In order to remedy this problem, a "Reverse Path Forwarding" check is recommended. See Section 5.1. for details.
このプロトコルの既存の実装は許可検査をサポートしません、別のISPとNASを共有するISPが別のISPのユーザのために承認を切断するか、または変えることができるように。 この問題を改善するために、「逆の経路推進」チェックはお勧めです。 詳細に関してセクション5.1を見てください。
Existing implementations utilize per-packet authentication and integrity protection algorithms with known weaknesses [MD5Attack]. To provide stronger per-packet authentication and integrity protection, the use of IPsec is recommended. See Section 5.3. for details.
既存の実装は知られている弱点[MD5Attack]がある1パケットあたりの認証と保全保護アルゴリズムを利用します。 1パケットあたりの、より強い認証と保全保護、IPsecの使用を提供するのはお勧めです。 詳細に関してセクション5.3を見てください。
Chiba, et al. Informational [Page 3] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
千葉、他 半径2003年7月への情報[3ページ]のRFC3576のダイナミックな承認拡張子
Existing implementations lack replay protection. In order to support replay detection, it is recommended that the Event-Timestamp Attribute be added to all messages in situations where IPsec replay protection is not employed. Implementations should be configurable to silently discard messages lacking the Event-Timestamp Attribute. See Section 5.4. for details.
既存の実装不足は保護を再演します。 再生検出をサポートするために、Event-タイムスタンプAttributeがIPsec反復操作による保護が採用していない状況におけるすべてのメッセージに追加されるのは、お勧めです。 実装は静かにEvent-タイムスタンプAttributeを欠いているメッセージを捨てるのにおいて構成可能であるべきです。 詳細に関してセクション5.4を見てください。
The approach taken with CoA commands in existing implementations results in a semantic ambiguity. Existing implementations of the CoA-Request identify the affected session, as well as supply the authorization changes. Since RADIUS Attributes included within existing implementations of the CoA-Request can be used for session identification or authorization change, it may not be clear which function a given attribute is serving.
既存の実装におけるCoAコマンドで取られたアプローチは意味的あいまい性をもたらします。 CoA-要求の既存の実装は、影響を受けるセッションを特定して、承認変化を供給します。 セッション識別か承認変化にCoA-要求の既存の実装の中に含まれていたRADIUS Attributesは使用できるので、与えられた属性がどの機能を果たしているかは、明確でないかもしれません。
The problem does not exist within [Diameter], in which authorization change is requested by a command using Attribute Value Pairs (AVPs) solely for identification, resulting in initiation of a standard Request/Response sequence where authorization changes are supplied. As a result, in no command can Diameter AVPs have multiple potential meanings.
問題は[直径]以内に存在していません、承認変化が供給される標準のRequest/応答系列の開始をもたらして。そこでは、承認変化が、唯一識別に、Attribute Valueペア(AVPs)を使用しながら、コマンドで要求されています。 その結果、どんなコマンドでも、Diameter AVPsは複数の潜在的意味を持つことができません。
Due to differences in handling change-of-authorization requests in RADIUS and Diameter, it may be difficult or impossible for a Diameter/RADIUS gateway to successfully translate existing implementations of this specification to equivalent messages in Diameter. For example, a Diameter command changing any attribute used for identification within existing CoA-Request implementations cannot be translated, since such an authorization change is impossible to carry out in existing implementations. Similarly, translation between existing implementations of Disconnect-Request or CoA-Request messages and Diameter is tricky because a Disconnect- Request or CoA-Request message will need to be translated to multiple Diameter commands.
RADIUSとDiameterでの取り扱い承認の変化要求の違いのために、Diameter/RADIUSゲートウェイが首尾よくこの仕様の既存の実装をDiameterの同等なメッセージに翻訳するのは、難しいか、または不可能であるかもしれません。 例えば、識別に既存のCoA-要求実装の中で使用されたどんな属性も変えるDiameterコマンドは翻訳できません、そのような承認変化は存在する際に実装を行うのが不可能であるので。 同様に、Disconnect要求かCoA-要求メッセージが、複数のDiameterコマンドに翻訳される必要があるので、Disconnect-要求かCoA-要求メッセージとDiameterの既存の実装の間の翻訳は扱いにくいです。
To simplify translation between RADIUS and Diameter, a Service-Type Attribute with value "Authorize Only" can (optionally) be included within a Disconnect-Request or CoA-Request. Such a Request contains only identification attributes. A NAS supporting the "Authorize Only" Service-Type within a Disconnect-Request or CoA-Request responds with a NAK containing a Service-Type Attribute with value "Authorize Only" and an Error-Cause Attribute with value "Request Initiated". The NAS will then send an Access-Request containing a Service-Type Attribute with a value of "Authorize Only". This usage sequence is akin to what occurs in Diameter and so is more easily translated by a Diameter/RADIUS gateway.
値でRADIUSとDiameter、Service-タイプAttributeの間の翻訳を簡素化する、「(任意に)含まれていて、Disconnect-要求かCoA-要求の中で」 缶だけを認可してください。 そのようなRequestは識別属性だけを含んでいます。 NASサポート、「認可、NAKがService-タイプAttributeを含んでいて」 Disconnect-要求かCoA-要求の中のService-タイプだけが値で応じる、「「要求は開始した」値で」 Error-原因Attributeだけを認可してください。 次に、NASがAccess-要求にa値があるService-タイプAttributeを含ませる、「認可、単に」 この用法系列は、Diameterに起こることと同系であるので、Diameter/RADIUSゲートウェイによって、より容易に翻訳されます。
Chiba, et al. Informational [Page 4] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
千葉、他 半径2003年7月への情報[4ページ]のRFC3576のダイナミックな承認拡張子
1.2. Requirements Language
1.2. 要件言語
In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本書では、いくつかの単語が、仕様の要件を意味するのに使用されます。 これらの単語はしばしば大文字で書かれます。 キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
1.3. Terminology
1.3. 用語
This document frequently uses the following terms:
このドキュメントは頻繁に次の用語を使用します:
Network Access Server (NAS): The device providing access to the
network.
アクセス・サーバー(NAS)をネットワークでつないでください: ネットワークへのアクセスを提供するデバイス。
service: The NAS provides a service to the user,
such as IEEE 802 or PPP.
サービス: NASはユーザに対するIEEE802かPPPなどのサービスを提供します。
session: Each service provided by the NAS to a
user constitutes a session, with the
beginning of the session defined as the
point where service is first provided
and the end of the session defined as
the point where service is ended. A
user may have multiple sessions in
parallel or series if the NAS supports
that.
セッション: NASによってユーザに提供された各サービスはセッションを構成します、セッションの始まりがサービスが最初に提供されるポイントと定義されて、セッションの終わりがサービスが終わるポイントと定義されている状態で。 ユーザには、NASがそれをサポートするなら、平行な複数のセッションかシリーズがあるかもしれません。
silently discard: This means the implementation discards
the packet without further processing.
The implementation SHOULD provide the
capability of logging the error,
including the contents of the silently
discarded packet, and SHOULD record the
event in a statistics counter.
静かに捨ててください: これは、実装がさらなる処理なしでパケットを捨てることを意味します。 実装SHOULDは静かに捨てられたパケットのコンテンツを含む誤りを登録する能力を提供します、そして、SHOULDは統計カウンタに出来事を記録に残します。
2. Overview
2. 概要
This section describes the most commonly implemented features of Disconnect and Change-of-Authorization messages.
このセクションはDisconnectと承認のChangeメッセージの最も一般的に実装している特徴について説明します。
2.1. Disconnect Messages (DM)
2.1. メッセージから切断してください。(DM)
A Disconnect-Request packet is sent by the RADIUS server in order to terminate a user session on a NAS and discard all associated session context. The Disconnect-Request packet is sent to UDP port 3799, and identifies the NAS as well as the user session to be terminated by inclusion of the identification attributes described in Section 3.
RADIUSサーバは、NASのユーザセッションを終えて、すべての合同会議文脈を捨てるためにDisconnect-リクエスト・パケットを送ります。 Disconnect-リクエスト・パケットは、セクション3で説明された識別属性の包含で終えられるためにUDPポート3799に送られて、ユーザセッションと同様にNASを特定します。
Chiba, et al. Informational [Page 5] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
千葉、他 半径2003年7月への情報[5ページ]のRFC3576のダイナミックな承認拡張子
+----------+ Disconnect-Request +----------+ | | <-------------------- | | | NAS | | RADIUS | | | Disconnect-Response | Server | | | ---------------------> | | +----------+ +----------+
+----------+ 分離要求+----------+ | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| NAS| | 半径| | | 分離応答| サーバ| | | --------------------->|、| +----------+ +----------+
The NAS responds to a Disconnect-Request packet sent by a RADIUS server with a Disconnect-ACK if all associated session context is discarded and the user session is no longer connected, or a Disconnect-NAK, if the NAS was unable to disconnect the session and discard all associated session context. A NAS MUST respond to a Disconnect-Request including a Service-Type Attribute with value "Authorize Only" with a Disconnect-NAK; a Disconnect-ACK MUST NOT be sent. A NAS MUST respond to a Disconnect-Request including a Service-Type Attribute with an unsupported value with a Disconnect- NAK; an Error-Cause Attribute with value "Unsupported Service" MAY be included. A Disconnect-ACK MAY contain the Attribute Acct-Terminate-Cause (49) [RFC2866] with the value set to 6 for Admin-Reset.
NASはすべての合同会議文脈が捨てられて、ユーザセッションがもう接続されないならDisconnect-ACKと共にRADIUSサーバによって送られたDisconnect-リクエスト・パケット、またはDisconnect-NAKに応じます、NASがセッションから切断して、すべての合同会議文脈を捨てることができなかったなら。 値があるService-タイプAttributeを含んでいて、A NAS MUSTがDisconnect-要求に応じる、「認可、唯一、」 Disconnect-NAKと共に。 Disconnect-ACKを送ってはいけません。 Disconnect- NAKと共にサポートされない値があるService-タイプAttributeを含んでいて、NAS MUSTはDisconnect-要求に応じます。 値があるError-原因Attribute「サポートされないサービス」が含まれるかもしれません。 Disconnect-ACKは選択値群でAttribute Acctが原因を終えている(49)[RFC2866]をAdmin-リセットのための6に含むかもしれません。
2.2. Change-of-Authorization Messages (CoA)
2.2. 承認の変化メッセージ(CoA)
CoA-Request packets contain information for dynamically changing session authorizations. This is typically used to change data filters. The data filters can be of either the ingress or egress kind, and are sent in addition to the identification attributes as described in section 3. The port used, and packet format (described in Section 2.3.), are the same as that for Disconnect-Request Messages.
CoA-リクエスト・パケットはダイナミックにセッション承認を変えるための情報を含んでいます。 これは、データフィルタを変えるのに通常使用されます。 データフィルタはイングレスか出口種類があることができて、セクション3で説明されるように識別属性に加えて送ります。 使用されるポート、およびパケット・フォーマット(セクション2.3では、説明される)はDisconnect-要求Messagesのためのそれと同じです。
The following attribute MAY be sent in a CoA-Request:
CoA-要求で以下の属性を送るかもしれません:
Filter-ID (11) - Indicates the name of a data filter list to be
applied for the session that the identification
attributes map to.
フィルタID(11)--識別属性が写像するセッションのために適用されるべきデータフィルタリストの名前を示します。
+----------+ CoA-Request +----------+ | | <-------------------- | | | NAS | | RADIUS | | | CoA-Response | Server | | | ---------------------> | | +----------+ +----------+
+----------+ CoA-要求+----------+ | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| NAS| | 半径| | | CoA-応答| サーバ| | | --------------------->|、| +----------+ +----------+
The NAS responds to a CoA-Request sent by a RADIUS server with a CoA-ACK if the NAS is able to successfully change the authorizations for the user session, or a CoA-NAK if the Request is unsuccessful. A NAS MUST respond to a CoA-Request including a Service-Type Attribute
Requestが失敗しているならNASがユーザセッション、またはCoA-NAKのために首尾よく承認を変えることができるなら、NASはCoA-ACKと共にRADIUSサーバによって送られたCoA-要求に応じます。 Service-タイプAttributeを含んでいて、NAS MUSTはCoA-要求に応じます。
Chiba, et al. Informational [Page 6] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
千葉、他 半径2003年7月への情報[6ページ]のRFC3576のダイナミックな承認拡張子
with value "Authorize Only" with a CoA-NAK; a CoA-ACK MUST NOT be sent. A NAS MUST respond to a CoA-Request including a Service-Type Attribute with an unsupported value with a CoA-NAK; an Error-Cause Attribute with value "Unsupported Service" MAY be included.
値、「認可、唯一、」 CoA-NAKと共に。 CoA-ACKを送ってはいけません。 CoA-NAKと共にサポートされない値があるService-タイプAttributeを含んでいて、NAS MUSTはCoA-要求に応じます。 値があるError-原因Attribute「サポートされないサービス」が含まれるかもしれません。
2.3. Packet Format
2.3. パケット・フォーマット
For either Disconnect-Request or CoA-Request messages UDP port 3799 is used as the destination port. For responses, the source and destination ports are reversed. Exactly one RADIUS packet is encapsulated in the UDP Data field.
UDPが移植するDisconnect-要求かCoA-要求メッセージのどちらかに関しては、3799は仕向港として使用されています。 応答において、ソースと仕向港は逆にされます。 ちょうど1つのRADIUSパケットがUDP Data分野でカプセルに入れられます。
A summary of the data format is shown below. The fields are transmitted from left to right.
データの形式の概要は以下に示されます。 野原は左から右まで伝えられます。
The packet format consists of the fields: Code, Identifier, Length, Authenticator, and Attributes in Type:Length:Value (TLV) format. All fields hold the same meaning as those described in RADIUS [RFC2865]. The Authenticator field MUST be calculated in the same way as is specified for an Accounting-Request in [RFC2866].
パケット・フォーマットは分野から成ります: Typeのコード、Identifier、Length、Authenticator、およびAttributes: 長さ: (TLV)形式を評価してください。 ものがRADIUS[RFC2865]で説明したようにすべての分野が意味しているのに同じくらい保ちます。 [RFC2866]でのAccounting-要求に指定されるのと同じようにAuthenticator分野について計算しなければなりません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 固有識別文字| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 属性… +-+-+-+-+-+-+-+-+-+-+-+-+-
Code
コード
The Code field is one octet, and identifies the type of RADIUS
packet. Packets received with an invalid Code field MUST be
silently discarded. RADIUS codes (decimal) for this extension are
assigned as follows:
Code分野は、1つの八重奏であり、RADIUSパケットのタイプを特定します。 静かに無効のCode分野で受け取られたパケットを捨てなければなりません。 この拡大のためのRADIUSコード(小数)は以下の通り割り当てられます:
40 - Disconnect-Request [RFC2882]
41 - Disconnect-ACK [RFC2882]
42 - Disconnect-NAK [RFC2882]
43 - CoA-Request [RFC2882]
44 - CoA-ACK [RFC2882]
45 - CoA-NAK [RFC2882]
40--分離要求[RFC2882]41--分離-ACK[RFC2882]42--分離-NAK[RFC2882]43--CoA-要求[RFC2882]44--CoA-ACK[RFC2882]45--CoA-NAK[RFC2882]
Chiba, et al. Informational [Page 7] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
千葉、他 半径2003年7月への情報[7ページ]のRFC3576のダイナミックな承認拡張子
Identifier
識別子
The Identifier field is one octet, and aids in matching requests
and replies. The RADIUS client can detect a duplicate request if
it has the same server source IP address and source UDP port and
Identifier within a short span of time.
Identifier分野は、1つの八重奏と、合っている要求と回答で援助です。 それが短い期間の中にソースIPのアドレスとソースUDPが移植する同じサーバとIdentifierを持っているなら、RADIUSクライアントは写し要求を検出できます。
Unlike RADIUS as defined in [RFC2865], the responsibility for
retransmission of Disconnect-Request and CoA-Request messages lies
with the RADIUS server. If after sending these messages, the
RADIUS server does not receive a response, it will retransmit.
[RFC2865]で定義されるRADIUSと異なって、Disconnect-要求とCoA-要求メッセージの「再-トランスミッション」への責任がRADIUSサーバにあります。これらのメッセージを送った後にRADIUSサーバが応答を受けないと、それは再送されるでしょう。
The Identifier field MUST be changed whenever the content of the
Attributes field changes, or whenever a valid reply has been
received for a previous request. For retransmissions where the
contents are identical, the Identifier MUST remain unchanged.
Attributes分野の内容が変化するときはいつも、Identifier分野を変えなければならない、a有効であるときはいつも、さもなければ、前の要求のために回答を受け取りました。 内容が同じである「再-トランスミッション」に関しては、Identifierは変わりがあってはいけません。
If the RADIUS server is retransmitting a Disconnect-Request or
CoA-Request to the same client as before, and the Attributes have
not changed, the same Request Authenticator, Identifier and source
port MUST be used. If any Attributes have changed, a new
Authenticator and Identifier MUST be used.
RADIUSサーバが従来と同様Disconnect-要求かCoA-要求を同じクライアントに再送していて、Attributesが変化していないなら、同じRequest Authenticator、Identifier、およびソースポートを使用しなければなりません。 どれかAttributesが変化したなら、新しいAuthenticatorとIdentifierを使用しなければなりません。
Note that if the Event-Timestamp Attribute is included, it will be
updated when the packet is retransmitted, changing the content of
the Attributes field and requiring a new Identifier and Request
Authenticator.
パケットを再送するとき、Event-タイムスタンプAttributeが含んでいると、それをアップデートすることに注意してください、Attributes分野の内容を変えて、新しいIdentifierとRequest Authenticatorを必要として。
If the Request to a primary proxy fails, a secondary proxy must be
queried, if available. Issues relating to failover algorithms are
described in [AAATransport]. Since this represents a new request,
a new Request Authenticator and Identifier MUST be used. However,
where the RADIUS server is sending directly to the client,
failover typically does not make sense, since Disconnect or CoA
messages need to be delivered to the NAS where the session
resides.
プライマリプロキシへのRequestが失敗するなら、セカンダリプロキシは、質問されていて、手があいているに違いありません。 フェイルオーバーアルゴリズムに関連する問題が[AAATransport]で説明されます。 これが新しい要求を表すので、新しいRequest AuthenticatorとIdentifierを使用しなければなりません。 しかしながら、RADIUSサーバがクライアントに直送しているところでは、フェイルオーバーは通常理解できません、DisconnectかCoAメッセージが、セッションがあるNASに提供される必要があるので。
Length
長さ
The Length field is two octets. It indicates the length of the
packet including the Code, Identifier, Length, Authenticator and
Attribute fields. Octets outside the range of the Length field
MUST be treated as padding and ignored on reception. If the
packet is shorter than the Length field indicates, it MUST be
silently discarded. The minimum length is 20 and the maximum
length is 4096.
Length分野は2つの八重奏です。 それはCode、Identifier、Length、Authenticator、およびAttribute分野を含むパケットの長さを示します。 Length分野の範囲の外での八重奏を詰め物として扱われて、レセプションで無視しなければなりません。 パケットがLength分野が示すより脆いなら、静かにそれを捨てなければなりません。 最小の長さは20です、そして、最大の長さは4096です。
Chiba, et al. Informational [Page 8] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
千葉、他 半径2003年7月への情報[8ページ]のRFC3576のダイナミックな承認拡張子
Authenticator
固有識別文字
The Authenticator field is sixteen (16) octets. The most
significant octet is transmitted first. This value is used to
authenticate the messages between the RADIUS server and client.
Authenticator分野は16(16)八重奏です。 最も重要な八重奏は最初に、伝えられます。 この値は、RADIUSサーバとクライアントの間のメッセージを認証するのに使用されます。
Request Authenticator
固有識別文字を要求してください。
In Request packets, the Authenticator value is a 16 octet MD5
[RFC1321] checksum, called the Request Authenticator. The Request
Authenticator is calculated the same way as for an Accounting-
Request, specified in [RFC2866].
Request Authenticatorは、Authenticator値がRequestパケットでは、16八重奏MD5[RFC1321]チェックサムであると呼びました。 Request Authenticatorは[RFC2866]で指定されたAccounting要求のように同じように計算されます。
Note that the Request Authenticator of a Disconnect or CoA-Request
cannot be done the same way as the Request Authenticator of a
RADIUS Access-Request, because there is no User-Password Attribute
in a Disconnect-Request or CoA-Request.
RADIUS Access-要求のRequest Authenticatorとして同じようにDisconnectかCoA-要求のRequest Authenticatorができないことに注意してください、Disconnect-要求かCoA-要求にはUser-パスワードAttributeが全くないので。
Response Authenticator
応答固有識別文字
The Authenticator field in a Response packet (e.g. Disconnect-ACK,
Disconnect-NAK, CoA-ACK, or CoA-NAK) is called the Response
Authenticator, and contains a one-way MD5 hash calculated over a
stream of octets consisting of the Code, Identifier, Length, the
Request Authenticator field from the packet being replied to, and
the response Attributes if any, followed by the shared secret.
The resulting 16 octet MD5 hash value is stored in the
Authenticator field of the Response packet.
Responseパケット(例えば、Disconnect-ACK、Disconnect-NAK、CoA-ACK、またはCoA-NAK)のAuthenticator分野は、Response Authenticatorと呼ばれて、Codeから成る八重奏のストリームに関して計算された一方向MD5ハッシュを含んでいます、とIdentifier、Length、答えられるパケットからのRequest Authenticator分野、およびもしあれば応答Attributesは共有秘密キーで続きました。 結果として起こる16八重奏MD5ハッシュ値はResponseパケットのAuthenticator分野に保存されます。
Administrative note: As noted in [RFC2865] Section 3, the secret (password shared between the client and the RADIUS server) SHOULD be at least as large and unguessable as a well-chosen password. RADIUS clients MUST use the source IP address of the RADIUS UDP packet to decide which shared secret to use, so that requests can be proxied.
管理注意: [RFC2865]セクション3に述べられるように、秘密(パスワードはクライアントとRADIUSサーバを平等に割り当てた)のSHOULDは少なくとも同じくらい大きく、適切なパスワードとして「蹄-可能」します。 RADIUSクライアントはどの共有秘密キーを使用したらよいかを決めるのにRADIUS UDPパケットのソースIPアドレスを使用しなければなりません、要求をproxiedされることができるように。
Attributes
属性
In Disconnect and CoA-Request messages, all Attributes are treated
as mandatory. A NAS MUST respond to a CoA-Request containing one
or more unsupported Attributes or Attribute values with a CoA-NAK;
a Disconnect-Request containing one or more unsupported Attributes
or Attribute values MUST be answered with a Disconnect-NAK. State
changes resulting from a CoA-Request MUST be atomic: if the
Request is successful, a CoA-ACK is sent, and all requested
authorization changes MUST be made. If the CoA-Request is
unsuccessful, a CoA-NAK MUST be sent, and the requested
DisconnectとCoA-要求メッセージでは、すべてのAttributesが義務的であるとして扱われます。 CoA-NAKがある1つ以上のサポートされないAttributesかAttribute値を含んでいて、NAS MUSTはCoA-要求に応じます。 Disconnect-NAKと共に1つ以上のサポートされないAttributesかAttribute値を含むDisconnect-要求に答えなければなりません。 CoA-要求から生じる州の変化は原子であるに違いありません: Requestがうまくいくなら、CoA-ACKを送りました、そして、すべてが承認変更を行わなければならないよう要求しました。 CoA-要求は失敗していて、CoA-NAKを送らなければならないということであるかどうか、そして、要求
Chiba, et al. Informational [Page 9] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
千葉、他 半径2003年7月への情報[9ページ]のRFC3576のダイナミックな承認拡張子
authorization changes MUST NOT be made. Similarly, a state change
MUST NOT occur as a result of an unsuccessful Disconnect-Request;
here a Disconnect-NAK MUST be sent.
承認変更を行ってはいけません。 同様に、州の変化は失敗のDisconnect-要求の結果、起こってはいけません。 ここに、Disconnect-NAKを送らなければなりません。
Since within this specification attributes may be used for
identification, authorization or other purposes, even if a NAS
implements an attribute for use with RADIUS authentication and
accounting, it may not support inclusion of that attribute within
Disconnect-Request or CoA-Request messages, given the difference
in attribute semantics. This is true even for attributes
specified within [RFC2865], [RFC2868], [RFC2869] or [RFC3162] as
allowable within Access-Accept messages.
属性が識別、承認または他の目的にこの仕様の中で使用されるかもしれないので、NASが使用のためにRADIUS認証と会計で属性を実装しても、Disconnect-要求かCoA-要求メッセージの中でその属性の包含をサポートしないかもしれません、属性意味論の違いを考えて。 [RFC2865]、[RFC2868][RFC2869]の中で指定された属性にさえ、これが本当であるか、または中で許容できるとしての[RFC3162]はメッセージをAccess受け入れます。
As a result, attributes beyond those specified in Section 3.2.
SHOULD NOT be included within Disconnect or CoA messages since
this could produce unpredictable results.
その結果、それらを超えた属性はセクション3.2で指定しました。 SHOULD NOT、これが予測できない結果を生むかもしれないので、DisconnectかCoAメッセージの中で含められてください。
When using a forwarding proxy, the proxy must be able to alter the
packet as it passes through in each direction. When the proxy
forwards a Disconnect or CoA-Request, it MAY add a Proxy-State
Attribute, and when the proxy forwards a response, it MUST remove
its Proxy-State Attribute if it added one. Proxy-State is always
added or removed after any other Proxy-States, but no other
assumptions regarding its location within the list of Attributes
can be made. Since Disconnect and CoA responses are authenticated
on the entire packet contents, the stripping of the Proxy-State
Attribute invalidates the integrity check - so the proxy needs to
recompute it. A forwarding proxy MUST NOT modify existing Proxy-
State, State, or Class Attributes present in the packet.
推進プロキシを使用するとき、各方向に通り抜けるとき、プロキシはパケットを変更できなければなりません。 プロキシがDisconnectかCoA-要求を転送するとき、Proxy-州のAttributeを加えるかもしれません、そして、プロキシが応答を進めるとき、1つを加えたなら、Proxy-州のAttributeを取り外さなければなりません。 いかなる他のProxy-州もしますが、Attributesのリストの中の位置に関する他のどんな仮定もしないことができた後に、プロキシ状態をいつも加えるか、または取り除きます。 DisconnectとCoA応答が全体のパケットコンテンツで認証されるので、Proxy-州のAttributeのストリップは保全チェックを無効にします--したがって、プロキシはrecomputeにそれを必要とします。 推進プロキシはパケットの現在の既存のProxy状態、州、またはClass Attributesを変更してはいけません。
If there are any Proxy-State Attributes in a Disconnect-Request or
CoA-Request received from the server, the forwarding proxy MUST
include those Proxy-State Attributes in its response to the
server. The forwarding proxy MAY include the Proxy-State
Attributes in the Disconnect-Request or CoA-Request when it
forwards the request, or it MAY omit them in the forwarded
request. If the forwarding proxy omits the Proxy-State Attributes
in the request, it MUST attach them to the response before sending
it to the server.
サーバから受け取られたDisconnect-要求かCoA-要求に何かProxy-州のAttributesがあれば、推進プロキシはサーバへの応答でそれらのProxy-州のAttributesを入れなければなりません。要求を転送するとき、推進プロキシがDisconnect-要求かCoA-要求でProxy-州のAttributesを入れるかもしれませんか、またはそれは転送された要求で彼らを省略するかもしれません。 推進プロキシが要求でProxy-州のAttributesを省略するなら、それをサーバに送る前に、それは彼らを応答に付けなければなりません。
Chiba, et al. Informational [Page 10] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
千葉、他 半径2003年7月への情報[10ページ]のRFC3576のダイナミックな承認拡張子
3. Attributes
3. 属性
In Disconnect-Request and CoA-Request packets, certain attributes are used to uniquely identify the NAS as well as a user session on the NAS. All NAS identification attributes included in a Request message MUST match in order for a Disconnect-Request or CoA-Request to be successful; otherwise a Disconnect-NAK or CoA-NAK SHOULD be sent. For session identification attributes, the User-Name and Acct- Session-Id Attributes, if included, MUST match in order for a Disconnect-Request or CoA-Request to be successful; other session identification attributes SHOULD match. Where a mismatch of session identification attributes is detected, a Disconnect-NAK or CoA-NAK SHOULD be sent. The ability to use NAS or session identification attributes to map to unique/multiple sessions is beyond the scope of this document. Identification attributes include NAS and session identification attributes, as described below.
Disconnect-要求とCoA-リクエスト・パケットでは、ある属性は、また、NASがNASのユーザセッションであると唯一認識するのに使用されます。 Requestメッセージに含まれていたすべてのNAS識別属性がうまくいくDisconnect-要求かCoA-要求に関する命令で合わなければなりません。 そうでなければ、Disconnect-NAKかCoA-NAK SHOULD、送ってください。 セッション識別属性のために、含まれているなら、User-名前とAcctセッションイドAttributesはうまくいくDisconnect-要求かCoA-要求に関する命令で合わなければなりません。 他のセッション識別属性SHOULDは合っています。 セッション識別属性のミスマッチが検出されていてDisconnect-NAKかCoA-NAK SHOULDであるところでは、送ってください。 NASかユニークであるか複数のセッションまで写像するセッション識別属性を使用する能力はこのドキュメントの範囲を超えています。 識別属性は以下で説明されるようにNASとセッション識別属性を含んでいます。
NAS identification attributes
NAS識別属性
Attribute # Reference Description --------- --- --------- ----------- NAS-IP-Address 4 [RFC2865] The IPv4 address of the NAS. NAS-Identifier 32 [RFC2865] String identifying the NAS. NAS-IPv6-Address 95 [RFC3162] The IPv6 address of the NAS.
Attribute # Reference Description --------- --- --------- ----------- NAS-IP-Address 4 [RFC2865] The IPv4 address of the NAS. NAS-Identifier 32 [RFC2865] String identifying the NAS. NAS-IPv6-Address 95 [RFC3162] The IPv6 address of the NAS.
Chiba, et al. Informational [Page 11] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
Chiba, et al. Informational [Page 11] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
Session identification attributes
Session identification attributes
Attribute # Reference Description
--------- --- --------- -----------
User-Name 1 [RFC2865] The name of the user
associated with the session.
NAS-Port 5 [RFC2865] The port on which the
session is terminated.
Framed-IP-Address 8 [RFC2865] The IPv4 address associated
with the session.
Called-Station-Id 30 [RFC2865] The link address to which
the session is connected.
Calling-Station-Id 31 [RFC2865] The link address from which
the session is connected.
Acct-Session-Id 44 [RFC2866] The identifier uniquely
identifying the session
on the NAS.
Acct-Multi-Session-Id 50 [RFC2866] The identifier uniquely
identifying related sessions.
NAS-Port-Type 61 [RFC2865] The type of port used.
NAS-Port-Id 87 [RFC2869] String identifying the port
where the session is.
Originating-Line-Info 94 [NASREQ] Provides information on the
characteristics of the line
from which a session
originated.
Framed-Interface-Id 96 [RFC3162] The IPv6 Interface Identifier
associated with the session;
always sent with
Framed-IPv6-Prefix.
Framed-IPv6-Prefix 97 [RFC3162] The IPv6 prefix associated
with the session, always sent
with Framed-Interface-Id.
Attribute # Reference Description --------- --- --------- ----------- User-Name 1 [RFC2865] The name of the user associated with the session. NAS-Port 5 [RFC2865] The port on which the session is terminated. Framed-IP-Address 8 [RFC2865] The IPv4 address associated with the session. Called-Station-Id 30 [RFC2865] The link address to which the session is connected. Calling-Station-Id 31 [RFC2865] The link address from which the session is connected. Acct-Session-Id 44 [RFC2866] The identifier uniquely identifying the session on the NAS. Acct-Multi-Session-Id 50 [RFC2866] The identifier uniquely identifying related sessions. NAS-Port-Type 61 [RFC2865] The type of port used. NAS-Port-Id 87 [RFC2869] String identifying the port where the session is. Originating-Line-Info 94 [NASREQ] Provides information on the characteristics of the line from which a session originated. Framed-Interface-Id 96 [RFC3162] The IPv6 Interface Identifier associated with the session; always sent with Framed-IPv6-Prefix. Framed-IPv6-Prefix 97 [RFC3162] The IPv6 prefix associated with the session, always sent with Framed-Interface-Id.
To address security concerns described in Section 5.1., the User-Name Attribute SHOULD be present in Disconnect-Request or CoA-Request packets; one or more additional session identification attributes MAY also be present. To address security concerns described in Section 5.2., one or more of the NAS-IP-Address or NAS-IPv6-Address Attributes SHOULD be present in Disconnect-Request or CoA-Request packets; the NAS-Identifier Attribute MAY be present in addition.
To address security concerns described in Section 5.1., the User-Name Attribute SHOULD be present in Disconnect-Request or CoA-Request packets; one or more additional session identification attributes MAY also be present. To address security concerns described in Section 5.2., one or more of the NAS-IP-Address or NAS-IPv6-Address Attributes SHOULD be present in Disconnect-Request or CoA-Request packets; the NAS-Identifier Attribute MAY be present in addition.
If one or more authorization changes specified in a CoA-Request cannot be carried out, or if one or more attributes or attribute- values is unsupported, a CoA-NAK MUST be sent. Similarly, if there are one or more unsupported attributes or attribute values in a Disconnect-Request, a Disconnect-NAK MUST be sent.
If one or more authorization changes specified in a CoA-Request cannot be carried out, or if one or more attributes or attribute- values is unsupported, a CoA-NAK MUST be sent. Similarly, if there are one or more unsupported attributes or attribute values in a Disconnect-Request, a Disconnect-NAK MUST be sent.
Chiba, et al. Informational [Page 12] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
Chiba, et al. Informational [Page 12] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
Where a Service-Type Attribute with value "Authorize Only" is included within a CoA-Request or Disconnect-Request, attributes representing an authorization change MUST NOT be included; only identification attributes are permitted. If attributes other than NAS or session identification attributes are included in such a CoA- Request, implementations MUST send a CoA-NAK; an Error-Cause Attribute with value "Unsupported Attribute" MAY be included. Similarly, if attributes other than NAS or session identification attributes are included in such a Disconnect-Request, implementations MUST send a Disconnect-NAK; an Error-Cause Attribute with value "Unsupported Attribute" MAY be included.
Where a Service-Type Attribute with value "Authorize Only" is included within a CoA-Request or Disconnect-Request, attributes representing an authorization change MUST NOT be included; only identification attributes are permitted. If attributes other than NAS or session identification attributes are included in such a CoA- Request, implementations MUST send a CoA-NAK; an Error-Cause Attribute with value "Unsupported Attribute" MAY be included. Similarly, if attributes other than NAS or session identification attributes are included in such a Disconnect-Request, implementations MUST send a Disconnect-NAK; an Error-Cause Attribute with value "Unsupported Attribute" MAY be included.
3.1. Error-Cause
3.1. Error-Cause
Description
Description
It is possible that the NAS cannot honor Disconnect-Request or
CoA-Request messages for some reason. The Error-Cause Attribute
provides more detail on the cause of the problem. It MAY be
included within Disconnect-ACK, Disconnect-NAK and CoA-NAK
messages.
It is possible that the NAS cannot honor Disconnect-Request or CoA-Request messages for some reason. The Error-Cause Attribute provides more detail on the cause of the problem. It MAY be included within Disconnect-ACK, Disconnect-NAK and CoA-NAK messages.
A summary of the Error-Cause Attribute format is shown below. The
fields are transmitted from left to right.
A summary of the Error-Cause Attribute format is shown below. The fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
Type
101 for Error-Cause
101 for Error-Cause
Length
Length
6
6
Value
Value
The Value field is four octets, containing an integer specifying
the cause of the error. Values 0-199 and 300-399 are reserved.
Values 200-299 represent successful completion, so that these
values may only be sent within Disconnect-ACK or CoA-ACK message
and MUST NOT be sent within a Disconnect-NAK or CoA-NAK. Values
The Value field is four octets, containing an integer specifying the cause of the error. Values 0-199 and 300-399 are reserved. Values 200-299 represent successful completion, so that these values may only be sent within Disconnect-ACK or CoA-ACK message and MUST NOT be sent within a Disconnect-NAK or CoA-NAK. Values
Chiba, et al. Informational [Page 13] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
Chiba, et al. Informational [Page 13] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
400-499 represent fatal errors committed by the RADIUS server, so
that they MAY be sent within CoA-NAK or Disconnect-NAK messages,
and MUST NOT be sent within CoA-ACK or Disconnect-ACK messages.
Values 500-599 represent fatal errors occurring on a NAS or RADIUS
proxy, so that they MAY be sent within CoA-NAK and Disconnect-NAK
messages, and MUST NOT be sent within CoA-ACK or Disconnect-ACK
messages. Error-Cause values SHOULD be logged by the RADIUS
server. Error-Code values (expressed in decimal) include:
400-499 represent fatal errors committed by the RADIUS server, so that they MAY be sent within CoA-NAK or Disconnect-NAK messages, and MUST NOT be sent within CoA-ACK or Disconnect-ACK messages. Values 500-599 represent fatal errors occurring on a NAS or RADIUS proxy, so that they MAY be sent within CoA-NAK and Disconnect-NAK messages, and MUST NOT be sent within CoA-ACK or Disconnect-ACK messages. Error-Cause values SHOULD be logged by the RADIUS server. Error-Code values (expressed in decimal) include:
# Value
--- -----
201 Residual Session Context Removed
202 Invalid EAP Packet (Ignored)
401 Unsupported Attribute
402 Missing Attribute
403 NAS Identification Mismatch
404 Invalid Request
405 Unsupported Service
406 Unsupported Extension
501 Administratively Prohibited
502 Request Not Routable (Proxy)
503 Session Context Not Found
504 Session Context Not Removable
505 Other Proxy Processing Error
506 Resources Unavailable
507 Request Initiated
# Value --- ----- 201 Residual Session Context Removed 202 Invalid EAP Packet (Ignored) 401 Unsupported Attribute 402 Missing Attribute 403 NAS Identification Mismatch 404 Invalid Request 405 Unsupported Service 406 Unsupported Extension 501 Administratively Prohibited 502 Request Not Routable (Proxy) 503 Session Context Not Found 504 Session Context Not Removable 505 Other Proxy Processing Error 506 Resources Unavailable 507 Request Initiated
"Residual Session Context Removed" is sent in response to a Disconnect-Request if the user session is no longer active, but residual session context was found and successfully removed. This value is only sent within a Disconnect-ACK and MUST NOT be sent within a CoA-ACK, Disconnect-NAK or CoA-NAK.
"Residual Session Context Removed" is sent in response to a Disconnect-Request if the user session is no longer active, but residual session context was found and successfully removed. This value is only sent within a Disconnect-ACK and MUST NOT be sent within a CoA-ACK, Disconnect-NAK or CoA-NAK.
"Invalid EAP Packet (Ignored)" is a non-fatal error that MUST NOT be sent by implementations of this specification.
"Invalid EAP Packet (Ignored)" is a non-fatal error that MUST NOT be sent by implementations of this specification.
"Unsupported Attribute" is a fatal error sent if a Request contains an attribute (such as a Vendor-Specific or EAP-Message Attribute) that is not supported.
"Unsupported Attribute" is a fatal error sent if a Request contains an attribute (such as a Vendor-Specific or EAP-Message Attribute) that is not supported.
"Missing Attribute" is a fatal error sent if critical attributes (such as NAS or session identification attributes) are missing from a Request.
"Missing Attribute" is a fatal error sent if critical attributes (such as NAS or session identification attributes) are missing from a Request.
"NAS Identification Mismatch" is a fatal error sent if one or more NAS identification attributes (see Section 3.) do not match the identity of the NAS receiving the Request.
"NAS Identification Mismatch" is a fatal error sent if one or more NAS identification attributes (see Section 3.) do not match the identity of the NAS receiving the Request.
Chiba, et al. Informational [Page 14] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
Chiba, et al. Informational [Page 14] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
"Invalid Request" is a fatal error sent if some other aspect of the Request is invalid, such as if one or more attributes (such as EAP- Message Attribute(s)) are not formatted properly.
"Invalid Request" is a fatal error sent if some other aspect of the Request is invalid, such as if one or more attributes (such as EAP- Message Attribute(s)) are not formatted properly.
"Unsupported Service" is a fatal error sent if a Service-Type Attribute included with the Request is sent with an invalid or unsupported value.
"Unsupported Service" is a fatal error sent if a Service-Type Attribute included with the Request is sent with an invalid or unsupported value.
"Unsupported Extension" is a fatal error sent due to lack of support for an extension such as Disconnect and/or CoA messages. This will typically be sent by a proxy receiving an ICMP port unreachable message after attempting to forward a Request to the NAS.
"Unsupported Extension" is a fatal error sent due to lack of support for an extension such as Disconnect and/or CoA messages. This will typically be sent by a proxy receiving an ICMP port unreachable message after attempting to forward a Request to the NAS.
"Administratively Prohibited" is a fatal error sent if the NAS is configured to prohibit honoring of Request messages for the specified session.
"Administratively Prohibited" is a fatal error sent if the NAS is configured to prohibit honoring of Request messages for the specified session.
"Request Not Routable" is a fatal error which MAY be sent by a RADIUS proxy and MUST NOT be sent by a NAS. It indicates that the RADIUS proxy was unable to determine how to route the Request to the NAS. For example, this can occur if the required entries are not present in the proxy's realm routing table.
"Request Not Routable" is a fatal error which MAY be sent by a RADIUS proxy and MUST NOT be sent by a NAS. It indicates that the RADIUS proxy was unable to determine how to route the Request to the NAS. For example, this can occur if the required entries are not present in the proxy's realm routing table.
"Session Context Not Found" is a fatal error sent if the session context identified in the Request does not exist on the NAS.
"Session Context Not Found" is a fatal error sent if the session context identified in the Request does not exist on the NAS.
"Session Context Not Removable" is a fatal error sent in response to a Disconnect-Request if the NAS was able to locate the session context, but could not remove it for some reason. It MUST NOT be sent within a CoA-ACK, CoA-NAK or Disconnect-ACK, only within a Disconnect-NAK.
"Session Context Not Removable" is a fatal error sent in response to a Disconnect-Request if the NAS was able to locate the session context, but could not remove it for some reason. It MUST NOT be sent within a CoA-ACK, CoA-NAK or Disconnect-ACK, only within a Disconnect-NAK.
"Other Proxy Processing Error" is a fatal error sent in response to a Request that could not be processed by a proxy, for reasons other than routing.
"Other Proxy Processing Error" is a fatal error sent in response to a Request that could not be processed by a proxy, for reasons other than routing.
"Resources Unavailable" is a fatal error sent when a Request could not be honored due to lack of available NAS resources (memory, non- volatile storage, etc.).
"Resources Unavailable" is a fatal error sent when a Request could not be honored due to lack of available NAS resources (memory, non- volatile storage, etc.).
"Request Initiated" is a fatal error sent in response to a Request including a Service-Type Attribute with a value of "Authorize Only". It indicates that the Disconnect-Request or CoA-Request has not been honored, but that a RADIUS Access-Request including a Service-Type Attribute with value "Authorize Only" is being sent to the RADIUS server.
"Request Initiated" is a fatal error sent in response to a Request including a Service-Type Attribute with a value of "Authorize Only". It indicates that the Disconnect-Request or CoA-Request has not been honored, but that a RADIUS Access-Request including a Service-Type Attribute with value "Authorize Only" is being sent to the RADIUS server.
Chiba, et al. Informational [Page 15] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
Chiba, et al. Informational [Page 15] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
3.2. Table of Attributes
3.2. Table of Attributes
The following table provides a guide to which attributes may be found in which packets, and in what quantity.
The following table provides a guide to which attributes may be found in which packets, and in what quantity.
Change-of-Authorization Messages
Change-of-Authorization Messages
Request ACK NAK # Attribute 0-1 0 0 1 User-Name [Note 1] 0-1 0 0 4 NAS-IP-Address [Note 1] 0-1 0 0 5 NAS-Port [Note 1] 0-1 0 0-1 6 Service-Type [Note 6] 0-1 0 0 7 Framed-Protocol [Note 3] 0-1 0 0 8 Framed-IP-Address [Note 1] 0-1 0 0 9 Framed-IP-Netmask [Note 3] 0-1 0 0 10 Framed-Routing [Note 3] 0+ 0 0 11 Filter-ID [Note 3] 0-1 0 0 12 Framed-MTU [Note 3] 0+ 0 0 13 Framed-Compression [Note 3] 0+ 0 0 14 Login-IP-Host [Note 3] 0-1 0 0 15 Login-Service [Note 3] 0-1 0 0 16 Login-TCP-Port [Note 3] 0+ 0 0 18 Reply-Message [Note 2] 0-1 0 0 19 Callback-Number [Note 3] 0-1 0 0 20 Callback-Id [Note 3] 0+ 0 0 22 Framed-Route [Note 3] 0-1 0 0 23 Framed-IPX-Network [Note 3] 0-1 0-1 0-1 24 State [Note 7] 0+ 0 0 25 Class [Note 3] 0+ 0 0 26 Vendor-Specific [Note 3] 0-1 0 0 27 Session-Timeout [Note 3] 0-1 0 0 28 Idle-Timeout [Note 3] 0-1 0 0 29 Termination-Action [Note 3] 0-1 0 0 30 Called-Station-Id [Note 1] 0-1 0 0 31 Calling-Station-Id [Note 1] 0-1 0 0 32 NAS-Identifier [Note 1] 0+ 0+ 0+ 33 Proxy-State 0-1 0 0 34 Login-LAT-Service [Note 3] 0-1 0 0 35 Login-LAT-Node [Note 3] 0-1 0 0 36 Login-LAT-Group [Note 3] 0-1 0 0 37 Framed-AppleTalk-Link [Note 3] 0+ 0 0 38 Framed-AppleTalk-Network [Note 3] 0-1 0 0 39 Framed-AppleTalk-Zone [Note 3] 0-1 0 0 44 Acct-Session-Id [Note 1] 0-1 0 0 50 Acct-Multi-Session-Id [Note 1] 0-1 0-1 0-1 55 Event-Timestamp 0-1 0 0 61 NAS-Port-Type [Note 1] Request ACK NAK # Attribute
Request ACK NAK # Attribute 0-1 0 0 1 User-Name [Note 1] 0-1 0 0 4 NAS-IP-Address [Note 1] 0-1 0 0 5 NAS-Port [Note 1] 0-1 0 0-1 6 Service-Type [Note 6] 0-1 0 0 7 Framed-Protocol [Note 3] 0-1 0 0 8 Framed-IP-Address [Note 1] 0-1 0 0 9 Framed-IP-Netmask [Note 3] 0-1 0 0 10 Framed-Routing [Note 3] 0+ 0 0 11 Filter-ID [Note 3] 0-1 0 0 12 Framed-MTU [Note 3] 0+ 0 0 13 Framed-Compression [Note 3] 0+ 0 0 14 Login-IP-Host [Note 3] 0-1 0 0 15 Login-Service [Note 3] 0-1 0 0 16 Login-TCP-Port [Note 3] 0+ 0 0 18 Reply-Message [Note 2] 0-1 0 0 19 Callback-Number [Note 3] 0-1 0 0 20 Callback-Id [Note 3] 0+ 0 0 22 Framed-Route [Note 3] 0-1 0 0 23 Framed-IPX-Network [Note 3] 0-1 0-1 0-1 24 State [Note 7] 0+ 0 0 25 Class [Note 3] 0+ 0 0 26 Vendor-Specific [Note 3] 0-1 0 0 27 Session-Timeout [Note 3] 0-1 0 0 28 Idle-Timeout [Note 3] 0-1 0 0 29 Termination-Action [Note 3] 0-1 0 0 30 Called-Station-Id [Note 1] 0-1 0 0 31 Calling-Station-Id [Note 1] 0-1 0 0 32 NAS-Identifier [Note 1] 0+ 0+ 0+ 33 Proxy-State 0-1 0 0 34 Login-LAT-Service [Note 3] 0-1 0 0 35 Login-LAT-Node [Note 3] 0-1 0 0 36 Login-LAT-Group [Note 3] 0-1 0 0 37 Framed-AppleTalk-Link [Note 3] 0+ 0 0 38 Framed-AppleTalk-Network [Note 3] 0-1 0 0 39 Framed-AppleTalk-Zone [Note 3] 0-1 0 0 44 Acct-Session-Id [Note 1] 0-1 0 0 50 Acct-Multi-Session-Id [Note 1] 0-1 0-1 0-1 55 Event-Timestamp 0-1 0 0 61 NAS-Port-Type [Note 1] Request ACK NAK # Attribute
Chiba, et al. Informational [Page 16] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
Chiba, et al. Informational [Page 16] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
Request ACK NAK # Attribute 0-1 0 0 62 Port-Limit [Note 3] 0-1 0 0 63 Login-LAT-Port [Note 3] 0+ 0 0 64 Tunnel-Type [Note 5] 0+ 0 0 65 Tunnel-Medium-Type [Note 5] 0+ 0 0 66 Tunnel-Client-Endpoint [Note 5] 0+ 0 0 67 Tunnel-Server-Endpoint [Note 5] 0+ 0 0 69 Tunnel-Password [Note 5] 0-1 0 0 71 ARAP-Features [Note 3] 0-1 0 0 72 ARAP-Zone-Access [Note 3] 0+ 0 0 78 Configuration-Token [Note 3] 0+ 0-1 0 79 EAP-Message [Note 2] 0-1 0-1 0-1 80 Message-Authenticator 0+ 0 0 81 Tunnel-Private-Group-ID [Note 5] 0+ 0 0 82 Tunnel-Assignment-ID [Note 5] 0+ 0 0 83 Tunnel-Preference [Note 5] 0-1 0 0 85 Acct-Interim-Interval [Note 3] 0-1 0 0 87 NAS-Port-Id [Note 1] 0-1 0 0 88 Framed-Pool [Note 3] 0+ 0 0 90 Tunnel-Client-Auth-ID [Note 5] 0+ 0 0 91 Tunnel-Server-Auth-ID [Note 5] 0-1 0 0 94 Originating-Line-Info [Note 1] 0-1 0 0 95 NAS-IPv6-Address [Note 1] 0-1 0 0 96 Framed-Interface-Id [Note 1] 0+ 0 0 97 Framed-IPv6-Prefix [Note 1] 0+ 0 0 98 Login-IPv6-Host [Note 3] 0+ 0 0 99 Framed-IPv6-Route [Note 3] 0-1 0 0 100 Framed-IPv6-Pool [Note 3] 0 0 0+ 101 Error-Cause Request ACK NAK # Attribute
Request ACK NAK # Attribute 0-1 0 0 62 Port-Limit [Note 3] 0-1 0 0 63 Login-LAT-Port [Note 3] 0+ 0 0 64 Tunnel-Type [Note 5] 0+ 0 0 65 Tunnel-Medium-Type [Note 5] 0+ 0 0 66 Tunnel-Client-Endpoint [Note 5] 0+ 0 0 67 Tunnel-Server-Endpoint [Note 5] 0+ 0 0 69 Tunnel-Password [Note 5] 0-1 0 0 71 ARAP-Features [Note 3] 0-1 0 0 72 ARAP-Zone-Access [Note 3] 0+ 0 0 78 Configuration-Token [Note 3] 0+ 0-1 0 79 EAP-Message [Note 2] 0-1 0-1 0-1 80 Message-Authenticator 0+ 0 0 81 Tunnel-Private-Group-ID [Note 5] 0+ 0 0 82 Tunnel-Assignment-ID [Note 5] 0+ 0 0 83 Tunnel-Preference [Note 5] 0-1 0 0 85 Acct-Interim-Interval [Note 3] 0-1 0 0 87 NAS-Port-Id [Note 1] 0-1 0 0 88 Framed-Pool [Note 3] 0+ 0 0 90 Tunnel-Client-Auth-ID [Note 5] 0+ 0 0 91 Tunnel-Server-Auth-ID [Note 5] 0-1 0 0 94 Originating-Line-Info [Note 1] 0-1 0 0 95 NAS-IPv6-Address [Note 1] 0-1 0 0 96 Framed-Interface-Id [Note 1] 0+ 0 0 97 Framed-IPv6-Prefix [Note 1] 0+ 0 0 98 Login-IPv6-Host [Note 3] 0+ 0 0 99 Framed-IPv6-Route [Note 3] 0-1 0 0 100 Framed-IPv6-Pool [Note 3] 0 0 0+ 101 Error-Cause Request ACK NAK # Attribute
Disconnect Messages
Disconnect Messages
Request ACK NAK # Attribute 0-1 0 0 1 User-Name [Note 1] 0-1 0 0 4 NAS-IP-Address [Note 1] 0-1 0 0 5 NAS-Port [Note 1] 0-1 0 0-1 6 Service-Type [Note 6] 0-1 0 0 8 Framed-IP-Address [Note 1] 0+ 0 0 18 Reply-Message [Note 2] 0-1 0-1 0-1 24 State [Note 7] 0+ 0 0 25 Class [Note 4] 0+ 0 0 26 Vendor-Specific 0-1 0 0 30 Called-Station-Id [Note 1] 0-1 0 0 31 Calling-Station-Id [Note 1] 0-1 0 0 32 NAS-Identifier [Note 1] 0+ 0+ 0+ 33 Proxy-State Request ACK NAK # Attribute
Request ACK NAK # Attribute 0-1 0 0 1 User-Name [Note 1] 0-1 0 0 4 NAS-IP-Address [Note 1] 0-1 0 0 5 NAS-Port [Note 1] 0-1 0 0-1 6 Service-Type [Note 6] 0-1 0 0 8 Framed-IP-Address [Note 1] 0+ 0 0 18 Reply-Message [Note 2] 0-1 0-1 0-1 24 State [Note 7] 0+ 0 0 25 Class [Note 4] 0+ 0 0 26 Vendor-Specific 0-1 0 0 30 Called-Station-Id [Note 1] 0-1 0 0 31 Calling-Station-Id [Note 1] 0-1 0 0 32 NAS-Identifier [Note 1] 0+ 0+ 0+ 33 Proxy-State Request ACK NAK # Attribute
Chiba, et al. Informational [Page 17] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
Chiba, et al. Informational [Page 17] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
Request ACK NAK # Attribute 0-1 0 0 44 Acct-Session-Id [Note 1] 0-1 0-1 0 49 Acct-Terminate-Cause 0-1 0 0 50 Acct-Multi-Session-Id [Note 1] 0-1 0-1 0-1 55 Event-Timestamp 0-1 0 0 61 NAS-Port-Type [Note 1] 0+ 0-1 0 79 EAP-Message [Note 2] 0-1 0-1 0-1 80 Message-Authenticator 0-1 0 0 87 NAS-Port-Id [Note 1] 0-1 0 0 94 Originating-Line-Info [Note 1] 0-1 0 0 95 NAS-IPv6-Address [Note 1] 0-1 0 0 96 Framed-Interface-Id [Note 1] 0+ 0 0 97 Framed-IPv6-Prefix [Note 1] 0 0+ 0+ 101 Error-Cause Request ACK NAK # Attribute
Request ACK NAK # Attribute 0-1 0 0 44 Acct-Session-Id [Note 1] 0-1 0-1 0 49 Acct-Terminate-Cause 0-1 0 0 50 Acct-Multi-Session-Id [Note 1] 0-1 0-1 0-1 55 Event-Timestamp 0-1 0 0 61 NAS-Port-Type [Note 1] 0+ 0-1 0 79 EAP-Message [Note 2] 0-1 0-1 0-1 80 Message-Authenticator 0-1 0 0 87 NAS-Port-Id [Note 1] 0-1 0 0 94 Originating-Line-Info [Note 1] 0-1 0 0 95 NAS-IPv6-Address [Note 1] 0-1 0 0 96 Framed-Interface-Id [Note 1] 0+ 0 0 97 Framed-IPv6-Prefix [Note 1] 0 0+ 0+ 101 Error-Cause Request ACK NAK # Attribute
[Note 1] Where NAS or session identification attributes are included in Disconnect-Request or CoA-Request messages, they are used for identification purposes only. These attributes MUST NOT be used for purposes other than identification (e.g. within CoA-Request messages to request authorization changes).
[Note 1] Where NAS or session identification attributes are included in Disconnect-Request or CoA-Request messages, they are used for identification purposes only. These attributes MUST NOT be used for purposes other than identification (e.g. within CoA-Request messages to request authorization changes).
[Note 2] The Reply-Message Attribute is used to present a displayable message to the user. The message is only displayed as a result of a successful Disconnect-Request or CoA-Request (where a Disconnect-ACK or CoA-ACK is subsequently sent). Where EAP is used for authentication, an EAP-Message/Notification-Request Attribute is sent instead, and Disconnect-ACK or CoA-ACK messages contain an EAP- Message/Notification-Response Attribute.
[Note 2] The Reply-Message Attribute is used to present a displayable message to the user. The message is only displayed as a result of a successful Disconnect-Request or CoA-Request (where a Disconnect-ACK or CoA-ACK is subsequently sent). Where EAP is used for authentication, an EAP-Message/Notification-Request Attribute is sent instead, and Disconnect-ACK or CoA-ACK messages contain an EAP- Message/Notification-Response Attribute.
[Note 3] When included within a CoA-Request, these attributes represent an authorization change request. When one of these attributes is omitted from a CoA-Request, the NAS assumes that the attribute value is to remain unchanged. Attributes included in a CoA-Request replace all existing value(s) of the same attribute(s).
[Note 3] When included within a CoA-Request, these attributes represent an authorization change request. When one of these attributes is omitted from a CoA-Request, the NAS assumes that the attribute value is to remain unchanged. Attributes included in a CoA-Request replace all existing value(s) of the same attribute(s).
[Note 4] When included within a successful Disconnect-Request (where a Disconnect-ACK is subsequently sent), the Class Attribute SHOULD be sent unmodified by the client to the accounting server in the Accounting Stop packet. If the Disconnect-Request is unsuccessful, then the Class Attribute is not processed.
[Note 4] When included within a successful Disconnect-Request (where a Disconnect-ACK is subsequently sent), the Class Attribute SHOULD be sent unmodified by the client to the accounting server in the Accounting Stop packet. If the Disconnect-Request is unsuccessful, then the Class Attribute is not processed.
[Note 5] When included within a CoA-Request, these attributes represent an authorization change request. Where tunnel attribute(s) are sent within a successful CoA-Request, all existing tunnel attributes are removed and replaced by the new attribute(s).
[Note 5] When included within a CoA-Request, these attributes represent an authorization change request. Where tunnel attribute(s) are sent within a successful CoA-Request, all existing tunnel attributes are removed and replaced by the new attribute(s).
Chiba, et al. Informational [Page 18] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
Chiba, et al. Informational [Page 18] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
[Note 6] When included within a Disconnect-Request or CoA-Request, a Service-Type Attribute with value "Authorize Only" indicates that the Request only contains NAS and session identification attributes, and that the NAS should attempt reauthorization by sending an Access- Request with a Service-Type Attribute with value "Authorize Only". This enables a usage model akin to that supported in Diameter, thus easing translation between the two protocols. Support for the Service-Type Attribute is optional within CoA-Request and Disconnect-Request messages; where it is not included, the Request message may contain both identification and authorization attributes. A NAS that does not support the Service-Type Attribute with the value "Authorize Only" within a Disconnect-Request MUST respond with a Disconnect-NAK including no Service-Type Attribute; an Error-Cause Attribute with value "Unsupported Service" MAY be included. A NAS that does not support the Service-Type Attribute with the value "Authorize Only" within a CoA-Request MUST respond with a CoA-NAK including no Service-Type Attribute; an Error-Cause Attribute with value "Unsupported Service" MAY be included.
[Note 6] When included within a Disconnect-Request or CoA-Request, a Service-Type Attribute with value "Authorize Only" indicates that the Request only contains NAS and session identification attributes, and that the NAS should attempt reauthorization by sending an Access- Request with a Service-Type Attribute with value "Authorize Only". This enables a usage model akin to that supported in Diameter, thus easing translation between the two protocols. Support for the Service-Type Attribute is optional within CoA-Request and Disconnect-Request messages; where it is not included, the Request message may contain both identification and authorization attributes. A NAS that does not support the Service-Type Attribute with the value "Authorize Only" within a Disconnect-Request MUST respond with a Disconnect-NAK including no Service-Type Attribute; an Error-Cause Attribute with value "Unsupported Service" MAY be included. A NAS that does not support the Service-Type Attribute with the value "Authorize Only" within a CoA-Request MUST respond with a CoA-NAK including no Service-Type Attribute; an Error-Cause Attribute with value "Unsupported Service" MAY be included.
A NAS supporting the "Authorize Only" Service-Type value within Disconnect-Request or CoA-Request messages MUST respond with a Disconnect-NAK or CoA-NAK respectively, containing a Service-Type Attribute with value "Authorize Only", and an Error-Cause Attribute with value "Request Initiated". The NAS then sends an Access-Request to the RADIUS server with a Service-Type Attribute with value "Authorize Only". This Access-Request SHOULD contain the NAS attributes from the Disconnect or CoA-Request, as well as the session attributes from the Request legal for inclusion in an Access-Request as specified in [RFC2865], [RFC2868], [RFC2869] and [RFC3162]. As noted in [RFC2869] Section 5.19, a Message-Authenticator attribute SHOULD be included in an Access-Request that does not contain a User-Password, CHAP-Password, ARAP-Password or EAP-Message Attribute. The RADIUS server should send back an Access-Accept to (re-)authorize the session or an Access-Reject to refuse to (re-)authorize it.
A NAS supporting the "Authorize Only" Service-Type value within Disconnect-Request or CoA-Request messages MUST respond with a Disconnect-NAK or CoA-NAK respectively, containing a Service-Type Attribute with value "Authorize Only", and an Error-Cause Attribute with value "Request Initiated". The NAS then sends an Access-Request to the RADIUS server with a Service-Type Attribute with value "Authorize Only". This Access-Request SHOULD contain the NAS attributes from the Disconnect or CoA-Request, as well as the session attributes from the Request legal for inclusion in an Access-Request as specified in [RFC2865], [RFC2868], [RFC2869] and [RFC3162]. As noted in [RFC2869] Section 5.19, a Message-Authenticator attribute SHOULD be included in an Access-Request that does not contain a User-Password, CHAP-Password, ARAP-Password or EAP-Message Attribute. The RADIUS server should send back an Access-Accept to (re-)authorize the session or an Access-Reject to refuse to (re-)authorize it.
[Note 7] The State Attribute is available to be sent by the RADIUS server to the NAS in a Disconnect-Request or CoA-Request message and MUST be sent unmodified from the NAS to the RADIUS server in a subsequent ACK or NAK message. If a Service-Type Attribute with value "Authorize Only" is included in a Disconnect-Request or CoA- Request along with a State Attribute, then the State Attribute MUST be sent unmodified from the NAS to the RADIUS server in the resulting Access-Request sent to the RADIUS server, if any. The State Attribute is also available to be sent by the RADIUS server to the NAS in a CoA-Request that also includes a Termination-Action Attribute with the value of RADIUS-Request. If the client performs the Termination-Action by sending a new Access-Request upon termination of the current session, it MUST include the State
[Note 7] The State Attribute is available to be sent by the RADIUS server to the NAS in a Disconnect-Request or CoA-Request message and MUST be sent unmodified from the NAS to the RADIUS server in a subsequent ACK or NAK message. If a Service-Type Attribute with value "Authorize Only" is included in a Disconnect-Request or CoA- Request along with a State Attribute, then the State Attribute MUST be sent unmodified from the NAS to the RADIUS server in the resulting Access-Request sent to the RADIUS server, if any. The State Attribute is also available to be sent by the RADIUS server to the NAS in a CoA-Request that also includes a Termination-Action Attribute with the value of RADIUS-Request. If the client performs the Termination-Action by sending a new Access-Request upon termination of the current session, it MUST include the State
Chiba, et al. Informational [Page 19] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
Chiba, et al. Informational [Page 19] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
Attribute unchanged in that Access-Request. In either usage, the client MUST NOT interpret the Attribute locally. A Disconnect- Request or CoA-Request packet must have only zero or one State Attribute. Usage of the State Attribute is implementation dependent. If the RADIUS server does not recognize the State Attribute in the Access-Request, then it MUST send an Access-Reject.
Attribute unchanged in that Access-Request. In either usage, the client MUST NOT interpret the Attribute locally. A Disconnect- Request or CoA-Request packet must have only zero or one State Attribute. Usage of the State Attribute is implementation dependent. If the RADIUS server does not recognize the State Attribute in the Access-Request, then it MUST send an Access-Reject.
The following table defines the meaning of the above table entries.
The following table defines the meaning of the above table entries.
0 This attribute MUST NOT be present in packet.
0+ Zero or more instances of this attribute MAY be present in
packet.
0-1 Zero or one instance of this attribute MAY be present in packet.
1 Exactly one instance of this attribute MUST be present in packet.
0 This attribute MUST NOT be present in packet. 0+ Zero or more instances of this attribute MAY be present in packet. 0-1 Zero or one instance of this attribute MAY be present in packet. 1 Exactly one instance of this attribute MUST be present in packet.
4. IANA Considerations
4. IANA Considerations
This document uses the RADIUS [RFC2865] namespace, see <http://www.iana.org/assignments/radius-types>. There are six updates for the section: RADIUS Packet Type Codes. These Packet Types are allocated in [RADIANA]:
This document uses the RADIUS [RFC2865] namespace, see <http://www.iana.org/assignments/radius-types>. There are six updates for the section: RADIUS Packet Type Codes. These Packet Types are allocated in [RADIANA]:
40 - Disconnect-Request 41 - Disconnect-ACK 42 - Disconnect-NAK 43 - CoA-Request 44 - CoA-ACK 45 - CoA-NAK
40 - Disconnect-Request 41 - Disconnect-ACK 42 - Disconnect-NAK 43 - CoA-Request 44 - CoA-ACK 45 - CoA-NAK
Allocation of a new Service-Type value for "Authorize Only" is requested. This document also uses the UDP [RFC768] namespace, see <http://www.iana.org/assignments/port-numbers>. The authors request a port assignment from the Registered ports range. Finally, this specification allocates the Error-Cause Attribute (101) with the following decimal values:
Allocation of a new Service-Type value for "Authorize Only" is requested. This document also uses the UDP [RFC768] namespace, see <http://www.iana.org/assignments/port-numbers>. The authors request a port assignment from the Registered ports range. Finally, this specification allocates the Error-Cause Attribute (101) with the following decimal values:
# Value
--- -----
201 Residual Session Context Removed
202 Invalid EAP Packet (Ignored)
401 Unsupported Attribute
402 Missing Attribute
403 NAS Identification Mismatch
404 Invalid Request
405 Unsupported Service
406 Unsupported Extension
501 Administratively Prohibited
502 Request Not Routable (Proxy)
# Value --- ----- 201 Residual Session Context Removed 202 Invalid EAP Packet (Ignored) 401 Unsupported Attribute 402 Missing Attribute 403 NAS Identification Mismatch 404 Invalid Request 405 Unsupported Service 406 Unsupported Extension 501 Administratively Prohibited 502 Request Not Routable (Proxy)
Chiba, et al. Informational [Page 20] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
Chiba, et al. Informational [Page 20] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
503 Session Context Not Found 504 Session Context Not Removable 505 Other Proxy Processing Error 506 Resources Unavailable 507 Request Initiated
503 Session Context Not Found 504 Session Context Not Removable 505 Other Proxy Processing Error 506 Resources Unavailable 507 Request Initiated
5. Security Considerations
5. Security Considerations
5.1. Authorization Issues
5.1. Authorization Issues
Where a NAS is shared by multiple providers, it is undesirable for one provider to be able to send Disconnect-Request or CoA-Requests affecting the sessions of another provider.
Where a NAS is shared by multiple providers, it is undesirable for one provider to be able to send Disconnect-Request or CoA-Requests affecting the sessions of another provider.
A NAS or RADIUS proxy MUST silently discard Disconnect-Request or CoA-Request messages from untrusted sources. By default, a RADIUS proxy SHOULD perform a "reverse path forwarding" (RPF) check to verify that a Disconnect-Request or CoA-Request originates from an authorized RADIUS server. In addition, it SHOULD be possible to explicitly authorize additional sources of Disconnect-Request or CoA-Request packets relating to certain classes of sessions. For example, a particular source can be explicitly authorized to send CoA-Request messages relating to users within a set of realms.
A NAS or RADIUS proxy MUST silently discard Disconnect-Request or CoA-Request messages from untrusted sources. By default, a RADIUS proxy SHOULD perform a "reverse path forwarding" (RPF) check to verify that a Disconnect-Request or CoA-Request originates from an authorized RADIUS server. In addition, it SHOULD be possible to explicitly authorize additional sources of Disconnect-Request or CoA-Request packets relating to certain classes of sessions. For example, a particular source can be explicitly authorized to send CoA-Request messages relating to users within a set of realms.
To perform the RPF check, the proxy uses the session identification attributes included in Disconnect-Request or CoA-Request messages, in order to determine the RADIUS server(s) to which an equivalent Access-Request could be routed. If the source address of the Disconnect-Request or CoA-Request is within this set, then the Request is forwarded; otherwise it MUST be silently discarded.
働くために、RPFはチェックします、セッション識別属性がDisconnect-要求かCoA-要求メッセージに含んだプロキシ用途、同等なAccess-要求を発送できたRADIUSサーバを決定するために。 このセットの中にDisconnect-要求かCoA-要求のソースアドレスがあるなら、Requestを進めます。 さもなければ、静かにそれを捨てなければなりません。
Typically the proxy will extract the realm from the Network Access Identifier [RFC2486] included within the User-Name Attribute, and determine the corresponding RADIUS servers in the proxy routing tables. The RADIUS servers for that realm are then compared against the source address of the packet. Where no RADIUS proxy is present, the RPF check will need to be performed by the NAS itself.
プロキシは、通常、User-名前Attributeの中に[RFC2486]を含んでいて、Network Access Identifierから分野を抽出して、プロキシ経路指定テーブルで対応するRADIUSサーバを決定するでしょう。 そして、その分野へのRADIUSサーバはパケットのソースアドレスに対してたとえられます。 どんなRADIUSプロキシも出席していないところでは、RPFチェックは、NAS自身によって実行される必要があるでしょう。
Since authorization to send a Disconnect-Request or CoA-Request is determined based on the source address and the corresponding shared secret, the NASes or proxies SHOULD configure a different shared secret for each RADIUS server.
Disconnect-要求かCoA-要求を送る承認がソースアドレスと対応する共有秘密キーに基づいて決定しているので、NASesかプロキシSHOULDがそれぞれのRADIUSサーバのための異なった共有秘密キーを構成します。
Chiba, et al. Informational [Page 21] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
千葉、他 半径2003年7月への情報[21ページ]のRFC3576のダイナミックな承認拡張子
5.2. Impersonation
5.2. ものまね
[RFC2865] Section 3 states:
[RFC2865]セクション3州:
A RADIUS server MUST use the source IP address of the RADIUS UDP
packet to decide which shared secret to use, so that RADIUS
requests can be proxied.
RADIUSサーバはどの共有秘密キーを使用したらよいかを決めるのにRADIUS UDPパケットのソースIPアドレスを使用しなければなりません、RADIUS要求をproxiedされることができるように。
When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or NAS-IPv6-Address Attributes will typically not match the source address observed by the RADIUS server. Since the NAS-Identifier Attribute need not contain an FQDN, this attribute may not be resolvable to the source address observed by the RADIUS server, even when no proxy is present.
RADIUS要求がプロキシによって転送されるとき、NAS IPアドレスかNAS-IPv6-アドレスAttributesがRADIUSサーバによって観測されたソースアドレスに通常合わないでしょう。NAS-識別子AttributeがFQDNを含む必要はないので、この属性はRADIUSサーバによって観測されたソースアドレスに溶解性でないかもしれません、どんなプロキシも出席してさえいないとき。
As a result, the authenticity check performed by a RADIUS server or proxy does not verify the correctness of NAS identification attributes. This makes it possible for a rogue NAS to forge NAS-IP- Address, NAS-IPv6-Address or NAS-Identifier Attributes within a RADIUS Access-Request in order to impersonate another NAS. It is also possible for a rogue NAS to forge session identification attributes such as the Called-Station-Id, Calling-Station-Id, or Originating-Line-Info [NASREQ]. This could fool the RADIUS server into sending Disconnect-Request or CoA-Request messages containing forged session identification attributes to a NAS targeted by an attacker.
その結果、RADIUSサーバかプロキシによって実行された信憑性チェックはNAS識別属性の正当性について確かめません。 これで、凶暴なNASが別のNASをまねるためにRADIUS Access-要求の中でNAS IP-アドレス、NAS-IPv6-アドレスまたはNAS-識別子Attributesを偽造するのが可能になります。 また、凶暴なNASがCalled駅のイド、Calling駅のイド、またはOriginating線インフォメーション[NASREQ]などのセッション識別属性を鍛造するのも、可能です。 偽造セッション識別属性を攻撃者によって狙われたNASに含んでいて、これは、RADIUSサーバがDisconnect-要求かCoA-要求メッセージを送るようにだますかもしれません。
To address these vulnerabilities RADIUS proxies SHOULD check whether NAS identification attributes (see Section 3.) match the source address of packets originating from the NAS. Where one or more attributes do not match, Disconnect-Request or CoA-Request messages SHOULD be silently discarded.
これらの脆弱性がRADIUSプロキシSHOULDであると扱うには、NAS識別属性(セクション3を見る)がNASから発するパケットのソースアドレスに合っているかどうかチェックしてください。 1つ以上の属性が合っていないところでは、捨てられて、Disconnect-要求かCoA-要求メッセージSHOULDは静かに合っています。
Such a check may not always be possible. Since the NAS-Identifier Attribute need not correspond to an FQDN, it may not be resolvable to an IP address to be matched against the source address. Also, where a NAT exists between the RADIUS client and proxy, checking the NAS- IP-Address or NAS-IPv6-Address Attributes may not be feasible.
そのようなチェックはいつも可能であるかもしれないというわけではありません。 NAS-識別子AttributeがFQDNに対応する必要はないので、ソースアドレスに対して合わせられるのはIPアドレスに溶解性でないかもしれません。 また、NATがRADIUSクライアントとプロキシの間に存在するところでNAS IP-アドレスかNAS-IPv6-アドレスAttributesをチェックするのは可能でないかもしれません。
5.3. IPsec Usage Guidelines
5.3. IPsec用法ガイドライン
In addition to security vulnerabilities unique to Disconnect or CoA messages, the protocol exchanges described in this document are susceptible to the same vulnerabilities as RADIUS [RFC2865]. It is RECOMMENDED that IPsec be employed to afford better security.
Disconnectにユニークなセキュリティの脆弱性かCoAメッセージに加えて、本書では説明されたプロトコル交換はRADIUS[RFC2865]と同じ脆弱性に影響されやすいです。 IPsecが、より良いセキュリティを都合するのに使われるのは、RECOMMENDEDです。
Chiba, et al. Informational [Page 22] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
千葉、他 半径2003年7月への情報[22ページ]のRFC3576のダイナミックな承認拡張子
Implementations of this specification SHOULD support IPsec [RFC2401] along with IKE [RFC2409] for key management. IPsec ESP [RFC2406] with a non-null transform SHOULD be supported, and IPsec ESP with a non-null encryption transform and authentication support SHOULD be used to provide per-packet confidentiality, authentication, integrity and replay protection. IKE SHOULD be used for key management.
この仕様SHOULDの実装はかぎ管理のために、IKE[RFC2409]に伴うIPsec[RFC2401]をサポートします。 非ヌル変換SHOULDがサポートされている超能力[RFC2406]、およびIPsecの超能力のaによる非ヌルの暗号化が変えて、認証がSHOULDであるとサポートするIPsecは1パケットあたりの秘密性、認証に保全を提供するのに使用されて、保護を再演します。 IKE SHOULD、かぎ管理には、使用されてください。
Within RADIUS [RFC2865], a shared secret is used for hiding Attributes such as User-Password, as well as used in computation of the Response Authenticator. In RADIUS accounting [RFC2866], the shared secret is used in computation of both the Request Authenticator and the Response Authenticator.
RADIUS[RFC2865]の中では、共有秘密キーは、User-パスワードなどのAttributesを隠すのに使用されて、Response Authenticatorの計算に使用されます。 RADIUS会計[RFC2866]では、共有秘密キーはRequest AuthenticatorとResponse Authenticatorの両方の計算に使用されます。
Since in RADIUS a shared secret is used to provide confidentiality as well as integrity protection and authentication, only use of IPsec ESP with a non-null transform can provide security services sufficient to substitute for RADIUS application-layer security. Therefore, where IPsec AH or ESP null is used, it will typically still be necessary to configure a RADIUS shared secret.
共有秘密キーが非ヌルと共に保全保護と認証、IPsecの使用だけと同様に超能力を秘密性に供給するのにRADIUSで使用されるので、変換はRADIUS応用層セキュリティに代入できるくらいのセキュリティー・サービスを提供できます。 したがって、IPsec AHか超能力ヌルが使用されているところでは、RADIUS共有秘密キーを構成するのはまだ通常必要になっているでしょう。
Where RADIUS is run over IPsec ESP with a non-null transform, the secret shared between the NAS and the RADIUS server MAY NOT be configured. In this case, a shared secret of zero length MUST be assumed. However, a RADIUS server that cannot know whether incoming traffic is IPsec-protected MUST be configured with a non-null RADIUS shared secret.
RADIUSがIPsecの上で非ヌル変換がある超能力、NASの間で共有された秘密、およびRADIUSサーバを管理するどこのことであるかは構成されないかもしれません。 この場合、ゼロ・レングスに関する共有秘密キーを想定しなければなりません。 しかしながら、非ヌルRADIUS共有秘密キーで入って来るトラフィックがIPsecによって保護されているかどうかを知ることができないRADIUSサーバを構成しなければなりません。
When IPsec ESP is used with RADIUS, per-packet authentication, integrity and replay protection MUST be used. 3DES-CBC MUST be supported as an encryption transform and AES-CBC SHOULD be supported. AES-CBC SHOULD be offered as a preferred encryption transform if supported. HMAC-SHA1-96 MUST be supported as an authentication transform. DES-CBC SHOULD NOT be used as the encryption transform.
IPsecであるときに、超能力はRADIUSと共に使用されて、1パケットあたりの認証、保全、および反復操作による保護を使用しなければなりません。 暗号化変換とAES-CBC SHOULDとして3DES-CBCをサポートしなければなりません。サポートされます。 AES-CBC SHOULD、都合のよい暗号化変換として、サポートするなら、提供してください。 HMAC-SHA1-96 MUST、認証変換として、サポートされてください。 デス-CBC SHOULD NOT、暗号化変換として、使用されてください。
A typical IPsec policy for an IPsec-capable RADIUS client is "Initiate IPsec, from me to any destination port UDP 1812". This IPsec policy causes an IPsec SA to be set up by the RADIUS client prior to sending RADIUS traffic. If some RADIUS servers contacted by the client do not support IPsec, then a more granular policy will be required: "Initiate IPsec, from me to IPsec-Capable-RADIUS-Server, destination port UDP 1812."
IPsec有能なRADIUSクライアントのための典型的なIPsec方針は「IPsecを開始してください、そして、私からあらゆる目的地まで、UDP1812を移植してください」です。 このIPsec方針で、送付RADIUSトラフィックの前のRADIUSクライアントはIPsec SAをセットアップします。 クライアントによって連絡されたいくつかのRADIUSサーバがIPsecをサポートしないと、より粒状の方針が必要でしょう: 「私からIPsecのできるRADIUSサーバ、仕向港UDP1812までIPsecを開始してください。」
For a client implementing this specification, the policy would be "Accept IPsec, from any to me, destination port UDP 3799". This causes the RADIUS client to accept (but not require) use of IPsec. It may not be appropriate to require IPsec for all RADIUS servers connecting to an IPsec-enabled RADIUS client, since some RADIUS servers may not support IPsec.
この仕様を履行するクライアントにとって、方針は「いずれから私にIPsecを受け入れてください、そして、目的地はUDP3799を移植します」でしょう。 しかし、RADIUSクライアントがこれで受け入れる、(必要でない、)、IPsecの使用。 IPsecによって可能にされたRADIUSクライアントに接するすべてのRADIUSサーバのためにIPsecを必要とするのは適切でないかもしれません、いくつかのRADIUSサーバがIPsecをサポートしないかもしれないので。
Chiba, et al. Informational [Page 23] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
千葉、他 半径2003年7月への情報[23ページ]のRFC3576のダイナミックな承認拡張子
For an IPsec-capable RADIUS server, a typical IPsec policy is "Accept IPsec, from any to me, destination port 1812". This causes the RADIUS server to accept (but not require) use of IPsec. It may not be appropriate to require IPsec for all RADIUS clients connecting to an IPsec-enabled RADIUS server, since some RADIUS clients may not support IPsec.
IPsecできるRADIUSサーバのために、典型的なIPsec方針は「いずれから私にIPsecを受け入れてください、そして、目的地は1812を移植します」です。 しかし、RADIUSサーバがこれで受け入れる、(必要でない、)、IPsecの使用。 IPsecによって可能にされたRADIUSサーバに接続するすべてのRADIUSクライアントのためにIPsecを必要とするのは適切でないかもしれません、何人かのRADIUSクライアントがIPsecをサポートしないかもしれないので。
For servers implementing this specification, the policy would be "Initiate IPsec, from me to any, destination port UDP 3799". This causes the RADIUS server to initiate IPsec when sending RADIUS extension traffic to any RADIUS client. If some RADIUS clients contacted by the server do not support IPsec, then a more granular policy will be required, such as "Initiate IPsec, from me to IPsec- capable-RADIUS-client, destination port UDP 3799".
この仕様を履行するサーバのために、方針は「私からどんな、仕向港UDP3799までの開始IPsecも」でしょう。 どんなRADIUSクライアントへの拡大トラフィックもRADIUSに送るとき、これで、RADIUSサーバはIPsecを開始します。 サーバで連絡された何人かのRADIUSクライアントがIPsecをサポートしないと、より粒状の方針が必要でしょう、「私から有能なIPsec RADIUSクライアントまでIPsecを開始してください、仕向港UDP3799」などのように。
Where IPsec is used for security, and no RADIUS shared secret is configured, it is important that the RADIUS client and server perform an authorization check. Before enabling a host to act as a RADIUS client, the RADIUS server SHOULD check whether the host is authorized to provide network access. Similarly, before enabling a host to act as a RADIUS server, the RADIUS client SHOULD check whether the host is authorized for that role.
IPsecがセキュリティに使用されて、RADIUS共有秘密キーが全く構成されないところでは、RADIUSクライアントとサーバが許可検査を実行するのは、重要です。 ホストがRADIUSクライアントとして務めるのを可能にする前に、RADIUSサーバSHOULDは、ホストがネットワークアクセサリーを提供するのに権限を与えられるかどうかチェックします。 同様に、ホストがRADIUSサーバとして務めるのを可能にする前に、RADIUSクライアントSHOULDは、ホストがその役割のために権限を与えられるかどうかチェックします。
RADIUS servers can be configured with the IP addresses (for IKE Aggressive Mode with pre-shared keys) or FQDNs (for certificate authentication) of RADIUS clients. Alternatively, if a separate Certification Authority (CA) exists for RADIUS clients, then the RADIUS server can configure this CA as a trust anchor [RFC3280] for use with IPsec.
RADIUSクライアントのIPのアドレス(あらかじめ共有されたキーがあるIKE Aggressive Modeのための)かFQDNs(証明書認証のための)でRADIUSサーバを構成できます。 あるいはまた、別々の認証局(カリフォルニア)がRADIUSクライアントのために存在するなら、RADIUSサーバはIPsecとの使用のための信頼アンカー[RFC3280]としてこのカリフォルニアを構成できます。
Similarly, RADIUS clients can be configured with the IP addresses (for IKE Aggressive Mode with pre-shared keys) or FQDNs (for certificate authentication) of RADIUS servers. Alternatively, if a separate CA exists for RADIUS servers, then the RADIUS client can configure this CA as a trust anchor for use with IPsec.
同様に、RADIUSサーバのIPのアドレス(あらかじめ共有されたキーがあるIKE Aggressive Modeのための)かFQDNs(証明書認証のための)でRADIUSクライアントを構成できます。 あるいはまた、別々のカリフォルニアがRADIUSサーバのために存在しているなら、RADIUSクライアントはIPsecとの使用のための信頼アンカーとしてこのカリフォルニアを構成できます。
Since unlike SSL/TLS, IKE does not permit certificate policies to be set on a per-port basis, certificate policies need to apply to all uses of IPsec on RADIUS clients and servers. In IPsec deployment supporting only certificate authentication, a management station initiating an IPsec-protected telnet session to the RADIUS server would need to obtain a certificate chaining to the RADIUS client CA. Issuing such a certificate might not be appropriate if the management station was not authorized as a RADIUS client.
IKEが、SSL/TLSと異なって証明書方針が1ポートあたり1個のベースに設定されるのを可能にしないので、証明書方針は、RADIUSクライアントとサーバにおけるIPsecのすべての用途に適用する必要があります。 証明書認証だけをサポートするIPsec展開では、IPsecによって保護されたtelnetセッションをRADIUSサーバに開始する管理局は、RADIUSクライアントカリフォルニアに証明書推論を得る必要があるでしょう。 管理局がRADIUSクライアントとして認可されないなら、そのような証明書を発行するのは適切でないでしょうに。
Where RADIUS clients may obtain their IP address dynamically (such as an Access Point supporting DHCP), Main Mode with pre-shared keys [RFC2409] SHOULD NOT be used, since this requires use of a group
RADIUSクライアントが彼らのIPを得るかもしれないところでは、ダイナミックに(DHCPをサポートするAccess Pointとしてのそのようなもの)を扱ってください、あらかじめ共有されたキー[RFC2409]SHOULD NOTが使用されているMain Mode、これがグループの使用を必要とするので
Chiba, et al. Informational [Page 24] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
千葉、他 半径2003年7月への情報[24ページ]のRFC3576のダイナミックな承認拡張子
pre-shared key; instead, Aggressive Mode SHOULD be used. Where RADIUS client addresses are statically assigned, either Aggressive Mode or Main Mode MAY be used. With certificate authentication, Main Mode SHOULD be used.
キーをあらかじめ共有します。 代わりにAggressive Mode SHOULD、使用されてください。 RADIUSクライアントアドレスが静的に割り当てられるところでは、Aggressive ModeかMain Modeのどちらかが使用されるかもしれません。 Main Mode SHOULD、認証を証明してください。使用されます。
Care needs to be taken with IKE Phase 1 Identity Payload selection in order to enable mapping of identities to pre-shared keys, even with Aggressive Mode. Where the ID_IPV4_ADDR or ID_IPV6_ADDR Identity Payloads are used and addresses are dynamically assigned, mapping of identities to keys is not possible, so that group pre-shared keys are still a practical necessity. As a result, the ID_FQDN identity payload SHOULD be employed in situations where Aggressive mode is utilized along with pre-shared keys and IP addresses are dynamically assigned. This approach also has other advantages, since it allows the RADIUS server and client to configure themselves based on the fully qualified domain name of their peers.
注意は、あらかじめ共有されたキーへのアイデンティティに関するマッピングを可能にするためにIKE Phase1Identity有効搭載量選択で取られる必要があります、Aggressive Modeがあっても。 キーへのアイデンティティのマッピングが可能でない、ID_IPV4_ADDRかID_IPV6_ADDR Identity有効搭載量が使用されていて、アドレスがダイナミックに割り当てられて、したがって、そのグループがあらかじめ共有されたところでは、それでも、キーが実用的な必要性です。 aは結果として生じます、ID_FQDNアイデンティティペイロードSHOULD。状況で、Aggressiveモードがあらかじめ共有されたキーと共に利用されて、IPアドレスがダイナミックに割り当てられるところで使われてください。 また、このアプローチには、他の利点があります、RADIUSサーバとクライアントが彼らの同輩の完全修飾ドメイン名に基づいてそれで自分たちを構成できるので。
Note that with IPsec, security services are negotiated at the granularity of an IPsec SA, so that RADIUS exchanges requiring a set of security services different from those negotiated with existing IPsec SAs will need to negotiate a new IPsec SA. Separate IPsec SAs are also advisable where quality of service considerations dictate different handling RADIUS conversations. Attempting to apply different quality of service to connections handled by the same IPsec SA can result in reordering, and falling outside the replay window. For a discussion of the issues, see [RFC2983].
IPsecと、セキュリティー・サービスがIPsec SAの粒状で交渉されることに注意してください、それらと異なったセキュリティー・サービスをセットに要求するRADIUS交換がIPsec SAsが新しいIPsec SAを交渉するために必要とする存在と交渉されたように。 また、別々のIPsec SAsもサービスの質問題が異なった取り扱いRADIUSの会話を決めるところで賢明です。 同じIPsec SAによって扱われた接続に異なったサービスの質を適用するのを試みるのを再生ウィンドウを再命令して、そらせるのに結果として生じることができます。 問題の議論に関しては、[RFC2983]を見てください。
5.4. Replay Protection
5.4. 反復操作による保護
Where IPsec replay protection is not used, the Event-Timestamp (55) Attribute [RFC2869] SHOULD be included within all messages. When this attribute is present, both the NAS and the RADIUS server MUST check that the Event-Timestamp Attribute is current within an acceptable time window. If the Event-Timestamp Attribute is not current, then the message MUST be silently discarded. This implies the need for time synchronization within the network, which can be achieved by a variety of means, including secure NTP, as described in [NTPAUTH].
IPsec反復操作による保護が使用されていないところでは、含まれていて、Event-タイムスタンプ(55)はすべてのメッセージの中で[RFC2869]SHOULDを結果と考えます。 この属性が存在しているとき、NASとRADIUSサーバの両方が、Event-タイムスタンプAttributeが許容できるタイムウィンドウの中でよく見られるのをチェックしなければなりません。 Event-タイムスタンプAttributeがよく見られないなら、静かにメッセージを捨てなければなりません。 これはネットワークの中で時間同期化の必要性を含意します、安全なNTPを含んでいて、[NTPAUTH]で説明されるように。さまざまな手段でネットワークを達成できます。
Both the NAS and the RADIUS server SHOULD be configurable to silently discard messages lacking an Event-Timestamp Attribute. A default time window of 300 seconds is recommended.
NASとRADIUSサーバSHOULDの両方、静かにEvent-タイムスタンプAttributeを欠いているメッセージを捨てるのにおいて、構成可能であってください。 300秒のデフォルトタイムウィンドウはお勧めです。
Chiba, et al. Informational [Page 25] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
千葉、他 半径2003年7月への情報[25ページ]のRFC3576のダイナミックな承認拡張子
6. Example Traces
6. 例の跡
Disconnect Request with User-Name:
ユーザ名との要求から切断してください:
0: xxxx xxxx xxxx xxxx xxxx 2801 001c 1b23 .B.....$.-(....#
16: 624c 3543 ceba 55f1 be55 a714 ca5e 0108 bL5C..U..U...^..
32: 6d63 6869 6261
0: xxxx xxxx xxxx xxxx xxxx2801 001c 1b23B.…$、-、(…、#16: 624c3543ceba 55f1 be55 a714 ca5e0108bL5C..U.U. ^32:、6d63 6869 6261
Disconnect Request with Acct-Session-ID:
Acct Session IDとの要求から切断してください:
0: xxxx xxxx xxxx xxxx xxxx 2801 001e ad0d .B..... ~.(.....
16: 8e53 55b6 bd02 a0cb ace6 4e38 77bd 2c0a .SU.......N8w.,.
32: 3930 3233 3435 3637 90234567
0: xxxx xxxx xxxx xxxx xxxx2801 001e ad0d B.… ~(.16. : 8e53 55b6 bd02 a0cb ace6 4e38 77bd 2c0a .SU.......N8w.、32:3930 3233 3435 3637 90234567
Disconnect Request with Framed-IP-Address:
縁どられたIPアドレスとの要求から切断してください:
0: xxxx xxxx xxxx xxxx xxxx 2801 001a 0bda .B....."2.(.....
16: 33fe 765b 05f0 fd9c c32a 2f6b 5182 0806 3.v[.....*/kQ...
32: 0a00 0203
0: 「xxxx xxxx xxxx xxxx xxxx2801 001a 0bda B.」…2.、(.16、: 33fe 765b 05f0 fd9c c32a 2f6b5182 0806 3.v、[kQ32…: …. . */0a00 0203
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[RFC1305] Mills, D., "Network Time Protocol (version 3)
Specification, Implementation and Analysis", RFC 1305,
March 1992.
[RFC1305] 工場、D.、「ネットワーク時間は仕様、実装、および分析について議定書の中で述べ(バージョン3)」RFC1305、1992年3月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC
1321, April 1992.
[RFC1321] Rivest、R.、「MD5メッセージダイジェストアルゴリズム」、RFC1321、1992年4月。
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC2104] Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[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月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
the Internet Protocol", RFC 2401, November 1998.
[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケントとS.とR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
Chiba, et al. Informational [Page 26] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
千葉、他 半径2003年7月への情報[26ページ]のRFC3576のダイナミックな承認拡張子
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC
2434, October 1998.
[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[RFC2486] Aboba, B. and M. Beadles, "The Network Access
Identifier", RFC 2486, January 1999.
[RFC2486] AbobaとB.とM.用務員、「ネットワークアクセス識別子」、RFC2486、1999年1月。
[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月)。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866] Rigney、C.、「半径会計」、RFC2866、2000年6月。
[RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS
Extensions", RFC 2869, June 2000.
[RFC2869] RigneyとC.とWillatsとW.とP.カルフーン、「半径拡大」、RFC2869、2000年6月。
[RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6",
RFC 3162, August 2001.
[RFC3162] AbobaとB.とゾルンとG.とD.ミットンと「半径とIPv6"、RFC3162、2001年8月。」
[RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[RFC3280] HousleyとR.とポークとW.とフォードとW.と一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280、2002年4月。
[RADIANA] Aboba, B., "IANA Considerations for RADIUS (Remote
Authentication Dial In User Service)", RFC 3575, July
2003.
[RADIANA] Aboba、B.、「半径(ユーザサービスにおけるリモート認証ダイヤル)のためのIANA問題」、RFC3575、2003年7月。
7.2. Informative References
7.2. 有益な参照
[RFC2882] Mitton, D., "Network Access Server Requirements:
Extended RADIUS Practices", RFC 2882, July 2000.
[RFC2882]ミットン、D.、「アクセス・サーバー要件をネットワークでつないでください」 「拡張半径習慣」、RFC2882、2000年7月。
[RFC2983] Black, D. "Differentiated Services and Tunnels", RFC
2983, October 2000.
[RFC2983] 黒、D.が「サービスとトンネルを差別化した」、RFC2983、10月2000日
[AAATransport] Aboba, B. and J. Wood, "Authentication, Authorization
and Accounting (AAA) Transport Profile", RFC 3539,
June 2003.
[AAATransport]Aboba、B.とJ.木、「認証、承認、および会計(AAA)輸送プロフィール」、RFC3539、6月2003日
[Diameter] Calhoun, P., et al., "Diameter Base Protocol", Work in
Progress.
[直径]カルフーン、P.、他、「直径基地のプロトコル」、ProgressのWork。
[MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent
Attack", CryptoBytes Vol.2 No.2, Summer 1996.
[MD5Attack] Dobbertin、H.、「最近の攻撃の後のMD5の状態」、CryptoBytes Vol.2No.2、1996年夏。
[NASREQ] Calhoun, P., et al., "Diameter Network Access Server
Application", Work in Progress.
[NASREQ] カルフーン、P.、他、「直径ネットワークアクセス・サーバーアプリケーション」、ProgressのWork。
Chiba, et al. Informational [Page 27] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
千葉、他 半径2003年7月への情報[27ページ]のRFC3576のダイナミックな承認拡張子
[NTPAUTH] Mills, D., "Public Key Cryptography for the Network
Time Protocol", Work in Progress.
D.、「ネットワーク時間プロトコルのための公開鍵暗号」という[NTPAUTH]工場は進行中で動作します。
8. Intellectual Property Statement
8. 知的所有権声明
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat.
IETFはどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP-11で標準化過程の権利と規格の関連するドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可がimplementersによるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFはこの規格を練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 IETF専務に情報を扱ってください。
9. Acknowledgments
9. 承認
This protocol was first developed and distributed by Ascend Communications. Example code was distributed in their free server kit.
このプロトコルは、Ascend Communicationsによって最初に、開発されて、分配されました。 例のコードはそれらの無料のサーバキットで分配されました。
The authors would like to acknowledge the valuable suggestions and feedback from the following people:
作者は以下の人々から貴重な提案とフィードバックを承諾したがっています:
Avi Lior <avi@bridgewatersystems.com>,
Randy Bush <randy@psg.net>,
Steve Bellovin <smb@research.att.com>
Glen Zorn <gwz@cisco.com>,
Mark Jones <mjones@bridgewatersystems.com>,
Claudio Lapidus <clapidus@hotmail.com>,
Anurag Batta <Anurag_Batta@3com.com>,
Kuntal Chowdhury <chowdury@nortelnetworks.com>, and
Tim Moore <timmoore@microsoft.com>.
Russ Housley <housley@vigilsec.com>
Avi Lior <avi@bridgewatersystems.com>, Randy Bush <randy@psg.net>, Steve Bellovin <smb@research.att.com> Glen Zorn <gwz@cisco.com>, Mark Jones <mjones@bridgewatersystems.com>, Claudio Lapidus <clapidus@hotmail.com>, Anurag Batta <Anurag_Batta@3com.com>, Kuntal Chowdhury <chowdury@nortelnetworks.com>, and Tim Moore <timmoore@microsoft.com>. ラス Housley <housley@vigilsec.com 、gt。
Chiba, et al. Informational [Page 28] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
千葉、他 半径2003年7月への情報[28ページ]のRFC3576のダイナミックな承認拡張子
10. Authors' Addresses
10. 作者のアドレス
Murtaza Chiba Cisco Systems, Inc. 170 West Tasman Dr. San Jose CA, 95134
Murtaza千葉シスコシステムズInc.170の西タスマン博士サンノゼカリフォルニア、95134
EMail: mchiba@cisco.com Phone: +1 408 525 7198
メール: mchiba@cisco.com 電話: +1 408 525 7198
Gopal Dommety Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA 95134
サンノゼ、ゴパルDommetyシスコシステムズInc.170の西タスマン博士カリフォルニア 95134
EMail: gdommety@cisco.com Phone: +1 408 525 1404
メール: gdommety@cisco.com 電話: +1 408 525 1404
Mark Eklund Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA 95134
サンノゼ、マークエクルンドシスコシステムズInc.170の西タスマン博士カリフォルニア 95134
EMail: meklund@cisco.com Phone: +1 865 671 6255
メール: meklund@cisco.com 電話: +1 865 671 6255
David Mitton Circular Logic UnLtd. 733 Turnpike Street #154 North Andover, MA 01845
デヴィッドミットン円形の論理UnLtd733Turnpike通り#154ノースアンドーバー(MA)01845
EMail: david@mitton.com Phone: +1 978 683 1814
メール: david@mitton.com 電話: +1 978 683 1814
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
バーナードAbobaマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン 98052
EMail: bernarda@microsoft.com Phone: +1 425 706 6605 Fax: +1 425 936 7329
メール: bernarda@microsoft.com 電話: +1 425 706、6605Fax: +1 425 936 7329
Chiba, et al. Informational [Page 29] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
千葉、他 半径2003年7月への情報[29ページ]のRFC3576のダイナミックな承認拡張子
11. Full Copyright Statement
11. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上に承諾された限られた許容は、永久であり、そのインターネット協会、後継者または指定代理人によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Chiba, et al. Informational [Page 30]
千葉、他 情報[30ページ]
一覧
スポンサーリンク
