Network Working Group L. Zhu
Request for Comments: 4121 K. Jaganathan
Updates: 1964 Microsoft
Category: Standards Track S. Hartman
MIT
July 2005
The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2
Kerberosバージョン5の汎用セキュリティサービスアプリケーションプログラムインタフェース（GSS-API）メカニズム：バージョン2
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (GSS-API) when using the Kerberos Version 5 mechanism.
このドキュメントは、プロトコル、手順、およびKerberosバージョン5メカニズムを使用した場合、汎用セキュリティサービスアプリケーションプログラムインタフェース（GSS-API）を実装するピアによって採用される規則を定義します。
RFC 1964 is updated and incremental changes are proposed in response to recent developments such as the introduction of Kerberos cryptosystem framework. These changes support the inclusion of new cryptosystems, by defining new per-message tokens along with their encryption and checksum algorithms based on the cryptosystem profiles.
RFC 1964が更新され、増分変更は、Kerberosの暗号フレームワークの導入として、最近の進展に応じて提案されています。これらの変更は、暗号プロファイルに基づいて自分の暗号化とチェックサムアルゴリズムと一緒にトークンごとのメッセージ新しい定義することによって、新しい暗号システムを含めることをサポートしています。
Table of Contents
目次
1. Introduction ....................................................2
2. Key Derivation for Per-Message Tokens ...........................4
3. Quality of Protection ...........................................4
4. Definitions and Token Formats ...................................5
4.1. Context Establishment Tokens ...............................5
4.1.1. Authenticator Checksum ..............................6
4.2. Per-Message Tokens .........................................9
4.2.1. Sequence Number .....................................9
4.2.2. Flags Field .........................................9
4.2.3. EC Field ...........................................10
4.2.4. Encryption and Checksum Operations .................10
4.2.5. RRC Field ..........................................11
4.2.6. Message Layouts ....................................12
4.3. Context Deletion Tokens ...................................13
4.4. Token Identifier Assignment Considerations ................13
5. Parameter Definitions ..........................................14
5.1. Minor Status Codes ........................................14
5.1.1. Non-Kerberos-specific Codes ........................14
5.1.2. Kerberos-specific Codes ............................15
5.2. Buffer Sizes ..............................................15
6. Backwards Compatibility Considerations .........................15
7. Security Considerations ........................................16
8. Acknowledgements................................................17
9. References .....................................................18
9.1. Normative References ......................................18
9.2. Informative References ....................................18
[RFC3961] defines a generic framework for describing encryption and checksum types to be used with the Kerberos protocol and associated protocols.
[RFC3961]は、Kerberosプロトコルおよび関連プロトコルで使用する暗号化とチェックサムのタイプを記述するための一般的なフレームワークを定義します。
[RFC1964] describes the GSS-API mechanism for Kerberos Version 5. It defines the format of context establishment, per-message and context deletion tokens, and uses algorithm identifiers for each cryptosystem in per-message and context deletion tokens.
[RFC1964]はケルベロスバージョン5のためのGSS-API機構を説明はごとメッセージおよびコンテキスト削除トークン、コンテキスト確立のフォーマットを定義し、そしてメッセージごと、コンテキスト削除トークン内の各暗号アルゴリズム識別子を使用します。
The approach taken in this document obviates the need for algorithm identifiers. This is accomplished by using the same encryption algorithm, specified by the crypto profile [RFC3961] for the session key or subkey that is created during context negotiation, and its required checksum algorithm. Message layouts of the per-message tokens are therefore revised to remove algorithm indicators and to add extra information to support the generic crypto framework [RFC3961].
この文書で撮影したアプローチは、アルゴリズム識別子を不要にします。これは、コンテキストのネゴシエーション、およびその必要なチェックサムアルゴリズム中に作成されたセッションキーまたはサブキーの暗号プロフィール[RFC3961]で指定された同じ暗号化アルゴリズムを使用することによって達成されます。メッセージごとのトークンのメッセージのレイアウトは、そのためのアルゴリズムの指標を削除すると、一般的な暗号化フレームワーク[RFC3961]をサポートするために追加の情報を追加するために改訂されています。
Tokens transferred between GSS-API peers for security context establishment are also described in this document. The data elements exchanged between a GSS-API endpoint implementation and the Kerberos Key Distribution Center (KDC) [RFC4120] are not specific to GSS-API usage and are therefore defined within [RFC4120] rather than this specification.
セキュリティコンテキスト確立のためのGSS-APIピア間で転送トークンはまた、このドキュメントで説明されています。 GSS-APIエンドポイントの実装およびKerberosキー配布センター（KDC）[RFC4120]の間で交換されるデータ要素は、GSS-APIの使用に固有のものではなく、従って、むしろ本明細書に比べ[RFC4120]内で定義されています。
The new token formats specified in this document MUST be used with all "newer" encryption types [RFC4120] and MAY be used with encryption types that are not "newer", provided that the initiator and acceptor know from the context establishment that they can both process these new token formats.
この文書で指定された新しいトークン形式は、すべての「新しい」暗号化タイプ[RFC4120]で使用する必要があり、「新しい」ではない暗号化タイプで使用でき、彼らは両方のことを、イニシエータとアクセプターは、コンテキストの確立から知っていることを提供しましたこれらの新しいトークン形式を処理します。
"Newer" encryption types are those which have been specified along with or since the new Kerberos cryptosystem specification [RFC3961], as defined in section 3.1.3 of [RFC4120]. The list of not-newer encryption types is as follows [RFC3961]:
「新しい」暗号化の種類は、[RFC4120]のセクション3.1.3で定義されるように、一緒に又は新しいケルベロス暗号仕様[RFC3961]以降に指定されているものです。 [RFC3961]を次のようにない、新しい暗号化タイプのリストは、次のとおりです。
Encryption Type Assigned Number
----------------------------------------------
des-cbc-crc 1
des-cbc-md4 2
des-cbc-md5 3
des3-cbc-md5 5
des3-cbc-sha1 7
dsaWithSHA1-CmsOID 9
md5WithRSAEncryption-CmsOID 10
sha1WithRSAEncryption-CmsOID 11
rc2CBC-EnvOID 12
rsaEncryption-EnvOID 13
rsaES-OAEP-ENV-OID 14
des-ede3-cbc-Env-OID 15
des3-cbc-sha1-kd 16
rc4-hmac 23
Conventions used in this document
この文書で使用されている表記
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The term "little-endian order" is used for brevity to refer to the least-significant-octet-first encoding, while the term "big-endian order" is for the most-significant-octet-first encoding.
用語「ビッグエンディアン順序は、」最上位オクテット - 最初の符号化されながら、用語「リトルエンディアン順序は、」、最下位オクテット - 最初のエンコーディングを参照するために簡潔にするために使用されます。
To limit the exposure of a given key, [RFC3961] adopted "one-way" "entropy-preserving" derived keys, from a base key or protocol key, for different purposes or key usages.
所与のキーの露出を制限するために、[RFC3961]は異なる目的やキー用途のための基本キーまたはプロトコルキーから、「一方向」「エントロピー保存」導出鍵を採用しました。
This document defines four key usage values below that are used to derive a specific key for signing and sealing messages from the session key or subkey [RFC4120] created during the context establishment.
この文書では、署名とコンテキスト確立中に作成されたセッションキーまたはサブキー[RFC4120]からメッセージをシールするための特定のキーを導出するために使用されるの下に4つの主要な使用値を定義します。
Name Value
-------------------------------------
KG-USAGE-ACCEPTOR-SEAL 22
KG-USAGE-ACCEPTOR-SIGN 23
KG-USAGE-INITIATOR-SEAL 24
KG-USAGE-INITIATOR-SIGN 25
When the sender is the context acceptor, KG-USAGE-ACCEPTOR-SIGN is used as the usage number in the key derivation function for deriving keys to be used in MIC tokens (as defined in section 4.2.6.1). KG-USAGE-ACCEPTOR-SEAL is used for Wrap tokens (as defined in section 4.2.6.2). Similarly, when the sender is the context initiator, KG-USAGE-INITIATOR-SIGN is used as the usage number in the key derivation function for MIC tokens, while KG-USAGE-INITIATOR-SEAL is used for Wrap tokens. Even if the Wrap token does not provide for confidentiality, the same usage values specified above are used.
送信側はコンテキストアクセプタである場合、KG-USAGE受容-SIGNは、MICトークン（セクション4.2.6.1で定義されるように）で使用する鍵を導出するための鍵導出関数に使用数として使用されます。 （セクション4.2.6.2で定義されるように）KG-利用アクセプタシールはラップトークンのために使用されます。送信側はコンテキスト開始剤である場合KG-利用開始剤シールがラップトークンを用いているが、同様に、KG-USAGEイニシエータ-SIGNは、MICトークンのキー導出関数に使用数として使用されます。ラップトークンは機密保持のために提供していない場合であっても、上記の指定された同じ使用値が使用されています。
During the context initiation and acceptance sequence, the acceptor MAY assert a subkey in the AP-REP message. If the acceptor asserts a subkey, the base key is the acceptor-asserted subkey and subsequent per-message tokens MUST be flagged with "AcceptorSubkey", as described in section 4.2.2. Otherwise, if the initiator asserts a subkey in the AP-REQ message, the base key is this subkey; if the initiator does not assert a subkey, the base key is the session key in the service ticket.
コンテキストの起動と受け入れシーケンスの間に、アクセプターは、AP-REPメッセージ内のサブキーを主張することができます。アクセプターがサブキーをアサートした場合、ベースキーは、セクション4.2.2に記載したように、アクセプタアサートサブキーおよびその後のメッセージごとのトークンが、「AcceptorSubkey」とフラグを立てなければならないです。イニシエータは、AP-REQメッセージ内のサブキーをアサートそうでない場合、ベースキーは、このサブキーです。イニシエータがサブキーをアサートしない場合は、ベース・キーは、サービスチケットのセッション鍵です。
The GSS-API specification [RFC2743] provides Quality of Protection (QOP) values that can be used by applications to request a certain type of encryption or signing. A zero QOP value is used to indicate the "default" protection; applications that do not use the default QOP are not guaranteed to be portable across implementations, or even to inter-operate with different deployment configurations of the same implementation. Using a different algorithm than the one for which the key is defined may not be appropriate. Therefore, when the new method in this document is used, the QOP value is ignored.
GSS-API仕様[RFC2743]は、暗号化または署名の特定のタイプを要求するためにアプリケーションによって使用することができる保護品質（QOP）値を提供します。ゼロQOP値が「デフォルト」の保護を示すために使用されます。デフォルトのQOPを使用しないアプリケーションを実装間、または同じ実装のさまざまな展開構成と相互運用への移植性が保証されていません。キーが定義されているものとは異なるアルゴリズムを使用することは適切ではないかもしれません。このドキュメントの新しいメソッドを使用するときため、QOP値は無視されます。
The encryption and checksum algorithms in per-message tokens are now implicitly defined by the algorithms associated with the session key or subkey. Therefore, algorithm identifiers as described in [RFC1964] are no longer needed and are removed from the new token headers.
メッセージごとのトークンでの暗号化とチェックサムアルゴリズムは今暗黙的にセッションキーまたはサブキーに関連したアルゴリズムによって定義されています。したがって、[RFC1964]に記載されているようにアルゴリズム識別子は、もはや必要とされないと、新しいトークンヘッダから除去されます。
This section provides terms and definitions, as well as descriptions for tokens specific to the Kerberos Version 5 GSS-API mechanism.
このセクションでは、Kerberosバージョン5 GSS-APIメカニズムに固有のトークンのための用語と定義、などについて説明します。
All context establishment tokens emitted by the Kerberos Version 5 GSS-API mechanism SHALL have the framing described in section 3.1 of [RFC2743], as illustrated by the following pseudo-ASN.1 structures:
Kerberosバージョン5 GSS-API機構によって放出されるすべてのコンテキスト確立トークンは以下の擬似ASN.1構造によって示されるように、[RFC2743]のセクション3.1に記載さフレーミングを有するものとします。
GSS-API DEFINITIONS ::=
BEGIN
ベギン
MechType ::= OBJECT IDENTIFIER
-- representing Kerberos V5 mechanism
GSSAPI-Token ::=
-- option indication (delegation, etc.) indicated within
-- mechanism-specific token
[APPLICATION 0] IMPLICIT SEQUENCE {
thisMech MechType,
innerToken ANY DEFINED BY thisMech
-- contents mechanism-specific
-- ASN.1 structure not required
}
END
終わり
The innerToken field starts with a two-octet token-identifier (TOK_ID) expressed in big-endian order, followed by a Kerberos message.
innerTokenフィールドは、2オクテットのトークン識別子（TOK_ID）で始まるケルベロスメッセージに続く、ビッグエンディアン順で発現。
Following are the TOK_ID values used in the context establishment tokens:
以下は、コンテキスト確立トークンに使用されるTOK_ID値です。
Token TOK_ID Value in Hex
-----------------------------------------
KRB_AP_REQ 01 00
KRB_AP_REP 02 00
KRB_ERROR 03 00
Where Kerberos message KRB_AP_REQUEST, KRB_AP_REPLY, and KRB_ERROR are defined in [RFC4120].
ケルベロスメッセージKRB_AP_REQUEST、KRB_AP_REPLY、及びKRB_ERRORは[RFC4120]で定義されます。
If an unknown token identifier (TOK_ID) is received in the initial context establishment token, the receiver MUST return GSS_S_CONTINUE_NEEDED major status, and the returned output token MUST contain a KRB_ERROR message with the error code KRB_AP_ERR_MSG_TYPE [RFC4120].
未知のトークン識別子（TOK_ID）が初期コンテキスト確立トークンに受信された場合、受信機はGSS_S_CONTINUE_NEEDED主要なステータスを返さなければならない、と返される出力トークンはエラーコードKRB_AP_ERR_MSG_TYPE [RFC4120]とKRB_ERRORメッセージを含まなければなりません。
The authenticator in the KRB_AP_REQ message MUST include the optional sequence number and the checksum field. The checksum field is used to convey service flags, channel bindings, and optional delegation information.
KRB_AP_REQメッセージでオーセンティケータは、オプションのシーケンス番号およびチェックサムフィールドを含まなければなりません。チェックサムフィールドは、サービスフラグ、チャネルバインディング、およびオプションの委任情報を伝えるために使用されます。
The checksum type MUST be 0x8003. When delegation is used, a ticket-granting ticket will be transferred in a KRB_CRED message. This ticket SHOULD have its forwardable flag set. The EncryptedData field of the KRB_CRED message [RFC4120] MUST be encrypted in the session key of the ticket used to authenticate the context.
チェックサムタイプは0x8003でなければなりません。委任を使用する場合は、チケット認可チケットがKRB_CREDメッセージに転送されます。このチケットは、その転送可能フラグが設定されているべきです。 KRB_CREDメッセージ[RFC4120]のはEncryptedDataフィールドには、コンテキストを認証するために使用されるチケットのセッション鍵で暗号化されなければなりません。
The authenticator checksum field SHALL have the following format:
オーセンティケータのチェックサムフィールドは、次の形式を持っていなければなりません。
Octet Name Description
-----------------------------------------------------------------
0..3 Lgth Number of octets in Bnd field; Represented
in little-endian order; Currently contains
hex value 10 00 00 00 (16).
4..19 Bnd Channel binding information, as described in
section 4.1.1.2.
20..23 Flags Four-octet context-establishment flags in
little-endian order as described in section
4.1.1.1.
24..25 DlgOpt The delegation option identifier (=1) in
little-endian order [optional]. This field
and the next two fields are present if and
only if GSS_C_DELEG_FLAG is set as described
in section 4.1.1.1.
26..27 Dlgth The length of the Deleg field in
little-endian order [optional].
28..(n-1) Deleg A KRB_CRED message (n = Dlgth + 28)
[optional].
n..last Exts Extensions [optional].
The length of the checksum field MUST be at least 24 octets when GSS_C_DELEG_FLAG is not set (as described in section 4.1.1.1), and at least 28 octets plus Dlgth octets when GSS_C_DELEG_FLAG is set. When
チェックサム・フィールドの長さは（セクション4.1.1.1に記載されているように）GSS_C_DELEG_FLAGが設定されていない、少なくとも28オクテットプラスDlgthオクテットがGSS_C_DELEG_FLAGが設定されているときに、少なくとも24個のオクテットでなければなりません。いつ
GSS_C_DELEG_FLAG is set, the DlgOpt, Dlgth, and Deleg fields of the checksum data MUST immediately follow the Flags field. The optional trailing octets (namely the "Exts" field) facilitate future extensions to this mechanism. When delegation is not used, but the Exts field is present, the Exts field starts at octet 24 (DlgOpt, Dlgth and Deleg are absent).
GSS_C_DELEG_FLAGはすぐにFlagsフィールドに従わなければならない、チェックサムデータのDlgOpt、Dlgth、およびDelegフィールドを設定されています。オプションの末尾のオクテット（すなわち「EXTS」フィールド）は、このメカニズムへの将来の拡張を容易にします。委任を使用するが、EXTSフィールドが存在していない場合、EXTSフィールドをオクテット24から始まる（DlgOpt、DlgthとDelegは存在しません）。
Initiators that do not support the extensions MUST NOT include more than 24 octets in the checksum field (when GSS_C_DELEG_FLAG is not set) or more than 28 octets plus the KRB_CRED in the Deleg field (when GSS_C_DELEG_FLAG is set). Acceptors that do not understand the
拡張をサポートしていません開始剤は、（GSS_C_DELEG_FLAGが設定されていない場合）、または28以上のオクテットプラス（GSS_C_DELEG_FLAGが設定されている）DelegフィールドにKRB_CREDチェックサムフィールドに24個の以上のオクテットを含んではいけません。理解していないアクセプター
Extensions MUST ignore any octets past the Deleg field of the checksum data (when GSS_C_DELEG_FLAG is set) or past the Flags field of the checksum data (when GSS_C_DELEG_FLAG is not set).
拡張機能は、（GSS_C_DELEG_FLAGが設定されている）チェックサムデータのDelegフィールド過去の任意のオクテットを無視するか（GSS_C_DELEG_FLAGが設定されていない）チェックサムデータのFlagsフィールド過去なければなりません。
The checksum "Flags" field is used to convey service options or extension negotiation information.
チェックサム「フラグ」フィールドは、サービスオプションや拡張折衝情報を伝えるために使用されます。
The following context establishment flags are defined in [RFC2744].
次のコンテキスト確立フラグは[RFC2744]で定義されています。
Flag Name Value
---------------------------------
GSS_C_DELEG_FLAG 1
GSS_C_MUTUAL_FLAG 2
GSS_C_REPLAY_FLAG 4
GSS_C_SEQUENCE_FLAG 8
GSS_C_CONF_FLAG 16
GSS_C_INTEG_FLAG 32
Context establishment flags are exposed to the calling application. If the calling application desires a particular service option, then it requests that option via GSS_Init_sec_context() [RFC2743]. If the corresponding return state values [RFC2743] indicate that any of the above optional context level services will be active on the context, the corresponding flag values in the table above MUST be set in the checksum Flags field.
コンテキスト確立フラグは、呼び出し元のアプリケーションにさらされています。呼び出し側のアプリケーションが特定のサービスオプションを希望する場合、それはもしGSS_Init_sec_context（）[RFC2743]を経由してそのオプションを要求します。対応する戻り状態値[RFC2743]は、上記任意のコンテキストレベルのサービスのいずれかが文脈上でアクティブになることを示している場合、テーブル内の対応するフラグの値は、上記のチェックサムフラグフィールドに設定されなければなりません。
Flag values 4096..524288 (2^12, 2^13, ..., 2^19) are reserved for use with legacy vendor-specific extensions to this mechanism.
フラグ値は4096..524288（^ 12 2、2 ^ 13、...、2 ^ 19）は、この機構に従来のベンダー固有の拡張子の使用のために予約されています。
All other flag values not specified herein are reserved for future use. Future revisions of this mechanism may use these reserved flags and may rely on implementations of this version to not use such flags in order to properly negotiate mechanism versions. Undefined flag values MUST be cleared by the sender, and unknown flags MUST be ignored by the receiver.
ここ指定されていない他のすべてのフラグ値は、将来の使用のために予約されています。このメカニズムの今後の改正は、これらの予約済みのフラグを使用することができ、適切に機構のバージョンを交渉するために、このようなフラグを使用しないように、このバージョンの実装に依存してもよいです。未定義のフラグ値は、送信者によってクリアされなければならない、そして未知のフラグは受信機で無視しなければなりません。
These tags are intended to be used to identify the particular communications channel for which the GSS-API security context establishment tokens are intended, thus limiting the scope within which an intercepted context establishment token can be reused by an attacker (see [RFC2743], section 1.1.6).
これらのタグは、このよう傍受コンテキスト確立トークンが攻撃者によって再使用可能な有効範囲を制限する、GSS-APIセキュリティコンテキスト確立トークンが意図される特定の通信チャネルを識別するために使用されることが意図される（[RFC2743]を参照してください1.1.6）。
When using C language bindings, channel bindings are communicated to the GSS-API using the following structure [RFC2744]:
C言語のバインディングを使用する場合、チャネルバインディングは、以下の構造[RFC2744]を使用して、GSS-APIに伝達されます。
typedef struct gss_channel_bindings_struct {
OM_uint32 initiator_addrtype;
gss_buffer_desc initiator_address;
OM_uint32 acceptor_addrtype;
gss_buffer_desc acceptor_address;
gss_buffer_desc application_data;
} *gss_channel_bindings_t;
The member fields and constants used for different address types are defined in [RFC2744].
異なるアドレスタイプのために使用されるメンバフィールドおよび定数は[RFC2744]で定義されています。
The "Bnd" field contains the MD5 hash of channel bindings, taken over all non-null components of bindings, in order of declaration. Integer fields within channel bindings are represented in little-endian order for the purposes of the MD5 calculation.
「無買デー」フィールドは、宣言の順番で、バインディングのすべての非ヌル要素を引き継いで、チャネルバインディングのMD5ハッシュが含まれています。チャネルバインディング内の整数フィールドは、MD5の計算の目的のためにリトルエンディアンの順序で表されます。
In computing the contents of the Bnd field, the following detailed points apply:
無買デーフィールドの内容を計算する際に、以下の詳細な点が適用されます。
(1) For purposes of MD5 hash computation, each integer field and input length field SHALL be formatted into four octets, using little-endian octet ordering.
（1）MD5ハッシュ計算の目的のために、各整数フィールドと入力の長さフィールドは、リトルエンディアンオクテットの順序を使用して、4つのオクテットにフォーマットすることがSHALL。
(2) All input length fields within gss_buffer_desc elements of a gss_channel_bindings_struct even those which are zero-valued, SHALL be included in the hash calculation. The value elements of gss_buffer_desc elements SHALL be dereferenced, and the resulting data SHALL be included within the hash computation, only for the case of gss_buffer_desc elements having non-zero length specifiers.
（2）もgss_channel_bindings_structのれるgss_buffer_desc要素内のすべての入力の長さフィールドがゼロ値であるものを、ハッシュ計算に含めなければなりません。れるgss_buffer_desc要素の値要素を逆参照するものとし、得られたデータは、非ゼロ長指定子を有するれるgss_buffer_desc要素の場合の、ハッシュ計算の中に含まれていなければなりません。
(3) If the caller passes the value GSS_C_NO_BINDINGS instead of a valid channel binding structure, the Bnd field SHALL be set to 16 zero-valued octets.
発呼者が代わりに有効なチャネル結合構造の値GSS_C_NO_BINDINGSをパスした場合（3）、無買デーフィールドは16ゼロ値のオクテットに設定されなければなりません。
If the caller to GSS_Accept_sec_context [RFC2743] passes in GSS_C_NO_CHANNEL_BINDINGS [RFC2744] as the channel bindings, then the acceptor MAY ignore any channel bindings supplied by the initiator, returning success even if the initiator did pass in channel bindings.
場合gss_accept_sec_context [RFC2743]に発信者がチャンネルバインディングとしてGSS_C_NO_CHANNEL_BINDINGS [RFC2744]に合格した場合、イニシエータは、チャネルバインディングを渡した場合でも、その後、アクセプターは成功を返し、イニシエータにより供給される任意のチャネルバインディングを無視してもよいです。
If the application supplies, in the channel bindings, a buffer with a length field larger than 4294967295 (2^32 - 1), the implementation of this mechanism MAY choose to reject the channel bindings altogether, using major status GSS_S_BAD_BINDINGS [RFC2743]. In any case, the size of channel-binding data buffers that can be used (interoperable, without extensions) with this specification is limited to 4294967295 octets.
チャネルバインディングのアプリケーション用品、4294967295（2 ^ 32 1 - ）よりも大きい長さフィールドとバッファ場合、このメカニズムの実装では、主要な状態GSS_S_BAD_BINDINGS [RFC2743]を使用して、完全にチャネルバインディングを拒否することを選ぶかもしれ。いずれの場合においても、本明細書で（拡張なしに、相互運用性）を使用することができるチャネル結合データバッファのサイズは4294967295オクテットに限定されます。
Two classes of tokens are defined in this section: (1) "MIC" tokens, emitted by calls to GSS_GetMIC() and consumed by calls to GSS_VerifyMIC(), and (2) "Wrap" tokens, emitted by calls to GSS_Wrap() and consumed by calls to GSS_Unwrap().
トークンの二つのクラスが、このセクションで定義されている：（1）にGSS_Wrapの呼び出しによって放出されたGSS_VerifyMIC（）、および（2）「ラップ」トークンの呼び出しによってGSS_GetMIC（）への呼び出しによって放出され、消費「MIC」トークン、、（）そして、はgss_unwrap（）への呼び出しによって消費。
These new per-message tokens do not include the generic GSS-API token framing used by the context establishment tokens. These new tokens are designed to be used with newer crypto systems that can have variable-size checksums.
これらの新しいメッセージごとのトークンは、コンテキスト確立トークンで使用される一般的なGSS-APIトークンのフレーミングが含まれていません。これらの新しいトークンは、可変サイズのチェックサムを持つことができ、新しい暗号システムで使用されるように設計されています。
To distinguish intentionally-repeated messages from maliciously-replayed ones, per-message tokens contain a sequence number field, which is a 64 bit integer expressed in big-endian order. After sending a GSS_GetMIC() or GSS_Wrap() token, the sender's sequence numbers SHALL be incremented by one.
悪意を持って、再生のものから意図的に反復メッセージを区別するために、メッセージごとのトークンは、ビッグエンディアン順で表現さ64ビットの整数であるシーケンス番号フィールドを含みます。 GSS_GetMIC（）またはにGSS_Wrap（）トークンを送信した後、送信者のシーケンス番号は1ずつ増加するものとします。
The "Flags" field is a one-octet integer used to indicate a set of attributes for the protected message. For example, one flag is allocated as the direction-indicator, thus preventing the acceptance of the same message sent back in the reverse direction by an adversary.
「フラグ」フィールドには、保護されたメッセージのための一連の属性を示すために使用される1オクテットの整数です。例えば、1つのフラグは、このように敵によって逆方向に送り返さ同じメッセージの受け入れを防止する、方向指示器として割り当てられます。
The meanings of bits in this field (the least significant bit is bit 0) are as follows:
次のようにこのフィールド内のビットの意味は（最下位ビットがビット0である）です。
Bit Name Description
--------------------------------------------------------------
0 SentByAcceptor When set, this flag indicates the sender
is the context acceptor. When not set,
it indicates the sender is the context
initiator.
1 Sealed When set in Wrap tokens, this flag
indicates confidentiality is provided
for. It SHALL NOT be set in MIC tokens.
2 AcceptorSubkey A subkey asserted by the context acceptor
is used to protect the message.
The rest of available bits are reserved for future use and MUST be cleared. The receiver MUST ignore unknown flags.
利用可能なビットの残りは将来の使用のために予約されており、きれいにしなければなりません。受信機は、未知のフラグを無視しなければなりません。
The "EC" (Extra Count) field is a two-octet integer field expressed in big-endian order.
「EC」（エクストラカウント）フィールドには、ビッグエンディアン順で表される2つのオクテットの整数フィールドです。
In Wrap tokens with confidentiality, the EC field SHALL be used to encode the number of octets in the filler, as described in section 4.2.4.
セクション4.2.4に記載したように、機密性を有するラップトークンにおいて、ECフィールドは、充填剤のオクテットの数を符号化するために使用されなければなりません。
In Wrap tokens without confidentiality, the EC field SHALL be used to encode the number of octets in the trailing checksum, as described in section 4.2.4.
セクション4.2.4に記載のように機密性なしにラップトークンにおいて、ECフィールドは、後続のチェックサムのオクテットの数を符号化するために使用されなければなりません。
The encryption algorithms defined by the crypto profiles provide for integrity protection [RFC3961]. Therefore, no separate checksum is needed.
暗号プロファイルによって定義された暗号化アルゴリズムは、完全性保護[RFC3961]を提供します。そのため、個別のチェックサムは必要ありません。
The result of decryption can be longer than the original plaintext [RFC3961] and the extra trailing octets are called "crypto-system residue" in this document. However, given the size of any plaintext data, one can always find a (possibly larger) size, such that when padding the to-be-encrypted text to that size, there will be no crypto-system residue added [RFC3961].
解読の結果は、元の平文[RFC3961]、余分な末尾のオクテットは、この文書の「暗号システム残基」と呼ばれているよりも長くすることができます。しかし、任意の平文データのサイズ与えられ、一つは常に（おそらく大きな）サイズを見つけることができ、その大きさに被暗号文をパディングするとき、加えない暗号システム残基[RFC3961]は存在しないようにします。
In Wrap tokens that provide for confidentiality, the first 16 octets of the Wrap token (the "header", as defined in section 4.2.6), SHALL be appended to the plaintext data before encryption. Filler octets MAY be inserted between the plaintext data and the "header." The values and size of the filler octets are chosen by implementations, such that there SHALL be no crypto-system residue present after the decryption. The resulting Wrap token is {"header" | encrypt(plaintext-data | filler | "header")}, where encrypt() is the encryption operation (which provides for integrity protection) defined in the crypto profile [RFC3961], and the RRC field (as defined in section 4.2.5) in the to-be-encrypted header contains the hex value 00 00.
機密性を提供するラップトークンでは、（セクション4.2.6で定義される「ヘッダ」）ラップトークンの最初の16個のオクテットは、暗号化前の平文データを添付しなければなりません。フィラーオクテットは、平文データとの間に挿入することができる「ヘッダ」。フィラーオクテットの値およびサイズは、復号後に存在しない暗号システム残基があってはならないように、実装によって選択されます。得られたラップトークンは{「ヘッダ」です|セクション4.2.5で定義されている（「ヘッダ」平文データ| |フィラー）}、暗号化（）は暗号プロファイル[RFC3961]で定義された（完全性保護を提供する）暗号化操作であり、RRCフィールド（暗号化）に、暗号化され、ヘッダに進値00 00を含んでいます。
In Wrap tokens that do not provide for confidentiality, the checksum SHALL be calculated first over the to-be-signed plaintext data, and then over the first 16 octets of the Wrap token (the "header", as defined in section 4.2.6). Both the EC field and the RRC field in the token header SHALL be filled with zeroes for the purpose of calculating the checksum. The resulting Wrap token is {"header" | plaintext-data | get_mic(plaintext-data | "header")}, where get_mic() is the checksum operation for the required checksum mechanism of the chosen encryption mechanism defined in the crypto profile [RFC3961].
機密性を提供しないラップトークンでは、チェックサムは被署名された平文データに対して最初に計算し、次にセクション4.2.6で定義されるようにラップトークンの最初の16個のオクテット（「ヘッダ」、以上であること）。トークンヘッダにおけるECフィールド及びRRCフィールドの両方は、チェックサムを計算するためにゼロで充填さSHALL。得られたラップトークンは{「ヘッダ」です|平文データ| get_mic |（）get_mic暗号プロファイル[RFC3961]で定義された選択された暗号化メカニズムの必要なチェックサム機構のチェックサム動作である（平文データ「ヘッダ」）}。
The parameters for the key and the cipher-state in the encrypt() and get_mic() operations have been omitted for brevity.
暗号における鍵と暗号状態用パラメータ（）およびget_mic（）操作は、簡潔にするために省略されています。
For MIC tokens, the checksum SHALL be calculated as follows: the checksum operation is calculated first over the to-be-signed plaintext data, and then over the first 16 octets of the MIC token, where the checksum mechanism is the required checksum mechanism of the chosen encryption mechanism defined in the crypto profile [RFC3961].
チェックサム動作は最初のチェックサム機構が必要なチェックサム機構であるMICトークンの平文データを署名することから、その後、オーバー第16オクテットに渡って計算される：次のようにMICトークンため、チェックサムを計算しますクリプトプロファイル[RFC3961]で定義された選択された暗号化メカニズム。
The resulting Wrap and MIC tokens bind the data to the token header, including the sequence number and the direction indicator.
得られたラップ及びMICトークンは、シーケンス番号と方向インジケータを含む、トークンヘッダとデータを結合します。
The "RRC" (Right Rotation Count) field in Wrap tokens is added to allow the data to be encrypted in-place by existing SSPI (Security Service Provider Interface) [SSPI] applications that do not provide an additional buffer for the trailer (the cipher text after the in-place-encrypted data) in addition to the buffer for the header (the cipher text before the in-place-encrypted data). Excluding the first 16 octets of the token header, the resulting Wrap token in the previous section is rotated to the right by "RRC" octets. The net result is that "RRC" octets of trailing octets are moved toward the header.
ラップトークンの「RRC」（右回転カウント）フィールドは、データを既存のSSPI（セキュリティサービスプロバイダインタフェース）[SSPI]トレーラーのための追加のバッファを提供しないアプリケーション（でその場で暗号化することを可能にするために追加されますヘッダ（インプレースで暗号化されたデータの前に暗号文）のためにバッファに加えて、インプレースで暗号化されたデータの後に暗号文）。トークンヘッダの最初の16個のオクテットを除いて、前のセクションで得られたラップトークンは「RRC」オクテットだけ右に回転させられます。正味の結果は、後続のオクテットの「RRC」オクテットがヘッダに向かって移動されることです。
Consider the following as an example of this rotation operation: Assume that the RRC value is 3 and the token before the rotation is {"header" | aa | bb | cc | dd | ee | ff | gg | hh}. The token after rotation would be {"header" | ff | gg | hh | aa | bb | cc | dd | ee }, where {aa | bb | cc |...| hh} would be used to indicate the octet sequence.
この回転動作の例として、以下を考える：RRC値は3であり、回転前のトークンが{「ヘッダ」であると仮定する| AA | BB | CC | DD | EE | FF | GG | HH}。回転後のトークンは{「ヘッダ」であろう| FF | GG | HH | AA | BB | CC | DD | EE}、ここで、{AA | BB | CC | ... | HH}オクテットシーケンスを示すために使用されるであろう。
The RRC field is expressed as a two-octet integer in big-endian order.
RRCフィールドは、ビッグエンディアン順に2オクテットの整数として表現されます。
The rotation count value is chosen by the sender based on implementation details. The receiver MUST be able to interpret all possible rotation count values, including rotation counts greater than the length of the token.
回転カウント値は実装の詳細に基づいて、送信者によって選択されます。受信機は、トークンの長さよりも大きい回転数を含むすべての可能な回転数の値を、解釈できなければなりません。
Per-message tokens start with a two-octet token identifier (TOK_ID) field, expressed in big-endian order. These tokens are defined separately in the following sub-sections.
メッセージごとのトークンが2オクテットトークン識別子（TOK_ID）フィールドで始まり、ビッグエンディアン順で発現。これらのトークンは、以下のサブセクションで個別に定義されています。
Use of the GSS_GetMIC() call yields a token (referred as the MIC token in this document), separate from the user data being protected, which can be used to verify the integrity of that data as received. The token has the following format:
GSS_GetMIC（）呼び出しの使用は、受信したそのデータの整合性を検証するために使用することができる保護されているユーザデータとは別に（この文書でMICトークンと呼ぶ）トークンを、もたらします。トークンの形式は次のとおりです。
Octet no Name Description
--------------------------------------------------------------
0..1 TOK_ID Identification field. Tokens emitted by
GSS_GetMIC() contain the hex value 04 04
expressed in big-endian order in this
field.
2 Flags Attributes field, as described in section
4.2.2.
3..7 Filler Contains five octets of hex value FF.
8..15 SND_SEQ Sequence number field in clear text,
expressed in big-endian order.
16..last SGN_CKSUM Checksum of the "to-be-signed" data and
octet 0..15, as described in section 4.2.4.
The Filler field is included in the checksum calculation for simplicity.
フィラーフィールドは、単純化のためのチェックサムの計算に含まれています。
Use of the GSS_Wrap() call yields a token (referred as the Wrap token in this document), which consists of a descriptive header, followed by a body portion that contains either the input user data in plaintext concatenated with the checksum, or the input user data encrypted. The GSS_Wrap() token SHALL have the following format:
GSS_Wrap（）呼び出しの使用は、チェックサムと連結平文で入力されたユーザデータ、または入力のいずれかを含む本体部分、続いて記述ヘッダから成る（本文書でラップトークンと呼ぶ）トークンを、得られますユーザデータは暗号化されました。 GSS_Wrap（）トークンは次の形式を持っていなければなりません。
Octet no Name Description
--------------------------------------------------------------
0..1 TOK_ID Identification field. Tokens emitted by
GSS_Wrap() contain the hex value 05 04
expressed in big-endian order in this
field.
2 Flags Attributes field, as described in section
4.2.2.
3 Filler Contains the hex value FF.
4..5 EC Contains the "extra count" field, in big-
endian order as described in section 4.2.3.
6..7 RRC Contains the "right rotation count" in big-
endian order, as described in section
4.2.5.
8..15 SND_SEQ Sequence number field in clear text,
expressed in big-endian order.
16..last Data Encrypted data for Wrap tokens with
confidentiality, or plaintext data followed
by the checksum for Wrap tokens without
confidentiality, as described in section
4.2.4.
Context deletion tokens are empty in this mechanism. Both peers to a security context invoke GSS_Delete_sec_context() [RFC2743] independently, passing a null output_context_token buffer to indicate that no context_token is required. Implementations of GSS_Delete_sec_context() should delete relevant locally-stored context information.
コンテキスト削除トークンは、このメカニズムでは空です。セキュリティコンテキストの両方のピアにはcontext_tokenが必要とされないことを示すためにヌルoutput_context_tokenバッファを渡す、独立GSS_Delete_sec_context（）[RFC2743]を呼び出します。 GSS_Delete_sec_context（）の実装は、関連するローカルに保存されたコンテキスト情報を削除する必要があります。
Token identifiers (TOK_ID) from 0x60 0x00 through 0x60 0xFF inclusive are reserved and SHALL NOT be assigned. Thus, by examining the first two octets of a token, one can tell unambiguously if it is wrapped with the generic GSS-API token framing.
0x60から0xffまで0x60 0x00を含めてからトークン識別子（TOK_ID）が予約されており、割り当てられないものとします。それは一般的なGSS-APIトークンのフレーミングでラップされている場合このように、トークンの最初の2つのオクテットを調べることによって、一つは明確に伝えることができます。
This section defines parameter values used by the Kerberos V5 GSS-API mechanism. It defines interface elements that support portability, and assumes use of C language bindings per [RFC2744].
このセクションでは、Kerberos V5 GSS-API機構によって使用されるパラメータ値を定義します。これは、移植性をサポートするインタフェース要素を定義し、[RFC2744]あたりのC言語バインディングの使用を想定しています。
This section recommends common symbolic names for minor_status values to be returned by the Kerberos V5 GSS-API mechanism. Use of these definitions will enable independent implementers to enhance application portability across different implementations of the mechanism defined in this specification. (In all cases, implementations of GSS_Display_status() will enable callers to convert minor_status indicators to text representations.) Each implementation should make available, through include files or other means, a facility to translate these symbolic names into the concrete values that a particular GSS-API implementation uses to represent the minor_status values specified in this section.
このセクションでは、Kerberos V5 GSS-APIメカニズムによって返されるminor_status値のための共通のシンボル名をお勧めします。これらの定義を使用すると、この仕様で定義されたメカニズムの実装が異なるアプリケーションの移植性を高めるために、独立した実装を可能にします。 （全ての場合において、GSS_Display_statusの実装（）表現をテキストにminor_statusインジケータを変換するために発信者を可能にする。）各実装が利用できるようにする必要があり、スルーファイル又は他の手段を含む、特定のGSS具体的な値にこれらのシンボル名を変換する機能を-APIの実装は、このセクションで指定minor_status値を表すために使用します。
This list may grow over time and the need for additional minor_status codes, specific to particular implementations, may arise. However, it is recommended that implementations should return a minor_status value as defined on a mechanism-wide basis within this section when that code accurately represents reportable status rather than using a separate, implementation-defined code.
このリストは、時間をかけて成長する可能性や、特定の実装に固有の追加minor_statusコード、の必要性が生じる可能性があります。しかしながら、そのコードが正確ではなく別個の、実装定義コードを使用するよりも報告ステータスを表す場合、このセクション内機構全体で定義されるような実装がminor_status値を返さなければならないことが推奨されます。
GSS_KRB5_S_G_BAD_SERVICE_NAME
/* "No @ in SERVICE-NAME name string" */
GSS_KRB5_S_G_BAD_STRING_UID
/* "STRING-UID-NAME contains nondigits" */
GSS_KRB5_S_G_NOUSER
/* "UID does not resolve to username" */
GSS_KRB5_S_G_VALIDATE_FAILED
/* "Validation error" */
GSS_KRB5_S_G_BUFFER_ALLOC
/* "Couldn't allocate gss_buffer_t data" */
GSS_KRB5_S_G_BAD_MSG_CTX
/* "Message context invalid" */
GSS_KRB5_S_G_WRONG_SIZE
/* "Buffer is the wrong size" */
GSS_KRB5_S_G_BAD_USAGE
/* "Credential usage type is unknown" */
GSS_KRB5_S_G_UNKNOWN_QOP
/* "Unknown quality of protection specified" */
GSS_KRB5_S_KG_CCACHE_NOMATCH
/* "Client principal in credentials does not match
specified name" */
GSS_KRB5_S_KG_KEYTAB_NOMATCH
/* "No key available for specified service
principal" */
GSS_KRB5_S_KG_TGT_MISSING
/* "No Kerberos ticket-granting ticket available" */
GSS_KRB5_S_KG_NO_SUBKEY
/* "Authenticator has no subkey" */
GSS_KRB5_S_KG_CONTEXT_ESTABLISHED
/* "Context is already fully established" */
GSS_KRB5_S_KG_BAD_SIGN_TYPE
/* "Unknown signature type in token" */
GSS_KRB5_S_KG_BAD_LENGTH
/* "Invalid field length in token" */
GSS_KRB5_S_KG_CTX_INCOMPLETE
/* "Attempt to use incomplete security context" */
All implementations of this specification MUST be capable of accepting buffers of at least 16K octets as input to GSS_GetMIC(), GSS_VerifyMIC(), and GSS_Wrap(). They MUST also be capable of accepting the output_token generated by GSS_Wrap() for a 16K octet input buffer as input to GSS_Unwrap(). Implementations SHOULD support 64K octet input buffers, and MAY support even larger input buffer sizes.
全て本明細書の実装（GSS_GetMICへの入力として、少なくとも16Kオクテットのバッファを受け入れることができなければなりません）、GSS_VerifyMIC（）、およびにGSS_Wrap（）。それらはまた）はgss_unwrap（への入力として16Kオクテット入力バッファ用）にGSS_Wrap（によって生成されたoutput_tokenを受け入れることができなければなりません。実装は64Kオクテット入力バッファをサポートする必要があり、さらに大きな入力バッファサイズをサポートするかもしれません。
The new token formats defined in this document will only be recognized by new implementations. To address this, implementations can always use the explicit sign or seal algorithm in [RFC1964] when the key type corresponds to not "newer" enctypes. As an alternative, one might retry sending the message with the sign or seal algorithm explicitly defined as in [RFC1964]. However, this would require either the use of a mechanism such as [RFC2478] to securely negotiate the method, or the use of an out-of-band mechanism to choose the appropriate mechanism. For this reason, it is RECOMMENDED that the new token formats defined in this document SHOULD be used only if both peers are known to support the new mechanism during context negotiation because of, for example, the use of "new" enctypes.
この文書で定義された新しいトークン形式は、唯一の新しい実装によって認識されます。これに対処するために、実装は常に、[RFC1964]キータイプは対応しない「新しい」enctypesで明示的徴候またはシールアルゴリズムを使用することができます。代替として、一方が明示的に[RFC1964]のように定義された記号又はシールアルゴリズムでメッセージの送信を再試行することがあります。しかし、このような安全法、又は適切な機構を選択するアウトオブバンドメカニズムの使用を交渉するために[RFC2478]などの機構の使用のいずれかを必要とするであろう。このような理由から、それは両方のピアが原因のコンテキストのネゴシエーション中に新しいメカニズムをサポートすることが知られている場合にのみ、この文書で定義された新しいトークン形式は、例えば、使用することを推奨し、「新しい」enctypesの使用。
GSS_Unwrap() or GSS_VerifyMIC() can process a message token as follows: it can look at the first octet of the token header, and if it is 0x60, then the token must carry the generic GSS-API pseudo ASN.1 framing. Otherwise, the first two octets of the token contain the TOK_ID that uniquely identify the token message format.
次のようにはgss_unwrap（）またはGSS_VerifyMIC（）は、メッセージ・トークンを処理することができる：それはトークンヘッダの最初のオクテットで見ることができ、それは0x60である場合、トークンは、汎用GSS-API擬似ASN.1フレーミングを運ばなければなりません。そうでない場合は、トークンの最初の2つのオクテットは、一意のトークンメッセージフォーマットを識別TOK_IDを含みます。
Channel bindings are validated by the acceptor. The acceptor can ignore the channel bindings restriction supplied by the initiator and carried in the authenticator checksum, if (1) channel bindings are not used by GSS_Accept_sec_context [RFC2743], and (2) the acceptor does not prove to the initiator that it has the same channel bindings as the initiator (even if the client requested mutual authentication). This limitation should be considered by designers of applications that would use channel bindings, whether to limit the use of GSS-API contexts to nodes with specific network addresses, to authenticate other established, secure channels using Kerberos Version 5, or for any other purpose.
チャネルバインディングは、アクセプターによって検証されています。アクセプターは、（1）チャネル・バインディングを場合gss_accept_sec_context [RFC2743]で使用されていない場合、イニシエータにより供給されると認証チェックサムで運ばれるチャネルバインディングの制限を無視することができ、及び（2）受容体は、それが持っていることをイニシエータに証明しませんイニシエータと同じチャネルバインディング（クライアントが相互認証を要求された場合でも）。この制限は、特定のネットワークアドレスを持つノードにGSS-APIコンテキストの使用を制限するためにKerberosバージョン5を使用して他の確立、安全なチャンネルを認証するために、またはその他の目的のためにかどうか、チャネルバインディングを使用するアプリケーションの設計者によって考慮されるべきです。
Session key types are selected by the KDC. Under the current mechanism, no negotiation of algorithm types occurs, so server-side (acceptor) implementations cannot request that clients not use algorithm types not understood by the server. However, administrators can control what enctypes can be used for session keys for this mechanism by controlling the set of the ticket session key enctypes which the KDC is willing to use in tickets for a given acceptor principal. Therefore, the KDC could be given the task of limiting session keys for a given service to types actually supported by the Kerberos and GSSAPI software on the server. This has a drawback for cases in which a service principal name is used for both GSSAPI-based and non-GSSAPI-based communication (most notably the "host" service key), if the GSSAPI implementation does not understand (for example) AES [RFC3962], but the Kerberos implementation does. This means that AES session keys cannot be issued for that service principal, which keeps the protection of non-GSSAPI services weaker than necessary. KDC administrators desiring to limit the session key types to support interoperability with such GSSAPI implementations should carefully weigh the reduction in protection offered by such mechanisms against the benefits of interoperability.
セッションキータイプは、KDCによって選択されています。現在のメカニズムの下で、アルゴリズムの種類のないネゴシエーションが発生しないので、サーバ側（アクセプター）の実装は、クライアントが、サーバによって理解されていないアルゴリズムのタイプを使用しないように要求することができません。しかし、管理者がenctypesはKDCが所定アクセプタプリンシパルのチケットで使用する意思があるチケットセッション鍵enctypesのセットを制御することによって、この機構のためのセッションキーのために使用することができるかを制御することができます。そのため、KDCは、実際にサーバ上のKerberosとGSSAPIソフトウェアでサポートされているタイプに指定されたサービスのためのセッションキーを制限するタスクを与えられることができました。 GSSAPIの実装は、（例えば）理解していない場合、これは、AESを[サービスプリンシパル名の両方GSSAPIベースおよび非GSSAPIベースの通信（特に「ホスト」サービスキー）に用いた場合の欠点を有していますRFC3962]が、Kerberos実装はありません。これは、AESセッションキーが必要以上に弱い非GSSAPIサービスの保護を維持し、そのサービスプリンシパル、のために発行することができないことを意味します。このようGSSAPIの実装との相互運用性をサポートするためにセッションキーの種類を制限することを望むKDCの管理者は、慎重に、相互運用性の利点に対して、このようなメカニズムによって提供される保護の減少を比較検討する必要があります。
Ken Raeburn and Nicolas Williams corrected many of our errors in the use of generic profiles and were instrumental in the creation of this document.
ケン・レイバーンとニコラス・ウィリアムズは、一般的なプロファイルを使用して私たちの多くのエラーを修正し、この文書の作成に尽力しました。
The text for security considerations was contributed by Nicolas Williams and Ken Raeburn.
セキュリティ上の配慮のためのテキストは、ニコラ・ウィリアムズとケン・レイバーンによって寄贈されました。
Sam Hartman and Ken Raeburn suggested the "floating trailer" idea, namely the encoding of the RRC field.
サム・ハートマンとケンレイバーンは「浮動トレーラー」のアイデア、RRCフィールドのつまりエンコーディングを示唆しました。
Sam Hartman and Nicolas Williams recommended the replacing our earlier key derivation function for directional keys with different key usage numbers for each direction as well as retaining the directional bit for maximum compatibility.
サム・ハートマンとニコラス・ウィリアムズは、それぞれの方向に異なるキーの使用数と方向キーのために私たちの以前の鍵導出関数を置き換えるだけでなく、最大の互換性のための方向ビットを保持推奨しました。
Paul Leach provided numerous suggestions and comments.
ポール・リーチは、数多くの提案やコメントを提供しました。
Scott Field, Richard Ward, Dan Simon, Kevin Damour, and Simon Josefsson also provided valuable inputs on this document.
スコットフィールド、リチャード・ウォード、ダン・サイモン、ケビンDamour、そしてサイモンJosefsson氏はまた、この文書に貴重なインプットを提供します。
Jeffrey Hutzelman provided comments and clarifications for the text related to the channel bindings.
ジェフリーHutzelmanは、チャネルバインディングに関連したテキストのコメントと説明を提供します。
Jeffrey Hutzelman and Russ Housley suggested many editorial changes.
ジェフリーHutzelmanとラスHousleyは、多くの編集上の変更を示唆しました。
Luke Howard provided implementations of this document for the Heimdal code base, and helped inter-operability testing with the Microsoft code base, together with Love Hornquist Astrand. These experiments formed the basis of this document.
ルークハワードはHeimdalのコードベースは、このドキュメントの実装を提供し、そして一緒に愛Hornquist Astrandで、マイクロソフトのコードベースとの相互運用性テストを助けました。これらの実験は、この文書の基礎を形成しました。
Martin Rex provided suggestions of TOK_ID assignment recommendations, thus the token tagging in this document is unambiguous if the token is wrapped with the pseudo ASN.1 header.
トークンが擬似ASN.1ヘッダで包まれている場合マーチンレックスTOK_ID割り当て勧告の提案を提供し、この文書に記載されているこのようにトークンタグは明白です。
John Linn wrote the original Kerberos Version 5 mechanism specification [RFC1964], of which some text has been retained.
ジョン・リンは、いくつかのテキストが保持されているのオリジナルKerberosバージョン5メカニズム仕様[RFC1964]を、書きました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2743]リン、J.、 "ジェネリックセキュリティーサービス適用業務プログラムインタフェースバージョン2、アップデート1"、RFC 2743、2000年1月。
[RFC2744] Wray, J., "Generic Security Service API Version 2: C-bindings", RFC 2744, January 2000.
[RFC2744]レイ、J.、 "ジェネリックセキュリティサービスAPIバージョン2：C-バインディング"、RFC 2744、2000年1月。
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996.
[RFC1964]リン、J.、 "Kerberosバージョン5 GSS-APIメカニズム"、RFC 1964、1996年6月。
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, February 2005.
[RFC3961]レイバーン、K.、 "暗号化とケルベロス5チェックサムの仕様"、RFC 3961、2005年2月。
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[RFC4120]ノイマン、C.、ゆう、T.、ハルトマン、S.、およびK.レイバーン、 "ケルベロスネットワーク認証サービス（V5）"、RFC 4120、2005年7月。
[SSPI] Leach, P., "Security Service Provider Interface", Microsoft Developer Network (MSDN), April 2003.
[SSPI]リーチ、P.、 "セキュリティサービスプロバイダインタフェース" は、Microsoft Developer Network（MSDN）、2003年4月。
[RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) Encryption for Kerberos 5", RFC 3962, February 2005.
[RFC3962]レイバーン、K.、 "Kerberos 5のためのAdvanced Encryption Standard（AES）暗号化"、RFC 3962、2005年2月。
[RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API Negotiation Mechanism", RFC 2478, December 1998.
[RFC2478]ベーズ、E.およびD.ピンカス、 "単純で保護されたGSS-API交渉メカニズム"、RFC 2478、1998年12月。
Authors' Addresses
著者のアドレス
Larry Zhu One Microsoft Way Redmond, WA 98052 - USA
ラリー朱1つのマイクロソフト道、レッドモンド、WA 98052 - USA
EMail: LZhu@microsoft.com
メールアドレス：LZhu@microsoft.com
Karthik Jaganathan One Microsoft Way Redmond, WA 98052 - USA
カルティクJaganathan 1つのマイクロソフト道、レッドモンド、WA 98052 - USA
EMail: karthikj@microsoft.com
メールアドレス：karthikj@microsoft.com
Sam Hartman Massachusetts Institute of Technology 77 Massachusetts Avenue Cambridge, MA 02139 - USA
USA - テクノロジー77マサチューセッツアベニューケンブリッジ、MA 02139のサム・ハートマンマサチューセッツ工科大学
EMail: hartmans-ietf@mit.edu
メールアドレス：hartmans-ietf@mit.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。