Network Working Group S. Santesson
Request for Comments: 4681 A. Medvinsky
Updates: 4346 J. Ball
Category: Standards Track Microsoft
October 2006
Network Working Group S. Santesson
Request for Comments: 4681 A. Medvinsky
Updates: 4346 J. Ball
Category: Standards Track Microsoft
October 2006
TLS User Mapping Extension
TLS用户映射扩展
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document specifies a TLS extension that enables clients to send generic user mapping hints in a supplemental data handshake message defined in RFC 4680. One such mapping hint is defined in an informative section, the UpnDomainHint, which may be used by a server to locate a user in a directory database. Other mapping hints may be defined in other documents in the future.
本文档指定了一个TLS扩展，该扩展使客户端能够在RFC 4680中定义的补充数据握手消息中发送通用用户映射提示。一个这样的映射提示在信息部分UpnDomainHint中定义，服务器可以使用它在目录数据库中定位用户。将来可能会在其他文档中定义其他映射提示。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Terminology ................................................2
1.2. Design Considerations ......................................2
2. User Mapping Extension ..........................................3
3. User Mapping Handshake Exchange .................................3
4. Message Flow ....................................................5
5. Security Considerations .........................................6
6. UPN Domain Hint (Informative) ...................................7
7. IANA Considerations .............................................8
8. Normative References ............................................9
9. Acknowledgements ................................................9
1. Introduction ....................................................2
1.1. Terminology ................................................2
1.2. Design Considerations ......................................2
2. User Mapping Extension ..........................................3
3. User Mapping Handshake Exchange .................................3
4. Message Flow ....................................................5
5. Security Considerations .........................................6
6. UPN Domain Hint (Informative) ...................................7
7. IANA Considerations .............................................8
8. Normative References ............................................9
9. Acknowledgements ................................................9
This document has a normative part and an informative part. Sections 2-5 are normative. Section 6 is informative.
本文件分为规范性部分和信息性部分。第2-5节是规范性的。第6节内容丰富。
This specification defines a TLS extension and a payload for the SupplementalData handshake message, defined in RFC 4680 [N6], to accommodate mapping of users to their user accounts when using TLS client authentication as the authentication method.
本规范定义了RFC 4680[N6]中定义的补充数据握手消息的TLS扩展和有效负载，以在使用TLS客户端身份验证作为身份验证方法时，适应用户到其用户帐户的映射。
The new TLS extension (user_mapping) is sent in the client hello message. Per convention defined in RFC 4366 [N4], the server places the same extension (user_mapping) in the server hello message, to inform the client that the server understands this extension. If the server does not understand the extension, it will respond with a server hello omitting this extension, and the client will proceed as normal, ignoring the extension, and not include the UserMappingDataList data in the TLS handshake.
新的TLS扩展（用户映射）在客户端hello消息中发送。根据RFC 4366[N4]中定义的约定，服务器在服务器hello消息中放置相同的扩展名（用户映射），以通知客户端服务器理解此扩展名。如果服务器不理解扩展，它将响应一个省略此扩展的服务器hello，客户端将正常进行，忽略扩展，并且在TLS握手中不包括UserMappingDataList数据。
If the new extension is understood, the client will inject UserMappingDataList data in the SupplementalData handshake message prior to the Client's Certificate message. The server will then parse this message, extracting the client's domain, and store it in the context for use when mapping the certificate to the user's directory account.
如果理解了新的扩展，那么客户端将在客户端的证书消息之前，将UserMappingDataList数据注入到SupplementalData握手消息中。然后，服务器将解析此消息，提取客户端的域，并将其存储在上下文中，以便在将证书映射到用户的目录帐户时使用。
No other modifications to the protocol are required. The messages are detailed in the following sections.
不需要对协议进行其他修改。以下各节将详细介绍这些消息。
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 [N1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[N1]中所述进行解释。
The syntax for the TLS User Mapping extension is defined using the TLS Presentation Language, which is specified in Section 4 of [N2].
TLS用户映射扩展的语法是使用TLS表示语言定义的，该语言在[N2]的第4节中指定。
The reason the mapping data itself is not placed in the extension portion of the client hello is to prevent broadcasting this information to servers that don't understand the extension.
映射数据本身不放在客户机hello的扩展部分的原因是为了防止将此信息广播到不理解扩展的服务器。
A new extension type (user_mapping(6)) is added to the Extension used in both the client hello and server hello messages. The extension type is specified as follows.
新的扩展类型（user_mapping（6））被添加到客户端hello和服务器hello消息中使用的扩展中。扩展类型指定如下。
enum {
user_mapping(6), (65535)
} ExtensionType;
enum {
user_mapping(6), (65535)
} ExtensionType;
The "extension_data" field of this extension SHALL contain "UserMappingTypeList" with a list of supported hint types where:
此扩展的“extension_data”字段应包含“UserMappingTypeList”，以及支持的提示类型列表，其中：
struct {
UserMappingType user_mapping_types<1..2^8-1>;
} UserMappingTypeList;
struct {
UserMappingType user_mapping_types<1..2^8-1>;
} UserMappingTypeList;
Enumeration of hint types (user_mapping_types) defined in this document is provided in Section 3.
第3节提供了本文档中定义的提示类型（用户映射类型）的枚举。
The list of user_mapping_types included in a client hello SHALL signal the hint types supported by the client. The list of user_mapping_types included in the server hello SHALL signal the hint types preferred by the server.
客户机hello中包含的用户映射类型列表应表示客户机支持的提示类型。服务器hello中包含的用户映射类型列表应表示服务器首选的提示类型。
If none of the hint types listed by the client is supported by the server, the server SHALL omit the user_mapping extension in the server hello.
如果服务器不支持客户端列出的任何提示类型，则服务器应省略服务器hello中的用户映射扩展。
When the user_mapping extension is included in the server hello, the list of hint types in "UserMappingTypeList" SHALL be either equal to, or a subset of, the list provided by the client.
当服务器hello中包含用户映射扩展时，“UserMappingTypeList”中的提示类型列表应等于或是客户端提供的列表的子集。
The underlying structure of the SupplementalData handshake message, used to carry information defined in this section, is defined in RFC 4680 [N6].
RFC 4680[N6]中定义了用于承载本节中定义的信息的补充数据握手消息的底层结构。
A new SupplementalDataType [N6] is defined to accommodate communication of generic user mapping data. See RFC 2246 (TLS 1.0) [N2] and RFC 4346 (TLS 1.1) [N3] for other handshake types.
定义了一个新的补充数据类型[N6]，以适应通用用户映射数据的通信。其他握手类型见RFC 2246（TLS 1.0）[N2]和RFC 4346（TLS 1.1）[N3]。
The information in this data type carries one or more unauthenticated hints, UserMappingDataList, inserted by the client side. Upon receipt and successful completion of the TLS handshake, the server
此数据类型中的信息包含客户端插入的一个或多个未经验证的提示UserMappingDataList。在收到并成功完成TLS握手后，服务器
MAY use this hint to locate the user's account from which user information and credentials MAY be retrieved to support authentication based on the client certificate.
可以使用此提示查找用户帐户，从中可以检索用户信息和凭据以支持基于客户端证书的身份验证。
struct {
SupplementalDataType supp_data_type;
uint16 supp_data_length;
select(SupplementalDataType) {
case user_mapping_data: UserMappingDataList;
}
} SupplementalDataEntry;
struct {
SupplementalDataType supp_data_type;
uint16 supp_data_length;
select(SupplementalDataType) {
case user_mapping_data: UserMappingDataList;
}
} SupplementalDataEntry;
enum {
user_mapping_data(0), (65535)
} SupplementalDataType;
enum {
user_mapping_data(0), (65535)
} SupplementalDataType;
The user_mapping_data(0) enumeration results in a new supplemental data type UserMappingDataList with the following structure:
user_mapping_data（0）枚举会产生一个新的补充数据类型UserMappingDataList，其结构如下：
enum {
(255)
} UserMappingType;
enum {
(255)
} UserMappingType;
struct {
UserMappingType user_mapping_version;
uint16 user_mapping_length;
select(UserMappingType) { }
} UserMappingData;
struct {
UserMappingType user_mapping_version;
uint16 user_mapping_length;
select(UserMappingType) { }
} UserMappingData;
struct{
UserMappingData user_mapping_data_list<1..2^16-1>;
}UserMappingDataList;
struct{
UserMappingData user_mapping_data_list<1..2^16-1>;
}UserMappingDataList;
user_mapping_length This field is the length (in bytes) of the data selected by UserMappingType.
user_mapping_length此字段是UserMappingType选择的数据的长度（以字节为单位）。
The UserMappingData structure contains a single mapping of type UserMappingType. This structure can be leveraged to define new types of user mapping hints in the future. The UserMappingDataList MAY carry multiple hints; it is defined as a vector of UserMappingData structures.
UserMappingData结构包含UserMappingType类型的单个映射。将来可以利用此结构定义新类型的用户映射提示。UserMappingDataList可能包含多个提示；它被定义为UserMappingData结构的向量。
No preference is given to the order in which hints are specified in this vector. If the client sends more than one hint, then the Server SHOULD use the applicable mapping supported by the server.
在此向量中指定提示的顺序没有优先权。如果客户端发送多个提示，则服务器应使用服务器支持的适用映射。
Implementations MAY support the UPN domain hint as specified in Section 6 of this document. Implementations MAY also support other user mapping types as they are defined. Definitions of standards-track user mapping types must include a discussion of internationalization considerations.
实现可能支持本文档第6节中指定的UPN域提示。实现还可以支持定义的其他用户映射类型。标准跟踪用户映射类型的定义必须包括国际化注意事项的讨论。
In order to negotiate sending user mapping data to a server in accordance with this specification, clients MUST include an extension of type "user_mapping" in the (extended) client hello, which SHALL contain a list of supported hint types.
为了根据本规范协商向服务器发送用户映射数据，客户端必须在（扩展的）客户端hello中包含类型为“user_mapping”的扩展，该扩展应包含支持的提示类型列表。
Servers that receive an extended client hello containing a "user_mapping" extension MAY indicate that they are willing to accept user mapping data by including an extension of type "user_mapping" in the (extended) server hello, which SHALL contain a list of preferred hint types.
接收包含“用户映射”扩展的扩展客户端hello的服务器可以通过在（扩展的）服务器hello中包含“用户映射”类型的扩展来表示它们愿意接受用户映射数据，该扩展应包含首选提示类型的列表。
After negotiation of the use of user mapping has been successfully completed (by exchanging hello messages including "user_mapping" extensions), clients MAY send a "SupplementalData" message containing the "UserMappingDataList" before the "Certificate" message. The message flow is illustrated in Figure 1 below.
在用户映射的使用协商成功完成后（通过交换包括“user_mapping”扩展名的hello消息），客户端可以发送一条“SupplementalData”消息，其中在“Certificate”消息之前包含“UserMappingDataList”。消息流如下图1所示。
Client Server
客户端服务器
ClientHello
/* with user_mapping ext */ -------->
ServerHello
/* with user-mapping ext */
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
ClientHello
/* with user_mapping ext */ -------->
ServerHello
/* with user-mapping ext */
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
SupplementalData
/* with UserMappingDataList */
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
SupplementalData
/* with UserMappingDataList */
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
* Indicates optional or situation-dependent messages that are not always sent according to RFC 2246 [N2] and RFC 4346 [N3].
* 表示根据RFC 2246[N2]和RFC 4346[N3]并非始终发送的可选或情况相关消息。
Figure 1. Message Flow with User Mapping Data
图1。具有用户映射数据的消息流
The server MUST expect and gracefully handle the case where the client chooses not to send any supplementalData handshake message even after successful negotiation of extensions. The client MAY at its own discretion decide that the user mapping hint it initially intended to send no longer is relevant for this session. One such reason could be that the server certificate fails to meet certain requirements.
即使在成功协商扩展之后，服务器也必须预期并优雅地处理客户端选择不发送任何补充数据握手消息的情况。客户端可以自行决定其最初打算发送的用户映射提示不再与此会话相关。其中一个原因可能是服务器证书无法满足某些要求。
The user mapping hint sent in the UserMappingDataList is unauthenticated data that MUST NOT be treated as a trusted identifier. Authentication of the user represented by that user mapping hint MUST rely solely on validation of the client certificate. One way to do this is to use the user mapping hint to locate and extract a certificate of the claimed user from the trusted directory and subsequently match this certificate against the validated client certificate from the TLS handshake.
UserMappingDataList中发送的用户映射提示是未经验证的数据，不能将其视为受信任的标识符。由该用户映射提示表示的用户的身份验证必须完全依赖于客户端证书的验证。一种方法是使用用户映射提示从可信目录中查找并提取声明用户的证书，然后将此证书与TLS握手中的已验证客户端证书进行匹配。
As the client is the initiator of this TLS extension, it needs to determine when it is appropriate to send the User Mapping Information. It may not be prudent to broadcast a user mapping hint to just any server at any time.
由于客户端是此TLS扩展的发起方，因此需要确定何时适合发送用户映射信息。在任何时候只向任何服务器广播用户映射提示可能是不明智的。
To avoid superfluously sending user mapping hints, clients SHOULD only send this information if it recognizes the server as a legitimate recipient. Recognition of the server can be done in many ways. One way to do this could be to recognize the name and address of the server.
为了避免多余地发送用户映射提示，只有当客户端将服务器识别为合法收件人时，才应发送此信息。可以通过多种方式识别服务器。一种方法是识别服务器的名称和地址。
In some cases, the user mapping hint may itself be regarded as sensitive. In such cases, the double handshake technique described in [N6] can be used to provide protection for the user mapping hint information.
在某些情况下，用户映射提示本身可能被认为是敏感的。在这种情况下，[N6]中描述的双握手技术可用于为用户映射提示信息提供保护。
This specification provides an informative description of one user mapping hint type for Domain Name hints and User Principal Name hints. Other hint types may be defined in other documents in the future.
本规范为域名提示和用户主体名称提示提供了一种用户映射提示类型的信息性描述。将来可能会在其他文档中定义其他提示类型。
The User Principal Name (UPN) in this hint type represents a name that specifies a user's entry in a directory in the form userName@domainName. Traditionally, Microsoft has relied on the presence of such a name form to be present in the client certificate when logging on to a domain account. However, this has several drawbacks since it prevents the use of certificates with an absent UPN and also requires re-issuance of certificates or issuance of multiple certificates to reflect account changes or creation of new accounts. The TLS extension, in combination with the defined hint type, provides a significant improvement to this situation as it allows a single certificate to be mapped to one or more accounts of the user and does not require the certificate to contain a proprietary UPN.
此提示类型中的用户主体名称（UPN）表示一个名称，该名称指定表单中目录中的用户条目userName@domainName. 传统上，Microsoft在登录到域帐户时依赖于在客户端证书中显示这样的名称表单。但是，这有几个缺点，因为它阻止使用缺少UPN的证书，并且还需要重新颁发证书或颁发多个证书以反映帐户更改或创建新帐户。TLS扩展与定义的提示类型相结合，为这种情况提供了显著的改进，因为它允许将单个证书映射到用户的一个或多个帐户，并且不要求证书包含专有的UPN。
The domain_name field MAY be used when only domain information is needed, e.g., where a user have accounts in multiple domains using the same username name, where that user name is known from another source (e.g., from the client certificate). When the user name is also needed, the user_principal_name field MAY be used to indicate both username and domain name. If both fields are present, then the server can make use of whichever one it chooses.
当仅需要域信息时，可以使用“域名”字段，例如，用户在多个域中使用相同用户名拥有帐户，该用户名是从其他来源（例如，从客户端证书）知道的。当还需要用户名时，可以使用user\u principal\u name字段来指示用户名和域名。如果两个字段都存在，那么服务器可以使用它选择的任何一个字段。
enum {
upn_domain_hint(64), (255)
} UserMappingType;
enum {
upn_domain_hint(64), (255)
} UserMappingType;
struct {
opaque user_principal_name<0..2^16-1>;
opaque domain_name<0..2^16-1>;
} UpnDomainHint;
struct {
opaque user_principal_name<0..2^16-1>;
opaque domain_name<0..2^16-1>;
} UpnDomainHint;
struct {
UserMappingType user_mapping_version;
uint16 user_mapping_length;
select(UserMappingType) {
case upn_domain_hint: UpnDomainHint;
}
} UserMappingData;
struct {
UserMappingType user_mapping_version;
uint16 user_mapping_length;
select(UserMappingType) {
case upn_domain_hint: UpnDomainHint;
}
} UserMappingData;
The user_principal_name field, when specified, SHALL be of the form "user@domain", where "user" is a UTF-8 encoded Unicode string that does not contain the "@" character, and "domain" is a domain name meeting the requirements in the following paragraph.
指定时，用户\u主体\u名称字段的格式应为“user@domain，其中“user”是一个UTF-8编码的Unicode字符串，不包含“@”字符，“domain”是一个满足以下段落要求的域名。
The domain_name field, when specified, SHALL contain a domain name [N5] in the usual text form; in other words, a sequence of one or more domain labels separated by ".", each domain label starting and ending with an alphanumeric character and possibly also containing "-" characters. This field is an "IDN-unaware domain name slot" as defined in RFC 3490 [N7], and therefore, domain names containing non-ASCII characters have to be processed as described in RFC 3490 before being stored in this field.
指定域名字段时，应包含通常文本形式的域名[N5]；换句话说，一个或多个域标签的序列，以“.”分隔，每个域标签以字母数字字符开头和结尾，可能还包含“-”字符。此字段是RFC 3490[N7]中定义的“IDN未知域名槽”，因此，包含非ASCII字符的域名必须按照RFC 3490中的说明进行处理，然后才能存储在此字段中。
The UpnDomainHint MUST at least contain a non-empty user_principal_name or a non-empty domain_name. The UpnDomainHint MAY contain both user_principal_name and domain_name.
UPNDOMAIN提示必须至少包含非空的用户名或域名。UPNDOMAIN提示可能同时包含用户名和域名。
IANA has taken the following actions:
IANA已采取以下行动：
1) Created an entry, user_mapping(6), in the existing registry for ExtensionType (defined in RFC 4366 [N4]).
1) 在ExtensionType（在RFC 4366[N4]中定义）的现有注册表中创建了一个条目user_mapping（6）。
2) Created an entry, user_mapping_data(0), in the new registry for SupplementalDataType (defined in RFC 4680).
2) 在新注册表中为SupplementalDataType（在RFC 4680中定义）创建了一个条目user_mapping_data（0）。
3) Established a registry for TLS UserMappingType values. The first entry in the registry is upn_domain_hint(64). TLS UserMappingType values in the inclusive range 0-63 (decimal) are assigned via RFC 2434 [N8] Standards Action. Values from the inclusive range 64-223 (decimal) are assigned via RFC 2434 Specification Required. Values from the inclusive range 224-255 (decimal) are reserved for RFC 2434 Private Use.
3) 为TLS UserMappingType值建立了注册表。注册表中的第一个条目是upn_domain_hint（64）。通过RFC 2434[N8]标准操作分配0-63（十进制）范围内的TLS UserMappingType值。包含范围64-223（十进制）的值通过RFC 2434规范指定。包含范围224-255（十进制）的值保留给RFC 2434专用。
[N1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[N1]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[N2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[N2]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC 2246，1999年1月。
[N3] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[N3]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
[N4] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006.
[N4]Blake Wilson，S.，Nystrom，M.，Hopwood，D.，Mikkelsen，J.，和T.Wright，“传输层安全（TLS）扩展”，RFC 4366，2006年4月。
[N5] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[N5]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[N6] Santesson, S., "TLS Handshake Message for Supplemental Data", RFC 4680, October 2006.
[N6]Santesson，S.，“补充数据的TLS握手信息”，RFC 46802006年10月。
[N7] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[N7]Faltstrom，P.，Hoffman，P.，和A.Costello，“应用程序中的域名国际化（IDNA）”，RFC 34902003年3月。
[N8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[N8]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
The authors extend a special thanks to Russ Housley, Eric Resocorla, and Paul Leach for their substantial contributions.
作者特别感谢Russ Housley、Eric Resocorla和Paul Leach做出的重大贡献。
Authors' Addresses
作者地址
Stefan Santesson Microsoft Finlandsgatan 30 164 93 KISTA Sweden
Stefan Santesson微软Finlandsgatan 30 164 93 KISTA瑞典
EMail: stefans@microsoft.com
EMail: stefans@microsoft.com
Ari Medvinsky Microsoft One Microsoft Way Redmond, WA 98052-6399 USA
Ari Medvinsky Microsoft One Microsoft Way Redmond，WA 98052-6399美国
EMail: arimed@microsoft.com
EMail: arimed@microsoft.com
Joshua Ball Microsoft One Microsoft Way Redmond, WA 98052-6399 USA
Joshua Ball微软一路微软华盛顿州雷德蒙98052-6399美国
EMail: joshball@microsoft.com
EMail: joshball@microsoft.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。