RFC 4771 - Integrity Transform Carrying Roll-Over Counter for the Secure Real-time Transport Protocol (SRTP) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc4771
タイトル : RFC 4771 - 安全なリアルタイムトランスポートプロトコル（SRTP）のキャリングロールオーバーカウンター
翻訳編集 : 自動生成

[要約] 要約：RFC 4771は、Secure Real-time Transport Protocol（SRTP）のためのIntegrity Transform Carrying Roll-Over Counter（IC-ROC）を定義しています。IC-ROCは、SRTPパケットの整合性を保証するために使用されるカウンターを含む新しいトランスフォームです。目的：RFC 4771の目的は、SRTPのセキュリティを向上させるために、パケットの整合性を保証するための新しいトランスフォームであるIC-ROCを定義することです。これにより、SRTPの通信が改ざんや攻撃から保護されます。

Network Working Group                                      V. Lehtovirta
Request for Comments: 4771                                    M. Naslund
Category: Standards Track                                     K. Norrman
                                                                Ericsson
                                                            January 2007

Integrity Transform Carrying Roll-Over Counter for the Secure Real-time Transport Protocol (SRTP)

安全なリアルタイムトランスポートプロトコル（SRTP）のキャリングロールオーバーカウンター

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）の現在のエディションを参照してください。このメモの配布は無制限です。

著作権表示

著作権（c）The IETF Trust（2007）。

Abstract

概要

This document defines an integrity transform for Secure Real-time Transport Protocol (SRTP; see RFC 3711), which allows the roll-over counter (ROC) to be transmitted in SRTP packets as part of the authentication tag. The need for sending the ROC in SRTP packets arises in situations where the receiver joins an ongoing SRTP session and needs to quickly and robustly synchronize. The mechanism also enhances SRTP operation in cases where there is a risk of losing sender-receiver synchronization.

このドキュメントでは、安全なリアルタイム輸送プロトコル（SRTP; RFC 3711を参照）の整合性変換を定義します。これにより、認証タグの一部としてロールオーバーカウンター（ROC）をSRTPパケットに送信できます。SRTPパケットでROCを送信する必要性は、レシーバーが進行中のSRTPセッションに参加し、迅速かつ堅牢に同期する必要がある状況で発生します。また、このメカニズムは、送信者と受信者の同期を失うリスクがある場合においてSRTP操作を強化します。

Table of Contents

   1. Introduction ....................................................2
      1.1. Terminology ................................................3
   2. The Transform ...................................................3
   3. Transform Modes .................................................5
   4. Parameter Negotiation ...........................................5
   5. Security Considerations .........................................7
   6. IANA Considerations ............................................10
   7. Acknowledgements ...............................................10
   8. References .....................................................10
      8.1. Normative References ......................................10
      8.2. Informative References ....................................10

1. Introduction

1. はじめに

When a receiver joins an ongoing SRTP [RFC3711] session, out-of-band signaling must provide the receiver with the value of the ROC the sender is currently using. For instance, it can be transferred in the Common Header Payload of a MIKEY [RFC3830] message. In some cases, the receiver will not be able to synchronize his ROC with the one used by the sender, even if it is signaled to him out of band. Examples of where synchronization failure will appear are:

受信者が進行中のSRTP [RFC3711]セッションに参加する場合、帯域外シグナリングは、送信者が現在使用しているROCの値を受信者に提供する必要があります。たとえば、Mikey [RFC3830]メッセージの一般的なヘッダーペイロードで転送できます。場合によっては、レシーバーは、バンドから彼に合図されていても、送信者が使用したROCとROCを同期することはできません。同期障害が表示される場所の例は次のとおりです。

1. The receiver receives the ROC in a MIKEY message together with a key required for a particular continuous service. He does not, however, join the service until after a few hours, at which point the sender's sequence number (SEQ) has wrapped around, and so the sender, meanwhile, has increased the value of ROC. When the user joins the service, he grabs the SEQ from the first seen SRTP packet and prepends the ROC to build the index. If integrity protection is used, the packet will be discarded. If there is no integrity protection, the packet may (if key derivation rate is non-zero) be decrypted using the wrong session key, as ROC is used as input in session key derivation. In either case, the receiver will not have its ROC synchronized with the sender, and it is not possible to recover without out-of-band signaling.

1. 受信者は、特定の継続的なサービスに必要なキーとともに、マイキーメッセージでROCを受信します。しかし、彼は数時間後までサービスに参加しません。その時点で、送信者のシーケンス数（seq）が包み込まれているため、送信者はROCの価値を高めました。ユーザーがサービスに参加すると、彼は最初に見られたSRTPパケットから配列をつかみ、ROCをプレイエンドしてインデックスを構築します。整合性保護を使用すると、パケットが破棄されます。整合性保護がない場合、ROCはセッションキー派生の入力として使用されるため、間違ったセッションキーを使用してパケット（キー導入率がゼロではない場合）を復号化することがあります。どちらの場合でも、受信者はROCが送信者と同期していないため、帯域外シグナリングなしで回復することはできません。

2. If the receiver leaves the session (due to being out of radio coverage or because of a user action), and does not start receiving traffic from the service again until after 2^15 packets have been sent, the receiver will be out of synchronization (for the same reasons as in example 1).

2. 受信者がセッションを離れる（無線のカバレッジがなくなったため、またはユーザーアクションのため）、2^15パケットが送信されるまでサービスから再びトラフィックを受信し始めない場合、レシーバーは同期しなくなります（例1と同じ理由で）。

3. The receiver joins a service when the SEQ has recently wrapped around (say, SEQ = 0x0001). The sender generates a MIKEY message and includes the current value of ROC (say, ROC = 1) in the MIKEY message. The MIKEY message reaches the receiver, who reads the ROC value and initializes its local ROC to 1. Now, if an SRTP packet prior to wraparound, i.e., with a SEQ lower than 0 (say, SEQ = 0xffff), was delayed and reaches the receiver as the first SRTP packet he sees, the receiver will initialize its highest received sequence number, s_l, to 0xffff. Next, the receiver will receive SRTP packets with sequence numbers larger than zero, and will deduce that the SEQ has wrapped. Hence, the receiver will incorrectly update the ROC and be out of synchronization.

3. Receiverは、SEQが最近ラップしたときにサービスに参加します（たとえば、SEQ = 0x0001）。送信者はMikeyメッセージを生成し、MikeyメッセージにROCの現在の値（ROC = 1）を含みます。MikeyメッセージはROC値を読み取り、ローカルROCを1に初期化するレシーバーに届きます。これは、ラップアラウンドの前にSRTPパケットが0（たとえば、SEQ = 0xffff）を下回る場合、SRTPパケットが遅延して到達した場合に到達しました。受信機は、彼が見た最初のSRTPパケットとして、受信者が最も高い受信シーケンス番号S_Lを0xffffに初期化します。次に、レシーバーはゼロより大きいシーケンス番号を持つSRTPパケットを受け取り、SEQがラップされていると推測します。したがって、受信者はROCを誤って更新し、同期しなくなります。

4. Similarly to (3), since the initial SEQ is selected at random by the sender, it may happen to be selected as a value very close to 0xffff. In this case, should the first few packets be lost, the receiver may similarly end up out of synchronization.

4. （3）と同様に、最初のSEQは送信者によってランダムに選択されるため、たまたま0xFFFFに非常に近い値として選択される可能性があります。この場合、最初のいくつかのパケットが失われた場合、レシーバーは同様に同期しなくなる可能性があります。

These problems have been recognized in, e.g., 3GPP2 and 3GPP, where SRTP is used for streaming media protection in their respective multicast/broadcast solutions [BCMCS][MBMS]. Problem 4 actually exists inherently due to the way SEQ initialization is done in RTP.

これらの問題は、たとえば3GPP2および3GPPなどで認識されており、SRTPはそれぞれのマルチキャスト/ブロードキャストソリューション[BCMCS] [MBMS]のメディア保護のストリーミングに使用されます。問題4は、RTPでSEQの初期化が行われる方法により、実際には本質的に存在します。

One possible approach to address the issue could be to carry the ROC in the MKI (Master Key Identifier) field of each SRTP packet. This has the advantage that the receiver immediately knows the entire index for a packet. Unfortunately, the MKI has no semantics in RFC 3711 (other than specifying master key), and a regular RFC 3711 compliant implementation would not be able to make use of the information carried in the MKI. Furthermore, the MKI field is not integrity protected; hence, care must be taken to avoid obvious attacks against the synchronization.

In this document, a solution is presented where the ROC is carried in the authentication tag of a special integrity transform in selected SRTP packets.

このドキュメントでは、ROCが選択したSRTPパケットの特別な整合性変換の認証タグに掲載されるソリューションが提示されます。

The benefit of this approach is that the functionality of fast and robust synchronization can be achieved as a separate integrity transform, using the hooks existing in SRTP. Furthermore, when the ROC is transmitted to the receiver it needs to be integrity protected to avoid persistent denial-of-service (DoS) attacks or transmission errors that could bring the receiver out of synchronization. (A DoS attack is regarded as persistent if it can last after the attacker has left the area; in this particular case, an attacker could modify the ROC in one packet and the victim would be out of synchronization until the next ROC is transmitted). The above discussion leads to the conclusion that it makes sense to carry the ROC inside the authentication tag of an integrity transform.

このアプローチの利点は、SRTPに存在するフックを使用して、高速で堅牢な同期の機能を個別の整合性変換として達成できることです。さらに、ROCが受信機に送信される場合、受信機を同期しない可能性のある永続的なサービス拒否（DOS）攻撃または送信エラーを避けるために、整合性保護が必要です。（DOS攻撃は、攻撃者がエリアを去った後も続く場合は永続的と見なされます。この特定のケースでは、攻撃者は1つのパケットでROCを変更でき、被害者は次のROCが送信されるまで同期しなくなります）。上記の議論は、整合性変換の認証タグ内でROCを運ぶことが理にかなっているという結論につながります。

1.1. Terminology

1.1. 用語

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 [RFC2119].

この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。

2. The Transform

2. 変換

The transform, hereafter called Roll-over Counter Carrying Transform (or RCC for short), works as follows.

以下、ロールオーバーキャリング変換（または略してRCC）と呼ばれる変換は、次のように機能します。

The sender processes the RTP packet according to RFC 3711. When applying the message integrity transform, the sender checks if the SEQ is equal to 0 modulo some non-zero integer constant R. If that is the case, the sender computes the MAC in the same way as is done when using the default integrity transform (i.e., HMAC-SHA1(auth_key, Authenticated_portion || ROC)). Next, the sender truncates the MAC by 32 bits to generate MAC_tr, i.e., MAC_tr is the tag_length - 32 most significant bits of the MAC. Next, the sender constructs the tag as TAG = ROC_sender || MAC_tr, where ROC_sender is the value of his local ROC, and appends the tag to the packet. See the security considerations section for discussions on the effects of shortening the MAC. In particular, note that a tag-length of 32 bits gives no security at all.

送信者はRFC 3711に従ってRTPパケットを処理します。メッセージの整合性変換を適用する場合、送信者はseqが0モジュロに等しいかどうかをチェックします。デフォルトの整合性変換（つまり、HMAC-SHA1（auth_key、Authenticated_portion || roc）を使用する場合と同じように）。次に、送信者はMACを32ビットで切り捨ててMAC_TRを生成します。つまり、MAC_TRはTAG_LENGTH -32 MACの最も重要なビットです。次に、送信者はタグをtag = roc_senderとして構築します||Mac_tr、ROC_SENDERは彼のローカルROCの価値であり、タグをパケットに追加します。Macの短縮の影響に関する議論については、セキュリティに関する考慮事項セクションを参照してください。特に、32ビットのタグ長はまったくセキュリティを与えないことに注意してください。

If the SEQ is not equal to 0 mod R, the sender just proceeds to process the packet according to RFC 3711 without performing the actions in the previous paragraph.

SEQが0 mod Rに等しくない場合、送信者は前の段落でアクションを実行せずにRFC 3711に従ってパケットを処理するように進みます。

The value R is the rate at which the ROC is included in the SRTP packets. Since the ROC consumes four octets, this gives the possibility to use it sparsely.

値rは、ROCがSRTPパケットに含まれるレートです。ROCは4オクテットを消費するため、これによりまばらに使用する可能性があります。

When the receiver receives an SRTP packet, it processes the packet according to RFC 3711 except that during authentication processing ROC_local is replaced by ROC_sender (retrieved from the packet). This works as follows. In the step where integrity protection is to be verified, if the SEQ is equal to 0 modulo R, the receiver extracts ROC_sender from the TAG and verifies the MAC computed (in the same way as if the default integrity transform was used) over the authenticated portion of the packet (as defined in [RFC3711]), but concatenated with ROC_sender instead of concatenated with the local_ROC. The receiver generates MAC_tr for the MAC verification in the same way the sender did. Note that the session key used in the MAC calculation is dependent on the ROC, and during the derivation of the session integrity key, the ROC found in the packet under consideration MUST be used. If the verification is successful, the receiver sets his local ROC equal to the ROC carried in the packet. If the MAC does not verify, the packet MUST be dropped. The rationale for using the ROC from the packet in the MAC calculation is that if the receiver has an incorrect ROC value, MAC verification will fail, so the receiver will not correct his ROC.

受信者がSRTPパケットを受信すると、認証処理中にROC_LOCALがROC_SENDER（パケットから取得）に置き換えられることを除いて、RFC 3711に従ってパケットを処理します。これは次のように機能します。整合性保護が検証されるステップでは、SEQが0モジュロRに等しい場合、受信機はタグからROC_SENDERを抽出し、認証されたマックを検証します（デフォルトの整合性変換が使用されたのと同じ方法で）認証されています。パケットの一部（[rfc3711]で定義されている）が、local_rocと連結するのではなく、roc_senderと連結されています。受信者は、送信者が行ったのと同じように、MAC検証のMAC_TRを生成します。MAC計算で使用されるセッションキーはROCに依存しており、セッションの整合性キーの導出中に、検討中のパケットにあるROCを使用する必要があることに注意してください。検証が成功した場合、レシーバーは彼のローカルROCをパケットに運ぶROCに等しく設定します。Macが確認しない場合、パケットをドロップする必要があります。MAC計算でパケットからROCを使用する理由は、受信者にROC値が正しくない場合、MAC検証が失敗するため、受信機はROCを修正しないことです。

If the SEQ is not equal to 0 mod R, the receiver just proceeds to process the packet according to RFC 3711 without performing the actions in the previous paragraph.

SEQが0 mod Rに等しくない場合、受信者は、前の段落でアクションを実行せずにRFC 3711に従ってパケットの処理を進めます。

Since Secure Real-time Transport Control Protocol (SRTCP) already carries the entire index in-band, there is no reason to apply this transform to SRTCP. Hence, the transform SHALL only be applied to SRTP, and SHALL NOT be used with SRTCP.

安全なリアルタイムトランスポートコントロールプロトコル（SRTCP）はすでにインデックス全体を含んでいるため、この変換をSRTCPに適用する理由はありません。したがって、変換はSRTPにのみ適用され、SRTCPで使用されないものとします。

3. Transform Modes

3. 変換モード

The above transform only provides integrity protection for the packets that carry the ROC (this will be referred to as mode 1). In the cases where there is a need to integrity protect all the packets, the packets that do not have SEQ equal to 0 mod R MUST be protected using the default integrity transform (this will be referred to as mode 2).

上記の変換は、ROCを運ぶパケットの整合性保護のみを提供します（これはモード1と呼ばれます）。整合性をすべてのパケットを保護する必要がある場合には、seqが0 mod rに等しくないパケットをデフォルトの整合性変換を使用して保護する必要があります（これはモード2と呼ばれます）。

Under some circumstances, it may be acceptable not to use integrity protection on any of the packets; this will be referred to as mode 3. Without integrity protection of the packets carrying the ROC, a DoS attack, which will prevail until the next correctly received ROC, is possible. Make sure to carefully read the security considerations in Section 5 before using mode 3.

状況によっては、パケットのいずれにも整合性保護を使用しないことが許容される場合があります。これは、モード3と呼ばれます。ROCを運ぶパケットの整合性保護なしでは、次に正しく受信されたROCまで優先されるDOS攻撃が可能です。モード3を使用する前に、セクション5のセキュリティ上の考慮事項を注意深く読んでください。

In case no integrity protection is offered, i.e., mode 3, the following applies. The receiver's SRTP layer SHOULD ignore the ROC value from the packet if the application layer can indicate to it that the local ROC is synchronized with the sender (hence, the packet would be processed using the local ROC). Note that the received ROC still MUST be removed from the packet before continued processing. In this scenario, the application layer feedback to the SRTP layer need not be on a per-packet basis, and it can consist merely of a boolean value set by the application layer and read by the SRTP layer.

整合性保護が提供されていない場合、つまりモード3、次のものが適用されます。レシーバーのSRTPレイヤーは、アプリケーションレイヤーがローカルROCが送信者と同期していることを示すことができる場合、パケットからROC値を無視する必要があります（したがって、パケットはローカルROCを使用して処理されます）。受信したROCは、処理を継続する前にパケットから削除する必要があることに注意してください。このシナリオでは、SRTPレイヤーへのアプリケーションレイヤーフィードバックはパケットごとにある必要はなく、アプリケーションレイヤーによって設定され、SRTPレイヤーで読み取られたブール値だけで構成することができます。

Thus, note the following difference. Using mode 2 will integrity protect all RTP packets, but only add ROC to those having SEQ divisible by R. Using mode 1 and setting R equal to one will also integrity protect all packets, but will in addition to that add ROC to each packet. Modes 1 and 2 MUST compute the MAC in the same way as the pre-defined authentication transform for SRTP, i.e., HMAC-SHA1.

したがって、次の違いに注意してください。モード2を使用すると、整合性はすべてのRTPパケットを保護しますが、Rで分割可能な人にROCのみを追加します。モード1を使用し、rを1に設定すると、整合性がすべてのパケットを保護しますが、それに加えて各パケットにROCを追加します。モード1と2は、SRTPの事前定義された認証変換、つまりHMAC-SHA1と同じ方法でMACを計算する必要があります。

To comply with this specification, mode 1, mode 2, and mode 3 are MANDATORY to implement. However, it is up to local policy to decide which mode(s) are allowed to be used.

この仕様に準拠するには、モード1、モード2、およびモード3を実装する必要があります。ただし、どのモードを使用できるかを決定するのはローカルポリシー次第です。

4. Parameter Negotiation

4. パラメーターネゴシエーション

RCC requires that a few parameters are signaled out of band. The parameters that must be in place before the transform can be used are integrity transform mode and the rate, R, at which the ROC will be transmitted. This can be done using, e.g., MIKEY [RFC3830].

RCCでは、いくつかのパラメーターがバンドからシグナルに表示される必要があります。変換が使用される前に整備されているパラメーターは、整合性変換モードとROCが送信されるレートr rです。これは、Mikey [RFC3830]などを使用して実行できます。

To perform the parameter negotiation using MIKEY, three integrity transforms have been registered -- RCCm1, RCCm2, and RCCm3 in Table 6.10.1.c of [RFC3830] -- for the three modes defined.

Mikeyを使用してパラメーターネゴシエーションを実行するために、定義された3つのモードについて、[RFC3830]の表6.10.1.cのRCCM1、RCCM2、およびRCCM3の3つの整合性変換が登録されています。

Table 1. Integrity transforms

表1.整合性変換

                      SRTP auth alg | Value
                      --------------+------
                      RCCm1         |     2
                      RCCm2         |     3
                      RCCm3         |     4

Furthermore, the parameter R has been registered in Table 6.10.1.a of [RFC3830].

さらに、パラメーターRは[RFC3830]の表6.10.1.Aに登録されています。

Table 2. Integrity transform parameter

表2.整合性変換パラメーター

        Type | Meaning                     | Possible values
        -----+-----------------------------+----------------
         13  | ROC transmission rate       |  16-bit integer

The ROC transmission rate, R, is given in network byte order. R MUST be a non-zero unsigned integer. If the ROC transmission rate is not included in the negotiation, the default value of 1 SHALL be used.

ROC送信レートrは、ネットワークバイトの順序で与えられます。rはゼロ以外の署名の整数でなければなりません。ROC送信レートが交渉に含まれていない場合、1のデフォルト値を使用するものとします。

To have the ability to use different integrity transforms for SRTP and SRTCP, which is needed in connection to the use of RCC, the following additional parameters have been registered in Table 6.10.1.a of [RFC3830]:

RCCの使用に関連して必要なSRTPとSRTCPに異なる整合性変換を使用する機能を持つために、[RFC3830]の表6.10.1.Aに次の追加パラメーターが登録されています。

Table 3. Integrity parameters

表3.整合性パラメーター

        Type | Meaning                     | Possible values
        -----+-----------------------------+----------------
         14  | SRTP Auth. algorithm        | see below
         15  | SRTCP Auth. algorithm       | see below
         16  | SRTP Session Auth. key len  | see below
         17  | SRTCP Session Auth. key len | see below
         18  | SRTP Authentication tag len | see below
         19  | SRTCP Authentication tag len| see below

The possible values for authentication algorithms (types 14 and 15) are the same as for the "Authentication algorithm" parameter (type 2) in Table 6.10.1.a of RFC 3830 with the addition of the values found in Table 1 above.

認証アルゴリズムの可能な値（タイプ14および15）は、上記の表1に追加されたRFC 3830の表6.10.1.aの「認証アルゴリズム」パラメーター（タイプ2）の場合と同じです。

The possible values for session authentication key lengths (types 16 and 17) are the same as for the "Session Auth. key length" parameter (type 3) in Table 6.10.1.a of RFC 3830.

セッション認証キーの長さ（タイプ16および17）の可能な値は、RFC 3830の表6.10.1.aの「セッションAuth。KeyLength」パラメーター（タイプ3）の場合と同じです。

The possible values for authentication tag lengths (types 18 and 19) are the same as for the "Authentication tag length" parameter (type 11) in Table 6.10.1.a of RFC 3830 with the addition that the length of ROC MUST be included in the "Authentication tag length" parameter. This means that the minimum tag length when using RCC is 32 bits.

認証タグの長さ（タイプ18および19）の可能な値は、RFC 3830の表6.10.1.Aの「認証タグの長さ」パラメーター（タイプ11）の場合と同じです。ROCの長さを含める必要があるという追加「認証タグの長さ」パラメーター。これは、RCCを使用するときの最小タグ長が32ビットであることを意味します。

To avoid ambiguities when introducing these new parameters that have overlapping functionality to existing parameters in Table 6.10.1.a of RFC 3830, the following approach MUST be taken: If any of the parameter types 14-19 (specifying behavior specific to SRTP or SRTCP) and a corresponding general parameter (type 2, 3, or 11) are both present in the policy, the more specific parameter SHALL have precedence. For example, if the "Authentication algorithm" parameter (type 2) is set to HMAC-SHA-1, and the "SRTP Auth. Algorithm" (type 14) is set to RCCm1, SRTP will use the RCCm1 algorithm, but since there is no specific algorithm chosen for SRTCP, the more generally specified one (HMAC-SHA-1) is used.

RFC 3830の表6.10.1.Aの既存のパラメーターに機能するこれらの新しいパラメーターを導入する際に、あいまいさを回避するには、次のアプローチをとる必要があります。）および対応する一般的なパラメーター（タイプ2、3、または11）はどちらもポリシーに存在するため、より具体的なパラメーターが優先されるものとします。たとえば、「認証アルゴリズム」パラメーター（タイプ2）がHMAC-SHA-1に設定され、「SRTPAuth。Algorithm」（タイプ14）がRCCM1に設定されている場合、SRTPはRCCM1アルゴリズムを使用しますが、そこから使用されますが、SRTCPに選択された特定のアルゴリズムはなく、より一般的に指定されたアルゴリズム（HMAC-SHA-1）が使用されています。

5. Security Considerations

5. セキュリティに関する考慮事項

An analogous method already exists in SRTCP (the SRTCP index is carried in each packet under integrity protection). To the best of our knowledge, the only security consideration introduced here is that the entire SRTP index (ROC || SEQ) will become public since it is transferred without encryption. (In normal SRTP operation, only the SEQ-part of the index is disclosed.) However, RFC 3711 does not identify a need for encrypting the SRTP index.

SRTCPには類似の方法が既に存在します（SRTCPインデックスは、整合性保護下で各パケットに掲載されています）。私たちの知る限り、ここで導入された唯一のセキュリティ考慮事項は、SRTPインデックス全体（ROC || seq）全体が暗号化なしで転送されるため公開されることです。（通常のSRTP操作では、インデックスのSEQパートのみが開示されます。）ただし、RFC 3711は、SRTPインデックスを暗号化する必要性を特定しません。

It is important to realize that only every Rth packet is integrity protected in mode 1, so unless R = 1, the mechanism should be seen for what it is: a way to improve sender-receiver synchronization, and not a replacement for integrity protection.

すべてのRTHパケットのみがモード1で整合性保護されていることを認識することが重要です。したがって、r = 1でない限り、それが何であるかについてメカニズムを見る必要があります：センダーレシーバーの同期を改善する方法は、整合性保護の代替品ではありません。

The use of mode 3 (NULL-MAC) introduces a vulnerability not present in RFC 3711; namely, if an attacker modifies the ROC, the modification will go undetected by the receiver, and the receiver will lose cryptographic synchronization until the next correct ROC is received. This implies that an attacker can perform a DoS attack by only modifying every Rth packet. Because of this, mode 3 MUST only be used after proper risk assessment of the underlying network. Besides the considerations in Section 9.5 and 9.5.1 of RFC 3711, additional requirements of the underlying transport network must be met.

モード3（null-mac）を使用すると、RFC 3711に存在しない脆弱性が導入されます。つまり、攻撃者がROCを変更した場合、変更は受信機によって検出されず、受信者は次の正しいROCが受信されるまで暗号化の同期を失います。これは、攻撃者がすべてのRTHパケットを変更するだけでDOS攻撃を実行できることを意味します。このため、モード3は、基礎となるネットワークの適切なリスク評価後にのみ使用する必要があります。RFC 3711のセクション9.5および9.5.1の考慮事項に加えて、基礎となる輸送ネットワークの追加要件を満たす必要があります。

o The transport network must only consist of trusted domains. That means that everyone on the path from the source to the destination is trusted not to modify or inject packets.

o 輸送ネットワークは、信頼できるドメインでのみ構成されている必要があります。つまり、ソースから目的地までのパス上の全員が、パケットを変更または挿入しないと信頼されていることを意味します。

o The transport network must be protected from packet injection, i.e., it must be ensured that the only packets present on the path from the source to the destination(s) originate from trusted sources.

o 輸送ネットワークは、パケットインジェクションから保護する必要があります。つまり、ソースから宛先までのパスに存在するパケットのみが信頼できるソースから発生することを保証する必要があります。

o If the packets, on their way from the source to the destination(s), travel outside of a trusted domain, their integrity must be ensured (e.g., by using a Virtual Private Network (VPN) connection or a trusted leased line).

o パケットがソースから宛先に向かう途中で、信頼できるドメインの外側を移動する場合、その完全性を確保する必要があります（例えば、仮想プライベートネットワーク（VPN）接続または信頼できるリースラインを使用して）。

In the (assumed common) case that the last link to the destination(s) is a wireless link, the possibility that an attacker injects forged packets here must be carefully considered before using mode 3. Especially, if used in a broadcast setting, many destinations would be affected by the attack. However, unless R is big, this DoS attack would be similar in effect to radio jamming, which would be easier to perform.

宛先への最後のリンクがワイヤレスリンクであるという（想定される一般的な）ケースでは、モード3を使用する前に、攻撃者が鍛造パケットを注入する可能性を慎重に考慮する必要があります。目的地は攻撃の影響を受けます。ただし、Rが大きくない限り、このDOS攻撃はラジオジャミングと有効になり、実行が容易になります。

It must also be noted that if the ROC is modified by an attacker and no integrity protection is used, the output of the decryption will not be useful to the upper layers, and these must be able to cope with data that appears random. In the case integrity protection is used on the packets containing the ROC, and the ROC is modified by an attacker (and the receiver already has an approximation of the ROC, e.g., by getting it previously), the packet will be discarded and the receiver will not be able to decrypt correctly. Note, however, that the situation is better in the latter case, since the receiver now can try different ROC values in a neighborhood around the approximate value he already has.

また、ROCが攻撃者によって変更され、整合性保護が使用されない場合、復号化の出力は上層に役立たないことに注意する必要があり、これらはランダムに見えるデータに対処できる必要があります。場合、ROCを含むパケットで整合性保護が使用され、ROCは攻撃者によって変更されます（およびレシーバーは、以前に取得することにより、ROCの近似を既に持っています）、パケットは破棄され、レシーバーは廃棄されます正しく復号化することはできません。ただし、後者の場合は状況が優れていることに注意してください。レシーバーは、既に持っているおおよその値の周りの近隣で異なるROC値を試すことができるためです。

As RCC is expected to be used in a broadcast setting where group membership will be based on access to a symmetric group key, it is important to point out the following. With symmetric-key-based integrity protection, it may be as easy, if not easier, to get access to the integrity key (often a combination of a low-cost activity of purchasing a subscription and breaking the security of a terminal to extract the integrity key) as being able to transmit.

RCCは、グループメンバーシップが対称グループキーへのアクセスに基づいているブロードキャスト設定で使用されると予想されるため、以下を指摘することが重要です。対称キーベースの整合性保護により、整合性キーにアクセスするのは簡単ではないにしても簡単かもしれません（多くの場合、サブスクリプションを購入し、端末のセキュリティを破るという低コストのアクティビティの組み合わせです。整合性キー）送信できるように。

A word of warning regarding the choice of length of the authentication tag: Note that, in contrast to common MAC tags, there is a clear distinction made between the RCC authentication tag and the RCC MAC. The tag is the container holding the MAC (and for some packets also the ROC), and the MAC is the output from the MAC-algorithm (i.e., HMAC-SHA1). The length of the authentication tag with the RCC transform includes the four-octet ROC in some packets. This means that for a tag-length of n octets, there is only room for a MAC of length n - 4, i.e., a tag-length of n octets does not provide a full n-octet integrity protection on all packets. There are five cases:

認証タグの長さの選択に関する警告の単語：一般的なMacタグとは対照的に、RCC認証タグとRCC Macの間には明確な区別があることに注意してください。タグはMACを保持しているコンテナ（および一部のパケットの場合もROC）であり、MacはMac-Algorithm（つまり、HMAC-Sha1）からの出力です。RCC変換を使用した認証タグの長さには、一部のパケットに4オクテットROCが含まれます。これは、nオクテットのタグ長の場合、長さn-4のMacのためのスペースのみがあることを意味します。つまり、nオクテットのタグ長はすべてのパケットに完全なn-OCTETの完全性保護を提供しません。5つのケースがあります：

1. RCCm1 is used and tag-length is n. For those packets that SEQ = 0 mod R, the ROC is carried in the tag and occupies four octets. This leaves n - 4 octets for the MAC.

1. RCCM1が使用され、タグ長はnです。seq = 0 mod rのパケットの場合、ROCはタグに持ち込まれ、4オクテットを占有します。これにより、Macにn -4オクテットが残ります。

2. RCCm1 is used and tag-length is n. For those packets that SEQ != 0 mod R, there is no ROC carried in the tag. For RCCm1 there is no MAC on packets not carrying the ROC, so neither the length of the MAC nor the length of the tag has any relevance.

2. RCCM1が使用され、タグ長はnです。seq！= 0 mod rのパケットの場合、タグにROCが運ぶことはありません。RCCM1の場合、ROCを運ばないパケット上にMACがないため、Macの長さもタグの長さも関連性がありません。

3. RCCm2 is used and tag-length is n. For those packets that SEQ = 0 mod R, the ROC is carried in the tag and occupies four octets. This leaves n - 4 octets for the MAC (this is equivalent to case 1).

3. RCCM2が使用され、タグ長はnです。seq = 0 mod rのパケットの場合、ROCはタグに持ち込まれ、4オクテットを占有します。これにより、Macのn -4オクテットが残ります（これはケース1に相当します）。

4. RCCm2 is used and tag-length is n. For those packets that SEQ != 0 mod R, there is no ROC carried in the tag. This leaves n octets for the MAC.

4. RCCM2が使用され、タグ長はnです。seq！= 0 mod rのパケットの場合、タグにROCが運ぶことはありません。これにより、MACのnオクテットが残ります。

5. RCCm3 is used. RCCm3 does not use any MAC, but the ROC still occupies four octets in the tag for packets with SEQ = 0 mod R, so the tag-length MUST be set to four. For packets with SEQ != 0 mod R, neither the length of the MAC nor the length of the tag has any relevance.

5. RCCM3が使用されます。RCCM3はMACを使用していませんが、ROCはまだseq = 0 mod rのパケットのタグの4オクテットを占有しているため、タグ長を4に設定する必要があります。seq！= 0 mod rのパケットの場合、Macの長さもタグの長さも関連性がありません。

The conclusion is that in cases 1 and 3, the length of the MAC is shorter than the length of the authentication tag. To achieve the same (or less) MAC forgery success probability on all packets when using RCCm1 or RCCm2, as with the default integrity transform in RFC 3711, the tag-length must be set to 14 octets, which means that the length of MAC_tr is 10 octets.

結論は、ケース1と3では、Macの長さは認証タグの長さよりも短いということです。RFC 3711のデフォルトの整合性変換と同様に、RCCM1またはRCCM2を使用する場合、すべてのパケットで同じ（またはそれ以下の）Mac Forkeryの成功確率を達成するには、タグ長を14オクテットに設定する必要があります。つまり、Mac_trの長さは10オクテット。

It is recommended to set the tag-length to 14 octets when RCCm1 or RCCm2 is used, and the tag-length MUST be set to four octets when RCCm3 is used.

RCCM1またはRCCM2を使用すると、タグ長を14オクテットに設定し、RCCM3を使用する場合はタグ長を4オクテットに設定する必要があります。

6. IANA Considerations

6. IANAの考慮事項

According to Section 10 of RFC 3830, IETF consensus is required to register values in the range 0-240 in the SRTP auth alg namespace and the SRTP Type namespace.

RFC 3830のセクション10によると、IETFコンセンサスは、SRTP Auth AlgネームスペースとSRTPタイプの名前空間の範囲0-240に値を登録するために必要です。

The value 2 for RCCm1, the value 3 for RCCm2, and the value 4 for RCCm3 have been registered in the SRTP auth alg namespace as specified in Table 1 in Section 4.

RCCM1の値2、RCCM2の値3、およびRCCM3の値4は、セクション4の表1に指定されているように、SRTP Auth Algネームスペースに登録されています。

The value 13 for ROC transmission rate has been registered in the SRTP Type namespace as specified in Table 2 in Section 4.

ROC伝送速度の値13は、セクション4の表2に指定されているように、SRTPタイプの名前空間に登録されています。

The values 14 to 19 have been registered in the SRTP Type namespace according to Table 3 in Section 4.

値14〜19は、セクション4の表3に従って、SRTPタイプの名前空間に登録されています。

7. Acknowledgements

7. 謝辞

We would like to thank Nigel Dallard, Lakshminath Dondeti, and David McGrew for fruitful comments and discussions.

実り多いコメントとディスカッションについては、ナイジェルダラード、ラクシュミナートドンデティ、デビッドマクグレイルに感謝します。

8. References

8. 参考文献

8.1. Normative References

8.1. 引用文献

[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.

[RFC3830] Arkko、J.、Carrara、E.、Lindholm、F.、Naslund、M。、およびK. Norrman、「Mikey：Multimedia Internet Keying」、RFC 3830、2004年8月。

[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.

[RFC3711] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「安全なリアルタイム輸送プロトコル（SRTP）」、RFC 3711、2004年3月。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

8.2. Informative References

8.2. 参考引用

[MBMS] 3GPP TS 33.246, "3G Security; Security of Multimedia Broadcast/ Multicast Service (MBMS)", October 2006.

[MBMS] 3GPP TS 33.246、「3Gセキュリティ、マルチメディアブロードキャスト/マルチキャストサービス（MBMS）のセキュリティ」、2006年10月。

[BCMCS] 3GPP2 X.S0022-0, "Broadcast and Multicast Service in cdma2000 Wireless IP Network", February 2005.

[BCMCS] 3GPP2 X.S0022-0、「CDMA2000ワイヤレスIPネットワークの放送およびマルチキャストサービス」、2005年2月。

Authors' Addresses

著者のアドレス

Vesa Lehtovirta Ericsson Research 02420 Jorvas Finland

   Phone:  +358 9 2993314
   EMail:  vesa.lehtovirta@ericsson.com

Mats Naslund Ericsson Research SE-16480 Stockholm Sweden

   Phone:  +46 8 58533739
   EMail:  mats.naslund@ericsson.com

Karl Norrman Ericsson Research SE-16480 Stockholm Sweden

Karl Norrman Ericsson Research SE-16480ストックホルムスウェーデン

   Phone:  +46 8 4044502
   EMail:  karl.norrman@ericsson.com

Full Copyright Statement

完全な著作権声明

著作権（c）The IETF Trust（2007）。

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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.

このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFCエディター機能の資金は現在、インターネット協会によって提供されています。