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
Proposed Agenda
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.
Minutes Approval
Jimmy Jung moved to approve the draft minutes from the July 13th IAWG meeting. Mark Hapner seconded the motion. Motion carried with no objections.
Kantara Updates
Andrew informed the group that the Deepfakes DG is up and running. He is arranging the first meeting and will send out a notice - hopefully to meet next week. The goal is to draft a report or two on the nature of the threat, what is real v. what is myth, and potentially a primer on what exactly is going on in the real world. Additionally, include some techniques and counter-measures that customers might want to ask their IDV providers. More information on the group can be found on their wiki page and anyone can join the group by completing the Kantara Group Participation Agreement.
The Board is continuing with regular activities. Initiatives started around review of Kantara governance structures, member engagement/recruiting, and the DEIA survey and sub-committee.
Lynzie shared that the Survey Monkey results for the time of this meeting has been inconclusive - so if you have an opinion on the time of the meeting and you are a voting member of the IAWG, please vote.
Assurance Updates
NIST held a meeting last week to talk about next steps regarding revision 4. During the meeting it was shared that 63A, 63C and the Base Volume would all likely be released for a second round of public comment in 2024 Q1. 63B received several comments but nothing that NIST felt warranted another round of public comment. 2024 Q2 is the absolute earliest we can expect revision 4 to be officially published, leading to a 2025 implementation date for feds.
Discussion:
800-63-3 Criteria Issues
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
During the last call it was decided to review these criteria and make a determination on which criteria can remain applicable to IAL2 and IAL3, and which criteria need to be applicable to IAL3 only. It was suggested by Andrew to hold off on this until later in the call - or we would assign a group to do the work outside the call and present it at the next call.
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].
Richard questioned if there is anything wrong with the criteria? Andrew noted that the CSP is pointing out that the clause is conditional - and if you do it, then there are mandatory requirements. We’ve taken out the conditionality - we essentially changed it from “verifiers should perform” to “verifiers shall perform.” Richard noted this is just another case where we may have went more rigorous than NIST. Andrew and Jimmy both questioned - are there two salts? Or is there only one salt? Are we only supposed to store one of the salts - the second one? Jimmy noted the language is not updated in revision 4 so it doesn’t look like they’ve made any updates. Andrew suggested emailing NIST for this clarification. Richard asked if this is problematic for CSPs or if they are just doing it - Jimmy feels like it is likely problematic for some CSPs. Lynzie agreed as this was brought to her attention by a CSP having issue with it. Andrew summarized we need to ask - Are there two salts or only one salt being discussed in 5.1.1.2? Did you mean there should be two salts? Jimmy thinks they may not have meant to suggest you only store one of the salts.
Richard noted we can re-write this if needed once we get a response.
Any Other Business
n/a