Loading article…
リモート認証ダイヤルイン ユーザー サービス( RADIUS ) は、ネットワーク サービスに接続して使用するユーザーに対して、集中的な認証、承認、アカウンティング ( 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 に 1) アクセス拒否、2) アクセスチャレンジ、または 3) アクセス承認の 3 つの応答のいずれかを返します。
- アクセス拒否
- ユーザーは、要求されたすべてのネットワーク リソースへのアクセスを無条件に拒否されます。理由としては、身分証明書を提示できなかった場合や、ユーザー アカウントが不明または非アクティブである場合などが挙げられます。
- アクセスチャレンジ
- セカンダリ パスワード、PIN、トークン、カードなどの追加情報をユーザーに要求します。アクセス チャレンジは、アクセス資格情報が NAS から隠されるように、ユーザー マシンと Radius サーバーの間に安全なトンネルが確立される、より複雑な認証ダイアログでも使用されます。
- アクセス承認
- ユーザーにアクセスが許可されます。ユーザーが認証されると、RADIUS サーバーは、多くの場合、ユーザーが要求したネットワーク サービスを使用する権限があるかどうかを確認します。たとえば、特定のユーザーは会社のワイヤレス ネットワークの使用は許可されているが、VPN サービスは許可されていない場合があります。この情報も、RADIUS サーバーにローカルに保存されるか、LDAP や Active Directory などの外部ソースで検索されます。
これら 3 つの RADIUS 応答にはそれぞれ、拒否の理由、チャレンジのプロンプト、または承認のウェルカム メッセージを示す Reply-Message 属性が含まれる場合があります。属性内のテキストは、返信 Web ページでユーザーに渡すことができます。
承認属性は、許可されるアクセス条件を規定する NAS に伝達されます。たとえば、次の承認属性が Access-Accept に含まれる場合があります。
- ユーザーに割り当てられる特定のIPアドレス
- ユーザーの IP アドレスを選択するアドレス プール
- ユーザーが接続を維持できる最大時間
- アクセスリスト、優先キュー、またはユーザーのアクセスに関するその他の制限
- L2TPパラメータ
- VLANパラメータ
- サービス品質 (QoS) パラメータ
クライアントが RADIUS を使用するように設定されている場合、クライアントのユーザーはクライアントに認証情報を提示します。これは、ユーザーがユーザー名とパスワードを入力することを要求される、カスタマイズ可能なログイン プロンプトで行われる場合があります。または、ユーザーは、この情報を運ぶ認証パケットを持つポイントツーポイント プロトコル (PPP) などのリンク フレーミング プロトコルを使用する場合もあります。
クライアントがこのような情報を取得すると、RADIUS を使用して認証することを選択できます。これを行うには、クライアントはユーザー名、ユーザーのパスワード、クライアントの ID、ユーザーがアクセスしているポート ID などの属性を含む「アクセス要求」を作成します。パスワードが存在する場合、RSA メッセージ ダイジェスト アルゴリズム MD5 に基づく方法を使用してパスワードが非表示になります。
会計
アカウンティングについては RFC 2866 で説明されています。
NASによってユーザーにネットワーク アクセスが許可されると、 NAS によって RADIUS サーバーにAccounting Start (値が "start" の Acct-Status-Type 属性を含む RADIUS Accounting Request パケット) が送信され、ユーザーのネットワーク アクセスの開始が通知されます。"Start" レコードには通常、ユーザーの ID、ネットワーク アドレス、接続ポイント、および一意のセッション ID が含まれます。[5]
定期的に、暫定更新レコード (値が「暫定更新」の Acct-Status-Type 属性を含む RADIUS アカウンティング要求パケット) が NAS から RADIUS サーバーに送信され、アクティブ セッションのステータスが更新されます。「暫定」レコードは通常、現在のセッション期間と現在のデータ使用量に関する情報を伝えます。
最後に、ユーザーのネットワーク アクセスが閉じられると、NAS は最終的なアカウンティング停止レコード (値が「stop」の Acct-Status-Type 属性を含む RADIUS アカウンティング要求パケット) を RADIUS サーバーに発行し、時間、転送されたパケット、転送されたデータ、切断の理由、およびユーザーのネットワーク アクセスに関連するその他の情報に関する最終的な使用状況に関する情報を提供します。
通常、クライアントは、何らかの再試行間隔を使用して、Accounting-Response 確認応答を受信するまで、Accounting-Request パケットを送信します。
このデータの主な目的は、ユーザーに対して適切な料金を請求できるようにすることです。また、このデータは統計目的や一般的なネットワーク監視にも一般的に使用されます。
ローミング
RADIUS は、次のようなISP間のローミングを容易にするためによく使用されます。
- 多くのパブリック ネットワークで使用できる単一のグローバル認証情報セットを提供する企業。
- 独立しているが協力関係にある機関が、独自の資格情報を自身のユーザーに発行し、eduroamなどのように、ある機関から別の機関への訪問者が所属機関によって認証されることを許可します。
RADIUS は、RADIUS サーバーが AAA 要求を処理のために転送する場所を識別する レルムを使用してこれを容易にします。
レルム
レルムは、通常、ユーザーのユーザー名に追加され、電子メール アドレスのドメイン名に似た「@」記号で区切られます。これは、レルムのポストフィックス表記と呼ばれます。もう 1 つの一般的な使用法はプレフィックス表記で、レルムをユーザー名の前に追加し、「\」を区切り文字として使用します。最新の RADIUS サーバーでは、レルムの区切り文字として任意の文字を使用できますが、実際には「@」と「\」が通常使用されます。
複雑なローミング シナリオを可能にするために、プレフィックス表記とポストフィックス表記の両方を使用してレルムを複合することもできます。たとえば、somedomain.com\username@anotherdomain.com は、2 つのレルムを持つ有効なユーザー名になります。
レルムはドメインに似ていることが多いですが、レルムは実際には任意のテキストであり、実際のドメイン名を含む必要はないことに注意することが重要です。レルムの形式はRFC 4282で標準化されており、ネットワークアクセス識別子（NAI）を「user@realm」の形式で定義しています。この仕様では、「レルム」の部分はドメイン名である必要があります。ただし、この慣例が常に遵守されるわけではありません。2015年5月にRFC 7542 [6]がRFC 4282に取って代わりました。
プロキシ操作
RADIUS サーバーは、レルムを含むユーザー名の AAA 要求を受信すると、設定されたレルムのテーブルを参照します。レルムがわかっている場合、サーバーはそのドメインに設定されたホーム サーバーに要求をプロキシします。要求からレルムを削除する (「ストリッピング」) ことに関するプロキシ サーバーの動作は、ほとんどのサーバーで設定に依存します。さらに、時間の経過とともに再度プロキシされるときに AAA 要求を追加、削除、または書き換えるようにプロキシ サーバーを設定できます。
RADIUS ではプロキシ チェーンが可能で、認証/承認およびアカウンティング パケットは通常、一連のプロキシを介して NAS デバイスとホーム サーバーの間でルーティングされます。プロキシ チェーンを使用する利点には、スケーラビリティの向上、ポリシーの実装、機能の調整などがあります。ただし、ローミング シナリオでは、NAS、プロキシ、ホーム サーバーは、通常、異なる管理エンティティによって管理されます。したがって、このようなドメイン間アプリケーションでは、プロキシ間の信頼要因がさらに重要になります。さらに、RADIUS にはエンド ツー エンドのセキュリティがないため、関係するプロキシ間の信頼の重要性が増します。プロキシ チェーンについては、RFC 2607 で説明されています。
安全
RADIUS によるローミングは、ユーザーをさまざまなセキュリティとプライバシーの懸念にさらします。より一般的には、一部のローミング パートナーは、RADIUS サーバー間に安全なトンネルを確立して、インターネット経由でプロキシされている間にユーザーの資格情報が傍受されないようにします。RADIUS に組み込まれている MD5 ハッシュは安全ではないと考えられているため、これは懸念事項です。[7]
パケット構造
RADIUSはUDP/IPのポート1812と1813で転送されます。 [8]
RADIUSパケットデータ形式は右側に示されています。フィールドは、コード、識別子、長さ、認証子、属性から始まり、左から右に送信されます。
割り当てられたRADIUSコード（10進数）には以下のものがあります。[9]
識別子フィールドは、要求と応答の一致に役立ちます。
長さフィールドは、コード、識別子、長さ、認証子、およびオプションの属性フィールドを含む RADIUS パケット全体の長さを示します。
認証子は、RADIUS サーバーからの応答を認証するために使用され、パスワードの暗号化に使用されます。その長さは 16 バイトです。
属性値ペア
RADIUS 属性値ペア (AVP) は、認証、承認、アカウンティング トランザクションの要求と応答の両方でデータを伝送します。RADIUS パケットの長さは、AVP の終了を決定するために使用されます。
ベンダー固有の属性
RADIUS は拡張可能であり、RADIUS ハードウェアおよびソフトウェアの多くのベンダーは、ベンダー固有属性 (VSA) を使用して独自のバリアントを実装しています。Microsoft はいくつかの VSA を公開しています。[10]他の多くの企業の VSA 定義は、独自の定義やアドホックな定義のままですが、 FreeRADIUSなどのオープンソース RADIUS 実装のソース コードをダウンロードすると、多くの VSA 辞書を見つけることができます。
RFC 2865 セクション 5.26 では、ほとんどのベンダーが従う推奨エンコーディングが提供されています。
ベンダーによっては、異なる形式を使用するものもあります。たとえば、一部のベンダーは「ベンダー長」フィールドを削除したり、「ベンダー タイプ」フィールドや「ベンダー長」フィールドに 2 オクテットを使用したりします。
RFC 8044 セクション 3.14 では、RFC 2865 セクション 5.26 形式を義務付ける「vsa」データ型が定義されています。
安全
RADIUS プロトコルは、共有シークレットとMD5ハッシュ アルゴリズムを使用して難読化されたパスワードを送信します。この特定の実装では、ユーザーの資格情報の保護が弱いため、[11] 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 年に、さまざまな独自の認証、認可、アカウンティング システムを統合するための提案依頼書を発行しました。初期の回答者の 1 つに Livingston Enterprises があり、会議後に RADIUS の初期バージョンが作成されました。初期の RADIUS サーバーはUNIXオペレーティング システムにインストールされていました。Livingston Enterprises はLucent Technologiesに買収され、Merit と協力して、RADIUS をプロトコルとして業界で受け入れられるようにするための措置が講じられました。両社とも RADIUS サーバーを無償で提供しました。[12] RADIUS は 1997 年に RFC 2058 および RFC 2059 として公開され、現在のバージョンは RFC 2865 および RFC 2866 です。[13]
オリジナルのRADIUS標準では、RADIUSはステートレスであり、ユーザーデータグラムプロトコル（UDP）上で動作する必要があると規定されていました。認証については、RADIUSがポイントツーポイントプロトコル上のパスワード認証プロトコル（PAP）とチャレンジハンドシェイク認証プロトコル（CHAP）をサポートすることが想定されていました。パスワードは、パケットのMD5ハッシュと共有秘密を取得し、そのハッシュとパスワードをXORすることで隠されます。オリジナルのRADIUSでは、50を超える属性値ペアも提供されており、ベンダーが独自のペアを構成することも可能でした。[14]
エンドツーエンドの暗号化ではなくホップバイホップのセキュリティモデルを選択したということは、複数のプロキシRADIUSサーバーが使用されている場合、すべてのサーバーがリクエスト内のすべてのデータを調べ、ロジックを実行し、渡す必要があることを意味します。これにより、パスワードや証明書などのデータが各ホップで公開されます。RADIUSサーバーには、承認が発行された後にリソースへのアクセスを停止する機能もありませんでした。RFC 3576やその後継のRFC 5176などの後続の標準では、RADIUSサーバーがユーザーの承認を動的に変更したり、ユーザーを完全に切断したりできるようになりました。[15]
現在、商用およびオープンソースの RADIUS サーバーがいくつか存在します。機能はさまざまですが、ほとんどのサーバーでは、テキスト ファイル、LDAPサーバー、さまざまなデータベースなどでユーザーを検索できます。アカウンティング レコードは、テキスト ファイル、さまざまなデータベースに書き込んだり、外部サーバーに転送したりできます。SNMPは、RADIUS サーバーのリモート監視やキープアライブ チェックによく使用されます。RADIUSプロキシ サーバーは、集中管理に使用され、セキュリティ上の理由から、またはベンダー方言間で変換するために、RADIUS パケットをオンザフライで書き換えることができます。
Diameterプロトコルは、RADIUS の代替として意図されていました。どちらも認証、承認、アカウンティング (AAA) プロトコルですが、2 つのプロトコルの使用例は異なります。Diameter は主に3Gスペースで使用され、RADIUS は他の場所で使用されます。Diameter を RADIUS に置き換える際の最大の障害の 1 つは、スイッチとアクセス ポイントは通常 RADIUS を実装しますが、Diameter は実装しないことです。Diameter はSCTPまたはTCP を使用しますが、RADIUS は通常、トランスポート層としてUDP を使用します。2012 年現在、RADIUS はセキュリティのためにTLSとともに TCP をトランスポート層として使用することもできます。
標準ドキュメント
RADIUS プロトコルは現在、次のIETF RFC ドキュメントで定義されています。
参照
参考文献
- ^ ab 「RADIUS の仕組み」。Cisco。2006年1 月 19 日。2009 年 4 月 15 日に取得。
- ^ Edwin Lyle Brown (2006). 802.1X ポートベース認証。Taylor & Francis。p. 17。ISBN 978-1-4200-4465-2。
- ^ abcd “Blast-RADIUS”。2024年7月9日。 2024年7月10日閲覧。
- ^ RFC 2865 リモート認証ダイヤルインユーザーサービス (RADIUS)
- ^ RFC 2866 RADIUS アカウンティング
- ^ Dekok, A. (2015年5月). 「ネットワークアクセス識別子」. インターネット技術タスクフォース (IETF). doi : 10.17487/RFC7542 . 2021年5月8日閲覧。
- ^ アレクサンダー・ソティロフ;マーク・スティーブンス;ジェイコブ・アッペルバウム。アリジェン・レンストラ。デビッド・モルナー;ダグ・アルネ・オスヴィク;ベン・デ・ウェガー (2008-12-08)。 「MD5 は現在有害であると考えられています - 不正な CA 証明書の作成」。アイントホーフェン工科大学。2009 年 4 月 19 日に取得。
- ^ 「NPS UDP ポート情報を構成する」。Microsoft 2020 年 8 月 7 日。2021年 6 月 20 日閲覧。
- ^ 「RADIUS (リモート認証ダイヤルインユーザーサービス)に関するIANAの考慮事項」。IETFデータトラッカー。インターネット技術特別調査委員会 (IETF)。2003年7月。 2021年5月8日閲覧。
- ^ RFC 2548
- ^ RADIUS認証プロトコルの分析
- ^ ジョナサン・ハッセル (2003)。RADIUS : プライベートリソースへのパブリックアクセスの保護。オライリーメディア。pp. 15–16。ISBN 9780596003227。
- ^ John Vollbrecht (2006). 「RADIUS の始まりと歴史」(PDF) . Interlink Networks . 2009-04-15閲覧。
- ^ ジョナサン・ハッセル (2003)。RADIUS : プライベートリソースへのパブリックアクセスの保護。オライリーメディア。p. 16。ISBN 9780596003227。
- ^ 「リモート認証ダイヤルインユーザーサービス（RADIUS）への動的認証拡張機能」。IETFデータトラッカー。インターネットエンジニアリングタスクフォース。2008年1月。 2021年5月8日閲覧。
文献
- ハッセル、ジョナサン (2002)。RADIUS - プライベートリソースへのパブリックアクセスの保護。O'Reilly & Associates。ISBN 0-596-00322-6. 2009年4月17日閲覧。
外部リンク
- 半径の種類
- RADIUS 認証プロトコルの分析
- RADIUS トランザクションのスニファー トレースのデコード
- Wireshark を使用して RADIUS をデバッグする