Network Working Group J. Peterson Request for Comments: 4474 NeuStar Category: Standards Track C. Jennings Cisco Systems August 2006 セッション開始プロトコル(SIP)の認証ID管理の強化 Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP) 本文書の位置付け 本文書は、インターネットコミュニティのためのインターネット標準化過程 プロトコルを規定し、改善のための議論や提案を依頼するものである。標準 化の段階や、プロトコルの位置付けについては、最新版の"Internet Official Protocol Standards" (STD 1)を参照されたい。本文書の配信は無 制限である。 著作権表記 Copyright (C) The Internet Society (2006). 概要 セッション開始プロトコル(Session Initiation Protocol/SIP)で既存のセ キュリティメカニズムは、SIPリクエストを開始するエンドユーザーのIDを 暗号的に保証するには不適切である。特にドメイン間の状況ではそうであ る。本文書は、SIPメッセージの発信元を安全に識別する仕組みを定義する。 そのために2つの新しいSIPヘッダーフィールドを定義する。Identityは、ID を検証するために使用する署名を伝達する。Identity-Infoは、署名者の証 明書への参照を伝達する。 Peterson & Jennings Standards Track [Page 1] RFC 4474 SIP Identity August 2006 目次 1. はじめに ..................................................... 3 2. 用語 ......................................................... 3 3. 背景 ......................................................... 3 4. 操作の概要 ................................................... 6 5. 認証サービスの動作 ........................................... 7 5 1. ダイアログ内のIDと対象変更 ............................ 10 6. ベリファイアの動作 .......................................... 11 7. ユーザーエージェントの考慮事項 .............................. 12 8. プロキシサーバーの考慮事項 .................................. 13 9. ヘッダー構文 ................................................ 13 10. 準拠のテストと例 .......................................... 16 10 1. MIMEボディが単一パートのIdentity-Info ................ 17 10 2. MIMEボディまたはContactがないリクエストのIdentity .... 20 11. IdentityとTEL URIのスキーム ................................ 22 12. プライバシの考慮事項 ...................................... 23 13. セキュリティの考慮事項 .................................... 24 13 1. digest-string要素の操作 .............................. 24 13 2. 表示名とIdentity ...................................... 27 13 3. 認証サービスに対する接続の保護 ........................ 28 13 4. ドメイン名と従属関係 .................................. 29 13 5. 認可と推移の戦略 ...................................... 30 14. IANA条項 .................................................. 31 14 1. ヘッダーフィールド名 .................................. 31 14 2. 428 'Use Identity Header'応答コード .................. 32 14 3. 436 'Bad Identity Header'応答コード .................. 32 14 4. 437 'Unsupported Certificate' 応答コード .............. 32 14 5. 438 'Invalid Identity Header'応答コード .............. 33 14 6. Identity-Infoのパラメータ ............................ 33 14 7. Identity-Infoのアルゴリズムパラメータ値 .............. 33 付録A. 謝辞 .................................................... 34 付録B. メッセージ例のbit-exactアーカイブ ...................... 34 B 1.エンコード済み参照ファイル .............................. 35 付録C. 元の要件 .............................................. 38 参考文献 ...................................................... 39 規範となる参考文献 .......................................... 39 有益な参考文献 .............................................. 39 Peterson & Jennings Standards Track [Page 2] RFC 4474 SIP Identity August 2006 1. はじめに 本文書は、セッション開始プロトコル(Session Initiation Protocol/SIP、 RFC 3261 [1])における認証ID管理の既存の仕組みを強化する。本文書の用 途からIDとはSIP URIと定義され、一般的には、ユーザーに到達するための 標準のAddresses-of-Record (AoR)である(たとえば 「sip:alice@atlanta.example.com」)。 RFC 3261は、SIPリクエスト内でユーザーが自身のIDを表すことができる場 所をいくつか規定している。特に、ユーザーが設定するFromヘッダーフィー ルドがある。ただし、何らかの暗号的な認証メカニズムがないため、SIPリ クエストの受信者にはFromヘッダーが適切に設定されたことを検証する方法 がない。 RFC 3261はSIPユーザーエージェント(user agents/UA)が採用することがで きるセキュリティメカニズムをいくつか規定している。たとえば、ダイジェ スト、TLS (Transport Layer Security)、S/MIMEがある(実装によっては他 のセキュリティスキームもサポートされている可能性がある)。ただし、 現在、(たとえばS/MIMEで)自身を認証するために必要なエンドユーザー証明 書をサポートしているSIPユーザーエージェントはほとんどない。さらに、 ダイジェスト認証は、発信元と発信先が事前に配置した秘密を共有する必要 があるため、制約がある。SIPユーザーエージェントは、以前に関連がない 発信先でもリクエストを送信できることが望ましい。つまり、現在の電話網 と同様である。電話では過去に関係のない相手から着呼することができる が、それでもその個人の表示される発呼者IDが正確であるという十分な保証 がある。本文書で説明するような暗号的な手法があれば、現在の電話網が提 供しているよりも遙かに強力でなりすましが困難な方法で、IDを保証できる 可能性がある。 2. 用語 本文書では、以下のキーワードはRFC 2119[2]に記述されている通りに解釈 されるべきであり、準拠するSIP実装に対する要求レベルを示すものであ る。「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、 「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、 「MAY」、「OPTIONAL」。 3. 背景 SIPアプリケーションとSIPサービスの多くの用法は、認可ポリシーに左右さ れる。認可ポリシーは自動化することもできるし、ユーザーが手動で適用す ることもできる。手動の例として、発呼側のCaller-IDを表示するインター ネット電話アプリケーションがある。この場合、呼に応答する前に発呼側を 確認することができる。自動の例として、サブスクリプションの受け入れま たは拒否を決定する前に、サブスクライバの可能性があるIDとホワイトリス Peterson & Jennings Standards Track [Page 3] RFC 4474 SIP Identity August 2006 トとを比較するプレゼンスサービスがある。どちらの場合でも、不正ユー ザーはなりすましによって認可ポリシーを回避しようとする。SIPリクエス トを送信した側のプライマリID、つまりFromヘッダーフィールドは、ユー ザーエージェントの制御によって任意に設定できるため、現在のところ、な りすましは非常に容易である。 本文書に記載されているメカニズムの目的は、なりすましで認可ポリシーを 回避することができない強力なIDシステムをSIPで実現することである。 RFC 3261準拠のユーザーエージェントはすべてダイジェスト認証をサポート している。ダイジェスト認証では、ユーザーエージェント自身をSIPレジス トラに対して認証する手段として、共有秘密を利用する。登録によって、 ユーザーエージェントは、特定のSIP AoR URI (「sip:alice@atlanta.example.com」など)にリクエストを送信することが できる適切なエンティティであることを表すことができる。 本文書で使用されるIDの定義では、登録とはレジストラに対するユーザーID の証明である。ただし、ユーザーエージェントが自身のIDをレジストラに対 して証明するために使用する証明書は、任意のユーザーエージェントやプロ キシサーバーが有効性を確認することはできない。 -- つまり、このような証明書は、そのユーザーエージェントとユーザー エージェントのドメイン管理者との間でのみ共有される。そのため、この共 有秘密があっても、ユーザーが多様な受信者を直接認証する助けにはなら ない。 受信者には、REGISTERリクエスト以外の「返信アドレス」(つまり、From ヘッダーフィールド値)が正規にアサートされたものかどうかを判断する手 段が必要である。 登録に使用されるAoR URIは、UAが「返信アドレス」のIDを受信側に示すた めにリクエストのFromヘッダーフィールドに通常設定するURIでもある。認 可の観点から、特定のAoRのドメインに登録する資格を持つことを証明でき る場合、そのAoRに対するリクエストを正規に受信可能であることを証明で きる。したがって、そのAoRを、登録以外のSIPリクエスト(INVITEなど)の Fromヘッダーフィールドに配置すると、正規に到達することができる「返信 アドレス」を提供することになる。言い換えると、その「返信アドレス」に 対するリクエストを受信する資格がある場合、Fromヘッダーフィールドにそ の「返信アドレス」をアサートすることも認可されることになる。当然なが ら、これは、特定ユーザーがFromヘッダーフィールドを設定する資格がある ことをドメインが判断できる唯一の方法である(余談だが、Fromのその他の URI (匿名URIなど)については、他の認可ポリシーが適用される)。 したがって、SIPユーザーエージェントは、ローカルドメインから認証され ていること、およびFromヘッダーフィールドの設定が認可されていることに ついて、何らかの方法でSIPリクエストの受信者に提供する手段がある、と Peterson & Jennings Standards Track [Page 4] RFC 4474 SIP Identity August 2006 いうのが理想である。本文書では、SIP向けの仲介的な認証アーキテクチャ を提案する。このアーキテクチャでは、リクエストはユーザーのローカルド メインのサーバーに送信される。このサーバーは受信したリクエストを認証 する(このとき、ドメインがREGISTERリクエストを認証するときと同じ手法 を使用する)。メッセージが認証された後、ローカルドメインは、送信側 ユーザーは認証され、そのユーザーはFromヘッダーフィールドの使用が認可 されているということを、他のSIPエンティティに通知する何らかの手段が 必要になる。本文書は、このような認証の許可を共有する方法について扱 う。 RFC 3261のセクション26.3.2.2でも、本文書とよく似たアーキテクチャにつ いてすでに説明されている。RFC 3261セクション26.3.2.2のアーキテクチャ では、ユーザーエージェントはローカルのプロキシサーバーに認証され、結 果として共通のTLS経由でリモートのプロキシサーバーからも認証されるこ とになり、発信元ドメインとリモートドメインとの間に推移的な認証の2リ ンクチェーンが作成される。これは一部のアーキテクチャでは機能するが、 実用的ではない部分もいくつかある。まず、推移的な信頼は、エンドツーエ ンドで有効性を確認できるアサートよりも本質的に弱い。SIPリクエストは、 別々の管理ドメインにある複数の仲介エンティティを経由する可能性があ る。このような場合、推移的な信頼はさらに説得力がなくなる。 この問題を解決する方法の1つは、特権を持つSIPヘッダーの形式で、ユー ザーのIDをアサートする「信頼済み」SIP仲介エンティティを使用する方法 である。これを実行するメカニズム(P-Asserted-IDヘッダーを使用)は、 [12]に記載されている。ただし、このソリューションは、エンドツーエンド の暗号を使用した認証ではなく、仲介エンティティ間でのホップバイホップ の信頼のみを許容している。また、厳密な相互信頼関係がある、ノードの管 理ネットワークを想定している。つまり、広範なインターネット配備とは互 換性がないという想定である。 したがって、本文書は、「認証サービス」と新しいSIPヘッダーである Identityヘッダーという概念に基づくドメイン間またはドメイン内という環 境で、エンドユーザーSIP IDの暗号的な保証を共有する手段を規定する。 本文書の範囲として、このID保証はSIPリクエストにのみ制限されているこ とに注意。SIP応答についてこの問題を解決するのはさらに複雑なので、今 後の研究課題である。 本仕様では、IDサービスを提供し、IDを検証する役割を、ユーザーエージェ ントまたはプロキシサーバーに許容している。エンドツーエンドのセキュリ ティを最大限にするには、エンドユーザーが自身の証明書とそれに対応する プライベートキーを取得する方が明らかに望ましい。その場合、エンドユー ザーは認証サービスとして動作することが可能である。ただし、エンドユー ザーの証明書は、実用的でもないし安価とも言えない。たとえば、エンド ユーザーまで広げてPKI (Public Key Infrastructure)を確立することは困 難であり、さらに1人のユーザーが多数のSIPユーザーエージェント(電話、 Peterson & Jennings Standards Track [Page 5] RFC 4474 SIP Identity August 2006 PC、ラップトップ、PDA、ゲーム機器)を採用する可能性がある。このような 環境では、複数の機器間でキーとなる要素を同期することは非常に複雑にな り、エンドポイントの動作を多数追加する必要が出てくる可能性がある。多 様な機器で複数の証明書を管理する方法にも多くの問題があり、ユーザーに は評判がよくない。 したがって、このメカニズムを初めて使用する場合、仲介エンティティが認 証サービスの役割をインスタンス化する可能性が高い。 4. 操作の概要 このセクションでは、参照情報(仕様外)として、本文書で説明するメカニズ ムの高レベルな概要を説明する。 たとえば、Aliceというユーザーが、example.comのホームプロキシと sip:alice@example.comというAddresses-of-Recordを持ち、 sip:bob@example.orgと通信しようとしているとする。 AliceはINVITEを生成し、リクエストのFromヘッダーフィールドに自分のID を設定する。次に、自ドメインの認証サービスプロキシにTLS上でINVITEを 送信する。 認証サービスはAliceを認証し(おそらくダイジェスト認証のチャレンジを送 信する方法)、AliceがFromヘッダーフィールドに設定されたIDをアサートす る資格を持つことを検証する。 この値はAliceのAoRか、またはプロキシサーバーのポリシーでAliceが使用 することを許可している他の値である可能性もある。メッセージのFromヘッ ダーフィールドやボディを含め、次に特定のヘッダー上でハッシュが算出さ れる。このハッシュは、ドメイン(Aliceの場合はexample.com)の証明書で署 名され、SIPメッセージの新しいヘッダーフィールド「Identity」ヘッダー に挿入される。 プロキシは、自ドメインのプライベートキーを保持しているため、このリク エストの発信元が認証されていること、およびAliceがFromヘッダーフィー ルドに指定されるID (SIPのAddresses-of-Record)を主張する資格があるこ とをアサートする。また、プロキシは付随ヘッダーフィールドの Identity-Infoを挿入する。このヘッダーフィールドは、Bobが証明書を持っ ていない場合に取得する方法を通知する。 Bobのドメインはリクエストを受信すると、Identityヘッダーフィールドで 指定された署名の有効性を確認する。これによって、Bobのドメインは、 FromヘッダーフィールドのAoRのホスト部で示されるドメインがユーザーを 認証したことと、ユーザーがFromヘッダーフィールド値をアサートすること を許可したことを検証することができる。これと同じ検証操作をBobのユー ザーエージェントサーバー(user agent server/UAS)で実行する可能性も ある。 Peterson & Jennings Standards Track [Page 6] RFC 4474 SIP Identity August 2006 5. 認証サービスの動作 本文書は、認証サービスというSIPエンティティについて新しい役割を定義 する。認証サービスの役割は、プロキシサーバーまたはユーザーエージェン トがインスタンス化することができる。認証サービスの役割をインスタンス 化するエンティティは、ドメイン証明書のプライベートキーを所有しなけれ ばならない[MUST]。この役割をインスタンス化する仲介エンティティは、そ のドメインに登録できる1人または複数のSIPユーザーを認証する機能を持た なければならない[MUST]。一般的に、この役割はプロキシサーバーがインス タンス化する。理由は、プロキシサーバーは静的なホスト名があり、対応す る証明書を保持し、SIPレジストラ機能(自ドメインのユーザーを認証するこ とができる機能)へのアクセス権がある可能性が高いためである。また、認 証サービスの役割は、リダイレクトサーバーとして動作するエンティティが インスタンス化する可能性もあるが、今後の研究課題として残っている。 認証サービスとして動作するSIPエンティティは、Dateヘッダーフィールド がSIPリクエストにない場合、追加しなければならない[MUST](Dateヘッダー フィールドでベリファイア(verifier / 検証者)を補助する方法については セクション9を参照)。同様に、認証サーバーはContent-Lengthヘッダー フィールドがSIPリクエストにない場合、追加しなければならない[MUST]。 これによって、ベリファイアがメッセージを検証するときに、認証サービス と同じメッセージボディのバイト数でハッシュしていることを、二重に チェックできる。 認証サービスの役割をインスタンス化するエンティティは、SIPリクエスト でIdentityヘッダーを生成するために、以下の手順を実行する。 手順1: 認証サービスは、リクエストから送信側のIDを抽出しなければならない [MUST]。認証サービスはこの値をFromヘッダーフィールドから取得する。こ のAoRは本書で「Identityフィールド」と呼ばれる。Identityフィールドに SIPまたはSIPS (SIP Secure) URIが含まれる場合、認証サービスはIdentity フィールドのホスト名部分を抽出し、それを責任を持つドメインと比較しな ければならない[MUST](このとき、プロキシサーバーは責任を持つドメイン を決定するときにRFC 3261のセクション16.4の手順に従う)。Identity フィールドがTEL URIスキームを使用している場合、認証サービスのポリ シーによって、このIDに責任を持つかどうかを判断する。詳細についてはセ クション11を参照。認証サービスが当該のIDに責任を持たない場合、通常ど おりにリクエストの処理と転送を行うべきである[SHOULD]。ただし、 Identityヘッダーを追加してはならない[MUST NOT]。既存のIdentityヘッ ダーを認証サービスで処理する方法の詳細については、以下を参照のこと。 Peterson & Jennings Standards Track [Page 7] RFC 4474 SIP Identity August 2006 手順2: 認証サービスは、リクエストの送信者がIdentityフィールドで指定されたID を主張する資格を持つかどうかを判断しなければならない[MUST]。この場 合、認証サービスはメッセージの送信者を認証しなければならない[MUST]。 この認証方法として考えられる方法をいくつか説明する。 認証サービスがSIP仲介エンティティ(プロキシサーバー)によってインス タンス化される場合、ダイジェスト認証スキームを使用して(または、RFC 3261のセクション22.3に記載されているようにキャッシュされた資格情 報を使用して、チャレンジを予想して送信されるリクエストの Proxy-Authenticateヘッダーを参照して)、リクエストを407応答コード でチャレンジすることができる。クライアントがダイジェスト認証を使 用して自身を認証した状況で、プロキシサーバーがクライアントとの間 でTLS接続を維持している場合、以前の認証手順で取得したID値は、追加 でダイジェストのチャレンジを行わなくても再利用することができる。 認証サービスをSIPユーザーエージェントがインスタンス化する場合、 ユーザーエージェントは、ユーザーがユーザーエージェントにドメイン のプライベートキーを提供できること、または、できればプライベート キーなどを解除するパスワードを提供することをその場で認証できると 言える。 Fromヘッダーフィールドで特定ユーザー名の使用を認可することは、認証 サービスのローカルポリシーの問題である。これは、認証の実行方法に依存 する部分が大きい。たとえば、ポリシーの例を挙げると、 Proxy-Authorizationヘッダーの「username」で指定されたユーザー名は、 SIPメッセージのFromヘッダーフィールドのユーザー名にそのまま対応しな ければならない[MUST]。ただし、この方法は、制限が多すぎたり不適切すぎ る場合が多い。領域によっては、SIPのFromヘッダーのユーザー部に対応し ないProxy-Authorizationの「username」パラメータを使用する場合や、 ユーザーが同じ管理ドメインで複数のアカウントを管理する場合もある。後 者の場合、Proxy-Authorizationの「username」パラメータ値と、その 「username」へ正規にアサートされた1つ以上のSIP URIセットとの間のマッ ピングをドメインが維持する場合もある。たとえば、ユーザー名は3GPP (Third Generation Partnership Project)で定義されているように「プラ イベートID」と対応させることができる。この場合、Fromヘッダーフィール ドには、このプライベートIDと関連付けられるパブリックIDのいずれかを含 めることができる。この場合、ポリシーの例を挙げると、Fromヘッダー フィールドのURIは、Proxy-Authorizationヘッダーの「username」と関連付 けられたマップ済みURIのいずれか1つにのみ対応しなければならない[MUST]。 このようなポリシーには、匿名性などのような場合に多様な例外が発生す る。FromヘッダーフィールドでアサートされたAoRが、 Peterson & Jennings Standards Track [Page 8] RFC 4474 SIP Identity August 2006 「sip:anonymous@example.com」のような形式を使用する場合、 「example.com」プロキシは、ユーザーがドメインで有効なユーザーである ことを認証すべきであり、通常どおりFromヘッダーフィールドに署名を挿入 すべきである。 このチェックは、Fromヘッダーフィールドのaddr-specで実行されることに 注意(たとえば、「sip:alice@atlanta.example.com」のような送信側URI)。 このとき、Fromヘッダーフィールドのdisplay-name部は変換されない。 認証サービスは、display-nameのチェックと有効性の確認を行い、送信者が 使用できるdisplay-nameのリストと比較してもよい[MAY]。display-nameが ポリシーの制約に適合しない場合、認証サービスは403応答コードを返さな ければならない[MUST]。理由フレーズには問題の特性を示すべきである。 たとえば、「Inappropriate Display Name」など。ただし、display-nameは 常に指定されるわけではなく、多くの環境では、display-nameの検証に必要 な操作手順が存在しない可能性がある。 詳細はセクション13.2を参照のこと。 手順3: 認証サービスは、リクエストの既存Dateヘッダーが正確であることを保証す べきである[SHOULD]。ローカルポリシーで、Dateを正確にする方法を的確に 指示することができる。推奨[RECOMMENDED]値は最大で10分の相違である。 こうすることでベリファイアがリクエストに混乱する可能性は低くなる。 Dateヘッダーと、認証サービスが示す現在の時間との時差が10分を超える 場合、認証サービスはリクエストを拒否すべきである[SHOULD]。ユーザー エージェントクライアント(UAC)がリクエストの検証が失敗することを狙っ て、Dateヘッダーを悪用する可能性があるため、この動作は必須ではない。 メッセージを処理するときに否認防止や完璧なレコードを実現するという目 的は、Identityヘッダーにはない。最終的に、認証サービスは、Dateヘッ ダーが証明書の有効期間内に含まれることを検証しなければならない [MUST]。Dateヘッダーフィールド値に関連するセキュリティ特性の詳細につ いては、セクション9を参照。 手順4: 認証サービスは、IDの署名を構築し、この署名を含むリクエストにIdentity ヘッダーを追加しなければならない[MUST]。Identityヘッダーがリクエスト に追加された後に、認証サービスはIdentity-Infoヘッダーも追加しなけれ ばならない[MUST]。Identity-Infoヘッダーには、証明書を取得できるURIが 含まれる。 これら両ヘッダーの生成については、セクション9を参照。 Peterson & Jennings Standards Track [Page 9] RFC 4474 SIP Identity August 2006 最終的に、認証サービスはメッセージを通常どおりに転送しなければならな い[MUST]。 5.1. ダイアログ内のIDと対象変更 対象変更(retargeting)とは、広義では、仲介エンティティによる Request-URIの変更と定義される。より具体的には、対象変更とは、元の対 象URIを、異なるユーザー(元の対象URIで登録する資格を持たないユーザー) に対応するURIで置き換えることである。この定義では、たとえば、対象変 更にはRequest-URIをエンドポイントのコンタクトアドレス(元の対象URIで 登録されたエンドポイント)に変換することは含まれない。 ダイアログを構成するリクエストの対象が変更されると、ダイアログ内で反 対方向に送信されるリクエストにIdentityメカニズムを適用するときに、 Identityメカニズムにいくつかの問題が発生する。このセクションでは、こ のような場合に関する仕様外の考慮事項を説明する。 リクエストの対象が変更されると、Toヘッダーフィールド値で指定された URIでは識別されないユーザーのSIPエンドポイントに到達する可能性があ る。ダイアログを構成するリクエストのToヘッダーフィールド値は、ダイア ログ内で反対方向に送信されたリクエストのFromヘッダーフィールドとして 使用される。したがって、これは反対方向で送信されるリクエストについて 認証サービスが署名するヘッダーである。対象変更の状況では、Fromヘッ ダーのURIが、反対方向で送信されたリクエストの送信者を特定しない場合、 Fromヘッダー上にIdentityの署名を提供することは明らかに不適切である。 前述のように、認証サービスが、リクエストのFromヘッダーフィールドのド メインに責任を持たない場合、Identityヘッダーをリクエストに追加しては ならない[MUST NOT]。また、リクエストを通常どおり処理/転送すべきで ある。 対象変更を予想する方法などは、本文書の範囲外である。また、ダイアログ 内で反対方向のリクエストの場合と、同じ方法が応答のIDにも適用できる可 能性が高い。したがって、本文書では「被接続パーティ」に関して実装者向 けに特別な指針を示さない。対象変更がダイアログを構成するリクエストで 発生した場合でも、認証サービスの動作は変わらない。最終的に、認証サー ビスは、Fromヘッダーフィールドで指定されたIDをアサートする資格を持つ 場合、反対方向のダイアログのリクエストでもIdentityヘッダーを提供す る。資格を持たない場合、Identityヘッダーを提供しない。 応答のID問題と解決案の詳細については、[15]を参照してください。 Peterson & Jennings Standards Track [Page 10] RFC 4474 SIP Identity August 2006 6. ベリファイアの動作 本文書は、サーバーというSIPエンティティについて新しい論理的役割を導入 する。ベリファイアはIdentityヘッダーを含むSIPメッセージを受信した場 合、署名を調べてメッセージの送信者IDを検証する。一般的に、この検証結 果は、本文書の範囲外である認証処理への入力として提供される。Identity ヘッダーがリクエストに存在せず、ローカルポルシーで必須とされている場 合(たとえば、per-sending-domain (送信側ドメインごと)のポリシーや per-sending-user (送信側ユーザーごと)のポリシーに基づいて)、428 'Use Identity Header' 応答を送信しなければならない[MUST]。 ベリファイアとして動作するエンティティは、メッセージの送信者IDを検証 するには、以下の手順を指定した順序どおりに実行しなければならな い[MUST]。 手順1: ベリファイアは、署名側ドメインの証明書を取得しなければならない [MUST]。本仕様をサポートする実装は、ドメインの証明書を保持する何らか の手段を持つべきである(証明書の有効期間と取り消しに関する通常の実行 方法に従って)。こうすることで、同じドメインからリクエストを受信する たびに同じ証明書をダウンロードするという無駄な作業を回避することがで きる。この方法でキャッシュされた証明書は、Identity-Infoヘッダー フィールド値で指定されたURIでインデックスすべきである。 このメッセージへの署名に使用されるドメインの証明書が、ベリファイアに 前もって知られていない場合、SIPエンティティは、Identity-Infoヘッダー を逆参照(dereferencing)することで、この証明書を検出すべきである [SHOULD]。ただし、実装固有の方法として、ドメインの証明書を取得するた めの、より効率的な方法がある場合はこの限りではない。Identity-Info ヘッダーのURIスキームを逆参照できない場合、436 'Bad Identity-Info'応 答を返さなければならない[MUST]。ベリファイアは、通常の方法でこの証明 書を処理する。たとえば、有効期限切れではないことのチェック、信頼認証 機関(certification authority/CA)へ戻るチェーンが有効であることの チェック、取り消しリストに含まれていないことのチェックなどである。証 明書を取得した場合、RFC 3280 [9]の手順に従って有効性を確認しなければ ならない[MUST]。証明書が有効と判断されなかった場合(自分で署名され信 頼できない場合、未知または信頼できない証明機関が署名した場合、期限切 れの場合、取り消されている場合)、ベリファイアは437 'Unsupported Certificate'応答を送信しなければならない[MUST]。 手順2: ベリファイアは、セクション13.4の処理に従って、Fromヘッダーフィールド のURIについて署名者が権利を持つかどうかを判断しなければならない [MUST]。 Peterson & Jennings Standards Track [Page 11] RFC 4474 SIP Identity August 2006 手順3: ベリファイアは、セクション9のハッシュ済みダイジェスト文字列を生成す る手順に従って、Identityヘッダーフィールドの署名を検証しなければなら ない[MUST]。ベリファイアは、メッセージ上の署名が再構築されたダイジェ スト文字列に対応しないと判断した場合、438 'Invalid Identity Header' 応答を返さなければならない[MUST]。 手順4: ベリファイアは、セクション13.1に記載されて方法で、Date、Contact、 Call-IDの各ヘッダーを検証しなければならない[MUST]。受信者は、 Identityの署名を検証する場合、セクション13.1に記載されるすべての操作 をサポートしなければならない[MUST]。こうすることで、対応するプライ ベートキーがIdentityヘッダーの署名に使用された証明書の有効期間内に、 Dateヘッダーの値が含まれることがさらに確実になる。 7. ユーザーエージェントの考慮事項 このメカニズムは、機会があれば既存のSIP配備へ適用することができる。 そのため、SIPユーザーエージェントの動作を効率化するための変更は必要 ない。ただし、このメカニズムはUACと認証サービスとの間に完全性の保護 は提供しないため、UACは完全性を実現する何らかの方法を実装すべきであ る[SHOULD]。TLSはこのようなメカニズムの一例であり、SIPプロキシサー バーはTLSをサポートしなければならない[MUST]ため、選択肢として魅力的 である。ただし、TLSはホップバイホップのメカニズムなので問題をはらん でいる。UACと認証サービスとのチャネル保護については、セクション13.3 を参照。 UACは、リクエストを送信するときに、自身に主張する権利があるIDと対応 する値を、Fromヘッダーフィールドに正しく設定しなければならない [MUST]。リクエストでは、ドメインで使用することが認可されたSIP、SIPS、 またはTEL URI AoRに一致するFromヘッダーのURI部を設定しなければならな い[MUST](RFC 3323 [3]に記載されている匿名URIを含む)。一般的に、UACは FromヘッダーフィールドにTEL URI形式を使用すべきではない[SHOULD NOT] (セクション11を参照)。 本文書は新規の4xx応答コードを定義していることに注意。 ユーザーエージェントはその応答コードをサポートする場合、Identityに基 づくエラー条件に対して適切に応答する機能を持つことになる。 また、UACは、「アウトバウンド」プロキシ(認証サービス)経由で、リクエ スト(通話中のリクエストを含む)を送信することもできなければならな い[MUST]。これを実現する最善の方法は、事前にロードされたRouteヘッ ダーとルースルーティングを使用することである。あるドメインで、認証 サービスの役割をインスタンス化できるエンティティが、ダイアログを構成 Peterson & Jennings Standards Track [Page 12] RFC 4474 SIP Identity August 2006 するリクエストのパスに含まれない場合、反対方向でダイアログ中のリクエ ストのIDは提供することはできない。 署名済みIDを検証できるユーザーエージェントは、リクエストの受信者とし て、適切なユーザーインターフェースをサポートして、ユーザーにIDの有効 性を表示すべきである。ユーザーエージェントの実装では、リクエストの送 信者IDをエンドユーザーに表示する場合、署名済みFromヘッダーフィールド 値と、未署名のFromヘッダーフィールド値とを区別すべきである[SHOULD]。 8. プロキシサーバーの考慮事項 ドメインポリシーによっては、SIPリクエストに設定されたIDの調査と検証 はプロキシサーバーが行う必要がある。プロキシサーバーによっては、スパ ム回避サービスや呼制御サービスを提供するためにメッセージの送信者IDを 確かめることがある。プロキシサーバーが認証サービスとして動作しない場 合でも、リクエストの転送を決定する前に、Identityヘッダーの有効性を確 認してもよい[MAY]。プロキシサーバーは、リクエストに設定済みの IdentityヘッダーやIdentity-Infoヘッダーを削除または変更してはならな い[MUST NOT]。 9. ヘッダー構文 本文書は、IdentityとIdentity- Infoという新規のSIPヘッダーフィールドを 2つ規定する。どちらのヘッダーも、1つのSIPメッセージで1度しか出現し ない。 これら2つのヘッダーの文法は以下のとおり(RFC 3261 [1]のABNF [6]に 従う)。 Identity = "Identity" HCOLON signed-identity-digest signed-identity-digest = LDQUOT 32LHEX RDQUOT Identity-Info = "Identity-Info" HCOLON ident-info *( SEMI ident-info-params ) ident-info = LAQUOT absoluteURI RAQUOT ident-info-params = ident-info-alg / ident-info-extension ident-info-alg = "alg" EQUAL token ident-info-extension = generic-param signed-identity-digestは、SIPリクエストの特定コンポーネントから生成 された標準文字列の署名済みハッシュである。signed-identity-digestのコ ンテンツを作成するには、SIPメッセージの以下の要素をbit-exact文字列で 配置しなければならない[MUST]。このとき順序は指定したとおりにし、区切 り文字にはバーティカルライン「|」または%x7Cを使用する。 o メッセージを送信するUAのAoR、またはFromヘッダーフィールドの addr-spec (本文書ではしばしば「Identityフィールド」と書かれる)。 Peterson & Jennings Standards Track [Page 13] RFC 4474 SIP Identity August 2006 o Toヘッダーフィールド(リクエストの送信先であるAoR)のaddr-specコン ポーネント。 o Call-IDヘッダーフィールドのcallid。 o CSeqヘッダーフィールドの数値(1*DIGIT)部とメソッド(method)部。シン グルスペース(ABNF SPまたは%x20)で区切られる。CSeqヘッダーフィール ドでは、digit部とmethod部を区別するときにSPではなくlinear whitespace (LWS)を許可しているということに注意。そのため、標準化 するにはCSeqヘッダーフィールドの変換が必要な場合もある。認証サー ビスは、ダイジェスト文字列を生成する前に、Cseqの「digit」部から先 頭のゼロを削除しなければならない[MUST]。 o Dateヘッダーフィールド。1つのSPごとに1つのスペースがあり、RFC 3261 のBNFに示されたとおりに設定されたweekday項目とmonth項目を含む。 RFC 3261は、weekdayとmonthのBNFは、トークン群からの選択であると規 定している。BNFのRFC 2234の規則では、トークンは大文字と小文字を区 別すると規定されている。ただし、本文書で定義される標準文字列を構 築するときに使用する場合、各週や各月の1文字目は大文字にしなければ ならない[MUST]。残りの2文字は小文字にしなければならない。これは、 各トークンの定義で提示される大文字指定と一致する。Identityメカニ ズムを使用するすべてのリクエストは、Dateヘッダーを含めなければな らない[MUST]。 o Contactヘッダーフィールド値のaddr-specコンポーネント。リクエスト にContactヘッダーフィールドを含めない場合、このフィールドは空にし なければならない[MUST](つまり、標準文字列の4番目と5番目の「|」文 字の間にホワイトスペースはない)。 o Message(SIPのABNFではmessage-body)にある場合と同じビットを持つ メッセージのボディコンテンツ。これには、マルチパートのメッセージ ボディの全コンテンツが含まれる。message-bodyには、SIPヘッダーと message-bodyとを区別するCRLFを含まない[NOT]ことに注意。ただし、 CRLFの後に続くものはすべて含まれる。メッセージにボディがない場合、 message-bodyは空であり、最後の「|」の後には何も文字は続かない。 これらのヘッダーのセキュリティ特性、これらのヘッダーを含めることでリ プレイ攻撃を軽減できる理由の詳細については、セクション13と[5]を参照。 したがって、このdigest-stringの正確な式は以下のようになる(RFC 3261 [1]のABNF [6]に従う)。 digest-string = addr-spec "|" addr-spec "|" callid "|" 1*DIGIT SP Method "|" SIP-date "|" [ addr-spec ] "|" message-body ここでも、最初のaddr-specをFromヘッダーフィールド値から取得しなけれ ばならないこと[MUST]、2番目のaddr-specをToヘッダーフィールド値から取 得しなければならないこと[MUST]、3番目のaddr-specをContactヘッダー フィールド値から取得しなければならないこと[MUST](Contactヘッダー フィールドがリクエストにある場合)に注意。 Peterson & Jennings Standards Track [Page 14] RFC 4474 SIP Identity August 2006 digest-stringを構築した後は、ドメインの証明書でハッシュおよび署名を 行わなければならない[MUST]。ハッシュと署名のアルゴリズムは、 Identity-Infoヘッダーの「alg」パラメータで指定される(Identity-Info ヘッダーのパラメータについては後述を参照)。本文書は、「alg」パラメー タの値として「rsa-sha1」のみを定義している。その他の値は、標準化過程 のRFCで定義しなければならない[MUST]。詳細についてはセクション14.7を 参照。本仕様を実装する場合、「rsa-sha1」をサポートしなければならな い[MUST]。「rsa-sha1」アルゴリズムがIdentity-Infoの「alg」パラメータ で指定される場合、ハッシュと署名は、「RFC 3370 [7]の記載どおりにこの 文字列をsha1WithRSAEncryptionで署名した結果を算出し、RFC 3548 [8]で 規定されているようにその結果をbase64でエンコードする」という手順で生 成しなければならない[MUST]。1024ビット以上のRSAキーを使用しなければ ならない[MUST]。この結果をIdentityヘッダーフィールドに配置する。この アルゴリズムの詳細な仕様例については、セクション10を参照のこと。 Identity-Infoヘッダーの「absoluteURI」部には、認証サービスの証明書を 含むリソースを逆参照するURIを含めなければならない[MUST]。本仕様のすべ ての実装は、Identity-InfoヘッダーでのHTTP URIとHTTPS URIの使用に対応 しなければならない[MUST]。このようなHTTP URIとHTTPS URIは、RFC 2585 [10]の規約に従わなければならない[MUST]。また、指定されたリソースは、 RFC 2585に記載されている「application/pkix-cert」形式を持たなければ ならない[MUST]。これによって、キーの有効期間の管理問題が持ち込まれる ことに注意。認証サービスが署名したリクエストをベリファイアが評価する 前に、ドメインがIdentity-Info URIで使用できるキーを変更した場合、明 確なベリファイアのエラーが発生する。 ロールオーバーが発生すると、認証サービスは、新しい証明書ごとに新し いIdentity-Info URIを提供すべきであり[SHOULD]、古いキー取得URIは、 SIPメッセージの適切な有効期間よりも長い期間、継続的に使用できるよう にすべきである[SHOULD]。 Identity-Infoヘッダーフィールドには「alg」パラメータを含めなければな らない[MUST]。本文書ではIdentity-Infoヘッダーに他のパラメータは定義 されていない。今後の標準化過程RFCで、追加のIdentity-Infoヘッダーパ ラメータが定義される可能性がある。 Peterson & Jennings Standards Track [Page 15] RFC 4474 SIP Identity August 2006 本文書では、RFC 3261 [1]の表2に以下のエントリを追加する。 Header field where proxy ACK BYE CAN INV OPT REG ------------ ----- ----- --- --- --- --- --- --- Identity R a o o - o o o SUB NOT REF INF UPD PRA --- --- --- --- --- --- o o o o o o Header field where proxy ACK BYE CAN INV OPT REG ------------ ----- ----- --- --- --- --- --- --- Identity-Info R a o o - o o o SUB NOT REF INF UPD PRA --- --- --- --- --- --- o o o o o o 上記の表では、このメカニズムがCANCELメソッドを保護していないというこ とに注意。CANCELメソッドを変更することはできない。なぜならCANCELは ホップバイホップであり、したがってCANCELに対する認証サーバーの動作は 大幅に制限されるためである。また、REGISTERメソッドは、通常とはまった く異なる方法でContactヘッダーフィールドを使用することにも注意。その ため、このメカニズムへの適用は複雑であり、REGISTERと共にIdentityを使 用することは、必然的に今後の研究が必要になる。ただし、将来的な互換性 という理由から、ここではオプションとして残している。Identityヘッダー とIdentity-InfoヘッダーはCANCELに出現してはならない[MUST NOT]。 10. 準拠のテストと例 このセクションの例では、SIPトランザクションのコンテキストでIdentity ヘッダーの用法を説明する。実装する場合、以下の基準に対する仕様への準 拠を検証することが推奨される。 o 認証サービスの役割を実装し、ソースメッセージを使用し、当該ドメイ ンで提供された適切なプライベートキーを利用して設定する場合、これ らの例のIdentityヘッダーに示される内容と同じbase64のID文字列を生 成しなければならない[MUST]。 o ベリファイアの役割を実装する場合、(後述する自分で署名した証明書に 関する停止申請と共に)提供された証明書を利用するときにIdentityヘッ ダーを含むメッセージの有効性を適切に確認しなければならない[MUST]。 Peterson & Jennings Standards Track [Page 16] RFC 4474 SIP Identity August 2006 以下の例では、認可済みの証明機関から発行された証明書ではなく、自分で 署名した証明書を使用していることに注意。このメカニズムでは、自分で署 名した証明書の使用は推奨されない[NOT RECOMMENDED]。ここでは、説明す るために使用している。 したがって、準拠のテストでは、ベリファイアを実装する場合、自分で署名 した証明書の使用について適切な警告を生成すべきである[SHOULD]。また、 このセクションの証明書例は、subjectAltNameフィールドのドメイン名サブ ジェクトを配置した。実際には、証明機関が証明書の別の位置にドメイン名 を配置する可能性がある(詳細についてはセクション13.4を参照)。 このセクションのどの例でも、「rsa-sha1」アルゴリズムを使用しているこ とに注意。 例のメッセージと多様な変換に関するbit-exactの参照ファイルは、付録Bを 参照のこと。 10.1. MIMEボディが単一パートのIdentity-Info 以下のプライベートキーと証明書のペアが、「atlanta.example.com」に割 り当てられているとする(OpenSSL形式で表示)。 -----BEGIN RSA PRIVATE KEY----- MIICXQIBAAKBgQDPPMBtHVoPkXV+Z6jq1LsgfTELVWpy2BVUffJMPH06LL0cJSQO aIeVzIojzWtpauB7IylZKlAjB5f429tRuoUiedCwMLKblWAqZt6eHWpCNZJ7lONc IEwnmh2nAccKk83Lp/VH3tgAS/43DQoX2sndnYh+g8522Pzwg7EGWspzzwIDAQAB AoGBAK0W3tnEFD7AjVQAnJNXDtx59Aa1Vu2JEXe6oi+OrkFysJjbZJwsLmKtrgtt PXOU8t2mZpi0wK4hX4tZhntiwGKkUPC3h9Bjp+GerifP341RMyMO+6fPgjqOzUDw +rPjjMpwD7AkcEcqDgbTrZnWv/QnCSaaF3xkUGfFkLx5OKcRAkEA7UxnsE8XaT30 tP/UUc51gNk2KGKgxQQTHopBcew9yfeCRFhvdL7jpaGatEi5iZwGGQQDVOVHUN1H 0YLpHQjRowJBAN+R2bvA/Nimq464ZgnelEDPqaEAZWaD3kOfhS9+vL7oqES+u5E0 J7kXb7ZkiSVUg9XU/8PxMKx/DAz0dUmOL+UCQH8C9ETUMI2uEbqHbBdVUGNk364C DFcndSxVh+34KqJdjiYSx6VPPv26X9m7S0OydTkSgs3/4ooPxo8HaMqXm80CQB+r xbB3UlpOohcBwFK9mTrlMB6Cs9ql66KgwnlL9ukEhHHYozGatdXeoBCyhUsogdSU 6/aSAFcvWEGtj7/vyJECQQCCS1lKgEXoNQPqONalvYhyyMZRXFLdD4gbwRPK1uXK Ypk3CkfFzOyfjeLcGPxXzq2qzuHzGTDxZ9PAepwX4RSk -----END RSA PRIVATE KEY----- -----BEGIN CERTIFICATE----- MIIC3TCCAkagAwIBAgIBADANBgkqhkiG9w0BAQUFADBZMQswCQYDVQQGEwJVUzEL MAkGA1UECAwCR0ExEDAOBgNVBAcMB0F0bGFudGExDTALBgNVBAoMBElFVEYxHDAa BgNVBAMME2F0bGFudGEuZXhhbXBsZS5jb20wHhcNMDUxMDI0MDYzNjA2WhcNMDYx MDI0MDYzNjA2WjBZMQswCQYDVQQGEwJVUzELMAkGA1UECAwCR0ExEDAOBgNVBAcM B0F0bGFudGExDTALBgNVBAoMBElFVEYxHDAaBgNVBAMME2F0bGFudGEuZXhhbXBs ZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM88wG0dWg+RdX5nqOrU uyB9MQtVanLYFVR98kw8fTosvRwlJA5oh5XMiiPNa2lq4HsjKVkqUCMHl/jb21G6 hSJ50LAwspuVYCpm3p4dakI1knuU41wgTCeaHacBxwqTzcun9Ufe2ABL/jcNChfa yd2diH6DznbY/PCDsQZaynPPAgMBAAGjgbQwgbEwHQYDVR0OBBYEFNmU/MrbVYcE KDr/20WISrG1j1rNMIGBBgNVHSMEejB4gBTZlPzK21WHBCg6/9tFiEqxtY9azaFd pFswWTELMAkGA1UEBhMCVVMxCzAJBgNVBAgMAkdBMRAwDgYDVQQHDAdBdGxhbnRh Peterson & Jennings Standards Track [Page 17] RFC 4474 SIP Identity August 2006 MQ0wCwYDVQQKDARJRVRGMRwwGgYDVQQDDBNhdGxhbnRhLmV4YW1wbGUuY29tggEA MAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADgYEADdQYtswBDmTSTq0mt211 7alm/XGFrb2zdbU0vorxRdOZ04qMyrIpXG1LEmnEOgcocyrXRBvq5p6WbZAcEQk0 DsE3Ve0Nc8x9nmvljW7GsMGFCnCuo4ODTf/1lGdVr9DeCzcj10YUQ3MRemDMXhY2 CtDisLWl7SXOORcZAi1oU9w= -----END CERTIFICATE----- atlanta.example.comのユーザーであるAliceは、INVITEを bob@biloxi.example.orgに送信したい。したがって、Aliceは以下のINVITE リクエストを作成する。Aliceは、認証サービスの役割をインスタンス化す るatlanta.example.orgプロキシサーバーに転送する。 INVITE sip:bob@biloxi.example.org SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 To: Bob From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Max-Forwards: 70 Date: Thu, 21 Feb 2002 13:02:03 GMT Contact: Content-Type: application/sdp Content-Length: 147 v=0 o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com s=Session SDP c=IN IP4 pc33.atlanta.example.com t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 認証サービスはINVITEを受信すると、407応答を送信することでAliceを認証 する。結果として、AliceはAuthorizationヘッダーフィールドを自分のリク エストに追加し、atlanta.example.com認証サービスへ再送する。これで サービスはAliceのIDに確認でき、リクエストのIdentityヘッダーを算出す る。IDの署名を生成した標準文字列を以下に示す(RFCの編集規約に従ってて いるため、1行目が改行されていることに注意)。 sip:alice@atlanta.example.com|sip:bob@biloxi.example.org| a84b4c76e66710|314159 INVITE|Thu, 21 Feb 2002 13:02:03 GMT| sip:alice@pc33.atlanta.example.com|v=0 o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com s=Session SDP c=IN IP4 pc33.atlanta.example.com t=0 0 Peterson & Jennings Standards Track [Page 18] RFC 4474 SIP Identity August 2006 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 前述したプライベートのRSAキーを使用する結果の署名 (sha1WithRsaEncryption)は、base64でエンコードされ、以下のようになる。 ZYNBbHC00VMZr2kZt6VmCvPonWJMGvQTBDqghoWeLxJfzB2a1pxAr3VgrB0SsSAa ifsRdiOPoQZYOy2wrVghuhcsMbHWUSFxI6p6q5TOQXHMmz6uEo3svJsSH49thyGn FVcnyaZ++yRlBYYQTLqWzJ+KVhPKbfU/pryhVn9Yc6U= したがって、atlanta.example.com認証サービスは、このbase64署名文字 列(175バイト)を含むIdentityヘッダーを作成する。また、証明書が利用で きるようになるHTTPS URLも追加する。これら2つのヘッダーが追加され、 メッセージは以下のようになる。 INVITE sip:bob@biloxi.example.org SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 To: Bob From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Max-Forwards: 70 Date: Thu, 21 Feb 2002 13:02:03 GMT Contact: Identity: "ZYNBbHC00VMZr2kZt6VmCvPonWJMGvQTBDqghoWeLxJfzB2a1pxAr3VgrB0SsSAa ifsRdiOPoQZYOy2wrVghuhcsMbHWUSFxI6p6q5TOQXHMmz6uEo3svJsSH49thyGn FVcnyaZ++yRlBYYQTLqWzJ+KVhPKbfU/pryhVn9Yc6U=" Identity-Info: ;alg=rsa-sha1 Content-Type: application/sdp Content-Length: 147 v=0 o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com s=Session SDP c=IN IP4 pc33.atlanta.example.com t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 次に、atlanta.example.comはリクエストを通常どおりに転送する。Bobがリ クエストを受信したときに、まだatlanta.example.comの証明書を認知して いない場合、Identity-InfoヘッダーのURIを逆参照して証明書を取得する。 次に、Bobは、SIPリクエストの同じヘッダーから、上記と同じ標準文字列を 生成する。Bobは、この標準文字列(Identityヘッダーの署名済みダイジェ スト)と、Identity-Infoヘッダーを逆参照して検出された証明書を使用し Peterson & Jennings Standards Track [Page 19] RFC 4474 SIP Identity August 2006 て、ヘッダーとメッセージボディのセットが変更されていないことを検証す ることができる。 10.2. MIMEボディまたはContactがないリクエストのIdentity 以下のプライベートキーと証明書のペアが、「biloxi.example.org」に割り 当てられているとする。 -----BEGIN RSA PRIVATE KEY----- MIICXgIBAAKBgQC/obBYLRMPjskrAqWOiGPAUxI3/m2ti7ix4caqCTAuFX5cLegQ 7nmquLOHfIhxVIqT2f06UA0lOo2NVofK9G7MTkVbVNiyAlLYUDEj7XWLDICf3ZHL 6Fr/+CF7wrQ9r4kv7XiJKxodVCCd/DhCT9Gp+VDoe8HymqOW/KsneriyIwIDAQAB AoGBAJ7fsFIKXKkjWgj8ksGOthS3Sn19xPSCyEdBxfEm2Pj7/Nzzeli/PcOaic0k JALBcnqN2fHEeIGK/9xUBxTufgQYVJqvyHERs6rXX/iT4Ynm9t1905EiQ9ZpHsrI /AMMUYA1QrGgAIHvZLVLzq+9KLDEZ+HQbuCLJXF+6bl0Eb5BAkEA636oMANp0Qa3 mYWEQ2utmGsYxkXSfyBb18TCOwCty0ndBR24zyOJF2NbZS98Lz+Ga25hfIGw/JHK nD9bOE88UwJBANBRSpd4bmS+m48R/13tRESAtHqydNinX0kS/RhwHr7mkHTU3k/M FxQtx34I3GKzaZxMn0A66KS9v/SHdnF+ePECQQCGe7QshyZ8uitLPtZDclCWhEKH qAQHmUEZvUF2VHLrbukLLOgHUrHNa24cILv4d3yaCVUetymNcuyTwhKj24wFAkAO z/jx1EplN3hwL+NsllZoWI58uvu7/Aq2c3czqaVGBbb317sHCYgKk0bAG3kwO3mi 93/LXWT1cdiYVpmBcHDBAkEAmpgkFj+xZu5gWASY5ujv+FCMP0WwaH5hTnXu+tKe PJ3d2IJZKxGnl6itKRN7GeRh9PSK0kZSqGFeVrvsJ4Nopg== -----END RSA PRIVATE KEY----- -----BEGIN CERTIFICATE----- MIIC1jCCAj+gAwIBAgIBADANBgkqhkiG9w0BAQUFADBXMQswCQYDVQQGEwJVUzEL MAkGA1UECAwCTVMxDzANBgNVBAcMBkJpbG94aTENMAsGA1UECgwESUVURjEbMBkG A1UEAwwSYmlsb3hpLmV4YW1wbGUuY29tMB4XDTA1MTAyNDA2NDAyNloXDTA2MTAy NDA2NDAyNlowVzELMAkGA1UEBhMCVVMxCzAJBgNVBAgMAk1TMQ8wDQYDVQQHDAZC aWxveGkxDTALBgNVBAoMBElFVEYxGzAZBgNVBAMMEmJpbG94aS5leGFtcGxlLmNv bTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAv6GwWC0TD47JKwKljohjwFMS N/5trYu4seHGqgkwLhV+XC3oEO55qrizh3yIcVSKk9n9OlANJTqNjVaHyvRuzE5F W1TYsgJS2FAxI+11iwyAn92Ry+ha//ghe8K0Pa+JL+14iSsaHVQgnfw4Qk/RqflQ 6HvB8pqjlvyrJ3q4siMCAwEAAaOBsTCBrjAdBgNVHQ4EFgQU0Z+RL47W/APDtc5B fSoQXuEFE/wwfwYDVR0jBHgwdoAU0Z+RL47W/APDtc5BfSoQXuEFE/yhW6RZMFcx CzAJBgNVBAYTAlVTMQswCQYDVQQIDAJNUzEPMA0GA1UEBwwGQmlsb3hpMQ0wCwYD VQQKDARJRVRGMRswGQYDVQQDDBJiaWxveGkuZXhhbXBsZS5jb22CAQAwDAYDVR0T BAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQBiyKHIt8TXfGNfpnJXi5jCizOxmY8Y gln8tyPFaeyq95TGcvTCWzdoBLVpBD+fpRWrX/II5sE6VHbbAPjjVmKbZwzQAtpp P2Fauj28t94ZeDHN2vqzjfnHjCO24kG3Juf2T80ilp9YHcDwxjUFrt86UnlC+yid yaTeusW5Gu7v1g== -----END CERTIFICATE----- ここでは、前のセクションで示した例のダイアログの終了時で、Bob (bob@biloxi.example.org)はAliceにBYEリクエストを送信しようとしてい る。したがって、Bobは以下のBYEリクエストを作成する。Bobは、認証サー ビスの役割をインスタンス化するbiloxi.example.orgプロキシサーバーに転 送する。 Peterson & Jennings Standards Track [Page 20] RFC 4474 SIP Identity August 2006 BYE sip:alice@pc33.atlanta.example.com SIP/2.0 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnashds10 Max-Forwards: 70 From: Bob ;tag=a6c85cf To: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 231 BYE Content-Length: 0 認証サービスは、BYEを受信すると、407応答を送信することでBobを認証す る。結果として、BobはAuthorizationヘッダーフィールドを自分のリクエス トに追加し、biloxi.example.org認証サービスを再送する。これでサービス はBobのIDに確認でき、リクエストのIdentityヘッダーを算出するために準 備する。このリクエストにはDateヘッダーフィールドがないことに注意。し たがって、biloxi.example.orgは、IDの署名を算出する前に、Dateヘッダー をリクエストに追加する。Content-Lengthヘッダーが存在しない場合にも、 認証サービスは追加する。そのため、基本のメッセージは以下のようにな る。 BYE sip:alice@pc33.atlanta.example.com SIP/2.0 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnashds10 Max-Forwards: 70 From: Bob ;tag=a6c85cf To: Alice ;tag=1928301774 Date: Thu, 21 Feb 2002 14:19:51 GMT Call-ID: a84b4c76e66710 CSeq: 231 BYE Content-Length: 0 また、このリクエストにContactヘッダーフィールドは含まれないというこ とにも注意。 したがって、biloxi.example.orgはコンタクトアドレスのaddr-specの標準 文字列に何も値を配置しない。また、メッセージボディがないことにも注 意。そのため、この例の署名文字列は2本のバーチカルラインで終了する。 IDの署名を生成した標準文字列を以下に示す(RFCの編集規約に従ってている ため、1行目が改行されていることに注意)。 sip:bob@biloxi.example.org|sip:alice@atlanta.example.com| a84b4c76e66710|231 BYE|Thu, 21 Feb 2002 14:19:51 GMT|| biloxi.example.orgについて前述したプライベートのRSAキーを使用する結 果の署名(sha1WithRsaEncryption)は、base64でエンコードされ、以下のよ うになる。 Peterson & Jennings Standards Track [Page 21] RFC 4474 SIP Identity August 2006 sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9dlxkWzo eU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgtw0Lu5csIp pPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs= したがって、biloxi.example.org認証サービスは、このbase64署名文字列を 含むIdentityヘッダーを作成する。 また、証明書が利用できるようになるHTTPS URLも追加する。これら2つの ヘッダーが追加され、メッセージは以下のようになる。 BYE sip:alice@pc33.atlanta.example.com SIP/2.0 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnashds10 Max-Forwards: 70 From: Bob ;tag=a6c85cf To: Alice ;tag=1928301774 Date: Thu, 21 Feb 2002 14:19:51 GMT Call-ID: a84b4c76e66710 CSeq: 231 BYE Identity: "sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9dlxkWzo eU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgtw0Lu5csIp pPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs=" Identity-Info: ;alg=rsa-sha1 Content-Length: 0 次に、biloxi.example.orgは通常どおりにリクエストを転送する。 11. IdentityとTEL URIのスキーム 多くのSIPアプリケーションにはVoice over IP (VoIP)サービスを提供して いるため、通常、電話番号がSIP配備のIDとして使用される。 多くの場合、このことは本文書に記載されているIDメカニズムにとって問題 にはならない。電話番号は、通常、SIP URIのユーザー名部に出現する(例: 「sip:+17005551008@chicago.example.com;user=phone」)。このユーザー 名は、TEL URIスキーム(RFC 3966 [13])の構文に準拠する。このような種類 のSIP Addresses-of-Recordの場合、chicago.example.comは適切な署名 者(signatory)である。 SIPまたはSIPS URIのコンテキスト外で、SIPのToまたはFromヘッダーフィー ルドにTEL URIが出現する可能性もある(例: 「tel:+17005551008」)。この 場合、適切なIDの署名者がわかりづらくなる。IDメカニズムに幸運なこと に、この形式のTEL URIは、FromヘッダーフィールドよりもSIPのToヘッダー フィールドおよびRequest-URIに、より一般的である。というのも、UACは、 リクエストの送信先であるリモートドメインがわからない場合に、TEL URI のみを提供する以外にオプションがないためである。ただし、ローカルドメ インは、通常、UACからは知られていない。したがって、TEL URI形式のユー Peterson & Jennings Standards Track [Page 22] RFC 4474 SIP Identity August 2006 ザー名を含むSIP URIを含めることで、適切なFromヘッダーフィールドを構 築することができる。実装で認証サービス経由でリクエストを送信する場 合、可能であれば必ずSIPまたはSIPS URIにFromヘッダーフィールドの電話 番号を指定すべきである[SHOULD]。 ローカルドメインがリクエストを構築するUACに知られていない場合、リク エストの認証サービスの位置を特定できる可能性はほとんどない。したがっ て、このような場合にIDを提供するという問題は、現実的ではない。ただ し、認証サービスはFromヘッダーフィールドにTEL URIを含むリクエストに 署名してもよい[MAY]。本仕様でこの方法は、今後の互換性の目的に限定し て許可されている。長期の観点では、ENUM [14]が電話番号に責任を持つ管 理ドメインを決定する手法になる可能性はある。また、電話番号を含むSIP IDの署名と検証にも役に立つ可能性もある。ENUMについては今後の研究の対 象である。 12. プライバシの考慮事項 本文書のIDメカニズムは、RFC 3323 [3]に記載されているプライバシに関す る標準的なSIP実践方法と互換性がある。SIPプロキシサーバーは、プライバ シサービスと認証サービスのどちらとしても機能する。ユーザーエージェン トは、認証サービスの認可処理を受けるFromヘッダーフィールド値を提供す ることができるため、認証サービスが正規のドメイン (sip:anonymous@example.comなど)を含むプライベートなSIP URIに署名でき ない理由はない。Identityヘッダーの構築は、プライベートURIとその他の URIとでは同様である。 ただし、認証サービスは、署名するリクエストのFromヘッダーフィールドで addr-specのホスト部に相当する証明書を所有する必要がある、ということ に注意。したがって、「anonymous.invalid」のようなドメインを使用する ことは、認証サービスとしても機能するプライバシサービスでは不可能であ る。有効なドメイン部がある匿名URIを使用することで、「これは、自分の ドメインで認証した既知のユーザーだが、このユーザーのIDは秘密にする」 ということが保証される。ドメイン「anonymous.invalid」を使用すると、 ドメインに対応する証明機関は存在しなくなる。結果的に、認証サービス機 能は意味がなくなる。 RFC 3323に記載されたプライバシの「ヘッダー」レベルによって、プライバ シサービスはSIPメッセージのContactヘッダーフィールドを変更することが 要求される。ContactヘッダーフィールドはIdentityヘッダーの署名で保護 されるため、結果の完全性に違反が発生することなく、認証サービスの後に プライバシサービスを適用することはできない。 Peterson & Jennings Standards Track [Page 23] RFC 4474 SIP Identity August 2006 RFC 3325 [12]は、P-Asserted-Identityヘッダーに固有の「id」priv-value 値トークンを定義している。P-Asserted-Identityヘッダーが提供する アサーションの種類は、本文書のIdentityヘッダーとは非常に異なる。 P-Asserted-Identityの場合、Fromヘッダーフィールドに出現する情報以外 に、メッセージの送信者に関する追加情報を含む。P-Asserted-Identityは、 閉じたネットワークの仲介エンティティであれば何らかの方法で知る、信頼 である送信者IDを保持する。このIDは、おそらくネットワークが課金やセ キュリティの目的で使用するものである。このようなネットワーク固有の情 報は、閉じたネットワークの外部に漏れる危険性があるため、「id」 priv-valueトークンが考えられた。「id」priv-valueトークンには、 Identityヘッダーに関する暗黙の事項はないため、プライバシサービスは、 「id」のpriv-valueがPrivacyヘッダーに出現したときに、Identityヘッダー を削除してはならない[MUST NOT]。 最後に、RFC 3325とは異なり、本仕様に記載されているメカニズムは、プラ イバシの暗黙事項があるSIPリクエストに何も情報を追加しない。 13. セキュリティの考慮事項 13.1. digest-string要素の操作 本文書は、Contact、Date、Caller-ID、CSeq、To、FromというSIPリクエスト のヘッダーフィールドに署名するメカニズムについて説明している。URI単 体を保護するにはFromヘッダーフィールドへの署名で十分だが、他のヘッ ダーにも署名することで、リプレイの保護と参照の完全性が実現する。こ れは、Identityヘッダーをカットアンドペースト攻撃に使用されないように するために必要である。一般的に、このようなヘッダーのセキュリティに関 する考慮事項は、トンネルされる「message/sip」MIMEボディにヘッダーを 含める場合にRFC 3261(特にセクション23を参照)で指定されている事項と同 じである。 以下のセクションでは、署名内に各ヘッダーフィールドを含めることで得ら れるセキュリティ特性について、詳細に説明する。このヘッダーフィールド 群全体で、なりすましを防ぐために必要な特性が実現する。 Fromヘッダーフィールドは、メッセージの送信側IDを示す。また、From ヘッダーフィールドのSIP Addresses-of-Record URIは、本文書の目的で は、SIPユーザーのIDである。 Toヘッダーフィールドは、このリクエストが対象とするSIPユーザーのIDを 提供する。Identityの署名にToヘッダーフィールドを指定することには、2つ の目的がある。第1に、カットアンドペースト攻撃を防ぐ。カットアンドペー ストは、あるユーザーに関する正規のリクエストに含まれるIdentityヘッ ダーが、異なるユーザーのリクエストにカットアンドペーストされる攻撃で ある。第2に、リクエストの開始URIスキームを保持する。これによって、 SIPSの使用に対するダウングレード攻撃を防ぐことができる。 Peterson & Jennings Standards Track [Page 24] RFC 4474 SIP Identity August 2006 DateとContactヘッダーは、参照の整合性およびリプレイ攻撃に対する保護 を実現する(RFC 3261のセクション23.4.2を参照)。 本仕様の実装では、期限切れのDateヘッダーフィールドを含むリクエストを 有効と見なしてはならない[MUST NOT](推奨される[RECOMMENDED]間隔は、 Dateヘッダーがメッセージ受信の3600秒以内の時間を示すことである)。実装 では、Identityヘッダーを含む有効なリクエストで受信したCall-IDも記録 しなければならない[MUST]。また、少なくとも単一のDate間隔の有効期間 は、そのCall-IDを記憶しなければならない[MUST]。SIP準拠のUAは、同じ Call-IDを複数生成してはならないため、ベリファイアは、Caller-IDを使用 してカットアンドペースト攻撃を認識することができる。Call-IDは臨時機 能として働く。 この結果、IdentityヘッダーがDate間隔の間にリプレイされた場合、ベリ ファイアは、Call-IDの重複によって無効であることを認識する。Identity ヘッダーがDate間隔を過ぎてからリプレイされた場合、ベリファイアは、 Dateが古いため無効であると認識する。CSeqヘッダーフィールドには、トラ ンザクションの番号付き識別子と、リクエストのメソッド名を含む。この情 報がない場合、INVITEリクエストが不正ユーザーにカットアンドペーストさ れる可能性がある。また、Identityヘッダーがカバーするフィールドを変更 することなく、BYEリクエストに変換される可能性がある。さらに、あるト ランザクション内のリクエストは、混乱を引き起こす方法や不正な方法でリ プレイされる可能性がある。 リクエストを生成した特定のユーザーエージェントインスタンスにIdentity ヘッダーを結び付けるには、Contactヘッダーフィールドを含める。不正 ユーザーが積極的であれば、Identityヘッダーを含むリクエストを傍受し、 Identityヘッダーを(元のメッセージに含まれるFrom、Contact、Date、 Call-IDフィールドを再利用して)自分のリクエストにカットアンドペースト する可能性がある。この場合、Contactヘッダーフィールドで識別されたURI にリクエストはルーティングされるため、攻撃者に着呼側ユーザーエージェ ントからSIPリクエストを受信する資格はない。 ただし、Contactヘッダーフィールドはダイアログを構成するリクエストに しか含まれないため、どの場合でもこのような保護が実現する訳ではない。 Viaヘッダーフィールド値で提示される情報の一部に署名することは魅力的 な場合もある。たとえば、一番上のViaヘッダーのsent-byフィールドに署名 がない場合、不正ユーザーがそのViaヘッダーを削除し、カットアンドペー スト攻撃で独自のViaを層に遊する可能性がある。結果として、そのリクエ ストの応答は、不正ユーザーが選択したホストにルートされる。ただし、一 番上のViaヘッダーに署名しても、このような性質の不正ユーザーを防ぐこ とにはならない。なぜなら、不正ユーザーは一番上のViaには手を付けず、 その直後に新しいViaヘッダーフィールドを挿入するだけの場合があるため である。この場合、有効なホストまでの「途中にある」不正ユーザーのホス トに応答がルーティングされることになる。この場合も、最終的な結果は まったく同じである。 仲介エンティティベースの認証サービスで、送信側ユーザーエージェントと 認証サービス間でViaのホップは挿入されていないことを保証することはで Peterson & Jennings Standards Track [Page 25] RFC 4474 SIP Identity August 2006 きるが、不正ユーザーが認証サービスの後にViaホップを追加することは防 ぐことができない。したがって、応答の横取りも防ぐことはできない。SIP の適切な操作として、仲介エンティティが、このようなViaヘッダーフィー ルドを挿入する機能を持つ必要がある。したがって、この問題は回避でき ない。 以上のように、Viaの保護は望ましいことではあるが、本文書で説明してい るようなIDメカニズムでは、Viaを保護できない。Viaの保護方法として現在 最善の方法は、SIPSを利用することである。 このメカニズムは、SIPリクエストのボディへの署名も実現している。ボディ に署名する最も重要な理由は、SIPリクエストで伝達されるセッション記述 プロトコル(Session Description Protocol/SDP)ボディを保護することで ある。 この保証が、メディア記述子に同程度の保証と組み合わされない場合、SIP リクエストを開始したユーザーのIDを確立するという目的はほとんどない。 ただし、これは完璧なエンドツーエンドのセキュリティではないということ に注意。仲介エンティティでインスタンス化された場合、認証サービス自 体が、署名する前にSDP(ついでにSIPヘッダーも)を変更する可能性がある。 そのため、このメカニズムによって、リプレイ実行者や介入者 (man-in-the-middle)がSDPを変更する可能性は少なくなるが、完全に可能性 がなくなるわけではない。このメカニズムの根本的な想定は、セキュリティ を保証するためにユーザーが自分のローカルドメインを信頼するということ なので、適切が理由がないのにメッセージの完全性を損なわないよう、サー ビスも信頼する必要がある。RFC 3261のセクション16.6では、SIPプロキシ サーバーは「メッセージボディに対して追加、変更、または削除を行っては ならない[MUST NOT]」と記載していることに注意。 最終的に分析すると、IdentityヘッダーとIdentity-Infoヘッダーは自身を 保護することはできない。不正ユーザーはSIPリクエストからこれらのヘッ ダーを削除し、後で任意にリクエストを変更することができる。ただし、こ のメカニズムには、SIPメッセージを妨害する介入者からリクエストを保護 する目的はない。このメカニズムの目的は、SIPユーザーが、自分が主張し ているIDの本人であることを明確に証明できる方法を提供することのみで ある。介入者は、リクエストからID情報を削除するだけでも、介入者が送信 する不正メッセージと、認証済みユーザーから送信されるメッセージとの区 別を不可能にすることができる。ただし、このような攻撃をしかけるには、 多大な労力が必要になる。単に第三者のFromヘッダーフィールドをコピーす る簡単ななりすまし攻撃よりも困難である。このメカニズムは、認証済み ユーザーが、自身のIDを明確に保証する(未認証ユーザーであるなりすまし の実行者には不可能な)方法を提供する。 Identity-Infoヘッダーが自身を保護できないもう1つの点は、「alg」パラ メータである。「alg」パラメータはdigest-stringに含まれないため、介入 者に「alg」パラメータを変更される可能性がある。ただし、介入者を防ぐ ことはこのメカニズムの主要な目的ではない点に注意が必要である。さら に、「alg」の変更は、最悪でも何らかのビットダウン攻撃[訳注: セキュリ Peterson & Jennings Standards Track [Page 26] RFC 4474 SIP Identity August 2006 ティレベルを低くする攻撃]を引き起こす程度で、軽ければベリファイアの エラーになるだけである。本文書では有効なパラメータは「alg」しか定義 されていないため、現在のところ、メカニズムをビッドダウンするような弱 いアルゴリズムは存在しない。 今後、現在のアルゴリズムに弱点があることがわかり、迅速に置き換えが必 要になった場合に備え、「alg」は将来的な互換性のためにこのメカニズム に組み込まれた。 13.2. 表示名とIdentity インターフェース設計の問題として、SIPユーザーエージェントは発呼側の Fromヘッダーフィールドの表示名部分を、発呼側のIDとして表示することが ある。この実行方法として、電子メールのユーザーインターフェースに重要 な前例がある。したがって、表示名に署名がないことは、重大な省略である ように考えられる。 ただし、表示名への署名によってなりすましを防ぐことはできないというこ とに、重要な意味もいくつかある。まず、「Jon Peterson」のように特定の 表示名は、世界で1つの名前ではない。さまざまな管理ドメインに多くのユー ザーが正規にその名前を主張する可能性がある。さらに、SIPベースのサー ビスへ加入する例では、ユーザーの正規の表示名を識別することは困難な場 合もある。なりすましの実行者が任意の表示名でSIPアカウントを作成する ことができる、と想定する方が安全である。同じ状況が現在の電子メールで も広く発生している。なりすましの実行者が、Fromヘッダーフィールドの表 示名のみを変更することでIdentityヘッダーを含むメッセージをリプレイし ようとした場合、セクション13.1に記載されている他のリプレイ保護メカニ ズムによって検出される、ということに注意。 当然ながら、表示名が署名されていない場合でも、認証サービスは表示名に ポリシーを課すことができる。このようなポリシーを作成および構築する正 確な手法は、本文書の範囲外である。このポリシーの機能は、SIP URIなど、 一意な識別子のなりすましを防ぐことではなく(なぜなら、表示名は一意な 識別子ではないためである)、ユーザーの主張をドメインが管理できるよう にすることである。このようなポリシーが課される場合、ユーザーは任意に 表示名を主張できなくなる。署名がない場合、不正な介入者は、おそらく簡 単にリクエストの表示名を変更することができる。 この仕様の範囲はなりすまし攻撃だが、介入者でもメッセージからIdentity ヘッダーやIdentity-Infoヘッダーを削除することができる、ということに 注意。 表示名に関するポリシーが適していない環境も数多くある。加入処理や登録 処理の一環として、bit-exactで国際化可能な表示名をエンドユーザーに配 布するには、本文書に記載されていないメカニズムが必要になる。ドメイン Peterson & Jennings Standards Track [Page 27] RFC 4474 SIP Identity August 2006 名に関してポリシーが課されていない場合、おそらく、ユーザーインター フェースで表示名に依存する部分が大きいSIPシステムに対して、攻撃がし かけられる可能性がある。ただし、これは適切なインターフェース設計の問 題であって、メカニズムを変更する問題ではない。IDについて固有ではない 識別子に依存すると、結果的にメカニズムが弱くなる。 13.3. 認証サービスに対する接続の保護 このメカニズムで実現する保証は、ユーザーエージェントが、仲介エンティ ティベースの認証サービスに対して、直接的な接続(できればTLSで保護され た接続)を構築する場合に最も強力になる。この理由は2つの要素からなる。 ユーザーが、予定しているドメインに対応するTLS接続上で認証サービス から証明書を受信しない場合(特に、ダイジェストなどのメカニズム経由 でチャレンジを受信する場合)、不正なサーバーが、制御していないドメ インの認証サービスとして、(ドメインの共有秘密を収集するときなど に)停止しようとする可能性がある。 TLSがない場合、多様なヘッダーフィールド値とリクエストのボディは、 リクエストに完全性が保護されずに認証サービスに到達することになる。 したがって、先にある仲介エンティティが正規でも不正なものでも、メッ セージを任意に変更することができる。 このような問題が2つあるが、1つ目は、このメカニズムが対象としている範 囲に最も重要な問題である。このメカニズムは、介入者攻撃ではなく、なり すまし攻撃を防ぐことが目的である。このメカニズムが提供するヘッダーと ボディの完全性は、リプレイ攻撃を防ぐためでしかない。ただし、Identity ヘッダーの提示に依存するアプリケーションは、この完全性保護(特にボディ の完全性)をリプレイ保護以外のサービスに活用することもできる。 したがって、直接的なTLS接続は、可能なかぎり、UACと認証サービス間に使 用すべきである[SHOULD]。ただし、機会があれば使用するというこのメカニ ズムの性質があるため、UACの動作を制約するのは非常に困難である。さら に、直接接続が単に実行できず、UACが認証サービスとして動作できない配 置アーキテクチャも一部にはある。したがって、直接接続とTLSが可能では ない場合、UACはSIPSメカニズム、ダイジェストの「auth-int」、可能な場 合はその両方をボディの完全性保護に使用すべきである。Identityヘッダー Peterson & Jennings Standards Track [Page 28] RFC 4474 SIP Identity August 2006 をリクエストに追加する最終的な判断は、当然ながら、認証サービスに委ね られる。ドメインポリシーは、認証サービスと関連付けられたUACのセキュ リティが弱すぎる条件を特定する必要がある。 13.4. ドメイン名と従属関係 ベリファイアは、Identity-Infoヘッダーを含むリクエストを処理するとき に、リクエストのFromヘッダーにあるURIのドメイン部と、Identity-Info ヘッダーから取得された識別子のサブジェクトであるドメイン名とを比較す る必要がある。これは単純な処理のように見えるが、実際の配置方法に2つ の問題があるため、複雑になっている。まず、証明書のサブジェクトは記述 方法がさまざまであり、複数のサブジェクトが存在する場合もある。特に、 複数ドメインが単一のアプリケーションに管理されている「仮想ホスティ ング」の場合はそうである。 第2に、一部のSIPサービスは、SIP機能を従属ドメイン(subordinate domain) に委任し、RFC 3263 [4]の手順を利用している。この場合、たとえば 「example.com」に対するリクエストが「sip.example.com」にルートされる 可能性がある。結果として、「sip:jon@example.com」というAoRのユー ザーは、リクエストを「sip.example.com」などのホスト経由で処理する可 能性もあるし、後者のホストが認証サービスとして動作する可能性もある。 上記の第2の問題に対応するには、従属ホストで認証サービスを展開するド メインは、そのホストに、証明書と関連付けられるプライベートキー作成の 素材を提供しなければならない[MUST]。この場合の証明書のサブジェクト は、ドメインがユーザーに配布するAoRのドメイン部に相当するドメイン名 である。 これは、インバウンドのSIPリクエストをドメインにルーティングする方法 と同等のケースに相当する、ということに注意。RFC 3263のNAPTRとSRVの手 順が、元のRequest-URIのドメインとは異なるドメイン名に直接リクエスト するときに使用される場合(たとえば、「sip:jon@example.com」の場合、対 応するSRVレポートはサービス「sip1.example.org」を指す場合)、そのホス トとのTLS交換で返される証明書は、ホストのドメイン名ではなく、元の Request-URIのドメインと一致する、とクライアントは期待する。結果と して、このようなSIPサービスへのインバウンドルーティングが機能する には、ドメイン管理者も同様に、ドメインのプライベートキーをサービスと 共有する意思を持つ必要がある。このような設計上の判断は、DNSの不安定 さを相殺するために下された。また、ドメイン管理者がキーをホスティン グサービスと共有したくない環境のSIPでは安全ではない、DNSベースの「仮 想ホスティング」に対処するための一手法でもある。 ベリファイアは、RFC 2818 [11]セクション3.1で定義された手順に従って、 ユーザーのIDと証明書の署名との関連性を評価しなければならない[MUST]。 RFC 2818は、TLSにおけるHTTPの使用を扱っているが、記載されている手 Peterson & Jennings Standards Track [Page 29] RFC 4474 SIP Identity August 2006 順は、Identityヘッダーを使用したSIPリクエストのFromヘッダーにある ユーザーIDのドメイン部で、HTTPの「サーバーのホスト名」が置き換えられ たかどうかを検証するときにも適用できる。 認証サービスが使用できるドメインの証明書は、認証サービスのホスト名の みをアサートする必要があるため、既存の証明機関は、このメカニズムに適 切な証明書を提供することができる。ただし、プロキシサーバーやユーザー エージェントのすべてが、全証明機関のルート証明書をサポートできるわけ ではない。さらに、証明機関が証明書を発行するポリシーには大きな違いが ある。本文書は、特定の証明機関を使用することは推奨しない。また、証明 機関が従うべきポリシーも規定しない。ただし、運用上の経験から、認証 サービスのデファクトスタンダードが作成されることを期待する。たとえ ば、サービスプロバイダの連盟などが、その連盟が運用している証明機関か ら提供された証明書のみを信頼するという場合が考えられる。ベリファイ アは、以前のキー交換で正当と認められていなければ、自分で署名したドメ イン証明書を信頼すべきではない、ということが強く推奨され る[RECOMMENDED]。 証明書のセキュリティと実行方法の詳細については、RFC 3280 [9]を参照。 RFC 3280の「Security Considerations(セキュリティの考慮事項)」は、本 文書に適用できる。 13.5. 認可と推移の戦略 最終的に、Identityヘッダーで実現する保証の価値は、保証を発行するドメ インのセキュリティ保護方法によって制限される。リモートの管理ドメイン が生成するIdentityヘッダーへ依存するということは、発行側ドメインが、 ユーザーの認証時に、その管理方法を使用したという想定である。ただし、 一部のドメインは、実質的にユーザーに責任を持たないポリシーを実装する 場合がある(たとえば、任意のユーザーから未認証の登録を受け入れるポ リシーなど)。このようなドメインからのIdentityヘッダー値には、問題が ある。SIPリクエストを調べることで「良い」ドメインと「悪い」ドメイン をベリファイアが区別できる奇跡の方法はないが、将来的に、このID ソリューションをうまく処理する認可方法の研究が確立する可能性がある。 このようなIDソリューションがなければ、認可ポリシーに期待されている多 くの手法は、不可能である。とは言うものの、プロキシサーバーに基づく認 証サービスは、トークンベースの識別子など、強力な認証方法を採用するこ とが推奨される[RECOMMENDED]。 すべてのSIPエンティティが一夜でIdentityヘッダーとIdentity-Infoヘッ ダーをサポートするなどということは期待できない。そのため、ベリファイ アは危うい立場にある。あるSIPユーザーからのリクエストをベリファイア Peterson & Jennings Standards Track [Page 30] RFC 4474 SIP Identity August 2006 が受信したときに、送信者のドメインがIdentityをサポートしているかどう かをどのように知ることができるだろうか。IDがどこででもサポートされて いる状況でなければ、何らかの推移的戦略が必要である。 ベリファイアは、Identityを使用するドメインからリクエストを受信し たときにそれを記憶しておき、将来的に、Identityヘッダーに疑念を抱 くことなく、そのドメインから受信したメッセージを表示することがで きる。 ベリファイアは、何らかのコールバックシステムによってドメインに照 会することで、そのドメインが認証サービスを実行しているかどうかを 判断することができる。これを実装する方法は、多数考えられる。たと えば、SIP OPTIONSメソッドを使用する方法がある。 これは今後の研究対象である。 長期の観点では、何らかのIDメカニズム(本仕様に記載されているもの、ま たは本文書の後継)が、SIPプロトコルで使用が必須になる。ベリファイアが 常にこの保護を期待できるということを保証するには、これが唯一の方法で ある。 最後に、Identityヘッダーの存在または欠如が、認可の判断において唯一の 要因になるということはありえない、という点に注目が必要である。特定の 検証済みIdentityに基づいて、またはSIPリクエストの他の側面に基づいて メッセージに対する許可が付与される可能性がある。認可ポリシーは、本仕 様の範囲外であるが、今後の認可研究では、有効なIdentityヘッダーを含む メッセージが常に正しいと想定しないことが推奨される。 14. IANA条項 本文書は、SIPパラメータのIANAレジストリにあるヘッダーと応答コードの サブレジストリを変更することを要求する。また、Identity-Infoヘッダー のパラメータとして、新しいレジストリを2つ作成することを要求する。 14.1. ヘッダーフィールド名 本文書は、IdentityとIdentity- Infoという新規のSIPヘッダーフィールドを 2つ規定する。構文はセクション9に示す。これのヘッダーフィールドは、以 下の情報で定義される。これは、以下のURLの、ヘッダーの下位登録に追加 された。assignments/sip-parameters ヘッダー名: Identity 短縮形: y ヘッダー名: Identity-Info 短縮形: n Peterson & Jennings Standards Track [Page 31] RFC 4474 SIP Identity August 2006 14.2. 428 'Use Identity Header'応答コード 本文書は、SIP応答コードを新規に登録する(セクション6に記載)。この応答 コードは、ベリファイアがIdentityヘッダーがないSIPリクエストを受信し たときに、リクエストがIdentityヘッダー付きで再送されるべきであること を示すために送信される。本文書は、以下の情報で定義される、新規の応答 コードを登録する。これは以下のURLの、メソッドおよび応答コードの下位 登録に追加された。assignments/sip-parameters 応答コード番号: 428 デフォルトの理由フレーズ: Use Identity Header 14.3. 436 'Bad Identity Header'応答コード 本文書は、SIP応答コードを新規に登録する(セクション6に記載)。この応答 コードは、Identity-Infoヘッダーにベリファイアが逆参照できないURIが含 まれるときに使用される(ベリファイアがサポートしていないURIスキームの 場合や、URIで指定されたリソースがその他の理由で使用できない場合)。本 文書は、以下の情報で定義される、新規の応答コードを登録する。これは以 下のURLの、メソッドおよび応答コードの下位登録に追加された。 assignments/sip-parameters 応答コード番号: 436 デフォルトの理由フレーズ: Bad Identity-Info 14.4. 437 'Unsupported Certificate' 応答コード 本文書は、SIP応答コードを新規に登録する(セクション6に記載)。 Identity-InfoヘッダーのURIから参照される証明書の有効性をベリファイア が確認できないときに使用される。たとえば、証明書が自分で署名された場 合や、ベリファイアがルート証明書を所持していないルート証明機関によっ て署名された場合など。本文書は、以下の情報で定義される、新規の応答 コードを登録する。これは以下のURLの、メソッドおよび応答コードの下位 登録に追加された。assignments/sip-parameters 応答コード番号: 437 デフォルトの理由フレーズ: Unsupported Certificate Peterson & Jennings Standards Track [Page 32] RFC 4474 SIP Identity August 2006 14.5. 438 'Invalid Identity Header'応答コード 本文書は、SIP応答コードを新規に登録する(セクション6に記載)。この応答 コードは、ベリファイアが算出したダイジェスト文字列に対応しない Identityの署名付きメッセージをベリファイアが受信したときに使用され る。本文書は、以下の情報で定義される、新規の応答コードを登録する。こ れは以下のURLの、メソッドおよび応答コードの下位登録に追加された。 assignments/sip-parameters 応答コード番号: 438 デフォルトの理由フレーズ: Invalid Identity Header 14.6. Identity-Infoのパラメータ IANAは、Identity-Infoヘッダーの新しいレジストリを作成した。このレジ ストリは、「alg」というパラメータを唯一のエントリとして作成すること。 「alg」は、Identityヘッダーの署名を作成するときに使用するアルゴリズ ムを記述する。レジストリエントリには、パラメータ名と、パラメータが定 義されている仕様を含める。Identity-Infoヘッダーの新しいパラメータは、 標準化過程のRFCで定義することができる。 14.7. Identity-Infoのアルゴリズムパラメータ値 IANAは、Identity-Infoの「alg」パラメータ値の新しいレジストリを作成 した。このレジストリは、「rsa-sha1」という値を唯一のエントリとして作 成すること。「rsa-sha1」は、Identityヘッダーの署名を作成するときに使 用するアルゴリズムを記述する。レジストリエントリには、「alg」パラ メータ値の名前と、その値が記述されている仕様を含める。「alg」パラ メータの新しい値は、標準化過程のRFCで定義することができる。 Peterson & Jennings Standards Track [Page 33] RFC 4474 SIP Identity August 2006 付録A. 謝辞 Eric Rescorla、Rohan Mahy、Robert Sparks、Jonathan Rosenberg、Mark Watson、Henry Sinnreich、Alan Johnston、Patrik Faltstrom、Paul Kyzviat、Adam Roach、John Elwell、Aki Niemi、Jim Schaadからいただい たコメントに感謝を述べたい。Jonathan Rosenberg は、数え切れないほど のセクションを詳細に修正してくださった。付録Bのビットアーカイブは、 RFC 4475 [16]の草分け的な例に従っている。Hans PerssonとTao Wanによる 細かいレビューに感謝したい。 付録B. メッセージ例のbit-exactアーカイブ 以下のテキストブロックは、セクション10で議論されたメッセージ例で実行 された変換を表すファイルを、エンコードしてgzip圧縮したTARアーカイブ である。各例には、以下が含まれる。 o (foo).message: 元のメッセージ o (foo).canonical: そのメッセージから構築された標準文字列 o (foo).sha1: 標準文字列のSHA1ハッシュ(16進) o (foo).sha1: 標準文字列のRSA署名済みSHA1ハッシュ(バイナリ) o (foo).signed.enc: リクエストに含まれる標準文字列の、RSA署名済み SHA1ハッシュのbase64エンコーディング o (foo).identity: IdentityヘッダーとIdentity-Infoヘッダーが追加され た元のメッセージ また、以下のように、2組のパブリックキー/証明書(それぞれ atlanta.example.com用とbiloxi.example.org用)もアーカイブに含まれる。 o (foo).cer: ドメインの証明書 o (foo).privkey: ドメインのプライベートキー o (foo).pubkey: ドメインのパブリックキー(便宜上、certファイルから 抽出) 圧縮されたアーカイブファイルを損傷することなく復元するには、本文書の テキストを、以下のPerlスクリプトに入力する(出力は、ファイルにリダイ レクトするか、「tar -xzvf -」にパイプする必要がある)。 Peterson & Jennings Standards Track [Page 34] RFC 4474 SIP Identity August 2006 #!/usr/bin/perl use strict; my $bdata = ""; use MIME::Base64; while(<>) { if (/-- BEGIN MESSAGE ARCHIVE --/ .. /-- END MESSAGE ARCHIVE --/) { if ( m/^\s*[^\s]+\s*$/) { $bdata = $bdata . $_; } } } print decode_base64($bdata); または、base-64でエンコードされたブロックを手動で編集して、ドキュメ ント構造の行を削除し、base-64のデコードユーティリティに入力すること もできる。 B.1. エンコード済み参照ファイル -- BEGIN MESSAGE ARCHIVE -- H4sICFfaz0QCA25ld2lkZW50LnRhcgDsW0us5NhZ7gUSwqiF2CAhFikiIQhFt992 +U46it+u8qPK5Uc9WPlVfj/KdpXtomEDCxaAhFggISE2WSHCIoIFioQQC8gqAhRA QQTY8JJAbMgGIYTv7b7T09PT0xNl+mqS3F8qVd3jY/uc85//+87/nXOLoIv9oGjB B2/PIAiDSBwfv1GERInxG8EwAh6/37UHMIQRKIljCI4+gGCUGKtP8Ad3YKemderJ 5EFSBW1QN2Xxmnp5GtblqXqUPfIffBdZcet/p82conUee0H9sfsfhiACw17nfwQa y+Dra+MkQGFkrI+TOPJgAt37/63bo2tjeHGuTVh+bc6FOUub/E0poM7nLGqyLJ06 Id3NGTocPxytMWF6jNJYpDqIoXVLoDlmr+pNx+o7ztZ1ke8WtnXhFUClU5GGLZ6l O3YN8T3P0Usm1GyG9lQGEiBXFE6+yPecSSvPykuV4TPB5ne9xNEO8KxQVXnk3cqn /TaK3C3T7A08cRGokyJPUzmrV7k5pHK7i5bQyOambNcDLxUmH9zMD2sl8FGa+WGt BG6bGe5nHafvFnK5n0dnT6N1nmF0mgt3EK3OxQVdiuMzZrNOhPxNOF37W7w4LmsL OA0Mpeqt7RTKTrDX1CztZgezbM7rLlvQeBnhWzWOV5qDZEdMahLZTo8Wq0oZOL4X FgkgMhY4pNBdU53sHVvlaIX5TjqH0+JkYXAXmmzgSI7H9N3RvHingrIOAUIzCph4 GhsdHGDwET+WCO5SuDtwxXKNvneGYrWiQ5WhaTEJXb0LXb6Trgd2DS0ZZscLWm6B au3aO48HZK4GEWgzN2oRTuBaG/vLXA+aZKh8kDBYyJj7bHWREXgjMWxIgFQrxPyx b3eUc3EEH6iEptuYL1zFRCpr22rPXujFs9EPx0s+o67pbhzRa/eOjvEZX+wjt1hH gKpDHdvdXJA5er1Y22tRXXed+KwyxzFadFtZyW1st4E7V7ROO4Rqw5Cnx6ncXb/Z 5ztdUOmx34dX3Ck8cydPc76+a5uO4XLTMI9Q3iIwDJBOloNbUahd5OK7FnQu637t L/cQdlSHel5tRVjh84Jfhl7pDfV2zZyPeEVs3D3t8XoKAVzDo3YAad6sp4r8nCUb UmxUUWAL9lRiS848gHAm+nZNcQF78RIY2lk6qq6DnFO30Q4B2JaLG2WTkcZ2uVx7 ezqGS4vqngA30c5r3KsI8ODevsvtFf6v6vicBsMd8j+ME+Qt/0PjAnCsT5AQes// d8z/a4OerNZze4z+iczvXqwBtvrI+7TMhDq3WqlMK9nlKt3a0z2RHGGlCQ8jMtub akAY2zocFupKgghFgbyFoS8BZx7Yl3mZXDZt5ZwYcj5kezmjEwY/YCO4rk+lFQc+ 26mK7GYb+rhviUDaVKy2X5DZUvOAOd8VeYQUtOfJ6QxVKtCW0DakDRBDOb3cIk3h F7toGs5wBFldupDkxU1TXS7dnKN1mgFumFWGNmhb8AJH0omt08VC23Jtj1O0A9sn ZMFvA6KMp8s6FYZmkbj7RdcoudzWYdsCq+3SmrVIvq9iqJOxaIu1+6ho406UU2vF ohHFJNVUDOr4sEIxeK0O6nJKHFZhclxeLK4DpvUqSdSqG1+eerx35ELXrPfF5gzq BWs4joD2qSUehFTp8aXsremUp0mrLxp+tnVMFALaFWhZHg6HWorIohz2um5KZcV4 QUcNh4BdC9HZV8ikckSn5WM83neiONKavbQlS4MlANoplaQn67JbMLQ2XSPumQa1 Peterson & Jennings Standards Track [Page 35] RFC 4474 SIP Identity August 2006 OD9iBLYPiyDjudXR4en9xuHQdHmIDGp6VsjyyBvTE85DwIJMty65T2PDtkJqa4Gz Va/KPcjRF8i38qUytVhdmrEUb1rqHDnx7lFyGd+2RC1FCYwFOMErfKO3oymKyceF n8Q7oyfs1eqMEFsqJw1oOfhmaoQNCmJluerLmeSox20+g1idmdZA7zKolVXLMvKY TpCp3KwzlSHYhjpmBCGHXZEp1CnlI0nalZdxHPxtUDLsEFlNGfqGBRCgY9CCd97w YpuQ4HlY8Kyus6wBZ3LIb0tNXx2XmpOdd9EwqPv1VlB8Dgvdbr2S4dNWBnZVirLp Qbgsh0MSKJ646reXI3K8nKSLaHL9nlrRQdVtsbWRviDVDwyrTzD+n9yPGf7fhP8j 5kO3+I/AN/k/gZHYPf7fMf6vLEaZs++FfvGg0pDIGkfRmLsj2PLX6R5NY6JGcywT 6x9OCcDrOOGjUgLwOk74qJQAvJYT3o3O93f6e3b958ZZ2cdvQ/55s/6DvEf/QbBr /YeAifv4/yToP3DCsnQyfZP+s32j/mOO6Tp3ub75uf6TLipXpDDH5DWVbp7VCzve sGxrnfDuWEEErgvprjN2eda4aFS9PzVXGWzLmTSsmvSgcTQyfgYtK6/LkOsy4D2F nX15k4AAm6p+k9Y/FxD2LOBs+nMgph+o/YgXev+u9pM/746BZ4EotJ7YZ0qunQHX ZJni8v5B4wWaXjKJTnfhLmWvRYMzIXYbFjI5jFzInZwlZZR0gmoAGoi39e6ENYEk HsO0UyJ7umXRkl/i+LGOLxE6zD3bkFOqoJYZrS3Mo5bYjjSc16cLjwvABjZ3Tbgw EIHu51MYjruBLihkPUwjBwTDKJjJ0MqZLpQpjMVG40i2HhaHDtNTcH08ZDpASGdm Vh2T7DzUC/SINbE6epSnaWfJNGP36oT2b+QcHeOFULeg/XStYOQGpFdc6+EMcDBK fXviBR7sukN3IxIljBR2fkm/UvlF3SHaEOu9Kng98MJNO5PObPM9s20E9IU2zrbV NVXduLbrRP35fLmVfYCXdZ9mrHGr+yzi5y5+n7CIsCNRdBx901oTYGirG/vMgJcP mP/XeqHOxIMszduZuT2I2qEqFtsYT9j4suzz3WwHhFkxa4eV4ATDkcJN0Tub7Obi l4xiVww3PVTrTb0F53O84Qlbcl16TBnsXHb33UWn26oCVojgnBJk1lLYPuAkDTkf L8mhkBJ2iWCpiC5OB8ScQXFWUTvJ47o+sYS6nRFWkbHTIfaBwTGDU7PBxRN5hsMn 97rPvb3K/29B/nmz/kOit/wPI+NaYFz/49j9/s8nR/8Jb/UfFixdZqes1VXSpDV9 3CxjcUVb/RwFc6SNybjHPOfImvRJ2OKeEoQ6QBb58aQspcM86u350UQOEGHRULYs Ec0uDzIlkqqZ2q6txQOdKTuL4xNyu1G4OXtA95ICEEINTlmB7GqdqrH0TG7jhdyX vs2yPshFrEmJ1dTmymAmDflxuQHlpgjqeJi/pP8syEMjzOWtnCabMJmljbhsIwM1 CpjqVwY78D7TH/gcWSUkqF0uQRaDK2/pxB6UAouR+r3iqCEHiQ/mogxSvcX05ukQ 6jt7cTwPEr9uiHq7BWMT2xU51cIUhPOxTu0rqannADguEKwdDeu1GNJz6bxXbOVy nFKywvH7qaS7J1ZZbIUp4WYQ7+LMtf5DoESp0loF6Q4K5LsNryOnNhebXZ9ujcPA uPDMZJcd2w5Q4TNrBLsMy4WAaO7eoGbKZSo6CB4d5mIHLiQZKDjKXfKzmXWj/zBr o/IxNzemOTZbgzDarnmDbqXj4GtxsYVSA1xHnVSTeSqZFpqCKiD0etuj2BwV5Yuz 79UCoglCNqgzaEh+IUyD1Y2YIgak3kTDfnaKW2XV7jkvYzcRL0vAkdal3OL3Z0tA bEmp3VOqKMtQsmpJcxDMmytnzEcHh7WtoB1yzTsNZhfJCYJ1Ap3SS+ACJj3MV5mG Rp0y1Zos25ebOT47nU8kSB8RD/UuR8cWGddFYbKR2F0op5BLi2jaLdE8BigUVLYb E/b8eGdXOeNJ3M1I51WYCsm035/wcEMbO/yUnKcCq66gTedIeGQW29O0lQNgtUB9 ZL7Yy71YZETcymuNFIN1RK0MGUr3Y5osBHZ9bhaYVlYvEewnVwN6Bf8/fvnnW9N/ yBv9B8Wge/z/jtB/Xk8JwOs44aNSAvA6TviolAC8lhPu9Z9X4n8IHntOURax52R3 G//jAvD5+S8MxbGb9R8K38f/nVgTV1du6X7+OfwHvZNXWfC4rMOn15ecLPaCz9/u Ddxe9cr8qTPDXMwjiYAgRtx+iqDwhNnxT83o9DMTBJ4IgTtBRkdPYOwKpq5weCKq 5tOn9wnXJzn+b37F7cdM/2/M/2AUe3H+E7vZ/0eg+/2fO7ExZicvAr3yUPTxB0T7 xJivQOQx9BCwY+fq9i/QVIwJTI2/HiOPsXfc2im86MmFikTMlQunifwGHm9Rnf6R UNadU/vN1YQcS4S6zK8mTOlOPvt6/PncO60TPnEIb4Z7h4eAWV5N6OtGPrvntcD0 7LaxVTMUgkkSewhwThtcTT4UmB4CrJNlj+bc1eRlXBsvGMHxavIc3h4C8+chcjX5 dHPGWbOEcPlYGXkrtajv8fEShNmNaezbQkRjewoX+alWtjYo5e2gGaTS1iHlZ326 uZQPgckLCyzSJ5f2TOoC0+RK10bj1szDVccKicPn6sDPUZ80Bg2BB40rEX4NLs9h 20HKCfeaefXSw6rVcRnCp23hXyRXJPM1sc4oprAi6XSw126Fw2qBdlB4sJonn37R p0fz4jCO8mejtq2aKxB81Sfv2SX63DtOFj6pG+dREznwOE5l0Y6PeaQERdhGV5Nx 6O7R9TsM//OgaZwwuOP9Pwh7cf57hH7i5vw3gd/j/z3+fyz4/1Gh/XsSwV6K/2sk fwvveFP8QyRxm/9hY43r+Efg+/Ofd2KGRMM/9VLu/5knkwM5IyjUP6A4jPuI5wfU GEw4jsEocX2ghnQdGMbgA3bP8N9l8R+HReDfefwj7/7/H0ZCOPHs/A95H/93YV/6 Peterson & Jennings Standards Track [Page 36] RFC 4474 SIP Identity August 2006 P0b7Veqnf3f9W3/5n9/42+/75f/65g/4f3X4+p/9w0/8wt8Mv/97f/jX/zt88Stf +/Ljv/unb379+OvZvw3aN/7jn59+6vt/Q7n6sU3/RS36oT/5cS+a/8pXGLL7gy+R eY1dET/8qa/+8Q9Wf/HlP6r/9DNf+J9f+8Wf/c3f/vs/z4p/Eb8Q/PePfu2Xfu53 rB/59381fvIfH05+Xr6PwE9c/D8OCu9u4/+F/nt9BOBG/yXuz//djf77bYoYwLcr XADfilhxv+B4a/EfF+e4fTtbQG+Kfxy6Pv+D4SiMosTN+V9yzAnu4/9O4v9DN3k+ ZHfoffs/6JgQ4NRkrtlz84N2gdArCLmC0JtdoDfrDU/PT8bsu3xiNUFN/3875/Pa NBiH8Yt6CBS0Q2SDYcYEkSl9k75Nmkmn7ebWde2WLm3646Jp2q7FtU2btq496EGc KMgu4sH5a4dN8NccCMLYP6AMwcv+Bg/e1NMuZimTdlvXyWxx4/s5pQ0N5SXPk/d9 nrclaSuHrBhbaKb6cHiUHOYxWe8SBkK1CTFVTWbSpDDAGwjZ1vATeRvaWPWnbFIh msyQmKNYmhz38Sa7yG+ckGy5vJKSlF5E8v0ev8mq3bwHPCTYqv9mVEAN9//p+Z+m f9qCMMvqv/+k4fnfEiqCJbcJfVPnuyR/9XS0YxBorSR4jTK/zWywKUlfjUftlEvW a4qqzKsSE0pyvrf629Ubir6awigcGnVEnP0IiZ5wjr4ezjNiqr/IZ9IBl2eo6PU5 BrITiUwg5p5yxcsOWqKUKXvOLE7kHEhQBbtU0/Ek4+p4NDnGZ7zh0FiJvpETJxKF hKx6Is6AXxicGmYUJmvxjXmDTk+qzBSuZMxq0aUKTszlE6WhdM3FBkU5XZLCPT2l 8UlHKOT1ubOBsqtnREzwI5G436TkSgkxzYVkxr9bYbTDCFT/r0y9yshXUrRhlxRF G0sprxm2SY0q2/NYCrMGwkDAo6GZ/t+MCqhh/4/MVf2Pvv7DDMz/wP8Pg/+DyQEH yP+bUQE23P+JqD/zfxpZ9P5fewv8vwXo/d/W7OecjaRZhGWaZq04LtGUjCPIwkUQ krUXmI1xEstIUQmbOVD/IdN/EyrAPfZ/Ff2z+v5P7RD03wpit+2TyoevQvtisv3j fJz48e1pxN3xs+1I74vpO89MxqurnY/XnlxeLFx702lcIjvurZ8ods/MHQtevPD+ bbBr+dR5amnN25XtflV+/fCLPbs62/fO+OD7yqzx9EzqbtfLk4GznxZurp+JHZ0+ 7l5+tPr8vtj2OfXr0sLKnHgrqM6DAv9H/f/bCnCP/Z+ufzOm9PyfhfVfS9hvJkXs N4ci/iZ7gtkGAAAAAAAAAAAAAAAAAAAAAAAAAABAPX4DY+BfEQB4AAA= -- END MESSAGE ARCHIVE -- Peterson & Jennings Standards Track [Page 37] RFC 4474 SIP Identity August 2006 付録C. 元の要件 以下の要件は、本文書で説明されているメカニズムの開発期間に作成され た。この要件は履歴を残す理由から保存されている。 o メカニズムは、プロキシサーバーまたはUASが検証できるリクエストで、 UACまたはプロキシサーバーが強力な暗号的ID保証を実現することを許容 する必要がある。 o ID保証を受信したユーザーエージェントは、ネットワーク検索を実行せ ずに、このような保証を検証できる必要がある。 o ユーザーの代理で証明書を持つユーザーエージェントは、このID保証を リクエストに追加する機能を持つ必要がある。 o ドメインの代理で証明書を保持するプロキシサーバーは、このID保証を リクエストに追加する機能を持つ必要がある。この形式でリクエストに ID保証を追加するために、UACはこのメカニズムをサポートする必要は ない。 o メカニズムは、ID保証のリレー攻撃を防ぐ必要がある。 o 完全なリプレイ攻撃保護を実現するには、SIPメッセージボディの完全性 を保護する機能が必要である(これは、メディアのオファーとアンサーを シグナリングIDにリンクさせるためである)。 o ドメイン内で使用することが認可されている複数のAoR(つまり、アカウ ントやエイリアス)をユーザーが持てるようにする必要がある。1つのID をアサートするUACの場合は、ドメインのローカルポリシーで許可されて いる別の関連IDとして自身を認証する。 Peterson & Jennings Standards Track [Page 38] RFC 4474 SIP Identity August 2006 参考文献 規範となる参考文献 [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] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002. [4] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. [5] Peterson, J., "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893, September 2004. [6] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [7] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002. [8] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003. [9] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [10] Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, May 1999. [11] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 有益な参考文献 [12] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002. [13] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004. Peterson & Jennings Standards Track [Page 39] RFC 4474 SIP Identity August 2006 [14] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004. [15] Peterson, J., "Retargeting and Security in SIP: A Framework and Requirements", Work in Progress, February 2005. [16] Sparks, R., Ed., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test Messages, RFC 4475, May 2006. 著者の連絡先 Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US Phone: +1 925/363-8720 EMail: jon.peterson@neustar.biz URI: http://www.neustar.biz/ Cullen Jennings Cisco Systems 170 West Tasman Drive MS: SJC-21/2 San Jose, CA 95134 USA Phone: +1 408 902-3341 EMail: fluffy@cisco.com Peterson & Jennings Standards Track [Page 40] RFC 4474 SIP Identity August 2006 完全な著作権表記 Copyright (C) The Internet Society (2006). 本文書は、BCP 78に含まれる権利、ライセンス、制限の対象となり、BCP 78 に記載されている例外に従い、著者はすべての権利を持つ。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、寄稿者、寄 稿者が代表となる組織、または寄稿者を後援する組織(存在する場合)、イン ターネット協会およびIETFは、この情報がいかなる権利も侵害していないと いう保証、商用利用および特定目的への適合性への保証を含め、また、これ らだけに限らずすべての保証について、明示的もしくは暗黙的の保証は行わ れない。 知的所有権 IETFは、本文書で記述される技術の実装または使用に関して要求される、知 的所有権または他の諸権利の有効性または範囲に関して、またはこのような 権利下の任意のライセンスがどの範囲まで使用可能か不可能かに関して、何 ら見解を持たない。このような権利を確認する独自の取り組みを行ったこと も示さない。RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79 に記載されている。 IPRの開示のコピーがIETF事務局に対して作成され、利用可能になるライセ ンスの保証すべて、またはこのような所有権の使用に関して、本仕様の実装 者またはユーザーが一般的なライセンスまたは許可の取得を試みた結果につ いては、IETFのオンラインIPR保存所 http://www.ietf.org/ipr で取得可能 である。 IETFは、この規格を実装するために必要とされる技術の範囲にある可能性が ある、すべての著作権、特許または特許アプリケーション、あるいは他の所 有権について、すべての関連団体に対して配慮するよう依頼している。情 報は、IETF (ietf-ipr@ietf.org)宛てに送信していただきたい。 謝辞 RFC編集職務のための資金は、IETF Administrative Support Activity (IASA)によって提供されている。 ----------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2007年 ----------------------------------------------------------------------- Peterson & Jennings Standards Track [Page 41]