- Richard mentioned about row 10 that he did not know why it was not in level 2, but he noticed it was not. He could not see any reason why it was omitted. Now he realized it is specific to agencies, that is why it suddenly appeared. Ken disagreed with that; the requirements are on agencies alone, not on CSPs. Agencies have to ensure that AAL2 is there for self-asserted PII, that is why it was rejected before. Richard explained that supposedly, agencies might be providing information to the subject online which to him, puts the agency in the role of a relying party. It was added that most of US agencies are on CSPs. It was agreed.
- Row 25 was agreed. Richard had made some changes.
- About row 26, Ken suggested that instead of ‘use’ to go back to the requirement, where the requirement says ‘procure’. It would require a contract. Martin said that ‘use’ is a very open-ended descriptor of the relationship. Richard said that his point has to do with the procuring of the service, not with the actual authentication. It was added a note “Seek NIST guidance?”. The criterion was modified as “Federal Agencies SHALL only procure authenticators which have been validated as meeting FIPS 140 Level 1 o higher”. It was agreed. Richard will make up a question to NIST.
- In line 29 Richard has not changed the tag. Richard said that Martin is right, the n/a should not be in red if they have not changed.
- About row 30, Martin asked if a verifier is always a CSP. Richard said he thinks so. Richard turned black again the criterion.
- Richard changed the criterion in row 31, he took out “use CSPs which?”. It was added as a comment to seek NIST guidance. Ken asked if there is a similar requirement at AAL3. Richard responded that he will have to see that. Lines 26 and 31 make this assertion at level 2 and it is not equivalent at level 3. The question added for NIST in line 31 is “What applies at AAL3?”. It was added a question mark in lines 26 and 31 for applicability at level 3.
- In row 41, Richard mentioned he does not see how a CSP can be responsible for reauthenticating the subscriber. Ken clarified it is a requirement on the RP to send another assertion request. Martin asked what positive means. Richard explained it means you have to take some actions to make it happen. Richard replaced ‘positive’ by ‘affirmative’.
- Ken mentioned that line 41 is a requirement for the RP and 42 is for the CSP. Ken asked if then line 42 should be changed, RP instead of CSP.
- Richard decided to research deeply into lines 39-42. It is needed to be reviewed and it will turn into a NIST question. Martin said it goes beyond his knowledge of the various interaction patterns. Richard will review the whole text in here.
- In relation to line 43-44, Richard explained that they are related. Line 43 says ‘moderate baseline’ and 44 says ‘moderate impact’. Richard removed “to include control enhancements, for moderate-impact systems” in line 43. Ken commented that line 44 requirement does not make much sense to him. Richard explained that these controls have to meet the requirements for modern impact systems. Ken argued that it says “The CSP SHALL ensure that the minimum assurance-related controls for moderate-impact systems or equivalent are satisfied”, is it the needs or requirement? What is satisfied? Richard said that when fulfilling line 43 criterion in selecting these controls, you need to ensure that the minimum assurance-related controls for moderate-impact systems or equivalent are satisfied. Ken asked if this is a valid sentence, he suggested that it should be ‘the CSP SHALL ensure that the requirements for minimum assurance-related controls for moderate-impact systems or equivalent are satisfied’; or ‘the CSP SHALL ensure that the needs of the minimum assurance-related controls for moderate-impact systems or equivalent are satisfied’. Richard modified the requirement as “the CSP SHALL ensure that minimum assurance-related control needs for moderate-impact systems or equivalent are satisfied”. Line 44 was agreed.
- Richard will reflect on this revised wording (line 44).
- About line 51, Ken said that it means that at AAL3 you could use more hardware and one software. Richard affirmed it and added that 51 says ‘at least one authenticator used is hardware-based’ and 52 ‘at least one authenticator used is verifier-impersonation resistant’. Multiple authenticators are allowed. Ken said that his only concern is the singular in the requirement and the allowance of multiples in the criterion. Richard added that you have to have multifactor at AAL3, it is a fundamental understanding that you cannot have only one authenticator. Ken agrees, but he argues that the requirement states it in singular, but it means all. Richard clarified it says at least one. Lines 51 and 52 were agreed.
- Line 54 was agreed.
- In line 59, Richard modified the criterion as “Single-Factor Cryptographic Device with a Multi-Factor OTP device (software or hardware)”.
- Lines 55-59 and 61-62 were agreed.
- Richard will go back to line 60, it has to be reworded.
- About line 64, Ken asked: is there a difference between all authenticators and cryptographic device authenticator? Richard said he is a little confused with the language used here, he will check the numbering.
- Martin explained that he can help with the language, to see if something is ambiguous, but he cannot help on the technology side. Richard said they will continue then on that side.
- Line 65: Richard thinks the word crypto is redundant, that is why he left it out. It was agreed.
- Line 66 was agreed, it covers it and it is almost the same wording.
- About line 67, Richard said he is not going to repeat AAL3 because it is redundant. It was agreed.
- Again, in row 68, there was irrelevant reference to AAL3. The word ‘overall’ was removed. It was agreed.
- Row 69 was agreed.
- In row 70, the criterion was modified as “The CSP SHALL ensure that verifiers are 'verifier compromise resistant' with respect to at least one authentication factor in accordance with 63B#9999 [range of criteria equiv to 5.2.7]”. It was agreed.
- Row 71: Richard said that the phrase “The CSP SHALL include in its risk assessment” implies that they actually do broader risk assessment, which includes side-channel attacks. It was agreed.
- Richard commented that in line 71 is the only place where it talks about side-channels. It was suggested to check NIST document, Richard explained that it was not included because it is a SHOULD (page 9). It was added in Guidance “Rev. 4: No explicit request to actually counter the identified threats (i.e. the CSP (only) SHOULD)”.
- Rows 72-73 will have to be revised again.
- Row 74: There was nothing specific in NIST document about any particular assurance levels. Richard said that the criterion could just mention “covered by 63B#1300 - '#1380 inc.”. However, and finally, it was left as it was. It was agreed.
- Line 76 was agreed.
- Line 77 has to be changed.
- Richard will make the necessary research.
- Next meeting will be cancelled.
Page Comparison
Manage space
Manage content
Integrations