RFC4771 日本語訳
4771 Integrity Transform Carrying Roll-Over Counter for the SecureReal-time Transport Protocol (SRTP). V. Lehtovirta, M. Naslund, K.Norrman. January 2007. (Format: TXT=27945 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group V. Lehtovirta
Request for Comments: 4771 M. Naslund
Category: Standards Track K. Norrman
Ericsson
January 2007
Lehtovirtaがコメントのために要求するワーキンググループV.をネットワークでつないでください: 4771年のM.ジーターカテゴリ: 標準化過程K.Norrmanエリクソン2007年1月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはSecureレアル-時間Transportプロトコル(SRTP; RFC3711を見る)のための保全変換を定義します。(ロールオーバーカウンタ(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. 序論…2 1.1. 用語…3 2. 変換…3 3. モードを変えてください…5 4. パラメタ交渉…5 5. セキュリティ問題…7 6. IANA問題…10 7. 承認…10 8. 参照…10 8.1. 標準の参照…10 8.2. 有益な参照…10
Lehtovirta, et al. Standards Track [Page 1] RFC 4771 Roll-Over Counter Carrying Transform January 2007
Lehtovirta、他 変換2007年1月に運ばれる標準化過程[1ページ]RFC4771華麗なる陰謀カウンタ
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の値を受信機に提供しなければなりません。 例えば、マイキー[RFC3830]メッセージのCommon Header有効搭載量でそれを移すことができます。 いくつかの場合、受信機はものが送付者によって使用されている彼の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を受けます。 しかしながら、彼が数時間後までサービスに参加しないので、一方、送付者はROCの値を増加させました。その時、送付者の一連番号(SEQ)のポイントは巻きつけられました。 ユーザがサービスに参加するとき、彼は1日からSEQをつかみます。インデックスを造るためにSRTPパケットを見て、ROCをprependsします。 保全保護が使用されていると、パケットは捨てられるでしょう。 保全保護が全くなければ、パケットは間違ったセッションキーを使用することで解読されるかもしれません(主要な派生率が非ゼロであるなら)、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が最近巻きつけたとき(たとえば、SEQ=0x0001)、受信機はサービスに参加します。 送付者は、マイキーメッセージを発生させて、マイキーメッセージのROC(たとえば、ROC=1)の現行価値を入れます。 マイキーメッセージは受信機に達します。(受信機は、値をROCに読み込んで、地方のROCを1に初期化します)。 今、すなわち、巻きつけて着るドレスの、前a SEQが0(たとえば、SEQは0xffffと等しい)より低いSRTPパケットが彼が見る最初のSRTPパケットとして遅れて、受信機に達すると、受信機は最も高い容認された一連番号を初期化するでしょう、s_l、0xffffに。 次に、受信機は一連番号がそれをゼロに合わせて、推論するより大きいSEQが包装したSRTP荷を受けるでしょう。 したがって、受信機は、不当に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. 同様に、初期のSEQが送付者によって無作為に選択されるので、値として0xffffの非常に近くで選択されるのが(3)に起こるかもしれません。 この場合、受信機はわずかな最初のパケットが失われているなら同期から同様に終わるかもしれません。
Lehtovirta, et al. Standards Track [Page 2] RFC 4771 Roll-Over Counter Carrying Transform January 2007
Lehtovirta、他 変換2007年1月に運ばれる標準化過程[2ページ]RFC4771華麗なる陰謀カウンタ
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.
問題を記述する1つの可能なアプローチはそれぞれのSRTPパケットのMKI(マスターKey Identifier)分野でROCを運ぶことであることができました。 これには、利点があります。受信機はすぐに、パケットで全体のインデックスを知っています。 残念ながら、MKIはRFC3711(マスターキーを指定する以外の)に意味論を全く持っていません、そして、3711年の定期的なRFC対応する実現は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攻撃はしつこいと見なされます; この場合は、攻撃者は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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. The Transform
2. 変換
The transform, hereafter called Roll-over Counter Carrying Transform (or RCC for short), works as follows.
今後オーバーRoll Counter Carrying Transform(または、略して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,
RFC3711によると、送付者はRTPパケットを処理します。 メッセージの保全変換を適用するとき、送付者が、SEQが法がケースである何らかの非ゼロ整定数R.Ifに0と等しいことであるかどうかチェックして、送付者がデフォルト保全変換を使用するとき行われるのと同じようにMACを計算する、(すなわち、HMAC-SHA1、(auth_キー
Lehtovirta, et al. Standards Track [Page 3] RFC 4771 Roll-Over Counter Carrying Transform January 2007
Lehtovirta、他 変換2007年1月に運ばれる標準化過程[3ページ]RFC4771華麗なる陰謀カウンタ
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.
認証された_部分|| ロック) すなわち、MAC_trはタグ_長さです--次に、32ビットに従って、送付者はMAC_trを発生させるようにMACに先端を切らせて、MACの32の最上位ビット。 次に、TAGがROC_送付者と等しいときに、送付者はタグを組み立てます。|| MAC_tr。(そこでは、ROC_送付者は、地元の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モッズRと等しくないなら、前のパラグラフにおける動作を実行しないで、RFC3711によると、送付者はパケットをただ処理しかけます。
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パケットを受けるとき、RFC3711によると、認証の間、地方でROC_を処理するのをROC_送付者(パケットから、検索される)に取り替えるのを除いて、それはパケットを処理します。 これは以下の通り働いています。 保全保護がSEQが法Rが0と等しいことであるなら確かめられることであるステップでは、受信機は、TAGからROC_送付者を抽出して、パケット([RFC3711]で定義されるように)の認証された部分に関して計算されますが(デフォルト保全変換が使用される同様に)、連結にされる地方の_ROCと共にの代わりにROC_送付者と共に連結されたMACについて確かめます。 受信機は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モッズRと等しくないなら、前のパラグラフにおける動作を実行しないで、RFC3711によると、受信機はパケットをただ処理しかけます。
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.
Secureレアル-時間Transport Controlプロトコル(SRTCP)が既に運ばれるので、全体がバンドで索引をつけて、この変換をSRTCPに適用する理由が全くありません。 適用されているだけであって、SHALLをSRTP、およびSHALL NOTに変えてください。したがって、SRTCPと共に使用されます。
Lehtovirta, et al. Standards Track [Page 4] RFC 4771 Roll-Over Counter Carrying Transform January 2007
Lehtovirta、他 変換2007年1月に運ばれる標準化過程[4ページ]RFC4771華麗なる陰謀カウンタ
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と呼ばれるでしょう)。 保全への必要がある場合では、すべてのパケット(保護された使用がデフォルト保全変換であったに違いない(これはモード2と呼ばれる)なら0モッズRと等しいSEQを持っていないパケット)を保護してください。
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を運ぶパケットの保全保護がなければ、DoS攻撃(次の正しく容認されたROCまで広がる)は可能です。 モード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層のSHOULDはパケットからROC値を無視します。 継続的な処理の前にパケットから容認されたROCをまだ取り外さなければならないことに注意してください。 このシナリオには、SRTP層への応用層フィードバックが1パケットあたり1個のベースにある必要はなくて、それは、応用層のそばで論理演算子選択値群から単に成って、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.Usingモード1でSEQを分割可能にするものにROCを加えるだけでしょう、そして、R同輩を1つに設定して、そこへ持ってきて各パケットにROCを加えて、保全もすべてのパケットを保護するでしょうか? SRTP(すなわち、HMAC- SHA1)のための事前に定義された認証変換と同様に、モード1と2は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は道具へのMANDATORYです。 しかしながら、どのモードが使用できるかを決めるのがローカルの方針まで達しています。
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です。 使用、例えば、マイキー[RFC3830]にこれができます。
Lehtovirta, et al. Standards Track [Page 5] RFC 4771 Roll-Over Counter Carrying Transform January 2007
Lehtovirta、他 変換2007年1月に運ばれる標準化過程[5ページ]RFC4771華麗なる陰謀カウンタ
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.
保全が変える3歳のマイキーを使用することでパラメタ交渉を実行するには、登録されてください、そうした--定義された3つのモードのための[RFC3830]のTable 6.10.1.cのRCCm1、RCCm2、およびRCCm3。
Table 1. Integrity transforms
1を見送ってください。 保全は変形します。
SRTP auth alg | Value
--------------+------
RCCm1 | 2
RCCm2 | 3
RCCm3 | 4
SRTP auth alg| 値--------------+------ RCCm1| 2 RCCm2| 3 RCCm3| 4
Furthermore, the parameter R has been registered in Table 6.10.1.a of [RFC3830].
その上、パラメタRは[RFC3830]のTable 6.10.1.aに示されました。
Table 2. Integrity transform parameter
2を見送ってください。 保全変換パラメタ
Type | Meaning | Possible values
-----+-----------------------------+----------------
13 | ROC transmission rate | 16-bit integer
タイプ| 意味| 可能な値-----+-----------------------------+---------------- 13 | ROC通信速度| 16ビットの整数
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であるなら交渉、デフォルト値に1SHALLについて含まれていません。使用されます。
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]:
SRTPとSRTCPに異なった保全変換を使用する接続でRCCの使用に必要である能力を持つために、以下の追加パラメタは[RFC3830]のTable 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
タイプ| 意味| 可能な値-----+-----------------------------+---------------- 14 | SRTP Authアルゴリズム| 15未満を見てください。| SRTCP Authアルゴリズム| 16未満を見てください。| SRTP Session Auth主要なlen| 17未満を見てください。| SRTCP Session Auth主要なlen| 18未満を見てください。| SRTP Authenticationタグlen| 19未満を見てください。| SRTCP Authenticationタグlen| 以下を見てください。
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.
Table1で見つけられた値の添加が上にある状態で、認証アルゴリズム(14と15をタイプする)のための可能な値は「認証アルゴリズム」パラメタのようにRFC3830のTable 6.10.1.aで同じです(2をタイプします)。
Lehtovirta, et al. Standards Track [Page 6] RFC 4771 Roll-Over Counter Carrying Transform January 2007
Lehtovirta、他 変換2007年1月に運ばれる標準化過程[6ページ]RFC4771華麗なる陰謀カウンタ
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をタイプする)のための可能な値が同じである、「セッションAuthキー長、」 RFC3830のTable 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.
認証タグの長さ(18と19をタイプする)のための可能な値は「認証タグの長さ」パラメタのようにRFC3830のTable 6.10.1.aで添加で同じです(11をタイプします)。ROC MUSTの長さは「認証タグの長さ」パラメタに含まれています。 これは、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.
RFC3830のTable 6.10.1.aの既存のパラメタに重なっている機能性を持っているこれらの新しいパラメタを紹介するとき、あいまいさを避けるために、以下のアプローチを取らなければなりません: パラメータの型14-19(SRTPかSRTCPに特定の振舞いを指定します)のどれかと対応する一般的指標(2、3、または11をタイプする)が方針でともに存在しているなら、より特定のパラメタSHALLには、先行があります。 「認証アルゴリズム」パラメタ(2をタイプする)が例えばHMAC-SHA-1、および"SRTP Auth"に設定されるなら。 「アルゴリズム」(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-部分だけが明らかにされます。) しかしながら、RFC3711は、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)の使用はRFC3711の現在でない脆弱性を導入します。 すなわち、攻撃者がROCを変更すると、変更は受信機で察知されずにいるでしょう、そして、次の正しいROCが受け取られているまで、受信機は暗号の同期を失うでしょう。 これは、攻撃者があらゆるRthパケットを変更するだけでDoS攻撃を実行できるのを含意します。 これのために、基本的なネットワークの適切なリスクアセスメントの後にモード3を使用するだけでよいです。 .1セクション9.5と9.5RFC3711の問題以外に、基本的な転送ネットワークの追加必要条件を満たさなければなりません。
Lehtovirta, et al. Standards Track [Page 7] RFC 4771 Roll-Over Counter Carrying Transform January 2007
Lehtovirta、他 変換2007年1月に運ばれる標準化過程[7ページ]RFC4771華麗なる陰謀カウンタ
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 パケットがソースから目的地への途中を信じられたドメインの外に移動するなら、彼らの保全を確実にしなければなりません(例えば、Virtual兵士のNetwork(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
認証タグの長さの選択に関する戒めの言葉: RCC認証タグとRCC MACの間でされた明らかな区別が一般的なMACタグと対照的になっていることに注意してください。 タグがMACを支える容器である、(いくつかのパケット、もROC)、MACはMACアルゴリズム(すなわち、HMAC-SHA1)からの出力です。 認証タグの長さ
Lehtovirta, et al. Standards Track [Page 8] RFC 4771 Roll-Over Counter Carrying Transform January 2007
Lehtovirta、他 変換2007年1月に運ばれる標準化過程[8ページ]RFC4771華麗なる陰謀カウンタ
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:
RCCと共に、変換はいくつかのパケットに4八重奏のROCを含んでいます。 これは、n八重奏のタグ長さのために、長さn--4のMACの余地しかないことを意味します、すなわち、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モッズRと等しく、ROCはタグで運ばれて、4つの八重奏を占領します。 これはn--4つの八重奏をMACに残します。
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モッズ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モッズRと等しく、ROCはタグで運ばれて、4つの八重奏を占領します。 これはn--4つの八重奏をMACに残します(これは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モッズ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モッズRにタグの4つの八重奏を占領しているので、タグ長さを4に設定しなければなりません。 0SEQ!があるパケット=モッズ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.
結論はMACの長さは場合1と3が認証タグの長さより不足しているということです。 RCCm1かRCCm2を使用するとき、タグ長さが14の八重奏へのデフォルト保全変換がRFC3711にあるセットであるに違いないので、同じように(それほど)すべてのパケットのMAC偽造成功確率を達成するために。(セットは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つの八重奏にタグ長さを設定しなければなりません。
Lehtovirta, et al. Standards Track [Page 9] RFC 4771 Roll-Over Counter Carrying Transform January 2007
Lehtovirta、他 変換2007年1月に運ばれる標準化過程[9ページ]RFC4771華麗なる陰謀カウンタ
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.
RFC3830のセクション10によると、IETFコンセンサスが、SRTP auth alg名前空間とSRTP Type名前空間における範囲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にTable1の指定されるとしての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にTable2の指定されるとしてのSRTP Type名前空間で示されました。
The values 14 to 19 have been registered in the SRTP Type namespace according to Table 3 in Section 4.
Table3に従って、値14〜19はセクション4にSRTP Type名前空間で示されました。
7. Acknowledgements
7. 承認
We would like to thank Nigel Dallard, Lakshminath Dondeti, and David McGrew for fruitful comments and discussions.
実り多いコメントと議論についてナイジェルDallard、Lakshminath Dondeti、およびデヴィッド・マグリューに感謝申し上げます。
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.、カラーラ、E.、リンドホルム、F.、ジーター、M.、およびK.Norrman、「マイキー:」 「マルチメディアインターネットの合わせる」RFC3830、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] 2004年のBaugher、M.、マグリュー、D.、ジーター、M.、カラーラ、E.、およびK.Norrman、「安全なリアルタイムのトランスポート・プロトコル(SRTP)」、RFC3711行進。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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 t33.246、「3Gセキュリティ」。 2006年10月の「マルチメディア放送/マルチキャストサービス(MBMS)のセキュリティ。」
[BCMCS] 3GPP2 X.S0022-0, "Broadcast and Multicast Service in
cdma2000 Wireless IP Network", February 2005.
2005年2月の[BCMCS]3GPP2X. S0022-0と、「cdma2000 Wireless IP Networkの放送とMulticast Service」
Lehtovirta, et al. Standards Track [Page 10] RFC 4771 Roll-Over Counter Carrying Transform January 2007
Lehtovirta、他 変換2007年1月に運ばれる標準化過程[10ページ]RFC4771華麗なる陰謀カウンタ
Authors' Addresses
作者のアドレス
Vesa Lehtovirta Ericsson Research 02420 Jorvas Finland
Vesa Lehtovirtaエリクソンの研究02420Jorvasフィンランド
Phone: +358 9 2993314 EMail: vesa.lehtovirta@ericsson.com
以下に電話をしてください。 +358 9 2993314 メール: vesa.lehtovirta@ericsson.com
Mats Naslund Ericsson Research SE-16480 Stockholm Sweden
Matsジーター・エリクソン研究SE-16480ストックホルムスウェーデン
Phone: +46 8 58533739 EMail: mats.naslund@ericsson.com
以下に電話をしてください。 +46 8 58533739 メール: 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 メール: karl.norrman@ericsson.com
Lehtovirta, et al. Standards Track [Page 11] RFC 4771 Roll-Over Counter Carrying Transform January 2007
Lehtovirta、他 変換2007年1月に運ばれる標準化過程[11ページ]RFC4771華麗なる陰謀カウンタ
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Lehtovirta, et al. Standards Track [Page 12]
Lehtovirta、他 標準化過程[12ページ]
一覧
スポンサーリンク
