[foaf-protocols] MashSSL - Some Clarifications

Ravi Ganesan ravi at findravi.com
Mon Nov 2 03:50:38 CET 2009


Hi,

Just thought I'd  add some clarifications Re. the  MashSSL related posts on
this list. Please see some related comments on SSL-FOAF at end. I believe
our work may be relevant to you, and welcome your participation in our XG.

The W3C MashSSL Incubator XG is absolutely NOT intended to in any way work
on end user identity. It is really all about a standard for allowing
applications/servers to securely identify each other and establish a shared
session key. SSL of course performs this function admirably at the transport
level for client-server or server-server communication. MashSSL allows this
to happen for server - browser - server communication, under the assumption
that the user in the middle could be an adversary. More specifically the XG
is focussed on when this communication is happening over HTTP. (as opposed
to over TCP). We are aware of (and reference) other work for SSL that has
been proposed or developed (e.g. over UDP).

Some use cases where MashSSL could be useful:

- To take a really old example, if you want a payment button on an eCommerce
site, one method of implementation often offered is to communicate via the
user's browser. Knowing that the user could cheat, proprietary crypto is
usually required, and the merchant has to get and manage credentials for
each provider they implement.

- To take a very recent example, if your web site is willing to service
cross domain XHR requests from Sites A, B and C; you really have to
completely trust the ORIGIN header in the request. If you have to protect
against a malicious user, you need to roll your own handshake crypto.

- And there are many other examples of protocols such as SAML, OpenID,
OAuth, 3D Secure which can benefit by being run over a MashSSL pipe

The underlying theme is: i) This problem occurs again and again, ii) Might
as well fix it ONCE and let all the other protocols run on top of it, rather
than invent new crypto each time we encounter it, and (iii) instead of a
single brand new protocol (which could take years to discover and work out
the security kinks from), lets find a way to use the SSL handshake, and the
SSL credential infrastructure.

Potential way to mash MashSSL and FOAF+SSL:

FOAF-SSL is new to me, so apologies in advance if I am mis-characterizing
something. Based on http://www.w3.org/2008/09/msnws/papers/foaf+ssl.html,
the core idea of FOAF+SSL is for a
(i) user to have a digital cert and private key locally which happens to
have an extension containing the URL for their foaf.
(ii) Any server they are accessing can turn on client auth in SSL. The
resulting SSL session allows the server to retrieve the URL in the user's
cert. and
(iii) The server can then go retrieve the foaf at that URL, and if the foaf
contains the same cert, then the server has authenticated the user, and
securely retrieved their cert.
This is elegant, as unlike an attribute certificate, which would stick the
foaf in the cert, this allows the foaf to change and only requires the uri
to be static. It is a neat inverse of the more traditional let me get the
cert, and use the DN to index into an LDAP directory to get the data. (Btw I
am not convinced it works with self signed certs, as even if the user adds
the self signed cert to the trusted roots part of the browser store (in
addition to in the user cert portion), the server would need to know the
root a priori in order to 'turn on client auth'. And even if this were
somehow possible, most web servers require you to provide the list of
trusted roots at start up time.)

Before asking HOW MashSSL can be mashed with foaf-ssl let me first
articulate WHY you may want to do this...  There are two limiting factors in
the current foaf-ssl design. First, it requires the deployment of client
side certs. Especially in the consumer context, I am afraid this is a lost
cause. Second, it requires 'turning on client authentication' in SSL, which
is unfortunately also extremely hard. SSL terminates in unexpected places
far from the application logic. SSL is the 'network persons' responsibility
not 'app persons'. SSL accelerators do not work as advertized... the list is
long. On a deeper level, user identity is a Layer 7 concern if you will.
Extracting the information from the transport is architecturally limited. I
will admit I am potentially more cynical than most, but I have been working
on 'making end user pki easy', 'practical pki' on and off since 1991, and
spent a lot of the first six years of this decade trying my best to persuade
people of all stripes to 'just turn on client side SSL', and I now believe
this is a lost cause. I do not believe anything has changed in 2009 to have
removed the very very long set of objections enterprises have raised to end
user pki.

The MashSSL approach would be to run MashSSL between (to use the example in
http://www.w3.org/2008/09/msnws/papers/foaf+ssl.html) between romeo.net and
juliette.net through the user's browser. If romeo.net is implemented such
that it will only participate in such a connection if it is assured of the
identity of the user (MashSSL does not care what authentication mechanism is
used), then juliette can be certain she is truly getting the foaf from
romeo.net and is assured that romeo.net is satisfied she has the correct
user on the wire.  One way to think about what MashSSL is actually doing,
is to take the client side certificate mgmt, and crypto processing that
foaf-ssl has happening at the client, and to run that remotely at
romeo.netitself. i.e. the desktop is moving the 'pki processing' to
the cloud..

This resulting foaf+mashssl  I believe has all the benefits of foaf+ssl but
does not require a client certificate or require turning on client auth in
ssl.  It does require the app developer to use a MashSSL library (until such
time that web application servers potentially provide the functionality
natively).

Cheers,
Ravi
p.s.: Regarding the question on why the name MashSSL.... the inventor is not
known for his marketing skills....
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20091101/ee3e5446/attachment.htm 


More information about the foaf-protocols mailing list