Network Working Group C. Jennings Request for Comments: 3325 Cisco Systems Category: Informational J. Peterson NeuStar, Inc. M. Watson Nortel Networks November 2002 信頼されたネットワーク内でアサートされたアイデンティティのための セッション開始プロトコル(SIP)のプライベート拡張 Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks 本文書の位置付け この文書は、インターネットコミュニティのためのインターネット標準トラッ クプロトコルを規定するものであり、改善のための議論や提案を依頼するもの である。標準化の段階や、プロトコルの位置付けについては、最新版の "Internet Official Protocol Standards" (STD 1)を参照されたい。この文書 の配布は無制限である。 著作権表記 Copyright (C) The Internet Society (2002). All Rights Reserved. 要旨 本文書は、信頼されたSIPサーバーのネットワークが認証済みのユーザー のアイデンティティをアサート(assert)できるようにするセッション開 始プロトコル(SIP)のプライベート拡張、および、既存のプライバシーメ カニズムのアイデンティティ問題への適用について、説明する。これら の拡張の使用は、このような情報の生成、トランスポート、用法に対し て合意済みのポリシーを持つ管理ドメイン内でのみ適用できる。本文書 は、異なる信頼ドメイン間での使用やインターネット全体での使用に適 した、汎用のプライバシーまたはアイデンティティのモデルを提示する ものではない[NOT]。 Table of Contents 1. 適用性の声明 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. 表記規則 . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. 概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. プロキシの動作 . . . . . . . . . . . . . . . . . . . . . . . 5 6. 複数のアイデンティティに関するヒント . . . . . . . . . . . . 6 7. Privacyの要求 . . . . . . . . . . . . . . . . . . . . . . . 6 8. ユーザーエージェントサーバーの動作 . . . . . . . . . . . . . 7 9. 正式なシンタックス . . . . . . . . . . . . . . . . . . . . 7 9.1 P-Asserted-Identityヘッダー . . . . . . . . . . . . . . 8 9.2 P-Preferred-Identity ヘッダー . . . . . . . . . . . . . 8 9.3 プライバシータイプ「id」. . . . . . . . . . . . . . . . 9 Jennings, et. al. Informational [Page 1] RFC 3325 SIP Asserted Identity November 2002 10. 例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1 信頼されたゲートウェイへ渡されたNetwork Asserted Identity 9 10.2 明かされないNetwork Asserted Identity . . . . . . . . . 11 11. Spec(T)の例 . . . . . . . . . . . . . . . . . . . . . . . . 13 12. セキュリティの考慮 . . . . . . . . . . . . . . . . . . . . 14 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 13.1 新規SIPヘッダーフィールドの登録 . . . . . . . . . . . . 14 13.2 SIP Privacyヘッダーの「id」プライバシータイプの登録 . . 15 14. 謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 規範となる参考文献 . . . . . . . . . . . . . . . . . . . . . 15 有益な参考文献 . . . . . . . . . . . . . . . . . . . . . . . 16 著者の連絡先 . . . . . . . . . . . . . . . . . . . . . . . . 17 完全な著作権表記 . . . . . . . . . . . . . . . . . . . . . . 18 1. 適用性の声明 本文書は、信頼されたSIPサーバーのネットワークが、エンドユーザーまたは システムのアイデンティティをアサートすること、および、エンドユーザーの 要求するプライバシーの指示を伝えることを可能にするSIP[1]のプ ライベート拡張について、説明する。「Short term requirements for Network Asserted Identity」[5]で定義されているように、これら の拡張の使用は、「信頼ドメイン」内でのみ適用できる。このような信頼ドメ インにおけるノードは、公にユーザーとエンドシステムの各パーティのアイデ ンティティをアサートし、また、プライバシーを要求される場合には、信頼ド メインの外部に対してそのアイデンティティを隠す責任を持つことで、ユーザ ーとエンドシステムに明確に信頼される。アサートするアイデンティティをネ ットワークが確定する手段は、本文書の適用範囲外である(それは一般に何ら かの形の認証を伴うのであるが)。 [5]の主な要件は、ある信頼ドメイン「T」内の全ノードの動作が、「Spec (T)」として知られる仕様の特定のセットに準拠すると知られていることであ る。Spec(T)は以下の動作を指定しなければならない[MUST]。 1. ユーザーが認証される方法 2. 信頼ドメイン内のノード間通信を安全にするために使用されるメカニズ ム 3. 信頼ドメイン内のUA・ノード間通信を安全にするために使用されるメカ ニズム Jennings, et. al. Informational [Page 2] RFC 3325 SIP Asserted Identity November 2002 4. どのホストが信頼ドメインの一部なのか確定するために使用される方法 5. Privacyヘッダーフィールドが存在しないときの、デフォルトのプライバ シーハンドリング 6. 信頼ドメイン内のノードがSIP[1]に準拠している 7. 信頼ドメイン内のノードが本文書に準拠している 8. セクション7で定義されるアイデンティティに対するプライバシーハンド リング 適切なSpec(T)の一例をセクション11で挙げる。 本文書は、ドメイン間での使用またはインターネット全体での使用に適した、 汎用のプライバシーまたはアイデンティティのモデルを提示するものではない [NOT]。本文書でのユーザーとネットワーク間の信頼関係についての前提は、 多くのアプリケーションに適用できないかもしれない。例えば、これらの拡張 は、エンドユーザーが本文書で定義される拡張を使用して独自に自分のアイデ ンティティをアサートできるモデルに適応しない。さらに、アサートされたア イデンティティは暗号的に認証されていないため、[5]の要件を満たさないす べてのアーキテクチャにおいては、改竄、リプレイ、変造の対象となる。 また、アサートされたアイデンティティは、厳密に誰がそのアイデンティティ をアサートしているのかを表していないため、信頼ドメインがそのアイデンテ ィティをアサートしていると推測せざるを得ない。それゆえ情報は、信頼ドメ インのメンバーであることが分かっているノードから安全に受信された場合に だけ有意義である。 これらの制限にもかかわらず、上述の前提を満足させ、かつ、結果的に生じる 制限を受け入れることができる、本メカニズムの情報公開を保証するための十 分に有用で特化された運用が存在する。運用例の一つは、従来の回路交換方式 電話網をエミュレートする閉鎖ネットワークであろう。 2. 表記規則 本文書では、次のキーワードはRFC 2119[3]のBCP14に記述されてい るとおりに解釈される。 「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、 「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および 「OPTIONAL」 本文書に渡り、プロキシサーバーやプロキシの動作に関する要件または参照は、 同様に信頼ドメイン内における他の中継媒体に当てはまる(例：B2BUAs)。 Jennings, et. al. Informational [Page 3] RFC 3325 SIP Asserted Identity November 2002 本文書では、次の単語は[5]で定義されるとおりの意味を持つ。 「アイデンティティ(Identity)」、「Network Asserted Identity」、および 「信頼ドメイン(Trust Domain) 」 3. はじめに IPネットワーク上でテレフォニーサービスを提供する様々なプロバイダーが、 SIPを呼確立プロトコルとして選択している。これらの環境は、サービスプロ バイダーが運営する信頼されたネットワークエレメント(例えば、SIPプロキシ サーバーなど)が、サブスクライバーのアイデンティティをそのようなサービ スへ伝達する方法を必要とし、さらに必要時には、その情報を信頼できないエ ンティティに明かさない必要もある。このようなネットワークは通常、プロバ イダーと自身が操作するデバイス間に、ある程度の推移的信頼(transitive trust)を仮定している。 これらのネットワークは、特定の従来のテレフォニーサービスをサポートする と共に、基本的な規制と公共の安全に関する要件を満たすことが必要である。 これには、発呼者アイデンティティ伝達(Calling Identity Delivery)サービ ス、発呼者アイデンティティ伝達ブロッキング(Calling Identity Delivery Blocking)、および発呼者をトレースする能力が含まれる。ベースラインSIPは これらのサービスをそれぞれ単独でサポートできるが、特定の組み合わせは本 文書で記述する拡張がないとサポートできない。例えばプライバシーを維持し たいので、SIP Fromヘッダーフィールドに限られた情報を提示する発呼側は、 発呼側のアイデンティティをつかむための何か別の手段に頼らない限り、その 呼の受信者には識別できないだろう。発信元のユーザーエージェントにおいて アイデンティティ情報をマスキングすることは、例えばコールトレースなど特 定のサービスが、公衆交換電話網(PSTN)内で機能することや、あるいはユーザ ーの認証済みアイデンティティを関知しない中継媒体において実行されること を防ぐだろう。 本文書は、[5]の要件に基づく、非常に制限された単純なメカニズムを利用す るNetwork Asserted Identityサービスの提示を試みるものである。この著作 は、信頼ドメイン内におけるプライバシーとアイデンティティに関するいくつ かの問題を解決を図るための以前の試みである、[6]に基づいている。より包 括的なメカニズムである[7]は、この問題に対処するのに暗号化を使用する が、これはSIPワーキンググループの目下の研究題材である。 SIPネットワーク内におけるプライバシーの提示は、PSTN内の場合よりもずっ と複雑である。SIPネットワーク内では、セッションの参加者は通常、SIPサー ビスプロバイダーをまったく関与させずに、IPトラフィックを直接交換でき る。これらのセッションに使用されるIPアドレス自体がプライベート情報を明 らかにする可能性がある。SIP環境におけるプライバシー提示のための汎用メ カニズムは[2]で議論される。本文書はそのプライバシーメカニズムをNetwork Asserted Identityの問題に適用する。 Jennings, et. al. Informational [Page 4] RFC 3325 SIP Asserted Identity November 2002 4. 概要 本文書で提案されるメカニズムは、URI(通常SIP URI)およびオプションで表示 名を含む、「P-Asserted-Identity」という名称の新規ヘッダーフ ィールドに依存する。例は以下のとおり: P-Asserted-Identity: "Cullen Jennings" メッセージをハンドリングするプロキシサーバーは、発信元ユーザーを何らか の方法(例えばDigest認証など)で認証後、P-Asserted-Identityヘッダーフィ ールドをメッセージ内に挿入でき、他の信頼されたプロキシへ転送(forward) することができる。自身が信頼していないプロキシサーバーまたはUAへメッセ ージを転送しようとしているプロキシは、ユーザーがその情報を秘密にするこ とを要求した場合、全P-Asserted-Identityヘッダーフィールド値を削除しな ければならない[MUST]。セクション7で記述するように、ユーザーはこのタイ プのプライバシーを要求できる。 P-Asserted-Identityヘッダーの正式なシンタックスは、セクション9で提示さ れる。 5. プロキシの動作 信頼ドメイン内のプロキシは、信頼するノード、あるいは信頼しないノード からメッセージを受信できる。プロキシが、信頼しないノードからメッセージ を受信し、P-Asserted-Identityヘッダーフィールドの追加を望むとき、プロ キシはメッセージの発信元を認証しなければならず[MUST]、そのメッセージに P-Asserted-Identityヘッダーフィールドを挿入するのに、この認証から生じ るアイデンティティを使わなければならない[MUST]。 プロキシが信頼するノードからメッセージ(リクエスト、または応答)を受信す る場合、P-Asserted-Identityヘッダーフィールド内の情報がもしあれば、ユ ーザー自体を認証したかのように使用できる。 P-Asserted-Identityヘッダーフィールドが存在しない場合、プロキシは多く てもSIPあるいはSIPS URIを1つ、および多くてもtel URL1つを含む P-Asserted-Identityヘッダーフィールドを追加してもよい[MAY]。プロキシが 信頼しないエレメントからメッセージを受信し、SIP、あるいはSIPS URIを含 むP-Asserted-Identityヘッダーフィールドが存在する場合、プロキシはその SIPまたはSIPS URIを単独のSIPまたはSIPS URIに置き換えるか、あるいは削除 しなければならない[MUST]。同様に、プロキシが信頼しないエレメントからメ ッセージを受信し、tel URIを含むP-Asserted-Identityヘッダーフィールドが 存在する場合、プロキシはそのtel URIを単独のtel URIと置き換えるか、ある いは削除しなければならない[MUST]。 プロキシがメッセージを別のノードへ転送するとき、まずそのノードを 信頼するか否かを決定しなければならない。ノードを信頼する場合、プロキシ は自身が生成した、あるいは信頼されたソースから受信したいかなる Jennings, et. al. Informational [Page 5] RFC 3325 SIP Asserted Identity November 2002 P-Asserted-Identityヘッダーフィールドをも削除しない。エレメントを信頼 しない場合、プロキシは、ユーザーがAsserted Identity情報を秘密にするこ とを要求したかどうか判断するために、(存在する場合は)Privacyヘッダーフ ィールドを検査しなければならない[MUST]。 6. 複数のアイデンティティに関するヒント プロキシが信頼しないエンティティから受信するメッセージ内に P-Preferred-Identityヘッダーフィールドが存在する場合、プロキシはその情 報を、認証済みユーザーに関する複数の有効なアイデンティティのうちどれを アサートするべきかを示唆するヒントとして使用してもよい[MAY]。そのよう なヒントが、そのユーザーに関するものとしてプロキシが知っている有効なア イデンティティのどれにも該当しない場合、プロキシは自身の構築による P-Asserted-Identityヘッダーフィールドを追加できるし、あるいはリクエス トを拒否できる(例えば、403 Forbiddenで)。プロキシは転送するすべ てのメッセージから、ユーザーが提示したP-Preferred-Identityヘッダーを削 除しなければならない[MUST]。 ユーザーエージェントは、信頼ドメイン内のプロキシサーバーへ P-Preferred-Identityヘッダーフィールドを送るだけである。ユーザーエージ ェントは、そのユーザーエージェントが信頼するプロキシへ直接送信されない メッセージにP-Preferred-Identityヘッダーフィールドを組み込んではならな い[MUST NOT]。ユーザーエージェントがP-Preferred-Identityヘッダーフィー ルドを含むメッセージを、信頼ドメインの外部にあるノードへ送信することに なっている場合、ヒントを与えられたアイデンティティはネットワーク(プラ イバシーへの否定的な派生的影響を持つ可能性がある)によって適切に処理さ れないかもしれない。 7. Privacyの要求 信頼されないエレメントへ伝達される前にP-Asserted-Identityヘッダーフィ ールドの削除を要求したいと望むパーティーは、Privacyヘッダーフィールド に本文書で定義されるプライバシートークン「id」を追加してもよい。 Privacyヘッダーフィールドは[6]で定義されている。このトークンが存在する 場合、プロキシは信頼されないエレメントへメッセージを転送する前に、すべ てのP-Asserted-Identityヘッダーフィールドを削除しなければならない[MUST]。 Privacyヘッダーフィールド値が「none」に設定されている場合、プロキシは P-Asserted-Identityヘッダーフィールドを削除してはならない[MUST NOT]。 プロキシが、信頼されないエレメントへリクエストを転送中で、かつ Privacyヘッダーフィールドが存在しないとき、プロキシは P-Asserted-Identityヘッダーフィールドを含んでもよいし[MAY]、あるいはそ れを削除してもよい[MAY]。その決定は信頼ドメインのポリシーの問題であり、 Spec(T)で指定されなければならない[MUST]。ローカルのプライバシーポリシ ーが妨げない限り、P-Asserted-Identityヘッダーフィールドは削除されるべ きではない[SHOULD NOT]ことを推奨する[RECOMMENDED]。これは、削除が Asserted Identityに基づいたサービスが機能しなくなる原因となりうるから である。 Jennings, et. al. Informational [Page 6] RFC 3325 SIP Asserted Identity November 2002 しかし信頼ドメインの全ユーザーが適切なプライバシーサービスへアクセスで きるのでない限り、P-Asserted-Identityのフォワーディングは、ユーザーが 要求していない、またはユーザーが防げない、情報の開示を結果として招くと いう点に留意するべきだろう。したがって、全ユーザーが本文書に記述される ようにプライバシーサービスへアクセスできることを強く推奨する [STRONGLY RECOMMENDED]。 Privacyヘッダーのpriv-value「id」の正式な仕様はセクション9.3で説明して いる。いつユーザーがプライバシーを要求するかに関する全般的なガイドライ ンは、[2]に記載されている。 メッセージ内に複数のP-Asserted-Identityヘッダーフィールド値が存在し、 P-Asserted-Identityヘッダーフィールドのプライバシーが要求される場合、 その要求を信頼されないエンティティへ転送する前に、ヘッダーフィー ルド値の全インスタンスは削除されなければならない[MUST]。 8. ユーザーエージェントサーバーの動作 通常ユーザーエージェントは、受信するP-Asserted-Identityヘッダーフィー ルドの値を、そのユーザーに提示する。それは、信頼ドメインにより提示さ れたアイデンティティは特定のものしか知らない、あるいはリクエストの Fromヘッダーフィールドよりも本質的に信頼できる、と見なすかもしれない。 しかしながら、いかなる特定の動作であれ、実装、あるいはサービスに特有の 動作である。また本文書は、メッセージ内にたまたまある、複数の P-Asserted-Identityヘッダーフィールド値(tel URLと並んでいるSIP URIな ど)を、ユーザーエージェントがハンドリングすることを命じるものではな い。 しかし、ユーザーエージェントサーバーが信頼しない以前のエレメントからメ ッセージを受信する場合、決してP-Asserted-Identityヘッダーフィールドを 使用してはならない[MUST NOT]。 UAが、P-Asserted-Identityヘッダーフィールドを含むメッセージを受信する 信頼ドメインの一部である場合、その値を自由に使用できるが、アサートされ たアイデンティティ情報を秘密にしておくことをユーザーが要求した場合、信 頼ドメインの一部ではないいかなるエレメントにも情報を転送しないことを、 保証しなければならない[MUST]。 UAがP-Asserted-Identityヘッダーフィールドを含むメッセージを受信する 信頼ドメインの一部ではない場合、その情報は秘密にする必要がないと見な すことができる。 9. 正式なシンタックス 以下のシンタックス仕様は、RFC-2234[4]の記述にあるとおり拡張 BNFを使用する。 Jennings, et. al. Informational [Page 7] RFC 3325 SIP Asserted Identity November 2002 9.1 P-Asserted-Identityヘッダー P-Asserted-Identityヘッダーフィールドは、信頼された SIPエンティティ(主と して中継媒体)間で、SIPメッセージを送信するユーザーが認証により検証され た時に、そのアイデンティティを伝えるために使用する。 PAssertedID = "P-Asserted-Identity" HCOLON PAssertedID-value *(COMMA PAssertedID-value) PAssertedID-value = name-addr / addr-spec P-Asserted-Identityヘッダーフィールド値は、厳密に1つのname-addr、また は addr-specで構成されなければならない[MUST]。1つ、あるいは2つの P-Asserted-Identity値が存在する可能性がある。存在する値が1つの場合、そ れはsip、sips、tel URIのいずれかでなければならない[MUST]。2つの値が存 在する場合、値の一方はsip、またはsips URIのいずれかで、もう一方はtel URIでなければならない[MUST]。プロキシがこのヘッダーフィールドを追加お よび削除できる(そして、そうするだろう)点は、注目に値する。 本文書は、以下のエントリーを[1]の表2に追加する。 ヘッダーフィールド where proxy ACK BYE CAN INV OPT REG ------------ ----- ----- --- --- --- --- --- --- P-Asserted-Identity adr - o - o o - SUB NOT REF INF UPD PRA --- --- --- --- --- --- o o o - - - 9.2 P-Preferred-Identityヘッダー P-Preferred-Identityヘッダーフィールドは、SIPメッセージを送信中のユー ザーが、信頼されたエレメントが挿入するであろうP-Asserted-Headerフィールド 値用に使用されることを望むアイデンティティを、ユーザーエージェントから 信頼されたプロキシへ伝達するために使用される。 PPreferredID = "P-Preferred-Identity" HCOLON PPreferredID-value *(COMMA PPreferredID-value) PPreferredID-value = name-addr / addr-spec P-Preferred-Identityヘッダーフィールド値は、厳密に1つのname-addr ある いはaddr-specで構成されなければならない[MUST]。1つないし2つの P-Preferred-Identity値が存在する可能性がある。存在する値が1つの場合、 それはsip、sips、tel URIのいずれかでなければならない[MUST]。2つの値が 存在する場合、値の一方はsip、またはsips URIのいずれかで、もう一方は tel URIでなければならない[MUST]。プロキシがこのヘッダーフィールドを追 加および削除できる(そして、そうするだろう)点は、注目に値する。 Jennings, et. al. Informational [Page 8] RFC 3325 SIP Asserted Identity November 2002 本文書は、以下のエントリーを[1]の表2に追加する。 ヘッダーフィールド where proxy ACK BYE CAN INV OPT REG ------------ ----- ----- --- --- --- --- --- --- P-Preferred-Identity adr - o - o o - SUB NOT REF INF UPD PRA --- --- --- --- --- --- o o o - - - 9.3 プライバシータイプ「id」 本仕様は、新規プライバシータイプ(「priv-value」)を、[2]で定義されてい るPrivacyヘッダーへ追加する。Privacyヘッダーフィールド内にこのプライバ シータイプが存在することは、ユーザーは、ユーザーが認証した信頼ドメイン の外部にあるSIPエンティティに対してNetwork Asserted Identityが秘密にさ れることを望むことを表す。複数のタイプのプライバシーを要求しているユー ザーは、そのPrivacyヘッダーフィールド値に、要求したプライバシータイプ のすべてを含まなければならない[MUST]点に注意すること。 priv-value = "id" Example: Privacy: id 10. 例 10.1 信頼されたゲートウェイへ渡されたNetwork Asserted Identity この例ではproxy.cisco.comが、SIP Digest認証からみつけたアイデンティテ ィからP-Asserted-Identityヘッダーフィールドを生成する。それはこの情報 を信頼されたプロキシへ転送し、信頼されたプロキシは信頼されたゲートウェイ へ転送する。これらの例は、認証済みアイデンティティ問題に関するこ れらのヘッダーだけを説明する、部分的なSIPメッセージで構成されている点 に注意すること。 * F1 useragent.cisco.com -> proxy.cisco.com INVITE sip:+14085551212@cisco.com SIP/2.0 Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-123 To: From: "Anonymous" ;tag=9802748 Call-ID: 245780247857024504 CSeq: 1 INVITE Max-Forwards: 70 Privacy: id Jennings, et. al. Informational [Page 9] RFC 3325 SIP Asserted Identity November 2002 * F2 proxy.cisco.com -> useragent.cisco.com SIP/2.0 407 Proxy Authorization Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-123 To: ;tag=123456 From: "Anonymous" ;tag=9802748 Call-ID: 245780247857024504 CSeq: 1 INVITE Proxy-Authenticate: .... realm="sip.cisco.com" * F3 useragent.cisco.com -> proxy.cisco.com INVITE sip:+14085551212@cisco.com SIP/2.0 Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-124 To: From: "Anonymous" ;tag=9802748 Call-ID: 245780247857024504 CSeq: 2 INVITE Max-Forwards: 70 Privacy: id Proxy-Authorization: .... realm="sip.cisco.com" user="fluffy" * F4 proxy.cisco.com -> proxy.pstn.net (trusted) INVITE sip:+14085551212@proxy.pstn.net SIP/2.0 Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-124 Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-abc To: From: "Anonymous" ;tag=9802748 Call-ID: 245780247857024504 CSeq: 2 INVITE Max-Forwards: 69 P-Asserted-Identity: "Cullen Jennings" P-Asserted-Identity: tel:+14085264000 Privacy: id Jennings, et. al. Informational [Page 10] RFC 3325 SIP Asserted Identity November 2002 * F5 proxy.pstn.net -> gw.pstn.net (trusted) INVITE sip:+14085551212@gw.pstn.net SIP/2.0 Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-124 Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-abc Via: SIP/2.0/TCP proxy.pstn.net;branch=z9hG4bK-a1b2 To: From: "Anonymous" ;tag=9802748 Call-ID: 245780247857024504 CSeq: 2 INVITE Max-Forwards: 68 P-Asserted-Identity: "Cullen Jennings" P-Asserted-Identity: tel:+14085264000 Privacy: id 10.2 明かされないNetwork Asserted Identity この例では、ユーザーエージェントが、sip:fluffy@cisco.comというアイデン ティティを優先する(prefer)ことを望むことを表すINVITEを最初のプロキシへ 送信し、最初のプロキシはこれをSIP Digestで認証する。最初のプロキシは P-Asserted-Identityヘッダーフィールドを生成し、信頼されたプロキシ (outbound.cisco.com)へ転送する。次のプロキシは、信頼しないbiloxi.comプ ロキシサーバーへこのリクエストを転送する前に、P-Asserted-Identityヘッ ダーフィールドと、Privacyに関するリクエストを削除する。 * F1 useragent.cisco.com -> proxy.cisco.com INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a111 To: From: "Anonymous" ;tag=9802748 Call-ID: 245780247857024504 CSeq: 1 INVITE Max-Forwards: 70 Privacy: id P-Preferred-Identity: "Cullen Jennings" * F2 proxy.cisco.com -> useragent.cisco.com SIP/2.0 407 Proxy Authorization Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a111 To: ;tag=123456 From: "Anonymous" ;tag=9802748 Call-ID: 245780247857024504 CSeq: 1 INVITE Proxy-Authenticate: .... realm="cisco.com" Jennings, et. al. Informational [Page 11] RFC 3325 SIP Asserted Identity November 2002 * F3 useragent.cisco.com -> proxy.cisco.com INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a123 To: From: "Anonymous" ;tag=9802748 Call-ID: 245780247857024504 CSeq: 2 INVITE Max-Forwards: 70 Privacy: id P-Preferred-Identity: "Cullen Jennings" Proxy-Authorization: .... realm="cisco.com" user="fluffy" * F4 proxy.cisco.com -> outbound.cisco.com (trusted) INVITE sip:bob@biloxi SIP/2.0 Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a123 Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-b234 To: From: "Anonymous" ;tag=9802748 Call-ID: 245780247857024504 CSeq: 2 INVITE Max-Forwards: 69 P-Asserted-Identity: "Cullen Jennings" Privacy: id * F5 outbound.cisco.com -> proxy.biloxi.com (not trusted) INVITE sip:bob@biloxi SIP/2.0 Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a123 Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-b234 Via: SIP/2.0/TCP outbound.cisco.com;branch=z9hG4bK-c345 To: From: "Anonymous" ;tag=9802748 Call-ID: 245780247857024504 CSeq: 2 INVITE Max-Forwards: 68 Privacy: id Jennings, et. al. Informational [Page 12] RFC 3325 SIP Asserted Identity November 2002 * F6 proxy.biloxi.com -> bobster.biloxi.com INVITE sip:bob@bobster.biloxi.com SIP/2.0 Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a123 Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-b234 Via: SIP/2.0/TCP outbound.cisco.com;branch=z9hG4bK-c345 Via: SIP/2.0/TCP proxy.biloxi.com;branch=z9hG4bK-d456 To: From: "Anonymous" ;tag=9802748 Call-ID: 245780247857024504 CSeq: 2 INVITE Max-Forwards: 67 Privacy: id 11. Spec(T)の例 本文書で記述するメカニズムの完全性は、信頼ドメイン内の全ノードが前も って決められた方法で動作するであろうことを(設定を通じて)知っている1ノ ードに依存する。これには、前もって決められた動作が明確に定義されるこ と、および信頼ドメインの全ノードが準拠していることが必要である。 信頼ドメインT内の全ノードが準拠しなければならない仕様セットは、 「Spec(T)」と呼ばれる。 本セクションでSpec(T)の例を以降に記述するが、これは決して規範ではな い。 1. プロトコル要件 以下の仕様はサポートされなければならない[MUST]。 1. RFC 3261 2. RFC 3325 2. 認証要件 ユーザーはSIP Digest認証で認証されなければならない[MUST]。 3. セキュリティ要件 信頼ドメイン内におけるノード間、および信頼ドメイン内のUAとノー ド間の接続は、RSA_WITH_AES_128_CBC_SHA1の暗号スイート(suite)を 利用するTLSを使用しなければならない[MUST]。その信頼ドメイン内 のノードの相互認証が実行されなければならず[MUST]、機密保持がネ ゴシエートされなければならない[MUST]。 Jennings, et. al. Informational [Page 13] RFC 3325 SIP Asserted Identity November 2002 4. 信頼ドメインの適用範囲 この協定で規定される信頼ドメインは、以下のような有効な証明書を所 有するホストで構成される。(【訳註】原文誤植posses→possessと判断 して訳した。) a) examplerootca.orgにより署名されている b) そのsubjectAltNameが、以下のドメイン名のいずれかで終了する trusted.div1.carrier-a.net／trusted.div2.carrier-a.net／ sip.carrier-b.com c) そのドメイン名が、証明書内のsubjectAltNameのhostnameと一致す る 5. Privacyヘッダーが存在しないときの暗黙的なハンドリング 信頼ドメイン内のエレメントは「id」プライバシーサービスをサポー トしなくてはならないため、Privacyヘッダーフィールドが存在しない ことは、ユーザーがいかなるプライバシーも要求していないことを示す と見なされる可能性がある。リクエスト内にPrivacyヘッダーフィール ドが存在しない場合、その信頼ドメイン内のエレメントはプライバシ ーがまったく要求されていないかのように、動作しなければならない [MUST]。 12. セキュリティの考慮 本文書で提示されるメカニズムは、SIPにおけるアイデンティティとプライバ シーの問題の部分的な考慮である。例えばこれらのメカニズムは、エンドユー ザーが、信頼されたサービスプロバイダーなしにエンドツーエンドでアイデン ティティ情報を安全に共有できる手段を提供するものではない。ユーザーが 「private」として指定するアイデンティティ情報は、信頼ドメインに参加し ているどの中継媒体による検査も受けられる。その情報は、信頼チェーン (chain of trust)内で一番弱いリンクと同程度の信頼性を持つ推移的信頼 (transitive trust)により安全にされる。 信頼されたエンティティがどのデスティネーションへでも、 P-Asserted-Identityヘッダーフィールド内にそのパーティーのアイデンティ ティを持つメッセージを送信するとき、そのエンティティはアイデンティティ 情報の機密性と完全性を守るため、そのアイデンティティ情報を盗聴および傍 受／妨害から保護するための予防措置を講じなければならない[MUST]。適切な 暗号スイートを伴うTLSまたはIPSecといった、トランスポートまたはネットワ ーク層ホップバイホップセキュリティメカニズムの使用は、この要件を満たす ことが可能である。 13. IANA条項 13.1 新規SIPヘッダーフィールドの登録 本文書は、「P-Asserted-Identity」および「P-Preferred-Identity」の、2つ のprivate SIPヘッダーフィールドを定義する。Transport Areaのポリシーに より推奨されたように、これらのヘッダーはIANAにより、本文書のRFC番号を 参考として使って、SIPヘッダー登録に登録されるべきである。 Jennings, et. al. Informational [Page 14] RFC 3325 SIP Asserted Identity November 2002 ヘッダー名: P-Asserted-Identity 省略形: なし 登録者: Cullen Jennings fluffy@cisco.com 規範となる記述: 本文書のセクション9.1 ヘッダー名: P-Preferred-Identity 省略形: なし 登録者: Cullen Jennings fluffy@cisco.com 規範となる記述: 本文書のセクション9.2 13.2 SIP Privacyヘッダーの「id」プライバシータイプの登録 プライバシータイプ名: id 簡単な説明: Third-Party Asserted Identityに対し要求される プライバシー 登録者: Cullen Jennings fluffy@cisco.com 規範となる記述: 本文書のセクション9.3 14. 謝辞 本文書を構成するテキストの大半を表すドラフトの作成に対し、Bill MarshallとFlemming Andreason[6]、Mark Watson[5]、Jon Peterson[7]に感謝 する。Jonathan Rosenberg、Rohan Mahy、Paul Kyzivatをはじめ、多くの方々 に有益なコメントを頂いたことに感謝する。 規範となる参考文献 [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. [2] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002. Jennings, et. al. Informational [Page 15] RFC 3325 SIP Asserted Identity November 2002 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. 有益な参考文献 [5] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, November 2002. [6] Andreasen, F., "SIP Extensions for Network-Asserted Caller Identity and Privacy within Trusted Networks", Work in Progress. [7] Peterson, J., "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", Work in Progress. Jennings, et. al. Informational [Page 16] RFC 3325 SIP Asserted Identity November 2002 著者の連絡先 Cullen Jennings Cisco Systems 170 West Tasman Drive MS: SJC-21/3 San Jose, CA 95134 USA Phone: +1 408 527-9132 EMail: fluffy@cisco.com Jon Peterson NeuStar, Inc. 1800 Sutter Street, Suite 570 Concord, CA 94520 USA Phone: +1 925/363-8720 EMail: Jon.Peterson@NeuStar.biz Mark Watson Nortel Networks Maidenhead Office Park (Bray House) Westacott Way Maidenhead, Berkshire England Phone: +44 (0)1628-434456 EMail: mwatson@nortelnetworks.com Jennings, et. al. Informational [Page 17] RFC 3325 SIP Asserted Identity November 2002 完全な著作権表記 Copyright (c) The Internet Society (2002). All Rights Reserved. 本記述とその翻訳は複写し他に提供することができる。また論評を加えた派 生的製品や、この文書を説明したり、その実装を補助するもので、上記の著 作権表示およびこの節を付加するものはすべて、全体であってもその一部で あっても、いっさいの制約を課されること無く、準備、複製、発表、配布す ることができる。しかし、この文書自体にはいかなる方法にせよ、著作権表 示やインターネットソサエティもしくは他のインターネット関連団体への参 照を取り除くなどの変更を加えてはならない。インターネット標準を開発す るために必要な場合は例外とされるが、その場合はインターネット標準化過 程で定義されている著作権のための手続きに従わなければならない。またRFC を英語以外の言語に翻訳する必要がある場合も例外である。 以上に述べられた制限は永久的なものであり、インターネットソサエティも しくはその継承者および譲渡者によって破棄されることはない。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、インターネッ トソサエティおよびIETFは、この情報がいかなる権利も侵害していないとい う保証、商用利用および特定目的への適合性への保証を含め、また、これら だけに限らずすべての保証について、明示的もしくは暗黙的の保証は行われ ない。 謝辞 RFC編集者の職務のための資金は、現在、インターネットソサエティによって 提供されている。 --------------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただし、 この権利の設定は原文から新たな翻訳を作成し公開することを妨げるものではあり ません。本翻訳物は、本著作権表示を含めて改変しないことを条件に再配布を許可 します。翻訳の正確さについては一切保証しません。原文とあわせてご利用くだ さい。 2005年 --------------------------------------------------------------------------- Jennings, et. al. Informational [Page 18]