Network Working Group S. Farrell
Request for Comments: 5327 Trinity College Dublin
Category: Experimental M. Ramadas
ISTRAC, ISRO
S. Burleigh
NASA/Jet Propulsion Laboratory
September 2008
Network Working Group S. Farrell
Request for Comments: 5327 Trinity College Dublin
Category: Experimental M. Ramadas
ISTRAC, ISRO
S. Burleigh
NASA/Jet Propulsion Laboratory
September 2008
Licklider Transmission Protocol - Security Extensions
利克利德传输协议-安全扩展
Status of This Memo
关于下段备忘
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
IESG Note
IESG注释
This RFC is not a candidate for any level of Internet Standard. It represents the consensus of the Delay Tolerant Networking (DTN) Research Group of the Internet Research Task Force (IRTF). It may be considered for standardization by the IETF in the future, but the IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. See RFC 3932 for more information.
本RFC不适用于任何级别的互联网标准。它代表了互联网研究任务组（IRTF）的延迟容忍网络（DTN）研究小组的共识。IETF将来可能会考虑将其标准化，但IETF不承认该RFC适用于任何目的，并特别指出，发布决定并非基于IETF对安全、拥塞控制或与已部署协议的不当交互等事项的审查。有关更多信息，请参阅RFC 3932。
Abstract
摘要
The Licklider Transmission Protocol (LTP) is intended to serve as a reliable convergence layer over single-hop deep-space radio frequency (RF) links. LTP does Automatic Repeat reQuest (ARQ) of data transmissions by soliciting selective-acknowledgment reception reports. It is stateful and has no negotiation or handshakes. This document describes security extensions to LTP, and is part of a series of related documents describing LTP.
利克利德传输协议（LTP）旨在作为单跳深空射频（RF）链路上的可靠汇聚层。LTP通过请求选择性确认接收报告来执行数据传输的自动重复请求（ARQ）。它是有状态的，没有协商或握手。本文档描述了LTP的安全扩展，是描述LTP的一系列相关文档的一部分。
This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised.
本文件是耐延迟网络研究小组的产品，该小组已对其进行了审查。没有人反对将其作为RFC出版。
Table of Contents
目录
1. Introduction ....................................................2
2. Security Extensions .............................................2
2.1. LTP Authentication .........................................3
2.2. A Cookie Mechanism .........................................6
3. Security Considerations .........................................7
4. IANA Considerations .............................................7
5. Acknowledgments .................................................8
6. References ......................................................8
6.1. Normative References .......................................8
6.2. Informative References .....................................9
1. Introduction ....................................................2
2. Security Extensions .............................................2
2.1. LTP Authentication .........................................3
2.2. A Cookie Mechanism .........................................6
3. Security Considerations .........................................7
4. IANA Considerations .............................................7
5. Acknowledgments .................................................8
6. References ......................................................8
6.1. Normative References .......................................8
6.2. Informative References .....................................9
This document describes extensions to the base LTP protocol [LTPSPEC]. The background to LTP is described in the "motivation" document [LTPMOTIVE]. All the extensions defined in this document provide additional security features for LTP.
本文档描述了基本LTP协议[LTPSPEC]的扩展。LTP的背景在“动机”文档[LTPMOTIVE]中描述。本文档中定义的所有扩展都为LTP提供了额外的安全特性。
LTP is designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity. Since communication across interplanetary space is the most prominent example of this sort of environment, LTP is principally aimed at supporting "long-haul" reliable transmission in interplanetary space, but has applications in other environments as well.
LTP旨在通过具有超长消息往返时间（RTT）和/或频繁连接中断特征的链路提供基于重传的可靠性。由于跨行星际空间的通信是此类环境中最突出的例子，因此LTP主要旨在支持行星际空间中的“长距离”可靠传输，但也可应用于其他环境。
This document describes security extensions to LTP, and is part of a series of related documents describing LTP. Other documents in this series cover the motivation for LTP and the main protocol specification. We recommend reading all the documents in the series before writing code based on this document.
本文档描述了LTP的安全扩展，是描述LTP的一系列相关文档的一部分。本系列的其他文档包括LTP的动机和主要协议规范。我们建议在基于本文档编写代码之前阅读本系列中的所有文档。
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 [B97].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[B97]中所述进行解释。
The syntactical layout of the extensions are defined in Section 3.1.4 of the base protocol specification [LTPSPEC].
基本协议规范[LTPSPEC]第3.1.4节定义了扩展的语法布局。
Implementers should note that the LTP extension mechanism allows for multiple occurrences of any extension tag, in both (or either) the header or trailer. For example, the LTP authentication mechanism defined below requires both header and trailer extensions, which both use the same tag.
实现者应该注意，LTP扩展机制允许任何扩展标记在头部或尾部（或其中一个）中多次出现。例如，下面定义的LTP身份验证机制需要标头和尾部扩展，它们都使用相同的标记。
This document defines new security extensions for LTP but does not address key management since key management in Delay-Tolerant Networking (DTN) remains an open research question.
本文档为LTP定义了新的安全扩展，但没有涉及密钥管理，因为延迟容忍网络（DTN）中的密钥管理仍然是一个开放的研究问题。
If LTP were deployed layered on top of UDP, it might be possible to use IPsec or other existing security mechanisms. However, in general DTN, IPsec's key exchange (IKE) cannot work (e.g., where link delays are measured in minutes).
如果LTP是在UDP之上分层部署的，那么就有可能使用IPsec或其他现有的安全机制。然而，在一般的DTN中，IPsec的密钥交换（IKE）无法工作（例如，链路延迟以分钟为单位测量）。
The LTP authentication mechanism provides cryptographic authentication of the segment.
LTP身份验证机制提供段的加密身份验证。
Implementations MAY support this extension field. If they do not support this header, then they MUST ignore it.
实现可能支持此扩展字段。如果他们不支持此标题，则必须忽略它。
The LTP authentication extension field has the extension tag value 0x00.
LTP身份验证扩展字段的扩展标记值为0x00。
LTP authentication requires three new fields, the first two of which are carried as the value of the Extensions field of the LTP segment header, and the third of which is carried in the segment trailer.
LTP身份验证需要三个新字段，前两个字段作为LTP段头的Extensions字段值携带，第三个字段在段尾中携带。
The fields that are carried in the header extensions field are catenated together to form the extension value (with the leftmost octet representing the ciphersuite and the remaining octets the KeyID). The KeyID field is optional, and is determined to be absent if the extension value consists of a single octet.
header extensions字段中携带的字段被链接在一起以形成扩展值（最左边的八位字节表示密码套件，其余的八位字节表示KeyID）。KeyID字段是可选的，如果扩展值由单个八位字节组成，则确定不存在该字段。
Ciphersuite: an 8-bit integer value with values defined below.
Ciphersuite：一个8位整数值，其值定义如下。
KeyID: An optional key identifier, the interpretation of which is out of scope for this specification (that is, implementers MUST treat these KeyID fields as raw octets, even if they contained an ASN.1 DER encoding of an X.509 IssuerSerial construct [PKIXPROF], for example).
KeyID：可选的密钥标识符，其解释超出了本规范的范围（即，实现者必须将这些KeyID字段视为原始八位字节，即使它们包含X.509发行者串行构造[PKIXPROF]的ASN.1 DER编码）。
The LTP-auth header extension MUST be present in the first segment from any LTP session that uses LTP authentication, but MAY be omitted from subsequent segments in that session. To guard against additional problems arising from lost segments, implementations SHOULD, where bandwidth allows, include these fields in a number of segments in the LTP session. If the first segment (or any part thereof) is retransmitted, then the LTP-auth header extension MUST be included in the retransmission.
LTP auth头扩展必须出现在使用LTP身份验证的任何LTP会话的第一个段中，但可以从该会话的后续段中省略。为了防止由于丢失段而引起的额外问题，在带宽允许的情况下，实现应该在LTP会话的多个段中包括这些字段。如果第一段（或其任何部分）被重新传输，那么LTP auth头扩展必须包括在重新传输中。
The field carried as a trailer extension is the AuthVal field. It contains the authentication value, which is either a message authentication code (MAC) or a digital signature. This is itself a structured field whose length and formatting depend on the ciphersuite.
作为拖车扩展名携带的字段是AuthVal字段。它包含身份验证值，即消息身份验证码（MAC）或数字签名。这本身就是一个结构化字段，其长度和格式取决于密码套件。
If for some reason the sender includes two instances of LTP-auth headers, then there is a potential problem for the receiver in that presumably at least one of the AuthVal fields will not verify. There are very few situations where it would make sense to include more than one LTP-auth extension in a single segment, since LTP is a peer-to-peer protocol. If however, keys are being upgraded, then the sender might protect the segment with both the new and old keys. In such cases, the receiver MUST search and can consider the LTP authentication valid so long as one AuthVal is correct.
如果出于某种原因，发送方包含两个LTP auth头实例，则接收方可能存在一个潜在问题，即至少有一个AuthVal字段无法验证。由于LTP是一种对等协议，因此在很少的情况下，在单个段中包含多个LTP auth扩展是有意义的。但是，如果密钥正在升级，则发送方可能会使用新密钥和旧密钥保护该段。在这种情况下，接收方必须搜索，并且可以考虑LTP认证有效，只要一个AuthVar是正确的。
For all ciphersuites, the input to the calculation is the entire encoded segment including the AuthVal extension tag and length, but not of course, including the AuthVal value.
对于所有密码套件，计算的输入是整个编码段，包括AuthVal扩展标记和长度，但当然不包括AuthVal值。
We define three ciphersuites in this specification. Our approach is to follow the precedent set by TLS [TLS], and to "hardcode" all algorithm options in a single ciphersuite number. This means that there are 256 potential ciphersuites supported by this version of LTP-auth. Since this is a limited space, IANA has established a registry for LTP Ciphersuites as described in the IANA Considerations section below. Current ciphersuite assignments are:
我们在本规范中定义了三种密码套件。我们的方法是遵循TLS[TLS]的先例，将所有算法选项“硬编码”在一个密码套件编号中。这意味着此版本的LTP auth支持256个潜在密码套件。由于篇幅有限，IANA为LTP密码套件建立了一个注册表，如下面IANA注意事项部分所述。当前的ciphersuite分配为：
Ciphersuite Value
----------- -----
HMAC-SHA1-80 0
RSA-SHA256 1
Unassigned 2-127
Reserved 128-191
Private/Experimental Use 192-254
NULL 255
Ciphersuite Value
----------- -----
HMAC-SHA1-80 0
RSA-SHA256 1
Unassigned 2-127
Reserved 128-191
Private/Experimental Use 192-254
NULL 255
1. HMAC-SHA1-80 Ciphersuite
1. HMAC-SHA1-80密码套件
The HMAC-SHA1-80 ciphersuite involves generating a MAC over the LTP segment and appending the resulting AuthVal field to the end of the segment. There is only one MACing algorithm defined for this, which is HMAC-SHA1-80 [HMAC]. The AuthVal field in this case contains just the output of the HMAC-SHA1-80 algorithm, which is a fixed-width field (10 octets).
HMAC-SHA1-80密码套件涉及在LTP段上生成MAC，并将生成的AuthVal字段附加到段的末尾。为此，仅定义了一种MACing算法，即HMAC-SHA1-80[HMAC]。本例中的AuthVal字段仅包含HMAC-SHA1-80算法的输出，这是一个固定宽度字段（10个八位字节）。
2. RSA-SHA256 Ciphersuite
2. RSA-SHA256密码套件
The RSA-SHA256 ciphersuite involves generating a digital signature of the LTP segment and appending the resulting AuthVal field to the end of the segment. There is only one signature algorithm currently defined for this, which is RSA with SHA256 as defined in [RSA], Section 8.2. The AuthVal field in this case is simply the signature value, where the signature value occupies the minimum number of octets, e.g., 128 octets for a 1024-bit signature).
RSA-SHA256密码套件涉及生成LTP段的数字签名，并将生成的AuthVal字段附加到段的末尾。目前仅定义了一种签名算法，即[RSA]第8.2节中定义的带SHA256的RSA。在这种情况下，AuthVal字段只是签名值，其中签名值占用最小的八位字节数（例如，1024位签名为128个八位字节）。
3. NULL Ciphersuite
3. 空密码套件
The NULL ciphersuite is basically the same as the HMAC-SHA1-80 ciphersuite, but with a hardcoded key. This ciphersuite effectively provides only a strong checksum without authentication, and thus is subject to active attacks and is the equivalent of providing a Cyclic Redundancy Check (CRC).
空密码套件与HMAC-SHA1-80密码套件基本相同，但具有硬编码密钥。该密码套件有效地只提供强校验和而不进行身份验证，因此会受到主动攻击，相当于提供循环冗余校验（CRC）。
The hardcoded key to be used with this ciphersuite is the following:
与此密码套件一起使用的硬编码密钥如下：
HMAC_KEY : c37b7e64 92584340 : bed12207 80894115 : 5068f738 (The above is the test vector from RFC 3537 [WRAP].)
HMAC_键：c37b7e64 92584340:bed12207 80894115:5068f738（以上是来自RFC 3537[WRAP]的测试向量。）
In each case, the bytes that are input to the cryptographic algorithm consist of the entire LTP segment except the AuthVal. In particular, the header extensions field that may contain the ciphersuite number and the KeyID field is part of the input.
在每种情况下，输入到加密算法的字节都由除AuthVal之外的整个LTP段组成。特别是，可能包含密码套件编号和密钥ID字段的标头扩展字段是输入的一部分。
The output bytes of the cryptographic operation are the payload of the AuthVal field.
加密操作的输出字节是AuthVal字段的有效负载。
The following shows an example LTP-auth header, starting from and including the Extensions field.
下面显示了一个示例LTP auth头，从Extensions字段开始，包括Extensions字段。
ext tag sdnv c-s k-id
+----+----+----+----+----+
|0x11|0x00|0x02|0x00|0x24|
+----+----+----+----+----+
ext tag sdnv c-s k-id
+----+----+----+----+----+
|0x11|0x00|0x02|0x00|0x24|
+----+----+----+----+----+
The Extensions field has the value 0x11 with the most significant and least significant nibble value 1, indicating the presence of one header and one trailer extension, respectively. The next octet is the extension tag (0x00 for LTP-auth), followed by the Self-Delimiting Numeric Value (SDNV) encoded length of the ensuing data: a one-octet ciphersuite (0x00 meaning HMAC-SHA1-80) and the KeyID (in this case with a short value of 0x24). The trailer extension (not shown above) should contain the AuthVal.
Extensions字段的值0x11具有最高有效位值1和最低有效位值1，分别表示存在一个标头和一个尾部扩展。下一个八位字节是扩展标记（对于LTP auth为0x00），后面是后续数据的自定界数值（SDNV）编码长度：一个八位字节的密码套件（0x00表示HMAC-SHA1-80）和密钥ID（在本例中，短值为0x24）。拖车扩展（上面未显示）应包含AuthVal。
The use of cookies is a well-known way to make Denial of Service (DoS) attacks harder to mount. We define the cookie extension for use in environments where an LTP implementation is liable to such attacks.
Cookie的使用是一种众所周知的方法，它使拒绝服务（DoS）攻击更难发动。我们定义了cookie扩展，以便在LTP实现容易受到此类攻击的环境中使用。
The cookie is placed in a header extension field, and has no related trailer extension field. It has the extension tag value 0x01.
cookie位于标题扩展字段中，没有相关的尾部扩展字段。它具有扩展标记值0x01。
The cookie value can essentially be viewed as a sufficiently long random number, where the length can be determined by the implementation (longer cookies are harder to guess and therefore better, though using more bandwidth). Note that cookie values can be derived using lots of different schemes so long as they produce random-looking and hard-to-predict values.
cookie值基本上可以被视为一个足够长的随机数，长度可以由实现来确定（较长的cookie更难猜测，因此更好，尽管使用更多的带宽）。请注意，cookie值可以使用许多不同的方案导出，只要它们产生随机的、难以预测的值。
The first cookie inserted into a segment for this session is called the initial cookie.
插入到该会话段中的第一个cookie称为初始cookie。
Note that cookies do not outlast an LTP session.
请注意，Cookie不会持续LTP会话。
The basic mode of operation is that an LTP engine can include a cookie in a segment at any time. After that time, all segments corresponding to that LTP session MUST contain a good cookie value -- that is, all segments both to and from the engine MUST contain a good cookie. Clearly, there will be some delay before the cookie is seen in incoming segments -- implementations MUST determine an acceptable delay for these cases, and MUST only accept segments without a cookie until that time.
基本操作模式是LTP引擎可以随时在段中包含cookie。在此之后，与该LTP会话对应的所有段都必须包含一个好的cookie值——也就是说，与引擎之间的所有段都必须包含一个好的cookie。显然，在传入段中看到cookie之前会有一些延迟——实现必须为这些情况确定一个可接受的延迟，并且在此之前必须只接受没有cookie的段。
The cookie value can be extended at any time by catenating more random bits. This allows both LTP engines to contribute to the randomness of the cookie, where that is useful. It also allows a node that considers the cookie value too short (say due to changing circumstances) to add additional security. In this case, the extended cookie value becomes the "to-be-checked-against" cookie value for all future segments (modulo the communications delay as above).
cookie值可以在任何时候通过链接更多的随机位来扩展。这允许两个LTP引擎对cookie的随机性做出贡献，这是有用的。它还允许认为cookie值太短（例如由于环境变化）的节点添加额外的安全性。在这种情况下，扩展cookie值成为所有未来段的“待检查”cookie值（如上所述对通信延迟进行模化）。
It can happen that both sides emit segments containing an initial cookie before their peer has a chance to see any cookie. In that case, two cookie extension fields MUST be included in all segments subsequently (once the traffic has caught up). That is, the sender and recipient cookies are handled independently. In such cases, both cookie values MUST be "good" at all relevant times (i.e., modulo the delay). In this case, the peer's initial cookie MUST arrive before the calculated delay for receipt of segments containing this engine's cookie -- there is only a finite window during which a second cookie can be inserted into the session.
双方都可能在对方有机会看到任何cookie之前发出包含初始cookie的段。在这种情况下，随后必须在所有段中包括两个cookie扩展字段（一旦流量被占用）。也就是说，发送方和接收方cookie是独立处理的。在这种情况下，两个cookie值在所有相关时间都必须是“良好的”（即，对延迟进行模化）。在这种情况下，对等方的初始cookie必须在接收包含此引擎cookie的段的计算延迟之前到达——只有一个有限的窗口，在此期间可以将第二个cookie插入会话。
A "good" cookie is therefore one that starts with the currently stored cookie value, or else a new cookie where none has been seen in that session so far. Once a cookie value is seen and treated as "good" (e.g., an extended value), the previous value is no longer "good".
因此，“好的”cookie是以当前存储的cookie值开始的cookie，或者是一个新的cookie，到目前为止在该会话中没有看到任何cookie。一旦cookie值被视为“好”（例如，扩展值），以前的值就不再是“好”。
Modulo the communications delay, segments with an incorrect or missing cookie value MUST be silently discarded.
以通信延迟为模，具有不正确或缺少cookie值的段必须被静默地丢弃。
If a segment is to be retransmitted (e.g., as a result of a timer expiring), then it needs to contain the correct cookie value at the time of (re)transmission. Note that this may differ from what was the correct cookie value at the time of the original transmission.
如果要重新传输段（例如，由于计时器过期），则需要在（重新）传输时包含正确的cookie值。请注意，这可能与原始传输时的正确cookie值不同。
The extensions specified above are generally intended to help thwart DoS attacks. For environments where lower layers provide neither integrity nor freshness, it makes sense to use both extensions together. For example, in the case where a node extends an existing cookie, the lack of origin authentication would allow a man in the middle to lock out the session.
上面指定的扩展通常用于帮助阻止DoS攻击。对于较低层既不提供完整性也不提供新鲜性的环境，将这两个扩展一起使用是有意义的。例如，在节点扩展现有Cookie的情况下，缺少原点认证将允许中间的人锁定会话。
While there are currently some concerns about using the SHA-1 algorithm, these appear to only make it easier to find collisions. In that case, the use of HMAC with SHA-1 can still be considered safe. However, we have changed to use SHA-256 for the signature ciphersuite.
虽然目前对使用SHA-1算法存在一些担忧，但这些似乎只会使查找碰撞变得更容易。在这种情况下，与SHA-1一起使用HMAC仍然是安全的。但是，我们已更改为使用SHA-256作为签名密码套件。
IANA has created and now maintains registry for known LTP ciphersuites (as defined in Section 2.1). The registry has been populated using the initial values given in Sections 2.1 and 2.2 above. IANA may assign LTP Extension Tag values from the range 2..127 (decimal, inclusive) using the Specification Required rule [GUIDE]. The specification concerned can be an RFC (whether
IANA已经创建并维护了已知LTP密码套件（如第2.1节所定义）的注册表。已使用上文第2.1节和第2.2节中给出的初始值填充注册表。IANA可以使用规范要求的规则[指南]分配范围为2..127（十进制，含小数）的LTP扩展标记值。相关规范可以是RFC（无论
Standards Track, Experimental, or Informational), or a specification from any other standards development organization recognized by IANA or with a liaison with the IESG, specifically including CCSDS (http://www.ccsds.org/).
标准跟踪、试验或信息），或IANA认可的任何其他标准开发组织或与IESG联络的任何其他标准开发组织的规范，具体包括CCSDS(http://www.ccsds.org/).
Many thanks to Tim Ray, Vint Cerf, Bob Durst, Kevin Fall, Adrian Hooke, Keith Scott, Leigh Torgerson, Eric Travis, and Howie Weiss for their thoughts on this protocol and its role in Delay-Tolerant Networking architecture.
非常感谢Tim Ray、Vint Cerf、Bob Durst、Kevin Fall、Adrian Hooke、Keith Scott、Leigh Torgerson、Eric Travis和Howie Weiss对该协议及其在延迟容忍网络架构中的作用的思考。
Part of the research described in this document was carried out at the Jet Propulsion Laboratory, California Institute of Technology, under a contract with the National Aeronautics and Space Administration. This work was performed under DOD Contract DAA-B07- 00-CC201, DARPA AO H912; JPL Task Plan No. 80-5045, DARPA AO H870; and NASA Contract NAS7-1407.
本文件中描述的部分研究是在加利福尼亚理工学院喷气推进实验室根据与美国国家航空航天局签订的合同进行的。这项工作是根据国防部合同DAA-B07-00-CC201，DARPA AO H912执行的；JPL任务计划编号80-5045，DARPA AO H870；美国宇航局合同NAS7-1407。
Thanks are also due to Shawn Ostermann, Hans Kruse, and Dovel Myers at Ohio University for their suggestions and advice in making various design decisions. This work was done when Manikantan Ramadas was a graduate student at the EECS Dept., Ohio University, in the Internetworking Research Group Laboratory.
感谢俄亥俄大学的Shawn Ostermann、Hans Kruse和Dovel Myers在做出各种设计决策时提出的建议和建议。这项工作是在马尼坎坦·拉马达斯（Manikantan Ramadas）是俄亥俄大学电子工程系（EECS）的研究生时在互联网研究小组实验室完成的。
Part of this work was carried out at Trinity College Dublin as part of the Dev-SeNDT contract funded by Enterprise Ireland's technology development programme.
这项工作的一部分在都柏林三一学院进行，作为爱尔兰企业技术开发计划资助的Dev SeNDT合同的一部分。
[B97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[B97]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[GUIDE] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[指南]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HMAC]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息身份验证的键控哈希”，RFC 2104，1997年2月。
[LTPSPEC] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider Transmission Protocol - Specification", RFC 5326, September 2008.
[LTPSPEC]Ramadas，M.，Burleigh，S.，和S.Farrell，“利克利德传输协议-规范”，RFC 5326，2008年9月。
[RSA] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RSA]Jonsson，J.和B.Kaliski，“公钥密码标准（PKCS）#1:RSA密码规范版本2.1”，RFC 3447，2003年2月。
[LTPMOTIVE] Burleigh, S., Ramadas, M., and S. Farrell, "Licklider Transmission Protocol - Motivation", RFC 5325, September 2008.
[LTPMOTIVE]Burleigh，S.，Ramadas，M.，和S.Farrell，“利克利德传输协议-动机”，RFC 53252008年9月。
[PKIXPROF] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[PKIXPROF]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[TLS]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[WRAP] Schaad, J. and R. Housley, "Wrapping a Hashed Message Authentication Code (HMAC) key with a Triple-Data Encryption Standard (DES) Key or an Advanced Encryption Standard (AES) Key", RFC 3537, May 2003.
[WRAP]Schaad，J.和R.Housley，“用三重数据加密标准（DES）密钥或高级加密标准（AES）密钥包装散列消息认证码（HMAC）密钥”，RFC 3537，2003年5月。
Authors' Addresses
作者地址
Stephen Farrell Computer Science Department Trinity College Dublin Ireland Telephone: +353-1-896-1761 EMail: stephen.farrell@cs.tcd.ie
斯蒂芬·法雷尔计算机科学系都柏林三一学院爱尔兰电话：+353-1-896-1761电子邮件：斯蒂芬。farrell@cs.tcd.ie
Manikantan Ramadas ISRO Telemetry Tracking and Command Network (ISTRAC) Indian Space Research Organization (ISRO) Plot # 12 & 13, 3rd Main, 2nd Phase Peenya Industrial Area Bangalore 560097 India Telephone: +91 80 2364 2602 EMail: mramadas@gmail.com
Manikantan Ramadas印度空间研究组织ISRO遥测跟踪和指挥网络（ISTRAC）印度空间研究组织（ISRO）班加罗尔喷丸工业区二期3号干线12号和13号地块560097印度电话：+91 80 2364 2602电子邮件：mramadas@gmail.com
Scott C. Burleigh Jet Propulsion Laboratory 4800 Oak Grove Drive M/S: 301-485B Pasadena, CA 91109-8099 Telephone: +1 (818) 393-3353 Fax: +1 (818) 354-1075 EMail: Scott.Burleigh@jpl.nasa.gov
斯科特·C·伯利喷气推进实验室4800橡树林大道M/S:301-485B加利福尼亚州帕萨迪纳91109-8099电话：+1（818）393-3353传真：+1（818）354-1075电子邮件：斯科特。Burleigh@jpl.nasa.gov
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at http://www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78和http://www.rfc-editor.org/copyright.html，除本协议另有规定外，提交人保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.