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)
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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
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を同期することができません。同期エラーが表示される場所の例としては、以下のとおりです。
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.受信機は、特定の継続的なサービスのために必要な鍵と共にMIKEYメッセージにROCを受信します。彼は、しかし、送信側のシーケンス番号（SEQ）が巻き付けられており、そのため、送信者が、一方、ROCの値を増加している、その時点で数時間、後までのサービスに加入しません。ユーザがサービスに加入するとき、彼は最初に見たSRTPパケットからSEQをつかみ、インデックスを構築するために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.受信機は、配列が最近周りに包まれたサービス（例えば、SEQ = 0x0001に）参加します。送信者は、MIKEYメッセージにMIKEYメッセージを生成し、ROC（たとえば、ROC = 1）の現在の値を含みます。ラップアラウンドする前SRTPパケット、すなわち、0（例えば、SEQ = 0xFFFFの）より低いSEQと、遅延及び到達した場合MIKEYメッセージは、ROC値を読み取り、次に1にそのローカルROCを初期化し、受信機に到達します彼は見て最初のSRTPパケットなどの受信機は、受信機は、0xffffのに最高受信したシーケンス番号、S_Lを、初期化します。次に、受信機は、ゼロよりも大きいシーケンス番号を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）、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およびSRTPは、それぞれのマルチキャスト/ブロードキャストソリューション[BCMCS] [MBMS]メディア保護をストリーミングするために使用される3GPPの、で認識されています。問題4は、実際には、本質的に配列の初期化は、RTPで行われている方法によるものが存在します。
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.
問題に対処するための1つの可能なアプローチは、各SRTPパケットのMKI（マスターキー識別子）フィールドにROCを運ぶためにである可能性があります。これは、受信機はすぐにパケットの全体のインデックスを知っているという利点があります。残念ながら、MKIは、（マスターキーを指定する以外の）RFC 3711には意味を持たず、通常のRFC 3711準拠の実装は、MKIで運ばれた情報を利用することができないであろう。さらに、MKIフィールドは整合性が保護されていません。したがって、注意が同期に対する明白な攻撃を避けるようにしなければなりません。
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攻撃は、攻撃者が地域を離れた後、それが続くことができるならば、永続的とみなされ、この特定のケースでは、攻撃者が一つのパケットにROCを変更することができ、次のROCが送信されるまで、被害者は、同期の外れになります）。上記の議論は、それが変換インテグリティの認証タグ内ROCを運ぶために理にかなっているという結論につながります。
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]に記載されているように解釈されます。
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,
変換メッセージの完全性を適用する場合、配列は0モジュロに等しい場合、送信者は、そのような場合は、送信者がでMACを計算するいくつかの非ゼロ整数定数R.、RFC 3711によれば、送信者の確認をRTPパケットを処理しますデフォルトの整合性（すなわち、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.
Authenticated_portion || ROC））。 MACの32最上位ビット - 次に、送信者はMAC_trはTAG_LENGTHである、すなわち、MAC_trを生成するために、32ビットMACを切り捨てます。次に、送信者は、TAG = ROC_senderとしてタグを構築|| ROC_senderは彼の地元のROCの値であり、パケットにタグを追加しMAC_tr、。 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_senderにより置換されて認証処理ROC_local中ことを除いてRFC 3711に従ってパケットを処理します。これは次のように動作します。完全性保護は、SEQが0モジュロRに等しい場合、確認するステップにおいて、受信機は、タグからROC_senderを抽出し、認証された上（デフォルトの整合性変換の場合に使用したのと同じ方法で）MACが計算検証します（[RFC3711]で定義されるように）が、ROC_senderと連結代わりにlocal_ROCと連結パケットの一部。受信機は、送信者がやったのと同じ方法で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で使用してはなりません。
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）。すべてのパケットを保護する整合性に必要がある場合には、MOD R 0に等しい配列を持っていないパケットは（これはモード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.
いくつかの状況下では、パケットのいずれかに完全性保護を使用しないように許容され得ます。これは可能である、ROCを運ぶパケットの完全性の保護、次の正しく受信ROCまで勝つDoS攻撃、なしでモード3と呼ぶことにします。慎重にモード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が提供されていない、以下が適用されます。アプリケーション層はローカルROCが送信者（従って、パケットがローカルROCを使用して処理される）と同期していることをそれに知らせることができれば、受信機のSRTP層パケットからの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.
したがって、以下の相違点に注意してください。整合性は、すべてのRTPパケットを保護するモード2を使用して、だけにも整合性がすべてのパケットを保護する1に等しいRをモード1を使用し、設定R.割り切れる配列を有するものにROCを追加し、それに加えて、各パケットに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に準拠するためには、実装が必須です。しかし、それは使用することが許可されているモード（S）を決定するローカルポリシー次第です。
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を、変換の整合性です。これは、例えば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つの整合性変換は、登録されている - RCCm1、RCCm2、及びRCCm3 [RFC3830]の表6.10.1.cで - 定義された三つのモードのために。
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における「セッション認証キー長さ」パラメータ（タイプ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.
ROCの長さを含まなければならないことを認証タグの長さの可能な値（タイプ18及び19）を添加したRFC 3830の表6.10.1.aにおける「認証タグの長さ」パラメータ（タイプ11）と同じです「認証タグの長さ」パラメータインチこれは、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内の既存のパラメータに重複した機能を持っているこれらの新しいパラメータを導入する際にあいまいさを避けるために、以下のアプローチがとられなければならない。パラメータの型のいずれかの14-19が（SRTPまたはSRTCPに特定の動作を指定した場合）及び対応する一般的なパラメータ（タイプ2、3、または11）が、両方のポリシーに存在する、より具体的なパラメータが優先されなければなりません。 「認証アルゴリズム」パラメータ（タイプ2）はHMAC-SHA-1、及び「SRTP認証。アルゴリズム」（タイプ14）に設定されている場合、例えば、RCCm1に設定されているが、そこので、RCCm1アルゴリズムを使用するSRTP SRTCPのために選択された特別なアルゴリズム、より一般的に指定されたもの（HMAC-SHA-1）を使用しないです。
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動作において、インデックスの唯一の配列部分が開示されている。）しかし、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.
送信者、受信機の同期を改善する方法ではなく、完全性保護のための交換：R = 1ない限り、メカニズムはそれが何のために見られるべきであるように、唯一、すべてのRthパケットがモード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は、基盤となるネットワークの適切なリスク評価の後に使用しなければなりません。 9.5節およびRFC 3711の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アルゴリズム（すなわち、HMAC-SHA1）から出力されます。 RCC変換と認証タグの長さは、いくつかのパケットに4オクテットROCを含んでいます。これは、nオクテットのタグの長さのために、長さnのMACのための唯一の余地があることを意味 - 4は、すなわち、nオクテットのタグの長さは、すべてのパケット上のフルのnオクテットの完全性保護を提供していません。 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のための4つのオクテット - これは、nを残します。
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です。これらのパケットのために、配列！= 0モッズ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のための4つのオクテット（これはケース1に相当する） - これは、nを残します。
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です。これらのパケットのために、配列！= 0モッズ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モッズ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偽造成功確率を達成するために、タグの長さはMAC_trの長さがあることを意味し、14個のオクテットに設定する必要があります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つのオクテットに設定しなければなりません。
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の認証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.
第4に、表1で指定されるようRCCm1の値2、RCCm2値3、及びRCCm3の値4は、SRTPの認証ALG名前空間に登録されています。
The value 13 for ROC transmission rate has been registered in the SRTP Type namespace as specified in Table 2 in Section 4.
第4に、表2で指定されるようにROCの伝送速度の値13は、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タイプのネームスペースに登録されています。
We would like to thank Nigel Dallard, Lakshminath Dondeti, and David McGrew for fruitful comments and discussions.
私たちは、実りのコメントや議論のためのナイジェルDallard、Lakshminath Dondeti、とDavidマグリューに感謝したいと思います。
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[RFC3830] Arkko、J.、カララ、E.、リンドホルム、F.、Naslund、M.、およびK. Norrman、 "MIKEY：マルチメディアインターネットキーイング"、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.、マグリュー、D.、Naslund、M.、カララ、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[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
VESA Lehtoエリクソンパワー研究02420 Jorvasフィンランド
Phone: +358 9 2993314 EMail: vesa.lehtovirta@ericsson.com
電話：+358 9 2993314 Eメール：vesa.lehtovirta@ericsson.com
Mats Naslund Ericsson Research SE-16480 Stockholm Sweden
マッツ・ナズランドエリクソン研究SE-16480ストックホルムスウェーデン
Phone: +46 8 58533739 EMail: mats.naslund@ericsson.com
電話：+46 8 58533739 Eメール：mats.naslund@ericsson.com
Karl Norrman Ericsson Research SE-16480 Stockholm Sweden
カールNorrmanエリクソン研究SE-16480ストックホルムスウェーデン
Phone: +46 8 4044502 EMail: karl.norrman@ericsson.com
電話：+46 8 4044502 Eメール：karl.norrman@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。