RFC4347 日本語訳
4347 Datagram Transport Layer Security. E. Rescorla, N. Modadugu. April 2006. (Format: TXT=56014 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group E. Rescorla
Request for Comments: 4347 RTFM, Inc.
Category: Standards Track N. Modadugu
Stanford University
April 2006
コメントを求めるワーキンググループE.レスコラの要求をネットワークでつないでください: 4347年のRTFM Inc.カテゴリ: 標準化過程N.Modaduguスタンフォード大学2006年4月
Datagram Transport Layer Security
データグラムトランスポート層セキュリティ
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This document specifies Version 1.0 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol.
このドキュメントはデータグラムTransport Layer Security(DTLS)プロトコルのバージョン1.0を指定します。 DTLSプロトコルはコミュニケーションプライバシーをデータグラムプロトコルに提供します。 プロトコルで、クライアント/サーバ・アプリケーションは盗み聞くのを防ぐように設計されている道、改ざん、またはメッセージ偽造で伝えます。 DTLSプロトコルは、Transport Layer Security(TLS)プロトコルに基づいていて、同等なセキュリティに保証を提供します。 基本的な輸送のデータグラム意味論はDTLSプロトコルによって保存されます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Requirements Terminology ...................................3
2. Usage Model .....................................................3
3. Overview of DTLS ................................................4
3.1. Loss-Insensitive Messaging .................................4
3.2. Providing Reliability for Handshake ........................4
3.2.1. Packet Loss .........................................5
3.2.2. Reordering ..........................................5
3.2.3. Message Size ........................................5
3.3. Replay Detection ...........................................6
4. Differences from TLS ............................................6
4.1. Record Layer ...............................................6
4.1.1. Transport Layer Mapping .............................7
1. 序論…2 1.1. 要件用語…3 2. 用法モデル…3 3. DTLSの概要…4 3.1. 損失神経の鈍いメッセージング…4 3.2. 信頼性を握手に提供します…4 3.2.1. パケットの損失…5 3.2.2. Reorderingします…5 3.2.3. メッセージサイズ…5 3.3. 検出を再演してください…6 4. TLSからの違い…6 4.1. 層を記録してください…6 4.1.1. 層のマッピングを輸送してください…7
Rescorla & Modadugu Standards Track [Page 1] RFC 4347 Datagram Transport Layer Security April 2006
レスコラとModadugu規格はデータグラムトランスポート層セキュリティ2006年4月にRFC4347を追跡します[1ページ]。
4.1.1.1. PMTU Discovery .............................8
4.1.2. Record Payload Protection ...........................9
4.1.2.1. MAC ........................................9
4.1.2.2. Null or Standard Stream Cipher .............9
4.1.2.3. Block Cipher ..............................10
4.1.2.4. New Cipher Suites .........................10
4.1.2.5. Anti-replay ...............................10
4.2. The DTLS Handshake Protocol ...............................11
4.2.1. Denial of Service Countermeasures ..................11
4.2.2. Handshake Message Format ...........................13
4.2.3. Message Fragmentation and Reassembly ...............15
4.2.4. Timeout and Retransmission .........................15
4.2.4.1. Timer Values ..............................18
4.2.5. ChangeCipherSpec ...................................19
4.2.6. Finished Messages ..................................19
4.2.7. Alert Messages .....................................19
4.3. Summary of new syntax .....................................19
4.3.1. Record Layer .......................................20
4.3.2. Handshake Protocol .................................20
5. Security Considerations ........................................21
6. Acknowledgements ...............................................22
7. IANA Considerations ............................................22
8. References .....................................................22
8.1. Normative References ......................................22
8.2. Informative References ....................................23
4.1.1.1. PMTU発見…8 4.1.2. 有効搭載量保護を記録してください…9 4.1.2.1. Mac…9 4.1.2.2. ヌルの、または、標準のストリーム暗号…9 4.1.2.3. 暗号を妨げてください…10 4.1.2.4. 新しい暗号スイート…10 4.1.2.5. 反再生…10 4.2. DTLS握手プロトコル…11 4.2.1. サービス妨害対策…11 4.2.2. 握手メッセージ・フォーマット…13 4.2.3. メッセージの断片化とReassembly…15 4.2.4. タイムアウトとRetransmission…15 4.2.4.1. タイマ値…18 4.2.5. ChangeCipherSpec…19 4.2.6. メッセージを終えます…19 4.2.7. 警告メッセージ…19 4.3. 新しい構文の概要…19 4.3.1. 層を記録してください…20 4.3.2. 握手プロトコル…20 5. セキュリティ問題…21 6. 承認…22 7. IANA問題…22 8. 参照…22 8.1. 標準の参照…22 8.2. 有益な参照…23
1. Introduction
1. 序論
TLS [TLS] is the most widely deployed protocol for securing network traffic. It is widely used for protecting Web traffic and for e-mail protocols such as IMAP [IMAP] and POP [POP]. The primary advantage of TLS is that it provides a transparent connection-oriented channel. Thus, it is easy to secure an application protocol by inserting TLS between the application layer and the transport layer. However, TLS must run over a reliable transport channel -- typically TCP [TCP]. It therefore cannot be used to secure unreliable datagram traffic.
TLS[TLS]はネットワークトラフィックを確保するためのプロトコルであると最も広く配布されます。 それはウェブトラフィックを保護して、IMAP[IMAP]やPOP[POP]などのメールプロトコルに広く使用されます。 TLSのプライマリ利点は見え透いた接続指向のチャンネルを提供するということです。 したがって、応用層とトランスポート層の間にTLSを挿入することによってアプリケーション・プロトコルを保証するのは簡単です。 しかしながら、TLSは高信頼の輸送チャンネルをひかなければなりません--通常TCP[TCP]。 したがって、頼り無いデータグラムトラフィックを保証するのにそれを使用できません。
However, over the past few years an increasing number of application layer protocols have been designed that use UDP transport. In particular protocols such as the Session Initiation Protocol (SIP) [SIP] and electronic gaming protocols are increasingly popular. (Note that SIP can run over both TCP and UDP, but that there are situations in which UDP is preferable). Currently, designers of these applications are faced with a number of unsatisfactory choices. First, they can use IPsec [RFC2401]. However, for a number of reasons detailed in [WHYIPSEC], this is only suitable for some applications. Second, they can design a custom application layer security protocol. SIP, for instance, uses a subset of S/MIME to
しかしながら、過去数年間にわたってUDP輸送を使用する増加する数の応用層プロトコルが設計されています。 Session Initiationなどの特定のプロトコルでは、プロトコル(SIP)[SIP]と電子ゲーミングプロトコルはますますポピュラーです。 (SIPがTCPとUDPの両方をひくことができますが、UDPが望ましい状況があることに注意します。) 現在、これらのアプリケーションのデザイナーは多くの不十分な選択に直面しています。 まず最初に、彼らはIPsec[RFC2401]を使用できます。 しかしながら、[WHYIPSEC]で詳細な多くの理由で、これは単にいくつかのアプリケーションに適しています。 2番目に、彼らはカスタムアプリケーション層のセキュリティプロトコルを設計する場合があります。 例えば、SIPはS/MIMEのa部分集合を使用します。
Rescorla & Modadugu Standards Track [Page 2] RFC 4347 Datagram Transport Layer Security April 2006
レスコラとModadugu規格はデータグラムトランスポート層セキュリティ2006年4月にRFC4347を追跡します[2ページ]。
secure its traffic. Unfortunately, although application layer security protocols generally provide superior security properties (e.g., end-to-end security in the case of S/MIME), they typically requires a large amount of effort to design -- in contrast to the relatively small amount of effort required to run the protocol over TLS.
トラフィックを保証してください。 残念ながら、応用層セキュリティプロトコルは一般に、優れたセキュリティ資産(例えば、S/MIMEの場合における終わりから終わりへのセキュリティ)を提供しますが、彼らは設計する取り組みの多量を通常必要とします--TLSの上にプロトコルを実行するのに必要である比較的少な量の取り組みと対照して。
In many cases, the most desirable way to secure client/server applications would be to use TLS; however, the requirement for datagram semantics automatically prohibits use of TLS. Thus, a datagram-compatible variant of TLS would be very desirable. This memo describes such a protocol: Datagram Transport Layer Security (DTLS). DTLS is deliberately designed to be as similar to TLS as possible, both to minimize new security invention and to maximize the amount of code and infrastructure reuse.
多くの場合、クライアント/サーバ・アプリケーションを保証する最も望ましい方法はTLSを使用するだろうことです。 しかしながら、データグラム意味論のための要件は自動的にTLSの使用を禁止します。 したがって、TLSのデータグラムコンパチブル異形は非常に望ましいでしょう。 このメモはそのようなプロトコルについて説明します: データグラムトランスポート層セキュリティ(DTLS)。 DTLSは、できるだけTLSと同様であり、ともに新しいセキュリティ発明を最小にして、コードとインフラストラクチャ再利用の量を最大にするように故意に設計されています。
1.1. Requirements Terminology
1.1. 要件用語
In this document, the keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" are to be interpreted as described in RFC 2119 [REQ].
本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHOULD"、「」 「5月」はRFC2119[REQ]で説明されるように解釈されることになっているべきです。
2. Usage Model
2. 用法モデル
The DTLS protocol is designed to secure data between communicating applications. It is designed to run in application space, without requiring any kernel modifications.
DTLSプロトコルは、アプリケーションを伝えることの間のデータを保証するように設計されています。 それは、カーネル変更を必要としないでアプリケーションスペースに立候補するように設計されています。
Datagram transport does not require or provide reliable or in-order delivery of data. The DTLS protocol preserves this property for payload data. Applications such as media streaming, Internet telephony, and online gaming use datagram transport for communication due to the delay-sensitive nature of transported data. The behavior of such applications is unchanged when the DTLS protocol is used to secure communication, since the DTLS protocol does not compensate for lost or re-ordered data traffic.
データグラム輸送は、データの信頼できるかオーダーの配送を必要でない、または提供しません。 DTLSプロトコルはペイロードデータのためにこの特性を保持します。 メディアストリーミングや、インターネット電話や、オンラインゲームなどのアプリケーションは輸送されたデータの遅れ敏感な本質のためコミュニケーションにデータグラム輸送を使用します。 DTLSプロトコルがコミュニケーションを保証するのに使用されるとき、そのようなアプリケーションの働きは変わりがありません、DTLSプロトコルが無くなっているか再規則正しいデータ通信量を補わないので。
Rescorla & Modadugu Standards Track [Page 3] RFC 4347 Datagram Transport Layer Security April 2006
レスコラとModadugu規格はデータグラムトランスポート層セキュリティ2006年4月にRFC4347を追跡します[3ページ]。
3. Overview of DTLS
3. DTLSの概要
The basic design philosophy of DTLS is to construct "TLS over datagram". The reason that TLS cannot be used directly in datagram environments is simply that packets may be lost or reordered. TLS has no internal facilities to handle this kind of unreliability, and therefore TLS implementations break when rehosted on datagram transport. The purpose of DTLS is to make only the minimal changes to TLS required to fix this problem. To the greatest extent possible, DTLS is identical to TLS. Whenever we need to invent new mechanisms, we attempt to do so in such a way that preserves the style of TLS.
DTLSの基本的な設計理念は「データグラムの上のTLS」を組み立てることです。 単に、直接データグラム環境でTLSを使用できない理由はパケットが失われているか、または再命令されるかもしれないということです。 TLSにはこの種類の非信頼性を扱うどんな内部の施設もありません、そして、したがって、データグラム輸送のときに再接待されると、TLS実装は壊れます。 DTLSの目的はこの問題を修正するためにTLSへの最小量の変化だけを必要とさせることです。 可能な最大限まで、DTLSはTLSと同じです。 新しいメカニズムを発明するのが必要であるときはいつも、私たちは、そうTLSのスタイルを保存するそのような方法でするのを試みます。
Unreliability creates problems for TLS at two levels:
非信頼性は2つのレベルでTLSのための問題を生じさせます:
1. TLS's traffic encryption layer does not allow independent
decryption of individual records. If record N is not received,
then record N+1 cannot be decrypted.
1. TLSのトラフィック暗号化層は個々の記録の独立している復号化を許容しません。 記録Nが受信されていないなら、記録的なN+1を解読することができません。
2. The TLS handshake layer assumes that handshake messages are
delivered reliably and breaks if those messages are lost.
2. TLS握手層は、メッセージが確かに提供されるその握手を仮定して、それらのメッセージが無くなるなら、壊れます。
The rest of this section describes the approach that DTLS uses to solve these problems.
このセクションの残りはDTLSがこれらの問題を解決するのに使用するアプローチについて説明します。
3.1. Loss-Insensitive Messaging
3.1. 損失神経の鈍いメッセージング
In TLS's traffic encryption layer (called the TLS Record Layer), records are not independent. There are two kinds of inter-record dependency:
TLSのトラフィック暗号化層(TLS Record Layerと呼ばれる)の中では、記録は独立していません。 2種類の相互記録の依存があります:
1. Cryptographic context (CBC state, stream cipher key stream) is
chained between records.
1. 暗号の文脈(CBC状態、ストリーム暗号の主要なストリーム)は記録の間でチェーニングされます。
2. Anti-replay and message reordering protection are provided by a
MAC that includes a sequence number, but the sequence numbers are
implicit in the records.
2. 反再生とメッセージ再命令保護は一連番号を含んでいるMACによって提供されますが、一連番号は記録で暗に示されています。
The fix for both of these problems is straightforward and well known from IPsec ESP [ESP]: add explicit state to the records. TLS 1.1 [TLS11] is already adding explicit CBC state to TLS records. DTLS borrows that mechanism and adds explicit sequence numbers.
これらの問題の両方が簡単であるので修理して、IPsecから超能力[超能力]をよく、知っています: 明白な状態を記録に追加してください。 TLS1.1[TLS11]は既に明白なCBC状態をTLS記録に追加しています。 DTLSはそのメカニズムを借りて、明白な一連番号を加えます。
3.2. Providing Reliability for Handshake
3.2. 信頼性を握手に提供します。
The TLS handshake is a lockstep cryptographic handshake. Messages must be transmitted and received in a defined order, and any other order is an error. Clearly, this is incompatible with reordering and
TLS握手は堅苦しい暗号の握手です。 定義されたオーダーにメッセージを送って、受け取らなければなりません、そして、いかなる他のオーダーも誤りです。 そして明確に、これが再命令と非互換である。
Rescorla & Modadugu Standards Track [Page 4] RFC 4347 Datagram Transport Layer Security April 2006
レスコラとModadugu規格はデータグラムトランスポート層セキュリティ2006年4月にRFC4347を追跡します[4ページ]。
message loss. In addition, TLS handshake messages are potentially larger than any given datagram, thus creating the problem of fragmentation. DTLS must provide fixes for both of these problems.
メッセージの損失。 さらに、TLS握手メッセージはどんな与えられたデータグラムよりも潜在的に大きくて、その結果、断片化の問題を生じさせます。 DTLSはこれらの問題の両方にフィックスを提供しなければなりません。
3.2.1. Packet Loss
3.2.1. パケット損失
DTLS uses a simple retransmission timer to handle packet loss. The following figure demonstrates the basic concept, using the first phase of the DTLS handshake:
DTLSは、パケット損失を扱うのに簡単な再送信タイマーを使用します。 DTLS握手の第1段階を使用して、以下の図は基本概念を示します:
Client Server
------ ------
ClientHello ------>
クライアントサーバ------ ------ ClientHello------>。
X<-- HelloVerifyRequest
(lost)
X<--HelloVerifyRequest(無くなる)です。
[Timer Expires]
[タイマは期限が切れます]
ClientHello ------>
(retransmit)
ClientHello------>。(再送します)
Once the client has transmitted the ClientHello message, it expects to see a HelloVerifyRequest from the server. However, if the server's message is lost the client knows that either the ClientHello or the HelloVerifyRequest has been lost and retransmits. When the server receives the retransmission, it knows to retransmit. The server also maintains a retransmission timer and retransmits when that timer expires.
クライアントがいったんClientHelloメッセージを送ると、それは、サーバからHelloVerifyRequestを見ると予想します。しかしながら、サーバのメッセージが無くなるなら、クライアントは、ClientHelloかHelloVerifyRequestのどちらかが失われて、再送するのを知っています。 サーバが「再-トランスミッション」を受けるとき、それは再送するのを知っています。 サーバは、また、再送信タイマーを維持して、そのタイマが期限が切れると、再送されます。
Note: timeout and retransmission do not apply to the HelloVerifyRequest, because this requires creating state on the server.
以下に注意してください。 これが、サーバに状態を創設するのを必要とするので、タイムアウトと「再-トランスミッション」はHelloVerifyRequestに適用されません。
3.2.2. Reordering
3.2.2. Reorderingします。
In DTLS, each handshake message is assigned a specific sequence number within that handshake. When a peer receives a handshake message, it can quickly determine whether that message is the next message it expects. If it is, then it processes it. If not, it queues it up for future handling once all previous messages have been received.
DTLSでは、特定の一連番号はその握手の中でそれぞれの握手メッセージに割り当てられます。 同輩が握手メッセージを受け取るとき、それは、そのメッセージが予想する次のメッセージであるかどうかすぐに決定できます。 あるなら、それはそれを処理します。 そうでなければ、いったん前のすべてのメッセージを受け取ると、それは将来の取り扱いのためにそれの列を作ります。
3.2.3. Message Size
3.2.3. メッセージサイズ
TLS and DTLS handshake messages can be quite large (in theory up to 2^24-1 bytes, in practice many kilobytes). By contrast, UDP datagrams are often limited to <1500 bytes if fragmentation is not
TLSとDTLS握手メッセージはかなり大きい場合があります(理論上習慣多くのキロバイトにおける最大2^24-1バイト)。 対照的に、断片化が制限されないなら、UDPデータグラムは<にしばしば1500バイト制限されます。
Rescorla & Modadugu Standards Track [Page 5] RFC 4347 Datagram Transport Layer Security April 2006
レスコラとModadugu規格はデータグラムトランスポート層セキュリティ2006年4月にRFC4347を追跡します[5ページ]。
desired. In order to compensate for this limitation, each DTLS handshake message may be fragmented over several DTLS records. Each DTLS handshake message contains both a fragment offset and a fragment length. Thus, a recipient in possession of all bytes of a handshake message can reassemble the original unfragmented message.
必要。 この制限を補うために、それぞれのDTLS握手メッセージはいくつかのDTLS記録の上で断片化されるかもしれません。 それぞれのDTLS握手メッセージは断片オフセットと断片の長さの両方を含んでいます。 したがって、握手メッセージのすべてのバイトの所有物の受取人はオリジナルの非断片化しているメッセージを組み立て直すことができます。
3.3. Replay Detection
3.3. 再生検出
DTLS optionally supports record replay detection. The technique used is the same as in IPsec AH/ESP, by maintaining a bitmap window of received records. Records that are too old to fit in the window and records that have previously been received are silently discarded. The replay detection feature is optional, since packet duplication is not always malicious, but can also occur due to routing errors. Applications may conceivably detect duplicate packets and accordingly modify their data transmission strategy.
DTLSは任意に記録的な再生検出をサポートします。 使用されるテクニックは、IPsec AH/超能力、受信された記録のビットマップの窓を維持することによって、同じです。 窓をうまくはめ込むことができないくらい古い記録と以前に受け取られた記録は静かに捨てられます。 再生検出機能は任意です、パケット重複がいつも悪意があるというわけではありませんが、また、ルーティング誤りのため起こることができるので。 アプリケーションは、多分写しパケットを検出して、それに従って、それらのデータ伝送戦略を変更するかもしれません。
4. Differences from TLS
4. TLSからの違い
As mentioned in Section 3, DTLS is intentionally very similar to TLS. Therefore, instead of presenting DTLS as a new protocol, we present it as a series of deltas from TLS 1.1 [TLS11]. Where we do not explicitly call out differences, DTLS is the same as in [TLS11].
セクション3で言及されるように、DTLSは故意にTLSと非常に同様です。 したがって、新しいプロトコルとしてDTLSを寄贈することの代わりに、私たちは一連のデルタとしてTLS1.1[TLS11]からそれを提示します。 私たちが明らかに違いを呼び出さないところでは、DTLSは[TLS11]と同じです。
4.1. Record Layer
4.1. 層を記録してください。
The DTLS record layer is extremely similar to that of TLS 1.1. The only change is the inclusion of an explicit sequence number in the record. This sequence number allows the recipient to correctly verify the TLS MAC. The DTLS record format is shown below:
DTLSの記録的な層はTLS1.1のものと非常に同様です。 唯一の変化は記録での明白な一連番号の包含です。 この一連番号で、受取人は正しくTLS MACについて確かめることができます。 DTLSレコード形式は以下に示されます:
struct {
ContentType type;
ProtocolVersion version;
uint16 epoch; // New field
uint48 sequence_number; // New field
uint16 length;
opaque fragment[DTLSPlaintext.length];
} DTLSPlaintext;
struct ContentTypeタイプ; ProtocolVersionバージョン; uint16時代; //新しい分野uint48系列_番号; //新しい分野uint16の長さ; 不明瞭な断片[DTLSPlaintext.length];DTLSPlaintext。
type
Equivalent to the type field in a TLS 1.1 record.
TLS1.1記録のタイプ分野にEquivalentをタイプしてください。
version
The version of the protocol being employed. This document
describes DTLS Version 1.0, which uses the version { 254, 255
}. The version value of 254.255 is the 1's complement of DTLS
Version 1.0. This maximal spacing between TLS and DTLS version
バージョン、使われるプロトコルのバージョン。 このドキュメントはDTLSバージョン1.0について説明して、どれがバージョンを使用するか。254、255。 254.255のバージョン値はDTLSバージョン1.0の1の補数です。 TLSとDTLSバージョンの間のこの最大限度のスペース
Rescorla & Modadugu Standards Track [Page 6] RFC 4347 Datagram Transport Layer Security April 2006
レスコラとModadugu規格はデータグラムトランスポート層セキュリティ2006年4月にRFC4347を追跡します[6ページ]。
numbers ensures that records from the two protocols can be
easily distinguished. It should be noted that future on-the-wire
version numbers of DTLS are decreasing in value (while the true
version number is increasing in value.)
数は、容易に2つのプロトコルからの記録を区別できるのを確実にします。 ワイヤのDTLSの将来のバージョン番号が値に縮小していることに注意されるべきです。(真のバージョン番号が値を増やしている間。)
epoch
A counter value that is incremented on every cipher state
change.
あらゆる暗号州の変化で増加される時代A対価。
sequence_number
The sequence number for this record.
これのための一連番号が記録する系列_数。
length
Identical to the length field in a TLS 1.1 record. As in TLS
1.1, the length should not exceed 2^14.
TLS1.1の長さの分野への長さのIdenticalは記録します。 TLS1.1のように、長さは2^14を超えるべきではありません。
fragment
Identical to the fragment field of a TLS 1.1 record.
TLS1.1の断片分野への断片Identicalは記録します。
DTLS uses an explicit sequence number, rather than an implicit one, carried in the sequence_number field of the record. As with TLS, the sequence number is set to zero after each ChangeCipherSpec message is sent.
DTLSは記録の系列_ナンバーフィールドで暗黙のものよりむしろ運ばれた明白な一連番号を使用します。 TLSのように、それぞれのChangeCipherSpecメッセージを送った後にゼロに一連番号を設定します。
If several handshakes are performed in close succession, there might be multiple records on the wire with the same sequence number but from different cipher states. The epoch field allows recipients to distinguish such packets. The epoch number is initially zero and is incremented each time the ChangeCipherSpec messages is sent. In order to ensure that any given sequence/epoch pair is unique, implementations MUST NOT allow the same epoch value to be reused within two times the TCP maximum segment lifetime. In practice, TLS implementations rarely rehandshake and we therefore do not expect this to be a problem.
いくつかの握手が厳密な継承で実行されるなら、ワイヤに関する複数の記録が同じ一連番号が、異なった暗号州からあるかもしれません。 時代分野で、受取人はそのようなパケットを区別できます。 そして、初めは時代番号がそうである、ChangeCipherSpecメッセージを送るたびに増加されます。 どんな与えられた系列/時代組も確実にユニークになるようにするために、実装は、同じ時代値がTCPの最大のセグメント生涯の2回以内に再利用されるのを許容してはいけません。 習慣、したがってめったに再握手と私たちがそうしないTLS実装では、これが問題であると予想してください。
4.1.1. Transport Layer Mapping
4.1.1. トランスポート層マッピング
Each DTLS record MUST fit within a single datagram. In order to avoid IP fragmentation [MOGUL], DTLS implementations SHOULD determine the MTU and send records smaller than the MTU. DTLS implementations SHOULD provide a way for applications to determine the value of the PMTU (or, alternately, the maximum application datagram size, which is the PMTU minus the DTLS per-record overhead). If the application attempts to send a record larger than the MTU, the DTLS implementation SHOULD generate an error, thus avoiding sending a packet which will be fragmented.
それぞれのDTLS記録は単一のデータグラムの中に合わなければなりません。 IP断片化[ムガール人]を避けるために、DTLS実装SHOULDはMTUより小さくMTUを決定して、記録を送ります。 DTLS実装SHOULDはアプリケーションがPMTU(交互に1記録あたりのDTLSオーバーヘッドを引いたPMTUである最大のアプリケーションデータグラムサイズ)の値を決定する方法を提供します。 アプリケーションが、MTUより大きい記録を送るのを試みるなら、DTLS実装SHOULDはエラーを起こします、その結果、断片化されるパケットを送るのを避けます。
Rescorla & Modadugu Standards Track [Page 7] RFC 4347 Datagram Transport Layer Security April 2006
レスコラとModadugu規格はデータグラムトランスポート層セキュリティ2006年4月にRFC4347を追跡します[7ページ]。
Note that unlike IPsec, DTLS records do not contain any association identifiers. Applications must arrange to multiplex between associations. With UDP, this is presumably done with host/port number.
IPsecと異なって、DTLS記録がどんな協会識別子も含まないことに注意してください。 アプリケーションは、関係の間で多重送信するように手配しなければなりません。 おそらく、UDPと共に、ホスト/ポートナンバーでこれをします。
Multiple DTLS records may be placed in a single datagram. They are simply encoded consecutively. The DTLS record framing is sufficient to determine the boundaries. Note, however, that the first byte of the datagram payload must be the beginning of a record. Records may not span datagrams.
複数のDTLS記録が単一のデータグラムに置かれるかもしれません。 それらは単に連続してコード化されます。 DTLSの記録的な縁どりは、境界を決定するために十分です。 しかしながら、データグラムペイロードの最初のバイトが記録の始まりであるに違いないことに注意してください。 記録はデータグラムにかからないかもしれません。
Some transports, such as DCCP [DCCP] provide their own sequence numbers. When carried over those transports, both the DTLS and the transport sequence numbers will be present. Although this introduces a small amount of inefficiency, the transport layer and DTLS sequence numbers serve different purposes, and therefore for conceptual simplicity it is superior to use both sequence numbers. In the future, extensions to DTLS may be specified that allow the use of only one set of sequence numbers for deployment in constrained environments.
DCCPなどのいくつかの輸送[DCCP]がそれら自身の一連番号を提供します。 それらの輸送の上まで運ばれると、DTLSと輸送一連番号の両方が存在するでしょう。 これは少量の非能率を導入しますが、トランスポート層とDTLS一連番号は異なる役割に役立ちます、そして、したがって、概念的な簡単さにおいて、両方の一連番号を使用するのは優れています。 将来、DTLSへの1セットの一連番号だけの強制的な環境における展開の使用を許す拡大は指定されるかもしれません。
Some transports, such as DCCP, provide congestion control for traffic carried over them. If the congestion window is sufficiently narrow, DTLS handshake retransmissions may be held rather than transmitted immediately, potentially leading to timeouts and spurious retransmission. When DTLS is used over such transports, care should be taken not to overrun the likely congestion window. In the future, a DTLS-DCCP mapping may be specified to provide optimal behavior for this interaction.
DCCPなどのいくつかの輸送がそれらの上まで運ばれたトラフィックのための輻輳制御を提供します。 混雑ウィンドウが十分細長いなら、DTLS握手「再-トランスミッション」はすぐに伝えられるよりむしろ持たれているかもしれません、潜在的にタイムアウトと偽物の「再-トランスミッション」に通じて。 DTLSがそのような輸送の上で使用されるとき、ありそうな混雑ウィンドウをオーバランさせないように注意するべきです。 将来、DTLS-DCCPマッピングは、この相互作用のための最適の振舞いを提供するために指定されるかもしれません。
4.1.1.1. PMTU Discovery
4.1.1.1. PMTU発見
In general, DTLS's philosophy is to avoid dealing with PMTU issues. The general strategy is to start with a conservative MTU and then update it if events during the handshake or actual application data transport phase require it.
一般に、DTLSの哲学はPMTU問題に対処するのを避けることです。 一般的な戦略は、握手か本番適用データ伝送段階の間のイベントがそれを必要とするなら、保守的なMTUから始まって、次に、それをアップデートすることです。
The PMTU SHOULD be initialized from the interface MTU that will be used to send packets. If the DTLS implementation receives an RFC 1191 [RFC1191] ICMP Destination Unreachable message with the "fragmentation needed and DF set" Code (otherwise known as Datagram Too Big), it should decrease its PMTU estimate to that given in the ICMP message. A DTLS implementation SHOULD allow the application to occasionally reset its PMTU estimate. The DTLS implementation SHOULD also allow applications to control the status of the DF bit. These controls allow the application to perform PMTU discovery. RFC 1981 [RFC1981] procedures SHOULD be followed for IPv6.
PMTU SHOULD、パケットを送るのに使用されるインタフェースMTUから、初期化されてください。 DTLS実装が「必要である断片化とDFセット」Code(そうでなければ、データグラムToo Bigとして、知られている)と共にRFC1191[RFC1191]ICMP Destination Unreachableメッセージを受け取るなら、それはICMPメッセージで与えられたそれとPMTU見積りを減少させるべきです。 SHOULDが時折へのアプリケーションを許容するDTLS実装はPMTU見積りをリセットしました。 また、DTLS実装SHOULDはアプリケーションにDFビットの状態を制御させます。 これらのコントロールで、アプリケーションはPMTU発見を実行できます。 RFC1981[RFC1981]手順SHOULD、IPv6には、続かれてください。
Rescorla & Modadugu Standards Track [Page 8] RFC 4347 Datagram Transport Layer Security April 2006
レスコラとModadugu規格はデータグラムトランスポート層セキュリティ2006年4月にRFC4347を追跡します[8ページ]。
One special case is the DTLS handshake system. Handshake messages should be set with DF set. Because some firewalls and routers screen out ICMP messages, it is difficult for the handshake layer to distinguish packet loss from an overlarge PMTU estimate. In order to allow connections under these circumstances, DTLS implementations SHOULD back off handshake packet size during the retransmit backoff described in Section 4.2.4. For instance, if a large packet is being sent, after 3 retransmits the handshake layer might choose to fragment the handshake message on retransmission. In general, choice of a conservative initial MTU will avoid this problem.
1つの特別なケースがDTLS握手システムです。 DFがセットした状態で、握手メッセージは設定されるべきです。 いくつかのファイアウォールとルータがICMPメッセージを別々にするので、握手層が大き過ぎているPMTU見積りとパケット損失を区別するのは、難しいです。 こういう事情ですから、DTLS実装SHOULDがオフ握手パケットサイズを支持する接続を許す、セクション4.2で.4に説明されたbackoffを再送してください。 例えば、大きいパケットを送るなら、3が再送された後に握手層は、「再-トランスミッション」に関する握手メッセージを断片化するのを選ぶかもしれません。 一般に、保守的な初期のMTUの選択はこの問題を避けるでしょう。
4.1.2. Record Payload Protection
4.1.2. 有効搭載量保護を記録してください。
Like TLS, DTLS transmits data as a series of protected records. The rest of this section describes the details of that format.
TLSのように、DTLSは一連の保護された記録としてデータを送ります。 このセクションの残りはその形式の詳細について説明します。
4.1.2.1. MAC
4.1.2.1. Mac
The DTLS MAC is the same as that of TLS 1.1. However, rather than using TLS's implicit sequence number, the sequence number used to compute the MAC is the 64-bit value formed by concatenating the epoch and the sequence number in the order they appear on the wire. Note that the DTLS epoch + sequence number is the same length as the TLS sequence number.
DTLS MACはTLS1.1のものと同じです。 しかしながら、MACを計算するのに使用される一連番号は、TLSの暗黙の一連番号を使用するよりむしろ、時代を連結することによって形成された64ビットの値と彼らがワイヤの上に見えるオーダーで一連番号です。 DTLS時代+一連番号がTLS一連番号と同じ長さであることに注意してください。
TLS MAC calculation is parameterized on the protocol version number,
which, in the case of DTLS, is the on-the-wire version, i.e., {254,
255 } for DTLS 1.0.
TLS MAC計算はプロトコルバージョン番号でparameterizedされます(DTLSの場合では、ワイヤの上のバージョン、すなわち、254、DTLS1.0のための255です)。
Note that one important difference between DTLS and TLS MAC handling is that in TLS MAC errors must result in connection termination. In DTLS, the receiving implementation MAY simply discard the offending record and continue with the connection. This change is possible because DTLS records are not dependent on each other in the way that TLS records are.
DTLSとTLS MAC取り扱いの1つの重要な違いがTLS MACでは、誤りが接続終了をもたらさなければならないということであることに注意してください。 DTLSでは、受信実装は、単に怒っている記録を捨てて、接続を続行するかもしれません。 TLS記録がそうであるというDTLS記録が方法で互いに依存していないので、この変化は可能です。
In general, DTLS implementations SHOULD silently discard data with bad MACs. If a DTLS implementation chooses to generate an alert when it receives a message with an invalid MAC, it MUST generate bad_record_mac alert with level fatal and terminate its connection state.
一般に、DTLS実装SHOULDは悪いMACsと共にデータを静かに捨てます。 DTLS実装が、無効のMACと共にメッセージを受け取るとき、警戒を生成するのを選ぶなら、それは、レベルが致命的に悪い_が記録_mac警戒であると生成して、接続状態を終えなければなりません。
4.1.2.2. Null or Standard Stream Cipher
4.1.2.2. ヌルの、または、標準のストリーム暗号
The DTLS NULL cipher is performed exactly as the TLS 1.1 NULL cipher.
ちょうどTLS1.1NULLが解くようにDTLS NULL暗号は実行されます。
The only stream cipher described in TLS 1.1 is RC4, which cannot be randomly accessed. RC4 MUST NOT be used with DTLS.
TLS1.1で説明された唯一のストリーム暗号がRC4です。(手当たりしだいにそのRC4にアクセスできません)。 RC4 MUST NOT、DTLSと共に使用されてください。
Rescorla & Modadugu Standards Track [Page 9] RFC 4347 Datagram Transport Layer Security April 2006
レスコラとModadugu規格はデータグラムトランスポート層セキュリティ2006年4月にRFC4347を追跡します[9ページ]。
4.1.2.3. Block Cipher
4.1.2.3. ブロック暗号
DTLS block cipher encryption and decryption are performed exactly as with TLS 1.1.
DTLSブロック暗号暗号化と復号化はちょうどTLS1.1のように実行されます。
4.1.2.4. New Cipher Suites
4.1.2.4. 新しい暗号スイート
Upon registration, new TLS cipher suites MUST indicate whether they are suitable for DTLS usage and what, if any, adaptations must be made.
登録、それらがDTLS用法と適合がどんなであるもそうしなければならないことに適しているか否かに関係なく、暗号スイートが示さなければならない新しいTLSでは、作られてください。
4.1.2.5. Anti-replay
4.1.2.5. 反再生
DTLS records contain a sequence number to provide replay protection. Sequence number verification SHOULD be performed using the following sliding window procedure, borrowed from Section 3.4.3 of [RFC 2402].
DTLS記録は反復操作による保護を提供する一連番号を含んでいます。 一連番号検証SHOULDは使用することで実行されて、以下の滑りが手順に窓を付けるということであり、.3セクション3.4[RFC2402]から借りました。
The receiver packet counter for this session MUST be initialized to zero when the session is established. For each received record, the receiver MUST verify that the record contains a Sequence Number that does not duplicate the Sequence Number of any other record received during the life of this session. This SHOULD be the first check applied to a packet after it has been matched to a session, to speed rejection of duplicate records.
セッションが確立されるとき、このセッションのための受信機パケットカウンタをゼロに初期化しなければなりません。 それぞれの受信された記録に関しては、受信機は、記録がこのセッションの寿命の間に受け取られたいかなる他の記録のSequence NumberもコピーしないSequence Numberを含むことを確かめなければなりません。 このSHOULD、それが重複レコードの拒絶を促進するためにセッションまで合わせられた後にパケットに適用された最初のチェックになってください。
Duplicates are rejected through the use of a sliding receive window. (How the window is implemented is a local matter, but the following text describes the functionality that the implementation must exhibit.) A minimum window size of 32 MUST be supported, but a window size of 64 is preferred and SHOULD be employed as the default. Another window size (larger than the minimum) MAY be chosen by the receiver. (The receiver does not notify the sender of the window size.)
写しは拒絶されて、滑りの使用で、窓に受信されているということです。 (窓がどう実装されるかは、地域にかかわる事柄ですが、以下のテキストは実装が示さなければならない機能性について説明します。) 32の最小のウィンドウサイズをサポートしなければなりませんが、64のウィンドウサイズが好まれる、SHOULD、デフォルトとして、使われてください。 別のウィンドウサイズ(最小限より大きい)は受信機によって選ばれるかもしれません。(受信機はウィンドウサイズについて送付者に通知しません。)
The "right" edge of the window represents the highest validated Sequence Number value received on this session. Records that contain Sequence Numbers lower than the "left" edge of the window are rejected. Packets falling within the window are checked against a list of received packets within the window. An efficient means for performing this check, based on the use of a bit mask, is described in Appendix C of [RFC 2401].
窓の「正しい」縁はこのセッションで最も高い有効にされたSequence Number対価領収を表します。 窓の「左」の縁より低いSequence民数記を含む記録が拒絶されます。 窓の中に落ちるパケットは窓の中で容認されたパケットのリストに対してチェックされます。 しばらくマスクの使用に基づくこのチェックを実行するための効率的な手段は[RFC2401]のAppendix Cで説明されます。
If the received record falls within the window and is new, or if the packet is to the right of the window, then the receiver proceeds to MAC verification. If the MAC validation fails, the receiver MUST discard the received record as invalid. The receive window is updated only if the MAC verification succeeds.
受信された記録が窓の中で低下して、新しいか、または窓の右にパケットがあるなら、受信機はMAC検証に続きます。 MAC合法化が失敗するなら、受信機は無効の受信された同じくらい記録を捨てなければなりません。 窓を受けてください。MAC検証が成功する場合にだけ、アップデートします。
Rescorla & Modadugu Standards Track [Page 10] RFC 4347 Datagram Transport Layer Security April 2006
レスコラとModadugu規格はデータグラムトランスポート層セキュリティ2006年4月にRFC4347を追跡します[10ページ]。
4.2. The DTLS Handshake Protocol
4.2. DTLS握手プロトコル
DTLS uses all of the same handshake messages and flows as TLS, with three principal changes:
DTLSは同じ握手メッセージのすべてを使用して、TLSとして3回の主要な変化で流れます:
1. A stateless cookie exchange has been added to prevent denial of
service attacks.
1. 状態がないクッキー交換は、サービス不能攻撃を防ぐために加えられます。
2. Modifications to the handshake header to handle message loss,
reordering, and fragmentation.
2. メッセージの損失、再命令、および断片化を扱う握手ヘッダーへの変更。
3. Retransmission timers to handle message loss.
3. メッセージの損失を扱う再送信タイマー。
With these exceptions, the DTLS message formats, flows, and logic are the same as those of TLS 1.1.
これらの例外で、DTLSメッセージ・フォーマット、流れ、および論理はTLS1.1のものと同じです。
4.2.1. Denial of Service Countermeasures
4.2.1. サービス妨害対策
Datagram security protocols are extremely susceptible to a variety of denial of service (DoS) attacks. Two attacks are of particular concern:
データグラムセキュリティプロトコルはサービス(DoS)攻撃のさまざまな否定に非常に影響されやすいです。 2つの攻撃が特別の関心のものです:
1. An attacker can consume excessive resources on the server by
transmitting a series of handshake initiation requests, causing
the server to allocate state and potentially to perform expensive
cryptographic operations.
1. 攻撃者は、高価な暗号の操作を実行するためにサーバが状態を割り当てることを引き起こして、一連の握手開始要求を伝えるのによるサーバに潜在的に過度のリソースを消費できます。
2. An attacker can use the server as an amplifier by sending
connection initiation messages with a forged source of the victim.
The server then sends its next message (in DTLS, a Certificate
message, which can be quite large) to the victim machine, thus
flooding it.
2. 攻撃者は、アンプとして犠牲者の偽造源がある開始メッセージを接続に送ることによって、サーバを使用できます。 次に、サーバは次のメッセージ(DTLSのかなり大きい場合があるCertificateメッセージ)を犠牲マシンに送ります、その結果、それをあふれさせます。
In order to counter both of these attacks, DTLS borrows the stateless cookie technique used by Photuris [PHOTURIS] and IKE [IKE]. When the client sends its ClientHello message to the server, the server MAY respond with a HelloVerifyRequest message. This message contains a stateless cookie generated using the technique of [PHOTURIS]. The client MUST retransmit the ClientHello with the cookie added. The server then verifies the cookie and proceeds with the handshake only if it is valid. This mechanism forces the attacker/client to be able to receive the cookie, which makes DoS attacks with spoofed IP addresses difficult. This mechanism does not provide any defense against DoS attacks mounted from valid IP addresses.
これらの攻撃の両方を打ち返すために、DTLSはPhoturis[PHOTURIS]とIKE[IKE]によって使用された状態がないクッキーのテクニックを借ります。 クライアントがClientHelloメッセージをサーバに送るとき、サーバはHelloVerifyRequestメッセージで反応するかもしれません。 このメッセージは[PHOTURIS]のテクニックを使用することで生成された状態がないクッキーを含んでいます。 クッキーが加えられている状態で、クライアントはClientHelloを再送しなければなりません。 それが有効である場合にだけ、サーバは、次に、クッキーについて確かめて、握手を続けます。 このメカニズムは、攻撃者/クライアントがクッキーを受け取ることができるのを強制します。(クッキーはDoSを攻撃に偽造されたIPアドレスが難しい状態でします)。 このメカニズムは有効なIPアドレスから仕掛けられたDoS攻撃に対してどんなディフェンスも提供しません。
Rescorla & Modadugu Standards Track [Page 11] RFC 4347 Datagram Transport Layer Security April 2006
レスコラとModadugu規格はデータグラムトランスポート層セキュリティ2006年4月にRFC4347を追跡します[11ページ]。
The exchange is shown below:
交換は以下に示されます:
Client Server
------ ------
ClientHello ------>
クライアントサーバ------ ------ ClientHello------>。
<----- HelloVerifyRequest
(contains cookie)
<。----- HelloVerifyRequest(クッキーを含んでいます)
ClientHello ------>
(with cookie)
ClientHello------>。(クッキーがある)
[Rest of handshake]
[握手の残り]
DTLS therefore modifies the ClientHello message to add the cookie value.
したがって、DTLSはクッキー価値を高めるClientHelloメッセージを変更します。
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
opaque cookie<0..32>; // New field
CipherSuite cipher_suites<2..2^16-1>;
CompressionMethod compression_methods<1..2^8-1>;
} ClientHello;
struct ProtocolVersionクライアント_バージョン; ; SessionIDセッション_イド;無作為の無作為の不透明なクッキー<0..32>; //新しい分野CipherSuite暗号_スイート<2..2^16-1>; CompressionMethod圧縮_メソッド<1..2^8-1>;ClientHello。
When sending the first ClientHello, the client does not have a cookie yet; in this case, the Cookie field is left empty (zero length).
最初のClientHelloを送るとき、クライアントはまだクッキーを食べていません。 この場合、Cookie野原は空の(ゼロ・レングス)に出られます。
The definition of HelloVerifyRequest is as follows:
HelloVerifyRequestの定義は以下の通りです:
struct {
ProtocolVersion server_version;
opaque cookie<0..32>;
} HelloVerifyRequest;
struct ProtocolVersionサーバ_バージョン; 不透明なクッキー<0..32>;HelloVerifyRequest。
The HelloVerifyRequest message type is hello_verify_request(3).
HelloVerifyRequestメッセージタイプがそうである、こんにちは、__要求(3)について確かめてください。
The server_version field is defined as in TLS.
_バージョン分野がTLSで定義されるサーバ。
When responding to a HelloVerifyRequest the client MUST use the same parameter values (version, random, session_id, cipher_suites, compression_method) as it did in the original ClientHello. The server SHOULD use those values to generate its cookie and verify that they are correct upon cookie receipt. The server MUST use the same version number in the HelloVerifyRequest that it would use when sending a ServerHello. Upon receipt of the ServerHello, the client MUST verify that the server version values match.
HelloVerifyRequestに応じるとき、クライアントはそれとしての値(バージョン、無作為のセッション_イドは_スイートを解きます、圧縮_メソッド)がオリジナルのClientHelloでした同じパラメタを使用しなければなりません。 サーバSHOULDは、クッキーを生成して、それらがクッキー領収書で正しいことを確かめるのにそれらの値を使用します。 サーバはServerHelloを送るときそれが使用するHelloVerifyRequestで同じバージョン番号を使用しなければなりません。 ServerHelloを受け取り次第、クライアントは、サーババージョン値が合っていることを確かめなければなりません。
Rescorla & Modadugu Standards Track [Page 12] RFC 4347 Datagram Transport Layer Security April 2006
レスコラとModadugu規格はデータグラムトランスポート層セキュリティ2006年4月にRFC4347を追跡します[12ページ]。
The DTLS server SHOULD generate cookies in such a way that they can be verified without retaining any per-client state on the server. One technique is to have a randomly generated secret and generate cookies as: Cookie = HMAC(Secret, Client-IP, Client-Parameters)
DTLSサーバSHOULDはサーバでどんな属国も保有しないでそれらについて確かめることができるような方法でクッキーを生成します。1つのテクニックは、手当たりしだいに発生している秘密を持って、以下としてクッキーを生成することです。 クッキー=HMAC(秘密、クライアントIP、クライアントパラメタ)
When the second ClientHello is received, the server can verify that the Cookie is valid and that the client can receive packets at the given IP address.
第2ClientHelloが受け取られているとき、サーバは、Cookieが有効であり、クライアントが与えられたIPアドレスでパケットを受けることができることを確かめることができます。
One potential attack on this scheme is for the attacker to collect a number of cookies from different addresses and then reuse them to attack the server. The server can defend against this attack by changing the Secret value frequently, thus invalidating those cookies. If the server wishes that legitimate clients be able to handshake through the transition (e.g., they received a cookie with Secret 1 and then sent the second ClientHello after the server has changed to Secret 2), the server can have a limited window during which it accepts both secrets. [IKEv2] suggests adding a version number to cookies to detect this case. An alternative approach is simply to try verifying with both secrets.
この体系における1つの起こり得るかもしれない攻撃は、攻撃者が異なったアドレスから多くのクッキーを集めて、次に、サーバを攻撃するためにそれらを再利用することです。サーバは頻繁にSecret値を変えることによって、この攻撃に対して防御されることができます、その結果、それらのクッキーを無効にします。 サーバが、正統のクライアントが変遷で握手にできることを願うなら(例えば、彼らは、Secret1と共にクッキーを受けて、次に、サーバがSecret2に変化した後に第2ClientHelloを送りました)、サーバはそれが両方の秘密を受け入れる限られた窓を持つことができます。 [IKEv2]は、本件を検出するためにバージョン番号をクッキーに加えるのを示します。 代替的アプローチは両方の秘密で単に確かめてみることです。
DTLS servers SHOULD perform a cookie exchange whenever a new handshake is being performed. If the server is being operated in an environment where amplification is not a problem, the server MAY be configured not to perform a cookie exchange. The default SHOULD be that the exchange is performed, however. In addition, the server MAY choose not to do a cookie exchange when a session is resumed. Clients MUST be prepared to do a cookie exchange with every handshake.
新しい握手が実行されているときはいつも、DTLSサーバSHOULDはクッキー交換を実行します。 サーバが増幅が問題でない環境で操作されているなら、サーバは、クッキー交換を実行しないように構成されるかもしれません。 しかしながら、交換が実行されるということになってください。デフォルトSHOULD、さらに、サーバは、セッションが再開されるとき、クッキー交換をしないのを選んでもよいです。 クライアントはあらゆる握手によるクッキー交換をする用意ができていなければなりません。
If HelloVerifyRequest is used, the initial ClientHello and HelloVerifyRequest are not included in the calculation of the verify_data for the Finished message.
HelloVerifyRequestが使用されているなら、初期のClientHelloとHelloVerifyRequestが計算に含まれていない、_Finishedメッセージのためのデータについて確かめてください。
4.2.2. Handshake Message Format
4.2.2. 握手メッセージ・フォーマット
In order to support message loss, reordering, and fragmentation, DTLS modifies the TLS 1.1 handshake header:
メッセージの損失、再命令、および断片化をサポートするために、DTLSはTLS1.1握手ヘッダーを変更します:
struct {
HandshakeType msg_type;
uint24 length;
uint16 message_seq; // New field
uint24 fragment_offset; // New field
uint24 fragment_length; // New field
select (HandshakeType) {
case hello_request: HelloRequest;
case client_hello: ClientHello;
struct、seqに、//新しい分野uint24断片_が相殺されたというHandshakeType msg_タイプ; uint24の長さ; uint16メッセージ_; //新しい分野uint24の断片_長さ; //新しい分野の選んだ(HandshakeType)、_要求: こんにちは、HelloRequestをケースに入れてください; _: こんにちは、ケースクライアントClientHello
Rescorla & Modadugu Standards Track [Page 13] RFC 4347 Datagram Transport Layer Security April 2006
レスコラとModadugu規格はデータグラムトランスポート層セキュリティ2006年4月にRFC4347を追跡します[13ページ]。
case hello_verify_request: HelloVerifyRequest; // New type
case server_hello: ServerHello;
case certificate:Certificate;
case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest;
case server_hello_done:ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
case finished:Finished;
} body;
} Handshake;
ケース、こんにちは、__要求について確かめてください: HelloVerifyRequest。 //新しいタイプがサーバ_をケースに入れる、こんにちは: ServerHello。 証明書をケースに入れてください: 証明書 サーバの_の主要な_交換をケースに入れてください: ServerKeyExchange。 証明書_要求をケースに入れてください: CertificateRequest。 _行われた_: こんにちは、サーバServerHelloDoneをケースに入れてください。 ケース証明書_は以下について確かめます。 CertificateVerify。 クライアントの_の主要な_交換をケースに入れてください: ClientKeyExchange。 ケースは終わりました: 終わっています。 ボディー。 } 握手。
The first message each side transmits in each handshake always has message_seq = 0. Whenever each new message is generated, the message_seq value is incremented by one. When a message is retransmitted, the same message_seq value is used. For example:
それぞれの側が各握手で送る最初のメッセージはいつもメッセージ_seq=0を持っています。 それぞれの新しいメッセージが発生しているときはいつも、メッセージ_seq値は1つ増加されます。 メッセージが再送されるとき、同じメッセージ_seq値は使用されています。 例えば:
Client Server
------ ------
ClientHello (seq=0) ------>
クライアントサーバ------ ------ ClientHello(seq=0)------>。
X<-- HelloVerifyRequest (seq=0)
(lost)
X<--HelloVerifyRequest(seq=0)(無くなる)です。
[Timer Expires]
[タイマは期限が切れます]
ClientHello (seq=0) ------>
(retransmit)
ClientHello(seq=0)------>。(再送します)
<------ HelloVerifyRequest (seq=0)
<。------ HelloVerifyRequest(seq=0)
ClientHello (seq=1) ------>
(with cookie)
ClientHello(seq=1)------>。(クッキーがある)
<------ ServerHello (seq=1)
<------ Certificate (seq=2)
<------ ServerHelloDone (seq=3)
<。------ ServerHello(seq=1)<。------ 証明書(seq=2)<。------ ServerHelloDone(seq=3)
[Rest of handshake]
[握手の残り]
Note, however, that from the perspective of the DTLS record layer, the retransmission is a new record. This record will have a new DTLSPlaintext.sequence_number value.
しかしながら、「再-トランスミッション」がDTLSの記録的な層の見解からの、新しい記録であることに注意してください。 この記録には、新しいDTLSPlaintext.sequence_数の値があるでしょう。
DTLS implementations maintain (at least notionally) a next_receive_seq counter. This counter is initially set to zero. When a message is received, if its sequence number matches next_receive_seq, next_receive_seq is incremented and the message is
実装が次の_であることを支持する(少なくとも概念的です)DTLSは_seqカウンタを受けます。 このカウンタは初めは、ゼロに設定されます。 次の一連番号マッチ_が_seqを受けるならメッセージが受信されていて、次の_が_増加されたseqを受けて、メッセージが受けるとき
Rescorla & Modadugu Standards Track [Page 14] RFC 4347 Datagram Transport Layer Security April 2006
レスコラとModadugu規格はデータグラムトランスポート層セキュリティ2006年4月にRFC4347を追跡します[14ページ]。
processed. If the sequence number is less than next_receive_seq, the message MUST be discarded. If the sequence number is greater than next_receive_seq, the implementation SHOULD queue the message but MAY discard it. (This is a simple space/bandwidth tradeoff).
処理にされる。 一連番号が次の_以下が_seqを受けるということであるなら、メッセージを捨てなければなりません。 一連番号が次の_が_seqを受けるより大きいなら、実装SHOULDはメッセージを列に並ばせますが、それを捨てるかもしれません。 (これは簡単なスペース/帯域幅見返りです。)
4.2.3. Message Fragmentation and Reassembly
4.2.3. メッセージ断片化とReassembly
As noted in Section 4.1.1, each DTLS message MUST fit within a single transport layer datagram. However, handshake messages are potentially bigger than the maximum record size. Therefore, DTLS provides a mechanism for fragmenting a handshake message over a number of records.
セクション4.1.1で有名であることで、それぞれのDTLSメッセージは単一のトランスポート層データグラムの中に合わなければなりません。 しかしながら、握手メッセージは最大のレコード・サイズより潜在的に大きいです。 したがって、DTLSは多くの記録の上で握手メッセージを断片化するのにメカニズムを提供します。
When transmitting the handshake message, the sender divides the message into a series of N contiguous data ranges. These ranges MUST NOT be larger than the maximum handshake fragment size and MUST jointly contain the entire handshake message. The ranges SHOULD NOT overlap. The sender then creates N handshake messages, all with the same message_seq value as the original handshake message. Each new message is labelled with the fragment_offset (the number of bytes contained in previous fragments) and the fragment_length (the length of this fragment). The length field in all messages is the same as the length field of the original message. An unfragmented message is a degenerate case with fragment_offset=0 and fragment_length=length.
握手メッセージを送るとき、送付者はメッセージを一連のN隣接のデータ範囲に分割します。 これらの範囲は、最大の握手断片サイズより大きいはずがなく、共同で全体の握手メッセージを含まなければなりません。 SHOULD NOTが重ね合わせる範囲。 そして、送付者はすべてオリジナルの握手メッセージと同じメッセージ_seq値でN握手メッセージを作成します。 それぞれの新しいメッセージは断片_オフセット(前の断片に含まれたバイト数)と断片_の長さ(この断片の長さ)でラベルされます。 すべてのメッセージの長さの分野はオリジナルのメッセージの長さの分野と同じです。 非断片化しているメッセージは断片_オフセット=0がある堕落したケースです、そして、断片_長さは長さと等しいです。
When a DTLS implementation receives a handshake message fragment, it MUST buffer it until it has the entire handshake message. DTLS implementations MUST be able to handle overlapping fragment ranges. This allows senders to retransmit handshake messages with smaller fragment sizes during path MTU discovery.
DTLS実装が握手メッセージ断片を受けるとき、全体の握手メッセージがあるまで、それはそれをバッファリングしなければなりません。 DTLS実装は重なっている断片範囲を扱うことができなければなりません。 これで、送付者は経路MTU探索の間、より小さい断片サイズで握手メッセージを再送できます。
Note that as with TLS, multiple handshake messages may be placed in the same DTLS record, provided that there is room and that they are part of the same flight. Thus, there are two acceptable ways to pack two DTLS messages into the same datagram: in the same record or in separate records.
複数の握手メッセージがTLSなら、余地があれば同じDTLS記録に置かれるかもしれなくて、彼らが同じ飛行の一部であることに注意してください。 したがって、2つのDTLSメッセージに同じデータグラムに詰め込む2つの許容できる方法があります: 同じ記録か別々の記録で。
4.2.4. Timeout and Retransmission
4.2.4. タイムアウトとRetransmission
DTLS messages are grouped into a series of message flights, according to the diagrams below. Although each flight of messages may consist of a number of messages, they should be viewed as monolithic for the purpose of timeout and retransmission.
以下のダイヤグラムによると、DTLSメッセージは一連のメッセージ飛行に分類されます。 メッセージの各飛行は多くのメッセージから成るかもしれませんが、それらはタイムアウトと「再-トランスミッション」の目的のために一枚岩的であるとして見なされるべきです。
Rescorla & Modadugu Standards Track [Page 15] RFC 4347 Datagram Transport Layer Security April 2006
レスコラとModadugu規格はデータグラムトランスポート層セキュリティ2006年4月にRFC4347を追跡します[15ページ]。
Client Server
------ ------
クライアントサーバ------ ------
ClientHello --------> Flight 1
ClientHello--------最初の>便
<------- HelloVerifyRequest Flight 2
<。------- 第2HelloVerifyRequest便
ClientHello --------> Flight 3
ClientHello--------第3>便
ServerHello \
Certificate* \
ServerKeyExchange* Flight 4
CertificateRequest* /
<-------- ServerHelloDone /
第4ServerKeyExchange*便 ServerHello\証明書*\CertificateRequest*/<。-------- ServerHelloDone/
Certificate* \
ClientKeyExchange \
CertificateVerify* Flight 5
[ChangeCipherSpec] /
Finished --------> /
第5便[ChangeCipherSpec]/終わった状態で*\ClientKeyExchange\CertificateVerify*を証明してください。-------->/
[ChangeCipherSpec] \ Flight 6
<-------- Finished /
第6[ChangeCipherSpec]\便 <。-------- 終わっている/
Figure 1. Message flights for full handshake
図1。 完全な握手へのメッセージフライト
Client Server
------ ------
クライアントサーバ------ ------
ClientHello --------> Flight 1
ClientHello--------最初の>便
ServerHello \
[ChangeCipherSpec] Flight 2
<-------- Finished /
第2ServerHello\[ChangeCipherSpec]便 <。-------- 終わっている/
[ChangeCipherSpec] \Flight 3
Finished --------> /
第3[ChangeCipherSpec]\便は終わりました。-------->/
Figure 2. Message flights for session-resuming handshake
(no cookie exchange)
図2。 セッションを再開する握手へのメッセージフライト(クッキー交換がありません)
DTLS uses a simple timeout and retransmission scheme with the following state machine. Because DTLS clients send the first message (ClientHello), they start in the PREPARING state. DTLS servers start in the WAITING state, but with empty buffers and no retransmit timer.
DTLSは以下の州のマシンがある簡単なタイムアウトと「再-トランスミッション」体系を使用します。 DTLSクライアントが最初のメッセージ(ClientHello)を送るので、彼らはPREPARING状態で始まります。 DTLSサーバはWAITING状態にもかかわらず、空のバッファにもかかわらず、どんな再送信タイマからも始まりません。
Rescorla & Modadugu Standards Track [Page 16] RFC 4347 Datagram Transport Layer Security April 2006
レスコラとModadugu規格はデータグラムトランスポート層セキュリティ2006年4月にRFC4347を追跡します[16ページ]。
+-----------+
| PREPARING |
+---> | | <--------------------+
| | | |
| +-----------+ |
| | |
| | |
| | Buffer next flight |
| | |
| \|/ |
| +-----------+ |
| | | |
| | SENDING |<------------------+ |
| | | | | Send
| +-----------+ | | HelloRequest
Receive | | | |
next | | Send flight | | or
flight | +--------+ | |
| | | Set retransmit timer | | Receive
| | \|/ | | HelloRequest
| | +-----------+ | | Send
| | | | | | ClientHello
+--)--| WAITING |-------------------+ |
| | | | Timer expires | |
| | +-----------+ | |
| | | | |
| | | | |
| | +------------------------+ |
| | Read retransmit |
Receive | | |
last | | |
flight | | |
| | |
\|/\|/ |
|
+-----------+ |
| | |
| FINISHED | -------------------------------+
| |
+-----------+
+-----------+ | 準備| +--->|、| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--+ | | | | | +-----------+ | | | | | | | | | 次の飛行をバッファリングしてください。| | | | | \|/ | | +-----------+ | | | | | | | 発信します。| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--+ | | | | | | 発信してください。| +-----------+ | | HelloRequestは受信します。| | | | 次へ| | 飛行を送ってください。| | または、飛行| +--------+ | | | | | 再送信タイマを設定してください。| | 受信してください。| | \|/ | | HelloRequest| | +-----------+ | | 発信してください。| | | | | | ClientHello+--、)、--| 待ち|-------------------+ | | | | | タイマは期限が切れます。| | | | +-----------+ | | | | | | | | | | | | | | +------------------------+ | | | 読まれて、再送してください。| 受信してください。| | | 最終| | | 飛行| | | | | | \|/\|/ | | +-----------+ | | | | | 終わっています。| -------------------------------+ | | +-----------+
Figure 3. DTLS timeout and retransmission state machine
図3。 タイムアウトと「再-トランスミッション」州が機械加工するDTLS
The state machine has three basic states.
州のマシンには、3つの基本的な州があります。
Rescorla & Modadugu Standards Track [Page 17] RFC 4347 Datagram Transport Layer Security April 2006
レスコラとModadugu規格はデータグラムトランスポート層セキュリティ2006年4月にRFC4347を追跡します[17ページ]。
In the PREPARING state the implementation does whatever computations are necessary to prepare the next flight of messages. It then buffers them up for transmission (emptying the buffer first) and enters the SENDING state.
PREPARING状態では、実装はどんなメッセージの次の飛行を準備するのに必要な計算もします。 それは、次に、トランスミッション(最初に、バッファを空にする)のためにそれらをバッファリングして、SENDING状態に入ります。
In the SENDING state, the implementation transmits the buffered flight of messages. Once the messages have been sent, the implementation then enters the FINISHED state if this is the last flight in the handshake. Or, if the implementation expects to receive more messages, it sets a retransmit timer and then enters the WAITING state.
SENDING状態では、実装はメッセージのバッファリングされた飛行を伝えます。 一度、メッセージを送ったことがあって、次に、実装はこれが握手で最後の飛行であるならFINISHED状態に入力します。 または、実装が、より多くのメッセージを受け取ると予想するなら、それは、再送信タイマを設定して、次に、WAITING状態に入れます。
There are three ways to exit the WAITING state:
WAITING状態を出る3つの方法があります:
1. The retransmit timer expires: the implementation transitions to
the SENDING state, where it retransmits the flight, resets the
retransmit timer, and returns to the WAITING state.
1. 再送信タイマは期限が切れます: 実装はSENDING状態に移行します。そこでは、それは、飛行を再送して、再送信タイマをリセットして、WAITING状態に戻ります。
2. The implementation reads a retransmitted flight from the peer:
the implementation transitions to the SENDING state, where it
retransmits the flight, resets the retransmit timer, and returns
to the WAITING state. The rationale here is that the receipt of a
duplicate message is the likely result of timer expiry on the peer
and therefore suggests that part of one's previous flight was
lost.
2. 実装は同輩からの再送されたフライトを読みます: 実装はSENDING状態に移行します。そこでは、それは、飛行を再送して、再送信タイマをリセットして、WAITING状態に戻ります。 ここの原理は写しメッセージの領収書が、同輩の上のタイマ満期の起こりそうな結果であり、したがって、人の前の飛行の一部が失われたと示唆するということです。
3. The implementation receives the next flight of messages: if
this is the final flight of messages, the implementation
transitions to FINISHED. If the implementation needs to send a
new flight, it transitions to the PREPARING state. Partial reads
(whether partial messages or only some of the messages in the
flight) do not cause state transitions or timer resets.
3. 実装はメッセージの次の飛行を受けます: これがメッセージの最終的な飛行であるなら、実装はFINISHEDに移行します。 実装が、新しい飛行を送る必要があるなら、それはPREPARING状態に移行します。 部分的な読書(部分的なメッセージか飛行におけるメッセージのいくつかだけであることにかかわらず)は状態遷移かタイマリセットを引き起こしません。
Because DTLS clients send the first message (ClientHello), they start in the PREPARING state. DTLS servers start in the WAITING state, but with empty buffers and no retransmit timer.
DTLSクライアントが最初のメッセージ(ClientHello)を送るので、彼らはPREPARING状態で始まります。 DTLSサーバはWAITING状態にもかかわらず、空のバッファにもかかわらず、どんな再送信タイマからも始まりません。
When the server desires a rehandshake, it transitions from the FINISHED state to the PREPARING state to transmit the HelloRequest. When the client receives a HelloRequest it transitions from FINISHED to PREPARING to transmit the ClientHello.
サーバが再握手を望んでいるとき、それは、HelloRequestを伝えるためにFINISHED状態からPREPARING状態に移行します。 クライアントがHelloRequestを受け取るとき、それは、ClientHelloを伝えるためにFINISHEDからPREPARINGに移行します。
4.2.4.1. Timer Values
4.2.4.1. タイマ値
Though timer values are the choice of the implementation, mishandling of the timer can lead to serious congestion problems; for example, if many instances of a DTLS time out early and retransmit too quickly on a congested link. Implementations SHOULD use an initial timer value
タイマ値は実装の選択ですが、タイマを誤って扱うのは重大な混雑問題を引き起こすことができます。 例えば、多くが早くDTLSタイムアウトについて例証して、あまりにすばやく再送する、混雑しているリンク。 実装SHOULDは初期のタイマ値を使用します。
Rescorla & Modadugu Standards Track [Page 18] RFC 4347 Datagram Transport Layer Security April 2006
レスコラとModadugu規格はデータグラムトランスポート層セキュリティ2006年4月にRFC4347を追跡します[18ページ]。
of 1 second (the minimum defined in RFC 2988 [RFC2988]) and double the value at each retransmission, up to no less than the RFC 2988 maximum of 60 seconds. Note that we recommend a 1-second timer rather than the 3-second RFC 2988 default in order to improve latency for time-sensitive applications. Because DTLS only uses retransmission for handshake and not dataflow, the effect on congestion should be minimal.
1秒(RFC2988[RFC2988]で定義された最小限)と少なくとも60秒のRFC2988最大までの各「再-トランスミッション」の値の二重について。 私たちが時間敏感なアプリケーションのために潜在を改良するために3秒のRFC2988デフォルトよりむしろ1秒のタイマを推薦することに注意してください。 DTLSがデータフローではなく、握手に「再-トランスミッション」を使用するだけであるので、混雑への効果は最小限であるべきです。
Implementations SHOULD retain the current timer value until a transmission without loss occurs, at which time the value may be reset to the initial value. After a long period of idleness, no less than 10 times the current timer value, implementations may reset the timer to the initial value. One situation where this might occur is when a rehandshake is used after substantial data transfer.
値がどの時に初期の値にリセットされるかもしれないかとき損失のないトランスミッションが起こるまで、実装SHOULDは現在のタイマ値を保有します。 長期の怠惰の後に、少なくとも現在のタイマ値の10倍、実装は初期の値にタイマをリセットするかもしれません。 これが起こるかもしれない1つの状況が再握手がかなりのデータ転送の後に使用される時です。
4.2.5. ChangeCipherSpec
4.2.5. ChangeCipherSpec
As with TLS, the ChangeCipherSpec message is not technically a handshake message but MUST be treated as part of the same flight as the associated Finished message for the purposes of timeout and retransmission.
TLSと共にChangeCipherSpecメッセージを技術的に握手メッセージではありませんが、タイムアウトと「再-トランスミッション」の目的への関連Finishedメッセージと同じフライトの一部として扱わなければならないとき。
4.2.6. Finished Messages
4.2.6. 終わっているメッセージ
Finished messages have the same format as in TLS. However, in order to remove sensitivity to fragmentation, the Finished MAC MUST be computed as if each handshake message had been sent as a single fragment. Note that in cases where the cookie exchange is used, the initial ClientHello and HelloVerifyRequest MUST NOT be included in the Finished MAC.
終わっているメッセージには、同じ形式がTLSのようにあります。 しかしながら、感度を断片化に移すために、まるでただ一つの断片としてそれぞれの握手メッセージを送ったかのようにFinished Macを計算しなければなりません。 クッキー交換が使用されている場合では、Finished MACに初期のClientHelloとHelloVerifyRequestを含んではいけないことに注意してください。
4.2.7. Alert Messages
4.2.7. 警告メッセージ
Note that Alert messages are not retransmitted at all, even when they occur in the context of a handshake. However, a DTLS implementation SHOULD generate a new alert message if the offending record is received again (e.g., as a retransmitted handshake message). Implementations SHOULD detect when a peer is persistently sending bad messages and terminate the local connection state after such misbehavior is detected.
握手の文脈に起こったら、Alertメッセージが全く再送されないことに注意してください。 しかしながら、再び(例えば、再送された握手メッセージとして)SHOULDが怒っている記録であるなら新しい警告メッセージを生成するDTLS実装を受け取ります。 実装SHOULDは同輩がいつ悪いメッセージを持続して送るかを検出して、そのような不正行為が検出された後に市内接続状態を終えます。
4.3. Summary of new syntax
4.3. 新しい構文の概要
This section includes specifications for the data structures that have changed between TLS 1.1 and DTLS.
このセクションはTLS1.1とDTLSの間で変化したデータ構造のための仕様を含んでいます。
Rescorla & Modadugu Standards Track [Page 19] RFC 4347 Datagram Transport Layer Security April 2006
レスコラとModadugu規格はデータグラムトランスポート層セキュリティ2006年4月にRFC4347を追跡します[19ページ]。
4.3.1. Record Layer
4.3.1. 層を記録してください。
struct {
ContentType type;
ProtocolVersion version;
uint16 epoch; // New field
uint48 sequence_number; // New field
uint16 length;
opaque fragment[DTLSPlaintext.length];
} DTLSPlaintext;
struct ContentTypeタイプ; ProtocolVersionバージョン; uint16時代; //新しい分野uint48系列_番号; //新しい分野uint16の長さ; 不明瞭な断片[DTLSPlaintext.length];DTLSPlaintext。
struct {
ContentType type;
ProtocolVersion version;
uint16 epoch; // New field
uint48 sequence_number; // New field
uint16 length;
opaque fragment[DTLSCompressed.length];
} DTLSCompressed;
struct ContentTypeタイプ; ProtocolVersionバージョン; uint16時代; //新しい分野uint48系列_番号; //新しい分野uint16の長さ; 不明瞭な断片[DTLSCompressed.length];DTLSCompressed。
struct {
ContentType type;
ProtocolVersion version;
uint16 epoch; // New field
uint48 sequence_number; // New field
uint16 length;
select (CipherSpec.cipher_type) {
case block: GenericBlockCipher;
} fragment;
} DTLSCiphertext;
ContentTypeはuint16時代; _番号(//新しい分野uint16の長さ)が選択する//新しい分野uint48系列をタイプします; ProtocolVersionバージョン;。struct、(CipherSpec.cipher_はタイプされます) ブロックをケースに入れてください: GenericBlockCipher、断片化してください;、DTLSCiphertext。
4.3.2. Handshake Protocol
4.3.2. 握手プロトコル
enum {
hello_request(0), client_hello(1), server_hello(2),
hello_verify_request(3), // New field
certificate(11), server_key_exchange (12),
certificate_request(13), server_hello_done(14),
certificate_verify(15), client_key_exchange(16),
finished(20), (255)
} HandshakeType;
(2)、こんにちは。enum、こんにちは、_要求(0)、クライアント_、こんにちは、(1)、サーバ_、こんにちは、__要求(3)について確かめてください、//新しい分野証明書(11)、サーバの_の主要な_交換(12)が_要求(13)を証明する、サーバ_、こんにちは、(14)、証明書_が行われた_が(15)、クライアントの_の主要な_交換(16)、終わっている(20)、(255)について確かめる、HandshakeType。
struct {
HandshakeType msg_type;
uint24 length;
uint16 message_seq; // New field
uint24 fragment_offset; // New field
uint24 fragment_length; // New field
struct、seqに、//新しい分野uint24断片_が相殺されたというHandshakeType msg_タイプ; uint24の長さ; uint16メッセージ_; //新しい分野uint24の断片_長さ; //新しい分野
Rescorla & Modadugu Standards Track [Page 20] RFC 4347 Datagram Transport Layer Security April 2006
レスコラとModadugu規格はデータグラムトランスポート層セキュリティ2006年4月にRFC4347を追跡します[20ページ]。
select (HandshakeType) {
case hello_request: HelloRequest;
case client_hello: ClientHello;
case server_hello: ServerHello;
case hello_verify_request: HelloVerifyRequest; // New field
case certificate:Certificate;
case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest;
case server_hello_done:ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
case finished:Finished;
} body;
} Handshake;
__要求について確かめてください: HelloVerifyRequest。(HandshakeType)を選択してください、_要求: こんにちは、HelloRequestをケースに入れてください; : こんにちは、ClientHello_: (こんにちは、ケースサーバServerHello)がケースに入れるクライアント_をケースに入れてください、こんにちは、//新しい分野ケース証明書: 証明書; ケースサーバ_キー_交換: ServerKeyExchange; ケース証明書_要求: CertificateRequest; _行われた_: こんにちは、サーバServerHelloDoneをケースに入れてください; _が確かめる証明書をケースに入れてください: CertificateVerify; ケースクライアント_キー_交換: ClientKeyExchange; ケースは終わりました: 終わっています;、ボディー。 } 握手。
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
opaque cookie<0..32>; // New field
CipherSuite cipher_suites<2..2^16-1>;
CompressionMethod compression_methods<1..2^8-1>;
} ClientHello;
struct ProtocolVersionクライアント_バージョン; ; SessionIDセッション_イド;無作為の無作為の不透明なクッキー<0..32>; //新しい分野CipherSuite暗号_スイート<2..2^16-1>; CompressionMethod圧縮_メソッド<1..2^8-1>;ClientHello。
struct {
ProtocolVersion server_version;
opaque cookie<0..32>;
} HelloVerifyRequest;
struct ProtocolVersionサーバ_バージョン; 不透明なクッキー<0..32>;HelloVerifyRequest。
5. Security Considerations
5. セキュリティ問題
This document describes a variant of TLS 1.1 and therefore most of the security considerations are the same as those of TLS 1.1 [TLS11], described in Appendices D, E, and F.
このドキュメントはTLS1.1の異形について説明します、そして、したがって、セキュリティ問題の大部分はAppendices D、E、およびFで説明されたTLS1.1[TLS11]のものと同じです。
The primary additional security consideration raised by DTLS is that of denial of service. DTLS includes a cookie exchange designed to protect against denial of service. However, implementations which do not use this cookie exchange are still vulnerable to DoS. In particular, DTLS servers which do not use the cookie exchange may be used as attack amplifiers even if they themselves are not experiencing DoS. Therefore, DTLS servers SHOULD use the cookie exchange unless there is good reason to believe that amplification is not a threat in their environment. Clients MUST be prepared to do a cookie exchange with every handshake.
DTLSによって上げられたプライマリ追加担保の考慮はサービスの否定のものです。 DTLSはサービスの否定から守るように設計されたクッキー交換を含んでいます。 しかしながら、このクッキー交換を使用しない実装はまだDoSに被害を受け易いです。 DoSを経験していなくても、特に、クッキー交換を使用しないDTLSサーバは攻撃アンプとして使用されるかもしれません。 したがって、増幅が脅威でないと信じるために彼らの環境でもっともな理由がない場合、DTLSサーバSHOULDはクッキー交換を使用します。 クライアントはあらゆる握手によるクッキー交換をする用意ができていなければなりません。
Rescorla & Modadugu Standards Track [Page 21] RFC 4347 Datagram Transport Layer Security April 2006
レスコラとModadugu規格はデータグラムトランスポート層セキュリティ2006年4月にRFC4347を追跡します[21ページ]。
6. Acknowledgements
6. 承認
The authors would like to thank Dan Boneh, Eu-Jin Goh, Russ Housley, Constantine Sapuntzakis, and Hovav Shacham for discussions and comments on the design of DTLS. Thanks to the anonymous NDSS reviewers of our original NDSS paper on DTLS [DTLS] for their comments. Also, thanks to Steve Kent for feedback that helped clarify many points. The section on PMTU was cribbed from the DCCP specification [DCCP]. Pasi Eronen provided a detailed review of this specification. Helpful comments on the document were also received from Mark Allman, Jari Arkko, Joel Halpern, Ted Hardie, and Allison Mankin.
作者はDTLSのデザインの議論とコメントについてダンBoneh、ユー-チン・ゴー、ラスHousley、コンスタンティーヌSapuntzakis、およびHovav Shachamに感謝したがっています。 彼らのコメントをDTLS[DTLS]に関する私たちのオリジナルのNDSS紙の匿名のNDSS評論家をありがとうございます。 また、助けたフィードバックのためのスティーブ・ケントへの感謝は多くのポイントはっきりさせます。 PMTUの上のセクションはDCCP仕様[DCCP]から盗用されました。 パシEronenはこの仕様の詳細なレビューを提供しました。 また、マーク・オールマン、ヤリArkko、ジョエル・アルペルン、テッド・ハーディー、およびアリソン・マンキンからドキュメントにおける役に立つコメントを受けました。
7. IANA Considerations
7. IANA問題
This document uses the same identifier space as TLS [TLS11], so no new IANA registries are required. When new identifiers are assigned for TLS, authors MUST specify whether they are suitable for DTLS.
このドキュメントがTLS[TLS11]と同じ識別子スペースを使用するので、どんな新しいIANA登録も必要ではありません。 新しい識別子がTLSのために割り当てられるとき、作者は、彼らがDTLSに適当であるかどうか指定しなければなりません。
This document defines a new handshake message, hello_verify_request, whose value has been allocated from the TLS HandshakeType registry defined in [TLS11]. The value "3" has been assigned by the IANA.
このドキュメントが新しい握手メッセージを定義する、こんにちは。_値が[TLS11]で定義されたTLS HandshakeType登録から割り当てられた_要求について確かめてください。 「3インチはIANAによって割り当てられた」値。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[RFC1191] ムガール人とJ.とS.デアリング、「経路MTU探索」、RFC1191、1990年11月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, August 1996.
[RFC1981] マッキャン、J.、デアリング、S.、およびJ.ムガール人、「IPのための経路MTUディスカバリー、バージョン6インチ、RFC1981、1996インチ年8月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Timer", RFC 2988, November 2000.
[RFC2988] パクソンとV.とM.オールマン、「コンピューティングTCPの再送信タイマー」、RFC2988、2000年11月。
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[TCP] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[TLS11] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[TLS11] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。
Rescorla & Modadugu Standards Track [Page 22] RFC 4347 Datagram Transport Layer Security April 2006
レスコラとModadugu規格はデータグラムトランスポート層セキュリティ2006年4月にRFC4347を追跡します[22ページ]。
8.2. Informative References
8.2. 有益な参照
[AESCACHE] Bernstein, D.J., "Cache-timing attacks on AES"
http://cr.yp.to/antiforgery/cachetiming-20050414.pdf.
[AESCACHE]バーンスタイン、D.J.、「AESに対するキャッシュタイミング攻撃」 http://cr.yp.to/antiforgery/cachetiming-20050414.pdf 。
[AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[ああ] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。
[DCCP] Kohler, E., Handley, M., Floyd, S., Padhye, J., "Datagram
Congestion Control Protocol", Work in Progress, 10 March
2005.
[DCCP] コーラー、E.、ハンドレー、M.、フロイド、S.、Padhye、J.、「データグラム混雑制御プロトコル」が進歩、2005年3月10日に働いています。
[DNS] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[DNS]Mockapetris、P.、「ドメイン名--、実現と仕様、」、STD13、RFC1035、11月1987日
[DTLS] Modadugu, N., Rescorla, E., "The Design and Implementation
of Datagram TLS", Proceedings of ISOC NDSS 2004, February
2004.
[DTLS]Modadugu、N.、レスコラ、E.、「データグラムTLSの設計と実装」、ISOC NDSS2004、2004年2月の議事。
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[超能力] ケントとS.とR.アトキンソン、「セキュリティ有効搭載量(超能力)を要約するIP」、RFC2406、1998年11月。
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[IKE]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
December 2005.
コーフマン、C.、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、2005年12月。
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[IMAP] クリスピン、M.、「バージョン4rev1"、RFC3501、2003年インターネットメッセージアクセス・プロトコル--3月。」
[PHOTURIS] Karn, P. and W. Simpson, "ICMP Security Failures
Messages", RFC 2521, March 1999.
[PHOTURIS]KarnとP.とW.シンプソン、「ICMPセキュリティ失敗メッセージ」、1999年3月のRFC2521。
[POP] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, May 1996.
[飛び出します] マイアーズ、J.、およびM.ローズ、「郵便局は議定書を作ります--バージョン3インチ、STD53、RFC1939、1996年5月。」
[REQ] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[REQ] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[SCTP] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000.
[SCTP] スチュワート、R.、シェ、Q.、K.の、そして、鋭いMorneault、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カッラ、M.、チャン、L.、および「流れの制御伝動プロトコル」、RFC2960(2000年10月)対パクソン
Rescorla & Modadugu Standards Track [Page 23] RFC 4347 Datagram Transport Layer Security April 2006
レスコラとModadugu規格はデータグラムトランスポート層セキュリティ2006年4月にRFC4347を追跡します[23ページ]。
[SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[一口] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[TLS] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[WHYIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec",
Work in Progress, October 2003.
S.、「IPsecの使用を強制するためのガイドライン」という[WHYIPSEC]Bellovinは進歩、2003年10月に働いています。
Authors' Addresses
作者のアドレス
Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303
エリックレスコラRTFM Inc.2064Edgewood Driveパロアルト、カリフォルニア 94303
EMail: ekr@rtfm.com
メール: ekr@rtfm.com
Nagendra Modadugu Computer Science Department Stanford University 353 Serra Mall Stanford, CA 94305
Nagendra Modaduguコンピュータサイエンス部のスタンフォード大学353のセラ・Mallスタンフォード、カリフォルニア 94305
EMail: nagendra@cs.stanford.edu
メール: nagendra@cs.stanford.edu
Rescorla & Modadugu Standards Track [Page 24] RFC 4347 Datagram Transport Layer Security April 2006
レスコラとModadugu規格はデータグラムトランスポート層セキュリティ2006年4月にRFC4347を追跡します[24ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
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 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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 provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Rescorla & Modadugu Standards Track [Page 25]
レスコラとModadugu標準化過程[25ページ]
一覧
スポンサーリンク
