Network Working Group S. Yadav
Request for Comments: 2752 R. Yavatkar
Category: Standards Track Intel
R. Pabbati
P. Ford
T. Moore
Microsoft
S. Herzog
IPHighway
January 2000
Network Working Group S. Yadav
Request for Comments: 2752 R. Yavatkar
Category: Standards Track Intel
R. Pabbati
P. Ford
T. Moore
Microsoft
S. Herzog
IPHighway
January 2000
Identity Representation for RSVP
RSVP的身份表示
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 (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This document describes the representation of identity information in POLICY_DATA object [POL-EXT] for supporting policy based admission control in RSVP. The goal of identity representation is to allow a process on a system to securely identify the owner and the application of the communicating process (e.g. user id) and convey this information in RSVP messages (PATH or RESV) in a secure manner. We describe the encoding of identities as RSVP policy element. We describe the processing rules to generate identity policy elements for multicast merged flows. Subsequently, we describe representations of user identities for Kerberos and Public Key based user authentication mechanisms. In summary we describe the use of this identity information in an operational setting.
本文档描述了POLICY_数据对象[POL-EXT]中身份信息的表示，以支持RSVP中基于策略的准入控制。身份表示的目标是允许系统上的进程安全地识别通信进程的所有者和应用程序（例如用户id），并以安全的方式在RSVP消息（路径或RESV）中传递此信息。我们将身份编码描述为RSVP策略元素。我们描述了为多播合并流生成身份策略元素的处理规则。随后，我们描述了Kerberos和基于公钥的用户身份验证机制的用户身份表示。总之，我们描述了该身份信息在操作设置中的使用。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC-2119]中所述进行解释。
RSVP [RFC 2205] is a resource reservation setup protocol designed for an integrated services Internet [RFC 1633]. RSVP is used by a host to request specific quality of service (QoS) from the network for particular application data streams or flows. RSVP is also used by routers to deliver QoS requests to all nodes along the path(s) of the flows and to establish and maintain state to provide the requested service. RSVP requests will generally result in resources being reserved in each node along the data path. RSVP allows particular users to obtain preferential access to network resources, under the control of an admission control mechanism. Permission to make a reservation is based both upon the availability of the requested resources along the path of the data and upon satisfaction of policy rules. Providing policy based admission control mechanism based on user identity or application is one of the prime requirements.
RSVP[RFC 2205]是为综合服务互联网[RFC 1633]设计的资源预留设置协议。RSVP由主机用于从网络请求特定应用程序数据流或流的特定服务质量（QoS）。路由器还使用RSVP向流路径上的所有节点发送QoS请求，并建立和维护状态以提供请求的服务。RSVP请求通常会导致沿数据路径在每个节点中保留资源。RSVP允许特定用户在准入控制机制的控制下优先访问网络资源。进行预订的权限取决于数据路径上请求的资源的可用性以及满足策略规则。提供基于用户身份或应用程序的基于策略的准入控制机制是首要要求之一。
In order to solve these problems and implement identity based policy control it is required to identify the user and/or application making a RSVP request.
为了解决这些问题并实现基于身份的策略控制，需要识别发出RSVP请求的用户和/或应用程序。
This document proposes a mechanism for sending identification information in the RSVP messages and enables authorization decisions based on policy and identity.
本文档提出了一种在RSVP消息中发送标识信息的机制，并支持基于策略和标识的授权决策。
We describe the authentication policy element (AUTH_DATA) contained in the POLICY_DATA object. User process can generate an AUTH_DATA policy element and gives it to RSVP process (service) on the originating host. RSVP service inserts AUTH_DATA into the RSVP message to identify the owner (user and/or application) making the request for network resources. Network elements, such as routers, authenticate request using the credentials presented in the AUTH_DATA and admit the RSVP message based on admission policy. After a request has been authenticated, first hop router installs the RSVP state and forwards the new policy element returned by the Policy Decision Point (PDP) [POL-FRAME].
我们描述包含在policy_数据对象中的身份验证策略元素（AUTH_数据）。用户进程可以生成一个AUTH_数据策略元素，并将其提供给发起主机上的RSVP进程（服务）。RSVP服务将身份验证数据插入RSVP消息中，以标识请求网络资源的所有者（用户和/或应用程序）。网络元素（如路由器）使用AUTH_数据中提供的凭据对请求进行身份验证，并根据接纳策略接纳RSVP消息。请求经过身份验证后，第一跳路由器安装RSVP状态并转发策略决策点（PDP）[POL-FRAME]返回的新策略元素。
POLICY_DATA objects contain policy information and are carried by RSVP messages. A detail description of the format of POLICY_DATA object can be found in "RSVP Extensions for Policy Control" [POL-EXT].
策略\数据对象包含策略信息，由RSVP消息携带。有关策略_数据对象格式的详细说明，请参见“策略控制的RSVP扩展”[POL-EXT]。
In this section, we describe a policy element (PE) called authentication data (AUTH_DATA). AUTH_DATA policy element contains a list of authentication attributes.
在本节中，我们将描述一个称为身份验证数据（AUTH_data）的策略元素（PE）。AUTH_数据策略元素包含身份验证属性的列表。
+-------------+-------------+-------------+-------------+
| Length | P-Type = Identity Type |
+-------------+-------------+-------------+-------------+
// Authentication Attribute List //
+-------------------------------------------------------+
+-------------+-------------+-------------+-------------+
| Length | P-Type = Identity Type |
+-------------+-------------+-------------+-------------+
// Authentication Attribute List //
+-------------------------------------------------------+
Length The length of the policy element (including the Length and P-Type) is in number of octets (MUST be a multiple of 4) and indicates the end of the authentication attribute list.
长度策略元素的长度（包括长度和P类型）以八位字节为单位（必须是4的倍数），并指示身份验证属性列表的结尾。
P-Type (Identity Type) Type of identity information contained in this Policy Element supplied as the Policy element type (P-type). The Internet Assigned Numbers Authority (IANA) acts as a registry for policy element types for identity as described in the [POL-EXT]. Initially, the registry contains the following P-Types for identity:
P-Type（标识类型）作为策略元素类型（P-Type）提供的此策略元素中包含的标识信息的类型。互联网分配号码管理局（IANA）充当[POL-EXT]中所述的标识策略元素类型的注册表。最初，注册表包含以下标识的P类型：
1 AUTH_USER Authentication scheme to identify users
1用于标识用户的AUTH_用户身份验证方案
2 AUTH_APP Authentication scheme to identify applications
2用于识别应用程序的AUTH_应用程序身份验证方案
Authentication Attribute List
身份验证属性列表
Authentication attributes contain information specific to authentication method and type of AUTH_DATA. The policy element provides the mechanism for grouping a collection of authentication attributes.
身份验证属性包含特定于身份验证方法和身份验证数据类型的信息。policy元素提供了对身份验证属性集合进行分组的机制。
Authentication attributes MUST be encoded as a multiple of 4 octets, attributes that are not a multiple of 4 octets long MUST be padded to a 4-octet boundary.
身份验证属性必须编码为4个八位字节的倍数，长度不是4个八位字节倍数的属性必须填充到4个八位字节的边界。
+--------+--------+--------+--------+
| Length | A-Type |SubType |
+--------+--------+--------+--------+
| Value ...
+--------+--------+--------+--------+
+--------+--------+--------+--------+
| Length | A-Type |SubType |
+--------+--------+--------+--------+
| Value ...
+--------+--------+--------+--------+
Length The length field is two octets and indicates the actual length of the attribute (including the Length and A-Type fields) in number of octets. The length does not include any bytes padding to the value field to make the attribute multiple of 4 octets long.
长度长度字段是两个八位字节，以八位字节数表示属性的实际长度（包括长度和A型字段）。该长度不包括任何填充到值字段的字节，以使属性长度为4个八位字节的倍数。
A-Type Authentication attribute type (A-Type) field is one octet. IANA acts as a registry for A-Types as described in the section 9, IANA Considerations. Initially, the registry contains the following A-Types:
A-Type身份验证属性类型（A-Type）字段是一个八位字节。IANA充当第9节“IANA注意事项”中所述的a型注册中心。最初，注册表包含以下A类型：
1 POLICY_LOCATOR Unique string for locating the admission policy (such as X.500 DN described in [RFC 1779]).
1 POLICY_LOCATOR用于定位接纳策略的唯一字符串（如[RFC 1779]中描述的X.500 DN）。
2 CREDENTIAL User credential such as Kerberos ticket, or digital certificate. Application credential such as application ID.
2凭据用户凭据，如Kerberos票证或数字证书。应用程序凭据，如应用程序ID。
3 DIGITAL_SIGNATURE Digital signature of the authentication data policy element.
3数字签名认证数据策略元素的数字签名。
4 POLICY_ERROR_OBJECT Detailed information on policy failures.
4策略\u错误\u对象有关策略失败的详细信息。
SubType Authentication attribute sub-type field is one octet. Value of SubType depends on A-type.
子类型身份验证属性子类型字段是一个八位字节。子类型的值取决于A类型。
Value: The value field contains the attribute specific information.
值：值字段包含特定于属性的信息。
POLICY_LOCATOR is used to locate the admission policy for the user or application. Distinguished Name (DN) is unique for each User or application hence a DN is used as policy locator.
策略定位器用于定位用户或应用程序的准入策略。可分辨名称（DN）对于每个用户或应用程序都是唯一的，因此DN被用作策略定位器。
+-------+-------+-------+-------+
| Length |A-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+--------
+-------+-------+-------+-------+
| Length |A-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+--------
Length Length of the attribute, which MUST be >= 4.
属性的长度，必须大于等于4。
A-Type POLICY_LOCATOR
A型策略定位器
SubType Following sub types for POLICY_LOCATOR are defined. IANA acts as a registry for POLICY_LOCATOR sub types as described in the section 9, IANA Considerations. Initially, the registry contains the following sub types for POLICY_LOCATOR:
定义了策略定位器的以下子类型。IANA充当策略定位器子类型的注册表，如第9节“IANA注意事项”所述。最初，注册表包含策略定位器的以下子类型：
1 ASCII_DN OctetString contains the X.500 DN as described in the RFC 1779 as an ASCII string.
1 ASCII_DN OctetString包含RFC 1779中描述的X.500 DN作为ASCII字符串。
2 UNICODE_DN OctetString contains the X.500 DN described in the RFC 1779 as an UNICODE string.
2 UNICODE_DN OctetString包含RFC 1779中描述为UNICODE字符串的X.500 DN。
3 ASCII_DN_ENCRYPT OctetString contains the encrypted X.500 DN. The Kerberos session key or digital certificate private key is used for encryption. For Kerberos encryption the format is the same as returned from gss_seal [RFC 1509].
3 ASCII_DN_ENCRYPT八进制字符串包含加密的X.500 DN。Kerberos会话密钥或数字证书私钥用于加密。对于Kerberos加密，格式与从gss_seal[RFC 1509]返回的格式相同。
4 UNICODE_DN_ENCRYPT OctetString contains the encrypted UNICODE X.500 DN. The Kerberos session key or digital certificate private key is used for encryption. For Kerberos encryption the format is the same as returned from gss_seal [RFC 1509].
4 UNICODE_DN_ENCRYPT八进制字符串包含加密的UNICODE X.500 DN。Kerberos会话密钥或数字证书私钥用于加密。对于Kerberos加密，格式与从gss_seal[RFC 1509]返回的格式相同。
OctetString The OctetString field contains the DN.
八进制字符串八进制字符串字段包含DN。
CREDENTIAL indicates the credential of the user or application to be authenticated. For Kerberos authentication method the CREDENTIAL object contains the Kerberos session ticket. For public key based authentication this field contains a digital certificate.
CREDENTIAL表示要验证的用户或应用程序的凭据。对于Kerberos身份验证方法，凭据对象包含Kerberos会话票证。对于基于公钥的身份验证，此字段包含数字证书。
A summary of the CREDENTIAL attribute format is shown below. The fields are transmitted from left to right.
凭证属性格式的摘要如下所示。字段从左向右传输。
+-------+-------+-------+-------+
| Length |A-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+--------
+-------+-------+-------+-------+
| Length |A-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+--------
Length Length of the attribute, which MUST be >= 4.
属性的长度，必须大于等于4。
A-Type CREDENTIAL
A型凭证
SubType IANA acts as a registry for CREDENTIAL sub types as described in the section 9, IANA Considerations. Initially, the registry contains the following sub types for CREDENTIAL:
子类型IANA充当凭证子类型的注册表，如第9节“IANA注意事项”中所述。最初，注册表包含以下凭据子类型：
1 ASCII_ID OctetString contains user or application identification in plain ASCII text string.
1 ASCII_ID八进制字符串包含纯ASCII文本字符串中的用户或应用程序标识。
2 UNICODE_ID OctetString contains user or application identification in plain UNICODE text string.
2 UNICODE_ID八进制字符串包含纯UNICODE文本字符串中的用户或应用程序标识。
3 KERBEROS_TKT OctetString contains Kerberos ticket.
3 KERBEROS_TKT八进制字符串包含KERBEROS票证。
4 X509_V3_CERT OctetString contains X.509 V3 digital certificate [X.509].
4 X509_V3_证书八位字符串包含X.509 V3数字证书[X.509]。
5 PGP_CERT OctetString contains PGP digital certificate.
5 PGP_证书八位字符串包含PGP数字证书。
OctetString The OctetString contains the user or application credential.
八位字符串八位字符串包含用户或应用程序凭据。
The DIGITAL_SIGNATURE attribute MUST be the last attribute in the attribute list and contains the digital signature of the AUTH_DATA policy element. The digital signature signs all data in the AUTH_DATA policy element up to the DIGITAL_SIGNATURE. The algorithm used to compute the digital signature depends on the authentication method specified by the CREDENTIAL SubType field.
DIGITAL_SIGNATURE属性必须是属性列表中的最后一个属性，并且包含AUTH_数据策略元素的数字签名。数字签名对AUTH_数据策略元素中的所有数据进行签名，直至数字签名。用于计算数字签名的算法取决于凭证子类型字段指定的身份验证方法。
A summary of DIGITAL_SIGNATURE attribute format is described below.
数字签名属性格式概述如下。
+-------+-------+-------+-------+
| Length |A-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+--------
+-------+-------+-------+-------+
| Length |A-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+--------
Length Length of the attribute, which MUST be >= 4.
属性的长度，必须大于等于4。
ti3 A-Type DIGITAL_SIGNATURE
ti3 A型数字签名
SubType No sub types for DIGITAL_SIGNATURE are currently defined. This field MUST be set to 0.
子类型当前未定义数字签名的子类型。此字段必须设置为0。
OctetString OctetString contains the digital signature of the AUTH_DATA.
OctetString OctetString包含身份验证数据的数字签名。
This attribute is used to carry any specific policy control errors generated by a node when processing/validating an Authentication Data Policy Element. When a RSVP policy node (local policy decision point or remote PDP) encounters a request that fails policy control due to its Authentication Policy Element, it SHOULD add a POLICY_ERROR_CODE containing additional information about the reason the failure occurred into the policy element. This will then cause an appropriate PATH_ERROR or RESV_ERROR message to be generated with the policy element and appropriate RSVP error code in the message, which is returned to the request's source.
此属性用于携带节点在处理/验证身份验证数据策略元素时生成的任何特定策略控制错误。当RSVP策略节点（本地策略决策点或远程PDP）遇到由于其身份验证策略元素而导致策略控制失败的请求时，它应该在策略元素中添加一个包含有关失败原因的附加信息的策略错误代码。这将导致使用策略元素和消息中的相应RSVP错误代码生成相应的PATH_错误或RESV_错误消息，并将其返回到请求的源。
The AUTH_DATA policy element in the PATH or RSVP message SHOULD not contain the POLICY_ERROR_OBJECT attribute. These are only inserted into PATH_ERROR and RESV_ERROR messages when generated by policy aware intermediate nodes.
PATH或RSVP消息中的AUTH_数据策略元素不应包含policy_ERROR_对象属性。当由策略感知中间节点生成时，这些消息仅插入路径错误和RESV错误消息中。
+----------+----------+----------+----------+
| Length | A-Type |SubType(0)|
+----------+----------+----------+----------+
| 0 (Reserved) | ErrorValue |
+----------+----------+----------+----------+
| OctetString ...
+----------+----------+----------+----------+
+----------+----------+----------+----------+
| Length | A-Type |SubType(0)|
+----------+----------+----------+----------+
| 0 (Reserved) | ErrorValue |
+----------+----------+----------+----------+
| OctetString ...
+----------+----------+----------+----------+
Length Length of the attribute, which MUST be >= 8.
属性的长度，必须大于等于8。
A-Type POLICY_ERROR_CODE
A型策略错误代码
ErrorValue A 32-bit bit code containing the reason that the policy decision point failed to process the policy element. Following values have been defined.
ErrorValue包含策略决策点未能处理策略元素原因的32位代码。定义了以下值。
1 ERROR_NO_MORE_INFO No information is available. 2 UNSUPPORTED_CREDENTIAL_TYPE This type of credentials is not supported.
1错误\u无\u更多\u信息无可用信息。2不支持的\u凭据\u类型不支持此类型的凭据。
3 INSUFFICIENT_PRIVILEGES The credentials do not have sufficient privilege.
3权限不足凭据没有足够的权限。
4 EXPIRED_CREDENTIAL The credential has expired.
4过期\u凭证凭证已过期。
5 IDENTITY_CHANGED Identity has changed.
5标识已更改标识已更改。
OctetString The OctetString field contains information from the policy decision point that MAY contain additional information about the policy failure. For example, it may include a human-readable message in the ASCII text.
八进制字符串八进制字符串字段包含来自策略决策点的信息，这些信息可能包含有关策略失败的其他信息。例如，它可以包括ASCII文本中的人类可读消息。
Authentication attributes are grouped in a policy element to represent the identity credentials.
身份验证属性在策略元素中分组以表示身份凭据。
In simple user authentication method the user login ID (in plain ASCII or UNICODE text) is encoded as CREDENTIAL attribute. A summary of the simple user AUTH_DATA policy element is shown below.
在简单用户身份验证方法中，用户登录ID（纯ASCII或UNICODE文本）编码为凭证属性。简单用户身份验证数据策略元素的摘要如下所示。
+--------------+--------------+--------------+--------------+
| Length | P-type = AUTH_USER |
+--------------+--------------+--------------+--------------+
| Length |POLICY_LOCATOR| SubType |
+--------------+--------------+--------------+--------------+
| OctetString (User's Distinguished Name) ...
+--------------+--------------+--------------+--------------+
| Length |CREDENTIAL | ASCII_ID |
+--------------+--------------+--------------+--------------+
| OctetString (User's login ID) ...
+--------------+--------------+--------------+--------------+
+--------------+--------------+--------------+--------------+
| Length | P-type = AUTH_USER |
+--------------+--------------+--------------+--------------+
| Length |POLICY_LOCATOR| SubType |
+--------------+--------------+--------------+--------------+
| OctetString (User's Distinguished Name) ...
+--------------+--------------+--------------+--------------+
| Length |CREDENTIAL | ASCII_ID |
+--------------+--------------+--------------+--------------+
| OctetString (User's login ID) ...
+--------------+--------------+--------------+--------------+
Kerberos [RFC 1510] authentication uses a trusted third party (the Kerberos Distribution Center - KDC) to provide for authentication of the user to a network server. It is assumed that a KDC is present and both host and verifier of authentication information (router or PDP) implement Kerberos authentication.
Kerberos[RFC 1510]身份验证使用受信任的第三方（Kerberos分发中心-KDC）向网络服务器提供用户身份验证。假设存在KDC，并且身份验证信息的主机和验证器（路由器或PDP）都实现Kerberos身份验证。
A summary of the Kerberos AUTH_DATA policy element is shown below.
Kerberos AUTH_数据策略元素的摘要如下所示。
+--------------+--------------+--------------+--------------+
| Length | P-type = AUTH_USER |
+--------------+--------------+--------------+--------------+
| Length |POLICY_LOCATOR| SubType |
+--------------+--------------+--------------+--------------+
| OctetString (User's Distinguished Name) ...
+--------------+--------------+--------------+--------------+
| Length | CREDENTIAL | KERBEROS_TKT |
+--------------+--------------+--------------+--------------+
| OctetString (Kerberos Session Ticket) ...
+--------------+--------------+--------------+--------------+
+--------------+--------------+--------------+--------------+
| Length | P-type = AUTH_USER |
+--------------+--------------+--------------+--------------+
| Length |POLICY_LOCATOR| SubType |
+--------------+--------------+--------------+--------------+
| OctetString (User's Distinguished Name) ...
+--------------+--------------+--------------+--------------+
| Length | CREDENTIAL | KERBEROS_TKT |
+--------------+--------------+--------------+--------------+
| OctetString (Kerberos Session Ticket) ...
+--------------+--------------+--------------+--------------+
An RSVP enabled host is configured to construct and insert AUTH_DATA policy element into RSVP messages that designate use of the Kerberos authentication method (KERBEROS_TKT). Upon RSVP session initialization, the user application contacts the KDC to obtain a Kerberos ticket for the next network node or its PDP. A router when generating a RSVP message contacts the KDC to obtain a Kerberos ticket for the next hop network node or its PDP. The identity of the PDP or next network hop can be statically configured, learned via DHCP or maintained in a directory service. The Kerberos ticket is sent to the next network node (which may be a router or host) in a RSVP message. The KDC is used to validate the ticket and authentication the user sending RSVP message.
启用RSVP的主机配置为在指定使用Kerberos身份验证方法（Kerberos_TKT）的RSVP消息中构造并插入AUTH_数据策略元素。在RSVP会话初始化时，用户应用程序联系KDC以获取下一个网络节点或其PDP的Kerberos票证。路由器在生成RSVP消息时会与KDC联系，以获取下一跳网络节点或其PDP的Kerberos票证。PDP或下一个网络跃点的标识可以静态配置、通过DHCP学习或在目录服务中维护。Kerberos票证在RSVP消息中发送到下一个网络节点（可能是路由器或主机）。KDC用于验证票证并验证发送RSVP消息的用户。
In public key based user authentication method digital certificate is encoded as user credentials. The digital signature is used for authenticating the user. A summary of the public key user AUTH_DATA policy element is shown below.
在基于公钥的用户身份验证方法中，数字证书被编码为用户凭证。数字签名用于对用户进行身份验证。公钥用户身份验证数据策略元素的摘要如下所示。
+--------------+--------------+--------------+--------------+
| Length | P-type = AUTH_USER |
+--------------+--------------+--------------+--------------+
| Length |POLICY_LOCATOR| SubType |
+--------------+--------------+--------------+--------------+
| OctetString (User's Distinguished Name) ...
+--------------+--------------+--------------+--------------+
| Length | CREDENTIAL | SubType |
+--------------+--------------+--------------+--------------+
| OctetString (User's Digital Certificate) ...
+--------------+--------------+--------------+--------------+
| Length |DIGITAL_SIGN. | 0 |
+--------------+--------------+--------------+--------------+
| OctetString (Digital signature) ...
+--------------+--------------+--------------+--------------+
+--------------+--------------+--------------+--------------+
| Length | P-type = AUTH_USER |
+--------------+--------------+--------------+--------------+
| Length |POLICY_LOCATOR| SubType |
+--------------+--------------+--------------+--------------+
| OctetString (User's Distinguished Name) ...
+--------------+--------------+--------------+--------------+
| Length | CREDENTIAL | SubType |
+--------------+--------------+--------------+--------------+
| OctetString (User's Digital Certificate) ...
+--------------+--------------+--------------+--------------+
| Length |DIGITAL_SIGN. | 0 |
+--------------+--------------+--------------+--------------+
| OctetString (Digital signature) ...
+--------------+--------------+--------------+--------------+
Public key based authentication assumes following:
基于公钥的身份验证假设如下：
- RSVP service requestors have a pair of keys (private key and public key).
- RSVP服务请求者有一对密钥（私钥和公钥）。
- Private key is secured with the user.
- 私钥由用户保护。
- Public keys are stored in digital certificates and a trusted party, certificate authority (CA) issues these digital certificates.
- 公钥存储在数字证书中，可信方证书颁发机构（CA）颁发这些数字证书。
- The verifier (PDP or router) has the ability to verify the digital certificate.
- 验证器（PDP或路由器）能够验证数字证书。
RSVP requestor uses its private key to generate DIGITAL_SIGNATURE. User Authenticators (router, PDP) use the user's public key (stored in the digital certificate) to verify the signature and authenticate the user.
RSVP请求者使用其私钥生成数字签名。用户身份验证器（路由器、PDP）使用用户的公钥（存储在数字证书中）来验证签名并对用户进行身份验证。
The application authentication method encodes the application identification such as an executable filename as plain ASCII or UNICODE text.
应用程序身份验证方法将应用程序标识（如可执行文件名）编码为纯ASCII或UNICODE文本。
+----------------+--------------+--------------+--------------+
| Length | P-type = AUTH_APP |
+----------------+--------------+--------------+--------------+
| Length |POLICY_LOCATOR| SubType |
+----------------+--------------+--------------+--------------+
| OctetString (Application Identity attributes in
| the form of a Distinguished Name) ...
+----------------+--------------+--------------+--------------+
| Length | CREDENTIAL | ASCII_ID |
+----------------+--------------+--------------+--------------+
| OctetString (Application Id, e.g., vic.exe)
+----------------+--------------+--------------+--------------+
+----------------+--------------+--------------+--------------+
| Length | P-type = AUTH_APP |
+----------------+--------------+--------------+--------------+
| Length |POLICY_LOCATOR| SubType |
+----------------+--------------+--------------+--------------+
| OctetString (Application Identity attributes in
| the form of a Distinguished Name) ...
+----------------+--------------+--------------+--------------+
| Length | CREDENTIAL | ASCII_ID |
+----------------+--------------+--------------+--------------+
| OctetString (Application Id, e.g., vic.exe)
+----------------+--------------+--------------+--------------+
+-----+ +-----+
| PDP |-------+ | PDP |
+-----+ | ................... +-----+
| : : |
+--------+ : Transit : +-------+
+----| Router |------: Network : -------| Router|--+
| +--------+ : : +-------+ |
| | :.................: | |
| | | |
Host A B C D
+-----+ +-----+
| PDP |-------+ | PDP |
+-----+ | ................... +-----+
| : : |
+--------+ : Transit : +-------+
+----| Router |------: Network : -------| Router|--+
| +--------+ : : +-------+ |
| | :.................: | |
| | | |
Host A B C D
Figure 1: User and Application Authentication using AUTH_DATA PE
图1：使用AUTH_数据PE的用户和应用程序身份验证
Network nodes (hosts/routers) generate AUTH_DATA policy elements, contents of which are depend on the identity type used and the authentication method used. These generally contain authentication credentials (Kerberos ticket or digital certificate) and policy locators (which can be the X.500 Distinguished Name of the user or network node or application names). Network nodes generate AUTH_DATA policy element containing the authentication identity when making the RSVP request or forwarding a RSVP message.
网络节点（主机/路由器）生成身份验证数据策略元素，其内容取决于所使用的身份类型和所使用的身份验证方法。它们通常包含身份验证凭据（Kerberos票证或数字证书）和策略定位器（可以是用户或网络节点或应用程序名称的X.500可分辨名称）。网络节点在发出RSVP请求或转发RSVP消息时生成包含身份验证标识的AUTH_数据策略元素。
Network nodes generate user AUTH_DATA policy element using the following rules
网络节点使用以下规则生成用户身份验证数据策略元素
1. For unicast sessions the user policy locator is copied from the previous hop. The authentication credentials are for the current network node identity.
1. 对于单播会话，将从上一跳复制用户策略定位器。身份验证凭据用于当前网络节点标识。
2. For multicast messages the user policy locator is for the current network node identity. The authentication credentials are for the current network node.
2. 对于多播消息，用户策略定位器用于当前网络节点标识。身份验证凭据用于当前网络节点。
Network nodes generate application AUTH_DATA policy element using the following rules:
网络节点使用以下规则生成应用程序身份验证数据策略元素：
1. For unicast sessions the application AUTH_DATA is copied from the previous hop.
1. 对于单播会话，应用程序身份验证数据从上一跳复制。
2. For multicast messages the application AUTH_DATA is either the first application AUTH_DATA in the message or chosen by the PDP.
2. 对于多播消息，应用程序验证数据是消息中的第一个应用程序验证数据，或者由PDP选择。
An RSVP message is created as specified in [RFC2205] with following modifications.
按照[RFC2205]中的规定创建RSVP消息，并进行以下修改。
1. RSVP message MAY contain multiple AUTH_DATA policy elements.
1. RSVP消息可能包含多个验证数据策略元素。
2. Authentication policy element (AUTH_DATA) is created and the IdentityType field is set to indicate the identity type in the policy element.
2. 将创建身份验证策略元素（AUTH_DATA），并将IdentityType字段设置为指示策略元素中的身份类型。
- DN is inserted as POLICY_LOCATOR attribute.
- DN作为策略定位器属性插入。
- Credentials such as Kerberos ticket or digital certificate are inserted as the CREDENTIAL attribute.
- 凭据（如Kerberos票证或数字证书）作为凭据属性插入。
3. POLICY_DATA object (containing the AUTH_DATA policy element) is inserted in the RSVP message in appropriate place. If INTEGRITY object is not computed for the RSVP message then an INTEGRITY object SHOULD be computed for this POLICY_DATA object, as described in the [POL_EXT], and SHOULD be inserted as a Policy Data option.
3. 策略数据对象（包含AUTH_数据策略元素）插入RSVP消息中的适当位置。如果未为RSVP消息计算完整性对象，则应为此策略数据对象计算完整性对象，如[POL_EXT]中所述，并应作为策略数据选项插入。
RSVP message is processed as specified in [RFC2205] with following modifications.
RSVP消息按照[RFC2205]中的规定进行处理，并进行以下修改。
1. If router is not policy aware then it SHOULD send the RSVP message to the PDP and wait for response. If the router is policy unaware then it ignores the policy data objects and continues processing the RSVP message.
1. 如果路由器不知道策略，那么它应该向PDP发送RSVP消息并等待响应。如果路由器不知道策略，那么它将忽略策略数据对象并继续处理RSVP消息。
2. Reject the message if the response from the PDP is negative.
2. 如果PDP的响应为否定，则拒绝该消息。
3. Continue processing the RSVP message.
3. 继续处理RSVP消息。
1. Retrieve the AUTH_DATA policy element. Check the PE type field and return an error if the identity type is not supported.
1. 检索AUTH_数据策略元素。检查PE类型字段，如果不支持标识类型，则返回错误。
2. Verify user credential
2. 验证用户凭据
- Simple authentication: e.g. Get user ID and validate it, or get executable name and validate it.
- 简单身份验证：例如，获取用户ID并对其进行验证，或者获取可执行文件名并对其进行验证。
- Kerberos: Send the Kerberos ticket to the KDC to obtain the session key. Using the session key authenticate the user.
- Kerberos：将Kerberos票证发送到KDC以获取会话密钥。使用会话密钥对用户进行身份验证。
- Public Key: Validate the certificate that it was issued by a trusted Certificate Authority (CA) and authenticate the user or application by verifying the digital signature.
- 公钥：验证由可信证书颁发机构（CA）颁发的证书，并通过验证数字签名对用户或应用程序进行身份验证。
If PDP fails to verify the AUTH_DATA policy element then it MUST return policy control failure (Error Code = 02) to the PEP. The error values are described in [RFC 2205] and [POL-EXT]. Also PDP SHOULD supply a policy data object containing an AUTH_DATA Policy Element with A-Type=POLICY_ERROR_CODE containing more details on the Policy Control failure (see section 3.3.4). The PEP will include this Policy Data object in the outgoing RSVP Error message.
如果PDP未能验证AUTH_数据策略元素，则必须将策略控制失败（错误代码=02）返回给PEP。错误值在[RFC 2205]和[POL-EXT]中描述。此外，PDP还应提供一个策略数据对象，该对象包含一个带有a-Type=policy\u ERROR\u代码的AUTH\u数据策略元素，该代码包含有关策略控制失败的更多详细信息（参见第3.3.4节）。PEP将在传出的RSVP错误消息中包含此策略数据对象。
Following the policies outlined in [IANA-CONSIDERATIONS], authentication attribute types (A-Type)in the range 0-127 are allocated through an IETF Consensus action, A-Type values between 128-255 are reserved for Private Use and are not assigned by IANA.
按照[IANA-注意事项]中概述的策略，通过IETF一致行动分配范围为0-127的认证属性类型（A-Type），128-255之间的A-Type值保留供私人使用，IANA不分配。
Following the policies outlined in [IANA-CONSIDERATIONS], POLICY_LOCATOR SubType values in the range 0-127 are allocated through an IETF Consensus action, POLICY_LOCATOR SubType values between 128-255 are reserved for Private Use and are not assigned by IANA.
按照[IANA-注意事项]中概述的策略，0-127范围内的策略定位器子类型值通过IETF一致行动分配，128-255之间的策略定位器子类型值保留供私人使用，IANA不分配。
Following the policies outlined in [IANA-CONSIDERATIONS], CREDENTIAL SubType values in the range 0-127 are allocated through an IETF Consensus action, CREDENTIAL SubType values between 128-255 are reserved for Private Use and are not assigned by IANA.
按照[IANA-注意事项]中概述的策略，0-127范围内的凭证子类型值通过IETF一致行动进行分配，128-255之间的凭证子类型值保留供私人使用，不由IANA分配。
The purpose of this memo is to describe a mechanism to authenticate RSVP requests based on user identity in a secure manner. RSVP INTEGRITY object is used to protect the policy object containing user identity information from security (replay) attacks. Combining the AUTH_DATA policy element and the INTEGRITY object results in a secure access control that enforces authentication based on both the identity of the user and the identity of the originating node.
本备忘录旨在描述一种基于用户身份安全认证RSVP请求的机制。RSVP INTEGRITY对象用于保护包含用户身份信息的策略对象免受安全（重播）攻击。将AUTH_数据策略元素和INTEGRITY对象组合在一起会产生一个安全的访问控制，该控制基于用户的身份和发起节点的身份来实施身份验证。
Simple authentication does not contain credential that can be securely authenticated and is inherently less secured.
简单身份验证不包含可以安全身份验证且本质上安全性较低的凭据。
The Kerberos authentication mechanism is reasonably well secured.
Kerberos身份验证机制的安全性相当好。
User authentication using a public key certificate is known to provide the strongest security.
众所周知，使用公钥证书的用户身份验证可以提供最强的安全性。
We would like to thank Andrew Smith, Bob Lindell and many others for their valuable comments on this memo.
我们要感谢安德鲁·史密斯、鲍勃·林德尔和其他许多人对这份备忘录的宝贵意见。
[ASCII] Coded Character Set -- 7-Bit American Standard Code for Information Interchange, ANSI X3.4- 1986.
[ASCII]编码字符集——信息交换用7位美国标准代码，ANSI X3.4-1986。
[IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[IANA注意事项]Alvestrand，H.和T.Narten，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[POL-EXT] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[POL-EXT]Herzog，S.，“政策控制的RSVP扩展”，RFC 2750，2000年1月。
[POL-FRAME] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy-based Admission Control RSVP", RFC 2753, January 2000.
[POL-FRAME]Yavatkar，R.，Pendarakis，D.和R.Guerin，“基于政策的准入控制RSVP框架”，RFC 2753，2000年1月。
[RFC 1510] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[RFC 1510]Kohl，J.和C.Neuman，“Kerberos网络身份验证服务（V5）”，RFC 1510，1993年9月。
[RFC 1704] Haller, N. and R. Atkinson, "On Internet Authentication", RFC 1704, October 1994.
[RFC 1704]Haller，N.和R.Atkinson，“互联网认证”，RFC 17041994年10月。
[RFC 1779] Killie, S., "A String Representation of Distinguished Names", RFC 1779, March 1995.
[RFC 1779]Killie，S.，“可分辨名称的字符串表示”，RFC 1779，1995年3月。
[RFC 2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, September 1997.
[RFC 2205]Braden，R.，Zhang，L.，Berson，S.，Herzog，S.和S.Jamin，“资源预留协议（RSVP）-第1版功能规范”，RFC 2205，1997年9月。
[RFC 2209] Braden, R. and L. Zhang, "Resource ReSerVation Protocol (RSVP) - Version 1 Message Processing Rules", RFC 2209, September 1997.
[RFC 2209]Braden，R.和L.Zhang，“资源预留协议（RSVP）-第1版消息处理规则”，RFC 2209，1997年9月。
[UNICODE] The Unicode Consortium, "The Unicode Standard, Version 2.0", Addison-Wesley, Reading, MA, 1996.
[UNICODE]UNICODE联盟，“UNICODE标准，版本2.0”，Addison Wesley，雷丁，马萨诸塞州，1996年。
[X.509] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 2459, January 1999.
[X.509]Housley，R.，Ford，W.，Polk，W.和D.Solo，“互联网X.509公钥基础设施证书和CRL配置文件”，RFC 2459，1999年1月。
[X.509-ITU] ITU-T (formerly CCITT) Information technology - Open Systems Interconnection - The Directory: Authentication Framework Recommendation X.509 ISO/IEC 9594-8
[X.509-ITU]ITU-T（前身为CCITT）信息技术-开放系统互连-目录：认证框架建议X.509 ISO/IEC 9594-8
Satyendra Yadav Intel, JF3-206 2111 NE 25th Avenue Hillsboro, OR 97124
萨蒂恩德拉·亚达夫·因特尔（Satyendra Yadav Intel），JF3-206 2111东北希尔斯博罗25大道，或97124
EMail: Satyendra.Yadav@intel.com
EMail: Satyendra.Yadav@intel.com
Raj Yavatkar Intel, JF3-206 2111 NE 25th Avenue Hillsboro, OR 97124
拉吉·雅瓦卡尔·因特尔，地址：希尔斯伯勒东北25大道JF3-206 2111号，邮编：97124
EMail: Raj.Yavatkar@intel.com
EMail: Raj.Yavatkar@intel.com
Ramesh Pabbati Microsoft 1 Microsoft Way Redmond, WA 98054
Ramesh Pabbati微软1号微软路雷德蒙，华盛顿州，98054
EMail: rameshpa@microsoft.com
EMail: rameshpa@microsoft.com
Peter Ford Microsoft 1 Microsoft Way Redmond, WA 98054
彼得·福特微软1号微软路雷德蒙，华盛顿州，98054
EMail: peterf@microsoft.com
EMail: peterf@microsoft.com
Tim Moore Microsoft 1 Microsoft Way Redmond, WA 98054
Tim Moore微软1号微软路雷德蒙德，华盛顿州98054
EMail: timmoore@microsoft.com
EMail: timmoore@microsoft.com
Shai Herzog IPHighway, Inc. 55 New York Avenue Framingham, MA 01701
Shai Herzog IPHighway，Inc.马萨诸塞州弗雷明翰纽约大道55号01701
EMail: herzog@iphighway.com
EMail: herzog@iphighway.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。