Loading article…
RADIUS（Remote Authentication Dial-In User Service ）は、ネットワークサービスに接続して利用するユーザーに対して、認証、認可、およびアカウンティング（ AAA ）を一元的に管理するネットワークプロトコルです。RADIUSは、1991年にLivingston Enterprisesによってアクセスサーバーの認証およびアカウンティングプロトコルとして開発されました。その後、 IEEE 802およびIETFの標準規格に組み込まれました。
RADIUSはアプリケーション層で動作するクライアント/サーバープロトコルであり、TCPまたはUDPのどちらでも使用できます。ネットワークへのアクセスを制御するネットワークアクセスサーバーには、通常、RADIUSサーバーと通信するRADIUSクライアントコンポーネントが含まれています。 [ 1 ] RADIUSは、802.1X認証のバックエンドとしてよく使用されます。[ 2 ] RADIUSサーバーは通常、UNIXまたはMicrosoft Windows上でバックグラウンドプロセスとして実行されます。[ 1 ]
Blast-RADIUS攻撃は、UDPのような暗号化されていないトランスポートプロトコルで実行されるとRADIUSを破ります。[ 3 ]
RADIUSは、ネットワークアクセスを管理するAAA（認証、認可、アカウンティング）プロトコルです。RADIUSは、認証と認可を管理するAccess-Requestと、アカウンティングを管理するAccounting-Requestという2種類のパケットを使用して、AAAプロセス全体を管理します。認証と認可はRFC 2865で定義され、アカウンティングはRFC 2866で説明されています。
ユーザーまたはマシンは、アクセス認証情報を使用して特定のネットワークリソースへのアクセス権を取得するために、ネットワークアクセスサーバー（NAS）にリクエストを送信します。認証情報は、リンク層プロトコル（例えば、多くのダイヤルアッププロバイダやDSLプロバイダの場合はポイントツーポイントプロトコル（PPP））を介してNASデバイスに渡されるか、 HTTPSで保護されたWebフォームに送信されます。
今度はNASがRADIUSサーバーにRADIUSアクセス要求メッセージを送信し、RADIUSプロトコルを介してアクセスを許可する許可を要求します。 [ 4 ]
この要求には、通常、ユーザー名とパスワード、またはユーザーが提供するセキュリティ証明書といったアクセス認証情報が含まれます。さらに、要求には、NASがユーザーについて把握しているその他の情報（ネットワークアドレスや電話番号など）、およびユーザーのNASへの物理的な接続ポイントに関する情報が含まれる場合があります。
RADIUSサーバーは、 PAP、CHAP、EAPなどの認証方式を使用して、情報が正しいかどうかを確認します。ユーザーの身元証明が検証されるとともに、必要に応じて、ユーザーのネットワークアドレスや電話番号、アカウントの状態、特定のネットワークサービスへのアクセス権限など、リクエストに関連するその他の情報も検証されます。従来、RADIUSサーバーはローカルに保存されたフラットファイルデータベースに対してユーザー情報をチェックしていました。最新のRADIUSサーバーは、この操作を実行できるほか、外部ソース（一般的にはSQL、Kerberos、LDAP、Active Directoryサーバーなど）を参照してユーザーの認証情報を検証することもできます。
RADIUSサーバーは、NASに対して次の3つの応答のうちの1つを返します。1) アクセス拒否、2) アクセス要求、3) アクセス承認。
これら3つのRADIUS応答にはそれぞれ、拒否理由、チャレンジのプロンプト、または承認時のウェルカムメッセージを示すReply-Message属性が含まれる場合があります。この属性のテキストは、返されたWebページでユーザーに渡されます。
認証属性は、許可されるアクセス条件を規定する形でNASに伝達されます。例えば、Access-Acceptには次のような認証属性が含まれる場合があります。
クライアントがRADIUSを使用するように設定されている場合、クライアントのユーザーは認証情報をクライアントに提示します。これは、ユーザーがユーザー名とパスワードを入力するカスタマイズ可能なログインプロンプトを使用する方法と、認証情報を含む認証パケットを持つポイントツーポイントプロトコル（PPP）などのリンクフレーミングプロトコルを使用する方法があります。
クライアントは、これらの情報を取得した後、RADIUSを使用して認証を行うことができます。その際、クライアントはユーザー名、パスワード、クライアントID、アクセス先のポートIDなどの属性を含む「アクセス要求」を作成します。パスワードが存在する場合は、RSAメッセージダイジェストアルゴリズムMD5に基づく方法で隠蔽されます。
会計処理についてはRFC 2866で説明されている。
NASがユーザーにネットワーク アクセスを許可すると、 NAS は RADIUS サーバーにアカウンティング スタート(値が "start" の Acct-Status-Type 属性を含む RADIUS アカウンティング リクエスト パケット) を送信して、ユーザーのネットワーク アクセスの開始を通知します。「Start」レコードには通常、ユーザーの識別情報、ネットワーク アドレス、接続ポイント、および一意のセッション 識別子が含まれます。[ 5 ]
NASは、アクティブなセッションの状態をRADIUSサーバーに更新するために、定期的に暫定更新レコード（値が「interim-update」のAcct-Status-Type属性を含むRADIUSアカウンティング要求パケット）を送信することがあります。「暫定」レコードには通常、現在のセッション期間と現在のデータ使用量に関する情報が含まれます。
最後に、ユーザーのネットワークアクセスが閉じられると、NASはRADIUSサーバーに最終的なアカウンティング停止レコード（値が「stop」のAcct-Status-Type属性を含むRADIUSアカウンティング要求パケット）を発行し、時間、転送されたパケット数、転送されたデータ数、切断理由、およびユーザーのネットワークアクセスに関連するその他の情報など、最終的な使用状況に関する情報を提供します。
通常、クライアントは一定のリトライ間隔を用いて、アカウンティングリクエストパケットを送信し、アカウンティングレスポンスの確認応答を受信するまで送信を続けます。
このデータの主な目的は、ユーザーに適切な料金を請求することです。また、このデータは統計目的や一般的なネットワーク監視にも広く利用されています。
RADIUSは、ISP間のローミングを容易にするために一般的に使用されており、以下のような用途があります。
RADIUSは、RADIUSサーバーがAAAリクエストを処理のために転送すべき場所を識別するレルムを使用することで、これを容易にします。
レルムは通常、ユーザー名に付加され、「@」記号で区切られます。これは、メールアドレスのドメイン名に似ています。これは、レルムの接尾辞表記法として知られています。もう1つの一般的な使用法は接頭辞表記法で、レルムをユーザー名の前に付加し、「\」を区切り文字として使用します。最新のRADIUSサーバーでは、レルムの区切り文字として任意の文字を使用できますが、実際には「@」と「\」が一般的に使用されます。
レルムは、接頭辞と接尾辞の両方の表記法を使用して組み合わせることもできます。これにより、複雑なローミングシナリオに対応できます。たとえば、somedomain.com\username@anotherdomain.com は、2 つのレルムを持つ有効なユーザー名になります。
レルムはドメインに似ていることが多いですが、レルムは任意のテキストであり、実際のドメイン名を含む必要はありません。レルムの形式はRFC 4282で標準化されており、ネットワークアクセス識別子（NAI）を「user@realm」の形式で定義しています。この仕様では、「realm」の部分はドメイン名である必要があります。ただし、この慣習は必ずしも守られているわけではありません。RFC 7542 [ 6 ]は2015年5月にRFC 4282に取って代わりました。
RADIUSサーバーがレルムを含むユーザー名のAAAリクエストを受信すると、設定済みのレルムのテーブルを参照します。レルムが既知の場合、サーバーはそのリクエストを当該ドメインの設定済みホームサーバーにプロキシします。プロキシサーバーによるリクエストからのレルムの削除（「ストリッピング」）の動作は、ほとんどのサーバーで設定に依存します。さらに、プロキシサーバーは、AAAリクエストが再度プロキシされる際に、リクエストを追加、削除、または書き換えるように設定できます。
RADIUSではプロキシチェーンが可能であり、認証/認可およびアカウンティングパケットは通常、一連のプロキシを介してNASデバイスとホームサーバー間でルーティングされます。プロキシチェーンを使用する利点には、スケーラビリティの向上、ポリシーの実装、機能の調整などがあります。しかし、ローミングシナリオでは、NAS、プロキシ、ホームサーバーは通常、異なる管理エンティティによって管理される可能性があります。そのため、このようなドメイン間アプリケーションでは、プロキシ間の信頼性がより重要になります。さらに、RADIUSにはエンドツーエンドのセキュリティがないため、関係するプロキシ間の信頼性の重要性が高まります。プロキシチェーンについては、RFC 2607で説明されています。
RADIUS を使用したローミングは、ユーザーにさまざまなセキュリティとプライバシーの懸念をもたらします。より一般的には、一部のローミング パートナーは、インターネット経由でプロキシされる際にユーザーの認証情報が傍受されないように、RADIUS サーバー間に安全なトンネルを確立します。RADIUS に組み込まれている MD5 ハッシュは安全ではないと考えられているため、これは懸念事項です。[ 7 ]
RADIUSはUDPのポート1812 [ 4 ]と1813 [ 8 ]で転送されます。RadSec（TLS上のRADIUS）はデフォルトでTCPポート2083を使用します[ 9 ] 。
RADIUSパケットのデータ形式を右図に示します。フィールドは左から右へ、コード、識別子、長さ、認証情報、属性の順に送信されます。
割り当てられたRADIUSコード（10進数）には以下が含まれます：[ 10 ]
識別子フィールドは、リクエストとレスポンスの照合に役立ちます。
Lengthフィールドは、Code、Identifier、Length、Authenticator、およびオプションのAttributeフィールドを含むRADIUSパケット全体の長さを示します。
オーセンティケーターは、RADIUSサーバーからの応答を認証するために使用され、パスワードの暗号化にも使用されます。その長さは16バイトです。
RADIUS属性値ペア（AVP）は、認証、認可、およびアカウンティングトランザクションのリクエストとレスポンスの両方にデータを格納します。RADIUSパケットの長さは、AVPの終了位置を特定するために使用されます。
RADIUSは拡張可能であり、RADIUSハードウェアおよびソフトウェアの多くのベンダーは、ベンダー固有属性（VSA）を使用して独自のバリアントを実装しています。Microsoftは、いくつかのVSAを公開しています。[ 11 ]他の多くの企業のVSA定義は、依然として独自仕様またはアドホックなものですが、 FreeRADIUSなどのオープンソースRADIUS実装のソースコードをダウンロードすることで、多くのVSA辞書を見つけることができます。
RFC 2865のセクション5.26では、ほとんどのベンダーが採用している推奨エンコーディングが示されています。
ベンダーによっては異なるフォーマットを使用している場合があります。例えば、「ベンダー長さ」フィールドを削除したり、「ベンダータイプ」および/または「ベンダー長さ」フィールドに2オクテットを使用したりする場合があります。
RFC 8044 セクション 3.14 では、「vsa」データ型が定義されており、RFC 2865 セクション 5.26 のフォーマットが義務付けられています。
RADIUSプロトコルは、共有シークレットとMD5ハッシュアルゴリズムを使用して難読化されたパスワードを送信します。この特定の実装ではユーザーの認証情報が弱く保護されるだけなので、[ 12 ] IPsecトンネルや物理的に保護されたデータセンターネットワークなどの追加の保護を使用して、NASデバイスとRADIUSサーバー間のRADIUSトラフィックをさらに保護する必要があります。さらに、ユーザーのセキュリティ認証情報はRADIUS自体によって保護される唯一の部分ですが、RADIUS経由で渡されるトンネルグループIDやVLANメンバーシップなどの他のユーザー固有の属性も、機密情報（攻撃者に役立つ）またはプライベート情報（個々のクライアントを識別するのに十分）とみなされる可能性があります。
RadSecプロトコルは、RADIUSプロトコルをTLSで「ラップ」することで、従来のRADIUS/UDPセキュリティの問題を解決します。ただし、 TLSトランスポート内のパケットは、パケットの完全性チェックと特定の属性の内容を難読化するために、依然としてMD5を使用します。
Blast-RADIUS攻撃は、RADIUS内のMD5を攻撃することで、プレーンUDPで転送されるRADIUSを破壊します。[ 3 ] RadSecはこの攻撃をブロックします。[ 3 ]推奨されるもう1つの緩和策は、すべてのリクエストとレスポンスにMessage-Authenticator属性を要求することです。[ 3 ] Blast-RADIUS攻撃にはCVE - 2024-3596が割り当てられています。
NSFNET を利用するダイヤルアップ顧客が増えるにつれ、Merit Networkは 1991 年に、さまざまな独自の認証、認可、およびアカウンティング システムを統合するための提案依頼書を送付しました。初期の回答者の中には Livingston Enterprises があり、会議の後、RADIUS の初期バージョンが作成されました。初期の RADIUS サーバーはUNIXオペレーティングシステムにインストールされました。Livingston Enterprises はLucent Technologiesに買収され、Merit とともに RADIUS をプロトコルとして業界で受け入れてもらうための措置が講じられました。両社は RADIUS サーバーを無償で提供しました。[ 13 ] 1997 年に RADIUS は RFC 2058 および RFC 2059 として公開され、現在のバージョンは RFC 2865 および RFC 2866 です。[ 14 ]
オリジナルのRADIUS標準では、RADIUSはステートレスであり、ユーザーデータグラムプロトコル（UDP）上で動作する必要があると規定されていました。認証に関しては、RADIUSはポイントツーポイントプロトコル上でパスワード認証プロトコル（PAP）とチャレンジハンドシェイク認証プロトコル（CHAP）をサポートすることが想定されていました。パスワードは、パケットのMD5ハッシュと共有シークレットを取得し、そのハッシュとパスワードをXOR演算することで隠蔽されます。オリジナルのRADIUSでは、50を超える属性値ペアも提供されており、ベンダーが独自のペアを設定できる可能性がありました。[ 15 ]
エンドツーエンド暗号化ではなくホップバイホップのセキュリティモデルを選択したため、複数のプロキシ RADIUS サーバーが使用されている場合、すべてのサーバーがリクエスト内のすべてのデータを検査し、ロジックを実行して渡す必要がありました。これにより、パスワードや証明書などのデータが各ホップで公開されます。また、RADIUS サーバーは、認証が発行された後にリソースへのアクセスを停止する機能もありませんでした。RFC 3576 やその後継の RFC 5176 などの後継標準では、RADIUS サーバーがユーザーの認証を動的に変更したり、ユーザーを完全に切断したりすることが可能になりました。[ 16 ]
現在、商用およびオープンソースのRADIUSサーバーが数多く存在します。機能は様々ですが、ほとんどのサーバーはテキストファイル、LDAPサーバー、各種データベースなどからユーザー情報を検索できます。アカウンティングレコードはテキストファイルや各種データベースに書き込んだり、外部サーバーに転送したりすることも可能です。RADIUSサーバーのリモート監視やキープアライブチェックには、SNMPがよく使用されます。RADIUSプロキシサーバーは集中管理に使用され、セキュリティ上の理由やベンダー固有の通信方式間の変換のために、RADIUSパケットをリアルタイムで書き換えることができます。
DiameterプロトコルはRADIUSの後継として開発されました。どちらも認証、認可、アカウンティング（AAA）プロトコルですが、その後、両プロトコルの用途は異なってきました。Diameterは主に3G環境で使用され、RADIUSはそれ以外の環境で使用されています。DiameterがRADIUSに取って代わる上での最大の障壁の一つは、スイッチやアクセスポイントが通常RADIUSを実装しているものの、Diameterを実装していないことです。DiameterはSCTPまたはTCPを使用するのに対し、RADIUSは通常UDPをトランスポート層として使用します。2012年現在、RADIUSはセキュリティのためにTLSを使用したTCPをトランスポート層として使用することもできます。
RADIUSプロトコルは現在、以下のIETF RFC文書で定義されています。
rfc2866が呼び出されましたが、定義されていません (ヘルプ ページを参照してください)。rfc6614が呼び出されましたが、定義されていません (ヘルプ ページを参照してください)。