以降の節においては、プロトコル メッセージとオブジェクトの正確な定数と符合化について説明します。ASN.1 基本定義は、最初の項において説明しています。残りの項は、プロトコル オブジェクト (チケットと認証子) とメッセージについて説明しています。暗号化とチェックサム技術の仕様と、それらに関連するフィールドについては、第 6 章において説明しています。
Kerberos において ASN.1 を使用する場合、必ず 8.7 節 [8] の X.509 仕様において説明しているようにデータ要素の正規符号化表現を使用します。
この節の以降の部分では、次の ASN.1 基本定義を使用しています。ASN.1 名ではアンダースコア文字 (_) が使用できないため、代わりにハイフン (-) を使用します。
Realm ::= GeneralString PrincipalName ::= SEQUENCE { name-type[0] INTEGER, name-string[1] SEQUENCE OF GeneralString }
Kerberos レルムは GeneralStrings として符合化されます。レルムはコード 0 (ASCII NUL) の文字を含んでいてはいけません。通常、ほとんどのレルムが、インターネット ドメイン ネーム形式でピリオド (.) で区切られるか、X.500 ネーム形式でスラッシュ (/) で区切られたいくつかのコンポーネントで構成されます。レルム名の使用可能な形式については、第 7 章において説明しています。 PrincipalName は、以下のサブフィールドで構成されている、形式化された一連のコンポーネントです。
name-type このフィールドは、後ろに付く名前のタイプを指定します。このフィールドのあらかじめ定義されている値については、7.2 節において説明しています。name-type は、ヒントとして扱います。名前タイプを無視すると、2 つの名前を同じにすることはできません (たとえば、少なくともコンポーネントまたはレルムの 1 つが異なっていなければなりません)。この定数は、将来省略できるようになります。 name-string このフィールドは、名前を形成する一連のコンポーネントを符合化します (各コンポーネントは一般文字列に符合化されます)。同様に、PrincipalName と Realm はプリンシパル識別子を形成します。 PrincipalNames は、通常、1つまたは 2つのコンポーネントで構成されています。
KerberosTime ::= GeneralizedTime
-- Specifying UTC time zone (Z)Kerberos で使用するタイムスタンプは、GeneralizedTimes に符号化されます。符号化は、UTC 時間帯 (Z) を指定し、秒の小数部分は含みません。また、区切り記号は含みません。例： UTC 時刻 1985年11月 6日午後 9時 6分27 秒を表わす有効な形式は、19851106210627Z です。
HostAddress ::= SEQUENCE { addr-type[0] INTEGER, address[1] OCTET STRING }
HostAddresses ::= SEQUENCE OF SEQUENCE { addr-type[0] INTEGER, address[1] OCTET STRING }
ホスト アドレスの符号化は、次の 2つのフィールドで構成されています。
addr-type このフィールドは、それに続くアドレスのタイプを指定します。あらかじめ定義されている値については、8.1 節において説明しています。
address このフィールドは、タイプ addr-type の 1 つのアドレスを符号化します。
2 つの形式は少し異なります。HostAddress は、1 つのアドレスだけを含み、HostAddresses は、(おそらく大量な)一連のアドレスを含みます 。
AuthorizationData ::= SEQUENCE OF SEQUENCE { ad-type[0] INTEGER Ad-data[1] OCTET STRING }
ad-data このフィールドは、対応する ad-type フィールドの値に従って解釈する必要のある認証データを含んでいます。 ad-type このフィールドは、ad-data サブフィールドの形式を指定します。負の値はすべてローカルで使用するために予約されています。負以外の値は、登録された使用のために予約されています。 APOptions ::= BIT STRING {
reserved(0),
use-session-key(1),
mutual-required(2)} TicketFlags ::= BIT STRING {
reserved(0),
forwardable(1),
forwarded(2),
proxiable(3),
proxy(4),
may-postdate(5),
postdated(6),
invalid(7),
renewable(8),
initial(9),
pre-authent(10),
hw-authent(11)} KDCOptions ::= BIT STRING {
reserved(0),
forwardable(1),
forwarded(2),
proxiable(3),
proxy(4),
allow-postdate(5),
postdated(6),
unused7(7),
renewable(8),
unused9(9),
unused10(10),
unused11(11),
renewable-ok(27),
enc-tkt-in-skey(28),
renew(30),
validate(31)} LastReq ::= SEQUENCE OF SEQUENCE { lr-type[0] INTEGER, lr-value[1] KerberosTime } lr-type このフィールドは、以降の lr-value フィールドをどのように解釈するかを示します。負の値は、情報が応答サーバーだけに関係することを示します。負以外の値は、レルムのすべてのサーバーに関係します。lr-type フィールドがゼロ (0) の場合、lr-value サブフィールドに情報は伝達されません。 lr-value lr-type フィールドの絶対値が (1) の場合、lr-value サブフィールドは前回行われた TGT の初期要求の時刻になります。lr-type フィールドの絶対値が (2) の場合、lr-value サブフィールドは前回行われた初期要求の時刻になります。lr-type フィールドの絶対値が (3) の場合、lr-value サブフィールドは使用した最新のチケット交付チケットを発行した時刻になります。lr-type フィールドの絶対値が (4) の場合、lr-value サブフィールドは前回更新した時刻になります。lr-type フィールドの絶対値が (5) の場合、lr-value サブフィールドは前回の要求 (あらゆるタイプの) の時刻になります。 このフィールドは、前回の要求の時刻を含みます。この時刻は、対応する lr-type サブフィールドの内容に従って解釈しなければなりません。
Checksum、ChecksumType、EncryptedData、EncryptionKey、EncryptionType、および KeyType の定義については、第 6 章を参照してください。
この節においては、チケットと認証子の形式と暗号化パラメータについて説明します。チケットまたは認証子がプロトコル メッセージに含まれている場合、それは非透過的なオブジェクトとして扱われます。
チケットは、クライアントがサービスから認証を得るレコードです。チケットには以下の情報が含まれています。
| Ticket ::= | [APPLICATION 1] SEQUENCE { | |
| tkt-vno[0] | INTEGER, | |
| 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 | |
| } | ||
| -- 符号化された Transited フィールド | ||
| TransitedEncoding ::= | SEQUENCE { | |
| tr-type[0] | INTEGER, -- 登録しなければならない | |
| contents[1] | OCTET STRING | |
| } |
EncTicketPart の符号化は、Kerberos と終端サーバー (サーバーの秘密鍵) によって共有されている鍵によって暗号化されています。暗号文の形式については、第 6 節を参照してください。
tkt-vno このフィールドは、チケット形式のバージョン番号を指定します。この文書は、v5 について説明します。 realm このフィールドは、チケットを発行するレルムを指定します。また、サーバーのプリンシパル識別子のレルム部分も識別します。Kerberos サーバーはレルム内のサーバーにだけチケットを発行できるので、これらは常に同じになります。 sname このフィールドは、サーバーの識別の名前部分を指定します。 enc-part このフィールドは、EncTicketPart シーケンスの符合化された符号を保持します。 flags このフィールドは、チケットが発行されたときにさまざまなオプションのどれが使用または要求されたかを示します。これはビットフィールドで、選択されているオプションはビットがセットされて示され (1)、選択解除されているオプションと予約済みフィールドはビットが解除されて示されます (0)。ビット 0 は、最上位ビットです。ビットの符号化については、5.2 節を参照してください。フラグの詳細については、第 2 節を参照してください。フラグの意味は以下のとおりです。 ビット 名前 説明 0 RESERVED このフィールドの将来の拡張のために予約済みです。
1 FORWARDABLE FORWARDABLE フラグは、通常、TGS だけが解釈し、終端サーバーは無視します。セットされている場合、このフラグは提出されたチケットに基づいた異なるネットワーク アドレスの新しいチケット交付チケットを発行しても良いことをチケット交付サーバーに伝えます。
2 FORWARDED セットした場合、このフラグは 転送されたチケット交付チケットを伴う認証に基づいて、チケットが転送または発行されたことを示します。 3 PROXIABLE PROXIABLE フラグは、通常、TGS だけが解釈し、終端サーバーは無視します。PROXIABLE フラグは、FORWARDABLE フラグと同じ意味を持ちますが、これは非チケット交付 チケットだけが異なるネットワーク アドレスで発行できることをチケット交付サーバーに伝えます。
4 PROXY セットした場合、このフラグはチケットが代理であることを示します。
5 MAY-POSTDATE MAY-POSTDATE フラグは、通常、TGS だけが解釈し、終端サーバーは無視します。このフラグは、このチケット交付チケットに基づいて未来の日付のチケットを発行することをチケット交付サーバーに伝えます。
6 POSTDATED このフラグは、チケットの日付が以降の日付であることを示します。終端サービスは、authtime フィールドをチェックして、オリジナルの認証が行われた日付を確認できます。
7 INVALID このフラグは、チケットが不正であり、使用する前に KDC で有効化しなければならないことを示します。アプリケーション サーバーは、このフラグがセットされているチケットを拒否しなければなりません。
8 RENEWABLE RENEWABLE フラグは、通常、TGS だけが解釈し、終端サーバーは無視します (特に慎重なサーバーは、更新可能なチケットを受け付けようとしません)。更新可能なチケットは、未来の日付に満了する代わりのチケットを取得するのに使用できます。
9 INITIAL このフラグは、チケットがチケット交付チケットに基づいてではなく、AS プロトコルを使用して発行されたことを示します。
10 PRE-AUTHENT このフラグは、初回の認証中に、クライアントはチケットが発行される前に KDC によって認証されたことを示します。事前認証方式の強さは示されませんが、KDC はこれを受け入れます。
11 HW-AUTHENT このフラグは、初回の認証で使用されたプロトコルが、特定のクライアントが単独で所有していると考えられるハードウェアの使用を要求したことを示します。ハードウェア認証方式は KDC によって選択され、方式の強さは示されません。
12-31 RESERVED 将来の使用のために予約済みです。 key このフィールドは、チケットと KDC 応答内に存在し、Kerberos からアプリケーション サーバーとクライアントにセッション鍵を渡すのに使用されます。フィールドの符号化については、6.2 節を参照してください。 crealm このフィールドは、クライアントが登録されていて、初回の認証が行われたレルム名を含んでいます。 cname このフィールドは、クライアントのプリンシパル識別子の名前部分を含んでいます。 transited このフィールドは、このチケットの発行先であるユーザーを認証するのに使われた Kerberos レルムの名前を一覧します。レルムの転送順序は示しません。このフィールドが通過したレルムをどのように符号化するかについては、3.3.3.1 節を参照してください。 authtime このフィールドは、名付けられたプリンシパルの初回の認証の時刻を示します。このチケットがベースになったオリジナルのチケットの発行時刻です。これは、終端サービスに追加情報を提供し、KDC で「ホットリスト」サービスを実装するのに必要な情報を提供するために含まれています。特に慎重な終端サービスは、かなり以前に初回の認証が行われたチケットの受け取りを拒否します。このフィールドは、KDC からの応答の一部分としても返されます。初回の認証に対する応答の一部分として返された場合 (KRB_AS_REP)、これは Kerberos サーバーの現在の時刻になります (ワークステーションのクロックの調整に、この時刻値を使用することはお勧めしません。これは、ワークステーションが、この KRB_AS_REP が適切な KDC から適時受け取ったことを判断できないためです)。 starttime チケット内のこのフィールドは、チケットが有効になったときの 時刻を示します。このフィールドと endtime を使用して、 チケットの有効期限を示すことができます。チケットにこの値が 含まれていない場合、authtime フィールドの値と同じであると扱われます。 endtime このフィールドは、チケットが受領されなくなる時刻を含んでいます (つまり、満了時刻)。個別のサービスは、独自のチケット有効期限を設定し、満了していないチケットを拒否する場合があることに注意してください。このため、実際にはこれはチケットの満了時刻の上限値となります。 renew-till このフィールドは、フラグ フィールドに RENEWABLE フラグがセットされたチケットだけに現れます。これは、更新時に含まれる最大 endtime を示し、すべての更新を含む、チケットの完全な満了時刻であると考えることができます。 caddr このチケット内のフィールドは、ゼロ (省略された場合) または複数 (存在する場合) のホスト アドレスを含みます。これらのアドレスは、チケットが使用できるアドレスです。アドレスが含まれていない場合、チケットはあらゆる場所から使用できます。アドレスが含まれていないチケットを KDC が発行するかどうかと、終端サービスが受け取るかどうかは、ポリシーで決定することで、Kerberos と終端サービスの管理者に委ねられています。このようなチケットの発行と受領を拒否することもできます。推奨されているデフォルトのポリシーでは、authorization_data フィールドにチケットの使用を制限できる追加情報が含まれている場合だけ、このようなチケットを発行したり受領できます。このようなチケットがケイパビィリティです。攻撃者が盗んだ信任状を使うことができないように、チケットにはネットワーク アドレスが含まれています。セッション鍵は、ネットワーク上をクリアテキストの状態では送信されないために、信任状は単にネットワークをリスンするだけでは盗むことはできません。つまり、攻撃者はセッション鍵にアクセスできなければなりません (オペレーティング システムのセキュリティ違反や不注意なユーザーがセッションを実行したままその場を離れた場合など)。 接続を受信したネットワーク アドレスは確実には判断できないことに注意してください。判断できたとして、クライアントのワークステーションを利用できる攻撃者は、そこから信任状を使用します。ネットワーク アドレスを含めた場合には、攻撃者は盗んだ信任状を持ち去ってそれを安全な場所から使用するのが難しくなりますが、不可能にはなりません。
authorization-data authorization-data フィールドは、プリンシパルからアプリケーション サービスに認定データを渡すのに使用します。プリンシパルから認証データが含まれていない場合、このフィールドは省略されます。このフィールド内のデータは、終端サービスに固有です。フィールドには、オブジェクトに固有なサービスの名前と、それらのオブジェクトに対する権限が含まれていると想定されます。このフィールドの形式は、5.2 節で 説明しています。Kerberos は、サブフィールドの内容の形式には関与しませんが、タイプ情報 (ad-type) は伝送します。 authorization_data フィールドを使用することで、プリンシパルは特定の目的で有効なプロキシを発行できます。例えば、ファイル印刷したいクライアントは、プリント サーバーに渡すファイル サーバーのプロキシを取得できます。authorization_data フィールド内にファイル名を指定することで、ファイル サーバーは、プリント サーバーが印刷する特定のファイルにアクセスした場合だけクライアントの権限を使用できることを認識します。
プロキシの authorization-data フィールドを指定して、ホスト アドレスを空白のままにしておくと、結果のチケットとセッション鍵はケイパビリティとして扱うことができます。このフィールドの使用方法については、[9]を参照してください。
authorization-data フィールドは、任意のフィールドで、チケットに含める必要はありません。
-- 暗号化されていない認証子 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 }
authenticator-vno このフィールドは、認証子の形式のバージョン番号を指定します。本書では、バージョン 5 を指定します。 crealm、cname これらのフィールドは、5.3.1 節において説明したチケットのフィールドと同じです。 cksum このフィールドは、KRB_AP_REQ を伴うアプリケーションデータのチェックサムを含んでいます。 cusec このフィールドは、クライアントのタイムスタンプのマイクロ秒部分を含んでいます。値 (暗号化前) の範囲は 0 〜 999999 です。このフィールドは、ctime とともに表示されます。2 つのフィールドは、適度に正確なタイムスタンプを指定するのに一緒に使用します。 ctime このフィールドは、クライアントのホスト上の現在の時刻を含みます。 subkey このフィールドは、クライアントが選択した、固有のアプリケーション セッションを保護するのに使用する暗号化鍵を含んでいます。アプリケーションが別のものを指定しない限り、このフィールドを省略した場合にはチケットのセッション鍵が使用されます。 seq-number このオプションのフィールドは、リプレイを検出するのにシーケンス番号を使用する場合に、KRB_PRIV または KRB_SAFE メッセージによって使用される初回のシーケンス番号を含んでいます (また、アプリケーション固有のメッセージも使用されます)。認証子に含めた場合、このフィールドは、クライアントからサーバーへのメッセージ用の初期シーケンス番号を指定します。AP-REP メッセージに含めた 場合、サーバーからクライアントへのメッセージ用の初期シーケンス番号になります。KRB_PRIV または KRB_SAFE メッセージで使用した 場合、各メッセージの送信後、これに 1 が加算されます。リプレイ検出を十分にサポートするためには、境界間の接続であっても、シーケンス番号は非リピートでなければなりません。攻撃者が推測できないように、また、連続したシーケンス番号が他のシーケンスを繰り返さないように、初期シーケンス番号はランダムで、利用可能なシーケンス番号全体に渡って一様に分散されていなければなりません。 authorization-data このフィールドは、5.3.1 節において説明しているチケットのフィールドと同じです。このフィールドはオプションで、チケットで指定されいる以外のチケットの使用方法の制約を追加した場合だけ表示されます。
ここでは、クライアントと Kerberos サーバー間の交換で使用されるメッセージの形式について説明します。発生する可能性のあるエラー メッセージの形式については、5.9.1 節を参照してください。
KRB_KDC_REQ メッセージは、独自のタイプを持っていません。このメッセージのタイプは、要求が初回のチケット取得用か追加のチケット取得用かによって KRB_AS_REQ または KRB_TGS_REQ になります。どちらの場合も、メッセージはクライアントから認証サーバーに送信され、サービスの信任状を要求します。
メッセージ フィールドを以下に示します。
AS-REQ ::= [APPLICATION 10] KDC-REQ TGS-REQ ::= [APPLICATION 12] KDC-REQ KDC-REQ ::= SEQUENCE { pvno[1] INTEGER, msg-type[2] INTEGER, padata[3] SEQUENCE OF PA-DATA OPTIONAL, req-body[4] KDC-REQ-BODY } PA-DATA ::= SEQUENCE { padata-type[1] INTEGER, padata-value[2] OCTET STRING, -- 符号化された AP-REQ } KDC-REQ-BODY ::= SEQUENCE { kdc-options[0] KDCOptions, cname[1] PrincipalName OPTIONAL, -- AS-REQ でだけ使用される realm[2] Realm, -- サーバーのレルム -- AS-REQ 内のクライアント sname[3] PrincipalName OPTIONAL, from[4] KerberosTime OPTIONAL, till[5] KerberosTime, rtime[6] KerberosTime OPTIONAL, nonce[7] INTEGER, etype[8] SEQUENCE OF INTEGER, -- 設定順序になった -- EncryptionType addresses[9] HostAddresses OPTIONAL, enc-authorization-data[10] EncryptedData OPTIONAL, -- 暗号化された AuthorizationData 符号 additional-tickets[11] SEQUENCE OF Ticket OPTIONAL }このメッセージ内のフィールドは以下のとおりです。：
pvno このフィールドは、各メッセージに含まれていて、プロトコルのバージョン番号を指定します。この文書では、プロトコル バージョン 5 を指定します。 msg-type このフィールドは、プロトコル メッセージのタイプを示します。これは、メッセージに伴われるアプリケーション識別子とほとんどいつも同じになります。これは、識別子が、より素早くアプリケーションにアクセスできるように含まれています。KDC-REQ メッセージでは、このタイプは KRB_AS_REQ または KRB_TGS_REQ になります。 padata padata (事前認証データ) フィールドは、信任状を発行したり復号するのに必要な認証情報を含んでいます。追加のチケットを要求した場合 (KRB_TGS_REQ)、このフィールドは PA-TGS-REQ の padata-type の要素と、認証ヘッダーのデータを含みます (チケット 交付チケットと認証子)。認証子内のチェックサム (耐衝突性でなければならない) は、KDC-REQ-BODY 符号化を通して検算されます。初回の認証 (KRB_AS_REQ) のほとんどの要求と応答 (KDC-REP) で padata フィールドは省略されます。 このフィールドは、Kerberos プロトコルの特定の拡張で必要となる情報も含んでいます。たとえば、応答が返される前に、クライアントの識別を初めて検証する場合に使用されます。padata フィールドの padata-type が PA-ENC-TIMESTAMP に等しく、padata-value が次のように定義されている場合にこのようになります。
padata-type ::= PA-ENC-TIMESTAMP
padata-value ::= EncryptedData -- PA-ENC-TS-ENC
PA-ENC-TS-ENC ::= SEQUENCE {
patimestamp[0] KerberosTime, -- クライアントの時刻
pausec[1] INTEGER OPTIONAL
}
patimestamp にクライアントの時刻が含まれ、pausec にマイクロ秒が含まれています。これはクライアントが 1 秒あたり 2 つ以上の要求を生成しないと省略されます。暗号文 (padata-value) は、PA-ENC-TS-ENC シーケンスで構成され、クライアントの秘密鍵を使用して暗号化されます。 padata フィールドは、KDC やクライアントが応答を生成したり復号するのに必要な情報を含むことができます。padata のこの形式は、Kerberos でそのようなスマートカードを使用する場合に便利です。これらの拡張の詳細は、この仕様の範囲外です。このフィールドのその他の使用方法については [10] を参照してください。
padata-type padata フィールドの padata-type 要素は、padata-value 要素の解釈方法を示します。padata-type の負の値は、未登録の使用方法用に予約済みです。負以外の値は、要素タイプの登録された解釈で使用されます。 req-body このフィールドは、残りのフィールドの範囲を区切っている位置指定子です。チェックサムが要求に対して計算される場合、それは req-body フィールドに入っている KDC-REQ-BODY シーケンスの符号に対して計算されることになります。 kdc-options このフィールドは、KDC への KRB_AS_REQ および KRB_TGS_REQ 要求に含まれていて、クライアントがチケットにセットしたいフラグと、KDC の動作を修正する他の情報を示します。適切な 場合、オプションの名前は、オプションによってセットされたフラグと同じになります。ほとんどの場合、オプション フィールド内のビットはフラグ フィールド内のビットと同じになりますが、これは保証されていません。このため、オプション フィールドをフラグ フィールドに単にコピーすることはできません。どちらにしろ、オプションを受領する前にさまざまなチェックを行う必要があります。 kdc_options フィールドはビット フィールドで、選択されているオプションはビットがセットされた状態 (1) で示され、選択されていないオプションと予約フィールドはビットが解除された状態 (0) で示されます。ビットの符号については、5.2 節を参照してください。オプションの詳細については、第 2 章を参照してください。オプションの意味は以下のとおりです。
ビット 名前 説明 0 RESERVED このフィールドの将来の拡張のために予約済みです。 1 FORWARDABLE FORWARDABLE オプションは、発行するチケットの転送可能フラグをセットする必要があることを示します。このフラグは、初回の要求のときだけセットできます。または、それがベースにしているチケット 交付チケットも転送可能な場合、後続の要求でもセットできます。 2 FORWARDED FORWARDED オプションは、チケット交付サーバーへの要求でだけ指定でき、要求内のチケット交付チケットの FORWARDABLE ビットがセットされている場合だけ受領されます。このオプションは、これが転送の要求であることを示します。結果のチケットが有効化されるホストのアドレスは、要求のアドレス フィールドに含まれます。 3 PROXIABLE PROXIABLE オプションは、発行するチケットの代理可能フラグをセットする必要があることを示します。このフラグは、初回の要求のときだけセットできます。または、それがベースにしているチケット 交付チケットも代理可能な場合、後続の要求でもセットできます。 4 PROXY PROXY オプションは、これが代理の要求であることを示します。このオプションは、要求内のチケット交付チケットの PROXIABLE ビットがセットされている場合だけ受領されます。結果のチケットが有効化されるホストのアドレスは、要求のアドレス フィールドに含まれます。 5 ALLOW-POSTDATE ALLOW-POSTDATE オプションは、発行するチケットの MAY-POSTDATE フラグをセットする必要があることを示します。このフラグは、初回の要求のときだけセットできます。または、それがベースにしているチケット交付チケットが MAY-POSTDATE フラグをセットしている場合、後続の要求でもセットできます。 6 POSTDATED POSTDATED オプションは、これが未来の日付のチケットの要求であることを示します。このオプションは、それがベースにしているチケット交付チケットの MAY-POSTDATE フラグがセットされている場合だけ受領されます。結果のチケットの INVALID フラグもセットされます。このフラグは、チケット内の starttime 以降、KDC に後続の要求を行うことでリセットできます。 7 UNUSED このオプションは、現在使われていません。 8 RENEWABLE RENEWABLE オプションは、発行するチケットの RENEWABLE フラグをセットする必要があることを示します。このフラグは、初回の要求のときだけセットできます。または、それがベースにしているチケット交付チケットが更新可能な場合もセットできます。このオプションを要求した場合、要求内の rtime フィールドには、チケットの希望する完全な満了時刻が含まれます。 9-26 RESERVED 将来の使用のために予約済みです。 27 RENEWABLE-OK RENEWABLE-OK オプションは、要求した有効期限のチケットが提供されない場合に、更新可能なチケットを受け付けることを示します。要求した有効期限のチケットが提供されない場合、renew-till を要求された endtime にセットして、更新可能なチケットを発行できます。renew-till フィールドの値は、引き続きローカルな制限、または個別のプリンシパルまたはサーバーによって選択された制限によって制限されます。 28 ENC-TKT-IN-SKEY このオプションは、チケット交付サービスだけが使用します。ENC-TKT-IN-SKEY オプションは、終端サーバーのチケットが追加のチケット交付チケットから提供されたセッション鍵で暗号化されることを示します。 29 RESERVED 将来の使用のために予約済みです。 30 RENEW このオプションは、チケット交付サービスだけが使用します。RENEW オプションは、提出されている要求が更新のための要求であることを示します。提供されたチケットは、それが有効であるサーバーの秘密鍵で暗号化されています。このオプションは、更新するチケットの RENEWABLE フラグがセットされていて、renew till フィールドの時刻に達していない場合だけ受領されます。更新するチケットは、認証ヘッダーの一部としてpadata フィールド内に渡されます。 31 VALIDATE このオプションは、チケット交付サービスだけが使用します。VALIDATE オプションは、要求が未来の日付のチケットを有効化することを示します。このオプションは、提出されたチケットが未来の日付のチケットで、現在 INVALID フラグがセットされていて、この時点でそれ以外では使用できない場合だけ受領されます。チケットは、その starttime 時刻以前には有効化できません。検証のために提出されたチケットは、サーバーの鍵 (そのサーバーに有効で、認証ヘッダーの一部として padata フィールドで渡された) で暗号化されています。 cname and sname これらのフィールドは、5.3.1 節において説明したチケットのフィールドと同じです。sname は、ENC-TKT-IN-SKEY オプションを指定した場合だけセットされません。セットされていない場合、サーバーの名前は、追加のチケットとして渡されたチケット内のクライアント名になります。 enc-authorization-data enc-authorization-data が存在する場合 (これは、TGS_REQ 形式内でのみ存在できます)、これは希望する認証データをサブセッション鍵 (認証子に存在する場合)または、チケット 交付チケット内のセッション鍵 (どちらも KRB_AP_REQ 内の padata フィールドから) で暗号化した符号です。 realm このフィールドは、サーバーのプリンシパル識別子のレルム部分を指定します。AS 交換で、これはクライアントのプリンシパル識別子のレルム部分でもあります。 from このフィールドは、要求したチケットが未来の日付にされた場合に、KRB_AS_REQ と KRB_TGS_REQ チケットの要求に含まれます。のフィールドは、要求したチケットの希望する開始時刻を指定します。 till このフィールドは、クライアントがチケット要求で要求した満了日を含みます。 rtime このフィールドは、チケット要求内でクライアントから KDC に送信された、要求した renew-till 時刻を含みます。これはオプションのフィールドです。 nonce このフィールドは、KDC 要求と応答の一部分です。クライアントが生成したランダムな番号を保持することを目的としています。KDC の暗号化された応答に同じ数値が含まれている場合、このフィールドは、応答が新しいもので、攻撃者によってリプレイされていないことを示す証拠を提供します。nonce の値は絶対に再使用してはいけません。理想的にはランダムに生成すべきですが、正しい時刻がわかっている 場合これで十分です (ただし、時刻をnonce として使用した場合、ワークステーションの時刻が一定割合で増加していることを確認する必要があります。時刻が以前に戻された 場合、nonce が再使用される可能性があります)。 etype このフィールドは、応答で使用する暗号化アルゴリズムを指定します。 addresses このフィールドは、チケットの初回の要求に含まれていて、チケット交付チケットの追加のチケット要求にオプションで含まれています。これは、要求したチケットが有効になるアドレスを指定します。通常、これは、クライアントのホストのアドレスを含んでいます。代理が要求された場合、このフィールドには他のアドレスが含まれます。このフィールドの内容は、通常、KDC により結果のチケットの caddr フィールドにコピーされます。 additional-tickets 追加のチケットを、チケット交付サーバーの要求にオプションで含めることができます。ENC-TKT-IN-SKEY オプションを指定した 場合、新しいチケットを暗号化するのに、サーバーの鍵の代わりに追加のチケットのセッション鍵が使われます。追加のチケットを要求するオプションを 2 つ以上指定した 場合、オプションのビットの順序で指定されている順序で追加のチケットが使われます (上記の kdc-options を参照のこと)。 アプリケーション コードは、要求が初回のチケット (AS-REQ) 用であるか追加のチケット (TGS-REQ) 用であるかによって、10 または 12 になります。
オプションのフィールド (addresses, authorization-data、additional-tickets) は、kdc-options フィールドで指定されている処理を実行する必要がある場合だけ含まれます。 KRB_TGS_REQ 内では、プロトコル バージョン番号が 2 回登場し、2 つの異なるメッセージ タイプが登場することに注目してください。
KRB_TGS_REQ メッセージは、padata フィールドで渡された認証ヘッダー (KRB_AP_REQ) と同様にこれらのフィールドを含んでいます。
KRB_KDC_REP メッセージ形式は、初回 (AS) の要求、または後続 (TGS) の要求用の KDC の応答で使用されます。KRB_KDC_REP 用のメッセージ タイプはありません。その代わり、タイプは KRB_AS_REP または KRB_TGS_REP のいずれかになります。応答の暗号文部分を暗号化するために使用する鍵は、メッセージ タイプによって異なります。KRB_AS_REP では、暗号文はクライアントの秘密鍵で暗号化され、クライアントの鍵バージョン番号は、暗号化データの鍵バージョン番号に含まれます。KRB_TGS_REP では、暗号文は、認証子のサブセッション鍵で暗号化されます。サブセッション鍵が存在しない場合、チケット交付チケットのセッション鍵が要求で使用されます。この場合、EncryptedData シーケンス内にバージョン番号は現れません。
KRB_KDC_REP メッセージには以下のフィールドが含まれています。
AS-REP ::= [APPLICATION 11] KDC-REP
TGS-REP ::= [APPLICATION 13] KDC-REP
KDC-REP ::= SEQUENCE {
pvno[0] INTEGER,
msg-type[1] INTEGER,
padata[2] SEQUENCE OF PA-DATA OPTIONAL,
crealm[3] Realm,
cname[4] PrincipalName,
ticket[5] Ticket,
enc-part[6] EncryptedData
}
EncASRepPart ::= [APPLICATION 25[25]] EncKDCRepPart
EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart
EncKDCRepPart ::= SEQUENCE {
key[0] EncryptionKey,
last-req[1] LastReq,
nonce[2] INTEGER,
key-expiration[3] KerberosTime OPTIONAL,
flags[4] TicketFlags,
authtime[5] KerberosTime,
starttime[6] KerberosTime OPTIONAL,
endtime[7] KerberosTime,
renew-till[8] KerberosTime OPTIONAL,
srealm[9] Realm,
sname[10] PrincipalName,
caddr[11] HostAddresses OPTIONAL
}
注意： EncASRepPart では、メッセージの暗号化部分のアプリケーション コードは、メッセージが正しく復号されたことを確認する追加チェックを提供します。
pvno、msg-type これらのフィールドについては、5.4.1 節において説明しています。msg-type は、KRB_AS_REP または KRB_TGS_REP です。 padata このフィールドについては、5.4.1 節で詳しく説明しています。
このフィールドは、代替の混ぜ合わせた文字列を「文字列から鍵」アルゴリズムで使用するために符号化する場合だけ使用します (6.3.2 節において説明しているように)。この機能は、レルム名を変更する必要がある場合に、変更を容易にする ために便利です。（例えば、会社が取得された場合。）そのような場合、KDC 内の、パスワードから取り出した存在するすべてのエントリは、次のパスワード変更が行われるまで特別な混ぜ合わせた文字列が必要であることがフラグされます。crealm、cname、srealm、sname これらのフィールドは、5.3.1 節において説明したチケット用のものと同じです。
ticket 5.3.1 節で新しく発行したチケットです。 enc-part このフィールドは、メッセージの暗号化部分を形成する暗号文と関連情報の位置指定子です。 メッセージの暗号化部分の説明は、このフィールドが現れるたびにその後ろに続きます。暗号化部分は、6.1 節において説明しているように符号化されます。
key このフィールドは、5.3.1 節において説明しているチケットのフィールドと同じです。 last-req このフィールドは KDC によって返され、プリンシパルが行った最後の要求時刻を指定します。利用可能な情報によって、この時刻は、チケット 交付チケットの要求が最後に行われたとき、あるいは、チケット交付チケットに基づいた要求が最後に成功したときになります。また、レルムのすべてのサーバーをカバーするか、特定のサーバーだけをカバーします。実装のいくつかは、あるユーザーの識別が許可なく使用されたことを発見できるように、この情報をユーザーに表示します。これは、タイムシェアリング システムにログインした場合、最後にログインした時刻が表示されるのと同じ発想です。 nonce このフィールドについては、5.4.1 節において説明しています。 key-expiration key-expiration フィールドは、KDC からの応答の一部分で、クライアントの秘密鍵が満了する時刻を指定します。パスワード エイジングまたはアカウント満了によって満了します。 このフィールドは、TGS 要求に対する応答がセッション鍵で暗号化されていて、KDC データベースからクライアント情報を取り出す必要がないため、通常 TGS 応答では省略されます。
満了時刻が迫っている場合、アプリケーション クライアント (通常は、ログイン プログラム) の責任で適切なアクション (ユーザに通知するなどの) を取ります。
flags、
authtime、
starttime、
endtime、
renew-till、
caddrこれらのフィールドは、添付されたチケットの暗号化部分にあるフィールドと重複しています (5.3.1 節を参照のこと)。 クライアントが、それらが意図した要求と一致していることを検証し、チケット キャッシングが適切に行われるのを助けるために提供されています。メッセージのタイプが KRB_TGS_REP の場合で、要求が代理チケットまたは転送チケット用である場合か、ユーザがチケット 交付チケットからアドレスのサブセットを代用している場合に、caddr フィールドはセットされます。
クライアントが要求しているアドレスが存在しない場合、または使用されていない場合、チケットに含まれるアドレスは、チケット交付チケットに含まれているものと同じになります。
5.5. クライアント／サーバー (CS) メッセージ仕様 English
この節においては、アプリケーション サーバーへのクライアントの認証に使用するメッセージの形式を指定しています。
KRB_AP_REQ メッセージは、Kerberos プロトコル バージョン番号、メッセージ タイプ KRB_AP_REQ、使用しているあらゆるオプションを示すオプション フィールド、およびチケットと認証子自体を含んでいます。KRB_AP_REQ メッセージは、「認証ヘッダー」とも呼ばれます。
AP-REQ ::= [APPLICATION 14] SEQUENCE {
pvno[0] INTEGER,
msg-type[1] INTEGER,
ap-options[2] APOptions,
ticket[3] Ticket,
authenticator[4] EncryptedData
}
APOptions ::= BIT STRING {
reserved(0),
use-session-key(1),
mutual-required(2)
}
pvno、msg-type これらのフィールドについては、5.4.1 節において説明しています。msg-type は、KRB_AP_REQ です。
ap-options このフィールドは、アプリケーション要求 (KRB_AP_REQ) に現れ、要求の処理方法に影響を与えます。 これはビットフィールドで、選択されているオプションはビットがセットされて示され (1)、選択解除されているオプションと予約済みフィールドはビットが解除されて示されます (0)。ビット 0 は、最上位ビットです。
ビットの符号化については、5.2 節を参照してください。
フラグの意味は以下のとおりです。
ビット 名前 説明 0 RESERVED このフィールドの将来の拡張のために予約済みです。 1 USE-SESSION-KEY USE-SESSION-KEY オプションは、クライアントがサーバーに提出しているチケットがサーバーのチケット 交付チケットのセッション鍵で暗号化されていることを示します。このオプションが指定されていない場合、チケットはサーバーの秘密鍵で暗号化されます。 2 MUTUAL-REQUIRED MUTUAL-REQUIRED オプションは、クライアントが相互認証を要求していて、KRB_AP_REP メッセージで応答しなければならないことをサーバーに伝えます。 3-31 RESERVED 将来の使用のために予約済みです。 ticket このフィールドは、サーバーにクライアントを認証させるチケットです。 authenticator これは、クライアントが選択したサブ鍵を含む認証子を含んでいます。これの符号化については 5.3.2 節を参照してください。
KRB_AP_REP メッセージは、Kerberos プロトコル バージョン番号、メッセージ タイプ、および暗号化されたタイムスタンプを含んでいます。メッセージは、相互認証オプションが ap-options フィールドで選択されたアプリケーション要求 (KRB_AP_REQ) に応じて送信されます。AP-REP ::= [APPLICATION 15] SEQUENCE { pvno[0] INTEGER, msg-type[1] INTEGER, enc-part[2] EncryptedData } EncAPRepPart ::= [APPLICATION 27] SEQUENCE { ctime[0] KerberosTime, cusec[1] INTEGER, subkey[2] EncryptionKey OPTIONAL, seq-number[3] INTEGER OPTIONAL }注意： EncASRepPart では、メッセージの暗号化部分のアプリケーション コードは、メッセージが正しく復号されたことを確認する追加チェックを提供します。
符合化された EncAPRepPart は、チケットの共有セッション鍵で暗号化されています。オプションのサブ鍵フィールドは、アプリケーションで計画したネゴシエーションで使用して、組み合わせごとのセッション鍵を選択できます。
pvno and msg-type これらのフィールドについては、5.4.1 節において説明しています。msg-type は、KRB_AP_REQ です。 enc-part このフィールドについては、5.4.2 節において説明しています。 ctime このフィールドは、クライアントのホスト上の現在の時刻を含みます。 cusec このフィールドは、クライアントのタイムスタンプのマイクロ秒部分を含んでいます。 subkey このフィールドは、この固有のアプリケーション セッションの保護に使用する暗号化鍵を含んでいます。このフィールドが鍵をネゴシエーションする特性については、3.2.6 節を参照してください。アプリケーションが指定しない限り、このフィールドが省略されると、認証子のサブセッション鍵が使用されます。これも省略された 場合、チケットのセッション鍵が使用されます。
アプリケーション要求の処理中にエラーが発生すると、それの応答として KRB_ERROR メッセージが送信されます。エラー メッセージの形式については 5.9.1 節を参照してください。cname および crealm フィールドは、サーバーが対応する KRB_AP_REQ メッセージから適切な値を判断できない場合、省略できます。認証子が解読できない場合、ctime と cusec フィールドはそれらの値を含みます。
この節は、耐改ざん性メッセージをピアに送信するのに、アプリケーションのどちらの側 (クライアントまたはサーバー) からも使用できるメッセージの形式を指定します。ここでは、セッション鍵がすでに交換されていると仮定しています (たとえば、KRB_AP_REQ/KRB_AP_REP メッセージを使用して)。
KRB_SAFE メッセージは、ユーザー データとともに、セッション鍵で鍵付きにされた耐衝突性のあるチェックサムを含んでいます。メッセージ フィールドを以下に示します。KRB-SAFE ::= [APPLICATION 20] SEQUENCE {
pvno[0] INTEGER,
msg-type[1] INTEGER,
safe-body[2] KRB-SAFE-BODY,
cksum[3] Checksum
}
KRB-SAFE-BODY ::= SEQUENCE {
user-data[0] OCTET STRING,
timestamp[1] KerberosTime OPTIONAL,
usec[2] INTEGER OPTIONAL,
seq-number[3] INTEGER OPTIONAL,
s-address[4] HostAddress,
r-address[5] HostAddress OPTIONAL
}
pvno、msg-type これらのフィールドについては、5.4.1 節において説明しています。msg-type は、KRB_SAFE です。 safe-body このフィールドは、KRB-SAFE メッセージの本文の位置指定子です。cksum フィールドで使用するには、これを個別に符号化し、全体をチェックサムで演算する必要があります。 cksum このフィールドは、アプリケーション データのチェックサムを含んでいます。チェックサムの詳細については、6.4 節を参照してください。チェックサムは KRB-SAFE-BODY シーケンスの符号全体を通して演算されます。 user-data このフィールドは、KRB_SAFE と KRB_PRIV メッセージの一部分で、送信者から受領者に渡されたアプリケーション固有のデータを含んでいます。 timestamp このフィールドは、KRB_SAFE と KRB_PRIV メッセージの一部分です。この内容は、メッセージの送信者が知っている現在の時刻です。タイムスタンプをチェックすることで、メッセージの受領者は、それがリプレイではなく最近生成されたものであることが確認できます。 usec このフィールドは、KRB_SAFE と KRB_PRIV ヘッダーの一部分です。これは、タイムスタンプのマイクロ秒部分を含んでいます。 seq-number このフィールドについては、5.3.2 節において説明しています。 s-address このフィールドは、メッセージの送信者が使用するアドレスを指定します。 r-address このフィールドは、メッセージの受領者が使用するアドレスを指定します。このフィールドは、使用方法 (ブロードキャスト プロトコルなど) によっては省略できますが、受領者はそのようなメッセージを任意に拒否できます。 このフィールドは s-address とともに使用して、正しくない受領者に間違ってまたは悪意で送信されたメッセージを検出できます。
この節においては、安全にそしてプライベートにメッセージをピアに送信するのに、アプリケーションのどちらの側 (クライアントまたはサーバー) からも使用できるメッセージの形式を指定します。ここでは、セッション鍵がすでに交換されていると仮定しています (たとえば、KRB_AP_REQ/KRB_AP_REP メッセージを使用して)。
KRB_PRIV メッセージは、セッション鍵に暗号化されたユーザー データを含んでいます。メッセージ フィールドを以下に示します。：
KRB-PRIV ::= [APPLICATION 21] SEQUENCE {
pvno[0] INTEGER,
msg-type[1] INTEGER,
enc-part[3] EncryptedData
}
EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE {
user-data[0] OCTET STRING,
timestamp[1] KerberosTime OPTIONAL,
usec[2] INTEGER OPTIONAL,
seq-number[3] INTEGER OPTIONAL,
s-address[4] HostAddress, -- 送信者のアドレス
r-address[5] HostAddress OPTIONAL
-- 受領者のアドレス
}
注意： EncASRepPart では、メッセージの暗号化部分のアプリケーション コードは、メッセージが正しく復号されたことを確認する追加チェックを提供します。
pvno and msg-type これらのフィールドについては、5.4.1 節において説明しています。msg-type は、KRB_PRIV です。 enc-part このフィールドは、セッション鍵で暗号化された EncKrbPrivPart シーケンスの符号化を保持します (使用している暗号化方式がサポートしている 場合、暗号化プロシージャに初期化ベクタを渡して、適切な暗号チェーン化を実行できます。初期化ベクタは、以前の KRB_PRIV メッセージの暗号文の最後のブロックから取り出されますが、そのような初期化ベクタを使用するかどうかはアプリケーションが選択する内容です。省略した 場合、暗号化アルゴリズムのデフォルトの初期化ベクタが使用されます)。この暗号化された符合は、KRB-PRIV メッセージの enc-part フィールドで使用されます。 暗号文の形式については、第 6 章を参照してください。
user-data、timestamp、
usec、s-address、r-addressこれらのフィールドについては、5.6.1 節において説明しています。 seq-number このフィールドについては、5.3.2 節において説明しています。
この節においては、あるプリンシパルから他のプリンシパルに Kerberos の信任状を送信するのに使用できるメッセージの形式を指定しています。チケットを転送したり、従属サーバーにプロキシを提供するのに、できるだけアプリケーションが共通したメカニズムを使用できるようにここで取り上げています。ここでは、セッション鍵が KRB_AP_REQ/KRB_AP_REP メッセージを使用してすでに交換されていると想定しています。
KRB_CRED メッセージは、送信するチケットのシーケンスとチケットを使用するのに必要な情報を含んでいます。これにはそれぞれのセッション鍵も含まれています。チケットを使用するのに必要な情報は、以前に交換した暗号化鍵で暗号化されています。メッセージ フィールドを以下に示します。
KRB-CRED ::= [APPLICATION 22] SEQUENCE { pvno[0] INTEGER, msg-type[1] INTEGER, -- KRB_CRED tickets[2] SEQUENCE OF Ticket, enc-part[3] EncryptedData } EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { ticket-info[0] SEQUENCE OF KrbCredInfo, nonce[1] INTEGER OPTIONAL, timestamp[2] KerberosTime OPTIONAL, usec[3] INTEGER OPTIONAL, s-address[4] HostAddress OPTIONAL, r-address[5] HostAddress OPTIONAL } KrbCredInfo ::= SEQUENCE { key[0] EncryptionKey, prealm[1] Realm OPTIONAL, pname[2] PrincipalName OPTIONAL, flags[3] TicketFlags OPTIONAL, authtime[4] KerberosTime OPTIONAL, starttime[5] KerberosTime OPTIONAL, endtime[6] KerberosTime OPTIONAL renew-till[7] KerberosTime OPTIONAL, srealm[8] Realm OPTIONAL, sname[9] PrincipalName OPTIONAL, caddr[10] HostAddresses OPTIONAL }
pvno 、msg-type これらのフィールドについては、5.4.1 節において説明しています。msg-type は、KRB_CRED です。 tickets これらは、意図した受領者が特別に使えるように KDC から取得したチケットです。連続したチケットは、KRB-CRED メッセージの enc-part の対応する KrbCredInfo シーケンスでペアにされます。 enc-part このフィールドは、送信者と意図した受領者間で共有しているセッション鍵で暗号化された、EncKrbCredPart シーケンスの符合を保持します。この暗号化された符合は、KRB-CRED メッセージの enc-part フィールドで使用されます。暗号文の形式については、第 6 章を参照してください。 nonce 実践的であれば、アプリケーションはメッセージの受領で生成された nonce を含めることを要求できます。同じ値をメッセージ内の nonce として含めると、メッセージが新しいもので、攻撃者によってリプレイされていない証拠が提供されます。nonce は絶対に再使用してはいけません。 これは、メッセージの受領者がランダムに生成し、アプリケーション固有の方法でメッセージの送信者に提供する必要があります。
timestamp、usec これらのフィールドは、KRB-CRED メッセージが生成された時刻を指定します。この時刻は、メッセージが新しいものであることを保証します。 s-address および r-address これらのフィールドについては、5.6.1 節において説明しています。これらは、KRB-CRED メッセージの 完全性をさらに保証するために、オプションで使用します。 key このフィールドは、KRB-CRED メッセージで渡された対応するチケット内に存在し、送信者から意図した受領者にセッション鍵を渡すのに使用されます。このフィールドの符合については、6.2 節において説明しています。 以下のフィールドはオプションです。存在する場合、リモート チケット ファイル内の信任状と関連付けることができます。省略されている場合、信任状の受領者がすでにこれらの値を知っていると想定できます。
prealm、pname 代理プリンシパル識別の名前とレルムです。 flags、authtime、
starttime、endtime、
renew-till、srealm、
sname、caddrこれらのフィールドは、チケット フィールドにあるチケットに対応するフィールドの値を含んでいます。 フィールドの説明は、KDC-REP メッセージと同じです。
この節では、KRB_ERROR メッセージの形式を指定します。メッセージに含まれているフィールドは、エラーの情報をできる限り多く返すように考慮されています。フィールドが要求するすべての情報を、すべてのタイプのエラーで利用できるわけではありません。メッセージが作成されたときに適切な情報が取得できない場合、対応するフィールドはメッセージから省略されます。
KRB_ERROR メッセージは、暗号化で保護されていないため、侵入者がメッセージを合成したり修正することは可能です。特に、クライアントは、このメッセージ内のいかなるフィールドも、システム クロックの設定や、新しい認証子の生成などの安全上重要な目的で使用してはいけません。障害がおきた場合、その理由をユーザーに知らせために、このメッセージは役に立ちます。
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
}
pvno、msg-type これらのフィールドについては、5.4.1 節において説明しています。msg-type は、KRB_ERROR です。 ctime このフィールドについては、5.4.1 節において説明しています。 cusec このフィールドについては、5.4.2 節において説明しています。 stime このフィールドは、サーバーの現在の時刻を含んでいます。時刻のタイプは、KerberosTime です。 susec このフィールドは、サーバーのタイムスタンプのマイクロ秒部分を含んでいます。値の範囲は 0 〜 999 です。このフィールドは、stime とともに表示されます。適度に正確なタイムスタンプを指定するのに、この 2つのフィールドが使用されます。 error-code このフィールドは、Kerberos が返したエラー コードを含んでいます。または、要求が失敗した場合、サーバーが返したエラー コードを含んでいます。このフィールドの値を解釈するには、第 8 章のエラー コードの一覧を参照してください。エラー メッセージを表示するためには、できるだけ実装が各国語言語をサポートするようにしてください。 crealm、cname、
srealm、snameこれらのフィールドについては、5.3.1 節において説明しています。 e-text このフィールドは、失敗した要求で返されたエラー コードの理解に役立つ追加のテキストを含んでいます (たとえば、不明なプリンシパル名を含んでいるなど)。 e-data このフィールドは、その状態から解読したりエラーを処理するのに役立つ、アプリケーションが使用するエラーの追加データを含んでいます。errorcode が KDC_ERR_PREAUTH_REQUIRED の場合、e-data フィールドは、一連の padata フィールドの符合を含みます。 これらはそれぞれ、許容できる事前認証方式に対応し、その方式のデータをオプションで含んでいます。
METHOD-DATA ::= SEQUENCE of PA-DATA
error-code が KRB_AP_ERR_METHOD の場合、e-data フィールドは以下のシーケンスの符合を含んでいます。
METHOD-DATA ::= SEQUENCE {
method-type[0] INTEGER,
method-data[1] OCTET STRING OPTIONAL
}
method-type は、要求した代替方式を示します。method-data は、要求した追加情報を含んでいます。