[要約] RFC 4121は、Kerberosバージョン5のGSS-APIメカニズムのバージョン2に関する仕様です。このRFCの目的は、セキュリティアプリケーションプログラムインターフェース（GSS-API）を使用してKerberos認証を実装するための標準化と指針を提供することです。
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).
Copyright（c）The Internet Society（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 Cryptosystem Frameworkの導入などの最近の開発に応じて、増分変更が提案されています。これらの変更は、暗号化システムプロファイルに基づいて暗号化とチェックサムアルゴリズムとともに、新しいメッセージごとのトークンを定義することにより、新しい暗号システムの包含をサポートします。
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]は、Kerberosバージョン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で定義されているように、新しいKerberos Cryptosystem Specification [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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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.
「リトルエンディアン順序」という用語は、Brevityが最も重要でないオクセットファーストエンコーディングを指すために使用されますが、「Big-Endian Order」という用語は、最も重要なオクセットファーストエンコーディングのためです。
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-ACCEPTOR-SIGNは、マイクトークンで使用するキーを導出するためのキー派生関数の使用番号として使用されます（セクション4.2.6.1で定義されています）。Kg-Usage-Acceptor-Sealは、ラップトークンに使用されます（セクション4.2.6.2で定義されています）。同様に、送信者がコンテキストイニシエーターである場合、kg-usage-initiator-signは、マイクトークンのキー導出関数の使用数として使用され、kg-usage-initiator-sealはラップトークンに使用されます。ラップトークンが機密性を提供しない場合でも、上記の同じ使用値が使用されます。
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」でそれに続く1つのメッセージがフラグを立てる必要があります。それ以外の場合、イニシエーターが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メカニズムによって放出されるすべてのコンテキスト確立トークンは、以下のPseudo-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オクテットのトークンIdentifier（tok_id）から始まり、その後にKerberosメッセージが続きます。
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].
Kerberosメッセージ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 majorステータスを返す必要があり、返された出力トークンはエラーコード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 message [rfc4120]の暗号化されたdataフィールドは、コンテキストの認証に使用されるチケットのセッションキーで暗号化する必要があります。
The authenticator checksum field SHALL have the following format:
Authenticator Checksumフィールドには、次の形式があります。
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 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が設定されていない場合（セクション4.1.1.1で説明されている）、GSS_C_DELEG_FLAGが設定されている場合、少なくとも28オクテットとDLGTHオクテットである必要があります。GSS_C_DELEG_FLAGが設定されている場合、チェックサムデータの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
拡張機能をサポートしていないイニシエーターは、チェックサムフィールドに24オクテットを超えるオクテット（GSS_C_DELEG_FLAGが設定されていない場合）または28オクテットを超えて、DELEGフィールドでKRB_CRED（GSS_C_DELEG_FLAGが設定されている場合）を含めてはなりません。理解していないアクセプター
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).
拡張機能は、チェックサムデータのdelegフィールド（GSS_C_DELEG_FLAGが設定されている場合）またはチェックサムデータのフラグフィールド（GSS_C_DELEG_FLAGが設定されていない場合）を通過するオクテットを無視する必要があります。
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（2^12、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.
「BND」フィールドには、宣言の順に、バインディングのすべての非ヌルコンポーネントを引き継いだチャネルバインディングのMD5ハッシュが含まれています。チャネルバインディング内の整数フィールドは、MD5計算の目的のために小さなエンディアンの順序で表されます。
In computing the contents of the Bnd field, the following detailed points apply:
BNDフィールドの内容を計算する際に、次の詳細なポイントが適用されます。
(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オクテットにフォーマットされます。
(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.
(3) 発信者が有効なチャネル結合構造の代わりに値GSS_C_NO_BINDINGSを渡す場合、BNDフィールドは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）を超える長さフィールドのバッファー（2^32-1）では、このメカニズムの実装は、主要なステータスGSS_SS_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().
このセクションでは、2つのクラスのトークンが定義されています。（1）GSS_GETMIC（）への呼び出しによって放出され、GSS_VERIFYMIC（）への呼び出しによって消費され、（2）GSS_WRAP（）への呼び出しによって放出される（2）「ラップ」トークンを消費します。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フィールドを使用してフィラー内のオクテットの数をコードするために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.
機密性を提供するラップトークンでは、ラップトークンの最初の16オクテット（セクション4.2.6で定義されている「ヘッダー」）は、暗号化前にプレーンテキストデータに追加されるものとします。フィラーオクテットは、プレーンテキストデータと「ヘッダー」の間に挿入できます。フィラーオクテットの値とサイズは、復号化後に暗号システム残基が存在するように、実装によって選択されます。結果のラップトークンは{"header" |暗号化（Plantext-Data | Filler | "Header"）}、encrypt（）は暗号化プロファイル[RFC3961]で定義されている暗号化操作（整合性保護を提供する）とRRCフィールド（セクション4.2.5で定義されています。）誘惑されたヘッダーには、16進価値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].
機密性を提供しないラップトークンでは、チェックサムは、最初に署名されたプレーンテキストデータで最初に計算され、次にラップトークンの最初の16オクテット（セクション4.2.6で定義されているように、「ヘッダー」）で計算されます。）。トークンヘッダーのECフィールドとRRCフィールドの両方に、チェックサムを計算する目的でゼロで満たされなければなりません。結果のラップトークンは{"header" |Plantext-data |get_mic（plaintext-data | "header"）}、get_mic（）は、暗号プロファイル[RFC3961]で定義された選択した暗号化メカニズムの必要なチェックサムメカニズムのチェックサム操作です。
The parameters for the key and the cipher-state in the encrypt() and get_mic() operations have been omitted for brevity.
encrypt（）およびget_mic（）操作のキーとcipher-stateのパラメーターは、簡潔に省略されています。
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].
マイクトークンの場合、チェックサムは次のように計算されます。チェックサム操作は、最初に署名されたプレーンテキストデータで計算され、次にチェックサムメカニズムが必要なチェックサムメカニズムであるマイクトークンの最初の16オクテットで計算されます。暗号プロファイル[RFC3961]で定義された選択された暗号化メカニズム。
The resulting Wrap and MIC tokens bind the data to the token header, including the sequence number and the direction indicator.
結果のラップトークンとマイクトークンは、シーケンス番号と方向インジケーターを含む、データをトークンヘッダーにバインドします。
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]トレーラーに追加のバッファを提供しない[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で、回転前のトークンが{"Header" |であると仮定します。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（）コールの使用は、保護されているユーザーデータとは別に、トークン（このドキュメントのマイクトークンと呼ばれる）を生成します。これは、受信したデータの整合性を確認するために使用できます。トークンには次の形式があります。
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.
このメカニズムでは、コンテキスト削除トークンが空です。セキュリティコンテキストへの両方のピアは、gss_delete_sec_context（）[rfc2743]を個別に呼び出し、null output_context_tokenバッファを渡して、コンテキスト_tokenが不要であることを示します。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 0x00から0x60 0xffのトークン識別子（tok_id）は予約されており、割り当てられないものとします。したがって、トークンの最初の2つのオクテットを調べることにより、一般的なGSS-APIトークンフレーミングに包まれているかどうかを明確に伝えることができます。
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が具体的な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.
このリストは時間の経過とともに成長する可能性があり、特定の実装に固有の追加のMinir_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（）、gss_verifymic（）、およびgss_wrap（）への入力として、少なくとも16kオクテットのバッファーを受け入れることができなければなりません。また、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]の明示的な符号またはシールアルゴリズムを常に使用できます。別の方法として、[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 pseudo asn.1 framingを運ぶ必要があります。それ以外の場合、トークンの最初の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]によって使用されない場合、イニシエーターから提供され、認証装置チェックサムで運ばれるチャネルバインディング制限を無視できます。イニシエーターと同じチャネルバインディング（クライアントが相互認証を要求した場合でも）。この制限は、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によって選択されます。現在のメカニズムでは、アルゴリズムタイプの交渉は発生しないため、サーバー側（アクセプター）の実装は、クライアントがサーバーによって理解されていないアルゴリズムタイプを使用しないことを要求することはできません。ただし、管理者は、KDCが特定のアクセプタープリンシパルのチケットで使用するチケットセッションキーエンジctypのセットを制御することにより、このメカニズムのセッションキーに使用できるエンジティプを制御できます。したがって、KDCには、サーバー上のKerberosとGSSAPIソフトウェアによって実際にサポートされているタイプに、特定のサービスのセッションキーを制限するタスクを与えることができます。これには、GSSAPIベースの通信と非GSSAPIベースの通信の両方にサービスの主名が使用される場合（最も顕著な「ホスト」サービスキー）、GSSAPI実装が（たとえば）AES [など）を理解していない場合には、欠点があります。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.
Ken RaeburnとNicolas Williamsは、一般的なプロファイルの使用に関するエラーの多くを修正し、このドキュメントの作成に貢献しました。
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.
Sam HartmanとNicolas Williamsは、方向キーの以前のキー派生関数を、各方向に異なるキー使用数を持つ、方向ビットを最大限に保持することを推奨しました。
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.
スコット・フィールド、リチャード・ウォード、ダン・サイモン、ケビン・ダムール、サイモン・ジョセフソンも、この文書に貴重な情報を提供しました。
Jeffrey Hutzelman provided comments and clarifications for the text related to the channel bindings.
Jeffrey Hutzelmanは、チャンネルバインディングに関連するテキストのコメントと説明を提供しました。
Jeffrey Hutzelman and Russ Housley suggested many editorial changes.
Jeffrey HutzelmanとRuss 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.
Luke Howardは、Heimdalコードベースにこのドキュメントの実装を提供し、Microsoftコードベースでの操作性間テストを、Love 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.
Martin RexはTOK_IDの割り当ての推奨事項の提案を提供したため、トークンが擬似ASN.1ヘッダーで包まれている場合、このドキュメントのトークンタグ付けは明確です。
John Linn wrote the original Kerberos Version 5 mechanism specification [RFC1964], of which some text has been retained.
John Linnは、元のKerberosバージョン5メカニズム仕様[RFC1964]を書きました。このテキストが保持されています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2743] Linn、J。、「Generic Security Service Application Program Interfaceバージョン2、Update 1」、RFC 2743、2000年1月。
[RFC2744] Wray, J., "Generic Security Service API Version 2: C-bindings", RFC 2744, January 2000.
[RFC2744] Wray、J。、「ジェネリックセキュリティサービスAPIバージョン2：C-Bindings」、RFC 2744、2000年1月。
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996.
[RFC1964] Linn、J。、「Kerberosバージョン5 GSS-APIメカニズム」、RFC 1964、1996年6月。
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, February 2005.
[RFC3961] Raeburn、K。、「Kerberos 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] Neuman、C.、Yu、T.、Hartman、S。、およびK. Raeburn、「The Kerberos Network認証サービス（V5）」、RFC 4120、2005年7月。
[SSPI] Leach, P., "Security Service Provider Interface", Microsoft Developer Network (MSDN), April 2003.
[SSPI] Leach、P。、「セキュリティサービスプロバイダーインターフェイス」、Microsoft Developer Network（MSDN）、2003年4月。
[RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) Encryption for Kerberos 5", RFC 3962, February 2005.
[RFC3962] Raeburn、K。、「高度な暗号化標準（AES）Kerberos 5の暗号化」、RFC 3962、2005年2月。
[RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API Negotiation Mechanism", RFC 2478, December 1998.
[RFC2478] Baize、E。およびD. Pinkas、「シンプルで保護されたGSS-API交渉メカニズム」、RFC 2478、1998年12月。
Authors' Addresses
著者のアドレス
Larry Zhu One Microsoft Way Redmond, WA 98052 - USA
Larry Zhu One Microsoft Way Redmond、WA 98052 -USA
EMail: LZhu@microsoft.com
Karthik Jaganathan One Microsoft Way Redmond, WA 98052 - USA
Karthik Jaganathan One Microsoft Way Redmond、WA 98052 -USA
EMail: karthikj@microsoft.com
Sam Hartman Massachusetts Institute of Technology 77 Massachusetts Avenue Cambridge, MA 02139 - USA
サムハートマンマサチューセッツ工科大学77マサチューセッツアベニューケンブリッジ、マサチューセッツ州02139-アメリカ
EMail: hartmans-ietf@mit.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。