[要約] RFC 3520は、セッション認可ポリシー要素に関する標準化された仕様であり、セッション認可のための要素を定義しています。このRFCの目的は、セッション認可の一貫性と相互運用性を確保することです。
Network Working Group L-N. Hamer
Request for Comments: 3520 B. Gage
Category: Standards Track Nortel Networks
B. Kosinski
Invidi Technologies
H. Shieh
AT&T Wireless
April 2003
Session Authorization Policy Element
セッション認証ポリシー要素
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
This document describes the representation of a session authorization policy element for supporting policy-based per-session authorization and admission control. The goal of session authorization is to allow the exchange of information between network elements in order to authorize the use of resources for a service and to co-ordinate actions between the signaling and transport planes. This document describes how a process on a system authorizes the reservation of resources by a host and then provides that host with a session authorization policy element which can be inserted into a resource reservation protocol (e.g., the Resource ReSerVation Protocol (RSVP) PATH message) to facilitate proper and secure reservation of those resources within the network. We describe the encoding of session authorization information as a policy element conforming to the format of a Policy Data object (RFC 2750) and provide details relating to operations, processing rules and error scenarios.
このドキュメントでは、ポリシーベースのセッションごとの許可と入場管理をサポートするためのセッション認証ポリシー要素の表現について説明します。セッションの承認の目標は、サービスへのリソースの使用を承認し、シグナリングプレーンと輸送機の間の訴訟を調整するために、ネットワーク要素間の情報の交換を許可することです。このドキュメントでは、システム上のプロセスがホストによるリソースの予約を承認する方法について説明し、そのホストにリソース予約プロトコルに挿入できるセッション認証ポリシー要素を提供します（例：リソース予約プロトコル（RSVP）パスメッセージ）ネットワーク内のこれらのリソースの適切かつ安全な予約を促進するため。セッション認証情報のエンコードについては、ポリシーデータオブジェクト（RFC 2750）の形式に準拠したポリシー要素として説明し、操作、ルールの処理、エラーシナリオに関連する詳細を提供します。
Table of Contents
目次
1. Conventions used in this document..............................3
2. Introduction...................................................3
3. Policy Element for Session Authorization.......................4
3.1 Policy Data Object Format..................................4
3.2 Session Authorization Policy Element.......................4
3.3 Session Authorization Attributes...........................4
3.3.1 Authorizing Entity Identifier..........................6
3.3.2 Session Identifier.....................................7
3.3.3 Source Address.........................................7
3.3.4 Destination Address....................................9
3.3.5 Start time............................................10
3.3.6 End time..............................................11
3.3.7 Resources Authorized..................................11
3.3.8 Authentication data...................................12
4. Integrity of the AUTH_SESSION policy element..................13
4.1 Shared symmetric keys.....................................13
4.1.1 Operational Setting using shared symmetric keys.......13
4.2 Kerberos..................................................14
4.2.1. Operational Setting using Kerberos...................15
4.3 Public Key................................................16
4.3.1. Operational Setting for public key based
authentication.......................................16
4.3.1.1 X.509 V3 digital certificates.....................17
4.3.1.2 PGP digital certificates..........................17
5. Framework.....................................................18
5.1 The coupled model.........................................18
5.2 The associated model with one policy server...............18
5.3 The associated model with two policy servers..............19
5.4 The non-associated model..................................19
6. Message Processing Rules......................................20
6.1 Generation of the AUTH_SESSION by the authorizing entity..20
6.2 Message Generation (RSVP Host)............................20
6.3 Message Reception (RSVP-aware Router).....................20
6.4 Authorization (Router/PDP)................................21
7. Error Signaling...............................................22
8. IANA Considerations...........................................22
9. Security Considerations.......................................24
10. Acknowledgments..............................................24
11. Normative References.........................................25
12. Informative References.......................................27
13. Intellectual Property Statement..............................27
14. Contributors.................................................28
15. Authors' Addresses...........................................29
16. Full Copyright Statement.....................................30
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC-2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [RFC-2119]に記載されているように解釈される。
RSVP [RFC-2205] is one example of a resource reservation protocol that is used by a host to request specific services from the network for particular application data streams or flows. RSVP requests will generally result in resources being reserved in each router along the data path. RSVP allows users to obtain preferential access to network resources, under the control of an admission control mechanism. Such admission control is often based on user or application identity [RFC-3182], however, it is also valuable to provide the ability for per-session admission control.
RSVP [RFC-2205]は、特定のアプリケーションデータストリームまたはフローに対してネットワークから特定のサービスを要求するためにホストが使用するリソース予約プロトコルの一例です。RSVPリクエストは、通常、データパスに沿って各ルーターにリソースが予約されるようになります。RSVPを使用すると、ユーザーは、入場制御メカニズムの制御下で、ネットワークリソースへの優先アクセスを取得できます。このような入場制御は、多くの場合、ユーザーまたはアプリケーションのID [RFC-3182]に基づいていますが、セッションごとの入場管理能力を提供することも価値があります。
In order to allow for per-session admission control, it is necessary to provide a mechanism for ensuring use of resources by a host has been properly authorized before allowing the reservation of those resources. In order to meet this requirement, there must be information in the resource reservation message which may be used to verify the validity of the reservation request. This can be done by providing the host with a session authorization policy element which is inserted into the resource reservation message and verified by the network.
セッションごとの入場管理を許可するには、これらのリソースの留保を許可する前に、ホストによるリソースの使用を確実に保証するためのメカニズムを提供する必要があります。この要件を満たすためには、リソース予約メッセージには、予約要求の有効性を検証するために使用できる情報が必要です。これは、リソース予約メッセージに挿入され、ネットワークによって検証されたセッション認証ポリシー要素をホストに提供することで実行できます。
This document describes the session authorization policy element (AUTH_SESSION) used to convey information about the resources authorized for use by a session. The host must obtain an AUTH_SESSION element from an authorizing entity via a session signaling protocol such as SIP [RFC-3261]. The host then inserts the AUTH_SESSION element into the resource reservation message to allow verification of the network resource request; in the case of RSVP, this element MUST be encapsulated in the Policy Data object [RFC-2750] of an RSVP PATH message. Network elements verify the request and then process the resource reservation message based on admission policy.
このドキュメントでは、セッションで使用されることが許可されたリソースに関する情報を伝えるために使用されるセッション認証ポリシー要素（auth_session）について説明します。ホストは、SIP [RFC-3261]などのセッションシグナリングプロトコルを介して、承認エンティティからauth_session要素を取得する必要があります。ホストは次に、auth_session要素をリソース予約メッセージに挿入して、ネットワークリソースリクエストの検証を許可します。RSVPの場合、この要素は、RSVPパスメッセージのポリシーデータオブジェクト[RFC-2750]にカプセル化する必要があります。ネットワーク要素は、リクエストを確認し、入学ポリシーに基づいてリソース予約メッセージを処理します。
[RFC-3521] describes a framework in which a session authorization policy element may be utilized to contain information relevant to the network's decision to grant a reservation request.
[RFC-3521]は、セッション認定ポリシー要素を利用して、予約リクエストを付与するというネットワークの決定に関連する情報を含めることができるフレームワークを説明します。
The Session Authorization policy element conforms to the format of a POLICY_DATA object which contains policy information and is carried by policy based admission protocols such as RSVP. A detailed description of the POLICY_DATA object can be found in "RSVP Extensions for Policy Control" [RFC-2750].
セッション認証ポリシー要素は、ポリシー情報を含み、RSVPなどのポリシーベースの入場プロトコルによって実行されるpolicy_Dataオブジェクトの形式に準拠しています。policy_Dataオブジェクトの詳細な説明は、「ポリシー制御のためのRSVP拡張機能」[RFC-2750]に記載されています。
In this section we describe a policy element (PE) called session authorization (AUTH_SESSION). The AUTH_SESSION policy element contains a list of fields which describe the session, along with other attributes.
このセクションでは、セッション承認（auth_session）と呼ばれるポリシー要素（PE）について説明します。Auth_Sessionポリシー要素には、他の属性とともにセッションを説明するフィールドのリストが含まれています。
+-------------+-------------+-------------+-------------+
| Length | P-Type = AUTH_SESSION |
+-------------+-------------+-------------+-------------+
// Session Authorization Attribute List //
+-------------------------------------------------------+
Length: 16 bits The length of the policy element (including the Length and P-Type) is in number of octets (MUST be in multiples of 4) and indicates the end of the session authorization information block.
長さ：16ビットポリシー要素の長さ（長さとpタイプを含む）はオクテット数（4の倍数でなければなりません）であり、セッション認証情報ブロックの終了を示します。
P-Type: 16 bits (Session Authorization Type) AUTH_SESSION = 0x04 The Policy element type (P-type) of this element. The Internet Assigned Numbers Authority (IANA) acts as a registry for policy element types as described in [RFC-2750].
P-Type：16ビット（セッション認証タイプ）auth_session = 0x04この要素のポリシー要素タイプ（p-type）。インターネットが割り当てられた番号当局（IANA）は、[RFC-2750]で説明されているように、ポリシー要素タイプのレジストリとして機能します。
Session Authorization Attribute List: variable length The session authorization attribute list is a collection of objects which describes the session and provides other information necessary to verify the resource reservation request. An initial set of valid objects is described in Section 3.3.
セッション認証属性リスト：変動長セッション承認属性リストは、セッションを説明し、リソース予約要求を確認するために必要な他の情報を提供するオブジェクトのコレクションです。有効なオブジェクトの初期セットについては、セクション3.3で説明します。
A session authorization attribute may contain a variety of information and has both an attribute type and subtype. The attribute itself MUST be a multiple of 4 octets in length, and any attributes that are not a multiple of 4 octets long MUST be padded to a 4-octet boundary. All padding bytes MUST have a value of zero.
セッション認証属性にはさまざまな情報が含まれており、属性タイプとサブタイプの両方があります。属性自体は長さ4オクテットの倍数でなければならず、長さ4オクテットの倍数ではない属性は、4オクテットの境界にパッドでパッドで付ける必要があります。すべてのパディングバイトにはゼロの値が必要です。
+--------+--------+--------+--------+
| Length | X-Type |SubType |
+--------+--------+--------+--------+
| Value ...
+--------+--------+--------+--------+
Length: 16 bits The length field is two octets and indicates the actual length of the attribute (including Length, X-Type and SubType fields) in number of octets. The length does NOT include any bytes padding to the value field to make the attribute a multiple of 4 octets long.
長さ：16ビット長さのフィールドは2オクテットで、オクテット数で属性の実際の長さ（長さ、X型フィールド、サブタイプフィールドを含む）を示します。長さには、値フィールドへのバイトパディングは含まれておらず、属性を長さ4オクテットの倍数にします。
X-Type: 8 bits Session authorization attribute type (X-Type) field is one octet. IANA acts as a registry for X-Types as described in section 7, IANA Considerations. Initially, the registry contains the following X-Types:
Xタイプ：8ビットセッション承認属性タイプ（Xタイプ）フィールドは1オクテットです。IANAは、セクション7、IANAの考慮事項で説明されているように、Xタイプのレジストリとして機能します。最初に、レジストリには次のXタイプが含まれています。
1 AUTH_ENT_ID The unique identifier of the entity which authorized the session.
1 auth_ent_idセッションを承認したエンティティの一意の識別子。
2 SESSION_ID Unique identifier for this session.
2 Session_idこのセッションの一意の識別子。
3 SOURCE_ADDR Address specification for the session originator.
3 Source_Addrセッションオリジネーターのアドレス仕様。
4 DEST_ADDR Address specification for the session end-point.
4 DEST_ADDRアドレスセッションエンドポイントの仕様。
5 START_TIME The starting time for the session.
5 start_timeセッションの開始時間。
6 END_TIME The end time for the session.
6 end_timeセッションの終了時間。
7 RESOURCES The resources which the user is authorized to request.
7リソースユーザーが要求する権限を与えられているリソース。
8 AUTHENTICATION_DATA Authentication data of the session authorization policy element.
8 Authentication_Dataセッション認証ポリシー要素の認証データ。
SubType: 8 bits Session authorization attribute sub-type is one octet in length. The value of the SubType depends on the X-Type.
サブタイプ：8ビットセッション承認属性サブタイプの長さは1オクテットです。サブタイプの値はXタイプに依存します。
Value: variable length The attribute specific information.
値：変数属性固有の情報。
AUTH_ENT_ID is used to identify the entity which authorized the initial service request and generated the session authorization policy element. The AUTH_ENT_ID may be represented in various formats, and the SubType is used to define the format for the ID. The format for AUTH_ENT_ID is as follows:
auth_ent_idは、最初のサービス要求を承認し、セッション認証ポリシー要素を生成したエンティティを特定するために使用されます。auth_ent_idはさまざまな形式で表される場合があり、サブタイプはIDの形式を定義するために使用されます。auth_ent_idの形式は次のとおりです。
+-------+-------+-------+-------+
| Length |X-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+-------+
Length Length of the attribute, which MUST be > 4.
属性の長さの長さ。これは> 4でなければなりません。
X-Type AUTH_ENT_ID
x-type auth_ent_id
SubType The following sub-types for AUTH_ENT_ID are defined. IANA acts as a registry for AUTH_ENT_ID sub-types as described in section 7, IANA Considerations. Initially, the registry contains the following sub-types of AUTH_ENT_ID:
サブタイプauth_ent_idの次のサブタイプが定義されています。IANAは、セクション7、IANAの考慮事項で説明されているように、auth_ent_idサブタイプのレジストリとして機能します。最初に、レジストリには次のauth_ent_idのサブタイプが含まれています。
1 IPV4_ADDRESS IPv4 address represented in 32 bits
1 IPv4_Address IPv4アドレスは32ビットで表されます
2 IPV6_ADDRESS IPv6 address represented in 128 bits
2 IPv6_Address IPv6アドレスは、128ビットで表されます
3 FQDN Fully Qualified Domain Name as defined in RFC 1034 as an ASCII string.
3 fqdn ASCII文字列としてRFC 1034で定義されている完全に適格なドメイン名。
4 ASCII_DN X.500 Distinguished name as defined in RFC 2253 as an ASCII string.
4 ascii_dn x.500 RFC 2253でASCII文字列として定義されている著名な名前。
5 UNICODE_DN X.500 Distinguished name as defined in RFC 2253 as a UTF-8 string.
5 Unicode_dn x.500 rfc 2253でUTF-8文字列として定義されている著名な名前。
6 URI Universal Resource Identifier, as defined in RFC 2396.
6 URIユニバーサルリソース識別子、RFC 2396で定義されています。
7 KRB_PRINCIPAL Fully Qualified Kerberos Principal name represented by the ASCII string of a principal followed by the @ realm name as defined in RFC 1510 (e.g., principalX@realmY).
7 KRB_PRINCIPALは、RFC 1510で定義されているように、プリンシパルのASCII文字列に続いて @ Realm Name（例えば、PrincipalX @ Realmy）がそれに続く完全に資格のあるKerberosプリンシパル名。
8 X509_V3_CERT The Distinguished Name of the subject of the certificate as defined in RFC 2253 as a UTF-8 string.
8 X509_V3_CERT RFC 2253でUTF-8文字列として定義されている証明書の主題の著名な名前。
9 PGP_CERT The PGP digital certificate of the authorizing entity as defined in RFC 2440.
9 PGP_CERT RFC 2440で定義されているように、承認エンティティのPGPデジタル証明書。
OctetString Contains the authorizing entity identifier.
OctetStringには、承認エンティティ識別子が含まれています。
SESSION_ID is a unique identifier used by the authorizing entity to identify the request. It may be used for a number of purposes, including replay detection, or to correlate this request to a policy decision entry made by the authorizing entity. For example, the SESSION_ID can be based on simple sequence numbers or on a standard NTP timestamp.
session_idは、承認エンティティがリクエストを識別するために使用する一意の識別子です。リプレイの検出など、多くの目的に使用するか、このリクエストを認可エンティティによって行われたポリシー決定エントリと関連付けることができます。たとえば、Session_IDは、単純なシーケンス番号または標準のNTPタイムスタンプに基づくことができます。
+-------+-------+-------+-------+
| Length |X-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+-------+
Length Length of the attribute, which MUST be > 4.
属性の長さの長さ。これは> 4でなければなりません。
X-Type SESSION_ID
XタイプSESSION_ID
SubType No subtypes for SESSION_ID are currently defined; this field MUST be set to zero. The authorizing entity is the only network entity that needs to interpret the contents of the SESSION_ID therefore the contents and format are implementation dependent.
サブタイプsession_idのサブタイプは現在定義されていません。このフィールドはゼロに設定する必要があります。承認エンティティは、session_idの内容を解釈する必要がある唯一のネットワークエンティティです。したがって、コンテンツとフォーマットは実装依存です。
OctetString Contains the session identifier.
OctetStringにはセッション識別子が含まれています。
SOURCE_ADDR is used to identify the source address specification of the authorized session. This X-Type may be useful in some scenarios to make sure the resource request has been authorized for that particular source address and/or port.
source_addrは、承認されたセッションのソースアドレスの仕様を識別するために使用されます。このXタイプは、いくつかのシナリオで役立つ場合があり、リソース要求がその特定のソースアドレスやポートに対して許可されていることを確認します。
+-------+-------+-------+-------+
| Length |X-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+-------+
Length Length of the attribute, which MUST be > 4.
属性の長さの長さ。これは> 4でなければなりません。
X-Type SOURCE_ADDR
X-Type source_addr
SubType The following sub types for SOURCE_ADDR are defined. IANA acts as a registry for SOURCE_ADDR sub-types as described in section 7, IANA Considerations. Initially, the registry contains the following sub types for SOURCE_ADDR:
Subtype source_addrの次のサブタイプが定義されています。IANAは、セクション7、IANAの考慮事項で説明されているように、Source_Addrサブタイプのレジストリとして機能します。最初に、レジストリにはsource_addrの次のサブタイプが含まれています。
1 IPV4_ADDRESS IPv4 address represented in 32 bits
1 IPv4_Address IPv4アドレスは32ビットで表されます
2 IPV6_ADDRESS IPv6 address represented in 128 bits
2 IPv6_Address IPv6アドレスは、128ビットで表されます
3 UDP_PORT_LIST list of UDP port specifications, represented as 16 bits per list entry.
3 udp_port_listリストエントリごとに16ビットとして表されるUDPポート仕様のリスト。
4 TCP_PORT_LIST list of TCP port specifications, represented as 16 bits per list entry.
4 TCP_PORT_LISTリストエントリごとに16ビットとして表されるTCPポート仕様のリスト。
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 subtypes 1 through 2 (inclusive) MUST be included in every Session Authorization Data Policy Element. Multiple SOURCE_ADDR attributes MAY be included if multiple addresses have been authorized. The source address field of the resource reservation datagram (e.g., RSVP PATH) MUST match one of the SOURCE_ADDR attributes contained in this Session Authorization Data Policy Element.
ソースアドレスが必要なシナリオ（セクション5を参照）では、サブタイプ1〜2（包括的）の少なくとも1つをすべてのセッション認証データポリシー要素に含める必要があります。複数のアドレスが承認されている場合、複数のSOURCE_ADDR属性が含まれる場合があります。リソース予約データグラムのソースアドレスフィールド（RSVPパスなど）は、このセッション認証データポリシー要素に含まれるsource_addr属性の1つと一致する必要があります。
At most, one instance of subtype 3 MAY be included in every Session Authorization Data Policy Element. At most, one instance of subtype 4 MAY be included in every Session Authorization Data Policy Element. Inclusion of a subtype 3 attribute does not prevent inclusion of a subtype 4 attribute (i.e., both UDP and TCP ports may be authorized).
せいぜい、サブタイプ3の1つのインスタンスは、すべてのセッション認証データポリシー要素に含まれる場合があります。せいぜい、サブタイプ4の1つのインスタンスは、すべてのセッション認証データポリシー要素に含まれる場合があります。サブタイプ3属性を含めることは、サブタイプ4属性の包含を妨げません（つまり、UDPポートとTCPポートの両方が承認される場合があります）。
If no PORT attributes are specified, then all ports are considered valid; otherwise, only the specified ports are authorized for use.
ポート属性が指定されていない場合、すべてのポートは有効と見なされます。それ以外の場合、指定されたポートのみが使用が許可されています。
Every source address and port list must be included in a separate SOURCE_ADDR attribute.
すべてのソースアドレスとポートリストは、別のSOURCE_ADDR属性に含める必要があります。
DEST_ADDR is used to identify the destination address of the authorized session. This X-Type may be useful in some scenarios to make sure the resource request has been authorized for that particular destination address and/or port.
DEST_ADDRは、承認されたセッションの宛先アドレスを特定するために使用されます。このXタイプは、特定の宛先アドレスおよび/またはポートに対してリソース要求が承認されていることを確認するために、一部のシナリオで役立つ場合があります。
+-------+-------+-------+-------+
| Length |X-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+-------+
Length Length of the attribute, 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 sub-types as described in section 7, IANA Considerations. Initially, the registry contains the following sub types for DEST_ADDR:
サブタイプDEST_ADDRの次のサブタイプが定義されています。IANAは、セクション7、IANAの考慮事項で説明されているDEST_ADDRサブタイプのレジストリとして機能します。最初に、レジストリにはDEST_ADDRの次のサブタイプが含まれています。
1 IPV4_ADDRESS IPv4 address represented in 32 bits
1 IPv4_Address IPv4アドレスは32ビットで表されます
2 IPV6_ADDRESS IPv6 address represented in 128 bits
2 IPv6_Address IPv6アドレスは、128ビットで表されます
3 UDP_PORT_LIST list of UDP port specifications, represented as 16 bits per list entry.
3 udp_port_listリストエントリごとに16ビットとして表されるUDPポート仕様のリスト。
4 TCP_PORT_LIST list of TCP port specifications, represented as 16 bits per list entry.
4 TCP_PORT_LISTリストエントリごとに16ビットとして表されるTCPポート仕様のリスト。
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 subtypes 1 through 2 (inclusive) MUST be included in every Session Authorization Data Policy Element. Multiple DEST_ADDR attributes MAY be included if multiple addresses have been authorized. The destination address field of the resource reservation datagram (e.g., RSVP PATH) MUST match one of the DEST_ADDR attributes contained in this Session Authorization Data Policy Element.
宛先アドレスが必要なシナリオ（セクション5を参照）では、サブタイプ1〜2（包括的）の少なくとも1つをすべてのセッション認証データポリシー要素に含める必要があります。複数のアドレスが承認されている場合、複数のDEST_ADDR属性が含まれる場合があります。リソース予約データグラムの宛先アドレスフィールド（RSVPパスなど）は、このセッション認証データポリシー要素に含まれるDEST_ADDR属性の1つと一致する必要があります。
At most, one instance of subtype 3 MAY be included in every Session Authorization Data Policy Element. At most, one instance of subtype 4 MAY be included in every Session Authorization Data Policy Element. Inclusion of a subtype 3 attribute does not prevent inclusion of a subtype 4 attribute (i.e., both UDP and TCP ports may be authorized).
せいぜい、サブタイプ3の1つのインスタンスは、すべてのセッション認証データポリシー要素に含まれる場合があります。せいぜい、サブタイプ4の1つのインスタンスは、すべてのセッション認証データポリシー要素に含まれる場合があります。サブタイプ3属性を含めることは、サブタイプ4属性の包含を妨げません（つまり、UDPポートとTCPポートの両方が承認される場合があります）。
If no PORT attributes are specified, then all ports are considered valid; otherwise, only the specified ports are authorized for use.
ポート属性が指定されていない場合、すべてのポートは有効と見なされます。それ以外の場合、指定されたポートのみが使用が許可されています。
Every destination address and port list must be included in a separate DEST_ADDR attribute.
すべての宛先アドレスとポートリストは、別のDEST_ADDR属性に含める必要があります。
START_TIME is used to identify the start time of the authorized session and can be used to prevent replay attacks. If the AUTH_SESSION policy element is presented in a resource request, the network SHOULD reject the request if it is not received within a few seconds of the start time specified.
start_timeは、承認されたセッションの開始時間を識別するために使用され、リプレイ攻撃を防ぐために使用できます。Auth_Sessionポリシー要素がリソースリクエストで提示された場合、ネットワークは、指定された開始時間の数秒以内に受信されない場合、リクエストを拒否する必要があります。
+-------+-------+-------+-------+
| Length |X-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+-------+
Length Length of the attribute, which MUST be > 4.
属性の長さの長さ。これは> 4でなければなりません。
X-Type START_TIME
X-Type start_time
SubType The following sub types for START_TIME are defined. IANA acts as a registry for START_TIME sub-types as described in section 7, IANA Considerations. Initially, the registry contains the following sub types for START_TIME:
Subtype start_timeの次のサブタイプが定義されています。IANAは、セクション7、IANAの考慮事項で説明されているように、start_timeサブタイプのレジストリとして機能します。最初に、レジストリにはstart_timeの次のサブタイプが含まれています。
1 NTP_TIMESTAMP NTP Timestamp Format as defined in RFC 1305.
1 NTP_TIMESTAMP NTPタイムスタンプ形式RFC 1305で定義されています。
OctetString The OctetString contains the start time.
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は、認定セッションの終了時間を識別するために使用され、使用が許可されているリソース（プリペイドセッションシナリオなど）を制限するために使用できます。
+-------+-------+-------+-------+
| 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 types for END_TIME are defined. IANA acts as a registry for END_TIME sub-types as described in section 7, IANA Considerations. Initially, the registry contains the following sub types for END_TIME:
サブタイプend_timeの次のサブタイプが定義されています。IANAは、セクション7、IANAの考慮事項で説明されているように、end_timeサブタイプのレジストリとして機能します。最初に、レジストリにはend_timeの次のサブタイプが含まれています。
1 NTP_TIMESTAMP NTP Timestamp Format as defined in RFC 1305.
1 NTP_TIMESTAMP NTPタイムスタンプ形式RFC 1305で定義されています。
OctetString The OctetString contains the end time.
OctetStringのオクテットストリングには、終了時間が含まれています。
RESOURCES is used to define the characteristics of the authorized session. This X-Type may be useful in some scenarios to specify the specific resources authorized to ensure the request fits the authorized specifications.
リソースは、承認されたセッションの特性を定義するために使用されます。このXタイプは、リクエストが承認された仕様に適合するように承認された特定のリソースを指定するために、一部のシナリオで役立つ場合があります。
+-------+-------+-------+-------+
| Length |X-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+-------+
Length Length of the attribute, which MUST be > 4.
属性の長さの長さ。これは> 4でなければなりません。
X-Type RESOURCES
Xタイプのリソース
SubType The following sub-types for RESOURCES are defined. IANA acts as a registry for RESOURCES sub-types as described in section 7, IANA Considerations. Initially, the registry contains the following sub types for RESOURCES:
サブタイプリソースの次のサブタイプが定義されています。IANAは、セクション7、IANAの考慮事項で説明されているリソースサブタイプのレジストリとして機能します。当初、レジストリには、リソースの次のサブタイプが含まれています。
1 BANDWIDTH Maximum bandwidth (kbps) authorized.
1帯域幅の最大帯域幅（kbps）が承認されています。
2 FLOW_SPEC Flow spec specification as defined in RFC 2205.
RFC 2205で定義されているFlow_Specフロー仕様仕様。
3 SDP SDP Media Descriptor as defined in RFC 2327.
3 SDP SDPメディア記述子RFC 2327で定義されています。
4 DSCP Differentiated services codepoint as defined in RFC 2474.
RFC 2474で定義されているDSCP差別化サービスCodePoint。
OctetString The OctetString contains the resources specification.
OctetStringのオクテットストリングには、リソース仕様が含まれています。
In scenarios where a resource specification is required (see Section 5), at least one of the subtypes 1 through 4 (inclusive) MUST be included in every Session Authorization Data Policy Element. Multiple RESOURCE attributes MAY be included if multiple types of resources have been authorized (e.g., DSCP and BANDWIDTH).
リソース仕様が必要なシナリオ（セクション5を参照）では、サブタイプ1〜4（包括的）の少なくとも1つをすべてのセッション認証データポリシー要素に含める必要があります。複数のタイプのリソースが承認されている場合（DSCPや帯域幅など）、複数のリソース属性が含まれる場合があります。
The AUTHENTICATION_DATA attribute contains the authentication data of the AUTH_SESSION policy element and signs all the data in the policy element up to the AUTHENTICATION_DATA. If the AUTHENTICATION_DATA attribute has been included in the AUTH_SESSION policy element, it MUST be the last attribute in the list. The algorithm used to compute the authentication data depends on the AUTH_ENT_ID SubType field. See Section 4 entitled Integrity of the AUTH_SESSION policy element.
Authentication_Data属性には、auth_sessionポリシー要素の認証データが含まれており、ポリシー要素のすべてのデータにauthentication_dataに署名します。Authentication_Data属性がauth_sessionポリシー要素に含まれている場合、それはリストの最後の属性でなければなりません。認証データの計算に使用されるアルゴリズムは、auth_ent_idサブタイプフィールドに依存します。auth_sessionポリシー要素の整合性というタイトルのセクション4を参照してください。
A summary of AUTHENTICATION_DATA attribute format is described below.
authentication_data属性形式の概要については、以下に説明します。
+-------+-------+-------+-------+
| Length |X-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+-------+
Length Length of the attribute, which MUST be > 4.
属性の長さの長さ。これは> 4でなければなりません。
X-Type AUTHENTICATION_DATA
X-Type Authentication_Data
SubType No sub types for AUTHENTICATION_DATA are currently defined. This field MUST be set to 0.
SubType Authentication_Dataのサブタイプは現在定義されていません。このフィールドは0に設定する必要があります。
OctetString The OctetString contains the authentication data of the AUTH_SESSION.
OctetString OctetStringには、auth_sessionの認証データが含まれています。
This section describes how to ensure the integrity of the policy element is preserved.
このセクションでは、ポリシー要素の完全性が保持される方法について説明します。
In shared symmetric key environments, the AUTH_ENT_ID MUST be of subtypes: IPV4_ADDRESS, IPV6_ADDRESS, FQDN, ASCII_DN, UNICODE_DN or URI. An example AUTH_SESSION policy element is shown below.
共有対称キー環境では、auth_ent_idはサブタイプでなければなりません：ipv4_address、ipv6_address、fqdn、ascii_dn、unicode_dnまたはuri。auth_sessionポリシー要素の例を以下に示します。
+--------------+--------------+--------------+--------------+
| Length | P-type = AUTH_SESSION |
+--------------+--------------+--------------+--------------+
| Length |SESSION_ID | zero |
+--------------+--------------+--------------+--------------+
| OctetString (The session identifier) ...
+--------------+--------------+--------------+--------------+
| Length | AUTH_ENT_ID | IPV4_ADDRESS |
+--------------+--------------+--------------+--------------+
| OctetString (The authorizing entity's Identifier) ...
+--------------+--------------+--------------+--------------+
| Length |AUTH DATA. | zero |
+--------------+--------------+--------------+--------------+
| KEY_ID |
+--------------+--------------+--------------+--------------+
| OctetString (Authentication data) ...
+--------------+--------------+--------------+--------------+
This assumes both the Authorizing Entity and the Network router/PDP are provisioned with shared symmetric keys and with policies detailing which algorithm to be used for computing the authentication data along with the expected length of the authentication data for that particular algorithm.
これは、認証エンティティとネットワークルーター/PDPの両方に、共有対称キーと、その特定のアルゴリズムの認証データの予想される長さとともに、認証データの計算に使用されるアルゴリズムの詳細なポリシーでプロビジョニングされていることを想定しています。
Key maintenance is outside the scope of this document, but AUTH_SESSION implementations MUST at least provide the ability to manually configure keys and their parameters locally. The key used to produce the authentication data is identified by the AUTH_ENT_ID field. Since multiple keys may be configured for a particular AUTH_ENT_ID value, the first 32 bits of the AUTH_DATA field MUST be a key ID to be used to identify the appropriate key. Each key must also be configured with lifetime parameters for the time period within which it is valid as well as an associated cryptographic algorithm parameter specifying the algorithm to be used with the key. At a minimum, all AUTH_SESSION implementations MUST support the HMAC-MD5-128 [RFC-2104], [RFC-1321] cryptographic algorithm for computing the authentication data. New algorithms may be added by the IETF standards process.
キーメンテナンスはこのドキュメントの範囲外ですが、auth_sessionの実装は、少なくともキーとそのパラメーターをローカルで手動で構成する機能を提供する必要があります。認証データの生成に使用されるキーは、auth_ent_idフィールドによって識別されます。特定のauth_ent_id値に対して複数のキーを構成できるため、auth_dataフィールドの最初の32ビットは、適切なキーを識別するために使用するためのキーIDでなければなりません。また、各キーは、有効な期間のライフタイムパラメーターと、キーで使用するアルゴリズムを指定する関連する暗号化アルゴリズムパラメーターで構成する必要があります。少なくとも、すべてのauth_session実装は、認証データを計算するために、HMAC-MD5-128 [RFC-2104]、[RFC-1321]暗号化アルゴリズムをサポートする必要があります。IETF標準プロセスによって新しいアルゴリズムが追加される場合があります。
It is good practice to regularly change keys. Keys MUST be configurable such that their lifetimes overlap allowing smooth transitions between keys. At the midpoint of the lifetime overlap between two keys, senders should transition from using the current key to the next/longer-lived key. Meanwhile, receivers simply accept any identified key received within its configured lifetime and reject those that are not.
定期的にキーを変更することをお勧めします。キーは、寿命が重複してキー間のスムーズな遷移を可能にするように構成可能でなければなりません。生涯の2つのキー間の重複の中間点では、送信者は現在のキーを使用してから次/長寿命キーに移行する必要があります。一方、受信者は、構成された寿命内で受信された識別されたキーを受け入れ、そうでないものを拒否するだけです。
In a Kerberos environment, the AUTH_ENT_ID MUST be of the subtype KRB_PRINCIPAL. The KRB_PRINCIPAL field is defined as the Fully Qualified Kerberos Principal name of the authorizing entity. Kerberos [RFC-1510] authentication uses a trusted third party (the Kerberos Distribution Center - KDC) to provide for authentication of the AUTH_SESSION to a network server. It is assumed that a KDC is present and both host and verifier of authentication information (authorizing entity and router/PDP) implement Kerberos authentication.
Kerberos環境では、auth_ent_idはサブタイプKRB_PRINCIPALでなければなりません。KRB_PRINCIPALフィールドは、認定エンティティの完全な資格のあるKerberosの主名として定義されています。Kerberos [RFC -1510]認証は、信頼できるサードパーティ（Kerberos Distribution Center -KDC）を使用して、ネットワークサーバーへのauth_sessionの認証を提供します。KDCが存在し、認証情報のホストと検証者（承認エンティティとルーター/PDP）の両方がKerberos認証を実装すると想定されています。
An example of the Kerberos AUTH_DATA policy element is shown below.
Kerberos auth_dataポリシー要素の例を以下に示します。
+--------------+--------------+--------------+--------------+
| Length | P-type = AUTH_SESSION |
+--------------+--------------+--------------+--------------+
| Length |SESSION_ID | zero |
+--------------+--------------+--------------+--------------+
| OctetString (The session identifier) ...
+--------------+--------------+--------------+--------------+
| Length | AUTH_ENT_ID | KERB_P. |
+--------------+--------------+--------------+--------------+
| OctetString (The principal@realm name) ...
+--------------+--------------+--------------+--------------+
An authorizing entity is configured to construct the AUTH_SESSION policy element that designates use of the Kerberos authentication method (KRB_PRINCIPAL) as defined in RFC 1510. Upon reception of the resource reservation request, the router/PDP contacts the local KDC, with a KRB_AS_REQ message, to request credentials for the authorizing entity (principal@realm). In this request, the client (router/PDP) sends (in cleartext) its own identity and the identity of the server (the authorizing entity taken from the AUTH_ENT_ID field) for which it is requesting credentials. The local KDC responds with these credentials in a KRB_AS_REP message, encrypted in the client's key. The credentials consist of 1) a "ticket" for the server and 2) a temporary encryption key (often called a "session key"). The router/PDP uses the ticket to access the authorizing entity with a KRB_AP_REQ message. The session key (now shared by the router/PDP and the authorizing entity) is used to authenticate the router/PDP, and is used to authenticate the authorizing entity. The session key is an encryption key and is also used to encrypt further communication between the two parties. The authorizing entity responds by sending a concatenated message of a KRB_AP_REP and a KRB_SAFE. The KRB_AP_REP is used to authenticate the authorizing entity. The KRB_SAFE message contains the authentication data in the safe-body field. The authentication data must be either a 16 byte MD5 hash or 20 byte SHA-1 hash of all data in the AUTH_SESSION policy element up to the AUTHENTICATION_DATA (note that when using Kerberos the AUTH_SESSION PE should not include AUTHENTICATION_DATA as this is sent in the KRB_SAFE message). The router/PDP independently computes the hash, and compares it with the received hash in the user-data field of the KRB-SAFE-BODY [RFC-1510].
承認エンティティは、RFC 1510で定義されているように、Kerberos認証方法（krb_principal）の使用を指定するauth_sessionポリシー要素を構築するように構成されています。リソース予約リクエストを受信すると、ルーター/PDPはローカルKDCにKRB_AS_REQメッセージと接触します。承認エンティティ（プリンシパル@realm）の資格情報を要求する。このリクエストでは、クライアント（Router/PDP）は（ClearTextで）独自のIDと、資格情報を要求しているサーバー（Auth_ent_idフィールドから取られた承認エンティティ）のIDを送信します。ローカルKDCは、クライアントのキーで暗号化されたKRB_AS_REPメッセージでこれらの資格情報を使用して応答します。資格情報は、1）サーバーの「チケット」と2）一時的な暗号化キー（「セッションキー」と呼ばれることが多い）で構成されています。Router/PDPはチケットを使用して、KRB_AP_REQメッセージを使用して認証エンティティにアクセスします。セッションキー（現在はルーター/PDPと認可エンティティが共有しています）は、ルーター/PDPの認証に使用され、承認エンティティの認証に使用されます。セッションキーは暗号化キーであり、2つの関係者間のさらなる通信を暗号化するためにも使用されます。認可エンティティは、KRB_AP_REPとKRB_SAFEの連結メッセージを送信することにより対応します。KRB_AP_REPは、承認エンティティを認証するために使用されます。KRB_SAFEメッセージには、セーフボディフィールドの認証データが含まれています。認証データは、Auth_Sessionポリシー要素のすべてのデータの16バイトMD5ハッシュまたは20バイトSHA-1ハッシュのいずれかでなければなりません（kerberosを使用する場合、auth_session PEはkrb_safeで送信されるため、auth_session peが認証_dataを含めるべきではないことに注意してくださいメッセージ）。ルーター/PDPはハッシュを個別に計算し、KRB-Safe-body [RFC-1510]のユーザーデータフィールドで受信したハッシュと比較します。
At a minimum, all AUTH_SESSION implementations using Kerberos MUST support the Kerberos des-cbc-md5 encryption type [RFC-1510] (for encrypted data in tickets and Kerberos messages) and the Kerberos rsa-md5-des checksum type [RFC-1510] (for the KRB_SAFE checksum) checksum. New algorithms may be added by the IETF standards process. Triple-DES encryption is supported in many Kerberos implementations (although not specified in [RFC-1510]), and SHOULD be used over single DES.
少なくとも、Kerberosを使用したすべてのauth_session実装は、Kerberos des-cbc-md5暗号化タイプ[RFC-1510]（チケットとKerberosメッセージの暗号化されたデータの場合）およびKerberos RSA-MD5-DESチェックサムタイプ[RFC-1510]をサポートする必要があります。（krb_safeチェックサムの場合）チェックサム。IETF標準プロセスによって新しいアルゴリズムが追加される場合があります。Triple-DES暗号化は、多くのKerberosの実装でサポートされています（[RFC-1510]で指定されていませんが）、単一のDESで使用する必要があります。
For cases where the authorizing entity is in a different realm (i.e., administrative domain, organizational boundary), the router/PDP needs to fetch a cross-realm Ticket Granting Ticket (TGT) from its local KDC. This TGT can be used to fetch authorizing entity tickets from the KDC in the remote realm. Note that for performance considerations, tickets are typically cached for extended periods.
認可エンティティが異なる領域（すなわち、管理ドメイン、組織の境界）にある場合、ルーター/PDPは、ローカルKDCからクロスリアムチケット付与チケット（TGT）を取得する必要があります。このTGTは、リモート領域のKDCからの承認エンティティチケットを取得するために使用できます。パフォーマンスに関する考慮事項のために、チケットは通常、長期間キャッシュされていることに注意してください。
In a public key environment, the AUTH_ENT_ID MUST be of the subtypes: X509_V3_CERT or PGP_CERT. The authentication data is used for authenticating the authorizing entity. An example of the public key AUTH_SESSION policy element is shown below.
公開キー環境では、auth_ent_idはサブタイプでなければなりません：x509_v3_certまたはpgp_cert。認証データは、承認エンティティを認証するために使用されます。公開キーのauth_sessionポリシー要素の例を以下に示します。
+--------------+--------------+--------------+--------------+
| Length | P-type = AUTH_SESSION |
+--------------+--------------+--------------+--------------+
| Length |SESSION_ID | zero |
+--------------+--------------+--------------+--------------+
| OctetString (The session identifier) ...
+--------------+--------------+--------------+--------------+
| Length | AUTH_ENT_ID | PGP_CERT |
+--------------+--------------+--------------+--------------+
| OctetString (Authorizing entity Digital Certificate) ...
+--------------+--------------+--------------+--------------+
| Length |AUTH DATA. | zero |
+--------------+--------------+--------------+--------------+
| OctetString (Authentication data) ...
+--------------+--------------+--------------+--------------+
Public key based authentication assumes the following:
公開鍵ベースの認証は次のとおりです。
- Authorizing entities have a pair of keys (private key and public key).
- 承認エンティティには、一対のキー（秘密鍵と公開キー）があります。
- Private key is secured with the authorizing entity.
- 秘密鍵は、承認エンティティで保護されています。
- Public keys are stored in digital certificates and a trusted party, certificate authority (CA) issues these digital certificates.
- パブリックキーはデジタル証明書に保存され、信頼できる当事者はこれらのデジタル証明書を発行します（CA）。
- The verifier (PDP or router) has the ability to verify the digital certificate.
- Verifier（PDPまたはRouter）には、デジタル証明書を確認する機能があります。
Authorizing entity uses its private key to generate AUTHENTICATION_DATA. Authenticators (router, PDP) use the authorizing entity's public key (stored in the digital certificate) to verify and authenticate the policy element.
承認エンティティは、その秘密鍵を使用して、Authentication_Dataを生成します。Authenticators（Router、PDP）は、承認エンティティの公開キー（デジタル証明書に保存）を使用して、ポリシー要素を検証および認証します。
When the AUTH_ENT_ID is of type X509_V3_CERT, AUTHENTICATION_DATA MUST be generated following these steps:
auth_ent_idがタイプx509_v3_certである場合、これらの手順に従ってauthentication_dataを生成する必要があります。
- A Signed-data is constructed as defined in section 5 of CMS [RFC-3369]. A digest is computed on the content (as specified in section 6.1) with a signer-specific message-digest algorithm. The certificates field contains the chain of authorizing entity's X.509 V3 digital certificates. The certificate revocation list is defined in the crls field. The digest output is digitally signed following section 8 of RFC 3447, using the signer's private key.
- 署名されたデータは、CMS [RFC-3369]のセクション5で定義されているように構築されています。ダイジェストは、署名者固有のメッセージダイジェストアルゴリズムを使用して、コンテンツ（セクション6.1で指定）で計算されます。証明書フィールドには、エンティティのX.509 V3デジタル証明書を認証するチェーンが含まれています。証明書の取り消しリストは、CRLSフィールドで定義されています。ダイジェスト出力は、署名者の秘密鍵を使用して、RFC 3447のセクション8に従ってデジタル署名されています。
When the AUTH_ENT_ID is of type X509_V3_CERT, verification MUST be done following these steps:
auth_ent_idがタイプx509_v3_certの場合、これらの手順に従って検証を行う必要があります。
- Parse the X.509 V3 certificate to extract the distinguished name of the issuer of the certificate. - Certification Path Validation is performed as defined in section 6 of RFC 3280. - Parse through the Certificate Revocation list to verify that the received certificate is not listed. - Once the X.509 V3 certificate is validated, the public key of the authorizing entity can be extracted from the certificate. - Extract the digest algorithm and the length of the digested data by parsing the CMS signed-data. - The recipient independently computes the message digest. This message digest and the signer's public key are used to verify the signature value.
- X.509 V3証明書を解析して、証明書の発行者の著名な名前を抽出します。 - 認定パス検証は、RFC 3280のセクション6で定義されているように実行されます。-認定証明書リストを解析して、受け取った証明書がリストされていないことを確認します。 - X.509 V3証明書が検証されると、認定エンティティの公開鍵を証明書から抽出できます。-CMS署名されたデータを解析することにより、ダイジェストアルゴリズムと消化データの長さを抽出します。 - 受信者は、メッセージダイジェストを個別に計算します。このメッセージダイジェストと署名者の公開キーは、署名値を確認するために使用されます。
This verification ensures integrity, non-repudiation and data origin.
この検証により、整合性、非和解、データの起源が保証されます。
When the AUTH_ENT_ID is of type PGP_CERT, AUTHENTICATION_DATA MUST be generated following these steps:
auth_ent_idがタイプpgp_certである場合、これらの手順に従ってauthentication_dataを生成する必要があります。
- AUTHENTICATION_DATA contains a Signature Packet as defined in section 5.2.3 of RFC 2440. In summary:
- Authentication_Dataには、RFC 2440のセクション5.2.3で定義されている署名パケットが含まれています。まとめ：
- Compute the hash of all data in the AUTH_SESSION policy element up to the AUTHENTICATION_DATA. - The hash output is digitally signed following section 8 of RFC 3447, using the signer's private key.
- Auth_Sessionポリシー要素のすべてのデータのハッシュをAuthentication_Dataに計算します。 - ハッシュ出力は、署名者の秘密鍵を使用して、RFC 3447のセクション8に従ってデジタル署名されています。
When the AUTH_ENT_ID is of type PGP_CERT, verification MUST be done following these steps:
auth_ent_idがタイプpgp_certの場合、これらの手順に従って検証を行う必要があります。
- Validate the certificate. - Once the PGP certificate is validated, the public key of the authorizing entity can be extracted from the certificate. - Extract the hash algorithm and the length of the hashed data by parsing the PGP signature packet. - The recipient independently computes the message digest. This message digest and the signer's public key are used to verify the signature value.
- 証明書を検証します。 - PGP証明書が検証されると、認定エンティティの公開鍵を証明書から抽出できます。-PGP署名パケットを解析することにより、ハッシュアルゴリズムとハッシュされたデータの長さを抽出します。 - 受信者は、メッセージダイジェストを個別に計算します。このメッセージダイジェストと署名者の公開キーは、署名値を確認するために使用されます。
This verification ensures integrity, non-repudiation and data origin.
この検証により、整合性、非和解、データの起源が保証されます。
[RFC-3521] describes a framework in which the AUTH_SESSION policy element may be utilized to transport information required for authorizing resource reservation for media flows. [RFC-3521] introduces 4 different models:
[RFC-3521]は、メディアフローのリソース予約を承認するために必要な情報を輸送するためにAUTH_SESSIONポリシー要素を利用できるフレームワークを説明しています。[RFC-3521] 4つの異なるモデルを導入します。
1- the coupled model 2- the associated model with one policy server 3- the associated model with two policy servers 4- the non-associated model.
1-結合モデル2- 1つのポリシーサーバーを含む関連モデル3- 2つのポリシーサーバーを持つ関連モデル4-非関連モデル。
The fields that are required in an AUTH SESSION policy element dependent on which of the models is used.
どのモデルが使用されているかに応じて、認証セッションポリシー要素で必要とされるフィールド。
In the Coupled Model, the only information that MUST be included in the policy element is the SESSION_ID; it is used by the Authorizing Entity to correlate the resource reservation request with the media authorized during session set up. Since the End Host is assumed to be untrusted, the Policy Server SHOULD take measures to ensure that the integrity of the SESSION_ID is preserved in transit; the exact mechanisms to be used and the format of the SESSION_ID are implementation dependent.
結合モデルでは、ポリシー要素に含める必要がある唯一の情報はsession_idです。これは、セッションのセットアップ中に認可されたメディアとリソース予約要求を相関させるために、承認エンティティによって使用されます。エンドホストは信頼されていないと想定されているため、ポリシーサーバーは、session_idの整合性が輸送中に保持されることを確認するための措置を講じる必要があります。使用する正確なメカニズムとセッション_IDの形式は実装依存です。
In this model, the contents of the AUTH_SESSION policy element MUST include:
このモデルでは、auth_sessionポリシー要素の内容には以下を含める必要があります。
- A session identifier - SESSION_ID. This is information that the authorizing entity can use to correlate the resource reservation request with the media authorized during session set up.
- セッション識別子-session_id。これは、承認エンティティがセッションのセットアップ中に許可されたメディアとリソース予約要求を相関させるために使用できる情報です。
- The identity of the authorizing entity - AUTH_ENT_ID. This information is used by the Edge Router to determine which authorizing entity (Policy Server) should be used to solicit resource policy decisions.
- 認可エンティティのアイデンティティ-AUTH_ENT_ID。この情報は、エッジルーターによって使用されて、リソースポリシーの決定を求めるために使用される承認エンティティ（ポリシーサーバー）を決定します。
In some environments, an Edge Router may have no means for determining if the identity refers to a legitimate Policy Server within its domain. In order to protect against redirection of authorization requests to a bogus authorizing entity, the AUTH_SESSION MUST also include:
一部の環境では、エッジルーターは、アイデンティティがドメイン内の正当なポリシーサーバーを指すかどうかを判断する手段がない場合があります。偽の認可エンティティへの認可要求のリダイレクトから保護するために、auth_sessionには以下を含める必要があります。
- AUTHENTICATION_DATA. This authentication data is calculated over all other fields of the AUTH_SESSION policy element.
- Authentication_Data。この認証データは、auth_sessionポリシー要素の他のすべてのフィールドで計算されます。
The content of the AUTH_SESSION Policy Element is identical to the associated model with one policy server.
auth_sessionポリシー要素の内容は、1つのポリシーサーバーを持つ関連モデルと同一です。
In this model, the AUTH_SESSION MUST contain sufficient information to allow the Policy Server to make resource policy decisions autonomously from the authorizing entity. The policy element is created using information about the session by the authorizing entity. The information in the AUTH_SESSION policy element MUST include:
このモデルでは、auth_sessionには、ポリシーサーバーが認可エンティティからリソースポリシーの決定を自律的に行うことができるように十分な情報を含める必要があります。ポリシー要素は、承認エンティティによるセッションに関する情報を使用して作成されます。auth_sessionポリシー要素の情報には、以下を含める必要があります。
- Calling party IP address or Identity (e.g., FQDN) - SOURCE_ADDR X-TYPE - Called party IP address or Identity (e.g., FQDN) - DEST_ADDR X-TYPE - The characteristics of (each of) the media stream(s) authorized for this session - RESOURCES X-TYPE - The authorization lifetime - START_TIME X-TYPE - The identity of the authorizing entity to allow for validation of the token in shared symmetric key and Kerberos schemes - AUTH_ENT_ID X-TYPE - The credentials of the authorizing entity in a public-key scheme - AUTH_ENT_ID X-TYPE - Authentication data used to prevent tampering with the AUTH_SESSION policy element - AUTHENTICATION_DATA
- パーティーIPアドレスまたはIDの呼び出し（例：FQDN）-Source_Addr X -Type-パーティーIPアドレスまたはIDと呼ばれる（例：FQDN）-DEST_ADDR X -Type-これのために許可されたメディアストリームの（それぞれ）の特性セッション - リソースXタイプ - 認証ライフタイム-Start_Time X -Type-共有対称キーとKerberosスキームでトークンの検証を可能にする認可エンティティのID -auth_ent_id x -type-承認エンティティの資格情報Public -Key Scheme -auth_ent_id x -type- Auth_Sessionポリシー要素の改ざんを防ぐために使用される認証データ-Authentication_Data
Furthermore, the AUTH_SESSION policy element MAY contain:
さらに、auth_sessionポリシー要素には以下が含まれる場合があります。
- The lifetime of (each of) the media stream(s) - END_TIME X-TYPE - Calling party port number - SOURCE_ADDR X-TYPE - Called party port number - DEST_ADDR X-TYPE
- （それぞれ）メディアストリーム（s） - end_time x -type-通話パーティーポート番号-source_addr x -type -partyポート番号-dest_addr x -typeの寿命
All AUTH_SESSION fields MUST match with the resource request. If a field does not match, the request SHOULD be denied.
すべてのauth_sessionフィールドは、リソースリクエストと一致する必要があります。フィールドが一致しない場合、リクエストは拒否されるべきです。
1. Generate the AUTH_SESSION policy element with the appropriate contents as specified in section 5.
1. セクション5で指定されているように、適切な内容を使用してAUTH_SESSIONポリシー要素を生成します。
2. If authentication is needed, the entire AUTH_SESSION policy element is constructed, excluding the length, type and subtype fields of the AUTH_SESSION field. Note that the message MUST include either a START_TIME or a SESSION_ID (See Section 9), to prevent replay attacks. The output of the authentication algorithm, plus appropriate header information, is appended to the AUTH_SESSION policy element.
2. 認証が必要な場合、auth_sessionフィールドの長さ、タイプ、サブタイプのフィールドを除く、auth_sessionポリシー要素全体が構築されます。再生攻撃を防ぐために、メッセージにはstart_timeまたはsession_id（セクション9を参照）を含める必要があることに注意してください。認証アルゴリズムの出力と適切なヘッダー情報は、auth_sessionポリシー要素に追加されます。
An RSVP message is created as specified in [RFC-2205] with the following modifications.
RSVPメッセージは、[RFC-2205]で指定されているように作成され、次の変更が行われます。
1. RSVP message MUST contain at most one AUTH_SESSION policy element.
1. RSVPメッセージには、最大1つのauth_sessionポリシー要素を含める必要があります。
2. The AUTH SESSION policy element received from the authorizing entity (Section 3.2) MUST be copied without modification into the POLICY DATA object.
2. 認可エンティティ（セクション3.2）から受け取ったAUTHセッションポリシー要素は、ポリシーデータオブジェクトに変更せずにコピーする必要があります。
3. POLICY_DATA object (containing the AUTH_SESSION policy element) is inserted in the RSVP message in the appropriate place.
3. Policy_Dataオブジェクト（Auth_Sessionポリシー要素を含む）は、適切な場所のRSVPメッセージに挿入されます。
RSVP message is processed as specified in [RFC-2205] with following modifications.
RSVPメッセージは、[RFC-2205]で指定されているとおりに処理され、次の修正が行われます。
1. If router is policy aware then it SHOULD send the RSVP message to the PDP and wait for response. If the router is policy unaware then it ignores the policy data objects and continues processing the RSVP message.
1. ルーターがポリシーを認識している場合は、RSVPメッセージをPDPに送信し、応答を待つ必要があります。ルーターがポリシーを認識していない場合、ポリシーデータオブジェクトを無視し、RSVPメッセージの処理を継続します。
2. Reject the message if the response from the PDP is negative.
2. PDPからの応答が負の場合、メッセージを拒否します。
3. Continue processing the RSVP message.
3. RSVPメッセージの処理を続けます。
1. Retrieve the AUTH_SESSION policy element. Check the PE type field and return an error if the identity type is not supported.
1. auth_sessionポリシー要素を取得します。PEタイプフィールドを確認し、IDタイプがサポートされていない場合はエラーを返します。
2. Verify the message integrity.
2. メッセージの整合性を確認します。
- Shared symmetric key authentication: The Network router/PDP uses the AUTH_ENT_ID field to consult a table keyed by that field. The table should identify the cryptographic authentication algorithm to be used along with the expected length of the authentication data and the shared symmetric key for the authorizing entity. Verify that the indicated length of the authentication data is consistent with the configured table entry and validate the authentication data.
- 共有対称キー認証：ネットワークルーター/PDPは、auth_ent_idフィールドを使用して、そのフィールドがキーにしたテーブルを参照します。表は、認証データの予想される長さとともに、認証エンティティの共有対称キーとともに使用する暗号化認証アルゴリズムを識別する必要があります。認証データの指定された長さが設定されたテーブルエントリと一致しており、認証データを検証することを確認します。
- Public Key: Validate the certificate chain against the trusted Certificate Authority (CA) and validate the message signature using the public key.
- 公開キー：信頼できる証明書局（CA）に対して証明書チェーンを検証し、公開キーを使用してメッセージ署名を検証します。
- Kerberos Ticket: If the AUTH_ENT_ID is of subtype KRB_PRINCIPAL, Request a ticket for the authorizing entity (principal@realm) from the local KDC. Use the ticket to access the authorizing entity and obtain authentication data for the message.
- Kerberosチケット：auth_ent_idがサブタイプKRB_PRINCIPALの場合、ローカルKDCから認可エンティティ（プリンシパル@Realm）のチケットをリクエストしてください。チケットを使用して、承認エンティティにアクセスし、メッセージの認証データを取得します。
3. Once the identity of the authorizing entity and the validity of the service request has been established, the authorizing router/PDP MUST then consult its local policy tables (the contents of which are a local matter) in order to determine whether or not the specific request is authorized. To the extent to which these access control decisions require supplementary information, routers/PDPs MUST ensure that supplementary information is obtained securely. An example of insecure access control decisions would be if the authorizing party relies upon an insecure database (such as DNS or a public LDAP directory) and authorizes with a certificate or an FQDN.
3. 承認エンティティの身元とサービス要求の有効性が確立されたら、承認ルーター/PDPは、特定のリクエストを決定するために、ローカルポリシーテーブル（その内容がローカル問題です）を参照する必要があります。許可されています。これらのアクセス制御決定に補足情報が必要な範囲で、ルーター/PDPは補足情報が安全に取得されることを保証する必要があります。不安定なアクセス制御の決定の例は、認可当事者が安全でないデータベース（DNSやPublic LDAPディレクトリなど）に依存し、証明書またはFQDNで承認された場合です。
4. Verify the requested resources do not exceed the authorized QoS.
4. 要求されたリソースが承認されたQOを超えないことを確認してください。
If a PDP fails to verify the AUTH_SESSION policy element then it MUST return a policy control failure (Error Code = 02) to the PEP. The error values are described in [RFC-2205] and [RFC-2750]. Also the PDP SHOULD supply a policy data object containing an AUTH_DATA Policy Element with A-Type=POLICY_ERROR_CODE containing more details on the Policy Control failure [RFC-3182]. If RSVP is being used, the PEP MUST include this Policy Data object in the outgoing RSVP Error message.
PDPがauth_sessionポリシー要素の検証に失敗した場合、ポリシー制御障害（エラーコード= 02）をPEPに返す必要があります。エラー値は[RFC-2205]および[RFC-2750]で説明されています。また、PDPは、a-type = policy_error_codeを含むauth_dataポリシー要素を含むポリシーデータオブジェクトを提供する必要があります。RSVPが使用されている場合、PEPは、発信RSVPエラーメッセージにこのポリシーデータオブジェクトを含める必要があります。
Following the policies outlined in [IANA-CONSIDERATIONS], Standard RSVP Policy Elements (P-type values) are assigned by IETF Consensus action as described in [RFC-2750].
[IANA分類]で概説されているポリシーに続いて、[RFC-2750]で説明されているように、標準のRSVPポリシー要素（Pタイプ値）がIETFコンセンサスアクションによって割り当てられます。
P-Type AUTH_SESSION is assigned the value 0x04.
p-type auth_sessionには値0x04が割り当てられます。
Following the policies outlined in [IANA-CONSIDERATIONS], session authorization attribute types (X-Type)in the range 0-127 are allocated through an IETF Consensus action; X-Type values between 128-255 are reserved for Private Use and are not assigned by IANA.
[Iana-Consididerations]で概説されているポリシーに続いて、0〜127の範囲のセッション認証属性タイプ（Xタイプ）は、IETFコンセンサスアクションを通じて割り当てられます。128-255の間のXタイプの値は、私的使用のために予約されており、IANAによって割り当てられていません。
X-Type AUTH_ENT_ID is assigned the value 1. X-Type SESSION_ID is assigned the value 2. X-Type SOURCE_ADDR is assigned the value 3. X-Type DEST_ADDR is assigned the value 4. X-Type START_TIME is assigned the value 5. X-Type END_TIME is assigned the value 6. X-Type RESOURCES is assigned the value 7. X-Type AUTHENTICATION_DATA is assigned the value 8.
x-type auth_ent_idには値が割り当てられます。xタイプsession_idには値が割り当てられます。x-type source_addrは値3に割り当てられます。x型dest_addrには値4が割り当てられます。x-type start_timeは値5に割り当てられます。X-Type End_Timeに値6が割り当てられます。xX-Typeリソースには値7が割り当てられます。XタイプAuthentication_Dataには値8が割り当てられます。
Following the policies outlined in [IANA-CONSIDERATIONS], AUTH_ENT_ID SubType values in the range 0-127 are allocated through an IETF Consensus action; SubType values between 128-255 are reserved for Private Use and are not assigned by IANA.
[IANA-Considerations]で概説されているポリシーに続いて、範囲0-127のauth_ent_idサブタイプ値は、IETFコンセンサスアクションを通じて割り当てられます。128-255の間のサブタイプの値は、私的使用のために予約されており、IANAによって割り当てられていません。
AUTH_ENT_ID SubType IPV4_ADDRESS is assigned the value 1. SubType IPV6_ADDRESS is assigned the value 2. SubType FQDN is assigned the value 3. SubType ASCII_DN is assigned the value 4. SubType UNICODE_DN is assigned the value 5. SubType URI is assigned the value 6. SubType KRB_PRINCIPAL is assigned the value 7. SubType X509_V3_CERT is assigned the value 8. SubType PGP_CERT is assigned the value 9.
auth_ent_id subtype ipv4_addressに値が割り当てられます。1。サブタイプIPv6_addressに値が割り当てられます。サブタイプfqdnには値が割り当てられます。サブタイプASCII_DNには値が割り当てられます。KRB_PRINCIPALには値7が割り当てられます。サブタイプX509_V3_CERTには値8が割り当てられます。SubTypePGP_CERTには値9が割り当てられます。
Following the policies outlined in [IANA-CONSIDERATIONS], SOURCE_ADDR SubType values in the range 0-127 are allocated through an IETF Consensus action; SubType values between 128-255 are reserved for Private Use and are not assigned by IANA.
[Iana-Consididerations]で概説されているポリシーに続いて、範囲0-127のSource_Addrサブタイプ値は、IETFコンセンサスアクションによって割り当てられます。128-255の間のサブタイプの値は、私的使用のために予約されており、IANAによって割り当てられていません。
SOURCE_ADDR SubType IPV4_ADDRESS is assigned the value 1. SubType IPV6_ADDRESS is assigned the value 2. SubType UDP_PORT_LIST is assigned the value 3. SubType TCP_PORT_LIST is assigned the value 4.
source_addr subtype ipv4_addressに値が割り当てられます。サブタイプIPv6_addressに値2が割り当てられます。サブタイプudp_port_listには値3が割り当てられます。
Following the policies outlined in [IANA-CONSIDERATIONS], DEST_ADDR SubType values in the range 0-127 are allocated through an IETF Consensus action; SubType values between 128-255 are reserved for Private Use and are not assigned by IANA.
[IANA-Consididerations]で概説されているポリシーに続いて、0-127の範囲のDEST_ADDRサブタイプ値は、IETFコンセンサスアクションによって割り当てられます。128-255の間のサブタイプの値は、私的使用のために予約されており、IANAによって割り当てられていません。
DEST_ADDR SubType IPV4_ADDRESS is assigned the value 1. SubType IPV6_ADDRESS is assigned the value 2. SubType UDP_PORT_LIST is assigned the value 3. SubType TCP_PORT_LIST is assigned the value 4.
DEST_ADDRサブタイプIPv4_Addressに値が割り当てられます。SubTypeIPv6_Addressに値2が割り当てられます。SubTypeUDP_PORT_LISTには値3が割り当てられます。
Following the policies outlined in [IANA-CONSIDERATIONS], START_TIME SubType values in the range 0-127 are allocated through an IETF Consensus action; SubType values between 128-255 are reserved for Private Use and are not assigned by IANA.
[IANA-Consididerations]で概説されているポリシーに続いて、0〜127の範囲のstart_timeサブタイプ値は、IETFコンセンサスアクションを通じて割り当てられます。128-255の間のサブタイプの値は、私的使用のために予約されており、IANAによって割り当てられていません。
START_TIME SubType NTP_TIMESTAMP is assigned the value 1.
start_time subtype ntp_timestampに値1が割り当てられます。
Following the policies outlined in [IANA-CONSIDERATIONS], END_TIME SubType values in the range 0-127 are allocated through an IETF Consensus action; SubType values between 128-255 are reserved for Private Use and are not assigned by IANA.
[IANA分類]で概説されているポリシーに続いて、0-127の範囲のEnd_Timeサブタイプ値は、IETFコンセンサスアクションを通じて割り当てられます。128-255の間のサブタイプの値は、私的使用のために予約されており、IANAによって割り当てられていません。
END_TIME SubType NTP_TIMESTAMP is assigned the value 1.
end_time subtype ntp_timestampに値1が割り当てられます。
Following the policies outlined in [IANA-CONSIDERATIONS], RESOURCES SubType values in the range 0-127 are allocated through an IETF Consensus action; SubType values between 128-255 are reserved for Private Use and are not assigned by IANA.
[IANA-Consididerations]で概説されているポリシーに続いて、0〜127の範囲のリソースサブタイプ値は、IETFコンセンサスアクションを通じて割り当てられます。128-255の間のサブタイプの値は、私的使用のために予約されており、IANAによって割り当てられていません。
RESOURCES SubType BANDWIDTH is assigned the value 1. SubType FLOW_SPEC is assigned the value 2. SubType SDP is assigned the value 3. SubType DSCP is assigned the value 4.
リソースサブタイプの帯域幅には値が割り当てられます。サブタイプFlow_Specには値が割り当てられます。SupTypeSDPに値3が割り当てられます。SubTypeDSCPには値4が割り当てられます。
The purpose of this document is to describe a mechanism for session authorization to prevent theft of service.
このドキュメントの目的は、サービスの盗難を防ぐためのセッション承認のメカニズムを説明することです。
Replay attacks MUST be prevented. In the non-associated model, the AUTH_SESSION policy element MUST include a START_TIME field and the Policy Servers MUST support NTP to ensure proper clock synchronization. Failure to ensure proper clock synchronization will allow replay attacks since the clocks of the different network entities may not be in-synch. The start time is used to verify that the request is not being replayed at a later time. In all other models, the SESSION_ID is used by the Policy Server to ensure that the resource request successfully correlates with records of an authorized session. If a AUTH_SESSION is replayed, it MUST be detected by the policy server (using internal algorithms) and the request MUST be rejected.
リプレイ攻撃を防ぐ必要があります。非関連モデルでは、auth_sessionポリシー要素にはstart_timeフィールドを含める必要があり、ポリシーサーバーは適切なクロック同期を確保するためにNTPをサポートする必要があります。異なるネットワークエンティティのクロックがシンク内ではない可能性があるため、適切なクロックの同期を確保できないと、リプレイ攻撃が可能になります。開始時間は、リクエストが後で再生されていないことを確認するために使用されます。他のすべてのモデルでは、セッション_IDがポリシーサーバーによって使用され、リソース要求が認定セッションのレコードと正常に相関するようにします。auth_sessionが再生される場合、ポリシーサーバー（内部アルゴリズムを使用）で検出する必要があり、リクエストを拒否する必要があります。
To ensure that the integrity of the policy element is preserved in untrusted environments, the AUTHENTICATION_DATA attribute MUST be included.
ポリシー要素の完全性が信頼されていない環境で保存されるようにするには、承認_DATA属性を含める必要があります。
In environments where shared symmetric keys are possible, they should be used in order to keep the AUTH_SESSION policy element size to a strict minimum. This is especially true in wireless environments where the AUTH_SESSION policy element is sent over-the-air. The shared symmetric keys authentication option MUST be supported by all AUTH_SESSION implementations.
共有対称キーが可能な環境では、auth_sessionポリシー要素のサイズを厳密に最小限に抑えるために使用する必要があります。これは、Auth_Sessionポリシー要素が無線で送信されるワイヤレス環境で特に当てはまります。共有対称キー認証オプションは、すべてのauth_session実装によってサポートされる必要があります。
If shared symmetric keys are not a valid option, the Kerberos authentication mechanism is reasonably well secured and efficient in terms of AUTH_SESSION size. The AUTH_SESSION only needs to contain the principal@realm name of the authorizing entity. This is much more efficient than the PKI authentication option.
共有対称キーが有効なオプションではない場合、Kerberos認証メカニズムは、Auth_Sessionサイズの点でかなり安全で効率的です。auth_sessionには、承認エンティティのプリンシパル@realm名を含める必要があります。これは、PKI認証オプションよりもはるかに効率的です。
PKI authentication option provides a high level of security and good scalability, however it requires the presence of credentials in the AUTH_SESSION policy element which impacts its size.
PKI認証オプションは、高レベルのセキュリティと優れたスケーラビリティを提供しますが、そのサイズに影響を与えるAuth_Sessionポリシー要素に資格情報が存在する必要があります。
We would like to thank Francois Audet, Don Wade, Hamid Syed, Kwok Ho Chan and many others for their valuable comments. Special thanks to Eric Rescorla who provided numerous comments and suggestions that improved this document.
Francois Audet、Don Wade、Hamid Syed、Kwok Ho Chanなど、貴重なコメントをしてくれたことに感謝します。この文書を改善する多くのコメントと提案を提供してくれたエリック・レスカラに感謝します。
In addition, we would like to thank S. Yadav, et al., for their efforts on RFC 3182, as this document borrows from their work.
さらに、この文書が彼らの仕事から借りているので、RFC 3182での努力について、S。Yadavet al。などに感謝します。
[ASCII] Coded Character Set -- 7-Bit American Standard Code for Information Interchange, ANSI X3.4- 1986.
[ASCII]コード化された文字セット-ANSI X3.4- 1986の情報交換のための7ビットアメリカ標準コード。
[X.509-ITU] ITU-T (formerly CCITT) Information technology Open Systems Interconnection - The Directory: Authentication Framework Recommendation X.509 ISO/IEC 9594-8
[X.509-ITU] ITU-T（以前のCCITT）情報技術オープンシステムの相互接続 - ディレクトリ：認証フレームワークの推奨X.509 ISO/IEC 9594-8
[RFC-1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC -1034] Mockapetris、P。、「ドメイン名 - 概念と施設」、STD 13、RFC 1034、1987年11月。
[RFC-1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation, and Analysis", RFC 1305, March 1992.
[RFC-1305] Mills、D。、「ネットワークタイムプロトコル（バージョン3）仕様、実装、および分析」、RFC 1305、1992年3月。
[RFC-1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC-1321] Rivest、R。、「The MD5 Message-Digest Algorithm」、RFC 1321、1992年4月。
[RFC-1510] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[RFC-1510] Kohl、J。およびC. Neuman、「The Kerberos Network Authentication Service（V5）」、RFC 1510、1993年9月。
[RFC-2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC-2104] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed Hashing for Message Authentication」、RFC 2104、1997年2月。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC-2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, September 1997.
[RFC -2205] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S.、S。Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、9月1997年。
[RFC-2209] Braden, R. and L. Zhang, "Resource ReSerVation Protocol (RSVP) - Version 1 Message Processing Rules", RFC 2209, September 1997.
[RFC -2209] Braden、R。およびL. Zhang、「リソース予約プロトコル（RSVP） - バージョン1メッセージ処理ルール」、RFC 2209、1997年9月。
[RFC-2253] Wahl, M., Kille, S. and T. Howes , "UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997.
[RFC-2253] Wahl、M.、Kille、S。and T. Howes、「UTF-8文字列表現の著名な名前の表現」、RFC 2253、1997年12月。
[RFC-2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[RFC-2279] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、RFC 2279、1998年1月。
[RFC-2327] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, October 1998.
[RFC-2327] Handley、M。and V. Jacobson、「SDP：セッション説明プロトコル」、RFC 2327、1998年10月。
[RFC-2396] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[RFC-2396] Berners-Lee、T.、Fielding、R.、Masinter、L。、「ユニフォームリソース識別子（URI）：ジェネリック構文」、RFC 2396、1998年8月。
[RFC-2440] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
[RFC-2440] Callas、J.、Donnerhacke、L.、Finney、H。およびR. Thayer、「OpenPGPメッセージ形式」、RFC 2440、1998年11月。
[RFC-2474] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC-2474] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
[RFC-2750] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[RFC-2750] Herzog、S。、「ポリシー管理のためのRSVP拡張」、RFC 2750、2000年1月。
[RFC-2753] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy-based Admission Control RSVP", RFC 2753, January 2000.
[RFC-2753] Yavatkar、R.、Pendarakis、D。、およびR. Guerin、「政策ベースの入学管理RSVPのフレームワーク」、RFC 2753、2000年1月。
[RFC-3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., Herzog, S. and R. Hess, "Identity Representation for RSVP", RFC 3182, October 2001
[RFC-3182] Yadav、S.、Yavatkar、R.、Pabbati、R.、Ford、P.、Moore、T.、Herzog、S.、R。Hess、「RSVPのアイデンティティ表現」、RFC 3182、10月2001年
[RFC-3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC-3280] Housley、R.、Polk、W.、Ford、W。and D. Solo、「インターネットX.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」、RFC 3280、2002年4月。
[RFC-3369] Housley, R., "Cryptographic Message Syntax", RFC 3369, August 2002.
[RFC-3369] Housley、R。、「暗号化メッセージ構文」、RFC 3369、2002年8月。
[RFC-3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RFC-3447] Jonsson、J.およびB. Kaliski、「Public-Key Cryptography Standards（PKCS）＃1：RSA暗号仕様バージョン2.1」、RFC 3447、2003年2月。
[RFC-3521] Hamer, L.-N., Gage, B. and H. Shieh, "Framework for Session Setup with Media Authorization", RFC 3521, April 2003.
[RFC-3521] Hamer、L.-N.、Gage、B。およびH. Shieh、「メディア認可によるセッションセットアップのフレームワーク」、RFC 3521、2003年4月。
[IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[Iana-Considerations] Alvestrand、H。およびT. Narten、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[RFC-3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC-3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：セッション開始プロトコル"、RFC 3261、2002年6月。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、知的財産またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用に関連すると主張される可能性のある他の権利、またはそのような権利に基づくライセンスがどの程度であるかについての程度に関連する可能性があるという立場はありません。利用可能;また、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連のドキュメントの権利に関するIETFの手順に関する情報は、BCP-11に記載されています。出版のために利用可能にされた権利の請求のコピーと、利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、関心のある当事者に、この基準を実践するために必要な技術をカバーする可能性のある著作権、特許、または特許出願、またはその他の独自の権利を注意深く招待するよう招待しています。情報をIETFエグゼクティブディレクターに宛ててください。
Matt Broda Nortel Networks
Matt Broda Nortelネットワーク
EMail: mbroda@nortelnetworks.com
Louis LeVay Nortel Networks
Louis Levay Nortel Networks
EMail: levay@nortelnetworks.com
Dennis Beard Nortel Networks
Dennis Beard Nortelネットワーク
EMail: beardd@nortelnetworks.com
Lawrence Dobranski Nortel Networks
ローレンス・ドブランスキー・ノーテル・ネットワーク
EMail: ldobran@nortelnetworks.com
Louis-Nicolas Hamer Nortel Networks PO Box 3511 Station C Ottawa, Ontario Canada K1Y 4H7
ルイ・ニコラス・ハマー・ノーテル・ネットワークのPO Box 3511駅Cオタワ、オンタリオカナダK1Y 4H7
Phone: +1 613.768.3409
EMail: nhamer@nortelnetworks.com
Brett Kosinski Invidi Technologies Edmonton, Alberta Canada T5J 3S4
Brett Kosinski Invidi Technologies Edmonton、Alberta Canada T5J 3S4
EMail: brettk@invidi.com
Bill Gage Nortel Networks PO Box 3511 Station C Ottawa, Ontario Canada K1Y 4H7
Bill Gage Nortel Networks PO Box 3511 Station C Ottawa、オンタリオカナダK1Y 4H7
Phone: +1 613.763.4400
EMail: gageb@nortelnetworks.com
Hugh Shieh AT&T Wireless 7277 164th Avenue NE Redmond, WA USA 98073-9761
Hugh Shieh AT＆Tワイヤレス7277 164th Avenue Ne Redmond、WA USA 98073-9761
Phone: +1 425.580.6898
EMail: hugh.shieh@attws.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。