NIST SP 800-63C-4(Draft) 確認してみた
こんにちは、さみーです。
前回のNIST SP 800-63A-4(Draft) 確認してみたに引き続き、ざっくり 63C の 変更点 を確認してみました。
63C-4(Draft) の Change Log
NIST SP 800-63C-4(Draft) の Change Log には、下記の10点が挙げられていました。（勝手に意訳＆短縮してます）
「文言の更新」以外はそれぞれ、以降で詳細確認していきます。
- 公平性に関する要件追加
- 信頼の合意(trust agreement)と登録のステップを確立
- すべての FAL に信頼の合意(trust agreement)の形成と登録に関する要件を設定
- FAL の定義から暗号化要件を撤廃
- FAL2 でインジェクション保護が必須化
- FAL3 でより一般的な bound authenticatorが許容
- IAL/AAL/FALの伝達の必須化
- 文言の更新
- RP加入者アカウントを追加
- 属性プロビジョニングモデルの追加
NIST SP 800-63C-4(Draft) Change Log の 原文
- Added discussion of equity considerations and requirements.
- Established trust agreements and registration as discrete steps in the federation process.
- All FALs have requirements around establishment of trust agreements and registration.
- FAL definitions no longer have encryption requirements; encryption is triggered by passing PII in an assertion through an untrusted party regardless of FAL.
- FAL2 requires injection protection.
- FAL3 allows more general bound authenticators including RP-managed authenticators, in addition to classical holder-of-key.
- Communication of IAL/AAL/FAL required.
- Updated language to be more inclusive.
- Added definition and discussion of RP subscriber accounts.
- Added attribute provisioning models and discussion.
1. 公平性に関する要件追加
Change Log 中の下記についてです。
Added discussion of equity considerations and requirements.
「公平性(equity)に関する考慮事項と要件の追加」とのことで、11. 公平性の考慮事項 (Equity Considerations) がまるまる新規内容として追加されています。
公平性に関する内容は revision4 全体通して追加されていますが、63C-4ではフェデレーションを使った場合に生じる可能性のある点が挙げられています。
revision3の発行以降、2021年1月25日に大統領令 13985 Advancing Racial Equity and Support for Underserved Communities Through the Federal Government が発行されているので、それに伴って内容が追加されたのだと思われます。
なお、NIST SP 800-63はあくまで、米国の 政府機関 におけるデジタルアイデンティティの技術要件です。
民間サービスが同様に公平でなければならないということではない点は、参照する上で注意するのがよさそうです。
2. 信頼の合意(trust agreement)と登録のステップを確立
Change Log 中の下記についてです。
Established trust agreements and registration as discrete steps in the federation process.
「フェデレーションプロセスの個別のステップとして信頼の合意(trust agreement)と登録を確立」とのことで、5. Federation にてフェデレーションのプロセスが記載されており、それぞれ 5.1. 信頼の合意 (Trust Agreements)、5.2. 登録 (Registration) に詳細があります。
「信頼の合意(trust agreement)」とは、IdPとRPがフェデレーションすることを相互に合意しなければならない、といったもので、下記の項目を事前に合意しておく必要があると明記されています。
- IdP が RP へ提示できる属性のセット
- IdP がアサーションを作成できる加入者(subscriber)アカウントの集合
- RP が要求する属性のセット (利用可能な属性のサブセット)
- RP によって要求された各属性の利用目的
- 加入者(subscriber)の属性の提供に関する決定に責任を負う authorized party
- RP への属性提供について加入者(subscriber)に通知する手段
- IdP が提供可能な xAL
- RP が必要とする xAL
2者間での合意、federation authority を介した多者間の合意、いずれで行っても良く、IdPとRP間で事前に合意形成しておく Static な方法とユーザーがログインしようとした際に Dynamic に合意が形成される方法とがあるものの、Static / Dynamic はFALによって可能な方法に制約があります。
「登録」とは、フェデレーションで利用されるアサーションの検証に必要な、識別子や鍵情報、エンドポイントURLなどプロトコル固有で必要な各情報をIdPとRPの間で交換することで、こちらも事前に交換しておく Static な方法、初めてフェデレーションを行う際に登録する Dynamic な方法があるものの、FALによって可能な方法に制約があります。
3. すべての FAL に信頼の合意(trust agreement)の形成と登録に関する要件を設定
Change Log 中の下記についてです。
Established trust agreements and registration as discrete steps in the federation process.
All FALs have requirements around establishment of trust agreements and registration.
「すべての FAL に信頼の合意(trust agreement)の形成と登録に関する要件を設定」とのことで、4. Federation Assurance Level (FAL) の冒頭に説明や要件の記載があります。
63C-3 でのFALのレベル分けはとてもあっさりしていて下記の通りだったのですが、
| FAL | Requirement |
|---|---|
| 1 | Beare assertion, signed by IdP. |
| 2 | Beare assertion, signed by IdP and encrypted to RP. |
| 3 | Holder of key assertion, signed by IdP and encrypted to RP. |
63C-4 でのFALは、さらに「信頼の合意(trust agreement)」「登録」の軸が追加されたことにより、下記の通りの整理となりました。
| FAL | インジェクション保護 | 信頼の合意(trust agreement) | 登録 | 提示 |
|---|---|---|---|---|
| 1 | 推奨 | Dynamic or Static | Dynamic or Static | Bearer Assertion |
| 2 | 必須 | Static | Dynamic or Static | Bearer Assertion |
| 3 | 必須 | Static | Static | Assertion and Bound Authenticator |
これを見る限りでは、OpenID Connect Dynamic Client Registrationを使う場合は、FAL1 になりそうです。
4. FAL の定義から暗号化要件を撤廃
Change Log 中の下記についてです。
FAL definitions no longer have encryption requirements; encryption is triggered by passing PII in an assertion through an untrusted party regardless of FAL.
「FAL の定義から暗号化要件を撤廃．暗号化は FAL に関係なく，信頼できない当事者を介してアサーションで PII を渡す際に必要となる」
上で記した通り 63C-3 では、FAL2とFAL3で暗号化が必須でしたが、63C-4 では暗号化はレベル別の要件からは外れました。
6.2.3. 暗号化アサーション (Encrypted Assertion) にて、63C-3で明記されていた「Note: Assertion encryption is required at FAL2 and FAL3.」が削除され、アサーションを暗号化することのメリットの記述と、暗号化を行わなければならない場合の要件の記述が追加されています。
暗号化が必要になる際の要件は下記の通りでした。
When personally-identifiable information is included in the assertion and the assertion is handled by intermediaries such as a browser, the federation protocol SHALL encrypt assertions to protect the sensitive information in the assertion from leaking to unintended parties.
「個人を特定できる情報がアサーションに含まれ，アサーションがブラウザなどの仲介者によって処理される場合，フェデレーションプロトコルはアサーションを暗号化して，アサーション内の機密情報が意図しない関係者に漏洩するのを防がなければならない(SHALL)．」
Rediret Binding や POST Binding で渡すSAMLアサーションにPIIを含むAttributeStatementが入っている場合や、OpenID Connect の Implicit Flow で渡すIDトークンにPIIを含むclaimが入っている場合などが暗号化必須になるようです。
※PII：Personally Identifiable Information、個人を特定するために使用できるあらゆる情報（氏名、メールアドレス、電話番号、等は全てPII）
5. FAL2 でインジェクション保護が必須化
Change Log 中の下記についてです。
FAL2 requires injection protection.
「FAL2 にはインジェクション保護が必要」とのことで、Federation Assurance Level 2 (FAL2) にその旨明記されています。
At FAL2, the assertion SHALL also be strongly protected from being injected by an attacker.
「FAL2 では，アサーションは，攻撃者によるインジェクションからも強力に保護されなければならない(SHALL)．」
基本的にはバックチャネルでアサーションを提示する(SHOULD)ことが要件となりそうです。
どうしてもフロントチャネルで提示する必要がある場合は追加のインジェクション保護の実装が必須です(SHALL)。
6. FAL3 でより一般的な bound authenticatorが許容
Change Log 中の下記についてです。
FAL3 allows more general bound authenticators including RP-managed authenticators, in addition to classical holder-of-key.
「FAL3 では，従来の holder-of-key に加えて，より一般的な bound authenticator（RP 管理の authenticatorなど）が許容された．」
6.1.2．Bound Authenticators が該当章です。
「Bound Authenticator」とは、アサーションと共にRPに提示されるオーセンティケーターで、これによって、今認証を試みている人が、アサーションが示しているユーザーの主体であることを保証するために使われるものです。Bound Authenticator がないとアサーションだけでは意味をなさなくなるので、これによって、より攻撃されにくくなります。
63C-3 では、Bound Authenticator として「Holder of Keyアサーション」が挙げられていましたが、63C-4 ではそれは「IdP 管理の bound authenticators」の一例になり、「RP 管理の bound authenticators」も許容されるようになりました。
7. IAL/AAL/FALの伝達の必須化
Change Log 中の下記についてです。
Communication of IAL/AAL/FAL required.
「IAL/AAL/FALの伝達が必須」とのことで、4.4. xALのリクエストと処理 (Requesting and Processing xALs) に詳細記載があります。
全てのトランザクションでxALが一定である場合は、信頼の合意(trust agreement)時の項目として含めておかなければならず(SHALL)、トランザクションごとに変わる場合は、アサーションの一部として含まなければならなりません(SHALL)。
また、RPから必要なxALを指定できるようにしなければならなりません(SHALL)。
OpenID Connectだと、IALはOIDC4IDA、AALはIDトークン中のacr（Authentication Context Class Reference）で表現できそうです。FALの伝達をどのように行うか、はこれからでしょうか。
SAMLだと、AALはAuthnContextで表現できそうですが、IAL、FALはExtention領域等で表現することになりそうです。（あるいは、IAL、AAL、FALを全て含んだものをAuthnContextとして表現するか、でしょうか。）
8. 文言の更新
Updated language to be more inclusive.
「より包括的になるように文言を更新」とのことです。
9. RP加入者アカウントを追加
Change Log 中の下記についてです。
Added definition and discussion of RP subscriber accounts.
「RP加入者アカウントの定義と説明を追加」とのことで、5.4. RP Subscriber Accounts に詳細が記載されています。
「RP加入者アカウント」とは、RPローカルで保持しているユーザーを表すレコードで、アサーションが示している識別子と紐付けて管理されているもののことです。
今までも存在していた概念ではありますが、「RP加入者アカウント」という言葉が定義付けられ、要件もいくつか明示されています。
その他、
- 5.4.1. プロビジョニングモデル (Provisioning Models) で、各プロビジョニングモデルの要件
- 5.4.2. 属性情報の同期 (Attribute Synchronization) で、IdPとRPとの間での属性情報同期の要件
- 5.4.3. プロビジョニングAPI (Provisioning APIs) で、5.4.1. で記されている「事前プロビジョニング」を行う際に必要なプロビジョニングAPIの要件
- 5.4.4．属性の収集 (Attribute Collection) で、IdPが提示するもの以外の属性をRPが収集する際の要件
- 5.4.5. タイムベースのRP加入者アカウントの削除 (Time-based Removal of RP Subscriber Accounts) で、一定期間アクセスのないアカウントは終了(terminate)するといった要件
が新しく記載されています。
10. 属性プロビジョニングモデルの追加
Change Log 中の下記についてです。
Added attribute provisioning models and discussion.
「属性プロビジョニングモデルと説明を追加」とのことで、RP加入者アカウントを作成する際のモデルとそれぞれのモデルにおける要件について、5.4.1. プロビジョニングモデル (Provisioning Models) に記されています。
| モデル | 概要 |
|---|---|
| 即時プロビジョニング | RPが不明な識別子を含むアサーションを受信した際に自動的に作成 |
| 事前プロビジョニング | IdPからのプッシュあるいはRPからのプルにより作成 |
| 一時的なプロビジョニング | アサーション受信した際に一時的に作成されるが、セッション終了時にアカウントも終了する |
| その他 | その他のプロビジョニングについてはガイドラインの範囲外 |
実際使われるものはほとんどが即時プロビジョニングか事前プロビジョニングのいずれかになると思われます。
あとがき と 追伸
以上、Change Log に上がっていた内容をざっくり確認してみました。
63-3ではそもそもFederationが前提とされていなかったこともあり、FALはふわっとした内容しかなかったのですが、63-4ではモデルとしてFederation前提のものも追加され、FALもしっかり定義された印象です。
では。
和訳情報
63C-3から変更がありそうな主要な章はほぼ和訳したので（ほとんど機械翻訳ですが）、まとまった翻訳版が出るまでご参考にどうぞ。
63A-4(Draft) 確認してみた
下記も合わせてご参考下さい。
Discussion