- Case Number: a20100404.1
- Status: running
- Claimants: Iang
Respondents: CAcert, MarioLipinski
Case Manager: UlrichSchroeter
Arbitrator: LambertHofstra, HansVerbeek
- Date of arbitration start: 2010-04-28
- Date of ruling: 201Y-MM-DD
- Case closed: 201Y-MM-DD
- Complaint: Urgent - Dispute Filing to block off OAs
As discussed below it was today revealed that any Organisation Administrator ("OA") has power to adjust any O-Admin list for any domain. This was demonstrated by Mario in the board meeting. This means (allegedly) that any OA can adjust the list for cacert.org's account, and then move to issue any certificate for any secure cacert site. This is a security breach. I therefore file urgent dispute to request an Arbitrator to rule that all OA access be disable until this can be sorted out. I will advise critical team leaders of this in Fwd. We will also initiate board motion to pass cacert.org's OA account into SP domain. Wider discussion will be needed with critical team leaders. iang, as writing up minutes from meeting at https://wiki.cacert.org/Brain/CAcertInc/Committee/MeetingAgendasAndMinutes/20100403 Please note that the Transcript for the above meeting is in the public record.
Followup by MarioLipinski dated 2010-04-04
> As discussed below it was today revealed that any Organisation > Administrator ("OA") has power to adjust any O-Admin list for any > domain. This is not correct. Not sure whether it is a typo or misunderstanding. The organisation administrators can just be edited by Organisation Assurers. These are well trained people regarding Organisation Assurance and know how to handle individual requests. Maybe Support has some power on this as well - but I am not sure there.
- Relief: TBD
Before: Arbitrator LambertHofstra (A1), HansVerbeek (A2), Respondent: CAcert, Mario Lipinski (R), Claimant: Iang (C), Case: a20100404.1
History Log
- 2010-04-04 (issue.c.o) case [s20100404.9]
2010-04-06 (UlrichSchroeter): added to wiki, request for CM / A
- 2010-04-28 (A1): I'll take care about this case as A (from within Arbteam meeting)
- 2010-04-28 (A2): I'll take care about this case as A (from within Arbteam meeting)
- 2010-04-28 (CM): I'll take care about this case as CM (from within Arbteam meeting)
- 2010-04-28 (CM): sent CCA/DRP req. to (C)
- 2010-04-28 (CM): forwarded all mails related to this case to (A1), (A2)
- 2010-04-28 (R): I'd like to serve the OA side in the block OA case.
- 2010-04-28 (CM): sent CCA/DRP req. to (R)
- 2010-04-29 (R): accepts to be (R), accepts CCA/DRP
- 2010-04-29 (C): accepts CCA/DRP
- 2010-05-01 (C): statement rcvd
- 2010-05-03 (A): questions sent to (C), (R)
- 2010-05-04 (C): responded to (A)'s questions
- 2010-05-04 (C): statement dated 2010-05-01 re-sent
- 2010-05-06 (R): statement rcvd
- 2010-07-16 (AO) There still exists a hidden script that lists current OA's from off the database
- 2010-07-16 (C): comment on info received from (AO)
- 2010-08-25 (CM): can you please provide me with a progress update report in this case
- 2010-09-08 (CM): req progress update report from (A) req#2
- 2010-09-12 (A2): contacts (A1) with req for progress report
- 2010-10-06 (CM): requesting progress report from (A) (req#3) with deadline until Oct 20th, 2010, with next step notification to board-private list
- 2010-10-06 (A2): still waiting for reply from (A1). still waiting for the answers of one of the parties on the questions, as asked by (A1). That party has sent a reply, but did not answer the questions at that time.
2010-10-06 (CM): reviewed this case, there are probably no unanswered questions by (C) or (R). If you'll try to test how the OA thing works, go to testserver catest1 and test it with the current production webdb code. Infos sent to (C), (R), (A1), (A2)
- 2010-10-06 (CM): irc chat with (A). Agreed to find a working solution till end of this week (Mon Oct 11th)
- 2010-10-10 (A): (CM) please ask Software-Engineers and Testers with followin question: Who can change O-Admin for a domain?
- 2010-10-11 (CM): sent out (A) question to (Software-Assessors)
- 2010-10-11 (CM): sent out (A) question to (Software-Testteam)
- 2010-10-11 (CM): sent own test result report to (A1), (A2)
- 2010-10-11 (CM): sending test result report to 3 other testers for confirmation
- 2011-01-14 (CM): progress report request to (A1), (A2)
- 2011-04-27 (A1): progress report request to (A2)
- 2011-05-04 (A1): sending summary to (OAO), (R), (A2), OA-mailing-list, (CM). Asks for confirmation of summary, requests list of OA's, assured Org's from (OAO)
2011-05-21 (A2): F2F disucssion meeting with dirk (SA), Joost (pOA, SE) at HCC! Linux Themadag for workaround findings
Discovery
- 2010-04-29 (R): statement sent to (CM), (A1), (A2)
See https://lists.cacert.org/wws/arc/cacert-arbitration/2010-04/msg00000.html I also request you to ask R to clearly state his relief. The current is misleading because of messing up with terms. So whether to completely block Organisation Assurances, Organisations Administrators or whatever. I do not see any violation of CAcert policies nor any security weaknesses introduced due to anything related to Organisation Assurance. So I ask the arbitration to dismiss any action. However the Arbitrator might consider proposing the system to be adjusted to reflect better auditibility. E.g. to see who assured an organisation, what changes have to done when and by whom. Also auditing features which notifies all involved actors of the organisation on changes to the organisational account. This would improve the positive user experience by our organisational users, especially of the paranoid ones.
- 2010-05-01 (C): statement sent to (R), (CM), (A1), (A2); resent 2010-05-04
Security Policy [0] generally creates the standard for CAcert to control its critical systems. It does not particularly speak to this issue, but it states principles and standards, that include * dual control over critical resources * ABC over personnel involved with critical resources Software also comes under the control of Security Policy. See Sections 1.1 and Section 7, establishing Software as a critical system. Organisation Assurance does not appear, and especially, Organisation Assurers (OAs) are not critical roles and do not have ABCs. In the board meeting of 20100403 [1] it was established that any OA was capable of adjusting the list of an organisation assurance account to add any domain. This included cacert.org domains. There was no limit suggested to this. The apparent situation then is that any OA can issue a certificate for secure.cacert.org. Which allows an OA to do a man-in-the-middle (MITM) attack of the secure site. While there may be a low risk for this, it is clearly something that falls within the expected scope of Security Policy, but equally as clearly not addressed at all by Security Policy. Therefore, the board, following SP 1.1, passed a motion [2] to make this issue part of Security Policy, so there is no doubt. That leaves how to deal with it. Given the gravity of the MITM situation (we are a CA, the point of a CA is to stop the MITM, allowing an MITM from inside is an easy failure), I see it as difficult to compromise on the security issue. In the longer term, we likely need software changes to control this issue more carefully. Or, we bring OAs into the Security Policy's scope? But in the shorter term, we know there will be no such easy fix. Therefore, until fixes are put in place, and Security Policy and practice are in alignment, I request the suspension of OA capabilities by some means or another so as to remove the risk. Another factor is that Organisation Assurance is essentially an uncontrolled area. In contrast to individual Assurance, it has no accepted manuals, no team leader, no identifiable security arrangements, and a word-of-mouth training & testing regime. For example, we don't have the Organisation Assurance Officer, who would be expected to stand up to take the place of respondent, and to explain the facts to us for Organisation Assurance. Because of the repeated claims but lack of defence when hard questions were asked, I as auditor declared Organisation Assurance to be unauditable, that is, "audit fail" [3]. Some work has been done since then, but not enough to change that declaration, in my opinion. This might be seen as placing the security requirements of the critical systems above the needs of the the Organisation Assurance area. A final factor is that Security Policy is wip. And therefore not binding /on the Community/. It remains binding on the critical roles, because they already agreed to it. OAs could argue that any reach of the SP does not effect them, they should therefore not lose capabilities. This would be unfortunate, but it might be sustainable. regards, iang PS: question of interest, why are two Arbitrators listed? [0] https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html [1] https://wiki.cacert.org/Brain/CAcertInc/Committee/MeetingAgendasAndMinutes/20100403 [2] https://community.cacert.org/board/motions.php?motion=m20100404.4 [3] https://wiki.cacert.org/Audit/CommunityReport20081007 https://wiki.cacert.org/Audit/CommunityReport20090119 https://wiki.cacert.org/PolicyDrafts/OrganisationAssurance
- 2010-05-03 (A): questions to (C), (R)
I've read both the claim and response, as documented in the wiki: https://wiki.cacert.org/Arbitrations/a20100404.1 What I understand of this is: - The assurance officer (AO) maintains a list of Organisation Assurers (OA's) - An OA can assure an organisation - an organisation that is assured, needs an Organisation Administrator (O-Admin) - the OA assigns an O-Admin to an organisation It seems to me that C states that any OA can modify the O-Admin of any organisation. C, Is this correct? It also seems to me that C states that as such, any OA can modify the O-Admin of CAcert. C, Is that correct? According to the OA Manual (https://wiki.cacert.org/Brain/EducationTraining/OrganisationAssurance/Manual?action=show&redirect=OrganisationAssurance/Manual) the O-Admin of an organisation can request certificates (server, client, and/or code-signing). It seems to me that C claims that because of the current capabilities of each OA (assigning a new O-Admin for any assured organisation), it is now possible that an OA can assign a new O-Admin to CAcert Inc., potentially his own account, or of a friend, and request certs for CAcert Inc., and that this is a big security problem. C, Is that correct? Now, the way I read the response from R is that, although the above might be true, it will never happen, since the OA's are trained and responsible. R, Is this correct? Can both of you please reply to me and let me know if my summary of the case, as written above, is correct? You can add more info in a separate paragraph in your reply.
- 2010-05-04 (C): response to (A)'s questions
> I've read both the claim and response, as documented in the wiki: > https://wiki.cacert.org/Arbitrations/a20100404.1 > > What I understand of this is: > - The assurance officer (AO) maintains a list of Organisation Assurers > (OA's) > - An OA can assure an organisation > - an organisation that is assured, needs an Organisation Administrator > (O-Admin) > - the OA assigns an O-Admin to an organisation > > It seems to me that C states that any OA can modify the O-Admin of any > organisation. > C, Is this correct? That is what I am led to believe. I have not tested it. > It also seems to me that C states that as such, any OA can modify the > O-Admin of CAcert. > C, Is that correct? Yes. > According to the OA Manual > (https://wiki.cacert.org/Brain/EducationTraining/OrganisationAssurance/Manual?action=show&redirect=OrganisationAssurance/Manual) > the O-Admin of an organisation can request certificates (server, client, > and/or code-signing). > > It seems to me that C claims that because of the current capabilities of > each OA (assigning a new O-Admin for any assured organisation), it is > now possible that an OA can assign a new O-Admin to CAcert Inc., > potentially his own account, or of a friend, and request certs for > CAcert Inc., and that this is a big security problem. > C, Is that correct? That is my understanding. I am not aware of the precise mechanism, but the above seems close. To confirm (R)s comment about a typo, the original filing did have an error, the first term should be Organisation Assurer ("OA"). Not administrator (who we generally term "O-Admin"). > Now, the way I read the response from R is that, although the above > might be true, it will never happen, since the OA's are trained and > responsible. > R, Is this correct? > > Can both of you please reply to me and let me know if my summary of the > case, as written above, is correct? > > You can add more info in a separate paragraph in your reply. I sent an additional mail on 1st May under this subject line, that seems not to be entered into the log. I'll resend.
- 2010-05-06 (R): response to (A)'s questions
> - The assurance officer (AO) maintains a list of Organisation Assurers > (OA's) Who is this actually for this case? Board or Uli? I doubt neither of them have the list. Maybe this is a good time to get the list from the system by having the admins query the database? > - An OA can assure an organisation Right. Therefore he has access to the organisation list in the database and there he can add, edit and delete organisations. He can also maintain the list of domain names and O-Admins associated to these accounts. > - an organisation that is assured, needs an Organisation Administrator > (O-Admin) Yes. The O-Admin is the Assurer (user) who can issue certificates with the organisational information within. > - the OA assigns an O-Admin to an organisation Technically yes. The O-Admin is appointed by the organisation via COAP form. The O-Admin then can also add other users as O-Admins. Iirc O-Admins cannot grant grant permissions (called main account). > It also seems to me that C states that as such, any OA can modify the > O-Admin of CAcert. > C, Is that correct? CAcert Inc. here is just another assured organisation. > Now, the way I read the response from R is that, although the above > might be true, it will never happen, since the OA's are trained and > responsible. > R, Is this correct? Yes. > Can both of you please reply to me and let me know if my summary of the > case, as written above, is correct? Yes.
Ruling
Execution
Similiar Cases