Sun, 05 Mar 2023 05:16:25 +0000

ABSTRACT

本ガイドライン群は, Digital Identity サービスを実装する連邦機関に対する技術的要件を提供するものであり, それ以外の条件下での標準仕様の開発・利用に対する制約を意図したものではない. 本ガイドラインは, 政府機関がネットワークを介して提供する情報システムを利用する Subject の Authentication にフォーカスしている. この Authentication により, 特定の Claimant が以前 Authenticate された Subscriber であるということが立証可能となる. Authentication プロセスの結果は Authentication を実行したシステムローカルで利用されることもあるが, Federated Identity System 内の別の場所で利用されることもある. 本ドキュメントは3つの Authenticator Assurance Level 毎に技術要件を定義する. 本ドキュメントの発行をもって, 本ドキュメントは既存の NIST Special Publication 800-63B を置き換えるものとする.

Keywords

authentication; authentication assurance; credential service provider; digital authentication; digital credentials; electronic authentication; electronic credentials; passwords.

翻訳者

• Hitomi Kimura
  • Trend Micro Inc. (United States)
• Nov Matake
  • OpenID Foundation Japan エバンジェリスト 兼 翻訳WGリーダー
  • MoneyForward inc.
  • YAuth.jp LLC

ABSTRACT

本ガイドライン群は, Digital Identity サービスを実装する連邦機関に対する技術的要件を提供するものであり, それ以外の条件下での標準仕様の開発・利用に対する制約を意図したものではない. 本ガイドラインは, 政府機関がネットワークを介して提供する情報システムを利用する Subject の Authentication にフォーカスしている. この Authentication により, 特定の Claimant が以前 Authenticate された Subscriber であるということが立証可能となる. Authentication プロセスの結果は Authentication を実行したシステムローカルで利用されることもあるが, Federated Identity System 内の別の場所で利用されることもある. 本ドキュメントは3つの Authenticator Assurance Level 毎に技術要件を定義する. 本ドキュメントの発行をもって, 本ドキュメントは既存の NIST Special Publication 800-63B を置き換えるものとする.

Keywords

authentication; authentication assurance; credential service provider; digital authentication; digital credentials; electronic authentication; electronic credentials; passwords.

Note to Reviewers

The rapid proliferation of online services over the past few years has heightened the need for reliable, equitable, secure, and privacy-protective digital identity solutions.

Revision 4 of NIST Special Publication 800-63 Digital Identity Guidelines intends to respond to the changing digital landscape that has emerged since the last major revision of this suite was published in 2017 — including the real-world implications of online risks. The guidelines present the process and technical requirements for meeting digital identity management assurance levels for identity proofing, authentication, and federation, including requirements for security and privacy as well as considerations for fostering equity and the usability of digital identity solutions and technology.

Taking into account feedback provided in response to our June 2020 Pre-Draft Call for Comments, as well as research conducted into real-world implementations of the guidelines, market innovation, and the current threat environment, this draft seeks to:

1. Advance Equity: This draft seeks to expand upon the risk management content of previous revisions and specifically mandates that agencies account for impacts to individuals and communities in addition to impacts to the organization. It also elevates risks to mission delivery – including challenges to providing services to all people who are eligible for and entitled to them – within the risk management process and when implementing digital identity systems. Additionally, the guidance now mandates continuous evaluation of potential impacts across demographics, provides biometric performance requirements, and additional parameters for the responsible use of biometric-based technologies, such as those that utilize face recognition.
2. Emphasize Optionality and Choice for Consumers: In the interest of promoting and investigating additional scalable, equitable, and convenient identify verification options, including those that do and do not leverage face recognition technologies, this draft expands the list of acceptable identity proofing alternatives to provide new mechanisms to securely deliver services to individuals with differing means, motivations, and backgrounds. The revision also emphasizes the need for digital identity services to support multiple authenticator options to address diverse consumer needs and secure account recovery.
3. Deter Fraud and Advanced Threats: This draft enhances fraud prevention measures from the third revision by updating risk and threat models to account for new attacks, providing new options for phishing resistant authentication, and introducing requirements to prevent automated attacks against enrollment processes. It also opens the door to new technology such as mobile driver’s licenses and verifiable credentials.
4. Address Implementation Lessons Learned: This draft addresses areas where implementation experience has indicated that additional clarity or detail was required to effectively operationalize the guidelines. This includes re-working the federation assurance levels, providing greater detail on trusted referees, clarifying guidelines on identity attribute validation sources, and improving address confirmation requirements.

NIST is specifically interested in comments on and recommendations for the following topics:

Authentication and Lifecycle Management

• Are emerging authentication models and techniques – such as FIDO passkey, verifiable credentials, and mobile driver’s licenses – sufficiently addressed and accommodated, as appropriate, by the guidelines? What are the potential associated security, privacy, and usability benefits and risks?
• Are the controls for phishing resistance as defined in the guidelines for AAL2 and AAL3 authentication clear and sufficient?
• How are session management thresholds and reauthentication requirements implemented by agencies and organizations? Should NIST provide thresholds or leave session lengths to agencies based on applications, users, and mission needs?
• What impacts would the proposed biometric performance requirements for this volume have on real-world implementations of biometric technologies?

General

• Is there an element of this guidance that you think is missing or could be expanded?
• Is any language in the guidance confusing or hard to understand? Should we add definitions or additional context to any language?
• Does the guidance sufficiently address privacy?
• Does the guidance sufficiently address equity?
  • What equity assessment methods, impact evaluation models, or metrics could we reference to better support organizations in preventing or detecting disparate impacts that could arise as a result of identity verification technologies or processes?
• What specific implementation guidance, reference architectures, metrics, or other supporting resources may enable more rapid adoption and implementation of this and future iterations of the Digital Identity Guidelines?
• What applied research and measurement efforts would provide the greatest impact on the identity market and advancement of these guidelines?

Reviewers are encouraged to comment and suggest changes to the text of all four draft volumes of of the NIST SP 800-63-4 suite. NIST requests that all comments be submitted by 11:59pm Eastern Time on March 24, 2023. Please submit your comments to dig-comments@nist.gov. NIST will review all comments and make them available at the NIST Identity and Access Management website. Commenters are encouraged to use the comment template provided on the NIST Computer Security Resource Center website.

Note to Reviewers

The rapid proliferation of online services over the past few years has heightened the need for reliable, equitable, secure, and privacy-protective digital identity solutions.

Revision 4 of NIST Special Publication 800-63 Digital Identity Guidelines intends to respond to the changing digital landscape that has emerged since the last major revision of this suite was published in 2017 — including the real-world implications of online risks. The guidelines present the process and technical requirements for meeting digital identity management assurance levels for identity proofing, authentication, and federation, including requirements for security and privacy as well as considerations for fostering equity and the usability of digital identity solutions and technology.

Taking into account feedback provided in response to our June 2020 Pre-Draft Call for Comments, as well as research conducted into real-world implementations of the guidelines, market innovation, and the current threat environment, this draft seeks to:

1. Advance Equity: This draft seeks to expand upon the risk management content of previous revisions and specifically mandates that agencies account for impacts to individuals and communities in addition to impacts to the organization. It also elevates risks to mission delivery – including challenges to providing services to all people who are eligible for and entitled to them – within the risk management process and when implementing digital identity systems. Additionally, the guidance now mandates continuous evaluation of potential impacts across demographics, provides biometric performance requirements, and additional parameters for the responsible use of biometric-based technologies, such as those that utilize face recognition.
2. Emphasize Optionality and Choice for Consumers: In the interest of promoting and investigating additional scalable, equitable, and convenient identify verification options, including those that do and do not leverage face recognition technologies, this draft expands the list of acceptable identity proofing alternatives to provide new mechanisms to securely deliver services to individuals with differing means, motivations, and backgrounds. The revision also emphasizes the need for digital identity services to support multiple authenticator options to address diverse consumer needs and secure account recovery.
3. Deter Fraud and Advanced Threats: This draft enhances fraud prevention measures from the third revision by updating risk and threat models to account for new attacks, providing new options for phishing resistant authentication, and introducing requirements to prevent automated attacks against enrollment processes. It also opens the door to new technology such as mobile driver’s licenses and verifiable credentials.
4. Address Implementation Lessons Learned: This draft addresses areas where implementation experience has indicated that additional clarity or detail was required to effectively operationalize the guidelines. This includes re-working the federation assurance levels, providing greater detail on trusted referees, clarifying guidelines on identity attribute validation sources, and improving address confirmation requirements.

NIST is specifically interested in comments on and recommendations for the following topics:

Authentication and Lifecycle Management

• Are emerging authentication models and techniques – such as FIDO passkey, verifiable credentials, and mobile driver’s licenses – sufficiently addressed and accommodated, as appropriate, by the guidelines? What are the potential associated security, privacy, and usability benefits and risks?
• Are the controls for phishing resistance as defined in the guidelines for AAL2 and AAL3 authentication clear and sufficient?
• How are session management thresholds and reauthentication requirements implemented by agencies and organizations? Should NIST provide thresholds or leave session lengths to agencies based on applications, users, and mission needs?
• What impacts would the proposed biometric performance requirements for this volume have on real-world implementations of biometric technologies?

General

• Is there an element of this guidance that you think is missing or could be expanded?
• Is any language in the guidance confusing or hard to understand? Should we add definitions or additional context to any language?
• Does the guidance sufficiently address privacy?
• Does the guidance sufficiently address equity?
  • What equity assessment methods, impact evaluation models, or metrics could we reference to better support organizations in preventing or detecting disparate impacts that could arise as a result of identity verification technologies or processes?
• What specific implementation guidance, reference architectures, metrics, or other supporting resources may enable more rapid adoption and implementation of this and future iterations of the Digital Identity Guidelines?
• What applied research and measurement efforts would provide the greatest impact on the identity market and advancement of these guidelines?

Reviewers are encouraged to comment and suggest changes to the text of all four draft volumes of of the NIST SP 800-63-4 suite. NIST requests that all comments be submitted by 11:59pm Eastern Time on March 24, 2023. Please submit your comments to dig-comments@nist.gov. NIST will review all comments and make them available at the NIST Identity and Access Management website. Commenters are encouraged to use the comment template provided on the NIST Computer Security Resource Center website.

Purpose

This section is informative.

本ドキュメントとそれと対をなす各ドキュメント [SP800-63], [SP800-63A], そして [SP800-63C] は, Digital Identity Service を実装する組織に向けた技術的ガイドラインを提供するものである.

このドキュメント, SP 800-63Bは, 3つの Authentication Assurance Levels (AALs) のそれぞれでのRemote User Authenticationのための Credential Service Providers (CSPs) に対する要件を提供するものである.

Purpose

This section is informative.

This publication and its companion volumes, [SP800-63], [SP800-63A], and [SP800-63C], provide technical guidelines to organizations for the implementation of digital identity services.

This document, SP 800-63B, provides requirements to credential service providers (CSPs) for remote user authentication at each of three authentication assurance levels (AALs).

Introduction

This section is informative.

Digital Authentication は, Digital Identity を主張するために使用される1つかそれ以上の Authenticator の有効性を判断するプロセスである. Authentication は, デジタル サービスにアクセスしようとしている Subject が,Authentication に使用される技術を制御していることを立証する. 再訪問の対象となるサービスの場合, Authentication に成功することは今日サービスにアクセスする Subject が以前サービスにアクセスした Subject と同じであるという合理的なリスクベースの保証を提供する.

Subscriber の進行中の Authentication は, Subscriber をそれらのオンライン アクティビティ (つまり, Subscriber Account) に関連付けるプロセスの中心である. Subscriber Authentication は, 特定のSubscriber Account に関連付けられた1つかそれ以上の Authenticator (SP 800-63 の一部の以前のバージョンでは Token と呼ばれる) を Claimant が制御していることを検証することによって実行される. Authentication の成功は, Pseudonymous または Non-Pseudonymous Identifierと, 選択に応じてその他の identity 情報が Relying Party (RP) に Assertion される.

このドキュメントでは, さまざまな Authentication Assurance Level (AAL) で使用される可能性がある, Authenticator の選択を含む Authentication プロセスのタイプに関する推奨事項を提供する. また紛失や盗難が発生した場合の失効を含む Authenticator のライフサイクルに関する推奨事項も提供する.

この技術ガイドラインは, Subject のネットワーク越しのシステムに対する Digital Authentication に適用される. デジタルアクセスに使用されるいくつかの Credential は物理アクセスの Authentication にも使用される場合があるが, 本ガイドラインは (例: 建物などへの) 物理アクセスに対する個人の Authentication には対応しない. この技術ガイドラインでは, Authentication プロトコルに参加する Federal システムとサービス プロバイダーが Subscriber に対して Authenticate されることも要求する.

AAL は, Authentication Transaction の強度を, 順序のあるカテゴリとして特徴づけることができる. より強力な Authentication (より高い AAL) は, 悪意のあるアクターが Authentication プロセスの転覆を成功させるために, より優れた能力を持ち, より大きなリソースを消費することを必要とする. より高い AAL での Authentication は, Attack のリスクを効果的に減らすことができる. 各 AAL の技術要件の概要を以下に示す. 特定の Normative Requirement についてはこのドキュメントの Sec. 4 と Sec. 5 を参照のこと.

Authentication Assurance Level 1: AAL1 は, Claimant が Subscriber Account に Bind された Authenticator を制御するというある程度の保証を提供する. AAL1 は, 利用可能な幅広い Authentication 技術を使用した Single-Factor または Multi-Factor の Authentication を必要とする. Authentication の成功には, Claimant がセキュアな Authentication プロトコルを介して Authenticator の所有と制御を証明する必要がある.

Authentication Assurance Level 2: AAL2 は, Claimant が Subscriber Account に Bind された1つかそれ以上の Authenticator を制御するという高い確信を提供する. セキュアな Authentication プロトコルを介して, 2つの異なる Authentication Factor の所有と制御の証明が必要である. AAL2 以上では, Approved な暗号技術が必要である.

Authentication Assurance Level 3: AAL3 は, Claimant が Subscriber Account に Bind された1つかそれ以上の Authenticator を制御するという非常に高い確信を提供する. AAL3 での Authentication は, 暗号プロトコルを介した Key の所有の証明に基づく. AAL3 Authentication は, ハードウェアベースの Authenticator と Phishing 耐性のある Authenticator を必要とし(Sec. 5.2.5 を参照), 同じデバイスがこれらの両方の要件を満たす場合がある. AAL3 で Authentication を行うには, Claimant は, セキュアな Authentication プロトコルを介して, 2つのはっきりと異なる Authentication Factor の所有と制御を証明する必要がある. Approved な暗号技術が必要である.

次のリストは, ドキュメントのどのセクションが Normative で, どのセクションが Informative であるかを示す.

• 1 Purpose Informative
• 2 Introduction Informative
• 3 Definitions and Abbreviations Informative
• 4 Authentication Assurance Levels Normative
• 5 Authenticator and Verifier Requirements Normative
• 6 Authenticator Lifecycle Management Normative
• 7 Session Management Normative
• 8 Threat and Security Considerations Informative
• 9 Privacy Considerations Informative
• 10 Usability Considerations Informative
• 11 Equity Considerations Informative
• References Informative
• Appendix A Strength of Memorized Secrets Informative
• Appendix B Change Log Informative

Introduction

This section is informative.

Digital authentication is the process of determining the validity of one or more authenticators used to claim a digital identity. Authentication establishes that a subject attempting to access a digital service is in control of the technologies used to authenticate. For services in which return visits are applicable, successfully authenticating provides reasonable risk-based assurances that the subject accessing the service today is the same as the one who accessed the service previously.

The ongoing authentication of subscribers is central to the process of associating a subscriber with their online activity (i.e., with their subscriber account). Subscriber authentication is performed by verifying that the claimant controls one or more authenticators (called tokens in some earlier versions of SP 800-63) associated with a given subscriber account. A successful authentication results in the assertion of a pseudonymous or non-pseudonymous identifier and optionally other identity information to the relying party (RP).

This document provides recommendations on types of authentication processes, including choices of authenticators, that may be used at various authentication assurance levels (AALs). It also provides recommendations on the lifecycle of authenticators, including revocation in the event of loss or theft.

This technical guideline applies to digital authentication of subjects to systems over a network. It does not address the authentication of a person for physical access (e.g., to a building), though some credentials used for digital access may also be used for physical access authentication. This technical guideline also requires that federal systems and service providers participating in authentication protocols be authenticated to subscribers.

The AAL characterizes the strength of an authentication transaction as an ordinal category. Stronger authentication (a higher AAL) requires malicious actors to have better capabilities and to expend greater resources in order to successfully subvert the authentication process. Authentication at higher AALs can effectively reduce the risk of attacks. A high-level summary of the technical requirements for each of the AALs is provided below; see Sec. 4 and Sec. 5 of this document for specific normative requirements.

Authentication Assurance Level 1: AAL1 provides some assurance that the claimant controls an authenticator bound to the subscriber account. AAL1 requires either single-factor or multi-factor authentication using a wide range of available authentication technologies. Successful authentication requires that the claimant prove possession and control of the authenticator through a secure authentication protocol.

Authentication Assurance Level 2: AAL2 provides high confidence that the claimant controls one or more authenticators bound to the subscriber account. Proof of possession and control of two different authentication factors is required through secure authentication protocols. Approved cryptographic techniques are required at AAL2 and above.

Authentication Assurance Level 3: AAL3 provides very high confidence that the claimant controls one or more authenticators bound to the subscriber account. Authentication at AAL3 is based on proof of possession of a key through a cryptographic protocol. AAL3 authentication requires a hardware-based authenticator and a phishing-resistant authenticator (see Sec. 5.2.5); the same device may fulfill both these requirements. In order to authenticate at AAL3, claimants are required to prove possession and control of two distinct authentication factors through secure authentication protocols. Approved cryptographic techniques are required.

The following list states which sections of the document are normative and which are informative:

• 1 Purpose Informative
• 2 Introduction Informative
• 3 Definitions and Abbreviations Informative
• 4 Authentication Assurance Levels Normative
• 5 Authenticator and Verifier Requirements Normative
• 6 Authenticator Lifecycle Management Normative
• 7 Session Management Normative
• 8 Threat and Security Considerations Informative
• 9 Privacy Considerations Informative
• 10 Usability Considerations Informative
• 11 Equity Considerations Informative
• References Informative
• Appendix A Strength of Memorized Secrets Informative
• Appendix B Change Log Informative

Definitions and Abbreviations

定義と略語の完全な組み合わせについては [SP800-63] Appendix A を参照.

Definitions and Abbreviations

See [SP800-63], Appendix A for a complete set of definitions and abbreviations.

Authentication Assurance Levels

This section is normative.

与えられた AAL の要件を満たし, Subscriber として認識されるためには, Claimant は, そのレベルの要件と同等, またはそれ以上の強度のプロセスで Authenticate されることとする(SHALL). Authentication プロセスの結果は, Subscriber がその RP に対して Authentication する, それぞれの回で使用されることになる(SHALL) Identifier である. Identifier は Pseudonymous であってもよい(MAY). Subscriber Identifier は別の Subject に再利用されないほうがよい(SHOULD NOT)が, 以前に登録された Subject が CSP によって再登録された場合に再利用する必要がある(SHOULD). Subscriber を一意の Subject として識別するその他の属性も提供されることがある(MAY).

各 AAL での Authenticator と Verifier の詳細な Normative Requirement は Sec. 5 で提供される.

最も適切な AAL を選択する方法の詳細については [SP800-63] Sec. 5 を参照.

[FIPS140] 要件は, FIPS 140-3 か, それ以降のリビジョンで満たされる.

Identity Proofing の最中およびその後に収集された Personal Information は, Digital Identity サービスを介して Subscriber が利用できるようにしてもよい(MAY). 連邦政府機関によって任意の PII またはその他の Personal Information が開示されたりオンラインで利用可能になる場合, その情報が Self-asserted か Validated かにかかわらず, [EO13681] に従って Multi-Factor Authentication が要求される. したがって連邦政府機関は, PII またはその他の Personal Information をオンラインで利用可能にする場合には, 最低限 AAL2 を選択することになる(SHALL).

Authentication Assurance Level 1

AAL1 は, Claimant が Subscriber Account に Bind された Authenticator を制御するというある程度の保証を提供する. AAL1 は, 利用可能な幅広い Authentication 技術を使用した Single-Factor または Multi-Factor の Authentication を必要とする. Authentication の成功には, Claimant がセキュアな Authentication プロトコルを介して Authenticator の所有と制御を証明する必要がある.

Permitted Authenticator Types

AAL1 Authentication は, Sec. 5で定義されているいずれかの Authenticator タイプを使用することで発生することになる(SHALL).

• Memorized secret (Sec. 5.1.1)
• Look-Up secret (Sec. 5.1.2)
• Out-of-band device (Sec. 5.1.3)
• Single-factor one-time password (OTP) device (Sec. 5.1.4)
• Multi-factor OTP device (Sec. 5.1.5)
• Single-factor cryptographic software (Sec. 5.1.6)
• Single-factor cryptographic device (Sec. 5.1.7)
• Multi-factor cryptographic software (Sec. 5.1.8)
• Multi-factor cryptographic device (Sec. 5.1.9)

Authenticator and Verifier Requirements

AAL1 で使用される Cryptographic Authenticator は Approved な暗号を使用することになる(SHALL). オペレーティングシステムのコンテキスト内で動作する Software-Based Authenticator は, 可能な場合, それらが実行中のユーザーエンドポイントで(例: マルウェアによる)侵害の検出を試みてもよい(MAY). また, そのような侵害が検出された場合は操作を完了しないほうがよい(SHOULD NOT).

Claimant と Verifier の間の通信は, Authenticator Output の Confidentiality (機密性) と Adversary-in-the-Middle (AitM) Attack への耐性の提供のため, Authenticated Protected Channel を介して行われることになる(SHALL).

連邦政府機関によって, または連邦政府機関に代わって AAL1 で運用されている Verifier は, [FIPS140] Level 1 の要件に適合しているか検証されることになる(SHALL).

Reauthentication

Subscriber Session の定期的な Reauthentication は, Sec. 7.2 で説明される通りに実行されることになる(SHALL). AAL1 では, Subscriber の Reauthentication は, ユーザーのアクティビティに関係なく, 延長使用 Session の間は少なくとも30日に1回繰り返される必要がある(SHOULD).

Security Controls

CSP は, [SP800-53] または同等の連邦 (例: [FEDRAMP]) ないし業界標準で定義されたベースラインセキュリティコントロールから適切に調整されたセキュリティコントロールを採用することになる(SHALL). 参考とするガイドラインは, 保護する対象となる情報システム, アプリケーション, オンラインサービスのために組織が決定すること. CSP は, 適切なシステムまたは同等のシステムに対する最低限の assurance-related controls が満たされていることを保証することになる(SHALL).

Records Retention Policy

CSP は, 適用される可能性のある National Archives and Records Administration (NARA) の記録保持スケジュールを含む, 適用される法律, 規制, およびポリシーに従って, それぞれの記録保持ポリシーを遵守することになる(SHALL). CSP が必須要件がない場合に記録を保持することを選択した場合, CSP は, 記録を保持する期間を決定するためにプライバシーおよびセキュリティリスクのアセスメントを含むリスク管理プロセスを実施することになる(SHALL). また, そのリテンションポリシーを Subscriber へ通知することになる(SHALL).

Authentication Assurance Level 2

AAL2 は, Claimant が Subscriber Account に Bind された Authenticator を制御するという高い確信を提供する. セキュアな Authentication プロトコルを介して, 2つの明確に異なる Authentication Factor の所有と制御の証明が必要である. AAL2 以上では, Approved な暗号技術が必要である.

Permitted Authenticator Types

AAL2 Authentication は, Multi-Factor Authenticator か, 2つの Single-Factor Authenticator の組み合わせのいずれかを使用することで発生することになる (SHALL). Multi-Factor Authenticator は, 単一の Authentication イベントを実行するために2つの要素を必要とする. 例として, デバイスを Activate するために必要となる Biometric センサーが統合された暗号的にセキュアなデバイスなどが挙げられる. Authenticator の要件は Sec. 5 に指定されている.

Multi-Factor Authenticator が使用されるとき, 以下のいずれかが使用されてもよい(MAY).

• Multi-Factor Out-of-Band Authenticator (Sec. 5.1.3.4)
• Multi-Factor OTP Device (Sec. 5.1.5)
• Multi-Factor Cryptographic Software (Sec. 5.1.8)
• Multi-Factor Cryptographic Device (Sec. 5.1.9)

2つの Single-Factor Authenticator の組み合わせが使用されるとき, その組み合わせは, 以下のリストから1つの Memorized Secret Authenticator (Sec. 5.1.1) と 1つの物理 Authenticator (すなわち, “something you have”) を含むことになる(SHALL).

• Look-Up Secret (Sec. 5.1.2)
• Out-of-Band Device (Sec. 5.1.3)
• Single-Factor OTP Device (Sec. 5.1.4)
• Single-Factor Cryptographic Software (Sec. 5.1.6)
• Single-Factor Cryptographic Device (Sec. 5.1.7)

Note: Biometric Authentication が Sec. 5.2.3 の要件を満たすとき, Biometric の一致に加えて, デバイスが Authenticate されなければならない. Biometric の特徴は1つの要素として認識されるが, それ自体は Authenticator とは認識されない. したがって, Biometric の特徴による Authentication を行う場合, 関連付けられたデバイスは “something you have” として働き, 同時に Biometric の一致は “something you are” として働くため, 2つの Authenticator を使用することは不要である.

Authenticator and Verifier Requirements

AAL2 で使用される Cryptographic Authenticator は Approved Cryptography を使用することになる(SHALL). 連邦政府機関によって調達された Authenticator は [FIPS140] Level 1 の要件に適合していることを検証されることになる(SHALL). オペレーティングシステムのコンテキスト内で動作する Software-Based Authenticator は, 可能な場合, それらが実行中のプラットフォームで(例: マルウェアによる)侵害の検出を試みてもよい(MAY). また, そのような侵害が検出された場合は操作を完了しないべきである (SHOULD NOT). AAL2 で使用される少なくとも1つの Authenticator は, Sec. 5.2.8 で説明されているように, リプレイ耐性を持つことになる(SHALL). AAL2 での Authentication は, Sec. 5.2.9 で説明されているように, 少なくとも1つの Authenticator から Authentication Intent を実施する必要がある(SHOULD).

Claimant と Verifier の間の通信は, Authenticator Output の Confidentiality (機密性) と AitM Attack への耐性の提供のため, Authenticated Protected Channel を介して行われることになる(SHALL).

連邦政府機関によって, または連邦政府機関に代わって AAL2 で運用されている Verifier は, [FIPS140] Level 1 の要件に適合しているか検証されることになる(SHALL).

AAL2 での Authentication に Bimetric Factorが使用される場合, Sec. 5.2.3 で述べられるパフォーマンス要件を満たすことになり(SHALL), Verifier は Bometric センサーとその後の Processing がこれらの要件を満たしていることを判断するべきである(SHOULD).

OMB Memorandum [M-22-09] は, 連邦政府機関に対して AAL2 のパブリックユーザーに少なくとも1つの Phishing 耐性のある Authenticator のオプションを提供することを要求している. Sec. 5.2.5 で説明されている Phishing 耐性は通常 AAL2 での Authentication には必要とされないが, Phishing は重大な脅威ベクトルであるため, Verifier は可能な限り AAL2 での Phishing 耐性のある Authenticator の使用を奨励するべきである(SHOULD).

Reauthentication

Subscriber Session の定期的な Reauthentication は, Sec. 7.2 で説明される通りに実行されることになる(SHALL). AAL2 では, Subscriber の Authentication は, ユーザーのアクティビティに関係なく, 延長使用 Session の間は少なくとも12時間に1回繰り返されることになる(SHALL). Subscriber の Reauthentication は, 30分以上続く非アクティブ期間の後に繰り返されることになる(SHALL). これらのタイムリミットのいずれかに到達した場合, Session は終了(つまり, ログアウト)されることになる(SHALL).

タイムリミットにまだ到達していない Session の Reauthentication には, Memorized Secret またはまだ有効な Session Secret と組み合わせた Biometric のみが必要とされるとしてもよい(MAY). Verifier は, 非アクティブタイムアウトの直前に, アクティビティを行うようにユーザーを促してもよい(MAY).

Security Controls

CSP は, [SP800-53] または同等の連邦 (例: [FEDRAMP]) ないし業界標準で定義されたベースラインセキュリティコントロールから適切に調整されたセキュリティコントロールを採用することになる(SHALL). 参考とするガイドラインは, 保護する対象となる情報システム, アプリケーション, オンラインサービスのために組織が決定すること. CSP は, 適切なシステムまたは同等のシステムに対する最低限の assurance-related controls が満たされていることを保証することになる(SHALL).

Records Retention Policy

CSP は, 適用される可能性のある NARA の記録保持スケジュールを含む, 適用される法律, 規制, およびポリシーに従って, それぞれの記録保持ポリシーを遵守することになる(SHALL). CSP が必須要件がない場合に記録を保持することを選択した場合, CSP は, 記録を保持する期間を決定するためにプライバシーおよびセキュリティリスクのアセスメントを含むリスク管理プロセスを実施することになる(SHALL). また, そのリテンションポリシーを Subscriber へ通知することになる(SHALL).

Authentication Assurance Level 3

AAL3 は, Claimant が Subscriber Account に Bind された Authenticator を制御するという非常に高い確信を提供する. AAL3 での Authentication は, 暗号プロトコルを介した Key の所有の証明に基づく. ハードウェアベースの Authenticator とPhishing 耐性のある Authenticator を使用することになり(SHALL), 同じデバイスがこれらの両方の要件を満たしてもよい(MAY). AAL3 で Authentication を行うには, Claimant は, セキュアな Authentication プロトコルを介して, 2つのはっきりと異なる Authentication Factor の所有と制御を証明することになる(SHALL). Approved な暗号技術が必要である.

Permitted Authenticator Types

AAL3 Authentication は, Sec. 4.3 の要件を満たす Authenticator の組み合わせのうちのひとつを使用することで発生することになる(SHALL). 可能性のある組み合わせは:

• Multi-Factor Cryptographic Device (Sec. 5.1.9)
• Single-Factor Cryptographic Device (Sec. 5.1.7) used in conjunction with a Memorized Secret (Sec. 5.1.1)
• Multi-Factor OTP device (software or hardware) (Sec. 5.1.5) used in conjunction with a Single-Factor Cryptographic Device (Sec. 5.1.7)
• Multi-Factor OTP device (hardware only) (Sec. 5.1.5) used in conjunction with a Single-Factor Cryptographic Software (Sec. 5.1.6)
• Single-Factor OTP device (hardware only) (Sec. 5.1.4) used in conjunction with a Multi-Factor Cryptographic Software Authenticator (Sec. 5.1.8)

Authenticator and Verifier Requirements

Claimant と Verifier の間の通信は, Authenticator Output の Confidentiality (機密性) と AitM Attack への耐性の提供のため, Authenticated Protected Channel を介して行われることになる(SHALL). AAL3で使用される少なくとも1つの Authenticator は, Sec. 5.2.5 で説明されているよ うにPhishing 耐性があり(SHALL), Sec. 5.2.8 で説明されているようにリプレイ耐性があることになる(SHALL). AAL3 でのすべての Authentication と Reauthentication は, Sec. 5.2.9 で説明されているように, 少なくとも1つの Authenticator から Authentication Intent を示す必要がある(SHOULD).

AAL3 で使用される Multi-factor Authenticator は, [FIPS140] レベル 2 以上で検証されたハードウェア暗号モジュールか, 少なくとも [FIPS140] レベル 3 を全体的に上回る物理セキュリティとなる(SHALL). AAL3 で使用される Single-factor Cryptographic Device は, [FIPS140] レベル 1 で検証されるか, 少なくとも [FIPS140] レベル 3 を全体的に上回る物理セキュリティとなる(SHALL).

AAL3 の Verifier は, [FIPS140] レベル 1 かそれ以上で検証されることになる(SHALL).

AAL3 の Verifier は, Sec. 5.2.7 で説明されているように, 少なくとも1つの Authentication Factor に関して, Verifier の危殆化耐性があることになる(SHALL).

AAL3 のハードウェアベースの Authenticator と Verifier は, 関連する Side-Channel Attack (例: タイミングや消費電力の分析) に resist する必要がある(SHOULD).

AAL3 での Authentication に Biometric Factor が 使用される場合, Verifier は Bometric Sensor とその後の Processing が Sec. 5.2.3 で述べられるパフォーマンス要件を満たしていることを判断することになる(SHALL).

Reauthentication

Subscriber Session の定期的な Reauthentication は, Sec. 7.2 で説明される通りに実行されることになる(SHALL). AAL3 では, Sec. 7.2で説明される通り, Subscriber の Authentication は, ユーザーのアクティビティに関係なく, 延長使用 Session の間は少なくとも12時間に1回繰り返されることになる(SHALL). Subscriber の Reauthentication は, 15分以上続く非アクティブ期間の後に繰り返されることになる(SHALL). Reauthentication は両方の Authentication Factor を使用することになる(SHALL). これらのタイムリミットのいずれかに到達した場合, Session は終了(つまり, ログアウト)されることになる(SHALL). Verifier は, 非アクティブタイムアウトの直前に, アクティビティを行うようにユーザーを促してもよい(MAY).

Security Controls

CSP は, [SP800-53] または同等の連邦 (例: [FEDRAMP]) ないし業界標準で定義されたベースラインセキュリティコントロールから適切に調整されたセキュリティコントロールを採用することになる(SHALL). 参考とするガイドラインは, 保護する対象となる情報システム, アプリケーション, オンラインサービスのために組織が決定すること. CSP は, 適切なシステムまたは同等のシステムに対する最低限の assurance-related controls が満たされていることを保証することになる(SHALL).

Records Retention Policy

CSP は, 適用される可能性のある NARA の記録保持スケジュールを含む, 適用される法律, 規制, およびポリシーに従って, それぞれの記録保持ポリシーを遵守することになる(SHALL). CSP が必須要件がない場合に記録を保持することを選択した場合, CSP は, 記録を保持する期間を決定するためにプライバシーおよびセキュリティリスクのアセスメントを含むリスク管理プロセスを実施することになる(SHALL). また, そのリテンションポリシーを Subscriber へ通知することになる(SHALL).

Privacy Requirements

CSP は, [SP800-53] または同等の業界標準で定義された, 適切に誂えられたプライバシーコントロールを採用することになる(SHALL).

CSP が Identity Proofing, Authentication, Attribute Assertion (総称して “Identity Service”), 関連する不正行為の軽減, または法律や法的手続きの遵守以外の目的で Attribute を処理する場合, CSP は 追加の処理から生じるプライバシーのリスクに見合った Predictability と Manageability を維持するための手段を実装することになる(SHALL). 手段には, 明確な通知の提供, Subscriber の同意の取得, Attribute の選択的な使用・開示の有効化を含んでもよい(MAY). CSP が同意を手段として使用する場合, CSP は追加の処理の同意を Identity Service の条件にしてはならない(SHALL NOT).

CSP が政府機関であるか民間セクターの Provider であるかに関わらず, Authentication Service を提供または使用する連邦政府機関には, 以下の要件が適用される:

1. 政府機関は, Senior Agency Official for Privacy (SAOP) と相談し, Authenticator を発行または維持するための PII の収集が [PrivacyAct] (Sec. 9.4 を参照) の要件をトリガーするかどうか判断するために分析を実施することになる(SHALL).
2. 政府機関は, 該当する場合, そのような収集を対象とする System of Records Notice (SORN) を公開することになる(SHALL).
3. 政府機関は, SAOP と相談し, Authenticator を発行または維持するための PII の収集が E-Government Act of 2002 [E-Gov].の要件をトリガーするかどうか判断するために分析を実施することになる(SHALL).
4. 政府機関は, 該当する場合, そのような収集を対象とする Privacy Impact Assessment (PIA) を公開することになる(SHALL).

Summary of Requirements

Table 1 は, 各 AAL の要件の non-normative な要約を提供する.

Table 1 AAL Summary of Requirements

Authentication Assurance Levels

This section is normative.

To satisfy the requirements of a given AAL and be recognized as a subscriber, a claimant SHALL be authenticated with a process whose strength is equal to or greater than the requirements at that level. The result of an authentication process is an identifier that SHALL be used each time that subscriber authenticates to that RP. The identifier MAY be pseudonymous. Subscriber identifiers SHOULD NOT be reused for a different subject but SHOULD be reused when a previously enrolled subject is re-enrolled by the CSP. Other attributes that identify the subscriber as a unique subject MAY also be provided.

Detailed normative requirements for authenticators and verifiers at each AAL are provided in Sec. 5.

See [SP800-63] Sec. 5 for details on how to choose the most appropriate AAL.

[FIPS140] requirements are satisfied by FIPS 140-3 or newer revisions.

Personal information collected during and subsequent to identity proofing MAY be made available to the subscriber by the digital identity service. The release or online availability of any PII or other personal information, whether self-asserted or validated, by federal government agencies requires multi-factor authentication in accordance with [EO13681]. Therefore, federal government agencies SHALL select a minimum of AAL2 when PII or other personal information is made available online.

Authentication Assurance Level 1

AAL1 provides some assurance that the claimant controls an authenticator bound to the subscriber account. AAL1 requires either single-factor or multi-factor authentication using a wide range of available authentication technologies. Successful authentication requires that the claimant prove possession and control of the authenticator through a secure authentication protocol.

Permitted Authenticator Types

AAL1 authentication SHALL occur by the use of any of the following authenticator types, which are defined in Sec. 5:

• Memorized secret (Sec. 5.1.1)
• Look-Up secret (Sec. 5.1.2)
• Out-of-band device (Sec. 5.1.3)
• Single-factor one-time password (OTP) device (Sec. 5.1.4)
• Multi-factor OTP device (Sec. 5.1.5)
• Single-factor cryptographic software (Sec. 5.1.6)
• Single-factor cryptographic device (Sec. 5.1.7)
• Multi-factor cryptographic software (Sec. 5.1.8)
• Multi-factor cryptographic device (Sec. 5.1.9)

Authenticator and Verifier Requirements

Cryptographic authenticators used at AAL1 SHALL use approved cryptography. Software-based authenticators that operate within the context of an operating system MAY, where applicable, attempt to detect compromise (e.g., by malware) of the user endpoint in which they are running and SHOULD NOT complete the operation when such a compromise is detected.

Communication between the claimant and verifier SHALL be via an authenticated protected channel to provide confidentiality of the authenticator output and resistance to adversary-in-the-middle (AitM) attacks.

Verifiers operated by or on behalf of federal government agencies at AAL1 SHALL be validated to meet the requirements of [FIPS140] Level 1.

Reauthentication

Periodic reauthentication of subscriber sessions SHALL be performed as described in Sec. 7.2. At AAL1, reauthentication of the subscriber SHOULD be repeated at least once per 30 days during an extended usage session, regardless of user activity. The session SHOULD be terminated (i.e., logged out) when this time limit is reached.

Security Controls

The CSP SHALL employ appropriately tailored security controls from the baseline security controls defined in [SP800-53] or equivalent federal (e.g., [FEDRAMP]) or industry standard that the organization has determined for the information systems, applications, and online services that these guidelines are used to protect. The CSP SHALL ensure that the minimum assurance-related controls for the appropriate systems, or equivalent, are satisfied.

Records Retention Policy

The CSP SHALL comply with its respective records retention policies in accordance with applicable laws, regulations, and policies, including any National Archives and Records Administration (NARA) records retention schedules that may apply. If the CSP opts to retain records in the absence of any mandatory requirements, the CSP SHALL conduct a risk management process, including assessments of privacy and security risks, to determine how long records should be retained and SHALL inform the subscriber of that retention policy.

Authentication Assurance Level 2

AAL2 provides high confidence that the claimant controls authenticators bound to the subscriber account. Proof of possession and control of two distinct authentication factors is required through secure authentication protocols. Approved cryptographic techniques are required at AAL2 and above.

Permitted Authenticator Types

At AAL2, authentication SHALL occur by the use of either a multi-factor authenticator or a combination of two single-factor authenticators. A multi-factor authenticator requires two factors to execute a single authentication event, such as a cryptographically secure device with an integrated biometric sensor that is required to activate the device. Authenticator requirements are specified in Sec. 5.

When a multi-factor authenticator is used, any of the following MAY be used:

• Multi-Factor Out-of-Band Authenticator (Sec. 5.1.3.4)
• Multi-Factor OTP Device (Sec. 5.1.5)
• Multi-Factor Cryptographic Software (Sec. 5.1.8)
• Multi-Factor Cryptographic Device (Sec. 5.1.9)

When a combination of two single-factor authenticators is used, the combination SHALL include a Memorized Secret authenticator (Sec. 5.1.1) and one physical authenticator (i.e., “something you have”) from the following list:

• Look-Up Secret (Sec. 5.1.2)
• Out-of-Band Device (Sec. 5.1.3)
• Single-Factor OTP Device (Sec. 5.1.4)
• Single-Factor Cryptographic Software (Sec. 5.1.6)
• Single-Factor Cryptographic Device (Sec. 5.1.7)

Note: When biometric authentication meets the requirements in Sec. 5.2.3, the device has to be authenticated in addition to the biometric match. A biometric characteristic is recognized as a factor, but not recognized as an authenticator by itself. Therefore, when conducting authentication with a biometric characteristic, it is unnecessary to use two authenticators because the associated device serves as “something you have,” while the biometric match serves as “something you are.”

Authenticator and Verifier Requirements

Cryptographic authenticators used at AAL2 SHALL use approved cryptography. Authenticators procured by federal government agencies SHALL be validated to meet the requirements of [FIPS140] Level 1. Software-based authenticators that operate within the context of an operating system MAY, where applicable, attempt to detect compromise (e.g., by malware) of the platform in which they are running. They SHOULD NOT complete the operation when such a compromise is detected. At least one authenticator used at AAL2 SHALL be replay resistant as described in Sec. 5.2.8. Authentication at AAL2 SHOULD demonstrate authentication intent from at least one authenticator as discussed in Sec. 5.2.9.

Communication between the claimant and verifier SHALL be via an authenticated protected channel to provide confidentiality of the authenticator output and resistance to AitM attacks.

Verifiers operated by or on behalf of federal government agencies at AAL2 SHALL be validated to meet the requirements of [FIPS140] Level 1.

When a biometric factor is used in authentication at AAL2, the performance requirements stated in Sec. 5.2.3 SHALL be met, and the verifier SHOULD make a determination that the biometric sensor and subsequent processing meet these requirements.

OMB Memorandum [M-22-09] requires federal government agencies to offer at least one phishing-resistant authenticator option to public users at AAL2. While phishing resistance as described in Sec. 5.2.5 is not generally required for authentication at AAL2, verifiers SHOULD encourage the use of phishing-resistant authenticators at AAL2 whenever practical since phishing is a significant threat vector.

Reauthentication

Periodic reauthentication of subscriber sessions SHALL be performed as described in Sec. 7.2. At AAL2, authentication of the subscriber SHALL be repeated at least once per 12 hours during an extended usage session, regardless of user activity. Reauthentication of the subscriber SHALL be repeated following any period of inactivity lasting 30 minutes or longer. The session SHALL be terminated (i.e., logged out) when either of these time limits is reached.

Reauthentication of a session that has not yet reached its time limit MAY require only a memorized secret or a biometric in conjunction with the still-valid session secret. The verifier MAY prompt the user to cause activity just before the inactivity timeout.

Security Controls

The CSP SHALL employ appropriately tailored security controls from the baseline security controls defined in [SP800-53] or equivalent federal (e.g., [FEDRAMP]) or industry standard that the organization has determined for the information systems, applications, and online services that these guidelines are used to protect. The CSP SHALL ensure that the minimum assurance-related controls for the appropriate systems, or equivalent, are satisfied.

Records Retention Policy

The CSP SHALL comply with its respective records retention policies in accordance with applicable laws, regulations, and policies, including any NARA records retention schedules that may apply. If the CSP opts to retain records in the absence of any mandatory requirements, the CSP SHALL conduct a risk management process, including assessments of privacy and security risks to determine how long records should be retained and SHALL inform the subscriber of that retention policy.

Authentication Assurance Level 3

AAL3 provides very high confidence that the claimant controls authenticators bound to the subscriber account. Authentication at AAL3 is based on proof of possession of a key through a cryptographic protocol. AAL3 authentication SHALL use a hardware-based authenticator and an authenticator that provides phishing resistance — the same device MAY fulfill both these requirements. In order to authenticate at AAL3, claimants SHALL prove possession and control of two distinct authentication factors through secure authentication protocols. Approved cryptographic techniques are required.

Permitted Authenticator Types

AAL3 authentication SHALL occur by the use of one of a combination of authenticators satisfying the requirements in Sec. 4.3. Possible combinations are:

• Multi-Factor Cryptographic Device (Sec. 5.1.9)
• Single-Factor Cryptographic Device (Sec. 5.1.7) used in conjunction with a Memorized Secret (Sec. 5.1.1)
• Multi-Factor OTP device (software or hardware) (Sec. 5.1.5) used in conjunction with a Single-Factor Cryptographic Device (Sec. 5.1.7)
• Multi-Factor OTP device (hardware only) (Sec. 5.1.5) used in conjunction with a Single-Factor Cryptographic Software (Sec. 5.1.6)
• Single-Factor OTP device (hardware only) (Sec. 5.1.4) used in conjunction with a Multi-Factor Cryptographic Software Authenticator (Sec. 5.1.8)

Authenticator and Verifier Requirements

Communication between the claimant and verifier SHALL be via an authenticated protected channel to provide confidentiality of the authenticator output and resistance to AitM attacks. At least one cryptographic authenticator used at AAL3 SHALL be phishing resistant as described in Sec. 5.2.5 and SHALL be replay resistant as described in Sec. 5.2.8. All authentication and reauthentication processes at AAL3 SHALL demonstrate authentication intent from at least one authenticator as described in Sec. 5.2.9.

Multi-factor authenticators used at AAL3 SHALL be hardware cryptographic modules validated at [FIPS140] Level 2 or higher overall with at least [FIPS140] Level 3 physical security. Single-factor cryptographic devices used at AAL3 SHALL be validated at [FIPS140] Level 1 or higher overall with at least [FIPS140] Level 3 physical security.

Verifiers at AAL3 SHALL be validated at [FIPS140] Level 1 or higher.

Verifiers at AAL3 SHALL be verifier compromise resistant as described in Sec. 5.2.7 with respect to at least one authentication factor.

Hardware-based authenticators and verifiers at AAL3 SHOULD resist relevant side-channel (e.g., timing and power-consumption analysis) attacks.

When a biometric factor is used in authentication at AAL3, the verifier SHALL make a determination that the biometric sensor and subsequent processing meet the performance requirements stated in Sec. 5.2.3.

Reauthentication

Periodic reauthentication of subscriber sessions SHALL be performed as described in Sec. 7.2. At AAL3, authentication of the subscriber SHALL be repeated at least once per 12 hours during an extended usage session, regardless of user activity, as described in Sec. 7.2. Reauthentication of the subscriber SHALL be repeated following any period of inactivity lasting 15 minutes or longer. Reauthentication SHALL use both authentication factors. The session SHALL be terminated (i.e., logged out) when either of these time limits is reached. The verifier MAY prompt the user to cause activity just before the inactivity timeout.

Security Controls

The CSP SHALL employ appropriately tailored security controls from the baseline security controls defined in [SP800-53] or equivalent federal (e.g., [FEDRAMP]) or industry standard that the organization has determined for the information systems, applications, and online services that these guidelines are used to protect. The CSP SHALL ensure that the minimum assurance-related controls for the appropriate systems, or equivalent, are satisfied.

Records Retention Policy

The CSP SHALL comply with its respective records retention policies in accordance with applicable laws, regulations, and policies, including any NARA records retention schedules that may apply. If the CSP opts to retain records in the absence of any mandatory requirements, the CSP SHALL conduct a risk management process, including assessments of privacy and security risks, to determine how long records should be retained and SHALL inform the subscriber of that retention policy.

Privacy Requirements

The CSP SHALL employ appropriately tailored privacy controls defined in [SP800-53] or equivalent industry standard.

If CSPs process attributes for purposes other than identity proofing, authentication, or attribute assertions (collectively “identity service”), related fraud mitigation, or to comply with law or legal process, CSPs SHALL implement measures to maintain predictability and manageability commensurate with the privacy risk arising from the additional processing. Measures MAY include providing clear notice, obtaining subscriber consent, or enabling selective use or disclosure of attributes. When CSPs use consent measures, CSPs SHALL NOT make consent for the additional processing a condition of the identity service.

Regardless of whether the CSP is an agency or private sector provider, the following requirements apply to a federal agency offering or using the authentication service:

1. The agency SHALL consult with their Senior Agency Official for Privacy (SAOP) and conduct an analysis to determine whether the collection of PII to issue or maintain authenticators triggers the requirements of the Privacy Act of 1974 [PrivacyAct] (see Sec. 9.4).
2. The agency SHALL publish a System of Records Notice (SORN) to cover such collections, as applicable.
3. The agency SHALL consult with their SAOP and conduct an analysis to determine whether the collection of PII to issue or maintain authenticators triggers the requirements of the E-Government Act of 2002 [E-Gov].
4. The agency SHALL publish a Privacy Impact Assessment (PIA) to cover such collection, as applicable.

Summary of Requirements

Table 1 provides a non-normative summary of the requirements for each of the AALs.

Table 1 AAL Summary of Requirements

Authenticator and Verifier Requirements

This section is normative.

このセクションでは, 各 Authenticator タイプ固有の詳細な要件を提供する. Sec. 4で指定された Reauthentication の要件および Sec. 5.2.5 で説明された AAL3 での Phishing 耐性のための要件を除いて, Authenticator が使用される AAL に関係なく, 各 Authenticator タイプの技術要件は同じである.

Requirements by Authenticator Type

Memorized Secrets

Memorized Secret Authenticator — 一般に Password または数値の場合は PIN と言われる — は, ユーザーによって選択され記憶されることを意図した秘密の値である. Memorized Secret は, Attacker が正しい Secret Value を推測または発見することが現実的でないように, 十分に複雑で秘匿されている必要がある. Memorized Secret は something you know である.

このセクションの要件は, Authenticated Protected Channel を介して CSP の Verifier に送信される, 独立した Authentication Factor として使用される中央で検証された Memorized Secret に適用される. Multi-Factor Authenticator によってローカルで使用される Memorized Secret は, Activation Secret と呼ばれ, Sec. 5.2.11 で議論される.

Memorized Secret Authenticators

Memorized Secret は, 長さが少なくとも8文字となる(SHALL). Memorized Secret は, Subscriber によって選択されるか, CSP によってランダムに割り当てられることとなる(SHALL).

CSP が, 頻繁に使用される, 予期される, または侵害されている値の Blocklist にあるために, 選択された Memorized Secret を許可しない場合 (Sec. 5.1.1.2 を参照), Subscriber は別の Memorized Secret を選択することになる(SHALL). Memorized Secret に他の複雑さの要件が課されることはない(SHALL). この根拠は, Appendix A Strength of Memorized Secrets に示される.

Memorized Secret Verifiers

Verifier は, 長さが少なくとも8文字の Memorized Secret を要求することとする(SHALL). Verifier は, Memorized Secret の長さが少なくとも64文字であることを許可する必要がある(SHOULD). すべての Printing ASCII 文字 [RFC20] と空白文字は Memorized Secret に受け入れられる必要がある(SHOULD). Unicode 文字 [ISO/ISC 10646] も同様に受け入れられる必要がある(SHOULD). Verifier は, Verification の前に先頭と末尾の空白文字を削除したり, 先頭の文字の大文字と小文字が異なる Memorized Secret の Verification を許可したり, 残りの文字数が8文字以上ある場合に先頭の文字の大文字・小文字が異なっていることを許したりなど, タイプミスの可能性を許容してもよい(MAY).

Verifier は, 提出された Memorized Secret 全体を検証することになる(SHALL)(つまり, Secret を切り詰めない). 前述の長さの要件に関して, 各 Unicode コードポイントは1文字としてカウントされることになる(SHALL).

Memorized Secret でUnicode文字が受け入れられる場合, Verifier は Sec. 12.1 of Unicode Normalization Forms [UAX15] で定義された NFKC または NFKD 正規化を使用して, スタビライズされた文字列の正規化プロセスを適用する必要がある(SHOULD). このプロセスは, Memorized Secret を表すバイト文字列をHash する前に適用される. Unicode 文字を含む Memorized Secret を選択する Subscriber は, 一部の文字が一部のエンドポイントによって異なる方法で表現される可能性があることを通知される必要がある(SHOULD). これは, 正常に Authenticate する能力に影響を与える可能性がある.

Memorized Secret の Verifier は, Subscriber に対して, Authenticate されていない Claimant がアクセスできるヒントを保存することを許可することはない(SHALL NOT). Verifier は, Memorized Secret を選択する際に, Subscriber に特定の種類の情報 (例えば, 「あなたの最初のペットの名前は何ですか?」といった Knowledge-Based Authentication (KBA) または秘密の質問として知られる手法) を使用するように促すことはない(SHALL NOT).

Memorized Secret を確立および変更するリクエストを処理するとき, Verifier は, 頻繁に使用される, 予期される, または侵害されていることが知られている値を含む Blocklist と, リクエストされた Secret を比較することになる(SHALL). 例えば, リストには以下を含んでもよい(MAY) が, これらに限定されない:

• 以前の侵害事例から得られた Password.
• 辞書の単語.
• 反復または連続した文字 (例: ‘aaaaaa’, ‘1234abcd’).
• サービスの名前, ユーザー名, およびその派生語など, コンテキスト特有の単語.

選択された Secret が Blocklist の中にある場合, CSP または Verifier は Subscriber に別の Secret を選択する必要があることを通知することとなり(SHALL), 拒否の理由を提供することになり(SHALL), Subscriber に別の値を選択することを要求することになる(SHALL). Blocklist はブルートフォース Attack を防御するために使用され, 試行の失敗は以下で説明するようにレート制限されるため, Blocklist は Subscriber が Attacker が試行リミットに到達する前に推測する可能性のある Memorized Secret を選択することを防ぐのに十分なサイズにする必要がある(SHOULD). 過度に大きな Blocklist は使用しないほうがよい(SHOULD NOT). これは, Subscriber が許容される Memorized Secret を確立しようとする試みを妨げ, 大幅に改善されたセキュリティを提供しないためである.

Verifierは, 強力な Memorized Secret を選択する際にユーザーを支援するために, Subscriber にガイダンスを提供することとなる(SHALL). これは, リストされた (そしておそらく非常に弱い) Memorized Secret への浅はかな変更を思いとどまらせるため, 上記のリストにある Memorized Secret の拒否に続いて特に重要である. [Blocklists]

Verifier は, Sec. 5.2.2 で説明されている通り, Subscriber Account で試行できる Authentication の失敗回数を効果的に制限するレート制限メカニズムを実装することとなる(SHALL).

Verifier は, Memorized Secret に他の構成ルールを課すことはない(SHALL NOT) (例: 異なる文字タイプの混合の要求, 連続して繰り返される文字の禁止). Verifier は, Memorized Secret を定期的に変更することをユーザーに要求することはない(SHALL NOT). ただし, Authenticator の侵害の証拠がある場合, Verifier は変更を強制することとなる(SHALL).

Verifier は, Passwordマネージャーの使用を許可することになる(SHALL). それらを使用しやすくするために, Verifier は, Memorized Secret を入力するときに, Claimant が「貼り付け」機能の使用を許可ことになる(SHALL). Passwordマネージャーは, ユーザーがより強力な Memorized Secret を選択する可能性を高める場合がある.

Claimant が Memorized Secret を正常に入力することを支援するために, Verifier は, 入力されている間および Verifier に送信されるまで, 一連のドットやアスタリスクではなく, Secret を表示するオプションを提供する必要がある(SHOULD). これにより Claimant は, 自分の画面が観察される可能性が低い場所にいる場合, 自分の入力を確認できる. Verifier は, 各文字が入力された後, 正しく入力したかを確認するために入力された個々の文字を短時間表示することを Claimant のデバイスに許可してもよい(MAY). これは, モバイルデバイスでは一般的である.

Verifier は, Memorized Secret を要求するときには, 盗聴や Adversary-in-the-Middle Attack に対する耐性を提供するために, Approved な暗号による暗号化と Authenticated Protected Channel を使用することになる(SHALL).

Verifier は, Memorized Secret を Offline Attack に耐性のある形式で保存することになる(SHALL). Memorized Secret は, 適切な Password Hash スキームを使用して Salt および Hash されることになる(SHALL). Password Hash スキームは, Password, Salt, およびコストファクターを入力として受け取り, Password Hash を生成する. それらの目的は, Hash された Password ファイルを取得した Attacker に対して, 各 Password の推測をより高価なものにし, それによって推測攻撃のコストを高くしたり法外なものにしたりすることである. Attack のコストを増加させるため, Memory-Hard と Compute-Hard の両方の性質を持つ関数を使用する必要がある(SHOULD). NIST は特定の Password Hash スキームに関するガイドラインを公開していないが, そのような関数の例には Argon2 [Argon2] や scrypt [Scrypt] などがある. Approved な一方向関数の例には, Keyed Hash Message Authentication Code (HMAC) [FIPS198-1], [SP800-107] で Approved ないずれかの Hash 関数, Secure Hash Algorithm 3 (SHA-3) [FIPS202], CMAC [SP800-38B], Keccak Message Authentication Code (KMAC), Customizable SHAKE (cSHAKE), および ParallelHash [SP800-185] が含まれる. Password Hash スキームが処理した出力の長さは, 基になる一方向関数の出力の長さと同じである必要がある(SHOULD).

Salt は長さが少なくとも 32 ビットとなり, 保存された Hash 間の Salt 値の衝突を最小限に抑えるためにばらついて選択されることとなる(SHALL). Salt 値と結果の Hash の両方が, Memorized Secret Authenticator ごとに保存されることとなる(SHALL).

Password-based Key Derivation Function 2 (PBKDF2) [SP800-132] の場合, コストファクターは反復回数である. PBKDF2 関数が反復される回数が多いほど, Password Hash の計算に時間がかかる. したがって, 反復回数は, Verification サーバのパフォーマンスが許す限り大きくする必要がある(通常, 少なくとも10,000回の反復)(SHOULD).

さらに, Verifier は, Verifier のみが知っている Secret Key を使用して, 鍵付き Hash または暗号化オペレーションの追加の反復を実行する必要がある(SHOULD). この Key 値を使用する場合, Approved Random Bit Generator [SP800-90Ar1] によって生成され, 少なくとも NIST SP 800-131A Transitioning the Use of Cryptographic Algorithms and Key Lengths [SP800-131A] の最新リビジョンで指定されている最小のセキュリティ強度を提供することとなる(この発行日時点で112ビット)(SHALL). Secret Key の値は, Hash された Memorized Secret とは別に保存されることとなる(例えば, Hardware Security Moduleのような特別なデバイスに)(SHALL). この追加の反復により, Secret Key の値が秘密のままである限り, Hash された Memorized Secret に対するブルートフォース Attack は非現実的である.

Look-Up Secrets

Look-up Secret Authenticator は, Claimant と CSP の間で共有される一連の Secret を格納する物理的または電子的な記録である. Claimant は, Verifier からのプロンプトに応答するために必要な, 適切な Secret を見つけるために Authenticator を使用する. 例えば, Verifier は, 表形式でカードに印刷された数値または文字列の特定のサブセットを提供するように Claimant に尋ねることができる. Look-up Secret の一般的な用途は, 別の Authenticator が紛失されたり故障した場合に使用するために, Subscriber によって保管された1回限りの”回復キー”としての使用である. Look-up Secret は something you have である.

Look-Up Secret Authenticators

Look-up Secret Authenticator を作成する CSP は, Approved Random Bit Generator [SP800-90Ar1] を使用して Secret のリストを生成することとなり(SHALL), Authenticator を Subscriber に安全に配布することとなる(SHALL). Look-up Secret は, 少なくとも20ビットの Entropy を持つこととなる(SHALL).

Look-up Secret Authenticator は, CSP が対面で, Subscriber の Address of Record へ郵便で, またはオンラインで配布してもよい(MAY). オンラインで配布される場合, Look-up Secret は Sec. 6.1.2 にある Post-Enrollment Binding の要件に従って, セキュアなチャネルを介して配布されることとなる(SHALL).

Authenticator がリストからシーケンシャルに Look-up Secret を使用する場合, Authentication が成功した後に限り, Subscriber は使用済みの Secret を破棄してもよい(MAY).

Look-Up Secret Verifiers

Look-up Secret の Verifier は, Claimant に, 彼らの Authenticator からの次の Secret, または特定の (例えば, 番号が振られた) Secret を要求することとなる(SHALL). Authenticator から与えられた Secret は, 一度だけ成功として使用されることとなる(SHALL). Look-up Secret がグリッド カードから得られたものである場合, グリッドの各セルは一度だけ使用されることとなる(SHALL).

Verifier は, Offline Attack に耐性のある形式で Look-up Secret を保存することとなる(SHALL). 少なくとも 112 ビットの Entropy を持つ Look-up Secret は, Sec. 5.1.1.2 で述べられた通り, Approved な一方向関数で Hash されることとなる(SHALL). Entropy が 112 ビット未満の Look-up Secret は, 同様にSec. 5.1.1.2で述べられた通り, Salt 化され適切な Password Hash スキームを使用して Hash されることとなる(SHALL). Salt 値は長さが少なくとも 32 ビット となり, 保存された Hash 間の Salt 値の衝突を最小限に抑えるためにばらついて選択されることとなる(SHALL). Salt 値と結果の Hash の両方が, Look-up Secret ごとに保存されることとなる(SHALL).

Entropy が 64 ビット未満の Look-up Secret の場合, Verifier は, Sec. 5.2.2 で説明されている通り, Subscriber Account で試行できる Authentication の失敗回数を効果的に制限するレート制限メカニズムを実装することとなる(SHALL).

Verifier は, Look-up Secret を要求するときには, 盗聴や AitM Attack に対する耐性を提供するために, Approved な暗号による暗号化と Authenticated Protected Channel を使用することになる(SHALL).

Out-of-Band Devices

Out-of-band Authenticator は, 一意にアドレス指定が可能で, セカンダリチャネルと呼ばれる個別の通信チャネルを介して Verifier と安全に通信できる物理デバイスである. デバイスは Claimant によって所有および制御され, Authentication のためのプライマリチャネルとは別に, このセカンダリチャネルを介したプライベート通信をサポートする. Out-of-band Authenticator は something you have である.

Out-of-band Athentiction は, Verifier によって生成された短期的な Secret を使用する. Secret の目的は, プライマリとセカンダリチャネルでの Athentiction 操作を安全にバインドし, Claimant による Out-of-band デバイスの制御を確立することである.

Out-of-band Authenticator は以下のいずれかの方法で動作できる:

• Claimant は, Out-of-band デバイスによってセカンダリチャネルを介して受信した Secret を, プライマリチャネルを使用して Verifier に転送する. 例えば, Claimant はモバイルデバイスで Secret (通常は6桁のコード) を受信し, それを Authentication Session に入力してもよい. この方法は Figure 1 に示される.

Figure 1. Transfer of Secret to Primary Device

• Claimant は, セカンダリチャネルを介して Verifier に送信するために, プライマリチャネルを介して受信した Secret を Out-of-band デバイスに転送する. 例えば, Claimant は Authentication Session 上で Secret を表示し, モバイルデバイスのアプリにそれを入力するか, バーコードやQRコードなどのテクノロジーを使用して転送を行ってもよい. この方法は Figure 2 に示される.

Figure 2. Transfer of Secret to Out-of-band Device

注: 三番目の方法であった, プライマリとセカンダリチャネルから受信した Secret の比較とセカンダリチャネルでの承認による Out-of-band Authentication は, 説明された通りに実装されることは稀であったため, もはや受け入れられないと見なされる. これは Claimant が Secret を実際に比較せず単に承認する可能性を高くしていた. 例えば, Verifier からプッシュ通知を受け取り, 単に Claimant に Transaction の承認を求めるだけの Authenticator は (たとえ Authentication に関する追加情報を提供したとしても), このセクションの要件を満たさない.

Out-of-Band Authenticators

Out-of-band Authenticator は, Out-of-band Secret または Authentication 要求を取得するために, Verifier と別のチャネルを確立することとなる(SHALL). このチャネルは, デバイスが Claimant の許可なしにひとつのチャネルから別のチャネルに情報を漏らさないという条件であれば, (たとえ同じデバイス上で完了する場合でも) プライマリ通信チャネルに関して Out-of-band であると見なされる.

Out-of-band デバイスは, Verifier によって一意にアドレス指定が可能である必要がある(SHOULD). セカンダリチャネルを介した通信は, 公衆交換電話網 (Public Switched Telephone Network, PSTN) 経由で送信されない限り, 暗号化されることとなる(SHALL). Out-of-band Authentication のために PSTN を使用する場合の追加の Authenticator 要件については, Sec. 5.1.3.3 を参照のこと. Voice-Over-IP (VOIP) 電話番号など, 特定のデバイスの所有を証明しないチャネルまたはアドレスは, Out-of-band Authentication に使用されることはない(SHALL NOT).

電子メールは特定のデバイスの所有を証明するものではなく, 通常は Memorized Secret のみを使用してアクセスされるため, Out-of-band Authentication に使用されることはない(SHALL NOT).

Out-of-band Authenticator は, Verifier と通信するときに, 以下のいずれかの方法で自身を一意に Authentication することとなる(SHALL).

• Approved Cryptography を使用して, Verifier への Authenticated Protected Channel を確立する. 使用されるキーは, Authenticator アプリケーションが利用可能な, 適切に安全なストレージ (例: キーチェーンストレージ, TPM, TEE, セキュアエレメントなど) に格納することとなる(SHALL).

• デバイスを一意に識別する SIM カードまたは同等のものを使用して, 公衆携帯電話ネットワークに対して Authentication する. このメソッドは, Secret が Verifier から PSTN (SMS または音声) 経由で Out-of-band デバイスに送信される場合にのみ使用されることとなる(SHALL).

Verifier によって Out-of-band デバイスに Secret が送信される場合, デバイスは, 所有者によってロックされている間, Authentication Secret を表示しないほうがよい(SHOULD NOT)(つまり, 表示のために PIN, パスコード, または Biometric Characteristic の提示と Verification を要求する必要がある(SHOULD). ただし, Authenticator は, ロックされたデバイス上で Authentication Secret の受信を示す必要がある(SHOULD).

Out-of-band Authenticator が, (Claimant がプライマリ通信チャネルに転送する Secret を提示するのではなく) セカンダリ通信チャネルで承認を要求する場合, プライマリチャネルからの Secret の転送を受け入れることとなり(SHALL), 承認を Authentication Transaction に関連付けるために, それをセカンダリチャネルを介して Verifier に送信することとなる. Claimant は, 転送を手動で行うか, バーコードやQRコードなどのテクノロジーを使用して転送を行ってもよい(MAY).

Out-of-Band Verifiers

PSTN に固有の追加の Verification 要件については, Sec. 5.1.3.3 を参照のこと.

Out-of-band Authenticator がスマートフォン上などの安全なアプリケーションである場合, Verifier はそのデバイスにプッシュ通知を送信してもよい(MAY). Verifier は, Out-of-band Authenticator との Authenticated Protected Channel の確立を待ち, その識別キーを Verifiy する. Verifier は識別キー自体を保管することはない(SHALL NOT)が, Verification 方法 (例えば, Approved なハッシュ関数または識別キーの所有の証明) を使用して, Authenticator を一意に識別することとなる(SHALL). ひとたび Authenticate されると, Verifier は Authentication Secret を Authenticator に送信する.

Out-of-band Authenticator のタイプに応じて, 以下のいずれかが行われることとなる(SHALL):

• セカンダリからプライマリチャネルへの Secret の転送: Verifier は, Authentication の準備ができていることを示すために, Subscriber の Authenticator を含むデバイスにシグナルを送ってもよい(MAY). そして, Random Secret を Out-of-band Authenticator に送信することとなる(SHALL). 続いて, Verifier は, プライマリ通信チャネル上で Secret が返却されるのを待つこととなる(SHALL).

• プライマリからセカンダリチャネルへの Secret の転送: Verifier は, プライマリチャネルを介して Claimant に Random Authentication Secret を表示することとなる(SHALL). そして, Claimant の Out-of-band Authenticator からセカンダリチャネル上で Secret が返却されるのを待つこととなる(SHALL).

すべてのケースで, 10分以内に完了しない場合, Authentication は無効と見なされることとなる(SHALL). Sec. 5.2.8で述べられた通りに Replay Resistance を提供するため, Verifier は, 与えられた Authentication Secret の受け入れを有効期間中に一度のみとすることとなる(SHALL).

Verifier は, Approved Random Bit Generator [SP800-90Ar1] を使用して, 少なくとも 20 ビットの Entropy を持つ Random Authentication Secret を生成することとなる(SHALL). Authentication Secret の Entropy が 64 ビット未満の場合, Verifier は, Sec. 5.2.2 で説明されている通り, Subscriber Account で試行できる Authentication の失敗回数を効果的に制限するレート制限メカニズムを実装することとなる(SHALL).

CSP が, Out-of-band Authentication が Sec. 5.1.3.4 の要件を満たしていることを確認しない限り, Out-of-band Verifier はすべての Authentication 操作を Single-Factor と見なすこととなる(SHALL). この要件は CSP または信頼されたサードパーティによる Authenticator の発行, またはこれらの要件を満たすことが CSP によって認識されている Authentication アプリケーションの使用によって満たされてもよい(MAY).

Subscriber のデバイスにプッシュ通知を送信する Out-of-band Verifier は, 成功した最後の Authentication 以降に送信されるプッシュ通知のレートまたは総数に合理的な制限を実装する必要がある(SHOULD).

Authentication using the Public Switched Telephone Network

Out-of-band Verification のための PSTN の使用は, このセクションと Sec. 5.2.10 で説明されているように制限されている. PSTN を使用して Out-of-band Verification を行う場合, Verifier は, 使用されている事前登録済みの電話番号が特定の物理デバイスに関連付けられていることを Verification することとなる(SHALL). 事前登録された電話番号の変更は, 新しい Authenticator のバインドであると見なされ, Sec. 6.1.2 で説明されている場合にのみ発生することとなる(SHALL).

PSTN を使用して Out-of-band Authentication Secret を配信することは, 限定された電話のカバレッジを持つ地域 (特に携帯電話サービスがない地域) では, 一部の Subscriber が利用できない可能性がある. したがって, Verifier は, すべての Subscriber が代替の Authenticator タイプを利用できるようにすることとなり(SHALL), バインドする前に, PSTN を使用した Out-of-band Authenticator のこの制限を Subscriber に通知する必要がある(SHOULD).

Verifier は, PSTN を使用して Out-of-band Authentication Secret を配信する前に, デバイスの交換, SIM の変更, 番号の移植, またはその他の異常な動作などのリスク指標を考慮する必要がある(SHOULD).

注意: Sec. 5.2.10 の Authenticator の制限と整合性を取り, NIST は, 脅威をとりまく状況の進化と PSTN の技術的なオペレーションに基づいて, 時間の経過とともに, PSTN の制限付きステータスを調整してもよい.

Multi-Factor Out-of-Band Authenticators

Multi-Factor Out-of-band Authenticator は, Claimant が Authentication Transaction を完了できるようにする前(つまり, Authentication Secret にアクセスする前, Authentication Secret を入力する前, または使用されている Authentication フローに適した Transaction を確認する前)に Memorized Secret または Biometric Characteristic のいずれかの追加要素の提示と Verification を必要とすることを除いて, Single-Factor Out-of-band Authenticator (Sec. 5.1.3.1を参照) と同様の方法で動作する. Authenticator の使用ごとに, Activation Factor の提示を要求することとなる(SHALL).

Authenticator による Activation Secret の使用は, Sec. 5.2.11 の要件を満たすこととなる(SHALL). Biometric Activation Factor は, Authentication の連続失敗回数の制限を含め, Sec. 5.2.3 の要件を満たすこととなる(SHALL). Activation Factor の提出は, ホストデバイス (スマートフォンなど) のロック解除とは別の操作となる(SHALL)が, ホストデバイスのロック解除に使用されたものと同じ Activation Factor が Authentication 操作で使用されてもよい(MAY). Activation に使用される Memorized Secret または Biometric Sample -および信号処理によって生成された Probe などの Biometric Sample から得られたすべての Biometric データ- は, Authentication 操作の直後に Zeroize されることとなる(SHALL).

Single-Factor OTP Device

Single-Factor OTP デバイスは, ワンタイムパスワード(OTP)を生成する. このカテゴリには, ハードウェアデバイスと携帯電話などのデバイス上にインストールされた Software-Based OTP Generator が含まれる. これらのデバイスは, OTP 生成のシードとして使用される組み込みの Secret を持ち, 二番目の要素による Activation を必要としない. OTP はデバイス上に表示され Verifier に送信するために手動で入力される, これによりデバイスの所有と制御が証明される. OTP デバイスは, 例えば, 一度に6文字を表示してもよい. Single-Factor OTP デバイスは something you have である.

Single-Factor OTP デバイスは, Secret が Authenticator と Verifier によって暗号論的にかつ独立して生成され, Verifier によって比較されることを除いて, Look-up Secret Authenticator と同様である. Secret は, 時間ベースの Nonce に基づいて, または Authenticator と Verifier の数値カウンターから計算されてもよい.

Single-Factor OTP Authenticators

Single-Factor OTP Authenticator は, 2つの永続的な値を含む. 1つ目は, デバイスのライフタイムの間保持される Symmetric Key である. 2つ目は, Authenticator が使用されるたびに変更されるか, リアルタイムクロックに基づく Nonce である.

Secret Key とそのアルゴリズムは, 少なくとも [SP800-131A] の最新リビジョンで指定されている最小のセキュリティ強度を提供することとなる(SHALL)(発行日現在で 112 ビット). Nonce は, デバイスのライフタイム全体にわたってデバイスの各操作ごとに一意であることを確保するのに十分な長さとなる(SHALL). Subscriber が Software-Based OTP Authenticator に使用されるデバイスを変更する必要がある場合, 彼らは Sec. 6.1.2.1 で説明されている通りに新しいデバイス上の Authenticator を Subscriber Account へバインドする必要があり(SHOULD), 使用されなくなった Authenticator アプリケーションを無効にする必要がある.

Authenticator Output は, Key と Nonce を安全な方法で結合するために Approved なブロック暗号または Hash 関数を使用すること取得される. Authenticator Output は, わずか6桁の10進数 (約20ビットのEntropy) に切り詰められられてもよい(MAY).

Authenticator Output を生成するために使用される Nonce がリアルタイムクロックに基づいている場合, Nonce は少なくとも2分ごとに変更されることとなる(SHALL).

Single-Factor OTP Verifiers

Single-Factor OTP Verifier は, Authenticator に使用される OTP 生成プロセスを効果的に複製する. そのため, Authenticator に使用される Symmetric Key は Verifier にもまた存在し, アクセスを必要とするデバイス上のそれらのソフトウェアコンポーネントのみに Key へのアクセスを制限するアクセスコントロールを使用して, 無許可の開示から強力に保護されることとなる(SHALL).

Single-Factor OTP Authenticator が Subscriber Account に関連付けられている場合, Verifier または関連付けられた CSP は, Authenticator Output を複製するために必要な Secret を生成および交換, または取得するために, Approved Cryptography を使用することとなる(SHALL).

Verifier は, OTP を収集するときに, 盗聴や AitM Attack への耐性を提供するために, Approved Encryption と Authenticated Protected Channel を使用することとなる(SHALL). Sec. 5.2.8 で説明されている通りに Replay Resistance を提供するために, Verifier は, 有効な OTP の受け入れを一度のみとすることとなる(SHALL). OTP の重複使用が原因で Claimant の Authentication が拒否された場合, Verifier は, Attacker が事前に Authenticate できた場合に備えて Claimant に警告してもよい(MAY). また, Verifier は, OTP の重複使用の試行について, 既存セッションの中にいる Subscriber に警告してもよい(MAY).

時間ベースの OTP [TOTP] は, ネットワーク遅延と OTP のユーザー入力のための許容値, それに加え Authenticator が寿命の間に持つはずの両方向のクロックのずれを考慮した上で決定される, 定義されたライフタイムを持つこととなる(SHALL).

Authenticator Output の Entropy が 64 ビット未満の場合, Verifier は, Sec. 5.2.2 で説明されている通り, Subscriber Account で試行できる Authentication の失敗回数を効果的に制限するレート制限メカニズムを実装することとなる(SHALL).

Multi-Factor OTP Devices

Multi-Factor OTP デバイスは, Activation Factor の入力による Activation 後に Authentication に使用する OTP を生成する. これには, ハードウェアデバイスと携帯電話などのデバイス上にインストールされた Software-Based OTP Generator が含まれる. Authentication の二番目の要素は, 一体型入力パッドのようなもの, 一体型Biometric (例: 指紋) リーダー, または直接的なコンピュータインターフェース (例: USB ポート) によって実現されてもよい. OTP はデバイス上に表示され Verifier に送信するために手動で入力される. 例えば, OTP デバイスは一度に6文字を表示することができ, それによってデバイスの所有と制御を証明する. Multi-Factor OTP デバイスは something you have であり, かつ, something you know または something you are のいずれかによって Activation されることとなる(SHALL).

Multi-Factor OTP Authenticators

Multi-Factor OTP Authenticator は, Authenticator から OTP を取得するために Memorized Secret または Biometric Characteristic のいずれかの提示と Verification を必要とすることを除いて, Single-Factor OTP Authenticator (Sec. 5.1.4.1を参照) と同様の方法で動作する. Authenticator の使用ごとに, Activation Factor の入力を要求することとなる(SHALL).

Activation 情報に加えて, Multi-Factor OTP Authenticator は, 2つの永続的な値を含む. 1つ目は, デバイスのライフタイムの間保持される Symmetric Key である. 2つ目は, Authenticator が使用されるたびに変更されるか, リアルタイムクロックに基づく Nonce である.

Secret Key とそのアルゴリズムは, 少なくとも [SP800-131A] の最新リビジョンで指定されている最小のセキュリティ強度を提供することとなる(SHALL)(発行日現在で 112 ビット). Nonce は, デバイスのライフタイム全体にわたってデバイスの各操作ごとに一意であることを確保するのに十分な長さとなる(SHALL). Subscriber が Software-Based OTP Authenticator に使用されるデバイスを変更する必要がある場合, 彼らは Sec. 6.1.2.1 で説明されている通りに新しいデバイス上の Authenticator を Subscriber Account へバインドする必要があり(SHOULD), 使用されなくなった Authenticator アプリケーションを無効にする必要がある.

Authenticator Output は, Key と Nonce を安全な方法で結合するために Approved なブロック暗号または Hash 関数を使用すること取得される. Authenticator Output は, わずか6桁の10進数 (約20ビットのEntropy) に切り詰められられてもよい(MAY).

Authenticator Output を生成するために使用される Nonce がリアルタイムクロックに基づいている場合, Nonce は少なくとも2分ごとに変更されることとなる(SHALL).

Authenticator による Activation Secret の使用は, Sec. 5.2.11 の要件を満たすこととなる(SHALL). Biometric Activation Factor は, Authentication の連続失敗回数の制限を含め, Sec. 5.2.3 の要件を満たすこととなる(SHALL). Activation Factor の提出は, ホストデバイス (スマートフォンなど) のロック解除とは別の操作となる(SHALL)が, ホストデバイスのロック解除に使用されたものと同じ Activation Factor が Authentication 操作で使用されてもよい(MAY). Unencrypted Key と Activation Secret, または Biometric Sample -および信号処理によって生成された Probe などの Biometric Sample から得られたすべての Biometric データ- は, Authentication 操作の直後に Zeroize されることとなる(SHALL).

Multi-Factor OTP Verifiers

Multi-Factor OTP Verifier は, 二番目の要素を提供を受ける要件なしに Authenticator に使用される OTP 生成プロセスを効果的に複製する. そして, Authenticator に使用される Symmetric Key はアクセスを必要とするデバイス上のそれらのソフトウェアコンポーネントのみに Key へのアクセスを制限するアクセスコントロールを使用して, 無許可の開示から強力に保護されることとなる(SHALL).

Multi-Factor OTP Authenticator が Subscriber Account に関連付けられている場合, Verifier または関連付けられた CSP は, Authenticator Output を複製するために必要な Secret を生成および交換, または取得するために, Approved Cryptography を使用することとなる(SHALL). Verifier または CSP は, Authenticator の発行によって, Authenticator が Multi-Factor デバイスであることを確立することとなる(SHALL). それ以外の場合, Verifier は, Sec. 5.1.4 に従って, Authenticator を Single-Factor として扱うこととなる(SHALL).

Verifier は, OTP を収集するときに, 盗聴や AitM Attack への耐性を提供するために, Approved Encryption と Authenticated Protected Channel を使用することとなる(SHALL). Sec. 5.2.8 で説明されている通りに Replay Resistance を提供するために, Verifier は, 有効な OTP の受け入れを一度のみとすることとなる(SHALL). OTP の重複使用が原因で Claimant の Authentication が拒否された場合, Verifier は, Attacker が事前に Authenticate できた場合に備えて Claimant に警告してもよい(MAY). また, Verifier は, OTP の重複使用の試行について, 既存セッションの中にいる Subscriber に警告してもよい(MAY).

時間ベースの OTP [TOTP] は, ネットワーク遅延と OTP のユーザー入力のための許容値, それに加え Authenticator が寿命の間に持つはずの両方向のクロックのずれを考慮した上で決定される, 定義されたライフタイムを持つこととなる(SHALL).

Authenticator Output または Activation Secret の Entropy が 64 ビット未満の場合, Verifier は, Sec. 5.2.2 で説明されている通り, Subscriber Account で試行できる Authentication の失敗回数を効果的に制限するレート制限メカニズムを実装することとなる(SHALL).

Single-Factor Cryptographic Software

Single-Factor Cryptographic Software Authenticator は, ディスク上またはその他の “ソフト” メディアに格納された Cryptographic Key である. Authentication は, Key の所有と制御を証明することによって成し遂げられる. Authenticator Output は, 特定の暗号プロトコルに大きく依存するが, 通常は何らかのタイプの署名付きメッセージである. Single-Factor Cryptographic Software Authenticator は something you have である.

Single-Factor Cryptographic Software Authenticators

Single-Factor Cryptographic Software Authenticator は, 1つかそれ以上の一意の Secret Key を Authenticator にカプセル化する. Key は, Authenticator アプリケーションが利用可能な, 適切に安全なストレージ (例: キーチェーンストレージ, TPM, または可能であれば TEE) に格納することとなる(SHALL). Key は, アクセスを必要とするデバイス上のそれらのソフトウェアコンポーネントのみに Key へのアクセスを制限するアクセスコントロールを使用して, 無許可の開示から強力に保護されることとなる(SHALL).

Cryptographic Hardware Authenticator の要件を満たさない, 外付けの Cryptographic Authenticator (例: Private Key のエクスポートを許可するメカニズムを持つもの) も, Cryptographic Software Authenticator と見なされる. それらは Sec. 5.2.12 の Connected Authenticator の要件を満たすこととなる(SHALL).

Single-Factor Cryptographic Software Verifiers

Single-Factor Cryptographic Software Verifier の要件は, Sec. 5.1.7.2 で述べられる Single-Factor Cryptographic Device Verifier と同様である.

Single-Factor Cryptographic Devices

Single-Factor Cryptographic デバイスは, 保護された Cryptographic Key を使用して暗号的操作を実行し, ユーザーエンドポイントへの直接接続を介して Authenticator Output を提供するハードウェアデバイスである. デバイスは, 組み込みの Symmetric または Asymmetric Cryptographic Key を使用し, 二番目の要素による Activation を必要としない. Authentication は, Authentication Protocol を介してデバイスの所有を証明することによって成し遂げられる. Authenticator Output は, ユーザーエンドポイントへの直接接続によって提供され, また特定の暗号デバイスとプロトコルに大きく依存するが, 通常は何らかのタイプの署名付きメッセージである. Single-Factor Cryptographic デバイスは something you have である.

Single-Factor Cryptographic Device Authenticators

Single-Factor Cryptographic Device Authenticator は, 1つかそれ以上の一意の Secret Key を, エクスポート機能を持つことはない(SHALL NOT)(つまり,デバイスから削除できない) Authenticator にカプセル化するために耐タンパー性ハードウェアを使用する. この Authenticator は, Sec. 5.2.12 に指定された通り, Authenticator とエンドポイントの間の直接的なインターフェース(例: USB ポートや保護されたワイヤレス接続)を通じて提示された Challenge Nonce に署名するために Secret Key を使用することで動作する. あるいは, Authenticator は, ユーザーエンドポイントそれ自体に統合された適切に安全なプロセッサであってもよい.

Secret Key とそのアルゴリズムは, 少なくとも [SP800-131A] の最新リビジョンで指定されている最小のセキュリティの長さを提供することとなる(SHALL)(発行日現在で 112 ビット). Challenge Nonce は, 少なくとも 64 ビットの長さとなる(SHALL). Approved Cryptography を使用することとなる(SHALL).

Cryptographic Device Authenticator は, 暗号デバイスによる組み込みの Authentication Secret によって, より大きな保護がもたらされるため, Cryptographic Software Authenticator とは異なる. 暗号デバイスと見なされるために, Authenticator は, ハードウェアの別の部分または組み込みプロセッサ, または実行環境 (例: セキュア エレメント, Trusted Execution Environment (TEE), Trusted Platform Module (TPM))のいずれかとなる(SHALL). これらのハードウェア Authenticator または組み込みプロセッサは, ラップトップやモバイルデバイス上の CPU などのホストプロセッサからは分離される. Cryptographic Device Authenticator は, ホストプロセッサへの Authentication Secret のエクスポートを禁止するように設計されることとなり(SHALL), Secret の抽出が許されるようにホストプロセッサによって再プログラムを行えるようになることはない(SHALL NOT). Authenticator は, Authenticator が使用されている AAL に適合する [FIPS140] の要件の対象となる.

Single-Factor Cryptographic Device Authenticator は, 動作するために物理的な入力 (例: ボタンを押す) を要求する必要がある(SHOULD). これは, デバイスが接続されているエンドポイントが侵害された場合に発生する可能性がある, デバイスの意図しない動作に対する防御を提供する.

Single-Factor Cryptographic Device Verifiers

Single-Factor Cryptographic Device Verifier は, Challenge Nonce を生成し, それを対象の Authenticator に送信し, デバイスの所有を検証するために Authenticator Output を使用する. Authenticator Output は, 特定の暗号デバイスとプロトコルに大きく依存するが, 通常は何らかのタイプの署名付きメッセージである.

Verifier は, それぞれの Authenticator に対応する Symmetric または Asymmetric Cryptographic Key のいずれかを持つ. 両タイプの鍵は変更から保護されることとなる(SHALL)が, Symmetric Key はさらに, アクセスを必要とするデバイス上のそれらのソフトウェアコンポーネントのみに Key へのアクセスを制限するアクセスコントロールを使用して, 無許可の開示から強力に保護されることとなる(SHALL).

Challenge Nonce は, 長さが少なくとも 64 ビットとなり(SHALL), Authenticator のライフタイムにわたって, または統計的に一意となる(SHALL)(つまり, Approved Random Bit Generator [SP800-90Ar1] を使用して生成される). Verification 操作は, Approved Cryptography を使用することとなる(SHALL).

Multi-Factor Cryptographic Software

Multi-Factor Cryptographic Software Authenticator は, Authentication の二番目の要素での Activation を必要とする, ディスク上またはその他の “ソフト” メディアに格納された Cryptographic Key である. Authentication は, Key の所有と制御を証明することによって成し遂げられる. Authenticator Output は, 特定の暗号プロトコルに大きく依存するが, 通常は何らかのタイプの署名付きメッセージである. Multi-Factor Cryptographic Software Authenticator は something you have であり, something you know または something you are のいずれかによって Activation されることとなる(SHALL).

Multi-Factor Cryptographic Software Authenticators

Multi-Factor Cryptographic Software Authenticator は, 1つかそれ以上の一意の Secret Key を Authenticator にカプセル化し, Memorized Secret または Biometric Characteristic のいずれかの Activation Factor の提示と Verification によってのみアクセス可能となる. Key は, Authenticator アプリケーションが利用可能な, 適切に安全なストレージ (例: キーチェーンストレージ, TPM, TEE) に格納する必要がある(SHOULD). Key は, アクセスを必要とするデバイス上のそれらのソフトウェアコンポーネントのみに Key へのアクセスを制限するアクセスコントロールを使用して, 無許可の開示から強力に保護されることとなる(SHALL).

Cryptographic Hardware Authenticator の要件を満たさない, 外付けの Cryptographic Authenticator (例: Private Key のエクスポートを許可するメカニズムを持つもの) も, Cryptographic Software Authenticator と見なされる. それらは Sec. 5.2.12 の Connected Authenticator の要件を満たすこととなる(SHALL).

Authenticator を使用する各 Authentication 操作は, Activation Factor の入力を必要とすることとなる(SHALL).

Authenticator による Activation Secret の使用は, Sec. 5.2.11 の要件を満たすこととなる(SHALL). Biometric Activation Factor は, Authentication の連続失敗回数の制限を含め, Sec. 5.2.3 の要件を満たすこととなる(SHALL). Activation Factor の提出は, ホストデバイス (スマートフォンなど) のロック解除とは別の操作となる(SHALL)が, ホストデバイスのロック解除に使用されたものと同じ Activation Factor が Authentication 操作で使用されてもよい(MAY). Activation Secret または Biometric Sample -および信号処理によって生成された Probe などの Biometric Sample から得られたすべての Biometric データ- は, Authentication 操作の直後に Zeroize されることとなる(SHALL).

Multi-Factor Cryptographic Software Verifiers

Multi-Factor Cryptographic Software Verifier の要件は, Sec. 5.1.7.2 で述べられる Single-Factor Cryptographic Device Verifier と同様である. Multi-Factor Cryptographic Software Authenticator Output の Verification は, Activation Factor の使用を証明する.

Multi-Factor Cryptographic Devices

Multi-Factor Cryptographic デバイスは, 1つかそれ以上の保護された Cryptographic Key を使用して暗号的操作を実行し, 二番目の Authentication Factor による Activation を必要とするハードウェアデバイスである. Authentication は, デバイスの所有および Key の制御を証明することによって成し遂げられる. Authenticator Output は, ユーザーエンドポイントへの直接接続によって提供され, また特定の暗号デバイスとプロトコルに大きく依存するが, 通常は何らかのタイプの署名付きメッセージである. Multi-Factor Cryptographic デバイスは, something you have であり, かつ, something you know または something you are のいずれかによって Activation されることとなる(SHALL).

Multi-Factor Cryptographic Device Authenticators

Multi-Factor Cryptographic Device Authenticator は, 1つかそれ以上の一意の Secret Key を, エクスポート機能を持つことはない(SHALL NOT)(つまり,デバイスから削除できない) Authenticator にカプセル化するために耐タンパー性ハードウェアを使用する. Secret Key は, Sec. 5.2.11 で述べられている通り, Biometric Characteristic または Activation Secret のいずれかの Activation Factor の提示と Verification によってのみアクセス可能となる(SHALL). この Authenticator は, Sec. 5.2.12 に指定された通り, Authenticator とエンドポイントの間の直接的なインターフェース(例: USB ポートや保護されたワイヤレス接続)を通じて提示された Challenge Nonce に署名するために Activation Factor によってアンロックされた Secret Key を使用することで動作する. あるいは, Authenticator は, ユーザーエンドポイントそれ自体に統合された適切に安全なプロセッサであってもよい(例: ハードウェア TPM).

Secret Key とそのアルゴリズムは, 少なくとも [SP800-131A] の最新リビジョンで指定されている最小のセキュリティの長さを提供することとなる(SHALL)(発行日現在で 112 ビット). Challenge Nonce は, 少なくとも 64 ビットの長さとなる(SHALL). Approved Cryptography を使用することとなる(SHALL).

Cryptographic Device Authenticator は, 暗号デバイスによる組み込みの Authentication Secret によって, より大きな保護がもたらされるため, Cryptographic Software Authenticator とは異なる. 暗号デバイスと見なされるために, Authenticator は, ハードウェアの別の部分または組み込みプロセッサ, または実行環境 (例: セキュア エレメント, Trusted Execution Environment (TEE), Trusted Platform Module (TPM))のいずれかとなる(SHALL). Cryptographic Device Authenticator は, ホストプロセッサへの Authentication Secret のエクスポートを禁止するように設計されることとなり(SHALL), Secret の抽出が許されるようにホストプロセッサによって再プログラムを行えるようになることはない(SHALL NOT). Authenticator は, Authenticator が使用されている AAL に適合する [FIPS140] の要件の対象となる.

Authenticator を使用する各 Authentication 操作は, Activation Factor の入力が必要である(SHOULD). Activation Factor の入力は, デバイス上の直接入力か, ハードウェア接続(例: USB, スマートカード)を介してのいずれかで行われてもよい(MAY).

Authenticator による Activation Secret の使用は, Sec. 5.2.11 の要件を満たすこととなる(SHALL). Biometric Activation Factor は, Authentication の連続失敗回数の制限を含め, Sec. 5.2.3 の要件を満たすこととなる(SHALL). Activation Factor の提出は, ホストデバイス (スマートフォンなど) のロック解除とは別の操作となる(SHALL)が, ホストデバイスのロック解除に使用されたものと同じ Activation Factor が Authentication 操作で使用されてもよい(MAY). Activation Secret または Biometric Sample -および信号処理によって生成された Probe などの Biometric Sample から得られたすべての Biometric データ- は, Authentication 操作の直後に Zeroize されることとなる(SHALL).

Multi-Factor Cryptographic Device Verifiers

Multi-Factor Cryptographic Device Verifier の要件は, Sec. 5.1.7.2 で述べられる Single-Factor Cryptographic Device Verifier と同様である. Multi-Factor Cryptographic Device からの Authenticator Output の Verification は, Activation Factor の使用を証明する.

General Authenticator Requirements

Physical Authenticators

CSP は, Authenticator を盗難や紛失から適切に保護する方法について, Subscriber にインストラクションを提供することとなる(SHALL). CSP は, Subscriber からの Authenticator の紛失または盗難が疑われる通知に対して, 即時に Authenticator を無効にするメカニズムを提供することとなる(SHALL).

Rate Limiting (Throttling)

Sec. 5.1 の Authenticator Type の説明で必要とされる場合, Verifier は, Online Guessing Attack から保護するための制御を実装することとなる(SHALL). その Authenticator の説明で特に指定されていない限り, Verifier は, 単一の Subscriber Account での Authentication の連続失敗の試行を 100回 以下に制限することとなる(SHALL).

レート制限の結果として Attacker が正当な Claimant をロックアウトする可能性を減らすために, 以下を含む追加のテクニックが使用されてもよい(MAY)：

• Authentication を試みる前に, Claimant にボットの検出と緩和のための課題を完了するように要求する.

• 失敗した試行の後に, Subscriber Account がその連続失敗試行回数の最大許容値に近づくにつれて増加する時間(例: 30秒から1時間まで)の間, Claimant に待つことを要求する.

• Subscriber が以前, Authentication に成功した IP アドレスの Allowlist からの Authentication 要求のみを受け入れる.

• 他のリスクベースまたは適応できる Authentication テクニックを活用して, 一般的な基準の範囲内または範囲外となるユーザーの行動を識別する. これらには, 例えば, IP アドレス, 位置情報, リクエストのタイミングのパターン, またはブラウザのメタデータの使用が含まれることがある.

Subscriber が Authentication に成功すると, Verifierは, 同じ IP アドレスからのそのユーザーのそれ以前の失敗試行をすべて考慮しないようにする必要がある(SHOULD).

Use of Biometrics

Authentication における Biometrics (something you are) の使用には, 身体的特徴 (例: 指紋, 虹彩, 顔の特徴) と行動的特徴 (例: タイピングのリズム) の両方の測定が含まれる. どちらのクラスも Biometric Modalitiy と見なされるが, Sec. 5.2.9 で説明されているように, Modalitiy が異なると Authentication Intent の確立度合いが異なる場合がある.

さまざまな理由から, このドキュメントでは, Authentication のための Biometrics の限定的な使用のみをサポートしている. 理由は以下を含む:

• Biometric False Match Rate (FMR) は, Subscriber の Authentication が Subscriber 自身 によってなされたものであるという信頼を提供しない. さらに, FMR はスプーフィング Attack を考慮して計算されない.
• Biometric の比較は確率的だが, 他の Authentication Factor は決定的である.
• Biometric Template Protection スキームは, 他の Authentication Factor (例: PKIの証明書および Password) と同等の Biometric Credential を失効する方法を提供する. しかし, そのようなソリューションの有効性は限られており, これらの方法をテストするための標準は開発中である.
• Biometric Characteristics は Secret の構成要素とはならない. それらはオンラインでたびたび入手でき, また人々の顔写真は相手の認識の有無を問わず写真を撮ることで入手できる. 隠れた指紋は人々が触れた物から取得することができ, 虹彩パターンは高解像度の画像で捉えられる. Presentation Attack Detection (PAD) テクノロジーはこれらのタイプの Attack のリスクを軽減できるが, PAD が CSP と Subscriber のニーズに従って動作していることを確実にするには, センサーまたは Biometric Processing への追加の信頼が必要とされる.

このため, Authentication のための Biometrics の限定的な使用は, 次の要件とガイドラインでサポートされる:

Biometrics は, 物理的な Authenticator (something you have) を使用した Multi-Factor Authentication の一部としてのみ使用されることとなる(SHALL).

Biometric システムは, 1/10000 またはそれよりも望ましい False-Match Rate (FMR) [ISO/IEC2382-37] で動作することとなる(SHALL). この FMR は, [ISO/IEC30107-1] で定義されている Conformant Attack (つまり, Zero-Effort Impostor Attempt) の条件のもとで達成されることとなる(SHALL).

Biometric システムは, Presentation Attack Detection (PAD) を実装する必要がある(SHOULD). 展開される Biometric システムのテストでは, 関連する Attack タイプ (つまり, Species) ごとに, Presentation Attack に対して少なくとも 90% の耐性があることを示す必要がある(SHOULD). 耐性は, 阻止された Presentation Attack の数を試行したPresentation Attack の数で割った値として定義される. Presentation Attack 耐性のテストは, [ISO/IEC30107-3] の第12条に従うこととなる(SHALL). PAD の決定は, Claimant のデバイス上でローカルに行われるか, 中央の Verifier によって行われてもよい(MAY).

Biometric システムは, Authentication の試行の連続失敗を5回まで, または, 上記の要件を満たす PAD が実装されている場合においては試行の連続失敗を 10 回まで許容することとなる(SHALL). ひとたびその制限に達すると, Biometric Authenticator は, 全体的な制限として Authentication の試行の連続失敗が 50 回 (PAD が実装されている場合は 100 回) を超えないとともに, その後の各試行の前に少なくとも 30 秒の遅延を課すこととなる(SHALL). ひとたび全体的な制限に達すると, Biometric システムは, Biometric User Authentication を無効にすることとなり(SHALL), 利用可能な代替方法がすでにある場合は, 他の要素 (例: 別の Biometric Modality, または, まだ要求された要素でない場合は Activation Secret) を提案することとなる.

Verifier は, センサーとエンドポイントのパフォーマンス, Integrity (完全性), および Authenticity (真正性) を判断することとなる(SHALL). この決定を行うための許容される方法は, 以下を含むがこれらに限定されない:

• センサーまたはエンドポイントの Authentication
• Approvedな 公認機関による Certification
• Sec. 5.2.4 で説明されている通りの, 署名されたメタデータ (例: Attestation) の実行時の問い合わせ.

Biometric の比較は, Claimant のデバイス上でローカルでも, 中央の Verifier でも実行可能である. しかし, 大規模な Attack の可能性は中央の Verifier の方が大きいため, 比較はローカルで実行される必要がある(SHOULD).

比較が中央で実行される場合:

• Authentication Factor としての Biometric の使用は, Approved Cryptography を使用して識別される1つかそれ以上の特定のデバイスに限定されることとなる(SHALL). Biometric はメインの Authentication Key をまだアンロックしていないため, デバイスの識別には別の Key が使用されることとなる(SHALL).
• [ISO/IEC24745] で Biometric Template Protection と呼ばれるBiometric Revocation が実装されることとなる(SHALL).
• Authenticated Protected Channel は, センサー (またはセンサー交換耐性があるセンサーを含むエンドポイント) と Verifier の間に確立されることとなり(SHALL), また, センサーまたはエンドポイントは, Claimant から Biometric Sample を取得する前に Authenticate されることとなる(SHALL).
• Biometrics のすべての送信は, Authenticated Protected Channel を介することとなる(SHALL).

Authentication プロセスの中で収集された Biometric Sampleは, 比較アルゴリズムのトレーニングに使用するか, または -ユーザーの同意のもとで- 他の研究目的に使用されてもよい(MAY). Biometric Sample, および信号処理によって生成された Probe などの Biometric Sample から得られたすべての Biometric データは, すべてのトレーニングまたは研究データが得られた直後に Zeroize されることとなる(SHALL).

Biometric Authentication 技術は, さまざまな人口統計的タイプ (人種的背景, 性別, 民族など) の Subscriber に対して同様のパフォーマンスを提供することとなる(SHALL).

Attestation

Attestation は, 接続された Authenticator, または Authentication 操作に関わるエンドポイントに関して Verifier に伝達される情報である. Attestation によって伝達される情報には以下を含んでもよい(MAY) が, これらに限定されない:

• Authenticator とエンドポイントの起源 (例: メーカーまたはサプライヤーの認定), 健全性, および Integrity (完全性)
• Authenticator のセキュリティ機能
• Biometric センサーのセキュリティとパフォーマンスの特性
• センサーモダリティ

この Attestation が署名されている場合は, 少なくとも [SP800-131A] の最新リビジョンで指定されている最小のセキュリティ強度(発行日現在で 112 ビット)を提供する Digital Signature を使用して署名されることとなる(SHALL).

Attestation 情報は, Verifier のリスクベース Authentication の決断の一部として使用されてもよい(MAY).

Phishing (Verifier Impersonation) Resistance

以前 SP 800-63B で “Verifier Impersonation” と呼ばれていた Phishing Attack は, 悪意のある偽物の Verifier と RP が, 不注意な Claimant をだまして Authenticator を Impostor に提示させようとする試みである. いくつかの SP 800-63 の以前のバージョンでは, Phishing Attack に耐性のあるプロトコルは, “Strongly MitM Resistant” とも呼ばれていた.

Phishing という用語は, さまざまな同様の Attack を説明するために広く使用されている. このドキュメントの目的上, Phishing 耐性とは, Subscriber の警戒に頼ることなく, Authentication Secret と有効な Authenticator Output を Impostor が偽装する Relying Party へ開示することを検出し防止する Authentication Protocol の機能である. Subscriber が Impostor が偽装する Relying Party に向けられた手段は関係しない. 例えば, Subscriber が検索エンジンの最適化によってそこに案内されたのか, 電子メールで促されたのかに関係なく, Phishing Attack であると見なされる.

Approved な暗号アルゴリズムは, 必要とされる場所で Phishing 耐性を確立するために使用されることとなる(SHALL). この目的のための Key は, 少なくとも [SP800-131A] の最新リビジョンで指定されている最小のセキュリティ強度(発行日現在で 112 ビット)を提供することとなる(SHALL).

Out-of-band や OTP Authenticator のような, Authenticator Output の手動入力を伴う Authenticator は, Phishing 耐性があると見なされることはない(SHALL NOT), なぜならば, 手動入力は Authenticator Output を特定の Authenticated session に Bind しないためである. AitM Attack では, Impostor が偽装する Verifier が OTP Authenticator の Output を Verifier に Replay し, Authentication に成功する可能性がある.

個々の Authenticator には Phishing 耐性があるとしても, 特定の Subscriber Account の Phishing 耐性はすべての Authentication の方法に Phishing 耐性がある場合にのみ達成される.

Phishing 耐性の2つの方法が知られている: Channel Binding と Verifier Name Binding である. Channel Binding は Relying Party 証明書の誤発行や不正使用に対して脆弱ではないため, Verifier Name Binding よりも安全であるとみなされるが, どちらの方法も Phishing 耐性の要件を満たす.

Channel Binding

Channel Binding を伴う Authentication Protocol は, Authenticated Protected Channel を Verifier と確立することとなる(SHALL). 次に, Authenticated Protected Channel を確立する際にネゴシエートされた Channel Identifier を, Authenticator Output に強力かつ不可逆的に Bind することとなる(SHALL)(例: Public Key が Verifier に知られている Claimant によって制御される Private Key を使用して, 2つの値を一緒に署名することによって). Verifier は, Phishing 耐性を証明するために, 使用される署名またはその他の情報を検証することとなる(SHALL). これにより, Impostor が偽装する Verifier が実際の Verifier を表す証明書を取得したとしても, 異なる Authenticated Protected Channel でその Authentication の中継に成功することを防ぐ.

Channel Binding を使用する Phishing 耐性のある Authentication Protocol の例は, Client-authenticated TLS である. なぜならば, ネゴシエートされた特定の TLS 接続に一意の, Protocol からの以前のメッセージと共に Authenticator Output にクライアントが署名するためである.

Verifier Name Binding

Authenticator Name Binding を伴う Authentication Protocol は, Authenticated Protected Channel をVerifier と確立することとなる(SHALL). 次に, Protocol の一部として Authenticate された Verifier Identifier に対して暗号的に Bind された Authenticator Output を生成することとなる(SHALL). Domain Name System (DNS) Identifier の場合, Verifier Identifier は, Verifier の Authenticate されたホスト名, またはホスト名に関連付けられた Public Suffix [PSL] の少なくとも 1 レベル遡った親ドメインのいずれかとなる(SHALL). Binding は, 関連付けられた Authenticator Secret を選択するか, Verifier Identifier を使用して Authenticator Secret を導出するか, Verifier Identifier と供に Authenticator Output に暗号的に署名するか, または同様の暗号的に安全な手段によって確立されてもよい(MAY).

Verifier-CSP Communications

Verifier と CSP が別々のエンティティである状況では ([SP800-63] の点線で示されているように, Verifier と CSP 間の通信は, Approved Cryptography を使用して, (Client-authenticated TLS 接続のような) 相互に Authenticate された安全なチャネルを介して行われることとなる(SHALL).

Verifier Compromise Resistance

いくつかのタイプの Authenticator を使用するには, Verifier が Authenticator Secret のコピーを保管する必要がある. 例えば, OTP Authenticator (Sec. 5.1.4 で説明) では, Claimant によって送信された値と比較するための Authenticator Output を, Verifier が独立して生成することが求められる. Verifier が侵害され, 保管された Secret が盗まれる可能性のため, Verifier が Authentication に使用できる Secret を永続的に保管する必要のない Authentication Protocol はより強力であると見なされ, Verifier Compromise Resistant(Verifierが侵害耐性を持つ状態) である旨がここで説明されている. このような Verifier もすべての Attack に耐性があるわけではないことに注意が必要である. Verifier は, 特定の Authenticator Output を常に受け入れるようにのっとられるなど, 別の方法で侵害されるかもしれない.

Verifier Compromise Resistant は様々な方法で達成できる, 例えば:

• Verifier は, Authenticator 保持する Private Key に対応する Public key を保管することを要求する Cryptographic Authenticator を使用する.

• 予想される Authenticator Output を Hash 形式で保管する. このメソッドは, 例えば一部の Look-Up Secret Authenticator (Sec. 5.1.2 で説明) で使用できる.

Verifier Compromise Resistant であると見なされるために, Verifier によって保管される Public key は, Approved な暗号アルゴリズムの使用によるものとなり(SHALL), 少なくとも [SP800-131A] の最新リビジョンで指定されている最小のセキュリティ強度(発行日現在で 112 ビット)を提供することとなる(SHALL).

その他の Verifier Compromise Resistant Secret は, Approved な Hash アルゴリズムを使用することとなり(SHALL), 基となる Secret は, 少なくとも [SP800-131A] の最新リビジョンで指定されている最小のセキュリティ強度(発行日現在で 112 ビット)を持つすることとなる(SHALL). 低い複雑度を持つ Secret (例: Memorized Secret) は, 辞書検索または網羅的探索によって Hash プロセスを破る可能性があるため, Hash された場合でも Verifier Compromise Resistant と見なされることはない(SHALL NOT).

Replay Resistance

Authentication Process は, 過去の Authentication のメッセージを記録して Replay することによって Authentication を成功させることが現実的でない場合, Replay Attack に耐性がある. Protected Channel に入る前に Output が盗まれる可能性があるため, Replay Resistance は Authenticated Protected Channel Protocol の Replay-Resistant 特性には含まれていない. Nonce または Challenge を使用して Transaction の “真新しさ” を証明するプロトコルは, Replay Attack に耐性がある. Verifier は, 古いプロトコルメッセージが適切な Nonce または適時性のあるデータを含んでいないため, 古いプロトコルメッセージが Replay されることを簡単に検出できるからである.

Replay 耐性のある Authenticator の例は, OTP デバイス, Cryptographic Authenticator, および Look-Up Secret である.

反対に, Memorized Secret は Replay 耐性があるとは見なされない. Authenticator Output —つまり, Secret そのもの— が Authentication ごとに提供されるためである.

Authentication Intent

Subject がそれぞれの Authentication または Reauthentication の要求に明示的に応答する必要がある場合, Authentication Process は Intent (意図)を実証する. Authentication Intent のゴールは, エンドポイント上のマルウェアなどによって, Subject の知らないうちに Authenticator (例: Multi-Factor Cryptographic Device) が使用されるのをより困難にすることである. Authentication Intent は, Authenticator 自体によって確立されることとなる(SHALL)が, Multi-Factor Cryptographic Device は, Authenticator の Activation Factor の再入力によって Intent を確立してもよい(MAY).

Authentication Intent は, いろいろな方法で確立されてもよい(MAY). Subject の介入を必要とする Authentication Process は, Intent を確立する (例: OTP デバイスからの Authenticator Output を入力するClaimant). それぞれの Authentication または Reauthentication 操作ごとにユーザーアクションを必要とする暗号デバイスも, Intent を確立する (例: ボタンを押す, 再挿入する).

Modality に応じて, Biometric Characteristic の提示は Authentication Intent を確立する場合と確立しない場合がある. Behavioral Biometrics も, Claimant 側での特定のアクションを必ずしも必要としないため, 同様に Authentication Intent を確立する場合と確立しない場合がある,

Restricted Authenticators

脅威の進化により, Authenticator の Attack 耐性の性能は通常は低下する. 反対に, 一部の Authenticator のパフォーマンスは, 例えば基となる標準の変更によって特定の Attack 耐性の能力が向上した場合に改善することがある.

Authenticator のパフォーマンスのこれらの変化に責任を持つために, NIST は, Authenticator Type, または Authenticator Type の特定のクラスやインスタンス化に追加の制約を課す:

Restricted Authenticator の使用は, 実装組織がその Authenticator に関連するリスクを評価, 理解, および受け入れ, リスクが時間の経過とともに増加する可能性があることを認識することを求める. システムと関連データについて許容可能なリスクのレベルを決定し, それを超えるリスクを軽減する方法を定義することは組織の責任である. いずれかの関係者へのリスクが許容できないと組織が判断した場合はいつでも, それ以降その Authenticator が使用されることはない(SHALL NOT).

さらに, Authentication エラーのリスクは通常, 実装組織, Authentication の決定に依存する組織, および Subscriber を含む複数の関係者によって負担される. 組織が Restricted Authenticator を受け入れると, Subscriber は追加のリスクにさらされる可能性があり, また Subscriber が持つ理解と制御能力が限られている可能性があるため, CSP は以下を行うこととなる(SHALL):

1. 必要とされる AAL で使用できる少なくとも1つの Restricted でない 代替の Authenticator を Subscriber に提供する.
2. Restricted Authenticator のセキュリティリスクと Restricted でない代替について, Subscriber に意味のある通知を提供する.
3. Risk Assessment で Subscriber への追加のリスクに取り組む.\
4. Restricted Authenticator が未来のある時点で受け入れられなくなる可能性について移行計画を作成し, この移行計画をその digital identity acceptance statement に含む.

Activation Secrets

Multi-Factor Authenticator の Activation Factor として使用される Memorized Secret は, Activation Secret と呼ばれる. Activation Secret は, Authentication に使用される Stored Secret Key を復号するために使用されるか, Authentication Key へのアクセスを提供するためにローカルに保持されている Stored Verifier と比較される. これらのいずれの場合でも, Activation Secret は Authenticator とそれに関連付けられたユーザーエンドポイント内にとどまることとなる(SHALL).

Activation Secret を利用する Authenticator は, Secret の長さに少なくとも 6 文字を要求することとなる(SHALL). Activation Secret は, すべて数字 (つまり PIN) であってもよい(MAY). (数字だけではなく)英数字の値が許可されている場合は, すべての Printing ASCII [RFC20] 文字と空白文字が受け入れられる必要がある(SHOULD). Unicode [ISO/ISC 10646] 文字もまた, 英数字の Secret に受け入れられる必要がある(SHOULD). Authenticator は, (特定の値またはアルゴリズムによって指定された) 少なくとも 10 個のよく使用される Activation 値の Blocklist を含むこととなり(SHALL), それらの Activation Secret としての使用を防ぐこととなる(SHALL).

Authenticator または Verifier は, Authenticator を使用した Activation の連続失敗の試行を効果的に 10回 に制限する再試行制限メカニズムを実装することとなる(SHALL). 正しくない Activation Secret の入力によって Authenticator が中央の Verifier に送信される無効な Output を生成する場合, Verifier によってレート制限が実装されてもよい(MAY). すべての他のケースでは, レート制限は Authenticator に実装されることとなる(SHALL). ひとたび 10回 の試行の制限に達すると, Authenticator を無効化されることとなり(SHALL), Authentication には別の Authenticator が要求されることとなる(SHALL).

Authenticator が Activation Secret を (Key の復号に使用するのではなく) ローカルで Verifiy する場合, Verification は, ハードウェアベースの Authenticator 内, または正しい Activation Secret の提示時にのみ Authentication Secret を解放するセキュアエレメント内 (例: TEE, TPM) で実行されることとなる(SHALL). 他の状況 (つまり, Software-Based Multi-Factor Authenticators) では, Authenticator は, 保管された Authentication Secret の復号のために Memorized Secret を Key として使用することとなる(SHALL). Approved Cryptography が使用されることとなる(SHALL).

Connected Authenticators

Cryptographic Authenticator は, Authenticator と Authenticate されるエンドポイントとの間の直接接続を必要とする. この接続は, 有線 (例: USB またはスマートカードとの直接接続) またはワイヤレス (例: NFC, Bluetooth) でもよい(MAY). ほとんどの場合, 有線接続は盗聴や Adversary-in-the-Middle Attack から安全であると推定できるが, ワイヤレス技術を介して接続されている Authenticator には追加の予防措置が必要とされる.

有線の Authenticator 接続は, エンドポイントに組み込まれている Authenticator (例: TPMの中) と, USB などの外部インターフェースを介して接続される Authenticator の両方を含む. Claimant は, 彼らが侵害されていないことのさらなる保証のため, 外部接続に信頼されたハードウェア (ケーブルなど) を使用することについてアドバイスを受ける必要がある(SHOULD).

ワイヤレスの Authenticator 接続は, 盗聴, インジェクション, リレー Attack などの脅威に対して潜在的に脆弱である. このような Attack の可能性は, 使用されているワイヤレス技術の有効範囲に依存する.

1 メートル以上の有効範囲を持つワイヤレス技術 (例: Bluetooth LE) は, Authenticator とエンドポイントの間で Authenticate された暗号化接続を使用することとなる(SHALL). ペアリングプロセスは, Authenticator とエンドポイント間の暗号化通信用の Key を確立するために使用される. ペアリングプロセスの代わりに, デバイス間の一時的な有線接続が Key を確立するために使用されてもよい(MAY). ペアリングプロセスは, ペアリングコードを使用することで Authenticate されることとなる(SHALL). ペアリングコードは, Authenticator またはエンドポイントのいずれかに関連付けられることとなり(SHALL), 少なくとも 20 ビットまたは 10 進数 6 桁の Entropy を持つこととなる(SHALL). ペアリングコードは, 関連付けられたデバイスに印刷してもよく(MAY), 手動入力, または光学的に伝達される QR コードか同様の提示方法を使用して, デバイス間で伝達することとなる(SHALL). この例は, [SP800-73] で指定された仮想コンタクトインターフェースで使用されるペアリングコードである. Authentication Transaction 全体は, ペアリングプロセスによって確立された Key を使用して暗号化されることとなる(SHALL).

1 メートル未満の有効範囲を持つワイヤレス技術 (例: NFC) が使用されている場合, エンドポイントから Authenticator に送信される Activation Secret がもしあれば, デバイス間のペアリングプロセスまたは一時的な有線接続を介して確立された Key を使用して暗号化されることとなる(SHALL). 上記の要件を満たすペアリング コードを使用した Authenticate された接続を使用する必要がある(SHOULD). Authenticator が Authenticate されたペアリングを要求するように構成されている場合, ペアリングコードが使用されることとなる(SHALL).

注: Authentication Transaction 全体ではなく Activation Secret のみの暗号化は, Relying Party の Identity などのセンシティブ情報を晒してしまう可能性があるが, これには Attacker が Subscriber の非常に近くにいる必要がある. “スキミング” や Eavesdropping Attack から情報を保護するために, Authenticate されたペアリングを必要としない, 個人を特定できる情報を含む Authenticator には, 特別な注意を払う必要がある.

ペアリングプロセスの結果として確立された Key は, 一時的 (限られた数のトランザクションまたは時間に対して有効) または永続的のどちらであってもよい(MAY). 永続 Key を削除するエンドポイントのメカニズムが提供されることとなる(SHALL).

暗号操作が必要なところでは, Approved Cryptography を使用することとなる(SHALL). Authenticator とエンドポイント間の Authentication データのすべての通信は, これらのデバイス間で直接行われるか, Authenticator とエンドポイント間の Authenticated Protected Channel を介して行われることとなる(SHALL).

Authenticator and Verifier Requirements

This section is normative.

This section provides the detailed requirements specific to each type of authenticator. With the exception of reauthentication requirements specified in Sec. 4 and the requirement for phishing resistance at AAL3 described in Sec. 5.2.5, the technical requirements for each of the authenticator types are the same regardless of the AAL at which the authenticator is used.

Requirements by Authenticator Type

Memorized Secrets

A Memorized Secret authenticator — commonly referred to as a password or, if numeric, a PIN — is a secret value intended to be chosen and memorized by the user. Memorized secrets need to be of sufficient complexity and secrecy that it would be impractical for an attacker to guess or otherwise discover the correct secret value. A memorized secret is something you know.

The requirements in this section apply to centrally verified memorized secrets that are used as an independent authentication factor, sent over an authenticated protected channel to the verifier of a CSP. Memorized secrets that are used locally by a multi-factor authenticator are referred to as activation secrets and discussed in Sec. 5.2.11.

Memorized Secret Authenticators

Memorized secrets SHALL be at least 8 characters in length. Memorized secrets SHALL be either chosen by the subscriber or assigned randomly by the CSP.

If the CSP disallows a chosen memorized secret because it is on a blocklist of commonly used, expected, or compromised values (see Sec. 5.1.1.2), the subscriber SHALL be required to choose a different memorized secret. No other complexity requirements for memorized secrets SHALL be imposed. A rationale for this is presented in Appendix A Strength of Memorized Secrets.

Memorized Secret Verifiers

Verifiers SHALL require memorized secrets to be at least 8 characters in length. Verifiers SHOULD permit memorized secrets to be at least 64 characters in length. All printing ASCII [RFC20] characters as well as the space character SHOULD be acceptable in memorized secrets. Unicode [ISO/ISC 10646] characters SHOULD be accepted as well. Verifiers MAY make allowances for likely mistyping, such as removing leading and trailing whitespace characters prior to verification or allowing verification of memorized secrets with differing case for the leading character, provided memorized secrets remain at least 8 characters in length after such processing.

Verifiers SHALL verify the entire submitted memorized secret (i.e., not truncate the secret). For purposes of the above length requirements, each Unicode code point SHALL be counted as a single character.

If Unicode characters are accepted in memorized secrets, the verifier SHOULD apply the normalization process for stabilized strings using either the NFKC or NFKD normalization defined in Sec. 12.1 of Unicode Normalization Forms [UAX15]. This process is applied before hashing the byte string representing the memorized secret. Subscribers choosing memorized secrets containing Unicode characters SHOULD be advised that some characters may be represented differently by some endpoints, which can affect their ability to authenticate successfully.

Memorized secret verifiers SHALL NOT permit the subscriber to store a hint that is accessible to an unauthenticated claimant. Verifiers SHALL NOT prompt subscribers to use specific types of information (e.g., “What was the name of your first pet?”, a technique known as knowledge-based authentication (KBA) or security questions) when choosing memorized secrets.

When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a blocklist that contains values known to be commonly used, expected, or compromised. For example, the list MAY include, but is not limited to:

• Passwords obtained from previous breach corpuses.
• Dictionary words.
• Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’).
• Context-specific words, such as the name of the service, the username, and derivatives thereof.

If the chosen secret is found in the blocklist, the CSP or verifier SHALL advise the subscriber that they need to select a different secret, SHALL provide the reason for rejection, and SHALL require the subscriber to choose a different value. Since the blocklist is used to defend against brute-force attacks and unsuccessful attempts are rate limited as described below, the blocklist SHOULD be of a size sufficient to prevent subscribers from choosing memorized secrets that attackers are likely to guess before reaching the attempt limit. Excessively large blocklists SHOULD NOT be used because they frustrate subscribers’ attempts to establish an acceptable memorized secret and do not provide significantly improved security.

Verifiers SHALL offer guidance to the subscriber to assist the user in choosing a strong memorized secret. This is particularly important following the rejection of a memorized secret on the above list as it discourages trivial modification of listed (and likely very weak) memorized secrets [Blocklists].

Verifiers SHALL implement a rate-limiting mechanism that effectively limits the number of failed authentication attempts that can be made on the subscriber account as described in Sec. 5.2.2.

Verifiers SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHALL NOT require users to periodically change memorized secrets. However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.

Verifiers SHALL allow the use of password managers. To facilitate their use, verifiers SHOULD permit claimants to use “paste” functionality when entering a memorized secret. Password manangers may increase the likelihood that users will choose stronger memorized secrets.

In order to assist the claimant in successfully entering a memorized secret, the verifier SHOULD offer an option to display the secret — rather than a series of dots or asterisks — while it is entered and until it is submitted to the verifier. This allows the claimant to confirm their entry if they are in a location where their screen is unlikely to be observed. The verifier MAY also permit the claimant’s device to display individual entered characters for a short time after each character is typed to verify correct entry. This is common on mobile devices.

The verifier SHALL use approved encryption and an authenticated protected channel when requesting memorized secrets in order to provide resistance to eavesdropping and adversary-in-the-middle attacks.

Verifiers SHALL store memorized secrets in a form that is resistant to offline attacks. Memorized secrets SHALL be salted and hashed using a suitable password hashing scheme. Password hashing schemes take a password, a salt, and a cost factor as inputs and generate a password hash. Their purpose is to make each password guess more expensive for an attacker who has obtained a hashed password file and thereby make the cost of a guessing attack high or prohibitive. A function that is both memory-hard and compute-hard SHOULD be used because it increases the cost of an attack. While NIST has not published guidelines on specific password hashing schemes, examples of such functions include Argon2 [Argon2] and scrypt [Scrypt]. Examples of approved one-way functions include Keyed Hash Message Authentication Code (HMAC) [FIPS198-1], any approved hash function in [SP800-107], Secure Hash Algorithm 3 (SHA-3) [FIPS202], CMAC [SP800-38B], Keccak Message Authentication Code (KMAC), Customizable SHAKE (cSHAKE), and ParallelHash [SP800-185]. The chosen output length of the password hashing scheme SHOULD be the same as the length of the underlying one-way function output.

The salt SHALL be at least 32 bits in length and be chosen arbitrarily so as to minimize salt value collisions among stored hashes. Both the salt value and the resulting hash SHALL be stored for each memorized secret authenticator.

For the Password-based Key Derivation Function 2 (PBKDF2) [SP800-132], the cost factor is an iteration count: the more times the PBKDF2 function is iterated, the longer it takes to compute the password hash. Therefore, the iteration count SHOULD be as large as verification server performance will allow, typically at least 10,000 iterations.

In addition, verifiers SHOULD perform an additional iteration of a keyed hashing or encryption operation using a secret key known only to the verifier. This key value, if used, SHALL be generated by an approved random bit generator [SP800-90Ar1] and provide at least the minimum security strength specified in the latest revision of NIST SP 800-131A, Transitioning the Use of Cryptographic Algorithms and Key Lengths [SP800-131A] (112 bits as of the date of this publication). The secret key value SHALL be stored separately from the hashed memorized secrets (e.g., in a specialized device like a hardware security module). With this additional iteration, brute-force attacks on the hashed memorized secrets are impractical as long as the secret key value remains secret.

Look-Up Secrets

A look-up secret authenticator is a physical or electronic record that stores a set of secrets shared between the claimant and the CSP. The claimant uses the authenticator to look up the appropriate secrets needed to respond to a prompt from the verifier. For example, the verifier could ask a claimant to provide a specific subset of the numeric or character strings printed on a card in table format. A common application of look-up secrets is the use of one-time “recovery keys” stored by the subscriber for use in the event another authenticator is lost or malfunctions. A look-up secret is something you have.

Look-Up Secret Authenticators

CSPs creating look-up secret authenticators SHALL use an approved random bit generator [SP800-90Ar1] to generate the list of secrets and SHALL deliver the authenticator securely to the subscriber. Look-up secrets SHALL have at least 20 bits of entropy.

Look-up secrets MAY be distributed by the CSP in person, by postal mail to the subscriber’s address of record, or by online distribution. If distributed online, look-up secrets SHALL be distributed over a secure channel in accordance with the post-enrollment binding requirements in Sec. 6.1.2.

If the authenticator uses look-up secrets sequentially from a list, the subscriber MAY dispose of used secrets, but only after a successful authentication.

Look-Up Secret Verifiers

Verifiers of look-up secrets SHALL prompt the claimant for the next secret from their authenticator or for a specific (e.g., numbered) secret. A given secret from an authenticator SHALL be used successfully only once. If the look-up secret is derived from a grid card, each cell of the grid SHALL be used only once.

Verifiers SHALL store look-up secrets in a form that is resistant to offline attacks. Look-up secrets having at least 112 bits of entropy SHALL be hashed with an approved one-way function as described in Sec. 5.1.1.2. Look-up secrets with fewer than 112 bits of entropy SHALL be salted and hashed using a suitable password hashing scheme, also described in Sec. 5.1.1.2. The salt value SHALL be at least 32 bits in length and arbitrarily chosen so as to minimize salt value collisions among stored hashes. Both the salt value and the resulting hash SHALL be stored for each look-up secret.

For look-up secrets that have less than 64 bits of entropy, the verifier SHALL implement a rate-limiting mechanism that effectively limits the number of failed authentication attempts that can be made on the subscriber account as described in Sec. 5.2.2.

The verifier SHALL use approved encryption and an authenticated protected channel when requesting look-up secrets in order to provide resistance to eavesdropping and AitM attacks.

Out-of-Band Devices

An out-of-band authenticator is a physical device that is uniquely addressable and can communicate securely with the verifier over a distinct communications channel, referred to as the secondary channel. The device is possessed and controlled by the claimant and supports private communication over this secondary channel, separate from the primary channel for authentication. An out-of-band authenticator is something you have.

Out-of-band authentiction uses a short-term secret generated by the verifier. The secret’s purpose is to securely bind the authentication operation on the primary and secondary channel and establishes the claimant’s control of the out-of-band device.

The out-of-band authenticator can operate in one of the following ways:

• The claimant transfers a secret received by the out-of-band device via the secondary channel to the verifier using the primary channel. For example, the claimant may receive the secret (typically a 6-digit code) on their mobile device and type it into their authentication session. This method is shown in Figure 1.

Figure 1. Transfer of Secret to Primary Device

• The claimant transfers a secret received via the primary channel to the out-of-band device for transmission to the verifier via the secondary channel. For example, the claimant may view the secret on their authentication session and either type it into an app on their mobile device or use a technology such as a barcode or QR code to effect the transfer. This method is shown in Figure 2.

Figure 2. Transfer of Secret to Out-of-band Device

Note: A third method of out-of-band authentication involving the comparison of secrets received from the primary and secondary channels and approving on the secondary channel is no longer considered acceptable because it was rarely implemented as described. It raised the likelihood that the claimant would just approve without actually comparing the secrets. For example, an authenticator that receives a push notification from the verifier and simply asks the claimant to approve the transaction (even if providing some additional information about the authentication) does not meet the requirements of this section.

Out-of-Band Authenticators

The out-of-band authenticator SHALL establish a separate channel with the verifier in order to retrieve the out-of-band secret or authentication request. This channel is considered to be out-of-band with respect to the primary communication channel (even if it terminates on the same device) provided the device does not leak information from one channel to the other without the authorization of the claimant.

The out-of-band device SHOULD be uniquely addressable by the verifier. Communication over the secondary channel SHALL be encrypted unless sent via the public switched telephone network (PSTN). For additional authenticator requirements specific to use of the PSTN for out-of-band authentication, see Sec. 5.1.3.3. Channels or addresses that do not prove possession of a specific device, such as voice-over-IP (VOIP) telephone numbers, SHALL NOT be used for out-of-band authentication.

Email SHALL NOT be used for out-of-band authentication because it also does not prove possession of a specific device and is typically accessed using only a memorized secret.

The out-of-band authenticator SHALL uniquely authenticate itself in one of the following ways when communicating with the verifier:

• Establish an authenticated protected channel to the verifier using approved cryptography. The key used SHALL be stored in suitably secure storage available to the authenticator application (e.g., keychain storage, TPM, TEE, secure element).

• Authenticate to a public mobile telephone network using a SIM card or equivalent that uniquely identifies the device. This method SHALL only be used if a secret is being sent from the verifier to the out-of-band device via the PSTN (SMS or voice).

If a secret is sent by the verifier to the out-of-band device, the device SHOULD NOT display the authentication secret while it is locked by the owner (i.e., SHOULD require the presentation and verification of a PIN, passcode, or biometric characteristic to view). However, authenticators SHOULD indicate the receipt of an authentication secret on a locked device.

If the out-of-band authenticator requests approval over the secondary communication channel — rather than by the presenting a secret that the claimant transfers to the primary communication channel — it SHALL accept transfer of the secret from the primary channel and send it to the verifier over the secondary channel to associate the approval with the authentication transaction. The claimant MAY perform the transfer manually or use a technology such as a barcode or QR code to effect the transfer.

Out-of-Band Verifiers

For additional verification requirements specific to the PSTN, see Sec. 5.1.3.3.

When the out-of-band authenticator is a secure application, such as on a smart phone, the verifier MAY send a push notification to that device. The verifier waits for the establishment of an authenticated protected channel with the out-of-band authenticator and verifies its identifying key. The verifier SHALL NOT store the identifying key itself, but SHALL use a verification method (e.g., an approved hash function or proof of possession of the identifying key) to uniquely identify the authenticator. Once authenticated, the verifier transmits the authentication secret to the authenticator.

Depending on the type of out-of-band authenticator, one of the following SHALL take place:

• Transfer of secret from the secondary to the primary channel: The verifier MAY signal the device containing the subscriber’s authenticator to indicate readiness to authenticate. It SHALL then transmit a random secret to the out-of-band authenticator. The verifier SHALL then wait for the secret to be returned on the primary communication channel.

• Transfer of secret from the primary to the secondary channel: The verifier SHALL display a random authentication secret to the claimant via the primary channel. It SHALL then wait for the secret to be returned on the secondary channel from the claimant’s out-of-band authenticator.

In all cases, the authentication SHALL be considered invalid if not completed within 10 minutes. In order to provide replay resistance as described in Sec. 5.2.8, verifiers SHALL accept a given authentication secret only once during the validity period.

The verifier SHALL generate random authentication secrets with at least 20 bits of entropy using an approved random bit generator [SP800-90Ar1]. If the authentication secret has less than 64 bits of entropy, the verifier SHALL implement a rate-limiting mechanism that effectively limits the number of failed authentication attempts that can be made on the subscriber account as described in Sec. 5.2.2.

Out-of-band verifiers SHALL consider all authentication operations to be single-factor unless the CSP has confirmed that the out-of-band authentication meets the requirements of Sec. 5.1.3.4. This requirement MAY be satisfied by issuance of the authenticator by the CSP or a trusted third party or by use of an authentication application known by the CSP to meet these requirements.

Out-of-band verifiers that send a push notification to a subscriber device SHOULD implement a reasonable limit on the rate or total number of push notifications that will be sent since the last successful authentication.

Authentication using the Public Switched Telephone Network

Use of the PSTN for out-of-band verification is restricted as described in this section and in Sec. 5.2.10. If out-of-band verification is to be made using the PSTN, the verifier SHALL verify that the pre-registered telephone number being used is associated with a specific physical device. Changing the pre-registered telephone number is considered to be the binding of a new authenticator and SHALL only occur as described in Sec. 6.1.2.

Use of the PSTN to deliver out-of-band authentication secrets is potentially not available to some subscribers in areas with limited telephone coverage (particularly in areas without mobile phone service). Accordingly, verifiers SHALL ensure that alternative authenticator types are available to all subscribers and SHOULD remind subscribers of this limitation of PSTN out-of-band authenticators prior to binding.

Verifiers SHOULD consider risk indicators such as device swap, SIM change, number porting, or other abnormal behavior before using the PSTN to deliver an out-of-band authentication secret.

NOTE: Consistent with the restriction of authenticators in Sec. 5.2.10, NIST may adjust the restricted status of the PSTN over time based on the evolution of the threat landscape and the technical operation of the PSTN.

Multi-Factor Out-of-Band Authenticators

Multi-factor out-of-band authenticators operate in a similar manner to single-factor out-of-band authenticators (see Sec. 5.1.3.1) except that they require the presentation and verification of an additional factor, either a memorized secret or a biometric characteristic, prior to allowing the claimant to complete the authentication transaction (i.e., prior to accessing the authentication secret, entering the authentication secret, or confirming the transaction as appropriate for the authentication flow being used). Each use of the authenticator SHALL require the presentation of the activation factor.

The use of an activation secret by the authenticator SHALL meet the requirements of Sec. 5.2.11. A biometric activation factor SHALL meet the requirements of Sec. 5.2.3, including limits on the number of consecutive authentication failures. Submission of the activation factor SHALL be a separate operation from unlocking of the host device (e.g., smartphone), although the same activation factor used to unlock the host device MAY be used in the authentication operation. The memorized secret or biometric sample used for activation — and any biometric data derived from the biometric sample such as a probe produced through signal processing — SHALL be zeroized immediately after the authentication operation.

Single-Factor OTP Device

A single-factor OTP device generates one-time passwords (OTPs). This category includes hardware devices and software-based OTP generators installed on devices such as mobile phones. These devices have an embedded secret that is used as the seed for generation of OTPs and does not require activation through a second factor. The OTP is displayed on the device and manually input for transmission to the verifier, thereby proving possession and control of the device. An OTP device may, for example, display 6 characters at a time. A single-factor OTP device is something you have.

Single-factor OTP devices are similar to look-up secret authenticators with the exception that the secrets are cryptographically and independently generated by the authenticator and verifier and compared by the verifier. The secret is computed based on a nonce that may be time-based or from a counter on the authenticator and verifier.

Single-Factor OTP Authenticators

Single-factor OTP authenticators contain two persistent values. The first is a symmetric key that persists for the device’s lifetime. The second is a nonce that is either changed each time the authenticator is used or is based on a real-time clock.

The secret key and its algorithm SHALL provide at least the minimum security strength specified in the latest revision of [SP800-131A] (112 bits as of the date of this publication). The nonce SHALL be of sufficient length to ensure that it is unique for each operation of the device over its lifetime. If a subscriber needs to change the device used for a software-based OTP authenticator, they SHOULD bind the authenticator application on the new device to their subscriber account as described in Sec. 6.1.2.1 and invalidate the authenticator application that will no longer be used.

The authenticator output is obtained by using an approved block cipher or hash function to combine the key and nonce in a secure manner. The authenticator output MAY be truncated to as few as 6 decimal digits (approximately 20 bits of entropy).

If the nonce used to generate the authenticator output is based on a real-time clock, the nonce SHALL be changed at least once every 2 minutes.

Single-Factor OTP Verifiers

Single-factor OTP verifiers effectively duplicate the process of generating the OTP used by the authenticator. As such, the symmetric keys used by authenticators are also present in the verifier, and SHALL be strongly protected against unauthorized disclosure by the use of access controls that limit access to the keys to only those software components on the device requiring access.

When a single-factor OTP authenticator is being associated with a subscriber account, the verifier or associated CSP SHALL use approved cryptography to either generate and exchange or to obtain the secrets required to duplicate the authenticator output.

The verifier SHALL use approved encryption and an authenticated protected channel when collecting the OTP in order to provide resistance to eavesdropping and AitM attacks. In order to provide replay resistance as described in Sec. 5.2.8, verifiers SHALL accept a given OTP only once while it is valid. In the event a claimant’s authentication is denied due to duplicate use of an OTP, verifiers MAY warn the claimant in case an attacker has been able to authenticate in advance. Verifiers MAY also warn a subscriber in an existing session of the attempted duplicate use of an OTP.

Time-based OTPs [TOTP] SHALL have a defined lifetime that is determined by the expected clock drift — in either direction — of the authenticator over its lifetime, plus allowance for network delay and user entry of the OTP.

If the authenticator output has less than 64 bits of entropy, the verifier SHALL implement a rate-limiting mechanism that effectively limits the number of failed authentication attempts that can be made on the subscriber account as described in Sec. 5.2.2.

Multi-Factor OTP Devices

A multi-factor OTP device generates OTPs for use in authentication after activation through input of an activation factor. This includes hardware devices and software-based OTP generators installed on devices such as mobile phones. The second factor of authentication may be achieved through some kind of integral entry pad, an integral biometric (e.g., fingerprint) reader, or a direct computer interface (e.g., USB port). The OTP is displayed on the device and manually input for transmission to the verifier. For example, an OTP device may display 6 characters at a time, thereby proving possession and control of the device. The multi-factor OTP device is something you have, and it SHALL be activated by either something you know or something you are.

Multi-Factor OTP Authenticators

Multi-factor OTP authenticators operate in a similar manner to single-factor OTP authenticators (see Sec. 5.1.4.1), except that they require the presentation and verification of either a memorized secret or a biometric characteristic to obtain the OTP from the authenticator. Each use of the authenticator SHALL require the input of the activation factor.

In addition to activation information, multi-factor OTP authenticators contain two persistent values. The first is a symmetric key that persists for the device’s lifetime. The second is a nonce that is either changed each time the authenticator is used or is based on a real-time clock.

The secret key and its algorithm SHALL provide at least the minimum security strength specified in the latest revision of [SP800-131A] (112 bits as of the date of this publication). The nonce SHALL be of sufficient length to ensure that it is unique for each operation of the device over its lifetime. If a subscriber needs to change the device used for a software-based OTP authenticator, they SHOULD bind the authenticator application on the new device to their subscriber account as described in Sec. 6.1.2.1 and invalidate the authenticator application that will no longer be used.

The authenticator output is obtained by using an approved block cipher or hash function to combine the key and nonce in a secure manner. The authenticator output MAY be truncated to as few as 6 decimal digits (approximately 20 bits of entropy).

If the nonce used to generate the authenticator output is based on a real-time clock, the nonce SHALL be changed at least once every 2 minutes.

The use of an activation secret by the authenticator SHALL meet the requirements of Sec. 5.2.11. A biometric activation factor SHALL meet the requirements of Sec. 5.2.3, including limits on the number of consecutive authentication failures. Submission of the activation factor SHALL be a separate operation from unlocking of the host device (e.g., smartphone), although the same activation factor used to unlock the host device MAY be used in the authentication operation. The unencrypted key and activation secret or biometric sample — and any biometric data derived from the biometric sample such as a probe produced through signal processing — SHALL be zeroized immediately after an OTP has been generated.

Multi-Factor OTP Verifiers

Multi-factor OTP verifiers effectively duplicate the process of generating the OTP used by the authenticator, but without the requirement that a second factor be provided. As such, the symmetric keys used by authenticators SHALL be strongly protected against unauthorized disclosure by the use of access controls that limit access to the keys to only those software components on the device requiring access.

When a multi-factor OTP authenticator is being associated with a subscriber account, the verifier or associated CSP SHALL use approved cryptography to either generate and exchange or to obtain the secrets required to duplicate the authenticator output. The verifier or CSP SHALL also establish, by issuance of the authentictor, that the authenticator is a multi-factor device. Otherwise, the verifier SHALL treat the authenticator as single-factor, in accordance with Sec. 5.1.4.

The verifier SHALL use approved encryption and an authenticated protected channel when collecting the OTP in order to provide resistance to eavesdropping and AitM attacks. In order to provide replay resistance as described in Sec. 5.2.8, verifiers SHALL accept a given OTP only once while it is valid. In the event a claimant’s authentication is denied due to duplicate use of an OTP, verifiers MAY warn the claimant in case an attacker has been able to authenticate in advance. Verifiers MAY also warn a subscriber in an existing session of the attempted duplicate use of an OTP.

Time-based OTPs [TOTP] SHALL have a defined lifetime that is determined by the expected clock drift — in either direction — of the authenticator over its lifetime, plus allowance for network delay and user entry of the OTP.

If the authenticator output or activation secret has less than 64 bits of entropy, the verifier SHALL implement a rate-limiting mechanism that effectively limits the number of failed authentication attempts that can be made on the subscriber account as described in Sec. 5.2.2.

Single-Factor Cryptographic Software

A single-factor cryptographic software authenticator is a cryptographic key stored on disk or some other “soft” media. Authentication is accomplished by proving possession and control of the key. The authenticator output is highly dependent on the specific cryptographic protocol, but it is generally some type of signed message. The single-factor cryptographic software authenticator is something you have.

Single-Factor Cryptographic Software Authenticators

Single-factor cryptographic software authenticators encapsulate one or more secret keys unique to the authenticator. The key SHALL be stored in suitably secure storage available to the authenticator application (e.g., keychain storage, TPM, or TEE if available). The key SHALL be strongly protected against unauthorized disclosure by the use of access controls that limit access to the key to only those software components on the device requiring access.

External cryptographic authenticators that do not meet the requirements of cryptographic hardware authenticators (e.g., that have a mechanism to allow private keys to be exported) are also considered to be cryptographic software authenticators. They SHALL meet the requirements for connected authenticators in Sec. 5.2.12.

Single-Factor Cryptographic Software Verifiers

The requirements for a single-factor cryptographic software verifier are identical to those for a single-factor cryptographic device verifier, described in Sec. 5.1.7.2.

Single-Factor Cryptographic Devices

A single-factor cryptographic device is a hardware device that performs cryptographic operations using protected cryptographic keys and provides the authenticator output via direct connection to the user endpoint. The device uses embedded symmetric or asymmetric cryptographic keys, and does not require activation through a second factor of authentication. Authentication is accomplished by proving possession of the device via the authentication protocol. The authenticator output is provided by direct connection to the user endpoint and is highly dependent on the specific cryptographic device and protocol, but it is typically some type of signed message. A single-factor cryptographic device is something you have.

Single-Factor Cryptographic Device Authenticators

Single-factor cryptographic device authenticators use tamper-resistant hardware to encapsulate one or more secret keys unique to the authenticator that SHALL NOT be exportable (i.e., cannot be removed from the device). The authenticator operates using a secret key to sign a challenge nonce presented through a direct interface between the authenticator and endpoint (e.g., a USB port or secured wireless connection) as specified in Sec. 5.2.12. Alternatively, the authenticator could be a suitably secure processor integrated with the user endpoint itself.

The secret key and its algorithm SHALL provide at least the minimum security length specified in the latest revision of [SP800-131A] (112 bits as of the date of this publication). The challenge nonce SHALL be at least 64 bits in length. Approved cryptography SHALL be used.

Cryptographic device authenticators differ from cryptographic software authenticators because of the greater protection afforded to the embedded authentication secrets by cryptographic devices. In order to be considered a cryptographic device, an authenticator SHALL either be a separate piece of hardware or an embedded processor or execution environment, e.g., secure element, trusted execution environment (TEE), trusted platform module (TPM). These hardware authenticators or embedded processors are separate from a host processor such as the CPU on a laptop or mobile device. A cryptographic device authenticator SHALL be designed so as to prohibit the export of the authentication secret to the host processor and SHALL NOT be capable of being reprogrammed by the host processor so as to allow the secret to be extracted. The authenticator is subject to applicable [FIPS140] requirements of the AAL at which the authenticator is being used.

Single-factor cryptographic device authenticators SHOULD require a physical input (e.g., the pressing of a button) in order to operate. This provides defense against unintended operation of the device, which might occur if the endpoint to which it is connected is compromised.

Single-Factor Cryptographic Device Verifiers

Single-factor cryptographic device verifiers generate a challenge nonce, send it to the corresponding authenticator, and use the authenticator output to verify possession of the device. The authenticator output is highly dependent on the specific cryptographic device and protocol, but it is generally some type of signed message.

The verifier has either symmetric or asymmetric cryptographic keys corresponding to each authenticator. While both types of keys SHALL be protected against modification, symmetric keys SHALL additionally be protected against unauthorized disclosure by the use of access controls that limit access to the key to only those software components on the device requiring access.

The challenge nonce SHALL be at least 64 bits in length, and SHALL either be unique over the authenticator’s lifetime or statistically unique (i.e., generated using an approved random bit generator [SP800-90Ar1]). The verification operation SHALL use approved cryptography.

Multi-Factor Cryptographic Software

A multi-factor cryptographic software authenticator is a cryptographic key stored on disk or some other “soft” media that requires activation through a second factor of authentication. Authentication is accomplished by proving possession and control of the key. The authenticator output is highly dependent on the specific cryptographic protocol, but it is generally some type of signed message. The multi-factor cryptographic software authenticator is something you have, and it SHALL be activated by either something you know or something you are.

Multi-Factor Cryptographic Software Authenticators

Multi-factor cryptographic software authenticators encapsulate one or more secret keys unique to the authenticator and accessible only through the presentation and verification of an activation factor, either a memorized secret or a biometric characteristic. The key SHOULD be stored in suitably secure storage available to the authenticator application (e.g., keychain storage, TPM, TEE). The key SHALL be strongly protected against unauthorized disclosure by the use of access controls that limit access to the key to only those software components on the device requiring access.

External cryptographic authenticators that do not meet the requirements of cryptographic hardware authenticators (e.g., that have a mechanism to allow private keys to be exported) are also considered to be cryptographic software authenticators. They SHALL meet the requirementss for connected authenticators in Sec. 5.2.12.

Each authentication operation using the authenticator SHALL require the input of the activation factor.

The use of an activation secret by the authenticator SHALL meet the requirements of Sec. 5.2.11. A biometric activation factor SHALL meet the requirements of Sec. 5.2.3, including limits on the number of consecutive authentication failures. Submission of the activation factor SHALL be a separate operation from unlocking of the host device (e.g., smartphone), although the same activation factor used to unlock the host device MAY be used in the authentication operation. The activation secret or biometric sample — and any biometric data derived from the biometric sample such as a probe produced through signal processing — SHALL be zeroized immediately after an authentication transaction has taken place.

Multi-Factor Cryptographic Software Verifiers

The requirements for a multi-factor cryptographic software verifier are identical to those for a single-factor cryptographic device verifier, described in Sec. 5.1.7.2. Verification of the output from a multi-factor cryptographic software authenticator proves use of the activation factor.

Multi-Factor Cryptographic Devices

A multi-factor cryptographic device is a hardware device that performs cryptographic operations using one or more protected cryptographic keys and requires activation through a second authentication factor. Authentication is accomplished by proving possession of the device and control of the key. The authenticator output is provided by direct connection to the user endpoint and is highly dependent on the specific cryptographic device and protocol, but it is typically some type of signed message. The multi-factor cryptographic device is something you have, and it SHALL be activated by either something you know or something you are.

Multi-Factor Cryptographic Device Authenticators

Multi-factor cryptographic device authenticators use tamper-resistant hardware to encapsulate one or more secret keys unique to the authenticator that SHALL NOT be exportable (i.e., cannot be removed from the device). The secret key SHALL be accessible only through the presentation and verification of an activation factor, either a biometric characteristic or an activation secret as described in Sec. 5.2.11. The authenticator operates by using a secret key that was unlocked by the activation factor to sign a challenge nonce presented through a direct interface between the authenticator and endpoint (e.g., a USB port or secured wireless connection) as specified in Sec. 5.2.12. Alternatively, the authenticator could be a suitably secure processor integrated with the user endpoint itself (e.g., a hardware TPM).

The secret key and its algorithm SHALL provide at least the minimum security length specified in the latest revision of [SP800-131A] (112 bits as of the date of this publication). The challenge nonce SHALL be at least 64 bits in length. Approved cryptography SHALL be used.

Cryptographic device authenticators differ from cryptographic software authenticators because of the greater protection afforded to the embedded authentication secrets by cryptographic devices. In order to be considered a cryptographic device, an authenticator SHALL either be a separate piece of hardware or an embedded processor or execution environment, e.g., secure element, trusted execution environment (TEE), trusted platform module (TPM). A cryptographic device authenticator SHALL be designed so as to prohibit the export of the authentication secret to the host processor and SHALL NOT be capable of being reprogrammed by the host processor so as to allow the secret to be extracted. The authenticator is subject to applicable [FIPS140] requirements of the AAL at which the authenticator is being used.

Each authentication operation using the authenticator SHOULD require the input of the activation factor. Input of the activation factor MAY be accomplished via either direct input on the device or via a hardware connection (e.g., USB, smartcard).

The use of an activation secret by the authenticator SHALL meet the requirements of Sec. 5.2.11. A biometric activation factor SHALL meet the requirements of Sec. 5.2.3, including limits on the number of consecutive authentication failures. Submission of the activation factor SHALL be a separate operation from unlocking of the host device (e.g., smartphone), although the same activation factor used to unlock the host device MAY be used in the authentication operation. The activation secret or biometric sample — and any biometric data derived from the biometric sample such as a probe produced through signal processing — SHALL be zeroized immediately after an authentication transaction has taken place.

Multi-Factor Cryptographic Device Verifiers

The requirements for a multi-factor cryptographic device verifier are identical to those for a single-factor cryptographic device verifier, described in Sec. 5.1.7.2. Verification of the authenticator output from a multi-factor cryptographic device proves use of the activation factor.

General Authenticator Requirements

Physical Authenticators

CSPs SHALL provide subscriber instructions on how to appropriately protect the authenticator against theft or loss. The CSP SHALL provide a mechanism to invalidate the authenticator immediately upon notification from subscriber that loss or theft of the authenticator is suspected.

Rate Limiting (Throttling)

When required by the authenticator type descriptions in Sec. 5.1, the verifier SHALL implement controls to protect against online guessing attacks. Unless otherwise specified in the description of a given authenticator, the verifier SHALL limit consecutive failed authentication attempts on a single subscriber account to no more than 100.

Additional techniques MAY be used to reduce the likelihood that an attacker will lock the legitimate claimant out as a result of rate limiting. These include:

• Requiring the claimant to complete a bot-detection and mitigation challenge before attempting authentication.

• Requiring the claimant to wait following a failed attempt for a period of time that increases as the subscriber account approaches its maximum allowance for consecutive failed attempts (e.g., 30 seconds up to an hour).

• Accepting only authentication requests that come from an allowlist of IP addresses from which the subscriber has been successfully authenticated before.

• Leveraging other risk-based or adaptive authentication techniques to identify user behavior that falls within, or out of, typical norms. These might, for example, include use of IP address, geolocation, timing of request patterns, or browser metadata.

When the subscriber successfully authenticates, the verifier SHOULD disregard any previous failed attempts for that user from the same IP address.

Use of Biometrics

The use of biometrics (something you are) in authentication includes both measurement of physical characteristics (e.g., fingerprint, iris, facial characteristics) and behavioral characteristics (e.g., typing cadence). Both classes are considered biometric modalities, although different modalities may differ in the extent to which they establish authentication intent as described in Sec. 5.2.9.

For a variety of reasons, this document supports only limited use of biometrics for authentication. These reasons include:

• The biometric False Match Rate (FMR) does not provide confidence in the authentication of the subscriber by itself. In addition, FMR does not account for spoofing attacks.
• Biometric comparison is probabilistic, whereas the other authentication factors are deterministic.
• Biometric template protection schemes provide a method for revoking biometric credentials that is comparable to other authentication factors (e.g., PKI certificates and passwords). However, the availability of such solutions is limited, and standards for testing these methods are under development.
• Biometric characteristics do not constitute secrets. They can often be obtained online or, in the case of a facial image, by taking a picture of someone with or without their knowledge. Latent fingerprints can be lifted from objects someone touches, and iris patterns can be captured with high resolution images. While presentation attack detection (PAD) technologies can mitigate the risk of these types of attacks, additional trust in the sensor or biometric processing is required to ensure that PAD is operating in accordance with the needs of the CSP and the subscriber.

Therefore, the limited use of biometrics for authentication is supported with the following requirements and guidelines:

Biometrics SHALL be used only as part of multi-factor authentication with a physical authenticator (something you have).

The biometric system SHALL operate with a false-match rate (FMR) [ISO/IEC2382-37] of 1 in 10000 or better. This FMR SHALL be achieved under conditions of a conformant attack (i.e., zero-effort impostor attempt) as defined in [ISO/IEC30107-1].

The biometric system SHOULD implement presentation attack detection (PAD). Testing of the biometric system to be deployed SHOULD demonstrate at least 90% resistance to presentation attacks for each relevant attack type (i.e., species), where resistance is defined as the number of thwarted presentation attacks divided by the number of trial presentation attacks. Testing of presentation attack resistance SHALL be in accordance with Clause 12 of [ISO/IEC30107-3]. The PAD decision MAY be made either locally on the claimant’s device or by a central verifier.

The biometric system SHALL allow no more than 5 consecutive failed authentication attempts or 10 consecutive failed attempts if PAD, meeting the above requirements, is implemented. Once that limit has been reached, the biometric authenticator SHALL impose a delay of at least 30 seconds before each subsequent attempt, with an overall limit of no more than 50 consecutive failed authentication attempts (100 if PAD is implemented). Once the overall limit is reached, the biometric system SHALL disable biometric user authentication and offer another factor (e.g., a different biometric modality or an activation secret if it is not already a required factor) if such an alternative method is already available.

The verifier SHALL make a determination of sensor and endpoint performance, integrity, and authenticity. Acceptable methods for making this determination include, but are not limited to:

• Authentication of the sensor or endpoint
• Certification by an approved accreditation authority
• Runtime interrogation of signed metadata (e.g., attestation) as described in Sec. 5.2.4.

Biometric comparison can be performed locally on the claimant’s device or at a central verifier. Since the potential for attacks on a larger scale is greater at central verifiers, comparison SHOULD be performed locally.

If comparison is performed centrally:

• Use of the biometric as an authentication factor SHALL be limited to one or more specific devices that are identified using approved cryptography. Since the biometric has not yet unlocked the main authentication key, a separate key SHALL be used for identifying the device.
• Biometric revocation, referred to as biometric template protection in [ISO/IEC24745], SHALL be implemented.
• An authenticated protected channel between sensor (or an endpoint containing a sensor that resists sensor replacement) and verifier SHALL be established and the sensor or endpoint SHALL be authenticated prior to capturing the biometric sample from the claimant.
• All transmission of biometrics SHALL be over an authenticated protected channel.

Biometric samples collected in the authentication process MAY be used to train comparison algorithms or — with user consent — for other research purposes. Biometric samples and any biometric data derived from the biometric sample such as a probe produced through signal processing SHALL be zeroized immediately after any training or research data has been derived.

Biometric authentication technologies SHALL provide similar performance for subscribers of different demographic types (racial background, gender, ethnicity, etc.).

Attestation

An attestation is information conveyed to the verifier regarding a connected authenticator or the endpoint involved in an authentication operation. Information conveyed by attestation MAY include, but is not limited to:

• The provenance (e.g., manufacturer or supplier certification), health, and integrity of the authenticator and endpoint
• Security features of the authenticator
• Security and performance characteristics of biometric sensors
• Sensor modality

If this attestation is signed, it SHALL be signed using a digital signature that provides at least the minimum security strength specified in the latest revision of [SP800-131A] (112 bits as of the date of this publication).

Attestation information MAY be used as part of a verifier’s risk-based authentication decision.

Phishing (Verifier Impersonation) Resistance

Phishing attacks, previously referred to in SP 800-63B as “verifier impersonation,” are attempts by fraudulent verifiers and RPs to fool an unwary claimant into presenting an authenticator to an impostor. In some prior versions of SP 800-63, protocols resistant to phishing attacks were also referred to as “strongly MitM resistant.”

The term phishing is widely used to describe a variety of similar attacks. For the purposes of this document, phishing resistance is the ability of the authentication protocol to detect and prevent disclosure of authentication secrets and valid authenticator outputs to an impostor relying party without reliance on the vigilance of the subscriber. The means by which the subscriber was directed to the impostor relying party are not relevant. For example, regardless of whether the subscriber was directed there via search engine optimization or prompted by email, it is considered to be a phishing attack.

Approved cryptographic algorithms SHALL be used to establish phishing resistance where it is required. Keys used for this purpose SHALL provide at least the minimum security strength specified in the latest revision of [SP800-131A] (112 bits as of the date of this publication).

Authenticators that involve the manual entry of an authenticator output, such as out-of-band and OTP authenticators, SHALL NOT be considered phishing resistant because the manual entry does not bind the authenticator output to the specific session being authenticated. In an AitM attack, an impostor verifier could replay the OTP authenticator output to the verifier and successfully authenticate.

While an individual authenticator may be phishing resistant, phishing resistance for a given subscriber account is only achieved when all methods of authentication are phishing resistant.

Two methods of phishing resistance are recognized: channel binding and verifier name binding. Channel binding is considered more secure than verifier name binding because it is not vulnerable to mis-issuance or misappropriation of relying party certificates, but either method satisfies the requirements for phishing resistance.

Channel Binding

An authentication protocol with channel binding SHALL establish an authenticated protected channel with the verifier. It SHALL then strongly and irreversibly bind a channel identifier that was negotiated in establishing the authenticated protected channel to the authenticator output (e.g., by signing the two values together using a private key controlled by the claimant for which the public key is known to the verifier). The verifier SHALL validate the signature or other information used to prove phishing resistance. This prevents an impostor verifier, even one that has obtained a certificate representing the actual verifier, from successfully relaying that authentication on a different authenticated protected channel.

An example of a phishing resistant authentication protocol that uses channel binding is client-authenticated TLS, because the client signs the authenticator output along with earlier messages from the protocol that are unique to the particular TLS connection being negotiated.

Verifier Name Binding

An authentication protocol with authenticator name binding SHALL establish an authenticated protected channel with the verifier. It SHALL then generate an authenticator output that is cryptographically bound to a verifier identifier that is authenticated as part of the protocol. In the case of domain name system (DNS) identifiers, the verifier identifier SHALL be either the authenticated hostname of the verifier or a parent domain that is at least one level below the public suffix [PSL] associated with that hostname. The binding MAY be established by choosing an associated authenticator secret, by deriving an authenticator secret using the verifier identifier, by cryptographically signing the authenticator output with the verifier identifier, or similar cryptographically secure means.

Verifier-CSP Communications

In situations where the verifier and CSP are separate entities (as shown by the dotted line in [SP800-63] Figure 1), communications between the verifier and CSP SHALL occur through a mutually authenticated secure channel (such as a client-authenticated TLS connection) using approved cryptography.

Verifier Compromise Resistance

Use of some types of authenticators requires that the verifier store a copy of the authenticator secret. For example, an OTP authenticator (described in Sec. 5.1.4) requires that the verifier independently generate the authenticator output for comparison against the value sent by the claimant. Because of the potential for the verifier to be compromised and stored secrets stolen, authentication protocols that do not require the verifier to persistently store secrets that could be used for authentication are considered stronger, and are described herein as being verifier compromise resistant. Note that such verifiers are not resistant to all attacks. A verifier could be compromised in a different way, such as being manipulated into always accepting a particular authenticator output.

Verifier compromise resistance can be achieved in different ways, for example:

• Use a cryptographic authenticator that requires the verifier store a public key corresponding to a private key held by the authenticator.

• Store the expected authenticator output in hashed form. This method can be used with some look-up secret authenticators (described in Sec. 5.1.2), for example.

To be considered verifier compromise resistant, public keys stored by the verifier SHALL be associated with the use of approved cryptographic algorithms and SHALL provide at least the minimum security strength specified in the latest revision of [SP800-131A] (112 bits as of the date of this publication).

Other verifier compromise resistant secrets SHALL use approved hash algorithms and the underlying secrets SHALL have at least the minimum security strength specified in the latest revision of [SP800-131A] (112 bits as of the date of this publication). Secrets (e.g., memorized secrets) having lower complexity SHALL NOT be considered verifier compromise resistant when hashed because of the potential to defeat the hashing process through dictionary lookup or exhaustive search.

Replay Resistance

An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message. Replay resistance is in addition to the replay-resistant nature of authenticated protected channel protocols, since the output could be stolen prior to entry into the protected channel. Protocols that use nonces or challenges to prove the “freshness” of the transaction are resistant to replay attacks since the verifier will easily detect when old protocol messages are replayed since they will not contain the appropriate nonces or timeliness data.

Examples of replay-resistant authenticators are OTP devices, cryptographic authenticators, and look-up secrets.

In contrast, memorized secrets are not considered replay resistant because the authenticator output — the secret itself — is provided for each authentication.

Authentication Intent

An authentication process demonstrates intent if it requires the subject to explicitly respond to each authentication or reauthentication request. The goal of authentication intent is to make it more difficult for authenticators (e.g., multi-factor cryptographic devices) to be used without the subject’s knowledge, such as by malware on the endpoint. Authentication intent SHALL be established by the authenticator itself, although multi-factor cryptographic devices MAY establish intent by reentry of the activation factor for the authenticator.

Authentication intent MAY be established in a number of ways. Authentication processes that require the subject’s intervention establish intent (e.g., a claimant entering an authenticator output from an OTP device). Cryptographic devices that require user action for each authentication or reauthentication operation also establish intent (e.g., pushing a button or reinsertion).

Depending on the modality, presentation of a biometric characteristic may or may not establish authentication intent. Behavioral biometrics similarly may or may not establish authentication intent because they do not always require a specific action on the claimant’s part.

Restricted Authenticators

As threats evolve, authenticators’ capability to resist attacks typically degrades. Conversely, some authenticators’ performance may improve, for example, when changes to their underlying standards increases their ability to resist particular attacks.

To account for these changes in authenticator performance, NIST places additional restrictions on authenticator types or specific classes or instantiations of an authenticator type.

The use of a restricted authenticator requires that the implementing organization assess, understand, and accept the risks associated with that authenticator and acknowledge that risk will likely increase over time. It is the responsibility of the organization to determine the level of acceptable risk for their systems and associated data and to define any methods for mitigating excessive risks. If at any time the organization determines that the risk to any party is unacceptable, then that authenticator SHALL NOT be used.

Further, the risk of an authentication error is typically borne by multiple parties, including the implementing organization, organizations that rely on the authentication decision, and the subscriber. Because the subscriber may be exposed to additional risk when an organization accepts a restricted authenticator and that the subscriber may have a limited understanding of and ability to control that risk, the CSP SHALL:

1. Offer subscribers at least one alternate authenticator that is not restricted and can be used to authenticate at the required AAL.

2. Provide meaningful notice to subscribers regarding the security risks of the restricted authenticator and availability of alternatives that are not restricted.

3. Address any additional risk to subscribers in its risk assessment.

4. Develop a migration plan for the possibility that the restricted authenticator is no longer acceptable at some point in the future and include this migration plan in its digital identity acceptance statement.

Activation Secrets

Memorized secrets that are used as an activation factor for a multi-factor authenticator are referred to as activation secrets. An activation secret is used to decrypt a stored secret key used for authentication or is compared against a locally held stored verifier to provide access to the authentication key. In either of these cases, the activation secret SHALL remain within the authenticator and its associated user endpoint.

Authenticators making use of activation secrets SHALL require the secrets to be at least 6 characters in length. Activation secrets MAY be entirely numeric (i.e., a PIN). If alphanumeric (rather than only numeric) values are permitted, all printing ASCII [RFC20] characters as well as the space character SHOULD be accepted. Unicode [ISO/ISC 10646] characters SHOULD be accepted as well in alphanumeric secrets. The authenticator SHALL contain a blocklist (either specified by specific values or by an algorithm) of at least 10 commonly used activation values and SHALL prevent their use as activation secrets.

The authenticator or verifier SHALL implement a retry-limiting mechanism that effectively limits the number of consecutive failed activation attempts using the authenticator to ten (10). If the entry of an incorrect activation secret causes the authenticator to generate an invalid output that is sent to the central verifier, rate limiting MAY be implemented by the verifier. In all other cases, rate limiting SHALL be implemented in the authenticator. Once the limit of 10 attempts is reached, the authenticator SHALL be disabled and a different authenticator SHALL be required for authentication.

If the authenticator verifies the activation secret locally (rather than using it for decryption of a key), verification SHALL be performed within a hardware-based authenticator or in a secure element (e.g., TEE, TPM) that releases the authentication secret only upon presentation of the correct activation secret. In other circumstances (i.e., software-based multi-factor authenticators), the authenticator SHALL use the memorized secret as a key to decrypt its stored authentication secret. Approved cryptography SHALL be used.

Connected Authenticators

Cryptographic authenticators require a direct connection between the authenticator and the endpoint being authenticated. This connection MAY be wired (e.g., USB or direct connection with a smartcard) or wireless (e.g., NFC, Bluetooth). While in most cases wired connections can be presumed to be secure from eavesdropping and adversary-in-the-middle attacks, additional precautions are required for authenticators that are connected via wireless technologies.

Wired authenticator connections include both authenticators that are embedded in endpoints (e.g., in a TPM) and those that are connected via an external interface, such as USB. Claimants SHOULD be advised to use trusted hardware (cables, etc.) for external connections for additional assurance that they have not been compromised.

Wireless authenticator connections are potentially vulnerable to threats including eavesdropping, injection, and relay attacks. The potential for such attacks depends on the effective range of the wireless technology being used.

Wireless technologies having an effective range of 1 meter or more (e.g., Bluetooth LE) SHALL use an authenticated encrypted connection between the authenticator and endpoint. A pairing process SHALL be used to establish a key for encrypted communication between the authenticator and endpoint. A temporary wired connection between the devices MAY also be used to establish the key in lieu of the pairing process. The pairing process SHALL be authenticated through the use of a pairing code. The pairing code SHALL be associated with either the authenticator or endpoint and SHALL have at least 20 bits or 6 decimal digits of entropy. The pairing code MAY be printed on the associated device and SHALL be conveyed between the devices by manual entry or by using a QR code or similar representation that is optically communicated. An example of this is the pairing code used with the virtual contact interface specified in [SP800-73]. The entire authentication transaction SHALL be encrypted using a key established by the pairing process.

When a wireless technology with an effective range of less than 1 meter is in use (e.g., NFC), the activation secret, if any, transmitted from the endpoint to authenticator SHALL be encrypted using a key established through a pairing process between the devices or through a temporary wired connection. An authenticated connection using a pairing code meeting the above requirements SHOULD be used. If the authenticator is configured to require authenticated pairing, pairing code SHALL be used.

Note: Encryption of only the activation secret, and not the entire authentication transaction, may expose sensitive information such as the identity of the relying party, although this would require the attacker to be very close to the subscriber. Special care should be taken with authenticators containing personally identifiable information that do not require authenticated pairing to protect that information against “skimming” and eavesdropping attacks.

The key established as a result of the pairing process MAY be either temporary (valid for a limited number of transactions or time) or persistent. A mechanism for endpoints to remove persistent keys SHALL be provided.

Where cryptographic operations are required, approved cryptography SHALL be used. All communication of authentication data between authenticators and endpoints SHALL occur directly between those devices or through an authenticated protected channel between the authenticator and endpoint.

Authenticator Lifecycle Management

This section is normative.

Subscriber の Authenticator のライフサイクル全体にわたって, Authenticator の使用に影響を与えるような多くのイベントが発生しうる. これらのイベントには, Binding, 紛失, 盗難, 無許可な複製, 有効期限切れ, および失効などが含まれる. 本セクションでは, これらのイベントに対応して実行すべきアクションについて記述する.

Authenticator Binding

Authenticator Binding とは, 特定の Authenticator と Subscriber Account の関連付けを確立することを指し, Authenticator を - 場合によっては他の Authenticator と組み合わせて - Subscriber Account の Authenticate に使用可能にすることを意味する.

Authenticator は Subscriber Account に以下のいずれかにより紐づけられるものとする (SHALL).

• Enrollment の一環としての CSP による Authenticator の発行
• Subscriber から提供された Authenticator を CSP が受け入れることによる Authenticator の登録

本ガイドライン群は上記の両オプションを考慮して Authenticator の発行ではなく Binding という用語を用いる.

Digital Identity のライフサイクルを通して, CSP は各 Subscriber Account に関連づけられている, ないしは関連づけられていた, すべての Authenticator レコードを管理することとする (SHALL). CSP ないし Verifier は, Sec. 5.2.2 にあるように, 必要に応じて Authentication 試行の Throttling に必要な情報も管理すること (SHALL). さらに, CSP はユーザーが提供する Authenticator のタイプ (e.g., Single-factor Cryptographic Device vs. Multi-factor Cryptographic Device) を検証し, Verifier が各 AAL 要件に準拠しているか判断できるようにすること (SHALL).

CSP が生成するレコードには, Authenticator が Subscriber Account に紐づけられた日時を含めること (SHALL). このレコードには, Enrollment に関与したすべてのデバイスとの Binding の発生源 (e.g., IP アドレス, Device 識別子) に関する情報も含めるべきである (SHOULD). 可能であれば, このレコードには当該 Authenticator による Authentication 試行失敗の発生源に関する情報も含めるべきである (SHOULD).

新しい Authenticator を Subscriber Account に紐づける際, CSP は Binding Protocol と関連する鍵の提示プロトコルが当該 Authenticator が用いられる AAL に見合ったセキュリティレベルであることを保証すること (SHALL). 例えば, 関連する鍵の提示プロトコルは Authenticated Protected Channel を使うか対面で行い, Adversary-in-the-Middle Attack から保護しなければならない (SHALL). Multi-factor Authenticator の Binding には, Multi-factor Authentication ないしそれ相当 (e.g., Identity Proofing が完了した直後の Session との関連付け) の利用を必要としなければならない (SHALL). 同じ条件は, Authenticator により Key Pair が生成され Public Key が CSP に送信される際にも適用される.

Binding プロセスの一環として, CSP は, 要求されている AAL に適合しているか, およびエンドポイントと Authenticator がマルウェアに感染していないかどうか判断するために, 新しい Authenticator やそれに関連するエンドポイントに関する追加情報を要求してもよい (MAY).

Binding at Enrollment

Enrollment プロセスの一環として Authenticator を Subscriber Account に紐づける際には, 以下の要件が適用される.

CSP は, Memorized Secret や1つ以上の Biometric Characteristics (生体特徴) に加え, 最低限1つ - そしてできれば最低限2つ (SHOULD) - の物理 Authenticator (something you have) を Subscriber Account に紐づけなければならない (SHALL). 複数の Authenticator の Binding により, Subscriber のプライマリー Authenticator の 紛失や盗難時のリカバリー手段が確保される. オンラインマテリアルやオンラインレピュテーションが長期間維持されていくほど, Authenticator を紛失し Subscriber Account のコントロールを失うことはますます望ましくないものとなる. 2つめの Authenticator は Authenticator 紛失時のセキュアなリカバリーを可能とする.

Enrollment と Binding が一度の物理的やりとりや電子的 Transaction (i.e., 単一の Protected Session 内) で完了できない場合は, 以下の方法によりプロセス全体を通じて同じ当事者が Applicant として行動していることを保証すること (SHALL).

Remote Transaction の場合:

1. Applicant は, 各新規 Binding Transaction において, 事前の Transaction 内で確立された, ないしは Applicant の電話番号, メールアドレスまたは Address of Record に配送された Temporary Secret を提示して, 自らを同定しなければならない (SHALL).

1. 長期間有効な Authenticator Secret は, Protected Session 内で Applicant に発行せねばならない (SHALL).

対面の Transaction の場合:

1. Applicant は, 上記 Remote Transaction (1) で述べたシークレットか事前の対面処理中に記録された Biometric を利用して, 自らを同定せねばならない (SHALL).

1. Temporary Secret を再利用してはならない (SHALL NOT).

1. CSP が物理 Transaction 中に長期間有効な Authenticator Secret を発行する場合, その Authenticator Secret は Applicant に対面で発行される物理デバイスにその場でロードするか, Address of Record を確認できる方法で配送されなければならない (SHALL).

Post-Enrollment Binding

Binding of an Additional Authenticator at Existing AAL

Memorized Secret を除き, CSP と Verifier は, Subscriber が使用することになる, ファクターの異なる最低限2つ以上の有効な Authenticator を維持するよう推奨すべきである (SHOULD). 例えば, 普段 OTP Device を物理 Authenticator として使用する Subscriber には, 物理 Authenticator が紛失, 盗難, 損傷した場合にそなえ, いくつかの Look-up Secret Authenticator を発行したり, Out-of-band Authentication のためのデバイスを登録させることができる (MAY). Memorized Secret Authenticator の置換に関する詳細情報は Sec. 6.1.2.3 を参照のこと.

以上のことから, CSP は追加の Authenticator を Subscriber Account に紐づけることを許容するべきである (SHOULD). 新しい Authenticator を追加する前に, CSP は Subscriber に 当該 Authenticator が利用されることになる AAL (ないしより高い AAL) で Authenticate することを要求しなければならない (SHALL). 新 Authenticator の紐付け要求に続いて, 既存の Authenticator を用いた独立した Authentication を実行し (SHALL), 当該 Authentication を20分間有効とすること (SHALL). Authenticator が追加された際, CSP は Subscriber に新しい Authenticator を紐づけた Transaction とは独立したメカニズムを用いて通知を送るべきである (SHOUD) (e.g., 事前に Subscriber に関連づけられていたアドレスへの Email). CSP はこの方法で紐づけられる Authenticator の数を制限してもよい (MAY).

Adding an Additional Factor to a Single-Factor Subscriber Account

Subscriber Account が1つしか Authentication Factor を持たず, 異なる Authentication Factor の Authenticator が追加されようとしている時, Subscriber は Subscriber Account を AAL2 に昇格するよう要求することができる (MAY).

新たな Authenticator を紐づける前に, CSP は Subscriber に AAL1 で Authenticate するよう要求しなければならない (SHALL). CSP は, 新しい Authenticator を紐づけた Transaction とは独立したメカニズムを用いて, Subscriber に当該イベントに関する通知を送るべきである (SHOULD) (e.g., 事前に Subscriber に関連づけられていたアドレスへの Email).

Account Recovery

Subscriber が Authenticator の制御を失った状況から Authenticate を成功させることができるようにするシチュエーションを, 一般的に Account Recovery と呼ぶ.

Identity Proofing を終えた Subscriber が Authentication を完了するために必要なすべての Authenticator を失った場合, [SP800-63A] にあるように Subscriber は Identity Proofing プロセスをやり直さねばならない (SHALL). CSP が ([SP800-63A] Sec. 5.2.2 にあるプライバシーリスク評価に従って) 元の Identity Proofing プロセスで用いられた Evidence の情報を保持しており, 元の Identity Proofing プロセスが当該 Evidence の有効性を検証した上で Subscriber に対して Verification を実行するだけで事足りるものであれば, 2度目のやり直しプロセスは [SP800-63A] にあるように Identity Proofing プロセスの Verification のみを再実行するだけでよい (MAY).

CSP は, Claimant がもしまだ残されたファクターの Authenticator を保持していれば, 既存 Subscriber Account との Binding を確認するため, それを用いて Authenticate するよう要求しなければならない (SHALL). IAL3 における Autentication Factor の再確立は, [SP800-63A] Sec. 5.6.8 にあるように対面ないし Supervised Remote プロセスを介して行わねばならず (SHALL), 元の Identity Proofing プロセス中に収集された Biometric 特性に対する Biometrics 比較を行わねばならない (SHALL).

CSP は Subscriber にこのイベントの通知を送るべきである (SHALL). これは Identity Proofing プロセスの一環として要求されたものと同じ通知でもよい (MAY).

Identity Proofing を終えていない Subscriber Account (i.e., IAL がない) は, Subscriber を当該アカウントに再び関連づける信頼できる方法が存在しないため, リカバリーもできない. そういったアカウントは放棄されたものとして扱い (SHALL), 新たな Subscriber Account を確立すること (SHALL).

紛失した (i.e., 忘れ去られた) Memorized Secret の置換は, それが非常に一般的であるがゆえに問題が多い. 追加の “バックアップ用” Memorized Secret は, 大抵の場合それもまた忘れ去られるため, 対策にならない. Biometric が Subscriber Account に紐づいていれば, 新たな Memorized Secret の確立にこの Biometrics 特徴と関連する物理 Authenticator を用いるべきである (SHALL).

Subscriber Account に Biometric が紐づけられていない場合における上記の再 Proofing プロセスの代替として, CSP は, Subscriber の Address of Record の1つに送られた確認コードとともに, 2つの物理 Authenticator を用いて, 新たな Memorized Secret を Authentication に紐づけることもできる (MAY). この確認コードは, Approved な乱数ビット生成器 [SP800-90Ar1] で生成された最低限6文字のランダムな英数字で構成すること (SHALL). 確認コードは最大限以下の期間のみ有効なものとする (SHALL).

• 米国本土の Address of Record に郵送される場合は21日.
• 米国本土以外の Address of Record に郵送される場合は30日.
• 記録済電話番号に (SMS ないし音声で) 送信される場合は10分.
• 記録済 Email アドレスに送信される場合は24時間.

External Authenticator Binding

External Authenticator Binding とは, Authenticated エンドポイントに接続されていない (または埋め込まれていない) Authenticator を Subscriber Account に Binding するプロセスである. 通常このプロセスは, 新たなエンドポイントに埋め込まれた Authenticator を追加する, ないしは接続の制限により新しく紐づけられた Authenticator が Authenticated エンドポイントに接続できない際に用いられる.

Binding プロセスは, CSP に Authenticate されたエンドポイントからの要求により開始できる (MAY). CSP への Authenticate は, CSP から受け取った Binding Code を, 新たな Authenticator に関連づけられたエンドポイントに入力して CSP に送信することで行う. さらに, 新たな Authenticator に関連づけられたエンドポイントが, CSP から Binding Code を取得して, それを Authenticated エンドポイントに入力して CSP に送信することもできる (MAY).

上記 Sec. 6.1.2.1, Sec. 6.1.2.2, および Sec. 6.1.2.3 に挙げた要件に加え, External Authenticator Binding には以下の要件も適用される.

• 新たな Auehtnicator に関連づけられるエンドポイントと CSP が Authenticated Protected Session を確立すること (SHALL).

• 新たな Authenticator に関連づけられるエンドポイントにおいて, CSP が Subscriber を識別できるような識別子を Subscriber に入力するよう促しても良い (MAY).

• CSP は Approved な乱数生成器を用いて Binding Code を生成し, それを新たな Authenticator エンドポイントないし Binding を許可しようとしている Authenticated エンドポイントに送らなければならない (SHALL). 前ステップで入力された識別子と組み合わせて使用する場合, Binding Code は最低限40bitのEntropyを持つものとする (SHALL). それ以外の場合は少なくとも112bitの Entropy が必要となる (SHALL).

• Subscriber は Binding Code を他方のエンドポイントに送信しなければならない (SHALL). この送信は手動ないし QR コード等のローカルの Out-of-band な手法で行うべきである (SHOULD). Binding Code は Email や PSTN (SMS / 音声) のようなセキュアでない経路で送信してはならない (SHALL NOT).

• Binding Code の利用は一度きりとし (SHALL), 有効期限は最大10分までとする (SHALL).

• 新たな Authenticator の Binding (PKI ベースの Authenticator の場合は証明書の発行) の後, CSP は当該プロセスが成功裏に完了したことを確認するため, Subscriber に新たな Authenticator を用いて Authenticate するよう促すべきである (SHOULD).

• CSP は, Authenticator Binding の事故が発生した場合に何をすべきか, Subscriber に明確な手順書を提供すること (SHALL). これには誤って紐づけられた Authenticator を即座に適切に無効化できるようなボタンや連絡先などが挙げられる. これは Authenticated Session や Binding 通知ないで提供することもできる (MAY). Binding 通知に関しては Sec. 6.1.2.1, Sec. 6.1.2.2, Sec. 6.1.2.3 を参照のこと.

Subscriber が騙されて Attacker に Binding Code を使用させられたり, Attacker に Binding Code を提供してしまったりする可能性があるため, External Authenticator の Binding は潜在的にリスクのある操作である. 場合によっては, 信頼できる情報源 (Authenticated Session から取得したものなど, 特に Authenticated Session が Phishing 耐性を持つものであればことさら) から取得した QR コードはそのような攻撃に対してより堅牢であると考えられる. これは通常そのような QR コードが Binding Code とともに CSP の URL を含むからである. そのような条件下では, Subscriber が騙されて Phishing サイトで Binding Code を入力する可能性が低くなる.

Binding to a Subscriber-provided Authenticator

Subscriber は特定の AAL での Authentication に適した Authenticator をすでに所有している可能性もある. 例えば, AAL2 および IAL1 とみなされるソーシャルネットワークプロバイダーから提供された2-factor Authenticator を持っており, その Credential を IAL2 を要求する RP に対して使用したいかもしれない.

CSP は, 差し支えなければ, Subscriber が提供した Authenticator を使用できるようにし, 多数の Authenticator を管理するという Subscriber の負担を軽減すべきである (SHOULD). そういった Authenticator の Binding に関しては Sec. 6.1.2 に従うこと (SHALL). Authenticator の強度が自明でない場合 (e.g., 特定のタイプの Single-factor Authenticator と Multi-factor Authenticator の間), より強力な Authenticator が実際に使われていることを立証 (e.g., Authenticator 発行者ないし製造者に対する Verification) できない限り, CSP はより弱い Authenticator が使われているものと想定すること (SHALL).

Renewal

Subscriber は, 既存の Authenticator の有効期限が切れる前に, 適切な時間的余裕を持って, 新規または更新すべき Authenticator を紐づけるべきである (SHOULD). このプロセスは, Sec. 6.1.2.1 で述べた追加の Authenticator の Binding プロセスにしっかりと従うべきである (SHOULD). CSP は, 更新プロセスの一環ないしそれとは別に, Address of Record の再確認などの他のアクションを定期的に実行してもよい (MAY). Authenticator の交換に成功した後, CSP は有効期限が切れそうな Authenticator を無効化してもよい (MAY).

Loss, Theft, Damage, and Unauthorized Duplication

侵害された Authenticator には, 紛失, 盗難, 無許可の複製の対象となったものなどが含まれる. 一般に, 紛失した Authenticator は, 正規の Subscriber ではない誰かに盗まれたか侵害されたと想定する必要がある. 損傷ないし誤動作している Authenticator もまた, Authenticator Secret が抽出される可能性を防止するため, 侵害されたとみなされる. ただし, Attacker に取得されたなどの侵害の兆候もなく忘れ去られた Memorized Secret は例外とする.

侵害された Authenticator の一時停止, 失効, ないし破棄は, それを検出した時点で出来る限り迅速に行うべきである (SHOULD). 組織はこのプロセスにタイムリミットを設定すべきである (SHOULD).

Authenticator の紛失, 盗難, ないし損傷をセキュアに報告しやすくするため, CSP は Subscriber にバックアップまたは代替の Authenticator を使って CSP に対する Authenticate を行う手段を提供すべきである (SHOULD). このバックアップ Authenticator は Memorized Secret ないし物理 Authenticator とすること (SHALL). どちらを使用して良いが, この報告には必要な Authentication Factor はどちらか一方のみである. また代わりに, Subscriber が CSP と Authenticated Protected Channel を確立し, Proofing プロセス中に収集された情報を検証することもできる (MAY). CSP は Address of Record の検証 (i.e., Email, 電話, 郵便) を選択し, 侵害報告のあった Authenticator を一時停止にしてもよい (MAY). Subscriber が有効な (i.e., 一時停止されていない) Authenticator を使用して CSP への Authentication に成功し, 同じ方法で一時停止にされた Authentication の Reactivation を要求した場合, 一時停止は元に戻すものとする (SHALL). CSP は, 一時停止された Authenticator が Reactivate できなくなるまでのタイムリミットを設定してもよい (MAY).

Expiration

CSP は有効期限付きの Authenticator を発行しても良い (MAY). Authenticator が有効期限切れになった場合, それを Authentication に使用可能にしてはならない (SHALL NOT). 有効期限切れの Authenticator を用いた Authentication 試行があった場合, CSP は Authentication の失敗が他の要因ではなく期限切れによるものであることを Subscriber に通知すべきである (SHOULD).

CSP は Subscriber に対して, 有効期限切れ後または更新された Authenticator の受領後出来るだけ早く, CSP が署名した Attribute Certificate を含む物理 Authenticator を返却するよう, または破棄したことを証明するよう要求すること (SHALL).

Invalidation

Authenticator の無効化 (Invalidation) とは, Authenticator と Subscriber Account の間の Binding を削除することをいう (Revocation や Termination と呼ばれることもある).

CSP は, Subscriber Account が存在しなくなった場合 (e.g., Subscriber の死亡, 不正な Subscriber の発見), Subscriber から要求を受けた場合, ないしは Subscriber がもう適格要件を満たさないと CSP が判断した場合, 即座に Authenticator を無効化しなければならない (SHALL).

CSP は, 無効化を実施した後できるだけ早く, CSP が署名した証明書などの Subscriber Attribute を含む物理 Authenticator の返却または破棄証明を Subscriber に要求すること (SHALL). これは, Subscriber のプライバシーを保護し, 証明書が無効化されてから期限切れになるまでの間にオフラインの状況で利用されることを防止するために必要である.

PIV Authenticator の無効化に関するさらなる要件については [FIPS201] を参照のこと.

Authenticator Lifecycle Management

This section is normative.

A number of events can occur over the lifecycle of a subscriber’s authenticator that affect that authenticator’s use. These events include binding, loss, theft, unauthorized duplication, expiration, and revocation. This section describes the actions to be taken in response to those events.

Authenticator Binding

Authenticator binding refers to the establishment of an association between a specific authenticator and a subscriber account, enabling the authenticator to be used — possibly in conjunction with other authenticators — to authenticate for that subscriber account.

Authenticators SHALL be bound to subscriber accounts either

• by issuance by the CSP as part of enrollment or
• by registration of a subscriber-provided authenticator that is acceptable to the CSP.

These guidelines refer to the binding rather than the issuance of an authenticator to accommodate both options.

Throughout the digital identity lifecycle, CSPs SHALL maintain a record of all authenticators that are or have been associated with each subscriber account. The CSP or verifier SHALL maintain the information required for throttling authentication attempts when required, as described in Sec. 5.2.2. The CSP SHALL also verify the type of user-provided authenticator (e.g., single-factor cryptographic device vs. multi-factor cryptographic device) so verifiers can determine compliance with requirements at each AAL.

The record created by the CSP SHALL contain the date and time the authenticator was bound to the subscriber account. The record SHOULD include information about the source of the binding (e.g., IP address, device identifier) of any device associated with the enrollment. If available, the record SHOULD also contain information about the source of unsuccessful authentications attempted with the authenticator.

When any new authenticator is bound to a subscriber account, the CSP SHALL ensure that the binding protocol and the protocol for provisioning the associated keys are done at a level of security commensurate with the AAL at which the authenticator will be used. For example, protocols for key provisioning SHALL use authenticated protected channels or be performed in person to protect against adversary-in-the-middle attacks. Binding of multi-factor authenticators SHALL require multi-factor authentication or equivalent (e.g., association with the session in which identity proofing has been just completed) be used in order to bind the authenticator. The same conditions apply when a key pair is generated by the authenticator and the public key is sent to the CSP.

As part of the binding process, the CSP MAY require additional information about the new authenticator or the endpoint it is associated with to determine that they are suitable for the AAL being requested and to attempt to determine that the endpoint and authenticator are free from malware.

Binding at Enrollment

The following requirements apply when an authenticator is bound to a subscriber account as part of the enrollment process.

The CSP SHALL bind at least one — and SHOULD bind at least two — physical (something you have) authenticators to the subscriber account, in addition to a memorized secret or one or more biometric characteristics. Binding of multiple authenticators provides a means to recover from the loss or theft of the subscriber’s primary authenticator. Preservation of online material or an online reputation makes it undesirable to lose control of a subscriber account due to the loss of an authenticator. The second authenticator makes it possible to securely recover from an authenticator loss.

If enrollment and binding cannot be completed in a single physical encounter or electronic transaction (i.e., within a single protected session), the following methods SHALL be used to ensure that the same party acts as the applicant throughout the processes:

For remote transactions:

1. The applicant SHALL identify themselves in each new binding transaction by presenting a temporary secret which was either established during a prior transaction, or sent to the applicant’s phone number, email address, or postal address of record.

2. Long-term authenticator secrets SHALL only be issued to the applicant within a protected session.

For in-person transactions:

1. The applicant SHALL identify themselves in person by either using a secret as described in remote transaction (1) above, or through use of a biometric that was recorded during a prior encounter.

2. Temporary secrets SHALL NOT be reused.

3. If the CSP issues long-term authenticator secrets during a physical transaction, then they SHALL be loaded locally onto a physical device that is issued in person to the applicant or delivered in a manner that confirms the address of record.

Post-Enrollment Binding

Binding of an Additional Authenticator at Existing AAL

With the exception of memorized secrets, CSPs and verifiers SHOULD encourage subscribers to maintain at least two valid authenticators of each factor that they will be using. For example, a subscriber who usually uses an OTP device as a physical authenticator MAY also be issued a number of look-up secret authenticators, or register a device for out-of-band authentication, in case the physical authenticator is lost, stolen, or damaged. See Sec. 6.1.2.3 for more information on replacement of memorized secret authenticators.

Accordingly, CSPs SHOULD permit the binding of additional authenticators to a subscriber account. Before adding the new authenticator, the CSP SHALL first require the subscriber to authenticate at the AAL (or a higher AAL) at which the new authenticator will be used. A separate authentication using existing authenticators SHALL be performed following the request to bind a new authenticator, and SHALL be valid for 20 minutes. When an authenticator is added, the CSP SHOULD send a notification to the subscriber via a mechanism that is independent of the transaction binding the new authenticator (e.g., email to an address previously associated with the subscriber). The CSP MAY limit the number of authenticators that are bound in this manner.

Adding an Additional Factor to a Single-Factor Subscriber Account

If the subscriber account has only one authentication factor bound to it and an additional authenticator of a different authentication factor is to be added, the subscriber MAY request that the subscriber account be upgraded to AAL2.

Before binding the new authenticator, the CSP SHALL require the subscriber to authenticate at AAL1. The CSP SHOULD send a notification of the event to the subscriber via a mechanism independent of the transaction binding the new authenticator (e.g., email to an address previously associated with the subscriber).

Account Recovery

The situation where a subscriber loses control of authenticators necessary to successfully authenticate is commonly referred to as account recovery.

If a subscriber that has been identity proofed loses all authenticators necessary to complete authentication, that subscriber SHALL repeat the identity proofing process described in [SP800-63A]. If the CSP has retained information from the evidence used in the original identity proofing process (pursuant to a privacy risk assessment as described in [SP800-63A] Sec. 5.2.2) that is sufficient to perform verification of the subscriber and if that evidence is still valid, it MAY repeat only the verification portion of the identity proofing process as described in [SP800-63A].

The CSP SHALL require the claimant to authenticate using an authenticator of the remaining factor, if any, to confirm binding to the existing subscriber account. Reestablishment of authentication factors at IAL3 SHALL be done in person or through a supervised remote process as described in [SP800-63A] Sec. 5.6.8, and SHALL perform a successful biometric comparison against the biometric characteristic collected during the original identity proofing process.

The CSP SHOULD send a notification of the event to the subscriber. This MAY be the same notice that is required as part of the identity proofing process.

Subscriber accounts that have not been identity proofed (i.e., without IAL) cannot be recovered because there is no reliable means for reassociating the subscriber with that account. Such accounts SHALL be treated as abandoned and a new subscriber account SHALL be established.

Replacement of a lost (i.e., forgotten) memorized secret is problematic because it is very common. Additional “backup” memorized secrets do not mitigate this because they are just as likely to also have been forgotten. If a biometric is bound to the subscriber account, the biometric characteristic and associated physical authenticator SHOULD be used to establish a new memorized secret.

As an alternative to the above re-proofing process when there is no biometric bound to the subscriber 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. The confirmation code SHALL consist of at least 6 random alphanumeric characters generated by an approved random bit generator [SP800-90Ar1]. Confirmation codes SHALL be valid for at most:

• 21 days, when sent to a postal address of record within the contiguous United States;
• 30 days, when sent to a postal address of record outside the contiguous United States;
• 10 minutes, when sent to a telephone of record (SMS or voice); or
• 24 hours, when sent to an email address of record.

External Authenticator Binding

External authenticator binding refers to the process of binding an authenticator to a subscriber account when it is not connected to (or embedded in) the authenticated endpoint. This process is typically used when adding authenticators that are embedded in a new endpoint, or when connectivity limitations prevent the newly bound authenticator from being connected to an authenticated endpoint.

The binding process MAY begin with a request from an endpoint that has authenticated to the CSP obtaining a binding code from the CSP that is input into the endpoint associated with the new authenticator and sent to that CSP. Alternatively, the endpoint associated with the new authenticator MAY obtain a binding code from the CSP, which is input to an authenticated endpoint and sent to the CSP.

In addition to the requirements given in Sec. 6.1.2.1, Sec. 6.1.2.2, and Sec. 6.1.2.3 above as applicable, the following requirements SHALL apply when binding an external authenticator:

• An authenticated protected session SHALL be established by the endpoint associated with the new authenticator and the CSP.

• The subscriber MAY be prompted to enter an identifier by which they are known by the CSP on the endpoint associated with the new authenticator.

• The CSP SHALL generate a binding code using an approved random number generator and send it to either the new authenticator endpoint or the authenticated endpoint approving the binding. The binding code SHALL have at least 40 bits of entropy if used in conjunction with an identifier entered on the previous step; otherwise a binding code with at least 112 bits of entropy SHALL be required.

• The subscriber SHALL transfer the binding code to the other endpoint. This transfer SHALL be either manual or via a local out-of-band method such as a QR code. The binding code SHALL NOT be communicated over any insecure channel such as email or PSTN (SMS or voice).

• The binding code SHALL be usable only once and SHALL be valid for a maximum of 10 minutes.

• Following the binding of the new authenticator (or issuance of a certificate, in the case of PKI-based authenticators), the CSP SHOULD encourage the subscriber to authenticate with the new authenticator to confirm that the process has completed successfully.

• The CSP SHALL provide clear instruction on what the subscriber should do in the event of an authenticator binding mishap, such as a button or contact address to allow a mis-bound authenticator to be quickly invalidated as appropriate. This MAY be provided in the authenticated session or in the binding notification described in Sec. 6.1.2.1, Sec. 6.1.2.2, and Sec. 6.1.2.3 above.

Binding an external authenticator is a potentially risky operation because of the potential for the subscriber to be tricked into using a binding code by an attacker or supplying a binding code to an attacker. In some cases, QR codes obtained from a trusted source (such as from an authenticated session, especially when that authentication is phishing resistant) are considered to be more robust against such attacks, because they typically contain the URL of the CSP as well as the binding code. There is less potential for the subscriber to be fooled into entering a binding code at a phishing site as a result.

Binding to a Subscriber-provided Authenticator

A subscriber may already possess authenticators suitable for authentication at a particular AAL. For example, they may have a two-factor authenticator from a social network provider, considered AAL2 and IAL1, and would like to use those credentials at an RP that requires IAL2.

CSPs SHOULD, where practical, accommodate the use of subscriber-provided authenticators in order to relieve the burden to the subscriber of managing a large number of authenticators. Binding of these authenticators SHALL be done as described in Sec. 6.1.2. In situations where the authenticator strength is not self-evident (e.g., between single-factor and multi-factor authenticators of a given type), the CSP SHALL assume the use of the weaker authenticator unless it is able to establish that the stronger authenticator is in fact being used (e.g., by verification with the issuer or manufacturer of the authenticator).

Renewal

The subscriber SHOULD bind a new or updated authenticator an appropriate amount of time before an existing authenticator’s expiration. The process for this SHOULD conform closely to the binding process for an additional authenticator described in Sec. 6.1.2.1. The CSP MAY periodically take other actions, such as reconfirming address of record, either as a part of the renewal process or separately. Following successful use of the replacement authenticator, the CSP MAY invalidate the authenticator that is expiring.

Loss, Theft, Damage, and Unauthorized Duplication

Compromised authenticators include those that have been lost, stolen, or subject to unauthorized duplication. Generally, one must assume that a lost authenticator has been stolen or compromised by someone that is not the legitimate subscriber of the authenticator. Damaged or malfunctioning authenticators are also considered compromised to guard against any possibility of extraction of the authenticator secret. One notable exception is a memorized secret that has been forgotten without other indications of having been compromised, such as having been obtained by an attacker.

Suspension, revocation, or destruction of compromised authenticators SHOULD occur as promptly as practical following detection. Organizations SHOULD establish time limits for this process.

To facilitate secure reporting of the loss, theft, or damage to an authenticator, the CSP SHOULD provide the subscriber with a method of authenticating to the CSP using a backup or alternate authenticator. This backup authenticator SHALL be either a memorized secret or a physical authenticator. Either could be used, but only one authentication factor is required to make this report. Alternatively, the subscriber MAY establish an authenticated protected channel to the CSP and verify information collected during the proofing process. The CSP MAY choose to verify an address of record (i.e., email, telephone, postal) and suspend authenticators reported to have been compromised. The suspension SHALL be reversible if the subscriber successfully authenticates to the CSP using a valid (i.e., not suspended) authenticator and requests reactivation of an authenticator suspended in this manner. The CSP MAY set a time limit after which a suspended authenticator can no longer be reactivated.

Expiration

CSPs MAY issue authenticators that expire. If and when an authenticator expires, it SHALL NOT be usable for authentication. When an authentication is attempted using an expired authenticator, the CSP SHOULD give an indication to the subscriber that the authentication failure is due to expiration rather than some other cause.

The CSP SHALL require subscribers to surrender or prove destruction of any physical authenticator containing attribute certificates signed by the CSP as soon as practical after expiration or receipt of a renewed authenticator.

Invalidation

Invalidation of an authenticator (sometimes referred to as revocation or termination) refers to removal of the binding between an authenticator and a subscriber account.

CSPs SHALL invalidate authenticators promptly when a subscriber account ceases to exist (e.g., subscriber’s death, discovery of a fraudulent subscriber), when requested by the subscriber, or when the CSP determines that the subscriber no longer meets its eligibility requirements.

The CSP SHALL require subscribers to surrender or certify destruction of any physical authenticator containing subscriber attributes, such as certificates signed by the CSP, as soon as practical after invalidation takes place. This is necessary to protect the privacy of the subscriber and to block the use of any certificates in offline situations between invalidation and expiration of the certificates.

Further requirements on the invalidation of PIV authenticators are found in [FIPS201].

Session Management

This section is normative.

一度 Authentication イベントが発生すると, Subscriber が Authentication イベントを繰り返さなくとも, 後続の複数のインタラクションに渡ってアプリケーションを使い続けられるようにすることが望ましいことが多い. この要件は [SP800-63C] で述べる Federation シナリオで特に当てはまる. Federation シナリオでは, Authentication イベントに複数のコンポーネントおよび当事者が関与し, Network 全体で協調する必要がある.

上記の挙動を円滑にするため, Authentication イベントに呼応して Session を開始して, 終了されるまでそれを継続させることもできる (MAY). Session は, 非アクティブタイムアウト, 明示的ログアウトイベント, またはその他の手段を含む, 様々な理由で終了させてよい (MAY). Session は Sec. 7.2 で述べる Reauthentication イベントを通じて継続してもよい (MAY). Reauthentication イベントでは, Subscriber は最初の Authentication イベントの一部または全てを繰り返し, それにより Session を再確立する.

Session Management は頻発する Credential の提示より好ましい. Credential の提示が頻発すると Usability が悪化し, Activation Factor のキャッシング, Authentication Intent の無効化, Authentication イベントの鮮度の不明瞭化などを引き起こすような回避策へのインセンティブを引き起こすことが多い.

Session Bindings

Session は, Subscriber が実行しているソフトウェア - ブラウザ, アプリケーションないしオペレーティングシステム (i.e., Session Subject) - と, Subscriber が Access している RP ないし CSP (i.e., Session Host) の間で発生する. Session Secret は Subscriber のソフトウェアと Access されるサービスの間で共有しなければならない (SHALL). このシークレットは Session の両端を Bind し, Subscriber が長時間サービスを使い続けられるようにする. このシークレットは Subscriber ソフトウェアから直接提示されるか (SHALL), 暗号論的メカニズムによりその保有が証明されなければならない (SHALL).

Authenticated Session の継続性は, Authentication 時に Verifier に発行され, オプションで Session 中に更新される Session Secret を保持しているかどうかに基づいている必要がある (SHALL). Session の性質は次のようなアプリケーションによって異なる.

• “Session” Cookie による Web ブラウザ Session
• Session Secret を保持するモバイルアプリケーション

Session Secret は永続的 (紐づくアプリケーションのリスタートやホストデバイスのリブートを挟んでも保持される) であってはならない (SHALL NOT).

Session Binding に用いられるシークレットは, Authentication イベントに直接レスポンスする Session Host によって生成されなければならない (SHALL). Session は, それを生成するトリガーとなった Authentication イベントの AAL プロパティを継承すべきである (SHOULD). Session は Authentication イベントより低い AAL であるとみなすこともできるが (MAY), Authentication イベントより高い AAL であるとみなしてはならない (SHALL NOT).

Session Binding に用いられるシークレットは以下の全要件を満たさねばならない (SHALL).

1. シークレットは Session Host によってインタラクション中に生成されること. 通常は Authentication 直後に.
2. シークレットは Approved なランダムビット生成器 [SP800-90Ar1] で生成し, 少なくとも64bitの Entropy を持つこと.
3. シークレットは Subscriber がログアウトした際は Session Subject により消去ないし無効化されること.
4. シークレットは Authenticated Protected Channel を利用したデバイスによって送信, 受信されること.
5. シークレットは, AAL に応じて, Sections 4.1.3, 4.2.3, ないし 4.3.3 に指定された時間を超えたのちはタイムアウトし, 受け入れられないこと.
6. シークレットは Host と Subscriber エンドポイント間のセキュアでないコミュニケーションにさらさないこと.

さらに, Session Binding に用いられるシークレットは, Subscriber がログアウトしたりシークレット自身が有効期限切れになったと見なされた時に, Subscriber エンドポイントから削除されるべきである (SHOULD). シークレットは HTML5 Local Storage などのセキュアでない場所に置くべきではない (SHOULD NOT). ローカルストレージは Cross-site Scripting (XSS) Attack に晒される可能性がある.

Authenticated Session は Authentication 後に, HTTPS から HTTP など, セキュアでない通信路にフォールバックしてはならない (SHALL NOT).

URL や POST コンテンツには, Cross-site Request Forgery 対策のために, RP が検証する (SHALL) Session 識別子を含めることとする (SHALL).

長時間 Session を管理するためのメカニズムはいくつか存在する. 後続のセクションでは, さまざまな例を, 各テクノロジー例固有の追加要件および考慮事項とともに示す. OWASP Session Management Cheat Sheet [OWASP-session] にも追加の有益なガイダンスが存在する.

Browser Cookies

ブラウザ Cookie は, Session を生成するための有力なメカニズムであり, サービスに Access する Subscriber を追跡するものである. Cookie は Authenticator ではないが, 短期間のシークレット (セッション中) に適している.

Session の維持に用いられる Cookie は以下の全要件を満たすこと (SHALL).

1. Cookie はセキュア (HTTPS) Session でのみアクセス可能なようタグ付けすること.
2. Cookie は必要最小限のホスト名およびパスのセットでのみアクセス可能であること.

さらに, Session 維持用 Cookie は, JavaScript からアクセスできないようにタグ付け (HttpOnly) されるべきである (SHOULD). 当該 Cookie は, Opaque 文字列 (Session 識別子など) のみで構成されるべきであり (SHOULD), 平文の PII を含むべきではない (SHOULD NOT). また当該 Cookie は, Session 有効期間終了時または終了後すぐに有効期限切れになるようタグ付けされるべきである (SHOULD). 最後の要件は Cookie の蓄積を制限することを目的としたものであり, Session タイムアウトの強制のためにそれに依存してはならない (SHALL NOT).

Access Tokens

Access Token - OAuth などで見られる - は, アプリケーションが Authentication イベント後に Subscriber の代理としてあるサービス群に Access することを許可するために用いられる. RP は, 他のシグナルがない限り, OAuth Access Token が存在することをもって Subscriber がそこに存在すると解釈してはならない (SHALL NOT). OAuth Access Token および関連する Refresh Token は, Authentication Session が終了し Subscriber がアプリケーションを去った後でも長期間有効でありうる (MAY).

Device Identification

Secure Device Identification のその他の手法 - mutual TLS, Token Binding, またはその他のメカニズム - も, Subscriber とサービスの間で Session を実現するために使用できる (MAY).

Reauthentication

Session の定期的な Reauthentication を実行し, Authenticated Session に Subscriber が引き続き存在することを確認すること (SHALL). (i.e., Subscriber がログアウトせずに立ち去っていないか)

Session は, Session Secret の提示のみをもって, (AAL に応じて) セクション 4.1.3, 4.2.3, および 4.3.3 のガイドラインを超えて延長してはならない (SHALL NOT). Session の有効期限が切れる前に, Table 2 で指定された Authentication Factor を Subscriber に求めることで, Reauthentication タイムリミットを延長すること (SHALL).

タイムアウトか他のアクションにより Session が終了した場合は, Subscriber に再度 Authentication を行い新たな Session を確立するよう要求すること (SHALL).

Table 2 AAL Reauthentication Requirements

Note: AAL2 では, 物理 Authenticator ではなく Memorized Secret や Biometric が求められる. Session Secret は something you have であるため, Session の継続には追加の Authentication Factor が求められるのである.

Reauthentication from a Federation or Assertion

[SP800-63C] で述べたように, RP に Authenticate するために Federation Protocol と Identity Provider (IdP) を使用する場合は, Session Management と Reauthentication に特別な考慮事項が適用される. Federation Protocol は Assertion を用いて IdP での Authentication イベントを RP に伝達し, RP はこの Assertion の検証の成功をもって Authenticated Session を開始する. IdP と RP は Session を個別に管理し, Federation Protocol は IdP と RP の Session Management を接続しないため, IdP と RP での Session の終了は互いに独立して行われる. 同様に, Subscriber が複数の RP で持つ Session は, 互いに独立して確立および終了される.

したがって, RP Session が期限切れになり RP が Reauthentication を要求する時, IdP の Session が期限切れになっておらず, Subscriber を明示的に Reauthenticate することなく, IdP のこの Session にもとづいて新たな Assertion が生成される可能性は十分にある. IdP が Authentication イベントの発生時間および詳細を RP に伝えることもできるが, Reauthentication 要件が満たされているかを判断する責任は RP にある. [SP800-63C] Section 5.3 には Federation コンテキストにおける Session Management に関するさらなる詳細および要件が記載されている.

Session Management

This section is normative.

Once an authentication event has taken place, it is often desirable to allow the subscriber to continue using the application across multiple subsequent interactions without requiring them to repeat the authentication event. This requirement is particularly true for federation scenarios — described in [SP800-63C] — where the authentication event necessarily involves several components and parties coordinating across a network.

To facilitate this behavior, a session MAY be started in response to an authentication event, and continue the session until such time that it is terminated. The session MAY be terminated for any number of reasons, including but not limited to an inactivity timeout, an explicit logout event, or other means. The session MAY be continued through a reauthentication event — described in Sec. 7.2 — wherein the subscriber repeats some or all of the initial authentication event, thereby re-establishing the session.

Session management is preferable over continual presentation of credentials as the poor usability of continual presentation often creates incentives for workarounds such as caching of activation factors, negating authentication intent and obscuring the freshness of the authentication event.

Session Bindings

A session occurs between the software that a subscriber is running — such as a browser, application, or operating system (i.e., the session subject) — and the RP or CSP that the subscriber is accessing (i.e., the session host). A session secret SHALL be shared between the subscriber’s software and the service being accessed. This secret binds the two ends of the session, allowing the subscriber to continue using the service over time. The secret SHALL be presented directly by the subscriber’s software or possession of the secret SHALL be proven using a cryptographic mechanism.

Continuity of authenticated sessions SHALL be based upon the possession of a session secret issued by the verifier at the time of authentication and optionally refreshed during the session. The nature of a session depends on the application, such as:

• a web browser session with a “session” cookie, or
• an instance of a mobile application that retains a session secret.

Session secrets SHALL NOT be persistent (retained across a restart of the associated application or a reboot of the host device).

The secret used for session binding SHALL be generated by the session host in direct response to an authentication event. A session SHOULD inherit the AAL properties of the authentication event which triggered its creation. A session MAY be considered at a lower AAL than the authentication event but SHALL NOT be considered at a higher AAL than the authentication event.

Secrets used for session binding SHALL meet all of the following requirements:

1. Secrets are generated by the session host during an interaction, typically immediately following authentication.
2. Secrets are generated by an approved random bit generator [SP800-90Ar1] and contain at least 64 bits of entropy.
3. Secrets are erased or invalidated by the session subject when the subscriber logs out.
4. Secrets are sent to and received from the device using an authenticated protected channel.
5. Secrets will time out and are not accepted after the times specified in Sections 4.1.3, 4.2.3, and 4.3.3, as appropriate for the AAL.
6. Secrets are not made available to insecure communications between the host and subscriber’s endpoint.

In addition, secrets used for session binding SHOULD be erased on the subscriber endpoint when they log out or when the secret is deemed to have expired. They SHOULD NOT be placed in insecure locations such as HTML5 Local Storage due to the potential exposure of local storage to cross-site scripting (XSS) attacks.

Authenticated sessions SHALL NOT fall back to an insecure transport, such as from https to http, following authentication.

URLs or POST content SHALL contain a session identifier that SHALL be verified by the RP to protect against cross-site request forgery.

There are several mechanisms for managing a session over time. The following sections give different examples along with additional requirements and considerations particular to each example technology. Additional informative guidance is available in the OWASP Session Management Cheat Sheet [OWASP-session].

Browser Cookies

Browser cookies are the predominant mechanism by which a session will be created and tracked for a subscriber accessing a service. Cookies are not authenticators, but they are suitable as short-term secrets (for the duration of a session).

Cookies used for session maintenance SHALL meet all of the following requirements:

1. Cookies are tagged to be accessible only on secure (HTTPS) sessions.
2. Cookies are accessible to the minimum practical set of hostnames and paths.

In addition, session maintenance cookies SHOULD be tagged to be inaccessible via JavaScript (HttpOnly). They SHOULD contain only an opaque string (such as a session identifier), and SHOULD NOT contain cleartext PII. They SHOULD be tagged to expire at, or soon after, the session’s validity period. This latter requirement is intended to limit the accumulation of cookies, but SHALL NOT be depended upon to enforce session timeouts.

Access Tokens

An access token — such as found in OAuth — is used to allow an application to access a set of services on a subscriber’s behalf following an authentication event. The presence of an OAuth access token SHALL NOT be interpreted by the RP as presence of the subscriber, in the absence of other signals. The OAuth access token, and any associated refresh tokens, MAY be valid long after the authentication session has ended and the subscriber has left the application.

Device Identification

Other methods of secure device identification — including but not limited to mutual TLS, token binding, or other mechanisms — MAY be used to enact a session between a subscriber and a service.

Reauthentication

Periodic reauthentication of sessions SHALL be performed to confirm the continued presence of the subscriber at an authenticated session (i.e., that the subscriber has not walked away without logging out).

A session SHALL NOT be extended past the guidelines in Sections 4.1.3, 4.2.3, and 4.3.3 (depending on AAL) based on presentation of the session secret alone. Prior to session expiration, the reauthentication time limit SHALL be extended by prompting the subscriber for the authentication factors specified in Table 2.

When a session has been terminated, due to a time-out or other action, the subscriber SHALL be required to establish a new session by authenticating again.

Table 2 AAL Reauthentication Requirements

Note: At AAL2, a memorized secret or biometric, and not a physical authenticator, is required because the session secret is something you have, and an additional authentication factor is required to continue the session.

Reauthentication from a Federation or Assertion

When using a federation protocol and Identity Provider (IdP) to authenticate at the RP as described in [SP800-63C], special considerations apply to session management and reauthentication. The federation protocol communicates an authentication event at the IdP to the RP using an assertion, and the RP then begins an authenticated session based on the successful validation of this assertion. Since the IdP and RP manage sessions separately from each other and the federation protocol does not connect the session management between the IdP and RP, the termination of the subscriber’s sessions at an IdP and at an RP are independent of each other. Likewise, the subscriber’s sessions at multiple different RPs are established and terminated independently of each other.

Consequently, when an RP session expires and the RP requires reauthentication, it is entirely possible that the session at the IdP has not expired and that a new assertion could be generated from this session at the IdP without explicitly reauthenticating the subscriber. The IdP can communicate the time and details of the authentication event to the RP, but it is up to the RP to determine if reauthentication requirements have been met. Section 5.3 of [SP800-63C] provides additional details and requirements for session management within a federation context.

Threats and Security Considerations

This section is informative.

Authenticator Threats

Authenticator のコントロールを取得できる Attacker は, 多くの場合 Authenticator 所有者になりすますことができる. Authenticator に対する脅威は, Authenticator を構成する Authentication Factor タイプに対する Attack に基づいて分類できる.

• Something you know には, Attacker に対する露呈のリスクがある. Attacker は Memorized Secret を推測できるかもしれない. Authenticator が Shared Secret の場合, Attacker は CSP または Verifier への Access を得てシークレット値を取得したり, シークレットのハッシュ値に対する辞書攻撃を実行するかもしれない. Attacker は PIN やパスコードの入力を監視したり, PIN やパスコードのメモ書き等を見つけたり, 悪意あるソフトウェア (e.g., キーロガー) をインストールしてシークレットを取得する可能性もある. さらに Attacker は Verifier が管理する Password データベースへのオフライン攻撃を通じてシークレットを特定するかもしれない.

• Something you have には, 紛失, 損傷, 所有者からの盗難, Attacker による複製などのリスクがある. 例えば所有者のコンピューターへの Access を得た Attacker は, Software Authenticator を複製するかもしれない. Hardware Authenticator は盗難, 改ざん, 複製されるかもしれない. Out-of-band Secret は Attacker に傍受され, Attacker 自身の Session の Authenticate に使用される可能性がある.

• Something you are には, 複製のリスクがある. 例えば, Attacker は Subscriber の指紋のコピーを取得し, レプリカを作成する可能性がある.

本ドキュメントは, Subscriber が Verifier に対して偽って Authenticate しようとしている Attacker と共謀していないことを前提とする. この前提の元, Digital Authentication に用いられる Authenticator に対する脅威を, いくつかの例とともに Table 3 に示す.

Table 3 Authenticator Threats

Threat Mitigation Strategies

上記で特定された脅威を軽減するための手助けとなる関連メカニズムを Table 4 に示す.

Table 4 Mitigating Authenticator Threats

Table 3 に挙げた脅威の軽減には, 他にもいくつかの戦略が適用可能である.

• 多要素 (Multiple factors) により, Attack の成功はさらに困難になる. Attacker が Cryptographic Authenticator を盗んだ上で Memorized Secret を推測しなければならない場合, 両方のファクターを見つけ出すための仕事量は多すぎる可能性がある.

• 物理セキュリティメカニズム (Physical security mechanism) を採用し, 盗まれた Autheticator を複製から保護することも可能である. 物理セキュリティメカニズムは改ざんの証拠, 検出, 応対も可能にしうる.

• 長い Memorized Secret の使用を要求 (Requiring the use of long memorized secrets) する. そのようなシークレットは一般的な辞書には載っておらず, Attacker は全ての取りうる値を総当たりしなければならなくなる可能性がある.

• システムおよび Network セキュリティコントロール (System and network security controls) を採用し, Attacker がシステムへの Access を得たり不正なソフトウェアをインストールすることを防ぐことも可能である.

• 定期的なトレーニング (Periodic training) を実施し, Subscriber がいつどのように侵害 - または侵害の疑い - を報告すべきか, いつどのように Attacker が Authentication プロセスを侵害しようとしていることを示しているかもしれない行動パターンを認識しうるかを理解できるようにすることもできる.

• Out-of-band なテクニック (Out of band techniques) を採用し, 登録デバイス (e.g., 携帯電話) の保持証明を検証することもできる.

Authenticator Recovery

多くの Authentication メカニズムの弱点は, Subscriber が1つ以上の Authenticator のコントロールを失いそれらをリプレイスする必要がある際のプロセスにある. 多くの場合, Subscriber を Authenticate するために残された利用可能な手段は限られており, 経済的な懸念 (e.g., コールセンターの維持費) が安価でしばしば安全性の低いバックアップ Authentication 手法を利用するモチベーションにつながっている. また, Authenticator リカバリーが人間の支援によるものである限り, Social Engineering Attack のリスクもつきものである.

Authentication Factor の Integrity (完全性) を維持するには, あるファクターを含む Authentication を利用して別のファクターの Authenticator を取得できないようにすることが不可欠である. 例えば, Memorized Secret は Look-up Secret の新しいリストを取得するために利用可能であってはならない.

Session Attacks

上記は Authentication イベント自体に対する脅威にフォーカスしているが, Authentication イベントに後続する Session に対する Hijacking Attack も同様のセキュリティインパクトを及ぼしうる. Sec. 7 の Session Management ガイドラインは, XSS などの Attack に対する Session Integrity (完全性) 維持に不可欠である. さらに表示される情報を全てサニタイズして [OWASP-XSS-prevention], 実行可能なコンテンツが含まれないようにすることも重要である. これらのガイドラインは, Session Secret の流出に対するさらなる保護策として, Mobile Code が Session Secret にアクセスできないようにすることも推奨している.

もう一つの Authentication 後の脅威である Cross-site Request Forgery (CSRF) は, 複数の Session を同時にアクティブにするユーザーの傾向を利用する. Session 識別子を Web リクエストに埋め込んで検証し, 有効な URL ないしリクエストが意図せずにまたは悪意を持ってアクティベートされるのを防ぐことが重要である.

Threats and Security Considerations

This section is informative.

Authenticator Threats

An attacker who can gain control of an authenticator will often be able to masquerade as the authenticator’s owner. Threats to authenticators can be categorized based on attacks on the types of authentication factors that comprise the authenticator:

• Something you know may be disclosed to an attacker. The attacker might guess a memorized secret. Where the authenticator is a shared secret, the attacker could gain access to the CSP or verifier and obtain the secret value or perform a dictionary attack on a hash of that value. An attacker may observe the entry of a PIN or passcode, find a written record or journal entry of a PIN or passcode, or may install malicious software (e.g., a keyboard logger) to capture the secret. Additionally, an attacker may determine the secret through offline attacks on a password database maintained by the verifier.

• Something you have may be lost, damaged, stolen from the owner, or cloned by an attacker. For example, an attacker who gains access to the owner’s computer might copy a software authenticator. A hardware authenticator might be stolen, tampered with, or duplicated. Out-of-band secrets may be intercepted by an attacker and used to authenticate their own session.

• Something you are may be replicated. For example, an attacker may obtain a copy of the subscriber’s fingerprint and construct a replica.

This document assumes that the subscriber is not colluding with an attacker who is attempting to falsely authenticate to the verifier. With this assumption in mind, the threats to the authenticators used for digital authentication are listed in Table 3, along with some examples.

Table 3 Authenticator Threats

Threat Mitigation Strategies

Related mechanisms that assist in mitigating the threats identified above are summarized in Table 4.

Table 4 Mitigating Authenticator Threats

Several other strategies may be applied to mitigate the threats described in Table 3:

• Multiple factors make successful attacks more difficult to accomplish. If an attacker needs to both steal a cryptographic authenticator and guess a memorized secret, then the work to discover both factors may be too high.

• Physical security mechanisms may be employed to protect a stolen authenticator from duplication. Physical security mechanisms can provide tamper evidence, detection, and response.

• Requiring the use of long memorized secrets that don’t appear in common dictionaries may force attackers to try every possible value.

• System and network security controls may be employed to prevent an attacker from gaining access to a system or installing malicious software.

• Periodic training may be performed to ensure subscribers understand when and how to report compromise — or suspicion of compromise — or otherwise recognize patterns of behavior that may signify an attacker attempting to compromise the authentication process.

• Out of band techniques may be employed to verify proof of possession of registered devices (e.g., cell phones).

Authenticator Recovery

The weak point in many authentication mechanisms is the process followed when a subscriber loses control of one or more authenticators and needs to replace them. In many cases, the options remaining available to authenticate the subscriber are limited, and economic concerns (e.g., cost of maintaining call centers) motivate the use of inexpensive, and often less secure, backup authentication methods. To the extent that authenticator recovery is human-assisted, there is also the risk of social engineering attacks.

To maintain the integrity of the authentication factors, it is essential that it not be possible to leverage an authentication involving one factor to obtain an authenticator of a different factor. For example, a memorized secret must not be usable to obtain a new list of look-up secrets.

Session Attacks

The above discussion focuses on threats to the authentication event itself, but hijacking attacks on the session following an authentication event can have similar security impacts. The session management guidelines in Sec. 7 are essential to maintain session integrity against attacks, such as XSS. In addition, it is important to sanitize all information to be displayed [OWASP-XSS-prevention] to ensure that it does not contain executable content. These guidelines also recommend that session secrets be made inaccessible to mobile code in order to provide extra protection against exfiltration of session secrets.

Another post-authentication threat, cross-site request forgery (CSRF), takes advantage of users’ tendency to have multiple sessions active at the same time. It is important to embed and verify a session identifier into web requests to prevent the ability for a valid URL or request to be unintentionally or maliciously activated.

Privacy Considerations

これらのプライバシー考慮事項は Sec. 4 のガイダンスを補足する. This section is informative.

Privacy Risk Assessment

Sections 4.1.5, 4.2.5, 4.3.5 は, CSP が記録保持のためのプライバシーリスク評価を実施することを要求する. このようなプライバシーリスク評価には, 以下を含む:

1. 記録の保持によって, Subscriber に情報への侵入や未承認のアクセスなどの問題が起こる可能性.
2. そのような問題が発生した場合の影響.

CSP は, リスクの受け入れ, リスクの軽減, リスクの共有を含む識別されたプライバシーリスクに対して行うあらゆる対応を合理的に正当化できる必要がある. Subscriber の同意の使用は, リスクを共有する形式であるため, Subscriber が共有されたリスクを評価して受け入れる能力を持っていると合理的に期待できる場合にのみ使用するのが適切である.

Privacy Controls

Section 4.4 は, CSP が適切に調整されたプライバシーコントロールを採用することを要求する. [SP800-53] は, CSP が Authentication メカニズムを展開する際に考慮すべき一連のプライバシーコントロールを提供する. これらのコントロールは, 効果的で信頼に値する展開のための通知, 是正, およびその他の重要な考慮事項をカバーする.

Use Limitation

Section 4.4 は, CSP に対して, Identity Proofing, Authentication, Authorization, または Attribute Assertion, 関連する不正の軽減, または法律と法的手続きの遵守以外の目的でのAttribute の処理から生じる可能性のあるプライバシーリスクに見合った Predictability (個人, 所有者, オペレーターによる, PII と情報システムによる Processing について信頼できるという仮定を可能にする) および Manageability (情報システムによる 変更, 削除, 選択的開示を含む PII の詳細な管理の提供) の目的を維持するための手段を使用することを要求する [NISTIR8062].

CSP は, Subscriber に Non-Identity Services を提供することを含む, Attribute を処理するためのさまざまなビジネス目的を持つ場合がある. しかし, 収集時に指定された以外の目的で Attribute を処理することは, 個人が追加の処理を期待していない, または快適でない場合, プライバシーリスクを作り出す可能性がある. CSP は, 追加の処理から生じるプライバシーリスクに見合った適切な手段を決定できる. たとえば, 適用される法律, 規制, ポリシーがなければ, Subscriber からリクエストされた Non-Identity Services を提供するために Attribute を処理する際に同意を得る必要はないかもしれないが, 通知は Subscriber が処理に関する信頼できる仮定を維持するのに役立つ場合がある(Predictability). Attribute のその他の処理には, 同意を取得する必要がある, または Subscriber が特定の Attribute の使用や開示をより詳細に制御できるようにする必要がある, さまざまなプライバシーリスクを運び込む可能性がある(Manageability). Subscriber の同意は意味のあるものである必要がある. したがって, Sec. 4.4 で述べられた通り, CSP が同意を手段として使用する場合, Subscriber が追加の使用を受け入れることが Authentication Service を提供する条件になることはない.

目的とする処理が許可された処理または適切なプライバシーリスク軽減手段の範囲外となるかどうかについて質問がある場合は, 政府機関の SAOP と相談する.

Agency-Specific Privacy Compliance

Section 4.4 は, 連邦の CSP の特定のコンプライアンス義務をカバーする. プライバシーリスクを評価して軽減し, Authenticator を発行・維持するための PII の収集が PIA を実施する Privacy Act of 1974 [PrivacyAct] または the E-Government Act of 2002 [E-Gov] の要件をトリガーするかどうかといったコンプライアンス要件を政府機関にアドバイスするために, Digital Authentication System 開発の一番早いステージで政府機関の SAOP を巻き込むことが非常に重要である. 例えば, Biometrics の集中管理に関しては, ほとんどの場合で Privacy Act requirements がトリガーされ, PII および Authentication に必要なその他の Attribute の収集と管理のために, 新規または既存の Privacy Act システムの記録によるカバーが要求される. 同様に, SAOP は政府機関が PIA が必要かどうかを判断することを支援できる.

これらの考慮事項は, Authentication だけのために Privacy Act SORN や PIA を開発するための要件として読まれないほうがよい. 多くの場合, Digital Identity Process 全体を網羅する PIA や SORN の草案を作成するか, 政府機関が確立しようとしているオンラインサービスやベネフィットについて議論する, より大きなプログラムによる PIA の一部として, Digital Identity Process を含めることが最も理にかなっている.

Digital Authentication には多くのコンポーネントがあるため, SAOP が個々のコンポーネントを認識し理解することが重要である. 例えば, 他の Privacy Artifact は, 連携された CSP や RP サービス (例: データ使用契約, コンピュータマッチング契約) を提供または使用する政府機関に適用される場合がある. SAOP は, 何の追加要件が適用されるかを政府機関が判断することを支援できる. さらに, Digital Authentication の個々のコンポーネントを十分に理解することは, SAOP が, コンプライアンスプロセスやその他の方法を通じて, プライバシーリスクを十分に評価, 軽減することを可能にする.

Privacy Considerations

These privacy considerations supplement the guidance in Sec. 4. This section is informative.

Privacy Risk Assessment

Sections 4.1.5, 4.2.5, and 4.3.5 require the CSP to conduct a privacy risk assessment for records retention. Such a privacy risk assessment would include:

1. The likelihood that the records retention could create a problem for the subscriber, such as invasiveness or unauthorized access to the information.
2. The impact if such a problem did occur.

CSPs should be able to reasonably justify any response they take to identified privacy risks, including accepting the risk, mitigating the risk, and sharing the risk. The use of subscriber consent is a form of sharing the risk, and therefore appropriate for use only when a subscriber could reasonably be expected to have the capacity to assess and accept the shared risk.

Privacy Controls

Section 4.4 requires CSPs to employ appropriately tailored privacy controls. [SP800-53] provides a set of privacy controls for CSPs to consider when deploying authentication mechanisms. These controls cover notices, redress, and other important considerations for successful and trustworthy deployments.

Use Limitation

Section 4.4 requires CSPs to use measures to maintain the objectives of predictability (enabling reliable assumptions by individuals, owners, and operators about PII and its processing by an information system) and manageability (providing the capability for granular administration of PII, including alteration, deletion, and selective disclosure) commensurate with privacy risks that can arise from the processing of attributes for purposes other than identity proofing, authentication, authorization, or attribute assertion, related fraud mitigation, or to comply with law or legal process [NISTIR8062].

CSPs may have various business purposes for processing attributes, including providing non-identity services to subscribers. However, processing attributes for other purposes than those specified at collection can create privacy risks when individuals are not expecting or comfortable with the additional processing. CSPs can determine appropriate measures commensurate with the privacy risk arising from the additional processing. For example, absent applicable law, regulation or policy, it may not be necessary to get consent when processing attributes to provide non-identity services requested by subscribers, although notices may help subscribers maintain reliable assumptions about the processing (predictability). Other processing of attributes may carry different privacy risks that call for obtaining consent or allowing subscribers more control over the use or disclosure of specific attributes (manageability). Subscriber consent needs to be meaningful; therefore, as stated in Sec. 4.4, when CSPs use consent measures, acceptance by the subscriber of additional uses shall not be a condition of providing authentication services.

Consult the agency SAOP if there are questions about whether the proposed processing falls outside the scope of the permitted processing or the appropriate privacy risk mitigation measures.

Agency-Specific Privacy Compliance

Section 4.4 covers specific compliance obligations for federal CSPs. It is critical to involve the agency SAOP in the earliest stages of digital authentication system development in order to assess and mitigate privacy risks and advise the agency on compliance requirements, such as whether or not the collection of PII to issue or maintain authenticators triggers the Privacy Act of 1974 [PrivacyAct] or the E-Government Act of 2002 [E-Gov] requirement to conduct a PIA. For example, with respect to centralized maintenance of biometrics, it is likely that the Privacy Act requirements will be triggered and require coverage by either a new or existing Privacy Act system of records due to the collection and maintenance of PII and any other attributes necessary for authentication. The SAOP can similarly assist the agency in determining whether a PIA is required.

These considerations should not be read as a requirement to develop a Privacy Act SORN or PIA for authentication alone. In many cases it will make the most sense to draft a PIA and SORN that encompasses the entire digital identity process or include the digital authentication process as part of a larger programmatic PIA that discusses the online service or benefit that the agency is establishing.

Due to the many components of digital authentication, it is important for the SAOP to have an awareness and understanding of each individual component. For example, other privacy artifacts may be applicable to an agency offering or using federated CSP or RP services (e.g., Data Use Agreements, Computer Matching Agreements). The SAOP can assist the agency in determining what additional requirements apply. Moreover, a thorough understanding of the individual components of digital authentication will enable the SAOP to thoroughly assess and mitigate privacy risks either through compliance processes or by other means.

Usability Considerations

This section is informative.

本セクションでは, ユーザー という用語は Claimant ないし Subscriber を意味する.

[ISO/IEC9241-11] は Usability を “特定の利用コンテキストにおいて, 特定のユーザーが, あるシステム, プロダクトないしはサービスを利用して, 特定の目標を, どの程度有効的, 効率的かつ満足のいくレベルで達成できるかの度合い” と定義している. この定義はユーザー, 目標および利用コンテキストを, 有効性, 効率性および満足度の達成に必要な重要要素として捉えている. Usability を実現するには, これらの重要要素を考慮した総合的なアプローチが必要となる.

ユーザーが情報システムに Access する際の目標とは, 彼らが意図した何らかのタスクの実行にある. Authentication とは, その目的を可能とする機能である. しかしながらユーザー視点で見ると, Authentication は彼らと彼らの意図したタスクの間に存在するものである. Authentication の効果的な設計および実装は, 正しいことの実行を容易にし, 誤ったことの実行を困難にし, 間違いが起こった場合のリカバリーを容易にする.

組織は, ステークホルダーの Digital Authentication エコシステムへの全体的な影響を認識する必要がある. ユーザーはしばしば複数の Authenticator をそれぞれ異なる RP に対して利用しており, パスワードを覚えるために苦闘し, どの Authenticator がどの RP 向けであったか思い出すために苦闘し, 複数の物理的な Authentication デバイスを持ち運ぶために苦闘している. Authentication の Usability を評価することは不可欠であり, Usability が低いと最終的にセキュリティコントロールの有効性を損ねかねない対処策や意図しない回避策が生じることもしばしばである.

Usability を開発プロセスに組み込むことで, ユーザーの Authentication へのニーズと組織のビジネス目標に対応しながら, 安全で使いやすい Authentication ソリューションを実現できる.

適切な AAL の決定の際は, リスク評価の一環として Digital システム全体の Usability を考慮する必要がある. より高い AAL の Authenticator のほうが Usability が良い場合もあり, より低い AAL の Authentication においてもそういった Authenticator の利用を許可すべき場合がある.

[SP800-63C] で述べるように, そのアプローチ自体にもトレードオプが存在するものの, Authentication のために Federation を活用すると多くの Usability の問題を軽減できる可能性もある.

本セクションでは一般的な Usability 上の考慮事項と取りうる実装について述べるが, 特定のソリューションを推奨するものではない. ここで言及する実装は, 特定の Usability ニーズに対応するための革新的技術アプローチを促すための例に過ぎない. さらに, Usability 上の考慮事項とこれらの実装は, 1つで全てを解決する万能なソリューションを妨げるような, 多くの要因を含みがちである. 例えば, デスクトップコンピューター環境においては適切なフォントサイズでも, 小さな OTP デバイスのスクリーンで見た際は文字がはみ出してしまうかもしれない. 選択された Authenticator に対する Usability 評価の実施は, 実装上の不可欠な要素である. 評価を行う際は, 代表的なユーザー, 現実的な目標とタスク, 適切な利用コンテキストのもとで行うことが重要である.

ガイドラインと考慮事項はユーザー目線で記述されている.

Usability とは異なり, アクセシビリティに関しては本ドキュメントのスコープ外とする. [Section508] は情報技術の障壁を取り除くために制定され, 連邦政府機関に対して電子および情報技術の公開コンテンツを障害を持つ人にもアクセスできるように要求している. アクセシビリティガイドラインに関しては Section 508 の法律および標準を参照のこと.

Usability Considerations Common to Authenticators

Authentication システムの選択および実装の際は, 選択した Authenticator のライフサイクル全体 (e.g., 通常の使用や断続的イベント) における Usability を考慮すること. またその際は, ユーザー, ユーザーの目標および利用コンテキストの組み合わせに注意すること.

通常, 単一の Authenticator Type ではユーザー母集団全体の要求を満たすには不十分である. 従って可能であれば - AAL 要件に基づき - CSP は代替の Authenticator Type をサポートすべきであり, それらをユーザーのニーズに合わせて選択させるべきである. タスクの緊急度, 認識される費用対効果のトレードオフ, 特定の Authenticator への習熟度などが, しばしば選択に影響を及ぼすことになる. ユーザーは, その時点で最も負担やコストの低い選択肢を選ぶ傾向がある. 例えば, タスクが情報システムへの即時 Access を必要とする場合, ユーザーはより多くのステップを必要とする Authenticator を選択するよりも, 新しい Subscriber Account と Password を作成することを選好する可能性もある. 代わりに, Identity Provider に Subscriber Account を持っている場合, ユーザーは - 適切な AAL で Approve された - Federated Identity という選択肢を選ぶ可能性もある. ユーザーはある Authenticator を他の Authenticator よりもよく理解しており, 理解と経験に基づいて異なるレベルの信頼感を持っている可能性もある.

ユーザーによるポジティブな Authentication エクスペリエンスは, 望ましいビジネス上の成果を達成する組織の成功に不可欠である. 従って, 組織はユーザーの視点に立って Autheenticator を検討するよう努力すべきである. Authentication Usability における非常に重要な目標として, ユーザーの負担と Authentication により生じる摩擦 (e.g., ユーザーが Authenticate しなければならない回数, それにかかるステップ数, 確認しなければならない情報量) の最小化が挙げられる. Single Sign-on はそのような最小化戦略の一例である.

以下に, 大抵の Authenticator に適用可能な Usability 上の考慮事項を示す. また, 後続のセクションは, 特定の Authenticator に特化した Usability 上の考慮時を鵜を説明するものである.

すべての Authenticator の通常利用 (Typical Usage) における Usability 上の考慮事項として, 以下のようなものが挙げられる.

• Authenticator の利用および保守に関する情報を提供する. e.g., Authenticator を紛失したり盗難にあった場合の対処方法, および使用手順 - 特に初回利用時または初期化時に異なる要件がある場合

• ユーザーは自身の Authenticator をすぐ利用できるようにしておく必要があるため, Authenticator の Availability (可用性) も考慮すべきである. 紛失, 損傷, その他のオリジナルの Authenticator への悪影響から保護するため, 代替となる Authentication の選択肢の必要性も検討すること.

• 可能な限り, AAL 要件に基づき, ユーザーに代替の Authentication の選択肢を提供するべきである. これによりユーザーは自身のコンテキスト, 目標, タスク (e.g., タスクの頻度や緊急度) に基づき Authenticator を選択することができるようになる. 代替の Authentication の選択肢は, 特定の Authenticator で発生する可能性のある Availablility (可用性) の問題に対処する際にも役に立つ.

• ユーザーに表示するテキストの特徴
  • ユーザーに表示するテキスト (e.g., 手順書, プロンプト, 通知, エラーメッセージ) は, 対象読者向けに平易な言葉で記述すること. 専門用語を避け, 読者に想定されるリテラシーレベルに合わせた記述にすること.
  • ユーザーに表示するテキストとユーザーが入力するテキストの読みやすさを考慮すること. これにはフォントスタイル, サイズ, 色, 周囲の背景とのコントラストなどを含む. 読みにくいテキストは, ユーザーの入力エラーの元となる. 読みやすさを向上させるため, 以下の採用を検討すること.
    • ハイコントラスト. 最大のハイコントラストは白地に黒である.
    • 電子的表示用には Sans Serif フォント. 印刷物用には Serif フォント.
    • 混同しやすい文字 (e.g., 大文字の “O” と数字の “0”) を明確に区別できるフォント.
    • テキストがデバイスのディスプレイでの表示に治る限り, 最小フォントサイズは12ポイント.

• Authenticator 入力中のユーザーエクスペリエンス
  • マスクされたテキスト入力はエラーを引き起こしやすいため, 入力中にテキストを表示するオプションを提供すること. 入力文字をユーザーが視認するのに十分長い間表示した後は, 非表示にしてもよい. 従来のデスクトップコンピューターよりモバイルデバイス (e.g., タブレットやスマートフォン) のほうが Memorized Secret の入力に時間がかかるので, マスキング遅延時間を決定する際はデバイスを考慮すること. マスキング遅延時間がユーザーのニーズに合致していることを保証すること.
  • テキスト入力に十分な時間が与えられている (i.e., 入力画面が途中でタイムアウトにならない) ことを保証すること. 許可されたテキスト入力時間がユーザーのニーズに合致していることを保証すること.
  • ユーザーの混乱とフラストレーションを軽減するため, 入力エラーについての明確で意味のある対応可能なフィードバックを提供すること. ユーザーがテキスト誤入力に気づかないと, Usability に重大な影響を及ぼす.
  • ユーザーに Authenticator Output を入力させるような Authenticator に関しては, 少なくとも10回の入力試行を許可すること. 入力テキストが長く複雑になればなるほど, ユーザーの入力エラー率も高くなる.
  • 許可された残りの試行回数について, 明確で意味のあるフィードバックを提供すること. レート制限 (i.g., スロットリング) については, 混乱とフラストレーションを軽減するため, 次に試行までどれくらい待つ必要があるのかをユーザーに知らせること.

• モバイルデバイスのタッチおよびディスプレイ領域の制限など, フォームファクターの制約による影響を最小化すること.
  • 小さなデバイス上でのタイピングはフルサイズキーボードでのタイピングと比べてはるかにエラー率が高く時間もかかるため, より大きなタッチ領域はテキスト入力の Usability を向上させる. スクリーン上のキーボードが小さいほど, 入力メカニズム (e.g., 指) のサイズとスクリーン上の対象物のサイズとの兼ね合いで, より入力が困難になる.
  • 小さなディスプレイ向けの優れたユーザーインタフェースおよび情報デザインに従うこと.

断続的イベント (Intermittent Events) には, Reauthentication, Subscriber Account のロックアウト, 期限切れ, 失効, 損傷, 紛失, 盗難, 機能しないソフトウェアといったイベントが含まれる.

すべての Authenticator Type における断続的イベントに関する Usability 上の考慮事項には以下のようなものが挙げられる.

• ユーザーが非アクティブであることが原因でユーザーが Reauthentication する必要がないように, 非アクティブタイムアウトが発生する直前 (e.g., 2分前) にアクティビティをトリガーするようユーザーに促すこと.

• ユーザーのアクティビティに関係なく固定の定期的な Reauthentication イベントが必要な場合, その前に十分な時間 (e.g., 1時間) を設けてユーザーに作業を保存するよう促すこと.

• 技術支援を受ける方法と場所を明確に伝えること. 例えば, オンラインのセルフサービス機能へのリンク, チャット Session, ヘルプデスクサポート用の電話番号などの情報をユーザーに提供すること. 理想的には, ユーザーが外部の介入なしに自身で断続的イベントからリカバリーできるよう十分な情報を提供されることが望ましい.

Usability Considerations by Authenticator Type

前述の大抵の Authenticator に適用可能な一般的な Usability 上の考慮事項 ((Sec. 10.1)) に加え, 以下のセクションでは特定の Authenticator Type 固有の Usability 上の考慮事項について述べる.

Memorized Secrets

Typical Usage (通常利用)

ユーザーは手動で Memorized Secret (一般的には Password や PIN と呼ばれる) を入力する.

通常利用における Usability 上の考慮事項としては以下のようなものが挙げられる.

• Memorized Secret の記憶可能性
  • ユーザーが覚える項目が多いほど, 思い出せずに失敗する可能性が高くなる. Memorized Secret が少なければ少ないほど, ユーザーは特定の RP のために必要な特定の Memorized Secret をより簡単に思い出すことができる.

• Memorized Secret 入力中のユーザーエクスペリエンス
  • Passphrase を含む Memorized Secret 入力フィールドにおいてコピーアンドペースト機能をサポートすること.

Intermittent Events (断続的イベント)

断続的イベントにおける Usability 上の考慮事項としては以下のようなものが挙げられる.

• ユーザーが Memorized Secret を生成・変更する際
  • Memorized Secret の生成・変更方法に関する情報を明確に伝えること.
  • Memorized Secret の要件 (Sec. 5.1.1 参照) を明確に伝えること.
  • Passphrase には最低でも64文字を許容すること. 記憶しやすいようユーザーが選好する文字 (スペースを含む) を使用して, 好きなだけ長い Memorized Secret を作成することを推奨すること.
  • Memorized Secret に他の構成ルール (e.g., 異なる文字種の混合) を課さないこと.
  • ユーザーの要求や Authenticator 侵害の証拠がない限り, Memorized Secret の変更を恣意的 (e.g., 定期的) に要求しないこと. (追加情報に関しては Sec. 5.1.1 参照)

• 選択した Password を拒否する場合 (e.g., 受け入れられない Password の “Blocklist” に含まれる場合や, 以前に使用されているものと同じである場合) は, 明確で意味のある対応可能なフィードバックを提供すること.

Look-Up Secrets

Typical Usage (通常利用)

ユーザーは - 印刷物または電子的な - Authenticator を使用して, Verifier のプロンプトに応答するために必要とされる適切なシークレットを見つけ出す. 例えば, ユーザーはカードに表形式で印刷された数値または文字列の特定のサブセットを提供するよう求められる場合がある.

通常利用における Usability 上の考慮事項としては以下のようなものが挙げられる.

• Look-up Secret 入力中のユーザーエクスペリエンス
  • プロンプトの複雑さとサイズを考慮すること. ユーザーが検索するよう求められるシークレットのサブセットが大きいほど, Usability への影響も大きくなる. Authentication のための Look-up Secret の量と複雑さを決定する際には, 認知作業負荷と入力の物理的な困難さの両方を考慮するべきである.

Out-of-Band

Typical Usage (通常利用)

Out-of-band Authentication では, ユーザーはプライマリおよびセカンダリなコミュニケーションチャネルへの Access を必要とする.

通常利用における Usability 上の考慮事項としては以下のようなものが挙げられる.

• ロックされているデバイスにシークレットを送信したことをユーザーに伝えること. ただし, Out-of-band Device がロックされている場合, シークレットに Access するためにデバイスへの Authenttication が要求されるべきである.

• 実装によっては, ユーザーがモバイルデバイス上でテキスト入力を行う必要がある場合に特に問題となるため, フォームファクターの制約を考慮すること. より大きなタッチ領域を提供することで, モバイルデバイス上でのシークレット入力の Usability を向上することができる.

• さらに良い Usability のオプションは, モバイルデバイス上でテキスト入力を必要としない機能 (e.g., スクリーンを一回タップするだけだったり, Out-of-band シークレットをコピーアンドペーストできるようにコピー可能にするなど) を提供することである. このような機能を提供すると, プライマリチャネルとセカンダリチャネルが同一デバイス上にある場合, 特に役に立つ. 例えば, スマートフォン上で - 場合によっては複数回 - Out-of-band アプリケーションとプライマリチャネルの間を行ったり来たりして Authentication Secret を移動させるのは困難である.

Single-Factor OTP Device

Typical Usage (通常利用)

ユーザーは Single-factor OTP Device で生成された OTP に Access する. Authenticator Output は通常デバイス上に表示され, ユーザーがそれを Verifier に入力する.

通常利用における Usability 上の考慮事項としては以下のようなものが挙げられる.

• Authenticator Output は切り替わるまでに少なくとも1分間の猶予があるが, 理想的には Sec. 5.1.4.1 にあるようにユーザーにフルで2分間の猶予を与えることが望ましい. ユーザーは Authenticator Output の入力 (Single-factor OTP Device と入力画面の間の行き来を含む) に十分な時間を必要とする.

• 実装によっては, 実装者向けの以下のような追加の Usability 上の考慮事項が挙げられる.
  • Single-factor OTP Device が電子的インタフェース (e.g., USB) を介して出力を提供できると, ユーザーは Authenticator Output を手動で入力する必要がないため, そのような実装が望ましい. しかしながら, 操作に物理的な入力 (e.g., ボタンを押す) が必要な場合, USB ポートの位置によっては Usability 上の問題をひきおこす可能性がある. 例えば, 一部のコンピューターの USB ポートはコンピューターの背面にあり, ユーザーがアクセスしにくい場合がある.
  • USB ポートなどの直接的コンピューターインタフェースの Availability (可用性) に関する制約が Usability 上の問題を引き起こす可能性もある. 例えば, ラップトップコンピューターの USB ポート数はしばしば非常に限られている. これによりユーザーは Single-factor OTP Device を使用するために他の USB 周辺機器を取り外す必要があるかもしれない.

Multi-Factor OTP Device

Typical Usage (通常利用)

ユーザーは Multi-factor OTP Device で生成された OTP に Access する. OTP は通常デバイス上に表示され, ユーザーがそれを Verifier に入力する. 2nd Authentication Factor は, Memorized Secret を入力するためのある種の一体型入力パッド, 一体型 Biometric (e.g., 指紋) リーダー, または直接的なコンピューターインタフェース (e.g., USB ポート) を介してもたらされる可能性がある. ここでは追加の Authentication Factor に対する Usability 上の考慮事項も適用される - Multi-factor Authenticator 内で用いられる Memorized Secret に対しては Sec. 10.2.1, Biometrics に対しては Sec. 10.4 を参照.

通常利用における Usability 上の考慮事項としては以下のようなものが挙げられる.

• Authenticator Output の手入力中のユーザーエクスペリエンス
  • Time-based OTP の場合, OTP が表示されている時間にプラスして猶予時間を設けること. Multi-factor OTP Device と入力画面の間を行き来することを含め, ユーザーは Authenticator Output の入力に十分な時間を要する.
  • ユーザーが, 一体型入力パッドを介して Multi-factor OTP Device のロックを解除したり, Authenticator Output をモバイルデバイスに入力する必要がある場合, フォームファクターの制約を考慮すること. 小型デバイスでの入力は, 従来のキーボードでの入力よりも大幅にエラーが発生しやすく, 時間がかかるものである. 一体型入力パッドとオンスクリーンキーボードが小さければ小さいほど入力は難しくなる. より大きなタッチ領域を提供することで, Multi-factor OTP Device のロックを解除したり, モバイルデバイスに Authenticator Output を入力する際の Usability が向上する.
  • USB ポートなどの直接的コンピューターインタフェースの Availability (可用性) に関する制約が Usability 上の問題を引き起こす可能性もある. 例えば, ラップトップコンピューターの USB ポート数はしばしば非常に限られている. これによりユーザーは Multi-factor OTP Device を使用するために他の USB 周辺機器を取り外す必要があるかもしれない.

Single-Factor Cryptographic Software

Typical Usage (通常利用)

ユーザーは Cryptographic Software Key を保持および管理していることを証明することにより Authenticate を行う.

通常利用における Usability 上の考慮事項としては以下のようなものが挙げられる.

• ユーザーはどの Authentication タスクにどの Cryptographic Key を使用するかを認識し思い出す必要があるため, Cryptographic Key には適切でわかりやすい名前をつけること. これによりユーザーは似たような曖昧な名前の複数の Cryptographic Key を扱う必要がなくなる. 小型のモバイルデバイスで複数の Cryptographic Key から選択する場合, 画面サイズが小さくなったために Cryptographic Key の名前が短縮されていると, 特に問題になる可能性がある.

Single-Factor Cryptographic Device

Typical Usage (通常利用)

ユーザーは Single-Factor Cryptographic Device を保持していることを証明することにより Authenticate を行う.

通常利用における Usability 上の考慮事項としては以下のようなものが挙げられる.

• Single-Factor Cryptographic Device を操作するために物理的な入力 (e.g., ボタンを押す) を必要とすると, Usability 上の問題を引き起こす可能性がある. 例えば, 一部の USB ポートはコンピューターの背面に配置されているため, ユーザーの手に届きにくい場所にある.

• USB ポートなどの直接的コンピューターインタフェースの Availability (可用性) に関する制約が Usability 上の問題を引き起こす可能性もある. 例えば, ラップトップコンピューターの USB ポート数はしばしば非常に限られている. これによりユーザーは Single-Factor Cryptographic Device を使用するために他の USB 周辺機器を取り外す必要があるかもしれない.

Multi-Factor Cryptographic Software

Typical Usage (通常利用)

Authenticate するため, ユーザーは Activation が必要なディスクまたはその他の “ソフト” メディアに保存されている Cryptographic Key の保持および管理を証明する. Activation は 2nd Authenticator Factor, Memorized Secret または Biometrics の特徴のいずれか, の入力により行われる. ここでは追加の Authentication Factor に対する Usability 上の考慮事項も適用される - Multi-factor Authenticator 内で用いられる Memorized Secret に対しては Sec. 10.2.1, Biometrics に対しては Sec. 10.4 を参照.

通常利用における Usability 上の考慮事項としては以下のようなものが挙げられる.

• ユーザーはどの Authentication タスクにどの Cryptographic Key を使用するかを認識し思い出す必要があるため, Cryptographic Key には適切でわかりやすい名前をつけること. これによりユーザーは似たような曖昧な名前の複数の Cryptographic Key を扱う必要がなくなる. 小型のモバイルデバイスで複数の Cryptographic Key から選択する場合, 画面サイズが小さくなったために Cryptographic Key の名前が短縮されていると, 特に問題になる可能性がある.

Multi-Factor Cryptographic Device

Typical Usage (通常利用)

ユーザーは Multi-Factor Cryptographic Device を保持していること, および保護されている Cryptographic Key を管理していることを証明することにより Authenticate を行う. Activation は 2nd Authenticator Factor, Memorized Secret または Biometrics の特徴のいずれか, の入力により行われる. ここでは追加の Authentication Factor に対する Usability 上の考慮事項も適用される - Multi-factor Authenticator 内で用いられる Memorized Secret に対しては Sec. 10.2.1, Biometrics に対しては Sec. 10.4 を参照.

通常利用における Usability 上の考慮事項としては以下のようなものが挙げられる.

• Authentication 後に Multi-factor Cryptographic Key を接続したままにしておくことを要求しないこと. ユーザーは Multi-factor Cryptographic Key を使い終わった後も取り外すのを忘れる (e.g., スマートカードリーダーにスマートカードを入れ忘れたままコンピューターから離れてしまう) 可能性がある.
  • 接続を維持するために Multi-factor Cryptographic Device が必要かどうか, ユーザーに通知する必要がある.

• ユーザーはどの Authentication タスクにどの Cryptographic Key を使用するかを認識し思い出す必要があるため, Cryptographic Key には適切でわかりやすい名前をつけること. これによりユーザーは似たような曖昧な名前の複数の Cryptographic Key を扱う必要がなくなる. 小型のモバイルデバイス (スマートフォンなど) で複数の Cryptographic Key から選択する場合, 画面サイズが小さくなったために Cryptographic Key の名前が短縮されていると, 特に問題になる可能性がある.

• USB ポートなどの直接的コンピューターインタフェースの Availability (可用性) に関する制約が Usability 上の問題を引き起こす可能性もある. 例えば, ラップトップコンピューターの USB ポート数はしばしば非常に限られている. これによりユーザーは Multi-Factor Cryptographic Device を使用するために他の USB 周辺機器を取り外す必要があるかもしれない.

Summary of Usability Considerations

Figure 3 は各 Authenticator Type 毎に通常利用 (Typical Usage) および断続的イベント (Intermittent Events) における Usability 上の考慮事項をまとめたものである. 表を見ても分かる通り, 通常利用における Usability 上の考慮事項の多くが, ほとんどの Authenticator Type に当てはまる. この表は Authenticator Type 全体にわたって共通するさまざまな Usability の特徴を示している. 各カラムにより, 読者は各 Authenticator に対応するための Usability Attribute を簡単に識別することができる. ユーザーの目標と利用コンテキストに応じて, 特定の Attribute が他の Attribute より高く評価される場合もある. 可能な限り代替の Authenticator Type を提供し, ユーザーがそれらの中から選択できるようにすることが望ましい.

Multi-factor Authenticator (e.g., Multi-factor OTP Device, Multi-factor Cryptographic Software, Multi-factor Cryptographic Device) は, さらにセカンダリーファクターに関する Usability 上の考慮事項も受け継いでいる. Biometrics は Multi-factor Authentication ソリューションの Activation Factor としてのみ許容されているため, Biometirics に関する Usability 上の考慮事項は Figure 3 には含まれず, Sec. 10.4 で述べられている.

Figure 3 Usability Considerations Summary by Authenticator Type

\clearpage

Biometrics Usability Considerations

本セクションでは, Biometrics の一般的な Usability 上の考慮点について概説する. Biometrics の Usability に関するより詳細な議論は Usability & Biometrics, Ensuring Successful Biometric Systems [UsabilityBiometrics] を参照のこと.

Biometrics の様式は多様であるが, 以下で述べる3つの Biometrics 様式, 指紋, 顔, 虹彩は, その中でもより一般的に Authentication に用いられる.

Typical Usage (通常利用)

• 全ての様式について, ユーザーがデバイスに慣れて実践することで, そのパフォーマンスは向上する.

• デバイスのアフォーダンス (i.e., ユーザーがアクションを実行できるようにするデバイスのプロパティ), フィードバックおよび明確な手順書は, ユーザーが Biometrics デバイスを使用して成功体験を得るのに不可欠である. 例えば, Liveness Detection に必要なアクションに関する明確な手順書を提供すること.

• 理想的には, ユーザーが 2nd Authentication Factor として最も使いやすい様式を選択できることが望ましい. ユーザー母集団はある Biometrics 様式に他より慣れ親しんで - かつ受け入れて - いる可能性がある.

• Activation Factor としての Biometrics のユーザーエクスペリエンス
  • 許可された残りの試行回数について, 明確で意味のあるフィードバックを提供すること. レート制限 (i.g., スロットリング) については, 混乱とフラストレーションを軽減するため, 次に試行までどれくらい待つ必要があるのかをユーザーに知らせること.

• 指紋認証に関する Usability 上の考慮事項
  • ユーザーは Enrollment 時にどの指を登録したか覚えておく必要がある.
  • 指の湿気がセンサーの読取精度に影響する.
  • 指紋読取精度に影響を与えるその他の要因として, 年齢, 性別, 職業 (e.g., 化学薬品を扱ったり手を酷使する仕事についているユーザーは, 指紋が劣化している可能性がある) などが挙げられる.

• 顔認証に関する Usability 上の考慮事項
  • 顔認識精度に影響するため, ユーザーは Enrollment 時に人工物 (e.g., メガネ) を着用していたかどうか覚えておく必要がある.
  • 環境光条件の違いが顔認識精度に影響を及ぼす可能性がある.
  • 表情 (e.g., 笑顔と無表情) は顔認識精度に影響を与える.
  • 顔のポーズ (e.g., 下を向いている, カメラから離れている) は顔認識精度に影響を与える.

• 虹彩認証に関する Usability 上の考慮事項
  • カラーコンタクトを着用すると, 虹彩認識精度に影響を与える可能性がある.
  • 目の手術を受けたユーザーは, 手術後に再度 Enrollment を行う必要があるかもしれない.
  • 環境光条件の違いが, 特に特定の虹彩の色について, 虹彩認識精度に影響を与える可能性がある.

Intermittent Events (断続的イベント)

Biometrics は Multi-factor Authentication における 2nd ファクターとしてのみ許容されている一方, 1つめの Authentication Factor における断続的イベントに関する Usability 上の考慮事項も適用される. Biometrics の利用に関する断続的イベントとしては, 認識精度に影響を与える以下のようなものが挙げられる. ここに挙げるものは例であり全てとは限らない.

• ユーザーが登録した指を傷つけた場合, 指紋認識が不能になる可能性がある. 指紋認証 (Fingerprint Authentication) は指紋を損傷したユーザーにとっては困難であろう.
• ユーザーの顔は時間の経過とともに自然に変化するため, 最初の Enrollment 時点から Authentication のための顔認識時点までに時間が経過していると, 認識精度に影響を与える可能性がある. ユーザーの体重変化もその要因となり得る.
• 目の手術を受けたユーザーは, 手術後に再度 Enrollment を行うまで虹彩認識が不能になるかもしれない.

全ての Biometrics 様式において, 断続的イベントにおける Usability 上の考慮事項として以下が挙げられる.

• 代替の Authentication 手段が利用可能かつ機能している必要がある. Biometrics が機能しない場合, ユーザーが Memorized Secret を代替の 2nd ファクターとして利用できるようにすること.
• 技術支援を提供すること.
  • 技術支援を受ける方法と場所を明確に伝えること. 例えば, オンラインのセルフサービス機能へのリンク, ヘルプデスクサポート用の電話番号などの情報をユーザーに提供すること. 理想的には, ユーザーが外部の介入なしに自身で断続的イベントからリカバリーできるよう十分な情報を提供されることが望ましい.
  • Biometric センサーの感度に影響を与える可能性のある要因 (e.g., センサーの清潔さ) をユーザーに知らせること.

Usability Considerations

This section is informative.

Note: In this section, the term users means claimants or subscribers.

[ISO/IEC9241-11] defines usability as the “extent to which a system, product, or service can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.” This definition focuses on users, their goals, and the context of use as key elements necessary for achieving effectiveness, efficiency, and satisfaction. A holistic approach that accounts for these key elements is necessary to achieve usability.

A user’s goal for accessing an information system is to perform an intended task. Authentication is the function that enables this goal. However, from the user’s perspective, authentication stands between them and their intended task. Effective design and implementation of authentication makes it easy to do the right thing, hard to do the wrong thing, and easy to recover when the wrong thing happens.

Organizations need to be cognizant of the overall implications of their stakeholders’ entire digital authentication ecosystem. Users often employ multiple authenticators, each for a different RP. They then struggle to remember passwords, to recall which authenticator goes with which RP, and to carry multiple physical authentication devices. Evaluating the usability of authentication is critical, as poor usability often results in coping mechanisms and unintended workarounds that can ultimately degrade the effectiveness of security controls.

Integrating usability into the development process can lead to authentication solutions that are secure and usable while still addressing users’ authentication needs and organizations’ business goals.

The impact of usability across digital systems needs to be considered as part of the risk assessment when deciding on the appropriate AAL. Authenticators with a higher AAL sometimes offer better usability and should be allowed for use with lower AAL applications.

Leveraging federation for authentication can alleviate many of the usability issues, though such an approach has its own tradeoffs, as discussed in [SP800-63C].

This section provides general usability considerations and possible implementations, but does not recommend specific solutions. The implementations mentioned are examples to encourage innovative technological approaches to address specific usability needs. Further, usability considerations and their implementations are sensitive to many factors that prevent a one-size-fits-all solution. For example, a font size that works in the desktop computing environment may force text to scroll off of a small OTP device screen. Performing a usability evaluation on the selected authenticator is a critical component of implementation. It is important to conduct evaluations with representative users, realistic goals and tasks, and appropriate contexts of use.

Guidelines and considerations are described from the users’ perspective.

Accessibility differs from usability and is out of scope for this document. Section 508 [Section508] was enacted to eliminate barriers in information technology and require federal government agencies to make their online public content accessible to people with disabilities. Refer to Section 508 law and standards for accessibility guidance.

Usability Considerations Common to Authenticators

When selecting and implementing an authentication system, consider usability across the entire lifecycle of the selected authenticators (e.g., typical use and intermittent events), while being mindful of the combination of users, their goals, and context of use.

A single authenticator type usually does not suffice for the entire user population. Therefore, whenever possible — based on AAL requirements — CSPs should support alternative authenticator types and allow users to choose based on their needs. Task immediacy, perceived cost benefit tradeoffs, and unfamiliarity with certain authenticators often impact choice. Users tend to choose options that incur the least burden or cost at that moment. For example, if a task requires immediate access to an information system, a user may prefer to create a new subscriber account and password rather than select an authenticator requiring more steps. Alternatively, users may choose a federated identity option — approved at the appropriate AAL — if they already have a subscriber account with an identity provider. Users may understand some authenticators better than others, and have different levels of trust based on their understanding and experience.

Positive user authentication experiences are integral to the success of an organization achieving desired business outcomes. Therefore, they should strive to consider authenticators from the users’ perspective. The overarching authentication usability goal is to minimize user burden and authentication friction (e.g., the number of times a user has to authenticate, the steps involved, and the amount of information they have to track). Single sign-on exemplifies one such minimization strategy.

Usability considerations applicable to most authenticators are described below. Subsequent sections describe usability considerations specific to a particular authenticator.

Usability considerations for typical usage of all authenticators include:

• Provide information on the use and maintenance of the authenticator, e.g., what to do if the authenticator is lost or stolen, and instructions for use — especially if there are different requirements for first-time use or initialization.

• Authenticator availability should also be considered as users will need to remember to have their authenticator readily available. Consider the need for alternate authentication options to protect against loss, damage, or other negative impacts to the original authenticator.

• Whenever possible, based on AAL requirements, users should be provided with alternate authentication options. This allows users to choose an authenticator based on their context, goals, and tasks (e.g., the frequency and immediacy of the task). Alternate authentication options also help address availability issues that may occur with a particular authenticator.

• Characteristics of user-facing text:
  • Write user-facing text (e.g., instructions, prompts, notifications, error messages) in plain language for the intended audience. Avoid technical jargon and write for the audience’s expected literacy level.
  • Consider the legibility of user-facing and user-entered text, including font style, size, color, and contrast with surrounding background. Illegible text contributes to user entry errors. To enhance legibility, consider the use of:
    • High contrast. The highest contrast is black on white.
    • Sans serif fonts for electronic displays. Serif fonts for printed materials.
    • Fonts that clearly distinguish between easily confusable characters (e.g., the capital letter “O” and the number “0”).
    • A minimum font size of 12 points as long as the text fits for display on the device.
• User experience during authenticator entry:
  • Offer the option to display text during entry, as masked text entry is error-prone. Once a given character is displayed long enough for the user to see, it can be hidden. Consider the device when determining masking delay time, as it takes longer to enter memorized secrets on mobile devices (e.g., tablets and smartphones) than on traditional desktop computers. Ensure masking delay durations are consistent with user needs.
  • Ensure the time allowed for text entry is adequate (i.e., the entry screen does not time out prematurely). Ensure allowed text entry times are consistent with user needs.
  • Provide clear, meaningful and actionable feedback on entry errors to reduce user confusion and frustration. Significant usability implications arise when users do not know they have entered text incorrectly.
  • Allow at least 10 entry attempts for authenticators requiring the entry of the authenticator output by the user. The longer and more complex the entry text, the greater the likelihood of user entry errors.
  • Provide clear, meaningful feedback on the number of remaining allowed attempts. For rate limiting (i.e., throttling), inform users how long they have to wait until the next attempt to reduce confusion and frustration.
• Minimize the impact of form-factor constraints, such as limited touch and display areas on mobile devices:
  • Larger touch areas improve usability for text entry since typing on small devices is significantly more error prone and time consuming than typing on a full-size keyboard. The smaller the onscreen keyboard, the more difficult it is to type, due to the size of the input mechanism (e.g., a finger) relative to the size of the on-screen target.
  • Follow good user interface and information design for small displays.

Intermittent events include events such as reauthentication, subscriber account lock-out, expiration, revocation, damage, loss, theft, and non-functional software.

Usability considerations for intermittent events across authenticator types include:

• To prevent users from needing to reauthenticate due to user inactivity, prompt users in order to trigger activity just before (e.g., 2 minutes) an inactivity timeout would otherwise occur.

• Prompt users with adequate time (e.g., 1 hour) to save their work before the fixed periodic reauthentication event required regardless of user activity.

• Clearly communicate how and where to acquire technical assistance. For example, provide users with information such as a link to an online self-service feature, chat sessions or a phone number for help desk support. Ideally, sufficient information can be provided to enable users to recover from intermittent events on their own without outside intervention.

Usability Considerations by Authenticator Type

In addition to the previously described general usability considerations applicable to most authenticators (Sec. 10.1), the following sections describe other usability considerations specific to particular authenticator types.

Memorized Secrets

Typical Usage

Users manually input the memorized secret (commonly referred to as a password or PIN).

Usability considerations for typical usage include:

• Memorability of the memorized secret
  • The likelihood of recall failure increases as there are more items for users to remember. With fewer memorized secrets, users can more easily recall the specific memorized secret needed for a particular RP.
  • The memory burden is greater for a less frequently used password.
• User experience during entry of the memorized secret
  • Support copy and paste functionality in fields for entering memorized secrets, including passphrases.

Intermittent Events

Usability considerations for intermittent events include:

• When users create and change memorized secrets:
  • Clearly communicate information on how to create and change memorized secrets.
  • Clearly communicate memorized secret requirements, as specified in Sec. 5.1.1.
  • Allow at least 64 characters in length to support the use of passphrases. Encourage users to make memorized secrets as lengthy as they want, using any characters they like (including spaces), thus aiding memorization.
  • Do not impose other composition rules (e.g. mixtures of different character types) on memorized secrets.
  • Do not require that memorized secrets be changed arbitrarily (e.g., periodically) unless there is a user request or evidence of authenticator compromise. (See Sec. 5.1.1 for additional information).
• Provide clear, meaningful and actionable feedback when chosen passwords are rejected (e.g., when it appears on a “blocklist” of unacceptable passwords or has been used previously).

Look-Up Secrets

Typical Usage

Users use the authenticator — printed or electronic — to look up the appropriate secret(s) needed to respond to a verifier’s prompt. For example, a user may be asked to provide a specific subset of the numeric or character strings printed on a card in table format.

Usability considerations for typical usage include:

• User experience during entry of look-up secrets.
  • Consider the prompts’ complexity and size. The larger the subset of secrets a user is prompted to look up, the greater the usability implications. Both the cognitive workload and physical difficulty for entry should be taken into account when selecting the quantity and complexity of look-up secrets for authentication.

Out-of-Band

Typical Usage

Out-of-band authentication requires users have access to a primary and secondary communication channel.

Usability considerations for typical usage:

• Notify users of the receipt of a secret on a locked device. However, if the out-of-band device is locked, authentication to the device should be required to access the secret.

• Depending on the implementation, consider form-factor constraints as they are particularly problematic when users must enter text on mobile devices. Providing larger touch areas will improve usability for entering secrets on mobile devices.

• A better usability option is to offer features that do not require text entry on mobile devices (e.g., a single tap on the screen, or a copy feature so users can copy and paste out-of-band secrets). Providing users such features is particularly helpful when the primary and secondary channels are on the same device. For example, it is difficult for users to transfer the authentication secret on a smartphone because they must switch back and forth — potentially multiple times — between the out-of-band application and the primary channel.

Single-Factor OTP Device

Typical Usage

Users access the OTP generated by the single-factor OTP device. The authenticator output is typically displayed on the device and the user enters it for the verifier.

Usability considerations for typical usage include:

• Authenticator output allows at least one minute between changes, but ideally allows users the full two minutes as specified in Sec. 5.1.4.1. Users need adequate time to enter the authenticator output (including looking back and forth between the single-factor OTP device and the entry screen).

• Depending on the implementation, the following are additional usability considerations for implementers:

  • If the single-factor OTP device supplies its output via an electronic interface (e.g, USB) this is preferable since users do not have to manually enter the authenticator output. However, if a physical input (e.g., pressing a button) is required to operate, the location of the USB ports could pose usability difficulties. For example, the USB ports of some computers are located on the back of the computer and will be difficult for users to reach.
  • Limited availability of a direct computer interface such as a USB port could pose usability difficulties. For example, the number of USB ports on laptop computers is often very limited. This may force users to unplug other USB peripherals in order to use the single-factor OTP device.

Multi-Factor OTP Device

Typical Usage

Users access the OTP generated by the multi-factor OTP device through a second authentication factor. The OTP is typically displayed on the device and the user manually enters it for the verifier. The second authentication factor may be achieved through some kind of integral entry pad to enter a memorized secret, an integral biometric (e.g., fingerprint) reader, or a direct computer interface (e.g., USB port). Usability considerations for the additional factor apply as well — see Sec. 10.2.1 for memorized secrets and Sec. 10.4 for biometrics used in multi-factor authenticators.

Usability considerations for typical usage include:

• User experience during manual entry of the authenticator output.
  • For time-based OTP, provide a grace period in addition to the time during which the OTP is displayed. Users need adequate time to enter the authenticator output, including looking back and forth between the multi-factor OTP device and the entry screen.
  • Consider form-factor constraints if users must unlock the multi-factor OTP device via an integral entry pad or enter the authenticator output on mobile devices. Typing on small devices is significantly more error prone and time-consuming than typing on a traditional keyboard. The smaller the integral entry pad and onscreen keyboard, the more difficult it is to type. Providing larger touch areas improves usability for unlocking the multi-factor OTP device or entering the authenticator output on mobile devices.
  • Limited availability of a direct computer interface like a USB port could pose usability difficulties. For example, laptop computers often have a limited number of USB ports, which may force users to unplug other USB peripherals to use the multi-factor OTP device.

Single-Factor Cryptographic Software

Typical Usage

Users authenticate by proving possession and control of the cryptographic software key.

Usability considerations for typical usage include:

• Give cryptographic keys appropriately descriptive names that are meaningful to users since users have to recognize and recall which cryptographic key to use for which authentication task. This prevents users from having to deal with multiple similarly and ambiguously named cryptographic keys. Selecting from multiple cryptographic keys on smaller mobile devices may be particularly problematic if the names of the cryptographic keys are shortened due to reduced screen size.

Single-Factor Cryptographic Device

Typical Usage

Users authenticate by proving possession of the single-factor cryptographic device.

Usability considerations for typical usage include:

• Requiring a physical input (e.g., pressing a button) to operate the single-factor cryptographic device could pose usability difficulties. For example, some USB ports are located on the back of computers, making it difficult for users to reach.

• Limited availability of a direct computer interface like a USB port could pose usability difficulties. For example, laptop computers often have a limited number of USB ports, which may force users to unplug other USB peripherals to use the single-factor cryptographic device.

Multi-Factor Cryptographic Software

Typical Usage

In order to authenticate, users prove possession and control of the cryptographic key stored on disk or some other “soft” media that requires activation. The activation is through the input of a second authentication factor, either a memorized secret or a biometric characteristic. Usability considerations for the additional factor apply as well — see Sec. 10.2.1 for memorized secrets and Sec. 10.4 for biometrics used in multi-factor authenticators.

Usability considerations for typical usage include:

• Give cryptographic keys appropriately descriptive names that are meaningful to users since users have to recognize and recall which cryptographic key to use for which authentication task. This prevents users from having to deal with multiple similarly and ambiguously named cryptographic keys. Selecting from multiple cryptographic keys on smaller mobile devices may be particularly problematic if the names of the cryptographic keys areas shortened due to reduced screen size.

Multi-Factor Cryptographic Device

Typical Usage

Users authenticate by proving possession of the multi-factor cryptographic device and control of the protected cryptographic key. The device is activated by a second authentication factor, either a memorized secret or a biometric. Usability considerations for the additional factor apply as well — see Sec. 10.2.1 for memorized secrets and Sec. 10.4 for biometrics used in multi-factor authenticators.

Usability considerations for typical usage include:

• Do not require users to keep multi-factor cryptographic devices connected following authentication. Users may forget to disconnect the multi-factor cryptographic device when they are done with it (e.g., forgetting a smartcard in the smartcard reader and walking away from the computer).
  • Users need to be informed regarding whether the multi-factor cryptographic device is required to stay connected or not.

• Give cryptographic keys appropriately descriptive names that are meaningful to users since users have to recognize and recall which cryptographic key to use for which authentication task. This prevents users being faced with multiple similarly and ambiguously named cryptographic keys. Selecting from multiple cryptographic keys on smaller mobile devices (such as smartphones) may be particularly problematic if the names of the cryptographic keys are shortened due to reduced screen size.

• Limited availability of a direct computer interface like a USB port could pose usability difficulties. For example, laptop computers often have a limited number of USB ports, which may force users to unplug other USB peripherals to use the multi-factor cryptographic device.

Summary of Usability Considerations

Figure 3 summarizes the usability considerations for typical usage and intermittent events for each authenticator type. Many of the usability considerations for typical usage apply to most of the authenticator types, as demonstrated in the rows. The table highlights common and divergent usability characteristics across the authenticator types. Each column allows readers to easily identify the usability attributes to address for each authenticator. Depending on users’ goals and context of use, certain attributes may be valued over others. Whenever possible, provide alternative authenticator types and allow users to choose between them.

Multi-factor authenticators (e.g., multi-factor OTP devices, multi-factor cryptographic software, and multi-factor cryptographic devices) also inherit their secondary factor’s usability considerations. As biometrics are only allowed as an activation factor in multi-factor authentication solutions, usability considerations for biometrics are not included in Figure 3 and are discussed in Sec. 10.4.

Figure 3 Usability Considerations Summary by Authenticator Type

\clearpage

Biometrics Usability Considerations

This section provides a high-level overview of general usability considerations for biometrics. A more detailed discussion of biometric usability can be found in Usability & Biometrics, Ensuring Successful Biometric Systems [UsabilityBiometrics].

Although there are other biometric modalities, the following three biometric modalities are more commonly used for authentication: fingerprint, face and iris.

Typical Usage

• For all modalities, user familiarity and practice with the device improves performance.

• Device affordances (i.e., properties of a device that allow a user to perform an action), feedback, and clear instructions are critical to a user’s success with the biometric device. For example, provide clear instructions on the required actions for liveness detection.

• Ideally, users can select the modality they are most comfortable with for their second authentication factor. The user population may be more comfortable and familiar with — and accepting of — some biometric modalities than others.

• User experience with biometrics as an activation factor.
  • Provide clear, meaningful feedback on the number of remaining allowed attempts. For example, for rate limiting (i.e., throttling), inform users of the time period they have to wait until next attempt to reduce user confusion and frustration.
• Fingerprint Usability Considerations:
  • Users have to remember which finger(s) they used for initial enrollment.
  • The amount of moisture on the finger(s) affects the sensor’s ability for successful capture.
  • Additional factors influencing fingerprint capture quality include age, gender, and occupation (e.g., users handling chemicals or working extensively with their hands may have degraded friction ridges).
• Face Usability Considerations:
  • Users have to remember whether they wore any artifacts (e.g., glasses) during enrollment because it affects facial recognition accuracy.
  • Differences in environmental lighting conditions can affect facial recognition accuracy.
  • Facial expressions affect facial recognition accuracy (e.g., smiling versus neutral expression).
  • Facial poses affect facial recognition accuracy (e.g., looking down or away from the camera).
• Iris Usability Considerations:
  • Wearing colored contacts may affect the iris recognition accuracy.
  • Users who have had eye surgery may need to re-enroll post-surgery.
  • Differences in environmental lighting conditions can affect iris recognition accuracy, especially for certain iris colors.

Intermittent Events

As biometrics are only permitted as a second factor for multi-factor authentication, usability considerations for intermittent events with the primary factor still apply. Intermittent events with biometrics use include, but are not limited to, the following, which may affect recognition accuracy:

• If users injure their enrolled finger(s), fingerprint recognition may not work. Fingerprint authentication will be difficult for users with degraded fingerprints.
• The time elapsed between the time of facial recognition for authentication and the time of the initial enrollment can affect recognition accuracy as a user’s face changes naturally over time. A user’s weight change may also be a factor.
• Iris recognition may not work for people who had eye surgery, unless they re-enroll.

Across all biometric modalities, usability considerations for intermittent events include:

• An alternative authentication method must be available and functioning. In cases where biometrics do not work, allow users to use a memorized secret as an alternative second factor.
• Provisions for technical assistance:
  • Clearly communicate information on how and where to acquire technical assistance. For example, provide users information such as a link to an online self-service feature and a phone number for help desk support. Ideally, provide sufficient information to enable users to recover from intermittent events on their own without outside intervention.
  • Inform users of factors that may affect the sensitivity of the biometric sensor (e.g., cleanliness of the sensor).

Equity Considerations

This section is informative.

正確で公平な Authentication Service は, Digital Identity System の不可欠な要素である. Authentication の正確さの aspect は, 大部分がこのドキュメント以外の場所で見つかるセキュリティ要件の対象だが, Executive Order 13985, “Advancing Racial Equity and Support for Underserved Communities Through the Federal Government” [EO13985] で指定されているように, 政府サービスへの公平なアクセスを提供するために, すべての Subscriber を確実に Authenticate できることが必要である. 連邦政府を通じて十分なサービスを受けていないコミュニティのために」[EO13985]. 公平性リスクを評価するにあたり, CSP はその Authentication Service によって取り扱われる全体的なユーザーの Population を考慮する必要がある. 加えて, CSP はその Service を使用する際に, 共通する特性によって不公平なアクセス, 扱い, または結果にさらされる可能性がある Population 内のユーザーのグループをさらに識別する. Sec. 10 で提供される使いさすさの考慮事項もまた Authentication Service を使用するすべての人のための全体的な使いやすさと公平性の確保のために考慮される必要がある.

Equity の主要な aspect は, CSP がその Subscriber Population のニーズの予測と, その Population に適した Authenticator の選択肢の提供を必要とすることである. Authenticator の適合性の問題の例を以下に示す:

• SMS-based Out-of-band Authentication は, 携帯電話のサービスが利用できない地域では使いづらい可能性がある.
• OTP デバイスは, 視覚に難しさがある Subscriber にとって読みにくい場合がある.
• 音声電話で送信される Out-of-band Authentication Secret は, 聞き取りに難しさがある Subscriber にとってはわかりにくい場合がある.
• Facial matching algorithm は, 一部の ethnicity の Subscriber の顔の特徴と効果的に一致しない場合がある.
• ハードウェアベースの Authenticator のコストは, 一部の Subscriber にとっては自身の許容範囲を超えている場合がある.
• Memorized Secret を正確に手動で入力することは, 動作や器用さに disabilitiy がある Subscriber にとっては難しい場合がある.
• 特定の Authenticator Type の使用は, 知能, 発達, 学習, 神経認知などに disabilitiy がある Subscriber にとっては難しい場合がある.

この分野の最も一般的な問題を軽減するために, CSP に要求する Normative Requirement が確立されている. しかし, すべての潜在的な公平性の問題を予測することは実現不可能である. 潜在的な公平性の問題はまたアプリケーションによって異なる. したがって, CSP は, Subscriber が不公平な Authentication Requirement を報告し, 代替となりえる Authentication 方法について助言するためのメカニズムを提供する必要がある.

このガイドラインでは, アカウント回復の必要性を最小限に抑えるために, 追加の Authenticator を Bind することを推奨している(Sec. 6.1.2.3 を参照). しかし, Subscriber は2つ目のハードウェアベースの Authenticator をバックアップとして購入することが難しい場合がある. この不公平性には, Look-up secret (Sec. 5.1.2 を参照) などの安価な Authenticator を, Primary Authenticator の障害や紛失の場合に使用できるようにすることで取り組める.

CSP は, 現在サポートしている Authenticator を使用して解決できない Authentication の課題に遭遇した Subscriber に対応する必要がある. これには, 新しい Authenticator Type のサポートや, Subscriber のニーズを満たす信頼できるサービスを介した Federated Authentication の許可が含まれる場合がある.

Equity Considerations

This section is informative.

Accurate and equitable authentication service is an essential element of a digital identity system. While the accuracy aspects of authentication are largely the subject of the security requirements found elsewhere in this document, the ability for all subscribers to authenticate reliably is required to provide equitable access to government services as specified in Executive Order 13985, “Advancing Racial Equity and Support for Underserved Communities Through the Federal Government” [EO13985]. In assessing equity risks, a CSP should consider the overall user population served by its authentication service. Additionally, the CSP further identifies groups of users within the population whose shared characteristic(s) can cause them to be subject to inequitable access, treatment, or outcomes when using that service. The usability considerations provided in Sec. 10 should also be considered to help ensure the overall usability and equity for all persons using authentication services.

A primary aspect of equity is that the CSP needs to anticipate the needs of its subscriber population and offer authenticator options that are suitable for that population. Some examples of authenticator suitability problems are as follows:

• SMS-based out-of-band authentication may not be usable for subscribers in rural areas where mobile phone service is not available.
• OTP devices may be difficult for subscribers with vision difficulties to read.
• Out-of-band authentication secrets sent via a voice telephone call may be difficult for subscribers with hearing difficulties to understand.
• Facial matching algorithms may less effectively match facial characteristics of subscribers of some ethnicities.
• The cost of hardware-based authenticators may be beyond the means of some subscribers.
• Accurate manual entry of memorized secrets may be difficult for subscribers with some mobility and dexterity-related physical disabilities.
• The use of certain authenticator types may be challenging for subscribers with some disabilities such as intellectual, developmental, learning, and neurocognitive difficulties.

Normative requirements have been established requiring CSPs to mitigate the problems in this area that are expected to be most common. However, it is not feasible to anticipate all potential equity problems. Potential equity problems also will vary for different applications. Accordingly, CSPs need to provide mechanisms for subscribers to report inequitable authentication requirements and to advise them on potential alternative authentication strategies.

This guideline recommends the binding of additional authenticators to minimize the need for account recovery (see Sec. 6.1.2.3). However, a subscriber might find it difficult to purchase a second hardware-based authenticator as a backup. This inequity can be addressed by making inexpensive authenticators such as look-up secrets (see Sec. 5.1.2) available for use in the event of a primary authenticator failure or loss.

CSPs need to be responsive to subscribers that experience authentication challenges that cannot be solved using authenticators they currently support. This might involve supporting a new authenticator type or allowing federated authentication through a trusted service that meets the needs of the subscriber.

References

This section is informative.

General References

[Argon2] Biryukov, A., Dinu, D., Khovratovich, D., and S. Josefsson, “Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications“, RFC 9106, DOI 10.17487/RFC9106, September 2021, https://www.rfc-editor.org/info/rfc9106.

[Blocklists] Habib, Hana, Jessica Colnago, William Melicher, Blase Ur, Sean Segreti, Lujo Bauer, Nicolas Christin, and Lorrie Cranor. “Password Creation in the Presence of Blacklists,” 2017. Available at: https://www.ndss-symposium.org/wp-content/uploads/2017/09/usec2017_01_3_Habib_paper.pdf

[Composition] Komanduri, Saranga, Richard Shay, Patrick Gage Kelley, Michelle L Mazurek, Lujo Bauer, Nicolas Christin, Lorrie Faith Cranor, and Serge Egelman. “Of Passwords and People: Measuring the Effect of Password-Composition Policies.” In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, 2595–2604. ACM, 2011. Available at: https://www.ece.cmu.edu/~lbauer/papers/2011/chi2011-passwords.pdf.

[E-Gov] E-Government Act (includes FISMA) (P.L. 107-347), December 2002, available at: https://www.gpo.gov/fdsys/pkg/PLAW-107publ347/pdf/PLAW-107publ347.pdf.

[EO13681] Executive Order 13681, Improving the Security of Consumer Financial Transactions, October 17, 2014, available at: https://www.federalregister.gov/d/2014-25439.

[EO13985] Executive Order 13985, Advancing Racial Equity and Support for Underserved Communities Through the Federal Government, January 25, 2021, available at: https://www.federalregister.gov/d/2021-01753.

[FEDRAMP] General Services Administration, Federal Risk and Authorization Management Program, available at: https://www.fedramp.gov/.

[M-22-09] OMB Memorandum M-22-09, Moving the U.S. Government Toward Zero Trust Cybersecurity Principles, January 26, 2022, available at: https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf.

[NISTIR8062] NIST Internal Report 8062, An Introduction to Privacy Engineering and Risk Management in Federal Systems, January 2017, available at: https://nvlpubs.nist.gov/nistpubs/ir/2017/NIST.IR.8062.pdf.

[UsabilityBiometrics] National Institute and Standards and Technology, Usability & Biometrics, Ensuring Successful Biometric Systems, June 11, 2008, available at: https://www.nist.gov/customcf/get_pdf.cfm?pub_id=152184.

[OWASP-session] Open Web Application Security Project, Session Management Cheat Sheet, available at: https://www.owasp.org/index.php/Session_Management_Cheat_Sheet.

[OWASP-XSS-prevention] Open Web Application Security Project, XSS (Cross Site Scripting) Prevention Cheat Sheet, available at: https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet.

[Persistence] herley, cormac, and Paul van Oorschot. “A Research Agenda Acknowledging the Persistence of Passwords,” IEEE Security&Privacy Magazine, 2012. Available at: https://research.microsoft.com/apps/pubs/default.aspx?id=154077.

[Policies] Weir, Matt, Sudhir Aggarwal, Michael Collins, and Henry Stern. “Testing Metrics for Password Creation Policies by Attacking Large Sets of Revealed Passwords.” In Proceedings of the 17th ACM Conference on Computer and Communications Security, 162–175. CCS ‘10. New York, NY, USA: ACM, 2010. doi:10.1145/1866307.1866327.

[PrivacyAct] Privacy Act of 1974 (P.L. 93-579), December 1974, available at: https://www.justice.gov/opcl/privacy-act-1974.

[PSL] Public Suffix List https://publicsuffix.org/list/

[Scrypt] Percival, C. and S. Josefsson, The scrypt Password-Based Key Derivation Function, RFC 7914, DOI 10.17487/RFC7914, August 2016, https://www.rfc-editor.org/info/rfc7914.

[Section508] Section 508 Law and Related Laws and Policies (January 30, 2017), available at: https://www.section508.gov/manage/laws-and-policies/.

[Shannon] Shannon, Claude E. “A Mathematical Theory of Communication,” Bell System Technical Journal, v. 27, pp. 379-423, 623-656, July, October, 1948.

[Strength] Kelley, Patrick Gage, Saranga Komanduri, Michelle L Mazurek, Richard Shay, Timothy Vidas, Lujo Bauer, Nicolas Christin, Lorrie Faith Cranor, and Julio Lopez. “Guess Again (and Again and Again): Measuring Password Strength by Simulating Password-Cracking Algorithms.” In Security and Privacy (SP), 2012 IEEE Symposium On, 523–537. IEEE, 2012. Available at: https://ieeexplore.ieee.org/iel5/6233637/6234400/06234434.pdf.

[TOTP] M’Raihi, D., Machani, S., Pei, M., and J. Rydell, TOTP: Time-Based One-Time Password Algorithm, RFC 6238, DOI 10.17487/RFC6238, May 2011, https://www.rfc-editor.org/info/rfc6238.

Standards

[ISO/IEC9241-11] International Standards Organization, ISO/IEC 9241-11 Ergonomic requirements for office work with visual display terminals (VDTs) — Part 11: Guidance on usability, March 1998, available at: https://www.iso.org/standard/16883.html.

[ISO/IEC2382-37] International Standards Organization, Information technology — Vocabulary — Part 37: Biometrics, 2017, available at: https://standards.iso.org/ittf/PubliclyAvailableStandards/c066693_ISO_IEC_2382-37_2017.zip.

[ISO/IEC10646] International Standards Organization, Information technology — Universal coded character set (UCS), 2020, available at: https://www.iso.org/standard/76835.html.

[ISO/IEC24745] International Standards Organization, Information technology — Security techniques — Biometric information protection, 2011, available at: https://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=52946.

[ISO/IEC30107-1] International Standards Organization, Information technology — Biometric presentation attack detection — Part 1: Framework, 2016, available at: https://standards.iso.org/ittf/PubliclyAvailableStandards/c053227_ISO_IEC_30107-1_2016.zip.

[ISO/IEC30107-3] International Standards Organization, Information technology — Biometric presentation attack detection — Part 3: Testing and reporting, 2017.

[RFC20] Cerf, V., “ASCII format for network interchange“, STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, https://www.rfc-editor.org/info/rfc20.

[UAX15] Unicode Consortium, Unicode Normalization Forms, Unicode Standard Annex 15, Version 9.0.0, February 2016, available at: https://www.unicode.org/reports/tr15/.

NIST Special Publications

NIST 800 Series Special Publications are available at https://csrc.nist.gov/publications/sp800. The following publications may be of particular interest to those implementing systems of applications requiring digital authentication.

[SP800-38B] NIST Special Publication 800-38B, Recommendation for Block Cipher Modes of Operation: the CMAC Mode for Authentication, October, 2016, https://dx.doi.org/10.6028/NIST.SP.800-38B.

[SP800-53] NIST Special Publication 800-53 Revision 5, Security and Privacy Controls for Information Systems and Organizations, September 2020 (updated December 10, 2020), https://dx.doi.org/10.6028/NIST.SP.800-53r5.

[SP800-63] NIST Special Publication 800-63-4, Digital Identity Guidelines, December 2022, https://doi.org/10.6028/NIST.SP.800-63-4.ipd.

[SP800-63A] NIST Special Publication 800-63B-4, Digital Identity Guidelines: Enrollment and Identity Proofing, December 2022, https://doi.org/10.6028/NIST.SP.800-63a-4.ipd.

[SP800-63C] NIST Special Publication 800-63C-4, Digital Identity Guidelines: Assertions and Federation, December 2022, https://doi.org/10.6028/NIST.SP.800-63c-4.ipd.

[SP800-73] NIST Special Publication 800-73-4, Interfaces for Personal Identity Verification, February 2016, https://doi.org/10.6028/NIST.SP.800-73-4.

[SP800-90A] NIST Special Publication 800-90A Revision 1, Recommendation for Random Number Generation Using Deterministic Random Bit Generators, June 2015, https://dx.doi.org/10.6028/NIST.SP.800-90Ar1.

[SP800-107] NIST Special Publication 800-107 Revision 1, Recommendation for Applications Using Approved Hash Algorithms, August 2012, https://dx.doi.org/10.6028/NIST.SP.800-107r1.

[SP800-131A] NIST Special Publication 800-131A Revision 2, Transitioning the Use of Cryptographic Algorithms and Key Lengths, March 2019, https://dx.doi.org/10.6028/NIST.SP.800-131Ar2

[SP800-132] NIST Special Publication 800-132, Recommendation for Password-Based Key Derivation, December 2010, https://dx.doi.org/10.6028/NIST.SP.800-132.

[SP800-185] NIST Special Publication 800-185, SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash, and ParallelHash, December 2016, https://doi.org/10.6028/NIST.SP.800-185.

Federal Information Processing Standards

[FIPS140] Federal Information Processing Standard Publication 140-3, Security Requirements for Cryptographic Modules, March 22, 2019, https://doi.org/10.6028/NIST.FIPS.140-3.

[FIPS198] Federal Information Processing Standard Publication 198-1, The Keyed-Hash Message Authentication Code (HMAC), July 2008, https://doi.org/10.6028/NIST.FIPS.198-1.

[FIPS201] Federal Information Processing Standard Publication 201-3, Personal Identity Verification (PIV) of Federal Employees and Contractors, January 2022, https://dx.doi.org/10.6028/NIST.FIPS.201-3.

[FIPS202] Federal Information Processing Standard Publication 202, SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions, August 2015, https://dx.doi.org/10.6028/NIST.FIPS.202.

References

This section is informative.

General References

[Argon2] Biryukov, A., Dinu, D., Khovratovich, D., and S. Josefsson, “Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications“, RFC 9106, DOI 10.17487/RFC9106, September 2021, https://www.rfc-editor.org/info/rfc9106.

[Blocklists] Habib, Hana, Jessica Colnago, William Melicher, Blase Ur, Sean Segreti, Lujo Bauer, Nicolas Christin, and Lorrie Cranor. “Password Creation in the Presence of Blacklists,” 2017. Available at: https://www.ndss-symposium.org/wp-content/uploads/2017/09/usec2017_01_3_Habib_paper.pdf

[Composition] Komanduri, Saranga, Richard Shay, Patrick Gage Kelley, Michelle L Mazurek, Lujo Bauer, Nicolas Christin, Lorrie Faith Cranor, and Serge Egelman. “Of Passwords and People: Measuring the Effect of Password-Composition Policies.” In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, 2595–2604. ACM, 2011. Available at: https://www.ece.cmu.edu/~lbauer/papers/2011/chi2011-passwords.pdf.

[E-Gov] E-Government Act (includes FISMA) (P.L. 107-347), December 2002, available at: https://www.gpo.gov/fdsys/pkg/PLAW-107publ347/pdf/PLAW-107publ347.pdf.

[EO13681] Executive Order 13681, Improving the Security of Consumer Financial Transactions, October 17, 2014, available at: https://www.federalregister.gov/d/2014-25439.

[EO13985] Executive Order 13985, Advancing Racial Equity and Support for Underserved Communities Through the Federal Government, January 25, 2021, available at: https://www.federalregister.gov/d/2021-01753.

[FEDRAMP] General Services Administration, Federal Risk and Authorization Management Program, available at: https://www.fedramp.gov/.

[M-22-09] OMB Memorandum M-22-09, Moving the U.S. Government Toward Zero Trust Cybersecurity Principles, January 26, 2022, available at: https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf.

[NISTIR8062] NIST Internal Report 8062, An Introduction to Privacy Engineering and Risk Management in Federal Systems, January 2017, available at: https://nvlpubs.nist.gov/nistpubs/ir/2017/NIST.IR.8062.pdf.

[UsabilityBiometrics] National Institute and Standards and Technology, Usability & Biometrics, Ensuring Successful Biometric Systems, June 11, 2008, available at: https://www.nist.gov/customcf/get_pdf.cfm?pub_id=152184.

[OWASP-session] Open Web Application Security Project, Session Management Cheat Sheet, available at: https://www.owasp.org/index.php/Session_Management_Cheat_Sheet.

[OWASP-XSS-prevention] Open Web Application Security Project, XSS (Cross Site Scripting) Prevention Cheat Sheet, available at: https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet.

[Persistence] herley, cormac, and Paul van Oorschot. “A Research Agenda Acknowledging the Persistence of Passwords,” IEEE Security&Privacy Magazine, 2012. Available at: https://research.microsoft.com/apps/pubs/default.aspx?id=154077.

[Policies] Weir, Matt, Sudhir Aggarwal, Michael Collins, and Henry Stern. “Testing Metrics for Password Creation Policies by Attacking Large Sets of Revealed Passwords.” In Proceedings of the 17th ACM Conference on Computer and Communications Security, 162–175. CCS ‘10. New York, NY, USA: ACM, 2010. doi:10.1145/1866307.1866327.

[PrivacyAct] Privacy Act of 1974 (P.L. 93-579), December 1974, available at: https://www.justice.gov/opcl/privacy-act-1974.

[PSL] Public Suffix List https://publicsuffix.org/list/

[Scrypt] Percival, C. and S. Josefsson, The scrypt Password-Based Key Derivation Function, RFC 7914, DOI 10.17487/RFC7914, August 2016, https://www.rfc-editor.org/info/rfc7914.

[Section508] Section 508 Law and Related Laws and Policies (January 30, 2017), available at: https://www.section508.gov/manage/laws-and-policies/.

[Shannon] Shannon, Claude E. “A Mathematical Theory of Communication,” Bell System Technical Journal, v. 27, pp. 379-423, 623-656, July, October, 1948.

[Strength] Kelley, Patrick Gage, Saranga Komanduri, Michelle L Mazurek, Richard Shay, Timothy Vidas, Lujo Bauer, Nicolas Christin, Lorrie Faith Cranor, and Julio Lopez. “Guess Again (and Again and Again): Measuring Password Strength by Simulating Password-Cracking Algorithms.” In Security and Privacy (SP), 2012 IEEE Symposium On, 523–537. IEEE, 2012. Available at: https://ieeexplore.ieee.org/iel5/6233637/6234400/06234434.pdf.

[TOTP] M’Raihi, D., Machani, S., Pei, M., and J. Rydell, TOTP: Time-Based One-Time Password Algorithm, RFC 6238, DOI 10.17487/RFC6238, May 2011, https://www.rfc-editor.org/info/rfc6238.

Standards

[ISO/IEC9241-11] International Standards Organization, ISO/IEC 9241-11 Ergonomic requirements for office work with visual display terminals (VDTs) — Part 11: Guidance on usability, March 1998, available at: https://www.iso.org/standard/16883.html.

[ISO/IEC2382-37] International Standards Organization, Information technology — Vocabulary — Part 37: Biometrics, 2017, available at: https://standards.iso.org/ittf/PubliclyAvailableStandards/c066693_ISO_IEC_2382-37_2017.zip.

[ISO/IEC10646] International Standards Organization, Information technology — Universal coded character set (UCS), 2020, available at: https://www.iso.org/standard/76835.html.

[ISO/IEC24745] International Standards Organization, Information technology — Security techniques — Biometric information protection, 2011, available at: https://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=52946.

[ISO/IEC30107-1] International Standards Organization, Information technology — Biometric presentation attack detection — Part 1: Framework, 2016, available at: https://standards.iso.org/ittf/PubliclyAvailableStandards/c053227_ISO_IEC_30107-1_2016.zip.

[ISO/IEC30107-3] International Standards Organization, Information technology — Biometric presentation attack detection — Part 3: Testing and reporting, 2017.

[RFC20] Cerf, V., “ASCII format for network interchange“, STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, https://www.rfc-editor.org/info/rfc20.

[UAX15] Unicode Consortium, Unicode Normalization Forms, Unicode Standard Annex 15, Version 9.0.0, February 2016, available at: https://www.unicode.org/reports/tr15/.

NIST Special Publications

NIST 800 Series Special Publications are available at https://csrc.nist.gov/publications/sp800. The following publications may be of particular interest to those implementing systems of applications requiring digital authentication.

[SP800-38B] NIST Special Publication 800-38B, Recommendation for Block Cipher Modes of Operation: the CMAC Mode for Authentication, October, 2016, https://dx.doi.org/10.6028/NIST.SP.800-38B.

[SP800-53] NIST Special Publication 800-53 Revision 5, Security and Privacy Controls for Information Systems and Organizations, September 2020 (updated December 10, 2020), https://dx.doi.org/10.6028/NIST.SP.800-53r5.

[SP800-63] NIST Special Publication 800-63-4, Digital Identity Guidelines, December 2022, https://doi.org/10.6028/NIST.SP.800-63-4.ipd.

[SP800-63A] NIST Special Publication 800-63B-4, Digital Identity Guidelines: Enrollment and Identity Proofing, December 2022, https://doi.org/10.6028/NIST.SP.800-63a-4.ipd.

[SP800-63C] NIST Special Publication 800-63C-4, Digital Identity Guidelines: Assertions and Federation, December 2022, https://doi.org/10.6028/NIST.SP.800-63c-4.ipd.

[SP800-73] NIST Special Publication 800-73-4, Interfaces for Personal Identity Verification, February 2016, https://doi.org/10.6028/NIST.SP.800-73-4.

[SP800-90A] NIST Special Publication 800-90A Revision 1, Recommendation for Random Number Generation Using Deterministic Random Bit Generators, June 2015, https://dx.doi.org/10.6028/NIST.SP.800-90Ar1.

[SP800-107] NIST Special Publication 800-107 Revision 1, Recommendation for Applications Using Approved Hash Algorithms, August 2012, https://dx.doi.org/10.6028/NIST.SP.800-107r1.

[SP800-131A] NIST Special Publication 800-131A Revision 2, Transitioning the Use of Cryptographic Algorithms and Key Lengths, March 2019, https://dx.doi.org/10.6028/NIST.SP.800-131Ar2

[SP800-132] NIST Special Publication 800-132, Recommendation for Password-Based Key Derivation, December 2010, https://dx.doi.org/10.6028/NIST.SP.800-132.

[SP800-185] NIST Special Publication 800-185, SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash, and ParallelHash, December 2016, https://doi.org/10.6028/NIST.SP.800-185.

Federal Information Processing Standards

[FIPS140] Federal Information Processing Standard Publication 140-3, Security Requirements for Cryptographic Modules, March 22, 2019, https://doi.org/10.6028/NIST.FIPS.140-3.

[FIPS198] Federal Information Processing Standard Publication 198-1, The Keyed-Hash Message Authentication Code (HMAC), July 2008, https://doi.org/10.6028/NIST.FIPS.198-1.

[FIPS201] Federal Information Processing Standard Publication 201-3, Personal Identity Verification (PIV) of Federal Employees and Contractors, January 2022, https://dx.doi.org/10.6028/NIST.FIPS.201-3.

[FIPS202] Federal Information Processing Standard Publication 202, SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions, August 2015, https://dx.doi.org/10.6028/NIST.FIPS.202.

Strength of Memorized Secrets

This appendix is informative.

本 Appendix を通じて, 議論を容易にするため “Password” という用語を用いる. 本用語が用いられる箇所では, Password に加え Passphrase や PIN も含むと解釈すべきである.

Introduction

Usability とセキュリティ双方の観点で Password の使用に関するフラストレーションが広がっているが, Password は依然として広く Authentication に使われている方式である [Persistence]. しかしながら, 人間は複雑で勝手に決められたシークレットを記憶する能力が限られており, しばしば簡単に推測可能な Password を選択することになる. この結果生じるセキュリティ上の懸念に対応するため, オンラインサービスは Memorized Secret の複雑度を上げるようなルールを導入してきた. 最も顕著なルール形式はその構成ルールであり, 1つ以上の数字, 大文字および記号など, 複数の文字種を用いることをユーザーに要求するようなものである. しかしながら, 侵害された Password データベースの分析からは, そのようなルールがもたらす Usability への影響や記憶しづらさのわりに, それによる恩恵は当初考えられていたほど大したものではないことが明らかになっている [Policies].

ユーザー選択により生成された Password の複雑度は, しばしば Entropy という情報理論のコンセプトを使って特徴づけられることがある [Shannon]. 決定論的分布関数を持つデータの Entropy は容易に計算可能だが, ユーザー選択の Password の Entropy を推定するのは困難であり, そのための過去の努力はあまり正確ではなかった. そのため, それとは異なりよりシンプルなアプローチとして, 主に Password の長さに基づくものをここに示す.

Password の使用に関連する Attack の多くは, Password の複雑性と長さには影響されない. キーストロークロギング, Phishing および Social Engineering Attack は, シンプルな Password に対して有効であるのと同様に, 長く複雑な Password に対しても有効である. こういった Attack は本 Appendix のスコープ外とする.

Length

Password の長さは Password 強度を特徴づける第一のファクターであることがわかっている [Strength] [Composition]. 短すぎる Password は, 単語や一般的に使用される Password を用いた辞書攻撃や Brute Force Attack の対象となる.

最低限必要な Password の長さは, 対応する脅威モデルに大きく依存する. Attacker が Password を推測してログインを試みる Online Attack は, 許容するログイン試行回数を制限することで軽減可能である. Attacker (またはタイピングスキルの低い執拗な Claimant) が大量の誤推測により Subscriber に対して Denial-of-Service Attack を引き起こすのを防ぐため, Password は十分複雑で, 適度な入力回数ではレートリミットに到達しないが, 推測が成功する可能性がかなり高くなる前にはレートリミットに到達するようなものとする必要がある.

Attacker がデータベース侵害を通じて1つ以上のハッシュ化された Password を取得すると, Offline Attack が可能になることもある. Attacker が1人以上のユーザーの Password を特定できるかは, Password の保存方法に依存する. 通常 Password は乱数値の Salt を用いてハッシュ化されており, さらに計算コストの高いアルゴリズムが使用されていればなお良い. そのような対策を講じても, 現在の Attacker はレートリミットなしで毎秒数十億のハッシュ計算が可能であり, そのような攻撃に対抗できる Password は Online Attack に抵抗できると予想される Password より桁違いに複雑でなければならない.

ユーザーには, 合理的な範囲内で Password を好きなだけ長くすることを推奨するべきである. ハッシュ化された Password のサイズは元の Password の長さとは無関係であるため, ユーザーが希望しているのに長い Password (ないし Passphrase) の利用を許可しない理由はない. 非常に長いパスワード (おそらくメガバイト級) はハッシュ化に過度の処理時間を要する可能性があるため, そういった制限を設けるのは合理的である.

Complexity

上述のように, 構成ルールは, ユーザー選択による Password の推測を困難にするために一般的に利用されている. しかし, 調査によると, ユーザーは構成ルールで課される要件に対して非常に推測容易な方法で応答することが示されている [Policies]. 例えば, Password として “password” を選択しようとするユーザーは, 大文字と数字を含める必要がある場合には “Password1” を, 記号も必要な場合は “Password1!” を選択する可能性が比較的高い.

また, 複雑な Password を生成しようとしてオンラインサービスに拒否されると, ユーザーはフラストレーションを感じる. 多くのサービスは, スペースやさまざまな特殊文字を含む Password を拒否する. 場合によっては, 受け入れられない特殊文字は, そういった文字に依存する SQL インジェクションなどの Attack を回避するためな可能性もある. しかしながら, 適切にハッシュ化された Password はどのような場合でもデータベースにそのまま送られるわけではないため, そのような予防策は不要である. さらに, ユーザーがフレーズを使用できるよう, スペースを含められるようにもすべきである. ただし, スペース自体は Password の複雑さをほとんど増やすこともなく, Usability の問題 (e.g., 気づかずに1つではなく2つのスペースを入力してしまう) を引き起こす可能性もあるため, 入力 Passsword 中の連続するスペースを Verification 前に取り除くことが有益な場合もある.

ユーザーの Password 選択は非常に予測しやすいため, Attacker は過去に利用に成功したものをもとに Password を推測する可能性がある. これには, 上記例の “Password1!” のような, 過去に侵害された辞書単語や Password を含む. そのため, ユーザー選択の Password を受け入れ不可な Password の Blocklist と比較することを推奨する. このリストには, 過去に侵害された事例で用いられた Password, 辞書単語やユーザーが選択しがちな特定単語 (サービス自体の名前など) から生成された Password を含めるべきである. ユーザー選択の Password も最小長要件に従うため, この辞書にはそのような要件にあったエントリーのみを含める必要がある. Sec. 5.1.1.2 で述べたように, Blocklist があまりに大きく包括的であることは有益ではない. Blocklist の主な目的は, Online Attack で Throttling 制限に到達するまでに推測されてしまう可能性のある非常に一般的な Password の利用を防ぐことである. Blocklist が大きすぎると, 覚えやすい Password を選択しようとするユーザーにフラストレーションを与えかねない.

非常に複雑な Memorized Secret は新たな潜在的脆弱性をもたらす. そういった Memorized Secret は記憶に残る可能性が低く, 安全でない方法で書き留められたり電子的に保存される可能性が高い. そういった慣行が必ずしも脆弱であるわけではないが, 統計的にはそういったシークレットの記録方法はのいくらかは脆弱になりがちである. これは過度に長く複雑な Memorized Secret を要求しないという追加のモチベーションとなる.

Central vs. Local Verification

単体の Authentication Factor として利用される Password は, 通常 CSP の Verifier によって中央で一元的に検証されるが, Multi-factor Authenticator の Activation Factor として利用される Password は, ローカルで検証されたり Authenticator Output の導出 (Activation Factor が正しくなければ Authenticator Output も正しくならない) のために用いられる. こういったシチュエーションは “Local Verification” と呼ばれる.

Central Verification と Local Verification の Attack 対象領域と脆弱性は互いに大きく異なる. したがって, 中央で検証される Memorized Secret に対する要件とローカルで検証されるそれは異なる. 中央で検証されるシークレットには, オンラインリソースである Verifier が, 全ての Subscriber の Password に対して Salt 付きで繰り返しハッシュ化した Verification シークレットを保存する必要がある. Salt およびハッシュ化プロセスはハッシュ値から Password を特定するための計算量を増大させるが, Verifier は Attacker にとっての格好の標的となる. 特定の Subscriber ではなく任意の Subscriber を侵害することに関心を持つ Attacker であればなおさらである.

ローカルの Verifier には, 中央のオンラインな Verifier に対する大規模攻撃のような心配はないが, Authenticator の物理セキュリティと関連するエンドポイントの Integrity (完全性) により大きく依存する. Authenticator が Activation Factor を保存する範囲で, その Activation Factor は物理攻撃および Side-Channel Attack (e.g., 電力およびタイミング解析) から保護しなければならない. 関連するエンドポイントから Activation Factor が入力される際は, そのエンドポイントがマルウェアに感染していてはならない. 例えば Password を保護する場合は, キーロガーソフトウェアなどが防ぐべきマルウェアになる. これらの脅威は Password の長さと複雑さにあまり依存しないため, こういった要件は Local Verification では緩和される.

Online Password-guessing Attack は, 中央およびローカルで検証される Password ともに共通した脅威である. Online Attack に対する主要な防御策である Throttling は, ローカルの Verifier にとっては特に困難となる可能性がある. そういった Authenticator の中には, 失敗試行に関する情報をセキュアに保存する能力が限られているものもある. Throttling は, Authenticator 内に無効な試行の回数を保持するか, Throttling を行う CSP Verifier に拒否されるような Authenticator Output を生成することで実現できる. この場合, Authenticator Output が無効であることが Attacker に明らかにならないことが重要である. さもないと Attacker は有効に見える Authenticator Output が出力されるまでオフライン試行を繰り返すことができる.

Summary

ここで推奨されている以上の長さと複雑さの要件は, Memorized Secret の難易度を大幅に高め, ユーザーのフラストレーションを増加させる. その結果, ユーザーはしばしばそういった制約の回避策として逆効果な方法を選ぶこともある. さらに, Blocklist, セキュアでハッシュ化されたストレージ, レートリミットなどのその他の軽減策は, モダンな Brute-force Attack を防ぐのにより効果的である. したがって, 追加の複雑さの要件は課さない.

Strength of Memorized Secrets

This appendix is informative.

Throughout this appendix, the word “password” is used for ease of discussion. Where used, it should be interpreted to include passphrases and PINs as well as passwords.

Introduction

Despite widespread frustration with the use of passwords from both a usability and security standpoint, they remain a very widely used form of authentication [Persistence]. Humans, however, have only a limited ability to memorize complex, arbitrary secrets, so they often choose passwords that can be easily guessed. To address the resultant security concerns, online services have introduced rules in an effort to increase the complexity of these memorized secrets. The most notable form of these is composition rules, which require the user to choose passwords constructed using a mix of character types, such as at least one digit, uppercase letter, and symbol. However, analyses of breached password databases reveal that the benefit of such rules is not nearly as significant as initially thought [Policies], although the impact on usability and memorability is severe.

Complexity of user-chosen passwords has often been characterized using the information theory concept of entropy [Shannon]. While entropy can be readily calculated for data having deterministic distribution functions, estimating the entropy for user-chosen passwords is difficult and past efforts to do so have not been particularly accurate. For this reason, a different and somewhat simpler approach, based primarily on password length, is presented herein.

Many attacks associated with the use of passwords are not affected by password complexity and length. Keystroke logging, phishing, and social engineering attacks are equally effective on lengthy, complex passwords as simple ones. These attacks are outside the scope of this Appendix.

Length

Password length has been found to be a primary factor in characterizing password strength [Strength] [Composition]. Passwords that are too short yield to brute force attacks as well as to dictionary attacks using words and commonly chosen passwords.

The minimum password length that should be required depends to a large extent on the threat model being addressed. Online attacks where the attacker attempts to log in by guessing the password can be mitigated by limiting the rate of login attempts permitted. In order to prevent an attacker (or a persistent claimant with poor typing skills) from easily inflicting a denial-of-service attack on the subscriber by making many incorrect guesses, passwords need to be complex enough that rate limiting does not occur after a modest number of erroneous attempts, but does occur before there is a significant chance of a successful guess.

Offline attacks are sometimes possible when one or more hashed passwords is obtained by the attacker through a database breach. The ability of the attacker to determine one or more users’ passwords depends on the way in which the password is stored. Commonly, passwords are salted with a random value and hashed, preferably using a computationally expensive algorithm. Even with such measures, the current ability of attackers to compute many billions of hashes per second with no rate limiting requires passwords intended to resist such attacks to be orders of magnitude more complex than those that are expected to resist only online attacks.

Users should be encouraged to make their passwords as lengthy as they want, within reason. Since the size of a hashed password is independent of its length, there is no reason not to permit the use of lengthy passwords (or pass phrases) if the user wishes. Extremely long passwords (perhaps megabytes in length) could conceivably require excessive processing time to hash, so it is reasonable to have some limit.

Complexity

As noted above, composition rules are commonly used in an attempt to increase the difficulty of guessing user-chosen passwords. Research has shown, however, that users respond in very predictable ways to the requirements imposed by composition rules [Policies]. For example, a user that might have chosen “password” as their password would be relatively likely to choose “Password1” if required to include an uppercase letter and a number, or “Password1!” if a symbol is also required.

Users also express frustration when attempts to create complex passwords are rejected by online services. Many services reject passwords with spaces and various special characters. In some cases, the special characters that are not accepted might be an effort to avoid attacks like SQL injection that depend on those characters. But a properly hashed password would not be sent intact to a database in any case, so such precautions are unnecessary. Users should also be able to include space characters to allow the use of phrases. Spaces themselves, however, add little to the complexity of passwords and may introduce usability issues (e.g., the undetected use of two spaces rather than one), so it may be beneficial to remove repeated spaces in typed passwords prior to verification.

Users’ password choices are very predictable, so attackers are likely to guess passwords that have been successful in the past. These include dictionary words and passwords from previous breaches, such as the “Password1!” example above. For this reason, it is recommended that passwords chosen by users be compared against a blocklist of unacceptable passwords. This list should include passwords from previous breach corpuses, dictionary words, and specific words (such as the name of the service itself) that users are likely to choose. Since user choice of passwords will also be governed by a minimum length requirement, this dictionary need only include entries meeting that requirement. As noted in Sec. 5.1.1.2, it is not beneficial for the blocklist to be excessively large or comprehensive, since its primary purpose is to prevent the use of very common passwords that might be guessed in an online attack before throttling restrictions take effect. An excessively large blocklist is likely to frustrate users that attempt to choose a memorable password.

Highly complex memorized secrets introduce a new potential vulnerability: they are less likely to be memorable, and it is more likely that they will be written down or stored electronically in an unsafe manner. While these practices are not necessarily vulnerable, statistically some methods of recording such secrets will be. This is an additional motivation not to require excessively long or complex memorized secrets.

Central vs. Local Verification

While passwords that are used as a separate authentication factor are generally verified centrally by the CSP’s verifier, those that are used as an activation factor for a multi-factor authenticator are either verified locally or are used to derive the authenticator output, which will be incorrect if the wrong activation factor is used. Both of these situations are referred to as “local verification”.

The attack surface and vulnerabilities for central and local verification are very different from each other. Accordingly, the requirements for memorized secrets verified centrally is different from those verified locally. Centrally verified secrets require the verifier, which is an online resource, to store salted and iteratively hashed verification secrets for all subscribers’ passwords. Although the salting and hashing process increases the computational effort to determine the passwords from the hashes, the verifier is an attractive target for attackers, particularly those who are interested in compromising an arbitrary subscriber rather than a specific one.

Local verifiers do not have the same concerns with attacks at scale on a central online verifier, but depend to a greater extent on the physical security of the authenticator and the integrity of its associated endpoint. To the extent that the authenticator stores the activation factor, that factor must be protected against physical and side-channel (e.g., power and timing analysis) attacks on the authenticator. When the activation factor is entered through the associated endpoint, the endpoint needs to be free of malware, such as key-logging software, if the password is to be protected. Since these threats are less dependant on the length and complexity of the password, those requirements are relaxed for local verification.

Online password-guessing attacks are a similar threat for centrally and locally verified passwords. Throttling, which is the primary defense against online attacks, can be particularly challenging for local verifiers because of the limited ability of some authenticators to securely store information about unsuccessful attempts. Throttling can be performed by either keeping a count of invalid attempts in the authenticator, or by generating an authenticator output that is rejected by the CSP verifier, which does the throttling. In this case it is important that the invalid outputs not be obvious to the attacker, who could otherwise make offline attempts until a valid-looking output appears.

Summary

Length and complexity requirements beyond those recommended here significantly increase the difficulty of memorized secrets and increase user frustration. As a result, users often work around these restrictions in a way that is counterproductive. Furthermore, other mitigations such as blocklists, secure hashed storage, and rate limiting are more effective at preventing modern brute-force attacks. Therefore, no additional complexity requirements are imposed.

Change Log

This appendix is informative. It provides an overview of the changes to SP 800-63B since its initial release.

• Section 5.2.3 — Updated biometric performance requirements and metrics and included discussion of equity impacts.

• Section 5.2.5 — Added definition and updated requirements for phishing resistant authenticators.

• Section 5.2.11 — Established separate requirements for locally verified memorized secrets known as activation secrets.

• Section 5.2.12 — Added requirements for authenticators that are connected via wireless technologies such as NFC and Bluetooth.

Change Log

This appendix is informative. It provides an overview of the changes to SP 800-63B since its initial release.

• Section 5.2.3 — Updated biometric performance requirements and metrics and included discussion of equity impacts.

• Section 5.2.5 — Added definition and updated requirements for phishing resistant authenticators.

• Section 5.2.11 — Established separate requirements for locally verified memorized secrets known as activation secrets.

• Section 5.2.12 — Added requirements for authenticators that are connected via wireless technologies such as NFC and Bluetooth.