認証だけでなく課金管理も担うRADIUS：RADIUSを使おう（2）
前回は企業に認証サーバが必要な理由をお話した。今回はいよいよ、RADIUSのお話に移ろうと思う。RADIUSといえば認証、認証といえばRADIUSといわれるくらい、広く認識されている。まずは、この概要をおさらいしてみたい。
RADIUSとは？
RADIUSとはいうまでもなく、Remote Authentication Dial In User Serviceの頭文字を取ったもので「ラディウス」と発音される。読んで字のままだが、もともとはリモートアクセスサーバ（RAS：Remote Access Server）のユーザー認証のために開発されていたプロトコルである。Merit Networks社およびLivingSton社＜現在はLucent Technologies社＞が開発を行い、これが最終的にIETF標準（RFCスタンダード）となっている。
プロトコル自体はUDPベースのクライアント／サーバモデルで、非常にシンプルなのが特長である。公式資料はRFC 2865（Authentication）およびRFC 2866（Accounting）になる。
RADIUSといえば「認証」と認識されている方が大半だと思うので、念のため補足しておくと、「認証」がRFC 2865になる。もう片方のRFC 2866が課金管理（アカウンティング）に関するものである。
インターネットの創成期にはごく一部の企業を除けば、インターネットへはモデムによるダイヤルアップ接続を行うしかなかった。当然、この接続を受けるISP（インターネットサービスプロバイダ）にはRASが大量に配備された。また、企業ではいわゆるリモートアクセスのためにRASを使用していた（図1）。
図1 ダイヤルアップPPPの場合RASを展開するに当たっては当然のことながら不正使用に目を光らせなければならない。また、正規のユーザーでも必要以上に長時間接続することによってほかのユーザーへのサービス低下を招く可能性もある。
ISPを運用している場合にはこれは死活問題になりかねない。現在でこそあまり見かけなくなった従量課金だが、当時は定額制など想像もできなかった。
また、RASの場合は物理的なポート（および電話回線）の数によってユーザーに提供するサービスの質が上下する。
あまりにもビジー率が高い（話中が常時続いて接続できない）ようではユーザーの不評を招くし、かといって必要のない投資を増やすというのも賢くない選択である。
こうしたキャパシティプランニングのための情報収集手段としてもRADIUSアカウンティングは使用される。従量課金の多くは接続時間単位で課金を行うが、RADIUSプロトコルでは送受信したデータのサイズもログを取ることが可能となっている。第1部（企業に認証サーバが必要な理由）で紹介したサンプルログを参考にしていただきたい。
RADIUSのシーケンス
前述したようにRADIUSプロトコルはUDPで実装されるため、TCPでのセッション確立などの手続きを省略していきなりシーケンス（順序番号）が始まる。シーケンスは極めてシンプルで、クライアントが要求を出し、サーバがそれに応じた応答を返す。
基本的にはこの繰り返しで処理が行われる。要求にはいくつかの種類があるが、これらは種別コードとサーバへのあて先ポート番号で区別する。認証のあて先ポート番号は1812（古い実装では1645）であり、アカウンティングのあて先ポート番号は1813（古い実装では1646）である。
なお、偽のRADIUSクライアント（もしくはサーバ）からの接続要求を排除するために、RADIUSクライアントとサーバの間で共有暗号鍵(Shared Secret)を事前に設定しておく。これと乱数を使用してパケットの一部を生成する。この措置により、リプレイアタックを防止することができる。
また、RADIUSサーバは正規のRADIUSクライアントのIPアドレスを把握しておくことにより、不正なアクセス要求を排除することができる（攻撃手法としては辞書攻撃が考えられる。偽のRADIUSクライアントを使用し、高速にアクセス要求を行い、パスワードをしらみつぶしに探し出す）。
RADIUSパケットの構造概念図を図2に示す。RADIUSパケットの先頭には種別コードが位置する。これにはAccess-Request（認証要求）、Access-Accept（アクセス許可）、Access-Reject（アクセス拒否）などがある。この後には識別子（複数の要求を区別するために使用）や認証符号（データの偽造を防止するために使用）が続く。
図2 RADIUSパケット概念図さらに、RADIUSプロトコルでは属性値ペア（Attribute Value Pair）というフォーマットでさまざまな情報を受け渡す。これは名前どおりで、属性と値のペアで構成される。属性の長さは3-255の間の整数であり、値そのものは整数もしくは文字列などの型が使用される。これらはRFCで細かく規定されている。属性値ペアの代表的な例は下記のとおりである。値の数字は属性番号を示す。
| 属性値 | 概要 |
|---|---|
| Framed-IP-Address(8) | ユーザーに指定するIPアドレス |
| Framed-IP-Netmask(9) | ユーザーに指定するサブネットマスク |
| User-Name(1) | アクセス要求で使用するユーザー名 |
| User-Password(2) | PAPで使用するパスワード |
| NAS-IP-Address(4) | 着信装置のIPアドレス |
| CHAP-Password(3) | CHAPの結果、計算された暗号化パスワード |
認証のシーケンス
認証のシーケンスは下記のようになる。
RADIUSクライアントがアクセス要求パケットをRADIUSサーバに送る
- 通常は最初のアクセス要求パケットにユーザーIDおよび暗号化されたパスワードが含まれる
これを受け取ったRADIUSサーバは応答を返す（返すことは必須）
- 応答の種類はアクセス許可(Access-Accept)もしくはアクセス拒否(Access-Reject)、またはアクセスチャレンジ(Access-Challenge)がある
応答としてアクセスチャレンジを受け取ったクライアントはそれに応じた処理を行う
- 通常は専用のトークンにチャレンジコードを入力し、得られた値を再度アクセス要求パケットに含めて送信する
RADIUSクライアントに最終的にアクセス許可が返される場合には、さまざまな付属パラメータが渡される場合がある
- 例えば、IPアドレス（Framed-IP-Address）やサブネットマスク（Framed-Netmask）などである
- RASはこれらの値を利用することができる。こうすることによってRASに情報を極力持たせない運用が可能となる
Access-request（認証要求）のパケットダンプ例を図3に示す。RADIUSクライアントがRADIUSサーバに対して送信したものである。Access Request（コード番号1）が含まれている。このほか、属性番号1のUser-Nameのほか、4のNAS-IP-Address（モザイクあり）が含まれている。属性番号2のUser-Passwordも含まれているが、この例ではきちんとダンプされず、空白になっている。
図3 RADIUSパケットダンプ例（Access-Request/PAP）ここで分かるように、ユーザー名およびパスワードを受け渡すためにも先に説明した属性値ペアを利用している。
誤解を招くといけないので念のため補足しておくと、ユーザーとRASの間はRADIUSプロトコルでやり取りをしていない。RASの場合はPPPというプロトコルが一般的に使用される。PPP上でパスワードを送信する方法は大きく分けて2種類が使用されている。
PAPでパスワードを暗号化しないで送出する
Password Authentication Protocol（PAP）とは、 パスワードをそのまま（暗号化せずに）属性値ペアで送り出す方式だ。PPPフレームを盗聴することが可能であれば、パスワードをそのまま読み取ることが可能である。ネットワークが完全に信頼できない限り、使用しない方が無難である。このパスワードはRADIUSプロトコルでは暗号化が行われる。PPP（PPPoE）パケットのダンプ例を図4に示すが、青色の部分では、パスワードがそのまま読めるようになっている。
図4 PPP（PPPoE）パケットダンプ例（Access-Request/PAP）CHAPでパスワードを乱数と交ぜて送出する
Challenge Handshake Authentication Protocol（CHAP）とは、パスワードを乱数と交ぜたうえでMD5でハッシュしたものを属性値ペアで送り出す方式だ。PPPフレームが盗聴されてもパスワードがそのまま書いてあるわけではない。ただし、辞書攻撃は可能であるので過信は禁物である。RADIUSクライアントはこのハッシュを改めて暗号化することはしない（これがそのままCHAP-Passwordの中身になる）。
図5 RADIUSパケットダンプ例（Access-Request/CHAP）PPPは第3部で後述するEAPの基となったプロトコルであり、ダイヤルアップ（シリアルライン）での接続で標準的に使用されている。また、シリアルラインではなく、イーサネット上で使用する場合はPPPoE（PPP over Ethernet）となる。
アカウンティング（課金管理）
同様にアカウンティングのシーケンスは下記のようになる。
RADIUSクライアントがアカウンティング要求パケットをRADIUSサーバに送信する
- Acct-Status-Typeの内容はStartとする
これを受け取ったRADIUSサーバは応答を返す（条件を満たさない場合には返す必要はない）
- 正当なアカウンティング要求の場合には記録開始処理を行う
（RADIUSクライアントがInterim-Updateを行う−オプション）
- Acct-Status-Typeの内容はInterim-Updateとする
- アカウンティング停止を明示的に指示せずにセッションが終了したわけではないことを通知する
RADIUSクライアントがアカウンティング要求パケットをRADIUSサーバに送信する
これを受け取ったRADIUSサーバは応答を返す（条件を満たさない場合には返す必要はない）
- Acct-Status-Typeの内容はStopとする
- パケット内部には総接続時間、送受信オクテット数などが含まれる
- 正当なアカウンティング要求の場合には記録終了処理を行う
アカウティングのパケットダンプ例を図6に示す。Authenticatorは認証符号を示し、青色の部分以下は属性ペア群を示している。
図6 アカウンティングパケットダンプ例（Accounting-Start）RADIUSの用途
前回お話ししたように、元来RADIUSはRASのユーザー認証を一元化させるためのプロトコルとして開発された。だが、ユーザーデータベースがそれぞれのサービスごとに分散するという事態は好ましいものではない。
また、RADIUSは実績もあり、歴史を重ねてきたユーザー認証方式およびデータベースともいえる。そのような背景もあり、ある程度以上の規模でのユーザー認証をRADIUSに任せるケースもある。
今日現在、RASが果たしていた役割のほとんどの部分はVPN機器によって置き換えられている。これらの機器は当然ながらローカルデータベースを持っているが、外部のユーザー認証手段としてRADIUSが使用できるのが常識となっている。
ほかには、WebサーバではデファクトスタンダードともいえるApacheがある。Apache自体が自前のユーザー認証メカニズムを提供している。その一方でRADIUSをユーザー認証バックエンドとして使用するモジュールも標準で提供している。
RADIUSプロキシ
RADIUSはユーザーデータベースの一元化のために開発された、とお話しした。しかし、サービスによってはユーザーデータベースの一元化が提供できない場合がある。例えば、NTT東西が提供するフレッツ・サービスでは一般ISPとの組み合わせで初めてインターネット接続が可能となる。
この場合、NTT東西はアクセスライン（ADSLや光）を提供するだけで、実際のユーザー認証とIPアドレスの払い出しは行っていない（フレッツ・スクエアはインターネットではないのでここでは例外となる）。ここで問題になるのは、ユーザーがユーザー名パスワードを接続の際に使用しなければならないという点と、NTT東西はその振り向け先が分からないということである。
しかし、実際にはそんな問題などなかったかのように接続できる。これはRADIUSプロキシ（Proxy RADIUS）といわれる、ユーザーに代わって業務を代行する代理サーバの仕組みで実現されている。
例えば、フレッツでインターネット接続する場合には、以下のように必ずユーザー名はISP名を含めて指定する必要がある。
例）
abcde1234@japan-isp.ne.jp
NTT東西が設置しているRADIUSプロキシサーバは@以下（@より右の部分）を見て、どのISPへ送るかを決定する。この場合、RADIUSプロキシサーバはユーザーから見てRADIUSサーバとして振る舞うが、ISPのRADIUSサーバから見てRADIUSクライアントとして振る舞う。概念図を図7に示す。
図7 Proxy RADIUSの例 最終的にアクセス要求を受けた各ISPのRADIUSは通常のアクセス要求同様にパスワードを確認してアクセス許可もしくはアクセス拒否を判断する。これを受けたNTT東西のRADIUSプロキシは逆の流れでRADIUSクライアントに応答を送り返す。こうしてNTT東西が各ユーザーのデータベースを持つことなく、サービスが提供できることになる。
次回は、将来のRADIUSについて解説したい。
Copyright © ITmedia, Inc. All Rights Reserved.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。