デジタルアイデンティティの技術を学ぼう!～認証認可にまつわる標準仕様文書を読んでみよう～ / OpenID Summit Tokyo 2024

2024/01/19 OpenID Summit Tokyo 2024: Beyond the Decade: The Evolution and Future of OpenID

（スライド中のミニキャラ画像は P.2が心葉御影さま、その他のスライドで利用している画像は 茶屋猫さまに描いていただいたものです）

Transcript

1. Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. 1 GMOサイバーセキュリティ byイエラエ株式会社 サイバーセキュリティ事業本部 高度解析部 調査分析課 名古屋 謙彦 （@ayokura） 「デジタルアイデンティティの技術を学ぼう！ ～認証認可にまつわる標準仕様文書を読んでみよう～」
2. Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. 2 自己紹介 ▪基本属性 姓名 名古屋 謙彦 （なごや よしひこ） 所属 GMOサイバーセキュリティ byイエラエ株式会社 サイバーセキュリティ事業本部 高度解析部 調査分析課 ▪その他の属性 Twitter（X） あよくら @ayokura BlueSky @ayokura.net 属性タグ CISSP/CC/クリスチャン エンジニアではない人でも簡単・安全にインターネットを利用できるように、 デジタルアイデンティティや認証連携などの技術の適切な利用を広めていきたいです。 デジタルアイデンティティの技術は、インターネット上で（実世界でも）、 僕が僕であることを、あなたがあなたであることを証明できる大切なパーツであり、 学生自体から今に至るまで大好きな領域です。
3. Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. 3 背景 • デジタルアイデンティティを形作る技術を学んでいくとき、概要を学んだあと、 さらに深めていくときに、ほぼ必ずRFCやNIST文章、OpenID Specificationsな どの仕様文書がでてきます。 ‒ 日本語資料がある場合もあるが、最新仕様を読む場合や、正確な記載を確認 する場合など、英語原文に当たらなければならないときもある • 近くに聴ける人がいるのも、強いことだけど、ある程度自分で頑張っていく上では、 この仕様を読み解けるようになる必要があるし、それができるのは強みになる！ ‒ 誤った理解による実装は、相互運用の支障になったり、セキュリティ上の脆弱性 に繋がることも……！
4. Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. 4 今日の内容 • 仕様文書を読んでいくという新人の研修を、僕がお手伝いするときは、 ①大まかな読み方を教える、②実際に読んで気づいたところをまとめる・発表する、 という2ステップで行っています。 • 今日は①の部分でいつもお話しすることを簡単に紹介します。
5. Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. 5 目標 RFCやNISTなどの標準仕様の文章を、忌避感なく読める そのために、読み方のかなめにもなると僕の思う、以下の二つを見ていきます。 • デジタルアイデンティティ関連の仕様でよく参照されている二つの書き方（RFC・ ISO）における、「要請の程度に使われるキーワード」について把握する • RFCの書き方においては、加えてセキュリティ面の記載や、プライバシー面の記載 がどこにあるか、を把握する （僕がはじめてRFCの文書を読んだときに知りたかったなーと思う内容です）
6. Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. 6 標準（化された）仕様の文書 • OAuthやOpenID Connectも、HTTPやDHCPも、はたまた物理的なネジにいた るまで、相互に使えるようにするためには、共通の取り決めが必要です。 • そんな共通の取り決めが作られることは 標準化 とよばれます。 • 標準化の作業で作られる仕様の文章は、読む人によって違った意味にとられない よう、書き方や使う用語についてもある程度ルールが定められています。 • 標準化をする組織によって、ルールには違いがありますが、例えば、守らなければな らないものの強さを表す表現は似通ったルールを使っていたりします。 • ここからは、そんな強さを表す表現について、よく見かける以下の二つの表記法で の使われ方を紹介します。 ‒ IETF（Internet Engineering Task Force）が定めるRFCで用いられる表記法 ‒ ISO（International Organization for Standardization）が定める国際標準で用いられ る表記法
7. Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. 7 参考： いろいろな標準化団体 デジタルアイデンティティ周りでも、いろんな団体が標準化をしています。 • IETFで定めたRFC(Internet Standard Track） ‒ RFC 6749 “The OAuth 2.0 Authorization Framework” • OpenID Foundationで定めたOpenID Specification ‒ OpenID Connect Core 1.0 ‒ Financial-grade API Security Profile 1.0 - Part 1: Baseline • NIST(アメリカ国立標準技術研究所)が作ったSpecial Publication ‒ NIST SP 800-63-3 / NIST SP800-63-4 draft • W3Cが定めたRecommendation（勧告） ‒ W3C Web Authentication（WebAuthn） • 他にもFIDO Allianceや、ISO、JISなどが定めた標準なども
8. Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. 8 RFCのKeywordsの話 RFCの表現方法で、どれくらい従うべき仕様を表すもの： BCP14 • BCP：Best Current Practices、現時点でベストと思われる推奨 BCP14は以下の2つのRFCで構成される ‒ RFC 2119 — Key words for use in RFCs to Indicate Requirement Levels • (RFCにおいて要請の程度を示すために用いるキーワード） ‒ RFC 8174 — Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words • （RFC 2119の大文字と小文字のあいまいさ） [BCP14] https://www.rfc-editor.org/info/bcp14 [RFC2119] Key words for use in RFCs to Indicate Requirement Levels https://www.ietf.org/rfc/rfc2119.txt [RFC8174] Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words https://www.ietf.org/rfc/rfc8174.txt
9. Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. 9 大文字キーワード（RFC） • "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL” • これらのキーワードは記載内容の要求レベルを表し、RFC 2119でその意味が厳 密に定義されている ‒ 例）MUST / REQUIRED / SHALL : 絶対要件 SHOULD / RECOMMENDED : 推奨要件、特定の条件下では採用さ れない場合もあり得るが、その際は十分検討する必要がある • RFC 8174で、キーワードは大文字で表記されたときのみ RFC 2119 の定義に 従うことが明確化（小文字のmustやshouldはキーワードではない） [RFC2119] Key words for use in RFCs to Indicate Requirement Levels https://www.ietf.org/rfc/rfc2119.txt [RFC8174] Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words https://www.ietf.org/rfc/rfc8174.txt
10. Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. 10 RFC/ISOのキーワードの違い RFC ISO 意味・備考 MUST / REQUIRED / SHALL shall 実施しなければならない（必須） MUST NOT / SHALL NOT shall not 実施してはいけない（必須） SHOULD / RECOMMENDED should 実施するべきである（推奨） SHOULD NOT / NOT RECOMMENDED should not 実施するべきでない（推奨） MAY / OPTIONAL may 実施してもよい、実施しなくてもよい（任意）
11. Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. 11 いろんな仕様でのキーワード表記 • 先ほど紹介した仕様たちでもこれらの表現が使われます。 • OpenID Foundationで定めたOpenID Specification ‒ OpenID Connect Core 1.0 （RFC表記） ‒ Financial-grade API Security Profile 1.0 - Part 1: Baseline （ISO 表記） • NIST(アメリカ国立標準技術研究所)が作ったSpecial Publication ‒ NIST SP 800-63-3 / NIST SP800-63-4 draft （いずれもRFC表記） • W3Cが定めたRecommendation（勧告） ‒ W3C Web Authentication（WebAuthn） （RFC表記） ⇒多くの場合、仕様の最初の方にどこの表現を借りてきているかの記載があります
12. Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. 12 例 • OpenID Foundationでの仕様では文章により、キーワードの表記が異なる Financial-grade API Security Profile 1.0 - Part 1: Baseline https://openid.net/specs/openid-financial-api-part-1-1_0.html OpenID Connect Core 1.0 incorporating errata set 2 https://openid.net/specs/openid-connect-core-1_0.html
13. Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. 13 はじめて仕様を読んでいくにあたって ここまで主に英語での仕様本文を読む場合の話をしてきました （でも英語資料読むのって難しいですよね） 実際に仕様を読んでいくのであれば例えば以下のような順序も考えられます 1. 仕様について解説しているような日本語記事を探して概要をつかむ 2. 仕様自体の日本語翻訳を読む（できたら機械翻訳でないもので） ⇒機械翻訳の場合は今日紹介したキーワードの部分も訳されてるので注意。あとた まに意味が真逆になってることも 3. 元々の英語仕様書で、2までの理解が正しいか、キーワードの部分などに気を付 けて検証していく 4．もちろん詳しい人に聞いてみるのも大事（直接とかTwitter（X）とか）
14. Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. 14 Security Considerations • RFCには基本的にSecurity Considerationsが含まれる ‒ 他にもOpenID Foundationが出しているSpecにも含まれる • RFCの本文を参照すれば実装することは可能だが、仕様の意図や目的（どのよう な思想でセキュリティを確保しているか）を知るためにはSecurity Considerationsを読むのが近道 • Security Considerationsだけで独立したRFCが出てる場合もある ‒ RFC 6819 “OAuth 2.0 Threat Model and Security Considerations” • OAuth 2.0の脅威モデルとセキュリティの考察(OAuth 2.0発行後に発生した問題に対 する対処) • ちなみに、OpenID FoundationのSpecではPrivacyに関するPrivacy Considerationsも章立 てされてるのでそちらも忘れず読もう ‒ RFCの場合はPrivacy Considerationsは必要に応じて独立したRFCとなっていそう
15. Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. 15 おすすめの技術文書 • 自分が好きなものや自分で使っているものが一番ではあるのですが…！ いくつか個人的なおすすめの例を書いてみます ‒ 良質な日本語訳があるもの(OIDF-Jの翻訳WG訳がおすすめ) • OpenID Connect Core 1.0 • RFC 6749 “The OAuth 2.0 Authorization Framework” • NIST SP 800-63-4 draft (身元確認・認証・認証連携の保証レベルが学べる) ‒ 英語での一本目として読みやすいと思うもの（図が多かったり） • RFC2131 Dynamic Host Configuration Protocol（いわゆるDHCP） • RFC8628 OAuth 2.0 Device Authorization Grant（いわゆるデバイスフロー） ‒ 最新仕様なもの • draft-ietf-httpbis-message-signatures-19 ‒ HTTPでのやり取りに署名を付ける仕様、もうすぐ正式なRFCになるはず
16. Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. 16 最後に • 標準仕様や、いろんな技術文書を英語でも読めるようになると、気になったことを どんどん深く調べていくことができると考えます。 • まだ読んだことがない方がもしいましたら、トライしてもらえればうれしいです。 • また、もし皆様が教えるときの選択肢の一つとして利用いただければ嬉しいです。 • そして、いろんな技術文書を読んで、もっと仕様を知って、一緒にデジタルアイデン ティティの技術を広げ、守っていき、信頼されて当たり前のものであり続けられる技 術だったらいいな、と思います。 • （私自身ももっと成長しつづけて、 その一端を担い続けられるよう頑張ります）
17. Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. 17 ご清聴ありがとうございました • ご質問などあれば 会場で捕まえて頂くか、 Twitter（X） / BlueSky 等で @ayokura までお寄せください