[時間割:サーバ]『RADIUS - ユーザ認証セキュリティプロトコル』その2
2009/02/11 22:53 posted by kunkichi

水曜日は「サーバ」の時間。前回に続いて『RADIUS』を読み進めていきます。今日はRADIUSプロトコルの仕様。

RADIUS―ユーザ認証セキュリティプロトコル

posted with amazlet at 09.01.29

Jonathan Hassell アクセンス・テクノロジー
オライリー・ジャパン
売り上げランキング: 193762

Amazon.co.jp で詳細を見る

• RADIUS認証プロトコル。RFC2865。
• ただし、アカウンティングについては、RADIUSアカウンティングプロトコル。こちらはRFC2866。
• UDPを使用する。理由は以下。
  • 通常、RADIUSはプライマリ、セカンダリで構成する。従って、片方から応答がない場合にもう片方に送信しなおす「再送信タイマ」処理が必要。TCPの再送信は「別のサーバに送信し直す」ということではないので、UDPのほうがよい。
  • また、利用者の使い勝手を考えると、確実性のために時間がかかるTCPを使う必要がない。UDPで一定時間応答がなければ、別の認証サーバにつないで、早くサービス開始できるほうがよい。
  • クライアント・サーバ間の接続が確立されていないといけない「ステートフル」なTCPよりも、クライアント・サーバ・ネットワークに問題があっても、最初の一度だけ初期化して、必要なときにデータのやり取りを行える、「ステートレス」なUDPのほうが手間を省ける。
  • 複数の認証を同時に受けるような場合には、UDPの方がシンプルに実装できる。

  ただし、逆にデメリットもある。

  • TCPなら再送信処理は元から組み込まれているが、UDPの場合は自分で実装する必要がある。
• 標準では1812番ポートを使用する。アカウンティングプロトコルは1813番。ただし、昔の名残で、1645番、1646番をデフォルトで使おうとする実装も多いので注意。
• 基本的な動作の流れは以下。
  1. クライアントが、認証に必要な情報を含めたアクセス要求パケットを、サーバに送信する。
  2. サーバは、アクセス要求パケットを受け取ったら、以下のどれかの応答パケットを返す。
     • アクセス許可
     • アクセス拒否
     • アクセスチャレンジ
  3. 一定時間内にサーバからの応答パケットが返ってこない場合は、クライアントは再送信する。
• パケットの形式は以下。構造はアカウンティングプロトコルも同じ。
  

  種別コード	識別子	パケット長	認証符号
  属性データ（可変サイズ）

  • 種別コード。パケットの種類を表す。主なものは以下。
    • 1: Access-Request（アクセス要求）
    • 2: Access-Accept（アクセス許可）
    • 3: Access-Reject（アクセス拒否）
    • 4: Accounting-Request（アカウンティング要求）※アカウンティングプロトコル
    • 5: Accounting-Response（アカウンティング応答）※アカウンティングプロトコル
    • 11: Access-Challenge（アクセスチャレンジ）
  • 識別子。要求パケットと応答パケットの対応を行う。
  • パケット長。パケットの長さを表して、実際のパケットとチェックするために使う。
  • 認証符号。データ（特にパスワード）の暗号化・解読のために使う。
• パケットの種類について。以下、認証・承認に関する部分。
  • アクセス要求
    ユーザID、ネットワークサービスを提供する機器のIPアドレス、暗号化されたパスワードが含まれ、サービスの利用開始を要求する。
  • アクセス許可
    許可された、利用可能なサービス情報が含まれ、サービスの利用を許可する。
  • アクセス拒否
    主に拒否された理由等の文字列が含まれれ、サービスの利用を拒否する。Reply-Message属性とProxy-State属性のみ指定可能。
  • アクセスチャレンジ
    利用者に再度何らかの情報入力を求め、アクセス要求パケットを再送信させる場合に使用する。ワンタイムパスワードとかかな？Reply-Message属性とState属性のみ指定可能。このパケットを受け取ったクライアントはState属性に同じ文字列を指定する必要がある。

ちょっと細かすぎたかな。も少しシンプルにまとめていきたいなー。

今日のところはここまで。

Category: Server |