2020-02-20 Minutes

Owned by Former user (Deleted)
Last updated: Mar 19, 2020

Attendees

Voting Participants: Ken Dagg; Richard Wilsher; Mark Hapner; JJ Harkema; Martin Smith 

Staff: Colin Wallis and  Ruth Puente

Quorum: As of 2019-12-19, quorum is 3 of 5. There was quorum

Agenda

Administration

  1. Roll Call
  2. Agenda Confirmation
  3. Action Item Review: action item list
  4. Staff reports and updates -  Keeping up with Kantara February 2020and January Director's Corner 
  5. LC reports and updates
  6. Call for Tweet-worthy items to feed (@KantaraNews)

Discussion

  1. ARB issue on Classic OP-SACwith regard to phishing attacks (AL3_CM_CRN#040 Token strength and AL3_CM_CRN#050 One-time password strength).
  2. DIACC Call for Comments: PCTF Organization component (Trusted Processes and associated Conformance Criteria that establish an Organization exists, is real, unique, and identifiable) for review by March 19th
  3. Review UK Government Digital Service document - Using authenticators to protect an online service.
  4. Develop Kantara Service Assessment Criteria for NIST SP 800-63C.

Any Other Business 

Discussion

ARB issue on Classic OP-SAC with regard to phishing attacks (AL3_CM_CRN#040 Token strength and AL3_CM_CRN#050 One-time password strength).

  • Ken suggested that some guidance could be added to be a guest to CSPs to be weary of, but he does not know how much value that would provide. Richard added that the CSP should closely follow the evolving landscape around phishing within this authentication technology.
  • It was argued that advice is not a particular good thing, it is a requirement, or it is not.
  • It was commented that the CSPs are relaying on Kantara, at some level of generality, to keep an eye on whether the framework is offering a protection. Richard answered that if Kantara was to catch as something which would say use of appropriate phishing new system authentication technologies, in the outside there is and this criteria that are reference, that potentially the scope to include if there is a list of things to be done (and there are in some places) it could be added in there. There is a list of factors which needs to be taken into account, Kantara could add a specific requirement in there that might be more concrete. But it is not the intention to be putting guidance, the idea is to make an assertive statement and then the assessors are able to make the judgement against it. The CSPs can have judgement on how they will respond to that requirement in terms of assessing the risk in applying controls against it.
  • JJ pointed out the 800-63-3 talks about the strength authentication and part of that has to do with the quality of the secrets that are used to authenticate an individual, therefore some of those secrets are more difficult to compromise than others. Now they all have their little risks and so from an 800-63-3 perspective, they try to stack up a few of them rather than relying on a single one mainly for proofing, he guesses. They are assuming for authentication that you are giving someone a strong secret, he thinks that the biggest issue today is that secrets are easy to compromise, they are easy to use and also easy to compromise. All of those are not the strongest, and thus the issue for CSPs is what motivates them to continue to move and improve the quality of the authenticator that they give people once they have been proved. For him this is the issue, what is motivating the industry to move forward to provide stronger authenticators.
  • It was added it is the motivation, but it is also the fear of losing part of it. The motivation to not do it in the moment is stronger than to implement it.
  • It was mentioned that going back to the immediate problem, it could be looked in here at adding an item g) to AL3_CM_CTR#020 criterion, related to phishing attacks explicitly. JJ argued that the problem is that if you mention a particular thread like phishing, there is a range of things that can be done potentially to mitigate that. It was responded that it is up to the CSPs to make the determination.
  • It was agreed that in order to satisfy the ARB’s concerns, to add a phrase to item g) in the list of AL3_CM_CTR#020 Protocol threat risk assessment and controls. 
  • The text to be added will be prepared, it will be reviewed probably at an e-ballot through next meeting.

Action item: To add a phrase to item g) in the list of OP SAC AL3_CM_CTR#020 Protocol threat risk assessment and controls. 


DIACC Call for Comments: PCTF Organization component (Trusted Processes and associated Conformance Criteria that establish an Organization exists, is real, unique, and identifiable) for review by March 19th

  • Ken commented that on Tuesday he received an email from Digital Identification and Authentication Counsel of Canada that the Pan-Canadian Trust Framework has issued another component for review, and it is an organizational component. It is describing the component and presenting some criteria to evaluate whether the organization component, the requirement statements, are being met. What they are doing is interesting because it is verifying that an organization is a valid organization. Ken added that it goes beyond, expanding what Kantara has. He wants that comments can be generated and after a couple of meetings an answer can be provided to them. There are two benefits from this, one would be to potentially expand on the CO-SAC requirements that are there today and maybe enhance them; the other would be to keep Kantara with a foot on the door with respect to DIACC and the Pan-Canadian Trust Framework, as to future opportunities that might arise for Kantara to undertake assessments. Ken reckons that it should be undertaken.


Review UK Government Digital Service document - Using authenticators to protect an online service.

  • Ken pointed out that they are looking for some preliminary comments on this document. They are looking for these comments for the end of February (29th).
  • Ken proposed to form a small Work Group and he offered to be the chair of it, to over the next week have a couple of calls, read the document and make some comments. Politically, it may or may not end up with anything substantial. He believes that at least a few comments have to be made.
  • Richard commented that the document is very simply expressed. Ken answered that comments can be made to suggest changing some sentences since some of them are too simplified, but he said that the approach they want to make is not a negative approach, they should just avoid ambiguities and incorrectness.

 

Develop Kantara Service Assessment Criteria for NIST SP 800-63C.

  • Ken mentioned that Richard sent an email about this an hour ago to introduce the topic.
  • Ken said that the internal Kantara processes require about 8 weeks to make it through all member ballot, internal review and LC approval and all of that sort of stuff, which means it has to be done in the end of April (to be ready for June/July). The first draft is in essence ready (it is being made by Richard).
  • Richard mentioned that the draft he shared, is thematically similar to the layout of 63a - 63b criteria. All the normative was extracted out of 63c. He remarked that there is now a number of uniquely criteria.
  • Richard suggested that the Federation Authority SHALL be responsible for the creation, maintenance, approval and publication of a documented Federation Agreement which SHALL define the obligations upon participants within the applicable Federation.
  • Regarding Normative statements, there will be SHALLs for the CSPs to know what they are meant to do.
  • It was asked about the sponsorship of ID.me, what is it constituted of?  Colin said ID.me is sponsoring the work through Kantara, and Kantara has contracted Richard as editor.
  • Another question was raised, who is getting assessed here? Richard said that historically Kantara has assessed the service provider. Kantara does not have means to assess true RPs.
  • Richard remarked that Federation Authorities SHALL establish parameters regarding expected and acceptable IALs, AALs, and FALs in connection with the federated relationships they enable. Moreover, Federation Authorities SHALL individually vet each participant in the Federation to determine whether they adhere to their expected security, identity, and privacy standards.