Kerberos (プロトコル)

ケルベロス
開発者	マサチューセッツ工科大学
安定版リリース	バージョン5、リリース1.21 / 2023年6月5日; 18か月前
書かれた	Ｃ
オペレーティング·システム	クロスプラットフォーム
タイプ	認証プロトコル
Webサイト	web.mit.edu/kerberos/

Kerberos ( / ˈ k ɜːr b ər ɒ s / ) は、チケットに基づいて機能し、安全でないネットワークを介して通信するノードが互いに安全な方法で ID を証明できるようにするコンピュータネットワーク認証プロトコルです。設計者は主にクライアントサーバーモデルを対象としており、ユーザーとサーバーの両方が互いの ID を確認する相互認証を提供します。Kerberos プロトコルメッセージは、盗聴やリプレイ攻撃から保護されています。

Kerberosは対称鍵暗号方式に基づいており、信頼できる第三者を必要とし、認証の特定の段階ではオプションで公開鍵暗号方式を使用する場合もあります。 ^{[2] Kerberosはデフォルトで}UDPポート88を使用します。

このプロトコルは、ギリシャ神話のハデスの凶暴な三つの頭を持つ番犬ケルベロス（またはケルベロス）にちなんで名付けられました。^[3]

歴史と発展

マサチューセッツ工科大学(MIT)は、1988 年にプロジェクト Athenaが提供するネットワークサービスを保護するために Kerberos を開発しました。^[4]^{[5]最初のバージョンは、以前の}Needham–Schroeder 対称鍵プロトコルに基づいて、主に Steve Miller と Clifford Neuman によって設計されました。^[6]^[7] Kerberos バージョン 1 から 3 は実験的なものであり、MIT 外部にはリリースされませんでした。^[8]

最初の公開バージョンである Kerberos バージョン 4 は、1989 年 1 月 24 日にリリースされました。Kerberos 4 は米国で開発され、データ暗号化標準(DES)暗号化アルゴリズムを使用していたため、米国の輸出管理規制により他国への輸出が禁止されていました。MIT は、すべての暗号化コードを削除した Kerberos 4 の輸出可能なバージョンを作成しました。^{[8]これは「Bones」と呼ばれています。}^{[9]オーストラリアの}ボンド大学の Eric Young は、DES を Bones に再実装し、「eBones」と呼ばれるバージョンを作成しました。これはどの国でも自由に使用できます。スウェーデンの王立工科大学は、KTH-KRB と呼ばれる別の再実装をリリースしました。^[10]

Neuman と John Kohl は、既存の制限とセキュリティの問題を克服する目的で、1993 年にバージョン 5 を公開しました。バージョン 5 は RFC 1510 として登場しましたが、2005 年に RFC 4120 によって廃止されました。

2005 年に、インターネット技術タスクフォース(IETF) Kerberos ワーキンググループは仕様を更新しました。更新内容は次のとおりです。

暗号化およびチェックサムの仕様 (RFC 3961)。
Kerberos 5 のAdvanced Encryption Standard (AES) 暗号化 (RFC 3962)。
Kerberos V5 仕様「Kerberos ネットワーク認証サービス (V5)」(RFC 4120) の新しいエディション。このバージョンでは、RFC 1510 が廃止され、プロトコルの側面と使用目的がより詳細かつ明確に説明されています。
汎用セキュリティサービスアプリケーションプログラムインターフェイス(GSS-API) 仕様の新しいエディション「Kerberos バージョン 5 汎用セキュリティサービスアプリケーションプログラムインターフェイス (GSS-API) メカニズム: バージョン 2」(RFC 4121)。

MIT は、 BSDに使用されているものと同様の著作権許可の下で、Kerberos の実装を自由に利用できるようにしています。2007 年に、MIT は継続的な開発を促進するために Kerberos コンソーシアムを結成しました。設立スポンサーには、Oracle、Apple Inc.、Google、Microsoft、Centrify Corporation、TeamF1 Inc. などのベンダー、スウェーデン王立工科大学、スタンフォード大学、MIT などの学術機関、および商用サポート付きバージョンを提供する CyberSafe などのベンダーが含まれています。

プロトコル

説明

クライアントは、キー配布センター(KDC)の一部である認証サーバー (AS)に対して自身を認証します。KDC は、タイムスタンプ付きのチケット許可チケット (TGT)を発行し、チケット許可サービス (TGS) の秘密キーを使用してこれを暗号化し、暗号化された結果をユーザーのワークステーションに返します。これはまれにしか行われず、通常はユーザーのログオン時に行われます。TGT は、ある時点で期限切れになりますが、ユーザーがログインしている間にユーザーのセッションマネージャーによって透過的に更新される場合があります。

クライアントが別のノード (Kerberos 用語では「プリンシパル」) 上のサービスと通信する必要がある場合、クライアントは TGT を TGS に送信します。TGS は KDC の別のコンポーネントであり、通常は認証サーバーと同じホストを共有します。サービスは、サービスプリンシパル名 (SPN)を使用して TGS にすでに登録されている必要があります。クライアントは SPN を使用してこのサービスへのアクセスを要求します。TGT が有効であり、ユーザーが要求されたサービスへのアクセスを許可されていることを確認した後、TGS はサービスチケット (ST)とセッションキーをクライアントに発行します。次に、クライアントはサービス要求とともにチケットをサービスサーバー (SS)に送信します。

プロトコルの詳細については以下で説明します。

Kerberos を使用しないユーザークライアントベースのログイン

ユーザーは、クライアントマシンにユーザー名とパスワードを入力します。pkinit (RFC 4556) などの他の認証メカニズムでは、パスワードの代わりに公開キーを使用できます。クライアントは、パスワードを対称暗号のキーに変換します。これは、使用する暗号スイートに応じて、組み込みのキースケジューリングまたは一方向ハッシュを使用します。
サーバーはユーザー名と対称暗号を受信し、それをデータベースのデータと比較します。暗号がユーザー用に保存されている暗号と一致する場合、ログインは成功です。

クライアント認証

クライアントは、ユーザーに代わってサービスを要求し、ユーザー ID のプレーンテキストメッセージを AS (認証サーバー) に送信します。(注: 秘密キーもパスワードも AS に送信されません。)
AS は、クライアントがデータベース内に存在するかどうかを確認します。存在する場合、AS はデータベース ( Windows Server のActive Directoryなど) で見つかったユーザーのパスワードをハッシュして秘密キーを生成し、次の 2 つのメッセージをクライアントに返します。
- メッセージ A:クライアント/ユーザーの秘密キーを使用して暗号化されたクライアント/TGS セッションキー。
- メッセージ B: TGS の秘密キーを使用して暗号化されたTicket-Granting-Ticket (TGT、クライアント ID、クライアントネットワークアドレス、チケットの有効期間、およびクライアント/TGS セッションキーを含む)。
クライアントはメッセージ A と B を受信すると、ユーザーが入力したパスワードから生成された秘密鍵を使用してメッセージ A を復号化しようとします。ユーザーが入力したパスワードが AS データベースのパスワードと一致しない場合、クライアントの秘密鍵は異なるため、メッセージ A を復号化できません。有効なパスワードと秘密鍵を使用して、クライアントはメッセージ A を復号化して、クライアント/TGS セッションキーを取得します。このセッションキーは、TGS との以降の通信に使用されます。(注: メッセージ B は TGS の秘密鍵を使用して暗号化されているため、クライアントはメッセージ B を復号化できません。) この時点で、クライアントは TGS に対して認証するのに十分な情報を持っています。

クライアントサービス承認

サービスを要求する場合、クライアントは次のメッセージを TGS に送信します。
- メッセージ C: メッセージ B (TGS 秘密キーを使用して暗号化された TGT) と要求されたサービスの ID で構成されます。
- メッセージ D: 認証子 (クライアント ID とタイムスタンプで構成)、クライアント/TGS セッションキー(メッセージ A でクライアントによって検出) を使用して暗号化されます。
メッセージ C と D を受信すると、TGS はメッセージ C からメッセージ B を取得します。TGS は TGS 秘密キーを使用してメッセージ B を復号化します。これにより、クライアント/TGS セッションキーとクライアント ID (両方とも TGT 内にあります) が提供されます。このクライアント/TGS セッションキーを使用して、TGS はメッセージ D (認証子) を復号化し、メッセージ B と D のクライアント ID を比較します。一致する場合、サーバーは次の 2 つのメッセージをクライアントに送信します。
- メッセージ E:サービスの秘密キーを使用して暗号化されたクライアントからサーバーへのチケット(クライアント ID、クライアントネットワークアドレス、有効期間、クライアント/サーバーセッションキーが含まれます)。
- メッセージ F:クライアント/TGS セッションキーで暗号化されたクライアント/サーバーセッションキー。

クライアントサービスリクエスト

TGS からメッセージ E と F を受信すると、クライアントはサービスサーバー (SS) に対して認証するのに十分な情報を持ちます。クライアントは SS に接続し、次の 2 つのメッセージを送信します。
- メッセージ E: 前のステップから ( TGS によってサービスの秘密キーを使用して暗号化されたクライアントからサーバーへのチケット)。
- メッセージ G: クライアント ID、タイムスタンプが含まれ、クライアント/サーバーセッションキーを使用して暗号化された新しい認証子。
SS は独自の秘密鍵を使用してチケット (メッセージ E) を復号化し、クライアント/サーバーセッションキーを取得します。セッションキーを使用して、SS は認証子を復号化し、メッセージ E と G のクライアント ID を比較します。一致する場合、サーバーはクライアントに次のメッセージを送信して、その真の ID とクライアントにサービスを提供する意思を確認します。
- メッセージH: クライアントの認証子で見つかったタイムスタンプ（バージョン4ではプラス1、バージョン5では不要^[11]^[12]）。クライアント/サーバーセッションキーを使用して暗号化されます。
クライアントは、クライアント/サーバーセッションキーを使用して確認 (メッセージ H) を復号化し、タイムスタンプが正しいかどうかを確認します。正しい場合、クライアントはサーバーを信頼し、サーバーにサービス要求を発行できるようになります。
サーバーは要求されたサービスをクライアントに提供します。

オペレーティングシステムによるサポート

マイクロソフトウィンドウズ

Windows 2000以降のバージョンでは、デフォルトの認証方法として Kerberos を使用しています。^[13] Kerberos プロトコルスイートへのMicrosoft の追加の一部は、RFC 3244「Microsoft Windows 2000 Kerberos パスワード変更およびパスワード設定プロトコル」に記載されています。RFC 4757 には、Microsoft によるRC4暗号の使用が文書化されています。Microsoft は Kerberos プロトコルを使用および拡張していますが、MIT ソフトウェアは使用していません。

Kerberosは優先認証方法として使用されます。一般に、クライアントをWindowsドメインに参加させるということは、そのクライアントからWindowsドメインおよびそのドメインと信頼関係にあるすべてのドメイン内のサービスへの認証のデフォルトプロトコルとしてKerberosを有効にすることを意味します。^[13]

対照的に、クライアントまたはサーバーのいずれか、あるいは両方がドメインに参加していない場合（または同じ信頼されたドメイン環境の一部ではない場合）、Windowsはクライアントとサーバー間の認証にNTLMを使用します。^[13]

インターネット Web アプリケーションは、 SSPIで提供される API を使用して、ドメインに参加しているクライアントの認証方法として Kerberos を適用できます。

Microsoft WindowsとWindows Serverにはsetspnというコマンドラインユーティリティが含まれており、これを使用してActive Directoryサービスアカウントのサービスプリンシパル名（SPN）を読み取り、変更、または削除することができます。^[14]^[15]

Unixおよびその他のオペレーティングシステム

FreeBSD、Apple のmacOS、Red Hat Enterprise Linux、OracleのSolaris、IBM のAIX、HP-UXなど、多くの Unix 系オペレーティングシステムには、ユーザーまたはサービスの Kerberos 認証用のソフトウェアが含まれています。z /OS、IBM i、OpenVMSなど、さまざまな非 Unix 系オペレーティングシステムも Kerberos をサポートしています。組み込みプラットフォームで実行されるクライアントエージェントおよびネットワークサービス用の Kerberos V 認証プロトコルの組み込み実装も、企業^{[ which? ]}から入手できます。

欠点と制限

Kerberos には厳格な時間要件があり、つまり、関係するホストのクロックは、設定された制限内で同期されている必要があります。チケットには時間使用可能期間があり、ホストクロックが Kerberos サーバークロックと同期されていない場合、認証は失敗します。MIT によるデフォルト構成では、クロックの時刻の差は 5 分以内である必要があります。実際には、ネットワークタイムプロトコルデーモンを使用して、ホストクロックを同期させるのが一般的です。一部のサーバー (Microsoft の実装もその 1 つです) は、両方のクロックのオフセットが設定された最大値より大きい場合、暗号化されたサーバー時刻を含む KRB_AP_ERR_SKEW 結果を返すことがあります。その場合、クライアントは、提供されたサーバー時刻を使用して時刻を計算し、オフセットを見つけることで再試行できます。この動作は、RFC 4430 に記載されています。
管理プロトコルは標準化されておらず、サーバーの実装によって異なります。パスワードの変更については、RFC 3244 で説明されています。
対称暗号化を採用する場合 (Kerberos は対称暗号化または非対称 (公開鍵) 暗号化を使用して動作します)、すべての認証は集中型の鍵配布センター(KDC) によって制御されるため、この認証インフラストラクチャが侵害されると、攻撃者は任意のユーザーになりすますことができます。
異なるホスト名を必要とする各ネットワークサービスには、独自の Kerberos キーセットが必要になります。これにより、仮想ホスティングとクラスターが複雑になります。
Kerberos では、ユーザーアカウントとサービスが Kerberos トークンサーバーと信頼関係を持つ必要があります。
必要なクライアントの信頼により、段階的な環境 (テスト環境、実稼働前環境、実稼働環境の個別のドメインなど) の作成が困難になります。環境ドメインの厳密な分離を防ぐドメイン信頼関係を作成するか、環境ごとに追加のユーザークライアントを提供する必要があります。

安全

データ暗号化標準（ DES ）暗号はKerberosと組み合わせて使用できますが、脆弱であるため、インターネット標準ではなくなりました。^[16] AESなどの新しい暗号化暗号をサポートしていないKerberosのレガシーバージョンを実装した製品には、セキュリティ上の脆弱性が存在します。

参照

参考文献

^ 「Kerberos 5 リリース 1.21」。
^ RFC 4556、要約。
^ 「Kerberos 認証」。IONOS Digitalguide。2022年 8 月 25 日閲覧。
^ ガーマン2003、5ページ。
^ Steiner, Jennifer G.; Geer, Daniel E. (1988 年 7 月 21 日)。Athena環境におけるネットワークサービス。1988 年冬期 Usenix カンファレンスの議事録。CiteSeerX 10.1.1.31.8727。
^ シュタイナー、ジェニファー・G.、ニューマン、クリフォード、シラー、ジェフリー・I.（1988年2月）。Kerberos : オープンネットワークシステム用の認証サービス。1988年冬 USENIX カンファレンスの議事録。CiteSeerX 10.1.1.112.9002。S2CID 222257682 。
^ Elizabeth D. Zwicky、Simon Cooper、D. Brent (2000 年 6 月 26 日)。インターネットファイアウォールの構築: インターネットと Webセキュリティ。O'Reilly。ISBN 9781565928718。
^ ガーマン2003、7ページより。
^ Pröhl & Kobras 2022、7ページ。
^ ガーマン2003、7-8頁。
^ Neuman, C.; Kohl, J. (1993). 「Kerberos ネットワーク認証サービス (V5)」. doi : 10.17487/RFC1510 . 2016-08-21 にオリジナルからアーカイブされました。
^ Neuman, Clifford; Hartman, Sam; Yu, Tom; Raeburn, Kenneth (2005). 「Kerberos ネットワーク認証サービス (V5)」。doi :10.17487/RFC4120。2016 年 8 月 21 日時点のオリジナルよりアーカイブ。
^ abc 「Kerberos 認証とは?」。Microsoft TechNet。2009 年 10 月 8 日。2016 年 12 月 20 日時点のオリジナルよりアーカイブ。
^ Setspn - Windows CMD - SS64.com
^ Setspn | Microsoft Docs
^ Tom, Yu; Love, Astrand (2012). 「Kerberos における DES、RC4-HMAC-EXP、およびその他の弱い暗号化アルゴリズムの廃止」doi :10.17487/RFC6649. 2015-10-27 にオリジナルからアーカイブ化。

一般的な

ガーマン、ジェイソン (2003)。ケルベロス: 決定版ガイド。O'Reilly Media, Inc. ISBN 978-0-596-00403-3。
マーク・プロール。コブラス、ダニエル（2022年4月14日）。 Kerberos: gemischten Linux/Windows-Umgebungen でのシングルサインオン (ドイツ語)。 dpunkt.verlag。 p. 7.ISBN 9783960888512。
Lynn Root (2013 年 5 月 30 日) (2013 年 4 月 2 日)。「5 歳児に説明する: Kerberos」。Lynn Root のブログ。{{cite web}}: CS1 maint: 数値名: 著者リスト (リンク)
Microsoft TechNet (2012 年 7 月 18 日)。「Kerberos プロトコルの基本概念」。MSDNライブラリ。
リソースキットチーム (2021 年 1 月 7 日)。「Microsoft Kerberos (Windows)」。MSDN ライブラリ。
B. Clifford Neuman、Theodore Ts'o (1994 年 9 月)。「 Kerberos : コンピュータネットワークの認証サービス」。IEEE Communications。32 ( 9): 33–8。doi : 10.1109 /35.312841。S2CID 45031265。
Kohl, John T.; Neuman, B. Clifford; Ts'o, Theodore Y. (1994)。「Kerberos認証システムの進化」。Brazier , FMT、Johansen, D (編)。分散オープンシステム。IEEE Computer Society Press。pp. 78–94。CiteSeerX 10.1.1.120.944。ISBN 978-0-8186-4292-0. OCLC 1191406172.
「Kerberos の概要: オープンネットワークシステム向けの認証サービス」。Cisco Systems。2006 年 1 月 19 日。2012 年8 月 15 日に閲覧。
「Kerberos 認証の仕組み」。learn-networking.com。2008 年 1 月 28 日。2015 年 4 月 2 日時点のオリジナルよりアーカイブ。2012年8 月 15 日に取得。
「Kerberos 認証とは: ログオンと認証」。Microsoft TechNet。2009 年 10 月 8 日。2016年12 月 7 日に閲覧。

RFC

RFC 1510 Kerberos ネットワーク認証サービス (V5) [廃止]
RFC 1964 Kerberos バージョン 5 GSS-API メカニズム
RFC 3961 Kerberos 5 の暗号化とチェックサムの仕様
RFC 3962 Kerberos 5 の Advanced Encryption Standard (AES) 暗号化
RFC 4120 Kerberos ネットワーク認証サービス (V5) [最新]
RFC 4121 Kerberos バージョン 5 汎用セキュリティサービスアプリケーションプログラムインターフェイス (GSS-API) メカニズム: バージョン 2
RFC 4537 Kerberos 暗号システムネゴシエーション拡張
RFC 4556 Kerberos の初期認証のための公開鍵暗号化 (PKINIT)
RFC 4557 オンライン証明書ステータスプロトコル (OCSP) Kerberos の初期認証のための公開鍵暗号化のサポート (PKINIT)
RFC 4757 Microsoft Windows で使用される RC4-HMAC Kerberos 暗号化タイプ [廃止]
RFC 5021 拡張 Kerberos バージョン 5 鍵配布センター (KDC) TCP 経由の交換
RFC 5349 楕円曲線暗号 (ECC) Kerberos の初期認証のための公開鍵暗号のサポート (PKINIT)
RFC 5868 Kerberos のクロスレルム操作に関する問題ステートメント
RFC 5896 汎用セキュリティサービスアプリケーションプログラムインターフェイス (GSS-API): ポリシーで承認された場合の委任
RFC 6111 追加の Kerberos 命名制約
RFC 6112 Kerberos の匿名性サポート
RFC 6113 Kerberos 事前認証の一般化フレームワーク
RFC 6251 トランスポート層セキュリティ (TLS) プロトコル上で Kerberos バージョン 5 を使用する
RFC 6448 Kerberos 5 KRB-CRED メッセージの暗号化されていない形式
RFC 6542 Kerberos バージョン 5 汎用セキュリティサービスアプリケーションプログラムインターフェイス (GSS-API) チャネルバインディングハッシュアジリティ
RFC 6560 ワンタイムパスワード (OTP) 事前認証
RFC 6649 Kerberos における DES、RC4-HMAC-EXP、およびその他の弱い暗号化アルゴリズムを非推奨にする
RFC 6784 DHCPv6 の Kerberos オプション
RFC 6803 Kerberos 5 の Camellia 暗号化
RFC 6806 Kerberos プリンシパル名の正規化とクロスレルム参照
RFC 6880 Kerberos バージョン 5 の情報モデル
RFC 8009 Kerberos 5 向け HMAC-SHA2 による AES 暗号化

さらに読む

「タニー法に基づくマイクロソフトと司法省間の和解案に対するノベル社のコメント」。民事訴訟番号 98-1232 (CKK): 米国対マイクロソフト社。司法省。2002 年 1 月 29 日。2012 年8 月 15 日に閲覧。
ブライアント、ビル (1988 年 2 月)。「認証システムの設計: 4 つのシーンの対話」。Kerberosの設計がどのように進化したかに関するユーモラスな劇。MIT。
Hornstein, Ken (2000 年 8 月 18 日)。「Kerberos FAQ, v2.0」。海軍長官。2002 年 12 月 3 日時点のオリジナルよりアーカイブ。2012年8 月 15 日閲覧。
Bellovin, SM; Merritt, M. (1990 年 10 月 1 日)。「 Kerberos 認証システムの限界」。ACM SIGCOMM Computer Communication Review。20 ( 5): 119–132。doi : 10.1145 /381906.381946。S2CID 8014806 。
Neuman , BC; Ts'o, T. (1994年9 月)。「Kerberos: コンピュータネットワークの認証サービス」IEEE Communications Magazine。32 ( 9 ): 33–38。doi :10.1109/35.312841。S2CID 45031265。
Bella, Giampaolo; Paulson, Lawrence C. (1998)。「Kerberos バージョン IV: 秘密保持目標の帰納的分析」。コンピュータセキュリティ — ESORICS 98。コンピュータサイエンスの講義ノート。第 1485 巻。361 ～ 375 ページ。doi : 10.1007/ BFb0055875。ISBN 978-3-540-65004-1。
Abdelmajid, NT; Hossain, MA; Shepherd, S.; Mahmoud, K. (2010)。「修正された BAN ロジックを使用した Kerberos セキュリティプロトコルの評価の改善」。2010第 10 回 IEEE 国際コンピュータおよび情報技術会議。pp. 1610–1615。doi : 10.1109 / CIT.2010.285。ISBN 978-1-4244-7547-6. S2CID 6246388。

外部リンク

ケルベロスコンソーシアム
MITウェブサイトの Kerberos ページ
IETFウェブサイトの Kerberos ワーキンググループ
Kerberos シーケンス図 2015-03-26 にWayback Machineでアーカイブされました
ヘイムダル/ケルベロスの実装

[1] 「Kerberos 5 リリース 1.21」。

[rfc4556-2] RFC 4556、要約。

[3] 「Kerberos 認証」。IONOS Digitalguide。2022年 8 月 25 日閲覧。

[FOOTNOTEGarman20035-4] ガーマン2003、5ページ。

[Athena_Network_Services-5] ^ Steiner, Jennifer G.; Geer, Daniel E. (1988 年 7 月 21 日)。Athena環境におけるネットワークサービス。1988 年冬期 Usenix カンファレンスの議事録。CiteSeerX 10.1.1.31.8727。

[6] シュタイナー、ジェニファー・G.、ニューマン、クリフォード、シラー、ジェフリー・I.（1988年2月）。Kerberos : オープンネットワークシステム用の認証サービス。1988年冬 USENIX カンファレンスの議事録。CiteSeerX 10.1.1.112.9002。S2CID 222257682 。

[Building_Internet_Firewalls-7] Elizabeth D. Zwicky、Simon Cooper、D. Brent (2000 年 6 月 26 日)。インターネットファイアウォールの構築: インターネットと Webセキュリティ。O'Reilly。ISBN 9781565928718。

[FOOTNOTEGarman20037-8] ガーマン2003、7ページより。

[FOOTNOTEPröhlKobras20227-9] Pröhl & Kobras 2022、7ページ。

[FOOTNOTEGarman20037–8-10] ガーマン2003、7-8頁。

[11] Neuman, C.; Kohl, J. (1993). 「Kerberos ネットワーク認証サービス (V5)」. doi : 10.17487/RFC1510 . 2016-08-21 にオリジナルからアーカイブされました。

[12] Neuman, Clifford; Hartman, Sam; Yu, Tom; Raeburn, Kenneth (2005). 「Kerberos ネットワーク認証サービス (V5)」。doi :10.17487/RFC4120。2016 年 8 月 21 日時点のオリジナルよりアーカイブ。

[MSTN-Kerberos-Auth-13] 「Kerberos 認証とは?」。Microsoft TechNet。2009 年 10 月 8 日。2016 年 12 月 20 日時点のオリジナルよりアーカイブ。

[14] Setspn - Windows CMD - SS64.com

[15] Setspn | Microsoft Docs

[16] Tom, Yu; Love, Astrand (2012). 「Kerberos における DES、RC4-HMAC-EXP、およびその他の弱い暗号化アルゴリズムの廃止」doi :10.17487/RFC6649. 2015-10-27 にオリジナルからアーカイブ化。