[要約] RFC 3162は、RADIUSプロトコルとIPv6の統合に関するガイドラインを提供しています。その目的は、RADIUSサーバーとIPv6ネットワークの間での認証、認可、およびアカウンティングのサポートを向上させることです。
Network Working Group B. Aboba
Request for Comments: 3162 Microsoft
Category: Standards Track G. Zorn
Cisco Systems
D. Mitton
Circular Logic UnLtd.
August 2001
RADIUS and IPv6
RADIUSおよびIPv6
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 (2001). All Rights Reserved.
Copyright（C）The Internet Society（2001）。全著作権所有。
Abstract
概要
This document specifies the operation of RADIUS (Remote Authentication Dial In User Service) when run over IPv6 as well as the RADIUS attributes used to support IPv6 network access.
このドキュメントでは、IPv6を介して実行する場合のRADIUS（リモート認証ダイヤルインユーザーサービス）の動作と、IPv6ネットワークアクセスをサポートするために使用されるRADIUS属性について説明します。
This document specifies the operation of RADIUS [4]-[8] over IPv6 [13] as well as the RADIUS attributes used to support IPv6 network access.
このドキュメントでは、IPv6 [13]を介したRADIUS [4]〜[8]の動作と、IPv6ネットワークアクセスをサポートするために使用されるRADIUS属性について説明します。
Note that a NAS sending a RADIUS Access-Request may not know a-priori whether the host will be using IPv4, IPv6, or both. For example, within PPP, IPv6CP [11] occurs after LCP, so that address assignment will not occur until after RADIUS authentication and authorization has completed.
RADIUSアクセス要求を送信するNASは、ホストがIPv4、IPv6、またはその両方を使用するかどうかを事前に知らない場合があることに注意してください。たとえば、PPP内では、IPv6CP [11]はLCPの後に発生するため、RADIUS認証と承認が完了するまでアドレス割り当ては発生しません。
Therefore it is presumed that the IPv6 attributes described in this document MAY be sent along with IPv4-related attributes within the same RADIUS message and that the NAS will decide which attributes to use. The NAS SHOULD only allocate addresses and prefixes that the client can actually use, however. For example, there is no need for the NAS to reserve use of an IPv4 address for a host that only supports IPv6; similarly, a host only using IPv4 or 6to4 [12] does not require allocation of an IPv6 prefix.
したがって、このドキュメントで説明されているIPv6属性は、同じRADIUSメッセージ内のIPv4関連の属性と一緒に送信される可能性があり、NASが使用する属性を決定すると想定されています。ただし、NASは、クライアントが実際に使用できるアドレスとプレフィックスのみを割り当てる必要があります（SHOULD）。たとえば、NASがIPv6のみをサポートするホストのIPv4アドレスの使用を予約する必要はありません。同様に、IPv4または6to4 [12]のみを使用するホストは、IPv6プレフィックスの割り当てを必要としません。
The NAS can provide IPv6 access natively, or alternatively, via other methods such as IPv6 within IPv4 tunnels [15] or 6over4 [14]. The choice of method for providing IPv6 access has no effect on RADIUS usage per se, although if it is desired that an IPv6 within IPv4 tunnel be opened to a particular location, then tunnel attributes should be utilized, as described in [6], [7].
NASはIPv6アクセスをネイティブに提供することも、IPv4トンネル内のIPv6 [15]や6over4 [14]などの他の方法を介して提供することもできます。 IPv6アクセスを提供する方法の選択は、RADIUSの使用自体には影響しませんが、[6]で説明されているように、IPv4トンネル内のIPv6を特定の場所に開くことが望ましい場合は、トンネル属性を利用する必要があります。 7]。
In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [1].
このドキュメントでは、キーワード「MAY」、「MUST、「MUST NOT」、「optional」、「recommended」、「SHOULD」、および「SHOULD NOT」は、[1]で説明されているように解釈されます。
Description
説明
This Attribute indicates the identifying IPv6 Address of the NAS which is requesting authentication of the user, and SHOULD be unique to the NAS within the scope of the RADIUS server. NAS-IPv6-Address is only used in Access-Request packets. NAS-IPv6- Address and/or NAS-IP-Address MAY be present in an Access-Request packet; however, if neither attribute is present then NAS-Identifier MUST be present.
この属性は、ユーザーの認証を要求しているNASの識別IPv6アドレスを示し、RADIUSサーバーのスコープ内でNASに対して一意である必要があります。 NAS-IPv6-Addressは、Access-Requestパケットでのみ使用されます。 NAS-IPv6-アドレスおよび/またはNAS-IP-アドレスは、アクセス要求パケットに存在する場合があります。ただし、どちらの属性も存在しない場合は、NAS-Identifierが存在する必要があります。
A summary of the NAS-IPv6-Address Attribute format is shown below. The fields are transmitted from left to right.
NAS-IPv6-Address 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 | Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
95 for NAS-IPv6-Address
NAS-IPv6-Addressの場合は95
Length
長さ
18
１８
Address
住所
The Address field is 16 octets.
アドレスフィールドは16オクテットです。
Description
説明
This Attribute indicates the IPv6 interface identifier to be configured for the user. It MAY be used in Access-Accept packets. If the Interface-Identifier IPv6CP option [11] has been successfully negotiated, this Attribute MUST be included in an Access-Request packet as a hint by the NAS to the server that it would prefer that value. It is recommended, but not required, that the server honor the hint.
この属性は、ユーザーに対して構成するIPv6インターフェースIDを示します。 Access-Acceptパケットで使用される場合があります。 Interface-Identifier IPv6CPオプション[11]が正常にネゴシエートされた場合、この属性は、NASがその値を優先するというヒントをNASからサーバーに通知するために、Access-Requestパケットに含める必要があります。サーバーがヒントを尊重することをお勧めしますが、必須ではありません。
A summary of the Framed-Interface-Id Attribute format is shown below. The fields are transmitted from left to right.
Framed-Interface-Id 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 | Interface-Id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Interface-Id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Interface-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
96 for Framed-Interface-Id
Framed-Interface-Idの場合は96
Length
長さ
10
１０
Interface-Id
インターフェースID
The Interface-Id field is 8 octets.
Interface-Idフィールドは8オクテットです。
Description
説明
This Attribute indicates an IPv6 prefix (and corresponding route) to be configured for the user. It MAY be used in Access-Accept packets, and can appear multiple times. It MAY be used in an Access-Request packet as a hint by the NAS to the server that it would prefer these prefix(es), but the server is not required to honor the hint. Since it is assumed that the NAS will plumb a route corresponding to the prefix, it is not necessary for the server to also send a Framed-IPv6-Route attribute for the same prefix.
この属性は、ユーザーに構成するIPv6プレフィックス（および対応するルート）を示します。 Access-Acceptパケットで使用される場合があり、複数回出現する可能性があります。 NASからサーバーへのヒントとして、これらの接頭辞を優先することをAccess-Requestパケットで使用できますが、サーバーはヒントを尊重する必要はありません。 NASがプレフィックスに対応するルートをplumbすることが想定されているため、サーバーが同じプレフィックスのFramed-IPv6-Route属性も送信する必要はありません。
A summary of the Framed-IPv6-Prefix Attribute format is shown below. The fields are transmitted from left to right.
Framed-IPv6-Prefix 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 | Reserved | Prefix-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
97 for Framed-IPv6-Prefix
Framed-IPv6-Prefixの場合は97
Length
長さ
At least 4 and no larger than 20.
4以上20以下。
Reserved
予約済み
This field, which is reserved and MUST be present, is always set to zero.
このフィールドは予約されており、存在する必要がありますが、常にゼロに設定されています。
Prefix-Length
プレフィックス長
The length of the prefix, in bits. At least 0 and no larger than 128.
接頭辞の長さ（ビット単位）。 0以上128以下。
Prefix
接頭辞
The Prefix field is up to 16 octets in length. Bits outside of the Prefix-Length, if included, must be zero.
プレフィックスフィールドの長さは最大16オクテットです。含まれている場合、Prefix-Lengthの外側のビットはゼロでなければなりません。
Description
説明
This Attribute indicates the system with which to connect the user, when the Login-Service Attribute is included. It MAY be used in Access-Accept packets. It MAY be used in an Access-Request packet as a hint to the server that the NAS would prefer to use that host, but the server is not required to honor the hint.
この属性は、Login-Service属性が含まれている場合に、ユーザーを接続するシステムを示します。 Access-Acceptパケットで使用される場合があります。 NASがそのホストを使用することを好むサーバーへのヒントとしてAccess-Requestパケットで使用される場合がありますが、サーバーはヒントを尊重する必要はありません。
A summary of the Login-IPv6-Host Attribute format is shown below. The fields are transmitted from left to right.
Login-IPv6-Host 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 | Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
98 for Login-IPv6-Host
Login-IPv6-Hostの98
Length
長さ
18
１８
Address
住所
The Address field is 16 octets in length. The value 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF indicates that the NAS SHOULD allow the user to select an address or name to be connected to. The value 0 indicates that the NAS SHOULD select a host to connect the user to. Other values indicate the address the NAS SHOULD connect the user to.
アドレスフィールドの長さは16オクテットです。値0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFは、NASがユーザーが接続するアドレスまたは名前を選択できるようにする必要があることを示します。値0は、NASがユーザーを接続するホストを選択する必要があることを示します。他の値は、NASがユーザーを接続する必要があるアドレスを示します。
Description
説明
This Attribute provides routing information to be configured for the user on the NAS. It is used in the Access-Accept packet and can appear multiple times.
この属性は、NASのユーザーに対して構成するルーティング情報を提供します。 Access-Acceptパケットで使用され、複数回出現する可能性があります。
A summary of the Framed-IPv6-Route Attribute format is shown below. The fields are transmitted from left to right.
Framed-IPv6-Route Attribute形式の要約を以下に示します。フィールドは左から右に送信されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | Text ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
タイプ
99 for Framed-IPv6-Route
Framed-IPv6-Routeの場合は99
Length
長さ
>=3
＞＝３
Text
テキスト
The Text field is one or more octets, and its contents are implementation dependent. The field is not NUL (hex 00) terminated. It is intended to be human readable and MUST NOT affect operation of the protocol.
Textフィールドは1つ以上のオクテットであり、その内容は実装に依存します。フィールドはNUL（16進00）で終了していません。それは人間が読めるように意図されており、プロトコルの操作に影響を与えてはなりません。
For IPv6 routes, it SHOULD contain a destination prefix optionally followed by a slash and a decimal length specifier stating how many high order bits of the prefix to use. That is followed by a space, a gateway address, a space, and one or more metrics (encoded in decimal) separated by spaces. Prefixes and addresses are formatted as described in [16]. For example, "2000:0:0:106::/64 2000::106:a00:20ff:fe99:a998 1".
IPv6ルートの場合、オプションで、その後にスラッシュと、使用する接頭辞の上位ビットの数を示す10進数の長さ指定子が続く宛先接頭辞を含める必要があります（SHOULD）。その後に、スペース、ゲートウェイアドレス、スペース、およびスペースで区切られた1つ以上のメトリック（10進数でエンコード）が続きます。プレフィックスとアドレスは、[16]で説明されているようにフォーマットされます。たとえば、「2000：0：0：106 :: / 64 2000 :: 106：a00：20ff：fe99：a998 1」です。
Whenever the gateway address is the IPv6 unspecified address the IP address of the user SHOULD be used as the gateway address. The unspecified address can be expressed in any of the acceptable formats described in [16]. For example, "2000:0:0:106::/64 :: 1".
ゲートウェイアドレスがIPv6未指定アドレスである場合は常に、ユーザーのIPアドレスをゲートウェイアドレスとして使用する必要があります（SHOULD）。未指定のアドレスは、[16]で説明されている受け入れ可能な形式のいずれかで表すことができます。たとえば、「2000：0：0：106 :: / 64 :: 1」です。
Description
説明
This Attribute contains the name of an assigned pool that SHOULD be used to assign an IPv6 prefix for the user. If a NAS does not support multiple prefix pools, the NAS MUST ignore this Attribute.
この属性には、ユーザーにIPv6プレフィックスを割り当てるために使用する必要がある割り当て済みプールの名前が含まれています。 NASが複数のプレフィックスプールをサポートしない場合、NASはこの属性を無視する必要があります。
A summary of the Framed-IPv6-Pool Attribute format is shown below. The fields are transmitted from left to right.
Framed-IPv6-Pool Attribute形式の要約を以下に示します。フィールドは左から右に送信されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
100 for Framed-IPv6-Pool
Framed-IPv6-Poolの場合は100
Length
長さ
>= 3
＞＝ ３
String
ストリング
The string field contains the name of an assigned IPv6 prefix pool configured on the NAS. The field is not NUL (hex 00) terminated.
文字列フィールドには、NASで構成された、割り当てられたIPv6プレフィックスプールの名前が含まれます。フィールドはNUL（16進00）で終了していません。
The following table provides a guide to which attributes may be found in which kinds of packets, and in what quantity.
次の表は、どの種類のパケットで、どのような量の属性が見つかるかのガイドです。
Request Accept Reject Challenge Accounting # Attribute Request 0-1 0 0 0 0-1 95 NAS-IPv6-Address 0-1 0-1 0 0 0-1 96 Framed-Interface-Id 0+ 0+ 0 0 0+ 97 Framed-IPv6-Prefix 0+ 0+ 0 0 0+ 98 Login-IPv6-Host 0 0+ 0 0 0+ 99 Framed-IPv6-Route 0 0-1 0 0 0-1 100 Framed-IPv6-Pool
Request Accept Reject Challenge Accounting＃Attribute Request 0-1 0 0 0 0-1 95 NAS-IPv6-Address 0-1 0-1 0 0 0-1 96 Framed-Interface-Id 0+ 0+ 0 0 0+ 97 Framed -IPv6-Prefix 0+ 0+ 0 0 0+ 98 Login-IPv6-Host 0 0+ 0 0 0+ 99 Framed-IPv6-Route 0 0-1 0 0 0-1 100 Framed-IPv6-Pool
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March, 1997.
[1] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, October 1996.
[2] Yergeau、F。、「UTF-8、UnicodeおよびISO 10646の変換フォーマット」、RFC 2044、1996年10月。
[3] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999.
[3] Aboba、B.およびJ. Vollbrecht、「Proxy Chaining and Policy Implementation in Roaming」、RFC 2607、1999年6月。
[4] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[4] リグニー、C。、ルーベンス、A。、シンプソン、W.、S。ウィレンス、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[5] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[5] リグニー、C。、「RADIUSアカウンティング」、RFC 2866、2000年6月。
[6] Zorn, G., Mitton, D. and B. Aboba, "RADIUS Accounting Modifications for Tunnel Protocol Support", RFC 2867, June 2000.
[6] Zorn、G.、Mitton、D。およびB. Aboba、「トンネルプロトコルサポートのためのRADIUSアカウンティング修正」、RFC 2867、2000年6月。
[7] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000.
[7] Zorn、G.、Leifer、D.、Rubens、A.、Shriver、J.、Holdrege、M. and I. Goyret、 "RADIUS Attributes for Tunnel Protocol Support"、RFC 2868、June 2000。
[8] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000.
[8] リグニー、C。、ウィラッツ、W.、P。カルホーン、「RADIUS Extensions」、RFC 2869、2000年6月。
[9] Kent S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[9] ケントS.およびR.アトキンソン、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[10] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[10] Alvestrand、H。およびT. Narten、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[11] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, December 1998.
[11] Haskin、D。およびE. Allen、「IPバージョン6 over PPP」、RFC 2472、1998年12月。
[12] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[12] カーペンター、B。およびK.ムーア、「IPv4クラウドを介したIPv6ドメインの接続」、RFC 3056、2001年2月。
[13] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[13] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[14] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999.
[14] Carpenter、B。およびC. Jung、「明示的なトンネルのないIPv4ドメインを介したIPv6の転送」、RFC 2529、1999年3月。
[15] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000.
[15] Gilligan、R.およびE. Nordmark、「Transition Mechanisms for IPv6 Hosts and Routers」、RFC 2893、2000年8月。
[16] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[16] Hinden、R. and S. Deering、「IP Version 6 Addressing Architecture」、RFC 2373、1998年7月。
This document describes the use of RADIUS for the purposes of authentication, authorization and accounting in IPv6-enabled networks. In such networks, the RADIUS protocol may run either over IPv4 or over IPv6. Known security vulnerabilities of the RADIUS protocol are described in [3], [4] and [8].
このドキュメントでは、IPv6対応ネットワークでの認証、承認、アカウンティングを目的としたRADIUSの使用について説明します。このようなネットワークでは、RADIUSプロトコルはIPv4またはIPv6のいずれかで実行できます。 RADIUSプロトコルの既知のセキュリティ脆弱性は、[3]、[4]、および[8]で説明されています。
Since IPSEC [9] is mandatory to implement for IPv6, it is expected that running RADIUS implementations supporting IPv6 will typically run over IPSEC. Where RADIUS is run over IPSEC and where certificates are used for authentication, it may be desirable to avoid management of RADIUS shared secrets, so as to leverage the improved scalability of public key infrastructure.
IPv6の実装にはIPSEC [9]が必須であるため、IPv6をサポートするRADIUS実装を実行すると、通常IPSECで実行されることが予想されます。 RADIUSがIPSEC上で実行され、証明書が認証に使用される場合、RADIUS共有シークレットの管理を回避して、公開鍵インフラストラクチャの向上したスケーラビリティを活用することが望ましい場合があります。
Within RADIUS, a shared secret is used for hiding of attributes such as User-Password [4] and Tunnel-Password [7]. In addition, the shared secret is used in computation of the Response Authenticator [4], as well as the Message-Authenticator attribute [8]. Therefore, in RADIUS a shared secret is used to provide confidentiality as well as integrity protection and authentication. As a result, only use of IPSEC ESP with a non-null transform can provide security services sufficient to substitute for RADIUS application-layer security. Therefore, where IPSEC AH or ESP null is used, it will typically still be necessary to configure a RADIUS shared secret.
RADIUS内では、共有シークレットを使用して、User-Password [4]やTunnel-Password [7]などの属性を非表示にします。さらに、共有シークレットは、応答認証子の計算[4]と、メッセージ認証子属性[8]で使用されます。したがって、RADIUSでは、共有秘密を使用して、機密性と完全性の保護および認証を提供します。その結果、非ヌル変換を伴うIPSEC ESPの使用のみが、RADIUSアプリケーション層セキュリティの代わりに十分なセキュリティサービスを提供できます。したがって、IPSEC AHまたはESP nullが使用されている場合でも、RADIUS共有シークレットを構成する必要があります。
However, where RADIUS is run over IPSEC ESP with a non-null transform, the secret shared between the NAS and the RADIUS server MAY NOT be configured. In this case, a shared secret of zero length MUST be assumed.
ただし、RADIUSがnull以外の変換を使用してIPSEC ESPで実行される場合、NASとRADIUSサーバー間で共有されるシークレットは構成されない場合があります。この場合、長さがゼロの共有秘密を想定する必要があります。
This document requires the assignment of six new RADIUS attribute numbers for the following attributes:
このドキュメントでは、次の属性に6つの新しいRADIUS属性番号を割り当てる必要があります。
NAS-IPv6-Address Framed-Interface-Id Framed-IPv6-Prefix Login-IPv6-Host Framed-IPv6-Route Framed-IPv6-Pool
NAS-IPv6-Address Framed-Interface-Id Framed-IPv6-Prefix Login-IPv6-Host Framed-IPv6-Route Framed-IPv6-Pool
See section 3 for the registered list of numbers.
登録されている番号のリストについては、セクション3を参照してください。
The authors would like to acknowledge Jun-ichiro itojun Hagino of IIJ Research Laboratory, Darran Potter of Cisco and Carl Rigney of Lucent for contributions to this document.
このドキュメントへの寄稿者として、IIJ Research Laboratoryのitojun Jun-ichiro itojun Haigino、CiscoのDarran Potter、Carl Rigneyに謝意を表します。
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
バーナードアボバマイクロソフトコーポレーションワンマイクロソフトウェイレドモンド、ワシントン州98052
Phone: +1 425 936 6605
Fax: +1 425 936 7329
EMail: bernarda@microsoft.com
Glen Zorn Cisco Systems, Inc. 500 108th Avenue N.E., Suite 500 Bellevue, WA 98004
Glen Zorn Cisco Systems、Inc. 500 108th Avenue N.E.、Suite 500 Bellevue、WA 98004
Phone: +1 425 471 4861
EMail: gwz@cisco.com
Dave Mitton Circular Logic UnLtd. 733 Turnpike Street #154 North Andover, MA 01845
Dave Mitton Circular Logic UnLtd。 733 Turnpike Street＃154 North Andover、MA 01845
Phone: 978 683-1814 Email: david@mitton.com
電話：978 683-1814メール：david@mitton.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（C）The Internet Society（2001）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができます。ただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、この文書自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。