ケルベロス認証

歴史と発展

MITは、Project Athenaによって提供されるネットワークサービスを保護するためにKerberosを開発しました。このプロトコルは、ギリシャ神話のキャラクターであるケルベロス(またはケルベロス)にちなんで名付けられたもので、ギリシャ神話ではハーデスの怪物的な3つの頭を持つ番犬として知られています。プロトコルにはいくつかのバージョンが存在します。

Kerberos バージョン 4 (DES 暗号化アルゴリズムに 56 ビットの鍵を使用した) の主要設計者である Steve Miller と Clifford Neuman は、1989 年にそのバージョンを公開したが、彼らは主にプロジェクト Athena のためにそれを目標としていた。

ジョン・コールとクリフォード・ニューマンによって設計されたバージョン5は、バージョン4の制限とセキュリティの問題を克服することを意図して、1993年にRFC1510として登場しました(2005年にRFC4120によって廃止されました)。MITは、BSDライセンスと同様のソフトウェアライセンスの下で、Kerberos Version 5の実装を自由に利用できるようにしています。

いくつかの企業が、以下のような商用ソフトウェアでKerberos Version 5を使用していました。

·         Microsoft の Windows 2000 以降では、デフォルトの認証方法として Kerberos を使用しています。Kerberos プロトコル群にマイクロソフトが追加したもの
は、RFC 3244「Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols」で文書化されています。
RFC 4757 は、Microsoft が RC4 暗号を使用していること
を文書化しています。マイクロソフトはKerberosプロトコルを使用していますが、MITソフトウェアは使用していません[1]。

·         AppleのMac OS Xもクライアント版とサーバ版の両方でKerberosを使用しています。

·         Red Hat Linux バージョン 4 以降では、クライアントとサーバーの両方で Kerberos を使用しています。

2005年、IETF Kerberosワーキンググループは、Kerberosバージョン5 [2]のための新しい更新された仕様を導入しました。

·         "Encryption and Checksum Specifications" (RFC 3961)。

·         "Advanced Encryption Standard (AES) Encryption for Kerberos 5" (RFC 3962)。

·         Kerberosバージョン5仕様「The Kerberos Network Authentication Service (V5)」(RFC 4120)の新版。このバージョンでは、RFC 1510 を削除し、プロトコルの側面と使用目的をより詳細に明確に説明しています。

·         GSS-API仕様の新版"The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism.バージョン2"(RFC 4121)を参照してください。

2007年、MITは開発継続のためにKerberosコンソーシアムを結成しました。

プロトコル

Kerberos は、Needham-Schroeder プロトコルをベースにしている。これは、「鍵配布センター(KDC)」として知られる信頼された第三者認証を利用しており、2つの論理的に分離した部分から構成されています。Kerberosは、ユーザの身元を証明するための「チケット」(Kerberosチケットと呼ばれる)に基づいて動作します。

Kerberos データベース。ネットワーク上の各エンティティ(クライアントであれサーバであれ)は、自分自身とKDCだけが知っている秘密鍵を共有する。この鍵の知識は、各エンティティの身元を証明するのに役立つ。2 つのエンティティ間の通信では、KDC はセッション鍵を生成し、これを使用して通信の安全性を確保する。

用語「Kerberosサーバ」は、一般的にKDCを指す。信頼性のために、バックアップのKDCを持つことが可能です。これらは「Kerberosスレーブサーバ」と呼ばれています。すべてのスレーブは、マスターのKerberosサーバからデータベースを同期させます。

用語「Kerberized application server」は、一般に、認証のためにKerberosチケットを使用してクライアントが通信するKerberizedプログラムを指します。例えば、Kerberos telnet サーバは、Kerberized アプリケーションサーバの一例です。用語 "Kerberizedアプリケーション"は、Kerberizedアプリケーションサーバのクライアント側を参照するために使用されている間 , 例えば、Kerberos telnetクライアントは、Kerberizedアプリケーションの例です .

プロトコルのセキュリティは大きく依存しています。

1. ゆるやかに同期した時間を維持している参加者。
2. 正真正銘の短命宣言：ケルベロスのチケット。

プロトコルの簡単な説明

以下のような略語を使用します。

·         AS = 認証サーバ

·         TGS = チケット付与サーバー

·         SSまたはサーバ＝サービスサーバ（プリントサーバ、ファイルサーバなど、そのサービスを要求するサーバ利用者。

·         TGT = Ticket Granting Ticket (TGS用のKerberosチケット。ASが作成し、TGSとの通話に使用)。

簡単に言えば、クライアントは長期的な共有秘密を使ってASに認証し、ASからチケットを受け取ります。その後、クライアントはこのチケットを使用して、同じ共有秘密を使用してSSに対する追加のチケットを取得することができます。これらのチケットは、SSへの認証を証明するために使用することができます。

より詳細なプロトコル

ユーザークライアントベースのログオンステップ。

1. ユーザーは、クライアントマシン上でユーザー名とパスワードを入力します。
2. クライアントは入力されたパスワードに対して一方向関数（主にHash関数）を実行し、これがクライアント/ユーザの秘密鍵となります。

クライアント認証のステップ。

1. クライアントは、ユーザーに代わってサービスを要求するクリアテキストメッセージをASに送信します。
   メッセージの例。"ユーザーXYZはサービスを要求したいと考えています。
   注意: 秘密鍵もパスワードもASには送信されません。
2. ASはクライアントがデータベースにあるかどうかを確認します。存在する場合、ASは以下の2つのメッセージをクライアントに送り返します。
• メッセージA：クライアント/ユーザーの秘密鍵を使用して暗号化されたクライアント/TGSセッション鍵。
• メッセージB：TGT（クライアントID、クライアントネットワークアドレス、チケット有効期間、クライアント/TGSセッションキーを含む）をTGSの秘密鍵で暗号化したもの。
3. クライアントはメッセージAとBを受信すると、メッセージAを復号化してクライアント/TGSセッションキーを取得します。このセッションキーはTGSとの通信に使用されます。この時点で、クライアントは TGS に対して自分自身を認証するのに十分な情報を持っています。
   注: メッセージBはTGSの秘密鍵を使って暗号化されているため、クライアントはメッセージBを復号化することができません。

クライアントサービスの承認ステップ。

1. サービスを依頼する場合、クライアントは以下の2つのメッセージをTGSに送信します。
• メッセージC：メッセージBのTGTと要求されたサービスのIDで構成されます。
• メッセージ D.クライアントIDとタイムスタンプで構成される認証機能で、クライアント/TGSセッションキーを使用して暗号化されています。
2. メッセージ C と D を受信すると、TGS はメッセージ C からメッセージ B を取り出します。これにより、クライアント/TGS セッションキーが与えられる。このキーを使用して、TGSはメッセージD（Authenticator）を復号化し、以下の2つのメッセージをクライアントに送信する。
• メッセージE：クライアント間チケット（クライアントID、クライアントネットワークアドレス、有効期間、クライアント/サーバセッションキーを含む）をSS秘密鍵を使用して暗号化したもの。
• メッセージF：クライアント/サーバセッションキーをクライアント/TGSセッションキーで暗号化しました。

クライアントサービスリクエストのステップ。

1. TGSからメッセージEとFを受信すると、クライアントはSSに自分自身を認証するのに十分な情報を持っています。クライアントはSSに接続し、以下の2つのメッセージを送信します。
• メッセージE: 前のステップ(クライアント間のチケット、SS秘密鍵を使って暗号化されたもの)からのメッセージです。
• メッセージ G: クライアント ID、タイムスタンプを含む新しい Authenticator で、クライアント/サーバー セッションキーを使用して暗号化されています。
2. SS は自身の秘密鍵を使用してチケットを復号化し、クライアント/サーバー セッション キーを取得します。セッションキーを使用して、SSはAuthenticatorを復号化し、クライアントに以下のメッセージを送信して、クライアントの真のアイデンティティとクライアントにサービスを提供する意思を確認します。
• メッセージ H: クライアントの Authenticator で検出されたタイムスタンプに 1 を加えたもので、クライアント/サーバー セッション キーを使用して暗号化されています。
3. クライアントは、クライアント/サーバセッションキーを使用して確認書を復号化し、タイムスタンプが正しく更新されているかどうかを確認します。もし更新されていれば、クライアントはサーバを信頼し、サーバにサービスリクエストを発行することができます。
4. サーバは要求されたサービスをクライアントに提供します。

欠点

• 単一障害点。中央サーバの継続的な可用性が必要です。Kerberosサーバがダウンすると、誰もログインできなくなります。これは、複数のKerberosサーバと緊急認証メカニズムを使用することで解決できます。
• Kerberosは、関係するすべてのホストのクロックを同期させる必要があります。チケットには利用可能な時間帯があり、ホストのクロックがKerberosサーバのクロックと同期していない場合、認証は失敗します。デフォルトの設定では、クロックの時間が10分以上離れていないことが要求されます。実際には、すべてのホストの同期を保つために、通常は Network Time Protocol (NTP) が使用されます。
• 管理プロトコルは標準化されておらず、サーバの実装間で異なります。パスワードの変更についてはRFC 3244に記載されています。
• すべてのユーザの秘密鍵は中央サーバに保存されているため、そのサーバが侵害されると、すべてのユーザの秘密鍵が侵害されることになります。
• 危殆化したクライアントは、ユーザーのパスワードを危殆化させます。

関連ページ

• アイデンティティ管理
• セキュアリモートパスワードプロトコル(SRP)
• 汎用セキュリティサービスアプリケーションプログラムインタフェース(GSS-API)