usnistgov/800-63-3

Home to public development of NIST Special Publication 800-63-3: Digital Authentication Guidelines

Special Publication 800-63 Digital Identity Guidelines

The finalized four-volume SP 800-63 Digital Identity Guidelines is now available, both in PDF format and online.

The official versions of these documents are the PDFs available at:

• https://doi.org/10.6028/NIST.SP.800-63-3
• https://doi.org/10.6028/NIST.SP.800-63a
• https://doi.org/10.6028/NIST.SP.800-63b
• https://doi.org/10.6028/NIST.SP.800-63c

This repository, used for development of the SP 800-63 document suite, is available as a resource for those who prefer to view the documents in HTML form or who wish to view the original Markdown.

Because of differences in Markdown rendering engines, the best place to view the HTML is on the NIST Pages website at https://pages.nist.gov/800-63-3/ rather than the GitHub rendering of the documents.

While this is believed to be a faithful representation of the official PDF documents, NIST would appreciate being informed about any inconsistencies that may be found other than minor formatting differences. These may be reported to [email protected].

800-63-3's Issues

Not all out-of-band authenticators require presentation of secret back to primary channel

Organization: 2

Type:

Reference (Include section and paragraph number): 800-63-B Section 5.1.3

Comment (Include rationale for comment): The 1st paragraph of 5.1.3 describes a way that an out-of-band authenticator can work - in which a secret is sent via one channel and that secret is presented back to the primary channel. But that is only one way an out-of-band authenticator can work. OOB authenticators can also work by never asking the user to present anything directly back to the primary channel but instead use the secondary channel to communicate solely.

Suggested Change: Section 5.1.3 should be made more specific to say that if the OOB Authenticator requires the presentation of the delivered secret back to the primary channel then the existing text holds. However, if the OOB Authenticator communicates solely along the secondary channel then the system must be designed to ensure that the delivery as well as a proof-of-possession action is done so securely.

---

Organization: 1 = Federal, 2 = Industry, 3 = Other

Address confirmation - enrollment code expiration

Organization: 3

Type:

Reference (Include section and paragraph number): -A,4.5.5 Address Confirmation, 7th bullet point -
"Enrollment codes sent by means other than physical mail SHALL be valid for a maximum of 10 minutes; those sent to a postal address of record SHALL be valid for a maximum of 7 days."

Comment (Include rationale for comment): The 7-day maximum expiration for enrollment codes sent to a postal address of record seems reasonable for addresses within the 50 states, but it may deny access to the service to potential subscribers located outside the U.S. While the target audience includes subscribers to U.S. government services, many citizens reside or spend much time abroad, some in rather remote places.

Suggested Change: "... SHALL generally be valid for a maximum of 7 days but MAY be made valid up to 21 days via an exception process to accommodate addresses outside the direct reach of the U.S. postal service."

---

Organization: 1 = Federal, 2 = Industry, 3 = Other

Future-proofing key strength requirements

Organization: 3

Type:

Reference (Include section and paragraph number):
-C, 5.2.2 Shared Secret ("A 128-bit random symmetric key or equivalent strength asymmetric key ...")
-B, 5.1.4.1. Single Factor OTP Authenticators ("The secret key SHALL be a 128-bit or longer AES...")
-B, 5.1.6.1 Single Factor Cryptographic Device Authenticators ("The secret key SHALL be a 128-bit or longer...")
Others...

Comment (Include rationale for comment): Consider qualifying all such statements of key strength with a date after which the strength must be increased. NIST is better positioned than most agencies that will use this document to predict when a particular strength key is likely to no longer be strong enough due to advances in technology. The ability of NIST to update this document at a particular time in the future will only be partially within NISTs control -- subject to budget cuts, politics, new national priorities assigned to NIST, etc. Writing in an automatic increase may help protect against use of keys that have become weak. The timeline will also give agencies using the guidance helpful information for deciding whether to deploy new systems with stronger keys from the beginning if they expect the system life to extend beyond the date advised by NIST. Even if the strength increase date is 60 years out, such information is still helpful to readers as it will help them avoid investing effort to figure that out for themselves.

Suggested Change: Consider qualifying all such statements of key strength with a date after which the strength must be increased.

---

Organization: 1 = Federal, 2 = Industry, 3 = Other

Address Confirmation: Why email but not VOIP

Organization: 1

Type:

Reference (Include section and paragraph number): 800-63-A, Section 4.5.5,
•May be sent to a mobile telephone (SMS or voice), landline telephone, email, or physical mailing address verified records
•SHALL NOT be sent to any form of software-based (i.e., VoIP) telephone number.

Comment (Include rationale for comment):
If you are willing to accept a non-self-asserted email, why not software based VOIP? Both have similar properties of being able to login with relatively low security to a IP-based server to access the message.

Suggested Change:
Allow VOIP for address confirmation or remove email

---

Organization: 1 = Federal, 2 = Industry, 3 = Other

Conflict(?) between Gen Req 4.2.7 and and IAL3 Req 4.6.6

Organization: 2

Type:

Reference (Include section and paragraph number): General Req 4.2.7 states: The CSP SHALL record the types of identity evidence presented in the proofing process, including any identification and reference number. The CSP SHALL NOT record an image, scan, or other copy of the evidence.

IAL3 Req. 4.6.6 states: The CSP SHALL collect and record a current biometric (e.g., photograph or fingerprints) to ensure that the applicant cannot repudiate application.

Comment (Include rationale for comment): There seems to be an apparent conflict - under what circumstance/context should CSP capture or record an image, scan, or other copy of the evidence?

Suggested Change: Perhaps a rephrasing of the General Requirement 4.2.7 to allow for capturing or recording for satisfying specific IAL level requirements?

---

Organization: 1 = Federal, 2 = Industry, 3 = Other

section 4.5

4.5. Assurance Levels

The overall level of assurance is determined by combining the assurance levels for each of the components of the architecture. For instance, to achieve an overall assurance level of 3:

The enrollment and identity proofing process shall, at a minimum, use IAL 2 processes or higher.
The authenticator (or combination of authenticators) used shall have an AAL of 2 or higher.
Authentication assertions (if used) shall have an FAL of 2 or higher.

---

Recommend changing "overall assurance level of 3:" to overall assurance level of 2:

Suggestion: Move all definitions to separate document

Organization: 2

Type:

Reference (Include section and paragraph number):

Comment (Include rationale for comment): The definition sections appears in each document as Section 3 and reflects a great deal of overlap. Why not simply create 800-63-D for a consolidated definitions document?

Suggested Change:

---

Organization: 1 = Federal, 2 = Industry, 3 = Other

4.2.4 Reauthentication

Organization: 2

Reference (Include section and paragraph number): 4.2.4 - paragraph 1

Comment (Include rationale for comment): The text says, "Reauthentication MAY use one of two authentication factors if the AAL 2 requirements of Section 5.2.4 are met." There is no section 5.2.4.

Suggested Change: Update the reference, or include a section 5.2.4.

Is the homepage of the site also editable?

I found a grammar typo on https://pages.nist.gov/800-63-3/ that I wanted to submit a pull request for, but I can't find that text in this repository.

Map FAL to concrete protocols

Perhaps we should map the FAL to specific deployment choices of the example protocols in the appendix, to give developers a (non-normative?) hold on what we're expecting.

LOA 2 (non-pseudonymous) Invalid Mapping Combo

Organization: 1

Type:

Reference (Include section and paragraph number):
First Table within "Backwards Compatability to M-04-04 Levels of Assurance" Executive Summary in 800-83-3

Comment (Include rationale for comment):
The row for LOA 2 Non-Pseudonymous say IAL 2 and AAL of 1 which is an invalid combination in the very next table - "Acceptable IAL and AAL Combinations." Agencies that do an M-04-04 risk assessment and land on Risk Level 2 (non-pseudo) will expect to be able to use IAL 2 and AAL1, which does not appear to be what you want.

Suggested Change:
Change the AAL to 2. That way whether agency risk assessments land on Risk Level 2 or 3, IAL 2 and AAL 2 are required. This aligns with that short version of what I heard NIST wants to do: get rid of LOA 2.

---

Organization: 1 = Federal, 2 = Industry, 3 = Other

section 8 Security Attestation and Mitigation Strategies

Rivetz Corp.
Steven Sprague

Section 8.1 and 8.2

10's of millions of devices have been deployed both Mobile and PC that include technologies for secure display. This technology addresses the remote use of hardware credentials that are persistently inserted in a device for a session or are built into a device. Use of these authenticators AAL 1-3 credentials can be easily accomplished by a compromised endpoint device. Secure display and secure Input provide the assurance that a user confirms the use of their credentials and the event that is being confirmed or the attribute that is being released.
These technologies of secure Display are part of the Global Platform standards under trusted user Interface (TUI), Trusted Display has also been part of chipset architecture by most of the major manufacturers. However NIST has been surprisingly silent on the protections afforded by these mass market industry standard capabilities. There are 1 or two sentences in all of 800-63 that could point to these controls.
Example is a PIV card in a lap top can be remotely leveraged by simple capture of the PIN as a second factor and then any and all transactions can be sent to the device without the users knowledge. Simple use of secure display and secure pin entry would dramatically enhance the actual security of the authentication.

This begs a large and separate conversation on the ATTESTATION of the authenticator integrity and health at the transaction level. Cyber security controls for authenticators are a critical requirement as the complexity of systems continue to grow. 800-63 should not be silent on how authenticator integrity validation should be verified and when. Is it only at registration or is it consistently or monthly? the technologies of modern devices that will support AAL 3 are no longer fixed devices like smart cards but the foundations of dynamic security systems like trusted computing and trusted execution. The integrity of the authenticator is now possible and should be part of the registration process.

This is part of the Payment security directive 2 for the EU and the US should not be silent on it.

Unknown devices are at the heart of the failure of authentication while hardware tokens have made some progress a PIV card in a North Korean provisioned computer is not safe and every Mom knows that you should not log into your bank account from an internet café computer. All of the levels of assurance would benefit from the integration of known computers. With billions invested by industry in trusted computing and trusted execution technologies NIST continues to soft integrate this massive investment by industry. Mobile is a shift from Unknown computers that have users logged in to services delivered based on the identity of the devices with the user as an attribute of a device identity. Many organizations are already implementing various forms of device identity but very few have taken a step to shift to hardware protected credentials.

Suggested Change:

8.1 threat

Unknown host compute
description
the authenticator is activated by malicious code on the host system without the users knowledge and second factors are captured and reused without the users knowledge
Example
A PIV card is inserted and the pin is phished by keyboard logging software. Authentications are then remoted to the computer without the users knowledge as long as the PIV is inserted. This is also true of software held credentials.

AND

Authenticator Integrity compromise
An authenticator may have been modified by malicious software or hardware.
A trusted execution environment has malicious code that has penetrated the system and resulted in a change to the measured execution environment.

8.2 Mitigation
Duplication - ADD
Use hardware protection should be used when available for AAL 1 no FIPS 140-2 level 1 required and AAL2 if hardware meets FIPS 140 - 2 level 1
( EXPLICITLY STATING IT SHOULD BE USED WOULD PROVIDE GREAT GUIDANCE)

Unknown compute

Use authenticators that provide for isolation of input and or secure channels from external devices to assure secure collection of the users intent. (secure Pin pads, Biometric match on chip, TUI) and the use of secure display to assure the user is aware of the authentication or attribute that will be transmitted to the CSP or RP.

Leverage Device identity as a recommended component of User authentication so users on Unknown devices are not treated the same as users with known devices. Device identity could have a complete 800-63 infrastructure for levels of assurance of a known device.

Attestation of authenticator

Authenticator provides a real-time attestation of the integrity of the authenticator in the form of a has to be compared by the CSP or RP to a previously registered reference measurement. This does not have to be for the whole computer just the authenticator. Nist 800-147 and Nist 800-155 may eventually apply but to the subsystem not the whole device.

---

Organization: 1 = Federal, 2 = Industry, 3 = Other

Backwards Compatability to M-04-04 Levels of Assurance

Government of Canada

I may not understand the new model, plus I am testing out the comment capability here are my comments anyway.

Executive Summary

In the table showing the mapping back to M04-04 I see no difference between Level of Assurance 1 and 2 (pseudonymous)

Suggested Change:

I suggest that the table be simplified by combining Level 1 and Level 2(pseudonymous) and stipulating that Level 2 is non-pseudonymous.

You may wish to re-title the first column as Level of Assurance Requirement (or Assurance Level Requirement)

I am also concerned about the potential confusion between the different levels - I will look at this more closely.

Tim

SMS Deprecation

Organization: 1

Type:

Reference (Include section and paragraph number): 800-63-3B Section 5.1.3

Comment (Include rationale for comment): Deprecating SMS will prove challenging for organization implementations. SMS is already a hard sell to some customers so a code (OTP) via voice call had to be implemented. Other Out-of-Bands (OOBs) assume user has a smart phone and app installed, based on past experience assuming a customer has a phone capable of SMS (and is willing to use messages to login) is not a safe assumption. Said differently, this version of 800-63 is pushing 2FA while already planning to remove one of the primary means 2FA is done today.

Suggested Change: Reconsider stance on SMS deprecation for OOB.

---

Organization: 1 = Federal, 2 = Industry, 3 = Other

Second Address of Record?

Organization: 2

Type: Procedural

Reference (Include section and paragraph number): SP 800-63A Section 4.5.5

Comment (Include rationale for comment): In the last bullet of this section it states: "A notification of proofing SHALL be sent via a different address of record than the destination of the enrollment code."
I'm not sure I understand this. Can you give an example of a different address of record? Also, proofing is not defined in the glossary, I'm not sure what is being delivered here. My concern is that not every individual will have a 'second address of record'.

Suggested Change:

---

Organization: 1 = Federal, 2 = Industry, 3 = Other

RP shouldn't rely on 'expiration' to be accurate

Organization: 2

Type:

Reference (Include section and paragraph number): 800-63-C Section 5

Comment (Include rationale for comment): We should be teaching RPs to play stronger defense when it comes to claims, especially around expiration. Just because a claim includes an expiration doesn't guarantee that something hasn't happened in the intervening time to cause the CSP to expire the claim prematurely. RPs should be of the habit to check the validity of the claim and not rely upon expiration as the sole expression of validity.

Suggested Change: A small section on claim validity checking, potentially in Section 7

---

Organization: 1 = Federal, 2 = Industry, 3 = Other

Documents do not print

Organization: Altmode Networks

Type: Editorial

Reference (Include section and paragraph number): All sections

Comment (Include rationale for comment): Documents do not print (using Firefox on Mac)

Suggested Change: Looks like the style sheets (.css) or div or section tags need updating

---

Organization: 1 = Federal, 2 = Industry, 3 = Other 3

Document Naming

Organization:2

Type: Editorial

Reference (Include section and paragraph number): Title

Comment (Include rationale for comment): I recognize that you have asked us to hold back on the editorial comments, but I believe this is fundamental to tracking these documents over time. As currently named (SP 800-63-3, SP 800-63A, SP 800-63B and SP 800-63C), there is no linkage between the A,B,C documents and the base document. This will become an issue if there are future updates to the document suite. It needs to be kept clear that this 'A' goes with this 'B' goes with this '-3'

Suggested Change: Rename SP 800-63A/B/C to SP 800-63-3A/B/C

---

Organization: 1 = Federal, 2 = Industry, 3 = Other

Address Confirmation Requirement for IAL3

Department of Justice

Question

800-63-3A - Sections 4.5.5 and 4.6.5

In the previous iteration of 800-63, the address confirmation requirement only applied for remote identity proofing, and since LOA4 did not allow for remote proofing, there was no address confirmation requirement. Specifically, it states "Address of record shall be confirmed through validation of either the primary or secondary ID." (section 5.3.1, pg 35).

Is it the goal of this new version to add address confirmation as a new requirement for IAL3/LOA4 identity proofing, in addition to the in-person proofing? Would this potentially cause the PIV issuance process to not meet the IAL3 minimum requirements, as FIPS 201-2 does not require an address confirmation in addition to the in-person proofing?

Organization: 1 = Federal

Identity Proofing of Homeless Person

800-63-3A IAL2 and greater always requires address verification. Has any consideration been made about how someone who is homeless can be identity proofed? This has come on multiple occasions in various VA discussions regarding how a homeless Veteran could get a credential (http://www.va.gov/homeless/index.asp).

Guidance for determining threshold for system users that KBV questions should be applied to for ID Proofing

Organization: 1

Reference (Include section and paragraph number):

5.3.2. Knowledge Based Verification Requirements

Comment (Include rationale for comment):

The focus of identity proofing should not only be on the odds on creating a given fraudulent account for an individual, but should also include the odds of attacking the identity proofing capability of a system. In the context of attacking the entire user base using random answers, KBV could lead to successful compromise of the identity verification steps for IAL 2 and 3.

Suggested Change:

Thresholds of users should be determined when the probability of compromise of KBV doesn’t support the use of KBV. In cases where KBV must be used irrespective of user population, then compensating controls such as micro-deposits or sending a letter in the mail to the user’s official home of record shall be used.

---

Organization: 1 = Federal, 2 = Industry, 3 = Other

RPs are not always responsible for eligbility

Organization: 2

Type:

Reference (Include section and paragraph number): 800-63-A Section 4.2 Item 1

Comment (Include rationale for comment): Item 1 states that identity proofing shall not be used to determine eligibility which is fine. But Item 1 goes on to say "The RP, not the CSP, is responsible for collecting and validating information for access control purposes" which is not universally true especially for federated systems. The CSP/IDP is very often in charge of which users can access which resources and the RP simply awaits an isAuthenticated signal from the IDP.

This has further implications in Item 5. A CSP/IDP very often uses collected information to determine appropriate authorizations.

Suggested Change: Strike the 2nd sentence of Item 1 and reword Item 5 accordingly

---

Organization: 1 = Federal, 2 = Industry, 3 = Other

Missing definition: side-channel attack

Organization: 2

Type: Omission

Reference (Include section and paragraph number): 800-63-3 Section 3

Comment (Include rationale for comment): If you are going to include on and offline attacks, you probably also want to include side-channel as well.

Suggested Change:

---

Organization: 1 = Federal, 2 = Industry, 3 = Other

The veracity of a micro-deposit is only as good as the strength of a financial institution’s identity proofing system.

Organization: 1

Reference (Include section and paragraph number):
5.3.2. Knowledge Based Verification Requirements

Comment (Include rationale for comment):
A fraudster opened up several checking accounts with “overdraft protection” through a financial institution online in my wife’s name. The fraudster made a mistake in opening some of the accounts that made us aware of the fraud, but the financial institution was totally unaware of any fraud until she notified them. Needless to say, the accounts were opened for several days—possibly enough time to commit fraud against a system using micro-deposits. She talked to the security group of the financial institution and they informed her that the fraudster knew her basic information, e.g. name, DOB, SSN etc., but according to the security team, no KBV type questions were asked. Because of this, she now has her credit locked.

Therefore, any government system that will place a reliance on micro-deposits must be aware of the above risk. The veracity of a micro-deposit is only as good as the strength of a financial institution’s identity proofing system. That being said, it is next to impossible for any government system owner to determine whether a micro-deposit is trustworthy or not without having a proper understanding of the identity proofing system of the financial institution. Moreover, we naturally focus on U.S. systems, but what happens in the case where a foreign bank is used?

It would seem to me that NIST 800-53 Rev 4 Security Control AC-20 Use of External Information Systems, “b” is applicable to micro-deposits. AC-20 “b” states “Process, store, or transmit organization-controlled information using external information systems.” In this case the organization-controlled information is the micro-deposit, but the reliance of the proofing mechanism isn’t the micro-deposit, but the reliance on the financial institutions identity proofing system that makes the financial account valid.

So in summary, the larger issue is, when a government system relies on a none-government system or any other government system for that matter for evidence of any kind for identity proofing individuals, the evidence produced by the system is only as strong as the identity proofing of that external system.

Suggested Change:
CSP MAY need to determine the IAL of a financial institution’s identity proofing system and the security controls of the proofing system that are implemented before allowing micro-deposits to be made to the financial institution that is to be used as a security control by the CSP for its identity proofing.

Note: I struggled with using MAY and SHOULD instead of SHALL because it is probably beyond the resources of any one agency to vet all financial institutions' methods of identity proofing that an agency may wish to use micro-deposits with in order to support the agency’s identity proofing of individuals. IMO, AC-20 is applicable but in reality it probably isn’t feasible to apply across every financial institution. Guidance on foreign banks should also be provided.

---

Organization: 1 = Federal, 2 = Industry, 3 = Other

IAL2 requires Trained Personnel and cannot be automated

Organization: 1

Type:

Reference (Include section and paragraph number): 800-63A, Section 5.2.2.1. Methods to Perform Identity Evidence Validation
"Strong" row in the table

Comment (Include rationale for comment):
IAL 2 requires at least on piece of Strong evidence. The requirements for validating Strong evidence state:

• The evidence has been confirmed as genuine by trained personnel and appropriate equipment, confirming the integrity of the physical security features OR The evidence has been confirmed as genuine by confirmation of the integrity of cryptographic security features.
  AND
  • All personal details and evidence details have been confirmed as valid by comparison with information held/published by the issuing source OR evidence details have been confirmed as valid by comparison with information held/published by the issuing source.

Assuming the transaction is remote and the evidence doesn't include cryptographic security feature (which I think is safe to assume is the vast majority of cases), you are requiring a "person" to look at an image/video (video is a series of images).

Suggested Change: Allow IAL 2 to be automated (no trained personnel required to look at each piece of Strong evidence).
Also, I suggest that requiring agencies to receive and analyze images of identity documents is relatively prescriptive. It makes me wonder what evidence NIST has to drive all agencies to these technologies.

---

Organization: 1 = Federal, 2 = Industry, 3 = Other

800-63-3 / sp800-63-3 / sec1_2_introduction.md

Organization: 1

Conducting risk assessment : I think this guidance need to give more specific guidance on risk assessments methodologies. The risk assessment method is giving to agencies and suggesting to map the risks to specific assurance levels. If risk assessment is not solid as at this stage assessors may not have good understand the limitations of technologies used during implementation. There is potentially mapping the risk to assurance levels may not be accurate.

This does refers to NIST Special Publication (SP) 800-30 .

Organization: 1 = Federal, 2 = Industry, 3 = Other

Throttling should be at the discretion of the verifier

Organization: 2

Type:

Reference (Include section and paragraph number): 800-63-B Section 5.1.1.2

Comment (Include rationale for comment): Currently 5.1.1.2 requires a verifier to implement memorized secret guessing throttling. Both the number of guess and the time period are arbitrary. The verifier should be able to specify their own intervals and thresholds. Furthermore, referenced section 5.2.2 opens with "MAY" and not must. There is an internal inconsistency problem.

Suggested Change: End the sentence at the word "account."

---

Organization: 1 = Federal, 2 = Industry, 3 = Other

Where are the definitions of the FALs?

Organization: 2

Type:

Reference (Include section and paragraph number): 800-63-3

Comment (Include rationale for comment): The concept of FAL is raised but in no subsequent document is it spelled out in greater depth. Where can we find what FAL1-3 mean?

Suggested Change: Add FAL to 800-63-C

---

Organization: 1 = Federal, 2 = Industry, 3 = Other

SHALL not SHA-ll

Organization: 2

Type:

Reference (Include section and paragraph number): 800-63-A Section 4.3 Item 2

Comment (Include rationale for comment): Incorrect capitalization

Suggested Change: SHAll should be SHALL

---

Organization: 1 = Federal, 2 = Industry, 3 = Other

5.1.3.1 adding trusted hardware to the example list

Organization:

Type:

Reference (Include section and paragraph number):
5.1.3.1

Comment (Include rationale for comment):
For many years industry has shipped 100's of millions of TPMs and TEE devices they should be articulated in the list of examples for "the key should be stored in the most secure storage"
Suggested Change:

Authentication to the verifier using approved cryptography. The key SHOULD be stored in the most secure storage available on the device (e.g., keychain storage, or trusted platform module or trusted execution environment if available).**

Organization: 1 = Federal, 2 = Industry, 3 = Other

usnistgov/800-63-3

Organization:1

5.3.2. Knowledge Based Verification Requirements

800-63-3 / sp800-63a / sec5_proofing.md

I am surprised to see Knowledge Based Verification Requirements in the this draft. KBV/KBA refers to asking "secret” questions that only applicant can supposedly answer to prove their identity for remote identity proofing/authentication.
In my opinion KBV/KBA is less effective as a verification of identity especially with growing
number of data breaches. It is no longer an effective method. It is not good idea to use KBV/KBA for IAL 2/IAL3. it is possibly can be used for IAL 1.

I like to see some alternatives to Knowledge Based Authentication/Verification in this draft.

Clarification on whether a table or a grid card look-up secret authenticator’s cell shall only be used successfully once with respect to lookup

Organization: 1

Reference (Include section and paragraph number):
5.1.2.2. Look-up Secret Verifiers

Comment (Include rationale for comment):
5.1.2.2 states: A given secret from an authenticator SHALL only be used successfully only once; therefore, a given authenticator can only be used for a finite number of successful authentications.

It is not clear how this requirement would apply to a look-up table/grid card. If a cell is used just once, than only the remaining set of unused cells can be used for authentication. If the requirement is referring to a specific grouping of cells that are used for authentication that can only be used once, then that could be difficult to track. For example, if one has a 50 cell look-up table and is required to enter values from 3 cells, then the look-up table can only be used 16 times. If cells are allowed to be used more than once, then a finite number wouldn’t be practical to track based on groupings. Limits on the number of times the table/card is used would possibly be more advisable.

If the intent is that a cell only be used once, then please provide clarity. If the intent is that a cell maybe used more than once, please state and provide guidance on lifetime of use.

Suggested Change:

Clarify whether the requirement above applies to look-up tables/grid cards. If the requirement does apply to look-up tables/grid cards, clarify if a given cell can only be used one time or multiple times and how often the look-up table/grid card should be changed.

Organization: 1 = Federal, 2 = Industry, 3 = Other

CSP Risk Mitigation Measures

Organization: 2 Industry

Reference (Include section and paragraph number): 800-63A Section 4.2, second enumerated list:
1.If the CSP employs risk mitigation measures, the agency SHALL conduct a privacy risk assessment of these mitigation measures. Such assessments should include any privacy risk mitigations (e.g., limited retention, strict use limitations, notice, etc.) or other technological mitigations (e.g.,cryptography).The CSP SHALL NOT apply additional risk-based approaches without providing explicit notice of such approaches.

Comment (Include rationale for comment):
If the CSP employs risk mitigation measures (a good thing), then that imposes additional responsibilities on the agency or other relying party (a bad thing). This might encourage agencies/RPs to favor CSPs that do not employ risk mitigation measures.
What are “risk-based approaches”? Do you mean the same thing as the earlier use of “risk mitigations”? Or something else? Could you provide an example?

Password Entropy Recommendation

Organization: Idaho National Laboratory

Type:3

Reference (Include section and paragraph number): SP 800-63b, Appendix A, section 3 "Password Complexity"

Comment (Include rationale for comment):
I like how the document pushes back on the idea of requiring the use of specific charter types and periodic changes. I agree that these were inadequate however, they were an attempt to ensure minimum password quality and the current document outlines little to replace it.

Suggested Change:
Consider adding a recommendation for organisations to measure and set minimum entropy bit threshold for passwords. where "entropy bits" is log2 of the maximum number patterns based on the characters and length of a given password.

Obviously, this could be considered outrageous as a requirement but as a suggestion it should encourage the industry down this path.

---

Organization: 1 = Federal, 2 = Industry, 3 = Other

Add TLS language to assertion presentation

The assertion and federation section should require TLS or equivalents on all the links.

Change from e-authentication to d-authentication

Digital authentication is the process of establishing confidence in user identities digitally presented to an information system. Digital authentication presents a technical challenge when this process involves the authentication of individual people over an open network for the purpose of digital government and commerce.

Respectfully recommend using electronic authentication (e-authentication) instead of the term digital authentication (presumably d-authentication) for historical continuity. Creation of a new term will cause confusion in those relying on the NIST standards (unless there is a good reason to distinguish the terms).

Annotate risk of use of Multi-Factor Software Cryptographic Authenticator

Organization: 1

Reference (Include section and paragraph number):
4.2.1. Permitted Authenticator Types

Comment (Include rationale for comment):
Of the multi-factor authenticators (MFA) listed, Multi-Factor Software Cryptographic Authenticator (MFSCA) is the only multi-factor authenticator that can be totally compromised on the host from which a transaction is initiated, e.g. workstation, laptop, etc. Depending on the transactions involved and risk profile of the hosts, one may determine that using a MFSC is not recommended and should defer to some other form of MFA.

Suggested Change:

Suggest entering a footnote stating that MFSCAs can be susceptible to compromise by malware and that CSPs should perform a risk assessment to determine the risk of the use of MFSCAs based on the expected level of security of a host.

Organization: 1 = Federal, 2 = Industry, 3 = Other

SP 800-63B(r3) uses imprecise length constraints in §5.1

Organization: NASA

Type: 1

Reference (Include section and paragraph number): SP 800-63B(r3) §5.1 multiple locations

Comment (Include rationale for comment):
There are quite a few length constraints of the sort "…Memorized secrets SHALL be at least 8 characters in length…". This, coupled with the inclusion of Unicode (§5.1.1.2), will result in problems when characters are conflated/confused with other things such as octets, bytes, glyphs, symbols, and character encoding schemes.
E.g., the passphrase «डबल गोप्य» occupies 25 octets when encoded as UTF-8.

Suggested Change:
Specify length constraints in octets or some other suitably precise unit independent of any character encoding. Eschew assumption or explication of character encoding schemes (unless one wishes to don the hair shirt of normalization specification).

Conflicting statements between 4.2 General Requirements 3, 7 and 9

Organization: 1

Reference (Include section and paragraph number):
4.2 General Requirements

Comment (Include rationale for comment):
Requirement 3 states: “The CSP SHALL provide explicit notice at the time of collection to the applicant regarding the purpose for collecting and ‘maintaining a record’ of the attributes necessary for identity proofing, including whether the such attributes are voluntary or mandatory in order to complete the identity proofing transactions and the consequences for not providing the attributes.”

Requirement 7 states: “The CSP SHALL record the types of identity evidence presented in the proofing process, including any identification and reference number. The CSP SHALL NOT record an image, scan, or other copy of the evidence.”

Requirement 9 states: “The CSP SHALL conduct a privacy risk assessment to determine what PII is necessary to maintain a record of for identity proofing. The CSP SHALL maintain such records in accordance with National Archives and Records Administration (NARA) records retention schedules or agency specific schedules as appropriate.”

Requirement 3 reads as if copies of documents such as notary documents, possibly fingerprints, driver’s license, etc. can be used to proof an individual and made part of a record, but Requirement 7 reads as if you can’t make a record when it states “The CSP SHALL NOT record an image, scan, or other copy of the evidence.” Requirement 9 seems to rebut Requirement 7. I can possibly see not collecting some of this information when proofing is performed. It also begs the question with respect to fraudulent documents, if one doesn’t have a copy of evidence, how can one determine the veracity of the evidence if it comes into question at later point in time or a subscriber refutes being identity proofed?

This NIST presentation http://csrc.nist.gov/groups/SMA/forum/documents/feb2012_nist-sp-800-63-1_newton-perlner.pdf seems to support the above. “RA records a current biometric (e.g., photo or fingerprints) to ensure that Applicant cannot repudiate application.”

I believe clarification is needed with respect to the above.

Suggested Change:
Delete “The CSP SHALL NOT record an image, scan, or other copy of the evidence” from Requirement 7 and make the first sentence of Requirement 9 the second sentence of Requirement 7 so 7 reads as follows:

“The CSP SHALL record the types of identity evidence presented in the proofing process, including any identification and reference number. The CSP SHALL conduct a privacy risk assessment to determine what PII is necessary to maintain a record of for identity proofing.”

“The CSP SHALL maintain such records in accordance with National Archives and Records Administration (NARA) records retention schedules or agency specific schedules as appropriate.”

Organization: 1 = Federal, 2 = Industry, 3 = Other

FIPS Level clarification for AAL 2 authenticators

Organization: 1

Type:

Reference (Include section and paragraph number): 800-63-B, Section 4.4 Summary of Requirements, FIPS 140 Verification Row, AAL 2 Column

Comment (Include rationale for comment):
The cell says:
Level 1 (single factor),
Level 2 (multi factor

However Multi-Factor Software Cryptographic Authenticator should be FIPS 140 Level 1 pretty much be definition (Software) - even though it is "multi-factor"

Suggested Change:

Change to:
Level 1 (Software)
Level 2 (Hardware)

---

Organization: 1 = Federal, 2 = Industry, 3 = Other

Alternate purpose for collecting attributes

Organization: 3

Type: Deconflict statements

Reference (Include section and paragraph number): -A, section 4.2 (General Requirements), point #5 - "The CSP SHALL NOT use attributes collected and maintained in the identity proofing process for any purpose other than identity proofing and authentication or to comply with law or legal process (to include federated authentication). The CSP SHALL provide clear notice and obtain consent from the subscriber if the attributes are to be used for any other purpose."

Comment (Include rationale for comment):
The condition (attributes being used for a purpose other than identity proofing and authentication) that would trigger the action required in the second sentence ("The CSP SHALL provide clear notice..") is prohibited by the first sentence. The existence of the second sentence undermines the requirement in the first one.

Suggested Change: Eliminate the second sentence, or change SHALL NOT to SHOULD NOT in the first sentence.

---

Organization: 1 = Federal, 2 = Industry, 3 = Other

Recording identity evidence

Organization:2

Type:Procedure

Reference (Include section and paragraph number):SP 800-63A Section 4.2 (7)

Comment (Include rationale for comment):
"The CSP SHALL NOT record an image, scan, or other copy of the evidence." So, a drivers license can't be copied? This goes against current practice for PIV/PIV-I identity proofing, and in industry. Can you provide a rationale for this prohibition?
Suggested Change:

---

Organization: 1 = Federal, 2 = Industry, 3 = Other

General Requirement #13 - Entire Identity Proofing Session over Mutually Authenticated Session

Organization: 1

Type:

Reference (Include section and paragraph number): 800-63-A, Section 4.2, bullet 13

Comment (Include rationale for comment):
Regarding: 13.The entire proofing transaction, including transactions that involve a third party, SHALL occur over mutually authenticated protected sessions.

Can you clarify? I assume that you don't mean that the user has to have a mutually authenticated TLS session with the CSP, since they don't have an authenticator yet. That would be good for use with third party services (e.g., credit bureau), but the user is a major part of the id proofing transaction.

Suggested Change:
Clarify

---

Organization: 1 = Federal, 2 = Industry, 3 = Other

The number of KBV questions needs to be increased to a minimum of 5 questions

Organization: 1

Reference (Include section and paragraph number):

5.3.2. Knowledge Based Verification Requirements

Comment (Include rationale for comment):

The bullet “A CSP SHALL require a minimum of four (4) KBV questions each requiring a correct answer to successfully complete the KBV step” of four questions is too low.
Allowing too low a number of possible questions increases the success against attacking the identity proofing capability of the system, not a given individual, when performing identity proofing. For example, the odds of guessing the correct answers to all five questions is 0.032% (0.2^5) when using 5 answers per question. A system that has 100 million users and requires 5 questions with five answers per question to be answered correctly has the potential of 32,000 fraudulent registrations.

A system that has 100 million users and requires 4 questions with five answers per question to be answered correctly has the potential of 160,000 fraudulent registrations. These numbers do not take into account that each account can be attacked twice or the possibility that a fraudster may already know some of the answers to questions.

Random guessing for four questions with four answers per question could lead to 390,625 fraudulent registrations. The odds of guessing the correct answers to all four questions correctly is 0.390625% or of (.25^4). Fraudulent registration is based on a user base of 100 million users and only having the questions asked once—not twice. Using the above for 100,000 user system, divide fraudulent registration numbers by 1,000.

Suggested Change:

Change the requirements for questions to “A CSP SHALL require a minimum of five (5) KBV questions each requiring a correct answer to successfully complete the KBV step.”

---

Organization: 1 = Federal, 2 = Industry, 3 = Other

5.2 add a general section on attestation

Organization:

Type:

Reference (Include section and paragraph number):
5.2

Comment (Include rationale for comment):
While government always like talk about the Public Private partnership the lack of attention in 800-63 for trusted computing is truly amazing.

The problem is that the only assurance model for hardware is Fips 140-2 and it's failure to adapt to the new framework of TPM and TEE embedded hardware has resulted in little use of these really valuable authentication technologies. There is not one example of TPM throughout all of this document but there is a bunch on PIV, Biometrics and OTP Just one example in the doc of TPM would probably be a good idea.

Suggested Change:
Add a section on attestation to the health and integrity of the hardware device and it's capabilities. The verifier should be able to verify that the authentication but also play a role in the Cyber security controls. In the modern model of cloud computing with remote users it is not clear that the network will be able to provide these cyber security measures. For a distributed user base verification of the attestation of the hardware as a self test performed by the hardware would lay the foundation to integrate cybersecurity controls on distributed authentication events. The concept that there should be velocity controls is very cool but their also should be Cyber security controls. Known authentications coming from Known devices in a Known condition. It is simple to integrate into a Multifactor authentication and would add tremendous value for the systems that can support it.

In general hardware protection of keys should be used if available regardless of FIPS 140- 2 certification level it will enhance an AAL1 if used.

---

Organization: 1 = Federal, 2 = Industry, 3 = Other

Apparent conflict for In-Person Proofing requirement for IAL3

Department of Justice

Requirement Conflict

800-63-3A, Sections 4.3 and 4.6
Section 4.3 - "At IAL 3, identity proofing SHOULD be performed in person. 'Virtual in-person' identity proofing MAY be employed by a CSP as an equivalent process to in-person identity proofing."
Section 4.6 - "In addition, identity proofing at IAL 3 SHALL be performed in-person."
Section 4.6.1 "The CSP SHALL perform identity proofing in-person."

There is a clear conflict between SHALL (must be done) and SHOULD (course of action is preferred but not necessarily required) in these sections. I think I understand where section 4.3 is going (promoting a virtual in-person option with specific requirements), but this type of conflict between requirement and recommendation in different sections will cause issues.

Additionally, the title of section 4.3 is In-person Proofing Requirements, but it is clearly focused on introducing the virtual in-person option.

Recommendation
The requirement language should be aligned between sections. If this virtual in-person is a true option for IAL3, it should be reflected in 4.6. Also recommend section 4.3 remove IAL3 requirement language and just be a definition of the in-person AND virtual in-person proofing requirements (potentially in separate subsections), and the section header adjusted to reflect it's content.

---

Organization: 1 - Federal

IAL and AAL Summary

Organization:
2
Type:
Nomative
Reference (Include section and paragraph number):
IAL and AAL Summary
Comment (Include rationale for comment):
Level 1 may not contain any attributes
Suggested Change:

At this level, attribute may be provided in conjunction

Organization: 1 = Federal, 2 = Industry, 3 = Other

No minimum number of possible answers to KBV questions specified

Organization: 1

Reference (Include section and paragraph number):
5.3.2. Knowledge Based Verification Requirements

Comment (Include rationale for comment):

The bullet “A CSP MAY perform KBV by asking questions of the claimed identity to demonstrate they are the owner of the claimed information” must be updated to include the number of answers per question. Currently there isn’t a requirement for the number of answers per question. Allowing too low a number of possible answers increases the success against attacking the identity proofing capability of the system, not a given individual, when performing identity proofing. For example, the odds of guessing the correct answers to four questions is 0.3906254 (0.25^4) when using 4 answers per question and 0.16% (0.2^4) when using 5 answers per question. In the context of an attack against an individual it seems low, but an attack against the identity proofing capability of a system can lead to high number accounts being created. Impact is greater on systems that have potentially millions, 10s or 100s of millions of users. If an attacker has information related to the questions, his odds improve.

Suggested Change:

“A CSP SHALL require a minimum of five (5) answers per KBV question.”

---

Organization: 1 = Federal, 2 = Industry, 3 = Other

4.2.4. Reauthentication in federation scenarios

Organization: 2

Reference (Include section and paragraph number): 4.2.4 - paragraph 1

Comment (Include rationale for comment): I was hoping that either 800-63B or 800-63C might provide some additional guidance about reauthentication requirements in federation scenarios, but I couldn’t find any. For example: if after 30 minutes of inactivity (or after 12 hours since the RPs session was created) the RP sends the user to the CSP with a request for assertion, and the user still has a valid session at the CSP, it’s common practice for the CSP to generate a new assertion for the subscriber without reauthenticating the subscriber. Would that assertion meet the RP’s reauthentication requirement? Would the CSP be required to have the same 30 minute inactivity and 12 hour limits? What about in brokered/proxied federation scenarios - if both the CSP (where the user conducts the primary authentication) and the broker have 12 hour session maximums, then the RP could receive a fresh assertion based on the user's primary authentication that occurred up to 24 hours ago.

Suggested Change: In either 800-63B or 800-63C provide some guidance around reauthentication in federation scenarios. I think a Reauthentication section in 800-63C might be best.

4.5 Assurance Levels: Reach Level 3 with IAL=2, AAL=2, FAL=2 ?!

Organization: 1

Type:

Reference (Include section and paragraph number): 800-63 Section 4.5 Assurance Levels

Comment (Include rationale for comment):
For instance, to achieve an overall assurance level of 3:
•The enrollment and identity proofing process shall, at a minimum, use IAL 2 processes or higher.
•The authenticator (or combination of authenticators) used shall have an AAL of 2 or higher.
•Authentication assertions (if used) shall have an FAL of 2 or higher.

Suggested Change:

Change 3 to 2

Organization: 1 = Federal, 2 = Industry, 3 = Other