Internet Engineering Task Force (IETF) J. Manner
Request for Comments: 5981 Aalto University
Category: Experimental M. Stiemerling
ISSN: 2070-1721 NEC
H. Tschofenig
Nokia Siemens Networks
R. Bless, Ed.
KIT
February 2011
Internet Engineering Task Force (IETF) J. Manner
Request for Comments: 5981 Aalto University
Category: Experimental M. Stiemerling
ISSN: 2070-1721 NEC
H. Tschofenig
Nokia Siemens Networks
R. Bless, Ed.
KIT
February 2011
Authorization for NSIS Signaling Layer Protocols
NSIS信令层协议的授权
Abstract
摘要
Signaling layer protocols specified within the Next Steps in Signaling (NSIS) framework may rely on the General Internet Signaling Transport (GIST) protocol to handle authorization. Still, the signaling layer protocol above GIST itself may require separate authorization to be performed when a node receives a request for a certain kind of service or resources. This document presents a generic model and object formats for session authorization within the NSIS signaling layer protocols. 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 coordinate actions between the signaling and transport planes.
在信令（NSIS）框架的下一步骤中指定的信令层协议可以依赖于通用因特网信令传输（GIST）协议来处理授权。然而，当节点接收到对某种服务或资源的请求时，GIST之上的信令层协议本身可能需要执行单独的授权。本文档介绍了NSIS信令层协议中会话授权的通用模型和对象格式。会话授权的目标是允许网元之间的信息交换，以便授权服务资源的使用，并协调信令平面和传输平面之间的操作。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5981.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5981.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Session Authorization Object . . . . . . . . . . . . . . . . . 4
3.1. Session Authorization Object format . . . . . . . . . . . 5
3.2. Session Authorization Attributes . . . . . . . . . . . . . 6
3.2.1. Authorizing Entity Identifier . . . . . . . . . . . . 7
3.2.2. Session Identifier . . . . . . . . . . . . . . . . . . 9
3.2.3. Source Address . . . . . . . . . . . . . . . . . . . . 9
3.2.4. Destination Address . . . . . . . . . . . . . . . . . 11
3.2.5. Start Time . . . . . . . . . . . . . . . . . . . . . . 12
3.2.6. End Time . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.7. NSLP Object List . . . . . . . . . . . . . . . . . . . 13
3.2.8. Authentication Data . . . . . . . . . . . . . . . . . 15
4. Integrity of the SESSION_AUTH Object . . . . . . . . . . . . . 15
4.1. Shared Symmetric Keys . . . . . . . . . . . . . . . . . . 15
4.1.1. Operational Setting Using Shared Symmetric Keys . . . 16
4.2. Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3. Public Key . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3.1. Operational Setting for Public-Key-Based
Authentication . . . . . . . . . . . . . . . . . . . . 19
4.4. HMAC Signed . . . . . . . . . . . . . . . . . . . . . . . 21
5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.1. The Coupled Model . . . . . . . . . . . . . . . . . . . . 23
5.2. The Associated Model with One Policy Server . . . . . . . 23
5.3. The Associated Model with Two Policy Servers . . . . . . . 24
5.4. The Non-Associated Model . . . . . . . . . . . . . . . . . 24
6. Message Processing Rules . . . . . . . . . . . . . . . . . . . 25
6.1. Generation of the SESSION_AUTH by an Authorizing Entity . 25
6.2. Processing within the QoS NSLP . . . . . . . . . . . . . . 25
6.2.1. Message Generation . . . . . . . . . . . . . . . . . . 25
6.2.2. Message Reception . . . . . . . . . . . . . . . . . . 26
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Session Authorization Object . . . . . . . . . . . . . . . . . 4
3.1. Session Authorization Object format . . . . . . . . . . . 5
3.2. Session Authorization Attributes . . . . . . . . . . . . . 6
3.2.1. Authorizing Entity Identifier . . . . . . . . . . . . 7
3.2.2. Session Identifier . . . . . . . . . . . . . . . . . . 9
3.2.3. Source Address . . . . . . . . . . . . . . . . . . . . 9
3.2.4. Destination Address . . . . . . . . . . . . . . . . . 11
3.2.5. Start Time . . . . . . . . . . . . . . . . . . . . . . 12
3.2.6. End Time . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.7. NSLP Object List . . . . . . . . . . . . . . . . . . . 13
3.2.8. Authentication Data . . . . . . . . . . . . . . . . . 15
4. Integrity of the SESSION_AUTH Object . . . . . . . . . . . . . 15
4.1. Shared Symmetric Keys . . . . . . . . . . . . . . . . . . 15
4.1.1. Operational Setting Using Shared Symmetric Keys . . . 16
4.2. Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3. Public Key . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3.1. Operational Setting for Public-Key-Based
Authentication . . . . . . . . . . . . . . . . . . . . 19
4.4. HMAC Signed . . . . . . . . . . . . . . . . . . . . . . . 21
5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.1. The Coupled Model . . . . . . . . . . . . . . . . . . . . 23
5.2. The Associated Model with One Policy Server . . . . . . . 23
5.3. The Associated Model with Two Policy Servers . . . . . . . 24
5.4. The Non-Associated Model . . . . . . . . . . . . . . . . . 24
6. Message Processing Rules . . . . . . . . . . . . . . . . . . . 25
6.1. Generation of the SESSION_AUTH by an Authorizing Entity . 25
6.2. Processing within the QoS NSLP . . . . . . . . . . . . . . 25
6.2.1. Message Generation . . . . . . . . . . . . . . . . . . 25
6.2.2. Message Reception . . . . . . . . . . . . . . . . . . 26
6.2.3. Authorization (QNE or PDP) . . . . . . . . . . . . . . 26
6.2.4. Error Signaling . . . . . . . . . . . . . . . . . . . 27
6.3. Processing with the NATFW NSLP . . . . . . . . . . . . . . 27
6.3.1. Message Generation . . . . . . . . . . . . . . . . . . 28
6.3.2. Message Reception . . . . . . . . . . . . . . . . . . 28
6.3.3. Authorization (Router/PDP) . . . . . . . . . . . . . . 28
6.3.4. Error Signaling . . . . . . . . . . . . . . . . . . . 29
6.4. Integrity Protection of NSLP Messages . . . . . . . . . . 29
7. Security Considerations . . . . . . . . . . . . . . . . . . . 30
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
10.1. Normative References . . . . . . . . . . . . . . . . . . . 34
10.2. Informative References . . . . . . . . . . . . . . . . . . 35
6.2.3. Authorization (QNE or PDP) . . . . . . . . . . . . . . 26
6.2.4. Error Signaling . . . . . . . . . . . . . . . . . . . 27
6.3. Processing with the NATFW NSLP . . . . . . . . . . . . . . 27
6.3.1. Message Generation . . . . . . . . . . . . . . . . . . 28
6.3.2. Message Reception . . . . . . . . . . . . . . . . . . 28
6.3.3. Authorization (Router/PDP) . . . . . . . . . . . . . . 28
6.3.4. Error Signaling . . . . . . . . . . . . . . . . . . . 29
6.4. Integrity Protection of NSLP Messages . . . . . . . . . . 29
7. Security Considerations . . . . . . . . . . . . . . . . . . . 30
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
10.1. Normative References . . . . . . . . . . . . . . . . . . . 34
10.2. Informative References . . . . . . . . . . . . . . . . . . 35
The Next Steps in Signaling (NSIS) framework [RFC4080] defines a suite of protocols for the next generation in Internet signaling. The design is based on a generalized transport protocol for signaling applications, the General Internet Signaling Transport (GIST) [RFC5971], and various kinds of signaling applications. Two signaling applications and their NSIS Signaling Layer Protocol (NSLP) have been designed, a Quality of Service application (QoS NSLP) [RFC5974] and a NAT/firewall application (NATFW NSLP) [RFC5973].
信令的下一步（NSIS）框架[RFC4080]为下一代互联网信令定义了一套协议。该设计基于信令应用的通用传输协议、通用互联网信令传输（GIST）[RFC5971]和各种信令应用。设计了两个信令应用程序及其NSIS信令层协议（NSLP），一个是服务质量应用程序（QoS NSLP）[RFC5974]和一个NAT/防火墙应用程序（NATFW NSLP）[RFC5973]。
The basic security architecture for NSIS is based on a chain-of-trust model, where each GIST hop may choose the appropriate security protocol, taking into account the signaling application requirements. For instance, communication between two directly adjacent GIST peers may be secured via TCP/TLS. On the one hand, this model is appropriate for a number of different use cases and allows the signaling applications to leave the handling of security to GIST. On the other hand, several sessions of different signaling applications are then multiplexed onto the same GIST TLS connection.
NSIS的基本安全架构基于信任链模型，其中每个GIST跳可以选择适当的安全协议，同时考虑信令应用程序的要求。例如，两个直接相邻的GIST对等方之间的通信可以通过TCP/TLS进行保护。一方面，该模型适用于许多不同的用例，并允许信令应用程序将安全性的处理留给GIST。另一方面，不同信令应用的多个会话随后被多路复用到同一GIST-TLS连接上。
Yet, in order to allow for finer-grain per-session or per-user admission control, it is necessary to provide a mechanism for ensuring that the use of resources by a host has been properly authorized before allowing the signaling application to commit the resource request, e.g., a QoS reservation or mappings for NAT traversal. In order to meet this requirement, there must be information in the NSLP message that may be used to verify the validity of the request. This can be done by providing the host with a Session Authorization Object that is inserted into the message and verified by the respective network elements.
然而，为了允许更细粒度的每会话或每用户许可控制，有必要提供一种机制，以确保在允许信令应用提交资源请求（例如，用于NAT遍历的QoS保留或映射）之前主机对资源的使用已被适当授权。为了满足此要求，NSLP消息中必须包含可用于验证请求有效性的信息。这可以通过向主机提供会话授权对象来实现，会话授权对象插入到消息中并由相应的网络元件进行验证。
This document describes a generic NSLP-layer Session Authorization Object (SESSION_AUTH) used to convey authorization information for the request. "Generic" in this context means that it is usable by all NSLPs. The scheme is based on third-party tokens. A trusted third party provides authentication tokens to clients and allows verification of the information by the network elements. The requesting host inserts the authorization information (e.g., a policy object) acquired from the trusted third party into the NSLP message to allow verification of the network resource request. Network elements verify the request and then process it based on admission policy (e.g., they perform a resource reservation or change bindings or firewall filter). This work is based on RFC 3520 [RFC3520] and RFC 3521 [RFC3521].
本文档描述了一个通用NSLP层会话授权对象（Session_AUTH），用于传递请求的授权信息。在此上下文中，“通用”表示所有NSLP都可以使用它。该方案基于第三方令牌。受信任的第三方向客户端提供身份验证令牌，并允许网元验证信息。请求主机将从受信任的第三方获取的授权信息（例如，策略对象）插入NSLP消息中，以允许验证网络资源请求。网络元素验证请求，然后根据许可策略对其进行处理（例如，它们执行资源保留或更改绑定或防火墙过滤器）。这项工作基于RFC 3520[RFC3520]和RFC 3521[RFC3521]。
The default operation when using NSLP-layer session authorization is to add one authorization policy object. Yet, in order to support end-to-end signaling and request authorization from different networks, a host initiating an NSLP signaling session may add more than one SESSION_AUTH object in the message. The identifier of the authorizing entity can be used by the network elements to use the third party they trust to verify the request.
使用NSLP层会话授权时的默认操作是添加一个授权策略对象。然而，为了支持端到端信令和从不同网络请求授权，发起NSLP信令会话的主机可以在消息中添加多个会话认证对象。网络元件可以使用授权实体的标识符来使用其信任的第三方来验证请求。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。
The term "NSLP node" (NN) is used to refer to an NSIS node running an NSLP protocol that can make use of the authorization object discussed in this document. Currently, this node would run either the QoS NSLP [RFC5974] or the NAT/Firewall NSLP [RFC5973] service.
术语“NSLP节点”（NN）用于指运行NSLP协议的NSIS节点，该协议可利用本文档中讨论的授权对象。当前，此节点将运行QoS NSLP[RFC5974]或NAT/防火墙NSLP[RFC5973]服务。
This section presents a new NSLP-layer object called session authorization (SESSION_AUTH). The SESSION_AUTH object can be used in the currently specified and future NSLP protocols.
本节介绍一个称为会话授权（session_AUTH）的新NSLP层对象。SESSION_AUTH对象可以在当前指定的和将来的NSLP协议中使用。
The authorization attributes follow the format and specification given in RFC3520 [RFC3520].
授权属性遵循RFC3520[RFC3520]中给出的格式和规范。
The SESSION_AUTH object contains a list of fields that describe the session, along with other attributes. The object header follows the generic NSLP object header; therefore, it can be used together with any NSLP.
SESSION_AUTH对象包含描述会话的字段列表以及其他属性。对象标头遵循通用NSLP对象标头；因此，它可以与任何NSLP一起使用。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|B|r|r| Type |r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +
// Session Authorization Attribute List //
+ +
+---------------------------------------------------------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|B|r|r| Type |r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +
// Session Authorization Attribute List //
+ +
+---------------------------------------------------------------+
The value for the Type field comes from shared NSLP object type space. The Length field is given in units of 32-bit words and measures the length of the Value component of the TLV object (i.e., it does not include the standard header).
类型字段的值来自共享NSLP对象类型空间。长度字段以32位字为单位给出，并测量TLV对象的值组件的长度（即，它不包括标准标头）。
The bits marked 'A' and 'B' are extensibility flags and are used to signal the desired treatment for objects whose treatment has not been defined in the protocol specification (i.e., whose Type field is unknown at the receiver). The following four categories of object have been identified, and are described here for informational purposes only (for normative behavior, refer to the particular NSLP documents, e.g., [RFC5974] [RFC5973]).
标记为“A”和“B”的位是可扩展性标志，用于向协议规范中未定义其处理的对象（即，其类型字段在接收器处未知）发出所需处理的信号。已确定以下四类对象，此处所述对象仅供参考（对于规范行为，请参考特定NSLP文件，例如[RFC5974][RFC5973]）。
AB=00 ("Mandatory"): If the object is not understood, the entire message containing it MUST be rejected, and an error message sent back (usually of class/code "Protocol Error/Unknown object present").
AB=00（“必需”）：如果对象不被理解，则必须拒绝包含该对象的整个消息，并返回一条错误消息（通常为类/代码“协议错误/存在未知对象”）。
AB=01 ("Ignore"): If the object is not understood, it MUST be deleted, and the rest of the message processed as usual.
AB=01（“忽略”）：如果对象不被理解，则必须将其删除，并按常规处理消息的其余部分。
AB=10 ("Forward"): If the object is not understood, it MUST be retained unchanged in any message forwarded as a result of message processing, but not stored locally.
AB=10（“转发”）：如果对象不被理解，则必须将其作为消息处理的结果保留在转发的任何消息中，而不是存储在本地。
AB=11 ("Refresh"): If the object is not understood, it should be incorporated into the locally stored signaling application state for this flow/session, forwarded in any resulting message, and also used in any refresh or repair message which is generated locally. This flag combination is not used by all NSLPs, e.g., it is not used in the NATFW NSLP.
AB=11（“刷新”）：如果不理解该对象，则应将其合并到此流/会话的本地存储信令应用程序状态中，在任何结果消息中转发，并在本地生成的任何刷新或修复消息中使用。并非所有NSLP都使用此标志组合，例如，NATFW NSLP中未使用此标志组合。
The remaining bits marked 'r' are reserved. The extensibility flags follow the definition in the GIST specification. The SESSION_AUTH object defined in this specification MUST have the AB bits set to "10". An NSLP Node (NN) may use the authorization information if it is configured to do so, but may also just skip the object.
标记为“r”的其余位保留。扩展性标志遵循GIST规范中的定义。本规范中定义的SESSION_AUTH对象的AB位必须设置为“10”。如果NSLP节点（NN）配置为使用授权信息，则可以使用授权信息，但也可以跳过对象。
Type: SESSION_AUTH_OBJECT (0x016)
类型：会话验证对象（0x016）
Length: Variable, contains length of session authorization object list in units of 32-bit words.
长度：变量，包含会话授权对象列表的长度，以32位字为单位。
Session Authorization Attribute List: variable length
会话授权属性列表：可变长度
The session authorization attribute list is a collection of objects that describes the session and provides other information necessary to verify resource request (e.g., a resource reservation, binding, or firewall filter change request). An initial set of valid objects is described in Section 3.2.
会话授权属性列表是一组对象，用于描述会话并提供验证资源请求所需的其他信息（例如，资源保留、绑定或防火墙筛选器更改请求）。第3.2节描述了初始有效对象集。
A session authorization attribute may contain a variety of information and has both an attribute type and sub-type. 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个八位字节的边界。所有填充字节的值必须为零。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | X-Type | SubType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Value ... //
+---------------------------------------------------------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | X-Type | SubType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Value ... //
+---------------------------------------------------------------+
Length: 16 bits
长度：16位
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 padding of the value field to make the attribute's length a multiple of 4 octets.
长度字段是两个八位字节，以八位字节数表示属性的实际长度（包括长度、X类型和子类型字段）。长度不包括值字段的任何填充，以使属性的长度为4个八位字节的倍数。
X-Type: 8 bits
X型：8位
Session authorization attribute type (X-Type) field is one octet. IANA acts as a registry for X-Types as described in Section 8, IANA Considerations. This specification uses the following X-Types:
会话授权属性类型（X-type）字段为一个八位字节。IANA充当第8节“IANA注意事项”中所述的X类型注册表。本规范使用以下X型：
1. AUTH_ENT_ID: The unique identifier of the entity that authorized the session.
1. 授权ID：授权会话的实体的唯一标识符。
2. SESSION_ID: The unique identifier for this session, usually created locally at the authorizing entity. See also RFC 3520 [RFC3520]; not to be confused with the SESSION-ID of GIST/ NSIS.
2. 会话ID：此会话的唯一标识符，通常在授权实体本地创建。另见RFC 3520[RFC3520]；不要与GIST/NSIS的会话ID混淆。
3. SOURCE_ADDR: The address specification for the signaling session initiator, i.e., the source address of the signaling message originator.
3. SOURCE_ADDR：信令会话发起方的地址规范，即信令消息发起方的源地址。
4. DEST_ADDR: The address specification for the signaling session endpoint.
4. DEST_ADDR：信令会话端点的地址规范。
5. START_TIME: The starting time for the session.
5. 开始时间：会话的开始时间。
6. END_TIME: The end time for the session.
6. 结束时间：会话的结束时间。
7. AUTHENTICATION_DATA: The authentication data of the Session Authorization Object.
7. 认证\数据：会话授权对象的认证数据。
SubType: 8 bits
子类型：8位
Session authorization attribute sub-type is one octet in length. The value of the SubType depends on the X-Type.
会话授权属性子类型的长度为一个八位字节。子类型的值取决于X类型。
Value: variable length
值：可变长度
The attribute-specific information.
属性特定的信息。
The AUTH_ENT_ID is used to identify the entity that authorized the initial service request and generated the Session Authorization Object. 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的格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | X-Type | SubType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// OctetString ... //
+---------------------------------------------------------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | X-Type | SubType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// OctetString ... //
+---------------------------------------------------------------+
Length: Length of the attribute, which MUST be > 4.
长度：属性的长度，必须大于4。
X-Type: AUTH_ENT_ID
X-Type:身份验证ID
SubType:
子类型：
The following sub-types for AUTH_ENT_ID are defined. IANA acts as a registry for AUTH_ENT_ID SubTypes as described in Section 8, IANA Considerations. Initially, the registry contains the following SubTypes of AUTH_ENT_ID:
定义了身份验证ID的以下子类型。IANA充当身份验证ID子类型的注册表，如第8节“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_地址：以128位表示的IPV6地址。
3. FQDN: Fully Qualified Domain Name as defined in [RFC1034] as an ASCII string.
3. FQDN:[RFC1034]中定义为ASCII字符串的完全限定域名。
4. ASCII_DN: X.500 Distinguished name as defined in [RFC4514] as an ASCII string.
4. ASCII_DN:X.500可分辨名称，如[RFC4514]中定义为ASCII字符串。
5. UNICODE_DN: X.500 Distinguished name as defined in [RFC4514] as a UTF-8 string.
5. UNICODE_DN:X.500可分辨名称，如[RFC4514]中定义为UTF-8字符串。
6. URI: Universal Resource Identifier, as defined in [RFC3986].
6. URI：通用资源标识符，如[RFC3986]中所定义。
7. KRB_PRINCIPAL: Fully Qualified Kerberos Principal name represented by the ASCII string of a principal, followed by the @ realm name as defined in [RFC4120] (e.g., johndoe@nowhere).
7. KRB_PRINCIPAL：完全限定的Kerberos主体名称，由主体的ASCII字符串表示，后跟[RFC4120]中定义的@realm name（例如。，johndoe@nowhere).
8. X509_V3_CERT: The Distinguished Name of the subject of the certificate as defined in [RFC4514] as a UTF-8 string.
8. X509_V3_CERT:[RFC4514]中定义为UTF-8字符串的证书主题的可分辨名称。
9. PGP_CERT: The OpenPGP certificate of the authorizing entity as defined as Public-Key Packet in [RFC4880].
9. PGP_证书：授权实体的OpenPGP证书，定义为[RFC4880]中的公钥包。
10. HMAC_SIGNED: Indicates that the AUTHENTICATION_DATA attribute contains a self-signed HMAC signature [RFC2104] that ensures the integrity of the NSLP message. The HMAC is calculated over all NSLP objects given in the NSLP_OBJECT_LIST attribute that MUST also be present. The object specifies the hash algorithm that is used for calculation of the HMAC as Transform ID from Transform Type 3 of the IKEv2 registry [RFC5996].
10. HMAC_SIGNED：表示AUTHENTICATION_数据属性包含自签名HMAC签名[RFC2104]，以确保NSLP消息的完整性。HMAC在NSLP_OBJECT_LIST属性中给出的所有NSLP对象上计算，该属性也必须存在。该对象指定用于从IKEv2注册表[RFC5996]的转换类型3计算HMAC作为转换ID的哈希算法。
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时间戳。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | X-Type | SubType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// OctetString ... //
+---------------------------------------------------------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | X-Type | SubType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// OctetString ... //
+---------------------------------------------------------------+
Length: Length of the attribute, which MUST be > 4.
长度：属性的长度，必须大于4。
X-Type: SESSION_ID
X-Type:会话\u ID
SubType:
子类型：
No sub-types 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的子类型；此字段必须设置为零。授权实体是唯一需要解释会话标识内容的网络实体；因此，内容和格式取决于实现。
OctetString: The OctetString contains the session identifier.
OctetString：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. Usually, it corresponds to the signaling source, e.g., the IP source address of the GIST packet, or flow source or flow destination address, respectively, which are contained in the GIST MRI (Message Routing Information) object.
SOURCE_ADDR用于标识授权会话的源地址规范。在某些情况下，此X-Type可能非常有用，可以确保资源请求已被授权用于特定的源地址和/或端口。通常，它对应于信令源，例如GIST分组的IP源地址，或者分别对应于包含在GIST MRI（消息路由信息）对象中的流源或流目的地地址。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | X-Type | SubType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// OctetString ... //
+---------------------------------------------------------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 SubTypes as described in Section 8, IANA Considerations. Initially, the registry contains the following SubTypes for SOURCE_ADDR:
定义了源地址的以下子类型。IANA作为源地址子类型的注册表，如第8节“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_地址：以128位表示的IPV6地址。
3. UDP_PORT_LIST: list of UDP port specifications, represented as 16 bits per list entry.
3. UDP_端口_列表：UDP端口规范的列表，表示为每个列表项16位。
4. TCP_PORT_LIST: list of TCP port specifications, represented as 16 bits per list entry.
4. TCP_端口_列表：TCP端口规范列表，表示为每个列表项16位。
5. SPI: Security Parameter Index, represented in 32 bits.
5. SPI：安全参数索引，以32位表示。
OctetString: The OctetString contains the source address information.
八进制字符串：八进制字符串包含源地址信息。
In scenarios where a source address is required (see Section 5), at least one of the sub-types 1 or 2 MUST be included in every Session Authorization Object. Multiple SOURCE_ADDR attributes MAY be included if multiple addresses have been authorized. The source address of the request (e.g., a QoS NSLP RESERVE) MUST match one of the SOURCE_ADDR attributes contained in this Session Authorization Object.
在需要源地址的场景中（参见第5节），每个会话授权对象中必须至少包含子类型1或2中的一个。如果已授权多个地址，则可能包括多个源地址属性。请求的源地址（例如，QoS NSLP保留）必须与此会话授权对象中包含的源地址属性之一匹配。
At most, one instance of sub-type 3 MAY be included in every Session Authorization Object. At most, one instance of sub-type 4 MAY be included in every Session Authorization Object. Inclusion of a sub-type 3 attribute does not prevent inclusion of a sub-type 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可能很有用，可以确保资源请求已被授权用于特定的目标地址和/或端口。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | X-Type | SubType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// OctetString ... //
+---------------------------------------------------------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | X-Type | SubType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// OctetString ... //
+---------------------------------------------------------------+
Length: Length of the attribute in number of octets, 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 SubTypes as described in Section 8, IANA Considerations. Initially, the registry contains the following SubTypes for DEST_ADDR:
定义了DEST_ADDR的以下子类型。IANA作为DEST_ADDR子类型的注册表，如第8节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_地址：以128位表示的IPV6地址。
3. UDP_PORT_LIST: list of UDP port specifications, represented as 16 bits per list entry.
3. UDP_端口_列表：UDP端口规范的列表，表示为每个列表项16位。
4. TCP_PORT_LIST: list of TCP port specifications, represented as 16 bits per list entry.
4. TCP_端口_列表：TCP端口规范列表，表示为每个列表项16位。
5. SPI: Security Parameter Index, represented in 32 bits.
5. SPI：安全参数索引，以32位表示。
OctetString: The OctetString contains the destination address specification.
八进制字符串：八进制字符串包含目标地址规范。
In scenarios where a destination address is required (see Section 5), at least one of the sub-types 1 or 2 MUST be included in every Session Authorization Object. Multiple DEST_ADDR attributes MAY be included if multiple addresses have been authorized. The destination
在需要目标地址的场景中（参见第5节），每个会话授权对象中必须至少包含一个子类型1或2。如果已授权多个地址，则可能包括多个DEST_ADDR属性。目的地
address field of the resource reservation datagram (e.g., QoS NSLP Reserve) MUST match one of the DEST_ADDR attributes contained in this Session Authorization Object.
资源预留数据报的地址字段（例如QoS NSLP Reserve）必须与此会话授权对象中包含的DEST_ADDR属性之一匹配。
At most, one instance of sub-type 3 MAY be included in every Session Authorization Object. At most, one instance of sub-type 4 MAY be included in every Session Authorization Object. Inclusion of a sub-type 3 attribute does not prevent inclusion of a sub-type 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 SESSION_AUTH object 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对象，则如果在指定的开始时间的几秒钟内未收到请求，则网络应拒绝该请求。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | X-Type | SubType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// OctetString ... //
+---------------------------------------------------------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | X-Type | SubType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// OctetString ... //
+---------------------------------------------------------------+
Length: Length of the attribute, which MUST be > 4.
长度：属性的长度，必须大于4。
X-Type: START_TIME
X-Type:开始时间
SubType:
子类型：
The following sub-type for START_TIME is defined. IANA acts as a registry for START_TIME SubTypes as described in Section 8, IANA Considerations. Initially, the registry contains the following SubType for START_TIME:
定义了以下开始时间的子类型。IANA充当启动时间子类型的注册表，如第8节“IANA注意事项”所述。最初，注册表包含启动时间的以下子类型：
1 NTP_TIMESTAMP: NTP Timestamp Format as defined in RFC 5905 [RFC5905].
1 NTP_时间戳：RFC 5905[RFC5905]中定义的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).
结束时间用于确定授权会话的结束时间，并可用于限制授权使用资源的时间量（例如，在预付费会话场景中）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | X-Type | SubType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// OctetString ... //
+---------------------------------------------------------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | X-Type | SubType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// OctetString ... //
+---------------------------------------------------------------+
Length: Length of the attribute, which MUST be > 4.
长度：属性的长度，必须大于4。
X-Type: END_TIME
X型：结束时间
SubType:
子类型：
The following sub-type for END_TIME is defined. IANA acts as a registry for END_TIME SubTypes as described in Section 8, IANA Considerations. Initially, the registry contains the following SubType for END_TIME:
定义了结束时间的以下子类型。IANA充当第8节“IANA注意事项”中所述的结束时间子类型的注册表。最初，注册表包含以下结束时间的子类型：
1 NTP_TIMESTAMP: NTP Timestamp Format as defined in RFC 5905 [RFC5905].
1 NTP_时间戳：RFC 5905[RFC5905]中定义的NTP时间戳格式。
OctetString: The OctetString contains the end time.
八进制字符串：八进制字符串包含结束时间。
The NSLP_OBJECT_LIST attribute contains a list of NSLP object types that are used in the keyed-hash computation whose result is given in the AUTHENTICATION_DATA attribute. This allows for an integrity protection of NSLP PDUs. If an NSLP_OBJECT_LIST attribute has been included in the SESSION_AUTH object, an AUTHENTICATION_DATA attribute MUST also be present.
NSLP_OBJECT_LIST属性包含用于键控哈希计算的NSLP对象类型列表，其结果在AUTHENTICATION_DATA属性中给出。这允许NSLP PDU的完整性保护。如果NSLP_对象_列表属性已包含在会话_身份验证对象中，则还必须存在身份验证_数据属性。
The creator of this attribute lists every NSLP object type whose NSLP PDU object was included in the computation of the hash. The hash computation has to follow the order of the NSLP object types as specified by the list. The receiver can verify the integrity of the NSLP PDU by computing a hash over all NSLP objects that are listed in this attribute (in the given order), including all the attributes of the authorization object. Since all NSLP object types are unique over all different NSLPs, this will work for any NSLP.
此属性的创建者将列出其NSLP PDU对象包含在哈希计算中的每个NSLP对象类型。哈希计算必须遵循列表指定的NSLP对象类型的顺序。接收方可以通过计算该属性中列出的所有NSLP对象（按给定顺序）上的哈希来验证NSLP PDU的完整性，包括授权对象的所有属性。由于所有NSLP对象类型在所有不同的NSLP上都是唯一的，因此这将适用于任何NSLP。
Basic NSIS Transport Layer Protocol (NTLP) / NSLP objects like the session ID, the NSLPID, and the MRI MUST be always included in the HMAC. Since they are not carried within the NSLP itself, but only within GIST, they have to be provided for HMAC calculation, e.g., they can be delivered via the GIST API. They MUST be normalized to their network representation from [RFC5971] again before calculating the hash. These values MUST be hashed first (in the order session ID, NSLPID, MRI), before any other NSLP object values that are included in the hash computation.
基本NSIS传输层协议（NTLP）/NSLP对象（如会话ID、NSLPID和MRI）必须始终包含在HMAC中。由于它们不在NSLP本身中携带，而仅在GIST中携带，因此必须为HMAC计算提供它们，例如，它们可以通过GIST API交付。在计算散列之前，它们必须再次从[RFC5971]标准化为其网络表示形式。在散列计算中包含的任何其他NSLP对象值之前，必须首先散列这些值（按照会话ID、NSLPID、MRI的顺序）。
A summary of the NSLP_OBJECT_LIST attribute format is described below.
NSLP_对象_列表属性格式的摘要如下所述。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Length | NSLP_OBJ_LIST | zero |
+---------------+---------------+-------+-------+---------------+
| # of signed NSLP objects = n | rsv | NSLP object type (1) |
+-------+-------+---------------+-------+-------+---------------+
| rsv | NSLP object type (2) | ..... //
+-------+-------+---------------+---------------+---------------+
| rsv | NSLP object type (n) | (padding if required) |
+--------------+----------------+---------------+---------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Length | NSLP_OBJ_LIST | zero |
+---------------+---------------+-------+-------+---------------+
| # of signed NSLP objects = n | rsv | NSLP object type (1) |
+-------+-------+---------------+-------+-------+---------------+
| rsv | NSLP object type (2) | ..... //
+-------+-------+---------------+---------------+---------------+
| rsv | NSLP object type (n) | (padding if required) |
+--------------+----------------+---------------+---------------+
Length: Length of the attribute, which MUST be > 4.
长度：属性的长度，必须大于4。
X-Type: NSLP_OBJECT_LIST
X-Type:NSLP_对象_列表
SubType: No sub-types for NSLP_OBJECT_LIST are currently defined. This field MUST be set to 0 and ignored upon reception.
子类型：当前未定义NSLP_对象_列表的子类型。此字段必须设置为0，并在接收时忽略。
# of signed NSLP objects: The number n of NSLP object types that follow. n=0 is allowed; in that case, only a padding field is contained.
#已签名NSLP对象数：后面的NSLP对象类型数n。允许n=0；在这种情况下，只包含一个填充字段。
rsv: reserved bits; MUST be set to 0 and ignored upon reception.
rsv：保留位；必须设置为0，并在接收时忽略。
NSLP object type: the NSLP 12-bit object type identifier of the object that was included in the hash calculation. The NSLP object type values comprise only 12 bits, so four bits per type value are currently not used within the list. Depending on the number of signed objects, a corresponding padding word of 16 bits must be supplied.
NSLP对象类型：散列计算中包含的对象的NSLP 12位对象类型标识符。NSLP对象类型值仅包含12位，因此列表中当前未使用每种类型值4位。根据签名对象的数量，必须提供16位的相应填充字。
padding: padding MUST be added if the number of NSLP objects is even and MUST NOT be added if the number of NSLP objects is odd. If padding has to be applied, the padding field MUST be 16 bits set to 0, and its contents MUST be ignored upon reception.
填充：如果NSLP对象数为偶数，则必须添加填充；如果NSLP对象数为奇数，则不得添加填充。如果必须应用填充，则填充字段必须为16位，设置为0，并且在接收时必须忽略其内容。
The AUTHENTICATION_DATA attribute contains the authentication data of the SESSION_AUTH object and signs all the data in the object up to the AUTHENTICATION_DATA. If the AUTHENTICATION_DATA attribute has been included in the SESSION_AUTH object, 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 SESSION_AUTH Object".
“身份验证数据”属性包含会话身份验证对象的身份验证数据，并将对象中的所有数据签名到身份验证数据。如果身份验证数据属性已包含在会话身份验证对象中，则它必须是列表中的最后一个属性。用于计算身份验证数据的算法取决于身份验证ID子类型字段。参见第4节“会话身份验证对象的完整性”。
A summary of the AUTHENTICATION_DATA attribute format is described below.
认证数据属性格式的摘要如下所述。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | X-Type | SubType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// OctetString ... //
+---------------------------------------------------------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | X-Type | SubType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// OctetString ... //
+---------------------------------------------------------------+
Length: Length of the attribute, which MUST be > 4.
长度：属性的长度，必须大于4。
X-Type: AUTHENTICATION_DATA
X-Type:AUTHENTICATION\u数据
SubType: No sub-types for AUTHENTICATION_DATA are currently defined. This field MUST be set to 0 and ignored upon reception.
子类型：当前未定义身份验证数据的子类型。此字段必须设置为0，并在接收时忽略。
OctetString: The OctetString contains the authentication data of the SESSION_AUTH.
OctetString：OctetString包含会话身份验证的身份验证数据。
This section describes how to ensure that the integrity of the SESSION_AUTH object is preserved.
本节介绍如何确保会话_AUTH对象的完整性得到保留。
In shared symmetric key environments, the AUTH_ENT_ID MUST be of sub-types: IPV4_ADDRESS, IPV6_ADDRESS, FQDN, ASCII_DN, UNICODE_DN, or URI. An example SESSION_AUTH object is shown below.
在共享对称密钥环境中，身份验证ID必须是子类型：IPV4地址、IPV6地址、FQDN、ASCII DN、UNICODE DN或URI。下面显示了一个SESSION_AUTH对象示例。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|0|0| Type = SESSION_AUTH |0|0|0|0| Object Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | AUTH_ENT_ID | IPV4_ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OctetString ... (The authorizing entity's Identifier) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | AUTH_DATA | zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OctetString ... (Authentication data) |
+---------------------------------------------------------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|0|0| Type = SESSION_AUTH |0|0|0|0| Object Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | AUTH_ENT_ID | IPV4_ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OctetString ... (The authorizing entity's Identifier) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | AUTH_DATA | zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OctetString ... (Authentication data) |
+---------------------------------------------------------------+
Figure 1: Example of a SESSION_AUTH Object
图1：SESSION_AUTH对象的示例
This assumes both the Authorizing Entity and the network router/PDP (Policy Decision Point) are provisioned with shared symmetric keys, policies detailing which algorithm to be used for computing the authentication data, and the expected length of the authentication data for that particular algorithm.
这假设授权实体和网络路由器/PDP（策略决策点）都提供了共享对称密钥、详细说明用于计算认证数据的算法的策略，以及该特定算法的认证数据的预期长度。
Key maintenance is outside the scope of this document, but SESSION_AUTH implementations MUST at least provide the ability to manually configure keys and their parameters. The key used 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 AUTHENTICATION_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 SESSION_AUTH implementations MUST support the HMAC-SHA2-256 [RFC4868] [RFC2104] cryptographic algorithm for computing the authentication data.
密钥维护不在本文档的范围内，但是会话_AUTH实现必须至少提供手动配置密钥及其参数的能力。用于生成身份验证数据的密钥由“身份验证ID”字段标识。由于可以为特定身份验证ID值配置多个密钥，因此身份验证数据字段的前32位必须是用于标识适当密钥的密钥ID。每个密钥还必须配置有效时间段的生存期参数，以及指定要与密钥一起使用的算法的相关加密算法参数。至少，所有会话验证实现必须支持HMAC-SHA2-256[RFC4868][RFC2104]加密算法来计算验证数据。
It is good practice to regularly change keys. Keys MUST be configurable such that their lifetimes overlap, thereby 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.
定期更换钥匙是一种很好的做法。关键点必须是可配置的，以便它们的生命周期重叠，从而允许关键点之间的平滑过渡。在两个密钥的生命周期重叠的中点，发送者应该从使用当前密钥过渡到下一个/寿命更长的密钥。同时，接收器只接受在其配置的生命周期内接收到的任何已识别密钥，并拒绝未识别的密钥。
Since Kerberos [RFC4120] is widely used for end-user authorization, e.g., in Windows domains, it is well suited for being used in the context of user-based authorization for NSIS sessions. For instance, a user may request a ticket for authorization to install rules in an NATFW-capable router.
由于Kerberos[RFC4120]广泛用于最终用户授权，例如在Windows域中，因此它非常适合在NSIS会话的基于用户的授权上下文中使用。例如，用户可以请求票证以授权在支持NATFW的路由器中安装规则。
In a Kerberos environment, it is assumed that the user of the NSLP requesting host requests a ticket from the Kerberos Key Distribution Center (KDC) for using the NSLP node (router) as a resource (target service). The NSLP requesting host (client) can present the ticket to the NSLP node via Kerberos by sending a KRB_CRED message to the NSLP node independently but prior to the NSLP exchange. Thus, the principal name of the service must be known at the client in advance, though the exact IP address may not be known in advance. How the name is assigned and made available to the client is implementation specific. The extracted common session key can subsequently be used to employ the HMAC_SIGNED variant of the SESSION_AUTH object.
在Kerberos环境中，假定NSLP请求主机的用户从Kerberos密钥分发中心（KDC）请求票证，以将NSLP节点（路由器）用作资源（目标服务）。NSLP请求主机（客户端）可以在NSLP交换之前，通过Kerberos向NSLP节点独立发送KRB_CRED消息，向NSLP节点提供票证。因此，客户机必须提前知道服务的主体名称，尽管可能事先不知道确切的IP地址。如何为客户机分配和提供名称是特定于实现的。提取的公共会话密钥随后可用于使用会话认证对象的HMAC_签名变体。
Another option is to encapsulate the credentials in the AUTHENTICATION_DATA portion of the SESSION_AUTH object. In this case, the AUTH_ENT_ID MUST be of the sub-type KRB_PRINCIPAL. The KRB_PRINCIPAL field is defined as the Fully Qualified Kerberos Principal name of the authorizing entity. The AUTHENTICATION_DATA portion of the SESSION_AUTH object contains the KRB_CRED message that the receiving NSLP node has to extract and verify. A second SESSION_AUTH object of type HMAC_SIGNED SHOULD protect the integrity of the NSLP message, including the prior SESSION_AUTH object. The session key included in the first SESSION_AUTH object has to be used for HMAC calculation.
另一个选项是将凭证封装在会话认证对象的认证数据部分。在这种情况下，身份验证ID必须是子类型KRB_PRINCIPAL。KRB_主体字段定义为授权实体的完全限定Kerberos主体名称。SESSION_AUTH对象的AUTHENTICATION_数据部分包含接收NSLP节点必须提取和验证的KRB_CRED消息。HMAC_SIGNED类型的第二个SESSION_AUTH对象应保护NSLP消息的完整性，包括前一个SESSION_AUTH对象。第一个会话_AUTH对象中包含的会话密钥必须用于HMAC计算。
An example of the Kerberos AUTHENTICATION_DATA object is shown below in Figure 2.
Kerberos身份验证数据对象的示例如图2所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|0|0| Type = SESSION_AUTH |0|0|0|0| Object Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | AUTH_ENT_ID | KERB_P. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OctetString ... (The principal@realm name) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | AUTH_DATA | zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OctetString ... (KRB_CRED Data) |
+---------------------------------------------------------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|0|0| Type = SESSION_AUTH |0|0|0|0| Object Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | AUTH_ENT_ID | KERB_P. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OctetString ... (The principal@realm name) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | AUTH_DATA | zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OctetString ... (KRB_CRED Data) |
+---------------------------------------------------------------+
Figure 2: Example of a Kerberos AUTHENTICATION_DATA Object
图2:Kerberos身份验证数据对象的示例
In a public key environment, the AUTH_ENT_ID MUST be of the sub-types: X509_V3_CERT or PGP_CERT. The authentication data is used for authenticating the authorizing entity. Two examples of the public key SESSION_AUTH object are shown in Figures 3 and 4.
在公钥环境中，身份验证ID必须是子类型：X509\u V3\u CERT或PGP\u CERT。身份验证数据用于验证授权实体。公钥会话_AUTH对象的两个示例如图3和图4所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|0|0| Type = SESSION_AUTH |0|0|0|0| Object Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | AUTH_ENT_ID | PGP_CERT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OctetString ... (Authorizing entity Digital Certificate) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | AUTH_DATA | zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OctetString ... (Authentication data) |
+---------------------------------------------------------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|0|0| Type = SESSION_AUTH |0|0|0|0| Object Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | AUTH_ENT_ID | PGP_CERT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OctetString ... (Authorizing entity Digital Certificate) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | AUTH_DATA | zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OctetString ... (Authentication data) |
+---------------------------------------------------------------+
Figure 3: Example of a SESSION_AUTH_OBJECT Using a PGP Certificate
图3：使用PGP证书的SESSION_AUTH_对象的示例
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|0|0| Type = SESSION_AUTH |0|0|0|0| Object Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | AUTH_ENT_ID | X509_V3_CERT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OctetString ... (Authorizing entity Digital Certificate) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | AUTH_DATA | zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OctetString ... (Authentication data) |
+---------------------------------------------------------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|0|0| Type = SESSION_AUTH |0|0|0|0| Object Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | AUTH_ENT_ID | X509_V3_CERT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OctetString ... (Authorizing entity Digital Certificate) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | AUTH_DATA | zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OctetString ... (Authentication data) |
+---------------------------------------------------------------+
Figure 4: Example of a SESSION_AUTH_OBJECT Using an X509_V3_CERT Certificate
图4：使用X509\u V3\u证书的会话\u身份验证\u对象的示例
Public-key-based authentication assumes the following:
基于公钥的身份验证假设如下：
o Authorizing entities have a pair of keys (private key and public key).
o 授权实体有一对密钥（私钥和公钥）。
o The private key is secured with the authorizing entity.
o 私钥由授权实体保护。
o Public keys are stored in digital certificates; a trusted party, the certificate authority (CA), issues these digital certificates.
o 公钥存储在数字证书中；可信方证书颁发机构（CA）颁发这些数字证书。
o The verifier (PDP or router) has the ability to verify the digital certificate.
o 验证器（PDP或路由器）能够验证数字证书。
The 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 object.
授权实体使用其私钥生成身份验证数据。验证器（路由器、PDP）使用授权实体的公钥（存储在数字证书中）来验证和验证对象。
When the AUTH_ENT_ID is of type X509_V3_CERT, AUTHENTICATION_DATA MUST be generated by the authorizing entity following these steps:
当身份验证ID为X509\u V3\u CERT类型时，授权实体必须按照以下步骤生成身份验证数据：
o A signed-data is constructed as defined in RFC 5652 [RFC5652]. 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 X.509 V3 digital certificates from each authorizing entity. The certificate revocation list is
o 按照RFC 5652[RFC5652]中的定义构造有符号数据。摘要是使用特定于签名者的消息摘要算法对内容（如第6.1节所述）进行计算的。证书字段包含来自每个授权实体的X.509 V3数字证书链。证书吊销列表为
defined in the crls field. The digest output is digitally signed following Section 8 of RFC 3447 [RFC3447], using the signer's private key.
在crls字段中定义。摘要输出根据RFC 3447[RFC3447]第8节使用签名者的私钥进行数字签名。
When the AUTH_ENT_ID is of type X509_V3_CERT, verification at the verifying network element (PDP or router) MUST be done following these steps:
当验证ID为X509\u V3\u CERT类型时，必须按照以下步骤在验证网元（PDP或路由器）上进行验证：
o Parse the X.509 V3 certificate to extract the distinguished name of the issuer of the certificate.
o 解析X.509 V3证书以提取证书颁发者的可分辨名称。
o Certification Path Validation is performed as defined in Section 6 of RFC 5280 [RFC5280].
o 按照RFC 5280[RFC5280]第6节的规定执行认证路径验证。
o Parse through the Certificate Revocation list to verify that the received certificate is not listed.
o 解析证书吊销列表以验证未列出收到的证书。
o Once the X.509 V3 certificate is validated, the public key of the authorizing entity can be extracted from the certificate.
o 验证X.509 V3证书后，可以从证书中提取授权实体的公钥。
o Extract the digest algorithm and the length of the digested data by parsing the CMS (Cryptographic Message Syntax) signed-data.
o 通过解析CMS（加密消息语法）签名数据，提取摘要算法和摘要数据的长度。
o The recipient independently computes the message digest. This message digest and the signer's public key are used to verify the signature value.
o 收件人独立计算邮件摘要。此消息摘要和签名者的公钥用于验证签名值。
This verification ensures integrity, non-repudiation, and data origin.
此验证可确保完整性、不可否认性和数据来源。
When the AUTH_ENT_ID is of type PGP_CERT, AUTHENTICATION_DATA MUST be generated by the authorizing entity following these steps:
当身份验证ID为PGP证书类型时，授权实体必须按照以下步骤生成身份验证数据：
AUTHENTICATION_DATA contains a Signature Packet as defined in Section 5.2.3 of RFC 4880 [RFC4880]. In summary:
认证数据包含RFC 4880[RFC4880]第5.2.3节中定义的签名包。总之：
o Compute the hash of all data in the SESSION_AUTH object up to the AUTHENTICATION_DATA.
o 计算会话_AUTH对象中所有数据直到身份验证_数据的哈希值。
o The hash output is digitally signed following Section 8 of RFC 3447, using the signer's private key.
o 根据RFC 3447第8节，使用签名者的私钥对散列输出进行数字签名。
When the AUTH_ENT_ID is of type PGP_CERT, verification MUST be done by the verifying network element (PDP or router) following these steps:
当验证ID为PGP证书类型时，验证网元（PDP或路由器）必须按照以下步骤进行验证：
o Validate the certificate.
o 验证证书。
o Once the PGP certificate is validated, the public key of the authorizing entity can be extracted from the certificate.
o 验证PGP证书后，可以从证书中提取授权实体的公钥。
o Extract the hash algorithm and the length of the hashed data by parsing the PGP signature packet.
o 通过解析PGP签名包，提取哈希算法和哈希数据的长度。
o The recipient independently computes the message digest. This message digest and the signer's public key are used to verify the signature value.
o 收件人独立计算邮件摘要。此消息摘要和签名者的公钥用于验证签名值。
This verification ensures integrity, non-repudiation, and data origin.
此验证可确保完整性、不可否认性和数据来源。
A SESSION_AUTH object that carries an AUTH_ENT_ID of HMAC_SIGNED is used as integrity protection for NSLP messages. The SESSION_AUTH object MUST contain the following attributes:
带有HMAC_签名的身份验证ID的SESSION_AUTH对象用作NSLP消息的完整性保护。SESSION_AUTH对象必须包含以下属性：
o SOURCE_ADDR: the source address of the entity that created the HMAC
o SOURCE_ADDR：创建HMAC的实体的源地址
o START_TIME: the timestamp when the HMAC signature was calculated. This MUST be different for any two messages in sequence in order to prevent replay attacks. The NTP timestamp currently provides a resolution of 200 picoseconds, which should be sufficient.
o 开始时间：计算HMAC签名时的时间戳。为了防止重播攻击，顺序中的任意两条消息必须不同。NTP时间戳目前提供200皮秒的分辨率，这应该足够了。
o NSLP_OBJECT_LIST: this attribute lists all NSLP objects that are included in HMAC calculation.
o NSLP_对象_列表：此属性列出HMAC计算中包含的所有NSLP对象。
o AUTHENTICATION_DATA: this attribute contains the Key-ID that is used for HMAC calculation as well as the HMAC data itself [RFC2104].
o 身份验证_数据：此属性包含用于HMAC计算的密钥ID以及HMAC数据本身[RFC2104]。
The key used for HMAC calculation must be exchanged securely by some other means, e.g., a Kerberos Ticket or pre-shared manual installation etc. The Key-ID in the AUTHENTICATION_DATA allows the reference to the appropriate key and also to periodically change signing keys within a session. The key length MUST be at least 64 bits, but it is ideally longer in order to defend against brute-force attacks during the key validity period. For scalability reasons it is suggested to use a per-user key for signing NSLP messages, but using a per-session key is possible, too, at the cost of a per-session key exchange. A per-user key allows for verification of the authenticity of the message and thus provides a basis for a session-based per-user authorization. It is RECOMMENDED to periodically
用于HMAC计算的密钥必须通过其他方式安全交换，例如Kerberos票证或预共享手动安装等。身份验证数据中的密钥ID允许引用适当的密钥，并允许在会话中定期更改签名密钥。密钥长度必须至少为64位，但最好更长，以便在密钥有效期内抵御暴力攻击。出于可伸缩性原因，建议使用每用户密钥对NSLP消息进行签名，但也可以使用每会话密钥，代价是每会话密钥交换。每用户密钥允许验证消息的真实性，因此为基于会话的每用户授权提供了基础。建议定期检查
change the shared key in order to prevent eavesdroppers from performing brute-force off-line attacks on the shared key. The actual hash algorithm used in the HMAC computation is specified by the "Transform ID" field (given as Transform Type 3 of the IKEv2 registry [RFC5996]). The hash algorithm MUST be chosen consistently between the object creator and the NN verifying the HMAC; this can be accomplished by out-of-band mechanisms when the shared key is exchanged.
更改共享密钥以防止窃听者对共享密钥执行暴力离线攻击。HMAC计算中使用的实际哈希算法由“Transform ID”字段指定（作为IKEv2注册表[RFC5996]的Transform Type 3给出）。哈希算法必须在对象创建者和验证HMAC的NN之间一致地选择；这可以通过交换共享密钥时的带外机制来实现。
Figure 5 shows an example of an object that is used for integrity protection of NSLP messages.
图5显示了用于NSLP消息完整性保护的对象示例。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|0|0| Type = SESSION_AUTH |0|0|0|0| Object Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | AUTH_ENT_ID | HMAC_SIGNED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | Transform ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | SOURCE_ADDR | IPV4_ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Source Address of NSLP sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | START_TIME | NTP_TIME_STAMP|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP Time Stamp (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP Time Stamp (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | NSLP_OBJ_LIST | zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|No. of signed NSLP objects = n | rsv | NSLP object type (1) |
+-------+-------+---------------+-------+-------+---------------+
| rsv | NSLP object type (2) | ..... //
+-------+-------+---------------+---------------+---------------+
| rsv | NSLP object type (n) | (padding if required) |
+--------------+----------------+---------------+---------------+
| Length | AUTH_DATA | zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Authentication Code HMAC Data |
+---------------------------------------------------------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|0|0| Type = SESSION_AUTH |0|0|0|0| Object Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | AUTH_ENT_ID | HMAC_SIGNED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | Transform ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | SOURCE_ADDR | IPV4_ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Source Address of NSLP sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | START_TIME | NTP_TIME_STAMP|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP Time Stamp (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP Time Stamp (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | NSLP_OBJ_LIST | zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|No. of signed NSLP objects = n | rsv | NSLP object type (1) |
+-------+-------+---------------+-------+-------+---------------+
| rsv | NSLP object type (2) | ..... //
+-------+-------+---------------+---------------+---------------+
| rsv | NSLP object type (n) | (padding if required) |
+--------------+----------------+---------------+---------------+
| Length | AUTH_DATA | zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Authentication Code HMAC Data |
+---------------------------------------------------------------+
Figure 5: Example of a SESSION_AUTH_OBJECT That Provides Integrity Protection for NSLP Messages
图5：为NSLP消息提供完整性保护的SESSION_AUTH_对象示例
RFC 3521 [RFC3521] describes a framework in which the SESSION_AUTH object may be utilized to transport information required for authorizing resource reservation for data flows (e.g., media flows). RFC 3521 introduces four different models:
RFC 3521[RFC3521]描述了一种框架，在该框架中，会话_AUTH对象可用于传输授权数据流（例如，媒体流）的资源保留所需的信息。RFC 3521引入了四种不同的型号：
1. The coupled model
1. 耦合模型
2. The associated model with one policy server
2. 与一个策略服务器关联的模型
3. The associated model with two policy servers
3. 具有两个策略服务器的关联模型
4. The non-associated model
4. 非关联模型
The fields that are required in a SESSION_AUTH object depend on which of the models is used.
会话_AUTH对象中所需的字段取决于使用的模型。
In the coupled model, the only information that MUST be included in the SESSION_AUTH object is the SESSION_ID; it is used by the Authorizing Entity to correlate the resource reservation request with the media authorized during session setup. 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.
在耦合模型中，SESSION_AUTH对象中必须包含的唯一信息是SESSION_ID；授权实体使用它将资源保留请求与会话设置期间授权的媒体关联起来。由于假定终端主机不受信任，策略服务器应采取措施确保会话ID的完整性在传输过程中得以保持；要使用的确切机制和会话ID的格式取决于实现。
In this model, the contents of the SESSION_AUTH object MUST include:
在此模型中，会话_AUTH对象的内容必须包括：
o A session identifier - SESSION_ID. This is information that the authorizing entity can use to correlate the resource request with the data flows authorized during session setup.
o 会话标识符-会话ID。这是授权实体可用于将资源请求与会话设置期间授权的数据流关联的信息。
o The identity of the authorizing entity - AUTH_ENT_ID. This information is used by an NN to determine which authorizing entity (Policy Server) should be used to solicit resource policy decisions.
o 授权实体的标识-身份验证ID。NN使用此信息确定应使用哪个授权实体（策略服务器）来请求资源策略决策。
In some environments, an NN 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 SESSION_AUTH MUST also include:
在某些环境中，NN可能无法确定标识是否引用其域内的合法策略服务器。为了防止将授权请求重定向到虚假授权实体，会话认证还必须包括：
AUTHENTICATION_DATA. This authentication data is calculated over all other fields of the SESSION_AUTH object.
验证数据。此身份验证数据是通过会话\身份验证对象的所有其他字段计算的。
The content of the SESSION_AUTH object is identical to the associated model with one policy server.
SESSION_AUTH对象的内容与具有一个策略服务器的关联模型相同。
In this model, the SESSION_AUTH object MUST contain sufficient information to allow the Policy Server to make resource policy decisions autonomously from the authorizing entity. The object is created using information about the session by the authorizing entity. The information in the SESSION_AUTH object MUST include:
在此模型中，SESSION_AUTH对象必须包含足够的信息，以允许策略服务器从授权实体自主地做出资源策略决策。该对象是由授权实体使用有关会话的信息创建的。会话_AUTH对象中的信息必须包括：
o Initiating party's IP address or Identity (e.g., FQDN) - SOURCE_ADDR X-Type
o 发起方的IP地址或身份（例如FQDN）-源地址X-类型
o Responding party's IP address or Identity (e.g., FQDN) - DEST_ADDR X-Type
o 响应方的IP地址或身份（例如FQDN）-目的地址X-Type
o The authorization lifetime - START_TIME X-Type
o 授权生存期-开始时间X-Type
o 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
o 允许在共享对称密钥和Kerberos方案中验证令牌的授权实体的标识-AUTH_ENT_ID X-Type
o The credentials of the authorizing entity in a public-key scheme - AUTH_ENT_ID X-Type
o 公钥方案中授权实体的凭据-身份验证ID X-Type
o Authentication data used to prevent tampering with the SESSION_AUTH object - AUTHENTICATION_DATA X-Type
o 用于防止篡改会话\u身份验证对象的身份验证数据-身份验证\u数据X-Type
Furthermore, the SESSION_AUTH object MAY contain:
此外，SESSION_AUTH对象可以包含：
o The lifetime of (each of) the media stream(s) - END_TIME X-Type
o （每个）媒体流的生存期-结束时间X-Type
o Initiating party's port number - SOURCE_ADDR X-Type
o 发起方的端口号-源地址X-Type
o Responding party's port number - DEST_ADDR X-Type
o 响应方的端口号-DEST_ADDR X-Type
All SESSION_AUTH fields MUST match with the resource request. If a field does not match, the request SHOULD be denied.
所有会话_AUTH字段必须与资源请求匹配。如果字段不匹配，则应拒绝请求。
This section discusses the message processing related to the SESSION_AUTH object. Details of the processing of the SESSION_AUTH object within QoS NSLP and NATFW NSLP are described. New NSLP protocols should use the same logic in making use of the SESSION_AUTH object.
本节讨论与SESSION_AUTH对象相关的消息处理。描述了QoS NSLP和NATFW NSLP中会话_AUTH对象的处理细节。新的NSLP协议在使用SESSION_AUTH对象时应该使用相同的逻辑。
1. Generate the SESSION_AUTH object with the appropriate contents as specified in Section 3.
1. 使用第3节中指定的适当内容生成SESSION_AUTH对象。
2. If authentication is needed, the entire SESSION_AUTH object is constructed, excluding the length, type, and SubType fields of the SESSION_AUTH field. Note that the message MUST include a START_TIME to prevent replay attacks. The output of the authentication algorithm, plus appropriate header information, is appended as the AUTHENTICATION_DATA attribute to the SESSION_AUTH object.
2. 如果需要身份验证，将构造整个会话\u AUTH对象，不包括会话\u AUTH字段的长度、类型和子类型字段。请注意，该消息必须包含开始时间，以防止重播攻击。身份验证算法的输出，加上适当的头信息，作为身份验证数据属性附加到会话身份验证对象。
The SESSION_AUTH object may be used with QoS NSLP QUERY and RESERVE messages to authorize the query operation for network resources, and a resource reservation request, respectively.
SESSION_AUTH对象可与QoS NSLP查询和保留消息一起使用，以分别授权网络资源的查询操作和资源保留请求。
Moreover, the SESSION_AUTH object may also be used with RESPONSE messages in order to indicate that the authorizing entity changed the original request. For example, the session start or end times may have been modified, or the client may have requested authorization for all ports, but the authorizing entity only allowed the use of certain ports.
此外，SESSION_AUTH对象还可以与响应消息一起使用，以指示授权实体更改了原始请求。例如，会话开始或结束时间可能已修改，或者客户端可能已请求对所有端口进行授权，但授权实体仅允许使用某些端口。
If the QoS NSIS Initiator (QNI) receives a RESPONSE message with a SESSION_AUTH object, the QNI MUST inspect the SESSION_AUTH object to see which authentication attribute was changed by an authorizing entity. The QNI SHOULD also silently accept SESSION_AUTH objects in the RESPONSE message that do not indicate any change to the original authorization request.
如果QoS NSIS启动器（QNI）接收到带有会话身份验证对象的响应消息，则QNI必须检查会话身份验证对象，以查看授权实体更改了哪个身份验证属性。QNI还应该静默地接受响应消息中的SESSION_AUTH对象，这些对象不表示对原始授权请求的任何更改。
A QoS NSLP message is created as specified in [RFC5974].
按照[RFC5974]中的规定创建QoS NSLP消息。
1. The policy element received from the authorizing entity MUST be copied without modification into the SESSION_AUTH object.
1. 必须将从授权实体收到的策略元素复制到会话\u AUTH对象中，而不进行修改。
2. The SESSION_AUTH object (containing the policy element) is inserted in the NSLP message in the appropriate place.
2. SESSION_AUTH对象（包含policy元素）插入NSLP消息中的适当位置。
The QoS NSLP message is processed as specified in [RFC5974] with the following modifications.
QoS NSLP消息按照[RFC5974]中的规定进行处理，并进行以下修改。
1. If the QoS NSIS Entity (QNE) is policy aware then it SHOULD use the Diameter QoS application or the RADIUS QoS protocol to communicate with the PDP. To construct the AAA message it is necessary to extract the SESSION_AUTH object and the QoS-related objects from the QoS NSLP message and to craft the respective RADIUS or Diameter message. The message processing and object format are described in the respective RADIUS or Diameter QoS protocol, respectively. If the QNE is policy unaware, then it ignores the policy data objects and continues processing the NSLP message.
1. 如果QoS NSIS实体（QNE）具有策略意识，则应使用Diameter QoS应用程序或RADIUS QoS协议与PDP通信。要构造AAA消息，必须从QoS NSLP消息中提取会话_AUTH对象和QoS相关对象，并制作相应的RADIUS或Diameter消息。消息处理和对象格式分别在相应的RADIUS或Diameter QoS协议中描述。如果QNE不知道策略，那么它将忽略策略数据对象并继续处理NSLP消息。
2. If the response from the PDP is negative, the request must be rejected. A negative response in RADIUS is an Access-Reject, and in Diameter is based on the 'DIAMETER_SUCCESS' value in the Result-Code AVP of the QoS-Authz-Answer (QAA) message. The QNE must construct and send a RESPONSE message with the status of the authorization failure as specified in [RFC5974].
2. 如果PDP的响应为否定，则必须拒绝请求。RADIUS中的否定响应是访问拒绝，而Diameter中的否定响应基于QoS Authz应答（QAA）消息的结果代码AVP中的“Diameter_SUCCESS”值。QNE必须构造并发送一条响应消息，其状态为[RFC5974]中规定的授权失败。
3. Continue processing the NSIS message.
3. 继续处理NSIS消息。
1. Retrieve the policy element from the SESSION_AUTH object. Check the AUTH_ENT_ID type and SubType fields and return an error if the identity type is not supported.
1. 从SESSION\u AUTH对象检索策略元素。检查“身份验证ID类型”和“子类型”字段，如果不支持该标识类型，则返回错误。
2. Verify the message integrity.
2. 验证消息的完整性。
* Shared symmetric key authentication: The QNE or 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.
* 共享对称密钥身份验证：QNE或PDP使用AUTH_ENT_ID字段来查询由该字段设置密钥的表。该表应确定要使用的加密身份验证算法以及授权实体的身份验证数据的预期长度和共享对称密钥。验证所指示的身份验证数据长度是否与配置的表条目一致，并验证身份验证数据。
* Public Key: Validate the certificate chain against the trusted Certificate Authority (CA) and validate the message signature using the public key.
* 公钥：根据可信证书颁发机构（CA）验证证书链，并使用公钥验证消息签名。
* HMAC signed: The QNE or PDP uses the Key-ID field of the AUTHENTICATION_DATA attribute 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 integrity of the parts of the NSLP message, i.e., session ID, MRI, NSLPID, and all other NSLP elements listed in the NSLP_OBJECT_LIST authentication data as well as the SESSION_AUTH object contents (cf. Section 6.4).
* HMAC signed:QNE或PDP使用AUTHENTICATION_数据属性的Key ID字段来查询由该字段设置密钥的表。该表应确定要使用的加密身份验证算法以及授权实体的身份验证数据的预期长度和共享对称密钥。验证认证数据的指示长度是否与配置的表条目一致，并验证NSLP消息部分的完整性，即会话ID、MRI、NSLPID和NSLP对象列表认证数据中列出的所有其他NSLP元素以及会话认证对象内容的完整性（参见第6.4节）。
* Kerberos: If AUTHENTICATION_DATA contains an encapsulated KRB_CRED message (cf. Section 4.2), the integrity of the KRB_CRED message can be verified within Kerberos itself. Moreover, if the same NSLP message contains another SESSION_AUTH object using HMAC_SIGNED, the latter can be used to verify the message integrity as described above.
* Kerberos：如果身份验证数据包含封装的KRB_CRED消息（参见第4.2节），则可以在Kerberos本身内验证KRB_CRED消息的完整性。此外，如果同一NSLP消息包含另一个使用HMAC_签名的会话_AUTH对象，则后者可用于如上所述验证消息完整性。
3. Once the identity of the authorizing entity and the validity of the service request have been established, the authorizing router/PDP MUST then consult its authorization policy in order to determine whether or not the specific request is finally authorized (e.g., based on available credits and on information in the subscriber's database). To the extent to which these access control decisions require supplementary information, routers/PDPs MUST ensure that supplementary information is obtained securely.
3. 一旦确定了授权实体的身份和服务请求的有效性，授权路由器/PDP必须随后参考其授权策略，以确定特定请求是否最终得到授权（例如，基于可用信用和订户数据库中的信息）。如果这些访问控制决策需要补充信息，路由器/PDP必须确保安全获取补充信息。
4. Verify that the requested resources do not exceed the authorized QoS.
4. 验证请求的资源没有超过授权的QoS。
When the PDP (e.g., a RADIUS or Diameter server) fails to verify the policy element, the appropriate actions described in the respective AAA document need to be taken.
当PDP（例如RADIUS或Diameter服务器）未能验证策略元素时，需要采取相应AAA文档中描述的适当措施。
The QNE node MUST return a RESPONSE message with the INFO_SPEC error code 'Authorization failure' as defined in the QoS NSLP specification [RFC5974]. The QNE MAY include an INFO_SPEC Object Value Info to indicate which SESSION_AUTH attribute created the error.
QNE节点必须返回一条响应消息，其中包含QoS NSLP规范[RFC5974]中定义的信息规范错误代码“授权失败”。QNE可能包含一个INFO_SPEC对象值INFO，以指示哪个会话身份验证属性创建了错误。
This section presents processing rules for the NATFW NSLP [RFC5973].
本节介绍NATFW NSLP[RFC5973]的处理规则。
A NATFW NSLP message is created as specified in [RFC5973].
按照[RFC5973]中的规定创建NATFW NSLP消息。
1. The policy element received from the authorizing entity MUST be copied without modification into the SESSION_AUTH object.
1. 必须将从授权实体收到的策略元素复制到会话\u AUTH对象中，而不进行修改。
2. The SESSION_AUTH object (containing the policy element) is inserted in the NATFW NSLP message in the appropriate place.
2. SESSION_AUTH对象（包含policy元素）插入NATFW NSLP消息中的适当位置。
The NATFW NSLP message is processed as specified in [RFC5973] with the following modifications.
NATFW NSLP消息按照[RFC5973]中的规定进行处理，并进行以下修改。
1. If the router is policy aware, then it SHOULD use the Diameter application or the RADIUS protocol to communicate with the PDP. To construct the AAA message, it is necessary to extract the SESSION_AUTH object and the objects related to NATFW policy rules from the NSLP message and to craft the respective RADIUS or Diameter message. The message processing and object format is described in the respective RADIUS or Diameter protocols. If the router is policy unaware, then it ignores the policy data objects and continues processing the NSLP message.
1. 如果路由器具有策略意识，则应使用Diameter应用程序或RADIUS协议与PDP通信。要构造AAA消息，需要从NSLP消息中提取会话_AUTH对象和与NATFW策略规则相关的对象，并制作相应的RADIUS或Diameter消息。在相应的RADIUS或Diameter协议中描述了消息处理和对象格式。如果路由器不知道策略，那么它将忽略策略数据对象并继续处理NSLP消息。
2. Reject the message if the response from the PDP is negative. A negative response in RADIUS is an Access-Reject, and in Diameter is based on the 'DIAMETER_SUCCESS' value in the Result-Code AVP.
2. 如果PDP的响应为否定，则拒绝该消息。RADIUS中的否定响应是访问拒绝，而Diameter基于结果代码AVP中的“Diameter_SUCCESS”值。
3. Continue processing the NSIS message.
3. 继续处理NSIS消息。
1. Retrieve the policy element from the SESSION_AUTH object. Check the AUTH_ENT_ID type and SubType fields and return an error if the identity type is not supported.
1. 从SESSION\u AUTH对象检索策略元素。检查“身份验证ID类型”和“子类型”字段，如果不支持该标识类型，则返回错误。
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）验证证书链，并使用公钥验证消息签名。
* HMAC signed: The QNE or PDP uses the Key-ID field of the AUTHENTICATION_DATA attribute 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 integrity of parts of the NSLP message, i.e., session ID, MRI, NSLPID, and all other NSLP elements listed in the NSLP_OBJECT_LIST authentication data as well as the SESSION_AUTH object contents (cf. Section 6.4).
* HMAC signed:QNE或PDP使用AUTHENTICATION_数据属性的Key ID字段来查询由该字段设置密钥的表。该表应确定要使用的加密身份验证算法以及授权实体的身份验证数据的预期长度和共享对称密钥。验证认证数据的指示长度是否与配置的表条目一致，并验证NSLP消息部分的完整性，即会话ID、MRI、NSLPID和NSLP对象列表认证数据中列出的所有其他NSLP元素以及会话认证对象内容的完整性（参见第6.4节）。
* Kerberos: If AUTHENTICATION_DATA contains an encapsulated KRB_CRED message (cf. Section 4.2), the integrity of the KRB_CRED message can be verified within Kerberos itself. Moreover, an if the same NSLP message contains another SESSION_AUTH object using HMAC_SIGNED, the latter can be used to verify the message integrity as described above.
* Kerberos：如果身份验证数据包含封装的KRB_CRED消息（参见第4.2节），则可以在Kerberos本身内验证KRB_CRED消息的完整性。此外，如果同一NSLP消息包含另一个使用HMAC_签名的SESSION_AUTH对象，则后者可用于如上所述验证消息完整性。
3. Once the identity of the authorizing entity and the validity of the service request have been established, the authorizing router/PDP MUST then consult its authorization policy 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.
3. 一旦建立了授权实体的身份和服务请求的有效性，授权路由器/PDP就必须参考其授权策略，以确定特定请求是否被授权。如果这些访问控制决策需要补充信息，路由器/PDP必须确保安全获取补充信息。
When the PDP (e.g., a RADIUS or Diameter server) fails to verify the SESSION_AUTH object, the appropriate actions described in the respective AAA document need to be taken. The NATFW NSLP node MUST return an error message of class 'Permanent failure' (0x5) with error code 'Authorization failed' (0x02).
当PDP（例如RADIUS或Diameter服务器）无法验证会话验证对象时，需要采取相应AAA文档中描述的适当措施。NATFW NSLP节点必须返回类为“永久故障”（0x5）的错误消息，错误代码为“授权失败”（0x02）。
The SESSION_AUTH object can also be used to provide an integrity protection for every NSLP signaling message, thereby also authenticating requests or responses. Assume that a user has deposited a shared key at some NN. This NN can then verify the integrity of every NSLP message sent by the user to the NN. Based on this authentication, the NN can apply authorization policies to actions like resource reservations or opening of firewall pinholes.
SESSION_AUTH对象还可用于为每个NSLP信令消息提供完整性保护，从而也验证请求或响应。假设用户在某个NN处存放了共享密钥。然后，该NN可以验证用户发送给NN的每个NSLP消息的完整性。基于此身份验证，NN可以将授权策略应用于资源保留或打开防火墙针孔等操作。
The sender of an NSLP message creates a SESSION_AUTH object that contains the AUTH_ENT_ID attribute set to HMAC_SIGNED (cf. Section 4.4) and hashes with the shared key over all NSLP objects that need to be protected and lists them in the NSLP_OBJECT_LIST. The SESSION_AUTH object itself is also protected by the HMAC. By inclusion of the SESSION_AUTH object into the NSLP message, the receiver of this NSLP message can verify its integrity if it has the suitable shared key for the HMAC. Any response to the sender should also be protected by inclusion of a SESSION_AUTH object in order to prevent attackers from sending unauthorized responses on behalf of the real NN.
NSLP消息的发送方创建一个会话身份验证对象，该对象包含设置为HMAC_SIGNED（参见第4.4节）的身份验证ID属性，并使用共享密钥对所有需要保护的NSLP对象进行散列，并将其列在NSLP_对象列表中。会话_AUTH对象本身也受HMAC保护。通过将SESSION_AUTH对象包含到NSLP消息中，此NSLP消息的接收方可以验证其完整性，前提是它具有适用于HMAC的共享密钥。对发送方的任何响应也应通过包含会话_AUTH对象来保护，以防止攻击者代表真实NN发送未经授权的响应。
If a SESSION_AUTH object is present that has an AUTH_ENT_ID attribute set to HMAC_SIGNED, the integrity of all NSLP elements listed in the NSLP_OBJECT_LIST has to be checked, including the SESSION_AUTH object contents itself. Furthermore, session ID, MRI, and NSLPID have to be included into the HMAC calculation, too, as specified in Section 3.2.7. The key that is used to calculate the HMAC is referred to by the Key-ID included in the AUTHENTICATION_DATA attribute. If the provided timestamp in START_TIME is not recent enough or the calculated HMAC differs from the one provided in AUTHENTICATION_DATA, the message must be discarded silently and an error should be logged locally.
如果存在具有设置为HMAC_SIGNED的AUTH_ENT_ID属性的SESSION_AUTH对象，则必须检查NSLP_object_列表中列出的所有NSLP元素的完整性，包括SESSION_AUTH对象内容本身。此外，会话ID、MRI和NSLPID也必须包括在HMAC计算中，如第3.2.7节所述。用于计算HMAC的密钥由身份验证数据属性中包含的密钥ID引用。如果在START_TIME中提供的时间戳不够近，或者计算的HMAC与在AUTHENTICATION_DATA中提供的HMAC不同，则必须以静默方式丢弃消息，并在本地记录错误。
This document describes a mechanism for session authorization to prevent theft of service. There are three types of security issues to consider: protection against replay attacks, integrity of the SESSION_AUTH object, and the choice of the authentication algorithms and keys.
本文档描述了一种会话授权机制，以防止服务被盗。有三种类型的安全问题需要考虑：防止重播攻击、会话的完整性、身份验证对象以及身份验证算法和密钥的选择。
The first issue, replay attacks, MUST be prevented. In the non-associated model, the SESSION_AUTH object MUST include a START_TIME field, and the NNs as well as 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 sync. 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 SESSION_AUTH object is replayed, it MUST be detected by the policy server (using internal algorithms), and the request MUST be rejected.
必须防止第一个问题，即重播攻击。在非关联模型中，SESSION_AUTH对象必须包含START_时间字段，NNs以及策略服务器必须支持NTP以确保正确的时钟同步。未能确保正确的时钟同步将允许重播攻击，因为不同网络实体的时钟可能不同步。开始时间用于验证请求是否在以后的时间重播。在所有其他模型中，策略服务器使用会话ID来确保资源请求与授权会话的记录成功关联。如果重播会话_AUTH对象，策略服务器必须检测到它（使用内部算法），并且必须拒绝该请求。
The second issue, the integrity of the SESSION_AUTH object, is preserved in untrusted environments by including the AUTHENTICATION_DATA attribute in such environments.
第二个问题是SESSION_AUTH对象的完整性，通过在不受信任的环境中包含AUTHENTICATION_DATA属性，可以在不受信任的环境中保护它。
In environments where shared symmetric keys are possible, they should be used in order to keep the SESSION_AUTH object size to a strict minimum, e.g., when wireless links are used. A secondary option would be Public Key Infrastructure (PKI) authentication, which provides a high level of security and good scalability. However, PKI authentication requires the presence of credentials in the SESSION_AUTH object, thus impacting its size.
在可能使用共享对称密钥的环境中，应使用这些密钥，以便将会话验证对象大小保持在严格的最小值，例如，在使用无线链路时。第二种选择是公钥基础设施（PKI）认证，它提供了高级别的安全性和良好的可扩展性。但是，PKI身份验证要求会话_AUTH对象中存在凭据，从而影响其大小。
The SESSION_AUTH object can also serve to protect the integrity of NSLP message parts by using the HMAC_SIGNED Authentication Data as described in Section 6.4.
SESSION_AUTH对象还可以通过使用HMAC_签名的身份验证数据来保护NSLP消息部分的完整性，如第6.4节所述。
When shared keys are used, e.g., in AUTHENTICATION_DATA (cf. Section 4.1) or in conjunction with HMAC_SIGNED (cf. Section 4.4), it is important that the keys are kept secret, i.e., they must be exchanged, stored, and managed in a secure and confidential manner, so that no unauthorized party gets access to the key material. If the key material is disclosed to an unauthorized party, authentication and integrity protection are ineffective.
当使用共享密钥时，例如在身份验证数据（参见第4.1节）或与HMAC签名（参见第4.4节）结合使用时，密钥必须保密，即必须以安全保密的方式交换、存储和管理，以便未经授权的一方无法访问密钥材料。如果将密钥材料披露给未经授权的一方，则身份验证和完整性保护无效。
Furthermore, security considerations for public-key mechanisms using the X.509 certificate mechanisms described in [RFC5280] apply. Similarly, security considerations for PGP (Pretty Good Privacy) described in [RFC4880] apply.
此外，使用[RFC5280]中描述的X.509证书机制的公钥机制的安全注意事项也适用。类似地，[RFC4880]中描述的PGP（相当好的隐私）的安全注意事项也适用。
Further security issues are outlined in RFC 4081 [RFC4081].
RFC 4081[RFC4081]中概述了进一步的安全问题。
The SESSION_AUTH_OBJECT NSLP Message Object type is specified as 0x016.
会话身份验证对象NSLP消息对象类型指定为0x016。
This document specifies an 8-bit Session authorization attribute type (X-Type) field as well as 8-bit SubType fields per X-Type, for which IANA has created and will maintain corresponding sub-registries for the NSLP Session Authorization Object.
本文档指定了一个8位会话授权属性类型（X-type）字段以及每个X-type的8位子类型字段，IANA已为其创建并将维护NSLP会话授权对象的相应子注册表。
Initial values for the X-Type registry and the registration procedures according to [RFC5226] are as follows:
根据[RFC5226]，X-Type注册表和注册程序的初始值如下：
Registration Procedure: Specification Required
注册程序：需要说明
X-Type Description
-------- -------------------
0 Reserved
1 AUTH_ENT_ID
2 SESSION_ID
3 SOURCE_ADDR
4 DEST_ADDR
5 START_TIME
6 END_TIME
7 NSLP_OBJECT_LIST
8 AUTHENTICATION_DATA
9-127 Unassigned
128-255 Reserved for Private or Experimental Use
X-Type Description
-------- -------------------
0 Reserved
1 AUTH_ENT_ID
2 SESSION_ID
3 SOURCE_ADDR
4 DEST_ADDR
5 START_TIME
6 END_TIME
7 NSLP_OBJECT_LIST
8 AUTHENTICATION_DATA
9-127 Unassigned
128-255 Reserved for Private or Experimental Use
In the following, registration procedures and initial values for the SubType registries are specified.
下面指定了子类型注册表的注册过程和初始值。
Sub-registry: AUTH_ENT_ID (X-Type 1) SubType values
子注册表：身份验证ID（X-Type 1）子类型值
Registration Procedure: Specification Required
注册程序：需要说明
Registry:
SubType Description
-------- -------------
0 Reserved
1 IPV4_ADDRESS
2 IPV6_ADDRESS
3 FQDN
4 ASCII_DN
5 UNICODE_DN
6 URI
7 KRB_PRINCIPAL
8 X509_V3_CERT
9 PGP_CERT
10 HMAC_SIGNED
11-127 Unassigned
128-255 Reserved for Private or Experimental Use
Registry:
SubType Description
-------- -------------
0 Reserved
1 IPV4_ADDRESS
2 IPV6_ADDRESS
3 FQDN
4 ASCII_DN
5 UNICODE_DN
6 URI
7 KRB_PRINCIPAL
8 X509_V3_CERT
9 PGP_CERT
10 HMAC_SIGNED
11-127 Unassigned
128-255 Reserved for Private or Experimental Use
Sub-registry: SOURCE_ADDR (X-Type 3) SubType values
子注册表：源地址（X-Type 3）子类型值
Registration Procedure: Specification Required
注册程序：需要说明
Registry:
SubType Description
-------- -------------
0 Reserved
1 IPV4_ADDRESS
2 IPV6_ADDRESS
3 UDP_PORT_LIST
4 TCP_PORT_LIST
5 SPI
6-127 Unassigned
128-255 Reserved for Private or Experimental Use
Registry:
SubType Description
-------- -------------
0 Reserved
1 IPV4_ADDRESS
2 IPV6_ADDRESS
3 UDP_PORT_LIST
4 TCP_PORT_LIST
5 SPI
6-127 Unassigned
128-255 Reserved for Private or Experimental Use
Sub-registry: DEST_ADDR (X-Type 4) SubType values
子注册表：DEST_ADDR（X-Type 4）子类型值
Registration Procedure: Specification Required
注册程序：需要说明
Registry: 0 Reserved 1 IPV4_ADDRESS 2 IPV6_ADDRESS 3 UDP_PORT_LIST 4 TCP_PORT_LIST 5 SPI 6-127 Unassigned 128-255 Reserved for Private or Experimental Use
注册表：0保留1 IPV4_地址2 IPV6_地址3 UDP_端口_列表4 TCP_端口_列表5 SPI 6-127未分配128-255保留供私人或实验使用
Sub-registry: START_TIME (X-Type 5) SubType values
子注册表：开始时间（X-Type 5）子类型值
Registration Procedure: Specification Required
注册程序：需要说明
Registry:
SubType Description
-------- -------------
0 Reserved
1 NTP_TIMESTAMP
2-127 Unassigned
128-255 Reserved for Private or Experimental Use
Registry:
SubType Description
-------- -------------
0 Reserved
1 NTP_TIMESTAMP
2-127 Unassigned
128-255 Reserved for Private or Experimental Use
Sub-registry: END_TIME (X-Type 6) SubType values
子注册表：结束时间（X-Type 6）子类型值
Registration Procedure: Specification Required
注册程序：需要说明
Registry:
SubType Description
-------- -------------
0 Reserved
1 NTP_TIMESTAMP
2-127 Unassigned
128-255 Reserved for Private or Experimental Use
Registry:
SubType Description
-------- -------------
0 Reserved
1 NTP_TIMESTAMP
2-127 Unassigned
128-255 Reserved for Private or Experimental Use
We would like to thank Xioaming Fu and Lars Eggert for providing reviews and comments. Helpful comments were also provided by Gen-ART reviewer Ben Campbell, as well as Sean Turner and Tim Polk from the Security Area. This document is largely based on the RFC 3520 [RFC3520] and credit therefore goes to the authors of RFC 3520 -- namely, Louis-Nicolas Hamer, Brett Kosinski, Bill Gage, and Hugh Shieh. Part of this work was funded by Deutsche Telekom Laboratories within the context of the BMBF-funded ScaleNet project.
我们要感谢Fu Xiaming和Lars Eggert提供的评论和意见。Gen艺术评论家本·坎贝尔以及安全部门的肖恩·特纳和蒂姆·波尔克也提供了有益的评论。本文件主要基于RFC 3520[RFC3520]，因此应归功于RFC 3520的作者，即路易斯·尼古拉斯·哈默、布雷特·科辛斯基、比尔·盖奇和休·谢。这项工作的一部分由德国电信实验室在BMBF资助的ScaleNet项目范围内资助。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RFC3447]Jonsson，J.和B.Kaliski，“公钥密码标准（PKCS）#1:RSA密码规范版本2.1”，RFC 3447，2003年2月。
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[RFC5905]Mills，D.，Martin，J.，Burbank，J.，和W.Kasch，“网络时间协议版本4：协议和算法规范”，RFC 59052010年6月。
[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, October 2010.
[RFC5971]Schulzrinne，H.和R.Hancock，“要点：通用互联网信号传输”，RFC 59712010年10月。
[RFC5973] Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", RFC 5973, October 2010.
[RFC5973]Stieemerling，M.，Tschofenig，H.，Aoun，C.，和E.Davies，“NAT/防火墙NSIS信令层协议（NSLP）”，RFC 59732010年10月。
[RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling", RFC 5974, October 2010.
[RFC5974]Way，J.，Karagiannis，G.，和A.McDonald，“用于服务质量信令的NSIS信令层协议（NSLP）”，RFC 5974，2010年10月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996]Kaufman，C.，Hoffman，P.，Nir，Y.，和P.Eronen，“互联网密钥交换协议版本2（IKEv2）”，RFC 59962010年9月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[RFC3520] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, "Session Authorization Policy Element", RFC 3520, April 2003.
[RFC3520]Hamer，L-N.，Gage，B.，Kosinski，B.，和H.Shieh，“会话授权策略元素”，RFC 3520，2003年4月。
[RFC3521] Hamer, L-N., Gage, B., and H. Shieh, "Framework for Session Set-up with Media Authorization", RFC 3521, April 2003.
[RFC3521]Hamer，L-N.，Gage，B.，和H.Shieh，“通过媒体授权建立会话的框架”，RFC 35212003年4月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, June 2005.
[RFC4080]Hancock，R.，Karagiannis，G.，Loughney，J.，和S.Van den Bosch，“信号的下一步（NSIS）：框架”，RFC 40802005年6月。
[RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next Steps in Signaling (NSIS)", RFC 4081, June 2005.
[RFC4081]Tschofenig，H.和D.Kroeselberg，“信令（NSIS）下一步的安全威胁”，RFC 40812005年6月。
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[RFC4120]Neuman，C.，Yu，T.，Hartman，S.，和K.Raeburn，“Kerberos网络身份验证服务（V5）”，RFC41202005年7月。
[RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, June 2006.
[RFC4514]Zeilenga，K.，“轻量级目录访问协议（LDAP）：可分辨名称的字符串表示”，RFC4514，2006年6月。
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007.
[RFC4868]Kelly，S.和S.Frankel，“在IPsec中使用HMAC-SHA-256、HMAC-SHA-384和HMAC-SHA-512”，RFC 4868，2007年5月。
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
[RFC4880]Callas，J.，Donnerhacke，L.，Finney，H.，Shaw，D.，和R.Thayer，“OpenPGP消息格式”，RFC 48802007年11月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652]Housley，R.，“加密消息语法（CMS）”，STD 70，RFC 56522009年9月。
Authors' Addresses
作者地址
Jukka Manner Aalto University Department of Communications and Networking (Comnet) P.O. Box 13000 Aalto FI-00076 Finland
Jukka-Aalto大学通信与网络系（Comnet）邮政信箱13000 Aalto FI-00076芬兰
Phone: +358 9 470 22481
EMail: jukka.manner@tkk.fi
Phone: +358 9 470 22481
EMail: jukka.manner@tkk.fi
Martin Stiemerling Network Laboratories, NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany
马丁·斯蒂梅林网络实验室，NEC欧洲有限公司Kurfuersten Anlage 36海德堡69115德国
Phone: +49 (0) 6221 4342 113
EMail: martin.stiemerling@neclab.eu
URI: http://www.stiemerling.org
Phone: +49 (0) 6221 4342 113
EMail: martin.stiemerling@neclab.eu
URI: http://www.stiemerling.org
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Hannes Tschofenig诺基亚西门子网络公司芬兰Linnoitustie 6 Espoo 02600
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Roland Bless (editor) Karlsruhe Institute of Technology Institute of Telematics Zirkel 2, Building 20.20 P.O. Box 6980 Karlsruhe 76049 Germany
罗兰·布莱斯（编辑）德国卡尔斯鲁厄理工学院远程信息处理研究所Zirkel 2号楼20.20信箱6980卡尔斯鲁厄76049
Phone: +49 721 608 46413
EMail: roland.bless@kit.edu
URI: http://tm.kit.edu/~bless
Phone: +49 721 608 46413
EMail: roland.bless@kit.edu
URI: http://tm.kit.edu/~bless