RE: WebID security picture

I've been playing with some Microsoft sample code for (RESTful) web
services, augmented with webid. Its specifically focuses on dynamic uses of
such as webid. It's hard to call it lightweight, but one can call it
commodity (since the ws-security standards it uses are in windows and java)

The sample has the following scenario: restful client (e.g. javascript in
browser page) uses local service-proxy to talk to service1. Service1
optionally exposes (signed) metadata, that induces metadata-based client to
first request return of a SAML token of an STS agent. (This request will be
augmented with webid and https, once I get it all working). The SAML token
and its response envelope communicate a symmetric key to the client's
service-proxy (rather like a SSL session key, in some sense). The webrequest
to the real service1 is then wrapped in a ws-trust envelope, signed and
sealed using service1's RSA encryption keys AND stamped with the symmetric
key known only to the STS, and the two entities. The service interceptor
strips off the ws-trust envelopes (this REALLY should remind you of s-http,
circa 1995!), and invokes the method of the service, setting cryptosession
variables in the host environment, for this service's endpoint. Subsequent
messages that execute web request/responses between these two entities
leverage keying derived from the session keys, so creating a liteweight
crypto-session(s) usable by REST for certain security purposes (NOT app
sessions!)

In the specific demo, service1 makes a further web call to service2,
projecting forward the client's SAML token. Service2 enforces access
controls using the client authority, not service1's authority.

The STS has an online signing key. IT basically translates a webid
connection into a dynamically signed STS token - and symmetric proof key
shared between certain SAML token recipients (service1, but not service2)
and the client. The resultant layer 7 (not 4) security context between
client and service then create a crypto session, quite similar (for crypto
101 folks) to an SSL session.

This is how Im getting passed the corporate firewalls, which block client
cert and client authn being used end-end, between client and service.
Obviously, the STS has to be WITHIN that firewall boundary. (Its running in
my browser, under opera unite.).

This is all a variation of Henry's demo of a webid-powered IDP. The only
different is that I'm using standards, rather than making up my own format
and having to sell them.

Now the other half of the experiment is to ensure that any webid procedure
is invoked when the signed STS token is received by the service1 security
interceptor. Though the "client cert" is not received from an https channel
(being received from a s-http-like, ws-trust channel instead), one notes
from the cert that this is usage of the webid'd cert IS authorized - since
it has the PKIX clientAuthn extended key usage (which many folks  improperly
interpret to mean SSL client authn, only).

As always, real web security is a hybrid world. Once rdf/xml file get
signed, one can see the metadata driving all this process using triples and
services descriptions, rather than SAML2 metadata format. Progress on
replacing SAML2's signed metadata seems slow, if not at dead stop, though -
since we still cannot sign RDF streams effectively.



-----Original Message-----
From: public-xg-webid-request@w3.org [mailto:public-xg-webid-request@w3.org]
On Behalf Of Mo McRoberts
Sent: Friday, April 08, 2011 5:30 AM
To: Henry Story
Cc: WebID XG
Subject: Re: WebID security picture


On 8 Apr 2011, at 12:45, Henry Story wrote:

> If you publish the foaf "anywhere at all" you still are dependent on what
that agent publishes about you there. If you have to sign those documents
with your private key there then you are not going to be able to generate
very dynamic web pages without placing the private key there too. 

It depends on which parts need to be very dynamic surely? Bearing in mind
the only assertion we might care about as being concrete (because it's the
only one which is relevant to the basic relying party processes) is the
public key listing, and so that's the only part of it which needs to be
signed - maybe you have detached counter-signatures just for those,
referenced as a property of the rsa:RSAPublicKey (e.g., <ex:counterSignature
rdf:resource="keysigs.asc" />), or you sign the 'identity' FOAF but use
rdfs:seeAlso as a way of associating more dynamic documents. there are
plenty of possibilities for that.

> If you want to reduce the surface of attack, the best would be for your
foaf to be hosted on the same device you are connecting from. WebID does not
exclude that possibility: in fact it is quite possible, especially if your
computer is always on. 

Increasing proportions of computers *aren't*, or are behind restrictive
firewalls, or layers of NAT. it's fine in the home, but what about on my
mobile phone or tablet, or my laptop which moves between networks regularly,
for example?

> We are trying to stay very open to all these possibilities by being as
light weight as possible. We are just specifying the minimum to get going.
This should allow many different implementations of webid to emerge and a
network effect to get going. Being too restrictive early on for the sake of
security, that people have trouble understanding is not going to enable
adoption.

By the same token, this has to be balanced by usefulness, surely? If there
are lots of WebIDs out there but they have limited usefulness, then that's
not necessarily a great result if you could have lots of WebIDs out there
which are more useful by being a little more restrictive and making efforts
to mitigate those restrictions?

Here's a concrete example of why I'm concerned about this:

I use the EasyWebID Facebook application to generate the FOAF document for
my WebID, because some of my friends did the same thing. It produces FOAF
automatically based upon data it has access to in Facebook, along with a
list of public keys I supply of WebID certificates.

I log into a bunch of sites using WebID certificates. These sites don't care
deeply about the public keys that I use, because to do so would be annoying:
as far as they're concerned, my user ID is
http://apps.facebook.com/easywebid/nevali#person and I authenticate by
providing a certificate with that URI in the SAN and checking that the FOAF
document has a matching public key entry. If my login was my certificate's
public key, then I'd only be able to log in from devices/browsers which
included that particular certificate, which is both annoying and risky (I
have to transfer pkcs#12 bundles about, increasing chances of compromising
security on the private keys, and everything becomes reliant me not losing
that key.).

Somebody later gains access to my Facebook account, and adds their own
certificate's public key to my FOAF document. Now, they can log in to
everything I've used my WebID for previously, impersonating me.

One could say "well, the EasyWebID Facebook application should take steps to
prevent this from happening", but there's every chance they won't; we can't
rely on users being able to differentiate between a provider who is good at
security and one who isn't if we can't rely on users knowing how and why
private keys work and how to protect them.

So, lending more weight to the IDs of the key in the client certificate
isn't an option because it massively reduces the utility of WebID as a
proposition, and similarly increases chances of lost identity. But relying
on the subject URI means that if somebody gains access to the place where
the WebID is published, everything I've ever used WebID to log into is now
accessible as well, so that's not viable either.

Thus, the solution must be something which isn't either of these two things.

M.

--
Mo McRoberts - Data Analyst - Digital Public Space, Zone 1.08, BBC Scotland,
40 Pacific Quay, Glasgow G51 1DA, Room 7066, BBC Television Centre, London
W12 7RJ,
0141 422 6036 (Internal: 01-26036) - PGP key 0x663E2B4A




http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal
views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance
on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

Received on Friday, 8 April 2011 16:15:21 UTC