[foaf-protocols] some ssl + HTTP security-related design issues specific to webid protocol

peter williams home_pw at msn.com
Thu Dec 23 20:22:36 CET 2010


In my mind, if Google can fiddle with the SSL handshake [and introduce
blacklists against certain sites into its browser concept], so can we -
probably in cooperation with IETF TLS WG for any technical mechanism
standardization. Ideally, any such fiddles should however preserve semantic
security of the SSL handshake protocol (leveraging such as OAEP-capable
ciphersuites that add plaintext-awareness to RSA) while accommodating the
unique nature of the webid protocol and its "scheme-centric" semweb context.

 

Seeing as its vacation time for me and I can play with this topic in code,
I've looked up my own v2 FOAF+SSL implementation from a few months ago - in
light of what Photuris was attempting to teach. Recall, Photuris (rather
like D-TLS) wants to enable a NIC in the relying party's server to discard
attacking packets seeking to disrupt availability. If one assumes that NICs
are SSL-capable, make the leap and want said SSL-NICs to discard attacking
webid protocol runs, by preserving resources where possible. This is not
fanciful thinking - I have such a (software) SSL NIC on my desktop, albeit a
virtual vs an offloading SSL-NIC. The world of iscsi clients used in private
cloud arrays are already offloading to real SSL-offloading nics (see Hi/FN
cards, in OpenBSD world).

 

We know that URI de-referencing is a core part of the webid protocol. And,
the act of de-referencing should occur using https when the webid cites the
https scheme -  so that the source of the document can be identified and
authenticated to the relying party. That is: there is one https channel used
to communicate the claimant's client cert bearing the reference, and there
is another https channel used by the relying party to de-reference the
inbound URI when it cites the https scheme.

 

What is the relationship between these two http(s) channels?

 

All we really know (from Henry) is that the architecture contemplates many
such relationships, and each one is operationally-selected by peers as part
of the "trust provider" to be used in the webid protocol run. A particular
trust provider might even entirely ignore https security services for I&A,
in favor of using DNSsec for server name authentication. A third provider
might augment https with DNSsec. A fourth may leverage a connectionless
D-TLS association instead of https, should the relying party already have
access to an SSLVPN endpoint operated by the claimant. A fifth may leverage
a TTLS association, similarly, in an environment based on trusted switch
paths over stretched vlans. A sixth might use stretched vlans transported
over MPLS channels from ATM service providers supporting one's home DSL
connection. A seventh may be running IPsec overlays over those vlans to
create a multi-protocol VPN. An eighth may be running group keying over the
IPsec-related ISAKMP, where the claimant with a semweb badge is also a
secure multicast group. Etc. Etc.

 

We might now consider one trust provider that cascade only https channels -
much as we have known them since 1996. Incidentally, this now allows us to
categorize providers as: exclusively browser based (using URI schemes only),
and secure NOS based (leveraging non-web architecture notions, such as
routed IPsec overlays, MPLS VPNs, multicast groups,.). 

 

So, concerning the browser category:-

 

The Photuris protocol (mentioned previous in the thread) computes a
hash-cookie over src/dest IP addresses and ports enabling the receiver
working with the signaling of that hash-cookie to determine if the sender is
the owner of the src IP address of the inbound datagrams. We might use SSL
sessionids similarly; to enable the receiver to know that the sender of the
client cert is the "controller" of the FOAF document. 

 

When supported by such a trust provider, the claimant can assert not only a
webid - but can assert " I control the document." To address concerns that
vendors might abuse the cloud, folks can say: there is no firm (such as
PayPal or Amazon) indirectly governing or controlling our communications.
This is not to say that PayPal or Amazon cannot serve the claimant as a
contractor; but a TTP-grade "governance relationship" is withheld.

 

What a provider spec might do is require that that channel used for the
webid de-referencing act always be use an SSL "connection resume phase"
protocol run (vs. a full handshake). Only the document repository with the
ssl sessionid cited by the relying party can complete this (fast) SSL
handshake.

 

To be like Photuris and allow the party relying on the webid to easily
discard webid claims that are not from parties who control their own FOAF
document (because they outsourced the document's web-management  to a
"governing party", like Amazon or PayPal), one might use the sessionid in
the role of the Photuris cookie

 

In such a world. 

 

1.       The claimant must have a cached and valid SSL sessionid with the
relying party.

2.       The claimant *may* communicate the sessionid in a new TLS hello
extension for webids, when releasing the client cert bearing the webid

3.       The TLS hello extension also communicates a variant of the
(Nokia-style) server name indication extension, identifying the virtual host
for the id document 

4.       The relying party *may* discard claims delivered by a webid
protocol that cannot cite a sessionid in its own current SSL session cache

 

This scheme has an apparent downside - the relying party must have performed
https with you the claimant, before you claim (in order to have cached the
sessionid). But this property is actually useful as a means of orchestrating
what I will term "trust subscription". The difference allows (i) FOAF+SSL
type interactions, and (ii) the enhanced interactions that guard against
attacks on consumers by cloud providers seeking to impose governance
presumptions. Where a relying party cares not about the effects of cloud
provider attacks on their users, they only offer a weaker trust provider.
When the relying party cares (as parts of its trust propositions to the
claimant about the privacy policies it enforces), it can optionally confirm
that the documents supplied to as part of the webid protocol are controlled
by the claimant (and not a cloud provider). The claimant gets to verify that
the relying party offering such assurances is indeed acting according to the
enhanced protocol. furthermore.

 

 

 

 

From: foaf-protocols-bounces at lists.foaf-project.org
[mailto:foaf-protocols-bounces at lists.foaf-project.org] On Behalf Of peter
williams
Sent: Wednesday, December 22, 2010 6:43 PM
To: foaf-protocols at lists.foaf-project.org
Subject: [foaf-protocols] some ssl + HTTP security-related design issues
specific to webid protocol

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20101223/92b5652f/attachment.htm 


More information about the foaf-protocols mailing list