Upgrade to Pro — share decks privately, control downloads, hide ads and more …

OpenID 2.0 Specification (OpenID TechNight Vol.3資料)

OpenID 2.0 Specification (OpenID TechNight Vol.3資料)

OpenID 2.0 Specificationについて2008年開催のOpenID TechNight Vol.1-3あたりで利用していた資料です。OpenID Foundation Japanも無事に10周年を迎えたとのことで、OIDFJ設立準備室として黎明期に活動していた際に作成し、OpenID Technight Vol.1-3にて利用していた資料を改めて掘り起こして掲載しました。ID/フェデレーション/認証技術のプロフェッショナルと知り合うきっかけにもなった思い出深い資料です。

More Decks by 勝原達也(Tatsuya Katsuhara)

Other Decks in Technology

Transcript

  1. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page0

    OpenID Tech Night Vol.3 OpenID Authentication 2.0 ~Specification Overview~ OpenIDファウンデーション・ジャパン準備事務局 日付 2008/08/01(Fri) 時間 18:30~19:30 場所 ソフトバンクBB株式会社 東京汐留ビルディング9F 研修会場(キャンパス) クラスルーム9
  2. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page1

    デジタル・アイデンティティ OpenID概要 OpenID技術解説 見落としがちな仕様 将来へ向けての活動
  3. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page2

    ディジタル・アイデンティティの現状 同じような 認証プログラムをいくつも開発 高度認証の実施は コスト大 毎度同じような データ交換処理 サービスを連携させ るのが非常に大変 保有情報が正確ではない ユーザが登録してくれない ユーザに連絡がとれない →猛烈に費用がかかる! パスワードが多すぎて忘れてしまう 提供されるサービスは私の ニーズに合わない カードが多すぎる セキュリティトークンが多すぎる どこに情報があるか分からない 自分の状況が 分からない フィッシングが心配 私の情報なのに私が見られない 今のネットの世界は、「ベンダーセントリック」  「私」は一人なのに、サービスごと切り取られた無数の「私」がいる  切り取られた「私」の情報は、「私」が許可しても決して見ることが出来ない  「私」の情報を利用したサービスを受けるため、仕方なく様々なID/PWを使う 公的個人認証局 認 証 データ 交換 免許証の番号は 0123456です 認 証 データ 交換 ◦◦省 本籍は沖縄です。 金融 認 証 データ 交換 残高は100万円です。 カード番号はXXXで、 期限はYY/ZZです。 物販会社 認 証 データ 交換 住所は、東京都港区 東新橋1-9-1です SNS ◦◦大学卒業です。 洋楽に興味があります。 携帯は090-xxxx-xxxx 認 証 データ 交換
  4. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page3

    ベンダーセントリックから、ユーザーセントリックへ ネット上の「私」を取り戻すためのパラダイムシフト ベンダーセントリックからユーザーセントリックへ SNS 公的個人認証局 金融 物販会社 ◦◦省 これからは「ユーザーセントリック」  「私」の情報は、「私」のもの  「私」の情報は、「私」が管理する  「私」の情報は、いつ、誰に、何の目的で、どの内容を提供したか常に把握する 情報提供・変更の指示 統合表示・履歴管理 提供 要求 提供 要求 提供 「私」情報ハブ 要求 属性情報 集約 属性情報 提供 高度認証 サーバー ◦◦大学卒業です。 洋楽に興味があります。 携帯は090-xxxx-xxxxです。 免許証の番号は0123456です。 本籍は沖縄です。 住所は、東京都港区東新橋1-9-1です。 預金残高は100万円です。 カード番号はXXXで、期限はYY/ZZです。
  5. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page4

    デジタル・アイデンティティ OpenID概要 OpenID技術解説 見落としがちな仕様 将来へ向けての活動
  6. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page5

    ユーザーセントリックを実現する有力技術 インターネットでSSO(Single Sign On)を実現するための規格 「普段自分が使うID」で、複数のウェブサービスにログインできるようにする 中央集権的なIDサーバは存在せず、自分で「私」の情報を管理するOPを選ぶ RPは自身の発行するIDの利用を強制せず、OpenIDを受け入れる Relying Party(RP) OpenID対応サイト へログイン コミュニティサイトもRP ECサイトもRP ブログもRP OpenID Identity Provider(OP) OpenID認証提供サイト 企業サイトもRP OpenID
  7. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page6

    OpenIDを利用したログインの流れ 必要な時に、必要なだけ、ユーザーの許諾に基づいた、属性情報(名前、 住所、TEL etc…)を、RPへ提供することができる 複数IDを覚える必要や、新たな個人情報の登録など、面倒な手続きを省 くことができる いつ、誰に、どの属性情報を提供したかをOPにて確認することができる 認証+パーミッションベースの属性情報提供 ◦◦さん こんにちは **** Password OpenID =katsu サイト:http://www.xxx.jpからの 認証リクエストです。 認証 キャンセル はい いいえ サイト:http://www.xxx.jpが 以下の情報を求めています ・ 住所、氏名 ・ 使用期間 20XX/12/31 情報提供を許可しますか? 今回のみ RPサイトへ アクセス OP認証画面 を表示 属性提供の 承諾画面を表示 RPサイトに ログイン完了 ログイン完了 認証依存サイトに情報を 提供するなら「はい」 本人のOpenIDを入力 パスワードの入力 OpenID RP OP RP
  8. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page7

    古典的な認証・属性情報管理との相違点 Webサイトは、常に同じような認証を行い、個人情報を登録・管理  セキュリティーの脅威  必要以上の個人情報を保持 認証+属性情報の目的の本質は、サービスを提供するユーザーを特定し、 適切なサービスを提供すること  高い信頼性のおけるサイトによる認証代行  サービスに必要最低限の(新鮮な)情報の都度提供 OpenIDに対応 していないサイト サイト毎に別々の ID/PWを入力 サイト数だけの 個人情報 住所・氏名 メールアドレス ID・パスワード カード番号 認証依頼 認証結果 パスワード入力 OP RP 認証依頼 認証結果 RP 住所・氏名 メールアドレス 「私」のID・パスワード カード番号 メールアドレス 「私」のID 住所・氏名 メールアドレス 「私」のID カード番号 メールアドレス 「私」のID 住所・氏名 カード番号 メールアドレス 「私」のID 「私」のIDを入力
  9. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page8

    OpenIDの歩み 2000年代初頭から、ウェブ上のID・パスワード管理への問題意識はあった 米Microsoftが、PassportにIDを中央集権的に統合する仕組みを提示 Sunらが分散型の認証連携のための Liberty Allianceを立ち上げ、SAML規格を 生む 2005年頃、米SixApart社のDavid RecordonらによってOpenIDが提唱 OpenID Foundationの設立  2007/6に、規格の制定・知財の管理団体(米国非営利法人)として誕生  理事企業: Google, IBM, Microsoft, SixApart, Verisign 爆発的な普及  2008/1に米Yahoo!がOpenIDを提供開始。OpenIDユーザは3億7000万へ  2008/7に米MySpaceがOpenIDを提供開始。OpenIDユーザは5億を突破! OpenID ファウンデーション・ジャパン(仮称)設立活動 2008/2 にOpenID Foundationの日本支部の立ち上げを目指した活動を開始 発起人 シックス・アパート株式会社、日本ベリサイン株式会社、株式会社野村総合研究所 参加表明企業 株式会社アセントネットワークス、株式会社イーコンテクスト、インフォテリア株式会社、 株式会社テクノラティジャパン、ニフティ株式会社、株式会社ミクシィ、ヤフー株式会社、 株式会社ライブドアなど約25社 (五十音順、2008年2月27日時点)
  10. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page9

    デジタル・アイデンティティ OpenID概要 OpenID技術解説 見落としがちな仕様 将来へ向けての活動
  11. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page10

    OpenIDの特徴 HTTP/HTTPS上で実現される、Simple&Light weightな認証 プロトコル OpenIDは、入力されたIdentifierから認証サーバの場所を知る  RPは入力IDの認証を、どのOPが行うかを動的に解決する 事前信頼関係を必要としない、オープンな認証アーキテクチャ  世の中の全てのRPとOPが連携可能 Sun, NTT, Intel, Oracle AOL, BT, France Telecom
  12. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page11

    認証フローの概要 ------ Password OpenID =katsu 認証 キャンセル この画像は表示できません。 OP ユーザーの認証要求 (ブラウザリダイレクト でOPへ) 認証結果を署名してRPへ (ブラウザリダイレクト) 1 4 7 6 3 9 ユーザー認証 (OpenIDの規格外) RPへアクセスして ID(XRI/URL)を入力 Discovery情報 提供サイト(URL) 2 5 XRI Authority(XRI) 8 署名鍵を交換 (キャッシュ可能) RPのRealmに Discovery行い、 正当性を検証 OPに署名の代理 検証を依頼 (特定ケース) OP Endpoint URLを得るため Discovery実施 不足情報を補うため Discovery実施 (特定ケース) ① ユーザーはRPでOpenIDを入力する ② RPは入力IDを元にDiscoveryを行い、OP の を取得する ③ RP/OP間で署名用の鍵交換を実施する (キャッシュされていれば省略) ④ ユーザーのブラウザをOPの認証画面へリダ イレクトする ⑤ RPの正当性を確かめるため、OPはRPの Realmに対してDiscoveryを行う ⑥ ユーザーはOPでパスワードを入力し、認証を 受ける ⑦ 認証提供サイトはブラウザリダイレクトを利 用して署名した認証結果を認証依存サイト へ送る ⑧ 結果検証のために不足している情報があれ ば、Discoveryを行う(特定ケースのみ) ⑨ RPが署名検証に失敗した場合、OPに対し て代理検証を依頼する(特定ケースのみ) ユーザー操作 間接通信 直接通信 Discovery RP
  13. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page12

    ① OpenID入力 ② Discovery ③ アソシエーション確立 ④ 認証要求をOPへ送信 ⑥ パスワード入力 ⑤ Discovery on the RP ⑧ Discovery ⑨ 署名の検証 ⑦ 認証応答をRPへ送信 ログイン完了 あなた RP OP シーケンス図
  14. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page13

    OpenIDのID体系 OpenID 2.0のID体系  XRI (eXtensible Resource Identifier)  XML関連の国際標準化団体OASIS Openにより策定  空間的に一意(reassignable)なi-nameと、時間的に一意 (persistence)なi-numberのマッピング 例) xri://=nat、=katsu、@nri/employee/id7777 etc…  URI  通常のOpenID(OPの場所+ユーザー情報) http://alice.pip.verisignlabs.com, myopenid.com/bob  OP Identifier(Directed Identity) http://yahoo.co.jp/, livedoor.com
  15. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page14

    OpenIDのID体系 入力Identifierから認証サーバの場所を知る(Discovery)  入力されたIDに応じて、3種類の方法がある 1. XRI  XRI Resolution  入力XRIから動的に認証プロバイダを特定する、DNSライクな名前解決  認証に必要な情報が記述されたXRDS(XML)を得る  XRDSからOP位置・対応サービスなどの情報を取得する 2. URI  Yadis Protocol  IDがURIの場合、そのURIからXRDS位置または本体の取得を試みる  URIが指し示すHTMLに含まれるMETA情報からXRDS位置を得ることもで きる 3. URI  HTML based  URIが指し示すHTMLに含まれるLINK情報からOPの場所を特定
  16. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page15

    Yadis Discovery ② Discoveryイメージ RP XRDS提供サーバ Top Level XRI Authority XRI Proxyリゾルバ Level-2 XRI Authority Level-n XRI Authority XRDS位置提供サーバ HTTP X-XRDS-Location HTML META情報 XRDS XRDS Level2の XRI Authorityの場所 XRDS Level3の XRI Authorityの場所 XRDS XRDS XRI Resolution ※HTTPバインディングに加え、 HTTPS/SAMLバインディングの Secure Resolutionもある XRDS Level2の XRI Authorityの場所 XRDS Level3の XRI Authorityの場所 XRDS HTML-based Discovery Discover情報提供ページ HTML <link rel=“openid2.provider” href=“・・・” /> <link rel=“openid2.local_id” href=“・・・”/>
  17. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page16

    Claimed Identifier(≒User-supplied Identifier)  これを認証することがプロトコルの大きな目的  http://openidenabled.com/ruby-openid/trunk/examples/user/alice OP Endpoint URL  全てのOpenID認証サービスを受け付けるURL  複数Endpoint URLを記述し、負荷分散やサービスセレクショ ンも可能 Supported Services  OP Endpoint URLが対応するサービス  http://specs.openid.net/auth/2.0/signon  http://openid.net/signon/1.0  http://openid.net/sreg/1.0 etc... ② Discoveryで得る情報
  18. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page17

    ② Discovery(例) http://example.com http://openidenabled.com Discovery情報 提供サイト (OPと同じでも良い) RP あなた Content-Type: application/xrds+xml <?xml version="1.0" encoding="UTF-8"?> <xrds:XRDS xmlns:xrds="xri://$xrds“ xmlns="xri://$xrd*($v*2.0)"> <XRD> <Service priority="0"> <Type>http://specs.openid.net/auth/2.0/signon</Type> <Type>http://openid.net/signon/1.0</Type> <Type>http://openid.net/sreg/1.0</Type> <URI>http://openidenabled.com/ruby-openid/trunk/examples/server</URI> </Service> </XRD> </xrds:XRDS> GET http://openidenabled.com/ruby-openid/trunk/examples/user/alice ①OpenIDの入力 ②Discovery OP Endpoint URL 対応するOpenIDバージョン XRDS文書
  19. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page18

    ③ アソシエーションの確立 署名用の鍵を交換するためのフェーズ(キャッシュ可)  Association handleが署名鍵に紐付くキーに Diffie-Hellmanアルゴリズムに基づく鍵交換  DHセッション鍵にて署名鍵を暗号化して交換  HMAC-SHA1用の160ビット鍵  HMAC-SHA256用の256ビット鍵  強衝突性が突破されているSHA1は、将来的にSHA-256移行が 推奨 アソシエーションは、適切な時間で再構成するのが望 ましい  常に同じアソシエーションだと、ハッシュが破られ署名鍵が 判明するかもしれない pubdh=2 mod p s
  20. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page19

    POST http://openidenabled.com/ruby-openid/trunk/examples/server openid.assoc_type : HMAC-SHA1 openid.dh_consumer_public : AKKgaoVMR+…C0SfzNEV7 openid.mode : associate openid.ns : http://specs.openid.net/auth/2.0 openid.session_type : DH-SHA1 RP http://example.com OP http://openidenabled.com ③アソシエーション確立要求と応答 assoc_handle : {HMAC-SHA1}{480c4fb1}{8T4/PQ==} assoc_type : HMAC-SHA1 dh_server_public : dFCaxM5Baq...VeLwSgQ8= enc_mac_key : jfVVSOLHm1MtyJTzZzL07oybK6g= expires_in : 1209600 ns : http://specs.openid.net/auth/2.0 session_type : DH-SHA1 ※鍵がキャッシュされていれば、実施しない ③ アソシエーションの確立例 OP Endpoint OpenID動作モード セッション鍵で暗号化された署 名検証の共有鍵 共有鍵の識別子 直接通信は 常にPOST 有効期限
  21. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page20

    ④認証要求と⑦認証応答 ブラウザリダイレクトで、認証メッセージを送受信  HTTP Redirectでも、Form Redirectionでも好きな方を  要求・応答で同じメソッドを利用する  Ajaxと組み合わせた非同期認証 (checkid_immediate モード) OPが払い出したnonceで再生攻撃防止  RPは応答中のnonceを適切な期間保持、再生攻撃を防ぐ  nonceを変更しただけのメッセージは署名検証で弾かれる  RPからの署名検証要求に備え、OPは払い出したnonceを 適切な期間重複しないように管理しなければならない 応答メッセージはアソシエーションの共有鍵で署名済
  22. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page21

    RP http://example.com OP http://openidenabled.com ④認証要求 ⑦認証応答 HTTP/1.1 302 Found  GET http://example.com/consumer/complete openid.mode=id_res openid.ns=http://specs.openid.net/auth/2.0 openid.assoc_handle={HMAC-SHA1}{480c4fb1}{8T4/PQ==} openid.claimed_id=http://openidenabled.com/ruby-openid/trunk/examples/user/alice openid.identity=http://openidenabled.com/ruby-openid/trunk/examples/user/alice openid.op_endpoint=http://openidenabled.com/ruby-openid/trunk/examples/server openid.response_nonce=2008-04-21T08:26:33ZqRenZa openid.return_to=http://example.com/consumer/complete openid.sig=VM+4kf9l8SGF/nbdWzL47rt4yA0= openid.signed=assoc_handle,claimed_id,identity,mode,ns,op_endpoint,response_nonce,return_to,signed HTTP/1.1 302 Found  POST http://openidenabled.com/ruby-openid/trunk/examples/server openid.mode : checkid_setup openid.ns : http://specs.openid.net/auth/2.0 openid.assoc_handle : {HMAC-SHA1}{480c4fb1}{8T4/PQ==} openid.claimed_id : http://openidenabled.com/ruby-openid/trunk/examples/user/alice openid.identity : http://openidenabled.com/ruby-openid/trunk/examples/user/alice openid.realm : http://example.com/consumer openid.return_to : http://example.com/consumer/complete ④認証要求と⑦認証応答 HTTP Redirect Form Redirection ⑤Discovery on the RP ⑥パスワードの入力 OPが認証するID Claimed Identifier 認証応答の戻り先 対応OpenIDバージョン 認証失敗時は、cancelまたはsetup_neededの場合もある 要求時と同じメソッド checkid_immediateを利用した非同期認証も可能 リプレイアタック対策 署名構成フィールド OPが認証したID (Verified)Claimed Identifier
  23. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page22

    ⑤ Discovery on the RP 認証要求で指定されるRealmに対してYadisプロトコルで Discoveryを行う(XRDS文書の取得) 認証メッセージの応答先である”return_to” URLが、OpenIDの 認証結果を返すEndpointとして妥当であることを確認  同時に、SSL状態(自己署名かEV-SSLか等)を確認できる(かも)  任意のURLへ認証結果や属性情報を送られることを防ぐ Authentication 2.0 Finalで追加された仕様で、利用している OPは少ない  うまく使うと、RPの信頼性についてユーザーへ警告を出すことができる  RPがXRDSを返却する機能が必要になる  動的に戻りURLが変化する場合はさらに作り込みが必要
  24. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page23

    ⑤ Discovery on the RP(例) RP Discovery失敗は 出現のトリガらしい ※RPのIP、EV-SSL対応、 ドメインなど複数の挙動に 従って警告を出すような実装は可能
  25. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page24

    RP http://example.com OP http://openidenabled.com ④認証要求 ⑦認証応答 HTTP/1.1 302 Found  POST http://openidenabled.com/ruby-openid/trunk/examples/server openid.mode : checkid_setup openid.realm : http://example.com/consumer openid.return_to : http://example.com/consumer/complete ⑤ Discovery on the RP(例) (⑤Discovery on the RP) ⑥パスワードの入力 GET http://example.com/consumer Content-Type: application/xrds+xml <?xml version="1.0" encoding="UTF-8"?> <xrds:XRDS xmlns:xrds="xri://$xrds“ xmlns="xri://$xrd*($v*2.0)"> <XRD> <Service priority="0"> <Type>http://specs.openid.net/auth/2.0/return_to</Type> <URI>http://example.com/consumer/complete</URI> </Service> </XRD> </xrds:XRDS> 2値を突きあわせて正しさを検証
  26. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page25

    ⑧ 認証結果の検証 署名検証内容の一覧 検証項目 RPにとって既知の情報 OPからの認証応答 検証法 Claimed Identifier claimed_id claimed_id(verified) 単純比較(フラグメント除く) OP-Local Identifier identity Identity(verified) 単純比較 OP Endpoint URL メッセージ送信先 op_endpoint 単純比較 Protocol Version ns ns 単純比較 Return to URL return_to return_to 認証応答を実際に処理しているURLと OP値を比較(query込み) Nonce Check 過去Nonce値ストア response_nonce Nonceの重複チェック Association & Signature assoc_handleと紐づく署名 key assoc_handle sig signed 認証応答のassoc_handleが紐づく署 名keyで、signed値のフィールドを連結 した文字列から署名を作成する 結果sig値と比較する OPからの認証応答を検証する必要がある 検証が成功してはじめて、RPは認証成功と解釈する
  27. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page26

    ⑧ 認証結果検証時のDiscovery 認証要求と応答で”claimed_id”値が異なると動作  Claimed Identifierに対応するユーザーを検証するための 情報を、RPがまだ十分に保有していない状態  (Verified)Claimed Identifierに対してDiscovery  OP Identifierを利用した場合(Directed Identity)  認証要求と応答で”claimed_id”値が異なる 要求:http ://specs.openid.net/auth/2.0/identifier_select 応答:ユーザーを特定する形式のOpenID  一方的にOPから認証結果が送られてきた場合
  28. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page27

    ⑦認証応答 openid.mode=id_res openid.claimed_id=http://sample-op.com/bob/ openid.identity=http://sample-op.com/bob/ GET/POST http://sample-op.com/openid/endpoint openid.mode=checkid_setup openid.claimed_id=http://specs.openid.net/auth/2.0/identifier_select openid.identity=http://specs.openid.net/auth/2.0/identifier_select ⑧ 結果検証時のDiscovery(例) ④認証要求 RP http://example.com OP http://sample-op.com 認証応答に含まれる”(verified)claimed_id”をDiscovery した結果を踏まえて、認証結果の検証を実施する HTTP 302(Redirect) JavaScript自動POST ⑥パスワードの入力 Discovery情報 提供サイト(URL) RPにとって既知でない (verified)claimed_idが返る ⑧Discovery on the claimed_id ⑤Discovery on the RP
  29. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page28

    ⑨ OPによる署名の直接検証 アソシエーション再確立による整合性の維持(参考) ケース 整合性を取るためのフロー RPがアソシエーションを喪 失した 1. 通常通りアソシエーション確立要求を実施する 2. OPは確立応答を返し、同時に当該RPとのアソシエーションを更新する OPがアソシエーションを破 損・喪失した、もしくはRP のアソシエーションが破損 した 1. OPにとって、認証リクエスト中の”assoc_handle”は不正な値に見えるので、テンポ ラリの”assoc_handle”値を払い出す 2. テンポラリの”assoc_handle”値に紐付く鍵は存在しないので、RPでの署名検証は 失敗し、直接通信で署名検証が行われる 3. RPは検証応答中の”invalid_handle”に紐付くアソシエーションを破棄(する実装) 4. RPは次回に通常のアソシエーション確立を行い、RP-OP間で整合性のとれた状態 となる アソシエーションに不整合が生じている場合、RPは署名検証 に失敗するので、OPに直接検証を依頼する  透過的にアソシエーションの整合性を取る仕組みを備える必要がある 「不正な”assoc_handle”」=「OPが知らない”assoc_handle”」
  30. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page29

    POST http://openidenabled.com/ruby-openid/trunk/examples/server openid.mode=check_authentication openid.ns=http://specs.openid.net/auth/2.0 openid.assoc_handle={HMAC-SHA1}{480c50f2}{iqK58w==} openid.claimed_id=http://openidenabled.com/ruby-openid/trunk/examples/user/me openid.identity=http://openidenabled.com/ruby-openid/trunk/examples/user/me openid.invalidate_handle={HMAC-SHA1}{59ad50c2}{9T5/PQ==} openid.op_endpoint=http://openidenabled.com/ruby-openid/trunk/examples/server openid.response_nonce=2008-0421T08:31:46ZDZbNaH openid.return_to=http://example.com/consumer/complete openid.sig=ASYAWxoGTTuNbwhrhttEkdC9HjQ= openid.signed=assoc_handle,claimed_id,identity,invalidate_handle,mode,ns,op_endpoint,response_nonce,return_to,signed RP http://example.com OP http://openidenabled.com (⑨署名の検証) invalidate_handle:{HMAC-SHA1}{59ad50c2}{9T5/PQ==} is_valid:true ns:http://specs.openid.net/auth/2.0 ※不正なassoc_handleで認証要求すると、OPはテンポラリassoc_handleを払い出す テンポラリassoc_handleを知らないRPは署名検証できず、OPに検証を要求する ⑨ OPによる署名の代理検証(例) テンポラリで払い出したassoc_handle 認証要求に含まれた 不正なassoc_handle OPが署名を直接 検証し、成功した
  31. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page30

    デジタル・アイデンティティ OpenID概要 OpenID技術解説 見落としがちな仕様 将来へ向けての活動
  32. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page31

    1/3. OpenID再利用問題 OpenIDは再利用される可能性がある ~ユーザーがフォームに入力するOpenIDのリサイクル~  過去ユーザーに対応するRPアカウントに、別人がログインできてしまう!  前ユーザーが退会して、別ユーザーに再割り当てされる場合  ドメインが別の所有者に再割り当てされた場合 OPは、OpenIDユーザーの変遷を管理しなければならない  フラグメントで識別できる管理をする  http://example.com/alice#0002  ユーザーが入力するOpenIDは同じでも、(Verified)Claimed Identifier としてはフラグメント付きのものを返却する  ある時点での“alice → alice#0002”というマッピングはOPだけが把握  RPは(Verified)Claimed Identifierを記憶してアカウント管理をする
  33. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page32

    1/3. OpenID再利用問題 “http://hoge.com/alice”を入力 “http://hoge.com/alice”を入力 過去のユーザー 現在のユーザー alice#0001へサービス提供 alice#0002へサービス提供 RP OP サービスを受けるユーザーは 別でも、同じOpenID を利用できるようになる alice#0002 alice#0001 “alice#0001”のパスワードを入力 “alice#0002”のパスワードを入力 (Verified)Claimed Identifier
  34. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page33

    1/3. OpenID再利用問題 再利用問題はIDの一意性の欠如から生じる  IDの一意性とは?  空間的一意性(reassignable)  URI(ドメインに基づく)  i-name(XRI)  時間的一意性(persistence)  i-number(XRI) URIは空間的に一意なもの  フラグメント利用による、時間的一意性の獲得  ドメイン自体がreassignableであることに起因する問題の解決が必要  ドメインの有効期限切れには注意する  フラグメント値の複雑さで衝突を回避する(UUIDやハッシュ) XRIは時間的にも一意  その時点では一意なi-nameを、時間軸を通して一意なi-numberにマッピング  RPはClaimed Identifierとしてi-numberを記憶して、常にユーザーを一意に特定 時間 =!ABCD.1234 Mapping http://hoge.com/alice#01 http://hoge.com/alice#02 http://hoge.com/alice =nat =sakimura
  35. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page34

    2/3. OpenIDではOP→RPの属性提供しかできない? 「属性提供 on 応答メッセージ」方式ばかりが注目されるが・・・  認証応答に、OP提供の属性をのせて返却 拡張定義により、RP→OPも可能  送りつけるだけなら、return_toを指定しなければ良い  認証不要なら、claimed_id/identityすら省略できる  使い道は十分に検討し尽くされていない  RPからOPへのデータ更新 他… RP OP リクエスト レスポンス+属性情報/任意パラメタ 認証結果が欲しい データが送りたい レスポンス必要/不要 「認証結果」や「受理結果」など リクエスト+属性情報/任意パラメタ レスポンス+属性情報/任意パラメタ 認証OK メッセージ受理 レスポンスは必要? RP OP
  36. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page35

    3/3. Unsolicited positive assertionとは OPから一方的にRPへ送りつけられるpositive assertionのこと 試しに、正常な認証アサーション応答を、RPへ一方 的に送付(デモ) RP OP Positive Assertion リクエストしていないのに いきなりメッセージが来た! 正しい認証結果を 返却 openid.mode=id_res openid.ns=http://specs.openid.net/auth/2.0 openid.claimed_id=(Verified)Claimed Identifier ・・・
  37. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page36

    3/3. Unsolicited positive assertionとは 使い道は?  ポータル(OP)からの、各種RPへの一発ログイン  OpenIDではできないと思われていたシングル・ログアウト  Ajaxと組み合わせ など... 広義のUnsolicitedメッセージの可能性!  ユーザーインタラクションを必要としない、RP-OP間の各種通信  RP属性が変化したことを通知するPing  OPログアウトを合図に一斉に裏でSingle Log-Outを投げる など... ログイン完了! Ping Single Log-Out 情報更新! 一斉にログオフ! Direct Direct RP OP RP OP RP OP RP
  38. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page37

    デジタル・アイデンティティ OpenID概要 OpenID技術解説 見落としがちな仕様 将来へ向けての活動
  39. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page38

    仕様拡張 Trusted Data Exchange  既存の属性提供仕様AX、SREGの問題点  属性情報の暗号化をHTTPSに依存  極めて単純な提供要求とユーザー許可のもとの実施(非否認性がない)  TXのコンセプト  契約ベースの属性提供(非否認性がある)  XML Encryption/XML Signatureによる暗号化・署名  非同期な属性提供(非否認性を持った契約ベース)  OIDF仕様ML&http://wiki.openid.net/Trusted_Data_Exchangeに提案済 Reputation Service  OPやRPの信頼性評価・提供基盤  公開鍵を動的に配布するインフラストラクチャ  ホワイトリスト方式を置き換え Provider Assertion Policy Extension  認証強度をメッセージに載せるためのプロトコル  各国の情報セキュリティ関連法に従うための拡張が必要  バイオメトリクスやHWトークンといった高度認証との組合せ実証
  40. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page39

    ⑦認証応答 ④認証要求 RP http://example.com OP http://sample-op.com ⑥パスワードの入力 Discovery情報 提供サイト(URL) ⑤Discovery on the RP PAPEの概要と追加案 PAPEメッセージ抜粋 openid.ns.pape=http://specs.openid.net/extensions/pape/1.0 openid.pape.max_auth_age=3600 openid.pape.preferred_auth_policies=http://schemas.openid.net/pape/policies/2007/06/multi-factor PAPEメッセージ抜粋 openid.ns.pape:http://specs.openid.net/extensions/pape/1.0 openid.pape.auth_policies: http://schemas.openid.net/pape/policies/2007/06/multi-factor-physical http://schemas.openid.net/pape/policies/2007/06/multi-factor-physical openid.pape.auth_level.fisc:2 openid.pape.auth_level.ns.fisc: http://www.fisc.or.jp/ex/authnlevel XRDS文書抜粋(OP Endpointのサービスタイプ) <Service priority=“20"> <Type>http://specs.openid.net/auth/2.0/signon</Type> <Type>http://openid.net/signon/1.0</Type> <Type>http://openid.net/sreg/1.0</Type> <Type>http://openid.net/pape/1.0</Type> <Type> http://schemas.openid.net/pape/policies/ 2007/06/phishing-resistant </Type> <Type> http://schemas.openid.net/pape/policies/ 2007/06/multi-factor</Type> <Type> http://schemas.openid.net/pape/policies/ 2007/06/multi-factor-physical</Type> <URI>http://example.com/server</URI> </Service> 日本のFISCの認証レベルにマッピング 該当ポリシでの認証の有効期間 要求認証ポリシ 複数の認証ポリシで認証可能
  41. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page40

    OpenID Tech Night Vol.3 OpenID周辺 最近のセキュリティ・トピックス 第2部
  42. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page41

    最近のセキュリティ・トピックスといえば・・・ DNS Cache Poisoning ×
  43. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page42

    OpenID Protocol RP GOOD OP User BAD OP XRDS
  44. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page43

    DNS Cache Poisoning @ RP GOOD OP User BAD OP XRDS RP
  45. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page44

    Can even attack the resolution GOOD OP User BAD OP XRDS RP
  46. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page45

    If it were https OpenID (or XRI) GOOD OP User BAD OP XRDS アソシエーション 証明書チェック 失敗 RP
  47. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page46

    If it were https OpenID (or XRI) GOOD OP User BAD OP XRDS RP シグネチャ チェック 失敗
  48. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page47

    DNS Cache Poisoning @ Client GOOD OP User BAD OP XRDS RP
  49. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page48

    If it were https OpenID (or XRI) GOOD OP User BAD OP XRDS RP 証明書 チェック 失敗
  50. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page49

    安全なサービス提供のためにRPができること https URI ないしは、XRIのみを使う XRIはTrusted Resolutionを使う https binding でも SAML binding でも良い OPの証明書ルートチェックは必ず行う 信頼できるルート以外は使わない
  51. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page50

    OpenID仕様に関するセキュリティトピックス OpenID PAPE 1.0 Draft 3 ×
  52. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page51

    PAPEとは? エンドユーザの認証方法について、 RPがOPにリクエストをする方法を提供 Phishing-Resistant Authentication Multi-Factor Authentication Physical Multi-Factor Authentication Auth_Level OPがRPに対して、一方的に認証アサーション の品質について通知する方法も提供
  53. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page52

    PAPE 1.0 Draft 2 との差異 auth_level に ns を導入 openid.pape.nist_auth_level openid.pape.auth_level.ns.nist openid.pape.auth_level.nist 表記法 「pape」というのは、変数なのだが、誤解する人が 多いので、変数は、<pape>のような表現に変更
  54. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page53

    おわりに 今後ともOpenIDを宜しくお願いいたします
  55. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved. Page54