|
ネットワーク WG Request for Comments： 1964 分類： スタンダードトラック |
J.Linn OpenVision Technologies 1996年 6月 |
本書は、 インターネットコミュニティのためのインターネット標準化過程プロトコルについて規定するものです。 このプロトコルを改善していくため、さらなる検討や提案が必要です。 このプロトコルの標準化については、"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サポートの開発と実現に携わっていただいたこれらの方々に、 この場を借りてお礼を申し上げます。
この節においては、 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)}
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の値が入っています。
関連するKRB_AP_REQ構文(RFC-1510で規定されている)を以下に示します。
AP-REQ ::= [APPLICATION 14] SEQUENCE {
pvno [0] INTEGER, -- バージョン 5 を示します。
msg-type [1] INTEGER, -- KRB_AP_REQ を示します。
ap-options[2] APOptions,
ticket[3] Ticket,
authenticator[4] EncryptedData
}
APOptions ::= BIT STRING {
reserved (0),
use-session-key (1),
mutual-required (2)
}
Ticket ::= [APPLICATION 1] SEQUENCE {
tkt-vno [0] INTEGER, -- バージョン 5 を示します。
realm [1] Realm,
sname [2] PrincipalName,
enc-part [3] EncryptedData,
}
-- チケットの暗号化部分です。
EncTicketPart ::= [APPLICATION 3] SEQUENCE {
flags[0] TicketFlags,
key[1] EncryptionKey,
crealm[2] Realm,
cname[3] PrincipalName,
transited[4] TransitedEncoding,
authtime[5] KerberosTime,
starttime[6] KerberosTime OPTIONAL,
endtime[7] KerberosTime,
renew-till[8] KerberosTime OPTIONAL,
caddr[9] HostAddresses OPTIONAL,
authorization-data[10] AuthorizationData OPTIONAL
}
-- 暗号化されていない認証子
Authenticator ::= [APPLICATION 2] SEQUENCE {
authenticator-vno[0] INTEGER,
crealm[1] Realm,
cname[2] PrincipalName,
cksum[3] Checksum OPTIONAL,
cusec[4] INTEGER,
ctime[5] KerberosTime,
subkey[6] EncryptionKey OPTIONAL,
seq-number[7] INTEGER OPTIONAL,
authorization-data[8] 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)での値と一致します。
|
||||||||||||
| 24..25 | DlgOpt | 代理オプション識別子(=1)[オプション] | ||||||||||||
| 26..27 | Dlgth | Delegフィールドの長さ[オプション] | ||||||||||||
| 28..n | Deleg | KRB_CREDメッセージ(n = Dlgth + 29)[オプション] |
Bndフィールドの内容の計算時には、以下の詳細事項が適用されます。
イニシエータからターゲットに転送される初めての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値が返されます。 注意: この内容をどんな状況でどの程度推奨できるかは、現在検討中です。 この内容は、 この仕様の将来のバージョンで変更される可能性があることをご了承ください。
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] INTEGER, -- Kerberos V5 を表します。
msg-type [1] INTEGER, -- KRB_AP_REP を表します。
enc-part [2] EncryptedData
}
EncAPRepPart ::= [APPLICATION 27] SEQUENCE {
ctime [0] KerberosTime,
cusec [1] INTEGER,
subkey [2] EncryptionKey OPTIONAL,
seq-number [3] INTEGER OPTIONAL
}
AP-REPのEncAPRepPart内のオプションのseq-number要素が含まれます。
KRB_ERRORの構文は以下のとおりです。
KRB-ERROR ::= [APPLICATION 30] SEQUENCE {
pvno[0] INTEGER,
msg-type[1] INTEGER,
ctime[2] KerberosTime OPTIONAL,
cusec[3] INTEGER OPTIONAL,
stime[4] KerberosTime,
susec[5] INTEGER,
error-code[6] INTEGER,
crealm[7] Realm OPTIONAL,
cname[8] PrincipalName OPTIONAL,
realm[9] Realm, -- 正しいレルム
sname[10] PrincipalName, -- 正しい名前
e-text[11] GeneralString OPTIONAL,
e-data[12] OCTET STRING OPTIONAL
}
KRB-ERRORメッセージのerror-codeフィールドに転送する値は、 この仕様ではなく、 [RFC-1510]で定義されています。
この節においては、次の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のメッセージごとのルーチンの説明では、 以前の名前ではなく、新たに推奨された名前を使用しています。
メッセージごとのトークンの生成と処理には、 以下に示すような暗号鍵の異形が使用されます。：
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トークンは、アプリケーションによって、 より上位のプロトコルにカプセル化しなければなりません。 埋め込み長さフィールドは不要です。
チェックサム計算手順 (すべてのアルゴリズムで共通): チェックサムは、 データフィールドに対して計算され、 プレーンテキストのパケットヘッダーの最初の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フィールドに格納されます。 このアルゴリズムがサポートされていない場合があります。
シーケンス番号フィールド： 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が示されるべきではありません。
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トークンは、アプリケーションによって、 より上位のプロトコルでカプセル化しなければなりません。 埋め込み長さフィールドは不要です。
チェックサム計算手順(すべてのアルゴリズムに共通)： チェックサムは、平文のパッド済みデータフィールドを通して計算され、 プレーンテキストのパケットヘッダーの最初の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フィールドに格納されます。 このアルゴリズムは、サポートされていない場合もあります。
シーケンス番号フィールド：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〜8バイトが追加することにより、 次に大きい8バイトの倍数にパッドされます。 これらの各バイトの値が、パッドバイトの合計数になります。 例えば、あるデータの長さが20バイトの場合、 4バイトがパッドされます。 そして、各バイトは16進数値の04を含みます。 8バイトのランダムコンファウンダ(混乱要素)がデータの前に付加され、 シグニチャはパッドされた結果プレーンテキストに対して計算されます。
パディング後、 データはSEAL_ALGフィールドに指定されているアルゴリズムに従って暗号化されます。 SEAL_ALG=DESの場合は(現在サポートしている唯一の非ナル アルゴリズム)、 データはゼロIVのDES-CBCを使用して暗号化されます。 使用される鍵は、確立されたコンテキスト鍵から、 コンテキスト鍵と16進定数f0f0f0f0f0f0f0f0の排他的論理和によって取り出されます。
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()によって発行されたトークンで計算されます。 ただし、「サインが必要なデータ」のユーザデータコンポーネントは、 ゼロ長文字列になります。
この節においては、 Kerberos V5 GSS-APIメカニズムのGSS_Import_name()呼出しの入力として渡される名前タイプと、 それに関連付けられている識別子の値について説明します。 これは、移植性をサポートするためのインターフェイス要素を定義していて、 RFC-1509で規定されているC言語パインディングの使用を想定しています。 名前タイプ識別子のOID値の指定に加え、シンボリック名が含まれています。 呼出し側の利便性を高めたい場合は、 シンボリック名を使用することをお勧めします。 Kerberos V5 GSS-APIメカニズムのすべての実装が、 このリストのすべての名前タイプをサポートしている必要はありません。 また、このリストには、今後名前形式が追加されていきます。 さらに、いくつかの名前タイプ、またはすべての名前タイプは、 メカニズム非依存の他の仕様に移行される可能性があります。 この仕様における名前タイプの説明は、 Kerberos V5メカニズムの実装だけがサポートしているタイプを示すことを目的としているのではありません。 特に、シンボリック名文字列内の文字列"_KRB5_"の説明は、 他の文書との競合を避けるために名前文字列の明確な登録方法を指定しているのであって、 名前タイプの使用や適用性を制限しようとしているのではありません。
GSS-APIの実装方法がより明確になるように、この節ではいくつかの名前形式と、 これらの形式を既存のKerberosテクノロジーでサポートする方法について説明しています。 これらの説明は、 Kerberosメカニズムや他のテクノロジーをベースにしているメカニズムの、 名前形式のサポートの代替実装戦略を排除することを目的としているのではありません。 ただし、アプリケーションの移植性を強化するには、 使用しているメカニズムがKerberos V5に依存しない場合でも、可能な限り、 この節で定義されている名前形式をサポートすることをお勧めします。
この節では、Kerberos V5 GSS-APIメカニズムに従属的なすべての実装でサポートすべき名前形式について説明します。
この名前形式は、オブジェクト識別子{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()関数を使って解析できます)。 この名前表現に含まれている要素について、 文字列の先頭から順に以下で説明します。
(1a) 名前コンポーネント内で文字`@`または`/`を使用する場合は、 その直前に引用文字`\`を付けて、 それらがコンポーネント区切り記号やレルム区切り記号として解釈されないようにしなければなりません。
(1b) ASCIIの改行、タブ、バックスペース、およびナル文字は、 コンポーネント内で直接使用することも、 それぞれ`\n`、`\t`、`\b`、`\0`で表すこともできます。
(1c) 引用文字`\`を、 上記(1a)および(1b)で説明しているコンテキスト以外で使用すると、 その直後の文字は文字通りに解釈されます。 特別な例としては、 引用文字を2つ続ける(`\\`)ことで1つの引用文字を表せます。
この名前形式は、 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とともに登録されます。
この名前形式は、 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プリンシパルの名前形式」で定義されている構造の連続した文字列になります。
比較のための正規符号化を行う場合には、 エクスポート操作で以下のことが制限されます。
この節では、Kerberos V5 GSS-APIメカニズムの実装で、 オプションとしてサポートされる追加の名前形式について説明します。 ここで引用している名前形式のいくつかは、 UNIX (tm)オペレーティングシステムプラットフォームから取り出したものです。 リストされている形式のいくつかは、 非UNIXプラットフォームでは不適切で、 それらのプラットフォームに対応する追加形式の定義も不適切です。 また、GSS-APIにはないOS固有の機能は、 これらの形式間で変換が行えるように存在し続け、 これらの形式をサポートしているGSS-APIの実装はOS固有の機能の最上位にレイヤされます。 このサポートは、 アプリケーションの利便性のためにGSS-APIの実装に含まれています。
名前形式は、オブジェクト識別子 {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()は、 ユーザーのプリンシパル名がローカルオペレーティングシステム名と同じであると想定し、 名前の後ろに"@"記号とローカルレルムの名前を追加して、 この形式の名前を処理します。
この名前形式は、 オブジェクト識別子 {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は、 「ユーザーの名前形式」で説明しているように扱われます。
この名前形式は、 オブジェクト識別子 {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形式と同じです。
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の応答を解読して実行します。
この節では、 Kerberos V5 GSS-APIメカニズムで使用するパラメータについて定義します。 移植性をサポートするためのインターフェイス要素を定義し、 RFC-1509 において規定されているC言語バインディングの使用を想定しています。
この節では、 Kerberos V5 GSS-APIメカニズムが返すminor_status値の推奨一般シンボリック名について説明します。 これらの定義を使用することで、 この仕様で定義している異なる実装メカニズム間でのアプリケーションの移植性を、 非依存環境の実装で強化できます(いかなる場合も、 GSS_Display_status()を実装することで、 呼出側はminor_statusインジケータをテキスト表現に変換できます)。 各実装では、インクルードファイルの使用や他の方法によって、 これらのシンボリック名を、 minor_status値を表すために特定のGSS-API実装が使用する具体的な値に変換できるようにする必要があります。
このリストは、今後増えていき、 特殊な実装に固有なminor_statusコードの必要性も出てくるはずです。 ただし、コードが再移植可能な状態を正確に表現する場合は、 独立した実装定義のコードを使用するのではなく、 この節で説明しているメカニズム全体に渡って定義されている minor_status値を実装が返すようにすることを勧めます。
この節においては、 代替の完全性アルゴリズムと守秘性アルゴリズムを選択するための保護品質(QOP)値を定義します。 これらは、 Kerberos V5 GSS-APIメカニズムでGSS_Wrap()およびGSS_GetMIC()ルーチンへの入力値として使用されます。 この仕様の将来のバージョンでは、QOP値が追加される予定です。 指定した完全性値と守秘性値の排他的論理和をとることで、 完全性QOPと守秘性QOPの両方が単一パラメータで選択されるように、 重ならないビット位置が採用されます。
Kerberos V5 GSS-APIメカニズムでは、 現在以下の保護品質(QOP)値が定義されていて、 これらは代替の完全性検査アルゴリズムを選択するのに使用されます。
Kerberos V5 GSS-APIメカニズムでは、 現在以下の守秘性QOP値だけが定義されています。
注意：守秘性QOPは、 守秘性サービスを提供することができるGSS-API呼出しでだけ指定してください。 将来、異なるアルゴリズムを表すゼロ以外の守秘性QOP値が定義された場合は、 GSS_GetMIC()およびGSS_VerifyMIC()の実装が値を返す前に、 これらの値を含んでいるビット位置をクリアしておく必要があります。
この仕様のすべての実装は、GSS_GetMIC()、GSS_VerifyMIC()、 およびGSS_Wrap()への入力として最低16KBのバッファを許容できなければなりません。 また、GSS_Wrap()によって生成されるoutput_tokenを許容できなければなりません。 これには、GSS_Unwrap()への入力として16KBの入力バッファが必要です。 必須ではありませんが、 より大きいバッファサイズをサポートすることを推奨します。
セキュリティの論点について、このメモ全体を通じて検討されています。
[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.