Re: [foaf-dev] Re: privacy and open data

Someone friendly sent me the following  mail personally. Since he may  
well be expressing what many are thinking, I thought I would respond  
to his criticism, in public whilst keeping his name confidential.

On 26 Mar 2008, at 14:25, someone write wrote:
> Dear Mr. Story,
>
> forgive me for saying this, but you need to listen to Alan  
> Ruttenberg when he says that creating a security protocol is a job  
> for a security expert.   Or just follow the general security maxim:  
> "don't roll your own!".

You are right I am not a security expert. I am a security consumer.  
Currently I am writing a semantic Address Book which I describe how to  
build at the end of this post

http://blogs.sun.com/bblfish/entry/opening_sesame_with_networked_graphs

This currently works very well for reading openly published foaf  
files, and it shows the power of linked data, and how it solves the  
problem recently so clearly exposed by The Economist, in their article  
on "Online Social Networks"

http://www.economist.com/business/displaystory.cfm?story_id=10880936

The core functionality that is missing in such open social networks  
currently is a way to reveal more or less data to some people, and not  
to others.
What I am looking for is a way to get this functionality with  
approximately the same level of security as the current social  
networks have, since those are the people I am trying to convince. And  
I am trying to do this for a RESTful Semantic Web application.

Now I am not looking for absolute security. If there are more secure  
methods those will be useful in the future, but probably not right now  
for this project. As a consumer I can set criteria on the types of  
things I need, the levels of security required. That is a basic  
guideline I learnt by reading the little security literature I cam  
across.

What I was proposing were some criteria of what would be acceptable as  
the next step to allow foaf and Beatnik help solve the problem The  
Economist was describing. I was not proposing a solution, though in  
the process of thinking about this I came to wonder whether there  
might not be some very simple solutions. Simplicity is very important  
here, as everything web related has to be designed to allow a large  
number of people to join.
And it is also important because I don't have that many resources at  
my disposal when programming this.

>   The basic issue is that good engineers tend to look at what works;  
> security people look sideways at how things can break - and in  
> breaking entirely unexpected thing, that you didn't even know you  
> needed to protect.  I currently work in security software, have an  
> MSc in Information Security, and would be very nervous myself to  
> propose an entirely new authentication protocol.
>
> I can see some basic weaknesses in your scheme off the top of my  
> head.  First off, you talk about encrypting the URI of the resource  
> using asymmetric key encryption.  Public key encryption is very  
> computationally expensive - typically, you would use a digital  
> signature here (usually calculated on a hash of the message).   Of  
> course, since you are passing the athentication secret to the  
> service, I take it you are mandating SSL encryption for this part of  
> the communication protocol, or some other way of protecting the  
> confidentiality of the secret?  Just encrypting the URI provides no  
> protection against third parties, as that is all that is required to  
> access the service.   Otherwise, you're just passing a password in  
> the clear over the open internet.

Yes, that sounds right.
So there has to be a way to reduce the computational cost. I suppose  
that is why there are login services that require a one time  
authentication cost, which then allows further communication over ssl.

> Your scheme also provides no "liveness" assurance - it is completely  
> vulnerable to replay attacks.  You do mention using a nonce  
> somewhere, but don't define how it will be used.

Well that is where I was hoping a security expert could advise me :-)  
I saw that openid uses a nonce to avoid replay attacks, so I thought I  
would need one too :-)

> The service itself is seriously exposed to denial of service attacks  
> - it must perform a FOAF file lookup and parse, a public key lookup,  
> followed by a public key decryption (or signature verification) for  
> every authentication request it receives.  It would be very easy to  
> take that service offline by bombarding it with fake requests.

But that is also true of OpenId. Even more so, because the OpenId  
requires a dynamic service, whereas a PGP key file is a RESTful  
service. Ie. it can easily be cached by proxies along the way. A PGP  
key does not change much. The HTTP header of the PGP key can specify  
the longevity of the key, and the service on the other end can  
therefore cache the representation. The same is true of the foaf file.

In short the problem with OpenId is that it is not completely RESTful.  
Especially the latest version. I was hoping one could solve this  
problem.

> Anyway, just some thoughts off the top of my head.  Hopefully I can  
> convince you that this is not a job for a non-security expert, and  
> frankly, probably isn't something that needs re-inventing.

Thanks for helping me point out that I am not hoping to do this as a  
security expert, but rather that I am a consumer with some  
architectural design guidelines looking for security experts to help  
me out.

:-)

> Regards,
>
> someone.
>
>
> On Wed, Mar 26, 2008 at 12:36 PM, Story Henry  
> <henry.story@bblfish.net> wrote:
> On 26 Mar 2008, at 13:11, Alan Ruttenberg wrote:
> >
> > The Handle system has a specification for encryption. My feeling is
> > that if you want to build something that will scale and last you
> > should do this carefully and properly secure. I'm not a security
> > expert, but this is a job for one of those.
> >
> > http://www.handle.net/rfc/rfc3652.pdf
>
> Thanks for the pointer. This looks way too complicated for what I am
> looking for. Or rather it does not seem to build well on what most
> people know. (The web standards are in   quite complex too but they
> are well known)
>
> I don't think there is a need for identifiers. We have some that are
> well understood, globally used, widely deployed and known as URIs.
> http URIs are the most widely used and are excellent identifiers for
> documents as well as things, as the Semantic Web has taught us.
>
> Also the security level I am looking for at present is at the level of
> openid or better.
>
> I think my suggestion is as good as openid or better. It is better at
> least as far as privacy goes, as it does not require a authentication
> service. The openid authentication services is usually hosted by some
> service provide (Yahoo, Microsoft, ...) which can use this role to
> gather information on what services people are using on the internet.
> True one can start one's own service, but this is not usually  
> accepted.
>
> It is probably more secure, just because it is simpler: it requires
> just a foaf file, and a public key located at a URL. The simpler
> something is, the less likely it can break.
>
> Henry
>
>
> > -Alan
> >
> > On Mar 26, 2008, at 7:36 AM, Story Henry wrote:
> >
> >>
> >> On 25 Mar 2008, at 19:04, Story Henry wrote:
> >>>
> >>> On 25 Mar 2008, at 18:59, Julian Bond wrote:
> >>>> Benjamin Nowack <bnowack@semsol.com> Tue, 25 Mar 2008 15:51:08
> >>>>> That's as simple and close to existing mechanisms as I could get
> >>>>> it.
> >>>>> Unlike OpenID and oAuth, there is no need for redirects, so
> >>>>> RDFAuth works
> >>>>> for non-browser agents, which was my main requirement.
> >>>>
> >>>> I feel like I'm missing something here. oAuth was built
> >>>> specifically to enable non-browser agents and non-UI applications
> >>>> to have good authentication. And it feels like you're re-
> >>>> inventing oAuth. And I'm not sure why.
> >>>
> >>> Well I may be reinventing it because its obvious. Which would be
> >>> good :-)
> >>> Let me check it out, since it comes up again and again.
> >>
> >> Ok, so I read the initial incomplete getting-started documentation
> >> on oAuth, and quickly perused the spec. There are parts that are
> >> interesting and may be useful, and also I may have missed some
> >> important bits. My initial feeling is that oAuth could be a lot
> >> better if it made use of Linked Data [1].
> >>
> >> Just from reading the getting started documentation I had the
> >> following reservations:
> >>
> >> - I am not looking for one time authorisation to access resources,
> >> which is what oAuth provides.
> >> - A client such as the Beatnik Address Book is not a web client. It
> >> is a Semantic Web client. So the User Agent is a consumer of data,
> >> not of human readable content. oAuth seems to be designed for
> >> reading human consumable web pages. The human reading the site has
> >> a few things to read, then gets redirected, then enters his
> >> password in his old site, then gets redirected again. As a result
> >> his pictures that belonged to one site now appear in another web
> >> site, ...
> >> - I have a feeling that the oAuth protocol is a pairwise protocol.
> >> It seems that every site has to get into a contract with every
> >> other web site they want to do business with for this to work. I
> >> don't see this scaling as it is. Perhaps with semantic help it  
> could.
> >>
> >> What I am looking for is even simpler than oAuth at the first
> >> level. I want simply the server to be able to decide what
> >> representation to return to a user. The user is initially (usually)
> >> not identified. So the resource should know how to return a default
> >> representation, and let the client know that more information is
> >> available. If the user identifies himself then more information is
> >> made available. What the server decides to make available or not is
> >> not of interest here. Presumably the server has a notion of groups
> >> and a notion of information that can be made available to members
> >> of these groups.
> >>
> >> Since the best way to identify a user is with a URI, a la foaf, we
> >> should use a URI identifier. Note, this need not be a person. It
> >> could also be a foaf:Agent. In order to help make sure that the
> >> user is who he says he is, he encrypts a string (eg. the uri of the
> >> requested resource appended with a nonce) with a pgp private key
> >> that is available from his identifier. (use of linked data)
> >>
> >> I don't think one can do simpler than that.
> >>
> >> Now on top of that I can imagine a service like oAuth being built.
> >> So let us give the Beppa eco friendly printing site a foaf file
> >>
> >> http://beppa.com/#company
> >>
> >> which could be encoded in rdfa in the html of the front page. [2]
> >>
> >> then what is needed would be a way for beppa to ask to be added to
> >> a group which gives short term access to resources belonging to
> >> another agent (why not identify him via his foaf id?). This seems
> >> to be all that oAuth is doing. Once that is settled, we are back to
> >> our very simple use case described above. Beppa could then ask for
> >> the resources by identifying itself as beppa, and the server could
> >> then return the correct representations. So it seems one could
> >> build one on top of the other.
> >>
> >> So from what I have read at present I think at first what is needed
> >> is just the very simple protocol a la RDFAuth that was mentioned
> >> previously. More complex services can be built on to of that.
> >>
> >> Does that sounds right? Have I missed something important?
> >>
> >>      Henry
> >>
> >>
> >>
> >> [1] http://blogs.sun.com/bblfish/entry/hyperdata_and_folktologies
> >> [2] http://blogs.sun.com/bblfish/entry/a_foaf_file_for_sun
> >>
> >>
> >>
> >>> Henry
> >>>
> >>>
> >>>> --
> >>>> Julian Bond  E&MSN: julian_bond at voidstar.com  M: +44 (0)77
> >>>> 5907 2173
> >>>> Webmaster:          http://www.ecademy.com/      T: +44 (0)192
> >>>> 0412 433
> >>>> Personal WebLog:    http://www.voidstar.com/     skype:julian.bond?chat
> >>> _______________________________________________
> >>> foaf-dev mailing list
> >>> foaf-dev@lists.foaf-project.org
> >>> http://lists.foaf-project.org/mailman/listinfo/foaf-dev
> >>
> >
>
>