[要約] RFC 5981は、NSISシグナリングレイヤープロトコルの認証に関するガイドラインです。その目的は、NSISプロトコルのセキュリティを向上させ、認証のための標準的な手法を提供することです。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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
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]、およびさまざまな種類のシグナリングアプリケーションに基づいています。2つのシグナル伝達アプリケーションとその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ホップが適切なセキュリティプロトコルを選択できるトラストチェーンモデルに基づいています。たとえば、2つの直接隣接する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-Layerセッションの承認を使用する場合のデフォルト操作は、1つの承認ポリシーオブジェクトを追加することです。しかし、異なるネットワークからエンドツーエンドのシグナリングと要求の承認をサポートするために、NSLPシグナリングセッションを開始するホストは、メッセージに複数のセッション_Authオブジェクトを追加する場合があります。認可エンティティの識別子は、ネットワーク要素によって使用され、信頼できるサードパーティを使用してリクエストを確認できます。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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/Firewall 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 Authorization（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 //
+ +
+---------------------------------------------------------------+
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」とマークされたビットは、拡張性フラグであり、プロトコル仕様で処理が定義されていないオブジェクトの目的の処理を知らせるために使用されます（つまり、そのタイプフィールドは受信機で不明です）。次の4つのカテゴリのオブジェクトが特定されており、情報目的のみで説明されています（規範的行動については、特定のNSLPドキュメントを参照してください。
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（ "Ingrore"）：オブジェクトが理解されていない場合は、削除する必要があり、残りのメッセージは通常どおり処理されます。
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（ "Forward"）：オブジェクトが理解されていない場合、メッセージ処理の結果として転送されたメッセージで変更されずに保持する必要がありますが、ローカルに保存されません。
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（ "REFRESH"）：オブジェクトが理解されていない場合、このフロー/セッションのローカルに保存されたシグナリングアプリケーション状態に組み込む必要があります。ローカルで生成されます。このフラグの組み合わせは、すべての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)
タイプ：session_auth_object（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 ... //
+---------------------------------------------------------------+
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.
長さフィールドは2オクテットで、オクテット数の属性（長さ、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: 1. AUTH_ENT_ID: The unique identifier of the entity that authorized the session.
セッション認証属性タイプ（Xタイプ）フィールドは1オクテットです。IANAは、セクション8、IANAの考慮事項で説明されているように、Xタイプのレジストリとして機能します。この仕様では、次のXタイプを使用します。1。auth_ent_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. SESSION_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. start_time：セッションの開始時間。
6. END_TIME: The end time for the session.
6. End_time：セッションの終了時間。
7. AUTHENTICATION_DATA: The authentication data of the Session Authorization Object.
7. Authentication_Data：セッション認証オブジェクトの認証データ。
SubType: 8 bits
サブタイプ：8ビット
Session authorization attribute sub-type is one octet in length. The value of the SubType depends on the X-Type.
セッション認証属性サブタイプの長さは1オクターです。サブタイプの値は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:
auth_ent_idは、初期サービス要求を承認し、セッション認証オブジェクトを生成したエンティティを識別するために使用されます。auth_ent_idはさまざまな形式で表される場合があり、サブタイプはIDの形式を定義するために使用されます。auth_ent_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 ... //
+---------------------------------------------------------------+
Length: Length of the attribute, which MUST be > 4.
X-Type: AUTH_ENT_ID
Xタイプ：auth_ent_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:
auth_ent_idの次のサブタイプが定義されています。IANAは、セクション8、IANAの考慮事項で説明されているように、auth_ent_idサブタイプのレジストリとして機能します。最初に、レジストリには次のauth_ent_idのサブタイプが含まれています。
1. IPV4_ADDRESS: IPv4 address represented in 32 bits.
1. IPv4_Address：32ビットで表されるIPv4アドレス。
2. IPV6_ADDRESS: IPv6 address represented in 128 bits.
2. IPv6_Address：128ビットで表されるIPv6アドレス。
3. FQDN: Fully Qualified Domain Name as defined in [RFC1034] as an ASCII string.
3. FQDN：ASCII文字列として[RFC1034]で定義されている完全に適格なドメイン名。
4. ASCII_DN: X.500 Distinguished name as defined in [RFC4514] as an ASCII string.
4. ASCII_DN：X.500 ASCII文字列として[RFC4514]で定義されている著名な名前。
5. UNICODE_DN: X.500 Distinguished name as defined in [RFC4514] as a UTF-8 string.
5. unicode_dn：x.500 utf-8文字列として[rfc4514]で定義されているdistinguished名。
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：プリンシパルのASCII文字列に代表される完全な資格のあるKerberosの校長名、[RFC4120]で定義されている @ Realm名（例えば、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：UTF-8文字列として[RFC4514]で定義されている証明書の主題の著名な名前。
9. PGP_CERT: The OpenPGP certificate of the authorizing entity as defined as Public-Key Packet in [RFC4880].
9. PGP_CERT：[RFC4880]のパブリックキーパケットとして定義されている認可エンティティのOpenPGP証明書。
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：認証_DATA属性には、NSLPメッセージの整合性を保証する自己署名HMAC署名[RFC2104]が含まれていることを示します。HMACは、nslp_object_list属性に与えられたすべてのNSLPオブジェクトで計算されます。オブジェクトは、IKEV2レジストリ[RFC5996]の変換タイプ3からの変換IDとしてHMACの計算に使用されるハッシュアルゴリズムを指定します。
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.
session_idは、承認エンティティがリクエストを識別するために使用する一意の識別子です。リプレイの検出など、多くの目的に使用するか、この要求を認可エンティティによるポリシー決定エントリと関連付けることができます。たとえば、Session_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 ... //
+---------------------------------------------------------------+
Length: Length of the attribute, which MUST be > 4.
長さ：属性の長さ。これは> 4でなければなりません。
X-Type: SESSION_ID
Xタイプ：session_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.
現在、session_idのサブタイプは定義されていません。このフィールドはゼロに設定する必要があります。承認エンティティは、session_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タイプは、いくつかのシナリオで役立つ場合があり、その特定のソースアドレスやポートに対してリソース要求が許可されていることを確認します。通常、これは、GIST MRI（メッセージルーティング情報）オブジェクトに含まれるGISTパケットのIPソースアドレス、またはフローソースまたはフロー宛先アドレスのそれぞれにそれぞれ対応します。
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.
X-Type: SOURCE_ADDR
Xタイプ：source_addr
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:
source_addrの次のサブタイプが定義されています。IANAは、セクション8、IANAの考慮事項で説明されているように、source_addrサブタイプのレジストリとして機能します。最初に、レジストリには、source_addrの次のサブタイプが含まれています。
1. IPV4_ADDRESS: IPv4 address represented in 32 bits.
1. IPv4_Address：32ビットで表されるIPv4アドレス。
2. IPV6_ADDRESS: IPv6 address represented in 128 bits.
2. IPv6_Address：128ビットで表されるIPv6アドレス。
3. UDP_PORT_LIST: list of UDP port specifications, represented as 16 bits per list entry.
3. udp_port_list：リストエントリごとに16ビットとして表されるUDPポート仕様のリスト。
4. TCP_PORT_LIST: list of TCP port specifications, represented as 16 bits per list entry.
4. TCP_PORT_LIST：リストエントリごとに16ビットとして表されるTCPポート仕様のリスト。
5. SPI: Security Parameter Index, represented in 32 bits.
5. SPI：32ビットで表されるセキュリティパラメーターインデックス。
OctetString: The OctetString contains the source address information.
OctetString：OctetStringには、ソースアドレス情報が含まれています。
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の少なくとも1つを含める必要があります。複数のアドレスが承認されている場合、複数のSOURCE_ADDR属性が含まれる場合があります。リクエストのソースアドレス（QoS NSLPリザーブなど）は、このセッション認証オブジェクトに含まれるSource_Addr属性の1つと一致する必要があります。
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の1つのインスタンスは、すべてのセッション認証オブジェクトに含まれる場合があります。せいぜい、サブタイプ4の1つのインスタンスは、すべてのセッション認証オブジェクトに含まれる場合があります。サブタイプ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.
ポート属性が指定されていない場合、すべてのポートは有効と見なされます。それ以外の場合、指定されたポートのみが使用が許可されています。すべてのソースアドレスとポートリストは、別のSOURCE_ADDR属性に含める必要があります。
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タイプは、特定の宛先アドレスやポートに対してリソース要求が許可されていることを確認するために、一部のシナリオで役立つ場合があります。
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> 4でなければなりません。
X-Type: DEST_ADDR
Xタイプ：DEST_ADDR
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は、セクション8、IANAの考慮事項で説明されているように、DEST_ADDRサブタイプのレジストリとして機能します。最初に、レジストリにはDEST_ADDRの次のサブタイプが含まれています。
1. IPV4_ADDRESS: IPv4 address represented in 32 bits.
1. IPv4_Address：32ビットで表されるIPv4アドレス。
2. IPV6_ADDRESS: IPv6 address represented in 128 bits.
2. IPv6_Address：128ビットで表されるIPv6アドレス。
3. UDP_PORT_LIST: list of UDP port specifications, represented as 16 bits per list entry.
3. udp_port_list：リストエントリごとに16ビットとして表されるUDPポート仕様のリスト。
4. TCP_PORT_LIST: list of TCP port specifications, represented as 16 bits per list entry.
4. TCP_PORT_LIST：リストエントリごとに16ビットとして表されるTCPポート仕様のリスト。
5. SPI: Security Parameter Index, represented in 32 bits.
5. SPI：32ビットで表されるセキュリティパラメーターインデックス。
OctetString: The OctetString contains the destination address specification.
OctetString：OctetStringには、宛先アドレスの仕様が含まれています。
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 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.
宛先アドレスが必要なシナリオ（セクション5を参照）では、すべてのセッション認証オブジェクトにサブタイプ1または2の少なくとも1つを含める必要があります。複数のアドレスが承認されている場合、複数のDEST_ADDR属性が含まれる場合があります。リソース予約データグラムの宛先アドレスフィールド（QOS NSLPリザーブなど）は、このセッション認証オブジェクトに含まれるDEST_ADDR属性の1つと一致する必要があります。
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の1つのインスタンスは、すべてのセッション認証オブジェクトに含まれる場合があります。せいぜい、サブタイプ4の1つのインスタンスは、すべてのセッション認証オブジェクトに含まれる場合があります。サブタイプ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.
start_timeは、承認されたセッションの開始時間を識別するために使用され、リプレイ攻撃を防ぐために使用できます。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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | X-Type | SubType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// OctetString ... //
+---------------------------------------------------------------+
Length: Length of the attribute, which MUST be > 4.
長さ：属性の長さ。これは> 4でなければなりません。
X-Type: START_TIME
Xタイプ：start_time
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:
start_timeの次のサブタイプが定義されています。IANAは、セクション8、IANAの考慮事項で説明されているように、start_timeサブタイプのレジストリとして機能します。最初に、レジストリにはstart_timeの次のサブタイプが含まれています。
1 NTP_TIMESTAMP: NTP Timestamp Format as defined in RFC 5905 [RFC5905].
1 NTP_TIMESTAMP：RFC 5905 [RFC5905]で定義されているNTPタイムスタンプ形式。
OctetString: The OctetString contains the start time.
OctetString：OctetStringには開始時間が含まれています。
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).
End_timeは、認定セッションの終了時間を識別するために使用され、使用が許可されているリソース（プリペイドセッションシナリオなど）を制限するために使用できます。
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タイプ：end_time
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:
END_TIMEの次のサブタイプが定義されています。IANAは、セクション8、IANAの考慮事項で説明されているように、end_timeサブタイプのレジストリとして機能します。最初に、レジストリにはend_timeの次のサブタイプが含まれています。
1 NTP_TIMESTAMP: NTP Timestamp Format as defined in RFC 5905 [RFC5905].
1 NTP_TIMESTAMP：RFC 5905 [RFC5905]で定義されているNTPタイムスタンプ形式。
OctetString: The OctetString contains the end time.
OctetString：OctetStringには終了時間が含まれています。
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属性には、認証_data属性に結果が与えられたキー付きハッシュ計算で使用されるNSLPオブジェクトタイプのリストが含まれています。これにより、NSLP PDUの整合性保護が可能になります。nslp_object_list属性がsession_authオブジェクトに含まれている場合、authentication_data属性も存在する必要があります。
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.
セッションID、NSLPID、およびMRIなどの基本的なNSIS輸送層プロトコル（NTLP） / NSLPオブジェクトは、常にHMACに含まれる必要があります。それらはNSLP自体内ではなく、GIST内でのみ運ばれているため、HMAC計算に提供する必要があります。たとえば、GIST APIを介して配信できます。ハッシュを計算する前に、再び[RFC5971]からネットワーク表現に正規化する必要があります。これらの値は、ハッシュ計算に含まれる他のNSLPオブジェクト値の前に、最初に（注文セッションID、NSLPID、MRIで）ハッシュする必要があります。
A summary of the NSLP_OBJECT_LIST attribute format is described below.
nslp_object_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
+---------------+---------------+---------------+---------------+
| 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_object_list
SubType: No sub-types for NSLP_OBJECT_LIST are currently defined. This field MUST be set to 0 and ignored upon reception.
サブタイプ：現在定義されているnslp_object_listのサブタイプはありません。このフィールドは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 = 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ビットあたり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ビットに設定されている必要があり、その内容は受信時に無視する必要があります。
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".
authentication_data属性には、session_authオブジェクトの認証データが含まれ、オブジェクト内のすべてのデータにauthentication_dataに署名します。Authentication_Data属性がSession_Authオブジェクトに含まれている場合、それはリストの最後の属性でなければなりません。認証データの計算に使用されるアルゴリズムは、auth_ent_idサブタイプフィールドに依存します。「Session_Authオブジェクトの整合性」というタイトルのセクション4を参照してください。
A summary of the AUTHENTICATION_DATA attribute format is described below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | X-Type | SubType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// OctetString ... //
+---------------------------------------------------------------+
Length: Length of the attribute, which MUST be > 4.
長さ：属性の長さ。これは> 4でなければなりません。
X-Type: AUTHENTICATION_DATA
Xタイプ：Authentication_Data
SubType: No sub-types for AUTHENTICATION_DATA are currently defined. This field MUST be set to 0 and ignored upon reception.
サブタイプ：現在定義されているauthentication_dataのサブタイプはありません。このフィールドは0に設定し、受信時に無視する必要があります。
OctetString: The OctetString contains the authentication data of the SESSION_AUTH.
OctetString：OctetStringには、session_authの認証データが含まれています。
This section describes how to ensure that the integrity of the SESSION_AUTH object is preserved.
このセクションでは、Session_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.
共有対称キー環境では、auth_ent_idはサブタイプでなければなりません：ipv4_address、ipv6_address、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) |
+---------------------------------------------------------------+
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.
キーメンテナンスはこのドキュメントの範囲外ですが、Session_Authの実装は、少なくともキーとそのパラメーターを手動で構成する機能を提供する必要があります。認証データの生成に使用されるキーは、auth_ent_idフィールドによって識別されます。特定のauth_ent_id値に対して複数のキーを構成することができるため、承認_dataフィールドの最初の32ビットは、適切なキーを識別するために使用されるキーIDでなければなりません。また、各キーは、有効な期間のライフタイムパラメーターと、キーで使用するアルゴリズムを指定する関連する暗号化アルゴリズムパラメーターで構成する必要があります。少なくとも、すべてのSession_Authの実装は、認証データを計算するために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.
定期的にキーを変更することをお勧めします。キーは、寿命が重複するように構成可能である必要があり、それによりキー間のスムーズな遷移を可能にします。2つのキー間の生涯の重複の中間点では、送信者は現在のキーを使用して、次の/長寿命キーに移行する必要があります。一方、受信者は、構成された寿命内で受信された識別キーを受け入れ、そうでないものを拒否するだけです。
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のユーザーがホストを要求するユーザーが、NSLPノード（Router）をリソース（ターゲットサービス）として使用するためにKerberos Key Distribution Center（KDC）からチケットを要求すると想定されています。NSLP要求ホスト（クライアント）は、NSLPエクスチェンジの前に、NSLPノードにKRB_CREDメッセージを個別に送信することにより、Kerberosを介してNSLPノードにチケットを提示できます。したがって、正確なIPアドレスは事前に知られていない場合がありますが、サービスの主な名前は事前にクライアントで知られている必要があります。名前が割り当てられ、クライアントが利用できるようにする方法は、実装固有です。その後、抽出された共通セッションキーを使用して、session_authオブジェクトのhmac_signedバリアントを使用できます。
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.
別のオプションは、session_authオブジェクトのauthentication_data部分の資格情報をカプセル化することです。この場合、auth_ent_idはサブタイプのkrb_principalでなければなりません。KRB_PRINCIPALフィールドは、認定エンティティの完全な資格のあるKerberosの主名として定義されています。Session_AuthオブジェクトのAuthentication_Data部分には、受信NSLPノードが抽出および検証する必要があるKRB_CREDメッセージが含まれています。タイプhmac_signedの2番目のセッション_Authオブジェクトは、以前のSession_Authオブジェクトを含むNSLPメッセージの整合性を保護する必要があります。最初のSession_Authオブジェクトに含まれるセッションキーは、HMAC計算に使用する必要があります。
An example of the Kerberos AUTHENTICATION_DATA object is shown below in Figure 2.
Kerberos Authentication_Dataオブジェクトの例を図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) |
+---------------------------------------------------------------+
Figure 2: Example of a Kerberos AUTHENTICATION_DATA Object
図2：Kerberos Authentication_Dataオブジェクトの例
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.
公開キー環境では、auth_ent_idはサブタイプのx509_v3_certまたはpgp_certでなければなりません。認証データは、承認エンティティの認証に使用されます。公開キーセッション_Authオブジェクトの2つの例を図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) |
+---------------------------------------------------------------+
Figure 3: Example of a SESSION_AUTH_OBJECT Using a PGP Certificate
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_v3_cert証明書を使用したsession_auth_objectの例
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 Verifier（PDPまたはRouter）には、デジタル証明書を確認する機能があります。
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.
承認エンティティは、その秘密鍵を使用して、Authentication_Dataを生成します。Authenticators（Router、PDP）は、承認エンティティの公開キー（デジタル証明書に保存）を使用して、オブジェクトを検証および認証します。
When the AUTH_ENT_ID is of type X509_V3_CERT, AUTHENTICATION_DATA MUST be generated by the authorizing entity following these steps:
auth_ent_idがタイプx509_v3_certの場合、承認_dataは、これらの手順に従って認可エンティティによって生成する必要があります。
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 defined in the crls field. The digest output is digitally signed following Section 8 of RFC 3447 [RFC3447], using the signer's private key.
o 署名されたデータは、RFC 5652 [RFC5652]で定義されているように構築されています。ダイジェストは、署名者固有のメッセージダイジェストアルゴリズムを使用して、コンテンツ（セクション6.1で指定）で計算されます。証明書フィールドには、各承認エンティティからのX.509 V3デジタル証明書のチェーンが含まれています。証明書の取り消しリストは、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:
auth_ent_idがタイプx509_v3_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（暗号化メッセージの構文）に署名されたDATAを解析することにより、ダイジェストアルゴリズムと消化データの長さを抽出します。
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:
auth_ent_idがタイプPGP_CERTの場合、認証_DATAは、これらの手順に従って承認エンティティによって生成される必要があります。
AUTHENTICATION_DATA contains a Signature Packet as defined in Section 5.2.3 of RFC 4880 [RFC4880]. In summary:
Authentication_Dataには、RFC 4880 [RFC4880]のセクション5.2.3で定義されている署名パケットが含まれています。要約すれば：
o Compute the hash of all data in the SESSION_AUTH object up to the AUTHENTICATION_DATA.
o Session_AuthオブジェクトのすべてのデータのハッシュをAuthentication_Dataに計算します。
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: o Validate the certificate.
auth_ent_idがタイプpgp_certの場合、これらの手順に従って、検証ネットワーク要素（PDPまたはルーター）によって検証を行う必要があります。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_signedのauth_ent_idを運ぶセッション_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 start_time：HMAC署名が計算されたときのタイムスタンプ。これは、リプレイ攻撃を防ぐために、順番に2つのメッセージで異なる必要があります。NTPタイムスタンプは現在、200ピコ秒の解像度を提供していますが、これで十分です。
o NSLP_OBJECT_LIST: this attribute lists all NSLP objects that are included in HMAC calculation.
o nslp_object_list：この属性には、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 Authentication_Data：この属性には、HMAC計算に使用されるKey-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 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計算に使用されるキーは、他の手段、たとえばKerberosチケットや事前に共有されたマニュアルのインストールなどによって安全に交換する必要があります。Authentication_DataのKey-IDは、適切なキーへの参照を許可し、内部の署名キーを定期的に変更することもできます。セッション。キーの長さは少なくとも64ビットでなければなりませんが、主要な有効期間中にブルートフォース攻撃から防御するために理想的には長いです。スケーラビリティの理由から、NSLPメッセージに署名するためにユーザーごとのキーを使用することが推奨されますが、セッションごとのキーを使用することも可能です。ユーザーごとのキーを使用すると、メッセージの信頼性を検証できるため、セッションベースのユーザーごとの許可の基礎が提供されます。共有キーを共有キーに定期的に変更することをお勧めします。HMAC計算で使用される実際のハッシュアルゴリズムは、「変換ID」フィールド（IKEV2レジストリ[RFC5996]の変換タイプ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 |
+---------------------------------------------------------------+
Figure 5: Example of a SESSION_AUTH_OBJECT That Provides Integrity Protection for NSLP Messages
図5：NSLPメッセージの整合性保護を提供するsession_auth_objectの例
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]は、データフロー（メディアフローなど）のリソース予約を許可するために必要な情報を輸送するためにSession_Authオブジェクトを利用できるフレームワークを説明します。RFC 3521は4つの異なるモデルを導入します。
1. The coupled model
1. 結合モデル
2. The associated model with one policy server
2. 1つのポリシーサーバーを備えた関連モデル
3. The associated model with two policy servers
3. 2つのポリシーサーバーを備えた関連モデル
4. The non-associated model
4. 非関連モデル
The fields that are required in a SESSION_AUTH object depend on which of the models is used.
Session_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です。承認エンティティによって使用され、リソース予約要求をセッションのセットアップ中に許可されたメディアと相関させます。エンドホストは信頼されていないと想定されているため、ポリシーサーバーは、session_idの整合性が輸送中に保持されることを確認するための措置を講じる必要があります。使用する正確なメカニズムとセッション_IDの形式は実装依存です。
In this model, the contents of the SESSION_AUTH object MUST include:
このモデルでは、session_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 セッション識別子-session_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 認可エンティティの身元-AUTH_ENT_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は、アイデンティティがドメイン内の正当なポリシーサーバーを指すかどうかを判断する手段がない場合があります。偽の認可エンティティへの認可要求のリダイレクトから保護するために、セッション_Authには以下も含める必要があります。
AUTHENTICATION_DATA. This authentication data is calculated over all other fields of the SESSION_AUTH object.
authentication_data。この認証データは、Session_Authオブジェクトの他のすべてのフィールドで計算されます。
The content of the SESSION_AUTH object is identical to the associated model with one policy server.
Session_Authオブジェクトのコンテンツは、1つのポリシーサーバーを持つ関連モデルと同一です。
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オブジェクトには、ポリシーサーバーが認可エンティティからリソースポリシーの決定を自律的に行うことを許可するのに十分な情報を含める必要があります。オブジェクトは、承認エンティティによるセッションに関する情報を使用して作成されます。session_authオブジェクトの情報には、以下を含める必要があります。
o Initiating party's IP address or Identity (e.g., FQDN) - SOURCE_ADDR X-Type
o 開始パーティのIPアドレスまたはID（例：FQDN）-Source_Addr X -Type
o Responding party's IP address or Identity (e.g., FQDN) - DEST_ADDR X-Type
o 応答者のIPアドレスまたはID（例：FQDN）-DEST_ADDR Xタイプ
o The authorization lifetime - START_TIME X-Type
o 承認ライフタイム-Start_Time Xタイプ
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 パブリックキースキームにおける承認エンティティの資格-AUTH_ENT_ID X-Type
o Authentication data used to prevent tampering with the SESSION_AUTH object - AUTHENTICATION_DATA X-Type
o セッションの改ざんを防ぐために使用される認証データ
Furthermore, the SESSION_AUTH object MAY contain:
さらに、session_authオブジェクトには以下が含まれる場合があります。
o The lifetime of (each of) the media stream(s) - END_TIME X-Type
o メディアストリーム（s）-End_Time X -Typeの（それぞれ）の寿命
o Initiating party's port number - SOURCE_ADDR X-Type
o 開始パーティーのポート番号-Source_Addr Xタイプ
o Responding party's port number - DEST_ADDR X-Type
o 応答者のポート番号-DEST_ADDR Xタイプ
All SESSION_AUTH fields MUST match with the resource request. If a field does not match, the request SHOULD be denied.
すべてのSession_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内のSESSION_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. 認証が必要な場合、Session_Authフィールドの長さ、タイプ、およびサブタイプフィールドを除く、Session_Authオブジェクト全体が構築されます。再生攻撃を防ぐために、メッセージにはstart_timeを含める必要があることに注意してください。認証アルゴリズムの出力と適切なヘッダー情報は、Session_AuthオブジェクトへのAuthentication_Data属性として追加されます。
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）がSession_Authオブジェクトを使用して応答メッセージを受信した場合、QNIはsession_Authオブジェクトを検査して、認証属性が認証エンティティによって変更されたことを確認する必要があります。また、QNIは、元の承認リクエストの変更を示さない応答メッセージにSession_Authオブジェクトを静かに受け入れる必要があります。
A QoS NSLP message is created as specified in [RFC5974].
QoS NSLPメッセージは、[RFC5974]で指定されているように作成されます。
1. The policy element received from the authorizing entity MUST be copied without modification into the SESSION_AUTH object.
1. 承認エンティティから受け取ったポリシー要素は、session_authオブジェクトに変更せずにコピーする必要があります。
2. The SESSION_AUTH object (containing the policy element) is inserted in the NSLP message in the appropriate place.
2. Session_Authオブジェクト（ポリシー要素を含む）は、適切な場所の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メッセージからsession_AuthオブジェクトとQoS関連オブジェクトを抽出し、それぞれの半径または直径メッセージを作成する必要があります。メッセージ処理とオブジェクト形式は、それぞれの半径または直径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からの応答が負の場合、要求を拒否する必要があります。半径の否定的な応答はアクセス拒否であり、直径はQOS-Authz-Answer（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_authオブジェクトからポリシー要素を取得します。auth_ent_idタイプフィールドとサブタイプフィールドを確認し、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署名：QNEまたはPDPは、Authentication_Data属性のKey-IDフィールドを使用して、そのフィールドがキーにしたテーブルを参照します。テーブルは、認証データの予想される長さと、認証エンティティの共有対称キーとともに使用する暗号化認証アルゴリズムを識別する必要があります。認証データの指定された長さが構成されたテーブルエントリと一致していることを確認し、NSLPメッセージの部分、つまりセッションID、MRI、NSLPID、およびNSLP_OBICL_LIST認証データにリストされている他のすべてのNSLP要素の整合性を検証します。Session_Authオブジェクトの内容として（セクション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：Authentication_Dataにカプセル化されたKRB_CREDメッセージ（セクション4.2を参照）が含まれている場合、KRB_CREDメッセージの整合性をKerberos自体内で検証できます。さらに、同じNSLPメッセージにhmac_signedを使用して別の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 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. 要求されたリソースが承認されたQOを超えないことを確認します。
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（半径または直径サーバーなど）がポリシー要素の検証に失敗した場合、それぞれの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]で定義されているように、info_specエラーコード「承認障害」を使用して応答メッセージを返す必要があります。QNEには、info_specオブジェクト値情報が含まれている場合があり、どのsession_auth属性がエラーを作成したかを示します。
This section presents processing rules for the NATFW NSLP [RFC5973].
このセクションでは、NATFW NSLP [RFC5973]の処理ルールを示します。
A NATFW NSLP message is created as specified in [RFC5973].
NATFW NSLPメッセージは、[RFC5973]で指定されているように作成されます。
1. The policy element received from the authorizing entity MUST be copied without modification into the SESSION_AUTH object.
1. 承認エンティティから受け取ったポリシー要素は、session_authオブジェクトに変更せずにコピーする必要があります。
2. The SESSION_AUTH object (containing the policy element) is inserted in the NATFW NSLP message in the appropriate place.
2. Session_Authオブジェクト（ポリシー要素を含む）は、適切な場所で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. ルーターがポリシーを認識している場合は、直径アプリケーションまたはRADIUSプロトコルを使用してPDPと通信する必要があります。AAAメッセージを作成するには、NSLPメッセージからNATFWポリシールールに関連するSession_Authオブジェクトとオブジェクトを抽出し、それぞれの半径または直径メッセージを作成する必要があります。メッセージ処理とオブジェクト形式は、それぞれの半径または直径プロトコルで説明されています。ルーターがポリシーを認識していない場合、ポリシーデータオブジェクトを無視し、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からの応答が負の場合、メッセージを拒否します。半径の負の応答はアクセス拒否であり、直径は結果コード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_authオブジェクトからポリシー要素を取得します。auth_ent_idタイプフィールドとサブタイプフィールドを確認し、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は、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 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署名：QNEまたはPDPは、Authentication_Data属性のKey-IDフィールドを使用して、そのフィールドがキーにしたテーブルを参照します。テーブルは、認証データの予想される長さと、認証エンティティの共有対称キーとともに使用する暗号化認証アルゴリズムを識別する必要があります。認証データの指定された長さが構成されたテーブルエントリと一致しており、NSLPメッセージの一部、つまりセッションID、MRI、NSLPID、およびNSLP_OBICL_LIST認証データおよび他のすべてのNSLP要素だけでなく、他のすべてのNSLP要素の整合性を検証することを確認します。Session_Authオブジェクトの内容（セクション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：Authentication_Dataにカプセル化されたKRB_CREDメッセージ（セクション4.2を参照）が含まれている場合、KRB_CREDメッセージの整合性をKerberos自体内で検証できます。さらに、同じNSLPメッセージにhmac_signedを使用して別のセッション_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（半径または直径サーバーなど）がSession_Authオブジェクトの検証に失敗した場合、それぞれのAAAドキュメントで説明されている適切なアクションを実行する必要があります。NATFW NSLPノードは、エラーコード「承認が失敗した」（0x02）を使用して、クラス「永続的な障害」（0x5）のエラーメッセージを返す必要があります。
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を参照）に設定されたauth_ent_id属性を含むsession_authオブジェクトを作成し、保護する必要があるすべてのNSLPオブジェクトに共有キーをハッシュし、nslp_object_listにリストします。Session_Authオブジェクト自体は、HMACによっても保護されています。session_authオブジェクトをNSLPメッセージに含めることにより、このNSLPメッセージの受信者は、HMACに適した共有キーがある場合、その完全性を確認できます。送信者への応答は、攻撃者が実際のNNに代わって不正な応答を送信するのを防ぐために、Session_Authオブジェクトを含めることにより保護する必要があります。
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_listにリストされているすべてのNSLP要素の整合性をチェックする必要があります。さらに、セクション3.2.7で指定されているように、セッションID、MRI、およびNSLPIDもHMAC計算に含める必要があります。HMACの計算に使用されるキーは、Authentication_Data属性に含まれるKey-IDによって参照されます。start_timeの提供されたタイムスタンプが十分に最近ではない場合、または計算されたHMACが認証_DATAで提供されるものと異なる場合、メッセージは静かに破棄する必要があり、エラーをローカルに記録する必要があります。
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.
このドキュメントは、サービスの盗難を防ぐためのセッション承認のメカニズムについて説明しています。考慮すべきセキュリティの問題には、リプレイ攻撃に対する保護、Session_Authオブジェクトの整合性、および認証アルゴリズムとキーの選択の3つのタイプがあります。
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_timeフィールドを含める必要があり、NNSとポリシーサーバーは、適切なクロック同期を確保するためにNTPをサポートする必要があります。適切なクロックの同期を確保できないと、異なるネットワークエンティティのクロックが同期していない可能性があるため、リプレイ攻撃が可能になります。開始時間は、リクエストが後で再生されていないことを確認するために使用されます。他のすべてのモデルでは、セッション_IDがポリシーサーバーによって使用され、リソース要求が承認されたセッションのレコードと正常に相関するようにします。Session_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.
2番目の問題である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.
共有対称キーが可能な環境では、セッション_Authオブジェクトサイズを厳密な最小限に保つために使用する必要があります。たとえば、ワイヤレスリンクを使用する場合。二次オプションは、高レベルのセキュリティと優れたスケーラビリティを提供する公開キーインフラストラクチャ（PKI）認証です。ただし、PKI認証には、Session_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オブジェクトは、セクション6.4で説明されているように、hmac_signed認証データを使用して、NSLPメッセージパーツの整合性を保護することもできます。
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.
たとえば、Authentication_Data（セクション4.1を参照）またはhmac_signed（セクション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.
session_auth_object 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タイプ）フィールドと、Xタイプあたり8ビットサブタイプフィールドを指定します。これは、IANAがNSLPセッション認証オブジェクトの対応するサブレジストリを作成し、維持します。
Initial values for the X-Type registry and the registration procedures according to [RFC5226] are as follows:
X型レジストリの初期値と[RFC5226]に従って登録手順は次のとおりです。
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
In the following, registration procedures and initial values for the SubType registries are specified.
以下では、サブタイプレジストリの登録手順と初期値が指定されています。
Sub-registry: AUTH_ENT_ID (X-Type 1) SubType values
サブレジストリ：auth_ent_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
Sub-registry: SOURCE_ADDR (X-Type 3) SubType values
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
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_Address 2 IPv6_Address 3 udp_port_list 4 tcp_port_list 5 spi 6-127
Sub-registry: START_TIME (X-Type 5) SubType values
サブレジストリ：start_time（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
Sub-registry: END_TIME (X-Type 6) SubType values
Registration Procedure: Specification Required
登録手順：仕様が必要です
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.
レビューとコメントを提供してくれたXioAming FuとLars Eggertに感謝します。また、Gen-ArtのレビュアーBen Campbell、およびSean TurnerとTim PolkがセキュリティエリアのTim Polkによっても役立つコメントが提供されました。このドキュメントは主に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、「Public-Key Cryptography Standards（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 5905、2010年6月。
[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, October 2010.
[RFC5971] Schulzrinne、H。およびR. Hancock、「Gist：General Internet Signaling Transport」、RFC 5971、2010年10月。
[RFC5973] Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", RFC 5973, October 2010.
[RFC5973] Stiemerling、M.、Tschofenig、H.、Aoun、C。、およびE. Davies、「Nat/Firewall NSIS Signaling Layer Protocol（NSLP）」、RFC 5973、2010年10月。
[RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling", RFC 5974, October 2010.
[RFC5974] MANER、J.、Karagiannis、G。、およびA. McDonald、「サービス品質シグナル伝達のためのNSISシグナリング層プロトコル（NSLP）」、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、「Internet Key Exchange Protocolバージョン2（IKEV2）」、RFC 5996、2010年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 3521、2003年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、「Uniform Resource Identifier（URI）：Generic Syntax」、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 4080、2005年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 4081、2005年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、「The Kerberos Network Authentication Service（V5）」、RFC 4120、2005年7月。
[RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, June 2006.
[RFC4514] Zeilenga、K。、「Lightweight Directory Access Protocol（LDAP）：著名な名前の文字列表現」、RFC 4514、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、「HMAC-SHA-256、HMAC-SHA-384、およびHMAC-SHA-512を使用してIPSECを使用して」、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 4880、2007年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 5280、2008年5月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652] Housley、R。、「暗号化メッセージ構文（CMS）」、STD 70、RFC 5652、2009年9月。
Authors' Addresses
著者のアドレス
Jukka Manner Aalto University Department of Communications and Networking (Comnet) P.O. Box 13000 Aalto FI-00076 Finland
Jukka Mather Aalto University of Communications and Networking（COMNET）P.O。Box 13000 Aalto FI-00076フィンランド
Phone: +358 9 470 22481
EMail: jukka.manner@tkk.fi
Martin Stiemerling Network Laboratories, NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany
Martin Stiemerling Network Laboratories、Nec Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115ドイツ
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 Nokia Siemens Networks Linnoitustie 6 Espoo 02600フィンランド
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
Roland Bless（編集者）Karlsruhe Institute of Techletion Institute of Telematics Zirkel 2、Building 20.20 P.O.Box 6980 Karlsruhe 76049ドイツ
Phone: +49 721 608 46413
EMail: roland.bless@kit.edu
URI: http://tm.kit.edu/~bless