Network Working Group S. Yadav
Request for Comments: 2752 R. Yavatkar
Category: Standards Track Intel
R. Pabbati
P. Ford
T. Moore
Microsoft
S. Herzog
IPHighway
January 2000
Identity Representation for RSVP
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 (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
This document describes the representation of identity information in POLICY_DATA object [POL-EXT] for supporting policy based admission control in 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オブジェクト[POL-EXT]における識別情報の表現を記述する。アイデンティティ表現の目標を確実に所有者と通信処理（例えば、ユーザID）のアプリケーションを識別し、安全な方法でRSVPメッセージ（PATHまたはRESV）にこの情報を伝えるために、システム上のプロセスを可能にすることです。私たちは、RSVPポリシー要素としてのアイデンティティのエンコーディングを記述します。私たちは、マルチキャストマージされたフローのアイデンティティポリシー要素を生成する処理ルールを記述します。その後、我々は、Kerberosや公開鍵ベースのユーザー認証メカニズムのためのユーザーIDの表現を記述します。要約すると、我々は、動作設定で、このアイデンティティ情報の使用を記載しています。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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は、特定のアプリケーションのデータストリームまたはフローのネットワークからのサービスの特定品質（QoS）を要求するためにホストによって使用されます。 RSVPはまた、流れの経路（S）に沿ってすべてのノードにQoS要求を提供し、要求されたサービスを提供するために状態を確立し、維持するためにルータにより使用されます。 RSVP要求は一般に、データパスに沿った各ノードに確保されたリソースになります。 RSVPは、アドミッション制御機構の制御下で、特定のユーザーがネットワークリソースへの優先アクセスを得ることができます。予約を行うための許可は、両方のデータのとポリシー・ルールの満足時にパスに沿って要求されたリソースの可用性に基づいています。ユーザーのアイデンティティやアプリケーションに基づいたポリシーベースのアドミッション制御メカニズムを提供することは、首相の要件の一つです。
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.
これらの問題を解決し、アイデンティティベースのポリシー制御を実現するために、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サービスは、ネットワークリソースを要求する所有者（ユーザおよび/またはアプリケーション）を識別するために、RSVPメッセージにAUTH_DATAを挿入します。ルータなどのネットワーク要素は、アドミッションポリシーに基づいて、RSVPメッセージをAUTH_DATAに提示した資格情報を使用して要求を認証し、認めます。要求が認証された後、最初のホップルータは、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.
このセクションでは、我々は、ポリシーエレメント（PE）と呼ばれる認証データ（AUTH_DATA）を記述する。 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型識別情報（アイデンティティタイプ）タイプポリシー要素型（P型）として供給されます。 [POL-EXT]に記載されているようにIANA（Internet Assigned Numbers Authority）は同一のポリシーエレメントタイプのレジストリとして作用します。最初は、レジストリは、アイデンティティのために、次のP-タイプが含まれています。
1 AUTH_USER Authentication scheme to identify users
ユーザを識別するために1つのAUTH_USER認証スキーム
2 AUTH_APP Authentication scheme to identify applications
アプリケーションを識別するために2 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.
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つのオクテットであり、オクテットの数（長さおよびタイプフィールドを含む）属性の実際の長さを示します。長さが長く4つのオクテットの属性複数を作るために、値フィールドに任意のバイトのパディングが含まれていません。
A-Type Authentication attribute type (A-Type) field is one octet. IANA acts as a registry for A-Types as described in the section 9, IANA Considerations. Initially, the registry contains the following A-Types:
型認証は、タイプ（A型）フィールドは1つのオクテットである属性。セクション9、IANAの考慮事項に記載されているようにIANAは、Aタイプのレジストリとして作用します。最初は、レジストリには、以下のA-タイプが含まれています。
1 POLICY_LOCATOR Unique string for locating the
admission policy (such as X.500 DN
described in [RFC 1779]).
2 CREDENTIAL User credential such as Kerberos ticket, or digital certificate. Application credential such as application ID.
そのようなKerberosチケット、またはデジタル証明書など2 CREDENTIALユーザーの資格情報。アプリケーション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つのオクテットである属性。サブタイプの値は型によって異なります。
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は、ユーザーやアプリケーションのための入場方針を見つけるために使用されます。識別名（DN）は、DNを政策ロケータとして使用され、したがって、各ユーザまたはアプリケーションのために独特です。
+-------+-------+-------+-------+
| Length |A-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+--------
Length Length of the attribute, which MUST be >= 4.
> = 4でなければならない属性の長さの長さ、。
A-Type POLICY_LOCATOR
型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 9, IANA Considerations. Initially, the registry contains the following sub types for POLICY_LOCATOR:
POLICY_LOCATORのためのサブタイプを以下のサブタイプが定義されています。セクション9、IANAの考慮事項に記載されているようにIANAはPOLICY_LOCATORサブタイプのレジストリとして作用します。最初は、レジストリはPOLICY_LOCATORのための次のサブタイプが含まれています。
1 ASCII_DN OctetString contains the X.500 DN as described
in the RFC 1779 as an ASCII string.
2 UNICODE_DN OctetString contains the X.500 DN described in the RFC 1779 as an UNICODE string.
2 UNICODE_DN OctetStringには、X.500 DNは、Unicode文字列としてRFC 1779に記載含ま。
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が含まれています。ケルベロスセッションキーまたはデジタル証明書の秘密鍵は、暗号化に使用されます。ケルベロス暗号化の形式は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 OctetStringには、暗号化されたUNICODE X.500 DNが含まれています。ケルベロスセッションキーまたはデジタル証明書の秘密鍵は、暗号化に使用されます。ケルベロス暗号化の形式は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.
CREDENTIALは、ユーザーまたはアプリケーションの資格情報が認証されることを示しています。 Kerberos認証方式の資格のオブジェクトは、Kerberosセッションチケットが含まれています。公開鍵ベースの認証の場合、このフィールドには、デジタル証明書が含まれています。
A summary of the CREDENTIAL attribute format is shown below. The fields are transmitted from left to right.
CREDENTIAL属性形式の概要は以下の通りです。フィールドは左から右に送信されます。
+-------+-------+-------+-------+
| Length |A-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+--------
Length Length of the attribute, which MUST be >= 4.
> = 4でなければならない属性の長さの長さ、。
A-Type CREDENTIAL
型CREDENTIAL
SubType IANA acts as a registry for CREDENTIAL sub types as described in the section 9, IANA Considerations. Initially, the registry contains the following sub types for CREDENTIAL:
セクション9、IANAの考慮事項に記載されているようにサブタイプIANAはCREDENTIALサブタイプのレジストリとして作用します。最初は、レジストリは、資格証明のために、次のサブタイプが含まれています。
1 ASCII_ID OctetString contains user or application
identification in plain ASCII text string.
2 UNICODE_ID OctetString contains user or application identification in plain UNICODE text string.
2 UNICODE_ID OctetStringには、プレーンUnicodeテキスト文字列内のユーザまたはアプリケーション識別情報を含んでいます。
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 OctetStringには、[X.509] X.509 V3デジタル証明書を含みます。
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方針要素のデジタル署名が含まれていなければなりません。デジタル署名サインDIGITAL_SIGNATUREまでAUTH_DATA方針要素内のすべてのデータ。デジタル署名を計算するために使用されるアルゴリズムはCREDENTIALサブタイプフィールドによって指定された認証方式に依存します。
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でなければならない属性の長さの長さ、。
ti3 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.
PATHまたはRSVPメッセージにAUTH_DATA方針要素はPOLICY_ERROR_OBJECT属性を含めることはできません。ポリシー認識中間ノードによって生成されたとき、これらのみPATH_ERRORとRESV_ERRORメッセージに挿入されます。
+----------+----------+----------+----------+
| Length | A-Type |SubType(0)|
+----------+----------+----------+----------+
| 0 (Reserved) | ErrorValue |
+----------+----------+----------+----------+
| OctetString ...
+----------+----------+----------+----------+
Length Length of the attribute, which MUST be >= 8.
> = 8でなければならない属性の長さの長さ、。
A-Type POLICY_ERROR_CODE
型POLICY_ERROR_CODE
ErrorValue A 32-bit bit code containing the reason that the policy decision point failed to process the policy element. Following values have been defined.
ポリシー決定ポイントは、ポリシー要素を処理するのに失敗した理由を含む32ビットのビットコードをErrorValue。以下の値が定義されています。
1 ERROR_NO_MORE_INFO No information is available.
2 UNSUPPORTED_CREDENTIAL_TYPE This type of credentials is
not supported.
3 INSUFFICIENT_PRIVILEGES The credentials do not have sufficient privilege.
図3は、資格情報が十分な権限を持っていないINSUFFICIENT_PRIVILEGES。
4 EXPIRED_CREDENTIAL The credential has expired.
4 EXPIRED_CREDENTIAL資格の有効期限が切れています。
5 IDENTITY_CHANGED Identity has changed.
5 IDENTITY_CHANGEDアイデンティティが変更されました。
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.
認証属性は、アイデンティティの認証情報を表現するためにポリシー要素にグループ化されています。
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.
簡単なユーザ認証方法で（プレーンASCIIまたはUnicodeテキストで）ユーザーのログインIDはCREDENTIAL属性として符号化されています。簡単なユーザ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.
ネットワーク・サーバへのユーザの認証を提供するために - ケルベロス[RFC 1510]認証は、信頼できる第三者（KDCのKerberos物流センター）を使用しています。 KDCが存在し、両方のホストとの認証情報の検証（ルータまたはPDP）は、Kerberos認証を実装することを想定しています。
A summary of the Kerberos 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 | 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チケットを取得します。 KDCは、ネクストホップネットワークノードまたはそのPDPのKerberosチケットを取得するためにRSVPメッセージの連絡先を生成するルータ。 PDPまたは次のネットワークホップのアイデンティティは静的に構成することができ、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).
- 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.
- 検証（PDPまたはルータ）は、デジタル証明書を検証する能力を有します。
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リクエスタはDIGITAL_SIGNATUREを生成するために、その秘密鍵を使用しています。ユーザーオーセンティケータ（ルータ、PDP）は、署名を検証し、ユーザーを認証するために（デジタル証明書に格納されている）ユーザーの公開鍵を使用しています。
The application authentication method encodes the application identification such as an executable filename as plain ASCII or UNICODE text.
アプリケーション認証方法は、プレーン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
AUTH_DATA PEを使用して、ユーザーとアプリケーションの認証：図1
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方針要素、使用される同一のタイプ及び使用される認証方法に依存しているの内容を生成します。これらは、一般的に認証証明書（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.ユニキャストセッションのためのユーザポリシーロケータは前のホップからコピーされます。認証資格情報は、現在のネットワーク・ノード・アイデンティティのためのものです。
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.マルチキャストメッセージのために、ユーザポリシーロケータは、現在のネットワーク・ノード・アイデンティティのためです。認証資格情報は、現在のネットワーク・ノードのためのものです。
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 [RFC2205] with following modifications.
以下のように変更して、[RFC2205]で指定されるようにRSVPメッセージが作成されます。
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）が作成されたIdentityTypeフィールドは、ポリシー要素に同一のタイプを示すように設定されています。
- 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チケットやデジタル証明書などの資格情報はCREDENTIAL属性として挿入されています。
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.
（AUTH_DATAポリシーエレメントを含む）3. POLICY_DATAオブジェクトが適切な場所にRSVPメッセージに挿入されています。 INTEGRITYオブジェクトはRSVPメッセージのために計算されていない場合、INTEGRITYオブジェクトは[POL_EXT]に記載されているように、このPOLICY_DATAオブジェクトについて計算されるべきであり、ポリシーデータオプションとして挿入されます。
RSVP message is processed as specified in [RFC2205] with following modifications.
RSVPメッセージは、以下のように変更して、[RFC2205]で指定されるように処理されます。
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.ルータが認識してポリシーではない場合、それはPDPにRSVPメッセージを送信し、応答を待つべきです。ルータがポリシー気付かない場合、それは、ポリシーデータオブジェクトを無視し、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タイプフィールドをチェックして、アイデンティティタイプがサポートされていない場合はエラーを返します。
- 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.
- ケルベロス：セッションキーを取得するためにKDCにKerberosチケットを送信します。セッションキーを使用すると、ユーザーを認証します。
- 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方針要素を検証するために失敗した場合、それはPEPにポリシー制御の失敗（エラーコード= 02）を返さなければなりません。エラー値は、[RFC 2205]と[POL-EXT]に記載されています。また、PDPは、型とAUTH_DATA方針要素を含むポリシーデータオブジェクトを提供する必要があり=ポリシー制御不良の詳細を含むPOLICY_ERROR_CODE（セクション3.3.4を参照）。 PEPは、発信RSVPエラーメッセージにこのポリシーデータオブジェクトが含まれます。
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-考察]に概説された方針以下、認証は範囲0〜127の型（タイプ）の属性はIETF Consensus動作を通じて割り当てられ、128-255の間の型の値は、プライベート使用のために予約され、割り当てられていませんIANAによります。
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-考察]に概説された方針以下、範囲0〜127でPOLICY_LOCATORサブタイプ値はIETFコンセンサス作用によって割り当てられ、128-255間POLICY_LOCATORサブタイプ値は、私的使用のために予約されており、IANAによって割り当てられていません。
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-考察]に概説された方針以下、範囲0〜127で資格サブタイプ値は、IETF Consensus動作を介して割り当てられ、128-255間CREDENTIALサブタイプ値は、私的使用のために予約されており、IANAによって割り当てられていません。
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方針要素とユーザのアイデンティティおよび発信ノードのアイデンティティの両方に基づいて認証を実行安全なアクセス制御でINTEGRITYオブジェクト結果を組み合わせます。
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.
私たちは、このメモの貴重なコメントをアンドリュー・スミス、ボブ・リンデルおよび多くの他に感謝したいと思います。
[ASCII] Coded Character Set -- 7-Bit American Standard Code for Information Interchange, ANSI X3.4- 1986.
[ASCII]コード化文字セット - 情報交換のための7ビットの米国標準コード、ANSI 1986 X3.4-。
[IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[IANA-考察] 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]ヘルツォーク、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.ゲラン、 "ポリシーベースのアドミッション制御のRSVPのためのフレームワーク"、RFC 2753、2000年1月。
[RFC 1510] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[RFC 1510]コールズ、J.及びC.ノイマン、 "ケルベロスネットワーク認証サービス（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]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.とS.ヤミン、 "リソース予約プロトコル（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]ブレーデン、R.とL.チャン、 "資源予約プロトコル（RSVP） - バージョン1つのメッセージ処理ルール"、RFC 2209、1997年9月。
[UNICODE] The Unicode Consortium, "The Unicode Standard, Version 2.0", Addison-Wesley, Reading, MA, 1996.
[UNICODE]ユニコードコンソーシアム、 "Unicode規格、バージョン2.0"、アディソン・ウェスリー、リーディング、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.、フォード、W.、ポーク、W.およびD.ソロ、 "インターネット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ヤダヴインテル、Jf3-206 2111 25日Avenuaヒルズボロ、および97124
EMail: Satyendra.Yadav@intel.com
メールアドレス：Satyendra.Yadav@intel.com
Raj Yavatkar Intel, JF3-206 2111 NE 25th Avenue Hillsboro, OR 97124
ラジYawatkarインテル、Jf3-206 2111 25日Avenuaヒルズボロ、および97124
EMail: Raj.Yavatkar@intel.com
メールアドレス：Raj.Yavatkar@intel.com
Ramesh Pabbati Microsoft 1 Microsoft Way Redmond, WA 98054
ラメシュPabbatiマイクロソフト1マイクロソフト道ワシントン州レッドモンド98054
EMail: rameshpa@microsoft.com
メールアドレス：rameshpa@microsoft.com
Peter Ford Microsoft 1 Microsoft Way Redmond, WA 98054
ピーター・フォードマイクロソフト1マイクロソフト道ワシントン州レッドモンド98054
EMail: peterf@microsoft.com
メールアドレス：peterf@microsoft.com
Tim Moore Microsoft 1 Microsoft Way Redmond, WA 98054
ちｍ もおれ みｃろそｆｔ １ みｃろそｆｔ わｙ れｄもんｄ、 わ ９８０５４
EMail: timmoore@microsoft.com
メールアドレス：timmoore@microsoft.com
Shai Herzog IPHighway, Inc. 55 New York Avenue Framingham, MA 01701
シャイヘルツォークIPHighway社55ニューヨーク・アベニューフラミンガム、MA 01701
EMail: herzog@iphighway.com
メールアドレス：herzog@iphighway.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。