Radiusプロトコルの概要(メリットやアカウンティングの意味、等)とパケットフォーマット

Radiusとは

RadiusとはRemote Authentication Dial In User Serviceの略で、NW機器へのリモートアクセスを一元的に管理できるプロトコルです。

一元的に行う管理とは、Authentication(認証)、Authorzation(承認)、Accounting(課金)の3つのことで、 AAAモデルと呼ばれます。

認証とは、アクセスする人が適した人かどうかをパスワードやクライアント証明書を利用して検証・判断することです。

認可とは、認証されたユーザに応じて、あらかじめ設定された権限を与えることです。NW機器へのtelnet/sshアクセスで利用するのであれば、ユーザAはshow コマンドのみ利用可ユーザBはインタフェースの設定まで利用可ユーザCは全てのコマンドが利用可、といった具合です。

課金とは、各ユーザのログイン時とログアウト時の時間をログに取ることです。言葉自体はISDN時代の「ダイヤルアップ接続」等の 従量課金型サービスを想定したものです。この名称は、その時代、このログから利用時間を確認し、金額を請求していたことの名残です。

Radiusのメリット

Radiusは、たくさんのNW機器で、共通の認証認可アカウントを設定する必要がある場合に大きなメリットが生まれます

例えば100台のL2スイッチに、コンソールログイン用のアカウントを30人分作る場合を考えます。

Radiusを使わずローカルDBにアカウントを作る場合、それぞれのスイッチにアカウントを作る必要があり、アカウント修正作業も大変です。100台のスイッチそれぞれに30人分のアカウント(のべ3000人分)を作成する必要があり1名修正するのに100台分のスイッチで修正を行う必要があるのです。

ですがRadiusを導入すれば、Radiusサーバにだけ30人分アカウントを作ればよく、さらに今後アカウントを修正する場合も Radiusサーバだけを設定変更すればよいのです

Radiusの用語

Radiusクライアント・・・NAS(Network Access Server)とも呼ばれます。主にNW機器やVPN装置など、認証情報をRadiusに問い合わせする機器のことです。

共有キー(Pre-shared Secret)・・・RadiusクライアントとRadiusサーバで設定する共通のパスワード。このキーは直接通信されることはありません。

Radiusのパケットフォーマット

RadiusはUDP上で動作する想定です。サーバはUDP1812番ポートで認証・認可のパケットを待ち受け、UDP1813番ポートで課金(ログ)のパケットを待ち受けます。

フォーマットは下記のようになります。

Code

1 Byte。Radiusパケットの種類を表します。

1. Access-Request・・・RadiusクライアントからRadiusサーバへの認証情報を送付します
2. Access-Accept・・・RadiusサーバからRadiusクライアントへ認可(与えられる権限)情報を送付します
3. Access-Reject・・・RadiusサーバからRadiusクライアントへ認証失敗を伝えます
4. Accounting-Request・・・RadiusクライアントからRadiusサーバへ利用開始や利用終了を伝えます
5. Accounting-Response・・・RadiusサーバからRadiusクライアントへ、利用ログを記録したことを伝えます。
11.Access-Challenge・・・RadiusサーバからRadiusクライアントへ追加の情報を求めます。これを受信したRadiusクライアントは再びAccess-Requestにより、要求された追加情報を送信します。これはIEEE802.1x認証等で利用されます。
12.Status-Server (experimental)
13.Status-Client (experimental)
255.Reserved

Identifier

1 Byte。どのパケットに対する返信なのかを識別するためのものです。一連の流れでは同じIdentifierを利用します。

Length

2 Byte。[Codeから最後のAttributeまでのサイズ] = [UDPセグメントのサイズ] を示します。

Authenticator

16 Byte。RadiusクライアントからRadiusサーバへのパケットにおいてはRequest Authenticatorと呼ばれ、その逆はResponse Authenticator と呼ばれます。

Request Authenticator

ランダムな値が使われます。これはユーザのパスワードが平文で流れるのを防ぐ目的でも使われますが、メインは次で説明するResponse Authenticatorがなりすましなど行われていないかを検証する目的で使われます。

Response Authenticator

受信したRadiusパケットに共有キーを付け加えたものをMD5でハッシュ化したものです。Radiusクライアントは共有キーが合致しているかを検証できますので、正しいRadiusサーバからの応答か、というのを確認できます。

Attribute

この属性はTLV形式(Type=1Byte, Length=1Byte, Value=Lengthで示したByte)で記載され、1つのRadiusパケットで複数の属性を送付することができます。この属性の種類は挙げればきりがないので、一部だけ紹介します。

1. User-Name・・・認証時のユーザID
2. User-Password・・・認証時のユーザパスワード
3. CHAP-Password・・・認証時のユーザパスワードハッシュ
26.Vender Specific・・・Radiusクライアントのメーカが独自に定義できる属性値。よく使われる例としては、動的認証VLANの実装として、認証されたユーザによってVLAN IDやVLAN name を属性値としてRadiusクライアントへ返し、Radiusクライアント側で認証されたユーザをそのVLANに変更する、といったことができます。
32.NAS Identifier・・・Radiusクライアントを識別する属性です。基本的にはRadiusクライアントのIPアドレスを含めるのが一般的なようですが、機器によっては、ユーザが認証を行ったVLAN ID等に設定変更することができます。この値は、Radiusサーバ側での制御に役立ちます。例えば「このスイッチ(Radiusクライアント)は他のスイッチとメーカが異なり、動的VLANで利用する属性が違うから、返す属性を変えたい」といった制御も可能です。
81.Tunnel-Private-Group-Id・・・先に紹介したVender Specificの例と同様、動的認証VLANのVLAN IDが属性値として入ります。Vender Specificと異なり、この属性は用途はこれに限定されます。

動的認証VLANを行う場合はたいてい26か81を利用することがほとんどのようです。

シェアする

  • このエントリーをはてなブックマークに追加

フォローする