ネットワーク WG
Request for Comments: 1964
分類: スタンダードトラック
J.Linn
OpenVision Technologies
1996年 6月

English

Kerberos バージョン 5 GSS-API メカニズム
(The Kerberos Version 5 GSS-API Mechanism)

このメモの位置付け

本書は、インターネット コミュニティのためのインターネット標準化過程プロトコルについて規定するものです。このプロトコルを改善していくため、さらなる検討や提案が必要です。このプロトコルの標準化については、"Internet Official Protocol Standards" (STD 1) の最新版を参照してください。このメモの配布に制限はありません。

概要

この仕様は、Kerberos バージョン 5 テクノロジー (RFC-1510 に規定 ) を使用する際に、GSSAPI (Generic Security Service Application Program Interface RFC-1508 および RFC-1509 に規定 )を使用しているピアで使うプロトコル、プロシージャ、規約について定義しています。

謝辞

このメモの多くの部分は、Digital Equipment Corporation の John Wray 氏 が執筆した論文、および Marc Horowitz 氏、Ted Ts'o 氏、John Wray 氏による検討、具体化作業、相互運用性テストに基づいてます。Kerberos バージョン 5 コードベースの GSS-API サポートの開発と実現に携わって いただいたこれらの方々に、この場を借りてお礼を申し上げます。

目次

1. トークン形式
1.1. コンテキスト確立トークン
1.1.1. 初回トークン
1.1.2. 応答トークン
1.2. メッセージごとのトークン、およびコンテキスト削除トークン
1.2.1. メッセージごとのトークン - MIC
1.2.1.1. チェックサム
1.2.1.2. シーケンス番号
1.2.2. メッセージごとのトークン - Wrap
1.2.2.1. チェックサム
1.2.2.2. シーケンス番号
1.2.2.3. パディング (パッド)
1.2.3. コンテキスト削除トークン

2. 名前タイプとオブジェクト識別子

2.1. 必須の名前形式
2.1.1. Kerberos プリンシパルの名前形式
2.1.2. ホストベースのサービス名の形式
2.1.3. Kerberos V5 メカニズムのエクスポートされた名前オブジェクト形式
2.2. オプションの名前形式
2.2.1. ユーザーの名前形式
2.2.2. マシン UID 形式
2.2.3. 文字列 UID 形式

3. 信任状管理

4. パラメータの定義

4.1. マイナー ステータス コード
4.1.1. Non-Kerberos-specific codes
4.1.2. Kerberos 固有コード
4.2. 保護品質値
4.2.1. インテグリティアルゴリズム
4.3. バッファ サイズ

5. セキュリティについての考慮事項

6. 参考文献

 

1. トークン形式 English

この節においては、RFC-1508 および RFC-1510 で規定されている Kerberos V5 セキュリティテクノロジーの最上層に実装される GSS-API メカニズムのプロトコル可視的な特性について説明します。ここでは、相互運用性のためのプロトコルの要素を定義しており、RFC-1509 で規定されている言語バインディングには依存しません。

GSS-API ピア間で転送されるトークン (セキュリティ コンテキスト管理とメッセージごとの保護が目的) を定義しています。GSS-API の終端実装と Kerberos KDC 間で交換されるデータ要素は、GSS-API の使用上固有なものではないため、この仕様ではなく RFC-1510 内で定義されています。

この仕様について現在進行中の実験、テスト、および開発をサポートするため、このメモや将来作成される同様の文書で定義される Kerberos V5 GSS-API メカニズムは、仕様が Proposed Standard RFC のレベルに進展するまでは、RFC-1510 の定義どおり、以下のオブジェクト識別子で識別されます。

{iso (1), org 3), dod (5), internet (1), security (5), kerberosv5 (2)}

Proposed Standard RFC のレベルに進行した時点をもって、Kerberos V5GSS-API メカニズムは以下のオブジェクト識別子で識別されます。

{iso (1) member-body (2) United States (840) mit (113554) infosys (1) gssapi (2) krb5 (2)}

1.1. コンテキスト確立トークン English

RFC-1508 の付録 B の規定により、初回のコンテキスト確立トークンは以下に示すフレーム内に格納されます。

InitialContextToken ::=
[APPLICATION 0] IMPLICIT SEQUENCE {

thisMech Mech Type
-- MechType は "Kerberos V5" を表す
-- オブジェクト識別子です。

innerContextToken ANY DEFINED BY thisMech

-- メカニズム固有の内容です。
-- innerContextToken では ASN.1 を使う
-- 必要はありません。

}

初回のコンテキスト トークンの innerContextToken は、2 バイトの token-id (TOK_ID) フィールドが先頭に付いた、Kerberos V5 の KRB_AP_REQ メッセージです。このフィールドには 01 00 という値が入っています。

上記の GSS-API フレームは、コンテキスト確立シーケンス内の初回の トークンだけではなく、KRB_AP_REP、KRB_ERROR、コンテキスト削除トークン、 およびメッセージごとのトークンを含む Kerberos V5 GSS-API が発行する すべてのトークンに適用されます。RFC-1508 では規定されていませんが、これによリ、強化されたエラー チェックを使用できます。Kerberos V5 GSS-API メカニズムのコンテキスト確立トークンの innerContextToken フィールドは、先頭に 2 バイトの TOK_ID フィールドが付いた Kerberos メッセージ (KRB_AP_REQ、KRB_AP_REP、KRB_ERROR のどれか) を含みます。この TOK_ID フィールドには、KRB_AP_REQ メッセージの場合は 01 00、KRB_AP_REP メッセージの場合は 02 00、KRB_ERROR メッセージの場合は 03 00 の値が入っています。

1.1.1. 初回トークン English

関連する KRB_AP_REQ 構文 ( RFC-1510 で規定されている ) を以下に示します。

AP-REQ ::= [APPLICATION 14] SEQUENCE {

pvno [0]
msg-type [1]
ap-options[2]
ticket[3]
authenticator[4]
INTEGER,
INTEGER,
APOptions,
Ticket,
EncryptedData
-- バージョン 5 を示します。
-- KRB_AP_REQ を示します。

}

APOptions ::= BIT STRING {

reserved (0),
use-session-key (1),
mutual-required (2)

}

Ticket ::= [APPLICATION 1] SEQUENCE {

tkt-vno [0]
realm [1]
sname [2]
enc-part [3]
INTEGER,
Realm,
PrincipalName EncryptedData,
-- バージョン 5 を示します。

}

-- チケットの暗号化部分です。
EncTicketPart ::= [APPLICATION 3] SEQUENCE {

flags[0]
key[1]
crealm[2]
cname[3]
transited[4]
authtime[5]
starttime[6]
endtime[7]
renew-till[8]
caddr[9]
authorization-data[10]
TicketFlags,
EncryptionKey,
Realm,
PrincipalName,
TransitedEncoding,
KerberosTime,
KerberosTime OPTIONAL,
KerberosTime,
KerberosTime OPTIONAL,
HostAddresses OPTIONAL,
AuthorizationData OPTIONAL

}

-- 暗号化されていない認証子
Authenticator ::= [APPLICATION 2] SEQUENCE {

authenticator-vno[0]
crealm[1]
cname[2]
cksum[3]
cusec[4]
ctime[5]
subkey[6]
seq-number[7]
authorization-data[8]
INTEGER,
Realm,
PrincipalName,
Checksum OPTIONAL,
INTEGER,
KerberosTime,
EncryptionKey OPTIONAL,
INTEGER OPTIONAL,
AuthorizationData OPTIONAL

}

認証子は、この仕様を満たすためにオプションのシーケンス番号を含んで います。また、チェックサム フィールドは、チャネルバインディング、 サービス フラグ、およびオプションで代理情報を伝送するのに使用されます。チェックサムは、0x8003 (Kerberos プロトコル仕様に現在登録中の値)の タイプと、少なくとも 24 バイト長の値フィールドを持ちます。値フィールドの 長さが 24 バイトを超えるように拡張されるのは、Kerberos で定義されている KRB_CRED メッセージを代理目的のため伝送するオプション機能がサポートされて おり、かつその機能がコンテキスト上でアクティブになっているときに限ります。代理機能がアクティブになっている場合、FORWARDABLE フラグが設定されている TGT は KRB_CRED メッセージ中に入れられて転送されます。

チェックサム値フィールドの形式を以下に示します。

バイト 名前 説明
0..3 Lgth Bnd フィールドのバイト数。
現在は、16 進数値 10 00 00 00 (リトル エンディアン形式で表した 16) を含んでいます。
4..19 Bnd チャネル バインディングの MD5 ハッシュ。
バインディングの すべての非ナル コンポーネントが取り除かれており、宣言どお りの順序になっています。
チャネル バインディング内の整数 フィールドは、MD5 計算のためにリトル エンディアンの順序で表されています。
20..23 Flags context-establishment フラグのビット ベクトルで、値は RFC-1509 (p. 41) での値と一致します。
GSS_C_DELEG_FLAG:
GSS_C_MUTUAL_FLAG:
GSS_C_REPLAY_FLAG:
GSS_C_SEQUENCE_FLAG:
SS_C_CONF_FLAG:
GSS_C_INTEG_FLAG:
1
2
4
8
16
32

結果のビット ベクトルは、バイト 20 〜 23 にリトル エンディアン形式で符号化されます。

24..25 DlgOpt 代理オプション識別子 (=1) [オプション]
26..27 Dlgth Deleg フィールドの長さ [オプション]
28..n Deleg KRB_CRED メッセージ (n = Dlgth + 29) [オプション]

Bnd フィールドの内容の計算時には、以下の詳細事項が適用されます。

(1) 各整数フィールドは、MD5 ハッシュ演算のため、リトル エンディアン バイト順序で 4 バイトに書式化されます。

(2) gss_channel_bindings_struct の gss_buffer_desc 要素内の入力長 フィールドは、すべてハッシュ演算に含まれます。この場合、値がゼロの ものも含まれます。gss_buffer_desc 要素の値要素は参照が解除され、gss_buffer_desc 要素の長さ指定子がゼロでない場合にのみ結果データがハッシュ演算に含まれます。

(3) 呼出側が有効なチャネル バインディング構造体の代わりに値 GSS_C_NO_BINDINGS を渡した場合、Bnd フィールドは 16 のゼロ値のバイトに設定されます。

イニシエータからターゲットに転送される初めての Kerberos V5 GSS-API メカニズム トークン (KRB_AP_REQ トークン) においては、GSS_C_DELEG_FLAG、 GSS_C_MUTUAL_FLAG、GSS_C_REPLAY_FLAG、および GSS_C_SEQUENCE_FLAG 値はそれぞれ、GSS_Init_sec_context() へのイニシエータの対応する要求 フラグと、GSS_Init_sec_context() の呼出側がそのオプションのサービスを利用できるかどうかを示すブール演算インジケータの論理和に設定されます。GSS_Init_sec_context() へのコンテキスト レベルの入力インジケータ フラグが存在しない GSS_C_CONF_FLAG と GSS_C_INTEG_FLAG は、確立されたコンテキスト上でそれぞれのメッセージ ごとの保護サービスが使用できるかどうかを示すように設定されます。

入力ソース アドレス チャネル バインディング値が呼出側から提供され (例えば、入力引数が GSS_C_NO_BINDINGS、または入力構造体内のソース アドレス指定子の値が GSS_C_NULL_ADDRTYPE ではない場合)、コンテキストのピアから受け取ったトークンがアドレス制限を満たしている場合は、呼出側が提供したソース アドレスが、受信したトークン内のものと一致するかどうか Kerberos V5 GSS-API メカニズムの実装を確認することをお勧めします。不一致が検出された場合は、GSS_S_BAD_BINDINGS major_status 値が返されます。注意: この内容をどんな状況でどの程度推奨できるかは、現在検討中です。この内容は、この仕様の将来のバージョンで変更される可能性があることをご了承ください。

1.1.2. 応答トークン English

Kerberos V5 メカニズムに基づいたコンテキスト確立シーケンスは、アプリケーションの GSS_Init_sec_context() 呼出し において mutual_req ビットが設定されていない場合、一方向認証 (イニシエータの KRB_AP_REQ に 対する応答で、ターゲットからイニシエータへ確認や戻りトークンを 送信しない) を実行します。認証が成功したことを示す確認が必要なアプリケーションでは、相互認証を要求する必要があります。相互認証を要求すると KRB_AP_REQ APoptions に mutual-required が示され、認証子 チェックサムのフラグ フィールドに mutual_req が設定されます。そのような要求に対して、コンテキストのターゲットは、KRB_AP_REP または KRB_ERROR のいずれかを含んでいるトークンでイニシエータに 応答し、相互にコンテキストが確立したことを確認します。

関連する KRB_AP_REP 構文を以下に示します。

AP-REP ::= [APPLICATION 15] SEQUENCE {

pvno [0]
msg-type [1]
enc-part [2]
INTEGER,
INTEGER,
EncryptedData
-- Kerberos V5 を表します。
-- KRB_AP_REP を表します。

}

EncAPRepPart ::= [APPLICATION 27] SEQUENCE {

ctime [0]
cusec [1]
subkey [2]
seq-number [3]
KerberosTime,
INTEGER,
EncryptionKey OPTIONAL,
INTEGER OPTIONAL

}

AP-REP の EncAPRepPart 内のオプションの seq-number 要素が含まれます。

KRB_ERROR の構文は以下のとおりです。

KRB-ERROR ::= [APPLICATION 30] SEQUENCE {

pvno[0]
msg-type[1]
ctime[2]
cusec[3]
stime[4]
susec[5]
error-code[6]
crealm[7]
cname[8]
realm[9]
sname[10]
e-text[11]
e-data[12]
INTEGER,
INTEGER,
KerberosTime OPTIONAL,
INTEGER OPTIONAL,
KerberosTime,
INTEGER,
INTEGER,
Realm OPTIONAL,
PrincipalName OPTIONAL,
Realm, -- 正しいレルム PrincipalName, -- 正しい名前 GeneralString OPTIONAL,
OCTET STRING OPTIONAL

}

KRB-ERROR メッセージの error-code フィールドに転送する値は、この仕様ではなく、[RFC-1510] で定義されています。

1.2. メッセージごとのトークン、およびコンテキスト削除トークン English

この節においては、次の 3つのクラスのトークンを定義しています。まず、GSS_GetMIC() (以前の GSS_Sign()) 呼出しで発行され、GSS_VerifyMIC() [以前の GSS_Verify()] 呼出しで消費される "MIC" トークン。次に GSS_Wrap() [以前の GSS_Seal()] 呼出しで発行され、GSS_Unwrap() [以前の GSS_Unseal()] 呼出しで使われる "Wrap" トークン。GSS_Delete_sec_context() 呼出しで発行され、GSS_Process_context_token() 呼出しで使われるコンテキスト 削除トークン。注意: この仕様の後半の GSS-API のメッセージごとのルーチンの説明では、 以前の名前ではなく、新たに推奨された名前を使用しています。

メッセージごとのトークンの生成と処理には、以下に示すような暗号鍵の異形が使用されます。 :

(1) コンテキスト鍵: Kerberos セッション鍵 (または、コンテキスト イニシエータから発行された認証子にサブ鍵が存在する場合はサブ鍵) を直接使用します。
 
(2) 守秘性鍵: 16 進定数 f0f0f0f0f0f0f0f0 との排他的論理和を とることでコンテキスト鍵の変形を形成します。

(3) MD2.5 シード鍵: コンテキスト鍵のバイトを逆転させることで コンテキスト鍵の変形を形成します (オリジナルの鍵が 8 バイトの 連番 {aa, bb, cc, dd, ee, ff, gg, hh} の場合、シード鍵は {hh, gg, ff, ee, dd, cc, bb, aa} になります)。

1.2.1. メッセージごとのトークン - MIC English

GSS_GetMIC() 呼出しにより、保護されているユーザー データから分離されたトークンが生成されます。このトークンは、データを受信したときにそのデータの完全性を検証するのに使用できます。トークンは以下の形式になっています。
バイト番号 名前 説明
0..1 TOK_ID 識別フィールド。
GSS_GetMIC() によって発行されたトークンは、このフィールドに16 進数値 01 01 が入っています。
2..3 SGN_ALG 完全性アルゴリズム インジケータ。
00 00 - DES MAC MD5
01 00 - MD2.5
02 00 - DES MAC
4..7 Filler ff ff ff ff が入っています。
8..15 SND_SEQ シーケンス番号フィールド。
16..23 SGN_CKSUM 「サインが必要なデータ」のチェックサムで、SGN_ALG フィールドに指定されているアルゴリズムに従って計算されます。

GSS-API トークンは、アプリケーションによって、より上位のプロトコル にカプセル化しなければなりません。埋め込み長さフィールドは不要です。

1.2.1.1. チェックサム English

チェックサム計算手順 (すべてのアルゴリズムで共通): チェックサムは、 データ フィールドに対して計算され、プレーンテキストのパケット ヘッダー の最初の 8 バイトによって論理的に追加されます。結果の値は、データが パケット タイプとシグニチャ アルゴリズム識別子フィールドに結合された ものです。

DES MAC MD5 アルゴリズム: チェックサムは、プレーンテキスト データに 対して MD5 [RFC-1321] ハッシュを演算し、その後 16 バイト MD5 の結果に 対して DES-CBC MAC を演算して生成されます。標準の 64 ビット DES-CBC MAC は、[FIPS-PUB-113] に従って、コンテキスト鍵とゼロ IV を使用して演算されます。

MD2.5 アルゴリズム: チェックサムは、ゼロ IV とコンテキスト鍵のバイト を逆転して生成された鍵 [オリジナルの鍵が 8 バイトの連番 {aa, bb, cc, dd, ee, ff, gg, hh} の場合、チェックサム鍵は、16 バイトの ゼロ ブロックを暗号化する最初の DES-CBC によって、{hh, gg, ff, ee, dd, cc, bb, aa} になる] を使用して生成されます。結果の 16 バイト値は、サイ ンが必要なデータに論理的に付加されます。標準の MD5 チェックサムは、結合 されたデータを通して計算され、結果の最初の 8 バイトは SGN_CKSUM フィー ルドに格納されます。注意 1: ここではこのアルゴリズムを、MD5 が生成する 128 ビットの半分を 使用することを示すために、臨時に「MD2.5」と呼んでいます。MD5 のビットの一部分だけを使用するのは、チェックサムに変更を加え既存のメッセージの 後ろにデータを追加することができないようにするためです。注意 2: このアルゴリズムは比較的新しく、他の完全性アルゴリズムと比べて 低い評価しか受けていません。最初に一部分だけを分析したところ、DES MAC MD5 よりもかなり劣っていることがわかりました。

DES-MAC アルゴリズム: 標準の 64 ビット DES-CBC MAC は、コンテキスト鍵と ゼロ IV を使用して、[FIPS-PUB-113] に従ってプレーンテキスト データに 対して演算されます。8 バイトの整数倍になっていないプレーンテキストの データ長を調整するパティング手順は、[FIPS- PUB-113] で定義されています。結果は 8 バイト値で、これは SGN_CKSUM フィールドに格納されます。このアルゴリズムがサポートされていない場合があります。

1.2.1.2. シーケンス番号 English

シーケンス番号フィールド: 8 バイトのプレーンテキストのシーケンス番号 フィールドは、送信側の 4 バイトのシーケンス番号から次のように形成 されます。送信側のシーケンス番号の 4 バイトの名前が s0、s1、s2 および s3 の場合 (重要性の低い順に)、プレーンテキストのシーケンス番号 フィールドは 8 バイトのシーケンス s0、s1、s2、s3、di、di、di、di に なります。ここで di は、方向インジケータです (16 進数の 0 は、 コンテキスト イニシエータが送信側であることを示し、16 進数の FF は、 コンテキスト アクセプタが送信側であることを示します)。その後、 このフィールドは、コンテキスト鍵と、以前に計算された SGN_CKSUM フィー ルドの最初の 8 バイトから生成された IV を使用して DES-CBC で暗号化 されます。GSS_GetMIC() または GSS_Wrap() トークンの送信後、送信側の シーケンス番号には 1 が加算されます。

トークンの受信側は、最初に SGN_CKSUM フィールドを検証します。有効であ れば、シーケンス番号フィールドは解読され、予測したシーケンス番号と 比較されます。シーケンス番号フィールド内の方向インジケータ (事実上 1 ビット) が繰り返されているのは、受信側が解読の成功を検証できるよ うに冗長性を持たせてあるからです。

シーケンス番号の解読の IV としてチェックサムの演算が使用されているた め、別のメッセージのチェックサムとシーケンス番号を結合しようとする動作 があれば、それは検出されます。つまり、方向インジケータが、悪意を持って送り返されたパケットがあれば、それを検出しています。シーケンス番号は、リプレイされたトークンを検出する基準を提供しています。リプレイ検出は、受信したシーケンス番号に保持されている状態情報を使用して 実施できます。この番号は、到達したセキュリティ コンテキストとともに解釈されます。

Kerberos V5 GSS-API メカニズムの実装においては、メッセージごとのリプレイの 対策と順序不整合検出サービスはオプションです。さらに、これらのサービスを提供する Kerberos V5 GSS-API メカニズムは、サービスをコンテ キスト上で無効にする呼出側の要求を引き受ける必要があります。特に、replay_det_req_flag が FALSE で入力された場合、replay_det_state は FALSE で返され、トークンが処理されたときに重複検出の結果として GSS_DUPLICATE_TOKEN と GSS_OLD_TOKEN stati が示されるべきではありません。sequence_req_flag が FALSE で入力された場合、sequence_state は FALSE で返され、トークンが処理されたときに順序不整合検出の結果として GSS_OLD_TOKEN と GSS_UNSEQ_TOKEN stati が示されるべきではありません。

1.2.2. メッセージごとのトークン - Wrap English

GSS_Wrap() 呼出しにより、入力したユーザー データ (オプションで暗号化 される) を関連する完全性検査量とともにカプセル化するトークンが生成 されます。GSS_Wrap() で発行されたトークンは、GSS_GetMIC() で発行された トークンと同一形式の完全性ヘッダーと (ただし、TOK_ID フィールドに値 02 01 が含まれていることを除く)、プレーンテキスト データ (SEAL_ALG = ff ff の場合) または暗号化データ (SEAL_ALG の他のサポート されている値の場合) のいずれかを含んでいる、後続の本体部分で構成されます。現在では、SEAL_ALG = 00 00 だけがサポートされています。これは、データを保護するのに DES-CBC 暗号化方式が使用されていることを意味します。

GSS_Wrap() トークンの形式を以下に示します。

バイト番号 名前 説明
0..1 TOK_ID 識別フィールド。
GSS_Wrap() によって発行されたトークンは、このフィールドに 16 進数の 02 01 の値を含んでいます。
2..3 SGN_ALG チェックサム アルゴリズム インジケータ。
00 00 - DES MAC MD5
01 00 - MD2.5
02 00 - DES MAC
4..5 SEAL_ALG ff ff - なし
00 00 - DES
6..7 Filler ff ff を含みます。
8..15 SND_SEQ 暗号化されたシーケンス番号フィールド。
16..23 SGN_CKSUM プレーンテキストのパッド済みデータのチェックサムで、SGN_ALG フィールドに指定されているアルゴリズムに従って計算されます。
24..last Data 暗号化データ、またはプレーンテキストのパッド済みデータ

GSS-API トークンは、アプリケーションによって、より上位のプロトコルで カプセル化しなければなりません。埋め込み長さフィールドは不要です。

1.2.2.1. チェックサム English

チェックサム計算手順 (すべてのアルゴリズムに共通): チェックサムは、平文のパッド済みデータ フィールドを通して計算され、プレーン テキストのパケット ヘッダーの最初の 8 バイトによって論理的に付加されます。結果のシグニチャは、データをパケット タイプ、プロトコル バージョン、 およびシグニチャ アルゴリズム識別子フィールドにバインドします。

DES MAC MD5 アルゴリズム: チェックサムは、プレーンテキスト データを 通して MD5 ハッシュを演算し、その後 16 バイト MD5 の結果に対して DES-CBC MAC を演算して形成されます。標準の 64 ビット DES-CBC MAC は、 コンテキスト鍵とゼロ IV を使用して [FIPS-PUB-113] に従って演算されます。8 バイトの結果が SGN_CKSUM フィールドに格納されます。

MD2.5 アルゴリズム: チェックサムは、 16 バイトのゼロ ブロックを暗号化 する最初の DES-CBC により、ゼロ IV とコンテキスト鍵のバイトを逆転して 形成された鍵 [オリジナルの鍵が 8 バイトの連番 {aa, bb, cc, dd, ee, ff, gg, hh} の場合、チェックサム鍵は {hh, gg, ff, ee, dd, cc, bb, aa} になる] を使用して形成されます。結果の 16 バイト値は、「サインが必要な データ」に論理的に付加されます。標準の MD5 チェックサムは、結合されたデータに対して計算され、結果の最初の 8 バイトは SGN_CKSUM フィールドに格納されます。

DES-MAC アルゴリズム: 標準の 64 ビット DES-CBC MAC は、コンテキスト 鍵とゼロ IV を使用して、[FIPS-PUB-113] に従ってプレーンテキストのパッド済みデータに対して演算されます。プレーンテキストのパッド済みデータは、すでに 8 バイトの整数倍になっていることが保証されているため、MAC 演算を実施するのにパッドする必要はありません。結果は 8 バイト値で、これは SGN_CKSUM フィールドに格納されます。このアルゴリズムは、サポートされていない場合もあります。

1.2.2.2. シーケンス番号 English

シーケンス番号フィールド: 8 バイトのプレーンテキストのシーケンス番号 フィールドは、送信側の 4 バイトのシーケンス番号から次のように形成され ます。送信側のシーケンス番号の 4 バイトの名前が s0、s1、s2 および s3 の場合 (重要性の低い順に)、プレーンテキストのシーケンス番号フィールドは 8 バイトのシーケンス s0、s1、s2、s3、di、di、di、di になります。ここで di は、方向インジケータです (16 進数の 0 は、コンテキスト イニシエータ が送信側であることを示し、16 進数の FF は、コンテキスト アクセプタが 送信側であることを示します)。

その後、このフィールドは、以前に計算された SGN_CKSUM フィールドの最初 の 8 バイトで形成されたコンテキスト鍵と IV を使用して DES-CBC で暗号 化されます。

GSS_GetMIC() または GSS_Wrap() トークンの送信後、送信側のシーケンス番号 には 1 が加算されます。

1.2.2.3. パディング (パッド) English

データ パディング: 暗号化、シグニチャ計算、またはそのいずれかの前に、平文のデータは 1 〜 8 バイトが追加することにより、次に大きい 8 バイトの倍数にパッドされます。これらの各バイトの値が、パッド バイトの合計 数になります。例えば、あるデータの長さが 20 バイトの場合、4 バイトがパッ ドされます。そして、各バイトは 16 進数値の 04 を含みます。8 バイトのラン ダム コンファウンダ (混乱要素) がデータの前に付加され、シグニチャはパッド された結果プレーンテキストに対して計算されます。

パディング後、データは SEAL_ALG フィールドに指定されているアルゴリズム に従って暗号化されます。SEAL_ALG=DES の場合は (現在サポートしている 唯一の非ナル アルゴリズム)、データはゼロ IV の DES-CBC を使用して 暗号化されます。使用される鍵は、確立されたコンテキスト鍵から、コンテキスト鍵と 16 進定数 f0f0f0f0f0f0f0f0 の排他的論理和によって取り出されます。

1.2.3. コンテキスト削除トークン English

GSS_Delete_sec_context() によって発行されたトークンは、GSS_GetMIC() によって発行されたトークンのパケット形式に基づいています。
コンテキスト削除トークンの形式は以下のとおりです。:
 
バイト番号 名前 説明
0..1 TOK_ID 識別子フィールド。
GSS_Delete_sec_context() によって発行されたトークンは、このフィールドに16 進数値 01 02 を含んでいます。
2..3 SGN_ALG 完全性アルゴリズム インジケータ。
00 00 - DES MAC MD5
01 00 - MD2.5
02 00 - DES MAC
4..7 Filler ff ff ff ff を含んでいます。
8..15 SND_SEQ シーケンス番号フィールド。
16..23 SGN_CKSUM 「サインが必要なデータ」のチェックサムで、SGN_ALG フィールドに指定されているアルゴリズムに従って計算されます。

SGN_ALG と SND_SEQ は、GSS_GetMIC() によって発行されたトークンで計算されます。SGN_CKSUM は、GSS_GetMIC() によって発行されたトークンで計算されます。ただし、「サインが必要なデータ」のユーザデータ コンポーネントは、ゼロ長文字列になります。

 

2. 名前タイプとオブジェクト識別子 English

この節においては、Kerberos V5 GSS-API メカニズムの GSS_Import_name() 呼出し の入力として渡される名前タイプと、それに関連付けられている識別子の値に ついて説明します。これは、移植性をサポートするためのインターフェイス要素を定義していて、RFC-1509 で規定されている C 言語パインディングの使用を想定しています。名前タイプ識別子の OID 値の指定に加え、シンボリック名が含まれています。呼出し側の利便性を高めたい場合は、シンボリック名を使用することをお勧めします。Kerberos V5 GSS-API メカニズムのすべての実装が、このリストのすべての名前タイプをサポートしている必要はありません。また、このリストには、今後名前形式が追加されていきます。さらに、いくつかの名前タイプ、またはすべての名前タイプは、メカニズム非依存の他の仕様に移行される可能性があります。この仕様における名前タイプの説明は、 Kerberos V5 メカニズムの実装だけがサポートしているタイプを示すことを目的としているのではありません。特に、シンボリック名文字列内の文字列 "_KRB5_" の説明は、他の文書との 競合を避けるために名前文字列の明確な登録方法を指定しているのであって、名前タイプの使用や適用性を制限しようとしているのではありません。

GSS-API の実装方法がより明確になるように、この節ではいくつかの名前形式と、これらの形式を既存の Kerberos テクノロジーでサポートする方法について説明しています。これらの説明は、Kerberos メカニズムや他のテクノロジーをベースにしているメカニズムの、名前形式のサポートの代替実装戦略を排除することを目的としているのではありません。ただし、アプリケーションの移植性を強化するには、使用しているメカニズムがKerberos V5 に依存しない場合でも、可能な限り、この節で定義されている名前形式をサポートすることをお勧めします。

2.1. 必須の名前形式 English

この節では、Kerberos V5 GSS-API メカニズムに従属的なすべての実装で サポートすべき名前形式について説明します。

2.1.1. Kerberos プリンシパルの名前形式 English

この名前形式は、オブジェクト識別子 {iso(1) member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) krb5(2) krb5_name(1)} で表されます。このタイプの推奨シンボリック名は "GSS_KRB5_NT_PRINCIPAL_NAME" です。

この名前タイプは、Kerberos 名の単一文字表記に対応します (MIT Kerberos V5 の実装では、これらの名前はkrb5_parse_name() 関数を使って解析できます)。この名前表現に含まれている要素について、文字列の先頭から順に以下で説明します。

(1) 1 つまたは複数のプリンシパル名コンポーネント: 2 つ以上のプリンシパル名コンポーネントが含まれている場合は、コンポーネントは `/` で区切られます。
また、以下の制約と特別な検討事項に従って、プリンシパル名コンポーネントに任意の数のオクテットを含むことができます。
(1a) 名前コンポーネント内で文字 `@` または`/` を使用する 場合は、その直前に引用文字 `\` を付けて、それらがコンポーネント区切り記号やレルム区切り記号として解釈されないようにしなければなりません。

(1b) ASCII の改行、タブ、バックスペース、およびナル文字は、 コンポーネント内で直接使用することも、それぞれ `\n`、`\t`、`\b`、`\0` で表すこともできます。

(1c) 引用文字 `\` を、上記 (1a) および (1b) で説明している コンテキスト以外で使用すると、その直後の文字は文字通りに 解釈されます。
特別な例としては、引用文字を 2 つ続ける (`\\`) ことで 1 つの引用文字を表せます。

(1d) 引用文字 `\` をコンポーネントの最後の文字として使用する ことはできません。

(2) 文字 `@` は任意で、直後にレルム名が続くことを表します。レルム名が含まれていない場合は、ローカルのレルム名が想定されます。レルム名には、`/`、`:`、およびナル文字は使用できません。`@`、 改行、タブ、バックスペース文字は、上記の (1a)、(1b)、(1c) の 表記方法に従って使用できます。

2.1.2. ホストベースのサービス名の形式 English

この名前形式は、GSS-API バージョン 2 のメカニズム非依存 GSS-API レベルで組み込まれました。この項では、Kerberos V5 GSS-API メカニズム レベルでこれまでに作成されたオブジェクト識別子とシンボリック名割り当てをそのまま使用し、メカニズム非依存レベルに進展したときにその定義を採用します。 名前形式は、オブジェクト識別子 {iso(1) member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) generic(1) service_name(4)} で表されます。このタイプの以前の推奨シンボリック名は "GSS_KRB5_NT_HOSTBASED_SERVICE_NAME" で、現在の推奨シンボリック名は "GSS_C_NT_HOSTBASED_SERVICE" です。

この名前タイプは、ホスト コンピュータに関連付けられたサービスを表すために使用します。この名前形式は、以下のように、"service"と "hostname" の 2 つの要素で構成されています。

service@hostname

このタイプの名前への照会が解決すると、DNS 参照を試行し、返された 完全なドメイン名を使用して "hostname" が正準化されます。DNS 参照が失敗した場合は、指定した "hostname" を使用して正準化されます。また、正準化処理によってホスト名は小文字に変換されます。

"hostname" は省略することもできます。"@" 区切り記号が含まれていない場合、名前全体はサービス指定子として解釈され、"hostname" はデフォルトでローカル ホストの正準化された名前になります。

"service" の値は、IANA とともに登録されます。

2.1.3. Kerberos V5 メカニズムのエクスポートされた名前オブジェクト形式 English

この名前形式は、GSS-V1 の実装ではサポートされている必要はあり ませんが、GSS-API バージョン 2 で計画されている GSS_Export_name() 呼出しとともに使用する場合には必要です。この名前形式の使用は、 GSS-API バージョン 2 のメカニズム非依存レベルで定義される "GSS-API Exported Name Object" OID 値で表されます。

この名前タイプは、フレーム化構造が GSS-API バージョン 2 のメカニズム 非依存レベルで定義される自己記述オブジェクトを表します。
Kerberos V5 メカニズムで生成された場合、エクスポート可能な名前の Mechanism OID は、Kerberos V5 メカニズムの Mechanism OID になります。エクスポート可能な 名前の名前要素は、「Kerberos プリンシパルの名前形式」で定義されている 構造の連続した文字列になります。

比較のための正規符号化を行う場合には、エクスポート操作で以下のことが 制限されます。

(1) プリンシパルのコンポーネント、またはレルム名内の文字 `@`、 `/`、`\` には、直前に `\` が付けられます。

(2) プリンシパルのコンポーネント、またはレルム名での、ナル、 バックスペース、タブ、または改行文字は、それぞれ `\0`、`\b`、 `\t`、`\n` で表されます。

(3) 上記 (1) と (2) に従う場合を除いて、エクスポートされた 名前内で引用文字 `\` を使用してはいけません。

2.2. オプションの名前形式 English

この節では、Kerberos V5 GSS-API メカニズムの実装で、オプションとしてサポートされる追加の名前形式について説明します。ここで引用している 名前形式のいくつかは、UNIX(tm) オペレーティング システム プラットフォームから取り出したものです。リストされている形式のいくつかは、非 UNIX プラットフォームでは不適切で、それらのプラットフォームに 対応する追加形式の定義も不適切です。また、GSS-API にはない OS 固有の機能は、これらの形式間で変換が行えるように存在し続け、これらの形式をサポートしている GSS-API の実装は OS 固有の機能の最上位に レイヤされます。このサポートは、アプリケーションの利便性のために GSS-API の実装に含まれています。

2.2.1. ユーザーの名前形式 English

名前形式は、オブジェクト識別子 {iso(1) member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) generic(1) user_name(1)} で表されます。このタイプの推奨シンボリック名は "GSS_KRB5_NT_USER_NAME" です。

この名前タイプは、ローカル システム上の名前の付けられているユーザー を示すのに使用します。この名前形式の解釈方法は OS 固有で、名前形式は以下のように構成されています。

username

Kerberos V5 テクノロジーに基づいて実装されている GSS_Import_name() は、ユーザーのプリンシパル名がローカル オペレーティング システム名と 同じであると想定し、名前の後ろに "@" 記号とローカル レルムの名前を 追加して、この形式の名前を処理します。

2.2.2. マシン UID 形式 English

この名前形式は、オブジェクト識別子 {iso(1) member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) generic(1) machine_uid_name(2)} で表されます。このタイプの推奨シンボリック名は "GSS_KRB5_NT_MACHINE_UID_NAME" です。

この名前タイプは、ローカル システム上のユーザーに対応する、数値の ユーザー識別子を示すのに使用します。この名前形式の解釈方法は OS 固有です。このタイプの名前を表す gss_buffer_desc は、ホスト バイト順序で表した、ローカルで有効な uid_t を含んでいる必要があります。GSS_Import_name() 処理は、この uid を username に分解します。その後、username は、「ユーザーの名前形式」で説明しているように扱われます。

2.2.3. 文字列 UID 形式 English

この名前形式は、オブジェクト識別子 {iso(1) member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) generic(1) string_uid_name(3)} で表されます。このタイプの推奨シンボリック名は "GSS_KRB5_NT_STRING_UID_NAME" です。

この名前タイプは、ローカル システム上のユーザーの、数値のユーザー識別子を表す数字を示すのに使用します。この名前形式の解釈方法は OS 固有です。この名前タイプは、uid_t を表す文字列がバッファに含まれていることを除けばマシン UID 形式と同じです。

 

3. 信任状管理 English

Kerberos V5 プロトコルは、セキュリティ コンテキストを開始/受領する のに異なる信任状を使用します (GSSAPI に従って)。通常のクライアントは、 チケット-グランティング チケット (TGT) と、関連付けられている セッション鍵をログイン時に受領します。TGT とそれに対応するセッション 鍵は、セキュリティ コンテキストを開始するのに適した信任状を形成します。チケット-グランティング チケット、それのセッション鍵、およびその他の あらゆるペア (チケットと鍵の) は、チケット-グランティング チケットを 使用して取得でき、通常、Kerberos V5 信任状キャッシュ (チケット ファイルとも呼ばれる) に格納されます。

特定のアプリケーション サービスのチケットを封印するのに Kerveros サーバーが使用する暗号化鍵は、セキュリティ コンテキストの受領に適した信任状を形成します。これらのサービス鍵は、通常、Kerberos V5 鍵テーブルまたは srvtab ファイルに格納されます。これらのサービス鍵は、信任状を受領するのに使用するほか、サービス プリンシパルの開始信任状を取得するのにも使用されます。

Kerberos V5 メカニズムの信任状の処理には、2 つのタイプの信任状のどちらか一方、またはその両方への参照を含むことができます。実装されている Kerberos V5 メカニズムが、適切な Kerberos V5 の信任状キャッシュまたは鍵テーブルを見つける方法は、個別の問題です。

ただし、Kerberos V5 メカニズムが、信任状キャッシュでは取得できないサービス プリンシパルの開始信任状を取得しようとして、Kerberos V5 の 鍵テーブルでそのサービス プリンシパルの鍵が取得できる場合、メカニズム はサービス鍵を使用してそのサービスの開始信任状を取得する必要が あります。これは、Kerberos 鍵配布センター (KDC) にチケット-グランティング チケットを要求して、サービス鍵を使用して KDC の応答を解読して実行します。

 

4. パラメータの定義 English

この節では、Kerberos V5 GSS-API メカニズムで使用するパラメータに ついて定義します。移植性をサポートするためのインターフェイス要素を定義し、RFC-1509 において規定されている C 言語バインディングの使用を想定しています。

4.1. マイナー ステータス コード English

この節では、Kerberos V5 GSS-API メカニズムが返す minor_status 値の推奨一般シンボリック名について説明します。これらの定義を使用することで、この仕様で定義している異なる実装メカニズム間での アプリケーションの移植性を、非依存環境の実装で強化できます (いかなる場合も、GSS_Display_status() を実装することで、呼出側は minor_status インジケータをテキスト表現に変換できます)。各実装では、インクルード ファイルの使用や他の方法によって、これらのシンボリック名を、 minor_status 値を表すために特定の GSS-API 実装が使用する具体的な値に 変換できるようにする必要があります。

このリストは、今後増えていき、特殊な実装に固有な minor_status コード の必要性も出てくるはずです。ただし、コードが再移植可能な状態を正確に表現する場合は、独立した実装定義のコードを使用するのではなく、この節で説明しているメカニズム全体に渡って定義されている minor_status 値を実装が返すようにすることを勧めます。

4.1.1. Non-Kerberos-specific codes English

GSS_KRB5_S_G_BAD_SERVICE_NAME
/* "SERVICE-NAME 名文字列に @ がありません。" */
GSS_KRB5_S_G_BAD_STRING_UID
/* "STRING-UID-NAME に数値が含まれていません。" */
GSS_KRB5_S_G_NOUSER
/* "UID を username に分解できません。" */
GSS_KRB5_S_G_VALIDATE_FAILED
/* "検証エラー" */
GSS_KRB5_S_G_BUFFER_ALLOC
/* "gss_buffer_t データを割り当てられません。" */
GSS_KRB5_S_G_BAD_MSG_CTX
/* "メッセージ コンテキストが不正です。" */
GSS_KRB5_S_G_WRONG_SIZE
/* "バッファ サイズが間違っています。" */
GSS_KRB5_S_G_BAD_USAGE
/* "信任状の使用タイプが不明です。" */
GSS_KRB5_S_G_UNKNOWN_QOP
/* "不明な保護品質を指定しました。" */

4.1.2. Kerberos 固有コード English

GSS_KRB5_S_KG_CCACHE_NOMATCH
/* "信任状キャッシュ内のプリンシパルが、希望する名前と一致しません。" */
GSS_KRB5_S_KG_KEYTAB_NOMATCH
/* "keytab 内に、希望する名前と一致するプリンシパルがありません。" */
GSS_KRB5_S_KG_TGT_MISSING
/* "信任状キャッシュに TGT がありません。" */
GSS_KRB5_S_KG_NO_SUBKEY
/* "認証子にサブ鍵がありません。" */
GSS_KRB5_S_KG_CONTEXT_ESTABLISHED
/* "コンテキストはすでに完全に確立されています。" */
GSS_KRB5_S_KG_BAD_SIGN_TYPE
/* "トークンに不明なシグニチャ タイプがあります。" */
GSS_KRB5_S_KG_BAD_LENGTH
/* "トークンに不正なフィールド長があります。" */
GSS_KRB5_S_KG_CTX_INCOMPLETE
/* "不完全なセキュリティ コンテキストを使おうとしました。" */

4.2. 保護品質値 English

この節においては、代替の完全性アルゴリズムと守秘性アルゴリズムを選択する ための保護品質 (QOP) 値を定義します。これらは、Kerberos V5 GSS-API メカニズムで GSS_Wrap() および GSS_GetMIC() ルーチンへの入力値として 使用されます。この仕様の将来のバージョンでは、QOP 値が追加される 予定です。指定した 完全性値と守秘性値の排他的論理和をとることで、 完全性 QOP と守秘性 QOP の両方が単一パラメータで選択されるように、重ならないビット位置が採用されます。

4.2.1. インテグリティ アルゴリズム English

Kerberos V5 GSS-API メカニズムでは、現在以下の保護品質 (QOP) 値が 定義されていて、これらは代替の完全性検査アルゴリズムを選択するのに 使用されます。
GSS_KRB5_INTEG_C_QOP_MD5 (数値: 1)
/* 部分的な MD5 ("MD2.5") を使用したプレーンテキストの完全性検査 */
 
GSS_KRB5_INTEG_C_QOP_DES_MD5 (数値: 2)
/* MD5 の DES MAC を使用したプレーンテキストの完全性検査 */
 
GSS_KRB5_INTEG_C_QOP_DES_MAC (数値: 3)
/* DES MAC を使用したプレーンテキストの完全性検査 */

4.2.2. 守秘性アルゴリズム English

Kerberos V5 GSS-API メカニズムでは、現在以下の守秘性 QOP 値だけが定義されています。
GSS_KRB5_CONF_C_QOP_DES (数値: 0)
/* DES による守秘性検査 */

注意: 守秘性 QOP は、守秘性サービスを提供することができる GSS-API 呼出しでだけ指定してください。将来、異なるアルゴリズムを表すゼロ以外の守秘性 QOP 値が定義された場合は、GSS_GetMIC() および GSS_VerifyMIC()の実装が値を返す前に、これらの値を含んでいるビット位置をクリアしておく必要があります。

4.3. バッファサイズ English

この仕様のすべての実装は、GSS_GetMIC()、GSS_VerifyMIC()、および GSS_Wrap() への入力として最低 16 KB のバッファを許容できなければ なりません。また、GSS_Wrap() によって生成される output_token を 許容できなければなりません。これには、GSS_Unwrap() への入力として16 KB の入力バッファが必要です。必須ではありませんが、より大きいバッファ サイズをサポートすることを推奨します。


5. セキュリティについての考慮事項 English

セキュリティの論点について、このメモ全体を通じて検討されています。

 

6. 参考文献

[RFC-1321]: Rivest, R.,
「MD5 メッセージダイジェストアルゴリズム(The MD5 Message-Digest Algorithm)」,
RFC 1321, 1992年 4月.

[RFC-1508]: Linn, J.,
"Generic Security Service Application Program Interface",
RFC 1508, 1993年 9月.

[RFC-1509]: Wray, J.,
"Generic Security Service Application Program Interface: C-bindings",
RFC 1509, 1993年 9月.

[RFC-1510]: Kohl, J., and C. Neuman,
「Kerberos ネットワーク認証サービス v5(The Kerberos Network Authentication Service (V5))」,
RFC 1510, 1993年 9月.

[FIPS-PUB-113]: National Bureau of Standards, Federal Information Processing Standard 113, "Computer Data Authentication", 1985年 5月.

 

著者のアドレス

John Linn
OpenVision Technologies
One Main St.
Cambridge, MA 02142 USA

電話番号: +1 617.374.2245
EMail: John.Linn@ov.com


Copyright (C) The Internet Society (1996). All Rights Reserved.