RFC4121 日本語訳
4121 The Kerberos Version 5 Generic Security Service ApplicationProgram Interface (GSS-API) Mechanism: Version 2. L. Zhu, K.Jaganathan, S. Hartman. July 2005. (Format: TXT=340314 bytes) (Updates RFC1964) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group L. Zhu
Request for Comments: 4121 K. Jaganathan
Updates: 1964 Microsoft
Category: Standards Track S. Hartman
MIT
July 2005
コメントを求めるワーキンググループL.朱の要求をネットワークでつないでください: 4121のK.Jaganathanアップデート: 1964年のマイクロソフトカテゴリ: 標準化過程S.ハートマンMIT2005年7月
The Kerberos Version 5
Generic Security Service Application Program Interface (GSS-API)
Mechanism: Version 2
ケルベロスバージョン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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(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.
ケルベロスバージョン5メカニズムを使用するときGeneric Security Service Application Program Interfaceが(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.
RFC1964をアップデートします、そして、ケルベロス暗号系フレームワークの導入などの最近の進展に対応して漸進的変化を提案します。 これらの変化は新しい暗号系の包含をサポートします、暗号系プロフィールに基づく彼らの暗号化とチェックサムアルゴリズムに伴う1メッセージあたりの新しいトークンを定義することによって。
Zhu, et al. Standards Track [Page 1] RFC 4121 Kerberos Version 5 GSS-API July 2005
朱、他 規格はGSS-API2005年7月にRFC4121ケルベロスバージョン5を追跡します[1ページ]。
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
1. 序論…2 2. 1メッセージあたりのトークンのためのキー派生…4 3. 保護の品質…4 4. 定義とトークン形式…5 4.1. 文脈設立トークン…5 4.1.1. 固有識別文字チェックサム…6 4.2. 1メッセージあたりのトークン…9 4.2.1. 一連番号…9 4.2.2. 分野に旗を揚げさせます…9 4.2.3. EC分野…10 4.2.4. 暗号化とチェックサム操作…10 4.2.5. RRC分野…11 4.2.6. メッセージレイアウト…12 4.3. 文脈削除トークン…13 4.4. トークン識別子課題問題…13 5. パラメタ定義…14 5.1. 小さい方のステータスコード…14 5.1.1. 非ケルベロスの詳細コード…14 5.1.2. ケルベロス特有のコード…15 5.2. サイズをバッファリングしてください…15 6. 遅れている互換性問題…15 7. セキュリティ問題…16 8. 承認…17 9. 参照…18 9.1. 標準の参照…18 9.2. 有益な参照…18
1. Introduction
1. 序論
[RFC3961] defines a generic framework for describing encryption and checksum types to be used with the Kerberos protocol and associated protocols.
[RFC3961]は、暗号化について説明して、チェックサムタイプがケルベロスプロトコルと関連プロトコルと共に使用されるためにジェネリックフレームワークを定義します。
[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メカニズムについて説明します。 それは、1メッセージあたりの文脈設立と文脈削除トークンの書式を定義して、各暗号系にメッセージと文脈削除トークンにアルゴリズム識別子を使用します。
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]によって指定された同じ暗号化アルゴリズムを使用することによって、達成されます。 したがって、1メッセージあたりのトークンのメッセージレイアウトは、アルゴリズムインディケータを取り除いて、ジェネリック暗号がフレームワーク[RFC3961]であるとサポートするためにその他の情報を加えるために改訂されます。
Zhu, et al. Standards Track [Page 2] RFC 4121 Kerberos Version 5 GSS-API July 2005
朱、他 規格はGSS-API2005年7月にRFC4121ケルベロスバージョン5を追跡します[2ページ]。
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終点実装とケルベロスKey Distributionセンター(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]と5月と共に使用されて、創始者とアクセプタであれば文脈設立から彼らがともにこれらの新しいトークン形式を処理できるのを知ってください。
"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]:
「より新しい」暗号化タイプは仕様か新しいケルベロス暗号系仕様[RFC3961]以来指定されているものです、.3セクション3.1[RFC4120]で定義されるように。 より新しくない暗号化タイプのリストは以下の通りです[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
暗号化タイプ規定番号---------------------------------------------- des-cbc-crc1des-cbc-md4 2 des-cbc-md5 3 des3-cbc-md5 5 des3-cbc-sha1 7 dsaWithSHA1-CmsOID9md5WithRSAEncryption-CmsOID10sha1WithRSAEncryption-CmsOID11rc2CBC-EnvOID12rsaEncryption-EnvOID13rsaES-OAEP-ENV-OID14des-ede3-cbc-Env-OID15des3-cbc-sha1-kd16rc4-hmac23
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[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.
「リトルエンディアンオーダー」という用語が言及する簡潔さに使用される、最も重要でない八重奏、最初に、「ビッグエンディアンオーダー」がある期間である、コード化する、最も重要な八重奏、最初に、コード化。
Zhu, et al. Standards Track [Page 3] RFC 4121 Kerberos Version 5 GSS-API July 2005
朱、他 規格はGSS-API2005年7月にRFC4121ケルベロスバージョン5を追跡します[3ページ]。
2. Key Derivation for Per-Message Tokens
2. 1メッセージあたりのトークンのための主要な派生
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
名前値------------------------------------- 用法創始者が署名する用法創始者が封をするkgの用法アクセプタが署名する用法アクセプタが封をするkgの22kg24 23kg25
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.
送付者が文脈アクセプタであるときに、主要な派生における用法番号がMICトークンに使用されるためにキーを引き出すために機能するとき(セクション4.2.6で.1を定義するので)、KG-USAGE-ACCEPTOR-SIGNは使用されています。 KG-USAGE-ACCEPTOR-SEALはWrapトークンに使用されます(セクション4.2.6で.2を定義するので)。 送付者が文脈創始者であるときに、同様に、主要な派生における用法番号がMICトークンのために機能するとき、KG-USAGE-INITIATOR-SIGNは使用されています、KG-USAGE-INITIATOR-SEALがWrapトークンに使用されますが。 Wrapトークンが秘密性に備えないでも、上で指定された同じ用法値は使用されています。
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メッセージでサブキーについて断言するかもしれません。 アクセプタがサブキーについて断言するなら、ベースキーはアクセプタで断言されたサブキーです、そして、"AcceptorSubkey"と共に1メッセージあたりのその後のトークンに旗を揚げさせなければなりません、セクション4.2.2で説明されるように。 さもなければ、創始者がAP-REQメッセージでサブキーについて断言するなら、ベースキーはこのサブキーです。 創始者がサブキーについて断言しないなら、ベースキーはサービスチケットの中に主要なセッションです。
3. Quality of Protection
3. 保護の品質
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]はあるタイプの暗号化を要求するのにアプリケーションで使用されるか、または署名することができるProtection(QOP)値のQualityを提供します。 QOPが評価するゼロは「デフォルト」保護を示すのに使用されます。 デフォルトQOPを使用しないアプリケーションは、実装の向こう側に携帯用である、または同じ実装の異なった展開構成で共同利用するのさえ保証されません。 異なったアルゴリズムを使用する、キーが定義される適切でないかもしれないというよりも。 したがって、新しいメソッドが本書では使用されているとき、QOP値は無視されます。
Zhu, et al. Standards Track [Page 4] RFC 4121 Kerberos Version 5 GSS-API July 2005
朱、他 規格はGSS-API2005年7月にRFC4121ケルベロスバージョン5を追跡します[4ページ]。
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.
1メッセージあたりのトークンにおける暗号化とチェックサムアルゴリズムは現在、セッションキーかサブキーに関連しているアルゴリズムでそれとなく定義されます。 したがって、[RFC1964]で説明されるアルゴリズム識別子は、もう必要でなく、新しいトークンヘッダーから取り除かれます。
4. Definitions and Token Formats
4. 定義とトークン形式
This section provides terms and definitions, as well as descriptions for tokens specific to the Kerberos Version 5 GSS-API mechanism.
このセクションはケルベロスバージョン5GSS-APIメカニズムに特定のトークンに用語、定義、および記述を提供します。
4.1. Context Establishment Tokens
4.1. 文脈設立トークン
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:
ケルベロスバージョン5GSS-APIメカニズムSHALLによって放たれたすべての文脈設立トークンが[RFC2743]のセクション3.1で説明された縁どりを持っています、疑似ASN以下の.1の構造によって例証されるように:
GSS-API DEFINITIONS ::=
GSS-API定義:、:=
BEGIN
始まってください。
MechType ::= OBJECT IDENTIFIER
-- representing Kerberos V5 mechanism
MechType:、:= OBJECT IDENTIFIER--ケルベロスV5メカニズムを表すこと。
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
}
GSSAPI-トークン:、:= -- 中で示されたオプション指示(委譲など)--メカニズム特有のトークン[APPLICATION0]IMPLICIT SEQUENCEthisMech MechType、innerToken、どんなDEFINED BY thisMechも--コンテンツメカニズム詳細--ASN.1構造は必要ではありません。
END
終わり
The innerToken field starts with a two-octet token-identifier (TOK_ID) expressed in big-endian order, followed by a Kerberos message.
innerToken分野はトークン識別子(TOK_ID)がケルベロスメッセージがあとに続いたビッグエンディアンオーダーで言い表した2八重奏から始まります。
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
十六進法におけるトークンTOK_ID価値----------------------------------------- KRB_AP_REQ01 00KRB_AP_レップ02 00KRB_誤り03 00
Zhu, et al. Standards Track [Page 5] RFC 4121 Kerberos Version 5 GSS-API July 2005
朱、他 規格はGSS-API2005年7月にRFC4121ケルベロスバージョン5を追跡します[5ページ]。
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)を受け取るなら、受信機はCONTINUE_が必要としたGSS_S_に主要な状態を返さなければなりません、そして、返された出力トークンは_エラーコードKRB_AP_ERR_エムエスジーTYPE[RFC4120]があるKRB_ERRORメッセージを含まなければなりません。
4.1.1. Authenticator Checksum
4.1.1. 固有識別文字チェックサム
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.
チェックサムタイプは0×8003であるに違いありません。 委譲が使用されているとき、KRB_CREDメッセージでチケットを与えるチケットを移すでしょう。 このチケットSHOULDは前進可能旗を設定させます。 文脈を認証するのに使用されるチケットのセッションキーでKRB_CREDメッセージ[RFC4120]のEncryptedData分野を暗号化しなければなりません。
The authenticator checksum field SHALL have the following format:
固有識別文字チェックサム分野SHALLには、以下の形式があります:
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].
八重奏名前記述----------------------------------------------------------------- 0..3 Bnd分野での八重奏のLgth Number。 リトルエンディアンオーダーでは、表されます。 現在、十六進法価値10 00 00 00の(16)を含みます。 4..19 セクション4.1.1で.2に説明されるように情報を縛るBnd Channel 20..Four-八重奏文脈設立がセクション4.1.1で.1に説明されるようにリトルエンディアンオーダーで旗を揚げさせる23個の旗 24..25 リトルエンディアンによる委譲オプション識別子(=1)が注文する[任意の]DlgOpt。 この分野と次の2つの分野が存在している、単に、GSS_C_DELEG_FLAGはセクション4.1.1で.1に説明されるように用意ができています。 26..27 リトルエンディアンによるDeleg分野の長さのDlgthは注文します[任意の]。 28..(n-1) Deleg A KRB_CREDメッセージ(n=Dlgth+28)[任意の]n.。最後のExts Extensions[任意の]。
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が用意ができていないときの(セクション4.1.1で.1について説明するので)少なくとも24の八重奏と、少なくとも28の八重奏であるに違いありません、そして、GSS_C_DELEG_FLAGがあるとき、Dlgth八重奏はセットしました。 いつ
Zhu, et al. Standards Track [Page 6] RFC 4121 Kerberos Version 5 GSS-API July 2005
朱、他 規格はGSS-API2005年7月にRFC4121ケルベロスバージョン5を追跡します[6ページ]。
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は用意ができて、チェックサムデータのDlgOpt、Dlgth、およびDeleg分野はすぐに、Flags野原に続かなければなりません。 任意の引きずっている八重奏(すなわち、「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
拡大をサポートしない創始者はDeleg分野でチェックサム分野(_GSS_C DELEG_FLAGがいつでないかがセットした)での24以上の八重奏か28以上の八重奏と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).
拡大はチェックサムデータ(GSS_C_DELEG_FLAGが用意ができているとき)のDeleg分野の先、または、チェックサムデータのFlags分野の先のどんな八重奏も無視しなければなりません(_GSS_C DELEG_FLAGがいつでないかがセットしました)。
4.1.1.1. Checksum Flags Field
4.1.1.1. 旗がさばくチェックサム
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
旗の名前価値--------------------------------- GSS_C_DELEG_旗1のGSS_Cの_の互いの_旗2のGSS_C_再生_旗4のGSS_C_系列_旗8のGSS_C_CONF_旗16のGSS_C_INTEG_旗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_秒_文脈()[RFC2743]でそれはそのオプションを要求します。 対応するリターン州の値[RFC2743]が、文脈の上の任意のレベルサービスのどれかが文脈でアクティブになるのを示すなら、チェックサムFlags分野に上のテーブルの対応する旗の値を設定しなければなりません。
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)は使用のためにレガシーのベンダー特有の拡大でこのメカニズムに予約されます。
Zhu, et al. Standards Track [Page 7] RFC 4121 Kerberos Version 5 GSS-API July 2005
朱、他 規格はGSS-API2005年7月にRFC4121ケルベロスバージョン5を追跡します[7ページ]。
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.
ここに指定されなかった他のすべての旗の値が今後の使用のために予約されます。 このメカニズムの今後の改正は、これらの予約された旗を使用して、適切にメカニズムバージョンを交渉するのにそのような旗を使用しないようにこのバージョンの実装を当てにするかもしれません。 送付者は未定義の旗の値を精算しなければなりません、そして、受信機で未知の旗を無視しなければなりません。
4.1.1.2. Channel Binding Information
4.1.1.2. 情報を縛るチャンネル
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;
typedef struct gss_チャンネル_結合_struct OM_uint32創始者_addrtype; gss_バッファ_desc創始者_アドレス; OM_uint32アクセプタ_addrtype; gss_バッファ_descアクセプタ_アドレス; gss_バッファ_descアプリケーション_データ;*gss_チャンネル_結合_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ハッシュ計算、それぞれの整数分野、および入力の長さの分野SHALLの目的のために、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) すべてが含まれているコネがハッシュ計算であったなら無評価されたa gss_チャンネル_結合_structなものさえのgss_バッファ_desc要素の中の長さの分野、SHALLを入力しました。 gss_バッファ_desc要素SHALLでは、「反-参照をつけ」られて結果として起こるデータSHALLになってください。価値要素、ハッシュ計算の中で含められてください、非ゼロ・レングス特許説明書の作成書があるgss_バッファ_desc要素のケースのためだけに。
Zhu, et al. Standards Track [Page 8] RFC 4121 Kerberos Version 5 GSS-API July 2005
朱、他 規格はGSS-API2005年7月にRFC4121ケルベロスバージョン5を追跡します[8ページ]。
(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のいいえ_BINDINGSを渡すなら、構造、Bnd分野SHALLを縛る有効なチャンネルの代わりに、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_秒_文脈[RFC2743]への訪問者がチャンネル結合としてGSS_Cで__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の八重奏に制限されます。
4.2. Per-Message Tokens
4.2. 1メッセージあたりのトークン
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()に放たれていて、呼び出しでGSS_Unwrap()に消費された"MIC"トークン。
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.
これらの1メッセージあたりの新しいトークンは文脈設立トークンによって使用されるジェネリックGSS-APIトークン縁どりを含んでいません。 これらの新しいトークンは、可変サイズチェックサムを持つことができるより新しい暗号システムと共に使用されるように設計されています。
4.2.1. Sequence Number
4.2.1. 一連番号
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.
陰湿に再演されたものと故意に繰り返されたメッセージを区別するために、1メッセージあたりのトークンは一連番号分野を含んでいます。(それは、ビッグエンディアンオーダーに表された64ビットの整数です)。 GSS_GetMIC()かGSS_Wrap()トークン、送付者の一連番号SHALLを送った後に、1つ増加されてください。
4.2.2. Flags Field
4.2.2. 分野に旗を揚げさせます。
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八重奏の整数です。 例えば、方向インディケータとして1個の旗を割り当てます、その結果、敵によって反対の方向に返送された同じメッセージの承認を防ぎます。
Zhu, et al. Standards Track [Page 9] RFC 4121 Kerberos Version 5 GSS-API July 2005
朱、他 規格はGSS-API2005年7月にRFC4121ケルベロスバージョン5を追跡します[9ページ]。
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.
噛み付いている名前記述-------------------------------------------------------------- 0 SentByAcceptor Whenはセットして、この旗は、送付者が文脈アクセプタであることを示します。 設定されないと、それは、送付者が文脈創始者であることを示します。 1 密封されたWhenはWrapトークンでセットして、この旗は、秘密性が備えられるのを示します。 それ、SHALL NOT、MICトークンでは、設定されてください。 文脈アクセプタによって断言された2AcceptorSubkey Aサブキーは、メッセージを保護するのに使用されます。
The rest of available bits are reserved for future use and MUST be cleared. The receiver MUST ignore unknown flags.
有効なビットの残りを今後の使用のために予約されて、儲けなければなりません。 受信機は未知の旗を無視しなければなりません。
4.2.3. EC Field
4.2.3. EC分野
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.
秘密性があるWrapトークンでは、EC分野SHALLがフィラーの八重奏の数をコード化するのに使用されて、中で説明されるように4.2に.4を区分してください。
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.
秘密性のないWrapトークンでは、EC分野SHALLが引きずっているチェックサムにおける、八重奏の数をコード化するのに使用されて、中で説明されるように4.2に.4を区分してください。
4.2.4. Encryption and Checksum Operations
4.2.4. 暗号化とチェックサム操作
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
Wrapトークンでは、それは秘密性に備えます、Wrapトークン(中で定義されるとしての「ヘッダー」セクション4.2.6)の最初の16の八重奏、SHALL。暗号化の前に平文データに追加します。 フィラー八重奏は平文データと「ヘッダー」の間に挿入されるかもしれません。 The
Zhu, et al. Standards Track [Page 10] RFC 4121 Kerberos Version 5 GSS-API July 2005
朱、他 規格はGSS-API2005年7月にRFC4121ケルベロスバージョン5を追跡します[10ページ]。
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.
フィラー八重奏の値とサイズが実装によって選ばれていて、そのようなものがそれである、そこ、SHALL、復号化の後にいいえ暗号系の残り現在の。 結果として起こるWrapトークンは「ヘッダー」| (平文データ| フィラー| 「ヘッダー」)を暗号化してください、どこが()を暗号化するかということです。暗号化操作(保全保護に備える)は暗号プロフィール[RFC3961]で定義されます、そして、暗号化されたヘッダーのRRC分野(セクション4.2.5で定義されるように)は十六進法値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].
秘密性、チェックサムSHALLに備えないWrapトークンでは、最初に、署名している平文データの上と、そして、そして、Wrapトークン(中で定義されるとしての「ヘッダー」セクション4.2.6)の最初の16の八重奏の上に関して計算されてください。 いっぱいにされて、EC分野とRRCの両方がトークンヘッダーでチェックサムについて計算する目的のためのゼロでSHALLをさばきます。 結果として起こるWrapトークンは「ヘッダー」| 平文データ| _mic(平文データ| 「ヘッダー」)を手に入れてください、どこに得られるかということです。_mic()は暗号プロフィール[RFC3961]で定義された選ばれた暗号化メカニズムの必要なチェックサムメカニズムのためのチェックサム操作です。
The parameters for the key and the cipher-state in the encrypt() and get_mic() operations have been omitted for brevity.
The parameters for the key and the cipher-state in the encrypt() and get_mic() operations have been omitted for brevity.
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].
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].
The resulting Wrap and MIC tokens bind the data to the token header, including the sequence number and the direction indicator.
The resulting Wrap and MIC tokens bind the data to the token header, including the sequence number and the direction indicator.
4.2.5. RRC Field
4.2.5. RRC Field
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.
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.
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
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
Zhu, et al. Standards Track [Page 11] RFC 4121 Kerberos Version 5 GSS-API July 2005
Zhu, et al. Standards Track [Page 11] RFC 4121 Kerberos Version 5 GSS-API July 2005
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.
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.
The RRC field is expressed as a two-octet integer in big-endian order.
The RRC field is expressed as a two-octet integer in big-endian order.
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.
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.
4.2.6. Message Layouts
4.2.6. Message Layouts
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.
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.
4.2.6.1. MIC Tokens
4.2.6.1. MIC Tokens
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:
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:
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.
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.
The Filler field is included in the checksum calculation for simplicity.
Zhu, et al. Standards Track [Page 12] RFC 4121 Kerberos Version 5 GSS-API July 2005
Zhu, et al. Standards Track [Page 12] RFC 4121 Kerberos Version 5 GSS-API July 2005
4.2.6.2. Wrap Tokens
4.2.6.2. Wrap Tokens
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:
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:
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.
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.
4.3. Context Deletion Tokens
4.3. Context Deletion Tokens
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 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.
4.4. Token Identifier Assignment Considerations
4.4. Token Identifier Assignment Considerations
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.
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.
Zhu, et al. Standards Track [Page 13] RFC 4121 Kerberos Version 5 GSS-API July 2005
Zhu, et al. Standards Track [Page 13] RFC 4121 Kerberos Version 5 GSS-API July 2005
5. Parameter Definitions
5. Parameter Definitions
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].
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].
5.1. Minor Status Codes
5.1. Minor Status Codes
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.
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.
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.
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.
5.1.1. Non-Kerberos-specific Codes
5.1.1. Non-Kerberos-specific Codes
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_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" */
Zhu, et al. Standards Track [Page 14] RFC 4121 Kerberos Version 5 GSS-API July 2005
Zhu, et al. Standards Track [Page 14] RFC 4121 Kerberos Version 5 GSS-API July 2005
5.1.2. Kerberos-specific Codes
5.1.2. Kerberos-specific Codes
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" */
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" */
5.2. Buffer Sizes
5.2. Buffer Sizes
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.
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.
6. Backwards Compatibility Considerations
6. Backwards Compatibility Considerations
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.
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.
Zhu, et al. Standards Track [Page 15] RFC 4121 Kerberos Version 5 GSS-API July 2005
Zhu, et al. Standards Track [Page 15] RFC 4121 Kerberos Version 5 GSS-API July 2005
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() 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.
7. Security Considerations
7. Security Considerations
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.
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.
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.
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.
Zhu, et al. Standards Track [Page 16] RFC 4121 Kerberos Version 5 GSS-API July 2005
Zhu, et al. Standards Track [Page 16] RFC 4121 Kerberos Version 5 GSS-API July 2005
8. Acknowledgements
8. Acknowledgements
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 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.
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.
Sam Hartman and Ken Raeburn suggested the "floating trailer" idea, namely the encoding of the RRC field.
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 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.
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.
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 provided comments and clarifications for the text related to the channel bindings.
Jeffrey Hutzelman and Russ Housley suggested many editorial changes.
Jeffrey Hutzelman and Russ Housley suggested many editorial changes.
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 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.
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 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.
John Linn wrote the original Kerberos Version 5 mechanism specification [RFC1964], of which some text has been retained.
John Linn wrote the original Kerberos Version 5 mechanism specification [RFC1964], of which some text has been retained.
Zhu, et al. Standards Track [Page 17] RFC 4121 Kerberos Version 5 GSS-API July 2005
Zhu, et al. Standards Track [Page 17] RFC 4121 Kerberos Version 5 GSS-API July 2005
9. References
9. References
9.1. Normative References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[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 Version 2, Update 1", RFC 2743, January 2000.
[RFC2744] Wray, J., "Generic Security Service API Version 2:
C-bindings", RFC 2744, January 2000.
[RFC2744] Wray, J., "Generic Security Service API Version 2: C-bindings", RFC 2744, January 2000.
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC
1964, June 1996.
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996.
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
Kerberos 5", RFC 3961, February 2005.
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, February 2005.
[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., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
9.2. Informative References
9.2. Informative References
[SSPI] Leach, P., "Security Service Provider Interface",
Microsoft Developer Network (MSDN), April 2003.
[SSPI] Leach, P., "Security Service Provider Interface", Microsoft Developer Network (MSDN), April 2003.
[RFC3962] Raeburn, K., "Advanced Encryption Standard (AES)
Encryption for Kerberos 5", RFC 3962, February 2005.
[RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) Encryption for Kerberos 5", RFC 3962, February 2005.
[RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
Negotiation Mechanism", RFC 2478, December 1998.
[RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API Negotiation Mechanism", RFC 2478, December 1998.
Zhu, et al. Standards Track [Page 18] RFC 4121 Kerberos Version 5 GSS-API July 2005
Zhu, et al. Standards Track [Page 18] RFC 4121 Kerberos Version 5 GSS-API July 2005
Authors' Addresses
Authors' Addresses
Larry Zhu One Microsoft Way Redmond, WA 98052 - USA
Larry Zhu One Microsoft Way Redmond, WA 98052 - USA
EMail: LZhu@microsoft.com
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
EMail: karthikj@microsoft.com
Sam Hartman Massachusetts Institute of Technology 77 Massachusetts Avenue Cambridge, MA 02139 - USA
Sam Hartman Massachusetts Institute of Technology 77 Massachusetts Avenue Cambridge, MA 02139 - USA
EMail: hartmans-ietf@mit.edu
EMail: hartmans-ietf@mit.edu
Zhu, et al. Standards Track [Page 19] RFC 4121 Kerberos Version 5 GSS-API July 2005
Zhu, et al. Standards Track [Page 19] RFC 4121 Kerberos Version 5 GSS-API July 2005
Full Copyright Statement
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
Acknowledgement
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.
Funding for the RFC Editor function is currently provided by the Internet Society.
Zhu, et al. Standards Track [Page 20]
Zhu, et al. Standards Track [Page 20]
一覧
スポンサーリンク
