Attendees:
Voting Participants: Andrew Hughes [Ping], Jimmy Jung [Slandala], Mark Hapner, Martin Smith, Richard Wilsher [Zygma], Mark King, Chris LaBarbera [Verizon], Zaid AlBukhari [NextGenID]
Non-voting Participants: Mike Magrath [Easy Dynamics], Jazzmin Dowtin [IDEMIA]
Staff: Lynzie Adams, Kay Chopard
...
Administration:
Roll call, determination of quorum
Minutes approval
Kantara updates
Assurance updates
Discussion:
800-63-3 Criteria Issues to Resolve - finalize plan for 63A work; move on to 63B updates.
Any Other Business
Meeting Notes
Administration:
IAWG Chair Andrew Hughes called the meeting to order. Roll was called. Meeting was quorate. He welcomed Chris & Zaid, new IAWG voting members.
...
The group continued to work through issues raised from ARB, assessors, etc that must be resolved. Notes are in the document as well.
63A#0490 - #0580
| View file | ||
|---|---|---|
|
...
Jimmy believes #0520-0580 should all be IAL2 only as intended by NIST in rev 3 (and rev 4), though he raised an additional issue with #0510. If you are doing supervised in-person proofing, you would not need to fulfill the biometrics criteria referenced in #0510. Biometrics would only be used in supervised remote proofing - and unsupervised, which is being left out in this criteria. Jimmy believes it’s the one that focuses most on biometrics. Richard shared that the reference to the biometric criteria in the T5-3 table applies to every mode of proofing, so unsupervised would be covered there. Andrew thinking #0510 is okay the way it is because of this. This conversation will be considered when the small group reviews the larger review of #0490-0580.
This was not revisited during the call and will be reviewed at the next call.
T5-1 Table
Lynzie shared the response from the ARB was positive when she shared the IAWG’s plan for the T5-1 table. The NIST rep commented that the supplemental guide is intended for this type of purpose. The ARB asked the IAWG to consider the criteria that handled how the CSP dealt with the evidence - beyond just the level of strength (primarily 63A-T5-1#fair c&d and the replicated criteria in strong & superior). Richard believes that everything in Table 1 has to do with the characteristics & qualities of the evidence. Does that form of evidence meet these requirements. The thought that the CSP is collecting the evidence is a misleading statement and it's possibly misleading wording by NIST. There is nothing being physically collected. Andrew believes NIST’s language accurately portrays that and that it’s Kantara’s language that is fuzzy. It was suggested to remove the words “collected by the CSP” from each of the criteria in T5-1 (reverting to NIST language). With this change, Lynzie will draft the memo to make this change more immediate than the full update to all SACs.
63B #0030
ARB suggested that this should not be for federal agencies only - that this is applicable to to any PII and should therefore be applicable to all categories (CSP & Fed Agencies). Richard noted that it is the NIST text that says “Agencies SHALL select…” Andrew noted that Agencies are directed to skip the risk assessment process and just use AAL2. If you are not an Agency and your risk assessment indicates something else, then you should use that. Richard noted that the requirements to do risk assessments do not exclude Agencies. If a CSP is selling a service to an Agency and they want this - it would be a contractual requirement. The danger of putting a tick in the CSP column is we are then requiring it for every CSP. After a short discussion, it was decided to leave this as-is and not update.
63B #0550
The group discussed if we should replace the word “randomly-chosen” with “unique” as suggested. It was decided not to make this update. As for the second bullet point, the group agreed the wording can be confusing. Richard suggested deleting the text “for each subscriber using a memorized secret authenticator.” Andrew & Jimmy agreed.
63B #0570
Richard feels it is a hard requirement because it says “SHALL store,” and that Kantara chose to not make requirements for SHOULDs or MAYs in the text. Mike asked if that point is captured anywhere - that only SHALLs are enforced and have corresponding criteria - either in the User’s Guide tab or elsewhere? Richard believes at one point that was the case, but it’s been potentially lost over the years. Mike suggested it going in the Assessor Accreditation Handbook and the User’s Guide - Richard noted in the Service Approval Handbook is likely a better place than the Assessor Accreditation Handbook. The group liked this idea and it will be added to the updated versions of the SACs. Lynzie will work on incorporating it into a new version of the SAH.
Andrew asked what is the difference between #0550 and the text quoted below by the CSP asking the question. #0550 says “secrets shall be salted and hashed” and then Section 5.1.1.2 says “verifiers should perform additional key derivation using the salt.” Is that the same salt? And secret? In 5.1.1.2, is the function a key derivation function or hashing function on the secret? Richard noted #0560 envokes the two standards referenced in 5.1.1.2, but it’s a SHALL that is conditional in the NIST text. The way it’s written in #0560 it’s imperative and applies to any salt value - not to an additional iteration. Andrew asked if the hashing being discussed is a key derivation function? Jimmy noted it all starts back at #0550 with “using a suitable one-way key derivation function”. Andrew summarized - NIST starts with perform salt & hash with a one-way key derivation function, then they refer to one-way key derivation functions as salting and hashing, and then they return to key derivation. So the hashing is a one-way key derivation function. Mark King noted it would not necessarily produce a key.
NIST Text: In addition, verifiers SHOULD perform an additional iteration of a key derivation function using a salt value that is secret and known only to the verifier. This salt value, if used, SHALL be generated by an approved random bit generator [SP 800-90Ar1] and provide at least the minimum security strength specified in the latest revision of SP 800-131A (112 bits as of the date of this publication) [#0560].The secret salt 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 salt value remains secret [#0570].
...