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

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

デジタル・アイデンティティ OpenID概要 OpenID技術解説見落としがちな仕様将来へ向けての活動

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

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

ユーザーセントリックを実現する有力技術インターネットで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

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

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

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日時点）

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

認証フローの概要 ------ Password OpenID =katsu 認証キャンセルこの画像は表示できません。ＯＰユーザーの認証要求 (ブラウザリダイレクトで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 ＲＰ

① OpenID入力 ② Discovery ③ アソシエーション確立 ④ 認証要求をOPへ送信 ⑥ パスワード入力 ⑤ Discovery on the RP ⑧ Discovery ⑨ 署名の検証 ⑦ 認証応答をRPへ送信ログイン完了あなた RP OP シーケンス図

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

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の場所を特定

Yadis Discovery ② DiscoveryイメージＲＰ 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=“・・・”/>

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で得る情報

② 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文書

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

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 有効期限

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

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

⑤ 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が変化する場合はさらに作り込みが必要

⑤ Discovery on the RP(例) RP Discovery失敗は出現のトリガらしい ※RPのIP、EV-SSL対応、ドメインなど複数の挙動に従って警告を出すような実装は可能

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値を突きあわせて正しさを検証

⑧ 認証結果の検証署名検証内容の一覧検証項目 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は認証成功と解釈する

⑧ 認証結果検証時の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から認証結果が送られてきた場合

⑦認証応答 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

⑨ 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”」

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が署名を直接検証し、成功した

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を記憶してアカウント管理をする

1/3. OpenID再利用問題 “http://hoge.com/alice”を入力 “http://hoge.com/alice”を入力過去のユーザー現在のユーザー alice#0001へサービス提供 alice#0002へサービス提供ＲＰＯＰサービスを受けるユーザーは別でも、同じOpenID を利用できるようになる alice#0002 alice#0001 “alice#0001”のパスワードを入力 “alice#0002”のパスワードを入力 (Verified)Claimed Identifier

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

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

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

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

仕様拡張 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トークンといった高度認証との組合せ実証

⑦認証応答 ④認証要求 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の認証レベルにマッピング該当ポリシでの認証の有効期間要求認証ポリシ複数の認証ポリシで認証可能

OpenID Tech Night Vol.3 OpenID周辺最近のセキュリティ・トピックス第2部

最近のセキュリティ・トピックスといえば・・・ DNS Cache Poisoning ×

OpenID Protocol RP GOOD OP User BAD OP XRDS

DNS Cache Poisoning @ RP GOOD OP User BAD OP XRDS RP

Can even attack the resolution GOOD OP User BAD OP XRDS RP

If it were https OpenID (or XRI) GOOD OP User BAD OP XRDS アソシエーション証明書チェック失敗 RP

If it were https OpenID (or XRI) GOOD OP User BAD OP XRDS RP シグネチャチェック失敗

DNS Cache Poisoning @ Client GOOD OP User BAD OP XRDS RP

If it were https OpenID (or XRI) GOOD OP User BAD OP XRDS RP 証明書チェック失敗

安全なサービス提供のためにRPができること https URI ないしは、XRIのみを使う XRIはTrusted Resolutionを使う https binding でも SAML binding でも良い OPの証明書ルートチェックは必ず行う 信頼できるルート以外は使わない

OpenID仕様に関するセキュリティトピックス OpenID PAPE 1.0 Draft 3 ×

PAPEとは？エンドユーザの認証方法について、 RPがOPにリクエストをする方法を提供 Phishing-Resistant Authentication Multi-Factor Authentication Physical Multi-Factor Authentication Auth_Level OPがRPに対して、一方的に認証アサーションの品質について通知する方法も提供

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>のような表現に変更

おわりに今後ともOpenIDを宜しくお願いいたします

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

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

More Decks by 勝原達也(Tatsuya Katsuhara)

Other Decks in Technology

Featured

Transcript