Network Working Group L-N. Hamer
Request for Comments: 3520 B. Gage
Category: Standards Track Nortel Networks
B. Kosinski
Invidi Technologies
H. Shieh
AT&T Wireless
April 2003
Network Working Group L-N. Hamer
Request for Comments: 3520 B. Gage
Category: Standards Track Nortel Networks
B. Kosinski
Invidi Technologies
H. Shieh
AT&T Wireless
April 2003
Session Authorization Policy Element
会话授权策略元素
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 (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document describes the representation of a session authorization policy element for supporting policy-based per-session authorization and admission control. The goal of session authorization is to allow the exchange of information between network elements in order to authorize the use of resources for a service and to co-ordinate actions between the signaling and transport planes. This document describes how a process on a system authorizes the reservation of resources by a host and then provides that host with a session authorization policy element which can be inserted into a resource reservation protocol (e.g., the Resource ReSerVation Protocol (RSVP) PATH message) to facilitate proper and secure reservation of those resources within the network. We describe the encoding of session authorization information as a policy element conforming to the format of a Policy Data object (RFC 2750) and provide details relating to operations, processing rules and error scenarios.
本文档描述了用于支持基于策略的每会话授权和准入控制的会话授权策略元素的表示。会话授权的目标是允许网络元素之间的信息交换，以便授权服务资源的使用，并协调信令和传输平面之间的操作。本文档描述了系统上的进程如何授权主机保留资源，然后向该主机提供会话授权策略元素，该元素可插入到资源保留协议（例如，资源保留协议（RSVP）路径消息）中以便于在网络内正确和安全地保留这些资源。我们将会话授权信息的编码描述为符合策略数据对象（RFC 2750）格式的策略元素，并提供有关操作、处理规则和错误场景的详细信息。
Table of Contents
目录
1. Conventions used in this document..............................3
2. Introduction...................................................3
3. Policy Element for Session Authorization.......................4
3.1 Policy Data Object Format..................................4
3.2 Session Authorization Policy Element.......................4
3.3 Session Authorization Attributes...........................4
3.3.1 Authorizing Entity Identifier..........................6
3.3.2 Session Identifier.....................................7
3.3.3 Source Address.........................................7
3.3.4 Destination Address....................................9
3.3.5 Start time............................................10
3.3.6 End time..............................................11
3.3.7 Resources Authorized..................................11
3.3.8 Authentication data...................................12
4. Integrity of the AUTH_SESSION policy element..................13
4.1 Shared symmetric keys.....................................13
4.1.1 Operational Setting using shared symmetric keys.......13
4.2 Kerberos..................................................14
4.2.1. Operational Setting using Kerberos...................15
4.3 Public Key................................................16
4.3.1. Operational Setting for public key based
authentication.......................................16
4.3.1.1 X.509 V3 digital certificates.....................17
4.3.1.2 PGP digital certificates..........................17
5. Framework.....................................................18
5.1 The coupled model.........................................18
5.2 The associated model with one policy server...............18
5.3 The associated model with two policy servers..............19
5.4 The non-associated model..................................19
6. Message Processing Rules......................................20
6.1 Generation of the AUTH_SESSION by the authorizing entity..20
6.2 Message Generation (RSVP Host)............................20
6.3 Message Reception (RSVP-aware Router).....................20
6.4 Authorization (Router/PDP)................................21
7. Error Signaling...............................................22
8. IANA Considerations...........................................22
9. Security Considerations.......................................24
10. Acknowledgments..............................................24
11. Normative References.........................................25
12. Informative References.......................................27
13. Intellectual Property Statement..............................27
14. Contributors.................................................28
15. Authors' Addresses...........................................29
16. Full Copyright Statement.....................................30
1. Conventions used in this document..............................3
2. Introduction...................................................3
3. Policy Element for Session Authorization.......................4
3.1 Policy Data Object Format..................................4
3.2 Session Authorization Policy Element.......................4
3.3 Session Authorization Attributes...........................4
3.3.1 Authorizing Entity Identifier..........................6
3.3.2 Session Identifier.....................................7
3.3.3 Source Address.........................................7
3.3.4 Destination Address....................................9
3.3.5 Start time............................................10
3.3.6 End time..............................................11
3.3.7 Resources Authorized..................................11
3.3.8 Authentication data...................................12
4. Integrity of the AUTH_SESSION policy element..................13
4.1 Shared symmetric keys.....................................13
4.1.1 Operational Setting using shared symmetric keys.......13
4.2 Kerberos..................................................14
4.2.1. Operational Setting using Kerberos...................15
4.3 Public Key................................................16
4.3.1. Operational Setting for public key based
authentication.......................................16
4.3.1.1 X.509 V3 digital certificates.....................17
4.3.1.2 PGP digital certificates..........................17
5. Framework.....................................................18
5.1 The coupled model.........................................18
5.2 The associated model with one policy server...............18
5.3 The associated model with two policy servers..............19
5.4 The non-associated model..................................19
6. Message Processing Rules......................................20
6.1 Generation of the AUTH_SESSION by the authorizing entity..20
6.2 Message Generation (RSVP Host)............................20
6.3 Message Reception (RSVP-aware Router).....................20
6.4 Authorization (Router/PDP)................................21
7. Error Signaling...............................................22
8. IANA Considerations...........................................22
9. Security Considerations.......................................24
10. Acknowledgments..............................................24
11. Normative References.........................................25
12. Informative References.......................................27
13. Intellectual Property Statement..............................27
14. Contributors.................................................28
15. Authors' Addresses...........................................29
16. Full Copyright Statement.....................................30
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 BCP 14, RFC 2119 [RFC-2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC-2119]中的说明进行解释。
RSVP [RFC-2205] is one example of a resource reservation protocol that is used by a host to request specific services from the network for particular application data streams or flows. RSVP requests will generally result in resources being reserved in each router along the data path. RSVP allows users to obtain preferential access to network resources, under the control of an admission control mechanism. Such admission control is often based on user or application identity [RFC-3182], however, it is also valuable to provide the ability for per-session admission control.
RSVP[RFC-2205]是资源预留协议的一个示例，主机使用该协议从网络请求特定应用程序数据流或流的特定服务。RSVP请求通常会导致沿数据路径在每个路由器中保留资源。RSVP允许用户在准入控制机制的控制下优先访问网络资源。这种接纳控制通常基于用户或应用程序身份[RFC-3182]，然而，提供每会话接纳控制的能力也很有价值。
In order to allow for per-session admission control, it is necessary to provide a mechanism for ensuring use of resources by a host has been properly authorized before allowing the reservation of those resources. In order to meet this requirement, there must be information in the resource reservation message which may be used to verify the validity of the reservation request. This can be done by providing the host with a session authorization policy element which is inserted into the resource reservation message and verified by the network.
为了允许每会话接纳控制，有必要提供一种机制，以确保在允许保留这些资源之前主机对资源的使用已得到适当授权。为了满足此要求，资源保留消息中必须包含可用于验证保留请求有效性的信息。这可以通过向主机提供会话授权策略元素来实现，该元素插入到资源保留消息中并由网络验证。
This document describes the session authorization policy element (AUTH_SESSION) used to convey information about the resources authorized for use by a session. The host must obtain an AUTH_SESSION element from an authorizing entity via a session signaling protocol such as SIP [RFC-3261]. The host then inserts the AUTH_SESSION element into the resource reservation message to allow verification of the network resource request; in the case of RSVP, this element MUST be encapsulated in the Policy Data object [RFC-2750] of an RSVP PATH message. Network elements verify the request and then process the resource reservation message based on admission policy.
本文档描述了会话授权策略元素（AUTH_session），该元素用于传递有关授权会话使用的资源的信息。主机必须通过会话信令协议（如SIP[RFC-3261]）从授权实体获得认证会话元素。然后，主机将AUTH_会话元素插入到资源保留消息中，以允许验证网络资源请求；对于RSVP，此元素必须封装在RSVP路径消息的策略数据对象[RFC-2750]中。网元验证请求，然后根据接纳策略处理资源保留消息。
[RFC-3521] describes a framework in which a session authorization policy element may be utilized to contain information relevant to the network's decision to grant a reservation request.
[RFC-3521]描述了一个框架，在该框架中，会话授权策略元素可用于包含与网络授予保留请求的决定相关的信息。
The Session Authorization policy element conforms to the format of a POLICY_DATA object which contains policy information and is carried by policy based admission protocols such as RSVP. A detailed description of the POLICY_DATA object can be found in "RSVP Extensions for Policy Control" [RFC-2750].
会话授权策略元素符合包含策略信息的policy_数据对象的格式，并由基于策略的接纳协议（如RSVP）承载。有关策略_数据对象的详细说明，请参见“策略控制的RSVP扩展”[RFC-2750]。
In this section we describe a policy element (PE) called session authorization (AUTH_SESSION). The AUTH_SESSION policy element contains a list of fields which describe the session, along with other attributes.
在本节中，我们将描述一个称为会话授权（AUTH_session）的策略元素（PE）。AUTH_SESSION policy元素包含描述会话的字段列表以及其他属性。
+-------------+-------------+-------------+-------------+
| Length | P-Type = AUTH_SESSION |
+-------------+-------------+-------------+-------------+
// Session Authorization Attribute List //
+-------------------------------------------------------+
+-------------+-------------+-------------+-------------+
| Length | P-Type = AUTH_SESSION |
+-------------+-------------+-------------+-------------+
// Session Authorization Attribute List //
+-------------------------------------------------------+
Length: 16 bits The length of the policy element (including the Length and P-Type) is in number of octets (MUST be in multiples of 4) and indicates the end of the session authorization information block.
长度：16位策略元素的长度（包括长度和P-Type）以八位字节为单位（必须是4的倍数），表示会话授权信息块的结束。
P-Type: 16 bits (Session Authorization Type) AUTH_SESSION = 0x04 The Policy element type (P-type) of this element. The Internet Assigned Numbers Authority (IANA) acts as a registry for policy element types as described in [RFC-2750].
P-Type:16位（会话授权类型）AUTH_Session=0x04此元素的策略元素类型（P-Type）。互联网分配号码管理局（IANA）充当[RFC-2750]中所述策略元素类型的注册表。
Session Authorization Attribute List: variable length The session authorization attribute list is a collection of objects which describes the session and provides other information necessary to verify the resource reservation request. An initial set of valid objects is described in Section 3.3.
会话授权属性列表：可变长度会话授权属性列表是一组对象，用于描述会话并提供验证资源保留请求所需的其他信息。第3.3节描述了初始有效对象集。
A session authorization attribute may contain a variety of information and has both an attribute type and subtype. The attribute itself MUST be a multiple of 4 octets in length, and any attributes that are not a multiple of 4 octets long MUST be padded to a 4-octet boundary. All padding bytes MUST have a value of zero.
会话授权属性可以包含各种信息，并且具有属性类型和子类型。属性本身的长度必须是4个八位字节的倍数，任何长度不是4个八位字节倍数的属性都必须填充到4个八位字节的边界。所有填充字节的值必须为零。
+--------+--------+--------+--------+
| Length | X-Type |SubType |
+--------+--------+--------+--------+
| Value ...
+--------+--------+--------+--------+
+--------+--------+--------+--------+
| Length | X-Type |SubType |
+--------+--------+--------+--------+
| Value ...
+--------+--------+--------+--------+
Length: 16 bits The length field is two octets and indicates the actual length of the attribute (including Length, X-Type and SubType fields) in number of octets. The length does NOT include any bytes padding to the value field to make the attribute a multiple of 4 octets long.
长度：16位长度字段为两个八位字节，以八位字节数表示属性的实际长度（包括长度、X类型和子类型字段）。长度不包括任何字节填充到值字段，以使属性长度为4个八位字节的倍数。
X-Type: 8 bits Session authorization attribute type (X-Type) field is one octet. IANA acts as a registry for X-Types as described in section 7, IANA Considerations. Initially, the registry contains the following X-Types:
X-Type:8位会话授权属性类型（X-Type）字段为一个八位字节。IANA充当第7节“IANA注意事项”中所述的X类型注册表。最初，注册表包含以下X类型：
1 AUTH_ENT_ID The unique identifier of the entity which authorized the session.
1 AUTH\u ENT\u ID授权会话的实体的唯一标识符。
2 SESSION_ID Unique identifier for this session.
2会话ID此会话的唯一标识符。
3 SOURCE_ADDR Address specification for the session originator.
3会话发起人的源地址规范。
4 DEST_ADDR Address specification for the session end-point.
4会话端点的DEST_ADDR地址规范。
5 START_TIME The starting time for the session.
5开始时间会话的开始时间。
6 END_TIME The end time for the session.
6结束时间会话的结束时间。
7 RESOURCES The resources which the user is authorized to request.
7资源用户有权请求的资源。
8 AUTHENTICATION_DATA Authentication data of the session authorization policy element.
8身份验证\会话授权策略元素的数据身份验证数据。
SubType: 8 bits Session authorization attribute sub-type is one octet in length. The value of the SubType depends on the X-Type.
子类型：8位会话授权属性子类型长度为一个八位字节。子类型的值取决于X类型。
Value: variable length The attribute specific information.
值：属性特定信息的可变长度。
AUTH_ENT_ID is used to identify the entity which authorized the initial service request and generated the session authorization policy element. The AUTH_ENT_ID may be represented in various formats, and the SubType is used to define the format for the ID. The format for AUTH_ENT_ID is as follows:
身份验证ID用于标识授权初始服务请求并生成会话授权策略元素的实体。身份验证ID可以用各种格式表示，子类型用于定义ID的格式。身份验证ID的格式如下：
+-------+-------+-------+-------+
| Length |X-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+-------+
+-------+-------+-------+-------+
| Length |X-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+-------+
Length Length of the attribute, which MUST be > 4.
属性的长度，必须大于4。
X-Type AUTH_ENT_ID
X型身份验证ID
SubType The following sub-types for AUTH_ENT_ID are defined. IANA acts as a registry for AUTH_ENT_ID sub-types as described in section 7, IANA Considerations. Initially, the registry contains the following sub-types of AUTH_ENT_ID:
子类型定义了身份验证ID的以下子类型。IANA充当身份验证ID子类型的注册表，如第7节“IANA注意事项”所述。最初，注册表包含以下身份验证ID子类型：
1 IPV4_ADDRESS IPv4 address represented in 32 bits
1 IPV4\u地址以32位表示的IPV4地址
2 IPV6_ADDRESS IPv6 address represented in 128 bits
2 IPV6\u地址以128位表示的IPV6地址
3 FQDN Fully Qualified Domain Name as defined in RFC 1034 as an ASCII string.
3 RFC 1034中定义为ASCII字符串的FQDN完全限定域名。
4 ASCII_DN X.500 Distinguished name as defined in RFC 2253 as an ASCII string.
4 RFC 2253中定义为ASCII字符串的ASCII_DN X.500可分辨名称。
5 UNICODE_DN X.500 Distinguished name as defined in RFC 2253 as a UTF-8 string.
5 RFC 2253中定义为UTF-8字符串的UNICODE_DN X.500可分辨名称。
6 URI Universal Resource Identifier, as defined in RFC 2396.
6 URI通用资源标识符，如RFC 2396中所定义。
7 KRB_PRINCIPAL Fully Qualified Kerberos Principal name represented by the ASCII string of a principal followed by the @ realm name as defined in RFC 1510 (e.g., principalX@realmY).
7 KRB_主体完全限定Kerberos主体名称，由主体的ASCII字符串表示，后跟RFC 1510中定义的@realm name（例如。，principalX@realmY).
8 X509_V3_CERT The Distinguished Name of the subject of the certificate as defined in RFC 2253 as a UTF-8 string.
8 X509\u V3\u证书RFC 2253中定义为UTF-8字符串的证书主题的可分辨名称。
9 PGP_CERT The PGP digital certificate of the authorizing entity as defined in RFC 2440.
9 PGP_证书RFC 2440中定义的授权实体的PGP数字证书。
OctetString Contains the authorizing entity identifier.
OctetString包含授权实体标识符。
SESSION_ID is a unique identifier used by the authorizing entity to identify the request. It may be used for a number of purposes, including replay detection, or to correlate this request to a policy decision entry made by the authorizing entity. For example, the SESSION_ID can be based on simple sequence numbers or on a standard NTP timestamp.
会话ID是授权实体用于标识请求的唯一标识符。它可用于多种目的，包括重播检测，或将此请求与授权实体作出的策略决策条目相关联。例如，会话ID可以基于简单序列号或标准NTP时间戳。
+-------+-------+-------+-------+
| Length |X-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+-------+
+-------+-------+-------+-------+
| Length |X-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+-------+
Length Length of the attribute, which MUST be > 4.
属性的长度，必须大于4。
X-Type SESSION_ID
X类型会话\u ID
SubType No subtypes for SESSION_ID are currently defined; this field MUST be set to zero. The authorizing entity is the only network entity that needs to interpret the contents of the SESSION_ID therefore the contents and format are implementation dependent.
子类型当前未定义会话ID的子类型；此字段必须设置为零。授权实体是唯一需要解释会话ID内容的网络实体，因此内容和格式取决于实现。
OctetString Contains the session identifier.
OctetString包含会话标识符。
SOURCE_ADDR is used to identify the source address specification of the authorized session. This X-Type may be useful in some scenarios to make sure the resource request has been authorized for that particular source address and/or port.
SOURCE_ADDR用于标识授权会话的源地址规范。在某些情况下，此X-Type可能非常有用，可以确保资源请求已被授权用于特定的源地址和/或端口。
+-------+-------+-------+-------+
| Length |X-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+-------+
+-------+-------+-------+-------+
| Length |X-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+-------+
Length Length of the attribute, which MUST be > 4.
属性的长度，必须大于4。
X-Type SOURCE_ADDR
X型源地址
SubType The following sub types for SOURCE_ADDR are defined. IANA acts as a registry for SOURCE_ADDR sub-types as described in section 7, IANA Considerations. Initially, the registry contains the following sub types for SOURCE_ADDR:
子类型定义了源地址的以下子类型。IANA作为源地址子类型的注册表，如第7节IANA注意事项所述。最初，注册表包含源地址的以下子类型：
1 IPV4_ADDRESS IPv4 address represented in 32 bits
1 IPV4\u地址以32位表示的IPV4地址
2 IPV6_ADDRESS IPv6 address represented in 128 bits
2 IPV6\u地址以128位表示的IPV6地址
3 UDP_PORT_LIST list of UDP port specifications, represented as 16 bits per list entry.
3 UDP_PORT_UDP端口规范列表，表示为每个列表项16位。
4 TCP_PORT_LIST list of TCP port specifications, represented as 16 bits per list entry.
4 TCP\u端口\u TCP端口规范列表，表示为每个列表项16位。
OctetString The OctetString contains the source address information.
八位字符串八位字符串包含源地址信息。
In scenarios where a source address is required (see Section 5), at least one of the subtypes 1 through 2 (inclusive) MUST be included in every Session Authorization Data Policy Element. Multiple SOURCE_ADDR attributes MAY be included if multiple addresses have been authorized. The source address field of the resource reservation datagram (e.g., RSVP PATH) MUST match one of the SOURCE_ADDR attributes contained in this Session Authorization Data Policy Element.
在需要源地址的场景中（参见第5节），每个会话授权数据策略元素中必须至少包含子类型1到2（包括）中的一个。如果已授权多个地址，则可能包括多个源地址属性。资源保留数据报的源地址字段（例如，RSVP路径）必须与此会话授权数据策略元素中包含的源地址属性之一匹配。
At most, one instance of subtype 3 MAY be included in every Session Authorization Data Policy Element. At most, one instance of subtype 4 MAY be included in every Session Authorization Data Policy Element. Inclusion of a subtype 3 attribute does not prevent inclusion of a subtype 4 attribute (i.e., both UDP and TCP ports may be authorized).
在每个会话授权数据策略元素中最多可以包括子类型3的一个实例。在每个会话授权数据策略元素中最多可以包括子类型4的一个实例。包含子类型3属性不会阻止包含子类型4属性（即，UDP和TCP端口都可以被授权）。
If no PORT attributes are specified, then all ports are considered valid; otherwise, only the specified ports are authorized for use.
如果未指定端口属性，则认为所有端口都有效；否则，仅授权使用指定的端口。
Every source address and port list must be included in a separate SOURCE_ADDR attribute.
每个源地址和端口列表必须包含在单独的源地址属性中。
DEST_ADDR is used to identify the destination address of the authorized session. This X-Type may be useful in some scenarios to make sure the resource request has been authorized for that particular destination address and/or port.
DEST_ADDR用于标识授权会话的目标地址。在某些情况下，此X-Type可能很有用，可以确保资源请求已被授权用于特定的目标地址和/或端口。
+-------+-------+-------+-------+
| Length |X-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+-------+
+-------+-------+-------+-------+
| Length |X-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+-------+
Length Length of the attribute, which MUST be > 4.
属性的长度，必须大于4。
X-Type DEST_ADDR
X型目的地地址
SubType The following sub types for DEST_ADDR are defined. IANA acts as a registry for DEST_ADDR sub-types as described in section 7, IANA Considerations. Initially, the registry contains the following sub types for DEST_ADDR:
子类型定义了DEST_ADDR的以下子类型。IANA作为DEST_ADDR子类型的注册表，如第7节IANA注意事项所述。最初，注册表包含DEST_ADDR的以下子类型：
1 IPV4_ADDRESS IPv4 address represented in 32 bits
1 IPV4\u地址以32位表示的IPV4地址
2 IPV6_ADDRESS IPv6 address represented in 128 bits
2 IPV6\u地址以128位表示的IPV6地址
3 UDP_PORT_LIST list of UDP port specifications, represented as 16 bits per list entry.
3 UDP_PORT_UDP端口规范列表，表示为每个列表项16位。
4 TCP_PORT_LIST list of TCP port specifications, represented as 16 bits per list entry.
4 TCP\u端口\u TCP端口规范列表，表示为每个列表项16位。
OctetString The OctetString contains the destination address specification.
八进制字符串八进制字符串包含目标地址规范。
In scenarios where a destination address is required (see Section 5), at least one of the subtypes 1 through 2 (inclusive) MUST be included in every Session Authorization Data Policy Element. Multiple DEST_ADDR attributes MAY be included if multiple addresses have been authorized. The destination address field of the resource
在需要目标地址的场景中（参见第5节），每个会话授权数据策略元素中必须至少包含子类型1到2（包括）中的一个。如果已授权多个地址，则可能包括多个DEST_ADDR属性。资源的目标地址字段
reservation datagram (e.g., RSVP PATH) MUST match one of the DEST_ADDR attributes contained in this Session Authorization Data Policy Element.
保留数据报（例如，RSVP路径）必须与此会话授权数据策略元素中包含的DEST_ADDR属性之一匹配。
At most, one instance of subtype 3 MAY be included in every Session Authorization Data Policy Element. At most, one instance of subtype 4 MAY be included in every Session Authorization Data Policy Element. Inclusion of a subtype 3 attribute does not prevent inclusion of a subtype 4 attribute (i.e., both UDP and TCP ports may be authorized).
在每个会话授权数据策略元素中最多可以包括子类型3的一个实例。在每个会话授权数据策略元素中最多可以包括子类型4的一个实例。包含子类型3属性不会阻止包含子类型4属性（即，UDP和TCP端口都可以被授权）。
If no PORT attributes are specified, then all ports are considered valid; otherwise, only the specified ports are authorized for use.
如果未指定端口属性，则认为所有端口都有效；否则，仅授权使用指定的端口。
Every destination address and port list must be included in a separate DEST_ADDR attribute.
每个目标地址和端口列表必须包含在单独的DEST_ADDR属性中。
START_TIME is used to identify the start time of the authorized session and can be used to prevent replay attacks. If the AUTH_SESSION policy element is presented in a resource request, the network SHOULD reject the request if it is not received within a few seconds of the start time specified.
开始时间用于标识授权会话的开始时间，并可用于防止重播攻击。如果资源请求中显示了AUTH_会话策略元素，则如果在指定的开始时间的几秒钟内未收到请求，则网络应拒绝该请求。
+-------+-------+-------+-------+
| Length |X-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+-------+
+-------+-------+-------+-------+
| Length |X-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+-------+
Length Length of the attribute, which MUST be > 4.
属性的长度，必须大于4。
X-Type START_TIME
X型启动时间
SubType The following sub types for START_TIME are defined. IANA acts as a registry for START_TIME sub-types as described in section 7, IANA Considerations. Initially, the registry contains the following sub types for START_TIME:
子类型定义了以下开始时间的子类型。IANA充当启动时间子类型的注册表，如第7节“IANA注意事项”所述。最初，注册表包含以下启动时间子类型：
1 NTP_TIMESTAMP NTP Timestamp Format as defined in RFC 1305.
1 NTP_时间戳RFC 1305中定义的NTP时间戳格式。
OctetString The OctetString contains the start time.
八进制字符串八进制字符串包含开始时间。
END_TIME is used to identify the end time of the authorized session and can be used to limit the amount of time that resources are authorized for use (e.g., in prepaid session scenarios).
结束时间用于确定授权会话的结束时间，并可用于限制授权使用资源的时间量（例如，在预付费会话场景中）。
+-------+-------+-------+-------+
| Length |X-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+-------+
+-------+-------+-------+-------+
| Length |X-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+-------+
Length Length of the attribute, which MUST be > 4.
属性的长度，必须大于4。
X-Type END_TIME
X型结束时间
SubType The following sub types for END_TIME are defined. IANA acts as a registry for END_TIME sub-types as described in section 7, IANA Considerations. Initially, the registry contains the following sub types for END_TIME:
子类型定义了结束时间的以下子类型。IANA充当第7节“IANA注意事项”中所述的结束时间子类型的注册表。最初，注册表包含以下结束时间的子类型：
1 NTP_TIMESTAMP NTP Timestamp Format as defined in RFC 1305.
1 NTP_时间戳RFC 1305中定义的NTP时间戳格式。
OctetString The OctetString contains the end time.
八进制字符串八进制字符串包含结束时间。
RESOURCES is used to define the characteristics of the authorized session. This X-Type may be useful in some scenarios to specify the specific resources authorized to ensure the request fits the authorized specifications.
资源用于定义授权会话的特征。在某些情况下，此X-Type可用于指定授权的特定资源，以确保请求符合授权规范。
+-------+-------+-------+-------+
| Length |X-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+-------+
+-------+-------+-------+-------+
| Length |X-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+-------+
Length Length of the attribute, which MUST be > 4.
属性的长度，必须大于4。
X-Type RESOURCES
X型资源
SubType The following sub-types for RESOURCES are defined. IANA acts as a registry for RESOURCES sub-types as described in section 7, IANA Considerations. Initially, the registry contains the following sub types for RESOURCES:
子类型定义了资源的以下子类型。IANA作为资源子类型的注册中心，如第7节“IANA注意事项”所述。最初，注册表包含以下资源子类型：
1 BANDWIDTH Maximum bandwidth (kbps) authorized.
1带宽授权的最大带宽（kbps）。
2 FLOW_SPEC Flow spec specification as defined in RFC 2205.
2 RFC 2205中定义的流量规格流量规格。
3 SDP SDP Media Descriptor as defined in RFC 2327.
3 RFC 2327中定义的SDP SDP介质描述符。
4 DSCP Differentiated services codepoint as defined in RFC 2474.
4 RFC 2474中定义的DSCP区分服务代码点。
OctetString The OctetString contains the resources specification.
OctetString该OctetString包含资源规范。
In scenarios where a resource specification is required (see Section 5), at least one of the subtypes 1 through 4 (inclusive) MUST be included in every Session Authorization Data Policy Element. Multiple RESOURCE attributes MAY be included if multiple types of resources have been authorized (e.g., DSCP and BANDWIDTH).
在需要资源规范的场景中（参见第5节），每个会话授权数据策略元素中必须至少包含子类型1到4（包括）中的一个。如果已授权多种类型的资源（例如，DSCP和带宽），则可包括多种资源属性。
The AUTHENTICATION_DATA attribute contains the authentication data of the AUTH_SESSION policy element and signs all the data in the policy element up to the AUTHENTICATION_DATA. If the AUTHENTICATION_DATA attribute has been included in the AUTH_SESSION policy element, it MUST be the last attribute in the list. The algorithm used to compute the authentication data depends on the AUTH_ENT_ID SubType field. See Section 4 entitled Integrity of the AUTH_SESSION policy element.
AUTHENTICATION_DATA属性包含AUTH_会话策略元素的验证数据，并将策略元素中的所有数据签名到AUTHENTICATION_数据。如果AUTHENTICATION_数据属性已包含在AUTH_会话策略元素中，则它必须是列表中的最后一个属性。用于计算身份验证数据的算法取决于身份验证ID子类型字段。请参阅第4节“AUTH_会话策略元素的完整性”。
A summary of AUTHENTICATION_DATA attribute format is described below.
认证数据属性格式的摘要如下所述。
+-------+-------+-------+-------+
| Length |X-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+-------+
+-------+-------+-------+-------+
| Length |X-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+-------+
Length Length of the attribute, which MUST be > 4.
属性的长度，必须大于4。
X-Type AUTHENTICATION_DATA
X型身份验证\u数据
SubType No sub types for AUTHENTICATION_DATA are currently defined. This field MUST be set to 0.
子类型当前未定义身份验证数据的子类型。此字段必须设置为0。
OctetString The OctetString contains the authentication data of the AUTH_SESSION.
八进制字符串八进制字符串包含身份验证会话的身份验证数据。
This section describes how to ensure the integrity of the policy element is preserved.
本节介绍如何确保策略元素的完整性得到保留。
In shared symmetric key environments, the AUTH_ENT_ID MUST be of subtypes: IPV4_ADDRESS, IPV6_ADDRESS, FQDN, ASCII_DN, UNICODE_DN or URI. An example AUTH_SESSION policy element is shown below.
在共享对称密钥环境中，身份验证ID必须是以下子类型：IPV4地址、IPV6地址、FQDN、ASCII DN、UNICODE DN或URI。下面显示了一个示例AUTH_会话策略元素。
+--------------+--------------+--------------+--------------+
| Length | P-type = AUTH_SESSION |
+--------------+--------------+--------------+--------------+
| Length |SESSION_ID | zero |
+--------------+--------------+--------------+--------------+
| OctetString (The session identifier) ...
+--------------+--------------+--------------+--------------+
| Length | AUTH_ENT_ID | IPV4_ADDRESS |
+--------------+--------------+--------------+--------------+
| OctetString (The authorizing entity's Identifier) ...
+--------------+--------------+--------------+--------------+
| Length |AUTH DATA. | zero |
+--------------+--------------+--------------+--------------+
| KEY_ID |
+--------------+--------------+--------------+--------------+
| OctetString (Authentication data) ...
+--------------+--------------+--------------+--------------+
+--------------+--------------+--------------+--------------+
| Length | P-type = AUTH_SESSION |
+--------------+--------------+--------------+--------------+
| Length |SESSION_ID | zero |
+--------------+--------------+--------------+--------------+
| OctetString (The session identifier) ...
+--------------+--------------+--------------+--------------+
| Length | AUTH_ENT_ID | IPV4_ADDRESS |
+--------------+--------------+--------------+--------------+
| OctetString (The authorizing entity's Identifier) ...
+--------------+--------------+--------------+--------------+
| Length |AUTH DATA. | zero |
+--------------+--------------+--------------+--------------+
| KEY_ID |
+--------------+--------------+--------------+--------------+
| OctetString (Authentication data) ...
+--------------+--------------+--------------+--------------+
This assumes both the Authorizing Entity and the Network router/PDP are provisioned with shared symmetric keys and with policies detailing which algorithm to be used for computing the authentication data along with the expected length of the authentication data for that particular algorithm.
这假设授权实体和网络路由器/PDP都提供了共享对称密钥，并且提供了详细说明用于计算认证数据的算法以及该特定算法的认证数据的预期长度的策略。
Key maintenance is outside the scope of this document, but AUTH_SESSION implementations MUST at least provide the ability to manually configure keys and their parameters locally. The key used
密钥维护不在本文档的范围内，但AUTH_会话实现必须至少提供在本地手动配置密钥及其参数的能力。使用的钥匙
to produce the authentication data is identified by the AUTH_ENT_ID field. Since multiple keys may be configured for a particular AUTH_ENT_ID value, the first 32 bits of the AUTH_DATA field MUST be a key ID to be used to identify the appropriate key. Each key must also be configured with lifetime parameters for the time period within which it is valid as well as an associated cryptographic algorithm parameter specifying the algorithm to be used with the key. At a minimum, all AUTH_SESSION implementations MUST support the HMAC-MD5-128 [RFC-2104], [RFC-1321] cryptographic algorithm for computing the authentication data. New algorithms may be added by the IETF standards process.
生成身份验证数据的步骤由“身份验证ID”字段标识。由于可以为特定身份验证ID值配置多个密钥，因此身份验证数据字段的前32位必须是用于标识适当密钥的密钥ID。每个密钥还必须配置有效时间段的生存期参数，以及指定要与密钥一起使用的算法的相关加密算法参数。至少，所有认证会话实现必须支持HMAC-MD5-128[RFC-2104]、[RFC-1321]加密算法来计算认证数据。IETF标准过程可能会添加新算法。
It is good practice to regularly change keys. Keys MUST be configurable such that their lifetimes overlap allowing smooth transitions between keys. At the midpoint of the lifetime overlap between two keys, senders should transition from using the current key to the next/longer-lived key. Meanwhile, receivers simply accept any identified key received within its configured lifetime and reject those that are not.
定期更换钥匙是一种很好的做法。关键点必须是可配置的，以便它们的生命周期重叠，从而允许关键点之间的平滑过渡。在两个密钥的生命周期重叠的中点，发送者应该从使用当前密钥过渡到下一个/寿命更长的密钥。同时，接收器只接受在其配置的生命周期内接收到的任何已识别密钥，并拒绝未识别的密钥。
In a Kerberos environment, the AUTH_ENT_ID MUST be of the subtype KRB_PRINCIPAL. The KRB_PRINCIPAL field is defined as the Fully Qualified Kerberos Principal name of the authorizing entity. Kerberos [RFC-1510] authentication uses a trusted third party (the Kerberos Distribution Center - KDC) to provide for authentication of the AUTH_SESSION to a network server. It is assumed that a KDC is present and both host and verifier of authentication information (authorizing entity and router/PDP) implement Kerberos authentication.
在Kerberos环境中，身份验证ID必须是KRB_主体的子类型。KRB_主体字段定义为授权实体的完全限定Kerberos主体名称。Kerberos[RFC-1510]身份验证使用受信任的第三方（Kerberos分发中心-KDC）提供对网络服务器的身份验证会话的身份验证。假设存在KDC，并且身份验证信息的主机和验证器（授权实体和路由器/PDP）都实现Kerberos身份验证。
An example of the Kerberos AUTH_DATA policy element is shown below.
Kerberos AUTH_数据策略元素的示例如下所示。
+--------------+--------------+--------------+--------------+
| Length | P-type = AUTH_SESSION |
+--------------+--------------+--------------+--------------+
| Length |SESSION_ID | zero |
+--------------+--------------+--------------+--------------+
| OctetString (The session identifier) ...
+--------------+--------------+--------------+--------------+
| Length | AUTH_ENT_ID | KERB_P. |
+--------------+--------------+--------------+--------------+
| OctetString (The principal@realm name) ...
+--------------+--------------+--------------+--------------+
+--------------+--------------+--------------+--------------+
| Length | P-type = AUTH_SESSION |
+--------------+--------------+--------------+--------------+
| Length |SESSION_ID | zero |
+--------------+--------------+--------------+--------------+
| OctetString (The session identifier) ...
+--------------+--------------+--------------+--------------+
| Length | AUTH_ENT_ID | KERB_P. |
+--------------+--------------+--------------+--------------+
| OctetString (The principal@realm name) ...
+--------------+--------------+--------------+--------------+
An authorizing entity is configured to construct the AUTH_SESSION policy element that designates use of the Kerberos authentication method (KRB_PRINCIPAL) as defined in RFC 1510. Upon reception of the resource reservation request, the router/PDP contacts the local KDC, with a KRB_AS_REQ message, to request credentials for the authorizing entity (principal@realm). In this request, the client (router/PDP) sends (in cleartext) its own identity and the identity of the server (the authorizing entity taken from the AUTH_ENT_ID field) for which it is requesting credentials. The local KDC responds with these credentials in a KRB_AS_REP message, encrypted in the client's key. The credentials consist of 1) a "ticket" for the server and 2) a temporary encryption key (often called a "session key"). The router/PDP uses the ticket to access the authorizing entity with a KRB_AP_REQ message. The session key (now shared by the router/PDP and the authorizing entity) is used to authenticate the router/PDP, and is used to authenticate the authorizing entity. The session key is an encryption key and is also used to encrypt further communication between the two parties. The authorizing entity responds by sending a concatenated message of a KRB_AP_REP and a KRB_SAFE. The KRB_AP_REP is used to authenticate the authorizing entity. The KRB_SAFE message contains the authentication data in the safe-body field. The authentication data must be either a 16 byte MD5 hash or 20 byte SHA-1 hash of all data in the AUTH_SESSION policy element up to the AUTHENTICATION_DATA (note that when using Kerberos the AUTH_SESSION PE should not include AUTHENTICATION_DATA as this is sent in the KRB_SAFE message). The router/PDP independently computes the hash, and compares it with the received hash in the user-data field of the KRB-SAFE-BODY [RFC-1510].
授权实体被配置为构造AUTH_会话策略元素，该元素指定使用RFC 1510中定义的Kerberos身份验证方法（KRB_主体）。在接收到资源预留请求后，路由器/PDP使用KRB_AS_REQ消息联系本地KDC，以请求授权实体的凭证(principal@realm). 在该请求中，客户机（路由器/PDP）发送（明文）自己的身份和服务器的身份（从身份验证ID字段中获取的授权实体），并为其请求凭据。本地KDC在KRB_AS_REP消息中使用这些凭据进行响应，该消息在客户端密钥中加密。凭据包括1）服务器的“票证”和2）临时加密密钥（通常称为“会话密钥”）。路由器/PDP使用票据通过KRB_AP_REQ消息访问授权实体。会话密钥（现在由路由器/PDP和授权实体共享）用于验证路由器/PDP，并用于验证授权实体。会话密钥是加密密钥，还用于加密双方之间的进一步通信。授权实体通过发送KRB_AP_代表和KRB_保险箱的连接消息进行响应。KRB_AP_代表用于验证授权实体。KRB_安全消息包含安全正文字段中的身份验证数据。身份验证数据必须是身份验证会话策略元素中直到身份验证数据的所有数据的16字节MD5哈希或20字节SHA-1哈希（请注意，使用Kerberos时，身份验证会话PE不应包括身份验证数据，因为这是在KRB_安全消息中发送的）。路由器/PDP独立计算散列，并将其与KRB-SAFE-BODY[RFC-1510]的用户数据字段中接收到的散列进行比较。
At a minimum, all AUTH_SESSION implementations using Kerberos MUST support the Kerberos des-cbc-md5 encryption type [RFC-1510] (for encrypted data in tickets and Kerberos messages) and the Kerberos rsa-md5-des checksum type [RFC-1510] (for the KRB_SAFE checksum) checksum. New algorithms may be added by the IETF standards process. Triple-DES encryption is supported in many Kerberos implementations (although not specified in [RFC-1510]), and SHOULD be used over single DES.
至少，所有使用Kerberos的身份验证会话实现必须支持Kerberos des-cbc-md5加密类型[RFC-1510]（用于票据和Kerberos消息中的加密数据）和Kerberos rsa-md5-des校验和类型[RFC-1510]（用于KRB_安全校验和）校验和。IETF标准过程可能会添加新算法。在许多Kerberos实现中支持三重DES加密（尽管[RFC-1510]中未指定），并且应在单DES上使用三重DES加密。
For cases where the authorizing entity is in a different realm (i.e., administrative domain, organizational boundary), the router/PDP needs to fetch a cross-realm Ticket Granting Ticket (TGT) from its local KDC. This TGT can be used to fetch authorizing entity tickets from the KDC in the remote realm. Note that for performance considerations, tickets are typically cached for extended periods.
对于授权实体位于不同领域（即管理域、组织边界）的情况，路由器/PDP需要从其本地KDC获取跨领域票证授予票证（TGT）。此TGT可用于从远程领域的KDC获取授权实体票证。请注意，出于性能考虑，票据通常会缓存较长的时间。
In a public key environment, the AUTH_ENT_ID MUST be of the subtypes: X509_V3_CERT or PGP_CERT. The authentication data is used for authenticating the authorizing entity. An example of the public key AUTH_SESSION policy element is shown below.
在公钥环境中，身份验证ID必须是子类型：X509\u V3\u CERT或PGP\u CERT。身份验证数据用于验证授权实体。公钥AUTH_会话策略元素的示例如下所示。
+--------------+--------------+--------------+--------------+
| Length | P-type = AUTH_SESSION |
+--------------+--------------+--------------+--------------+
| Length |SESSION_ID | zero |
+--------------+--------------+--------------+--------------+
| OctetString (The session identifier) ...
+--------------+--------------+--------------+--------------+
| Length | AUTH_ENT_ID | PGP_CERT |
+--------------+--------------+--------------+--------------+
| OctetString (Authorizing entity Digital Certificate) ...
+--------------+--------------+--------------+--------------+
| Length |AUTH DATA. | zero |
+--------------+--------------+--------------+--------------+
| OctetString (Authentication data) ...
+--------------+--------------+--------------+--------------+
+--------------+--------------+--------------+--------------+
| Length | P-type = AUTH_SESSION |
+--------------+--------------+--------------+--------------+
| Length |SESSION_ID | zero |
+--------------+--------------+--------------+--------------+
| OctetString (The session identifier) ...
+--------------+--------------+--------------+--------------+
| Length | AUTH_ENT_ID | PGP_CERT |
+--------------+--------------+--------------+--------------+
| OctetString (Authorizing entity Digital Certificate) ...
+--------------+--------------+--------------+--------------+
| Length |AUTH DATA. | zero |
+--------------+--------------+--------------+--------------+
| OctetString (Authentication data) ...
+--------------+--------------+--------------+--------------+
Public key based authentication assumes the following:
基于公钥的身份验证假设如下：
- Authorizing entities have a pair of keys (private key and public key).
- 授权实体有一对密钥（私钥和公钥）。
- Private key is secured with the authorizing entity.
- 私钥由授权实体保护。
- 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或路由器）能够验证数字证书。
Authorizing entity uses its private key to generate AUTHENTICATION_DATA. Authenticators (router, PDP) use the authorizing entity's public key (stored in the digital certificate) to verify and authenticate the policy element.
授权实体使用其私钥生成身份验证数据。验证器（路由器、PDP）使用授权实体的公钥（存储在数字证书中）来验证和验证策略元素。
When the AUTH_ENT_ID is of type X509_V3_CERT, AUTHENTICATION_DATA MUST be generated following these steps:
当身份验证ID为X509\u V3\u CERT类型时，必须按照以下步骤生成身份验证数据：
- A Signed-data is constructed as defined in section 5 of CMS [RFC-3369]. A digest is computed on the content (as specified in section 6.1) with a signer-specific message-digest algorithm. The certificates field contains the chain of authorizing entity's X.509 V3 digital certificates. The certificate revocation list is defined in the crls field. The digest output is digitally signed following section 8 of RFC 3447, using the signer's private key.
- 签名数据按照CMS[RFC-3369]第5节的规定构造。摘要是使用特定于签名者的消息摘要算法对内容（如第6.1节所述）进行计算的。证书字段包含授权实体的X.509 V3数字证书链。证书吊销列表在crls字段中定义。摘要输出使用签名者的私钥按照RFC 3447第8节进行数字签名。
When the AUTH_ENT_ID is of type X509_V3_CERT, verification MUST be done following these steps:
当身份验证ID为X509\u V3\u证书类型时，必须按照以下步骤进行验证：
- Parse the X.509 V3 certificate to extract the distinguished name of the issuer of the certificate. - Certification Path Validation is performed as defined in section 6 of RFC 3280. - Parse through the Certificate Revocation list to verify that the received certificate is not listed. - Once the X.509 V3 certificate is validated, the public key of the authorizing entity can be extracted from the certificate. - Extract the digest algorithm and the length of the digested data by parsing the CMS signed-data. - The recipient independently computes the message digest. This message digest and the signer's public key are used to verify the signature value.
- 解析X.509 V3证书以提取证书颁发者的可分辨名称。-按照RFC 3280第6节的规定执行认证路径验证。-解析证书吊销列表以验证未列出收到的证书。-验证X.509 V3证书后，可以从证书中提取授权实体的公钥。-通过解析CMS签名数据，提取摘要算法和摘要数据的长度。-收件人独立计算邮件摘要。此消息摘要和签名者的公钥用于验证签名值。
This verification ensures integrity, non-repudiation and data origin.
此验证可确保完整性、不可否认性和数据来源。
When the AUTH_ENT_ID is of type PGP_CERT, AUTHENTICATION_DATA MUST be generated following these steps:
当身份验证ID为PGP证书类型时，必须按照以下步骤生成身份验证数据：
- AUTHENTICATION_DATA contains a Signature Packet as defined in section 5.2.3 of RFC 2440. In summary:
- 认证数据包含RFC 2440第5.2.3节中定义的签名包。总之：
- Compute the hash of all data in the AUTH_SESSION policy element up to the AUTHENTICATION_DATA. - The hash output is digitally signed following section 8 of RFC 3447, using the signer's private key.
- 计算AUTH_会话策略元素中直到AUTHENTICATION_数据的所有数据的哈希值。-根据RFC 3447第8节，使用签名者的私钥对散列输出进行数字签名。
When the AUTH_ENT_ID is of type PGP_CERT, verification MUST be done following these steps:
当身份验证ID为PGP证书类型时，必须按照以下步骤进行验证：
- Validate the certificate. - Once the PGP certificate is validated, the public key of the authorizing entity can be extracted from the certificate. - Extract the hash algorithm and the length of the hashed data by parsing the PGP signature packet. - The recipient independently computes the message digest. This message digest and the signer's public key are used to verify the signature value.
- 验证证书。-PGP证书验证后，可以从证书中提取授权实体的公钥。-通过解析PGP签名包，提取哈希算法和哈希数据的长度。-收件人独立计算邮件摘要。此消息摘要和签名者的公钥用于验证签名值。
This verification ensures integrity, non-repudiation and data origin.
此验证可确保完整性、不可否认性和数据来源。
[RFC-3521] describes a framework in which the AUTH_SESSION policy element may be utilized to transport information required for authorizing resource reservation for media flows. [RFC-3521] introduces 4 different models:
[RFC-3521]描述了一个框架，在该框架中，可利用授权会话策略元素传输授权媒体流资源保留所需的信息。[RFC-3521]介绍了4种不同的型号：
1- the coupled model 2- the associated model with one policy server 3- the associated model with two policy servers 4- the non-associated model.
1-耦合模型2-具有一个策略服务器的关联模型3-具有两个策略服务器的关联模型4-非关联模型。
The fields that are required in an AUTH SESSION policy element dependent on which of the models is used.
身份验证会话策略元素中所需的字段取决于所使用的模型。
In the Coupled Model, the only information that MUST be included in the policy element is the SESSION_ID; it is used by the Authorizing Entity to correlate the resource reservation request with the media authorized during session set up. Since the End Host is assumed to be untrusted, the Policy Server SHOULD take measures to ensure that the integrity of the SESSION_ID is preserved in transit; the exact mechanisms to be used and the format of the SESSION_ID are implementation dependent.
在耦合模型中，策略元素中必须包含的唯一信息是会话ID；授权实体使用它将资源保留请求与会话设置期间授权的媒体关联起来。由于假定终端主机不受信任，策略服务器应采取措施确保会话ID的完整性在传输过程中得以保持；要使用的确切机制和会话ID的格式取决于实现。
In this model, the contents of the AUTH_SESSION policy element MUST include:
在此模型中，AUTH_会话策略元素的内容必须包括：
- A session identifier - SESSION_ID. This is information that the authorizing entity can use to correlate the resource reservation request with the media authorized during session set up.
- 会话标识符-会话ID。这是授权实体可用于将资源保留请求与会话设置期间授权的媒体关联的信息。
- The identity of the authorizing entity - AUTH_ENT_ID. This information is used by the Edge Router to determine which authorizing entity (Policy Server) should be used to solicit resource policy decisions.
- 授权实体的标识-身份验证ID。边缘路由器使用此信息确定应使用哪个授权实体（策略服务器）来请求资源策略决策。
In some environments, an Edge Router may have no means for determining if the identity refers to a legitimate Policy Server within its domain. In order to protect against redirection of authorization requests to a bogus authorizing entity, the AUTH_SESSION MUST also include:
在某些环境中，边缘路由器可能无法确定标识是否指向其域中的合法策略服务器。为了防止将授权请求重定向到虚假授权实体，授权会话还必须包括：
- AUTHENTICATION_DATA. This authentication data is calculated over all other fields of the AUTH_SESSION policy element.
- 验证数据。此身份验证数据是通过AUTH_会话策略元素的所有其他字段计算的。
The content of the AUTH_SESSION Policy Element is identical to the associated model with one policy server.
AUTH_会话策略元素的内容与具有一个策略服务器的关联模型相同。
In this model, the AUTH_SESSION MUST contain sufficient information to allow the Policy Server to make resource policy decisions autonomously from the authorizing entity. The policy element is created using information about the session by the authorizing entity. The information in the AUTH_SESSION policy element MUST include:
在此模型中，AUTH_会话必须包含足够的信息，以允许策略服务器从授权实体自主地做出资源策略决策。策略元素是由授权实体使用有关会话的信息创建的。AUTH_会话策略元素中的信息必须包括：
- Calling party IP address or Identity (e.g., FQDN) - SOURCE_ADDR X-TYPE - Called party IP address or Identity (e.g., FQDN) - DEST_ADDR X-TYPE - The characteristics of (each of) the media stream(s) authorized for this session - RESOURCES X-TYPE - The authorization lifetime - START_TIME X-TYPE - The identity of the authorizing entity to allow for validation of the token in shared symmetric key and Kerberos schemes - AUTH_ENT_ID X-TYPE - The credentials of the authorizing entity in a public-key scheme - AUTH_ENT_ID X-TYPE - Authentication data used to prevent tampering with the AUTH_SESSION policy element - AUTHENTICATION_DATA
- 主叫方IP地址或标识（如FQDN）-源地址X型-被叫方IP地址或标识（如FQDN）-目的地址X型-媒体流的特征为此会话授权-资源X-TYPE-授权生存期-开始时间X-TYPE-授权实体的标识，以允许验证共享对称密钥和Kerberos方案中的令牌-身份验证ID X-TYPE-公钥方案中授权实体的凭据-身份验证ID X-TYPE-身份验证用于防止篡改AUTH_会话策略元素的数据-AUTHENTICATION_数据
Furthermore, the AUTH_SESSION policy element MAY contain:
此外，AUTH_会话策略元素可能包含：
- The lifetime of (each of) the media stream(s) - END_TIME X-TYPE - Calling party port number - SOURCE_ADDR X-TYPE - Called party port number - DEST_ADDR X-TYPE
- （每个）媒体流的生存期-结束时间X-TYPE-主叫方端口号-源地址X-TYPE-被叫方端口号-目的地地址X-TYPE
All AUTH_SESSION fields MUST match with the resource request. If a field does not match, the request SHOULD be denied.
所有AUTH_会话字段必须与资源请求匹配。如果字段不匹配，则应拒绝请求。
1. Generate the AUTH_SESSION policy element with the appropriate contents as specified in section 5.
1. 生成具有第5节中指定的适当内容的AUTH_会话策略元素。
2. If authentication is needed, the entire AUTH_SESSION policy element is constructed, excluding the length, type and subtype fields of the AUTH_SESSION field. Note that the message MUST include either a START_TIME or a SESSION_ID (See Section 9), to prevent replay attacks. The output of the authentication algorithm, plus appropriate header information, is appended to the AUTH_SESSION policy element.
2. 如果需要身份验证，将构造整个AUTH_会话策略元素，不包括AUTH_会话字段的长度、类型和子类型字段。请注意，消息必须包含开始时间或会话ID（请参阅第9节），以防止重播攻击。身份验证算法的输出以及适当的头信息被附加到AUTH_会话策略元素。
An RSVP message is created as specified in [RFC-2205] with the following modifications.
按照[RFC-2205]中的规定创建RSVP消息，并进行以下修改。
1. RSVP message MUST contain at most one AUTH_SESSION policy element.
1. RSVP消息最多必须包含一个AUTH_会话策略元素。
2. The AUTH SESSION policy element received from the authorizing entity (Section 3.2) MUST be copied without modification into the POLICY DATA object.
2. 必须将从授权实体（第3.2节）收到的身份验证会话策略元素复制到策略数据对象中，无需修改。
3. POLICY_DATA object (containing the AUTH_SESSION policy element) is inserted in the RSVP message in the appropriate place.
3. 策略数据对象（包含AUTH_会话策略元素）插入RSVP消息中的适当位置。
RSVP message is processed as specified in [RFC-2205] with following modifications.
RSVP消息按照[RFC-2205]中的规定进行处理，并进行以下修改。
1. If router is 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_SESSION policy element. Check the PE type field and return an error if the identity type is not supported.
1. 检索AUTH_会话策略元素。检查PE类型字段，如果不支持标识类型，则返回错误。
2. Verify the message integrity.
2. 验证消息的完整性。
- Shared symmetric key authentication: The Network router/PDP uses the AUTH_ENT_ID field to consult a table keyed by that field. The table should identify the cryptographic authentication algorithm to be used along with the expected length of the authentication data and the shared symmetric key for the authorizing entity. Verify that the indicated length of the authentication data is consistent with the configured table entry and validate the authentication data.
- 共享对称密钥身份验证：网络路由器/PDP使用“身份验证ID”字段来查询由该字段设置密钥的表。该表应确定要使用的加密身份验证算法以及授权实体的身份验证数据的预期长度和共享对称密钥。验证所指示的身份验证数据长度是否与配置的表条目一致，并验证身份验证数据。
- Public Key: Validate the certificate chain against the trusted Certificate Authority (CA) and validate the message signature using the public key.
- 公钥：根据可信证书颁发机构（CA）验证证书链，并使用公钥验证消息签名。
- Kerberos Ticket: If the AUTH_ENT_ID is of subtype KRB_PRINCIPAL, Request a ticket for the authorizing entity (principal@realm) from the local KDC. Use the ticket to access the authorizing entity and obtain authentication data for the message.
- Kerberos票证：如果身份验证ID为子类型KRB_PRINCIPAL，请为授权实体请求票证(principal@realm)来自本地KDC。使用票据访问授权实体并获取消息的身份验证数据。
3. Once the identity of the authorizing entity and the validity of the service request has been established, the authorizing router/PDP MUST then consult its local policy tables (the contents of which are a local matter) in order to determine whether or not the specific request is authorized. To the extent to which these access control decisions require supplementary information, routers/PDPs MUST ensure that supplementary information is obtained securely. An example of insecure access control decisions would be if the authorizing party relies upon an insecure database (such as DNS or a public LDAP directory) and authorizes with a certificate or an FQDN.
3. 一旦建立了授权实体的身份和服务请求的有效性，授权路由器/PDP必须随后查阅其本地策略表（其内容是本地事务），以确定特定请求是否被授权。如果这些访问控制决策需要补充信息，路由器/PDP必须确保安全获取补充信息。不安全访问控制决策的一个示例是授权方依赖于不安全的数据库（如DNS或公共LDAP目录）并使用证书或FQDN进行授权。
4. Verify the requested resources do not exceed the authorized QoS.
4. 验证请求的资源未超过授权的QoS。
If a PDP fails to verify the AUTH_SESSION policy element then it MUST return a policy control failure (Error Code = 02) to the PEP. The error values are described in [RFC-2205] and [RFC-2750]. Also the 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 [RFC-3182]. If RSVP is being used, the PEP MUST include this Policy Data object in the outgoing RSVP Error message.
如果PDP未能验证AUTH_会话策略元素，则必须向PEP返回策略控制失败（错误代码=02）。[RFC-2205]和[RFC-2750]中描述了误差值。此外，PDP还应提供一个策略数据对象，该对象包含一个具有a-Type=policy\u ERROR\u代码的AUTH\u数据策略元素，该代码包含有关策略控制失败的更多详细信息[RFC-3182]。如果正在使用RSVP，PEP必须在传出的RSVP错误消息中包含此策略数据对象。
Following the policies outlined in [IANA-CONSIDERATIONS], Standard RSVP Policy Elements (P-type values) are assigned by IETF Consensus action as described in [RFC-2750].
按照[IANA-注意事项]中概述的政策，标准RSVP政策元素（P型值）由IETF协商一致行动分配，如[RFC-2750]中所述。
P-Type AUTH_SESSION is assigned the value 0x04.
P-Type AUTH_会话被分配值0x04。
Following the policies outlined in [IANA-CONSIDERATIONS], session authorization attribute types (X-Type)in the range 0-127 are allocated through an IETF Consensus action; X-Type values between 128-255 are reserved for Private Use and are not assigned by IANA.
按照[IANA-注意事项]中概述的策略，通过IETF一致行动分配0-127范围内的会话授权属性类型（X-类型）；128-255之间的X-Type值保留供私人使用，不由IANA分配。
X-Type AUTH_ENT_ID is assigned the value 1. X-Type SESSION_ID is assigned the value 2. X-Type SOURCE_ADDR is assigned the value 3. X-Type DEST_ADDR is assigned the value 4. X-Type START_TIME is assigned the value 5. X-Type END_TIME is assigned the value 6. X-Type RESOURCES is assigned the value 7. X-Type AUTHENTICATION_DATA is assigned the value 8.
X型身份验证ID的值为1。X-Type会话_ID的值为2。X-Type SOURCE_ADDR的值为3。X-Type DEST_ADDR的值为4。X型开始时间的值为5。X型结束时间的值为6。X-Type资源的值为7。X-Type认证_数据被赋值为8。
Following the policies outlined in [IANA-CONSIDERATIONS], AUTH_ENT_ID SubType values in the range 0-127 are allocated through an IETF Consensus action; SubType values between 128-255 are reserved for Private Use and are not assigned by IANA.
按照[IANA-注意事项]中概述的政策，通过IETF一致行动分配范围为0-127的认证ID子类型值；128-255之间的子类型值保留供私人使用，不由IANA分配。
AUTH_ENT_ID SubType IPV4_ADDRESS is assigned the value 1. SubType IPV6_ADDRESS is assigned the value 2. SubType FQDN is assigned the value 3. SubType ASCII_DN is assigned the value 4. SubType UNICODE_DN is assigned the value 5. SubType URI is assigned the value 6. SubType KRB_PRINCIPAL is assigned the value 7. SubType X509_V3_CERT is assigned the value 8. SubType PGP_CERT is assigned the value 9.
身份验证ID子类型IPV4地址的值为1。子类型IPV6_地址的值为2。子类型FQDN的值为3。子类型ASCII_DN的值为4。子类型UNICODE_DN的值为5。子类型URI的值为6。子类型KRB_PRINCIPAL的值为7。子类型X509_V3_CERT的值为8。子类型PGP_CERT的值为9。
Following the policies outlined in [IANA-CONSIDERATIONS], SOURCE_ADDR SubType values in the range 0-127 are allocated through an IETF Consensus action; SubType values between 128-255 are reserved for Private Use and are not assigned by IANA.
按照[IANA-注意事项]中概述的政策，通过IETF一致行动分配0-127范围内的源地址子类型值；128-255之间的子类型值保留供私人使用，不由IANA分配。
SOURCE_ADDR SubType IPV4_ADDRESS is assigned the value 1. SubType IPV6_ADDRESS is assigned the value 2. SubType UDP_PORT_LIST is assigned the value 3. SubType TCP_PORT_LIST is assigned the value 4.
源地址子类型IPV4地址的值为1。子类型IPV6_地址的值为2。子类型UDP_端口_列表的值为3。子类型TCP_端口_列表的值为4。
Following the policies outlined in [IANA-CONSIDERATIONS], DEST_ADDR SubType values in the range 0-127 are allocated through an IETF Consensus action; SubType values between 128-255 are reserved for Private Use and are not assigned by IANA.
按照[IANA-注意事项]中概述的政策，通过IETF一致行动分配0-127范围内的DEST_ADDR子类型值；128-255之间的子类型值保留供私人使用，不由IANA分配。
DEST_ADDR SubType IPV4_ADDRESS is assigned the value 1. SubType IPV6_ADDRESS is assigned the value 2. SubType UDP_PORT_LIST is assigned the value 3. SubType TCP_PORT_LIST is assigned the value 4.
DEST_ADDR子类型IPV4_地址的值为1。子类型IPV6_地址的值为2。子类型UDP_端口_列表的值为3。子类型TCP_端口_列表的值为4。
Following the policies outlined in [IANA-CONSIDERATIONS], START_TIME SubType values in the range 0-127 are allocated through an IETF Consensus action; SubType values between 128-255 are reserved for Private Use and are not assigned by IANA.
按照[IANA-注意事项]中概述的政策，通过IETF一致行动分配0-127范围内的开始时间子类型值；128-255之间的子类型值保留供私人使用，不由IANA分配。
START_TIME SubType NTP_TIMESTAMP is assigned the value 1.
开始时间子类型NTP\U TIMESTAMP的值为1。
Following the policies outlined in [IANA-CONSIDERATIONS], END_TIME SubType values in the range 0-127 are allocated through an IETF Consensus action; SubType values between 128-255 are reserved for Private Use and are not assigned by IANA.
按照[IANA-注意事项]中概述的政策，通过IETF共识行动分配0-127范围内的结束时间子类型值；128-255之间的子类型值保留供私人使用，不由IANA分配。
END_TIME SubType NTP_TIMESTAMP is assigned the value 1.
结束时间子类型NTP\U TIMESTAMP的值为1。
Following the policies outlined in [IANA-CONSIDERATIONS], RESOURCES SubType values in the range 0-127 are allocated through an IETF Consensus action; SubType values between 128-255 are reserved for Private Use and are not assigned by IANA.
按照[IANA-注意事项]中概述的政策，通过IETF共识行动分配0-127范围内的资源子类型值；128-255之间的子类型值保留供私人使用，不由IANA分配。
RESOURCES SubType BANDWIDTH is assigned the value 1. SubType FLOW_SPEC is assigned the value 2. SubType SDP is assigned the value 3. SubType DSCP is assigned the value 4.
资源子类型带宽的值为1。子类型FLOW_SPEC的值为2。子类型SDP的值为3。子类型DSCP的值为4。
The purpose of this document is to describe a mechanism for session authorization to prevent theft of service.
本文档旨在描述一种会话授权机制，以防止服务被盗。
Replay attacks MUST be prevented. In the non-associated model, the AUTH_SESSION policy element MUST include a START_TIME field and the Policy Servers MUST support NTP to ensure proper clock synchronization. Failure to ensure proper clock synchronization will allow replay attacks since the clocks of the different network entities may not be in-synch. The start time is used to verify that the request is not being replayed at a later time. In all other models, the SESSION_ID is used by the Policy Server to ensure that the resource request successfully correlates with records of an authorized session. If a AUTH_SESSION is replayed, it MUST be detected by the policy server (using internal algorithms) and the request MUST be rejected.
必须防止重播攻击。在非关联模型中，AUTH_会话策略元素必须包含开始时间字段，策略服务器必须支持NTP以确保正确的时钟同步。由于不同网络实体的时钟可能不同步，未能确保正确的时钟同步将允许重播攻击。开始时间用于验证请求是否在以后的时间重播。在所有其他模型中，策略服务器使用会话ID来确保资源请求与授权会话的记录成功关联。如果要重播AUTH_会话，则策略服务器必须检测到该会话（使用内部算法），并且必须拒绝该请求。
To ensure that the integrity of the policy element is preserved in untrusted environments, the AUTHENTICATION_DATA attribute MUST be included.
为确保在不受信任的环境中保留策略元素的完整性，必须包括“身份验证”数据属性。
In environments where shared symmetric keys are possible, they should be used in order to keep the AUTH_SESSION policy element size to a strict minimum. This is especially true in wireless environments where the AUTH_SESSION policy element is sent over-the-air. The shared symmetric keys authentication option MUST be supported by all AUTH_SESSION implementations.
在可以使用共享对称密钥的环境中，应该使用这些密钥，以便将AUTH_会话策略元素的大小保持在严格的最小值。这在无线环境中尤其如此，在无线环境中，AUTH_会话策略元素通过空中发送。所有身份验证会话实现都必须支持共享对称密钥身份验证选项。
If shared symmetric keys are not a valid option, the Kerberos authentication mechanism is reasonably well secured and efficient in terms of AUTH_SESSION size. The AUTH_SESSION only needs to contain the principal@realm name of the authorizing entity. This is much more efficient than the PKI authentication option.
如果共享对称密钥不是有效的选项，那么Kerberos身份验证机制在身份验证会话大小方面是相当安全和高效的。AUTH_会话只需要包含principal@realm授权实体的名称。这比PKI身份验证选项更有效。
PKI authentication option provides a high level of security and good scalability, however it requires the presence of credentials in the AUTH_SESSION policy element which impacts its size.
PKI身份验证选项提供了高级别的安全性和良好的可扩展性，但是它要求在AUTH_会话策略元素中存在凭据，这会影响其大小。
We would like to thank Francois Audet, Don Wade, Hamid Syed, Kwok Ho Chan and many others for their valuable comments. Special thanks to Eric Rescorla who provided numerous comments and suggestions that improved this document.
我们要感谢弗朗索瓦·奥德特、唐·韦德、哈米德·赛义德、郭浩灿和许多其他人的宝贵意见。特别感谢Eric Rescorla，他提供了许多改进本文件的意见和建议。
In addition, we would like to thank S. Yadav, et al., for their efforts on RFC 3182, as this document borrows from their work.
此外，我们要感谢S.Yadav等人在RFC 3182上的努力，因为本文件借鉴了他们的工作。
[ASCII] Coded Character Set -- 7-Bit American Standard Code for Information Interchange, ANSI X3.4- 1986.
[ASCII]编码字符集——信息交换用7位美国标准代码，ANSI X3.4-1986。
[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
[RFC-1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC-1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC-1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation, and Analysis", RFC 1305, March 1992.
[RFC-1305]Mills，D.，“网络时间协议（第3版）规范、实施和分析”，RFC 1305，1992年3月。
[RFC-1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC-1321]Rivest，R.，“MD5消息摘要算法”，RFC 13211992年4月。
[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-2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC-2104]Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC-2205] Braden, R., Ed., 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.，Ed.，Zhang，L.，Berson，S.，Herzog，S.和S.Jamin，“资源预留协议（RSVP）-第1版功能规范”，RFC 22052997年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月。
[RFC-2253] Wahl, M., Kille, S. and T. Howes , "UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997.
[RFC-2253]Wahl，M.，Kille，S.和T.Howes，“可分辨名称的UTF-8字符串表示法”，RFC 2253，1997年12月。
[RFC-2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[RFC-2279]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，RFC 2279，1998年1月。
[RFC-2327] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, October 1998.
[RFC-2327]Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年10月。
[RFC-2396] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[RFC-2396]Berners Lee，T.，Fielding，R.，Masinter，L.，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
[RFC-2440] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
[RFC-2440]Callas，J.，Donnerhacke，L.，Finney，H.和R.Thayer，“OpenPGP消息格式”，RFC 2440，1998年11月。
[RFC-2474] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC-2474]Nichols，K.，Blake，S.，Baker，F.和D.Black，“IPv4和IPv6标头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[RFC-2750] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[RFC-2750]Herzog，S.，“策略控制的RSVP扩展”，RFC 2750，2000年1月。
[RFC-2753] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy-based Admission Control RSVP", RFC 2753, January 2000.
[RFC-2753]Yavatkar，R.，Pendarakis，D.和R.Guerin，“基于政策的准入控制RSVP框架”，RFC 2753，2000年1月。
[RFC-3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., Herzog, S. and R. Hess, "Identity Representation for RSVP", RFC 3182, October 2001
[RFC-3182]Yadav，S.，Yavatkar，R.，Pabbati，R.，Ford，P.，Moore，T.，Herzog，S.和R.Hess，“RSVP的身份表示”，RFC 31822001年10月
[RFC-3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC-3280]Housley，R.，Polk，W.，Ford，W.和D.Solo，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）概要”，RFC 3280，2002年4月。
[RFC-3369] Housley, R., "Cryptographic Message Syntax", RFC 3369, August 2002.
[RFC-3369]Housley，R.，“加密消息语法”，RFC 3369，2002年8月。
[RFC-3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RFC-3447]Jonsson，J.和B.Kaliski，“公钥密码标准（PKCS）#1:RSA密码规范版本2.1”，RFC 3447，2003年2月。
[RFC-3521] Hamer, L.-N., Gage, B. and H. Shieh, "Framework for Session Setup with Media Authorization", RFC 3521, April 2003.
[RFC-3521]Hamer，L.-N.，Gage，B.和H.Shieh，“媒体授权会话设置框架”，RFC 3521，2003年4月。
[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月。
[RFC-3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC-3261]罗森伯格，J.，舒尔兹林内，H.，卡马里洛，G.，约翰斯顿，A.，彼得森，J.，斯帕克斯，R.，汉德利，M.和E.斯库勒，“SIP：会话启动协议”，RFC 3261，2002年6月。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
Matt Broda Nortel Networks
马特布罗达北电网络公司
EMail: mbroda@nortelnetworks.com
EMail: mbroda@nortelnetworks.com
Louis LeVay Nortel Networks
路易莱维北电网络公司
EMail: levay@nortelnetworks.com
EMail: levay@nortelnetworks.com
Dennis Beard Nortel Networks
丹尼斯·比尔德北电网络公司
EMail: beardd@nortelnetworks.com
EMail: beardd@nortelnetworks.com
Lawrence Dobranski Nortel Networks
劳伦斯·多布兰斯基北电网络公司
EMail: ldobran@nortelnetworks.com
EMail: ldobran@nortelnetworks.com
Louis-Nicolas Hamer Nortel Networks PO Box 3511 Station C Ottawa, Ontario Canada K1Y 4H7
Louis Nicolas Hamer Nortel Networks邮政信箱3511加拿大安大略省渥太华C站K1Y 4H7
Phone: +1 613.768.3409
EMail: nhamer@nortelnetworks.com
Phone: +1 613.768.3409
EMail: nhamer@nortelnetworks.com
Brett Kosinski Invidi Technologies Edmonton, Alberta Canada T5J 3S4
Brett Kosinski Invidi Technologies加拿大阿尔伯塔省埃德蒙顿T5J 3S4
EMail: brettk@invidi.com
EMail: brettk@invidi.com
Bill Gage Nortel Networks PO Box 3511 Station C Ottawa, Ontario Canada K1Y 4H7
Bill Gage Nortel Networks邮政信箱3511加拿大安大略省渥太华C站K1Y 4H7
Phone: +1 613.763.4400
EMail: gageb@nortelnetworks.com
Phone: +1 613.763.4400
EMail: gageb@nortelnetworks.com
Hugh Shieh AT&T Wireless 7277 164th Avenue NE Redmond, WA USA 98073-9761
休谢AT&T无线7277美国西澳州雷德蒙东北大街164号，邮编：98073-9761
Phone: +1 425.580.6898
EMail: hugh.shieh@attws.com
Phone: +1 425.580.6898
EMail: hugh.shieh@attws.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
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编辑功能的资金目前由互联网协会提供。