RFC3324 日本語訳
3324 Short Term Requirements for Network Asserted Identity. M. Watson. November 2002. (Format: TXT=21964 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Watson Request for Comments: 3324 Nortel Networks Category: Informational November 2002
コメントを求めるワーキンググループM.ワトソン要求をネットワークでつないでください: 3324 ノーテルはカテゴリをネットワークでつなぎます: 情報の2002年11月
Short Term Requirements for Network Asserted Identity
アイデンティティであると断言されたネットワークのための短期間要件
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
Abstract
要約
A Network Asserted Identity is an identity initially derived by a Session Initiation Protocol (SIP) network intermediary as a result of an authentication process. This document describes short term requirements for the exchange of Network Asserted Identities within networks of securely interconnected trusted nodes and to User Agents securely connected to such networks.
Network Asserted Identityは初めは認証過程の結果、Session Initiationプロトコル(SIP)ネットワーク仲介者によって引き出されたアイデンティティです。 このドキュメントはしっかりとインタコネクトされた信じられたノードのネットワーク以内としっかりとそのようなネットワークに接続されたUserエージェントにNetwork Asserted Identitiesの交換のための短期間要件について説明します。
There is no requirement for identities asserted by a UA in a SIP message to be anything other than the user's desired alias.
ユーザの必要な別名以外に、何かであるSIPメッセージでUAによって断言されたアイデンティティのための要件が全くありません。
Watson Informational [Page 1] RFC 3324 Requirements for Network Asserted Identity November 2002
2002年11月にアイデンティティであると断言されたネットワークのためのワトソン情報[1ページ]のRFC3324Requirements
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Identity . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Network Asserted Identity . . . . . . . . . . . . . . . . . . 3
2.3 Trust Domains . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4 Spec(T) . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Generation of Networks Asserted Identity . . . . . . . . . . . 7
4. Transport of Network Asserted Identity . . . . . . . . . . . . 7
4.1 Sending of Networks Asserted Identity within a Trust Domain . 7
4.2 Receiving of Network Asserted Identity within a Trust Domain . 7
4.3 Sending of Network Asserted Identity to entities outside a
Trust Domain . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4 Receiving of Network Asserted Identity by a node outside the
Trust Domain . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Parties with Network Asserted Identities . . . . . . . . . . . 8
6. Types of Network Asserted Identity . . . . . . . . . . . . . . 8
7. Privacy of Network Asserted Identity . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
Normative References . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 11
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 定義. . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1のアイデンティティ. . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2ネットワークは、アイデンティティ. . . . . . . . . . . . . . . . . . 3 2.3が信頼ドメイン. . . . . . . . . . . . . . . . . . . . . . . . 4 2.4仕様(T). . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3であると断言しました。 ネットワーク世代はアイデンティティ. . . . . . . . . . . 7 4について断言しました。 Trust Domain. . . . . . . . . . . . . . . . . . . . . . . . . 8 5の外のノードによるNetwork Asserted IdentityのTrust Domain.74.4Receivingの外の実体へのNetwork Asserted IdentityのTrust Domain.74.3Sendingの中のNetwork Asserted IdentityのTrust Domain.74.2Receivingの中のNetworks Asserted IdentityのNetwork Asserted Identity.74.1Sendingの輸送。 ネットワークがある党はアイデンティティ. . . . . . . . . . . 8 6について断言しました。 ネットワークのタイプはアイデンティティ. . . . . . . . . . . . . . 8 7について断言しました。 ネットワークのプライバシーはアイデンティティ. . . . . . . . . . . . . 9 8について断言しました。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 9 9。 IANA問題. . . . . . . . . . . . . . . . . . . . . 10 10。 承認. . . . . . . . . . . . . . . . . . . . . . . 10引用規格. . . . . . . . . . . . . . . . . . . . . 10作者のアドレスの.10の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 11
1. Introduction
1. 序論
SIP [1] allows users to assert their identity in a number of ways e.g., using the From: header. However, there is no requirement for these identities to be anything other than the users desired alias.
SIP[1]がユーザに彼らのアイデンティティについて多くの方法で断言させる、例えば、From:を使用すること。 ヘッダー。 しかしながら、通称望まれていたユーザ以外に、これらのアイデンティティが何かであるという要件が全くありません。
An authenticated identity of a user can be obtained using SIP Digest Authentication (or by other means). However, UAs do not always have the necessary key information to authenticate another UA.
SIP Digest Authentication(または他の手段で)を使用することでユーザの認証されたアイデンティティを得ることができます。 しかしながら、UAsには、いつも、別のUAを認証する必要な主要な情報があるというわけではありません。
A Network Asserted Identity is an identity initially derived by a SIP network intermediary as a result of an authentication process. This may or may not be based on SIP Digest authentication. This document describes short term requirements for the exchange of Network Asserted Identities within networks of securely interconnected trusted nodes and also to User Agents with secure connections to such networks.
Network Asserted Identityは初めは認証過程の結果、SIPネットワーク仲介者によって引き出されたアイデンティティです。 これはSIP Digest認証に基づくかもしれません。 このドキュメントはそのようなネットワークとの安全な接続と共にしっかりとインタコネクトされた信じられたノードのネットワーク以内とUserエージェントにもNetwork Asserted Identitiesの交換のための短期間要件について説明します。
Watson Informational [Page 2] RFC 3324 Requirements for Network Asserted Identity November 2002
2002年11月にアイデンティティであると断言されたネットワークのためのワトソン情報[2ページ]のRFC3324Requirements
Such a network is described in this document as a Trust Domain and we present a strict definition of trust and Trust Domain for the purposes of this document. These short-term requirements provide only for the exchange of Network Asserted Identity within a Trust Domain and to an entity directly connected to the trust domain.
そのようなネットワークは本書ではTrust Domainとして記述されています、そして、私たちはこのドキュメントの目的のために信頼とTrust Domainの厳しい定義を提示します。 これらの短期的な要件はTrust Domain以内と直接信頼ドメインに接続された実体にNetwork Asserted Identityの交換だけに備えます。
General requirements for transport of Network Asserted Identities on the Internet are out of scope of this document.
このドキュメントの範囲の外にインターネットにおけるNetwork Asserted Identitiesの輸送のための一般要件があります。
2. Definitions
2. 定義
2.1 Identity
2.1 アイデンティティ
An Identity, for the purposes of this document, is a sip:, sips: or tel: URI, and optionally a Display Name.
このドキュメントの目的がaが以下をちびちび飲むということであるので、Identityはちびちび飲みます: または、tel: URI、任意に、Display Name。
The URI MUST be meaningful to the domain identified in the URI (in the case of sip: or sips: URIs) or the owner of the E.164 number (in the case of tel: URIs), in the sense that when used as a SIP Request-URI in a request sent to that domain/number range owner, it would cause the request to be routed to the user/line that is associated with the identity, or to be processed by service logic running on that user's behalf.
URIはURIで特定されたドメインに重要であるに違いありません。(: 一口: 要求におけるSIP Request-URIがそのドメイン/数の範囲所有者に発信したので使用されると、使用されるだろうという意味においてE.164番号(tel: URIの場合における)において、より自己のURIで要求を発送する一口の場合では、ユーザ/がアイデンティティで関連づけられたそれを裏打ちするか、または処理されるために、そのユーザの代理で動く論理を修理してください。
If the URI is a sip: or sips: URI, then depending on the local policy of the domain identified in the URI, the URI MAY identify some specific entity, such as a person.
URIが一口であるなら: 一口: URI、次に、URIで特定されたドメインのローカルの方針によって、URIは何らかの特定の実体を特定するかもしれません、人のように。
If the URI is a tel: URI, then depending on the local policy of the owner of the number range within which the telephone number lies, the number MAY identify some specific entity, such as a telephone line. However, it should be noted that identifying the owner of the number range is a less straightforward process than identifying the domain which owns a sip: or sips: URI.
URIがtel:であるなら URI、次に、電話番号がある数の範囲の所有者のローカルの方針によって、数は何らかの特定の実体を特定するかもしれません、電話回線のように。 しかしながら、数の範囲の所有者を特定するのが、一口を所有しているドメインを特定するほど簡単でないプロセスであることに注意されるべきです: 一口: ユリ。
2.2 Network Asserted Identity
2.2 アイデンティティであると断言されたネットワーク
A Network Asserted Identity is an identity derived by a SIP network entity as a result of an authentication process, which identifies the authenticated entity in the sense defined in Section 2.1.
Network Asserted Identityはセクション2.1で定義された意味における認証された実体を特定する認証過程の結果、SIPネットワーク実体によって引き出されたアイデンティティです。
In the case of a sip: or sips: URI, the domain included in the URI MUST be within the Trust Domain.
一口の場合で: 一口: Trust Domainの中にURI、URIにドメインを含んでいるのがあるに違いありません。
In the case of a tel: URI, the owner of the E.164 number in the URI MUST be within the Trust Domain.
tel:の場合で URI、URIにおけるE.164番号の所有者はTrust Domainの中にいるに違いありません。
Watson Informational [Page 3] RFC 3324 Requirements for Network Asserted Identity November 2002
2002年11月にアイデンティティであると断言されたネットワークのためのワトソン情報[3ページ]のRFC3324Requirements
The authentication process used, or at least it's reliability/ strength, is a known feature of the Trust Domain using the Network Asserted Identity mechanism i.e., in the language of 2.3 below, it is defined in Spec(T).
使用される認証過程、または少なくともそれの信頼性/強さがNetwork Asserted Identityメカニズムを使用するTrust Domainの知られている特徴です、すなわち、2.3未満の言葉を借りて言えば、それはSpec(T)で定義されます。
2.3 Trust Domains
2.3 信頼ドメイン
A Trust Domain for the purposes of Network Asserted Identity is a set of SIP nodes (UAC, UAS, proxies or other network intermediaries) that are trusted to exchange Network Asserted Identity information in the sense described below.
Network Asserted Identityの目的のためのTrust Domainは以下で説明された意味における交換Network Asserted Identity情報に任せられる1セットのSIPノード(UAC、UAS、プロキシまたは他のネットワーク仲介者)です。
A node can be a member of a Trust Domain, T, only if the node is know to be compliant to a certain set of specifications, Spec(T), which characterize the handling of Network Asserted Identity within the Trust Domain, T.
ノードはTrust Domainのメンバーであるかもしれません、T、ノードが、ある仕様、Trust Domainの中でNetwork Asserted Identityの取り扱いを特徴付けるSpec(T)に言いなりになるのを知ることである場合にだけ、T。
Trust Domains are constructed by human beings who know the properties of the equipment they are using/deploying. In the simplest case, a Trust Domain is a set of devices with a single owner/operator who can accurately know the behaviour of those devices.
信頼Domainsはそれらが使用するか、または配布している設備の特性を知っている人間によって組み立てられます。 最も簡単な場合では、Trust Domainは正確にそれらのデバイスのふるまいを知ることができる単独の所有者/オペレータがいる1セットのデバイスです。
Such simple Trust Domains may be joined into larger Trust Domains by bi-lateral agreements between the owners/operators of the devices.
そのような簡単なTrust Domainsはデバイスの所有者/オペレータの間の双方の協定で、より大きいTrust Domainsに接合されるかもしれません。
We say a node is 'trusted' (with respect to a given Trust Domain) if and only if it is a member of that domain.
私たちが、ノードが'信じられる'(与えられたTrust Domainに関して)と言う、それである場合にだけ、そのドメインのメンバーはそうです。
We say that a node, A, in the domain is 'trusted by' a node, B, (or 'B trusts A') if and only if:
私たちが、ノード、そのドメインのAが'信じられて'aノード、Bであると言う、(または、'B受託A')唯一、:
1. there is a secure connection between the nodes, AND
1. ノードの間の安全な接続、ANDがあります。
2. B has configuration information indicating that A is a member
of the Trust Domain.
2. Bには、AがTrust Domainのメンバーであることを示す設定情報があります。
Note that B may or may not be a member of the Trust Domain. For example, B may be a UA which trusts a given network intermediary, A (e.g., its home proxy).
BがTrust Domainのメンバーであるかもしれないことに注意してください。 例えば、Bは与えられたネットワーク仲介者を信じるUA、Aであるかもしれません(例えば、ホームプロキシ)。
A 'secure connection' in this context means that messages cannot be read by third parties, cannot be modified by third parties without detection and that B can be sure that the message really did come from A. The level of security required is a feature of the Trust Domain i.e., it is defined in Spec(T).
第三者は検出なしで第三者がメッセージを読み込むことができないこの文脈手段における'安全な接続'を変更できません、そして、Bがメッセージが本当にセキュリティのレベルが必要としたA.から来たのを確信している場合があるのは、Trust Domainの特徴です、そして、すなわち、それはSpec(T)で定義されます。
Watson Informational [Page 4] RFC 3324 Requirements for Network Asserted Identity November 2002
2002年11月にアイデンティティであると断言されたネットワークのためのワトソン情報[4ページ]のRFC3324Requirements
Within this context, SIP signaling information received by one node FROM a node that it trusts is known to have been generated and passed through the network according to the procedures of the particular specification set Spec(T), and therefore can be known to be valid, or at least as valid as specified in the specifications Spec(T).
この文脈の中では、SIPシグナリング情報は、特記仕様書セットSpec(T)の手順に応じて、生成されたそれが信じるノードが知られている1つのノードのFROMによって受け取られて、ネットワークに通り抜けて、したがって、同じくらい有効であるか、仕様Spec(T)で指定されるのとまたは少なくとも同じくらい有効であることを知ることができます。
Equally, a node can be sure that signaling information passed TO a node that it trusts will be handled according to the procedures of Spec(T).
等しく、ノードはシグナリング情報が扱われるSpec(T)の手順によると、それが信じるノードをTOに通過したのを確信している場合があります。
For these capabilities to be useful, Spec(T) must contain requirements as to how the Network Asserted Identity is generated, how its privacy is protected and how its integrity is maintained as it is passed around the network. A reader of Spec(T) can then make an informed judgement about the authenticity and reliability of Network Asserted Information received from the Trust Domain T.
役に立つこれらの能力のために、Network Asserted Identityがどのように発生しているか、そして、プライバシーがどのように保護されるか、そして、それがネットワークの周りで通過されるとき保全がどのように維持されるかに関してSpec(T)は要件を含まなければなりません。 そして、Spec(T)の読者はNetwork Assertedの信憑性と信頼性に関する知識がある判断をTrust Domain Tから受け取られた情報にすることができます。
The term 'trusted' (with respect to a given Trust Domain) can be applied to a given node in an absolute sense - it is just equivalent to saying the node is a member of the Trust Domain. However, the node itself does not know whether another arbitrary node is 'trusted', even within the Trust Domain. It does know about certain nodes with which it has secure connections as described above.
絶対意味で'信じられる'という(与えられたTrust Domainに関して)用語を与えられたノードに適用できます--ノードがTrust Domainのメンバーであると言うのにそれはただ同等です。 しかしながら、ノード自体は、別の任意のノードがTrust Domainの中でさえ'信じられるかどうか'を知りません。 それは安全な接続が上で説明されるようにあるあるノードに関して知っています。
With the definition above, statements such as 'A trusted node SHALL ...' are just shorthand for 'A node compliant to this specification SHALL...'.
上の定義、'信じられたノードSHALL'などの声明で…''この仕様SHALLへの対応することのノードのためのまさしく速記はそうです''.
Statements such as 'When a node receives information from a trusted node...' are NOT valid, because one node does not have complete knowledge about all the other nodes in the trust domain.
'ノードがいつaから情報を受け取るかがノードを信じなどだったことなど'の声明…'あるノードが信頼ドメインに他のすべてのノードに関する完全な知識を持っていないので、NOTは有効です'?
Statements such as 'When a node receives information from another node that it trusts...' ARE valid, and should be interpreted according to the criteria (1) and (2) above.
ノードが別のノードからの'…を信じるという情報を受け取るという'いつなどの声明'有効であり、評価基準(1)と(2)に従って、上で解釈されるべきです'。
Watson Informational [Page 5] RFC 3324 Requirements for Network Asserted Identity November 2002
2002年11月にアイデンティティであると断言されたネットワークのためのワトソン情報[5ページ]のRFC3324Requirements
The above relationships are illustrated in the following figure:
上の関係は以下の図で例証されます:
+------+
| |
| F |
| |
+------+
x
..............................x.........
. x .
. +------+ +------+ . +------+
. | | | | . | |
. | A | | B |-----.----| E |
. | | | | . | |
. +------+ +------+ . +------+
. \\ / .
. \\ +------+ // .
. \\ | | // .
. \ | C |/ .
. | | .
. +------+ .
. | Trust Domain.
........................................
|
|
+------+
| |
| D |
| |
+------+
+------+ | | | F| | | +------+ x…x.… . x+------+ +------+ . +------+ . | | | | . | | . | A| | B|-----.----| E| . | | | | . | | . +------+ +------+ . +------+ . \\ / . . \\ +------+ // . . \\ | | // . . \ | C|/ . . | | . . +------+ . . | ドメインを信じてください。 ........................................ | | +------+ | | | D| | | +------+
xxxxxx Insecure connection
------ Secure connection
xxxxxx Insecure接続------ 安全な接続
......
. .All boxes within the dotted line
......are part of the same Trust Domain
...... . 点線の中の.All箱…同じTrust Domainの一部です。
o A, B and C are part of the same trust domain
o A、B、およびCは同じ信頼ドメインの一部です。
o A trusts C, but A does not trust B
o 信頼Bではなく、しかし、C、Aがそうする受託
o since E knows that B is inside of the trust domain, E
o Eが、Bが信頼ドメインの内部、Eであることを知っているので
o trusts B, but B does not trust E
o しかし、B、BがEを信じないと信じます。
o B does not trust F, F does not trust B
o Bは、F、FがBを信じないと信じません。
Watson Informational [Page 6] RFC 3324 Requirements for Network Asserted Identity November 2002
2002年11月にアイデンティティであると断言されたネットワークのためのワトソン情報[6ページ]のRFC3324Requirements
2.4 Spec(T)
2.4 仕様(T)
An aspect of the definition of a trust domain is that all the elements in that domain are compliant to a set of configurations and specifications generally referred to as Spec(T). Spec(T) is not a specification in the sense of a written document; rather, its an agreed upon set of information that all elements are aware of. Proper processing of the asserted identities requires that the elements know what is actually being asserted, how it was determined, and what the privacy policies are. All of that information is characterized by Spec(T).
信頼ドメインの定義の局面はそのドメインのすべての要素が一般に、Spec(T)と呼ばれた構成と仕様一式に対応であるということです。 仕様(T)は文書の意味で仕様ではありません。 むしろ、それ、すべての要素が意識している情報のセットに同意しました。 断言されたアイデンティティの適切な処理は、要素が何が実際に断言されているか、そして、それがどのように断固としていたか、そして、プライバシーに関する方針が何であるかを知っているのを必要とします。 その情報のすべてがSpec(T)によって特徴付けられます。
3. Generation of Networks Asserted Identity
3. アイデンティティであると断言されたネットワーク世代
A Network Asserted Identity is generated by a network intermediary following an Authentication process which authenticates the entity (UA) to be identified.
特定されるために、実体(UA)を認証するAuthenticationプロセスに続いて、Network Asserted Identityはネットワーク仲介者によって生成されます。
The Authentication process(es) used are a characteristic feature of the Trust Domain, and MUST be specified in Spec(T).
(es)が使用したAuthenticationプロセスをTrust Domainの特色であり、Spec(T)で指定しなければなりません。
It shall be possible for a UA to provide a preferred identity to the network intermediary, which MAY be used to inform the generation of the Network Asserted Identity according to the policies of the Trust Domain.
UAが都合のよいアイデンティティをネットワーク仲介者に提供するのは、可能でしょう。(その仲介者は、Trust Domainの方針に従ってNetwork Asserted Identityの世代に知らせるのに使用されるかもしれません)。
4. Transport of Network Asserted Identity
4. アイデンティティであると断言されたネットワークの輸送
4.1 Sending of Networks Asserted Identity within a Trust Domain
4.1 信頼ドメインの中でアイデンティティであると断言されたネットワークを発信させること。
It shall be possible for one node within a Trust Domain to securely send a Network Asserted Identity to another node that it trusts.
Trust Domainの中の1つのノードがしっかりとそれが信じる別のノードにNetwork Asserted Identityを送るのは、可能でしょう。
4.2 Receiving of Network Asserted Identity within a Trust Domain
4.2 信頼ドメインの中にアイデンティティであると断言されたネットワークを受け取ること。
It shall be possible for one node within a Trust Domain to receive a Network Asserted identity from another node that it trusts.
Trust Domainの中の1つのノードがそれが信じる別のノードからNetwork Assertedのアイデンティティを受けるのは、可能でしょう。
4.3 Sending of Network Asserted Identity to entities outside a Trust
Domain
4.3 Trust Domainの外の実体へのNetwork Asserted Identityの送付
If a node, A, within the Trust Domain, is trusted by a node, B, outside the Trust Domain, then it shall be possible for A to securely send a Network Asserted Identity to B, if allowed by the privacy policies of the user that has been identified, and the trust domain.
ノードであるなら、AはTrust Domainの中でノードによって信じられます、B、次に、Trust Domainの外では、AがしっかりとNetwork Asserted IdentityをBに送るのは、可能でしょう、特定されたユーザのプライバシーに関する方針、および信頼ドメインによって許容されているなら。
This is most often used to pass a Network Asserted Identity directly to a UA.
これは、直接UAにNetwork Asserted Identityを渡すのにたいてい使用されます。
Watson Informational [Page 7] RFC 3324 Requirements for Network Asserted Identity November 2002
2002年11月にアイデンティティであると断言されたネットワークのためのワトソン情報[7ページ]のRFC3324Requirements
4.4 Receiving of Network Asserted Identity by a node outside the Trust
Domain
4.4 Trust Domainの外のノードはNetwork Asserted Identityを受信すること。
It shall be possible for a node outside the Trust Domain to receive a Network Asserted Identity from a node that it trusts.
Trust Domainの外のノードがそれが信じるノードからNetwork Asserted Identityを受け取るのは、可能でしょう。
Network Asserted Identity received in this way may be considered valid, and used for display to the user, input data for services etc.
このように受け取られたネットワークAsserted Identityはディスプレイにユーザに有効であると考えられて、使用されるかもしれません、サービスなどのための入力データ
Network Asserted Identity information received by one node from a node which it does not trust carries no guarantee of authenticity or integrity because it is not known that the procedures of Spec(T) were followed to generate and transport the information. Such information MUST NOT be used. (i.e., it shall not be displayed to the user, passed to other nodes, used as input data for services, etc.)
Spec(T)の手順が情報を生成して、輸送するために従われたのが知られていないので、1つのノードによってそれが信じないノードから受け取られたネットワークAsserted Identity情報は信憑性か保全の保証を全く運びません。 そのような情報を使用してはいけません。 (他のノードに通過されたサービスなどのための入力データとして中古のユーザにすなわち、それを表示しないものとします)
5. Parties with Network Asserted Identities
5. ネットワークがアイデンティティであると断言されている党
A Network Asserted Identity identifies the originator of the message in which it was received.
Network Asserted Identityはそれが受け取られたメッセージの創始者を特定します。
For example,
例えば
a Network Asserted Identity received in an initial INVITE (outside
the context of any existing dialog) identifies the calling party.
初期のINVITE(どんな既存の対話の文脈の外における)に受け取られたNetwork Asserted Identityは起呼側を特定します。
a Network Asserted Identity received in a 180 Ringing response to
such an INVITE identifies the party who is ringing.
そのようなINVITEへの180Ringing応答で受け取られたNetwork Asserted Identityは鳴っているパーティーを特定します。
a Network Asserted Identity received in a 200 response to such an
INVITE identifies the party who has answered.
そのようなINVITEへの200応答で受け取られたNetwork Asserted Identityは答えたパーティーを特定します。
6. Types of Network Asserted Identity
6. アイデンティティであると断言されたネットワークのタイプ
It shall be possible to assert multiple identities associated with a given party (in a given message), provided that these are of distinct types.
与えられたパーティー(与えられたメッセージの)に関連している複数のアイデンティティについて断言するのは可能でしょう、異なったタイプにこれらがあれば。
The types of identity supported shall be sip:, sips: and tel: URIs, all of which identify the user as described in Section 2.1. It is not required to transport both a sip: and sips: URI.
以下をちびちび飲むことであり、サポートされたアイデンティティのタイプはちびちび飲みます: そして、tel: URI。それのすべてがセクション2.1で説明されるようにユーザを特定します。 それはaがちびちび飲む両方を輸送するのに必要ではありません: 一口: ユリ。
It shall be possible for the capability to transport additional types of identity associated with a single party to be introduced in future.
これから導入するのは独身のパーティーに関連しているアイデンティティの追加タイプを輸送する能力に可能になるでしょう。
Watson Informational [Page 8] RFC 3324 Requirements for Network Asserted Identity November 2002
2002年11月にアイデンティティであると断言されたネットワークのためのワトソン情報[8ページ]のRFC3324Requirements
7. Privacy of Network Asserted Identity
7. アイデンティティであると断言されたネットワークのプライバシー
The means by which any privacy requirements in respect of the Network Asserted Identity are determined are outside the scope of this document.
このドキュメントの範囲の外にNetwork Asserted Identityの点におけるどんなプライバシー要件も決定している手段があります。
It shall be possible to indicate within a message containing a Network Asserted Identity that this Network Asserted Identity is subject to a privacy requirement which prevents it being passed to other users. This indication should not carry any semantics as to the reason for this privacy requirement.
Network Asserted Identityを含むメッセージの中に示すのにおいて、このNetwork Asserted Identityはそれが他のユーザに渡されるのを防ぐプライバシー要件を受けることがあるのが、可能でしょう。 この指示はこのプライバシー要件の理由に関して少しの意味論も運ぶべきではありません。
It shall be possible to indicate that the user has requested that the Network Asserted Identity be not passed to other users. This is distinct from the above indication, in that it implies specific user intent with respect to the Network Asserted Identity.
ユーザが、Network Asserted Identityが他のユーザに渡されないよう要求したのを示すのは可能でしょう。 これは上の指示と異なっています、Network Asserted Identityに関して特定のユーザ意図を含意するので。
The mechanism shall support Trust Domain policies where the above two indications are equivalent (i.e., the only possible reason for a privacy requirement is a request from the user), and policies where they are not.
メカニズムは上の2つの指摘が同等である(すなわち、プライバシー要件の唯一の可能な理由がユーザからの要求です)Trust Domain方針、およびそれらがそうでない方針をサポートするものとします。
In this case, the Network Asserted Identity specification shall require that the mechanism of Section 4.3 SHALL NOT be used i.e., a trusted node shall not pass the identity to a node it does not trust. However, the mechanism of Section 4.3 MAY be used to transfer the identity within the trusted network.
この場合、Network Asserted Identity仕様は、セクション4.3 SHALL NOTのメカニズムが使用されるのを必要とするものとします、すなわち、信じられたノードがそれが信じないノードにアイデンティティを通過しないものとします。 しかしながら、セクション4.3のメカニズムは、信じられたネットワークの中でアイデンティティを移すのに使用されるかもしれません。
Note that 'anonymity' requests from users or subscribers may well require functionality in addition to the above handling of Network Asserted Identities. Such additional functionality is out of the scope of this document.
ユーザか加入者からの'匿名'要求がたぶんNetwork Asserted Identitiesの上の取り扱いに加えた機能性を必要とするだろうことに注意してください。 このドキュメントの範囲の外にそのような追加機能性はあります。
8. Security Considerations
8. セキュリティ問題
The requirements in this document are NOT intended to result in a mechanism with general applicability between arbitrary hosts on the Internet.
本書では、インターネットの任意のホストの間には、一般的な適用性がある状態で要件がメカニズムをもたらすことを意図しません。
Rather, the intention is to state requirements for a mechanism to be used within a community of devices which are known to obey the specification of the mechanism (Spec(T)) and between which there are secure connections. Such a community is known here as a Trust Domain.
そして、むしろ、意志がメカニズムがメカニズムの仕様に従うのが知られているデバイスの共同体の中で使用されるという要件を述べることである、(仕様(T))、安全な接続がある。 そのような共同体はTrust Domainとしてここで知られています。
The requirements on the mechanisms used for security and to initially derive the Network Asserted Identity must be part of the specification Spec(T).
セキュリティ、初めはNetwork Asserted Identityを引き出すのに使用されるメカニズムに関する要件は仕様Spec(T)の一部であるに違いありません。
Watson Informational [Page 9] RFC 3324 Requirements for Network Asserted Identity November 2002
2002年11月にアイデンティティであると断言されたネットワークのためのワトソン情報[9ページ]のRFC3324Requirements
The requirements also support the transfer of information from a node within the Trust Domain, via a secure connection to a node outside the Trust Domain.
また、要件はTrust Domainの中のノードからの情報の転送をサポートします、Trust Domainの外のノードとの安全な接続で。
Use of this mechanism in any other context has serious security shortcomings, namely that there is absolutely no guarantee that the information has not been modified, or was even correct in the first place.
いかなる他の文脈におけるこのメカニズムの使用でも、重大なセキュリティ短所があります、すなわち、情報が変更されていないか、または第一に正しくさえあったという保証が全く絶対にありません。
9. IANA Considerations
9. IANA問題
This document does not have any implications for IANA.
このドキュメントには、IANAのための少しの意味もありません。
10. Acknowledgments
10. 承認
Thanks are due to Jon Peterson, Cullen Jennings, Allison Mankin and Jonathan Rosenberg for comments on this document.
感謝はこのドキュメントのコメントのためのジョン・ピーターソン、Cullenジョニングス、アリソン・マンキン、およびジョナサン・ローゼンバーグのためです。
Normative References
引用規格
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[1] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
Author's Address
作者のアドレス
Mark Watson Nortel Networks Maidenhead Office Park Westacott Way Maidenhead, BERKS SL6 3QH UK
ワトソンノーテルネットワーク処女性オフィスパークWestacott道が処女性、ばかSL6 3QHイギリスであるとマークしてください。
EMail: mwatson@nortelnetworks.com
メール: mwatson@nortelnetworks.com
Watson Informational [Page 10] RFC 3324 Requirements for Network Asserted Identity November 2002
2002年11月にアイデンティティであると断言されたネットワークのためのワトソン情報[10ページ]のRFC3324Requirements
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 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機能のための基金は現在、インターネット協会によって提供されます。
Watson Informational [Page 11]
ワトソンInformationalです。[11ページ]
一覧
スポンサーリンク
