[要約] RFC 4014は、DHCPリレーエージェント情報オプションのためのRADIUS属性サブオプションに関するものです。このRFCの目的は、RADIUSサーバーとDHCPリレーエント間の通信を改善し、ネットワークの認証と認可を強化することです。
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
リモート認証ダイヤルインユーザーサービス（RADIUS）属性ダイナミックホスト構成プロトコル（DHCP）リレーエージェント情報オプションのサブオプション
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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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属性Suboptionにより、ネットワーク要素は、DHCPサーバーへのRADIUS認証中に受信された識別と承認属性を渡すことができます。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がデバイスのユーザーのアイデンティティを認証する前に、認証サービスとしてRADIUSを使用してレイヤー2ネットワークアクセスを提供するメカニズムの例です。RFC 3580 [8]で指定されています。IEEE 802.1x認証アクセスでは、デバイスはまずNASといくつかの認証資格情報を交換する必要があります。その後、NASはこれらの資格情報をRADIUSサーバーに提供し、最終的にアクセスリケストに応じてアクセス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認証器として機能し、DHCPメッセージへのRADIUS属性サブオプションを含むDHCPリレーエージェントオプションを追加します。IEEE 802.1x認証の結論が成功したため、RADIUS Access-AcceptはNASへのサービス許可の属性を提供します。NASはこれらの属性をローカルに保存します。NASがその後、ネットワークデバイスからDHCPメッセージをリレーすると、NASはこれらの属性をRADIUS属性サブオプションに追加します。RADIUS属性Suboptionは、リレーエージェント情報オプションのもう1つのサブオプションです[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と組み合わせて使用することに限定されず、何らかの理由でリレーエージェントが取得した半径属性を運ぶために使用できます。つまり、オプションはIEEE 802.1xで使用することではなく、半径セマンティクスによって制約されます（セクション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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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].
この仕様の中で、キーワードの「必須」、「必須」、「必須」、「shill」、「suff "、" nove "、" buld "、" becommended "、" may "、and"、 "、and"、 "sult" nove "、" sult "nove"、 "sult" nove "、" suld "nove"、 "bured"、 "suld" nove "は使用したりする必要があります」「オプション」は、この仕様のオプションの機能を実装するRADIUSクライアントとサーバーに関するものです。これらのキーワードを使用しても、その範囲以外の規範的要件は作成されず、RFC 2865 [4]などの基本半径仕様を変更しません。
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 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]で定義されているように、データ要素をカプセル化するタイプ長価値タプル。
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は、PPPなどのプロトコルを持っていない場合があります。PPPは、RADIUS属性からクライアントに構成情報を渡すことができます。
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属性Suboptionは、DHCPリレーエージェントオプションの新しいサブオプションです。
The format of the RADIUS Attributes suboption is as follows:
RADIUS属性の形式は次のとおりです。
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アクセス/受け入れメッセージに提供される属性のみを含める必要があります。DHCPリレーエージェントは、メッセージにSuboptionを1つ以上追加してはなりません。
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属性のサブオプションにユーザー名とフレームプール属性を含める必要があり、他の属性を含めることができます。
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のテーブルに含まれていないRERAYSARYIUS属性をリレーする場合、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で説明されているように、DHCPリレーエージェントとサーバーの間の信頼できる関係に依存します[5]。詐欺的なリレーエージェントオプションの導入は、リレーエージェントが信頼されない限り、これらのオプションをブロックする境界防御によって防止できますが、リレーエージェントオプションの認証オプションを使用したより深い防御[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.
Bernard Aboba、Paul Funk、David Nelson、Ashwin Palekar、およびGreg Weberからの専門家のアドバイスは、radiusの絡み合いを回避することに感謝しています。
[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 Standard 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] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[5] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[5] Patrick、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。and T. Lemon、「DHCPリレーエージェントオプションの認証サブオプション」、2003年10月の作業。
[10] Droms, R., "Authentication of DHCP Relay Agent Options Using IPsec", Work in Progress, September 2003.
[10] DROMS、R。、「IPSECを使用したDHCPリレーエージェントオプションの認証」、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
John Schnizlein Cisco Systems 9123 Loughran Road Fort Washington, MD 20744 USA
ジョン・シュニズレイン・シスコ・システム9123ラフラン・ロード・フォート・ワシントン、メリーランド州20744米国
EMail: jschnizl@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。