RFC5176 日本語訳
5176 Dynamic Authorization Extensions to Remote Authentication Dial InUser Service (RADIUS). M. Chiba, G. Dommety, M. Eklund, D. Mitton, B.Aboba. January 2008. (Format: TXT=79541 bytes) (Obsoletes RFC3576) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group M. Chiba
Request for Comments: 5176 G. Dommety
Obsoletes: 3576 M. Eklund
Category: Informational Cisco Systems, Inc.
D. Mitton
RSA, Security Division of EMC
B. Aboba
Microsoft Corporation
January 2008
コメントを求めるワーキンググループM.千葉の要求をネットワークでつないでください: 5176G.Dommetyは以下を時代遅れにします。 3576年のM.エクルンドカテゴリ: 情報のシスコシステムズInc.D.ミットンRSA、EMC B.Abobaマイクロソフト社安全保障課2008年1月
Dynamic Authorization Extensions to
Remote Authentication Dial In User Service (RADIUS)
リモート認証へのダイナミックな承認拡大はユーザでサービスにダイヤルします。(半径)
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
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 5176 Dynamic Authorization Extensions to RADIUS January 2008
千葉、他 半径2008年1月への情報[1ページ]のRFC5176のダイナミックな承認拡張子
Table of Contents
目次
1. Introduction ....................................................2
1.1. Applicability ..............................................3
1.2. Requirements Language ......................................4
1.3. Terminology ................................................4
2. Overview ........................................................4
2.1. Disconnect Messages (DMs) ..................................5
2.2. Change-of-Authorization (CoA) Messages .....................5
2.3. Packet Format ..............................................6
3. Attributes .....................................................10
3.1. Proxy State ...............................................12
3.2. Authorize Only ............................................13
3.3. State .....................................................14
3.4. Message-Authenticator .....................................15
3.5. Error-Cause ...............................................16
3.6. Table of Attributes .......................................20
4. Diameter Considerations ........................................24
5. IANA Considerations ............................................26
6. Security Considerations ........................................26
6.1. Authorization Issues ......................................26
6.2. IPsec Usage Guidelines ....................................27
6.3. Replay Protection .........................................28
7. Example Traces .................................................28
8. References .....................................................29
8.1. Normative References ......................................29
8.2. Informative References ....................................30
9. Acknowledgments ................................................30
Appendix A ........................................................31
1. 序論…2 1.1. 適用性…3 1.2. 要件言語…4 1.3. 用語…4 2. 概要…4 2.1. メッセージ(DMs)から切断してください…5 2.2. 承認の変化(CoA)メッセージ…5 2.3. パケット形式…6 3. 属性…10 3.1. プロキシ状態…12 3.2. 認可、単に…13 3.3. 状態…14 3.4. メッセージ固有識別文字…15 3.5. 誤り原因…16 3.6. 属性のテーブル…20 4. 直径問題…24 5. IANA問題…26 6. セキュリティ問題…26 6.1. 承認問題…26 6.2. IPsec用法ガイドライン…27 6.3. 保護を再演してください…28 7. 例の跡…28 8. 参照…29 8.1. 標準の参照…29 8.2. 有益な参照…30 9. 承認…30 付録A…31
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 user session(s) in progress. Alternatively, if the user changes authorization level, this may require that authorization attributes be added/deleted from user session(s).
しかしながら、変更をセッションの特性にするのが望ましい多くのインスタンスがあります、NASが交換を起こす必要でない。 例えば、管理者が進行中のユーザセッションを終えることができるのは、望ましいかもしれません。 あるいはまた、ユーザが承認レベルを変えるなら、これは、承認属性がユーザセッションから加えられるか、または削除されるのを必要とするかもしれません。
To overcome these limitations, several vendors have implemented additional RADIUS commands in order to enable unsolicited messages to be sent to the NAS. These extended commands provide support for Disconnect and Change-of-Authorization (CoA) packets. Disconnect
打ち勝つために、これらの制限、いくつかのベンダーは実装しました。お節介なメッセージがNASに送られるのを可能にするために追加RADIUSコマンドであると実装されます。 これらの拡張コマンドはDisconnectと承認のChange(CoA)パケットのサポートを提供します。 分離
Chiba, et al. Informational [Page 2] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
千葉、他 半径2008年1月への情報[2ページ]のRFC5176のダイナミックな承認拡張子
packets cause user session(s) to be terminated immediately, whereas CoA packets modify session authorization attributes such as data filters.
すぐに、パケットでユーザセッションを終えますが、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 described; see Section 6.1 for details.
このプロトコルの既存の実装は許可検査をサポートしません、別のISPとNASを共有するISPが別のISPのユーザのために承認を切断するか、または変えることができるように。 この問題を改善するために、「逆の経路推進」チェックは説明されます。 詳細に関してセクション6.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 6.2 for details.
既存の実装は知られている弱点[MD5Attack]がある1パケットあたりの認証と保全保護アルゴリズムを利用します。 1パケットあたりの、より強い認証と保全保護、IPsecの使用を提供するのはお勧めです。 詳細に関してセクション6.2を見てください。
Existing implementations lack replay protection. In order to support replay detection, it is recommended that an Event-Timestamp Attribute be added to all packets in situations where IPsec replay protection is not employed. See Section 6.3 for details.
既存の実装不足は保護を再演します。 再生検出をサポートするために、Event-タイムスタンプAttributeがIPsec反復操作による保護が採用していない状況ですべてのパケットに加えられるのは、お勧めです。 詳細に関してセクション6.3を見てください。
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 the Diameter protocol [RFC3588], in which server-initiated authorization change is initiated using a Re-Auth-Request (RAR) command identifying the session via User-Name and Session-Id Attribute Value Pairs (AVPs) and containing a Re-Auth-Request-Type AVP with value "AUTHORIZE_ONLY". This results 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.
問題はDiameterプロトコル[RFC3588]以内に存在していません。そこでは、サーバで開始している承認変化が、(AVPs)と値があるRe-Authがタイプを要求しているAVPを含んでいると「認可されるだけである」User-名前とSession-イドAttribute Valueペアでセッションを特定するRe-Auth-要求(RAR)命令を使用することで起こされます。 これは承認変化が供給される標準のRequest/応答系列の開始をもたらします。 その結果、どんなコマンドでも、Diameter AVPsは複数の潜在的意味を持つことができません。
Chiba, et al. Informational [Page 3] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
千葉、他 半径2008年1月への情報[3ページ]のRFC5176のダイナミックな承認拡張子
1.2. Requirements Language
1.2. 要件言語
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:
このドキュメントは頻繁に次の用語を使用します:
Dynamic Authorization Client (DAC)
The entity originating Change of Authorization (CoA) Requests or
Disconnect-Requests. While it is possible that the DAC is
co-resident with a RADIUS authentication or accounting server,
this need not necessarily be the case.
Authorization(CoA)要求かDisconnect-要求のダイナミックなAuthorization Client(DAC)実体起因するChange。 DACがRADIUS認証か会計サーバをもっているコレジデントであることが可能である間、これは必ずそうでなければならないというわけではありません。
Dynamic Authorization Server (DAS)
The entity receiving CoA-Request or Disconnect-Request packets.
The DAS may be a NAS or a RADIUS proxy.
ダイナミックなAuthorization Server(DAS)の実体受信CoA-要求かDisconnect-リクエスト・パケット。 DASはNASかRADIUSプロキシであるかもしれません。
Network Access Server (NAS)
The device providing access to the network.
デバイス提供がネットワークにアクセスするAccess Server(NAS)をネットワークでつないでください。
service
The NAS provides a service to the user, such as IEEE 802 or
Point-to-Point Protocol (PPP).
NASがユーザに対するPointから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によってユーザに提供されたセッションEachサービスはセッションを構成します、セッションの始まりがサービスが最初に提供されるポイントと定義されて、セッションの終わりがサービスが終わるポイントと定義されている状態で。 ユーザには、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.
さらに処理しながら、静かにThis手段を実装がパケットを捨てる捨ててください。 実装SHOULDは静かに捨てられたパケットのコンテンツを含む誤りを登録する能力を提供します、そして、SHOULDは統計カウンタに出来事を記録に残します。
2. Overview
2. 概要
This section describes the most commonly implemented features of Disconnect and Change-of-Authorization (CoA) packets.
このセクションはDisconnectと承認のChange(CoA)パケットの最も一般的に実装している特徴について説明します。
Chiba, et al. Informational [Page 4] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
千葉、他 半径2008年1月への情報[4ページ]のRFC5176のダイナミックな承認拡張子
2.1. Disconnect Messages (DMs)
2.1. メッセージから切断してください。(DMs)
A Disconnect-Request packet is sent by the Dynamic Authorization Client in order to terminate user session(s) 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(s) to be terminated by inclusion of the identification attributes described in Section 3.
Disconnect-リクエスト・パケットは、NASのユーザセッションを終えて、すべての合同会議文脈を捨てるためにDynamic Authorization Clientによって送られます。 Disconnect-リクエスト・パケットは、セクション3で説明された識別属性の包含で終えられるためにUDPポート3799に送られて、ユーザセッションと同様にNASを特定します。
+----------+ +----------+ | | Disconnect-Request | | | | <-------------------- | | | NAS | | DAC | | | Disconnect-ACK/NAK | | | | ---------------------> | | +----------+ +----------+
+----------+ +----------+ | | 分離要求| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| NAS| | DAC| | | 分離-ACK/NAK| | | | --------------------->|、| +----------+ +----------+
The NAS responds to a Disconnect-Request packet sent by a Dynamic Authorization Client with a Disconnect-ACK if all associated session context is discarded and the user session(s) are no longer connected, or a Disconnect-NAK, if the NAS was unable to disconnect one or more sessions and discard all associated session context. A Disconnect- ACK MAY contain the Acct-Terminate-Cause (49) Attribute [RFC2866] with the value set to 6 for Admin-Reset.
NASはすべての合同会議文脈が捨てられて、ユーザセッションがもう接続されないならDisconnect-ACKと共にDynamic Authorization Clientによって送られたDisconnect-リクエスト・パケット、またはDisconnect-NAKに応じます、NASが分離1か、より多くのセッションにすべての合同会議文脈を捨てるなら。 Disconnect- ACKは選択値群があるAcctが原因を終えている(49)属性[RFC2866]をAdmin-リセットのための6に含むかもしれません。
2.2. Change-of-Authorization (CoA) Messages
2.2. 承認の変化(CoA)メッセージ
CoA-Request packets contain information for dynamically changing session authorizations. Typically, this is 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 those for Disconnect-Request packets.
CoA-リクエスト・パケットはダイナミックにセッション承認を変えるための情報を含んでいます。 通常、これは、データフィルタを変えるのに使用されます。 データフィルタはイングレスか出口種類があることができて、セクション3で説明されるように識別属性に加えて送ります。 使用されるポートとパケット・フォーマット(セクション2.3では、説明される)はDisconnect-リクエスト・パケットのためのそれらと同じです。
The following attributes 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(s) that the
identification attributes map to.
フィルタID(11)--データの名前が識別属性が写像するセッションのために適用されるべきリストをフィルターにかけるのを示します。
NAS-Filter-Rule (92) - Provides a filter list to be applied for
the session(s) that the identification
attributes map to [RFC4849].
NASフィルタ規則(92)--識別属性が[RFC4849]に写像するセッションのために適用されるためにフィルタリストを提供します。
Chiba, et al. Informational [Page 5] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
千葉、他 半径2008年1月への情報[5ページ]のRFC5176のダイナミックな承認拡張子
+----------+ +----------+ | | CoA-Request | | | | <-------------------- | | | NAS | | DAC | | | CoA-ACK/NAK | | | | ---------------------> | | +----------+ +----------+
+----------+ +----------+ | | CoA-要求| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| NAS| | DAC| | | CoA-ACK/NAK| | | | --------------------->|、| +----------+ +----------+
The NAS responds to a CoA-Request sent by a Dynamic Authorization Client with a CoA-ACK if the NAS is able to successfully change the authorizations for the user session(s), or a CoA-NAK if the CoA- Request is unsuccessful. 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" SHOULD be included.
CoA要求が失敗しているならNASがユーザセッション、またはCoA-NAKのために首尾よく承認を変えることができるなら、NASはCoA-ACKと共にDynamic Authorization Clientによって送られたCoA-要求に応じます。 CoA-NAKと共にサポートされない値があるService-タイプAttributeを含んでいて、NAS MUSTはCoA-要求に応じます。 値の「サポートされないサービス」SHOULDが含まれているError-原因Attribute。
2.3. Packet Format
2.3. パケット・フォーマット
For either Disconnect-Request or CoA-Request packets 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 following 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長さの価値(TLV)の形式におけるコード、Identifier、Length、Authenticator、およびAttributes。 ものが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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 固有識別文字| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 属性… +-+-+-+-+-+-+-+-+-+-+-+-+-
Chiba, et al. Informational [Page 6] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
千葉、他 半径2008年1月への情報[6ページ]のRFC5176のダイナミックな承認拡張子
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 [RFC3575]
41 - Disconnect-ACK [RFC3575]
42 - Disconnect-NAK [RFC3575]
43 - CoA-Request [RFC3575]
44 - CoA-ACK [RFC3575]
45 - CoA-NAK [RFC3575]
40--分離要求[RFC3575]41--分離-ACK[RFC3575]42--分離-NAK[RFC3575]43--CoA-要求[RFC3575]44--CoA-ACK[RFC3575]45--CoA-NAK[RFC3575]
Identifier
識別子
The Identifier field is one octet, and aids in matching requests
and replies. A Dynamic Authorization Server implementing this
specification MUST be capable of detecting a duplicate request if
it has the same source IP address, source UDP port, and Identifier
within a short span of time.
Identifier分野は、1つの八重奏と、合っている要求と回答で援助です。 それが短い期間の中に同じソースIPアドレス、ソースUDP港、およびIdentifierを持っているなら、この仕様を履行するDynamic Authorization Serverは写し要求を検出できなければなりません。
The responsibility for retransmission of Disconnect-Request and
CoA-Request packets lies with the Dynamic Authorization Client.
If after sending these packets, the Dynamic Authorization Client
does not receive a response, it will retransmit.
Dynamic Authorization ClientにはDisconnect-要求とCoA-リクエスト・パケットの「再-トランスミッション」への責任があります。 これらのパケットを送った後にDynamic Authorization Clientが応答を受けないと、それは再送されるでしょう。
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 Dynamic Authorization Client is retransmitting a
Disconnect-Request or CoA-Request to the same Dynamic
Authorization Server as before, and the attributes haven't
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.
Dynamic Authorization Clientが従来と同様Disconnect-要求かCoA-要求を同じDynamic Authorization Serverに再送していて、属性が変化していないなら、同じRequest Authenticator、Identifier、およびソースポートを使用しなければなりません。 何か属性が変化したなら、新しいAuthenticatorとIdentifierを使用しなければなりません。
If the Request to a primary Dynamic Authorization Server fails, a
secondary Dynamic Authorization Server must be queried, if
available; issues relating to failover algorithms are described in
[RFC3539]. Since this represents a new request, a new Request
Authenticator and Identifier MUST be used. However, where the
Dynamic Authorization Client is sending directly to the NAS,
failover typically does not make sense, since CoA-Request or
Disconnect-Request packets need to be delivered to the NAS where
the session resides.
プライマリDynamic Authorization ServerへのRequestが失敗するなら、セカンダリDynamic Authorization Serverは質問されていて、利用可能であるに違いありません。 フェイルオーバーアルゴリズムに関連する問題が[RFC3539]で説明されます。 これが新しい要求を表すので、新しいRequest AuthenticatorとIdentifierを使用しなければなりません。 しかしながら、Dynamic Authorization ClientがNASに直送しているところでは、フェイルオーバーは通常理解できません、CoA-要求かDisconnect-リクエスト・パケットが、セッションがあるNASに提供される必要があるので。
Chiba, et al. Informational [Page 7] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
千葉、他 半径2008年1月への情報[7ページ]のRFC5176のダイナミックな承認拡張子
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 maximum length
is 4096.
Length分野は2つの八重奏です。 それはCode、Identifier、Length、Authenticator、およびAttribute分野を含むパケットの長さを示します。 Length分野の範囲の外での八重奏を詰め物として扱われて、レセプションで無視しなければなりません。 パケットがLength分野が示すより脆いなら、静かにそれを捨てなければなりません。 最小の長さは20です、そして、最大の長さは4096です。
Authenticator
固有識別文字
The Authenticator field is sixteen (16) octets. The most
significant octet is transmitted first. This value is used to
authenticate packets between the Dynamic Authorization Client and
the Dynamic Authorization Server.
Authenticator分野は16(16)八重奏です。 最も重要な八重奏は最初に、伝えられます。 この値は、Dynamic Authorization ClientとDynamic Authorization Serverの間のパケットを認証するのに使用されます。
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 CoA-Request or
Disconnect-Request cannot be computed the same way as the
Request Authenticator of a RADIUS Access-Request, because there
is no User-Password Attribute in a CoA-Request or Disconnect-
Request.
RADIUS Access-要求のRequest Authenticatorとして同じようにCoA-要求かDisconnect-要求のRequest Authenticatorを計算できないことに注意してください、CoA-要求かDisconnectのAttributeが要求するUser-パスワードが全くないので。
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分野、およびもしあれば応答属性は共有秘密キーで続きました。 結果として起こる16八重奏のMD5ハッシュ値はResponseパケットのAuthenticator分野に保存されます。
Administrative note: As noted in [RFC2865], Section 3, the secret
(password shared between the Dynamic Authorization Client and the
Dynamic Authorization Server) SHOULD be at least as large and
unguessable as a well-chosen password. The Dynamic Authorization
管理注意: [RFC2865]、セクション3に述べられるように、秘密(パスワードはDynamic Authorization ClientとDynamic Authorization Serverを平等に割り当てた)のSHOULDは少なくとも同じくらい大きく、適切なパスワードとして「蹄-可能」します。 ダイナミックな承認
Chiba, et al. Informational [Page 8] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
千葉、他 半径2008年1月への情報[8ページ]のRFC5176のダイナミックな承認拡張子
Server MUST use the source IP address of the RADIUS UDP packet to
decide which shared secret to use, so that requests can be
proxied.
サーバはどの共有秘密キーを使用したらよいかを決めるのにRADIUS UDPパケットのソースIPアドレスを使用しなければなりません、要求をproxiedされることができるように。
Attributes
属性
In CoA-Request and Disconnect-Request packets, all attributes MUST
be treated as mandatory. If one or more authorization changes
specified in a CoA-Request cannot be carried out, the NAS MUST
send a CoA-NAK. A NAS MUST respond to a CoA-Request containing
one or more unsupported attributes or Attribute values with a
CoA-NAK; an Error-Cause Attribute with value 401 (Unsupported
Attribute) or 407 (Invalid Attribute Value) MAY be included. A
NAS MUST respond to a Disconnect-Request containing one or more
unsupported attributes or Attribute values with a Disconnect-NAK;
an Error-Cause Attribute with value 401 (Unsupported Attribute) or
407 (Invalid Attribute Value) MAY be included.
CoA-要求とDisconnect-リクエスト・パケットでは、義務的であるとしてすべての属性を扱わなければなりません。 CoA-要求で指定された1回以上の承認変化を行うことができないなら、NAS MUSTはCoA-NAKを送ります。 CoA-NAKがある1つ以上のサポートされない属性かAttribute値を含んでいて、NAS MUSTはCoA-要求に応じます。 値401(サポートされないAttribute)か407(無効のAttribute Value)があるError-原因Attributeは含まれるかもしれません。 Disconnect-NAKがある1つ以上のサポートされない属性かAttribute値を含んでいて、NAS MUSTはDisconnect-要求に応じます。 値401(サポートされないAttribute)か407(無効のAttribute Value)があるError-原因Attributeは含まれるかもしれません。
State changes resulting from a CoA-Request MUST be atomic: if the
CoA-Request is successful for all matching sessions, the NAS MUST
send a CoA-ACK in reply, and all requested authorization changes
MUST be made. If the CoA-Request is unsuccessful for any matching
sessions, the NAS MUST send a CoA-NAK in reply, and the requested
authorization changes MUST NOT be made for any of the matching
sessions. Similarly, a state change MUST NOT occur as a result of
a Disconnect-Request that is unsuccessful with respect to any of
the matching sessions; a NAS MUST send a Disconnect-NAK in reply
if any of the matching sessions cannot be successfully terminated.
A NAS that does not support dynamic authorization changes applying
to multiple sessions MUST send a CoA-NAK or Disconnect-NAK in
reply; an Error-Cause Attribute with value 508 (Multiple Session
Selection Unsupported) SHOULD be included.
CoA-要求から生じる州の変化は原子であるに違いありません: CoA-要求がすべての合っているセッションにうまくいくなら、NAS MUSTは回答でCoA-ACKを送ります、そして、すべてが承認変更を行わなければならないよう要求しました。 CoA-要求がどんな合っているセッションのためにも失敗しているなら、NAS MUSTは回答でCoA-NAKを送ります、そして、要求された承認変更は合っているセッションのいずれのためにも行われてはいけません。 同様に、州の変化は合っているセッションのいずれに関しても失敗のDisconnect-要求の結果、起こってはいけません。 首尾よく合っているセッションのどれかを終えることができないなら、NAS MUSTは回答でDisconnect-NAKを送ります。 複数のセッションに適用されるダイナミックな承認変化をサポートしないNASは回答でCoA-NAKかDisconnect-NAKを送らなければなりません。 値508(複数のSession Selection Unsupported)のSHOULDが含まれているError-原因Attribute。
Within this specification, attributes can be used for
identification, authorization, or other purposes. RADIUS
Attribute specifications created after publication of this
document SHOULD state whether an attribute can be included in CoA
or Disconnect messages, and if so, which messages it can be
included in and whether it serves as an identification or
authorization attribute.
この仕様の中では、識別、承認、または他の目的に属性を使用できます。 このドキュメントSHOULDの公表の後に作成されたRADIUS Attribute仕様はそうだとすれば、CoAかDisconnectメッセージに属性を含むことができるかどうかと、どのメッセージでそれを含むことができるか、そして、それが識別か承認属性として機能するかどうかと述べます。
Even if a NAS implements an attribute for use with RADIUS
authentication and accounting, it is possible that it will not
support inclusion of that attribute within CoA-Request and
Disconnect-Request packets, given the difference in attribute
semantics. This is true even for attributes specified as
NASが使用のためにRADIUS認証と会計で属性を実装しても、CoA-要求とDisconnect-リクエスト・パケットの中でその属性の包含をサポートしないのは、可能です、属性意味論の違いを考えて。 指定された属性にさえ、これは本当です。
Chiba, et al. Informational [Page 9] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
千葉、他 半径2008年1月への情報[9ページ]のRFC5176のダイナミックな承認拡張子
allowable within Access-Accept packets (such as those defined
within [RFC2865], [RFC2868], [RFC2869], [RFC3162], [RFC3579],
[RFC4372], [RFC4675], [RFC4818], and [RFC4849]).
Access受け入れているパケット([RFC2865]、[RFC2868]、[RFC2869]、[RFC3162]、[RFC3579]、[RFC4372]、[RFC4675]、[RFC4818]、および[RFC4849]の中で定義されたものなどの)の中で許容できます。
3. Attributes
3. 属性
In Disconnect-Request and CoA-Request packets, certain attributes are used to uniquely identify the NAS as well as user session(s) on the NAS. The combination of NAS and session identification attributes included in a CoA-Request or Disconnect-Request packet MUST match at least one session in order for a Request to be successful; otherwise a Disconnect-NAK or CoA-NAK MUST be sent. If all NAS identification attributes match, and more than one session matches all of the session identification attributes, then a CoA-Request or Disconnect- Request MUST apply to all matching sessions.
Disconnect-要求とCoA-リクエスト・パケットでは、ある属性は、また、NASがNASのユーザセッションであると唯一認識するのに使用されます。 CoA-要求かDisconnect-リクエスト・パケットに属性を含んでいるNASとセッション識別の組み合わせはうまくいくためにRequestにおいて、整然としている少なくとも1つのセッションに合わなければなりません。 さもなければ、Disconnect-NAKかCoA-NAKを送らなければなりません。 すべてのNAS識別属性が合っていて、1つ以上のセッションがセッション識別属性のすべてに合っているなら、CoA-要求かDisconnect要求がすべての合っているセッションに適用されなければなりません。
Identification attributes include NAS and session identification attributes, as described below.
識別属性は以下で説明されるように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.
属性#参照記述--------- --- --------- ----------- IPv4が扱うNAS IPアドレス4[RFC2865]、NASについて。 NASを特定するNAS-識別子32[RFC2865]ストリング。 95をNAS-IPv6扱ってください。NASの[RFC3162]IPv6アドレス。
Session identification attributes
セッション識別属性
Attribute # Reference Description
--------- --- --------- -----------
User-Name 1 [RFC2865] The name of the user
associated with one or
more sessions.
NAS-Port 5 [RFC2865] The port on which a
session is terminated.
Framed-IP-Address 8 [RFC2865] The IPv4 address associated
with a session.
Vendor-Specific 26 [RFC2865] One or more vendor-specific
identification attributes.
Called-Station-Id 30 [RFC2865] The link address to which
a session is connected.
Calling-Station-Id 31 [RFC2865] The link address from which
one or more sessions are
connected.
Acct-Session-Id 44 [RFC2866] The identifier uniquely
identifying a session
on the NAS.
属性#参照記述--------- --- --------- ----------- ユーザの名前が1つ以上のセッションに関連づけたユーザ名の1[RFC2865]。 5をNAS移植してください。セッションが終えられる[RFC2865]ポート。 IPv4が扱う縁どられたIPアドレス8[RFC2865]はセッションと交際しました。 ベンダー特有の26[RFC2865]の1つ以上のベンダー特有の識別属性。 セッションがどれであるかと接続されて、リンクが扱う呼ばれた駅のイド30[RFC2865]。 リンクがどの1つ以上のセッションから扱う呼んでいる駅のイド31[RFC2865]は接続されています。 Acctセッションイド、44 [RFC2866] 唯一NASのセッションを特定する識別子。
Chiba, et al. Informational [Page 10] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
千葉、他 半径2008年1月への情報[10ページ]のRFC5176のダイナミックな承認拡張子
Acct-Multi-Session-Id 50 [RFC2866] The identifier uniquely
identifying related sessions.
NAS-Port-Id 87 [RFC2869] String identifying the port
where a session is.
Chargeable-User- 89 [RFC4372] The CUI associated with one
Identity or more sessions. Needed
where a privacy Network
Access Identifier (NAI) is
used, since in this case the
User-Name (e.g., "anonymous")
may not identify sessions
belonging to a given user.
Framed-Interface-Id 96 [RFC3162] The IPv6 Interface Identifier
associated with a session,
always sent with
Framed-IPv6-Prefix.
Framed-IPv6-Prefix 97 [RFC3162] The IPv6 prefix associated
with a session, always sent
with Framed-Interface-Id.
AcctのマルチSessionのイド、50 [RFC2866] 唯一関連するセッションを特定する識別子。 セッションがそうであるポートを特定するNASポートイド87[RFC2869]ストリング。 CUIが1Identityのセッションに関連づけた請求できるユーザ-89[RFC4372]。 User-名前(例えば、「匿名」)がこの場合与えられたユーザのものであるセッションを特定しないかもしれないので、プライバシーNetwork Access Identifier(NAI)が使用されているところで必要です。 Framed-IPv6-接頭語と共にいつも送って、IPv6 Interface Identifierがセッションに関連づけた縁どられたインタフェースイド96[RFC3162]。 Framedインタフェースアイダホ州と共にいつも送って、IPv6接頭語がセッションに関連づけた縁どられたIPv6接頭語97[RFC3162]
To address security concerns described in Section 6.1, either the User-Name or Chargeable-User-Identity attribute SHOULD be present in Disconnect-Request and CoA-Request packets.
セキュリティがセクション6.1(User-名前かChargeableユーザのアイデンティティ属性SHOULDのどちらか)で説明された関心であると扱うには、Disconnect-要求とCoA-リクエスト・パケットに存在してください。
Where a Diameter client utilizes the same Session-Id for both authorization and accounting, inclusion of an Acct-Session-Id Attribute in a Disconnect-Request or CoA-Request can assist with Diameter/RADIUS translation, since Diameter RAR and ASR commands include a Session-Id AVP. An Acct-Session-Id Attribute SHOULD be included in Disconnect-Request and CoA-Request packets.
Diameterクライアントが同じSession-イドを承認と会計の両方に利用するところでは、Disconnect-要求かCoA-要求でのAcctセッションイドAttributeの包含はDiameter/RADIUS翻訳を助けることができます、Diameter RARとASRコマンドがSession-イドAVPを含んでいるので。 AcctセッションイドAttribute SHOULD、Disconnect-要求とCoA-リクエスト・パケットで含められてください。
A NAS implementing this specification SHOULD send an Acct-Session-Id or Acct-Multi-Session-Id Attribute within an Access-Request. Where an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not included within an Access-Request, the Dynamic Authorization Client will not know the Acct-Session-Id or Acct-Multi-Session-Id of the session it is attempting to target, unless it also has access to the accounting data for that session.
この仕様がSHOULDであると実装するNASはAccess-要求の中でAcctセッションイドかAcctのマルチSessionのイドAttributeを送ります。 AcctセッションイドかAcctのマルチSessionのイドAttributeがAccess-要求の中に含まれていないところでは、Dynamic Authorization Clientはそれが狙うのを試みているセッションのAcctセッションイドかAcctのマルチSessionのイドを知らないでしょう、また、そのセッションのための会計データに近づく手段を持っていない場合。
Where an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not present in a CoA-Request or Disconnect-Request, it is possible that the User-Name or Chargeable-User-Identity attributes will not be sufficient to uniquely identify a single session (e.g., if the same user has multiple sessions on the NAS, or if the privacy NAI is used). In this case, if it is desired to identify a single session, session identification MAY be performed by using one or more of the Framed-IP-Address, Framed-IPv6-Prefix/Framed-Interface-Id, Called- Station-Id, Calling-Station-Id, NAS-Port, and NAS-Port-Id attributes.
AcctセッションイドかAcctのマルチSessionのイドAttributeがCoA-要求かDisconnect-要求に存在していないところでは、User-名前かChargeableユーザのアイデンティティ属性が唯一ただ一つのセッションを特定できないくらい(例えば、同じユーザにNASの複数のセッションがあるか、またはプライバシーNAIが使用されているなら)可能です。 この場合、ただ一つのセッションを特定するのが必要であるなら、セッション識別は、Framed IPアドレス(縁どられたインタフェースFramed-IPv6-接頭語/イド、Called駅イド、Calling駅のイド、NAS-ポート、およびNASポートイド属性)の1つ以上を使用することによって、実行されるかもしれません。
Chiba, et al. Informational [Page 11] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
千葉、他 半径2008年1月への情報[11ページ]のRFC5176のダイナミックな承認拡張子
To assist RADIUS proxies in routing Request packets to their destination, one or more of the NAS-IP-Address or NAS-IPv6-Address attributes SHOULD be present in CoA-Request and Disconnect-Request packets; the NAS-Identifier Attribute MAY be present. Impersonation issues with NAS Identification attributes are discussed in [RFC3579], Section 4.3.7.
NAS IPアドレスのそれらの目的地、1つまたは以上へのルーティングRequestパケットのRADIUSプロキシかNAS-IPv6-アドレス属性SHOULDを補助するには、CoA-要求とDisconnect-リクエスト・パケットに存在してください。 NAS-識別子Attributeは存在しているかもしれません。 [RFC3579]、セクション4.3.7でNAS Identification属性のものまね問題について議論します。
A Disconnect-Request MUST contain only NAS and session identification attributes. If other attributes are included in a Disconnect- Request, implementations MUST send a Disconnect-NAK; an Error-Cause Attribute with value "Unsupported Attribute" MAY be included.
Disconnect-要求はNASとセッション識別属性だけを含まなければなりません。 他の属性がDisconnect要求に含まれているなら、実装はDisconnect-NAKを送らなければなりません。 値があるError-原因Attribute「サポートされない属性」は含まれるかもしれません。
The DAC may require access to data from RADIUS authentication or accounting packets. It uses this data to compose compliant CoA- Request or Disconnect-Request packets. For example, as described in Section 3.3, a CoA-Request packet containing a Service-Type Attribute with a value of "Authorize Only" is required to contain a State Attribute. The NAS will subsequently transmit this attribute to the RADIUS server in an Access-Request. In order for the DAC to include a State Attribute that the RADIUS server will subsequently accept, some coordination between the two parties may be required.
DACはRADIUS認証か会計パケットからのデータへのアクセスを必要とするかもしれません。 それは、対応するCoA要求かDisconnect-リクエスト・パケットを構成するのにこのデータを使用します。 例えば、セクション3.3で説明されるような値があるService-タイプAttributeを含むCoA-リクエスト・パケット、「認可、唯一、」 州Attributeを含むのが必要です。 NASは次に、Access-要求におけるRADIUSサーバにこの属性を伝えるでしょう。 DACがRADIUSサーバが次に受け入れる州Attributeを含むように、2回のパーティーの間の何らかのコーディネートが必要であるかもしれません。
This coordination can be achieved in multiple ways. The DAC may be co-located with a RADIUS server, in which case it is presumed to have access to the necessary data. The RADIUS server may also store that information in a common database. The DAC can then be separated from the RADIUS server, so long as it has access to that common database.
複数の方法でこのコーディネートを達成できます。 DACはRADIUSサーバで共同見つけられるかもしれません、その場合、必要なデータがあえてそれに近づく手段を持たれています。 また、RADIUSサーバは一般的なデータベースにその情報を保存するかもしれません。 そして、その一般的なデータベースに近づく手段を持っている限り、RADIUSサーバとDACを切り離すことができます。
Where the DAC is not co-located with a RADIUS server, and does not have access to a common database, the DAC SHOULD send CoA-Request or Disconnect-Request packets to a RADIUS server acting as a proxy, rather than sending them directly to the NAS.
DACがRADIUSサーバで共同見つけられていなくて、また一般的なデータベースに近づく手段を持っていないところでは、DAC SHOULDは直接NASに彼らを送るよりプロキシとしてむしろ務めるRADIUSサーバにCoA-要求かDisconnect-リクエスト・パケットを送ります。
A RADIUS server receiving a CoA-Request or Disconnect-Request packet from the DAC MAY then add or update attributes (such as adding NAS or session identification attributes or appending a State Attribute), prior to forwarding the packet. Having CoA/Disconnect-Requests forwarded by a RADIUS server can also enable upstream RADIUS proxies to perform a Reverse Path Forwarding (RPF) check (see Section 6.1).
その時DAC MAYからCoA-要求かDisconnect-リクエスト・パケットを受け取るRADIUSサーバは、属性(NASかセッション識別属性を加えるか、または州Attributeを追加などなどの)を加えるか、またはアップデートします、パケットを進める前に。 また、RADIUSサーバで分離CoA/要求を転送させるのは、上流のRADIUSプロキシがReverse Path Forwarding(RPF)チェックを実行するのを可能にすることができます(セクション6.1を見てください)。
3.1. Proxy State
3.1. プロキシ状態
If there are any Proxy-State attributes in a Disconnect-Request or CoA-Request received from the Dynamic Authorization Client, the Dynamic Authorization Server MUST include those Proxy-State attributes in its response to the Dynamic Authorization Client.
Dynamic Authorization Clientから受け取られたDisconnect-要求かCoA-要求に何かProxy-州の属性があれば、Dynamic Authorization ServerはDynamic Authorization Clientへの応答にそれらのProxy-州の属性を含まなければなりません。
Chiba, et al. Informational [Page 12] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
千葉、他 半径2008年1月への情報[12ページ]のRFC5176のダイナミックな承認拡張子
A forwarding proxy or NAS MUST NOT modify existing Proxy-State, State, or Class attributes present in the packet. The forwarding proxy or NAS MUST treat any Proxy-State attributes already in the packet as opaque data. Its operation MUST NOT depend on the content of Proxy-State attributes added by previous proxies. The forwarding proxy MUST NOT modify any other Proxy-State attributes that were in the packet; it may choose not to forward them, but it MUST NOT change their contents. If the forwarding proxy omits the Proxy-State attributes in the request, it MUST attach them to the response before sending it.
推進プロキシかNAS MUST NOTがパケットの現在の既存のProxy-状態、州、またはClass属性を変更します。 推進のプロキシかNAS MUSTが不明瞭なデータとして既にパケットでどんなProxy-州の属性も扱います。 操作は前のプロキシによって加えられたProxy-州の属性の内容によってはいけません。 推進プロキシはパケットにあったいかなる他のProxy-州の属性も変更してはいけません。 それらを進めないのを選ぶかもしれませんが、それはそれらのコンテンツを変えてはいけません。 推進プロキシが要求におけるProxy-州の属性を省略するなら、それを送る前に、それはそれらを応答に付けなければなりません。
When the proxy forwards a Disconnect-Request or CoA-Request, it MAY add a Proxy-State Attribute, but it MUST NOT add more than one. If a Proxy-State Attribute is added to a packet when forwarding the packet, the Proxy-State Attribute MUST be added after any existing Proxy-State attributes. The forwarding proxy MUST NOT change the order of any attributes of the same type, including Proxy-State. Other attributes can be placed before, after, or even between the Proxy-State attributes.
プロキシがDisconnect-要求かCoA-要求を転送するとき、Proxy-州のAttributeを加えるかもしれませんが、それは1つ以上を加えてはいけません。 パケットを進めるとき、Proxy-州のAttributeがパケットに加えられるなら、どんな既存のProxy-州の属性の後にもProxy-州のAttributeを加えなければなりません。 推進プロキシはProxy-状態を含む同じタイプのどんな属性の注文も変えてはいけません。 属性の後か属性の前かProxy-州の属性の間にさえ他の属性を置くことができます。
When the proxy receives a response to a CoA-Request or Disconnect- Request, it MUST remove its own Proxy-State Attribute (the last Proxy-State in the packet) before forwarding the response. 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 MUST recompute it.
プロキシがCoA-要求かDisconnect要求への応答を受けるとき、応答を進める前に、それはそれ自身のProxy-州のAttribute(パケットにおける最後のProxy-状態)を取り外さなければなりません。 DisconnectとCoA応答が全体のパケットコンテンツで認証されるので、Proxy-州のAttributeのストリップが保全チェックを無効にするので、プロキシはそれを再計算しなければなりません。
3.2. Authorize Only
3.2. 認可、唯一
To simplify translation between RADIUS and Diameter, Dynamic Authorization Clients can include a Service-Type Attribute with value "Authorize Only" within a CoA-Request; see Section 4 for details on Diameter considerations. Support for a CoA-Request including a Service-Type Attribute with value "Authorize Only" is OPTIONAL on the NAS and Dynamic Authorization Client. A Service-Type Attribute MUST NOT be included within a Disconnect-Request.
RADIUSとDiameterの間の翻訳を簡素化するために、Dynamic Authorization Clientsが値があるService-タイプAttributeを含むことができる、「認可、唯一、」 CoA-要求の中で。 Diameter問題に関する詳細に関してセクション4を見てください。 値があるService-タイプAttributeを含むCoA-要求のサポート、「認可、唯一、」 OPTIONALがNASとDynamic Authorization Clientにありますか? Disconnect-要求の中にService-タイプAttributeを含んではいけません。
A NAS MUST respond to a CoA-Request including a Service-Type Attribute with value "Authorize Only" with a CoA-NAK; a CoA-ACK MUST NOT be sent. If the NAS does not support a Service-Type value of "Authorize Only", then it MUST respond with a CoA-NAK; an Error-Cause Attribute with a value of 405 (Unsupported Service) SHOULD be included.
値があるService-タイプAttributeを含んでいて、A NAS MUSTがCoA-要求に応じる、「認可、唯一、」 CoA-NAKと共に。 CoA-ACKを送ってはいけません。 NASがService-タイプ値をサポートしない、「認可、単に」、次に、CoA-NAKと共に応じなければなりません。 405(サポートされないService)SHOULDの値が含まれているError-原因Attribute。
A CoA-Request containing a Service-Type Attribute with value "Authorize Only" MUST in addition contain only NAS or session identification attributes, as well as a State Attribute. If other
値があるService-タイプAttributeを含むCoA-要求、「認可、唯一、」 さらに、NASかセッション識別属性と、州Attributeだけを含まなければなりません。 他
Chiba, et al. Informational [Page 13] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
千葉、他 半径2008年1月への情報[13ページ]のRFC5176のダイナミックな承認拡張子
attributes are included in such a CoA-Request, a CoA-NAK MUST be sent; an Error-Cause Attribute with value 401 (Unsupported Attribute) SHOULD be included.
そのようなCoA-要求に属性を含んで、CoA-NAKを送らなければなりません。 値401(サポートされないAttribute)のSHOULDが含まれているError-原因Attribute。
If a CoA-Request packet including a Service-Type value of "Authorize Only" is successfully processed, the NAS MUST respond with a CoA-NAK containing a Service-Type Attribute with value "Authorize Only", and an Error-Cause Attribute with value 507 (Request Initiated). The NAS then MUST send an Access-Request to the RADIUS server including a Service-Type Attribute with value "Authorize Only", along with a State Attribute. This Access-Request SHOULD contain the NAS identification attributes from the CoA-Request, as well as the session identification attributes from the CoA-Request permitted in an Access-Request; it also MAY contain other attributes permitted in an Access-Request.
Service-タイプ値を含むCoA-リクエスト・パケットである、「認可、単に」、首尾よく処理されています、a CoA-NAKがService-タイプAttributeを含んでいてNAS MUSTが値で応じるということである、「値507で」 Error-原因Attributeだけを認可してください(Initiatedを要求してください)。 次に、NASが値があるService-タイプAttributeを含むRADIUSサーバにAccess-要求を送らなければならない、「認可、単に」、州Attributeと共に。 このAccess-要求SHOULDはCoA-要求からのNAS識別属性を含んでいます、Access-要求で受入れられたCoA-要求からのセッション識別属性と同様に。 また、それはAccess-要求で受入れられた他の属性を含むかもしれません。
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 then will respond to the Access-Request with an Access-Accept to (re-)authorize the session or an Access- Reject to refuse to (re-)authorize it.
[RFC2869]、セクション5.19、Message-固有識別文字属性SHOULDでUser-パスワード、CHAP-パスワード、ARAP-パスワード、またはEAP-メッセージAttributeを含まないAccess-要求で含められるように注意するので。 次に、RADIUSサーバがAccess-要求に応じる、Access受け入れてください、(再、)、セッションかAccess廃棄物が、拒否するのを認可してください、(再、)、それを認可してください。
3.3. State
3.3. 状態
The State Attribute is available to be sent by the Dynamic Authorization Client to the NAS in a CoA-Request packet and MUST be sent unmodified from the NAS to the Dynamic Authorization Client in a subsequent ACK or NAK packet.
Attributeが利用可能である州をDynamic Authorization ClientがCoA-リクエスト・パケットでNASに送って、その後のACKかNAKパケットでNASからDynamic Authorization Clientまで変更されていなく送らなければなりません。
[RFC2865], Section 5.44 states:
[RFC2865]、セクション5.44は以下を述べます。
An Access-Request MUST contain either a User-Password or a
CHAP-Password or State. An Access-Request MUST NOT contain both a
User-Password and a CHAP-Password. If future extensions allow
other kinds of authentication information to be conveyed, the
attribute for that can be used in an Access-Request instead of
User-Password or CHAP-Password.
Access-要求はUser-パスワードかCHAP-パスワードか州のどちらかを含まなければなりません。 Access-要求はUser-パスワードとCHAP-パスワードの両方を含んではいけません。 今後の拡大が、他の種類に関する認証情報が伝えられるのを許容するなら、User-パスワードかCHAP-パスワードの代わりにAccess-要求でそれのための属性を使用できます。
In order to satisfy the requirements of [RFC2865], Section 5.44, an Access-Request with Service-Type Attribute with value "Authorize Only" MUST contain a State Attribute.
値で[RFC2865]、セクション5.44、Access-要求の要件をService-タイプAttributeに満たす、「認可、唯一、」 州Attributeを含まなければなりません。
In order to provide a State Attribute to the NAS, a Dynamic Authorization Client sending a CoA-Request with a Service-Type Attribute with a value of "Authorize Only" MUST include a State Attribute, and the NAS MUST send the State Attribute unmodified to the RADIUS server in the resulting Access-Request, if any. A NAS
値があるService-タイプAttributeとのCoA-要求を送りながらNASへのAttribute、Dynamic Authorization Clientを州に提供する、「認可、単に」、インクルードa州Attribute、およびNAS MUSTはもしあれば結果として起こるAccess-要求におけるRADIUSサーバに変更されていない州Attributeを送らなければなりません。 NAS
Chiba, et al. Informational [Page 14] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
千葉、他 半径2008年1月への情報[14ページ]のRFC5176のダイナミックな承認拡張子
receiving a CoA-Request containing a Service-Type Attribute with a value of "Authorize Only" but lacking a State Attribute MUST send a CoA-NAK and SHOULD include an Error-Cause Attribute with a value of 402 (Missing Attribute).
値があるService-タイプAttributeを含んでいて、CoA-要求を受け取る、「」 州Attributeがa CoA-NAKを送らなければならない欠けだけを認可してください。そうすれば、SHOULDは402(なくなったAttribute)の値があるError-原因Attributeを含んでいます。
The State Attribute is also available to be sent by the Dynamic Authorization Client to the NAS in a CoA-Request that also includes a Termination-Action Attribute with the value of RADIUS-Request. If the NAS performs the Termination-Action by sending a new Access- Request upon termination of the current session, it MUST include the State Attribute unchanged in that Access-Request. In either usage, the Dynamic Authorization Server MUST NOT interpret the Attribute locally. A CoA-Request packet MUST have only zero or one State Attribute. Usage of the State Attribute is implementation dependent.
また、Dynamic Authorization Clientによってまた、RADIUS-要求の値があるTermination-動作Attributeを含んでいるCoA-要求におけるNASに送られるように、州Attributeも利用可能です。 NASが新しいAccess要求を現在のセッションの終了に送ることによってTermination-動作を実行するなら、それはそのAccess-要求で変わりのない州Attributeを含まなければなりません。 用法で、Dynamic Authorization Serverは局所的にAttributeを解釈してはいけません。 CoA-リクエスト・パケットには、ゼロか1州Attributeしかあってはいけません。 州Attributeの使用法は実装に依存しています。
3.4. Message-Authenticator
3.4. メッセージ固有識別文字
The Message-Authenticator Attribute MAY be used to authenticate and integrity-protect CoA-Request, CoA-ACK, CoA-NAK, Disconnect-Request, Disconnect-ACK, and Disconnect-NAK packets in order to prevent spoofing.
Message-固有識別文字Attributeは、だますのを防ぐためにCoA-要求、CoA-ACK、CoA-NAK、Disconnect-要求、Disconnect-ACK、およびDisconnect-NAKパケットを認証して、保全して保護するのに使用されるかもしれません。
A Dynamic Authorization Server receiving a CoA-Request or Disconnect-Request with a Message-Authenticator Attribute present MUST calculate the correct value of the Message-Authenticator and silently discard the packet if it does not match the value sent. A Dynamic Authorization Client receiving a CoA/Disconnect-ACK or CoA/Disconnect-NAK with a Message-Authenticator Attribute present MUST calculate the correct value of the Message-Authenticator and silently discard the packet if it does not match the value sent.
送られた値を合わせないなら、Message-固有識別文字Attributeが存在していた状態でCoA-要求かDisconnect-要求を受け取るDynamic Authorization ServerはMessage-固有識別文字の正しい値について計算して、静かにパケットを捨てなければなりません。 送られた値を合わせないなら、Message-固有識別文字Attributeが存在していた状態で分離CoA/ACKか分離CoA/NAKを受けるDynamic Authorization ClientはMessage-固有識別文字の正しい値について計算して、静かにパケットを捨てなければなりません。
When a Message-Authenticator Attribute is included within a CoA- Request or Disconnect-Request, it is calculated as follows:
Message-固有識別文字AttributeがCoA要求かDisconnect-要求の中に含まれているとき、それは以下の通り計算されます:
Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
Request Authenticator, Attributes)
メッセージ固有識別文字=HMAC-MD5(タイプ、識別子、長さ、要求固有識別文字、属性)
When the HMAC-MD5 message integrity check is calculated the
Request Authenticator field and Message-Authenticator Attribute
MUST each be considered to be sixteen octets of zero. The
Message-Authenticator Attribute is calculated and inserted in the
packet before the Request Authenticator is calculated.
HMAC-MD5メッセージの保全チェックが計算されるとき、ゼロの16の八重奏であるとそれぞれRequest Authenticator分野とMessage-固有識別文字Attributeを考えなければなりません。 Request Authenticatorが計算される前に、Message-固有識別文字Attributeはパケットに計算されて、挿入されます。
Chiba, et al. Informational [Page 15] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
千葉、他 半径2008年1月への情報[15ページ]のRFC5176のダイナミックな承認拡張子
When a Message-Authenticator Attribute is included within a CoA-
ACK, CoA-NAK, Disconnect-ACK, or Disconnect-NAK, it is calculated
as follows:
Message-固有識別文字AttributeがCoA- ACK、CoA-NAK、Disconnect-ACK、またはDisconnect-NAKの中に含まれているとき、それは以下の通り計算されます:
Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
Request Authenticator, Attributes)
メッセージ固有識別文字=HMAC-MD5(タイプ、識別子、長さ、要求固有識別文字、属性)
When the HMAC-MD5 message integrity check is calculated, the
Message-Authenticator Attribute MUST be considered to be sixteen
octets of zero. The Request Authenticator is taken from the
corresponding CoA/Disconnect-Request. The Message-Authenticator
is calculated and inserted in the packet before the Response
Authenticator is calculated.
HMAC-MD5メッセージの保全チェックが計算されるとき、ゼロの16の八重奏であるとMessage-固有識別文字Attributeを考えなければなりません。 Request Authenticatorは対応する分離CoA/要求から抜粋されます。 Response Authenticatorが計算される前に、Message-固有識別文字は、パケットに計算されて、挿入されます。
3.5. Error-Cause
3.5. 誤り原因
Description
記述
It is possible that a Dynamic Authorization Server cannot honor
Disconnect-Request or CoA-Request packets for some reason. The
Error-Cause Attribute provides more detail on the cause of the
problem. It MAY be included within CoA-NAK and Disconnect-NAK
packets.
Dynamic Authorization Serverがある理由でDisconnect-要求かCoA-リクエスト・パケットを光栄に思うことができないのは、可能です。 Error-原因Attributeは問題の原因に関するその他の詳細を提供します。 それはCoA-NAKとDisconnect-NAKパケットの中に含まれるかもしれません。
A summary of the Error-Cause Attribute format is shown below. The
fields are transmitted from left to right.
Error-原因Attribute形式の概要は以下に示されます。 野原は左から右まで伝えられます。
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 値の+++++++++++++++++++++++++++++++++値(cont)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
101 for Error-Cause
101 誤り原因のために
Length
長さ
6
6
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
Value分野は誤りの原因を指定する整数を含む4つの八重奏です。 値0-199と300-399は予約されています。 値200-299が無事終了を表して、そうがそれである、これら
Chiba, et al. Informational [Page 16] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
千葉、他 半径2008年1月への情報[16ページ]のRFC5176のダイナミックな承認拡張子
values may only be sent within CoA-ACK or Disconnect-ACK packets
and MUST NOT be sent within a CoA-NAK or Disconnect-NAK packet.
Values 400-499 represent fatal errors committed by the Dynamic
Authorization Client, so that they MAY be sent within CoA-NAK or
Disconnect-NAK packets, and MUST NOT be sent within CoA-ACK or
Disconnect-ACK packets. Values 500-599 represent fatal errors
occurring on a Dynamic Authorization Server, so that they MAY be
sent within CoA-NAK and Disconnect-NAK packets, and MUST NOT be
sent within CoA-ACK or Disconnect-ACK packets. Error-Cause values
SHOULD be logged by the Dynamic Authorization Client. Error-Code
values (expressed in decimal) include:
値はCoA-ACKかDisconnect-ACKパケットの中で送るだけであるかもしれなく、CoA-NAKかDisconnect-NAKパケットの中で送ってはいけません。 値400-499はDynamic Authorization Clientによって犯された致命的な誤りを表します、それらはCoA-NAKかDisconnect-NAKパケットの中で送るかもしれなくて、CoA-ACKかDisconnect-ACKパケットの中で送ってはいけないように。 値500-599はDynamic Authorization Serverに発生する致命的な誤りを表します、それらはCoA-NAKとDisconnect-NAKパケットの中で送るかもしれなくて、CoA-ACKかDisconnect-ACKパケットの中で送ってはいけないように。 値にSHOULDを誤りで引き起こしてください。Dynamic Authorization Clientによって登録されます。 誤りコード値(小数では、言い表される)は:
# 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
407 Invalid Attribute Value
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
508 Multiple Session Selection Unsupported
# 値--- ----- 201 サポートされないサービス406のサポートされない拡大407の無効の属性値501が行政上502を禁止したという残りのセッションの文脈取り除かれた202無効のEAPパケット(無視される)の401のサポートされない属性402のなくなった属性403NAS識別ミスマッチ404の無効の要求405は、入手できない507が要求する他の移動可能な505プロキシ整理過程の誤差506リソースではなく、504セッション文脈が複数のセッションのときに選択サポートされない状態で508を開始したのがRoutable(プロキシ)503セッション文脈でないことによってわからなかったよう要求します。
"Residual Session Context Removed" is sent in response to a
Disconnect-Request if one or more user sessions are 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.
1つ以上のユーザセッションがもう活発でないならDisconnect-要求に対応して「残りのSession Context Removed」を送りますが、残りのセッション関係を見つけて、首尾よく取り除きました。 この値はDisconnect-ACKの中で送るだけであり、CoA-ACK、Disconnect-NAK、またはCoA-NAKの中で送ってはいけません。
"Invalid EAP Packet (Ignored)" is a non-fatal error that MUST NOT
be sent by implementations of this specification.
「無効のEAP Packet(無視される)」はこの仕様の実装によって送られてはいけない非致命的な誤りです。
"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.
「サポートされないAttribute」はRequestがサポートされない属性(Vendor-詳細かEAP-メッセージAttributeなどの)を含んでいるなら送られた致命的な誤りです。
"Missing Attribute" is a fatal error sent if critical attributes
(such as NAS or session identification attributes) are missing
from a Request.
「なくなったAttribute」はきわどい属性(NASかセッション識別属性などの)がRequestからなくなるなら送られた致命的な誤りです。
Chiba, et al. Informational [Page 17] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
千葉、他 半径2008年1月への情報[17ページ]のRFC5176のダイナミックな承認拡張子
"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"は1つ以上のNAS識別属性(セクション3を見る)がRequestを受けながらNASのアイデンティティに合っていないなら送られた致命的な誤りです。
"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.
「無効のRequest」、Requestのある他の局面が送ったなら送った致命的な誤りがまるで1つや、より多くであるかのように無効で、そのようである、属性、(Attribute(s))が適切にフォーマットされないというEAP-メッセージなどのように。
"Unsupported Service" is a fatal error sent if a Service-Type
Attribute included with the Request is sent with an invalid or
unsupported value. This error cannot be sent in response to a
Disconnect-Request.
「サポートされないService」は無効の、または、サポートされない値と共にRequestと共に含まれていたService-タイプAttributeを送るなら送った致命的な誤りです。 Disconnect-要求に対応してこの誤りを送ることができません。
"Unsupported Extension" is a fatal error sent due to lack of
support for an extension such as Disconnect and/or CoA packets.
This will typically be sent by a proxy receiving an ICMP port
unreachable message after attempting to forward a CoA-Request or
Disconnect-Request to the NAS.
「サポートされないExtension」はDisconnect、そして/または、CoAパケットなどの拡大のサポートの不足のため送られた致命的な誤りです。 これはCoA-要求かDisconnect-要求をNASに転送するのを試みた後にICMPのポートの手の届かないメッセージを受け取るプロキシによって通常送られるでしょう。
"Invalid Attribute Value" is a fatal error sent if a CoA-Request
or Disconnect-Request contains an attribute with an unsupported
value.
「無効のAttribute Value」はCoA-要求かDisconnect-要求がサポートされない値がある属性を含んでいるなら送られた致命的な誤りです。
"Administratively Prohibited" is a fatal error sent if the NAS is
configured to prohibit honoring of CoA-Request or Disconnect-
Request packets for the specified session.
「行政上、Prohibited、」 禁止するNASが構成されるなら送られたa致命的な誤りは指定されたセッションのためのCoA-要求かDisconnectリクエスト・パケットの名誉であることですか?
"Request Not Routable" is a fatal error that MAY be sent by a
proxy and MUST NOT be sent by a NAS. It indicates that the proxy
was unable to determine how to route a CoA-Request or Disconnect-
Request to the NAS. For example, this can occur if the required
entries are not present in the proxy's realm routing table.
「要求Not Routable」はプロキシが送るかもしれなくて、NASが送ってはいけない致命的な誤りです。 それは、プロキシがCoA-要求かDisconnect要求をNASに発送する方法を決定できなかったのを示します。 例えば、必要なエントリーがプロキシの分野経路指定テーブルに存在していないなら、これは起こることができます。
"Session Context Not Found" is a fatal error sent if the session
context identified in the CoA-Request or Disconnect-Request does
not exist on the NAS.
「セッションContext Not Found」はCoA-要求かDisconnect-要求で特定されたセッション文脈が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.
「セッションContext Not Removable」は、NASがセッション文脈の場所を見つけることができたならDisconnect-要求に対応して送られた致命的な誤りですが、ある理由でそれを取り除くことができませんでした。 CoA-ACK、CoA-NAK、またはDisconnect-ACK以内とDisconnect-NAKだけの中でそれを送ってはいけません。
"Other Proxy Processing Error" is a fatal error sent in response
to a CoA or Disconnect-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 CoA or Disconnect-Request that could not be processed by a proxy, for reasons other than routing.
Chiba, et al. Informational [Page 18] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
Chiba, et al. Informational [Page 18] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
"Resources Unavailable" is a fatal error sent when a CoA or
Disconnect-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 CoA or Disconnect-Request could not be honored due to lack of available NAS resources (memory, non-volatile storage, etc.).
"Request Initiated" is a fatal error sent by a NAS in response to
a CoA-Request including a Service-Type Attribute with a value of
"Authorize Only". It indicates that the CoA-Request has not been
honored, but that the NAS is sending one or more RADIUS Access-
Requests including a Service-Type Attribute with value "Authorize
Only" to the RADIUS server.
"Request Initiated" is a fatal error sent by a NAS in response to a CoA-Request including a Service-Type Attribute with a value of "Authorize Only". It indicates that the CoA-Request has not been honored, but that the NAS is sending one or more RADIUS Access- Requests including a Service-Type Attribute with value "Authorize Only" to the RADIUS server.
"Multiple Session Selection Unsupported" is a fatal error sent by
a NAS in response to a CoA-Request or Disconnect-Request whose
session identification attributes match multiple sessions, where
the NAS does not support Requests applying to multiple sessions.
"Multiple Session Selection Unsupported" is a fatal error sent by a NAS in response to a CoA-Request or Disconnect-Request whose session identification attributes match multiple sessions, where the NAS does not support Requests applying to multiple sessions.
Chiba, et al. Informational [Page 19] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
Chiba, et al. Informational [Page 19] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
3.6. Table of Attributes
3.6. 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 0-1 0 0 7 Framed-Protocol (Note 3) 0-1 0 0 8 Framed-IP-Address (Notes 1, 6) 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 0+ 0 0 25 Class (Note 3) 0+ 0 0 26 Vendor-Specific (Note 7) 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) 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 0-1 0 0 7 Framed-Protocol (Note 3) 0-1 0 0 8 Framed-IP-Address (Notes 1, 6) 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 0+ 0 0 25 Class (Note 3) 0+ 0 0 26 Vendor-Specific (Note 7) 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) Request ACK NAK # Attribute
Chiba, et al. Informational [Page 20] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
Chiba, et al. Informational [Page 20] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
Request ACK NAK # Attribute 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+ 0 0 56 Egress-VLANID (Note 3) 0-1 0 0 57 Ingress-Filters (Note 3) 0+ 0 0 58 Egress-VLAN-Name (Note 3) 0-1 0 0 59 User-Priority-Table (Note 3) 0-1 0 0 61 NAS-Port-Type (Note 3) 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-1 0 0 89 Chargeable-User-Identity (Note 1) 0+ 0 0 90 Tunnel-Client-Auth-ID (Note 5) 0+ 0 0 91 Tunnel-Server-Auth-ID (Note 5) 0-1 0 0 92 NAS-Filter-Rule (Note 3) 0 0 0 94 Originating-Line-Info 0-1 0 0 95 NAS-IPv6-Address (Note 1) 0-1 0 0 96 Framed-Interface-Id (Notes 1, 6) 0+ 0 0 97 Framed-IPv6-Prefix (Notes 1, 6) 0+ 0 0 98 Login-IPv6-Host (Note 3) 0+ 0 0 99 Framed-IPv6-Route (Note 3) Request ACK NAK # Attribute
Request ACK NAK # Attribute 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+ 0 0 56 Egress-VLANID (Note 3) 0-1 0 0 57 Ingress-Filters (Note 3) 0+ 0 0 58 Egress-VLAN-Name (Note 3) 0-1 0 0 59 User-Priority-Table (Note 3) 0-1 0 0 61 NAS-Port-Type (Note 3) 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-1 0 0 89 Chargeable-User-Identity (Note 1) 0+ 0 0 90 Tunnel-Client-Auth-ID (Note 5) 0+ 0 0 91 Tunnel-Server-Auth-ID (Note 5) 0-1 0 0 92 NAS-Filter-Rule (Note 3) 0 0 0 94 Originating-Line-Info 0-1 0 0 95 NAS-IPv6-Address (Note 1) 0-1 0 0 96 Framed-Interface-Id (Notes 1, 6) 0+ 0 0 97 Framed-IPv6-Prefix (Notes 1, 6) 0+ 0 0 98 Login-IPv6-Host (Note 3) 0+ 0 0 99 Framed-IPv6-Route (Note 3) Request ACK NAK # Attribute
Chiba, et al. Informational [Page 21] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
Chiba, et al. Informational [Page 21] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
Request ACK NAK # Attribute 0-1 0 0 100 Framed-IPv6-Pool (Note 3) 0 0 0+ 101 Error-Cause 0+ 0 0 123 Delegated-IPv6-Prefix (Note 3) Request ACK NAK # Attribute
Request ACK NAK # Attribute 0-1 0 0 100 Framed-IPv6-Pool (Note 3) 0 0 0+ 101 Error-Cause 0+ 0 0 123 Delegated-IPv6-Prefix (Note 3) 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 0 0 6 Service-Type 0 0 0 8 Framed-IP-Address (Note 1) 0+ 0 0 18 Reply-Message (Note 2) 0 0 0 24 State 0+ 0 0 25 Class (Note 4) 0+ 0 0 26 Vendor-Specific (Note 7) 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 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 0 0 61 NAS-Port-Type 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 89 Chargeable-User-Identity (Note 1) 0-1 0 0 95 NAS-IPv6-Address (Note 1) 0 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 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 0 0 6 Service-Type 0 0 0 8 Framed-IP-Address (Note 1) 0+ 0 0 18 Reply-Message (Note 2) 0 0 0 24 State 0+ 0 0 25 Class (Note 4) 0+ 0 0 26 Vendor-Specific (Note 7) 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 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 0 0 61 NAS-Port-Type 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 89 Chargeable-User-Identity (Note 1) 0-1 0 0 95 NAS-IPv6-Address (Note 1) 0 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
The following defines the meaning of the above table entries:
The following 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.
Chiba, et al. Informational [Page 22] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
Chiba, et al. Informational [Page 22] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
(Note 1) Where NAS or session identification attributes are included in Disconnect-Request or CoA-Request packets, they are used for identification purposes only. These attributes MUST NOT be used for purposes other than identification (e.g., within CoA-Request packets to request authorization changes).
(Note 1) Where NAS or session identification attributes are included in Disconnect-Request or CoA-Request packets, they are used for identification purposes only. These attributes MUST NOT be used for purposes other than identification (e.g., within CoA-Request packets 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 Extension Authentication Protocol (EAP) is used for authentication, an EAP- Message/Notification-Request Attribute is sent instead, and Disconnect-ACK or CoA-ACK packets 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 Extension Authentication Protocol (EAP) is used for authentication, an EAP- Message/Notification-Request Attribute is sent instead, and Disconnect-ACK or CoA-ACK packets 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 values 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 values 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 NAS to the RADIUS 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 NAS to the RADIUS 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 attributes are included 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 attributes are included within a successful CoA-Request, all existing tunnel attributes are removed and replaced by the new attribute(s).
(Note 6) Since the Framed-IP-Address, Framed-IPv6-Prefix, and Framed-Interface-Id attributes are used for session identification, renumbering cannot be accomplished by including values of these attributes within a CoA-Request. Instead, a CoA-Request including a Service-Type Attribute with a value of "Authorize Only" is sent; new values can be supplied in an Access-Accept sent in response to the ensuing Access-Request. Note that renumbering will not be possible in all situations. For example, in order to change an IP address, IPCP or IPv6CP re-negotiation could be required, which is not supported by all PPP implementations.
(Note 6) Since the Framed-IP-Address, Framed-IPv6-Prefix, and Framed-Interface-Id attributes are used for session identification, renumbering cannot be accomplished by including values of these attributes within a CoA-Request. Instead, a CoA-Request including a Service-Type Attribute with a value of "Authorize Only" is sent; new values can be supplied in an Access-Accept sent in response to the ensuing Access-Request. Note that renumbering will not be possible in all situations. For example, in order to change an IP address, IPCP or IPv6CP re-negotiation could be required, which is not supported by all PPP implementations.
(Note 7) Within Disconnect-Request packets, Vendor-Specific Attributes (VSAs) MAY be used for session identification. Within CoA-Request packets, VSAs MAY be used for either session identification or authorization change. However, the same Attribute MUST NOT be used for both purposes simultaneously.
(Note 7) Within Disconnect-Request packets, Vendor-Specific Attributes (VSAs) MAY be used for session identification. Within CoA-Request packets, VSAs MAY be used for either session identification or authorization change. However, the same Attribute MUST NOT be used for both purposes simultaneously.
Chiba, et al. Informational [Page 23] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
Chiba, et al. Informational [Page 23] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
4. Diameter Considerations
4. Diameter Considerations
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 a Diameter Re-Auth-Request (RAR) to a CoA-Request and vice versa. For example, since a CoA-Request only initiates an authorization change but does not initiate re-authentication, a RAR command containing a Re-Auth-Request-Type AVP with value "AUTHORIZE_AUTHENTICATE" cannot be directly translated to a CoA-Request. A Diameter/RADIUS gateway receiving a CoA-Request containing authorization changes will need to translate this into two Diameter exchanges. First, the Diameter/RADIUS gateway will issue a RAR command including a Session-Id AVP and a Re-Auth-Request-Type AVP with value "AUTHORIZE ONLY". Then the Diameter/RADIUS gateway will respond to the ensuing access request with a response including the authorization attributes gleaned from the CoA-Request. To enable translation, the CoA-Request SHOULD include a Acct-Session-Id Attribute. If the Diameter client uses the same Session-Id for both authorization and accounting, then the Diameter/RADIUS gateway can copy the contents of the Acct- Session-Id Attribute into the Session-Id AVP; otherwise, it will need to map the Acct-Session-Id value to an equivalent Session-Id for use within a RAR command.
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 a Diameter Re-Auth-Request (RAR) to a CoA-Request and vice versa. For example, since a CoA-Request only initiates an authorization change but does not initiate re-authentication, a RAR command containing a Re-Auth-Request-Type AVP with value "AUTHORIZE_AUTHENTICATE" cannot be directly translated to a CoA-Request. A Diameter/RADIUS gateway receiving a CoA-Request containing authorization changes will need to translate this into two Diameter exchanges. First, the Diameter/RADIUS gateway will issue a RAR command including a Session-Id AVP and a Re-Auth-Request-Type AVP with value "AUTHORIZE ONLY". Then the Diameter/RADIUS gateway will respond to the ensuing access request with a response including the authorization attributes gleaned from the CoA-Request. To enable translation, the CoA-Request SHOULD include a Acct-Session-Id Attribute. If the Diameter client uses the same Session-Id for both authorization and accounting, then the Diameter/RADIUS gateway can copy the contents of the Acct- Session-Id Attribute into the Session-Id AVP; otherwise, it will need to map the Acct-Session-Id value to an equivalent Session-Id for use within a RAR command.
Where an Acct-Session-Id Attribute is not present in a CoA-Request or Disconnect-Request, a Diameter/RADIUS gateway will either need to determine the appropriate Acct-Session-Id or, if it cannot do so, it can send a CoA-NAK or Disconnect-NAK in reply, possibly including an Error-Cause Attribute with a value of 508 (Multiple Session Selection Unsupported).
Where an Acct-Session-Id Attribute is not present in a CoA-Request or Disconnect-Request, a Diameter/RADIUS gateway will either need to determine the appropriate Acct-Session-Id or, if it cannot do so, it can send a CoA-NAK or Disconnect-NAK in reply, possibly including an Error-Cause Attribute with a value of 508 (Multiple Session Selection Unsupported).
To simplify translation between RADIUS and Diameter, Dynamic Authorization Clients can include a Service-Type Attribute with value "Authorize Only" within a CoA-Request, as described in Section 3.2. A Diameter/RADIUS gateway receiving a CoA-Request containing a Service-Type Attribute with a value "Authorize Only" translates this to a RAR with Re-Auth-Request-Type AVP with value "AUTHORIZE ONLY". The received RAA is then translated to a CoA-NAK with a Service-Type Attribute with value "Authorize Only". If the Result-Code AVP in the RAA has a value in the success category, then an Error-Cause Attribute with value "Request Initiated" is included in the CoA-NAK. If the Result-Code AVP in the RAA has a value indicating a Protocol Error or a Transient or Permanent Failure, then an alternate Error- Cause Attribute is returned as suggested below.
To simplify translation between RADIUS and Diameter, Dynamic Authorization Clients can include a Service-Type Attribute with value "Authorize Only" within a CoA-Request, as described in Section 3.2. A Diameter/RADIUS gateway receiving a CoA-Request containing a Service-Type Attribute with a value "Authorize Only" translates this to a RAR with Re-Auth-Request-Type AVP with value "AUTHORIZE ONLY". The received RAA is then translated to a CoA-NAK with a Service-Type Attribute with value "Authorize Only". If the Result-Code AVP in the RAA has a value in the success category, then an Error-Cause Attribute with value "Request Initiated" is included in the CoA-NAK. If the Result-Code AVP in the RAA has a value indicating a Protocol Error or a Transient or Permanent Failure, then an alternate Error- Cause Attribute is returned as suggested below.
Within Diameter, a server can request that a session be aborted by sending an Abort-Session-Request (ASR), identifying the session to be terminated using Session-ID and User-Name AVPs. The ASR command is
Within Diameter, a server can request that a session be aborted by sending an Abort-Session-Request (ASR), identifying the session to be terminated using Session-ID and User-Name AVPs. The ASR command is
Chiba, et al. Informational [Page 24] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
Chiba, et al. Informational [Page 24] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
translated to a Disconnect-Request containing Acct-Session-Id and User-Name attributes. If the Diameter client utilizes the same Session-Id in both authorization and accounting, then the value of the Session-ID AVP may be placed in the Acct-Session-Id Attribute; otherwise the value of the Session-ID AVP will need to be mapped to an appropriate Acct-Session-Id Attribute. To enable translation of a Disconnect-Request to an ASR, an Acct-Session-Id Attribute SHOULD be present.
translated to a Disconnect-Request containing Acct-Session-Id and User-Name attributes. If the Diameter client utilizes the same Session-Id in both authorization and accounting, then the value of the Session-ID AVP may be placed in the Acct-Session-Id Attribute; otherwise the value of the Session-ID AVP will need to be mapped to an appropriate Acct-Session-Id Attribute. To enable translation of a Disconnect-Request to an ASR, an Acct-Session-Id Attribute SHOULD be present.
If the Diameter client utilizes the same Session-Id in both authorization and accounting, then the value of the Acct-Session-Id Attribute may be placed into the Session-ID AVP within the ASR; otherwise the value of the Acct-Session-Id Attribute will need to be mapped to an appropriate Session-ID AVP.
Diameterクライアントが承認と会計の両方で同じSession-イドを利用するなら、AcctセッションイドAttributeの値はASRの中にSession-ID AVPに置かれるかもしれません。 さもなければ、AcctセッションイドAttributeの値は、適切なSession-ID AVPに写像される必要があるでしょう。
An Abort-Session-Answer (ASA) command is sent in response to an ASR in order to indicate the disposition of the request. A Diameter/RADIUS gateway receiving a Disconnect-ACK translates this to an ASA command with a Result-Code AVP of "DIAMETER_SUCCESS". A Disconnect-NAK received from the NAS is translated to an ASA command with a Result-Code AVP that depends on the value of the Error-Cause Attribute. Suggested translations between Error-Cause Attribute values and Result-Code AVP values are included below:
要求の気質を示すためにASRに対応してAbortセッション答え(ASA)命令を送ります。 Disconnect-ACKを受けるDiameter/RADIUSゲートウェイは「直径_成功」のResult-コードAVPとのASAコマンドにこれを翻訳します。 NASから受け取られたDisconnect-NAKはError-原因Attributeの値に依存するResult-コードAVPとのASAコマンドに翻訳されます。 Error-原因Attribute値とResult-コードAVP値の間の提案された翻訳は以下に含まれています:
# Error-Cause Attribute Value Result-Code AVP
--- --------------------------- ------------------------
201 Residual Session Context DIAMETER_SUCCESS
Removed
202 Invalid EAP Packet DIAMETER_LIMITED_SUCCESS
(Ignored)
401 Unsupported Attribute DIAMETER_AVP_UNSUPPORTED
402 Missing Attribute DIAMETER_MISSING_AVP
403 NAS Identification DIAMETER_REALM_NOT_SERVED
Mismatch
404 Invalid Request DIAMETER_UNABLE_TO_COMPLY
405 Unsupported Service DIAMETER_COMMAND_UNSUPPORTED
406 Unsupported Extension DIAMETER_APPLICATION_UNSUPPORTED
407 Invalid Attribute Value DIAMETER_INVALID_AVP_VALUE
501 Administratively DIAMETER_AUTHORIZATION_REJECTED
Prohibited
502 Request Not Routable (Proxy) DIAMETER_UNABLE_TO_DELIVER
503 Session Context Not Found DIAMETER_UNKNOWN_SESSION_ID
504 Session Context Not DIAMETER_AUTHORIZATION_REJECTED
Removable
505 Other Proxy Processing DIAMETER_UNABLE_TO_COMPLY
Error
506 Resources Unavailable DIAMETER_RESOURCES_EXCEEDED
507 Request Initiated DIAMETER_SUCCESS
# 誤り原因属性値結果コードAVP--- --------------------------- ------------------------ 201の残りのセッション文脈直径_成功が_の役立たれたミスマッチ404の無効の要求直径_であることができるのではなく、無効のサポートされない202のサポートされない402なくなった属性_EAPパケットの直径の_の限られた_成功(無視される)401属性直径_AVP_直径取り逃がす_AVP403NAS識別直径_分野_を取り外した、__に、サポートされない405のサポートされない406サポートされない拡大サービス直径_コマンド_直径_アプリケーション_のサポートされない407無効の状態で応じてください; 値の直径の_の無効の_AVP_価値501を結果と考えてください、行政上、_が拒絶した直径_承認がどんな502要求Routable(プロキシ)直径_であることができないも禁止しなかった、__に、503セッション文脈を提供してください、_どんなID504セッション文脈直径_承認_もどんな他の移動可能な505プロキシ処理直径_であることができるも拒絶しなかった直径の_の未知の_セッション_が見つけられないで、_に、超えられている507要求が開始した誤り506リソースの入手できない直径_リソース_が応じている、直径_成功
Chiba, et al. Informational [Page 25] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
千葉、他 半径2008年1月への情報[25ページ]のRFC5176のダイナミックな承認拡張子
Since both the ASR/ASA and Disconnect-Request/Disconnect- NAK/Disconnect-ACK exchanges involve just a request and response, inclusion of an "Authorize Only" Service-Type within a Disconnect- Request is not needed to assist in Diameter/RADIUS translation, and may make translation more difficult. As a result, as noted in Section 3.2, the Service-Type Attribute MUST NOT be used within a Disconnect-Request.
ASR/ASAと分離NAK/ACK交換がまさしく要求と応答、包含にかかわるDisconnect-要求/分離の両方、「Diameter/RADIUS翻訳が促進される必要はなくて、翻訳をより難しくするかもしれないDisconnectが、要求するaの中で」 Service-タイプだけに権限を与えてください。 その結果、セクション3.2に述べられるように、Service-タイプAttributeはDisconnect-要求の中で使用されているはずがありません。
5. IANA Considerations
5. IANA問題
This document uses the RADIUS [RFC2865] namespace; see <http://www.iana.org/assignments/radius-types>. In addition to the allocations already made in [RFC3575] and [RFC3576], this specification allocates additional values of the Error-Cause Attribute (101):
このドキュメントはRADIUS[RFC2865]名前空間を使用します。 <が>をhttp://www.iana.org/課題/半径でタイプするのを確実にしてください。 [RFC3575]と[RFC3576]で既にされた配分に加えて、この仕様はError-原因Attribute(101)の加算値を割り当てます:
# Value
--- -----
407 Invalid Attribute Value
508 Multiple Session Selection Unsupported
# 値--- ----- 407の無効の属性値508複数のセッション選択サポートされないです。
6. Security Considerations
6. セキュリティ問題
6.1. Authorization Issues
6.1. 承認問題
Where a NAS is shared by multiple providers, it is undesirable for one provider to be able to send Disconnect-Requests or CoA-Requests affecting the sessions of another provider.
NASが複数のプロバイダーによって共有されるところでは、Disconnect-要求かCoA-要求が1つのプロバイダーで別のプロバイダーのセッションに影響できるのは、望ましくありません。
A Dynamic Authorization Server MUST silently discard Disconnect- Request or CoA-Request packets from untrusted sources. In situations where the Dynamic Authorization Client is co-resident with a RADIUS authentication or accounting server, a proxy MAY perform a "reverse path forwarding" (RPF) check to verify that a Disconnect-Request or CoA-Request originates from an authorized Dynamic Authorization Client. 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 packets relating to users within a set of realms.
Dynamic Authorization Serverは信頼できないソースからDisconnect要求かCoA-リクエスト・パケットを静かに捨てなければなりません。 Dynamic Authorization ClientがRADIUS認証か会計サーバをもっているコレジデントである状況で、プロキシは、Disconnect-要求かCoA-要求が認可されたDynamic Authorization Clientから発することを確かめるために「逆の経路推進」(RPF)チェックを実行するかもしれません。 さらに、それ、SHOULD、セッションのあるクラスに関連しながら明らかにDisconnect-要求かCoA-リクエスト・パケットの追加源を認可するのにおいて、可能であってください。 例えば、明らかに、特定のソースがCoA-リクエスト・パケットを1セットの分野の中でユーザに関連させるのに権限を与えることができます。
To perform the RPF check, the Dynamic Authorization Server uses the session identification attributes included in Disconnect-Request or CoA-Request packets, 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 CoA-Request or Disconnect-Request is forwarded; otherwise it MUST be silently discarded.
働くために、RPFはチェックします、セッション識別属性がDisconnect-要求かCoA-リクエスト・パケットに含んだDynamic Authorization Server用途、同等なAccess-要求を発送できたRADIUSサーバを決定するために。 このセットの中にDisconnect-要求かCoA-要求のソースアドレスがあるなら、CoA-要求かDisconnect-要求を転送します。 さもなければ、静かにそれを捨てなければなりません。
Chiba, et al. Informational [Page 26] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
千葉、他 半径2008年1月への情報[26ページ]のRFC5176のダイナミックな承認拡張子
Typically, the Dynamic Authorization Server will extract the realm from the Network Access Identifier [RFC4282] included within the User-Name or Chargeable-User-Identity Attribute, and determine the corresponding RADIUS servers in the realm routing tables. If the Dynamic Authorization Server maintains long-term session state, it MAY perform the authorization check based on the session identification attributes in the CoA-Request. The session identification attributes can be used to tie a session to a particular proxy or set of proxies, as with the NAI realm.
Dynamic Authorization Serverは通常、User-名前の中に含まれていたNetwork Access Identifier[RFC4282]かChargeableユーザのアイデンティティAttributeから分野を抽出して、分野経路指定テーブルで対応するRADIUSサーバを決定するでしょう。 Dynamic Authorization Serverが長期のセッション状態を維持するなら、それはCoA-要求におけるセッション識別属性に基づく許可検査を実行するかもしれません。 特定のプロキシか1セットのプロキシにセッションを結ぶのにセッション識別属性を使用できます、NAI分野のように。
Where no proxy is present, the RPF check can only be performed by the NAS if it maintains its own a realm routing table. If the NAS does not maintain a realm routing table (e.g., it selects forwarding proxies based on primary/secondary configuration and/or liveness checks), then an RPF check cannot be performed.
どんなプロキシも出席していないところでは、それ自身のものが分野経路指定テーブルであることを支持する場合にだけ、NASはRPFチェックを実行できます。 NASが分野経路指定テーブルを維持しないなら(例えば、それはプライマリの、または、セカンダリの構成、そして/または、活性チェックに基づく推進プロキシを選びます)、RPFチェックを実行できません。
Since authorization to send a Disconnect-Request or CoA-Request is determined based on the source address and the corresponding shared secret, the Dynamic Authorization Server SHOULD configure a different shared secret for each Dynamic Authorization Client.
Disconnect-要求かCoA-要求を送る承認がソースアドレスと対応する共有秘密キーに基づいて決定しているので、Dynamic Authorization Server SHOULDは各Dynamic Authorization Clientのための異なった共有秘密キーを構成します。
6.2. IPsec Usage Guidelines
6.2. IPsec用法ガイドライン
In addition to security vulnerabilities unique to Disconnect or CoA packets, 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, utilizing the profile described in [RFC3579], Section 4.2.
DisconnectかCoAパケットにユニークなセキュリティの脆弱性に加えて、本書では説明されたプロトコル交換はRADIUS[RFC2865]と同じ脆弱性に影響されやすいです。 IPsecが[RFC3579]で説明されたプロフィールを利用することでのセクション4.2をより良いセキュリティに都合するのに使われるのは、RECOMMENDEDです。
For Dynamic Authorization Servers implementing this specification, the IPsec policy would be "Require IPsec, from any to me, destination port UDP 3799". This causes the Dynamic Authorization Server to require use of IPsec. If some Dynamic Authorization Clients do not support IPsec, then a more granular policy will be required: "Require IPsec, from IPsec-Capable-DAC to me".
「IPsecを必要としてください、いずれから私まで、仕向港UDP3799」というこの仕様、IPsec政策を実施するのがそうするDynamic Authorization Serversに関してはことになってください。 これで、Dynamic Authorization ServerはIPsecの使用を必要とします。 いくつかのDynamic Authorization ClientsがIPsecをサポートしないと、より粒状の方針が必要でしょう: 「IPsecのできるDACから私までIPsecを必要としてください。」
For Dynamic Authorization Clients implementing this specification, the IPsec policy would be "Initiate IPsec, from me to any, destination port UDP 3799". This causes the Dynamic Authorization Client to initiate IPsec when sending Dynamic Authorization traffic to any Dynamic Authorization Server. If some Dynamic Authorization Servers contacted by the Dynamic Authorization Client do not support IPsec, then a more granular policy will be required, such as "Initiate IPsec, from me to IPsec-Capable-DAS, destination port UDP 3799".
「私からいずれまでもIPsecを開始してください、仕向港UDP3799」というこの仕様、IPsec政策を実施するのがそうするDynamic Authorization Clientsに関してはことになってください。 どんなDynamic Authorization ServerへのトラフィックもDynamic Authorizationに送るとき、これで、Dynamic Authorization ClientはIPsecを開始します。Dynamic Authorization Clientによって連絡されたいくつかのDynamic Authorization ServersがIPsecをサポートしないと、より粒状の方針が必要でしょう、「私からできるIPsec DASまでIPsecを開始してください、仕向港UDP3799」などのように。
Chiba, et al. Informational [Page 27] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
千葉、他 半径2008年1月への情報[27ページ]のRFC5176のダイナミックな承認拡張子
6.3. Replay Protection
6.3. 反復操作による保護
Where IPsec replay protection is not used, an Event-Timestamp (55) [RFC2869] Attribute SHOULD be included within CoA-Request and Disconnect-Request packets, and MAY be included within CoA-ACK, CoA- NAK, Disconnect-ACK, and Disconnect-NAK packets.
IPsec反復操作による保護が使用されていないところでは、Event-タイムスタンプ(55)[RFC2869]属性SHOULDはCoA-要求とDisconnect-リクエスト・パケットの中に含まれていて、CoA-ACK、CoA- NAK、Disconnect-ACK、およびDisconnect-NAKパケットの中に含まれるかもしれません。
When the Event-Timestamp Attribute is present, both the Dynamic Authorization Server and the Dynamic Authorization Client MUST check that the Event-Timestamp Attribute is current within an acceptable time window. If the Event-Timestamp Attribute is not current, then the packet MUST be silently discarded. This implies the need for loose time synchronization within the network, which can be achieved by a variety of means, including Simple Network Time Protocol (SNTP), as described in [RFC4330]. Implementations SHOULD be configurable to discard CoA-Request or Disconnect-Request packets not containing an Event-Timestamp Attribute.
Event-タイムスタンプAttributeが存在しているとき、Dynamic Authorization ServerとDynamic Authorization Clientの両方が、Event-タイムスタンプAttributeが許容できるタイムウィンドウの中でよく見られるのをチェックしなければなりません。 Event-タイムスタンプAttributeがよく見られないなら、静かにパケットを捨てなければなりません。 これはネットワークの中でゆるい時間同期化の必要性を含意します、Simple Network Timeプロトコル(SNTP)を含んでいて、[RFC4330]で説明されるように。さまざまな手段でネットワークを達成できます。 実装SHOULD、Event-タイムスタンプAttributeを含んでいなくて、CoA-要求かDisconnect-リクエスト・パケットを捨てるのにおいて、構成可能であってください。
If the Event-Timestamp Attribute is included, it represents the time at which the original packet was sent, and therefore it SHOULD NOT be updated when the packet is retransmitted. If the Event-Timestamp Attribute is not updated, this implies that the Identifier is not changed in retransmitted packets. As a result, the ability to detect replay within the time window is dependent on support for duplicate detection within that same window. As noted in Section 2.3, duplicate detection is REQUIRED for Dynamic Authorization Servers implementing this specification.
Event-タイムスタンプAttributeが含まれているなら、オリジナルのパケットが送られた時を表して、したがって、それを表す、SHOULD NOT、パケットを再送するときには、アップデートしてください。 Event-タイムスタンプAttributeをアップデートしないなら、これは、Identifierが再送されたパケットで変えられないのを含意します。 その結果、タイムウィンドウの中に再生を検出する能力はその同じ窓の中の写し検出のサポートに依存しています。 セクション2.3に述べられるように、写し検出はこの仕様を履行するDynamic Authorization ServersのためのREQUIREDです。
The time window used for duplicate detection MUST be the same as the window used to detect a stale Event-Timestamp Attribute. Since the RADIUS Identifier cannot be repeated within the selected time window, no more than 256 Requests can be accepted within the time window. As a result, the chosen time window will depend on the expected maximum volume of CoA/Disconnect-Requests, so that unnecessary discards can be avoided. A default time window of 300 seconds should be adequate in many circumstances.
写し検出に使用されるタイムウィンドウは窓が以前はよく聞き古したEvent-タイムスタンプAttributeを検出していたのと同じであるに違いありません。 選択されたタイムウィンドウの中でRADIUS Identifierを繰り返すことができないので、タイムウィンドウの中で256Requestsを受け入れることができます。 その結果、選ばれたタイムウィンドウを分離CoA/要求の予想された最大のボリュームに依存するでしょう、不要な破棄を避けることができるように。 300秒のデフォルトタイムウィンドウは多くの事情で適切であるべきです。
7. Example Traces
7. 例の跡
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
Chiba, et al. Informational [Page 28] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
千葉、他 半径2008年1月への情報[28ページ]のRFC5176のダイナミックな承認拡張子
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
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC1321] Rivest、R.、「MD5メッセージダイジェストアルゴリズム」、RFC1321、1992年4月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、RFC2119、1997年3月。
[RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC2865]RigneyとC.とルーベンとA.とシンプソン、W.とS.ウィレンス、「ユーザサービス(半径)におけるリモート認証ダイヤル」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月。」
[RFC3575] Aboba, B., "IANA Considerations for RADIUS", RFC 3575,
July 2003.
[RFC3575] Aboba、B.、「半径のためのIANA問題」、RFC3575、2003年7月。
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3579]AbobaとB.とP.カルフーン、「拡張認証プロトコル(EAP)の半径サポート」、RFC3579、2003年9月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005.
[RFC4282] AbobaとB.と用務員とM.とArkkoとJ.とP.Eronen、「ネットワークアクセス識別子」、RFC4282、2005年12月。
Chiba, et al. Informational [Page 29] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
千葉、他 半径2008年1月への情報[29ページ]のRFC5176のダイナミックな承認拡張子
8.2. Informative References
8.2. 有益な参照
[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年夏。
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege,
M. and I. Goyret, "RADIUS Attributes for Tunnel Protocol
Support", RFC 2868, June 2000.
[RFC2868] ゾルン、G.、ライファー、D.、ルーベン、A.、シュライバー、J.、Holdrege、M.、およびI.Goyret、「トンネルへの半径属性はサポートについて議定書の中で述べます」、RFC2868、2000年6月。
[RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization
and Accounting Transport Profile", RFC 3539, June 2003.
[RFC3539] Aboba、B.、J.木、および「認証、承認、および会計輸送プロフィール」、RFC3539、6月2003日
[RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B.
Aboba, "Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)", RFC 3576,
July 2003.
[RFC3576] 千葉、M.、Dommety、G.、エクルンド、M.、ミットン、D.、およびB.Aboba、「リモート認証へのダイナミックな承認拡大はユーザでサービス(半径)にダイヤルします」、RFC3576、2003年7月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J.
Arkko, "Diameter Base Protocol", RFC 3588, September
2003.
[RFC3588] カルフーンとP.とLoughneyとJ.とGuttmanとE.とゾルンとG.とJ.Arkko、「直径基地のプロトコル」、RFC3588、2003年9月。
[RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
for IPv4, IPv6 and OSI", RFC 4330, January 2006.
[RFC4330]工場、D.、「IPv4、IPv6、およびOSIのための簡単なネットワーク時間プロトコル(SNTP)バージョン4」、RFC4330、2006年1月。
[RFC4372] Adrangi, F., Lior, A., Korhonen, J. and J. Loughney,
"Chargeable User Identity", RFC 4372, January 2006.
[RFC4372] AdrangiとF.とLiorとA.とKorhonenとJ.とJ.Loughney、「請求できるユーザのアイデンティティ」、RFC4372、2006年1月。
[RFC4675] Congdon, P., Sanchez, M. and B. Aboba, "RADIUS Attributes
for Virtual LAN and Priority Support", RFC 4675,
September 2006.
[RFC4675] コングドンとP.とサンチェスとM.とB.Aboba、「バーチャルLANと優先権サポートのための半径属性」、RFC4675、2006年9月。
[RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix
Attribute", RFC 4818, April 2007.
[RFC4818] SaloweyとJ.とR.Droms、「半径代表として派遣されたIPv6接頭語属性」、RFC4818、2007年4月。
[RFC4849] Congdon, P., Sanchez, M. and B. Aboba, "RADIUS Filter
Rule Attribute", RFC 4849, April 2007.
[RFC4849] コングドンとP.とサンチェスとM.とB.Aboba、「半径フィルタ規則属性」、RFC4849、2007年4月。
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 valuable suggestions and feedback from Avi Lior, Randy Bush, Steve Bellovin, Glen Zorn, Mark Jones, Claudio Lapidus, Anurag Batta, Kuntal Chowdhury, Tim Moore, Russ Housley, Joe Salowey, Alan DeKok, and David Nelson.
作者はアヴィLior、ランディ・ブッシュ、スティーブBellovin、Glenゾルン、マーク・ジョーンズ、クラウディオ・ラピドゥス、Anurag Batta、Kuntalチョードリ、ティム・ムーア、ラスHousley、ジョーSalowey、アランDeKok、およびデヴィッド・ネルソンから貴重な提案とフィードバックを承諾したがっています。
Chiba, et al. Informational [Page 30] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
千葉、他 半径2008年1月への情報[30ページ]のRFC5176のダイナミックな承認拡張子
Appendix A. Changes from RFC 3576
RFC3576からの付録A.変化
This Appendix lists the major changes between [RFC3576] and this document. Minor changes, including style, grammar, spelling, and editorial changes, are not mentioned here.
このAppendixは[RFC3576]とこのドキュメントの間の大きな変化を記載します。 スタイル、文法、スペル、および編集の変化を含むマイナーチェンジがここに言及されません。
o The term "Dynamic Authorization Client" is used instead of RADIUS server where it applies to the originator of CoA-Request and Disconnect-Request packets. The term "Dynamic Authorization Server" is used instead of NAS where it applies to the receiver of CoA- Request and Disconnect-Request packets. Definitions of these terms have been added (Section 1.3).
o 「ダイナミックな承認クライアント」という用語はそれがCoA-要求とDisconnect-リクエスト・パケットの創始者に適用されるRADIUSサーバの代わりに使用されます。 「ダイナミックな承認サーバ」という用語はそれがCoA要求とDisconnect-リクエスト・パケットの受信機に適用されるNASの代わりに使用されます。 これらの用語の定義は加えられます(セクション1.3)。
o Added requirement for duplicate detection on the Dynamic
Authorization Server (Section 2.3).
o Dynamic Authorization Server(セクション2.3)で写し検出のための要件を加えました。
o Clarified expected behavior when session identification attributes
match more than one session (Sections 2.3, 3, 3.5, 4).
o セッション識別属性が1つのセッション(セクション2.3、3、3.5、4)より合っているとき、予想された振舞いをはっきりさせました。
o Added Chargeable-User-Identity as a session identification
attribute. Removed NAS-Port-Type as a session identification
attribute (Section 3).
o セッション識別属性としてChargeableユーザのアイデンティティを加えました。 セッション識別としての取り除かれたNASポートタイプは(セクション3)を結果と考えます。
o Added recommendation that an Acct-Session-Id or Acct-Multi-
Session-Id Attribute be included in an Access-Request (Section 3).
o 推薦を加える、それ、AcctセッションイドかAcct、-、マルチSession-イドAttribute、Access-要求(セクション3)で含められてください。
o Added discussion of scenarios in which the "Dynamic Authorization
Client" and RADIUS server are not co-located (Section 3).
o シナリオの加えられた議論は「ダイナミックな承認クライアント」とRADIUSサーバがどれであるかで(セクション3)の共同場所を見つけませんでした。
o Added details relating to handling of the Proxy-State Attribute
(Section 3.1).
o Proxy-州のAttribute(セクション3.1)の取り扱いに関連する詳細を加えました。
o Added clarification that support for a Service-Type Attribute with
value "Authorize Only" is optional on both the NAS and Dynamic
Authorization Client (Section 3.2). Use of the Service-Type
Attribute within a Disconnect-Request is prohibited (Sections 3.2,
3.6).
o それがa Service-タイプAttributeのために値でサポートする明確化を加える、「認可、単に」、NASとDynamic Authorization Clientの両方(セクション3.2)では、任意です。 Disconnect-要求の中のService-タイプAttributeの使用は禁止されています(セクション3.2、3.6)。
o Added requirement for inclusion of the State Attribute in CoA-
Request packets including a Service-Type Attribute with a value of
"Authorize Only" (Section 3.3).
o CoAのAttributeがaがあるAttributeが評価するService-タイプを含むパケットを要求する州の包含のための要件を加える、「」 (セクション3.3)だけ、を認可してください。
o Added clarification on the calculation of the Message-
Authenticator Attribute (Section 3.4).
o Message固有識別文字Attribute(セクション3.4)の計算のときに明確化を加えました。
o Additional Error-Cause Attribute values are allocated for Invalid
Attribute Value (407) and Multiple Session Selection
Identification (508) (Sections 3.5, 4).
o Invalid Attribute Value(407)とMultiple Session Selection Identification(508)(セクション3.5、4)のために追加Error-原因Attribute値を割り当てます。
Chiba, et al. Informational [Page 31] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
千葉、他 半径2008年1月への情報[31ページ]のRFC5176のダイナミックな承認拡張子
o Updated the CoA-Request Attribute Table to include Filter-Rule,
Delegated-IPv6-Prefix, Egress-VLANID, Ingress-Filters, Egress-
VLAN-Name, and User-Priority attributes (Section 3.6).
o Filter-規則、Delegated-IPv6-接頭語、Egress-VLANID、Ingress-フィルタ、Egress- VLAN-名前、およびUser-優先権属性(セクション3.6)を含んでいるというCoA-要求Attribute Tableをアップデートしました。
o Added the Chargeable-User-Identity Attribute to both the CoA-
Request and Disconnect-Request Attribute table (Section 3.6).
o CoA要求とDisconnect-要求Attributeの両方へのChargeableユーザのアイデンティティAttributeが(セクション3.6)をテーブルの上に置くと言い足しました。
o Use of Vendor-Specific Attributes (VSAs) for session
identification and authorization change has been clarified
(Section 3.6).
o Vendor特有のAttributes(VSAs)のセッション識別と承認変化の使用ははっきりさせられました(セクション3.6)。
o Added Note 6 on the use of the CoA-Request for renumbering, and
Note 7 on the use of Vendor-Specific attributes (Section 3.6).
o CoA-要求の番号を付け替えることの使用でのNote6、およびVendor特有の属性(セクション3.6)の使用でのNote7を加えました。
o Added Diameter Considerations (Section 4).
o 直径問題(セクション4)を加えました。
o Event-Timestamp Attribute should not be recalculated on
retransmission. The implications for replay and duplicate
detection are discussed (Section 6.3).
o 「再-トランスミッション」でイベントタイムスタンプAttributeについて再計算するべきではありません。 再生と写し検出のための含意について議論します(セクション6.3)。
o Operation of the Reverse Path Forwarding (RPF) check has been
clarified. Use of the RPF check is optional rather than
recommended by default (Section 6.1).
o Reverse Path Forwarding(RPF)チェックの操作ははっきりさせられました。 お勧めであるというよりむしろRPFチェックの使用はデフォルトで(セクション6.1)任意です。
o Text on impersonation (included in [RFC3579], Section 4.3.7) and
IPsec operation (included in [RFC3579], Section 4.2) has been
removed, and is now referenced.
o ものまね([RFC3579]、セクション4.3.7では、含まれている)とIPsec操作([RFC3579]、セクション4.2では、含まれている)に関するテキストは、取り除かれて、現在、参照をつけられます。
Chiba, et al. Informational [Page 32] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
千葉、他 半径2008年1月への情報[32ページ]のRFC5176のダイナミックな承認拡張子
Authors' Addresses
作者のアドレス
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 RSA, Security Division of EMC 174 Middlesex Turnpike Bedford, MA 01730
デヴィッドミットンRSA、EMC174ミドルセックスTurnpikeベッドフォード、MA 01730人の安全保障課
EMail: david@mitton.com
メール: david@mitton.com
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 33] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
千葉、他 半径2008年1月への情報[33ページ]のRFC5176のダイナミックな承認拡張子
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Chiba, et al. Informational [Page 34]
千葉、他 情報[34ページ]
一覧
スポンサーリンク
