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

相変わらず体調も精神も停滞気味な感じですが、無理せずできるレベルでがんばります。

毎週水曜日は「サーバ」の時間だったのだけど、これ！と興味が沸くようなものがなくて、ダラダラと本を読んだりしてたのですが、ちょい仕事で必要に迫られたこともあって（笑）今回から『RADIUS』を勉強してみようかと思います。

とはいっても、日常業務でそれなりには触ってるので、ちゃんと系統立てて整理していくのが目的です。

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

posted with amazlet at 09.01.29

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

Amazon.co.jp で詳細を見る

RADIUSとは

• Remote Access Dial In User Serviceの略。
• 「AAA」モデル。認証（Authentication）、承認（Authorization）、アカウンティング（Accounting）。
  • 認証 ・・・ 正規のユーザであるかの確認。一般的なIDとパスワードの組み合わせ。
  • 承認 ・・・ 認証されたユーザに対して、どのようなサービスを許可するのか。
  • アカウンティング ・・・ ユーザが利用した事実と利用状況を記録する。
• クライアント・サーバ方式。クライアントがサーバのリソースを使用する。
• プロキシも可能。AAAサーバが他のAAAサーバへの要求の転送を行う。プロバイダ同士の再販とか卸とか。
• ホップトゥホップ方式とエンドトゥエンド方式。
  • ホップトゥホップ方式
    • 利用者端末 <=> 着信装置（NAS、BASなど）<=> AAAサーバ <=> 他AAAサーバ
    • 隣接する機器同士の間に「信頼」関係が確立される。（利用者端末と着信装置、着信装置とAAAサーバ、AAAサーバと他AAAサーバ、・・・）
  • エンドトゥエンド方式
    • 利用者端末 <-> 着信装置（NAS、BASなど）<-> AAAサーバ <-> 他AAAサーバ
    • 利用者端末と最終到達点のAAAサーバ間で「信頼」関係が確立される。その間は単なる経路。
• AAA承認フレームワーク
  • エージェント手順
    利用者端末とサービス機器の間にAAAサーバを置く。利用者端末からの要求をAAAサーバが承認し、サービス機器にサービス提供を指示する。
  • プル手順
    利用者端末とAAAサーバの間にサービス機器を置く。利用者端末からの要求があれば、サービス機器は、承認をAAAサーバに行い、承認されたら利用者端末にサービスを提供する。
  • プッシュ手順
    利用者端末はAAAサーバに要求を行い、承認されたら「チケット」を応答する。利用者端末はそのチケットを持って、サービス機器にサービスの提供を要求する。
• UHO(User Home Organization) ・・・ エンドユーザと直接サービス利用契約関係を結ぶ組織。
• サービスプロバイダ ・・・ 実際にサービスを提供する組織。
• UHOとサービスプロバイダが同一の場合は、AAAサーバとサービス機器は同じ組織内にあることが多い。
• UHOとサービスプロバイダが別々の場合は、UHOがAAAサーバを持ち、サービスプロバイダがサービス機器＋AAAサーバを持つ、などの形態になる。これをローミングという。ローミングでも上の３つの承認フレームワークが当てはまる。
• UHOが、複数の別々のサービスプロバイダを利用して、一定のサービスを利用させるような形態を、分散サービスという。
• どのようなルールでユーザを承認しサービスを提供するかを決めているのがポリシーである
• 資源管理とセッション管理
  • 資源管理
    割当可能な資源の利用状況を監視するための機能
  • セッション管理
    セッション状況を記録し、その内容に応じてセッションの状態を変更させる機能。
• RADIUSプロトコルの特徴
  • UDP。
  • ホップトゥホップ。
  • 「状態」がない。
  • PPPでのPAP認証とCHAP認証をサポート。
  • MD5によるパスワードの隠蔽。
  • 属性値のペア。ベンダ固有で作ることも可能。
  • MD5によるパスワードの隠蔽
• RADIUSプロトコルの制限
  • セキュリティ的な問題。PPPのPAP認証では経由するプロキシがパスワードを見ることができる。
  • あくまでも承認までしか行わない。承認後は資源割当の解除や停止はできない。
  • 「状態」がないため、資源管理・セッション管理が100%ではない。
  • 大規模システムではパフォーマンスの低下、データの損失の問題が発生するため、スケーラビリティが低い。

まだ最初のところなので概念とか言葉とかそういう点が多いのだけど、AAAフレームワークみたいなのは、システムの設計や構成を考える上では非常に役に立ちますね。

今日はここまで。次回はRADIUSプロトコルの仕様についてです。

Category: Server |