【要点抽出】NIST SP800-63C-4（後編）

ニキヌス

フェデレーションのお話、NIST SP800-63C-4の続きです。
５．セクション以外を読みます。

https://openid-foundation-japan.github.io/800-63-4/sp800-63c.ja.html

６．Assertions

IdPからRPに送る「アサーション」は、登録済利用者（Subscriber）のAttribute、IdPに対して行った認証に関する情報、RPがその他必要とする情報など様々なものを含みます。
Attributeは細かく言うと「Attribute Value」と「Derived Attribute Value」の2つがあります。
前者が「誕生日は1980年1月1日」といった個人の属性情報そのもの、後者が「年齢は18歳以上」といったちょっとぼかした属性情報です。
７．セクションでは、ユーザのプライバシー保護のために、RPは可能な限りAttribute ValueではなくDerived～を要求すること（SHALL）と、IdPも可能な限りそれをサポートすること（SHALL）と書かれています。

（１）アサーションに含めるAttribute

アサーションには以下のAttributeを含めます （SHALL）。

  1. Subject Identifier：アサーションが指し示す主体についての識別子。主にSubscriberを指す

  2. Issuer Identifier：アサーションの発行者の識別子。主にIdPを指す

  3. Audience Identifier：アサーションの想定利用者の識別子。主にRPを指す

  4. Assertion Identifier：アサーションそのものの識別子

  5. Issuance Time：IdPがAssertionを発行した時刻のタイムスタンプ

  6. Authentication Time：IdP が最後に 登録済利用者（Subscriber）の認証を行った時刻のタイムスタンプ

  7. Validity Time Window：アサーションの有効期限を表すタイムスタンプ
    ＃これを超えた後、RPは登録済利用者（Subscriber）を受け入れてはいけません（SHALL NOT）

  8. IAL：登録済利用者アカウント（Subscriber Account）の IALの値

  9. AAL：IdPが登録済利用者（Subscriber）を認証した際のAALの値

  10. FAL：そのフェデレーションプロセスにおいてIdPが意図するFALの値

  11. Signature：アサーションそのものの署名

  12. Authenticator Binding：登録済利用者（Subscriber）がRPに提示するBound Authenticator（後述）の検証に必要な情報

アサーションにxALの3つを含める理由は、同じIdPとRP間のやりとりでもログインごとにxALが変わる場合があるためです。
これらが常に変わらないのであればxALの値はTrust Agreementに含め（SHALL）、変わる場合はアサーションに含めます（SHALL）。

RPはアサーションを受け取ったら、上記の2，3，7，11を検証します（SHALL）。

（２）アサーションのBinding時の確認

RPが受け取ったアサーションと登録済利用者（Subscriber）を紐づけることをBindingと呼びます。Bindingの際のチェックは、その厳しさにより2種類に分けられます。
Bearer Assertionsは、アサーションを受け取って検証できたらそれを信じるものです。FAL１，２はこれにあたります。
仮に第三者が不正にアサーションを入手してRPに提示した場合、なりすましができてしまいます。
OAuth2.0におけるBearer Tokenと同じかと思います。

Bound Authenticatorsは、登録済利用者（Subscriber）がRPにアサーションを提示するとともに追加の認証を行う方式です。FAL３はこれにあたります。
これにより、第三者が不正にアサーションを入手した場合でも、それを用いたなりすましを防ぐことができます。
OAuth2.0におけるHolder-of-Key Tokenであり、MTLSで認証した上でトークンを提示するようなイメージかと思います。

Bound Authenticatorはフィッシング耐性を持つ必要があります（SHALL）。つまりパスワードは使えません。
IdPへの認証に用いるAuthenticatorとRPに用いるBound Authenticatorは、同じものでも別のものでも構いません。

（３）Bound Authenticatorの管理方式

Bound Authenticatorは、IdPが管理する方式と、RPが管理する方式があります。
前者の場合は、IdPからRPに対してAuthenticatorの識別子（例えば公開鍵）をアサーションに含めて連携します（SHALL）。これが上述の「12.Authenticator Binding」です。

後者の場合は、IdPからのアサーションの中にAuthenticatorの識別子を含めることができません。かわりに「このアサーションはFAL３なので、Bound Authenticatorと一緒に使うものです」という情報を含めます（SHALL）。

（４）Bound Authenticatorの入手方式

上記の「RPが管理する方式」において、RPは一番最初にBound Authenticatorをどう入手するのでしょうか。
これは、RPが提示する方式と、登録済利用者（Subscriber）が提示する方式の２つに分かれます。

RPが提示する方式は、登録済利用者（Subscriber）が認証した際にRPからSubscriberへAuthenticatorを発行します。
Subscriberが提示する方式はもう少し複雑で、最初に登録済利用者（Subscriber）がRPにAuthenticatorを提出する「Bindingセレモニー」を行います（SHALL）。
セレモニーの詳細は割愛しますが、以下の要件があります（いずれもSHALL）。

  • Bindingセレモニーのセッションは5分以内にタイムアウトする

  • Bindingセレモニーが終わった後、RPは改めてIdPから新たなアサーションをもらい、登録済利用者（Subscriber）にBound Authenticatorを用いた認証を求める

また、登録済利用者アカウント（Subscriber Account）に対するBound Authenticatorの紐づけの追加や解除があった場合、RPは登録済利用者（Subscriber）とIdPにそれぞれ通知します（SHALL）。

（５）アサーションの保護

本書では、アサーションを悪用されないための保護策が定められています。

  • IdPがアサーションに署名すること（SHALL）

  • アサーションに個人情報が含まれる場合は、アサーションを暗号化すること（SHALL）
    #SAMLのAssertionに対するXML-Encryptionや、OpenID ConnectのID Tokenに対するJWEの話

  • アサーション内に、そのアサーションが想定する発行対象のRPの情報を含め、それをRP自身がチェックすること（SHALL）

（６）Pairwise Pseudonymous Identifiers

登録済利用者（Subscriber）のプライバシー保護のためにPairwise Pseudonymous Identifiers（PPI）を活用する場合は、以下が求められます。（PPIとは？については前編参照）

  •  IdPは各RPに異なるユーザの識別子（Federated Identifier）を生成する（SHALL）

  • PPIには登録済利用者（Subscriber）の情報を含めず、推測不可能な値とする（SHALL）

  • RP同士がPPI以外のAttributeを突き合わせて名寄せすることをプライバシーポリシーで禁止する（SHOULD）

通常、1つのPPIは1組のIdP・RP間でのみ使います（SHALL）が、Authorized Partyが同意し、Trust Agreementにも明記されるなど特定の条件を満たした時のみ、複数のRPに同じ識別子を使ってもOKです（MAY）。

（７）Identity API

ここまで登録済利用者（Subscriber）のAttributeはアサーションに含まれることを前提に書いてきました。
しかし、認証のたびに個人情報がわんさか入ったアサーションを連携するのは、アサーション自体の肥大化に繋がり効率的ではありません。
そもそも個人情報はログインのたびに確認せねばならないほど高頻度に変わるものでもありません。
このため、個人情報に関するやりとりはアサーションではなく別のIdentity APIを用意し、RPが欲しい場合はこのAPIを使って取得してもらうことができます（MAY）。

OpenID ConnectにおけるUserinfoエンドポイントがその例で、IdPはアサーションと一緒にアクセストークンを発行します。RPはそのトークンを利用してAPIにアクセスします。
このAPIは通常IdPが提供しますが、また別のAttribute Providerが提供するケースもあります。

７．Assertion Presentation

ここではIdPがRPにアサーションを連携する際の詳細な動きに触れます。
連携方法は2種類あり、IdPが登録済利用者（Subscriber）のブラウザを介してRPに連携するフロントチャネル提示モデルと、IdPがRPに直接連携するバックチャネル提示モデルがあります。
RPにとっては直接IdPからアサーションを受け取れるバックチャネルの方が、漏洩や改ざんのリスクが低いためセキュアであり、この方法はFAL２以上で推奨されます。

まずはバックチャネル提示モデル。
以下の流れでアサーションが連携されます。

  1. IdPが登録済利用者（Subscriber）にAssertion Reference（アサーション発行許可証的なもの）を送る

  2. 登録済利用者（Subscriber）がRPに上記のAssertion Referenceを送る

  3. RPがIdPにAssertion Referenceと、RP自身を証明するクレデンシャルを提示する

  4. IdPはそれらを確認後、RPにアサーションを送る

Assertion Referenceには以下が求められます。

  • 利用できるRPを単一に制限する (SHALL)

  • 利用できる回数を1度きりに制限する (SHALL)

  • 有効期限を定め (SHALL)、 そのライフタイムを数分以内にする (SHOULD)

  • RPが提示する際に、IdPに対するRP自身の認証を求める (SHALL)

  • 128bit以上のエントロピーを持つ (SHALL)

  • Assertion Referenceのやりとりはセキュアな通信経路（Authenticated Protected Channel）を介して行う（SHALL）

次にフロントチャネル提示モデル。
こちらは上述の通り、IdPとRPが直接会話せず、登録済利用者（Subscriber）のブラウザでリダイレクトさせることでアサーションを届けます。
この場合、Subscriberにアサーションの中身が見られることで、そこに含まれるシステム情報が知られてしまうとか、登録済利用者（Subscriber）が想定と異なるRPにアサーションが送ってしまうなど様々なリスクが考えられますが、本書はそれらに対する打ち手は特に触れていません。
リスクに応じた使い方をしてくださいということのようです。

余談として、OpenID Connectはバックチャネル提示モデルが主流（でもインプリシットフローはフロントチャネル）、SAMLはフロントチャネル提示モデルが主流、とどこかで読みました。

４．Federation Assurance Level (FAL)

いよいよFALの解説です。
まず、それぞれの違いを表にまとめます。

表１．FAL比較表

  • どのFALもアサーションへの署名と検証、およびAudience Restrictionsの設定と確認は必須です。

  • FAL１はTrust AgreementやRegistrationについて、比較的自由に選べます。

  • FAL２はRPに対するアサーションのインジェクション攻撃を防ぐために、基本的にバックチャネルでのアサーションの連携を求められます。
    あるいは、IdP発ではなくRP発でIdPとセッションを確立することも有効です。
    Trust AgreementはStatic、つまり事前に契約等で結ぶ必要があります。

  • FAL３はとにかくBound Authenticatorが特徴です。
    これにより、RPにアクセスしてきてるヤツ＝アサーションにより識別されるSubscriberであることを確認します。

SP800-63-4：こちら
SP800-63A-4：こちら
SP800-63B-4（前編）：こちら
SP800-63B-4（後編）：こちら
SP800-63C-4（前編）：こちら
SP800-63C-4（後編）：こちら（この記事）

＊＊＊はじめての方へ＊＊＊
これは何のnoteだ？と思われた方はこちらをご覧ください。
これまでにまとめたガイドライン類の一覧はこちら

この記事が気に入ったらサポートをしてみませんか？