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
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.
承認を処理するために、一般的なインターネットシグナリングトランスポート（GIST）のプロトコルに依拠することができるシグナリング（NSIS）枠組みの中で次のステップ内で指定されたレイヤのシグナリングプロトコル。依然として、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.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5981.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5981で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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）について説明します。この文脈での「ジェネリック」は、それがすべてNSLPsで使用可能であることを意味しています。スキームは、サードパーティのトークンに基づいています。信頼できるサードパーティがクライアントに認証トークンを提供し、ネットワーク要素によって情報の検証を可能にします。要求しているホストは、ネットワークリソース要求の検証を可能にするために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層のセッション認証を使用して、デフォルトの操作は、1つの許可ポリシーオブジェクトを追加することです。しかし、異なるネットワークからのエンドツーエンドシグナリングおよび要求承認をサポートするために、NSLPシグナリングセッションを開始するホストは、メッセージ内の複数のSESSION_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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [RFC2119]に記載されているように解釈されます。
The term "NSLP node" (NN) is used to refer to an NSIS node running an NSLP protocol that can make use of the authorization object discussed in this document. Currently, this node would run either the QoS NSLP [RFC5974] or the NAT/Firewall NSLP [RFC5973] service.
用語「NSLPノード」（NN）は、この文書で説明した権限オブジェクトを利用することができNSLPプロトコルを実行NSISノードを指すために使用されます。現在、このノードは、QoS NSLP [RFC5974]またはNAT /ファイアウォールNSLP [RFC5973]サービスのいずれかを実行します。
This section presents a new NSLP-layer object called session authorization (SESSION_AUTH). The SESSION_AUTH object can be used in the currently specified and future NSLP protocols.
このセクションでは、セッション認証（SESSION_AUTH）と呼ばれる新しいNSLP層のオブジェクトを提示します。 SESSION_AUTHオブジェクトは、現在指定されており、将来のNSLPプロトコルで使用することができます。
The authorization attributes follow the format and specification given in RFC3520 [RFC3520].
承認属性は、RFC3520 [RFC3520]で与えられた形式と仕様に従ってください。
The SESSION_AUTH object contains a list of fields that describe the session, along with other attributes. The object header follows the generic NSLP object header; therefore, it can be used together with any NSLP.
SESSION_AUTHオブジェクトは、他の属性と一緒に、セッションを記述するフィールドのリストが含まれています。オブジェクトヘッダは、一般的なNSLPオブジェクトヘッダに続きます。したがって、それはどんなNSLPと一緒に使用することができます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|B|r|r| Type |r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +
// Session Authorization Attribute List //
+ +
+---------------------------------------------------------------+
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).
Typeフィールドの値が共有NSLPオブジェクト型空間から来ています。 Lengthフィールドは、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のドキュメントを参照して、例えば、[RFC5974]、[RFC5973]）を同定されており、情報の目的のためにここに記載されています。
AB=00 ("Mandatory"): If the object is not understood, the entire message containing it MUST be rejected, and an error message sent back (usually of class/code "Protocol Error/Unknown object present").
ABは、= 00（「必須」）：オブジェクトが理解されていない場合、それを含むメッセージ全体を拒否しなければなりません、そして返送エラーメッセージ（通常クラス/コードの「プロトコルエラー/未知のオブジェクトの存在」）。
AB=01 ("Ignore"): If the object is not understood, it MUST be deleted, and the rest of the message processed as usual.
AB = 01（「無視」）：オブジェクトが理解されていない場合、それは削除され、通常どおり処理されたメッセージの残りなければなりません。
AB=10 ("Forward"): If the object is not understood, it MUST be retained unchanged in any message forwarded as a result of message processing, but not stored locally.
AB = 10（「フォワード」）：オブジェクトが理解されていない場合は、メッセージ処理の結果として転送されたメッセージで不変保持するが、ローカルに格納されないことを意味します。
AB=11 ("Refresh"): If the object is not understood, it should be incorporated into the locally stored signaling application state for this flow/session, forwarded in any resulting message, and also used in any refresh or repair message which is generated locally. This flag combination is not used by all NSLPs, e.g., it is not used in the NATFW NSLP.
AB = 11（「更新」）：オブジェクトが理解されていない場合、それは任意の結果のメッセージで転送され、このフロー/セッションのローカルに格納されたシグナリングアプリケーション状態に組み込まれ、また、任意のリフレッシュまたは修復メッセージに使用されるべきですローカルで生成されました。このフラグの組み合わせは全てNSLPsによって使用されていない、例えば、それが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オブジェクトが「10」に設定ABビットを持たなければなりません。 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:
セッション承認属性タイプ（X-タイプ）フィールドは1つのオクテットです。第8章、IANAの考慮事項で説明したようにIANAはX-タイプレジストリとして。この仕様は、次のX-タイプを使用しています。
1. AUTH_ENT_ID: The unique identifier of the entity that authorized the session.
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のSESSION-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は：シグナリングセッションエンドポイントのアドレス指定。
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.
長さ：属性の長さは、> 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ための以下のサブタイプが定義されています。セクション8、IANAの考慮事項に記載されているようにIANAはAUTH_ENT_IDサブタイプのレジストリとして作用します。最初は、レジストリはAUTH_ENT_IDの次のサブタイプが含まれています。
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：ASCII文字列として[RFC4514]で定義されるようにX.500識別名。
5. UNICODE_DN: X.500 Distinguished name as defined in [RFC4514] as a UTF-8 string.
5. UNICODE_DN：UTF-8文字列として[RFC4514]で定義されるようにX.500識別名。
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：[RFC4120]（どこ例えば、JOHNDOEの@）で定義されている@レルム名に続く主のASCII文字列で表される完全修飾Kerberosプリンシパル名。
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は：AUTHENTICATION_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パケットのIPソースアドレスに対応する、またはGIST MRI（メッセージルーティング情報）オブジェクトに含まれているそれぞれのソースまたはフローの宛先アドレスを、流れます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | X-Type | SubType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// OctetString ... //
+---------------------------------------------------------------+
Length: Length of the attribute, which MUST be > 4.
長さ：属性の長さは、> 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ための以下のサブタイプが定義されています。セクション8、IANAの考慮事項に記載されているようにIANAはSOURCE_ADDRサブタイプのレジストリとして作用します。最初は、レジストリはSOURCE_ADDRのため、次のサブタイプが含まれています。
3. UDP_PORT_LIST: list of UDP port specifications, represented as 16 bits per list entry.
3. UDP_PORT_LIST：UDPポート仕様のリストは、リストのエントリあたり16ビットで表現しました。
4. TCP_PORT_LIST: list of TCP port specifications, represented as 16 bits per list entry.
4. TCP_PORT_LIST：TCPポート仕様のリストは、リストのエントリあたり16ビットで表現しました。
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の少なくとも一方は、すべてのセッション権限オブジェクトに含まれなければなりません。複数のアドレスが許可されている場合、複数のSOURCE_ADDR属性が含まれるかもしれません。要求（例えば、のQoS NSLP RESERVE）の送信元アドレスは、このセッション権限オブジェクトに含まSOURCE_ADDR属性のいずれかと一致しなければなりません。
At most, one instance of sub-type 3 MAY be included in every Session Authorization Object. At most, one instance of sub-type 4 MAY be included in every Session Authorization Object. Inclusion of a sub-type 3 attribute does not prevent inclusion of a sub-type 4 attribute (i.e., both UDP and TCP ports may be authorized).
せいぜい、サブタイプ3の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.
何PORT属性が指定されていない場合は、すべてのポートが有効であると考えています。それ以外の場合は、必ず指定のポートが使用を許可されています。すべての送信元アドレスとポートリストは、個別の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でなければなりません。
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はのための次のサブタイプが定義されています。セクション8、IANAの考慮事項に記載されているようにIANAはdest_addrはサブタイプのレジストリとして作用します。最初は、レジストリはdest_addrはのために、次のサブタイプが含まれています。
3. UDP_PORT_LIST: list of UDP port specifications, represented as 16 bits per list entry.
3. UDP_PORT_LIST：UDPポート仕様のリストは、リストのエントリあたり16ビットで表現しました。
4. TCP_PORT_LIST: list of TCP port specifications, represented as 16 bits per list entry.
4. TCP_PORT_LIST：TCPポート仕様のリストは、リストのエントリあたり16ビットで表現しました。
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の少なくとも一方は、すべてのセッション権限オブジェクトに含まれなければなりません。複数のアドレスが許可されている場合、複数のdest_addrは属性が含まれるかもしれません。リソース予約データグラム（例えば、QoSのNSLP区）の宛先アドレスフィールドには、このセッションの権限オブジェクトに含まれるdest_addrは属性のいずれかと一致しなければなりません。
At most, one instance of sub-type 3 MAY be included in every Session Authorization Object. At most, one instance of sub-type 4 MAY be included in every Session Authorization Object. Inclusion of a sub-type 3 attribute does not prevent inclusion of a sub-type 4 attribute (i.e., both UDP and TCP ports may be authorized).
せいぜい、サブタイプ3の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.
何PORT属性が指定されていない場合は、すべてのポートが有効であると考えています。それ以外の場合は、必ず指定のポートが使用を許可されています。
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のための次のサブタイプが定義されています。セクション8、IANAの考慮事項に記載されているようにIANAはSTART_TIMEサブタイプのレジストリとして作用します。最初は、レジストリは、START_TIMEのために、次のサブタイプが含まれています。
1 NTP_TIMESTAMP: NTP Timestamp Format as defined in RFC 5905 [RFC5905].
RFC 5905 [RFC5905]で定義されているNTPタイムスタンプ形式：1 NTP_TIMESTAMP。
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のための次のサブタイプが定義されています。セクション8、IANAの考慮事項に記載されているようにIANAはEND_TIMEサブタイプのレジストリとして作用します。最初は、レジストリは、END_TIMEのために、次のサブタイプが含まれています。
1 NTP_TIMESTAMP: NTP Timestamp Format as defined in RFC 5905 [RFC5905].
RFC 5905 [RFC5905]で定義されているNTPタイムスタンプ形式：1 NTP_TIMESTAMP。
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属性は、その結果AUTHENTICATION_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オブジェクトタイプがすべて異なるNSLPs以上のユニークなので、これは任意のNSLPのために動作します。
Basic NSIS Transport Layer Protocol (NTLP) / NSLP objects like the session ID, the NSLPID, and the MRI MUST be always included in the HMAC. Since they are not carried within the NSLP itself, but only within GIST, they have to be provided for HMAC calculation, e.g., they can be delivered via the GIST API. They MUST be normalized to their network representation from [RFC5971] again before calculating the hash. These values MUST be hashed first (in the order session ID, NSLPID, MRI), before any other NSLP object values that are included in the hash computation.
基本NSISトランスポート層プロトコル（NTLP）/ NSLPは、セッションIDのようなNSLPIDオブジェクト、およびMRIは常にHMACに含めなければなりません。それらはNSLP自体の中で運ば、だけGIST内で、それらがHMAC計算のために提供されなければならないので、例えば、それらはGISTのAPIを介して送達することができます。彼らは再びハッシュを計算する前に[RFC5971]からのネットワーク表現に正規化されなければなりません。これらの値は、ハッシュ計算に含まれている任意の他のNSLPオブジェクトの値の前に、（順セッションID、NSLPID、MRIで）最初にハッシュされなければなりません。
A summary of the NSLP_OBJECT_LIST attribute format is described below.
NSLP_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-タイプ：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を。 N = 0が許可されています。その場合には、唯一のパディングフィールドが含まれています。
rsv: reserved bits; MUST be set to 0 and ignored upon reception.
RSV：予約ビット。 0に設定されて、レセプションで無視しなければなりません。
NSLP object type: the NSLP 12-bit object type identifier of the object that was included in the hash calculation. The NSLP object type values comprise only 12 bits, so four bits per type value are currently not used within the list. Depending on the number of signed objects, a corresponding padding word of 16 bits must be supplied.
NSLPオブジェクトタイプ：ハッシュ計算に含まれたオブジェクトのNSLP 12ビットのオブジェクトタイプ識別子。 NSLPオブジェクトタイプ値は、12ビットを含むので、型の値ごとに4ビットは、現在リスト内で使用されていません。署名されたオブジェクトの数に応じて、16ビットの対応するパディングワードが供給されなければなりません。
padding: padding MUST be added if the number of NSLP objects is even and MUST NOT be added if the number of NSLP objects is odd. If padding has to be applied, the padding field MUST be 16 bits set to 0, and its contents MUST be ignored upon reception.
パディング：NSLPオブジェクトの数が偶数とNSLPオブジェクトの数が奇数であれば追加しない場合、パディングを追加する必要があります。パディングが適用されなければならない場合、パディングフィールドが0に設定さ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-種類：認証データ
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.
IPV4_ADDRESS、IPV6_ADDRESS、FQDN、ASCII_DN、UNICODE_DN、又はURI：共有対称鍵環境では、AUTH_ENT_IDサブタイプでなければなりません。例えば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値のために構成されてもよいので、AUTHENTICATION_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.
ケルベロス[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ノード（ルータ）を使用するためのKerberosキー配布センター（KDC）からチケットを要求するものとします。 NSLP要求ホスト（クライアント）NSLP交換に独立しかし前NSLPノードにKRB_CREDメッセージを送信することによって、ケルベロス介し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の第SESSION_AUTHの目的は、従来SESSION_AUTHオブジェクトを含む、NSLPメッセージの完全性を保護しなければなりません。第SESSION_AUTHオブジェクトに含まれるセッション鍵はHMAC計算のために使用されなければなりません。
An example of the Kerberos AUTHENTICATION_DATA object is shown below in Figure 2.
ケルベロス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：ケルベロス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.
X509_V3_CERTまたはPGP_CERT：公開鍵の環境では、AUTH_ENT_IDは、サブタイプでなければなりません。認証データは、認可実体を認証するために使用されます。公開鍵SESSION_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
図3：PGP証明書を使用してSESSION_AUTH_OBJECTの例
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.
検証者（PDPまたはルータ）Oデジタル証明書を検証する能力を有します。
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を生成するために、その秘密鍵を使用しています。オーセンティケータ（ルータ、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である場合、AUTHENTICATION_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.
[RFC5652] RFC 5652で定義されるように、O署名されたデータが構成されています。ダイジェストは、署名者固有のメッセージダイジェストアルゴリズムと（セクション6.1で指定されるように）コンテンツに計算されます。証明書フィールドは、各認可エンティティからX.509 V3デジタル証明書のチェーンが含まれています。証明書失効リストは、CRLのフィールドで定義されています。ダイジェスト出力はデジタル署名者の秘密鍵を使用して、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].
RFC 5280のセクション6 [RFC5280]で定義されるようにO認証パス検証が行われます。
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.
X.509 v3証明書が検証されると、O、認可実体の公開鍵証明書から抽出することができます。
o Extract the digest algorithm and the length of the digested data by parsing the CMS (Cryptographic Message Syntax) signed-data.
O CMS（暗号メッセージ構文）署名されたデータを解析してダイジェストアルゴリズムおよび消化データの長さを抽出します。
o The recipient independently computes the message digest. This message digest and the signer's public key are used to verify the signature value.
O受信者は、独立して、メッセージダイジェストを計算します。このメッセージダイジェストと署名者の公開鍵は、署名値を検証するために使用されています。
This verification ensures integrity, non-repudiation, and data origin.
この検証は、完全性、否認防止、およびデータ起源を保証します。
When the AUTH_ENT_ID is of type PGP_CERT, AUTHENTICATION_DATA MUST be generated by the authorizing entity following these steps:
AUTH_ENT_IDがタイプPGP_CERTである場合、AUTHENTICATION_DATAは、以下の手順に従って認可実体によって生成されなければなりません。
AUTHENTICATION_DATA contains a Signature Packet as defined in Section 5.2.3 of RFC 4880 [RFC4880]. In summary:
RFC 4880 [RFC4880]のセクション5.2.3で定義されるようAUTHENTICATION_DATAは、署名パケットを含んでいます。要約すれば：
o Compute the hash of all data in the SESSION_AUTH object up to the AUTHENTICATION_DATA.
O AUTHENTICATION_DATAまでSESSION_AUTHオブジェクト内のすべてのデータのハッシュを計算します。
o The hash output is digitally signed following Section 8 of RFC 3447, using the signer's private key.
Oハッシュ出力は、デジタル署名者の秘密鍵を使用して、RFC 3447のセクション8以下の署名されています。
When the AUTH_ENT_ID is of type PGP_CERT, verification MUST be done by the verifying network element (PDP or router) following these steps: o Validate the certificate.
検証O証明：AUTH_ENT_IDはタイプPGP_CERTである場合、検証は以下の手順に従って検証ネットワーク要素（PDPまたはルータ）によって行われなければなりません。
o Once the PGP certificate is validated, the public key of the authorizing entity can be extracted from the certificate.
PGP証明書が検証されたらO、認可実体の公開鍵証明書から抽出することができます。
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を運ぶSESSION_AUTHオブジェクトは、NSLPメッセージの完全性保護として使用されています。 SESSION_AUTHオブジェクトは以下の属性を含まなければなりません：
o SOURCE_ADDR: the source address of the entity that created the HMAC
O SOURCE_ADDR：HMACを作成したエンティティの送信元アドレス
o START_TIME: the timestamp when the HMAC signature was calculated. This MUST be different for any two messages in sequence in order to prevent replay attacks. The NTP timestamp currently provides a resolution of 200 picoseconds, which should be sufficient.
入出力START_TIME：HMAC署名が算出したタイムスタンプ。これは、リプレイ攻撃を防ぐために、シーケンス内の任意の2つのメッセージのために異なっている必要があります。 NTPタイムスタンプは、現在、十分であるべきである200ピコ秒の分解能を提供します。
o NSLP_OBJECT_LIST: this attribute lists all NSLP objects that are included in HMAC calculation.
NSLP_OBJECT_LIST O：この属性は、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計算だけでなく、HMACデータ自体[RFC2104]のために使用されるキーIDが含まれています。
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.
AUTHENTICATION_DATAでHMAC計算のために使用されるキーなど、いくつかの他の手段によって安全に交換する必要があり、ケルベロスチケットまたは事前共有手動インストール等キーIDは、適切なキーへの参照を可能にし、また定期的に内鍵に署名変更しますセッション。キーの長さは、少なくとも64ビットである必要がありますが、それは、キーの有効期間中にブルートフォース攻撃を防御するために、理想的に長くなっています。スケーラビリティの理由から、NSLPメッセージに署名するために、ユーザーごとのキーを使用することが提案されていますが、セッションごとのキーを使用すると、セッションごとの鍵交換の費用で、あまりにも、可能です。ユーザごとの鍵は、メッセージの真正性の検証を可能にし、従って、セッションベースのユーザごとの認可のための基礎を提供します。定期的に共有されたキーにブルートフォースオフライン攻撃を実行することから盗聴を防止するために、共有キーを変更することをお勧めします。 HMAC計算に使用される実際のハッシュアルゴリズムは、（IKEv2のレジストリの変換タイプ3 [RFC5996]として与えられる）「IDを変換」フィールドによって指定されます。ハッシュアルゴリズムは、オブジェクトの作成者と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つの異なるモデルが導入されています。
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の整合性が輸送中に保存されていることを確保するための措置を取るべきです。使用する正確なメカニズムおよびSESSION_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.
AUTH_ENT_ID - 認可実体のアイデンティティ、O。この情報は、リソースの政策決定を勧誘するために使用されるべき認可エンティティ（ポリシーサーバ）を決定するために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は決定するための手段を持たないことがあります。偽の認可実体への認証要求のリダイレクトから保護するためには、SESSION_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
SOURCE_ADDR X-タイプ - パーティのIPアドレスまたはID（例えば、FQDN）を開始O
o Responding party's IP address or Identity (e.g., FQDN) - DEST_ADDR X-Type
dest_addrはX-タイプ - パーティのIPアドレスまたはID（例えば、FQDN）を受けて、O
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型
o The credentials of the authorizing entity in a public-key scheme - AUTH_ENT_ID X-Type
AUTH_ENT_ID X-タイプ - 公開鍵方式で認可実体の資格情報O
o Authentication data used to prevent tampering with the SESSION_AUTH object - AUTHENTICATION_DATA X-Type
SESSION_AUTHオブジェクトと改ざんを防止するために使用されるO認証データ - AUTHENTICATION_DATA X型
Furthermore, the SESSION_AUTH object MAY contain:
さらに、SESSION_AUTHオブジェクトが含まれる場合があります。
o The lifetime of (each of) the media stream(s) - END_TIME X-Type
END_TIME Xタイプ - メディアストリーム（複数可）（のそれぞれ）の寿命O
o Initiating party's port number - SOURCE_ADDR X-Type
SOURCE_ADDR X-タイプ - パーティのポート番号を開始O
o Responding party's port number - DEST_ADDR X-Type
dest_addrはX-タイプ - パーティのポート番号を対応O
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 QUERYとRESERVEメッセージネットワークリソースの照会操作を許可するため、およびリソース予約要求と共に使用することができます。
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].
[RFC5974]で指定されたQoS NSLPメッセージが作成されます。
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.（policy要素を含む）SESSION_AUTHオブジェクトが適切な場所にNSLPメッセージに挿入されています。
The QoS NSLP message is processed as specified in [RFC5974] with the following modifications.
以下のように変更して、[RFC5974]で指定されたQoS NSLPメッセージが処理されます。
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）の場合は、それはPDPと通信するためのDiameterのQoSアプリケーションまたはRADIUS QoSのプロトコルを使用すべき認識ポリシーです。 AAAメッセージを構築することは、QoS NSLPメッセージからSESSION_AUTHオブジェクトおよびQoS関連オブジェクトを抽出し、それぞれのRADIUSまたはDiameterメッセージを作ることが必要です。メッセージ処理及びオブジェクトフォーマットは、それぞれ、それぞれのRADIUSまたはDIAMETERのQoSプロトコルに記載されています。 QNEポリシー認識しない場合、それは、ポリシー・データ・オブジェクトを無視しNSLPメッセージの処理を継続します。
2. If the response from the PDP is negative, the request must be rejected. A negative response in RADIUS is an Access-Reject, and in Diameter is based on the 'DIAMETER_SUCCESS' value in the Result-Code AVP of the QoS-Authz-Answer (QAA) message. The QNE must construct and send a RESPONSE message with the status of the authorization failure as specified in [RFC5974].
2. PDPからの応答が負の場合、要求は拒否されなければなりません。 RADIUSで否定応答は、アクセスが拒否され、直径のQoSのauthz-回答（QAA）メッセージの結果、コードAVPの「DIAMETER_SUCCESS」値に基づいています。 QNEは、[RFC5974]で指定されている許可障害の状態に応答メッセージを構築し、送信する必要があります。
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タイプとサブタイプのフィールドをチェックして、アイデンティティタイプがサポートされていない場合はエラーを返します。
* 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.
* 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属性のキーIDフィールドを使用しています。テーブルは、認証データと認可実体の共有対称鍵の予想される長さと一緒に使用される暗号化認証アルゴリズムを識別すべきです。認証データの示す長さが設定テーブルエントリと一致することを確認し、同様にNSLP_OBJECT_LIST認証データに記載されているNSLPメッセージ、すなわち、セッションID、MRI、NSLPID、および他のすべての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.
*ケルベロス：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.要求されたリソースは、許可QoSを超えていないことを確認します。
When the PDP (e.g., a RADIUS or Diameter server) fails to verify the policy element, the appropriate actions described in the respective AAA document need to be taken.
PDP（例えば、RADIUSまたはDIAMETERサーバ）ポリシー要素を検証するために失敗した場合、それぞれのAAAの文書に記載され、適切なアクションが取られる必要があります。
The QNE node MUST return a RESPONSE message with the INFO_SPEC error code 'Authorization failure' as defined in the QoS NSLP specification [RFC5974]. The QNE MAY include an INFO_SPEC Object Value Info to indicate which SESSION_AUTH attribute created the error.
QNEノードは、QoS NSLP仕様[RFC5974]で定義されるようINFO_SPECエラーコード「承認失敗」で応答メッセージを返さなければなりません。 QNEはSESSION_AUTH属性がエラーを作成したかを示すためにINFO_SPECオブジェクト値情報を含むかもしれません。
This section presents processing rules for the NATFW NSLP [RFC5973].
このセクションでは、NATFW NSLP [RFC5973]のための処理規則を提示します。
A NATFW NSLP message is created as specified in [RFC5973].
[RFC5973]で指定されるようNATFW NSLPメッセージが作成されます。
1. The policy element received from the authorizing entity MUST be copied without modification into the SESSION_AUTH object.
1.認可実体から受け取ったポリシー要素はSESSION_AUTHオブジェクトに変更することなく、コピーしなければなりません。
2. The SESSION_AUTH object (containing the policy element) is inserted in the NATFW NSLP message in the appropriate place.
2.（policy要素を含む）SESSION_AUTHオブジェクトが適切な場所にNATFW NSLPメッセージに挿入されています。
The NATFW NSLP message is processed as specified in [RFC5973] with the following modifications.
以下のように変更して、[RFC5973]で指定されるようNATFW NSLPメッセージが処理されます。
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を、それがPDPとの通信にDiameterアプリケーションまたはRADIUSプロトコルを使用すべきです。 AAAメッセージを構築し、SESSION_AUTHオブジェクトとNSLPメッセージからNATFWポリシールールに関連するオブジェクトを抽出し、それぞれのRADIUSまたはDIAMETERメッセージを作ることが必要です。メッセージ処理及びオブジェクトフォーマットは、それぞれのRADIUSまたはDIAMETERプロトコルに記載されています。ルータがポリシー気付かない場合、それは、ポリシーデータオブジェクトを無視し、NSLPメッセージの処理を継続します。
2. Reject the message if the response from the PDP is negative. A negative response in RADIUS is an Access-Reject, and in Diameter is based on the 'DIAMETER_SUCCESS' value in the Result-Code AVP.
PDPからの応答が否定的である場合2.メッセージを拒否する。 RADIUSで否定応答は、アクセスが拒否され、直径が結果、コードAVPの「DIAMETER_SUCCESS」値に基づいています。
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タイプとサブタイプのフィールドをチェックして、アイデンティティタイプがサポートされていない場合はエラーを返します。
* 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.
* 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属性のキーIDフィールドを使用しています。テーブルは、認証データと認可実体の共有対称鍵の予想される長さと一緒に使用される暗号化認証アルゴリズムを識別すべきです。認証データの指示された長さが設定テーブルエントリと一致することを確認し、NSLPメッセージ、すなわち、セッションID、MRI、NSLPID、及びNSLP_OBJECT_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, 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.
*ケルベロス：AUTHENTICATION_DATAがカプセル化KRB_CREDメッセージ（参照セクション4.2）が含まれている場合、KRB_CREDメッセージの完全性は、Kerberos自体の中に検証することができます。また、同一のNSLPメッセージはHMAC_SIGNEDを使用して別のSESSION_AUTHオブジェクトが含まれている場合、ANは、後者は、上述のように、メッセージの完全性を検証するために使用することができます。
3. Once the identity of the authorizing entity and the validity of the service request have been established, the authorizing router/PDP MUST then consult its authorization policy in order to determine whether or not the specific request is authorized. To the extent to which these access control decisions require supplementary information, routers/PDPs MUST ensure that supplementary information is obtained securely.
3.認可実体のアイデンティティとサービス要求の妥当性が確立されたら、認可ルータ/ PDPは、特定の要求が許可されているかどうかを判断するために、その承認ポリシーを参照する必要があります。これらのアクセス制御の決定は、補足情報を要求する程度まで、ルータ/ PDPは補足情報が確実に得られることを確実にしなければなりません。
When the PDP (e.g., a RADIUS or Diameter server) fails to verify the SESSION_AUTH object, the appropriate actions described in the respective AAA document need to be taken. The NATFW NSLP node MUST return an error message of class 'Permanent failure' (0x5) with error code 'Authorization failed' (0x02).
PDP（例えば、RADIUSまたはDIAMETERサーバ）SESSION_AUTHオブジェクトを検証するために失敗した場合、それぞれのAAAの文書に記載され、適切なアクションが取られる必要があります。 NATFW NSLPノードはエラーコードでクラスの永久故障 '（0x5）のエラーメッセージを返さなければなりません（0×02）「認証に失敗しました」。
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に設定AUTH_ENT_ID属性（節参照4.4）を含み、保護する必要のあるすべてのNSLPのオブジェクトの上に共有キーをハッシュし、NSLP_OBJECT_LISTでそれらを示していますSESSION_AUTHオブジェクトを作成します。 SESSION_AUTHオブジェクト自体もHMACで保護されています。それはHMACに適した共有鍵を有する場合NSLPメッセージにSESSION_AUTHオブジェクトを含めることによって、このNSLPメッセージの受信機は、その完全性を検証することができます。送信者への応答は、実際の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.
SESSION_AUTHオブジェクトがHMAC_SIGNEDに設定AUTH_ENT_ID属性を持つものが存在する場合は、NSLP_OBJECT_LISTに記載されているすべてのNSLP要素の整合性はSESSION_AUTHオブジェクトの内容自体を含め、チェックする必要があります。さらに、セッションIDは、MRI、およびNSLPIDは、セクション3.2.7で指定されるように、あまりにも、HMAC計算に含めなければなりません。 HMACを計算するのに使用されるキーはAUTHENTICATION_DATA属性に含まれるキーIDによって参照されます。 START_TIMEで提供タイムスタンプが十分に最近ではないか、計算されたHMACがAUTHENTICATION_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フィールドを含まなければならない、としたNNだけでなく、ポリシーサーバは、適切なクロック同期を確保するためにNTPをサポートしなければなりません。異なるネットワークエンティティのクロックが同期していなくてもよいので、適切なクロック同期がリプレイ攻撃が可能になります確保に失敗しました。開始時間は、要求が後で再生されていないことを確認するために使用されます。他のすべてのモデルでは、SESSION_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.
第二の問題、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.
共有対称鍵が可能である環境では、それらは、無線リンクが使用される場合、例えば、厳しい最小限にSESSION_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-タイプ）フィールドだけでなく、IANAが作成したとNSLPセッション権限オブジェクトのためのサブレジストリに対応する維持する対象のX-タイプごとに8ビットのサブタイプのフィールドを、指定します。
Initial values for the X-Type registry and the registration procedures according to [RFC5226] are as follows:
次のように[RFC5226]に従って初期X型レジストリの値と登録手続きは以下のとおりです。
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-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
サブレジストリ：SOURCE_ADDR（X-3型）サブタイプ値
Registration Procedure: Specification Required
登録手順：仕様が必要
Registry:
SubType Description
-------- -------------
0 Reserved
1 IPV4_ADDRESS
2 IPV6_ADDRESS
3 UDP_PORT_LIST
4 TCP_PORT_LIST
5 SPI
6-127 Unassigned
128-255 Reserved for Private or Experimental Use
Sub-registry: DEST_ADDR (X-Type 4) SubType values
サブレジストリ：dest_addrは（X-タイプ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未割り当て128-255
Sub-registry: START_TIME (X-Type 5) SubType values
サブレジストリ：START_TIME（X-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
サブレジストリ：END_TIME（X-タイプ6）サブタイプ値
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フーとラースエッゲルトに感謝したいと思います。参考コメントも警備区域からのGen-ART投稿者ベン・キャンベル、だけでなく、ショーン・ターナーとティムポークによって提供されました。このドキュメントは、主にRFC 3520 [RFC3520]に基づいており、信用したがって、RFC 3520の作者に移行する - つまり、ルイ・ニコラ・ハマー、ブレット・コジンスキー、ビル・ゲージ、およびヒューShieh。この作品の一部は、BMBFの資金によるScaleNetプロジェクトのコンテキスト内でドイツテレコム研究所によって資金を供給されました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ジョンソン、J.とB. Kaliski、 "公開鍵暗号規格（PKCS）＃1：RSA暗号仕様バージョン2.1"、RFC 3447、2003年2月。
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[RFC5905]ミルズ、D.、マーティン、J.、バーバンク、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.ハンコック、 "GIST：一般的なインターネットシグナリング交通"、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.、アウン、C.、およびE.デイヴィス、 "NAT /ファイアウォールNSISシグナリング層プロトコル（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]マナー、J.、Karagiannis、G.、およびA.マクドナルド、 "NSISシグナリング層プロトコルクオリティ・オブ・サービスシグナリングのための（NSLP）"、RFC 5974、2010年10月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996]カウフマン、C.、ホフマン、P.、ニール、Y.、およびP. Eronen、 "インターネット鍵交換プロトコルバージョン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.、ベラー、M.、およびR.カネッティ、 "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]ハマー、L-N。、ゲージ、B.、コジンスキー、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]ハマー、L-N。、RFC 3521、2003年4月、ゲージ、B.、およびH. Shieh、 "メディア認証とセッションのセットアップのためのフレームワーク"。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, June 2005.
[RFC4080]ハンコック、R.、Karagiannis、G.、Loughney、J.、およびS.ヴァンデンボッシュ、 "シグナル伝達における次のステップ（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]ノイマン、C.、ゆう、T.、ハルトマン、S.、およびK.レイバーン、 "ケルベロスネットワーク認証サービス（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.、 "ライトウェイトディレクトリアクセスプロトコル（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]ケリー、S.、およびS.フランケル、 "HMAC-SHA-256を使用して、HMAC-SHA-384、およびIPSecとHMAC-SHA-512"、RFC 4868、2007年5月。
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
[RFC4880]カラス、J.、Donnerhacke、L.、フィニー、H.、ショー、D.、およびR.セイヤー、 "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]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネット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
コミュニケーションとネットワーキングのユッカマナーアールト大学学部（Comnet）P。ボックス13000アアルトFI-00076フィンランド
Phone: +358 9 470 22481 EMail: jukka.manner@tkk.fi
電話：+358 9 470 22481 Eメール：jukka.manner@tkk.fi
Martin Stiemerling Network Laboratories, NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany
マーティンStiemerlingネットワーク研究所、NECヨーロッパ社Kurfuersten-Anlageの36ハイデルベルクドイツ69115
Phone: +49 (0) 6221 4342 113 EMail: martin.stiemerling@neclab.eu URI: http://www.stiemerling.org
電話：+49（0）6221 4342 113電子メール：martin.stiemerling@neclab.eu URI：http://www.stiemerling.org
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
ハンネスTschofenigノキアシーメンスネットワークスLinnoitustie 6 02600エスポー、フィンランド
Phone: +358 (50) 4871445 EMail: Hannes.Tschofenig@gmx.net URI: http://www.tschofenig.priv.at
電話番号：+358（50）4871445 Eメール：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
ローランドは、午前20時20分私書箱の構築、テレマティクスZirkel 2の技術研究所の（編集者）カールスルーエ研究所を祝福しますボックス6980 76049カールスルーエドイツ
Phone: +49 721 608 46413 EMail: roland.bless@kit.edu URI: http://tm.kit.edu/~bless
電話：+49 721 608 46413 Eメール：roland.bless@kit.edu URI：http://tm.kit.edu/~bless