Network Working Group M. Watson Request for Comments: 3324 Nortel Networks Category: Informational November 2002 ネットワークでアサートされるアイデンティティのための短期的要件 Short Term Requirements for Network Asserted Identity 本文書の位置付け この文書は、インターネットコミュニティのために情報を提供する。いかなる 種類であれインターネット標準を規定するものではない。この文書の配布は 無制限である。 著作権表記 Copyright (C) The Internet Society (2002). All Rights Reserved. 概要 ネットワークでアサートされるアイデンティティとは、認証プロセスの結果と してセッション開始プロトコル(Session Initiation Protocol / SIP)ネット ワークの中継媒体によって最初に導き出されるアイデンティティである。本文 書では、セキュアに相互接続された信頼されるノードのネットワークにおい て、ネットワークでアサートされるアイデンティティの交換を行うための、 また、そのようなネットワークにセキュアに接続されたユーザーエージェント に対する、短期的な要件について述べる。 UAによってSIPメッセージ中にアサートされるアイデンティティに対する要件 は、ユーザーが望むエイリアスであるということ以外には何もない。 Watson Informational [Page 1] RFC 3324 Requirements for Network Asserted Identity November 2002 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. 定義 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 アイデンティティ . . . . . . . . . . . . . . . . . . . . . . . 3 2.2 ネットワークでアサートされるアイデンティティ . . . . . . . . 3 2.3 信頼ドメイン . . . . . . . . . . . . . . . . . . . . . . . . 4 2.4 Spec(T) . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. ネットワークでアサートされるアイデンティティの生成 . . . . . . 7 4. ネットワークでアサートされるアイデンティティのトランスポート . 7 4.1 信頼ドメイン内でのネットワークでアサートされるアイデンティ ティの送信 . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2 信頼ドメイン内でのネットワークでアサートされるアイデンティ ティの受信 . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3 信頼ドメイン外のエンティティへのネットワークでアサートされる アイデンティティの送信 . . . . . . . . . . . . . . . . . . . . 7 4.4 信頼ドメイン外のノードによるネットワークでアサートされるアイ デンティティの受信 . . . . . . . . . . . . . . . . . . . . . . 8 5. ネットワークでアサートされるアイデンティティを持つパーティ . . 8 6. ネットワークでアサートされるアイデンティティのタイプ . . . . . 8 7. ネットワークでアサートされるアイデンティティのプライバシー . . 9 8. セキュリティの考慮 . . . . . . . . . . . . . . . . . . . . . . 9 9. IANA条項 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. 謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 規範となる参考文献 . . . . . . . . . . . . . . . . . . . . . . 10 著者の連絡先 . . . . . . . . . . . . . . . . . . . . . . . . . 10 完全な著作権表記 . . . . . . . . . . . . . . . . . . . . . . . 11 1. はじめに SIP [1]は、ユーザーが多くの方法で(例:Fromヘッダーを使用して)アイデン ティティをアサートすることを認める。しかしながら、これらのアイデンティ ティに対する要件は、ユーザーが望むエイリアスであるということ以外には何 もない。 ユーザーの認証されたアイデンティティは、SIPのダイジェスト認証(あるい は他の手段)を使用して取得できる。しかしながら、UAは他のUAを認証するた めに必要なキー情報を常に持っているわけではない。 ネットワークでアサートされるアイデンティティとは、認証プロセスの結果と してSIPネットワークの中継媒体によって最初に導き出されるアイデンティティ である。これはSIPのダイジェスト認証を基にするものかどうかわからない。 本文書では、セキュアに相互接続された信頼されるノードのネットワークにお いてネットワークでアサートされるアイデンティティの交換を行うための、ま た、このようなネットワークにセキュアに接続されたユーザーエージェントに 対する、短期的な要件について述べる。 Watson Informational [Page 2] RFC 3324 Requirements for Network Asserted Identity November 2002 そのようなネットワークは、本文書では信頼ドメインと記述される。また、本 文書における信頼(trust)および信頼ドメインの厳密な定義を提示する。これ らの短期的な要件は、信頼ドメイン内のネットワークでアサートされるアイデ ンティティを交換するため、および信頼ドメインに接続されているエンティ ティに対してのみ提供される。 インターネット上でのネットワークでアサートされるアイデンティティのトラ ンスポートのための一般的な要件は、本文書の適用範囲外である。 2. 定義 2.1 アイデンティティ 本文書において、アイデンティティとは、sip:、sips:、またはtel: URI、 およびオプションで表示名(Display Name)である。 URIは、そのURIで識別されるドメイン(sip:またはsips: URIの場合)または E.164番号の所有者(tel: URIの場合)に対して意味を持つものでなければなら ない[MUST](そのドメインまたは番号範囲の所有者に対して送信されるSIP Request-URIとして使用されたときに、それがそのリクエストを、そのアイデ ンティティに関連付けられているユーザーあるいは回線にルートするか、あ るいはそのユーザーに成り代わって実行されているサービスロジックによっ て処理される、という意味で)。 URIがsip:またはsips: URIの場合、そのURIで識別されるドメインのポリシー に依存して、そのURIは、たとえばある個人といった、何らかの具体的なエン ティティを特定してもよい[MAY]。 URIがtel: URIの場合、その電話番号が存在する番号範囲の所有者のポリシー に依存して、その番号は、たとえばある電話回線といった、何らかの具体的 なエンティティを特定してもよい[MAY]。しかしながら、番号範囲の所有者を 特定することは、sipまたはsips URIを所有するドメインを特定することに比 べると、単純な処理ではない、ということに注意すること。 2.2 ネットワークでアサートされるアイデンティティ ネットワークでアサートされるアイデンティティとは、認証プロセスの結果と してSIPネットワークのエンティティによって導き出されるアイデンティティ である。これは、セクション2.1で定義された意味において、認証されたエン ティティを特定する。 sip:またはsips: URIの場合、そのURIに含まれるドメインは、信頼ドメイン 内になければならない[MUST]。 tel: URIの場合、そのURI中のE.164番号の所有者は、信頼ドメイン内にいな ければならない[MUST]。 Watson Informational [Page 3] RFC 3324 Requirements for Network Asserted Identity November 2002 使用される認証プロセス、あるいは少なくともそれの信頼性/強度は、ネット ワークでアサートされるアイデンティティを使用する信頼ドメインの既知の フィーチャー、すなわち、下記の2.3の表現を借りれば、Spec(T)である。 2.3 信頼ドメイン ネットワークでアサートされるアイデンティティにおける信頼ドメインとは、 以下に記述されるような意味合いでネットワークでアサートされるアイデン ティティ情報を交換するために信頼されているSIPノード(UAC、UAS、プロキ シ、あるいは他のネットワーク中継媒体)のセットである。 ノードは、信頼ドメイン(T)内でのネットワークでアサートされるアイデン ティティの処理方法を説明するある特定の仕様セット(Spec(T))に準拠してい ることが既知の場合にのみ、信頼ドメイン(T)のメンバーになれる。 信頼ドメインは、使用/導入している機器の特性を知っている人によって構 築される。最も単純なケースでは、信頼ドメインはデバイスのセット(それ らのデバイスの動作を正確に知ることができる1人の所有者/オペレーターが いる)である。 そのような単純な信頼ドメインは、双方のデバイスの所有者/オペレーター の合意によって、より大きな信頼ドメインに加わるかもしれない。 ノードが(ある信頼ドメインにおいて)「信頼されている(Trusted)」と言え るのは、そのノードがそのドメインのメンバーである場合だけである。 ノードAがドメイン内でノードBに「信頼されている(Trusted)」(あるいはBが Aを信頼する(Trust))と言えるのは、以下の場合だけである。 1. それらのノード間にセキュアなコネクションが存在し、かつ[AND] 2. Aが信頼ドメインのメンバーであるということを示す設定情報をBがもっ ている。 Bが信頼ドメインのメンバーであるかどうかはわからない、ということに注 意すること。例えば、Bは、あるネットワーク中継媒体A(例えば、それのホー ムプロキシ)を信頼するUAかもしれない。 このコンテキストにおける「セキュアなコネクション」とは、サードパーテ ィがメッセージを読めないこと、検知せずに(without detection)サードパー ティがメッセージを修正できないこと、および、メッセージが確かにAから来 たことをBが確信できること、を意味する。要求されるセキュリティレベルは、 信頼ドメインのフィーチャーである(すなわち、Spec(T)で定義される)。 Watson Informational [Page 4] RFC 3324 Requirements for Network Asserted Identity November 2002 このコンテキスト内では、あるノードがそれが信頼するノードから[FROM]受 信するSIPシグナリング情報は、特定の仕様セット(Spec(T))の手順に従って ネットワークを介して生成されて渡されたことがわかっており、それゆえ、 有効あるいは少なくともSpec(T)仕様で規定されているのと同程度に有効であ ると知ることができる。 同様に、あるノードは、それが信頼するノードに[TO]渡されたシグナリング 情報がSpec(T)の手順に従ってハンドリングされることを確信できる。 これらの能力が有用であるために、Spec(T)は、ネットワークでアサートされ るアイデンティティがどのように生成され、それがネットワーク中を順次渡さ れる際に、そのプライバシーがどのように保護されてその完全性がどのように 維持されるか、についての要件を含まなければならない。その結果Spec(T)の 読者は、信頼ドメイン(T)から享受できるネットワークでアサートされるアイ デンティティ情報の確実性と信頼性について、しっかりとした情報に基づいた 判断を下すことができる。 (ある信頼ドメインにおいて)「信頼されている(Trusted)」という用語は、 感覚的な表現としてノードに適用できる。つまりそれは、そのノードがTrust ドメインのメンバーであると言っているのに等しい。しかしながら、そのノ ード自身は、たとえ他の任意のノードが信頼ドメイン内にいたとしても、そ れが「信頼されている(Trusted)」かどうか知らない。そのノードは、上記の ようなセキュアコネクションを持つ特定のノードについては知っている。 上記の定義において、「信頼されるノードは・・・べきである[SHALL]」という 記述は、「この仕様に準拠するノードは・・・べきである[SHALL]」を短く表 現しただけである。 「あるノードが信頼されるノードから情報を受信するとき・・・」というような 記述は、1つのノードは信頼ドメイン内の他のすべてのノードについての完 全な知識を持っていないので、妥当ではない[NOT]。 「あるノードが、それが信頼する他のノードから情報を受信するとき・・・」 というような記述は、妥当であり[ARE]、上記の基準(1)と(2)にしたがって解 釈されるべきである。 Watson Informational [Page 5] RFC 3324 Requirements for Network Asserted Identity November 2002 上記の関係を以下に図解する。 +------+ | | | F | | | +------+ x ..............................x......... . x . . +------+ +------+ . +------+ . | | | | . | | . | A | | B |-----.----| E | . | | | | . | | . +------+ +------+ . +------+ . \\ / . . \\ +------+ // . . \\ | | // . . \ | C |/ . . | | . . +------+ . . | 信頼ドメイン. ........................................ | | +------+ | | | D | | | +------+ xxxxxx セキュアではない(insecure)コネクション ------ セキュアコネクション ...... . .点線内のすべての四角は ......同一の信頼ドメインの一部である o A、B、およびCは同一の信頼ドメインの一部 o AはCを信頼するが、AはBを信頼しない o EはBが信頼ドメイン内にいることを知っているので、 o EはBを信頼するが、BはEを信頼しない o BはFを信頼せず、FはBを信頼しない Watson Informational [Page 6] RFC 3324 Requirements for Network Asserted Identity November 2002 2.4 Spec(T) 信頼ドメインの定義の特長は、そのドメイン内のすべてのエレメントが、一 般にSpec(T)として言及される設定と仕様のセットに準拠することである。 Spec(T)とは、文書という意味での仕様ではなく、すべてのエレメントが認識 している、合意された情報セットである。アサートされるアイデンティティの 適切な処理は、実際に何がアサートされているか、それがどのように確定され たか、プライバシーポリシーは何か、についてエレメントが知ることを必要と する。それらすべての情報はSpec(T)で述べられる。 3. ネットワークでアサートされるアイデンティティの生成 ネットワークでアサートされるアイデンティティは、特定されるエンティティ (UA)を認証する認証プロセスに続いて、ネットワーク中継媒体が生成する。 使用される認証プロセスは、信頼ドメインを特徴付けるフィーチャーであり、 Spec(T)で規定されなければならない[MUST]。 UAがネットワーク中継媒体に好みのアイデンティティを提示することが可能 であるべきである。このアイデンティティは、信頼ドメインのポリシーにし たがって、ネットワークでアサートされるアイデンティティの生成処理に知ら せるために使用してもよい[MAY]。 4. ネットワークでアサートされるアイデンティティのトランスポート 4.1 信頼ドメイン内でのネットワークでアサートされるアイデンティティの送信 信頼ドメイン内の1つのノードが、それが信頼する他のノードに、ネットワー クでアサートされるアイデンティティをセキュアに送信することが可能である べきである。 4.2 信頼ドメイン内でのネットワークでアサートされるアイデンティティの受信 信頼ドメイン内の1つのノードが、それが信頼する他のノードから、ネット ワークでアサートされるアイデンティティを受信することが可能であるべきで ある。 4.3 信頼ドメイン外のエンティティへのネットワークでアサートされるアイデン ティティの送信 信頼ドメイン内のノードAが信頼ドメイン外のドメインBに信頼されている 場合、特定されたユーザーとその信頼ドメインのプライバシーポリシーが許 可するなら、AがBにネットワークでアサートされるアイデンティティをセキュ アに送信することが可能であるべきである。 これは、ネットワークでアサートされるアイデンティティをUAに直接渡すため に最もよく使用される。 Watson Informational [Page 7] RFC 3324 Requirements for Network Asserted Identity November 2002 4.4 信頼ドメイン外のノードによるネットワークでアサートされるアイデンティ ティの受信 信頼ドメイン外の1つのノードが、それが信頼するノードから、ネットワーク でアサートされるアイデンティティを受信することが可能であるべきである。 この方法で受信されたネットワークでアサートされるアイデンティティは、有 効であるとみなされ、ユーザーへの表示やサービスのための入力データなどに 使用される。 1つのノードが、それが信頼しないノードから受信したネットワークでアサー トされたアイデンティティ情報は、確実性や完全性を保証しない。なぜなら、 その情報を生成してトランスポートするためにSpec(T)の手順に従ったかどう かわからないからである。このような情報を使用してはならない[MUST NOT]。 すなわち、それをユーザーに表示したり、他のノードに渡したり、サービスの ための入力データとして使用したりするべきではない。 5. ネットワークでアサートされるアイデンティティを持つパーティ ネットワークでアサートされるアイデンティティはメッセージの発信元を特定 する(ネットワークでアサートされるアイデンティティはそのメッセージ中で 受信した)。 例えば、 最初のINVITE(既存のすべてのダイアログのコンテキスト外)中で受信した ネットワークでアサートされるアイデンティティは発呼側パーティを特定 する。 そのようなINVITEに対する180(Ringing)応答中で受信したネットワークで アサートされるアイデンティティは、呼び出し音が鳴っているパーティを 特定する。 そのようなINVITEに対する200応答中で受信したネットワークでアサートさ れるアイデンティティは、電話に出たパーティを特定する。 6. ネットワークでアサートされるアイデンティティのタイプ あるパーティに関連付けられた複数のアイデンティティを、それらが別個の タイプであれば、アサートする(任意のメッセージ中で)ことが可能であるべ きである。 サポートされるアイデンティティのタイプは、sip:、sips:、およびtel: URI であるべきである(それらすべては、セクション2.1で述べられているように ユーザーを特定する)。sip:およびsips: URIの両方をトランスポートするこ とは要求されない。 将来導入される、単一パーティに関連付けられた追加のアイデンティティタ イプをトランスポートすることが、能力として可能であるべきである。 Watson Informational [Page 8] RFC 3324 Requirements for Network Asserted Identity November 2002 7. ネットワークでアサートされるアイデンティティのプライバシー ネットワークでアサートされるアイデンティティに関するすべてのプライバ シー要件が確定される手段は、本文書の適用範囲外である。 ネットワークでアサートされるアイデンティティを含むメッセージ内で、この ネットワークでアサートされるアイデンティティが他のユーザーに渡されるこ とを防ぐプライバシー要件に従うことを示すことが可能であるべきである。こ の指示は、このプライバシー要件の理由に関するいかなるセマンティクスも伝 えるべきではない。 ネットワークでアサートされるアイデンティティが他のユーザーに渡されない ことを、ユーザーが要求することを示すことが可能であるべきである。これは 上記の指示とは区別され、その中で、ネットワークでアサートされるアイデン ティティに関するユーザーの特定の要望を示す。 上記の2つの指示が同等である信頼ドメインポリシー(すなわち、プライバシ ー要件の唯一の根拠は、そのユーザーからのリクエストであること)、および 同等ではないポリシーを、メカニズムはサポートするべきである。 この場合、ネットワークでアサートされるアイデンティティ仕様は、セクショ ン4.3のメカニズムが使用されるべきでない[SHALL NOT]ことを要求するべきで ある。すなわち、信頼されるノードは、それが信用しないノードにアイデン ティティを渡すべきではない。しかしながら、セクション4.3のメカニズムを、 信頼されるネットワーク内でアイデンティティを転送(transfer)するために使 用してもよい[MAY]。 ユーザーあるいはサブスクライバーからの匿名(anonymity)リクエストは、上 記のネットワークでアサートされるアイデンティティのハンドリングに加え て、機能性(functionality)を十分に必要とするかもしれない、ということに 注意すること。そのような付加的な機能性は、本文書の適用範囲外である。 8. セキュリティの考慮 本文書中の要件は、インターネット上の任意のホスト間で汎用に適用可 能なメカニズムを得ることを意図していない[NOT]。 そうではなく、意図するところは、メカニズムに対する要件を提示すること である(そのメカニズムの仕様(Spec(T))に従うことが既知のデバイスのコミ ュニティ内で使用されるため、および、セキュアコネクションがあるデバイ スのコミュニティ間で使用されるため)。そのようなコミュニティを、ここで は信頼ドメインという。 セキュリティのため、および、ネットワークでアサートされるアイデンティ ティを最初に導き出すために使用されるメカニズムに関する要件は、Spec(T) 仕様の一部でなければならない。 Watson Informational [Page 9] RFC 3324 Requirements for Network Asserted Identity November 2002 要件はまた、信頼ドメイン内のノードから、セキュアコネクションを使用し た信頼ドメイン外のノードへの、情報の転送(transfer)もサポートする。 他のいかなるコンテキストにおいてこのメカニズムを使用することも、深刻 なセキュリティの欠陥を持つ。すなわち、情報が改竄されていない、あるい は最初の時点でそれが正しかった、という保証はまったくない。 9. IANA条項 本文書はIANAとの関係を何も持たない。 10. 謝辞 本文書に関するコメントをいただいたJon Peterson、Cullen Jennings、Allison Mankin、およびJonathan Rosenbergに感謝する。 規範となる参考文献 [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. 著者の連絡先 Mark Watson Nortel Networks Maidenhead Office Park Westacott Way Maidenhead, BERKS SL6 3QH UK EMail: mwatson@nortelnetworks.com Watson Informational [Page 10] RFC 3324 Requirements for Network Asserted Identity November 2002 完全な著作権表記 Copyright (C) The Internet Society (2002). All Rights Reserved. 本記述とその翻訳は複写し他に提供することができる。また論評を加えた派 生的製品や、この文書を説明したり、その実装を補助するもので、上記の著 作権表示およびこの節を付加するものはすべて、全体であってもその一部で あっても、いっさいの制約を課されること無く、準備、複製、発表、配布す ることができる。しかし、この文書自体にはいかなる方法にせよ、著作権表 示やインターネットソサエティもしくは他のインターネット関連団体への参 照を取り除くなどの変更を加えてはならない。 インターネット標準を開発す るために必要な場合は例外とされるが、その場合はインターネット標準化過 程で定義されている著作権のための手続きに従わなければならない。 また RFCを英語以外の言語に翻訳する必要がある場合も例外である。 以上に述べられた制限は永久的なものであり、インターネットソサエティも しくはその継承者および譲渡者によって破棄されることはない。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、インターネッ トソサエティおよびIETFは、この情報がいかなる権利も侵害していないとい う保証、商用利用および特定目的への適合性への保証を含め、また、これら だけに限らずすべての保証について、明示的もしくは暗黙的の保証は行われ ない。 謝辞 RFCエディターの活動のための資金は、現在インターネットソサエティによっ て提供されている。 --------------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただし、 この権利の設定は原文から新たな翻訳を作成し公開することを妨げるものではあり ません。本翻訳物は、本著作権表示を含めて改変しないことを条件に再配布を許可 します。翻訳の正確さについては一切保証しません。原文とあわせてご利用くだ さい。 2005年 --------------------------------------------------------------------------- Watson Informational [Page 11]