NIST Website About NIST usnistgov on Github

Thu, 29 Aug 2019 02:59:56 +0000

NOTE:
この翻訳は2016年11月段階の SP 800-63-3 Draft 版を元に作成されています。
Final 版の翻訳はこちら をご覧ください。

DRAFT NIST Special Publication 800-63C

Digital Authentication Guideline (翻訳版)

Federation and Assertions

Paul A. Grassi
Justin P. Richer
Sarah K. Squire
James L. Fenton


DRAFT NIST Special Publication 800-63C

Digital Authentication Guideline

Federation and Assertions

Paul A. Grassi
Applied Cybersecurity Division
Information Technology Laboratory

Justin P. Richer
Bespoke Engineering
Billerica, MA

Sarah K. Squire
Engage Identity
Seattle, WA

James L. Fenton
Altmode Networks
Los Altos, CA

翻訳者

Nov Matake
YAuth.jp LLC

Month TBD 2016

U.S. Department of Commerce
Penny Pritzker, Secretary

National Institute of Standards and Technology
Willie E. May, Under Secretary of Commerce for Standards and Technology and Director

Authority

This publication has been developed by NIST in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3541 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130.

Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on Federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other Federal official. This publication may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would, however, be appreciated by NIST.

National Institute of Standards and Technology Special Publication 800-63C
Natl. Inst. Stand. Technol. Spec. Publ. 800-63C, xxx pages (MonthTBD 2016)
CODEN: NSPUE2

Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose. There may be references in this publication to other publications currently under development by NIST in accordance with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies, may be used by federal agencies even before the completion of such companion publications. Thus, until each publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For planning and transition purposes, federal agencies may wish to closely follow the development of these new publications by NIST. Organizations are encouraged to review all draft publications during public comment periods and provide feedback to NIST. Many NIST cybersecurity publications, other than the ones noted above, are available at http://csrc.nist.gov/publications.

Reports on Computer Systems Technology

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analyses to advance the development and productive use of information technology. ITL’s responsibilities include the development of management, administrative, technical, and physical standards and guidelines for the cost-effective security and privacy of other than national security-related information in Federal information systems. The Special Publication 800-series reports on ITL’s research, guidelines, and outreach efforts in information system security, and its collaborative activities with industry, government, and academic organizations.

Abstract

This document and its companion documents, SP 800-63-3, SP 800-63A, and SP 800-63B, provide technical and procedural guidelines to agencies for the implementation of federated identity systems and for assertions used by federations. This publication supersedes corresponding sections of NIST SP 800-63-1 and SP 800-63-2.

Keywords

assertions; authentication; credential service provider; digital authentication; electronic authentication; electronic credentials; federations.

Acknowledgements

The authors would like to acknowledge the thought leadership and innovation of the original authors: Donna F. Dodson, Elaine M. Newton, Ray A. Perlner, W. Timothy Polk, Sarbari Gupta, and Emad A. Nabbus. Without their tireless efforts, we would not have had the incredible baseline from which to evolve 800-63 to the document it is today.

Audience

Compliance with NIST Standards and Guidelines

Conformance Testing

Trademark Information

Requirements Notation and Conventions

The terms “SHALL” and “SHALL NOT” indicate requirements to be followed strictly in order to conform to the publication and from which no deviation is permitted.

The terms “SHOULD” and “SHOULD NOT” indicate that among several possibilities one is recommended as particularly suitable, without mentioning or excluding others, or that a certain course of action is preferred but not necessarily required, or that (in the negative form) a certain possibility or course of action is discouraged but not prohibited.

The terms “MAY” and “NEED NOT” indicate a course of action permissible within the limits of the publication.

The terms “CAN” and “CANNOT” indicate a possibility and capability, whether material, physical or causal.

Executive Summary

Under Construction

Table of Contents

1. Purpose

2. Introduction

3. Definitions and Abbreviations

4. Federation

5. Assertion Strength

6. Assertion Presentation

7. Federation Assurance Levels

8. Security

9. Privacy Requirements and Considerations

10. Usability

11. Assertion Examples

12. References

1. Purpose

本ドキュメントおよび SP 800-63-3, SP 800-63A, SP 800-63B は, リモートでの認証を実装する際の Credential Service Provider の技術ガイダンスである.

2. Introduction

Assertion は Identity Provider (IdP) から Relying Party (RP) に対して提示される, ある Subscriber に関する情報を含む Statement である. Assertion は RP と Verifier がお互いに離れた場所にいる場合に用いられる (例: 両者が共有ネットワークやインターネットを通じて接続されているなど). RP は Assertion に含まれる情報を使って Subscriber を識別し, RP の管理下にあるリソースに対する Subscriber のアクセスを制御する. Assertion は Subscriber についての Identification / Authentication Statement を含むこともあり, Subscriber のその他の属性を含むこともありうる. それらの情報は RP が Authorization Decision を下す際の手助けとなる.

Assertion は Identity Federation Protocol を使ってネットワーク越しに提示される. Federation Protocol では, Subscriber は Credential を使って RP に直接認証をすることはなく, Federation Protocol の定める方法により IdP が生成した Assertion を提示することで RP に認証を行う. またその際 IdP が Subscriber を認証することになる. この仕組みを利用すると, IdP に一度認証を行えば, それ以降複数の RP に対して個別の Credential を必要とせずにサービス提供を受けることができるようになるため, Single Sign On の実現にもつながる. なお本ドキュメントでは, “RP” は Federation Protocol における RP を意味し, Primary Credential の RP を含まないので注意すること.

また, Assertion Mechanism は Subscriber の属性・特徴ベースの認証スキーマを促進するものでもある. 属性はしばしば Attribute Based Access Control (ABAC) や Role Based Access Control (RBAC) といったアクセスコントロール手法の中で, アクセス権限を決定する際に用いられる.

Assertion Scheme は一般的にかなり複雑な Multiparty Protocol であるため, 満たすべき Security Requirements も多岐にわたる. ある Assertion Scheme を評価する際は, その Scheme に含まれる Interaction を分解し, 個別に分析してゆくことが有効な手段となる. 一般的に, Subscriber <-> IdP 間の Interaction と Subscriber <-> RP 間の Interaction は 800-63B で示された認証方式と類似したものとなり, IdP <-> RP 間の Interaction は SP 800-63A で示された手順によって確立された属性などを運搬するものとなる. したがって, 本ドキュメントで示される Requirements は, 上記2つのドキュメントと相通じるものがある.

3. Definitions and Abbreviations

Authentication のエリアでは数多くの用語定義がなされている. その多くは前リビジョンの SP 800-63 と一貫性が保たれているが, いくつかについては本リビジョンで改定がなされている. こういった用語の多くには, 一貫した単一の定義はなく, 個々の定義に注意深く注目することが望まれる.

本セクションで定義される用語は, 主に本ドキュメントで参照されるものである. その他の定義や略語については, 他の SP 800-63 ドキュメント群を参照のこと.

Assertion

Verifier から Relying Party (RP) に対して発行される Subscriber に関する Identity Information を含む Statement. Assertion は Verified Attributes を含むこともある.

Assertion Reference

Assertion と紐付けて生成されるデータオブジェクトであり, Verifier を識別するとともに, Verifier が所有する Full Assertion へのポインタとして機能する.

Asymmetric Signature

Asymmetric Keys (Public Key と Private Key のペア) を利用して Digital Signature を付与することで Data Integrity を保護する方法. RSA 署名や Elliptic Curve 署名などが例としてあげられる.

Attribute

人や物に関する生来の性質や特徴.

Attribute Claim

Subscriber のプロパティをアサートする Statement. Identity Information を含まなくても良く, フォーマットは問わない. 例えば “birthday” という属性に対して, “18歳以上” とか “12月生まれ” などが Attribute Claim となりうる.

Attribute Value

Subscriber のプロパティをアサートする完全な Statement. フォーマットは問わない. 例えば “birthday” という属性に対して, “12/1/1980” や “December 1, 1980” などが Attribute Value となりうる.

Authenticated Protected Channel

Connection Initiator (接続元, Client) が Recipient (接続先, Server) を認証し, 暗号化されたコミュニケーションチャネル. Authenticated Protocol Channel は Confidentiality および Man-in-the-middle 耐性を提供するものであり, 認証プロセスの中でよく使われるものである. TLS [BCP 195] がその例としてあげられ, TLS では Recipient が提示した Certificate を Initiator が Verify することになる.

Authentication

User や情報システムの Identity について確証を得るプロセス.

Authentication Protocol

Claimant (要求者) が自身の Identity を確立するための正当な Authenticator を保持および制御していることを示す, Claimant と Verifier の間での一連のメッセージのやりとり. セキュアな Authentication Protocol は, Claimant が正規の Verifier とやりとりしていることも明示する.

Back-Channel Communication

2つのシステム間で直接コネクションを貼って行われるコミュニケーション. (標準プロトコルレベルでのプロキシの利用を許容する) ブラウザ等を媒介としたリダイレクトは用いない. HTTP Request & Response により実現される.

Federation

Identity / Authentication Information を一連のネットワークシステム間でやりとりするためのプロセス. 多くの場合, 各システムは異なるネットワークおよび異なるセキュリティドメインに存在し, 異なる主体により管理・運営されている.

Federation Proxy

IdP に対して論理的に RP として動作し, RP に対して論理的に IdP として動作する, 2つのシステムを Bridge するコンポーネント. “Broker” と呼ばれることもある.

Front-Channel Communication

ブラウザ等を媒介とし, 2つのシステム間でリダイレクトを用いて行われるコミュニケーション. これは通常メッセージ受信者がホストする URL に HTTP Query Parameter を付与することで実現される.

Identity Provider (IdP)

Subscriber の Primary Authentication Credentials を管理し, Assertion を発行する主体. 本ドキュメント群においては, Credential Service Provider (CSP) とも呼ばれる.

Pairwise Pseudonymous Identifier

CSP が特定の RP に対して生成する, opaque で推測不可能な Subscriber Identifier. この識別子は特定の CSP-RP ペア以外には知られることはなく, 当該ペア間でのみ用いられる.

Relying Party (RP)

本ドキュメントでは, Subscriber を識別する Assertion を受け取り処理する主体.

Symmetric Signature

Shared Key を利用して Hash や Digest を付与することで Data Integrity を保護する方法. HMAC や KMAC などが例としてあげられる.

4. Federation

Identity / Authentication Information を一連のネットワークシステム間でやりとりするためのプロセス. Federation シナリオでは, Verifier / CSP は Identity Provider や IdP と呼ばれる. また本ドキュメントでは Relying Party や RP は Federated Identity を受け取る主体である.

Figure 1: Federation

Figure 4-1: Federation

Federation Protocol では, Subscriber, IdP, RP の3者間で三角形の関係がなりたつ ((Figure 4-1). プロトコルによっては, 異なるタイミングで異なる情報が各辺を流れることもある. Subscriber は, 通常は Web Browser を通じて IdP, RP 双方とやり取りを行う. RP と IdP の間のやりとりは, (Subscriber が関与するリダイレクト経由で) Front Channel で行われることもあれば, Back-channel で (Direct Connection を通じて) 行われることもあり, (暗号論的に保護された Self-contained Assertion などのように) パッケージ化された情報を通じて行われることもある.

Subscriber は IdP に対して何らかの Primary Credential を使って自身を認証し, その Authentication Event はネットワーク経由で RP に対して Assert される. IdP はこのプロセスを通じて Subscriber に関する Attribute Statement を生成することも可能である. この Attribute および Authentication Event は通常 Assertion を利用して RP に伝えられる. (Section 5 参照)

RP と IdP とのやりとりは, Subscriber がトランザクションを行う IdP には明示される. 複数の RP とやりとりする IdP は Subscriber のトランザクションをプロファイリングすることも可能となる. これは Federation 無しには不可能であったろう. これは Subscriber の Privacy Interest にそぐわない形での Subscriber Tracking や Profile Information の利用につながりかねない.

IdP は RP 上での Subscriber のアクティビティを第三者に漏らすべきではなく (SHALL NOT), Federated Authentication 目的や法的手続き, 当該ユーザーからの要望による以外でそういった情報を利用すべきでもない (SHALL NOT). IdP は Subscriber Tracking や Profiling を防止したり Unlinkability を確保するための技術的対策を行うべきである (SHOULD).

IdP は, Subscriber アカウントへの不正ログイン発生時など, セキュリティ目的であれば, Federation の範囲内で他の RP に Subscriber のアクティビティを公表することもできる (MAY).

各機関には以下の要件が課せられる.

a) Senior Agency Official for Privacy と協議の上, Privacy Act の要件に照らして, 自身が Identity Federation において IdP となるか RP となるかを分析, 決定する (SHALL).

b) 適宜 System of Records Notice を公開, ないしは適用範囲を特定する (SHALL).

c) Senior Agency Official for Privacy と協議の上, E-Government Act の要件に照らして, 自身が Identity Federation において IdP となるか RP となるかを分析, 決定する (SHALL).

d) 適宜 Privacy Impact Assessment を公開, ないしは適用範囲を特定する (SHALL).

4.1. Federation Models

本セクションでは, 現在使われているいくつかの Identity Federation の一般的モデルを概観する. これらのモデルでは, Federation 参加者間の関係性確立方法が複数種類存在する. なかには等しく高レベルの Trust を必須とするモデルもあり, 多様な Trust Relationship を認めるモデルもある.

4.1.1 Central Authority

Central Authority に従って, 関係各所と相互にメタデータのやりとりを行う Federated Party も存在する. そういったモデルでは, Central Authority は Federation を行う各主体に対して一定レベルの審査を行い, Security および Integrity Standard に対する準拠を求めることが多い.

Central Authority モデルを用いた Federation の多くでは, Federation に参加しているか否かというシンプルなメンバーシップモデルを採用している. しかしながら, より洗練した Federation ではより細かなメンバーシップレベルを持ち, より細かく徹底した審査を通過した主体やより高いアクセスレベルを満たす主体を扱うことができる. 結果として, Federation 参加者が高レベルのメンバーに対して Subscriber の情報を自動的に渡すといったことも可能になる

4.1.2 Manual Registration

Manual Registration モデルでは, System Administorator がメタデータを扱い, システムの相互接続性をテストしたのち, 実際に User Transaction を開始させる. Federation に参加する主体に関するメタデータは Federated Party のレジストリに手動入力される. 各主体は個別に自身が Federation を行いたい相手を登録したレジストリを管理する.

Manual Registration は, Authority や Federation Operator の関与無しに, 個別に行うことができる. この場合, IdP と RP の間で IdP と RP の間には相互の関連性が確立される.

Manual Registration は Central Authority モデルと合わせて利用することもできる. その場合, Central Authority に既知の主体を含んだレジストリが事前に構築され, それ以降は必要に応じて手動でのレジストリ登録が行われることになる.

4.1.3 Dynamic Registration

Dynamic Registration モデルでは, 各システムはその他のシステムが当該システムのメタデータを取得できるように well-known location エンドポイントを持つ. また新しいシステムが人間の関与無しに自身を登録できるよう, 予測可能な形で API エンドポイントも提供する. Dynamic Registration を使うシステムは, Subscriber に IdP 上で Identity Federation Transaction に対する明示的許可を要求するなど, 人間が関与する検証ステップを設けるべきである (SHOULD).

各 Federated Party は, その他の Federated Party に対して, Attribute やその他の情報に関するアクセスポリシーを設定する. Dynamic Registration 環境では, 新しく登録された主体は Authorized Party のレビューを通過するまで非常に限定されたアクセスのみが可能となることもある. 例えば, システム管理者などがより高いアクセスレベルを許可するケースなどがありうる. さらに Dynamic Registration により登録された主体は往々にして Authentication Transaction 中に Subscriber による Authorization を必要とすることになる. (Runtime Decisions 参照)

Dynamic Registration モデルでは, 各主体は事前に相互の関係性を確立できないことが多く, デフォルトではあまり多くの情報をやりとりしないことが多い. この問題は, Software Statement と呼ばれる技術を用いれば, ある程度改善される. Software Statement とは, Dynamic Registration に関与した主体に関する属性を暗号論的に検証可能とするものである. Software Statement は RP Software に関する属性のリストであり, 認証機関により暗号論的に署名されている. 認証機関を信頼する主体は, 認証機関に対する Trust を Dynamic Registration によって確立したパートナーシップに対しても拡張できる. これにより, self-asserted な属性のみに依存せず, Federated Party 間でコネクションを確立したり強めたりすることができる. 詳細は [RFC 7591] Section 2.3 を参照のこと.

4.1.4 Proxied Federation

Proxied Federation Model では, IdP と RP は, 2者間の直接的コミュニケーションを禁止する形で Proxy される. この実現方法は様々であるが, 一般的には “Federation Proxy” (or “Proxy”) やネットワーク上の “node” として動作する第三者が介在することになる.

この介在者は片や Federation IdP として動作し, もう片方では Federation RP として動作する. 特に Federation Proxy は全ての Federated RP に対して IdP として動作し, 全ての Federated IdP に対して RP として動作する. よって IdP および RP に適用される Normative Requirements は, 上記介在者にも同様に適用されるべきである (SHALL).

Figure 2: Federation Proxy

Figure 4-2: Federation Proxy

Proxied Federation Model は多様な利点を持つ. 例えば Federation Proxy は RP と IdP の間でインテグレーションが必要な箇所を削減することで技術的インテグレーションを単純化することもできる. これは Dynamic Registration をサポートしないプロトコルでは有効たりうる. さらに, Proxied Federation Model は RP と IdP の双方を効果的に blind するため, Subscriber のリストをお互いに開示したくない組織にとってビジネス上の機密性を高める効果もある. また同様に上述の Federation におけるプライバシーリスクを軽減する効果もある.

追加のプライバシー保護策を提供しない実装もあれば, Blinding Technology によって多様なプライバシーレベルを提供する実装もある. (注: Blinding Technology を利用したとしても, Blind された主体が Timestamp や Cookie, Attribute や Attribute Bundle のサイズなどを解析し, Subscriber の行動を推測することは可能である.) Privacy Policy で IdP, RP, Federation Proxy による適切なデータ利用を宣言していたとしても, Blinding 技術はデータへのアクセス自体を困難にするため, より効率的である. しかしながらBlinding レベルが上がると, それに比例して技術的・運用上の複雑度は上昇する.

以下に Blinding 実装のパターンを挙げる. この表は説明用のものであり, 網羅性を持つものでもある技術固有のものではない.

Table 4-1: Federation Proxies

Proxy Type RP knows IdP IdP knows RP Proxy can track subscriptions between RP and IdP Proxy can see attributes of Subscriber
Non-blinding Proxy with Attributes Yes Yes Yes Yes
Non-blinding Proxy Yes Yes Yes No
Double Blind Proxy with Attributes No No Yes Yes
Double Blind Proxy No No Yes No
Triple Blind Proxy No No No No

4.1.5 Runtime Decisions

Federated Party が何らかの登録処理や Central な主体による管理によって相互に既知であったとしても, それだけですぐに情報のやりとりが許されるわけではない. 例えば Federated Party の Whitelist を作成し, そういった相手にのみ Subscriber の Runtime Authorization なしで認証連携や Subscriber に関する情報のやり取りを行うこともできる. また同様に Federated Party の Blacklist を作成し, そういった相手には Subscriber に関する情報を全く渡さないということもありうる. Whitelist にも Blacklist にもない Federated Party に対しては, デフォルトではグレーゾーンとして扱い, Authorized Party (往々にして Subscriber) による Runtime Authorization を求めることになろう.

5. Assertions

Assertion とは, Authenticated Subscriber に関する一連の Claim および Statement を含んだものである. Assertion はその利用方法の特徴や保護方法などの複数の軸でカテゴライズされる.

Assertion に含まれるコアとなるべき (SHOULD) Claim は以下の通りである (が, これに限らない):

これらのコアとなる Claim の中でも, 特に Issuance と Expiration Claim は, その Assertion が指し示す Authentication Event 自体に関連し, Subscriber に紐付いたその他の付加的な Identity Attributre には関連しない. Subscriber Attribute は, Assertion 自体の Expiration や Invalidation とは独立して Expire したり Invalidate されたりしうる (MAY).

Assertion は上記以外の Identity Attributes を含んでもよい (MAY). Attribute を Assertion に含める場合の Privacy 要件については Sec.6 を参照のこと. RP は, その他の Identity Attributes を, Assertion と同時に発行された Authorization Credential を用いて別 Trancation で IdP から取得できる (MAY).

詳細は Federation Protocol ごとに異なるが, Assertion は RP での個々のログインイベントのみを表現するべきである (SHOULD). ひとたび RP が Assertion を受け取って処理を完了すれば, その後は session management の段階に移り, 当該 Assertion を直接利用することはない. Assertion の有効期限は RP におけるセッション有効期限を示すべきではない (SHALL NOT).

5.1. Assertion possession category

Assertion は, Assertion を所有している主体が Assertion の Subject となるか, Assertion とは別に Subject であることを示す証拠が必要かという, 所有者の表現方法で分類できる.

5.1.1. Holder-of-Key Assertions

Holder-of-Key Assertion は, Subscriber の持つ共通鍵ないしは (秘密鍵とペアとなる) 公開鍵の参照を含む. RP は, 自身のポリシーに従って, いつ Subscriber に対して当該鍵を所有している証拠を示すべきかを決定することができる. しかしながら, RP は Assertion を Holder-of-Key Assertion として受けとる場合, Subscriber に Assertion が参照する鍵の所有を示すよう要求すべきである (SHALL). ユーザーが鍵の所有を示さずに鍵の参照を含む Assertion を提示する場合, 当該 Assertion は Bearer Assertion (5.1.2) として扱われる.

Holder-of-Key Assertion 参照される鍵は, Client ではなく Subscriber を示す. この鍵は Subscriber が IdP に対して認証を行う際に利用される鍵とは別のものでも良い (MAY).

Subscriber が鍵を所有している証拠を提示できれば, Subscriber は当該 Assertion の正式な Subject であることをある程度の確からしさを持って証明できる. 攻撃者が Subscriber あてに発行された Holder-of-Key Assertion を盗んだとしても, 攻撃者は Subscriber の鍵も同時に盗まなければならず, 盗んだ Assertion を利用するのは困難となる.

鍵の参照は Assertion の Issuer がその他の Claim 同様に Assert するものであるから, その参照もまた当該 Assertion に含まれる他の Claim と同じレベルの信頼度を持った情報として扱うべきである (SHALL).

Assertion は Holder-of-Key を表現するために利用する Private / Symmetric Key を暗号化せずに含むべきでない (SHALL NOT).

5.1.2. Bearer Assertions

Bearer Assertion は, Bearer (持参人) 自身が誰であれ, Bearer 自身の Identity の証拠としてその Assertion を提示することができる. その他の鍵などへのリファレンスは不要である. もし攻撃者が Subscriber を示す正規の Assertion をキャプチャまたは生成できてしまえば, 攻撃者はその Assertion を RP に提示するだけで Subscriber になりすますことができる.

ただし Bearer Assertion を取得することだけが Subscriber になりすます条件であることは稀であり, 後述の Back-channel Federation Model (Section 6.1) のように, 実際には Assertion に RP の識別情報を含んだり Assertion Injection を防いだりといった, RP への不正なアクセスを防ぐ追加の防御策が施されているものである (MAY)

5.2. Assertion protection category

上記の Assertion の所有方式や Section 4 で触れた Assertion 取得に用いる Federation Model とは別に, Assertion は偽造や他 RP に対する再利用を防ぐ何らかの保護策を内包する必要がある.

5.2.1. Assertion Identifier

Assertion は偽造防止の目的で十分なエントロピーを持つべきである (SHALL). 同様に nonce, timestamp, assertion identifier, それらの組み合わせやその他のテクニックを使ってもこの目的を達成できる (MAY).

その他の暗号論的保護策がない場合, こういったランダム性を IdP と RP の間で Assertion をユニークに識別するための共有鍵として扱うべきであろう (SHALL).

5.2.2. Signed Assertion

IdP は Assertion に暗号論的に署名することもできる (MAY). RP は IdP の鍵を用いて各 Assertion の署名を検証すべきである (SHALL). この署名は, Issuer, Audience, Subject, Expiration, その他の各種識別子等, Assertion に含まれる重要なフィールド全体に対してなされるべきである (SHALL).

IdP が公開鍵を公開する鍵ペアによって署名を行うこともでき (MAY), その場合 RP は公開鍵を (IdP がホストする HTTPS URL などから) 動的かつセキュアに取得することができる (MAY). 鍵は (RP の設定段階において) out-of-band で RP に提供されてもよい (MAY).

IdP と RP の間で何らかの方法で共有された共通鍵による署名を用いることもできる (MAY). その場合 IdP は RP ごとに異なる鍵を用いるべきである (SHALL).

署名には Approved Signing Method のいずれかを利用すべきである (SHALL).

5.2.3. Encrypted Assertion

意図された Audience のみが復号できる形で Assertion を暗号化することもできる (MAY). IdP は RP の公開鍵で Assertion を暗号化すべきである (SHALL). その場合 IdP は RP の公開鍵を (RP がホストする HTTPS URL などから) 動的かつセキュアに取得することができる (MAY). 鍵はそれ以外の何らかの方法で (RP の登録時などに) IdP に提供されてもよい (MAY).

暗号化には Approved Encryption Method のいずれかを利用すべきである (SHALL).

5.2.4. Audience Restriction

すべての Assertion は Audience Restriction を施し, RP が当該 Assertion の発行先が自分自身であるかどうかを検知できるようにすべきである (SHOULD). Audience が含まれている場合, RP は Assertion の Audience をチェックし, ある RP に対して発行された Assertion がその他の RP に対して利用されることを防止しべきである (SHALL).

5.2.5. Pairwise Pseudonymous Identifiers

ある条件下では, IdP 上の Subscriber のアカウントが共通の識別子を通じて複数の RP 間でリンクされることを防ぎたい場合もある. そのような場合, IdP は RP に対して Pairwise Pseudonymous Subject Identifier を含んだ Assertion を発行するべきであり (SHALL), IdP は各 RP ごとに異なる識別子を生成するべきである (SHALL). (詳細は Pairwise Pseudonymous Identifier Generation を参照のこと)

RP ごとに固有の Pseudonymous Identifier を用いたとしても, 複数の RP が結託し Subscriber に関するその他の属性を通じて名寄せを行う可能性はある. 例えば2つの独立した RP が同じ Subscriber を異なる Pseudonymous Identifier によって識別したとしても, 両 RP がそれぞれ Pseudonymous Identifier と同時に得た氏名, Email アドレス, 住所, その他の識別可能な属性によって, 当該 Subscriber を同一人物と特定することもできる. Privacy Policy でこのような名寄せを禁止する場合においても, Pseudonymous Identifier は属性の名寄せに必要な作業を増加させるため, ポリシー運用を効率的にする.

Proxied Federation Model では, 末端の IdP は末端の RP に対して Pairwise Pseudonymous Identifier の生成を行えないこともある. この Proxy は Subscriber がどの RP にアクセスしているかを IdP に知らせないこともありうるからである. このようなケースでは, Pairwise Pseudonymous Identifier は IdP と Federation Proxy の間で生成される. IdP として動作する Proxy は, 自身が Downstream の RP に対して Pairwise Pseudonymous Identifier を提供することもある. プロトコルによっては, Federation Proxy は Pairwise Pseudonymous Identifier を Upstream IdP が発行した Identifier に紐付ける必要がある場合もある. そのような場合, 当該 Proxy は同一 Subscriber に紐づく複数の Pairwise Pseudonymous Identifier を名寄せし Track することができる.

5.2.6. Pairwise Pseudonymous Identifier Generation

Pairwise Pseudonymous Identifier は opaque で推測不可能かつ Subscriber の識別情報を含まないべきであり (SHALL), 単一の IdP-RP ペア以外に知られることなくそのペア間のみで利用されるべきである (SHALL).

IdP は RP の要求に答えて同じ Identifier を複数の RP に生成してもよい (MAY) が, それはあくまで以下のようなケースに限ること.

RP は Privacy リスクアセスメントを行い, 共通 Identifier を扱うに際したプライバシーリスクについて検討を行うべきである (SHALL). IdP は意図された RP のみが相互連携を行うことを保証すべきであり (SHALL), 不正な RP がグループの一員のふりをして当該 Pseudonymous Identifier を取得できないようにすること.

6. Assertion Presentation

Assertion は IdP から RP に対して back-channel ないしは front-channel で提示される (MAY). どちらのモデルにも利点と欠点があるが, いずれにせよ Assertion を正しく検証する必要があるのは同じである. Section 4.1.4 にあるように, ある条件下では Federation を簡単にするため IdP と RP の間を Proxy した状態で Assertion をやりとりすることもある.

IdP は RP が明示的に要求した Attribute のみを送信するべきである (SHALL). また RP は Privacy Risk Assesment を行い, どの Attribute を要求するか決定するべきである (SHALL).

(Shoulder Surfing 等により) センシティブな情報を認可なしに露出するリスクを提言するため, 必要に応じてマスキング等の対策を行うべきだが (SHALL), Subscriber は送信される Attribute を閲覧可能であるべきである (SHALL). Subscriber は明示的な通知を受け, Subscriber の Attribute が RP に送信される前に明示的同意を行えるべきである (SHALL). 最低限, 最も効果的に通知および同意取得を行える主体により通知が行われるべきである (SHOULD). どちらの主体が通知と同意取得を行うべきかに関しては, Section 9.2 を参照のこと. もし利用するプロトコルが Optional Attribute をサポートしている場合, Subscriber はそれらの属性についても RP に渡すか否かの選択肢を与えられるべきである (SHALL). IdP はある RP に送信された Attribute Bundle を記憶し, 同じ RP へ当該 Attribute Bundle を再送信するような仕組みを導入してもよい (MAY).

6.1. Back-channel presentation

Back-Channel Model では, Subscriber は Assertion の参照を渡され, 一般的には Front-Channel を通じてそれを RP に提示することになる. Assertion の参照はそれ自身では Subscriber に関する情報は持たず, Attacker による偽造や改ざんに耐えねばならない (SHALL). RP がその参照を IdP に提示して初めて Assertion が取得できる. また RP が IdP に Assertion の参照を提示する際, 通常は RP の認証が行われる.

Figure 1: Back-channel presentation

Figure 6-1: Back-channel presentation

このモデルでは, Assertion 自体は IdP から RP に直接渡されるため, (Subscriber 自身を含む) 3rd-party にインターセプトされたり改ざんされるリスクを最小化できる.

またこの方式では, 最初の Authentication Transaction の後にさらに Back-Channel Communication を継続することもできるため, RP は Assertion に含まれない追加の Attribute を IdP に問い合わせることもできる.

Back-Channel 方式では, ネットワークトランザクションがより多く必要となる一方, やり取りされる情報はそれを必要としている主体以外に渡されることはない. RP が IdP から直接 Assertion を受け取るため, 攻撃箇所は限定される.

Assertion の参照には以下のような要件が求められる.

RP は, Cross-Site Scripting やその他の攻撃への対策を行い, 偽造された Assertion や Capture された Assertion を使った Injection 攻撃を防ぐべきである (SHALL).

Assertion に含まれる Claim は Issuer Verification, Signature Validation, Audience Restriction 等により検証されるべきである (SHALL).

IdP から Subscriber, Subscriber から RP へと Assetion の参照を送信する際には, 認証され保護された Channel を利用すべきである (SHALL). RP から IdP に Assertion の参照を送信する際, IdP から RP に Assertion を送信する際も, 認証され保護された Channel を利用すべきである (SHALL).

Assertion の参照の提示を受ける際には, IdP は Assertion 発行前に RP を認証するべきである (SHOULD).

6.2. Front-channel Presentation

front-channel Model では, IdP は認証成功後 Assertion を生成し Subscriber に渡す. Subscriber は渡された Assertion を利用して RP に自身を認証する. これはしばしば Subscriber のブラウザの機能を用いて実現される.

Figure 2: Front-channel presentation

Figure 6-2: Front-channel presentation

この方式では, Assertion は Subscriber に閲覧可能である. これは Assertion に含まれるシステム情報などの漏洩につながる可能性もある.

Assertion は Subscriber のコントロール下に置かれることから, Subscriber が当該 Assertion を Replay したり, 単一の Assertion を複数の RP に送ることも可能である.

Assertion は Subscriber のコントロール下に置かれることから, Subscriber はブラウザをリプレイして Assertion を複数の RP に送りつけるなどの手段によって, Assertion を本来意図されない主体に送りつけることもできる. Assertion が Audience Restriction により RP に Reject されたとしても, 意図しない RP への Assertion の提示は Subscriber に関する情報や Subscriber のオンラインアクティビティの漏洩につながりうる. 意図して複数の RP に提示できるよう設計された Assertion を生成することも可能だが, そのような手法は当該 Assertion に対する Audience Restriction を緩め, 当該 RP 間における Subscriber の Privacy および Security 侵害につながりうる. よってそのような Multi-RP Use は推奨しない. RP はそれぞれ個別の Assertion を取得するよう推奨される.

RP は, Cross-Site Scripting やその他の攻撃への対策を行い, 偽造された Assertion や Capture された Assertion を使った Injection 攻撃を防ぐべきである (SHALL).

Assertion に含まれる Claim は Issuer Verification, Signature Validation, Audience Restriction 等により検証されるべきである (SHALL).

IdP から Subscriber, Subscriber から RP へと Assetion を送信する際には, 認証され保護された Channel を利用すべきである (SHALL).

6.3. Assertion proxying

実装によっては, IdP, RP, Subscriber の中間者となる Proxy が IdP から Assertion を受け取り, その Assertion を元に RP に対して新たな Assertion を生成することもある. IdP から見れば, こういった Proxy は RP となる. RP から見れば, こういった Proxy は IdP となる. (Section 4.1.4 参照)

こういった Proxy の利用目的としては, 以下のようなものがあげられる.

すべての情報のやりとりは, 認証され保護された Channel を通じて行うべきである (SHALL).

6.4. Protecting Information

IdP と RP の間のコミュニケーションは, 認証され保護された Channel を利用して保護するべきである (SHALL).

IdP は, RP が自身のセキュリティポリシーを適用する際に有用な情報にアクセスできる可能性もある. こういった情報としては, Device Identity, Location, System Health Check, Configuration Management 等があげられる. IdP がこういった情報を取得できる場合, Subscriber のプライバシーを侵害しない範囲内で, そういった情報を RP に渡すことも可能であろう.

User に関する追加の属性は, Assertion とは別に, RP から IdP への認可されたリクエストを通じてやり取りされてもよい (MAY). こういった属性へのアクセスに対する認可は, Assertion と一緒に発行することもできる (MAY). User に関する情報をこのように分離することで, Authentication Assertion 自体には必須な情報のみを含めればよいことになり, ユーザーのプライバシー保護につながる.

RP は可能な限り全属性ではなく Attribute Claim を要求すべきであり (SHALL), IdP は Attribute Claim をサポートすべきである (SHALL).

7. Federation Assurance Level (FAL)

本セクションでは利用可能な Federation Assurance Level (FAL) の一覧を定義する. FAL はあるトランザクションで利用されている Assertion と Federation Protocol の特徴を記述するものである. RP が当該トランザクションにおける要求レベルを明示したり, RP と IdP が当該トランザクションにおける必要レベルをあらかじめ設定しておいたりといった利用方法が想定される.

FAL は assertion protection strength および assertion presentation を統合し, 多様な federation model に適用できる, スカラーで比較可能な値としたものである. 他の様々な要素を組み合わせることも可能だが, FAL の上記3要素を用いて段階的によりセキュアな実装方法の選択肢を提示することにより, 実装ガイドラインとして分かりやすいものを作ることを意図している. FAL のリストに無いような組み合わせも可能であるが, 本ドキュメントではそういった組み合わせは対象としない.

以下の表は Assertion の提示方式が Front Channel か Back Channel (= Assertion Reference を利用する) かという点に基づいて, 異なる要件をまとめている. 一連の各レベルは, そのレベル以下の要件をすべて満たすものとする. Proxy 経由の Federation においては, Proxy された Transaction における最も低いレベルを採用すること (SHALL).

Table 7-1: Federation Assertion Levels

FAL Back-channel Presentation Requirement Front-channel Presentation Requirement
1 Bearer assertion, signed by IdP Bearer assertion, signed by IdP
2 Bearer assertion, signed by IdP Bearer assertion, signed by IdP and encrypted to RP
3 Bearer assertion, signed by IdP and encrypted to RP Bearer assertion, signed by IdP and encrypted to RP
4 Holder of key assertion, signed by IdP and encrypted to RP Holder of key assertion, signed by IdP and encrypted to RP

例えば, FAL 1 は OpenID Connect Implicit Client Profile や SAML Web SSO Profile 等に相当する. FAL 2 は OpenID Connect Basic Client Profile, SAML Artifact Binding Profile 等に相当する. FAL 3 では, FAL 2 に加えて, OpenID Connect ID Token や SAML Assertion を当該 RP の公開鍵で暗号化することといった要件が加わる. FAL 4 では, FAL 3 に加えて, Assertion に紐付いた鍵 (Cryptographic Authenticator 等) の提示が要求される. FAL 4 で提示される追加の鍵は, Subscriber が IdP に対して認証する際に利用するものと同じである必要はない.

どんなプロトコルであれど, Federation Protocol の一部として Assertion の性質に着目すれば, RP はそれがどの FAL レベルに相当するかを簡単に特定できる. したがって, 当該認証トランザクションで要求すべき FAL の決定や, 実際にそのトランザクションが当該 FAL に適合しているかの検証は, RP の責務である.

Table 7-2 に M-04-04 Level of Assurance に厳格に準拠する場合に必要となる Federation Assurance Level のマッピングを示す.

Table 7-2: Legacy M-04-04 FAL Requirements

M-04-04 Level of Assurance (LOA) Federation Assurance Level (FAL)
1 1
2 2
3 2
4 4

しかしながら M-04-04 Level of Assurance では Table 7-3 のようなマッピングを採用することも可能である. 各機関は算定した M-04-04 LOA に対応した適切な FAL を選択すべきである (SHALL).

Table 7-3: Recommended M-04-04 FAL Requirements

M-04-04 Level of Assurance Federation Assurance Level
1 1, 2, 3, or 4
2 2, 3, or 4
3 2, 3, or 4
4 3 or 4

7.1 Key Management

どの FAL においても, IdP は Assertion を Approved Cryptography を用いた署名や鍵によって保護し, RP が他の RP に対して IdP になりすますことができないようにすること (SHALL). Assertion を Asymmetric Signature により保護する場合, IdP は複数の RP に対して同じ Public & Private Key Pair を利用して署名を行ってもよい (MAY). IdP は, well-known location の HTTPS-protected URL に Public Key を配置するなど, 検証可能な形で自身の Public Key を公開してもよい (MAY). Assertion を Symmetric Signature により保護する場合, IdP は RP 毎に異なる Shared Key を利用すること (SHALL).

8. Security

This section is non-normative.

IdP, RP, Subscriber および代表的な Assertion Transaction の登場人物ではない主体も含めて, いかなる主体も悪意を持ったり不正アクセスの被害にあう可能性を否定できない. 攻撃者は, Assertion を偽造したり置換したりすることで, RP が提供するリソースやサービスへのより多くのアクセス権限を取得しようと試みるかもしれない. 同様に攻撃者は, Assertion や Assertion の参照を詐取したり偽造したりすることで, Subscriber になりすましたり, 本来は権限を持たないはずのデータやサービスにアクセスしようと試みるかもしれない. さらに, 2つ以上の主体が共謀し, その他の主体を攻撃することも考えられる. 攻撃者は, Assertion データの Integrity や Confidentiality を損なわせることで, Assertion Protocol 自体を転覆させるかもしれない. こういった一連の脅威に対しては, たとえ認可済みであったとしても, 自身が持つ権限を超えたアクセスを試みる主体は攻撃者とみなされる. 本セクションでは Assertion 伝送トランザクションにおける一般的攻撃パターンについてまとめる.

場合によっては Subscriber は何らかの鍵情報を発行され, それを使って RP に認証することもある. このような鍵情報は Subscriber と Subscriber になりすまそうとする攻撃者を区別するために利用できる. Holder-of-Key Assertion を使う場合は, この鍵は Assertion Protocol を開始する前に事前に IdP との間で確立されていることもある. また IdP がテンポラリな鍵を生成し, 認証済の Subscriber にその鍵を送付することもある. テンポラリな鍵を RP への認証に用いる場合は, そういった鍵は Secondary Authenticator と呼ばれる. Front-channel Model での Assertion, Kerberos の Session Key, Back-channel Model での Assertion の参照, 認証 Cookie なども, Secondary Authenticator の一種である. Secondary Authenticator に対する脅威としては, 以下のようなものがあげられる.

最後に, Subscriber が RP に対して認証を行うためには, RP への認証に用いる鍵と Subscriber を示す Assertion との紐づけを強固にする必要がある.

8.1. Threat Mitigation Strategies

上記のそれぞれの脅威に対する防御策を以下に示す.

9. Privacy Considerations

本章の内容は参考情報である.

9.1 Minimizing Tracking and Profiling

Section 4, 4.1.4 および 5.2.5 では, Tracking および Profiling 能力の向上によりもたらされる Privacy リスクの最小化を目的とした要件をまとめた. 例えば複数の RP に対して同じ IdP を利用して認証を行う Subscriber がいた場合, IdP は Federation を行わない時は存在しえなかった Subscriber Transaction の Profile を構築することができるようになる. そのようなデータは Subscriber が感知せず望みもしないような使い方をされる危険性を孕んでいる. Federation は RP および Subscriber に多くの恩恵をもたらすが, Subscriber による IdP に対する信頼を必要とする. Federation Model において Subscriber の信頼を構築するには, Subscriber のデータ利用が適切に制限され, データ収集時の目的に限定されていることが重要である. 利用目的の範囲内に収まっているかどうかが疑問な際は, Senior Agency Official for Privacy に相談のこと.

Section 4 は Unlinkability を提供し Subscriber Activity の Tracking と Profiling を防止する技術的対策を推奨している. IdP のポリシーと手順は適切な利用制限および目的明確化の原則の順守のために重要な要素であるが, 4.1.4 で述べた Distributed Federation や 5.2.5 で述べた Pairwise Pseudonymous Identifier ような技術的対策は, Subscriber のデータにアクセスすることをより困難にし, IdP のポリシーをより有効なものとする.

Federation において Subscriber の Trust を構築するには, Subscriber に対して Transparency が確保されていなければならず, どのような情報が送信されるのか, どれが必須でどれがオプショナルなのかが Subscriber に理解され, オプショナルな属性を RP に送るかどうかの決定権が Subscriber に与えられている必要がある. Section 6 が Subscriber に関するいかなる属性の送信に際してもその送信前に Subscriber による Positive Confirmation を要求しているのも, そのような訳である. UX スタンダード & リサーチ, およびデータ収集に伴って発生するプライバシーリスクに関するアセスメントを考慮した, 効果的な Notice が重要となろう. 考慮すべき点は, Subscriber がデータ収集の結果として予期するであろう内容の信頼性, Subscriber から収集した上納にその他の情報を紐付けるか否かなど, 多岐にわたる. 効果的な Notice とは, 相当数の Subscriber が読みもせず理解もしないであろう複雑で法律用語に満ちた Privacy Policy や一般契約条件 (General Terms and Conditions) へのリンクではないことだけは注意すること.

Section 6 はどの主体が Notice を提示すべきかを指定していない. Federation においては, Subscriber に Notice を行い Consent を得るための Subscriber への直接のコネクションを持たない主体も存在しうる. 複数の主体が Notice を行うこともありうるが, あらかじめ契約や Trust Framework Policy によってどの主体が Notice を行い Confirmation を得るかを取り決めておくことも可能である. ただしそのような取り決めを行う際は, Subscriber が Notice に気づき, 十分な説明を受けよく考えた上での選択 (Informed Choice) を行えることを前提とすること.

9.3 Data Minimization

IdP が RP の要求以上の追加属性を収集することもあるが, 送信する属性は RP が明示的に要求したものに限定すること. 場合によっては, RP がある属性についての完全な値を必要としないこともありうる. Subscriber が13歳以上かどうかを知りたいが, 完全な生年月日は必要としない場合などが例として挙げられる. 潜在的にセンシティブな PII の収集を最小化するため, RP は “Subscriber は13歳以上か? (Y/N)” などの Attribute Claim を要求することもできる. そうすることで RP はセンシティブかつ不要な PII の収集を最小化できる. このようなことから, Section 6.4 では RP に可能な限り完全な Attribute Value ではなく Attribute Claim を要求するよう求めている.

9.4 Agency Specific Privacy Compliance

Section 4 では Privacy Compliance Requirements 策定のため SAOP (Senior Agency Official for Privacy) と協議すべき要件について定めている. 各機関は Digital Authentication システム構築の早い段階から担当 SAOP を関与させること. Privacy リスクの評価と対策, Privacy Act of 1974 や E-Government Act of 2002 に定められた Privacy Impact Assesment 実施義務の有無などについて, 早期の段階から SAOP の意見を聞くことは非常に重要である. 例えばある機関が Federation において Credential Service Provider を提供している場合, RP となる機関の代理で Credential を管理することになるため, Privacy Act 要件を求められ, 新規もしくは既存の Privacy Act System of Records の対象となるだろう. しかしながらある機関が Relying Party であり 3rd party の IdP を使って Digital Authentication を実現している場合は, どのようなデータが RP に渡り RP がどのような管理を行うかによって Privacy Act 要件を求められないこともある. (そのような場合は当該機関は当該データをカバーするより広くプログラマティックな SORN (System of Records Notices) を提出することになろう) SAOP は同時に PIA の要・不要についても当該機関をサポートできる. これらの Considerations は Privacy Act System of Records Notice や PIA を Federated Credential の利用のためだけに要求するものではない. 多くの場合は, Digital Authentication プロセス全体を網羅した PIA や SORN を記述したり, 当該機関がオンラインアクセスを提供するプログラムやベネフィットについて検討する広範囲の PIA の一部として Digital Authentication プロセスを位置付けるのが良いだろう.

Digital Authentication の要素は多岐にわたるため, SAOP は各個別要素の認識と理解を持ち, どのようなコンプライアンス要件が必要かを適切に助言することが重要である. さらに言えば, SOAP が Digital Authentication の個別要素に関して綿密に理解することによって, コンプライアンスプロセス等を通じたプライバシーリスクの正確な評価と対策が可能になるのである.

10. Usability

Assertion と Federation を利用するには複数の主体の関与とネットワークトランザクションが必須となるため, セキュアなシステムを開発し運用するにはユーザビリティが非常に重要な鍵となる.

11. Assertion Examples

This section is non-normative.

本セクションでは SAML (Security Assertion Markup Language) Assertion, Kerberos Ticket, OpenID Connect Token の各種 Assertion について述べる.

11.1. Security Assertion Markup Language (SAML)

SAML はインターネットを介して信頼された主体間で Authentication & Attribute Information を生成・交換するための XML ベースのフレームワークである. 本ドキュメント執筆時の [SAML] 最新仕様は SAML v2.0 (2015年5月15日発行) である.

SAML の構成要素は以下の通りである.

上記3つの構成要素の組み合わせは SAML Profile と呼ばれ, “Web Browser SSO” などの特定のユースケースに対応する.

SAML Assertion は XML Schema にエンコードされ, 最大3種類の Statement を伝搬するために用いられる.

なお, Authorization Statement は本ドキュメントのスコープ外であり, ここでは議論しない.

11.2. Kerberos Tickets

Kerberos Network Authentication Service [RFC 4120] は, ローカルの共有ネットワーク上で共通鍵暗号方式を利用する Client/Server アプリケーションに対して, 強固な認証方式を提供するプロトコルである. Kerberos では, 拡張仕様によりプロトコル中の特定のステップで公開鍵暗号を利用することもできる. また Kerberos は Subscriber と RP の間のセッションデータに関する Confidentiality および Integrity を保証することもできる. Kerberos は Assertion を利用するが, 共有ネットワーク上での利用を想定して設計されたプロトコルであるため, 厳密には Federation Protocol とは言えない.

Kerberos は, 信頼できない共有ローカルネットワーク上で, 1つ以上の IdP を利用した Subscriber の認証を可能にする. Kerberos では, IdP が Subscriber に対して暗号化した状態で発行したランダムな Session Key を Subscriber が復号することにより, 暗黙的に Subscriber が IdP に対して認証したものとする. (Kerberos の派生プロトコルでは, Subscriber が明示的に IdP に対して認証することを要求するものもあるが, そういったパターンは一般的ではない) 暗号化された Session Key に加え, IdP は Kerberos Ticket と呼ばれる他の暗号化オブジェクトを生成する. Kerberos Ticket は, Session Key および当該 Session Key の発行対象である Subscriber の Identity, Session Key の有効期限を含む. チケットは IdP と RP の間での明示的セットアップフェーズで確立された共通鍵を使って Confidentiality と Integrity を保証される.

Session Key を使って認証するにあたり, Subscriber はチケットを RP に送り, それに添えて Subscriber が当該 Kerberos Ticket に含まれる Session Key の所有者であることを証明する暗号化されたデータも一緒に送る. Session Key は新しいチケットを生成するのに使われたり, Subscriber と RP の間のコミュニケーションの暗号化および認証のために用いられたりする.

一連のプロセスを開始するにあたり, Subscriber は Authentication Server (AS) に Authentication Request を送信する. AS は, Subscriber の長期間有効なクレデンシャルを用いて Subscriber に紐づく Session Key を暗号化する. 長期間有効なクレデンシャルは AS と Subscriber の間の共通鍵でもよいし, Kerberos における PKINIT 相当の派生パターンでは公開鍵証明書を利用することもできる. Kerberos 派生プロトコルの多くは, ユーザーが生成したパスワードから導出された Subscriber と IdP の間の共通鍵に依存しているため, 受動的盗聴者によるオフライン辞書攻撃に対して脆弱であることに注意.

Session Key を Subscriber に伝送するのに加え, AS は Ticket Granting Server (TGS) と共有されたチケットを発行する. Verifier は, 明示的な認証を行う代わりに, 当該チケットに含まれる Session Key を使ってチケットを発行するため, このチケットは Ticket Granting Ticket (TGT) と呼ばれる. TGS は TGT に含まれる Session Key を用いて Subscriber に紐付いた新たな Session Key を暗号化し, RP との共通鍵を使って新しい Session Key に紐付いたチケットを生成する. Subscriber は Session Key を復号し, チケットと新しい Session Key を使って RP に対して認証を行う.

11.3. OpenID Connect

OpenID Connect は, OAuth 2.0 Authorization Famework および JSON Object Signing and Encryption (JOSE) をベースとした, インターネットスケールの Federated Identity and Authentication Protocol である. 本ドキュメント執筆時点での最新仕様は version 1.0 with errata (2014年11月8日発行) である.

OpenID Connect は OAuth 2.0 Authorization Protocol の上に定義され, Subscriber が RP に対して Subscriber Identity および Authentication Information にアクセスすることを許可できるようにする. OpenID Connect および OAuth 2.0 では RP を Client と呼ぶ.

OpenID Connect のトランザクションでは, IdP は ID Token と呼ばれる JSON Web Token (JWT) 形式の Signed Assertion を発行する. Client は ID Token をパースして Subscriber および IdP における Primary Authentication Event についての情報を得る. この ID Token は, 少なくとも Subscriber および Authentication Event に関する以下の Claim を含む.

<!– - iss: An HTTPS URL identifying the IdP that issued the assertion

ID Token に加え, IdP は Client に対して OAuth 2.0 Access Token を発行する. この Access Token は IdP の UserInfo Endpoint にアクセスするために利用できる. UserInfo Endpoint は Subscriber に関する一連の Claim を含んだ JSON Object を返す. ここで返される Claim としては, 氏名, Email アドレス, 住所, 電話番号, その他のプロフィール情報等が挙げられる. ID Token に含まれる情報は Authentication Event を反映したものであるが, UserInfo Endpoint から返される情報は一般的には不変かつさまざまな目的で利用できるものである. UserInfo から返されるそれぞれの Claim へのアクセス権限は, 特別に定義された OAuth Scope を使って管理される. OpenID Connect が定義するそういった Scope としては, openid, profile, email, phone, address が挙げられる. また, offline_access という Scope を用いて, Refresh Token の発行をリクエストすることができる. Refresh Token を利用すると, RP は Subscriber がその場にいない時でも UserInfo Endpoint にアクセスすることができる.

12. References

[OMB M-03-22] OMB Memorandum M-03-22, OMB Guidance for Implementing the Privacy Provisions of the E-Government Act of 2002 (September 26, 2003), available at: https://www.whitehouse.gov/omb/memoranda/m03-22.html.

[RFC 7591] IETF, OAuth 2.0 Dynamic Client Registration Protocol, available at https://tools.ietf.org/html/rfc7591/.

[NISTIR 8112] NIST Internal Report 8112, Attribute Metadata, available at: https://pages.nist.gov/NISTIR-8112/NISTIR-8112.html


Privacy Policy | Security Notice | Accessibility Statement | Send feedback Get help with leaving a comment