Re: [TLS] foaf+tls for distributed social networks - 2 questions

[Bruno Harbulot <Bruno.Harbulot at manchester.ac.uk>]

Hello,

Nikos Mavrogiannopoulos wrote:
> Henry Story wrote:
> > Dear TLS experts,
> >
> > We are working on a very simple protocol for distributed identity in a
> > web of trust that uses TLS in a novel way. The details of this are short
> > and can be found online [1]. Here I'd first just like to ask two
> > questions, to get into the heart of the problem, then I'll explain why
> > these came up.
>
> After the explanation and seeing the protocol description I still do not
> understand why you need the client certificate for what you want to
> achieve.  Why you don't send the information you need for foaf on the
> application layer (if it is http via a cookie etc)? Why send a dummy
> certificate and add some extensions on it? Also the security offerings
> are not clear to me. What will that protocol offer, security-wise?

As an authentication mechanism, the main goal of FOAF+SSL is to bind the 
client to the URI (of a foaf:Agent), in the same way as the client would 
be bound to a Subject DN in a PKI.

In short, FOAF+SSL certificates are X.509 certificates that contain a 
public key and foaf:Agent URI in its subject alternative name extension; 
more or less all the rest is ignored. (For people not familiar with 
FOAF, foaf:Person is a subclass of foaf:Agent that models a person, for 
example.)

To compare FOAF+SSL and PKI: what binds the client to a Subject DN is 
both (a) the TLS handshake (which links the client the holder of the 
private key matching the public key in the client cert) and (b) the 
verification of the actual certificate (certification path to trust 
anchor, etc.)
FOAF+SSL also uses the fact that the client presents both an identity 
claim (its foaf:Agent URI in the client certificate instead of an X.500 
Subject DN) and the public key (which matches the private key the client 
actually has). Only the evaluation of trust in the client-certificate 
changes. At this stage, whether the client certificate is self-signed or 
signed by another party isn't particularly important, since it's not 
what's used to verify its content.

There are two ways of verifying the certificate in FOAF+SSL, and the 
security offerings are significantly different: dereferencing and 
cryptographic web-of-trust.


A. Dereferencing

Dereferencing is the main method explained on Henry's blog [1][2]. (I 
should point out that Henry's use of "web of trust" is more about how 
individuals link to each other in a social network and doesn't 
necessarily involve signing those assertions, as in OpenPGP, which makes 
it somewhat different from a "cryptographic" web of trust).

It works as follows:
  1. The client presents a certificate (self-signed or not) that 
contains a URI (such as <https://romeo.example/#me>, a foaf:Agent), and 
a public key.
  2. The server dereferences this URI (i.e. does an HTTP GET) and 
processes the content of the document, which will contain a public key 
associated to this URI.
  3. If the public key in the dereferenced document for this URI and 
the public key in the client certificate match, then the verification is 
successful.

The security of this verification model depends on how much the 
authenticating server can trust the authenticity of document that was 
obtained by dereferencing the URI. In particular, it must trust the 
server certificate of 'romeo.example' and the fact that no one tampered 
with the file on that server.

This level of security is suitable for some applications, but probably 
not all.


B. Cryptographic web of trust

I've talked a bit more about this on my own blog [3]. It's possible to 
sign sub-graphs asserting the links between an ID (the URI) and a public 
key.
This way, one could have a set of trust anchors under the form of a 
local/trusted FOAF file (or something else) against which to evaluate a 
certificate (à la OpenPGP). Similarly, a hierarchical model could be 
built. The level of assurance here depends on how much you trust the 
trust anchors and potential introducers; it's likely to be greater than 
with the dereferencing method.



The security levels are quite flexible, and systems using FOAF+SSL for 
authentication and authorisation ought to be configured according to the 
requirements of the application (like any system, I suppose). When we 
say that FOAF+SSL is a secure protocol, we really ought to qualify that 
assertion.

The advantage of the FOAF+SSL approach (putting the information in an 
X.509 certificate as opposed to creating another type of certificate) is 
that this works without modifying the implementation of SSL/TLS stacks. 
The only changes required are in the customisation of the evaluation of 
trust in a client certificate.
This requires some specific configuration in the application, but no 
changes of the SSL-related libraries themselves if they have such hooks 
(JSSE and OpenSSL work, at least). In fact, for development purposes, 
we've accept any certificate during the handshake and do the 
verification at the application level.


The original questions that Henry sent were related to the way the 
browser chooses a certificate (or asks the user to choose). Because the 
FOAF+SSL certificate is self-signed, the server has to be configured 
with an empty list of CAs in the CertificateRequest. This is the same 
problem as the one addressed in Section 3.4 of RFC 5081 [4].
To make the choice of certificate easier in the browser, we had thought 
of having an "open CA", for which we would distribute the private key 
openly, just for the sake of making the servers add that CA in the 
CertificateRequest list. I've since realised that we don't really need 
that, since only the name matters: we could just make the server ask for 
a conventional name and the self-signed client certificate would have 
that issuer name [5]. Of course, this wouldn't be compliant with RFC 
5280 [6].


We would be interested in feedback regarding this approach, in 
particular whether this would break with further versions of TLS.


Best wishes,

Bruno.



[1] http://blogs.sun.com/bblfish/entry/foaf_ssl_adding_security_to
[2] http://blogs.sun.com/bblfish/entry/more_on_authorization_in_foaf
[3] 
http://blog.distributedmatter.net/post/2009/03/07/Signing-FOAF-files%3A-FOAF-files-as-certificates
[4] http://tools.ietf.org/html/rfc5081#section-3.4
[5] 
http://lists.foaf-project.org/pipermail/foaf-protocols/2009-April/000450.html
[6] http://tools.ietf.org/html/rfc5280