[要約] RFC 3182は、RSVPのためのアイデンティティ表現に関する規格であり、アイデンティティ情報の表現と交換を可能にすることを目的としています。
Network Working Group S. Yadav
Request for Comments: 3182 R. Yavatkar
Obsoletes: 2752 Intel
Category: Standards Track R. Pabbati
P. Ford
T. Moore
Microsoft
S. Herzog
PolicyConsulting.Com
R. Hess
Intel
October 2001
Identity Representation for RSVP
RSVPのID表現
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 (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
Abstract
概要
This document describes the representation of identity information in POLICY_DATA object for supporting policy based admission control in the Resource ReSerVation Protocol (RSVP). The goal of identity representation is to allow a process on a system to securely identify the owner and the application of the communicating process (e.g., user id) and convey this information in RSVP messages (PATH or RESV) in a secure manner. We describe the encoding of identities as RSVP policy element. We describe the processing rules to generate identity policy elements for multicast merged flows. Subsequently, we describe representations of user identities for Kerberos and Public Key based user authentication mechanisms. In summary, we describe the use of this identity information in an operational setting.
このドキュメントでは、リソース予約プロトコル（RSVP）でのポリシーベースの入場制御をサポートするためのpolicy_DataオブジェクトのID情報の表現について説明します。アイデンティティ表現の目標は、システム上のプロセスが所有者と通信プロセスの適用（ユーザーIDなど）の適用を安全に識別し、この情報をRSVPメッセージ（パスまたはRESV）で安全な方法で伝えることです。アイデンティティのエンコードをRSVPポリシー要素として説明します。マルチキャストマージされたフローのIDポリシー要素を生成するための処理ルールについて説明します。その後、Kerberosおよび公開キーベースのユーザー認証メカニズムのユーザーIDの表現について説明します。要約すると、運用設定でこのID情報の使用について説明します。
This memo corrects an RSVP POLICY_DATA P-Type codepoint assignment error and a field size definition error in ErrorValue in RFC 2752.
このメモは、RSVP Policy_Data P-Type CodePoint割り当てエラーと、RFC 2752のエラー値のフィールドサイズ定義エラーを修正します。
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 [RFC 2119].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC 2119]で説明されているように解釈される。
RSVP [RFC 2205] is a resource reservation setup protocol designed for an integrated services Internet [RFC 1633]. RSVP is used by a host to request specific quality of service (QoS) from the network for particular application data streams or flows. RSVP is also used by routers to deliver QoS requests to all nodes along the path(s) of the flows and to establish and maintain state to provide the requested service. RSVP requests will generally result in resources being reserved in each node along the data path. RSVP allows particular users to obtain preferential access to network resources, under the control of an admission control mechanism. Permission to make a reservation is based both upon the availability of the requested resources along the path of the data and upon satisfaction of policy rules. Providing policy based admission control mechanism based on user identity or application is one of the prime requirements.
RSVP [RFC 2205]は、統合サービスインターネット[RFC 1633]向けに設計されたリソース予約セットアッププロトコルです。RSVPは、特定のアプリケーションデータストリームまたはフローについて、ネットワークから特定のサービス品質（QO）を要求するためにホストによって使用されます。RSVPは、ルーターがフローのパスに沿ってすべてのノードにQoSリクエストを配信し、要求されたサービスを提供するために状態を確立および維持するためにも使用されます。通常、RSVP要求は、データパスに沿った各ノードにリソースが予約されます。RSVPを使用すると、特定のユーザーは、入場制御メカニズムの制御下で、ネットワークリソースへの優先アクセスを取得できます。予約を行う許可は、データのパスに沿った要求されたリソースの可用性とポリシールールの満足度の両方に基づいています。ユーザーのアイデンティティまたはアプリケーションに基づいて、ポリシーベースの入場管理メカニズムを提供することは、主要な要件の1つです。
In order to solve these problems and implement identity based policy control it is required to identify the user and/or application making a RSVP request.
これらの問題を解決し、IDベースのポリシーコントロールを実装するには、RSVPリクエストを作成するユーザーおよび/またはアプリケーションを特定する必要があります。
This document proposes a mechanism for sending identification information in the RSVP messages and enables authorization decisions based on policy and identity.
このドキュメントは、RSVPメッセージに識別情報を送信するメカニズムを提案し、ポリシーと身元に基づいて認証決定を可能にします。
We describe the authentication policy element (AUTH_DATA) contained in the POLICY_DATA object. User process can generate an AUTH_DATA policy element and gives it to RSVP process (service) on the originating host. RSVP service inserts AUTH_DATA into the RSVP message to identify the owner (user and/or application) making the request for network resources. Network elements, such as routers, authenticate request using the credentials presented in the AUTH_DATA and admit the RSVP message based on admission policy. After a request has been authenticated, first hop router installs the RSVP state and forwards the new policy element returned by the Policy Decision Point (PDP) [POL-FRAME].
policy_dataオブジェクトに含まれる認証ポリシー要素（auth_data）について説明します。ユーザープロセスは、auth_dataポリシー要素を生成し、発信元ホストのRSVPプロセス（サービス）にそれを提供できます。RSVPサービスは、auth_dataをRSVPメッセージに挿入して、所有者（ユーザーおよび/またはアプリケーション）を識別し、ネットワークリソースをリクエストします。ルーターなどのネットワーク要素は、auth_dataで提示された資格情報を使用してリクエストを認証し、入学ポリシーに基づいてRSVPメッセージを認めます。リクエストが認証された後、First Hop RouterはRSVP状態をインストールし、ポリシー決定ポイント（PDP）[Pol-Frame]によって返される新しいポリシー要素を転送します。
POLICY_DATA objects contain policy information and are carried by RSVP messages. A detail description of the format of POLICY_DATA object can be found in "RSVP Extensions for Policy Control" [POL-EXT].
policy_dataオブジェクトにはポリシー情報が含まれており、RSVPメッセージによって伝達されます。policy_Dataオブジェクトの形式の詳細な説明は、「ポリシー制御のためのRSVP拡張機能」[POL-EXT]に記載されています。
In this section, we describe a policy element (PE) called authentication data (AUTH_DATA). AUTH_DATA policy element contains a list of authentication attributes.
このセクションでは、認証データ（auth_data）と呼ばれるポリシー要素（PE）について説明します。auth_dataポリシー要素には、認証属性のリストが含まれています。
+-------------+-------------+-------------+-------------+
| Length | P-Type = Identity Type |
+-------------+-------------+-------------+-------------+
// Authentication Attribute List //
+-------------------------------------------------------+
Length The length of the policy element (including the Length and P-Type) is in number of octets (MUST be a multiple of 4) and indicates the end of the authentication attribute list.
長さポリシー要素の長さ（長さとpタイプを含む）はオクテット数（4の倍数でなければなりません）であり、認証属性リストの終了を示します。
P-Type (Identity Type) Type of identity information contained in this Policy Element supplied as the Policy element type (P-type). The Internet Assigned Numbers Authority (IANA) acts as a registry for policy element types for identity as described in the [POL-EXT]. Initially, the registry contains the following P-Types for identity:
P-Type（IDタイプ）ポリシー要素タイプ（P-Type）として提供されるこのポリシー要素に含まれるID情報のタイプ。インターネットに割り当てられた番号局（IANA）は、[Pol-Ext]で説明されているように、IDのポリシー要素タイプのレジストリとして機能します。最初に、レジストリには、アイデンティティの次のpタイプが含まれています。
2 AUTH_USER Authentication scheme to identify users
2 auth_user認証スキームユーザーを識別します
3 AUTH_APP Authentication scheme to identify applications
3 AUTH_APP認証スキームアプリケーションを識別する
Authentication Attribute List
認証属性リスト
Authentication attributes contain information specific to authentication method and type of AUTH_DATA. The policy element provides the mechanism for grouping a collection of authentication attributes.
認証属性には、認証方法とauth_dataのタイプに固有の情報が含まれています。ポリシー要素は、認証属性のコレクションをグループ化するメカニズムを提供します。
Authentication attributes MUST be encoded as a multiple of 4 octets, attributes that are not a multiple of 4 octets long MUST be padded to a 4-octet boundary.
認証属性は、4オクテットの倍数としてエンコードする必要があります。長さ4オクテットの倍数ではない属性は、4オクセットの境界にパッドで埋める必要があります。
+--------+--------+--------+--------+
| Length | A-Type |SubType |
+--------+--------+--------+--------+
| Value ...
+--------+--------+--------+--------+
Length The length field is two octets and indicates the actual length of the attribute (including the Length and A-Type fields) in number of octets. The length does not include any bytes padding to the value field to make the attribute multiple of 4 octets long.
長さの長さフィールドは2オクテットで、オクテット数の属性の実際の長さ（長さとA型フィールドを含む）を示します。長さには、値フィールドへのバイトパディングは含まれていません。
A-Type Authentication attribute type (A-Type) field is one octet. IANA acts as a registry for A-Types as described in the section 8, IANA Considerations. Initially, the registry contains the following A-Types:
Aタイプ認証属性タイプ（Aタイプ）フィールドは1オクテットです。IANAは、セクション8、IANAの考慮事項で説明されているように、Aタイプのレジストリとして機能します。最初に、レジストリには次のAタイプが含まれています。
1 POLICY_LOCATOR Unique string for locating the admission policy (such as X.500 DN described in [RFC 1779]).
1 Policy_locator入学ポリシーを見つけるための一意の文字列（[RFC 1779]に記載されているX.500 DNなど）。
2 CREDENTIAL User credential such as Kerberos ticket, or digital certificate. Application credential such as application ID.
2 Kerberosチケットやデジタル証明書などの資格ユーザーの資格情報。アプリケーションIDなどのアプリケーション資格情報。
3 DIGITAL_SIGNATURE Digital signature of the authentication data policy element.
3 Digital_Signature認証データポリシー要素のデジタル署名。
4 POLICY_ERROR_OBJECT Detailed information on policy failures.
4 policy_error_objectポリシーの障害に関する詳細情報。
SubType Authentication attribute sub-type field is one octet. Value of SubType depends on A-type.
サブタイプ認証属性サブタイプフィールドは1オクテットです。サブタイプの値はAタイプに依存します。
Value: The value field contains the attribute specific information.
値：値フィールドには、属性固有の情報が含まれています。
POLICY_LOCATOR is used to locate the admission policy for the user or application. Distinguished Name (DN) is unique for each User or application hence a DN is used as policy locator.
policy_locatorは、ユーザーまたはアプリケーションの入場ポリシーを見つけるために使用されます。Distinguished Name（DN）は各ユーザーまたはアプリケーションに一意であるため、DNはポリシーロケーターとして使用されます。
+-------+-------+-------+-------+
| Length |A-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+--------
Length Length of the attribute, which MUST be >= 4.
属性の長さの長さ。これは> = 4でなければなりません。
A-Type POLICY_LOCATOR
a-type policy_locator
SubType Following sub types for POLICY_LOCATOR are defined. IANA acts as a registry for POLICY_LOCATOR sub types as described in the section 8, IANA Considerations. Initially, the registry contains the following sub types for POLICY_LOCATOR:
policy_locatorのサブタイプのサブタイプが定義されています。IANAは、セクション8、IANAの考慮事項で説明されているように、policy_locatorサブタイプのレジストリとして機能します。最初に、レジストリにはpolicy_locatorの次のサブタイプが含まれています。
1 ASCII_DN OctetString contains the X.500 DN as described in the RFC 1779 as an ASCII string.
1 ASCII_DN OctetStringには、RFC 1779でASCII文字列として説明されているようにX.500 DNが含まれています。
2 UNICODE_DN OctetString contains the X.500 DN described in the RFC 1779 as an UNICODE string.
2 unicode_dnオクテッツストリングには、RFC 1779に記載されているx.500 dnがユニコード文字列として含まれています。
3 ASCII_DN_ENCRYPT OctetString contains the encrypted X.500 DN. The Kerberos session key or digital certificate private key is used for encryption. For Kerberos encryption the format is the same as returned from gss_seal [RFC 1509].
3 ASCII_DN_ENCRYPT OctetStringには、暗号化されたX.500 DNが含まれています。Kerberosセッションキーまたはデジタル証明書の秘密キーは、暗号化に使用されます。Kerberosの暗号化の場合、形式はGSS_SEAL [RFC 1509]から返されたものと同じです。
4 UNICODE_DN_ENCRYPT OctetString contains the encrypted UNICODE X.500 DN. The Kerberos session key or digital certificate private key is used for encryption. For Kerberos encryption the format is the same as returned from gss_seal [RFC 1509].
4 unicode_dn_encryptオクターストリングには、暗号化されたUnicode x.500 dnが含まれています。Kerberosセッションキーまたはデジタル証明書の秘密キーは、暗号化に使用されます。Kerberosの暗号化の場合、形式はGSS_SEAL [RFC 1509]から返されたものと同じです。
OctetString The OctetString field contains the DN.
OctetString octetStringフィールドにはDNが含まれています。
CREDENTIAL indicates the credential of the user or application to be authenticated. For Kerberos authentication method the CREDENTIAL object contains the Kerberos session ticket. For public key based authentication this field contains a digital certificate.
資格情報は、ユーザーまたはアプリケーションの資格情報を認証することを示します。Kerberos認証方法の場合、資格情報にはKerberosセッションチケットが含まれています。公開キーベースの認証の場合、このフィールドにはデジタル証明書が含まれています。
A summary of the CREDENTIAL attribute format is shown below. The fields are transmitted from left to right.
資格情報属性形式の概要を以下に示します。フィールドは左から右に送信されます。
+-------+-------+-------+-------+
| Length |A-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+--------
Length Length of the attribute, which MUST be >= 4.
属性の長さの長さ。これは> = 4でなければなりません。
A-Type CREDENTIAL
Aタイプの資格情報
SubType IANA acts as a registry for CREDENTIAL sub types as described in the section 8, IANA Considerations. Initially, the registry contains the following sub types for CREDENTIAL:
サブタイプIANAは、セクション8、IANAの考慮事項で説明されている資格のサブタイプのレジストリとして機能します。当初、レジストリには、資格情報の次のサブタイプが含まれています。
1 ASCII_ID OctetString contains user or application identification in plain ASCII text string.
1 ASCII_ID OctetStringには、プレーンASCIIテキスト文字列にユーザーまたはアプリケーションの識別が含まれています。
2 UNICODE_ID OctetString contains user or application identification in plain UNICODE text string.
2 unicode_idオクターストリングには、プレーンユニコードテキスト文字列にユーザーまたはアプリケーションの識別が含まれています。
3 KERBEROS_TKT OctetString contains Kerberos ticket.
3 kerberos_tktオクターストリングには、Kerberosチケットが含まれています。
4 X509_V3_CERT OctetString contains X.509 V3 digital certificate [X.509].
4 X509_V3_CERTオクターストリングにはX.509 V3デジタル証明書[X.509]が含まれています。
5 PGP_CERT OctetString contains PGP digital certificate.
5 PGP_CERT OctetStringには、PGPデジタル証明書が含まれています。
OctetString The OctetString contains the user or application credential.
OctetString OctetStringには、ユーザーまたはアプリケーションの資格情報が含まれています。
The DIGITAL_SIGNATURE attribute MUST be the last attribute in the attribute list and contains the digital signature of the AUTH_DATA policy element. The digital signature signs all data in the AUTH_DATA policy element up to the DIGITAL_SIGNATURE. The algorithm used to compute the digital signature depends on the authentication method specified by the CREDENTIAL SubType field.
Digital_Signature属性は、属性リストの最後の属性である必要があり、auth_dataポリシー要素のデジタル署名が含まれています。デジタル署名は、auth_dataポリシー要素のすべてのデータにdigital_signatureに署名します。デジタル署名を計算するために使用されるアルゴリズムは、資格情報サブタイプフィールドで指定された認証方法に依存します。
A summary of DIGITAL_SIGNATURE attribute format is described below.
Digital_Signature属性形式の概要については、以下に説明します。
+-------+-------+-------+-------+
| Length |A-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+--------
Length Length of the attribute, which MUST be >= 4.
属性の長さの長さ。これは> = 4でなければなりません。
A-Type DIGITAL_SIGNATURE
a-type digital_signature
SubType No sub types for DIGITAL_SIGNATURE are currently defined. This field MUST be set to 0.
サブタイプDigital_Signatureのサブタイプは現在定義されていません。このフィールドは0に設定する必要があります。
OctetString OctetString contains the digital signature of the AUTH_DATA.
OctetString OctetStringには、auth_dataのデジタル署名が含まれています。
This attribute is used to carry any specific policy control errors generated by a node when processing/validating an Authentication Data Policy Element. When a RSVP policy node (local policy decision point or remote PDP) encounters a request that fails policy control due to its Authentication Policy Element, it SHOULD add a POLICY_ERROR_CODE containing additional information about the reason the failure occurred into the policy element. This will then cause an appropriate PATH_ERROR or RESV_ERROR message to be generated with the policy element and appropriate RSVP error code in the message, which is returned to the request's source.
この属性は、認証データポリシー要素の処理/検証時にノードによって生成された特定のポリシー制御エラーを搭載するために使用されます。RSVPポリシーノード（ローカルポリシー決定ポイントまたはリモートPDP）が、認証ポリシー要素のためにポリシー制御に失敗するリクエストに遭遇すると、障害がポリシー要素に発生した理由に関する追加情報を含むpolicy_error_codeを追加する必要があります。これにより、適切なPATH_ERRORまたはRESV_ERRORメッセージが、リクエストのソースに返されるメッセージ内のポリシー要素と適切なRSVPエラーコードを使用して生成されます。
The AUTH_DATA policy element in the PATH or RSVP message SHOULD not contain the POLICY_ERROR_OBJECT attribute. These are only inserted into PATH_ERROR and RESV_ERROR messages when generated by policy aware intermediate nodes.
パスまたはRSVPメッセージのauth_dataポリシー要素には、policy_error_object属性を含めるべきではありません。これらは、ポリシー認識中間ノードによって生成された場合にのみ、PATH_ERRORおよびRESV_ERRORメッセージに挿入されます。
+----------+----------+----------+----------+
| Length | A-Type | SubType |
+----------+----------+----------+----------+
| 0 (Reserved) | ErrorValue |
+----------+----------+----------+----------+
| OctetString ...
+----------+----------+----------+----------+
Length Length of the attribute, which MUST be >= 8.
属性の長さの長さ。これは> = 8でなければなりません。
A-Type POLICY_ERROR_CODE
a-type policy_error_code
SubType No sub types for POLICY_ERROR_CODE are currently defined. This field MUST be set to 0.
サブタイプpolicy_error_codeのサブタイプは現在定義されていません。このフィールドは0に設定する必要があります。
ErrorValue A 16-bit bit code containing the reason that the policy decision point failed to process the policy element. IANA acts as a registry for ErrorValues as described in section 8, IANA Considerations. Following values have been defined.
エラーバリューポリシーの決定ポイントがポリシー要素の処理に失敗した理由を含む16ビットのコード。IANAは、セクション8、IANAの考慮事項で説明されているエラー数のレジストリとして機能します。次の値が定義されています。
1 ERROR_NO_MORE_INFO No information is available. 2 UNSUPPORTED_CREDENTIAL_TYPE This type of credentials is not supported.
1 ERROR_NO_MORE_INFO情報はありません。2 unsupported_credential_typeこのタイプの資格情報はサポートされていません。
3 INSUFFICIENT_PRIVILEGES The credentials do not have sufficient privilege.
3不足_privileges資格情報には十分な特権がありません。
4 EXPIRED_CREDENTIAL The credential has expired.
4 exped_credentialクレデンシャルが期限切れになっています。
5 IDENTITY_CHANGED Identity has changed.
5 Identity_Changed IDが変更されました。
OctetString The OctetString field contains information from the policy decision point that MAY contain additional information about the policy failure. For example, it may include a human-readable message in the ASCII text.
OctetString OctetStringフィールドには、ポリシーの障害に関する追加情報が含まれる可能性のあるポリシー決定ポイントからの情報が含まれています。たとえば、ASCIIテキストに人間の読み取り可能なメッセージが含まれる場合があります。
Authentication attributes are grouped in a policy element to represent the identity credentials.
認証属性は、ID資格情報を表すためにポリシー要素にグループ化されます。
In simple user authentication method the user login ID (in plain ASCII or UNICODE text) is encoded as CREDENTIAL attribute. A summary of the simple user AUTH_DATA policy element is shown below.
単純なユーザー認証方法では、ユーザーログインID（プレーンASCIIまたはUnicodeテキスト）が資格属性としてエンコードされています。単純なユーザーauth_dataポリシー要素の概要を以下に示します。
+--------------+--------------+--------------+--------------+
| Length | P-type = AUTH_USER |
+--------------+--------------+--------------+--------------+
| Length |POLICY_LOCATOR| SubType |
+--------------+--------------+--------------+--------------+
| OctetString (User's Distinguished Name) ...
+--------------+--------------+--------------+--------------+
| Length |CREDENTIAL | ASCII_ID |
+--------------+--------------+--------------+--------------+
| OctetString (User's login ID) ...
+--------------+--------------+--------------+--------------+
Kerberos [RFC 1510] authentication uses a trusted third party (the Kerberos Distribution Center - KDC) to provide for authentication of the user to a network server. It is assumed that a KDC is present and both host and verifier of authentication information (router or PDP) implement Kerberos authentication.
Kerberos [RFC 1510]認証は、信頼できるサードパーティ（Kerberos Distribution Center -KDC）を使用して、ユーザーのネットワークサーバーへの認証を提供します。KDCが存在し、認証情報（ルーターまたはPDP）のホストと検証者の両方がKerberos認証を実装すると想定されています。
A summary of the Kerberos AUTH_DATA policy element is shown below.
Kerberos auth_dataポリシー要素の概要を以下に示します。
+--------------+--------------+--------------+--------------+
| Length | P-type = AUTH_USER |
+--------------+--------------+--------------+--------------+
| Length |POLICY_LOCATOR| SubType |
+--------------+--------------+--------------+--------------+
| OctetString (User's Distinguished Name) ...
+--------------+--------------+--------------+--------------+
| Length | CREDENTIAL | KERBEROS_TKT |
+--------------+--------------+--------------+--------------+
| OctetString (Kerberos Session Ticket) ...
+--------------+--------------+--------------+--------------+
An RSVP enabled host is configured to construct and insert AUTH_DATA policy element into RSVP messages that designate use of the Kerberos authentication method (KERBEROS_TKT). Upon RSVP session initialization, the user application contacts the KDC to obtain a Kerberos ticket for the next network node or its PDP. A router when generating a RSVP message contacts the KDC to obtain a Kerberos ticket for the next hop network node or its PDP. The identity of the PDP or next network hop can be statically configured, learned via DHCP or maintained in a directory service. The Kerberos ticket is sent to the next network node (which may be a router or host) in a RSVP message. The KDC is used to validate the ticket and authentication the user sending RSVP message.
RSVP有効なホストは、kerberos認証方法（kerberos_tkt）の使用を指定するRSVPメッセージにauth_dataポリシー要素を構築および挿入するように構成されています。RSVPセッションの初期化により、ユーザーアプリケーションはKDCに連絡して、次のネットワークノードまたはそのPDPのKerberosチケットを取得します。RSVPメッセージを生成するときのルーターは、KDCに連絡して、次のホップネットワークノードまたはそのPDPのKerberosチケットを取得します。PDPまたは次のネットワークホップのIDは、静的に構成、DHCPを介して学習するか、ディレクトリサービスで維持できます。Kerberosチケットは、RSVPメッセージで次のネットワークノード（ルーターまたはホストである可能性がある）に送信されます。KDCは、ユーザーがRSVPメッセージを送信するチケットと認証を検証するために使用されます。
In public key based user authentication method digital certificate is encoded as user credentials. The digital signature is used for authenticating the user. A summary of the public key user AUTH_DATA policy element is shown below.
公開キーベースのユーザー認証方法では、デジタル証明書はユーザー資格情報としてエンコードされています。デジタル署名は、ユーザーを認証するために使用されます。公開キーユーザーauth_dataポリシー要素の概要を以下に示します。
+--------------+--------------+--------------+--------------+
| Length | P-type = AUTH_USER |
+--------------+--------------+--------------+--------------+
| Length |POLICY_LOCATOR| SubType |
+--------------+--------------+--------------+--------------+
| OctetString (User's Distinguished Name) ...
+--------------+--------------+--------------+--------------+
| Length | CREDENTIAL | SubType |
+--------------+--------------+--------------+--------------+
| OctetString (User's Digital Certificate) ...
+--------------+--------------+--------------+--------------+
| Length |DIGITAL_SIGN. | 0 |
+--------------+--------------+--------------+--------------+
| OctetString (Digital signature) ...
+--------------+--------------+--------------+--------------+
Public key based authentication assumes following:
公開鍵ベースの認証は次のとおりです。
- RSVP service requestors have a pair of keys (private key and public key).
- RSVPサービスリクエスターには、一対のキー（秘密鍵と公開キー）があります。
- Private key is secured with the user.
- 秘密鍵はユーザーで保護されています。
- 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）には、デジタル証明書を確認する機能があります。
RSVP requestor uses its private key to generate DIGITAL_SIGNATURE. User Authenticators (router, PDP) use the user's public key (stored in the digital certificate) to verify the signature and authenticate the user.
RSVP Requestorは、秘密鍵を使用してDigital_Signatureを生成します。ユーザー認証者（ルーター、PDP）は、ユーザーの公開キー（デジタル証明書に保存）を使用して、署名を確認し、ユーザーを認証します。
The application authentication method encodes the application identification such as an executable filename as plain ASCII or UNICODE text.
Application Authenticationメソッドは、Plain ASCIIまたはUnicodeテキストとして実行可能ファイル名などのアプリケーション識別をエンコードします。
+----------------+--------------+--------------+--------------+
| Length | P-type = AUTH_APP |
+----------------+--------------+--------------+--------------+
| Length |POLICY_LOCATOR| SubType |
+----------------+--------------+--------------+--------------+
| OctetString (Application Identity attributes in
| the form of a Distinguished Name) ...
+----------------+--------------+--------------+--------------+
| Length | CREDENTIAL | ASCII_ID |
+----------------+--------------+--------------+--------------+
| OctetString (Application Id, e.g., vic.exe)
+----------------+--------------+--------------+--------------+
+-----+ +-----+
| PDP |-------+ | PDP |
+-----+ | ................... +-----+
| : : |
+--------+ : Transit : +-------+
+----| Router |------: Network : -------| Router|--+
| +--------+ : : +-------+ |
| | :.................: | |
| | | |
Host A B C D
Figure 1: User and Application Authentication using AUTH_DATA PE
図1：auth_data peを使用したユーザーおよびアプリケーション認証
Network nodes (hosts/routers) generate AUTH_DATA policy elements, contents of which are depend on the identity type used and the authentication method used. These generally contain authentication credentials (Kerberos ticket or digital certificate) and policy locators (which can be the X.500 Distinguished Name of the user or network node or application names). Network nodes generate AUTH_DATA policy element containing the authentication identity when making the RSVP request or forwarding a RSVP message.
ネットワークノード（ホスト/ルーター）は、auth_dataポリシー要素を生成します。その内容は、使用されるIDタイプと使用される認証方法に依存します。これらには通常、認証資格情報（Kerberosチケットまたはデジタル証明書）とポリシーロケーター（ユーザーまたはネットワークノードまたはアプリケーション名のX.500の著名な名前になります）が含まれています。ネットワークノードは、RSVP要求を行うとき、またはRSVPメッセージを転送するときに認証IDを含むauth_dataポリシー要素を生成します。
Network nodes generate user AUTH_DATA policy element using the following rules:
ネットワークノードは、次のルールを使用してユーザーauth_dataポリシー要素を生成します。
1. For unicast sessions the user policy locator is copied from the previous hop. The authentication credentials are for the current network node identity.
1. ユニキャストセッションの場合、ユーザーポリシーロケーターは前のホップからコピーされます。認証資格情報は、現在のネットワークノードID用です。
2. For multicast messages the user policy locator is for the current network node identity. The authentication credentials are for the current network node.
2. マルチキャストメッセージの場合、ユーザーポリシーロケーターは現在のネットワークノードID用です。認証資格情報は、現在のネットワークノード用です。
Network nodes generate application AUTH_DATA policy element using the following rules:
ネットワークノードは、次のルールを使用してアプリケーションauth_dataポリシー要素を生成します。
1. For unicast sessions the application AUTH_DATA is copied from the previous hop.
1. ユニキャストセッションの場合、アプリケーションAUTH_DATAは前のホップからコピーされます。
2. For multicast messages the application AUTH_DATA is either the first application AUTH_DATA in the message or chosen by the PDP.
2. マルチキャストメッセージの場合、アプリケーションAUTH_DATAは、メッセージの最初のアプリケーションAUTH_DATAまたはPDPによって選択されます。
An RSVP message is created as specified in [RFC 2205] with following modifications.
RSVPメッセージは、[RFC 2205]で指定されているように作成され、次の変更が行われます。
1. RSVP message MAY contain multiple AUTH_DATA policy elements.
1. RSVPメッセージには、複数のauth_dataポリシー要素が含まれる場合があります。
2. Authentication policy element (AUTH_DATA) is created and the IdentityType field is set to indicate the identity type in the policy element.
2. 認証ポリシー要素（auth_data）が作成され、IDTYPEフィールドは、ポリシー要素のIDタイプを示すように設定されています。
- DN is inserted as POLICY_LOCATOR attribute.
- DNはpolicy_locator属性として挿入されます。
- Credentials such as Kerberos ticket or digital certificate are inserted as the CREDENTIAL attribute.
- Kerberosチケットやデジタル証明書などの資格情報は、資格属性として挿入されます。
3. POLICY_DATA object (containing the AUTH_DATA policy element) is inserted in the RSVP message in appropriate place. If INTEGRITY object is not computed for the RSVP message then an INTEGRITY object SHOULD be computed for this POLICY_DATA object, as described in the [POL_EXT], and SHOULD be inserted as a Policy Data option.
3. policy_dataオブジェクト（auth_dataポリシー要素を含む）は、適切な場所にrsvpメッセージに挿入されます。整合性オブジェクトがRSVPメッセージに対して計算されていない場合、[pol_ext]で説明されているように、このpolicy_dataオブジェクトに対して整合性オブジェクトを計算する必要があり、ポリシーデータオプションとして挿入する必要があります。
RSVP message is processed as specified in [RFC 2205] with following modifications.
RSVPメッセージは、[RFC 2205]で指定されているように処理され、次の変更が行われます。
1. If router is not 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_DATA policy element. Check the PE type field and return an error if the identity type is not supported.
1. auth_dataポリシー要素を取得します。PEタイプフィールドを確認し、IDタイプがサポートされていない場合はエラーを返します。
2. Verify user credential
2. ユーザーの資格情報を確認します
- Simple authentication: e.g., Get user ID and validate it, or get executable name and validate it.
- 簡単な認証：たとえば、ユーザーIDを取得して検証するか、実行可能な名前を取得して検証します。
- Kerberos: Send the Kerberos ticket to the KDC to obtain the session key. Using the session key authenticate the user.
- Kerberos：KERBEROSチケットをKDCに送信して、セッションキーを取得します。セッションキーを使用して、ユーザーを認証します。
- Public Key: Validate the certificate that it was issued by a trusted Certificate Authority (CA) and authenticate the user or application by verifying the digital signature.
- 公開鍵：信頼できる証明書局（CA）によって発行された証明書を検証し、デジタル署名を確認してユーザーまたはアプリケーションを認証します。
If PDP fails to verify the AUTH_DATA policy element then it MUST return policy control failure (Error Code = 02) to the PEP. The error values are described in [RFC 2205] and [POL-EXT]. Also 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 (see section 3.3.4). The PEP will include this Policy Data object in the outgoing RSVP Error message.
PDPがauth_dataポリシー要素の検証に失敗した場合、ポリシー制御障害（エラーコード= 02）をPEPに返す必要があります。エラー値は[RFC 2205]および[Pol-Ext]で説明されています。また、PDPは、a-type = policy_error_codeを含むauth_dataポリシー要素を含むポリシーデータオブジェクトを提供する必要があります。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 [POL-EXT].
[IANA分類]で概説されているポリシーに続いて、[Pol-Ext]で説明されているように、標準のRSVPポリシー要素（Pタイプ値）がIETFコンセンサスアクションによって割り当てられます。
P-Type AUTH_USER is assigned the value 2. P-Type AUTH_APP is assigned the value 3.
p-type auth_userには値2が割り当てられます。p-type auth_appには値3が割り当てられます。
Following the policies outlined in [IANA-CONSIDERATIONS], authentication attribute types (A-Type) in the range 0-127 are allocated through an IETF Consensus action, A-Type values between 128-255 are reserved for Private Use and are not assigned by IANA.
[IANA-Consididerations]で概説されているポリシーに続いて、0-127の範囲の認証属性タイプ（Aタイプ）はIETFコンセンサスアクションを通じて割り当てられ、128〜255の間のAタイプの値は私的使用のために予約されており、割り当てられていませんイアナによって。
A-Type POLICY_LOCATOR is assigned the value 1. A-Type CREDENTIAL is assigned the value 2. A-Type DIGITAL_SIGNATURE is assigned the value 3. A-Type POLICY_ERROR_OBJECT is assigned the value 4.
a-type policy_locatorには値が割り当てられます。Aタイプの資格情報に値が割り当てられます。AタイプのDigital_Signatureには値3が割り当てられます。
Following the policies outlined in [IANA-CONSIDERATIONS], POLICY_LOCATOR SubType values in the range 0-127 are allocated through an IETF Consensus action, POLICY_LOCATOR SubType values between 128-255 are reserved for Private Use and are not assigned by IANA.
[IANA-Considerations]で概説されているポリシーに続いて、範囲0-127のpolicy_locatorサブタイプ値はIETFコンセンサスアクションを通じて割り当てられます。128〜255の間のpolicy_locatorサブタイプ値は、IANAによって割り当てられていません。
POLICY_LOCATOR SubType ASCII_DN is assigned the value 1, SubType UNICODE_DN is assigned the value 2, SubType ASCII_DN_ENCRYPT is assigned the value 3 and SubType UNICODE_DN_ENCRYPT is assigned the value 4.
policy_locator subtype ascii_dnには値1、subtype unicode_dnに値2、subtype ascii_dn_encryptが値3およびsubtype unicode_dn_encryptが値4に割り当てられます。
Following the policies outlined in [IANA-CONSIDERATIONS], CREDENTIAL SubType values in the range 0-127 are allocated through an IETF Consensus action, CREDENTIAL SubType values between 128-255 are reserved for Private Use and are not assigned by IANA.
[IANA-Consididerations]で概説されているポリシーに続いて、0-127の範囲の資格的サブタイプ値はIETFコンセンサスアクションを通じて割り当てられ、128〜255の間の資格情報サブタイプ値は個人使用のために予約され、IANAによって割り当てられていません。
CREDENTIAL SubType ASCII_ID is assigned the value 1, SubType UNICODE_ID is assigned the value 2, SubType KERBEROS_TKT is assigned the value 3, SubType X509_V3_CERT is assigned the value 4, SubType PGP_CERT is assigned the value 5.
資格情報サブタイプASCII_IDには値1、サブタイプunicode_idに値2が割り当てられ、サブタイプkerberos_tktは値3、サブタイプx509_v3_certに値4、サブタイプpgp_certに値5を割り当てられます。
Following the policies outlined in [IANA-CONSIDERATIONS], ErrorValues in the range 0-32767 are allocated through an IETF Consensus action, ErrorValues between 32768-65535 are reserved for Private Use and are not assigned by IANA.
[IANA分類]で概説されているポリシーに続いて、範囲0-32767のエラー値はIETFコンセンサスアクションによって割り当てられ、32768-65535の間のエラー数は私的使用のために予約され、IANAによって割り当てられていません。
ErrorValue ERROR_NO_MORE_INFO is assigned the value 1, UNSUPPORTED_CREDENTIAL_TYPE is assigned the value 2, INSUFFICIENT_PRIVILEGES is assigned the value 3, EXPIRED_CREDENTIAL is assigned the value 4, and IDENTITY_CHANGED is assigned the value 5.
errorvalue error_no_more_infoには値1、unsupported_credential_typeが値2を割り当て、不十分な_privilegesが値3、exped_credentialは値4に割り当てられ、Identity_Changedが値5に割り当てられます。
The purpose of this memo is to describe a mechanism to authenticate RSVP requests based on user identity in a secure manner. RSVP INTEGRITY object is used to protect the policy object containing user identity information from security (replay) attacks. Combining the AUTH_DATA policy element and the INTEGRITY object results in a secure access control that enforces authentication based on both the identity of the user and the identity of the originating node.
このメモの目的は、安全な方法でユーザーIDに基づいてRSVP要求を認証するメカニズムを記述することです。RSVP Integrityオブジェクトは、ユーザーID情報をセキュリティ（リプレイ）攻撃から含むポリシーオブジェクトを保護するために使用されます。auth_dataポリシー要素と整合性オブジェクトを組み合わせると、ユーザーのIDと発信元ノードのIDの両方に基づいて認証を強制する安全なアクセス制御が得られます。
Simple authentication does not contain credential that can be securely authenticated and is inherently less secured.
単純な認証には、安全に認証され、本質的に保護されていない資格情報が含まれていません。
The Kerberos authentication mechanism is reasonably well secured.
Kerberos認証メカニズムは、かなり安全に保護されています。
User authentication using a public key certificate is known to provide the strongest security.
公開キー証明書を使用したユーザー認証は、最も強力なセキュリティを提供することが知られています。
We would like to thank Andrew Smith, Bob Lindell and many others for their valuable comments on this memo.
このメモに関する貴重なコメントについて、Andrew Smith、Bob Lindell、その他多くの人々に感謝します。
[ASCII] Coded Character Set -- 7-Bit American Standard Code for Information Interchange, ANSI X3.4- 1986.
[ASCII]コード化された文字セット-ANSI X3.4- 1986の情報交換のための7ビットアメリカ標準コード。
[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月。
[POL-EXT] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[Pol-Ext] Herzog、S。、「ポリシー管理のためのRSVP拡張」、RFC 2750、2000年1月。
[POL-FRAME] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy-based Admission Control RSVP", RFC 2753, January 2000.
[Pol-Frame] Yavatkar、R.、Pendarakis、D。、およびR. Guerin、「ポリシーベースの入場管理RSVPのフレームワーク」、RFC 2753、2000年1月。
[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認証サービス（V5）」、RFC 1510、1993年9月。
[RFC 1704] Haller, N. and R. Atkinson, "On Internet Authentication", RFC 1704, October 1994.
[RFC 1704]ハラー、N。およびR.アトキンソン、「インターネット認証について」、RFC 1704、1994年10月。
[RFC 1779] Killie, S., "A String Representation of Distinguished Names", RFC 1779, March 1995.
[RFC 1779]キリー、S。、「著名な名前の文字列表現」、RFC 1779、1995年3月。
[RFC 2205] Braden, R., 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.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[RFC 2209] Braden, R. and L. Zhang, "Resource ReSerVation Protocol (RSVP) - Version 1 Message Processing Rules", RFC 2209, September 1997.
[RFC 2209] Braden、R。およびL. Zhang、「リソース予約プロトコル（RSVP） - バージョン1メッセージ処理ルール」、RFC 2209、1997年9月。
[RFC 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 2751] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 2751, January 2000.
[RFC 2751] Herzog、S。、「シグナル前の先制優先政策要素」、RFC 2751、2000年1月。
[UNICODE] The Unicode Consortium, "The Unicode Standard, Version 2.0", Addison-Wesley, Reading, MA, 1996.
[Unicode] Unicode Consortium、「Unicode Standard、バージョン2.0」、Addison-Wesley、Reading、MA、1996。
[X.509] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 2459, January 1999.
[X.509] Housley、R.、Ford、W.、Polk、W。and D. Solo、「インターネットX.509公開キーインフラストラクチャ証明書とCRLプロファイル」、RFC 2459、1999年1月。
[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
Satyendra Yadav Intel, JF3-206 2111 NE 25th Avenue Hillsboro, OR 97124
Satyendra Yadav Intel、JF3-206 2111 NE 25th Avenue Hillsboro、または97124
EMail: Satyendra.Yadav@intel.com
Raj Yavatkar
Intel, JF3-206
2111 NE 25th Avenue
Hillsboro, OR 97124
EMail: Raj.Yavatkar@intel.com
Ramesh Pabbati Microsoft 1 Microsoft Way Redmond, WA 98054
Ramesh Pabbati Microsoft 1 Microsoft Way Redmond、WA 98054
EMail: rameshpa@microsoft.com
Peter Ford Microsoft 1 Microsoft Way Redmond, WA 98054
ピーターフォードマイクロソフト1マイクロソフトウェイレドモンド、ワシントン州98054
EMail: peterf@microsoft.com
Tim Moore Microsoft 1 Microsoft Way Redmond, WA 98054
ティムムーアマイクロソフト1マイクロソフトウェイレドモンド、ワシントン州98054
EMail: timmoore@microsoft.com
Shai Herzog PolicyConsulting.Com 200 Clove Rd. New Rochelle, NY 10801
Shai Herzog PolicyConsulting.com 200 Clove Rd。ニューロシェル、ニューヨーク10801
EMail: herzog@policyconsulting.com
Rodney Hess Intel, BD1 28 Crosby Drive Bedford, MA 01730
ロドニー・ヘス・インテル、BD1 28クロスビー・ドライブ・ベッドフォード、マサチューセッツ州01730
EMail: rodney.hess@intel.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
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エディター機能の資金は現在、インターネット協会によって提供されています。