2020-07-15 Meeting notes - AAL3 criteria

Owned by Former user (Deleted)
Last updated: Jul 22, 2020

Attendees: Martin; Ken; Richard; Colin; Ruth


Key discussion items:


Draft reviewed during the meeting: KIAF-1440 SP 800-63B Service Assessment Criteria v3.0.4.xlsx

  • Martin asked about the scope of the work involved in the SAC annual reviews, as he does not want to delay the xAL3 review. Richard said that the idea is to give people two weeks to review. The SACs have been published for a long time and at least three or four CSP are actively using them. We've noticed things in IAL2 that need to be fixed.
  • Richard suggested to run the 12-year review in parallel as an open call for comment in the IAWG. The group agreed.
  • Regarding the compilation of comments for NIST, Ken and Richard have been generating PDFs of the NIST documents with line numbers, so it'd be easier for commenters to reference where they think there should be changes.
  • Reauthentication – lines 75-77; 63B#3160 - 63B#3190 Richard: So, it's either 15 minutes of inactivity or irrespective of inactivity or regardless. Prior to reaching 12 hours being reached, so that's how seems to be a more logical way to approach these three criteria. You could do it every 60 minutes if you want it to.  So, if you did every five minutes that would meet the requirement of prior to it reaching 12 hours. 12 hours is the max.
  • If you're going to put these limits on it and you fail to reauthenticate it then you got to terminate it. 63B#4343 says, ‘shall terminate when they are unable to get affirmative re-authentication’. Richard said that these four criteria have been structured in a has all a logical manner. This is one of the things to consider in rev 4, being better structured about what they say.
  • Martin pointed out that the language in line 79 is a little confusing; you're saying they should apply in the same process they did for the initial. Richard: It come out of risk treatment. The CSP will never know that it is re-authentication, it will just treat it as an authentication.
  • Assuming the CSP has no way of knowing whether it's authentication or re-authentication, then we believe that this requirement is moot. It was concluded that we should ask NIST about 63B#3180.
  • Richard clarified that 63B#3200 is related to CSP systems. When you employ those high baseline security controls from 800-63-3 make sure that they also meet the minimum assurance-related controls. So, the first level we'd be relying upon an adequate description of the scope of assessment in the S3A. The assessor would ask for the risk assessment or your FedRAMP or whatever which led you to the choice of these controls, making sure there's a common scope.
  • Row 81 #3205- Martin suggested to change the criteria from passive to active so that you can say the CSP shall ensure that its systems meet. The text now reads ‘the CSP SHALL ensure that its system satisfies a minimum assurance-related controls’.
  • 63B#3210 Records Retention Policy it’s covered by 63B#0220. Regarding NARA records retention, it was agreed to make it broader and a clarifying note was added as guidance. Rows 82-84 (63B#3210;3220;3230): There's no need to repeat it because there's nothing that has rigor for level 3.
  • Privacy requirements Rows 92-96. Richard: This is a new set of requirements that are introduced because after we've done the Federation stuff on had brought in RPs and federal agencies. I then selectively invoked these Clauses which we previously ignored. I've done a little bit of optimization the language. Martin: The reason is broken out is since the publication of SORN is via OMB not within the agency; they may have considered that a separate step.
  • 63B#0400 – ‘SHALL force’ was replaced by ‘SHALL require’.
  • Row 133 – Martin suggested to ask NIST if they meant that to be an exhaustive list function. Also, it was agreed to ask NIST approved by whom?
  • 5.1. Memorized secrets verifiers. The condition was ignored because it would be perfectly legit for a CSP to say, ‘we don't generate salts’. Therefore, this doesn't apply.
  • 5.1. Look-Up secrets. It was suggested to see the non-normative sections of 63B to get NIST understanding of what these terms are and how they're applying them. There's a secret which have to have 20 bits of entropy and secret verifier which has to have 32 bits which is substantially stronger. When assessing this, the first question to ask would be, how are you applying it? in which case is either 20 or 32-bit. You need to read 63B and understand what it was expecting and then begin to the subject of assessment and understand what they were trying to accomplish.
  • 5.1. Single-Factor OTP Authenticators. Line 201. Martin pointed out that “Strongly protected” was not defined. Richard said that there is no NIST definition for strong, it's just got to be better than ordinarily protected; it's very hard to quantify that. A note was made to let the CSP make the argument and convince the assessor that the protection warrants a claim of being ‘strong’. Comment for NIST rev. 4: Do not use terms implying rigor without some basis of measurement or a reference source.
  • 5.1. Multi-Factor OTP Verifiers. Line 220. Comment for Rev. 4: What a Trusted statement is? Ken said that he understands that trust statement is evidence. Richard added that the guideline implies a trusted statement is what you have established via the authenticator source. The criterion was reworded to provide more clarity ‘Unless it is able to rely upon a statement via the authenticator source that a device is multifactor the CSP SHALL treat the authenticator as if it was single-factor’. Richard said that it is related to how does a CSP manage binding between a proven ID and some form of authenticator. At this point they would come to this and say, ‘we do that because we only allow these authenticators at the back of the binding stage’. It may be relatively easy to prove, given their process to validate the legitimacy of particular multi-factor devices.
  • 5.2. Verifier Impersonation Resistance. Martin pointed out that clearly the CSP is distinct from the verifier in these criteria. Richard said that it’s upon the RP. Ken asked, what is the definition of a verifier? And what is the relationship of a verifier to a CSP? Richard read 5.2.5 from the guideline ‘Verifier impersonation attacks, sometimes to as “phishing attacks”, are attempts by fraudulent verifiers and RPS to fool an unwary claimant into authenticating to an impostor website’. We need a definition of verifier. The verifier is a function of the CSP.