[KI-LC] [BoT] Round 2 FTC Kantara Input regarding Security and Privacy

Ingo.Friese at telekom.de Ingo.Friese at telekom.de
Wed May 29 10:12:37 CDT 2013


Ken,

I agree regarding the paper.
Just one more explanation regarding the example.

Let's say the truck uses a contactless authentication tool. Let's say SIM card. As soon as the truck passes the gate it is authenticated.
Someone can take the same SIM card to another truck. In the "Human identity" you can prevent this by using e.g. PIN or security question.
Like you said the driver could type in a PIN. But this is Humen IdM and not full automatic IoT.

What we want to do, if someone puts a faked barcode to a product?
In our lets say "Human IdM" we can challenge a person, with password, security question etc. ...but what to do with a product?

Best,

Ingo


From: Dagg, Kenneth [mailto:Kenneth.Dagg at tbs-sct.gc.ca]
Sent: Mittwoch, 29. Mai 2013 16:49
To: Friese, Ingo; 'joni at ieee-isto.org'
Cc: 'Smedinghoff at wildman.com'; 'email at colinsoutar.com'; 'LC at kantarainitiative.org'; 'trustees at kantarainitiative.org'; 'anna.slomovic at equifax.com'; 'mark.lizar at gmail.com'
Subject: RE: [KI-LC] [BoT] Round 2 FTC Kantara Input regarding Security and Privacy

Ingo,

I would suggest that the use-cases where it appears that access-control (as it currently is known) need to be re-examined with a view to either updating the use-case or access-control.

For the use-case of a truck accessing Hamburg harbor I am not clear why the truck is not able to authenticate. It may not be able to provide a traditional LOA2 username/password but it should be able to provide some sort of equivalent LOA2 token. Or maybe the truck, the driver and the truck-driver association are all validated and access-control is strengthened.

The "fake" product scenario is also interesting.  However, it is very similar, at least in my mind, to ensuring that the credential remains under the control of the entity (a part in this case) to which it was issued and that it is not a "fake/counterfeit" credential.  These are challenges that high-level (2 and above) authentication is supposed to address.

It is my still my belief (I'm not sure how yet) that a vast majority of these scenarios should be addressable / enhancable by the approaches suggested in Attribute Based Access Control (ABAC). That is not to say that we won't have to explore new and different directions but rather that we work hard to scope the these to a few exceptions rather than the norm.

All this being said, I would endorse the approach that Kantara's contribution should be a light touch at this time. I would endorse Colin's suggestion that we use our response to raise some issues/questions and identify some potentially applicable approaches that don't leave people with the impression that the IoT is a brand new thing.

Ken

Kenneth Dagg
Senior Project Co-ordinator | Coordonnateur de projet supérieur
Security and Identity Management | Sécurité et gestion des identités
Chief Information Officer Branch | Direction du dirigeant principal de l'information
Treasury Board of Canada Secretariat | Secrétariat du Conseil du Trésor du Canada
Ottawa, Canada K1A 0R5
Kenneth.Dagg at tbs-sct.gc.ca<mailto:Kenneth.Dagg at tbs-sct.gc.ca>
Telephone | Téléphone 613-957-7041 / Facsimile | Télécopieur 613-954-6642 / Teletypewriter | Téléimprimeur 613-957-9090
Government of Canada | Gouvernement du Canada

[cid:image001.gif at 01CE5C8E.7A07DC50]

From: Ingo.Friese at telekom.de<mailto:Ingo.Friese at telekom.de> [mailto:Ingo.Friese at telekom.de]<mailto:[mailto:Ingo.Friese at telekom.de]>
Sent: May-29-13 10:27 AM
To: joni at ieee-isto.org<mailto:joni at ieee-isto.org>; Dagg, Kenneth
Cc: Smedinghoff at wildman.com<mailto:Smedinghoff at wildman.com>; email at colinsoutar.com<mailto:email at colinsoutar.com>; LC at kantarainitiative.org<mailto:LC at kantarainitiative.org>; trustees at kantarainitiative.org<mailto:trustees at kantarainitiative.org>; anna.slomovic at equifax.com<mailto:anna.slomovic at equifax.com>; mark.lizar at gmail.com<mailto:mark.lizar at gmail.com>
Subject: RE: [KI-LC] [BoT] Round 2 FTC Kantara Input regarding Security and Privacy

Hi Joni,
Hi Ken,

Thank you for revising the paper. I like it. Joni I agree, this should be (like you said) a n early light touch contribution.
Ken , thank you for your comments. Let me try to answer:

Frist of all it would be great if we could apply access control as known also to the IoT, because we don't want to re-invent the wheel.
Unfortunately we have many use-cases where the old way won't work.
e.g.: A truck accessing Hamburg harbor is not able to use username/password for authentication. In this case we need generic identifiers and other ways for authentication
Another example - faked products or machine parts (companies think they bought a high-tech Siemens rotor - and they get a low cost plagiarism).
So how to check and authenticate parts online along their way from production to the customer? I think sometimes we can apply known access control stuff and sometimes we have to go new directions.


Regarding your architecture comment : You are right, we should help to develop an IoT architecture at least from an IdM part of view.

Joni it's a good paper (considering the few days we had for preparation). Like Colin said lets integrate, e.g. the architecture remark etc. and that's it.


Best regards,

                Ingo


From: lc-bounces at kantarainitiative.org<mailto:lc-bounces at kantarainitiative.org> [mailto:lc-bounces at kantarainitiative.org] On Behalf Of Joni Brennan
Sent: Donnerstag, 23. Mai 2013 21:35
To: Dagg, Kenneth
Cc: Smedinghoff, Tom; Colin Soutar; LC at kantarainitiative.org<mailto:LC at kantarainitiative.org>; trustees at kantarainitiative.org<mailto:trustees at kantarainitiative.org>; Anna Slomovic/Equifax; Mark Lizar
Subject: Re: [KI-LC] [BoT] Round 2 FTC Kantara Input regarding Security and Privacy

Thank you for the comments Ken.  I will seek to work them in to a next draft.  The paper is very comprehensive and the original intent of LC was to make an early light touch contribution.  Note that there is likely soon to be an Identity of Things (IDoT) DG in Kantara which would explore the issues in much more detail and then potentially develop some recommendations about how Kantara might provide value in the space etc.  Modeling that you described could very likely be a part of the IDoT DG early approach if not as recommended for a WG to take action on.
We continue to welcome comments from others as well.
Best Regards,
Joni

On Thu, May 23, 2013 at 12:29 PM, Dagg, Kenneth <Kenneth.Dagg at tbs-sct.gc.ca<mailto:Kenneth.Dagg at tbs-sct.gc.ca>> wrote:
Joni,

I reviewed the document and found some shortcomings. My personal concerns could be mitigated if there are other documents that describe the context of the Internet of Things (IoT). I have used COMMENTS to voice my personal concerns. My apologies, but given the short turnaround time, I regret not being able to recommend how the text could be changed but I just do not have the cycles.

It appears to me, with my minimal technical knowledge about the IoT, that the basic concepts of Access Control should apply to the IoT. If this is true, then I would suggest that a lot of the privacy and security implications have been identified. The prime difference, in my personal opinion, with traditional Access Control is the components, like they are in Trust Frameworks and Federations, are decoupled.

I also believe that a conceptual architecture of the IoT needs to be developed (if it already exists then I stand corrected). Without this type of understanding, it is my personal opinion that any standards / frameworks / infrastructures that are developed will be tend to be restrictive rather than accommodating. If my belief that Access Control applies then the architecture may essentially be done (could be based on the Attribute Based Access Control - NIST Special Publication 800-162).

The conceptual architecture would also include an architecture for "things" that identifies the type of information they contain, its functions (e.g., authentication), etc.

Ken

Kenneth Dagg
Senior Project Co-ordinator | Coordonnateur de projet supérieur
Security and Identity Management | Sécurité et gestion des identités
Chief Information Officer Branch | Direction du dirigeant principal de l'information
Treasury Board of Canada Secretariat | Secrétariat du Conseil du Trésor du Canada
Ottawa, Canada K1A 0R5
Kenneth.Dagg at tbs-sct.gc.ca<mailto:Kenneth.Dagg at tbs-sct.gc.ca>
Telephone | Téléphone 613-957-7041<tel:613-957-7041> / Facsimile | Télécopieur 613-954-6642<tel:613-954-6642> / Teletypewriter | Téléimprimeur 613-957-9090<tel:613-957-9090>
Government of Canada | Gouvernement du Canada

[cid:image001.gif at 01CE5C8E.7A07DC50]

From: trustees-bounces at kantarainitiative.org<mailto:trustees-bounces at kantarainitiative.org> [mailto:trustees-bounces at kantarainitiative.org<mailto:trustees-bounces at kantarainitiative.org>] On Behalf Of Joni Brennan
Sent: May-23-13 2:10 PM
To: trustees at kantarainitiative.org<mailto:trustees at kantarainitiative.org>; LC at kantarainitiative.org<mailto:LC at kantarainitiative.org>
Cc: Smedinghoff, Tom; Mark Lizar; Colin Soutar; Anna Slomovic/Equifax
Subject: [BoT] Round 2 FTC Kantara Input regarding Security and Privacy

Hello,

Thank you Ingo for your first take at the FTC comments [1]!  I have edited them slightly and made some contributions to the document.
Please see attached.  Trustees and LC please advise of suggested inclusions or edits for the document.  I'm hopeful that some of our Privacy based membership will have additional comments. (I've copied a few of you directly but this is an open paper so don't hesitate to add others!)
Ideally we need to have the document finalized by May 29 (with no LC objections).  I would then like to submit the document as the Kantara ED and on behalf of the Leadership Council.
Please advise with any further comments or considerations to this activity.

[1] http://www.ftc.gov/opa/2013/04/internetthings.shtm
Best Regards,
Joni

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/lc/attachments/20130529/7ee84335/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 7226 bytes
Desc: image001.gif
URL: <http://kantarainitiative.org/pipermail/lc/attachments/20130529/7ee84335/attachment-0001.gif>


More information about the LC mailing list