RFC2752 日本語訳
2752 Identity Representation for RSVP. S. Yadav, R. Yavatkar, R.Pabbati, P. Ford, T. Moore, S. Herzog. January 2000. (Format: TXT=33954 bytes) (Obsoleted by RFC3182) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
Yadavがコメントのために要求するワーキンググループS.をネットワークでつないでください: 2752年のR.Yavatkarカテゴリ: 標準化過程インテルR.Pabbati P.フォードT.ムーアマイクロソフトS.ハーツォグIPHighway2000年1月
Identity Representation for RSVP
RSVPのアイデンティティ表現
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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]のアイデンティティ情報の表現について説明します。 アイデンティティ表現の目標はシステムの上のプロセスがしっかりと交信プロセス(例えば、ユーザイド)の所有者とアプリケーションを特定して、安全な方法でRSVPメッセージのこの情報(PATHかRESV)を伝えるのを許容することです。 私たちはRSVP方針要素としてアイデンティティのコード化を記述します。 私たちは、マルチキャストのためのアイデンティティ方針要素に合併している流れを生成するために処理規則について説明します。 次に、私たちはケルベロスのためにユーザアイデンティティの表現について説明します、そして、Public Keyはユーザー認証メカニズムの拠点を置きました。概要では、私たちは操作上の設定でのこのアイデンティティ情報の使用について説明します。
1. Conventions used in this document
1. 本書では使用されるコンベンション
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC-2119]で説明されるように本書では解釈されることであるべきですか?
Yadav, et al. Standards Track [Page 1] RFC 2752 Identity Representation for RSVP January 2000
Yadav、他 規格は2000年1月にRSVPのRFC2752アイデンティティ表現を追跡します[1ページ]。
2. Introduction
2. 序論
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[RFC2205]は統合サービスインターネット[RFC1633]に設計された資源予約セットアッププロトコルです。 RSVPは特定用途データ・ストリームのために、ネットワークから特定のサービスの質(QoS)を要求するのにホストによって使用されるか、または流れます。 要求されたサービスを提供するために状態をまた、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.
これらの問題を解決して、アイデンティティがベースの方針コントロールであると実装するために、それが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を挿入します。 ルータなどのネットワーク要素は、AUTH_DATAに提示された資格証明書を使用することで要求を認証して、入場方針に基づくRSVPメッセージを認めます。 要求が認証された後に、最初のホップルータはPolicy Decision Point(PDP)[POL-FRAME]で新しい政策要素が返したRSVP状態とフォワードをインストールします。
3. Policy Element for Authentication Data
3. 認証データのための方針要素
3.1 Policy Data Object Format
3.1 方針データ・オブジェクト形式
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メッセージによって運ばれます。 「方針コントロールのためのRSVP拡張子」[POL EXT]でPOLICY_DATAオブジェクトの形式の詳細記述を見つけることができます。
Yadav, et al. Standards Track [Page 2] RFC 2752 Identity Representation for RSVP January 2000
Yadav、他 規格は2000年1月にRSVPのRFC2752アイデンティティ表現を追跡します[2ページ]。
3.2 Authentication Data Policy Element
3.2 認証データ方針要素
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 //
+-------------------------------------------------------+
+-------------+-------------+-------------+-------------+ | 長さ| P-タイプはアイデンティティタイプと等しいです。| +-------------+-------------+-------------+-------------+ //認証属性リスト//+-------------------------------------------------------+
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.
方針要素(Lengthと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:
このPolicy Elementに含まれたアイデンティティ情報のP-タイプ(アイデンティティType)タイプはPolicyとして要素型(P-タイプ)を供給しました。 インターネットAssigned民数記Authority(IANA)がアイデンティティのために中で説明されるように方針要素型のための登録として機能する、[POL-EXT。] 初めは、登録はアイデンティティのための以下のP-タイプを含みます:
1 AUTH_USER Authentication scheme to identify users
1 AUTH_USER Authenticationは、ユーザを特定するのを計画します。
2 AUTH_APP Authentication scheme to identify
applications
2 AUTH_APP Authenticationは、アプリケーションを特定するのを計画します。
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の認証方法とタイプに、特定の情報を含んでいます。 方針要素は認証属性の収集を分類するのにメカニズムを提供します。
3.3 Authentication Attributes
3.3 認証属性
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 ... +--------+--------+--------+--------+
+--------+--------+--------+--------+ | 長さ| 1タイプです。|SubType| +--------+--------+--------+--------+ | 値… +--------+--------+--------+--------+
Yadav, et al. Standards Track [Page 3] RFC 2752 Identity Representation for RSVP January 2000
Yadav、他 規格は2000年1月にRSVPのRFC2752アイデンティティ表現を追跡します[3ページ]。
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つの八重奏であり、八重奏の数における、属性(LengthとA-タイプ分野を含んでいる)の実際の長さを示します。 長さは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:
Authentication属性タイプ(A-タイプ)がさばくA-タイプはある八重奏です。 IANA Considerations、IANAはA-タイプのためにセクション9で説明されるように登録として機能します。 初めは、登録は以下のA-タイプを含みます:
1 POLICY_LOCATOR Unique string for locating the
admission policy (such as X.500 DN
described in [RFC 1779]).
1 LOCATOR Uniqueが入場方針([RFC1779]で説明されたX.500 DNなどの)の場所を見つけるように結ぶPOLICY_。
2 CREDENTIAL User credential such as Kerberos
ticket, or digital certificate.
Application credential such as
application ID.
ケルベロスチケット、またはデジタル証明書などの2CREDENTIAL User資格証明書。 アプリケーションIDなどのアプリケーション資格証明書。
3 DIGITAL_SIGNATURE Digital signature of the
authentication data policy element.
認証データ方針要素の3Digital_SIGNATURE Digital署名。
4 POLICY_ERROR_OBJECT Detailed information on policy
failures.
4 政策の失敗のPOLICY_ERROR_OBJECT Detailed情報。
SubType
Authentication attribute sub-type field is one octet. Value of
SubType depends on A-type.
SubType Authentication属性サブタイプ分野は1つの八重奏です。 SubTypeの値はA-タイプに頼っています。
Value:
The value field contains the attribute specific information.
値: 値の分野は属性特殊情報を含んでいます。
3.3.1 Policy Locator
3.3.1 方針ロケータ
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は、ユーザかアプリケーションのための入場方針の場所を見つけるのに使用されます。 各Userかアプリケーションに、顕著なName(DN)はユニークです、したがって、DNが方針ロケータとして使用されます。
+-------+-------+-------+-------+ | Length |A-Type |SubType| +-------+-------+-------+-------+ | OctetString ... +-------+-------+-------+--------
+-------+-------+-------+-------+ | 長さ|1タイプです。|SubType| +-------+-------+-------+-------+ | OctetString… +-------+-------+-------+--------
Yadav, et al. Standards Track [Page 4] RFC 2752 Identity Representation for RSVP January 2000
Yadav、他 規格は2000年1月にRSVPのRFC2752アイデンティティ表現を追跡します[4ページ]。
Length
Length of the attribute, which MUST be >= 4.
属性の長さのLength。(それは、>=4であるに違いない)。
A-Type
POLICY_LOCATOR
1タイプの方針_ロケータ
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のためのSubType Following潜水艦タイプは定義されます。 IANA Considerations、POLICY_LOCATORが代理をするので登録がセクション9で説明されるようにタイプされるようにIANAは行動します。 初めは、登録はPOLICY_LOCATORのための以下の潜水艦タイプを含みます:
1 ASCII_DN OctetString contains the X.500 DN as described
in the RFC 1779 as an ASCII string.
1 RFC1779でASCIIストリングと説明されるようにASCII_DN OctetStringはX.500 DNを含んでいます。
2 UNICODE_DN OctetString contains the X.500 DN described in
the RFC 1779 as an UNICODE string.
2 ユニコード_DN OctetStringはRFC1779でユニコードストリングと説明された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を含んでいます。 ケルベロスのセッションの主要であるかデジタルの証明書秘密鍵は暗号化に使用されます。 ケルベロス暗号化において、形式はgss_シールから返すのと[RFC1509]同じです。
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 ユニコード_DN_ENCRYPT OctetStringは暗号化されたUNICODE X.500 DNを含んでいます。 ケルベロスのセッションの主要であるかデジタルの証明書秘密鍵は暗号化に使用されます。 ケルベロス暗号化において、形式はgss_シールから返すのと[RFC1509]同じです。
OctetString
The OctetString field contains the DN.
OctetString、OctetString分野はDNを含んでいます。
3.3.2 Credential
3.3.2 資格証明書
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は、認証されるためにユーザかアプリケーションの資格証明書を示します。 ケルベロス認証方法のために、CREDENTIALオブジェクトはケルベロスセッションチケットを含んでいます。 公開鍵に基づいている認証のために、この分野はデジタル証明書を含んでいます。
A summary of the CREDENTIAL attribute format is shown below. The fields are transmitted from left to right.
CREDENTIAL属性形式の概要は以下に示されます。 野原は左から右まで伝えられます。
Yadav, et al. Standards Track [Page 5] RFC 2752 Identity Representation for RSVP January 2000
Yadav、他 規格は2000年1月にRSVPのRFC2752アイデンティティ表現を追跡します[5ページ]。
+-------+-------+-------+-------+ | Length |A-Type |SubType| +-------+-------+-------+-------+ | OctetString ... +-------+-------+-------+--------
+-------+-------+-------+-------+ | 長さ|1タイプです。|SubType| +-------+-------+-------+-------+ | OctetString… +-------+-------+-------+--------
Length
Length of the attribute, which MUST be >= 4.
属性の長さのLength。(それは、>=4であるに違いない)。
A-Type
CREDENTIAL
1タイプの資格証明書
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:
IANA Considerations、CREDENTIALが代理をするので登録がセクション9で説明されるようにタイプされるようにSubType IANAは行動します。 初めは、登録はCREDENTIALのための以下の潜水艦タイプを含みます:
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 ユニコード_ID OctetStringは明瞭なユニコードテキスト文字列にユーザかアプリケーション識別を含んでいます。
3 KERBEROS_TKT OctetString contains Kerberos ticket.
3 ケルベロス_TKT OctetStringはケルベロスチケットを含んでいます。
4 X509_V3_CERT OctetString contains X.509 V3 digital
certificate [X.509].
4 X509_V3_CERT OctetStringは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はユーザかアプリケーション資格証明書を含んでいます。
3.3.3 Digital Signature
3.3.3 デジタル署名
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 SubType分野によって指定された認証方法によります。
A summary of DIGITAL_SIGNATURE attribute format is described below.
Digital_SIGNATURE属性形式の概要は以下で説明されます。
Yadav, et al. Standards Track [Page 6] RFC 2752 Identity Representation for RSVP January 2000
Yadav、他 規格は2000年1月にRSVPのRFC2752アイデンティティ表現を追跡します[6ページ]。
+-------+-------+-------+-------+ | Length |A-Type |SubType| +-------+-------+-------+-------+ | OctetString ... +-------+-------+-------+--------
+-------+-------+-------+-------+ | 長さ|1タイプです。|SubType| +-------+-------+-------+-------+ | OctetString… +-------+-------+-------+--------
Length
Length of the attribute, which MUST be >= 4.
属性の長さのLength。(それは、>=4であるに違いない)。
ti3 A-Type
DIGITAL_SIGNATURE
ti3A-タイプDigital_SIGNATURE
SubType
No sub types for DIGITAL_SIGNATURE are currently defined. This
field MUST be set to 0.
Digital_SIGNATUREのためのSubTypeいいえ潜水艦タイプは現在、定義されます。 この分野を0に設定しなければなりません。
OctetString
OctetString contains the digital signature of the AUTH_DATA.
OctetString OctetStringはAUTH_DATAのデジタル署名を含んでいます。
3.3.4 Policy Error Object
3.3.4 方針誤りオブジェクト
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.
この属性は、Authentication Data Policy Elementを処理するか、または有効にするときノードによって生成されたどんな特定保険証券コントロール誤りも運ぶのに使用されます。 RSVP方針ノード(ローカルの政策決定ポイントかリモートPDP)が要求に遭遇すると、やり損ない方針がAuthentication Policy Elementのため制御されて、それがSHOULDであることは失敗が方針要素に起こった理由のPOLICY_ERROR_CODE含有追加している情報を加えます。 そして、これはメッセージで方針要素と適切なRSVPエラーコードで生成される適切なPATH_ERRORかRESV_ERRORメッセージを引き起こすでしょう。(それは、要求のソースに返されます)。
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のAUTH_DATA方針要素かSHOULDがPOLICY_ERROR_OBJECT属性を含んでいないというRSVPメッセージ。 方針の意識している中間的ノードによって生成されると、これらはPATH_ERRORとRESV_ERRORメッセージに挿入されるだけです。
+----------+----------+----------+----------+ | Length | A-Type |SubType(0)| +----------+----------+----------+----------+ | 0 (Reserved) | ErrorValue | +----------+----------+----------+----------+ | OctetString ... +----------+----------+----------+----------+
+----------+----------+----------+----------+ | 長さ| 1タイプです。|SubType(0)| +----------+----------+----------+----------+ | 0(予約されます)| ErrorValue| +----------+----------+----------+----------+ | OctetString… +----------+----------+----------+----------+
Length
Length of the attribute, which MUST be >= 8.
属性の長さのLength。(それは、>=8であるに違いない)。
Yadav, et al. Standards Track [Page 7] RFC 2752 Identity Representation for RSVP January 2000
Yadav、他 規格は2000年1月にRSVPのRFC2752アイデンティティ表現を追跡します[7ページ]。
A-Type
POLICY_ERROR_CODE
1タイプの方針_誤り_コード
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.
政策決定が指す理由を含むErrorValueのA32ビットのビット・コードが方針要素を処理しませんでした。 次の値は定義されました。
1 ERROR_NO_MORE_INFO No information is available.
2 UNSUPPORTED_CREDENTIAL_TYPE This type of credentials is
not supported.
1 ERROR_いいえ、_MORE_INFOいいえ情報は利用可能です。 2 資格証明書のUNSUPPORTED_CREDENTIAL_TYPE Thisタイプはサポートされません。
3 INSUFFICIENT_PRIVILEGES The credentials do not have
sufficient privilege.
3 資格証明書がするINSUFFICIENT_PRIVILEGESは十分な特権を持っていません。
4 EXPIRED_CREDENTIAL The credential has expired.
4EXPIRED_CREDENTIAL、資格証明書は期限が切れました。
5 IDENTITY_CHANGED Identity has changed.
5 IDENTITY_CHANGED Identityは変化しました。
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テキストに人間読み込み可能なメッセージを含むかもしれません。
4. Authentication Data Formats
4. 認証データ形式
Authentication attributes are grouped in a policy element to represent the identity credentials.
認証属性は、アイデンティティ資格証明書を表すために方針要素で分類されます。
4.1 Simple User Authentication
4.1 簡単なユーザー認証
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かユニコードテキストの)は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) ... +--------------+--------------+--------------+--------------+
+--------------+--------------+--------------+--------------+ | 長さ| P-タイプはAUTH_ユーザと等しいです。| +--------------+--------------+--------------+--------------+ | 長さ|方針_ロケータ| SubType| +--------------+--------------+--------------+--------------+ | OctetString(ユーザの分類名)… +--------------+--------------+--------------+--------------+ | 長さ|資格証明書| ASCII_ID| +--------------+--------------+--------------+--------------+ | OctetString(ユーザのログインID)… +--------------+--------------+--------------+--------------+
Yadav, et al. Standards Track [Page 8] RFC 2752 Identity Representation for RSVP January 2000
Yadav、他 規格は2000年1月にRSVPのRFC2752アイデンティティ表現を追跡します[8ページ]。
4.2 Kerberos User Authentication
4.2 ケルベロスユーザー認証
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.
ケルベロス[RFC1510]認証は、ネットワークサーバにユーザの認証に備えるのに、信頼できる第三者機関(ケルベロスDistributionセンター--KDC)を使用します。KDCが存在していて、ホストと認証情報(ルータかPDP)の検証の両方が、ケルベロスが認証であると実装すると思われます。
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) ... +--------------+--------------+--------------+--------------+
+--------------+--------------+--------------+--------------+ | 長さ| P-タイプはAUTH_ユーザと等しいです。| +--------------+--------------+--------------+--------------+ | 長さ|方針_ロケータ| SubType| +--------------+--------------+--------------+--------------+ | OctetString(ユーザの分類名)… +--------------+--------------+--------------+--------------+ | 長さ| 資格証明書| ケルベロス_TKT| +--------------+--------------+--------------+--------------+ | OctetString(ケルベロスセッションチケット)… +--------------+--------------+--------------+--------------+
4.2.1. Operational Setting using Kerberos Identities
4.2.1. ケルベロスのアイデンティティを使用する操作上の設定
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の可能にされたホストは、認証方法(ケルベロス_TKT)にケルベロスの使用を指定するRSVPメッセージにAUTH_DATA方針要素を構成して、挿入するために構成されます。 RSVPセッション初期化のときに、ユーザアプリケーションは、次のネットワーク・ノードかそのPDPのケルベロスチケットを得るためにKDCに連絡します。 RSVPメッセージを生成するとき、ルータは、次のホップネットワーク・ノードかそのPDPのケルベロスチケットを得るためにKDCに連絡します。 PDPか次のネットワークホップのアイデンティティを静的に構成するか、DHCPを通して学習されるか、またはディレクトリサービスで維持できます。 RSVPメッセージの次のネットワーク・ノード(ルータかホストであるかもしれない)にケルベロスチケットを送ります。 KDCはチケットを有効にするのに使用されます、そして、ユーザ送付RSVPメッセージは認証が使用されます。
4.3 Public Key based User Authentication
4.3 公共のKeyはUser Authenticationを基礎づけました。
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方針要素の概要は以下に示されます。
Yadav, et al. Standards Track [Page 9] RFC 2752 Identity Representation for RSVP January 2000
Yadav、他 規格は2000年1月にRSVPのRFC2752アイデンティティ表現を追跡します[9ページ]。
+--------------+--------------+--------------+--------------+ | 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) ... +--------------+--------------+--------------+--------------+
+--------------+--------------+--------------+--------------+ | 長さ| P-タイプはAUTH_ユーザと等しいです。| +--------------+--------------+--------------+--------------+ | 長さ|方針_ロケータ| SubType| +--------------+--------------+--------------+--------------+ | OctetString(ユーザの分類名)… +--------------+--------------+--------------+--------------+ | 長さ| 資格証明書| SubType| +--------------+--------------+--------------+--------------+ | OctetString(ユーザのデジタル証明書)… +--------------+--------------+--------------+--------------+ | 長さ|Digital_は署名します。 | 0 | +--------------+--------------+--------------+--------------+ | OctetString(デジタル署名)… +--------------+--------------+--------------+--------------+
4.3.1. Operational Setting for public key based authentication
4.3.1. 公開鍵のための操作上のSettingは認証を基礎づけました。
Public key based authentication assumes following:
以下に続くベースの認証が仮定する公開鍵
- RSVP service requestors have a pair of keys (private key and
public key).
- RSVPサービス要請者は1組のキー(秘密鍵と公開鍵)を持っています。
- 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.
- 公開鍵はデジタル証明書と信じられた党で保存されて、認証局(カリフォルニア)はこれらのデジタル証明書を発行します。
- 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であると生成するのに秘密鍵を使用します。 ユーザAuthenticators(ルータ、PDP)は、署名について確かめて、ユーザを認証するのに、ユーザの公開鍵(デジタル証明書では、保存される)を使用します。
4.4 Simple Application Authentication
4.4 簡単なアプリケーション認証
The application authentication method encodes the application identification such as an executable filename as plain ASCII or UNICODE text.
アプリケーション認証方法は明瞭なASCIIかユニコードテキストとしての実行可能なファイル名などのアプリケーション識別をコード化します。
Yadav, et al. Standards Track [Page 10] RFC 2752 Identity Representation for RSVP January 2000
Yadav、他 規格は2000年1月にRSVPのRFC2752アイデンティティ表現を追跡します[10ページ]。
+----------------+--------------+--------------+--------------+ | 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) +----------------+--------------+--------------+--------------+
+----------------+--------------+--------------+--------------+ | 長さ| P-タイプはAUTH_装置と等しいです。| +----------------+--------------+--------------+--------------+ | 長さ|方針_ロケータ| SubType| +----------------+--------------+--------------+--------------+ | OctetString(| Distinguished Nameの形のアプリケーションIdentity属性)… +----------------+--------------+--------------+--------------+ | 長さ| 資格証明書| ASCII_ID| +----------------+--------------+--------------+--------------+ | OctetString(アプリケーションId、例えば、vic.exe)+----------------+--------------+--------------+--------------+
5. Operation
5. 操作
+-----+ +-----+
| PDP |-------+ | PDP |
+-----+ | ................... +-----+
| : : |
+--------+ : Transit : +-------+
+----| Router |------: Network : -------| Router|--+
| +--------+ : : +-------+ |
| | :.................: | |
| | | |
Host A B C D
+-----+ +-----+ | PDP|-------+ | PDP| +-----+ | ................... +-----+ | : : | +--------+ : トランジット: +-------+ +----| ルータ|------: 以下をネットワークでつないでください。 -------| ルータ|--+ | +--------+ : : +-------+ | | | :.................: | | | | | | B C Dを接待してください。
Figure 1: User and Application Authentication using AUTH_DATA PE
図1: AUTH_データ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に方針要素、コンテンツを生成するそうするネットワーク・ノードはタイプが使用したアイデンティティとメソッドが使用した認証によります。 一般に、これらは認証資格証明書(ケルベロスチケットかデジタル証明書)と方針ロケータ(ユーザ、ネットワーク・ノードまたはアプリケーション名のX.500 Distinguished Nameであるかもしれない)を含んでいます。 RSVP要求か推進をRSVPメッセージにするとき、ネットワーク・ノードは、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. マルチキャストメッセージに関しては、ユーザ方針ロケータは現在のネットワーク・ノードのアイデンティティのためのものです。 認証資格証明書は現在のネットワーク・ノードのためのものです。
Yadav, et al. Standards Track [Page 11] RFC 2752 Identity Representation for RSVP January 2000
Yadav、他 規格は2000年1月にRSVPのRFC2752アイデンティティ表現を追跡します[11ページ]。
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はPDPによるマルチキャストメッセージが、メッセージか選ばれるところの最初のアプリケーションAUTH_DATAです。
6. Message Processing Rules
6. メッセージ処理規則
6.1 Message Generation (RSVP Host)
6.1メッセージ世代(RSVPホスト)
An RSVP message is created as specified in [RFC2205] with following modifications.
RSVPメッセージは[RFC2205]で次の変更で指定されるように作成されます。
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)は作成されます、そして、IdentityType分野が方針要素でアイデンティティタイプを示すように設定されます。
- DN is inserted as POLICY_LOCATOR attribute.
- DNはLOCATORが結果と考えるPOLICY_として挿入されます。
- Credentials such as Kerberos ticket or digital certificate are
inserted as the CREDENTIAL attribute.
- ケルベロスチケットかデジタル証明書などの資格証明書は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.
3. POLICY_DATAオブジェクト(AUTH_DATA方針要素を含んでいる)は適切な場所のRSVPメッセージに挿入されます。 RSVPがその時INTEGRITYオブジェクトSHOULDを通信させるのでINTEGRITYオブジェクトが計算されないなら、このPOLICY_DATAオブジェクトのために計算されてください、[POL_EXT]、およびSHOULDで説明されるように。Policy Dataオプションとして、挿入されます。
6.2 Message Reception (Router)
6.2 メッセージレセプション(ルータ)
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. ルータであるなら、次に、意識している方針はそれではありません。SHOULDは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メッセージを処理し続けてください。
Yadav, et al. Standards Track [Page 12] RFC 2752 Identity Representation for RSVP January 2000
Yadav、他 規格は2000年1月にRSVPのRFC2752アイデンティティ表現を追跡します[12ページ]。
6.3 Authentication (Router/PDP)
6.3 認証(ルータ/PDP)
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タイプ分野をチェックしてください、そして、アイデンティティタイプがサポートされないなら、誤りを返してください。
2. Verify user credential
2. ユーザ資格証明書について確かめてください。
- Simple authentication: e.g. Get user ID and validate it, or get
executable name and validate it.
- 簡易認証: そして、例えば、GetユーザID、それを有効にするか、実行可能な名前を得てください、そして、またはそれを有効にしてください。
- Kerberos: Send the Kerberos ticket to the KDC to obtain the
session key. Using the session key authenticate the user.
- ケルベロス: ケルベロスチケットを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.
- 公開鍵: それが信じられたCertificate Authority(カリフォルニア)によって発行された証明書を有効にしてください、そして、デジタル署名について確かめることによって、ユーザかアプリケーションを認証してください。
7. Error Signaling
7. 誤りシグナリング
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方針要素について確かめないなら、それは方針コントロール失敗(誤りCode=02)をPEPに返さなければなりません。 誤り値は[RFC2205]と[POL-EXT]で説明されます。 また、PDP SHOULDはPOLICY_ERROR_A-タイプ=CODEがPolicy Controlの故障に関するその他の詳細を含んでいるAUTH_DATA Policy Elementを含む方針データ・オブジェクトを供給します(セクション3.3.4を見てください)。 PEPは送信するRSVP ErrorメッセージにこのPolicy Dataオブジェクトを含むでしょう。
8. IANA Considerations
8. IANA問題
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-CONSIDERATIONS]に概説された方針に従って、IETF Consensus動作で範囲0-127の認証属性タイプ(A-タイプ)を割り当てて、128-255の間のA-タイプ値は、兵士のUseのために予約されて、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-CONSIDERATIONS]に概説された方針に従って、IETF Consensus動作で範囲0-127のPOLICY_LOCATOR SubType値を割り当てて、128-255の間のPOLICY_LOCATOR SubType値は、兵士のUseのために予約されて、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-CONSIDERATIONS]に概説された方針に従って、IETF Consensus動作で範囲0-127のCREDENTIAL SubType値を割り当てて、128-255の間のCREDENTIAL SubType値は、兵士のUseのために予約されて、IANAによって割り当てられません。
Yadav, et al. Standards Track [Page 13] RFC 2752 Identity Representation for RSVP January 2000
Yadav、他 規格は2000年1月にRSVPのRFC2752アイデンティティ表現を追跡します[13ページ]。
9. Security Considerations
9. セキュリティ問題
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.
このメモの目的は安全な方法でユーザのアイデンティティに基づくRSVP要求を認証するためにメカニズムについて説明することです。 RSVP INTEGRITYオブジェクトは、セキュリティ(再生)攻撃からユーザアイデンティティ情報を含む政策目的を保護するのに使用されます。 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.
ケルベロス認証機構は合理的によく固定されています。
User authentication using a public key certificate is known to provide the strongest security.
公開鍵証明書を使用するユーザー認証が最も強いセキュリティを提供するのが知られています。
10. Acknowledgments
10. 承認
We would like to thank Andrew Smith, Bob Lindell and many others for their valuable comments on this memo.
このメモの彼らの貴重なコメントについてアンドリュー・スミス、ボブ・リンデル、および多くの他のものに感謝申し上げます。
11. References
11. 参照
[ASCII] Coded Character Set -- 7-Bit American Standard
Code for Information Interchange, ANSI X3.4-
1986.
[ASCII]は文字コードをコード化しました--7ビットの情報交換用米国標準コード、ANSI X3.4 1986。
[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問題部に書くためのガイドライン」、BCP26、RFC2434(1998年10月)。
[POL-EXT] Herzog, S., "RSVP Extensions for Policy
Control", RFC 2750, January 2000.
[POL-EXT] ハーツォグ、S.、「方針コントロールのためのRSVP拡張子」、RFC2750、2000年1月。
[POL-FRAME] Yavatkar, R., Pendarakis, D. and R. Guerin, "A
Framework for Policy-based Admission Control
RSVP", RFC 2753, January 2000.
[POLフレーム] YavatkarとR.とPendarakisとD.とR.ゲラン、「方針ベースの入場コントロールRSVPのためのフレームワーク」、RFC2753、2000年1月。
[RFC 1510] Kohl, J. and C. Neuman, "The Kerberos Network
Authentication Service (V5)", RFC 1510,
September 1993.
[RFC1510] コールとJ.とC.ヌーマン、「ケルベロスネットワーク認証サービス(V5)」、RFC1510 1993年9月。
[RFC 1704] Haller, N. and R. Atkinson, "On Internet
Authentication", RFC 1704, October 1994.
[RFC1704] ハラーとN.とR.アトキンソン、「インターネット認証」、RFC1704、1994年10月。
Yadav, et al. Standards Track [Page 14] RFC 2752 Identity Representation for RSVP January 2000
Yadav、他 規格は2000年1月にRSVPのRFC2752アイデンティティ表現を追跡します[14ページ]。
[RFC 1779] Killie, S., "A String Representation of
Distinguished Names", RFC 1779, March 1995.
[RFC1779] Killie、S.、「分類名のストリング表現」、RFC1779、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.
[RFC2205] ブレーデン、R.、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
[RFC 2209] Braden, R. and L. Zhang, "Resource ReSerVation
Protocol (RSVP) - Version 1 Message Processing
Rules", RFC 2209, September 1997.
[RFC2209] ブレーデン、R.、およびL.チャン、「資源予約プロトコル(RSVP)--バージョン1メッセージ処理は統治します」、RFC2209、1997年9月。
[UNICODE] The Unicode Consortium, "The Unicode Standard,
Version 2.0", Addison-Wesley, Reading, MA,
1996.
[ユニコード] ユニコード共同体、「ユニコード規格、バージョン2インチ、アディソン-ウエスリー、読書、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.と一人で生活して、「インターネットX.509公開鍵基盤の証明書とCRLは輪郭を描く」D.、RFC2459、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/IEC9594-8
Yadav, et al. Standards Track [Page 15] RFC 2752 Identity Representation for RSVP January 2000
Yadav、他 規格は2000年1月にRSVPのRFC2752アイデンティティ表現を追跡します[15ページ]。
12. Author Information
12. 作者情報
Satyendra Yadav Intel, JF3-206 2111 NE 25th Avenue Hillsboro, OR 97124
Satyendra Yadavインテル、第25JF3-206 2111Ne Avenueヒルズバロ、または97124
EMail: Satyendra.Yadav@intel.com
メール: Satyendra.Yadav@intel.com
Raj Yavatkar Intel, JF3-206 2111 NE 25th Avenue Hillsboro, OR 97124
主権Yavatkar諜報、第25JF3-206 2111Ne Avenueヒルズバロ、または97124
EMail: Raj.Yavatkar@intel.com
メール: Raj.Yavatkar@intel.com
Ramesh Pabbati Microsoft 1 Microsoft Way Redmond, WA 98054
Ramesh 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
ティムムーアマイクロソフト1マイクロソフト道、レッドモンド、ワシントン 98054
EMail: timmoore@microsoft.com
メール: timmoore@microsoft.com
Shai Herzog IPHighway, Inc. 55 New York Avenue Framingham, MA 01701
ShaiハーツォグIPHighway Inc.55ニューヨークAvenueフレイミングハム、MA 01701
EMail: herzog@iphighway.com
メール: herzog@iphighway.com
Yadav, et al. Standards Track [Page 16] RFC 2752 Identity Representation for RSVP January 2000
Yadav、他 規格は2000年1月にRSVPのRFC2752アイデンティティ表現を追跡します[16ページ]。
13. Full Copyright Statement
13. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Yadav, et al. Standards Track [Page 17]
Yadav、他 標準化過程[17ページ]
一覧
スポンサーリンク
