例 B-3 (AUTH_KERB) は、例 B-2 で示された AUTH_DES と似ています。両者の違いに注意してください。
#define AUTH_KERB 4
/*
* 資格には 2 種類あります。1 つはクライアントが (前もって暗号化された)
* Kerberos チケット送信する資格で、もう 1 つはクライアントがサーバーに指定され
* た「ニックネーム」(符号なしの整数のみ) を使用する資格です。クライアントは、
* サーバーへの初めてのトランザクションでは、フルネームを使用しなければなりませ
* ん。それに対してサーバーはクライアントにニックネームを返します。クライアントは
* それ以降、サーバーへのトランザクションでニックネームを使用できます。
* (チケットの期限が切れるまで)。 必ずニックネームを使用しなけれ
* ばならないわけではありませんが、パフォーマンスから考えても、ニック
* ネームを使用する方がよいでしょう。
*/
enum authkerb_namekind {
AKN_FULLNAME = 0,
AKN_NICKNAME = 1
};
/*
* フルネームには、暗号化されたサービスチケットと有効期限が含まれます。
* 実際、この有効期限は、資格の有効期限と同じです。ベリファイアの
* タイムスタンプに示されている時間に有効期限を加えた時間がすでに経過すると、
* サーバーは要求を満了にして、もはや承諾しません。要求がやり直されないようにす
* るため、サーバーは、はじめのトランザクション以外の場合に、タイムスタンプが以
* 前のタイムスタンプより大きくないかどうかをチェックする必要があります。はじ
* めのトランザクションでは、サーバーはウィンドウベリファイアがウィンドウより小
* さいことを検査します。
*/
struct authkerb_fullname {
KTEXT_ST ticket; /* Kerberos サービスチケット */
unsigned long window; /* 暗号化されたウィンドウ */
};
/*
* 資格はフルネームかニックネーム
*/
union authkerb_credswitch(authkerb_namekind akc_namekind){
case AKN_FULLNAME:
authkerb_fullname akc_fullname;
case AKN_NICKNAME:
unsigned long akc_nickname;
};
/*
* タイムスタンプには、1970 年 1 月 1 日の午前 0 時からの秒数を符号化
*/
struct timestamp {
unsigned long seconds; /* 秒 */
unsigned long useconds; /* マイクロ秒 */
};
/*
* ベリファイア:クライアント側
*/
struct authkerb_verf_clnt {
timestamp akv_timestamp; /* 暗号化されたタイムスタンプ */
unsigned long akv_winverf; /* 暗号化されたウィンドウベリファイア */
};
/*
ベリファイア:サーバー側
* クライアントによりサーバーは、タイムスタンプ(暗号化)が与えられた。
* また、サーバーは、クライアントがニックネームを今後の(暗号化されて
* いない)トランザクションで使用するように指定します。
*/
struct authkerb_verf_svr {
timestamp akv_timeverf; /* 暗号化されたベリファイア */
unsigned long akv_nickname; /* クライアントの新しいニックネーム */
};
|