2024-06-27 IAWG Meeting Notes DRAFT

quorate

Ready for review

TBD

Eballot results and update on next steps

1. There is  strong pushback from Kay and ARB regarding what happens next as a result of these changes.  Andrew Hughes in negotiations with staff as the discussion is tangled around the idea that Kantara’s trustmarks and criteria are  designed around NIST 863 structures.

2. This is loosely tied to the idea of components (which in theory, are no problem) but the difficulty comes in what we call an IAL2 component.

3. Criteria 63A#0180-One statement was split into different parts, which seems OK.  The challenge from ARB stems from the thought that if the service provider chooses specific permutations in their SoCA of these criteria, they could end up with a service that doesn’t do what IAL purports to do, because the service isn’t dealing with all of the evidence that must be dealt with in scope of the assessment.  It can’t be called IAL2 unless it processes all of the evidence needed as envisioned by NSIT (one strong and one fair piece of evidence is not IAL2).  So the trustmark is impacted and this is a material change (not immaterial).  

4. Jimmy: Components systems also don’t write a practice statement (because they don’t know the full, larger system), which is allowed through.

5. All are in agreement on the need to support components.

6. Hughes:  If the receiving customer of the components is trying to be (NIST-style) CSP, then they should apply to be a full CSP.  

7. Jimmy:  This isn’t something that can be enforced.  We can only offer assurance that the component works as intended.

8. Richard:  Nothing mandates that something has to be Kantara approved before becoming IAL2 (Example: An organization wants to provide a component service and it is assessed by a Kantara Assessor as meeting the criteria which apply to the scope of the component functionality.  Kantara stops at their approval of this.

9. Andrew Hughes:  “IAL2” shouldn’t be used for those cases, as it’s misleading.  The problem is with our branding. Within the NIST structure, it’s always going to be difficult to describe things.

10. Richard: The branding says “IAL2 component”.

11. Eric Thompson:  How is that the conversation regarding the recent criteria changes (separating the evidence into different elements) and component services is different from 63A#0450-enrollment codes and being an IAL2 component service?  Experian doesn’t do enrollment codes (which is part of IAL2) but they go through the identity proofing process.

12. Andrew Hughes:  The design of the program is to use the NIST terminology IAL2, which carries certain requirements. If you don’t include all the essential pieces, you can’t achieve IAL2 .

13. Jimmy: Any component is not going to achieve that.

14. Andrew Hughes: Thus the trustmarks need to be renamed.  The problem still exists where ARB will likely not see a provider as being IAL2 with the current criteria changes.

15. Jimmy:  Applicants have sought certification where they meet 4 pieces of criteria (either IAL2 or IAL3, or both) and that’s OK.  So what Jimmy is hearing from Andrew’s concerns is that there are no longer IAL2 or IAL3 components, there are only components?

16. Yehoshua:  NIST criteria can be broken down into components.  So isn’t what we are highlighting a discrepancy between the way things should be working and the way they are actually working?

17. Roger:  Is there a description articulating the differences between full service and component?  This could be helpful when continuing this topic.  

18. Andrew/Jimmy:  The definitions didn’t get updated on the website, but there is a glossary/TSL, as well as some conversations Jimmy documented in an email.

19. Richard:  We voted on a criteria change, this should be published and CSPs can be assessed against it as component v. full service.  Approval is contingent on the assessor finding them in conformance to criteria that is applicable to their scope/service.

20. Jimmy: The idea of a component (i.e. slicing the criteria) was agreed to 2 years ago. The difference now is a different slicing of the criteria.

Tabled for now.

• NIST's 63B Supplement for Syncable Authenticators 

• Initial discussion to determine if any criteria need changing

• Roger: what is Kantara’s perspective?

• Jimmy’s initial response: 

  1. There are 4 pieces of criteria that don’t allow cloning and passkeys allow cloning

  2. Supplement implies that there are things (‘shall’ statements) to do, but they don’t provide them  - not clear what to do with it or if something is allowed.

  3. Letting those 4 criteria go would be a material change (or somehow note/flag that this can be waived based on supplement)

  4. Are there other things that need changing/updating?  If so, the criteria would need to adusted accordingly.

• Andrew Hughes: Does the supplement establish a new authenticator in 63B? Jimmy/Richard say no.

• Richard: It addresses inhibitions on multi-factor crypto that were imposed when they drafted rev 3.  The technologies/practices to overcome the risks were not in place and they are now recognizing that people want to start using syncable authenticators.  The coping mechanism is this supplement to override some of the prior restrictions.  

  1. Two principal problems:

     1. Multiple implications RE: not having certain things prohibited anymore.  But the full extent to which you can (or should still) adhere to existing requirements in 63B OR override them with this supplement.  Which of the old criteria no longer apply OR only apply if you’re not using a synchronizable authenticator?

     2. The supplement isn’t related to the original document.

• Andrew Hughes:  MFA affected but how it’s affected/impacted is not clear. Syncable pass keys have been added, but not integrated into 63B

• Richard: Note 4.4.2-originally you couldn’t use the sign-on of a handheld/mobile device as part of the authentication, now it seems you can, but it isn’t clearly stated.  

• Richard:  The supplement contains a string of what you shall do to implement syncable authenticators but it isn’t clear which of the original criteria (or our derived criteria) from 63B would go by the wayside. 

• Yehoshua: If you allow authenticators and specifically the private key to be synced, it can only be synced if you complete XYX.

  1. Richard concurs this is reasonable, but is it definitive?

• Overall approach to the supplement:

  1. Look at it in 2 stages, or move quickly?

  2. Possibility of rev. 4 being published in July.  Does it make more sense to wait for that draft and hope for more clarification?