foaf+ssl: adding security to open distributed social networks

For the "W3C Workshop on the Future of Social Networking", taking place in Barcelona January 2009

Attending:
Henry Story
Contributors:
Bruno Harbulot, Ian Jacobi, Toby Inkster
Enthusiastic:
Melvin Carvalho

Semantic Web vocabularies such as foaf permit distributed hyperlinked social networks to exist. We would like to discuss a group of related ways we are exploring (mailing list) to add information and services protection to such distributed networks.

One major criticism of open networks is that they seem to have no way of protecting the personal information distributed on the web or limiting access to resources. Few people are willing to make all their personal information public, many would like large pieces to be protected, making it available only to a select group of agents. Giving access to information is very similar to giving access to services. There are many occasions when people would like services to only be accessible to members of a group, such as allowing only friends, family members, colleagues to post a blog, photo or comment on a site. How does one do this in a maximally flexible way, without requiring any central point of access control?

Using an intuition made popular by OpenID we show how one can tie a User Agent to a URI by proving that he has write access to it. foaf+ssl is architecturally a simpler alternative to OpenID (fewer connections), that uses X.509 certificates to tie a User Agent (Browser) to a Person identified via a URI. However, foaf+ssl can provide additional features, in particular, some trust management, relying on signing FOAF files, in conjunction with set of locally trusted keys, as well as a bridge with traditional PKIs. By using the existing SSL certificate exchange mechanism, foaf+ssl integrates more smoothly with existing browsers (pictures with Firefox) including mobile devices, and permits automated sessions in addition to interactive ones.

The steps in the protocol can be summarised simply:

  1. A web page points to a protected resources using a https URL, e.g. https://juliette.net/location
  2. The client fetches the secure http URL .
  3. As part of that exchange the server requests the client certificate. The client returns Romeo's (possible self signed) certificate, containing the little known X.509 v3 extensions section:
            X509v3 extensions:
               ...
               X509v3 Subject Alternative Name: 
                               URI:http://romeo.net/#romeo
    
    Because the connection is encrypted, Juliet's server knows that Romeo's client knows the private key of the public key that is also passed in the certificate. Something like:
          Subject Public Key Info:
                Public Key Algorithm: rsaEncryption
                RSA Public Key: (1024 bit)
                    Modulus (1024 bit):
                        00:b6:bd:6c:e1:a5:ef:51:aa:a6:97:52:c6:af:2e:
                        71:94:8a:b6:da:9e:5a:5f:08:6d:ba:75:48:d8:b8:
                        01:50:d3:92:11:7d:90:13:89:48:06:2e:ec:6e:cb:
                        57:45:a4:54:91:ee:a0:3a:46:b0:a1:c2:e6:32:4d:
                        54:14:4f:42:cd:aa:05:ca:39:93:9e:b9:73:08:6c:
                        fe:dc:8e:31:64:1c:f7:f2:9a:bc:58:31:0d:cb:8e:
                        56:d9:e6:da:e2:23:3a:31:71:67:74:d1:eb:32:ce:
                        d1:52:08:4c:fb:86:0f:b8:cb:52:98:a3:c0:27:01:
                        45:c5:d8:78:f0:7f:64:17:af
                    Exponent: 65537 (0x10001)
    
  4. Juliet's server dereferences the URI found in the certificate, fetching a document .
  5. The document's log:semantics is queried for information regarding the public key contained in the previously mentioned X.509. This can be done in part with a SPARQL query such as:
    PREFIX cert: <http://www.w3.org/ns/auth/cert#>
    PREFIX rsa: <http://www.w3.org/ns/auth/rsa#>
    SELECT ?modulus ?exp
    WHERE { 
       ?key cert:identity <http://romeo.net/#romeo>;
            a rsa:RSAPublicKey;
            rsa:modulus [ cert:hex ?modulus; ];
            rsa:public_exponent [ cert:decimal ?exp ] .   
    }                   
    
    If the public keys in the certificate is found to be identical to the one published in the foaf file, the server knows that the client has write access over the http://romeo.net/ resource.
  6. Romeo's identity is then checked as to its position in a graph of relations (including frienship ones) in order to determine trust according to some criteria . Juliet's server can get this information by crawling the web starting from her foaf file, or by other means.
  7. Access is granted or denied .

We have tested this on multiple platforms in a number of different languages, (Java™, Python, ...) and across a number of existing web browsers (Firefox, Safari, more to come).

foaf+ssl is one protocol that we would like to concentrate on due to its simplicity. But there are a number of other ways of achieving the same thing, by using OpenID for example. All of them require some extra pieces:

  • An ontology to describe what can be done with the data (copied, republished,...) or what obligations incur in using a service .
  • An ontology to describe who has access to the service. This would be useful to help people decide if they should bother trying to access it, or what else they need to do such as become friends with someone, or reveal a bug in the software somewhere .
  • Other things that might come up .

We will discuss our experience implementing this, the problems we have encountered and where we think this is leading us to next.

Comments:

A few more links for this:
- more on the authentication piece, or how one can have a web of trust without keysigning
http://blogs.sun.com/bblfish/entry/more_on_authorization_in_foaf
- The wiki page for foaf+ssl
http://esw.w3.org/topic/foaf+ssl
for the latest links and pointers.

Posted by Henry Story on January 17, 2009 at 09:47 AM CET #

Is signing the certificate in step (3) really necessary? I would expect the encryption of the communication to be (secure) enough. Or is this only done, because certificates are a standard format, and using unsigned plain text (=a new format) would be reinventing the wheel?

Posted by Axel Rauschmayer on September 01, 2009 at 10:36 AM CEST #

Axel, yes, I don't think you can have a valid x509 certificate if it is not signed. I don't know enough about x509 to know if this is justified or not security wise. It may remove the possibility of certain types of man in the middle attack... But I think this is mostly an constraint of x509. I may be wrong though.

Posted by Henry Story on September 01, 2009 at 04:04 PM CEST #

Post a Comment:
Comments are closed for this entry.
About

bblfish

Search

Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today