Network Working Group R. Droms
Request for Comments: 4014 J. Schnizlein
Category: Standards Track Cisco Systems
February 2005
Remote Authentication Dial-In User Service (RADIUS)
Attributes Suboption for the
Dynamic Host Configuration Protocol (DHCP)
Relay Agent Information Option
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントでは、インターネットコミュニティ向けのインターネット標準追跡プロトコルを指定し、改善のための議論と提案を求めています。 このプロトコルの標準化状態とステータスについては、「Internet Official Protocol Standards」（STD 1）の最新版を参照してください。 このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
The RADIUS Attributes suboption enables a network element to pass identification and authorization attributes received during RADIUS authentication to a DHCP server. When the DHCP server receives a message from a relay agent containing a RADIUS Attributes suboption, it extracts the contents of the suboption and uses that information in selecting configuration parameters for the client.
RADIUS属性サブオプションを使用すると、ネットワーク要素は、RADIUS認証中に受信した識別および許可属性をDHCPサーバーに渡すことができます。 DHCPサーバーは、RADIUS属性サブオプションを含むメッセージをリレーエージェントから受信すると、サブオプションの内容を抽出し、その情報を使用してクライアントの構成パラメーターを選択します。
The RADIUS Attributes suboption for the DHCP Relay Agent option provides a way in which a NAS can pass attributes obtained from a RADIUS server to a DHCP server [1]. IEEE 802.1X [2] is an example of a mechanism through which a NAS such as a switch or a wireless LAN access point can authenticate the identity of the user of a device before providing layer 2 network access with RADIUS as the Authentication Service, as specified in RFC 3580 [8]. In IEEE 802.1X authenticated access, a device must first exchange some authentication credentials with the NAS. The NAS then supplies these credentials to a RADIUS server, which eventually sends either an Access-Accept or an Access-Reject in response to an Access-Request. The NAS, based on the reply of the RADIUS server, then allows or denies network access to the requesting device.
DHCPリレーエージェントオプションのRADIUS属性サブオプションは、NASがRADIUSサーバーから取得した属性をDHCPサーバーに渡す方法を提供します[1]。 IEEE 802.1X [2]は、スイッチやワイヤレスLANアクセスポイントなどのNASがデバイスのユーザーのIDを認証してから、認証サービスとしてRADIUSを使用してレイヤー2ネットワークアクセスを提供するメカニズムの例です。 RFC 3580 [8]で指定されています。 IEEE 802.1X認証アクセスでは、デバイスは最初に認証資格情報をNASと交換する必要があります。 次に、NASはこれらの資格情報をRADIUSサーバーに提供し、RADIUSサーバーは最終的にAccess-Requestに応じてAccess-AcceptまたはAccess-Rejectを送信します。 NASは、RADIUSサーバーの応答に基づいて、要求元デバイスへのネットワークアクセスを許可または拒否します。
Figure 1 summarizes the message exchange among the participants in IEEE 802.1X authentication.
図1は、IEEE 802.1X認証の参加者間のメッセージ交換をまとめたものです。
+-----------------+
|Device requesting|
| network access |
+-----------------+
| ^
| |
(1) Request for access
| |
| (4) Success/Failure
v |
+-----------------+
| NAS |
|(IEEE 802.1X and |
|DHCP relay agent}|
+-----------------+
| ^
| |
(2) Request for authentication
| |
| (3) Access-Accept/Reject
v |
+-----------------+
| RADIUS |
| Server |
+-----------------+
Figure 1
図1
The access device acts as an IEEE 802.1X Authenticator and adds a DHCP relay agent option that includes a RADIUS Attributes suboption to DHCP messages. At the successful conclusion of IEEE 802.1X authentication, a RADIUS Access-Accept provides attributes for service authorizations to the NAS. The NAS stores these attributes locally. When the NAS subsequently relays DHCP messages from the network device, the NAS adds these attributes in a RADIUS Attributes suboption. The RADIUS Attributes suboption is another suboption of the Relay Agent Information option [5].
アクセスデバイスはIEEE 802.1X認証システムとして機能し、RADIUS属性サブオプションを含むDHCPリレーエージェントオプションをDHCPメッセージに追加します。 IEEE 802.1X認証が正常に終了すると、RADIUS Access-AcceptはNASにサービス許可の属性を提供します。 NASはこれらの属性をローカルに保存します。 NASがその後ネットワークデバイスからDHCPメッセージをリレーすると、NASはこれらの属性をRADIUS属性サブオプションに追加します。 RADIUS Attributesサブオプションは、Relay Agent Informationオプション[5]の別のサブオプションです。
The RADIUS Attributes suboption described in this document is not limited to use in conjunction with IEEE 802.1X and can be used to carry RADIUS attributes obtained by the relay agent for any reason. That is, the option is not limited to use with IEEE 802.1X but is constrained by RADIUS semantics (see Section 4).
このドキュメントで説明するRADIUS属性サブオプションは、IEEE 802.1Xと組み合わせて使用することに限定されず、何らかの理由でリレーエージェントが取得したRADIUS属性を伝送するために使用できます。 つまり、このオプションはIEEE 802.1Xでの使用に限定されず、RADIUSセマンティクスによって制限されます（セクション4を参照）。
The scope of applicability of this specification is such that robust interoperability is only guaranteed for RADIUS service implementations that exist within the same scope as does the DHCP service implementation, i.e., within a single, localized administrative domain. Global interoperability of this specification, across administrative domains, is not required.
この仕様の適用範囲は、堅牢な相互運用性が、DHCPサービス実装と同じスコープ内、つまり単一のローカライズされた管理ドメイン内に存在するRADIUSサービス実装に対してのみ保証されるようなものです。 管理ドメイン間でのこの仕様のグローバルな相互運用性は必要ありません。
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 RFC 2119 [3].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は RFC 2119 [3]で説明されているように解釈されます。
Within this specification, the use of the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" is with respect to RADIUS clients and servers that implement the optional features of this specification. The use of these key words does not create any normative requirements outside of that scope, and does not modify the base RADIUS specifications, such as RFC 2865 [4].
この仕様では、キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および 「オプション」は、この仕様のオプション機能を実装するRADIUSクライアントおよびサーバーに関するものです。 これらのキーワードの使用は、その範囲外の規範的な要件を作成せず、RFC 2865 [4]などの基本RADIUS仕様を変更しません。
The following terms are used as defined in RFC 2131 and RFC 3046: DHCP relay agent, DHCP server, DHCP client.
RFC 2131およびRFC 3046で定義されているように、DHCPリレーエージェント、DHCPサーバー、DHCPクライアントという用語が使用されます。
The following terms are used in conjunction with RADIUS:
次の用語はRADIUSと組み合わせて使用されます。
RADIUS server: A RADIUS server is responsible for receiving user connection requests, authenticating the user, and then returning all configuration information necessary for the client to deliver service to the user.
RADIUSサーバー：RADIUSサーバーは、ユーザー接続要求を受信し、ユーザーを認証し、クライアントがユーザーにサービスを提供するために必要なすべての構成情報を返す役割を果たします。
Attribute: A Type-Length-Value tuple encapsulating data elements as defined in RFC 2865 [4].
属性：RFC 2865 [4]で定義されているデータ要素をカプセル化するType-Length-Valueタプル。
NAS: A Network Access Server (NAS) provides access to the network and operates as a client of RADIUS. The client is responsible for passing user information to designated RADIUS servers and then acting on the response that is returned. Unlike a traditional dial NAS, the NAS considered here may not have a protocol such as PPP through which it can pass configuration information from the RADIUS attributes to the client.
NAS：ネットワークアクセスサーバー（NAS）は、ネットワークへのアクセスを提供し、RADIUSのクライアントとして動作します。 クライアントは、指定されたRADIUSサーバーにユーザー情報を渡し、返された応答に基づいて動作します。 従来のダイヤルNASとは異なり、ここで検討するNASには、RADIUS属性からクライアントに構成情報を渡すことができるPPPなどのプロトコルがない場合があります。
The following terms are used as defined in the IEEE 802.1X protocol: Authenticator, Supplicant.
次の用語は、IEEE 802.1Xプロトコルで定義されているとおりに使用されます。認証者、サプリカント。
The RADIUS Attributes suboption is a new suboption for the DHCP Relay Agent option.
RADIUS属性サブオプションは、DHCPリレーエージェントオプションの新しいサブオプションです。
The format of the RADIUS Attributes suboption is as follows:
RADIUS Attributesサブオプションの形式は次のとおりです。
SubOpt Len RADIUS attributes
code
+-------+-----+------+------+------+------+--...-+------+
| 7 | N | o1 | o2 | o3 | o4 | | oN |
+-------+-----+------+------+------+------+--...-+------+
The RADIUS attributes are encoded according to the encoding rules in RFC 2865, in octets o1...oN.
RADIUS属性は、RFC 2865のエンコード規則に従って、オクテットo1 ... oNでエンコードされます。
The DHCP relay agent truncates the RADIUS attributes to fit in the RADIUS Attributes suboption.
DHCPリレーエージェントは、RADIUS属性サブオプションに収まるようにRADIUS属性を切り捨てます。
When the DHCP relay agent receives a DHCP message from the client, it MAY append a DHCP Relay Agent Information option containing the RADIUS Attributes suboption, along with any other suboptions it is configured to supply. The RADIUS Attributes suboption MUST only contain the attributes provided in the RADIUS Access/Accept message. The DHCP relay agent MUST NOT add more than one RADIUS Attributes suboption in a message.
DHCPリレーエージェントがクライアントからDHCPメッセージを受信すると、提供するように設定されている他のサブオプションとともに、RADIUS属性サブオプションを含むDHCPリレーエージェント情報オプションを追加できます。 RADIUS属性サブオプションには、RADIUS Access / Acceptメッセージで提供される属性のみを含める必要があります。 DHCPリレーエージェントは、メッセージに複数のRADIUS属性サブオプションを追加してはなりません。
The relay agent MUST include the User-Name and Framed-Pool attributes in the RADIUS Attributes suboption, if they are available, and MAY include other attributes.
リレーエージェントは、利用可能な場合、RADIUS属性サブオプションにUser-NameおよびFramed-Pool属性を含める必要があり、他の属性を含めることができます。
To avoid dependencies between the address allocation and other state information between the RADIUS server and the DHCP server, the DHCP relay agent SHOULD include only the attributes in the table below in an instance of the RADIUS Attributes suboption. The table, based on the analysis in RFC 3580 [8], lists attributes that MAY be included:
RADIUSサーバーとDHCPサーバー間のアドレス割り当てと他の状態情報との依存関係を避けるために、DHCPリレーエージェントは、RADIUS属性サブオプションのインスタンスに以下の表の属性のみを含める必要があります。 RFC 3580 [8]の分析に基づいた表には、含めることができる属性がリストされています。
# Attribute
--- ---------
1 User-Name (RFC 2865 [3])
6 Service-Type (RFC 2865)
26 Vendor-Specific (RFC 2865)
27 Session-Timeout (RFC 2865)
88 Framed-Pool (RFC 2869)
100 Framed-IPv6-Pool (RFC 3162 [7])
When the DHCP server receives a message from a relay agent containing a RADIUS Attributes suboption, it extracts the contents of the suboption and uses that information in selecting configuration parameters for the client. If the relay agent relays RADIUS attributes not included in the table in Section 4, the DHCP server SHOULD ignore them. If the DHCP server uses attributes not specified here, it might result in side effects not anticipated in the existing RADIUS specifications.
DHCPサーバーは、RADIUS属性サブオプションを含むメッセージをリレーエージェントから受信すると、サブオプションの内容を抽出し、その情報を使用してクライアントの構成パラメーターを選択します。 リレーエージェントがセクション4の表に含まれていないRADIUS属性をリレーする場合、DHCPサーバーはそれらを無視する必要があります。 DHCPサーバーがここで指定されていない属性を使用する場合、既存のRADIUS仕様では予期されない副作用が発生する可能性があります。
Relay agent options are exchanged only between relay agents and the DHCP server, so DHCP clients are never aware of their use.
リレーエージェントオプションはリレーエージェントとDHCPサーバー間でのみ交換されるため、DHCPクライアントはその使用を認識しません。
Message authentication in DHCP for intradomain use where the out-of-band exchange of a shared secret is feasible is defined in RFC 3118 [6]. Potential exposures to attack are discussed in section 7 of the DHCP protocol specification in RFC 2131 [1].
共有シークレットの帯域外交換が実行可能なドメイン内使用のためのDHCPのメッセージ認証は、RFC 3118 [6]で定義されています。 攻撃にさらされる可能性については、RFC 2131 [1]のDHCPプロトコル仕様のセクション7で説明されています。
The DHCP Relay Agent option depends on a trusted relationship between the DHCP relay agent and the server, as described in section 5 of RFC 3046 [5]. Although the introduction of fraudulent relay-agent options can be prevented by a perimeter defense that blocks these options unless the relay agent is trusted, a deeper defense using the authentication option for relay agent options [9] or IPsec [10] SHOULD be deployed as well.
DHCPリレーエージェントオプションは、RFC 3046 [5]のセクション5で説明されているように、DHCPリレーエージェントとサーバー間の信頼関係に依存します。 不正なリレーエージェントオプションの導入は、リレーエージェントが信頼されない限り、これらのオプションをブロックする境界防御によって防止できますが、リレーエージェントオプション[9]またはIPsec [10]の認証オプションを使用したより深い防御は、 まあ。
IANA has assigned the value of 7 for the DHCP Relay Agent Information option suboption code for this suboption. This document does not define any new namespaces or other constants for which IANA must maintain a registry.
IANAは、このサブオプションのDHCPリレーエージェント情報オプションサブオプションコードに値7を割り当てました。 このドキュメントは、IANAがレジストリを維持しなければならない新しい名前空間またはその他の定数を定義しません。
Expert advice from Bernard Aboba, Paul Funk, David Nelson, Ashwin Palekar, and Greg Weber on avoiding RADIUS entanglements is gratefully acknowledged.
RADIUSのエンタングルメントの回避に関するBernard Aboba、Paul Funk、David Nelson、Ashwin Palekar、およびGreg Weberからの専門家のアドバイスは感謝されます。
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[1] Droms、R。、「動的ホスト構成プロトコル」、RFC 2131、1997年3月。
[2] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port based Network Access Control", IEEE Standard 802.1X, March 2001.
[2]電気電子技術者協会、「ローカルおよびメトロポリタンエリアネットワーク：ポートベースのネットワークアクセス制御」、IEEE標準802.1X、2001年3月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[4] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[4]リグニー、C。、ウィレンス、S。、ルーベンス、A。、およびW.シンプソン、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[5] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[5]パトリック、M。、「DHCPリレーエージェント情報オプション」、RFC 3046、2001年1月。
[6] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[6] Droms、R。、およびW. Arbaugh、「DHCPメッセージの認証」、RFC 3118、2001年6月。
[7] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
[7] Aboba、B.、Zorn、G。、およびD. Mitton、「RADIUS and IPv6」、RFC 3162、2001年8月。
[8] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003.
[8] Congdon、P.、Aboba、B.、Smith、A.、Zorn、G。、およびJ. Roese、「IEEE 802.1Xリモート認証ダイヤルインユーザーサービス（RADIUS）使用ガイドライン」、RFC 3580、2003年9月 。
[9] Stapp, M. and T. Lemon, "The Authentication Suboption for the DHCP Relay Agent Option", Work in Progress, October 2003.
[9] Stapp、M。、およびT. Lemon、「DHCPリレーエージェントオプションの認証サブオプション」、Work in Progress、2003年10月。
[10] Droms, R., "Authentication of DHCP Relay Agent Options Using IPsec", Work in Progress, September 2003.
[10] Droms、R。、「IPsecを使用したDHCPリレーエージェントオプションの認証」、Work in Progress、2003年9月。
Authors' Addresses
著者のアドレス
Ralph Droms Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719 USA
Ralph Droms Cisco Systems 1414 Massachusetts Avenue Boxborough、MA 01719 USA
EMail: rdroms@cisco.com
メール：rdroms@cisco.com
John Schnizlein Cisco Systems 9123 Loughran Road Fort Washington, MD 20744 USA
John Schnizlein Cisco Systems 9123 Loughran Road Fort Washington、MD 20744 USA
EMail: jschnizl@cisco.com
メール：jschnizl@cisco.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、制限の対象となります。また、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本書および本書に含まれる情報は「現状のまま」提供され、寄稿者、代表者または代表者（もしあれば）、インターネット協会、インターネットエンジニアリングタスクフォースはすべての保証を放棄します 黙示的であるが、ここに記載されている情報の使用が商品性または特定の目的への適合性の黙示的保証を侵害しないという保証に限定されない。
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 IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、本書に記載されている技術の実装または使用に関連すると主張される可能性のある知的財産権またはその他の権利の有効性または範囲、またはそのような権利の下でのライセンスの有無に関して、立場をとりません。 利用可能 また、そのような権利を特定するための独立した努力を行ったことを表すものでもありません。 IETFドキュメントの権利に関するIETFの手順に関する情報は、BCP 78およびBCP 79にあります。
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.
IETF事務局に行われたIPR開示のコピーおよび利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによる一般的なライセンスまたはそのような所有権の使用許可の取得を試みた結果を取得できます。 IETFオンラインIPRリポジトリ（http://www.ietf.org/ipr）から。
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のietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能の資金は、現在インターネット協会によって提供されています。