Attendees: Nathan Faut, Richard Wilsher, Sato, Martin Smith, Mark Hapner, Ken Dagg, Ruth Puente.
Draft reviewed during the meeting: KIAF-1450 SP 800-63C Service Assessment Criteria v0.06.0.xlsx
- Richard started the meeting reminding the group that everything related to Federation Authority was covered. He said there was great conversation, and that all the comments received were resolved. Ken wanted to make sure if anyone disagreed on this last comment from Richard, the group agreed on it.
- In row 14 63C #080, “The CSP SHALL protect keys used for signing or encrypting AAL2 (or higher) assertions with crypto modules validated at FIPS 140 Level 1 or higher”, Richard said that NIST representatives have commented that “NIST personnel commented that 'govt-operated' is essentially noise, since the SP is intended for application by government agencies and systems they operate or procure”. Mark commented that the whole deal with FIPS 140 is that it is primarily an enterprise standard, therefore if you have an IdP in the cloud for instance, and you put your keys into an AWS KMS, the KMS is not FIPS 140. Requiring keys to be in some kind of FIPS 140 KMS effectively is to restrict how people protect their keys. He added that AWS KMS does not meet any FIPS 140 level, not sure exactly why. The problem with FIPS 140 is that, in addition of some level requiring hardware, it also requires very particular software linked to hardware. A comment was added in relation to this in row 14 “What of CSPs who use services which are not FIPS 140-validated? Ken suggested to gather comments for NIST, and probably this issue would be an input to 63 rev.4. It was argued that it should be focused on whether this is an adequate form of words for the intention of NIST requirements. It was agreed with the KI criteria interpreting NIST requirements.
- About row 15 63C #0100, Richard made the NIST text much stronger and specifically referenced RPs and CSPs on the statement. Ken asked if this should be a policy issue. He added it looks more like a technical issue, he interprets this requirement to basically say “just because you are in a Federation does not give you permission to exchange PII”. Ken stressed he does not get this reading from what is there in the criteria right now. Richard responded it means it needs explicit consent, it should not be taken from the subject. Ken commented that instead of using negative language, it should say “parties in a federation must seek permission to pass information in the Federation”. It was asked what would be the purpose of federating if you were not trying to pass information. Ken explained that federations in existence today, they pass information but never seek for permission; by joining the federation they have the right/capability to pass information. It was added a comment to the criteria and agreed to seek clarification with NIST, “PARKED pending review of further (later) criteria / Request NIST's clarification - what nature of info are they addressing”.
- In relation to 63C #0100 Sato commented that this criterion is related to an IdP, he thinks that an IdP must be involved in the criterion. Richard added that IdPs and RPs are involved because it is in the agreement, and according to later criteria, they have to be vetted as meeting that agreement before they are permitted to be a part of the Federation. Sato agreed to this. Ken pointed out that when auditors do the assessment, they would be assessing that the Federation agreement contains such clauses; when they assess the IdP and RP, they would be assessing whether the IdP and RP have agreed to those clauses.
- In relation to 63C #0110, Richard said that the comment written “Must the CSP require that an RP have an Approval [under Kantara ??]”, it is an assumption, because the criteria is written in the context of Kantara. It basically means, that an IdP could not interact with an RP and that was not Kantara approved. Richard added that the Federation Authority is responsible for vetting all RPs. Ken said that he understands from NIST writing, that IdP needs assurance from someone but all the RPs have been assessed as being good members of the Federation. That assurance can either be granted by the IdP, or the IdP has to have process where in place where it goes through it and looks at all the RPs and says we believe the assessment or the re-assessment that they are conformant to all of the requirements of 800-63-3 FAL2 or FAL3. Richard clarified it says they have to meet all the requirements of IAL, AAL, FAL. The following comment was added “Reword as an FA / Federation Agreement (practical interpretation) / Input to rev.4”. Richard said that from the conversation on these two criteria, he is inclined to re-write this to say that the Federation Agreement “MUST” do something to address this.
- 63C #0120 “IdPs SHALL make whitelists available to subscribers as described in [NIST SP 800-63C] Section 9.2”. Richard commented on this that it says nothing definitive. “§9.2 is pretty fluffy and there is nothing of substance there which can be adopted into a normative criterion”. Ken made the assumption that 9.2 talks about PII, otherwise where does that come from? Ken asked what the definition of whitelist is. Richard proposed a change “The CSP SHALL manage”, not publish, but manage at least. Ken argued it would be better to say “maintain”. It was asked to “Add examples of 'types' as guidance”.
- It was proposed to extend the next meeting to two hours. It was agreed to have a longer meeting next week.