Kerberos_PHP チュートリアルの概要

Kerberos の概要

Kerberos プロトコル:

Kerberos プロトコルは、主にコンピュータ ネットワークの本人認証 (Authentication) に使用され、その特徴は、ユーザーがチケット (チケット交付チケット) を取得するために認証情報を 1 回入力するだけで済むことです。この検証に基づいて)、複数のサービス、つまり SSO (シングル サインオン) にアクセスします。各クライアントとサービスの間で共有キーが確立されるため、プロトコルは非常に安全です。

条件

まず、Kerberos プロトコルの前提条件を見てみましょう:

クライアントと KDC、KDC とサービスは、プロトコルが機能する前にすでに独自の共有キーを持っており、プロトコル内のメッセージはファイアウォールを通過できないため、これらの条件はこれにより、Kerberos プロトコルの使用が組織内での使用に制限され、そのアプリケーション シナリオが X.509 PKI とは異なります。

プロセス

Kerberos プロトコルは 2 つの部分に分かれています:

1. クライアントは ID 情報を KDC に送信し、KDC はチケット認可サービスから TGT (チケット認可チケット) を取得し、クライアントと KDC の間で情報を使用します。プロトコルが開始される前に、間にキーを使用して TGT 暗号化応答がクライアントに送信されます。

現時点では、本物のクライアントのみが、クライアントと KDC の間でキーを使用して、暗号化された TGT を復号化し、TGT を取得できます。

(このプロセスは、クライアントが検証を通過するためにパスワードを KDC に直接送信するという安全でない方法を回避します)

2. クライアントは、以前に取得した TGT を使用して、他のサービスのチケットを KDC に要求し、それによって、他のサービスの ID 認証。

Kerberos プロトコルの焦点は 2 番目の部分にあり、導入は次のとおりです。

1.クライアントは、以前に取得した TGT と要求するサービス情報 (サービス名など) を KDC に送信します。KDC 内のチケット認可サービスは、クライアントを認証するために、クライアントとサービスの間でセッション キーを生成します。 。次に、KDC はセッション キーをユーザー名、ユーザー アドレス (IP)、サービス名、有効期間、タイムスタンプとともにチケットにパッケージ化し (この情報は最終的にサービスがクライアントを認証するために使用します)、サービスに送信します。ただし、Kerberos プロトコルはチケットをサービスに直接送信するのではなく、クライアント経由でサービスに転送します。そのため、2 番目のステップがあります。

2. この時点で、KDC は正しいチケットをクライアントに転送します。このチケットはサービス用であり、クライアントには表示できないため、KDC は、プロトコルがチケットの暗号化を開始する前に、KDC とサービスの間でキーを使用してチケットをクライアントに送信します。同時に、クライアントとサービスの間でシークレット (最初のステップで KDC によって作成されたセッション キー) を共有するために、KDC はクライアントとサービスの間でそのキーを使用してセッション キーを暗号化し、一緒にクライアントに返します。暗号化されたチケットを使用して。

3． チケットの配信を完了するために、クライアントは受信したばかりのチケットをサービスに転送します。クライアントは KDC とサービスの間のキーを知らないため、チケット内の情報を変更できません。同時に、クライアントは受信したセッション キーを復号化し、ユーザー名とユーザー アドレス (IP) をオーセンティケーターにパッケージ化し、セッション キーで暗号化し、サービスに送信します。

4.チケットを受信した後、サービスはチケットと KDC 間のキーを使用してチケット内の情報を復号化し、それによりセッション キー、ユーザー名、ユーザー アドレス (IP)、サービス名、有効期間を取得します。次に、セッション キーを使用してオーセンティケータを復号化し、ユーザー名とユーザー アドレス (IP) を取得し、それを前のチケットで復号化したユーザー名とユーザー アドレス (IP) と比較して、クライアントの身元を確認します。

5. サービスが結果を返した場合は、それをクライアントに返します。

kinit - Kerberos チケット認可チケットの取得とキャッシュ

kinit は、Kerberos チケット認可チケットの取得とキャッシュに使用されます。このツールは、SEAM などの他の Kerberos 実装で一般的に見られる kinit ツールと機能的に似ています。

kinit を実行する前に、ユーザーはキー配布センター (KDC) にプリンシパルとして登録されている必要があります。

SYNOPSIS

kinit [ コマンド ] <プリンシパル名> [<パスワード>]

概要

要約すると、Kerberos プロトコルは主に 2 つのことを行います

1.チケットの安全な配送。

2.セッションキーの安全なリリース。

タイムスタンプの使用と組み合わせることで、ユーザー認証のセキュリティが大幅に保証されます。また、セッションキーを使用することで、認証を通過した後にクライアントとサービスの間で受け渡されるメッセージもConfidentiality(機密性)とIntegrity(完全性)によって保証することができます。ただし、非対称鍵を使用しないため、否認防止ができず、用途も限定されます。ただし、X.509 PKI ID 認証方法よりも実装が比較的簡単です。

特定のプロセス

(注: このプロセスは対称暗号化を使用します。このプロセスは特定の Kerberos レルムで発生します。小文字の c、d、および e はクライアントによって送信されたメッセージであり、大文字の A、B、およびE、F、G、H は各サーバーから返信されたメッセージです)

まず、ユーザーはクライアント (ユーザー自身のマシン) 上のプログラムを使用してログインします。

1. ユーザーはクライアントにユーザーIDとパスワードを入力します。
2. クライアント プログラムは、一方向関数 (主にハッシュ) を実行して、パスワードをキーに変換します。これは、クライアント (ユーザー) の「ユーザー キー」(K_client) です。信頼された AS も、何らかの安全な手段を通じてこのキーと同じキーを取得します。

その後、クライアントが認証されます (クライアントは AS からチケット (TGT) のチケットを取得します):

1. クライアントは 1 つのメッセージを AS に送信します (注: ユーザーはキー (K_client) を AS に送信せず、パスワードも送信しません):

• 「ユーザー Sunny がサービスをリクエストしたいと考えています」などのユーザー ID を含むクリア テキスト メッセージ (Sunny はユーザー ID)

AS はユーザー ID の有効性を確認し、次の 2 つのメッセージを返します:

• メッセージA: ユーザーキー (K_client) によって暗号化された「クライアント-TGS セッションキー」 (K_TGS-session) (セッションキーは、クライアントと TGS 間の今後の通信 (セッション) に使用されます)
• メッセージ B: TGS キー (K_TGS) で暗号化「チケット認証チケット」(TGT) (TGT には、クライアント - TGS セッション キー (K_TGS-session)、ユーザー ID、ユーザー URL、TGT 有効期間が含まれます)

クライアントは独自のキー (K_client) を使用して A を復号化し、クライアント TGS セッション キー (K_TGS-session)。 (注: B は TGS キー (K_TGS) で暗号化されているため、クライアントはメッセージ B を復号化できません)。

次に、サービス認可 (クライアントは TGS からチケット (T) を取得します):

1. クライアントは次の 2 つのメッセージを TGS に送信します:

• メッセージ c: つまり、メッセージ B (K_TGS 暗号化された TGT)、および取得したいサービスのサービス ID (注: ユーザー ID ではありません)
• メッセージ d: クライアント TGS セッション キー (K_TGS セッション) の暗号化された「認証子」 (認証子にはユーザー ID、タイムスタンプが含まれます)

TGS は独自の鍵 (K_TGS) を使用して B in c を復号し、TGT を取得します。これにより、AS によって提供されるクライアント - TGS セッション鍵 (K_TGS-session) が取得されます。次に、このセッション キーを使用して d を復号化し、ユーザー ID (認証) を取得し、2 つのメッセージを返します:

• メッセージ E: サーバー キー (K_SS) で暗号化された「クライアント サーバー チケット」 (T) (T には以下が含まれます:クライアント-SSセッション鍵(K_SS-session)、ユーザーID、ユーザーURL、T有効期間)
• メッセージF: クライアント-TGSセッション鍵(K_TGS-session)暗号化された「クライアントSSセッション鍵」(K_SS_session)

クライアントは、クライアント TGS セッション キー (K_TGS-session) を使用して F を復号し、クライアント SS セッション キー (K_SS_session) を取得します。 (注: E は SS キー (K_SS) で暗号化されているため、クライアントはメッセージ E を復号化できません)。

最後に、サービスリクエスト（クライアントはSSからサービスを取得します）：

1. クライアントはSSに2つのメッセージを送信します：

• メッセージe：つまりメッセージE
• メッセージg：クライアントサーバーセッションキー（K_SS_session）暗号化された「新しい認証子」 (新しい認証子には、ユーザー ID、タイムスタンプが含まれます)

SS は、独自のキー (K_SS) を使用して e/E を復号し、T を取得します。これにより、TGS によって提供されるクライアント - サーバー セッション キー (K_SS_session) を取得します。 ）。次に、このセッション キーを使用して g を復号化し、ユーザー ID (認証) を取得し、メッセージを返します (確認レター: ID が真実であり、サービスを提供する意思があることを確認します):

• メッセージ H: クライアント サーバー セッション キー(K_SS_session) 暗号化後の「新しいタイムスタンプ」 (新しいタイムスタンプは、クライアントによって送信されたタイムスタンプに 1 を加えたものです)

クライアントは、クライアントサーバーセッションキー (K_SS_session) を使用して H を復号化し、新しいタイムスタンプを取得します。

クライアントはタイムスタンプが正しく更新されていることを確認すると、サーバーを信頼してサーバー (SS) にサービス リクエストを送信できます。

サーバー（SS）がサービスを提供します。

欠陥

• 単一点で失敗します。中央サーバーからの継続的な応答が必要です。 Kerberos サービスが終了すると、誰もサーバーに接続できなくなります。この欠点は、複合 Kerberos サーバーと欠陥のある認証メカニズムを使用することで補うことができます。
• Kerberos では、通信に参加しているホストのクロックが同期している必要があります。チケットには有効期間があるため、ホストの時計が Kerberos サーバーの時計と同期していない場合、認証は失敗します。デフォルト設定では、クロック時刻の差が 10 分以内であることが必要です。実際には、ホスト クロックの同期を維持するために Network Time Protocol デーモンがよく使用されます。
• 管理プロトコルは標準化されておらず、サーバー実装ツールにはいくつかの違いがあります。 RFC 3244 では、パスワードの変更について説明しています。
• すべてのユーザーが使用するキーは中央サーバーに保存されるため、サーバーのセキュリティが侵害されると、すべてのユーザーのキーが侵害されます。
• 危険なクライアントはユーザーのパスワードを侵害します。

参考:
http://idior.cnblogs.com/archive/2006/03/20/354027.html
http://bey2nd.blog.163.com/blog/static/12063183120141275250466/
http:/ /docs.oracle.com/javase/1.5.0/docs/tooldocs/windows/kinit.html

http://www.bkjia.com/PHPjc/1097745.htmlwww.bkjia.com本当http://www.bkjia.com/PHPjc/1097745.html技術記事 Kerberos の概要 Kerberos プロトコル: Kerberos プロトコルは、主にコンピュータ ネットワークにおける ID 認証 (Authentication) に使用され、その特徴は、ユーザーが認証情報を 1 回入力するだけで確認できることです...

。