=kthrtty/(+blog)

最近旅してないフルスタックサラリーマンジャーマネの旅行の記録

NISTがSP800-63-3の改定に入る前にパブコメやるらしいからコメントを考えてみた

パブコメってどういうこと?

2017年に正式に改定され,「パスワードの定期変更」ネタで物議を呼んだご存知NIST SP800-63-3が,どうやら改定を検討しているらしく,そのインプットとしてのパブコメを募集するというアナウンスがありました.

csrc.nist.gov

ということでパブコメをしてみます.

パブコメなんて,「よく考えられていると思いました」とか意味不明な内容でも良いはずなので,とりあえず気に入らなかったり,分かりにくかったりした箇所があればどんどんコメントするのが良いですね!

そもそもNIST SP800-63って何でしたっけ?

2017-2018年のネタですからね,もう記憶喪失です.

オンラインにおけるDigital Identity Framework(昔は登録と認証メインでしたが,最近はフェデレーションも含まれるようになってまさにフレームワーク)と呼ぶにふさわしいガイドラインです.

一応,NISTのガイドラインは米国政府機関向けであり,その他の人にとって何ら参照しなければならないものではないですが,クレジットカードにおけるPCI-DSSや,FISC安対なんかでも(追いつき不足による内容不整合はおいておいて)参照されており,非常に由緒ただしいものと考えられているはず.

2006年4月に発行されたNIST SP800-63は,IPAサイトで翻訳版が公開されています.https://www.ipa.go.jp/security/publications/nist/

最新のSP800-63-3は,githubで差分管理することになり以下で公開されています. csrc.nist.gov

それを,OpenID Foundation JAPAN有志メンバで翻訳した版が以下のgithubで管理されています.私は63Bパートを担当しました. openid-foundation-japan.github.io

更に,解説スライドは以下に配置してあります.InternetWeek2018と,翌年の東北大学で実施したInternetWeek Showcaseで使いました. speakerdeck.com

パブコメの内容メモ

自分も記憶喪失なので,思い出しながら何をコメントしようか考えながら書いてみよう.とりあえず自分で担当していた63Bで気になったところが何だったっけかな?と.

"Device"って書いてあるのにハードウェアじゃないかもしれない件

63Bに限らず,Authenticatorがハードウェア(Hardware root of trust)かどうかはセキュリティの面で重要な意味を持ちます.

5.1.4 Single-Factor OTP Devices(および5.1.5 Multi-Factor OTP Devices)において,以下のように書いてあります.

This category includes hardware devices and software-based OTP generators installed on devices such as mobile phones. 

この2つのAuthenticator種別についてだけ,スマホにインストールされたOTPソフトウェアが混同されていて分かりにくかった記憶があります.

実際,

という具合に概ねデバイスとソフトウェアを明らかに「HWかどうか」で分割しているにも関わらず,OTPデバイスだけは「HWだったりSWだったり」という具合です.

そこで「tangibleかそうでないかははっきりと分離したほうが良いのでは」というコメントをしてみることにします.

一応紛らわしい例を想像してからコメントを書いてみなければ.

  • iPhoneに入っているGoogle Authenticator
    • iPhoneはSomething you haveである.
    • Google AuthenticatorはSoftwareである.
    • iPhone自体のFaceIDやTouchID,Passcodeは「かかっているかもしれないし,かかっていないかもしれないし,Verifier側でそれを知るすべはないので」1要素目の認証要素としてはカウントしない(という63Bの整理)

これはDevice(Hardware)なのかSoftwareなのかと言われるとやはり曖昧ですね.Hardwareでいいの?違うの?どっちなの,と.

VerifierとのAuthenticated protected channelを張っている端末上に存在していなければDevice,同じならSoftwareとかだったら複雑だなと想像しつつ,何かしら理由をつけて分離するか,補足しててほしいと思いました.

多要素認証と多段階認証

某セブンペイ事件の際に,世の中でだいぶ取り沙汰された2段階認証ですが,2要素認証との違いについて明記してほしいですよね.

PCI-DSSにおいては,Multi-Step AuthenticationとMulti-Factor Authenticationについて内部的にモメたようで,一定の見解を出していました.

blog.pcisecuritystandards.org

更に参照しているこれとか. https://www.pcisecuritystandards.org/pdfs/Multi-Factor-Authentication-Guidance-v1.pdf

要するに

  • アクセス許可する前に全ての要素の認証が成功しなければならない.
  • 全ての要素が提示される前に認証の成否が分かってはならない.

特に2項目は簡単に言ってくれるな,という感じです. サービスによってはユーザビリティ向上のために,メールアドレス入れた段階でユーザの存在有無を確定されるようなこともあるでしょう.(e.g, Google Account Chooser,Azure Active Directory)

OTPハードウェアのように,それ自身が既にユーザ(Subscriber)のIdentityにバインドされているならば良いですが,Push通知やSMS,電話(が適切なAuthenticatorであるかは棚上げして)など,サーバサイドでユーザのIdentityが特定されなければ開始できないことはままあります.

2. The authentication mechanisms are independent of one another, such that access to one factor does not grant access to any other factor, and the compromise of any one factor does not affect the integrity or confidentiality of any other factor.

というあたりも簡単に言ってくれるな,という感じです.

PCI-DSSのMulti-Factorがちょっと厳しすぎて世の中の相場観と乖離しているように思えるけれど,NISTとしてはこの辺について整理してみませんか?」という感じのコメントでしょうかね.

パスワードの定期変更の混乱に着地点を示してほしい

私はそこまでこれにご執心ではないのですが,皆さんイライラしているらしく盛り上がりまくった件です.

63Bでは定期変更をユーザに求めることを「すべきではない」こととしていますが,63Bが主なターゲットとして想定しているのは,政府機関が提供するデジタルサービスや職員向けの認証機能です.

ということで,PCI-DSSの「定期変更をユーザに求める」ことを強制する姿勢と不整合を発生させています.

ここはぜひ,

  • 政府機関職員(一般ユーザ)転じてコンシューマは63Bの定期変更を求めることはすべきではない
  • システム運用管理者(定期変更により弱いパスワードに至ることがないような強固な運用を期待できる人)には引き続き有効な側面が残る

など踏み込んで言及してもらえると世界平和につながると考えてコメントすることにします.

EmailはOOB Authenticatorには使えないが,他の目的を制限していない,という点がわかりにくい

5.1.3.1 アウトオブバンドAuthenticator

Voice-over-IP(VoIP)やEmailなど,特定デバイスの所持証明を行わない方式は,アウトオブバンドAuthenticationを行う目的では利用しないものとする(SHALL).

他の用途として,アカウントリカバリに利用している事例を考えてみます.

Login HintとしてAccount Chooserに過去にログインした形跡が残っている(アカウント名が選択可能)な場合は,PW忘れをした場合のEmailによる確認コード受信&入力でアカウントリカバリが直ちに完了します.(ログイン形跡のある環境であり,リスクが少ないと判断されるため)

一方,完全に新規環境だと,Emailによる確認コード受信&入力後に,「追加情報」として過去PWや過去接続元IP,過去接続ブラウザなどログインに関連するトラッキング情報との突き合わせ要素を増やすように促され,そういった環境でアカウントリカバリを試行すると成功します.

Googleの例のように「他の目的でのEmail OOB活用」をしているわけですが,ほとんど「解釈」の話になっていて,わかりにくいですよね.「アカウントリカバリに利用してもよい(MAY)が,その場合はリスクベースで〜」とか補足があると良いなと思いました.

アカウントリカバリのためのAuthenticatorの再バインディングでのIdentity Proofingの方法が曖昧

6.1.2.3 紛失したAuthentication要素の置き換え

要するにPWを忘れてしまったときの再バインディングの話なのですが,根が深い.

記憶シークレットの紛失(すなわち忘れてしまうこと)の置き換えは,非常に一般的であるがゆえに解決が難しい問題である.追加の “バックアップ” 記憶シークレットは,結局忘れる可能性があるために緩和策にはならない.もしバイオメトリックがアカウントにバインドされていれば,バイオメトリックと関連する物理Authenticatorが新しい記憶シークレットを設定するために利用されるべきである(SHOULD).
アカウントにバイオメトリックがバインドされていない場合には,上記のre-proofingプロセスの代わりとして,CSPは,Subscriberの住所の一つに送信された確認コードとともに2つの物理Authenticatorを用いたAuthenticationを行い新しい記憶シークレットをバインドしてもよい(MAY).

唐突に登場している物理Authenticator(phisical authenticators)に対して一切の説明がないのでわかりにくいです.また今までは複数の同じ認証要素のAuthenticatorを利用しても,多要素認証にはならない点に言及されているにも関わらず,唐突に要素数ではなく物理Authenticator数に言及しています.63Aにも2つの物理Authenticatorに関する記述はなく,唐突に感じられるため,具体例を補足してほしいというコメントをすることにしました.

加えて,前述の通りですが「Google/MSはPW忘れに伴うAAL2のRebindingをEmailを使って実施しているけれど,これはGoogle/MSがSelf-Evident/ClaimedなIAL1なサービスだからだと理解して良いよね?」というコメントは追加しておこうと思います.

他にも言いたいことはあるが・・・

これは米国政府機関向けという但し書きを考慮するとぐうの音もでない件がいくつか.まだコメントすることまでは考えていません.

IAL>AALのときパーソナルデータを開示するな

6.1.1 Enrollment時のバインディング

CSPはAAL1のAuthenticatorをIAL2のアイデンティティにバインドしてもよい(MAY)が,もしSubscriberがAAL1でAuthenticateされた場合には,CSPは,それが仮にself-assertedであっても,個人情報をSubscriberに対して開示しない(SHALL NOT).

冷静に考えて,AALとIALの関係に基づいて開示範囲をスコーピングするの実装が面倒ですよね.ましてOIDCのscopeなんかと組み合わせた日には,大して面白みもないのに複雑なテストパターンが出来上がりそうで辟易します.

Authentication Context Referenceをうまくアクセス可能エリアに結びつけて,ユーザ情報の確認・変更画面へのアクセスを禁止する程度ならOKでしょうが,至るところで表示するために参照しうるものを正しく一律に制限するだなんて,正気の沙汰とは思えません.UserInfoとか一箇所だから制御する気になるだけですよ.

パブコメ英文

英語は、結局自分でまずは書いてみて、そのあとDeepLとGoogleに和訳してもらって意味が崩壊していないか眺めた程度でそれっぽく.意味反転してなければよいですね。

I think there are several uncertain/ambiguous expression in 63B, so I comment as follows:


1) Some authenticators named "Device" are ambiguous as to whether they are hardware or software
Single-Factor OTP Authenticators are mentioned that "This category includes hardware devices and software-based OTP generators installed on devices such as mobile phones." in Sec 5.1.4.
However other "hardware" authenticators(e.g., "Single-Factor Cryptographic Device Authenticators") are all named "Device" and explicitly distinct from "software" authenticators(e.g., "Single-Factor Cryptographic Software Authenticators")

Thus, I think that "Single-Factor OTP Authenticators" should be divided into "Device"(hardware) and "Software".


2) NIST should explain the difference between "Multi-Factor" and "Multi-Step" authentication.
PCI-DSS introduces "Multi-Step" authentication in the following documents.

https://blog.pcisecuritystandards.org/faq-is-two-step-authentication-acceptable-for-pci-dss-requirement-8.3
https://www.pcisecuritystandards.org/pdfs/Multi-Factor-Authentication-Guidance-v1.pdf

NIST has no responsibility to mention about a specific industry, however the insight should be provided by NIST.
Technically speaking, some kinds of action need an email ID prior to inputting the 2nd factor value.
In fact, GAFA's authentication flow is not multi-factor but multi-step in the view of PCI and ambiguous.

Because of the above reason, I think that 63B should mention multi-step authentication.


3) Double standard about "memorized secret periodically changed" in 5.1.1.2 Memorized Secret Verifiers should be mentioned.
63B stated that 'Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically)', then this policy transition caused lots of discussion.
NIST's new policy is acceptable especially for Web sites(e.g,. EC), however it conflicts with PCI-DSS's policy.

I propose that 63B show the difference between end-users and administrators/operators.
To show my intention, please see the following example.
- For end-users including US government staff, 63B's approach works well.
- For administrators/operators, traditional periodical password renewal policy may also work well because such persons can renew their password complicated enough according to the policy.


4) Use case of some OOB methods which do not prove possession should be mentioned.
63B says that "Methods that do not prove possession of a specific device, such as voice-over-IP (VOIP) or email, SHALL NOT be used for out-of-band authentication." in Section 5.1.3.1.
Actually, Google and Microsoft don't use such purpose, but use email OOB as a method of end-user account recovery flow with additional countermeasures.
For example, in Google's flow, if google account chooser memorize "logged-in" history, account recovery successfully finished right away, and if not, additional information is required.

I recognize that such an account recovery flow is one of the implementations of "Replacement of a Lost Authentication Factor".

If my understanding is correct, I offer to add the following example:
 "Such a OOB method MAY be used for the purpose of account recovery, and then the verifier should verify other additional attributes implicitly to confirm whether user access from customary environment or not. "



5) How csp does Identity Proofing to rebind authenticators for account recovery is ambiguous.
63B says that "As an alternative to the above re-proofing process when there is no biometric bound to the account, the CSP MAY bind a new memorized secret with authentication using two physical authenticators, along with a confirmation code that has been sent to one of the subscriber's addresses of record." in Sec6.1.2.3.

The word "physical authenticators" is first occurrence in 63-3 publication and 63A doesn't mention "physical authenticator".
AAL doesn't mention the number of physical authenticators, but multi-factor.
Please consider adding concrete examples to clear up any ambiguity I mentioned at the above.

Related to 6, my understanding is that Google and Microsoft using email(login ID) for account recovery don't comply with rebinding using two "physical" authenticators and that is because IAL is 1 (Self- Evident).
Because some people might have questions about it, please consider mentioning this point.

おしまいです。