Table of Contents

1. Purpose

2. Introduction

3. Definitions and Abbreviations

4. Digital Authentication Model

5. A New Approach to Levels of Assurance

6. References

1. Purpose

Sections 1 - 5 are informative.

本リコメンデーションおよび SP 800-63A, SP 800-63B, SP 800-63C は, 政府機関に対して Digital Authentication の実装に際した技術的なガイドラインを提示する.

2. Introduction

Digital Authentication は, 情報システムに対して提示された User Identity の確からしさを確立するプロセスである. ネットワーク越しに個人に対して Remote Authentication を行う場合, Digital Authentication は技術的なチャレンジに直面する. 本リコメンデーションは, 政府機関に技術的なガイドラインを提示し, 個人がリモートで Federal Information Technology (IT) システムに対して自身の Identity を認証できるようにする. また同様に Credential Service Provider (CSP), Verifier, Relying Party (RP) に対するガイドラインも提示する.

現在の政府システムは Authentication と Attribute Provider の機能を分離してはいないが, アプリケーションによってはこれらは異なる主体によって提供されることもありうる. 本ドキュメント群は Authenticator Assurance と Identity Assurance を異なる指標として扱い, それらの指標と全体の Level of Assurance とのマッピングを提示する. これらの技術的なガイドラインは OMB のガイドラインである E-Authentication Guidance for Federal Agencies [OMB M-04-04] を補完し, NIST SP 800-63-1 および SP 800-63-2 を置き換えるものである. OMB M-04-04 は, 誤った認証結果や Credential の誤用などによりもたらされる結果といった観点から, Level1 から Level4 まで4つの Level of Assurance を定義している. なお Level1 が最低で Level4 が最高の Assurance Level となる. この OMB のガイダンスでは, 誤った認証結果によりもたらされるであろう結果という観点から, 必要となる Level of Assurance を定義している. より深刻な影響が想定されるほど, 必要となる Level of Assurance も高くなる. OMB ガイダンスは, 政府機関に対して, 特定のデジタルトランザクションおよびシステムにおいて必要となる Level of Assurance を定めるための基準を提供している. 必要となる Level of Assurance は, リスクやその発生確率に基づいて求められる.

SP 800-63 は以下のドキュメント群からなる.

• SP 800-63-3 Digital Authentication Guideline - 一般的な Authentication Framework, および情報システムにおける Authenticator, Credential, Assertion の利用について概観し, 各 Assurance Level の選択方法について述べる. This document is informative.

• SP 800-63A Enrollment and Identity Proofing - 個人に対する Identity Proofing をおこない, 当該個人を Identity System に登録する一連のプロセスに関するガイドラインを提供する. This document contains both normative and informative material.

• SP 800-63B Authentication and Lifecycle Management - Remote Subscriber を特定の Authenticator Assurance Level で認証する際の, (以前は token と呼ばれていた) Authenticator の選択, 利用, 管理についてのガイドラインを提供する.　This document contains both normative and informative material.

• SP 800-63C Federation and Assertions - Federated Identity, および認証結果の Relying Party への伝搬に用いる Assertion の利用についてのガイドラインを提供する. This document contains both normative and informative material.

SP 800-63A, SP 800-63B, SP 800-63C は今後非同期に改定されることが予想されるが, 各々の最新リビジョンを用いることとする.

OMB ガイダンスは政府機関が Authentication Assurance 要件を満たすために以下の5つのステップからなるプロセスを用いるよう述べている.

1. Conduct a risk assessment of the government system – 特別なリスクアセスメントの手法が規定されているわけではないが, NIST Special Publication (SP) 800-30 [SP 800-30] はリスクアセスメントとリスク軽減策のための一般的なプロセスを提示している. また NIST Special Publication (SP) 800-37 Revision 1 [SP 800-37] は, 組織全体に渡る情報セキュリティ対策の一環として, 情報システムに対するセキュリティ管理策の選択や利用可能な標準仕様に関するガイドラインを提示している. 本ガイドラインは情報システムにおける処理に関与する組織や個人に対するリスクの特定の一助となるであろう.

2. Map identified risks to the appropriate assurance level – OMB M-04-04 の Section 2 は各機関がリスクに見合った Assurance Level のマッピングを行うために必要なガイダンスを提供している.

3. Select technology based on digital authentication technical guidance – 適切な Assurance Level を決定したら, OMB ガイダンスに従い各機関は本ドキュメント群が指定する技術要件に見合う技術を選択すべきである. 機関によっては既存の Digital Authentication 技術を所有しているものもあるであろう. その場合, 各機関は既存技術が本ドキュメント群が指定する要件に適合するか検証を行うべきである.

4. Validate that the implemented system has met the required assurance level – 実装上の問題によりその実装特有のリスクを生み出す可能性もあることから, 各機関は当該システムがユーザーと当該機関との間の一連のプロセスに渡って要求される Assurance Level を満たしているかどうか, 最終確認を行うべきである. NIST SP 800-53A [SP 800-53A] はこの検証プロセスにおける実装済システムのアセスメントに関するガイドラインを提供している. この検証は NIST SP 800-37, Revision 1 [SP 800-37] に記述されている Security Authorization プロセスの一環として行われるべきである.

5. Periodically reassess the information system to determine technology refresh requirements – 各機関は情報システムに関する定期的な再アセスメント行い, Identity Authentication に関する要件が引き続き満たされているかを確認すべきである. NIST SP 800-37, Revision 1 [SP 800-37] は, 定期的な再アセスメントに関する頻度, 深さ, 広さについてのガイドラインを提供している. また, 最初の検証プロセス同様, セキュリティアセスメントに関しては SP 800-53A [SP 800-53A] に示されたアセスメントガイドラインに従うこと.

本ドキュメント群は上記プロセスの Step 3 の実装に対するガイドラインを提供する. 特に本ドキュメントは OMB M-04-04 が定義する4段階の Level of Assurance を対応する Authenticator Assurance Level および Identity Assurance Level にマッピングしている. また本ドキュメント群の他のドキュメントは, 下記のようなエリアに関する Identity Assurance および Authenticator Assurance 固有の技術要件に関して言及している.

• Identity Proofing および Applicant の登録 (SP 800-63A)

• Credential Lifecycle および Credential Management 方式 (SP 800-63A)

• 認証に用いる Authenticators (一般には暗号鍵やパスワードなど) (SP 800-63B)

• Authenticator Lifecycle および Authenticator Management 方式 (SP 800-63B)

• Claimant と Verifier の間の認証のために利用できるプロトコル (SP 800-63B)

• Remote Authentication の認証結果を他の主体とやりとりするための Assertion 方式 (SP 800-63C).

M-04-04 Level of Assurance は, 上記の各要素に対して達成された Identity Assurance Level, Authenticator Assurance Level, Federation Assurance Level を考慮した上で, 全要素を満たすものとして決定される.

設定された Level of Assurance の範囲内で, 各機関は追加のリスク緩和策と補完コントロール (補完統制) を行ってもよい. Credential Assurance Level を緩和することで, サービス利用可能顧客を増やすこともできる. ただしその場合でも, 各機関はシステムに設定した Assurance Level が意図しているセキュリティおよびプライバシーレベルを保証すること. また, センシティブな情報を扱わない機能に関しては低い Level of Authentication Assurance および Level of Identity Assurance を許容しつつ, センシティブな情報を扱う時にはより高い Level of Assurance を要求するといったように, Digital Authentication を行うアプリケーションを機能ごとに分割することもできる.

これらの技術ガイドラインはネットワーク経由の IT システムに対する Remote Digital Authentication をカバーしているが, 対面による認証に関しては言及しない. 例えばある建物への入館時等にリモート利用可能な Credential や Authenticator を Local Authentication に用いることもあるが, そういったユースケースは対象外である. 当技術ガイドラインは,　認証プロトコルに関与する連邦の IT システムおよびサービスプロバイダーが Subscriber を認証する際の要件をまとめている. しかしながら Machine-to-Machine (Router-to-Router 等) の Authentication などには言及しない. また人間を相手にする Authentication Protocol において Machine や Server に対して Authentication Credential や Authenticator を発行するといったことも対象外である.

本ドキュメント群の枠組みにおいては, 個人を登録し, Authenticator を発行し, 個人の Identity を Authenticator に紐付けることで Registration プロセスを実施することになる. より高い Identity Assurance Level では, より強固な Registration 手続きが要求される. その後個人は Authentication Protocol に基づいて Authenticator を用いてシステムやアプリケーションに対してネットワーク経由でリモート認証を行う. この Authentication Protocol は, Authenticator Secret が様々な種類の攻撃から守られた状態で, 当該本人が Authenticator を所持および管理していることを Verifier に提示できるようなものである. より高い Authenticator Assurance Level では, より強固な Authentication Mechanism, より良い Protocol, より高度な Authenticator および関連する鍵の保護策が必要となる.

本ドキュメント群は, 認可を受けていない主体にはアクセスできないような鍵を含み, 簡単には偽造できないような Authenticator にフォーカスしている. また本ドキュメント群が対象としている以外のコンテキストでは, この Authenticator を利用しないことが望ましい. Biometrics Authentication は人間の特徴を利用するものであり, それは攻撃者にも利用可能な場合がある. したがって, Authentication 目的での Biometrics の利用は, 特別な物理 Authenticator のアクティベーションに限定する. また, そういった Authenticator は, Biometrics が強固に紐づけられ, 許容される連続アクティベーション失敗回数が制限されており, それを超えるとその他のアクティベーション要素や Authenticator が必要となるものとする. 本ドキュメント群は, 登録の否認防止, および登録プロセスの全フェーズにおいて同一人物が関与していることの検証の目的でも, Biometrics の利用をサポートする.

Knowledge Based Authentication では, パブリックなデータベースに対して当該個人の知識をチェックすることになる. この情報はプライベートであると考えられるが, 実際には秘匿情報ではなく, 当該個人の Identity に関する確証を得ることは困難たりうる. また Knowledge Based Authentication システムの複雑さと相互依存性は定量化が困難である. しかしながら Knowledge Based Verification の技術は SP 800-63A の Registration の一部として含まれている.

本ドキュメント群は Remote Authentication のための最低限の技術要件を特定するものである. 各機関はそれぞれのリスク分析に基づいて特定コンテキストにおいて適切な追加対策を行ってもよい. 特にプライバシー要件とリーガルリスクは, 各機関が Authentication やその他のプロセスにおける追加の保護策の採用を決める要因となりうる. Digital Authentication のプロセスおよびシステムを構築するにあたって, 各機関は OMB Guidance for Implementing the Privacy Provisions of the E-Government Act of 2002 [M-03-22] を参照すべきである. Guide to Federal Agencies on Implementing Electronic Processes [DOJ 2000] は, Use of Electronic Signatures in Federal Organization Transactions [ESIG] と同様に, リーガルリスクに関する追加情報として, 特に Legal Standards of Proof を満たし否認を防止するのに必要な要件を提供する.

さらに, 本ガイドラインを実装する連邦政府機関は, Title III of the E-Government Act (Federal Information Security Management Act [FISMA]), および関連する NIST 標準 & ガイドラインの要件に準拠すべきである. FISMA は, 各政府機関に対して, 当該機関のオペレーションおよびアセットを支える情報および情報システムにおける情報セキュリティを確保する機関全体を通したプログラムの開発, 記録, 実装を要求する. Digital Authentication をサポートする IT システムにおける Security Authorization も対象に含む. 連邦政府機関以外がこれらのガイドラインを実装する場合も, Security Management, Certification, Accreditation (適格性認定) に関する同等の基準に従い, Digital システムにおけるセキュアなオペレーションを保障すべきである.

2.1. How to Use this Suite of Special Publications

初期の Special Publication 800-63 がリリースされた頃と比較すると, ビジネスモデル, マーケットプレイス, Identity Service の提供形態などは大幅に変化している. 特に CSP は, 異なるビジネス主体によって独立して運用・管理されたコンポーネントの組み合わせとして実現されるようになった. また Identity Proofing が不要なケースでも, 強固な Authenticator を利用するメリットが明らかになってきてもいる. こういった背景から, これらの新しいモデルを促進し, 全体の Digital Authentication モデルの特定の機能要素に求められる固有の要件に容易にたどり着けるように, 800-63 以下の一連の Special Publication が作成されたのである. 各ドキュメントは独立しているが, すべての CSP は (たとえコンポーネント化されていても) SP 800-63A および SP 800-63B への準拠が求められている. CSP が Identity Federation をサポートする場合には, SP 800-63C もその要件となる. なお, Standaline の CSP よりも Identity Federation をサポートする CSP が好まれることを注記しておく.

2.2. Relationship to Other Standards and Guidelines

本ドキュメントは連邦政府機関のニーズに合わせて記述されている. しかしながら, 市民サービスが世界中に広がり, Identity Assurance および Authentication Assurance への要求が拡大する中, 国際的な Identity Federation や相互接続性を促進させるようなユースケースも増大している. よって, 国家的ないしは国際的な Level of Identity Assurance の標準を確立することも, 本ガイドラインの目的となる. Table 2-1 provides a representative snapshot of mappings to various international and national assurance documents. Table 2-1 は多くの国家的・国際的な Assurance ドキュメントとの代表的なマッピングを示している. IAL および AAL と国家的・国際的な様々な標準との間の直接的な相関があるわけでは無いが, 本ドキュメントはそういった標準が明示する基準を満たすものとなろう.

SP 800-63	[GPG 45]	[RSDOPS]	[STORK 2.0]	[ISO 29115]	[ISO 29003]	[Canada]
N/A	N/A	Level 01	N/A	N/A	N/A	N/A
AAL/IAL 1	Level 1	Level 1	QAA Level 1	LoA 1	LoA 1	IAL/CAL 1
AAL/IAL 1	Level 2	Level 2	QAA Level 2	LoA 2	LoA 2	IAL/CAL 2
AAL/IAL 2	Level 3	Level 3	QAA Level 3	LoA 3	LoA 3	IAL/CAL 3
AAL/IAL 3	Level 4	N/A2	QAA Level 4	LoA 4	LoA 4	IAL/CAL 4

2.2. Change History

2.2.1. SP 800-63-1

NIST SP 800-63-1 は NIST SP 800-63 の更新版として, 当時の Authenticator (Token) 技術を反映し, Digital Authentication アーキテクチャモデルの理解をより深めるべく再構成されたものである. また同時に追加の (かつ最小限の) 技術要件が, CSP, 認証情報伝送用のプロトコル, (利用する場合は) Assertion に対して要求されている. その他の NIST SP 800-63 からの変更点は以下の通りである.

• 従来の Token タイプに対する専門用語の変更や, Pre-registered Knowledge Token や Look-up Secret Token, Out-of-band Token 等のより多種多様な Token タイプへの言及.

• Assertion Protocol と Kerberos に対する詳細な要求.

• Token and Credential Management という新たなセクション.

• パスワードエントロピーと Throttling に関するよりシンプルなガイドライン.

• Federal IT システムを対象としたドキュメントであることの強調.

• Figure 1 に示す連邦 IT システムにおけるシンプルなモデル以外のより幅広い Digital Authentication モデル, Assertion モデル, Proxy モデルなどへの言及. (Figure 6 参照)

• Table 12 における Level 3 と Level 4 の差異の明確化.

• 既存の Credential を利用して新たな Credential を発行するための新たなガイドライン.

NIST SP 800-63-1 では, それ以外にも RA, CSP, Verifier, RP のそれぞれに関するセキュアな実装のための一連の Recommendation を提示している. なお, これら一連の要素の全てがそれぞれセキュアに実装されて初めて, 必要とされる Level of Assurance を実現できることに注意すること. したがって NIST SP 800-63-1 では以下のような想定がなされている.

• RA, CSP, Verifier はそれぞれ Trusted Entity である. これら Trusted Entity を実装する各機関は, それらがインタラクションを行うその他の Trusted Entity も同様に, 必要とされる Security Level を満たすよう適切に実装されていることに確証を持っている.

• RP は Trusted Entity とはみなされないが, 認証システムによっては, Verifier が RP との関係性を維持し, セキュアコミュニケーションを推進して RP が責任を持って動作できるときにのみ本来の価値を発揮できるよう, なんらかの Security Control を行う場合もある. また Subscriber は, RP が要求されたサービスを適切に提供し, 関連する Privacy Policy に従うであろうと信頼している.

• Certification のプロセスによって, 各機関が自分自身が実装した Trusted Entity 以外に対しても, 上記の各項目に対する確証を得ることができる.

• Trusted Entity は当該ドキュメントの推奨にしたがって適切に実装され, 悪意を持って不正を働かない.

• Trusted Entity は悪意を持って不正を働かないと想定されるが, 当該ドキュメントには Trusted Entity の悪意や過失によってもたらされるダメージを低減・分離するための Recommendation も含まれている.

2.2.2. SP 800-63-2

NIST SP 800-63-2 は Special Publication 800-63-1 の限定的なアップデートであり, 実質的な変更点は Section 5 Registration and Issuance Processes に限定されていた. これらの変更は Identity Proofing プロセスにおける Professional Credential の利用推進を目的としており, Level 3 の Remote Registration において Credential 発行のために当該住所に対して郵便を送る必要性を低減することを目的としていた. Section 5 に対するその他の変更は軽微である.

2.2.3. SP 800-63-3

NIST SP 800-63-3 では, Special Publication 800-63-2 に対して大幅な改定と再構成を行っている. 本リビジョンでは Authenticator Assurance Level, Identity Assurance Level および Federation Assurance Level という概念を導入し, 認証強度と Claimant の Identity に関する確度を分離して扱いたいというニーズ (例えば仮名を使った強固な認証等) の高まりに答えている. また同時に単一のドキュメントであったものを, SP 800-63-3 を最上位とした4つのドキュメント群に分割している.

SP 800-63-2 からのその他の変更は以下の通りである.

• Assertion 技術における Token という用語との混同を防ぐため, 従来の Token という用語を Authenticator に置き換え.
• Security 技術および脅威の拡大に対応すべく, Authentication および Assertion に関する要件を更新.
• Verifier に対する長期間有効な Secret の保存に関する要件の追加.
• Identity Proofing モデルの再構成.
• “something you have” として利用されるチャネルおよびデバイスとしては, 独立したものを利用することという要件の明確化.
• Pre-registered Knowledge Token (Authenticator) は (往々にして弱い) パスワードの特別な形態であるという認識のもと, Pre-registered Knowledge Token を関する記述の削除.
• Authenticator を紛失したり盗難にあったりした場合における Account Recovery に関する要件の追加.
• Reauthentication および Session Management に関するさらなる議論.
• Identity Federation に関するさらなる議論. Federation コンテキストにおける Assertion の再構成.

3. Definitions and Abbreviations

Authentication 分野で使われる用語は幅広く, 多くの用語は SP 800-63 との整合性を保っているものの, いくつかは本リビジョンから定義が変更になっている. 多くの用語に複数の定義がありうるため, 本ドキュメントにおける定義を明確にする必要がある.

本セクションでは, 本ドキュメントで利用される用語の定義を行う. SP 800-63 ドキュメント群のその他のドキュメントで利用される定義や略語は, それぞれのドキュメントにて定義する.

Address of Record

許可された手段によって特定個人とのコミュニケーションに利用可能な, 有効かつ検証済の (物理的またはデジタルの) 場所情報.

Applicant

登録および Identity Proofing のプロセスを受けている主体.

Assertion

Verifier から Relying Party (RP) に対して送られる, Subscriber の Identity 情報を含んだ Statement. Assertion は検証済属性情報を含むこともある.

Assurance

[OMB M-04-04] および本ドキュメントのコンテキストにおいては, Assurance とは 1) 当該 Credential を発行された個人の Identity を確立する審査プロセスにおける確からしさの度合い, および 2) 当該 Credential の提示者が当該 Credential の発行対象の個人と同一であることの確からしさの度合い, の2つを持って定義される.

Asymmetric Keys

公開鍵と秘密鍵からなる鍵ペア. 暗号化と復号, 署名生成と署名検証など, 対となるオペレーションに用いられる.

Attack

認可を持たない個人が, Verifier や Relying Party をだまして当該個人を Subscriber だと信じ込ませようとする行為.

Attacker

不正な意図を持ち情報システムに不正アクセスする主体.

Attribute

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

Authentication

ユーザーや情報システム自体の Identity の確からしさを確立するプロセス.

Authentication Protocol

Claimant が, 正規の Authenticator の所有および管理権限を示すことで自身の Identity を確立するプロセスにおいて, Claimant と Verifier の間でやりとりされる一連のメッセージの定義. Claimant が意図した Verifier とコミュニケーションしていることを立証するためのプロセスを含むこともある.

Authentication Secret

あらゆる鍵を示す一般的な呼び名. Authentication Protocol において Attacker が Subscriber になりすますために利用することもできる.

Authentication Secret は short-term authentication secrets と long-term authentication secrets に分類することができ, 前者は限定的な期間のみ利用可能なもの, 後者は手動でリセットされるまで使い続けられるものを示す. Authenticator Secret は long-term authentication secret の代表的な例であり, Authenticator の出力する鍵が Authenticator Secret と異なる場合, その出力された鍵は一般的に short-term authentication secret である.

Authenticator

Claimant が所有および管理するもので, 典型的な例としては暗号モジュールやパスワード等がある. Authenticator は Claimant の Identity を認証するために用いられる. SP 800-63 の前リビジョンにおいて token と呼ばれていたものと同等である.

Authenticator Assurance Level (AAL)

Claimant が Subscriber の Authenticator を管理していることを証明する Authentication プロセスの頑健性を示す指標.

Authenticator Secret

Authenticator に内含される鍵.

Authenticity

データが意図された情報源から得られたものであるという性質.

Biometrics

個人の行動や生体情報をもとに個人を自動認証すること.

本ドキュメントでは, Biometrics は Authenticator のアンロックや登録の否認防止目的で用いられることもある.

Claimant

1つ以上の Authentication Protocol により Identity を検証される主体.

Claimed Identity

Applicant により申告された Unvalidated かつ Unverified な Personal Attributes.

Credential

ある Identity (および付加的属性) を (Identifier を通じて) Subscriber が所有ないしは管理する Authenticator に紐付ける信頼の置けるオブジェクトもしくはデータ構造.

一般的に Credential は Subscriber に管理されることが想定されるが, 本ドキュメントでは Subscriber の Authenticator と Identity の紐付けを確立する CSP 管理下の電子レコードを指すこともある.

Credential Service Provider (CSP)

Subscriber の Authenticator を発行もしくは登録し, Subscriber に電子的な Credential を発行する信頼された主体. CSP は自身が運営する Registration Authorities (RAs) および Verifier を内包することもある. CSP は独立した第三者となることもあれば, 自身で発行した Credential を用いて自らサービスを提供することもある.

Cryptographic Key

復号, 暗号化, 署名生成, 署名検証等の暗号論的オペレーションを管理するために用いられる値. 本ドキュメントでは, NIST SP 800-57 Part 1 の Table 2 で述べられた最低限の要件を満たすものとする.

Asymmetric keys および Symmetric key も参照のこと.

Cryptographic Authenticator

Cryptographic Key を利用する Authenticator.

Digital Authentication

情報システムに対して, デジタル表現されたユーザーの Identity の確からしさを確立するプロセス. SP 800-63 では以前まで Electronic Authentication と呼ばれていたもの.

Digital Signature

秘密鍵を用いてデータに電子署名を行い, 公開鍵を用いて署名検証を行う, Asymmetric Key を用いたオペレーション. Digital Signature は Authenticity Protection (真正性), Integrity Protection (完全性), Non-Repudication (否認防止) を提供するが, Confidentiality Protection (機密性) は提供しない.

Electronic Authentication (E-Authentication)

Digital Authentication 参照.

Federal Information Security Management Act (FISMA)

E-Government Act の Title III に規定されている. FISMA は, 各政府機関に対して, 当該機関のオペレーションおよびアセットを支える情報および情報システムにおける情報セキュリティを確保する機関全体を通したプログラムの開発, 記録, 実装を要求する. ここで保護対象となる情報および情報システムには, 他の機関や受託業者などに提供および管理されるものも含む.

Federal Information Processing Standard (FIPS)

Information Technology Management Reform Act (Public Law 104-106) のもとで, Secretary of Commerce は National Institute of Standards and Technology (NIST) が連邦のコンピューターシステムのために作成した標準およびガイドラインを承認する. これらの標準およびガイドラインは, NIST によって Federal Information Processing Standards (FIPS) として発行され, 政府全体で利用される. NIST は, 連邦政府がセキュリティや相互運用性に対する必要性を持っており, 利用可能な業界標準やソリューションが存在しない場合に, FISP を作成する.

FISP ドキュメントは FISP ホームページからオンラインで閲覧可能である. : http://www.nist.gov/itl/fips.cfm

Federation

一連のネットワークシステム間で Identity および認証情報の伝搬を行うためのプロセス.

Federation Assurance Level

Federation において, 認証情報および属性情報を Relying Party に送る際に用いられる Assertion Protocol の頑健性を示す指標.

Identity

特定のコンテキストにおいてある人物を他と区別できるかたちで表現する属性の集合.

Identity Assurance Level (IAL)

Applicant の Claimed Identity が本人の本物の Identity であることの確からしさの度合いをあらわす指標.

Identity Proofing

CSP および Registration Authority (RA) が, Credential 発行のためにある人物に関する情報を収集および検証するプロセス.

Memorized Secret

Subscriber に記憶されることを前提とした, 文字列からなる Authenticator. Subscriber が Authentication Process において something they know を立証するために利用できる.

Multi-Factor

2つ以上の Authentication Factor を要求する認証システムや Authenticator の特徴. Multi-Factor Authentication には, 1つ以上の要素を提供する単一の Authenticator を用いてもよいし, 異なる要素となる複数の Authenticator を組み合わせて用いてもよい.

Authentication Factor としては, Something You Know, Something You Have, Something You Are の3種類がある.

Network

オープンなコミュニケーションの伝達手段. Internet がその代表例である. Network は Claimant とその他の主体の間でメッセージを伝達するために用いられる. 特に明示されない限り, Network のセキュリティは前提とされず, オープンであり, 任意の主体 (Claimant, Verifier, CSP および RP) 間の任意の点において自発的な攻撃 (なりすまし, Man-in-the-Middle, Session Hijacking 等) や受動的な攻撃 (盗聴等) にさらされうるものと想定される.

Password

Memoized Secret の一種. 場合によっては文字列長や文字種に制限があることもある.

Personal Identification Number (PIN)

10進数の数値のみで構成された Memoized Secret.

Personally Identifiable Information (PII)

OMB Circular [A-130] で定義されているように, Personally Identifiable Information とは個人の Identity を識別したり追跡するために用いられる情報である. 単体の情報で個人を識別・追跡可能なものもあれば, 特定の個人に紐付け済もしくは紐付け可能なその他の情報と組み合わせることで識別・追跡可能となるものもある.

Private Key

Asymmetric Key ペアの秘密鍵. データへの署名生成や復号に用いられる.

Pseudonymous Identifier

RP による Subscriber の推測を許さず, かつ RP が複数のインタラクションに渡って Subscriber の Claimed Identity を紐づけられるような, 意味のないユニークな識別子.

Public Key

Asymmetric Key ペアの公開鍵. データへの署名検証や暗号化に用いられる.

Public Key Certificate

Certificate Authority によって発行され, Certificate Authority の秘密鍵でデジタル署名された電子文書. Public Key Certificate により Subscriber の Identifier が Public Key と紐づけられる. 当該 Certificate により識別される Subscriber のみが Private Key の管理およびアクセス権限を持っていることが暗示される. [RFC 5280] も参照のこと.

Public Key Infrastructure (PKI)

Certificate と Public-Private Key Pair を管理する目的で利用される, 一連のポリシー, プロセス, サーバープラットフォーム, ソフトウェア, ワークステーションなど. Public Key Certificate の発行, 管理, 失効を行う能力を備える.

Registration

Applicant が CSP の Subscriber となるべく申請し, CSP が Applicant の Identity を確認する一連のプロセス.

Relying Party (RP)

Subscriber の Authenticator および Credential, Verifier の Claimant Identity に関する Assertion を信頼して, トランザクションを処理したり情報やシステムへのアクセスを許可したりする主体.

Remote

(Remote Authentication や Remote Transaction といったコンテキストで) 単一組織によるセキュリティ対策のみでは End-to-End での確実な保護が期待できないような状況下での, ネットワーク接続されたデバイス間の情報交換.

注) Internet を介した情報交換はすべて Remote とみなされる.

Risk Assessment

システムセキュリティに対するリスクを特定した上で, その発生確率やもたらされる影響を判定し, その影響を軽減する追加の保護策を決定していくプロセス. Risk Assessment は Risk Management の一部であり, Risk Analysis と同義である.

Shared Secret

Subscriber と Verifier が知っている, Authentication で使われる鍵.

Special Publication (SP)

NIST が発行する出版物の一形態. 特に Special Publication 800 シリーズは, Information Technology Laboratory による研究活動, ガイドライン, コンピュターセキュリティ分野における公共福祉のための支援活動, 民間・政府・学術組織との協調的な活動などに関するレポートとなっている.

Subscriber

CSP から Credential や Authenticator を受け取る主体.

Symmetric Key

暗号化と復号, メッセージ認証コードの生成と検証などの, 対となる暗号論的オペレーションの両方で用いられる暗号論的な鍵.

Token

Authenticator の定義を参照のこと.

Valid

ある ID (身分証明書) について, それが期限切れや失効していないこと.

Verifier

Claimant の Identity を検証する主体. Claimant Identity の検証は, Authentication Protocol により Claimant が1つ以上の Authenticator を所持・管理していることを検証することで行われる. Verifier は Authenticator と Subscriber の Identifier を紐付ける Credential を確認し, それらの状態を確認する必要があることもある.

4. Digital Authentication Model

4.1. Overview

OMB M-04-04 にあるとおり, Digital Authentication はある Digital System に提示された個人の Identity に対して確信を得るプロセスである. 各システムは Authenticated Identity を元に, 当該個人が当該オンライントランザクションを実行する権限を持っているかどうかを判断する. 多くの場合, Authentication およびトランザクションは Internet のようなオープンネットワーク上で実施されるが, ネットワークアクセスが制限されており, その制限を考慮したアクセスコントロールがなされる場合もある.

本ガイドラインにおける Digital Authentication Model は, 政府機関で現在用いられている技術およびアーキテクチャを反映したものになっている. Credential の発行と Attribute の提供が異なる主体によって行われるなど, 複数の主体に機能が分離されたより複雑なモデルも考えられ, ある種のアプリケーションではそういったモデルを採用するメリットがあるだろう. 本ドキュメントではシンプルなモデルを扱うが, これは決して各機関が機能分離モデルの採用を排除するものではない. また, 本来 Credential Service Provider (CSP) が実施する登録, Identity Proofing, 発行プロセスにおいても, それらのプロセスが Registration Authority (RA) や Identity Manager (IM) と呼ばれる主体に移譲されることもある. 通常は RA/IM と CSP の間には強い関連性があるが, これらの関連の性質は個々のケースで異なり得る. RA/IM と CSP の関連性やその要件については本ドキュメントのスコープ外とする. 以降では, CSP は RA/IM の機能を含むものとして進める.

Digital Authentication は登録のフェーズから開始される. 一般的な登録プロセスは次のような手順となる. Applicant が CSP に登録申請を行う. 申請が認められると, CSP は Credential を生成し, それを1つ以上の Authenticator に紐付ける. Credential には Identifier (仮名可) が含まれており, CSP が検証した1つ以上の属性が含まれることもある. Authenticator は CSP が発行することもあれば, Subscriber が直接生成・提示することもあり, 3rd-party が提供することもある. Authenticator と Credential はそれ以降の Authentication Event で用いられる.

Applicant が彼らの実世界の Identity と紐付いていることを検証するプロセスが Identity Proofing である. Identity Proofing の強度は Identity Assurance Level (IAL) としてカテゴライズされている. IAL1 では Identity Proofing は要求されない. IAL2 および IAL3 では Identity Proofing が要求されるが, CSP は検証済の属性値や Claim, 仮名等をアサートしても良いし, 何もアサートしなくてもよい. これらの情報は, Relying Party (RP) がアクセスコントロールや認可判断を行うときに有用である. RP は彼らが必要とする IAL を2ないし3とした上で, 特定の属性のみを必要とすることもあり, また当該個人を特定しない程度の属性のみを必要とすることもある. こういったケースでは必要な属性のみを要求することでプライバシーを高めることができるが, これは Proofing Process の強度を Authentication Process の強度と分離して定義したことで得られたメリットの1つである. RP は Identity Proofing, Attribute Collection, Attribute Storage をすべて CSP にゆだねる Federated Identity というアプローチをとることもできる.

本ドキュメント群では, 認証される主体を Claimant, Identity を検証する主体を Verifier と呼ぶ. Authentication Protocol を通じて Claimant が1つ以上の Authenticator を所有および管理していることを Verifier に示すことで, Verifier は Claimant が正規の Subscriber であることを検証できる. その後 Verifier は Subscriber に関する Assertion を RP に送る. Subscriber は仮名 (Pseudonymous) な場合もあれば仮名でない場合もある. 当該 Assertion は Subscriber の識別子を含むと同時に, 氏名や登録時に検証されたその他の属性といった Identity 情報を含むこともある. (詳細は CSP のポリシーとアプリケーションのニーズに依存する) Verifier が RP をかねる場合, Assertion は Implicit なこともある. RP は Verifier が提供した Authenticated Information をもとに, Access Control や Authorization Decision を行うことができる.

Authentication は Claimant Identity の確からしさを確立し, 場合によっては Claimant Attributes に関しても確からしさを確立する. (例えば, Subscriber が US Citizen であるとか, 特定の大学の学生であるとか, ある機関や組織から特定の番号やコードを割り振られているなど) Authentication は Claimant が認可されているかやアクセス権を持つかなどを判断するものではなく, それらはまた別の話である. RP (例: 政府機関) は Subscriber の Authenticated Identity および Attributes をもとに, その他の要素も含めて, Access Control や Authorization Decision を行う. 本ドキュメント群は RP が Subscriber を認証した後に追加の情報を要求することを禁止するものではない.

Authentication Process の強度は Authenticator Assurance Level (AAL) として記述される. AAL1 は Single-factor Authencitacion を要求し, 多様な Authenticator の利用を認めている. AAL2 は AAL1 に加えて2つ目の Authentication Factor を要求している. もっともレベルの高い AAL3 では, AAL2 の片方の Factor として, ハードウェアベースの Authenticator の利用を要求している.

Authentication の一環として, Device Identity や Geo-location などのメカニズムを利用し, 誤判定を検知 / 防止することもある. これらのメカニズムは Authenticator Assurance Level を直接引き上げるものではないが, Security Policy やリスク逓減策として利用できる. 多くの場合, Authentication Process および Authentication Service は多くのアプリケーションや機関に共有されることになるが, 特定のアプリケーションの要件に基づいてアクセス許可やトランザクション実施の判断を行うのは, RP となる個々の機関やアプリケーションである.

Figure 4-1 は, Digital Authentication Model に関与する多様な主体およびそれらの間のインタラクションを描いている. 左側は登録, Credential 発行, Lifecycle Management, 個人が Identity Proofing および Authentication の各フェーズで取りうるステータスを示している. 一般的には以下のような一連のインタラクションが行われる.

1. 個人 (Applicant) が登録プロセスを通じて CSP に申し込みを行う.
2. CSP は Applicant に対して Identity Proofing を行い, Proofing が成功すれば Applicant は Subscriber となる.
3. CSP と新規 Subscriber の間で, Authenticator およびそれに対応する Credential が確立される.
4. CSP は (最低限) 当該 Credential 自体, 当該 Credential のステータス, 当該 Credential が有効な間に登録されたデータを管理する. Subscriber は自身の Authenticator を管理する.

これ以外のフローは上記ほど一般的ではないであろうが, 同じ要件を満たす別のやり方も存在しうる.

Figure 4-1 の右側は, Authenticator を利用して Digital Authentication を行う各主体およびそれらの間でのインタラクションを描いている. トランザクション実施のために　Subscriber の認証が必要な時には, Subscriber は Verifier に対する Claimant となり, 以下のようなインタラクションを行うことになる.

1. Claimant は自身の Authenticator を所有および管理していることを Authentication Protocol を通じて Verifier に示す.
2. Verifier や CSP とインタラクションをおこない, Subscriber Identity と Authenticator を紐付ける Credential の検証を行う. また同時に CSP から Claimant の属性を取得することもある.
3. Federated Identity Architecture においては, CSP / Verifier は RP に対して Subscriber に関する Assertion を提供する. RP は Assertion に含まれる情報を使って Access Control や Authorization Decision を行う.
4. Subscriber と RP の間で認証済セッションが確立される.

いかなる場合でも, RP は Claimant の認証前に必要な属性を CSP に要求するべきである. また Claimant は, Assertion の生成・提供前に, それらの属性提供に対する同意を求められるべきである.

場合によっては, Verifier は CSP とリアルタイムにコミュニケーションを行う必要がないこともある. (例: デジタル証明書を利用する場合など) したがって Verifier と CSP の間の点線は, それら2つの主体の間の (物理的というより) 論理的なリンクを示すものである. 実装によっては Verifier, RP, CSP は Figure 4-1 のようにそれぞれ分離・独立していることもあるが, それらが同じプラットフォーム上にある場合, それらの要素間のインタラクションは (Untrusted Network を介したやりとりではなく) 同じシステム上のアプリケーション間のローカルメッセージとなる.

前述の通り, CSP は自身が発行した Credential のステータスを管理する. 一般的に CSP は Credential の管理期間を限定するため Credential 発行時にその有効期限を定める. ステータスが変更されたり Credential が有効期限切れに近づくと, Credential は更新されたり再発行されることもあれば, 無効化されたり破棄されることもある. 典型的には, Subscriber が自身の既存かつ有効期限切れでない Authenticator および Credential を使って CSP に対して認証を行い, 新規 Authenticator および Credential の発行を要求することになる. Subscriber が Authenticator および Credential の期限切れないし無効化前に再発行できなかった場合は, 登録プロセスをやり直して新規 Authenticator や Credential を取得することになる場合もある. 場合によっては CSP が有効期限切れから一定期間は再発行リクエストを受け入れることもある.

4.2. Enrollment and Identity Proofing

基準となる要件は Special Publication 800-63A Enrollment and Identity Proofing を参照のこと.

前セクションでは Digital Authentication Model に登場する複数の主体が登場した. 本セクションでは, それら各主体のうち, 登録および Identity Proofing に関与する主体間の関連や責任分担について詳細にまとめる.

個人はこのステージでは Applicant と呼ばれ, CSP に対して Credential 発行を要求する. Applicant が Identity Proofing に成功すると, CSP は Credential を発行し, Authenticator を当該 Credential に紐づけ, それをもって当該個人は CSP の Subscriber となる.

CSP は各 Subscriber をユニークに識別するメカニズムを確立し, Subscriber の Credential を登録し, Subscriber に発行された Authenticator を監視する. Subscriber が登録時に Authenticator を受け取ることもあれば, Subscriber がすでに所有している Authenticator を CSP が紐付けることもあり, あとで必要になった段階で Authenticator を生成することもある. Subscriber は自身の Authenticator を管理し, CSP に対する自身の責任を果たす義務を負う. CSP は各 Subscriber の登録レコードを管理し, リカバリなどに対応する.

4.3. Authentication and Lifecycle Management

基準となる要件は Special Publication 800-63B Authentication and Lifecycle Management を参照のこと.

4.3.1. Authenticators

Authentication System における古典的なパラダイムでは, Authentication の基礎となる以下の3つの要素が存在する.

• Something you know (for example, a password)
• Something you have (for example, an ID badge or a cryptographic key)
• Something you are (for example, a fingerprint or other biometric data)

Multi-factor Authentication では上記から2つ以上の要素を利用することになる. Authentication System の強度は大枠としてそのシステムに組み込まれた認証要素数によって決まる. 2つの異なる要素を利用した実装は1要素のみの場合より強度が高いと考えられ, 3要素すべてを利用する場合はより強度が高いと考えられる. Section 5.1 で述べるように, RP や Verifier が位置情報や Device Identity などのその他の情報を利用して Claimed Identity に関するリスク評価を行うこともあるが, それらは認証要素とはみなされない.

Digital Authentication において, Claimant は CSP に登録された1つ以上の Authenticator を所有・管理し, 自身の Identity を証明する. Authenticator は Claimant が自身を正規の Subscriber であることを証明するための鍵を含み, Claimant はネットワーク越しに Authenticator を所有・管理していることを示すことで認証を行う.

Authenticator に含まれる鍵は公開鍵ペア (Asymmetric Keys) ないしは共通鍵 (Symmetric Keys) に基づいている. 公開鍵ペアは公開鍵 (Public Key) およびそれと関連付けられた秘密鍵 (Private Key) から構成され, Private Key は Authenticator 内に保存され Claimant が Authenticator を所有・管理していることを示すために用いられる. 何らかの Credential (典型的には Public Key Certificate) を通じて Claimant の Public Key を知っている Verifier は, Claimant が Private Key を含んだ Authenticator を所有・管理していることを確認することで, Authentication Protocol を通じて Claimant Identity を検証することができる.

Authenticator に共通鍵を保存する場合には, その共通鍵は Symmetric Key ないしは Memoized Secret (Password や PIN 等) となる. 上述の Asymmetric Secret の例と異なり, Subscriber は共通鍵を認証者と共有する必要がある. Symmetric Key も Password もどちらも類似プロトコルで利用することができるが, 両者はそれらがどのように Subscriber と関連付けられるかという点で異なる. Symmetric Key は一般的には Subscriber が管理するハードウェアないしソフトウェア内に保存されるが, Password は Subscriber に記憶されることが想定される. 多くのユーザーは記憶および入力を容易にするため短い Password を選ぶため, Password は Cryptographic Key よりも短い文字列となる. さらにいえば, システムは Symmetric Key をランダムに生成する一方, ユーザーは記憶できる Password を可能な文字列のごく小さなサブセット内から選択し, その多くが似た値となる傾向がある. したがって, Cryptographic Key がネットワーク越しの推測攻撃に対して強固な一方で, ユーザーが選択した Password は (特にその他の防御策がない場合) 脆弱になりやすい.

本ドキュメントでは, Authenticator は常に鍵を含む. 古典的認証要素の中には Digital Authentication に直接適用できないものもある. 例えば ID バッジは Something You Have の一種であり対面認証時には有用であるが, Digital Authentication における Authenticator とはならない. Something You Know に分類される認証要素は必ずしも鍵である必要はなく, Knowledge Based Authentication では Claimant が公開されたデータソースを用いて確認できるような質問に答えることで認証を行うが, そういった認証要素も Digital Authentication で利用できる鍵とはならない. また一般的に Something You Are に属するものは鍵とはいえない. したがって本ガイドラインでは Biometrics を Authenticator として利用することは許可しない.

しかしながら本ガイドラインでは, 上記3要素すべてを用いた Authentication System が2要素のみを利用している場合よりセキュアであるということは認める. 複数要素を用いる Digital Authentication System は, 複数要素を Verifier に提示する形式か, Verifier に提示するための鍵を保護するためにいずれかの要素を用いる形式のいずれかを取りうる. 複数要素を Verifier に提示する場合は, 各要素が Authenticator となり, それぞれが鍵を含むことになる. 単一要素を Verifier に提示し, 追加要素を Authenticator 自体の保護に用いる場合には, 追加要素自体は Authenticator でなくてもよい.

例えば Cryptographic Key を含んだハードウェア (Authenticator) を指紋認証により保護するなどの例が考えられる. Biometrics とともに利用する場合, Cryptographic Key の出力が Claimant の Authentication Process に用いられることとなる. その場合, Subscriber になりすまそうとする攻撃者は, 鍵が保存されたハードウェアを盗むなどの手段によって暗号化された鍵を盗み, その Authenticator を利用するために指紋認証を突破する必要がある. 本ドキュメントでは, 実際の Authentication Protocol 上は Verifier と Claimant の間の単純な鍵所有確認だとしても, そういったデバイスは効率的に2要素認証を提供するものと考える.

上述のように, Biometrics は単一の認証要素として用いる場合には Digital Authentication で利用可能な鍵とはみなされないが, 特定の使い方をすれば本仕様の枠組みのなかで利用することもできる. Biometrics は, Verification の時点で物理的にその場にいた人間の Identity 検証に用いることができる, ユニークに個人を特定する属性である. 顔認証, 指紋認証, 虹彩認証, 声紋認証などが Biometrics に含まれる. Special Publication 800-63A Enrollment and Identity Proofing では, 登録プロセスにおける Biometrics の利用を推奨している. 登録時に Biometrics を利用することで, Subscriber による登録の否認を防止する一助となったり, 登録において詐欺行為を行った人物を特定したりすることもできるし, Authenticator を Unlock することもできる. これらにより各 Assurance Level を向上することもできる.

4.3.2. Credentials

前述のように, Credential はその発行プロセスにおいて Authenticator を Identifier を通じて Subscriber に紐付けるものとなる. Credential は CSP に保管・管理される. Claimant は Authenticator を所有するが, 必ずしも電子的な Credential を所有する必要はない. 例えばユーザー属性を含む Database Entry は本ドキュメントが目的とするケースにおいては Credential とみなされるが, これは Verifier に所有されるものである. X.509 Public Key Certificate は Claimant が所有する Credential としての古典的な例である.

4.3.3. Authentication Process

Authentication Process は, Authentication Protocol を通じて, Claimant が Verifier に対して Asserted Identity に紐づけらた Authenticator を所有・管理していることを示すところから始まる. 一度それが証明されると, Verifier は当該 Credential がまだ Valid であることを検証する. この検証には往々にして Verifier と CSP とのインタラクションが伴う.

Authentication Protocol における Verifier と Claimant の間のインタラクションは, システム全体のセキュリティにとっても非常に重要である. よくデザインされたプロトコルでは, Claimant と Verifier の間のトラフィックは認証時も認証後も Integrity および Confidentiality が保護されており, 攻撃者が正規の Verifier になりすました場合でもその被害を限定的にすることができる.

また Verifier 側では, パスワードや PIN などのエントロピーの低い鍵に対するオンライン推測攻撃への対策を行うこともできる. オンライン推測攻撃対策としては, Rate Limit を設ける方法や, 間違ったリクエストに対する Delay 処理を行うなどの方法があげられる. 一般化すると, これらは間違った施行の回数を監視および制限することで実現できる. オンライン推測攻撃はその前提としてほとんどの施行が失敗するからである.

Verifier は機能的には独立した役割であるものの, しばしば CSP and/or RP の一部として実装される傾向にある. Verifier が CSP から独立した主体である場合, Verifier は Subscriber の Authenticator Secret を Authentication Process を通じて知ることがないと保証されることが望ましい. 最低限 Verifier が CSP の保有する鍵に制限なくアクセスできる状態は避けること.

4.4. Federation and Assertions

基準となる要件は Special Publication 800-63C, Federation and Assertions を参照のこと.

全体的に SP 800-63-3 は Federated Identity Architecture を前提とはしない. 本ガイドラインは市場にある既存のモデルにはとらわれず, 各機関が Digital Authentication Scheme を自身の要件に合わせて採用できるようにしている. しかしながら National Strategy for Trusted Identities in Cyberspace (NSTIC) [NSTIC] とも整合をとり, Identity Federation は各機関および RP が個別にサイロ化した Identity System を持つ状況よりも好ましいものとしている.

Federated Architecture は以下のような重要な利点をもたらす. (以下に挙げたものに限定はしない)

• User Experience の向上. 例えばひとたび Identity Proofing を経た個人が, 同じ Credential を複数の RP に対して再利用することができる.
• コスト削減. ユーザーにとっては Authenticator の削減, 各機関にとっては IT インフラの削減.
• データ最小化. 各機関は個人情報の保存にかかる各種データ収集・保管・破棄およびコンプライアンス準拠活動を必要としない.
• Privacy 向上.
• Pseudonymous Attribute Assertion. 各機関はサービス提供のために必要最低限の Claim を含む属性のみをリクエストすることができる.
• Misson Enablement. 各機関は Identity Management にかかる負荷を軽減し, 各々のミッションに集中できる.

以降のセクションでは Federated Identity Architecture の各要素について議論する.

4.4.1 Assertions

Authentication Process が完了すると, Verifier は認証結果を含む Assertion を生成し, それを RP に提示する. Verifier が RP の一部として実装されている場合, この Assertion は Implicit である. Verifier が RP と分離して実装されている場合, それは典型的な Federated Identity モデルであり, Verifier から RP に認証プロセスの結果を伝搬するために Assertion が利用される. また同時に Subscriber に関する追加の情報も Assertion によって伝搬されることもある. Assertion は RP に直接渡されることもあれば, Subscriber を通じて伝搬されることもあるが, それはシステムデザインに密接に関係する.

RP は Assertion の生成者, 生成日時, および CSP および RP のポリシーおよびプロセスを管轄する Trust Framework の存在などをもとに Assertion を信頼する. Verifier は Assertion の Integrity を確認できる仕組みを提供する責任がある.

RP は Assertion 生成者 (Verifier) を認証し, Assertion の Integrity を確認する責任がある. Verifier が Subscriber を介して Assertion を伝搬してくる場合には, Verifier は Subscriber が Assertion を改ざんできないよう Integrity の保護を行う必要がある. Verifier と RP が直接通信を行う場合は, 保護されたセッションをもって Integrity Protection とすることもできる. Assertion をオープンなネットワークを介して送る場合, Verifier は Assertion に含まれる Subscriber に関するセンシティブな情報の Confidentiality を確保して信頼できる RP にのみ当該情報が受け取れるようにする責任がある.

Assertion の例としては以下のようなものがあげられる.

• SAML Assertions - SAML Assertion は Mark-up Language を用いて定義されており, Security Assertion の記述を目的とする. 当該 Assertion は Verifier が RP に対して Claimant の Identity に関する Statement を生成する際に利用できる. SAML Assertion はオプションで電子署名がされる.
• OpenID Connect Claims - OpenID Connect Claims は JavaScript Object Notation (JSON) を用いて Security に関する情報およびオプションで User Claims を記述するよう定義されている. JSON 形式のユーザー情報 Claims はオプションで電子署名がされる.
• Kerberos Tickets - Kerberos Ticket は, Ticket Granting Authority が2つの認証された主体に対してセッションキーを発行する仕組みである. Kerberos では Symmetric Key ベースの秘匿化方式 (Encapsulation Scheme)を用いる.

4.4.2. Relying Parties

RP は Authentication Protocol の結果を信頼し Subscriber の Identity および Attributes の確からしさを確立し, オンライントランザクションを行う. RP は Subscriber の Authenticated Identity (Pseudonymous な場合もあればそうでない場合もある), IAL, AAL and/or FAL およびその他の要素を用いて Access Control や Authorization Decision を行う. Verifier と RP は同じ主体なこともあれば, 相互に独立した主体であることもある. 両者が相互に独立している場合, RP は通常 Verifier から Assertion を受け取り, Assertion が確かに自身が信頼する Verifier から送られてきたことを確認する. RP は Assertion に含まれる個人の属性や有効期限などの追加情報もおなじように処理する. RP は, IAL, AAL, FAL に関係なく, Verifier が提示した Assertion が RP のシステムアクセスに必要な基準を満たすかどうかを最終的に判断する.

5. Determining Levels of Assurance

OMB M-04-04 requires agencies to select transaction or system authentication Level of Assurance (LOA) by conducting a risk assessment to determine the potential impact of an authentication error. In the context of M-04-04, LOA is defined as:

1. The degree of confidence in the vetting process used to establish the identity of the individual to whom the authenticator was issued, and
2. the degree of confidence that the individual who uses the credential is the individual to whom the credential was issued.

Per M-04-04, once an LOA is selected, the agency is required to follow the identity proofing, credentialing, and federation technical requirements specified by NIST at that level. For example, if the impact of an authentication error results in an application assessed at LOA 3, the agency must identity proof and provide authenticators that meet the requirements for LOA 3.

However, in today’s digital services, combining proofing and authenticator requirements into a single bundle sometimes creates unintended consequences as well as putting unneccessary implementation burden upon the implementing entity. It is quite possible that an agency can deliver the most effective set of identity services by assessing the risk and impacts of failures for each individual component of digital authentication, not as a single, all encompassing LOA. An authentication error is not a singleton that drives all requirements. This guideline recommends that agencies meet M-04-04 requirements by separately evaluating the impact that could result from (1) a true authentication error (the wrong individual using someone else’s credential) and (2) an identity proofing error. From the perspective of an identity proofing failure, there are two dimensions of potential risk:

• The impact of providing a service to the wrong person (e.g. an attacker successfully proofs as someone else)
• The impact of excessive identity proofing (i.e. collecting more information about a person than is required to successfully provide the digital service.)

As such, agencies should assess the risk of authentication and proofing errors separately to determine the appropriate technical solutions that should be applied to their system.

5.1. Categories of Assurance Levels

To determine the process and system requirements that reduce the risk of an authentication or identity proofing failure, this guideline introduces distinct categories of assurance which drive the technical solutions an agency may implement. They are:

• Identity Assurance Level (IAL) - the robustness of the identity proofing process to confidently determine the identity of an individual
• Authenticator Assurance Level (AAL) - the robustness of the authentication process itself, and the binding between an authenticator and the identifier of a specific individual.
• Federation Assurance Level (FAL) - the robustness of the assertion protocol utilized by the federation to communicate authentication and attribute information (if applicable) to a relying party. FAL is optional as not all digital systems will leverage federated identity architectures.

A summary of each of the identity, authenticator, and federation assurance levels is provided below.

Identity Assurance Level
IAL1 - At this level, attributes provided in conjunction with the authentication process, if any, are self-asserted.
IAL2 - IAL 2 introduces the need for either remote or in-person identity proofing. IAL 2 requires identifying attributes to have been verified in person or remotely using, at a minimum, the procedures given in SP 800-63A.
IAL3 - At IAL 3, in-person identity proofing is required. Identifying attributes must be verified by an authorized representative of the CSP through examination of physical documentation as described in SP 800-63A.

Authenticator Assurance Level
AAL1 - AAL 1 provides some assurance that the claimant controls the authenticator registered to a subscriber. AAL 1 uses single-factor authentication using a wide range of available authentication technologies. Successful authentication requires that the claimant prove through a secure authentication protocol that he or she possesses and controls the authenticator.
AAL2 – AAL 2 provides high confidence that the claimant controls the authenticator registered to a subscriber. Two different authentication factors are required. Approved cryptographic techniques are required at AAL 2 and above.
AAL3 – AAL 3 provides very high confidence that the claimant controls the authenticator registered to a subscriber. Authentication at AAL 3 is based on proof of possession of a key through a cryptographic protocol. AAL 3 is similar to AAL 2 except that a “hard” cryptographic authenticator that also provides impersonation resistance is required.

Federation Assurance Level
FAL1 - FAL 1 allows for the subscriber to retrieve and present a bearer assertion directly to the relying party (RP) in the front channel. The assertion must be signed with using approved cryptography.
FAL2 - FAL 2 requires the subscriber to retrieve an assertion artifact to present to the RP, which the RP then presents to the CSP to fetch the bearer assertion in the back channel. The assertion must be signed using approved cryptography. Alternatively, if the assertion is presented in the front channel, the assertion is required to be encrypted such that the RP is the only party that can decrypt it.
FAL3 - FAL 3 builds on FAL 2 and adds the requirement that the assertion be encrypted using approved cryptography such that the RP is the only party that can decrypt it.
FAL4 - FAL 4 requires the subscriber to present proof of possession of a cryptographic key referenced in the assertion in addition to the assertion artifact itself. The assertion must be signed using approved cryptography and encrypted to the RP using approved cryptography.

When described generically or bundled, this guideline will refer to the combination of IAL, AAL, and FAL as xAL.

A risk assessment to determine each xAL is recommended. Section 5.3. provides details on how agencies may going about making xAL selections.

5.2. Mapping xAL to M-04-04 Levels of Assurance

This guideline introduces a model where individual xALs can be selected without parity to each other in order to protect a digital service, as opposed to applying a single LOA where all xALs are equal. While options exist to select varying xALs for a system in many instances the same level will be chosen for all xALs. This provides an opportunity to directly map to the LOAs specified in M-04-04. Table 5-1 shows strict adherence to M-04-04 by mapping the corresponding Identity, Authenticator, and Federation Assurance Levels to LOA.

M-04-04 Level of Assurance (LOA)	Identity Assurance Level (IAL)	Authenticator Assurance Level (AAL)	Federation Assurance Level (FAL)
1	1	1	1
2	2	2	2
3	2	2	2
4	3	3	4

Note: LOA2 is now equivalent to LOA3. Higher AALs than specified can always be used.

The ability to combine varying xALs offer significant flexibility to agencies, but not all combinations are possible due to the nature of the data collected from an individual and the authenticators to protect that data. Table 5-2 details valid combinations of IAL and AAL to ensure personal information remains protected by multi-factor authentication.

	IAL 1	IAL 2	IAL 3
AAL 1	Allowed	NO	NO
AAL 2	Allowed	Allowed	See Note
AAL 3	Allowed	Allowed	Allowed

Note: Per Executive Order 13681 [EO 13681], the release of personal information requires protection with multifactor authentication. Therefore, it should not be possible to use an authenticator at a lower assurance level then the IAL. However, depending on the use case, specifically that the transaction that the user authenticates to does not release or manage any personal information, it could be possible for these combinations to exist, though unlikely and not recommended.

5.3. Selecting the Appropriate xAL

Agency mission and risk tolerance should drive the most advantageous selection of xALs to minimize risk. This could include the selection of an IAL that is lower than the selected AAL. For example, an agency may establish a “health tracker” application. In line with the terms of Executive Order 13681 requiring “…that all agencies making personal data accessible to citizens through digital applications require the use of multiple factors of authentication…”, the agency is required to implement multi-factor authentication at AAL 2 or 3. The EO also requires agencies employ “…an effective identity proofing process, as appropriate.” when personal information is released. This does not mean that proofing at IAL 2 or 3 (to match the required AAL) is required for all scenarios when personal information is made available. In the above example, there may be no need for the agency system to know the true identity of the user. Therefore, an effective proofing process would be to not proof at all. In the past, an LOA3 assessment would equate to identity proofing the user at IAL2. This is no longer necessary and the agency is encouraged to not perform any identity proofing and allow the user of the health tracker system to be pseudonymous at IAL1.

Separating IAL and AAL also works for traditional M-04-04 LOA use cases, such as HSPD-12 requirements for federal employees to obtain a Personal Identity Verification (PIV) smart card. The requirement for PIV is that agencies meet LOA4; therefore, an authenticator at AAL3 and identity proofing at IAL 3 sufficiently meets the LOA4 requirements.

Note: An agency can accept a higher assurance level than those required in the table above. For example, in a federated transaction, an agency can accept an IAL3 identity if their application is assessed at IAL2. The same holds true for authenticators; stronger authenticators can be used at RP’s that have lower authenticator requirements. However, RPs will have to ensure that this only occurs in federated scenarios with appropriate privacy protections by the CSP such that only the requested attributes are provided to the RP and that excessive personal information does not leak from the authenticator or the assertion. See privacy requirements in SP 800-63C for more details.

Note: Since agencies are encouraged to consider each distinct element of assurance, the notion of the ‘low watermark’ to determine LOA no longer applies. An IAL1/AAL2 application should not be considered any less secure or privacy enhancing than an IAL2/AAL2 application. The only difference between these applications is the amount of proofing required, which may not impact the security and privacy of each application. That said, if an agency incorrectly determines the xAL, security and privacy could very well be impacted.

5.3.1. Business Process vs. Online Transaction

An online transaction may not equate to a complete business process that requires offline processing, or online processing in a completely segmented system. In selecting the appropriate assurance levels, the agency should assess the risk associated with the online transactions they are offering via the digital service, not the entire business process associated with the provided benefit or service. For example, in an online survey, sensitive personally identifiable information may be collected, but it is never made available online to the person after the information is submitted. In this instance, it is important for the information to be carefully protected in backend systems, but there is no reason to identity proof or even authenticate the user providing the information. The online transaction is solely a submission of the data only. The entire business process may require a significant amount of data validation, without ever needing to know if the correct person submitted the correct information regarding their family. In this scenario, there is no need for any xAL.

Another example where the assessed risk could differ if the agency evaluated the entire business process rather than the online transaction requirements, is a digital service that accepts resumes in order to apply for open job postings. In this use case, the digital service allows any individual to submit a resume on behalf of anyone else, and in subsequent visits to the site, access the resume for various purposes. Since the resume information is provided in later sessions, and is considered personal information, the agency must select an AAL that requires MFA. In this case, the requirements of [EO 13681] apply, driving the AAL to be at least level 2. However, the identity proofing requirements remain unclear. The entire business process of examining a resume and ultimately interviewing a person requires a significant amount of identity proofing. The agency needs a high level of confidence that the job applicant/interviewee is in fact the subject of the resume submitted online if a decision to hire is made. Yet this level of proofing is not required to actually submit the resume online. Identity proofing is not required to complete the digital transaction successfully. The resume could be submitted by the applicant, but may also be submitted by a surrogate. Identity proofing the submitter would create more risk than required in the online system as excess personal information would be collected, such as from the surrogate, when no such information is needed. Therefore, the most appropriate IAL selection would be 1. There is no need to identity proof the user to successfully complete the online transaction, nor is there any potential negative impact as a result of offering the online transaction if a proofing failure occurred. Yet, there would be significant impact if the entire business process failed to correctly identity proof the person - a job may be offered to a fraudulent applicant - but that risk should not be applied holistically to the online system via a higher IAL.

In this use case, it is assumed the system allows surrogates. If the use case is that the only person that can submit is the actual subject of the resume, then identity proofing requirements for the online transaction would be significantly different.

5.3.2. Selecting Authenticator Assurance Level

The AAL decision tree in Figure 5-1 offers agencies a possible path to determine the most appropriate authentication requirements for their digital service offering. This analysis is not intended to substitute M-04-04 risk assessments or any other risk management process in use by the agency. Nor is it expected to cover all the identity service needs of each agencies unique mission. Descriptions follow for specific steps that fall outside the risk management process documented in M-04-04.

The AAL selection does not mean the digital service provider will need to issue authenticators themselves. More information of whether the agency can federate or not is provided in Section 5.4.

5.3.3. Selecting Identity Assurance Level

The IAL decision tree in Figure 5-2 offers agencies a possible path to determine the most appropriate identity proofing requirements for their digital service offering. This analysis is not intended to be a substitute for M-04-04 risk assessments or any other risk management process in use by the agency. Nor is it expected to cover all the identity service needs of each agencies unique mission. Descriptions follow for specific steps that fall outside the required risk management process documented in M-04-04.

The IAL selection does not mean the digital service provider will need to perform the proofing themselves. More information on whether the agency can federate or not is provided in Section 5.4.

5.3.4. Selecting Federation Assurance Level

Coming Soon

5.4. Federation Considerations

The technical guidelines detailed in NIST SP 800-63-3 and its companion volumes are agnostic to the authentication and identity proofing architecture an agency selects. However, there are scenarios an agency may encounter which make identity federation potentially more attractive than establishing identity services local to the agency or individual applications. The following list details the scenarios where an agency may consider federation as a viable option. This list does not factor in any economic benefits or weaknesses of federation vs. localized identity architectures.

Federate Authenticators:

• Potential users already have an authenticator at or above required AAL
• Multiple credential form factors are required to cover all possible user communities
• Agency does not have infrastructure to support authentication management (e.g., account recovery, authenticator issuance, help desk)

Federate Attributes:

• Pseudonymity is important to stakeholders accessing the service
• Access to the service only requires a partial attribute list
• Access to the service only requires at least one attribute claim
• Agency is not the authoritative source or issuing source for required attributes
• Attributes are only required temporarily during use (such as to make an access decision), such that agency does not need to locally persist the data

6. References

[EO 13681] Executive Order 13681, Improving the Security of Consumer Financial Transactions (October 17, 2014), available at: https://www.whitehouse.gov/the-press-office/2014/10/17/executive-order-improving-security-consumer-financial-transactions.

[M-04-04] OMB Memorandum M-04-04, E-Authentication Guidance for Federal Agencies (December 16, 2003), available at: https://www.whitehouse.gov/sites/default/files/omb/memoranda/fy04/m04-04.pdf.

[NSTIC] National Strategy for Trusted Identities in Cyberspace (April, 2011), available at: https://www.whitehouse.gov/sites/default/files/rss_viewer/NSTICstrategy_041511.pdf.

[DOJ 2000] Guide to Federal Agencies on Implementing Electronic Processes (November 2000), available at: http://www.usdoj.gov/criminal/cybercrime/ecommerce.html URL not found; obsolete document?

[ESIG] Federal CIO Council, Use of Electronic Signatures in Federal Organization Transactions (January 25, 2013), available at: https://cio.gov/wp-content/uploads/downloads/2014/03/Use_of_ESignatures_in_Federal_Agency_Transactions_v1-0_20130125.pdf

[FISMA] Federal Information Security Management Act, available at: http://csrc.nist.gov/drivers/documents/FISMA-final.pdf

[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: http://www.whitehouse.gov/omb/memoranda/m03-22.html.

<a name-“A-130”></a>[A-130] OMB Circular A-130, Managing Federal Information as a Strategic Resource (July 28, 2016), available at: https://www.whitehouse.gov/omb/circulars_default

[SP 800-30] NIST Special Publication 800-30, Guide for Conducting Risk Assessments (September 2012), available at: http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-30r1.pdf.

[SP 800-37] NIST Special Publication 800-37, Guide for Applying the Risk Management Framework to Federal Information Systems, A Security Life Cycle Approach (February 2010), available at: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-37r1.pdf.

[SP 800-53A] NIST Special Publication 800-53A, Assessing Security and Privacy Controls in Federal Information Systems and Organizations, Building Effective Assessment Plans (December 2014), available at: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53Ar4.pdf.

[GPG 45] UK Cabinet Office, Good Practice Guide 45, Identity proofing and verification of an individual, November 3, 2014, available at: https://www.gov.uk/government/publications/identity-proofing-and-verification-of-an-individual.

[RSDOPS] UK Cabinet Office, Good Practice Guide 43, Requirements for Secure Delivery of Online Public Services (RSDOPS), November 3, 2014, available at: https://www.gov.uk/government/publications/requirements-for-secure-delivery-of-online-public-services.

[STORK 2.0] European Union, Secure idenTity acrOss boRders linKed 2.0, 2014, available at: https://www.eid-stork2.eu/.

[ISO 29115] International Standards Organization, ISO/IEC 29115 Information technology – Security techniques – Entity authentication assurance framework, April 1, 2013, available from http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=45138

[ISO 29003] International Standards Organization, ISO/IEC DIS 29003 Information technology – Security techniques – Identity proofing (under development)

[Canada] Government of Canada, Standard on Identity and Credential Assurance, February 1, 2013, available at: https://www.tbs-sct.gc.ca/pol/doc-eng.aspx?id=26776