[要約] RFC 5403は、RPCSEC_GSSバージョン2の仕様を定義しており、RPCプロトコル上でのセキュリティを向上させることを目的としています。
Network Working Group M. Eisler
Request for Comments: 5403 NetApp
Updates: 2203 February 2009
Category: Standards Track
RPCSEC_GSS Version 2
RPCSEC_GSSバージョン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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/ license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Abstract
概要
This document describes version 2 of the RPCSEC_GSS protocol. Version 2 is the same as version 1 (specified in RFC 2203) except that support for channel bindings has been added. RPCSEC_GSS allows remote procedure call (RPC) protocols to access the Generic Security Services Application Programming Interface (GSS-API).
このドキュメントでは、RPCSEC_GSSプロトコルのバージョン2について説明します。バージョン2は、チャネルバインディングのサポートが追加されていることを除いて、バージョン1（RFC 2203で指定）と同じです。RPCSEC_GSSを使用すると、リモートプロシージャコール（RPC）プロトコルが一般的なセキュリティサービスアプリケーションプログラミングインターフェイス（GSS-API）にアクセスできます。
Table of Contents
目次
1. Introduction and Motivation .....................................2
1.1. Requirements Language ......................................3
2. Channel Bindings Explained ......................................3
3. The RPCSEC_GSSv2 Protocol .......................................4
3.1. Compatibility with RPCSEC_GSSv1 ............................4
3.2. New Version Number .........................................5
3.3. New Procedure - RPCSEC_GSS_BIND_CHANNEL ....................7
3.4. New Security Service - rpc_gss_svc_channel_prot ...........10
4. Version Negotiation ............................................11
5. Native GSS Channel Bindings ....................................11
6. Operational Recommendation for Deployment ......................11
7. Implementation Notes ...........................................11
8. Acknowledgments ................................................11
9. Security Considerations ........................................11
10. References ....................................................13
10.1. Normative References .....................................13
10.2. Informative References ...................................14
This document describes RPCSEC_GSS version 2 (RPCSEC_GSSv2). RPCSEC_GSSv2 is the same as RPCSEC_GSS version 1 (RPCSEC_GSSv1) [1] except that support for channel bindings [2] has been added. The primary motivation for channel bindings is to securely take advantage of hardware-assisted encryption that might exist at lower levels of the networking protocol stack, such as at the Internet Protocol (IP) layer in the form of IPsec (see [7] and [8] for information on IPsec channel bindings). The secondary motivation is that even if lower levels are not any more efficient at encryption than the RPCSEC_GSS layer, if encryption is occurring at the lower level, it can be redundant at the RPCSEC_GSS level.
このドキュメントでは、RPCSEC_GSSバージョン2（RPCSEC_GSSV2）について説明します。RPCSEC_GSSV2は、RPCSEC_GSSバージョン1（RPCSEC_GSSV1）[1]と同じです。チャネルバインディングの主な動機は、IPSECの形式のインターネットプロトコル（IP）レイヤーなど、ネットワーキングプロトコルスタックのより低いレベルで存在する可能性のあるハードウェア支援暗号化を安全に利用することです（[7]および[[参照]8] IPSECチャネルバインディングの詳細については）。二次的な動機は、低レベルがRPCSEC_GSSレイヤーよりも暗号化が効率的でなくても、暗号化が低レベルで発生している場合、RPCSEC_GSSレベルで冗長性を発揮する可能性があることです。
RPCSEC_GSSv2 and RPCSEC_GSSv1 are protocols that exchange tokens emitted by the Generic Security Services (GSS) framework, which is defined in [3], and differ only in the support for GSS channel bindings in RPCSEC_GSSv2. GSS itself supports channel bindings, and in theory RPCSEC_GSSv2 could use native GSS channel bindings to achieve the effects described in this section. However, as Section 1.1.6 of [3] states, not all implementations of all GSS mechanisms support channel bindings. This is sufficient justification for the approach taken in this document: modify the RPCSEC_GSS protocol to support channel bindings independent of the capabilities of the GSS mechanism being used.
RPCSEC_GSSSV2およびRPCSEC_GSSV1は、[3]で定義されているGeneric Security Services（GSS）フレームワークによって放出されるトークンを交換するプロトコルであり、RPCSEC_GSSV2でのGSSチャネルバインディングのサポートのみが異なります。GSS自体はチャネルバインディングをサポートし、理論的にはRPCSEC_GSSV2は、ネイティブGSSチャネルバインディングを使用して、このセクションで説明されている効果を実現できます。ただし、[3]のセクション1.1.6が述べているように、すべてのGSSメカニズムのすべての実装がチャネルバインディングをサポートするわけではありません。これは、このドキュメントで取得したアプローチの十分な正当化です。RPCSEC_GSSプロトコルを変更して、使用されているGSSメカニズムの機能とは無関係にチャネルバインディングをサポートします。
Once an RPCSEC_GSS target and initiator are mutually assured that they are each using the same secure, end-to-end channel, the overhead of computing message integrity codes (MICs) for authenticating and integrity-protecting RPC requests and replies can be eliminated because the channel is performing the same function. Similarly, if the channel also provides confidentiality, the overhead of RPCSEC_GSS privacy protection can also be eliminated.
RPCSEC_GSSターゲットとイニシエーターが、それぞれ同じ安全なエンドツーエンドチャネルを使用していることを相互に保証すると、RPCリクエストと返信を認証および整合するためのコンピューティングメッセージ整合性コード（MIC）のオーバーヘッドを排除することができます。チャネルは同じ機能を実行しています。同様に、チャンネルも機密性を提供する場合、RPCSEC_GSSプライバシー保護のオーバーヘッドも排除できます。
The External Data Representation (XDR) [4] description is provided in this document in a way that makes it simple for the reader to extract into a ready-to-compile form. The reader can feed this document into the following shell script to produce the machine-readable XDR description of RPCSEC_GSSv2:
外部データ表現（XDR）[4]説明は、このドキュメントで、読者がすぐにコンパイルできるフォームに抽出できるようにする方法で提供されています。読者は、このドキュメントを次のシェルスクリプトに送り込み、RPCSEC_GSSV2の機械可読XDR説明を作成できます。
<CODE BEGINS>
<code begins>
#!/bin/sh
grep "^ *///" | sed 's?^ *///??'
<CODE ENDS>
<コードエンド>
That is, if the above script is stored in a file called "extract.sh", and this document is in a file called "spec.txt", then the reader can do:
つまり、上記のスクリプトが「extract.sh」というファイルに保存され、このドキュメントが「spec.txt」というファイルにある場合、読者は次のことができます。
<CODE BEGINS>
<code begins>
sh extract.sh < spec.txt > rpcsec_gss_v2.x
sh extract.sh <Spec.txt> rpcsec_gss_v2.x
<CODE ENDS>
<コードエンド>
The effect of the script is to remove leading white space from each line of the specification, plus a sentinel sequence of "///".
スクリプトの効果は、仕様の各ラインから先頭の空白を削除することと、「///」のセンチネルシーケンスを削除することです。
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 RFC 2119 [5].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [5]に記載されているように解釈される。
If a channel between two parties is secure, there must be shared information between the two parties. This information might be secret or not. The requirement for secrecy depends on the specifics of the channel.
2つの当事者間のチャネルが安全な場合、2つの当事者間で共有された情報が必要です。この情報は秘密かもしれません。秘密の要件は、チャネルの詳細によって異なります。
For example, the shared information could be the concatenation of the public key of the source and destination of the channel (where each public key has a corresponding private key). Suppose the channel is not end-to-end, i.e., a man-in-the-middle (MITM) exists, and there are two channels, one from the initiator to the MITM, and one from the MITM to the target. The MITM cannot simply force each channel to use the same public keys, because a public key derives from a private key, and the key management system for each node will surely assign unique or random private keys. At most, the MITM can force one end of each channel to use the same public key. The MIC of the public keys from the initiator will not be verified by the target, because at least one of the public keys will be different. Similarly, the MIC of the public keys from the target will not be verified by the initiator because at least one of the public keys will be different.
たとえば、共有された情報は、チャネルのソースと宛先の公開鍵（各公開鍵に対応する秘密鍵がある場合）の連結である可能性があります。チャネルがエンドツーエンドではなく、つまり、中間者（MITM）が存在すると仮定し、2つのチャネルがあり、1つはMITMから1つ、MITMからターゲットに1つあります。公開キーは秘密鍵から派生し、各ノードのキー管理システムが一意またはランダムなプライベートキーを確実に割り当てるため、MITMは各チャネルに同じパブリックキーを使用するように強制することはできません。せいぜい、MITMは各チャネルの一端を強制的に同じ公開キーを使用させることができます。イニシエーターからのパブリックキーのマイクは、少なくとも1つのパブリックキーが異なるため、ターゲットによって検証されません。同様に、少なくとも1つのパブリックキーが異なるため、ターゲットからのパブリックキーのマイクはイニシエーターによって検証されません。
A higher-layer protocol using the secure channel can safely exploit the channel to the mutual benefit of the higher-level parties if each higher-level party can prove:
安全なチャネルを使用した高層プロトコルは、各高レベルのパーティーが証明できる場合、チャネルを高レベルのパーティーの相互利益に安全に活用できます。
o They each know the channel's shared information.
o 彼らはそれぞれ、チャネルの共有情報を知っています。
o The proof of the knowledge of the shared information is in fact being conveyed by each of the higher-level parties, and not some other entities.
o 共有された情報の知識の証明は、実際には、他のエンティティではなく、それぞれの高レベルの当事者によって伝えられています。
RPCSEC_GSSv2 simply adds an optional round-trip that has the initiator compute a GSS MIC on the channel binding's shared information, and sends the MIC to the target. The target verifies the MIC, and in turn sends its own MIC of the shared information to the initiator that then verifies the target's MIC. This accomplishes three things. First, the initiator and target are mutually authenticated. Second, the initiator and target prove they know the channel's shared information, and thus are using the same channel. Third, the first and second things are done simultaneously.
RPCSEC_GSSV2は、イニシエーターがチャンネルバインディングの共有情報にGSS MICを計算するオプションのラウンドトリップを追加し、マイクをターゲットに送信します。ターゲットはマイクを検証し、共有情報の独自のマイクをイニシエーターに送信し、ターゲットのマイクを検証します。これは3つのことを達成します。まず、イニシエーターとターゲットは相互に認証されています。第二に、イニシエーターとターゲットは、チャネルの共有情報を知っているため、同じチャネルを使用していることを証明しています。第三に、最初と2番目のことは同時に行われます。
The RPCSEC_GSSv2 protocol will now be explained. The entire protocol is not presented. Instead the differences between RPCSEC_GSSv2 and RPCSEC_GSSv1 are shown.
RPCSEC_GSSV2プロトコルについて説明します。プロトコル全体は提示されていません。代わりに、RPCSEC_GSSV2とRPCSEC_GSSV1の違いが示されています。
The functionality of RPCSEC_GSSv1 is fully supported by RPCSEC_GSSv2.
RPCSEC_GSSV1の機能は、RPCSEC_GSSV2によって完全にサポートされています。
<CODE BEGINS>
<code begins>
/// /*
/// * Copyright (c) 2009 IETF Trust and the persons identified
/// * as the document authors. All rights reserved.
/// *
/// * The document authors are identified in [RFC2203] and
/// * [RFC5403].
/// *
/// * Redistribution and use in source and binary forms, with
/// * or without modification, are permitted provided that the
/// * following conditions are met:
/// *
/// * o Redistributions of source code must retain the above
/// * copyright notice, this list of conditions and the
/// * following disclaimer.
/// *
/// * o Redistributions in binary form must reproduce the above
/// * copyright notice, this list of conditions and the
/// * following disclaimer in the documentation and/or other
/// * materials provided with the distribution.
/// *
/// * o Neither the name of Internet Society, IETF or IETF
/// * Trust, nor the names of specific contributors, may be
/// * used to endorse or promote products derived from this
/// * software without specific prior written permission.
/// *
/// * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS
/// * AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED
/// * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
/// * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
/// * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
/// * EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
/// * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
/// * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
/// * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
/// * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
/// * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
/// * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
/// * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
/// * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
/// * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
/// */
/// /*
/// * This code was derived from [RFC2203]. Please
/// * reproduce this note if possible.
/// */
///
/// enum rpc_gss_service_t {
/// /* Note: the enumerated value for 0 is reserved. */
/// rpc_gss_svc_none = 1,
/// rpc_gss_svc_integrity = 2,
/// rpc_gss_svc_privacy = 3,
/// rpc_gss_svc_channel_prot = 4 /* new */
/// };
///
/// enum rpc_gss_proc_t {
/// RPCSEC_GSS_DATA = 0,
/// RPCSEC_GSS_INIT = 1,
/// RPCSEC_GSS_CONTINUE_INIT = 2,
/// RPCSEC_GSS_DESTROY = 3,
/// RPCSEC_GSS_BIND_CHANNEL = 4 /* new */
/// };
///
/// struct rpc_gss_cred_vers_1_t {
/// rpc_gss_proc_t gss_proc; /* control procedure */
/// unsigned int seq_num; /* sequence number */
/// rpc_gss_service_t service; /* service used */
/// opaque handle<>; /* context handle */
/// };
///
/// const RPCSEC_GSS_VERS_1 = 1;
/// const RPCSEC_GSS_VERS_2 = 2; /* new */
///
/// union rpc_gss_cred_t switch (unsigned int rgc_version) {
/// case RPCSEC_GSS_VERS_1:
/// case RPCSEC_GSS_VERS_2: /* new */
/// rpc_gss_cred_vers_1_t rgc_cred_v1;
/// };
///
<CODE ENDS>
<コードエンド>
Figure 1
図1
As is apparent from the above, the RPCSEC_GSSv2 credential has the same format as the RPCSEC_GSSv1 credential (albeit corrected so that the definition is in legal XDR description language that is also compatible with [9]; hence, the field "version", a keyword in RFC 1831, is replaced with "rgc_version"). Setting the rgc_version field to 2 indicates that the initiator and target support channel bindings.
上記から明らかなように、RPCSEC_GSSV2資格情報は、RPCSEC_GSSV1資格情報と同じ形式を持っています（ただし、定義は[9]とも互換性がある法的XDR説明言語であるため、修正されていますが、フィールド「バージョン」、キーワードRFC 1831では、「RGC_Version」に置き換えられます）。RGC_versionフィールドを2に設定すると、イニシエーターとターゲットサポートチャネルのバインディングが示されます。
<CODE BEGINS>
<code begins>
/// struct rgss2_bind_chan_MIC_in_args {
/// opaque rbcmia_bind_chan_hash<>;
/// };
///
/// typedef opaque rgss2_chan_pref<>;
/// typedef opaque rgss2_oid<>;
///
/// struct rgss2_bind_chan_verf_args {
/// rgss2_chan_pref rbcva_chan_bind_prefix;
/// rgss2_oid rbcva_chan_bind_oid_hash;
/// opaque rbcva_chan_mic<>;
/// };
///
<CODE ENDS>
<コードエンド>
Figure 2
図2
Once an RPCSEC_GSSv2 handle has been established over a secure channel, the initiator MAY issue RPCSEC_GSS_BIND_CHANNEL (Figure 1). Targets MUST support RPCSEC_GSS_BIND_CHANNEL. Like RPCSEC_GSS_INIT and RPCSEC_GSS_CONTINUE_INIT requests, the NULL RPC procedure MUST be used. Unlike those two requests, the arguments of the NULL procedure are not overloaded, because the verifier is of sufficient size for the purpose of RPCSEC_GSS_BIND_CHANNEL. The gss_proc field is set to RPCSEC_GSS_BIND_CHANNEL. The seq_num field is set as if gss_proc were set to RPCSEC_GSS_DATA. The service field is set to rpc_gss_svc_none. The handle field is set to that of an RPCSEC_GSS handle as returned by RPCSEC_GSS_INIT or RPCSEC_GSS_CONTINUE_INIT.
RPCSEC_GSSV2ハンドルが安全なチャネルで確立されると、イニシエーターはRPCSEC_GSS_BIND_CHANNELを発行する場合があります（図1）。ターゲットはRPCSEC_GSS_BIND_CHANNELをサポートする必要があります。RPCSEC_GSS_INITやRPCSEC_GSS_CONTINUE_INITリクエストのように、NULL RPC手順を使用する必要があります。これらの2つのリクエストとは異なり、VerifierはRPCSEC_GSS_BIND_CHANNELの目的のために十分なサイズであるため、NULLプロシージャの引数は過負荷になりません。GSS_ProcフィールドはRPCSEC_GSS_BIND_CHANNELに設定されています。SEQ_NUMフィールドは、GSS_PROCがRPCSEC_GSS_DATAに設定されているかのように設定されています。サービスフィールドはRPC_GSS_SVC_NONEに設定されています。ハンドルフィールドは、RPCSEC_GSS_INITまたはRPCSEC_GSS_CONTINUE_INITによって返されるRPCSEC_GSSハンドルのフィールドに設定されています。
The RPCSEC_GSS_BIND_CHANNEL request is similar to the RPCSEC_GSS_DATA request in that the verifiers of both contain MICs. As described in Section 5.3.1 of [1], when gss_proc is RPCSEC_GSS_DATA, the verifier of an RPC request is set to the output of GSS_GetMIC() on the RPC header. When gss_proc is RPCSEC_GSS_BIND_CHANNEL the verifier of an RPC request is set to the XDR encoding on a value of data type rgss2_bind_chan_verf_args, which includes a MIC as described below. The rgss2_bind_chan_verf_args data type consists of three fields:
RPCSEC_GSS_BIND_CHANNELリクエストは、両方のVerifiersがMICを含むという点で、RPCSEC_GSS_DATA要求に似ています。[1]のセクション5.3.1で説明されているように、GSS_PROCがRPCSEC_GSS_DATAの場合、RPC要求の検証者はRPCヘッダーのGSS_GETMIC（）の出力に設定されます。GSS_ProcがRPCSEC_GSS_BIND_CHANNELの場合、RPCリクエストの検証剤がXDRに設定され、データ型の値RGSS2_BIND_CHAN_VERF_ARGSの値に設定されています。RGSS2_BIND_CHAN_VERF_ARGSデータ型は、3つのフィールドで構成されています。
o rbcva_chan_bind_prefix. This is the channel binding prefix as described in [2] up to, but excluding, the colon (ASCII 0x3A) that separates the prefix from the suffix.
o rbcva_chan_bind_prefix。これは、[2]で説明されているように、しかし、接尾辞を接尾辞から分離するコロン（ASCII 0x3a）を除くチャネル結合プレフィックスです。
o rbcva_chan_bind_hash_oid. This is the object identifier (OID) of the hash algorithm used to compute rbcmia_bind_chan_hash. This field contains an OID encoded in ASN.1 as used by GSS-API in the mech_type argument to GSS_Init_sec_context ([3]). See [6] for the OIDs of the SHA one-way hash algorithms.
o rbcva_chan_bind_hash_oiod。これは、RBCMIA_BIND_CHAN_HASHを計算するために使用されるハッシュアルゴリズムのオブジェクト識別子（OID）です。このフィールドには、GSS_INIT_SEC_CONTEXT（[3]）のMECH_TYPE引数でGSS-APIが使用するASN.1にエンコードされたOIDが含まれています。SHA一元配置ハッシュアルゴリズムのOIDについて[6]を参照してください。
o rbcva_chan_mic. This is the output of GSS_GetMIC() on the concatenation of the XDR-encoded RPC header ("up to and including the credential" as per [1]) and the XDR encoding of an instance of type data rgss2_bind_chan_MIC_in_args. The data type rgss2_bind_chan_MIC_in_args consists of one field, rbcmia_bind_chan_hash, which is a hash of the channel bindings as defined in [2]. The channel bindings are a "canonical octet string encoding of the channel bindings", starting "with the channel bindings prefix followed by a colon (ASCII 0x3A)". The reason a hash of the channel bindings and not the actual channel bindings are used to compute rbcva_chan_mic is that some channel bindings, such as those composed of public keys, can be relatively large, and thus place a higher space burden on the implementations to manage. One way hashes consume less space.
o rbcva_chan_mic。これは、XDRエンコードされたRPCヘッダー（[1]に従って「資格情報まで」を含む」とタイプデータのインスタンスのXDRエンコードのXDRエンコードRPCヘッダーの連結に関するGSS_GETMIC（）の出力です。データ型RGSS2_BIND_CHAN_MIC_IN_ARGSは、[2]で定義されているチャネルバインディングのハッシュであるRBCMIA_BIND_CHAN_HASHである1つのフィールドで構成されています。チャネルバインディングは、「チャネルバインディングの標準的なオクテット文字列エンコード」で、「チャネルバインディングのプレフィックスが続いてコロン（ASCII 0x3a）が続く」から始まります。実際のチャネルバインディングではなくチャネルバインディングのハッシュがRBCVA_CHAN_MICを計算するために使用される理由は、パブリックキーで構成されるものなどの一部のチャネルバインディングが比較的大きく、したがって、管理するための実装により高いスペースの負担をかける可能性があるため。1つの方法は、より少ないスペースの消費量が少なくなります。
<CODE BEGINS>
<code begins>
/// enum rgss2_bind_chan_status {
/// RGSS2_BIND_CHAN_OK = 0,
/// RGSS2_BIND_CHAN_PREF_NOTSUPP = 1,
/// RGSS2_BIND_CHAN_HASH_NOTSUPP = 2
/// };
///
/// union rgss2_bind_chan_res switch
/// (rgss2_bind_chan_status rbcr_stat) {
///
/// case RGSS2_BIND_CHAN_OK:
/// void;
///
/// case RGSS2_BIND_CHAN_PREF_NOTSUPP:
/// rgss2_chan_pref rbcr_pref_list<>;
///
/// case RGSS2_BIND_CHAN_HASH_NOTSUPP:
/// rgss2_oid rbcr_oid_list<>;
/// };
///
/// struct rgss2_bind_chan_MIC_in_res {
/// unsigned int rbcmr_seq_num;
/// opaque rbcmr_bind_chan_hash<>;
/// rgss2_bind_chan_res rbcmr_res;
/// };
///
/// struct rgss2_bind_chan_verf_res {
/// rgss2_bind_chan_res rbcvr_res;
/// opaque rbcvr_mic<>;
/// };
///
<CODE ENDS>
<コードエンド>
Figure 3
図3
The RPCSEC_GSS_BIND_CHANNEL reply is similar to the RPCSEC_GSS_DATA reply in that the verifiers of both contain MICs. When gss_proc is RPCSEC_GSS_DATA, the verifier of an RPC reply is set to the output of GSS_GetMIC() on the seq_num of the credential of the corresponding request (as described in Section 5.3.3.2 of [1]). When gss_proc is RPCSEC_GSS_BIND_CHANNEL, the verifier of an RPC reply is set to the XDR encoding of an instance of data type rgss2_bind_chan_verf_res, which includes a MIC as described below. The data type rgss2_bind_chan_verf_res consists of two fields.
RPCSEC_GSS_BIND_CHANNEL応答は、両方の検証者にマイクが含まれているという点で、RPCSEC_GSS_DATA応答に似ています。GSS_PROCがRPCSEC_GSS_DATAの場合、RPC応答の検証剤は、対応する要求の資格情報のSEQ_NUMのGSS_GETMIC（）の出力に設定されます（[1]のセクション5.3.2で説明）。GSS_PROCがRPCSEC_GSS_BIND_CHANNELの場合、RPC応答の検証剤は、以下のマイクを含むデータ型RGSS2_BIND_CHAN_VERF_RESのインスタンスのXDRエンコードに設定されます。データ型RGSS2_BIND_CHAN_VERF_RESは、2つのフィールドで構成されています。
o rbcvr_res. The data type of this field is rgss2_bind_chan_res. The rgss2_bind_chan_res data type is a switched union consisting of three cases switched on the status contained in the rbcr_stat field.
o rbcvr_res。このフィールドのデータ型はRGSS2_BIND_CHAN_RESです。RGSS2_BIND_CHAN_RESデータ型は、RBCR_STATフィールドに含まれるステータスに切り替えられた3つのケースで構成されるスイッチ付きユニオンです。
* RGSS2_BIND_CHAN_OK. If this status is returned, the target accepted the channel bindings, and successfully verified rbcva_chan_mic in the request. No additional results will be in rbcvr_res.
* RGSS2_BIND_CHAN_OK。このステータスが返された場合、ターゲットはチャネルバインディングを受け入れ、リクエストでRBCVA_CHAN_MICを正常に検証しました。RBCVR_RESでは追加の結果はありません。
* RGSS2_BIND_CHAN_PREF_NOTSUPP. If this status is returned, the target did not support the prefix in the rbcva_chan_bind_prefix field of the arguments, and thus the RPCSEC_GSS_BIND_CHANNEL request was rejected. The target returned a list of prefixes it does support in the field rbcr_pref_list. Note that a channel can have multiple channel bindings each with different prefixes. The initiator is free to pick its preferred prefix. If the target does not support the prefix, the status RGSS2_BIND_CHAN_PREF_NOTSUPP will be returned, and the initiator can select its next most preferred prefix among the prefixes the target does support.
* rgss2_bind_chan_pref_notsupp。このステータスが返された場合、ターゲットは引数のRBCVA_CHAN_BIND_PREFIXフィールドのプレフィックスをサポートしなかったため、RPCSEC_GSS_BIND_CHANNEL要求は拒否されました。ターゲットは、フィールドRBCR_PREF_LISTでサポートするプレフィックスのリストを返しました。チャネルには、それぞれ異なる接頭辞を持つ複数のチャネルバインディングを持つことができることに注意してください。イニシエーターは、好みのプレフィックスを自由に選択できます。ターゲットがプレフィックスをサポートしていない場合、ステータスRGSS2_BIND_CHAN_PREF_NOTSUPPが返され、イニシエーターはターゲットがサポートするプレフィックスから次に最も優先されるプレフィックスを選択できます。
* RGSS2_BIND_CHAN_HASH_NOTSUPP. If this status is returned, the target did not support the hash algorithm identified in the rbcva_chan_bind_hash_oid field of the arguments, and thus the RPCSEC_GSS_BIND_CHANNEL request was rejected. The target returned a list of OIDs of hash algorithms it does support in the field rbcr_oid_list. The array rbcr_oid_list MUST have one or more elements.
* rgss2_bind_chan_hash_notsupp。このステータスが返された場合、ターゲットは引数のRBCVA_CHAN_BIND_HASH_OIDフィールドで識別されたハッシュアルゴリズムをサポートしていなかったため、RPCSEC_GSS_BIND_CHANNELリクエストは拒否されました。ターゲットは、フィールドRBCR_OID_LISTでサポートするハッシュアルゴリズムのOIDのリストを返しました。配列rbcr_oid_listには、1つ以上の要素が必要です。
o rbcvr_mic. The value of this field is equal to the output of GSS_GetMIC() on the XDR encoding of an instance of data type rgss2_bind_chan_MIC_in_res. The data type rgss2_bind_chan_MIC_in_res consists of three fields.
o rbcvr_mic。このフィールドの値は、データ型RGSS2_BIND_CHAN_MIC_IN_RESのインスタンスのXDRエンコードのGSS_GETMIC（）の出力に等しくなります。データ型RGSS2_BIND_CHAN_MIC_IN_RESは、3つのフィールドで構成されています。
* rbcmr_seq_num. The value of this field is equal to the field seq_num in the RPCSEC_GSS credential (data type rpc_gss_cred_vers_1_t).
* rbcmr_seq_num。このフィールドの値は、RPCSEC_GSS資格情報（データ型RPC_GSS_CRED_VERS_1_T）のフィールドSEQ_NUMに等しくなります。
* rbcmr_bind_chan_hash. This is the result of the one way hash of the channel bindings (including the prefix). If rbcr_stat is not RGSS2_BIND_CHAN_HASH_NOTSUPP, then the hash algorithm that is used to compute rbcmr_bind_chan_hash is that identified by the rbcva_chan_bind_oid_hash field in the arguments to RPCSEC_GSS_BIND_CHANNEL. If rbcr_stat is RGSS2_BIND_CHAN_HASH_NOTSUPP, then the hash algorithm used to compute rbcmr_bind_chan_hash is that identified by rbcr_oid_list[0] in the results.
* rbcmr_bind_chan_hash。これは、チャネルバインディング（プレフィックスを含む）の1つの方法のハッシュの結果です。RBCR_STATがRGSS2_BIND_CHAN_HASH_NOTSUPPでない場合、RBCMR_BIND_CHAN_HASHを計算するために使用されるハッシュアルゴリズムは、RBCVA_CHAN_CHAN_BIND_OID_HASHフィールドによってRPCSECSECSECS_BIND_CHANNELに識別されます。RBCR_STATがRGSS2_BIND_CHAN_HASH_NOTSUPPの場合、RBCMR_BIND_CHAN_HASHの計算に使用されるハッシュアルゴリズムは、結果のRBCR_OID_LIST [0]によって識別されるものです。
* rbcmr_res. The value of this field is equal to the value of the rbcvr_res field.
* rbcmr_res。このフィールドの値は、RBCVR_RESフィールドの値に等しくなります。
RPCSEC_GSSv2 targets MUST support rpc_gss_svc_channel_prot.
RPCSEC_GSSV2ターゲットは、RPC_GSS_SVC_CHANNEL_PROTをサポートする必要があります。
The rpc_gss_svc_channel_prot service (Figure 1) is valid only if RPCSEC_GSSv2 is being used, an RPCSEC_GSS_BIND_CHANNEL procedure has been executed successfully, and the secure channel still exists. When rpc_gss_svc_channel_prot is used, the RPC requests and replies are similar to those of rpc_gss_svc_none except that the verifiers on the request and reply always have the flavor set to AUTH_NONE, and the contents are zero length.
RPC_GSS_SVC_CHANNEL_PROTサービス（図1）は、RPCSEC_GSSV2が使用されている場合にのみ有効です。RPCSEC_GSS_BIND_CHANNELプロシージャは正常に実行され、安全なチャネルはまだ存在します。RPC_GSS_SVC_CHANNEL_PROTを使用する場合、RPCリクエストと返信は、RPC_GSS_SVC_NONEのリクエストと返信に似ています。
Note that even though NULL verifiers are used when rpc_gss_svc_channel_prot is used, non-NULL RPCSEC_GSS credentials are used. In order to identify the principal sending the request, the same credential is used as before, except that service field is set to rpc_gss_svc_channel_prot.
RPC_GSS_SVC_CHANNEL_PROTが使用されるときにnull検証剤が使用されている場合でも、非ヌルRPCSEC_GSS資格情報が使用されることに注意してください。リクエストを送信するプリンシパルを特定するために、サービスフィールドがRPC_GSS_SVC_CHANNEL_PROTに設定されていることを除いて、以前と同じ資格情報が使用されます。
An initiator that supports version 2 of RPCSEC_GSS simply issues an RPCSEC_GSS request with the rgc_version field set to RPCSEC_GSS_VERS_2. If the target does not recognize RPCSEC_GSS_VERS_2, the target will return an RPC error per Section 5.1 of [1].
RPCSEC_GSSのバージョン2をサポートするイニシエーターは、RPCSEC_VersionフィールドをRPCSEC_GSS_VERS_2に設定してRPCSEC_GSSリクエストを発行するだけです。ターゲットがRPCSEC_GSS_VERS_2を認識していない場合、ターゲットは[1]のセクション5.1ごとにRPCエラーを返します。
The initiator MUST NOT attempt to use an RPCSEC_GSS handle returned by version 2 of a target with version 1 of the same target. The initiator MUST NOT attempt to use an RPCSEC_GSS handle returned by version 1 of a target with version 2 of the same target.
イニシエーターは、同じターゲットのバージョン1を持つターゲットのバージョン2によって返されるRPCSEC_GSSハンドルを使用しようとしてはなりません。イニシエーターは、同じターゲットのバージョン2を持つターゲットのバージョン1によって返されるRPCSEC_GSSハンドルを使用しようとしてはなりません。
To ensure interoperability, implementations of RPCSEC_GSSv2 SHOULD NOT transfer tokens between the initiator and target that use native GSS channel bindings (as defined in Section 1.1.6 of [3]).
相互運用性を確保するために、RPCSEC_GSSV2の実装は、[3]のセクション1.1.6で定義されているように、ネイティブGSSチャネルバインディングを使用するイニシエーターとターゲットの間にトークンを転送してはなりません。
RPCSEC_GSSv2 is a superset of RPCSEC_GSSv1, and so can be used in all situations where RPCSEC_GSSv1 is used. RPCSEC_GSSv2 should be used when the new functionality, channel bindings, is desired or needed.
RPCSEC_GSSV2はRPCSEC_GSSV1のスーパーセットであるため、RPCSEC_GSSV1が使用されるすべての状況で使用できます。RPCSEC_GSSV2は、新しい機能であるチャネルバインディングが必要または必要な場合に使用する必要があります。
Once a successful RPCSEC_GSS_BIND_CHANNEL procedure has been performed on an RPCSEC_GSSv2 context handle, the initiator's implementation may map application requests for rpc_gss_svc_none and rpc_gss_svc_integrity to rpc_gss_svc_channel_prot credentials. And if the secure channel has privacy enabled, requests for rpc_gss_svc_privacy can also be mapped to rpc_gss_svc_channel_prot.
成功したRPCSEC_GSS_BIND_CHANNEL手順がRPCSEC_GSSV2コンテキストハンドルで実行されると、イニシエーターの実装は、RPC_GSS_SVC_NONEおよびRPC_GSS_SVC_INTERITYのRPC_GSS_SVC_INTERITYのアプリケーションリクエストをRPC_SVSVCHANNL_PROT CREDENETIENTSにマッピングできます。Secure Channelがプライバシーを有効にしている場合、RPC_GSS_SVC_PRIVACYのリクエストもRPC_GSS_SVC_CHANNEL_PROTにマッピングできます。
Nicolas Williams had the idea for extending RPCSEC_GSS to support channel bindings. Alex Burlyga, Lars Eggert, Pasi Eronen, and Dan Romascanu reviewed the document and gave valuable feedback for improving its readability.
ニコラス・ウィリアムズは、RPCSEC_GSSを拡張してチャネルバインディングをサポートするというアイデアを持っていました。Alex Burlyga、Lars Eggert、Pasi Eronen、およびDan Romascanuがこの文書をレビューし、読みやすさを向上させるための貴重なフィードバックを提供しました。
The base security considerations consist of:
基本セキュリティの考慮事項は次のとおりです。
o All security considerations from [1].
o [1]からのすべてのセキュリティ上の考慮事項。
o All security considerations from [2].
o [2]からのすべてのセキュリティ上の考慮事項。
o All security considerations from the actual secure channel being used.
o 使用されている実際の安全なチャネルからのすべてのセキュリティ上の考慮事項。
Even though RPCSEC_GSS_DATA requests that use rpc_gss_svc_channel_prot protection do not involve construction of more GSS tokens, the target SHOULD stop allowing RPCSEC_GSS_DATA requests with rpc_gss_svc_channel_prot protection once the GSS context expires.
RPCSEC_GSS_DATAを使用するRPC_GSS_SVC_CHANNEL_PROT保護には、より多くのGSSトークンの構築が含まれない場合でも、ターゲットはRPC_GSS_SVC_CHANNEL_PROT保護のRPC_GSS_SVC_CHANNEL_PROT保護のRPCSEC_GSSS_DATA要求を停止する必要があります。
With the use of channel bindings, it becomes extremely critical that the message integrity code (MIC) used by the GSS mechanism that RPCSEC_GSS is using be difficult to forge. While this requirement is true for RPCSEC_GSSv1, and indeed any protocol that uses GSS MICs, the distinction in the seriousness is that for RPCSEC_GSSv1, forging a single MIC at most allows the attacker to succeed in injecting one bogus request. Whereas, with RPCSEC_GSSv2 combined with channel bindings, by forging a single MIC the attacker will succeed in injecting bogus requests as long as the channel exists. An example illustrates. Suppose we have an RPCSEC_GSSv1 initiator, a man-in-the-middle (MITM), an RPCSEC_GSSv1 target, and an RPCSEC_GSSv2 target. The attack is as follows.
チャネルバインディングの使用により、RPCSEC_GSSが使用しているGSSメカニズムで使用されるメッセージ整合性コード（MIC）が鍛造が困難であることが非常に重要になります。この要件はRPCSEC_GSSV1、および実際にGSS MICSを使用するプロトコルには当てはまりますが、深刻さの違いは、RPCSEC_GSSV1の場合、最大のマイクを鍛造することで、攻撃者が1つの沼地のリクエストを注入することができることです。一方、RPCSEC_GSSV2とチャネルバインディングを組み合わせて、単一のマイクを偽造することにより、攻撃者はチャネルが存在する限り偽の要求を注入することに成功します。例を示しています。RPCSEC_GSSV1イニシエーター、中間者（MITM）、RPCSEC_GSSV1ターゲット、およびRPCSEC_GSSV2ターゲットがあるとします。攻撃は次のとおりです。
o The MITM intercepts the initiator's RPCSEC_GSSv1 RPCSEC_GSS_INIT message and changes the version number from 1 to 2 before forwarding to the RPCSEC_GSSv2 target, and changes the reply's version number from 2 to 1 before forwarding to the RPCSEC_GSSv1 initiator. Neither the client nor the server notice.
o MITMは、イニシエーターのRPCSEC_GSSV1 RPCSEC_GSS_INITメッセージをインターセプトし、RPCSEC_GSSV2ターゲットに転送する前にバージョン番号を1から2に変更し、RPCSEC_GSSV1イニシエーターに転送する前に返信のバージョン番号を2から1に変更します。クライアントもサーバーも通知しません。
o Once the RPCSEC_GSS handle is in an established state, the initiator sends its first RPCSEC_GSS_DATA request. The MITM constructs an RPCSEC_GSS_BIND_CHANNEL request, using the message integrity code (MIC) of the RPCSEC_GSS_DATA request. It is likely the RPCSEC_GSSv2 target will reject the request. The MITM continues to reiterate each time the initiator sends another RPCSEC_GSS_DATA request. With enough iterations, the probability of a MIC from an RPCSEC_GSS_DATA being successfully verified in the forged RPCSEC_GSS_BIND_CHANNEL increases. Once the MITM succeeds, it can send RPCSEC_GSS_DATA requests with a security service of rpc_gss_svc_channel_prot, which does not have MICs in the RPC request's verifier.
o RPCSEC_GSSハンドルが確立された状態になると、イニシエーターは最初のRPCSEC_GSS_DATAリクエストを送信します。MITMは、RPCSEC_GSS_DATAリクエストのメッセージ整合性コード（MIC）を使用して、RPCSEC_GSS_BIND_CHANNEL要求を構築します。RPCSEC_GSSV2ターゲットがリクエストを拒否する可能性があります。MITMは、イニシエーターが別のRPCSEC_GSS_DATAリクエストを送信するたびに繰り返し続けます。十分な反復により、RPCSEC_GSS_DATAからのMICの確率は、偽造されたRPCSEC_GSS_BIND_CHANNELで確認されています。MITMが成功すると、RPC_GSS_SVC_CHANNEL_PROTのセキュリティサービスでRPCSEC_GSS_DATAリクエストを送信できます。
The implementation of RPCSEC_GSSv2 can use at least two methods to thwart these attacks.
RPCSEC_GSSV2の実装は、これらの攻撃を阻止するために少なくとも2つの方法を使用できます。
o The target SHOULD require a stronger MIC when sending an RPCSEC_GSS_BIND_CHANNEL request instead of an RPCSEC_GSS_DATA request -- e.g., if HMACs are used for the MICs, require the widest possible HMAC (in terms of bit length) that the GSS mechanism supports. If HMACs are being used, and the target expects N RPCSEC_GSS_DATA requests to be sent on the context before it expires, then the target SHOULD require an HMAC for RPCSEC_GSS_BIND_CHANNEL that is log base 2 N bits longer than what it normally requires for RPCSEC_GSS_DATA requests. If a long enough MIC is not available, then the target could artificially limit the number of RPCSEC_GSS_DATA requests it will allow on the context before deleting the context.
o ターゲットは、RPCSEC_GSS_DATAリクエストの代わりにRPCSEC_GSS_BIND_CHANNEL要求を送信する際に、より強力なマイクを必要とするはずです。たとえば、HMACがMICSに使用される場合は、GSSメカニズムがサポートする可能性のあるHMAC（ビットの長さの観点から）が必要です。HMACSが使用されており、ターゲットがn RPCSEC_GSS_DATAのリクエストが有効期限が切れる前にコンテキストに送信されると予想する場合、ターゲットは、通常、RPCSEC_GSS_DATAリクエストに必要なものよりも長いログベース2 NビットであるRPCSEC_GSS_BIND_CHANNELのHMACを必要とする必要があります。十分な長いマイクが利用できない場合、ターゲットは、コンテキストを削除する前にコンテキストで許可するRPCSEC_GSS_DATA要求の数を人為的に制限する可能性があります。
o Each time an RPCSEC_GSSv2 target experiences a failure to verify the MIC of an RPCSEC_GSS_BIND_CHANNEL request, it SHOULD reduce the lifetime of the underlying GSS context, by a significant fraction, thereby preventing the MITM from using the established context for its attack. A possible heuristic is that if the target believes the possibility that failure to verify the MIC was because of an attack is X percent, then the context's lifetime would be reduced by X percent. For simplicity, an implementer might set X to be 50 percent, so that the context lifetime is halved on each failed verification of an RPCSEC_GSS_BIND_CHANNEL request and thus rapidly reduced to zero on subsequent requests. For example, with a context lifetime of 8 hours (or 28800 seconds), 15 failed attempts by the MITM would cause the context to be destroyed.
o RPCSEC_GSSV2ターゲットがRPCSEC_GSS_BIND_CHANNEL要求のマイクを検証できないことを経験するたびに、基礎となるGSSコンテキストの寿命を大幅に削減し、それによりMITMが攻撃のために確立されたコンテキストを使用するのを妨げるはずです。ヒューリスティックの可能性は、ターゲットがマイクの検証に失敗したことが攻撃のためであるという可能性がxパーセントであると信じている場合、コンテキストの寿命はxパーセント削減されることです。簡単にするために、実装者はXを50パーセントに設定する可能性があるため、RPCSEC_GSS_BIND_CHANNELリクエストの検証が失敗するたびにコンテキスト寿命が半分になり、後続のリクエストで急速にゼロに減少します。たとえば、コンテキストの寿命8時間（または28800秒）で、MITMによる15の失敗した試行により、コンテキストが破壊されます。
A method of mitigation that was considered was to protect the RPCSEC_GSS version number with RPCSEC_GSSv2's RPCSEC_GSS_INIT and RPCSEC_GSS_CONTINUE_INIT tokens. Thus, the version number of RPCSEC_GSS would be in the tokens. This method does not completely mitigate the attack; it just moves the MIC guessing to the RPCSEC_GSS_INIT message. In addition, without changing GSS, or the GSS mechanism, there is no way to include the RPCSEC_GSS version number in the tokens. So for these reasons this method was not selected.
考慮された緩和方法は、RPCSEC_GSSV2のRPCSEC_GSS_INITおよびRPCSEC_GSS_CONTINUE_INITトークンを使用して、RPCSEC_GSSバージョン番号を保護することでした。したがって、RPCSEC_GSSのバージョン番号はトークンになります。この方法は、攻撃を完全に軽減するわけではありません。マイクがRPCSEC_GSS_INITメッセージに推測するだけです。さらに、GSSやGSSメカニズムを変更せずに、トークンにRPCSEC_GSSバージョン番号を含める方法はありません。したがって、これらの理由により、この方法は選択されていません。
[1] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol Specification", RFC 2203, September 1997.
[1] Eisler、M.、Chiu、A。、およびL. Ling、「RPCSEC_GSSプロトコル仕様」、RFC 2203、1997年9月。
[2] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007.
[2] ウィリアムズ、N。、「チャンネルを保護するためのチャネルバインディングの使用について」、RFC 5056、2007年11月。
[3] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[3] Linn、J。、「Generic Security Service Application Program Interfaceバージョン2、Update 1」、RFC 2743、2000年1月。
[4] Eisler, M., "XDR: External Data Representation Standard", STD 67, RFC 4506, May 2006.
[4] アイスラー、M。、「XDR：外部データ表現標準」、STD 67、RFC 4506、2006年5月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[6] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, June 2005.
[6] Schaad、J.、Kaliski、B。、およびR. Housley、「インターネットで使用するRSA暗号化の追加アルゴリズムと識別子X.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」、RFC 4055、2005年6月。
[7] Williams, N., "IPsec Channels: Connection Latching", Work in Progress, November 2008.
[7] ウィリアムズ、N。、「IPSECチャネル：接続ラッチング」、2008年11月、進行中の作業。
[8] Williams, N., "End-Point Channel Bindings for IPsec Using IKEv2 and Public Keys", Work in Progress, April 2008.
[8] ウィリアムズ、N。、「IKEV2およびパブリックキーを使用したIPSEC用のエンドポイントチャネルバインディング」、2008年4月、進行中の作業。
[9] Srinivasan, R., "RPC: Remote Procedure Call Protocol Specification Version 2", RFC 1831, August 1995.
[9] Srinivasan、R。、「RPC：リモート手順コールプロトコル仕様バージョン2」、RFC 1831、1995年8月。
Author's Address
著者の連絡先
Mike Eisler NetApp 5765 Chase Point Circle Colorado Springs, CO 80919 US
マイクアイスラーネットアップ5765チェイスポイントサークルコロラドスプリングス、コロラド州80919米国
Phone: +1-719-599-9026
EMail: mike@eisler.com