Page Comparison

2024-09-05 IAWG Meeting Notes DRAFT

• Supplement for Syncable Authenticators

• Carol and Kay met with NIST staff to discuss syncable authenticators.  

  1. Concern from NIST about term “nonconformance” -  could potentially signal to fed agencies to NOT use syncable authenticators, however the difficulty still lies in the fact that Kantara doesn’t have something to audit against.

  2. Andrew: language is always present in NIST 8000-63 versions RE: conformance (If you don’t meet the requirements of the “shall’s”, you do not conform)

  3. Carol: concerned about Kantara’s due process/integrity

     1. “Guidance”--they want to use this word, what is it actually going to be?

  4. Mike Magrath: Will they working on their own conformance criteria for syncable authenticators?

     1. They intend to release something after rev. 4

     2. Hughes: If we want improvements on syncable authenticators, the comment period on rev.4 is the vehicle.

  5. Jimmy: 2 data points from presentation

     1. Ryan-seems to have acknowledged that they don’t know some things about “bring your own authenticator” “hand waving–problematic for us as assessors

     2. ARB response–well NIST says syncable authenticators are AAL2, we would like to take syncable authenticators as mildly nonconformant while IAWG works through the process. Waiting for IAWG is problematic for clients.

  6. Andrew: heard that some mandatory requirements are not mandatory, we don’t want to guess

     1. ACTION: @Carol-look at “BYO authenticators” sections in 63B and see if it is replicated–what are the mandatory requirements–do they match?  Treated as optional? If they are doing it now, our discussion with NIST is different.  If they aren’t doing it (just omitted things), then we have a stronger argument to make regarding these being shoulds/not mandatory/guidance/optional.

  7. Emphasizes focusing on text as written, not interpretation.

  8. Roger: Notes concern between a potential “split” between NIST as the publisher and Kantara as the approver

  9. Jimmy: Concern with passkeys not being supported under current version of 800-63-3, and users/customers having to wait until rev.4 is finalized.  How can Kantara recognize the current marketplace for vendors?

  10. Andrew: Kantara’s framework was explicitly designed to reflect 800-63-3’s mandatory requirements.

  11.  Option for passkeys to get a “pass”?  Where would that line be drawn?

  12. Andrew:  CSPS evaluate the risk and assessor confirm the evaluation is sound (seems to be the approach of companies using passkeys now)

  13. Yehoshua: If NIST is telling us they don’t want companies to be “nonconformant”, are they saying it is is ok to use some kind of complementary control?  Do we leave out some of the NIST requirements from Kantara’s framework?  Will there be corresponding line items in the SAC/SoCA?

  14. Tim: Agrees on not waiting too long to address syncable authenticators and would be open to future conversations on what rev 4 offers.  Would also accept a CSP writing up/accepting the risk of not fulfilling a mandatory requirement.

  15. Andrew: Compensating controls/risk acceptance may not be enough

  16. Jimmy: ARB wants to wait for IAWG to fix it in the interim (Concurred by Kay/Carol)

  17. Yehoshua: Seems to be an idea that IAWG could come up with things that serve as compensating controls.  Could it be possible to come up with something to discuss and use as a group for a risk framework?

  18. Carol: Propose a list of compensatory controls that would be acceptable.

  19. Andrew/Tim: Could Kantara have criterion stating “The CSP shall produce some statement of risk/acceptance/exception” that would then be evaluated?

  20. Jimmy/Andrew:  Should the requirement be for the CSP to have a risk mitigation strategy?  This could be evaluated.

      1. Potential to be boxed into 63-3

      2. Meaning-passkeys are good for AAL2 (since rev. 3 won’t be touched again-can’t change shall to should)

  21. Jimmy: how is a compensating risk mitigation framework different from criteria saying if it’s a passkey, it’s okay?

  22. Ultimately, the market needs to be able to use passkeys  with AAL2 and Kantara needs a way to assess this (quickly) considering that the core requirement says it is mandatory, but it is impossible to achieve/assess.  If we can manage with risk statements, that’s fine.  But considering that the Trust Mark is tailored to NIST requirements, would that need to be changed?  Ask the BoD?

  23. Tim: Kantara already accepts compensating controls/risk mitigation frameworks (FEDRAMP, FISMA, etc).  So if if discrete criteria isn’t an option, risk-based criteria/framework would be a reasonable path forward.

  24. Andrew: Similar to his efforts to push against following the mandatory requirements of 800-63 beyond v.3.

  25. Roger: Would Kantara pushing the risk back onto the CSP alleviate the need for Kantara?

  26. Carol: Action is needed and should be based on the reality and accessible criteria.  Will be looking at things immediately.