没有合适的资源?快使用搜索试试~ 我知道了~
温馨提示
试读
42页
Datagram Transport Layer Security Version 1.2 数据报传输层安全版本1.2(DTLS1.2)中英对照版 本文件规定了数据报传输层安全(DTLS)协议的1.2版。DTLS协议为数据报协议提供通信隐私。该协议允许客户机/服务器应用程序以防止窃听、篡改或消息伪造的方式进行通信。DTLS协议基于传输层安全(TLS)协议,并提供等效的安全保证。DTLS协议保留了底层传输的数据报语义。本文档更新了DTLS 1.0以与TLS 1.2版配合使用。 TLS[TLS]是用于保护网络流量的最广泛部署的协议。它广泛用于保护Web流量和电子邮件协议,如IMAP[IMAP]和POP[POP]。TLS的主要优点是它提供了一个透明的面向连接的通道。因此,通过在应用层和传输层之间插入TLS,很容易保护应用协议。但是,TLS必须运行在可靠的传输通道上——通常是TCP[TCP]。因此,它不能用于保护不可靠的数据报流量。
资源推荐
资源详情
资源评论
2023/6/2
RFC6347 中文翻译 中文RFC RFC文档 RFC翻译 RFC中文版
rfc2cn.com/rfc6347.html
1/42
RFC 6347: Datagram Transport Layer Security Version
1.2 中文翻译
标题 : RFC 6347
Internet Engineering Task Force (IETF) E. Rescorla
Request for Comments: 6347 RTFM, Inc.
Obsoletes: 4347 N. Modadugu
Category: Standards Track Google, Inc.
ISSN: 2070-1721 January 2012
Internet Engineering Task Force (IETF) E. Rescorla
Request for Comments: 6347 RTFM, Inc.
Obsoletes: 4347 N. Modadugu
Category: Standards Track Google, Inc.
ISSN: 2070-1721 January 2012
Datagram Transport Layer Security Version 1.2
数据报传输层安全版本1.2
Abstract
摘要
This document specifies version 1.2 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. This
document updates DTLS 1.0 to work with TLS version 1.2.
本文件规定了数据报传输层安全(DTLS)协议的1.2版。DTLS协议为数据报协议提供通信隐私。该
协议允许客户机/服务器应用程序以防止窃听、篡改或消息伪造的方式进行通信。DTLS协议基于传
输层安全(TLS)协议,并提供等效的安全保证。DTLS协议保留了底层传输的数据报语义。本文档
更新了DTLS 1.0以与TLS 1.2版配合使用。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the
consensus of the IETF community. It has received public review and has been approved for
2023/6/2
RFC6347 中文翻译 中文RFC RFC文档 RFC翻译 RFC中文版
rfc2cn.com/rfc6347.html
2/42
publication by the Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组(IETF)的产品。它代表了IETF社区的共识。它已经接受了公众审查,
并已被互联网工程指导小组(IESG)批准出版。有关互联网标准的更多信息,请参见RFC 5741第2
节。
Information about the current status of this document, any errata, and how to provide
feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6347.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息,请访问http://www.rfc-
editor.org/info/rfc6347.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All
rights reserved.
版权所有(c)2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF
Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this
document. Please review these documents carefully, as they describe your rights and
restrictions with respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in Section 4.e of the Trust
Legal Provisions and are provided without warranty as described in the Simplified BSD
License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)
自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本
文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本,并提供简化
BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published
or made publicly available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. Without obtaining an
adequate license from the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and derivative works
of it may not be created outside the IETF Standards Process, except to format it for
publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料
版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材
料版权的人员处获得充分许可的情况下,不得在IETF标准流程之外修改本文件,也不得在IETF标准
流程之外创建其衍生作品,除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
2023/6/2
RFC6347 中文翻译 中文RFC RFC文档 RFC翻译 RFC中文版
rfc2cn.com/rfc6347.html
3/42
1. Introduction ....................................................4
1.1. Requirements Terminology ...................................5
2. Usage Model .....................................................5
3. Overview of DTLS ................................................5
3.1. Loss-Insensitive Messaging .................................6
3.2. Providing Reliability for Handshake ........................6
3.2.1. Packet Loss .........................................6
3.2.2. Reordering ..........................................7
3.2.3. Message Size ........................................7
3.3. Replay Detection ...........................................7
4. Differences from TLS ............................................7
4.1. Record Layer ...............................................8
4.1.1. Transport Layer Mapping ............................10
4.1.1.1. PMTU Issues ...............................10
4.1.2. Record Payload Protection ..........................12
4.1.2.1. MAC .......................................12
4.1.2.2. Null or Standard Stream Cipher ............13
4.1.2.3. Block Cipher ..............................13
4.1.2.4. AEAD Ciphers ..............................13
4.1.2.5. New Cipher Suites .........................13
4.1.2.6. Anti-Replay ...............................13
4.1.2.7. Handling Invalid Records ..................14
4.2. The DTLS Handshake Protocol ...............................14
4.2.1. Denial-of-Service Countermeasures ..................15
4.2.2. Handshake Message Format ...........................18
4.2.3. Handshake Message Fragmentation and Reassembly .....19
4.2.4. Timeout and Retransmission .........................20
4.2.4.1. Timer Values ..............................24
4.2.5. ChangeCipherSpec ...................................25
4.2.6. CertificateVerify and Finished Messages ............25
4.2.7. Alert Messages .....................................25
4.2.8. Establishing New Associations with Existing
Parameters .........................................25
4.3. Summary of New Syntax .....................................26
4.3.1. Record Layer .......................................26
4.3.2. Handshake Protocol .................................27
5. Security Considerations ........................................27
6. Acknowledgments ................................................28
7. IANA Considerations ............................................28
8. Changes since DTLS 1.0 .........................................29
9. References .....................................................30
9.1. Normative References ......................................30
9.2. Informative References ....................................31
1. Introduction ....................................................4
1.1. Requirements Terminology ...................................5
2. Usage Model .....................................................5
3. Overview of DTLS ................................................5
3.1. Loss-Insensitive Messaging .................................6
3.2. Providing Reliability for Handshake ........................6
3.2.1. Packet Loss .........................................6
3.2.2. Reordering ..........................................7
3.2.3. Message Size ........................................7
3.3. Replay Detection ...........................................7
4. Differences from TLS ............................................7
4.1. Record Layer ...............................................8
4.1.1. Transport Layer Mapping ............................10
4.1.1.1. PMTU Issues ...............................10
4.1.2. Record Payload Protection ..........................12
4.1.2.1. MAC .......................................12
4.1.2.2. Null or Standard Stream Cipher ............13
4.1.2.3. Block Cipher ..............................13
4.1.2.4. AEAD Ciphers ..............................13
4.1.2.5. New Cipher Suites .........................13
4.1.2.6. Anti-Replay ...............................13
4.1.2.7. Handling Invalid Records ..................14
4.2. The DTLS Handshake Protocol ...............................14
4.2.1. Denial-of-Service Countermeasures ..................15
4.2.2. Handshake Message Format ...........................18
4.2.3. Handshake Message Fragmentation and Reassembly .....19
4.2.4. Timeout and Retransmission .........................20
4.2.4.1. Timer Values ..............................24
4.2.5. ChangeCipherSpec ...................................25
4.2.6. CertificateVerify and Finished Messages ............25
2023/6/2
RFC6347 中文翻译 中文RFC RFC文档 RFC翻译 RFC中文版
rfc2cn.com/rfc6347.html
4/42
4.2.7. Alert Messages .....................................25
4.2.8. Establishing New Associations with Existing
Parameters .........................................25
4.3. Summary of New Syntax .....................................26
4.3.1. Record Layer .......................................26
4.3.2. Handshake Protocol .................................27
5. Security Considerations ........................................27
6. Acknowledgments ................................................28
7. IANA Considerations ............................................28
8. Changes since DTLS 1.0 .........................................29
9. References .....................................................30
9.1. Normative References ......................................30
9.2. Informative References ....................................31
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]. Therefore, it cannot be used to secure unreliable datagram
traffic.
TLS[TLS]是用于保护网络流量的最广泛部署的协议。它广泛用于保护Web流量和电子邮件协议,如
IMAP[IMAP]和POP[POP]。TLS的主要优点是它提供了一个透明的面向连接的通道。因此,通过在
应用层和传输层之间插入TLS,很容易保护应用协议。但是,TLS必须运行在可靠的传输通道上——
通常是TCP[TCP]。因此,它不能用于保护不可靠的数据报流量。
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 [RFC4301]. 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. 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
require a large amount of effort to design -- in contrast to the relatively small amount of
effort required to run the protocol over TLS.
越来越多的应用层协议被设计为使用UDP传输。特别地,诸如会话发起协议(SIP)[SIP]和电子游
戏协议之类的协议越来越流行。(请注意,SIP可以在TCP和UDP上运行,但在某些情况下UDP更
可取。)目前,这些应用程序的设计者面临着许多不令人满意的选择。首先,他们可以使用
IPsec[RFC4301]。然而,由于[WHYIPSEC]中详述的许多原因,这仅适用于某些应用。其次,他们
可以设计定制的应用层安全协议。不幸的是,尽管应用层安全协议通常提供优越的安全属性(例
如,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.
This memo describes a protocol for this purpose: Datagram Transport Layer Security
2023/6/2
RFC6347 中文翻译 中文RFC RFC文档 RFC翻译 RFC中文版
rfc2cn.com/rfc6347.html
5/42
(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。本备忘录描述了用于此目的的协议:数据报传输层安全(DTLS)。DTL被刻意
设计为尽可能类似于TLS,既可以最小化新的安全发明,又可以最大限度地提高代码和基础设施的
重用量。
DTLS 1.0 [DTLS1] was originally defined as a delta from [TLS11]. This document introduces
a new version of DTLS, DTLS 1.2, which is defined as a series of deltas to TLS 1.2 [TLS12].
There is no DTLS 1.1; that version number was skipped in order to harmonize version
numbers with TLS. This version also clarifies some confusing points in the DTLS 1.0
specification.
DTLS 1.0[DTLS1]最初定义为[TLS11]中的增量。本文档介绍了DTLS的新版本DTLS 1.2,定义为TLS
1.2[TLS12]的一系列增量。没有DTLS 1.1;为了使版本号与TLS一致,跳过了该版本号。此版本还
澄清了DTLS 1.0规范中的一些混淆点。
Implementations that speak both DTLS 1.2 and DTLS 1.0 can interoperate with those that
speak only DTLS 1.0 (using DTLS 1.0 of course), just as TLS 1.2 implementations can
interoperate with previous versions of TLS (see Appendix E.1 of [TLS12] for details), with
the exception that there is no DTLS version of SSLv2 or SSLv3, so backward compatibility
issues for those protocols do not apply.
同时使用DTLS 1.2和DTLS 1.0的实现可以与只使用DTLS 1.0的实现进行互操作(当然使用DTLS
1.0),正如TLS 1.2实现可以与TLS的早期版本进行互操作(有关详细信息,请参见[TLS12]的附录
E.1),但没有SSLv2或SSLv3的DTLS版本,因此,这些协议的向后兼容性问题不适用。
1.1. Requirements 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 [REQ].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建
议”、“可”和“可选”应按照RFC 2119[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
剩余41页未读,继续阅读
资源评论
俊英小哥
- 粉丝: 0
- 资源: 2
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功