[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Modified: COEL-TC Call
|
Event Title: COEL-TC Call Date: Tuesday, 28 July 2015, 01:00pm to 02:00pm UTC Location: Teleconf (see below) Description Pass code: 46620642 United Kingdom 08000234295 02076351808 +44 2076351808 Australia 1800004583 0282239344 +61 282239344
This meeting counts towards voter eligibility. Agenda We agreed last week to review the latest security topics. See below: [1] Use SSL for all internet communications within the ecosystem. This creates an encrypted channel for the data (Atoms, Reports and Pseudonymised Keys – no DIPI) and prevents a third party from reading it in transit. It means that servers like the IDA, Data Engine and any Service Provider/ or Operator systems must have SSL certificates (between £100 and £300 pa cost or see https://letsencrypt.org/) [2] Use single factor authentication (user-id and password) for all Data Engine and IDA calls with the exception of: [a] submitting atoms which can be done anonymously [b] an operator registering consumers with the DE (see below for why) [3] Use IDA generated pseudonymous keys as the user-ids for actors in the ecosystem. These are devoid of DIPI and unique across the ecosystem. [4] Use different user-ids AND different passwords for each embodiment (e.g. for Operator with IDA, Operator with DE, Service Provider with different DEs etc) Let’s look at the systems/interactions to see what the threats are: [1] Operator / IDA: Disclosure of M2M credentials would allow an attacker to generate Pseudonymous Keys on behalf of an operator. There is no possibility of disclosure of DIPI or behavioural data. Risk is low. [2] Service Provider / IDA. Disclosure of SP interactive login would allow attacker allocate new OperatoIDs or disable existing OperatorIDs. The IDA will not keep any DIPI for operators and their IDA passwords are stored encrypted so there is no risk of these being disclosed. If an attacker gains access then the Service Provider will need to change their password and re-register its operators. [3] Operator / DE: Disclosure of operator credentials would allow an attacker only to register consumers as the operator has no other role with the DE. With this in mind Matt and I agreed that there is no need for an operator password when registering a consumer with the DE. Registering is similar to submitting an Atom. [4] Service Provider / DE: This is where the highest threat is. Disclosure of credentials that gave access to the Data Engine Management Interface (MI) and Query Interface (QI) would open up two possible attacks: [a] An attacker can query the tree of operators and consumers (via MI) and then retrieve all Atoms for all consumers for the SP (via QI). [b] An attacker can use the MI to issue ‘forget’ requests for consumers. This would result in either deleting all the atoms, or disconnecting the atoms from their original consumer ID. It would render the atoms useless to the SP because by definition these are not reversible. To reduce the likelihood of [a], we should mandate that separate credentials be used to access the MI and QI, reducing the likelihood of getting both. To reduce the likelihood of [b], the data engine must use a secondary method to assert the identity of the service provider. Forgetting is a rare event and insisting that there be a human in the loop will make it more secure. We can mandate that the DE send an authorisation email to the SP asking it to confirm the forget request. (Unlikely attacker has access to this mailbox). Or the DE can mandate a second factor of authentication for forget requests such as a handheld RSA key [5] Operator/SP. Where the operator is a separate entity (such as in the GP/AI scenario), it will request reports on consumers from the SP, but these reports are pseudonymised so contain no more information than the query returned from the DE. The operator adds in the DIPI itself. Low risk. Minutes Review of COEL Ecosystem document We agreed the approach to security was coherent and sensible with no obvious holes.
Review of actions
[2015-07-21 / 1] David: Create Issues in OASIS issue tracker from outstanding issue list document. TO BE COMPLETED [2015-07-21 / 2] Paul: Verify that the IDA specification captures the "Need a standard format for Operators and Service Provider identifiers" DONE [2015-07-21 / 3] Paul: Present security options for ecosystem at next call. Post an email for discussion to COEL list.(to include privacy contribution from Joss) DONE [2015-07-21 / 4] David to lead discussion at next meeting on Schedule for publishing drafts. DONE [2015-07-21 / 5] David: Make requests to OASIS to create document folders: "Documents/Submissions" and "Working Drafts/COEL Model" DONE
Owner: Dr. David Snelling Group: OASIS Classification of Everyday Living (COEL) TC Sharing: This event is shared with the OASIS Open (General Membership), and General Public groups. Public Event Link
Microsoft Outlook users: You will see event notifications requiring further
action in your Outlook mail application. |
Attachment:
ical_40673.ics
Description: application/ics
BEGIN:VCALENDAR CALSCALE:GREGORIAN METHOD:REQUEST VERSION:2.0 PRODID:-//Kavi Corporation//NONSGML Kavi Groups//EN X-MS-OLK-FORCEINSPECTOROPEN:TRUE BEGIN:VTIMEZONE TZID:UTC BEGIN:STANDARD DTSTART:20000101T000000 RRULE:FREQ=YEARLY;BYMONTH=1 TZNAME:UTC TZOFFSETFROM:+0000 TZOFFSETTO:+0000 END:STANDARD END:VTIMEZONE BEGIN:VEVENT STATUS:CONFIRMED TRANSP:OPAQUE DTSTAMP:20150731T090403Z DTSTART;VALUE=DATE-TIME;TZID=UTC:20150728T130000 DTEND;VALUE=DATE-TIME;TZID=UTC:20150728T140000 SEQUENCE:2 SUMMARY:COEL-TC Call LOCATION:Teleconf (see below) LAST-MODIFIED:20150731T090403Z ORGANIZER:workgroup_mailer@lists.oasis-open.org DESCRIPTION:Pass code: 46620642\n\nUnited Kingdom 08000234295 0207635180 8 +44 2076351808\nUnited States 18662486013 17183541170\n\nA ustralia 1800004583 0282239344 +61 282239344\nAustria 080029 1639 0179567791 +43 179567791\nBelgium 080080213 027133682 + 32 27133682\nCanada 18667425609\nChina 108008520981\nChina 1 08001520981\nFinland 0800112578 0969379596 +358 969379596\nF rance 0805770046 0157323695 +33 157323695\nGermany 080070050 13 069945192088 +49 69945192088\nGreece 0080044141240\nIndia 0008004401045\nIreland 1800946925 012421054 +353 12421054\n Italy 800782318 0291483678 +39 0291483678\nJapan 00348004005 53 0357674201 +81 357674201\nNetherlands 08000223510 0202013 854 +31 202013854\nPortugal 800844385 214154495 +351 2141544 95\nRussia 84955453544 +7 4955453544\nSingapore 8008523488 6 4155063 +65 64155063\nSpain 900810179 912757175 +34 91275717 5\nSwitzerland 0800562604 0448009450 +41 448009450\nUnited K ingdom 08000234295 02076351808 +44 2076351808\nUnited States 18662486013 17183541170\n\n \n\nAgenda: We agreed last week to review the latest security topics. See below:\n\n[1] Use SSL for all internet communications within the ecosystem. T his creates an encrypted channel for the data (Atoms\, Repor ts and Pseudonymised Keys &ndash\; no DIPI) and prevents a t hird party from reading it in transit. It means that servers like the IDA\, Data Engine and any Service Provider/ or Ope rator systems must have SSL certificates (between £\;10 0 and £\;300 pa cost or see https://letsencrypt.org/)\n \n[2] Use single factor authentication (user-id and password ) for all Data Engine and IDA calls with the exception of: [ a] submitting atoms which can be done anonymously [b] an ope rator registering consumers with the DE (see below for why)\ n\n[3] Use IDA generated pseudonymous keys as the user-ids f or actors in the ecosystem. These are devoid of DIPI and uni que across the ecosystem.\n\n[4] Use different user-ids AND different passwords for each embodiment (e.g. for Operator w ith IDA\, Operator with DE\, Service Provider with different DEs etc)\n\nLet&rsquo\;s look at the systems/interactions t o see what the threats are:\n\n[1] Operator / IDA: Disclosur e of M2M credentials would allow an attacker to generate Pse udonymous Keys on behalf of an operator. There is no possibi lity of disclosure of DIPI or behavioural data. Risk is low. \n\n[2] Service Provider / IDA. Disclosure of SP interactive login would allow attacker allocate new OperatoIDs or disab le existing OperatorIDs. The IDA will not keep any DIPI for operators and their IDA passwords are stored encrypted so th ere is no risk of these being disclosed. If an attacker gain s access then the Service Provider will need to change their password and re-register its operators.\n\n[3] Operator / D E: Disclosure of operator credentials would allow an attacke r only to register consumers as the operator has no other ro le with the DE. With this in mind Matt and I agreed that the re is no need for an operator password when registering a co nsumer with the DE. Registering is similar to submitting an Atom.\n\n[4] Service Provider / DE: This is where the highes t threat is. Disclosure of credentials that gave access to t he Data Engine Management Interface (MI) and Query Interface (QI) would open up two possible attacks:\n\n[a] An attacker can query the tree of operators and consumers (via MI) and then retrieve all Atoms for all consumers for the SP (via QI ).\n\n[b] An attacker can use the MI to issue &lsquo\;forget &rsquo\; requests for consumers. This would result in either deleting all the atoms\, or disconnecting the atoms from th eir original consumer ID. It would render the atoms useless to the SP because by definition these are not reversible.\n\ nTo reduce the likelihood of [a]\, we should mandate that se parate credentials be used to access the MI and QI\, reducin g the likelihood of getting both.\n\nTo reduce the likelihoo d of [b]\, the data engine must use a secondary method to as sert the identity of the service provider. Forgetting is a r are event and insisting that there be a human in the loop wi ll make it more secure. We can mandate that the DE send an a uthorisation email to the SP asking it to confirm the forget request. (Unlikely attacker has access to this mailbox). Or the DE can mandate a second factor of authentication for fo rget requests such as a handheld RSA key\n\n[5] Operator/SP. Where the operator is a separate entity (such as in the GP/ AI scenario)\, it will request reports on consumers from the SP\, but these reports are pseudonymised so contain no more information than the query returned from the DE. The operat or adds in the DIPI itself. Low risk.\nGroup: OASIS Classifi cation of Everyday Living (COEL) TC\nCreator: Dr. David Snel ling URL:https://www.oasis-open.org/apps/org/workgroup/coel/event.php?event_id=40673 UID:https://www.oasis-open.org/apps/org/workgroup/coel/event.php?event_id=40673 BEGIN:VALARM ACTION:DISPLAY DESCRIPTION:REMINDER TRIGGER;RELATED=START:-PT00H15M00S END:VALARM END:VEVENT END:VCALENDAR
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]