Re: [TLS] foaf+tls for distributed social networks - 2 questions
Bruno Harbulot <Bruno.Harbulot@manchester.ac.uk> Fri, 24 April 2009 14:15 UTC
Return-Path: <Bruno.Harbulot@manchester.ac.uk>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABD843A6AD9 for <tls@core3.amsl.com>; Fri, 24 Apr 2009 07:15:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.799
X-Spam-Level:
X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCGeq4ofgTJ2 for <tls@core3.amsl.com>; Fri, 24 Apr 2009 07:15:11 -0700 (PDT)
Received: from serenity.mcc.ac.uk (serenity.mcc.ac.uk [130.88.200.93]) by core3.amsl.com (Postfix) with ESMTP id 1B3233A6A8B for <tls@ietf.org>; Fri, 24 Apr 2009 07:15:10 -0700 (PDT)
Received: from kelvin.its.manchester.ac.uk ([130.88.25.195]) by serenity.mcc.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <Bruno.Harbulot@manchester.ac.uk>) id 1LxMCY-000Jzo-BF; Fri, 24 Apr 2009 15:16:26 +0100
Received: from mirabelle.rcs.manchester.ac.uk ([130.88.1.123]:55866 helo=mymachine) by kelvin.its.manchester.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <Bruno.Harbulot@manchester.ac.uk>) id 1LxMCY-0005Ri-6F; Fri, 24 Apr 2009 15:16:26 +0100
Message-ID: <49F1C9B7.9060504@manchester.ac.uk>
Date: Fri, 24 Apr 2009 15:16:23 +0100
From: Bruno Harbulot <Bruno.Harbulot@manchester.ac.uk>
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
References: <6CF4BBB1-9004-44B7-A08E-62BA8D1F9F86@Sun.COM> <49A7C991.5050309@gnutls.org>
In-Reply-To: <49A7C991.5050309@gnutls.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Authenticated-Sender: Bruno Harbulot from mirabelle.rcs.manchester.ac.uk (mymachine) [130.88.1.123]:55866
X-Authenticated-From: Bruno.Harbulot@manchester.ac.uk
X-UoM: Scanned by the University Mail System. See http://www.itservices.manchester.ac.uk/email/filtering/information/ for details.
Cc: Henry Story <Henry.Story@Sun.COM>, tls@ietf.org, foaf-protocols@lists.foaf-project.org
Subject: Re: [TLS] foaf+tls for distributed social networks - 2 questions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Apr 2009 14:15:12 -0000
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
- [TLS] foaf+tls for distributed social networks - … Henry Story
- Re: [TLS] foaf+tls for distributed social network… Nikos Mavrogiannopoulos
- Re: [TLS] foaf+tls for distributed social network… Henry Story
- Re: [TLS] [foaf-protocols] foaf+tls for distribut… Henry Story
- Re: [TLS] foaf+tls for distributed social network… Bruno Harbulot
- Re: [TLS] foaf+tls for distributed social network… Nikos Mavrogiannopoulos
- Re: [TLS] foaf+tls for distributed social network… Nikos Mavrogiannopoulos
- Re: [TLS] [foaf-protocols] foaf+tls for distribut… Henry Story