キータブ

キータブ (keytab) バイナリ形式は、標準形式ではありません。書式は、発展していて、継続してます。しかしながら、それは、Heimdal、MIT、Sun の Java ktab を含むいくつかの Kerberos 実装によって理解され、Windows から ktpass.exe ユーティリティによって作成されます。それで、Kerberos キーを格納するための事実上の標準形式としての地位を確立しました。

次の C のような構造体の定義は、MIT キータブファイル形式を説明しています。すべての値は、ネットワークバイト順です。すべてのテキストは、ASCII です。

keytab {
uint16_t file_format_version; # 0x502
keytab_entry entries[*];
};

keytab_entry {
int32_t size;
uint16_t num_components; # バージョンが 0x501 であるなら、1 を引く
counted_octet_string realm;
counted_octet_string components[num_components];
uint32_t name_type; # バージョンが 0x501 であるなら、存在しない
uint32_t timestamp;
uint8_t vno8;
keyblock key;
uint32_t vno; # entry に >= 4 バイト残る場合のみ存在する
uint32_t flags; # entry に >= 4 バイト残る場合のみ存在する
};

counted_octet_string {
uint16_t length;
uint8_t data[length];
};

keyblock {
uint16_t type;
counted_octet_string;
};

すべての数値は、ネットワークバイト順 (ビッグエンディアン) 形式で格納されます。

キータブファイル形式は、この文書が 0x502 で書かれた時点で 16 ビットの file_format_version で始まります。より古いキータブの形式は、この文書の終りに記述されています。

file_format_version は、エントリに続くバイトの数を示す 32 ビットのサイズを前に付けられた、keytab_entry 構造体の配列に直ちに続きます。サイズが署名されるように評価されるべきであることに注意してください。これは、エントリが (例えば、削除されました) 実際に空であり、 (もちろん正の値である) 負の値が、次の keytab_entry へのオフセットである負の値であることを示す負の値であるためです。これらのサイズの値単独に基づいた、すべてのキータブファイルを横断することができます。

構成要素の配列の counted_octet_string 構成要素の数を示す 16 ビットの num_components フィールドがサイズに続きます。

プリンシパルのレルム (realm) を表わす counted_octet_string が num_components フィールドに続きます。

counted_octet_string は、単に 16 のビットの長さを前に付けられたバイトの配列です。レルムと名前の構成要素については、counted_octet_string バイトは、 0 の終了指示子のない ASCII エンコードされたテキストです。

レルムに続くことは、プリンシパルの名前を表わす構成要素の配列です。これらの構成要素のテキストは、典型的な SPN 表現を構築するためにスラッシュを付けて結合されます。例えば、サービスプリンシパル HTTP/www.foo.net@FOO.NET は、 'www.foo.net' が続く名前構成要素 'HTTP' から成るでしょう。

構成要素の配列に続くことは、32 ビットの name_type (例えば、1 は、 KRB5_NT_PRINCIPAL、2 は、KRB5_NT_SRV_INST、5 は、KRB5_NT_UID、など) です。実際上、name_type は、ほとんど確かに KRB5_NT_PRINCIPAL を意味する 1 です。

32 ビットのタイムスタンプは、キーがそのプリンシパルのために確立された時間を示します。値は、1970 年 1 月 1 日以来の秒の数を表わします。

8 ビットの vno8 フィールドは、キーのバージョン番号です。この値は、それが存在するなら、32 ビットの vno フィールドによって上書きされます。 vno8 フィールドは、32 ビットのプロトコル kvno フィールドの下位 8 ビットで満たされます。

keyblock 構造体は、暗号化タイプを示す 16 ビットの値から成り、キーを含んでいる counted_octet_string です。暗号化タイプは、Kerberos 標準 (例えば、3、は descbc-md5 で、23 は、 arcfour-hmac-md5 です、など) と同じです。

keytab_entry 構造体の最後のフィールドは、オプションです。 keytab_entry のサイズが少なくとも 4 バイトが残っていることを示すなら、キーバージョン番号を表わす 32 ビットの値は、存在します。この値は、keyblock に先行する 8 ビットの vno8 値に優先します。

0x501 の file_format_version があるより古いキータブは、次の 3 つの方法で異なります:

•

すべての整数は、ホストバイト順です [1]。

•

num_components フィールドは、あまりにも大きな 1 です (すなわち、デコードの後に、1 減少されます)。

•

32 ビットの name_type フィールドは、存在しません。

[1] file_format_version フィールドは、それぞれメジャーとマイナバージョン番号を表わす 2 つの分離された 8 ビットの量として実際に扱われるべきです。

Heimdal データベースダンプファイル

Heimdal 0.6.3 の時点での Heimdal テキストダンプファイルの形式は、次の通りです:

ダンプファイルの各行は、データベースの 1 つのエントリです。

行の各フィールドは、空白を \ でクォートすることができ、\ は、\ によってクォートできるところで、空白を含んでいるプリンシパルから成るフィールドを例外として、1 つ以上の空白によって分離されます。

フィールドとそれらのタイプは、次の通りです:

Quoted princial (quote character is ) [string]
Keys [keys]
Created by [event]
Modified by [event optional]
Valid start time [time optional]
Valid end time [time optional]
Password end valid time [time optional]
Max lifetime of ticket [time optional]
Max renew time of ticket [integer optional]
Flags [hdb flags]
Generation number [generation optional]
Extensions [extentions optional]

これらに続くフィールドは、静かに無視されます。

すべてのオプションのフィールドは、それらが解析に失敗する (か、または '-' のオプションのフィールドマーカを含む、w/o クォート) なら、スキップされます。

使用例:

fred@CODE.COM 27:1:16:e8b4c8fc7e60b9e641dcf4cff3f08a701d982a2f89ba373733d26ca59ba6c789666f6b8bfcf169412bb1e5dceb9b33cda29f3412:-:1:3:4498a933881178c744f4232172dcd774c64e81fa6d05ecdf643a7e390624a0ebf3c7407a:-:1:2:b01934b13eb795d76f3a80717d469639b4da0cfb644161340ef44fdeb375e54d684dbb85:-:1:1:ea8e16d8078bf60c781da90f508d4deccba70595258b9d31888d33987cd31af0c9cced2e:- 20020415130120:admin@CODE.COM 20041221112428:fred@CODE.COM - - - 86400 604800 126 20020415130120:793707:28 -

タイプのエンドコードは、次の通りです:

•

キー

kvno:[masterkvno:keytype:keydata:salt]{zero or more separated by :}

kvno は、キーのバージョン番号です。

keydata は、16 進数でエンコードされます。

masterkvno は、データベースのマスタキーの kvno です。このフィールドが空であるなら、kadmin ロードとマージ操作は、キーデータがあるるなら、マスタキーがあるキーデータを暗号化します。そうでなければ、キーデータは、そのままインポートされます。

salt (塩) は、'-' としてエンコード化されます (デフォルトの salt はなし) または

salt-type /
salt-type / 'string'
salt-type / hex-encoded-data

keytype は、プロトコル enctype 番号です。値については、include/krb5_asn1.h の enum ENCTYPE を参照してください。

使用例:

27:1:16:e8b4c8fc7e60b9e641dcf4cff3f08a701d982a2f89ba373733d26ca59ba6c789666f6b8bfcf169412bb1e5dceb9b33cda29f3412:-:1:3:4498a933881178c744f4232172dcd774c64e81fa6d05ecdf643a7e390624a0ebf3c7407a:-:1:2:b01934b13eb795d76f3a80717d469639b4da0cfb644161340ef44fdeb375e54d684dbb85:-:1:1:ea8e16d8078bf60c781da90f508d4deccba70595258b9d31888d33987cd31af0c9cced2e:-

kvno=27,{key: masterkvno=1,keytype=des3-cbc-sha1,keydata=..., default salt}...

•

時間

時間の形式は、次の通りです: strftime 形式 '%Y%m%d%k%M%S' に対応する、YYYYmmddHHMMSS

時間は、UTC で表現されます。

時間 0 が使用されるとき、時間は、省略可能です (- を使用)。

使用例:

20041221112428

•

イベント

time:principal

時間は、書式時間で与えられます。

プリンシパルは、文字列です。クォートしなければ、Heimdal の初期のバージョンで動作しないかもしれません。

使用例:

20041221112428:bloggs@CODE.COM

•

hdb フラグ

HDB フラグの整数エンコードは、lib/hdb/hdb.asn1 の HDBFlags を参照してください。整数の各ビットは、仕様書のビットと同じです。

•

生成:

time:usec:gen

usec は、マイクロ秒です、整数。 gen は、生成番号です、整数。

生成は、('-' を使用して) デフォルトとするか、空の文字列にすることができます。

•

拡張:

first-hex-encoded-HDB-Extension[:second-...]

HDB 拡張は、エンコードされ、DER は、lib/hdb/hdb.asn1 の HDB-Extension をエンコードします。消費者 HDB 拡張は、ASN.1 データの内容は、未知であるかもしれないからといって、未知のエントリを保存される必要があることを承知しているべきです。エントリが使用されるなら、エントリが理解されていなければならない KDC に表示するためのデータの重大なフラグがあります。